Glacis Protocol -- Security Model

Version 0.1.0 | February 2026

Table of Contents

1. Security Philosophy
2. Threat Model
3. Privacy Guarantees
4. Nullifier Security Properties
5. PII Handling: Client vs Server Path
6. Certificate Authority Trust Model
7. Post-Quantum Resistance Analysis
8. Attack Vectors and Mitigations
9. Comparison with Other Proof of Humanity Systems
10. Security Invariants

Security Philosophy

Glacis Protocol treats security as existential. This is an identity and cryptographic protocol -- a single vulnerability can compromise the uniqueness guarantees for every user. The design follows three principles:

1. Minimize trust assumptions. Trust only the mathematics (hash collision resistance, STARK soundness) and the government CA signing infrastructure.
2. Minimize data exposure. No PII is ever stored on-chain, in logs, or in any persistent storage. The only data that survives the verification process is a set of Poseidon hashes.
3. Fail closed. If any verification step fails -- STARK proof invalid, CA untrusted, nullifier already registered -- the entire operation reverts. There are no partial verification states.

Threat Model

Primary Threats

Threat Matrix by Component

Privacy Guarantees

Absolute Rule

Zero personally identifiable information (PII) is ever stored on-chain, in logs, or in any persistent storage.

What IS Public (On-Chain)

What Is NEVER Public

• Name
• Nationality (beyond CA-level inference)
• Date of birth
• Document number
• Photo
• Biometric data (fingerprints, iris)
• MRZ text
• Any raw passport field content

Cross-Application Unlinkability

A key privacy property: different applications cannot link the same user across services.

User Alice verifies once. Two apps query her identity:

App A (Bastion blog):
  pseudonym_A = poseidon(nullifier, 'bastion_blog')
  --> 0x7a3f...

App B (DeFi protocol):
  pseudonym_B = poseidon(nullifier, 'defi_protocol_x')
  --> 0x1c8e...

App A cannot determine that pseudonym_A and pseudonym_B belong to the same person.
Poseidon preimage resistance prevents linking.

The only entity that can link pseudonyms is the user themselves (who knows their nullifier) or someone who compromises the user's wallet.

Nullifier Security Properties

The nullifier is the core anti-sybil primitive. Its security properties are non-negotiable.

Property 1: Deterministic

Same passport + same protocol version = same nullifier. Always.

generate_nullifier(passport_id_X, 'glacis_v1') == generate_nullifier(passport_id_X, 'glacis_v1')

This is enforced by the circuit. The nullifier computation has no randomness and no user-controlled inputs. The same passport data will always produce the same nullifier, regardless of which device runs the prover, which wallet submits the proof, or when the verification occurs.

Property 2: Irreversible

Given nullifier N, it is computationally infeasible to find passport_id such that:
  poseidon(passport_id, 'glacis_v1') == N

This relies on the preimage resistance of Poseidon hash. Poseidon is designed for algebraic hash function security in STARK-friendly fields, with a security level of 128 bits against preimage attacks.

Property 3: Collision-Resistant

For passport_id_A != passport_id_B:
  poseidon(passport_id_A, 'glacis_v1') != poseidon(passport_id_B, 'glacis_v1')

with overwhelming probability (2^-128 collision probability).

This prevents two different passports from accidentally or deliberately producing the same nullifier.

Property 4: No User Bypass

nullifier = poseidon(passport_unique_id, domain_separator)

There is NO third input. No salt, no secret, no user-chosen value.

Why this matters: If users could provide a salt (nullifier = poseidon(id, domain, user_salt)), then the same person could generate different nullifiers by choosing different salts, creating multiple identities from one passport. This would completely defeat the anti-sybil mechanism.

Contrast with OpenPassport: OpenPassport uses hash(government_signature) as the nullifier. This is also deterministic (the government signature is unique per passport and not user-controlled). Glacis uses poseidon(hash(DG1), domain_separator) -- equivalent in security properties but using Poseidon for STARK efficiency.

