The most defensible place to keep a cryptographic key is inside the chip that uses it, never exposed to software at all. Move the key off-die — into firmware, into the OS, into a config file — and you have multiplied the ways it can leak. On-die key management is the hardware-security ideal: the secret is born, lives, and is used inside silicon that resists physical extraction.

US12113786B2, “Secure feature and key management in integrated circuits,” granted to Cryptography Research, Inc. on October 8, 2024, claims exactly that on-chip discipline. Classified under G06F 21/71 (protecting hardware) with a stack of key-management codes, it covers managing keys and securely enabling chip features on the silicon.

“A mechanism for providing secure feature and key management in integrated circuits is described.”— U.S. Patent No. 12,113,786 source

The independent claim describes a concrete on-die architecture, not a generic “secure chip.” Claim 1 recites an integrated circuit with a secure memory storing a “base key,” a “security manager (SM) core,” a plurality of hardware features the SM core can configure, and a “hardware extractor” coupling the two. The flow is: the SM core receives “feature update information comprising a command” that, when executed, can set a hardware feature to be “locked, unlocked, or modified”; the SM core derives a “transport key” from the base key; it decrypts an encrypted payload carried with the command using that transport key; and the hardware extractor routes the decrypted payload to the targeted features. So the base key never leaves the secure memory — it is used to derive a transport key, and only the transport key touches the payload.

The key-derivation chain is deliberately layered, which is the side-channel-aware part. Claim 2 inserts an intermediate step: the SM core “derives a mixed key using the base key” and then “derives the transport key using the mixed key.” That extra hop means the long-lived base key is not used directly to decrypt attacker-supplied payloads, limiting how much an adversary observing one transport operation can learn about the root secret. Claim 6 adds that a value in the chip's “feature space” can control “whether the base key is available for use” at all — an on-die kill switch for the root key.

The signature side is equally explicit. Claim 13 requires the feature command to arrive as a “digitally signed message” signed by “a private key associated with a root authority,” which the SM core verifies “using a public key associated with the root authority… stored in a secure memory.” Claim 14 extends this to a delegate authority, and claim 15 spells out the delegation check: the SM core obtains the delegate's permissions and public key “from a root signed block signed by a root authority,” verifies the message under the delegate key, and then confirms “the command is permitted using the delegate permissions.” That is a full root-of-trust hierarchy — root authority delegating scoped signing power to delegates — enforced inside the chip before any feature is touched.

The “feature management” half of the claim is the commercially clever part. Claim 7 ties a feature-space value to “geographical information,” used “to control authorization of the integrated circuit in a specified geographical region” — region-locking enforced cryptographically on the die. Claim 11 has the SM core, on executing a command, “deliver one or more keys to one or more components” for “encryption operations… digital rights management operations… password management… or authentication.” Modern chips ship with capabilities that vendors want to enable, disable, or license selectively, and doing that securely requires the same cryptographic machinery as key management: authenticated, tamper-resistant control over what the silicon will and will not do. Binding feature enablement to on-chip keys ties the business model to the hardware root of trust.

The internal decomposition of the SM core, disclosed in claim 9, shows how seriously the architecture takes separation of duties even inside a single chip. The SM core is recited as comprising distinct modules: “a crypto module to verify the signature of the digitally signed message; an execution engine module to execute the command; a communications module to facilitate communications by the SM core; and a data storage module to manage internal storage… and to interface with a secure memory.” Verification, execution, communication, and storage are split into separate functional blocks rather than collapsed into one — which limits how far a fault in any one block can reach. Claim 16, a third independent claim, ties the whole flow together in its strongest form: a secure memory storing a secret key, an SM core that verifies the signature “using the secret key,” derives a transport key from a base key “stored in the secure memory,” decrypts the encrypted payload with the transport key, and routes the result through the hardware extractor. Claim 17 then adds “sub-extractors,” each bound to one hardware feature, so the decrypted payload is delivered only to the specific feature it authorizes — least privilege enforced at the wire level.

The inventor line is worth pausing on: Paul Kocher is among the names. Kocher is one of the most consequential figures in applied hardware security — differential power analysis, SSL/TLS work, later co-discovery of Spectre. A key-management-on-chip patent from his group carries the presumption of being grounded in deep side-channel and hardware-attack realism, and the layered base-key/mixed-key/transport-key derivation in the claims reads exactly like a construction designed to minimize what a power or timing analysis can extract.

Per the desk's rules: issued grant (B2), not an application; a hardware-method claim, not a product announcement. Cryptography Research (now part of Rambus) licenses exactly this kind of hardware-security IP widely, which is the commercial context — their business is being licensed into other people's chips.

For the reader mapping the field, this is a reminder that key management is not only a cloud and software problem. At the bottom of the stack, the question is where a key physically lives, and the most durable answer — inside tamper-resistant silicon, never exposed, used only through derived transport keys under a signed, delegable root of trust — has its own dense, expert patent landscape that everything above it ultimately rests on.