Conditional Access in Mobile Systems

Conditional Access in Mobile Systems: Securing the Application Eimear Gallery and Allan Tomlinson Mobile VCE Research Group, Information Security Group, Royal Holloway, University of London, Egham, Surrey, TW20 0EX, England [email protected], [email protected] Abstract This paper describes two protocols for the secure download of content protection software to mobile devices. The protocols apply concepts from trusted computing to demonstrate that a platform is in a sufficiently trustworthy state before any application or associated keys are securely downloaded. The protocols are designed to allow mobile devices to receive broadcast content protected by proprietary conditional access applications. They may also be applied in the general case where demonstration of a secure execution environment is required before an application is downloaded.

1. Introduction Recent developments in communications systems have given the potential to deliver complex content to mobile devices. It is expected that the next generation of mobile communications systems will be able to collaborate with broadcast networks to provide wireless access to video content from a wide range of mobile devices [25]. For a service like this to achieve its full commercial potential, the owners of the content will require assurance that their material is not illegally accessed. Current broadcast systems accomplish this by using conditional access systems to ensure that only bona fide subscribers have access to the content. The DVB organisation has developed several standards defining a common interface to conditional access systems at both the transmission site and at the receiver, while allowing the systems themselves to remain proprietary [2, 6, 7]. Services broadcast today, therefore, are protected by a range of proprietary access control systems. While receivers remain static, and consumers subscribe to one or two service providers, the DVB standards provide a practical solution. However, if a mobile subscriber requires access to services protected by a range of conditional access systems, then the current solutions become impractical. This paper proposes a flexible approach that allows consumer products

to support a wide range of proprietary content protection systems.

2. Current solutions The DVB standards specify two mechanisms that provide a degree of flexibility in the application of proprietary conditional access systems to broadcast services [3]. At the transmission site, the simulcrypt standard allows a service to be controlled by two or more conditional access systems. At the receiver, the common interface standard allows conditional access modules to be plugged into pc-card slots in the receiver to configure the device for the required conditional access system. Both systems rely on the service being scrambled by a standard common scrambling algorithm [6]. To apply the DVB standards, a service would be scrambled by the common scrambling algorithm under a single key known as the control word. Since the cryptographic scheme is a symmetric algorithm, the control word must be delivered to the receiver in a secure manner. This is the function of the conditional access system. At the transmission site, the control word is encrypted by the conditional access system and the encrypted control word is broadcast to the receiver in advance of the scrambled service.

2.1. Simulcrypt If a second conditional access system is available to the broadcaster, then the same control word may be encrypted by this system too. The simulcrypt standard [7] describes the interface to the conditional access systems. Both encrypted control words are then broadcast in advance of the scrambled service. Thus, receivers running either conditional access system are able to decipher the control word and access the scrambled service. As far as the consumer is concerned, the operation of this system is completely transparent. The service provider, however, must operate multiple conditional access systems. While it may be commercially feasible for large networks to operate two or three conditional access systems,

the cost and logistics of running many such systems simultaneously could prove to be prohibitive for smaller networks.

2.2. Common interface The alternative to simulcrypt is to provide a solution at the receiver. This is accomplished by specifying a standard interface for the receiver that provides access to the scrambled service and the encrypted control words [2]. In this instance the scrambled service and the encrypted control word are passed to a separate pc-card module containing the hardware and software for a specific conditional access system. The encrypted control words can be deciphered on the module to provide access to the service. By swapping modules, the receiver can thus be configured to match the conditional access system used by the broadcaster. This system is therefore transparent to the broadcaster but not the subscriber. As is the case with simulcrypt, this mechanism may provide a solution for two or three conditional access systems, but as the numbers increase the cost to the subscriber could become prohibitive.

time minimising the hardware overhead on the mobile device and the cost to the user. An attractive solution is to allow a service provider to re-configure the mobile device to be compatible with the appropriate proprietary conditional access system. The implication of this is that the proprietary application is implemented entirely in software and delivered to the mobile device on demand. The difficulty lies in convincing the service provider that the application, including any embedded secret keys, will be protected to at least the level offered by current solutions. This contrasts with the more familiar problem of securing the platform against malicious applications. To address this problem, the delivery mechanism must protect both the integrity and confidentiality of the application. Moreover, the mobile device must be able to demonstrate the trustworthiness of the platform on which the application will execute, to the application provider. The former can be accomplished by well known security mechanisms such as encryption and the use of message authentication codes [11], while the latter may be achieved by the deployment of emerging trusted computing technologies.

