IEC TS 62224:2007

IEC/TS 62224
Edition 1.0 2007-11
TECHNICAL
SPECIFICATION
Multimedia home server systems – Conceptual model for digital rights
management
IEC/TS 62224:2007(E)
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form
or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from
either IEC or IEC's member National Committee in the country of the requester.
If you have any questions about IEC copyright or have an enquiry about obtaining additional rights to this publication,
please contact the address below or your local IEC member National Committee for further information.

IEC Central Office
3, rue de Varembé
CH-1211 Geneva 20
Switzerland
Email: inmail@iec.ch
Web: www.iec.ch
About the IEC
The International Electrotechnical Commission (IEC) is the leading global organization that prepares and publishes
International Standards for all electrical, electronic and related technologies.

About IEC publications
The technical content of IEC publications is kept under constant review by the IEC. Please make sure that you have the
latest edition, a corrigenda or an amendment might have been published.
ƒ Catalogue of IEC publications: www.iec.ch/searchpub
The IEC on-line Catalogue enables you to search by a variety of criteria (reference number, text, technical committee,…).
It also gives information on projects, withdrawn and replaced publications.
ƒ IEC Just Published: www.iec.ch/online_news/justpub
Stay up to date on all new IEC publications. Just Published details twice a month all new publications released. Available
on-line and also by email.
ƒ Electropedia: www.electropedia.org
The world's leading online dictionary of electronic and electrical terms containing more than 20 000 terms and definitions
in English and French, with equivalent terms in additional languages. Also known as the International Electrotechnical
Vocabulary online.
ƒ Customer Service Centre: www.iec.ch/webstore/custserv
If you wish to give us your feedback on this publication or need further assistance, please visit the Customer Service
Centre FAQ or contact us:
Email: csc@iec.ch
Tel.: +41 22 919 02 11
Fax: +41 22 919 03 00
IEC/TS 62224
Edition 1.0 2007-11
TECHNICAL
SPECIFICATION
Multimedia home server systems – Conceptual model for digital rights
management
INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
PRICE CODE
V
ICS 33.160.60; 35.240.99 ISBN 2-8318-9361-5

– 2 – TS 62224 © IEC:2007(E)
CONTENTS
FOREWORD.4
INTRODUCTION.6

1 Scope.7
2 Normative references .7
3 Terms, definitions and abbreviated terms .7
3.1 Terms and definitions .7
3.2 Abbreviated terms .12
4 Notation .12
4.1 Numerical values.12
4.2 Notations for keys .12
4.3 Notation list .13
5 Requirements .13
5.1 Viewpoint of content user .13
5.1.1 Content usage environment .13
5.1.2 Content distribution services.15
5.1.3 Integrity of content.15
5.2 Viewpoint of rights holder .16
5.2.1 Overview of requirements for content protection .16
5.2.2 Licence service model .16
5.2.3 Threats and counter-measures .17
5.2.4 Evaluation criteria.19
6 Design considerations .19
6.1 Security model .19
6.1.1 Overview of security model.19
6.1.2 Secure licence transaction protocol (SLTP) model.20
6.1.3 Certification authority .21
6.1.4 Key revocation and termination of TREM .22
6.2 Interconnection model .22
6.2.1 Generic interconnection model .22
6.2.2 Licence relay protocol (LRP) model .24
6.2.3 Implementation model of inter-connection.25
6.3 Licence information model.26
6.3.1 Access conditions.26
6.3.2 Generic licence format (GLF) model .26
6.4 Protected content format (PCF) model.27
7 Issues to be standardized.27

Annex A (informative) Example of algorithms for cryptosystem and hash .28
Annex B (informative) Example of conversion of licence information in DRM based
upon SLTP into that of existing DRM .29

Bibliography.31

Figure 1 – Requirements in the target ubiquitous content usage environment .14

