Secure Infrastructure Access Protocol (SIAP)

Executive Summary

Deterministic two-factor infrastructure access built entirely from symmetric primitives

SIAP is a certificate-free access architecture for environments where login, key release, and device authorization must remain viable without PKI, online validators, or live network dependencies. It binds physical token possession and passphrase knowledge into a deterministic authentication process driven by SHAKE, cSHAKE, SCB, and RCS, while replacing reusable credentials with a one-time token tree that advances irreversibly after each successful use.

Within the QRCS stack, SIAP occupies the role of a post-quantum authentication and authorization layer rather than a transport protocol. Its strategic value is that it solves identity and access at the point of use: air-gapped consoles, secure boot or firmware release, privileged maintenance, offline wallets, and infrastructure nodes can authenticate through a compact symmetric mechanism that is auditable, deterministic, and resistant to replay, rollback, and database compromise.

High relative value Role: Offline authentication and access control layer Primary buyers: Critical infrastructure, fintech, industrial, embedded, government

Protocol At A Glance

Factor model Memory token + passphrase

Authentication succeeds only when the removable token state and the SCB-hardened passphrase proof are both present and mutually consistent.

Credential model 1,024 one-time leaves

The device carries an encrypted token tree and each successful session burns exactly one leaf, increments the index, and rewrites the sealed state.

Cryptographic base SHAKE / cSHAKE / SCB / RCS

The construction remains in the symmetric hash domain and avoids certificate parsing, KEM negotiation, and reliance on trapdoor assumptions.

Operational profile Offline and low-footprint

The specification positions SIAP for smart-card class devices, secure elements, embedded controllers, and disconnected infrastructure access workflows.

Executive Summary

Strategic overview of SIAP as a certificate-free, post-quantum authentication system for infrastructure access, tokenized authorization, and offline deployments.

Open Executive Summary

Formal Analysis

Game-based treatment of authentication soundness, replay and reuse resistance, offline passphrase security, forward secrecy by erasure, and server database safety.

Open Formal Analysis

Technical Specification

Engineering description of identity structures, server and device key formats, key-tree generation, enrollment, authentication flow, and mathematical construction.

Open Technical Specification

Strategic Positioning

SIAP replaces persistent credentials with deterministic state progression

The protocol is built against a specific operational problem: certificate-driven or password-centric access systems retain standing credentials, depend on revocation or online validation infrastructure, and become difficult to govern in disconnected or long-lifecycle environments. SIAP replaces that model with a sealed one-time token tree and a monotonic counter that jointly define the only acceptable authentication state.

Why the model is structurally different

SIAP should not be read as a conventional MFA variant. It eliminates reusable password-verifier login semantics, avoids certificate hierarchies entirely, and turns every successful authentication into a destructive state update. That shift is the core security mechanism: replay fails because the previously valid leaf no longer exists, and rollback fails because the server-side tag and the device state cease to agree.

Dimension	Certificate / Password Systems	SIAP
Credential state	Persistent verifier or reusable secret	Single-use indexed leaf
Trust dependencies	PKI, revocation, network services	Local server state only
Forward security basis	Usually absent at login layer	Leaf burn and index advancement
Offline posture	Often degraded	Native operating mode
Quantum exposure	Dependent on asymmetric migration	Symmetric hash-domain construction

High-level technical rationale

The server maintains a master derivation key and compact per-device tag data; the removable token carries the encrypted device state; and the user supplies the passphrase that unlocks the sealed token tree. Authentication is therefore the intersection of three consistent views of state: the device identity and index, the sealed one-time token tree, and the server-side tag binding the current tree hash and passphrase hash.

