SMPTE Standards Transition Issues for NIST/FIPS Requirements V1.1

SMPTE Standards Transition Issues for NIST/FIPS Requirements v1.1

2010.8.23

DRM inside, Taehyun Kim ETRI, Kisoon Yoon Contents

1 Introduction

NIST (National Institute of Standards and Technology) published second draft special document 1 (SP 800-131, Recommendation for the Transitioning of Cryptographic Algorithms and Key Length) [28] in June, 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 Signature (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 documents2 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 Signature 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 S427 5.1 LE_Key generation Random number generation Random number - [15] 6.3.1 Algorithm type RSA_oaep_mgf1p_sha1_2048 Key transport RFC 2437 [9] 1 It is a revised version reflecting public comments related on the delay of the imminent 2010 transition due date of the vulnerable algorithm or key length. The second draft temporarly grants delay of the deadline in some parts until 2013 or 2015 with the term ‘deprecated’. Currently NIST has received additional comments on the second version. 2 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. 1 6.3.3 Hash SHA1 Integrity FIPS 180-1 [1] 6.4.5 LE Key Type AES-CTR-128 Data encryption FIPS 197 [6] 5.5 Cipher Algorithm AES-CBC-128 Data encryption FIPS 197 S429-6 5.6 MIC Algorithm HMAC-SHA1-128 Integrity RFC 2104 [8] [16] 6.10 MIC (Optional) MIC Key derivation Random number FIPS 186-2 [4] S429-7 Digest method : SHA-1 6.13 Signature (Optional) Digital signature FIPS 186-2 [17] Signature method : RSA-SHA256 8.2.2 Hash SHA-1 Integrity RFC3174 [11] S429-8 Digest method : SHA-1 5.10 Signature (Optional) Digital signature FIPS 186-2 [18] Signature method : RSA-SHA256 6.3 Hash SHA-1 Integrity RFC 3174 S430-1 None [19] (Refer 430-3) Signature algorithm:RSA-SHA256 Digital signature RFC 3280 [13] S430-2 5.2 Field Constraints Public Key : RSA-2048 Key algorithm RFC 3447 [14] [20] Hash for Public Key TP : SHA1 5.4 Thumbprint Key identifier FIPS 180-2 [2] Hash for Certificate Key TP : SHA1 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 S430-3 6.2 EncryptedData AES-CBC-128 Data encryption FIPS 197 [21] Digest method : SHA-256 W3C XML- 7.2 SignatureInfo Digital signature Signature method : RSA-SHA256 Signature [29] 7.1.8 Previous Header Hash SHA-1 FIPS 180-1 7.1.9 Record Body Hash SHA-1 S430-4 7.3.3.1 Record Header Hash SHA-1 Digital signature [22] W3C XML- 7.3.4 Signature (Optional) xml-signature Signature S430-5 Digest method : SHA-256 W3C XML- 6.1.3 Log Record Signature Digital signature [23] Signature method : RSA-SHA256 Signature Communication channel : TLS Key transport RFC 2246 [9] S430-6 Public key algorithm : RSA-2048 Key encryption RFC 3447 6.1 Message Security [24] 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 186-x: Digital Signature Standard FIPS 197: Advanced Encryption 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 2 3.1 Encryption

NIST recommends using Three-key Triple DES or 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 /decryption 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.

Algorithm Use (Encryption/Decryption) AES-128 Acceptable beyond 2010 AES-192 Acceptable beyond 2010 AES-256 Acceptable beyond 2010 Table 1 NIST Recommendation for Encryption [28]

3.2 Digital Signatures

3.2.1 Signature method

NIST recommends using above 112 bits symmetric key length on new implementation of digital signature after 20103. SMPTE currently uses RSA algorithm with 2048 key size in the S429-7, S429-8, S430-2 and S430- 3. The 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 Signature (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 at least before end of the 2013. 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 Signature Process Use 80 bits of security strength: Deprecated from 2011 through 2013 Signature RSA: 1024 ≤ |n| < 2048 Generation ≥ 112 bits of security strength: Acceptable beyond 2010 RSA: |n| ≥ 2048 80 bits of security strength: Legacy use after 2010 Signature RSA: 1024 ≤ |n| < 2048 Verification ≥ 112 bits of security strength: Acceptable beyond 2010 RSA: |n| ≥ 2048 Table 2 NIST Recommendation for Digital Signature Method [28]

3.2.2 Digest method

NIST recommends using above SHA-224 on new implementation of digital signature after 2010 4. 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] at least before end of the 2013.

Digital Signature Process Use

3 Transition can be delayed until 2013. But it is recommended to be done as soon as possible since it said the lower bits (e.g. above 80 bits) would be deprecated from 2011 to 2013. 4 Transition can be delayed until 2013. But it is recommended to be done as soon as possible since it said using of SHA-1 would be deprecated from 2011 to 2013. 3 Signature SHA-1 Deprecated from 2011 through 2013 Generation SHA-224, SHA-256, SHA-284, SHA-512 Acceptable beyond 2010 Signature SHA-1 Legacy use after 2010 Verification SHA-224, SHA-256, SHA-284, SHA-512 Acceptable beyond 2010 Table 3 NIST Recommendation for Digital Signature Digest Method [28]

3.3 Random Number Generation

NIST recommends using the RNG method described in SP 800-90 [27] on new implementation of RNG after 20105. 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 at least before end of the 2015.

Description Use RNGs specified in SP 800-90 (HASH, HMAC, CTR, Acceptable beyond 2010 DUAL_EC) and ANS X9.62-2005 (HMAC) RNGs specified in FIPS 186-2, ANS X9.31-1998 and Deprecated from 2011 through 2015 ANS X9.62-1998 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 20106 [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 at least before end of the 2013.

Description Use |n| = 1024 bits Deprecated from 2011 through 2013 SP 800-56B Key Agreement schemes |n| = 2048 bits Acceptable beyond 2010 |n| = 1024 bits Deprecated from 2011 through 2013 SP 800-56B Key Transport schemes |n| = 2048 bits Acceptable beyond 2010 Non-56B-compliant Key Transport |n| ≥ 1024 bits Deprecated from 2011 through 2013 schemes |n| ≥ 2048 bits Deprecated after 2013 Table 5 NIST Recommendation for Key Agreement and Key Transfer [28]

3.6 Key Wrapping

5 Transition can be delayed until 2015. But it is recommended to be done as soon as possible since it said using of RNGs specified in FIPS 186-2, ANS X9.31-1998 and ANS X9.62-1998 would be deprecated from 2011 to 2015. 6 Transition can be delayed until 2013. But it is recommended to be done as soon as possible since it said using 1024 bits or non-56B-compliant key transport schemes would be deprecated from 2011 to 2013. 4 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 Use SHA-1 SHA-224 SHA-256 Acceptable beyond 2010 SHA-384 SHA-512 Table 6 NIST Recommendation for Hash Function [28]

3.9 Message Authentication Codes (MACs)

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 Use HMAC Generation Key lengths ≥ 112 bits Acceptable beyond 2010 HMAC Verification 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 specifications are identified to be considered evolving like following table.

SMPTE doc. # Transition Items Reason Deadline7 Reference Ch. Random number generation Not using SP 800-90 Before 2016 3.3 S427 Key transport scheme Not using SP 800-56B Before 2014 3.5 S429-6 Random number generation Not using SP 800-90 Before 2016 3.3 S429-7 Digital signature Using SHA1 Before 2014 3.2.2 S429-8 Digital signature Using SHA1 Before 2014 3.2.2

7 The deadline was extended by 3 years than SP800-131 draft v1.0. But it is a temporal approval from 2011 to 2014 or 2016 with ‘deprecated’ mark. So it is recommended to update SMPTE document related SP800-31 transition plan as soon as possible. Because it will prevent digital cinema device manufacturers who make a system based on the current obsolete SMPTE specification and want to take security validation process between 2011 and 2013, from doing the process again with new specification after 2013. 5 S430-1 - - - - S430-2 - - - - S430-3 - - - - S430-4 Digital signature Using SHA1 Before 2014 3.2.2 S430-5 Digital signature Algorithm Before 2014 3.2.1 S430-6 - - - - Table 8 SMPTE document list considered updating

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 Signature Standard", Federal Information Processing Standards Publication, Jan. 2000. [5] FIPS 186-3, "Digital Signature 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 6 Generators", National Institute of Standards and Technology, Mar. 2007 [28] SP 800-131, "Recommendation for the Transitioning of Cryptographic Algorithms and Key Length", National Institute of Standards and Technology, Jun. 2010 [29] XML Signature, "XML-Signature Syntax and Processing", W3C Recommendation, Feb. 2002