Nokia Standard Document Template - TML

Enabling advanced Mobile DRM scenarios
N. Asokan and Jan-Erik Ekberg, February 2002
1. MOTIVATING SCENARIOS
2. REQUIREMENTS
1 (11)
Timo was about to board a train in the railway station when he noticed an advertisement for
a wireless kiosk selling the latest topper of the local music charts. He took out his
communicator. The wireless kiosk was already visible in his browser. With a few clicks, he
paid for a copy of the single, and downloaded the audio file to his communicator. While on
the train, Timo started to chat with his fellow traveller Anna and found out that she was a
music fan, too. He transferred a copy of the new song to Anna’s communicator. Anna
could listen to it a few times. Then Anna’s communicator indicated that the number of free
previews has expired, and if Anna wanted to continue to listen to the song, she must
commit to paying for it. Anna liked the song so much that she committed to pay. After that
she was able to listen to the song again. When Anna got off the train, she noticed another
kiosk. She paid for the song she got from Timo.
Simple approaches to digital rights management (DRM) are based on preventing the
copying of protected content. Although they are simple to implement, they are not tenable
in the long term because their restrictiveness prevents reasonable usage scenarios like the
above from being realized. Even honest users, frustrated at not being able to do what they
consider reasonable, may be tempted to circumvent the rights management system. Thus,
in the long term, digital rights management on mobile devices should focus on enabling
reasonable use of protected content so that the interests of all parties are served to the
best possible degree.
The goal of the the work described in this chapter was to design and implement a system
that allows scenarios like the above to be realized. This system should protect the interests
of all parties involved: consumers like Anna and Timo, as well as the owner of the
copyright, and the operators of kiosks. to the concrete objectives were to study the
feasibility of secure content distribution focussing on supporting
• downloading of content and rights from public kiosks to mobile devices using (high
speed) local networks,
• superdistribution of content and rights from one user device to another, and
• accurate and timely metering mechanisms on which revenue sharing schemes can be
based.
The motivation behind these objectives is to enable the legal spreading of content in and
via mobile devices to the greatest possible extent: allowing copies to be made while still
retaining the ability for proper metering and reporting of new copies. The chosen approach
was to develop a potential architecture and build a reference implementaiton.
The primary requirements for the reference implementation were
1. Only compliant devices must be allowed to acquire and redistribute rights.
2. It must be possible to track and report any new creation of rights.

3. Creation and transfer of rights must be possible even when there is no on-line
connection to a network server.
2 (11)
4. When rights are exchanged for payment, it must be possible to use any payment
scheme, both electronic and traditional. The system must not be limited to one or a few
schemes only.
The first requirement is applicable to any DRM system based on the notion of compliant
devices. The last requirement is required for flexibility and is also generally applicable.
Requirement 2 is necessary for the distribution of rights. This can be easily solved if there
is always a connection to an on-line server. But this may not always be possible for mobile
users. Requirement 3 captures this aspect. Requirements 2 and 3 can therefore be seen
as specific to DRM for mobile users/devices.
3. BASIC CONCEPTS AND DESIGN
The architecture of a node is shown in the figure below. Each user node is required to have
at least the following two parts:
• A tamper-resistant module (called the DRM device)
• A protocol engine implementing the rights transfer protocols (including a user interface)
The reason for separating these two parts is the underlying trust assumption: the node is
responsible for protecting the interests not only of the owner, but also of other parties such
as the authors and publishers of content. This part of the node must be certifiable. It is
therefore useful to identify the minimal certifiable functionality as a separate part. This is the
DRM device. This separation also allows the DRM device to be used with different protcol
engines, possibly implementing the rights transfer protocols over different transports. The
implementation of DRM functionality requires some support from the underlying operating
platform. This functionality is defined by the platform API.
In addition, there may be additional entities such as
• Rendering applications that receive content from the DRM device and render it, and
• Authorization plug-ins (e.g., for a payment system)

