Internet DRAFT - draft-gildred-perm
draft-gildred-perm
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. <CACH>
5. <Certificate>
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,
<Protection_config>, EncAlg(B),
EDM_value, <CACH(B)>, 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 <CACH(B)>
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,
<Protection_config>, EncAlg(B),
EDM_value, <CACH(U)>, 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): <Discovery Hello>
2. (ZM -> CSoD/CSiD): <Discovery Response>
3. (CSoD/CSiD -> ZM): <Join Zone Request>
4. (ZM -> CSoD/CSiD): <Join Zone Response>
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),
<CRP(A)>, <CACH(A)>,
CERT(A)}SIGN(Priv_A)
----------------------->
{MsgType(0x02), EncAlg(B),
Zone_Limit,
Zone_Size,
UID (zone), <CRP(B)>,
<CACH(B)>, 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,
<CACH(A)>, Cert (A)} SIGN(Priv_A)
--------------------------->
{MsgType (0x04), UID(zone),
E[KZ, Pub_D], TLT, <CACH(B)>,
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 <CACH(B)>
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,
<CACH(B)>, CERT(B)}
SIGN(Priv_B)
<---------------------
Figure 5: Status Notification (MsgType 0x08)
If Indirect Authentication is supported, then the chain of <CACH(B)>
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,
<CACH(B)>, 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 <CACH(B)>
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),
<CACH(A)>, 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 <CACH(B)>
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),
<CACH(A)>, 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,
<CACH<A)>, 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 <CACH(A) >
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,
<Protection_config>, EncAlg(B), UID(zone),
EDM_value, <CACH(B)>, 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| <CACH> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| <CACH> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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]
