secmodel.html 17.3 KB

Raw Blame History Permalink

<html>
<head>
<title>
	BB Security Model
</title>
</head>
<body bgcolor="#ffffff" text="#000000"
  link="#004868" vlink="#986424" alink="#00ffff">

<table width="100%" cellpadding=2 cellspacing=0 border=0>
<tr>
<td bgcolor="#e0e0e0">
	Project BB
</td>
<td align=right bgcolor="#f0c0c0" width="20%">
<font color=red>
	<b>Broad<i>On</i> confidential</b>
</font>
</td>
</tr>
</table>

<h3><u> 1. Overview </u></h3>
	This Page describes the security model for the BB. The goal of the
	model is to enable the secure delivery and play of games or other
	content. For gaming applications, the security of the content (the
	game) is of lesser importance than the ability to run that content
	on an economically viable platform. The opposite is true for media
	delivery, such as mp3 and video. Here the security of the content
	is paramount.

<h3><u> 2. Historical Background </u></h3>
	Several schemes have been deployed in the past to prevent attacks on
	the content or the ability to clone game systems. They range from
	obfuscation to the use of board-level components. None of these systems
	could be considered secure in today's terms. In many cases, simple
	board level attacks were sufficient to break the system.

<h3><u> 3. Classification of Attackers </u></h3>
	The referenced research article
<a href="#add91">[ADD-91]</a>
	proposed the following classification of attackers:
<dl>
<dt> <b>Class I</b> (clever outsiders):
<dd>
	They are often very intelligent but may have insufficient knowledge
	of the system. They may have access to only moderately sophisticated
	equipment. They often try to take advantage of an existing weakness in
	the system, rather than try to create one.
<dt> <b>Class II</b> (knowledgeable insiders):
<dd>
	They have substantial specialized technical education and experience.
	They have varying degrees of understanding of parts of the system but
	potential access to most of it. They often have highly sophisticated
	tools and instruments for analysis.
<dt> <b>Class III</b> (funded organisations):
<dd>
	They are able to assemble teams of specialists with related and
	complementary skills backed by great funding resources. They are capable
	of in-depth analysis of the system, designing sophisticated attacks, and
	using the most advanced analysis tools. They may use Class II adversaries
	as part of the attack team.
</dl>

<h3><u> 4. Security Background </u></h3>
	With the advent of the internet, open security software has become
	readily available in recent years. The core of these cryptographic
	packages consists of the following algorithms and functions:
<dl>
<dt> Message Digest Algorithms (MD2, MD5, SHA)
<dd>
	A digest is a one-way function that maps or hashes a large block of
	data into a short message. A digest is cryptographically secure. The
	important properties are that is it computationally infeasable to
	recover the original data from the message, and that no two blocks of
	data produce the same digest message.
<p>
<dt> Public Key Algorithms (RSA, DSA, DH)
<dd>
	Public Key algorithms use asymmetric keys, one is kept private and the
	other is made public. The mathematical basis of public key algorithms
	is the factorization of large numbers. It is computationally infeasible
	to derive one key from the other. The algorithms can be used for
	encryption, key exchange and signatures.
<p>
<dt> Certificate/Signature Algorithms (PKCS, X509)
<dd>
	These functions deal with the packing of public keys, private keys and
	other identifiers into standard formats for export and import into the
	security packages.
<p>
<dt> Block and Stream Ciphers (DES, 3-DES, RC2, RC4)
<dd>
	Block ciphers encrypt blocks of data, while stream ciphers can handle
	smaller data quantities. While the sharing of a secret key amongst parties
	is a disadvantage when compared to public key algorithms, block ciphers
	offer substantially better performance and are the choice for bulk data
	encryption. Puplic key algorithms are used to exchange the cipher keys.
	When choosing a cipher mode, certain tradeoffs have to be made regarding
	error recovery, block scrambling, level of security and speed.
<p>
<dt> Random Number Generators (SHA-1, FIPS)
<dd>
	Random number generators are a fundamentally critical component of any
	cryptographic system. They are typically achived by obtaining a local
	seed entropy that should not be guessable, used by a secure pseudo
	random number generator of large state.
