PALLAS Quantum State Security Key

Abstract

PALLAS is a hardware security key developed by Pilon Laboratories Inc. that provides post-quantum authentication, biometric identity binding, and encrypted mass storage in a single USB-C form factor. Unlike existing hardware keys that rely on classical elliptic-curve cryptography vulnerable to Shor's algorithm, PALLAS implements CRYSTALS-Dilithium5 (NIST FIPS 204, Level 5) as its primary signature algorithm, combined with on-device true quantum random number generation (QRNG) and biometric liveness detection to ensure that no quantum or classical adversary can forge, replay, or extract credentials.

PALLAS is available in Standard and Pay configurations across eight models. Pro models feature an IP67-rated sealed enclosure rated for water submersion to one metre for thirty minutes, suitable for demanding field, industrial, and outdoor environments. PALLAS Pay models add optional NFC contactless payment capability (ISO/IEC 14443-A/B), hardware-disabled whenever biometric authentication is not actively satisfied — enabling tap-to-pay at any Visa or Mastercard terminal with the same quantum-secure, privacy-preserving architecture that governs all other PALLAS functions.

This document describes the hardware architecture, cryptographic protocols, key lifecycle, threat model, and FIDO2/WebAuthn compliance posture of PALLAS Rev 1.0.

1 · The Quantum Threat

Shor's algorithm, running on a sufficiently large fault-tolerant quantum computer, can factor RSA moduli and solve the discrete logarithm problems underlying ECDSA and Ed25519 in polynomial time. Current estimates from NIST and CISA project that a cryptographically relevant quantum computer (CRQC) capable of breaking 2048-bit RSA may be available within 10–15 years. Nation-state adversaries are already collecting encrypted traffic today for decryption once a CRQC becomes available — a strategy known as harvest now, decrypt later.

Every existing hardware security key — including YubiKey 5, Google Titan, and Apple's Secure Enclave — relies on ECDSA P-256 or Ed25519 for FIDO2 assertions. These algorithms provide zero resistance to quantum adversaries. PALLAS was designed from the ground up to replace these algorithms with NIST-standardized post-quantum alternatives before the threat materializes.

2 · Hardware Architecture

PALLAS integrates four security-critical hardware components on a single PCB, each communicating over independent SPI buses managed by the main MCU. No sensitive data crosses component boundaries in plaintext.

2.1 Main MCU — NXP LPC55S69

The NXP LPC55S69 is an Arm Cortex-M33 microcontroller with hardware TrustZone isolation, a Physical Unclonable Function (PUF) for device-unique key derivation, and an on-chip HASHCRYPT accelerator supporting SHA-2, SHA-3, and AES. The MCU runs the FIDO2/CTAP2 protocol stack, manages USB HID enumeration, and coordinates all inter-component communication. The PUF generates a factory-derived device secret that seeds SE mutual authentication without ever being stored in flash.

2.2 Secure Element (SE) — SLE97

The SLE97 is a Common Criteria EAL 6+ certified secure element. All private key operations — generation, derivation, signing, and destruction — occur exclusively inside the SE. Private key material never crosses the SPI bus. The SE communicates via APDU frames over SPI; the main MCU acts as an APDU terminal and never has access to key material in RAM or flash.

PALLAS uses a two-phase mutual authentication protocol between the MCU and SE using HMAC-SHA3-256 and the PUF-derived factory key. Session keys are established fresh on every power cycle. After each signing operation, the derived key is cryptographically destroyed within the SE and destruction is verified by the MCU — if the verification fails, the device halts immediately.

2.3 Quantum Random Number Generator — IDQ6MC1

The ID Quantique IDQ6MC1 is a hardware quantum random number generator based on photon detection. It produces true random numbers sourced from quantum vacuum fluctuations — intrinsically unpredictable by any classical or quantum adversary. Every credential derivation operation seeds its IKM with 32 bytes of fresh QRNG entropy, ensuring that even an adversary who knows all other derivation inputs cannot reproduce the private key.

2.4 Biometric Sensor — Synaptics FS7600

The Synaptics FS7600 capacitive fingerprint sensor incorporates on-sensor liveness detection that distinguishes live tissue from spoofed prints, photographs, or gelatin replicas. Biometric templates are stored in encrypted flash and are never transmitted off-device. Every FIDO2 assertion and vault access requires a live fingerprint match; there is no PIN fallback that bypasses biometric verification.

