SMPTE Standards Transition Issues for NIST/FIPS Requirements Contents 2010.5.20 DRM inside Taehyun Kim 1 Introduction NIST (National Institute of Standards and Technology) published a draft special document (SP 800-131, Recommendation for the Transitioning of Cryptographic Algorithms and Key Sizes) [28] in January, 2010. It includes transition recommendations through 9 items associated with the use of cryptography, whose purpose is to keep the security level being still higher as the more powerful computing techniques are available. The 9 items described in the SP 800-131 are: Encryption (Sec. 2) Digital (Sec. 3) Random Number Generation (Sec. 4) Key Agreement Using Diffie-Hellman and MQV (Sec. 5) Key Agreement and Key Transport Using RSA (Sec. 6) Key Wrapping (Sec. 7) GDIO Protocol (Sec 8.) Deriving Additional Keys (Sec. 8) Hash Function (Sec. 9) Message Authentication Codes (Sec. 10) Currently, SMPTE documents 1 refer to the FIPS (Federal Information Processing Standard) to use its cryptographic algorithms which are Secure Hash Standard (FIPS 180-1, 180-2) [1][2], Digital Standard (FIPS 186-2, Jan. 2000) [4], Random Number Generation (FIPS 186-2, Jan. 2000), Advanced Encryption Standard (FIPS 197, Nov. 2001) [6] and Keyed-Hash Message Authentication Code (FIPS 198-1, Apr. 2002) [7]. As upgrade version of the FIPSs and new recommendation are published from the NIST, we need to consider impacts on the SMPTE standard documents. This report summarizes SMPTE documents in cryptographic point of view and new NIST requirements related to the cryptographic algorithm and strength to which SMPTE standards are referring. And it also verifies if current algorithms and key length used in SMPTE standards are compliant to the new requirements. 2 SMPTE Standard List with Cryptography Specification SMPTE Chapter Cryptographic item Purpose Reference 5.1 LE_Key generation Random number generation Random number - S427 6.3.1 Algorithm type RSA_oaep_mgf1p_sha1_2048 Key transport RFC 2437 [9] [15] 6.3.3 Hash SHA1 Integrity FIPS 180-1 [1] 6.4.5 LE Key Type AES-CTR-128 Data encryption FIPS 197 [6] S429-6 [16] 5.5 Cipher Algorithm AES-CBC-128 Data encryption FIPS 197 5.6 MIC Algorithm HMAC-SHA1-128 Integrity RFC 2104 [8] 6.10 MIC (Optional) MIC Key derivation Random number FIPS 186-2 [4] 1 All SMPTE documents in this report are SMPTE Standards for Digital Cinema published or worked by SMPTE 21 DC. Other standard documents from other TC groups are not considered.
S429-7 [17] S429-8 [18] S430-1 [19] S430-2 [20] S430-3 [21] S430-4 [22] S430-5 [23] S430-6 [24] 6.13 (Optional) Digest method : SHA-1 Digital signature FIPS 186-2 8.2.2 Hash SHA-1 Integrity RFC3174 [11] 5.10 (Optional) Digest method : SHA-1 Digital signature FIPS 186-2 6.3 Hash SHA-1 Integrity RFC 3174 None (Refer 430-3) 5.2 Field Constraints algorithm:rsa-sha256 Digital signature RFC 3280 [13] Public Key : RSA-2048 Key algorithm RFC 3447 [14] 5.4 Thumbprint Hash for Public Key TP : SHA1 Hash for Certificate Key TP : SHA1 Key identifier FIPS 180-2 [2] 6.1.1 Encryption method rsa-oaep-mgf1p Key agreement RFC 3447 6.1.2 KeyInfo D-Cinema certificate (RSA-2048) Key encryption RFC 3447 6.2 EncryptedData AES-CBC-128 Data encryption FIPS 197 7.2 Info Digest method : SHA-256 W3C XML- Digital signature [29] 7.1.8 Previous Header Hash SHA-1 7.1.9 Record Body Hash SHA-1 Digital signature FIPS 180-1 7.3.3.1 Record Header Hash SHA-1 7.3.4 (Optional) xml-signature W3C XML- 6.1.3 Log Record Digest method : SHA-256 W3C XML- Digital signature Communication channel : TLS Key transport RFC 2246 [9] 6.1 Message Security Public key algorithm : RSA-2048 Key encryption RFC 3447 Cipher algorithm : AES-CBC-128 Data encryption RFC 3268 [12] HASH : SHA1 Integrity - S427: Link Encryption for 1.5Gb/s1 Serial Digital Interface S429-6: D-Cinema Packaging, MXF Track File Essence Encryption S429-7: D-Cinema Packaging, Composition Playlist S429-8: D-Cinema Packaging, Packing List S430-1: D-Cinema Operations Key Delivery Message S430-2: D-Cinema Operations Digital Certificate S430-3: D-Cinema Operations Generic Extra-Theatre Message Format S430-4: D-Cinema Operations, Log Record Format Specification S430-5: D-Cinema Operations, Security Log Event Class and Constraints S430-6: D-Cinema Operations, Auditorium Security Messages for Intra-Theater Communications FIPS 180-x: Secure Hash Standard FIPS 197: Advanced Encryption Standard FIPS 186-x: Digital Standard FIPS 198-x: The Keyed-Hash Message Authentication Code RFC 2104: HMAC: Keyed-Hashing for Message Authentication RFC 2246: The TLS Protocol Version 1.0 RFC 2437: PKCS #1: RSA Cryptography Specifications Version 2.0 RFC 3174: US Secure Hash Algorithm 1 RFC 3268: Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS) RFC 3280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile RFC 3447:"Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1 SP 800-56B: Recommendation for Pair-Wise Key Establishment Schemes Using Integer Factorization Cryptography SP 800-57: Recommendation for Key Management SP 800-90: Recommendation for Random Number Generation Using Deterministic Random Bit Generators SP 800-131: Recommendation for the Transitioning of Cryptographic Algorithms and Key Sizes 3 SMPTE Transition Issues on the SP 800-131 Recommendation 3.1 Encryption NIST recommends using above AES-128 encryption algorithm on new implementation after 2010. SMPTE
currently uses only AES-128 algorithm for symmetric encryption (FIPS 197) in the S427, S429-6, S430-3 and S430-6. So there is NO transition issue on the symmetric encryption algorithm in the SMPTE standards. And under the current NIST recommendation, AES-128 is valid even beyond 2030. Therefore, there will be also no transition concern on this item for the time being. Encryption algorithm New Validations Already Validated Implementations AES-128 Approved Approved beyond 2010. AES-192 Approved Approved beyond 2010. AES-256 Approved Approved beyond 2010. Table 1 NIST Recommendation for Encryption [28] 3.2 Digital 3.2.1 method NIST recommends using above 112 bits symmetric key length on new implementation of digital signature after 2010. SMPTE currently uses RSA algorithm with 2048 key size in the S429-7, S429-8, S430-2 and S430-3. A asymmetric algorithm RSA with 2048 bits is regarded as having 112 bits symmetric key length [28]. So there is no transition issue on the Digital (FIPS 186-x) in those SMPTE standards. However S430-5 (Section 6.1.3 Log record signature) specifies the algorithm to W3C s xml-signature which allows DSS algorithm as well as RSA with any key length. Although S430-5 s xml-signature implicitly indicates using the digital cinema certificate which is required to have only RSA algorithm and 2048 key length [20], S430-5 needs to consider changing signature method as RSA instead of vague xml-signature to keep consistency with other SMPTE standards. And under the current NIST recommendation, RSA-2048 is valid until 2030. Therefore, if SMPTE wants to use this algorithm even beyond 2030, it needs to increase the key length to 3072 bits before 2030. Digital Process Generation Verification New Validations 80 and < 112 bits of security approved through 2010 only 112 bits of security approved Already Validated Implementations 80 and < 112 bits of security approved through 2010 only 112 bits of security approved beyond 2010 80 bits of security approved 80 bits of security approved beyond 2010 Table 2 NIST Recommendation for Digital Method [28] 3.2.2 Digest method NIST recommends using above SHA-224 on new implementation of digital signature after 2010. SMPTE currently uses both SHA1 (in S429-7, S429-8 and S430-4) and SHA256 (in S430-2 and S430-5) for the purpose of signature digest. The SHA1 of the SMPTE digest method may not be security critical issue because SMPTE uses it only at the optional signature part. However once someone used signature function, the algorithm is required to be secure enough. So it needs to consider changing SHA1 algorithms in the S429-7, S429-8 and S430-4 into SHA 256 according to FIPS 186-3 [4] before end of the 2010. Hash Function New Validations Already Validated Implementations Approved for digital signatures Approved for digital signatures generation SHA-1 generation through 2010 only. through 2010 only. SHA-224 SHA-256 SHA-384 SHA-512 3.3 Random Number Generation applications applications beyond 2010 Table 3 NIST Recommendation for Digital Digest Method [28]
NIST recommends using the RNG method described in SP 800-90 [27] on new implementation of RNG after 2010. There are 2 usages of RNG in SMPTE documents. S429-6 specifies a RNG method described in FIPS 186-2 and S427 mentions a RNG without specific RNG algorithm or standard reference. So S429-6 and S427 needs to consider modifying its description to use the method specified in the SP 800-90 before end of the 2010. Description New Validations Already Validated Implementations RNGs specified in SP 800-90 (HASH, HMAC, CTR, DUAL_EC) and ANS X9.62-2005 (HMAC) Approved Approved beyond 2010 RNGs specified in FIPS 186-2, ANS X9.31-1998 and ANS X9.62-1998 Approved through 2010 only Approved through 2015 only Table 4 NIST Recommendation for Random Number Generation [28] 3.4 Key Agreement Using Diffie-Hellman and MQV There is no reference on this cryptography in the SMPTE standards. So there is NO transition issue for SMPTE in this part. 3.5 Key Agreement and Key Transport Using RSA NIST recommends using 2048 bits key size on new implementation of Key Agreement and Key Transport after 2010 [25][28]. SMPET standard currently uses 2048 bits RSA certificate for key agreement and transport in ETM (S430-3), KDM (S430-1) format and ASM (S430-6) protocol. So there is NO transition issue for these SMPTE documents until 2013. However NIST requests new cryptographic module, even though it has 2048 key bits, to be compliant with SP 800-56B for the Key Transport after 2013. The 430-6 has no problem because it uses TLS scheme as Key Transport protocol, which NIST already agreed as a proven scheme. On the other hand, S427 needs to consider to be verified if the key transport scheme of this standard is compliant with SP 800-56B before 2013. Description New Validations Already Validated Implementations Key agreement n = 1024 bits approved through 2010 only n = 1024 bits allowed through 2010 only n = 2048 approved n = 2048 bits approved beyond 2010 Any scheme with 1024 n < 2048 allowed Any scheme with 1024 n < 2048 allowed through 2010 only through 2010 only Key transport Approved through 2010 only if the scheme is tested for compliance with SP 800-56B with n = 1024 Any untested scheme with n 2048 allowed through 2013 only Approved through 2010 only if the scheme is tested for compliance with SP 800-56B with n = 1024 Any untested scheme with n 2048 allowed through 2013 only 3.6 Key Wrapping Approved if the scheme is tested for compliance with SP 800-56B with n = 2048 Approved beyond 2013 if the scheme is tested for compliance with SP 800-56B with n = 2048 Table 5 NIST Recommendation for Key Agreement and Key Transfer [28] Key wrapping is the encryption of a symmetric key by another symmetric key. SMPTE standard uses asymmetric key for encryption of a symmetric key. So there is NO transition issue for SMPTE in this part. 3.7 Deriving Additional Keys from a Cryptographic Key
NIST allows using an approved RNG scheme to obtain derived additional key from a cryptographic key. SMPET 429-6 standard uses RNG method to get MIC key value. So there is no transition issue for SMPTE in this part, only under the condition that the 3.3 Random Generation Number transition issue is resolved. 3.8 Hash Functions NIST allows SHA1 algorithm for all non-digital signature generation applications even beyond 2010. SMPTE uses SHA-1 for integrity checking and identifier in S427, S429-7, S429-8, S430-2 and S430-6. So there is NO transition issue for SMPTE in this part. Hash Function New Validations Already Validated Implementations Approved for all non-digital Approved for all non-digital signature generation SHA-1 signature generation applications applications beyond 2010. SHA-224 SHA-256 SHA-384 SHA-512 applications Table 6 NIST Recommendation for Hash Function [28] applications beyond 2010 3.9 Message Authentication Codes NIST recommend using over 112 bits key on new implementation of HMAC algorithm after 2010. SMPTE 429-6 standard currently uses HMAC-SHA1-128 for checking essence integrity in the MXF. So there is NO transition issue for SMPTE in this part. MAC Algorithm New Validations Already Validated Implementations Any approved hash function Any approved hash function Key lengths 80 bits and < 112 bits Key lengths 80 bits and < 112 bits HMAC approved through 2010 only approved through 2010 only Key lengths 112 bits approved Key lengths 112 bits approved beyond 2010 Table 7 NIST Recommendation for HMAC [28] 4 Conclusion The main objective of this report is to go over the SMPTE standards in the cryptography perspective and check if the standards abide by the latest NIST recommendation (SP 800-131) in order that digital cinema products would not be vulnerable in more powerful computing environment. We found that the SMPTE standards refer FIPS, IETF s RFC and W3C standards or recommendations for its cryptographic specification through 9 documents. All cryptographic items in the SMPTE documents, no matter which standards the SMPTE refers, were checked if these items are complied with the new NIST recommendations. In the result, some SMPTE standards with digital signature and RGN specification are identified to be considered evolving the standards before the end of the 2010. Key Transport scheme not using TLS protocol needs to be verified on the compliance with SP 800-56B before 2013. And under the current NIST recommendation, it is found that RSA key length needs to be increased to 3072 bits before end of the 2030. 5 References [1] FIPS 180-1, "Secure Hash Standard", Federal Information Processing Standards Publication, Apr. 1995. [2] FIPS 180-2, "Secure Hash Standard", Federal Information Processing Standards Publication, Aug. 2002. [3] FIPS 180-3, "Secure Hash Standard", Federal Information Processing Standards Publication, Oct. 2008. [4] FIPS 186-2, "Digital Standard", Federal Information Processing Standards Publication, Jan. 2000. [5] FIPS 186-3, "Digital Standard", Federal Information Processing Standards Publication, Jan. 2009. [6] FIPS 197, "Advanced Encryption Standard", Federal Information Processing Standards Publication, Nov.
2001. [7] FIPS 198-1, "The Keyed-Hash Message Authentication Code ", Federal Information Processing Standards Publication, Jul. 2008. [8] RFC 2104, "HMAC: Keyed-Hashing for Message Authentication", Internet Engineering Task Force, Feb. 1997. [9] RFC 2246, "The TLS Protocol Version 1.0", Internet Engineering Task Force, Jan. 1997. [10] RFC 2437, "PKCS #1: RSA Cryptography Specifications Version 2.0, Internet Engineering Task Force, Oct. 1998. [11] RFC 3174, "US Secure Hash Algorithm 1", Internet Engineering Task Force, Sep. 2001. [12] RFC 3268, "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)", Internet Engineering Task Force, Jun. 2002. [13] RFC 3280, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", Internet Engineering Task Force, Apr. 2002. [14] RFC 3447, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", Internet Engineering Task Force, Feb. 2003. [15] SMPTE 427, "Link Encryption for 1.5Gb/s1 Serial Digital Interface", SMPTE Technology Committee DC28 on D-Cinema, Nov. 2007. [16] SMPTE 429-6, "D-Cinema Packaging, MXF Track File Essence Encryption", SMPTE Technology Committee DC28 on D-Cinema, Jun. 2007. [17] SMPTE 429-7, "D-Cinema Packaging, Composition Playlist", SMPTE Technology Committee DC28 on D- Cinema, May. 2006. [18] SMPTE 429-8, "D-Cinema Packaging, Packing List", SMPTE Technology Committee DC28 on D-Cinema, May. 2006. [19] SMPTE 430-1, "D-Cinema Operations Key Delivery Message", SMPTE Technology Committee DC28 on D-Cinema, May. 2006 [20] SMPTE 430-2, "D-Cinema Operations Digital Certificate", SMPTE Technology Committee DC28 on D- Cinema, May. 2006 [21] SMPTE 430-3, "D-Cinema Operations Generic Extra-Theatre Message Format", SMPTE Technology Committee DC28 on D-Cinema, May. 2006 [22] SMPTE 430-4, "D-Cinema Operations, Log Record Format Specification", SMPTE Technology Committee DC28 on D-Cinema, Mar. 2008 [23] SMPTE 430-5, "D-Cinema Operations, Security Log Event Class and Constraints", SMPTE Technology Committee DC28 on D-Cinema, Mar. 2008 [24] SMPTE 430-6, "D-Cinema Operations, Auditorium Security Messages for Intra-Theater Communications", SMPTE Technology Committee DC28 on D-Cinema, Mar. 2008 [25] SP 800-56B, "Recommendation for Pair-Wise Key Establishment Schemes Using Integer Factorization Cryptography, National Institute of Standards and Technology, Aug. 2009 [26] SP 800-57, "Recommendation for Key Management, National Institute of Standards and Technology, Mar. 2007 [27] SP 800-90, "Recommendation for Random Number Generation Using Deterministic Random Bit Generators", National Institute of Standards and Technology, Mar. 2007 [28] SP 800-131, "Recommendation for the Transitioning of Cryptographic Algorithms and Key Sizes", National Institute of Standards and Technology, Jan. 2010 [29] XML, "XML- Syntax and Processing", W3C Recommendation, Feb. 2002