Sign up to receive free email alerts when patent applications with chosen keywords are publishedSIGN UP

Abstract:

A DRM client on a device establishes trust with a DRM server for playback
of digital content. The client executes in a secure execution
environment, and the process includes (1) securely loading loader code
from secure programmable memory and verifying it using a digital
signature scheme and first key securely stored in the device; (2) by the
verified loader code, loading DRM client code from the memory and
verifying it using a digital signature scheme and second key included in
the loader code; (3) by the verified DRM client code (a) obtaining a
domain key from the memory; (b) encrypting the domain key with a device
identifier using a DRM system key included in the DRM client code; and
(c) sending the encrypted domain key and device identifier to the DRM
server, whereby the device becomes registered to receive content licenses
via secure communications encrypted using the domain key.

Claims:

1. A method by which the trustworthiness of a digital rights management
(DRM) client on a device is established with a DRM server, the DRM server
to engage in secure communications with the DRM client by which licenses
are provided to the DRM client for enabling playback of digital content
on the device, the secure communications being encrypted using a domain
key, the method including the steps, performed in a secure execution
environment of the device distinct from a normal execution environment in
which a content player executes content playback, of: securely loading
loader code from secure programmable memory of the device and verifying
the loader code by performing first digital signature calculations using
a first manufacturer public key stored in the secure programmable memory;
by the loader code upon being verified, loading DRM client code from the
secure programmable memory and verifying the DRM client code by
performing second digital signature calculations using a second
manufacturer public key included in the loader code; and by the DRM
client code upon being verified: obtaining the domain key from the secure
programmable memory; encrypting the domain key together with a device
identifier for the device using a DRM system public key included in the
DRM client code; and sending the encrypted domain key and device
identifier to the DRM server as part of a device registration process by
which the device becomes registered with the DRM server to receive the
content licenses via the secure communications encrypted using the domain
key.

2. A method by which a signed client certificate is created for use by a
client device in establishing mutually authenticated secure
communications with a backend server of an application service, the
communications to be secured by a client private/public key pair, the
backend server storing a validation server public key used by the backend
server to confirm a certificate signature of the signed client
certificate, comprising: at the client device, generating a first message
and sending it to a device validation server, the generating including
(1) generating the client private/public key pair using a random number
generator, (2) generating a certificate signing request including the
client public key and a certificate hash value; (3) encrypting the
certificate signing request together with a device-specific
authentication token and a locator value for the backend server, the
encrypting producing encrypted values and performed using a domain token
shared among a plurality of client devices, and (4) forming the first
message to include the encrypted values and a hash of the domain token;
at the device validation server, (1) receiving the first message and
confirming the hash of the domain token, (2) decrypting the encrypted
values using the domain token to obtain decrypted values including the
certificate signing request, authentication token and locator value, (3)
generating the certificate signature from the decrypted values using a
digital signature process and a validation server private key, and (4)
securely sending the certificate signature to the client device; and at
the client device, forming the signed client certificate including the
client public key and the certificate signature received from the device
validation server.

Description:

SUMMARY

[0001] A procedure is described for establishing trust between a
computerized device (also called a "client device") and a server system
for digital rights management (DRM) (also referred to as a DRM server or
"backend"). The technique is applicable to devices such as mobile
smartphones or tablets (more generally mobile devices) as well as fixed
devices such as set top boxes. In one embodiment the device may utilize a
specialized processing chipset, referred to as "system-on-chip" or SoC,
that incorporates several hardware components such as processor(s), WiFi
and network interface controller, content decryption and decoding, etc.

[0002] The techniques herein utilize a processing arrangement including a
secure execution environment such as the arrangement known by the name
TrustZone. Such an arrangement generally requires some level of specific
hardware support in any physical implementation. The arrangement includes
two execution environments, one being the secure environment and the
other referred to as the non-secure or "normal" environment. With the
exception of a secure communication channel, the normal environment does
not have access to resources of the secure environment, but the secure
environment has full access to all resources including secure as well as
non-secure resources.

[0003] The DRM client utilizes the backend to help bootstrap a chain of
trust to the backend, so that DRM licenses can be served to enable
protected content to be played. Key aspects of establishing the root of
trust of the device and the application to the backend are described.

BRIEF DESCRIPTION OF THE DRAWINGS

[0004] The foregoing and other objects, features and advantages will be
apparent from the following description of particular embodiments of the
invention, as illustrated in the accompanying drawings in which like
reference characters refer to the same parts throughout the different
views. The drawings are not necessarily to scale, emphasis instead being
placed upon illustrating the principles of various embodiments of the
invention.

[0005]FIG. 1 is a block diagram of a networked system for content
delivery and playback;

[0006]FIG. 2 is a block diagram of a hardware organization of a
computerized device;

