FORITECH SECURE SYSTEM

Foritech Protocol Specification

Version: 1.0-draftStatus: ExperimentalMedia Type: application/vnd.foritech.containerExtension: .ftech

This document defines the signed binary container format and verification model used by Foritech Secure System — a cryptographic verification platform for telemetry and machine data.

Purpose

The Foritech protocol enables cryptographic verification of telemetry, machine-generated data, files, edge-to-cloud integrity records, and signed industrial or IoT payloads. The protocol provides authenticity, integrity, tamper evidence, deterministic verification results, and audit-ready verification behavior.

Design Principles

→Never trust data before cryptographic verification
→All security-relevant metadata must be covered by the signature
→Malformed containers must be rejected
→Verification results must be deterministic
→Policy enforcement must be separated from parsing and signature verification

Container Model

A Foritech container encapsulates four logical components bound into a single signed verification unit:

1. Header
2. Metadata
3. Payload
4. Signature

Header

The header identifies the container format and protocol version. Fields include magic, version, algorithm, and container profile identifier. The header is part of the signed material.

magic:     "foritech"
version:   1
algorithm: ML-DSA

Metadata

Metadata contains fields required to interpret and validate the container. All metadata affecting trust, verification, routing, or replay handling must be covered by the signature.

device_id: "device-001"
timestamp: 1710000000
key_id:    "device-key-1"
nonce:     "<random-value>"

Payload

The payload contains the actual data — telemetry samples, machine status, file contents, or industrial protocol output. The payload is treated as opaque data by the core verification engine.

Signature

The signature provides authenticity and integrity protection. It must cover header, metadata, and payload.

PRIMARY ALGORITHM

ML-DSA-65

Post-quantum cryptography — NIST standardized. PQC-first protocol.

Container Creation

1.Construct header
2.Construct metadata
3.Attach payload
4.Generate ML-DSA signature over header + metadata + payload
5.Append signature
6.Serialize as binary .ftech container

Container Verification

1. Parse header
2. Validate container structure
3. Parse metadata
4. Load verification key
5. Verify signature
6. Return VERIFIED or REJECTED

Verification Output

Verification produces one of two results. No partial trust state is permitted.

VERIFIED

REJECTED

Core Verification vs Service-Layer Policy

Core verification handles parsing, structure validation, key loading, signature verification, and produces VERIFIED or REJECTED. Service-layer policy handles replay protection, timestamp windows, key lifecycle, device allowlists, and audit logging. This separation keeps the core deterministic and portable.

Replay Protection

Replay protection is not guaranteed by signature validity alone. Mitigation uses timestamp validation, nonce tracking, device identity tracking, and service-side replay caches enforced by the platform layer.

Security Requirements

Strict parsing, explicit signature verification, deterministic behavior, rejection of malformed containers, rejection of altered signed content. All trust-relevant metadata must be signed. Unsigned metadata must not influence trust decisions. Fail closed on errors.

Interoperability

Requires shared container specification, deterministic serialization, agreement on protocol version, metadata semantics, and signature algorithm. Payload interpretation may vary but verification behavior must be consistent.

Media Type Registration Intent

Media Type: application/vnd.foritech.container
Extension:  .ftech

Verification Philosophy

"Never trust data without cryptographic verification."

A container is either verified or rejected — no partial trust.

Error Codes

Verification rejection must include a reason code.

CODE	MEANING
INVALID_SIGNATURE	Signature verification failed
MALFORMED_CONTAINER	Container structure is invalid or incomplete
UNKNOWN_KEY	key_id not found in trusted key registry
EXPIRED_TIMESTAMP	Timestamp outside the accepted replay window
REPLAY_DETECTED	Nonce has been seen before
UNSUPPORTED_VERSION	Protocol version not supported
UNSUPPORTED_ALGORITHM	Signature algorithm not in approved registry
POLICY_VIOLATION	Container rejected by service-layer policy

Versioning Policy

The container header includes a version field identifying the protocol version. Implementations must reject containers with unsupported versions with reason code UNSUPPORTED_VERSION. Version negotiation is not performed. Producers must declare the version they use. Consumers must explicitly support that version. Backward compatibility is not guaranteed across major versions.

Current version: 1

Canonicalization Rules

Deterministic signing requires a canonical serialization of the signed material.

→JSON fields must be serialized in lexicographic key order
→No whitespace between tokens (compact form)
→String encoding: UTF-8
→Numbers: integer representation, no trailing zeros
→Boolean: true / false lowercase
→Signed byte sequence: canonical(header) || canonical(metadata) || payload_bytes
→No length prefix or delimiter added between sections at the outer level

Implementations must produce identical byte sequences for identical logical containers. Any deviation in serialization invalidates the signature.

Key Trust Model

Each container declares a key_id in the metadata. The key_id is derived from the PQC public key using SHA-256(public_key_bytes).hex(). The key_id is a stable identifier, not a trust source. Trust is established by locating the corresponding public key in the Foritech Device Registry and performing ML-DSA-65 signature verification.

ACTIVE

accepted for verification

REVOKED

rejected — containers signed with this key are rejected

EXPIRED

rejected by policy after TTL

Status

EXPERIMENTAL

This specification is experimental and subject to controlled evolution under the Foritech Secure System architecture and governance model.

← Back to foritech.bg