</dl>

<h3><u> 5. Secure Delivery and Play of Content </u></h3>
	Security is an end-to-end problem, nothing in the path of delivery can
	be trusted. The entire system consists of the following three main
	components, each being in different domains of trust. The model was
	derived from
<a href="#jp1-02">[JP1-02]</a>.
<p>
<center>
<img src="secmod1.gif" width=579 height=439>
</center>
<dl>
<dt> Central Servers
<dd>
	These are located in a trusted environment of the operator.
	Conceptually, they consist of:
<p>
<dl>
<dt> Content Preparation (PREx)
<dd>
	Content Cx is encrypted with symmetric key Kx, resulting in CKx. CKx is
	moved to the content server SVRx which in turn delivers it to the
	gateways Gx. The key Kx and the content identifier Ix are sent to the
	license server LICx.
<p>
<dt> Content Server (SVRx)
<dd>
	The content server(s) processes requests from the gateways Gx which may
	store multiple cached copies of encrypted content CK1..CKn. The gateways
	copy CKx into the players Px without modification.
<p>
<dt> License Server (LICx)
<dd>
	The license server(s) deal with client authentication, server
	authenticaton, per-player licensing and interface to the billing system.
	Therefore, they must hold a public key PUB-Lx and private key PRIV-Lx.
<p>
<dt> Billing System (BILLx)
<dd>
	The billing system processes all financial transaction initiated by the
	customer. It's function is beyound the scope of this document.
</dl>
<p>
<dt> Game/Media Gateways (Gx)
<dd>
	This is the gateway (ala deport station) that players plug into to
	download new games or content. It is located in public places, such as
	video stores, shopping malls, etc. The gateway cannot be trusted because
	it is in the public domain and is physically accessible. The gateway is
	strictly an access point that caches content but is not involved in
	cryptographic operations. Tampering with the gateway should only result
	in interruption of access or service.
<p>
<dt> Players (Px)
<dd>
	This is the component of the system that is most vulnerable, first by the
	large number of entities, and second because of the low cost. Advanced
	features must be deployed to make tampering, cloning or breaking of
	security very costly to attackers of class I and II. Furthermore, even if
	the plain content is available, it should be very difficult to design a
	cheaper system that can run it. The player must store a public key PUB-Px,
	a private key PRIV-Px, a player ID ID-Px, and the public key(s) of
	possible license servers PUB-Lx.
</dl>

<h3><u> 6. Client Authentication </u></h3>
	Client authentication is required to guard against attacks that target
	the billing system and not the content. Without client authentication,
	an attacker could replace a gateway Gx with a system that could produce
	excessive billing requests for players for which the public key PUB-Px
	is known. Secure client authentication was chosen over signatures to
	prevent plain/encrypted challenge pairs from aiding in statistical
	analyses. To authenticate player Px, the license server LICx creates
	a challenge (random number), encrypts it with the player's public key
	PUB-Px and sends it to the player Px. The player decrypts it with its
	private key PRIV-Px, re-encrypts the challenge with the license server's
	public key PUB-Lx and sends it back. The license server verifies the
	response by decrypting it with its private key PRIV-Lx.
<p>
<center>
<img src="secmod2.gif" width=564 height=156>
</center>
	Gateway Gx is transparent and involved only in the data transfer.

<h3><u> 7. Server Authentication </u></h3>
	Server authenticaton verifies to the player Px that the license server
	LICx is legitimate. Player Px sends its public key PUB-Px, ID-Px, and
	the requested content identifier Ix to the license server LICx. Once the
	client has been authenticated, the license server prepares a licence
	for decryption and play of content CKx. The license contains the
	content key Kx, a hash over encrypted content CKx and other DRM (digital
	rights management) information. The license is encrypted with the
	player's public key PUB-Px and sent to Px. A database on the server
	verifies the ID-Px/PUB-Px relation. The returned valid license
	constitutes server authentication to the client.
<p>
<center>
<img src="secmod3.gif" width=541 height=238>
</center>
	Again, gateway Gx is transparent and involved only in the data transfer.