[0007]FIG. 3 is a schematic diagram of a hardware and software
organization of a client device;

[0008]FIG. 4 is a schematic diagram showing processes performed between a
device and a backend system; and

[0010]FIG. 1 is a simplified view showing pertinent components of a
networked system for storing, delivering and playing protected content
such as encrypted video files. In this simplified view, the system
includes a set of backend servers or "backend" 10 connected to a client
device 12 via a network 14. The backend 10 is described in more detail
below. The client device 12 is generally a computerized device having
playback capability including the decryption of encrypted content files,
including for example a personal computer, tablet computer, smart phone,
etc. Decryption keys used in to decrypt the encrypted content files are
provided to the client device 12 by the backend 10. In operation as
described more below, the client device 12 authenticates itself to the
backend 10 and provides information establishing its authorization to
play identified encrypted content (e.g., a particular video). The backend
10 responds by providing one or more decryption keys enabling the client
device 12 to decrypt the content file(s) for the video. The client device
12 obtains the encrypted content files from a content server (not shown),
decrypts them using the decryption keys, and then renders (plays) the
decrypted content.

[0011]FIG. 2 is a generalized depiction of a computerized device such as
may be used to realize the client device 12 and a server of the backend
10. It includes one or more processors 20, memory 22, local storage 24
and input/output (I/O) interface circuitry 26 coupled together by one or
more data buses 28. The I/O interface circuitry 26 couples the device to
one or more external networks (such as network 14), additional storage
devices or systems, and other input/output devices as generally known in
the art. System-level functionality of the device as described herein is
provided by the hardware executing computer program instructions
(software), typically stored in the memory 22 and retrieved and executed
by the processor(s) 20.

[0012] Any description herein of a software component performing a
function is to be understood as a shorthand reference to operation of a
computer or computerized device when executing the instructions of the
software component. Also, the collection of components in FIG. 2 may be
referred to as "processing circuitry", and when executing a given
software component may be viewed as a function-specialized circuit, for
example as a "player circuit" when executing a software component
implementing a content player function. As described below, the client
device 12 includes a more specialized hardware organization for purposes
of security.

[0013]FIG. 3 shows the specialized organization of the client device 12.
It includes a partitioning of functionality between a secure execution
environment 30 and a normal or non-secure environment 32. Hardware
components include an application processor 20-A in the non-secure
environment 32 and a secure processor 20-S in the secure environment 30.
Also included in the non-secure environment 32 is a hardware decryption
circuit (CRYP) 34. Operating software in the non-secure environment
includes an operating system (O/S) 36, content player application or
"app" 38, chipset application programming interface (C/S API) component
40, and a non-secure (NS) portion of a DRM client (DRM CLT-NS) 42. In one
embodiment, the operating system 36 may be the Android® operating
system 36 for mobile devices.

[0014] The components in the secure environment 30 are responsible for
establishing a root of trust with the backend 10 (FIG. 1) to enable the
client device 12 to obtain decryption keys for decrypting content. It
includes a secure kernel 44, secure file system 46, and DRM agent 48. It
also includes a secure (S) portion of the DRM client (DRM CLT-S) 50 that
works together with the non-secure DRM client 42 to establish the
necessary trust as described below. In the remaining description the term
"DRM client" may be used to refer to the paired DRM client portions 42,
50 as a single unit.

[0015] The non-secure DRM client 42 is mainly an interface (via the API
component 40) between the content player 38 and the secure DRM client 50.
In particular, the non-secure DRM client 42 only sends requests to the
latter to register the device 12, obtain a rights object for a particular
media object, and enable decryption and playing of the media object. The
DRM Agent 48 is an API layer to access the backend servers 10.

[0016] In one embodiment, the secure environment 30 may employ components
of the so-called TrustZone family, including the secure processor 20-S
realized according to the ARM architecture, as well as the secure kernel
44 and secure file system 46 which are specially tailored for
security-related uses. Establishing a root of trust is based on security
features offered by the hardware (SOC chipset) that is embedded in a
circuit board used to build a device (e.g., mobile phone handset). While
the chipset manufacturer provides the hardware, the device manufacturer
(OEM) loads firmware (code) such as the DRM client and DRM agent 48.

[0017] FIGS. 4 and 5 are used to describe steps taken to establish an
unbroken chain of trust between the content player application 38 and the
backend 10. As shown in each figure, three processes are employed.
Referring to FIG. 4 in particular, a device authentication process 60 is
carried out between the DRM agent 48 and a device validation service (DEV
VAL SVC) 10-DV. A subscriber authentication process 62 is carried out
between the app 38 and a subscriber management (SUBSCR MGMT) service
10-SM. A playback authorization 64 for playback of specific content is
carried out between the application backend (APP BACKEND) 10-AB and
components (SoC COMPS) 66 of the secure environment 30, including for
example the secure file system 46 in which any sensitive data items are
stored. Playback authorization 64 includes delivery of
content-item-specific licenses and manifest files for example.

