Mitchell, Chris J

Rantos, Konstantinos

Royal Holloway Research Online

Key recovery for archived data using smart cards

Royal Holloway - Pure

Key Reovery for Arhived Datausing Smart CardsKonstantinos Rantosand Chris J. MithellInformation Seurity Group,Royal Holloway, University of London,Egham, Surrey TW20 0EX, UK.{K.Rantos, C.Mithell}rhbn.a.ukAbstratAlthough many key reovery mehanisms have been proposed, themajority of them have been designed in the ontext of use with om-muniated data. The dierent requirements, however, that surroundommuniated and arhived data make most of these mehanisms in-appropriate for use on arhived data. This paper investigates the busi-ness need for key reovery for enrypted arhived data, identies therequirements a key reovery mehanism should full, and proposes asheme where keys used for stored data enryption an easily be re-overed.Keywords: key reovery, smart ards, arhived data, rogue userattaks, business requirements.1 IntrodutionWith the development of ryptography and its growing use in protetingommuniated and arhived data, a ritial issue has evolved onerning theloss of deryption keys. Assuming the use of seure mehanisms, loss ofThis author's work is supported by the European Commission (TMR Marie CurieResearh and Training Grant ERBFMBICT983274).1keys means that deryption is infeasible, resulting in inaessibility of data.Corporations will nd suh situations unaeptable, espeially if the inaes-sible data hold potentially valuable information. Key reovery mehanisms(KRMs) an be an eient ountermeasure to this threat. KRMs are meh-anisms that allow authorised parties, under ertain onditions, to retrievethe ryptographi keys used for data ondentiality, with the ultimate goalof reovering the leartext data. An introdution to how these mehanismswork, and desriptions of existing KRMs and their properties, an be foundin [1, 2, 3, 4, 5, 6℄.The KRMs proposed so far have mainly been designed to provide keyreovery (KR) for enrypted ommuniation sessions. However, the dierentrequirements for KRMs for ommuniated and arhived data [7℄ demand thedistintion between these two types of appliation. This paper examines therequirements that a KRM should full when deployed for enrypted arhiveddata in a orporate environment. Further to this analysis, a mehanism isproposed that meets these needs. More speially, the mehanism givesauthorised parties the ability to reover keys used for enrypting arhiveddata with limited storage and proessing requirements while preventing rogueuser attaks. Unlike most KRMs, eah user will be able to reover the keysused on the les he enrypted without the intervention of the key reoveryagent (KRA), i.e. the trusted entity that assists in the reovery of keys, bypreserving the appropriate key material.2 The need for KR for enrypted arhived dataThe enryption of arhived data typially involves a single entity, whih storesand retrieves data at distint points in time [7℄. Unless omplex key gener-ation tehniques giving a third party aess to the generated key materialare used, the entity that does the enryption is likely to be the only one inpossession of the key material needed to derypt the data. As a result, thereare many irumstanes that an result in the loss or inaessibility of keys.These irumstanes inlude both deliberate ations and aidents.Deliberate ations originate both from outsiders and insiders. Experieneseems to show that attaks are more likely to ome from insiders than out-siders [8, 9℄, and hene the threat to the ompany from its employees annotbe ignored when enforing seurity in a orporate environment. One of the2dangers that a ompany might fae is a disgruntled employee being the onlyholder of the keys used to derypt business information. When requested tohand over the deryption keys, e.g. on termination of employment, he mightrefuse to do so, leaving the ompany with the potentially infeasible task ofretrieving enrypted data without having the deryption key.There are also ertain aidental situations whih might have the sameunaeptable result. Consider, for instane, an employee that is away on va-ation when the ompany requires the keys for the deryption of some of hisdata. Requesting the employee to reveal the password over an inseure tele-phone link, subjet to eavesdropping, bears the risk of aidentally revealingit to unauthorised third parties. Under these onditions there should be analternative means for the ompany to gain aess to the keys neessary forderyption.When keys are held in a storage devie, e.g. a hard disk or a smart ard,aessible by a password, the possibility exists that the devie is destroyed,malfuntions, or is lost (not unlikely in the ase of smart ards). The storedkeys would then beome inaessible and, if a mehanism that allows reoveryof the keys kept in the devie does not exist, the data would be lost.All these undesirable situations imply that the orporation, as the legiti-mate owner of all the ompany data, should have aess to data deryptionkeys when neessary. KRMs an help overome this problem, sine theyprovide a means to aess the key material neessary to reover the data de-ryption keys. This aess will typially only be given to authorised entities,ating in aordane with a dened orporate seurity poliy.Although key reovery an be used as a ountermeasure to the abovethreats, it an also be used to enourage employees to use enryption. Unlessthey are sure that data they enrypt an be easily reovered even if they losethe deryption keys, employees will be relutant to use enryption, heneleaving their data unenrypted even though that information needs to beproteted. Note that this paper does not attempt a detailed analysis of thevarious lasses of KRMs; instead see [1℄ and [2℄.3 Using existing KRMs with arhived dataPreviously proposed KRMs were mainly designed to provide KR funtional-ity for enrypted ommuniations. When these mehanisms are applied to3arhived data (espeially key enapsulation shemes [2, 6℄), they suer fromthe absene of a seond party that an verify the generated KR information.As a result, they beome partiularly vulnerable to rogue user attaks, wherea rogue user an tamper with (alter or delete) the KR information during orafter its generation, making it unusable to third parties.An obvious ountermeasure to this attak is to have an on-line agentwhih will ontribute to the generation of all data enryption keys, whilehaving diret aess to, and keeping a bakup of, all the generated keys.Alternatively, users ould be required to esrow their master key or thele enrypting keys with a entral agent. These solutions, however, typi-ally demand a high-powered on-line server that may be involved in the keygeneration proess, and its unavailability would prevent use of enryption.Furthermore, the administrative osts involved, inluding the seurity meh-anisms needed for the protetion of this information and the storage needs ofall the esrowed keys, may make this solution quite unattrative, espeiallyin small and medium-sized enterprises.Another problem with most existing KRMs is that they do not oer theuser who performed the enryption the ability to reover his keys unaided.That is, every time the user wants to reover a key previously used for en-rypting data, he has to ontat his agent, who will reover the requiredkeys on the user's behalf. This problem arises from the fat that the inten-tion of the majority of the proposed mehanisms was to give KRAs aessto suspeted enrypted ommuniated data. So the design was foused ongiving aess to the on-line agent, where the ommuniation hannel alreadyexists, rather than the user himself. As a result, applying these mehanismsto enrypted arhived data introdues extra ommuniations osts, due tothe required agent's interation, and demands an on-line agent with the on-sequenes mentioned above.A key reovery mehanism that would be speially designed for usewith enrypted arhived data while overoming the aforementioned problemsshould typially satisfy the following requirements:1. The KRA should have the ability to reover the required keys, evenwhen the user tampers with the generated KR information.2. The mehanism should give the user the ability to reover his keysunaided, i.e. without the KRA's intervention. This will ensure that theuser has ontinuous aess to his keys while avoiding the need to keep4a bakup of them loally (an approah that introdues new threats tothe serey of the keys).Further to these requirements, it will be an advantage if the KRM makesno demands for an on-line server or storage of users' key related material.A KRM designed for use with arhived data was proposed by Maher, [10℄.This mehanism, however, suers from the problem that a user an tamperwith the generated key reovery information and prevent key reovery bythe agent. Moreover, the user annot reover his keys without the agent'spartiipation, a property that either neessitates the use of bakup opies ofkeys or relies on the KRA's ative support to aess enrypted data.Another sheme is proposed here that overomes this problem. Morespeially, for the proposed KRM a user does not require his agent's inter-vention to reover his keys. Further, it is not vulnerable to rogue user attakson the generated KR information, and has no requirement for generated keysto be esrowed with the agent. Therefore, the proposed mehanism avoidsboth the vulnerability to rogue user attaks of key enapsulation mehanisms,and the requirement for storage and protetion of user key material of keyesrow mehanisms.As far as rogue user attaks are onerned, for the purposes of this pa-per we assume that a rogue user, trying to disable authorised KR by hisassoiated KRA, may tamper with the generated KR information by eitheraltering or deleting it, or may even prevent its generation. However, we as-sume that the user will leave the enrypted data unhanged so that he anreover it when neessary (if the enrypted data is modied or destroyed,then no KRM an deal with the situation). For instane, the rogue usermight simply detah the KR information from the enrypted le, whih hewill retain but not hand to the KRA. Through possession of this informationthe user an reover the required key, but the KRA annot. Finally, notethat no KRM an prevent a rogue user from deploying his own ryptographiinfrastruture, and hene, suh rogue user attaks are not onsidered in thispaper.4 A new KRM for enrypted arhived dataWe now desribe the new mehanism for adding KR funtionality to theenryption proess for arhived data.5Three entities are involved in the proposed mehanism: the user whoenrypts the data, the KRA whih assists in the management of keys, andthe authorised entity AE whih is the entity authorised by the orporatepoliy to have aess to users' data.Whenever a user wants to enrypt a le or message, instead of generatinga random key for data enryption, he uses the proposed mehanism for keygeneration, whih will also allow later reovery of the generated key. Forthis mehanism, whih neessitates the use of a smart ard by eah user, thefollowing requirements must be satised:1. The KRA and the user's ard share a message authentiation ode(MAC) funtion f1, a one-way hash funtion h, and a key generat-ing funtion f2 (this ould potentially be a one-way hash funtion). f2is used to generate the key KACthat will be used by the MAC funtionf1, i.e. KAC= f2(KM; idA), where KMis the KRA's master key andidAis user's A identity. KACshould be stored on the user's ard, typ-ially during the ard's personalisation, while the user must not haveaess to it to prevent rogue user attaks.2. The KRA, user, and authorised entity share a key generating funtionf3. As with f2, f3 an be a one-way hash funtion.3. The user's ard and the AE share a seret key KAMwhih is generatedas a funtion of KAand a seret master key KAEthat the authorisedentity possesses, i.e. KAM= f3(KAE; KA). KAis a master key speito user A, whih is generated as a funtion of KRA's key KMand theuser's identity idA, i.e. KA= f3(KM; idA). As with KAC, KAMshouldalso be stored on the user's ard during the ard's personalisation.4. The user has aess to a random number generator. The generatedrandom numbers are used to ensure key freshness so that even a singlele will not be enrypted with the same key more than one.5. The KRA administers a le onsisting of indexes binding a uniquele identier with a random value generated for the spei le. Theintegrity of this le and must be preserved.6. All the entities trust the devie where the enryption takes plae, i.e.the user's PC or a server. If this is not the ase then enryption has to6take plae on the ard, although there are ertain performane limita-tions assoiated with this approah.When user A wants to enrypt a le, a session key KShas to be generatedusing the following protool.1. A generates a random value RAND either on his ard or on the PC andusing his ard omputes a MAC on RAND and the unique identierleid of the le to be enrypted, i.e. MAC1= f1KAC(RAND; leid). Athen sends the following message to the KRA,AidA k RAND k leid k MAC1                         ! KRAwhere k denotes onatenation.2. Upon reeipt of the message the KRA uses the reeived user's iden-tity idAand the master key KMto ompute the key KAC. The KRAthen reomputes the message authentiation ode MAC1using the re-eived values RAND and leid and heks the result against the re-eived MAC1. If the hek sueeds the KRA adds an entry to theindex le onsisting of the reeived leid and the random value RAND,indexed by the user who sent it. The KRA then omputes a messageauthentiation ode MAC2on the hash of values RAND and leid, i.e.MAC2= f1KAC(h(RAND; leid)) and sends it bak to the user's ard.AMAC2          KRAThis tells the ard that the KRA has suessfully registered the reeivedrandom value RAND for the le identied by leid.3. As soon as the ard reeives MAC2it reomputes it using the valuesRAND and leid that it sent to the KRA, and heks it against thereeived MAC2. (Note that the omputation of MAC2ould take plaewhile the ard waits for the KRA's response.) If the hek sueeds, theard uses the seret key KAMand the random value RAND to generatethe session key KSasKS= f3(KAM;RAND)7whih is passed to the PC for the enryption proess. The le is en-rypted using KSand a key reovery eld KRF is attahed to it. TheKRF onsists of the random value RAND (the KRA's identity shouldalso be inluded if there are multiple KRAs), i.e.KRF = fRANDgShould an emergeny aess situation arise, the authorised entity will re-quest from the KRA the key KAthat orresponds to the user that performedthe enryption. Having KAand using the master key KAEand the funtionf3 the authorised entity omputes the orresponding user's key KAM, i.e.KAM= f3(KAE; KA). Using KAMand the value RAND attahed to the le,the authorised entity an suessfully reover the required key and the targetdata.5 Properties and seurity analysisWith the proposed sheme, there is no need for interation with the agent ineveryday user aess to the enrypted data, a property that simplies the keyreovery proess for the user. More speially, when a user wants to aessa key that he has previously used to enrypt arhived data, the agent neednot partiipate in this proess. The user is able to reover the keys using hissmart ard, whih an reompute the target key KSusing the value RANDattahed to the le.The majority of KRMs lak suh a feature; the user's KRA is typiallythe only entity that an reover the key. With the proposed sheme the userwill be required to ontat his agent only if he has lost his ard, in whihase only the authorised entity AE an reover the user's keys. This propertytypially eliminates the requirement for an on-line agent for the reovery ofkeys (for the purposes of user everyday aess to enrypted data) and avoidsthe related ommuniations overhead. Moreover, the user does not haveto bak-up or arhive the generated keys for his own needs, thus avoidingertain problems assoiated with suh an approah. Further properties ofthe proposed mehanism inlude:1. The proposed mehanism is not vulnerable to rogue user attaks, aseven if a rogue user deletes the generated KRF the KRA has the means8to reover the requested key. Using just the index le and the identityof the le and the user, the KRA has all the needed values to omputethe required key.2. The KRA does not have to store or protet any of the user generatedkeys, thus avoiding ertain problems that key esrow mehanisms fae,e.g. protetion from unauthorised aess to the esrowed material. Theonly requirement, apart from the protetion of the seret value KM, isprotetion of the index le from unauthorised modiation.3. The mehanism benets from the separation of the KRA from the au-thorised entity AE in that the KRA does not have aess to users'generated session keys. The only entities that an reover the sessionkeys are the users and the authorised entity AE. This allows the orpo-ration to outsoure the management of the KRM without endangeringthe ondentiality of the orporate data.4. Dispersion of key material, a ountermeasure that makes attaks onkey reovery mehanisms more diult, is properly enfored with theuse of both KMand KAEfor the omputation of KAMand, therefore,the generation of KS. Even ifKMor KAEis ompromised an adversaryannot gain aess to the users' keys. The attaker has to know bothKMand KAEto be able to reover users' keys.5. The random value RAND an be either generated on the ard or onthe user's PC and passed to the ard. The seurity of the mehanism,however, does not rely on the randomness of this value, sine it is onlyused to ensure freshness of the generated key. As a result, RAND anbe generated on the PC to redue the number of power onsumingproedures that take plae on the ard.6 ConlusionsIn this paper, the possible dangers to a orporation arising from an inabilityto aess keys used for enrypting stored data have been onsidered. Therequirements for a KRM used as a ountermeasure have been identied anda new mehanism that fulls them has been proposed. More speially,9the mehanism is not vulnerable to rogue user attaks, unlike many existingKRMs when used for enrypted arhived data, while it oers the user theability to reover his keys without his agent's intervention, a feature thateliminates any ommuniation overheads. It has the additional benet thatit does not require the diret esrow of any user generated keys, avoiding theosts introdued by the demand for protetion and administration of thesekeys.AknowledgementsThe authors would like to thank Keith Martin and the anonymous refereesfor their helpful omments.Referenes[1℄ D.E. Denning and D.K. Branstad. A taxonomy of key esrow enryptionsystems. Communiations of the ACM, 39(3):3440, Marh 1996.[2℄ M. Smith, P. van Oorshot, and M. Willett. Cryptographi informationreovery using key reovery. Computers & Seurity, 19(1):2127, 2000.[3℄ J. Kennedy, S.M. Matyas Jr., and N. Zuni. Key reovery funtionalmodel. Computers & Seurity, 19(1):3136, 2000.[4℄ IBM SeureWay. Towards a framework based solution to ryptographikey reovery.http://www-4.ibm.om/software/seurity/keyworks/library/.[5℄ N. Jeeries, C. Mithell, and M. Walker. A proposed arhiteture fortrusted third parties. In E. Dawson and J. Goli, editors, Cryptogra-phy: Poliy and Algorithms  Proeedings: International Conferene,Brisbane, Australia, pages 98104. Springer-Verlag (LNCS 1029), Berlin1996.[6℄ S.T. Walker, S.B. Lipner, C.M. Ellison, and D.M. Balenson. Commerialkey reovery. Communiations of the ACM, 39(3):4147, Marh 1996.10[7℄ K. Rantos and C.J. Mithell. Mathing key reovery mehanisms tobusiness requirements. Submitted.[8℄ D.E. Denning. Information Warfare and Seurity. AddisonWesley, 1998.[9℄ M.R. Smith. Commonsense Computer Seurity. MGraw-Hill, 1994.[10℄ D.P. Maher. Crypto bakup and key esrow. Communiations of theACM, 39(3):4853, Marh 1996.11

https://pure.royalholloway.ac.uk/ws/files/4739565/krfadu2.pdf

Key recovery for archived data using smart cards

Abstract

Similar works

Full text

Available Versions

Royal Holloway Research Online

Royal Holloway - Pure

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 Research Online