Personal identification number processing using control vectors4924514Abstract Cryptographic PIN processing is achieved in an improved manner by associating control vectors with the PIN generating (verification) keys and PIN encrypting keys which provide authorization for the uses of the keys intended by the originator of the keys. The originator may be the local cryptographic facility (CF) and a utility program under the control of a security administrator, or the originator may be another network node which uses the key management methods described in the above-referenced copending patent applications to distribute said keys. Among the uses specified by the control vector are limitations on the authority to use the associated key with certain PIN processing instructions, such as PIN generation, verification, translation and PIN block creation. Furthermore, the control vector may limit the authority of certain instructions to process clear PIN inputs (such as in PIN verification). The control vector may contain information identifying and, possibly restricting, PIN processing to a particular PIN format or particular processing algorithm. The control vector implementation provides a flexible method for coupling format, usage, and processing authorization to keys. The system administrator can exercise flexibility in changing the implementation of his security policy by selecting appropriate control vectors in accordance with the invention. Furthermore, a method is provided for the security administrator to restrict certain PIN format translations. Claims What is claimed is: Description BACKGROUND OF THE INVENTION
______________________________________
Notation - The following 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
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
(*)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 concantentation 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, 02, 03,...
where Il, I2, I3,... are the inputs to the
function and 01, 02, 03,... are the outputs
from the function.
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(dKMX(eKMY(key)))
where, KMY = KML XOR Cx
KMX = KMR XOR Cx
key = 64 bit key
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, KEKR = 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 = KEKL 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 compatibility-mode key types will not diminish the security, certain rules governing generation, distribution, and usage of these two classes of key types 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). (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 security of other data keys. (e) Data ANSI. Allows ANSI X9.17 key management to be coexist with non-ANSI X9.17 key management without loss of security to either approach. (f) Key Encrypting Keys. KEK Sender from KEK Receiver. (g) PIN Keys. PIN Generating Key from PIN Encrypting key. Pin Keys Separation The justifications for the separation are given below: 1. A--PIN Generating Keys: PIN Encrypting Keys An insider who could cause a PIN block to be forced equal to a valid ID value and then encrypted under a PIN generating key instead of a PIN encrypting key, could expose PINs. 2. B--Generate PIN function: Encipher PIN function During PIN generation, the Encipher PIN attribute allows separation of PIN Generating keys that allow clear PINs to be generated from those that always must output encrypted PINs. 3. C--Create PIN Block & Generate PIN: Reformat PIN, Verify PIN & Xlate PIN Permits the PIN encrypting key to be used with routine PIN processing functions like Reformat PIN, Verify PIN and Xlate PIN without allowing PIN keys to be used or create or otherwise "introduce" PINs into the network at electronic speeds. This would prevent dictionaries of plain and encrypted PINs to be collected at electronic speeds, which would be useful in attacking and recovering PINs without directly deciphering them. Tight control needs to be enforced over where and when and under what conditions PINs may be introduced into the system. 4. D--Create PIN Block: Generate PIN Greater control can be exercised over the introduction of PINs into the network. A node with a requirement to create PIN blocks need not necessarily have a right or need to generate PINs. 5. E--Reformat PIN and Verify PIN: Xlate PIN Greater control can be exercised over the PIN processing functions in the network. A node with a need and right to translate PINs does not necessarily have a right or need to reformat a PIN or verify a PIN. The later two functions might be used in combination to exhaust PINs via an internal attack, whereas the Xlate PIN function could be used by some nodes without giving away full processing capabilities. 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 exported or not. The control vector is coupled cryptographically to the key via a special encryption function. For example, when the K is stored in a Key Storage, K is encrypted under a key formed 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 KEK is a key shared between the sender and receiver. Thus, K is transmitted as the tuple (eKEK.C(K), C). The architecture 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 signal bit change in the control vector will cause an entirely different key to be recovered.) 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". Thus, each usage attribute is defined independently from all other usage attributes. This guarantees 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 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 follows 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 checking. 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: 1. Vertical Separation. The control vector has a "CV Type" 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 key management. However, vertical separation is implemented only where necessary under the CA, thus ensuring architectural simplicity and of ease of comprehension of the CV checking rules. 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 effectively 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 field 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 Keys. 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 GKS) from a non-system generated key. 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.) 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 (once 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 result in an internal key of odd parity. This, in turn, ensures compatibility with hardware that may check such internally derived keys for odd parity (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 63. 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 implementations 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 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. Control Vector Format for PIN Keys PIN keys are divided into the following subtypes: (a) PIN-encrypting keys (PEKs) These are the keys that are used to encrypt PINs. (b) PIN-generating keys (PGKs) These are the keys that are used to generate PINs. In some cases, the PGKs are also called PIN validating keys since they are used to validate/verify PINs. Control Vector for PIN-Encrypting Keys Refer to FIG. 6. The following is a detailed description of each field and subfield of this figure. CV TYPE CV TYPE=B`0010000` for PIN-encrypting key (PEK) (maintype="PIN key"=B`0010`, subtype="PIN-encrypting key"=B`000`) EXPORT CONTROL--This field occupies 1 bit: EXPORT CONTROL=1: This key can be exported by RFMK. Also, the RFMK, RTMK and LCVA instructions can reset this bit to 0. EXPORT CONTROL=0: This key cannot be exported by RFMK. Also, it cannot be changed to 1 by any instruction. USAGE (a) CREATE PINBLK CREATE PINBLK=1: This key is allowed to encipher the PIN Block in the CREATE PIN BLOCK instruction. CREATE PINPBL=0: This key is not allowed to encipher the PIN Block in the CREATE PIN BLOCK instruction. (b) GENPIN GENPIN=1: This key is allowed to encrypt the input customer PIN (CPIN) in the GENERATE PIN instruction. (c) VERPIN VERPIN=1: This key is allowed to decrypt the encrypted PIN input to the VERIFY PIN instruction. VERPIN=0: This key is not allowed to decrypt the encrypted 1/2 IN input to the VERIFY PIN instruction. (d) XPIN in XPIN in=1: This key is allowed to decrypt the encrypted input PIN in the TRANSLATE PIN instruction. XPIN in=0: This key is not allowed to decrypt the encrypted input PIN in the TRANSLATE PIN instruction. (e) XPIN out=1: This key is allowed to encrypt the output PIN in the TRANSLATE PIN instruction. XPIN out=0: This key is not allowed to encrypt the output PIN in the TRANSLATE PIN instruction. 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, 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 None. 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. To facilitate the ease of future uses for this field, the hardware must check to make sure that the last 16 bits of this field are all zero. Other bits of this field may not be checked. Of the reserved bits, one byte (including parity) is specifically reserved for the future expansion of the CV TYPE field. PARITY This field consists of the last bit of every byte of the control vector. Every parity bit is the even parity of the preceding 7 bits of the byte. Control Vector for PIN-Generating Keys Refer to FIG. 7. The following is a detailed description of each field and subfield of this figure. CV TYPE CV TYPE=B`0010000` for PIN-generating key (maintype="PIN key"=B`0010`, subtype="PIN-generating key"=B`001`) EXPORT CONTROL EXPORT CONTROL=1: This key can be exported by RFMK. Also, the RFMK, RTMK and LCVA instructions can reset this bit to 0. EXPORT CONTROL=0: This key cannot be exported by RFMK. Also, it cannot be changed to 1 by any instruction. USAGE (a) GENPIN This field occupies 2 bits, indicating the conditions under which the key is allowed to generate PINs or PIN Offsets in the GENERATE PIN instruction. GENPIN=B`00`: not allowed to generate PINs or PIN offsets. GENPIN=B`01`: allowed to generate a clear PIN or clear PIN offset. GENPIN=B`10`: allowed to generate an encrypted PIN or encrypted PIN offset. GENPIN=B`11`: allowed to generate a clear or encrypted PIN, or a clear or encrypted PIN offset. (b) GPIN This bit indicates whether the customer selected PIN (CPIN) can be input to the GENPIN instruction in the form of a clear PIN or an encrypted PIN. GPIN=0: Clear or encrypted PIN is allowed. GPIN=1: Only encrypted PIN is allowed (c) VERPIN This bit indicates whether the key can be used as a PIN-validating key to verify PINs in the VERIFY PIN instruction. VERPIN=1: Allowed to be used to verify PINs. VERPIN=0: Not allowed to be used to verify PINs. (d) VPIN This bit indicates whether the PIN to be verified in the VERIFY PIN instruction can be input to the instruction in the form of a clear PIN or an encrypted PIN. VPIN=0: Clear or encrypted PIN is allowed. VPIN=1: Only encrypted PIN is allowed. AV (Anti-Variant) Same description as that of PIN-encrypting keys. SOFTWARE bits This field occupies 12 bits. (a) CV VERSION Same description as that of PIN-encrypting keys. (b) Software-Enforced Usage None. EXTENSION Same description as that of PIN-encrypting keys. RESERVED bits Same description as that of PIN-encrypting keys. PARITY bits Same description as that of PIN-encrypting keys. Pin Processing Instructions The PIN processing instructions are described in detail in the following sections. These instructions must be implemented within the cryptographic facility. Create Pin Block (CPINB)
______________________________________
Equation:
e*KM.C1(KPE),PIN,format-out,
pad-in,seq-in,pan,a-pin-len,C1
--eKPE(PIN BLOCK)
Inputs:
e*KM.C1(KPE)
KPE is the 64 bit PIN encrypting key triple
encrypted under KM with a control vector C1 and
used to encrypt the input PIN.
PIN 1 to 16 decimal digits in clear.
format-out 4 bit code indicating the PIN format to be used
for the pin block.
0000: IBM 3624 format
0001: IBM 3621 format
0010: ANSI format
0011: 4704 format (encrypting key pad)
0100: Docutel, Diebold, NCR
0101: Burroughs
0110: ISO format
0111: not used
lXXX: not used
pad-in This is a pad-in character, a 4 bit value from
X'0]to X]F], to be used to format a PIN
according to the PIN format. The pad character
and the number of padding characters depend upon
the type of format.
seq-in A two byte Sequence number. If the PIN format
requires only a one byte sequence number, then
the least significant byte of seq-in will be
used. Seq-in may or may not be required
depending upon the format.
pan Twelve 4-bit digits representing the "rightmost"
least significant 12 digits of the primary
account number. Pan may or may not be required
depending upon the format.
a-pin-len Cl is the control vector for the input pin
encrypting key.
Outputs:
eKPE(PIN BLOCK The formatted PIN Block encrypted under the
pin encrypting key KPE.
______________________________________
Description: The Create PIN Block function is used to encrypt a clear PIN using input PIN encrypting key at ATMs or any other PIN input devices. The clear PIN is 1-16 decimal character input to the function, the PIN is formatted using the given format-out type and encrypted with KPE key. Now this formatted PIN can be sent to a verification node or any other intermediate node securely. CC: 1. successful operation 2. Cl is in invalid 3. Unsuccessful operation (error). Control Vector Checking: 1. Checking on Cl cv type="PIN KEY/PEK" Create PINBLK usage bit=1 reserved=X`0` Generate IBM 3624 PIN (GPIN)
______________________________________
Equation:
e*KM.C1(KPG,[e*KM.C2(KD)]
e*KM.C3(KPE),out-mode,eKPE(CPIN,[CPIN]
dec-tab,val-data,a-pin-len,pad,cpin-mode,c1,[C2],C3
--PIN (Out-mode=0)
--eKD(PIN) (Out-mode=1)
--Offset (Out-mode=2)
--eKD(Offset)
(Out-mode=3)
Inputs:
e*KM.Cl(KPG)
KPG is the 64 bit Pin generating key, triple
encrypted under KM with a control vector C1.
e*KM.C2(KD)
KD is the 64 bit data key, triple encrypted
under KM with a control vector C2 and used to
encrypt the generated PIN or the generated
Offset. This optional parameter must be
provided for out-mode =1 or out-mode =3.
e*KM.C3(KPE)
KPE is the 64 bit Pin encrypting key, triple
encrypted under KM with a control vector C3 and
used to encrypt the customer PIN.
out-mode Output mode indicates the form of output
required.
0: Clear PIN output
1: eKD(PIN)
2: Offset
3: eKD(Offset)
eKPE(CPIN) CPIN is a 64 bit (16 decimal coded digits),
customer selected PIN. Used to generate the
Offset, this is an encrypted form of the
customer selected PIN under the PIN encrypting
key. The default is encrypted customer selected
PIN to this function. (CPIN is a formatted PIN
in IBM 3624 format.)
CPIN CPIN is a 64 bit (16 decimal coded digits),
customer selected PIN in clear form. This
optional input must be provided if cpin-mode = 0
is specified to the function. The clear
customer PIN will be only permitted if the PIN
generating key permits clear PINs to the
function. The clear customer PINs are permitted
by the CCA to be compatible with the existing
system requirements.
dec-tab Decimalization TABLE is a 64 bit plain input
which represents 16 decimal digits to be used in
the PIN generation process.
val-data Validation data is a 64 bit plain user's data,
padding included. Ordinarily it will be the
user's PAN.
a-pin-len a-pin-len is a 4 bit number (1-16) indicating
how many digits of the generated PIN are
assigned to the customer, and represents the
number of digits in the intermediate PIN.
pad This is a pad character, a 4 bit value from X'A'
to X'F', to be used to format a PIN according to
IBM 3624 PIN format. There could be 0-15 pad
characters (16 - number of pin characters = pad
characters).
cpin-mode cpin-mode specifies whether a clear customer PIN
or encrypted customer PIN is passed to the
function. The control vector checking is
enforced on the pin generating key to insure the
security of using encrypted pins from the clear
pins.
0: clear CPIN
1: encrypted CPIN
C1,C2,C3 C1, C2 and C3 are the control vectors for KPG,
KD and KPE respectively. C2 is an optional
control vector which must be supplied if the
output-type specified is either 1 or 3.
Outputs:
PIN: This is a 64 bit IBM 3624 formatted PIN output
in the clear. Padding and formatting is done
internal to the hardware.
eKD(PIN) eKD(PIN) is the 64 bit formatted PIN encrypted under
data key KD. Decipher data instruction can be used
to decipher the PIN in some other node for PIN
mailing purposes. (A secure PC can be used to
decrypt these encrypted PINs and print for mailing).
No decryption of PINs are allowed in the generating
node.
Offset Offset is a 64 bit data, representing 1-16
decimal digits, used by the PIN verification
process if the PIN was user selected. The
offset data reflects the difference between the
PIN that is selected by the customer (denoted
CPIN) and the PIN that is generated by the
verification (denoted PIN).
______________________________________
Description: The GPIN instruction generates an IBM 3624 formatted PIN from the validation data and a PIN generating key. Alternatively, the GPIN instruction can accept a customers selected PIN to generate the Offset; the customer selected PIN can be in the clear or encrypted form. The PIN output can be in clear or in encrypted form. The output PIN is always formatted using the supplied padding character. The clear output can be used for printing a clear PIN distributed via a PIN mailer. The encrypted PIN or offset is provided to support decrypting capability at the PIN mailer stations. A secure PC can be used to decrypt PINs and Offset and print on the customer card. The Offset outputs is in clear or encrypted form. The Offset is written on the customer's card, in addition to the other information. The Offset is generated by substracting intermediate PIN (length=assigned PIN length) from CPIN (length=16). The padding in the CPIN is preserved and propagated to Offset. NOTE: The PIN generating keys and PIN verification keys refer to the same key. The different names are often used pending upon the usage of the key in the function. CC: 1. successful operation 2. C1 or C2 or C3 is invalid 3. invalid pad character 4. invalid customer pin 5. invalid decimalization table 6. unsuccessful operation (error). Control Vector Checking: 1. cv type="PIN KEY/PGK" If out-mode=0 or 2 then GENPIN=`01` or `11` If out-mode=1 or 3 then GENPIN=`10` or `11` If cpin-mode=0 then EPIN=0 reserved=X'0' 2. Checking on C2 if (out-mode=1 or 3) CV type="data/compatibility" or "data/privacy" E usage bit=1 D usage bit=0 3. Checking on C3 if cpin-mode=1. cv type="PIN KEY/PEK" GEN PIN usage bit=1 Verify IBM 3624 PIN (VPIN)
______________________________________
Equation:
e*KM.C1(KPV), e*KM.C2(KPE), eKPE(PIN) [PIN]
dec-tab,val-data,a-in-len,p-chk-len,offset,pin-mode,C1,C2
-- PIN OK or PIN NOT OK
Inputs:
e*KM.C1(KPV)
KPV is the 64 bit PIN validation key, triple
encrypted under KM with a control vector C1.
PIN generating key (KPG) and the PIN validation
key (KPV) have to be one and the same keys to
verify the PIN. The key names KPV and KPG are
used for the notation only.
e*KM.C2(KPE)
KPE is the 64 bit PIN encrypting key, triple
encrypted under KM with a control ector C2.
eKPE(PIN) eKPE(PIN) is the 64 bit formatted PIN encrypted
under PIN input protection key. Create PIN
block is used to encrypt the formatted PIN. PIN
is a 64 bit formatted PIN in IBM 3624 format.
This s a standard input to the verify pin
function.
PIN PIN is a 64 bit (16 decimal coded digits), input
PIN in clear form. This optional input must be
provided if pin-mode = 0 is specified to the
function. The clear input PIN will be only
permitted if the IN verification key permits
clear PINs to the function. The clear input
PINs are permitted by the CCA to be compatible
with the existing system requirements.
dec-tab decimalization table is a 64 bit plain input
which represents 16 decimal digits to be used in
the PIN verification process.
val-data valid data is a 64 bit users data, padding
included. Ordinarily it will be the user's PAN.
a-pin-len a-pin-len is the number (1-16) indicating how
many digits of the generated PIN is assigned to
the customer; this is the number of digits of
the intermediate PIN.
p-chk-len p-chk-len is the number (1-16) indicating how
many digits of the PIN assigned to the customer
are checked in the verification process. These
digits are selected from right to left from the
Intermediate pin and customer entered PIN.
offset offset is a 64 bit data, representing 1-16
decimal digits, used by the PIN verification
process if the PIN was user selected. The
offset data reflects the difference between the
PIN that is selected by the customer and the
intermediate PIN that is generated by the
validation procedure.
pin-mode pin-mode indicates the PIN entered is in clear
or encrypted.
0: clear
1: encrypted
C1,C2 C1 and C2 are the control vectors for KPV and
KPE
Outputs: PIN-OK or PIN-NOT-OK
______________________________________
Description: The VPIN instruction generates an IBM 3624 formatted PIN from the validation data and a PIN validation key and compares it with the customer entered PIN. The customer entered PIN is an IBM 3624 formatted PIN which can be in clear or encrypted form. The pin-mode indicates whether the entered PIN is in the clear or encrypted under a PIN encrypting key. Clear PIN input will only be permitted if the PIN verification key is allowed to use clear PIN inputs. The Offset input is in clear. The entered PIN and the Offset are added (MOD 10) using only the left most digits equal to the length of A-pin-len. This result is compared with the intermediate PIN using only the right most digits equal to the length of P-chk-len. The output of this function is YES/NO on the compare of the PINs as illustrated above. CC: 1. successful operation 2. C1 or C2 is invalid 3. invalid entered PIN 4. invalid decimalization table 5. unsuccessful operation (error). Control Vector Checking: 1. Checking on C1 cv type="PIN KEY/PGK" VERPIN usage bit=1 If pin-mode=1 then EPIN=1 reserved=X`0` 2. Checking on C2 if pin-mode=1 cv type="PIN KEY/PEK" VERPIN usage bit=1 reserved=X`0` PIN Translate (PINT)
______________________________________
Equation:
e*KM.C1(KPE1),[e*KM.C2(KPE2)],eKPE1(PIN),format-in,format-out,
pad-in,pad-out,seq-in,seq-out,pan,kp2-mode,C1,C2
-- eKPE2(PIN .sub.-- Block) or
eKPE3(PIN .sub.-- Block), e*KM.C2(KPE3)
Inputs:
e*KM.C1(KPEl)
KPE1 is the 64 bit PIN encrypting key, triple
encrypted under KM with a control vector C1 and
used to encrypt the formatted PIN inputs.
e*KM.C2(KPE2)
KPE2 is an optional 64 bit PIN encrypting key,
triple encrypted under KM with a control vector
C2, used to encrypt the translated PIN for
output. KPE2 may or may not be equal to KPE1.
If KPE2 is not supplied, a randomly generated
KPE3 will be used to encrypt the translated PIN.
eKPE1(PIN) This is a 64 bit encrypted formatted 1/2IN under
KPE1 key.
format-in This is a 64 bit encrypted formatted PIN under
KPE1 key.
format-in This is a 64 bit encrypted formatted PIN under
KPE1 key.
0000: IBM 3624 format
0001: IBM 3621 format
0010: ANSI format
0011: 4704 format (encrypting key pad)
0100: Docutel, Diebold, NCR
0101: Burroughs
0110: ISO format
0111: not used
1XXX: not used
format-out 4 bit code indicating the PIN format output.
0000: IBM 3624 format
0001: IBM 3621 format
0010: ANSI format
0011: 4704 format (encrypting key pad)
0100: Docutel, Diebold, NCR
0101: Burroughs
0110: ISO format
0111: not used
1XXX: not used
pad-in This is a pad-in character, a 4 bit value from
X'0' to X'F', to be used to format a PIN
according to the PIN format. The pad character
and the number of padding characters depend upon
the type of format input.
pad-out This is a pad-out character, a 4 bit value from
X'0' to X'F', to be used to format a PIN
according to the PIN format. The pad character
and the number of padding characters depend upon
the type of format output.
seq-in A two byte Sequence number. If the input PIN
format requires only a one byte sequence number,
then the least significant byte of seq-in will
be used. Seq-in may or may not be required
depending upon the format-in.
seq-out A two byte Sequence number. If the output PIN
format requires only a one byte sequence number,
then the least significant byte of seq-out will
be used. Seq-out may or may not be required
depending upon the format-out.
pan Twelve 4-bit digits representing the "rightmost"
(least significant) 12 digits of the primary
account number. Pan may or may not be required
depending upon the format (Check digits not
included.)
kp2-mode kp2-mode indicates whether a key encrypting key
is supplied or has to be randomly generated
securely. When KPE2 is supplied, it is supplied
in encrypted form e*KM.C2(KPE2), so that the key
is not exposed in clear outside the crypto
facility.
0: KPE2 supplied
1: KPE3 has to be generated randomly
When KPE3 is generated randomly, it has to be
generated in the crypto facility and implies
that any reformat combination is allowed. When
KPE2 is supplied, certain translation
combinations must be disallowed based on an
implementation dependent, secure mapping table.
See Note under Description below.
C1,C2 C1 and C2 are the control vectors for KPE1, KPE2
respectively. KPE2 is supplied or output
depending on kp2-mode equal to '0' or '1'. C2
is always supplied to the function.
Outputs:
eKPE2(PIN .sub.-- Block)
e(KPE2(PIN .sub.-- Block) is the 64 bit translated PIN
encyrpted under PIN encrypting key KPE2; the PIN
is translated according to the output format
specification.
eKPE3(PIN .sub.-- Block),
eKPE3(PIN) .sub.-- Block) is the 64
e*KM.C2(KPE3)
bit translated PIN encrypted under PIN
encrypting key KPE3; the PIN is translated
according to the output format specification.
e*KM.C2(KPE3) is a randomly generated triple
encrypted key, KPE3, under KM with a control
vector C2.
______________________________________
Description: The PIN translate (PINT) function is used to translate the PIN from one PIN block format to another PIN block format without the PIN appearing in clear outside the cryptographic facility. The PIN is securely translated from one pin encrypting key to the other pin encrypting key. The PIN Block formats are described in FIG. 8. The PIN encrypting keys KPE1, KPE2 could be the same or different. If they are the same then the input parameters e*KM.C1(KPE1) and e*KM.C2(Kpe2) are euqal and C1=C2. NOTE: Certain reformatting combinations (as selected by format-in and format-out) may weaken the security of an encrypted PIN. If an opponent were permitted to generate all formats of encrypted PINs under a fixed output key, a dictionary attack could be waged. For this reason, the permissible combinations must be restricted whenever KPE2 is specified on input. A suggested method is to define an 8*8 mapping table of bit entries, indexed by format-in and format-out. The bit entry for a specified reformat combination is set to `1` if the combination is permitted, otherwise it is zero. This table must be stored/accessed with integrity (e.g. within the CF). One method to load this table with integrity is via a handheld keypad attached to the CF through a secure front-panel interface. The keypad is enabled by a front-panel keyswitch. The physical key may be held by trusted security personnel. The CF may include one or more instructions, such as LOAD.sub.-- XLATE.sub.-- AUTHORITY.sub.-- TABLE, which verify that the physical keyswitch is in the enable position and then transfer the contents of the keypad buffer into the internal table storage locations. If the keyswitch is not in the proper position, the instruction aborts with an appropriate error code. An alternative to the physical keyswitch would be to require the security personnel to enter a secret password. The instruction would then cryptographically verify the password before updating the internal table. The new table contents need not come from an external device, such as the keypad. Although less secure, an application program could pass this table to the CF through programming interfaces. Again, however, the transfer should be enabled via a physical keyswitch or personnel-entered password. The method chosen to load the authorization table is up to the implementor. The goal is to provide a means to securely load the table into the CF, thereby preventing substitution or modification by unauthorized personnel. The table is referenced by PINT whenever an explicit KPE2 is supplied as an input parameter. On the other hand, if KPE2 is not specified, KPE3 is randomly generated and thus cannot be used to reformat PINs under a fixed key. The reformatted, encrypted output PIN is essentially cryptographically separate from the input PIN. For that reason, no combination restrictions are required if KPE3 is randomly generated. In either case, the output PIN may be used as input to the PIN verification function or sent to another node. CC: 1. successful operation 2. C1 or C2 is invalid 3. invalid format 4. unsuccessful operation (error) Control Vector Checking: 1. Checking on C1 cv type="PIN KEY/PEK" PIN XLT IN usage bet=1 reserved=X`0` 2. Checking on C2 cv type="PIN KEY/PEK" PIN XLT OUT usage bet=1 reserved=X`0` STANDARDS AND DEFINITIONS Standards ANSI X2.92--1981 "Data Encryption Algorithm". ANSI X9.106--1983 "Modes of DEA Operation". ANSI X9.2--198X "Interchange Message Specificatin 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 sysstems. It specifies message structure, format and content, data elements and values for data elements. ANSI X9.8--1982 "American 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 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 Messages". 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 Specifications--Content for Financial Transactions". This international 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 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-1) 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 international 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 Protection Principles and Technique" This standard specifies the minimum security measures required for effective PIN management. Standard means of interchanging PIN data are provided. 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. In a first method, 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 interface, 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 storing the key and control vector paired expression (as with the first method) and key and control vector are exclusive-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 for the first method. Alternatively, the key and control vector could be exclusive-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. In the second method, the preferred form for storing the key K is to use the exclusive-OR as the combining function, F, between the key and its control vector C, forming a product, and the inverse combining function, F.sup.-1, is the exclusive-OR of the product with the control vector. However, there may be particular applications where other combining functions, F, and their inverses, F.sup.-1, are more appropriate. For example, applications requiring greater security can define F as an encrypting transformation, for example where the key K is encrypted under its control vector C forming eC(K), and the inverse transformation is a decrypting function, for example where eC(K) is decrypted under C. Although specific embodiments of the invention have been disclosed, it will be understood by those having skill in the art that changes can be made to these specific embodiments without departing from the spirit and the scope of the invention.
|
Same subclass Same class Consider this |
||||||||||