TS 62224 © IEC:2007(E) – 3 –
Figure 2 – Licence service model to consider the threats .17
Figure 3 – Example of protection level control.19
Figure 4 – Security model of content protection .20
Figure 5 – Basic procedure of SLTP model .21
Figure 6 – Overview of issuing TREM class certificates .22
Figure 7 – Revocation of certificates and termination of TREMs.23
Figure 8 – Generic interconnection model for content protection .23
Figure 9 – Implementation model of inter-connection .25
Figure 10 – Example of GLF structure.27
Figure B.1 – Example of static conversion of licence information .29
Figure B.2 – Example of dynamic conversion of licence information.30

Table 1 – Expression of numerical values .12
Table 2 – Notations used in this model .13
Table 3 – Threats and counter-measures in the licence service model.17
Table 4 – Types of access condition .26

– 4 – TS 62224 © IEC:2007(E)
INTERNATIONAL ELECTROTECHNICAL COMMISSION
___________
MULTIMEDIA HOME SERVER SYSTEMS –
CONCEPTUAL MODEL FOR DIGITAL RIGHTS MANAGEMENT

FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of IEC is to promote
international co-operation on all questions concerning standardization in the electrical and electronic fields. To
this end and in addition to other activities, IEC publishes International Standards, Technical Specifications,
Technical Reports, Publicly Available Specifications (PAS) and Guides (hereafter referred to as “IEC
Publication(s)”). Their preparation is entrusted to technical committees; any IEC National Committee interested
in the subject dealt with may participate in this preparatory work. International, governmental and non-
governmental organizations liaising with the IEC also participate in this preparation. IEC collaborates closely
with the International Organization for Standardization (ISO) in accordance with conditions determined by
agreement between the two organizations.
2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all
interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence
between any IEC Publication and the corresponding national or regional publication shall be clearly indicated in
the latter.
5) IEC provides no marking procedure to indicate its approval and cannot be rendered responsible for any
equipment declared to be in conformity with an IEC Publication.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees for any personal injury, property damage or
other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and
expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC
Publications.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of
patent rights. IEC shall not be held responsible for identifying any or all such patent rights.
The main task of IEC technical committees is to prepare International Standards. In
exceptional circumstances, a technical committee may propose the publication of a technical
specification when
• the required support cannot be obtained for the publication of an International Standard,
despite repeated efforts, or
• the subject is still under technical development or where, for any other reason, there is the
future but no immediate possibility of an agreement on an International Standard.
Technical specifications are subject to review within three years of publication to decide
whether they can be transformed into International Standards.
IEC 62224, which is a technical specification, has been prepared by IEC technical committee
100: Audio, video and multimedia systems and equipment.

TS 62224 © IEC:2007(E) – 5 –
The text of this technical specification is based on the following documents:
Enquiry draft Report on voting
100/1064/DTS 100/1117A/RVC
Full information on the voting for the approval of this technical specification can be found in
the report on voting indicated in the above table.
This publication has been drafted in accordance with the ISO/IEC Directives, Part 2.
The committee has decided that the contents of this publication will remain unchanged until
the maintenance result date indicated on the IEC web site under "http://webstore.iec.ch" in
the data related to the specific publication. At this date, the publication will be
• transformed into an International Standard,
• reconfirmed;
• withdrawn;
• replaced by a revised edition, or
• amended.
A bilingual version of this document may be issued at a later date.