4. Emerging technologies 2.3. Limits of current solutions The current solutions are well suited to current technology, where services are generally controlled by one or two conditional access systems and subscribers generally only require authorisation from one or two broadcasters. With a mobile receiver, however, subscribers will require authorisation from an increasing number of service providers as they move around. The common interface solution would require mobile devices to have a pc-card interface and the user to carry a number of modules. The cost of adding such an interface as well as the practical design issues could make this infeasible. The cost of the modules may also deter some subscribers. The alternative solution using current technology would be to broadcast each service under the control of as many conditional access systems as possible, which would prove expensive for many broadcasters. Both current solutions therefore have potential difficulties which will significantly restrict the content available to mobile receivers. These existing solutions do not transfer well to mobile systems and the problem would benefit therefore from some reconsideration in the light of new requirements.

3. Proposed solution The objective is to provide access controlled broadcast content to mobile devices. This should be achieved with minimum impact on existing networks while at the same

4.1. Trusted Computing Group’s trusted platform The Trusted Computing Group (TCG) is an industry standards body which is developing specifications for a trusted computing platform [21]. The system proposed by the TCG is composed of three fundamental components. 1. The Core Root of Trust for Measurement (CRTM) has the ability to measure at least one integrity metric which reflects a portion of the software environment of the platform. The CRTM records this integrity metric a Platform Configuration Register (PCR) held in the Trusted Platform Module (TPM). 2. The TPM [22–24] is a tamper-resistant component responsible for recording the integrity measurements from the CRTM. It calculates a cryptographic digest of all sequences of integrity metrics presented to it on request. The TPM also provides security functionality to the platform, such as platform attestation, protected storage, and sealing. 3. The TCG Software Stack (TSS) [20], which consists of: • The TCS event log, in which a record of all platform software that has been measured is stored. This may also contain validation certificates containing correct integrity metrics or links to correct integrity metrics of firmware or software running on the platform;

In conjunction with this, the TSS must provide the functionality such that measurement agents and a trusted platform agent, as labeled by Balacheff et al. [1], may be implemented, where: • Measurement agents, have similar functionality to that of the CRTM. They perform integrity measurements but, as they do not constitute a root of trust, they must therefore be measured by the CRTM before they can be trusted and run; and • A trusted platform agent co-ordinates the supply of integrity metrics to a challenger. The security services offered by a TCG compliant trusted platform include confidentiality and integrity of data and application code during storage. This is provided by the protected storage mechanism. In this instance the binary object is encrypted under a key protected by the tamper-resistant TPM. This key is only released and the binary object is only accessible on presentation of the correct authorisation data to the TPM. Further protection is provided by a mechanism called sealing, where a binary object is associated with specific PCR values (cumulative digests of software running on the platform) before encryption such that the object cannot be retrieved unless the current PCR values, which represent the software environment of the platform, match those associated with the object. TCG compliant platforms also provide an authenticated boot process. During this boot process the software state of the platform is recorded and stored in the TPM. For the problem addressed by this paper, platform attestation is particularly important. This permits the state of the trusted platform’s software configuration to be demonstrated to a challenger. To accomplish this the TPM signs the software measurement log and the relevant PCR values.

4.2. Next Generation Secure Computing Base Microsoft are developing the Next Generation Secure Computing Base, or NGSCB [5, 15]. Although the NGSCB specifications remain unpublished, Microsoft have produced technical reports [12–14] that provide an insight into the proposed architecture. NGSCB requires a Security Support Component (SSC) compliant with the TPM v1.2 as defined by the TCG. NGSCB also requires modifications to be made to the CPU, memory controller, graphics adaptor, and keyboard. As was the case with the TCG’s trusted platform, the NGSCB architecture has three fundamental components. 1. The most fundamental of these components is the security support component or ‘SSC’ which is a tamperresistant cryptographic chip required to provide cryptographic processing, a small amount of memory, and

