Elsevier

Computers & Security

Volume 19, Issue 1, 1 January 2000, Pages 41-47
Computers & Security

A Common Key Recovery Block Format: Promoting Interoperability Between Dissimilar Key Recovery Mechanisms

https://doi.org/10.1016/S0167-4048(00)86362-2Get rights and content

Abstract

When cryptographic products that employ different key recovery mechanisms need to interoperate with one another, one of the major obstacles is the inability of the decryptor product to recognize, and optionally validate, the key recovery information generated by the encryptor product. In this paper, a common Key Recovery Block (KRB) format is being proposed to facilitate interoperability between heterogeneous key recovery systems. The KRB serves as a container for mechanism-specific key recovery information, and supports techniques to identify and optionally validate the contained key recovery information. This specification provides an extensible set of KRB validation techniques - however, it makes no attempt to set a preference for one technique over the others. The choice of validation technique(s) used is determined by the policies (with respect to the use of cryptography and key recovery) that apply to the encryptor and decryptor products. It may be noted that the KRB format specification is independent of the encryption algorithm used to protect the confidentiality of the data, and independent of the communication or storage protocol used to carry the encrypted data.

It should also be recognized that the KRB format proposed in this paper is of limited scope. It assumes that the key recovery information can be made available to interested parties along with the encrypted data. There are a number of open issues regarding the techniques that allow key recovery information to be associated with encrypted data (whether the key recovery information and the encrypted data are transmitted over the same channel or separate channels) — these issues are beyond the scope of this proposal.

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 Security
    Citation 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 Engineering
  • Key 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)

View full text