Patents Wiki
Back to briefings
PatentCryptography

The Double-Key Dispatch

If you want to lose a hundred dollars' worth of Bitcoin, lose your seed phrase. If you want to lose a billion dollars' worth, run a custodial bank. The two failure modes are not the same, and the second one is what a freshly granted Citibank patent, US12506619B1, is trying to make harder.

The patent is titled "Controlling access to cryptographic resources using double encryption" and was issued December 23, 2025. Its argument is simple to state. A user's blockchain private key is never held in a single, directly usable form. The key is split into shards, wrapped in a second, hardware-managed layer of encryption, and stored in an ordinary database. The key can therefore be both recoverable and never exposed, which is the trick custodians have been trying to pull off for the better part of a decade.

What follows is a walk through the twenty issued claims, how the cryptography hangs together, and what the patent does and does not prove about where institutional crypto custody is going.

The patent at a glance

  • Patent / publication number: US12506619B1
  • Title: Controlling access to cryptographic resources using double encryption
  • Assignee: Citibank, N.A.
  • Inventors: Biser Dimitrov; Boaz Bechar
  • Application number: US 19/287,737
  • Filing date: 2025-07-31
  • Grant / publication date: 2025-12-23
  • Anticipated expiration: 2045-07-31
  • Independent claims: 3 (system, method, computer-readable medium)
  • Dependent claims: 17
  • CPC classes of note: H04L9/32 (digital signatures), H04L9/085 (secret sharing / threshold), H04L9/0894 (key escrow / storage), H04L9/50 (blockchains / hash chains), H04L2209/56 (financial cryptography)
  • Source: USPTO granted patent record, mirrored on Google Patents

The Custody Conundrum

If you own a single Bitcoin, the custody question is almost quaint: any software wallet will do. The worst case is you lose a hundred dollars. If you are a bank holding client Bitcoin in the billions, the question becomes existential.

A private key is, mathematically, a very large number. The whole system runs on public-key cryptography, where each user holds a matched pair: a private key kept secret and used to sign, and a public key derived from it and shared with the world for verification. Whoever knows the private key can move the funds, irreversibly. There is no "forgot password" link. The whole point of a public blockchain is that the signature, not the institution, is the authority.

That makes the custody problem simple on paper and brutal in practice. There are two ways to hold a private key, and they sit on opposite ends of a spectrum:

  • Cold storage. The key lives on a device that is physically disconnected from every network, ideally in a vault, signed in and signed out by named custodians under multi-party approval. A cold key can be stolen only by physically breaching the vault. It can also be used only by physically bringing it online, which is slow, expensive, and audit-heavy. For a custodian processing thousands of transactions a day, cold storage is the equivalent of a safety-deposit box that requires three managers, two keys, and a 24-hour waiting period.
  • Hot storage. The key lives on a network-connected server, ready to sign at machine speed. Hot keys are fast and convenient. They are also catastrophically vulnerable: if the server is compromised, the key is gone, and so are the funds.

The patent's BACKGROUND section names this trade-off, then adds a third constraint that most casual readers miss: jurisdictional fragmentation. A global custodian has to store and process client assets in different physical locations to satisfy local data-residency and sanctions rules. A Brazilian client's key data should sit in a Brazilian database; a Chinese client's key data should sit in a Chinese one. The hard problem is doing all of that while still running a signing service that has to stay online.

A Key Wrapped in Two Coats

The core idea is best understood as an onion, or a coat over a coat. A user's blockchain private key is broken into pieces, and the bundle of pieces is then wrapped in a second, independent layer of encryption. Neither layer alone is enough to recover a usable key. You need to peel back both, in the right order, with the right hardware, to produce a single signature.

The two layers are managed by two different kinds of specialized hardware, and that distinction is the whole point.

The inner layer: multi-party computation

The inner layer is handled by a multi-party computation (MPC) cluster. MPC is a family of cryptographic protocols in which a group of computers jointly compute a function over their private inputs without ever pooling those inputs in one place. The computers cooperate on a calculation that no single one of them can see in full.

In this patent, that calculation is the production of a single digital signature, and the private inputs are key shares that never reassemble into the full key. The key is generated as a set of shares, one per MPC node, with a property that any threshold tt of the nn shares can be combined to reconstruct the key, but no smaller number reveals anything about it.

That property has a name. A (t,n)(t, n)-threshold scheme is one in which a secret is split into nn pieces such that any tt of them suffice to reconstruct it, but any t−1t - 1 of them leak no information at all.

The construction that turns this idea into working code is Shamir's secret sharing, a 1979 scheme by Adi Shamir that rests on a piece of algebra most readers will recognize from school. A polynomial of degree t−1t - 1 is uniquely determined by tt of its values, and t−1t - 1 values are consistent with every possible secret. Pick such a polynomial at random, set the secret equal to the constant term f(0)f(0), and hand out f(1),f(2),…,f(n)f(1), f(2), \ldots, f(n) as the shares. Any tt shares pin down the polynomial uniquely and recover the secret. t−1t - 1 shares reveal nothing.

In the patent, every MPC node encrypts its own share with a key that lives only on that node, and the encrypted shares together form the "MPC layer" of the bundle. The cleartext key never exists on a single machine. It exists only ephemerally, while the shares recombine to produce a signature.

The outer layer: the hardware security module

The outer layer is handled by a hardware security module (HSM). An HSM is a dedicated, tamper-resistant hardware appliance, often a rack-mounted box with specialized chips and physical anti-tamper mechanisms, whose entire purpose is to hold cryptographic keys and to perform encrypt, decrypt, and sign operations on them without ever exposing the cleartext to the host computer it is plugged into.

In this patent, the HSM does not hold the user keys directly. The HSM generates its own key, uses that key to encrypt the entire bundle of MPC-encrypted shares, and hands the doubly-encrypted bundle back to the system. That doubly-encrypted blob is what gets persisted, in a regular database, indexed by the user's identifier.

The result is a small, opaque record that looks like random noise to anyone who reads it. To turn it into a usable signature, an attacker would have to defeat the HSM's hardware protection and compromise enough MPC nodes to recombine the shares, and do it in a window small enough that the signing host has not already torn the in-memory key material down. Two coats, two hardware roots of trust, and no single component holds enough information to act alone.

Core Architecture/Flow

From a Database Row to a Blockchain Signature

The diagram above shows the whole flow in one glance. Reading left to right, the order matters and the claim language depends on it.

Suppose Alice wants to send ten bitcoin to Bob. A transfer request arrives at the custodian's "resource transfer system," carrying Alice's user identifier, the destination address, the amount, and a first signature from an internal verification engine confirming that Alice's authentication, sanctions, and balance checks have all passed.

Step one is a database lookup. The system queries the key vault for Alice's identifier and pulls back the doubly-encrypted blob. This is a row in a relational table. The patent is explicit that the encrypted key does not have to live inside the HSM, which matters in practice because HSM storage is expensive and capacity-limited. The "encrypted key object" is a normal data record.

Step two is the first peel. The doubly-encrypted blob is shipped over a private network to the HSM. The HSM applies its hardware-resident decryption key and returns the inner layer: a set of MPC-encrypted shares. The HSM never sees a complete key. It only ever sees the outer layer come off.

Step three is the second peel, distributed across the MPC cluster. Each share is routed to the MPC node that originally encrypted it. That node decrypts its own share with its locally stored key, uses the cleartext share to compute a partial signature, and returns the partial.

The math, for the curious, looks like this in an ECDSA-style scheme. ECDSA is the Elliptic Curve Digital Signature Algorithm, the workhorse signing scheme used by Bitcoin, Ethereum, and most other major chains. The full private key is a scalar dd, and the public key is the elliptic-curve point P=d⋅GP = d \cdot G, where GG is a fixed generator point on the curve. To sign a message mm, the signer hashes it to H(m)H(m), picks a random nonce kk, and computes r=(k⋅G).xr = (k \cdot G).x along with s=k−1(H(m)+d⋅r) mod ns = k^{-1}(H(m) + d \cdot r) \bmod n, where nn is the curve order. The pair (r,s)(r, s) is the signature, and anyone holding the public key PP can verify it without ever learning dd.