<br>
	In fact, both athentication exchanges can be interleaved in order to
	reduce authentication and processing time.
<p>
<center>
<img src="secmod4.gif" width=540 height=329>
</center>

	From a cryptographic point of view, the initial outgoing request
	<i>msg</i> does not need encryption. However, a third party could
	intercept the requests to gather user profiles. Sending <i>msg</i>
	in encrypted form improves privacy.

<h3><u> 8. Additional Techniques </u></h3>
<dl>
<dt> Distributed Triple-DES
<dd>
	Triple-DES uses three different keys K1, K2, and K3. First, Content Cx
	is encrypted with K1, then decrypted with K2, and finally encrypted with
	K3, The receiver must know all three keys to sucessfully decrypt.
	Distributed triple-DES executes the three crypto operation on different
	systems along the path of delivery. Assuming that the gateway Gx is
	insecure, triple-DES would only be as secure as single-DES, but it would
	localize the encryption of content Cx. <br>
<p>
	K1 is equivalent to key Kx mentioned above. K2 would be generated in the
	central servers based on some information about the local environment
	of the gateway Gx (such as IP addresses or other network IDs). K2 is
	not known by the gateway Gx, but sent to the license server(s) LICx.
	K3 is generated by the gateway Gx based on its local environment, but
	differently than key K2. Gateway Gx only needs to send K3 to the license
	server(s) once. The gateway encrypts the cached content with K3 before
	sending it to the player Px. The license returned to the player now
	contains all three keys which are needed to decrypt content Cx.
<p>
<dt> Limited lifetime of license server's public keys
<dd>
	The license server's addresses and public keys PUB-Lx can be assigned a
	limited lifetime. The player Px gets updated versions after both sides
	have authenticated themselves successfully. Since the player Px has no
	sense of time, this becomes a per-plug operation.
<p>
<dt> Locality
<dd>
	The license servers LICx can keep track of when and where a plug operation
	occurred. An algorithm can be implemented that prevents serving of licenses
	for impossible location/time events.
</dl>

<h3><u> 9. Requirements for the BB Player </u></h3>
	Each player Px has to hold the following pieces:
<ul>
<li> player identifier, ID-Px;
<li> own private key, PRIV-Px;
<li> own public key, PUB-Px;
<li> addresses of content and license servers;
<li> public key of license servers, PUB-Lx;
<li> software that implements the algorithms in section 4;
<li> software to download content into the external FLASH;
</ul>

	The player's private key PRIV-Px is the most critical piece of information.
	It should be very difficult to obtain them by tampering with board level
	components. Futhermore, the boot/security code and required state should
	reside within the most expensive component of the board. No actions of the
	boot/security code should be visible on external interfaces. Embedded
	FLASH/ROM and embedded SRAM are essential to make tampering a chip-level
	operation. Overall, it should be economically infeasible to produce cloned
	players.

<center>
<img src="secmod5.gif" width=504 height=298>
</center>

<h3><u> 10. Internal FLASH/ROM and SRAM </u></h3>
	All the critical bits of the security system and boot code must reside
	inside a chip to make tampering with board-level components impossible.
	The internal FLASH must have security bits to disable reprogramming once
	the security bits are set to lock mode. In addition, all JTAG and debug
	interfaces must be disabled to prevent stepping of any interface. More
	bits can be used to lock up the chip if an attempt was made to put the
	chip into JTAG or any other debug mode.
<p>
	A strict boot algorithm must be implemented that allows the cpu to
	execute plain boot code from the internal FLASH, authenticate licenses
	and content from external FLASH, decrypt that content and then run it.
	Access to the internal flash must be turned off by hardware just before
	leaving the secure boot environment to execute the decrypted content.
	Only a system reset can reenable access to the internal FLASH. The
	internal SRAM must hold all state of the boot and security code.
	None of that state must leave the chip.
