A Common Key Recovery Block Format: Promoting Interoperability Between Dissimilar Key Recovery Mechanisms
Introduction
There are multiple and varied key recovery (key escrow as well as key encapsulation) mechanisms that have been proposed to date. Each of these mechanisms support the ability to recover a key that has been used, either directly or indirectly, to protect the confidentiality of data. The escrow mechanisms typically allow the retrieval of the private key of an asymmetric key pair, which may, in turn, be used to retrieve the secret key used to protect the confidentiality of data. The encapsulation mechanisms, on the other hand, typically allow the direct retrieval of the secret key used to protect data confidentiality. In the majority of key recovery mechanisms, there is an identifiable set of key recovery fields (KRF) which represent the key recovery information necessary for the (direct or indirect) retrieval of the ciphertext decryption key. The KRF is generated by the party performing the data encryption, and associated with the enciphered data. To ensure the correctness of the key recovery fields, and its association with the encrypted data, the KRF may be validated by the party performing the data decryption. In such cases, the policy enforced by the decrypting party ensures that successful data decryption will not occur unless the key recovery fields are validated. In certain situations, the KRF may be validated by parties other than the decryptor.
In a typical escrow mechanism (where an Escrow Agent holds the private keys for individuals,) the KRF would comprise the Key Exchange Block, in which the bulk encryption key is wrapped using the recipient’s public key. In a typical encapsulation mechanism, the KRF may comprise the bulk encryption key wrapped with the public key(s) of the Recovery Agent(s).
In mechanisms where the KRF comprises the key exchange block, decryption cannot occur at the receiving end unless the KRF is processed to obtain the decryption key; thus the KRF is automatically validated. In mechanisms where the KRF is distinct from the key exchange block, the policy at the decryptor side may require validation of the KRF, before allowing the successful decryption of the ciphertext. If the decryptor side is incapable of validating the KRF, the validation may be performed by other interested parties, such as those that perform interception of the KRF.
Section snippets
Problem Statement
There are a large number of key recovery mechanisms that are in use today in key recovery enabled products. Each such key recovery mechanism is based on a proprietary algorithm for generation of the KRF, and possibly, a proprietary algorithm for validating the KRF.
One of the goals of key recovery is to define techniques to promote ‘interoperability’ between products that incorporate dissimilar key recovery (KR) mechanisms. The word ‘interoperability’ is used here to mean the ability of product
Proposed Solution
A common Key Recovery Block (KRB) format is being proposed for the express purpose of facilitating interoperability between heterogeneous KR systems. A Key Recovery Block is defined as a stream of bytes, that serves as a container for a single key recovery mechanism-specific KRF, and associates the KRF with a set of standard fields in a predefined format. The definition of the KRB achieves the two objectives laid out in the last section.
The first objective specified above is to provide a way to
Format of the Key Recovery Block
The Version 1 common KRB is specified in byte-oriented format only. Subsequent versions of the KRB can support an ASN.1 specification, as well as a byte-oriented specification. The byte-oriented common KRB format for Version 1 uses big-endian byte ordering as shown below.
KRB Version Number:
Value of 1 for this version of the common KRB format.
KRB Length:
The number of 32-bit words in the entire KRB (beginning at KRB Version Number and ending at the last word in the Validation Field Value.)
Object
Usage of KRB Validation Techniques
This section elaborates on the different KRB validation techniques.
NONE (TYPE=0)
No validation field is calculated. The Validation Field Value does not exist. The Validation Field Length is set to zero.
Certain KR products may not require any validation of the KRF to be done at the decrypting side. These products should use Validation Field Type ‘NONE’, indicating that KRF validation is unnecessary.
SEMANTIC (TYPE=1)
No validation field is calculated. The Validation Field Value does not exist. The
Examples
Consider the following example of a KRB (a modified version of a KRB generated by a Cylink product) that uses no validation techniques.
Consider another example of a KRB generated by a product of fictitious company XXYYZZ that uses the CONF-HMAC-SHA-1-96 type of validation field.
Proposed Usage and Conclusions
Vendors that are compliant with the common KRB format, would design their products so that their KRF (in proprietary format) is placed within the common KRB defined above. The other fields of the KRB would be filled in appropriately. The resultant KRB would be used wherever the proprietary format KRF was being used before. When using the KRB format to transport key recovery information within a protocol, attention should be given to framing the KRB appropriately within a Protocol Data Unit
References
Krawczyk, H., M. Bellare, and R. Canetti, HMAC: Keyed-Hashing for Message Authentication, RFC 2104, February 1997.
Madson, C., and R. Glenn, The Use of HMAC-SHA-1-96 within ESP and AH, RFC 2404.
Madson, C., and R. Glenn, The Use of HMAC-MD5-96 within ESP and AH, RFC 2403.
RSA Labs, PKCS#7: Cryptographic Message Syntax Standard, Technical Note, Version 1.5, November 1, 1993.
References (0)
Cited by (4)
Matching key recovery mechanisms to business requirements
2005, Computers and SecurityCitation Excerpt :Assuming that KR is required for all encrypted communicated data, it is clear that interoperability restrictions on its use would be undesirable. A couple of schemes that promise to provide interoperability between dissimilar mechanisms have been proposed by IBM SecureWay, and the Key Recovery Alliance (Gupta, 2000). As far as the latter is concerned, although it promises to promote interoperability between dissimilar schemes, in many cases it fails to do so.
Recoverable encryption through a noised secret over a large cloud
2013, Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics)FASiRec: A fast session recovery scheme for large-scale VPNs using IPSec
2008, Journal of Information Science and EngineeringKey recovery scheme interoperability – A protocol for mechanism negotiation
2001, Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics)
- 1
(CygnaCom Solutions)