a monotonic counter. A module compliant with version 1.2 of the TCG’s TPM specifications [22–24] is expected to serve as a potential SSC in the NGSCB architecture; 2. The second of these components is the nexus or security kernel which is of minimal size, and provides access control and memory isolation through the curtained memory facility described below. It manages the security hardware and the protected operating environment and offers system services and security functionality to trusted applications running in the protected environment; 3. Finally there are the NGSCB trusted applications, also called Nexus Computing Agents (NCA), which may be an application, or part of an application or a service, and which run securely within the protected operating environment. The security services offered by the NGSCB architecture include confidentiality and integrity of data and applications during storage. This is provided by the sealed storage mechanism. The sealing mechanism ensures that a particular binary object is only accessible to the trusted application that created it, running on a specific instance of a particular nexus, or to a trusted application specifically permitted by the creator as trusted to have access to it. NGSCB also provides attestation. Each NCA has the ability to identify itself to other, either local or remote, NCAs. This is accomplished by the provision of the NCA’s signature on its integrity values. These integrity values consist of the identity of the nexus upon which it is running, and the identity of the trusted application itself. Secure input/output facilities are also provided by NGSCB, in which only trusted NCAs have access to user’s input and output operations which cannot be observed or modified by any other processes. An important aspect of the NGSCB architecture is the curtained memory facility. The protected operating environment isolates a secure area of memory that is used to process data with higher security requirements. In curtained memory each NCA may be isolated from every other NCA as well as from any untrusted software running on a regular OS, which may run in parallel to the trusted environment. This physical memory protection is achieved via chipset extensions and a specially designed CPU. Secure channels are also provided so that inter-application communications are protected. Intel’s LaGrande Technology project [8] have developed a set of hardware components, including a processor and chipset extensions, keyboard, mouse and graphic subsystem enhancements and a v1.2 TPM. These component will support an IA-32 platform that is able to provide security ser-

vices described above, such as protected execution (DMA prevention), sealed storage, platform attestation.

4.3. Alternative architectures In addition to the major trusted computing initiatives outlined above, parallel developments are taking place in the open source community. For example, the PERSEUS project [16] proposes a new architecture for a trusted platform which uses TCG/NGSCB hardware features in conjunction with an open source security kernel [17]. Marchessini et al. [10] also describe experiments where TCG hardware has been used to transform a desktop Linux machine into a virtual secure processor. Two other architectures that may meet our objectives are the AEGIS processor architecture [19], and the XOM, executable only memory architecture [9]. Both these projects propose architectures developed around secure processors.

5. Proposed protocols Having identified technology with the potential to solve the problem of proving that a platform is trustworthy, we may now address the challenge of securing a downloaded conditional access application. Our two objectives are: 1. To protect the confidentiality and integrity of the application as it is transported from the service provider to the host platform; and 2. To protect the application when it reaches the host platform. To meet these objectives we propose two protocols that make use of trusted computing facilities. The protocols, specified in sections 5.5 and 5.6, use different types of cryptographic primitives to achieve similar objectives. Before specifying these protocols we briefly note relevant prior art, together with possible issues with a trusted computing based approach. Balacheff et al. [1] and Sadeghi and Stuble [17] have both highlighted the potential of the TCG architecture for the secure delivery and storage of content to a trusted platform, where: 1. A challenge-response mechanism is used so that the challenger (in our application the service provider) can be certain that the mobile host can indeed be trusted; and 2. Encryption of the application by the service provider so that it is only retrievable by the platform proved to be trusted in the previous step. There are however, some potential issues with TCG trusted platform based protocols.

