Mitchell, Chris J

Rantos, Konstantinos

Royal Holloway Research Online

Remarks on KRA's key recovery block format

Remarks on KRA's Key Recovery Block FormatKonstantinos Rantosand Chris MitchellInformation Security Group,Royal Holloway, University of London,Egham, Surrey TW20 0EX, UK.K.Rantos@dcs.rhbnc.ac.uk, C.Mitchell@rhbnc.ac.uk26th January 1999AbstractThe introduction of a plethora of key recovery (KR) schemes and thelack of a standard has led to interoperability problems between dissimi-lar mechanisms. To overcome these problems the Key Recovery Alliance(KRA) has proposed a common Key Recovery Block (KRB) format. Thispaper identies some cases that the mechanism fails to achieve its objec-tives.Keywords: key recovery, interoperability.1 IntroductionThe deployment of cryptographic mechanisms for data condentiality has re-sulted in the introduction of key recovery (escrow) services. These will poten-This author's work is supported by the European Commission (TMR Marie Curie Re-search and Training Grant ERBFMBICT983274).1tially be used both by companies as well as by individuals who do not want tolose their encryption keys and therefore have no access to their data. Many KRschemes have been proposed so far by industry and academia. An overview ofsome of these mechanisms is given in [1]. The existence of various KR mech-anisms, with dierent characteristics and more important not compliant to astandard, has led to interoperability problems.Consider the case where an entity A using a KR mechanism KRMAwants tocommunicate with an entity B using a KR mechanism KRMB. Assuming thatboth entities wish to establish a secure communication with KR capability, bothof them have to make use of their KR mechanisms. The problem that arisesin such a case is whether these two mechanisms can interoperate, i.e. whether\KRMAcan set up a KR enabled cryptographic association with KRMB"[2].The problem becomes more visible when one or both of the entities want, orare obliged due to policy restrictions, to validate the KR information receivedfrom the peer entity prior to decryption of the ciphertext. That is, both entitieswant to make sure that the peer entity makes proper use of the KR mechanism.Due to the increasing number of KR schemes commercially available, and notcompliant with a standard, it will be infeasible forKRMBto know the semanticdetails of all the mechanisms and be able to parse the KR information receivedfrom A. The KR information in many KR mechanisms is within a Key RecoveryField (KRF). In [2] two main types of KRFs are identied. The rst one is foundin a key escrowmechanism and basically contains the session key encrypted withthe recipient's public key. Such a mechanism requires access to the recipient's2private key which in turn enables the recovery of the session key. In a keyencapsulation mechanism, however, the session key is encrypted with the publickey(s) of the Recovery Agent(s). This type of mechanism allows the RecoveryAgent to directly recover the session key.The diering requirements of the available KR mechanisms and the varyingformats of their KRFs (when one is used) have led to interoperability problems.In many situations the KRFs cannot be interpreted and therefore cannot beused at all. This might lead to suspension of communications as in manycases the communicating entities' policies might explicitly require validationof the KR information prior to decryption. Thus, it becomes obvious that amechanism is needed that will enable the entities to validate the KR informationreceived.2 KRA's modelTo overcome the interoperability problems described in the previous section theKey Recovery Alliance (KRA) has proposed a mechanism which, when adopted,enables communications between dissimilar KR mechanisms. The mechanismintroduces a Key Recovery Block (KRB) that \serves as a container for a singleKR mechanism-specic KRF" [2]. The KRB according to [2] achieves two mainobjectives; it \provides a means to identify the KR mechanism used to constructthe KRF", and, \provides a range of validation techniques, including those thatallow validation of the KR information in generic, KR mechanism-independentways".32.1 Description of the KRB and its validation mechanismsIn this section brief descriptions of the KRB and the KRB validation techniquesare given. For full details and explanations of the mechanism see [2]. The KRBconsists of the following elds: KRB Version Number. KRB Length: The number of words in the entire KRB. Object Identier (OID) for KRF: The OID for the KR mechanismused to generate the KRF, as registered with a central authority. Reserved: A 16-bit eld reserved for future use. KRF Length: Number of words in the KRF. Key Recovery Field: The proprietary KRF whose format and contentsare indicated by the OID. Validation Field Type: Identies one of the following seven techniquesused to compute the Validation1. NONE(Type 0): No Validation Field Value (VFV) is calculated;KRF validation is unnecessary at the decrypting side.2. SEMANTIC(Type 1): No VFV is calculated; the KRF should bevalidated semantically using the mechanism-specic algorithm.3. PROTOCOL(Type 2): No VFV is calculated; the KRB need notbe checked for validity since the carrier protocol provides integrityprotection for the KRB.44. CONF-HMAC-SHA-1-96(Type 3): The VFV is a hash of theKRB using HMAC and SHA-1 and the condentiality key associatedwith the KRF.5. CONF-HMAC-MD5-96(Type 4): The VFV is a hash of theKRB using HMAC and MD-5 and the condentiality key associatedwith the KRF.6. INTEG-HMAC-SHA-1-96(Type 5): The VFV is a hash of theKRB using HMAC and SHA-1 and the integrity key associated withthe KRF.7. INTEG-HMAC-MD5-96(Type 6): The VFV is a hash of theKRB using HMAC and MD-5 and the integrity key associated withthe KRF. Validation Field Length: Number of words in the VFV. Validation Field Value: It is calculated over the entire KRB.3 Problems identied in this mechanismThe mechanism proposed by the KRA, as mentioned above, promises to pro-mote interoperability between dissimilar mechanisms. However, two problemscan be identied within this mechanism. The rst relates to diculties arisingfrom the generation of proprietary KRFs while the other concerns the fact thatin many cases the mechanism fails to provide interoperability.53.1 KRF generationThe paper makes the silent assumption that a KRF has already been gener-ated and therefore it is always available for the KRB generation. However,this is feasible only in a very limited number of combinations of the variousKR schemes. In the case of non-interoperable mechanisms, the sender mightnot be able to generate a KRF because the receiver's end does not fulll therequirements of the sender's KR mechanism. Consider the case, in its simplestapproach, where the KRF generation requires the encryption of the secret ses-sion key (data encryption key) using the public key of the receiver (because thesender is using a key escrow mechanism). If the receiver does not have a publickey because he is not using key escrow but a key encapsulation mechanism (ora public key that he might have does not fulll the requirements of the sender'sKR mechanism) the sender cannot oblige the receiver to get one. Therefore thesender cannot generate a KRF.3.2 Interoperability issuesAmong the Validation Field Types proposed in [2] there are ve (types 2{6)which provide validation of the KRB. According to [2], using the generic valida-tion mechanisms supported by the KRB, entity B would be able to validate theproprietary KRF sent by A and vice versa, \even though B did not understandhow to parse the KRF". However, the placement of the KRF within the KRBdoes not enable this validation. The receiving entity still has to parse the KRFto check its validity. The integrity, condentiality, and/or authentication of the6KRB and therefore of the content of the KRB, the KRF, does not guaranteethe latter's validity.As a consequence, the validation techniques proposed are vulnerable to a singlerogue user scenario. Consider the case where two parties communicate usingdissimilar (non-interoperable) KR mechanisms. Sender A generates a KRF forthe receiver B who is not able to verify the proprietary KRF using the methodrequired by A's KR mechanism because he is using a dissimilar KR mechanism.Assuming further that A is a rogue user, then the following scenario might takeplace: A generates a non-valid KRF. However, the Validation Field Value isgenerated using the valid session key (validation eld types 3-6) which thereceiver knows in advance. A genuine receiver B will validate correctly theKRB, as this was correctly generated by A. However, the validation techniqueand therefore the validation of the KR information has just failed because theKRF is not genuine and B has no means to verify that (we assume that thetwo mechanisms are not compliant and therefore B does not know the semanticdetails of KRMA). Thus B will not be compliant with his policy which requiresvalidation of the KRF prior to decryption of the encrypted data.Moreover a Key Recovery Agent that A is associated with will not be able torecover the key. This is because the KRA will not try to recover the key usingthe KRB but using the KRF contained in it. However, the KRB was acceptedas valid by B. In other words the KRB does not play the main role of theKRF which is to give information on the session key. It is only a mechanismthat can provide integrity, condentiality, or/and authentication but it is not a7\mechanism for verifying the validation of the enclosed KRF" [2, page 7]. Thereis no way to recover the key from the KRB using only the information providedby the KRB itself (excluding the KRF because this can be manipulated only bythe users that deploy the same product). In the case of Validation Field Type7 the same problem holds, as the Validation Field Value is a digital signatureon the KRB which can carry a non-valid KRF. The only types that do notsuer from this problem are types 0 and 1 which demand \no validation" and\mechanism specic validation" respectively.Therefore the solution proposed here does not achieve one of the two majorobjectives mentioned above, which is to provide \the ability to validate the KRinformation in a way that does not require knowledge of the exact semanticproperties of the KRF". The solution fails to achieve its objective in situationswhere it is most desirable, i.e. in environments where there is a lack of trust.The mechanisms where the KRF comprises the key exchange block do not suerfrom the above problem because in such a case the KRF has to be processed toobtain the decryption key. However, these mechanisms face the problem wherethe sender cannot generate a KRF and if one is generated the receiving endmight not be able to parse it and get the session key. The KRB proposed doesnot oer an alternative to this situation since the receiving end cannot obtainthe session key using interoperable components.84 ConclusionsThis paper has looked at two problems inherent in the KRA proposal for in-teroperability of dissimilar key recovery mechanisms. The mechanism proposedoers an ecient way of carrying the KRF with condentiality, integrity, and/orauthentication but not a way of validating the KRF itself. Thus the proposedscheme fails to achieve one of its main objectives.References[1] Dorothy E. Denning and Dennis K. Branstad. A taxonomy of key escrowencryption systems. Communications of the ACM, 39:34{40, March 1996.[2] Sarbari Gupta. A common key recovery block format: Promoting interoper-ability between dissimilar key recovery mechanisms. A document preparedfor the Key Recovery Alliance, http://www.kra.org, May 1998.9

Royal Holloway - Pure

https://repository.royalholloway.ac.uk/items/7e6640be-52f5-30e4-c4ba-55d97034f25e/9/rokkrb.pdf

Remarks on KRA's key recovery block format

Abstract

Similar works

Full text

Available Versions

Royal Holloway Research Online

Royal Holloway Research Online

Royal Holloway Research Online

Royal Holloway Research Online

Royal Holloway Research Online

Royal Holloway Research Online

Royal Holloway Research Online

Royal Holloway - Pure

Royal Holloway Research Online

Royal Holloway Research Online