3 · Cryptographic Stack

3.1 CRYSTALS-Dilithium (NIST FIPS 204)

CRYSTALS-Dilithium is a lattice-based digital signature scheme standardized by NIST in FIPS 204, now formally known as ML-DSA (Module-Lattice Digital Signature Algorithm). Its security rests on the hardness of the Module Learning With Errors (MLWE) and Module Short Integer Solution (MSIS) problems, both believed to be intractable for quantum computers. PALLAS targets Dilithium5 (NIST Level 5) for production — the highest security level available, equivalent to breaking AES-256. Hardware supports this with no modification; it is a firmware parameter selection.

3.2 Key Lifecycle — Derive-Then-Destroy

PALLAS uses an ephemeral derivation model: no private key is ever written to non-volatile storage. Keys exist only in SE RAM for the duration of a single signing operation, then are cryptographically destroyed and verified gone. FIDO2 compatibility requires that the same keypair can be reproduced for a given credential — PALLAS achieves this by storing the 32-byte QRNG entropy from registration (AES-256-GCM encrypted) alongside the credential, allowing identical IKM reconstruction at authentication time.

At credential registration (MakeCredential):

• QRNG generates 32 bytes of true quantum entropy (fresh, one-time)
• MCU assembles IKM: master_seed_id ‖ platform_id ‖ account_index ‖ QRNG(32B) ‖ biometric_hash
• SE derives a Dilithium5 keypair in SE RAM — public key returned, private key never leaves SE
• Public key is sent to the relying party (website) and registered
• The 32-byte QRNG value is stored encrypted in the credential record in flash
• Private key is destroyed in SE RAM; destruction is verified by MCU

At authentication (GetAssertion):

• Credential record is retrieved; stored QRNG bytes are decrypted from flash
• MCU reconstructs the identical IKM using the same inputs
• SE re-derives the identical keypair — producing the same public key the website registered
• SE signs the authentication challenge; signature is returned to host
• Private key is destroyed and verified gone — key exists in SE RAM for milliseconds only

This design ensures FIDO2 interoperability (reproducible public key) while maintaining the post-quantum security guarantee: the private key never persists anywhere, and the QRNG component makes each credential's keypair unique to that specific registration event on that specific device.

3.3 Vault Encryption — AES-256-GCM

The encrypted storage vault uses AES-256-GCM, with encryption and decryption performed entirely inside the SLE97. The vault key is derived from the master seed via HKDF-SHA3-512 with a vault-specific info string and loaded into SE RAM slot 0x11 for the duration of the vault session. A vault session requires a live biometric match before the key is loaded; the key is destroyed from SE RAM when the vault is locked.

Each stored item is encrypted with a unique 96-bit random IV generated by the QRNG. The GCM authentication tag provides ciphertext integrity — any tampering with flash contents is detected before decryption is attempted.

4 · FIDO2 / WebAuthn Compliance

PALLAS implements the FIDO2 Client-to-Authenticator Protocol 2 (CTAP2) over USB HID using the FIDO Alliance CTAPHID transport layer. The device enumerates as a standard HID device (VID: 0x1209, PID: 0x5353) and requires no drivers on any supported operating system.

PALLAS advertises the pqc extension in its authenticatorGetInfo response. Relying parties that support COSE algorithm -6 (Dilithium5) will receive a post-quantum public key in the attestation. Relying parties that do not yet support PQC will receive a standard FIDO2 registration flow and can upgrade when their backend is ready.

5 · Threat Model

The table below compares known real-world attack vectors against current market hardware security devices with PALLAS's specific mitigations. Each row identifies how existing products are compromised and why PALLAS is immune.

6 · Full Specifications

6.1 · Product Variants — Standard vs. PALLAS Pay

PALLAS is offered across eight models in two hardware variants — Standard and Pay. All cryptographic capabilities, biometric liveness detection, QRNG, secure element, and vault functions are identical across all models. The only hardware difference between variants is the presence of an NFC module in the Pay models. NFC is available from the 512GB tier upward; the 128GB and 256GB Standard models are NFC-free by design, targeting enterprise and government buyers where policy or preference requires zero wireless attack surface.

The Standard variant is the recommended choice for government procurement, enterprise IT, and security professionals operating in environments where NFC transmission may be prohibited by policy or presents an unacceptable additional attack surface. The absence of an NFC module provides a hardware-level guarantee — not a software toggle — that no contactless transmission is possible.