In an MPC-ECDSA scheme, the share held by node ii is did_i, and each node produces a partial sis_i such that the sum ∑isi≡s(modn)\sum_i s_i \equiv s \pmod n. The full signature is recovered without anyone reconstructing dd. The patent is silent on which MPC-ECDSA protocol family is used (GG20, Frost, and Lindell all fit), but the structure is the same: each node produces a partial, no node sees the full key.

Step four is aggregation. The custodian combines the partial signatures into a single (r,s)(r, s) pair. The verification step is just elliptic-curve point addition, and the partial-to-final combination is modular addition, both of which are cheap.

Step five is broadcast. The system builds a blockchain transaction (source address, target address, amount, attached signature), formats it for the destination chain (Bitcoin, Ethereum, or any other secp256k1-curve chain, since the patent is chain-agnostic), and ships it to a node for inclusion in a block.

The cold storage variant

The patent also describes a cold storage variant, in which the signing host has no persistent connection to the HSM at all. A "secure bypass switch" physically toggles the host's network cable between the public internet and an air-gapped internal network (a network with no electronic connection at all to the public internet or to any other outside network) that holds the HSM and MPC nodes. The host pulls a request in from the internet, flips the switch, walks the request into the air gap, gets the signature back, flips the switch again, and broadcasts.

Some embodiments split this into a separate receiver host and sender host, each with its own bypass switch, so that the signing material only ever exists on the air-gapped side for the duration of the signing step. That second embodiment is structurally similar to the offline-signing boxes that cryptocurrency exchanges have been running since the early 2010s. The patent's contribution here is mostly the formal claim language and the integration with the MPC/HSM stack, not the air-gap idea itself.

For account creation, the flow runs in reverse, inside-out. The MPC cluster generates a fresh keypair, splits the private key into shares, encrypts each share on its own node, and ships the bundle to the HSM, which applies the outer layer. The doubly-encrypted blob is then routed to whichever jurisdiction-specific database server matches the user's home country, so a Brazilian user ends up in a Brazilian vault and a Chinese user in a Chinese one.

Reading the Twenty Claims

The patent's twenty issued claims are organized in three independent claims, one for each statutory category, with seventeen dependent claims layering in specifics.

Claim 1 (system) is the heart of the patent. It recites, in order:

  • receive a transfer request carrying a user identifier and a verification-engine signature
  • retrieve a doubly-encrypted key object from a key vault, where the object contains a plurality of encrypted key shards
  • transmit a decryption command to a first security device (the HSM), which strips the outer layer and returns the encrypted shards
  • transmit the encrypted shards plus a signing command to a second security device (the MPC cluster), which routes each shard to the node that encrypted it, and each node produces a corresponding portion of the cryptographic signature
  • assemble those portions into a single signature
  • build a blockchain operation from the request and the signature
  • transmit the operation to a blockchain node

Eight steps, in order, with no step omitted.

Claim 7 (method) is the same eight steps recast as a method claim. Claim 15 (computer-readable medium) is the same eight steps recast as instructions stored on a non-transitory computer-readable medium. These three independent claims give Citibank parallel coverage regardless of how an infringer chooses to implement the flow: as a system they sell, as a method they perform, or as software they ship.

The dependent claims layer in the specifics. Claims 2, 10, and 18 cover the inside-out account creation flow: MPC generates the keypair, each node encrypts its own share, the HSM wraps the result in a second layer, and the doubly-encrypted blob is stored in the key vault. Claims 3 and 11 cover jurisdiction-routed storage, including the specific data fields the system uses to infer the user's jurisdiction (legal documents, profile information, IP address) and the rule that the chosen database server is one of "a plurality of database servers active in a plurality of different jurisdictions." Claims 4 and 12 cover the lookup mechanics: pull the user identifier out of the request, send it to the key vault, receive the encrypted blob back. Claims 5, 13, and 19 cover signature aggregation, with the system receiving a "plurality of portions of the cryptographic signature" and combining them. Claims 6, 14, and 20 cover hash-based signing, where the system hashes the source address, target address, and amount into a single digest and sends the hash to the MPC nodes for signing, rather than passing the raw transaction around.