– 6 – TS 62224 © IEC:2007(E)
INTRODUCTION
Due to the recent trends in the rapid popularization of mobile phones and the Internet, as well
as the realization of high-speed data transmission and large-volume data recording media,
high-quality content distribution and ubiquitous information services are making progress and
a new type of information distribution and network sharing service has gradually emerged into
the market. It is capable of utilizing terabyte-sized home servers also in private homes.
Under these circumstances, in distribution of content over shared networks, it is crucial to
establish digital rights management (DRM) technologies to protect the content from illegal
copying and usage. A truly successful DRM system must be built on open worldwide
specifications and provide maximum interoperability and user acceptance.
An open interoperable specification that follows this technical specification is able to construct
highly expandable PKI-based DRM, targeting usage between systems, considering the
expansion of recent content distribution services and clients (console type AV equipment, PC,
mobile phone terminal, automotive telematics terminal, and so on). This technical
specification gives protocol specifications for the exchange of license information among the
DRM module, the description of specifications for license information and the encrypted
content formats.
During the development of this model, the main consideration was the use of contents in
consumer electronics equipment connected with a home server. Also considered were
distribution, storage exchange and use of content between the distribution server and the
destination client system, allowing for conditions approved by the rights holder, and without
loss of convenience for the users. The standardization and its popularization based on this
model will enable interconnection between DRM modules allowing strong content protection in
various content distribution services over networks such as the Internet and mobile phone
networks.
TS 62224 © IEC:2007(E) – 7 –
MULTIMEDIA HOME SERVER SYSTEMS –
CONCEPTUAL MODEL FOR DIGITAL RIGHTS MANAGEMENT

1 Scope
This technical specification explains the conceptual model of a protocol specification to
exchange licence information between DRM modules and outlines what should be defined as
standards.
2 Normative references
The following referenced documents are indispensable for the application of this document.
For dated references, only the edition cited applies. For undated references, the latest edition
of the referenced document (including any amendments) applies.
ISO/IEC 15408-1:2005, Information technology – Security techniques – Evaluation criteria for
IT security – Part 1: Introduction and general model
ITU-T Recommendation X.509:2000, Information technology – Open Systems Interconnection
– The Directory: Authentication Framework
3 Terms, definitions and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the following terms and definitions, in addition to some of
those given in ITU-T Recommendation X.509, apply.
3.1.1
access condition
information that describes the content usage conditions
NOTE The access condition represents the conditional rules that restrict user ability to manipulate the content
information and is a part of authorization information in the licence for the content.
3.1.2
access control list
list of conditions to access content for each principal such as content users, user groups and
so on
3.1.3
asset identifier
information which identifies an asset which may include one or more contents
NOTE A licence should include an asset identifier. There are cases, for example, when an asset identifier is in
accordance with a content identifier, which specify the group of content identifier or a part of the content identified
by the content identifier.
3.1.4
certification authority
authority trusted by one or more users to create and assign public-key certificates
[ITU-T Recommendation X.509, 3.3.17]

– 8 – TS 62224 © IEC:2007(E)
3.1.5
certificate revocation list
signed list indicating a set of certificates that are no longer considered valid by the certificate
issuer. In addition to the generic term CRL, some specific CRL types are defined for CRLs
that cover particular scopes
[ITU-T Recommendation X.509, 3.3.12]
3.1.6
class certificate
certificate which declares the justifiability of TREM and its class public key with its related
information
3.1.7
class private key
key kept privately inside a TREM being subject to the same TREM class
NOTE The TREM developer or manufacturer should keep and manage this key privately.
3.1.8
class public key
public key corresponding to the class private key
3.1.9
content credential
information to certify integrity of the content data and the generator of the content data
NOTE This information includes a digital signature of the content, i.e., the hash value of the content data
encrypted with the generator’s private key. In general, it is added at the end of the protected content format (PCF)
data.
3.1.10
content identifier
identifier which is a unique value assigned to each content that is a unit of information
provided by the content holder
3.1.11
content key
content encryption key unique to each content under the symmetric key cryptosystem
3.1.12
data concatenation
concatenation of two bit-streams into a single bit-stream
NOTE The first bit of the second original stream is next to the last bit of the first original stream.
3.1.13
decoder TREM
TREM in which encrypted content can be decrypted and played
3.1.14
destination TREM
TREM receiving a licence
3.1.15
digital rights management
technology or functions to protect rights relating with digital content, for example, copyright, or
system or module which provides these functions
NOTE Inside this system or module it manages content access conditions and behaves under these conditions.

TS 62224 © IEC:2007(E) – 9 –
3.1.16
encrypted content
encrypted content data with its related meta data: broadcasting content, download content,
streaming content, and so on
3.1.17
entry TREM
TREM that has the function of generating a new licence according to indication from outside
and behaves as a source TREM, inside the licence distribution server and so on
3.1.18
hash function
(mathematical) function which maps values from a large (possibly very large) domain into a
smaller range
[ITU-T Recommendation X.509, 3.3.32]
3.1.19
licence
information including one or more content keys and authorization information like access
conditions, etc.
NOTE If it is outside a TREM, it should be a protected licence, which is protected with a session key generated in
accordance with SLTP.
3.1.20
licence identifier
data as an output of the concatenated asset identifier (may be the content identifier) and the
transaction identifier
3.1.21
licence move
moving of a licence from one TREM to the other
NOTE Once the licence is moved, the licence is deleted from the source TREM. A licence move with the
encrypted content copy equals a content move.
3.1.22
licence relay module
LRM
system or module that relays a protected licence between TREMs through an SLTP session
NOTE LRM is an endpoint of an LRP connection and has the function of controlling internal bus and network in
order to relay the protected licence via the LRP connection.
3.1.23
licence relay protocol
LRP
protocol between LRMs
NOTE Over this protocol, secure licence transaction protocol (SLTP) is realized for the Internet environment. For
the SLTP, the LRP provides functions of transaction management, restart of disconnected SLTP session, protocol
negotiation, and transfer of information relating with user authentication or accounting management.
3.1.24
licence server
server system that has a TREM and the LRM which mediates the transmission of a licence
issued by the TREM
– 10 – TS 62224 © IEC:2007(E)
3.1.25
licence transaction
unit of processing to distribute, move or copy a licence
NOTE For each transaction, the different resources are assigned and managed.
3.1.26
mediator TREM
TREM that mediates licence transfer as a main role
NOTE A mediator TREM has both roles as destination and source TREMs.
3.1.27
principal
subject that accesses a specific content or asset, such as content operation equipment, a
storage medium, a content user and a group or domain of them
3.1.28
protected content format (PCF)
data format in which the encrypted content is distributed
NOTE PCF can include multimedia contents and information representing their relationships. It can include a
content credential.
3.1.29
protected licence
licence information protected to transfer between TREMs
NOTE A protected licence includes encrypted content keys and protected authorization information. The content
keys are encrypted with the SLTP session key. The authorization information, including access conditions or its
hash, is encrypted with the SLTP session key as a counter-measure to its modification. Because authorization
information is often very short, hash is not only needed but also causes redundancy.
3.1.30
protection level
robustness to protect TREM and/or its content
NOTE Protection of TREM is realized as a tamper-resistant module.
3.1.31
public key cryptosystem
cryptosystem in which the encryption and the decryption keys are different
NOTE When concealing the data, the key used for encryption is publicly distributed. RSA and elliptic curve
cryptosystem are well known as public key cryptosystems.
3.1.32
root private key
private key securely maintained by the certification authority
3.1.33
root public key
public key corresponding to the root private key
3.1.34
secure licence transaction protocol (SLTP)
protocol to transfer licence information securely between TREMs
NOTE This protocol consists of formats of the information exchanged between TREMs and a state transition
specification of the TREM, which should be implemented.

TS 62224 © IEC:2007(E) – 11 –
3.1.35
session key
temporary key shared between TREMs at each SLTP session
NOTE A session key is a random number produced by one TREM and a key for the symmetric key cryptosystem.
3.1.36
SLTP session
secure session generated between TREMs according to the SLTP in order to transfer licence
NOTE Each SLTP session has a session key shared by both sides of the TREMs.
3.1.37
source TREM
TREM issuing a licence
3.1.38
symmetric key cryptosystem
cryptosystem in which the same key is used to encrypt and decrypt the data
NOTE The advanced encryption standard (AES) standardized by NIST in the U.S.A. is a well-known symmetric
key cryptosystem.
3.1.39
tamper-resistant module
TRM
module to protect from analysis or modification of information and its processing
NOTE See FIPS 140-2.
3.1.40
tamper-resistant rights enforcement module
TREM
system or module which has functions of digital rights management
NOTE TREM is structured as a tamper-resistant module. TREM has functions to enforce rights, manage the
licence and process the licence transfer according to SLTP.
3.1.41
transaction identifier
identifier that is assigned to each licence transaction
3.1.42
transaction log
log data representing the status of a licence transfer transaction and the licence issued in that
transaction
NOTE A transaction log is securely stored in the TREM.
3.1.43
TREM class
set of TREM authorized in a security judgment
NOTE A TREM that belongs to a TREM class has a subset of the same class certificates set issued by that
judgment.
3.1.44
TREM (individual) private key
key kept privately by each TREM individually

– 12 – TS 62224 © IEC:2007(E)
3.1.45
TREM (individual) public key
public key corresponding to a TREM (individual) private key
3.2 Abbreviated terms
ACL Access Control List
AES Advanced Encryption Standard
AID Asset Identifier
CA Certification Authority
CRL Certificate Revocation List
DES Data Encryption Standard
DRM Digital Rights Management
EC-DH Elliptic Curve Key Agreement Scheme, Diffie-Hellman
EC-DSA Elliptic Curve Verification Primitive, DSA version
GLF Generic Licence Format
ID Identifier
LRM Licence Relay Module
LRP Licence Relay Protocol
PCF Protected Content Format
SLTP Secure Licence Transaction Protocol
T-DES Triple DES
TID Transaction Identifier
TREM Tamper-resistant Rights Enforcement Module
TRM Tamper-resistant Module
4 Notation
4.1 Numerical values
In this model, the following expressions of numerical values are used.
Table 1 – Expression of numerical values
Binary (BIN) Decimal (DEC) Hexadecimal (HEX)
Letters used for value '0'～'1' '0'～'9' '0'～～'9', 'A' 'F'
Appended letter Nothing （ or 'b'） Nothing 'h'
Example 200 C8h
（）or 11001000b
4.2 Notations for keys
The following are the rules to represent keys in this model.
a) Keys that are used for cryptography shall be represented by a string starting with capital
‘K’.
b) Key expression with a capital ‘P’ in the second letter represents a public key of the public
key cryptosystem. The public key shall have a corresponding private key which is
represented by a key expression without a capital ‘P’ in the second letter.

TS 62224 © IEC:2007(E) – 13 –
c) A key expression with a small letter, ‘c’, ‘s’ or ‘x’ as the second letter represents the
symmetric key (shared key) or private key corresponding to the public key. A symmetric
key expression with small letter ‘s’ as the second letter represents a session key and ‘x’
represents a symmetric key for individual TREM.
d) Key expression with a small letter ‘t’ represents the embedded key in a TREM.
e) Key expression with a small letter ‘t’ and ‘c’ represents a symmetric key for a TREM class.
f) A numerical suffix letter or a letter ‘x’ or ‘j’ indicates a number or an identifier of each
individual key or class key. The numerical suffix is a natural number and can be omitted.
4.3 Notation list
This model uses the following notations.
Table 2 – Notations used in this model
Name Expression Description
Encryption E (K, D) The result of encryption of information ‘D’ with a key ‘K’
Hash H (D) The result of hash of information ‘D’
Concatenation A || B The result of data concatenation of ‘A’ and ‘B’
Content key Kc A content encryption key associated with each content
Root private key Ka A private key securely maintained by CA
Root public key KPa The public key corresponding to Ka
Relevant information Ixx The information relating to xx
Certificate C (Ka, KPxx || Ixx) A certificate of a public key KPxx.
KPxx || Ixx || E (Ka, H (KPxx || Ixx))
Class private key Ktcx A key that the same class TREM keeps inside them secretly
Class public key KPtcx The public key corresponding to Ktcx
TREM private key Ktx A key that the TREM keeps individually and secretly
TREM public key KPtx A public key corresponding to Ktx
Session key Ksj (j=1, 2,. ) A temporary key of symmetric key cryptosystem shared between the
communication entities per each communication session
CRL update time List CRLUpdates Date and time when CRL is renewed
Content ID CID The value of a unique identifier assigned to each content
Transaction ID TID The value of an identifier assigned for each transaction
Asset ID AID Identifier of asset that is authorized to access by a licence
Transaction log TransactionLog The log of the status of each transaction stored securely
Individual TREM Kx A key of a symmetric key cryptosystem that each individual TREM
symmetric key uses inside its TRM

5 Requirements
5.1 Viewpoint of content user
5.1.1 Content usage environment
The aim of this conceptual model is that equipment operating digital contents is implemented
conforming to the specifications compliant with this model, and then the rights to manipulate
the contents can be exchanged freely among the equipment, storage media, and digital locker

– 14 – TS 62224 © IEC:2007(E)
services without infringement of any rights. Implementation according to this model realizes
the environment where the general consumer can purchase and enjoy high-quality contents
(AV contents, programmes and multi-media contents) with any equipment, such as home
server, TV, mobile phone, PC, PDA, IT microwave oven, automotive telematics terminal, etc.
anywhere without infringement of any of the rights. Ubiquitous content usage environment like
this is shown in Figure 1.
1) Server authentication
3) Automatic decryption
Mobile phone
2) Privacy control
4) Simple charge
5) Recording replay position
Download site 6) Moving rights
Digital locker
7) Exchange with
any equipment
8) Playback at moved place
9) Sharing with families
10) Resale
Internet
Television
Home server
PC
Automotive telematics
Home network
Video
11) Transfer of rights 14) Usage control
camera
12) Restriction by user of versatile data
identification
13) Real-time authentication
and usage control
Storage media
15) Transportability
16) Backup and restore
IT microwave oven
17) Offline availability
Mobile TV CCTV
IEC  2196/07
Figure 1 – Requirements in the target ubiquitous content usage environment
Requirements in the content usage environment from the viewpoint of a content user are as
follows.
a) Server authentication: secure and reliable server authentication.
b) Privacy control: no-one can illegally access the privacy information of content users.
c) Automatic decryption: the network content is automatically decrypted and decoded
without complex operations by the user.
d) Simple charge: the content can be played with simple charge.
e) Recording replay position: the user can restart the playing of content from the position
last interrupted.
f) Moving rights: rights of purchased content can be moved within the conditions assigned
by rights holder.
g) Exchange with any equipment: the user can exchange content between mobile and home
equipments.
—————————
Digital locker service: service to provide the user’s virtual storage over the Internet. The user can store content,
which the user already has or has purchased, to the virtual storage and read (download or receive as a
streaming content) it from the virtual storage via the Internet.