Firstly, it is difficult to confirm that returned PCR values represent a trustworthy computing platform. It is clear from the way PCR values are calculated that verification of an integrity challenge may become a difficult and overly complex task. This may be a particular problem if there are a large number of entries in the trusted platform measurement store, which may occur when a challenged platform has been running for a long time. Verification may also be particularly complex if many different validation entities are being used by the challenged trusted platform to certify the entries in the software measurement log. Further problems arise if the host platform has deployed extensible software. PCR values may be reflective of every piece of software running on the trusted platform, a PCR value containing the integrity metric for a piece of extensible software would be very difficult to verify as ‘correct’ or trustworthy. The integrity mechanism deployed by the TCG specifications may ultimately mean that a very large number of different software states may have to be verified. A question also arises in relation to the protection of binary objects after they have been unsealed. When an application is unsealed and executing we must consider the threats it may be exposed to, for example tampering or replication. Finally, there exists the possibility that malicious software may penetrate the system and bypass the operating system kernel, e.g. via direct memory access. In this way applications that have been measured by the CRTM may be overwritten by malicious code. Therefore, during platform attestation, a false impression of the software environment may be given to a challenger. The protocols proposed in sections 5.5 and 5.6 are based on a combination of the security mechanisms offered by NGSCB, LT hardware extensions, and the CRTM and TPM as defined by the TCG. This combination of security mechanisms is being proposed here for a number of reasons. The CRTM and the TPM described in the TCG specifications are well defined, in the public domain and have undergone a review process leading to the recent release of version 1.2 of the main TPM specification [22–24]. The physical memory protection provided by LT and NGSCB guarantees that, when the downloaded application is unsealed, it can execute without interference or without external monitoring. By implementing an architecture that allows the physical separation of the trusted partition from the untrusted system partition, any legacy operating system and any untrusted applications may run in parallel with a trusted kernel. This removes any restrictions on applications that may be run in parallel on the same platform. Furthermore, the process of platform attestation or software integrity verification also becomes much simpler than the process described in the TCG specifications. Chipset extensions can also prohibit system vulnerabilities caused by,

physical attacks bypassing the integrity measuring mechanisms.

Broadcasters

Therefore, given the emergence of trusted platform technologies, we assume the presence of a trusted platform. This platform ideally consists of a TPM, as described in [22–24], in conjunction with additional hardware extensions as described in [12–14] and [8]. This will then enable the problem of securely downloading the conditional access application to be tackled, as described below.

Software Provider

DVB-C

DVB-S

DVB-T

Application Server

Network

Mobile Receiver

5.1. Model

Figure 1. Model. The model under consideration is illustrated in Fig. 1 and involves three parties: the user, who has a mobile receiver, M ; the broadcasters, B; and the software providers, S. The mobile user does not have a long term relationship with the broadcaster but is aware of the services that are available. Some of these services may be scrambled, in which case access is controlled by a conditional access system. For each scrambled service, the associated conditional access application, AC , must be acquired by the mobile receiver. The protocol requires that the mobile receiver is able to demonstrate to the software provider that it is a bona fide receiver and not a in a malicious state that may attempt to illegally modify or replicate the downloaded application. Once the receiver has proved itself to be legitimate, the application is made available only to that receiver. Finally, the protocol must protect the confidentiality and integrity of the application as it is transported to the mobile device. The software provider in this model is required to supply the appropriate conditional access software to the mobile receiver. This software provider may, in practice, be the same entity as the broadcaster; alternatively it may be a third party broker who provides the application, AC , to the receiver. The mobile user needs to be aware of which software provider can deliver the application, AC . He may be informed of this by either the broadcaster or the software provider. The mobile receiver is therefore in a position to download AC from the software provider and descramble the broadcast service, subject to the appropriate commercial agreements.

M B S CA TPM AB AC AD

CertX KX,Y RX EK (Z) SealI (Z)

H MACK (Z) SX (Z)

p g

5.2. Notation The following notation is used in the specification of the protocols:

aX bX X||Y

denotes the mobile receiver denotes the broadcaster denotes the software provider denotes a certification authority trusted by S and M denotes a secure TPM chip embedded on the mobile receiver denotes a trusted broadcast application denotes the conditional access application which is downloaded denotes a trusted application/agent responsible for the secure download of conditional access software is a public key certificate for entity X denotes a secret key possessed only by X and Y is a random number issued by entity X is the result of the symmetric encryption of data Z using the key K is the result of the encryption of data Z concatenated with integrity metrics, I, such that Z can only be deciphered and accessed if the software state of the platform is consistent with I is a one-way hash function is a Message Authentication Code, generated on data Z using key K is the digital signature of data Z computed using entity X’s private signature transformation is a prime number is a generator for Diffie-Hellman key exchange modulo p, i.e. an element of multiplicative order q (a large prime dividing p − 1) modulo p is entity X’s Diffie-Hellman private key is entity X’s Diffie-Hellman public key = g aX mod p is the result of the concatenation of data items X and Y in that order

