Note: Descriptions are shown in the official language in which they were submitted.
MA9-88-012
-1-
.
1322418 i
Description
DATA CRYPTOGRAPHY OPERATIONS USING CONTROL VECTORS
Ba _gLound of _he_I_vention
1. Technical Field
The invention disclosed broadly relates to data processing
technology and more particularly relates to cryptographic
applications in data processing.
2. Back~round Art
The following tWo patents are related to this invention
and are both assigned to IBM Corporation: U.S. Patent No.
4,850,017, issued July 18, 1989, B. Brachtl, et al.,
"Controlled Use of Cryptographic Keys via Generating Stations
Established Control Values", U.S. Patent No. 4,941,176, issued
July 10, l990, S. M. Matyas, et al., "Secure Management of Keys
Using Control Vectors".
Various methods exist in support of elactronic data
security. Cryptography is the transformation of intelligible
information into apparently unintelligible form in order to
conceal the information from unauthorizad parties.
Cryptography is the only known practical method to protect
information transmitted through communicatlons networks that
use land line~, communications satellites, and microwave ~
facilities. It can also be the most economical way to protect
stored data. Cryptographic proc~edures can be used not only to
protect the privacy of data, but also khe integrity of data.
The ~ryptographi~ -transformation of data is ordinarily
defined by a selected algorithm, or procedure, under~the
control of a key. Since the algorithm is normally public
knowledge, protection of the transformed~, or enciphered, data
depends on secrecy of the key. Thus the key must be kept
secret to preVent~an~opponent from simply using the known
algorithm and key to recover the encipherèd data. The
protection of the data therefore hinges on the protection of
~ecret keys.
:
MA9-88-012
--2--
t 3224 1 8
A new approach to key management is described in -the
above-mentioned U.S. Patent No. 4,941,176 which also provides a
good background for this invention. The invention disclosed
herein deals with data cryptography which has as its objective
the application of crytographic keys and methods to protecting
the confidentiality and integrity of data via cryptography
whereas U.S. Patent ~o. 4,941,176 deals with the generation,
distribution, and management of the keys themselves.
Prior art methods for encryption and decryption of data
have evolved into complex sequences of key and data
manipulations to thwart the attacks of an eavesdropper. These
sequences have become so convoluted that security management of
the secure system is difficult. Changing the security features
of a processor or a system of processors is costly. What is
needed is a better way to control usage of keys and the data
encrypted by those keys. It is important for the system
administrator to be able to specify the security features of
the system, including the ability to maintain the separation of
certain types of data and the corresponding keys. To maximize
the security of the system, the administrator should be able to
do this on a dynamic, unannounced basis with ease. The system
administrator must be able to enforce a security policy for the
system which imposes restrictions on the users, the data, the
keys and the cryptographic operations which can be performed.
That enforcement should be easily implemented~by the
administrator and yet should be secure from subversion by an
attacker. The features of flexibility and security have been
difficult to achieve in the prior art.
Obiects of the Invention
It is therefore an object of the invention to provide an
improved method of data cryptography.
It is another object of the invention to provide an
improved method of data cryptography which is more flexible
than in the prior art.
It is another object of the invention to provide an
improved data cryptography method which controls the
authorization of users to encrypt, decrypt or authenticate data
in accordance with a security policy established by the system
manager.
,
A
..,
MA9-88-012
--3--
1 3224 1 8
It is another object of the invention to provide a data
cryptographic method which builds into the storage of a key the
authority to use that key in a manner which has been authorized
by its originator.
It is an object of the invention to improve file security
by providing the ability to encrypt a data file so that one
portion is fully encrypted and another portion can be decrypted
by authorized recipients.
Summary of the Invention
These and other objects, features and advantages are
accomplished by the invention disclosed herein. Data
cryptography is achieved in an improved manner by associating
with the data cryptography key, a control vector which provides
the authorization for the uses of the key intended by the
originator of the key. Among the uses specified by the control
vector are limitations on encryption, decryption,
authentication code generation and verification, and
translation of the user's data. Complex combinations of data
manipulation functions are possible using the control vectors,
in accordance with the invention. The system administrator can
exercise flexibility in changing the implementation of his
security policy by selecting appropriate control vectors in
accordance with the i~vention.
Complex scenarios such as encrypted mail box, session
protection, file protection, ciphertext translation center,
peer~to-peer ciphertext translation, message authentication,
message authentication with non-repudiation and many others can
be easily implemented by a system designer using the control
vectors, in accordance with the invention.
Brief Description of the Drawings
These and other objects, features and advantages of the
invention will be more fully appreciated with referencQ~to the
accompanying figùres:
Fig. 1 is a system dia~ram showing the major components of
the Cryptographic Facility (CF).
Fig. 2 is a system diagram showing the components of the
CF, software driver CFAP and cryptographic application
programs.
Fig. 3 illustrates the fundamental cryptographic key
separation.
MA9-88-012
--4--
1 3224 1 8
Fig. ~ illustrates data key separation.
Fig. 5 shows the general format for Control Vectors (CV).
Fig. 6 shows the CV format for privacy ke~s.
Fig. 7 shows the CV format for MAC keys.
Fig, 8 shows the CV format for data compatibility keys.
Fig. 9 shows the CV format for data translate (XLATE)
keys.
Fig. 10 shows the CV format for ANSI Data keys.
Fig. 11 shows the CV format for intermediate ICVs.
Fig. 12 shows the CV format for tokens.
Fig. 13 is a block diagram of the encode instruction.
Fig. 14 is a block diagram of the decode instruction.
Fig. 15 is a block diagram of the encipher instru~tion.
Fig. 16 is a block diagram of the decipher instruction.
Fig. 17 is a block diagram of the genera~e message
authentication code ~Genmac) instruction.
Fig. 18 is a block diagram of the verify message
authentication code tVermac) instruction.
Fig. 19 is a block diagram of the translate cipher text
instruction.
Fig. 2~ shows the electronic code book (ECB) mode of DES
encryption.
Fig. 21 shows the cipher block chaining lCBC~ mode of DES
encipherment.
Fig. 22 shows the C~C mode of DE~ decipherment.
Fig. 23 shows the message authentication (MAC) algorithmO
Fig. 24 summarizes the equations for each of the data
instructions.
Fig. 25 shows the operation of session protection.
Fig. 26 shows the operation of file protection.
Fig. 27 shows the operation of encrypted mail box.
Fig. 28 shows the operation of ciphertext translation
center.
Fig. 29 shows the operation of peer-to-peer ciphertext
translation.
Fig. 30 shows translating part of an encrypted file.
Fig. 31 shows message integrity using control vectors.
Fig. 32 shows message integrity with non-repudiation using
control ~ectors.
Fig. 33 shows a message format.
MA9-88-012
--5--
1 3224 1 8
Descript_on of the Best Mode f_r_CarrYi_q _ut the Invention
The reader should refer to U.S. Patent No. 4,941,176
referred to above for an overall description of the principles
of the Cryptographic Architecture (CA) underlying the invention
disclosed herein. The Cryptographic Architecture enforces
strict key separation within the local cryptographic facility
and between systems by employing control vectors which force
the recipient or user of a key to use the key in a manner
consistent with the intentions of the originator of the key.
The following cryptographic data management functions are
provided by the invention disclosed herein:
1. Data Confidentiality. Data confidentiality protects the
contents of a message or file form unauthorized
disclosure.
Applications of data confidentiality include the
following:
a. Session Protection. Data encryption to protect the
confidentiality or session level data transmission
between two communicating devices. Each end user
(device or application) shares a common data
encrypting/decrypting key, thus permitting each end
user to both send and receive encrypted data.
b. File Protection. Data encryption to protect the
con~identiality of data files. A single end user
(device or application) possesses a data
encrypting/decrypting key permitting data to be
encrypted for storage and to be decrypted, at a later
time, for purposes of recovery or access to the file.
`
c. Encrypted Mail Box. The encrypted mail box describes
a multi-user environment in which each user has a
data/privacy key in two forms. The first form
permits data encryption; the second form permits data
decryption. The first form of the key is placed in a
public directory or central registry accessible to
all users of the system. Each so registered key is
recorded under a user identifier belonging to the
~;,
t MA9-88-012 -6-
1 3224 1 8
user who registers the key. The second form of the
key is kept private by the user to which it belongs.
Thus, a user i who wishes to send encrypted messages
to user j, first requests user i's encryption from
the public directory. Data encrypted with this key
is then sent to user i and placed in user i's mail
box. User i can read received mail by decrypting
first with his/her private decryption key. But since
no other user has access to user i's decryption key,
the environment is such that users can encrypt mail
for each other user but only the authorized
designated receivin~ user can decrypt and read
hi`s/her mail.
d. Ciphertext Translation Center (CTC). The ciphertext
translation center is a network node or device
capable of securely translating encrypted data from
encryption under a first data key to encryption under
a second data key. In effect, the CTC possesses one
or more data keys under which encrypted data may be
received and one or more data keys under which
received encrypted data may be re-encrypted. These
data keys thus establish a secure channel permitting
the CTC to translate ciphertext from one key to
another but not to decrypt ciphertext. The CTC may
. be further restricted from encryptin~ data with one
or more of these data/privacy keys for the purpose of
introducing data into the secure channel.
:
e. Peer-to-Peer Ciphertext Translation. This
environment consists of a chain of two or more CTCs
which establish a secure channel from one set of
network devices to another set of network devices.
The first CTC in the chain posse~ses one or ~ore data
keys under which encrypted data may be received from
the first set of network devices. Each CTC in the
chain possesses one or more data keys under which
encrypted data may be re-encrypted, but not
decrypted. The CTCs may be further re5tricted from
encrypting data with one or more of these keys for
the purpose of introducing data into the secure
channel. The last CTC in the chain re-encrypts the
encrypted data under one or more data keys shared
with members of the second set of network devices.
, MA9-88-012
132~418
f. Translate Part o~ an Encrypted File. This is an
application wherein part of an encrypted file can be
translated to a key which can be conveniently shared
with an intended receiver. The method avoids sharing
the original data/privac~ key used to encrypt the
file, since doing so may jeopardize the
confidentiality of data not intended to be shared.
2. Data Integrity. Data integrity protects the contents of
message or file from unauthorized modification. This
includes changes, additions, and deletions to the data.
Cryptography provides only methods for detecting
unauthorized changes to datac It cannot prevent
unauthorized changes to data.
3. Message Authentication. Message authentication is a
procedure established between two communicants which
allows each communicant to verify that received messages
are genuine. Communicants can be people, devices, or
processing functions. Message authentication allows the
receiver of a message to determine that:
a. The message originated with the alleged sender.
.
b. The contents of the message have not been
accidentally or intentionally changed.
c. The message has been received in the same sequence
that it was transmitted.
:
d. The message was delivered to the intended receiver.
In other words, message authentication permits the
receiver to valiaate a message's origin, contents~
timeliness, and intended destination. Applications of
message authentication include the following:
a. Straight message authentication.
b. Non-repudiation via MACGEN and MACVER.
, MA9~88-~12
,
1322418 -
Fig. 1 gives a block diagram representation of the data
processing system with the cryptographic facility therein. In
Fig. 1, the data processing s~stem 2 executes a program such as
the crypto ~acility access programs and the application
prograrns illustrated in Fig. 2. These programs output
cryptographic service requests for data cryptography operations
using keys which are associated with control vectors. The
general format for a control vector is shown in Fig. S.
Control vectors define the function which the associated key is
allowed by its originator ~o perform. The invention herein is
an apparatus and a method for validating that data cryptography
functions requested for a data set by the program, have been
authorized by the originator of the key.
As is shown in Fig. 1, contained within or associated with
the data processing system 2 is a cryptographic facility ~
which is characterized by a secure boundary 6. An input/output
path 8 passes throush the secure boundary 6 ~or receiving the
cryptographic service request, data, cryptographic keys and
their associated control vectors from the program. The
input/out 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 units 14 is coupled to the
instruction in storage 10 and a cryptographic processing units
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 data cryptography 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 data cryptography function with a cryptographic
key. The contxol 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 connectedlto the
cryptographic instruction storage 10, for receiving control
signals to initiate checking that the control vector authoriæes
the data cryptography function which is requested by the
cryptographic service request.
I~LA9-88-012
- 9 -
1322418 -
The control vector checking unit 14 has an authorization
output 20 which is connected to an input of the cryptographic
processing unit 16, for signalling that data cryptography
function is authorized, the receipt of the authorization signal
by the eryptographic processing unit 16 initiates the
performance of the requested data cryptography 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
eryptographic key is encrypted under a storage key which is a
logieal product of the associated control vector and the master
key stored in the master key storage 18.
An example of recovering an encrypted key from the
cryptographic key storage 22 occurs when the cryptographic
instruction storage 10 receives over the input/output path 8 a
eryptographic service request for recovering the cryptographie
key from the cryptographic key storage units ~2. The control
veetor eheeking unit 14 will then output in response thereto,
an authorization signal on line 20 to the cryptographie
processing unit 16 that the function of recovering the
eryptographie 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 whieh 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 eontrol vector, whose general format is
shown in Fig. 5, is stored with the encrypted form of its
associated eryptographic key in the cryptographic key storage
22. Since all keys stored on a eryptographic storage are
enerypted under the master key, a uniform method for encryption
and deeryption of enerypted keys thereon ean be performed.
The associated eontrol vector, whose general format is
shown in Fig. 5, ineludes fields defining the authorized types
, MA9-88-012
--10--
1 322¢ 1 8
of cryptographic functions, including data cryptography
functions, data encryption/decryption functions and personal
identification numbers (PIN) processing functions. In the data
cryptography applications, the data cryptography functions type
is designated for the type field. The associated control
vector also includes additional fields which can define export
control for the keys and associated encrypted information and
the usage of the keys and associated encrypted information.
The following provides a more detailed description of the
components and operations o~ the invention~
Fig. 2 shows the major components of a crypto subsystem.
The cryptographic subsystem consists of a Crypto Facility (CF),
Crypto Facility Access Program (CFAP), and Application Program
(AP). Normally, the CF is implemented in hardware, inside a
physically secure box. Depending upon the implementation, the
CF, CFAP, and AP could all be in a physically secure box.
The Cryptographic Facility 4 consists of:
Key Registers
The registers and their usages are described below:
- Master Key Register 18
The master key register is 128 bits wide, containing
the master key.
- New Master Key (NMK) register:
The new master key regis~er is 128 bits wide,
containing the new master key that is going to become
the current master key. The New Master Key will
become the current master key only after a special
instruction, the SMK instruction is issued to load
the value of new master key into the master key
register.
- Old Master Key Register
The old master Xey register is 128 bits wide,
containing the master key that was xeplaced by the
current master key. The master key update mechanism
is such that the current master key becomes the old
master key prior to the new master key becoming the
current master key.
- Key Part Register
The key part register is 128 bits wide, containing
the value of a key part (component), or a complete
ke~y that is being installed via a key loading device
such as a key pad or key board attached to the CF via
a~ optional secured physical interface~
~ MA9-88-012
1322418
- Working Key Register(s)
For performance reasons, the system has working
register(s~, 128 bits wide each, to contain immediate
working key(s) for fast accesses. For example, a key
that is used to encrypt data is brought into the CF
in encrypted form on the first use. It then is
decrypted and the clear value can be stored in one of
the working key registers. In subsequent uses to
encrypt or decrypt the data, this clear key can be
quickly accessed from a specific working key
register, thus eliminating the repeated steps of
decrypting the key prior to using it.
- Program MDC Register (PMDC Reg)
The program MDC register is 64 bits wide, containing
the MDC of the program to be loaded in the program
memory inside the CF.
- Dataset MDC registex (DMDC Reg)
The dataset MDC register is 64 bits wide, containing
the MDC of the datasets whose integrity is validated
by CFAP. This normally is, at least, the key storage
datasets.
Cryptographic instructions and control vector checking
algorithms.
The instruction set and control vector checking algorithms
are implemented in the secured cryptographic facility and
are stored in the cryptographic instruction storage 10
which is a random access memoryO They are executed in a
microprocessor such as~an Intel 80286 which can serve as
the cryptographic processing unit 16. The control vector
checking unit 14 can also be implemented in the
cryptographic processing unit. 16 or it can be implemented
by a second microprocessor such as an Intel 80286 serving
as the control vector checking unit 14.
Program Memory and Processing Engine ..l
The system can also employ a memory inside the CF to store
user's programs and a processing engine to execute the
programs. An example of this is a program or macro for
performing new algorithms for PIN verifications on new PIN
formats.
Random Number Generator 26
The ra~dom number generator is an algorithmic procedure
for producing 64 bit pseudo random numbers. The algorithm
MA9-88-012
-12-
1 3224 1 8
itself is nonsecret, but makes use of two 128 bit secret keys
and a ~4 bit nonsecret incrementing counter. Although
nonsecret, the integrity and proper management of the counter
are essential to security.
The Crypto Facility ~CF~ is a secure implementation
containing the Data Encryption Algorithm and storage for a
small number of key and data parameters in the cryptographic
instruction storage 10. It can be accessed only through
inviolate inter~aces (secure against intrusion, circumvention,
and deception) which allow processing requests, key, and data
parameters to be presented, and transformed output(s) to be
received.
The ANSI Data Encryption Algorithm (DEA) is a standard
cryptographic algorithm for commercial data security products.
The DEA is a symmetric block cipher algorithm that uses a
56-bit secret key to encipher 64 bits of plaintext to form 64
bits of cipher text. DEA keys are normally stored with 1
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.
The cryptographic facility must resist probing by an
insider adversary who has limited access to the cryptographic
hardware. "Limited" is measured in minutes or hours as opposed
to days and weeks, and the adversary is constrained to a
probing attack at the location where the system is installed,
using limited electronic devices as opposed to a laboratory
attack launched at a site under the control of the adversary
using sophisticated electronic and mechanical equipment.
The cryptographic facility must detect attempts at
physical probing or intrusion. This may be accompli~shed using
a variety of electro-mechanical sensing devices.
The cryptographic facility must provide ~or the automatic
zeroization of all internally stored clear keys~ Such
zer~ization must be performed automatically whenever an~
attempted probing or intrusion has been detected. The
cryptographic facility must also provide a manual capability to
zeroize key storage via the front panel interface.
The crypto facility contains one master key KM~ All other
keys can reside on mass storage encrypted under a key formed by
Exclusive ORing the master key with a valid control vector.
Refer to U.S. Patent 4,386,234 entitled "Cryptographic
MA9-88-012
-13-
1 3224 1 8 -
Communications and File Security Using Terminals" by Ehrsam, et
al., assigned to IBM Corporation ~r a description of an
example Cryptographic Facility.
The CFAP is the programming interface between the CF and
the application program. Since users do not have direct access
to the cryptographic facilit~, the CFAP is the programming
interface through which the users can request the CF to perform
specific operations.
Associated with the CFAP is the Key Storage outside ~he CF
where encrypted keys are stored. No clear keys are stored
outside the CF. The Key Storage 22 is also referred to herein
as the "Cryptographic Key Data Set" (CKDS).
The CFAP typically consists of the following:
- Key Storage Manager to manage keys stored in the key
storage mentioned above.
- CFAP Macros through which users access to the CF to
perform cryptographic functions.
Application programs include user's application programs,
some utilities such as a key installation utility, and
communication programs such as I~M VTAM.
User's application programs consist of statements that
will invoke certain CFAP macros to perform a specific task. As
m~ntioned, the CFAP is the only interface through which
application programs can request CF to execute a cryptographic
operation. For example, a user might want to encipher a ~ile
prior to shipping it to another node on the network. His
application program might have one statement that calls a CFAP
macro to generate a key, and another statement that invokes
another CFAP macro to encipher the data of the file with the
given key.
Another example of a user 9 5 application program is one
that allows the manual installation of keys on the system,
similar to the installation program mentioned ahove.
Notation - The ~ollowing notation is used herein:
ECB Electronic code book
CBC Cipher block chaining
KM 128 bit Master key
KEK 128 bit Key encrypting key
K 64 bit key
*K ~ 128 bit key
~*)K 64 or 128 bit key
M~9-88-012
-14-
~32~8
KD 64 bit data encrypting key
KK 64 bit Key encrypting key
*KK 128 bit Key encrypting key
KKo offset 64 bit Key encrypting key
*KKo offset 128 bit Key encrypting key
l*)KKo offset 64 or 128 bit Key encrypting key
*KKNI 128 bit partial notarizing Key encrypting
key
*KN 128 bit notarizing key, equivalent to
*KKNIo
cx 64 bit control vector
CxL 64 bit left control vector
CxR 64 bit right control vector
XOR or xor exclusive or operation
or logical or operation
X '0' Hex notation
11 concatenation operation
[x] optional parameter x
not = not equal
E or e single encryption
D or d single decryption
EDE or ede triple encryption
DED or ded triple decryption
: Equations The function of each instruction is
: mathematically denoted in the form-
~ Il, I2, I3, I4,.... --- 01, 02t 03,
: where Il, I2, I3,.. are~the inputs to the
~ function and 01, 02, 03,.~.. are the outputs
: from the functionO
: KM.Cx (KML XOR Cx) 11 (KMR XOR Cx~ = KMY 11 KMX
where, KML = Left 64 bits of the master key
KM,
KMR = right 64 bits of the master key
KM,
KMY = KML XOR Cx
KMX - KMR XOR Cx
e*KM.Cx(key) e*KM.Cx(key) = eKMY¦d~X(eKMY(key)))
where, KMY - KML XOR Cx
KMX= KMR XOR Cx
key = 64 bit key
.
M~9-88-O12
-15-
1322~18
e*KEKn.CX(key) e*KEKn.Cx(key) = eKEKY(dKEKX(eKEKY(key)))
where, KEKY = KEKnL XOR CxL
KEKX = KEKnR XOR CxR
key = 64 bit key
e*KM.CxL(KEKnL)e*KM.CxL(KEKL~ = eKMY)dKMX(eKMY(KEKnL)))
where, KEKL = left 64 bits of KEK
KMY = KML XOR CxL
KMX = KMR XOR CxL
e*KM.CxR(KEKnR)e*KM.CxR(KEKR) - eKMY(dKMX(eKMY(KEKnR~))
where, KÆKR = right 64 bits of KEK
KMY = KML XOR CxR
KMX = KMR XOR CxR
e*KEKo(key) e*KEKo(key) = eKEKLo(dKEKRo(eKEKLo(key)
where, KEKLo = XEKL XOR cntr
KEKRo = KEKR XOR cntr
cntr = implicit 64-bit key-message
counter for KEK
key = 64 bit key
Cryptographic Separation of Keys
Keys are separated cryptographically by the invention
according to key type and key usage attributes.
1. The architecture guarantees that cryptographic keys
can be used only in the way or ways prescribed and intended.
2. Internal Versus On-The-Link Separation. Internally
(i.e., within the cryptographic facility), keys are separated
via control vectors or other appropriate/equivalent mechanism.
On the link, keys are separated using control vectors.
3. Hardware Versus Software Enforcement. Certain
cryptographic separation is implemented in hardware; other
cryptographic separation can be implemented via software.
4. Control vector key types and compatibility-mode key
types. In order that the compatibiIity-mode key types will not
diminish the security, certain xules governing generation,
distribution, and usage of these two classes o~ key ty~es is
imposed.
5. A list of required key separations provided by the
invention is listed below:
a) Data Privacy. ENCIPHER from DECIPHER, allows public
key protocols such as mailbox, ballot and pass on.
b) Data MAC. MACGEN from MACVER, allows for
non-repudiation (equivalent of electronic signature).
MA9-88-012
-16-
1322418
c) Data XLATE. Allows a secure translate channel to be
established, where intermediate devices cannot decrypt
encrypted data.
d) Data COMPAT. Allows compatibility mode without
weakening securi~y of other data keys.
e) Data ANSI. Allows ANSI X9.17 data cryptography to be
coexist with non-ANSI X9.17 data cryptography without loss
of security to either approach.
f) Xey Encrypting Keys. XEX Sender from KEX Receiver.
g) PIN Keys. PIN Generating Key from PIN Encrypting
Key.
The following notation is used for Figs. 3 and 4:
Notation:
Near each line leaving a box is a separation letter and a
priority number.
The separation letter will correspond with descriptions
below:
The range of priority numbers (1 through 4) should be
interpreted as follows:
1. Absolute necessity
2. Strongly recommended
3. Recommended
4. Desirable
Fundamental Key Separation
Fig. 4 illustrates the fundamental cryptographic key
separationO An explanation of the separation is given below:
1. A. Data Keys : KEXs and PIN keys
If KDs (Data Keys) are not separated from KEKs and
PIN keys, then Decipher data function used with data
keys could be misused to decipher KEKs and PINs.
2. B~ Key Encrypting Keys : PIN keys
If KEKs (Key Encrypting Keys) are not separated from
PIN Keys it would be possible for an outsider to
wiretap an encrypted PIN block and replay it.in place
of an encrypted KD. Ahead of time, an insider
accomplice could replace the encrypted stored KEK
with the encrypted stored PIN Key in the receiving
node's cryptographic key data set. The PIN block
would be then recovered and used as a data key at the
receiving node. Subsequentl~, data that would be
encrypted under this PIN block used as a data key
MA9-88-012
-17-
1 3224 1 8
would be much easier to subject to a key exhaustion
attack as the variability of PINs (normally four to
six decimal digits) is much less than that of a
random 56 bit data key.
Data Keys Separation
Fig. 4 shows the flow chart of the Data keys separation.
The justifications for the separation are given below.
l. A - Authentication : Privacy
An insider who can collect plain and corresponding
ciphertext encrypted with a MAC key can perpetrate an
attack against the ~C procedure. For example, it
would be possible to construct fraudulent messages
and MACs that would be authenticated and accepted by
the MAC algorithm. Thus, the data keys used for
encryption~decryption should not be used for
authentication of data.
On the link, if an intercepted data key can be
substituted for a MAC key, the transmitted ciphertext
(under that data key) could be used to construct a
fraudulent message and MAC.
B - Xlate Ciphertext : Privacy
By definition, Xlate Ciphertext implies the use of a
pair of data keys KDl and KD2, where ciphertext
encrypted under KD1 is decrypted under KD1 and then
re-encrypted under KD2 without exposing the data to
the calling application program. Otherwise, Xlate
Ciphertext could be performed using the exlsting
Decipher and Encipher functions.
C - ANSI : all others
ANSI keys have their own protocol for key
distribution and an additional possible usage
referred to as ANSI COMBINE KEYS. These differences
mandate a separate pool for all ANSI keys.
D - Data COMPATIBILITY " All others ~
Data Compatlbillty keys exist dae to requirements to
be compatible with previous systems such as IBM*
CUSP/3848, IBM PCF, and IBM 4700. As the enforced
- internal separation in these systems does not extend
- to the level of separating MAC from Privacy keys,
these keys need to be distinguished from the CV keys
wh-ich support such an improved level of separation.
*Registered Trade Mark
MA9-a8-012
-18-
1322418
2. B - MACGEN : MACVER
Provides an audit trail to "prove" who originated a
message and MAC (called non-repudiation). This
method is no more secure than the CF, and assumes a
mutual trust in the integrity and secrecy of keys
stored in the CF.
3. C - Encipher : Decipher
Provides true separation of the encipher and decipher
functions, thus permitting data to be enciphered
under a data key without exposing the right to
decipher under that same data key. For example, an
encipher only data key could be used in a 'vote and
pass on' balloting scheme. A decipher only data key
could be used in an environment where a user is
authorized to read but not write some data.
Control Vectors
Control Vectors Concept
The control vector is a 64 bit nonsecret cryptographic
variable for controlling the usage of keys. Each key K defined
to the cryptographic system has an associated control vector C,
i.e., the key and control vector define a tuple (K, C).
Each control vector specifies a CV TYPE, which broadly
defines how the key may be used and the rules governing how
that key may be communicated on the link. A key may be a data
key, sender key encrypting key, receiver key encrypting key,
PIN encrypting key, PIN generating key, Intermediate ICV, Key
part or Token. Additional bits in the control vector specify
exactly in which cryptographic instructions and parameter
inputs the key may operate. Still other bits control the
export of the key, i.e., whether the key can be expoxted or
not.
The control vector is coupled cryptographlcally to the key
via a special encryption function. For exampIe, when the K is
stored in a Key Storage, K is encrypted under a key fo~med by
Exclusive-ORing the control vector with the master key, i.e., K
is stored as the tuple (eKM.C(K), C), where KM.C denotes KM xor
C. When K is transmitted on the link ~from one device to
another), a similar encrypted form is used. In this case, the
master key KM is replaced by a key encrypting key KEK, where
XEK is a key shared between the sender and receiver. Thus, K
is transmitted as the tuple ( eKEK.C(K), C). The architecture
,
MA9~88-012
-19-
1322418
does not require that the control vector be stored or
transmitted with the key in situations where its value is
defined implicitly from the context or can be reconstructed
from available key-related information.
Since the control vector (C) is tightly coupled to the key
(K), via the encrypted form eKM.C(K) or eKEK.C(K), it is
apparent that K cannot be recovered from its encrypted form
unless C is correctly specified. Thus, if the tuple (eKM.C(K),
C) is provided as an input to a requested cryptographic
instruction, the cryptographic facility will first check the
supplied value of C to determine that the requested usage of
the key is permitted. Only then will C be used to decrypt
eKM.C(K) to recover the clear value of K internal to the
cryptographic facility. If a false value C* is specified, the
cryptographic facility may be fooled temporarily into accepting
C*, but K will not be recovered properly. Thus, there is no
opportunity for a user to recover the correct value of K unless
the correct value of C is also specified. The cryptographic
principle is thus the basis upon which the entire architecture
is built; and additional security is provided as necessary and
where appropriate.
The control vector is a compact data structure for
defining the usage attributes of a cryptographic key. The
control vector is cryptographically coupled to the key via an
encryption process. This process is such that the key can be
decrypted properly only if the control vector is correctly
specified. (Even a single bit change in the control vector
will cause an ent1rely different key to be recovered.l
CV Checking
The control vector is designed to minimize CV checking.
Control vector usage bits are defined and structured so that
each usage attribute, by itself, grants or denies a specific
usage. Thus, the capability to encipher data via the Encipher
Data instruction is controlled via a single "Encipher" bit
within the control vector whose type/subtype is "data/privacy".
~ hus, each usage attribute is defined independently from
all other usage attributes. This g~arantees a CV checking
process such that each instruction checks only the usage
attributes called for by the requested function. A design
wherein usage attributes are enabled only when certain other
MA9-88 012
-20-
1 3224 1 8
attributes are enabled or disabled is specifically avoided,
since this increases CV checking. Some cross checking of
attributes among two or more control vectors is required, but
is kept to a minimum.
To facilitate and simplify CV checking, each cryptographic
instruction, where necessary, is passed a "mode" parameter
declaring a specified use of the key or keys passed as
parameters to the instruction. Thus, the CV checking process
tests each control vector according to the specified "mode".
This eliminates costly cross checking among control vector
attributes to ensure consistency.
The design also ~ollows a principle that no cryptographic
instruction generates a control vector. All control vectors
are supplied to the cryptographic instructions as parameter
inputs.
Where possible, like usage attributes and field
definitions are located at the same bit positions in the
control vector, regardless of CV type. This facilitates CV
checkingO For example, the translate ciphertext instruction
interrogates the same bit positions in the data/privacy and the
data~xlate control vectors, even though the usage bits are "E"
and "D" for the data/privacy CV and "XOUT" and "XIN" for the
data/xlate CV, respectively.
CV Structure
In general, the control vector structure (including
formats, field and bit assignments) has been defined to
minimize and to facilitate CV checking, while at the same time
providing cryptographic security. The CV structure, so to
speak, is the variable with the greatest degree of freedom in
the design process.
The following design options have been employed in the
control vector: ~ -
l. Vertic~l Separation. The control vector has.~a "CVType" field that provides vertical separation within the
control vector structure, much like the separation provided by
variants. Control vector types are defined along intuitive
lines, following existing key terminology and data
cryptography. However, vertical separation is implemented only
where necessary under the CA, thus ensuring architectural
simplicity and ease of comprehension of the CV checking rules.
~A9-88-012
-21-
1 3224 1 8
By first defining broad classes of CV Main Types (e.g.
Data Keys, Key Encrypting Keys, PIN Keys) and then further
defining CV Subtypes and usage attributes within CV Type, the
CV checking rules can be optimized much in the same way that a
"divided and conquer" search can be employed more ef~ectively
than a brute force approach.
2. Horizontal Separation. The control vector is ideally
suited as a data structure for recording the usage attributes
to be associated with a key (or other cryptographic variable).
Within the CA, this is accomplished by specifying a bit in the
control vector for every cryptographic instruction (or key
parameter within the instruction, if more than one key
parameter may participate) where the key may be used as an
input. A bit value of "1" signifies that a usage of the key is
"enabled" by the CF whereas a bit value of "0" signifies that a
usage of the key is "disabled" by the CF. This form of control
vector structuring is called horizontal separation.
3. Encoded Fields. A field of two or more bits is
sometimes encoded for reasons of security. An encoded field
has the property that individual bits have no significance by
themselves, but the bits together define a set of possible
values. Encoded fields have the advantage that they define
mutually exclusive events since the fisld can take on only one
value at a time. Encoded fields have the potential
disadvantage that CV checking is not always optimized from a
performance standpoint. However, encoded fields are sometimes
necessary to ensure that usage attributes cannot be mixed in
inappropriate combinations that give rise to cryptographic
attack or introduce some cryptographic weakness.
4. Protection From Non-System Generated Xeys.~ The
method for coupling the control vector and key is such that CV
checking is unable to detect a system generated key (via KGEN
or GXS) from a non-system generated keyO For this reason, a
"back-door" method exists within the architecture for ~.~
generating a keys and control vectors. It consists of defining
a control vector "of choice" and a random number which is then
represented as a key encrypted in the manner described under
the architecture using the selected control vector. (However,
the method has no capability to control the key actually
recovered within the cryptographic facility )
~ ~9-88-012
-2~- t 3224 1 8
The so-called "back-door" method of key generation is
primarily an annoyance, although in some cases cryptographic
attacks would be possible if additional measures of defense
were not taken in the architecture. It would be a simple
matter to define an architecture that eliminates this
"back-door" key generation tonce and for all), but doing so
would introduce additional unwarranted complexity and
processing. A more practical approach is followed by the CA,
viz., the "back-door" key generation problem is prevented only
where necessary for security reasons. Thus, a good balance
among security, complexity, and performance is achieved.
Techniques to avoid cryptographic weaknesses introduced by the
"back-door" method of key generation are these:
a) Where necessary, conflicting usage attributes
within a single control vector are split among two
control vectors. The GKS instruction has checking
that prevents so-called bad combinations of key pairs
from being generated.
b) Where necessary, conflicting usage attributes
within a single control vector are grouped into a
single encoded field.
c) As a last resort, extra redundancy is used so
that the CF can validate its own system generated
keys.
5. Even Parity for Control Vectors. Even parity is
enforced on the control vector. This ensures that the
Exclusive-OR of an odd parity key with the control vector will
resuIt in an internal key of odd parity. This, in turn,
ensures compatibility with hardware that may check such
internally derived keys for odd parit~ (if such checking is
enforced). Saying it another way, the CA cannot ensure that
hardware will not enforce this odd parity on internal keys.
A control vector of 64 bits, numbered 0 through ~3. The
most significant bit is bit 0, by convention. Of the 64 bits,
there are 8 parity bits.
6. Anti-Variant Bits. This guarantees cryptographic
separation between variants and control vectors, which may
unavoidably be mixed in some irnplementations internal to a
node.
7. Avoid Onto Mappings. The control vector design and
the manipulation of the control vector via the cryptographic
instruction set avoids instances where CV fields with multiple
MA9-88-012
-23-
1 32241 8
values are mapped into a single value. Some specific instances
of such onto mappings are allowed (e.g., LCVA, RFMK, and RTMK
instructions) where security is not jeopardized.
CFAP Control
Certain bits in the control vector are reserved for CFAP.
These bits can be used by CFAP for further data cryptography
control. These bits are not checked by the CF, but are
entirely managed by CFAP.
General Format for Control Vectors
Fig. 5 shows the general format for control vectors. The
first row of of Fig. 5 shows the fields that are in common for
most of the control vectors. They are briefly described as
follows: (Further details can be found in subsequent
subsections.)
* CV Type
This field indicates the type of control vector, and is
also the key type of the key to which this control vector
is attached. The CV Type field consists of main-type and
sub-type.
-
The main types of a control vector are:Data key
Data key~ are used to encrypt/decrypt data, or to
authenticate data.
PIN key
PIN keys are used to encrypt PINs or to generate
PINs.
Key-encrypting key
Key-encrypting keys are used to encrypt keys.
Key part
A key part is a part or a component of a key;~having
the same length as the key. For example, a key K may
have two key parts Ka and Kb such that Ka XOR Kb = K.
Intermediate ICV
An Intermediate ICV is used during MAC processing to
encrypt the intermediate Output Chaining Value of a
segment of data or message. This OCV is then fed
into the next segment of the data and used as an ICV.
MA9-88-012
-24-
1 32~4 1 8
This occurs when a message or data on which a MAC to
be generated or verified is long and must be divided
into shorter segments.
- Token
Tokens are variables used to protect the integrlty of
the data keys stored in the Data Key Dataset la key
stora~e for Data keys). They help prevent the access
of data keys by unauthorized users.
The sub type differentiates the classes of keys of the
same main type. For example, a key of main type data key
can have the sub type of privacy (capable of doing
encryption and decryption); or MAC (capable of doing data
authentication); or XLATE Data (capable of translating
ciphertext); etc. When no sub-type distinction is made,
the keys are normally referred by the main type (e.g.,
Data key, PIN key, etc.)
* Export Control
This field indicates how the export of the key associated
to this control vector is controlled, and wheth~r the key
is allowed to be exported.
* ~F Enforced Usage
This field indicates for what CA functions the key can be
used, and how it is used. For example, a data privacy key
may have the usage attributes E=1 and D=1, which indicate
that the key can be used in the Encipher and Decipher
function to encrypt and decrypt the data, respectively.
* AV (Anti-Variant)
This field differentiates any valid control vector from
the 64 predefined variants that are used in variant-based
crypto systems. Since all 8 bytes of the any variant of
the 64 predefined variants are the same, settin~ the value
of the AV field such that at least two byte~ of the
control vector are not the same will differentiate a valid
control vector from a predefined variant.
* Software Bits
This field represents control vector bits that are
controIled/managed entirely by CFAP; The software field is
- not checked/enforced by the hardware (CF). When no
MA9-88-012
-25-
1322~18
control vector exists, CFAP builds a control vector from
information supplied to CFAP (normally via parameter in a
macro). When a control vector already exists, CFAP will
chec]c the control vector (including the software field) to
determine whether the key is allowed to operate in the
manner specified/requested. The hardware (CF), unlike
software ~CFAP), checks only those bits associated with a
CA instruction, other usage bits are not checked).
* Extension
This field indicates whether the control vector is a 64
bit control vector or an extended control vector of 128
bits. In the current CA, all the control vectors have 64
bits in length. This field is defined now to ease the
expanding of the control vector in the future when the
number of bits required to specify the control vector
exceeds the b4 bit length.
* Reserved Bits
This field is reserved for the system for future use.
.
* Parity Vector
Every parity bit is the even parity of the preceding 7
bits of the byte.
For key-encrypting key control vectors, besides the common
fields listed above, there are two additional fields, KEY FORM
and LINK CONTROL.
* Key Form
This field indicates the length of the key (single or
double length) and whether the Xey half associated with
the control vector key is the right or left half of the
key. Note that for a single length key, the right half is
the same as the left half and is the key itself.
* Link Control
This field indicates how the key-encrypting key associated
to this control vector is used to transmit other keys on
the link, and what type of system (e.g., CV system or
non-CV system) can keys be shipped to or received from ,
under this key-encrypting key.
MA9-88-012
-26-
1322418
Note that the descriptions in the second row and the third
row in the general figure and other referenced figures in
this section are not part of the control vector. They are
put there to give information on the fields of the control
vector as follows:
- The second row indicates the bit length of the
fields. The abbreviation 'b' stands for 'bit'. For
example, lb stands for 1 bit, 3b stands for 3 bits, etc.
~ The third row indicates whether the field is checked
by hardware (CF) or software (CFAP).
Control Vector Format for Data Ke~
Data keys are divided into the following subtypes:
- Data Compatibility Key. This is the data key that
would be used to maintain compatibility with existing
systems such as IBM 3848/CU5P or IBM 4700 FCS. Since
these existing systems do not have the cryptographic
separation between privacy and authentication, this key
can be used to perform any or all of the following
functions: encipher, decipher, generate MACs and verify
MACs. This control vector can be removed (i.eO,
substituted by CV=0 on-the-link) when it is exported to
other systems (via the RFMK instruction), whereas the
control vectors for all other data keys except ANSI data
keys cannot be removed.
- Privacy Key. This is the key used for enciphering
and/or deciphering only.
- MAC Key. This is the key used for the purpose of
data authentication only. That is, it can only be used to
generate MACs and/or verify MACs.
Data Translation Key (Data XLT Key). This i5 the key
used in the translation of ciphertext. ~
- ANSI Xey. This is the key that is used in ANSI
applications. It can be used to encipher and decipher
data or to generate and verify MACs. It can also be
combined with another ANSI key to form an ANSI MAC key
(i.e., a Data ANSI key with generate M~C/verify M~C
capability). This control vector can be removed when
exported to other systems ~i.e., substituted by CV=0
~9-88-01
-27-
1 3224 1 8
on-the-link) via the ARFMK instruction, whereas the
control vectors for all other data keys except
compatibility keys cannot be removed.
Depending on the CV subtype of the control vector, the
bits in the USAGE field have specific meaning to be described
shortly.
Control Vector for Privacy Keys
Refer to Fig. 6. The following is a detailed description
of each field and subfield of this figure.
* CV Type
CV Type for privacy key (main type="DATA KEY",
subtype="PRIVACY".
* Export Control (controls exporting of this key): This field
occupies 1 bit:
- EXPORT CONTROL = 1: This key can be exported by RFMK.
Also, the RFMX, RTMK and LCVA instruction can reset
this bit to 0.
- EXPORT CONTROL - 0: This key cannot be exported by
RFMKO Also, it cannot be changed to 1 by any
instruction.
As an example, suppose node X generates a key K and
control vector C and sends them to node Y.
* Usage
a) E
E-1: This key can be used in the ENCIPHER
instruction to encrypt the data.
- E=O: This key cannot be used in the ENCIPHER
instruction to encrypt the data.
; b) D
- D=l: this key can be used in the DECIPHER instruction
to decrypt the data.
- D=0: This key cannot be used in the DECIPHER
instruction to decrypt the data.
* AV (Anti-Variant)
This field occupies two bits, used to differentiate the
- cont~ol vector ~rom 64 predefined variants that are used
MA9-88-01;~
-28-
1 3224 1 8
in variant-based crypto systems. Since all 8 bytes of the
any variant of the 64 predefined variants are the same,
setting the value of the AV field such that at least two
bytes of the control vector are not the same will
differentiate a valid control vector from a predefined
variant.
* Software bits
This field occupies 12 bits.
a) CV Version
This field is 6 bits long and is used by CFAP to
distinguish the current control vector definition from
future definitions.
b) Software=Enforced Usage
See also the CFAP section.
- CVDPIM (Control Vector Data Privacy Icv Mandatory)
CVDPCU (Control Vector Data Privacy CUsp)
- CVDP47 (Control Vector Data Privacy 4700)
~ CVDPM8 (Control Vector Data Privacy Multiple of 8)
* Extension
This field indicates whether the control vector is a 64
bit control vector or an extended control vector of more
than 64 bits.
* Reserved bits
This field is reserved for the system for future use.
:
* Parity
This field consists of the last bit of every byte of the
control vector. The parity bit of each byte is set to
achieve even parity for the byte.
- Control Vector for MAC keys
Refer to Fig. 7~ The following is a detailed description
o~ each field and subfield of this figure.
* CV Type:
CV TYPE for M~C key (main type=:DATA KEY", sub type
="MAC").
MA9-88-012
-29-
1 3224 1 8
* Export Control (controls exporting of this key):
Same description as that of Privacy keys.
* Usage
a~ MG
- MG=l: This key is permitted to be used in the GMAC
instruction to generate MACs on data.
- MG=0: This key is not permitted to be used in the
GMAC instruction to generate MACs on data.
b) MV
- MV=l: This key is permitted to be used in the VMAC
instruction to verify MACs on data.
- MV=0: This key is not permitted to be used in the
VMAC instruction to verify MACs on data.
* AV (Anti-Variant~
Same description as that of Privacy keys.
* Software bits
This field occupies 12 bits.
a) CV Verson - Same description
b) Software-Enforced Usage
See also the CFAP section
-
- CVDML4 (Control Vector Data MACLEN = 4)
- CVDM99 (Control Vector Data MAC MODE = ANSI X 9.9)
, - CVDM19 (Control Vector Data MAC MODE = ANSI X 9.19)
- CVDM00 (Control Vector Data MAC MODE = IBM 4700)
- CVDM30 (Control Vector Data MAC MODE = IBM 4730)
* Extension
~: :
Same description as that of Privacy keys.
* Reserved bits
Same description as that of Privacy keys. ~.
:`:
* Parity bits ~ ~
Same description as that of Privacy Keys. -
Control Vector for D ta Com~ibility Keys
Refer to Fig. 8. The followin~ is a detailed description
ot eaah field and subfield of this figure.
MA9-88 012
~ -30-
1322418
* CV Type
CV TYPE = for data compatibility key (main type="DATA
KEY", sub type ="coMpATIsILITy"
* Export Control
Same description as that of Privacy keys.
* Usage
a) E
- E=l: This key can be used in the ENCIPHER
instruetion to encrypt the data.
~ E=0: This key cannot be used in the ENCIPHER
instruction to encrypt the data.
b) D
- D=1: This key ean be used in the DECIPHER
instruetion to deerypt the data.
- D=0: This key eannot be used in the DECIPHER
instruetion to deerypt the data.
e) MG
- MG=1: This key can be used in the GMAC instruction
to generate MACs on data.
- MG=0: This key cannot be used in the GMAC
instruction to generate MACs on data.
d) MV
- MV=1: This key can be used in the VMAC instruction
to verify MACs on data.
- MV=0: This key cannot be used in the VMAC
instruction to verify MACs on data.
* AV ¦Anti-Variant)
SAme description as that of Privacy keys.
* Software bits
This field occupies 12 bits.
a) CV Version
Same deseription as that of Privacy keys.
b) Software-Enforced Usage
* Extension
Same description as that of Privaey keys.
:' ' ' "
MA9-88-012
-31-
1 322~ 1 8
* Reserved bits
Same description as that of Privacy keys.
* Parity bits
Same description as that of Privacy keys.
Control Vector for Data XLATE key
Refer to Fig. 9. The following is a detailed description
of each field and subfield of this figure.
* CV Type
CV Type for data XLATE key (main type="DATA XEY", sub
type="XLATE")
* Export Control ~controls exporting of this key)
Same description as that of Privacy keys.
* Usage
a) XDout
XDout=1: This key is permitted to be used as the
output data key in the TRANSLATE CIPHERTEXT
instruction.
- XDout=0: This key is not permitted to be used as the
output data key in the TRANSLATE CIPHERTEXT
instruction.
b) XDin
- XDin-1: This key is permitted to be used as the
input data key in the TRANSLATE CIPHERTEXT
instruction.
- XDin=0: This key is not permitted to be used as the
input data key in the TRANSLATE CIPHERTEXT
instruction.
, ~ .
* AV ~Anti~Variant~
Same description as that of Privacy keys.
* Software Bits
This field occupies 12 bits
a) CV Version
b~ Software-Enforced Usage
None.
,
~A9-88-012
-32-
~322418
* Extension
Same description as that of Privacy keys.
* Reserved Bits
Same description as that of Privacy keys.
* Parity Bits
Same description as that of Privacy keys.
Control Vector for ANSI Data Keys
Refer to Fig~ 16. The following is a detailed description
of each field and subfield of this figure.
* CV Type
CV Type for data ANSI key (main type="DATA KEY", sub type
="ANSI")
* Export control
Same description as that of Privacy keys.
* Usage
a) E
- E=l: This key can be used in the ENCIPHER
instruction to encrypt the data.
- E=0: This key cannot be used in the ENCIPHÆR
instruction to encrypt the data.
b) D
- D=1: This key can be used in~the DECIPHER
instruction to decrypt the data.
- D=0: This key cannot be used in the DECIPHER
instruction to decrypt the data.
c~ MG
- MG=1: This key can be used in the GMAC instruction
` to generate MACs on data.
- MG=0: This key~cannot be used in the GMAC
instruction to generate MACs on data.
d) MV
- MV-l: This key can be used in the VMAC instruction
to verify MAC on data.
w MV=0: This ~ey cannot be used in the VMAC
instruction to verify MAC on data.
MA9-88-012
- -33-
1 3224 1 8
e) ACMB
This bit indicates whether the data key can be XORed with
another data key having the ACOMBKD attribute. The XORing
process is done by the ACOMsKD instruction, as will be
described in section "ANSI Combine KDs (ACOMBKD)." The
resulting key is used to verify and ~enerate MACs for the
messages communicated via the ANSI X9.17 protocol.
- ACMB=1: This data key can be combined in the ACMB
instruction.
- ACMB=0: This data key cannot be combined in the ACMs
instruction.
* AV (Anti-Variant)
Same description as that of Privacy keys.
* Software Bits
a) CV Version
Same description as that of Privacy keys.
b) Software-Enforced Usage
None.
* Extension
Same description as that of Privacy keys.
.
* Reserved Bits
Same description as that of Privacy keys.
* Parity Bits
Same description as that of Privacy Keys.
Control Vector Format for Intermediate ICV
_
Refer to Fig. 11. The following is a detailed description
of each fiela and subfield of this figure~
" ~
- * CV TYPE
CV TYPE, where the last three bits xxx of CV TYPE are set
to zero but are not checked by the instructions
(maintype="Intermediate ICV", subtype=Not applicable3
* Export Control
Same description as that of Privacy keys. The ICV keys
are normally not imported to other nodes except in the
case of a hot backup. Thus, normally, this field assumes
the value B'00' for an ICV control vector.
MA9-88-012
-34-
1 3224 1 8
* AV (Anti-Variant)
Same descriptian as that of Privacy keys.
* Software Bits
a) CV VERSION
Same description as that of Privacy keys.
b) Sotware-Enforced Usage
None.
* Extension
Same description as t~at o~ Privacy keys.
* Reserved Bits
Same description as that of Privacy keys.
* pari~y B.l~s
Same description as that of Privacy keys.
Control Vector Format for Tokens
Refer to Fig. 12. The following is a detailed description
of each field and subfield of this figure.
* CV TYPE
CV TYPE, where the last three bits xxx of CV TYPE are set
to zero but are not checked by the instructions
(maintype="Token", subtype=Not applicable).
Tokens are secret quantities used to protect the integrity
of Data keys stored in the Data Keys Dataset (DKDS). Data
keys are stored in the DKDS in the form
token+e*KM.C:l(K),e*KM.C2(token). Token control vector
type is allowed in several instructions such as EMK, RTNMK
and RTCMK.
`: ~
* Export Control
Same description as that of Privacy keys. The ICV keys
are normally not imported to other nodesiexcept in the
case of a hot backup. Thus, normally, this field assumes
the value B'0D' for a~n ICV aontrol vector.
A9-88-012
-35-
1 3224 1 8
* AN ~Anti-Variant)
Same description as that of Privacy keys.
* Software Bits
a) CV VERSION
Same description as that of Privacy keys.
b) Software-Enforced Usage
None.
* Reserved Bits
Same description as that of Privacy keys.
* Extension
Same description as that of Privacy keys.
* Parity Bits
Same description as that of Privacy keys.
i
:
.
' , , :
~A9-88-012
-36-
1322418
Instruction Set
The instruction set described here is a common
cryptographic function set which is implemented in the CF.
There may be exceptions to this requirement; for instance, MDC
can be implemented at a CFAP level. Other deviations in the
instruction set implementation should be carefully considered
based on security requirements and product environment.
The instruction set is based on a control vector approach.
There are several fields in the control vectors which may or
may not be implemented in a particular system. However, the
minimum control vector checking as described here must be
performed in each system in the CF. If the full crypto
separation is not required or only a subset of the instruction
set is sufficient for a given application, the control vector
checking can be excluded for the functions not implemented in a
given design. (The checking on subtype fields in the control
vector, an encoded field, ensures that control vectors can not
be mixed and matched in the crypto instructions using invalid
combinations. Thig checking is crucial to security.)
The instruction set e~uations represent the inputs
required to the function and outputs expected from the function
related to a cryptographic function described. Instead of
passing actual data to the function, the implementation may
pass the addresses of data to the function. This addressing
would depend upon the given system implementation and is not
described here.
The equations describe all the parameters and data
required to perform a given function. Depending upon the modes
of the operation, some or all the parameters are used in the
function, however, the fields in the equation have to be
treated as inputs and outputs rather than the actual values of
inputs and outputs as passed to the function in a given
implementation. For example: the "A" field in the equation
represent the data to be passed to a function, the physical
form of this may be a 32 bit address pointing to the data to be
fetched by the instruction from memory or to be stored to the
memory. The data bus width from memory is also implementation
dependent, whereas the input data to be encrypted or decrypted
by crypto function operati~ns is always a multiple of 8 bytes.
There are two fundamental ways in which CV checking can be
done.
~9-88-012
-37-
1322418
1. Test Bits in Control Vector: Test the control vector
bits according to what they should be, if it does not
match then set a condition code and abort the
operation. For example, in ENCIPHER instruction "E"
bit of the CV is tested for "1", if it is not one
then the operation is aborted. For more complicated
instructions, the testing is not as trivial as this,
and we need to pass some parameters to specify the
intent of input and output operation and the usage of
control vector. For example, in generate key set
(GKS), "mode" is specified to the instruction to
generate a particular from of output, and the control
vector checking has to be performed according to the
"mode" specification.
2. Set bits in Control Vecto : Set a bit in control
vector as appropriate then perform the operation~
This does not require any testing of control vectors.
For example, in ENCIPHER instruction "E" bit is set
in the control and the operation is performed. Now,
each instruction has to know, what bits to set and
under what conditions? This strategy may not work in
all cases. For instance, how would the instruction
know what is the bit setting for "target control"?
This means, there has to be a parameter specified to
the instruction indicating to choose a particular
setting in the control vector. This approach will
take away all the flexibility in the control vector
specification.
Either of the above two techniques will satisfy the
cryptographic requirements of the control vector checking. We
have chosen the "Test bits in Control vector" approach (no bits
in the control vector are set by the instruction) for the
~ollowing reasons:
1. Instruction does not have to know what bits to s~t
nor when.
2. It is very flexible to pass a parameter like "mode"
and get the possible combination of'outputs, and
provide a combination of inputs to the instruction.
3. If the setting is hardcoded in the CF, then it is
very hard to make extension to the architecture, and
MA9-88-012
-~8-
1 3224 1 8
it is also very difficult to know all the possible
combinations ahead of time.
4. It simplifies hardware implementation, and provides
greater flexibility to software.
5. It preserves the intent of control vectors: Control
vectors (at the present time) are used for
cryptographic separation and specifically for
security reasons. Control vectors are not used in CA
for "specifying an operation or a function to the
instruction". In other words, control vectors are
not like an "extended opcode" for the instruction.
En _ de (ENC
Equation
KD, A -- eKD(A)
Inputs:
XD 64 bit clear key
A 64 bit plain text
Outputs:
eKD~A) 64 bit encrypted data
Description: The encode function is used to encipher an 8
byte plain text data in ECB mode using a 64 bit clear key. No
control vector is passed to this instructionO
Fig. 13 is a block diagram of this instruction.
CC: '
1. successul operation
20 unsuccessful operation (error)
NOTE: Unsuccessful operation can be any hardware error
specific to a given implementation. The condition
codes (CC described here mexely represent suggested
condition codes for the instruction, however, there
may be more condition codes implemented in a-given
system. ~Furthermore, the CC codes do not represent
the actual condition codes that have to be passed by
the function in a given implementatiion, the numbering
used here is for a convenient description of crypto
architecture.
Contxol Vector Checking: None.
' :
MA9-88-012
-3g-
~322418
Decode (DEC)
Equation: KD, eKD(A) -- A
Inputs:
KD 64 bit clear key
eKD(~) 64 bit encrypted data
Outputs:
A 64 bit encrypted data
Description: The decode function is used to encipher an 8
byte plain text data in ECB mode using a 64 bit clear key. No
control vector is passed to this instruction.
Fig. 14 is a block diagram of this instruction.
CC:
1. successul operation
2. unsuccessful operation (error)
Control Vector Checking: None
Encipher (ENCI)
Equation: e*KM.Cl(KD1), ICV, A, n, C1 --- eKDl(ICV,A)
.
Inputs:
e*KM.Cl(KD1) 64 bit data key (KD1) triple encrypted
under the master key (KM) with a
control vector Cl.
ICV 64 bit plain input chaining value
NOTE: Encrypted ICVs are managed by
CFAP as described in the "ICV/OCV
Management" and "Software Interface."
~ .
If output chaining value (OCV~ is
required, the last 8 byte output (En)
must be used as OCV, however, this is
not a standard approlach. Each system
implementation treats the encryption
and decryption of the last block
differently. Refer to "Software
Interface" for more details on the
. , . ~,
MA9-88-01~
-40-
~322418
last block treatment and OCV
generation techniques. CFAP handles
all the possible last block
encipherment and decipherment and also
OCV management.
A Data to be encrypted, in multiples of
8 byte blocks. The 8 byte blocks are
A1, A2,...An. If the last block ~n is
not a multiples of 8 bytes, padding
should be performed by CFAP before
calling this instruction. CF
instructions always assume multiples
of 8 bytes data as inputs and outputs.
n number of 8 byte blocks to be
encrypted. n should be as large as
possible, however, this may be system
dependent. CA does not define any
maximum limit on n.
For example: If number of 8 byte
blocks = 10,000 and n max = 4,000,
then Encipher instruction will be
invoked as follows:
- Encipher n=4000
Encipher n=4000
- Encipher n=2000
Note: After each call of Encipher,
the last 8 bytes enciphered data En
(OC~) has to be fed back as ICV input
to the next Encipher call. ~
cl 64 bit control vector for data key (KD1).
: I .
Outputs:
ekDl~ICV,A encrypted data, n blocks, each block
~ is 8 bytes (E1, E2.. En).
.
A9-88-012
-41-
1 3224 1 8 -
Description: The input data is encrypted via the CBC mode
of DEA encryption. Multiples of 8 byte blocks are encrypted by
this instruction until all n blocks are encrypted.
~ he architecture defines only plain ICV input to the
function. If encrypted ICV is required, the ICV can be
encrypted using a data key (KD2) using encipher instruction.
Encrypted ICV's can be decrypted using decipher instruction.
All the encrypted ICV's and OCV's are managed by the CFAP
programO
If the input data is not in multiples of 8 byte blocks
then padding must be done. This padding has to be performed by
CFAP before invoking the encipher function.
Fig. 15 is a block diagram of this instruction.
CC:
1. successful operation
2. C1 is invalid
3. unsuccessful operation (error)
Control Vector Checking:
1. Checking on C1
- cv type = "data/compatibility" or
- "data/privacy" or
"data/ANSI'
- E usage bit
- reserved ~48:63) = X'0'
NOTE: For all the instructions described here, control
vector checking implies that if the check is not passed
then the instruction must be aborted and the corresponding
control vector invalid condition code (CC) be turned on.
If there are one or more checks to be performed on the
control vectors, all the checks are performed and all the
checks have to be passed to perform the operation. If any
of the checks fail, the operation must be aborted.
Decipher (DECI)
:, : i .
Equation:
e*KM.Cl(XD1), ICV, eKDl(ICV,A), n, C1 -- A
Inputs:
MA9-88-012
-42-
1 3224 1 8
e*KM.CltKdl) 64 bit data key (KD1) triple encrypted
under the master key (KM) with a control
vector C1.
ICV 64 bit plain input chaining value.
Note: Encrypted ICVs are managed by CFAP
as described in the "ICV/OCV Management"
and "Software Interface."
If output chaining value (OCV) is required,
the last 8 byte input (En) must be used as
OCV, however, this is not a standard
approach. Each system implementation
treats the encryption and decryption of the
last block differently. Refer to "Software
Interface" for more details on the last
block treatment and OCV generation
techniques. CFAP handles all the possible
last block encipherment and decipherment
and also OCV management.
eKdl(ICV,A) encrypted data, n blocks, each block is 8
~ bytes (E1, E2..En).
.
.~ n number of 8 byte blocks to be decrypted. n
should be as large as possible, however,
this may be system~dependent. CA does not
define any maximum~limit on n.
~ote: After each call of Decipher, the
last 8 bytes enciphered data En (OCV) has
to be fed as input ICV to the next Decipher
; ~ call. This is being managed by CFAP.
For example:
If number of 8 byte blocks -10,000 and n
max =4000, then Decipher instruction will
be invoked as follows:
~:
Decipher n=4000
MA9-88-012
-43-
1 3224 1 8
Decipher n=4000
Decipher n=2000
Cl 64 bit control vector for data key tKDl).
Outputs:
A Plain data, in a multiples of 8 byte
blocks. The 8 byte blocks are Al,
` A2,... An.
Descriptiono The input data is decrypted via the CBC mode
of DEA encryption. The multiples of 8 byte blocks are
decrypted by this instruction until alI n blocks are decrypted.
The architecture defines only plain ICV input to ~he
function. If encrypted ICV is required, the CV can be
encrypted using a data key (KD2) using encipher instruction.
Encrypted ICV's can be decrypted using decipher instruction.
A71 the encrypted ICV's and OCV.='s are managed by the CFAP.
Fig. 16 is a block diagram of this instruction.
CC:
1. successful operation
2. Cl is invalid
3. unsuccessful operation (error)
Control Vector Checking
1. Checking on Cl
- cv type = "data/compatibility" or
"data/privacy" or
"data/ANSI"
- D usage bit = ~1
- reserved (48:63) = X'O'
ENMAC (GMAC)
i .
quation:
e*KM.Cl(KD2=l),~e*KM.C2(KD2)],
ICV[e*K~.C3(0CV~],
MA9-88-012
-44-
1322418
A, n, icv-type,output-type, mac-enc, Cl,[C2],[C3]
--- MAC (64 bit)
or
e*KM.C3(0CV)
Inputs:
e*KM.Cl(KDl) KD1 is a MAC generation key for single
encrypting MAC, triple encrypted under KM with a
control vector Cl.
e*KM.C2(KD2) KD2 is an optional MAC generation key for triple
encrypting MAC, triple encrypted under KM with a
control vector C2. This is an optional input
required for triple encrypting mac output if
mac-enc =1.
ICV ICV equal to zero is the default Initial
Chaining Value, and is standard to CA
architecture, ANSI X9.9 and ANSI X9.19.
Non-zero plain ICV can also be used to be
compatible with systems which require plain ICV
input. Encrypted ICV input i5 not supported by
CA as it was found that it does not provide any
more security for the function. Encrypted
~` intermediate ICVs are supported by CA.
Note: Encrypted ICVs if required are managed by
. ~ CFAP as described in the ICV/OCV Management" and
"Software Interface."
e*KM.C3~(0CV) This is a 64 bit intermediate ICV encrypted
under the~master key with a speciaI control
vector C3. This is an optional input which must
be provided if~large blocks~of data (/n~ are
used~to generate MAC. Decrypting the ICV is
done internal to the function. Intermediate OCV
can not be shipped from the local node, as it is
stored under the master key with a control
vector in the form for local uise only.
A Data to be MAC'd/ in multiples of 8 byte blocks
: :
~ (A1, A2.. :An~.
MAg-88-012
-45-
1 3224 1 8 -
n number of 8 byte ~locks to be MAC'd. n should
be as large as possible, however, this may be
system dependent. CCA does not define any
maximum limit on n. If large number of blocks
have to be MAC'd then GMAC is invoked multiple
number of times until all blocks are complete.
For example:
If n max is 4000 ~or the system, and the data to
be MAC's are 10,000 8 byte blocks, then GMAC is
invoked as follows:
GMAC n=4000,output-type=l,icv-type=O
G~AC n=4000,output-type=l,icv-type=2
GMAC n=2000,output-type=l,icv-type=2
Note: After each call of GMAC, the intermediate
ICV e*KM.C3(0CV) must be fed back to next GMAC
call as ICV input. The decryption of this
intermediate ICV must be done internally in the
CF
cv-type icv-type indicates whether the ICV passed to the
function is zero, pIain, or intermediate.
Intermediate ICV is triple encrypted under the
master key with a control vector C3. Zero ICV
is a deault value.
O: zero ICV ~default~ -
1: plain ICV
2: intermediate ICV (OCV)
output-type indicates the stage of the mac generation
~ ~ process to the instruction.
; ~ O: MAC output
Intermediate ICV output (OC~)
:
:
mac-enc mac-enc indicates a sinyle or triple encryption
mac output
,
:
MA9-88~012
-~6-
~322~18 -
0: single encrypting mac output
1: triple encrypting mac output(ANSI 9.19
requirement)
Cl,C2,C3 64 bit control vectors for KDl, KD2, and OCV
respectively. C2 and C3 are optional inputs to
the instruction, C2 must be input if mac-enc=l,
and C3 must be input if icv-type =2 or
output-type=l.
Outputs:
MAC is a 64 bit output, resulted from the single
encryption or triple encryption of the final
input block of data, depending upon mac-enc
parameter. This output is valid only if
output-type=0.
e~KM.C3(0CV) OCV is a 64 bit intermediate ICV triple
encrypted under KM with control vector C3. This
output is valid only if output-type=l. MAC
output and IntPrmediate OCV outputs both must
not be output at the same time for security
reasons.
. ~ ~
Description: The input data is encrypted with CBC mode of DEA
encryption, and the final block of encrypted data is output.
There are two modes, the single encryption mode and triple
encryption mode. ~With the single encryption mode, a single key
KDl is used to create the MAC. In the triple encryption mode,
::: : : :
the single encryption mode is employed with KDl to create a
MAC, except the MAC is then decrypted with XD2, and reencrypted
again with XDl to produce the final~64 bit MAC~
The instruction~outputs 64 bit MAC, however, X9.9~
, specifies 32 bit MAC which is 32 left most bits of the 64 bit
:
MAC output. CFAP has to extract the appropriate MAC bits from
the 64 bit M~C output.
ICV is zero as a standard and optionally can be a plain or
intermediate ICV to GMAC instruction. If encrypted ICV's are
required then CFAP must encrypt ICV under (KDS) and must pass a
plain ICV to the G~C instruction. The ANSI X9.9 MAC standard
MA9-8~-012
-- -47
1 3224 1 ~
specifies a zero ICV for the first block and thus is defined
here as a standard input. However, architecture provides plain
and intermediate inputs to satisfy every possible need of MAC
generation.
If MAC generation is required for the blocks greater than
n, intermediate ICV option must be used to generate MAC. This
requirement provides additional security by not exposing
intermediate ICVs in clear.
If the data block is not multiples of 8 byte blocks,
padding must be doneO The padding has ~o be performed by the
CFAP before invoking this function. MAC computation must be
for the binary data as specified by the ANSI X9.9-1986 section
5.0 and Coded character sets authentication if needed must be
implemented by CFAP.
Fig. 17 is a block diagram of this instruction.
CC:
1. successful operation
2. Cl is invalid
3. C2 or C3 is invalid
4. unsuccessful operation (error).
Control Vector Checking:
1. Checking on Cl
- CV type = "data/compatibility" or "data/mac"
or "data/ANSI"
- MG usage bit = 1
- reserved (~8:63)-X'0'
2. Checking on C2 if (mac-enc =l).
- cv type = "data/compatibilityl' or "data/mac"
or "data/ANSI"
- MG usage bit = 1
- reserved 48:63) =X'0'
3. Checking on C3 if (icv-type=2 OR output-type =1).
- CV type ="Intermediate ICV"
Verify MAC (VMAC)
Equation:
e*KM.Cl(KDl), [e*~M.C2IKD2)]
ICV[e*KM.C3(0CV)],
A,~C, n, icv-type,output-type,mac-enc,mac-len, Cl, [C2],[C3]
~A9-88-012
-48-
1 3224 ~ 8
yes/no
OR
e*KM.C3(0CV)
Inputs:
e*KM.Cl(KDl) KDl is a mac verification key for single
encrypting mac, triple encrypted under KM with a
control vector Cl.
e*KM.C2(KD2) KD2 is a mac verification key for triple
encrypting mac, triple encrypted under KM with a
control vector C2. This is an optional input
required for triple encrypting mac output if
mac-enc=l~
ICV ICV equal to zero is the default Initial
Chaining Value, and is standard to CA
architecture,ANSI X9.9 and ANSI X9.19. Non-zero
plain ICV can also be used to be compatible with
systems which require plain ICV input.
Encrypted ICV input is not supported by CA as it
was found that it does not provide any more
security for the function. Encrypted
intermediate ICVs are supported by CA.
NOTE: Encrypted ICVs if required are managed by
CFAP as described in the "ICV/OCY Management"
and "Software Interface."
e*XM.C3(0CV) This is a 64 bit intermediate ICV encrypted
under the master key with a special control
vector C3. This is an optional input must be
provided if large blocks of data ~] n) are used
to verify MAC. Decrypting the ICV is done
internal to the function. Intermediate OCV can
not be shipped from the local node, as it is
stored under the mas er key with a control
vector in the form for local use only. ~The
intermediate ICV's must be secret in the MAC
` verification process~to protect from attacks.
A Data used in MAC, in multiplesiof 8 byte blocks
(Al,A2...An).
MAC 64 bit MAC input o the instruction either
single or triple encrypted. By default, only
left most 32 bits of this MAC are used for MAC
MA9-88-012
-49-
1322418
comparison. mac-len may be used to explicitly
specify other comparison lengths.
n number of 8 byte blocks MAC'ed. n should be as
large as possible, however, this may be system
dependent. If large number of blocks have to be
mac verified then VMAC is invoked multiple
number of times until all blocks are complete.
For example- -
if n max is 4000 for the system, and the data
to be verified are 10,000 8 byte blocks,
then VMAC is invoked as follows:
NOTE: After each call of VMAC, the intermediate
ICV e*KM.C3(0CV) must he fed back to next VMAC
call as ICV input.
The decryption of this intermediate ICV must be
done internally in the CF.
VMAC n=4000,output-type=l,icv-type=0
VMAC n=4000,output-type=l,icv-type=2
VMAC n=2000,output-type=0,icv-type=2
icv-type icv-type indicates whether the ICV passed to the
function is zero, plain, or intermediate.
Intermediate ICV is~triple encrypted under the
master key with a control vector C3.
0:zero ICV (default)
l:plain ICV
2:intermediate ICV (OCV)
output-type indicates the stage of~the mac verification
process to the instruction
O : MAC Verification output
1 : Intermediate ICV output (OCV)
mac-enc mac-enc indicates a single or triple encryption
mac input.
0 : single encrypting mac input
1 : triple encrypting mac input (ANSI 9.19
: requlrement)
- MA9-8~-012
-50-
1 3224 1 8
mac-len mac-len specifies the number of bytes of the mac
to be compared. 4 left most bytes are compared
as a default.
0 : 4 left most bytes
1 : 5 left most bytes
2 : 6 left most bytes
3 : 7 left most bytes
4 : 8 bytes
NOTE: provision of 4, 5, 6, 7, 8 byte MAC
verification may subvert MAC generation process
for 8 byte MAC. We do not have any solution to
solve this problem in crypto facility, but CFAP
may consider some checking for different length
MAC verification. Further investigation is
needed for this problem.
Cl,C2,C3 64 bit control vectors for KDl, KD2, an~ OCV
respectively. C2 and C3 are optional inputs to
the instruction, C2 is required if mac-enc=l,
and C3 is required if icv-type=2 or
output-type=l.
Outputs:
yes/no mac is verified or not.
e*KM.C3~0CV) OCV is a 64 bit lntermediate ICV triple
~encrypted under KM with control vector C3. This
is an optional output valid for output-type=l.
~ . .
Description: The input data is encrypted with CBC mode of DEA
encryption using data key KDl and 32 le~t most
bits o~ the final encrypted block are compared
for equality with the supplied MAC.32 bit MAC
compare is a default value, and other ~ -
comparisons must be made as~specified by the
~mac-len parameter. CC = l is~set for macs equal
and CC=2~is set if macs are not equal. ~There
are two encryption modes: single encryption
mode, a~single key KDl is used to create the
MAC. In the triple encryption; mode, the single
encryptlon mode is employed with KDl to create a
MAC, except the MAC is then decrypted with gD2,
and reencrypted again with KDl to produce the
final 64 bit MAC.~ The MAC is generated as
~9~88~012 -51-
1 3224 1 8
specified by mac-enc input and then compared
with the supplied mac to the function.
The first ICV is zero as a standard and
optionally can be plain. Intermediate ICV must
be used if the mac'd data is greater than n
blocks in length.
If the data block is not multiples of 8 byte
blocks, padding must be done. The padding has
to be performed by the CFAP before invoking this
instruction.
Fig. 18 is a block diagram of this instruction.
cc:
1. MACs equal
2. MACs not equal
3. Cl is invalid
4. C2 or C3 is invalid
5. unsuccessful operation (error~.
Control Vector Checking:
1. Checking on C1
- cv type ~ ~"data/compatibllity" or "data/mac"
or "data/ANSI"
- MV usage bit - 1
- reserved (48:63)=X'0'
:. Checking on C2 if (mac-enc =1).
cv type = "data/compatibility" or "data/mac"
or "data/ANSI"
- MG usage bit = 1
- reserved 48:63) =X'0'.~ Checking on C3 if (icv-type~2 OR output-type =1).-
~
- CV type ~="Intermediate ICV"
. ':
Translate Cipher Text ~TCTXT) ~ i
quation: e*KM.Cl(XDl),ICVl,eXDl(ICVl,A),
e*KM~C2(K~2),ICV2, n, C1, C2
~ eKD2(ICV2,A)
,
MA9-88~012
-52-
1322~18
Inputs:
e*KM.Cl(KDl) KDl is an input data key, triple encrypted under
KM with a control vector Cl.
ICVl 64 bit clear ICV.
eKDl(ICVl,A) KD2 is an output data key, triple encrypted
under KM with a control vector C2
ICV2 64 bit clear ICV.
n Number of 8 byte blocks of data to be
translated.
Cl, C2 Control vectors for KDl, KD2 respectively.
Outputs:
eKD2(ICV2,A) outputs Data A encrypted with data key KD2 using
ICV2.
Description: Translate cipher text instruction translates
data from one data key and ICV to another data
key and ICV. This instruction operates with
data/xlt keys, and data/compatibility keys. CV
keys or CV=0 keys can be used to translate data,
no mix and match of these key types are
permitted by this instruction. The data can be
up to n 8 byte blocks, the translation is done
in the crypto facility without exposing the
clear data outside the crypt facility.
The ICV inputs ICVl and ICV2 can only be plain
ICV inputs to the instruction.~ No intermediate
ICV is provided by the instruction. If more
than n blocks o data have to be translated,~and
the data has to be chained then CFAP has to pass
:
the last 8 byte encrypted block(En) as input to
ICV. If ~ncrypted ICVs are used then CFAP must
decipher the ICVs before passing ICVs to the
instruction.
NOTE: The xlate Ciphertext instruction is
specifically designed to operate with CV-only
.
keys (i.e., xlate data keys). I~here is no
~- compatibility mode xlate ciphertext option
offered. To get around this, the xlate
- ciphertext instxuction will accept data keys
with the D and E attributes as well as the XDin
:
MA9-88-012
-53
13224t8
and XDout attributes. But this is provided as a
service to reduce the accidental exposure of
clear data, since an insider adversary could
recover data unclear using the decipher
instruction. It is not possible to isolate the
xlate ciphertext keys in the compatibility mode,
and to architect a control vector for this would
give an illusion of security, when in fact, an
attack could be perpetrated with the RTMK
instruction by importing an intended xlate key
(sent over CV=O channel) as a decipher key.
Thus, the xlate ciphertext data channel could be
subverted by deciphering data sent over that
channel.
Fig. 19 is a block diagram of this instruction.
CC:
1. successful operation
2. Cl or C2 is in~alid
3. unsuccessful operation (error)
:
-~ Control Vector Checking:
1. Checking on Cl
- cvy type ="data/xlt" or "data/compatability"
If (cv~type = "data/xlt") then XDin = 1
reserved (48:63)=X 0'
2. Checking on~C2~i (mac-enc =1).
- cv type = "data/lxt" or "data/compatability"
If (av type ="data/xlt") then XDout = 1.
reserved 48:63) =X'O
3. Checking on C~l and C2
- CV type(Cl) ="cv type (C~)
::: : ,
MDCOP (MDC OPERATION)
DESCRIPTION: ~It~is within the skill of the art to provide an
instruction which~calculates a Modification Detection Code
(MDC) as described in U.S. Patent No. 4,908,861, issued March
13, 1990, "Data Authentication Using Modiication Detection
Codes Based on a Public One-Way Encryption Function," by B. O.
Brachtl, et al., and assigned to IBM Corporation.
MA9-88-012
-54-
1 3224 1 8
ICV/OCV Management
An initial chaining value (ICV) is a 6~ bit random,
pseudorandom, or, in some cases, nonrepeating value used with
the cipher block chaining (CBC) mode of encryption of the DEA
and with some algorithms or calculating message authentication
codes (MACs).
ICV management includes options for electronic transmission and
Local storage of both plain and encrypted ICVs. However,
encrypted ICVs must first be decrypted before being used as
input parameters to any of the cryptographic functions.
An output chaining value (OCV~ i5 a 64 bit value returned,
under certain conditions, by the GENMAC and VERMAC
cryptographic instructions. The same cryptographic instruction
is again called and the OCV is passed as the ICV. The OCV is
always encrypted in the form eKM.CV(OCV), where CV is a control
vector for intermediate ICV. For the VERMAC instruction, an
encrypted OCV is absolutely essential for reasons of security.
A plain OCV, in this case, could be used to reveal MACs, which
is something that the VERMAC instruction is not supposed to
do. An encrypted OCV is also defined for the GENMAC
instruction. This is done so that the GENMAC and VERMAC
instructions are made as similar as possible, thus allowing for
possible function overlap in hardware.
ICV Manaqement Outside the Cryptographic Facility
The Communication Architecture permits the following three
modes of electronic transmission of the ICV:
1. Plain ICV: sent in the clear.
2. Encrypted ICY: encrypted with a da-ta key (KD) shared
between the sender and receiver.
3. Private Protocol: ICV established using a private
protocol between sender and receiver.
~ A
~A9-88-012
1 3224 1 8
Under the CA, CFAP must handle both plain and encrypted ICVs.
Although, applications may elect to manage their own encrypted
ICVs thus passing plain ICVs to CFAP to encrypt ICVs for
transmission and to decrypt all encrypted IDVs received from
other nodes. Optionally,the cryptographic support program may
also establish ICVs using a private protocol.
ICV Management Inside the Cryptographic Facility
Control vectors are not used for the electronic distribution of
IDVs, nor are there any bits in the control vector that may be
used by the cryptographic facility (hardware) to control ICV
distribution. There is no checking or enforcement by the
cryptographic facility of the mode of ICV distribution. Thus,
ICV management is strictly a function of the cryptographic
support program (i.e., software external to the cryptographic
facility).
All ICV's passed as cryptographic function input parameters to
the cryptographic facility must be plain ICVs. ICV = 0, which
is required by the GENMAC and VERMAC instructions, is just a
subcase of Plain ICV. The affected cryptographic instructions
are these:
-
1. Encipher
2. Decipher
3. Genmac
4. Vermac
5. Translate Cipher Text
:
.,~
~'
, . . .
`~9-88-012
~56-
1 3224 1 8
Acronyms and Abbreviations
CC Condition code
CA or CCA Cryptographic Architecture
CV Control Vector (nothing to do with ICV or OCV)
CBC Cipher Block Chaining. An encryption mode of the
Data Encryption Standard.
DED Decipher, Encipher and Decipher
DEA Data Encryption Algorithm
DES Data Encryption Standard
ECB Electronic Code Book. An encryption mode of DES.
EDE Encipher, Decipher and Encipher
ICV Input Chaining Value (Nothing to do with CV)
KDx Data Key (x = integer)
KEXx Key Encrypting Key (x = integer)
KM Master Key
KMN New master key
KM0 Old master key
KPEx Pin Encrypting Key (x = integer)
KPGx Pin Generation Key (x = integer)
KPVx Pin Validation Key (x = integer)
KKNI Immediate notarized key, 128 bits
KKNIL Left 64 bits of KKNI
KKNIR Right 64 bits of KKNI
KDmac Temporary MAC key for ANSI message
MAC Message Authentication Code
MDC Modification Detection Code
OCV Output Chaining Value
PIN Personal Identification Number (used with ATMs)
Al~orithms
Encode and Decode Algorithm
The Encode and Decode instructions use the ECB (Electronic Code
800k) mode of the DESo There is no chaining or feedback in
this mode. Fig. 20 illustrates the operati~oniof the ECB mode
of encryption and decryption.
~9-88-012
-57-
4 1 8
Cipher Algorithm
The Enciphering/Deciphering Algorithm is the National Bureau of
Standards Data Encryption Standard (DES) or equivalently the
American National 5tandards Institute Data Encryption Algorithm
(ANSI DEA) X9.92-1981. Cipher Block Chaining (CBC) is done as
specified in ANSI Cryptographic Modes of Operation X9.106-1983.
Figs. 21 and 22 show the CBC mode of operation of Encipher and
Decipher operations respectively.
Messa~e Authentication (MAC)
The Financial Institution Message Authentication Standard
(Wholesale ANSI X9.9) as referenced in References (6), defines
a process for authentication of messages from originator to
recipient. This process is independent of communication media
an and payment systems.
The authentication process includes the computation,
transmission, and verification of a Message Authentication code
(MAC). The MAS=C is based on either of the complete message
text or a selected message elements of the text. The MAC is
added to the message by the originator and is transmitted to
the recipient. The message or message elements are accepted as
authentic by the recipient if the same algorithm and secret key
produce a MAC identical to the received MAC. The security of
the authentication process is directly dependent on the
security afforded to the secret key.
-
The MAC is generated as shown in Fig. 23. The authentication
algorithm as described in this standard may be implemented
using either the 64 bit CBC or CFB modes of operation as
described in ANSI X3.106-1983. Both modes shall be initialized
so as to produce equivalent MAC~s. KEY is a 64 bit key,~and Al
thru An are 64 bit data blocks. Initial chaining value is '0'
in this standard and CBC mode of operation should be
implemented as shown in Fig. 23. If An is lelss than 64 bits,
then '0's are appended (padded) to the right of the remaining
bits. The l~ft mo9t 32 bits of (on) are taken as the MAC.
Note: The capability should exist to generate and to process
48 to 64 bit MAC's. For these cases, the left most 48 bits or
the entire final output (On) are taken as the MAC.
MA9-88-012
-58-
1322418
The algorithm de~cribes the MAC generation for binary data.
Message authentication for "Coded Character Sets" should be
implemented as described in the ANSI X9.9-1986, the MAC
algorithm is invoked ater the characters are represented in
binary data.
MDC Al~orithms
__~__
The principles of modification detection codes are
described in the abovementioned U.S. Patent No. ~,908,861.
Two MDC algorithms exist:
1. MDC_2 - Two encipherments per 8 byte input data block
2. MDC_4 - Four encipherments per 8 byte input data block
Two different algorithms allow the invoker to trade a 50%
performance improvement for a slight decrease in security
depending on his applications.
- MDC_2 (text)
1. Pad the input text with X FF to a multiple of 8
bytes.
2. Partition the input text into [nl 8 byte blocks T8[1]
to T8[n].
3. If n=1 then set n=2 and T8[2] = 8 bytes of x OO .
4. Set initial values of KD1 and KD2 (see below).
5. For [i] = 1,2,...,n:
a. MDCOP(KDllKD2,T8[i],T8~i]
b. KD1 :=OUTl
c. KD2 :-OUT2
d. end of FOR loop
6. Output of MDC_2 is the 16 byte MDC :=~KD1 // KD2).
- MDC_4 (text)
1. Pad the input text with X FF to a multiple of 8
bytes.
A
~9-88-~12
-59-
1322418 i
2. Partition the input te~t into [n] 8 byte blocks T8[1]
to T8[n]
3. If n=1 then set n=2 and T8[2] = 8 bytes of x'00'
4. Set initial values of KD1 and KD2 (see below)
5. For [i] = 1,2,...,n:
a. MDCOP(KDl,KD2,T8[i],T8[i])
b. KDlint :=OUTl
c. KD2int :=OUT2
d. MDCOP(KDlint,KD2int,KD2,KDl)
e. KDl :=OUTl
f. KD2 :-OUT2
g. end of FOR loop
6. Output of MDC_4 is the 16 byte MDC :=(KDl // KD2)
The initial values of KDl and KD2 are as follows:
1. KD1 :=X'5252525252525252'
2. KD2 :=X'2525252525252525'
Notarization Algorithms
Let KK be the key which is to be used to compute the
notarization key. Then:
KR = KK + FM1 ~+ is exclusive or operation, and FM1 is first 8
bytes of from ID)
KKL = KK + TO1 (TO1 is the first 8 bytes of to ID)
NS1 = eKKR(T02) T02 is the second 8 bytes of to ID)
NSr = eKKL(FM2) FM2 is the second 8 bytes of from ID~
NS = (left most 32 bits of NS1) //
right most 32 bits of NSr~ + CT
(CT is a 64 bit counter associated with KK)
KN = KK + NS ~ ~
KN is a notarized key used to encrypt either a KD or KK.
Let *KK be the key which is to be used to computer the
notarization key. Then:
,
-MA9-88-012
-60-
1 32241 8
*KK = KKl // KKr
KKR = KKr + FMl (+ is exclusive or operation, and
FMl is first 8 bytes of from ID)
KKL = KKl+ T01 (T01 is the first 8 bytes of to ID)
NSl - eKKR(T02)+ CT (T02 is the second 8 bytes of to ID
and CT is a 64 counter associated with
*KK)
NSr = eKKL(FM2)~CT (FM2 is the second 8 bytes of from ID)
*KN = (KKl + NSl) // (KKr + NSr)
*KN is a notarized key used to encrypt either a KD or (*)KK.
Standards and Definitions
Standards
ANSI X2.92 - 1981 "Data Encryption Al~orithm".
ANSI X9.106 1983 "Modes of DEA Operation".
ANSI X9.2 - 198X "Interchange Message Specification for Debit
and Credit Card Message Exchange Among Financial
Institutions". This standard specifies a common
interface by which bank card originated messages
relating to a financial transaction may be
interchanged between private systems~ It specifies
message structure, format and content, data elemer.ts
and values for data elements.
ANSI X9.8 - 1982 "~merican National Standard for Personal
Identification Number (PIN) Management and Security".
This standard establishes standards and guidelines
for the management and security of the Personal
Identification Number's (PIN's) life cycle.
ANSI X9.9 - 1986 "American National Standard for Financial
Institution Message_Authentication (Wholesale)".
This standard established a method to authenticate
financial messages (wholesale), including fund
transfers (e.g. wire transfers~, letters of credit,
security transfers, loan agreements and foreign
exchange contracts.
ANSI X9.17 - 1985 "Financial Institution Key Management
~Wholesale)". This standard establishes methods
(including the protocol) for the generation, exchange
.~A9-88-012
-61-
1 3224 1 8
and use of cryptographic keys of authentication and
encryption.
ANSI X9.19 - 198X "Financial Institution Retail Message
Authentication". This standard establishes a method
to authenticate financial messages for retail
transactions.
ANSI X9.23 - 198X "Encryption of Wholesale Financial Messaqes".
This standard established a method to encrypt
wholesale financial messages in order to provide
confidentiality (e.g., wire transfers, letters of
credit, etc.)
ISO DIS 8583 "Bank Card Originated Messages - Interchange
Message S~cifications - Content for Financial
Transactions". This international standard specifies
a common interface by which ~ank card originated
messages relating to a financial transaction may be
interchanged between private systems. It specifies
message structure, format and content, data elements
and values .
ISO DIS 8720 "Message Authentication"
ISO DP 8730 "Banking - Requirements for Standard Message
Authentication ~wholesale)". This international
- standard specifies a technique for protecting the
authenticity of messages passing between financial
institutions by means of a Message Authentication
Code (MAC).
ISO DP 8731 "Banking - Approved Algorithms;for Message
Authentication - Part 1 DES-1 Algorithm". This
part of ISO 8731 deals with the Data Encryption
Algorithm (DEA-l) as a method for use in~the
calculation of the Message Authentication Code (MAC).
Part-2 Other non DEA Algorithms
ISO DP 8732 "Banking - Key Management Wholesale" This
nternational standard specifies methods for the
management of keying material used for the encryption
-~ and authentication of messages exchanged in the
course of wholesale financial transactions.
ISO DP 9546 "Personal Identification Number Management and
Security_Part 1 - PIN Pr _ection Principles and
Technique" This standard specifies the minimum
security measures required for effective PIN
-
'
~A9-88-012
-62-
1 3224 1 8
management. Standard means of interchanging PIN data
are provided.
Instructions and Macros Summary Chart
Fig. 24 summarizes the equations for each of the data
instructions.
Operation of the Invention
The operation of the invention can be described as it
carries out several cryptographic data management functions.
These data management functions make use of the encipher,
decipher, generate MAC, verify MAC and translate ciphertext
instructions. Operationally, these instructions require,
besides data, key and control vector parameters, an initial
chaining value (ICV~. However, since the ICV is of secondary
importance in explaining the data management functions, as a
convenience ICVs are omitted from the discussion. However, the
reader will appreciate that the originator of ciphertext and
MACs will also be required to generate, use, and communicate
ICVs to other communicants in order that the cryptographic
instruction will operate consistently and in conformance to
their defined, architected interfaces. See for example C. H.
Meyer and S. M. Matyas, "Cryptography: A New Dimension in
Computer Data Security," John Wiley & Sons, 1982.
1. Data Confidentiality. Data confidentiality protects the
contents of a message or file from unauthorized
disclosure.
: ,
Applications of data confidentiality include the
following:
a. Session Protection. Data encryption is used to
protect the confidentiality or session;level~data
transmission between two communicating devices. Each
end user (device or application) shares a common data
encrypting/decrypting key, thus permitting each ènd
user to both send and receive encrypted data.
In accordance with the invention, as shown in Fig.
25, session protection is provided by a data/privacy
key shared between two end users. Each key is stored
MA9-88-012
-63-
1322418
in operational form, i.e., encrypted under the master
key of each respective device~ The control vector
usage attributes of each key are encipher (E) and
decipher (D), respectively, which enables each key to
be used to both encipher with an encipher instruction
and decipher data with a decipher instruction.
b. File Protection. Data encryption to protect the
confidentiality of data files. A single end user
(device or application) possesses a data
encrypting/decrypting key KD permitting data to be
encrypted for storage and to be decrypted, at a later
time, for purposes of recovery or access to the file.
In accordance with the invention, as shown in Fig.
26, file protection is provided by a data/privacy key
KD belonging to or possessed by a single end user.
The key is stored in import form, i.e., encrypted
under a key encrypting key with KEK/receiver
attribute. The encrypted data/privacy key is stored
in a data storage with the encrypted data, e.g., in a
file header record. Because the key KD is encrypted
under KEI~ in the import form, a re-encipher to master
key (RTMK) instruction is authorized by the control
vector for KEK to enable it to re-encipher the
data/privacy key KD under the master key KM. Once in
the operational form, the key KD can be used to
encipher and decipher data. Storing the key KD in
; data storage encrypted under KEK in the import form
means that the master key KM can be changed without
causing the data/privacy key KD to be invalid or
unusable for file recovery. The control vector usage
attributes of the data/privacy key KD are encipher
(E) and decipher (D). This permits a data f~le to be
both encrypted using an encipher~instruction and
decrypted using a decipher instruction with the same
key. I
: : :
c. Encrypted Mail Box. The encrypted mail box describes
a multi~user environment in which each user has a
data/privacy key in two encrypted forms, encrypted
~A9-88-012
-64-
1 3224 1 8
under a storage key formed as the exclusive-O~ of the
master key ~M and the control vector of the
associated data/privacy key. The first form permits
data encryption; the second form permits data
decryption. The first form of the key is placed in a
central directory or central registry accessible to
all users of the system. Each so registered key is
recorded under a user identifier belonying to the
user who registers the key. Each sending user i can
obtain a copy from the central directory. He then
stores the encryption key under his master key KMi.
The second form of the key is kept private by the
receiving user j to which it belongs, under j's
master key KMj. Thus, a user i who wishes to send
encrypted messages to user j, first requests user j's
encryption key from the public directory. Data
encrypted by user i using an encipher instruction
with this key is then sent to user j and placed in
user j's mail box. User j can read received mail by
decrypting first with his/her private decryption key
using a decipher instruction. But since no other
user has access to user j's decryption key, the
environment is such that users can encrypt mail going
to each other user but only the authorized designated
receiving user can decrypt and read his/her mail.
:
In accordancP with the invention, as shown in Fig.
27, an encrypted maiI box environment is provided via
a datajprivacy key which has been generated in two
forms. The first form permits encipher (E) only and
the second form permits decipher (~) (not necessarily
decipher only, since possession of both encipher and
decipher attributes by the recipient would suffice).
The control vector usage attributes for the ~irst
form of the data/privacy key are encipher (E) only
and for the second form of the kéy are decipher (D)
only ~or both E and D~
d. Ciphertext Translation Center (CTC). The ciphertext
translation center is a network node or device
capable of securely translating encrypted data from
encryption under a first data key to encryption under
~A9~88-012
-65-
1 3224 1 8
a second data key with a translate ciphertext
instruction. In effect, the CTC possesses one or
more data keys under which encrypted data may be
received and one or more data keys under which
received encrypted data may be re encrypted. These
data keys thus establish a secure channel permitting
the CTC to translate ciphertext from one key to
another but not to decrypt ciphertext. The CTC may
be further restricted from encrypting data with one
or more of these data/privacy keys for the purpose of
introducing data into the secure channel.
In accordance with the invention, as shown in Fig.
28, a ciphertext translation center is provided via a
data/xlate key used in combination with a
data/privacy key. Consider a network of n devices
connected to a single ciphertext translation center
(CTC). Each device generates a data key in two
encrypted forms. The first form is a data/privacy
key stored in operational form, where the storage key
is the master key KM exclusive-ORed with the control
vector of the data/privacy key. The control vector
for this key has encipher ~Ej and decipher ~D)
attributes for bidirectional communication. The
second form is a data/xlate key in~export form,
suitable for export to the CTC where the storage key
is a key encrypting key KEK which is exclusive-ORed
with the control vector of the data/xlate key. At
the CTC, the received dataixlate kéy is imported
using the RTMK instruction, whlch converts the
received data/xlate key to an operational form. The
control vector for this key has Xlate-in and
Xlate-out attributes for bidirectional communication.
Thus, data enciphered~at device "ii' can be translated
with a translate ciphertext instruction at the CTC to
encipherment under a key known to any one of the
other devlces. But~the~CTC cannot idecrypt received
inbound encrypted~data nor encrypt data in a form
comparable to the outbound encrypted data, since the
contxol vector associated with the data/xlate key has
no usage attributes permitting the encipher or
decipher instructions to be executed.
'
MA9-88-012
~ -66-
1322~fl8
In order to provide only unidirectional ciphertext
translation from system A to system B, the respective
control vectors establish that the first form of the
first data key is a data/privacy key with an encipher
only usage attribute; the second form of the Eirst
data key is a data/xlate key with an xlate-in usage
attribute; the first form of the second data key is a
data/privacy key with~a decipher only (or encipher
and decipher) usage attribute; and the second form of
the second data key is a data/xlate key with an
xlate-out usage attribute.
e. Peer-to-Peer Ciphertext Translation. As is shown in
Fig. 29, this environment consists of a chain of two
or more CTCs which establish a secure channel from
one set of network devices to another set of network
devices. Fig. 29 is a example of unidirectional
peer-to-peer ciphertext translation. The first CTC
in the chain possesses one or more data keys under
which encrypted data may be received from the first
set of network devices. Each CTC in the chain
possesses one or more data keys under which encrypted
data may be re-encrypted, but not decrypted. The
CTCs may be further restricted from encrypting data
with one or more of these keys for the purpose of
introducing data into the secure channeI. The last
CTC in the chain re-encrypts the encrypted data under
one or more data keys shared with members of the
second set of network devices.
~:
In accordance with the invention, a ciphertext
translation center is provided via a data/xlate key
used in combination with either a data/privacy key or
another data/xlate key. Consider a node i o~ a
network A of devices connecte~ to a node j of a
network B of devices via a chain of k CTCs, labeled
in order CTCl/ CTC2,...,CTCk. Nodei i-generates a
data key in two forms. The first form is a
data/privacy key in operational form~ The control
vector for this key has an E attribute. The second
form is a data/xlate key in export form, suitable for
export to CTC1, the first CTC in the chain. At CTC1,
A9-88-012
-6~-
1 3224 1 8
the received data/xlate key is imported using the
RTMK instruction, which converts the received
data/xlate key to an operational form. The control
vector for this key has an xlate~in attribute.
Node j generates a key in the same two forms: an
operational data/privacy key and exportable
data/xlate key. The control vector of j's
data/privacy key has a decipher attribute. The
data/xlate key is shipped to CTCk, the last CTC in
the chain. At CTCk, the received data/xlate key is
imported to operational form via RTMK. The control
vector for this key has an xlate-out attribute.
Each CTC in the chain (except CTCk) generates a
data/xlate key in two forms: operational and
exportable. The operational data/xlate key has a
control vector with an xlate-out attribute. The
exportable form is shipped to the next CTC in the
chain, i.e. CTCx ships to CTC(x+l) for x equals 1 to
(k-l). The receiving CTC imports the received
data/xlate key and converts it to operational form
via the RTMK instruction. The control vector for the
data/xlate key has an xlate-in attribute.
Alternately, a third party node can generate and ship
a data/xIate key and its associated control vector in
t~o forms for nodes x and x+l, an xlate-out for node
x and an xlate-in for node x+l.
Thus, data enciphered at node i of network A with the
encipher instruction, can be translated and
re-transIated along the chain of CTCs from CTCl to
CTCk with a translate ciphertext instruction~and
finally to node j of network B. But none of the CTCs
in the chain can decrypt received inbound data nor
encrypt arbitrary data in a form co~parable to the
outbound encrypted data. ~Thus, the chain of CTCs and
the above-defined keys form a secure chann~l
permitting the CTCs, as a group to translate data
enciphered under one key held by node i to
_~9-88~012
-6~-
1322418
encipherment under another key held by node j.
Although Fig. 29 shows a unidirectional peer-to-peer
communication, the control vectors can be modified to
allow bidirectional communication.
f. Translate Part of an Encrypted File. This is an
application wherein part of an encrypted file can be
translated to a key which can be conveniently shared
with an intended receiver. The method avoids sharing
the original data/privacy key used to encrypt the
file, since doing so may jeopardize the
confidentiality of data not intended to be shared.
In order for a user or application program to
beneficially use this feature, it is necessary for
the user to generate a data key in two encrypted
forms. The first form of the data key is a data
privacy key stored in operational form, i.e.,
encrypted under a storage key formed as the
exclusive-OR operation of the master key and a first
control vector associated with the first form of the
data key. The second form of the data key is a data
- xlate key stored in import form., i.e., encrypted
~ under a storage key formed as the exclusive-OR
i operation of a key encrypting key KEK1 and a second
control vector associated with the second form of the
data key, where the control vector of KEKl defines
KEK1 as; an lmport key encrypting key. (Note: ~
defining KEKl as an import key encrypting key permits
the so encrypted data xlate key encrypted under KEKl
to be re-enciphered, at any later time, from
encipherment under KEK1 to encipherment under the
master key via a re-encipher to master key (RTMK)
instruction.~ The control vector for the first form
of the data key is a data/privacy control vector with
usage attri~ute encipher ~E), thus allowing data to
be enciphered under the data key~viia an encipher
instruction. The control vector for the second form
of the data key is a data/xlate control vector with
usage attribute xlate in (Xin), thus allowing data
enciphered under the data key to be translated from
encipherment under the data key to encipherment under
some other data key via a translate ciphertext
instruction.
--`~9-88-012
-69-
1 3224 1 8
In practice, as shown in Fig. 30 the data file is
first encrypted with the data key Kl via an encipher
instruction using the first form of the data key,
i.e., the operational form of the key whose control
vector is a data/privacy control vector with usage
attribute encipher (E). The second form of the data
key stored in import form is written in a header
record of the encrypted data file. Thus, at any
later time when it is desired to translate part of
the encrypted data file from encryption under the
present data key (called the first data key) to
encryption under a second data key, the following
procedure is followed. The second form of the first
data key stored in import form and written in the
header record of the encrypted data file is accessed
and i5 re-enciphered from encryption under KEKl to
encryption under the master key by using an RTMK
instruction. This converts the second form of the
data key (i.e., the data/xlate with xin usage
attribute) to an operational key which is now
suitable for use in translate ciphertext instruction.
A second data key K2 is now generated in two
encrypted forms. The first encrypted form of the key
is a data/xlate key stored in operational form, i.e.,
encrypted under a storage key formed as the
exclusive-OR operation of the master key and the
control vector associated with the data/xlate key.
The second encrypted form of the key is a
data/privacy key stored in export form, i.e.,
encrypted under a key encrypting key XEK2 shared with
the intended receiver. (It is assumed that the
intended receiver can import the so-generated
data/privacy key via a re-encipher to master~key
(RTMK) instruction, thus causing the data/privacy key
to be stored encrypted under a storage key formed as
the exclusive-OR operation of the miaster key of the
supporting device and the control vector associated
with the data/privacy key.) The control vector usage
attributes for the first form of the second data key
(i.e., for the data/xlate key) are xlate out (Xout)
:
~A9-88-012
-70-
1322~18
and for the second form of the second data key (i.e.,
for the data/privacy key) are decipher (D) only (or
decipher and encipher). Now a portion of the
encrypted data file is re-enciphered from encryption
under the first data key to encryption under the
second data key via a translate ciphertext
instruction, using second encrypted form of the first
data key which has been re-enciphered from import
form to operational form (whose control vector
designates the key as a data/xlate key with Xin usage
attribute) and the first encrypted form of the second
data key already in operational form (whose control
vector designates the key as a data/xlate key with
Xout usage attribute). The so-translated ciphertext
is then sent from system i to the intended receiver
system j, whereupon the encrypted data is decrypted
via a decipher instruction, using the second form of
the second data key (whose control vector designates
the key as a data/privacy key with a D usage
attribute)~
As is seen by the example part A' of the encrypted
file A can be given to another user j without
requiring the data to be decrypted in clear form at
the device of the fixst user i and~without requiring
the first user i to- share the data key Kl~under which
the entire file A is encrypted.
2. Data Integrity. Data integrity protects the contents of a
message or file from unauthorized modificationO This
includes changes, additions, and deletions to the data.
Cryptography provides only methods for detecting
unauthorized changes to data. It cannot prevent
unauthorized changes to data. .
: :
a. Message Integrity. Each end user (device or
application program) ln a multi user environment
- shares a common data M~C generationtverification key,
thus permitting each end user to generate MACs
(message authentication codes) on messages
transmitted to any other end user and permitting each
end user to verify MACs on messages received from
other end users.
M~9-88-01~
-71-
1 3224 1 8
In accordance with the invention, as shown in Fig.
31, message integrity is provided by a dataJMAC key
shared between two end users. Each key is stored in
operational form, i.e., encrypted under a storage key
formed as the exclusive-OR operation of the master
key o~ the device serving each respective end user
and the control vector associated with the data/MAC
key. The control vector usage attributes of each key
are MAC generation (MG) and MAC verification (MV),
respectively, which permits each user's key to be
used for both MAC generation and MAC verification.
Thus, the integrity of messages communicated between
the respective end users can be assured. Thus, for
example, the first end user generates a MAC on a
message to be sent to the second end user via a
generate MAC instruction, using his copy of the
data/MAC key. The message and MAC are then
communicated to the second end user. The second end
user verifies the MAC via a verify MAC instruction,
using his copy of the data/MAC key. Since the
control vectors for each copy of the key have usage
attributes MG and MV, each user can generate and
verify MACs with the key, and messages and MACs can
be communicated from the first user to the second
user or the second user to the first user.
Message Integrity with Non-Repudiation. Each end
user ~device or application program) in a multi-user
environment~has a dataiMAC key in two encrypted
forms, i.e., encrypted under a storage key formed as
the exclusive-OR operation of the respective device
master key and the respective control vector
associated with the data/MA~ key. The first form
permits MAC verification; the second form pe~mits MAC
generation. The first form of the key is placed in a
public directory or central registry~accessible to
all users of the system. Each so riegistered key is
recorded under a user identifier belonging to the
user who registers the key. The second form of the
key is kept private by the user to which it belongs~
Thus, a user j who wishes to send a message and MAC
to user i, generates a MAC on the desired message via
~A9-88-012
-72-
1322418 - -
a GENMAC instruction using the private MAC generation
key belonging to user j. The message and MAC are
then communicated to user i. To verify the received
message and MAC, user i first requests user j's MAC
verification key from the public directory. (Note:
if the public directory is located at a device
different from the device supporting user i, then it
is necessary to export and import the desired key
using an RFMK and an RTMK instruction. This causes
the MAC verification key to be re-enciphered under a
key encrypting key shared between the two devices,
via an RFMK instruction, for purposes of exporting
the key and then to be re-enciphered under the master
key at the device supporting user i via an RTMK
instruction.) User i then verifies the received
message and MAC via a verify MAC instruction using
j's MAC verification key. But since no other user
has access to user j's M~C generation key, the
environment is such that users can verify MACs and
messages received from any other user (say user v)
but cannot generate MACs on messages using any other
user's MAC generation key. Thus one user cannot pose
as another user and generate MACs with another user's
MAC generation key. Conversely, a user tsay user j)
cannot deny or repudiate a valid message and MAC as
having originated with that user if the message and
MAC is successfully verified with that user's MAC
verification key via the verify MAC instruction.
This is callPd non-repudiation.
In accordance with the invention, as shown in Fig.
32, message integrity with non-repudiation is
provided via a data/MAC key which has been generated
in two encrypted forms. The first form perm ts MAC
verification only and the second form permits MAC
generation (no~ necessarily MAC generation only,
since possession of both MAC genera'tion and MAC
verification would suffice). The control vector
usage attributes for the first form of the data/MAC
key are M~C verification tMv) only and for the second
form of the key are~MAC generation (MG) only (or both
MG and MV).
MA9-88-012
-73-
1322418
3. Message Authentication. Message authentication is a
procedure established between two communicants which
allows each communicant to verify that received messages
are genuine. Communicants can be people, devices, or
processing functions. Message authentication allows the
receiver of a message to determine that:
a. The message originated with the alleged sender.
b. The contents of the message have not been
accidentally or intentionally changed.
c. The message has been received in the same sequence
that it was transmitted.
d. The message was delivered to the intended receiver.
As can be seen, message authentication encompasses a
requirement for message integrity, but is a broader
concept. Message authentication, as defined here, permits
the receiver to additionally validate a message's origin,
timeliness or sequence, and intended destination. To
accomplish these additional features, a sender identifier
field, a receiver identifier field, and a sequence number
field are included in each message, as shown in Fig. 33.
Thus, upon receipt of a message and ~AC, the contents of
the message are first authenticated via the MAC using a
verify MAC instruction and a MAC verification key shared
between the two users (i.e., which has been previously
established via the key management processes). Once the
contents of the message have been authenticated, a simple
check is performed to verify that the sender identifier is
equal to the identifier of the MAC verification key
belonging to the anticipated or intended sender o~ the
message, that the value in the sequence number field is
one greater than the sequence number in the previously
received message from that same sender,land that the
receiver identifier is equal to the identifier of the
actual receiver. If all checking is passed successfully,
the received message is accepted as valid; otherwise the
message is rejected. Message authentication and message
authentication with non-repudiation are achieved in the
` ~A9-88-012
-74-
1322418
same way the data integrity and data integrity with
non-repudiation are achieved (see the applications
described under items 2a and 2b, respectively), except
that additional fields are defined and checked in the
message as just outlined.
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 24 in Fig. 1 of the crypto
facility 4 or alternately they can be stored in the working key
registers of the crypto facility as in shown in Fig. 2.
In a first me~hod, each key and its associated control
vector are stored as a paired expression in the RAM within the
crypto facility. Each such key and control vector are
initialized within the crypto facility, in advance of their
intended use, via a special authorized procedure available only
to authorized system personnel (e.g., a security officer). A
procedure similar to initializing a master key (e.g., via a
hand-held key entry device attached to a front panel interfacé,
which is enabled via a physical key-activated key switch) could
easily be adapted for initializing keys and control vectors
within the crypto facility. Methods for initializing
parameters within the crypto facility are well-known in the
art. 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 authorization is affirmative,
then the corresponding key is accessed from the RAM and is used
for the intended operations within the crypto facility.
In a second method, the exclusive-OR product of the key
and its associated control vector are stored in the RAM inside
the crypto facility, i.e., instead of store the key and`control
vector paired expression (as with thé first method) the key and
control vector are exclusi~e-ORed and the product of the
exclusive-OR operation is stored in the RAM inside the crypto
facility. A procedure for initializing the crypto facility
could be based on performing the exclusive-OR operation of the
key and control vector outside the crypto facility and then
entering their product as a parameter using a procedure similar
to that for entering the key and control vector, as described
,
MA9-88-012
-75-
1322418
for the Eirst method. Alternatively, the key and control
vector could be e~clusive-ORed within the crypto facility and
the product then stored as before. Later on, the steps to
access a key can be traced as follows. An instruction which
designates the use of a particular key must also provide the
control vector associated with that key as a parameter of the
instruction. The control vector is first checked, as before,
using the control vector checking operation, in order to ensure
that the proposed key usage is authorized. If the
authorization is affirmative, the exclusive-OR product of the
key and control vector stored in the crypto facility is
accessed and exclusive-ORed with the control vector supplied as
a parameter to the instruction to recover the clear key which
is then used in the intended cryptographic operations. It can
be seen that if cheating is attempted, i.e., a false control
vector is specified in an instruction, then the clear value of
the recovered key is not correct (i.e., is not the correct key
value). The crypto instructions are designed such that no
useful outputs are obtained when an incorrect key value is
produced as a result of such control vector cheating.
Although specific embodiments of the invention have been
disclosed, it will be understood by those having skill ln the
art that changes can be made to these specific embodiments
without departing from the spirit and the scope of the
invention.
:
