CA2075329C - Public key cryptosystem key management based on control vectors - Google Patents

Abstract

A data processing system, method and program are disclosed, for managing a public key cryptographic system.
The method includes the steps of generating a first public key and a first private key as a first pair in the data processing system, for use with a first public key algorithm and further generating a second public key and a second private key as a second pair in the data processing system, for use with a second public key algorithm. The method then continues by assigning a private control vector for the first private key and the second private key in the data processing system, for defining permitted uses for the first and second private keys. Then the method continues by forming a private key record which includes the first private key and the second private key in the data processing system, and encrypting the private key record under a first master key expression which is a function of the private control vector. The method then forms a private key token which includes the private control vector and the private key record, and stores the private key token in the data processing system. At a later time, the method receives a first key use request in the data processing system, requiring the first public key algorithm. In response to this, the method continues by accessing the private key token in the data processing system and checking the private control vector to determine if the private key record contains a key having permitted uses which will satisfy the first request. The method then decrypts the private key record under the first master key expression in the data processing system and extracts the first private key from the private key record. The method selects the first public key algorithm in the data processing system for the first key use request and executes the first public key algorithm in the data processing system using the first private key to perform a cryptographic operation to satisfy the first key use request.

Description

2075~2~

PUBLIC KEY CRYPTOSYSTEM KEY MANAGEMENT BASED ON
CONTROL VECTORS

Ba~k~round of ~e Illvention 1. Te~ k'icl,~
The inventic)n disclosed broadly relates to data processing systems and meth(:)d ancl more particularly relates to cryptograpllic systems and n-lethods for use in data processing systellls to erlhance security.

2. Bac~gr(lu)~d ~r t The following patcnts are rclated to tllis inverltion:
B. Braclltl, et al., "Controlled Use of Cryptographic Keys Via Generating Stations Established Control Vahles", USI' 4,850,017, issued July 18, 1989, assigned to IBM Corporation S.M. Matyas et al., "Secure Management of ICeys Using Control Vectors", USP 4,941,176, issued July 10, 199(), assigned to IBM ( orporation.
S.M. Matyas et al., "Data Crypt()graplly Operations Using G)Iltrol Vcctors", USP 4,918,728, issued April 17, 1990, assigned to IBM Corporatioll.
S.M. Matyas et: al., "Personal Identification Number ProcessiIlg Using Control Vectors", USP 4,924,514, isslled May 8, 1990, assigned to IBM Corporation.
S.M. Matyas et al., "Secure Management of I{eys Using Extended Control Vectors", USP 4,924,515, issued May 8, 199(), assigned to IBM Corporation.
S.M. Matyas et al., "Secure Managerllent Using Programmable Control Vector Checlcirlg", USP 5,007,()89, issucd April 9, 1990, assigned to IBM Corporation.
S.M. Matyas et al., "Secure ICey Management Using Control Vector Trallslation", USP 4,993,0~9, issued Febnlary 12, 1991, assigned to IBM Corporation.
B. Brachtl, et al., "Data AutheIltication Using Modification Detection Codes Based on a Pllblic One Way Encryption FuIlctioIl'', USP 4,908,861, issued March 13, 199(), assigned to IBM Corporation.
S.M. Matyas et al., ''GeneratiIlg Public and Private ICey Pairs Using a Passphrase", USP 5,2()1,0()0, issued April 4, 1993, assigne(l to IBM Corporation.
I

207;~32~

I'he cryptographic architecture described in the cited patents by S. M. Matyas, ct al. is bascd on associating with a cryptographic key, a control vector which provides tl)c authori7atioll for the uscs Or thc key intended by the origLnator of the key. The cryptographic architccture descril~ccl in ~he citcd patents hy S. M. Matyas, et al. is based on the Data Encryption ~Igorithm (DI~A~, scc Amcricall Naliollal Slalldard X3.92-1981, l~ala ~ncryption ~llgorithm, American National Standards Institute, New York (I)ecember 31, 1981), whereas the present invention is based on both a secret key algorithm, such as the Ol~,A, and a public key algorithm.
Various key m~n~Eernent functions, data cryptography functions, and other data processing functions are possible using control vectors, in accordance with the inventioll. A system administratol- can exercise flexi-bility in the implementation of his security policy by selccting appropriate control vcctors in accordance with the invention. A cryptographic facility (Cl~) in the cryptographic architccture is clcscribed in the above cited patents by S. M. Matyas, et al. The Cl:i is an instruction processor for a sct of cryptographic instructions, implementing encryption methods and key generation mcthods. A mcllloly in tlle cryptographic facility stores a set of internal cryptographic variables. Each cryptograptlic instruction is describcd in terms of a sequence vf processing steps required to transform a set of input parametcrs to a sct of output param~ters.
A cryptographic -facility application program (Cl AP) is also describc(l in the refcrenced patents and patent applications, which defines an invocation method, as a calling scquence, for eacll cryptographic instruction consisting of an instruction mnemonic and an addrcss with corrcspollding input and output parameters.
Public key encryption algorithms are described in a papcr by W. I)iffic and M. Ii. Ilcllman cntitled ~I'rivacy and Authentication: An Introduction to Cryptography,~ I'ro~eedi~gs ~f ~Ite 11~1~1, Volumc 67, No. 3, March 1979, pp. 397-427. rublic key systems are based on dispellsing with the secrct kcy distribulion channel, as long as the channel has a sufficient level of integrity. In a public kcy cryptographic system, two keys are used, one for enciphering and one for deciphering. I'ublic key algolilllm syslcms are designcd so that it is easy to generate a random pair of inverse keys ru for enciplleritlg and l'R for clecipllcrillg and it is casy to operate with PU and PR, but is computationally infeasible to compute r~R frOtn P~ acll user generates a pail of inverse transforms, PU and l'R. Ilc kceps thc deciE>llcritlg tr.msfolmalioll l'R sccret, and makes the enciphering transformation I'U public by placing it in a public dircctory. Anyolle can llOW CllCrypt IlleSSageS
and send them to the user, but no one else can decipher messages intendcd for him. It is possiblc, and often desirable, to encipher with PU and decipher with PR l~or this reasoll, I'U is usually called a public key and PR is usually called a private key. A corollary feature of public key cryptographic systems is the provision of a digital signature which uniquely identifies the sen~ler of a mcssagc. If user A wishes to send a signed message M to user B, he operates on it with his private kcy rR to produce thc signed message S. I'R was used as A's deciphering key when privacy was desired, but it is llOW used as his "encip}lering" Icey. Whe user B receives the message S, he can recover the messagc M by operating on the ciphertext S with A's public PIJ. By successfully decryptillg A's messagc, the receiver 13 has concl~lsive proof it camc from thc sender A. E~xamples of public key cryptography are providcd itl the following U. S. patents: USP 4,218,582 to Ilellman, et al., "Public Key Cryptographic /~pparatus and Mc~hod;" I~SI' 4,200,77() to llellman, et al., ~Cryptographic Apparalus and Metllod;" and USI' 4,4()5,~29 to Rivcst, ct al., "(,ryptograp}lic Communi-cations System and Method."
Most cryptographic systems make use of many difrercnl types of keys, so that information cncryptcd with a key of one type is not affected by using a key of another typc. A kcy is assigncd a lypc On the basis of the information the key encrypts or the use bei~Ig madc of tllc kcy. I or cxan7l-1c, a data-crlcl-yptilIg key cnclypts data. A key-encrypting key encrypts keys. ~ I'lN-cnclyr)tillg kcy encryl-ts pclson~l idcntificatioll numbers (I'INs) used in electronic funds transfer and point-of-s~lc applicaliolls. A MA(' kcy is usccl to gcnerate and authenticate message authentication codes (MA('s).
The use of encryption is based on a strategy of pro~ccting a l~rgc ilmoutll of information (a data file or communications session) with a sm~ller additional amoullt of infortnatioll (a singlc key). Sophisticatcd key hierarchies have been devised using this principle. I~or e.Yamplc, ~J,S I'atcnts 4,~5(),()17, 4,941,176, 4,918,728, 4,924,514, which are based on a symmetric key algorithtn sucll as the l)ata l ncl-yption i~lgoritllm (I)E,A), make use of a key hierarchy wherein keys belonging to a cryptograr-llic dcvicc arc cncryptc(l with a single master key and stored in a key data set. The mastcr key is storc(l in clear fonn withiIl the cryptographic hardware. The concept of ~Ising a single master key to cncrypt kcys storc(i in a kcy datll set is known as the master key concept (see C.EI. Meyer and S.M. Matycls, (~r~ J~Ial)ltJ~--A 1~1ew l)if7l~ On in ~,~om~ut(?~ ata 2 Puhiic Key Cryptosystem Key Managcmcrll 13ascd ~ nlrol Vcc~

-Security, John Wiley & Sons, Inc., New York, 1982.). Ulltil now, thc master key concept has been applied only to cryptographic systems bascd on a symmetric key ctyptographic algoritllm. I lowever, the present invention extends the master key concept and teacllcs how it may be applied to cryptographic systems based on an asymmetric key cryptographic algorithm, and more particularly how it may be applied to cryptographic systems incorporating both asymmetric and symmctric key cryptograpllic algorithms, generally called hybrid cryptographic systems. The reader will appreciate that in a public key based cryptograp}lic system employing (I) an asyrnmetric algorithm or (2) both asymmetric and symmetric algorithms, there is still a need to use many public and private keys pairs. Ilence, at a minimum, the private keys must be stored in encrypted form outside the cryptographic hardware.
In order for a cryptographic systetn cmploying the master key conccpt to be ma(~e operable, each device must first be initiali~ed with a master key and one or more othcl keys to permit thc cryptographic system to communicate cryptographically with other cryptograpllic systems or to distril utc kcys to other cryptographic systems. Typically, these keys are generated and installc(l using manual entry techniqucs. In a well-clesigned cryptographic system, all other keys are generatcd and han(lled by tlle cryptograpllic system automatically.
Keys generated by the cryptographic system are stored in encryptc(l form in a cryptograpllic key data set or transrnitted in encrypted form to a designated receiving devicc whcre thc key is itnportcd (i.e., rc-encrypted to a form suitable for storage and use at the receiving de~ice). I hus, an important fcature of any key manage-ment scheme is the method used to encrypt keys ror safc storage in a cryptogr~lphic kcy data set.
At the time a key is generatecl, the user or user application dctcrmilles, fiom among the range of options permitted by the key management, the form of each generated l~ey ror example, a generated key can be produced (I) in clear form, (2) in encryp~ed form suitable f'or storage in a cryptographic key data set, or (3) in encrypted form suitable for distribution to a designated rcceiving dcvicc. (~enerally, cryptographic systems have different options for generating keys in these dif~'erent forms. /~lso, at the time a key is genelated, the user or user application determ.ines, from among the range of options permitted hy the key management, the type and usage of each generated key. Type and usage information are examplcs of a class of key-related infortnatioll called control information. I~or example, in US l'atcnts 4,850,()17, 4,941,176, 4,918,728, 4,924,514, 4,924,515, and 5,007,089, the control infortnation is embodie(l within a data variable called the control vector. The control vector concepts taught in these lJS l~tcnts is summari%ed in a paper by S. M.
Matyas entitled "Key handl.ing with control vcctors," InM ~ tlm.~ .Joun7al, Volume 3n, No. 2, 1991, pp.
151-174.

PUsl lC KEY CRYl~l OSYS l EM KIIY I~lANA(il l\ll,N'I' 13ASI,I) ()N (:'()N'I'KC)I, Vl: C'r'ORS 3 2 0 7 5 3 2 ~
lS~ief I~CSCri/7~ 7f t1~ D~nl~i7~,~s TlIese an(l otller objects features and advantages of the invention will be more fully appreciated with reference to the accompanying figures.
Fig. I is a block diagram illustratioIl of the process to encrypting Iceys and dccrypting keys in a DE~A-based cryptogral~hic system using the control vector encrypt (CVE) and control vector decrypt (CVD) algorithms.
Fig. 2 is a block diagram ilhlstration of the CVE algorithlll implemeIlted in a DEA-based crypt.ographic syst en I .
I:ig. 3 is a block diagram illustratiot-l of the CVD algorithm implemeIlted in a I~F.A-based cryptographic SyStCIII.
~ig. 4 is a block diagram illustration of the hasllil-lg algorithm ha implemented in the CVE and CVD
algoritllllIs of Figs. 1 2 and 3.
Fig. 5 is a block diagram illustration of the Modification Detection Code (MI)C-2) algorithm.
IFig. 6 is a block diagram illustration of a first embodiment of the invention wherein the generated pllblic an(1 private keys storc-d outside the cryptographic facility are protecte(l writll a commlltative asylllmctric system master key pair (PUO PR0).
Fig. 7 is a l)lock diagram illustration of a second emhodimellt of the invelltioIl wherein tlle generated public and private keys stored outside the cryptographic facility are protected witlI a symmetric system master key I~M.
I ig. 8 is a block diagr utl illustratioll of a public key key generatioIl algorithlll (IC(GA).
Fig. 9 illustrates the fomlats of tlle PU key record and PR key record.
I~ig. I() is a block diagram illustration of the Clenerate Public and Private ICey Pair (GPUPR) instructioIl.
I ig. 11 illustrates the formats of the PU key token and the PR key tokeIl.
I:ig. 12 ilhlstrates a cc)mlntlllications network 10 including a plurality of data processors each of which incllldes a crypt(~gral~hic system.
Fig. 13 is a hlock diagram of a cryptograplIic system 22.
Fig. 14 is a bk~ck diagraItl of a cryptographic facility 30.
Fig. 15 is a block diagraIll illustration of the cryptographic algoritllms 144 conlpc)Ilent of the cryptographic facility 30 contaiIlillg the key record encrypt and key record decrypt algorithms.
Fig. I () is a flOw diagram of a first embodiment of key record encrypt algorithm 12.
I ig. 17 is a flow diagram of a first embodimellt of key record decrypt algorithm 13.
Fig. 18 is a flow diagram of a second embodiment of key record encrypt algorithm 12.
Fig. 19 is a flow diagram of a second embodinleIlt of key record decrypt algorithm 13.
Fig. 20 is a functioIlal block diagram illustrating the recovery of two private keys and their use in two public key algorithnIs to fulfill two different cryptographic service reqllests.

~ r~

I'ig. 21 is a block diagram sh(.)willg the production of an internal key token from a key record and the productioll of an exterrlal key token from a key record.
Fig. 22 is a block diagram showirlg the production of an internal key token from an internal key llnit prodllce(t from a key record and the production of an external key token from an external key Ullit produced from a key record.
Fig. 23 lists the comporlents of the Instruction I'rocessor 142.
Fig. 24 shows the elements of the Collfigllration Table in the CE' Ellvirorllnerlt Memory 146.
Fig. 25 shows the main elelllellts of the CryptograE~l1icAlgoritl1llls 144.
Fig. 26 is a block diagrall1 illustratioll of the compc)nents of tlle CE' Environmel1t.
Fig. 27 shovvs the instructions controlled by the D~FINE, AUTI I CON'I'ROI., AUTI 1, and EN~BLE fields in the Collfigllration Vector.
Fig. 28 is a block diagram illustration of the MDC 'I'able.
Fig. 29 is a block diagram illustration of the Counter Table.
I'ig. 3() illustrates the contrc)l vector hierarchy of Public ICey Cryptographic Design (PICCD) keys.
E-ig. 31 is a block diagranl ilhlstratioll of the fields in a control vector associated with a private aulll~llticatioll key.
~ig. 32 is a l~lock diagram illustration of the fields in a control vector associated with a private cert,ification key.
}ig. 33 is a block diagram illustratiorl of the fields in a control vector associaled with a private key mallagelllellt key.
Fig. 34 is a block diagram illustration of the fields in a control vector associated with a private user key.
Fig. 35 is a block diagrarn illustration of t,he fields in a control vector associated with a public autllelllication key, Fig. 36 is a block dia~rarn illustration of the fields in a control veck)r associated with a public cert,ification key.
E'ig. 37 is a block diagrarn illustration of the fields in a control vcctor associated with a yublic key management key.
I~ig. .~ is a block diagralrl ilhlstration of the fields in a control vect,or associated with a public user key.
Fig. 39 is a hlock diagram illustrat,ion of the fields in a hasll vector.
In a cryptographic system employing control vectors, every key IC has an associated c.~ntrol vecl,or C. Thus, IC and C denote a 2-tuple, where K initializes the cryptographic algorithrll by selecting an enciphering transfonrlatiorl and C initializes the cryptographic hardware by selecting a set of cryptographic instructions, modes, and ~Isage that IC is grant.ed. Implementation of the control vector concept requires that IC and C be coupled cryptograE~hically. Otherwise, the key-nsage attriblltes granted to IC by C could be changed by merely rcplacing (' Witll anotller control vector. Thc method for accomplishillg t,his is based on integrating C into the furlctiorls used to encrypt and decrypt keys, called control vector encryption (CVE) and control . ~

207 )~29 vector decryption (CVD). Fig. I is a block diagram illustratioll showillg the implelncntatioIl of the CVI~ and CVD algorithms withill a cryptographic facility 30. Cl' :3() contaills a ('Vl~, algorithm 1, a ('VD algorithm 2, a master key (KM) 3, a to-be-encrypted key K 4, and a recovcrcd key K 5. 'I'lle ( VE algorithm I enclypts a clear key K 4 within CF 30 using a variant key KM + C formed as the 1'~ xclusive ()R product of master key KM 3 stored within CE~ 30 and control vcctor C' 6 spccificd as ~n input to ('1; ~0 to producc an output encrypted key value of the form e~KM + C(K) 7. Notc tllat ~+ " dcllotcs lllc l~,xclusivc 0R opcration and e~ denotes encryption with a 128-bit key. 'I'he operation of cncryptioIl consists of cncrypting K with the leftmost 64 bits of KM + C then decrypting the rcsult wilh the rightmost 64 bits of KM + C and then encrypting that result with the leftmost 64 bits of KM + C. 'I'he (,VI) algorithn1 2 dccrypts the encrypted key e~KM+C(K) 9 specified as an input to Cl~ 30 with the variant key KM+(' formed as the Exclusive-OR product of master key KM 3 stored withill ('1; 30 and control vector C 8 spccified as an input to CF 30 to produce an output clear key K 5. The opcration of clccryption consists of decryptillg e*KM + C(K) with the leftmost 64 bit of KM + C then cnclyl-litlg the result with tlle rightmost 64 bits of KM + C and then decrypting that result with the lel'lmost 64 bits of KM + C. 'I'hc CVI, algol-itlltn is used to encrypt and protect keys stored outside thc cr;. 'I'hc ('Vl) algoritllln is used to decrypt alld rccovcr keys to be processed within the CF.
Fig. 2 is a block diagram illustration of the control vcctor cnclyptioll (('Vl,) algorit}lm. Referrillg to l ig. 2, C is an input control vector whose lengtll is a multiplc of' 64 hits; KK is a 128-bit kcy-encryptitlg key COIl-sisting of a leftmost 64-bit part KKI, and a rightmost 64-bit part KKR, i.c., KK = (KKI"KKR); K is a 64-bit key or the leftmost or rightmost 64-bit part of a 128-bit key to hc cncryptc(l. 'I'hc specirlcatioll of KK
is meant to be very general. For example, KK can bc lllc mastcr kcy KM, or somc otllcr kcy-encryptillg key. The inputs are processed as follows. Colltrol vector C is opcrate(l on hy llaslling algorithlll ha, described below, to produce the 128-bit output hasll vector II. Il is l~,xclusivc-ORe(l with KK to produce 128-bit output KK + Il. Finally, K is encrypted with KK + Il to plo(luce ou1put e~KK ~- II(K), where e~
indicates encryption with 128-bit key KK + II using an cncryptioll-dccryptioll-cllclyptioll (e-d-e) algorithm as defined in ANSI Standard X9.17-1985 entitled "American National ~tandard ror l inallcial Institution Key M~n~ment (Wholesale)", 1985, and in ISO Standard 8732 cntitled ~13anking--Key Managemcllt (Whole-sale)~, 1988.
I~ig. 3 is a block diagram illustration of the control vector decl~ption (('Vl)) algoritllm. Rcferring to Fig. 3, C is an input control vector whose lengtll is a multiple of 64 bits; KK is a 128-bit key-encrypting key cOn-sisting of a leftmost 64-bit part KKI, and a rightmost 64-bit palt KKR, i.e., KK = (KKI,,KKR);
e~KK + I-I(K) is the encrypted key to be dccrypted. Control vector C is operated on by hastling algorithm ha, described below, to produce the 128-bit output hasll vector II. Il is l,xclusive-ORed with KK to produce 128-bit output KK + I-I. T-inally, e~KK + I T(K) is dccryptcd with KK + T I IJSillg a dccryption-encryption-decryption (d-e-d) algorithm to produce output K. 'I'he d-e-d algorithm is just the inverse of the e-d-e algorithm.
Fig. 4 is a block diagram illustration of hashing algorithm ln~l. I lasllillg algorithm h,l operatcs on input control vector C (whose length is a multiple of 64 bits) to prod-lce a 12~-bit o~ltp~lt 11, ~hcre 11 = ha(C).
If C is 64 bits, ha(C) is set equal to (C,C), where thc comlna denotcs COIlCatCIlaliOIl, all(l thc extcnsion ficld (bits 45,46) in ha(C) is set equal to n oo . I hat is, ha ~CtS likc a ('OllCatCn.lliOIl l'Ull(tiOIl. If C is 128 bits, ha(C) is set equal to C, and the extension field in ha(C) is set equal lo 13'()1'. '1'hal is, ha acts like an iden~ity function. If C is greater than 128 bits, h t((C) iS SCt equal to a 128 bi~ OllC ~ty cryptograrllic rullctiOn of (,, e.g. a 128-bit modification detection code calculate(l l-y the Ml)(~-2 algorithlll in l ig. 5, and the extensioll f1eld in ha(C) is set equal to B'10'. In each of the three cases, the eightll l it of' eacll bytc in ha(C) is adjusted such that each byte has even parity. This adjustment ellsules that whell h~l(C) iS exclusive-ORed with KK, the variant key KK + h(C) has the same parity as K K. 'I'he extension ficld in h t((.') serves to ensure, for a fixed KK, that the set of keys of the form KK + h(C) cOnsists of thlee disjoillt subsets S I, S2, and S3, where Sl denotes the keys resulting from all 64-bit control vectors, S2 dellotes the keys resultillg from all 128-bit control vectors, and S3 denotes the keys resulting from all contl-ol vectors larger thall 128 bits. 'I'his l7revents a form of cheating wherein the CVD algorithm is tricked intO decl~pting tll cncrypled key using a false control vector. IIas}ling algorithm ha fulfills two importallt objectives. I irst, it hall(lles hoth short and long control vectors, thus ensuring that a key-managemellt scheme base(l on the contlol vectol concert is open-6 Public Key Cryl tosyslem Key Managerrlet~ ascd on ( onll ol Veclor s 207532~

ended. Second, the processing overhead lo handlc short conlrol vcctols (64 an(l 12~ bits) is minimi7.ecl so asto have minimal impact on the key management scheme.
As an alternate embodiment, the length of the input control vcctor lo the hashillg algorithm lla can be eneoded in the extension field (bits 45,46). If the input control vcctor is 64 bits long, the rleld is B'OO', if the input control vector is 128 bits long, the field is set ~o 13'()1' an(l if lhe inpul control vcclor is longer thall 128 bits, the field is set to B'10'. This has the advantage of simplifying the hasllillg algoritllm ha so that it does not need to set the extension field in tlle resulting output ll, except if the input control vector was greater than 128 bits.
Eiig. S is a block diagrarn illustration of a cryptograpllic functioll for calculating a 12~-bit modification detection code (MDC), called the MDC-2 algorithm. Referrillg lo l~ig. 5, K I = X'5252525252525252' and Ll = X'2525252525252525' are two 64-bit nonsecret constant keys. 'I'hey ale used only to process the rlrst 64-bit block of plaintext, Yl . Thereafter, input value K2, K~, ..., etc. arc based 011 output values (A 1,1)1), ~1~2,D2), ..., ete., and input values 1,2, 1,3, ..., etc. are bascd on output values (C1,131), (C2,n2)~ ..., etc.
Tbat is, the outputs of each iteration are fed back and usecl as the kcys at tlle next iteration. The 32-bit swapping function merely replaces 32-bit value 13 witll .~2-hit villuc 1) an(l .~2-hit value 1) witll 32-bit value B.
In summary, the prior art describes a method for controllillg key usage in cryptograpllic systems based on a symmetrie key cryptographie algorithm sueh as the I~ ,A. Key usage information is stored in a control vector C which is cryptographically coupled with the key K USillg control vector cncryptioll and control vector decryption algorithms, CV~ and CVI), respectively. 'I'he CVI~ and CVI) algorithllls can handle both short and long control vectors. 'I'he only restriction on length is that the control vector must be a multiple of 64 bits. The control vector itself consists of a group of sub~;clds, where each subfielcl has it own definition and use within the key management to control the proccssing of the key. I~,ncoding the control vector as a group of independent subfields has many advantages. The processing control vector checking need only concern itself with those subfields that pertain to the requested key usage. 'I'hus, while the control vector may have many subfields, a partieular eryptographie instruetion may only neecl to eheek the eneoded infor-mation in a few subfields. This speeds up the eontrol vector checking process. Another important charac-teristic of the control vector is that the control vector accompanies (either explicitly or implicitly) the key wherever it goes. 'I'his is beeause the eorrect noll-seclct control vector must be specirled to reeover the eorrect secret key value. Thus, the control vector is availablc and Call be checke(l at many different places within the cryptographic system: applicalioll program, cryptographic software, and cryptographic hardwale.
Within a cryptographic system, the CVE and CVI) algorilhms are implemented so that their operation is transparent to the system. All clear keys are encrypted w ith tlle CVE algorithm before the keys are output from the cryptographic hardware. All encrypted keys arc clecrypted with the CVI) algorithm before they are processed within the cryptographic hardware. Evell witllill the cryptograpllic hardware, these services can be provided transparently from the cryptographic instrucliolls tlnat process keys. I~y employing a single pair of control vector encryption and deeryption fullctiolls, mOst of tlle complexily associate(l with key handling can be encoded as information fields within the control veclor allcl wi~hill tllc checl~ g processes themselves, whereas the process of enerypting and deerypting keys ancl linkillg eontrol vector information to the key ean be handled with one eommon method.
'Ihe present invention provides a method for incorporatillg conll-ol vcctors inlo a key mallagemellt scheme that uses a public key algorithm. The rea(3er will apl-reciate Ih.lt ~vhile the advalltages Or eontrolling key usage with the eontrol veetor are universal in nalure, the metllo(ls for aeeolnplisllillg tllis ean vary depen(li]lg on the attributes of the eryptographie algorithm employecl. I or example, consider the snethod of enclypting K with a variant key KK + C to produee eKK + ('(K). In tllis case, K is encrypte~l using the l)a~a Eneryption Algorithm, in whieh ease the l~xelusive-OR product of KK allcl C is always guaranteed to produee a valid l)FA key, as DE~A keys, ignoring parity bits, are maximally dellse in the set of all binary numbers of their magnitude. When the cryptographie algoritl~m is ian asylnmctrie algorithlll such as the RSA algorithtn, there are two keys l'lJ an(l I'R. In gcllenll, if (I'~J,I'R) is a vali(l key pair, then (PtJ + C,I'R + C) is not a valid key pair for an arhitraly vlllue ('. 'l'his is hecause t}lC l'tJ an(l T'R key values YUnl.lCKEY(,RYPlOSYSlrl\1 KliY M/~N/\(il MliNI 13~SI l~()N (,()N~IROI,VI~ IORS 7 207a329 meet certain mathematical constraints and are sparse itl the sct of all binary nulllbers of thcir magni~ude.
Thus, an alternate method for coupling C to I'U and l'R is needcd. Morcover, encrypting one key with another can sometimes be cumbersome, e.g., wl1ell an the RSA algorit}1m is cmployed it is cumbersome to encrypt a key of one modulus value with a key of anothcr mo(lulus value if the value of thc frst modulus is greater than the value of the second modulus. 'I'his cumbersomc situatiol1 must be dealt with in tlle under-lying design so that a general methodology is ach;eved. rl'hc present invcntioIl will show how this is accom-plished. In hybrid cryptographic systems where both a symmetric and asymmetric algoritl1m are implemented, the public and private keys bclongit1g to the asymmetric algoritl1m can be encrypted with keys belonging to the symmetric key algorithm. In that casc, thc metho(l for coupling a kcy and control vector can be similar to that described in the prior art. Ilowevcr, CVCIl here thele are subtle differences that affect the design ehoice. For example, the public and private keys belonging to tl1e asymmetric key algorithm are typically longer than the keys belonging to the symmetric key algoritl1m. /~lso, the possibility that the public and private keys will be of different and varying lengths must be ad(lresscd. 51 2-bit R.SA keys are not uncommon, where a DEA master key is generally 12~ bits. 'I'hus, the CVI~, an(l (~VI) algorithms must be adjusted to permit long asymmetric keys to be encryptcd with shorter (e.g., I 28-bit) symmetric keys.
Another difference is that, in theory, the public keys nee(l n0t be encryptcd wl1en stored in a cryptographic key data set. IIowever, there are advantages to hancllillg both the public and private keys similarly. ~s examples, the same method for coupling thc control vector and the private key can be uscd to couplc the control vector and the public key, and the same metl1od of authel1tic.ltil1g thc kcy valuc C.lll be uscd. Also, handling the public and private keys in the same way means that all keys are hal1dle(1 and processed just one way, which reduces the complexity of the key management design. 'I'hat is, as ~l~e private key must be encrypted to ensure that its value does not become knowIl, the puhlic key may also he encl-ypted to simplify tlle internal key managemcnt design, as thell the key (whetller puhlic or privatc) will always be decrypted before being processed further.
When a public key algorithm is employed, the key lengtl1s or key sixes are not fixcd by the algorithm as with the DEA. In this case, the cryptographie system will most likely havc to opcrate with public and private keys of different lengths, varying as much as several hun(lred bits. 'I'herefore, the (,VI~, and CVI~ algorithms must be designed to handle public and private keys with varying Icngths. It is also important that the length of the key be made transparent from the application and the cryptograrl1ic system using the key.
In cryptographic systems based on the DI~/~, many cryptographic instructions that han(lle bulk data must be streamlined so that performance is not degraded by the introductiol1 of the control vector and tl1e encryptio and dccryption algorithms (CVI~ and CVI)). Ilowever, when a l-ublic kcy (I'K) algorithm is cmployed, the individual steps of encryption and clecryption are orders of magllitu(le slower th.lll cncryptiOIl ancl decryption with the DE~. Tl1us, the design of a key managemetlt scheme hasc(l on a l'K algc~rithll1 can have diffèrel1t underlying objectives. ~or example, key processing al1d kcs~ hal1dlil1g operations that inlloduce unwarraTIted processing overhead in a I)I:~A-based key mal1agelncllt, may in(lccd bc ~ppropriatc lor a l'K-based kcy man-agement. This is because the processing overhead whilc lalgc comp.lrcd to onc I~I~A encryl tion may be insignificant compated to one l'K encryptiom In the p rcsellt illVCTltiOn, a strategy is pulsuc(l of authentieating a key dynamieally within the cryptographic har(l-vare as part of' tlle ('Vl) algorithm. Rela-tively speaking, while this introduces signifieant processing overllea(l in a l)l~ -basc(l key mallagemellt scheme, it adds very little proeessing overhead in a I'K-base(l ke~ mallagelTIellt sehell1e. I lowc ver, this ensures that valid and strong J'R and J~J keys are used, an(l tllat an itlValiCI (i.C., itlSCClllC) lcey value is n0t inadvertently used.
Objects of the Invenllon It is therefore an objeet of the inventiol1 to provide .111 imrrovc(l mclllo(l for conlr(?lling tllc usage of public and private keys.
It is another object of the invention to perrnit large amolll1ts of COllltOI inform.lti(!ll for tl1e public and private keys.

'c' Public Key Cryt losysLem Key ManagclTIerll 13.~se<J oll ( onlrol ~CCIolS

2Q7~29 It is another object of tlle invention to pGrmit the application, thc systcm sof'twarG, al~d tllc systcm hardware to check and set portions of the control informatiol1 It is another object of thc invention to permit keys to be authcl1ticated withit1 thG crypto hardware as part of the key recovery process, so that all keys are authenticatcd hcrorc tl1cy arG uscd by thc crypto hardwarG.
It is another object of t'he inventiol1 to permit an opGn-et1(lcd dcsign allowing new and expanded key USagG
to be added to the architecture.
It is another object of the invention to provide a single consistcnl mctllo(l for hal1dlillg both public and private keys.
It is another object of the invention to allow the physical makcup of tllc kcys to appGar tr<u1sparel1t.
It is another object of the invet1tion to allow uscrs to pott thcir public an(l privatc kcys frotn Onc cryptographic system to anotl1er.
It is another object of the invention to basc control vector encryrt al-(l dccrypt on a Dr A master key Or 128 bits.
It is another object of the invel1tion to provide a gcncml method rOr control vcctor cncrypt an(l dccrypt where the system master key is a privatc and public kcy pair of a commut<ltivc asymmctric cryptographic algorithm (i.e., no DEA or other symmetric algoritht1l mastcr lccy is uscd).
It is another objèct of the invention to providc a gcncral mctl1o(1 for control vector enclypt and decrypt where the system master key is a quadruple of two key pairs of privatc al1d public kcys of a non-cornmutative asymmetric cryptographic algorithm. SpGcifically thc systctl1 mastcr kGy quadruple consists of (I) a PUI master key used to encrypt the public and private keys kept outsidG the cryptographic facility, (2) a I'RI master key used to decrypt the public and private keys kcpt outsi(le tl1c cryptographic facility, (3) a PR2 master key used to generate an authentication signature for thc public and private keys kept outside the cryptographic facility, and (4) a PU2 master key usccl to vGrify thG authcl1tication signatule of the public and private keys kept outside the cryptographic facility.
It is another object of tl1e inventiol1 to provide a gencral mcthod for control vector Gncrypt and decrypt where thè system master key is a quadruplG of one kGy pair of private and public keys USiI1g public key algorithm I and anothèr key pair of private and public keys using public key algorithm 2. Specifically the system master key quadruple consists of (I) a l'lJI m<lster key (bascd On public kcy algorithm 1) used to encrypt the public and private keys kcpt outsidc thc cryptographic facility, (2) a l'R 1 master key (using public key algorithm 1) used to decrypt the public and privatG keys kept outsidc thc cryptographic facility, (3) a 1'R2 master key (using public key algoritht1l 2) uscd to ~Gncl-atc all autllcnticatiotl signature for tilG
public and private keys kept outside the cryptogtaphic facilily, and (4) a 1~2 mastcr kcy (using public key algorithm 2) used to verify the authenticatiot1 signaturc of Il1e puhlic al1d privatc keys kcpt outside thc cryptographic facility.
'I'he invention describes a method for encryptil1g the pul-lic al1d pl-ivatc kcys of' a cryptographic asymmctric key (public key) algorithm, when these keys arc s~orc(l outsidG thc sccurc boundary of the cryptographic facility (i.e., cryptographic hardware) and for decryptit1g thcsc kcys whcll they aTc proccssc(l or usecl withi the secure boundary of the cryptographic facility. I'hc so-produccd cncryplcd kGys may bc kcpt in a cryptographic key data set belonging to thG cryptographic systcm softwarc or thcy may bc matl.lged by the cryptograp'hic application programs that use the keys. 'I he public alld priv<ltc kcys arc Gncrypted by a system master key stored in clear fonn withil1 the sccurG boun(lary of thc cryptographic facility Tn situations where the cryptographic system implements a symmetric kcy alKorithln in ad(li~iol1 to thc asymmGtric kcy algorithm the system master key can be a symmGtric kcy. I or c~amplc, if thc cryptograpl1ic systGtn imple-ments both Dl~/~ and RS~ algorithms, thcn the RSA puhlic and privatc kcys arG protcctcd with a 128-bit D~A master key.

PU13LIC KrY CRYPIOSYSII M KEY MANA(JI MI NI' 13ASI I) ()N C()Nl'l~OI. VE(,IORS 9 207 ~329 In situations where the cryptographic system implements a commutative asymmctric key algorithm (such as the RSA algorithm), the system master key consists of a spccial public and private key pair (I'IJ0,I'RU) stored in clear form within the cryptographic facility. ~ comlllutative asymmetric key alKorithm is one where the operation of encryption followed by decryption is equal to tlle operation of dccryption followed by encryption in that both result in the original plaintcxt. I l-e mastcr public kcy l~J0 is used to cncrypt and verify authenticity for public and private keys stored outside thc cryptographic facility and the master private key rR0 is used to decrypt and generate authenticatioll signaturcs on the public and private keys stored outside the cryptographic facility. In addition to providing a means to cncrypt arl(l dccrypt thc public and private keys stored outside the cryptographic facility, thc itlVCll~iOn also providcs a means to cryptographically couple the control vector witll the public ancl private kcys alld to aut}lellticat.c the public and private keys using a special authenticator produccd witllill the clyptographic racility.
In situations where the cryptographic syslem implcmellts only a noll-comlnutative asytnmetric kcy algo-rithm, the system master key may consist of a special quadrul-lc composed of a two public and privatc key pairs ((PUI,PRI),(PU2,PR2)) stored in clear form withill the cryptographic facility. A noll-commutative asyrnrnetric key algorithm is one where encryption must always bc done bcrorc dccryption. Mastcr public key PUI is used to encrypt public and private keys slored outside tllc cryptograptlic facility and master private key PRI is used to decrypt public and private keys stored outside the cryptographic facility. Master public key Ptl2 is used to verify tlle authcnticity of and privalc kcys storcd outsidc the cryptograpllic faciLity and master plivate key PR2 is used to generate authenticatioll signaturcs for the public and private keys stored outside the cryptographic facility.
In situations where the cryptographic system implemcllts t~vo diffcrcnt asymmetric algoritllms, where OllC
algoritl~n is used for key encryption/decryption and another (diirercllt) algorithm is uscd for authentication, the system master key consists of a special quadruple composed of a two public and private key pairs ((PU I ,PRl),(PU2,PR2)) stored in clear forrn within the cryptographic facility. (I'II 1 ,PR 1) comprise an asymmetric key pair from a first public key a]gorithun and (PIJ2,1'R2) comprise an asymmetric kcy pair from a second public key algorithm, which is different from the first algorithm. Master public key l'U I is used to encrypt public and private keys stored outside the cryptographic faciiity and master privatc kcy l'R I is used to decrypt public and private keys stored outside the cryptographic facility. Master public key PIJ2 is used to verify the authenticity of public and private keys stored outside tllc cryptoKraph;c facility and master private key PR2 is used to generate authentication signatures for thc public and private keys stored outsidc the cryptographic facility.
Note also, as an alternate embodimcnt, if the public key algorithm is not commutative, if both the public key and the private keys that are used as tlle master key pair are kept sccret, thell only onc master key pair is needed In this case, the (secret) public key is uscd to encrypt the autllcllticatioll record and the private key is used to decrypt it. Normally this would represent a sccurity exposure, but as the public key is secret and known only inside the crypto~raphic facility, there is no exposurc. (~are must he takcll to ensure that thc (secret) public key is never inadvertently exposed.
Fig. 6 illustrates a cryptographic facility 30 contaillillg a commutativc asymmctric algorithm master key. In this case, the public and private keys stored outsidc thc cryptograp}lic facility 3n are protccted (i.e., encrypted for privacy and authenticated) with an asymmetric master key pair, dcsignatcd (I~J(),I'R0). Outsidc the cryptographic facility 30, all public and private keys are storcd in kcy tokcns. I'ublic keys are stored in public key tokens (PU key tokens) and private kcys arc stored in privalc kcy tokcns ~I'R kcy tokcns). Tlle PU key tokens and l'R key tokens are stored in a cryptographic kcy dat.l set 32 managcd by the cryptographic systcm software, or they may be managed by thc cryptoKrarllic applicatioll programs them-selves (not shown in Fig. 6).
~ig. 7 illustrates a cryptographic facility 30 containillg an asymmctric kcy algoritllm and a symmctric key algorithm. In this case, the public and private keys storcd outsidc tllc cryptograrllic facility 30 are protectc(l with a syrnmetric system master key, designated KM. lf tllc symmctlic kcy algolitllm is thc l)l A, thell KM
is a 12~-bit key, as described in the prior art. As in l ig. (~, thc puhlic alld private kcys are storcd in l'U key tokens and E'R key tokens. The 1~] key tokcns an(l l'R kcy tokcns alc storc(l in a cryptographic key data o Public Key Cryplosyslem Key Managen)crll 13asc~l o~ onllol ~'cclors 2~7a329 set 32 managed by the cryptographic system soft~ are, or thcy may bc matlagcd hy the ct~ptographic applica-tion programs themselves (not shown in r~ig. 7).
The reader will appreciate from the full description of tlle invetltion, providcd hclow that, except for the special functions that encrypt and decrypt the keys in thc kcy tokctls, tlle meatls for p rotectillg kcys based on any of the following metllods:
(1) a symmetric system master key (KM), (2) a commutative asymmetric system master key pair (PU~,PR~), (3) a non-commutative asymmetric master key pair (PW,PR~) where both the public and private key are kept secret, (4) a non-commutative asymmetric master key qu~druple ((PU1,PR1),(PU2,PR2)), or (5) a master key quadruple ((PU1,PR1),(PU2,PR2)) when the first key pair uses one public key algorithm for key encryption/decryption and the second key pair uses another public key algorithm different from the first for authentic~tion can be ~nade transparent to the user of a cryptograpllic systetn. I IIUS, the cryptograpllic instructions tllat process and use the public and private keys and the cryptograp}lic software and cryptographic application programs that handle the public and private key tokcns arc ullarfcctcd by tlle particular encryption and decryption means for storage and recovery of the public and private keys. I his is so because the keys are treated as logical entities. T heir physical characteristics such as lcngtll, fonnat, componcnt make up, etc., are kept transparent to the cryptographic system. Tllis is parti<llly accomplished throug}l the use of special records called the public key record (I'U key record) and privatc kcy record (I'R key rccord) which may have varying length, as the keys they contain may have val-yillg lengt,h. /~11 public and privatc keys generated within the cryptographic system are stored in thesc varyiTlg-lcllgtll kcy records. /~s an altcrnate embodiment, the key records may be set to a fixed si7.e that will contaill the largest si7e public and private keys that will be generated and/or used on the system.
I~ig. 8 illustrates the production of publ;c and private kcys USillg a public key kcy generation algorithm (KGA) 152. In response to a request to generate a (I'IJ,I'R) kcy pair, public kcy generation algorithm 152 causes a (PU,PR) key pair to be generated. The generated public key I'IJ is stored in a E'U key record and the generated private key l'R is stored in a rR key record. I lle I~J key record and I'R key record are returned as outputs. In addition to returning the l'U key rccord and l'R key rccord, the public key gener-ation algorithm 152 may also optionally return a l'lJ_length parameter indicatillg the length of PU key record and a PR_length parameter indicating the length of l'R key record. The optional lengt}l parameters may be useful in implementations where the lengt}ls of 1~11 key rccord and l'R key rccord may vary.
I~ig. 9 illustrates the formats of the l'IJ kcy record ancl I'R key recor(l. I h( I'IJ key record contains parse data that permits the public key to be rccovered from thc record. I hc parse data may be length and dis-placement data of fields in the record. l he I'U key recor(l also contaiIls control inl'ormation that may be useful in describing the record type and type of key or kcys storcd within thc recolcl. I llc l'lJ key rccord also permits one or more public keys to be storcd as a single logical public kcy. l his may be particularly useful in situations where a first public key algorithlll is uscd for I)E/~ kcy encryptioll/decryption purposes, e.g., to distribute VEA keys from one devicc to anotllcr, and a sccoll(l public key algorithm is used for gener-ating and verifying digital signatures. I hus, a first public kcy I~J I is uscd to cncrypt OE/~ kcys and a second public key l'lJ2 is uscd verify digital signaturcs. In such situ;ltions, Ihc cryptographic systeln is designed in such a way that the key processing opcra~ions will know from Ihc contcx~ ol' thc opcrations being perform whetller tlle public key to be used is I~J I or l'~J2. I hc l'R kcy rccord also contains parse data that permits the private key to be recovered from tl~e rccord. I lle l'R kcy rccord also contaills control information that may be useful in describing the recor(l typc an(l type of key or kcys storcd witllin tlle record. ~f he l'R key record also permits one or morc private kcys to be s~orc(l as a singlc 10gical private key.
Thus, a first private key rR I is used to dccryp~ a l)l A key CllCIyptC(I hy tlle first public key l'U 1, and a second private key I'R2 is used to gencrate digital sigIlaturcs for la~cr vcrificatioll hy tllc second public kcy PU2. In such situations, the cryptograp}lic system is dcsiKIlc(l in such a W.'ly tllat tllc key proccssing oper-ations will know from the context of the operatiolls l-cing pcrf'orlnc(l wllctllcr thc pliV.ltC key to be used is l'UJ3LIC KEY CRYI'IOSY~I'EM KEY MANA(31 MI N'I' 13ASI I) O N (()NI~ROI VE cro RS 1l PR1 or PR2. The PU and PR key records keep algorithlll sl)ecif;c an(l key specific information transparent to the cryptograpllic systen . Only the p lblic key algorithm itself that processes the key recorcts need he awar of the interllal strllct~lre and makellp of these key recorcls.
As an alternate embc)dimel t, in certain situations, there may be advant:agcs to maintaillillg the logical key recorcls in two forms: the first containing both the private keys an 11~ublic key for the owner or creator of thl' keys an(l the second contaiIling just the public keys for distributiorl to others. As before if nsing the owller!s logical key record containillg both private and Emblic keys, the correct key t o use can be deterlllilled frolll c on t ~xt .
Fig. 1() illustrates the productic)ll of public and ~rivate key pairs using a Generate Public and l rivate ICey Pair (GPUI R) instrnctioll. Tlle GPUPR instructioll is described in detail in USP 5,201,()00, as cited in the baclcgronlld art. Refcrrillg lIOW to Fig. 1(), the GPUPR instmctio]l 52 is containcd in an instruction prc)cess{)r 142 within the cryptographic facility (CF) 3(). In practice, the Cl~ 30 is implemented within secure harclware, so that keys and cryptographic variables stc:)recl Witllill the ( F 30 are protected, i.e., both the secrccy all(l intcgrity of these keys and cryptogra~ ic variables are protected. The CF 30 also contains a ('1: environll ent nlelll-)ry 14f~ for tlle storage of keys ancl cryptograpllicvariables such as a master key 15.
I~ig. 10 does nOt specit'y whetller the n aster key is (1) a symmetric master key ICM, (2) an asyrrmletric comllllltative n~aster key pair (PU0, PR0), (3) a noncormnutative asylmnetric master key pair (PU0, PR0) where both the public and private key are kept secret, (4) an asynlmetric nollcc)lrmlltative nlaster key quadrllple ((PUI, PRI), (PU2, PR2)), or (5) an asymmetric twoPI~algorithlll master key quadrllple ((I UI, PRI ), (PU2, PR2)) where tlle first pair llses one public key algc)rithln and the seconcl ~air uses a differellt p ublic key algoritllnl for the first. lhe CF 30 also contairls cryl~tographic algorithms 144, which inclu(~es an asynmletric key algorithm 10, an optional symmetric Icey algorithm 11, and an asymmctric kcey generation algorithm (ICGA) 152. The inputs to the GPUPR instruc-tioll at 50 consist of a mo(le, an optional code worc1, I U contrc)l vector, and PR control vector. In respc)llse to a reqllest to execute the GPUI R instrllctioIl at 50, the GPUPR instruction invokes th~ ICGA 152, at 53, passing the mo(le and optional cocle word. Ihe mode indicates to ICGA 152 whether the t obeg nerate(l plll)lic an(1 private kcy pair (PU, PR) are generated from a code word (mode = Pl ) or not (mo(le = no PP ). In response the ICGI~
152 produces a public and private key pair (PU, PR) which are formatted in a PU key record and PR key record. The PU key record and PR key record are returned to the GPUPR instr~lctic)ll at 54. In response, the Gl UPR instrllction bllilds a key token and a 1 R key tokcn containillg tlle encrypted PU key recorcl and encryptecl PR key record, respectively. Each key tokell contaills a control vector and an autheIlticator, as furtller described below. The GPUPR instruction 52 also perfc)rllls consisterlcy checking on the mode and control vector snpplied as inputs at 50. See also USP 5,201,000 cited in the background art for a further diSC'~lSSiOII of this consistency checlcing. The soproduced PU key tokell and PR key token arc retllmed as Ollt l)lltS ~1~ 5 1 .
Fig. I l illustrates the formats of the PU key token and PR key token. The PU key token consists of a heacler, a I U control vector, an encrypted PU key records, and a PU authcnticator. As an alternate enlboclilllellts, the PU key token may consist of a lleader, PU control vector, a plaintext PU key record, and a PU anthenticator. The preferred embodinlent has an encrypted PU key record in the PU key token as thc l R kcy token mllst contaill an encrypte 1 PR key record (to maintairl its secrecy) and doing both PU
alld I l~ kcy tokt ns in the sallle mallller simplifies the processin~. rhe Pl~ key token consists of a header, 11~ colltrol vect:or, an encryptecl PR kcy recor 1, and a PR allthenticator. The header in the PU key token consists of informatioll (e.g., offsets or displacements to start of fields, offsets or displacen ents to end of fiel ls, and/or lellgtlls of fields) that enable the systeln to deternline the slart and end of each other field in the PU kcy t:okc.ll. Tllc l U control vector COllSiStS c)f a PU key type, PU key llsage data, PR key usage data (for h;story pllrposes), algorithnl identifier, algoritllmspecific data, key start date/time, key expiration data/time, device identifier, nscr identifier, key identifier, logical device identifier, and userdefirled data. the fields of PU control vectors are presented in more detail tmder the heading Description of tlle Best Mode for Carrying Ont the Invention . If the system rnaster key is a symlrletric key ICM, then I U key record is encrypted with a variant key derived from l<M, and explained below. If the system master key is an asymmetric key pair (PU0, PR0), then PU key record is encrypted with PU0, as explained below. The PU autllellticat~r is a special authentication code produced at the time the PU key token is cc)llstructed. Later, wherl the PU key tolcen is specified as a parameter input to a cryptographic instruction, the PU authellticator is used to validate the public key as part of key recovery, I-efore the recovered PU is processed willlin ~he Crypt(-)graplliC illStr-lCtiOIl.
I'hc headcr in the PR Icey token consists of inforlllatioll (e.g., offsets or displacelllellts to start of fields, offsets or displacements to end of fields, and!or Icngtlls of fields) that enable tlle system to determine the start and end of each other field in the PR key token The PRcontrol vectors consists of a PR key type, PR
kcy nsage data, PU key usage data (for history purposes), algoritllm ident:ifier, algorithrnspecific data, key start date/timc, key cxpiratioll data!time, device identifier, uscr identifier, Icey identifier, logical device idelltifier, and userdefirle(l data. Tlle fields of PR cont:rc)lve(tors arc presented in more detail under "Description of the Best Mode for Carrying Ollt the Invention". If the system master key is a syrmlletric key ICM, then PR key record is encrypted with a variant lcey derived from ICM, as explained below. If the system master key is an asymmetric key pair (PU0, PRO),thcnt:llePR key record is encrypted witll PU(), as explainedbelow. rhePRalltllerlticatoris a spccial authenticatioll code pro(lllced at the time tlle PR key token is constmcted. I,ater, when the PR key token is specified as a parameter input to a cryplograpllic instruction, the PR autllellticatorisused to validate the publi( key as part of key recovcry, befc)rc the recovered PRis processed within the cryptographic instmctic)n.
In the abovementioned USP 5,201,000 by S.M. Matyas, et al., enlillcd "Gcnerating Pul)lic and Private ICay Pairs Using a l'assphrase", the outputs of key generatc)r algorithm 152 are generatc(l public and private keys, PU and PR, respectively, as defined here. Those skilled in the art will appreciate that the description of the ~TI'UPR instrllction and the key generation algoritllnl in USI' 5,201,000, is for all intents and purposes the same as the dcscriptic)rl provided here, and that returllillg PU an(l PR as outputs from the key generation algoritlllll 152, instead of return PU and PR Icey records does not depart from the ~mderlyillg invellt,ic)ll.

13~r9-91-015 2~75~29 I)eseription of the Best ~Iode for Carrvin~ Out the Invention Environment Descrip~ion: Fig. 12 illustrates a net~ork bloek diagram sho-ving a communications network 10 to ~-hieh is conneeted a plurality of data proeessors ineluding data proeessor 20, data processor 20', and data processor ''0". .~lso ineluded in eaeh data proeessor is a eryptog~raphie system, as sho-vn in E-io. 1 ?.
Data proeessor 20 ineludes er~ptographie system 22, data processor 20' includes cryptographic system 2?' and data processor 20" includes eryptographic system 22". Each data proeessor supports the processin_ of one or more applieations whieh require aeeess to eryptographie serviees SUCII as for the cneryption, decryption and authentieating of applieation data and the L~eneration and installation of eryptographie l;eys.
The er~-ptographie serviees are provided by a seeure eryptographie faeility in eaeh eryptographie system. The network provides the means for the clata proeessors to send and reeeive enerypted data and keys. Various protoeols, that is, formats and proeedural rules, govern the e~cehange of eryptographie quantities bet~veen eommunicating data proeessors in order to ensure the interoperability between them.
Fig. 13 illustrates the eryptographie system 22. In the eryptographie system 22, the eryptographie faeility (CF) 30 has an input 37 from a physie,31 interfaee. The eryptographie faeility aeeess program (CF;~Y) 34 is eoupled to the eryptogr;lphie t'aeility 30 by means of the interfaee 31. The eryptographie key d~ta set (CKDS) 32 is connected to thc ery,ptograpllie faeility aecess program 3~1 by me.ms of the interface 33. The application programs (AI)PL) 36 are connected to the cryptographie faeility access program 3 1 by means of the interface 35.
t~ typical request for cryptographic service is initiated by t~PPL 36 via a function call to the CE-.~P 34 at the interface 35. 'l'he ser-ice request includes key and data parameters, as well as ~ey identifiers whieh Ihe ('F~I' 34 uses to access enerypted keys from the CKDS 32 at the interface 33. The CFAP 34 processes the service request by issuing one or more eryptographie aeeess instruetions to the CF 30 at the interface 31.
The CF 30 may also have an optional physieal interfaee 37 for direet entry of cryptographic variables into the CF 30. Each cryptographic aceess instruetion invoked at the interfaee 31 has a set of input parameters processed by the CF 30 to produee a set of output parameters returned by the CF 30 to the CFAE' 3 1. III
turn, the CFAE) 34 may return output parameters to the APPL 36. The CFAP 34 may also use the output parameters and input parameters to subsequently invoke instructions. If the output parameters contain encrypted keys, then the CFr~P 34, in many cases, may store these encrypted Lieys in the CKDS 3''.
Fig. 14 illustrates the cryptographic facility 30. The cryptographie facility 30 is maintained within a secure boundary 140. The eryptographie faeility 30 ineludes the instruetion processor 142 which is coupled to the cryptographic algorithms 144 which are embodied as e~ecutable code. 'I'he cryptograpllic faciIity envi-ronment memory 146 is coupled to the instruction processor 142. The physical interface can be coupled over line 37 to the Cl~ environment memory 146, as shown in the figure. The instruction processor 14' is coupled to the cryptographic facility access program (CFt~P) 34 by means of the interface at 31.
The instruction processor 142 is a functional element which e~cecutes cryptogr.lp}lic microillstructioIls invoked by the CFt~I' access instruction at the interface 31. For each access instruction, the interface 31 tirst deflnes an instruction mnemonie or operation code used to seleet particular mieroinstructions f'or e~ecution.
Secondly a set of input parameters is passed from the CF.i~I' 3 1 to the CF 30. 'I'hirdly, a set of OUtp~lt parameters is retumed by the CF 30 to the CF~ 3~1. 'I'he instruction processor I 1~ c~;c~cutes the selected instruction by performing an instruction specific se~luence of cryptographic processing steps embodie~l as microinstructions storcd in cryptocraphic microinstruction mcmory 1~. 'rhe control ilowv and subscqucnt output of thc crypto~raphic proccssing steps dcpend on thc v al~lcs of thc input par;mlctcrs and thc cont.nts of thc ('1 cn\ironmcIlt mcmory 1~6. The Cl- cnvironmcnt mcmory 1~6 consists of a sct of crvptog~rapllic variablcs, for e~ample l;eys, flags, counters, Cl- con~iguration information, etc., \vhich are collccti~ely storcd ~-ithin thc CF 30. Thc cr cnvironmcnt ~ariablcs in memory 1~6 are initiali~ed ~ia the interface ~1, that is by c.~ccution of ccrtain Cl~ microinstructions ~hich rcad input pararncters and load them into the CF cnvi-ronmcnt mcmory 1~6. ,~ltcrnately, initiali,~ation can be done ~ ia an optional physical interf~cc ~-hich permits ct~pto ~raphic vari;lbles to be loadcd directly into the CF en-ironment memory 1~6, for e~ mple ~ia an attachcd lic~- cntry device.

Description of the Bcsl \lode for C~lrr~-ing Out the In~ cntion 1 13 19-91-01 ?
207 .~329 Thc physical cmbodimcnt of the cryptographic facility sccure bound~ry I 1(). incorporates thc following physical sccurity fcaturcs. Thc physical embodimcnt rcsists probing by an insidcr adv ersary w ho has limited acccss to the cryptographic facility 30. Thc tcrm '1imitcd" is mcasurcd in minuIcs or houri as opposcd to days or ~veeks. 'I'he adversary is constrained to a probin~ attack at the customer's site usinV limited elec-tronic dc- iccs as opposed to a laboratory attack launched at a site undcr thc control ot' thc adt ersary using sophisticatcd elcctronic and mcch.mical equipment. Thc physical cmbodimcnt also dctccts aItcmpts at phys-ical probing or intruLlin~,, through the use of a ~aricty of clcctro-mcc}Ianical scnsing dcviccs. Also. the phys-ical embodiment of the crypto"raphic facility 30 provides for the zcroization of all internally itored secret crypto~raphic ~ariablcs. Such zcroi~ation is done automatically ~vhcnever an attcmptcd probing or intrusion has becn detcctcd. T}Ie physical cmbodimcnt also pro-idcs a m.anual facility for a zcroization of intcrnally storcd sccrct cryptograp}Iic variables. Ret'ercnce to the Abraham, ct al. patcnt apl?lication ci~ed abo-e, will .~ive an e:;ample of how such physical security features can be implementcd.
h.'ey Record Erlc~yption/Decryption: Fig IS is a block diagram illustration of cry p tograp}lic l'acilit! 30 incor-por;ltin~, thc l;cy rccord encrypt and key record dccrypt algorithms. CryptograplIic l'.Icilit! 31~ contains an instruction procesjor 1~2 consisting of a plurality of cryptouraphic instructions (not sho~n in ~ig. lS), a CF
cnvironmcnt mcmory 116 containing a mastcr key 15, and crypto~Traphic algoritlInls I 1~. Crypto~Tr;ap}Iic algoritlmIs 1~ cont;ains ~n asymmctric kcy crypto~raphic algolithm 10, an option.ll s! mmctric-l;cy cl~ptograp!Iic algolithm 11, an asymmctric-l;cy kcy gcncratiolI algoritlInn IS2, ;a l;cv rccord clIcr!pt al~orit!ITn 12, alId a kcy rccorLl decr5pt al~oritlIm 13. I~ey record cncrypt ;al,orithm 12 is a low-level t'unction us~LI by instruction proccssor 142 to encrypt a kcy record (PU key record or I'R key rccord~ and pro.luce an encrypteLI key authenticator record (KAR), which serves to authenticate the ke5 record ;md aijociateLI
contrc)l ~cctor to thc cryptographic facility 30. During kcy gcncration (via the Gl'l;l'R instmction), thc 1'1' and l'R key rccorLls produccLI by the asymmetric l;ey key gener;ltion ;LI~ orithm IS2 are encrypted anLI then storcd in kcy tol;cns constnuctcd by the instmction processor. Thcse key tokcns are retume(l as outputs at 51. 'l'he kcy rccord encrypt al;,olitlam 12 is invoked by the instruction processor 1~ at 1~ ai~ing ;1 I;CY
rccord and control vector. In response, key record encrypt algorithm 12 encrypts the l;ey reiord with m;lster key 15, or a v ariant key derived from master key IS, as e~plained below. Key record encrypt al~lorithm 12 also produces a key authcnticator record (KAR) from the key record or from thc control v cctor and key rccord, again as e.~Lplained below. The so-produced KAR is then encrypted ~vith master l;ev IS. or a v;arimt key dcrived from master key 15 (different from the variant l;ey used to encr pt the kcv record). as c~pl.aincd below. i\'ote that if the KAR was not encrypted, this mi~ht represent a security e:;posure, aj the control vector and key record for a public key and the KAR generation algorithm are all assumed to be public knowledge. This ~vould possibly allow substitution of a incorrect public key or incorrcct control ~ector for the correct values, for e~ample, in the cryptographic kcy data set. ~Vhile the KAR t'or a pri~ ate key m;l5 not need to be encrypted for security, in the preferred embodiment, it is encrypted to allow conjistent processing of the Kl'~R for both public and private keys. As an altemate embodiment, the ~ ~R t'or th. pri~ ate lic y could just be the output of a strong cr~ptographic one-way function, such as the ~,IDC-' I'unction de jclibed elsewhere. 'rhe encr~pted key record and encr~pted ~ R are returned at 16 to the injtmctioIl proce~sor 142. Key record decrypt algorithm 13 is a low-level funetion usecl by instruction procesior I 1' to cleer!~pt ;
key record (Pl~' key record or PR key reeord) and autheIlticate the l;ey reeord and associated colltrol ~ector to the crypto~-;lpllic facility 30 before permitting instmction processor 112 to proces~ or uj. th.' l~ey in thc decr~ptecl l~e- rccord. .~,lany of the cr~ptograp}lic instmctions e~ecutin~, in thc in:;tmction pl-oc;~or 1~' make u~e of cr~-pto~raphic keys stored in key tokens and supplied as inputs at ~1) to ~he in~tnl.tion pl-ocesior 1~2. nefore a };ey can be processed or used by the instmction proeessor 1~ it must he reco~.red. I~ulillg key reco~!ery, the encryptcd l'U and I'R key records cont.lule(l in the input lie~ toliens (;lt ~ ) .Ire decr~ ptccl and autheIltic.ltecl. 'rhe key record decr~pt al_orithm 13 is in~ol;ed at 17 by the injtmction processor 1~.
p;ls~ing a l;ey re-ord ancl control ~ector as inputs. In responsc, }~ey record clcer! pt al~c)rithm 13 decr! pts the cncrypt ke- rccorcl ~ ith master key 1~, or a ~ ariant key deri~ed from master liey 1~. as e~;plaillcd bclo~ .
~cy record dccl~-pt algorithm 13 also produces a l;ey authenticator record (Ki~R) from the reco\erecl liey rccord, or t'rom the control ~ector and reco-ered ~ey reeord, again as e~plained belo~. 'I'he lie\- record decrypt algorithm 13 then decrypts the encrypted ~,~R ,md compares the reco~ered ~alue of li.-~R and the oenerated or produced ~,~R for equality. If the t~o ~alues of K,~R are equal. the ~;.y record decr!pt algo-rithm 13 retums the reco~ered l;ey record and a retunn code (e.g., RC=0) indicatin_ that th- I;e! record haj been successt'ully authentieated ~ia the K.-~R. Other~ise, if the t~o ~alue of Ii;~R are unequal the }iey Dcscription of ~he Best \lode for C~rr~-in~ Out tht~ In~(ntion 1 13 1 9-91-01 ~
207~32~
rccord decrypt algorithm 13 rcturns only a rcturn codc (e.g., RC = I) indicating that thc kcy rccord has failcd to bc aLIthcnticated via the KAR.
Fig. 16 is block diagram illustration of a first embodiment of the key record encrypt algolithm 1'. The first cmbodimcnt of thc in-cntion covers the case ~vhere the cryptographic system implemcnts both a s--m-mctric key algorithm ;md an asymmctric key al~ortthm, and whcre the master key uscd to encrypt thc kc-records in thc key tokens storcd outsidc the cryptographic facility is a symmetric kcy K~l Rct'crring no~ to l ig. 16, the inputs (a) key record and (b) control vector are read at step SOO. Key record is the key record to bc cncryptcd and control vector is kcy-rclated data, or data related to thc kcy storcd in kcy rccord. Control v ector is the samc control vector storcd in thc key tokcn, as described in Fig. I l. At stcp 501, a hajll v aluc II.~SIII is calculatcd on the control vcctor using hash algorithm hal. I or e~ample, ~vllcll thc m.lstcr l;cy i a 12S-bit l)E~ m.lster key, 11.-~'.111 can be a 12S-bit .~IDC calculate(l ~ ith the ;\,IDC-2 al~,orithm of l~ . 5.
~t stcp 502, hash ~cctors 111 and 1-12 arc calculatcd from II~SIII. I'or e.~camplc, ~ hcn thc mastcr kcy is a 12S-bit DEA m;3stcr kcy and 111 and 112 are both 128-bit hash ~ectors, the proccd-lrc for calcul;ltillg III an~l 112 is as follo~-s. Thc 12S-bit hash vector 111 is ca1culatcd from l-IASIII as follows:
1. Sct bit 30 of 11~S111 equal to B'O'.
2. Sct bit 3S of 11.~111 cqual to B'l'.
3. Sct bits ~5..~6 of II.~SIII cqual to 13'10'.
. Set bit 62 of II.~SIII equal 13'0'.
5. 1 or cach byte in II~L~SIII (bits are numbcred bO through b7), set bit b7 so that bits bO throuvh b7 h;l-e an even number of one bits (i.e., to have even parity).
13its 30 ancl 3g are anti-variant bits ~vhose values are set so that the resulting hash vector 11 is gu;lr;mtcc~l to be ditfcrcnt from a variant value in which each bytc of thc ~ariant has the same bit pattcm. I~its Ij and -16 arc sct to B'10' to distinguish H 1 from a 6~-bit control vcctor (bits 15..~6 equal to B'OO'); nd a 12S-bit control ~ector (bits 45..~6 equal to B'OI'). In this case, B'10' indicates that 111 has bcen dcrivcd from a '10ng" control vector whose length exceeds 128 bits. Bit 62 indicates whether the control vcctor is associ;lted ~vith a key record (B'O') or a key authcnticator rccord (B'l'). The 12g-bit hash vector 112 is calcul;3tcd t'rom H I as follows:
1. Set 1-12 equal to Ell.
2. Set bit 62 of 112 equal to B'l'.
3. Invert bit 63 of 112 (i.e., the parity bit).
Basically, E12 ditfers from ~H l only in that 111 is associated with a key record (bit 62 equals B'O') alld 11 ' is associated with a key authenticator record (bit 62 equals B' I '). The parity bit is adjustcd to maillt;lin evcn parity. Otherwise, Hl and 112 are equal. ~t step 503, variant key K~,l+ 111 is formed as thc E:;clusive-OR
product of master key K.~I and hash vector El I . nd variant key K.\~l + f 12 is formed as the E.~;clu~-.ivc-O R
product of master key K.~,l and control vector ~12. In the event that the length of 1~.~1 di1't'crs from the length of Hl and E12, Hl and 1-12 can be E:l~clusive-ORcd with a portion of K:\~1 only. Those sl;illcd in the art ~vill recognize that a combining operation other than the E:~clusive-OR opcration can hc pcrfolmc(l instead of the E~clusivc-OR operation, ~vithout dcpartillD from thc spirit of thc int~cntion. ~'h.ll li~ a DE.~ master key of 128 bits, then the E.~cclusive-OR operation calculates the E~clusi-e-OR ;-roduct ot' 1~\ o 128-bit valucs, ~-hich is thc straightforward way in ~ hich this opcration ~ orks. ,~t stcp 50~. thc l;c~ rccor-l supplicd as input at 500 is cncr~pted ~vith variant l;ey K.~,l+ 111 to producc thc cncrypted kc) rccold v;ll~lc cK.\,I + 11 I(lic~ record). ~!~Dain, thosc skillcd in the art ~ill recognii~e that many dil'fcrcnt IllOdCS of cncr~ption can be uscd hcre, since the g,oal is to protect the sccrccy of the kcy record but not necess;-nl! to pursuc onc single stratcgy f'or providing an encryption capability. I~or c.Yample, if the variant key K~l + 111 is a 6~-bit DI~A key, thcn thc key record can bc encrypted using thc Cipher 1310ck Ch;lil~illg (CBC) mode of encryptioll. If thc ~ariant l;ey K~l + 111 is a 12S-bit DE~ I;c-, then kcy reeord ean be encrypted Usillg a ~ariation on the C13C mode of encryption. In that case, l~ey reeord is first encr~pted ~vith CBC mode U~ill"
the Iettmost 6~ bits of 1~.~1 + 111, thc result is ne.Yt decrypted ~ith CBC modc using the ri_htmost 6~-bits of ~1 + 111, and ftnally that result is cncryptcd ~ith CBC modc usin~ the Ieftmost 6~-bits of ~.~1 + ~ n initialization ~eetor (IV) of ~cro is useJ throughout the eneryption and dceryption operations. In eaeh e;lSC.
in-erse decryption operations are employed in the }~ey reeord decrypt algorithm, discussed belo~. Thoje killed in the art ~ill reco~r~ize that encryption methods other than those illustrated herc e;m bc ujed ~ithout l)escription of the Best .\lode for C~rr~inv Out ~he In~en~ion 16 13 r9-91 -015 2~i329 dcparting from the spirit of the invcntion. At step 505 a hash ~alue 1-IAS112 is calculatcd on l;cy rccord using h;lsh ~Igorithrn ha2. Ilash algorithm ha2 may be different from hash al-/orithrn hal or it ma! be the same. l~or c~ample hash alDorithm ha2 may be the .~IDC-2 algorithm of Fig. 5 and I l;~SI I a 1 7S-kit .~IDC value. The ..alue II.~S112 is for practical purposes defmed to be the key authenticator rccord (~;~R).
Ilowevcr the Kt~R may contain additional data besides l-IAS112. t~t step 506 KAR is cncryrtcd \ith ~ari;mt key K~l + ~12 to produce the encrypted Kt~R ~alue eK.~I + 1-12(KAR). Again those sl;illc-l in thc art ~ill rccogni~e that many diffcrent modes of encryption can be used here since the goal is to protcct thc inte ~rity of the K-~R by making it infeasible for an adversary to substitute ;m alternate value ol' ~ ~R ot' his or hcr choosing. silIce an adversary has no ability to e:cercise the encryption function using 1;:~1 + 11 . it is not possible to substitute an cncrypted KAR value that ~ ill authenticate an cncr;ptcd kcy rccord. c:;ccF.t ~ !
mcre ch~Ice. ~or e~cample if the variant key K:\l + ~12 is a 6~-bit DEA ~;ey then K.-~R can b: cllcrypte-i usinD the Cipher l310ck ChaininD (CBC) mode of encryption. If the variant key K.~l + 112 is a 1 S-l?it 1~
licy then Kt~R can be cncryptcd using a variation OII the CBC modc of encryption as dcscril cd above t'or thc cncryption of the kcy rccord. In each case in~erse dccryption operations are employcd in the l; y rccord decrypt algolithm liscusscd below. Those skilled in the art will recognize that encryption mcthods othcr th.m those illustrated here can be used ~vithout departinD from the spirit of the invention. t~t step 07. the calculated valucs (a) eK~I+ I-ll(key record) and (b) eK.\I+ 112(KAR) are returned as outputs.
Fig. 17 is block diagram illustration of a first embodiment of the key record decrypt al_olithlll 13. I'hc f;rst embodiment ofthe in-ention covers the case ~here the cryptographic system implements ~oth a s!m-metric key algorithm and an asymmctric key Llgorithm and ~ here the master l~ey used to cncrypt the };c--records in the key tokens stored outside the cryptographic facility is a symmetric key K ~1 l'he key rccor l encrypt algorithm 12 of Fig. 16 and the key record decrvpt algorithm 13 of Fig. 17 are in~crse ahTolithllIs i.e. key records encrypted ~ith key record encrypt algorithm 12 of Fig. 16 are decrypted ~ ith l;ey record dccrypt algorithm 13 of Fig. 17. Ret'erring now to Fig. 17 the inputs (a) control vector (b) c~l+ Ill(~i !
record) and (c) cK.~I + 1l 7(Kf~R) are read at step 510. Control vector is ~ey-rclatcd data or dat;l rcl;ltcd to the key stored in key rccord. Control vcctor is the same control vector stored in the l;cy tokcn ;IS ~Icscribc l in Fig. 11. eK.~l+Hl(k:ey record) and eKi~l+112(KAR) are values produced by the ~ey recorl ellcr!pt algorithm 12 of Fig. 16. ~t step 511 a hash value II.~SI-II is calculated on the control vcctor Usill hash algorithm hal using the same method as described in step 501 of Fig. 16. At step 512 hash ~cctors 111 an H are calcul;lted from HASIIl using the s~me method as describcd in stcp 502 of ~ig. 16. ~t stcp 1~.
variant ke~ s K~I + 111 and K.\ I + i 12 are calculated from master key ~ f and hash vectors 111 ;md 11~ Usi the same method as desclibed in step 503 of FiCr. 16. At step 514 thc cncr~pted key rccor3 c~l+ III(kc record) supplied as input at 510 is decryptcd ~vith variant key K.~ l + H I to produce the clc.lr valuc ot' 1; !-record The method of decryption at step 514 of Fig 17 is just the inverse operation of encr!ptio;l ;It st p 5W of l~ig 16. ~t step 515 a hash ~alue IIASH2 is calcul;3ted on key record usin- htsh al~orithm ha~.
Step 515 of Fig. 17 is the same as step 505 of l~iCr. 16. ~t step ?16 the encryptcd K~R e~l + 11~ R) supplied as input at 510 is decrypted ~ith variant key ~\I + H2 to producc thc clear value of ~ R. l'h method of decryption at step 516 of }~ig. 17 is just the inverse operation of encryption tt stcp ~n6 ot' Fi!. 16.
At step 517 the generated K ~R is compared for equality ~-ith the decrypted ~ ~R. If e~Iual then a return codc is sct equal to success . If unequal then a return code is set equal to ~failurc and kc! rccord is sct cqual to null (i.e. the rccovercd key record is erased). .-~t step 518. the valucs of (a) rctum co lc alI~ I;.y rccord arc returlIcd IS outputs. If the kcy rccord authenticatcs properly it is returnerl as all outE ut at st p 51~.. Other - ise a null ~alue is rcturned. Those skilled in the art ~ ill reco_ni~.c th tt there ale oth r a\~s in hich thc output ~alucs can be returned or not returned. Thc intcnt hcrc i . for kc~ rccord ~Iccl~-rt al ;olithm 13 to rcturn thc reco-crcd kcy rccord ~~hen it authenticatcs propcrly and to not rcturn it ~hcn it do s not authcntic;ltc propcrly. I hc rcturn code could be omittcd from the dcsign if desircd pro idcd th;lt a protocol i5 adoptcd hercin thc kcy record has a special reser-ed ~alue say ~cro to in-3icate a t'ail-lrc conuiti(!n (a non~cro v aluc indicatcs succcss).
I ig. IS is block di:l-vr;lm illustration of a second cmbodimcnt of thc kcy rccor l cncr~pt al ~olithm I
I'hc second embodimcnt of the invention co-ers the case ~ here the cryptographic system implem nts an comMut tti~ c asymmctric key algorithm and ~ here thc master key is an asymrnetric lie~ pair (P~ O.PRO).
~laster public key 1 1_ 0 is used to encrypt l;e~ records and to ~ erif~- di it ll sivnatures. !rl~tsler E ri~ ;Ite ~; y 1 RO is usccl to decrypt l;ey rccorLls and to gcnerate digital si_n~tures. Ret'crring no~ to Fi_. I g thc inputs l)cscription of the Bcst .\ lodc for CL?rr~ in~r Out th e I n ~-e n tion 1 7 13~r9-91-O1S 207~329 (a) key rccord and (b) control vcctor are rcad at stcp 520. Key record is the kcy rccord to bc cncryptcd and control ~ector is key-rclatcd ~lata, or data rclated to the key storcd in kcy recorcl. Control vector is the same control ~cctor storcd in the kev token, as dcscribcd in l ig. I l. At stcp 521, thc kcy rccord supplied as input at 520 is encrypted w,ith public master key 1'1,0 to produce the encrypted key record ~alue el'~;0(key record). Sincc the length of key rccord may be grcater than the block size (or modulus size) of the asym-metric key algorithm, an encryption mc;3ns must be employcd to handle Yong" kcy rccords. Onc approach is to usc a means similar to Ciphcr Block Chaining (CBC) mode, as dcfined for thc DEA. In this case, key recorcl is di-ided into blocks whose length is such that each block can be encrypted with the asymmetric key algorithm. r~ftcr each step of cncryption, the so-produced cipherteYt block is EYclusive-ORed with the neYt block of input plainte~t in key record. Thosc skilled in the art will apprcciate that therc arc many ways in which thc cncryption with 1'1,0 can bc performcd and that these various altcrnate mcans do not dcpart from the spirit of the in-ention. LL~t step 522 control vector and key record are conc;3tenated to form an interme-diatc ~alue callcd 11A-I~'. r~t step 523, a hash ~alue 11AS112 is calculatcd on 11~ using hash algorithm ha2. For c.Yamplc, hash algorithrn ha2 may be the .~IDC-2 algorithm of Fig. S and HASrl~ a 128-bit .\,IDC
value. TllC valuc II.~S112 is for practical purposcs defincd to be the key authcnticator rccord (KAR).
Ilowever, the ~ R may contain additional data besides Ik~S1-12. L~t step 524, KAR is decrypted with private master key PR0 to produce dPR0(KAR). In public key cryptography, the ciphcrte.Yt dPR0(KL~R) is callccl a digital signaturc. In this case, dl'R0(KAR) is a cdigital signature on HA-I~' (the concatenation of control vcctor and key rccord). At stcp 525, thc calculated values (a) cl'U0(kcy rccord) and (b) dl'R0(K,~R) are rcturned as outputs.
l-'ig. 19 is block di.laram illustration of a second embodiment of the key record decr5pt algorithm 13.
'I hc second cmbodiment of thc invcntion covers the case whcre the cryptographic system implements a commut.ltive asymmctric !icy alaorithm, and where the master key is an asymmetric key p;lir (I'1,'0,1'R()).
:\lastcr public l;cy r~o is uscd to cncrypt key rccords and to verify digital siDJnaturcs. ~\,lastcr privatc l;ey l'R0 is uscd to decrypt key rccords and to generate diDital siD~natures. The kcy record encrypt algolithrn 12 of I ig. 18 and the };ey record decrypt algorithm 13 of Fig. 19 are inverse algorithms, i.e., key records encrypted with key record encrypt alDorithrn 12 of Fig. 18 are decrypted with key record decrypt algorithm 13 of E~ig. 19. Rcfcrring now to Fig. 19, the inputs (a) control vector, (b) ePI,'0(key record), and (c) dl'R0(KAR) are read at step 530. Control vector is key-related data, or data related to the key stored in key rccord. Control vector is the same control vector stored in the key token, as dcscribcd in Fig. 11. ePI,'0(key record) and dPR0(KAR) are values produced by the key record encrypt algorithm 12 of r-ig. 18. At step 531, the encr!,ptcd key record, eP~0(key record), supplied as input at 530 is dccryptcd with private master key l'R0 to produce a clear key record. The step of decryption is just the inverse operation of encryptioll perforrned at step 521 of Fig. 18. At step 532, control vector supplied as input at 530 and kcy rccord recov-ered at 531 are conc~tenated to forrn an intermediate value callcd IIA-I~. Step 532 is just the same ;3s stcp 522 in ~ig. 18. At step 533, a hash ~alue HAS112 is calculated on IIA-I~i using hash algorithm ha2. Thc value HASH2 is for practical purposes defined to be the key authenticator record (KAR). I-lowevcr, the KAR may contain additional data besides l~ S112. Step 533 is just the same as stcp 523 in l~ig. 18. At stcp 534, the decrypted KAR, dl'R0(KAR), is encrypted with public master key 1'~'0 to produce a clear value of K~R (callcd the reco-ered KAR). ~ote that this is the stcp that requires thc asymmetrie key algorithm bc comLnutative. At step 535, the gencrated KAR is comparcd for equality with the reeovered ~AR. If equ;ll, then a rctum eode is set equal to "succcss". If unequal, then a rcturn code is sct equ;ll to "f;lilurc" al-d kcy record is set equal to null (i.e., the reco-ered key record is crased). ~t stcp 536, the ~.llues of (a) return cocle ~md (b) key record are rcturned as outputs. If thc l;cy rccord authcnticates properly, it is retunncd as an output at step 536. Othcr-vise a null valuc is rctumcd. Those skillcd in thc art ~-ill recognizc that thcrc arc other ~vays in ~hieh the output values can be returned or not retunned. 'I'he intcnt here is t'or kcy rccord clecrypt alaorithm 13 to return the recoverecl kcy record ~vhen it authenticates properly and to not return it ~vllen it docs not authentieate propcrly. The rcturn eodc could bc omitted from the desi~n, it' desired, pro-vicled that a protocol is aclopted ~vhercin the key record has a special rcser~ed ~al~lc, say zero, to indic;lte a failure col~dition (a non~ero value indicatina success).
'I'hosc sl~illed in the art ~-ill reco~Tnize that step 5~1 in Fig. 1~ could make use of a decr~ption opera-tion using the public master key 1'1~0 and step 531 of Fia. 19 could like~vise make use of an encr.\-ption operation usina thc pri--~tc rnaster ~ey l'R0. In li~e manner, step 52~ in }~ig. 1~ could make use of an Description of ~he 13est .\lode for Carr~ing Out the Invcntion 18 131'9-9 1 -0 1 5 207;~329 encrypt operation using pri~atc rnastcr key PR0 and step 534 of l~ig. 19 could ma};c usc ot' ;I decrypt opcra-tion using public mastcr key I'l~0, as long as both the public kc~ 0 alld pri-atc ke\ I'R0 rcmain sccrct.
ln fact, the choice of cncrypt or decrypt at step 521 of Fig. 18 is indepcndeIlt of the choice of encr~-pt or decrypt at step ~21 of ~ig. 18, so that altennate embodimcnts of the in~ention can maXe use of these alter-nate schcmcs of cncryption vcrsus decryption or dccryption ~crsus cncryption. ~nd tho~e j~illcd in the art ill rcco~c that thcse altcrnate cmbodimcnts do not dcpart trom thc spirit of the in~ crltion.
Thosc skilled in the art ~ iLI also rccog~ni,~e that the key record encrypt algtorithm 17 ot' Fi_. I~ and the keyrecorddccryptalgorithm 13of~ig. 19couldmakcuseofasymmctricmastcrl;cy ~ 1 ins~eadofa public ~mcl privatc master key (Pl,rO,l'RO). In that casc, all opcrations pcrfomleLi ~ith 1'~0 and l'R0 are instcad pcrforrncd ~~ith K.\/l. In an altcrnate approach, ~ariant kcys K.~ll and E;.~l' (not cqu31 to K~
c~m be used as the master key. In this case, K.~,II is used in place of 1'~;0 and K.~ used in place of l'R0.
This pro~idcs a folm of crypto~raphic scparation bct~vccn thc cncryption and autllcIltic~tion componcnts of the dcsi,,n. -I'h-ls, cncryption of the key record is pcrformed ~\ ith li~I 1 ;und cncryption ot' the K.~R is per-fommcd ~vith K.~17. Those skilled in thc art ~ill apprcciate that these altcmate cmbodimenti do not depart from the spirit of the invention.
Fi~t. 20 shows a functional block ciiag,ram of the crypto~,raphic facility 30, for rcco~ ering a plur;llity of public and/or pri~ atc l;cys from a kcy tokcn for use in a plumlity of public kcy algolitllIlls. in respoIlsc to a plurality of di~erse crypto ,raphic servicc rcquests. In particular, I-i~t. '0 depicts ho\~ t~o pri~:lte keys, 1'1~1 and PR2 can bc recovcred from a key token accessed from the cryptoor~phic key data set CKDS 3 for use in t~vo different pubLic key al ,orithms, to fuLfill t~vo diffcrent crypto ~raphic ser~ ice requests. The first rcquest Rl is to import thc cncryptcd DE.~ kcy cl'Ul(keyl), which ~vas cncryptcd undcr ;3 tirst publi. kc! I'l l, .md dccrypt the key undcr the correspondinD pri-ate key I'RI to obtain keyl, using a tirst public ke\ aloorithm ~1. Thc sccond requcst R2 is to gcncrate a digital signature from Data2 undcr a secon-l pri~ate l;ey I'R2, using a second pubLic key algorithm ~2.
The key token is input from the CKDS on line 50 to the L;ey token re_ister 700, ~ ith the header portion in the component register 704 and the concatenated control ~ector CV, encr!-pted l;e~- record eK~I+ Hl(parse,Ctl,l'Rl,PR2) and encrypted key authentication record eK.~,I+ H'(K-~R) in the compo-ncnt rc_ister 702. The header in register 704 defines the beginr~ing and enLiin~ of thc control ~ ector thc encrypted key record and the encrypted key authentication record in reoistér /0~. Tlle header re~ister 70~
output is colmected to a control input of the multiple.~or 706, ~ hich separates thc control ~ ~ctor for output over line 17 to the control vector reg~ister 70S, ~hich separates the encrypted key record for output to the encrypted key record register 710 and which separates the encr~pted key autheIltic;ltioll reconi l'or output to the encrypted key authentication register 712.
The control vector checker 714 recei~es the control ~-ector CV from the rc<~ister OS. Ii' thc Import DEA ~ey request Rl is the cry-ptographic scrvice request ~hich has bccn madc. thcl1 tllc conlrol \cctor checker receives R 1 and performs the checking operations on CV to ensure that the l;c~ recc)rd cont;lins a key which is permitted to be applied to this use. If CV satisfies the controi v ector chccl;cr ~ I 1. thcll aIl enabLing signal 'ok" is sent to the ~ate 716, ~vhose data input is connectcd to thc outF)~It ot'lhe coIltrol ~cctor rcgister 708, p~ssing CV to the control ~cctor islput of the kev record decr~-pt al~onthl1l 71S alld 7'l). If CV
fails to pass the checks by the control ~ector chec~;er 71~, then the proccss is aborte(l.
.-~lternately, if the Generate Digital Si_nature request R2 is the cr~pto~,r;lphic ser~ ice re~luest ~ hich has bccn made, thcn the control ~ector checker recei-es R2 and perforrns the chec};in~ opcratiol1s on CV to ensure that the kcy record contains a key ~hich is perrnitted to be applicd to this use. If C~ s;ltist;es the control vector checker 71~, then an enabling signal "ok" is seIlt to the g~te 716. ~-hose dala input is COII-necte~l to the output of the control vector register 70S, passin~, CV to the control ~cctor input of the l;e~
rccord decrypt algorithm 71S and 720. If CV fails to pass these checlis by the control ~ector chcckcr 71~, then the process is aborted.
lhe l;ey record decrypt al~orithrn 13 in the flo-~ diagram of ~ig. 17 i~ e.~ecuted b! the l'unclional blocl;s 71S, 720, 7~7. 72~, and 726 of Fig. 20. ~r--O functional blocks, 71S an~l 720, ~re arr3l1g~ed in parallel Description ofthe Best \lode for C~rr~in~ Out the In~erltion 19 13-r9-9l-ol~ 2 0 7 j 3 2 9 and are labclcd ~Kcy Record Dccrypt ~lgorithm", in l~ig. 20, to provide a clcar dcscription of the dccryption operations on the encryptcd kcy rccord and on thc cncrypted kcy authcntication rccord. I lo~vcver, in the prcfcrrcd embodimcnt of thc invcntion, thc t-~o functional blocks 71S and 72() ~-oukl bc combincd into a single Key Record Decrypt .~lgorithm ~vhich would operate sequentially on the cncr!l tcd l;cy record ;lnd thc cncrypted l~cy authcntication rccord. Doing so cnablcs sccond hash vcctor 112 to bc produccd trom tirst hash vector 1-11 by challging only a singlc bi~ in ~11. The key rccord dccrypt ~IlDoritlllll 71S rcccivcs CV alld performs thc hashinv opcration dcscribcd in stcps ~11 and 512 of l':i~. 17, producinD thc h;lsll vcctor 111.
The master key K.~l is input from re,ister 15 and the e.Yclusive OR product ~vi~h 111 is tormcd, ~-icl~lin~ the ~ari;mt key K.~l+ 111, as dcscribcd in stcp 513 ot' I:ig. 17. Thc second l;cy rccord dccrypt algol-itllm 72(~
receives CV ;lnd pcrforms the hashing opcration dcscribc(l in stcps 511 and 512 of l~ig. 17, producin, thc sccon(l hash vcctor 112. 'I'hc mastcr };cy 1~1 is input from rcgistcr 15 and tllc CYClUsivc OR yroduct ~ith 112 is t'ormed, yicl(ling the second vari;mt key li.\,l+ 112, as described in stcp 513 of l ig. 17. 'I'hc tirst l;e rccord dccrypt alDorithm 7 IS thcn uscs thc variant kcy K.~,l + 111 to dccrypt thc cncryptcd l;cy rcconl, as ~ dcscribcd in stcp 51~ of l ig. 17, yicldinD the };cy rccord (parsc,Ctl,l'Rl,l'R2). 'I'llc kcy rccord t'rom kc rccord dccrypt algolithm 71S is input to the h~sh algorithm 724, to produce thc computcd ~cy authentication record (K~R), as described in step 515 of 1~ jD 17. 'I'hen the computed key a~lthentic;ltion record (K.~R) is input to a f;rst sidc of the comparator 726. The second l;cy rccord dccrypt al~ orithlll 7'0 uscs the vari;mt kcy K.~,l+ 1-12 to dccrypt the cncryptcd key autllcntication rccord, as dCsClibCd ill stcp 516 of l i~g. 17, yickling thc kcv autllcntication rccord k~.~R. 'I'hcn thc kcy authcllticatioll rccord li~ is iny-lt to a second side of the compar;ltor 726. If the comparator 726 determines that the computed (K.~R) is e(lu;ll to the decryptcd K~R, then an enabling signal "yes" is output to a control input of the gate 722, to pass thc key record (parse,Ctl,l'Rl,l'R2) from the first L;ey record decrypt algorithrn 71S to the l;ey record register 7~g.
Tlle kcy rccord is input to thc }~ey record rcgister 72S over line IS, ~vith the parsc dat;l in a tirst COlllpO-nent rcgistcr 730 and the concatcnated control inforrnation Ctl, first pri-ate kcy l'RI alld sccond pliV;ltC kc!
I'R in a SCCOIld component rcgister 732. The parse data in registcr 730 dcf;ncs thc bcginnill~, and cnd " ot' the control inforrnation Ctl, the first private key l'Rl and the second private L;ey 1'1~2 in re~istcr 73'. 'I'he parse data rcgistcr 730 output is connected to a control input of the multiplexor 73~, ~vhich scparatci thc control inforrnation Ctl for output thro~l2~t register 736 to the public key algorithrns 10 ;md 10', ~vllicll SCp;l-ratcs thc first private key l'RI for output through recrister 73S to thc Date 712 ;md ~hich scp;ll;ltcs thc scc~
private key l'R2 for output through re2ister 7~0 to the gate 7~Til.
Gate 7~2 has a control irlput conncctcd to receive the Import DEA Key requcst signal 1~ hich enables the passing of the first private key PRI to the first public key calgoritllm r~l at 10. 'I'hc cncryptcd DEA key el'~, l(keyl) which was encrypted under a first public key l~jl, is input to the opcr;lnd input ot' the first public kcy algorithrn Al. The control inforrnation Ctl input to thc tirst public kcy al=,olitllm ~1 describcs thc kcy type for the first private key l'R I (i.e., spccifies PR I is a dccryption kcy). I 'sin2 thc tirst private key l'RI, the public key algorithm t~l at 10 decrypts the cncryptcd DE~ kcy cl'l;l(licyl), \\hich \VaS
encrypted under a first public key P~,'l, to obtain the clear text kcyl.
Gatc 7~ has a control input connected to recci~c the Gcncratc Digital Si~latulc n:~lucst sign;ll 1~ '.
~hich cnablcs thc passin2 of the sccond private }~ey 1'R2 to the sccond public kcy al~olitlllll .\~ at 1()'. 'I'h;
clear tcxt Dat;l~ e.~pression is input to the operand input of the second public key algoritlllll .\'. 'I'hc control intormation Ctl input to the sccond public kcy algorithm ~\2 dcscribcs thc l;cy typc t'or thc SCCOlld pri-ate kcy 1'1~2 (i.e., spccifics l'R~ is a dccryption kcy). I'sin2 the sccond privatc l;cy l'R', thc pllblic lic al_orithm .\~ at 1()' ~Jccr~pts" the clear te~t Data2 exprcssion to obtain thc r-qucstcd di~ait;ll si rn.lturc.
.~ltcnnatc cmbodimcnts ot' the functional blocli diagram of l~ig. '0 c.~n includc provi-ling a singlc lic rccord dccrypt algorithm \~hich scquentially pcrforms thc functions of algorithms 71~ alld 7'0. ~notllcr altcm,ttc cmbodimcllt can include providing a sinc~le public key algorithm ~-hich scquclltiall~ pcl1'0nlls the funcîions of algorithms 10 and 10'. .-~nother altennate embodiment can inclu(le storing ~cyl in a }iey blo-l;
an(l rccci-ing and proccssing the l;cy in the cncryptcd form cP~;l(kcy block). In th;tt casc, the output trom public };c! ;31_orithm ~1 is a key block cont tinin~, Ke~-l. Another ~ltern~te embodilllent elilllin.lt~T thc conlrol inl'onm;ltion in thc key record specifyin_ that the l~ey is a private key or a public kcy. Instea~l~ the Dcscription of Illc ~3cst ~lodc for Grr!in~ Out ~hc in~-clltion ~0 207532~
public key algc)ritllms Al and A2 include a control line indicating encryl-tion or decryption, wlIicll is set by cryptographic facility 30 on the basis of the type of cryptographic operation rectuested. For exanIple, for requests R1 and R2, cryptographic facility 30 will know that the key record contairls a private key and that decryption with the private key is required. T}lus, a (le(ryption signal can be scnt on the control line to the public key algorithms, Al and A2.
I<ey Toke~ls a7ld ICey U77its: Thus far the described inventioll has taugllt that a key token is produce(l within the cryptographic facility (Cl ) 30 from a ~ontrol vector and a key recc)rd, as Sh0WIl ill Fig 21, arlcl the soproduce(l key tokells are stored outside CF 30 in a cryptc)grapllic key data set 32. Rcferring to Fig. 21, a key record 401 and associated control vector 400 are stored either in an interlIal key token 403 or an external key token 404. Tllat is, a key token is either an interllal kcy token (also referred to as a key token, i.e., wilhollt t:he modifier 'internal') or an extcrnal key token. I~n Interllal I<ey Tokcn 403 consists of a header 4(:)5, a cc)lItrol vector 406, and encrypted key record 407, and an encrypted autlIellticator 408. The encryf)tecl key record 4()7 and encrypted autl-lenticator record 408 are prodllced via key record encrypt algorithm 4()2, USillg as inputs control vector 400 and key record 4()1. Control vector 406 in intemal key tc~kcll 4()3 is jtlSt a copy of control vector 400, which is the control vector associated with key recorcl 401.
ICey record encrypt algorithm 402 is the same key record encrypt algorithm 12 of Fig. 15. An External ICey Token 4()4 consists of a header 409, a control vector 410, and a key rccord 411 (i.e., a clear key record).
G:)lItrc)l vector 410 in external key token 404 is just a copy of control vector 400, which is the control vec~or asso( iated witlI key record 401. A key record is either a public key record (i.e., PU key record) or a private key record (i.e., PR key record). Likewise, an internal key tc)kelI is either a internal PU key token or a interlIal PR key tokell, depelIding on whetlIer the key token contains a PU key record or a PR key record, respectively, and an external key token is either an extemal PU key tc)kelI or an external PR key token, clepelldillg On wrlletller the key tokclI contailIs a PU key record or a I'R key record, respectively.
I lowever, it may be advantagcous to penlIit thc cryptc~grapllic facility access program (Cl AP) 34 to store keyrelated informati(:)n in the kcy token, not directly availablc to the CF 30 and therefore not convenient or possible for the Cl' 3() to store in the Icey token. Thus, it may be more practical for the CFAP 34 to add certain infc)rlllatioll fields to the key token once the key token is retllrned to the CFAP 34 as an instmctic)n output. In SIIC]I situatic)ns where the CFAP is permitted to add information to the key token, a new set of tcrminology is introdllccd, as illustrated in Fig. 22. Thus, the internal key token 403 in Fig. 21 beconles intemal key urlit 423 in Fig. 22, and external key token 404 in Fig. 21 becomes extemal key Ullit 424 in Fig. 22. Likevvise, control vector 400, key record 401, and key record encrypt algorithm of Fig. 21 are just control vector 420, key record 421, and key record encrypt algorithnl 422 of Fig. 22. L,ikewise, header 405, control 406, en~rypted key record 407 and encryptcd authenticator record 408 of Fig. 21 are just htader 425, control vector 426, encrypted key record 427, and encrypted autlIenticator record 428 of Fig. 22.
Likewise header 409, control vector 410 and key record 411 of Fig. 21 are just hea(1er 429, cc)ntrol vector 430 and key rccc)rd 431 of Fig. 22. Referring again to Fig. 22, internal key token 434 contailIs IICU 423 as well as other data 432 supplied by Cl-AP 34. Likewise, extemal key token 435 colltaills EICU 424 as well as other data 433 supplied by CFAP 34. Where conveniellt, the termillology IICU (i.e., internal key unit) and EICU (i.e., extenlal key unit) will be used ill lieu of il-terllal key t-)ken al-ld exterMal key token when it is ecessary to refer to qllalItities produced by CF 30.
171ic l~ey C'ryptllgrap1lic Desig1l: Full features and apparatus of the inventiorl, which is referred to herein as the Pllblic ICcy Cryl)tographic Design (PICCD), are now describcd. The reader will appreciate that the metlIc)(ls used for key record elIcryption alId decryptiolI described earlier are essential for coupling the usage colltrol to a key in a public key cryptosysteMI. Tlle reader will also notice that alt}-oug}I alternate e nIl)o(lilllell~ s have been discussed earlier for key record encryption and decryption, only the first embo(lilIlellt of Fig. 16 and Fig. 17 is incorporated in the Pl<CI).

13'1 9-9 1 -0 1 ~

Components of the Cr~ r)to~rraPhie FaeilitY 2 0 7 a 3 Z 9 'I'lle Cryptographie Faeility eontains three major eomponents ~ Instruction l'roeessor ~ Cr~!ptographic ,Ugorithms ~ Cl~ l~nvironmcnt Instrllction Processor ri~. ~3 is a bloek di;l~,rram illustration of the components of the Instruction l'rocessor 'I'hey ~re ~ Instrlleri(~n~: 'I'lle (~1- instructions are invoked at the Cl~ To-CI~ intelt;ace 'rhe~ pro~ ide the t'ol-lo-ving cr~ ptographie services to the CFAP
System Digital Signatures Application Digital Signatures Key ~!anagement CKDS Update Cf Backup CF Audi t CF Initialization C F Con f i gu ra t i on CF Control Utility ~ Internal Ro~tines: The internal routines are in~oked only from ~~ithin the CF Collecti~ely the! repre-sent a set of algorithms and processing functions that are common to many CF instructiorls 'I'he internal routines have been specified to simplify the arehiteetural deseription and del'initioll, and to m;3~e each instruction's functional speeifieation preeise and less apt to eontain errors and ambi~7uities Althou~,h the internal routines are .~n integrral part of the instruetion functional speeifications, all imple-menter may eleet to implement the instructions and internal routines in a ~-ay th;lt best S-lits or opti-mi~c-s the partieular implementation ~ Confilrlllntion T~ble: The Configuration Table is a colleetion of eonstants that may var~ in ~al~le from one implementation to another The Configuration l'able permits the Instruetiolls and Internal Rou-tines to be defined in a more general and open-ended ~vay t,'nlike the cr Bn~ironment, the Confgur;l-tion Table is an integrral part of the CF (e g, hardware or ROS mieroeode) Fig 24 is a bloek diagram iLlustration of the elements in the Conti"ur:ltioll 'I ablc.

Cr~ptogr~phic Algorithms ~, 25 is a block dia,ram illustr.ltion of the main components of (~r!ptogr;lpllic ~ oritllms of th.' ~'1 ~I'he Cryptographic ~Igorithms eomponents are these t(~ Ener~ption ~ o~ithm !DE~): 'I'he L)E4-~ is clescribed in the .-~melican \'ation;ll ~tandar~ls Insti-tute (~ SI) I)ata l ncr~ption ~lgorithm (I)E~ 3 9~ I'he 1~ is a sy~ ctric algolitllln ~hi~l encrypts or (le( rypts a 6~ bit input ~vith a 6~ bit l;ey to procluce a 6 I bit output 'I'he 6~ bit kcy Sl?eCi-t;ed to the algorithm eonsists of 56 key bits used by the algorithm and 8 non-key bits, ~ hieh optionally may be used for error deteetion ~eeording to A\'SI ~3 92-19~1, the ~ non-key kits m:l! be use(l t'or error (Ieteetion On the other h~nd, aecording to l'IYS Pl,'B ~6, the 8 non-};ey bits sh;lll be used for error deteetion and more speeifieally the error deteetion is based on b~le-by-b!le odd parity ~Ithough the Symmetrie liey Cr! ptographie r~luorithm ean be an optional eomponent of the Cryptographie ~l!o-Components orthe G!-ptoYr(lpllic I Icili~! _2 ~ , 13'1'9-91-015 207;~329 rithms 11~ sho~vn in Fig. 15, the DEA is a rcquired component in the PKCD, as it is needed for kcy rccord cncryption and dccryption.
~ P~hlic Key ,~I~~o~ithm (PAA): PKA is a generic terrn ret'erring to one of se-er31 possible public l~ey algorithms. The PKCD does not specify the use of a particular PKA. Ilo~-e-er, the PKA must pcrmit key distribution to bc based on a key ser~er concept wherein a DE~ key, randomly generated and encryptcd with a public key of a rccei~ ing device, is ser cd to a recei--ing dc- ice ~ hcre it is dccr~-ptcd with the private key of the receiving device and reencrypted under the master l~ey. 'I'he l'K.l~ must also permit gcncration and verification of digital si~,natures. A digital si~naturc is produced by decr~v-pting a signature record, containing a hash value, ~vith a pri~ate ~;ey. ~ digital signature is ~crified by encrypting thc sicnature with a public key and compaling hash ~alues. Thc l'KCI) also pcrrnits kcy distribution with a first l'KA and di~,ital signatures to be implemented ~~ith a second l'K.~.
~ Pllhlic KcV ~t[f o~ithrtl Ke~ Generato~ (P~.~AG): I'~,~KG is a scp~ratc al~olithm for thc gcneration of keys used by thc l'K~.
Besides the main components, there are lo~ver level ak~orithms, such as ~cy Record Encryption and Key Record Decryplion algorithms ncedcd for frequent encr) ption ;md decr~ption of public and pri-atc kcys, as discujsed earlicr.

CF Environment Fig. 26 is a block diagram illustration of the componcnts ol' the CF En-ironmcnt.
The Cl~ En-ironment components are Ihese:
~ Confi~~~u~ntion Vector: Thc confi~uration ~ector is a collection of encoded fields that Lunit or rcstrict the operation of the cr~ptographic facility. The configuration vector is set to a dcfault ~aluc ~ia e~ecution of the Enter Initialization State (EIS) instruction, or it may be set to an installation-specit;ed ~alue ~ia e~;e-cution of the Load Configuration Vector (I_CV) instruction.
~ State Vector: The state vector is a collection of Qags and state ~ ariablcs that det;ne thc current st;ltc of the cryptographic facility. The state ~ector is used by the instruction processor to control the orJcr in which PKCD instructions are e,Yecuted.
~ Re~,riste~s: The rcgisters contain space for the storage l'KCD crypto~ari:lblcs. inclu(ling l~eys, .~11)(~
values, internal counters, identifiers, ancl control ~ectors.
~ .lll)C 7~1hle: The MDC table contains space for the storage of :\Iodification Detection Codcs (.~IDCs) uscd by the Import Public Key (IPUK) instruction to import E~ternal Key Units. Each table Clltl~ is an ~IDC calculated on an External Key Unit using a hash al~ orithrn.
~ Colmter Tnble: The Countcr table contains space for thc storage of counters, \~ herc cach countcr is associatcd ~vith a particular PKCD instruction. Countcr(i) contains a ~-alue "n" froln I to 255, sct by thc S~I instruction, ~hich represents the number of tirnes instruction "i~ is pem~ittc~l to be e.~;ecutcd.
~ cfp~ lcn~rtll: 'I'he Icngrth of cfpkrl in 8 b~1e blocL;s. cfpkrl is storc~l in thi l'U.~ 13uffcr and contaills thc l'ublic Dc~ice ~uthcntication Kcy (I'UA).
~ P(,~ f~cr: Thc T'l,'t~ buffcr contains spacc for thc stora_e of cfpkrl, ~hicll contaills 1'1,';\. Thc Pl'.\
but'fcr is uscd only by thc l'KCD instructions.
~ cfp~;r~-l( n~tll: 'I'he len~th of cfpl;r2 in 8-b~le bloclis. ct'pl;r2 is storccl in thc l'R,~ 13uft'er and co1lt;~ s thc Pli~atc Dc-icc ~\uthcntication l;cy (I'R.~).
~ I'R,~ ffi7~- T]lc l'R~ buffcr contains spacc for the stora_e of cfpl;r~ hich contains l'R.-~. 'I'hc PRf\
buffer is used onl~ by the l'l~CD instructions.
~ Scc~et l'ro(l~ct Enlironmcnt L~n~th: I'he Icnnth of the secrct ~roduct en~ironrncnt in b!tes.

Componcnts of the G~pto~r~phic l~cilit~ 23 Seclet Yrwtl~ct ~n1,~iro)lment: Tlle secret product environmel1t cOnsists c)f a set of tlle secret cryptographic variables unique to a product or implemeIltalion. That is, secret cryptc~grapllic variables not specified by I'K~I) bllt needed by a product.
No11stcretProdl~ctE7lltir~771711e7ltLc71gtl1: The Icngth of the nonsecret prodl,lct environn1el1t iJl byt:es.
No71sccret Prodl~ct E7l1tiron7nt7lt: The nonsecret product envirorlrl1ent consists of a set of the nonsecret cryl~tographic variables unique to a product or implemeIltatioll That is, nonsecret cryptographic variables n-)t spccified by PICCD but needed by a prodllct.
~KULc71,~tll: The lengtll in l)ytes of the EICU in the EICU buffer.
EKU Bll~tr: A l~uffer for the temporary storage of an Extemal ICey Unit, (F.ICU) (e.g., an EICU loaded into the CF via an interfa(-e other thaI) the CFAPtoCF interface).
GKSP Sa~c: A field used by processmode= I of the Generate ICey Set Pair ~GICSP) instruction to save inforIllatic)n needed by proccssrmodt =2 of t:he GICSP instrllctioIl.
Gl<S~' Bl~ffer Lc~l~tll: The leIlgt 11 of C,-IICSP Bul'fer in hytes.
GKSP Record Le~tll: 'I'he lengtll of record or block in GI~SP Buffer in bits.
GKSP Bllfferl/ag: A 11ag indicating the status of the record or block in GICSP Buffer, as folk~ws:
4255: reserved 3: ~lICSP 13uffer contail1s a record of llnspecified fon1lat that m~lst be processed to produce a keyblk which is thell encrypted.
2: C~ICSP Buffer contaiIls a keyblk of unspecified format that nceds only to be encrypted.
1: GICSP Buffer cont,ains a CF DE~ ICey Record.
0: CIICSP Buffer is empty GKSP licket: ~n ~byte pseudoral1dom value generated via e~ecutiol1 of processmode= l of the GKSP
instruction.
GKSP Buf~er: ~ buffer for the storage of a key record or key bloc-k. II)K S~VE: A fiekl used by processmode= I of the Import D~A ICey (II)IC) instruction to save inforl11ati(,)l1 nee(led by processrrlo(ie=2 of the IDIC instruction.
IDK Buffer Le7lgtll: T}le lengtl1 of IDIC Buffer in bytes.
IDK Rcc07d Le71gth: rhelengtll of record or block in IDIC Burfer in bits.
IDK Bu~er~lag: 1~ flag indicatillg tl1e status of tlle record or block in IDIC Buffer, as follows:
4255: reserve(i ~ : IDIC Bufft r contail1s a record of uIlspecified format recovered from a keyblk of specified format recovert d by processmode= I of the IDIC instructiol1 by decrypting a keyblk encrypt,ed with public kcy managelrlellt, key of anotl1er device (ePUM(keyblk)).
2: IDK Buffer contairls a keyblk of unspecified forrnat recovered by processmode= I of the IDK
instrllctioll by decrypting ePlJM(keyblk).
1: IDK Buffer contains a CF DEA ICey Record.
(): IDK Buffer is empt,y IDK 7icket: An 8byte pseudoraIldolll value generated via execllti(n1 of processmode= I of the IDK
instru( tiorl.
IDK 13~ r: 1~ b1lffer for the ~storage of a key record or key block.
Configuration Vcctor The configuratiol1 vector has the following specificatioIl:

r'~
_ -i2U I ~29 CONFIGURArrION VE("I OR:
l~it~
0().. ()7 Version Nulllbcr X'00': reserved ~'()1': PICCD
X 10 X'FI ': reserved 08..151 DEFINE f;eld l he DEFINF, field is a vector in(lexed as DLFINE(i) for i = 0,1,...,143.
For i = 0,109 DEFINE(i) is reserved.
For i = 1 10,11 1,...,143 DEFINE(i) pertains to the instructions of the PI~D.
DEFINE(i) for i = 110,...,143 has the following mea~ lg:
B'l': instructioIl is defined to the CF in the ''ruIl'' state B'0': instruction is not defined to CF in the ''ruIl'' statc Note: DEFINE(i) for i = 110,...,143 pertains only to executioll of instrllctioIls in the "r~m" state.
A list of the instrtlctiolls and their correspoll(lillg indices are provide(l in F ig. 27.
152..2~5 AUTI I (I~()Nl ROI, field I he AU I H CONrrROI. fiekl is a vector in(lexed as AU I E I ('ONTROl,(i ) for i = 0,1,...,143.
For i = (), I, ...,109 AUTI I CONTROL(i) is reserved.
I or i = 110, ...,143 AUTI I CONTROL(i) pertains to the instru( tions c)f PI~CI).
AU I I I CON I ROL(i) has the following meaning:
n~ P the I,CV instruction sets AUTI-I(i) = B'1' and ENABl,E(i) = B'l 1' (i.e., "authorization rc(luire(l" &"disal-led").
B'(:)': tlle I,C'V instrl1ctioll sets AUTH(i) = B'0' and ENABI,E(i) = B'00' (i.e., "authorization not re(luired" & "enable(l").
A list: of the instrllctiolls and thcir correspondiIlg indices are provide(l in Fig. 27.
29(~ CER I'II I(.A I ION
B'1': certifica~ioIl cellter (the device can act as a certificatioIl center) B'0': not a certificatioll center (the device cannot act as a certifi(ation center). This means the following: Gencrate Public and Private I~ey Pair (GPUPR) cannot generate a certification key pair;
a PRC key cannot be used with the Generate Digital Signature (GDS), Generate Application Digital Signatllre (GADS), and/(-)r Export Public I~ey (EPUIC) instrllctions to generate a digital signature.
297 PICA IOEY ENCRYPTING MASTER IOEY (ICMP) REI,OAD
B'1': if CllrreIlt PICA ICey Encr~pting Master ICey (CICMP) IIISTORY in state vector = (), thcll ICMPmode = 1 must bc specified in the Export Crypto Facility EnvironmeIlt Record (ECFER) instruction (i.e., the ICMP must be rel~aded at the receiving device).

~07532~

B'()': no restrictions Note t:hat this field pertains only to tlle ECF}.R instructioll.

B'I': (reserved for fl1ture use) if C'urrellt DF,A ICey Encrypting Master ICey (CICM) IIISTORY in state vector = 0, then ICMmode = 1 rmlst be specified in tlle ECE'ER instructioll (i.e., the Dl',A key encrypting master key ICM must be reloade(l at the receiving device).
B'0': n o rest riction s Note: this field pertains only to the ECFER instrll( tion.
Note: the I CV instrllction sets this bit = B'0', which guarantees that present systems shall be colllE~atible with futltre releases implementing the ICM RELO~I ) l it.
~'~9 . . '3()(:) I'LOORMDC field Tlle FLOORMI:)C field specifies the following:
a. 'I'he minilllllm TI IRESMDC value that may be specifie(l in the I'rivate I{ey Management ICey (PRM) c ontrol vector in the GPUPR instnlctioll.
'lle IllinitllUlll I IISTMDC value in the PUA control vector that caIl be processed by the F,CFER
and ImE~(:)rt C'r~to Facility EnvironllleIlt Record (ICl'ER) instructions.
Tlle l'LOORMI)C ficld has tlle following meanillg:
13'1 1 ': 'I'lle referellce(l TI IRE.SMDC or E IIS'I'MDC' mllst have a value = B' 1 1.
B'10': 'I'he rcfercnced THRI'.SMDC or HISTMDC must have a value >= B'10.
B'(~ 1 ': The reference~l THRESMDC or HISTMDC must llave a vallle > = B'0 1.
B'00': reserve(l Note that the FLOORMDC field controls the processing of PU keys in tht GPUPR, ECFI'R, and ICI:ER instrllctions.
3()1..302 ICMGT PROTOCOL (i.e., key management protocol via the GICSP and II)IC instrllct:ions).
B'11': CICMGT & PICMGT (i.e., certification center and private key maIlagenlellt protocols are enablecl).
B'10': CICMGT (i.e., certification center key maIlagenlellt protc)cc)l is enabled) B'() 1': PICMGT (i.e., private key managemeIlt protocol is enal~le(l) B'()0': nolle Notes:
a) ICMGT PROTOCOL = B'11' means that the keymallagelllentE)rotocol paranleter in the GICSP
and IDIC instmctiolls may be 0 or 1.
b) ICMG'r l'ROTOCOI, = B'10' mealls that the keynlallagemelltE)rot:ocol parameter in the GICSP
an(l Il)IC instructioIls may only be 1.
c) ICMGT PROTOCOL = B'01' means that the keymanagelllentE~rotocol parameter in the GICSP
and IDIC instmctiolls may only be 0.
d) ICMGT PROTOCOL = B'00' means that key management via the GIC~SP and IDIC instructiorls is nOt penllitted.
303..3n4 BICUP PROTOCOL (i.e., protocol for CFenvirollllleIlt backllp via the ECFER and ICFER
instrllctiolls) .

2~7~32~
B'l 1': PBICUP (privatc protocol, i.e., no restriction on how PUA is importe(l) B'10': CBICUP2 (certiricatioll center protocol where the l'UA control vector has I~ISTCI~AIN=3) B'() 1 ': CBICUP I (certifica~ioll center protocol where the PUA control vector has HISTCI IAIN=2) B'()0': llC) backtlp p( nnitte(l Note that the spccification matchcs that of the protocol-mode parameter in the IECFI,R and ICFER
instrll( tions The BICUI' PROTOCOL field is valid onlywhen DEFINE(~CI ER)=B'I' or Dl,FIN},(ICl ~R)=B'l'.
3(~5 ICRl:~G field The ICREG field dcfines the key registration mode or mo(les perlllitte(l for certification center kcy managelllellt and for certification center backup, as follows:
1: restricted mode 0: unrestricted mode Note: the meallillgs attached to restricted mode and unrestricte(l mode are specified by the neh~vork~ i.e., set forth according to network security policy.
For example, the certification center could define restricted mc)de s~lch that tlle colldilioll~s in (a) or (b) must l~e satisfied, as follows:
(a) PUM key registration is performed in a pllysically secure envirollment; ICMI' is loacled into tlle device by trustcd personllel using the Load First PICA Master ICey Part (LFPMICP) and Com~ille PICA Master ICey Part (CPMICP) instructions or ICMP is internally generated tlSillg thc Generate New PICA Master ICey (GNPMIC) instmctioll.
(h) PUM key registration is not performed in a physically secure envir(:)lllnent~ but the Extemal ICey Unit containillg l'UM (sent to the certification center for registration) is signed with a PRA key which has been indepell(lelltly validated by the certification center as originating from witl~in the said dcvice. I~MP is interllally generated using the GNPMI< instn1ction.
Bot:h (a) and (b) represent very 'high security' modes.
3(:)6 IN I I,RCI IANGE
B'l': interchallge (the device can act as an interchallge device). A PRA, PRM, and Private User I~ey (PRU) key can be use~ with the GDS instrllctic)n to generatc digital signat~lres.
B'0': not intcrcllallge (the device cannot act as an intcrcllange devicc). A PRA, PRM, and PRU key callllot be used witll the GDS instrllctic)n to generate digital sigrlatllres.
3~)7..3()8 SIG-COMI'ATIBILITY field l he SIG-COMI'ATIBII,I IY field is a vector indexed as COMI'ATIBII.ITY(i) for i = O and 1.
For i = (), SlC,-COMPATIBILITY(i) pertains to the IPUIC instmction.
For i = I, SIG-COMI'~TlBlLITY(i) pertains to the IDIC instnlction.
SIG-COMPATIBII,ITY(i) has the following meanillg:
B'l': the instruction does not require CF authentication of system signatures.
B'()': the instructioll rcquires CF authentication of system sigllatures.
309..511 reserved, set := 203 B'0'.

~075329 Default ('onfiguration Vector Tlle clefalllt c c)llrigtlratioIl vector is tlle value of tlle configuratioIl vector autolmatically set via execlltion of an F,IS instrllctioIl The value of the default configuration vector in 8 groups of 16 hexadecimal digits per group is as follows 2. X'I'I'I'F0000000003FF' 3. X'FFFFFF0000000000' 4. X'000000()00~)()00000' 5. X'0000()00000()E0000' 6 X'00()0()0000000()()00' 7. X'()()()()000()00000000' 8 X'()()0000000()00000o~
l he defalllt c onfigtlration vector has the following specification DF,I AUI, I CONFIGURATION VECTOR
l~it s vall1e field 00.... 07 (= B'00000001') Version Number 08.... 151 DF,FINE
08. .79 ( = 72 B' I ') Reservc d X0.... 117 (= 38 B'0') reserved 118... 151 (= 34 B'l') PICCD instructions (VADS tllru VII<U) 152... 295 (= 144 B'()) AUTII CONlROL
296 (= B'0') CERTIFICAI ION (llOt certification center) 297 (= B'0') ICMP Rl,l,OAI) (no restrictions) 298 (= B'()') ICM REI.OAD (no restrictions) 299... 30() (= P,'()l') II,OORMD(C field (Ihe referenced TIIRESMDC or IIISIMDC
mttst have avalue >= B'01'.) 3()1.. 3()2 (= B'l l') ICMGT PROTOCOL (CICM('.T and PICMGT modes) 303... 3~)4 ( = B'()()') BICUP l'RO I OCOL (backllp not perrmitted) 305 (= B'()') ICREG field (ullrestricted Inode) 306 (= B'0') INTERCHANGE (not an interchallge) 3()7 (= B'0') SIG-COMI'ATIBILITY(IPUIC) (signature required) .3()8 (= B'()') SIG-COMPATIBILITY(IDIC) (signature required) 309... 511 ( = 203 B'0') reser~ed State Vector 'I'he state vector has the following specificatio STATE VECTOR
00 ICP FI~G (ICey Part) B' I ' tlle Ia~ register is in the "full" state B'0' tl~e ICP register is in the "empty" state 01 OICM l'LAG (Old DEA key encrypting nlaster key) B' 1 ' the OICM register is in the "full" state B'0' tlle OI~M register is in the "empty" state Note In a subseqllent release of PICCD, the existing OICM llag shall be reinlplelllellted within the state vect,or I'or the presellt, this field is initialized only via the Export Crypto E~acility Audit Record (ECFAR) instmction (thus Illaking it appear that the OI~M flag is implemeIlted within tllestate vcct(-)r).
02 CKM FI AG (Currcnt DEA key encryptillg master key) B'l' t,he CICM register is in the "full" state B'0' the CICM register is in the "empty" state Note In a subsequeIlt release of PICCl), the exist,ing CI~M flag shall be reimplemented within the state vector For thc prcscnt, this field is initiali7,e(1 Oll]y via the ECI'AR instnlction (thus making it appear that tht~ M flag is implemellted within the state vector) 03 04 NI~M I~I.AG (New Dl~ key encryptillg nlaster key) B' I I ' reserved 13'10' the NICM register is in the ~rull~ state B'0 1 ' the NICM rcgister is in the "partially full" stat~
13'()()' the NKM register is in the "empty" state Note In a subsequent release of PICCD, tlle existing NICM flag shall l-e reim~lemenled witllin the state vect-)r For the present, this field is initialized only via the I~CFAR instruction (thus makillg it appcar that the NICM flag is impleIllented withill the state vector) 05 Rcservcd 06 12 RESERVED (= 7B'0') B'1' ~1 exec~ltable progralll has heell loaded B'0' An executable prograIll has not been k)adc(l 14 PROGMDC0 FL.AG (Sccure loadable prograIll MDC #()) B'1' PRO(lMDC0 btlffcr is in the "fllll" state B'()' PRO(lMl)C() b~lffer is in the ''eIllpty'' state 15 PROGMDCI FI,~G (Secure loadable progranl MDC #1) B' 1' I'ROGMDC I buffer is in the "fnll" state B'()' PROGMDC I b~lffer is in the "empty" state 16 21 ICM I IISTORY field The ICM HISTORY field is a vector indexed as ICM I IIS'l'ORY(i) for i = (),1,2, where i is defined as 0 OI<M

KM l-lISTORY(i) has the following meanillg E~' I I ' reserved , ~ ~,,, , . ~;, B'l()': (rescrved) Generate New DEA Master ICcy (GNDMIC) (i.e., the contellts of the ICM register were produced via execution of the GNDMIC instruction).
E3'() 1': (reserved) LE MICP/CMICP (Load First Master ICey Part/Colnbil)e Master ICey Part - i.e., the contents of the ICM register were produced via executioll of the Ll MICP and CMICP instr-lctions).
E3'00': indeterminate Note: Tlle EPS instrllctioll sets this field to B'000000', ensurillg the present PICCl) ~ill bc-colnE~atible witll futl1re releases of PICCD implementing code points B'01' and B'10' of the ICM
E IISTORY field.
Note: In a subseqllent release of PICCD, the SMIC instrllction shall be modified so that the OICM
HISTORY field is updated from the CICM E IISTORY field.
Note: In a subsequellt release of PICCD, tl~e SMIC instruction shall be Inodified so that the ('ICM
I IISTORY field is updated using a nlet.hod whi( ll is similar to that followed by the SPMIC
instmctiotl in its managelllellt of the CICMP EIISTORY field. rl'he SMIC instrllctic)n shall also be modified so that the CICM HISTORY field is reset to the !'indeterlllillate" state whellever the (:'ICM
E~Ll~G is reset to the "empty" state, and tlle Nl<M EIISTORY field is reset to the "indetenllillate"
state whenever the NICM FIAG is reset to the "empty" state.
Note: In a subsequent release of PICCD, the GNDMIC instrl1ction shall be rmodified to resct tlle NI~M HI~TORY field to B'10', and the LFMICP and CMICP instrllctions sllall be modified to reset the NICM E IIS I ORY field to B'0 1'.
22..165 AUTE-I field The AUTE-I field is a vector indexe(l as AUTI l(i) for i = 0,1,...143.
For i = 0,1, ...,109 AUTEI(i) is reserved E~or i = 111), ...,14'3 AUTIl(i) pertains to instrtlctions of the PICCI).
AUTE-l(i) has the fo]lowing nleanillg:
B'l': t:he SEF instnlction can be tlsed to cnable execution of instruction or instruction mode "i"
only after supplying appropriate proof of allthorization to the CF. The level ofauthorizatiorl is deternlined by the imE)lernentatioll and can l)e different for each "1."
B'0': no restrictions AUTI I(i) is not defined for the following instructiorls:
( 1 ) Load Physical Identifier (LPID), Gerlerate Device Authellticatioll ICey Pair (GDAIC), I.CV, since they do not execute in the "run" state.
(2) Enter Run State (ERS), since the specification is contra(lictory.
(3) Set Enable Flag (SEF), since this could lead to "lockout."
A list of the instrllct:ions and their corresponding indices arc provided in Fig. 27.
166..453 ENABLE field I he ENABLE field is a vector indexed as AUTE I(i) for i = 0,1,... 143.
Fc)~ i = 0,1, ...,109 ENAE3LE,(i) is reserved For i = I l(), ...,143 ENA13I,E(i) pertains to instmctiorls of the PKCI).

207532'~

EN~BLE(i) has the following meaning:
B'l 1': instruction or instruction mode execution not enabled.
B' 10': instmction or instnlction mode enabled for n executiolls~ where n (a value from I to 255) is a val~le specified by an instruction inpllt parameter.
B'()l': instmctioll or instmction mode enabled for 1 execution.
B'00': instmction or instruction mode enabled for any number of executions.
E NABLE(i) = B'00' and ENABLE = B'l 1' are valid for all but the following instructions:
( I ) I,PID, GDAIC, LC~V, since they do not execute in the "run" state.
(2) E~S, since the specification is contradictory.
(3) SEF, since this could lead to "lockout."
I,NI~BLI,(i) = B'10' is valid only for the follc)wing instructions:
( 1 ) CPMI~P inp~ltmodc=0 and CPMICP inplltmode= 1 (2) GPUPR n-~ode=0/2.
ENABI.r,(i) = B'() I ' is valid only for the following instructiolls:
( I ) EMDCC (I,oad Ml)C' for Public Certification I{ey) (2) LMDC (I.oad MDC) (3) LFPMIC inputmocle=0 and l.,FPMI~ inputmode= 1 (7) GNPMI{, (8) GNDMIC, (9) SPMIC, (Set PICA Master ICey) (10) ECFER
A list of the instrllctiolls and their corresponding indices is provided in Fig. 27.
454 Cl.ONE (history bit ) B' 1 ': CFenvironment has been set via the ICFE~ instnlc tion.
B'0': original CFenvirolllllent Note: this bit is reset to 0 via executioll of an EPS instructioll but not by an EIS instructioll. This bit is set to B' 1 ' via execulioll of the ICFER instmctic)ll.
455..457 ICMI'I IIS IOI~Y field The I<MI'I--IISTORY field is a vector indexed as ICMPI IISI ORY(i) for i = 0,1,2, where i is dcfined as:
0: OICMP I IISTORY
1: CI<MP HISTORY
2: NICMP I IISTORY
I<MP stands for PICA ICey encryptillg Master key.
ICMPI lISTORY(i) has the following meaning:
~'1' : GNPMIC (i.e., the contents of the ICMP register were prodllced via execution of the GNPMIC
instructioll) .
B'0': I.~PICMP/C'PMIa' (i.e., the colltents of the ICMP register were ~roduced via executioll of the I,FPI<MP and CPMICP instructions).
Note: ICMPI lIS I ORY(i) has meallillg ollly when I<MPI~LAG(i) is in the "filll" state.

~0~5329 45~..461 ICMPI LAG field I lle I<MPFLAG field is a vector indexe~1 as ICMPl~ G(i) for i = 0,1,2, where i is defined as:
0: OICMP FLAG
I: CICMP I LAG
2 : NICMP I I,ACI
For i = O and I, ICMPFLAG(i) is a 1 bit f;eld with the fo110vriIlg Inealling:
B'l': the ICMP register is in the "full'! state B'O': tlle I<MP register is in the "empty" state E~or i = 2, ICMPFI~AG(i) is a 2 bit field with the lollowing nleallillg:
B' 1 I ': reserved B'10': the ICMP register is in the "full" state B'O1': the ICMP register is in the "partially full" state B'O()': the ICMP register is in the "empty" state 462 GDAIC FI~G
B'l': the PUA buffer, PRA buffer, PU~CV registcr, and PRACV register are in the "full" state.
B'O': the PUA buffer, PRA buffer, PU~CV register, and l'RACV register are itl the "enlpty" state.
463 I.,I'ID FI~G
B'l': the Device Identifier (DID) and Environmellt Identifier (EII)) registers are in the "full" state.
B'O': the I)ID and EII) registers are in the "empty" state.
464 1,CV FI~AG
B'l': a configuration vector llas l~een loaded USillg an I,C~I instrll(tion.
B'O' : a configuration vector has not been loaded using an LCV instrll( tion If CF S rATE = "init" or "rlm", then CONFIG FI..AG = B'O' in(1icates that a default configuration ve~tor has beell loaded.
465 EICU l I~G
B'l': an EICU is stored in the F,ICU buffer and its length is stored in EICU Length.
13'()': an rKu is not stored in the EICU buffer and its lengtll is not stored in EICU Length.
466..467 CF ~'I'ATF
B' I 1 ': reserved B'10': the Cl is in the "run" state B'O1': th~ CF is in the "init" state B'OO': the c~r is ill the "preinit" state Note: the CF states control inst.ruction executioll.
468..501 EICUMDC FLAG field The EICUML)C FI,AG ~ield is a vector indexed as EKUMDC FLAG(i) ror i = 0,1,...,16.
For i = (), I ,...,15, EICUMDC FLAG(i) has the following meaning:
B'l 1': EICUMDC(i) has been initialized with an MDC loaded via a secure interface (e.g., via a smart card).
B' 10': F.ICUMDC(i) has been initialized with the LMDCC instrll( tion B'O1': EICUMDC(i) has been initialized via the IPUIC instrn(tioll.
B'OO': EICUMDC(i) is wliIlitialized.

B r9-9 l -o l s 207S~29 For i = 16, EKU.~/~DC F~LAG(16) has the following meaning:
B'Il': EKU.~ilDC(16) has been initialized with an i\~lDC loaded via a secure interf~ce (e.g., via a smart card).
B'10': EKU~IDC(16) has been initi~ ed via an L.\~fDC instruction.
B'01 ': reserved B'00': EKU.~fDC(16) is nniniti~li7ec~

B' I' : one or more PR have not been randomly generated inside the CF.
B'0': all PR have been randomly generated inside the CF.
S03 ECFER Status B'l': the ECFER instruction has been executed at least once (i.e., the CF environment of this device has been e~ported).
B'0': the ECFER instruction has not been e~ecuted.
SW AL.~R.~f FLAG
B' l' : ~ rm has been acti~ ated B'0': no rUann S05..S0~ IllS'I'-DO.~,f~
This fiekl contains a domain iclentifier (an arbitrary ~alue from B'0000' to B' 1111'). The IlIST-DO~It~l~r field in the state vector is set by the ECFER instruction equal to the value of DO.\;I,~ ID
in the IllST-DO~f~ T field of the l'U~ control vector contained in IKUI, which is input to the ECI~R instruction.
This field is valid only if the CLO~'E bit in the state vector is equal to B'l' and BKUP PROTOCOL in the configuration vector is equ31 to B'01' (CBKUPl) or B'10' (CBKIJP2).
S09..S11 reserved, set = 3 B'0'.
Registers The following registers are defined by PKCD:

NKMP Register S 128b New PKA Master Key Register CKMP Register P 128b Current PKA Master Key Register OKMP Register P 128b 01d PKA Master Key Register DID Register P 128b Device Identifier Register EID Register P 128b Environment Identifier Register PUACV Register P 128b PUA Control Vector PRACV Regi ster P 128b PRA Control Vector The reg~isters are designated as perrnanent (encodecl ~vith letter ~1'") or semi-permanent (encoded w ith Ietter "S"). The contents of the permanent registers must be preser~ed for the 'life of the system,~ e.g., ~ia a battery-backed R~ ,f. Values stored in the perm ment registers ch;mge or are ch~nged according to .m installation-deterrnined schedule. 'I he contents of the serni-permanent registers must be prèser-~ed onl~ until the information they contain has béen processed by a CF instruction.

Componenti of the Cryptocraphic Faci1ity 33 207~329 l\IDC T~ble The ;\IDC Table is a vector EKUl\~lDC(i), for i = 0,1,...,16, ~vhere each EKl'~lDC(i) contains storage for a l2S bit .~IDC value.
Fig. 28 illustrates the organization and indexing of the .~,IDC T.~ble.
The ~iDC Table is used by the IPUK instruction to import public keys, which are presentcd to the IPUK instruction in the form of an E~tcrnal Key Unit (EKU). For i = 0,...,15, thc ~fDC in EKlJ'.~lDC(i) must be calculated on an EKU containing a public certification key (i.e., a I'l,'C key) and the domain ID
field in the control vector of the PUC kcy must contain the value "i". For i= 16, thc :~,IDC in EKU~lDC(i) must be calculated on a EKU containing a public key m.~n.~Pcment key, a public authcntication key, or a public user key (i.e., a I'U~, I'UA, or PIJU key). The domain ID field can cont3in any value from 0 to 1~.
Counter T~ble The Counter Table is a vcctor COUNTER~i), for i = 0,1,...,143, where cach COlj'~'TER(i) contains storage for ~m ~ bit counter. For i = 113, 11~, or 120, COU?'.1'l'ER(i) is defincd. For i ~ 113, 11~, or 120, COU~''I'ER(i) is not dcfmed (i.e., this portion of Counter Table is null).
The value of COU~TER(i) denotes the number of times that instruction "i~ can be e~cecuted before E~\ABLE(i) is set from B'10' to B' l l'. Fig. 27 specifies the relationship bet~veen inde.Y and instruction n~me. I or e.~cample, i= 113 dcnotes input-mode= 0 of the Cl'.\~l~P instruction.
I~ig. 29 illustrates the organization and inde.Ying of the Counter Table.

Control Vector Enforcement Control vector enforcement is a method which ensures that the control vectors processed by each CF
instruction are consistent with and in conformance with certain instruction-unique rules and restrictions which limit or defLne the values that these control vcctors may have. Control vcctor enforcement may bc accomplished by, although is not limited to, one of the following methods or combinatiol1s thercof:
~ Specifv Conlrol Yecror in CF~IP and Check Control Yecror Bits in CF: This mcthod checks bits and fields within the control vcctor to ensure that they contain pcrmitted values. In ccrtain cascs, cross checking of bits and fields among two or more control vectors is necessary to ensure that they contain only permitted combinations of values.
~ Specifv Control Yector in CFAP and Set Control Yector Bits in CF: This mcthod scts bits and ficlds within thc control vector to prescribed values (i.e., by over~vriting the bits aIld ficlds of the control vectors passed at the instruction interface).
~ Cenerate Cont~ol Vecto~ in CF from lnfcrmation Specified hv CF~IP: This mcthod ~cncratcs control vcctors f'rom paramctcr information passcd at the instruction interface.
~ rable l ook~lp of Control Yector in CF from Inde.~ ~Specifed hy CF~P: This mcthod uses a t;3ble of control vcctors storcd ~vithin the CF. An inde:c value passed at the instruction intcrface sclccts thc control v cctor or vectors uscd by an instruction.
For convcniencc, control vcctor enforcement is dcfincd in this teaching using a combination of thc first and third methods dcscribcd above. Some control vectors are spccified as instruction parameters and bits and fields in thcsc control vcctors are checked by the CF. Other control ~ ectors are gcncratcd ~vithin thc CF, e.g., it is typical for the control vector associated ~vith the rightmost 6~ bits of a l'S bit key to be dcrivcd from the control vector associated ~vith the Icftmost 6~ bits of a I~S bit l;cy.

Components ol ~he Cr)ptoYraphic racili~y 3 2û7~329 Initi~liz~tion Requirements Some CF instructions process cryptovariables stored internally within the CF, which must be loaded or irnported into the CF before instruction exccution. Several CF instructions havc bccn dcfined to support the initi~ tion and configuration of the CF. However, PKCD does not define or spccify how key parts are loadcd into the ~P register.
Those CF instructions which process cryptovariables storcd in thc KP reg,ister, which must be loaded ~ia means other than those defined in the I'KCD, are listed in the following table.

Instructi~n Cryptovariable CF Storage Location LFPMKP key part KP register CPMKP key part KP register PKCD do not definc how key parts are loaded into the KP rcgister. One possibility is for ~ey parts to bc loadcd by authorizcd installatioll personnel via a protected, controlled intcrface. I hc physical intcrf~ce described earlier could be used for this purpose.

Power On Sequence During each power-on, the CF e~cecutes a powcr-on sequence (POS) routine. Thc POS routinc does the following:
~ Initialize the PRNGKEYl and PRNGKEY2 registers with random seed keys.
If the content of the POS register - X'0123456789ABCDEF0123456789ABCDEF' then continue; else do the follo-ving:
- Perforrn the EIS instruction to clcar the CF environment.
-- Set POS register := X'0123456789ABCDEF0123456789ABCDEF'.

Record Formats and Descriptions The following records are defined by PKCD:

Components of the Cr~pto~raphic r3ciiity 35 13'r9-91-015 207 ~;329 Record Name Length Crypto Facility PKA Key Record multiple of 8 bytes Crypto Facility Key Authenticator Record multiple of 8 bytes Crypto Facility DEA Key Record 64 bytes Crypto Facility Backup DEA Key Record 64 bytes Crypto Facility System Signature Record 64 bytes Crypto Facility Environment Record multiple of 8 bytes Crypto Facility Audit Record multiple of 8 bytes Internal Key Unit multiple of 8-bytes Clear Key Unit multiple of 8 bytes External Key Unit multiple of 8 bytes Skeleton Key Unit multiple of 8 bytes Rccord Formats and D~scriptions 36 Crypto Facility l'ICA ICey Record (CFPICR) The Crypto Facility PICA ICey Record (CFPI<R) contains a pnblic or private kcy llsed with a p~Jblic key algorithm. If different public key algorithlrls are used for key distr;blltioll and digital signatures, thetl the CFPICR contains two public or two private keysone key for key distributioll and ~he other for digital signatl1res The CFPICR is defined to be a mllltiple of 8 bytes.
A Cryp~o Facility l'ICA ICey Record has the following form:
Offset Lengtll Data (in bits) 0 a Parse a b ICey c d RN (where c = a+b) e 0 Bnd of CFPICR (where e = c+d) DATA DESC1~3P I'ION
PARSE I he parse field contains data that permits the CI~ to parse the key field. The length of the key parse field is nc)t prescribed by the arcllitecture. 'I'hc key parsc field MUST pexmit the key, or any portic)ll of the key, to be ulli(ltlely identifie(3alld lo(ated in tlle key field. The parse field mllst directly or indirectly specify key lengtll, such that all adversary cannot callse the CF to use only a portion of a key as a fnl~l key. In adclition, the parse field contains at least 8 bytes of random data to act. as a confolln(ler to tllwart revealing any contellts of the encrypted CFPICR by pattem analysis by anadversary.
IOEY The Icey field contains a PICA key. The key is either a public kcy or a private kcy. Tlle key stored in the key field consists of one or more key variables that together constitllte or define the key. For example, if the PICA is based on exponentiation modulo a n~lmber n, then tlle key COllSiStS of an exponellt e and a modulus n. Both e and n are stored in the key field, and the parse field is defined in SUCIl a way to permit e and n to be located. ICey length and format of the parse and key fields c an be differ~llt dependillg on whether the key is a public key or a private key. If a first PICA is used for key distribut:ioll and a second PICA is used for digital signatures, tllen the ICey field CC)ll(aillS a pair of ptlblic or private keys (i.e., a key for each algorithln). The fact that there are two algorithnls i~s made transparellt to the ('FAP.
RN The RN field contains a dbit random nnmber gcnerated within the CF. The value d ranges from 0 to 63 and is chosen so that the length of Crypto Facility PICA l~ey Block (CFPICB) is a mllltiple of 8 bytes.
Outside the CF, the CFPICR is encrypted lmder a variant key ICMP.C fonlle(1 as the F,xclusive OR product of ICMP and control vector C.

13T9-91-015 Cr~pto F~cilit~ Key Autllenti~tor Record Crypto Facility Key Authenticator Record (CFKAR) 207 j32 9 The Crypto Facility Key Authentieator Record (CFKAR) contains information functionally related to a single CFPKR. The CFKAR is used to authenticate a CFPKR. The CFK~R is deftned to be a multiple of 8 bytes.
A Crypto Faeility Key AllthPntie~tor Reeord has the following form:
Offset Length Oata (in bits) O a Key Authenticator a b RN
c O End of CFPKR (where c = a+b) D~t~ D~scription Kcy Authentic~tor T he key authentie~tor field eontains data funetionally rel~ted to a CFI'KR.
R~' The Ri~ field eontains a b-bit random number generated within the CF. The value b ranges from 0 to 63 and is ehosen so that the length of CFKAR is a multiple of 8 b~tes.
Outside the Cl~, the CFKi~R is enerypted under a variant key K~IP.C formed as the E~celusive OR
product of K.~fP and control veetor C.
Methods for deriving a key authentieator from a key reeord has been diseussed in Key Record Encr~ pt rUgorithm 12 of Fig. 16.

Record Formats and Descriptions 38 sr9-91-0ls Cr~pto l~acilit~ DEA l~e~ Record Crypto F~cility DEA Key Record (CFDKR) ~075329 The Crypto ~acility D~A Key Record is produced by a GKSI' instmction and is processed by an IDK instmction. The C~DKR is a ~2 byte record.
A Crypto ~acility DEA Key Record has the followin~ forrn:

Offset Length Data (in bytes) C 1 Record ID
The most significant bit in a byte is the leftmost bit.
0003 0000 - 'Crypto Facility DEA Key Record' 1 1 Record Code 000 xxxxx - 128b key-encrypting key produced by GKSP and processed by IDK.
l~lhen bits 0..2 of the above field are B'OOG', bits 3..7 are defined as follows:
Control Vector Format 330 xxxOO - control vector field stores hash of 128 bit C.
030 xxx01 - control vector field stores hash of 64 bit C.
000 xxx1x - reserved KEY-MANAGEMENT-PROTOCOL specified in GKSP (implying IDK
must also specify the same) 303 Oxxxx - private protocol 000 1xxxx - certification center protocol KEY-MANAGEMENT-MODE specified in GKSP (implying IDK must also specify the same) 333 x~xxx - key registration is performed using mode O
003 x1xxx - key registration is performed using mode 1 001 xxxxx - reserved 31x xxxxx - reserved 1xx xxxxx - reserved 2 2 Reserved (=X'303a') 4 16 EID - The value of EID stored in the CF Environment of the originating device.
2a 16 h(C), where C is a 64- or 128-bit control vector and h is a hash function. Basically, if C is 64 bits, then h(C) = concat(C,C). And, if C is 128 bits, then h(C) = C.
36 16 Key - This field contains a 128 bit odd parity adjusted key generated within the CF by the GKSP instruction.

Record FormaLs ~nd Descriptions 39 13T9-91-015 Cr~pto F;lcility Bacliup DEA Key Record Crypto F~lcility B~ckllp DEA Key Record (CFBDKR) ~o7 ~2 The Crypto Facility Backup DEA Key Record is produced by an ECFER instruction and is processed by an ICFER instruction. The CFBDKR is a 52 byte reeord.
A Crypto Facility B.~ckup DEA Key Reeord has the following form:

Offset Length Data (in bytes) 0 1 Record ID
The most significant bit in a byte is the leftmost bit.
OOGO 0031 - Crypto Facility Backup DEA Key Record 1 1 Record Code PROTOCOL-MODE specified in ECFER (implying ICFER must also specify the same) xxxx OOxx - invalid xxxx 01xx - certification center protocol where the PUA
control vector has HIST-CHAIN=Z
xxxx 10xx - certification center protocol where the PUA
control vector has HIST-CHAIN=3 xxxx 11xx - private protocol.
KMP MODE specified in ECFER (implying ICFER must also specify the same) xxxx xxCx - KMP-mode = a has been specified in ECFER
xxxx xx1x - KMP-mode = 1 has been specified in ECFER
KM MODE specified in ECFER (implying ICFER must also specify the same) xxxx xxxO - KM-mode = O has been specified in ECFER
xxxx xxx1 - KM-mode = 1 has been specified in ECFER
2 1 Hash Rule Indicates the hash algorithm used to generate the hash.
X 00 : MDC-2 algorithm with 128-bit hash x ~ al ~ MDC-4 algorithm with 128-bit hash X 02 : MD4 algorithm with 128-bit hash X 03 - X FF : reserved.
3 17 Reserved (=17 X 00 ) 16 MDC - A 128-bit MDC calculated on a CFER in the CF by an ECFER instruction. The MDC is calculated using the MDC-2 hash algorithm.
36 16 Key - This field contains a 128-bit odd parity adjusted key generated within the CF by the ECFER instruction "lhich may be Exclusive ORed with KM, KMP, or both (depending on KMP-mode and KM-mode specified in ECFER).

Reeord Forma~s and D~scriptions ~0 Brs-sl-ols Cr~pto F;lcilit~ S~tem Sign~tllre Record Crypto F~cility System Sign~tllre Record (CFSSR) 2~rlS329 T he Crypto Facility System Signature Record is produced by one of the following instructions:
ECFAR, EPUK, GKSP, GDS, and ECFER. The CFSSR can be processcd by one or more of the fol-lowing instructions: IPUK, IDK, VDS, and ICFER. The CFSSR is a 253-bit record.
A Crypto Facility System SiDnature Record has the following forrn:

Offset Length Data (in bits) 0 4 Reserved (=B OOOO ) 4 1 Emulation B 1 : CFSSR created via the GDS instruction B a~ CFSSR created via the instruction specified in the first nibble of Record Code field.
8 Record ID (=B 0000 0010 for CFSSR) 13 16 Record Length (in bits) The record length is currently fixed at 253 bits (=X OOFD ) 29 8 Record Code The first nibble indicates the CF instruction, and the second nibble indicates the key type of the private key used to generate the signature.
First nibble: Second nibble:
_ 3 3a31 - EPUK B loal~ - PRM
B ~1a - GKSP B 1013 - PRA

B 01aO - GDS B Oxxx - reserved B 0101 - reserved B 11xx - reserved B 011x - reserved B 1xxx - reserved 37 8 Hash Rule Indicates the hash algorithm used to generate the hashj and the rule (if any) for formatting and producing, from the generated hash value, the value to be stored in the Hash field.
X 00 : MDC-2 algorithm with 128-bit hash X 01 : ~lDC-4 algorithm with 128-bit hash X 02 : ~lD4 algorithm with 128-bit hash X 03 - X FF : reserved.
2~8 Hash field The field in which the hash value is stored--right justified, and filled with higher order zero bits.

Record Formats and Descriplions ~1 BT9-91-015 Cr~pto F~ility En\ironment Record 207532~
Crypto Facility Environment Record (CFER) The Crypto F~cility Environment Record (CEER) contains that portion of a CF Environment neces-sary to clone a de-ice (i.e. by replicating the CF Environment of one device into another device).
The Crypto Facility Environment Reeord has the follo-~ ing form:

Offset Length Data (in bytes) ~3 64 Header (H) 64 a Secret Part (SP) 64+a b Nonsecret Part (NSP) Data l)escription -~Icadcr The IIeader (Il) contains information necessary to parse the CFER. I-I has a fi~ed Icngth of 6~ b~,tes.
Seeret l':ut I he Secret l'art (SI') contains the secret p~rt of the CF Environrnent to be ported. SI' is variable length, but a multiple of 8 bytes.
~onsecret l': rt The ~onsecret Part (~TSI') contains O!~.'LY T II~T I'ART or TrlE ~oNsr cRr r l~RT OE TIIE cr- E~VlRO~ lE~rT to be ported. ~'SP is variable lenDth but con-tains a whole number of b~tes.
The I Icadcr has the following form:
Offset Length Data (in bytes) ~3 64 Header 31 Record ID (=B'~G~0~11') ~1 03 Reserved (=3 X'O~') 04 04 Length of Secret Part in 8-byte blocks; (112+a+b)/8 Value is coded in binary representation.
38 ~4 Length of Secret Part of Product Environment in bytes ("a"). Value is coded in binary representation.
12 ~3 Reserved (=3 X'~O') ~1 Length of Random Pad for Secret Part in bytes ("b").
Value is coded in binary representation.
16 34 Length of Nonsecret Part in bytes; (568+d+e).
Value is coded in binary representation.
2~ ~2 Reserved (=2 X'O~') 22 ~2 reserved (=2 X'90') 24 ~4 Length of Nonsecret Part of Product Environment in bytes ("e"). Value is coded in binary representation.
2a 36 Reserved (=36 X'33') 64 ~ End of Header Record Forma~s and DescripLions -12 I~T9-91-OlS Crypto F.lcilit~ Envir()nlllent Record The Sccrct Part has the following forrn: 2 0 ~ -j 3 2 9 64 112+c Secret Part 64 112 Registers 64 16 CKM Register (Current DEA-key-encrypting Master key) 16 OKM Register (Old DEA-key-encrypting Master key) 96 8 PRNGCTR1 Register (Pseudo-Random Number Counter #1) 134 8 PRNGCTR2 Register (Pseudo-Random Number Counter #2) 112 16 PRNGKEY1 Register (Pseudo-Random Number Seed Key #1) 128 16 PRNGKEY2 Register (Pseudo-Ransom Number Seed Key #2) 144 16 CKMP Register (Current PKA-key-encrypting Master key) 16~ 16 OKMP Register (Old PKA-key-encrypting Master key) 176 O End of Registers 176 a Secret Part of Product Environment The product environment contains information specific to a product implementation (beyond that called for by the the PKCD).
176+a b Random Pad The Random Pad field contains "b" randomly generated pad bytes, where "b~' is a number from O to 7. The random pad field is adjusted so that the length of the Secret Part is guaranteed to be a multiple of 8 bytes.
176+c û End of Secret Part (where c = a+b) Record Form.~ts ~nd l)cscriptions 13 BT9-91-015 Cr~pto F~eilit~ En~irolllllent Rccord The ;\Tonsecret Part has the following forrn 2 ~ 7 ~ 3 2 9 176+c 488+f Nonsecret Part 176+c 64 Configuration Vector 240+c 64 State Vector The following flags are reset to reflect that the corresponding registers do not port:
KP FLAG := B'O' NKM FLAG := B' oa PIN FLAG := B'O' KMP FLAG(2) := B'30' 334+c 80 Registers 334tc 16 PROGMOCG Register (Secure Loadable Program MDC #O) 320+c 16 PROGMOC1 Register (Secure Loadable Program MDC ~1) 336+c 16 EID Register (Environment Identifier) 352+c 16 PUACV Register (Public Device Authentication key CV) 368+c 16 PRACV Register (Private Device Authentication key CV) 384+c ~ End of Registers 384+c 272 MDC Table 656+c 3 Counter Table 659+c 5 Reserved (=X'OOOOOOOOOO') Keeps remaining fields on an 8 byte boundary.
.* The next line is changed from PIN Tables to reserved 664+c d reserved 664+c+d e Nonsecret Part of Product Environment The product environment contains information specific to a product implementation (beyond that called for by the PKCD).
664+c+f 3 End of Nonsecret Part (where f = d+e) 664+c+f O End of CFER

Outside the CF, the Secret Portion of the CFER is encrypted with a 12~ bit DE~ ~;ey li~l lil~l is ~encrated within the CF and encrypted ~vith a public de-ice authentication key l'UA I'he ~onsecret Portion of the CFER is specifically not encrypted to prevent a covert privacy ch~nnel from heillg set ~Ip when the CFER is used with the ECFER and ICFER instructions Rccord Form~ts ~nd l~cscriptions ~1 13T9-91-015 Cr~pto F.lcilit~ En-irol~ ellt R~eol-d E~tern~l Crypto F~cility Environment Record (XCFER) 2 0 7 5 3 2 9 The E.cternal Crypto Facility Environment Record (~CFER) is the same as the CFER c~;pect that the Secret Part is encrypted.
The E~cternal Crypto Eacility Environment Record has the following form:
Offset Length Data (in bytes) 64 Header (H) 64 a Encrypted Secret Part (ESP) 64ra b Nonsecret Part (NSP) I);lt:l I)cscription lIcadcr Thc I-Ieader (II) contains information necessary to parse the CFER. II has a fi~ced lell_th of 6~ bytes.
~'ncr~ptc(l S~crct l'art The Encrypted Sccret Part (ESI') contains the secret part of the CF Environment to be ported cncrypted under a key shared with, or to-be-shared with, a ~1e~i~n.~ted recei~
device. The length of ESI' equals the length of SP. SP is variable length, but a multiple of 8 bytes.
~'onsccrct l';lrt 'I'he l\'onsecret I'art (~'Sr) contains the nonsecret p.~rt of the CF Environment to be ported. i~SI' is variable length, but a ~ hole number of bytes.

Record Formats,~nd Dcscrip~ions ~:~

B'r9-9 1-015 Cr~ pto F~eilit~ Audit Rec()r~l 207-~329 Crypto F~cility Audit Record (CFAR) The Crypto Facility ~udit Record (CFAR) contains the nonsecret part of the Cl Environment plus additional nonsecret information. The CF~R is designed to be a multiple of 8 bytes.
The Crypto Facility ~udit Reeord has the following form:

Offset Length Data (in bytes) ~ 64 Header (H) 64 a Nonsecret Part (NSP) Data l)escription He.lder The l-leader (ll) contains information necessary to parse the CFAR. It also contains a random number (R~') field and a date and time (DT) field. The lleader is 64 bytes in length.
~'onsecr~t l'.ut The ~'onsccret Part (~'SI') contains the nonsecret part of the CF Environment. ~'SI' is variable length, but must be a whole number of bytes. The ~\'SP in the CF.L~R is not the same as the i~SP in the CFER (see Crypto Facility Environment Record).
The lleaclcr has the following form:
Offset Length Data (in bytes) ~ 64 Header 33 ~1 Record ID (=B'a3~a1~a') ~1 33 Reserved (=3 X'~
~4 ~4 Length of Nonsecret Part of CF Environment in bytes;
(523+a+b+d). Value is coded in binary representation ~8 ~2 Reserved (=2 X'O~') 13 32 Length of cfpkrl containing PUA (~'a") in bytes.
Value is coded in binary representation 12 ~2 Reserved (=2 X'O~') .* Next line is changed from PIN-table-length to reserved 14 ~2 reserved (=2 X'~
16 ~4 Length of Nonsecret Part of Product Environment ("d") in bytes. Value is coded in binary representation.
2~ 34 Reserved (=4 X'~3') 24 ~8 RN field 32 ~3 Reserved (=3 X'~
14 D~ field 49 15 Reserved (=15 X'~a') 64 3~ End of Header l)~t~ scriptioll R.~ n 8 byte CF~P-supplied time-variant parameter. This tield is set by the ECr'~R
instruction only ~hen process-mode= 1 or process-modc= ~. This fielcl is intenclecl to be usecl as a nonee in a request/response protoeol to guaralltee freshness of the .~udit rccorcl.
'l'he Certification Center generates and random number ancl sends it to the cle-ice to be auditcd in the Request-for-~udit message. The deviec then supplies this r~ndom numbcr to the E.~port Cryptographie Facility Audit Record instruction. This results in the signcd .~udit record bcing sent to the Certification Center by the .~uditecd clevice ~ith the corrcct nonce. 'rhe Certifieation Center is assured that the ~udit record is current.

Rccord Formats and Dcscrip~ions ~6 1319-91-OI5 Cr~pto F;lcility Audit Recor(J
207~29 DT ~ 14 character ficld with forrnat YYYY~I~fDDlll~ lSS containinp, the date and Coor-dinatcd Universal Time ([,'TC). Ihe characters are decirnal (0 thru 9) and are encoded using 8-bit ~SC11 rcprcsentation. A value of 14 'O's denotes that DT is uninitialized.
The ~onsccret Part has the following form:
64 52C+e Nonsecret Part of CF Environment 64 64 Configuration Vector 128 64 State Vector 192 112 Registers 192 16 PROGMDCC Register 2C8 16 PROGMDC1 Register 224 16 POS Register 24C 16 DID Register 256 16 EID Register 272 16 PUACV Register 288 16 PRACV Register 304 C End of Registers 3C4 272 MDC Table 576 3 Counter Table 579 5 Reserved (=5 x'~a ~ ) Keeps remaining fields on an 8 byte boundary.
584 a cfpkrl from the PUA Buffer .* Next line is changed from PIN Tables to reserved.
584+a b reserved 584+c ~ GKSP Save (not audited) 584+c C GKSP Buffer Length (not audited) 584+c 3 GKSP Record Length (not audited) 584+c C GKSP Buffer Flag (not audited) 584+c ~ GKSP Ticket (not audited) 584+c C IDK Save (not audited) 584+c C IDK Buffer Length (not audited) 584+c C IDK Record Length (not audited) 584+c 3 IDK Buffer Flag (not audited) 584+c G IDK Ticket (not audited) 584+c d Nonsecret Part of Product Environment (where c = a+b) The product environment contains information specific to a product implementation (beyond that called for by the PKCD).
584+e C End of Nonsecret Part of CF Environment (where e = c+d) 584+e ~ End of CFAR
~ o cncryptcd information in the CFER ever appears in the elear in the CF~R. Speci~lcally, this is done to prevent a covert privacy channel from being set up when the CFER is used ~vith the ECFER and ICFER instructions.

Record ~ormats and Descriptions ~7 BT9-9 1-015 I ntern~ e~ Unit 2075~29 Intern~l Key Unit (IKU) The IKU is an internal form of a Key Unit. The Key Unit contains an encryptcd C~l'KR, an encrypted CFKAR, and information about the public or private key in the CFPKR. Thc IKU is designed to be a multiple of 8 bytes.
The Internal Key Unit has the following form:
Offset Length Oata (i n bytes) ~û 32 Header (H) 32 a System Control B1 ock (SCB) ~2+a b User Control Bl ock (UCB) 32+c d Encrypted Crypto Faci 1 i ty PKA Key Record (ECFPKR), c=a+b 32+e f Encrypted Crypto Facility Key Authenticator Record, e=c+d (ECFKAR) D~ta Dcscription Hcadcr The ÇIeader (Çl) contains inforrnation necessary to parse the IKU.
~ystcm Contro1 Block The Systcm Control Block (SCB) contains information about the liey in CFI'KR, including a control vector Cl. The SCB is managed by the system. The SCB is designed to be a multiple of 8 bytes.
~scr Control BlOck The l 'ser Control Block (UCB) contains information about the key in CFPKR. The UCB is specified by the user (or installation). The IJ'CB must be a multiple of 8 b~tes.
~,ncryptcd Crypto Facility l'KA Key Record 'I'he Encryptecl Crypto l~acility YK~ Key Record (ECÇ I'KR) contains a Cl' l'KR
cncrypted under a key K.~IP.C2 formed as the Exclusive OR product of K~IP and a control vector C2. C2 is generated from SCB and UCB using the method discussed in steps 501 and 502 of the Key Record Encrypt Algorithm 12 in Fig. 16. Thc CÇ l'ICR
contains a public or private key.
~ncryptc(l Crypto Facility Kcy Authcnticator Rccord The Encrypted Crypto Facility Key Authenticator Record (ECFK~R) contains a CFK~R encrypted under a key K;\~IP.C3 formed as the Exclusive OR product of K~,IY
and a control vcctor C3. C3 is generated from SCB and UCB using the mcthod dcscribcd in steps 501 and 502 of the Key Record Encrypt Algorithm 12 in Ç ig. 16.

Rccord Form3ts ~nd Dcscrip~ions ~8 13T9-91-015 Intern~ e~ Unit 207 i329 The llcadcr has the follo~ing forrn:

Offset Length Data (in bytes) 00 3Z Header (H) 32 Anti-ISO field (=X'8083') The anti-ISO field is a 2-byte field purposely encoded to be invalid as the leading 2 bytes of a data record conforming to 'Basic Encoding Rules of ASN.1(IS0 8825)'.
02 01 Record ID (=B'~0030101') 33 ~3 (=3 X'O~') 06 02 SCB-Length - number of 8 byte blocks in SCB.
Value is coded in binary representation SCB-Length must be ~ O
~8 ~2 (=2 X~
13 02 UCB-Length - number of 8 byte blocks in UCB.
Value is coded in binary representation UCB-Length must be ~=
12 ~2 (=2 X~
14 ~2 ECFPKR-Length - number of 8 byte blocks in ECFPKR.
Value is coded in binary representation ECFPKR-Length must be ~ O
16 ~2 (=2 X'~O') 18 C2 ECFKAR-Length - number of 8 byte blocks in ECFKAR.
Value is coded in binary representation ECFKAR-Length must be ~ O
23 12 (=12 X~
32 ~ End of Header (H) Thc System Control Block has the following forrn:
Offset Length Data (in bytes) 32 a System Control Block (SCB) 32 16 Control Vector 48 16 EID - Environment ID
64 2 Reserved (set to zero) 66 14 Tstart 2 Reserved (set to zero) 82 14 Texp 96 4 Reserved (set to zero) 1CC 4 Seq 1C4 64 LDID - Logical Device Identifier 168 64 LKN - Local Key Name 232 64 UID - User Identifier 296 b Optional CFAP fields 296+b C End of System Control Block (SCB) I)~t:l I)cscription ~ontrol ~'cctor .~ 128 bit control vector associ~te ~vith the public or private l~cy storc(l in the Cl~l'KI~.
Ihe control ~ector is a CF enforced f~eld. ~Ihe control ~ector is ~ required fiel(l in the SCB.

Record Form~s ;~nd r)escripLions ~9 l3rr9-9l-ols 7 5 3 2 ~nt~rn~tl ~e~ Unit EID A 16 byte Environmcnt ID of the crypto facility wherc IKU is crcatcd. EID is a CF
cnforced ficld (i.e., the CF verifies that EID cquals the valuc storcd in thc EID register of the CF whcn a kcy is created and, as appropriate, verifics that EID is cqual or not equal to the value in the FJID register when an IKU is processed). ~\'ote that EID may exist in multiplc physical dcvices, dcpending on the number of "cloncd" CF Environmcnts ac~ive at any onc time. EID is a required field in the SCB.
Tst~rt A l~ character field with forrnat YYYY~ /IDD~IlI.~l.~,ISS containing the date and Coor-dinated l_niversal Time (UTC) when the IKU becomcs active. The ch tractcrs in Tstart are decimal (0 thru 9) and are encoded using 8-bit ASCII representation. ~'start is a CF
enforced field (i.e., the IKU cannot be processed unlcss 'I'start has passcd). ~ valuc of l~
ASCII 'O's denotes that Tstart is ignored. Tstart is a re4uired t;eld in tl1e SCI3.
Tcxp A l~ character ficld with forrnat YYYYl~I;\IDDI~ ISS containing thc datc and Coor-dinated Universal Time (U'l'C) when the IKU expires. The charactcrs in TCYP are decimal (0 thru 9) and are encoded using 8-bit ASCII representation. 'I'eYp is a CF
enforced field (i.e., the IKU cannot be processed when TeYp has passcd). ,~ value of l~
ASCII '9's denotes that Texp is ignored. Texp is a rcquired field in the SCB.
Scq A d, byte sequence number. Seq is not a CF enforced ticld. 'I he scq ticld may be used bv CFAP to record the rclative scquence of IKU in a chain starting ~vith a "root" IKU. Scq is an optional field in the SCB.
Ll)ID Logical Device Identifier (LDID) is the identificr of the logical, as opposcd to physic31, dc~ice to which IKU belongs. LDID is not a CF enforccd ficld. LDID consists of l or more narne elements x; scparated by periods (i.e., xl, X2, x3 is storcd as xl.Y2..Y3). Each name element Xj is I to 8 characters and is encoded in ~-bit ASCII rcprcscIltatioll. (~\'ote that LDlD is the network equivalent of EID.) LDID is an optional f;eld in the SCB.
LK~' Local Key ~'ame (LKNT) is the name or local name of the key in IKU and is assigned by the '10gical" device to which IKU belongs. LK~ is not a Cl~ enforccd ficld. LK~' con-sists of l or more name elements xi separated by periods (i.e."Yl~ ,Y2, x3 is stored as xl.x2..x3). Each name element x; is l to 8 characters and is encodcd in S-bit ASCII repre-sentation. LDID.LKIY and UID.LK~T constitute global kcy namcs that uIliquely idcntify a key. LK?~ is an optional field in the SCB.
UID User Identifier (UID) is the identifier of the user to which IKU bclongs. UlD is not a Cl~
enforced field. UID consists of l or more name elements Xj separatcd by pcriods (i.e., xl, Y2, x3 is stored as xl.x2.x3). Each name elcment x; is I to 8 characters aIld is encodcd in 8-bit ASCII representation. UID is an optional field in thc SCB.

Rccord Forrn.~ts ~nd I)cscriptions 50 BT9-91-015 C~ r l~e~ Unit 207~532~
Clear Key Unit (CKU) The CKU is a clear forrn of an Internal Key Ur~it. I'he ~ey Unit eontains a clear CI I'KR and a clear CFK~R. The CKU is designed to be a multiple of 8 bytcs.
The Clear Key l,rnit has the following forrn:
Offset Length Data (i n bytes) 00 32 Header (H) 32 a System Control Block (SCB) 32+a b User Control Bl ock (UCB) 32+c d Crypto faci l i ty PKA Key Record (CFPKR), c=a+b 32+e f Crypto Facility Key Authenticator Record (CFKAR), e=c+d D:lta l)escription llc~dcr The IIeader (II) eontains inforrn~tion neeessary to parse the CKI,T. See below.
~ystem Control Block The System Control Bloek (SCB) eontains inforrnation about the key in CFI'KR, including a control ~~ector Cl. The SCB is managed by the system. The SCB is desi(Tned to be a multiple of 8 bytes. ( I'he SCB forrn in the CKU is the same as in the IKI .) ~~ser Control l~loek The ~'ser Control Bloek (UCB) eontains inforrnation about the key in CI I'KR. The l,TCB is speeified by the user (or installation). The UCB must be a multiple of ~ b~tes.
(The UCB form in the CKU is the sarne as in the IKU.) ~r~pto Facility PE;.~ Key Record The Crypto Facility PKA Key Reeord (CFPKR) eontains a public or pri~.lte key.
~rypto l :lcility Kcy Authcntic~tor Rccor(l The Crypto Faeility Key Authentieator Reeord (CFKAR) is used by the C~ to ~ralidatc the CFPKR.
The I-Ieader has the following forrn:
Offset Length Data (i n bytes) ûû 32 Header (H) û~ û2 An t i - I SO f i e l d (=X ' 8080 ' ) The anti-ISO field is a 2-byte field purposely encoded to be invalid as the leading 2 bytes of a data record conforming to 'Basic Encoding Rules of ASN.1(IS0 8825) '.
02 01 Record ID (=B'0000311û') 03 03 Reserved (=3 X'OO') û6 û2 SCB-Length - number of 8 byte blocks in SCB.
Value is coded in binary representation.
SCB-Length must be > O
08 û2 Reserved (=2 X ' 33 ' ) lû û2 UCB-Length - number of 8 byte blocks in UCB.
Val ue i s coded i n bi nary representati on .
UCB-Length must be ~= O
12 û2 Reserved (=2 X ' oa ~ ) 14 û2 CFPKR-Length - number of 8 byte bl ocks i n CFPKR.

Rccord FormaLs and l~cscrir~Lions ~1 13T9-91-015 2 0~ ~32~ Cle~r ~e~ Ullit Value is coded in binary represéntation CFPKR-Length must be ~ C
16 32 reserved (=2 X'00') 18 C2 CFKAR-Length - number of 8 byte blocks in CFKAR.
Value is coded in binary representation.
CFKAR-Length must be ~ C
23 12 Reserved (=12 X'CC') 32 ~ End of Header (H) ~'ote: The specification for System Control Block, User Control Block, Crypto Facility PKt~ Key Rccord~
and Crypto Facility Key ~uthenticator Record are the same as those for the IKU.

Rccord Formats and DcscripLions ~2 l3r9-9l-ols ~o7 ~329 E~;tcrnal ~ IJnit E~tern~l Key Unit (EKU) 'I'he EKU is an extemal form of a Key Unit. The Key l,'nit contains a clear Cl:I'KR and infonn;ltion about the public or pnvate key in the CFPKR. The EKU has no cncryptcd or clear CFKAR. Thc l-KI ' is designed to be a multiple of ~ bytes.
The E.~cternal Key Unit has the following form:
Offset Length Oata (in bytes) 32 Header (H) 32 a System Control Block (SCB) 32+a b User Control Block (UCB) 32+c d Crypto Facility PKA Key Record (CFPKR), c=a+b l)~t~ l)eseription H~ ler The lleader (~1) contains inforrnation necessary to parse the EKU.
~ystem Control 131oek 'I'he System Control Block (SCB) contains information about the key in Cl l'KR, including a control vector Cl. The SCB is managed by the system. The SCB is desi~ d to be a multiple of 8 bytes. (The SCB form in the EKU is the same as in the IKI,'.) ~'s~r Control I~lock The User Control Block (liCB) contains inforrnation about the key in C~l'KR. 'l'he I'CB is specified by the user (or installation). The UCB must be a multiplc of S b~lcs.
(The UCB form in the ~KU is the same as in the IKU.) ~rypto F;lcility rKA ~ey Rccord The Crypto Facility PKA Key Record (CFPKR) contains a public or pri-ate l;cy, although ordinarily only publie keys occur in an EKU.
The lIeader has the follo~ving form:
Offset Length Data (in bytes) 33 32 Header (H) 00 02 Anti-lSO field (=X'8a80') The anti-lSO field is a 2-byte field purposely encoded to be invalid as the leading 2 bytes of a data record conforming to 'Basic Encoding Rules of ASN.1(IS0 8825)'.
02 01 Record ID (=B'00003111') 33 33 Reserved (=3 X'33') C6 02 SCB-Length - number of 8 byte blocks in SCB.
Value is coded in binary representation.
SCB-Length must be ~ O
38 02 Reserved (=2 X'CO') 02 UCB-Length - number of 8 byte blocks in UCB.
Value is coded in binary representation.
UCB-Length must be ~= O
12 02 Reserved (=2 X'OO') 14 02 CFPKR-Length - number of 8 byte blocks in CFPKR.
Value is coded in binary representation.
CFPKR-Length must be ~ 3 16 02 reser~Jed (=2 X'03') 18 ~2 Constant (=2 X'~C') 2~ 12 (=12 X~

Rccord Formats and l)c~cripLion~ ~3 13-1'9-91-015 E,~t~rnal 1~ Unit 207 i329 32 0 End of Header (H) ~otc: The spccification for Systcm Control Block, Uscr Control Block, and Crypto ~acility PK~ Kcy Rccord Rccord are thc sarne as thosc for the IKU.

Record Formats and Dc~cripLion~

r3-rs-sl-015 2 0 7 -~ 3 2 ~ Sliel~ton ~e~ unit Skeleton Key Unit (SKU) The SKU is a partially completed Key l~nit. The SKU is designed to be a multiple of 8 bytes.
The Skeleton Key Unit has the following form:

Offset Length Data (in bytes) C3 32 Header (H) 32 a System Control Block (SCB) 32+a b User Control Block (UCB) D~t~ Dcscription lIe~der The ~leader (Il) contains information necessary to parse the SKU.
~~stem Control Block The System Control Block (SCB) contains information about the key in Cl~l'KR, inclu(ling a control vector Cl. The SCB is managed by the system. The SCB is designed to be a multiple of 8 bytes. The SCB format is the same as that for the IKU.
~,ser Control 131ock The User Control Block (UCB) cont;lins information about the key in Cl:l'liR. Thc UCB is specified by the user (or installation). The UCB is an optional field in the SKI,.
The l,'CB must be a multiple of 8 bytes.
The I leader has the follo-ving form:
Offset Length Data (in bytes) CC 32 Header (H) ~ ~2 (=X'8~8~') C2 ~4 (=4 X~
36 02 SCC-Length - number of 8 byte blocks in SCB.
Value is coded in binary representation.
SCB-Length must be ~ O
~8 ~2 (=2 X~
02 UCB-Length - number of 8 byte blocks in UCB.
Value is coded in binary representation.
UCB-Length must be ~= O i-12 ~2 (=2 X~
14 02 Constant (=2 X'Ca') 16 ~2 (=2 X~
18 ~2 Constant (=2 X'OO') 2~ 12 (=12 X'3~) 32 3 End of Header (H) .~ote~ e spccification for System Control Block and l~ser Control l310ck are the salne as those for the IK[, .

Record l~orm~ts ~nd l)escriptions 55 ~3r9-91-015 An O~r~ie~ of PI~CD l~e~ T~pes 20~ ''i32~
Control Vector Forrnats and Descriptions An Overview of PKCD Key Types Fig. 30 illustrates the l'KCD control vector hierarchy, Each PKCD control vector has a CV TYI'E
field consisting of a main-type and a sub-type. The main-type portion of the CV TYPE field permits broad classes of keys and cryptov~riables to be dcfined, ~vhcreas the sub-type portion of the CV TYPE field permits gcneric key types to be dcflned within each class, which are morc closely associated with the func-tional use of the key or cryptovariable. The lefthand portion of Fig. 30 illustrates the control vector main-typcs dcfincd by PKCD. The righthand portion of ~ig. 30 illustrates the control vector sub-types defincd for each main-type. ~Vhen no sub-type distinction is made, the key or cryptovariable is generally refcrred to by its main-typc.
The PKCD namcs ascribed to keys are dctcrmined by a conc~ten~tion of the narnes associated ~ith main-type and sub-type. The following keys are dcfined by PKCD:
~ I'ublic Authentication Key ~ I'ublic Ccrtific~tion Kcy ~ Public Key .~/Ianagement Key ~ Public User Key ~ Private ~uthentication Key ~ Private Certification Key ~ Private Key .~Ianagement Key ~ I'rivate User Key Gener~l form.lt for PKA control vectors The fields defined for one or more control vectors are these:

ALGORITHM GKSP LENGTH
ALGORITHM EXTENSION HIST-CHAIN PARITY
ANTIVARIANT ONE HIST-DOMAIN ID PR USAGE
ANTIVARIANT ZERO HIST-IPRK PU USAGE
CV TYPE HIST-IPUK RTNKMP/RTCKMP
DOMAIN ID HIST-KREGMODE SOFTl~lARE
ECFAR HIST-MDC TESTZERO
ECFER ICFER THRES-MDC
EPUK IDK VAL/VAL AUTHENTICATOR
EXTENSION INSTALLATION
GADS IPUK
GDS KREGMODE

dcfinition of the control ~ector ficlds is providcd below in alphabctical ordcr:

Control ~'cctor Formats and Dcscriptions 56 BT9-91-015 An OYervie~ of Pl~CD ~e~ TJpes 2D7 ~329 ALGORITII.~I <4 bits>
This field eontains an algorithm unique code word whieh permits the Cl; to distinguish keys associated with one l'KA from another. (The architeeture permits the CF to implement multiple PKAs.) Eaeh different PKA is assigned a different eode word. The ALGORITII:\I
field is eheeked before a key is used by the PKA thus preventing keys assoeiated ~vith one l'KA
to be used with another PKA. The eoding of this field is as follows:
~ B'0000': RSA IUgorithm (modulus size from 512 to 2048 bits) ~ B'000 1'- B' I I I I ': reserved ~LGORITII.~I E~TE~'SIO~' <3 bits>
This field is an e~tension of the ~.LGORIl'll.~l field and the coding is depelldent on the value of the ALGORITH;U field.
For ALGORITH~I field = B'0000' the eoding of the ALGORI'rl-l.~I E.~ 'SIO\' fieldis as follows:
~ B'000': ~'o restrictions ~ B'00 1': Publie key e.Yponent is 3 ~ B'010': Publie key exponent is 2~16+1 ~ B'0 1 1'- B' I I I ': reserved ~'Tn'~RIA~'T O~'E < I bit >
This field is a fixed value of B'l'.
A~'TIVARIA~'T ZERO < I bit >
This f1eld is a fixed value of B'0'.
CV TYPE ' 7 bits >
This field indicates the type of the eontrol veetor whieh is also the }iey type of thc l;c~ ith which this control vector is associated. The following key types are def ned for l'E~.~ l;eys:
1. B'l 1 10010': Public Authentieation Key 2. B'l 111010': Private Authentieation Key 3. B'1110000': Publie Certification Key 4. B' I 1 1 1000': Private Certifieation Key 5. B ' I 1 10001': Public Key l~lanagement Key 6. B' 1 1 1 1001': Private Key ,~ ~anagement Key 7. B' 1 1 10011': I'ublic User Key 8. B'l 111011': I'rivate User Key ~ 'ote that the value of the first three bits of the CV TYI'~ field of l'K.-~ control ~ectors .Ire al-vays B' 111 ' as opposed to other values for Dl .~ control vectors.
I)O.~ < ~ bits >

'I'his field contains a domain identifier (an arbitrary value from B'0000' to 13'1 11 1' assi ~ned by an install;ltion). The domain ID field of all publie and pri~ate l;eys used ~-ithin a cryptographic instruction must be equal.

Control ~,'ector Formats ~nd Dcscrip~ions 57 ~0~5329 ECFAR < 1 BIT>
This ficld in(licates whether a private lcey PR can be used in an ECFAR instructioll to generate a digital signature on a ClAR:
o B'0': cannot o B' 1 ': can ECFF,R < I BIT>
In a PRA control vector, this field indicatcs whetller a PR~ lccy can be used in tlle ECFF,R
instnlction to generate a digital signatllre on an X(:'I ER. In a PUA control vector, this field indicates whetller a I'UA key can be used to encrypt a Crypto Iacility Backup DF:~A ICey Block ((:'FBDICB).
o B'0': cann-)t o B' 1 ': can EPUIC < 1 BIT>
Tllis ficld in(licates wllet}ler a private key can be llsed in an EPUIC instrtlctioll to generate a digital signattlrc on an outplltExternal ICey Unit (EICU).
o B'0': canllot o B' 1 ': can EXTI,NSION <2 BITS>
Tllis field indicates wl~ether the colltrol vector is a 64bit, 128bit, or >128bit control vector. In PICCD, all control vectors are > 128bit control vectors.
o B'0()!: 64 bit control vector base o B'01': the control vector is a 128bit control vector o B'10': the control vector is a > 128bit control vector o B' I I ': reserved GAOS <I BIT>
This field indicates whetl1er a privatc key (PRC, PRM or PRU) can be used in a G~I:)S instrtlction to generate a digital si~natnre.
o B'0': canllot o B' I ': can GI)S < I BIT>
This field indicates whetller a private key (PRA, PRC, PRM or PRU) can be used in a GDS
instrllctioll to generate a digital signature.
o B'0': cannot o B' 1 ': ca Gl<SP <1 BIT>
Tllis fiekl indicates whetller a key (PRM or PUM) can be llsed in a GI~SP instrtlcti-)ll.
o B'(:)': canllot IT,r9-91-015 An O~rvie-. of PI~CD Key T~pes I~IST-CIIAI~T < 2 bits > 2 ~ 7 .) 3 2 9 This field indicates a chain of history of how a public key has been importcd in the IPI,'K
instnuction:
~ B'00' other (i e, not B'01', B'l0', or B'l 1') ~ B'01' conditions stated in (a) or (b) must be true - (a) PU in EKU 1 is a PUC and is imported via import-mode = 0;
-- (b) PU in EKUI is a PUC and is imported via import-mode= I; PU in IKU2 is a l'I,'C
with ~IIST-IPUK= I and IIIST-C~IAI~'= I; PU in EKUI and PU in IKU2 have same DOl\~IAI?~T ID
~ B'10' conclitions stated in (c) or (d) must be true - (c) PU in EKUl is a PUi~/I and is imported via irnport-mode= I; PU in IKU2 is a l'I_C
with HIST-IPUK= 1 and IIIST-CIIAI~'= l; PU in EKUl and PU in IKIJ I ha~e same DO~fAI~ ID
- (d) PU in EKUl is a PUA and is irnported viaimport-mode= I; I'U in IKU2 is a l'I_'C
with IIIST-IPUK= I and IIIST-C~IAIN= 1 ~ B'l 1' conditions stated in (e) must be true -- (e) PU in EKUI is a l'UA with IIIST-IPUK= 0 and is importcd via import-modc= 1;
I'U in IKU2 is a l'Ui~f with IIIS'I'-II'UK= I and IIIS'r-CllAI.\I= 2 i~'ote this field is valid only when HIST-IPUK = B'l' HIST-DO~I~' ID < 41 bits >
I IIST-DO~IAI~T ID is a f~eld in a PUA control vector used to record the value of DO~IAII~' ID in a PUC or PU~f control vector A domain identifier is an arbitrary value from B'0000' to B'l l l l' PUA is a key in an EKU imported with IPUK and PU.~f or PUC is a key used to validate the digital signature previously generated on the to-be-imported EKU at the sendinp device ~'ote this field is valid only when HIST-IPUK = B'l' and either IIIST-CE-IAI~' = B'10' or IIIST-CIIAI~T = B'll' HIST-IPRI~ < I bits>
This field indicates whether a private user key has been imported ~ia the II'RK instruction, as follows ~ B'0' not imported via IPRK
~ B'I' irnported via IPRK
I-IIS'r-ll'l,'K ~ I bits>
This fielcl indicates whether a public key (I'UA, Pl,'C, I'l,'\,l, or 1'[,'~) h;3s bccn impoltcd Vi,l the II'[,'K instruction, as follows ~ 13'0' not imported ~ia IPI,'K
~ 13'1' importecl via IPUK
~'ote the IllST-~IDC and IIIST-CIIAI~r fields in the control ~ector are ~alid only whcn IIIS~ II'UK in the control vector = B'l' ~IIST-KREG~,IODL~ is ~alicl only when IllS'I'-IPI,K=B'l'and IIIS'l''-CII,~ '=B'II' Control ~'cclor Formats and Dcscriptions :~9 13T9-91-olS An O~er~ie~ of P~(~D E~e~ T~pes ~IIST-KREG~IODE < 2 bits > 2 0 7 ~ 3 2 9 IIIST-KREG.\~IODE is a field in a PUA control vector used to rccord thc value ofKREG:\~IODE in a PU.~I control vector. See also KREG,\,IODE. I'UA is a key in an EKU
imported with IPUK and PU~I is a key used to validate the digital signature pre-iously gcner-atcd on the to-be-imported EKU at the sending device.
~ 13'00': KREG;.\ifODE= B'00' in PU~
~ B'01': KREG~IODE= B'01' in PU~i ~ B' 10': KREGi\IODE = B' 10' in PU.~f ~ B' l l': reserved ~otc: this field is valid only when IIIST-IPUK = B' I' and l-IIST-CI l,~l~T = B' l l'.
HIST-.~IDC < ~ bits >
This field records IPUK information about a root PU in a chain, as follows:
~ B'00': rcserved ~ B'01': root l'U was imported in II'UK using .~lDC-mode= 0 (i.e., no .~IL)C) ~ B'10': root PU was imported in IPU~ using i\~lDC-mode= l (i.e, with ~IDC) such that EKU~IDC FLAG = B' l0'.
~ B'l l': root PU was importcd in IPUK using ;~fDC-mode= I (i.e., with .~ilDC) such th3t EKU.~IDC FL~G= B'l l'.
~otc: this field is valid only when IIIST-IPUK = B'l'.
ICFER < I bit >
In a PUA control vector, this field indicates whether a PUA key can be used in the ICFER
instruction to validate a digital si,gnature on an ~CFER. In a PR~ control ~ector, this field indicates whcthcr a PRA key can be used to decrypt an encryptcd CF13DKB.
~ B'0': cannot ~ B' 1' : can II)K < I bit ~
This ficld indicates whether a kcy (PR.~I or PU.\~I) can be uscd in an IDE~ instruction.
~ B'0': cannot ~ B' l': can l~'S'rALI,,~TIO~' <7 bits>
This ficld represents control vector bits that are controlled/m3n.l~,cd entircly by the installa-tion. The I~Srl'r~LLI~TlO!~ ficld is not chccked/cnforced by the h.lrd~ arc (CF).
Il'~ K < I bit >
rl his ficld indicatcs whcther a public key can be used in an 11'1, K instruction to ~alid;3tc a li~rit31 sign.~ture on an input E~cternal Key Unit (EKU).
~ B'0': cannot ~ 13'1': can ~otc: the II'UK usage bit does not control the uje of l'U in an EKU to ~alidate a signature on that same E.KU.

Control ~,'ector rorma(s an~ DescripLions 60 2~75329 ICREGMODE <2 BITS>
This field indicates the method used to register a ptlblic key anagt mellt key (PUM) in a certification ~cnter envirollrllent.
o B 00: PUM not registered o B 01 : PUM registere l withotlt restrictions o B 1 0: PUM registere 1 wi~h res~rictions o B 11: reservcd I,ENGTII < 16 BITS> This field contains a lerlgth value which directly or indirectly determines key length or key size. l'he coding and interpretation of the L,ENGTH field is dependent Or the Al,GORITI IM field.
For AI,GORITEIM = B0000 (i.e., RSA) the LENGTII field contains avalue from 512 to 2048 representing modl.llus length in bits. Unless elsewllere restricte l, the public and private keys can range in lengtll up to the modultls length. Tlle lcey gencrator shall ensllre that if LENGTH = n, then a In(:)dultls is generated such that the value of the modulus is B 1 followed by n I zero and one bits.
PAIUIY <16 BITS>
Tllis is a set of bits in the control vector reserved for USt by CFAP and by the the algorithm used to calculatc the IIash Function h. The PARITY bits are used to set even bytc parity on the 12~bit valu( I I=h(C) pro luced by applying I-lash Ftmction h to colltrol vector C.
PR USAGE < 7 BI I S>
In a PR control vector, PR USAGE consists of architected usage bits and reserved bits. Tht PR
USAGE field is also stored as history information in the associated PU control vector.
The fc)llc)wiIlg PR USAGE subfiel ls are defined for a PRA control vector:
o ECrAR < 1 bit>
o EPUIC < 1 bit>
o ECFER < 1 bit>
o ICFER < I bit >
o GDS < I bit>
T he f(:)llowing PR USAGE subfields are define l for a PRC control vector:
o ECFAR < 1 bit >
o RTNPMIC/RTCPMIC < I bit~, reserved (=B I ) (Reencipher to New PICA Master ICey / Reencipher to Current PIC~ Master ICey) o EPUIC < I bit>
o GDS I bit>
o GADS <1 bit>
Tlle r(:~llowing l R USAGE subfields are define 1 for a PRM control vector:
o ECIAR<1bit>
o RTNPMlClRI('PMlC <1 hit>, reserved (=B I ) o r,PUIC < 1 l~it>
o GI)S <1 bit>
o GICSP < 1 bit >

6l ~u /~y o IDK <1 bit>
o C.~ADS <I bit>
The followillg PR USAGE subfields are defined for a PRU control vector:
o E( 'F AR < I bit >
o RTNPMIC!RT(.PMIC < 1 bit >, reserved ( = B' 1 ') o EPUIC c I bit>
o GDS <1 bit>
o GADS <I bit>
PU USAGE < 7 BITS>
In a PU control vector, PU USAGE consists of arc}litecte(1 usage bits and reserved bits. The PU
USACIE field is also stored as history information in tl~e associated PR control vector.
The following PU USAGE subrields are defined for a PU~ cont:rol vector:
o Rl'Nl'MIC!RTCPMIC <1 bit>, reserved (=B'l') o IPUK < I bit>
o ECFER < I bit >
o ICFF.R < I bit >
The follov~ing PU USAGE subfields are defilled for a PUC control vector:
o RTNPMI</RTCPMIC < 1 bit >, reserve(l ( = B' I ') ~) II'UI~ < 1 ~it >
The following PU USACJE subfields are defined for a PUM control vector:
o ~ I'NPMIC1RTCPMIC ~ 1 bit >, reservecl ( = B' 1 ') o IPUI< < 1 bit>
o GICSP < 1 bit>
o IDK < 1 l~it>
The following PU USAGE subfields are defined for a PUU control vector:
o RTNPMIClRTCPMIC < 1 bit>, reserved (=B'1') o IPUIC<lbit>
RTNICMP/RTCICMP < 1 BIT> (Reencipher to New ICMP / Reencipher to Current ICMP) This ficld indicatcs whether a public or private key can be reenciphered in an RTNICMP or RTCICMP instmction:
o B'0': cannc)t o B' 1 ': can NOTE: 'I~his field has a fixed value of B' 1', and is enforced in tlle GDAK and GPUPR inst.ruction.
SOFTWARF, <6 BITS>
This field represellts control vector bits that are controlled!rllanaged entirely by CFAP. The SOF~WARE field is not checked/enforced by the hardware (CF).
: Q~

I~T9 91-015 ~n O~r~ie~ of Pl~CD ~e~ T~pes TESTZERO < 3 bits >
This field is reserved by the CF and tested for zero. That is, TESTZERO must equal B'000'.
THRES-.~IDC < 2 bits >
This field is used in a r'Ri.\~a eontrol veetor to establish a threshold on IIIST-.~,IDC in a corresponding PU.\/Ib eontrol vector. The PR.~Ia and Pll.\~lb are used together irt a Gk~SP or IDK instruction. ~ote that "a" represents this device and "b" another dcvice.
~ B'00': reserved ~ B '01 ': H IST-.~,I DC must be 2 B'01 ' ~ B'10': IIIST-:.\I[)C must be 2 B'10' ~ B' 11 ': HIS'I'-:\ IDC must be = B' 11 ' ~'ALl,'E/.~l,'l'I IE~'TIC~TOR < I bit >
The VAL~,'E/~ 'TIlE?~iTIC~L~TOR field is rcsen~cd for use by the algorithm used to calcu-late the H~sh l~unction h.
The layout of control vectors for all PKCD keys are deseribed in Figs. 31 through 38, inclusive.

General form~t for the h~sh vector A definition of the hash vector fields is provided below in alphabetical order:
A~''l'rV,~Kl~i~'T O~E ~ I bit >
This field is a fixed value of B'l'.
A~TIV~RIr~i~'T ZERO < I bit >
This field is a fi~ed value of B'0'.
E,~'l'E~SIO~' < ~ bits >
This field indicates whether the hash vector is produced from a 6~-bit, 128-bit, or > 128-bit control vector. In PKCD, all hash vectors are produced from > 12~-bit control vectors.
~ B'00': h~sh vector produced from 64 bit control vector ~ B'01': hash vector produced from 128-bit control veetor ~ B'10': hash veetor produeed from >'128-bit control vector ~ B' 11 ': reserved IlASHi < 107 bits>
The l-IASII field consists of 107 bits of a 128 bit :\lodification Detcction Code (.~IDC) produced by using the .\~IDC-2 hash algorithm. The IIASH ficld consists of bits 00..06, 08..14, 16. .__, 2~. .29, 32.. 37, 40.. 44, 48. .5~1, 56. .61, 64.. 70, 72.. 78, 80.. 86, 88.. 94, 96.. 1 0--! I O ~ I 0, 112..118, 120..126 from the ;,~IDC.
lcl'l'Y ' 16 bits>
'Ihe l'.~RI'rY bits are used to set even b~te parity on the 1~8 hash ~ector.

~'ALI,'E/.-~I''I'HE~''I'IC~'rOR < I bit >
'I'he V~L~,'L/r'~l,l'lIEl\'TICr~'rOR field inclicates ~ hether the hash vector is associated ~vith a value or an authenticator, as follo-~s:

Control ~'cctor rorm~ts ~nd l)~scription~ 63 13T9-91-015 An OverYi~ of Pl~CD l:~e~ T~pes 20~5~29 ~ B O: value ~ B I authenticator The layout of the llash vector is described in Fig. 39.

Instruction Processin.~r Instruction Set The C~ instructions may be logically divided into eight functional categories:
CF Initi;lli~atioll These instructions support various CF initialization, including thc PI~A m~ster kev.
CF Configuratioll This instruction is used to load a configuration vector into thc CF.
CF Au~lit This instruction is used to export the nonsecret portion of the CF environment.
CF Control These instructions are used to control instruction execution and to ch;mge Cl st;lte.
Cl~DS Up(l:ltc These instructions are used to reencipher the keys in a CKDS from a currcnt to anew, or an old to a current, PKA master key.
Kcy i~l.allagcnlcnt These instructions are used to generate, e~cport, and import l'KCD 1'~ ~icys.
They are also used to generate and import DEA key-encrypting keys.
Systcm Digital Sign:lturcs These in~tructions are used to gcnerate and verify system di3ihl si3latures.
Application Digital Signaturcs These instructions are used to generate and verify application digital signat-lrcs.
Crypto l acility Backup These instructions are used to e:cport and import a CI~ environment.
tility These instructions provide miscellaneous cryptographic functions.
I he instructions are listed by group in the follo~ving table:
T3ble 1 (1'3;,e 1 of 3).
Instrllction.~'.lmc ¦ Instrllction.~ cmol~ic Cl~ iti:lliJ..ltioll:
Load Physical Idcntiticr 1 I'ID
Gcncrate Dcvice ,~uthcntication Key Pair GD.~K
Lo3d First 1'1~ \laster ~ey Part Ll~ IKP
Combinc l'K:~ ~laster ~ey Parts CP~IKP

Control ~ cctor Forma[s 3n~ [)eseri~-(ions 6 UT9-91-015 An Ov~rvie~ of PI~CD Key T~pe.s 207~329 Table I (Page 2 of 3).
Instruction.~'~me Instruction.~lncmonic Generate ~Tew PKA ~faster Key G~'P:~,IK
Generate i~rew DE~ faster Key G~D~fK
Set PKt~ ~Iaster Key SP:~IK
Load ~IDC For Public Certification Key LMDCC
Load ~f DC L.~f DC
Initialize Pseudo Random l\~lmber Generator II'RI\G
C~' Configur:ltion:
Load Confic~uration Vector ¦ LCV
CF ~udit:
E.Yport Crypto Facility Audit Record ¦ ECFAR
CF Control:
Enter Preinit State El'S
Enter Init State EIS
Enter Run State ERS
Clear ~ew PKA Master Key Register CL~\'P.~,fK
Clear Old l'KA Master Key Register CLOP.~fK
Set Authorization ~lag S~F
Set Enable Flag SEF
CKDS l,pd;lte:
Reencipher to New PKA Master Key RTNl'.~fK
Reencipher to Current PKA .Master Key RTCP:\,fK
Key .~l~n :Igcmen t:
Generate Public and Private Key Pair GPUPR
E~cport Public Key EPUK
Import Public Key IPUK
Import Private Key IPRK
Generate Key Set PK~ (iKSP
Import DE~ Key IDK
Verify Intcrnal Kcy Unit VIKU
System l)igit:l1 ~Sig~11atl1rcs:
Generate Digital Sic~nature GDS
~'erify I)i_ital Sig~nature VDS
.-~pp1ic:ltio1l I)igit:l1 Sign:ltures:
Generate .~pplication Di_ital Signature GADS
Verify ~pplication Di;,ital Signature ~'ADS
Crypto I-:lcility 13:1c~up:

Instruction Proccssing 6 BT9-91-015 Lo~d Physic~l De~ice ID (LPID) Table I (Page 3 of 3).
Instruction ~amc Instruction .~Incmonic Export Crypto Facility Environrnent Record ECFER
Import Crypto Facility Environment Record ICI~ER
l,'tility:
Set and Reset Alarm ¦ SRAL.~I

CF Initializ~tion Lo~d Physic~l Device ID (LPID) EQliATIO~:
PID /128b/
CC /unspecified/
PAR~IETER DEFI~ITIO~-S:
Illp~lts l)cscription I'll) ~ 1~8 bit physical identifier of a dcvice.
Outpllts D~scription CC Condition code indicating success or failure of the instruction execution.
DESCRIPTIO~:
The Load Physical Device ID instruction perrnits a 1~8 bit physical identifler of a device to be loadcd into the CF and stored in the DID and EID registers. E.cecution of the LI'ID instruction causes the DID
flag to be set to the full~' state. The instruction e.cecutes only whcn the DID flag is in the 'empty state.
(Note that an EPS instruction must be executed in order to reset the DID flag to the 'empty' state.) The DID flag serves two purposes: (a) it controls the execution of the LPID instruction, and (b) it indicates ~vhether the DID and EID registers have or have not been initialized.
The value of PID stored in the DID register is the PID value associated with I'UA and I'RA (i e., the Pl~A and PRA of that device).
The value of PID stored in the EID register is used for two purposes: (a) it is the ~.Llue stored in thc EIDO field of a certificate, and thus identifies the device to another device, and (b) it is the v ;llue stored in a DE~ key rccord, ~vhich is used by the GKSP and IDK instructions as an anti-rcimport valuc.
The 16 b~te I'ID consists of an 8 byte network part and an 8 byte node part. I he 8 b~te nodc part uniquely identifies the node ~vithin a net-vork. The 8 byte network part uniquelv idcntities the net-vork.
The objcctive is to arrive at a narning convention that ~vill ensure unique PID values t'rom OIIC net- ork to .lnothcr. Onc possibility is for the 8 b~te net-vork part to be registered (e.g., ~vith an IB.~I rcgistration ccntcr) .
Thc l CE~AR instruction can be used by CI~AP to read the contents of the DID and EID registers.
~ or reasons of security, the Ll'ID instruction is architected such that the DID registcr contcnts cannot be change(l without erasing the contents of the Pl,.-~ and l'RA but'fers (i.e., a different PID can t be assi_ned to the same key pair stored in the P[,A and PRA buffers). In like manner, the ICFER instruction is archi-lnstruction Proccssin~ 66 BTs-s l -O l S 2 ~ 7 ~ 3 2 9 Lo~d Ph~ sic~l Device I D ( L P I D) tected such that the EID register eontents eannot be ehanged without reinitializing the CK.~IP register with a new key. Otherwise, use of the EID buffer as an anti-reirnpon value would be ineffective.
The LPID instruction e:~ecutes only in the "preinit~ state.

Instruction Processing 67 r3-r9-9l-ols 2 0 7 - 3 2 gCener~te Device Allthelltic ttion l~e~ P.lir ((~DA~) Gener~te Device Authentic~tion Key P~ir (GDAK) ~ EQuA I IO~r C1 /128 bi ts/
CZ /128 bi ts/
CC /unspeci fied/
P~Rr~lETER DEF~ITIO~S
In pll ts l)~scri ption Cl A 12~ bit control vector associated with the generated public authentication ~;ey I'l,A.
C' A 12~ bit control vector associated with the generated private authentication key I'RA.
OUtpllts l)~scription CC Condition code indicating success or failure of the instruction execution.
DESCRII~TIO~T:
The Generate Device Authentication Key Pair instruction generates a public and pri-ate authentication l~ey pair, PUA and PRA. The generated keys are stored in the PUA buffer and PRA buffer in the CF, respectively, as Crypto Facility I'KA Key Record I (CFPKRl) and Crypto Facility l'KA Key Rccord ' (CFI'KR2). The 12~ bit control vectors associated ~vith PUt~ and PRA are specified to the GDAK instruc-tion as inputs Cl an~l C2, respectively. The control vectors specify the public key algorithm and other ;31_0-rithm related information necessary for }cey generation. Consistency checking is perfotmed on Cl and C2.
For example, the ALGORITHl~I, ALGORITH.~,I EXTEl\'SIO~, and LEI\GTH fields in Cl and C' must match.
E.Yecution of the GDAK instruction causes the GDAK FLt~G in the state vector to be set to the t;lll state from the empty~ state. The instruction e.Yecutes only ~vhen the GDAK FLAG is in the empt~ st~lte.
(~rote that the EPS instruction must be eYecuted to reset the GDAK FLAG to the empty state.) The GDAK FLAG serves t-vo purposes: (a) it controls eYecution of the GDAK instruction, and (b) it indicates when the I'UA and I'RA buffers have been initialized.
The GDAK instruction eYecutes only in the preinit state.
FU~CTIO~AL SPECIFICAT10~:
1. I'erform input parameter consistency checking: ~'one.
2. Perform state vector checking:
a. Verity that CF STATE in the state vector is in the preinit~ state.
b. Verit~ that GDAK I~LAG in state vector is in the empty state.
Continue if checking succeeds; otherv~ise set CC status fklg aI-d jump to stcp ~.
3. ~ertorrn control vector checl;ing. Continue if checking succceds; other- ise set CC status flag and jump to step ~.
. Store control vectors:
a. Store C1 in l'~ CV Register b. Store C2 in PRACV Register . Gcnerate .~ pair of cr~ptog~raphic facility PKA records cfpkrl and cf'pkr2 of Iength sl and s2, rcspcctiv Iy, ~-here s l and s2 are pre-selected ~alues that indicate the number of ~ bvte blocLis.

Instruc~ion l'roccssin~ 6X

13'r9-91-015 Gener;lte De~ice Alltllentic~tion ~e~ P;lir (GD.~) 207 i329 6. Store generated keys and Iengths:
. . a. Store sl in PUA Buffer Length field in CF Environment.
b. Store cfpkrl in PUA But'fer in CF Environrnent.
e. Store s2 in PRA Buffer Length field in CF Environment.
d. Store cfpkr2 in l'RA Buffer in CF Environrnent.
7. Perfonn state ~ector update.
a. Set GDAK FLAG to the ~full" state.
8. Produce output CC from CC status flags.
CO~''I'ROL BLOCK ~'D CO~-TROL ~'ECTOR CHECl~l~-G:
Perfonn control vector checking:
1. Chec~ing on Cl (associated ~vith PUA) a. Verify CV TYPE = 'public authentication key' b. ~'ote: checking on CV TYPE E~TE~'S10~\~ has been deleted.
c. Verify RTi~lKMP/RTCKi\lP usage bit = B'l' d. Perfonn Control Vector Validate on Cl to validate certain fields in Cl.
e. Verify RC I = 0.
If any of the abo-e ehecking fails then stop the control vector ehecking and issue a condition code to indicate that Cl is not ~alid.
2. Checking on C' (associated ~vith l'RA):
a. Verify CV TYI'E = 'pri-ate authentieation key' b. Perfonn Control Vector Validate on Cl to validate eertain fields in Cl.
c. Verify RC 1 = 0.
If any of the above checking fails then stop the control vector checking and issue a condition code to indicate that C2 is not valid.
3. Checking on Cl and C2:
a. ~Tote: checking on CV TYPE EXTE~TS10~ has been deleted.
b. Verify ALGORITII:M in Cl = ALGORITII.~I in C2 c. Verify t~-LGORITHM EXTEi~SIO~T in Cl = ALGORITIIM EXTEI\'S10~ in C2 d. Verify LE~GTH in Cl = LE~TGTH in C2 e. Verify PR USAGE in Cl = PR USAGE in C2 f. Verify PU USAGE in Cl = I'U USAGE in C2 If any of the above checking fails then stop the control vector checking and issue a condition code to indicate that cross checking among control vectors has failed.
I\'ote that there is no cross checking on ( I) DO~IAI~' ID since this field is not implemented in the l'UA and l'RA eontrol vectors.

Inslruction Pro.cssin~ 69 13T9-91-015 Lo~d First PI~A M~ster Ke~ P.lrt (LFP~ P) 207.~29 Load First PKA Master Key P~rt (LFPMKP) EQUr~ l'IOl~T:
input-mode /lb minimum/
<key-part~ /lZ8b/ ; if input-mode=0 CC /unspecified/
rARA~lETER l)EFr~'ITlO.~S:
Inputs Dcscription input-lllo(lc spccifies how the key part to be processed is supplied to the instruction.
~ 0: the key part is passed via the instruction interface, i.e., via input parameter key-part.
~ 1: the key part is retrieved from the intern~l KP register.
I;e~-part 12~ bit key part. This parameter is required only when input-mode= O.
011tvUtS l)~s~ription CC Condition code indicating success or failure of the instruction e~cecution.
DESCI~ll''rlO~':
The Load First PKA ~Iaster Key Part instruction loads the first part of the PKA master kcy (K~IP) into the ~K~IP (~ew I'KA ;.\~Iaster Key) register. An input-mode par~Lmeter indicatcs whether thc loadcd key part is passed as an input parameter at the instruction interface or whether it is retrieved from the internal Kl' register. The ~rKi~lP flag is set to the i'partially full" state from the ~empty" state and the ~Ki\ilP llistory Flag is set to O (indicating that the contents of the ?~KMP registcr were loaded ~ia the LFPi\llKP instruction). If input-mode= 1, the operation is performed only if the KP ftag is in the "full"
state; in ~vhich case the KP flag is set to the ~empty~' state. The operation is performed only if the ~K;\IP
fiag is in the "empty" state.
~'otc: If input-mode= 1, it is assumed that prior to the eYecution of this instruction the first I'KA master key part has been entered into the key part register via a key-entry device, keyboard, etc., which, optionally, may operate only in a special authorized mode (e.g., supersecure mode enabled via a physical key-activated switch).
The LFP~IKP instruction e.~ecutes only in the "run" state.

Instruction Proccssin~ 70 BT9-91-015 Collll)ille PI~A M;lster K~ P~rts (CP~ P) Coml)ille PKA M;lster Key P;lrts (CPMKP) EQU~ I'10~':
input-mode /lb minimum/
mode /lb mi nimum/
<key-part~ /128b/ ; if input-mode=~
CC /unspecified/
P.~ IETI~R DEFI~I'I'IO~'S:
Inp~lts Dcscription input~ ode specifies how the key part to be processed is supplied to the instruction.
~ 0: the kcy part is passed via the instruction interface, i.e., via input paramctcr l;cy-part.
1: the key part is retrieved from the internal KP register.
mode indicates whether the l'K.~ master key part in the key part rCvistcr is an intermcdiatc ke-part or a last key part.
~ 0: intermediate key part ~ 1: last key part l~e~-pal-t 1~ bit key part. This parameter is required only when input-mode= 0.Outpllts l)cscription CC Condition code indicating success or f~ilure of the instruction e.cecution.
DESCRlP'rlO.~':
The Combine l'KA .~Iaster Key l'arts instruction E.l~clusive ORs a PKA master key part with the l'KA master key part stored in the ~K.~fP register and stores the result in the i~'KhII' register. An input-mode parameter indicates whether the loaded key part is passed as ~n input parameter at the instruction interface or whether it is retrieved from the intcrnal KP register. The ~'K;\IP flag is set to the "full" state if mode = 1 or to the 'Vpartially full" state if mode = 0. For mode= 1, the CP;~,IKP instruction ensures that the produced value of Kl~P has odd patity (odd parity adjusted, if necessary) and that the left and ri~lt ~
bit parts of K.~,IP are not equal. If input-mode= 1, the operation is performed only if the KP tlag is in the "full" state; in which case the KP flag is set to the "empty" state. The operation is performed only if the l\'K~IP flag is in the "partially full" state and the ~KhIP History flag is zero. The instruction has no output .
~'ote: If input-mode= 1, it is assumed that prior to the e~cecution of this instruction a PK.~ mastcr l;ey part has been entercd into the kcy part register via a key-entry device, keyboard, etc., which, optionally, m;ly operate only in a speci31 authorized mode (e.g., supersecure mode enabled via a physical ke~-acti-atcd switch).
The CP.\,IKP instruction e,~ecutes only in the "run" state.

InslrucLion Proccssin~ 7 i srg-sl-ols Cener~te Ne-. PI~A M~ster l~e~ (GNP

Gener~te New PKA Master Key~ 'Mh) EQUAT10~':
() CC /u n s pec i f i ed/
PARA.~IETER DEFI~II'IO~'S:
Inputs Dcscription ~one.
Outputs l)cscril~tion CC Condition code indicating success or failure of the instruction e~cecution.
DESCRII'T10~:
The Generate l\Tew l'K,~ ~,laster Key instruction c .uses a 12~ bit odd parity ~djusted r.~ndom number to be generated ~nd stored in the ~K~IP register. The lcft and ri~ht 6~ bit p~rts of the generated liey must be unequal. The instruction e~cecutes only if the ;!~rK:~,IP flag is in the ~empty" state. Successful e~ecution ot' the G?~iPi\~lK instn1ction causes the ~'K.\IP flag to be set to the "full" state from the "empty" state and Ihe i\'K;\/lP l-listory flag to be set := 13'1'.
The G~ IK instruction e.~cecutes only in the "run~ state lnslrucLion Proccssin~ 72 l3T9-91-015 C.ener:lt~ Ne~T DEA l\l;lster ~;eJ ((~'D.~
2û73329 Gener~te New DEA M~ster Key (GNDMK) EQUATIO~r:
() CC /unspeci fied/
I'AR,~I~IETER I)EFI~'Il'IO~'S:
InPuts Dcscription ~'one.
Ou tpu ts Dcscription CC Condition code indicatinD success or f3ilure of the instruction eYecution.
DESCRII'TIO~':
The Generate ~'e-v DEf~ .~laster Key instruction causes a 12~ bit odd parity adjusted r.mdom number to be Dencr~tcd and storcd in the new master key rcgister (i.e., the ~'K.~I register). The let't ~nd ri~lt ~ bit parts of the generated key must be unequal. The instruction executes only if the ~'K.~,I 11aD is in îhe 'eIII~ t!"' state. Successful e.Yecution of the G~'D~iK instruction causes the ~Tl~IK flag to be set to the "full" st ite from the 'Vempty'' st~te.
'I'he ~l\'I).~,IK instruction executcs only in the "run" state.

Instruction Pro.~,sin~ 73 BT9-91-015 Set PKA Master Ke~ (SPi~

Set PKA Master Key (SP~IK) 2 07 5 3 ~
EQU~TIO~':
() CC /unspeci fi ed/
P..~R~ lETr'R l)EFr.~'l'rlO~S:
Inl~llts Dcscription ~'one.
Outl)llts l)escription CC Conciition code indicating success or failure of the instruction execution.
DESCR1PT10~
The Set l'K~ l\,faster Key instruction transfers the contents of the CK~fl' reg~ister into the OK.~,II' register and then transfers the contents of the l~K~IP register into the CK~IP register. This instruction operates only if the ~'K.~fP flag (new l'KA master key flag) is in the "full" state and the left .and ri~tt 6~ bit parts of the key stored in the ~K.~II' register are unequal. ~Iso, if the CK~II' tlag is in the ~full" state .~nd CK:\/II' I IIS l'ORY = 1, then the instruction operates only if ~ K.~f l' I IISTORY = 1. Tllis guarantees that a C~-gencrated Ki~IP c~n't be replaced by a CI~P-supplicd K.~fP.
The SP~IK instruction is used to activate a ne~v K.~fP after the RT~ \fK instruction has been uscd to reencipher encrypted records in the CKDS from encryption under the current K.~ll' to ;l ne~v K.~,ll'.
The SP-~,IK instruction executes only in the "run" state.

Instruction Proccssin~/ 7 ~ 13T9-91-015 Loa(l ~IDC For Public Certitï~tion l~ey (LI~IDCC) 2~7~32~
Load l\IDC For Public Certific~tion K~y (LMDCC) EQU~'rlo~:
index-value /4b/
MDC-value /128b/
CC /unspecified/
P~RA~IETER l)EFI~'ITIO~S:
InPuts l)~scription in~ lu~ A S bit field containing an indcx value from 0 to 15.
~IL)C-v;llue A 128 bit modification detection code to be loaded into one of 16 12~-bit storage - locations in ~IDC Tablc, dcsi~,nated as EKUMDC(0), ..., EKUMDC(I5) Outp(lts Description CC Condition code indicating success or failure of the instruction execution Dl.SCRll''l'IO~':
The Load MDC For Public Certification Key instruction perrnits a 12~ bit MDC, designated MDC-value, to be loadcd and stored in the CF in one of 16 possible storage locations in MDC Table, dcsig-nated as EKUMIDC(0), ..., EKUMDC(15). MDC-v~lue is stored in EKUMDC(i), where i is the v~luc of inde.Y-value .\,IDC-value contains an MDC calculated on an External Key Unit (EKU) usinV one of sever~l possible hashing algorithrns (see the hash-rule parameter of the IPUK instruction). The EKU must contain a public certification key PUC. (The fact that EKU contains a public certification key is verificd when EK[,' is impoltcd using the Il'UK instruction ) 'I'he Load MDC For Public Certification Key instruction scts F,KUMDC FLAG(i) equal to B'10'.
The LMDCC instruction operatcs only when EKUMDC FLAG(i) = B'00' Otherwise, to lo;3d an MDC into an already occupied ;\IDC Table location requires EKUi~,IDC FLAG(i) to be reset to B'00' This can be done only be issuing an EPS or EIS instruction. For reasons of security, the LMDCC instruc-tion is architected such that the MDC Table locations EKUMDC(0) thru EKI,'.~IDC(15) cannot be changed without erasing the contents of the CKMP re~,ister. Thus, a certification center has the means to audit each security module to ensure that public certification keys have been loadcd in conforrnancc with an established network security policy.
The EKUMIDC FL~G serves the following purposes: (a) it controls initializ;ltion of thc ML)C 'I'able via the LMDCC and LMDC instructions, and (b) it controls import of public kcys via the "MDC-modc"
parameter of the IPI,'K instruction.
The ECFAR instruction can be used by CFAP to view the contents of the MDC 'I'ablc and thc l,~U.\,IDC I-LAG field The L,MDCC instruction c,Yccutes only in thc ~run~ state InsLruc~ion Proccssin~ 7 13r9-9l-ols Lo~d ~IDC (Li~IDC) 207:~32~
Lo~d I~IDC (LMDC) EQUA'rIO~r:
MDC-val ue /128b/
CC /unspeci fied/
r,~R~.~IETER DEFI~ITIO~S:
Inputs Dcscription ;.\II)C-~;Ilue ~ 12~ bit modifieation deteetion eode to be loaded into EKl'.~fl)C(16).
Outputs l)~scription CC Condition eode indieating sueeess or failure of the instruction e~cecution.
DESCRII'TIO.~:
The Load ~IDC instruetion permits a 128 bit I~IDC to be lo.lded and stored in :~,IDC T;lble stor;lge loc~tion EKU.~,IDC(16). .~fDC-value contains an .~IDC calcul~ted on an E~ternal Key l nit (EKI') usin~
one of se-eral possible hashing algorithms (see the hash-rule parameter of the II'UK instmction). The E~l, must eontain a public key management key, a public authentication key, or a public user key (no public certification key). (The fact that EKU contains a public key manacement key, a public ;luthentic;ltion l~ey, or a public user kcy is verified when EKU is imported using the IPliK instruction.) Unlike the L;~/fDCC instruction, the L:\/fDC instruction e.~ecutes re~ardless of the current value of EKU~fDC I LAG(16). E,cecution of the L.\~IDC instruction causes .~IDC-v:~lue to be 10;3ded into EKUl~,fDC(16) and EKUi~,lDC FLAG(16) to be set equal to B'10'.
The EKU.~IDC FLAG serves the followin~ purposes: (a) iî controls initiali~ation of the :~,IDC Table via the L.\~fDCC and L.~fDC instructions, and (b) it controls import of public keys via the ".~fDC-mode~
parameter of the IPUK instruetion.
The ECFt~R instruetion can be used by CFAP to view the contents of the l~,IDC 'I'able ~nd the EKU.~IDC FLAG field.
The L~IDC instruction e~cecutes only in the "run" state.

Ins~ruc~ion l'rocessing 76 ~3T9-91-015 2~ u~10r~l1dom Number Cener:~tor (IPRI~rG) Initi~lize Pseul~orandom Number Generator (IPRNG) EQUA I IO~':
() CC /uns peci f i ed/
PARA~IETER DEFr.~'ITIO~S:
Inputs Dcscription ~'one.
Outputs l)cscription CC Condition code in~licating success or failure of the instruction execution.
DESCRIPTIO~':
The Initialize Pseudorandom ~'umber Generator instruction initi~ es the pseudorcmclom number gen-erator usin~, the mcthod specified in the Initialize Pseudo-Random Number algorithm (Initialize Pseudo-random ~\'umber). 'I'he Initialize Pseudo-random ~umber algorithm reads the current values stored in the PR~\'GKEYl, PR~'GKEY2, and PRi~'GCTRl registers and calculates two new key values ~vhich are then stored back into the I'R~rG~EYI and I'R~'GKEY~ registers.
The II'R~'G instruction executes in the "preinit", "init", and ~run~ states.

InsLruc~ion Proc~ssin_ 77 l3r9-9l-ols Lo:ld Configur~tion Ve~tor (LCV) 2 ~ 7 !~, 3 2 9 CF Configllr~tion Lo~d Configur~tion Vector (LCV) EQUA'l'IO.~
config-vector /512b/
CC /unspeci fi ed/
PARA.~IETER DEFl~'ITIO~'S:
Inpllts l~cscription cont~g-vcctor A configuration vector.
Outputs Dcscription CC Condition code indicating success or failure of the instruction e~ecution.
I)ESCRIl'T10~':
The Load Configuration Vector instruction perrnits a 64 byte configuration vector to be loadcd and stored within the CF Environrnent. E~cecution of the LCV instruction causes the LCV r Ll'~G to bc set to the "full" state. The LCV instruction executes only when the LCV FLAG is in the ~empty~ state. 'I'he LCV
FLl~G can only be reset to the "empty" state via e~cecution of an EPS or EIS instruction. In cffcct, the LCV
FLAG controls LCV e?cecution as follows: (a) If the LCV FLAG = "cmpty" state, thcn LCV instruction e~ecution is enabled for one execution only, whereas (b) if the LCV ~LAG = "full'' state, thcn L.CV
instruction e~;ecution is disabled.
Execution of the EIS instruction causes a configuration vector in the CF Environment to be initialized/reinitialized to a "default" value. This value can be changed by e~cecuting an LCV instruction.
For reasons of security, the LCV instrnction is architected such that the configuration vcctor ~alue storcd in thc CF Environrnent cannot be changed without erasing or invalidating the contcnts of thc CK.~,II' buffcr.
The LCV instruction e:cecutes only in the "init" state.
F~C'I'IO~TAL Sl'EClFlCL~TIO~T:
1. Pcrform configuration vector and state vector checking:
a. Verify that CI~ ST~TE in the state vector is in the ~init~ state.
b. Verify that LCV F LAG in the state vector is in the "empty" state.
Continue if chccking succceds; other vise sct CC status tlag ;3n~1 jump to stcp 5.
2. I'crt'orm consi~tency checl;ing on config-vector:
a. Verify Vcrsion ~umber = X'01' b. Verify K.\/l RELO~D = B'0'.
c. Verify Dr l l~\'E(LI'S) = B'l' or DEFI~\'E(EIS) = B'l' (i.e., eithcr EP~ or r 1~ or both arc dct;llc to prcvcnt C~-rcinitialization lockout) d. For i = O to 71, do the following:
I) Verify DEEI?iE(i) = B'l'.
2) VerifyL~TII CO~'TROL(i) = B'0'.
e. I or i = 72 to start-inst-inde~c minus l, do the follo-~ing:
I) Vcrify DEFI.\'E(i) = B'0'.
2) Verify .~I,'TII CO~'TROL(i) = B'0'.
Instruc~ion I'roccssing 78 13 r9-91-ols E.~port Cr~pto F~cilit~ Au(lit Re~ord (ECF~R) Continue if checking succeeds; other vise set CC status nag and jump to stcp 5 3 Loacd the value of config--ector into the conflguration vcctor Perform state vector update a Set LCV FLAG to the "full" state b For i = start-inst-index to 1~3, process ~UTI I CO~TROL as follows 1) If AUT~I CO~TROL(i) = B'0', then set AUT}I(i) = B'0' and E~'ABI.E(i) = B'00' 2) If AUTH CO~TROL(i) = B'l', then set A~,iTlI(i) = B'l' ancl E~'ABLE(i) = B'l l' 5 Produce output CC from CC status flags CO~ I ROL ~'ECTOR C~I~Cl;I~G
~one E~cport Crypto F~cility Au(lit Record (ECFAR) EQUA I 10~:
process-mode /2b minimum/
PUA-key /lb minimum/
product-component /lb minimum/
<hash-rule~ /3b minimum/ ; if process-mode = (1 or 2) ~IKUl-length~ /16b/ ; if process-mode = 2 cIKUl~ /unspecified/ ; if process-mode = 2 <RN~ /64b/ ; if process-mode = (1 or 2) cfar-length /16b/
cfar /unspecified/
~dsigl-length~ /16b/ ; if process-mode = (1 or 2) <dsigl~ /unspecified/ ; if process-mode = (1 or Z) CC /unspecified/
- P~RA;~lE I ER DEFr~'ITIO~S:
Inputs Description process-mocle The process-mode parameter specif1es the type of processing to be performcd ~ process-mode = 0 no digital signature is generated ~ process-mode = 1 a digital signature is generated on CFAR1 using the pri-ate authentication key PRA stored in the I'RA buflcr in the CF
~ process-mocle = 2 a cdigital signature is gcnerated on C~ RI using the pri-ate l;ey PR specif;ed in IKUl ~ proccss-mocle = 3 rcserved -I;cy The I'lJ'A-key par.lmcter inclicates ~vhcther thc cfar shoulcl contain cf'plirl, ~vhich cont;lins the I'l,A kcy ~ I'[,~-kcy = 0 no ~ I'UA-key= 1 yes ~ro(lllct-colllpollcnt Thc product-componcnt parametcr indicatcs ~ hcthcr thc ctar sho-lld c ont lin thc ~onsc-cret l'rocluct Environment ~ procluct-component = 0 no ~ procluct-component= 1 yes Ins~ruc ion Proccssin~ 79 13T9-91-015 E~;port Cr~pto F;l~ilit~ All(lit Rcc()rd (ECF~R) 207 i329 hash-rule Specifies the hash algorithm to be used to caleulate a hash value on cfar. The encoding of the hash-rule is as follows:
~ hash-rule = 0: .~IDC-2 algorithm ~ hash-rule = 1: :\~IDC-~ algorithm ~ hash-rule = 2: .\~fDJ algorithm ~ hash-rule = 3: quadratic residue ~ hash-rule = 4-7: reserved This parameter is required only when process-mode= I or process-mode= 2.
'l-lcngth The length of IKU I in bytes. This parameter is required only when process-mode = 2.
IKUI An Internal ICey l,'nit containing a private key PR. This parameter is required only ~-hen process-mode = 2. The value of EID in SCB I must equal the value in the Ell~ re ,ister.
The v;~lues of Tstart and Te,xp in SCB I must satisfy the relationship Tstart S DT <
Texp, ~vhere DT is the current date and time expressed in Coordinated l,niversal Tilne.
R~' A CFAP-supplied time-variant parameter to be stored in CFARI. This parameter is required only ~ hen process-mode = I or process-mode = 2.
OUtpllts D~scription ef~r-len~ th The length of cfar in bytes.
cf~r A Crypto Facility Audit Record.
~si~rl-lcll~,tll 'I'he length of dsigl in bits. This parameter is required only ~vhen process-mode= I or process-mode= 2.
~Isigl A digital signature produced from a CF System Signature Record (CFSSR) and a pri-ate key PR, in accordance ~vith section 6 of ISO DIS 9796. The CFSSR contains a 12g-bit hash value calculated on cfar. This parameter is required only when process-mode= I or process-mode= 2.
CC Condition cocle indicating success or failure of the instruction execution.
- DESCRlPT10.~':
The Export Crypto Facility Audit Record instruction constructs a Crypto Facility Audit Record (CFAR) and returns it to the CFAP. The CFAR contains (I) a copy of the nonsecret palt of the CF
Environment, a date and time (DT) supplied by the CF, and (3) for process-mode= I and process-modc = 2, a CFAP-supplied time-variant value R~'. R~' can be a random number, sequence number, or time stamp, ~vhich may be used by a designated receiving device to ensure that a produced Cl;AR is current.
A process-mode parameter specifies to the instruction ~vhether a digital signature is ~ellcr;lted on the CFAR and, if so, then ~hether the private key is (I) PRA or (2) a l'R supplied to the ECFAI~ instruction.
A hash-rule parameter indicates to the ECFAR instruction the hash algorithm to be used in cener.ltin2 the dig~ital signature.
Process-mode= I can only be executed ~Yhen the GDAK FLAG is in the "full~ state.l'rocess-mode= 2 can only be executed ~vhen the CK.~II' FLAG is in the "full~ state.
The Lxport Cr~pto Facility Audit Record instruction e.xecutes in the "preinit", "init", and "run" statcs.

Ins~ruction l'rocessin~l ~0 13T9-91-015 Entcr Pr~init Stat~ (EPS) 2~7a 3 2 9 CF Control Enter Preinit St~te (EPS) EQUATIO~:
() CC /unspeci fi ed/
PARA.~IETER DEFI~-ITIO~'S:
Inpllts l)~scription ~\one.
OUtr)uts l)~scription CC Condition code indicating success or failure of the instruction execution.
L)ESCI~ 'rlO.~':
The Enter Preinit State instruction resets the CF STATE to the "preinit" state; it resets the conti_-lr;l-tion and state vectors to zero; it resets the POS register to value X'0123456789ABCDEF0123456789ABCDEF'; and it executes algorithm Initialize Pseu(lo-r;lndom ~\umber to (further) initialize the pseudorandom number generator. The Enter Preinit State instructioll l)()l ~S ~() 1' erase or zeroize the f'R.\IGCTRl, PR~'GC'rR2, 'R~GKEYl, and PR.\TGKEY2 registers, \~hich are regi~-ters used by the Initi31ize Pseudo-random ~umber.

Inslru::ùon f'ro~cssin~ Xl B-r9-9l-ols Ent~r Init St.lte (EIS) ~ ~ 7 ~
Enter Init State (EIS) EQUATIO~':
() CC /unspeci fied/
PAR.~ IETER DEF~ll'IO~rS:
Inpllts Dcscription ?~'one.
Outpllts D~scription CC Condition code indicating success or failure of the instruction execution.
DESCRIPTIO~':
The Enter Init State instruction loads a "default" configuration vector into the CF environment and resets certain flags in the state vector to change the state of the CF and to clear certain registers and buffers.
(See "Configuration Vector" on page 2~ for a description of the default configuration vector.) L~Iore partic-ularly, the Enter Init State instruction causes the flags controLling the old, eurrent, and new K~IP registers to be reset to the 'empty" state, thereby causing these keys to be invali~i. It causes l-.K~:.\ID(' I L,~G fickl to be resct to 7.cro, thereby invalidating any ,\,lDCs currently loaded in the l~,IDC I able. It causes the L CV
FLAG to be reset to the ~empty~ state, thereby enabLing e.~ecution of the LCV instruction. It C;lUSCS the Ct STi~TE to bc rcsct to the "init" state.
The Enter Init State instruction does not reset llags associated with the master key K.~,l.
The EIS instruction can be e:ceeuted in the "preinit", "init", and "run" states.

In~lruc~ion Proccssinu 82 131'9-91-OlS Ent~r Rull St; t~ (ERS) Enter Run St~te (ERS) EQU~ l'lo~':
() CC /unspeci fied/
l',~R ~ TER DEFI~ITIO~'S:
Inpllts Dcscription ~Tone.
Outputs Dcscription CC Condition code indicating success or failure of the instruction execution.
DESC RIPTIO~:
The Enter Run State instruction causes the CF ST~TE fia,, to be set to the "run~ state.
The ERS instruction e.xecutes only in the "init" state.

Inslruc~ion Proccssin~ X3 sTs-sl-ols Cle~r I~Te-- P~A l~l~stcr ~e~T~ R~gistcr (CLNP

Cle~r Ne-r PKA M~ster Key Register (CLNPMK) EQU~'l'IO~T:
() CC /unspeci fied/
R,~.~IETER DEF~I I IO~S:
Inpllts Dcscriptio l\'one.
OUtPllts Dcscriptioll CC Con~lition code in(licating success or failure Or the instruction eYecUtiOn.
DESCRII'T10~:
The Clear I~Tew l'K~ laster Key Register instruction causes the ~K.~II' nag in the state vector to be rcset to thc ~cmpty~ state.
The Clear ~'ew PK,~ laster Key Register instruction e.Yecutes only in the "run" state.

lnstru~Tion Pro~ssiny 81 13T9-91-015 Clear Old PKA Master Key Register (CLOP~
207 ~329 Clear Old PKA Master Key Register (CLOPMK) EQUA I 10~':
() CC /unspeci fi ed/
PARA.~IETER DEF~ITIO~S:
Inpllts Dcscription l~Tone.
OlltPlltS Dcscription CC Condition code indicatincg success or failure of the instruction execution.
DESCRII'T10.~':
The Cle~r Old l'KA .~laster Key Register instruction causes the OK.~,II' flag in the state vector to be resct to the ~empty" state.
The Clear Old PKA ~Iaster Key Register instruction executes only in the "run" state.

InsLrucLion Proccssing ~S5 13T')-91-01~ Set Autll()riz~tion Fl;lg (SAF) Set Authoriz~tion Fl~g (SAF) ~Q~ o~:
inst-index /16b/
CC /unspecified/
I'AR,~ .TER l)EF~ITlO~S:
Inputs l)cscription inst~ (le~ n instruction and instruction-mode inde~c referencing ~U~rII(inst-in(le:c) in the A1J I Il l;eld of the state ~ector. inst-inde:c is a positive integer value bet~een start-inst-inde:c and 1~3, inclusi~e. See Configuration Table for a def~ition of start-inst-inde~c and encl inst-indeY. See also I~UTI-I field in the state ~eetor.
inst-inde:~ is value refereneing the following PKCD instructions and instructionmodes: ~
110 VADS 121 CPMKP (input 3) 132 IPRK (input O) 111 SRALM 122 CPMKP (input 1) 133 IPRK (input 1) 113 EPS ~24 GNDMK 135 RTCPllK

117 LMDCC 128 GPUPR (mode 3/2) 139 GDS
118 LMDC 129 GPUPR (mode 1) 143 VDS
119 LFPMKP (input C) 133 EPUK 141 ECFER
120 LFPMKP (input 1) 131 IPUK 142 ICFER

OutI)uts D~scription CC Conclition code inclicating sueeess or failure of the instruction e~cecution.
DESCRll''rlO~':
The Set Authorization Flag instruetion permits an AUTI-I flag asssoeiate(l ~vith a partieular instructic)n or instruetion mode to be set to the "authorization required~ state. Initially, the AUTII flag may be in the ~authorization not required" or "authorization required" state.
AU-I II flags are reset to the ''authorization not required" state via e~eeution of an l.I'S or l~,IS instruc-tion.
The Set .~uthori7ation l~lag instruetion e.Yeeutes in the ~init~ and ~run~ st.ltes.

Instruction l'roc~sin.7 86 13r9-91-015 Set En~ble Fl~g (SEF) 207~329 Set En~ble Fl~g (SEF) EQI~,~ I'lo.~:
inst-index /16b/
flag-val /2b minimum/
<ctr~ /8b/ ; if inst-index='CPMKP input-mode=O' or inst-index='CPMKP input-mode=1' or inst-index='GPUPR mode=0/2' <r> /16b/
cv> /unspecified/
CC /unspecified/
PAR.-~IE l ~R l)EFI~I~'10.~-S:
Inputs Dcscription inst-in~lc~c An instruction and instruction-mode inde~c referencing E~'A13LE(inst-inde.Y) in the E~ABLE~; ficld of thc state ~cctor. inst-index is a positi-e integer valuc bctwccn start-inst-indcx and 143, inclusi-e. Sce Confiauration Table for a dcfinition of start-inst-index and 1~3. See also E?.TABLE ficld in the state vector.
inst-inde~ is value rcferencing the PKCD instructions and instruction modes, as follo~vs:
113 VADS 121 CPMKP (input 0) 132 IPRK (input O) 111 SRALM 122 CPMKP (input 1) 133 IPRK (input 1) 117 LMDCC 128 GPUPR (mode 0/2) 139 GDS
118 LMDC 129 GPUPR (mode 1) 143 VDS
119 LFPMKP (input 0) 130 EPUK 141 ECFER
120 LFPMKP (input 1) 131 IPUK 142 ICFER

n~g-~l A parameter specifying the L?~rABLE(inst-inde.Y) value, as follows:
~ 0: enabled for any number of executions.
~ 1: enabled for I execution only.
~ 2: enabled for n (n= I thru 255) executions, where n is specit;ed in input paramcter ctr.
~ 3: not enabled The perrnittcd values of flag-val for each instruction and instructiotl modc arc listcd below (see also the E~'ABLE ficld in the state vector for a dcscription of 1 :\A13LE(inst-indcY) values which are valid and invaLid).

Instruction l~roccssing X7 B r9-91-015 Set En;~ Fl.lg (S EF) 207 )~29 inst inst index ~ 1 2 3 index ~ 1 2 3 138 reserved 127 SPllK y y y 1~9 reserved 128 GPUPR (mode G/2) y y y 113 VAOS y y 129 GPUPR (mode 1) y y 111 SRALM y y 1~0 EPUK y y 112 IPRNG y y 131 IPUK y y 113 EPS y y 132 IPRK (input ~) y y 114 ECFAR y y 133 IPRK (input 1) y y 115 EIS y y 134 RTNPMK y y 116 SAF y y 135 RTCP~lK y y 117 UlDCC y y y 136 GKSP y y 118 LMOC y y y 137 IOK y y 119 LFPMKP (input 3) y y y 138 GADS y y 12~ LFP~lKP (input 1) y y y 139 GDS y y 121 CPllKP (input ~) y y y 14~ VDS y y 122 CPMKP (input 1) y y y 141 ECFER ~ y y y 123 GNPMK y y y 142 ICFER y y 124 GNDMK y y y 143 VIKU y y 125 CLNPMK y y 126 CLOPMK y y etr A counter specit~ing a number (I thru 25~) of perrnitted eYecutions of the inslruction or instruction-mode specified by inst-inde~c. This parameter is required only whellinst-inde,Y = 'CB,~IKP input-mode = O' or inst-inde.Y = 'CP.~IKI' input-mode = I' or inst-inde~c~ 'GPUPR mode = ()/2'.
r The length of V in bytes. This pararneter is required only when V is present.
V A p~rarneter eontaining proof of authorization. The specification of ~vhat V contains, the format of V, and the proeessing perforrned on V is not defincd by the l'EiCD. I his is an implementation choice. Tl~is parameter is optional and is needed only wllen re~luire(l by the irnplementation.
Outputs Dcscription CC Condition code indicating success or failure of the instruction eYecution.
DESCRlP'rlO~':
The Set Enable Flag instruction perrnits an E~f~BI.E flag associated with a particul.lr instruction or instruction mode to be set to one of its permitted E~ABLE flag values. The possible E~.~nEL tl;lg ~~lucs are (I) enabled, (2) enabled for I eYecution, (3) enabled for n e.Yeeution, ~vhere n is a number Irom I to '~, and (4) disabled.
The E?ir~BI E flag value supported by each instruetion vary. See the de~;nition of the tlag-v.ll par.lm-eter.
I he SEI instruction has no associated DEFII\E, ,~li I ll CO~TROL, A[J I II, .md 1'~.~131 1 tl~gi to control sr r instruction eYecution.
I he ~EF instruction e.~ecutes in the "init" and "run" states.

Instrl~tion l)roccsiin~/ 88 13T9-91-015 Reencieller To l~ v PI~A ~ ster l~e~ (RTI~P,~
207'i3Z9 CKDS Update l~eencipher To l~ew PKA ~l~ster Key (RTNPM~) EQUA'rlO~':
IKU1-length /16b/
IKU1 /unspecified/
IKU2 /unspecified/
CC /unspecified/
PARA.~I~I'ER r)EFl~lTlO~S
Inr~llts l)cscription ll~l, I-1en~th The length of IKU I in bytes.
Ilil,'l An Internal Key Unit.
O11tp11ts l)cscription An Internal Key Unit. The length of IKU2 in bytes is equal to IKUI-length.
CC Condition eode indieating sueeess or failure of the instruetion exec-1tion.

The Reencipher To l\'e-v PKA .~Iaster Key instruction reeneiphers an IKU from encryption undcr the current l'KA master }iey (CK~II') to encryption un~ler a ne~v l'KA master key (~'Ki~ll'). T he instruction operates only if the CKi\~fP FLAG and the ~Kl~IP FLAG are in the "full" states. .~lso, if CK.~IP h;3s been generated via the Gi\P.~/lK instruction, then the instruetion operates only if \Kl\IP has been generated via the G~P.~IK instruction.
The RT~\rl'i~,IK instruction executes only in the ~run" state.

Ins~ruction ProcessinY 89 BT9-91-015 Reencipher To Current PKA M;lster Ke~ (RTCPI~IK) Reencipher To Current PKA M~ster Key (i~CPMK) EQ UAT10~':
IKU1-length /16b/
IKU1 /unspeci fied/
IKU2 /unspeci fied/
CC /unspeci fi ed/
R~.~IETER l)EFl~'ITlO.~S:
~e~ l)cscription ll~UI-1cn~th The length of IKUI in bytes.
Ihljl An Intemal Kcy Unit.
OUtpllts Dcscription An Intcm.al Kcy Unit. The Icngth of IKU2 in bytes is cqu~l to IKI,'I-lcngth.
CC Condition code indicating success or failure of the instruction e.Yccution.
DESCRIPTIO~':
'I~he Reencipher To Current l'KA .~Iaster Key instruction reenciphers an IKU from encryption under the old f'KA master key (OK.~IP) to encryption under the current l'KA master ~ey (CK.\,IP). Thc instruc-tion oper~ltcs only if the OK.~IP FLAG and the CK;.\IP FLAG are in the "full" states.
The RTCP.~IK instruction e,Yecutes only in the "run" state.

Instruction Processin~ 90 131'9-91-015 C~nerate Pul)lic ~n(l Priv;lte l~e~ P~ir (CPUPR) 2Q7J1 ~29 Key ~Tan~gement Gener~te Pllblic ;lnd Priv~te Key P~ir (GPUPR) EQ~ I 10~':
gen-mode /2b minimum/
<codeword~ /128b/ ; if gen-mode=1 SKU1-length /16b/
SKU1 /unspecified/
SKU2-length /16b/
SKU2 /unspecified/
IKU1-length /16b/
IKU1 /unspecified/
cIKU2-lengthj /16b/ ; if gen-mode=O or gen-mode=1 ~IKU2~ /unspecified/ ; if gen-mode=3 or gen-mode=1 ~EKU2-length~ /16b/ ; if gen-mode=2 ~EKU2~ /unspecified/ ; if gen-mode=2 CC /unspecified/
P A R.~.\IEI'~ R l)~ lT10 ~ S:
Inpllts l)cscription g~n-mo~lc 'I'he gen-mode parametcr specifics the Deneration mode of the Gl'[ll'l~ instruction.
~ gen-mode = 0: PU and I'R are randomly generated. The generatcd (PU,PR) arc a (PUC,PRC), (PU.~,I,PR.~I), or (PUU,PRU). PU and PR are output as IKI'I and IKU2, respectively.
~ gen-mode= 1: PU and PR are generated from codcword, such that ~vhenever thc -same codeword is specified to the GPUPR instruction the same (P~',l'R) pair is gCII-erated The generated (PU,PR) is a (PUU,PRU) PU and l'R are output as IK~; I
an~l IKU2, respectively.
~ gen-mode= 2: PU and PR are randomly generated. The generated (PU,PR) is a (PUU,PRU). PU and PR are output as IKUI and EKU1, respectively.
codc-~ord A value using by the key generator to derive PU and PR.
SKI;I-length The length of SKUI in bytes.
SKI,'I A Sl;eleton Key Unit for to-be-generated PU.
Sl~ -lcngth Thc length of SKU2 in bytes SKI,'~ Skeleton Key Unit for to-be-generated l'R
Outputs l)cscription IKljl-lcn~tl1 The length of IKI~ I in bytes.
IK[~ n Internal Key l'nit con~aining generated PU. The ~~luc of l_lD in SCBI must equ;ll the value in the EID register. The value of Tc~cp in sCr3 1 must satisfy thc rclationship D T < Te.Yp, where DT is the current date and ti~ne eYprcssed in Coordinatcd [ ni-crs;ll 'rimc.
Il~[,~-l~n"tll 'I'he Icngth of IKI,2 in bytes. 'I'his paramcter is required only ~vhcn gcn-mode= () or gen-mode = 1.
I~1,7 r~n Internal Key .'.,'nit containing generated-PR. This parameter is required only ~-hen gcn-mode = O or gcn-mode = 1. The value of EID in SC132 must cqu31 thc value in S('13 1.
The values of Tstart and Te.Yp in SCB2 must equal the values of Tstart md 'I'e~p in SCB 1.
Ins~ruction Proccssin~ 91 13T9-91-015 Cener:lte Pulllic and Priv~te l~ey P~ir (GPUPR) 2Q7~29 EK~,'-lcngth The length of EKU2 in bytcs. This parameter is required only when gen-mode = 2.
EKU2 ~.n E:~tennal Key Unit containing generated PR. This parameter is rcquircd only ~~hcn gen-mode = 2.
CC Condition code indicating success or failure of the instruction e~cecution.
DESCRIP I'IO~:
The Gcncratc I'ublic and Private Kcy Pair instruction gcncratcs a public and private kcy p.air, I"(, an(l PR, and storcs each key in and Intcnnal Key l,'nit (IKU) or E.ctennal Key Unit (EKU) depcnding thc value of a gen-mode parameter supplied to the Generate I'ublic and Private Key Pair instruction.
For gen-mode = O, the gencrated keys can be a (PUC,PRC), (PU.~f,PR.~,I), or (I'UU,PRU) key pair.
~Iowever, to _enerate a (I'UC,PRC) pair, the device must be configured as a ccrtification centcr (i.e., CER-TIFICAT10~\ = E3 1 must be specified in the configuration vector). Both I'U and l'R arc output as Internal Key ~.nits.
For gen-mode= 1, the generated keys can be a (PUU,I'RU) key pair only. In this case, the ke~s are generate from :. 12~ bit code ~vord supplied to the Generate I'ublic and I'rivate Kcy l'air instruction. 130th PUU and I'RI, are output as Intennal Key ~nits.
For gcn-mode = 2, the generated keys can be a (PUU,PRU) key pair only. PUU is output as an Intennal Key l_nit and PRU is output as an E:~tennal Key Unit (i.e., I'RU is output in cle~r fonm).
The attributes of the to-be-gcnerated kevs, PU and l'R, are specified in Skeleton Key Units, S~l, l, and SKU2, rcspectively. Consistcncy checking is pcrfonncd on the control blocks and control vcctors in SKUI and SE~'(,2, prior to generating l'U and PR. Control vector fields such as .L~LGORITII.~,I, .~I.GO-RITI~ I E~TE~SIO~T, LE~GTI-I, DO.'vfAI~ ID must be the same for both PU and PR. The EID f;eld.
in SCBl of SliUI and the EID field in SCB2 of SKU2 must be equal to the value stored in the EID rc(rister of the CF (i.e., the EID value originally set using an LPID instruction).
The control vcctor fields ~LGORITII~f, ALGORlTI~f E~TENSION, and LE~TGTI-I specify to the cryptographic facility the public key algorithrn and other lcey generation information sufficient to pcrmit (PU,PR) to be generated.
The Gcnerate Public and Private Key Pair instruction e~cecutes only in the ~run statc.
Fl,~C~ lO~AL Sl'ECIFIC~TIO~':
1. Perforrn input parametcr consistency checking:
a. Vcrify gen-mode has value 0,1, or 2 b. Verify that S~l, I is consistent to definition of an SKU.
c. Verif~ that SKI,2 is consistent to definition of an SKU.
Continuc if chec};ing succeeds; other~isc set CC status tlag and jump to stcp 9.
2. Pcrform configuration ~ector and statc vector checking:
a. Vcrif~ that Cl~ S~ l E in state vector is in the ~run state.
b. Vclif~ that K.~ll'-Fl ~G(CK.~,fI') in state ~ector is in the fullV state.
c. If gcn-moclc = O or gen-mode = 2, then do:
I) Verif) that DEEI~\E(GPUPR mode=0/2) in config. vector = B'l'.
') Vcrit'~ that E~'r~Bl,E(GP~'PR mode=012) in state vector = B OO or B 10 .
d. If _en-mode = I then do:
I) V erif~ that I~EEI~'E(GPIUPR mode= I) in config. vector = B l .
') Vcril'~ that E~ BLE(GPUPR mode= I) in state vector = B'OO'.

InstrucLion l'roccssin~ 92 l3'r9-gl-ols Cenertte Pul)lic ;In~i PriY;ltc Ke~ P;lir ((~I'UPR) 207 .329 Continue if checking succeeds; other~vise set CC status flag and jump to step 9.
3. Perform control block and control ~ cctor checking. Continue if checking succeeds; othcr-~ isc sct CC
status flag and jump to step 9.
.. Generate Keys:
a. If gen-mode= 0 or gen-mode= 2, then perform PKA Key Generation to generate a pair of public and pri~ate cryptographic facility PKA records cfpkrl and cfpkr2, respeetively. The Iength of cfpkrl and cfpkr2 are sl and s2, respectively, ~vhere sl and s2 are pre-selectcd valucs that indicate thc number of 8 b~le blocks.
b. If gen-mode= 1, then perform l'KA Key Generation, with code-word supplied as an input, lo re-gcncrate a pair of public and private cryptographic facility PKA records cfpl~r I and cfpkr2, rcspcc-ti~ely. The Icngth of cfpkrl and cfpkr2 are sl and s2, respectively, whcre sl and s2 arc pre-sclccted values that indicate the number of 8 byte blocks.
5. Prepare outputs IKUI-length and IKUI:
a. Constr ict a key authenticator record cfkarl from the-key record cfpkrl, using the mcthod spccificd in Key Record Encrypt ~Ugorithm 12.
b. Construct a clear key unit CK~I from SKUI, cfpkrl, and cfkarl.
c. Set CK.~,IP := value of K.~,ll' ~torcci in the CK.~,II' rcgister.
d. Perform Encipher Clear Key Unit on CKUI to obtain an internal key unit IKUI, using C~.~IP ;3s the master key KI~IP.
6. Prepare outputs IKU2-length and IKU2, if gen-mode= 0 or gen-mode= 1:
a. Construct a key authenticator record ctkar2 from the key record cfp};r2, using thc mcthod spcci~icd in Kcy Record Encrypt tUgorithm 12.
b. Construct a clear key unit CKU2 from SKU2, cfpkr2, and cfkar2.
c. Perform Encipher Clear Key Unit on CKU2 to obtain an internal key Ullit IKI~, usino CK~ as the master key KMP.
7. Prepare outputs EKU2-length and EKU2, if gen-mode = 2:
a. Construct an e.~ternal key unit EKU2 from SKU2 and cfpkr2.
8. Perform state vector update:
a. If (gen-mode = O and E?~'ABLE(GI'UPR mode = 0/2) = B'10') or (gen-mode = 2 and E~'A13LE(GPUPR mode = 0/2) = B'10'), then do:
1) Dccrement COU~TER(GPUPR mode= 0/2) in Counter Table by 1.
2) If COU~'TER(GPUPR mode = 0/2) = 0, then rcset E~rABLE(GPUPR modc = 0/2): = B' I 1' (i.e., reset the E~'ABLE l~lag to the "disabled" state).
9. Produce output CC from CC status flags.
CO..~''I'ROL Bl.OCI~ ~D CO.~-'l'ROL ~'EC'rOR C~ CI~I~'G:
I'crform control block and control ~cctor checking:
I . E.~tract SC13 1 and C I from SKI,' 1:
a. E~tract thc system control block SCBI from SKI~I.
b. E:ctract control vector Cl from SCBI.
2. E.~tract scr32 and C2 from SKI,2:
a. E.~tract thc system control block SCB2 from SK[,'2.
b. E.~tract control vector C2 from SCB2.

3. Checking on Cl (associated ~~ith public key):

instruction Proc.~ssin~ 93 13rg-9l-ol~ C~n~r.lte Puhlic .ln~l Pri~ate 1~ Pair (CPUPR) 2Q7 ~2g a. If gen-mode=0, thcn ~erify CV TYPE in CI = 'public ccrtification kcy' or 'public kcy managcment key' or 'pubLic uscr key' b. If gen-mode= I or gen-mo(le= 2, then verify CV T YPE in Cl = 'public user key' c. Verify RT~'P.\,[K/RTCI'~IK in Cl = B'l' (i.e., 'enabled') d. Verify l{IST-IPI,~ in Cl = B'0' (i.e., 'not imported') 4. Chccking on C2 (associatcd ~vith private key):
a. If CV TYPE in C2 = 'PRU', then verify IIIST-IPRK in C2 = B'0' (i.e., not importcd via IPRK
instruction) b. Verify RT~P.~IK,RTCP.~,IK in C2 = B'l' (i.e., 'enabled') 5. Checl;ing on Cl and C2 (i.e., for a PUC/PRC, PU.~ljPR~I, or PUU/PRU):
a. Verify (CV 'I'YI'E in Cl) ~OR B'000l000' = (CV TYPE in C2) b. Verify (;~LGORITII~I in Cl) = (ALGORITII.~I in C2) c. ~,'erify (.-~LGORITI~ I E~TEi\S10~\' in Cl) = (t~LGORlTI~ I E~CTE~S10~\' in C2) d. Verify (LE~GTI-I in Cl) = (LE~G'I'I-I in C2) e. Verify (DO~ ID in Cl) = (DO~IAI~ ID in C~) f. Verify (PR I~S.~GE in Cl) = (I'R USAGE in C2) g. Vcrif'y (l'U l,S.~GE in Cl) = (I'U liS~GE in C2) 6. Chccking on Cl and configuration ~ector:
a. If CV TYPE in Cl = 'public certification key', thcn verify CERTIFrCATIO~' in conf;g. vector =
B' l' (i.e., certification center).
b. If (CV TYI'E in Cl = 'public key management kcy') and (KREG.~IOL)E in Cl = B'01'), then verify I~REG in config. vector = B'0'.
7. Checking on C2 and configuration vector, if CV TYPE in C2 = 'pri-ate key management key':
a. Verify TIIRES-.~,IDC in C2 > FLOOR-.~IDC in conflg. vector.
8. (optional) Checking on SCB l:
a. (optional) Verify that the current date and time is less than the eYpiration time Te~cp specified in SCB 1.
b. (optional) Verify that the Environment ID stored in the EID register is the same as the Environment ID stored iII SCBI.
~'ote: : Tstart, Te~cp, and EID are checked only ~vhen an IKU is used.
9. Checking on SCB I and SCB2:
a. Verit'y that the values of Environment ID stored in SCBl and SCB2 are the same.
b. Verify that the values of Tstart stored in SCB1 and SCB2 are the same.
c. Verify that the values of Te~cp stored in SCB I and SCB2 are the same.
Continuc if chccking succeeds; othcr vise sct CC status flag and jump to stcp 9.

Ins[ruction l'roccssinc 9 13T9-91-015 E~;port l'lIl)lic l~y (EPUI~) 207 .~29 E~port Public Key (EPUK) EQUATIO~r:
PU-mode /lb minimum/
PR-mode /2b minimum/
<hash-rule> /3b minimum/ ; if PR-mode=2 or PR-mode=3 <IKUl-length> /16b/ ; if PU-mode=~
~IKUl> /unspecified/ ; if PU-mode=C
~IKU2-length> /16b/ ; if PR-mode=2 ~IKU2> /unspecified/ ; if PR-mode=2 C3 /128b/
EKU3-length /16b/
EKU3 /unspecified/
~dsigl-length~ /16b/ ; if PR-mode=2 or PR-mode=3 ~dsigl~ /unspecified/ ; if PR-mode=2 or PR-mode=3 CC /unspecified/
PARA.~IETER DEF~'l'rIO~S:
Inputs l)cscription PU-mode The PU-mode parameter specifies the source of the public key to be e:cported, as follo~s:
~ PU-mode=O: use I'U in IKUI
~ I'U-mode= 1: use PUA in CF
PR-modc The PR-mode parameter specifies whether a digital signature is generated and, if so, then also the source of PR.
~ PR-mode = 0: no ~ PR-mode= 1: reserved ~ PR-mode= 2: yes, use PR in IKU2 ~ PR-mode= 3: yes, use PRA in CF
h~sh-rule Specifies the hash algorithm to be used to calculate a hash value on EKU3. The encoding of the hash-rule is as follows:
~ hash-rule = 0 m~IDC-2 algorithm ~ hash-rule = 1: ~tDC-4 algorithm ~ hash-rule = 2: ~ID4 algorithm ~ hash-rule = 3: quadratic residue ~ hash-rule = 4-7: rescrved This p~rameter is required only when PR-mode= 2 or I'R-mode = 3.
IKUI-I~n~th rhe length of IKUI in b~tes. This p.~rameter is requircd only ~vhen l'[ -modc= O.
IKUI ~n Internal Key Unit containing PU. This parameter is require(l only ~vhen PU-mode= O
l\o checl;ing is pcrformed on the EID, Tstart, and Te~cp ficlds in SCB 1.
IKIi'-lelI"~ttl The Icngth of IKI,2 in bytes. T his parameter is requircd only ~vh;~ll I'R-moclc = 2.
IKI,' ,~n Intcrnal Kcy Unit containing PR. This paramcter is rcquircd only ~vhcn I'R-modc= 2. Thc value of EID in SCB2 must equal thc v.llue in thc E ID rcgister. Thc values of Tstart and Te:~p in SCB2 must satisfy the relationship Tstart < DT < rc~p, ~vhere VT is the current date and time e.~pressed in Coordinate(l Uni~ers.ll Time.

C3 ~ 16 byte control ~ector for to-be-e.~portcd l'U.

Ins~rucLiOn r~rOccSSin~ 9 13 rs-sl-ols E~port Pubiic Ke~ (EPUl~) 207~329 Outputs Dcscription EKU3-length The length of EKU3 in bytes.
EKU3 An External Key Unit eontaining the e~cported PU.
~sigl-1ength The Icngth of dsigl in bits. This parameter is required only when PR-mode= 2 or PR-mode= 3.
dsigl A digital signature produced from a CF System Signature Record (CFSSR) and a private key PR, in aceordanee with seetion 6 of lSO DIS 9796. The C~SSR contains a 12~-bit hash value calculated on EKU3. rhis parameter is required only when I'R-mode = 2 or PR-mode= 3.
CC Condition code indicating suecess or failure of the instruction e~cecution.
DE:SCRIPTIO~:
The E~port Public Key instruction (I) translates an Internal Key Unit containing public key p~T to an E,cternal Key l,nit containing PU (I'U-mode = O) or (2) it constructs an E,~tem~l liey Unit for the internally stored key PUA (PU-mode= 1).
The E,Yport I'ublic Key instruction has options for outputting the constructed E~ternal Key l,nit (I) without a digital signature (I'R-mode= O), (2) with a digital signature generated ~vith a l'R supplied to the E~cport Public Key instruction (PR-mode= 2), or (3) ~ith a digital signature generated ~vith the intcrnally stored key l'RA (I'R-mode = 3). The private key I'R used ~vith PR-mode = 2 can be a l'RC, I'R.\.I, or l'RI ' key. IIowever, to gencrate a digit~l signature ~ith private key PRC, the device must be configured as a certification center (i.e., CER I II~IG~I IOI\ = B l must be specified in the configuration vector). A hash-rule parameter indicates to the EPI,K instruction the hash algorithm to be used in generating the digital signature.
Control vectors Cl, C3, and C4 are all associated with the PU to be e,~ported. Cl is stored either in IKUl (PU-mode= O) or in the PUACV register (PU-mode= 1). C4 is stored in EKU3, and C3 is an inter-mediate value uscd by the CFAI' to request changes to Cl, as follo-vs. ~Vhen a I'U is e~ported, the Cl t~P
is permitted, in certain cases, to change control vector fields. If no change is desired or no ch:3nge is per-mitted, then the CI~AP sets C3 := Cl, else the CI~AI' produces C3 by making selected changes to Cl. rhe control vector checking process assures that C3 is properly specificd. Likewise, when a PU is exported the CF is perrnitted to chan,e certain control vector fields. If no change is needed or prescribed, then the Cl~
scts C4 := C3; else the Cl~ produces C4 by making selected changes to C3.
The E~port Public Key instruction e~cecutes only in the "run state.
Fl,~;C rlO~'AL SPECIFICA I IO~:
1. Perform input parameter consistency checking:
a. Verify l'R-mode has value 0, 2, or 3 b. If 1'~-mode = (), then verify that IK1,'1 is consistent to definition of an 1KU
c. If PR-mode= 2, then verify that IKU2 is consistent to dei~nition of an IKU
Continue if checking succeeds; other-~ise set CC st~tus flag and jump to step 9.
2. Perforrn configuration vcctor and state vector checl;ing:
a. Verify that l)EI'l~E(El'l,K) in config. vector = B l .
b. Verify that C~ S r,~TE in state ~ector is in the 'run ' state.
c. Verifv that El\ABLE(EPl,'K) in state ~ector = B OO .
1. Verify that K~IP-I~LAG(CK.~,IP) in st~te vector is in the full" state.
Continue if checl;ing succeeds; other~-ise set CC status llag ~nd jump to step 9.

InsLruc[ion l'roccssing ~)6 13T9-91-015 E.~port Pul)lie l~e! ( EPU~) 3. Perform control block and control vector checking. Continue if checking succeeds; othcr vise set CC
status flag and jump to stcp 9.
4. Construct outputs EKU3-len2th and EKU3, if PU-mode= 0:
a. Set CK.~IP := value of Ki~,lI' in the CK~IP register.
b. Pcrforrn Recover Clear Key Unit on IKUI to recover a clear key unit C~l,JI, usin~ CK.~II' as the master key K.~IP.
c. Construct control vector C4 from C3.
d. Construct an eYtcrnal key unit EKU3 and its Icngth EKU3-lcngth, from CKUI and C~.
5. Construct outputs EKU3-length and EKU3, if l'U-mode= 1:
a. Construct control vector C~ from C3 b. Construct SC13 for an eYternal key unit, from C4 and Environment ID.
c. Construct external key unit EKU3 and its length EKU3-len2th, from the the l;ey record of the PUA
storcd insidc the CF and from thc SCB.
6. Producc outputs dsigl-length and dsigl, if PR-mode= 2:
a. EYtract control vector C from IKU2.
b. Calculatc a hash value on EKU3, using the hash al~lorithm specificd by input hash-rulc.
c. Construct a crypto;,raphic facility system signature record cfssrl from h~sh-rule and the calcul:.lcd hash ~alue.
d. Calculate digital signature dsigl on the eonstructed cfssrl, using the pri-ate l;ey storcd in llil,'.
7. I'roducc outputs dsigl-length and dsigl, if PR-mode= 3:
a. Calculate a hash valuc on EKU3, using the hash algorithm specified by b. Construct a cr~pto2raphic facility system signature record from hash-rule and the calculatcd ha~h value.
c. Calculate diaital signature dsigl on the constructed cryptographic facility s~stem si2nature record, using the private authenticator key stored inside the CF.
8. Perforrn state vector update: NTone.
9. Produce output CC from CC status flags.
CO~ l ROL BLOCK A~D CO.~TROL VECTOR Cl-IECl~ G:
Perform control block and control vector checking:
1. EYtract SCB1 and Cl from IKUI, if PU-mode=0:
a. EYtract the system control block SCBI from IKUI.
b. EYtract control vector Cl from SCBI.
2. E,Ytract Cl from Pl,'ACV regrister, if PU-mode= 1:
a. Sct C 1: = 16 byte control vector in the PUACV register.
3. EYtract S( B2 and C2 from 1~U2, if PR-mode= 2:
a. EYtract thc system control block SCB2 from IICI,12.
b. E.Ytract control vector C2 from SCB2.
4. E.Ytract C2 from PRACV register, if PR-modc= 3:
a. Sct C2 := 16 b~te control vector in the PRACV register.
5. Checking on C I (associated ~vith PU to-bè-eYported), if PU-mode = 0:

a. Vcrify CV rYPE in Cl = B'l I IOY.~' (i.e., a public PKt~ ke~) 6. Checking on Cl (associated ~vith P~,~ to-be-eYported), if Pl,-mode= 1: none Instruction Pro-cssin7 97 131 9-9 1 -o I ~ E.~;port Pul)lic ~ey ( E P Ul~) 207a329 7. Chccking on C2 (associated with PR), if PR-mode= 2:
a. Verify CV TYPE in C2 = B'l 111~' (i.e., a private PKA key) b. Verify EPUK usage bit = B'l' (i.e., enabled) c. Perform Control Vector Validate on Cl to validate certain fields in Cl.
8. Checking on C2 (associated with PRA), if PR-mode= 3:
a. Verify EPUK usage bit = B'l' (i.e., enabled) 9. Checking on C I and C3:
a. Vcrify C3 = C 1.
10. Checking on C2 and configuration vector:
a. If CV TYPE in C2 = 'private certification key', then ~erify CERTIFIC~TIO~ in conf;g. vector =
B' I' (i.e., certification center).
I l . (optional) Checking on SCB 1, if PU-mode = 0:
a. (optional) Verify that the current date and time is less than the expiration time Texp spccified in SCB I .
~'otc: : Tstart, Texp, and EID are checked only when an I~U is used.
12. Checking on SCB2, if PR-mode= 2:
a. Vcrify that the current date and time are in the timc inter-al (Tstart,Te.Yp), spccificd in SCB2 (i.e., Tstart < DT < Te.Yp).
b. Vcrify that the Environment ID stored in the EID register is the same as the En-ironmcnt ID stored in SCB2.
Continue if checking succeeds; otherwise set CC status flag md jump to step 9.

InsLrucLion Processin~ 98 . BT9-91-015 lmport P~ ic ~e~ (IPU~) 207~32~
Import Public }~ey (IPUK) EQU~T10.~:
import-mode /lb minimum/
~MDC-mode~ /lb minimum/; if import-mode=3 ~M~C-index> /5b minimum/; a) if import-mode=a ~ ~lDC-mode=C
~ EKU1 contains a PUC key b) if import-mode=C & MOC-mode=1 chash rule> /3b minimum/; a) if import-mode=C ~ M~C-mode=C
& EKU1 contains a PUC key b) if import-mode=C & MDC-mode=1 signature-mode /2b minimum/
EKUl-length /16b/
EKUl /unspecified/
~dsigl-length~ /16b/ ; if signature-mode=C
~dsigl~ /unspecified/; if signature-mode=C
clKU2-length~ /16b/ ; if import-mode=1 & signature-mode = (C, 1) <IKU2> /unspecified/ ; if import-mode=l & signature-mode = (O, 1) C3 /128b/
IKU3-length /16b/
IKU3 /unspecified/
CC /unspecified/
~ 11,R ~ E~1~II10 ~'S:
Inpllts l)cscriptioll import-mo~le specifies the mode of publie key import as follows:
~ import-mode=0: The public key in EKUI is irnported as a root PU.
~ import-mode= 1: The public key in EKUl is imported as a suceessor Pl,'.
~lI)C-mo(le Specifies the .~IDC processing mode, as follows:
~ ~iDC-mode = 0: If EKU I contains a l'UC key, then an .\/IDC calculated on EKI, l is loaded into EKUMDC Table. (The EKU.\;IDC Table cntry must be uniniti31ized.) Othervise, if EKUI contains a PUA, I'U;~il, or PUU key, no l~fDC is loacled.
~ l~,IDC-mode= 1 :.\/IDC calculated on EKUl is validated a~,ainst an ~IDC ~alue in the EKU.~IDC Table. (The EKl,rMDC Table entry must be preinitialized.) The MDC-mode parameter is required when import-mode= 0.
~'ote: The hash-rule parameter specifies the hash al~,orithm to be usecl in calculatin~, an C on EKUI.
.~lI)C-in-lex 'l~he ~IDC-inde~c parameter specifics a number n = 0,1,...,16, ~vhere n refers to EK~ ~lDC(n).
This parameter is required ~vhen (a) import-mode = 0, ~IDC-mode= 0, and EKI,'I
contains a PUC key, or (b) import-mocle = 0, .~lDC-mode - 1. For case (a), .~lDC-inde c must be a value 0, 1, ..., IS. For case (b), .~lDC-index must be a value 0, ..., IS, ~hen EKUI contains a I'UC key ancl .~lDC-incle:~ must be value 16 ~hen L~KI'I contains a PU~, I'U.\~I, or Pl,'U key.
h,~sh-rllle Specifies the hash al~,orithrn to be used to hash the E.~;ternal ~ey l,nit EKI,'I. The encoclin~ of the hash-rule is as follo-vs:
~ hash-rule = 0: .~,IDC-2 algorithrn ~ hash-rule = 1: ~IDC-~ algorithm Instruction l'rocessinJ 99 1319-91-015 Import Puhlic l~e~ (IPUl~) ~75329 ~ hash-rule = 2: .~ID4 algorithm ~ hash-rule = 3: quadratie residue ~ hash-rule = 4-7: reserved This parameter is required when (a) import-mode = O, ~IDC-mode = O, and EKI, I
contains a I'UC key, or (b) import-mode = O, MDC-mode = 1.
sign~ture-molle Specifies the signature processing mode, as follows:
~ signature-mode= 0: system signature (checked by CF) ~ signature-mode= 1: application signature (checked by CFAP) ~ si(rnature-mode = 2: no sign~ture Signature-mode = 2 may be specified only when import-mode = O. That is, a publickey imported ~vith signature-mode= 2 (no signature) must be a root l'U.
The following proeessing is indicated by signature-mode and import-mode:
1. E~or signature-mode = O and import-mode= O, the system signature, dsigl, is verified by the CF using the PU in EKUI.
2. E~or signature-mode = O and import-mode = 1, the system signature, dsig I, is v erified by îhe CF using the E'U in IKU2.
3. For signature-mode= I and import-mode= O, an application si~ature is verified by the CFAE' using the I'U in EKUI.
4. I~or signature-mode= I and import-mode= 1, an application signature is verified by the CFAP using the I'U in IKU2.
l~KUI-lcll~,th The len~th of EKUI in bytes.
E~UI An E.Yternal Key Unit containing the to-be-imported PU. For import-rmode= O, Te:;p in SCB I must satisfy the relationship DT < Te.Yp, where DT is the current d~te and tirne expressed in Coordinated Universal Time. This is because the to-be-imported E'U is used to verify a ~ eak signature generated on EKUI.
dsigl-length The length of dsigl in bits. This parameter is required only when si~,nature-mode= O.
dsigl A digital signature produced from a CF System Si~nature Record (CFSSR) and a private key PR in accordance with section 6 of ISO DIS 9796. The CFSSR contains a 12S-bit hash value calculated on EKUI. This parameter is required only when signature-mode= O.
IKU2-Iength The length of IKU2 in bytes. This parameter is required only ~vllen import-mode= I and signature-mode = (O or 1).
IKU2 ~n Internal Key Unit containing PU. The values of Tstart and Te~cp in SCB2 must satisfy the relationship Tstart < DT < Te~p, where DT is the current date and time e~pressed in Coordinated l,niversal Time. This parameter is rcquired only ~vhe import-mode= I and signature-mode=(O or 1).
C3 A 16 bSte control vector for the to-be-imported ru.
OUtl)llts l)~cscril)tion IK~3-I~elIhtll Ihe Icn~th of IK'(,'3 in bStes.
IKI,3 .~n Internal Key [,nit cont~ininD the irnported Pl,r.
CC Condition code inclic~ting success or failure of the instruction e;;ecution.
I)l.SCl~ll' l 10~:
l~he Import l'ublic key instruction translates an E,~tern~l ~ey l,nit containinr~ a public key 1"(, to ~n Internal ~ey l nit contaiIlin~;r PU. The imported Pl, can be a PU.~, PUC, I'l,.~I, or P'(,'L,. A 1"(, imported InsLruction Proccssin~ i 00 2 0 7 5 3 2 9 I~ )olt Plll)lic li~ (IPIJI~) ~vith import-mode = O is callcd a "root~ PU in a chain; a l'U imported with import-mode= I is callcd a "suc-cessor" I'U in a chain.
The E~cternal Key Unit can also have an attached digital signature (dsigl), which is validatcd usinD (I) the PU containcd in the E cternal Kcy l~'nit to be imported (impot-t-mode= O) or (2) a PU containcd in an Intemal Kcy Unit supplied to the Import l'ublic key instruction (import-mode= 1). The PU uscd to vali-date thc attachcd cligital signature can be a PUA, PUC, Pl,~f, or l'UU.
t~ signature-mode parameter indicates whether a system siDgnature is specified to the IPUK instruction (signature-mode = O) or whether a system signature is not specified to the IPUK instruction (signaturc-mode = I and signature-mode = 2). signature-mode= I indicates that an application signature is spccificd to, and checked by, the CF.~I'. signature-mode= I causes the II'UK instruction to e.cecute eYactly the same as signature-rnodc = O, eYccpt that the step of validating the system signature is omitted. For eYample, whcn import-mode= I and signature-mode= 1, history information is set in the control vector associated with IKU3 Usillg information in the control vector associated with IKU2, even though the PU in IKU2 is not used to validate a system signature on EKUI. The IPUK instruction assumes that the CF.~P uses the l'U
in IKU2 to validate an application signature on EKUI, and therefore the IPI,'K instruction uscs IKI 2 only to update IKI,3 as a ser-ice to the CFAP. Likewise, when import-mode= O and signaturc-mocle= 1, the IPUK instruction assumes th~t thc Cl ~1' uses the l'U in l KUI to valiJate an applicatioll si~n.lturc on EKUI, ;md thcrct'orc the ll~,'K instruction uses I~KUI only to upcl;3te IKU3 as a servicc to thc (~ 1'. On the other hand, signature-mode= 2 indicates that no signature is specit;ed to, and checked by, thc er .~P.
signature-mode= 2 is valid only when import-mode= O. Signature-mode= 2 can be specified only ~vhcn a root PU is importcd (i.e., ~vhen import-modc= O is specified). ~Vhen signature-mode = ', thc lI'~;li instruc tion sets the IllS'r-CI-lAI~\' tield = B'OO' in the control vector of the imported public key (i.c., the importcd PU key is always typed as a BRO~-ZE key).
A ficld in the configuration vector, deiign~ted SIG-CO.~IPATIBILITY(IPUK), indicatcs ~vhcthcr dsi,l is required (i.e., si nified by SIG-CO\;IPATIBILITY(IPUK) = B'O') or whether dsigl is optional (i.e., si_-nified by SIG-CO~IPATIBILITY(IPUK) = B'l'). For e~cample, when signature-mode= I or signature-mode= 2 are specified, the IPUK instruction ensures that SIG-CO.~II'ATIBILITY(II'UK) = B'l'.
~ Vhen a device is configured to specit'y SIG-COl\~lPATIBILI rY(lPUK) = B'O', the systcm si~,nature attached to the E.Ytemal Key Unit is produced at an origin~tino device (a) via an EPUK instruction, it thc origin~ting device is configured as an ordinary security module (i.e., I~TERCI-IA~'GE ficlcl in conf~,uration vector is B'O') or (b) via a GDS instruction, it' the origin,1ting device is specit'ally configured as an intcrchange device (i.e., Il\-rERCIIA~'GE~ field in configuration vector is 13'1'). EYcept when the originatin,, dcvice is an interchange dcvice, the IPUK instruction eYecuted at the receiving device ensures that an importcd l'l;~ I;cy with l-IIST-CIIAI~T= 3 must have originated with the same device as the rI~ ey used to validatc thc digital signaturc on that imported I'U,~ kcy.
For import-mode = O, an .~,IDC-mode parameter additionally specifics whcther the iml-ortcd l Ytcrnal Key Unit is validatcd a~,ainst an .\iIDC value in the ;.\IDC Tablc stored in the CF En-ironmcnt. ~ s storcd in thc .~II)C Table may be calculated Usillo eithcr .~II)C-2 or ;.~,I[)C-~ hash ;ll~orithnl. ~n .~lI)C-indcY par;lmeter specifies ~-hich entry in the .~II)C 'lable is used for valid;ltirl~ the importcd 1 1~1;. If EKU eontains a l'[,-C key, then ;\~lDC-indeY must have a value from O to 15, inclusive. It l.KI contains a I'UA, I'U.~I, or l'I -U key, then ~IDC-inde~ must have a v.llue of 16. T-lo--e-er, if import-mocle = ~), .~II)C-mocle = O, and EKI, eontains a PUC liey, then the IPl_K instruetion performs as tollo-~s: ( I) .~lI)C-inde:Y is set equal to the value of DO.~ ID in the l'I,C eontrol ~eetor, (2) it is ~erit;ed that EK~,:\,II)C Fl ~G(.~IDC-index) = B'OO', (3) an :\,IDC is caleulated on EKU and stored in l~K~ ,lDC(~lDC-incle.~c), and (~) EKU.\/IDC FLAG(.~,lDC-illde~c) is set equal to 13'01'. Ihe II'[ K proc-ejsino rules ensure that one and only one Pl,-C key can be imported for eaeh domain (DO.
Control vectors Cl, C3, and C~ are ~11 assoeiated ~ith the P~' to be imported. Cl is stored in r~
C~ is stored in IKI-3, and C3 is an intermediate value used b~ the CFAP to requejt chan~,es to Cl, ~s follo~s. ~Vhen a 1'[~ is imported, the CF.l~l' is perrnitted, in eert3in e~ses, to ehan,e eontrol ~ector t;ekls. If Ins~ruction Processir1t 101 2 0 7 i 3 2 9 Import Pulllic l;ey (IPUI~) no ehange is desired or no ehange is permitted, then the CF~L~P sets C3 := Cl, else the CFAP produees C3 by making seleeted ehanges to Cl. The eontrol veetor eheeking proeess assures that C3 is properly specified.
kikewise, when a PU is imported the C~ is permitted to ehange eertain eontrol veetor fielcds, e.g., to reeord import '11istory" about PU. If no ehange is needed or preseribed, then the CF sets C4 := C3; else the CF
produees C4 by making seleeted ehanges to C3.
The fundamental strategy followed in key import is to freely permit, rather than restriet, the key import proeess--eYeept that all releYant history and aetions pertaining to the key and to the key import proeess are reeorded in the eontrol veetor of the irnported key. Thereafter, ~- hen the };ey is used, the "history" informa-tion in the eontrol veetor is be tested to ensure that it meets ~vhatever minimum stanclard has been set forth.
Eor e.Yample, ~ hen used together with a private key in one of the key man;lgement instruetions, such as a GKSP or IDI~ instr lction, the logged ''history'V infonmation in the eontrol vector of the public key must be at Ieast as great as the threshold infonnation that has been encoded into the control ~ector of the private key at the time of key generation via the GP~'I'R instruetion.
The Import Publie key instruetion eYeeutes only in the "run" state.
~ I~'CTIO.~ L Sl'ECl~'lCA'rlO~':
1. I'erfonm input parameter consisteney eheeking:
a. If import-mode=0, then verify .~,lDC-mode= 0 or I
b. If import-mode= 0 and .\~lDC-mode= 1, then verify 0 < .\,tDC-inde:~ < 16.
e. Verify that E K U I is consistent to clefinition of ~n L~ K U .
d. If import-mode= 1, then verify that IKU2 is eonsistent to definition of an EKU.
e. If import-mode = 0, verify that signature-mode = 0, 1 or 2.
f. Else (import-mocle= I) verify signature-mocle = 0 or 1.
Continue if eheeking suceeeds; otherwise set CC status flag and jump to step 13.
2. Perforrn configuration vector and state vector eheeking:
a. Verify that CE STATE in state veetor is in the "run" state.
b. Verify that K.~/IP-FLAG(CK.~II') in state vector is in the "full~ state.
e. Verify that DEFli\'E(ll'UK) in config. vector = B'l'.
d. Verify that E~ BLE(IPUK) in state veetor = 13'00'.
e. If import-mode = O and ~IDC-mode = 1, then ~erify EDUl~ilDC FL~G(:~1DC-inde~;~ in state ~ ector > B'00'.
f. If si~,nature-mode= I or signature-mode= 2, then ~crify that SlG-CO.~ rll311,1'1'Y(11'1'~) in config. ~ ector = B' l '.
Continue if checking~ succeeds; other~ise set CC status flag and jump to step 13.
3. Perform control bloek and control ~ector checking. Continue if checking succeeds; other~vise set CC
status flag and jump to step 13.
4. Calculate .~,IDC on EKU3, using the hash algorithm specified by input hash-l-ule, if import-mc)de = O
and .~lI)C-mocle= 1.
5. Initiali~.e .~,II)C Table entry, if import-mode= 0 and ~IDC-mode= 0 al1d E}i~l contail1s a l'I 'C key:
If import-mocle = O and .\,lDC-mode = 0, then clo:
a. E.~tr.act the system control block SCBI from EKI_'I.
b. E~tr;lct the control ~ector Cl from SCBI.
c. If CV l'Yf'E in Cl = 'I)~JC ~ then do:
I) ~,'crify 0 < .~,lDC-inde~c < 15.
~) Set ,Y := ~alue of DO.~,IAI.\' ID in Cl (i.e., 0 to 15) 3) ~'erify ,~ 1 DC-inde.~
~) Veril~ E~ IDC ~ L.~G(.~lDC-in(le~) in state ~!eetor = B'00'.

Ins~rucLion Processing 102 131-9-91-015 2 0 7 ~ 3 2 3 Import Pul)lic l;e~ (IP~!

S) Continue if all of the above checking succeeds; other~vise set CC status flag and jump to step 13.
6) Calculate .~IDC on EKUl, using the hash algorithm specified by input hash-rule.
~ 7) Set EKU.~fDC FL~G(.~fDC-inde.~c) in state vector := B'01'.
8) Set EKUi~lDC(~lDC-index) in l\~IDC T~ble ~ ,fDC (i.e., .~fDC calculated above) 6. Validate MDC if import-mode= 0 and ~IDC-mode = 1:
a. Set .~,lDC-of-reference := EKU~fDC(.~fDC-index) in l~ifDC Table b. Verify ~IDC-of-reference = .~f DC (calculated above) Continue if checking succeeds; other vise set CC status flag and jump to step 13.
7. Construct e:Ypected record-codel to be referenced against record-code stored in cfssrl, if signature-mode= 0:
a. If import-mode = 0, then extract control vector C from EKUI.
b. If import-mode= 1, then e~ctract control vector C from IKU2.
c. Construct record-codel from control vector C.
8. I~ecover and valiclate cfssrl, if signature-mode= 0:
a. If import-mo(~e= 0, then recover cryptographic facility system signature record cfssrl from from diDital si~,nature dsigl, using the public key stored in EKUI.
b. If import-mode= 1, then recover cryptographic facility system signature record cfssrl from from digital signature dsigl, using the public key stored in IKU2.
c. Vcrify that cfssrl is consistent to definition of a cryptographic facility system signature record.
d. I xtr;lct hash rul~ hash-rulel from cfssrl.
e. Verify that record-code stored in cfssrl is the same as record-codel.
Continue if ehecking succeeds; otherwise set CC status flag and jump to step 13.
9. Calculate hash value l~fDCI on EKUI using the hash algorithrn specit'ied by hash-rulel, if signature-mode= 0.
10. Validate ~fDCI against reference ~fDCI in cfssrl, if signature-mode= 0:
a. E~ctract the hash value stored in the hash field in cfssrl.
b. Verify that i~/lDCI is the same as the e~;tracted hash value.
Continue if verification succeeds; other vise set CC status fl~g and jump to step 13.

11. Construct outputs IKU3-length and IKU3:
a. If import-mode = 0, then set C2: = C I
b. Set C4 := C3 and update history information (~IIST-IPUK, IIIST-CI~ !, EIIST-:\IDC, HIST-DO~IAI.\' ID, and H1ST-KREG.~,fODE) in C4, using the Control Vector Generate.
c. Replace the value of the control vector stored in EKUI with C4.
d. Construct a key authenticator record karl from the key record in EKU I, using the mcthod sp~citii d in Key Record Encrypt ~Igorithm 12.
e. Cvnstruct a clear key unit CKUl from EKUl and karl.
f. Set CK~II' := value of K~IP storcd in the CK;\,fP register.
g. I'erform Encipher Clear Key l,'nit on CKUl to obtain an internal key unit IKI,'3, using CK.~II' as the master key K.~IP

12. Perform state vector update: ~'one.

13. Produce output CC from CC status flags.
CO~''I'ROI l~l.OC~ A~D CO~''I'ROL ~'r;C'l'OR CIIECI~I~'G:
Pcrforrn control block ~nd control ~cctor chccking:

1. E.Ytract SC131 and Cl from EKI,'I:

InsLrucLion Proccssin~ 103 3'r9-91-01~ 2 0 7 ~i 3 2 9 Import PlJI)li~ }~e~ (IPUI~) a. Extract the system eontrol bloek SCBI from EKUI.
b. ~ Extract control vector C I from SCB I .
2. Extract SCB2 and C2 from IKU2, if import-mode= 1:
a. Extract system control block SCB2 from IKU2.
b. Extract control vector C2 from SCB2.
3. Checking on Cl (associated ~vith PU to-be-imported):
a. Verify CV TYPE in Cl = B'l I IO.~YY' (i.e., a publie l'KA key) b. If import-mode= O and .~IDC-mode= 1, then do:
I) If CV TYPE in Cl = 'PUC', then ~erify .~ifDC-index = DO:\IAI~' lD in Cl (i.e., a value O to 15).
2) If CV 'I'YI'E in Cl ~ 'PUC', then ~erify ;\lDC-index = 16.
~'ote: For impolt-mode = O, IPUK usage is not checked since the use of PU to validate a '- eak' signa-ture is al~vays implied.
4. Checl;ing on C2, if import-mode = 0: none ~'ote: The II'UE~ us~ge bit is not checked for import-mode= O, since the usage in this case is implied.
5. Checking on C2 (associated with PU used to validate sigrnature), if impon-mode= 1:
a. Verify CV TYPE in C3 = B'l I IO.~YY' (i.e., a public PKA key) b. Verify IrUK usage bit in C2 = 13'1' (i.e., enabled) c. I'erform Control Vector Validate on C2 to validate certain fields in C2.
6. Checliing on C I and C3:
a. VerifyC3=CI
~'ote: there are currently no fields in Cl that may be altered by CFAP.
7. (optional) Checking on SCB 1, if impon-mode = 0:
a. (optional) Verify that the current date and time is less than the expiration time 'I'exp specif~ed in SCB 1.
i~'ote: : Tstart, Texp, and EID are checked only ~vhen an IKU is used.
8. Checking on SC13 1, if import-mode = I (i.e., ~ hen l'U is the key being imported): no checking required 9. Checking on SCB2, if import-mode= I (i.e., ~ hen I'U is used to ~erify a 'strong' signature):
a. Verify that the current date and time lre in the time interval (Tstart,Texp), specified in SCB2 (i.e., Tstart < DT < Texp).
Continue if checking succeeds; othel~vise set CC status flag and jump to step 13.
In the above checking steps, it should be noted that import-mode = I implies that ( I) siOnature-mode = O or signature-mode= I and that (2) .In IKU2 is specified to the II'I'K instruction.

Ins~ruc ion l'roccssing 10 1 13 r9-91-ols ~ ~ 9 lmport Pri~t~ l~e~ (IPRl~) Import Priv~te ~ey (IPRK) EQUAT10~:
i nput-source /lb mi nimum/
<EKU1-length~ /16b/ ; if input-source=~
~EKU1~ /unspecified/ ; if input-source=û
IKU2-length /16b/
IKU2 /unspeci fied/
CC /unspeci fied/
R;~.~I L l'l~R l)l.l l~I I IO.~S:
Inputs Dcscription inp-lt-sollrcc The input-souree parameter specifies the souree of EKUl-length and 1 Kl 1, ;IS follo~s:
~ input-souree = 0: instruetion input ~ input-souree= 1: EKU buffer in CF Environment Ll~Ul-lcll~,th I'he lcngth of EKUI in bytes. This input is required if input-so-lrce = O.
EEiUI An EYternal Key Unit eontaining the to-be-imported PR. This input is require(l if input-souree = O. The value of EID in SCB I must equal the value in the EID register. I hc v31ue of Te~cp in SCB I must satisfy the relationship DT ~ Te~cp, w hcre D r is thc currellt date and time e~pressed in Coordinated Universal rime.
Olltpllts Dcscription Il~U~-Iength The length of IKU2 in bytes.
IKU2 An Internal Key Unit eontaining the imponed PR.
CC Condition eode indieating sueeess or failure of the instruetion e~ecution.
DLSCRIPTIO~':
The Impon Private Key instruction translates an E:~ternal Key Unit EKUI contailling a I'RU l;cy to an Internal Key Unit containing the PRU. An input souree parameter indieates whether EKUI is supplie(l as a parameter input to the Impon Private Key instruetion or whether it is read from the EKU buffer in thc CF Environment. An EKUI read from the EKU buffer must be loaded into the CF Yia a protectcd inter-face, e.g., a sman card reader.
The EID ficld in the System Control Bloek (SCB) of EKUI must be initialized with 16 ASCII 'O's or with a value equal to the ~alue stored in the EID register of the CF (i.e., the EID v;llue oli~in;llly sct U~illg an Ll'ID instruction).
The Impolt l'riv;3te Key instruction e:~ecutes only in the "run" state.

In~Lruc[ion l'roccssin~ I 0:~

13T9-91-015 2 0 7 Y 3 2 9 Cener~te f~e~ Set PI~A (C~SP) Gener~te Key Set PKA (G~SP) EQUAT10~:
process-mode /2b mi nimum/
domain-id /4b/ i if process-mode=(~ or 1) key-management-protocol /lb minimum/ ; if process-mode=(~ or 1) <key-management-mode~ /lb minimum/ ; if process-mode=(~ or 1), key-management-protocol=1 <PR-mode~ /lb minimum/ ; if process-mode=(~ or 2) <hash-rule~ /3b minimum/ ; if process-mode=(~ or 2), PR-mode=l <IKUl-length~ /16b/ i if process-mode=(~ or 2) ~IKU1~ /unspecified/ ; if process-mode=(~ or 2) <IKU2-length~ /16b/ i if process-mode=(3 or 2), PR-mode=l ~IKU2~ /unspecified/ ; if process-mode=(0 or 2), PR-mode=l <ticket-in~ /64b/ i if process-mode=2 <C3~ /128b/ ; i f process-mode=(0 or 1) <C4~ /128b/ ; i f process-mode=(0 or 1) <e*KM.C4(KKL)~ /64b/ i i f process-mode=(~ or 1) <e*KM.C5(KKR)~ /64b/ i if process-mode=(~ or 1) <keyblk-length~ /16b/ ; if process-mode=(0 or 2) <ePUM(keyblk)~ /unspecified/ ; if process-mode=(~ or 2) <dsigl-length~ /16b/ i if process-mode=(~ or 2), PR-mode=l <dsigl~ /unspecified/ ; if process-mode=(~ or 2), PR-mode=1 <ti cket-out~ /64b/ i i f process-mode=1 CC /unspeci fi ed/
rAR~ R l~EFl~'ITlO~'S:
Inputs l)cscription process-mollc specifies the instruction processing mode, as follows ~ process-mode= 0: produce outputs from inputs ~ proccss-mode= I: produce intennediate outputs from inputs ~ process-mode= 2: produce outputs from intenmediatc outputs ~lom:lin-i~l The domain-id parameter specifies a domain identifier that ranges from 0 to 15. ~Vhen C3 and C4 are 64 bit control vectors (E~TE~'SIO~' = B'00'), a value of domain-id= 0 must be specified. This parameter is required only ~vhen process-mode = (0 or l).
~cy-m~ clllcnt-protocol The key-management-protocol parameter specifies the protocol uscd for kcy m:magcmcnt, as follows:
~ key-management-protocol= 0: private protocol ~ kcy-managcment-protocol = l: cenification ccnter protocol This paramcter is requircd only when proccss-mode= (0 or l).
~cy-lll~n~"clllcllt-nlodc 'I'he kcy-management-mode parametcr specifics the mcthocl (callcd modc) uscd to rcgistcr a public kcy managcment };cy with thc certification centcr, as f'ollo-vs:
~ kcy-managcmcnt-modc = 0: kcy rcgistration is pcrfonncd usin, modc 0 ~ kcy-managcmcnt-modc= l: key rcgistration is pcrfonncd using modc l 'l'he cr~ does not dcfine the meaning of modes 0 and l. These modes arc dcf;ned on thc basis of the nct-vork kcy m~n~g~ment architecture, and (as far as thc C~ is con-ccnncd) can be ~vhatevcr a customer wants thcm to bc. I'his paramctcr is requircd only ~-hcn proccss-modc=(0 or 1) ~ld kcy-managcmcnt-protocol= l.

Instruc~ion l~roccssing 1 06 B r9-9l-ols 2 Q 7 ~~ ~ 2 ~ener~te l~e~ Set PKA (CI~SP) PR-mode Thc PR-modc parameter spccifics whcther a digital signaturc is gcncratcd and, if so, thcn also the source of l'R.
~ I'R-mode = 0: no ~ PR-mode= 1: yes, use PR in IKU2 This parameter is required only when process-mode = O or process-mode = 2.
h~ r1llc Spccifics the hash algorithm to be used to calculate a hash value on cl'U.~I(keyblk). The encoding of the hash-rulc is as follo~vs:
~ hash-rule = 0: ~TDC-2 algorithm ~ hash-rule = 1: \,IDC-~ al ,orithm ~ hash-rulc = 2: .~ID4 algorithm ~ hash-rule = 3: quadratic residue ~ hash-rule = ~-7: rescrved This paramctcr is requircd only when process-mode = (O or 2) and PR-mode = 1.
IKUI-lcll~tll Thc Icngth of IKI,'I in bytes.
'rhis par~metcr is rc4uircd only ~vhen process-mode= (O or ~).
Il~UI ~n Internal Kcy Unit containing a PU;\,f of another dcvice and belonging to domain-id.
'I'hc value of EID in SCBI must not equal the value in the EID registcr. The val~les of 'I'start and Te~cp in SC131 must satisfy the rclationship Tstart < D'l' < Tc~;p, whcrc l)T is thc current date ;md time e~;pressed in Coordinatcd Uni-ers;ll 'I'ime.
'I-his parameter is required only when process-mode= (O or 2).
Il~U2-lcngth The length of IKU2 in bytes. This parameter is required only when process-mode= (O or 2) and PR-mode= 1.
IKU2 An Internal Key Unit containing a PRM of this device and belonging to dom~in-id. The value of EID in SCB2 must equ31 the value in the EID re~ster. The values of Tstart and Te~cp in SCB2 must satisfy the relationship Tstart < DT < Te.Yp, where DT is the current datc and time e.~pressed in Coordinated Universal Time. 'I'his parameter is rcquircd only when process-mode= (O or 2) and PR-mode= 1.
ticket-in An 8-b,vte value that must be equal to the 8-byte value storcd in the GKSP-Tickct register in the CF. This pararneter is required only when process-mode = 2.
C3 A 16-byte control vector associated with the leftmost 64 bits of the key-encryptin(l recei-er key KK to be e~cported to a receiving cryptographic system. For process-mode= O, C3 .~,IUST be equal to the control vector stored in keyblk of output parameter ePU;\/I(keyblk). See control vector checking for a specification of C3. This paramctcr is required only ~vhen process-mode= (O or 1).
C~ A 16-byte control vector associated with KKL, ~vhere KKL, is thc lcftmost 6~ bits of thc liey-encrypting scnder kcy KK to be rctaincd at the gcncn1tillg cl~pto~rmphic systcm. 'I'his paramcter is requircd only when process-mode = (O or 1).
Outl)uts l)~scriptioll ~*I~.~I.(,'~(I;I~I,) 6~ bit ~;cy KKL enciphercd under 128 bit m~ster key K.~,I and 12~ bit control vcctor ('~.
KKI. is the lct't half of a 1~8 bit licy-encrypting key. This paramctcr is produccd only w hcn process-modc= (O or 1).
c*l~.~I.C~ R) 6~ bit key KKR enciphered under 128 bit master key K.~,l and 128 bit control ~ector C5.
KKR is thc right half of a 128 bit key-cncrypting kcy. This parameter is produced only ~vhen process-mode= (O or 1).

Instruction Proccssing 107 13-1-9-91-015 0 ~ " ~ 2 9 Gener.lte Ke~ Set PI~A (Cl~SP) ~c~blk-lcllgtll The length of keyblk and ePU.~I(keyblk) in bits. This parameter is produccd only ~vhcn process-mode = (0 or 2).
~PU~I(kcyblk) keyblk encrypted with public key l'I,'.~I of another de-ice. I or process-mode= 0, keyblk is a key block produced from a Crypto Facility DEA Key Record (Cl DKR). For process-mode = (1 or 2), keyblk has an unspeeified format. This parameter is produccd only when process-mode = (0 or 2).
~sigl-lcngth The length of dsigl in bits. This parameter is produced only ~vhcn process-mode= (0 or 2) and PR-mode= 1.
dsig1 A digital signature produced from a CF System Signature Record (Cl SSR) and a private key m.~n~g~ment key PR.~I of this device, in accordance with section 6 of ISO DIS 9~96.
The CFSSR contains a 128-bit hash value calculated on cl'U.~I(cfbdkbl). This parameter is produced only when process-mode= (0 or 2) and l'R-mode= 1.
tickct-o~lt ~n 8-b~te value equal to an 8-b~te value stored in the GKSP-Ticket rc ,ister in tlle Cl~.
This parameter is produced only when process-mode = 1.
CC Condition code indicating success or failure of the instruction eYecution.
l)k;SCRII' I 10~:
The Generate Key Set PKA instruction generates t~vo encrypted copies of a l~-bit key-encrypting key, KK = (KKL, KKR), where KKL and KKR are the left and right 6~-bit parts of KK. The first copy, which is encrypted with the master key, is for local use at the generating de~ice. rlhe second copy, wllicl- is encryptcd with a public key management key, is distributed to a receiving dcvicc w}lcre it is impolted with and IDK instruction. At the generating device, KK is designated (via a control vector) to be a key-cncryptillg scnder key with a GKS OP-E~ attribute. ~t the receiving device, I~K is designated (-ia a control vector) to be a key-encrypting receiver key with an RT.~,IK attribute. (~'hen the receivin~ device docs not implement PKCD or control vectors, KK usage must be controlled via other means.) The EXl'OR r CO~ I ROL field in the control vectors associated ~vith KK must also specify no e.Yport.
I'hc fLrst cncrypted copy of KK has the form e*K.~I.C4(KKL), e~KI~iI.C5(KKR), where e*K.\,l.C4(KKL) and e*K.\/I.CS(KKR) are the encrypted left and right 64-bit parts of KK, respecti-cly.
K:\ I.C~ and K.~l.C5 are variant keys formed as the Exc}usive-OR product of master key K:\ I and control vectors C4 and CS, respectively. C4 and CS are control vectors associated with KKL and KKR, respec-tivcly. I he sccond encrypted copy of KK has the fonm eI'U.~,I(keyblk), where ~ I is thc public key m;m-ag~clllcnt kcy of the rccciving device and keyblk is a key block containing KK.
~ proccss-mode parameter providcs different processing options within thc GKSP instmction. ~rhcn proccss-mo ;Ie = O is spccificd, keyblk is key block produced from a Crypto Facility DEA Key Recor(l (Cl l)KR). I hc fonnat of the CI DKR and the algorithm for producing keyblk from CFDKR arc li_idly def;ned by l'K( D. I'rocess-modes I and 2 pennit a keyblk with unspecified format to be processed. I his is ~ccomplis}lcd hy invoking the GKSP instnuction with process-mode= I to producc ~ er DliR storcd ~vithin thc Cl, thcn in-okin~ a rr;mslatc-from-CFDKR instruction which translates Cl ~KR to a specit;c(l kcy block (kcyblk) also storcd ~vithin thc Cl, and t;nally invoking the GKSI' instnuction ~vith proccss-mo-lc= ' to take thc so-translated keyblk and encrypt it ~vith the public key management key, I'U.~I, of the rcccivin, de~icc. I hc aim of proccss-modcs I and ~ is to remove the translation step f'rom thc GKSP instnlction, so th;lt thc GKSP instnuction nced not directly implement a host of diffcrent possiblc trallslation options t'or compatibility ~- ith othcr non-l'K('V dcviccs. ,~ si~,nific;mt advanta( e c;m be achic-e~l if thc I ransl;ltc-from-Cl:VKI~ instruction is implemented within a progrrammable memory \vithin the Cl:.
I-hc Gcncrate Key Set l'K.~ instmction has options for generating a s~stem signature, dsigl, on output cl'~,~l(kcyblk) (I'R-mo(lc= I) or not gcnerating a system signature on output el'l :\I(keyblk) (I'R-mo(lc= 0). ~'hen l)R-mo(le= I is specified, a private key management key, I'R.~I, belon~ring to the lnslrucLion l~roccssing 10~3 131'9-91-015 C~n~r;lte l~c~ Set PI~A (C}~SP) 2!~7~329 sending device is used to generated the s~stem signature. ~ hash-rule parameter indicates to the GKSP
instruction the hash algorithm to be used in generating the digital signature.
The Generate Key Set l'KA instruction e.l~ecutes only in the "run" state.
Fl,~;CTlO~'~L SPECI~'IC~'I IO~':
1. Verify process-mode = O, 1, or 2. If verification fails, set CC status flag and jump to step 13.
2. V31idate ticket-in, and extract fields from CF Environment, if process-mode = 2:
If process-mode = 2 then do:
a. Vcrify GKSI' Buffer Flag in CF En-ironment = 2 or 3. If verification fails thcn set CC status flag and jump to step 13 b. Verify ticket-in: = value stored in GKSI' Ticket fiel~d in C~ Environment. If verification fails then set CC status tlag and jump to step 13 c. Set domain-id := bits 00..03 of GKSP Save field in CF Environment d. Set key-man3._ement-protocol := bit 04 of GKSP Save field in Cl~ Environment e. Set kcy-management-mode := bit 0~ of GKSI' Save field in CF En-ironment.
3. I'crform input parameter consistency cheeking if process-mode = O or 2:
If process-mode = O or process-mode = 2 then do:
a. Vcrify l'R-mode = O or I
b. Vcrify that I K I,- I is consistent to definition of an I K U .
c. If l'R-mode = 1, then verify that IKU2 is consistent to defulition of an IKU.
Continue if checking succeeds; other vise set CC status flag and jump to stcp 13.
4. Perform configuration vector and state vector checking:
a. Verify that DEFI~'E(GKSP) in config. vector = B'l'.
b. If key-management-protocol= 1, then K;\/lGT PROTOCOL in config. vector = B'l 1' or B'10'.
c. If key-m~n~gement-protocol= I and key-management-mode= O, then KREG in config. ~ector =
B'O'.
d. If key-management-protocol = O, then Kl~,IGT l'ROrOCOL in config. ~ ector = B' l l ' or B'O 1'.
e. Verify that Cl~ STi~TE in state vector is in the "run~ state.
f. Verify that K:~,lP-l~L~G(CKi\~P) in state vector is in the "full" state.
g. Verify that CK;\/I I~LAG in state vector is in the ~full" state.
h. (optional) Verify LI'ID FLAG in state vector is in the "full" state.
i. Verify that E~ABLE(GKSP) in state vector = B'OO'.
Continue if checking succeeds; otheru~ise sel CC status ilag and jump to step 13.
5. I'erfonn control block and control vector checking. Contulue if checking succeeds; othcru ise sct CC
status flag and jump to step 13.
6. Construct a rccord code record-codel for cfdkrl based on par;lmeters key-man;l ,emcnt-protocol alld liey-rnana~ement-mode, if process-mode = (I or process-mode = 1.
7. Construct cfdkrl if process-mode = O or process-mode = 1:
a. Gcnerate a 12S-bit random l;ey ~K consisting of a 61-bit Icft half KKL alld a 6~-bit ri_ht half ~KR.
b. ,~djust parity of KK to odd parity c. Set EID := contents of the ~ID register in CF Environment.
d. Construct the crypto~aphic facility l)E~ key record cfdkrl bascd on KK, EID, C3, and record-code I .
S. I'roducc outputs e$K~l.C~(KKL) and e~K.~l.C~(KKR) if process-mode = O or process-mode = 1:

Instruction Proccssing 1 O~) u~r9-91-015 2 n 7 ~ 3 2 9 ~ener~te l~e~ Set P~ (GI~SP) If proccss-mode = 0 or proccss-mode = I then do:
a. Set K.~l := contents of CK~I Register in the CF Environment.
b. Exclusive-OR K.~f to C4 and use the resulting key to encrypt KKL.
c. Sct C5 := C~ and invert the values in bits 41 and 42 in C5 (i.e., adjust the KEY ~OR.~I ficld in C5).
d. E~cclusive-OR K.~/f to CS and use the resulting key to encrypt KKR.
9. Produce output ticket-out and store parameter values in CF Environment if proccss-mode = 1:
If process-mode = I then do:
a. Gcneratc a 6~-bit random numbcr and assign it to ticket-out.
b. Sa-e paramctcr valucs in CF Environment:
I) Scl GKSI' Ticl;ct ficld in CF Environment := ticket-out 2) Set GKSI' Save field in CF Environment := domain-id 1I key-management-protocol 11 key-managemcnt-mode 11 B 00 3) Set GKSI' Buffer Flag in CF Environment: = 1.
4) Sct GKSI' Buffcr ficld in CF Environment := 4I6-bit cfd~rl (left-justified in GI~SP Butfcr field).
S) Sct GKSP Rccord Lcng~th ficld in CF Environmcnt := 416 6) Sct GKSP Buffcr Lcng~th field in CF Environment := value of G~SI'-buffcr-lcn ,th in Config-ur.~tion Table.
10. Producc outputs licyblk-lcngth and cPU:~I(keyblk) if process-mode = O or proccss-modc = ':
a. If proccss-modc = 0 tllcn do:
I) Sit key-process = I
2) Sct cfdkrl-lcngrth:= 416 b. If process-mode = ~ then do:
I) Set key-process := value of GKSP Buffer Flag in CF Environment - 2 /* Set key-proccss := 0, if GKSP Buffer Flag = 2 */ /* Set key-process := 1, if GKSP Buffer Flag = 3 */
2) Set cfdkrl-length := valuc storcd in GKSP Record Length field in Cl~ Envirolunent 3) Sct cfdkrl := thc lcftmost cfdkrl-length bits of value stored in GKSP-buffer.c. Construct an cncryptcd DE~ key block ePli~'(keyblk), from cfdkrl, using the public key PU~I
stored in IKUl. ~'ote: keyblk-length is also produced by this step.
I l. I'roduce outputs dsigl-leng~th and dsigl, if (process-mode = 0 or process-mode = 2) and if I'R-mode= 1:
a. E~ctract 16-byte control vcctor C from IKU2 b. Construct record-code to bc stored in a cryptographic facility system signature rccord, bascd on control vcctor C.
c. Calculate a hash value on el'U~I(keyblk), usmg the hash algorithm specified by input hash-rule.
d. Construct a cr~ptographic facility systcm signaturc rccord cfssrl t'rom hash-rule, rccord-codc, and tllc calculated hash ~aluc.
e. Calc~llate digital si~naturc dsi~,l on the constructed cfssrl, using thc privatc kcy storcd in I~U~.
12. Rcsct C~ Environmcnt paramctcrs if process-mode = 2:
If proccss-mode = 2 thcn do:
a. Sct G~SP Tickct ficld in C~ Environment := ~ X 00 b. Sct G~SI' S.--c fickl in Cl Environment := X 0() c. Sct GliSI' 13uf'f-cr I lag in Cl EIlvironment := 0.
13. I'roducc output CC from CC status flags.
CO~ I~ROI l~I.OCl~ 1) CO~TROL ~'ECTOR CI IEC~I~ C,:
Pcrform control block and control vector checking:

Ins~ruc~ion Proccssino I 1 0 13'1'9-91-015 2 0 7 ~ 3 2 9 Cenerate Ke~ Set PKA (GKSP) ~ Perform the checking in steps 1, 2, and 3, if proccss-mode = 0 or process-mode = 1:
1. Checking on C3 (~ssociatcd with KKL sent to receiver) a. CV~I'YPE in C3 = 'Key-Encrypting Receiver Key' b. Verify R'l'i~,IK in C3 = B'l' (i.e., en~bled) c. Verify XLTKEY-in in C3 = B'0' (i.e., disabled) d. Verify GKS in C3 = B'000' (i.e., disabled) e. Vcrify EXI'ORT CO?~,'TROL in C3 = B'0' (i.e., eYport via RF.~,IK not perrnitted) f. If E~TE?~'SIO?~ in C3 = B'00', then verify domain-id (in instruction) = O
g. Verify KEY FOR~I = B'010' or B'110' (i.e., KKL) h. Verify EXTE~'SlOi~ in C3 = B'00' or B'01'.
i. If E~'l'E~SlO~' in C3 = 13'00', then do:
I) Verify C3R = C3L (i.e., CV EXTE?'lSlO~ = CV B.~SE) 2) Verify domain-id (in instruction) = 0 j. If EX'I'EI\SIOI\T in C3 = B'01', thcn do:
I) Verify DO:\,lt~ ' ID in C3 = domain-id (in instruction).
2) Verify IIIST-GKSP/IDK field in C3 = B'l' 2. Chccking on C4 (associated ~vith KKL rct~incd by sender):
a. CV 'I'YPE in C4 = 'liey-Encrypting Sender Key' b. Verify GKS in C4 = B' 111' (i.e., enablcd) c. Verify RF.~,IK in C4 = B'0' (i.e., disabled) d. Vcrify ~LTKEY-out in C4 = B'0' (i.e., disablcd) e. Verify EXI'OR'I' CO;~'rROL in C4 = B'0' (i.e., e~cport via RI~l~IK not permitted) t: If EXTE?~'SIO~' in C4 = B'00', then do:
1) Verify C4R = C4L (i.e., CV EXTE~SlO;~r = CV BASE) 2) Verify domain-id (in instruction) = 0 3. Chccking on C3 and C4:
a. Verify KEY FORM in C4 = KEY FOR~I in C3.
b. Verify ~XTE~'SIO~' in C4 = EXTENSIO~T in C3.
c. If LOG l~'DlCt~TOR in C3 = 1 thcn LOG in C3 = USt~GE in C~?. (i.e. C3(50..54) = C4(18..22) d. If LOG l~'DICATOR in C4 = I then LOG in C4 = USt~GE in C3 (i.e. C~'.(50..54) = C3(18..22) e. If EXTE~'SIO~ = B'01', then verify C4R = C3R
Continue if checking succeeds; other~vise set CC status flag and jump to step 13.
~3 Perform the checking in steps 4, 5, ..., 10, if proccss-mode = O or process-mode = 2:
4. ~.ctract SCBl and Cl from IKUl:
a. E~ctract system control block SCBI from IK~Tl.
b. E.Ytract control vector Cl from SCBl.
5. E~;tract S('l32 and C2 from IICU2, if PR-mode= I
a. E.~;tract system control block SCB2 from IKI,'2.
b. E.Ytlact control vcctor C2 from SCB2.
6. Chccl;ing on CI (associatcd ~vith ~
a. Vcnfy ('V -I'YI'E in Cl = 'public kcy managcmcnt kcy' b. ~'ote: chccl:ing on CV l'Yl'E EX'I'E~SIO~ has been deleted.
c. Vcrify GKSP usagc in Cl = B'l' (i.e., enabled) d. Vcrify IllS'r-ll't,K = B'l' (i.e., imported) c. Vcrify I~O.~lt~l~' IL) in Cl = domain-id (in instruction) f. If l~ey-m~nagement-protocol (in instruction) = B'l' (i.e., 'certific;ltion center protocol'), then do:
I) If l~e~-management-mode (in instruction) = 0, then KREG:~lOr)E in Cl = B'01'.
2) If l;ey-management-mode (in instruction) = 1, then KREG.~IODE in Cl = B'10'.
Instruction l'roccssing 1 1 1 13T9-91-01~ C',ener~te l~e~ Set l'l~A (GI~SP) 3) Verify IIIST-CII~ in Cl = 2.
g. Perforrn Control Vector Validate on Cl to validate certaLn fields in C l.
h. Verify IIIST-~IDC in Cl 2 ELOOR-.~,IDC in configuration vcctor.
7. Checking on C2 (associated ~ ith PR~I), if PR-mode= 1:
a. Verify CV TYPE in C2 = 'private key m~nagement key' b Verify G~SI' in C2 = B'l' (i.e., enabled) c. Verify 1)0~ ID in C2 = domain-id (in instruction) d. I'erform Control Vector Validate on C2 to ~aliclate certain fiekls in C2.
e. Verify RC2 = O
. Checl;ing on Cl and C2 (associated with PU~I and PR~I), if PR-mode= l:
a. Verify IllS'r-:\,ll)C in Cl 2 'I'IIRES-:~,IDC in C2. (This chcck is valid for private protocols .md certitication center protoeols.) b. ~\'ote: checking on CV TYPE E~TE~'S10~ has been deletcd.
9. Checking on SC13l:
a. Verify that the current date and time are in the time interval (Tstart,Te~p), specified in ~CB l (i.e., rSt;lrt < L)-r < ~ ~p).
b. Ven~y that the Enviro1lment ID stored in the EID regiiter is not the same as the Environment ID
stored in SCB l.
10. Chccl;in~, on SC132, if BR-mode= l:
a. Velify that the current date and time are in the time interv31 ('I'start,'le.~p), specifie(l in SC132 (i.e., 'I'start < r) r < Te~cp).
b. Vcrify that thc En-ironment ID stored in the EID register is the same as the Environment ID store(l in SCB2.
Continue if checking succeeds; other~vise set CC status flag and jump to step 13.

Ins~ruction Proccsiin~ 1 12 13 T 9-91-ol~ Import DEA l~ey (IDl~) Import DEA Key (IDK) 2 0 7 5 ~ 2 9 EQUA I 10~':
process-mcde /2b minimum/
domain-id /4b/ ; if process-mode=(a or 1) key-management-protocol /lb minimum/ ; if process-mode=(3 or 1) ckey-mana~ement-mode~ /lb minimum/ ; if process-mode=(~ or 1), key-management-protocol=1 <IKU1-length~ /16b/ ; if process-mode=(~ or 1), dsigl-length~
'IKU1~ /unspecified/ ; if process-mode=(~ or 1), dsigl-length~
<IKU2-length~ /16b/ ; if process-mode=(~ or 1) ~IKU2~ /unspecified/ ; if process-mode=(3 or 1) <keybli-length~ /16b/ ; if process-mode=(~ or 1) <ePU~l(keyblk)~ /unspecified/ ; if process-mode=(~ or 1) <dsigl-length~ /16b/ ; if process-mode=(~ or 1) ~dsigl~ /unspecified/ ; if process-mode=(a or 1), dsigl-length~
<ticket-in~ /64b/ ; if process-mode=2 <sender-EID~ /12ab/ ; if process-mode=(O or 2) <C3~ /128b/ ; if process-mode=(~ or 2) <C4~ /128b/ ; if process-mode=(~ or 2) <e*KM.C5(KKL)> /64b/ ; if process-mode=(O or 2) <e*KM.C6(KKR)~ /64b/ ; if process-mode=(~ or 2) <ticket-out~ /64b/ ; if process-mode=1 CC /unspecified/
P~R ~IETER DI~FI~-I I 10~-S
Inputs l)cscription process-mo~lc specifies the instruction processing mode, as follows ~ process-mode=0 produce outputs from inputs ~ process-mode= 1 produce intcrmediate outputs from inputs ~ process-mode= 2 produce outputs from interrnediate outputs domain-i~l The domain-id parameter specifies a domain identifier that ranges from O to lS ~Vhen C3 and C~ are 64 bit control ~ectors (EXTE~SIO~T = B'OO'), a value of domaill-id= O must be specified This parameter is required only when process-mode = (O or 1) ~cy-man.l~cmcllt-protocol The key-management-protocol paramcter specifies the protocol uscd for l;ey managcmcnt, ~s follows ~ key-m~n~gement-protocol = O private protocol ~ key-management-protocol= 1 ccrtil;cation ccnter protocol This paramcter is required only when process-mode= (O or 1) nt-lllo~le The key-m~n Igcmt nt-modc p~rametcr specifies lhe mcthod (callcd modc) uscd to rcgistcr a public key management key ~ ith the certification center, as follows ~ key-management-mode= 0 key registration is performed using IllOdC O
~ key-m n;3gement-mode= 1 key registration is performed using mode I
The Cl~ ~loes not define the meaning of modes O and 1 Thcse modcs are dcfincd on the basis of the nct-vork l;ey m~nagement architecture, and (as far as the Cl is con-cernecl) can be whatever a cujtomer wants them to be I his parameter is required only ~-hcn proccss-mode=(O or I) and key-management-protocol= 1 Instruction Proccssing 1 13 13'1'9-91 -n l 5 2 o 7 s 3 2 9 I n~port D E,~ ( I D ~) lengtll The length of IKUI in bytes. This paramctcr is rcquired only when proccss-mode=(O or 1) and dsigl-length > O
ll~lu I ~n Intemal Key Unit cont ~ining a l'[J:\ I of another device and bclonging to domain-id.
The value of EID in SCB I must not equal t~le value in the LID register. The values of Tstart and Texp in SCBI must satisfy the relationship Tstart S DT < Texp, whcre DT is the currcnt date and time cxpressed in Coordinated Univcrsal Time. This parameter is required only when process-mode= (O or 1) and dsigl-length 2 O.~Ei~, 7-lcn~th 'rhe length of IKU2 in bytes. This parameter is required only when process-mode = (O or 1).
I~U2 An Internal Key I nit containing a PR:\I of this device and belonging to domain-id. The value of EID in 5~CB2 must cqual the value in the EID rcgister. The values of Tstart and Texp in SCB2 must satisfy the rclationship Tstart < DT < Texp, where DT is the currcnt dnte ancl time expresse(l in Coordinated l~'ni~ersal Time. This parameter is required only ~vhen process-mode= (O or i).
~~e~bll;-lcnl th Thc length of kcyblk and cPI ~.~l(keyblk) in bits. This parametcr is rcquired only ~-hcn process-mode = (O or I ) .
~Pl,'~l(l;c~l~ll;) kcyblk cncrypted ~vith public kcy l'U.~I of this dcvice. For proccss-mo~c = O, kc~blk is a key block produccd from a Crypto E~acility VEi~. Key Record (CI~D~R). For process-mode = ( I or 2), keyblk has an unspecified format. 'T'his parameter is required only whcn proccss-mode= (O or 1).
~Isi~l-lcn~,th The Icngth of dsigl in bits. A value of dsigl-length= O indicates that no dsigl paramctcr is specified to the IDK instruction This parameter is required only when process-mode= (O or 1).
dsigl A digital signature produced from a CF Systcm Signature Record (CFSSK) and a pri-ate key m.~n~g~ment key PRl~f of another device, in accordance with section 6 of ISO DIS
9796. The CFSSR contains a 128-bit hash value calculated on ePU;\,I(keyblk). This parameter is required only when process-mode= (O or 2) and dsigl-len~th > O.
tickct-in ,'~n 8-byte value that must be equal to the 8-byte value stored in the IDK 'Iicket field in the CF Environment. This parameter is required only ~vhen process-mode= 2.
sender-I~lD ~ 128-bit environment ID of the sender of the DE.~ key. This parameter is rcquired only when process-mode= O or process-mode = 2.
C3 A 16-byte control vector associated with KKL, where KKL is the leftmost 6~ bits of the key-encrypting receiver key KK to be imported. For process-mode= O, C3 \I['ST beequal to the control ~ector stored in keyblk of input parametcr el'lJ~f(keyblk) See control vector checking for a specification of C3. This param~ter is rcquircd only w hen process-mode= (O or 2).
C~ 16-byte control vector associated ~vith KKL, where KKL is th~ leftmost 6~ bits ot thc kcy-cncr pting rcccivcr kcy KK to be importcd. I xccpt for ccltain tickls ~vhiclI Cl- ~1' is pcrmittcd to sct, C~ must cqual C3. Control vcctor checking cnsurcs th;tt C~ is a vali(l dcrivative of C3. This paramctcr is required only ~vhcn proccss-modc= (() or 2).()Utpllts Dcscrir)tion ~7'1~1.C5(1~1~l ) 6~ bit key KKL cnciphcred undcr 128 bit mastcr kcy K~I and 128 bit control vcctor C5.
KKI, is the Icft half of a 128 bit kcy-encr~pting key. I~xcept for ccrt,tin tickls ~hich the IDK instruction is permitted to sct, C5 must cqual C~. C5 is dcrived from C~ ~ia an intern31 control vector gener,ttion routine. 'I'his parameter is required only ~hen proccss-moclc = (O or 2).

Instruction l~roccssinY l l 1 13-1'9-91-015 Imp()rt 2~

~*K.~I.C6(1~R) 64 bit key KKR enciphered under 128 bit master key K.\/I and 128 bit control ~ector C6.
KKR is the right half of a 128 bit key-encrypting key. C6 is deri-cd from C5 ~ia an internal control vector generation routine. This parameter is required only ~vhen process-mode = (0 or 2).
ticl;et-out An 8-byte value equal to an 8-byte value stored in the II~K-Ticket register in the CF.
This p;3rameter is required only when process-mode= 1.
CC Condition code indicating success or failure of the instruction e~ccution.
I)l,SCRlr'~'10~':
Thc IDK instruction reenciphers a 128-bit key-encrypting key KK (= KKL,KKR) in cncrvpted forrn cl'l-.\,l(keyblk) to encrypted form e*K.~,I.CS(KKL), e*K:\I.C6(KKR). eP[J'.~I(keyblk) denotcs a kev block containillg KK cncr~pted with a public key management key of this device. e~K.~I.C5(KKL) and e*K~l.C6(KKR) are the encrypted left and right 6'~-bit parts of KK, respectively. K.~l.C5 and K.~I.C6 are variant keys formcd as the E~cclusive-OR product of master key K~I and control ~ectors C5 and C6. rcspec-tively. C5 and C6 are control ~ectors associated with KKL aild KKR, respecti-ely. CS and C6 desi~rn;lte KK as a key-cncrypting rccci-er key with an "R'l'.~IK~ attribute. The EXPORT CO~'TROL f~eld in CS
.md C6 must also spccit'y 'no e.~;port.' A process-mode parameter provides different processing options within the IDK instruction. ~Vhen process-mode = 0 is specificd, keyblk is a key block produced from a Crypto l~acility I)E.~ Kcy Record (CI DKR). 'I'he format of the CI VKR and the al~orithm for producing keyblk from CFI)KR ~re rigicilv dcfined by PKCD. Process-modes I and 2 permit a keyblk with unspccified format to be processcd. This is accomplished by invoking the IDK instruction with process-mode = I to decrypt ei~'l,'.\,l(kc! blk) and store the recovered keyblk within the C~, then invoking a Translate-To-CFDKR instruction ~vhich translatcs the keyblk t'o a CFDKR also stored within the CF, and finaliy invoking the IDK instruction ~vith process-mode= 2 to process and recover KK from the so-produced CFDKR and to produce e*K~I.C5(KKL), e*K.~I.C6(KKR). The aim of process-modes I and 2 is to remo-e the translation step from the IDK instruction, so that the IDK instruction need not directly implement a host of diffcrcnt pos-sible translation options for compatibility with other non-PKCD devices. ~ significant ad- anta~e can be achicved if the Translatc-To-CFDKR instruction is implemcnted ~vithin a programrnable mcmory ~vithin the CF.
The dsigl-length parameter indicates to the IDK instruction whether ePl~ ,I(keyblk) has an accompa-nying system signature, dsigl (dsigl-length > 0), or has no accompanying systcm signaturc (dsigl-lcngt}~
If prescnt, dsigl is validated ~vith a public key, PU, contained in the spccified Intcrnal Key Unit, IK[,-I.
ePlJ';\~I(kcyblk) may be imported ~A~ith no accompanying system signature.
A ficld in the confivuration vector, decien~ted SfG-CO~IPATIBILITY(IDE~), inclicates ~vhcthcr dsigl is rcquircd (i.c., significd by SIG-CO.~,lPA'l'IBILITY(IDK) = B'0') or whcthcr dsigl is option~ (i.c., ~
fiecl by SIG-CO.\,IPATIBILITY(IDK) = B'l'). For e~cample, when dsi~JI-lcngth= O is spccif;ed, thc IDK
instmction ensures that SIG-CO.~IE'ATIBII,ITY(IDK) = B'l'. In other ~-orcls, ~hen a (icvice is con~ ured as a compatibility devicc, the IDK instmction does not require specificatioll of a systcm sianaturc.
Control vectors C3, C4, and C5 are aii associated ~vith the KKL to be impc)rtcd. C3 mujt bc cqual in valuc to the control vector stored in CFDKR. 'I'he E,YI'OR'I CO~'TROI. ticlcl in C3, C4, ancl ( 5 must spccify 'no c~cport.' C4 is an intcrrnediate value used by the CE-~E' to rcqucst changcs to C3, as t'ollo~vs.
~Vhcn a KKL is imported, the CF.~P is permittcd, in certain cascs, to chanage control vcctor ficlds. If no chanac is clcsirccl or no change is permitted, thcn the CE~ I' scts C~ := C3, else the CI-.~I' prociuccs C~ hy m.~king selected changes to C3. The control vector checking process assures that C4 is propcrly specifiecl.
Like~ise, ~hen a KKL is imported the CF is permitted to change certain control vector ticlds. If no change is nccded or prescribed, then the CF sets C5 := C4; else the CF produces C5 by mal;ing selected chang.i to C4. Control ~ector C6 associated ~ith KKR is deri~ed ~ithin the Import DL.-~ ~;ey instruction t'rom CS.

Ins~ruc~ion Pro~cssin~ 1 15 13 1 9-91 -olS Import DEA ~e~ (ID~) The Import DE~ Key instruction e~cecutes only in the ~mn~' state.
Fli~'C'rlO~ I, s~r,cll lcA rlo:~-1. Verify process-mode = 0, 1, or 2. If ~erification fails, sct CC status nag and jump to stcp 17.
2. Validate ticket-in, and e.Ytract fields from Cl~ Environrncnt, if process-modc = 2:
If process-mode = 2 then do:
a. Verify IDK Buffer F;lag in CF Environmcnt = 1. If ~erification fails then set CC status flag and jump to step 17.
b. ~.~crit'y tickct-in := value storcd in IDK Tickct ficld in CF En-ironment. If ~crification l;-lils thcn sct CC status flag and jump to step 17.
c. Sct domain-id := bits 00..03 of IDK Save ficld in CI- ~:nvironmcnt.
d. Set key-management-protocol := bit W of IDK Save field in CF Environment.
c. ~ct kcy-m.magcmcnt-modc: = bit 05 ot IDK Save t;cld in Cl~ Environmcnt.
f. Sct ct'dkrl-lcngth := value stored in IL)K Rccord Len~,th field in CF Environmcnt.
g Sct cl'dkrl := Icftmost cfdkrl-lcngth bits of ~alue storcd in IDK Buffcr ticld in Cl r;nviromncnt.
3. I'crform input parametcr consistcncy chccking if process-mode = 0 or 1:
If proccss-modc = 0 or process-modc = I then do:
a. If dsigl-length > 0, then ~clify that IKUI is consistent to definition of an IICU.
b. Vcrif5 that IKU2 is consistent to dcfinition of an IKU.
Continue if checkinD succeeds; otheAvise set CC status flag and jump to step 17.
. I'erform configuration vector and state vector checking:
a. Verify that DEFI~'E(IDK) in config. vector = 13'1'.
b. If key-management-protocol= 1, then KMGT PROTOCOL in config. vector = B'l 1' or B'10'.
c. If key-management-protocol = I and key-management-mode = 0, then ~REG in config. ~ ector =
B'0'.
d. If key-management-protocol= 0, then Kl~IGT PROTOCOL in config. ~ector = 13'11' or B'01'.
e. Verif5~ that Cl; ST~TE in state vector is in the ~run" state.
f. Verify that K.~,IP-FLAG(CK.~II') in state vector is in the "full~' state.
g Verify that CK.~ LAG in state ~ector is in the "full" state.
h. (optional) Verify LPID FL~G in state vector is in the "full" state.
i. Verify that E~\TABLE(IDK) in state vector = B'00'.
j. If process-mode = 0 or process-mode - 1, and if dsigl-length= 0, then verify SIG-COl\~IPATIBILITY(IDK) in config. vector = B'1'.
Continue if checking succceds; other vise set CC status flag and jump to step 17.
5. I'crfortn control block and control vcctor checking.
Continue if checking succeeds; other~ise sct CC status flag and jump to step 17.
6. Constnuct e.~pcctcd record-code to be rcfercnccd against rccord-codc storcd in cfssrl, if (proccss-rno~lc =
O or process-mode = 1) and dsigl-lenDth > 0:
a. E~;tract control ~cctor C from IKI,'l b. Constmct record-code from control vector C.
7. Rcco-cr and ~alidatc cfssrl, if (proccss-mode = O or proccss-mode = I) and dsigl-lcIlg~th > 0:
a. Rcco-er cryptographic facility systcm signature record cfssrl from from digrital sigllaturc dsigl, usin_ thc public key stored in IK~il.
b. ~'crify that cfssrl is consistcnt to dcfinition of a cryptorrraphic facility systcm signaturc rccord.
c. E.~tr.lct hash rule hash-rulcl from cfssrl.
clil'y that rccor~l-code storcd in cfssrl is the s~me as record-code constnuctecl in st~p 6.

Ins~ruction l'roccssin~ 1 16 13-1'9-91-015 2 0 7 5 3 2 9 Import DE~ y (IDI~) Continue if ~erifications succccd; other~vise set CC status tlag and jump to stcp 17.
8. Calculate hash value .~,IDC on ePl,'.~l(keyblk) using the hash algorithm spccified by hash-rulcl, if (process-mode = O or process-mode = 1) and dsi~l-lenp,th > 0.
9. Validate .\,IDC against reference .~IDC in cfssrl, if (process-mode = O or process-mode = I) and dsigl-lengtll > 0:
a. Extract the hash value storcd in thc hash field in cfssrl.
b. Vcrify that i~,lDC is the samc as the e~tractcd hash value.
Continue if verification succeeds; otherwise set CC status fiag and jump to step 17.
10. Rcco-er cfdkrl if proccss-mode = 0:
a. Set key-process := I
b. Rcco-cr thc C~DKR cfdkrl from the encrypted DE~ key block eP~ I(keyblk), using thc private key l'R.~,I storcd in IKU2.
Il. Recover key block, if process-mode = 1:
a. Set key-process := 0 b. Recover thc l;cy block kcyblk from the encryptcd DE.~ key block ePU~I(keyblk), using thc plivate key l'R.~,I stored in IKU2.
12. I'roduce output ticket-out and store parameter ~alues in CF Environment if proccss-mode = 1:
a. I'roduce ticket-out:
1) Gcneratc an S-byte random number and assi,,n it to tickct-out.
b. Sa-e parameter values in CF Environrnent:
I) Set IDK Ticket field in CF Enviromnent: = ticket-out 2) If key-process= 0, then set IDK Buffer Flag in CF Environment: = 2 3) Else (key-process= I) set IDK Buffer Flag in CF Environment := 3 ~) Set IDK Save field in CF Environment := domain-id 11 key-mana~,ement-protocol 1I kcy-management-mode 1I B'OO' S) Set IDK Buffer field in CF Environment := keyblk (left-justified in IDK Buffer field).
6) Set IDK Rccord Length ficld in C~ En~ironrncnt: = keyblk-lcngth 7) Set IDK Buffer Length field in CF Environment: = value of IDK-buffer-lcngth in Configura-tion Table.
13. Construct a record code record-codel for cfdkrl based on parameters key-mana~,emcnt-protocol and key-management-mode, if process-mode = 0 or process-mode = 2.

14. Validate cfdkrl if process-mode = 0 or process-mode = 2:
a. Verify cfdkrl-lcngth = 416 /* check length */.
b. Vclify that record ID in cfdkrl is B'00000000'.
c. E~;tract the one-byte record code from cfdkrl and assign it to Y.
d. Vcrify rccord-codcl = (B'l l l l lO00' ~\'D Y) ("~'1)" is lo~,ical ~D) c. Vcrify tll.lt the value of the EID ficld in cfdkrl is not thc same as the contcnts of thc EID rc~,istcr in Cl l,nvirollmcnt (i.c., EID acts as an anti-rcimport value.) f. Verif~ that the value of the EIL) field in cfdkrl is the same as the sender-ElD. j~ recciver can't be foolcd about sendcr's identity */
,'crit'y th.lt the ~aluc of the hash control vcctor ficld (i.c.,h(C)) in cf ll;rl is thc s.unc .IS C3.
h. I,.~;tractc~l thc ~1-bit lcft h llf K~L of thc 12g-bit kcy Kt~ from ct'dkrl.
i. Vcrify that parity of KKL is odd.
j. I'~tractcd thc ~-bit richt half KKR of thc 12g-bit kcy KK from cfdkrl.
k. Vcnf~ that parity of KKR is odd.
'crify that rcscr-cd ficlds in cfdkrl are all zero.
Continuc if vcrifications succced; othcr~isc sct CC status flag and jump to stcp 17.

I ns~rucùon Proccss in~ I 1 7 13T9-91 015 2 0 7 S 3 2 9 IlllpOlt DEA l~e~ (IDI~) 1~. Produee outputs e~KiVI.C5(KKL) and e~KM.C6(KKR) if proeess-mode = O or process-mode = 2:
a. Set K~l := eontents of CK.\iI Register in the Cl~ Environment.
b. Set C5 := C~ and update the history bits in C5 if neeessary.
e. E~cclusive-OR K.~l ~vith C5 and use the resulting key to to enerypt KKL.
d Set C6 := C5 and in~ert the values in bits 41 and 42 in C5 (i.e., adjust the KEY FOR:~,I field in CS).
e. E.~cclusive-OR K~l with C6 ~nd use the resulting key to to enerypt KKR.
16. Perforrn st.~te veetor update: None.
17. Produce output CC from CC status flags.
CO~ I'ROL BLOCK A~V CO~'l ROL VECTOR CHEC}~I~G:
Perforrn control block and control vector checking:
13 Perforrn the checking in steps I and 2, if proeess-mode - O or process-mode = 2:
1. Chcckin~ollC3 (associ.ated ~Yith KKL):
. CV IYI'EillC3 = 'Key-r.ncryptinc~ ReceiYer Key' b. Vcrity I~T:\,IK usage in C3 = B'l' (i.e., enabled) c. Vcrify ,YLTKEY-in in C3 = B'0' (i.e., disabled) d. Verif~ GKS in C3 = B'000' (i.e., disabled) e. Vcrif~ ~ ~BOI~ r CO~'TROI, in C3 = B'0' (i.e., e~cport via Rl .~IK not p~rmittccl) f. Vcrify l~ Y rOR.~I = 13'010' or B'110' (i.e., KKL) g. Veri~; E~TE~SIO\T in C3 = B'00' or B'01'.
h. If E,YIE~\SIOI\ in C3 = B'00', thcn do:
I) Verify C3R = C3L (i.e., CV EX'rEl\SION = CV BASE) 2) Verify domain-id (in instruetion) = 0 i. If EiYTE~SIO.\' in C3 = B'01', then do:
1) Verify DO:\IAI~ ID in C3 = domain-id (in instmction).
2) Verify III~T-GKSP/IL~K fielcl in C3 = B'l' 2. Checking on C3 ancl C~:
a. Verify C~ = C3.
~ote: Currently there is nothing in C3 that ean be changed by CFAP in the IDK instmction.
Continuc if checking succceds; other~ise set CC status flag and jump to step 17.
~ I'erforrn the checking in steps 3 thru 9, if process-mode = 0 or process-mocle = 1:
3. E~;tract SCB I and Cl from IKUI, if dsigl-lenuth > 0:
a. I..~tract system control block SC131 from IKUI.
b. r~ctract control vcctor Cl from SCBI.
. E;~tract SC132 and C2 from IKI,2:
a. I ~tract system control block SC132 f'rom IKU2.
b. ~.Ytract control vcctor C2 from SCB2.
5. Checkina on Cl (~ssociatecd ~ith Pl~ f), if clsi~gl-length > 0:
~. Vcrify CV 'rYI'E in Cl = 'public key management key' b. Vcrif 11)~ in Cl = B'l' (i.e., enabled) c. Verify IIIST-II'[,K = B'l' (i.e., imported) d. Verify DO~fr~ ID in Cl = domain-id (in instr~ction) e. If key-manaaement-protoeol (in instruction) = B'l' (i.e., 'eertific~tion center protocol'), thcn clo:
I) If~c~-m~n~aement-mo~c(ininst~ction) = 0,then ~REG~IODE in Cl = 13'UI'.

Instrucùon l'roccssin~ 118 13r9-9l-0l5 532!~ port DE~ l~e~ (ID~) 2) If kcy-managcmcnt-mode (in instruction) = 1, then KREG!.IODE in Cl = B'10'.
3) Verify HIST-CI-IAI~' in Cl = 2.
f. I'crform Control Vcctor Validate on Cl to validate certain ficlds in Cl.
6. Checking on C2 (associatcd with PR~
a. Verify CV TYPE in C2 = 'private kcy managemcnt key' b. Verify ID~ usage in C2 = B'l' (i.e., enabled) c. Verify DO~ ID in C2 = domain-id (in instruction) d. I'crforrn Control Vector Validate on Cl to validate certain fields in C2.
7. Checking on Cl and C2 (associated ~vith PU.\,f and PR~I), if dsigl-length > 0:
a. Vcrify IIIST-~IDC in Cl > TIIRES-.~IDC in C2. (This chcck is valid for private protocols and ccrtification ccntcr protocols.) 8. Chccking on SCBl, if dsigl-lcngth > 0:
a. Verit'v that thc current date and time are in the time interval (Tstart,Te~p), specified in SCB I (i.e..
Tstart < D T < Te~cp).
b. Vcrif'y that the Environmcnt ID storcd in the EID rcgister is not the same as the Environmcnt ID
storc~l in SCB I .
9. Checking on SCB2:
a. Vcrify that the current date and time are in the tirne interval (Tstart,Te~cp), spccificd in SCB2 (i.e., rS~a~t < D r < Tc~cp).
b. Verify that the Environrnent ID stored in the EID register is the sarne as the Environment ID stored in SCB2.
Continue if chccLing succeeds; otherwise set CC status flag and jump to step 17.

Instruclion l'roccssinc 1 19 131'9-91-015 2~7 53C~I~r.ltc Digit~l Si~ .ltllre ((',DS) Verify Internal Key Unit (VIKU) I~Ql,r,~ I 10~:
KllP-mode /2b/
IKU1-length /16b/
IKUl /unspeci fied/
CC /unspeci fied/
R,~ R L)l F~ O~S:
Inpllts l)(~scription l;.~ll'-mo~l~ Specifics the PK,~ master key as follo~vs:
0: Ck~.~ll' 1: ~'~11' 2: OlC~tl' IE~UI-l-~n~th rhe Icn~,th of IKI, l in bStcs IhUI .-~n Internal Key l~nit OlltpUts l)cscril)tion CC Condition code in~ticating success or t'.uilure of the instruction eYecution l)ESCl~ll' l IO~:
The Verify Internal Key l,'nit instruction eYtracts the encr~pted CI~I'KR and encryptcd ( 1 K.~R from an Internal Key Unit, dccrypts them, and validates the CFPKR using the CFKAR. A E~.~,ll'-modc param-eter permits the validation to be perforrned usinD the current, new, or old PK~ master key rhe Verify Internal Key Unit instruction e.Yecutes only in the ~run state System Digital Sigllatllres Generate Digital Signature (GDS) PR-mode /lb/
<IKUl-length> /16b/ i if PR-mode=3 ~IKUl~ /unspecified/ ; if PR-mode=~
data-l ength /16b/
data /unspeci fi ed/
hash-rul e /3b/
i nst-code /4b/
dsig-length /16b/
dsig /unspecified/
CC /unspecified/
I' ~R,~.\IEI'I R l)EI~ IIO~S:
I)~scription l'R-Illo(tc T hc l'R-mode par~mctcr spccitics thc source of thc pri~atc l;c~ uscd to ~cneratc thc di~ital si~rn~ture, as follo-vs:
~ I'R-mode= 0 use l'R in 11 ~ I'R-mode= 1: use PR~ in Cl~

Instruction l'roccssillu 1 20 u T9-91-ol~ Ccner.lte Digit~l Si~ ture (~DS!
2075~29 II;I,TI-len~tll The Iengtll of IKlj I in bytes. I''his parameter is required only when l'R-mode= O.
IKUI ~n Internal Key IJnit containing a private key PR. I'K must be a private certification key, a private key manaDement key, or a private user key. The value of rll) in SCBI
must equal the value in the EID register. The values of Tstart and ~e:cp in SCB I must satisfy the relationship Tstart S DT < Texp, ~vhere DT is the current date and time e~cpressed in Coordinated Universal Time. This parameter is required only whcn l'R-mode = O.
lata-lcllgtll l'he Iength of data in bits.
(I,lta The data upon ~vhich a digital signature is to be calculated.
h;lsll-rllle Specifies the hash algorithm to be used to hash the input data md the rule, if any, for formatting and producinD the Cl~ System Signature Record (Cr SSI~). I he encoding of the hash-rule is as follows:
~ h~sh-rule = 0: .~,IDC-2 alDorithm (~v-ith 12g bit hash right justified in the Ilash fi kl).
~ hash-rule = 1: :\IDC-4 algorithm (~ith 128 bit hash ri~,ht justified in the llash feld).
~ hash-rule = 2: .~ID~i algorithm (~!ith 128 bit hash right justified in thc llash fiekl) ~ hash-rule = 3: quadrltic residue (~vith 12S bit hash right justit;ed in the llash feld) ~ hash-rule = ~ rcser cd inst-co(le Specifies the l'KCD instruction to be emulated (inst-codes O thru 3) or the GDS instruc-tion (inst-code= 4), as follows:
~ inst-codc= 0: rcl ~R instruction ~ inst-code = 1 : E l",' K instruction ~ inst-code = 2: G KS P instruction ~ inst-code = 3: ECFER instruction ~ inst-code = ~: GDS instruction ~ote: For inst-code= O, data is a CFAR; for inst-code= 1, data is an EKI_; for inst-code= 2, data is ePlj~I(keybLk); for inst-code= 3, data is ePUA(CFBDKB).
Outputs l)cscription lsig-lcngtll The Iength of dsig in bits.
Isig ~ digital signature produced from a CF System Signature Record (Cl-SSR) according to the signature generation processing rules outlined in Section 6 of ISO DIS 9796.CC Condition code indicating success or failure of the instruction e~ecution.
DESCRIPTIO~:
I he Gcnerate Digital Signature instruction generates a cligital siDnature, called dsig, f'rom a Crypto l acility System ~Si rnature Record (CI SSR) in accordance ~vith Section 6 of ISO l)lS 9796. I he Cl:SSI~ is a 253-bit Cl~-gencratcd rccord contaiJIing a 12g-bit hash value calculated on a variablc Icngtll input data rccord, called data. The Ien ,th of CI SSR must be less than or equal to I j~ the mod-ll-ls Icngth of the public key algorithm. I'he process of producillg dsig from CI~SSR consists of pre-proccssing stcps, decryption ~vith a pri~ate key, and post-processing steps.
,~ I'R-Inodc par.lmetcr spccifics to the GOS instruction ~hcthcr the l'R key usc(~ to pr~ e thc systcm sigrnature is spccificd in 1~1~1 (I'R-modc = O) or ~hethcr the l'R key used to producc thc sy stcm siglnature is the l'R,~ kcy stored in the Cl~ (I'R-mode= 1).
~ pri~ate celtification key can be specified to the GDS instruction only ~hcn the dc~ice is confi~Turcd as a ccrtii;cation ccnter (CERTII IC.-~T10~ ficld in the configuration ~cctor is 13 1 ). ~ pri~atc .~uthcntication };ey, a pri~ate l;e~ management key, or ~ pri~ate user key can be specificd to the Gl~i injtruc-lnstruc ion l'roccssin~

l3l9-9l-nls Cener;lte Digit~l Sign~tllre (GDS) 207 ~329 tiOII only when the device is configured as an interchange device (I?~TERCllA~'GE field in thc configura-tion vector is B'l'). A device may act as both a certification center and an intcrchange dcvice.
The GDS instruction executes only in the "run" state.

Instruction Proccssin~ i 22 13-1'9-91-()15 Verif~ Digital Signature (VDS) -- 207 ~29 Verify Digital Sign~ture (VDS) PU-mode /lb/
<IKU1-length~ /16b/ ; if PU-mode=a ~IKU1~ /unspecified/ ; if PU-mode=~
data-length /16b/
data /unspeci fied/
dsig-length /16b/
dsi g /unspeci fi ed/
hash-rul e /4b/
i nst-code /4b/
CC /unspeci fied/
I'AR.~ I ER l)l~ ITIO~S:
Inputs l)~scription PU-mo~lc The l'U-mode parameter specifies the souree of the public key used to validate the digital si~,nature, as follows:
~ PU-mode = 0: use PU in IKU 1 ~ I'U-mode= 1: use I'UA in CF
Il~lil-lcn~tll The length of IKUI in bytes. This par~meter is required only when l'U-mode= O.
II~UI An Internal Key l,'nit containing a public key PU. The values of Tstart ~md Te~cp in SCB I must satisfy the relationship Tstart S DT < Te~cp, where D r is the current date and time e~cpressecl in Coordinated Universal Time. This parameter is required only when PU-mode= O.
d~t~-length The length of data in bits.
data The data upon which a digital signature is to be calculated.
dsi~,-len~th The length of clsig in bits.
dsi~ ~ digital signature originally produced from a CF System Sic~natu re Record (CFSSR) according to the signature generation proeessing rules outlined in Section 6 of ISO DIS
9796.
Outpllts l)cscription h.lstl-rllle The encoded hash-rule field in the CF System Signature Record (Cl:SSR), ~s follo~s:
~ hash-rule = 0 m~fr)C-2 algorithm (with 128 bit hash right justified in the l-lash ficld).
~ hash-rule = 1: ~fDC-~ algorithm (with 128 bit hash right justified in the ~Iash field).
~ hash-rule = 2: i~ algorithm (with 128 bit hash ri ,ht justitied in the Ilash fiekl) ~ hash-rule = 3: qu ~dratie residue (with 128 bit hash right justified in the I lash field) ~ hash-rule = 4 - 15: reserved inst-codc l'he Ieftmost 4 bits of the Record Code field in the CF System Si~Iature Recor(l (CFSSR) (i.e., the l'KCI) instruetion that created the digital sig~n.lture or the I'KCD
instruction emulated by a GDS instruction), as follows:
~ inst-code= 0: I,CFi~R instruction ~ inst-code= 1: EI'I K instruction ~ inst-cocle = 2: GKSP instruetion ~ inst-cocle= 3: ECFER instruction ~ inst-code=4: GDS instruction ~ote: I or inst-eode = O, data is a CF~R; for inst-code = 1, data is an 1- Kl.; for inst-code= 2, data is ePl,.~ e~blk); for inst-code= 3, data is el'l,.-~(CI BL~KB).

Ins~ruc~ion l'roccssing 123 13r9-9~-015 Cener.lte Applic~tion Digit~l Signature (GADS) 207S~29 CC Condition eode indieating sueeess or failure of the instruetion exeeution.
I)l SCRIP I'10~':
The Verify Digital Signature instruction verifies a system signature, ealled dsig, in aeeordanee with Section 7 of ISO DIS 9796, where dsig was ereated from a Crypto FaciLity System Signature Record (CFSSR) in accordance with Seetion 6 of ISO DIS 9796. The C~SSR is a 253-bit C~-generated record containing a 12g-bit hash value ealculated on a variable lenDth input data reeord, called data. CFSSR is recovered from dsig by enerypting dsig with a publie key, performing eonsisteney checking on the recovercd block, and disearding redundant data and eYtraeting CFSSR.
There are no restrictions on the key type of the public key that may be used with the VDS instruction.
The VVS instruction e~eeutes only in the "run" state.
Application Di ital Signatllres Gener~te Applic;ltion Digit~l Sign~tllre (GADS) I QU~IIO~:
IKU1-length /16b/
IKU1 /unspecified/
hash-val -l ength /16b/
hash-val /unspecified/
dsi g-l ength /16b/
dsi g /unspeci fi ed/
CC /unspeci fied/
l'~RA:\IEIER l)EF~ITIO~S:
~ I)cscriptioll IKUI-I~n~tll The length of IKUl in bytes.
IKUI ~n Internal Key l,nit containing a private key PR. PR must be a private certification key, a private key management key, or a private user key. The value of EID in SCBI
must equal the value in the EID register. I he values of T start an(l Te~cp in SCB I must satisfy the relationship T start < DT < TeYp, where D T is the current clate and time e.Ypressed in Coordinated Universal Time.
I1~LSI1-V~II-I~n~ th The lengrth of hash-val in bytes. It must be < one half of modulus ICnDtll indic;lted in the control veetor assoeiated with the private l~ey ~'R in I~CUl.
sh-v:ll The hash value on which the signature is produced. hash-v.ll is computed from the dat.
by eithcr the application or CF~I', using ally hash algorithm.
Outl)nts l)~scril~tion lsit,-lell~tll I hC Iengrth of dsig in bits.
15i~ di_ital signature produced from hash-val and private l~ey E'R in accor(lallce with section 6 of ISO DIS 9796.
( C Condition code indicating success or failure of the instruction e:;ecution.
I)I .'jCI~II' I'10~:

Inslruc~ion l'roccssing 1 1319-91 -ol ~ Cener~te Applic-ltion Digit~l Sig~ tllre (C,~DS) - 207-i329 The (ienerate Applieation Digital Signature instruction generates a digital signature, eallcd dsig, from an input hash value (ealled hash-val) in aeeordanee with Seetion 6 of ISO DIS 9796. hash-val must be a whole number of bytes and the Iength of hash-val must be Iess than or equal to 1/2 the modulus len~rth of the publie key algorithm. The proeess of produeing dsig from hash-val eonsists of pre-processing steps, deeryption with a private key, and post-proeessing steps.
A signature produeed by the G.~DS instruetion is e311ed an applieation sigrnature; a signaturc produecd by the ECFAR, El'UK, GKSP, ECFER, or GDS instruetion is ealled a system signature. To prevent the G.~DS instruetion from produeing a system signature, the system signature is produeed from a 253-bit CF
Systcm Sig~ ture Rceord, whereas the applieation signature is produeed from a hash valuc consisting of a ~vhole numbcr of bytes. ~ote that 253 bits is not a whole number of bytes.
A private ccrtification l;ey can be speeified to the GADS instruetion only if the dcvicc is conf;,ure~l as a ccrtification ccnter (CERTIFIC~T10~\;' field in the eonfiguration veetor is B'l').
The GADS instruetion e~eeutes only in the "run" state.

Instruclion l~roc~ inc 12 13-19-91-015 V~rif~ Appli~tioll Digit~l sig~ ture (V.~DS) Verify Applic~tion Digital Sign~ture (VADS) EQU,~ l lo~:
IKU1-length /16b/
IKU1 /unspecified/
hash-val-length /16b/
hash-val /unspecified/
dsi g-l ength /16b/
dsi g /unspeci fi ed/
CC /unspeci fied/
r,~ .\ll'l'LR Dl~ 'I'I'IO;~'S:
Inpllts l)cscription ll~UI-lcn~th The length of IKUl in bytes.
I~UI An Internal Key Unit containing a publie key l'U. The values of Tstart and Te~;p in SCBI must satisfy the relationship Tstart < DT < Texp, uhere DT is the current date and time e.Ypressed in Coordinated Universal Time.
h~sh-~ al-lcll~tll The length ol' hash-val in bytes. It must be < one half of modulus length indicated in the control veetor assoeiated with the publie key PU in IKUI.
h:ISII-~:II 'I'he hash value on whieh the signature is produced. h.lsll-val is computcd from the dat;
by either the applieation or C~AI', using any h:~sh algorithm.
~siL~-lcn~tll The length of dsig in bits.
~Isi~ A digital si~nature produced from hash-val and private key l'R in accord:lnee with section 6 of ISO DIS 9796, and ~vhieh is validated in the V,'~DS instruetion using the public l;e~-PU (speeified in IKUl) in aeeordanee with seetion 7 of ISO DIS 9796.
Outputs D~scription CC Condition code indicating success or failure of the instruction e,~ecution.
Dl~SCRII''I'10~':
The Verify f~pplication Digital Sign;3ture instruction validates a digit31 signature, called dsig, usino ;un input hash value (called hash-val) and a public key PU in accordance with Section 7 of ISO I~IS 9796.
hash-val must be a whole number of bytes and the length of hash-val must be less than or equal to 1 ~ the modulus Iength of the public key algorithm. The proeess of validating dsig eonsists of encryption w ith a publie key, consistency eheeking to validate the redundaney bytes, and reeovery of of the h.lsh-value-of-reference oligrin;llly used to oenerate dsig. The hash value supplied to the Vf~DS instructioll (i.e., h;lsh-~al) is compared for equality with hash-value-of-reference.
~ si2,nature v:~lidated by the V,~ S instruction is c311ed ~1 application si~lature; a si~lature ~.liid;lted by the VDS instruction is callcd a system signature. See the G~DS instruction for an e.~;pll~nation of s! stem and application signatures.
'I'he V.-~L)S instruction operates with any publie key suppiied in 1~1,'1.
'I~he V.,~DS instruction e~ecutes only in the "run" state.

CF Bacl~up Ins~ruclion i~roc-ssirlU 126 13T9-91-015 E.~;port Cr~pto F~t~ility En~!iro~ t Re~ord (ECFER) E~port Crypto F~cility Environrnent Record (ECFER) 2 0 7 5 3 2 9 EQU~'rlO~':
protocol-mode /2b minimum/
KM-mode /lb minimum/
KMP-mode /lb minimum/
hash-rule /3b minimum/
IKUl-length /16b/
IKUl /unspecified/
xcfer-length /32b/
xcfer /unspecified/
cfbdkbl-length /16b/
ePUAb(cfbdkbl) /unspecified/
dsigl-length /16b/
dsigl /unspecified/
CC /unspecified/
P,~R,~.~IL'l'~ R ~ El ~lllO ~'S:
tS l)cscription ~rotocol-mo~le I'hc protocol-modc paramcter spccifies the protocol used for c:;polt and import of thc CF
cnvirollmcnt, as follo-vs:
~ 0: rcscrvcd ~ 1: CBKUI'I (certif~cation center protocol where the l'U.~ control vcctor h~s I I IS-I -C I I~ ' = 2) ~ 2: CBK~,1'2 (cenific~tion center protocol where the l'U~ control vcctor has I IIST-CI I~ T = 3) ~ 3: I'BKI,P (private protocol, i.e., no restriction on ho~v 1'1~ is importcd) I\otc that the control vector for PUAb (i.e., Cl) contains a similar 13E~I,P l'RO-I OCOL field that must match the protocol-mode parametcr.
K~l-mo(le rhe K:\,l-mode par~meter indicates ~vhether the master key K.~l is requirecl to he cnterc(l into the nc~v K~1 rcgistcr at the recciving de~ice via the L F.~IKP and C.~IKI' instructiolls:
~ K !,I-mode = 0: no ~ K;~,l-mode= l: yes (load via L,Fl~,IKI' and Cl~IKI') .~'otc: K.\~l-mocle = I silould be selected only if the value ot' K.~l is kno\vn outsi(le thc cr~pto facility, i.e., K.~ vas ori"inally loaded into the Cl~ of thc s-ndill~ dcvicc ~ ia thc Ll-~ilKI' and C,~IKI' instructions.
K.~ll'-mo(le l'hc K.~,ll'-mo(lc par:lmctCr illclicatcs whcthcr thc PKt~ mastcr l;cy K~ll' is rcquir~(l to lc cntcrcd into thc IICW K.~ll' rc ,ister at the rccci-in~, clc~icc ~ia thc I l~ ,IKI' ;3nd ('I'.~llil' instructions:
~ K.~ll'-moclc = 0: no ~ K.~ll'-mode = 1: ycs (load via LI~P.~IKI' and Cl'.~IKI') ~ote: I~.\,ll'-mode= I should bc selcctcd only if thc ~aluc of K~ll' is l;no~n outsidc thc cr~pto facility, i.c., K.~,ll~vas ori~inally loadcd into thc Cl~ of thc scndillD dc~icc via thc 1 I-I'.~IKI' and Cl'.~IKI' instructions.
ll;~sh-r~llc Spccifics the hash alDorithm to be used to calculate a h;3sh ~aluc on cl'l ~b(ct~J~;bl) ;lnd oll the cfcr. The encoding of the hash-rule is as follo-vs:

~ h~sh-rule = 0: .~1 DC-2 ~lgonthm Instrucliorl l'roc~jsin~ 7 1319-91-()1~ E~;port Cr~pto F;lcilit~ En-irol~ llt Re(:()rtl (ECFER) ~ hash-rule = 1: .~IDC-~I 31gorithm 2 0 7 ~ 3 2 9 ~ hash-rule = 2 m\,lD~ algorithrn ~ ~ hash-rule = 3: quadratie resiclue ~ hash-rule = ~-7: reser ed IKI,1-1cngt11 The length of IKUI in bytes.
II~UI r~n Internal Key Unit eont.~ining l'U~b of c3eviee b . ~ote that a is this deviee and b is the other deviee. The value of EID in SCB I must not equal the value in the EID
register. The v.~lues of Tstan and TCYP in SCB I must satisfy the relationship Tst. n <
DT < TCYP, where D T is the eurrent date .mcl time e.Ypressed in Coorclinated ~niversal Time.
Outpllts D~scriptioll ~cefer-1~ ,rt1l The len~rth of Yefer in b~1es.
~efer An l~.Yternal Crypto l aeility Environment Reeord.
efb(ll~bl-1~n(rtll The len rth of cfbclkbl .md el'U,~b(efbdkbl) in bits.
~I'U..l~b(efl)~ bl) ctbclkbl encrypted ~vith public key l'UAb of device b~. The Encrypte-l Secret l'.~n (ESI') in .Yeter is eller~pted ~ith ;I key storcd in cfbdl;bl. efbclkbl also cont~ ls cl I~S-blt h;lsh value (.~IDC) ealeul~tecl on efer.
~Isi~,l-1(1l~,tll I he Ien,th of dsiDI in bits.
rl ~ digital sirnature proclueed trom a Cl~ Systcm Signature Reeord (Cl~SSI~) and a pri~.lte authentieation key l'R~a of deviee a, in aeeordanee with seetion 6 of ISO DIS 9796.
l he CFSS R contains a 1 2s~-bit hash value calculated on eP~ b(ctbdkb l) .
CC Conclition code indicating success or failure of the instruction e cee~ltion.
l)ESCRll''rlO~':
The E.Yport Crypto ~aeility Environment Record instruction constructs an ~.Yternal Crypto l~aeility ~nvironment Record, ~ccfer, an encrypted Crypto FaciLity Backup Kcy Block, el'U..~b(cfbdkbl), and a diDital siDnature, dsigl. dsigl is calculated from a Crypto Facility System Signature Record (efssrl) and a priv.lte authentication key PR.~a. Subscripts ~a and b designate this device and another device respeetively.
efssrl eontains a hash value (e.g., an l\,fDC) caleulated on ePUr~b(efbdkbl), i.e., the digital signature authenticates ePU~b(cfbdkbl). cfbdkbl eontains a similar hash ~alue (e.g., an ~IDC) ealculclted on efer, which permits .Yefer to be authentieated. Both hash values (i.e., the hash value in efssrl ancl the hash v;llue in ctbdkbl) are calculated using the same hash akrorithm, .IS specified in the hash-lule p.~rameter of the E;CFER instruction. efbdl;bl also eontains a 128 bit l~ey KK2 used to enerypt the Seeret l'art (Sl') of .~;et'er, ~here KE~2 = KKl Yor ~ Yor Y. Yefer also eontains a ~onsecret Part (~SP). The v alues ~ and Y are determined as follo\vs~ : = K.~,ll' if K.~ mode = 1 and .~: = O if K~ll' = rr.ode= 0, and (') Y: =
K.\,f if K:\l-mo(le = 1 and Y: = O if K.\,f-mode = 0. Together SP and l\SI' eonstitute e~ er~hinu in th~ ('P' I~nvironment eYeept the l'tJ,L~ and 1'1~ key, their length fields, and control ~eetors, an~l the eontents ot the DID register. l-hese elements do not port in the .Yefer.
~ ny OIIC of three protoeol modes may be used to CYport and import a Cl--e nv ironmellt reeord: (a) 1'13KUI', (b) C13Kt l'l, and (e) C13KUI'2. The I'13KUI' (i.e., private protoeol) mode is the Ieast restrieti~e.
Ihis mode permits an installation to et'feet deviee baekup using privately eYehanged l't ~ keys. l-he C13KUI'1 ~nd C13E~1,1'2 modes ma};e use of a eertifieation eenter to indireetly ~ali(late the 1'1,.-~ };ey, ;m-l thus Ire more restrietive. In the C13KI,1'2 mode, the eontrol veetor of the Pl ey mu~t ha~e a IIIS I -Cll.~l~' value equal to 3, i.e., the PUr~ key is imported using a 1'1,.~1 I;ey ~vllose control vector has a IIISr-CII~ value equ~l to 2 and the P~:\l key is imported using a Pl C l~ey ~vhose control vector has a IIIS I -Cll.~l~ value equ~l 1. In the CBKI~-PI mode, the control vector of the 1'1 .~ I;ey must have a IIIS l--CII ~ V;IIUC equal to ~, i.e., the 1'~,~ key is imported using a l'I C l;ey ~VIIOSC control ~cctor h.ls ;3 I I IS I -CI I.'.I ~\ ~ alue equal to 1.

Instruction l'roc~ssin~ 12~

Ul9-91-015 E.YPOI~ Cr~pto F;l~ility En~irollment R~eord (ECFER) - 2 ~ 7 ~ ~ 2 ~
Several mcchanisms are provided to authorize and control the exccution of the ECFER instruction.
These eontrol mcchanisms are cffccted via the confi ,~uration vector, the control vcctors, and the instruction parameters. The ECI:ER and ICI-ER instructions are designed to opcrate only if both the exporting and importing devices agree~ to use the same protocol and protocol options. In effect, this means that both devices must be conligured thc samc (i.e,., both configuration vectors must be the samc with rcspcct to de-ice backup), both devices must use the s.lme key m.~n~3E,em~nt protocol, and the same parameter options must be spccificd to tlle ECEER and ICI~ER instructions. Thc follo ving addition conditions are enforced: ( I
the method of lo.l ling or gener;lting K.~IP at the exporting and importing devices must be thc same"ln(l ( ) ~ hen protocol-mode = 1 or 2 the l UC keys (or PU.~I and I l,C keys) used at the exporting and importing devices to import the l UA kcys must bc thc same. A l-llST-DO.~f.~ - ID ficld in the statc cctor of a cloncd Cl cnvirollmcnt rccords the domain idcntifier of the l tjC kcys (or l ~C and 1 U:\l kcys) uscd to import the 1 I,A keys when protocol modes I or are used. By usin,, the ECF~R instruction, a cloned dcvice can be aulitcd to ensure that backup and rccovery was cffccted ~ith the proper l I-C key. ~grccmcnt between the exporting and imponing devices is effected through the use of the record code ficld in thc Crypto Facility B.~ckup l)Ef~ Key Record and through direct comparisons of the information storc(l in thc CFER produced at the exporting device and the Cl En,ironment of the importing lcvice.
The ECFER ;md ICFER instructions provide an option requiring the master key K.~if and or thc l Kf~ master kcy K~ll to be reentered at thc importing (or recei-ing) dc icc. In that C.lSC, thc cryptovariable encrypting key I~KI under vhich the Secret l :~rt of xcfer is encrypted can be rcco crc l .It the receiving device only if the required values of K:\~l and/or K.\~IP have been properly entcred. This option permits a CF Environment to be ported without exposing K~l or K~,IP to anv greater e~ctent than ould othcr vise be rcquircd for ordinary manual key entry at a sending or receiving dcvice.
The ECFER instruction e~cecutes only in the run state.

I nstruclion I roc~- in ~ I ' 9 B-r9-9l-ol~ Import Cr~pto F.l~ility En-ir()nll-ellt Rc~:orù (IC~ ER) 20~53~9 Import Crypto Facility Environment Record (ICFER) EQUA l lo~:
I~R~ I ER l)l.FI~l l lO~S:
protocol-mode /2b minimum/
KM-mode /lb minimum/
KMP-mode /lb minimum/
IKUl-length /16b/
IKUl /unspecified/
xcfer-l ength /32b/
xcfer /unspeci fied/
cfbdkbl-l ength /16b/
ePUAb (cfbdkbl) /unspeci fi ed/
dsigl-length /16b/
dsigl /unspecified/
CC /unspeci fied/
lFl'ER Dl FI~ITIO~S:
Inr)uts l)cscription ~rotoeol-nlo(le The protoeol-mode par;lmeter speeifies the protoeol used for e.~;port ;md i nport of the CF
environmellt, as follows:
~ 0: reserved ~ 1: CBKUPI (certifieation center protocol where the l'UA control vector has I IIST-CI IAI~ = 2) ~ 2: CBKUP2 (certification center protocol where the l'UA control vector has I IIST-CH.~ T = 3) ~ 3: I'BKUP (private protoeol, i.e., no restrietion on how PUA is imported) i~ote that the eontrol veetor for Pl,lAa (i.e., Cl) eontains a similar BK~P Pl~O-rOCOL field that must mateh the protocol-mode parameter.
K~mo(le The Ki~il-mode parameter indicates whether the master key K~l is required to be entered into the new K~l register at the receiving deviee via the L~.~,fKP and C~fKP instructions:
~ K:.\,l-mode = 0: no .\,l-mode= 1: yes (load via L~.~IKI' and C.~IKI') ~otc: K.\~f-mode= I should be seleeted only if the ~alue of K~l is hlown outside the erypto facility, i.e., K.~f was originally loaded into the Cl~ of the sendinv device ~ ia the Ll;.~IKP and C.~IKI' instruetions.
ll'-nlo(le I'he K.~ mode parameter indientes wllethcr the l'K;~ master L~cy K.~ll' is rcquircd to 1 e entered into the new K.~ll' register at the receivinV device ~ia the l l l'.~lKI' ;:3nd Cl'.\IKI' instmctions:
~ K.~ mode = 0: no ~ K:\,ll'-mode = 1: yes (load via 1 I~ IKI' and Cl'.~ll~l') ~otc: K.~IP-mode= I should be selected only it the value of K~ll' is ~nown outsid the crypto facility, i.e., K~ll~vas ori,inally lo.lded into Ihe Cl: of the sendill~, device Vi~l the Ll~ IKI' and Cl'.~IKI' instructions.
Il~l l-lell~,tll The Iengt}l of IKI I in b~tes.

InstnJc~ion Processin~ 130 1~'1'9-91-015 Import Cr~pto F~cilit~ En~ir(~ e~t21:~cord (ICFER) IKUI ~n Internal Key Unit containing PUAa of device "a". ~\ote that "a" is thc other dc-ice and ~b~v is this device. The value of EID in SCBl must not equal thc ~alue in the EID
register. The values of Tstart and Texp in SCB I must satisfy the rclationship Tst1rt S
l)T < Te~;p, where D'l' is the current date and time expressed in Coorclinated l 'niversal Time.
~;crcr-length The Icngth of ~ccfer in bytes.
~;cfcr ~n External Crypto Facility Environment Record.
cfb~ll;bl-lcn~th The length of cfbdkbl and ePUAb(cfbdkbl) in bits.
~l'~'~b(cfb~ bl) cfbdkbl encrypted with public key PUAb of device "b". The Encr~pted Sccrct Part (ESP) in ~ccfer is encrypted with a key stored in cfbdkbl. cfbdkbl also contains ~ 12S-bit h.~sh value (.~IOC) calculated on cfer.
si~ n"t1l Thc len~th of dsigl in bits.
~Isi~ di~ital signature produced from a CF System Signature Record (CI SSR) and a private ;luthc ntication key l'R~a of device "a", in accordance ~ ith section 6 of IS0 L)IS 9;r96.
Thc Cl SSR contains a 128-bit hash value calculatcd on ePli~b(cfbdkbl).
()utl)uts l)cscriptioll CC Condition codc indicating success or failurc of thc instnuction c:cccution.
I)l.~CI~II''I'10~:
The Import Cl~pto racility Environment Record instmction permnits an ~cfcr producccl ~-ith an ECFER instruction, at a sending device, to be imported at a rcceiving de~ice. In effcct, thc output of .m ECI:ER instruction becomes the input to an ICFER instruction. E~cecution of the IC}~ER instruction causes the variables stored in the xcfer to replace the comparable ~ariables in the CF l n~ironrnent of the receiving device.
l'he inputs to the Impon Crypto l~acility Environment Rccord instnuction consists of an ~ctcrnal Crypto Facility l~n-ironment Record, xcfer, an encrypted Crypto l acility Backup Key l310ck, ePU~b(cfbdkbl), and a digital signature, dsigl. dsigl is calculated from a Crypto Facility Systcm Si~n~ture Record (cfssrl) and a private authentication key PRAa. Subscripts "b" and "a" dcsign~te this de-ice an-l another device, respectively. cfssrl contains a hash value (e.g., an ~fDC) calculated on el'lj~b(cfbdkbl), i.e., the digital signature authenticates el'UAb(cfbdkbl). ctbdkbl contains a similar hash ~alue (e.~., an MDC) calculated on cfer, which permits xcfer to be authenticated. Both hash values (i.e., the hash ~aluc in cfssrl and the hash value in cfbdkbl) are calculated using the same hash algorithun, as orijn;llly spccifiecl in the hash-nule parametcr of the ECFER instnuction. cfbdkbl also contains a 12~ bit key KEi' uscd to encrypt the Secret Pan (SP) of xcfer, ~vhere KK2 = KKI ~or X ~;or Y. .Ycfer also contains a l\'onsecret Part (~'SP). Thc valucs X and Y are dctccrmincd as follo~vs~ : = K~IP if K~ modc = I .md .~: = n if Kl~iII'=moclc=0, and (2) Y := K.;\~l if KM-mode= I and Y := 0 if K.~,l-modc=0. rroDcthcr Sl' ~ncl ~'SI' constitutc cvcr~~thinu in thc Cl~ r.nvironmcnt e.~ccpt the l'U~ an-l I'KA kcy, thcir Icnl~th liclds. ;Incl colltrol vcctors, .mcl thc contents of the I~IL) rcDister. 'I'hcse elemcnts do not pon in the ~cfcr.
,~ny onc of thrcc protocol modcs m;ly bc uscd to C.~pOlt .IIId impon .I C}'-cn~ironlllcnt rc~cor-l~
1'13KI,'I', (b) C13KI'I'I, and (c) C13KI,'1'2. 'I'hc 1'13KUI' (i.c., pri-atc protocol) modc is thc Icast rcslrictivc.
'I'his moclc pcrmits an installation to effcct devicc backup using privately e~ch.moccl 1'1~ I;evs. 'I'he C13K~;PI ancl CnKl~P2 modcs ma};c usc of a ccrtitication ccntcr to indircctly ~alidatc the P~ kcy. ~nd thus are more restrictive. In the CBK[J'1'2 mode, the control vector of the 1'1~ L;ey must ha-e a IIIS'r-CIl~ ' valuc equal to 3, i.c., the 1'1'~ key is importcd usinl~ a P[~r.\~l I;ey ~~hosc control vector has a IIIS'I'-CII.~I~' value equal to 2 and the 1'[1.~,1 key is imported usinD a }'IJC l~cy ~vhose control vector has a IllS'r-CII;\I~' ~alue equal to 1. ln the C13K~PI modc, the control ~ector of the Pl,i~ l;ey must h;3-e a IIIS'I'-CII.~ alue equal to 2, i.e., the 1'1'.-~ key is imported usinD a Pl,'C key ~-hose control ~ector has a I lls'r-c l l;~ lue ~qu;31 to 1 .

Instruction Proccssinu 131 13r9-91-015 S~t ~n(l Reset Al trm (SRAL~
207:~32~
Se~eral mechanisms are provided to authorize and eontrol the e:cecution of the IC~ER instruction.
These eontrol mechanisms are effected via the eonfiguration vector, the eontrol ~ectors, and the instruction p~rameters. The ECFER and ICE ER instructions are designed to operate only if both the e.~porting and importing devices agree to use the same protocol and protocol options. In efTect, this means that both deviees must be configured the same (i.e., both eonfiguration veetors must be the same ~ ith respect to device backup), both deviees must use the same key management protoeol, and the same parameter options must be speeified to the ECE ER and ICI ER instruetions. The follo-vinD addition eonditions are enforced: ( I) the method of loadinO or generating K.~tP at the exporting and importing de-ices must be the same, and (2) ~vhen protocol-mode = I or 2 the l'UC keSs (or PU~I and Pl,C keys) used at the e~cporting and importing devices to import the I'UA keys must be the same. A HIST-VO.~ IV field in the state ~ector of a cloned Cl~ en~ironment records the domain identifier of the P[jC keys (or l'I,C and 1~ ,1 keys) used to import the l'U}~ keys ~vhen protocol modes I or 2 are used. By using the ECI .~R instruction, a cloned de-ice can be audited to ensure that backup and recovery ~vas ef'feeted ~vith the proper l'I C key. ~greement between the eYporting and importinD devices is effeeted through the use of the recor~l code field in the Crypto F acility 13ackup l)E~ Key Record and through direct comparisons of the inform;ltion stored in the CFI~R produced at the exporting device and the Cl~ Environment of the importino device.
I he ECE ER and ICFER instructions pro~ide an option requiring the master key li.~,l andjor the l'K ~ master key ~IP to be reentered at the importing (or receiving) device. In that ease, the cryptovariable encrypting key KKI under ~-hich the Secret l'art of Ycfer is encrypted c~n be recovered at the recci~ing device only if the required ~Llues of K~l andlor K.\~ll' have been properly entered. This option pennits a CF Environment to be ported ~vithout e.~posing K~l or K.~IP to any greater e.~;tent than ~vould other~vise be requirc(l for ordinary manual key entry at a scnding or receiving dc~ice. T o pennit rcco-cl~, K.~ll' must be reentered into the ?~K.~II' reDister and ~.~1 must be reentere~l into the ~ 1 re~ister usin~, the CF instructions.
The concept of CF Environment backup using the ECFER and ICFER instructions is such that the I'UA and l'RA keys are not ported from one device to another. Thus, ~vhen a CF Environment is reim-ported at a receiving device, the eYisting PUA and PR~ keys are not changed, and the contel~t of the DID
register is not changed. Ho~vever, the eontent of the EID register IS ehanged, i.e., the content of the EID
reDister ports from one device to another. These ensure that e.Yisting certificates containin~, EID remain valid, and the anti-reimport property of EID remains valid.
The ICFER instruction e.Yecutes only in the run~ state.
Set ;Ind Reset Al~rm (SRALM) EQUA I lo~:
mode /lb mi nimum/
CC /unspecified/
P.~R.~ l'rR l)l,rl~'lT10~'S:
Inl)llts l)cscription motlc ~ parameter indieatinD ~hether to set or reset alarm, as follo~s:
~ 0: reset alarm ~ 1: set alarm ()nt~ ts l)~scription CC Condition code indicating success or failure of the instruction C~CCUtiOII.
I)l'SCI~II' 1'10.~:

Inslruction l~roccssin~ 132 I~-rs sl-ols ~ O ~ .) 3 2 9 Set .~nd Reset Al;lrm (SRAL.~I) The Set and Rcset Alarm instruction signals the cr that an alarrn condition should be sct or rcset.
e tcrrn alarrn me~ns a signal scnt on a line, e.g., causing a light to come on or a signal to bc sent on a monitoring line lo a ccntral location.

Ins~ruclion l'roccssin~ 133 13'1'9-91-01~ 2075329 Bcsides the frcquently used Kcy Rccord ~ncrypt and Key Record Dccrypt algorithms, there arc othcr algorithms commonly used by thc PKCD instructions. 'I'hcy are dcscribed as follows.
IPRN - Initi;llize Pseudo-R~tndom Nullll)er Algorithm Inputs: ~'one.
OI~tputs. ~'one.
orithm Description:
1. Produce KKI and KK2 from PR~'GKEYI, PRI\'GKEY2 and PR~'GCTR I rcgistcrs:
a. Sct KKII, := Icttmost l'R~'GKI-,YI ~(jR l'R~'GCTRI
b. Set KKIR := rightmost PR;~'GKEYl ~OR l'RI\'GCTRI
c. Sct KK2L := Icftmost PR~'GKEY2 ~OR PR~'GCTRI
d. Sct KK2R := rightmost l'R~'GKEY2 ~COR l'R:\GCTRI
~'ot~:: the II'R~' algorithm assumcs that l'R~GC'I'RI is continuously upd:lted by by h:lr~l\v;lre If }'Rl\'GCTRI is not implemcntcd, onc may altcrnati-cly rcad an intcrnal Timc of' D;ly Clocl~ valuc and, if 'l-OD h:ls morc than 64 bits, usc thc lo~v-ordcr 6 I bits of 'l'OL) instcad of l'RI\'GC'['R I.
2. Calculate KK3 and KK4:
a. Calculate ~ hash value on KKl using thc ;\IDC-2 algorithm, and assign thc rcsult to KK3.
b. Calculate a h:lsh valuc on KK2 usin~, thc :\II)C-2 al~,oritllm, an-l assi~l thc rcs-llt to KK4.
~ 'otc this stcp climin.~tec thc nccd to erasc or zcroizc the PR~'GKEYI and PR~'GKEY' registcrs whcn thc CF Environment is clcar. It also distributes any randomness uniformly over the key.
3. Fi~c bits in KK3 and KK4:
a. Sct bits 00..01 of KK3 := B'00'.
b. Set bits 64..65 of KK3 := B'01'.
c. Sct bits 00..01 of KK4 := B'10'.
d. Set bits 64..65 of KK I: = B' l l'.
4. (Optional) adjust parity of KK3 and KK4:
a. For each b~te in KK3 and KK4 (whose bits are numbered bO to b7), set bit b7 so that bits bO
thru b7 have an odd number of bits set to B'l'.
5. Write KK3 to l'R~'GKEYl register and KK4 to PR.~\'GKEY2 register:
a. I'RI\'GKEYI := KK3.
b. PRI\'GKEY2 := KK4.

In~truction l~rocciiing 13 13'r9-91-015 ~o ENCE~U - Encrypt CKU to IKU Algorithm The E~C~U algorithm is the in-erse of the RCKI,'I algorithm.
The E;iC~U al;,orithrn is as follows:
CKU(K.llP,nl,CKU ~ IKU) Inpt~ts:
IP A 1~ bit DEA key.
nl I'he length of C~U ancl IKU in b~tes.
Cl~U A Clear Key l,'nit.
~tp~s.
Il~U ,\n Internal Key l,'nit.
, l looritl~m Description:
1. E.~tract control data (consisting of a system control block concatenated to a user control block) from CKU.
ctract key record and key authenticator record l'rom C~U.
3. I'ncrypt key record and key authenticator record using the method described in the Key Record Encrypt aloorithm 4. Convert CKU to IICU by updating the header and by replacing the key record and key authenticator record in CKU with encrypted key record and encrypted key authenticator, respectively.

Instruc~ion l~roccssinv 13:~

13 1'9-9 1 -O l S
207~329 RCKUI - Recover CKU from IKU Algorithm Thc RCKI,I algorithm is the invcrsc of the E~C~U algorithm.
The RCKUI al"orithm is as follows:
RCKUI(K.illP~nl~lKU ~ CKU,RC) ptltS:
~.~11' ~ 12~ bit DE~ key.
n I The length of IKU in bytes.
II~U ~n Intcrnal Key Unit.
Ot~tpt~ts.;
CI~U .~ Clcar Key Unit.
RC Return code I . succcssful complction 2. kcy authenticator record in the IKU does not verify rithm l>escripti~7n:
1. E~tract thc control data from IKU.
2. E~tract cncrypted key rccord and encrypted key authcnticator rccord from CKU.
3. Decrypt cncrypted key record and encrypted key authcnticator record using thc method dcscribcd iIl the Key Record Decrypt algorithm.
4. Convert IKU to CKU by updating the header and by replacing the encrypted kcy rccord and cncr!-pted key authcnticator record in IKU with key record and key authenticator, rcspcctively.

Instruction l'rocc,sin~ 136 PI~GA - PKA Key Generation Algorithm ~ hc l'KA Key Gcncration algorithm is as foUo~vs:
PA'G~ (C,gmode,codewo) d,res ~ sl ,cfpkrl ,s2,cfpkr2,RC) Inputs.
C A 16 byte control vector of the generated public key.
~,mo(te A par~metcr indicating the modc of key generation, as foUo~vs:
'R': Random - E~ey generation mal;es use of an L-bit seed randomly generated.
'D': Dcri~cd - Kcy gencration makes use of an L-bit seed derived from a 12g bit code~vord supplicd as an input par;3meter.
colle~or(l ~ 12g bit "sced'' value used to generate an L-bit pseudorandom number.
rcs A paramctcr indicating key Icngth restrictions, as follows:
~ 0: no rcstriction ~ 1: Icngth rcstriction typc ~1"
O~(tp~lts:
51 '['hc Icngth of cfpkrl in ~-bytc blocks.
cf~ rl ,~ Crypto l~acility l'KA Key Record containing a generated public key.s7 l hc Icll~,th of cfpkr2 in g-bytc blocks.
cfpl~r7 t~ Crypto Facility PKA Key Record containing a generated private key.
RC Rcturn code 1. - successful operation 2. - Al~,onthrn spccifled in the control ~ector is not supported ,ll~oritflm Description.
1. Set alg ~ LGORITIIi\/l f~eld in C
~. If gmodc= 'R', then generate an L-bit seed using a random or a pscudorandom numbcr 2cncrator.
3. I lse (gmode='D'), derive an L-bit seed from the supplied codc~vord.
. I'erform the Key Generation Algorithm (KGA) on the L-bit seed to generate a p.~ir of public and pri-ate key records cfpkrl and cfpkr2, respcctively.
~ote: l~G,~ and the method for deriving an L-bit seed from a codc~vord havc becn dcscribcd in co-pcnding patent by S..;~ latyas, et ~11. entitled "Generating l'ublic and l'rivate Key l'airs using ;
l'assphrase,~ cited in thc backcround art.
CVVLD - Control Vector Vali(late Algoritllm '1 hc Control Vector V;31idatc algorithm is as foUo~vs:
Cl'~ (Ci I RC) Inpllts.
Ci I hc input control vector Ci on ~vhich the CV checl;ing is perforrned.
Ol~tpl~t.~:

InsLruc~ion l~roc~ ssing 137 l3 r9-9~-ols ~0~ 329 RC Rcturn code I . successful completion 2. unsuccessful completion ~ orithm Description:
The Control Vector Vali~late checks a control ~ector associatecl with a l'K~ kcy. ~o checkin~J is per-formed on the CV TYPE ficld.
1. Sct RC := O
2. Vcrify r~TIV~Rl~T ZERO in Ci = B'O' 3. Vcril'y ~ 1 IVI~Rl~.\ I' O~E in Ci = B'l' . Vcrify E~TE~S10~ in Ci = B'10' (i.e., > 12~ bit control vcctor) 5. Verify TES I ZERO in Ci = B'OOO' (i.e., RPZ are vali~l) 6. If chccl~in~ f3ils, thcn set RC := I and abort opcration.

Instru~tion l~roccssinY 138 I~T9-(31-015 2 0 ~ '.) ?~ 2 3 CVG - Control Vector Generation Algorithm The Control Vector Generate ~Igorithrn is used by the IPI,'K instruction to set history inforrnation in an output control vector. The speeifie fields set by the Control Vector Generate routine are IIIST-IP~'K, IIIST-CII,~ , IIIST-.~IDC, IIIST-DO.~ ' ID and IllS'r-~REG.\,lODE. These history fields are inter-rogated for compliance ~ith minimum threshold values set forth in the configuration vcctor ~nd in other eontrol ~ectors, when a publie Icey is used for key management or CF en~ironment backup The Control Vector Gener;3te is as follo~vs:
Cl G(impo~l-mo(le,mllc-mo~le"tt(~c-in~lex,si,nlltl~rc-mo~lc,C1,C7 I C3) l~oZlts:
import-lllo(le ~'~ I bit value inclicating the import-mode, as follo~vs:
~ 0: import-mode= 0 in IPUK instruction ~ 1: import-mode= I in IPI,'K instruction m~le-ll1o(le .~ I bit ~alue inclieatino the .~,lDC-mode, as follo~vs:
~ 0: .~lDC-mode = O in IYUK instruetion ~ 1: .~lDC-mocle= 1 in II'UK instruction This p;lr;lmeter is ~ alid only when import-mode = 0.
m(le-in(lex ,l~ p:1r;mleter has a value equal to the ~IDC-inde.~c parameter in the ll'l~ instluction.
~i~n.lture-mo(le A 2 bit value indieating the signature mode, as follo-vs:
~ 0: sirJnature-mode = 0 in IPUK instruetion ~ 1: signature-mode= 1 in IPUK instruetion ~ 2: signature-mode= 2 in II'UK instruction Cl A 16 b~te control ~ector assoeiated ~vith a PU to be imported.
C2 A 16 byte control veetor associated ~vith a l'U used to validate a di=,ital si~,nature.
O~tp~lts:
C3 A 16 byte control veetor, associated with the imported l'U.
~l2oritllrn Description:
1. Set C3 := Cl 2. Irpclate EIIST-II'I,'K field:
a. Set lIIST-IYI'~ in C3 := 13'1' (i.e., imported) 3. [,'pdate ~1 IS'I'-.~,I DC field:
a. If import-mode= 0 and mde-mode= 0, then set l-IIS'I'-.~IDC in C3: = 13'01'.
b. If'import-mode=0 and mde-mode= 1, thcn set IIIST-.~IDC in C3 := E ~ II)C
G(m(le-inr~e;Y) in state ~ector.
c. If ilnpor-t-mode= 1, then set IIIST-:~,IDC in C3 := IIIST-.~,IDC in C _.
. ~;pcl;:lte IllS~ Rr G.~,IODE field, if CV TYI'E in Cl = 'PUf~' and CV 'I'YI'E in C2 = 'E'E'~
a. Set IIIS'I'-~RI'(J.\,IODE in C3 := f~REG.~IODE in C2. ~'ote: The IllS'I'-~REG.~lOr)E fiel~l may contain ~ali{l history information ~~hen Ills-r-cl~ 13'11'. ~'ot~ithst tnclin, this, the IIIST-~RE(~ IODE field is eonsidered ~alid only ~hen IIIST-IPI'~ = B'l' and IIIST-CII
13'11.

Ins~ruction Procrssirl~J 139 ~7~3~

NOTE: Sillce for importIllode=O CV TYPE in Cl always equals CV IYPE in C2, step 4 is executed only whell importmode= 1.
5. Update I IIS l DOMAIN Il) field, if CV I YPE in C1 = 'PUA' and (CV IYPF. in C2 ='PUC'orCV IYPE
in C2 ='PUM):
a. Set EIISTDOMAIN II:) in C3 := DOMAIN IV in C2. Note: The HISTDOMAIN ID field may contain valid hist(-)ty inforlIlation wheIl E IISTCE IAIN c > B' 10' or B' I 1'. NotwithstaIldillg this, the I IISTI~OMAIN
ID field is considered valid only when EIISTIPUIC = B'1' and (either EIISTCE-IAIN = B'l() or I IISTCEIAIN
= B'll').
NOTE: Since for importmode=0 CV TYPE in Cl always eqllals CV IYPF, in C2, step 5 is executed only when importmode= 1.
6. Up(1ate IIIST(~ IAIN field:
a. Set EIISTCEIAIN in C3 := E~'OO' h. If (importmode=0) and (signaturemode=0 or signaturenlode=1) and (CV IYPE irl Cl = 'PUC'), then set EIISTCEIAIN in C3 := B'Ol'.
c. If (importmode= 1 ) and (CV TYPI~ in C 1 = 'PUC') and (CV TYPE in C2 ='PUC') and (I IISTIPUIC
inC'2 = B'l') and (IIISTCEIAIN in ('2 = B'01') and (DOM~IN ID in Cl = DOMAIN ID in C2), then set HISTCE IAIN in C3: = B'() 1'.
d. If (importmode= I ) and (CV TYPE in C 1 = 'PUM') and (CV lYPE in C2 = 'PUC') and (HIS I IPUIC in C2 = B' l ') and ( HISTC'E~AIN iIl C2 = B'O I ') and (DOMAIN ID in C l = I)OMAIN
Il) in C2), thell set EIISTCEIAIN in C3 := B'10'.
e. If (im~<)rtrrlode= I ) and (CV TYPE in C 1 = 'PUA') and (CV TYPE in C2 = 'PUC') and (E IISTIPUIC
in C2 = B'l') and (IIISTCIIAIN in C2 = B'01'), then set IIISTCE~AIN in C3 := B'10'.
f. If (importIllode= 1) and (CV IYPE in Cl = 'PUA') and (IIISTII'UIC in Cl = B'0') and (CV TYPE
in C2 = 'PUM') and (IllSTlPUlCin C2 = B'1') and (EIISTCI~AIN in C2 = B'10'), then set llI~TCI~IN in ('3 := B'l1'. Note: Chcckirlg that HISlIPUICin Cl = B'0' ensllres that PUA is generated at the same device as the l'RM used to generate the digital signature on EICU.
NOIE: For importlllode=() and signaturemode=O, EIISTCI-IAIN is set c~lual to B'OO', which, in terms of the CFAP definitioIl of 'merit', limits all imported PU keys to be 'BRONZE' keys (i.e., no 'GOI,D' or 'SIl,Vl,R' keys Call be irnported).
Althollgll a specific enlbodirIlellt of the invention has been disclosed, it will be understood by those having skill in the art that changes can be made tc) the specific embodirnent without departitlg from the spirit an(1 the scope of the inv(ntioll.

,.j,

Claims (33)

1. In a data processing system, a method for managing a public key cryptographic system, comprising the steps of:

generating a first public key and a first private key as a first pair in said data processing system, for use with a first public key algorithm;

generating a second public key and a second private key as a second pair in said data processing system, for use with a second public key algorithm;

assigning a private control vector for said first private key and said second private key in said data processing system, for defining permitted uses for said first and second private keys;

forming a private key record which includes said first private key and said second private key in said data processing system, and encrypting said private key record under a first master key expression which is a function of said private control vector;

forming a private key token which includes said private control vector and said private key record, and storing said private key token in said data processing system;

receiving a first key use request in said data processing system, requiring said first public key algorithm;

accessing said private key token in said data processing system and checking said private control vector to determine if said private key record contains a key having permitted uses which will satisfy said first request;

decrypting said private key record under said first master key expression in said data processing system and extracting said first private key from said private key record;

selecting said first public key algorithm in said data processing system for said first key use request;

executing said first public key algorithm in said data processing system using said first private key to perform a cryptographic operation to satisfy said first key use request.

2. The method of claim 1, wherein:

said private key record includes parse data to locate said first private key and said second private key in said private key record; and said extracting step includes using said parse data for extracting said first private key from said private key record.

3. The method of claim 1, which further comprises:

forming a first private key authentication record in said data processing system, by computing a hash value using a hashing function on said private key record and encrypting said first private key authentication record under a second master key expression which is a function of said private control vector;

said private key token including said first private key authentication record.

4. The method of claim 3, which further comprises:

after said decrypting step, computing a second private key authentication record in said data processing system, by computing a second hash value using said hashing function on said decrypted private key record and comparing said second private key authentication record with said first private key authentication record;

aborting further processing of said first key use request in said data processing system, if said second private key authentication record is not equal to said first private key authentication record.

5. The method of claim 4, wherein:

said private key token includes header data to locate said control vector, said private key record and said private key authentication record in said private key token; and said accessing step includes using said header data to locate said private key record in said private key token.

6. The method of claim 3, which further comprises:

assigning a public control vector for said first public key and said second public key in said data processing system, for defining permitted uses for said first and second public keys;

forming a public key record which includes said first public key and said second public key in said data processing system, and encrypting said public key record under a third master key expression which is a function of said public control vector;

forming a public key token which includes said public control vector and said public key record, and storing said public key token in said data processing system;

receiving a second key use request in said data processing system, requiring said second public key algorithm;

accessing said public key token in said data processing system and checking said public control vector to determine if said public key record contains a key having permitted uses which will satisfy said second request;

decrypting said public key record under said third master key expression in said data processing system and extracting said second public key from said public key record;

selecting said second public key algorithm in said data processing system for said second key use request;

executing said second public key algorithm in said data processing system using said second public key to perform a cryptographic operation to satisfy said second key use request.

7. The method of claim 6, wherein:

said public key record includes second parse data to locate said first public key and said second public key in said public key record; and said extracting step for extracting said first public key includes using said parse data for extracting said first public key from said public key record.

8. The method of claim 6, which further comprises:

forming a first public key authentication record in said data processing system, by computing a hash value using a hashing function on said public key record and encrypting said first public key authentication record under a fourth master key expression which is a function of said public control vector;

said public key token including said first public key authentication record.

9. The method of claim 8, which further comprises:

after said decrypting step for said public key record, computing a second public key authentication record in said data processing system, by computing a second hash value using said hashing function on said decrypted public key record and comparing said second public key authentication record with said first public key authentication record;

aborting further processing of said second key use request in said data processing system, if said second public key authentication record is not equal to said first public key authentication record.

10. The method of claim 9, wherein:

said public key token includes header data to locate said public control vector, said public key record and said public key authentication record in said public key token; and said accessing step for said public key token includes using said header data to locate said public key record in said public key token.

11. In a data processing system, a method for managing a public key cryptographic system, comprising the steps of:

generating a public key and a private key as a pair in said data processing system, for use with a public key algorithm;

assigning a private control vector for said private key in said data processing system, for defining permitted uses for said private key;

forming a private key record which includes said private key in said data processing system, and encrypting said private key record under a first master key expression which is a function of said private control vector;

forming a private key token which includes said private control vector and said encrypted private key record and storing said private key token in said data processing system;

receiving a first key use request in said data processing system, requiring execution of said public key algorithm with a private key;

accessing said private key token in said data processing system and checking said private control vector to determine if said private key record contains a key having permitted uses which will satisfy said first key use request;

decrypting said private key record under said first master key expression in said data processing system and extracting said private key from said private key record;

executing said public key algorithm in said data processing system using said private key to perform a cryptographic operation to satisfy said first key use request.

12. The method of claim 11, which further comprises:

assigning a public control vector for said public key in said data processing system, for defining permitted uses for said public key;

forming a public key record which includes said public key in said data processing system, and encrypting said public key record under a second master key expression which is a function of said public control vector;

forming a public key token which includes said public control vector and said public key record and storing said public key token in said data processing system;

receiving a second key use request in said data processing system, requiring execution of said public key algorithm with a public key;

accessing said public key token in said data processing system and checking said public control vector to determine if said public key record contains a key having permitted uses which will satisfy said second key use request;

decrypting said public key record under said second master key expression in said data processing system and extracting said public key from said public key record;

executing said public key algorithm in said data processing system using said public key to perform a cryptographic operation to satisfy said second key use request.

13. The method of claim 12, which further comprises:

forming a first private key authentication record in said data processing system, by computing a hash value using a hashing function on said private key record;

said private key token including said first private key authentication record.

14. The method of claim 13, which further comprises:

after said decrypting step for said private key record, computing a second private key authentication record in said data processing system, by computing a second hash value using said hashing function on said decrypted private key record and comparing said second private key authentication record with said first private key authentication record;

aborting further processing of said first key use request in said data processing system, if said second private key authentication record is not equal to said first private key authentication record.

15. The method of claim 14, which further comprises:

forming a first public key authentication record in said data processing system, by computing a hash value using said hashing function on said public key record;

said public key token including said first public key authentication record.

16. The method of claim 15, which further comprises:

after said decrypting step for said public key record, computing a second public key authentication record in said data processing system, by computing a second hash value using said hashing function on said decrypted public key record and comparing said second public key authentication record with said first public key authentication record;

aborting further processing of said second key use request in said data processing system, if said second public key authentication record is not equal to said first public key authentication record.

17. In a data processing system, a method for managing a public key cryptographic system, comprising the steps of:

generating a public key and a private key in said cryptographic system;

assigning a public key control vector to said public key in accordance with intended uses for said public key;

assigning a private key control vector to said private key in accordance with intended uses for said private key;

storing said public key in a public key record and storing said private key in a private key record;

encrypting said public key record under a master key and encrypting said private key record under said master key;

forming a modification detection code on a concatenated expression of said public key control vector and said public key record as a public key authentication record;

forming a modification detection code on a concatenated expression of said private key control vector and said private key record to produce a private key authentication record;

encrypting said public key authentication record under said master key and encrypting said private key authentication record under said master key;

forming a public key token which includes said public key control vector in a first field, said encrypted public key record in a second field, and said encrypted public key authentication record in a third field;

forming a private key token including said private key control vector in a first field, said encrypted private key record in a second field, and said encrypted private key authentication record in a third field.

18. The method of claim 17 wherein said master key is a secret key belonging to a symmetric key algorithm.

19. The method of claim 18 wherein said secret key is a data encryption algorithm key.

20. A computer program storage device readable by a data processing system, embodying a program of instructions executable by said data processing system to perform method steps for managing a public key cryptographic system, said method steps comprising:

generating a first public key and a first private key as a first pair in said data processing system, for use with a first public key algorithm;

generating a second public key and a second private key as a second pair in said data processing system, for use with a second public key algorithm;

assigning a private control vector for said first private key and said second private key in said data processing system, for defining permitted uses for said first and second private keys;

forming a private key record which includes said first private key and said second private key in said data processing system, and encrypting said private key record under a first master key expression which is a function of said private control vector;

forming a private key token which includes said private control vector and said private key record, and storing said private key token in said data processing system;

receiving a first key use request in said data processing system, requiring said first public key algorithm;

accessing said private key token in said data processing system and checking said private control vector to determine if said private key record contains a key having permitted uses which will satisfy said first request;

decrypting said private key record under said first master key expression in said data processing system and extracting said first private key from said private key record;

selecting said first public key algorithm in said data processing system for said first key use request;

executing said first public key algorithm in said data processing system using said first private key to perform a cryptographic operation to satisfy said first key use request.

21. The computer program storage device of claim 20, wherein:

said private key record includes parse data to locate said first private key and said second private key in said private key record; and said extracting step includes using said parse data for extracting said first private key from said private key record.

22. The computer program storage device of claim 20, wherein the method steps comprise:

forming a first private key authentication record in said processing system, by computing a hash value using a hashing function on said private key record and encrypting said first private key authentication record under a second master key expression which is a function of said private control vector;

said private key token including said first private key authentication record.

23. The computer program storage device of claim 22, wherein the method steps further comprise:

after said decrypting step, computing a second private key authentication record in said data processing system, by computing a second hash value using said hashing function on said decrypted private key record and comparing said second private key authentication record with said first private key authentication record;

aborting further processing of said first key use request in said data processing system, if said second private key authentication record is not equal to said first private key authentication record.

24. The computer program storage device of claim 23, wherein:

said private key token includes header data to locate said control vector, said private key record and said private key authentication record in said private key token; and said accessing step includes using said header data to locate said private key record in said private key token.

25. A computer program storage device readable by a data processing system, embodying a program of instructions executable by said data processing system to perform method steps for managing a public key cryptographic system, said method steps comprising:

generating a public key and a private key as a pair in said data processing system, for use with a public key algorithm;

assigning a private control vector for said private key in said data processing system, for defining permitted uses for said private key;

forming a private key record which includes said private key in said data processing system, and encrypting said private key record under a first master key expression which is a function of said private control vector;

forming a private key token which includes said private control vector and said encrypted private key record and storing said private key token in said data processing system;

receiving a first key use request in said data processing system, requiring execution of said public key algorithm with a private key;

accessing said private key token in said data processing system and checking said private control vector to determine if said private key record contains a key having permitted uses which will satisfy said first key use request;

decrypting said private key record under said first master key expression in said data processing system and extracting said private key from said private key record;

executing said public key algorithm in said data processing system using said private key to perform a cryptographic operation to satisfy said first key use request.

26. The computer program storage device of claim 25, wherein said method steps further comprise:

assigning a public control vector for said public key in said data processing system, for defining permitted uses for said public key;

forming a public key record which includes said public key in said data processing system, and encrypting said public key record under a second master key expression which is a function of said public control vector;

forming a public key token which includes said public control vector and said public key record and storing said public key token in said data processing system;

receiving a second key use request in said data processing system, requiring execution of said public key algorithm with a public key;

accessing said public key token in said data processing system and checking said public control vector to determine if said public key record contains a key having permitted uses which will satisfy said second key use request;

decrypting said public key record under said second master key expression in said data processing system and extracting said public key from said public key record;

executing said public key algorithm in said data processing system using said public key to perform a cryptographic operation to satisfy said second key use request.

27. The computer program storage device of claim 26, wherein said method steps further comprise:

forming a first private key authentication record in said data processing system, by computing a hash value using a hashing function on said private key record;

said private key token including said first private key authentication record.

28. The computer program storage device of claim 27, wherein said method steps further comprise:

after said decrypting step for said private key record, computing a second private key authentication record in said data processing system, by computing a second hash value using said hashing function on said decrypted private key record and comparing said second private key authentication record with said first private key authentication record;

aborting further processing of said first key use request in said data processing system, if said second private key authentication record is not equal to said first private key authentication record.

29. The computer program storage device of claim 28, wherein said method steps further comprise:

forming a first public key authentication record in said data processing system, by computing a hash value using said hashing function on said public key record; and including said first public key authentication record in said public key token.

30. The computer program storage device of claim 29, wherein said method steps further comprise:

after said decrypting step for said public key record, computing a second public key authentication record in said data processing system, by computing a second hash value using said hashing function on said decrypted public key record and comparing said second public key authentication record with said first public key authentication record;

aborting further processing of said second key use request in said data processing system, if said second public key authentication record is not equal to said first public key authentication record.

31. A data processing system for managing a public key cryptographic system, comprising:

first generating means for generating a first public key and a first private key as a first pair in said data processing system, for use with a first public key algorithm;

second generating means for generating a second public key and a second private key as a second pair in said data processing system, for use with a second public key algorithm;

assigning means for assigning a private control vector for said first private key and said second private key in said data processing system, for defining permitted uses for said first and second private keys;

key record forming means coupled to said first and second generating means, for forming a private key record which includes said first private key and said second private key in said data processing system, encrypting means coupled to said key record forming means and said assigning means, for encrypting said private key record under a first master key expression which is a function of said private control vector;

key token forming means coupled to said assigning means and to said key record forming means, for forming a private key token which includes said private control vector and said private key record;

storing means coupled to said key token forming means, for storing said private key token in said data processing system;

receiving means coupled to a user input, for receiving a first key use request in said data processing system, requiring said first public key algorithm;

accessing means coupled to said receiving means and to said storing means, for accessing said private key token in said data processing system and checking said private control vector to determine if said private key record contains a key having permitted uses which will satisfy said first request;

decrypting means coupled to said accessing means, for decrypting said private key record under said first master key expression in said data processing system and extracting said first private key from said private key record;

selecting means coupled to said receiving means, for selecting said first public key algorithm in said data processing system for said first key use request;

executing means coupled to said selecting means and to said decrypting means, for executing said first public key algorithm in said data processing system using said first private key to perform a cryptographic operation to satisfy said first key use request.

32. The system of claim 31, which further comprises:

authentication record forming means coupled to said key record forming means, for forming a first private key authentication record in said data processing system, by computing a hash value using a hashing function on said private key record and encrypting said first private key authentication record under a second master key expression which is a function of said private control vector;

said private key token including said first private key authentication record.

33. The system of claim 32, which further comprises:

computing means coupled to said decryption means, for computing a second private key authentication record in said data processing system, by computing a second hash value using said hashing function on said decrypted private key record and comparing said second private key authentication record with said first private key authentication record;

terminating means coupled to said computing means, for aborting further processing of said first key use request in said data processing system, if said second private key authentication record is not equal to said first private key authentication record.