5.3. Assumptions In describing the protocols the following is assumed: 1. The mobile receiver M can support multiple execution environments, or system partitions. Within a protected partition applications may run in isolation, free from being observed or compromised by software running in any other partition. Trusted applications running in the protected environment should have access to a TPM. 2. We assume the presence of chipset extensions which allow memory protection policy to be enforced by providing enhancements to prevent physical attacks such as direct memory access. 3. We assume the presence of a TPM as described in version 1.2 of the TCG specifications. 4. We imply the use of the TPM command set and data structures as specified by the TCG. TPM commands and data structures used in the protocols include T P MCreateW rapKey , T P MCertif yKey , T P MQuote, T P MSeal . We will also utilise the exclusive transport session mechanism as described in version 1.2 of the TCG specifications [22–24]. 5. All secret keys required by the mobile receiver are protected and are only accessible via the TPM. 6. The TPM has a certificate CertT P M issued by a certification authority CA. This certificate associates the identity of a TPM with a public key value. 7. The software provider S has a certificate CertS issued by the certification authority CA. This certificate associates the identity of the software provider with a public key value. 8. For the second protocol proposed, the software provider’s certificate CertS contains public DiffieHellman parameters g and p. 9. The software provider S is able to look up or otherwise obtain, e.g. from a validation authority, the expected values of trustworthy integrity metrics reflecting the software environment which may be running on the platform. 10. The mobile device wishing to receive a controlled video broadcast has a trusted broadcast application, AB , running in the trusted partition. 11. The mobile device has requested and received a conditional access download application, AD , also running in the trusted partition, which is specific to the particular broadcast application running on the device.

5.4. Protocol initiation Both protocols begin when the user makes a request to the broadcast application, AB , to view a specific video broadcast. If reception of this broadcast is controlled by a particular conditional access application, AC , then AB carries out the following steps: 1. AB checks to see if the mobile device already has dedicated hardware or software installed to support AC . 2. If no dedicated hardware exists on the mobile device then AB determines whether AC has previously been downloaded, and is still available in secure storage. If so, the download application, AD , is called to retrieve AC from secure storage and execute the application. 3. If AC is not available on the mobile device, then AD is called to download the application. 4. The download of AC will be accomplished by deploying one of the following protocols.

5.5. Protocol one 1. AD → S : Request for application AC 2. S → AD : RS 3. AD → T P M : request to generate a new asymmetric key pair AD (private) and AD (public); and to SealI (AD (private)), where I represents the software state of the platform. In this instance the T P MCreateW rapKey command is called, where input operands include information about the key to be created, authorisation data for the sealed key, and the handle of the key used in key wrapping. What is returned is a wrapped key of type T P MKey , which includes the public portion of the key, the encrypted private key, and any associated PCR information. 4. T P M → AD : T P MKey 5. AD → T P M : Request for certification of public key generated above in conjunction with platform attestation. In this instance the command sent to the TPM is the T P MCertif yKey command. T P MCertif yKey uses as input; the key handle or key identifier of the key chosen to certify the public key, the handle of the key to be certified and 160 bits of externally supplied data (which in protocol one consist of a 160 bit nonce RS ). 6. T P M → AD : ST P M (AD (public) || I || RS ) 7. AD → S : ST P M (AD (public) || I || RS ) 8. S retrieves CertT P M created by a particular CA, verifies it and then verifies the signature on the data received: ST P M (AD (public) || I || RS )

9. S checks RS to ensure the message has not been replayed. 10. S verifies the integrity values, I, received.

11. AD → S : ST P M (RS || I || bM ) 12. S verifies CertT P M created by a particular CA, verifies it and verifies the signature on the data received ST P M (RS || I || bM ).

11. If the outcome of this decision process is positive, then S Generates: K1S,AD used for data encryption S Generates: K2S,AD used for data integrity protection

13. S checks RS to ensure the message has not been replayed.

12. S → AD : SS (EAD (public) (K1S,AD , K2S,AD )) || EK1S,AD (MACK2S,AD (AC ))

15. S calculates KS,AD and derives K1S,AD and K2S,AD

5.6. Protocol two

14. S verifies the integrity values received. 16. S → AD : EK1S,AD (MACK2S,AD (AC ))

3. S → AD : SS (RS || bS || CertS )