Identity scoping is encoded directly into fixed-width identifiers for server, user, device, and key index.
The server can derive expected leaves on demand from its base secret rather than storing plaintext authentication tokens.
Compromise of the server database does not reveal future leaves, because the database stores hashes and identifiers rather than live token material.
Each authentication event irreversibly consumes the active token and advances a monotonic index, enforcing single-use credentials and eliminating replay viability.
All long-lived secrets and token material are derived from SHAKE XOF and protected by a memory-hard SCB KDF, increasing resistance to offline passphrase attacks.
The protocol operates without public-key infrastructure or online trust dependencies, enabling secure authentication in disconnected or air-gapped environments.

From an acquisition standpoint, SIAP is best understood as a replacement-class access mechanism for infrastructure where long-lived PKI dependencies are operationally expensive, hard to audit, or impossible to sustain at the edge.

Identity and State Model

Server state, device state, and verification state are compact but tightly bound

The SIAP specification defines small, fixed-format structures rather than a large object model. This is important to the protocol’s deployment value because it keeps the access layer analyzable and implementable on constrained devices.

Server identity

The server identity string (Sid) scopes authentication to a domain, server group, and specific server instance. This binds all derived material to the issuing infrastructure context.

Fields	Domain, Server Group, Server
Role	Administrative scoping for server state and salt derivation

Device identity

The device identifier (Did) combines infrastructure and user context with a unique device field, allowing revocation or reassignment at the device, user, or group level without disturbing unrelated assets.

Fields	Domain, Server Group, Server, User Group, User, Device
Role	Deterministic namespace for key-tree derivation

Server key

The server maintains Kbase, the derived diversification salt Dsalt, the server identity, and an expiration value. This structure is the root of all token-tree derivations.

Contents	Kbase, Sid, Dsalt, Expiration
Role	Root derivation state kept only on the server

Device key and tag

The removable token carries the encrypted device key structure, while the server stores a searchable tag containing the key identity, the token-tree hash, and the SCB passphrase hash.

Token	Kid, Expiration, encrypted Ktree
Server tag	Kid, Khash, Phash

Cryptographic Construction

Deterministic derivation, passphrase hardening, and authenticated sealing replace PKI mechanics

The formal paper and specification describe SIAP as a symmetric authentication system in which every critical value is derived, hashed, or authenticated under a small set of Keccak-based functions and the RCS authenticated cipher. The design objective is not merely compactness, but removal of uncontrolled cryptographic branches.

Derivation abstraction

Core construction Kid = DID ∥ idx T[i] = cSHAKE(Kbase, config, DID ∥ i) Phash = SCB(passphrase) rcskey = cSHAKE(Phash, Kid, Dsalt) Kseal_dev = RCS_Enc(rcskey, T, Kid, tsexp) Tsrv = cSHAKE(Kbase, config, Kid)

The structure matters because the server can reconstruct the expected token for any valid index while the device stores only the encrypted tree. The passphrase does not directly authenticate the session by itself; it protects access to the live device state and binds the sealing key to both the identity and the server diversification salt.

This separation between derivation and storage reduces the attack surface associated with credential persistence. The server retains only a base secret, identity records, and verification hashes, while the device carries the evolving token state in encrypted form. An adversary must therefore compromise both the passphrase and the physical device state at the correct index to reproduce a valid authentication event, with neither component alone providing sufficient information to reconstruct future tokens.

Forward secrecy is enforced through the one-time key discipline embedded in the token chain. Each successful authentication destroys the currently active leaf and advances the index, ensuring that previously used tokens cannot be replayed and future tokens cannot be inferred. Even with full visibility of past exchanges, the absence of retained intermediate material prevents retrospective reconstruction of prior session keys.

Operationally, this design allows the authentication layer to remain independent of transport protocols and session management systems. The derived token can be consumed directly as a symmetric key, injected into existing secure channel frameworks, or used to authorize application-level actions. This decoupling enables SIAP to act as a drop-in authentication primitive across heterogeneous infrastructure without requiring changes to established network protocols.

Primitive and state inventory

