Purpose

The purpose is to provide the implementation and testing team with:

• Input/output values for core cryptographic functions as well as intermediate values
• Python scripts outlining the mathematical steps involved in each cryptographic function along with pertinent inline documentation

The input/output values along with the Python scripts will serve in ensuring the correct implementation of the cryptographic algorithms, which are typically prone to erroneous implementation.

Test Vectors Location

Test vectors are located at http://stash.campllc.org/projects/SCMS/repos/crypto-test-vectors/ .

Overview

The following is the README in that Stash repository:

Hash-based Functions

Key Derivation Function, KDF2

• This function is used to expand/derive keys from shared secret and specified input parameters. The derived keys may be used in symmetric-key encryption and/or authentication.
• Based on SHA-256
• Implemented as per IEEE-1363a and ANSI X9.63
• Required in the implementation of ECIES

Message Authentication Code, MAC1 (HMAC)

• This is a symmetric-key authentication function, i.e., it takes as input an authentication key and the data to be authenticated and outputs an authentication tag that is appended to the data and ensures its integrity and authenticity
• Based on SHA-256
• Implemented as per IEEE-1363a, ANSI X9.71, RFC 2104 and 4231
• Required in the implementation of ECIES

AES-based Functions

AES-CCM Authenticated Encryption

• This is a symmetric-key authenticated encryption function, i.e., it takes as input a symmetric key and a plaintext and outputs a cipher text and an authentication tag. It provides confidentiality, integrity and authenticity of the data.
• Based on AES-128
• Implemented as per IEEE-1609.2 and NIST SP 800-38C
• Used in all data encryption. The symmetric key used is then wrapped with ECIES and sent along with the encrypted data.

ECC Functions

ECDH Key Agreement

• Elliptic Curve Diffie-Hellman is a public-key primitive where two parties can compute a shared secret by exchanging public keys and employing them and the corresponding private keys in the computation
• Based on ECC over the curve P-256
• Implemented as per NIST SP800-56A Section 5.7.1.2
• Required in the implementation of ECIES

ECIES Public-key Encryption

• Elliptic Curve Integrated Encryption Scheme is a hybrid encryption primitive composed of public-key key agreement (ECDH), a key derivation function (KDF2) and symmetric-key encryption (XOR) and authentication (MAC1). A Sender employs this scheme to encrypt a message using the public-key of the Recipient.
• The primitives in the brackets above are as per IEEE-1609.2
• Used to wrap (encrypt) AES-CCM-128 encryption keys

Implicit Certificate Generation and Public/Private Keys Reconstruction

• Implicit certificates are employed for pseudonym certificates, enrollment certificates, etc. (see Certificate Types)
  They do not contain the subject's public key and are not signed by the issuer, as is the case with explicit certificates, rather they contain a public key reconstruction point that is used to reconstruct the public key of the subject knowing the public key of the issuer. When issued, a private key reconstruction value is sent along from the issuer to the subject and only the subject can reconstruct the actual private key using this value and the private key used in the certificate request. In the case of pseudonym certificates, for example, the subject is the EE and the issuer is the PCA.
• Based on ECC over the curve P-256
• H(CertU) in the script is provided as an illustrative value. See IEEE 1609.2-2016, Sec. 6.4.8, under ENCODING CONSIDERATIONS: "for implicit certificates, the value H(CertU) in SEC 4, section 3, is for purposes of this standard taken to be H (H (canonicalized ToBeSignedCertificate from the subordinate certificate) || H(entirety of issuer Certificate) ). See 5.3.2 for further discussion" See the cited section for details.
• Notes:
  
  • CertU is a term in SEC4 standard which only deals with implicit certs and public/private keys reconstruction. It is used in the Python scripts that generate the test vectors with comments that ensure that it's understood to be only for illustrative purpose:
  • 
    
    • tbsdata was arbitrary
  • 
    
    • CertU = Hash (tbsdata || pub key recon point), just to emphasize that however the input to the hash is formulated, it should contain at least the tbs data and the public key reconstruction point for mathematical and cryptographic correctness and assurance of the algorithm
      
    • In 1609.2-2016, Sec 6.4.5 and 6.4.8, the public key reconstruction point is the verifyKeyIndicator and is already part of ToBeSignedCertificate, which already satisfies the cryptographic requirement in the previous item. In addition to that, there is another input, the issuer cert; as explained in Sec 6.4.8, the hash is calculated as:  H (H (canonicalized ToBeSignedCertificate from the subordinate certificate) || H(entirety of issuer Certificate) )
    • The hash in 1609.2 is calculated the same way for implicit and explicit certs as in Sec 5.3.1 and Sec. 6.4.8 
      
      
  • The operations in SEC4 that would require using the 1609.2-2016 hashing algorithm are conveniently listed in 1609.2-2016 Sec 5.3.2:
    

    5.3.2 Implicit Certificates

    Implicit certificates were proposed in Brown, Gallant, and Vanstone [B3] and Pintsov and Vanstone [B18] while modifications to protect against attacks were proposed in Brown, Campagna, and Vanstone [B4]. In this standard, implicit certificates are processed as specified in Standards for Efficient Cryptography (SEC) 4 except for the exceptions noted in this subclause.

    a) In this standard, an implicit certificate is encoded as an ImplicitCertificate, as defined in 6.4.5, and is encoded with the Canonical Octet Encoding Rules (COER). All references to “the certificate CertU” in SEC 4 should be taken as referring to the encoded ImplicitCertificate except when the implicit certificate is hashed to an integer modulus n. This case is addressed in item b) below.

    b) When an implicit certificate is hashed to an integer modulo n, the input is not simply the implicit certificate CertU but the information specified below. This affects the following steps in SEC 4:
    1) Section 3.4, Action 7
    2) Section 3.5, Action 4
    3) Section 3.6, Action 2
    4) Section 3.7, Action 4
    5) Section 3.8, Action 4

    The encoded data input to the hash function is Hash (ToBeSignedCertificate from the subordinate certificate as specified in 6.4.8) || Hash (Entirety of issuer certificate as specified in 6.4.3).