[0018]FIG. 5 generally illustrates the flow of messages during the
different processes. These different exchanges are described below.

Overview

[0019] The initial step is device authentication 60 in which it is
established that the device 12 is an authentic device running an
unmodified version of the device O/S 36, the DRM Client (portions 42 and
44) as well as DRM agent 50. The approach used is to begin with a secure
boot process involving two levels of boot using a signature scheme such
as RSA-PSS (Probabilistic Signature Scheme) to verify the authenticity of
the signatures of boot loaders and the DRM client. The DRM client is
distributed as firmware and resides in flash memory of the device 12, not
ROM. It is included in the second level boot, and thus it is necessary to
authenticate the DRM client code by a process as described below. The
device manufacturer uses a private key PrK to generate a signature of the
firmware in the factory. This signature is verified at each boot. The DRM
client is verified as part of the firmware. The device 12 also contains
the manufacturer's public key PuK to verify that the binary has not been
modified. This verification code is stored in SoC ROM. The PuK must not
be modifiable even if it is not confidential.

[0020] Next, this root of trust is extended to include the backend 10.
This involves securely sending a secret back to the backend 10. At this
point, the backend 16 has verified the authenticity of the device 12 and
indirectly the authenticity of the client software. An application client
that authenticates to its application backend server can subsequently use
the DRM agent 48 to request a media play. The DRM agent 48 uses
client-certificates for mutual authentication when talking to the backend
10 for verifying trust and obtaining rights object containing licenses
pertaining to the specific device and the media selected. A content key
is securely conveyed to the hardware player and the media is decrypted
and rendered on the screen of the device 12. This workflow is shown in
FIG. 5.

Phase 1--Establishing Root of Trust

[0021] Establishing a root of trust begins with a secure boot procedure.
This is implemented using the secure execution environment 30 (e.g., ARM
TrustZone) in addition to some hardware mechanisms that may be
manufacturer-specific.

[0022] For the secure boot process, in one embodiment a
manufacturer-specific private key PvK is used to generate a signature of
the firmware at its creation point. The DRM client may be deployed in
this manner. The chain of trust begins with one component--SoC ROM.
Ideally, the corresponding public key PuK is burnt into the ROM and used
to authenticate the first bootloader. However, putting the PuK on the SoC
ROM means it is the same for the class of devices. To prevent
class-hacks, OTP (One Time Programmable) poly-silicon fuses may be used
to store unique values in each SoC during device manufacture. For
example, a 256-bit hash of a 2,048-bit PuK can be stored. Thus, the PuK
is individualized to some collection of devices 12 and its verification
is via the hash burned into the OTP fuses. The PuK itself can be loaded
from flash memory. The flash would contain all PuKs that may be usable,
and the specific one in use is identified by the hash.

[0023] For the code authentication, the following steps are taken at boot
time (all operations in the secure environment 30):

[0024] 1. The secure kernel 44 (which has basic functionality and resides
in SoC ROM) starts execution in the secure environment 30. This kernel is
programmed into the SoC ROM when SoC chipset is manufactured.

[0025] 2. By the secure kernel 44, load PuK from flash memory to a secure
location and verify it based on the hash stored on the on-chip ROM (e.g.,
OTP fuse array). The verification needs to check that the particular hash
value matches at least one of the keys stored in the flash. This key is
determined to be the PuK.

[0026] 3. Also by the kernel 44, load first boot code from flash memory to
a secure location and verify it using the PuK. A digital signature scheme
such as a 128-bit MD5 hash may be used for the verification. The first
boot code is digitally signed in the factory using the private key
corresponding to PuK. During startup, a checksum of the loaded boot code
is calculated. The stored signature is decrypted and the
decrypted/recovered checksum is compared to the calculated checksum. A
match indicates that the boot code is authentic and not tampered with.

[0027] 4. Use the verified first boot code to load DRM client code
(portions 42 and 50 as well as DRM agent 48) from the flash memory to a
secure location and verify its signature. This verification may use a
similar digital signature scheme, but in this case using a secondary PuK
that is stored in the first boot code. This verification is trusted
because the first boot code performing this operation was verified in the
preceding step. A match of digital signatures indicates that the DRM
client code is authentic and not tampered with.

[0028] Note that all communication between the secure and non-secure
environments 30, 32 are via a secure API, which in the case of TrustZone
is referred to as TZ-API. This communication is necessary to allow the
content player 38 to communicate with the DRM agent 48.

Phase 2--Device Registration

