Invention Disclosure: Attested Key-Pair Generation with "Key Escrow"

The following public posting is intended to function as a record of an invention disclosure where the inventor gives up any IPR claims as well as hoping that the described invention is not already filed as a patent application.

A PDF version is currently available at:
http://webpki.org/papers/keygen2/keygen2-key-escrow.pdf

Attested Key-Pair Generation with Key "Escrow"

Occasionally credential issuers want (or require) that encryption private keys are backuped in order to be able to restore data (AKA "key escrow") in case an encryption-key is lost or is replaced.

This document shows how KeyGen2's key-attestation scheme has been augmented by an end-to-end-secured escrow mechanism as well. The concept is as follows: An issuer sends a key-generation request to a client presumably having an SE (Security Element) for keeping user-keys in. The SE responds with attested public keys where each attest consists of a signature over the generated public key, key-usage, key-exportability, and a nonce, using an embedded SE device-key as an attestation signature key.

By also including a key-escrow public key (supplied by the issuer during the request), in the attest signature hash, the issuer gets a cryptographically strong evidence enabling it to detect if something in the transport layer or in the SE middleware temporarily swapped the escrow-key in order to steal the private key and then changed it back to cover-up the operation.

A prerequisite for this to be trustworthy is that the entire operation (key-pair generation, private-key escrow-key encryption, and device-key attest-signing) is carried out inside of the SE in a fully atomic fashion. In addition to successful signature validation, the issuer (of course) also has to recognize and trust the SE device type identified by the public key certificate received in the response.

For details on the original key-attestation scheme see:
http://webpki.org/papers/keygen2/keygen2-fips140-2.pdf

Note that although the referred document exploits KeyGen2's DIAS (Device Internal Attestation Signature) single device-key scheme, the core principle is equally applicable to designs relying on separate device-keys for attestations, authentications, and encryptions performed by an SE.

Request Phase

The following is a slightly simplified version of a KeyGen2 key generation request where the issuer asks for two keys; an encryption key with escrow and an authentication without escrow (actually KeyGen2 only allows escrow for encryption keys).

<KeyOperationRequest ... >
<CreateObject>

    <KeyPair ID="Key.1" KeyUsage="encryption">
      <RSA KeySize="2048"/>
      <EscrowKey>
        <ds:X509Data>
          <ds:X509Certificate>MIIB2 ... FLlck8SX</ds:X509Certificate>
        </ds:X509Data>
      </EscrowKey>
    </KeyPair>

    <KeyPair ID="Key.2" KeyUsage="authentication">
      <RSA KeySize="2048"/>
    </KeyPair>

</CreateObject>
</KeyOperationRequest>

Response Phase

Below is a condensed version of the anticipated KeyGen2 response. The only thing that differs from a regular KeyGen2 response is the element EncryptedPrivateKey which contains a copy of the generated private key in PKCS #8 PrivateKeyInfo format, wrapped by a 128-bit random AES key, which in turn is wrapped by the issuer-supplied escrow public key. The EndorsementKey contains the device public key as well as an enveloped signature over the entire response.

<KeyOperationResponse ... >

<GeneratedPublicKey ID="Key.1" KeyAttestation="H8USg ... ZixaYVw==">
    <ds:KeyInfo>
      <ds:KeyValue>
        <ds:RSAKeyValue>
          <ds:Modulus>AKu4uVZ8 ... 4mjS422CqxwAt</ds:Modulus>
          <ds:Exponent>AQAB</ds:Exponent>
        </ds:RSAKeyValue>
      </ds:KeyValue>
    </ds:KeyInfo>
    <EncryptedPrivateKey Format="http://xmlns.webpki.org/keygen2/1.0#format.pkcs8">
      <xenc:EncryptedKey>
        <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
        <ds:KeyInfo>
          <ds:KeyName>Key.1.Private</ds:KeyName>
        </ds:KeyInfo>
        <xenc:CipherData>
          <xenc:CipherValue>mWi94IJ ... Xk/HbWM2o=</xenc:CipherValue>
        </xenc:CipherData>
      </xenc:EncryptedKey>
      <xenc:EncryptedKey>
        <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
        <xenc:CipherData>
          <xenc:CipherValue>RbDx5WbN ... D3GjL7qIhD59s=</xenc:CipherValue>
        </xenc:CipherData>
        <xenc:CarriedKeyName>Key.1.Private</xenc:CarriedKeyName>
      </xenc:EncryptedKey>
    </EncryptedPrivateKey>
  </GeneratedPublicKey>

<GeneratedPublicKey ID="Key.2" KeyAttestation="k6QN ... dUpyTA==">
    <ds:KeyInfo>
      <ds:KeyValue>
        <ds:RSAKeyValue>
          <ds:Modulus>AIOwQTj ... Dfi2WeJLQ2k=</ds:Modulus>
          <ds:Exponent>AQAB</ds:Exponent>
        </ds:RSAKeyValue>
      </ds:KeyValue>
    </ds:KeyInfo>
</GeneratedPublicKey>

<EndorsementKey KeyAttestationAlgorithm="http://xmlns.webpki.org/keygen2/1.0#algorithm.key-attestation-1">
    <ds:Signature>
          .
          .
    </ds:Signature>
</EndorsementKey>

</KeyOperationResponse

Anders Rundgren