6.2 · NFC Payment Architecture — PALLAS Pay

The PALLAS Pay variant includes an NFC module conforming to ISO/IEC 14443-A/B and ISO/IEC 18092, enabling contactless payment at any NFC-enabled terminal worldwide. The PALLAS companion app allows users to load credit cards, debit cards, and their XInfinitum Card into the device's encrypted vault. All card credentials are stored as tokenized representations inside the SLE97 secure element — the raw card number never touches the host device or any external storage.

Payment is authorized exclusively by the biometric fingerprint sensor. The NFC module is hardware-disabled when the biometric gate is not actively satisfied — there is no passive tap, no background transmission, and no relay possible without a live, authenticated fingerprint present at the moment of transaction. This neutralizes the primary NFC relay attack vector that affects all standard contactless payment cards.

6.3 · PALLAS Pay — Card Setup & Active Card Selection

Card management and NFC payment require a USB-C connection to the PALLAS companion app. There is no wireless provisioning pathway — card credentials are loaded exclusively via the physical USB-C interface, eliminating any over-the-air interception surface during setup.

The active card selection model is deliberately singular: one card is designated active at a time, written to the secure element. This is a security property, not a limitation — it prevents ambiguous charge routing and ensures the user makes a conscious, deliberate selection before any payment can occur. To switch the active card, the user reconnects via USB-C and selects a different card in the PALLAS app. The NFC module cannot fire for any card other than the currently designated active card.

6.4 · PALLAS Pay vs. Apple Pay / Google Pay — Security Comparison

Apple Pay and Google Pay are well-engineered payment systems that provide strong security for most consumers. PALLAS Pay is not positioned as a replacement for those systems — it is positioned as a higher-assurance alternative for users who require hardware-level guarantees rather than software-level ones, and for users who do not wish to link payment behaviour to a cloud account.

6.5 · Battery & Power Architecture

The PALLAS Pay variant incorporates a sealed lithium polymer (LiPo) cell — approximately 40 mAh — housed within the aluminium enclosure. This cell powers the biometric sensor, microcontroller, and NFC gating logic independently of any host device. The NFC module itself harvests power from the terminal's RF field during a transaction; however, the biometric authentication processor and the SLE97 secure element gating logic require independent power to authorize the NFC window prior to terminal contact.

The battery charges automatically and passively whenever the device is connected via USB-C for any purpose — FIDO2 authentication events, vault access, card loading, card switching, firmware updates, or simply plugging in at a desk. Users who connect the device periodically for any management task maintain a near-full charge without any dedicated charging behaviour. The USB-C port, already required for card management, serves as the sole charging interface — no additional cable, dock, or wireless pad is needed.

6.6 · Operational Modes — Plugged vs. Standalone

PALLAS Pay operates in one of two mutually exclusive modes determined by USB-C connection state. This physical mode separation is a deliberate security architecture decision — not a software toggle.

When unplugged, the firmware interprets a valid biometric touch as a payment intent — unambiguously. There is no host to communicate with and no vault to access, so the only meaningful action is a payment. This eliminates an entire class of accidental-trigger and social-engineering scenarios: an attacker who has the device while it is plugged in cannot trigger an NFC payment, and an attacker who has the device while unplugged cannot access the vault, load fraudulent card credentials, or push unauthorized firmware.

6.7 · NFC Biometric Gate — Hardware Security Guarantees

The NFC module is controlled by a hardware enable line driven directly by the SLE97 secure element. No software running on the host, MCU application layer, or any external process can assert this line without a valid hardware confirmation from the SE. There is no API, debug interface, or firmware command that bypasses this gate.

The gate sequence on each payment attempt is as follows:

6.8 · Duress Fingerprint & Emergency SOS Protocol

PALLAS supports a duress fingerprint — a designated finger enrolled in the SLE97 with a DURESS flag, separate from the user's standard access fingers. This feature is designed for scenarios where a user is compelled under threat or coercion to authenticate with their device. To an observer the device behaves identically — no indicator reveals that a duress template exists or has been triggered.

Setup: During enrollment, the user may optionally designate one finger (e.g., right pinky) as the duress finger. The duress template is stored in the SE with a flag distinguishing it from access templates. Standard access fingers and the duress finger cannot be the same digit.