3.1 Securing rights transfer
Rendering Application Protocol Engine
Usage API Rights Management API Access Control API
DRM device/module Authorization plug-ins
(payment, …)
Platform API
Operating platform
Figure 1 Conceptual architecture of a node
3 (11)
A compliant device is one that behaves according to the specifications laid out here. Every
compliant device will have an encryption key pair and a digital signature key pair for
suitable asymmetric cryptographic schemes. Each device will also have a device certificate
issued by the device manufacturer. The device certificate certifies the public keys of the
device as belonging to a compliant device. Every device will also have the public signature
verification key of the device manufacturer so that it can verify device certificates of other
devices. For the sake of simplicity, let us only consider a single manufacturer. But devices
of multiple manufacturers can inter-operate by using certificate chains and crosscertification
of manufacturers.
A piece of content is associated with two types of rights: usage rights which specify policies
governing the local use of content, and transfer rights which specify policies for creating
new rights for another device. The design supported several types of transfers including:
• ‘give’: a device can give away its rights to a content to another device. Once the
right is transferred, the sending device will not be able to use the content anymore.
Note that the receiving device may pay the sender. Such sales are not the concern of
the rights management system.
• ‘copy’: copying creates a new right. This is used when content is sold by a kiosk or
superdistributed by ordinary users.
Rights for a piece of content are embodied in a voucher. Each piece of content is encrypted
with a content key using a symmetric cipher. The voucher contains the content key
encrypted using the public key of the target device. It also contains policies specifying how
this copy of the content is to be used. Compliant devices will obey the policy restrictions
specified in a voucher. When a right is transferred, the sending device creates a voucher
targeted for the receiving device. A sending device MUST verify that the receiving device is
a compliant device before creating a voucher for it. A receiving device will accept a voucher
if it can verify its correctness: A voucher contains, among other things,
• description of the content

• description of rights
• content key encrypted using the public encryption key of the receiver
• sequence numbers used to ensure freshness
4 (11)
• a message authentication code (MAC) on all of the other fields, using the content key
When a compliant receiving device is asked to import a voucher, it verifies the validity of
the voucher by first extracting the content key, and then checking the MAC. With these
mechanisms, the Requirement 1 is met.
Typically, verifying compliance alone is not enough for a sender to make an access control
decision about a receiver. For example, in the case of a sale, the sender may ask the
receiver to securely bind his device certificate to a payment transaction (e.g., open a
secure channel, and send credit card number and device certificate through the same
channel). To enable such access control decisions, other authorization certificates may be
used. For example, a user may issue certificates to each of his devices so that they can
recognize each other. A device can then automatically approve a ‘give’ transfer if the
request came from another device belonging to the same user.
3.2 Metering and reporting new rights
Requirements 2 and 3 deal with distribution of rights by copying. Creation of a new right for
a piece of content must be metered and reported so that the resulting revenue can be
effectively collected and shared.
When the protocol engine asks its compliant device to create a new right by copying, it can
indicate whether it should be sender-reported or receiver-reported. In the former case, the
compliant device records it locally as an unreported transaction. In the latter case, it issues
a voucher which is marked as report-pending. A special case of the receiver-reported
voucher are the preview vouchers. These come with a specified number of free previews.
By default, these vouchers need not be reported, and will disappear once the free previews
are used. But the user can convert it into a real receiver-reported voucher by committing to
report it. Such a voucher will be marked as report-pending. If proof of reporting is imported
into the device, the report-pending voucher will be converted to an unconstrained voucher.
When the number of report-pending vouchers reach a specified limit, the device may be
disabled in some fashion. In other words, it is the compliant devices that enforce policies on
rights. Unconstrained and preview vouchers can be deleted by the user. If the user deletes
a report-pending voucher, it will be marked as locked, and will be really removed only after
it has been reported.
The main intent behind the reporting feature is that the copyright owner will be able to
receive payment from the owner of the device that reports the transactions. This implies
that sender-reported transactions will be typically of the pay-now type where the transfer is
accompanied by a payment from the receiver to the sender, using whatever payment
mechanism is suitable (of course, there may be no payment at all: the transfer may be a
gift). Receiver-reported transactions are typically of the pay-later type because the receiver
should eventually pay the copyright owner.
In both types of payment scenarios, any payment scheme can be used for value transfer.
Hence requirement 4 is satisfied.