A few things are absent from the claims. The patent does not specify a particular blockchain, signature algorithm, MPC threshold, or shard count. The word "secp256k1" appears in the description but not in any independent claim. The word "ECDSA" likewise. A competitor who implements the same eight-step flow using BLS signatures, EdDSA, or a post-quantum scheme would still, in principle, fall within the scope of the issued claims, because the claims speak in terms of "cryptographic signature" and "blockchain operation" rather than any specific primitive.

The claims are also narrowly scoped in one specific way. They cover a custodian-managed signing flow. The user's "cryptography-based storage application," in the patent's terminology, is treated as a logical construct the custodian signs on behalf of, not a self-custody wallet in the user's hand. If you generate your own seed phrase and store it on a hardware wallet, you are not practicing the claimed invention. This is a patent on one way a custodian can run its key-management stack, not a patent on cryptography in general.

Why a Bank Cares About Encryption Layers

The grant landed in late December 2025, a few months before this briefing. Citibank has been working on a digital-asset custody offering since around 2022, and is publicly targeting a 2026 launch to serve asset managers, corporates, and high-net-worth clients who want crypto exposure without the operational risk of running their own key stack (see CNBC, American Banker, and CoinDesk from October 2025). The U.S. Office of the Comptroller of the Currency has allowed national banks to custody crypto under certain conditions since Interpretive Letter #1170 in July 2020, so the regulatory runway is in place.

The more interesting reason this patent is worth reading is operational rather than regulatory. Holding a private key inside an HSM is a good security posture, but it does not scale. HSMs are expensive, slow to provision, and capped at relatively small numbers of keys per appliance. Storing encrypted keys in a normal database is cheap, fast, and unbounded in practice, but only safe if the encryption key is somewhere an attacker cannot reach. The patent's contribution is the claim that you can have both: an HSM-protected outer layer plus an MPC-protected inner layer, with the result living in a normal database, indexed like any other row.

If that claim holds up under real-world stress, it lets a custodian build a scale-out key-vault tier that is not bottlenecked on HSM capacity while still inheriting the hardware-rooted trust of the HSM cluster. Combined with jurisdiction-routed storage, it also gives the custodian a clean way to satisfy data-residency rules without spinning up a separate HSM cluster in every country.

The patent does not establish that the architecture has been deployed, benchmarked, audited, or proven secure in production. The claims define a legally protected scope, not a measured result. The granted patent's six patent citations and four non-patent citations are a useful starting point for understanding the prior art the examiner considered, but they are not endorsements of any particular production deployment. Citibank's commercial custody offering is a separate product surface and is not described in this document.

What the Patent Doesn't Tell You

Six caveats are worth keeping in mind.

No performance numbers. There are no claims about signing latency, throughput, cost per signature, MPC round counts, or HSM utilization. Any specific number quoted in a marketing pitch that traces back to this patent would be invented, or would trace to a different document.

No security proof. There is no formal threat model, no reduction to a hard cryptographic assumption, no benchmark against a known adversary. The architectural arguments are descriptive, which is typical for a U.S. utility patent but should not be confused with a security certification.

Chain-agnostic. The description names Bitcoin and Ethereum, but the issued claims are not tied to any specific chain. An implementation would still need to choose key-derivation functions, signature algorithms, and address formats. The patent does not foreclose those choices.

Narrow threat model. The two encryption layers address a specific class of attack. Insider threats, side-channel attacks against the HSM, supply-chain compromise of the bypass switches, and insider collusion at the MPC node operators are all out of scope of the claimed double-encryption flow. A real deployment would need separate mitigations for each.

One routing rule among many. The dependent claims describe picking a database server based on the user's location, but they do not describe sanctions screening, OFAC checks, KYC, transaction monitoring, or any of the other compliance machinery a regulated custodian must run. The patent is one layer of a much larger stack, not the whole stack.

Newly granted, untested in court. The patent is recent enough that we cannot say much about how examiners and competitors will treat it. Six patent citations and four non-patent citations suggest the examiner did meaningful prior-art work, but the legal landscape around MPC-based custody is crowded and shifting. A reader who needs an enforceable, defensible opinion on the patent's validity or scope should consult a patent attorney, not a newsletter.

Sources