# Lokblok — Full Markdown Corpus This file is the concatenation of every Markdown mirror published at https://www.lokblok.co/. Each section corresponds to one page; sections are separated by a horizontal rule. The canonical per-page mirror is also available at `https://www.lokblok.co.md` (or `/index.md` for the home page). # Lokblok™ — Zero-Custody Cryptographic Infrastructure > Lokblok eliminates the root cause of most cryptographic breaches by removing stored private keys from the architecture entirely. Keys are reconstructed from threshold shares inside certified hardware only when identity, policy, and context conditions are simultaneously satisfied — used once, then destroyed. There is no key to steal because there is no stored key. ## What Lokblok Builds Lokblok is an enterprise cryptographic security company. Our products are deployed by financial institutions, digital asset custodians, governments, critical infrastructure operators, and telecoms. The technology is based on threshold cryptography (multi-party computation), hardware security modules (HSMs), and ephemeral key lifecycle management. ## The Core Concept: Zero Standing Secrets (ZSS) Traditional security protects stored keys. Lokblok removes them. The Phantom Secrets™ protocol reconstructs private keys from distributed shares inside certified hardware only when all required conditions are met. The key is used, then destroyed. No key persists anywhere at any time. This is not key rotation. It is key elimination. The attack surface disappears because the target disappears. ## Product Lines - **Phantom Secrets™** — the core zero-custody key protocol - **PhantomGate™** — zero-persistence authentication gateway - **Secure Terminal** — zero-trust execution environment - **ToughID** — cryptographic identity attestation without stored personal data - **Toughkey** — Lokblok's certified hardware security module ## Who We Serve Digital asset custody, banking and finance, payments, data sovereignty, critical infrastructure, digital identity, digital inheritance, enterprise security, HSM providers, telecoms, and security service providers. ## Related - Architecture: /api/md/architecture - Products index: /api/md/products/phantom-secrets - Solutions index: /api/md/solutions/digital-asset-custody - Contact: /api/md/contact --- # Phantom Secrets™ > The core zero-custody key protocol. Private keys are never stored. They are reconstructed on demand from threshold shares inside a hardware security module (HSM or secure element), used for a single cryptographic operation, then destroyed. ## What It Is Phantom Secrets™ is the cryptographic protocol that implements Zero Standing Secrets (ZSS) — the architectural principle that no private key exists at rest at any point in time. It composes threshold cryptography, hardware-bound reconstruction, a policy engine, and an ephemeral key lifecycle into a single deployable runtime. ## How It Works 1. The private key is split into N threshold shares; M of N are required to reconstruct it. 2. When a cryptographic operation is requested, the policy engine checks identity, context, and quorum conditions. 3. If satisfied, the shares are combined inside a certified HSM or secure element. The reconstructed key never crosses the hardware boundary. 4. The key performs a single cryptographic operation (sign, decrypt, authenticate). 5. The key is destroyed before the hardware boundary is exited. No persistence. ## Compatibility Compatible with any key type — ECC, RSA, AES, Bitcoin secp256k1, Ethereum, Ed25519, and others — and algorithm-agile so post-quantum primitives can be substituted without redesign. Drops into existing wallet, custody, and HSM workflows without a full architectural rebuild. ## Key Properties - No stored private key, anywhere, ever - Reconstruction is conditional on identity + policy + context - Reconstruction occurs only inside certified hardware - Single-operation lifecycle with immediate destruction - No escrow, no recovery key, no administrative override ## Related - Architecture: /api/md/architecture - Toughkey HSM: /api/md/products/toughkey - Quantum resistance: /api/md/features/quantum-resistance - Zero stored private keys: /api/md/features/private-keys --- # PhantomGate™ > Zero-persistence authentication gateway. Session authentication keys are created inside the Toughkey secure element, used for mutual authentication, then immediately destroyed. No credential exists before or after a session. ## What It Solves Conventional authentication systems store long-lived credentials — passwords, API tokens, session keys, certificate private keys. Each is a target. PhantomGate eliminates the credential by generating it inside hardware only at the moment of authentication and destroying it the moment the session is established. ## How It Works 1. A session authentication request reaches the gateway. 2. PhantomGate triggers the Phantom Secrets™ runtime inside the Toughkey secure element. 3. A session authentication key is reconstructed from threshold shares, mutual authentication is performed, and the session is established. 4. The session authentication key is destroyed inside the secure element. 5. From the perspective of any attacker, the credential never existed. ## Use Cases - Privileged-access authentication for administrators and operators - Machine-to-machine authentication in zero-trust networks - Authentication for payment, custody, and signing operations - Replacement for stored API keys and long-lived bearer tokens ## Related - Phantom Secrets™: /api/md/products/phantom-secrets - Toughkey: /api/md/products/toughkey - Enterprise Security solution: /api/md/solutions/enterprise-security --- # Secure Terminal > A zero-trust execution environment. Hardware-enforced access control, whitelisted application environment, zero-trust networking, encrypted distributed storage, and Phantom Secrets™ key integration. Every element is verified before anything executes. ## What It Is A hardened endpoint and execution environment for high-assurance operations: signing, custody, identity issuance, OT/SCADA control, and other workflows where the conventional desktop or server is too permissive a runtime. ## What's Hardware-Enforced - **Access control** — only attested users on attested hardware can boot or interact - **Application environment** — only whitelisted, signed binaries may execute - **Networking** — zero-trust, identity-bound, mutually authenticated by default - **Storage** — encrypted, distributed, tamper-evident - **Cryptographic operations** — bound to Phantom Secrets™; private keys never exist on the terminal at rest ## Where It Deploys Custody operations rooms, regulated trading desks, treasury workstations, government secure facilities, defence and critical-infrastructure operator stations, and any environment where a single-host compromise would be catastrophic. ## Related - Phantom Secrets™: /api/md/products/phantom-secrets - PhantomGate™: /api/md/products/phantom-gate - Critical Infrastructure solution: /api/md/solutions/critical-infrastructure --- # ToughID > Cryptographic identity attestation without stored personal data. Identity is verified once by a trusted provider, resulting in a signed cryptographic token bound to a public key. Systems verify the signature, not the underlying data. No personal data database. No honeypot. ## The Identity Honeypot Problem Most identity systems centralise personal data so that relying parties can verify it. The result is a database that becomes a permanent target. Breach of one identity provider exposes millions of identities. ## How ToughID Works 1. A trusted issuer verifies an identity once — KYC, eIDAS, EUDI, or equivalent. 2. The issuer produces a signed cryptographic token bound to a public key controlled by the user. 3. Relying parties verify the signature against the issuer's public key. They never receive the underlying personal data. 4. Selective disclosure: the user can prove specific attributes (age over 18, jurisdiction of residence, regulatory status) without revealing the full identity record. ## Properties - No central database of personal data - Compatible with EUDI and eIDAS frameworks - Selective disclosure as a first-class operation - Phantom Secrets™ integration for the user's signing key — the key proves identity without ever existing at rest ## Related - Digital Identity solution: /api/md/solutions/digital-identity - Phantom Secrets™: /api/md/products/phantom-secrets --- # Toughkey > Lokblok's certified hardware security module (HSM). A tamper-resistant secure element that hosts the Phantom Secrets™ runtime. The same Lokblok protocol also runs inside SIM cards, eUICC, mobile secure enclaves, and qualified cloud HSMs. ## What It Is Toughkey is a certified secure element designed specifically to host the Phantom Secrets™ runtime. It provides the tamper-resistant boundary inside which threshold shares are combined into a private key, used for a single cryptographic operation, and destroyed. ## Form Factors - Standalone HSM appliance for data centre and on-premises deployment - USB-connected secure element for endpoint and operator scenarios - Embedded module for OEM integration into terminals, gateways, and ATMs - Software runtime targeting partner HSMs, secure elements, SIM/eUICC, and qualified cloud HSMs ## Certifications Designed to meet the certification expectations of regulated buyers (FIPS 140-3, Common Criteria, eIDAS, MiCA-relevant). Specific current certifications and roadmap are available under NDA. ## Related - Phantom Secrets™: /api/md/products/phantom-secrets - HSM Providers solution: /api/md/solutions/hsm-providers - Architecture: /api/md/architecture --- # Zero Stored Private Keys > The private key is the root cause of every key-based breach. Phantom Secrets™ eliminates the stored key entirely. No key at rest means no key to steal. ## The Insight Every catastrophic key loss — from custody failures to ransomware to insider theft to lawful-access compulsion — depends on the same thing: a private key existed somewhere durable. Encryption at rest, HSMs, multi-sig, and key rotation all assume the key must continue to exist. Phantom Secrets™ removes that assumption. ## What "Zero Stored" Means - The key does not exist on disk, in memory, in a database, in an HSM file system, or in any backup. - Threshold shares exist, but no single share — and no possessable subset short of the threshold — reveals the key. - Reconstruction occurs only inside certified hardware, only when policy is satisfied, and the key is destroyed before the hardware boundary is exited. ## Consequences - Theft requires reconstruction inside hardware you control under conditions you set - Lawful-access compulsion has nothing to compel — the operator cannot produce the key - Insider risk collapses: even a fully privileged operator cannot extract the key - Backup and recovery become public-data operations ## Related - Architecture: /api/md/architecture - Phantom Secrets™: /api/md/products/phantom-secrets --- # Hierarchical Signatures > Multi-party approval workflows enforced cryptographically. Approval hierarchies (CFO must sign, quorum of board members required) are encoded in policy and enforced by mathematics, not procedure. ## The Problem with Procedural Approval Conventional multi-party approval relies on procedural enforcement — a workflow tool, a checklist, a four-eyes process. It can be bypassed by anyone with sufficient privilege, social-engineered, or ignored under operational pressure. ## The Cryptographic Solution Phantom Secrets™ encodes the approval policy directly into the threshold reconstruction conditions. The signing key cannot be reconstructed unless the required parties have produced the required signatures, in the required order, within the required context. The approval is not a control on the key — it is a precondition for the key to exist. ## Example Policies - Treasury transfers above a threshold require CFO + COO co-signature - Production deployment requires quorum of 3 of 5 SREs plus security team approval - Board-level decisions require quorum of board members within a defined window - Custody transfers require client approval, compliance approval, and operations approval ## Properties - Approval workflows are tamper-evident by construction - Bypass is mathematically impossible, not procedurally discouraged - Audit evidence is cryptographic, not log-based ## Related - Phantom Secrets™: /api/md/products/phantom-secrets - Banking and Finance solution: /api/md/solutions/banking-finance - Enterprise Security solution: /api/md/solutions/enterprise-security --- # Transfer on Death > Cryptographic estate planning. Digital assets transfer to designated beneficiaries only when death or incapacity is cryptographically attested by authorised parties. No probate. No custodian dependency. ## The Inheritance Problem Self-custodied digital assets famously die with their owner. Custodial inheritance depends on a custodian's continued existence, solvency, and willingness to act. Neither model provides predictable, dignified, or jurisdictionally enforceable inheritance. ## How Phantom Secrets™ Solves It The owner defines a policy that authorises beneficiary access only upon cryptographic attestation of death or incapacity by named parties (medical authority, legal authority, family members, or any combination). The asset's controlling key cannot be reconstructed for beneficiaries until that attestation is produced and verified. Once produced, the asset transfers atomically and the original owner's reconstruction capability is revoked. ## Use Cases - Personal estate planning for digital asset holders - Trust structures for family wealth involving cryptographic assets - Continuity planning for businesses dependent on a single signer - Sovereign and institutional inheritance frameworks ## Related - Digital Inheritance solution: /api/md/solutions/digital-inheritance - Phantom Secrets™: /api/md/products/phantom-secrets --- # Transfer on Sale > Atomic, trustless digital asset transfer. A private key is reconstructed and transferred to a buyer only when all transaction conditions are cryptographically verified: payment confirmed, regulatory sign-off received, counterparty approved. No escrow agent required. ## The Problem Trading or transferring custody of a digital asset that is controlled by a private key historically requires a trusted intermediary — an escrow agent, a custodian, a clearing house — to ensure the key is only handed over once payment and conditions are met. ## How Phantom Secrets™ Solves It The transfer policy is encoded as preconditions for reconstruction of the key (or for re-keying to the buyer's new key material). Until every precondition is cryptographically satisfied — payment on-chain, sanctions check passed, regulatory approval signed — the key cannot exist for either party. When all conditions are met, the key materialises for the buyer and the seller's ability to reconstruct is permanently revoked. ## Use Cases - OTC digital asset settlement - Tokenised securities transfer - Inter-custodian transfers - M&A involving digital assets, signing keys, or cryptographic IP ## Related - Digital Asset Custody solution: /api/md/solutions/digital-asset-custody - Phantom Secrets™: /api/md/products/phantom-secrets --- # Quantum Resistance > Algorithm-agile architecture. Because Phantom Secrets™ never stores keys, harvest-now-decrypt-later attacks find nothing to harvest. The cryptographic layer is algorithm-agnostic and can be upgraded from ECDH to post-quantum algorithms (NTRU, SABER, CRYSTALS-Kyber) without architectural redesign. ## Two Defences, Not One Lokblok provides two independent defences against quantum-era attacks: 1. **Nothing to harvest.** Harvest-now-decrypt-later attacks assume the attacker can capture today's encrypted material and decrypt it once quantum hardware is available. Phantom Secrets™ stores no private keys, so an adversary capturing every byte of every Lokblok-protected system today still has nothing to decrypt tomorrow. 2. **Algorithm agility.** When a primitive needs to be replaced (ECDH to a post-quantum KEM, ECDSA to a post-quantum signature scheme), the substitution happens at the cryptographic layer of the protocol. The threshold structure, hardware boundary, policy engine, and lifecycle do not change. There is no architectural rebuild. ## Practical Implication Lokblok customers do not need to choose between deploying today and being post-quantum-ready. They deploy today and the post-quantum upgrade path is built in. ## Related - Architecture: /api/md/architecture - Phantom Secrets™: /api/md/products/phantom-secrets --- # Digital Asset Custody > Zero-custody infrastructure for institutional digital asset custodians. No stored private keys means no key theft, no insider risk, no legal-compulsion attack surface, and MiCA alignment. ## What Changes for a Custodian - **No stored signing keys.** The wallet keys controlling client assets do not exist at rest. Reconstruction is policy-bound and hardware-enforced. - **Insider risk collapses.** Even a fully privileged operator cannot extract a key. - **Lawful-access compulsion has no target.** The custodian cannot produce a key it does not possess. - **Audit becomes cryptographic.** Every reconstruction event is provable from public material. - **MiCA alignment.** Segregation, governance, and operational-risk requirements map cleanly onto the policy engine. ## Integration Compatible with major custody platforms, exchanges, and wallet infrastructures. Phantom Secrets™ replaces the signing-key layer without rebuilding the surrounding system. ## Related - Phantom Secrets™: /api/md/products/phantom-secrets - Hierarchical Signatures: /api/md/features/hierarchical-signatures - Transfer on Sale: /api/md/features/transfer-on-sale - Banking and Finance: /api/md/solutions/banking-finance --- # Banking and Finance > Zero Standing Secrets for regulated financial institutions. Eliminates key management risk, enables hardware-enforced multi-party approval, satisfies audit requirements cryptographically. ## What It Replaces - Long-lived signing keys for payments, settlements, and treasury operations - Procedural multi-party approval for high-value transactions - Periodic key ceremonies and rotation work - Audit trails based on log files rather than cryptographic evidence ## What It Enables - Hardware-enforced quorum approval for every regulated operation - Cryptographic audit evidence acceptable to financial regulators - Reduced operational risk and lower insurance exposure - Sovereign deployment in jurisdictions with data-localisation requirements ## Related - Hierarchical Signatures: /api/md/features/hierarchical-signatures - Payments solution: /api/md/solutions/payments - Enterprise Security solution: /api/md/solutions/enterprise-security --- # Payments > Phantom Secrets™ for payment infrastructure. No stored credentials, policy-bound transaction execution, and cryptographic auditability for every payment event. ## Where It Fits - Card-present and card-not-present transaction signing - Inter-bank settlement and instant-payment scheme participation - Stablecoin and tokenised-payment issuance and redemption - Merchant acquiring and PSP key management ## What Changes Stored merchant keys, terminal keys, and scheme keys are replaced by ephemeral keys reconstructed only at the moment of authorisation, only inside certified hardware, only when policy is satisfied. The credential becomes uncopyable because it does not persist. ## Related - Phantom Secrets™: /api/md/products/phantom-secrets - PhantomGate™: /api/md/products/phantom-gate - Banking and Finance: /api/md/solutions/banking-finance --- # Data Sovereignty > Sovereignty enforced at the key layer, not the contractual layer. Providers cannot access, reconstruct, or disclose keys they do not hold. Sovereignty becomes technical, not dependent on trust. ## The Contractual Sovereignty Problem Most "sovereign cloud" or "data residency" arrangements are contractual: the provider promises not to access data, and may be legally able to access it nonetheless under foreign jurisdiction. The data subject's protection depends on trusting the provider and the provider's home jurisdiction. ## Technical Sovereignty With Phantom Secrets™ the keys controlling sovereign data do not exist for the provider to disclose. Threshold shares are held by parties under the data subject's jurisdiction. The provider operates the infrastructure but cannot reconstruct the keys, and cannot be lawfully compelled to disclose what it does not possess. ## Use Cases - Government and public-sector data hosted on commercial cloud - Cross-border financial data subject to multiple jurisdictions - Healthcare and biometric data subject to strict residency rules - Sovereign AI training data and model weights ## Related - Critical Infrastructure: /api/md/solutions/critical-infrastructure - Enterprise Security: /api/md/solutions/enterprise-security - Architecture: /api/md/architecture --- # Critical Infrastructure > No persistent credentials in operational technology (OT), SCADA, energy, water, and defence systems. Attackers cannot steal credentials that do not exist. ## Why OT Is the Worst Place for Stored Credentials OT environments combine long-lived hardware, infrequent patching, high blast radius, and growing IT/OT convergence. Stored operator and machine credentials in this environment are uniquely valuable to attackers and uniquely difficult to rotate. ## What Phantom Secrets™ Changes Operator authentication, machine-to-machine authentication, and command signing all become ephemeral. The credential is reconstructed inside a secure element only at the moment it is needed, only when policy is satisfied. There is no persistent credential to harvest, replay, or compromise. ## Use Cases - Energy generation, transmission, and distribution control - Water treatment and distribution control - Transport and rail signalling - Defence command-and-control - Industrial control systems and SCADA networks ## Related - Secure Terminal: /api/md/products/secure-terminal - PhantomGate™: /api/md/products/phantom-gate - Enterprise Security: /api/md/solutions/enterprise-security --- # Digital Identity > Privacy-preserving, EUDI-aligned digital identity. Phantom Secrets™ enables selective disclosure: systems verify what they need to know without receiving raw personal data. ## How It Works Identity is verified once by an authorised issuer (eIDAS, EUDI, KYC provider, or equivalent). The result is a cryptographic credential bound to a key that the user controls — a key that, with Phantom Secrets™, never exists at rest. Relying parties verify the credential's signature, not the underlying data, and the user can selectively disclose only the attributes a particular relying party requires. ## Properties - No central database of personal data to breach - Selective disclosure is a first-class operation, not a bolt-on - The user's signing key is ephemeral and unstealable - Compatible with EUDI, eIDAS, and major identity wallet frameworks ## Related - ToughID: /api/md/products/toughid - Phantom Secrets™: /api/md/products/phantom-secrets - Data Sovereignty: /api/md/solutions/data-sovereignty --- # Digital Inheritance > Legally structured, cryptographically enforced inheritance of digital assets, accounts, and intellectual property. ## What It Solves Self-custodied digital assets typically die with their owner. Custodial inheritance depends on a custodian's continued existence and willingness to act. Lokblok provides a third path: inheritance that is enforced cryptographically by the same protocol that holds the asset, with legal structure layered on top. ## How It Works The owner defines beneficiaries and the attestation conditions under which they may inherit (death certificate, court order, trustee attestation, multi-party family quorum). Until those conditions are cryptographically satisfied, beneficiaries cannot reconstruct the controlling keys. Once satisfied, transfer is atomic and the original owner's reconstruction capability is permanently revoked. ## Use Cases - Personal estate planning for digital asset holders - Family-office and trust structures - Continuity for businesses dependent on a single signer - Sovereign inheritance frameworks ## Related - Transfer on Death feature: /api/md/features/transfer-on-death - Phantom Secrets™: /api/md/products/phantom-secrets --- # Enterprise Security > Zero-trust cryptographic security for enterprises. Eliminate standing credentials, enforce cryptographic governance, audit every privileged action. ## Where Standing Credentials Live in Most Enterprises - Privileged-access service accounts and SSH keys - API keys for production systems and third-party services - Long-lived certificate private keys for code signing and TLS termination - Database root credentials and backup keys - Master keys for secrets-management systems Each is a target. Each compromise has historically caused major breaches. ## What Phantom Secrets™ Replaces Every standing credential becomes an ephemeral, policy-bound, hardware-reconstructed key. The credential exists for the duration of the operation that needs it and is destroyed afterwards. No credential vault to breach, no key to rotate, no leaked-token incident. ## Related - PhantomGate™: /api/md/products/phantom-gate - Hierarchical Signatures: /api/md/features/hierarchical-signatures - Critical Infrastructure: /api/md/solutions/critical-infrastructure --- # HSM Providers > Lokblok partners with HSM manufacturers to add zero-storage capabilities beyond FIPS 140-3 certification. Phantom Secrets™ as an HSM software layer. ## What Lokblok Adds to an HSM A FIPS 140-3 certified HSM protects keys that exist inside it. Phantom Secrets™ adds the option that the keys do not exist inside it — they are reconstructed from threshold shares only at the moment of use and destroyed immediately after. Customers gain zero-custody behaviour without abandoning their HSM investment. ## Partnership Model Lokblok provides the Phantom Secrets™ runtime as a software layer that targets the HSM's secure execution environment. The HSM vendor retains its certification, brand, and customer relationship; Lokblok contributes the protocol and roadmap. Joint go-to-market is structured around the vendor's existing channels. ## Related - Toughkey: /api/md/products/toughkey - Phantom Secrets™: /api/md/products/phantom-secrets - Architecture: /api/md/architecture --- # Telecoms > Deploy Phantom Secrets™ inside SIM, eUICC, and telecom-controlled hardware to deliver global ephemeral identity and authentication infrastructure. ## What Telecom-Controlled Secure Hardware Enables The SIM and eUICC are the largest deployed base of certified secure elements in the world, already in operator-controlled distribution channels. Phantom Secrets™ executing inside this hardware turns every subscriber device into a zero-custody cryptographic endpoint. ## Use Cases - Mobile-first authentication for banking, government, and enterprise - Sovereign digital identity tied to a regulated telecom operator - Machine identity for IoT and connected vehicles, with no stored credentials on the device - Operator-issued payment credentials with zero stored card data ## Related - ToughID: /api/md/products/toughid - PhantomGate™: /api/md/products/phantom-gate - Digital Identity solution: /api/md/solutions/digital-identity --- # Security Providers > MSPs, MSSPs, and security vendors can offer zero-custody cryptographic infrastructure as a differentiated service layer. ## The Opportunity Most managed-security offerings still depend on stored credentials — for the customer and, often, for the provider. Offering Phantom Secrets™-backed services lets a security provider eliminate the most consequential class of incident from its book of business while introducing a high-margin, defensible service line. ## How It Works Lokblok provides the Phantom Secrets™ runtime, integration patterns, and joint reference architectures. The security provider operates the service in its own infrastructure, under its own brand, with its own commercial terms. Lokblok supplies the protocol and ongoing roadmap. ## Related - Phantom Secrets™: /api/md/products/phantom-secrets - Enterprise Security: /api/md/solutions/enterprise-security - HSM Providers: /api/md/solutions/hsm-providers --- # Evaluate Lokblok > A guided technical evaluation path for security architects and procurement teams. ## What the Evaluation Includes 1. **Entry** — short qualification questionnaire covering use case, regulatory environment, and current key-management surface area. 2. **Hub** — curated technical materials matched to your use case: architecture documents, threat-model walkthroughs, integration patterns. 3. **Qualify** — deeper diagnostic to identify the highest-impact deployment surface in your environment. 4. **Result** — tailored summary with recommended product configuration, integration plan, and next steps to a hands-on briefing. ## Who This Is For - Security architects evaluating zero-custody or post-quantum strategies - Custody, treasury, and signing-operations leaders - Compliance and risk officers preparing audit-grade evidence ## Related - Demonstrators: /api/md/demonstrators - Contact: /api/md/contact --- # Demonstrators — Phantom Secrets™ in Action > Reference implementations, not retail products. Built for security architects, custody officers, and procurement teams who need to evaluate the technology against their own threat model. ## What These Demonstrators Are Working reference implementations of the Phantom Secrets™ protocol in selected use cases. They show concrete behaviour — key reconstruction, policy enforcement, ephemeral destruction — at the level of detail required to make a real procurement or architecture decision. They are not packaged products and they are not for resale. ## Who Should Use Them - Security architects validating the protocol against their threat model - Custody and treasury officers evaluating zero-custody operations - Procurement teams comparing Lokblok against incumbent HSM and MPC vendors - Government and regulated-entity reviewers performing technical due diligence ## How To Use Them Watch the recorded walkthroughs, download the reference materials, and request a hands-on session with a Lokblok engineer. Briefings are conducted under NDA. ## Related - Architecture: /api/md/architecture - Evaluate Lokblok: /api/md/evaluate - Contact: /api/md/contact --- # Glossary > The language of secrets that don't exist. Each term has its own page with related concepts. ## All terms (A–Z) - [Business-Logic-Enforced Cryptography](https://www.lokblok.co/glossary/business-logic-enforced-cryptography) — The principle behind hierarchical signatures: organisational policies (who must sign, under what conditions) are not just workflow rules but cryptographically required. If the right people don't sign, the secret simply cannot be recovered. - [Ephemeral](https://www.lokblok.co/glossary/ephemeral) — The property of a regenerated secret. It exists only for the briefest moment to perform its task, then is immediately destroyed — leaving nothing to store or steal. - [Hierarchical Signatures](https://www.lokblok.co/glossary/hierarchical-signatures) — An extension of MPC/TSS that enforces real-world business logic in the cryptography itself. Instead of simple thresholds (e.g. 'any 2 of 3'), signatures can require specific roles or conditions (e.g. CFO + CEO + Compliance Officer for large transactions). These rules are cryptographically binding, preventing spoofing, insider abuse, or collusion. Lokblok refers to this as business-logic-enforced cryptography. - [Lokbox](https://www.lokblok.co/glossary/lokbox) — Lokblok's secure cloud storage system (formerly Toughcloud) that shards and encrypts data across decentralised storage providers, with the customer retaining sole control of encryption keys. This design eliminates single points of compromise in cloud environments. Available today via S3-compatible APIs. - [Middleware](https://www.lokblok.co/glossary/middleware) — In Lokblok, middleware refers to two related layers. First, Lokblok's platform role: operating as an invisible, cloud-based security layer between existing applications and cryptographic hardware. Institutions integrate via APIs and SDKs, while end users never see Lokblok directly. Second, at the component level: the client-side and server-side software libraries that handle communication with Toughkey™s, Secure Terminal™, and other Lokblok modules. By design, Lokblok spans both senses — a SaaS middleware platform that delivers security as a service, and a set of middleware components that connect applications to certified hardware. - [Multi-Party Computation (MPC)](https://www.lokblok.co/glossary/multi-party-computation) — A cryptographic process where multiple parties jointly compute on a secret without any one party seeing the whole secret. In Phantom Secrets, recovery agents regenerate temporary secret shares, which are recombined inside a Toughkey to produce a usable private key for signing or encryption. The key exists only ephemerally, then is destroyed — ensuring nothing persists at rest. - [Phantom Gate™](https://www.lokblok.co/glossary/phantom-gate) — A stealth-mode access service formerly called Phantom Secrets Knock Knock Protocol. Keeps applications and servers invisible until an authenticated sequence is performed with a Toughkey™. Reduces the attack surface to near zero, extending Zero Trust ('Never Trust, Always Verify') into the service layer itself. Requires Secure Terminal™. - [Phantomizing](https://www.lokblok.co/glossary/phantomizing) — The full process of converting a persistent secret into a phantom secret that never exists at rest. Secrets are destroyed and only regenerated inside certified hardware when needed. - [Regen Tokens](https://www.lokblok.co/glossary/regen-tokens) — A step within phantomizing where encrypted secret shards are replaced with harmless Regen Tokens. These act like signposts — pointing to where a secret could be reconstituted, but carrying no value if stolen. - [Secure Terminal™ Encrypted Local Storage](https://www.lokblok.co/glossary/secure-terminal-encrypted-local-storage) — An enhancement to Secure Terminal™ that allows encrypted files to be kept entirely local on the user's device instead of being pushed to cloud storage. Users can optionally sync their encrypted files to services like OneDrive or Dropbox, but Lokblok itself never handles the raw file. - [Threshold Secret Sharing (TSShr)](https://www.lokblok.co/glossary/threshold-secret-sharing) — The foundational method of splitting a secret into multiple parts (shares), where only a defined threshold (e.g. 2 of 3) can reconstitute it. In traditional systems, shares are stored and later recombined. In Lokblok, shares are never stored: they are generated, recovered as needed, and destroyed immediately after use. This makes Threshold Secret Sharing the generic base concept underpinning Phantom Secrets, MPC, and Threshold Signature Schemes. - [Threshold Signature Scheme (TSSig)](https://www.lokblok.co/glossary/threshold-signature-scheme) — A form of MPC where the private key is never reconstructed at all. Instead, each participant produces a partial signature, and these are combined to form a complete digital signature. Unlike Phantom Secrets (where shares recombine inside a Toughkey), in TSSig the key never exists even ephemerally — only the final signature does. Lokblok implements TSSig directly in certified hardware, making it far stronger than software-only schemes. - [ToughID™](https://www.lokblok.co/glossary/toughid) — A Lokblok identity specification that orchestrates KYC, verification, and recovery processes across multiple parties, using tokenised data and hardware-based attestations to prove each step without exposing sensitive information. - [Toughkey™](https://www.lokblok.co/glossary/toughkey) — Certified hardware (FIPS / Common Criteria smartcard or USB form factor) that anchors Phantom Secrets in a tamper-resistant environment. Binds identity to device and ensures secrets are only ever reconstructed inside hardware. - [Zero Trust](https://www.lokblok.co/glossary/zero-trust) — The principle 'Never Trust, Always Verify.' Lokblok applies this to every layer: users, devices, networks, applications, and secrets. Nothing is assumed safe; everything must prove trustworthiness in real time. ## By category ### Phantom Secrets™ - [Phantomizing](https://www.lokblok.co/glossary/phantomizing) - [Regen Tokens](https://www.lokblok.co/glossary/regen-tokens) - [Ephemeral](https://www.lokblok.co/glossary/ephemeral) - [Toughkey™](https://www.lokblok.co/glossary/toughkey) - [Multi-Party Computation (MPC)](https://www.lokblok.co/glossary/multi-party-computation) - [Threshold Secret Sharing (TSShr)](https://www.lokblok.co/glossary/threshold-secret-sharing) - [Threshold Signature Scheme (TSSig)](https://www.lokblok.co/glossary/threshold-signature-scheme) - [Hierarchical Signatures](https://www.lokblok.co/glossary/hierarchical-signatures) - [Business-Logic-Enforced Cryptography](https://www.lokblok.co/glossary/business-logic-enforced-cryptography) ### Secure Terminal™ - [ToughID™](https://www.lokblok.co/glossary/toughid) - [Phantom Gate™](https://www.lokblok.co/glossary/phantom-gate) - [Secure Terminal™ Encrypted Local Storage](https://www.lokblok.co/glossary/secure-terminal-encrypted-local-storage) _(Coming Soon)_ ### Standalone / Infrastructure - [Lokbox](https://www.lokblok.co/glossary/lokbox) ### Core Principles - [Middleware](https://www.lokblok.co/glossary/middleware) - [Zero Trust](https://www.lokblok.co/glossary/zero-trust) --- # Phantom Secrets™ Architecture > How Lokblok eliminates the stored private key. ## The Problem Every key-based breach — from custodian compromises to enterprise data theft — has the same root cause: a private key existed somewhere it could be stolen, copied, or coerced. Conventional defences (encryption at rest, HSMs, key rotation, access controls) all assume the key must continue to exist. They protect the target rather than removing it. ## The Lokblok Approach Phantom Secrets™ removes the stored key from the architecture entirely. The protocol composes four well-established cryptographic primitives: 1. **Threshold cryptography** — the private key is split into N shares. M of N shares are required to reconstruct it. Shares alone reveal nothing. 2. **Hardware-bound reconstruction** — shares are combined only inside a certified HSM, secure element, or equivalent. The reconstructed key never exists outside hardware. 3. **Policy engine** — reconstruction proceeds only when identity, context, and quorum policies are satisfied. Policies are cryptographically enforced, not procedurally enforced. 4. **Ephemeral lifecycle** — the reconstructed key is used for a single cryptographic operation (sign, decrypt, authenticate) and is destroyed before the hardware boundary is exited. ## What Persists - **Public material** — public keys, addresses, certificates, audit logs. - **Regen Tokens** — public-data tokens used to regenerate distributed shares. They contain no secret material. - **Policy and identity bindings** — describing what conditions must be met before reconstruction is permitted. ## What Does Not Persist - The private key, in any form, at any layer. - Any single share large enough to reconstruct the key. - Any escrow, backup, recovery key, or administrative override. ## Algorithm Agility The protocol is algorithm-agnostic. ECC, RSA, AES, secp256k1, Ed25519 today; CRYSTALS-Kyber, SABER, NTRU and other post-quantum schemes can be substituted without architectural rewrite. Harvest-now-decrypt-later attacks find nothing to harvest because nothing is stored. ## Deployment Surfaces Phantom Secrets™ runs inside Lokblok's Toughkey HSM, partner HSMs, telecom SIM/eUICC, mobile secure enclaves, and qualified cloud HSMs. The same protocol semantics apply on every surface. ## Related - Phantom Secrets™ product: /api/md/products/phantom-secrets - Toughkey HSM: /api/md/products/toughkey - Quantum resistance: /api/md/features/quantum-resistance - Patents: /api/md/patents --- # Patents > Lokblok's patent portfolio covers the Phantom Secrets™ protocol and zero-custody key management. ## Scope The patent family covers the core mechanisms by which a private key can be used for a cryptographic operation without ever existing in storage at rest: - Threshold reconstruction inside certified hardware - Conditional reconstruction bound to identity, policy, and context - Ephemeral key lifecycle bounded by the hardware trust boundary - Regen Token mechanism for share regeneration without secret material persistence - Hierarchical and quorum-based signature workflows enforced cryptographically ## Jurisdictions Patents are granted or pending in major markets including the United States, the European Union, the United Kingdom, and other strategic jurisdictions. Specific filing details are available under NDA. ## Related - Architecture: /api/md/architecture - Phantom Secrets™: /api/md/products/phantom-secrets - Contact: /api/md/contact --- # About Lokblok > Lokblok is a European deep-tech company building the cryptographic infrastructure for an era in which stored secrets are no longer acceptable. ## Mission Eliminate the stored private key — the single component responsible for the majority of catastrophic cryptographic breaches across finance, custody, identity, and critical infrastructure. ## Position Lokblok is a research-led product company. The technology originates from work on threshold cryptography, hardware-bound key reconstruction, and ephemeral key lifecycle management. The result is the Phantom Secrets™ protocol: a way to use private keys without ever storing them. ## How Lokblok Engages - **Direct enterprise deployment** — for institutions running their own custody, identity, or signing infrastructure. - **OEM and HSM partnerships** — Phantom Secrets™ is embedded inside HSMs, secure elements, SIMs, eUICC, and mobile secure enclaves. - **Sovereign and regulated programmes** — for governments and regulated entities that require keys to be unreconstructable outside hardware they control. ## Related - Patents: /api/md/patents - Architecture: /api/md/architecture - Contact: /api/md/contact --- # Contact Lokblok > Book a technical briefing, request a white paper, or start a procurement conversation. ## Who Should Contact Us - Banks, custodians, exchanges, and payment institutions evaluating zero-custody infrastructure - Governments and regulated entities with sovereignty or post-quantum requirements - HSM manufacturers, secure-element vendors, and telecom operators considering an OEM partnership - Enterprises planning to eliminate standing credentials in privileged systems ## What a Briefing Covers - Phantom Secrets™ protocol walk-through (threshold reconstruction, hardware binding, policy engine) - Reference architecture for your specific deployment (custody, identity, signing, OT/SCADA, telecom, etc.) - Integration model with existing HSMs, wallets, and identity systems - Commercial and licensing model ## Reach Us - General: info@lokblok.co - Press and analyst inquiries: info@lokblok.co - Responsible disclosure: see /.well-known/security.txt ## Related - About: /api/md/about - Evaluate Lokblok: /api/md/evaluate --- # Privacy Policy > Lokblok® is committed to protecting your privacy. This policy describes how we collect, use, and protect information you provide to us. ## Information We Collect We collect information you provide directly to us, such as when you request a demo, contact us, or sign up for communications. This may include your name, email address, company name, job title, and the content of your messages. ## How We Use Your Information We use the information we collect to respond to your inquiries, provide product demonstrations, send communications you have requested, improve our products and services, and comply with legal obligations. ## Information Sharing Lokblok® does not sell, rent, or share your personal information with third parties for their marketing purposes. We may share information with service providers who assist us in operating our business, subject to appropriate confidentiality agreements. ## Data Security We implement industry-standard security measures to protect your personal information. Our own products, Phantom Secrets™, represent the state of the art in cryptographic security. We take data protection seriously at every level of our organisation. ## Cookies Our website uses cookies to improve your browsing experience and analyze site traffic. You can control cookie settings through your browser preferences. ## Contact If you have questions about this privacy policy or our data practices, please contact us at privacy@lokblok.com or using the contact form on our website. ## Changes to This Policy We may update this privacy policy from time to time. We will notify you of material changes by posting the updated policy on this page with a revised effective date. Effective date: January 1, 2025. --- # Insights > Practitioner-level pieces on key-management architecture, zero-custody cryptography, and the alternatives to keeping secrets at rest. - [Alternatives to MPC custody: when threshold key shares are still keys](https://www.lokblok.co/insights/alternatives-to-mpc-custody) — Multi-party computation custody distributes key shares across operators, but the shares still exist at rest. Map the failure modes of MPC and the case for on-demand reconstruction without persistent shares. - [How to eliminate stored private keys: a practitioner's guide](https://www.lokblok.co/insights/eliminate-stored-private-keys) — Walk the four storage models, HSM, MPC shares, encrypted backups, seed phrases, and the fifth model that removes the storage problem altogether: ephemeral reconstruction inside hardware. - [Post-quantum key management: why algorithms aren't enough](https://www.lokblok.co/insights/post-quantum-key-management) — Migrating to post-quantum algorithms is necessary but not sufficient. Stored keys remain a harvest-now-decrypt-later target until you remove the storage assumption itself. - [MiCA-compliant custody architecture: a technical reading](https://www.lokblok.co/insights/mica-compliant-custody-architecture) — MiCA Article 67 and 70 require segregation of client crypto-assets and demonstrable key control. A zero-custody architecture maps cleanly onto both requirements without operator-level controls. - [Zero-trust key management: extending Never Trust, Always Verify into the cryptographic layer](https://www.lokblok.co/insights/zero-trust-key-management) — Zero-trust networking removes the assumption of a trusted perimeter. Zero-trust key management removes the assumption of a trusted key store. Both rely on the same principle: nothing is safe by virtue of where it sits. - [Wallet recovery without seed phrases: quorum-based threshold reconstruction](https://www.lokblok.co/insights/recovery-without-seed-phrases) — Seed phrases trade one failure mode for another: the wallet can survive without the device, but only if the user can survive without losing a piece of paper. Quorum-based reconstruction removes both failure modes. - [Delegate signing without giving up keys: hierarchical signatures explained](https://www.lokblok.co/insights/delegation-without-custody) — Conventional delegation hands over the key. Hierarchical signatures grant the right to sign, under specific conditions, for a bounded time, without ever transferring the key material. - [Insider threat and cryptographic keys: why human-process controls run out of road](https://www.lokblok.co/insights/insider-threat-cryptographic-keys) — Rotation policies, dual control, and access reviews mitigate insider risk. They cannot eliminate it as long as a privileged operator can read, copy, or assemble the key. Cryptographic non-possession can. - [HSM vs MPC vs zero-persistence: a decision framework](https://www.lokblok.co/insights/hsm-vs-mpc-vs-zero-persistence) — Three models for protecting cryptographic keys, each with honest tradeoffs. Where each one fits, where each one breaks, and how zero-persistence reconstruction sits alongside the established two. - [Payment system key architecture: removing keys-at-rest from the chain](https://www.lokblok.co/insights/payment-system-key-architecture) — Payment cryptography concentrates risk in a long-lived ZMK/ZPK hierarchy. A zero-persistence runtime adds per-operation reconstruction without disturbing the certified HSM substrate underneath. --- # Alternatives to MPC custody: when threshold key shares are still keys > Multi-party computation custody distributes key shares across operators, but the shares still exist at rest. Map the failure modes of MPC and the case for on-demand reconstruction without persistent shares. *Primary query: alternatives to MPC custody. Last updated 2026-04-22.* MPC custody splits a private key into shares held by independent parties so no single operator can sign alone. That is a real improvement over a single hot wallet, and it is still custody. The shares persist at rest, the operators that hold them are coercible, and the recombination process is the new attack surface. The honest alternative is not 'more shares' but no persistent shares at all: reconstructing the key inside hardware only at the instant of use, then destroying every intermediate value. ## Why MPC custody isn't the end of the story Production MPC custody systems hold each party's share in a key-management service, an HSM, or a cloud KMS. The share is encrypted, audited, and rotated, but it is data at rest, and data at rest can be exfiltrated, subpoenaed, or quietly read by an insider with the right credentials. The cryptography says no single share is enough; operational reality says the same insider can often touch more than one. The recombination protocol introduces its own surface. Whether the key is briefly assembled in one location or only a partial signature is generated, the orchestration layer, the signing nodes, and the network between them all need hardening. Vendor breaches in 2022–2024 hit precisely these orchestration paths, not the cryptography itself. Recovery is the quietest failure mode. When a participant disappears, the surviving shares must be redistributed, which means the key has to be reconstructed somewhere, by someone, under time pressure. That is the moment most custodians discover their MPC deployment was indistinguishable from a multi-sig with extra steps. ## A model that has nothing to steal between operations Zero-persistence reconstruction inverts the question. Instead of distributing and protecting shares, the system holds only public, useless artifacts (Regen Tokens) at rest. When a signing operation is authorised by a quorum of independent recovery agents, ephemeral shares are derived inside a certified secure element, the signing key is reconstructed for one operation, the signature is produced, and every intermediate value is destroyed before the call returns. Between operations there is nothing in any store that an attacker, insider, regulator, or future quantum adversary can use. Recovery is the same primitive as everyday signing, a quorum re-derives the key on demand, so disaster recovery does not become a separate trust assumption. ## Side by side | Dimension | Conventional approach | Zero-persistence reconstruction | | --- | --- | --- | | Material at rest | Encrypted key shares | Public Regen Tokens | | Insider compromise of one operator | Reduces threshold by one | Reveals nothing useful | | Subpoena of any holder | Yields ciphertext shares | Yields no key material | | Recovery | Re-share ceremony, key briefly assembled | Same flow as a signing operation | | Quantum exposure (HNDL) | Stored shares are harvestable | Nothing to harvest | | Audit trail | Operator logs | Cryptographic chain bound to hardware attestation | ## What this looks like in practice - **A regulated digital-asset custodian** stops needing operator-level segregation policies because no operator ever holds key material; the segregation is enforced by the cryptography itself. - **An exchange running cold, warm, and hot tiers** collapses the tiers, the security difference between them was 'how often is the key present?', and the answer is now 'never except for the signing instant'. - **A bank moving toward MiCA Article 67/70 alignment** evidences key control through hardware attestation and a quorum log, instead of through layered procedural controls on share holders. ## Related Lokblok material - [zero-custody digital asset architecture](https://www.lokblok.co/solutions/digital-asset-custody) - [hierarchical signatures with policy-bound delegation](https://www.lokblok.co/features/hierarchical-signatures) - [the underlying threshold-reconstruction architecture](https://www.lokblok.co/architecture) ## FAQ ### Isn't MPC custody already non-custodial? No. MPC custody distributes trust between operators, but every share-holder is still a custodian of part of the key, and any sufficiently large subset of operators can collectively reconstruct it. A non-custodial architecture is one where the operator has nothing at any point in time that, alone or in collusion, can reproduce a usable key outside an authorised signing event. ### What happens during recovery if a recovery agent goes offline? Threshold reconstruction tolerates m-of-n agents being available, where m is the configured threshold. As long as the quorum is met, the missing agents are irrelevant to that operation. New agents can be enrolled by re-deriving Regen Tokens from a fresh quorum, without ever assembling the underlying key in storage. ### Is this just MPC with a hardware enclave? It uses threshold cryptography as a primitive but inverts the persistence model. Conventional MPC stores shares between operations; zero-persistence reconstruction stores only public material and derives shares on demand inside the hardware that will use them. The difference is whether anything sensitive exists at rest at all. ### How do auditors verify a key was used correctly if it never existed in storage? Each operation produces a signed, hardware-attested chain: the quorum vote, the policy evaluation, the secure-element attestation, and the resulting signature. Auditors verify the chain rather than inspect a key store; the cryptographic record is stronger than any operational log because it cannot be backdated or rewritten. ## Related insights - [How to eliminate stored private keys: a practitioner's guide](https://www.lokblok.co/insights/eliminate-stored-private-keys) - [HSM vs MPC vs zero-persistence: a decision framework](https://www.lokblok.co/insights/hsm-vs-mpc-vs-zero-persistence) --- # How to eliminate stored private keys: a practitioner's guide > Walk the four storage models, HSM, MPC shares, encrypted backups, seed phrases, and the fifth model that removes the storage problem altogether: ephemeral reconstruction inside hardware. *Primary query: how to eliminate stored private keys. Last updated 2026-04-22.* Every breach of a key-management system is a breach of something stored. The honest engineering question is whether the key needs to exist between operations at all. For most signing, decryption, and authentication workloads it does not, the key only needs to exist at the moment of use. This article maps the four conventional storage models, the failure mode each one accepts, and a fifth model that holds no key material at rest. ## The four conventional storage models Hardware security modules (HSMs) keep keys inside a tamper-resistant boundary. The boundary is excellent; the assumption that a key must live inside it for years is the weak point. Every HSM-protected key is a multi-year target with a known location. MPC shares distribute the key across operators so no single party holds it whole. Effective against single-operator compromise; ineffective against share-store breaches, insider collusion, or the brief recombination window during signing. Encrypted backups (cold storage, KMS-wrapped blobs, paper backups) push the problem to a key-encryption key. The KEK is itself a key that must be stored somewhere, usually with weaker controls than the keys it protects. Seed phrases and BIP39 mnemonics are the retail equivalent: a written secret with the same lifetime as the wallet. They fail at recovery time, when the user must produce a piece of paper that may have been lost, photographed, or coerced. ## A fifth model: hold no key, reconstruct on demand Zero-persistence key reconstruction stores only public, non-sensitive Regen Tokens between operations. When a signing or decryption call arrives, a quorum of independent recovery agents authorises the operation; ephemeral shares are derived inside a certified secure element; the key is reconstructed for that single operation and destroyed before the call returns. The attack surface at rest is not 'small', it is empty. Recovery uses the same primitive: a quorum re-derives the key on demand, with no special ceremony and no temporary assembly point. The disaster-recovery flow stops being a separate, weaker security regime than everyday operation. ## Side by side | Dimension | Conventional approach | Zero-persistence reconstruction | | --- | --- | --- | | Key at rest | Encrypted blob, sharded blob, or written phrase | None, only public Regen Tokens | | Theft surface | Persistent, measured in years | Ephemeral, measured in milliseconds | | Insider access | Privileged operators can read or assemble | Operators have nothing useful to read | | Backup | Separate, often weaker, copies | Same flow as signing, no copies needed | | Recovery | Custodian / seed-phrase ceremony | Quorum re-derives on demand | | Audit | Process and log review | Hardware-attested cryptographic chain | ## What this looks like in practice - **A SaaS platform that signs customer artefacts** stops budgeting for an HSM cluster's lifetime threat model, the per-tenant signing key only exists for the milliseconds it is used. - **A retail wallet vendor** removes the seed-phrase recovery flow and replaces it with a quorum of devices the user already controls plus a recovery-agent network. - **A regulated bank running internal PKI** ages out long-lived KMS-wrapped keys in favour of per-operation ephemeral keys, shrinking the cryptographic-incident blast radius from 'all signatures since rotation' to 'one signature'. ## Related Lokblok material - [zero standing secrets as an architectural principle](https://www.lokblok.co/features/private-keys) - [hardware-rooted threshold reconstruction](https://www.lokblok.co/architecture) - [Phantom Secrets™ as a key-management protocol](https://www.lokblok.co/products/phantom-secrets) ## FAQ ### Doesn't every system need a key somewhere? Every system needs a key at the instant of use. It does not need a key between uses. Zero-persistence reconstruction stores only public material at rest and assembles a key inside hardware only when an authorised operation is in flight, then destroys it immediately. ### How does this differ from short-lived KMS-wrapped keys? Short-lived keys are still stored, the wrapping key is the persistent secret. Zero-persistence reconstruction has no persistent secret at any layer; the artifacts at rest are public Regen Tokens that cannot reproduce a key on their own, regardless of who reads them. ### Can the same model protect symmetric encryption keys, not just signing keys? Yes. The same threshold-reconstruction primitive applies to any cryptographic operation that needs a key briefly: AES data-encryption keys, JWT-signing keys, code-signing keys, and TLS server keys can all be reconstructed on demand inside hardware without persistent storage. ### What about latency? Reconstruction adds the network round-trip to the recovery agents and the secure-element operation. For most signing and decryption workloads this is in the low tens of milliseconds, comparable to a remote KMS call and lower than many HSM cluster operations. ## Related insights - [Alternatives to MPC custody: when threshold key shares are still keys](https://www.lokblok.co/insights/alternatives-to-mpc-custody) - [Zero-trust key management: extending Never Trust, Always Verify into the cryptographic layer](https://www.lokblok.co/insights/zero-trust-key-management) --- # Post-quantum key management: why algorithms aren't enough > Migrating to post-quantum algorithms is necessary but not sufficient. Stored keys remain a harvest-now-decrypt-later target until you remove the storage assumption itself. *Primary query: post-quantum HSM. Last updated 2026-04-22.* Most post-quantum migration plans focus on swapping algorithms, RSA and ECC out, ML-KEM and ML-DSA in. That is necessary work. It also leaves the deeper assumption untouched: that cryptographic keys exist at rest. Any key sitting in storage today is a candidate for harvest-now-decrypt-later, and 'we will rotate it before quantum is real' is a calendar bet, not an architecture. The durable answer is to stop storing keys at all. ## Algorithm agility solves half the problem NIST's post-quantum standardisation gives the industry a concrete migration target: by some date, every long-lived key should use a quantum-resistant algorithm. Crypto-agile HSMs and KMS products make the swap mechanically possible. None of this addresses what happens to the keys that are stored today. Adversaries with significant collection budgets do not need to wait for quantum hardware to extract value. They need to record encrypted traffic and capture key material now. Encrypted backups, KMS-wrapped blobs, MPC share stores, and archived TLS sessions are the harvest-now-decrypt-later targets. The fix is not 'rotate to PQ', the rotated key is still stored, and the previously stored ciphertext is already in the adversary's hands. Post-quantum HSMs also still concentrate risk: a single device boundary protecting a key for years is the same architecture, with a different algorithm inside. ## Remove the harvest target If the key does not exist at rest, there is nothing to harvest. Zero-persistence reconstruction stores only public Regen Tokens and reconstructs the operating key inside a secure element only at the instant of use. An adversary who records the network sees ciphertext; an adversary who breaches the storage layer finds public material with no cryptographic value. The model is also algorithm-neutral. The threshold primitive can derive ECC keys today and ML-DSA keys tomorrow without re-architecting the surrounding system. Crypto-agility becomes a property of the runtime, not a multi-quarter migration project. ## Side by side | Dimension | Conventional approach | Zero-persistence reconstruction | | --- | --- | --- | | Harvest-now-decrypt-later exposure | All currently stored keys are at risk | Nothing stored to harvest | | Algorithm migration | Re-key, re-distribute, re-attest every key | Switch the derivation algorithm in the runtime | | Long-lived key lifetimes | Years per key | Milliseconds per use | | PQ HSM cost | New hardware fleet | Software upgrade to existing secure elements | | Quantum break window | All historic ciphertext signed under the broken algorithm becomes forgeable | Only signatures issued during the vulnerable window are exposed | ## What this looks like in practice - **A telecom operator with subscriber identity keys** stops worrying about SIM-vault harvesting because each authentication derives an ephemeral subscriber key inside a quorum-bound element. - **A government PKI** decouples PQ migration from key rotation, the same signing service can serve ECC and ML-DSA in parallel for years without holding both keys at rest. - **A long-tail TLS workload** halves its rotation budget because there is no key to rotate, only a derivation parameter. ## Related Lokblok material - [quantum-resistant key management without persistent secrets](https://www.lokblok.co/features/quantum-resistance) - [the algorithm-agile threshold runtime](https://www.lokblok.co/architecture) - [Phantom Secrets™ as a runtime layer for any HSM or secure element](https://www.lokblok.co/products/phantom-secrets) ## FAQ ### Do I still need post-quantum algorithms if there is no key at rest? Yes, for signature verification on existing chains, for traffic in flight, and for the threshold primitive itself. Zero-persistence does not replace post-quantum algorithms; it removes the harvest-now-decrypt-later attack against keys that would otherwise sit in storage waiting for a quantum break. ### What about historic ciphertext I have already encrypted with ECC? Anything already encrypted with a quantum-vulnerable algorithm and held by an adversary is exposed when quantum hardware arrives. Zero-persistence reconstruction does not retroactively repair this; it stops the bleeding for everything you do from now on. ### Can I migrate from a conventional HSM in place? Phantom Secrets™ runs as a software layer on top of FIPS-certified secure elements, including modern HSMs. The migration path is to introduce zero-persistence operations alongside existing stored-key operations, then ramp down the stored keys as workloads move over. ### How does crypto-agility actually work at the runtime layer? The runtime decouples the key-derivation algorithm from the calling application. Switching from ECC to ML-DSA changes which primitive the secure element invokes during reconstruction; the orchestration layer, the recovery agents, and the audit chain are unchanged. ## Related insights - [How to eliminate stored private keys: a practitioner's guide](https://www.lokblok.co/insights/eliminate-stored-private-keys) - [HSM vs MPC vs zero-persistence: a decision framework](https://www.lokblok.co/insights/hsm-vs-mpc-vs-zero-persistence) --- # MiCA-compliant custody architecture: a technical reading > MiCA Article 67 and 70 require segregation of client crypto-assets and demonstrable key control. A zero-custody architecture maps cleanly onto both requirements without operator-level controls. *Primary query: MiCA-compliant custody architecture. Last updated 2026-04-22.* MiCA's custody requirements (Articles 67 and 70 in particular) ask custodians to segregate client crypto-assets, prevent commingling with their own holdings, and demonstrate effective control over the underlying keys. Most existing implementations meet this through layered operator-level controls. A zero-custody architecture meets it through cryptography: the operator never holds material that could move client assets, so segregation is enforced by construction rather than by policy. ## What the regulation actually asks for Article 67 obliges crypto-asset service providers to safeguard client crypto-assets and means of access, including segregation from the provider's own holdings and demonstrable arrangements that prevent loss arising from misuse, fraud, or operational failure. Article 70 reinforces this with specific custody-and-administration obligations. Conventional custody platforms answer this with operator hierarchies, dual control, segregated wallets per client, and audited key ceremonies. The regulator inspects the procedural controls and the access logs; the supervisor's confidence is in the chain of human approvals, not in the key material itself. The blast radius of any operator compromise, insider, credential theft, supply-chain, is the set of client wallets that operator could touch. That is usually a large set, because operational efficiency pulls toward shared infrastructure. ## Cryptographic segregation, not procedural segregation Zero-persistence custody removes the operator's ability to act on client assets at all. Each client wallet's signing key exists only at the instant of an authorised operation; it is reconstructed inside a secure element, used once, and destroyed. No operator, including the platform itself, holds material capable of producing a signature outside of an authorised event. The supervisor's evidence shifts from 'we have policies that prevent operators from misusing keys' to 'no operator has ever held the key, and the cryptographic chain proves it'. Segregation is not a property of the operator's directory layout; it is a property of the keys themselves. ## Side by side | Dimension | Conventional approach | Zero-persistence reconstruction | | --- | --- | --- | | Segregation enforcement | Operator policy + access controls | Per-wallet keys, never assembled outside the authorised event | | Insider misuse blast radius | All wallets the operator can reach | None, operator holds no usable key | | Article 67 evidence | Procedure documentation, access logs | Hardware-attested cryptographic chain per operation | | Disaster recovery | Backup keys held by the custodian | Quorum re-derives on demand; no backup exists | | Sub-custodian risk | Each sub-custodian needs its own controls | Sub-custodians can be quorum members without holding key material | ## What this looks like in practice - **A MiCA-licensed exchange** documents key control by reference to hardware attestation rather than operator workflow, shrinking the operational-controls section of its supervisory file. - **A bank offering crypto-asset custody to professional clients** uses its own staff as one quorum participant and an external recovery-agent network as another, evidencing genuine separation of duties without sharing key material. - **A pan-EU custodian serving multiple national supervisors** demonstrates the same segregation model uniformly across jurisdictions, because the segregation is cryptographic rather than process-based. ## Related Lokblok material - [MiCA-aligned digital asset custody](https://www.lokblok.co/solutions/digital-asset-custody) - [the underlying threshold-reconstruction architecture](https://www.lokblok.co/architecture) - [policy-bound delegation for institutional approval workflows](https://www.lokblok.co/features/hierarchical-signatures) ## FAQ ### Does zero-persistence custody count as 'safeguarding' under MiCA Article 67? Article 67 requires the provider to take effective steps to prevent loss from misuse, fraud, or operational failure. A model in which the provider holds nothing capable of moving client assets between authorised events meets the spirit of safeguarding more strictly than any procedural arrangement, because the prohibited actions are cryptographically impossible rather than merely policy-forbidden. ### How does this interact with the requirement to maintain a register of client positions? The position register is independent of the key model. Zero-persistence reconstruction protects the means of access (the keys); the off-chain ledger of who owns what continues to be maintained by the custodian and reconciled to on-chain balances on the normal cadence. ### What does the supervisor inspect if there are no key ceremonies? The supervisor inspects the recovery-agent quorum configuration, the secure-element attestation chain, the policy engine that authorises operations, and the per-operation cryptographic record. These are stronger evidence than ceremony minutes because they cannot be backdated. ### Can the same architecture serve professional and retail clients under different obligation levels? Yes. The same per-wallet zero-persistence model applies; the policy engine differentiates retail and professional flows by quorum composition, approval thresholds, and operational limits, not by storing different keys. ## Related insights - [Alternatives to MPC custody: when threshold key shares are still keys](https://www.lokblok.co/insights/alternatives-to-mpc-custody) - [Delegate signing without giving up keys: hierarchical signatures explained](https://www.lokblok.co/insights/delegation-without-custody) --- # Zero-trust key management: extending Never Trust, Always Verify into the cryptographic layer > Zero-trust networking removes the assumption of a trusted perimeter. Zero-trust key management removes the assumption of a trusted key store. Both rely on the same principle: nothing is safe by virtue of where it sits. *Primary query: zero-trust key management. Last updated 2026-04-22.* Zero-trust networking dismantled the idea that a corporate perimeter could be trusted. Every request is authenticated, every device is attested, every session is short-lived. The cryptographic layer underneath has not yet caught up. We still build key-management systems on the assumption that a 'trusted key store' exists. A zero-trust key model rejects that assumption: no store is trusted, no key is allowed to persist between authorised events, and every signing operation is verified end-to-end before any key material exists. ## Why 'trusted key store' is an oxymoron A trusted store has the same problem as a trusted network: it concentrates value, becomes a target, and converts every breach into a catastrophic loss. The fact that the store is an HSM or a KMS or an MPC share-cluster does not change the structural property, there is a place an attacker can aim at, and the value of compromising it grows with every key it holds. Operationally, the 'trust' in trusted store is process trust: the operators are vetted, the access is logged, the rotations are scheduled. Zero-trust networking spent a decade arguing that process trust is necessary but never sufficient. The same argument applies to keys. ## Verify the request, then reconstruct Zero-trust key management treats every signing or decryption call the way zero-trust networking treats every connection. The identity of the caller is verified, the device is attested, the policy is evaluated, and a quorum of independent recovery agents authorises the specific operation. Only then are ephemeral shares derived inside the secure element that will use them; the resulting key exists for one operation and is destroyed before the response is returned. Between operations there is no key store to harden, no perimeter to defend, and no privileged operator to monitor. The trust boundary collapses to the per-operation cryptographic chain, which is verifiable after the fact by anyone with the public attestation material. ## Side by side | Dimension | Conventional approach | Zero-persistence reconstruction | | --- | --- | --- | | Trust model | Trusted store + procedural controls | No trusted store; per-operation attestation | | Persistent target | Yes, the store itself | No, only public material at rest | | Operator authority | Privileged access to read or assemble keys | None outside the authorised event | | Identity binding | External (the operator says who is calling) | Built into the cryptographic chain | | Audit | Log review | Cryptographic verification | ## What this looks like in practice - **An enterprise issuing internal code-signing keys** stops needing a hardened build-server bastion because the signing key only exists for the build-step that requested it, with the requesting CI job's identity bound into the attestation chain. - **A privileged-access management platform** replaces the long-lived SSH CA key with a per-session reconstruction, so a compromise of the PAM server cannot mint backdoor certificates. - **A regulated workload with strict separation-of-duties requirements** encodes the duty separation into the recovery-agent quorum directly: no signature exists unless the required roles each contributed. ## Related Lokblok material - [the zero-persistence cryptographic architecture in detail](https://www.lokblok.co/architecture) - [enterprise-wide zero-trust key controls](https://www.lokblok.co/solutions/enterprise-security) - [Phantom Gate™ for service-to-service zero-trust access](https://www.lokblok.co/products/phantom-gate) ## FAQ ### How does zero-trust key management relate to zero-trust networking? They share the same principle: never assume safety based on location. Zero-trust networking removes the trusted perimeter; zero-trust key management removes the trusted key store. Both replace a positional trust model with a per-event verification model that does not rely on any zone being inherently safe. ### Doesn't this just move trust to the recovery agents? It distributes trust to a quorum of independent recovery agents, none of which holds anything useful on its own. The trust model is a threshold: a sufficient subset of agents must authorise an operation, and any single agent can be compromised without affecting the system. This is structurally different from trusting any single store or operator. ### Is this compatible with existing zero-trust frameworks like BeyondCorp or NIST 800-207? Yes. Zero-trust frameworks describe the verification model for access; zero-trust key management plugs into the same identity, device, and policy signals and uses them to authorise the cryptographic operation as well as the network access. ### How is the per-operation attestation produced? Each step of the workflow, caller authentication, device attestation, policy evaluation, quorum vote, secure-element operation, signature emission, produces a signed record that links to the previous step. The chain is the audit artefact and is verifiable independently of the system that produced it. ## Related insights - [Insider threat and cryptographic keys: why human-process controls run out of road](https://www.lokblok.co/insights/insider-threat-cryptographic-keys) - [Delegate signing without giving up keys: hierarchical signatures explained](https://www.lokblok.co/insights/delegation-without-custody) --- # Wallet recovery without seed phrases: quorum-based threshold reconstruction > Seed phrases trade one failure mode for another: the wallet can survive without the device, but only if the user can survive without losing a piece of paper. Quorum-based reconstruction removes both failure modes. *Primary query: wallet recovery without seed phrases. Last updated 2026-04-22.* BIP39 seed phrases solved a real problem in 2013: how does a wallet survive a lost device? The answer was to write the entropy down. A decade of incidents shows the cost of that answer: phishing for seed phrases, photographs in cloud backups, $5-wrench attacks, lost wallets that should have been recoverable, and family inheritance disasters. Quorum-based threshold reconstruction replaces the paper backup with a distributed authorisation event, no single secret to write down, no single artifact to lose or steal. ## What seed phrases actually trade A seed phrase is a complete copy of the wallet's master secret, expressed in a memorable form. Anyone who reads it can drain the wallet; anyone who loses it loses the wallet. Both failure modes are routine. Phishing pages that trick users into entering twelve words remain the dominant retail-crypto attack vector; the long tail of 'I've lost my seed phrase' losses is invisible because no one self-reports. Sharded backups (Shamir, Trezor's SLIP-39, social-recovery wallets) reduce the single-artifact risk by spreading the secret across multiple cards or contacts. They reduce, but do not remove, the persistent-secret problem: the shards still exist, can still be photographed, and still combine into a key that exists from that moment forward. Institutional deployments inherit the same logic at a different scale: a master backup that is 'safe' as long as nobody compromises the safe. ## Recovery as a quorum event Quorum-based threshold reconstruction replaces the written backup with an authorisation event. The user proves identity to a configured quorum of recovery agents, combinations of personal devices, family members, professional fiduciaries, or institutional services, and the quorum authorises the derivation of the signing key inside a secure element. The key is used for the requested operation and destroyed immediately afterwards. There is no master secret anywhere to write down, lose, or photograph. Recovery uses the same primitive as everyday signing, so the security regime does not weaken at the moment of greatest stress. ## Side by side | Dimension | Conventional approach | Zero-persistence reconstruction | | --- | --- | --- | | Backup artifact | Written seed phrase or shards | None, quorum re-derives on demand | | Phishing surface | Twelve-word entry forms | No reusable secret to phish | | $5-wrench coercion | User can be forced to reveal the phrase | No phrase exists; coercion must compromise the quorum | | Lost-device recovery | Re-import seed on new device | Re-enrol new device with quorum approval | | Inheritance | Heir must find the phrase | Configurable transfer-on-death policy in the quorum | ## What this looks like in practice - **A retail self-custody wallet** ships without a seed-phrase setup screen; users enrol two personal devices and one optional recovery service as the initial quorum. - **A family digital-estate plan** configures the quorum as 'the device + two of three family members + optional notary' for inheritance, with a configurable delay for contestation. - **An institutional employee wallet** uses the employee's hardware token + the security team + a separation-of-duties officer as the quorum, eliminating the 'departing employee' recovery flow. ## Related Lokblok material - [transfer on death and digital-inheritance flows](https://www.lokblok.co/solutions/digital-inheritance) - [the underlying threshold-reconstruction model](https://www.lokblok.co/architecture) - [Toughkey™ as the user-side hardware root](https://www.lokblok.co/products/toughkey) ## FAQ ### What if I lose all of my devices? Recovery succeeds as long as the quorum threshold can still be met. A typical configuration tolerates losing any one quorum participant; aggressive configurations tolerate losing more. The point is that no single artefact can lose access to the wallet. ### How is this different from social-recovery wallets like Argent? Social-recovery wallets recover a stored key by combining shares held by guardians. Quorum-based threshold reconstruction does not store a key at all, the recovery agents authorise the derivation of an ephemeral key inside hardware. The difference is whether anything sensitive exists between operations. ### Can the recovery agents collude to steal the wallet? A sufficient quorum of recovery agents can authorise an operation. This is identical to any threshold model. The mitigation is to choose a quorum composition where collusion is operationally implausible, e.g. an institutional agent, an offline personal device, and a notary, and to require the secure element's hardware attestation as part of the chain. ### Does this work for hardware wallets? Yes. The user's hardware wallet (Toughkey™ or any compatible secure element) is one quorum participant; the others are configured per the user's threat model. The hardware wallet stops being a single point of failure because losing it does not lose the wallet. ## Related insights - [Delegate signing without giving up keys: hierarchical signatures explained](https://www.lokblok.co/insights/delegation-without-custody) - [Alternatives to MPC custody: when threshold key shares are still keys](https://www.lokblok.co/insights/alternatives-to-mpc-custody) --- # Delegate signing without giving up keys: hierarchical signatures explained > Conventional delegation hands over the key. Hierarchical signatures grant the right to sign, under specific conditions, for a bounded time, without ever transferring the key material. *Primary query: delegate signing without giving up keys. Last updated 2026-04-22.* Delegation is the routine that breaks every key-management system. To let someone else sign on my behalf, I copy the key, share the share, mint a sub-credential, or grant API access, and from that moment the delegate has the same power I do, with weaker accountability. Hierarchical signatures change the granularity: the policy engine grants the right to sign a specific operation, under specific conditions, for a bounded period, without ever transferring the underlying key. ## Why conventional delegation fails Sharing a key, even briefly, is custodianship transfer: the recipient now holds something they should not be trusted with for a moment longer than necessary, and you have no cryptographic guarantee they will not retain it. Sub-keys (intermediate CAs, derived signing keys, OAuth client credentials) reduce the blast radius but do not change the model, the delegate still holds material. The audit story is also weak. Logs say 'a signature was produced'; they do not prove the signature respected the policy under which delegation was granted. Reconstructing 'did the delegate exceed their authority?' is forensic work after the fact. ## Delegation as a policy-bound signing right In a zero-persistence model, the underlying key is reconstructed inside hardware only when a quorum authorises an operation. Delegation becomes a policy: the delegate's identity is added to the set of acceptable callers, with constraints, operation type, value, counterparty, time window, geography, encoded in the policy that the quorum evaluates. The delegate never holds the key; they hold the right to trigger an authorised reconstruction within the policy boundary. The audit chain is intrinsic. Every signature carries a hardware-attested record of which policy authorised it, which delegate triggered it, and which quorum members signed off. There is no 'unauthorised use of the delegated key' failure mode because there is no delegated key. ## Side by side | Dimension | Conventional approach | Zero-persistence reconstruction | | --- | --- | --- | | What is delegated | Key material or a sub-credential | A policy-bound signing right | | Delegate compromise blast radius | Everything the delegate could sign before revocation | Only operations within the policy bounds | | Revocation | Re-issue or rotate keys | Update the policy; takes effect on the next operation | | Audit | Logs of delegate activity | Cryptographic chain proving policy compliance | | Bounded operations (e.g. value, counterparty) | Application-layer enforcement | Cryptographic enforcement at the signing step | ## What this looks like in practice - **A treasury team delegating routine outflows to operations staff** configures a policy that authorises sub-threshold transfers to a list of approved counterparties without operations holding the treasury key. - **An asset manager granting limited trading authority to a sub-advisor** encodes the mandate (instrument list, position limits, time horizon) directly into the signing policy; off-mandate trades cannot be signed at all. - **A SaaS platform letting a third party sign artefacts on its behalf** issues a per-tenant delegation that allows signing only artefacts matching the tenant's namespace, automatically expiring at the contract end date. ## Related Lokblok material - [hierarchical signatures with cryptographically enforced approvals](https://www.lokblok.co/features/hierarchical-signatures) - [Phantom Secrets™ as the underlying key-derivation protocol](https://www.lokblok.co/products/phantom-secrets) - [MiCA-aligned institutional custody flows](https://www.lokblok.co/solutions/digital-asset-custody) ## FAQ ### How is this different from a sub-key or derived key? A sub-key is still a key the delegate holds; revoking it requires action and propagation. A policy-bound signing right grants no key material, the delegate triggers the reconstruction of the parent key under quorum control, and revocation is a policy update that takes effect immediately. ### Can the policy enforce arbitrary business rules? Within practical limits, yes. Common constraints include operation type, payload patterns, counterparty allow-lists, value thresholds, time windows, geography from the device attestation, and required co-signers. Anything that can be evaluated deterministically against the operation request can be made part of the policy. ### What happens if the delegate's identity is compromised? An attacker impersonating the delegate can only trigger operations the policy already permits. They cannot exfiltrate the key (it does not exist between operations), they cannot widen the policy without quorum approval, and every action is bound to the delegate's identity in the audit chain. ### Is this compatible with hardware wallets and existing signing devices? Yes. The reconstruction happens inside a certified secure element; the delegate's role is to authenticate to the quorum and trigger an operation. Their device can be a hardware wallet, a Toughkey™, a phone with attestation, or an integrated CI runner. ## Related insights - [MiCA-compliant custody architecture: a technical reading](https://www.lokblok.co/insights/mica-compliant-custody-architecture) - [Insider threat and cryptographic keys: why human-process controls run out of road](https://www.lokblok.co/insights/insider-threat-cryptographic-keys) --- # Insider threat and cryptographic keys: why human-process controls run out of road > Rotation policies, dual control, and access reviews mitigate insider risk. They cannot eliminate it as long as a privileged operator can read, copy, or assemble the key. Cryptographic non-possession can. *Primary query: insider threat key management. Last updated 2026-04-22.* Every mature security program has insider-threat controls: separation of duties, four-eyes approvals, periodic access reviews, privileged-session recording. They reduce the probability of misuse and increase the probability of detection. They do not change the underlying fact: somewhere, a sufficiently privileged person can read or assemble the key. Cryptographic non-possession changes that fact, there is no key for an insider to access between authorised events. ## Where human-process controls hit their ceiling Dual control assumes the two operators are independent. In practice, organisational pressure, deadlines, and shared reporting lines collapse independence. The most damaging breaches of the past decade have not been single-operator failures, they have been small-group failures where the controls existed but the dynamics did not enforce them. Privileged-session recording is forensic, not preventive. By the time the recording is reviewed, the key has been copied. Access reviews assume the reviewer can tell legitimate access from illegitimate; for cryptographic operations, this distinction is often invisible at the access-control layer. Rotation reduces the lifetime of any single compromise. It does not reduce the per-event blast radius and it relies on the very same operators to execute the rotation correctly. ## Cryptographic non-possession Zero-persistence reconstruction inverts the question. The operator does not hold the key, ever. Between operations there is only public Regen Token material; during an operation, the key is reconstructed inside a secure element, used once, and destroyed before the response returns. An operator with arbitrary administrative access to the platform finds nothing to misuse. Insider threat controls do not disappear, they continue to apply to the policy engine, the recovery-agent quorum membership, and the application logic. They simply stop being the last line of defence against unauthorised key use, because cryptographic non-possession is now that line. ## Side by side | Dimension | Conventional approach | Zero-persistence reconstruction | | --- | --- | --- | | Privileged operator can read the key | Yes, by design or by privilege escalation | No key exists to read | | Two-operator collusion | Defeats dual control | Defeats the policy engine, but no key is exfiltrated | | Departing-employee risk | Re-key, rotate, audit | Remove from quorum and policy; no key material to revoke | | Forensic discovery | Sessions reviewed after the fact | Cryptographic chain proves what happened | | Coerced operator (legal or physical) | Operator can produce the key | Operator cannot produce a key that does not exist | ## What this looks like in practice - **A custodian moving from N-of-M operator approvals to per-operation cryptography** stops needing operations staff to be cleared to signing-key-equivalent levels because operations staff never touch signing material. - **An enterprise CA** removes the long-lived intermediate CA key from the offline vault and replaces it with per-operation reconstruction; the 'key ceremony' becomes the everyday flow. - **A bank with a privileged-access platform** binds privileged session approval into the cryptographic chain so a privileged session that did not produce a quorum-authorised signature simply did not produce one. ## Related Lokblok material - [enterprise insider-threat key controls](https://www.lokblok.co/solutions/enterprise-security) - [the cryptographic enforcement model in detail](https://www.lokblok.co/architecture) - [Phantom Gate™ as a stateless access boundary](https://www.lokblok.co/products/phantom-gate) ## FAQ ### Doesn't the policy engine become the new insider-threat target? It does, and that is a feature. The policy engine has a much smaller, more specific surface than a general key store, and its decisions are co-signed by the recovery-agent quorum. An insider who compromises the policy engine cannot mint signatures on their own; they can at most attempt to push policy changes that the quorum must still approve. ### What about the recovery agents themselves, could a malicious agent collude with an insider? A quorum threshold tolerates a configured number of malicious or unavailable agents. Sound deployments place agents under genuinely independent operational control, different organisations, different jurisdictions, different hardware. A single insider cannot meet quorum alone. ### How does this map onto regulatory expectations for separation of duties? Regulators expect demonstrable separation between request, approval, and execution. A policy + quorum + secure-element model produces that separation cryptographically and records it in the per-operation chain. The regulatory evidence is stronger than process documentation because it cannot be backdated. ### Does this remove the need for SIEM and access reviews? No. SIEM, access reviews, and behavioural monitoring continue to apply to the platform. They simply stop being the last line of defence against key compromise, because there is no key to compromise between authorised events. ## Related insights - [Zero-trust key management: extending Never Trust, Always Verify into the cryptographic layer](https://www.lokblok.co/insights/zero-trust-key-management) - [Delegate signing without giving up keys: hierarchical signatures explained](https://www.lokblok.co/insights/delegation-without-custody) --- # HSM vs MPC vs zero-persistence: a decision framework > Three models for protecting cryptographic keys, each with honest tradeoffs. Where each one fits, where each one breaks, and how zero-persistence reconstruction sits alongside the established two. *Primary query: HSM vs MPC. Last updated 2026-04-22.* There is no universal best choice for protecting cryptographic keys. HSMs, MPC custody, and zero-persistence reconstruction each make different tradeoffs and each fits different workloads. This article maps the three honestly: what each model assumes, what it gives up, and the kinds of workload where each one is the right answer. Treat this as a decision framework, not a marketing comparison. ## What each model actually offers An HSM offers a hardened boundary around a long-lived key. Strengths: certified tamper resistance, well-understood operational model, broad standards support. Weaknesses: the key persists for years inside the boundary, the boundary is a known target, and the operator with administrative access to the HSM cluster is a single point of catastrophic compromise. MPC custody offers distribution of trust across operators. Strengths: no single operator holds the whole key, removes a class of single-point compromises, fits institutional governance. Weaknesses: shares persist at rest across the operator estate, the recombination step is a real surface, and the security model degrades to operator-trust under collusion. Zero-persistence reconstruction offers the absence of a key at rest. Strengths: nothing to harvest, insider non-possession, algorithm agility, recovery flow identical to signing flow. Weaknesses: requires a quorum of recovery agents (operational dependency), benefits are largest when the workload tolerates per-operation reconstruction latency. ## How they compose, not compete In practice the three models layer well. The secure element used for zero-persistence reconstruction is itself a hardened HSM-class device, Phantom Secrets™ runs as a software layer on top of FIPS-certified hardware. The threshold primitive used for the on-demand derivation is the same threshold cryptography the MPC vendors built their products around, the difference is whether the shares persist between operations. The decision is rarely 'replace HSMs with X'. It is more often 'where is a key currently sitting between operations, and could it not?'. For most signing and decryption workloads the answer is that the key does not need to persist, and the cleanest model is to stop persisting it. ## Side by side | Dimension | Conventional approach | Zero-persistence reconstruction | | --- | --- | --- | | Material at rest | HSM: the key. MPC: the shares. | Public Regen Tokens only | | Insider compromise | HSM: catastrophic. MPC: bounded by threshold. | Bounded by quorum; no key exfiltration | | Per-operation latency | HSM: low. MPC: medium. | Medium (quorum + secure element) | | Regulatory acceptance | HSM: extensive. MPC: growing. | Maps naturally onto safeguarding obligations | | Crypto-agility | HSM: per-device upgrades. MPC: per-protocol. | Runtime swap | | Backup/recovery | HSM: backup ceremonies. MPC: re-share ceremonies. | Same primitive as signing | ## What this looks like in practice - **A payment processor running per-transaction MAC keys** keeps an HSM cluster for line-rate symmetric operations and adds zero-persistence reconstruction for the higher-value MAC roots that previously sat inside the HSM long-term. - **A digital-asset custodian on MPC** augments the existing MPC cluster with zero-persistence reconstruction so that the share-store stops being the multi-year target while the operational shape of the platform stays the same. - **A new fintech with no legacy** skips the HSM-cluster build-out and starts on zero-persistence reconstruction with a small recovery-agent quorum, sized to the workload from day one. ## Related Lokblok material - [Phantom Secrets™ as a layer over existing HSMs](https://www.lokblok.co/solutions/hsm-providers) - [the underlying threshold-reconstruction architecture](https://www.lokblok.co/architecture) - [Toughkey™ as the certified secure element](https://www.lokblok.co/products/toughkey) ## FAQ ### When is an HSM still the right answer? When the workload requires extremely low-latency symmetric operations at line rate, when standards mandate a specific certified module, or when integration cost into legacy systems makes anything else uneconomic. The HSM remains the right choice for those workloads, and zero-persistence reconstruction can sit alongside it for the keys that do not need to persist. ### Is MPC custody obsolete? No. MPC custody is a meaningful improvement over single-operator key storage and a fit for institutional governance models. The honest framing is that MPC distributes a custody problem; zero-persistence reconstruction removes one. Mature programs often run both during a multi-year migration. ### Can I run zero-persistence reconstruction on an existing HSM? Yes. Phantom Secrets™ runs as a software layer on top of FIPS-certified secure elements, including HSMs from major vendors. The HSM remains the certified hardware boundary; the runtime layer adds the zero-persistence behaviour on top. ### What does the migration path look like? Identify the keys that genuinely need to persist (rare) and the keys that only need to exist at the moment of use (most). Move the latter to zero-persistence reconstruction in a parallel path, validate the operational and audit shape, then ramp down the persistent equivalents. The HSM and MPC investments are not wasted, they continue to serve the operations that need them. ## Related insights - [Alternatives to MPC custody: when threshold key shares are still keys](https://www.lokblok.co/insights/alternatives-to-mpc-custody) - [Post-quantum key management: why algorithms aren't enough](https://www.lokblok.co/insights/post-quantum-key-management) --- # Payment system key architecture: removing keys-at-rest from the chain > Payment cryptography concentrates risk in a long-lived ZMK/ZPK hierarchy. A zero-persistence runtime adds per-operation reconstruction without disturbing the certified HSM substrate underneath. *Primary query: payment HSM modernisation. Last updated 2026-04-22.* Payment cryptography is one of the oldest and best-engineered key-management domains: zone master keys, zone PIN keys, derivation hierarchies, and certified payment HSMs are all decades-mature. They are also, structurally, a very large estate of stored, long-lived keys, exactly the kind of estate that grows in value as a target and gets harder to retire as it ages. Zero-persistence reconstruction adds per-operation key derivation without disturbing the HSM substrate underneath. ## How payment key estates accumulate risk Issuer and acquirer environments rely on a key hierarchy: master keys (LMK/ZMK), zone keys (ZPK/ZAK), working keys for PIN translation, MAC, and derivation. Each layer is a long-lived, certified-HSM-protected secret. The certifications (PCI HSM, FIPS 140-3) are real and necessary; they describe how the keys are protected, not whether the keys need to exist. The estate grows monotonically. Every new acquirer relationship adds zone keys; every key rotation creates an overlap window with both old and new keys present; every legacy scheme adds derivation keys that cannot be retired without coordinated migration. The net effect is an ever-larger set of long-lived secrets concentrated in HSM clusters. Modernisation programs (PCI HSM v3, post-quantum readiness, cloud HSM migration) all run into the same wall: the keys outlive the projects that try to refactor them. ## Per-operation derivation on top of the certified substrate Zero-persistence reconstruction does not replace payment HSMs, it runs on top of them. The certified secure element remains the hardware root; the runtime layer derives the working key inside the element only at the instant of use, performs the PIN translation or MAC, and destroys the working key before returning. The persistent inventory shrinks to the public Regen Token material; the certified hardware still bounds the cryptographic operation. For PCI scope and certification, the substrate is unchanged. For risk and modernisation, the long-lived working-key estate disappears, taking with it the multi-year migration burden and the HNDL exposure of the symmetric working keys. ## Side by side | Dimension | Conventional approach | Zero-persistence reconstruction | | --- | --- | --- | | Working keys at rest | Held in HSM clusters across the estate | Derived on demand; nothing persists | | Key rotation | Coordinated across acquirers and issuers | Per-operation derivation makes rotation a runtime parameter | | PCI HSM substrate | Required and used | Required and used (unchanged) | | Quantum migration of working keys | Estate-wide rotation project | Runtime algorithm swap | | Audit | Per-key inventory | Per-operation cryptographic chain | ## What this looks like in practice - **An acquirer with hundreds of zone-key pairs** stops maintaining the bulk of the working-key inventory by deriving zone working keys per transaction inside the existing HSM fleet. - **An issuer modernising its card platform** treats the new BIN as a clean greenfield, no working keys to provision, no rotation calendar, and migrates legacy BINs over time. - **A processor preparing for PCI HSM v3 + PQ readiness** addresses both with one architectural move: per-operation derivation removes the long-lived estate that v3 and PQ migration would otherwise have to refactor. ## Related Lokblok material - [the payments solution overview](https://www.lokblok.co/solutions/payments) - [Phantom Secrets™ as a runtime layer for any HSM substrate](https://www.lokblok.co/solutions/hsm-providers) - [the underlying threshold-reconstruction architecture](https://www.lokblok.co/architecture) ## FAQ ### Does this break PCI HSM certification? No. PCI HSM certifies the secure element and its operational profile. Zero-persistence reconstruction runs cryptographic operations inside the certified element exactly as the certification expects. The change is in what persists between operations, not in how the operation itself is performed. ### What about latency at acquirer line rates? Per-operation derivation adds the threshold reconstruction step inside the secure element. For modern HSMs and well-placed recovery agents this is sub-millisecond for the cryptographic step plus the network round-trip to the quorum; in many deployments the quorum is co-located with the issuer or acquirer and the added latency is negligible relative to the message envelope. ### How does this interact with existing key-block standards (TR-31, ASC X9.143)? Key blocks are an interchange format for keys that are exchanged between parties. Zero-persistence reconstruction reduces the population of keys that need to be exchanged in the first place; the working keys are derived locally on demand. Where key blocks remain necessary (e.g. for legacy partner integration), they can be produced on demand from the same primitive. ### Can this run alongside an existing payment HSM estate during migration? Yes, and that is the common adoption shape. The runtime layer is introduced for new BINs, new acquirer integrations, or specific high-value working-key categories first; the existing HSM estate continues to serve traffic during the migration period and ramps down as workloads move over. ## Related insights - [HSM vs MPC vs zero-persistence: a decision framework](https://www.lokblok.co/insights/hsm-vs-mpc-vs-zero-persistence) - [Post-quantum key management: why algorithms aren't enough](https://www.lokblok.co/insights/post-quantum-key-management) --- # Phantomizing *Category: Phantom Secrets™.* The full process of converting a persistent secret into a phantom secret that never exists at rest. Secrets are destroyed and only regenerated inside certified hardware when needed. **Read more:** [/architecture](https://www.lokblok.co/architecture) ## Related terms in Phantom Secrets™ - [Regen Tokens](https://www.lokblok.co/glossary/regen-tokens) - [Ephemeral](https://www.lokblok.co/glossary/ephemeral) - [Toughkey™](https://www.lokblok.co/glossary/toughkey) - [Multi-Party Computation (MPC)](https://www.lokblok.co/glossary/multi-party-computation) - [Threshold Secret Sharing (TSShr)](https://www.lokblok.co/glossary/threshold-secret-sharing) - [Threshold Signature Scheme (TSSig)](https://www.lokblok.co/glossary/threshold-signature-scheme) - [Hierarchical Signatures](https://www.lokblok.co/glossary/hierarchical-signatures) - [Business-Logic-Enforced Cryptography](https://www.lokblok.co/glossary/business-logic-enforced-cryptography) [← Back to glossary](https://www.lokblok.co/glossary) --- # Regen Tokens *Category: Phantom Secrets™.* A step within phantomizing where encrypted secret shards are replaced with harmless Regen Tokens. These act like signposts — pointing to where a secret could be reconstituted, but carrying no value if stolen. **Read more:** [/products/phantom-secrets](https://www.lokblok.co/products/phantom-secrets) ## Related terms in Phantom Secrets™ - [Phantomizing](https://www.lokblok.co/glossary/phantomizing) - [Ephemeral](https://www.lokblok.co/glossary/ephemeral) - [Toughkey™](https://www.lokblok.co/glossary/toughkey) - [Multi-Party Computation (MPC)](https://www.lokblok.co/glossary/multi-party-computation) - [Threshold Secret Sharing (TSShr)](https://www.lokblok.co/glossary/threshold-secret-sharing) - [Threshold Signature Scheme (TSSig)](https://www.lokblok.co/glossary/threshold-signature-scheme) - [Hierarchical Signatures](https://www.lokblok.co/glossary/hierarchical-signatures) - [Business-Logic-Enforced Cryptography](https://www.lokblok.co/glossary/business-logic-enforced-cryptography) [← Back to glossary](https://www.lokblok.co/glossary) --- # Ephemeral *Category: Phantom Secrets™.* The property of a regenerated secret. It exists only for the briefest moment to perform its task, then is immediately destroyed — leaving nothing to store or steal. **Read more:** [/features/private-keys](https://www.lokblok.co/features/private-keys) ## Related terms in Phantom Secrets™ - [Phantomizing](https://www.lokblok.co/glossary/phantomizing) - [Regen Tokens](https://www.lokblok.co/glossary/regen-tokens) - [Toughkey™](https://www.lokblok.co/glossary/toughkey) - [Multi-Party Computation (MPC)](https://www.lokblok.co/glossary/multi-party-computation) - [Threshold Secret Sharing (TSShr)](https://www.lokblok.co/glossary/threshold-secret-sharing) - [Threshold Signature Scheme (TSSig)](https://www.lokblok.co/glossary/threshold-signature-scheme) - [Hierarchical Signatures](https://www.lokblok.co/glossary/hierarchical-signatures) - [Business-Logic-Enforced Cryptography](https://www.lokblok.co/glossary/business-logic-enforced-cryptography) [← Back to glossary](https://www.lokblok.co/glossary) --- # Toughkey™ *Category: Phantom Secrets™.* Certified hardware (FIPS / Common Criteria smartcard or USB form factor) that anchors Phantom Secrets in a tamper-resistant environment. Binds identity to device and ensures secrets are only ever reconstructed inside hardware. **Read more:** [/products/toughkey](https://www.lokblok.co/products/toughkey) ## Related terms in Phantom Secrets™ - [Phantomizing](https://www.lokblok.co/glossary/phantomizing) - [Regen Tokens](https://www.lokblok.co/glossary/regen-tokens) - [Ephemeral](https://www.lokblok.co/glossary/ephemeral) - [Multi-Party Computation (MPC)](https://www.lokblok.co/glossary/multi-party-computation) - [Threshold Secret Sharing (TSShr)](https://www.lokblok.co/glossary/threshold-secret-sharing) - [Threshold Signature Scheme (TSSig)](https://www.lokblok.co/glossary/threshold-signature-scheme) - [Hierarchical Signatures](https://www.lokblok.co/glossary/hierarchical-signatures) - [Business-Logic-Enforced Cryptography](https://www.lokblok.co/glossary/business-logic-enforced-cryptography) [← Back to glossary](https://www.lokblok.co/glossary) --- # Multi-Party Computation (MPC) *Category: Phantom Secrets™.* A cryptographic process where multiple parties jointly compute on a secret without any one party seeing the whole secret. In Phantom Secrets, recovery agents regenerate temporary secret shares, which are recombined inside a Toughkey to produce a usable private key for signing or encryption. The key exists only ephemerally, then is destroyed — ensuring nothing persists at rest. **Read more:** [/insights/alternatives-to-mpc-custody](https://www.lokblok.co/insights/alternatives-to-mpc-custody) ## Related terms in Phantom Secrets™ - [Phantomizing](https://www.lokblok.co/glossary/phantomizing) - [Regen Tokens](https://www.lokblok.co/glossary/regen-tokens) - [Ephemeral](https://www.lokblok.co/glossary/ephemeral) - [Toughkey™](https://www.lokblok.co/glossary/toughkey) - [Threshold Secret Sharing (TSShr)](https://www.lokblok.co/glossary/threshold-secret-sharing) - [Threshold Signature Scheme (TSSig)](https://www.lokblok.co/glossary/threshold-signature-scheme) - [Hierarchical Signatures](https://www.lokblok.co/glossary/hierarchical-signatures) - [Business-Logic-Enforced Cryptography](https://www.lokblok.co/glossary/business-logic-enforced-cryptography) [← Back to glossary](https://www.lokblok.co/glossary) --- # Threshold Secret Sharing (TSShr) *Category: Phantom Secrets™.* The foundational method of splitting a secret into multiple parts (shares), where only a defined threshold (e.g. 2 of 3) can reconstitute it. In traditional systems, shares are stored and later recombined. In Lokblok, shares are never stored: they are generated, recovered as needed, and destroyed immediately after use. This makes Threshold Secret Sharing the generic base concept underpinning Phantom Secrets, MPC, and Threshold Signature Schemes. **Read more:** [/architecture](https://www.lokblok.co/architecture) ## Related terms in Phantom Secrets™ - [Phantomizing](https://www.lokblok.co/glossary/phantomizing) - [Regen Tokens](https://www.lokblok.co/glossary/regen-tokens) - [Ephemeral](https://www.lokblok.co/glossary/ephemeral) - [Toughkey™](https://www.lokblok.co/glossary/toughkey) - [Multi-Party Computation (MPC)](https://www.lokblok.co/glossary/multi-party-computation) - [Threshold Signature Scheme (TSSig)](https://www.lokblok.co/glossary/threshold-signature-scheme) - [Hierarchical Signatures](https://www.lokblok.co/glossary/hierarchical-signatures) - [Business-Logic-Enforced Cryptography](https://www.lokblok.co/glossary/business-logic-enforced-cryptography) [← Back to glossary](https://www.lokblok.co/glossary) --- # Threshold Signature Scheme (TSSig) *Category: Phantom Secrets™.* A form of MPC where the private key is never reconstructed at all. Instead, each participant produces a partial signature, and these are combined to form a complete digital signature. Unlike Phantom Secrets (where shares recombine inside a Toughkey), in TSSig the key never exists even ephemerally — only the final signature does. Lokblok implements TSSig directly in certified hardware, making it far stronger than software-only schemes. **Read more:** [/architecture](https://www.lokblok.co/architecture) ## Related terms in Phantom Secrets™ - [Phantomizing](https://www.lokblok.co/glossary/phantomizing) - [Regen Tokens](https://www.lokblok.co/glossary/regen-tokens) - [Ephemeral](https://www.lokblok.co/glossary/ephemeral) - [Toughkey™](https://www.lokblok.co/glossary/toughkey) - [Multi-Party Computation (MPC)](https://www.lokblok.co/glossary/multi-party-computation) - [Threshold Secret Sharing (TSShr)](https://www.lokblok.co/glossary/threshold-secret-sharing) - [Hierarchical Signatures](https://www.lokblok.co/glossary/hierarchical-signatures) - [Business-Logic-Enforced Cryptography](https://www.lokblok.co/glossary/business-logic-enforced-cryptography) [← Back to glossary](https://www.lokblok.co/glossary) --- # Hierarchical Signatures *Category: Phantom Secrets™.* An extension of MPC/TSS that enforces real-world business logic in the cryptography itself. Instead of simple thresholds (e.g. 'any 2 of 3'), signatures can require specific roles or conditions (e.g. CFO + CEO + Compliance Officer for large transactions). These rules are cryptographically binding, preventing spoofing, insider abuse, or collusion. Lokblok refers to this as business-logic-enforced cryptography. **Read more:** [/features/hierarchical-signatures](https://www.lokblok.co/features/hierarchical-signatures) ## Related terms in Phantom Secrets™ - [Phantomizing](https://www.lokblok.co/glossary/phantomizing) - [Regen Tokens](https://www.lokblok.co/glossary/regen-tokens) - [Ephemeral](https://www.lokblok.co/glossary/ephemeral) - [Toughkey™](https://www.lokblok.co/glossary/toughkey) - [Multi-Party Computation (MPC)](https://www.lokblok.co/glossary/multi-party-computation) - [Threshold Secret Sharing (TSShr)](https://www.lokblok.co/glossary/threshold-secret-sharing) - [Threshold Signature Scheme (TSSig)](https://www.lokblok.co/glossary/threshold-signature-scheme) - [Business-Logic-Enforced Cryptography](https://www.lokblok.co/glossary/business-logic-enforced-cryptography) [← Back to glossary](https://www.lokblok.co/glossary) --- # Business-Logic-Enforced Cryptography *Category: Phantom Secrets™.* The principle behind hierarchical signatures: organisational policies (who must sign, under what conditions) are not just workflow rules but cryptographically required. If the right people don't sign, the secret simply cannot be recovered. **Read more:** [/features/hierarchical-signatures](https://www.lokblok.co/features/hierarchical-signatures) ## Related terms in Phantom Secrets™ - [Phantomizing](https://www.lokblok.co/glossary/phantomizing) - [Regen Tokens](https://www.lokblok.co/glossary/regen-tokens) - [Ephemeral](https://www.lokblok.co/glossary/ephemeral) - [Toughkey™](https://www.lokblok.co/glossary/toughkey) - [Multi-Party Computation (MPC)](https://www.lokblok.co/glossary/multi-party-computation) - [Threshold Secret Sharing (TSShr)](https://www.lokblok.co/glossary/threshold-secret-sharing) - [Threshold Signature Scheme (TSSig)](https://www.lokblok.co/glossary/threshold-signature-scheme) - [Hierarchical Signatures](https://www.lokblok.co/glossary/hierarchical-signatures) [← Back to glossary](https://www.lokblok.co/glossary) --- # ToughID™ *Category: Secure Terminal™.* A Lokblok identity specification that orchestrates KYC, verification, and recovery processes across multiple parties, using tokenised data and hardware-based attestations to prove each step without exposing sensitive information. **Read more:** [/products/toughid](https://www.lokblok.co/products/toughid) ## Related terms in Secure Terminal™ - [Phantom Gate™](https://www.lokblok.co/glossary/phantom-gate) - [Secure Terminal™ Encrypted Local Storage](https://www.lokblok.co/glossary/secure-terminal-encrypted-local-storage) [← Back to glossary](https://www.lokblok.co/glossary) --- # Phantom Gate™ *Category: Secure Terminal™.* A stealth-mode access service formerly called Phantom Secrets Knock Knock Protocol. Keeps applications and servers invisible until an authenticated sequence is performed with a Toughkey™. Reduces the attack surface to near zero, extending Zero Trust ('Never Trust, Always Verify') into the service layer itself. Requires Secure Terminal™. **Read more:** [/products/phantom-gate](https://www.lokblok.co/products/phantom-gate) ## Related terms in Secure Terminal™ - [ToughID™](https://www.lokblok.co/glossary/toughid) - [Secure Terminal™ Encrypted Local Storage](https://www.lokblok.co/glossary/secure-terminal-encrypted-local-storage) [← Back to glossary](https://www.lokblok.co/glossary) --- # Secure Terminal™ Encrypted Local Storage _(Coming Soon)_ *Category: Secure Terminal™.* An enhancement to Secure Terminal™ that allows encrypted files to be kept entirely local on the user's device instead of being pushed to cloud storage. Users can optionally sync their encrypted files to services like OneDrive or Dropbox, but Lokblok itself never handles the raw file. **Read more:** [/products/secure-terminal](https://www.lokblok.co/products/secure-terminal) ## Related terms in Secure Terminal™ - [ToughID™](https://www.lokblok.co/glossary/toughid) - [Phantom Gate™](https://www.lokblok.co/glossary/phantom-gate) [← Back to glossary](https://www.lokblok.co/glossary) --- # Lokbox *Category: Standalone / Infrastructure.* Lokblok's secure cloud storage system (formerly Toughcloud) that shards and encrypts data across decentralised storage providers, with the customer retaining sole control of encryption keys. This design eliminates single points of compromise in cloud environments. Available today via S3-compatible APIs. **Read more:** [/solutions/data-sovereignty](https://www.lokblok.co/solutions/data-sovereignty) [← Back to glossary](https://www.lokblok.co/glossary) --- # Middleware *Category: Core Principles.* In Lokblok, middleware refers to two related layers. First, Lokblok's platform role: operating as an invisible, cloud-based security layer between existing applications and cryptographic hardware. Institutions integrate via APIs and SDKs, while end users never see Lokblok directly. Second, at the component level: the client-side and server-side software libraries that handle communication with Toughkey™s, Secure Terminal™, and other Lokblok modules. By design, Lokblok spans both senses — a SaaS middleware platform that delivers security as a service, and a set of middleware components that connect applications to certified hardware. **Read more:** [/architecture](https://www.lokblok.co/architecture) ## Related terms in Core Principles - [Zero Trust](https://www.lokblok.co/glossary/zero-trust) [← Back to glossary](https://www.lokblok.co/glossary) --- # Zero Trust *Category: Core Principles.* The principle 'Never Trust, Always Verify.' Lokblok applies this to every layer: users, devices, networks, applications, and secrets. Nothing is assumed safe; everything must prove trustworthiness in real time. **Read more:** [/insights/zero-trust-key-management](https://www.lokblok.co/insights/zero-trust-key-management) ## Related terms in Core Principles - [Middleware](https://www.lokblok.co/glossary/middleware) [← Back to glossary](https://www.lokblok.co/glossary)