Internet Draft J. Khan Expires in six months RSA Security Inc. M. Gaur RSA Security Inc. Cryptographic Message Syntax for MP3/MPEG I, II, and III Secure MPEG (SMPEG) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract This document describes a 'cryptographic message syntax for representing encrypted MPEG (Moving Picture Experts Group) 1 or 2, layer III audio (commonly known as "MP3")'. The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "SHALL", "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase, as shown) are to be interpreted as described in [RFC2119]. Khan, et al. [Page 1] Internet Draft Secure MPEG August 2001 1 Introduction MPEG in its current playable format lacks 'content security' when copyright and unauthorized content distribution is a concern. Current MPEG format (e.g., MP3) also suffers content identification information. The security layer discussed in this specification provides a cryptographic way of encrypting the MPEG content such that it can only be decrypted and used by intended recipients. The Security layer also stores the content identification information which can be used to convey related information about the content. It is important to mention that for this cryptographic syntax to be successful, it must be extremely easy to implement. To achieve this goal, most commonly used algorithms are suggested, defaults are assumed for easier implementation, and simplest ASN1 data objects are used. This version mandates the use of RSA Cryptosystem to accomplish the asymmetric encryption which allows two parties to exchange confidential information securely. The symmetric algorithm used here is 3-DES (3-key-EDE, CBC mode) which uses a 24 byte encryption key (set of 3 keys) for encryption/decryption. The optional signature algorithm is SHA-1 with RSA. 2 Overview A Secure MPEG message (SMPEGMsg), as defined in section 3 of this document, contains encrypted MPEG content along with information which an intended recipient uses to decrypt the content. Construction of encrypted MPEG content involves the following steps: (a) An X509 Certificate [X509] of the intented recipient is obtained and validated, thus ensuring authenticity. (b) A 24 byte long symmeteric key is generated. (c) This randomly generated symmetric key is encrypted using the public key, obtained from the recipients's certificate. This operation ensures confidentiality of symmetric key. (e) MPEG data (e.g. MP3 music file contents) MUST be encrypted with the symmetric key using 3-DES (3-key-EDE, CBC mode) algorithm and then encoded as an OCTET STRING. (f) Optionally, a digital signature MAY be generated on the encrypted content to provide non-repudiation and integrity. Such signature Khan, et al. [Page 2] Internet Draft Secure MPEG August 2001 MUST be created using SHA-1 with RSA algorithm. The final SMPEGMsg message is created using: - Serial numbers of the recipient and vendor certificates . - Encrypted symmetric key. - Encrypted Content - and other optional items as defined in section 3. The transport of the Secure MPEG Message is beyond the scope of this document. 3 SMPEGMsg Syntax The SMPEGMsg message has the following structure: SMPEGMsg ::= SEQUENCE { version INTEGER, mediaSerialNumber INTEGER, recipientCertSerialNumber INTEGER, encryptedSymmetricKey OCTET STRING, title [0] OCTET STRING OPTIONAL, playtime [1] OCTET STRING OPTIONAL, genre [2] OCTET STRING OPTIONAL, vendor [3] OCTET STRING OPTIONAL, miscInfo [4] OCTET STRING OPTIONAL, symmetricAlg [5] AlgorithmIdentfier OPTIONAL, vendorCertSerialNumber [6] INTEGER OPTIONAL, vendorSignature [7] OCTET STRING OPTIONAL, encryptedContent OCTET STRING } Mandatory Fields: -- version field defines the version of this MPEG message MUST be 0 for current version. -- mediaSerialNumber field is vendor specific serial number for encrypted content. This MAY be analogous to a track number. -- recipientCertSerialNumber field is the serial number of the recipient certificate used to encrypt the Symmetric key. -- encryptedSymmetricKey - Since this version mandates the use of 3-DES (3-key-EDE, CBC mode), the symmetric key MUST be 24 bytes Khan, et al. [Page 3] Internet Draft Secure MPEG August 2001 long and MUST be encrypted. This randomly generated key is first encrypted by the vendor using its private key (which provides non-repudiation) and the result of which is then encrypted using the public key from recipient's X509 [X509] Certifcate (which provides confidentiality of the symmetric key). All the above asymmetric encryption/decryption operaions must be performed as defined in PKCS#1[PKCS1]. -- encryptedContent is the encrypted MPEG content which MUST be encrypted with the aforementioned symmetric key using 3-DES (3-key-EDE, CBC mode). For more information refer section 3.2. Optional Fields: -- title field specifies the title of the MPEG content. -- playtime is the media length in seconds, 0 for unknown length -- genre is the category which the MPEG content belongs to. -- vendor field specifies the Vendor Name -- miscInfo contains additional content information that MAY be included in the SMP3Msg as a string of URL-Encoded [URL] name-value pairs. This string is then encoded as an OCTET STRING. -- symmetricAlg specifies the algorithm to be used for symmetric encryption/decription operations. This version requires that symmetric algorithm MUST be 3-DES (3-key-EDE, CBC mode) which makes this item field unnecessary for this version but it is mentioned here for future extensibility. Implementations conforming to this version should simply ignore this field and assume that symmetric algorithm is 3-DES (3-key-EDE, CBC mode) (see section 4 for other information regarding default algorithm parameters etc.) -- vendorCertSerialNumber field is the serial number of the vendor certificate which should be used to verify the vendor signature if present. -- vendorSignature, if present, is the signature generated on the encryptedContent (including tag and length octets). This signature MUST be created using SHA-1 with RSA algorithm. 3.1 Notes on encryptedContent: Encoding of Encrypted Content can be of fixed or indefinite length. Khan, et al. [Page 4] Internet Draft Secure MPEG August 2001 Ordinarily, the content would be shipped as fixed length content (e.g. a song file). In other cases, the content can be indefinite length (e.g. live broadcast). Both cases are defined below:[ASN1] 3.1.1 Fixed length content Fixed length content would be encoded as an OCTET STRING of given length. 3.1.2 Indefinite length content Indefinite length content is encoded as a constructed OCTET STRING which consists of one or more OCTET STRING elements followed by end of content bytes (two zeros, see 'A Layman's guide to ASN1'). [ASN1] Use of Indefinite length encoding might be a good idea in live broadcasts where each encrypted MPEG frame can be encoded as a separate OCTET STRING element. 4 Algorithms and associated data. Complying implementations MUST use, - 3-DES (3-key-EDE, CBC mode) for all symmetric key operations. The Initialization Vector(IV) used for this purpose MUST be the following eight bytes: 0x41 0x42 0x43 0x44 0x45 0x46 0x47 0x48 - RSA Encryption/Decryption and padding, as defined in PKCS#1 [PKCS1], for all assymmetric key operations. - SHA-1 with RSA as the signature algorithm. 5. Entity Initilization and Encrypted Message Generation Before an encrypted MPEG message can be exchanged, both parties, the intended recipient and the vendor (entity actually creating the encrypted message) must initialize themselves in order to participate in successful message exchange. 5.1 Initialization Participating entities must follow the steps below in order to establish trust. These steps MAY required to be performed only Khan, et al. [Page 5] Internet Draft Secure MPEG August 2001 once during an initial setup of a vendor or a recipient. Vendor Initialization 1. Generate an RSA key pair and have it certified by a trusted Certificate Authority. 2. The certificate thus obtained, along with any other certificate that may be required to validate the vendor certificate, MUST be supplied to all recipients with whom vendor wants to exchange Encrypted MPEG messages with. Recipient Initialization 1. Generate an RSA key pair and have it certified by a trusted Certificate Authority which is also trusted by the Vendor. 2. The certificate thus obtained, along with any other certificate that may be required to validate the vendor certificate, MUST be supplied to the Vendor when Recipient wants to receive an Encrypted MPEG message. 5.2 Message Generation Following are the steps involved in Generating a SMPEG message: (a) The vendor recieves a request for a particular SMPEG message (a song or a video). (b) The recipient provides a X509 certificate to the vendor that will be used for encryption of symmetric key. (c) The vendor encrypts the actual MPEG content using a randomly generated symmeteric key. (d) The vendor then encrypts the symmetric key using the RSA public key from the recipient's X509 certificate. (e) Optionally, a digital signature MAY be generated on the encrypted content to provide non-repudiation and integrity. Such signature MUST be created using SHA-1 with RSA algorithm. (f) The vendor constructs the SMPEG message as defined in section 3 (g) The vendor sends the SMPEG message to the intended recipient. 6 Playing Encrypted Content Below are the steps involved in Playing an Encrypted message Khan, et al. [Page 6] Internet Draft Secure MPEG August 2001 generated in section 5: (a) The recipient has in its possession or receives a new SMPEG message. (b) The recipient locates the private key corresponding to the certificate used by the vendor to encrypt the symmetric key and decrypts the contents of encryptedSymmetricKey field. (c) The output of step (b) should be the symmetric key which was used by the vendor to encrypt the MPEG content. The recipient then uses this symmetric key to decrypt the actual content specified by the encryptedContent field. (d) If present, the digital signature MAY be verified using the vendor certificate which is identified by the vendorCertSerialNumber field. (e) The OPTIONAL fields in the SMPEGMsg can be used to deliver additional information to the recipient. 7 Sample SMPEG ASN1 Encoded Messages: Here we define both type of encrypted content: the Fixed length and the unknown length Encrypted content. 7.1 Fixed Length Encoding of Encrypted Content: -- Outer Sequence Bytes (the length bytes are fake) 30 82 01 02 -- Version Number 02 01 00 -- Media Serial Number 02 10 90 80 70 60 50 40 30 20 10 11 22 33 44 55 66 77 -- Recipient Certificate Serial Number 02 10 68 6F 72 65 20 62 79 20 48 6F 75 68 6F 6E 67 20 -- Encrypted Symmetric Key (the length is defined -- by the modulus lenth of the RSA key; assume 128). 04 81 80 68 6F 72 65 20 62 79 20 72 76 65 72 20 70 72 87 6C 69 65 6E 74 2F 53 65 6E 20 53 75 6E 20 53 6F ... 90 80 70 60 50 40 30 20 10 11 22 33 44 55 66 77 -- Title (optional item) "My Secure MPEG" A0 11 04 0E 4D 79 20 53 65 63 75 72 65 20 4D 50 45 47 Khan, et al. [Page 7] Internet Draft Secure MPEG August 2001 -- Play time (optional item) 180 seconds. A1 03 02 01 B4 -- Encrypted Content (the actual encrypted -- MPEG data). With Known/Fixed/Definite length -- encoding. 04 82 2F 90 90 80 70 60 50 40 30 20 10 11 22 33 44 55 66 77 6C 69 65 6E 74 2F 53 65 6E 20 53 75 6E 20 53 6F ... 90 80 70 60 50 40 30 20 10 11 22 33 44 55 66 77 6C 69 65 6E 74 2F 53 65 6E 20 53 75 6E 20 53 6F 7.2 Indefinite Length Encoding of Encrypted Content: -- Outer Sequence Bytes 30 80 -- Version Number 02 01 00 -- Media Serial Number 02 10 90 80 70 60 50 40 30 20 10 11 22 33 44 55 66 77 -- Recipient Certificate Serial Number 02 10 68 6F 72 65 20 62 79 20 48 6F 75 68 6F 6E 67 20 -- Encrypted Symmetric Key (the length is defined -- by the modulus lenth of the RSA key; assume 128). 04 81 80 68 6F 72 65 20 62 79 20 72 76 65 72 20 70 72 87 6C 69 65 6E 74 2F 53 65 6E 20 53 75 6E 20 53 6F ... 90 80 70 60 50 40 30 20 10 11 22 33 44 55 66 77 -- Title (optional item) "My Secure MPEG" A0 11 -- Content Specific Tag and length 04 0E -- Octet String and length 4D 79 20 53 65 63 75 72 65 20 4D 50 45 47 -- Play time (optional item) 180 seconds. A1 03 -- Content Specific Tag and length 02 01 B4 -- Integer length and value -- Encrypted Content (the acutal encrypted -- MPEG data). With Unknown length encoding. 24 80 -- Now rest of the data is contained -- in individual OCTET STRINGS (e.g. frames). 04 08 -- actual encrypted data... 1st frame 6E 20 53 75 6E 20 53 6F 04 08 -- actual encrypted data... 2nd frame 6C 69 6E 74 2F 53 65 12 Khan, et al. [Page 8] Internet Draft Secure MPEG August 2001 04 08 -- actual encrypted data... LAST frame 74 2F 65 6E 20 53 75 49 -- End of content bytes 00 00 00 00 7. References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [X509] R. Housley, W. Ford, W. Polk, D. Solo, "Internet X.509 Public Key Infrastructure, Certificate and CRL Profile," RFC 2459, January 1999. [PKCS1] RSA Laboratories. PKCS #1: RSA Encryption Standard. Version 2.0, October 1998. [ASN1] RSA Laboratories. "A Layman's Guide to a Subset of ASN.1, BER, and DER". November 1, 1993. [URL] T. Berners-Lee, L. Masinter, M. McCahill "Uniform Resource Locators (URL)," RFC 1738, January 1999. 8. Authors' Addresses Jahanzeb Khan RSA Security Inc. 2955 Campus Dr. San Mateo, CA-94403 jkhan@rsasecurity.com Manish Gaur RSA Security Inc. 2955 Campus Dr. San Mateo, CA-94403 mgaur@rsasecurity.com Khan, et al. [Page 9]