Data cryptography operations using control vectors4918728Abstract 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, 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 invention. 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. Claims What is claimed is: Description DESCRIPTION
__________________________________________________________________________
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 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:
I1, I2, I3, I4, . . . --- 01, 02, 03, . . .
where I1, 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 data cryptography to be coexist with non-ANSI X9.17 data cryptography 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. 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 cryptograhic key separation. An explanation of the separation is given below: 1. A. Data Keys: KEKs 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. Subsequently, data that would be encrypted under this PIN block used as a data key 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 justification for the separation are given below. 1. A--Authentication: Privacy An insider who can collect plain and corresponding ciphertext encrypted with a MAC key can perpetrate an attack against the MAC 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 KD1 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 existing 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 Compatibility keys exist due 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 which support such an improved level of separation. 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 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 single 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 enable 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 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. 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 advantages 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. 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 keys 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. 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 integrity of the data keys stored in the Data Key Dataset (a key storage 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 whether the key is allowed to be exported. CF 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, 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 represents control vector bits that are controlled/managed entirely by CFAP; The software field is not checked/enforced by the hardware (CF). When no 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 check 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 key 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. 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, 1b 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 Key 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/CUSP or IBM 4700 FCS. Since these existing systems do not have the eryptographic 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.e., substituted by CV=0 on-the-link) when it is exported to other systems (via the RFMK instructions), 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 is the key used in the translation of ciphertext. ANSI Key. 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 MAC/verify MAC capability). This control vector can be removed when exported to other systems (i.e., substituted by CV=0 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 RFMK, RTMK and LCVA instruction 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. 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=0: This key cannot be used in the ENCIPHER 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. AV (Anti-Variant) This field occupies two bits, used to differentiate the control vector from 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 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 of each field and subfield of this figure. CV Type CV TYPE for MAC key (main type=:DATA KEY", sub type="MAC"). Export Control (controls exporting of this key) Same description as that of Privacy keys. Usage (a) MG MG=1: 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=1: 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 Version-Same description (b) Software-Enforced Usage See also the CFAP section CVDML4 (Control Vector Data MACLEN=4) CVDM99 (Control Vector Data MAC MODE=ANSI.times.9.9) CVDM19 (Control Vector Data MAC MODE=ANSI.times.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 Data Compatibility Keys Refer to FIG. 8. The following is a detailed description of each field and subfield of this figure. CV Type CV TYPE=for data compatibility key (main type="DATA KEY", sub type="COMPATIBILITY" Export Control Same description as that of Privacy keys. Usage (a) E E=1: This key can be used in the ENCIPHER instruction 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 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=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 description as that of Privacy keys. (b) Software-Enforced Usage 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 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 KEY", 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. 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=1: This key can be used in the ENCIPHER instruction 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 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-1: This key can be used in the VMAC instruction to verify MAC on data. MV=0: This key cannot be used in the VMAC instruction to verify MAC on data. (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 ACOMBKD instruction, as will be described in section "ANSI Combine KDs (ACOMBKD)." The resulting key is used to verify and generate MACs for the messages communicated via the ANSI.times.9.17 protocol. ACMB=1: This data key can be combined in the ACMB instruction. ACMB=0: This data key cannot be combined in the ACMB 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 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="Intermediate ICV", subtype=Not applicable) 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. 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 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.C1(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 nodes except in the case of a hot backup. Thus, normally, this field assumes the value B`00` for an ICV control vector. 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. 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. This checking is crucial to security.) The instruction set equations 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 operations is always a multiple of 8 bytes. There are two fundamental ways in which CV checking can be done. 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 Vector: 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 following reasons: 1. Instruction does not have to know what bits to set 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 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.
______________________________________
Encode (ENC)
______________________________________
Equation
KD, A -- eKD(A)
Inputs:
KD 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 instruction. FIG. 13 is a block diagram of this instruction.
______________________________________
CC:
1. successful operation
2. unsuccessful operation (error)
NOTE: Unsuccessful operation can be any hardware error
specific to a given implementation. The condition
codes (CC described here merely 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 implementation, the numbering
used here is for a convenient description of crypto
architecture.
Control Vector Checking: None.
Decode (DEC)
Equation: KD, eKD(A) -- A
Inputs:
KD 64 bit clear key
eKD(A) 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. successful operation
2. unsuccessful operation (error)
Control Vector Checking: None
Encipher (ENCI)
Equation: e*KM.C1(KD1), ICV, A, n,
C1 --- eKD1(ICV,A)
Inputs:
e*KM.C1(KD1)
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 output (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.
A Data to be encrypted, in multiples of
8 byte blocks. The 8 byte blocks are
A1, A2, . . . An. If the last block An 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
(OCV) has to be fed back as ICV input
to the next Encipher call.
c1 64 bit control vector for data key (KD1).
Outputs:
ekD1(ICV,A encrypted data, n blocks, each block
is 8 bytes (E1, E2 . . . En).
______________________________________
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. The 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 program. 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 =
1
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)
Equation:
e*KM.C1(KD1), ICV, eKD1(ICV,A), n, C1 -- A
Inputs:
e*KM.C1(Kd1)
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.
eKd1(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.
Note: 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
Decipher n = 4000
Decipher n = 2000
C1 64 bit control vector for data key (KD1).
Outputs:
A Plain data, in a multiples of 8 byte
blocks. The 8 byte blocks are A1,
A2, . . . An.
______________________________________
Description: The input data is decrypted via the CBC mode of DEA encryption. The multiples of 8 byte blocks are decrypted by this instruction until all n blocks are decrypted. The architecture defines only plain ICV input to the 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. All 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. C1 is invalid
3. unsuccessful operation (error)
Control Vector Checking
1. Checking on C1
cv type =
"data/compatibility" or
"data/privacy" or
"data/ANSI"
D usage bit =
1
reserved (48:63) =
X`0`
GENMAC (GMAC)
Equation:
e*KM.C1(KD2=1),[e*KM.C2(KD2)],
ICV[e*KM.C3(OCV)],
A, n, icv-type,output-type, mac-enc, C1,[C2],[C3]
MAC (64 bit)
or
e*KM.C3(OCV)
Inputs:
e*KM.C1(KD1)
KD1 is a MAC generation key for single
encrypting MAC, triple encrypted under KM
with a control vector C1.
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 com-
patible 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/OCV
Management" and "Software Interface."
e*KM.C3(OCV)
This is a 64 bit intermediate ICV encrypted
under the master key with a special 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 use only.
A Data to be MAC'd, in multiples of 8 byte blocks
(A1, A2 . . . An).
n number of 8 byte blocks 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 for 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=1,icv-type=0
GMAC n=4000,output-type=1,icv-type=2
GMAC n=2000,output-type=1,icv-type=2
Note: After each call of GMAC, the
intermediate ICV e*KM.C3(OCV) must be
fed back to next GMAC
call as ICV input. The decryption of this
intermediate ICV must be done internally in the
CF
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. Zero ICV
is a default value.
0: zero ICV (default)
1: plain ICV
2: intermediate ICV (OCV)
output-type
indicates the stage of the mac generation
process to the instruction.
0: MAC output
1: Intermediate ICV output (OCV)
mac-enc mac-enc indicates a single or triple encryption
mac output
0: single encrypting mac output
1: triple encrypting mac output(ANSI 9.19
requirement)
C1,C2,C3 64 bit control vectors for KD1, KD2, and OCV
respectively. C2 and C3 are optional inputs to
the instruction, C2 must be input if mac-enc=1,
and C3 must be input if icv-type = 2 or
output-type=1.
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(OCV)
OCV is a 64 bit intermediate ICV triple
encrypted under KM with control vector C3.
This output is valid only if output-type=1.
MAC output and Intermediate 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 KD1 is used to create the MAC. In the triple encryption mode, the single encryption mode is employed with KD1 to create a MAC, except the MAC is then decrypted with KD2, and reencrypted again with KD1 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 MAC 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 GMAC instruction. The ANSI X9.9 MAC standard 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 done. The padding has to 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. C1 is invalid
3. C2 or C3 is invalid
4. unsuccessful operation (error).
Control Vector Checking:
1. Checking on C1
CV type = "data/compatibility" or "data/mac"
or "data/ANSI"
MG usage bit = 1
reserved (48:63)=X`0`
2. 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`
3. Checking on C3 if (icv-type=2 OR output-type = 1).
CV type = "Intermediate ICV"
Verify MAC (VMAC)
Equation:
e*KM.C1(KD1), [e*KM.C2(KD2)]
ICV[e*KM.C3(OCV)],
A,MAC, n, icv-type,output-type,mac-enc,mac-len, C1, [C2],[C3]
yes/no
OR
e*KM.C3(OCV)
Inputs:
e*KM.C1(KD1)
KD1 is a mac verification key for single
encrypting mac, triple encrypted under KM
with a control vector C1.
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=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 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/OCV Management"
and "Software Interface."
e*KM.C3(OCV)
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 master 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 multiples of 8 byte blocks
(A1,A2 . . . An).
MAC 64 bit MAC input to the instruction either
single or triple encrypted. By default, only
left most 32 bits of this MAC are used for MAC
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(OCV) must
be 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=1,icv-type=0
VMAC n=4000,output-type=1,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)
1: plain ICV
2: intermediate ICV (OCV)
output-type
indicates the stage of the mac verification
process to the instruction
0: 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
requirement)
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.
C1,C2,C3 64 bit control vectors for KD1, KD2, and OCV
respectively. C2 and C3 are optional inputs to
the instruction, C2 is required if mac-enc=1,
and C3 is required if icv-type=2 or
output-type=1.
Outputs:
yes/no mac is verified or not.
e*KM.C3(OCV)
OCV is a 64 bit intermediate ICV triple
encrypted under KM with control vector C3.
This is an optional output valid for
output-type=1.
Description:
The input data is encrypted with CBC
mode of DEA encryption using data key
KD1 and 32 left most
bits of 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 = 1 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 KD1 is used to create the
MAC. In the triple encryption mode, the single
encryption mode is employed with KD1
to create a MAC, except the MAC is
then decrypted with KD2,
and reencrypted again with KD1 to produce the
final 64 bit MAC. The MAC is generated as
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. C1 is invalid
4. C2 or C3 is invalid
5. unsuccessful operation (error).
Control Vector Checking:
1. Checking on C1
cv type = "data/compatibility" or "data/mac"
or "data/ANSI"
MV usage bit = 1
reserved (48:63)=X`0`
2. 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`
3. Checking on C3 if (icv-type=2 OR output-type=1).
CV type = "Intermediate ICV"
Translate Cipher Text (TCTXT)
Equation: e*KM.C1(KD1),ICV1,eKD1(ICV1,A),
e*KM.C2(KD2),ICV2, n, C1, C2
eKD2(ICV2,A)
Inputs:
e*KM.C1(KD1)
KD1 is an input data key, triple encrypted
under KM with a control vector C1.
ICV1 64 bit clear ICV.
eKD1(ICV1,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.
C1, C2 Control vectors for KD1, 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 ICV1 and ICV2 can only
be plain - ICV inputs to the instruction.
No intermediate
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 copending patent application entitled "Data Authentication Using Modification Detection Codes Based on a Public One-Way Encryption Function," by B. O. Brachtl, et al., Ser. No. 90,633, filed Aug. 23, 1987, and assigned to IBM Corporation, and incorporated herein by reference. ICV/OCV Management An initial chaining value (ICV) is a 64 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 for 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) is 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 Management 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 ICV: encrypted with a data key (KD) shared between the sender and receiver. 3. Private Protocol: ICV established using a private protocol between sender and receiver. 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 ICVs 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 t | ||||||