TS 62224 © IEC:2007(E) – 15 –
h) Playback at moved place: after going to a second room, the user can watch the rest of
the same content on a PC as the one which was being watched on the TV in the first
room.
i) Sharing with families: the user can share a content purchased with other families without
infringement of any rights.
j) Resale: the purchased content may be sold to another without infringement of any rights.
k) Transfer of rights: the user can transfer rights of purchased content to another.
l) Restriction by user identification: the player system can control the play of content
according to the result of the user identification, for example, the age of the user.
m) Real-time authentication and usage control: the user system can process usage control in
real time in receiving and playing of the content.
n) Usage control of versatile data: without infringement of any rights, the user can enjoy
multimedia content including motion picture, music, superimposition, lyrics, image,
programme, and others. The user equipment can also process non-multimedia data, for
example, recipe data processed by an IT microwave oven.
o) Transportability: transportability of recording media. The user can carry a content stored
in a recording media and watch the rest of the content without indicating the restart
position.
p) Back-up and restore: in the case where the content package media is broken or lost, the
user can revoke the rights to play the media and set the same (back-up) content to a new
package media without renewal of the sales contractand
q) Offline availability: The user can use purchased rights in an offline (non-network)
environment.
5.1.2 Content distribution services
In this model, the following types of content distribution services that are required in the
above environment are considered.
a) Network download service.
b) Streaming service.
c) Content exchange support service, which supports the copying or moving of protected
contents among home or mobile equipments (such as P2P) and digital lockers without
infringement of any rights.
d) KIOSK terminal, from which the user can purchase contents.
e) Superdistribution service, by which the user can purchase just the rights to play an
encrypted content.
In this model, the following functional requirements for these services are considered.
a) Ubiquitous service: the user can purchase any content and play it wherever and whenever.
b) Mediation function: any type of digital content can be downloaded and forwarded with its
rights into any type of content operation system (like a digital content player device)
through any type of mediation server system such as contents management system,
contents distribution system, digital locker server, home server and so on.
c) Automatic session recovery: the content distribution service system can automatically
reconnect just after disconnection in downloading content. After reconnection, only the
rest of the content data not yet downloaded should be downloaded.
5.1.3 Integrity of content
The superdistribution service, considered in this conceptual model, encourages the exchange
of encrypted content among users unknown to each other. With superdistribution, it is
necessary for the user who has received encrypted content from an unreliable site to be able

– 16 – TS 62224 © IEC:2007(E)
to confirm the integrity of the encrypted content, because anyone may modify the original
content data at one of the unreliable sites where the content distribution was mediated.
5.2 Viewpoint of rights holder
In this model, it is considered that multimedia contents (for example, movies, games,
documents, programmes, etc.) are distributed, stored and used according to the conditions
designated by the rights holders. It must also be considered that the rights are protected
without spoiling the usability.
5.2.1 Overview of requirements for content protection
The following are the requirements for content protection in the content distribution and usage
environment described in 6.1.
a) Right to read: the content holder can grant the right to read and play, display or print the
content.
b) Right to edit: the content holder can grant the right to edit and store the content.
c) Right to copy or move: the content holder can grant the right to copy or change the rights.
After the rights are changed , the rights in the source shall be deleted.
d) Editing of rights: the content holder can edit the rights within the limited rights granted.
e) Permission for each principal: the content holder can grant the rights for each principal
such as a content operation equipment, a storage medium, a content user and a group or
domain of them.
f) Permission with a time limit: the content holder can grant the rights with a time limit.
g) Rights countability: the content holder can restrict the number of rights and the number of
equipments or media through which the rights are changed or copied, for example, in
order to limit the number of users who use a content simultaneously.
h) Rights exchange among servers: the rights may be exchanged among content
management server, content distribution server, digital locker server, home server and so
on.
i) Ubiquitous access control: The rights granted by content holders shall be enforced to the
principal (via equipment or media) whenever and wherever in this universe.
5.2.2 Licence service model
In this conceptual model, the licence service model that satisfies the requirements described
in 6.1 and 6.2.1 is considered in order to consider the threats of content distribution services
in the next paragraph. The following functional requirements for the licence service model are
described in Figure 2.
a) Content is encrypted and distributed in any way.
b) The licence information includes content keys and access conditions (ACs).
c) Once created by rights holder, the encrypted content and protected licence are decrypted
only in TREM (tamper-resistant rights enforcement module).
d) The licence information is protected by cryptosystem outside TREMs and shall be moved
among TREMs according to the AC itself.
e) A role to issue the changed licence is called source TREM and a role to receive the
changed licence is called destination TREM.
f) The TREM processes user a request according to the AC in the licence.
g) Entry TREM (defined in of 3.1.17) in such a content management/distribution server can
receive plain content data and plain licence information and can create the encrypted
content and the protected licence information and behave as a source TREM.
h) Mediator TREM (defined in of 3.1.26) in a content/licence mediation system behave as
both source and destination TREMs.