import full voucher
import receiver-reported
voucher
import preview voucher
[removable]
report-pending
receiver-reported copy
locked
(deleted)
existing
deleted
(existing)
usable
(existing)
report-pending
(usable)
unremovable
(deleted)
give [givable] delete
use [usecount ≥ uselimit]
preview copy [copycount < copylimit, copycount++]
unconstrained
(usable)
commit
report
report
uncommitted
(usable)
Figure 2 Lifecycle of a voucher
report
use [usecount < uselimit, usecount++]
The figure above shows the lifecycle of a voucher as a state transition diagram.
5 (11)
In the reference implementation, metering and reporting of new vouchers is done as
follows. For transactions between terminals (i.e., superdistibution), only receiver-reported
vouchers are supported. Kiosks sell unconstrained vouchers. Reporting of vouchers is
done implicitly by purchasing an unconstrained voucher from any kiosk. When an
unconstrained voucher is imported, if there is already a corresponding report-pending
voucher then instead of creating a new voucher, the old one will be marked as
unconstrained.

3.3 Rights transfer Protocol
Receiving
DRM device
RD
UI
Selection/Approval
Transfer Request:
{Content_ID, Tx_Type, Download_Flag, RSEQ, [Rights_Template]} tuples,
[Authorization_Method], CertRD, [Authorization certificates]
importVoucher()
update local state
y/n
Receiver
protocol engine
R
Sender
protocol engine
S
Transfer Trigger:
{Tx_Type, Policy_Info, Content_Desc. Rights_Template} tuples,
[Authorization_Options]
Compliance check
Access Control check
E.g., Payment transaction (bind receiving
Device ID and payment)
Voucher Creation
Transfer Response:
Voucher, [Encrypted content]
Voucher Import
Figure 3 Rights transfer protocol
isAuthorized()
Sending
DRM device
SD
verifyDeviceCertificate()
y/n
auth.
plugin
y/n
createVoucher()
update local state
Voucher
6 (11)
The figure above iillustrates the rights transfer protocol. It consists of three message flows.
It does not show any service location or browsing activity that may have preceded the
actual transfer transaction. The participants are
• sender is the player sending a right and/or the encrypted content. The sender’s
device is SD.
• receiver is the other player participating in the protocol. The receiving device (RD) is
the recipient of the transferred right. RD may belong to R, but this is not mandatory;
the protocols can be used to buy a right on behalf of someone else’s device.
The optional Transfer Trigger is sent by the sender. This message contains the proposed
transaction type (e.g., ‘copy’), policy information (e.g., price requested) that can be
displayed to the receiver user, description of the content, and a description of the proposed
voucher. It may also explicitly list the acceptable authorization options (e.g., payment
methods).
The Transfer Request is sent by the receiver. Among other things, it should include a
compliance certificate for the receiving device, and a sequence number to be used by the
receiving device to guard against the replaying of old vouchers. On receiving the request,
the sender should first check if the device certificate is acceptable to SD. Then it may do an

7 (11)
access control check via an access control plugin (e.g., a payment plugin). This access
control check is orthogonal to the rights transfer system. Then the sender asks SD to
create a voucher for RD. SD will create a voucher only if RD has an acceptable
compliance certificate. Creation of a voucher may change state information maintained by
SD. It is important that the integrity of this state information is protected.
The Transfer Reply contains the newly created voucher. The receiver may also get the
encrypted content along with this reply, or separately. To use the voucher, it must be
imported into RD. RD will check if the voucher is acceptable as explained earlier. In
particular, it would check if RSEQ is an acceptable sequence number. If RD was not
consulted before sending the Request, a special RSEQ value may be used. Such
vouchers are marked unremovable. This is to prevent the attack where the receiver ‘give’s
this right to another device, and then replays old voucher back into his own device, thus
ending with a free voucher.
4. PLATFORM SUPPORT
It is the compliant DRM device that enforces the management of rights. Rather than design
a special-purpose device, a minimal set of changes that would allow a commonly used
operating system platform to be adapted as a DRM device were identified and designed.
The approach is based on authenticating processes at run-time when needed. This sets at
least the following requirements on the way the operating system is operated and how it
handles its processes:
1. The user cannot make modifications in the OS kernel . This implies that the OS can be
loaded / started in a secure and reliable manner. Note that only integrity of the kernel is
required; the kernel source code need not contain any secrets.
2. OS processes cannot access each other's memory areas without explicit permissions
3. Disk swapping or other kinds of temporary storage that may leave traces of critical data
can be disabled for processes that require this feature.
4. The system hardware can be set to enable some secure storage to the kernel.
If these requirements hold it is easy to see that the kernel can get unique access to the
secure data, and based on that it can
a) Form a secret by which secure storage for vouchers can be implemented (and
equivalently a secret protecting the private key of the device when stored) These
secrets may or may not be separate.
b) Authenticate a process claiming to be the DRM engine (more about this later)
Processes are authenticated by calculating a message digest over the text segment of the
process, verifying that there is a signed and appropriate certificate matching this digest and
checking the position of the program counter. Assuming that the program is statically linked
the following should hold: The (digest over the) text segment uniquely identifies the
program, and provided that the program counter actually points to the text segment no viral
program could replicate this identity.
Based on this functionality, the kernel provides the following services to processes

8 (11)
a) A system call by which a process can claim to be the DRM engine and insert a
certificate to prove this fact. Upon this request, the kernel will check the process in
accordance with method described above, and if all things match this process is given
the necessary secret to maintain the secure storage
b) A system call by which a process may register an easy-to-remember name (or some
other identity) for itself
c) A system call by which a process may retrieve the digest and process identifier (PID) of
a process (that has registered some name)
d) A system call by which a process may send a secret to a another process identified by
a specific [PID,name, digest] – tuple.
e) A system call by which a process may retrieve a secret sent to it by another process.
Two kinds of tamper-resistant secure storage are needed on the device: a small amount
(e.g., 128 bits) secret storage which can be used to bootstrap larger amounts of secret
storage for private keys, etc.; and a equally small amount (128-160 bits) integrity-protected
storage, which can be used to bootstrap additional integrity-protected storage for state
information. The former can be read-only, while the latter is necessarily mutable over time.
5. REFERENCE IMPLEMENTATION
A music player reference implementaiton with the above-mentioned features and a UI was
done on Linux system (kernel 2.2.17) with X-windows and wireless LAN access. Several
additional building blocks were needed to put together the final demonstrator. The elements
in the following picture are described in more detail to show the functionality of the
demonstrator.
Conceptual architecture
Rendering Application TranSec Protocol Engine
TranSec Usage API TranSec Rights Management API TranSec Access Control API
TranSec DRM device/module Authorization plug-ins
(Payment, …)
TranSec Platform API
Operating platform
Implementation architecture
Charging
(BillNeat)
SLP
IP
WLAN
UI
Engine (DRM)
WLAN
ctrl
DRM
kernel
supp.
Figure 4 Conceptual architecture and its mapping to reference implementation
Smart
card
supp.
?

