llllllllllllllllllllllllllllllllllllllllllllIIIlllllllllllllllllllllllllll
US005231666A
United States Patent [19]
[11]
i451
Matyas
[54] CRYPTOGRAPHIC METHOD FOR
Patent Number:
Date of Patent:
5,231,666
Jul. 27, 1993
[75] Inventor:
Stephen M. Matyas, Manassas, Va.
terns,” Proceedings of the 1980 Symposium on Securty
and Privacy, pp. 122-134, Apr. 14-16, 1980.
Primary Examiner-David Cain
[73] Assignee:
International Business Machines
Attorney, Agent, or Firm-John E. Heel
Corporation, Armonk, NY.
[5?]
UPDATING FINANCIAL RECORDS
[21] Appl. No.1 870,978
Apr. 20, 1992
[22] Filed:
Int.
Cl.5
.............................................
.. H04K 1/00
[51]
[52] US. Cl. ...................................... .. 380/25; 380/23;
380/4
[53]
[56]
Field of Search .............................. .. 380/23, 25, 4
References Cited
U.S. PATENT DOCUMENTS
4,309,569
l/l982
Merkle .
4,661,658
4,850,177
4,908,861
4,918,728
4,924,514
4,924,515
4,941,176
4/1987
7/ 1989
3/1990
4/1990
5/1990
5/1990
7/1990
2/ 1991
4/1991
4/1992
Matyas .
Brachtl et al.
Brachtl et al.
Matyas et a1.
Matyas et a1.
Matyas et al.
Matyas et al.
Matyas et al.
Matyas et a1.
Matyas et al.
4,993,069
5,007,089
5,103,478
ABSTRACT
A data processing system, method and computer pro-_
gram provide for the secure updating an electronic
purse which includes a list of purse records. The
method includes the step of de?ning an authentication
tree with an authentication tree function comprising a
one way function of purse records in the list, the authen
tication tree having a ?rst root for a ?rst list of the purse
records and storing the ?rst root in a cryptographic
facility. The authentication tree includes authentication
MDC vectors, one for each purse record in the list. The
method includes the step of receiving a transaction
record in the cryptographic facility, including an au
thentication code, a cryptographic key, and an authenti
cation MDC vector, for updating an existing purse
record in the ?rst list. The method then performs the
step of performing a purse update function in the cryp
.
.
.
.
.
.
tographic facility. The method ?rst authenticates the
transaction record using the authentication code and
.
.
.
cryptographic key and authenticates the existing purse
record with the authentication MDC vector and ?rst
root. The method next performs the step of substituting
OTHER PUBLICATIONS
R. C. Merkle, “Secrecy, Authentication, and Public
Key Systems," UMI Research Press, Ann Arbor,
Mich., 1982 & Technical Report, No. 1979-1, Informa
tion Systems Laboratory, Stanford University, Jun.
an updated purse record for the existing purse record in
the ?rst list, forming a second list. The method then
computes with the updated purse record and the ?rst
authentication MDC vector, a second path MDC vec
tor and a second root of the authentication tree for the
1979.
second list by computing a path MDC vector of the
authentication tree between the updated purse record
R. C. Merkle, “Protocols for Public Key Cryptosys
tems,” Technical Report, BNR, Palo Alto, Calif., Jan.
tographic facility.
and the ?rst root and stores the second root in the cryp
1980.
R. C. Merkle, “Protocols for Public Key Cryptosys
2 Claims, 6 Drawing Sheets
O?YPTOGMPHIC SYSTEM COMPONENTS TO IMPLEMENT THETREE
unnermcmou ueonrrm;
svsrrm
om STORAGE 40
| nsoonu FILE 41 j
ammo FACIUTV
AOCESSPROGRAM
(em;
a
APPLICATION
mamas
wru A
HLESTOHAGE new
Mac vscron 42 ] L .sroas neoonn
. mmsve nsconu
ammo FAOUTHOFH
meta-emu
0mm 11
m
‘m
4‘
cw Fmcmus 53
mDFlLE
our:
*
necoao mo
.EOORD m1‘:
meow m
m
names 64
" a“
noumesza
.vasc
.aurnncv
mox
.moa
roam
roam
aux:
new
mum
.mox
mon
.rronm'
'DBEKJUTNESOOULDMSOIENHMITEDASQMUCTW,SINCE
MYALEADYEXXSTASWTERNALWMTWNTHECF.
"Tl‘EWDCNSTRUCTMSANEXAIPLEOFANMEHNALROl-MNE
’
US. Patent
July 27, 1993
Sheet 1 of 6
5,231,666
F|G.1
BINARYTREE:
l?lZlQlQZQ?ZZZ?ZAZ?ZQZZZ?ZQE?
l
1
T
§
l
L
9
19
Q
I
l
1_1
I
l
12
I
l
1.3
I
l
1_4
I
1.5
I_______.|
I________T
L_.._—I
5
5
Z
:1
L_____.J
L___________I
2
3
g
I
1
FIG. 2
CRYPTOGRAPHIC NETWORK:
COMMUNICATIONS NETWORK
CRYPTO
CRYPTO
SYSTEM
SYSTEM -
1
2
CRYPTO
------ --
SYSTEM
n
US. Patent
July 27, 1993
Sheet 2 of 6
5,231,666
CRYPTCCRAPHIC SYSTEM’:
2
FIG. 3
\
CKDS
f
3
4
‘
‘
APPL
e3 ‘_
sj
CFAP
8
7
L CI= ‘EL
CRYPTOGRAPHIC FACILITY 1:
FIG' 4
sECuRE BOUNDARY
s
/11
\
CF
ENVIRONMENT
K10
12’\
CRYPTOGRAPHIC __INSTRUCT|ON_
PHYSICAL
ALGORITHMS
PRoCEssoR
CFAP-TO-CF
INTERFACE
-
9\
INTERFACE
'(OPTIONAL)
FIG. 5
CF ENVIRONMENT 11:
ROOT-MDC REGISTERS
112
ROOT-'MDC REGISTER FLAGS 113
__
CW3
US. Patent
July 27, 1993
Sheet 3 of 6
5,231,666
FIG. 6
INDEXES IN RF AND MDCV:
RF MDCV
1
1234567890. m23~
36457890
FIG. 8
TRANSACTION MESSAGE ORIGINATING WITH MEMBER i :
ACCOUNT
ACCOUNT
TRANSACTION
NUMBER
DEBITED (i)
NUMBER AMOUNT SEQUENCE
CREDITED (i)
NUMBER
OTHER
FIG. 9
PURSE RECORD Ri I
FINANCIAL INSTITUTION
ACCOUNT NUMBER (i)
ACCOUNT TRANSACTION
BALANCE SEQUENCE
NUMBER
OTHER
US. Patent
July 27, 1993
Sheet 4 of 6
5,231,666
FIG. 7
CRYPTOGRAPHIC SYSTEM COMPONENTS TO IMPLEMENT THE TREE
AUTHENTICATION ALGORITHM:
SYSTEM A
’
DATA STORAGE 4o
CRYPTO FACILITY
APPLICATION
ACCESS PROGRAM
(CFAP)
s
PROGRAMS
(APPL) 4
RECORD FILE 41
‘
FILE STORAGE MGR 51
M00 vECTOR 42
‘
ISTORE RECORD
RETRIEvE RECORD
CRYPTO FACILITY (CF) 1
OF ENVIRONMENT 11
.DELETE RECORD
APPL
.ROOT-MDC
REG'STER FLAGS
11a
4‘
CFAP FUNCTIONS 53
.RECORD FILE
.ROOT-MDC
CREATE
REGISTERS
.RECORD ADD
112
.RECORD DELETE
_
~ I
.RECORD UPDATE
.
INSTRUCTION
PROCESSOR 12
.GMDC**
.LRMDC
‘Egg?
-
'
RE C 0 RD VERIFY
INTERNAL
*
ROUTINES s4
ROUTINES 2a
INTERNAL
_GAMDCV
.vREC
.GNPMDCV
.FINDX
.PADR
.FORM1
.FORM2
.GMDC
.FINDX
_pADR*
_RFQRM1*
.RFORM2*
* THESE ROUTINES COULD ALSO BE IMPLEMENTED AS CF INSTRUCTIONS, SINCE
THEY ALREADY EXIST AS INTERNAL ROUTINES WITHIN THE CF.
** THE GMDC INSTRUCTION IS AN EXAMPLE OF AN INTERNAL ROUTINE
EXTERNALIZED AS A CF INSTRUCTION.
U.S. Pate'nt
July 27, 1993
FIG. 10
Sheet 5 of 6
CRYPTOGRAPHIC SYSTEM (BLOCK DIAGRAM):
CRYPTO FACILITY ACCESS
PROGRAM (CFAP) a
ELEC. PURSE MGR 51
ELECTRONIC PURSE 4o
RECORD FILE 41
‘ \l
STORE RECORD
MDC vECTOR 42
‘I
RETRIEvE RECORD
.DELETE RECORD
KEY STORAGE (KS) 2
CKDS
31
DKDS
32
KEY STORAGE
75
MGR 52
.STORE KEY
.RETRIEvE KEY
.DELETE KEY
CRYPTO FACILITY (CF) 1
CF ENVIRONMENT 11
CFAP FUNCTIONS
53
.MASTER KEY 111
ROOT MDC
REGISTERS
APPLICATION
PROGRAMS (APPL) 4
112
70
‘PURSE CREATE
\
&|N|T|AL|ZE s31
7"'-’\
'
INSTRUCTION
ggRSE UPDATE
74
PROCESSOR (IP)12 76
\
78
\
121
7-,-
'
\.
INTERNAL
_
ROuTINES 2s
.vREC
INTERNAL ROuTINES
54
.MDCvI
.GAMDCv
.MDCvu
.GNPMDCv
.FINDX
.PADR
.FORMI
.PORM2
.GMDC
'GMAC
.FRONT PANEL
INTERFACE 13
73 KEY ENTRY DEVICE
_ \
‘
.
.ROOT MDC REG
ISTER FLAGS 11s
,uPuRSE
PURSE uTILITY 61
14
—
I__ROOT MDC
\
PURSE
PROCESSING
62
.PuRSE uPDATE
US. Patent
July 27, 1993
Sheet 6 of 6
5,231,666
BEGIN A SECURE METHOD FOR UPDATING AN ELECTRONIC PURSE
/202
DEFINE AN AUTHENTICATION TREE WITH AN AUTHENTICATION TREE FUNCTION
HAVING A FIRST ROOT FOR A FIRST LIST OF PURSE RECORDS AND STORING THE
FIRST ROOT IN A CRYPTOGRAPHIC FACILITY
/204
RECEIVE IN THE CRYPTOGRAPHIC FACILITY TRANSACTION RECORD, A PURSE
RECORD, AN AUTHENTICATION CODE, AND AN MDC AUTHENTICATION VECTOR
r206
PERFORM A PURSE UPDATE FUNCTION IN THE CRYPTOGRAPHIC FACILITY. BY
PERFORMING THE FOLLOWING STEPS WITHOUT INTERRUPTION
/2D8
AUTHENTICATE THE TRANSACTION RECORD, USING THE AUTHENTICATION CODE
AND CRYPTOGRAPHIC KEY
/21 0
COMPUTE, WITH THE EXISTING PURSE RECORD AND A FIRST AUTHENTICATION
MDC VECTOR FOR THE EXISTING PURSE RECORD, A FIRST TEST PATH MDC
VECTOR AND A FIRST TEST ROOT OF THE AUTHENTICATION TREE FOR THE
FIRST LIST BY COMPUTING A PATH MDC VECTOR OF THE AUTHENTICATION
TREE BETWEEN THE EXISTING PURSE RECORD AND THE FIRST ROOT
/212
COMPARE THE FIRST TEST ROOT WITH THE FIRST ROOT
K214
UPDATE THE EXISTING PURSE RECORD WITH THE TRANSACTION RECORD’
FORMING AN UPDATED PURSE RECORD
.
‘
r216
SUBSTITUTE THE UPDATED PURSE RECORD FOR THE EXISTING PURSE RECORD
IN THE FIRST LIST, FORMING A SECOND LIST
/218
I COMPUTE WITH THE UPDATED PURSE RECORD AND THE FIRST AUTHENTICATION
MDC VECTOR, A SECOND PATH MDC VECTOR AND A SECOND ROOT OF THE
AUTHENTICATION TREE FOR THE SECOND LIST BY COMPUTING A PATH MDC
VECTOR OF THE AUTHENTICATION TREE BETWEEN THE UPDATED PURSE
RECORD AND THE FIRST ROOT AND STORE THE SECOND ROOT IN THE
CRYPTOGRAPHIC FACILITY
1
5,231,666
2
assigned to IBM Corporation and incorporated here by
reference.
B. Brachtl, et al., “Data Authentication Using Modi
CRYPTOGRAPHIC METHOD FOR UPDATING
FINANCIAL RECORDS
?cation Detection Codes Based on a Public One Way
BACKGROUND OF THE INVENTION’
1. Technical Field
The invention disclosed broadly relates to data pro
5
S. M. Matyas, et al., “Method and Apparatus for
cessing systems and methods and more particularly
Controlling the Use of a Public Key, Based on the
relates to cryptographic systems and methods for use in
Level of Import Integrity for the Key,” Ser. No.
07/602,989, ?led Oct. 24, 1990, assigned to IBM Corpo
ration and incorporated herein by reference.
S. M. Matyas, et al., “A Hybrid Public Key Al
data processing systems to enhance security.
2. Background Art
The following patents and patent applications are
related to this invention and are incorporated herein by
gorithm/Data Encryption Algorithm Key Distribution
reference:
Method
R. C. Merkle, “Method of Providing Digital Signa
Based on Control Vectors,”
Ser.
No.
07/748,407, ?led Aug. 22, 1991, assigned to IBM Cor
tures,” U.S. Pat. No. 4,309,569, issued Jan. 5, 1982.
R. C. Merkle, Secrecy, Authentication. and Public Key
Systems, UMI Research Press, Ann Arbor, Mich., 1982.
R. C. Merkle, Secrecy, Authentication, and Public Key
Systems, Technical Report No. 1979-1, Information
Systems Laboratory, Stanford University, June 1979.
R. C. Merkle, Protocols for Public Key Cryptogrstems,
poration and incorporated herein by reference.
Technical Report, BNR, Palo Alto, Calif, January
1980.
25
R. C. Merkle, “Protocols for Public Key Cryptosys
tems,” Proceedings of the 1980 Symposium on Security
and Privacy, 122-134, Apr. 14-16, 1980.
S. M. Matyas, “Of?ine PIN Validation with DES,”
U.S. Pat. No. 4,661,658, issued Apr. 28, 1987, assigned
to IBM Corporation and incorporated herein by refer
S. M. Matyas et al., “Generating Public and Private
Key Pairs Using a Passphrase,” Ser. No. 07/766,533,
?led Sep. 27, 1991, assigned to IBM Corporation and
incorporated herein by reference.
S. M. Matyas et al., “Public Key Cryptosystem Key
Management Based on Control Vectors,” Ser. No.
07/766,260, ?led Sep. 27, 1991, assigned to IBM Corpo
ration and incorporated herein by reference.
S. M. Matyas et al., “Method to Establish and En
force a Network Cryptographic Security Policy in a
30
ence.
Public Key Cryptosystem,” Ser. No. 07/786,227, ?led
Oct. 31, 1991, assigned to IBM Corporation and incor
porated herein by reference.
S. M. Matyas et al., “Cryptographic Facility Envi
ronment Backup/Restore and Replication in a Public
B. Brachtl, et al., “Controlled Use of Cryptographic
Key Cryptosystem,” Ser. No. 07/786,237, ?led Oct. 31,
1991, assigned to IBM Corporation and incorporated
herein by reference.
The cryptographic architecture described in U.S.
Pat. Nos. 4,850,017, 4,941,176, 4,918,728, 4,924,514,
4,924,515, 4,993,069, and 5,007,089 and in patent appli
Keys Via Generating Stations Established Control Val
ues,” U.S. Pat. No. 4,850,017, issued Jul. 18, 1989, as
signed to IBM Corporation and incorporated herein by
reference.
S. M. Matyas, et al., “Secure Management of Keys
Using Control Vectors,” U.S. Pat. No. 4,941,176, issued
Jul. 10, 1990, assigned to IBM Corporation and incorpo
rated herein by reference.
S. M. Matyas, et al., “Data Cryptography Operations
Using Control Vectors,” U.S. Pat. No. 4,918,728, issued
Apr. 17, 1990, assigned to IBM Corporation and incor
porated herein by reference.
Encryption Function," U.S. Pat. No. 4,908,861, issued
Mar. 13, 1990, assigned to IBM Corporation and incor
porated herein by reference.
40
cations Ser. No. 07/596,637, Ser. No. O7/574,012, Ser.
No. 07/602,989, Ser. No. 07/748,407, Ser. No.
07/766,533, Ser. No. 07/766,260, Ser. No. 07/786,227,
and Ser. No. 07/ 786,237 by S. M. Matyas et a1. is based
on associating with a cryptographic key, a control vec
tor which provides the authorization for the uses of the
45
S. M. Matyas, et al., “Personal Identification Number .
Processing Using Control Vectors,” U.S. Pat. No.
4,924,514, issued May 8, 1990, assigned to IBM Corpo
ration and incorporated herein by reference.
S. M. Matyas, et al., “Secure Management of Keys
key intended by the originator of the key. The crypto
graphic architecture described in the cited U.S. Pat.
Nos. 4,850,017, 4,941,176, 4,918,728, 4,924,514,
4,924,515, 4,993,069, and 5,007,089 and cited patent
applications Ser. No. 07/596,637 and Ser. No.
07/574,012 by S. M. Matyas et a1. is based on the Data
Using Extended Control Vectors,” U.S. Pat. No.
4,924,515, issued May 8, 1990, assigned to IBM Corpo
Encryption Algorithm (DEA), see American National
Standard X3.92-1981, Data Encryption Algorithm,
ration and incorporated herein by reference.
American National Standards Institute, New York Dec.
-
S. M. Matyas, et al., “Secure Key Management Usin
Control Vector Translation,” U.S. Pat. No. 4,993,069,
issued Feb. 12, 1991, assigned to IBM Corporation and
31, 1981). The cryptographic architecture described in
55
incorporated herein by reference.
S. M. Matyas, et al., “Secure Key Management Using
Programmable Control Vector Checking,” U.S. Pat.
No. 5,007,089, issued Apr. 9, 1991, assigned to IBM
Corporation and incorporated herein by reference.
S. M. Matyas, et al., “Secure Management of Keys
Using Control Vectors with Multi-Path Checking,”
Ser. No. 07/596,637, ?led Oct. 12, 1990, assigned to
IBM Corporation and incorporated here by reference.
S. M. Matyas, et al., “Secure Cryptographic Opera
cited patents by S. M. Matyas, et al. The CF is an in
struction processor for a set of cryptographic instruc
tions, implementing encryption methods and key gener
65
tions Using Alternate Modes of Control Vector En- ‘
forcement,” Ser. No. 07/574,012, ?led Aug. 22, 1990,
the cited patent applications Ser. No. 07/602,989, Ser.
No. 07/748,407, Ser. ‘No. 07/766,533, Ser. No.
07/766,260, Ser. No. 07/786,227, and Ser. No.
07/786,237, by S. M. Matyas et a1. is based in addition
on a public key algorithm (PKA), i.e., a combination of
DEA and PKA. A cryptographic facility (CF) in the
cryptographic architecture is described in the above
ation methods. A memory in the cryptographic facility
stores a set of internal cryptographic variables. Each
cryptographic instruction is described in terms of a
sequence of processing steps required to transform a set
5,231,666
3
of input parameters to a set of output parameters. A
cryptographic facility application program (CFAP) is
also described in the referenced patents and patent ap
plications, which de?nes an invocation method, as a
calling sequence, for each cryptographic instruction
consisting of an instruction mnemonic and an address
4
tion tree function or a one-way function of a secret
number. More speci?cally, the method according to
Merkle provides a digital signature of the type which
generates a secret number X,~, where X,~=x,~1,x,1, . . . , x1”
computes Y,-= F(X,-) and transmits part of X; to the
receiver as the digital signature. Merkle characterizes
with corresponding input and output parameters.
his invention as providing an authentication tree with an
Public key encryption algorithms are described in a
paper by W. Dif?e and M. E. Hellman entitled “Privacy
and Authentication: An Introduction to Cryptogra
authentication tree function comprising a one-way
functions of Y,-. The root of the authentication tree and
the authentication tree function are authenticated at the
phy,” Proceedings of the IEEE, Volume 67, No. 3,
March 1979, pp. 397-427. Public key systems are based
on dispensing with the secret key distribution channel,
receiver. The Y,- and the corresponding authentication
path values of the authentication tree are transmitted
from the transmitter to the receiver. Finally, the Y; are
as long as the channel has a suf?cient level of integrity.
authenticated at the receiver by computing the authen
In a public key cryptographic system, two keys are
tication path of the authentication tree between the Y,
used, one for enciphering and one for deciphering. Pub
and the rest of the authentication tree. U.S. Pat. No.
lic key algorithm systems are designed so that it is easy
4,661,658 to Matyas for “Offline PIN Validtion with
to generate a random pair of inverse keys PU for enci
DES” discloses a method of offline personal authentica
phering and PR for deciphering and it is easy to operate
tion in a multiterminal system. The method makes use of
with PU and PR, but is computationally infeasible to 20 a secret user PIN, a secret key and other nonsecret data
compute PR from PU. Each user generates a pair of
stored on a customer memory card, and a nonsecret
inverse transforms, PU and PR. He keeps the decipher
validation value and stored in each terminal connected
ing transformation PR secret, and makes the encipher
in a network. The nonsecret validation value is just the
ing transformation PU public by placing it in a public
root of an authentication tree calculated using a Merkle
directory. Anyone can now encrypt messages and send 25 tree authentication function. In each case, U.S. Pat. No.
4,309,569 to Merkle and U.S. Pat. No. 4,661,658 to
intended for him. It is possible, and often desirable, to
Matyas, the described inventions make use of a root of
enc'ipher with PU and decipher with PR. For this rea
an authentication tree calculated on data characterized
son, PU is usually referred to as a public key and PR is
as a piece of information in a list of information or one
usually referred to as a private key.
30 item in a list of items that remain constant. Neither U.S.
A feature of public key cryptographic systems is the
Pat. No. 4,309,569 to Merkle and U.S. Pat. No.
provision of a digital signature which uniquely identi
4,661,658 to Matyas teach how a tree authentication
?es the sender of a message. If user A wishes to send a
algorithm can be used to authenticate data in a dynami
signed message M to user B, he operates on it with his
cally and rapidly changing data ?le. In effect, U.S. Pat.
private key PR to produce the signed message S. PR 35 No. 4,309,569 to Merkle and U.S. Pat. No. 4,661,658 to
was used as A’s deciphering key when priva'cy was
Matyas ‘make use of a root of an authentication tree
desired, but it is now used as his “enciphering” key.
calculated on a list of information or items that remain
When user B receives the message S, he can recover the
constant, and hence these inventions are characterized
them to the user, but no one else can decipher messages
message M by operating on the ciphertext S with A’s
public PU. By successfully decrypting A’s message, the
receiver B has conclusive proof it came from the sender
A. Digital signatures can be produced either by de
crypting the data to be signed with the private key,
which works well when the data is short, or by ?rst
by a root of an authentication tree that remains con
40 stant. However, there are data processing environments
wherein it is desired to authenticate data elements in a
data ?le that is continually updated and changed. Such
processing environments are common in transaction
based systems, where each processed transaction may
hashing the data with a'strong one-way cryptographic
function and decrypting the so-produced hashed value
45 cause a central data ?le to be updated. The present
gorithm/Data Encryption Algorithm Key Distribution
institutions communicate with the purse, located at a
Method Based on Control Vectors”), cited in the Back
central facility, via an Electronic Funds Transfer net
invention described a method for adapting the Merkle
with the private key. Either method will work. Thus, in
tree authentication algorithm so that it may be applied
the above described method of DEA key distribution, B
advantageously to solve the problem of authenticating
sends A two quantities: (l) the encrypted key, ePU(K),
data elements in a dynamically changing data ?le.
and (2) a digital signature e.g., of the form (a) 50 The subject invention describes a cryptographic
dPR(ePU(K)) or dPR(hash(ePU(K))). A method for
method for implementing a particular kind of data ?le
producing digital signatures based on the hash of the
called an electronic purse. An electronic purse is a com
data to be signed is taught in co-pending patent applica
puter data ?le consisting of the account records of a
tion Ser. No. 07/748,407 (“A Hybrid Public Key Al
group of member ?nancial institutions. The member
ground Art. Examples of public key cryptography are
work. Each purse record contains a member ?nancial
provided in the following U.S. patents: U.S. Pat. No.
institution identi?er, an account balance, a transaction
4,218,582 to Hellman, et al., “Public Key Crypto
sequence number, and other appropriate data not rele
graphic Apparatus and Method;” U.S. Pat. No. 60 vant to the present discussion. Account balances can
4,200,770 to Hellman, et al., “Cryptographic Apparatus
range in the millions and billions of dollars. Hence, the
and Method;” and U.S. Pat. No. 4,405,829 to Rivest, et
integrity of the purse, and particularly the transaction
al., “Cryptographic Communications System and
driven process of updating the purse, is of critical im
portance. The integrity of the purse is achieved through
Method.”
.
-
U.S. Pat. No. 4,309,569 to Merkle for “Method of 65 use of a tree authentication algorithm. The tree authen
Providing Digital Signatures” discloses a method of
tication algorithm makes use of modi?cation detection
providing a digital signature for purposes of authentica
codes calculated with a public one-way cryptographic
tion of a message. This method utilizes an authentica
function.
5
5,231,666
6
Since the purse may contain many records, it is im
practical for these records to be stored within the secure
cords in the ?le or other items in the list of items or‘
other information in the list of information and does not
boundary of a cryptographic facility (i.e., crypto
require this information or any part thereof to be input
to the authentication algorithm in order to authenticate
graphic hardware). However, when purse records are
stored outside the CF, they are exposed to possible
change or replacement by an insider adversary. Thus, a
method is needed to preserve the integrity of the purse,
i.e., an equivalent level of integrity should be achieved.
the speci?ed record, item, or piece of information.
It is another object of the invention to provide a
means of authentication such that the root of the au
thentication tree can be updated dynamically and in a
secure way whenever a record in the ?le of records or
For a purse with records R1, R2, . . . , Rn, the security
objectives are these:
10
item in the list of items or piece of information in the list
1. The CF must permit records in the purse to be au
of
information changes.
thenticated independently. That is, the CF can au
It
is another object of the invention to provide a
thenticate record Ri without having access to other
means ‘to dynamically update the root of the authentica
records in the purse.
2. The CF must permit purse records to be updated 15 tion tree and the authentication tree itself such that the
process of updating the root and the authentication tree
without loss of integrity to the purse. Thus, if Ri’ is an
depends on the record, item, or piece of information
updated record produced from record Ri, the CF
being changed and a relatively small set of pre-cal
must recognize Ri’ as a valid record and Ri as an
culated values from the authentication tree (roughly
_ invalid record.
3. The CF must permit records in the purse to be up 20 log2(n) values where n is the number of records in the
?le or items in the list or pieces of information in the
dated independently. That is, the CF can update re
list), but is independent of other records in the ?le or
cord Ri without having access to other records in the
other items in the list of items or other information in
purse.
the list of information and does not require these other
The security objectives preclude straightforward, or
obvious authentication schemes based on message au 25 records, items, or information, or any part thereof to be
thentication codes calculated with the Data Encryption
Algorithm or digital signatures calculated with a public
input to the update procedure.
key algorithm (e.g., using the RSA algorithm). To illus
authentication means and update means such that as
trate this, suppose the KB is a clear key, in the crypto
records, items, or information is updated that the new
It is another object of the invention to provide an
graphic facility, used to generate and verify message 30 records, items, or information are recognized by the
authentication codes. Suppose that the electronic purse
authentication method as genuine whereas the old re
cords, items, or information, are recognized by the
authentication method as not genuine.
consists of entries (R1, MACl), (R2, MACZ), . . . , (Rn,
MACn), where each record Ri has an associated MACi
generated on Ri using the key KD. Each (Ri, MACi) is
easily validated in the cryptographic facility using KD.
But there is no effective way to update purse records
using the straightforward method of calculating a new
MAC on an updated record. This is so because the
35
SUMMARY OF THE INVENTION
These and other objects, features, and advantages are
accomplished by the invention disclosed herein.
A data processing system, method and computer
process of replacing purse record (Ri, MACi) with
program provide for the secure updating an electronic
updated purse record (Ri’, MACi’) does not invalidate 40 purse which includes a list of purse records. The
(Ri, MACi). Thus, an insider adversary with access to
method includes the step of de?ning an authentication
the purse and an old copy of (Ri, MACi) may subvert
the purse by substituting (Ri, MACi) in place of (Ri’,
MACi’). The problem is not remedied by changing KD,
tree with an authentication tree function comprising a
one-way function of purse records in the list, the au
thentication tree having a ?rst root for a ?rst list of the
since then MACs must be recalculated on all the purse 45
purse records and storing the ?rst root in a crypto
records. This could be costly for large ?les.
graphic facility. The authentication tree includes au
The same problem occurs if digital signatures are
thentication MDC vectors, one for each purse record in
used instead of message authentication codes, since
changing the public and private key pair each time a
record in the ?le is changed will likewise require the
signature for record in the ?le to be re-calculated. This
no advantage is gained from a public key algorithm
the list. The method includes the step of receiving a
transaction record in the cryptographic facility, includ
ing an authentication code, a cryptographic key, and an
authentication MDC vector, for updating an existing
purse record in the ?rst list. The method then performs
over a private or secret key algorithm.
.
the step of performing a purse update function in the
OBJECTS OF THE INVENTION
55 cryptographic facility. The method ?rst authenticates
the transaction record using the authentication code
It is therefore an object of the invention to provide an
and cryptographic key and authenticates the existing
improved method of ?le management in a data process
ing system.
purse record with the authentication MDC vector and
?rst root. The method next performs the step of substi
means for authenticating records in a ?le of records, or 60 tuting an updated purse record for the existing purse
record in the ?rst list, forming a second list. The method
an item in a list of items, or a piece of information in a
then computes with the updated purse record and the
list of information.
‘
?rst authentication MDC vector, a second path MDC
It is another object of the invention to provide a
It is another object of the invention to provide a
means of authentication such that the authentication
vector and a second root of the authentication tree for
method depends on the record, item, or piece of infor 65 the second list by computing a path MDC vector of the
mation being authenticated, and a root of an authentica
tion tree calculated on the ?le of records or list of items
authentication tree between the updated purse record
and the ?rst root and stores the second root in the cryp
or list of information, but is independent of other re
tographic facility.
*
7
5,231,666
8
The tree authentication algorithm de?nes the follow
BRIEF DESCRIPTION OF THE DRAWINGS
ing objects:
These and other objects, features, and advantages of
the invention will be more fully appreciated with refer
ence to the accompanying ?gures.
FIG. 1 illustrates a binary tree with 25—l=3l ele
Object
Description
Record File (RF)
The RF contains t records, denoted {R1,
ments.
R2, . . . , R,}, which represent the records to
FIG. 2 illustrates a cryptographic network consisting
of multiple cryptographic systems interconnected via a
10
communications network.
FIG. 3 illustrates a cryptographic system consisting
of a Cryptographic Facility (CF) 1, a Cryptographic
Key Data Set. (CKDS) 2, a Cryptographic Facility
be authenticated by the tree authentication
algorithm. The records in RF can be actual
records or dummy records (e.g., allocated
and initialized to ASCII zeroes).
MDC Vector
(MDCV)
relationship 2"-2<t§2"- 1, where n,n— l,
and n-2 are non-negative integers. Each
element i in MDCV, denoted MDCV(i) is a
l28-bit Modi?cation Detection Code
(MDC). The MDCV is just a linear repre
Access Program (CFAP) 3, and using Application Pro
15
grams (APPL) 4.
FIG. 4 illustrates a Cryptographic Facility 1 consist
ing of a CF Environment 10, Cryptographic Algo
rithms 11, and an Instruction Processor 12, enclosed
sentation of a binary tree where each
element of the tree, j, has an MDC associ
ated with it, denoted MDCVO). Where
convenient, the elements MDCV(1),
within a Secure Boundary.
FIG. 5 illustrates a CF Environment 11 containing 20
storage for 64 128-bit Root MDC registers 112 and 64
MDCV(2), . . . , MDCV(s) may sometimes
be expressed as MDC‘, MDCZ, . . . , MDC,.
The algorithm for producing the MDC
values in MDCV is given below.
Root MDC register ?ags 113.
Root MDC
FIG. 6 illustrates the relationship between indexes of
(RMDC)
records and null records in the Record File (RF) and
Path Vector (PV)
25
indexes in the MDC Vector (MDCV).
FIG. 7 illustrates a cryptographic system and the
cryptographic system components needed to implement
the tree authentication algorithm.
FIG. 8 illustrates a transaction message containing an
account number to be debited, an account number to be
Path MDC Vector
30 (PMDCV)
institution account number, an account balance, a trans
Authentication
action sequence number, and other optional account
Vector (AV)
data.
Authentication
MDC Vector
DESCRIPTION OF THE BEST MODE FOR
CARRYING OUT THE INVENTION
A tree authentication algorithm makes use of a public
elements, except for the 2"-1 ?nal elements, which have
describe the path from a ?nal element in the
tree to the root element. An algorithm for
calculating PV is given below.
For a binary tree of s=2"—l elements, the
PMDCV is a vector of n MDCs, denoted
the MDCs in MDCV that correspond to the
indexes in PV.
For a binary tree of s=2"-l elements, the
AV is a vector of n—-l index values, de
are derived from PV using the following
algorithm. For i=1, 2,... , n-l, AV(i)=
PV(i+ 1) if i is and even integer and
AV(i)=PV(i-l) if i is an odd integer.
FIG. 11 is a ?ow diagram of the invention.
no successor elements. Those skilled in the art will
{11, I2, . . . , In}. These index values
noted {I}, I1, . . . , I,,_1}. The indexes in AV
FIG. 10 illustrates a cryptographic system imple
menting an Update Purse (UPURSE) instruction.
The tree authentication algorithm method makes use
of a binary tree of 2"--l elements. Beginning with a
root element, each element in the tree has two successor
For a binary tree of s=2"-l elements,
PV is a vector of n index values, denoted
2, . . . , it. That is, the PMDCV contains just
FIG. 9 illustrates a purse record containing a ?nancial
Algorithm (DEA). Modi?cation Detection Codes are
described in US. Pat. No. 4,908,861 by Brachtl et al.
Those skilled in the art will recognize that other public
one-way cryptographic functions could be used with
the invention without detracting from the spirit of the
invention.
MDC Vector, denoted MDCV(1).
PMDCV(i)=MDCV(PV(i)) for i=1,
and other optionslinformation.
tion makes of a public one-way cryptographic function
used in the calculation of a Modi?cation Detection
Code (MDC) which is based on the Data Encryption
The RMDC is de?ned as the ?rst element in
{MDC|, MDCZ, . . . , MDCn}, where
credited, an amount, a transaction sequence number,
one-way cryptographic function. The described inven
MDCV is a vector of s=2"—l elements,
where n is selected such that it satis?es the
(AMDCV)
For a binary tree of s=2"-l elements, the
AMDCV is a vector of n--] MDCs, de
noted {MDC1, MDCZ, . . ., MDC,,_1},
where AMDCV(i)=MDCV(AV(i)) for
i=1, 2, . . . , n-l. That is, the AMDCV
45
contains just the MDCs in MDCV that
correspond to the indexes in AV.
The Record File may be static or dynamic. In a static
?le, records are not added, deleted, or updated. In a
dynamic ?le, the opposite is true. Records in the Re
cord File may be ?xed or variable length. MDCs can be
calculated on records of any length. The Record File
can be managed either by the system software or by the
application program.
The Record File may contain actual records, dummy
records, or both. Altogether, the Record File contains t
records. A dummy record is a record for which space
has been allocated in the Record File. For convenience,
it is assumed that dummy records are initialized to
recognize that tree authentication algorithms could also 60 ASCII zeroes.
be based on other than binary trees without detracting
Before records in the Record File can be authenti
from the spirit of the invention, so that each element in
cated, an MDC Vector must be produced. The MDC
the tree may in fact have three, four, etc., successor
Vector is calculated from the records in the Record File
elements.
using a Generate Modi?cation Detection Code
FIG. 1 illustrates a binary tree with 25-l=3l ele 65 (GMDC) instruction described below. Hence, if the
ments, which are labelled 1, 2, . . . , 31. The root element
Record File is static, then the MDC Vector will be
is labelled 1; the 2"-': l6 ?nal elements are labelled 16,
static. Likewise, if the Record File is dynamic, then the
17, . . . , 31.
MDC Vector will be dynamic. One or more MDCs in
5,231,666
9
the MDC Vector must be recalculated and changed
whenever a record in the Record File is added, deleted,
or updated.
The ?rst element in the MDC Vector is the Root
MDC. In addition to being stored in the MDC Vector,
the Root MDC is also loaded and stored within the
secure hardware using a Load Root MDC (LRMDC)
10
then the PV vector of 11 index values (i1, i2, . . . 1
is
calculated as follows:
instruction (described below). The copy of the Root
MDC maintained in the secure hardware is a reference
in: : integer(i,, _1+ 2).
value against which other calculated Root MDC values
are compared as part of the record veri?cation process.
The Root MDC maintained in the secure hardware
Algorithm for Calculating Authentication Vector (AV)
must be changed whenever a record in the Record File
If MDCV is an MDC Vector with 2"-l elements
is added, deleted, or updated. This may occur directly
by issuing an LRMDC instruction or indirectly as the 15 and i is an index whose value ranges from 2" -1 to 2"— 1,
then the AV vector of n-l index values (i1, i2, . . . ,
result, or by-product of the execution of some other
i,,_.1)
is calculated as follows:
hardware instruction. The MDC Vector can be man
aged by the system software or by the application pro
gram. However, for practical considerations, the Re
i|:= opposite(i).
cord File and MDC Vector are assumed to be managed
by the same party (e.g., either the system software or
i2: = opposite(intcrger(i1 + 2)).
i3 : = opposite(interger(i2 + 2)).
the application program).
Algorithm for Calculating MDC Vector (MDCV)
The MDCV contains 2"—l elements. The 2"-1 ele
ments in MDCV whose index values range from 2"-1 to
The Authentication MDC Vector is created dynami
2"—l (i.e., corresponding to the 2"“1 ?nal elements in a
cally each time a record in the Record File is authenti
2"—l element binary tree) are calculated from the t
cated by the secure hardware. The Authentication
records in Record File and 2"—1--t null records. The 30 MDC Vector, and the Root MDC stored in the secure
null records represent nonexistent records in Record
hardware, are used by the hardware to authenticate the
File. The remainder of the elements, MDCV(l),
record. Each record in the Record File has a different
MDCV(2), . . . , MDCV(2"-1—l) are calculated from
Authentication MDC Vector associated with it. The
Authentication MDC Vector is created from the record
to be authenticated and the MDC Vector.
To produce the Authentication MDC Vector from a
‘ For i=2"-1, 2"-1+ l, . . . , 2"— 1, MDCV(i) is calcu
lated with a public one-way cryptographic function,
given record, it is ?rst necessary to know or determine
called oneway, as follows:
the relative position of the record in the Record File.
For example, given a record R, one must be able to
40 determine that R is, say, the ith record in the Record
File. Thus, for convenience, a mapping function
elements
MDCV(2"-1),
MDCV(2""1+ l),
.
.
.
,
MDCV(2"- l).
FINDX is assumed to exist that maps a given record to
its index value in the Record File. For example, if R;
denotes the ith record in the Record File, then FINDX
45
(R,-)=i. An algorithm for calculating the Authentica
tion MDC Vector from a given record, say R,-, and the
MDC Vector is provided below.
If the Record File and MDC Vector are maintained
MDCV(2"— 1):= oneway(concat(2"“ 1,null)).
50
For elements i=1, 2, . . . , 2"-l)—l, MDCV(i) is
calculated as follows:
‘
by the system software, then the Authentication MDC
Vector is created by the system software, If the Record
File and MDC Vector are maintained by the application
program, then the Authentication MDC Vector is cre
ated by the application program.
The Path MDC Vector is created dynamically each
55 time a record in the Record File is authenticated and
Note: The function oneway is used merely as a means to conveniently
describe the operation of the tree authentication algorithm. A more
then updated. Each record in the Record File has a
different Path MDC Vector associated with it. The
Path MDC Vector is created in the secure hardware
using the Authentication MDC Vector
precise and detailed algorithm for calculating MDCs using a Generate
MDC (GMDC) routine is given below.
60 record R and the updated record R’.
associated with
The Path Vector and Authentication Vector are de
A new Root MDC is also calculated with the Au—
?ned here only to help explain the concept of tree au
thentication MDC Vector and the just-computed Path
thentication. In an actual implementation, these two
vectors are not needed.
Algorithm for Calculating Path Vector (PV)
If MDCV is an MDC Vector with 2"—l elements
and i is an index whose value ranges from 2""1 to 2" — l,
MDC Vector. The secure hardware replaces the cur
rent Root MDC with the new Root MDC.
65
The updated record and Path MDC Vector are also
returned to the system software, and to the application
program if the application program maintains the Re
cord File and the MDC Vector. The updated record
11
5,231,666
and Path MDC Vector are then used to update the
Record File and MDC Vector, respectively.
CRYPTOGRAPHIC SYSTEM MODEL
The tree authentication algorithm is implemented
within a cryptographic system described by the follow
ing architectural model.
FIG. 2 illustrates a cryptographic network consisting
of multiple cryptographic systems interconnected via a
communications network. Each system supports the
processing of one or more applications which require
access to cryptographic services (e.g., for the encryp
12
via the CFAP-to-CF interface 9 (i.e., by execution of
certain CF instructions which read input parameters
and load them into the CF environment 11) or via an
optional Physical Interface 8 which permits cryptovari
ables to be loaded directly into the CF Environment 11
(e.g., via an attached key entry device).
The secure boundary enclosing the cryptographic
facility is achieved through the use of one or more of ~
the following features: tamper-resistant design, tamper
detection circuitry, and zeroization of keys. Tamper
resistant designs enables the CF to resist probing by an
insider adversary who has limited access to the CF.
tion, decryption, and authentication of application data
Tamper-detection circuitry enables the CF to detect
and the generation and installation of cryptographic ' attempts at physical probing or intrusion, e.g., through
keys). The cryptographic services are provided by a 15 the use of a variety of electro-mechanical sensing de
secure cryptographic facility in each system. The net
vices. Zeroization circuitry enables the CF to automati
work provides the means for the systems to send and
cally erase its keys whenever an attempted probing or
receive encrypted data and keys. Various protocols
intrusion has been detected.
(i.e., formats and procedural rules) govern the exchange
of cryptographic quantities between communicating
systems in order to ensure interoperability but are be
yond the scope of this document.
FIG. 3 illustrates a cryptographic system consisting
of a Cryptographic Facility (CF) 1, a Cryptographic
Key Data Set (CKDS) 2, a Cryptographic Facility
Access Program (CFAP) 3, and using Application Pro
grams (APPL) 4.
A typical request for cryptographic service is initi
The Instruction Processor 12 consists of a set of in
20 structions and a set of internal routines. The CF instruc
tions are invoked at the CFAP-To-CF interface 9, and
provide cryptographic services to the CFAP 3. The
internal routines are invoked only from within the CF 1.
They represent a set of algorithms and processing func
25 tions that are common to many CF instructions.
The tree authentication algorithm makes use of a
public one-way cryptographic function based on the
Data Encryption Algorithm (DEA). The DEA is de
ated by an APPL 4 via a function call to the CFAP 3 at
scribed in the American National Standards Institute
an APPL-To-CFAP interface 5. The service request 30 (ANSI) Data Encryption Algorithm (DEA) X3.92
includes key and data parameters, as well as key identi
?ers which the CFAP 3 uses to access encrypted keys
from the CKDS 2 at a CFAP-To-CKDS interface 6.
The CFAP 3 processes the service request by issuing
1981. See American National Standard X3.92-1981,
Data Encryption Algorithm, American National Stan
dards Institute, New York (Dec. 31, 1981). The DEA is
a symmetric algorithm which encrypts or decrypts a 64
one or more cryptographic instructions to the CF 1 at a 35 bit input with a 64 bit key to produce a 64 bit output.
CFAP-To-CF interface 7. (The CF may also have an
optional physical interface 8 for direct entry of crypto
graphic variables into the CF.) Each cryptographic
The 64 bit key speci?ed to the algorithm consists of 56
key bits used by the algorithm and 8 non-key bits, which
optionally may be used for error detection. The algo
rithm speci?ed in this standard is identical to the algo
rithm speci?ed in Federal Information Processing Stan
dard Publication 46, entitled Data Encryption Stan
instruction invoked at the CFAP~To-CF interface 7 has
a set of input parameters processed by the CF to pro 40
duce a set of output parameters returned by the CF 1 to
the CFAP 3. In turn, the CFAP 3 may return output
dard.
parameters to the APPL 4; it may also use the output
The CF Environment 11 contains storage for 64 128
parameters as input parameters to subsequently invoked
bit Root MDC registers 112 and 64 Root MDC register
instructions. If the output parameters contain encrypted 45 ?ags 113, as'illustrated in FIG. 5. The 64 Root MDC
keys, then CFAP 3 may, in cases, store these encrypted
registers are stored in a Root MDC Table, not shown in
keys in the CKDS 2.
FIG. 5. The 64 Root MDC register ?ags are stored in a
FIG. 4 illustrates a Cryptographic Facility 1 consist
CF State Vector (not shown in FIG. 5) together with
ing of a CF Environment 10, Cryptographic Algo
other ?ags and state variables de?ning the state of the
rithms 11, and an Instruction Processor 12, all of which 50 cryptographic facility 1.
are enclosed within a Secure Boundary. The Instruction
The Root MDC registers 112 are indexed as Root
Processor 12 is a functional element which executes
MDC register(i), for i=0, 1, . . . , 63. The Root MDC
cryptographic instructions invoked by the CFAP 3 at
the CFAP-to-CF interface 9. For each instruction, the
register ?ags 113 are indexed as Root MDC register
?ag(i), for i=0, 1, . . . , 63, where ?ag values 0 and l are
CFAP-to-CF interface 9 de?nes (1) an instruction mne 55 de?ned as 0=‘not initialized’ and l=‘initialized’.
monic or operation code used to select a particular
Where convenient, the subject invention shall be de
instruction for execution, (2) a set of input parameters
scribed on the basis of only a single Root MDC stored
passed from the CFAP to the CF, and (3) a set of output
parameters returned by the CF to the CFAP. The In
struction Processor 12 executes the selected instruction
by performing an instruction-speci?c sequence of cryp
tographic processing steps whose control ?ow and
subsequent output depend on the values of the input
in a single Root MDC register.
Routines
A set of routines is speci?ed for implementing parts of
the tree authentication algorithm. Some routines are
implemented in the CF and called by the CF instruc
parameters and the contents of the CF Environment 10.
tions and some are implemented in the CFAP and called
The CF Environment 10 consists of a set of crypto 65 by the CFAP functions.
graphic variables (e.g., keys, ?ags, counters, CF con?g
uration data, etc.) which are collectively stored within
the CF. The CF Environment variables are initialized
The following is a list of simple mathematical func
tions used by the routines listed in this section, and
elsewhere.
5,231,666
13
14
integer(x) truncates x, as necessary, to produce an inte
i: The index of record R in the Record File.
ger value.
opposite(x) If x is even, then opposite(x) returns x+ 1. If
x is odd, then opposite(x) returns x- l.
R-length: The length of R in bytes. R-length must be
a multiples of 8. If required, padding must be performed
by the software prior to its being processed by the hard
ware. This parameter is required only when process
rule=0.
R: A record in Record File. This parameter is re
concat(x1, x2, . . . , x,-) denotes the concatenation of x1,
x2, . . . , x,-.
extract(x,y,z) denotes to return 2 bytes starting at byte
position y in variable x
replace (w,x,y,z) denotes to replace 2 bytes starting at
byte position y in variable w with the z-byte variable
quired only when process-rule=0.
j: The number of elements in the MDCV associated
with Record File.
Outputs:
x.
oneway(x) denotes to return a public one-way crypto
graphic function of x. (The de?nition of oneway(x) is
rec-length: The length of rec in bytes.
rec: A formatted record.
purposely left imprecise.)
Algorithm Description:
15
Generate MDC (GMDC)
The Generate MDC routine is de?ned as follows:
GMDC(mode,text-length,text->MDC)
Inputs:
mode: One of the following:
The RFORMl routine builds a formatted record
from the inputs i and R. An objective of the RFORMl
routine is to produce a formatted record that is indepen
dent of the number of elements in the MDC Vector.
While the formatted record may depend on its relative
20 position in Record File, it is independent of its relative
position in the MDC Vector (binary tree). The
RFORMl routine represents only one possible way to
0: Two encipherments per 64-bit input data block
produce a formatted record.
1: Four encipherments per 64-bit input data block.
1. Perform consistency checking:
text-length: The length of the input text in bytes. For 25 a. Verify that j+l is a power of 2, i.e., ?nd the posi
convenience, text-length is a multiple of 8 bytes. Pad
tive integer n such that 2"— l =j.
ding of the input text, if required, is assumed to be per
b. Verify that n-2 and n-l are non-negative inte
formed before the text is processed by the GMDC rou
tine.
gers.
:
text: The input text to be MDC’ed.
Outputs:
Continue if checking succeeds; otherwise set CC
status ?ag and jump to step 4.
I
MDC: The 128-bit MDC (Modi?cation Detection
-
2. Build Header
Code)
Algorithm Description:
b. If process-rule=0, set Y1:=X’00’
c. Else (process-rule: 1) set Y1:=X’Ol'
An precise speci?cation of the Generation MDC
routine is unimportant to the speci?cation of the tree
authentication algorithm. The MDC produced by the
GMDC routine is a public one-way cryptographic func
tion of the input text.
Find Index (FINDX): The Find Index routine is de
d. Replace(HR,Yl,O,l)
e. Set Y2:=i (where Y2 is a 6-byte binary value)
f. Replace(HR,Y2,2,6)
3. Build Output Formatted Record:
a. If process-rule=0, then do:
1) Set rec-length:=8
?ned as follows:
2) Set recz=HR
b. Else (process-rule: 1) do:
1) Set rec-length: = 8 + R-length
FINDX(reeord->i).
Inputs:
45
record: One of the t records in Record File.
2) Set rec:=concat(HR,R)
4. Produce outputs:
Outputs:
Record Format Two (RFORM2):
i: The index of record in Record File, where i is an
integer satisfying the relation léiét.
The Record Format Two routine is de?ned as fol
lows:
Algorithm Description:
The FINDX routine maps-a record to the index of
that record in the Record File. FINDX is a routine that
must be de?ned by the installation, since the records in
Record File, their size, number, and data content are
highly installation-dependent.
~
Inputs:
.55
i: A positive integer.
Record Format One (RFORMl):
MDCl: A 128-bit MDC (Modi?cation Detection
Code) associated with element 2Xi in the MDC Vector.
The Record Format One routine is defined as fol
lows:
M‘DCZ: A 128-bit vMDC associated with element
2Xi+l in the MDC Vector.
RFORMl(process-mle,i,R-length,R,->rec-length,
rec)
Outputs:
rec-length: The length of rec in bytes.
rec: A formatted record.
Algorithm Description:
Inputs:
‘
The RFORM2 routine builds a formatted record
process-rule: Indicates the processing mode for R, as 65 from the inputs i, MDCl, and MDCYZ. The RFORM2
follows:
routine represents only one possible way to produce a
0: i is the index of an actual record in Record File
1: i is the index of a null record
formatted record.
1. Perform consistency checking:
5,231,666
15
a. Verify i a positive integer.
2. Build Header
16
b. Verify MDC=Root-MDC
5. Produce output CC and CC status ?ags.
a. Set HR:=l6X'0O'
Pad Record (PADR):
b. Set Yl:=X'02'/*X'O2’ distinguishes the header
from one in which X'OO' or X’Ol' is stored "‘/
5
c. Replace(HR,Yl,0,l)
(I. Set Y2:=i, where Y2 is a 6-byte binary value.
e. Replace(HR,Y2,2,6)
Continue if checking succeeds; otherwise set CC
status flag and jump to step 4.
PADR(Rl-length,Rl—>R2-length, R2)
Inputs:
Rl-length: The length of record R1 in bytes.
.
R1: A record in Record File.
Note: The value i is the index of the MDC element in MDC Vector to
be produced from the formatted record output from the RFORMZ
routine. The value i is made part of the formatted record to add crypto
graphic strength to the tree authentication algorithm. It blocks attacks
where one subtree is substituted for another in the authentication tree.
3. Build Output Formatted Record:
a. Set rec-1ength:=40
The Pad Record routine is de?ned as follows:
Outputs:
R2-length: The length of record R2 in bytes. R2
length must be a multiple of 8 bytes.
15
R2: The resultant record obtained by padding record
Rl.
Algorithm Description:
b. Set rec:=concat(HR,MDCl, MDC2)
4. Produce outputs:
The PADR routine pads records of a whole number
of bytes so that the padded record is a multiple of 8
Verify Record (V REC):
20
The Verify Record routine is de?ned as follows:
bytes. The PADR routine pads all records irrespective
of whether they are already a multiple of 8 bytes. The
padding algorithm is the same as that implemented in
the MDC Generate (CSNBMDG) service de?ned by
the Common Cryptographic Architecture. See Com
VREC(root-MDC,i,R-length,R,hash-rule,j
,AMDCV-sRC).
25
Inputs:
root-MDC: The root-MDC to be used to authenticate
R. .
mon Cryptographic Architecture: Cryptographic Ap
plication Programming Interface Reference, SC40
1675, International Business Machines Corporation,
1990.
i: The index of record R in the Record File.
R-length: The length of R in bytes. This parameter is 30 Generate New Path MDC Vector (GNPMDCV):
The Generate New Path MDC Vector routine is de
?ned as follows:
R: A record in Record File.
required only when process-rule=0.
hash-rule: Indicates the hash algorithm, as follows:
0:MDC-2 algorithm
lzMDC-4 algorithm
j: The number of elements in AMDCV. _
Inputs:
-
AMDCV: An Authentication MDC Vector.
hash-rule: Indicates the hash algorithm, as follows:
Outputs:
OzMDC-Z algorithm
1:MDC-4 algorithm
RC: A Return Code, as follows
Ozrecord veri?cation successful
l6:record veri?cation unsuccessful.
i: The index of record R in the Record File.
R~length: The length of record R in bytes.
Algorithm Description:
R: A record in Record File.
1. Perform Consistency Checking:
n: The number of elements in PMDCV and one more
a. Verify that j-l is a a non-negative integer.
b. Verify that 2j-1<i§2J'.
c. Verify that AMDCV contains j elements.
Continue if checking succeeds; otherwise set CC
status flag and jump to step 4.
2. Calculate MDC on (i,R):
a. Set nl:=2"—1+i—1.
,recl—->recl-length,recl)
Algorithm Description:
>
GMDC(hash-rule,rec2-length
,rec2->MDC)
e. Set n3:=nl./*initialize n3 for next step */
3. For k=l to <n-l> do:
a. Set n1:=n3.
b. Set n2:=opposite(nl).
c. Set n3:=integer(nl -:-2).
d. If n1 < n2, then perform RFORM2(n3,MD
C,AMDCV(k)—>rec-length,rec)
e.
Else
(n1 >n2)
perform
3,AMDCV(k),MDC—>rec-length,rec)
1. Perform Consistency Checking:
a. Verify that AMDCV has n elements.
b. Verify that n-2 and i are non-negative integers.
c. Verify that 2"-2<i§2""1.
Continue if checking succeeds; otherwise set CC
status ?ag and jump to step 5.
RFORM2(n
4. Perform veri?cation step:
a. Verify n3=l (i.e., that the root has been calcu
'
2. Calculate PMDCV(l):
a. Perform PADR(R-length,R->recl-length,recl)
b. Perform RFORMl(process-rule=0,i,recl-length
,recl->recl-length,rec2)
0.
f. Perform GMDC(hash-rule,rec-length,rec—>MDC)
lated).
,
PMDCV is the path MDC vector produced from i, R,
c. Perform RFORMl(process-rule=0,i,R1-length
Perform
Outputs:
PMDCV: A Path MDC Vector with n elements.
50 and AMDCV.
b. Perform PADR(R-length,R->recl-length,rec1)
d.
than the number of elements in AMDCV.
AMDCVz‘ An Authentication MDC Vector with
45
n-l elements.
Perform
GMDC(hash-rule,rec2~length
,rec2—>MDC)
d. Set PMDCV(1):=MDC.
65 3. Initialize n3:
a. Set n3:=2"-1+i--l.
4. Calculate remainder of PMDCV:
For k=2 to n do:
5,231,666
17
a. Set n1:=n3
b. Set n2:=opposite(n1)
c. Set n3:=integer(nl —:2)
(n1 > n2)
GMDC(hash-rule,recl-length
,rec1—->MDC) /* GMDC is a CF instruction */
5
C,AMDCV(k — l)—>rec-length,rec)
Else
Invoke
c. Set nl:=2"-1+i—1.
d. If n1<n2, then perform RFORM2(n3,MD
e.
18
b.
perform
RFORM2(n
d. Set new-MDCV(n1):=MDC
5. Initialize remainder of new-MDCV:
For i=2"-1—1 to 1 by-l do:
a. Set n1:=2><i.
3,AMDCV(k - 1),MDC—->rec-length,rec)
f. Perform GMDC(hash-rule,rec-length,rec—>MDC)
b. Perform RFORM2(i,MDCV(n1),MDCV(n1+1)
g. Set PMDCV(k):=MDC
5. Produce outputs:
—>recl-length,recl)
c.
MDC Vector Initialize (MDCVI)
_
Invoke
GMDC(hash-rule,recl-length
,rec1-+MDC) /‘ GMDC is a CF instruction “/
d. Set new-MDCV(i):=MDC
6. Produce outputs.
The MDC Vector Initialize routine is used by the
CFAP to produce an MDC Vector for a given Record
File.
The MDC Vector Initialize routine is de?ned as fol
lows:
MDC Vector Update (MDCVU)
The MDC Vector Update routine is used by the
CFAP to update the MDC vector in response to a
change in the Record File due to adding, deleting, or
updating a record in Record File.
20
The MDC Vector Update routine is de?ned as fol
lows:
Inputs:
hash-rule: Indicates the hash algorithm, as follows:
0: MDC-2 algorithm
1: MDC-4 algorithm
Inputs:
s: The number of elements in MDCV
s: The number of elements in MDCV
MDCV: A ?le of s 128-bit records initialized to zero.
The elements in MDCV are uninitialized, i.e. set to
MDCV: A ?le of s 128-bit MDC values.
i: The index of a record in Record File.
PMDCV: A Path MDC Vector for a record in Re
zero.
30 cord File whose index is i.
t: The number of records in record-?le.
Outputs:
Outputs:
0: success
‘
new-MDCV: A copy of MDCV which has been
new-MDCV: A copy of MDCV which has been
initialized.
RC: A Return Code, as follows
updated.
RC: A Return Code, as follows
0: success
'
16: failure.
16: failure.
Algorithm Description:
Algorithm Description:
1. Perform Consistency Checking:
1. Perform Consistency Checking:
a. Verify that MDCV has s elements.
a. Verify that MDCV has s elements.
b. Verify that s+l is a power of 2, i.e., ?nd the posi
b. Verify that s+1 is a power of 2, ?nd positive inte
ger n such that 2"- 1 =5.
_ tive integer n such that 2"—1=j.
0. Verify that n—2>0.
c. Verify that n—2 is a non-negative integers.
(1. Verify that 2"-2<t§2""1.
e. Verify that PMDCV has n records.
e. Verify that record-?le contains t elements.
Continue if checking succeeds; otherwise set CC
status flag and jump to step 6.
2. Initialize new-MDCV:
Continue if checking succeeds; otherwise set CC
status flag and jump to step 6.
2. Initialize new-MDCV:
a. Set new-MDCV:=MDCV
a. Set new-MDCV:=MDCV
3. Update ?rst element:
3. Process records in record-?le:
For i=1 to t do:
50
.
b. Set new-MDCV(i1):=PMDCV(l)
4. Update remainder of elements:
a. Read record R; from record-?le.
b. Perform FINDX(Ri->j)
_
For kequal2 to n do:
'c. Verify i: j. Continue if checking succeeds; other
a. Set i1:=integer(i1+2)
wise set RC:= 16 and jump to step 6.
b. Set new-MDCV(i1):=PMDCV(k)
(1. Set Ri-length:=length of R,-.
e. Perform PADR(Ri-length,Ri--->rec1-length,recl)
5. Verify i1 =1 /"‘ ensure tree has been traversed '/
6. Produce outputs:
/" ensure recl is a multiple of 8 bytes */
f. Perform RFORM1(process-ru1e=0,i,rec1-length
,rec 1->rec2-length,rec2)
g.
Invoke
GMDC(hash-rule,rec2-length
'
Generate Authentication MDC Vector (GAMDCV)
The Generate Authentication MDC Vector routine is
de?ned as follows:
,rec2—>MDC) /* GMDC is a CF instruction "‘/
h. Set n1:=2""1+i-—1.
i. Set new-MDCV(n1): =MDC.
. Process null records:
65
For i=t+1 to s do:
a.
Perform
length,rec1)
RFORM1(process-rule=1,i,,,—->recl
-
Inputs:
i: The index of a record in Record File, where i is an
'
integer satisfying the relation léiét.
j: The number of ‘elements in MDCV.
5,231,666
19
MDCV: An MDC Vector produced from the Record
File containing a record whose index in the Record File
20
index: A value from O to 63 that references one of 64
Root-MDC registers in the secure hardware.
IS 1.
new-MDC: A new 128-bit MDC to be loaded into the
Outputs:
Root-MDC register designated by index.
Outputs:
k: The number of elements in AMDCV.
AMDCV: An Authentication MDC Vector.
?ag: A value indicating whether old-MDC exists, as
follows:
Algorithm Description:
For a description of the functions called integer and
opposite, see the section entitled Mathematical Func
tions.
0: no old-MDC exists
1: old-MDC exists. .
old-MDC: A l28-bit MDC (Modi?cation Detection
Code), if ?ag: 1.
1. Perform consistency checking:
Algorithm Description:
a. Verify that MDCV has j elements.
b. Verify that j+l is a power of 2, i.e., find the posi
The following assumptions are made about the secure
hardware. The secure hardware contains 64 Root
tive integer n such that 2"—- l =j.
0. Verify that n—2 and n-l are non-negative inte
gers.
MDC registers indexed as 0, 2, . . . , 63. Associated with
each Root-MDC register is a l-bit Root~MDC register
?ag (O=empty, l=full).
d. Verify that 2"-2<i§2”-1.
The LRMDC instruction assumes that the secure
Continue if checking succeeds; otherwise set CC
status ?ag and jump to step 5.
hardware provides for the storage of several Root
2. Determine n and initialize AMDCV(n):
MDC values, so that the tree authentication algorithm
b. Set n2: =opposite(n 1).
can authenticate records in several Record Files. An
other way to handle multiple Record Files is to make
0. Set AMDCV(1): = MDCV(n2).
use of a Record File of Root MDC values and to store
3. Initialize remainder of AMDCV:
25 single Root MDC is calculated on the Record File of
a single Root MDC in the secure hardware, where this
Root MDC values. Those skilled in the art will recog
nize that the subject invention covers the case of multi
ple Record Files and the case of a Record File of Root
MDC values.
a. For n3=2 to (k-l) do:
1) Set nl:=integer(nl+2).
2) Set n2:=opposite(n2).
_
3) Set AMDCV(n3):=MDCV(n2).
1. Perform Consistency Checking:
4. Calculate and verify last path vector index, n2:
a. Set n2:=integer(nl -:—2).
b. Verify n2=l.
5. Produce outputs:
a. Verify that index is a value 0, l, . . . , 63.
2. Produce outputs ?ag and old-MDC:
a. Set ?ag:=Root-MDC register flag (index)
b. Set old~MDC:=Root-MDC register (index)
35 3. Load new-MDC:
CF Instructions
a. Set Root-MDC register ?ag (index):=‘full’
The following set of instructions permits the tree
b. Set Root-MDC register (index):=new-MDC
authentication algorithm to be implemented by the CF.
Read Root MDC (RRMDC)
Generate MDC (GMDC)
The Read Root MDC instruction is de?ned as fol
The Generate MDC instruction is de?ned as follows:
lows:
GMDC(mode,text-length,text—>MDC).
Inputs:
RRMDC(index->flag, MDC).
45
Inputs:
'
mode: One of the following:
index: A value from 0 to 63 that references one of 64
0: Two encipherments per 64-bit input data block
Root-MDC registers in the secure hardware.
1: Four encipherments per 64-bit input data block.
Outputs:
text-length: The length of the input text in bytes. For
flag: A value indicating whether MDC exists, as fol
convenience, text-length is a multiple of 8 bytes. Pad 50 lows:
'
ding of the input text, if required, is assumed to be per
0: no MDC exists
formed before the text is processed by the GMDC rou
1: MDC exists
tine.
MDC: A l28-bit MDC (Modi?cation Detection
text: The input text to be MDC’ed.
Outputs:
Code), if ?ag: 1.
55
MDC: The 128-bit MDC (Modi?cation Detection
Code)
Algorithm Description:
The GMDC instruction is implemented by making a
Algorithm Description:
The following assumptions are made about the secure
hardware. The secure hardware contains 64 Root
MDC registers indexed as 0, 2, . . . , 63. Associated with
each Root~MDC register is a 1-bit Root-MDC register
subroutine call to the GMDC routine (see the section 60
?ag (0=empty, l=full).
entitled Routines). The GMDC instruction is just the
1. Perform Consistency Checking:
externalized version of the internal GMDC routine.
Load Root MDC (LRMDC): The Load Root MDC
instruction is de?ned as follows:
LRMDC(index, new-MDC-r?ag, old-MDC)
Inputs:
a. Verify that index is a value 0, l, . . _. , 63.
2. Produce outputs ?ag and old-MDC:
a. Set ?ag:=Root-MDC register ?ag (index)
b. Set MDC:=Root-MDC register (index)
Update Records (URECS)
The Update Records instruction is de?ned as follows:
5,231,666
21
22
1) Set AMDCVj(l);=PMDCVi(l)
URECS(index, hash-rule, Ri-length, Ri, Rj-length,
Rj, Ri'-length, Ri', Rj’-length, Rj’, s, AMDCVi,
AMDCVj-m, PMDCVi, PMDCVj. RC).
2) Jump to step 5. /* no more elements need to be
updated */
d. For k=2 n—l do:
Inputs:
1) Set i1:=integer(i+2))
:
2) Set jl:=opposite(integer(jl+2))
index: A value from 0 to 63 that references one of 64
3) Ifil=jl then do:
Root-MDC registers in the secure hardware.
hash-rule: Indicates the hash algorithm, as follows:
-.
a) Set AMDCVj(k): = PMDCVi(k)
b) Jump to step 5. /‘ no more elements need to
0: MDC-2 algorithm
1: MDC-4 algorithm
Ri-length: The length of record Ri in bytes.
Ri: A record in Record File whose position in the ?le
is speci?ed by index i.
Rj-length: The length of record Rj in bytes.
Rj: A record in Record File whose position in the ?le
be updated ‘/
5. Calculate PMDCVj:
6. Produce outputs: /" Note that PMDCVi must be
processed before PMDC'v'j to update MDCV. Some
is speci?ed by index j.
Ri'-length: The length of record Ri' in bytes.
old elements in PMDCVi may be overlaid by new
elements in PMDCVj '/
Ri’: A copy of record Ri which has been updated.
Rj’-length: The length of record Rj’ in bytes.
Rj’: A copy of record Rj which has been updated.
s: The number of elements in the MDC Vector associ
ated with the Record File containing records Ri, Rj,
(updated to Ri', and Rj’).
AMDCVi: An Authentication MDC Vector for an
thenticating record Ri.
20
CFAP Functions
A list of functions is provided that an implementer
might ?nd useful in achieving an implementation of a
tree authentication algorithm. An implementer may find
it useful to implement one of more of the functions as
internal routines, called by higher-level CFAP func
tions that may be invoked via a service call at the ap
AMDCVj: An Authentication MDC Vector for au
plication-to-CFAP interface. Whereas for others, it may
be found convenient to externalize them directly at the
thenticating record Rj. '
Outputs:
application-to-CFAP interface.
The list of CFAP functions is this:
n: The number of elements in PMDCVi and
PMDCVj: and one more than the number of elements in
1. Record File Create
AMDCVi and AMDCVj.
2. Record Verify
PMDCVi: A Path MDC Vector associated with
record Ri’.
PMDCVj: A Path MDC Vector associated with
3. Record Add
4. Record Delete
record Rj’.
5. Record Update
Record File Create: The CFAP creates an MDC
Vector from Record File. A Load Root MDC instruc
tion is then executed to load the root MDC into the CF.
Record Verify (RECV) The Root MDC is read from
the CF using a Read Root MDC (RRMDC) instruction
and veri?cation is performed against a CFAP-cal
culated Root‘ MDC. Another option allows the CFAP
RC: A Return Code, as follows
0: success
16: failure.
Algorithm Description:
1. Perform Consistency Checking:
a. Verify that index is a value 0, 1, . . . , 63.
b. Verify that Root-MDC register ?ag (index)=‘full’
c. Verify that 5+1 is a power of 2, ?nd positive inte
ger n such that 2"—1=s.
d. Verify that n—2>0.
to calculate an Authentication MDC Vector for the
record to be veri?ed and to pass this and the record to
the CF for veri?cation. The CF authenticates the re
cord by calculating a Root MDC, which it compares
for equality against a Root MDC stored in the CF.
Record Add (RECA): The CFAP updates the MDC
e. Perform FINDX(Ri->i) /"‘ ?nd index i “/
f. Perform FINDX(Rj-—>j) /* ?nd index j "‘/
Vector on the basis of the record to be added to Record
h. Verify that 2"—2<j§2"-1.
50 File. A Load Root MDC instruction is then executed to
Continue if checking succeeds; otherwise set CC
status flag and jump to step 6.
load the new root MDC into the CF.
2. Authenticate Ri and Rj:
MDC Vector on the basis of the record to be deleted
_
a. Set root-mdc:=MDC stored in Root-MDC regis
ter(index).
0. Verify RC=0
~
Perform VREC(root-mdc,j,Rj-length,Rj,hash
e. Verify RC=0
3. Calculate PMDCVi:
a. Perform GNPMDCV(hash-rule,i,Ri'-length,Ri',
n,AMDCVi->PMDCVi)
4. Update AMDCVj using PMDCVi:
a. Set il:=2"-1+i-1
c. Ifil=jl then do:
from Record File. A Load Root MDC instruction is
then executed to load the new root MDC into the CF .
b. Perform VREC(root-mdc,i,Ri-length, Ri,hash
rule,n- l ,AMDCVi->RC)
d.
Record Delete (RECD): The CFAP updates the
Record Update (RECU): The CFAP updates the
MDC Vector on the basis of the record to be updated
within Record File. A Load Root MDC instruction is
then executed to load the new'root MDC into the CF.
Another options allows the root MDC to be calculated
in the CF from the updated record and the root MDC
stored in the CF to be replaced by the CF-calculated
MDC. This second option may lead to implementations
with better performance or better integrity or both.
An Example
The following example illustrates the relationship of
the MDC Vector, Path Vector, Path MDC Vector,
_
5,231,666
23
Authentication Vector, and Authentication MDC Vec
24
13. Set MDCV(3):=oneway(concat(3, MDCV(6),
I01‘.
MDCV(7))).
Given a Record File with t: 13 Records:
14. Set MDCV(2):=oneway(concat(2, MDCV(4),
MDCV(5))).
Let {R1,R2, . . . , R13} denote a Record File oft= 13
records.
-
5
15. Set MDCV(l):=oneway(concat(l, MDCV(Z),
Determine n= 5:
MDCV(3))).
To ?nd n, ?rst ?nd positive integers n—2 and n—1
that satisfy the relation 2"-2<t§2"-1. For t=13, we
see that positive integers 3 and 4 satisfy the relation
23< 1322“, so that n=5.
Determine the Null Records:
To calculate the MDC Vector (MDCV), we de?ne
2"-1—t=24— l3=3 null records.
Calculate MDC Vector:
The 13 records in Record File and the 3 null records
give a total of 16 records (i.e., 24 records). The MDCs
calculated on these 16 records ?ll positions 16 thru 31 of
the MDC Vector. FIG. 6 illustrates the relationship
between indexes of records and null records in the Re
cord File (RF) and indexes in the MDC Vector
From this example, one sees that the 31 MDC values
in MDCV are associated with a binary tree of 31 ele
ments, as illustrated in FIG. 1. Referring to FIG. 1, note
that the MDC associated with element 15 is calculated
from its successor elements 30 and 31; the MDC value
associated with element 14 is calculated from its succes
sor elements 28 and 29, and so forth. The root MDC
associated with element 1 is calculated from its succes
sor elements 2 and 3.
Calculate Path Vector for Records R6 and R11:
The process 'of calculating the Path Vector (PV) is
illustrated here for records R6 and R11. In our example,
n=5, so that PV contains n=5 elements 11, I2, . . . , I5.
We ?rst note that R6 is mapped by ?nd index function
(MDCV).
FINDX to value 6, i.e., FINDX(R6)=6. Likewise, R11
If i is the index in RF, then the index jin MDCV is
is mapped by ?nd index function FINDX to value 11.
calculated as j=2"-1+i— l, where n=5 in our exam
Thus, in the binary tree of 2,,—1 elements, where n=5,
ple. The corresponding MDC values in MDCV are
records
R6 and R11 are associated with elements 21 and
25
calculated using the oneway function, as follows:
.
.
.
.
.
.
.
.
.
Set
Set
Set
Set
Set
Set
Set
Set
Set
10.
11.
12.
13.
14.
15.
16.
MDCV(l6):=oneway(concat(1,
MDCV(17):=oneway(concat(2,
MDCV(l8):=oneway(concat(3,
MDCV(19):=oneway(concat(4,
MDCV(ZO):=oneway(concat(5,
MDCV(2l):=oneway(concat(6,
MDCV(22):=oneway(concat(7,
MDCV(23):=oneway(concat(8,
MDCV(24):=oneway(concat(9,
26, i.e., by evaluating the formula 2"-1+i—l at i=6
and i=l1, respectively, for n=5. The index values in
the binary tree representing the path from element 21
R1)).
R2».
R3)).
R4».
R5)).
R6)).
R7)).
Rg)).
R9)).
Set MDCV(25):=oneway(concat(l0,
Set MDCV(26):=oneway(concat(ll,
Set MDCV(27):=oneway(concat(l2,
Set MDCV(28):=oneway(concat(l3,
Set MDCV(29):=oneway(concat(l4,
Set MDCV(30):=oneway(concat(l5,
Set MDCV(31):=oneway(concat(l6,
are calculated as follows:
30 1. Set i1:=2l.
2.
3.
4.
5.
Set i2:=integer(21—:-2)=10.
Set i3:=integer(10+2)=5.
Set i4:=integer(5+2)=2.
Set i5:=integer(2+2)= 1.
Thus, PV of2l={2l, l0, 5, 2, l}. The index values in
the binary tree representing the path from element 26
R10)).
R11)).
R12).).
R13».
null)).
null)).
null)).
are calculated as follows:
1.
2.
3.
4.
5.
The remaining 15 MDC values in MDC Vector are
calculated with function oneway, as follows:
1. Set MDCV(lS):=oneway(concat(l5, MDCV(30),
MDCV(31))).
Thus, PV of 26={26, 13, 6, 3, 1}.
45
MDCV(29))).
MDCV(25))).
MDCV(23))).
7. Set MDCV(9):=oneway(concat(9, MDCV(18),
MDCV(l9))).
8. Set MDCV(B):=oneway(concat(8, MDCV(16),
MDCV(17))).
9. Set MDCV(7):=oneway(ooncat(7, MDCV(16),
MDCV(17))).
10. Set MDCV(6):=oneway(concat(6, MDCV(lZ),
MDCV(13))).
11. Set MDCV(S):=oneway(concat(5, MDCV(lO),
MDCV(11))).
12. Set MDCV(4):=oneway(concat(4, MDCV(8),
MDCV(9))).
“PV of 21”={2l, l0, 5, 2, I}, as follows:
1. Set i1:=opposite(PV(l))=opposite(2l)=20.
2. Set i2: =opposite(PV(2))=opposite(l0) = 11.
.
MDCV(2l))).
‘
11, I2, . . . , 14. The “AV of 21” is calculated from the
50
5. Set MDCV(ll):=oneway(concat(ll, MDCV(22),
6. Set MDCV(IO):=oneway(concat(l0, MDCV(20),
R11:
The process of calculating the Authentication Vector
(AV) is illustrated here for records R6 and R11. In our
example, n=5, so that AV contains n—l=4 elements
3. Set MDCV(l3):=oneway(concat(l3, MDCV(26),
4. Set MDCV(lZ):=oneway(concat(l2, MDCV(24),
Set i3:=integer(l3—:-2)=6.
Set i4:=integer(6+2)=3.
Set i5:=integer(3+2)=l.
Calculate Authentication Vector for Records R6 and
2. Set MDCV(14):=oneway(concat(14, MDCV(28),
MDCV(27))).
Set i1:=26.
Set i2:=integer(26-:-2)= 13.
55
3. Set i3: =opposite(PV(3)) =opposite(5)=4.
4. Set i4:=opposite(PV(4))=opposite(2)=3.
Thus, AV of 21 ={20, ll, 4, 3}.
The “AV of 26” is calculated from the- “PV of
26”={26, 13, 6, 3, 1}, as follows: '
1.
2.
3.
4.
Set i1:=opposite(PV(1))=opposite(26)=27.
Set i2:=opposite(PV(2))=opposite(13)= 12.
Set i3: =opposite(PV(3))=opposite(6) =7.
Set i4:=opposite(PV(4))=opposite(3)=2.
Thus, AV of 26={27, l2, 7, 2}.
FIG. 7 illustrated a cryptographic system and the
cryptographic system components needed to implement
the tree authentication algorithm. The reader will note
that several of routines (FINDX, PADR, RFORMI,
and RFORMZ) are implemented both in the CF and the
CFAP. The GMDC routine is externalized as a CF
25
5,231,666
instruction, and hence does not appear as an internal
26
with a private key and signatures are veri?ed with a
routine within the CFAP.
public key different from the private key. Each member
Data storage 40 contains a Record File 41 and MDC
Vector 42. Record File 41 is a ?le of records to be
authenticated and MDC Vector 42 is a vector of MDC
?nancial institution has an account with the central
values used by the tree authentication algorithm to
authenticate records in Record File 41.
Cryptographic Facility 1 contains a CF Environment
11, an Instruction Processor 12, and Internal Routines
23. CF Environment 11 contains 64 Root-MDC Regis
ters 112 and 64 Root-MDC Register Flags 113. Instruc
tion Processor 12 contains Generate MDC (GMDC),
Load Root MDC (LRMDC), Read Root MDC
(RRMDC), and Update Records (URECS) instruc
tions. The GMDC instruction is implemented as a call
to the GMDC internal routine. Internal Routines 23
contains Verify Record (VREC), Generate New Path
MDC Vector (GNPMDCV), Find Index (FINDX),
Pad Record (PADR), Record Format One (RFORMI),
facility, so that the purse contains a single purse record
for each member ?nancial institution. As illustrated in
FIG. 9, a purse record contains a financial institution
account number, an account balance, a transaction se
quence number, and other account data unimportant to
the present discussion. The transaction sequence num
ber is a value shared between the member institution
and the central facility, and is used by the member insti
tution and central facility to ensure that each transac
tion sent from the member institution to the central
facility is uniquely identi?ed. A received transaction is
‘valid only if the transaction sequence number is l
greater than the value of the transaction sequence num
ber stored in the purse record for that member institu
tion. Those skilled in the art will recognize that other
means could be used to ensure that transactions are
Record Format Two (RFORMZ), and Generate MDC 20 received in the proper order, e. g., that the next transac
(GMDC) routines.
tion sequence number is greater (but not necessarily 1
Cryptographic Facility Access Program 3 contains a
greater) than the transaction sequence number of the
File Storage Manager 51, CFAP Functions 53, and
last processed transaction, and that implementing such
Internal Routines 54. CFAP Functions 53 contains
other means does not depart from the spirit of the inven
MDC Vector Create, MDC Vector Initialize, Record 25 tion.
Verify, Record Update, and Record Delete functions.
FIG. 10 illustrates a cryptographic system imple
Internal Routines 54 contains MDC Vector Initialize
menting an Update Purse (UPURSE) instruction. The
(MDCVI), MDC Vector Update (MDCVU), Generate
cryptographic system consists of a cryptographic facil
Authentication MDC Vector (GAMDCV), Find Index
ity (CF) 1 with a CF environment 11 for storage of
(FINDX), Pad Record (PADR), Record Format One 30 cryptographic variables and an instruction processor 12
(RFORMI), and Record Format Two (RFORM2) rou
capable of executing a set of cryptographic instructions,
tines.
‘
a key storage (KS) 2, an electronic purse 40, a crypto
Records in the electronic purse are updated at the
graphic facility access program (CFAP) 3, and using
central facility in response to transaction messages re
application programs (APPLs) 4. CF 1 contains a CF
ceived from member institutions. As illustrated in FIG. 35 environment 11 for storage of cryptographic variables
8, a transaction message consists of an account number
and an instruction processor 12 capable of executing a
to be debited, an account number to be credited, an
set of cryptographic instructions. Key storage 2 consists
amount, a transaction sequence number, and other in
of a cryptographic key data set (CKDS) 31 for the
formation unimportant to the present discussion. The
storage of key-encrypting keys and a data key data set
transaction message directs the central facility to debit
(DKDS) 32 for the storage of data-encrypting keys.
the ?rst account by the amount indicated in the amount
Electronic purse 40 consists of a record ?le (RP) 41
‘?eld and to credit that same amount to the second ac-v
containing a purse record for each member institution
count. The account debited is the account belonging to
and an MDC vector (MDCV) 42 used in authenticating
the originator of the transaction message. The premise
records in record file 41. CF environment 11 provides
here is that a member institution has nothing to gain by 45 for the storage of a system master key (KM) 111, 64 root
falsely directing the central facility to debit his account.
MDC registers 112, and 64 root MDC register flags 113.
Thus, an authentication scheme is implemented to pre
vent a member institution from impersonating another
Keys stored in CKDS 31 and DKDS 32 are encrypted
under master key 111. Root MDC 112 is used in the
authentication process. A hand-held key-entry device
member institution and thereby falsely debiting that
account and crediting his own account.
Each transaction is MACed with a MAC key shared
between the central facility and the member institution.
14, which attaches to front panel interface 13, permits
cryptographic variables (e.g., the master key and the
Note that an alternate embodiment could make use of
root MDC) to be manually loaded into CF 1. CFAP 3
contains an electronic purse manager 51, which stores,
digital signatures based on a public key algorithm such
retrieves, and deletes records in electronic purse 40, and
as the RSA algorithm instead of message authentication 55 a key storage manager 52, which stores, retrieves, and
codes based on a private key algorithm such as the
deletes keys in key storage 2.
DEA. Those skilled in the art will recognize that such
The steps in creating the electronic purse are traced
an alternate embodiment does not depart from the spirit
as follows. Electronic purse 40 is created and initialized
of the invention. The originating member institution has
a MAC key capable of generating MACs and the cen~
tral facility has a copy of the same key, but has only a
capability to verify MACs with the key. With a private
key algorithm such as the DEA, control vectors are
via a Purse Create and Initialize function 531 in re
sponse to a service request 70 initiated by Purse Utility
61. Purse Utility 61 is an program executing in applica
tion program space 4. Purse Create and Initialize func
tion 531_creates purse records for each member institu
used to specify the uses of the keys so that one copy of
tion, and produces an MDC vector, denoted MDCV,
the key can be used to generated MACs while another 65 by invoking an MDC Vector Initialize (MDCVI) rou
copy of the same key can be used only to verify MACs.
tine, described in detail in the section entitled “Rou
If .a public key algorithm is implemented instead of a
tines.” Electronic purse manager 51, on behalf of Purse
private key algorithm, then signatures are generated
Create and Initialize function 531, at 71, writes the cre