Linkage Values and Butterfly Key Expansion Functions

• These are as specified in Special Cryptographic Primitives in SCMS

1602.2 and SCMS ASN.1 Objects

scms-protocol.asn:

SCMS-Protocol ASN.1

1609.2-schema.asn:

IEEE 1609.2 Schema ASN.1

See ECIES diagram and Notes on Encrypted Data below, as well as PKRecipientInfo and EciesP256EncryptedKey ASN.1 objects in 1609dot2-schema.asn and EciesP256EncryptedKey in 1609dot2-base-types.asn, to see how the outputs of ECIES are encoded in the RecipientInfo.

SignedData ASN.1

Example of SignedData from scms-protocol.asn:

SignedData Example ASN.1

ECIES Encryption as in 1609.2-2016, Sec 5.3.5

ECIES Encryption

Inputs:
P1: see below
R: recipient's public key
k: AES-CCM symmetric key to be encrypted with ECIES

Outputs:
V: Sender's ephemeral public key
C: Cipher text (encrypted symmetric key k)
T: Tag

Notes:

• KDF is KDF2 [in IEEE 1363a, Section 13.2]:
  KDF2(Z, P1) = Hash(Z || Counter || P1),
  where Hash is SHA-256, and the 32-bit counter increases as more output blocks are generated, the output blocks are concatenated to form the KDF output
• MAC2 is HMAC:
  HMAC(K2, C) = Hash( (K2 ^ iPad) || Hash( (K2 ^ oPad) || C ) ),
  where Hash is SHA-256, and iPad and oPad are 256-bit (32-byte) blocks formed by repeating the byte 0x36 and 0x5C, respectively
• in 1609.2-2016
  "Encryption shall use non-DHAES mode. This means that the elliptic curve points shall be converted to octet strings using LSB compressed representation."
  Regarding non-DHAES mode, in IEEE 1363a-2004:
  "The length in bits of the shared secret key K shall be l + k2 where k2 is the length in bits of the key for the message authentication code (l is the bitlength of the message M to be encrypted). In non-DHAES mode, let K1 be the leftmost l bits of K and let K2 be the remaining k2 bits.”
  This means that the KDF output = ENC key | MAC Key, in a (big endian) byte array.
• From 1609.2-2016, Sec 6.3.30:
  On EncryptedData:

  This data structure encodes data that has been encrypted to one or more recipients using the recipients’ public or symmetric keys as specified in 5.3.4.

  Sec 5.3.4.1: This section explains how the data is encrypted with a fresh symmetric key generated by the sender, and the symmetric key is then encrypted for the recipient using that recipient’s encryption key and refers to Sec 5.3.5 that explains Public Key Encryption using ECIES.
• Sec 6.3.31:
  On RecipientInfo:
  • certRecipInfo: The data encryption key was encrypted using the public encryption key in a certificate. This field contains the HashedId8 of the certificate. In this case, the parameter P1 to ECIES as defined in 5.4.5 is the hash of the certificate.
  • signedDataRecipInfo: The data encryption key was encrypted using the public response encryption key from a SignedData. In this case, this field contains the HashedId8 of the1609Dot2Data containing the SignedData containing the encryption key. In this case, the parameter P1 to ECIES as defined in 5.4.5 is the SHA-256 hash of the Ieee1609Dot2Data containing the response encryption key.
  • rekRecipInfo: The data encryption key was encrypted using a public response encryption key that was not obtained from a SignedData. In this case, this field contains the HashedId8 of the response encryption key. In this case, the parameter P1 to ECIES as defined in 5.4.5 is the hash of the empty string.