Property 5: Scoped Privacy

Different applications see different pseudonyms derived from the same nullifier:

pseudonym = poseidon(nullifier, app_domain)

This prevents cross-application tracking while maintaining one-person-one-identity within each application.

Migration and Renewal

When a user changes wallets or renews their passport:

• Wallet change: User proves possession of the same passport and signs with the old wallet. The migration mechanism transfers the attestation to the new wallet while keeping the same nullifier.
• Passport renewal: User proves with the new passport. A new nullifier is generated (different passport data). The old attestation is retired and a new one is minted.

PII Handling: Client vs Server Path

Client-Side Path (Option A: Direct)

Passport --> NFC Reader --> Device Memory --> Cairo Circuit --> Proof
                                 |
                                 +-- Data NEVER leaves device
                                 +-- No network transmission of PII
                                 +-- Maximum privacy guarantee

Trust model: User trusts only their own device.

Server-Side Path (Option C: Ephemeral)

Passport --> NFC Reader --> Device Memory --> TLS --> Server Memory --> Proof
                                                          |
                                                          +-- Data in RAM only
                                                          +-- Proof generated
                                                          +-- Data zeroed immediately
                                                          +-- No disk write
                                                          +-- No logging of PII
                                                          +-- Proof returned to device

Trust model: User trusts:

1. TLS transport security (standard web security assumption)
2. Vauban's ephemeral server implementation (data deletion guarantee)
3. Server host environment (no memory dumping by third parties)

Server security measures:

• Memory-only processing (no filesystem PII writes)
• Explicit memory zeroing after proof generation (zeroize crate in Rust)
• No PII in application logs (structured logging excludes passport fields)
• No PII in error reports or crash dumps
• Process isolation (containerized, no shared memory)
• Regular security audits of the prover service

Comparison

Certificate Authority Trust Model

Glacis trusts government Certificate Authorities (CAs) that sign ICAO 9303 passports. This is the same trust model used by every border control system worldwide.

CA Registry Architecture

CaRegistry (on-chain)
|
|-- trusted_cas: Map<felt252, bool>      Hash of CA public key -> trusted
|-- revoked_cas: Map<felt252, bool>      Hash of CA public key -> revoked
|
|-- Functions:
|   |-- is_trusted(ca_key_hash) -> bool  Check if CA is trusted AND not revoked
|   |-- add_ca(ca_key_hash)              Add new trusted CA (admin only)
|   +-- revoke_ca(ca_key_hash)           Revoke compromised CA (admin only)

Trust Chain

ICAO (International Civil Aviation Organization)
    |
    +-- Country Signing CA (CSCA)        Root certificate per country
        |
        +-- Document Signer (DS)         Signs individual passports
            |
            +-- Passport SOD            Government signature over chip data

Glacis verifies the DS signature over the passport's SOD (Security Object of the Document). The DS public key is validated against the CSCA. The CSCA key hash is what gets registered in the CaRegistry.

Revocation Scenarios

Governance

CA management is initially admin-controlled (protocol owner). Future governance may migrate to a multisig or DAO structure as the protocol matures.

Post-Quantum Resistance Analysis

STARKs vs SNARKs

Why Post-Quantum Matters for Identity

Identity proofs have long time horizons. A Glacis attestation has a 5-year TTL. If quantum computers capable of breaking elliptic curve cryptography emerge within 10-20 years (conservative estimates range from 2035-2050), then:

• SNARK-based systems would need to re-prove all existing attestations with new cryptographic assumptions. Users would need to re-verify.
• STARK-based systems (Glacis) would continue operating unchanged. The hash-based security assumptions remain valid.

Glacis Quantum Exposure Analysis

Note on RSA/ECDSA in circuit: The government's RSA/ECDSA signature is verified inside the Cairo circuit. If quantum computers break RSA, an attacker could forge a passport signature. However, the forged signature would need to be accepted by the CA trust chain AND produce a unique nullifier. The defense is:

1. The CA Registry can revoke compromised CAs
2. Passport-issuing governments would rotate to post-quantum signature schemes (ICAO is already studying this)
3. The STARK proof itself remains sound regardless

Comparison with Alternative Approaches

Attack Vectors and Mitigations

1. Passport Cloning Attack

Vector: An attacker physically clones a passport's NFC chip to create duplicate passport data.

Analysis: Modern passports (since BAC/AA) include Active Authentication (AA) or Chip Authentication (CA), where the chip proves it possesses a private key that cannot be extracted. Glacis Phase 1 focuses on Passive Authentication (verifying SOD signature). Active Authentication integration is planned for Phase 2+.

Mitigation: SOD signature verification prevents data fabrication. Active Authentication (future) would prevent chip cloning.

2. Stolen Passport Attack

Vector: An attacker steals a passport and verifies before the legitimate owner.

Mitigation:

• The nullifier is bound to the passport, not the wallet. If the legitimate owner later verifies, the nullifier is already registered.
• The legitimate owner can use the migration mechanism (prove same passport + old wallet) to reclaim the attestation.
• Passport theft is a criminal offense with existing legal remedies.

3. Corrupt Government Attack

Vector: A government issues fraudulent passports specifically to create Sybil identities.

Mitigation:

• This is a fundamental limitation of any document-based system. Glacis trusts the same CA infrastructure that the entire international travel system relies on.
• The CA Registry can remove trust in a compromised or corrupt government CA.
• Statistical anomaly detection (unusual verification patterns from a single CA) can flag suspicious activity.

4. Memory Extraction Attack (Server Path)

Vector: An attacker with access to the prover server extracts passport data from memory during proof generation.

Mitigation:

• Proof generation is fast (<3s), minimizing the window of exposure.
• Memory is explicitly zeroed after proof generation (zeroize crate).
• Server runs in isolated containers with no shared memory.
• No core dumps enabled.
• Hardware-level memory encryption (AMD SEV / Intel TDX) can be deployed for defense in depth.

5. Side-Channel Attack on Circuit

Vector: Timing or power analysis reveals information about the private inputs to the circuit.

Mitigation:

• Cairo circuits execute in a deterministic step count regardless of input values (no branching on secrets).
• The circuit is a public program -- there are no secret instructions, only secret inputs.
• STARK proving is inherently resistant to timing attacks because the trace is computed entirely before the proof is generated.

Comparison with Other Proof of Humanity Systems

Worldcoin (World ID)

OpenPassport

Summary Comparison Matrix

Security Invariants

These invariants must hold at all times. Any violation is a critical security incident.

1. Nullifier determinism: For any given passport data P and domain separator D, generate_nullifier(hash(P), D) always returns the same value. There are no random or user-controlled inputs.

2. Nullifier uniqueness: The NullifierRegistry contract never allows the same nullifier to be registered twice. The register function reverts if the nullifier already exists.

3. Zero PII on-chain: No passport field content (name, DOB, nationality, document number, photo, biometric data) ever appears in any on-chain transaction, event, or storage slot.

4. SBT non-transferability: The HumanAttestationToken contract reverts on any transfer_from or safe_transfer_from call. Attestations cannot be moved between wallets except through the explicit migration mechanism.

5. TTL enforcement: is_verified_human returns false for expired attestations. There is no grace period.

6. CA trust chain: verify_and_attest reverts if the CA key hash is not in the trusted set or has been revoked.

7. Fee integrity: Queries (is_verified_human, get_scoped_pseudonym) are always free. Only verify_and_attest collects a fee.

8. Ephemeral data lifecycle: In the server prover path, passport data exists only in memory during proof generation and is zeroed immediately after. No PII is written to disk, logs, error reports, or any persistent storage.

This security model is a living document. It will be updated as the protocol matures and as new threats are identified. Security audit findings will be incorporated as they become available.