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)
<draft-khan-gaur-secure-mpeg-syntax-00.txt>
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]