Thoughts on escrow of signature keys.

In general, a certificate and private key secured on a smart device can be used for:

  • authentication
  • signature/non-repudiation
  • confidentiality (encryption)

The smart device itself is a dedicated and tamper resistant microcomputer to which the user has only limited access. Most significant is that private keys stored on the device cannot be directly accessed or copied by an external system. All interactions with private keys occur by sending data to the device which then operates on the data and returns the result. The user must enter a PIN before the private key can be used in this way.

Private keys can either be generated on the device (in which case the device holds the only copy) or they can be generated on some other system and copied to the device (where they can't be removed). The former process is used for keys used for signature or authentication in order to support non-repudiation. The latter can be used for encryption keys if an escrow or backup copy is kept.

  • The current system was designed with signature and non-repudiation in mind.
  • Signature/authentication key escrow weakens (if not destroys) non-repudiation.
  • Certificates do not contain the attributes to allow encryption. This does not prevent the use of the key for encryption, but it makes it more difficult with applications that check these attributes.
  • The risks of data loss associated with issuing tokens are similar to ones we already face with user-installed encryption. The change introduced by the token is merely the location the key is stored.
    • The user still has to install encryption software.
    • Getting the software to work with the token is probably more difficult than generating a key.
  • Users can generate and store their own keys on the token.
  • If or when the VT-CA issues personal certificates with the encryption attribute, data recovery methods will be reconsidered.

References

FIPS PUB 201-1 Personal Identity Verification (PIV) of Federal Employees and Contractors

FIPS 201 Excerpts from Section 4.3 Cryptographic Specifications

Requirements specific to storage and access of each class of keys are detailed below. Where applicable, key management requirements are also specified.

  • PIV Authentication Key This key shall be generated on the PIV Card. The PIV Card shall not permit exportation of the PIV authentication key.
  • Digital Signature Key The PIV digital signature key shall be generated on the PIV Card. The PIV Card shall not permit exportation of the digital signature key.

The Risks of "Key Recovery," "Key Escrow" and "Trusted Third-Party" Encryption

The Risks of "Key Recovery," "Key Escrow" and "Trusted Third-Party" Encryption - This article raises several other interesting points in addition to the one below. The focus of the article is primarily govenrment escrow of keys, but most of the ideas are significant at an institutional scale as well. Team of authors includes Bellovin, Blaze, Diffie, Rivest, Shiller, Schneier.

Excerpts from The Risks of "Key Recovery," "Key Escrow" and "Trusted Third-Party" Encryption

2.2 Much of the promise of electronic commerce depends on the ability to use cryptographic techniques to make binding commitments. Yet some key recovery schemes are designed to archive authentication and signature keys along with confidentiality keys. Such schemes destroy the absolute non-repudiation property that makes binding commitments possible. Furthermore, there are simply no legitimate uses for authentication or signature key recovery. The private sector requires distinct keys for all signers, even when two or more individuals are authorized to send a given message; without that, the ability to audit transactions is destroyed. Government surveillance does not require the recovery of signature keys, either.

Higher Education PKI Technical Activities Group (HEPKI-TAG)

Excerpts from Getting started with PKI - The PKI-Lite Recipe

2.8 Separate Signing and Encryption Keys?

A strong argument can be made that private encryption keys should be escrowed. Otherwise, sealed email could never be unsealed if the private key were no longer available. However, if encryption keys are to be escrowed, then separate signing keys should be used. There should only be one copy of the private signing key, and that should be in the possession of the owner. Otherwise, the owner could always claim that their signature has been forged.

2.9 Key Escrow Requirements

A campus must analyze the structure of its PKI-enabled applications to determine the role and need for escrow of private keys. Keys used for signing must never be escrowed, since that would allow someone to be able to impersonate the owner. When a key is used to seal (or encrypt) information, there must be a way to ensure that the information remains available to authorized parties when needed. If the encryption is only used to hide the information while it is in transit, then simply saving the information upon receipt in unencrypted form is one approach. Another approach is to encrypt the information to the keys of multiple parties and make it available to each of them. E.g. contracts could be encrypted to the lawyer involved, and also CC'd and encrypted to an "archival" account at the legal office. Yet another approach is to escrow the encryption key. The best approach depends on how the cost, complexity and risk assessments play out for a given situation.

Keys For Digital Signatures or Authentication

  • Short lifetime (typically 1 or two years).
  • Minimal cost if lost.
  • To support non-repudiation, private keys are generated on the device and cannot be copied from the device.
  • Signatures are generated using the private key.
  • Signatures are validated using the public key contained in the certificate (published). Validation does not depend on the private key.
  • forward secrecy

Keys For Encryption

  • Encrypted data must be recoverable. Private key escrow provides one tool to do this in a narrow set of circumstances.
  • Long lifetime (as long as the data must be accessed).
  • Creates high-value target.
  • No labels

1 Comment

  1. Mary Dunker

    Dec 10, 2007

    The Higher Education PKI Technical Activites Group http://middleware.internet2.edu/hepki-tag/#PKI_Lite refers to the draft PKI-Lite Recipe at http://stc.cis.brown.edu/~stc/Projects/Security/PKI/PKI-how.html.  Excerpts follow.

    2.8 Separate Signing and Encryption Keys?

    A strong argument can be made that private encryption keys should be escrowed. Otherwise, sealed email could never be unsealed if the private key were no longer available. However, if encryption keys are to be escrowed, then separate signing keys should be used. There should only be one copy of the private signing key, and that should be in the possession of the owner. Otherwise, the owner could always claim that their signature has been forged.

    2.9 Key Escrow Requirements

    A campus must analyze the structure of its PKI-enabled applications to determine the role and need for escrow of private keys. Keys used for signing must never be escrowed, since that would allow someone to be able to impersonate the owner. When a key is used to seal (or encrypt) information, there must be a way to ensure that the information remains available to authorized parties when needed. If the encryption is only used to hide the information while it is in transit, then simply saving the information upon receipt in unencrypted form is one approach. Another approach is to encrypt the information to the keys of multiple parties and make it available to each of them. E.g. contracts could be encrypted to the lawyer involved, and also CC'd and encrypted to an "archival" account at the legal office. Yet another approach is to escrow the encryption key. The best approach depends on how the cost, complexity and risk assessments play out for a given situation.