<p>
	A word on FLASH attacks. Class I and II attackers can attempt various
	voltage, spike, temperature and clocking attacks to make the cpu execute
	something other than the internal boot code. Clocking attacks can be
	made more difficult by monitoring the clock or PLL lock state. The FLASH
	can be made more tamper-proof by extending the width to include something
	like ECC on a per-word basis. Running a block checksum over the FLASH
	is not sufficient as this is limited temporaly. The same applies for
	the cpu caches.

<h3><u> 11. External FLASH </u></h3>
	The external FLASH stores variable data. Except for non-critical data
	(header, addresses and public keys of license servers), everything is
	encrypted and goes through the same authentication and decryption process
	as if it was downloaded fom the deport station. Erasure, programming or
	tampering with the external FLASH does not compromise security and may
	make the system unusable.
<dl>
<dt> Header
<dd>
	This header is not encrypted and points to the various sections. It can
	be thought of as a primitive file system.
<p>
<dt> Addresses and public keys of license servers
<dd>
	The list of IP addresses and public keys of license servers are stored
	in external FLASH, because of the limited lifetime of the public keys.
	They could be stored in internal FLASH, but that would expose the
	programming interface of the internal FLASH to attacks involving
	voltages, spikes and temperature.
<p>
<dt> Licenses, LICx
<dd>
	Licenses are stored in encrypted format as described above. Each license
	is the right to play a specific encrypted content. The license is bound
	to a hash of the content and the player identifier. The encrypted content
	does not have to be resident in the player. The intend is to cache
	licenses, because the user can get the encrypted content CKx from the
	gateway Gx without another transaction to the license server. However,
	the license server(s) keep a copy for error recovery.
<p>
<dt> Content, CKx
<dd>
	Contents in external FLASH are encrypted with key Kx. Each content must
	have a corresponding license in the license section. The boot code of
	the player refuses to play content for which there is no valid license.
</dl>

<h3><u> 12. External DRAM </u></h3>
	The external DRAM (DDR to be more precise), is the working memory of
	the system. An attacker can retrieve the entire plain content or pieces
	of it by snooping on the DRAM protocol. The only way of closing this
	security hole is by embedding the DRAM into the chip with the processor
	and internal FLASH/SRAM. It is important to remember the assertion at the
	beginning of this paper; the security of the content is of lesser
	importance thant the ability to produce an economic alternative player.
<p>
	Simple obfuscation techniques can be implemented in hardware to make
	snooping on the content more difficult. They don't improve security but
	raise the entry level for snooping attacks. Address XORs and address
	dependent data XORs are simple and require very little extra logic.

<h3><u> 13. Protocols and sizes </u></h3>
	A first estimate limits the size of the internal FLASH to about 64kbytes,
	and the internal SRAM to 32kbytes.
	A full implementation of SSL is far too large for the size contraints
	of the internal FLASH/SRAM. At a minimum, the network interface driver
	and a scaled-down IP layer are needed to implement simple exchanges of
	network packets. The tftp protocol is simple and sufficient for
	downloading the encrypted contents. The secure exchanges described above
	all fit into a standard IP packet over ethernet. A single message digest,
	block ciper and certificate packing must be chosen.

<h3><u> 14. Secure Manufacturing </u></h3>
	The manufacturing process is an easy target for attacks. If the IDs,
	private and public keys of all the players were distributed on CDs or
	reside on a manufacturing computer, then a compromise would constitute
	a disaster. It is best to have the players create their own private and
	puplic keys based on their ID and other random inputs. At the end of
	the manufacturing line, the player would send out the ID and public key
	to be put into a database.

<h3><u> References </u></h3>
<dl>
<a name="add91">
<dt> [ADD-91] </td>
<dd>
	DG Abraham, GM Dolan, GP Double, JV Stevens, ``Transaction Security
	System'', in IBM Systems Journal v 30 no 2 (1991) pp 206-229
<a name="jp1-02">
<dt> [JP1-02] </td>
<dd>
	John Princen, ``Architecture and Flow for GC and BB'' email 01/17/2002
</dl>

<hr>
<font size="-1">
	Problems and comments to
<a href="mailto:berndt@routefree.com">
	berndt@routefree.com
</a>
</font>
</body>
</html>