Primitive	Function	Why it matters
SHAKE-256 / SHAKE-512	Tree hashing and output expansion	Keeps the system inside a symmetric post-quantum security model
cSHAKE	Domain-separated derivation of salt, leaves, and sealing keys	Separates token, server, and sealing contexts cleanly
SCB	Memory-hard passphrase processing	Raises the work factor of offline guessing against stolen device state
RCS	Authenticated encryption of the device key tree	Ensures the sealed token state cannot be modified silently
Optional KMAC usage	Message authentication / derived use cases	Supports downstream protected uses of the one-time secret

The repository documentation also positions SIAP as a drop-in replacement for password- or static-key-based access, with the resulting one-time secret suitable not only for login confirmation but also for storage unlock, PSK injection, or release of symmetric channel material.

Operational Model

Enrollment is one-time provisioning; authentication is deterministic state transition

SIAP’s runtime behavior is intentionally narrow. There is no negotiation, no alternate authentication branch, and no certificate validation phase. The engineering flow is a repeatable sequence of checks and state updates.

Enrollment and sealing

The server generates the master derivation state, assigns the device identity, constructs the one-time token tree, hashes the full tree for later verification, computes the SCB-hardened passphrase hash, and seals the device state under an RCS key derived from (Phash, Kid, Dsalt). The server then retains only the server key and the device tag; the removable token receives the encrypted device key structure.

Stage	Effect
Server key generation	Creates Kbase, Sid, Dsalt, and the expiration context
Device key generation	Builds a 1,024-leaf token tree keyed to DID and index
Passphrase hardening	Transforms the user secret into SCB output for verification and sealing
State sealing	Encrypts and authenticates the device key structure before distribution

Authentication path

The server validates the key identity and expiration fields, verifies the SCB passphrase hash, decrypts and authenticates the sealed tree, recomputes the tree hash, extracts and burns the current device token, derives the expected server token from the current identity, compares the two in constant time, and only then advances the state.

Identity mismatch, expiration mismatch, passphrase failure, decrypt failure, tree-hash divergence, and token mismatch all terminate before state update.
On success the consumed leaf is erased, the key index increments, the server tag is regenerated, and the device state is re-encrypted under the updated identity.
The protocol therefore makes synchronization itself part of the authentication property: stale or replayed state is rejected because it no longer matches the server’s expected index and tree commitment.
Because every transition is validated against both the stored commitment and the derived token, any deviation in state progression is immediately detectable and results in deterministic authentication failure.

This is why SIAP is more accurately described as a state-evolving authentication machine than as a simple password replacement. The acceptable credential is the current synchronized device state, not just a memorized secret.

One-Time Token Lifecycle

Forward secrecy is enforced by leaf consumption and monotonic index progression

The formal analysis is explicit that SIAP’s replay and rollback properties depend on strong erasure and monotonic state advancement. Those assumptions are not decorative: they are the protocol’s central operational invariants.

State progression semantics

Each authentication consumes exactly one leaf from the current index position, clears that token from the device tree, increments the device identity counter, regenerates the tree hash, and reseals the device state. A later compromise of the token therefore exposes only the sealed remainder of the tree, not previously consumed leaves.

Because the server independently derives the expected leaf from the shared base secret and index, it does not need to persist historical token material to validate progression. This asymmetric knowledge model ensures that verification remains deterministic while minimizing stored sensitive data, and it prevents an attacker with partial state disclosure from reconstructing either prior or future authentication values.

Property	Mechanism
Replay resistance	Used leaf is erased and no longer accepted
Rollback resistance	Server tag and device hash cease to match after stale restoration
Forward secrecy	Past leaves are destroyed and not recoverable from current state
Predictable verification	Server derives the expected leaf directly from Kbase and Kid

Why the one-time structure matters

Traditional login systems can revoke or rotate credentials, but they do not ordinarily make past successful authentication material unrecoverable. SIAP does. A captured network observation yields a token that has already been burned; a stolen database yields identifiers, hashes, and state commitments rather than future leaves; and a stolen device without the passphrase yields only encrypted token-tree state.