Trigger behavior — device must be plugged into the PALLAS companion app on a smartphone:

Why USB-C connection is required for the full protocol: Alert transmission requires access to the phone's GPS, cellular data, and messaging stack — all available only when the PALLAS app has an active connection. The device-lock component of the duress protocol does function in standalone mode (fingerprint match against DURESS template → immediate lockout), but the silent alert and location transmission require the phone to be connected.

Optional decoy vault: Users may configure a secondary decoy vault, accessible only under the duress finger, containing limited or sanitized data. This provides the appearance of cooperation while the emergency alert transmits silently in the background.

7 · Standards & Compliance

• NIST FIPS 204 — ML-DSA (CRYSTALS-Dilithium) — primary signature algorithm, Level 5 production target
• NIST FIPS 203 — ML-KEM (CRYSTALS-Kyber) — planned for device-to-device key encapsulation and XInfinitum protocol node encryption
• FIDO Alliance CTAP 2.1 — Client-to-Authenticator Protocol
• W3C WebAuthn Level 3 — Web Authentication API
• RFC 5869 — HKDF key derivation
• FIDO HID Transport — CTAPHID v1.0
• Common Criteria EAL 6+ — SLE97 Secure Element (Infineon)
• ISO/IEC 7816 — Smart card APDU framing (SPI adaptation)
• NIST SP 800-90B — Entropy assessment methodology (QRNG)
• IP67 — Ingress protection (Pro model enclosure)

8 · XInfinitum — One-Time Key Blockchain Architecture

PALLAS supports a second operational mode beyond FIDO2: serving as the hardware signing terminal for the XInfinitum blockchain protocol. This mode exploits PALLAS's unique hardware capabilities to implement an architectural property no existing blockchain possesses — genuinely unique, quantum-seeded, hardware-destroyed private keys for every single transaction.

8.1 Why One-Time Keys?

Every major blockchain today — Bitcoin, Ethereum, Solana — assigns users one keypair. Every transaction is signed by the same private key. This creates several compounding risks:

• Key reuse attacks: Multiple signatures from the same key allow statistical analysis. In classical cryptography this is mitigated; in lattice schemes, key reuse is explicitly discouraged.
• Harvest-for-later: An adversary collecting signed transactions today can forge new transactions once quantum computing matures, if the keypair persists.
• Single point of failure: Compromise of one keypair compromises the entire transaction history and future access.

8.2 The PALLAS One-Time Key Scheme

For each blockchain transaction, PALLAS executes the following protocol — no private key is ever the same twice:

• QRNG generates 32 bytes of fresh quantum entropy — never stored, never reproducible
• SE derives a Dilithium5 keypair: HKDF-SHA3-512(master_seed ‖ QRNG_32B) — entirely in SE RAM
• SE signs the transaction payload; signature and one-time public key are returned
• SE destroys the keypair in RAM; MCU verifies destruction
• Transaction broadcast contains: {account_commitment, recipient, amount, nonce, one_time_pubkey, signature}

The account_commitment is a SHA3-256 hash of the master seed — a stable, public account identifier that cannot be reversed to reveal the seed. Validators confirm: (1) the signature is valid against the included one-time public key, and (2) the account commitment matches the signing device's registered identity. Balance is maintained by the network as a function of all valid transactions committed to that account hash.

8.3 Security Properties

9 · Perfect Forward Secrecy

What Is Perfect Forward Secrecy?

Perfect Forward Secrecy (PFS) is a guarantee about the past. It answers one of the most important questions in all of security: "If something is compromised in the future, can the damage reach backward through my history?"

In plain terms: imagine every door you have ever unlocked used the same key. If someone steals that key today, they can open every door you ever touched — going back years. This is how most digital security works, and it is a structural flaw that affects banks, messaging apps, hardware wallets, blockchains, and authentication systems worldwide.

Perfect Forward Secrecy removes this flaw entirely. Instead of one persistent key protecting everything, the system generates a different, unique, temporary key for every single interaction. Each key is used once, then permanently destroyed. If an adversary compromises something today, all they touch is today. Every prior session is forever locked behind keys that no longer exist — not hidden, not encrypted, but physically, mathematically gone from the universe.

Why PFS Is Rare — And Why It Matters Now