5.1 Operating platform support
5.2 DRM engine
9 (11)
The Operating platform support has been coded into the Linux kernel as has been
described in the previous chapter. No hardware support or support for secure kernel
loading is available; so the necessary security elements have been hard-wired into the
kernel. Minimal hardware support for secure kernel loading and secure storage is
absolutely essential for this approach to be secure.
The DRM engine will be authenticated by the kernel at start-up. The kernel has hardcoded
information of the expected message digest of the DRM engine. If the digest of the engine
matches, a key is given (also hard-coded in the kernel source) to the DRM engine for
generation of integrity-protected storage for the vouchers it handles. In this implementation,
the DRM engine also 'owns' the device secret key, which it uses to sign outgoing
messages. The engine also includes the actual protocol engine for receiving, sending and
verifying messages between DRM engines. Additionally it will keep track (and enforce
restrictions) of global device parameters such as the number of unreported vouchers
currently stored in the device, and maintain voucher state (such as number preview copies,
and whether apsecific voucher has been reported or not).
In the reference implementaiton, the DRM engine additionally keeps track of data
essentially irrelevant to it such as the position of actual encrypted content in the device
(and which voucher the content relates to), some nice textual information regarding the
content (originally received by the Service Location Protocol) and some additional state
information needed by the user interface). In a real implementation, this functionality would
not belong in the engine itself, but is now included for convenience.
5.3 User interface and rendering application
The User Interface and Rendering application (the MP3 player) are both authenticated by
the DRM-engine before taken into use. When the user wants to play some music (and the
voucher restrictions allow it) the DRM-engine will send the content key to the rendering
application through the kernel (kernel services (d) and (e)). An ad-hoc encryption method
where each MP3 – block is encrypted separately using RC4 has also been implemented.
The purpose geared more towards ease of demonstration than actual security. The basic
point is that the music will be decoded and sent to the audio driver (which is in the kernel)
only on demand, and the plaintext music will never be stored or kept in the device in
decrypted form. Additionally, key distribution through the kernel could establish a mutual
key between the rendering application and the audio driver so that internal communication
paths are also secured.
5.4 Discovering available content
The Service Location Protocol [SLP-RFC] is used to inform users of music available at a
certain kiosk, and in user-to-user transactions what content is available for (receiverreported)
copying in the sender's device. Essentially these records are used to transmit
user-readable information of the music, its author, price and other textual information, as
well as identification information for the related encrypted content and voucher ID. Retrieval
of encrypted content is done as non-authorized bulk transfer either directly from the kiosk
or user-to-user. There are no enforced restrictions on this activity (a user is allowed to
download encrypted content without a valid voucher for it (he just cannot play it).

5.5 Authorization and payments
10 (11)
The BillNeat charging system [BILLNEAT] was used as an authorization plug-in for
purchasing content vouchers at kiosks. BillNeat is a 3rd party charging solution based on a
three-tier structure - the buyer, the seller, and a distributed network platform that contains
the core of BillNeat's functionality. The authentication mechanism used in Billneat is based
on asymmetric cryptography and x.509 certificates, making the billing records
uncontestable.
5.6 Other aspects of the reference implementaiton
6. CONCLUSIONS
Adding wireless LAN infrastructure to the elements above makes it possible to emulate the
service scenario described in the introduction. The user terminals will tune in to kiosks and
automatically show the available music, it is up to the user to select the music pieces he
wants, to dowload the content and to buy for the vouchers. In a user-to-user scenario,
either user can turn his device into an 'access point' which the other user can browse just
like it would be a kiosk, with the difference that a kiosk only sells 'pay-now' vouchers,
whereas other users only distribute 'pay-later' – ones. Music playing is similar to any MP3player
on the market.
Figure 5 User interface screenshots
Based on the experience in designing and building this reference implementaiton reported
above, it can be concluded that a digital rights management scheme supporting off-line
superdistribution and hotspot content sales is feasible on mobile devices, assuming that at
least the the minimum necessary platform support is available. It is also clear that
implementing the necessary operating system support is feasible. Thus, the critical factor is
the availability of hardware support.
It is commonly accepted that all known tamper-resistance mechanisms can be defeated
given sufficient resources and skill. The decision to rely on tamper-resistance as a security
mechanism should therefore be based on a delicate cost/benefit analysis. Any use of
tamper-resistance should consider the impact of a breach.
An alternative to tamper-resistance is to rely on the assumption that collusions cannot
happen in a large scale. Offline superdistribution can be based on the receiver giving a
non-repudiable commitment (e.g., in the form of a digital signature) to the sender. The
sender will forward the commitment to the copyright owner, who will then use it as the basis

7. REFERENCES
11 (11)
for payment from the receiver. This approach does not rely on tamper-resistance, but on
assuming that the sender has an incentive to forward the commitment he received from the
receiver. This pre-supposes additional infrastructure.
Finally, copyright itself is a hotly debated topic. In course of time, the world may develop
alternative business models that do not require protection of copyright in its current form.
However, the type of platform security described is also useful in many other applications
like copy-protected ticketing, and electonic money. In fact, the same techniques that are
used to protect the interests of a third party from a malicious device owner can also help
protect the device owner from a thief who stole the device!
[BILLNEAT] P. Ginzboorg, J-E Ekberg and A. Ylä-Jääski: “A Charging and Billing
Mechanism for the Public Internet”, Proceedings of Telecom Interactive 97, ITU, Geneva.
[SLP-RFC] Service Location Protocol, v.2, IETF RFC 2608, June 1999.