In this second protocol it is possible the platform may be tampered with, between the seal and attest operations. However, version 1.2 of the TCG specification provides a mechanism, the exclusive transport session, that can thwart this potential threat. In this case the trustworthy AD will insist that an exclusive transport session is set-up before any interaction with the TPM is attempted. Once an exclusive transport session is underway, any TPM command made outside the exclusive session between the AD and the TPM, will lead to the exclusive session being aborted. Thus, if anything alters the state of the platform after the exclusive session has been initiated, a T P MExtend command will be initiated, updating the PCRs, and interrupting the session. Such an interruption would reset or abort the protocol.

4. AD verifies the signature upon the message received and extracts g and p from CertS

5.7. Protocol close

Bearing in mind that our focus is on the mobile device, which may be resource limited, the method proposed below makes use of symmetric encryption as opposed to more resource intensive asymmetric techniques. It also has the advantage that less calls are made to the TPM thereby ensuring that it does not become a bottleneck. 1. AD → S : Request for application AC 2. S chooses a Diffie-Hellman private value aS and calculates bS based on g and p which are contained in CertS

5. AD chooses a Diffie-Hellman private value aM and calculates bM based on g and p which were delivered in CertS 6. AD calculates shared key KS,AD = g aM aS mod p 7. AD uses KS,AD to derive K1S,AD used for data encryption and K2S,AD used for data integrity protection 8. AD → T P M : request to SealI (K1S,AD , K2S,AD ), where I is integrity information. In this instance the T P MSeal command is called where incoming operands will include the handler or identifier of the key that can perform the seal operation, the authorisation data necessary to unseal the data, the PCR selection information and the data, in this case the symmetric keys to be sealed to the platform. 9. AD → T P M : Request for attestation (RS || bM ) The T P MQuote command is called so that the signature of the TPM can be sent on both external data and the current PCR values. In this instance the external data will need to contain not only the challenger nonce but also the bM value, so the 160-bit external data entry will consist of a hash of the nonce and the bM value. 10. T P M → AD : ST P M (RS || I || bM )

Finally, when the broadcast application, AB , needs to access and execute the conditional access system, AC , it calls AD to unseal the keys so that the application can be decrypted. This can only occur if the software state, I, of the trusted environment has not been altered. Once AC has been decrypted, it is executed in protected memory where AB may communicate with it over secure channels. Once the application has run, it is either deleted or the encrypted copy is stored for future use.

6. Protocol analysis Formal analysis of the protocols specified above has been successfully performed by Delicata [4]. This analysis is based on a process-algebraic representation of the protocol and uses the concept of a rank function [18] to enable the proof of properties such as authentication and confidentiality.

7. Conclusion The protocols presented above allow a mobile receiver to demonstrate to a software provider that it is running a trusted platform. Based on this the software provider can be confident that his application will not be tampered with. In

this way the user may therefore be given access to a wider range of applications, including those required to decipher proprietary broadcast scrambling systems and, ultimately, the services protected by those systems. Although this paper has focussed on the secure download of conditional access applications, it is clear that other applications that require a trusted platform could also make use of these protocols.

Acknowledgments The work reported in this paper has formed part of the Core 3 Research programme of the Virtual Centre of Excellence in Mobile and Personal Communications, Mobile VCE, www.mobilevce.com, whose funding support, including that of EPSRC, is gratefully acknowledged. Fully detailed technical reports on this research are available to Industrial Members of Mobile VCE.

References [1] B. Balacheff, L. Chen, S. Pearson, D. Plaquin, and G. Proudler. Trusted Computing Platforms: TCPA Technology in Context. Prentice Hall, 2003. [2] CENELEC. Common Interface Specification for Conditional Access and other Digital Video Broadcasting Decoder Applications. CENELEC Standard 50221, European Committee for Electrotechnical Standardization (CENELEC), Brussels, Belgium, Feb. 1997. [3] D. J. Cutts. DVB Conditional Access. Electronics and Communications Engineering Journal, 9(1):21–27, Feb. 1997. [4] R. Delicata. An Analysis of Two Protocols for Conditional Access in Mobile Systems. Technical report, Department of Computing, University of Surrey, 2004. [5] P. England, B. Lampson, J. Manferdelli, M. Peinado, and B. Willman. A Trusted Open Platform. IEEE Computer, 36(7):55–62, July 2003. [6] ETSI. Digital Video Broadcasting (DVB); Support for use of Scrambling and Conditional Access (CA) within Digital Broadcasting Systems. ETSI Technical Report ETR 289, European Telecommunications Standards Institute (ETSI), Sophia Antipolis, France, Oct. 1996. [7] ETSI. Digital Video Broadcasting (DVB); Head-End Implementation of DVB Simulcrypt. ETSI Standard TS 103 197 V1.3.1, European Telecommunications Standards Institute (ETSI), Sophia Antipolis, France, Jan. 2003. [8] Intel. LaGrande Technology Architectural Overview. Technical report, Intel Corporation, 2003. [9] D. Lie, C. Thekkath, M. Mitchell, P. Lincoln, D. Boneh, J. Mitchell, and M. Horowitz. Architectural Support for Copy and Tamper Resistant Software. In ASPLOS-ix, pages 169 – 177. ACM, Nov. 2000. [10] J. Marchesini, S. Smith, O. Wild, and R. MacDonald. Experimenting with TCPA/TCG Hardware. Technical Report 2003476, Dartmouth PKI Lab, Dartmouth College, Hanover, New Hampshire, USA, Dec. 2003.