The repository README extends this operational view by positioning SIAP not only for terminal or console login, but also for offline wallets, secure firmware release, SCADA and HMI unlock, cold-wallet signing ceremonies, and per-session PSK injection for symmetric channels. In all of those cases, the important property is identical: the authorization secret is single-use and state-bound.

This consistency across use cases allows SIAP to act as a unifying authentication primitive rather than a narrowly scoped access mechanism. Whether the token is consumed to unlock a device, authorize a transaction, or seed a secure channel, the semantics remain unchanged: the system verifies a deterministic, one-time value tied to a specific identity and index, then advances the state. This removes ambiguity in how authentication is interpreted across environments and simplifies both auditing and system integration.

From a systems perspective, the protocol replaces long-lived credentials with a continuously advancing authorization stream. This reduces the exposure window associated with credential theft, eliminates the need for revocation infrastructure tied to static secrets, and provides a built-in progression model that can be monitored and enforced. The result is an authentication layer that aligns with zero-trust principles while remaining lightweight enough for embedded and offline deployments.

Security Model

Formal treatment covers authentication soundness, offline resistance, and state continuity

The formal paper models an adversary that can observe authentication attempts, obtain the server-side device tag, obtain the sealed device key, attempt offline passphrase guessing, and try to force desynchronization. The resulting security goals are therefore tied directly to realistic operational compromise scenarios.

Security properties proved or reduced in the formal model

Goal	Operational meaning
Authentication soundness	An adversary should not authenticate without an unconsumed leaf, the correct passphrase-derived state, or the server master secret
Replay and reuse resistance	Previously consumed tokens must fail on reuse
Offline attack resistance	Stolen device state still requires repeated SCB work per passphrase guess
Server database safety	Stored tag data does not enable derivation of future authentication tokens
Symmetric forward secrecy	Past consumed leaves are not recoverable after later compromise

Assumptions and compromise boundaries

The formal argument relies on secrecy of Kbase, pseudo-random behavior of cSHAKE under secret input, security of RCS authenticated encryption, the memory hardness of SCB, reliable erasure of consumed leaves, and strict monotonic enforcement of the index field. These are transparent assumptions, not hidden engineering conveniences.

Equally important is what the protocol does not claim. If the server master key is lost, future leaf derivation is exposed; if strong erasure fails on the device, prior-state recovery becomes easier; and if state updates are not persisted correctly on both sides, desynchronization can occur. The value of the design is that these boundaries are explicit and operationally manageable.

This explicit boundary definition allows operators to align controls directly with the protocol’s assumptions. Server key material can be isolated or hardware-backed, device state can be protected with secure storage and verified erasure routines, and synchronization can be enforced through transactional update handling. Rather than obscuring risk behind opaque mechanisms, SIAP exposes its trust dependencies in a way that supports auditing, monitoring, and disciplined operational hardening.

The practical consequence is that SIAP gives operators a smaller and more explainable trust surface than PKI-dependent login systems. The remaining trust anchors are few: server master-key protection, passphrase quality, device integrity, and correct monotonic state storage.

Operational and Commercial Fit

SIAP is aligned with access problems that are infrastructure-bound, offline, or compliance-sensitive

The protocol is especially well suited to secure administrator login, field-service authentication, payment terminal maintenance, OEM activation, local unlock of SCADA or industrial HMI systems, encrypted storage release, and environments that need post-quantum migration without inheriting the certificate and revocation burden of full PKI. Its commercial value comes from giving operators a minimal-trust access layer that can be audited, provisioned, and reasoned about independently of higher-level transport systems. It therefore integrates cleanly into existing infrastructure as a deterministic authentication primitive without requiring redesign of surrounding network or application layers.

Deployment fit

Air-gapped and intermittently connected infrastructure
Embedded or smart-card class authenticators
Privileged maintenance and technician access
Cold-storage, wallet, and key-release ceremonies
Certificate-free access control inside regulated environments