Network Working Group J. Gildred Internet-Draft A. Andreasyan Expires: January 15, 2005 Pioneer R. Osawa T. Stahl Thomson J. Card Echostar July 17, 2004 Protected Entertainment Rights Management (PERM) draft-gildred-perm-02 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. This Internet-Draft will expire on January 15, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document describes the Protected Entertainment Rights Management (PERM) protocol for management of usage rights to digital entertainment content. PERM is not intended to replace existing copy protection and conditional access systems. Rather it is intended to complement such systems by providing standardized methods of device and user authentication, content protection and content rights Gildred, et al. Expires January 15, 2005 [Page 1] Internet-Draft PERM July 2004 management across heterogeneous data networks. PERM does not impose any content usage policy upon an implementation of the PERM protocol. PERM defines a common method for policy enforcement, and implementors are free to design and enforce their own policy by using the features and conventions of the PERM protocol. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Abbreviations, Terms and Conventions . . . . . . . . . . . . 5 3. Device Roles . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Content Access Translation . . . . . . . . . . . . . . . . . 10 5. Content Scrambling . . . . . . . . . . . . . . . . . . . . . 11 6. Removable Media . . . . . . . . . . . . . . . . . . . . . . 12 7. Direct and Indirect Authentication . . . . . . . . . . . . . 13 8. Signatures . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. Key Exchange . . . . . . . . . . . . . . . . . . . . . . . . 15 10. Content Usage Rights (CURs) . . . . . . . . . . . . . . . . 16 11. Entitlement Control Message (PERM ECM) . . . . . . . . . . . 17 12. Profile D: PERM Device ECM . . . . . . . . . . . . . . . . . 19 12.1 Device Authentication . . . . . . . . . . . . . . . . . 19 12.2 Device Content Protection . . . . . . . . . . . . . . . 19 13. Profile U: PERM User ECM . . . . . . . . . . . . . . . . . . 21 13.1 User Authentication . . . . . . . . . . . . . . . . . . 21 13.2 User Content Protection . . . . . . . . . . . . . . . . 21 14. Profile Z: PERM Zone ECM . . . . . . . . . . . . . . . . . . 23 14.1 PERM Zone . . . . . . . . . . . . . . . . . . . . . . . 23 14.2 Complex Zone . . . . . . . . . . . . . . . . . . . . . . 24 14.3 PERM Message Transport . . . . . . . . . . . . . . . . . 24 14.4 Zone Device Authentication . . . . . . . . . . . . . . . 24 14.5 Zone Membership . . . . . . . . . . . . . . . . . . . . 26 14.6 Zone Renewal . . . . . . . . . . . . . . . . . . . . . . 29 14.7 Zone Merging . . . . . . . . . . . . . . . . . . . . . . 31 14.8 Zone Content Protection . . . . . . . . . . . . . . . . 33 14.8.1 Protected Mode . . . . . . . . . . . . . . . . . . . 34 14.8.2 Pass Through Mode . . . . . . . . . . . . . . . . . 35 14.8.3 Clear Mode . . . . . . . . . . . . . . . . . . . . . 35 14.8.4 Zone Broadcasting and Multicasting . . . . . . . . . 35 15. PERM Device Requirements . . . . . . . . . . . . . . . . . . 37 16. Certification and Compliance Rules . . . . . . . . . . . . . 38 17. Future Work . . . . . . . . . . . . . . . . . . . . . . . . 39 18. Security Considerations . . . . . . . . . . . . . . . . . . 40 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 42 A. MsgType Header Description . . . . . . . . . . . . . . . . . 44 B. PERM CURs . . . . . . . . . . . . . . . . . . . . . . . . . 47 C. PERM ECM . . . . . . . . . . . . . . . . . . . . . . . . . . 52 C.1 ECM Header . . . . . . . . . . . . . . . . . . . . . . . . 52 Gildred, et al. Expires January 15, 2005 [Page 2] Internet-Draft PERM July 2004 C.2 Content Key . . . . . . . . . . . . . . . . . . . . . . . 54 C.3 CUR Section . . . . . . . . . . . . . . . . . . . . . . . 54 C.4 Certificate Authority Chain - CACH . . . . . . . . . . . . 54 C.5 Certificate - Cert . . . . . . . . . . . . . . . . . . . . 55 C.6 ECM HMAC and Signature . . . . . . . . . . . . . . . . . . 55 D. Encryption Algorithms and Mode . . . . . . . . . . . . . . . 56 E. Status Notification . . . . . . . . . . . . . . . . . . . . 57 F. DSA Certificates . . . . . . . . . . . . . . . . . . . . . . 59 G. Random Number Generator . . . . . . . . . . . . . . . . . . 60 H. X.509 v3 Certificates . . . . . . . . . . . . . . . . . . . 61 I. CRL Request . . . . . . . . . . . . . . . . . . . . . . . . 62 J. Certification Request . . . . . . . . . . . . . . . . . . . 63 K. Content Request Methods (CRMs) . . . . . . . . . . . . . . . 64 L. Protection Modes . . . . . . . . . . . . . . . . . . . . . . 65 M. ECM Delivery Methods (EDMs) . . . . . . . . . . . . . . . . 67 N. PERM Content Storage Methods (CSMs) . . . . . . . . . . . . 71 O. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 73 Intellectual Property and Copyright Statements . . . . . . . 74 Gildred, et al. Expires January 15, 2005 [Page 3] Internet-Draft PERM July 2004 1. Introduction This document describes a method of protecting digital content from unintended use. This document has three goals: 1. To describe a simple and secure protocol for authentication of the content sink as a user, device or group of devices. 2. To describe a simple yet sufficiently robust rights language for restricting content use by a sink device. 3. To provide content protection with strong encryption considering optimizations where possible for implementations with limited computing resources. It is beyond the scope of this document to discuss the political ramifications of using a digital rights management system to protect the fair use of any digital entertainment content. It is a premise of this specification that providing a mechanism for content owners and distributors to restrict the use of their content as they see fit, is a worthwhile endeavor. Gildred, et al. Expires January 15, 2005 [Page 4] Internet-Draft PERM July 2004 2. Abbreviations, Terms and Conventions The following abbreviations and terms are defined for this specification: PERM Device ....... A PERM Device is any device which is compatible with the PERM specification. Compatibility between PERM devices additionally requires a common certificate authority between the PERM devices. ECM ............... Entitlement Control Message PERM ECM .......... ECM in PERM-compliant format PERM Zone ......... Logical grouping of PERM devices to allow zone-level rights PERM Profile ...... A protection mode which defines the scope of access per content item CUR ............... Content Usage Right - PERM definition of content usage rights CSoD .............. Content Source Device - PERM device capable of transmitting PERM protected content CSiD .............. Content Sink Device - PERM device capable of receiving PERM protected content KC ................ Content key used for content scrambling. KZ ................ Zone key used for protection and authentication of zone communication. SSK ............... Shared secret key. Pub_D, Priv_D ..... A device public/private key pair is represented by Pub_D and Priv_D, respectively. TZ ................ Represents the zone key lifetime. The length of TZ is determined by the ZM which created the zone key. Pub_U, Priv_U ..... A user public/private key pair is represented by Pub_U and Priv_U, respectively. ZM ................ Zone Master - A CSoD responsible for generating the zone key and allowing zone membership to other Gildred, et al. Expires January 15, 2005 [Page 5] Internet-Draft PERM July 2004 devices. Only a CSoD device can be a ZM. CRM ............... Content Request Method - A method of requesting content, such as HTTP GET or RTSP. PERM defines extensions to existing CRMs allowing for PERM authentication data to be included in the content request. PMP ............... PERM Message Payload - The part of a CRM which is extended to include a PERM content request message. EDM ............... ECM Delivery Method - A method of delivering one or more ECMs inline with the corrsponding content or separately. PERM defines extensions to existing media formats, content delivery methods, and other communication protocols allowing for PERM ECMs to included with the content transfer or obtained through a separate transfer session. Protection Scope .. PERM defines three protection scopes: "zone", "device" and "user". UID(A) ............ The unique identifier of A. A can be a zone, device or user. The device UID() can be for CSoD and CSiD. The format of UID() is an alphanumeric string of 20 characters using only standard ascii values. For a zone, the string must begin with a "z", for a device the string must begin with a "d" and for a user the string must begin with a "u". PERM requires the UID() parameter in each device or user certificate. CERT(A) ........... Certificate of entity A. In PERM all certificates must be X.509 v3 format, signed by a Certificate Authority. PERM defines two basic types of certificates: device certificates represented by CERT(D) and user certificates represented by CERT(U). Currently PERM only allows certificates which contain RSA or DSA signatures. DN(A) ............. Represents the Distinguished Name of entity A. CA ................ Certificate Authority - A certifying entity capable of issuing certificates for PERM devices or users. Issuer(A) ......... CA which issued certificate of entity A. Entity A can be device, user or subordinate CA. Gildred, et al. Expires January 15, 2005 [Page 6] Internet-Draft PERM July 2004 Root(A) ........... The root CA of device or user A. Root(A) must be represented in the CA chain as a self-signed certificate. TA(A,B) ........... Trusted Authority between device or user A and B; a common certificate issuer between two peers (device or user). CRP(A) ............ A Certificate Request Payload of a device or user. A list of all DN(CA) of the device or user. CACH(A) ........... Certificate Authority chain for device or user A. EncAlg(A) ......... Represents the list of symmetric key encryption algorithms supported by device A. For example: AES_128_CBC and TDES_CBC8. CRL(CA) ........... A Certificate Revocation List from certificate authority CA. A CRL is a list of serial numbers of certificates which are revoked by CA. Nonce() ........... Random data used for protection from replay attacks. MsgType() ......... PERM message type; hex value of type is dislayed in parenthesis. StatCode ........... PERM status code in hexadecimal. Zone_Limit ........ Maximum allowed number of CSiDs in a zone. This number is determined by the ZM. Zone_Size ......... Current number of CSiDs in a zone. This number is maintained by the ZM. IV ................ Initialization Vector for a scrambling algorithm. The following notation conventions are defined for use in this document: Gildred, et al. Expires January 15, 2005 [Page 7] Internet-Draft PERM July 2004 [], {}, and || .... Encryption is represented by brackets [], signing is represented by braces {}, and concatenation is represented by bars ||. A comma delimited list of items within (), {}, [] represents that they are concatenated in listed order prior to processing. E[m, KZ] .......... Represents a message m which is encrypted using a symmetric zone key KZ. E[m, Pub_D] ....... Represents a message m which is encrypted using a device public key Pub_D. {m}SIGN(Priv_D) ... Represents a message m which is signed by using a device private key Priv_D. This notation signifies that the message is included before the signature. (B -> A): < m > ... Entity B sends message m to entity A. < m > ............. Represents that m is information which may be required in some cases. {A, B}HMAC(K) ..... Represents a keyed hashing authentication code on concatenated message A and B by using a symmetric key K. This notation signifies that the message is included before the HMAC. Parts of this document use the "C" programming language syntax to describe data structures [20]. All data is assumed to be transmitted in network or big-endian order. Gildred, et al. Expires January 15, 2005 [Page 8] Internet-Draft PERM July 2004 3. Device Roles In PERM there are two roles that a device may assume. They are: Content Source Device (CSoD) and Content Sink Device (CSiD). A PERM device may be capable of both the role of CSoD and CSiD. A CSoD is defined as a device which transmits protected content to another PERM device. A CSoD ensures that the content is protected using the appropriate encryption for it's intended recipient which could be a user, device or all devices in a PERM Zone. A CSiD is defined as a device which receives protected content from another PERM device. A PERM device may contain a region identifier, typically to signify the geographic region in which the device operates. The definition of the region identifier is provided in an annex of this document. Gildred, et al. Expires January 15, 2005 [Page 9] Internet-Draft PERM July 2004 4. Content Access Translation In addition to PERM functionality, a CSoD may have a non-PERM conditional access system and tuning or other data reception system which allows the device to receive non-PERM protected content from a content provider outside the zone. Such behavior would be bound by an agreement between the licensing authority managing the conditional access system and the certificate authority for the PERM CSoD. An example of such a device is a cable set-top box. This box has a conditional access system capable of decoding broadcast video content, and as a PERM CSoD it may also be able to retransmit this content to PERM CSiDs in the same PERM Zone. Such retransmission requires that the conditional access information be translated and repurposed to allow CSiDs in the same zone to access the content. A CSoD may also act as a CSiD. For example, a cable set-top box, acting as a home media server, may be able to collect content from other CSoDs in the same zone. Gildred, et al. Expires January 15, 2005 [Page 10] Internet-Draft PERM July 2004 5. Content Scrambling PERM defines a set of minimally required content scrambling formats to provide a base level of compatibility with the most commonly used conditional access systems. A PERM CSiD must support content de-scrambling using the following minimal set of scrambling formats: 1. DES_CBC 2. TDES_CBC 3. AES_CBC_128 A PERM CSoD is required to provide all available protected content in at least one of the required PERM CSiD scrambling formats, which in some cases may require that the CSoD be capable of re-scrambling some or all of the content before transmission to a CSiD. Gildred, et al. Expires January 15, 2005 [Page 11] Internet-Draft PERM July 2004 6. Removable Media A PERM CSoD may be capable of reading removable media which contain non-PERM copy protection methods specific to the media format. In such case a PERM CSoD may be authorized to move or copy such protected content to internal persistent storage or transmit such protected content to CSiDs in the same zone, provided that the copy protection information on the media allows such action. The CSoD would be required to translate the copy protection information prior to transmission to a CSiD in the zone. Such behavior would be bound by an agreement between the licensing authority managing the copy protection system for each format and the licensing authority for the PERM CSoD. Additionally, a PERM CSiD may be capable of recording to removable media which may have non-PERM copy protection capabilities specific to the media format. In such case the PERM CSiD may be authorized to record protected content to removable media, given that the PERM CURs of the content allow such action. The CSiD would be required to translate the PERM scrambling as well as the PERM ECM for that content into the copy protection format specific to that media type. Such behavior may be bound by an agreement between the certificate authority of the PERM CSiD and the licensing authority managing the corresponding copy protection system. Gildred, et al. Expires January 15, 2005 [Page 12] Internet-Draft PERM July 2004 7. Direct and Indirect Authentication When two peers (devices or users) are directly certified by the same CA (both device or user certificates are signed by the same authority), the direct certifier of both peers is known as the Trusted Authority (TA) between both peers. Each peer can authenticate the other by comparing its Issuer's certificate with the peer's. This type of authentication in PERM is called Direct Authentication. When two peers are not directly certified by the same CA, but they share a common certifier in their certificate chains, the common certifier is the TA. Each peer can validate the other by evaluating the other's entire chain of CAs. This type of authentication in PERM is called Indirect Authentication. The following is an example of Direct Authentication: CA(1) -> CERT(A) and CA(1) -> CERT(B) In this example the certificates of device A and B are both issued by the same CA. As both devices can authenticate each other simply by examining the other's issuer CA, Direct Authentication is possible. The following is an example of Indirect Authentication: CA(root) -> CA(1) -> CERT(A) and CA(1) -> CA(2) -> CERT(B) In this example device A and B share a TA, but their device certificates are not issued by the same CA. In this case Direct Authentication is not possible. Each device must examine the entire CA chain of the other in order to authenticate up to a common TA. It is not required that both peers authenticate up to a root (self-signed) certificate, only that they authenticate up to a common TA. A PERM device must support Direct Authentication and may additionally support Indirect Authentication. If a PERM device does not support Indirect Authentication, and the device attempts to authenticate another PERM device having a common TA, but their device certificates do not have the same issuer CA, then device authentication must fail in this case. Gildred, et al. Expires January 15, 2005 [Page 13] Internet-Draft PERM July 2004 8. Signatures PERM defines a set of minimally required signature methods to provide a base level of compatibility between PERM Devices. A PERM Device must support signatures using the following minimal set of methods. As well, a PERM Device must at least support the key sizes designated in parenthesis: o RSA (512, 1024) Gildred, et al. Expires January 15, 2005 [Page 14] Internet-Draft PERM July 2004 9. Key Exchange PERM defines a set of minimally required key exhange methods to provide a base level of compatibility between PERM Devices. A PERM Device must support key exchange using the following minimal set of methods. As well, a PERM Device must at least support the key sizes designated in parenthesis: o RSA (512, 1024) Gildred, et al. Expires January 15, 2005 [Page 15] Internet-Draft PERM July 2004 10. Content Usage Rights (CURs) Content Usage Rights (CURs) are standardized rights definitions in PERM. One CUR represents a single usage right such as "play" or "copy". Having standardized CURs enables interoperability between secure devices supporting a variety of protected content. Content originating outside a PERM Zone will most likely contain usage rights definitions native to the conditional access system of the content provider. If content which is protected using a non-PERM system from outside the PERM Zone is made available to PERM devices within the zone, the usage rights of that content must be translated into the standardized PERM format CURs. The list of PERM CURs and methods of translation between popular CA or CP systems is defined in Annex C of this document. Gildred, et al. Expires January 15, 2005 [Page 16] Internet-Draft PERM July 2004 11. Entitlement Control Message (PERM ECM) PERM defines a PERM Entitlement Control Message (PERM ECM). Each protected content item is associated with a corresponding PERM ECM or set of PERM ECMs. When a PERM CSoD transfers protected content to a PERM CSiD via a PERM supported content request method (CRM), the content is usually encrypted and accompanied by a PERM ECM. The PERM ECM contains the content key, the CURs of the content and the ECM signature or HMAC. There are three types of PERM ECMs: Zone, Device and User. The PERM Zone ECM is authenticated using the corresponding PERM Zone key and message authentication function SHA-1. The PERM Device and User ECMs are always signed using the CSoD private key. In a PERM Zone ECM the content key, KC, is encrypted using the PERM zone key. In a PERM Device or User ECM the content key is encrypted using the corresponding device or user public key using the RSA or DSA method (for DSA encryption see Annex F: DSA Certificates) of encryption. The KC life time, TZ, is recommended to be at least 86400 seconds (24 hours). TZ may be changed at any time by the ZM. Each ECM is associated with a PERM Profile (Z, D or U), which determines the content protection scope. A PERM device must support at least one profile and may support up to all three. A PERM ECM must be formatted in one of two possible schemes: Long and Short. The Long ECM is used when CURs are intended to be included with the ECM. If a content item has only one corresponding ECM, then its ECM must be a Long ECM. If a content item has multiple ECMs, as in the case where the content key changes periodically during content transfer, the first ECM received during content transfer must be a Long ECM, and subsequent ECMs may be Short. If the CURs should change during the course of a content transfer, a Long ECM must be transmitted with the content to provide the CURs to the receiving CSiD. The following is the format of a Long ECM: 1. Header 2. Encrypted content scrambling key 3. CURs 4. 5. 6. ECM HMAC or Signature In the case of RSA certificates: If the content request uses Profile Z, KC is encrypted using KZ. If the content request uses Profile D, KC is encrypted using or the CSiD's Pub_D. If the content request uses Profile U, KC is encrypted using or the CSiD's Pub_U. Gildred, et al. Expires January 15, 2005 [Page 17] Internet-Draft PERM July 2004 In the case of DSA certificates: KC is generated according to section Annex F: DSA Certificates of this specification. A more detailed description of the PERM ECM is described in Annex C: PERM ECM. The following is the format of a Short ECM: 1. Header 2. Encrypted content scrambling key A Long ECM is authenticated according to the profile used in the content request. In Profile Z a Long ECM is authenticated by the zone key HMAC; in Profile D and Profile U a Long ECM is signed by the CSoD's Priv_D. A Device ECM has the following format: {ECM Header, encrypted KC, CURs, CACH(), CERT()}SIGN(Priv_D) If Indirect Authentication is supported, then the chain of CACH() must be included inside the Device or User ECM. A Zone ECM has the following format: {ECM Header, encrypted KC, CURs}HMAC(KZ) Profile U, D and Z are described in more detail in the following sections. Gildred, et al. Expires January 15, 2005 [Page 18] Internet-Draft PERM July 2004 12. Profile D: PERM Device ECM This section describes the method of content protection for device access. 12.1 Device Authentication Device authentication is a process of establishing the legitimacy of another device before allowing access to requested content. User authentication is necessary if a device supports Profile D and must restrict access to content to a specific device. Device authentication is performed by a PERM CSoD upon receiving a Profile D content request. The CSoD authenticates the credentials of the requesting CSiD upon receiving the device-signed content request. The specific procedure for device authentication is defined in more detail later in this document. 12.2 Device Content Protection Device content protection is provided in the case where a CSiD sends a content request using Profile D. In response to such a content request, the CSoD transmits the content to the CSiD, protected using a PERM Device ECM. During content reception the CSiD's private key must be available to the CSiD for processing the ECM(s) in order to de-scramble the content. In PERM devices are not always bound to a zone, or if bound to one or many zones a device may choose to request content from a CSoD outside all zones. As such, Profile D may allow protected content to be accessible to a device which is not a member of any zone. The following figure describes a Profile D content request. Device A: CSoD Device B: CSiD {MsgType(0xA1), Protection_mode, , EncAlg(B), EDM_value, , CERT(B)} SIGN(Priv_B) <----------------------------------- Figure 1: Content Request, Prof D (MsgType 0xA1) Device B: CSiD makes a "Content Request" using Profile D. The request is made using a PERM supported content request method (CRM). The CRM is extended to include a PERM message payload section (PMP); see Appendix K for a detailed description of PERM supported CRMs and Gildred, et al. Expires January 15, 2005 [Page 19] Internet-Draft PERM July 2004 the method of including PERM message payloads for each. Included in the PERM message payload section is a list of supported encryption algorithms, CERT(B) and protected by device B signature. If Indirect Authentication is supported, then the chain of must be included inside the "Content Request" message. Device A: CSoD verifies validity and authenticity of the "Content Request" by doing the following: verifies incoming message signature; compares requested scrambling algorithms with its own algorithms and chooses first matching one from the EncAlg(B); and verifies the Cert (A) validity. If message is valid and well formatted, then CSoD generates ECM by above described manner, encrypts content key by device B public key signed all ECM and encrypts the content. Device A: CSoD {ECM Header, E[KC, Pub_B], CURs, CACH(A), CERT(A)}SIGN(Priv_A), E[Content, KC], Padding If validation is not successful, the CSoD sends an "Status Notification" with the corresponding status code. If Indirect Authentication is supported, then CACH(A) must be included in the Device ECM. Device B: By receiving ECM device B verifies validity and authenticity of ECM. If it passes then decrypts the content protection key and decrypts all content. Gildred, et al. Expires January 15, 2005 [Page 20] Internet-Draft PERM July 2004 13. Profile U: PERM User ECM This section describes the method of content protection for user access. 13.1 User Authentication User authentication is a process of establishing the legitimacy of a user before allowing access to requested content. User authentication is necessary if a device supports Profile U and must restrict access to content to a specific user. User authentication is performed in two phases. Phase I: A PERM CSiD authenticates the user by requiring secret user information prior to making a content request. Phase II: A PERM CSoD authenticates the user's credentials upon receiving the user-signed content request from the CSiD. The specific procedure for user authentication is defined in more detail later in this document. 13.2 User Content Protection User content protection is provided in the case where a CSiD sends a content request using Profile U. In response to such a content request, the CSoD transmits the content to the CSiD, protected using a PERM User ECM. During content reception the user's private key must be available to the CSiD for processing the ECM(s) in order to de-scramble the content for the user. In PERM users are not bound to a device or zone. As such, Profile U may allow protected content to be accessible to a user across multiple devices in different zones. Before sending a "Content Request", the CSiD must perform Phase I user authentication. In Phase I the CSiD must check that the user is certified by a common TA (via indirect or direct authentication). The user certificate may be located on a smart card or stored in secure memory on the CSiD or obtained from an authentication service. Optionally the CSiD may require that the user provide a pass code which matches the one stored on the CSiD or smart card. If a smart card is used by the CSiD, the method of communication between the CSiD and the smart card must adhere to the PKCS#11 standard. If an authentication service is used by the CSiD, the authentication service must verify the user identity by requesting a user password. After successful Phase I user authentication, the following content request scenario is possible. Device B sends a "Content Request". The request contains a PERM message payload section with MsgType value indicating a Profile U content request, the set of supported Gildred, et al. Expires January 15, 2005 [Page 21] Internet-Draft PERM July 2004 encryption algorithms for Device B and the user certificate. The entire message is signed using Priv_U obtained in Phase I user authentication. If Indirect Authentication is supported, CACH(U) must be included inside the "Content Request" message. The following figure describes a Profile U content request. Device A: CSoD Device B: CSoD/CSiD {MsgType(0xA2), Protection_mode, , EncAlg(B), EDM_value, , CERT(U)} SIGN(Priv_U) <--------------------------- Figure 2: Content Request, Prof U (MsgType 0xA2) Upon receiving the content request, the CSoD performs Phase II user authentication by verifying the user signature in the PERM message and checking that the user is certified by a common TA. If the CSoD supports Profile U and successfully authenticates the user request, then the response provides the content to the CSiD with user content protection. The processing of a Profile U content request and a Profile D content request is identical; only the certificates and the MsgType are different. A CSoD capable of Profile D is logically capable of Profile U and vice versa. Having different MsgType values for Profile U and Profile D content requests allows the CSoD to decide to handle the request differently for a user or reject the request altogether. Gildred, et al. Expires January 15, 2005 [Page 22] Internet-Draft PERM July 2004 14. Profile Z: PERM Zone ECM This section describes the method of content protection for a PERM Zone. 14.1 PERM Zone As user's rights to content typically fall within the zone of a personal work area or living area such as a home, the concept of a PERM Zone is useful. A PERM Zone is not restricted to physical boundaries. The definition of a PERM Zone is the following: A PERM Zone is a set of devices with common network connectivity, authenticated by the same trusted chain or authority and a common secret key, which we call, the zone key. Only a CSoD can create a PERM zone. A PERM Zone may contain several CSIDs and CSoDs. It is not recommended to use more than one CSoD per zone, as this requires more complex Zone Master management described later in this document. When a device joins a PERM zone its membership in the zone is bound to a role: CSiD, CSoD or both. If a device's certificate device_type is CSiD/CSoD (see section on X.509 certificates later in this document), then it must choose to join the zone as a CSiD only, a CSoD only, or as both. A device which is not defined to be a CSiD or CSoD/CSiD in it's certificate device_type, must not attempt to join a zone bound to the role of CSiD. Similarly, a device which is not defined to be a CSoD or CSoD/CSiD in it's certificate device_type, must not attempt to join a zone bound to the role of CSoD. The join request specifies in the device_role field which role the joining device chooses to use as a member of the zone. The join request is described in more detail later in this document. In a PERM Zone all devices used for playback or recording must be authenticated by at least one other device from the same PERM Zone. Other authentication requirements may exist as defined later in this document. A method for allowing users to be bound to a PERM Zone is not currently defined; however, such a mechanism is not prohibited. The zone key is generated by CSoD. The zone generator device is the initial Zone Master (ZM) for the zone. The ZM takes responsibility for distributing and renewing the zone key. The zone key is a randomly generated key (See Appendix G), which is used between the CSoD and CSiD/CSoD to authenticate a content protection session, to encrypt content protection key, to broadcast or multi-cast contents. Only the CSoD can generate the zone key. The zone rights are provided by ZM along with content. Every device (CSoD/CSiD) can join to zone if device is authenticated Gildred, et al. Expires January 15, 2005 [Page 23] Internet-Draft PERM July 2004 by ZM and has a common set of encryption algorithm. The sequence of messages, for joining a zone, between ZM and CSoD/ CSiD has the following form: 1. (CSoD/CSiD -> BCAST): 2. (ZM -> CSoD/CSiD): 3. (CSoD/CSiD -> ZM): 4. (ZM -> CSoD/CSiD): This sequence of messages is divided by two parts: Zone Device Authentication and Zone Membership. These parts are described in more detail in the following sections. 14.2 Complex Zone A Complex Zone is a PERM Zone which contains more than one CSoD. In this case, the Zone Master must be managed more carefully, as more than one device in the zone is capable of assuming the ZM role. Mechanisms for a CSoD to join an existing zone, as well as negotiate to become the ZM are defined later in this document. A CSoD is not required to support Complex Zones. If a CSoD does not support complex zones, then it always assumes it is the Zone Master, and it must reject another CSoD's request to join the same zone. A CSoD supporting Complex Zones is also called a CSoD-CZ. CSiDs must support Complex Zones. 14.3 PERM Message Transport PERM messages for zone management are transferred via the User Data-gram Protocol (UDP), using a port number assigned by the IANA for such purpose. For unicast messages, retransmission is attempted if no response is received within 1 second. This may be repeated no more than 2 times, for a total maximum of 3 transmission attempts per message. 14.4 Zone Device Authentication Every PERM device must have an on-board device CERT() and private key in secure storage (smart card or embedded memory). As well, every PERM device must have an on-board copy of all current certificate revocation lists (CRLs) which have been passed to the device by CA through TFTP or by another authenticated PERM device. The CRL is signed by a CA , and its size is limited to 1 Megabyte. The CRLs must also reside in secure storage. The methods of providing secure storage in a PERM device are defined in section "Robustness Rules". A device capable of being a PERM CSoD or CSiD must be able to authenticate itself to another PERM device in a zone if it wishes to Gildred, et al. Expires January 15, 2005 [Page 24] Internet-Draft PERM July 2004 be added to the same zone. This requires that a PERM device have a private key that is unique to the device, a certificate signed by a common CA or one of the subordinate CAs (Indirect Authentication). The following is a scenario of zone device authentication. Device A represents a new device that is not part of a zone. Device B represents CSoD device currently being a ZM. A new zone device authentication protocol has the following form: Device A: CSiD Device B: CSoD (ZM) {MsgType(0x01), , , CERT(A)}SIGN(Priv_A) -----------------------> {MsgType(0x02), EncAlg(B), Zone_Limit, Zone_Size, UID (zone), , , CERT(B)}SIGN(Priv_B) <----------------------------- Figure 3: Discovery Hello and Response (MsgType 0x01, 0x02) Device A: If Device A is a CSiD, upon connection to a network interface, it requests to any PERM device on the local network to identify itself and any zones. A CSoD supporting Complex Zones will do the same. The method discovery is as follows: Device A (CSiD or CSoD-CZ) broadcasts MsgType(0x01) "Discovery Hello" to all devices. The "Discovery Hello" message contains the message header, the CRP payload contains all device certificate Issuer DNs. If the device has only one CA, then CRP(A) can be omitted. Whole message is sent along with CERT(A) and is signed by the device private key. If Indirect Authentication is supported, then CACH(A) must be included inside the "Discovery Hello" message. Device B: The zone is limited by manufactured set value Zone_Limit of zone generator device. The device B (ZM) verifies incoming message authenticity, by verifying message signature and Cert (A) using its' own CACH(B), tries to find the certificate based on CRP(A) list. If one of these operations fails, then device B drops received message. Otherwise Device B generates "Discovery Response". The "Discovery Response" contains message header, the zone encryption algorithm, the Gildred, et al. Expires January 15, 2005 [Page 25] Internet-Draft PERM July 2004 Zone_Limit, the Zone_Size (current number of CSiDs in the zone), zone identification number - UID(zone), Device B's CAs Issuer DN- chain and CERT(B). CERT(B) is chosen based on the CRP(A) list (lowest match in the chain). If the device has only one CA then CRP(B) can be omitted. The "Discovery Response" message is signed by the Priv_B. If Indirect Authentication is supported, then CACH(A) must be included inside the "Discovery Hello" message. Device A: Examines "Discovery Response" messages. If no responses are received within 3 seconds and device A is a CSoD, then it creates a new zone (or first prompts the user to create a zone, then creates it). Creating a new zone is simply creating a zone key, KZ, for the zone. A zone key is a 32-bytes random number. The size of zone key depends on zone encryption algorithm type. See Table 10 Encryption algorithm and key length correspondence for zone key sizes. The remaining bytes of zone key must be set to 0x00. If device A is a CSiD, then above described actions must be skipped and when the response is received, Device A verifies a message validity and authenticity. Authentication of Device B is performed by verifying the entire received message signature and CERT(B) using its own CA chain. By continuing "Discovery Response" message verification, Device A verifies message validity, compares zone encryption algorithms with its own list. If there is a match then it checks Zone_Size is less than Zone_Limit. If yes, device A checks if it has a certificate from CRP(B) list. If yes, "Join Zone Request" is generated. If any of the above checks fail then Device A must discard "Discovery Response" message. If Indirect Authentication is supported, then CACH(B) must be included inside the "Discovery Response" message. All messages are signed according to [19] and [15] for RSA and DSS signature respectively. The MsgType of device authentication protocol is defined in more detail in Annex A: MsgType Header Description. Subsequent actions are described in the following section. 14.5 Zone Membership Device A: After verifying and authenticated the device B's "Discovery Response", it considers the zone available, but not yet valid. This Gildred, et al. Expires January 15, 2005 [Page 26] Internet-Draft PERM July 2004 procedure is done for each response. If many responses are provided for each zone, then only the first response for each zone should be examined, the remaining responses for each zone may be ignored. If more than one zone is found, the device selects a zone to join (or prompts the user to select one). Zone membership protocol has the following form: Device A: CSoD/CSiD Device B: CSoD {MsgType (0x03), UID (zone), device_role, , Cert (A)} SIGN(Priv_A) ---------------------------> {MsgType (0x04), UID(zone), E[KZ, Pub_D], TLT, , Cert (B)}SIGN(Priv_B) <----------------------------- Figure 4: Join Zone Request and Response (MsgType 0x03, 0x04) Device A: Sends a MsgType(0x03) "Join Zone Request" to Device B to get a zone key. The request contains message header, zone identification number UID (zone) and Device A's certificate CERT(A). The whole message is signed by the device private key Priv_D. If Indirect Authentication is supported, then the chain of has to be included inside the "Join Zone Request" message. Device B: Verifies the validity and authenticity of a "Join Zone Request" for a zone key by doing the following: verifies incoming message signature; and verifies the Cert (A)'s validity. Before doing any validation, the device B must check, if device_role is CSiD or CSiD/CSoD, and if to then checks to see if current number of zone devices is less than manufacture set value Zone_Size < Zone_Limit. Also if Device B does not support Complex Zones, then it checks to make sure that the device_role is neither CSoD nor CSoD/CSiD. If one of these conditions is not valid, then the CSoD must drop the "Join Zone Request" message and send an "Status Notification" with the corresponding status code (see Annex E) and no new devices can join the zone. If message is valid and well formatted, then Device A is considered a valid candidate to join the zone and Device B responds to Device A's request by MsgType(0x04) "Join Zone Response" and increments the Gildred, et al. Expires January 15, 2005 [Page 27] Internet-Draft PERM July 2004 current number of zone device Zone_Size by one. The response includes message header, zone ID and the zone key KZ, encrypted with Device A's public key. The "Join Zone Response" is sent along with KZ, lifetime and device B's certificate. A zone key lifetime TLT is defined by the following way TLT = TZ-TE , where TZ is a manufacture set or user modified zone key lifetime and TE is a elapsed time starting from the zone key generation time or renewal time. The whole message is signed. If "Join Zone Request" doesn't pass one of the above verification, then Device B sends "Status Notification" with corresponding status code Appendix E. The "Status Notification" message has the following form: Device A: CSoD/CSiD Device B: CSoD {MsgType(0x08), StatCode, , CERT(B)} SIGN(Priv_B) <--------------------- Figure 5: Status Notification (MsgType 0x08) If Indirect Authentication is supported, then the chain of must be included inside the "Join Zone Response" message. Device A: Examines the "Join Zone Response" in the following manner: verifies the "Join Zone Response" message validity and authenticity. Checks the validity of Device B certificate, if valid then uses Device A's private key to decrypt zone key and stores the zone key in secured storage (smart card or embedded memory). Device A is now a member of the zone by virtue of having the zone key. A "Status Notification" with status code success informs Device B about becoming a new member of zone. No other device has a record of this membership, as membership is defined by the device having a copy of the zone key pair. It is recommended that no PERM device may have more than one zone key at a time. If a device contains a zone key, and requests to change its zone to another, and successfully negotiates to get the key pair for the new zone, then that device should erase the pre-existing zone key from secure storage immediately after saving the new zone key. Further robustness rules may be defined by the CA of the device to restrict changing zones too easily, for example, not more than once Gildred, et al. Expires January 15, 2005 [Page 28] Internet-Draft PERM July 2004 in a 30-day period. The device authentication protocol MsgType is defined in more detail in Annex A: MsgType Header Description. To avoid an anti-replay attack it is recommended to use methods described in [2]. Each authentication and zone membership message has message id in a message header. The message id can be converted into a counter. As in all counter-based anti-replay schemes, each side should keep a record of the last message id it received from the peer. The initiator uses 1 in "Discovery Hello" as his first message id, and he increments this value by 1 on each subsequent messages. The responder does the same, but he always sets the high bit of his message id to 1. This ensures that the initiator and responder can never generate the same value. PERM is protected from the man in the middle attack as well because all messages are signed. An attacker can intercept messages going between the two parties but it won't able to modify messages. 14.6 Zone Renewal The zone key has a lifetime, which is passed from the ZM along with encrypted zone key. This lifetime can be set at manufacturing time or can be changed by the user (depending on device capability). It is recommended to use 86400 seconds (24 hours). It is ZM's responsibility to regenerate the zone key upon expiration of the current zone key. It is recommended that the ZM regenerate the zone key 300 seconds before the current zone key expiration and broadcast "Update Membership" message to the entire zone. The "Update Membership" message has the following form: Entire Zone Device B: CSoD (ZM) {MsgType (0xA3), UID(zone), E[new KZ, old KZ],TZ, , Cert (B)} HMAC(old KZ) <---------------------------- Figure 6: Update Membership (MsgType 0xA3) Device B ZM broadcasts an "Update Membership" message to the entire zone. The message contains MsgType(0xA3), zone UID, new generated zone key (new KZ ) encrypted with the old zone key (old KZ ) using Gildred, et al. Expires January 15, 2005 [Page 29] Internet-Draft PERM July 2004 the zone encryption algorithm. The AES_128_ECB is used for distributing the zone key. The KZ is broadcasted along with lifetime TZ. and device certificate CERT(B). The entire message is authenticated by {"Update Membership"}HMAC(old KZ). If Indirect Authentication is supported, then the chain of must be included inside the "Renew All Membership" message. By receiving the "Update Membership" message, all devices must verify message authenticity. If message is valid and device belongs to the same zone, then the zone key should be decrypted and renewed. Zone member devices can make a new request to the ZM to renew device membership (get a new zone key) at the zone key expiration time, if they do not receive an "Update Membership" message for some reason. This new request is called a "Renew Membership" request. The "Renew Membership" request and response are protected by signature. This message has the following form: Device A: CSoD/CSiD Device B: CSoD (ZM) {MsgType (0x05), UID( zone), , Cert (A) } SIGN(Priv_A) ------------------------> Join Zone Response <-------------------------- Figure 7: Renew Membership (MsgType 0x05) Device A: Sends a "Renew Membership" request message. The request contains a message type MsgType(0x05), UID(zone), device certificate CERT(A) and the entire message is signed by device private key. If Indirect Authentication is supported, then the chain of must be included inside the "Renew Membership" request message. Device B: By receiving MsgType(0x05) ZM checks the message validity and authenticity by verifying message signature, verifies certificate validity. The ZM must verify if device A previously belong to the zone. If all validations are successful, then Device B sends a "Join Zone Response" message, which is defined in section Zone Membership. Otherwise, it sends an "Status Notification" message with corresponding status code and Device A will be out of zone. Gildred, et al. Expires January 15, 2005 [Page 30] Internet-Draft PERM July 2004 Device A: By receiving "Join Zone Response" device checks message validity and authenticity by verifying signature and certificates validity. If message is well formatted and all verifications are passed, device decrypts a new zone key and stores it in secure storage (smart card or embedded memory). If the ZM is physically removed from the zone or turned off, then upon the next zone key expiration time, if a zone member device send a "Renew Membership" request and subsequently does not receive a "Renew Membership" response within the timeout period, the device must disable its copy of the zone key, effectively removing itself from the zone. If the device is a CSoD-CZ, then upon "Join Zone Response" or "Renew Membership" response timeout the CSoD must send a "Negotiate Zone" message which includes a new randomly generated UID(zone) value and listen for other "Negotiate Zone" messages from other CSoDs for 1 second. If the CSoD receives a "Negotiate Zone" message (which is signed by the device private key) within the one second period, it must remember the UID(zone) value from each. At the end of the 1 second period the highest UID(zone) value is determined between all received UID(zone) values and its own new UID(zone) value. The "Negotiate Zone" message has the following form Device A: CSoD Old Zone { MsgType(0x06), UID(new zone), , CERT(A)} SIGN(Priv_A) ------------------------> Figure 8: Negotiate Zone (MsgType 0x06) If its own value is the highest of all, then the CSoD assumes that it is the new ZM and sends a "Renew Zone" broadcast message. If its own value is not the highest, then it assumes that another device is the new ZM and it waits for a "Renew Zone" message from the new ZM, and all devices previously in the zone send a "Join Zone Request" to re-join. 14.7 Zone Merging It is possible that 2 zones can merge together. The one of the initiator zone devices (CSoD or CSiD) must broadcast the "Discovery Hello" message and gets back a "Discovery Response" messages from the Gildred, et al. Expires January 15, 2005 [Page 31] Internet-Draft PERM July 2004 different ZMs . After verifying "Discovery Response" messages and choosing to which zone to join, initiator zone device broadcasts "Renew Zone" message to entire zone (see Figure 7 Renew Zone Message). Choosing a new ZM must be done by considering the new ZM Zone_Limit, Zone_Size and CACH. It is possible, that some of the devices which were in the initiator zone cannot be included in the new zone, if they do not have a common CA with the new ZM, or the new ZM limits the total number of zone devices. Only CSiD and CSiD/CSoD must join to the new zone. The old ZM (CSoD) will be out of merged zone and must keep its zone key. The "Renew Zone" message must contain UID(old zone) matching the current zone ID and UID(new zone) matching the ID of the zone to which it wants to join. The message also contains IP address of the new zone ZM. The entire message is protected by {"Renew Zone"}HMAC(zone key), where the zone key is a current zone key. When initiator zone devices receive "Renew Zone" message and verify message validity, they must send "Join Zone" message to the new ZM. The sequence of messages is as follows: 1. (CSoD/CSiD from Zone A -> Zone B): <"Discovery Hello"> 2. (Zone B -> CSoD/CSiD from Zone A): <"Discovery Response"> 3. (CSoD/CSiD from Zone A -> Zone A): <"Renew Zone"> 4. (All devices from Zone A -> ZM of Zone B): <"Join Zone"> The "Renew Zone" message contains the following: Device A: CSoD (New ZM) Old Zone {MsgType(0x07), EncAlg(A), UID(old zone), UID(new zone), ZM address, , Cert (A)} SIGN(Priv_A) ---------------------------> Figure 9: Renew Zone (MsgType 0x07) MsgType is the message type defined in Annex A: MsgType Header Description, EncAlg(A) is a set of encryption algorithms, UID(old zone) and UID(new zone) is an old and new zone IDs, ZM address is a 64 bit number, which usually will be an IP address of new ZM, CERT(A) is new ZM certificate. The entire message is signed by new ZM private key Priv_A. If Indirect Authentication is supported, then the chain of Gildred, et al. Expires January 15, 2005 [Page 32] Internet-Draft PERM July 2004 must be included inside the "Renew Zone" message. When the ZM is turned on again or physically reconnected to the network, it sends a "Discovery Hello" message first to see if any ZM have assumed control over its zone. If not, then it sends a "Renew Zone" broadcast message. 14.8 Zone Content Protection In the case where protected content originates from outside the PERM Zone, a PERM CSoD may serve as an acquisition point for this content. The CSoD may provide the acquired content to the entire PERM Zone. This CSoD must include a conditional access system authorized by the content provider in order to properly decode the content received from the provider. An example of a content provider could be a cable MSO, satellite TV provider, or Internet content provider. To get content, a PERM CSiD makes "Content Request". If CSiD wants to make content available to the entire zone, then it must use zone Profile Z, with MsgType(0xA0). In Profile Z a "Content Request" has the following form: Device A: CSoD Device B: CSiD {MsgType(0x09), Protection_mode, , EncAlg(B), UID(zone), EDM_value, , CERT(B)} HMAC(KZ) <------------------------------------- Figure 10: Content Request, Prof Z (MsgType 0x09, 0xA0) Device B: CSiD makes a "Content Request" using HTTP Get Request. The "Content Request" message can be set into the request-header. This field allows CSiD to pass additional information to CSoD which contains a list of supported encryption algorithms, UID of zone, CERT(B), all protected by a zone key HMAC. If Indirect Authentication is supported, then CACH(B) must be included inside the "Content Request" message. Device A: CSoD verifies message validity and authenticity by calculating {"Content Request"}HMAC(KZ); compares the requested scrambling algorithms with its own algorithms and chooses the first matching one from the EncAlg(B); checks requester certificate validity and checks device CUR's in content directory by using UID(B) Gildred, et al. Expires January 15, 2005 [Page 33] Internet-Draft PERM July 2004 from the certificate. CSoD discards the "Content Request" and sends "Status Notification" with the corresponding status code to CSiD, if CURs don't allow for this request or one of the above verification doesn't pass. Otherwise, it is possible to have the scenarios listed in the following subsections. 14.8.1 Protected Mode If the protected content originates outside the PERM Zone, and the content is not encrypted by the content provider, then CSoD must does the following actions: 1. Generates content key KC. The size of KC depends on encryption algorithm type. For example, TDES requires a 24 - bytes length key, for AES [14] it can be 16, 24 or 32-bytes length. KC is generated by a random number generator; 2. Encrypts the content key using method corresponding to the algorithm appropriate for the type of peer end certificate. For example, if the peer end certificate contains an RSA public key then KC is encrypted using the RSA encryption method. If the certificate contains a DSA public key then KC is encrypted by the method described in section Annex F: DSA Certificates; 3. Generates the ECM, encrypts KC by using the requester's RSA public key, obtained from CERT(B). The entire ECM is protected by zone key {ECM}HMAC(KC); 4. Padding is used to make an unencrypted content to multiple of encryption block size. TDES has a 8-bytes block size length, AES has a 16- bytes block size length and respectively the padding length must be defined based on encryption algorithm type. As a padding mechanism can be used method defined in [16]. Device A: CSoD Device B: CSiD {ECM Header, E[KC, KZ], CUR's} HMAC(KZ), E[Content, KC], Padding ---------------------------------------> Figure 11: Content Delivery Device B: CSiD first calculates {ECM}HMAC(KZ) and compares it against the received value. If both values are the same, then the CSiD decrypts KC and uses it to decrypt the content. In this mode KC will remain valid for duration the session validity period, which can be defined by the manufacture or user. At KC Gildred, et al. Expires January 15, 2005 [Page 34] Internet-Draft PERM July 2004 expiration time the CSoD must generate a new session key. 14.8.2 Pass Through Mode If protected content is received by the CSoD from the content provider in encrypted form, then the content encryption is preserved if possible, and only the content's original ECM is replaced by a PERM Zone ECM. Replacing the ECM involves the following process: 1. Compare content requester encryption algorithms with incoming ECM encryption algorithms and chooses first match; 2. If they match, then Decrypt the original ECM content key; Extract the content key and the usage rules; Translate the usage rules to the appropriate PERM CURs; Re-encrypt the content key; Calculate HMAC using the zone key; 3. If preserving the original content scrambling is not possible or the original content was not scrambled, then content must be encrypted using PERM compliant scrambling, and accompanied by a PERM Zone ECM. 14.8.3 Clear Mode CSiD can request content with a NULL encryption algorithm, which means CSiD requests the content in clear mode. If CURs allows passing the content in clear, then CSoD translates usage rules to CUR's format, generates ECM and transfers the content in clear mode, otherwise it sends "Status Notification" with corresponding status code. The clear content is sent along with Long ECM in first content transfer packet. After this, CSoD uses Short ECM for the following contents, if CUR's are the same. It switches to the Long ECM, when CUR's are changed. 14.8.4 Zone Broadcasting and Multicasting CSoD can broadcast or multi-cast content to whole zone or one of the zone devices can make content request for entire zone. To make content available to whole zone, CSoD must use Profile Z ECM. Only zone member devices can decrypt the content. First, CSoD randomly generates content protection key (see Protected Mode), then generates ECM, encrypts content with content key; and then content key is encrypted with zone key and entire content with zone ECM is broadcasted or multi-cast to whole zone as described in Protected Mode (see Figure 8 Zone ECM in Protected Mode). By receiving zone ECM, each zone member device first validates zone ECM: checks zone ECM HMAC, checks for well formatting and then Gildred, et al. Expires January 15, 2005 [Page 35] Internet-Draft PERM July 2004 decrypts the content key and decrypts the content. Gildred, et al. Expires January 15, 2005 [Page 36] Internet-Draft PERM July 2004 15. PERM Device Requirements Developers of PERM devices should include the unique PERM device key and X.509 v3 certificate. The device key pair must be unique to each device, and each device must also have a unique identifier (UID), which is unique across all PERM devices from any vendor. The CA's X.509 certificate should also be included in each device. A PERM device should include: 1. Priv_D 2. CERT(Device) 3. CERT(CA) or CACH() 4. Zone_Limit (CA imposed maximum allowed number of CSiDs in a zone) 5. TZ - Zone key life time (it is recommended to use 86400 seconds) Gildred, et al. Expires January 15, 2005 [Page 37] Internet-Draft PERM July 2004 16. Certification and Compliance Rules Device/implementation certification requirements of certificate authorities and applicable compliance and robustness rules are outside the scope of this specification. However, PERM is only as secure as the device which uses it. Third-party key licensing authorities supporting the PERM protocol would most likely include additional compliance rules for device certification. Such rules should ensure a significant barrier to circumvent or disable the security mechanisms provided by PERM and the certification program. Gildred, et al. Expires January 15, 2005 [Page 38] Internet-Draft PERM July 2004 17. Future Work 1. Support for Elliptic Curve (ECC) 2. Additional Content Request Methods (CRMs) 3. Additional ECM Delivery Methods (EDMs) Gildred, et al. Expires January 15, 2005 [Page 39] Internet-Draft PERM July 2004 18. Security Considerations The Cryptographic strength of PERM protocol is based on discrete logarithm and factorization problem on which the RSA and DSA algorithms are based. The proposed protocol uses a 1024-bit or larger size key for RSA and DSA, the cryptographic strength of which are approximately 2^86 or greater. Future versions of PERM will likely include the addition of elliptic curves which may greatly increase strength using much smaller numbers. PERM uses DES, TDES and AES symmetric algorithms for content scrambling. The strength of all keys are limited by the size of the output of the negotiated PRNG function. PERM uses PRNG based on SHA-1 as described in [15] Appendix 3. The security of this protocol is critically dependent upon the randomness of the randomly chosen parameters. These should be generated by a strong random or properly seeded pseudo-random source. See [17]. Implementors should take care to ensure that the use of random numbers for both keys and nonces is engineered in a fashion that does not undermine the security of the keys. PERM is protected against man-in-the-middle, impersonation and anti-replay attacks. 19 References [1] National Institute of Standards and Technology, "Recommendation for Block Cipher Modes of Operation", Document# SP800-38A, 2001. [2] Krywaniuk, A., "Using Isakmp Message Ids for Replay Protection", Internet Draft draft-krywaniuk-ipsec-antireplay-00, July 2001. [3] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [5] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, Gildred, et al. Expires January 15, 2005 [Page 40] Internet-Draft PERM July 2004 November 1996. [6] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", RFC 2048, November 1996. [7] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. [8] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners, "Hypertext Transfer Protocol -- HTTP/ 1.1", RFC 2616, June 1999. [9] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, July 2003. [10] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998. [11] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [12] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with the Session Description Protocol (SDP)", RFC 3264, June 2002. [13] National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 180-1, April 1995. [14] National Institute of Standards and Technology, "Advanced Encryption Standard", FIPS 197, November 2001. [15] National Institute of Standards and Technology, "Digital Signature Standard", FIPS 186, May 1994. [16] Atkinson, R. and S. Kent, "IP Encapsulation Security Payload (ESP)", RFC 2406, 1998. [17] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994. [18] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. [19] RSA Laboratories, "PKCS#1: RSA Encryption Standard", PKCS 1, Version 2.1, June 2002. [20] Srinivasan, R., "XDR: External Data Representation Standard", Gildred, et al. Expires January 15, 2005 [Page 41] Internet-Draft PERM July 2004 RFC 1832, August 1995. [21] Housley, R. and P. Hoffman, "Internet X.509 Public Key Infrastructure - Operational Protocols: FTP and HTTP", RFC 2585, May 1999. [22] International Telecommunications Union, "Information technology - Open System Interconnection - The Directory: Overview of concepts, models and services", ITU-R X.500, ISO/IEC 9594-1:1997, 1997. [23] International Telecommunications Union, "Information technology - Open System Interconnection - The Directory: Models", ITU-T X.501, IEC 9594-2:1997, 1997. [24] Housley, R., Ford, W. and D. Solo, "X.509 PKI certificate and certificate revocation list (CRL) Profile", RFC 2459, January 1999. Authors' Addresses John Gildred Pioneer 101 Metro Drive, Suite 264 San Jose, CA 95110 US Phone: +1 408 437 1800 EMail: john@pioneer-pra.com URI: http://www.pioneerelectronics.com/ Ashot Andreasyan Pioneer 101 Metro Drive, Suite 264 San Jose, CA 95110 US Phone: +1 408 437 1800 EMail: ashot@pioneer-pra.com URI: http://www.pioneerelectronics.com/ Gildred, et al. Expires January 15, 2005 [Page 42] Internet-Draft PERM July 2004 Roy Osawa Thomson EMail: roy.osawa@thomson.net URI: http://www.thomson.net/ Tom Stahl Thomson EMail: tom.stahl@thomson.net URI: http://www.thomson.net/ John Card Echostar EMail: john.card@echostar.com URI: http://www.echostar.com/ Gildred, et al. Expires January 15, 2005 [Page 43] Internet-Draft PERM July 2004 Appendix A. MsgType Header Description The following table explains general message header format, which is used in Device Authentication and Zone Membership protocols. 0 1 2 3 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MsgType | Version | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The following are the allowed MsgType values: Gildred, et al. Expires January 15, 2005 [Page 44] Internet-Draft PERM July 2004 Hex Definition ---- ---------- 0x00 Reserved 0x01 "Discovery Hello" - Broadcasted by device to authenticate itself, when it first connected to a network 0x02 "Discovery Response" - Response to "Discovery Hello" message 0x03 "Join Zone Request" - Request to join a zone 0x04 "Join Zone Response" - Sent by ZM in response to a "Join Zone Request" message 0x05 "Renew Membership" - Request to ZM renewing for zone key 0x06 "Negotiate Zone" - Sent by CSoD to negotiate a new zone 0x07 "Renew Zone" - Announce requirement for all zone devices to renew zone key 0x08 "Status Notification" - Used to inform peer end about status or result of the action 0x09 "Content Request Z" - for Profile Z, extends existing content request protocols such as HTTP 0xA0 "Content Request MZ" - for Profile Z for broadcast or multicast, extends existing content request protocols such as HTTP 0xA1 "Content Request D" for Profile D - Requests a content for a device 0xA2 "Content Request U" for Profile U - Requests a content for a user 0xA3 "Update Membership" - Broadcasted by ZM to entire zone for zone key updating 1. Version (1 byte)- PERM protocol version consists from major and minor portions. High four bits indicates the major version of the PERM protocol and low four bits indicates minor version. Implementations should never accept packets with a major version number larger than its own. Gildred, et al. Expires January 15, 2005 [Page 45] Internet-Draft PERM July 2004 2. Msg Length (2 bytes) - Total length of message including all message and signature. 3. Message ID (4 bytes) - This number is generated as described in [2]. It is used for anti-replay protection. For "Status Notification" case it is set to zero. Gildred, et al. Expires January 15, 2005 [Page 46] Internet-Draft PERM July 2004 Appendix B. PERM CURs Each ECM has a set of CURs. The following actions are defined for PERM CURs with consideration given toward alignment with similar rights defined in MPEG-21 Part 5 Multimedia Extensions. Each action may be restricted by the action parameters. The combination of an action with restriction parameters makes up one CUR. If any CUR is not included in the ECM or it is included without any parameter, then it is considered as having the "never" parameter. The following are the CUR actions defined in PERM and the bit positions of each in the CUR section of the ECM. Setting the bit position to 1 signifies that the action is allowed, and the action must be constrained by any action parameters. A value of 0 signifies that the action is not allowed, and any action parameters are ignored. Bit Action Definition --- ------------- ---------- 0 Play Display/render or convert to analog and output for display/render 1 Copy Record to non-removable persistent storage, leave original copy in tact 2 Move Record to non-removable persistent storage, erase original copy 3 Burn Copy Record to removable persistent storage, leave original copy in tact 4 Burn Move Record to removable persistent storage, erase original copy 5 Cache Keep partial or complete copy in temporary storage to enhance live viewing performance, no limit to cache size 6 Short Cache Keep partial or complete copy in temporary storage to enhance live viewing performance, limited cache size 7 Skip Ahead Jump ahead in the content sequence a short distance during viewing, for example 30 seconds 8 Ad Skip Remove or bypass embedded advertisements during a recording or viewing Gildred, et al. Expires January 15, 2005 [Page 47] Internet-Draft PERM July 2004 9 Replay Jump back in the content sequence a short distance during viewing to replay content 10 Pause Pause playback with or without freeze frame display 11 Fwd Scan Playback in forward direction faster than real-time 12 Rev Scan Playback in reverse direction real-time or faster 13 Fwd Slow Playback in forward direction slower than real-time 14 Rev Slow Playback in reverse direction slower than real-time 15 Fwd Frame Move one frame forward and pause 16 Rev Frame Move one frame backward and pause 17 Fwd Seek Move to a specified location forward in the content and begin/resume playback 18 Rev Seek Move to a specified location backward in the content and begin/resume playback 19 Delete Remove entire item from persistent storage 20 Modify Change content and save changes over previous version 21 Adapt Save a modified copy of the content 22 Extract Extract a portion of the content 23 Embed Insert data into the content 24 Enlarge Make the item larger 25 Reduce Make the item smaller 26 Execute Execute a run-time instance of the item 27 Print Render a physical representation of the content 28 Install Install components of item in order to allow usage Gildred, et al. Expires January 15, 2005 [Page 48] Internet-Draft PERM July 2004 29 Uninstall Remove components of item from system 30 Enable Make the item active for user interaction 31 Disable Make the item inactive for user interaction 32 Show Display the content item in as available 33 Hide Hide the content item obscuring its availability 34 Change Rights Change CURs to be more restrictive A CUR action is defined as a logical OR of the above mentioned actions. It is a 64-bit unsigned integer (uint64 cur_action). Each bit corresponds to one action. All parameters corresponding to allowed actions must be populated with valid data. The following parameters are applied to each action separately: o action_limit: Restricts content action by number if instances. o action_start: Action is allowed only after this time. o action_until: Action is allowed only before this time. action_limit is applicable only during the allowed period as defined by action_start and action_until. The following values are allowed for action_limit: Value Description -------- ----------- 0 Action may not occur, effectively same as action not allowed; 65535 Action may occur unlimited number of instances; 1-65534 Action may occur n number of instances. It is possible to create a 'blackout window' for an action by setting action_start later than action_until. This is allowed, however this configuration will result in the action being allowed indefinitely after action_start. action_start and action_until are in standard UTC 32-bit format (seconds since the midnight starting Jan 1, 1970, GMT) according to the CSoD internal clock. A value of all 0's for action_start is interpreted as infinitely in the past. A value of all 0's for Gildred, et al. Expires January 15, 2005 [Page 49] Internet-Draft PERM July 2004 action_until is interpreted as infinitely in the future. The format of action parameters is the following: struct { uint16 action_limit; unit32 action_start; unit32 action_until; }action_params; The following diagram illustrates the format of the CUR section of an ECM. 0 1 2 3 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | cur_expire_offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | cur_region | | ... | | ... | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | cur_action | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | action_params | | ... | | ... | | ... | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ cur_expire_offset defines the expiration time of the CURs in the ECM. It is sent only in a Long ECM, and it is applied to all CURs in that ECM. The CUR expiration time is defined as the beginning of the stream (set as time=0) increased by the cur_expire_offset. When the CUR expiration time is reached, the ECM is invalid and use of the content item must cease immediately. cur_expire_offset is a 32-bit unsigned integer containing the offset amount of time (always positive) in seconds. If the content stream contains a dynamic ECM (changing periodically throughout the stream), then each ECM only applies to the segment of the stream following the embedded ECM. In this case, the CUR expiration time is defined as the beginning of the stream segment where the current CURs were extracted (set as time=0) increased by Gildred, et al. Expires January 15, 2005 [Page 50] Internet-Draft PERM July 2004 the cur_expire_offset. For uninterrupted playback, in such a case, the cur_expire_offset must be long enough to allow for the next long ECM to arrive before expiration. In the case where viewing of the content is not time-base, such as an image, the CUR expiration time is defined as the start time of viewing (time=0) increased by the cur_expire_offset. This effectively limits the viewing time of the content by the number of seconds in cur_expire_offset. cur_region is an 8-bit unsigned integer representing region_type followed by an 11 byte string representing the applicable region of the CURs. Only one region may be defined per set of CURs. The cur_region field consist of the following format: struct { uint8 region_type; uchar11 region_data; }cur_region; The following region_types are defined: Value Type ----- ------------- 0 Reserved 1 PERM Standard Region - ISO 3166 2-character country code + up to 9 chars for postal code 2 GPS Location (4 bytes Longitude, 4 bytes Latitude, 3 bytes Altitude) 3 DVD Region (integer value 1-7) 4-253 Undefined 254 Vendor Defined Region Type Each action_params structure corresponds to each set action bit in big-endian format. The total number of action_params depends on number of active actions set bits in the cur_action. m times defines the number of action_params. Gildred, et al. Expires January 15, 2005 [Page 51] Internet-Draft PERM July 2004 Appendix C. PERM ECM There are two types of scheme for the PERM ECM: Long and Short. The Long ECM is always applied to the first content and when CURs are changed. After sending the Long ECM, CSoD switches to a Short ECM if CURs remain unchanged. A Long ECM has the following form: 0 1 2 3 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Content Key | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CURs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CERT() | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HMAC or SIGN() | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A Short ECM has the following form: 0 1 2 3 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Content Key | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The following subsections describe the ECM in more detail. C.1 ECM Header The ECM header has the following form: Gildred, et al. Expires January 15, 2005 [Page 52] Internet-Draft PERM July 2004 0 1 2 3 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope | Reserved | Version | Scheme | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length (including Header) | EncALg | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The ECM Header fields are defined as follows: o Scope (1 byte) - indicates ECM type: Zone, Device, User (see Table 8 Scope Values); o Reserved (1 byte) - Must be set zero; o Version (1 byte) - Defined in Annex A; o Scheme (1 byte) - Long or Short (see Table 9 Scheme Values); o Length (2 bytes) - Length of total ECM and content; o EncAlg (1 byte) - Defined in Section D: Encryption Algorithms and Mode; o Reserved (1 byte) - Must be set zero; o ECM Sequence Number (4 bytes) - Sequentially increasing 32-bit unsigned number [16]. This number is used by CSiD for preventing against anti-reply attack. It is mandatory and is always present even if the CSiD does not elect to enable the anti-replay service; o IV (8 or 16 bytes) - IV must be chosen by the CSoD in a manner that ensures that the same IV value is used only once for a given key. The length of IV depends on encryption algorithm type. If algorithm is TDES, then the length is a 8-byte, for AES length [1] of IV is a 16-byte. If NULL encryption is applied then 8 byte IV must be set to zero. The following defines ECM Header Type Values. Scope Value (Hex) -------------- ----------- Reserved 0x00 User ECM 0x01 Device ECM 0x02 Zone ECM 0x03 The following defines ECM Header Scheme values. Gildred, et al. Expires January 15, 2005 [Page 53] Internet-Draft PERM July 2004 Scheme Value (Hex) -------------- ----------- Reserved 0x00 Long 0x01 Short 0x02 C.2 Content Key The content scrambling key follows right after the Long or Short ECM Header. It is a randomly generated number and can be changed any time by the content provider. It is always sent with the ECM, encrypted by the CSiD public key. The key length depends upon the encryption algorithm type. The following table shows the correspondence between encryption algorithm type and key length. Encryption Algorithm Key Length (Bytes) --------------------- ------------------ NULL 8 DES 24 TDES CBC 24 AES CBC 128 16 AES CBC 192 24 AES CBC 256 32 If NULL encryption is applied then the 8-byte key and IV must be used and set to zero (0). C.3 CUR Section The CURs are defined in more detail in Annex B: PERM CURs. C.4 Certificate Authority Chain - CACH This field is conditional and can be omitted in the ECM if both ends share a common certification. If both ends support multiple Certificate Authorities then CAs must be exchanged for verifying certificates. The chain starts from a root certificate and ends with Gildred, et al. Expires January 15, 2005 [Page 54] Internet-Draft PERM July 2004 the issuer certificate. This field is used only in the case of Profile D or Profile U. C.5 Certificate - Cert This field contains the CSoD's X.509 v3 device certificate. It follows right after chain of authority's certificate. In more detail it is described in [24]. The certificate is transferred only for Profile D and U. C.6 ECM HMAC and Signature The HMAC [18] is applicable only for Profile Z, and it is calculated using SHA-1 [13]. This algorithm is fixed for HMAC calculation. The output of the HMAC is a 20-byte number. A Signature is applied only when using Profile D or U. The length of the signature depends on the CSoD certificate type. If the certificate contains an RSA key, then the [19] standard must be used for signature generation. If the certificate contains a DSA key, then the [15] standard must be used for signature generation. Gildred, et al. Expires January 15, 2005 [Page 55] Internet-Draft PERM July 2004 Appendix D. Encryption Algorithms and Mode The following table defines encryption algorithms vales used in Device Authentication, Zone Membership protocols and "Content Request" message. Encryption Algorithm Value (Hex) --------------------- ----------- NULL 0x00 DES 0x01 TDES CBC 0x02 AES CBC 128 0x03 AES CBC 192 0x04 AES CBC 256 0x05 Gildred, et al. Expires January 15, 2005 [Page 56] Internet-Draft PERM July 2004 Appendix E. Status Notification "Status Notification" informs a peer entity of success or status that has occurred during protocol processing. The "Status Notification" message has the following format: 0 1 2 3 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | StatCode | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CERT() | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SIg() | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Status Notification Message Header is described in Appendix A. The following status codes are used in a status message: enum{ success = 0x00, zone_is_full = 0x01, unknown_msg_type = 0x02, unknown_msg_format = 0x03, wrong_prot_version = 0x04, enc_alg_mismatch = 0x05, invalid_msg_id = 0x06, cert_revoked = 0x07, cert_expired = 0x08, unknown_ca = 0x09, no_room_in_zone = 0xa0, not_allowed_to join = 0xa1 }STAT_CODES; CACH - Chain of CA certificates. The CACH is used only for Indirect Authentication. CERT() can be omitted for initiator side, since it is in the third message of Zone membership, protocols and responder already has the initiator certificate public key for verifying "Status Notification" digital signature. Gildred, et al. Expires January 15, 2005 [Page 57] Internet-Draft PERM July 2004 SIGN() digital signature, generated over the message. This is used for verifying the integrity of the message and against non-repudiation services. Gildred, et al. Expires January 15, 2005 [Page 58] Internet-Draft PERM July 2004 Appendix F. DSA Certificates The above key distribution protocol requires that devices have an RSA type certificate (certificate contains RSA public key). If a device's certificate contains a DSA type public key, then some additional computations must be done to generate the zone key. The DSA [15] type of certificate contains deviceØs DSA public key Pub_A inside the CERT(A). When Device B receives "Join Zone Request" from device A, it does the following computations using DSA common parameters from requester certificate CERT(A). Generates 20-byte random number R(B) (1< R(B) < Q-1) and computes one time public number PN(B). Using device A DSA public key Pub_A from CERT(A), calculates shared secret key, SSK(B). (see description bellow) Then the PN(B) is sent to device A. The device A using PN(B) calculates the same SSK(A) as described bellow. Device A Device B DSA common parameters P,Q,G and Pub_A from certificate CERT(A) ---------> PN(B)=G^R(B) mod(P) <---------------------- SSK(B) = Pub_A^R(B) mod(P) SSK(A) = PN(B)^Priv_A mod(P) Figure 12: Key Exchange Using DSA Certificate Now both sides have the same shared number SSK(A) = SSK(B), which can be used to generate zone key. Depends on encryption algorithm type (see Table 10 Encryption algorithm and key length correspondence) the zone key must be taken first bytes (starting from LSB) of SSK. If algorithm type is TDES the weak key validation test must be done. If weak key is found then must be shift one byte and do the same. This mechanism allows generating the same shared secret key without using special key exchange payload. Gildred, et al. Expires January 15, 2005 [Page 59] Internet-Draft PERM July 2004 Appendix G. Random Number Generator A PERM device must use a pseudo random number generator (PRNG) based on SHA-1 as described in [17] Appendix 3 for all random number generation. The seed for PRNG must be set at manufacture time securely or must be generated using different timing of clocking speed, number of current processing being executing, etc. The seed must be stored in FLASH memory. Gildred, et al. Expires January 15, 2005 [Page 60] Internet-Draft PERM July 2004 Appendix H. X.509 v3 Certificates A PERM device must use only X.509 v3 certificates. Version 3 certificates are required as PERM uses private certificate extensions for device UID, device type, Zone_Limit, and device region. The PERM certificate extensions have the following structure. Struct { uchar8 uid [20]; uint32 dev_type; uint32 zone_limit; uint8 region_type; uchar8 region_data [11]; } PERM_DEV_ID The dev_type can be CSoD, CSiD or CSoD/CSiD. The device type values are defined in the following table. Device Type Value (Hex) ------------ ----------- Reserved 0x00 CSoD 0x01 CSiD 0x02 CSoD/CSiD 0x03 The uid is an alphanumeric string of 20 characters, which uniquely defines a device. The zone_limit is valid only for CSoD and CSoD/ CSiD type of devices and is set to Zone_Limit. For CSiD this filed is set zero. All these data are set by the CA and remains unchanged during device lifetime. region_type and region_data are described in a previous section of this document. Gildred, et al. Expires January 15, 2005 [Page 61] Internet-Draft PERM July 2004 Appendix I. CRL Request This section describes the standard method of requesting CRLs in PERM. Other standard and non-standard methods are allowed, however the methods described in this section must be supported by a PERM device. HTTP GET: A PERM device must support certification requests via HTTP GET as described in this section. The CRL request is simply an HTTP GET which includes a CRL-REQUEST extension-header containing the serial number of the CA certificate. The response to an HTTP GET CRL request contains the requested CRL in the format defined by content type application/pkix-crl [21]. Gildred, et al. Expires January 15, 2005 [Page 62] Internet-Draft PERM July 2004 Appendix J. Certification Request This section describes the standard method of requesting device or user Certification in PERM. Other standard and non-standard methods are allowed, however the methods described in this section must be supported by a PERM device. HTTP GET: A PERM device must support certification requests via HTTP GET as described in this section. The certification request is simply an HTTP GET which includes a PKCS10-REQUEST extension-header containing the Base64 encoded PKCS#10 message. The PKCS#10 message must be signed by the private key of the requesting user or device. As the request must come from a previously certified user or device, the request is always for re-certification. The response to an HTTP GET certification request contains the new certificate in the format defined by content type application/ pkix-cert [21]. Gildred, et al. Expires January 15, 2005 [Page 63] Internet-Draft PERM July 2004 Appendix K. Content Request Methods (CRMs) This section describes a basic set of PERM supported content request methods (CRMs) and a method for including PERM authentication information in each. The following request methods are allowed. HTTP GET CRM: A PERM CSiD and PERM CSoD must support the HTTP GET CRM as described in this section. This CRM is simply an HTTP GET which includes a PERM-CR extension-header containing the base64 encoded PERM message. Only PERM message types 0x09, 0xA0, 0xA1, 0xA2 may be used in the PERM-CR extension-header. The response to an HTTP GET CRM contains the requested content and corresponding ECMs via the requested EDM (see below for EDMs). RTSP CRM: A PERM CSiD and PERM CSoD may support the RTSP CRM as described in this section. This CRM is simply an RTSP DESCRIBE command which includes a PERM-CR extension-header containing the base64 encoded PERM message. Only PERM message types 0x09, 0xA0, 0xA1, 0xA2 may be used in the PERM-CR extension-header. The response to an RTSP CRM contains the requested content and corresponding ECMs via the requested EDM (see below for EDMs). Gildred, et al. Expires January 15, 2005 [Page 64] Internet-Draft PERM July 2004 Appendix L. Protection Modes This section describes a basic set of extensions to existing media formats, content delivery methods, and other communication protocols allowing for PERM ECMs to included with the content transfer or obtained through a separate transfer session. When sending a content request the CSiD must include the EDM value which describes the required EDM for the response. The following EDM values are allowed in a content request message. Protection Mode Value (Hex) --------------- ----------- Reserved 0x00 Protected 0x01 Passthru 0x02 Clear 0x03 Protected: This setting indicates that the CSoD may use one of the encryption algorithms which are supported by the requesting CSiD. A CSiD and CSoD is required to support Protected mode. Passthru: This mode indicates that the CSoD may use the original content encryption. The following content encryption configurations are allowed. A CSiD and CSoD is not required to support Passthru mode. Gildred, et al. Expires January 15, 2005 [Page 65] Internet-Draft PERM July 2004 Configuration Value (Hex) --------------- ----------- Reserved 0x00 DVB 0x01 US-Cable-Card 0x02 US-Cable-SA 0x03 US-Cable-MOT 0x04 DirecTV 0x05 ARIB 0x06 ATSC 0x07 XM 0x08 SIRIUS 0x09 The format of each configuration is defined by the relevant digital broadcast standards. More configuration types may be defined in the future to accommodate additional digital broadcast standards. Clear: This method should only be used if content encryption is not desired. A CSiD and CSoD is not required to support Clear mode. Gildred, et al. Expires January 15, 2005 [Page 66] Internet-Draft PERM July 2004 Appendix M. ECM Delivery Methods (EDMs) This section describes a basic set of extensions to existing media formats, content delivery methods, and other communication protocols allowing for PERM ECMs to be included with the content transfer or obtained through a separate transfer session. When sending a content request the CSiD must include the EDM value which describes the required EDM for the response. The following EDM values are allowed in a content request message. EDM Value (Hex) ------------ ----------- Reserved 0x00 HTTP Response 0x01 RTP 0x02 HTTP Response EDM: This method must be used when responding to an HTTP GET or POST. A CSoD is required to support HTTP Response EDM to a requesting CSiD. In the HTTP Response EDM, the HTTP response must be chunked encoded. The ECMs are inserted into the chunked payload byte stream periodically as separate chunks. The ECM is delimited by a 20-byte boundary value, a 2-byte sequence number, and a 1-byte content type. The HTTP header of the response must include parameters with the content type header. These parameters are used to define the section boundary value as well as the primary content type. The HTTP header of the response must include additional PERM extension headers. A PERM-Version header declaring the PERM version number, and one or more Subcontent-Type headers which define the various payload section content types and their corresponding labels (as used in the section content types). For example, an HTTP Response header may include the following headers. Content-Type: multipart/perm; primary-type=video/mpeg; boundary="34lkekho3404u0e34kjt" PERM-Version: 1.0 Subcontent-Type: video/mpeg; unit-length=176; label=aa Subcontent-Type: application/perm-ecm; scheme=long; unit-length=132; label=bb Gildred, et al. Expires January 15, 2005 [Page 67] Internet-Draft PERM July 2004 Subcontent-Type: application/perm-ecm; scheme=short; unit-length=88; label=cc In the example above, the content type includes two parameters: primary-type and boundary (represented as a 20-char string). The content type must be set to multipart/perm for PERM protected content. The unit length defines the length of each body part containing data of the corresponding subcontent type. A new subcontent type header is introduced which can include any MIME content type with associated parameters. The subcontent type header requires two additional parameters: unit-length (in bytes) and label which defines a 2-byte identifier (represented as a 2-char string) for the subcontent type. The above header example contains three subcontent types. One defines the video content stream, and two of them define the long and short ecms. The content type used for a PERM ECM is application/ perm-ecm. Application/perm-ecm requires a scheme parameter. Currently the scheme parameter may contain one of the following values: long or short. Below is an example of a byte stream (represented by ascii characters here for readability) which contains PERM ECMS according to the header example above. < beginning of bytestream > < anything before the first boundary is ignored > --34lkekho3404u0e34kjt0000bb <-- ( 1st Boundary ) 34kl5lk34j3jhkj34lj6234524k5h3k5j3kj53648w8eh <-- ( Long ECM ) 090d9g8w0r9t0v9et09g0aerg8a938rk2jhhr8sdd7gdf <-- ( ... ) 097t9ry2ijfhk34th98yw9v832r2ekfjwhe9i3i33se74 <-- ( ... ) --34lkekho3404u0e34kjt0001aa <-- ( 2nd Boundary ) 097t9ry2ijfhk34th98yw9v832riekfjwh98f8s74h3th <-- ( Video Data ) djr837xh0r9t0v9et09g0aerg8ga98rkhrtikw38d7gdf <-- ( ... ) 42y7gsfbv837234th98yw9v832ri2ewheii3rui33se74 <-- ( ... ) lkj4liw09f8wyuoti2h3lrjwepf9g34okfhgd98ryt983 <-- ( ... ) --34lkekho3404u0e34kjt0002cc <-- ( 3rd Boundary ) 34kl5lk34j3jhkj34lj62345235h3kj3kf09sd093a0e0 <-- ( Short ECM ) 090d9g8w0r9t0v9et09g0aerga938ry894wudv90fjs8u <-- ( ... ) --34lkekho3404u0e34kjt0003aa <-- ( 4th Boundary ) jwepf9ueg834okfhwlgidh83kj53648wef09sd0934ede <-- ( Video Data ) 090d9g8w0r9t0v9et09gerg8gatikwyf2eij38vhb8w72 <-- ( ... ) 097t9ry2ijfhk34th9w9v832ri2ey98sdfi3rui33see4 <-- ( ... ) 378hf83h9f8wyuoth3lrjwepf9ueg834okf478wfy738r <-- ( ... ) Gildred, et al. Expires January 15, 2005 [Page 68] Internet-Draft PERM July 2004 < end of bytestream > In the example above, the byte stream begins with the 20-byte boundary value (prefixed with "--"), followed by a 4-byte sequence number, then a 2-byte content type label and a CRLF (carriage return and line feed). Immediately following the CRLF is the long ECM, followed by the boundary for the next section, etc. Any data appearing after the HTTP headers and before the first boundary is ignored. An optional additional PERM-EIF header may be used in the HTTP response to indicate a location where the CSiD may retrieve an EIF (see next section about EIFs) containing ECMs for the content stream of the current session. The PERM-EIF contains a URI, as in the example below. PERM-EIF: http://hostname/path/filename.eif RTP EDM: This method must be used when responding to an RTSP PLAY or other RTSP command which results in the return of PERM protected content via RTP. A CSoD which supports an RTSP/RTP service is required to support RTP EDM to a requesting CSiD. In the RTP EDM, RTP packets containing PERM ECMs transmitted via a separate RTP streams. The payload type identifier for an RTP packet containing a PERM ECM must match that which is defined for the corresponding ECM type in the RTSP session description via SDP. The following is an example of an SDP session description which contains payload type definitions for PERM ECMs. Subcontent-Type Description (HTTP): ----------------------------------- application/perm-ecm; scheme=long; unit-length=132; label=97 SDP Payload Type Description (RTP): ----------------------------------- m=application 49170 RTP/AVP 97 a=rtpmap:97 perm-ecm a=fmtp:97 scheme=long In RTP the unit-length and label parameters are not needed as all ECMs for the content stream will be delivered in a separate RTP Gildred, et al. Expires January 15, 2005 [Page 69] Internet-Draft PERM July 2004 stream from the content stream with its own payload type. Synchronization between ECMs and the content stream can be achieved by using timing information carried in the RTP/RTCP packets for both. The SDP key field may also be used to indicate a location where the CSiD may retrieve an EIF (see next section about EIFs) containing ECMs for the content stream of the current session. The key type is a URI, as in the example below. k=uri:http://hostname/path/filename.eif Notes on media formats which contain ECMs: If a media format which contains ECMs, for example MPEG-TS with SCTE extensions for conditional access information), is retransmitted by a CSoD to a CSiD with PERM protection, then the ECM section in the media format should be removed before retransmission to the CSiD. This will ensure that the CSiD will not detect both the PERM ECMs and the media format ECMs, causing confusion as to which ECM is applicable. Gildred, et al. Expires January 15, 2005 [Page 70] Internet-Draft PERM July 2004 Appendix N. PERM Content Storage Methods (CSMs) This section describes a basic set of extensions to existing media formats and content storage methods for PERM ECMs to be included with the content when stored on recordable media. The ECMs listed here are intended as a baseline which may be applied to many different media formats. Other media format specific CSMs may be defined outside this specification. ECM Index File (EIF): This method places all ECMs related to a particular content stream into a separate file which contains all ECMs in the order that they are applied to the content stream. The file format of the EIF is the following. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Index Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CRLF | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1st Index Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1st ECM | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CRLF | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2nd Index Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2nd ECM | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CRLF | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3rd Index Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3rd ECM | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CRLF | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CRLF | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In the figure above the index type currently may have one of the following values. The length of the index values is always 32-bits. The format of the index values are determined by the index type. Gildred, et al. Expires January 15, 2005 [Page 71] Internet-Draft PERM July 2004 Index Type Value (Hex) Format of Index Values ------------ ----------- ---------------------- Reserved 0x00 NA Time Position 0x01 uint (seconds after start of stream) Byte Position 0x02 uint (bytes after start of stream) Binding of an EIF to a media file is possible by using the same file name as the media file for the EIF file, replacing the suffix with ".eif". The MIME content type for an EIF is application/perm-eif. 7-bit transports such as STMP should use Base64 transfer encoding. Gildred, et al. Expires January 15, 2005 [Page 72] Internet-Draft PERM July 2004 Appendix O. Acknowledgements The author gratefully acknowledges the contributions of other participants. Gildred, et al. Expires January 15, 2005 [Page 73] Internet-Draft PERM July 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Gildred, et al. Expires January 15, 2005 [Page 74] Internet-Draft PERM July 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Gildred, et al. Expires January 15, 2005 [Page 75]