Most systems do not implement PFS because it requires generating, using, and destroying a fresh cryptographic key for every operation. This demands significant engineering discipline and hardware investment. Traditional systems take the shortcut of reusing long-lived keys, accepting the assumption that those keys will never be compromised. That assumption is increasingly dangerous.

Nation-state intelligence agencies are already conducting harvest now, decrypt later attacks — recording encrypted data today, archiving it, and waiting until quantum computers become powerful enough to break the classical cryptography (ECDSA, RSA, elliptic curve) that protects it. Every message, transaction, and authentication token protected by classical cryptography is potentially sitting in an adversary's archive right now. When a sufficiently powerful quantum computer arrives, that archive becomes fully readable retroactively.

For blockchains, this means every transaction ever signed on Bitcoin or Ethereum could be exposed — wallet balances revealed, pseudonymous identities linked, entire financial histories deanonymized. For authentication systems, it means credentials signed today could be forged later. The threat is not theoretical; the data collection is already happening.

Three Requirements for True Perfect Forward Secrecy

PFS requires all three of the following properties to hold simultaneously. Any single missing element breaks the guarantee:

• Ephemeral key generation: A fresh, unique cryptographic key pair must be generated for every session or transaction. Keys derived from the same source, or reused in any form, allow sessions to be linked and potentially compromised together.
• Verified hardware destruction: The ephemeral private key must be permanently and verifiably destroyed immediately after use. Software deletion is insufficient — operating systems can page keys to disk, memory dumps can capture them, and compromised runtimes can log them before deletion. Hardware-level zeroization confirmed by an independent processor is required.
• No derivability from persistent state: The session key must not be reconstructable from any data that persists after the session ends. If any stored value could allow an adversary to recompute the key, PFS is broken regardless of whether the key itself was deleted.

How PALLAS Achieves Perfect Forward Secrecy

PALLAS is designed from genesis to satisfy all three requirements simultaneously — and to do so at a higher assurance level than any software-only implementation can claim.

What This Means for You — In Plain Language

Every time you use PALLAS — to log in to a website, authorize a transaction, access your vault, or pay at an NFC terminal — a new quantum-derived key is born inside the chip, performs exactly one purpose, and is immediately erased from existence. The next use generates a completely different key. So does every use after that.

The practical meaning: if your PALLAS device is lost, stolen, or forensically analyzed at any point in the future, an adversary gains the ability to authorize actions from that moment forward only — and even that requires your live fingerprint. Everything you authenticated in the past remains permanently sealed behind keys that are gone from the physical world.

There is no archive to subpoena. No database to breach. No record that can be quantum-decrypted. The past is protected not by encryption — but by the most absolute security mechanism possible: the keys that protected it do not exist.

PFS Scope Across the PALLAS Device

XInfinitum — Blockchain-Native Post-Quantum Forward Secrecy for Signing Authority

On a public blockchain where all transaction data is visible by design, the relevant forward secrecy property is not confidentiality of transaction content — it is forward secrecy of signing authority: the mathematical impossibility of reconstructing the private key used to authorize any past transaction. XInfinitum's architecture is designed to provide this property at the individual transaction level, extending PALLAS's hardware PFS guarantee into the blockchain layer.

References

1. NIST. FIPS 204: Module-Lattice-Based Digital Signature Standard. National Institute of Standards and Technology.
2. FIDO Alliance. FIDO Client to Authenticator Protocol (CTAP) 2.1. 2023.
3. W3C. Web Authentication: An API for accessing Public Key Credentials Level 3. 2023.
4. Krawczyk, H. & Eronen, P. RFC 5869: HMAC-based Extract-and-Expand Key Derivation Function (HKDF). 2010.
5. Shor, P.W. Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer. SIAM J. Comput., 1997.
6. CISA / NSA / NIST. Quantum-Readiness: Migration to Post-Quantum Cryptography. August 2023.
7. NXP Semiconductors. LPC55S6x Data Sheet. Rev. 4, 2022.
8. Infineon Technologies. SLE 97 Family Security Controller. 2021.
9. ID Quantique. IDQ6MC1 Quantum Random Number Generator — Product Brief. 2023.
10. Synaptics. FS7600 Fingerprint Sensor. 2022.

© 2026 Pilon Laboratories Inc. All rights reserved. Patent Pending.
This document may be distributed freely for informational and investor purposes.
Inquiries: derek@pilonlaboratories.com