Appendix A of SDN.701 MOSAIC Algorithms 1.0 Overview The purpose of this appendix is to specify the conventions for use of the MSP specification with the MOSAIC suite of cryptographic algorithms. This appendix describes the approaches for data encryption, hash, signature generation and validation, and token processing. 2.0 Data Encryption When message confidentiality is selected as a service, the encapsulated content is encrypted as a single string. This string is padded to a multiple of 8 octets and encrypted as a single string. Encryption is performed using the SKIPJACK algorithm in CBC mode. The IV for this encryption is placed in the parameters field of the mosaicConfidentialityAlgorithm algorithm identifier. Padding shall be performed as follows. The input to the SKIPJACK CBC encryption process shall be padded to a multiple of 8 octets. Let n be the length in octets of the input. Pad the input by appending 8-(n mod 8) octets to the end of the message, each having the value 8-(n mod 8), the number of octets being added. In hexadecimal, the possible paddings are: 01, 0202, 030303, 04040404, 0505050505, 060606060606, 07070707070707, and 0808080808080808. All input is padded with 1 to 8 octets to produce a multiple of 8 octets in length. The padding can be removed unambiguously after decryption. 3.0 Signatures Signatures are generated by calculating a hash over the data to be signed and then calculating a signature based on the resulting hash value. The hash used throughout this processing shall be the NIST Secure Hash Algorithm and the signature algorithm shall be the NIST Digital Signature Algorithm. The signature value specified in the DSA consists of the values R and S. Mosaic signature values used in MSP and in certificates (either a BIT STRING or an OCTET STRING) will carry R and S encoded as SEQUENCE (INTEGER, INTEGER) in the order R, S. 3.1 Generation A message signature is generated by calculating a hash on the encapsulated content, and the signature control information. This hash is then input to the signature algorithm with the result placed in the signature value field in the signature block. The hash is calculated by first generating a complete hash over the encapsulated content. This hash, the msgHash, is placed in the token. A second hash value is calculated over the concatenation of the msgHash and ControlInformation (SignatureInformation choice) (i.e., a hash calculated over the 160 bit msgHash prepended to ControlInformation). This second hash is used as the input to the signature algorithm. 3.2 Validation A message signature is validated by calculating a hash based on the encapsulated content, and the signature information. This hash is calculated in the same manner as specified in section 3.1 and is used along with the received signature value as input to the DSA signature validation process which determines the validity of the signature. 3.3 Receipt Generation A receipt is generated by calculating a hash based on the encapsulated content, signature information from the message being receipted, and the receipt information field. A hash based on the encapsulated content, and signature control information from the message being receipted is calculated according to section 3.1. A hash is then calculated based on the concatenation of this signature hash and the ControlInformation (ReceiptInformation choice). This resulting hash is then input to the signature algorithm with the result placed in the signature value field in the signature block. 3.4 Receipt Validation A receipt is validated by calculating the hash based on the encapsulated content, and signature information from the message being receipted, and the receipt information field. This hash is calculated in the same manner as specified in section 3.3 and is used along with the received signature value as input to the DSA signature validation process which determines the validity of the signature. 3.5 Hash Extension In many cases it is necessary to calculate a hash over different collections of input involving common elements (e.g. the msg hash in the token is calculated over the encapsulated content while the input to the signature value is calculated over the encapsulated content and the signature information). The SHA used here specifies appending the length of the signed data at the end of the data being hashed. In order to generate complete hashes over a sequence of objects, a hash is calculated over the first object, and the resulting 160 bit hash is then prepended to the second object for subsequent hash calculations. This approach is reflected in the descriptions in sections 3.1 and 3.3 and in the following diagram. Figure 1 - Hash Calculation Figure 1 shows the relationship between the respective hashes calculated for tokens, message signatures, and signed receipts. All hash values are complete SHA hashes including the length input. Each successive hash in the diagram is calculated over the concatenation of the 160 bit preceding hash and the ASN.1 encoded additional data. 4.0 Tokens Per-recipient tokens are generated for each recipient of a MSP with MOSAIC message. The contents of the token are specified in the MSP specification. 4.1 Token Protection Individual recipient key tokens are protected for each recipient of a message. The token is protected using a token protection key generated by means of the key exchange algorithm. This token protection key is generated using the KEA material of the originator and the recipient along with the originator UKM for this message and the value 01 (see section 4.3). Note: For the generation of the token protection key to be successful, the parameters, g p and q, for the KEA material of the originator and the recipient must be the same. The KMID from the recipient's KEA material is used in the tag for this token. The Edition field of the tag is set to 0 and the date field is omitted. The token protection key is first used to protect the message key. The message key is protected using the Tessera/Capstone wrapping function. This function will take the 80 bit message key along with a 16 bit checkvalue and produce a 96 bit result using the token protection key. The result of this wrapping operation is the protected message key. The protected message key, the msgHash, signatureBlockIndicator, additionalSecurityInfoIndicator, encapsulatedContentType, and securityLabel are the contents of the RecipientKeyToken. The RecipientKeyToken is padded to a multiple of 8 octets using the pad algorithm specified in section 2.0. An ICV is calculated over the RecipientKeyToken and pad. The ICV is 64 bits. The first 32 bits are a 1's complement addition of each 32 bit block of the RecipientKeyToken and pad. The last 32 bits are all 0's. As an example of the ICV algorithm, for a RecipientKeyToken (note this sample token is random data) C517680FA7C01FDA8362342C (hex); it would first be padded to C517680FA7C01FDA8362342C04040404. The ICV would be F43DC01A00000000. The RecipientKeyToken, pad, and ICV are then concatenated and encrypted with the token protection key, using the SKIPJACK algorithm in CBC mode, forming a protected token. An IV is generated for each protected token and is prepended to the protected token forming a ProtectedRecipientKeyToken. 4.2 Key Generation The message key for each message is generated locally. This key shall not be used for any other purpose. 4.3 UKMs An originator UKM is generated by the originator MSPUA for each message. This UKM is placed in the originator UKM field and is used to form each token protection key. A token protection key is formed for each recipient using the KEA with these inputs: originator's private key, the recipient's public key, the originator UKM, and the value 01. The recipient obtains the token protection key using the KEA with these inputs: recipient's private key, the originator's public key, the originator UKM, and the value 01. An originator UKM is a 1024 bit random number generated by the originator. The value 01 is also represented as a 1024 bit quantity. 4.4 ML Key Tokens Not applicable. 4.5 ML Key Generation Not applicable. 4.6 TU Key Tokens Not applicable. 5.0 Travelling Users Not applicable. 6.0 Additional Security Info If present, the ASI is independently encrypted using the message key from the RecipientKeyToken. The ASI is padded to a multiple of 8 octets using the pad algorithm specified in section 2.0 and is encrypted using the SKIPJACK algorithm in CBC mode. The asiIntegrityCheckValue is calculated over the lrbac field in the ASI. The algorithm used for the asiIntegrityCheckValue is the same algorithm specified for the token ICV in section 4.1. The IV for the ASI encryption is placed in the parameters field of the asiProtectionAlgorithm algorithm identifier. This IV must be different from the IV used for the encryption of the encapsulated content. 7.0 Algorithm IDs id-mosaicSignatureAlgorithm DSA with SHA id-mosaicConfidentialityAlgorithm SKIPJACK in CBC mode id-mosaicIntegrityAlgorithm SHA id-mosaicTokenProtectionAlgorithm (see section 4.1) id-mosaicKeyManagementAlgorithm KEA id-mosaicKMandSigAlgorithms KEA and DSA with SHA The id-mosaicKMandSigAlgorithms value is used in X.509 certificates to indicate that both the KEA and DSA keys are present. This value may be used in either the case where two bitstrings are present or the case where the same key is used for both algorithms. The DSA and KEA algorithms have optional parameters associated with them. The same parameters may be used for both algorithms. For Mosaic and MSP, the algorithm parameters are expected to be carried in the algorithm identifier in the subject public key info field of the X.509 certificate. If absent, the parameters of the certificate's issuer apply. The following structures are used to convey parameters required for the operation of cryptographic algorithms. These structures are the individual Type definitions that are included, along with the appropriate Object Identifier, within the AlgorithmIdentifier structure. Dss-Parms ::= SEQUENCE { p OCTET STRING, q OCTET STRING, g OCTET STRING } Kea-Parms ::= SEQUENCE { p OCTET STRING, q OCTET STRING, g OCTET STRING } Kea-Dss-Parms ::= CHOICE { [0] Different-Parms [1] Common-Parms } Different-Parms ::= SEQUENCE { Kea-Parms, Dss-Parms } Common-Parms ::= SEQUENCE { p OCTET STRING, q OCTET STRING, g OCTET STRING } Skipjack-Parm ::= SEQUENCE { initialization_vector OCTET STRING } The following table lists the assignment of cryptographic algorithms, assigned Object Identifiers, and Parameters to Object Identifier value names for each mosiac algorithm. Symbolic Object Identifier Algorithm Assigned Object Identifier Parameters id-mosaicSignatureAlgorithm DSA with SHA 2 16 840 1 101 2 1 1 2 Dss-Parms id-mosaicConfidentialityAlgorithm SKIPJACK in CBC mode 2 16 840 1 101 2 1 1 4 Skipjack-Parm id-mosaicIntegrityAlgorithm SHA 2 16 840 1 101 2 1 1 6 absent id-mosaicTokenProtectionAlgorithm see section 4.1 of PMSP Algorithms Appendix 2 16 840 1 101 2 1 1 8 absent id-mosaicKeyManagementAlgorithm KEA 2 16 840 1 101 2 1 1 10 Kea-Parms id-mosaicKMandSigAlgorithms KEA and DSA with SHA 2 16 840 1 101 2 1 1 12 Kea-Dss-Parms 8.0 Certificate Formats The Subject Public Key field of the X.509 certificates may contain the MOSAIC signature material, key management material, or both elements of MOSAIC keying material. The format and conventions for carrying MOSAIC information in X.509 certificates are contained in the MOSAIC Key Management Concept Document. 1994-03-23 Page A- MOSAIC MSP APPENDIX FOR OFFICIAL USE ONLY MOSAIC MSP APPENDIX FOR OFFICIAL USE ONLY MOSAIC MSP APPENDIX FOR OFFICIAL USE ONLY FOR OFFICIAL USE ONLY - FOR OFFICIAL USE ONLY