TS 62224 © IEC:2007(E) – 17 –
i) Decoder TREM (defined in of 3.1.13 ) in such a playback system can receive the licence
from the other TREM and decrypt encrypted contents according to the AC included in the
licence.
Content
TREM developers/manufacturers
user
Playback system
Decoder TREM
Playback Content
Encrypted content
Distribution of encrypted content
AC
(in any way)
Permission
for playback
Digital locker/home server/storage media
Rights holder
Mediator TREM Mediator TREM
Entry TREM
Licence Licence
Issue
AC +
Rights Move
AC +
AC +
Distribution server Mediation system Client system
: Access condition (usage condition)
AC The number of mediator TREMs may be 0 or more
※
IEC  2197/07
Figure 2 – Licence service model to consider the threats
5.2.3 Threats and counter-measures
Table 3 shows threats in the licence service environment described in 6.2.2 and counter-
measures against each threat.
Table 3 – Threats and counter-measures in the licence service model
Subject Attack (threat) Counter-measures
Analysis of TREM 1) Manufacturing TREM as TRM
Camouflage of the
2) Encryption with session key shared after
TREM user
destination TREM
Camou-
mutual authentication by the certificate of the
flage
Replay (camouflage of
destination TREM
the source TREM)
Leakage of TREM class private 3) Encryption with individual key for each
keys or temporary private keys destination TREM instance
TREM user and Camouflage of disconnection of
4) Comparison between logs in each TREMs
network user
the licence transaction session
Leakage of private key for the CA
Key renewal
or the TREM class
5) Issue of CRL
Illegal manufacturing
TREM Termination of the broken
manufacturer or illegal TREM
Leakage of key information
PC user Analysis of software TREM 6) Content protection level control

– 18 – TS 62224 © IEC:2007(E)
5.2.3.1 Manufacturing TREM as TRM
TREM must be TRM in order to prevent the content user from analysing the TREM and
stealing the secret keys from it.
5.2.3.2 Encryption with session key
In the licence distribution service, impersonation of the TREM such as replay attack by
camouflage of the licence sender TREM causes unauthorized unlimited copies of the content.
So, in order to prevent anyone from developing the module impersonating the source (sender)
or destination (receiver) TREM, the changed licence must be encrypted with the session key
shared after the mutual authentication of the source and destination TREMs using the
certificate for the class public key of the destination TREM.
5.2.3.3 Encryption with individual key
The changed licence should be encrypted with also key for each individual destination TREM
instance, in order to prevent anyone from breaking the TREM class public key. Otherwise,
once the TREM class public key is broken by anyone to analyse an instance of the TREM
class, all the other instances of the same class are also broken.
5.2.3.4 Comparison between logs
It is necessary that the licence transaction logs are securely stored in the TREM. When the
session to transfer/change licence is disconnected and the recovery of the session to send
the licence is needed once more, the log of the destination TREM should be securely
transferred to the source TREM in order to compare the logs of source and destination to
confirm if the licence was already received by the destination or not. Otherwise, anyone may
camouflage the unauthorized copy of the licence with the session recovery.
The probabilities of disconnection unexpected by the user are many during purchasing of
licence through communication networks, especially wireless mobile networks. If there is no
counter-measure for this type of threat, a distributor could only repeatedly send licences to a
deceitful TREM camouflaged with the legally disconnected TREM. Because not only the
disconnection may really have occurred but also there is no evidence that the licence arrived,
the source TREM must certainly deliver the licence to the destination in exchange for
accounting or decrease of the rights.
5.2.3.5 Issue of CRL
CRL can be used in order to terminate the use of illegal or broken keys and TREMs. For the
description of CRL, see RFC 3280.
5.2.3.6 Protection level control
The robustness of software TRM is remarkably low if compared with that of a dedicated
hardware TRM. In the environment where TREM as hardware TRM and TREM as software
TRM coexist, the fact that the software TRM was broken influences the whole of the
environment without
...