Note: Descriptions are shown in the official language in which they were submitted.
1 3 1 9 1 98
88-023
Description
SECURE MA~AGEMENT OF KEYS USING
EXTENDED CONTROL VECTORS
Backqround o~ the Invention
1. Technical Field
The invention disclosed broadly relates to data processing
technology and more particularly relates to cryptographic
applications in data processing.
The Control Vector Concept:
The control vector is a compact data structure for
defining the usage attributes of cryptographic keys and for
controlling the distribution of cryptographic keys from one
network device to another. The control vector is
cryptographically coupled to the key via an encryption process
such that the key can be decrypted properly only if the control
vector is correctly specified to the cryptographic hardware.
Objects of the Invention
- It is an o~ject of the invention to provide an improved
method for the management of cryptographic keys.
It is another object of the invention to provide an
improved method ~or the management of cryptographic keys which
is more flexible than methods described by prior art and which
has equivalent or improved cryptographic security.
It is another object of the invention to provide an
improved method for the management of cryptographic keys that
permits new and improved cryptographic services to be offered
to cryptographic system users.
It is another object of the invention to extend the length
of a control vector while minimizing the additional
encryptions/decryptions required to process the control vectox.
It is another object of the invention to extend the length
of a control vector while keeping the process of key recovery
transparent to the cryptographic hardware.
~ .
1 31 9 1 q8
-88-023 2
It is another o~ject of the invention to provide two
methods for implementing control vectors of arbitrary length:
a) the first is a positional definition, where bits in the
control vector are defined according to their relative
positional locations within the control vector, b) the second
is tag definition, where bits in the control vector are defined
according to the field tag definitions that precede them.
It is another object of the invention to provide strong
cryptographic separation between three control vector types,
viz., single length control vectors, double length control
vectors, and arbitrary length control vectors, such that a
control vector of one type cannot cross over and be interpreted
as a valid control vector of another type.
It is another object of the invention to provide an
improved method of key management which permits the generator
or creator of a key to prescribe specific intervals of time
when the key is enabled for usage, whereas at all other times
the key cannot be used.
It is another object of the invention to provide an
improved method of key management which permits the usage of a
key to be linked to a password ~hich must be correctly
specified prior to usage of the key, such that the key can be
used only if the password is correctly specified.
Summary of the Invention
The present invention shows firstly how the 64 bit control
vector can be conveniently extended to a 128 bit control
vector. The method consists of exclusive-ORing the left-hand
64 bits of C with the left-hand 64 bits of KK and
exclusive-ORing the right-hand 64 bits of C with the right-hand
64 bits of KK. Otherwise, the 128 bit control vector is
conceptually the same as the 64 bit control vector. However,
the 128 bit control vector offers an additional 64 bits for key
management control, effectively doubling the control vector
length, but does so without additional encryption/decryption
steps. In effect, a 128 bit control vector is obtained with no
additional computatlonal overhead. The method is such that the
64 bit control vector definition is just a subcase of the 128
bit control vector.
t319198
MA9-~8-023 3
The present invention shows secondly how the 64 bit
eontrol vector can bé extended -to a control vector of arbitrary
length. However, from two to four extra encryption operations
are required for each 64 bit block in the eontrol vector.
Thus, the additional processing overhead increases linearly
with control vector length. Basically, a control vector of
arbitrary length is first operated on using a hashing ~unction
which maps a control vector C having many bits Mx into a hash
value C' having fewer bits N, where Nx is greater than N. tIn
the examples herein, N=128.) A partieularly useful hashing
funetion is a nonseeret one-way funetion, to
calculate a 128 bit hashed, one-way function of the eontro~
veetor. This 128 bit result is then eombined with KK to
produce two variant keys of KKL and KKR in exactly the same
manner in which a 128 bit control vector is combined with KK.
More precisely, if M denotes the 128 bit MDC calculated on the
control vector, then the left-hand 64 bits of M are
exclusive-ORed with the left-hand part of KK and the right-hand
64 bits of M are exclusive-ORed with the right-hand part of KK.
Otherwise, the arbitrary length control vector is conceptually
the same as the 128 bit eontrol vector.
Let C denote a eontrol vector of arbitrary length. The
invention describes two possible architectural specifications
for C. Firstly, C will admit a specifieation where the field
information in C is positional (i.e., it depends on its
position relative to a left- or right-hand origin point).
Secondly, C will admit a tag-oriented speeifieation wherein the
fields in C consist of a tag and a datum. In sueh a
speeification, the fields are not positional, but ean occur in
any order. Moreover, only those fields required for managing
and eontrolling a key need to be speeified in the eontrol
veetor. Mixtures of positional and tag-oriented specifieations
are possible, and are embraeed by the present definition of the
arbitrary length control vector.
Control veetor eheeking for a 128 bit eontrol vector is
exactly the same as control vector ehecking for a 54 bit
eontrol veetor, except that the cheeking ean involve any of the
128 bits whereas the latter ease involves at most 64 bits.
Control vector ehecking for a control vector of arbitrary
length is similar. That is, checking is based on the eontrol
veetor as always, except now a very long control vector is
1 3 1 9 1 98
MA9-88-023 4
present, and many more control vector bits and fields may need
to be tested. Control vector checking is not performed on the
128 bit hashed, one-way function of the control vector. This
hashed value is calculated internal to the CF only, not
appearing or needing to appear outside the CF for any
cryptographic purpose, as part of the key recovery process.
(Although there is no loss in security if the hash value is
known outside the CF, since the control vector and the hashing
function are ordinarily publicly available and knGwn.)
The arbitrary length CV, like the 128 bit CV, provides
additional space to define or extend key usage and control
parameters. In particular the arbitrary length CV more readily
supports tag-oriented specifications, since the length of such
specifications are themselves, arbitrary. More specifically,
the invention describes a means in which the arbitrary length
CV mav support a list of dates and times during which the
associated key may be used. The invention also describes a
means for incorporating a secret password into the control
vector, such th~~ the key can be used only if the correct
password is first specified.
Brief Description of the Drawings
These and other features and advantages of the invention
will be more fully appreciated with reference to the
accompanying figures.
Fig. 1 is a block diagram description of the system for
encrypting a 64 bit cryptographic key K with a 128 bit key
encrypting key KK (consisting of a left-hand 64 bit portion of
the key designated KKL and a right-hand 64 bit portion of the
key designated KKR3 and a 64 bit control vector C.
Fig. 2 is a block diagram description of the system for
decrypting a 6a bit cryptographic key X (previously encrypted
using the method oE Fig. 1) with a 128 bit key encrypting key
KK and a 64 bit control vector C.
Fig. 3 is a block diagram illustrating a network of
cryptographic devices connected via a cryptographic
distribution channel.
Fig. 4 is a block diagram describing the basic components
within a cryptographic device.
1 3 1 9 1 98
~9-88-023 5
Pig. 5 is a block diagram illustrating a sequence of
processes within the components of a cryptographic device to
generate a key K in operational form. K is encrypted using the
master key KM and control vector C, and is stored in key
storage. The application may access the operational key K via
an index, or label, associated with the key in storage.
Fig. 6 is a block diagram description of the common
processes performed by the cryptographic instructions within
the CF.
Fig. 7 is a block diagram description of a first
embodiment of the invention, showing the system for encrypting
a 64 bit cryptographic key with a 128 bit Xey encrypting key RK
(consisting of a left-hand 64 bit portion of the key denoted
KKL and a right-hand 64 bit portion of the key denoted KK~) and
a 128 bit control vector C (consisting of a left-hand 64 bit
portion denoted CL and a right-hand 64 bit portion denoted CR).
Fig. 8 is a block diagram description of the first
embodiment of the invention, showing the system for decrypting
a 64 bit cryptographic key K (previously encrypted using the
method of Fig. 7, i.e. using a 128 bit control vector and 128
bit key encrypting key).
Fig. 9 is a block diagram des~ription of a second
embodiment of the invention, showing the system for encrypting
a 64 bit cryptographic key K with a 128 bit key encrypting key
KK (consisting of a left-hand 64 bit portion of the key denoted
KKL and a right-hand 64 bit portion of the key denoted KKR) and
an arbitrary length control vector Cinf.
Fig. 10 is a block diagram of the second embodiment of the
invention, showing the system for decrypting a 64 bit
cryptographic key X (previously encrypted using the method of
Fig. 9, i.e. using an arbitrary length control vector and 128
bit key encrypting key).
Fig. 11 describes the modification detection code
operation (MDCOP), which is employed in the 2- and
4-encryptions per block MDC algorithms. The figure illustrated
the MDCOP algorithm in both text and block diagram forms.
Fig. 12 describes the 2-encryptions per block modification
detection code (MDC) algorithm.
Fig. 13 describes the 4-encryptions per block modification
detection code (MDC0 algorithm.
13191~8
MA9-88-023 6
Fig. 14 illustrates a method to cryptographically separate
the three CV ~ethods: 64 bit CV, 1~8 bit CV, and arbitrary
length CV. The control vector quantities to be exclusive-ORed
with the key encrypting key RKL,KKR are identified for each
method. A fixed bit field within these quantities is defined
along with the unique encodings used to separate the three
methods.
ig. 15, parts (a) through (f), describe data structure
for control vectors of arbitrary length.
Fig. 16 is a block diagram of a cryptographic processing
system which incorporates secret passwords into controi
vectors.
Fig. 17 illustrates several ways in which passwords may be
incorporated into the control vector data structure.
Fig. 18 is a block diagram of a cryptographic processing
system which incorporates time information into control
vectors.
Fig. 19 illustrates several ways in which time information
may be incorporated into the control vector data .structure.
Fig. 20 illustrates encryption with a control vector of
arbitrary length, including a password.
! Fig. 21 illustrates decryption with a control vector of
arbitrary length, with time interval checking.
Fig. 22 illustrates a cryptographic facility for arbitrary
length control vectors.
Fig. 1 illustrates a system for cryptographicallY coupling
a 64 bit control vector to a 128 bit cryptographic key.
~otationally, it is convenient to express encryption of
plaintext X with key K as eK(X) = Y, where Y denotes the
resulting ciphertext. The inverse process of decryption of
ciphertext Y with key K to recover plaintext X is expressed as
dK(Y) = X. The method of encrypting a 64 bit key K with a 128
bit key encrypting key KK (consisting of a left-hand 64 bit
portion of the key designated KKL and a right-hand 64 bit
portion of the key designated KKR) and a 64 bit control vector
C in register 40' is a variation on the method of multiple
encryption and is expressed as eKKL+C(dKKR+C(eKKL+C(K)))
1 3 1 9 1 ~
MA9-88-023 7
where 1~+1~ denotes an exclusive-OR function. Thus, encryption
consists of first exclusive-ORing in exclusive-OR device 46 the
64 bit control vector C to KKL and KKR in register 42 and then
alternately encrypting K in register 44 with KKL+C in
encryption device 41, decrypting the result with KKR-~C in
decrypting device 43, and encrypting that result with KKL+C in
encrypting device 4~. Instead of wrlting the cumbersome form
eKKL+C(dKKR+C(eKKL+C(K))), a shorthand notation is used
instead. The notation KK.C is used to express the exclusive-OR
operation i.e., that C is exclusive-ORed with KK, or more
precisely, that C is exclusive-ORed with KKL and KKR,
respectively. The notation *K~ is used in lieu of KK to
indicate that KK is a 128 bit key instead of a 64 bit key,
i.e., *KK denotes a 128 bit key whereas KK without the asterisk
denotes a 64 bit key. Used together, e*KK.C(K) denotes
encryption of K with a 128 bit KK where C is previously
exclusive-ORed with each half of KK.
Fig. 2 illustrates the system for decrypting the encrypted
value of K (i.e. Y = e*KK.C(K)) using key KK and control vector
C. This process consists of first exclusive-ORing C with KKL
and KKR, as before, and then alternately decrypting the
er.crypted value of K with KKL+C in decryption device 47,
encrypting the result with KKR~C in encryption device 48, and
decrypting that result with KKL+C in decryption device 49. It
will be appreciated from a reading of Fig. 2 that K is properly
recovered when KK,C and eKKL+C(dXKR+C(eKKL+C(K))) are correctly
specified, but that an unpredictable, and effectively random
~ MA9-88-023 1 3 1 9 1 ~8
value is produced if even so much as one bit in C is
incorrectly specified. (Precisely speaking, if C' is an
arbitrary control vector not equal to C and ciphertext
eKKL+C(dKKR+C(eKKL+C(~))) is decrypted with KK and Cl, the
probability of accidentally recovering a plaintext equal to K
is about 1/2**64, which is of no cryptographic consequence. An
adversary would have as good a chance to discover the clear
value o~ K through cryptoanalysis using a straightforward
method of direct search, i.e., given a plaintext and
corresponding ciphertext encrypted with K, decrypt the
ciphertext with every possible key until one is found that
produces the given plaintext. A comparable number of
encryption/decryption steps is required in both cases.)
The data encryption algorithm (DEA), as described in ANSI
X3.92-1981 is one example of an encryption algorithm that can
operate with control vectors using the methods of encryption
and decryption described in Fig. 1 and Fig. 2. The reader will
appreciate that the control vector concept can be adapted to
any symmetric block cipher by specifying the control vector
length to be equal to the key length, or to a multiple of it
when multiple encipherment techniques are employed.
Network Configuration of Cryptographic Devices:
Fig. 3 illustrates a network of connected cryptographic
devices (hosts, controllers, workstations, etc.), consisting o~
a first cryptographic device 1~0 in a data processing system 2,
connected to several other cryptographic devices 200, 300, etc.
via a cryptographic distribution channel 1000, and which are
capable of communicating cryptographically. That is, the
devices can communicate privately by encrypting data at a
sending device and decrypting data at a receiving device. The
devices can authenticate data transmissions by generating and
attaching a message authentication code to a message prepared
at a sending device and authenticate the message and message
authentication code at a receiving device. And the devices can
generate keys securely within a cryptographic device at a
generating device, encrypt the keys, and transmit the encrypted
keys to a receiving device where they are received and stored
in an appropriate form in the key data set belonging to the
receiving device for subsequent use in encrypting and
authenticating data, or for some other key management function.
,
MA9-88-023 1 3 1 9 1 9 8
Referring now to Fi.g. ~, whic:ll is an enlargement of
cryptographic device ~00 shown in ~iCJ. 3, each cryp-tographic
device con-tains a cryptographic faciLity (CF) 4 capable of
executing a set of cryptographic instructions 52, a key
storage 22, a cryptographic fac~ ity access program (CF~P)
54, and user applica-tion programs 55. The CF contains a
register 18 for the storage of a ]28 bit master key KM
consisting of a left-hand 64 bi-t por-tion, denoted KML, and a
right-hand 64 bit portion, denotecl KMR. (It is assumed that
the cryptographic algorithm implemented within the CF is the
data encryp-tion algorithm (DEA).) ~1] keys stored outside
the CF are encrypted under the mas-ter key and a control
vector, as described in Fig. 1, ancl are stored in key
storage 22. Keys in key storage 22, i.e., encrypted under
the master key are in a form -tha-t can be processed by the
CF, and therefore are called operational keys. Keys
encrypted under other keys (called key encryp-ting keys,
KEKs) are in a form suitable for distrib~ltion from one
device to another, i.e., the keys are stored in a form
suitable for export to another device or for import from
another device. (Note: keys are sometimes generated and
enciphered in an import form so they can be re-imported at
the same device where they are generated.) Typically, each
pair of devices share two KEKs: a) a first KEK (denoted
KEKl) used to encryp-t and transmit keys from a first device
to a second device, and b) a second KEK (deno-ted KEK2) used
to encrypt and transmit keys from the second device to the
first device. At -the first device, I~EK1 ls designated via
its control vector as a KEK sendel^ key since i-t is capable
of encrypting keys for export to the second device, whereas
KEK2 is designated via lts control vec-tor as a KEK receiver
key since it is capable of decrypting keys for import from
the second device. At -the second device, KEKl and KEK2 are
designated opposite].y, i.e., KEKl is a KEK receiver and KEK2
is a KEK sender key. The cryptographic facility 4 also
contains a random number generator 26 capable of generating
64 bit random numbers. The output o the random number
generator can be read only by the CF. The cryptographic
facility also contains a secure front panel interface 58
with a port 59 for attachment of a hand-held key entry
device 60. The front panel also has a physical key-activated
switch 61 for enabliny entry of keys, including the master
key, via key entry device ~
~ MA9-~8-023 1 3 1 9 1 q 8
l ()
Referring again -to FicJ. 4, in.qtr-lct].on set 52 consists
of several cryptoyraphic instructiolls capable of supporting
key management, data encryption ancl authentication
functions, and processing of financial transackions based on
authentica-tion of personal identlfica-tlon numbers (PINs)
Typically, a request for cryptographic servlce originates
with an application program 55. The steps necessary to
satisfy the request can be traced. For example, a request
can take the form of a macro call to CFAP at 62 in which one
or more parameters are passed (e.~., clear and encrypted
data, keys and cryptovariables, key labe].s used in accessing
encrypted keys in key storage 22 at 65) and thereby enabling
CFAP 54 to carry out the requested Eunction. In turn, CFAP
may call for CF 4 to execute one or more cryptographic
instructions at 64, as necessary, in order to generate new
cryptographic keys and cryptovariables, or to encipher,
decipher, or re-encipher data or keys thereby producing the
outputs in the appropriate encrypted or decrypted form. As a
result, CFAP may store newly generated encrypted keys in key
storage 22 at 65, it may return one or more values to the
requesting application program at 66, or both. Condition
codes from the CF to CFAP at 64 and from CFAP to the
application program at 66 indicate normal. or abnormal status
including indications when a requested operation could and
could not be performed.
Control Vec-tors Used for Management of Operational Keys:
Since the attribu-tes of a key are typically public, not
private, i.e., are either known or can be inferred by system
users, the control vector is deflned as a public or
nonsecret value. On the other hand, since -the
cryptographic-keys defined to the system must be kept
secret, the process of "linking" -the control vector to a key
must not expose the key. (Note: One
B
" ~9 88-023 131~1q8
aspect of the invention involves a technique for incorporating
a secret password into the control vector.)
Fig. 5 illustrates linking a control vector to a key. The
example given is the use of the key generate instruction KGEN,
which causes a key to be generated by the cryptographic
facility. The steps can be traced. In step 71, the
application A calls CFAP to generate a key. Prior to issuing
the KGEN instruction, CFAP builds a 6~ bit control vector in
step 72 specifying the àttributes of the desired key to be
generated. Control vector C is passed to the CF at step 73 as
part of the KGEN instruction. In response, the CF generates
(using a random number generator whose output can be read only
by the CF) a 64 bit random number at step 75, which is adjusted
for odd parity. This represents the generated key K. K is
encrypted using the exclusive-OR product of the control vector
C passed at 73 and master key KM accessed at 74 as indicated by
the encryption rule described in Fig. 1. The encrypted key,
denoted e*KM.C(R), is returned to CFAP at step 76. (Note that
e*KM.C(K) is a shorthand notation for expressing multiple
encryption under the variant keys XML+C and KMR+C,
respectively.) In turn, CFAP may store the encrypted key
e*KM.C(K) and control vector C output at 77, in the key storage
22 at step 78 (in which case a key label is returned in step 79
to the application program at step 80) or the values may be
returned to a requesting application program at step 80. In
any event~ the reader will appreciate that the process of ~ey
generation and "linking" the control vector to the generated
key via encryption is one that does not expose the generated
key in cleartext form outside the cryptographic facility,
whereas the control vector is maintained as a public or
nonsecret value.
Although the control vector is not a secret quantity, it
is necessary that it be supplied, specified, or provided as an
input to the cryptographic facility anytime the key to which it
is linked is to be used. Every bit in the control vector must
be specified, exactly as it was specified originally when the
key was generated and encrypted. Failure to specify C
correctly will result in the recovery of a random, unknown key
value. The recovery of a key (i.e., decryption of a key) which
has been previously ensrypted using a control vector, is always
part of a larger process in which the encrypted key and control
vector are passed as parameters of a cryptographic instruction
invo~ed via the CFAP to CF interface. In this way, the
1319198
MA9-88-023 12
cryptographic facility can check the control vector to ensure
that the key is permitted to be used as an input parameter to
the requested cryptographic instruction. This preliminary
checking of the control vector is called CV checking. When
more than one encrypted key and control vector are supplied as
parameters to a cryptographic instruction, CV chec~ing not only
consists of checking with control vector for consistency, but
cross checking values in one control vector against values in
another control may be re~uired. The steps required by the
cryptographic facility to process a cryptographic instruction
are traced in Fig. 6. Basically, ever~ instruction consists of
three functions: a) CV checking 81, b) key recovery 82, and c)
processing the requested instruction 83. The first functional
requirement is CV checking 81, which consists of checking the
control vectors for consistency and to determine whether the
requested usage of the key parameters is consistent with the
requested instruction. If CV checking fails, the instruction
execution is aborted. In all cases, a condition code is turned
to CFAP indicating status information. If CV checking
succeeds, the process continues. The second functional
requirement is key recovery 82, i.e~, decryption of encrypted
keys. The method of cryptographic coupling between the control
vector and the key is such that any cheating (i.e., changing
bits in the control vector to give the key incorrect
attributes) will result in the recovery of a random,
unpredictable value for the key. In effect, the desired,
needed cryptographic key is not recovered by the cryptographic
instruction. The third functional requirement is that of
processing the requested cryptographic instruction 83. If the
control vectors and keys have been correctly specified, the
instruction is processed correctly. However, if cheating
occurs, the instructions are designed so that the instruction
outputs are of no beneficial value.
The degree of key management control offered by the
control vector is related to and depends largely on the number
of bits that are available in the control vector. An
especially short control vector, say from 10 to 50 bits, would
have a very limited use and could support only a limited number
of key management separations, usages, and controlling mechanisms.
131ql98
~A9-80-0.-3 1~
Description of the Best Mode for Carryinq Out the Invention
Double Length Control Vectors:
In the first embodiment of the invention shown in Figs. 7
and 8, the 64 bit control vector can be advantageously extended
to a 128 bit control vector. The additional 64 bits given by
the 128 bit control vector thus provicle the cryptographic
system and cryptographic system user with a means to better
control cryptographic key usage.
The system of Fig. 7 differs from the system of Fig. 1 as
follows. With the system of Fig. 7, CL in register 40L is
exclusive-ORed in exclusive-OR 46L with KKL in register 42L to
form KKL+CL and CR in register 40R is exclusive-ORed in
exclusive-OR 46L with KKR in register 42R to form KKR+CR~ With
the system of Fig. 1, C is exclusive-ORed with ICKL and KKR to
form KKL+C and KKR+C, respectively. Thus, with the system of
Fig. 1, the same 64 bit control vector is exclusive-ORed with
both parts of KK, whereas with the system of Fig. 7, different
64 bit control vectors are exclusive-ORed with each part of KK.
Otherwise, the system of Fig. 1 and Fig. 7 are the same.
For convenience, the notation e*KK.C64(K) distinguishes
the case where a 64 bit control vector is used with KK to
encrypt K in Fig. 1 and the notation e*KK.C128~K) distinguishes
the case where a 128 bit control vector is used with KK to
encrypt K in Fig. 7. The output value Y in Fig. 1 is an
example where Y can be expressed as Y = e*KK.C64(K). Likewise,
the output value Y in Fig. 7 is an example where Y can be
expressed as Y = e*KK.C128(K).
The system of Fig. 8 differs from the system of Fig. 2 as
follows. With the system of Fig. 8, CL in register 4OL is
exclusive-ORed in exclusive-OR 46L with KKL in register 42L to
form KKL+CL and CR in register 40R is exclusive-ORed in
exclusive-OR 46R with KKR in register 42R to form KKR~CR. With
the system of Fig. 2, C is exclusive-ORed with KKL and KKR to
form KKL~C and KKR~C, respectively. Thus, the difference
between Fig. 2 and Fig. 8 is that different 64 bit control
vectors are exclusive-ORed with each part of KK.
~A9-88-023 1 3 1 9 1 9 8
-14-
The reader will appreciate that the system of Fig. 1 and
Fig. 2 is just the system of Fig. 7 and Fig. 8 where C = CL =
CR. In other words, the method of employing a 128 bit control
vector reduces to that of employing a 64 bit control vector
provided that the left-hand 64 bit portion of C equals to the
right-hand portion of C. Thus, a 64 bit control vector is just
a degenerate case of a 128 portion of C. Thus, a 64 bit
control vector is just a degenerate case of a 128 bit control
vector. The advantage of the system of Fig. 7 and Fig. 8 is
that the control vector length is doubled without any
additional computational or processing overhead. In fact, the
definitions for a 64 bit control vector (Fig. 1 and Fig. 2) and
a 128 bit control vector (Fig. 7 and Fig. 8) have architectural
and implementation advantages. Existing cryptographic hardware
and software implementing 64 bit control vectors can be easily
extended to support 128 bit control vectors, since both systems
are implemented using a triple encryption operation involving
variant keys derived from KKL and KKR. Otherwise, the
encrypt~on processes are exactly the same. New cryptographic
hardware and software implementing 128 bit control vectors can
easily support 64 bit control vectors by merely setting CL = CR
at the software level. ~n effect, both 64 and 128 bit control
vectors can be made transparent to the cryptographic hardware.
Arbitrary Length Control Vectors:
In the second embodiment of the invention shown in Figs. 9
and 10, the 64 bit control vector can be advantageously
extended to a control vector of arbitrary length. The
unlimited number of bits provided by this system offers -the
ma~imum degree of cryptographic key management control
possible.
Fig. 9 illustrates the system for encrypting a 64 bit
cryptographic key K in register 44 with a 128 bit key
encrypting key KK which is KKL concatenated with KXR (KK =
KKL//KKR) in register 42 and a control vector C of arbitrary,
or infinite, length (denoted Cinf) in register 90. The
operation consists of first calculating a one-way public hash
function on Cinf in hash function processor 92 to produce a 128
bit hash value result consisting of a left-hand 64 bit part
denoted ML loaded into register 94L and a right-hand 64 bit
part denoted MR loaded into register 94R. The one-way function
computed in processor 92 has the property that it is
computationally infeasible to calculate the input to the
function from the function's output, but it is easy to
;~A9-88-023 1 3 1 ~ 1 9~
-15-
calculate an output from an input. One-way functions are
well-known and have been described in prior art. The
definition of a strong one-way function is given below, from W.
Diffie, et al. entitled "New Directions in Cryptography," IEEE
Transactions on Information Theory, IT-22, No. 6, pp. 644-654
(1976).
A function f is a one-way function if, for any argument x
in the domain of f, it is easy to compute the corresponding
value y = f(x); yet for almost all y in the range of f, it is
computationally infeasible, glven a value of y and knowledge of
f, to calculate any x whatsoever with the property that f(x) =
y. It is important to note that a function is defined which is
not invertible from a computational point of view, but whose
noninvertibility is entirely different from that normally
encountered in mathematics. A function f is normally called
"noninvertible" when the inverse of a point y is not unique;
i.e., there exist distinct points xl and x2 such that f(xl) = y
= ftx2). This is not the sort of inversion difficulty that is
required here. Rather, it must be overwhelmingly difficult,
given a value y and knowledge of f, to calculate any x
whatsoever with the property that f(x) = y.
The algorithm for calculating a modification detection
code (see Fig. 11, Fig. 12, and Fig. 13), described below,
provides an even stronger definition of a one-way function.
The MDC algorithm is such that it is computationally infeasible
to find an xl and x2 such that f(xl) = f(x2). ~n order to
satisfy this stronger requirement, it is necessary for the MDC
to be at least 128 bits in length. Otherwise, birthday-type
attacks can be employed to find an xl and x2 such that f(xl) =
f(x2).
Continuing with the system oI Fig. 9, the operation next
consists of exclusive-ORing with exclusive-OR 46L the 64 bit
value ML in register 94L with the 64 bit key KKL in register
42L and exclusive-ORing with exclusive-OR 46R the 64 bit value
MR in register 94R with the 64 bit key KKR in register 42R. K
in register 44 is then alternately encrypted with KKL+ML in
encryption device 41, decrypted with KKR+MR in decryption
device 43, and encrypted with KKL+ML in encryption device 45.
The resultant value Y is denoted e*KK.Cinf(K) for convenience.
(The "+" denotes the exclusive-OR operation.)
Fig. 10 illustrates the system of decrypting the 64 bit
value Y which is the encrypted cryptographic key K in register
44 with a 128 bit key encrypting key KK (KKL,KKR) in register
42 and a control vector Cinf of arbitrary length in register
- 131919~
P '-88-023
-16~
90. The steps in Fig. 10 are basically the inverse of those in
Fig. 9. The operation consists of first calculating a one~way
public hash function of Cinf (using the same one-way public
hash function as used in Fig. 9) in the hash function processor
92 to produce a 128 bit result ML,MR. The operation next
consists of exclusive-ORing ML with KRL and MR with KKR,
respectively, to produce KKL-~ML, KKR+~R. K is then alternately
decrypted with KKL+ML in decryption device 47, encrypted with
KKR+MR in encryption device 48, and decrypted with KKL+ML in
decryption device 99. In effect, e*KK.Cinf(K) is decr~pted
with *KK.Cinf to recover K.
The preferred method of calculating a one-way public hash
function in the processor 92 is to make use of the algorithms
for calculating modification detection codes (MDCs).
Fig. 11 describes the primitive MDC
operation, MDCOP, which is applied in two different systems to
calculate an MDC. Fig. 12 illustrates the calculation of a 128
bit MDC using a method requiring two encryption operations per
64 bit input. Fig. 13 illustrates the calculation of a 12~ bit
MDC using a method requiring four encryption operations per 64
bit input. Both methods require the input a plaintext control
vector of arbitrary length to be divided into 64 bit blocks,
where padding of the final blocks with hexadecimal digits "FF"
is performed as necessary to ensure that every block has ~4
bits. The plaintext blocks are processed serially by the MDC
algorithm until all blocks are processed. The output of the
function is a 128 bit MDC.
In the case of Cinf, the control vector is divided into
blocks Cl, C ,..., Cn where Cn is padded on the right with
hexadecimal 'FF' (with as many bytes of "FF" as necessary) to
make Cn eight bytes. The paddin~ step is performed, as
necessary by the cryptographic hardware (i.e~ it is an integral
part of the one-way public hash function itself). Blocks Cl,
C2,..., Cn are then operated on with the MDC algorithm (either
the two encryption or four encryption per block method) to
produce a 128 bit MDC. The left-hand part of the 128 bit MDC
(denoted ML) is exclusive-ORed with KKL to form KKL+ML and the
right-hand part of the 128 bit MDC (denoted MR) is
exclusive-ORed with KKR to form KKR+MR.
.
. .~A9-88-023 1 3 1 9 1 q ~
It is very important for maximum security that a strong
one-way function, such as the MDC algorithm, be employed to
calculate the so-indicated 128 bit hash value on the arbitrary
length control vector. This is necessary to prevent an
adversary from finding two different valid control vectors Cl
and C2, which yield the same hash value. If such a pair, C1
and C2, could be found, where MDC(C1) = MDC(C2), then the
integrity of the process would be violated. To illustrate why
this is so, consider an example where C1 permits encipher only
of data and C2 is some control vector which, among other
things, permits decipher of data. Now, if it is known that an
encrypted data key has control vector C1, then security is
easily subverted by any insider by simply specifying C instead
of Cl. That is, the adversary passes the encrypted data key
and C2 to a decipher instruction, together with intercepted
ciphertext that has been enciphered with the subject data key
by the unsuspecting user, and the decipher instruction is
unable to detect that C2 is invalid or unable to prevent the
correct data key from being recovered internally within the CF
and consequently unable to prevent the data from being
decrypted.
Fig. 22 is provided to show how the hash function
processor 92 can be connected to the bus 12 in the
cryptographic facility 4. Although the hash function processor
92 can be a part of the cryptographic processing unit 16, it
can also be a separate processor connected to the bus 12. The
hash function processor 92 performs the one-way public hash
function described above, on the control vector.
Cryptographic Separation Among Control Vectors:
The reader will appreciate that a cryptographic
implementation based on 64 bit control vectors only, or 128 bit
control vectors only, or arbitrary length control vectors only
can be securely implemented using methods prescribed herein and
as defined to this point in the invention. However, systems
may exist where it is desired, and even necessary for the
methods to coexist (i.e. to be implemented within the same
cryptographic system). In that case, it is absolutely
essential, for reasons of achieving cryptographic security, for
the methods to be separated cryptographically. In other words,
it must be infeasible for an insider adversary to cheat such
that the cryptographic hardware accepts an encrypted key under
one method of control vector specification where the key has
been encrypted using a different method of control vector
. MA9-88-023 -1~- 1 3 1 ~ 1 q8
sPecification. For example, if e*XK.C128(K) denotes a key
encrypted using a 128 bit control vector, -the cryptographic
interface should be such that it is impossible to claim that
e*KK.C128(K) is a key encrypted using a 64 bit control vector
in such a way that the cryptographic hardware decrypts and
recovers K from e*KK.C128(K). This is because C128 and C64
could possibly have conflicting specifications such that C128
does not permit a certain key usage whereas C64 does.
One obvious difficulty with the above definitions is this.
It could happen, in a particular implementation, that the left
and right halves of a 128 bit control vector are equal (i.e.,
legitimately) and CL may represent a valid 64 bit control
vector C. A somewhat artificial example will illustrate the
problem. Suppose that bit 13 in CL, in CR and in C is set =
B'l' and that all other bits are set = s'0'. In CL, bit 13 =
B'l' says that the encrypted cryptovariable X (suppose X is a
~ey) can be used to encipher data only. Bit 13 in CR further
restricts the encryption operation in some way (e.g., requiring
the user to first enter a password, or restricting the
encr~ption operation to be performed only between the hours of
8:~0 a.m. and 4:30 p.m.). However, bit 13 in control vector C
(i.e., the 64 bit control vector) means that X can be used to
decrypt data. If Y denotes the encrypted value of X using
CL,CR and KL,KR, then an insider adversary could cheat by
asking the cryptographic device to decrypt Y using C and KL,KR.
In the latter case, the adversary would be permitted to decrypt
data with X, which is a right that he should have been denied.
The cryptographic property desired, in this case, is now
stated. Let C64, C128, and Cinf denote the methods of
encrypting a key K with XK using a 64 bit control vector, a 128
bit control vector, and an arbitrary length control vector,-
respectively. Let i denote any of the these methods, and let Y
denote the encryption of K with KK using control method i. Now
if j-denotes any one of the methods such that i does not equal
j, then the cryptographic hardware must be such that the
following holds true. If Y and j are passed to the hardware
(i.e., the insider adversary lies and says method j was used
when in fact method i was used), then the cryptographic
hardware must ensure that cheating is discovered and the
operation is aborted, or else the cryptographic hardware must
ensure that a random, unpredictable value K' (not equal to K)
is produced which is of no use or value to an adversary.
- MA9-~8-023 -19- 1 3 1 9 1 98
A method for achieving total cryptographic separation
among the three methods of control vector definition is
illustrated in Fig. 14. The method makes use of a two bit
field (say bits i and i+1) in each 64 bit part of each control
vector and iII each 64 bit part of the MDC calculated on an
arbitrary length control vector, such that the bits do not
overlap with parity bits in the key. The bits are assigned
values such that for a given K and KK, the set of all encrypted
values e*KK.C64(K), for all C64, is clifferent from the set of
all encrypted values e*KK.C128(K), for all C128, is different
from the set of all encrypted values e*KK.Cinf(K), for all
Cinf. This guarantees that no encrypted K can be decrypted
with more than one control vector. All control vectors, except
the correct control vector will result in an incorrectly
decrypted value of K' not equal to K.
Con*rol ~ector Checking:
Control vector checking for a 128 bit control vector is
similar to control vector checking for a 64 bit control vector,
except that the checking can involve any of the 128 bits
whereas for a 64 bit control vector it can involve any of the
64 bits. Thus, the control vector checking logic as detailed
in Fig. 6 for a 64 bit control vector is similar to the control
vector checking logic that is needed for a 128 bit control
vector, except that 128 bit control vectors are provided as
inputs to the cryptographic facility instead of 64 bit control
vectors.
Control vector checking for a control vector of arbitrary
length is similar. That is, checking is still based on the
control vector, except now a very long control vector can be
present and many more control vector bits and fields may need
to be tested. When a control vector of arbitrary length is
employed, control vector checking is always based on the
control vector -- not on the 128 bit hashed, one-way function
of the control vector. This hashed value is calculated
internally to the cryptographic facility only and there is no
requirement for this hashed value to exist outside the
cryptographic facility for the purpose of communicating it from
one device to another, or from one cryptographic facility to
another, or for the purpose of storing it like a control vector
and reentering it into the cryptographic facility. (Although,
certainly, there is no loss in security if the hashed value of
the control vector is known outside the cryptographic facility,
since the hashing algorithm and the control vector are presun~ed
131919~
. ~9-88-023
-20-
to be publicly known, nonsecret components. The eXCeptiOn to
this is when a secret password i5 incorporated into the control
vector, in an alternate embodiment of the present invention-)
Tag-Oriented aI~d Positional Dependent Control Vector Data
Structures:
In accordance with the invention, as shown in Fig. 15,
part "a," a control vector of arbitrary length C can be
structured so the control vector consists of a sequence of
positional dependent fields, e.g., field 1, field 2,..., field
n. The fields consist of one or more bits, where each such
field has a predefined meaning, interpretation, and intended
usage.
In accordance with the invention, as shown in Fig. 15,
part "d," a control vector of arbitrary length C can be
structured to consist of fields that are identified not by
their position in the control vector but according to a field
descriptor. Such a tag-oriented data structure consists of
multiple fields, as shown in Fig. 15, part "d," where each such
field consists of a fixed length field descriptor, a fixed
length field length, and a variable length datum, as shown in
Fig. 15, part "b."
In accordance with the invention, as shown in Fig. 15,
part "e," a control vector of arbitrary length C can be
structured to conslst of field identified by field descriptor
(i.e., tags), where field length is not prescribed by a length
field but is determined on the basis of a field delimiter
character of fixed width placed at the end of the datum. In
that case, the field delimiter character must not be a valid
character in the datum. Such a tag-oriented data structure
consists of multiple fields, as shown in Fig. 15, part "e,"
where each such field consists of a fixed length field
descriptor, a variable length datum, and a fixed length field
delimiter character, as shown in Fig. 15, part "c."
In accordance with the invention, as shown in Fig. 15,
part "f," a control v~ctor of arbitrary length C can be
structured to consist of both a positional dependent portion
and a tag-oriented portion. The example given, cites a fixed
MA9-88-023
-21-
1319198
length positional dependcnt portion of the control vector which
appears first and a variable length tag-oriented portlon which
appears next. Such a data structure may be particularly
convenient, since the positional dependent portion could
consist of a 128 bit field definition corresponding to a 128
bit control vector and the variable length tag-oriented portion
could consist of a control vector extension to the 128 bit
fixed portion of the control vector.
The reader will appreciate that many different variations
exist for implementing a control vector of arbitrary length to
gain architectural simplicity, minimize storage and processing
requirements, and to maintain compatibility among
implementations of 64 bit control vectors, 128 bit control
vectors, and control vectors of arbitrary length, where all
three types may coexist in the same cryptographic system or
network or connected devices.
Secret Passwords and Control Vectors:
Finer control on cryptographic key usage can be obtained
by including a secret password in the control vector. This may
be particularly advantageous in applications where very high
security is required and tight control measures must be
employed in managing cryptographic usage ~i.eO, access control
to cryptographic keys).
Fig. 16 gives a block diagram representation of ~ data
processing system with a cryptographic facility therein. In
Fig. 16, the data processing system 2 executes a program such
as a crypto facility access program. These programs
output cryptographic service requests for the
management of the cryptographic keys which are
associated with control vectors. The general format
for a control vector is more fully explained below.
Control vectors define the functions which the
associated key is allowed by its originator to perform.
The cryptographic architecture is a system for
validating the key management functions requested for a
cryptographic key by the program, and assures that they
have been authorized by the originator of the key.
~ MA9-88-023
13191q8
As is shown in Fig. 16 herein, contained within or
associated with the data processing system 2 is a cryptographic
facility 4 which is characterized by a secure boundary 6. An
input/output path 8 passes through the secure boundary 6 for
receiving the cryptographic service request, cryptographic keys
and their associa~ed control vectors from the program. The
input/output path 8 outputs responses to those cryptographic
requests from the cryptographic facility. Included within the
secure boundary 6 is a cryptographic instruction storage 10
which is coupled by units of the bus 12 to the input/output
path 8. A control vector checking unit 14 is coupled to the
instruction in storage 10 and a cryptographic processing unit
16 is also coupled to the instruction storage 10. A master key
storage 18 is coupled to the cryptographic processing unit 16.
The cryptographic facility 4 provides a secure location for
executing key management functions in response to the received
service request.
The cryptographic instruction storage 10 receives over the
input/output path 8 a cryptographic service request for
performing a key management function with a cryptographic key.
The control vector checking unit 14 has an input coupled to the
input/output path 8, for receiving a control vector associated
with the cryptographic key. The control vector checking unit
14 also has an input connected to the cryptographic instruction
storage 10, for receiving control signals to initiate checking
that the control vector authorizes the key management function
which is requested by the cryptographic service request.
The control vector checking unit 14 has an authorization
output 20 which is connected to an input of the cryptographic
processing unit 16, for signaling that key management functions
is authorized; the receipt of the authorization signal by the
cryptographic processing unit 16 initiates the performance of
the requested key management function with the cryptographic
key.- A cryptographic key storage unit 22 is coupled to the
cryptographic facility 14 over the input/output path 8. The
cryptographic key storage unit 22 stores the cryptographic key
in an encrypted form in which the cryptographic key is
encrypted under a storage key which is a logical product of the
associated control vector and the master key stored in the
master key storage 18. Such a logical product is represented
as KM.C, where KM is the 128 bit master key KM and C is the
control vector. When more than one key and control vector are
required for a service request, all control vectors are
~A9-88-0 3 -23-
1 3 1 q 1 98
checked, and all must be found satisfactory in order for an
authorization signal to be provided to the cryptographic
processing unit 16.
An example of recovering an encrypted key from the
cryptographic key storage 22 occurs when the cryptographic
instruction storage 1~ receives over the input/output path 8 a
cryptographic service request for recovering the cryptographic
key from the cryptographic key storage unit 22. The control
vector checking unit 14 will then output in response thereto,
an authorization signal on line 20 to the cryptographic
processing unit 16 that the function of recovering the
cryptographic key is authorized. The cryptographic processing
unit 16 will then opera~e in response to the authorization
signal on line 20, to receive the encrypted form of the
cryptographic key from the cryptographic key storage 22 and to
decrypt the encrypted form under the storage key which is a
logical product of the associated control vector and the master
key stored in the master key storage 18.
The storage key is the exclusive-OR product of the
associated control vector and the master key stored in the
master key storage 18. Although the logical product is an
exclusive-OR operation in the preferred embodiment, it can also
be other types of logical operations.
The associated control vector is stored with the encrypted
form of its associated cryptographic key in the cryptographic
storage 22. Since all keys stored on a cryptographic storage
encrypted under the master key, a uniform system for encryption
and decryption of encrypted keys thereon can be performed.
In accordance with the invention, as shown in Fig. 16, a
system for incorporating a secret password into the control
vector is provided. As shown in Fig. 16, the control vector
stored with the encrypted form of its associated cryptographic
key in the cryptographic key storage 22 has a password field.
However, since the password is a secret quantity, it is not
stored in the control vector. Instead, the password field in
the control vector is set to zero (i.e., all zero bits). Thus,
if the password field is 56 bits in length, then 56 zero bits
are stored in this field. The secret passwords themselves are
provided to the cryptographic facility 4 via a separate
password channel 32 connected to the input/output path 8.
Thus, a user who is authorized to have access to a
cryptographic key :is provided, in advance, with a copy of the
secret password. When a cryptographic service request is made
which uses a key whose control vector has an associated
I
~ 9-88-0~3 l 3 1 q 1 q8
-2~-
password, the user must supply the clear form of the password
as an additional parameter to the cryptographic service
request. Control vector checking proceeds as described above
and the control vector checking unit 1~ will then output in
response thereto, an authorization signal on line 20 to the
crvptographic processing unit 16 that the function of
recovering the cryptographiC key is authorized. The password
field in the control vector is not checked in the control
vector checking unit 14. The cryptographic processing unit 16
will then operate in response to th~ authorization signal on
line 20, to receive the encrypted form of the cryptographic key
from the cryptographic key storage 22 and the clear password
via the password channel 32 connected to the input/output path
8 connected to bus 12. The password is then inserted into the
control vector, so that the control vector is now complete, and
is run through the hash function genera~or, producing an N-bit
hash value. The recovery of the key can go forward as bcfore,
i.e., the encrypted cryptographic key is decrypted under the
storage key which is a logical product of the N-bit computed
hash value of the associated control vector and the N-~it
master key stored in the master key storage 18.
Although the password is not checked as part of the key
recovery process, or as part of the process of servicing
cr~ptographic service requests, such checking is not required.
When the key was originally generated, t was encrypted under
the hash value of a control vector which included the password.
Later, when the key is to be recovered, if the user supplies an
incorrect password, then its associated encrypted key will be
decrypted under a storage key which represents a logical
product of an incorrect assGciated control vector and the
master key, ancl hence, and for all practical purposes, a
random, unknown, and unpredictable key will be recovered and
used in processing the requested cryptographic instruction.
Fig. 17 describes several ways in which a password can be
incorporated into the control vector. In particular, the
password can be a positional dependent field in the control
vector, as shown in ~ig. 17, a part "a," or it can be a field
~9-88-023
-25- 1 31 91 ~
in a tag-oriented structure with field descriptor, fleld
length, and datum, as shown in Fig. 17, part "b," or it can be
a field in a tag-oriented structure with field descriptor/
datum, and delimiter character, as shown in E'ig. 17, part "c."
The reader will appreciate that these and other methods can be
found to conveniently incorporate the passwo.d field into the
control vector for the purpose of authorizing the use of a
cryptographic key.
Fig. 20 gives another view of the cryptofacility 4 for
performing encryptions using a control vector which includes a
password (in either cleartext or ciphertext form). The control
vector in register 90 is of arbitrary length and includes a
vacant (all zeros) field as shown in Figs. 16 and 17, into
which a user-supplied password from password input device 32 is
to be inserted in the staging register 91 before inputting the
control vector (including the password~ to the hash function
processor 92. The hash function processor 92 outputs an N-bit
hash value which is characteristic of the combined control
vector and user-supplied password. The N-bit hash value is
then exclusive-ORed in logic 46 with the N-bit key encrypting
key KEK to produce a product which is an N-bit computed key
value, which will be the key input to the encryption device ~1.
The ciphertext output by encryption device 41 is characterized
by the N-bit hash value of the control vector/password
combination. Decryption can be done in the same manner,
substituting the decryption device 47 for the encryption device
41 in Fig. 20. When the ciphertext is to be decrypted, if the
user supplies the wrong password, which is then put into the
control vector, the resultant hash value thereof will not be
the correct computed key value necessary to produce a cleartext
output from the decryption device 47.
Time Intervals and Control Vectors:
Finer control on cryptographic key usage can also be
obtained by including date and time information in the control
vector. This concept can be implemented in several different
forms, although basically one or more time intervals are
encoded into the control vector for the purpose of specifying
when the associated cryptographic key may or may not be used
for processing, i.e., used with a cryptographic service
request. Even finer granularity can be o~tained by limiting
access to keys according to instruction types or parameters
within instructions. For example, the control vector can be
. .~A9-88-023
131~1~8
encoded to permit a key to be used within an encipher
instruction during a first period and within a decipher
instruction during a second period not equal to the first
period. Similarly, access to the key could vary according to
other system parameters besides instruction type. For example,
the key may be active on system A during a first period and
active on system B during a second period. The reader will
appreciate that linking periods of time to instructions,
systems, users, etc., can be accomplished in many useIul ways
not specifically defined by the preserlt invention, but which
are built upon the basic concept of including time information
in the control vector in some way. The use of time information
in the control vector may be particularly advantageous in
applications where very high security is required, or for
particular applications where it is desired to allow key usage
for a certain period of time (e.g., which may provide the user
access to a certain system resource to allow the user to
inspect and become familiar with an application, but which does
not give the user unlimited use to the application until the
user purchases or subscribes to the application.)
In accordance with the invention, as shown in Fig. 18, a
system for incorporating time information into the control
vector is provided~ As shown in Fig. 18, the control vector
stored with the encrypted form of its associated cryptographic
key in the cryptographic key storage 22 has a time interval
field, which consists of one or more intervals of time each
delineated by a starting date and time and an ending date and
time. The cryptographic facility 4 is also equipped with a
real time clock 34 connected to bus 12, thus enabling clock
values to be read out over bus 12 by control vector checking
unit 14. A provision also exists, although not shown in Fig.
18, to initially set the real time clock using a process with
integrity. For example, the real time clock 3~ would be
initialized using a process similar to that whereby the master
key 18 is initialized, and involves a hand-held key
entry device connected to a secure front panel entry
port with a physical key-activated key switch used for
enabling the master key entry process. A different
switch position and the same hand~held key entry device
could be used to enter a clock value into the real time
clock register 3~. Other mechanisms for initializing
the clock value
~IA9-88-023
-~7-
1 3 1 9 1 q8
can be employed. Otherwise, the components in Fig. 18 are
exactly the same as the components in Fig. 16, and the
description for handling a cryptographic service requ~st
described above, except for the e~ceptions noted below, also
similarly describe the process for handling a cryptographic
service request when a time interval ls incorporated in the
control vector and the cryptographic facility has a real time
clock, as shown in Fig. 18.
In accordance with the invention, as shown in Flg. 18, at
the time when a cryptographic service request is made which
uses a key whose control vector has an associate time interval
field, processing is performed as follcws. Contral vector
checking proceeds as described above except that now an
additional check is performed on the stored time information.
(The control vector may or may not have an associated password
field, but this level of controlled key management is invariant
to the checking on the time interval described herein.)
Referring to Figs. 18 and 21, the control vector checking unit
1~ accesses the current real time clock value Erom clock 34 and
a check is made to determine that the clock value falls within
the time interval specified in the control vector. If more
than one time interval is present in the control vector, then
the clock value must fall within one of these time intervals
(but need not fall within more than one of the intervals). If
this check succeeds and also the remainder of the control
vector checking succeeds, then control vector checking unit 14
will output in response thereto, an authorization signal on
line 20 to the cryptographic processing unit 16 that the
function of recovering the cryptographic key is authorized.
The cryptographic processing unit 16 will then operate in
response to the authorization signal on line 20, to receive the
encrypted form of the cryptographic key from the cryptographic
key storage 22 and to decrypt the encrypted form under the
storage key which is a logical product of the associated
control vector and the master key stored in the master key
storage 18.
As shown in Fig. 21, the control vector checking unit 1~
accesses the real time clock 34 and compares the current time
with the periods specified in the control vector C~ The
control vector checking unit also checks that the control
vector C allows the usage specified by the cryptographic
service request input thereto. If both of these tests are
satisfied, then an enable signal is output on line 20 and the
9-88-023
-28- l 3l ~l q8
control vector C, which is of arbitrary length, is input to the
hash function processor 92 where it is converted into an N-bit
hash value C'. The N-bit hash value C' is then exclusive-ORed
with the N-bit key encrypting key KEK in the exclusive-OR 46 to
reproduce a product which is an N-bit computed key value, which
will be the key input to the decryption device 47. (Encryption
can be done in the same manner, substituting the encryption
device 41, for the decryption device 47 in Fig. 21.)
Fig. 19 further elaborates on the time interval field
shown in Fig. 18. More specifically, Fig. 19, part "a"
describes the time interval field as one or more intervals
consisting of a start date/time and an end date/time. The
method for encoding these fields and the measure of time (e.g.,
hours, minutes, seconds, etc.) is unimportant to the present
invention. Fig. 19, part "b" describes a method whereby the
time intervals are associated with particular instructions, so
that processing with the key is dependent on the instruction
required to do that processing. Fig. 19, part "c" describes a
method whereby the time intervals are associated with
particular systems, so that processing wlth the key is
dependent on the system where the key is to be used. This
requires the cryptographic facility to provide the control
vector checking unit 14 with a system ID, not shown in Fig. 18,
but which could be stored with integrity within the
cryptographic facility and accessed as r.eeded. The system ID
is ini.ialized into the crypto facility using a process similar
to that of initializing the master key or the real time clock
value, already described above. Likewise, although not
specifically shown, the time interval field could be
implemented similarly to the password field, as described in
Fig. 15. That is, the time interval could be a positional
dependent field in the control vector or it could be a
tag-oriented field, and could be implemented in any of the ways
already defined and described by Fig. 15 (except that the
password field is replaced by a time interval field).
The encryption device 41 and the decryption device 47, in
their preferred embodiment, use the ANSI data encryption
algorithm (DEA) which is a standard cryptographic algorithm for
commercial data security products, and is described in the
standard ANSI X2.92-1981 "Data Encryption Algorithm." The DEA
is a symmetric block algorithm cipher algorithm that uses a
56-bit secret key to encipher 64 bits of plaintext to form 64
bits of ciphertext. DEA keys are normally stored with one
MA~-88-023
-29-
73191~q~
parity bit per byte, forming a 64-bit key. DEA forms the basis
for the National Bureau of Standards approved Federal Data
EncryptiOn Standard, so it is also called DES. HoweVer~ oth~r
embodiments for the encryption device 41 and decryption device
47 can be chosen as being more suitable for particular
applicatiGns. Alterrate encryption algorithms can be employed
with different key and block sizes than thGse employed in the
DEA.
The preferred embodiment for the one-way public hash
function performed in the hash function processor 92 is by
making use of the algorithm for calculating modification
detection codes (MDC)
However, alternate hash functions can be employed for
converting the arbitrary length control vector in the storage
register 90, into a hash value having a ~ifferent length
suitable for exclusive-ORing with the key portion, in
accordance with the invention. Where the key portion length is
64 bits, a hash value length of 64 bits will be required to
enable the performance of an exclusive-OR therebetween in
accordance with the invention. If the key portion length is
128 bits, then the hash value length must also be 128 bits. If
an alternative key portion length value is employed, then an
equivalent alternative hash value length must also be employed,
in order to enable exclusive-ORing the key portion with the
hash value in the exclusive-OR 46, in accordance with the
invention. A portion of the hash value can be exclusive-ORed
with a portion of tor the whole) key having the same bit
length.
In an alternate embodiment of the invention, clear keys
can be stored in the crypto facility for immediate availability
in cryptographic operations. Those clear keys can be stored
for example in the working storage 2~ in Fig. 22. In a first
method, each key and its associated control vector are stored
as a paired expression in the random access memory (RAM)
working storage 24 of the crypto facility. During routine
operations, in order to access a particular key, the associated
control vector is first accessed and the control vector
checking operation is carried out as has been previously
described, in order to ensure that the proposed key usage is
authorized. If the proposed usage is authorized~ then the
corresponding key is accessed from the working stoxage and is
9-88-023
-30-
13191q8
used for the intended operations within the crypto facility.
In a seeond method, the exelusive-OR product of the key and the
hash value of its assoeiated eontrol veetor are stored in the
working storage inside the erypto facility. The arbitrary
length control vector, itself, can either be stored in
association with the key/hash value product in the working
storage or alternately the arbitrary length control vector can
be supplied on the input path 8. During routine operations, in
order to aecess a partieular key, the associated arbitrary
length control vector is first accessed from the working
storage or alternately is first received over the input path 8
and the control vector checking operation is carried out as has
been previously described, in order to ensure that the proposed
key usage is authorized. If the usage is authorized, then the
arbitrary length control vector is processed through the hash
function processor 92 to produce the hash value. Then,
the exclusive-OR product of the key and its associated hash
value of the control vector is accessed from the working
storage and exclusive-ORed with the hash value just computed by
the hash function processor 92, resulting in the key which can
then be used in the requested cryptographic operations. In a
third method, for a 128-bit key and 128-bit hash value, the
left half of the key can be exclusive-ORed with the left half
of the hash value and stored in the working storage and the
right half of the key can be exclusive-ORed with right half of
the hash value and stored in the working storage. In a fourth
method, if the key is a 64-bit key and the hash value is
128-bit hash value, then the 64-bit key can be exclusive-ORed
with the left half of the hash value and stored in the working
storage and the 64-bit key can be exclusive-ORed with the right
half of the 128-bit hash value and stored in the working
storage. Each of these methods has the advantage that
encryption and decryption operations on the key need not be
conducted to recover the key, as long as the key is stored in
the clear text form inside the secure boundary of the crypto
facility, thereby enhancing the speed of operations. Other
logic functions besides the exclusive-OR, can be used to
eombine the hash value of the eontrol vector with its
associated key for storing in the working storase 24.
Although speeifie embcdiments of the invention have been
disclosed, it will be understood by those havins skill in the
art that minor ehanges ean be made to the speciric embodiments
disclosed, without departing from the spirit and the scope of
the invention.