[11] A. Menezes, P. van Oorschot, and S. Vanstone. Handbook of Applied Cryptography, volume 6 of Discrete Mathematics and its Applications. CRC Press, London, UK, Oct. 1996. [12] Microsoft. Hardware Platform for the Next-Generation Secure Computing Base. Technical report, Microsoft Corporation, 2003. [13] Microsoft. NGSCB: Trusted Computing Base and Software Authentication. Technical report, Microsoft Corporation, 2003. [14] Microsoft. Security Model for the Next-Generation Secure Computing Base. Technical report, Microsoft Corporation, 2003. [15] M. Peinado, Y. Chen, P. England, and J. Manferdelli. NGSCB: A Trusted Open System. In H. Wang, J. Pieprzyk, and V. Varadharajan, editors, Proceedings of 9th Astralasian Conference on Information Security and Privacy, ACISP 2004, volume 3108 of Lecture Notes in Computer Science, pages 86–97, Berlin, Germany, July 2004. Springer-Verlag. [16] B. Pfitzmann, J. Riordan, C. Stuble, M. Waidner, and A. Weber. The PERSEUS System Architecture. Technical Report RZ 3335 (#93381), IBM, IBM Research Division, Zurich Laboratory, Apr. 2001. [17] A.-R. Sadeghi and C. Stuble. Taming “Trusted Platforms” by Operating System Design. In K. Chae and M. Yung, editors, Proceedings of Information Security Applications, 4th International Workshop, (WISA 2003), volume 2908 of Lecture Notes in Computer Science, Berlin, Germany, Aug. 2003. Springer-Verlag. [18] S. A. Schneider. Verifying Authentication Protocols with CSP. In Proceedings of the 10th Computer Security Foundations Workshop, pages 3–17. IEEE Computer Society Press, 1997. [19] G. E. Suh, D. Clarke, B. Gassend, M. van Dyke, and S. Devadas. The AEGIS Processor Architecture for Tamper– Evident and Tamper-Resistant Processing. In Proceedings of the 17th Annual ACM International Conference on Supercomputing (ICS’03), pages 160 – 171, San Francisco, June 2003. ACM Press. [20] TCG. TCG Software Stack (TSS) Specification. TCG Specification Version 1.1, The Trusted Computing Group, Portland, OR, USA, Aug. 2003. [21] TCG. TCG Specification Architecture Overview. TCG Specification Revision 1.2, The Trusted Computing Group, Portland, OR, USA, Apr. 2003. [22] TCG. TPM Main Part 1 Design Principles. TCG Specification Version 1.2 Revision 62, The Trusted Computing Group, Portland, OR, USA, Oct. 2003. [23] TCG. TPM Main Part 2 TPM Structures. TCG Specification Version 1.2 Revision 62, The Trusted Computing Group, Portland, OR, USA, Oct. 2003. [24] TCG. TPM Main Part 3 Commands. TCG Specification Version 1.2 Revision 62, The Trusted Computing Group, Portland, OR, USA, Oct. 2003. [25] W. Tuttlebee, D. Babb, J. Irvine, G. Martinez, and K. Worrall. Broadcasting and Mobile Telecommunications: Interworking — Not Convergence. EBU Technical Review, 293:1–11, Jan. 2003.