[0029] Thus far, it has been verified that the boot loaders and the DRM
client code are genuine. It is still necessary to perform device-level
verification to establish for the backend 10 that the device 12 is a
genuine device running a genuine O/S 36. Device authentication includes
communicating certain sensitive information to the backend 10 in a secure
manner. This step applies to each backend. Thus, it is required to
register the device 12 for each different app 38. The device 12 is
validated through a secret value by a device validation service 10-DV.
The registration process is initiated by the app 38 calling a "register"
API with 2 arguments: a URL pointing to the app's service backend 10-AB,
and an opaque user authentication token that the app has obtained from
the app's subscriber management server 10-SN (typically after a user
authentication step done in the app). This triggers the authentication
steps described below.

[0030] Step 1. The secure DRM client 50 sends to the device validation
service 10-DV the following 4-tuple:

[0031] (1) a SHA256 hash DTH of a
token (a 128-bit Domain Token (DT)) placed at the factory in the secure
file system 48;

[0035] The DT may be generated in a secure manner in an entirely separate
process, then it is stored in the validation server 10-DV. It is
desirable to partition the devices 12 into sub-groups with different DTs
in order to contain any damage from a breach.

[0036] The client SSL certificate signing request is generated based on a
device-generated local property called "Device ID" (2048 bits long) that
is stored in the secure file system 48. The Device ID is a confidential
way of individualizing this device and is used as the client's private
key CPrK. The Device ID is constructed at run time in the device 12 from
a hardware-based random source and created only when the device
registration is run. The combination of the individualized manufacturer
PuK and the Device ID has a high degree of uniqueness.

[0037] The device 12 is validated in the beginning when it first needs to
acquire a client certificate and thereafter to renew the certificate when
DT is revoked. A client certificate is specific to the device 12 and may
be used with multiple apps 38.

[0038] The above secret values are sent to the validation service 10-DV
after encryption with AES 128 using DT as key. The hash DTH is not
included in the encryption but sent together with the encrypted message.

[0039] The encryption with DT together with Step 2 (below) is a way to
ensure the authenticity of the device 12. This is because the DT is
installed into the secure file system 48 by the OEM (handset)
manufacturer (or on their behalf by the chipset manufacturer) and the
secure file system 48 guarantees confidentiality.

[0040] A backup value of DT also needs to be stored in the secure file
system 48 in order to renew the primary DT as explained below. The SSL
client certificate(s) associated with a retired DT also need to be
renewed.

[0041] Step 2. The validation service 10-DV verifies DTH. This message
also contains the client certificate signing request containing the
client's public key CPuK and the hash CCH of the client's certificate.
The server first encrypts the CCH with a DRM system private key DPrk.
This is equivalent to the service 10-DV signing the client's certificate.
The signature is sent back to the client. This message is encrypted using
AES-128 with DT as key and salted with a nonce.

[0042] Step 3. The secure DRM client 50, after decrypting the server's
response using the DT, completes the confirmation of the backend's
response in the secure environment 30. At this point, only a valid device
12 could proceed to receive the contents of the message. Further, the
secure DRM client 50 decrypts the certificate signature with the DRM
system public key DPuK to validate the signature. It can then proceed to
request playlists and rights objects from the app's backend server 10-AB.

[0043] All further client communication to the app's service backend 10-AB
are via the mutually-authenticated SSL using the client certificate. The
service backend 10-AB can verify the signature using the DRM system
public key DPuK.

[0044] Rights objects are sent over an SSL connection and stored encrypted
in the secure file system 48 (e.g., using AES encryption or public-key
encryption, in which case the client's public key is stored with the
encrypted rights objects). Media keys are stored in the secure file
system 48 and provided to the media player in the secure environment 30.
Media playback is via a hardware-based decrypt and decode mechanism.

[0045] The DT stored in the secure file system 48 may need to be renewed
in the event of a security incident. This is achieved by using a
revocation procedure where the old DT is renewed with a new one sent down
to the device 12 after establishment of trust. In step 2 of the Device
Authentication, the old DT is no longer accepted by the backend 10-DV and
an error is returned with a condition that rejects the old DT. In this
event, the secure DRM client 50 retries with the backup DT. After the
successful acceptance of the backup DT, trust is established and a new DT
is transmitted encrypted with the backup DT using AES-128. This new DT is
then installed as the primary DT.

[0046] After the DT is renewed, all old client certificates issued based
on this must be renewed. This is achieved by forcing a new device
registration. The process may be controlled so that not all clients are
forced to renew at the same time.

[0047] While various embodiments of the invention have been particularly
shown and described, it will be understood by those skilled in the art
that various changes in form and details may be made therein without
departing from the spirit and scope of the invention as defined by the
appended claims.