New Attestation Based Security Architecture for In ... - Semantic Scholar

New Attestation-Based Security Architecture for In-vehicle Communication Hisashi Oguma∗ , Akira Yoshioka∗ , Makoto Nishikawa∗ , Rie Shigetomi† , Akira Otsuka† and Hideki Imai† ∗

†

Toyota InfoTechnology Center, Co., Ltd. 6-6-20 Akasaka, Minato-ku, Tokyo 107-0052 Japan Research Center for Information Security, National Institute of Advanced Industrial Science and Technology 1-18-13 Sotokanda, Chiyoda-ku, Tokyo 101-0021 Japan

Abstract—This paper presents a novel security architecture for in-vehicle communication. The ratio of electronics to vehicle equipment is steadily increasing. And novel vehicles will also have connectibility to public networks to provide many kinds of services. Therefore, they are expected to suffer from a wide variety of threats and the electronic control units (ECUs) embedded in them may execute execute malicious programs because of tampering. The remote attestation scheme with the Trusted Platform Module (TPM) has been attracting a great deal of attention to cope with such issues. However, it is not feasible for vehicle systems because the conventional attestation process cannot adapt to in-vehicle communication and TPM cannot adapt to time-constrained vehicle systems. We propose an attestation based security architecture that is suitable for novel vehicles.

I. I NTRODUCTION The past four decades have witnessed an exponential increase in the number and sophistication of electronic systems and vehicles. Today, the cost of electronics in luxury vehicles can amount to more than 23 percent of the total manufacturing cost. Analysts estimate that more than 80 percent of all automotive innovations now stems from electronics. These days most vehicle services are implemented with such electronics devices, which are called electronic control units (ECUs). All ECUs can communicate with one another through controller area network (CAN). As well as inside vehicle communication, technological innovations enable novel vehicles to achieve both inter-vehicle and road-to-vehicle communications. Furthermore, novel vehicles will be able to connect to the Internet to supply an extensive number of services. For these reasons, we can easily assume that novel vehicles will suffer from a wide variety of threats, such as networkconnected computers. If an ECU is in trouble because a malicious program is running on it, it might advertise the wrong information (i.e., collision-avoidance), and the transportation system might therefore be paralyzed. Because of this background, we have to consider a security scheme for ECUs to counter any threats as well as conventional computers. In a general-computer system, it is better to execute the supposed code without tampering with the computers. To satisfy this requirement, all the codes and processing units should be stored in a tamper-free device. However it is not feasible to introduce such expensive devices and we lose the convenience of updating the software. Hence,

we have to pay attention to remote attestation, which offers flexible maintenance and executes safe codes on computers. To enable remote attestation, the Trusted Computing Group (TCG) has proposed the Trusted Platform Module (TPM). TPM is a tamper-free security chip and it measures targeted software. In remote attestation, a verification server that is located away from the target platform collects and checks the measurement results. The number of ECUs embedded in vehicles is steadily increasing and we can categorize them into the following kinds. 1) The first are sensor ECUs. They collect real-world information and send it to management ECUs. 2) The second are management ECUs. They consider the situation based on real-world information and manage actuator ECUs to maintain vehicle systems. 3) The last are actuator ECUs. They work under orders from the management ECUs. They communicate with one another through vehicle networks, such as CAN, Local Interconnect Network (LIN), and FlexRay. In this scenario, we assumed that each 1) and 3) would have simple functions, and vehicles would have a large number of 1) and 3). Therefore, these 1) and 3) have to be inexpensive. Furthermore, 1), 2) and 3) must be tamper-proof. This is because a tampered ECU may cause trouble as we previously mentioned. To avoid this, we can easily come up with adopting a remote attestation scheme with the TPM in all ECUs. However, it is difficult to adopt this because most ECUs have few resources and vehicle systems generally require low latency. Furthermore, vehicles can not always communicate with their verification server for attestation schemes (i.e., in tunnels or underground parking spaces). This paper proposes an attestation-based security architecture for in-vehicle communication. We assume that a novel vehicle will have many ECUs with fewer resources and several with rich resources. We let resource-rich ECUs be Masters. A Master ECU verifies other ECUs similar to a verification server. Furthermore, we adopt secret key cryptography based on Key Predistribution System (KPS), and we let each pair of ECUs have a separate key. Our basic experiments demonstrate the effectiveness of our proposed architecture.

978-1-4244-2324-8/08/$25.00 © 2008 IEEE. This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE "GLOBECOM" 2008 proceedings.

II. R ELATED W ORKS

to the rest of the low-cost ECUs.

A. In-vehicle Communication

B. Remote Attestation

Wolf, Weimerskirch, and Paar discussed trends in in-vehicle communication [9], and pointed out that as in-vehicle communication systems evolve from LIN, and CAN to more sophisticated networks such as FlexRay, the exposure of automotive bus systems to attackers may cause problems. They also proposed a countermeasure to these new increased risks, an example implementation being a combination of (1) controller authentication, (2) encrypted communication, and (3) gateway firewalls. They required authentication of all senders to ensure that only valid controllers were able to communicate, and all unauthorized messages were processed separately or immediately discarded. To achieve this authentication, they required all controllers to hold a public-key certificate issued by the manufacturers. The gateway is responsible for checking the validity of the certificates, conducting an authentication process with the controller, and managing a list of authorized controllers. The gateway manages communication keys for symmetric encryption used in all sub-networks and sends one of the symmetric keys to all authorized controllers. All communications in a sub-network of authorized controllers are encrypted by the symmetric key allocated by the gateway. Communication over different sub-networks is intermediated by the gateway, and it acts as a firewall so that only authorized senders can send messages to some specific sub-networks. This approach is similar to ours described in the following sections in that (1) the authorization process, usually considered as a heavy process, is centralized to gateway (we call this the Master ECU), (2) symmetric key encryption, which is relatively light-weight, is used for all communication. However, there is different in that (1) a PKI-based authorization process is used in their system, which requires all controllers (ECUs) to be equipped with PKI capabilities and this results in cost-increases for each controller, whereas our proposal uses the Key Predistribution System (KPS), which is much faster and more cost-effective. (2) Their authorization process only checks whether controllers (ECUs) have secret key corresponding to their certificates, whereas ours checks whether there is a software hash-code in a list of valid hashcodes as well as doing a key-possession check. This process is greatly simplified from that proposed by TCG. Stephan, Richter and M¨uller discussed details on the challenge [6] of trusted software flashing of ECUs. Developers and after-sales services are interested in remote software flashing via networks so that they can ensure all vehicles have correct and up-to-date versions of software in their ECUs. They simultaneously pointed out the misuse of flashing by unauthorized persons to enhance engine power, calibrate sportive shock absorbers, and improve braking behavior. Adelsbach, Huber, and Sadeghi discussed secure software delivery to vehicle systems [1] based on public key broadcast encryption [3] and a sealing technique that only permits software with a specified hash code to decrypt the content [8]. Similar techniques can be applied in our approach intermediated by the Master ECU

The TCG has introduced TPM v1.2 specifications [7] [8], that propose protocols and standards for remote attestation. Remote attestation is the means by which a remote verification server ensures that a target computer is trustworthy. It assumes that a TPM is embedded in the target computer. In the series of remote attestations, the Core Root of Trust for Measurement (CRTM), which is a BIOS boot block code that is considered trustworthy, measures other parts of the BIOS block before passing control. After measurement, the CRTM stores the results into the Platform Configuration Register (PCR), which is in the TPM. The BIOS then measures the bootloader and passes control to this. The bootloader measures the OS kernel and passes control to the OS. The same as CRTM, the BIOS and bootloader also store all measurements into all PCRs and a trust chain is established as a result. After the OS is loaded, the target computer calculates a response value based on all the PCR values and the challenge received from the verification server. The remote computer then receives the response value and verifies whether the code on the target computer is safe or not. Stable connectivity with the verification server is required in this scheme. However it is difficult to adopt into vehicles because they are mobile. We let Master ECU have attestation capabilities in our proposed scheme and it can create trust chains with other ECUs. All ECUs can create make a trust relationship through the intermediation of the Master ECU. C. Key Predistribution System In this paper, we make use of the term Key Predistribution System [4] (KPS) in place of public key cryptography. The following is a brief definition. Definition 1: The KPS consists of a center and multiple players Pi (i = 0, 1, 2, . . .). Let q be a prime power. Let T be a security parameter. The management center (i.e., vehicle manufacturer) randomly generates an (T +1)× (T +1) matrix A = {aij } and defines a bi-variate polynomial, X aij xi yj (mod q) F (x, y) = 0≤i,j≤T

where aij = aji . Then, the center delivers a key generation algorithm, Fi (x) = F (x, i) to each player, Pi (i = 0, 1, . . . ). A shared key, K, between any two players, say Pi and Pj , is generated by K = Fi (j) at Player Pi and by K = Fj (i) at Player Pj . Obviously Fi (j) = Fj (i). KPS is information-theoretically secure up to the collusion (or key exposure) of T players. In our security architecture for in-vehicle communication, KPS is used as follows. A vehicle manufacturer plays the role of the center in the above definition. Each ECU in a vehicle plays a role of a player, hence Fi (x) is securely distributed to the ECU with number i through an authenticated secure channel between the center and each ECU.

978-1-4244-2324-8/08/$25.00 © 2008 IEEE. This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE "GLOBECOM" 2008 proceedings.

The advantages of KPS over public key cryptography in invehicle communication is that (1) the total number of ECUs implemented in one vehicle is fixed; thus, maximum collusion does not exceed the number of ECUs, hence T ≤ #{ECU}, and (2) the number of ECUs in one vehicle is normally within the range of 30 to 300. Thus, we can set security parameter T at most in this range. With this range of T , KPS is much faster than public key cryptography such as RSA or even elliptic carve cryptography. Note that to impersonate an uncorrupted ECU, one must tamper with at least (T + 1) ECUs and extract the key generation algorithm, Fi (x), from (T + 1) of tamperresistant module implemented in each ECU. III. P ROPOSED A RCHITECTURE What are specifically requirements for a security architecture in in-vehicle communication compared with other IT products can be described as follows. First, long-term security is required. Vehicles have a relatively long life, usually more than 10 years, compared with other IT products. The same model will also continue to be sold for 5 to 10 years. Thus, security parameters, such as cryptographic key length, must be chosen to survive for at least 15 to 20 years. Next, some ECUs are composed of time-critical control systems. The control systems in vehicles typically require each ECU to respond within 1ms. Any additional cryptographic operations facilitated for authentication and encrypted communication must complete operation in much less time than 1ms. At the last, recent luxury vehicles already have 100 ECUs and the number of ECUs has been growing. However, the space in vehicles is limited and it is difficult to embed them with a huge number of ECUs. Therefore, the trends in vehicle-electronics design are to integrate vehicle functions into several resource-rich ECUs, which cooperate with a lot of resource-poor ECUs to acquire information and create appropriate vehicle movements. Thus, any additional functions that are installed should be very reliable, very inexpensive, and have a low impact on existing vehicle functions. A. Requirements Once a vehicle is sold to users, all ECUs in the vehicle will be controlled by them, and some users may try to modify some of their functionalities. Regardless of whether they have malicious intentions or not, modifications to some ECUs may cause serious problems. In-vehicle control systems are becoming increasingly more complex. In X-by-wire systems, every control signal is represented as sending or receiving messages to/from ECUs over an in-vehicle network. Furthermore, in safety systems involving inter-vehicle and road-to-vehicle communication, an emergency brake signal may arrive from outside via an external communication channel to in-vehicle control systems when the vehicle is about to collide. Thus, ill-considered or malicious modifications to an ECU hardware/software configuration may result in unpredictable behavior. To reduce the

TABLE I M AJOR C OMPONENTS

Components

Center

Master ECU

ECU

Stored Information and Cryptographic Keys (Ey , Ky ): list of shared keys Ky with component Ey (version, H(ROM)): list of hash value for each ROM, (type, version): list of ROM versions for each vehicle, (V, {Aij }): list of KPS matrices {Aij } for each vehicle V. M(= Em ): identification number of Master ECU Km : shared key with Center (version, H(ROM)): list of acceptable hash values Fm (y): KPS key generation algorithm Ex : identification number of ECU Kx : shared key with Center Fx (y): KPS key generation algorithm

risk of unforeseen behaviors, we need a security architecture where each ECU is able to check whether the other ECUs are genuine and whether a series of information processes from sensors and several service-management units to actuators are only processed through genuine ECUs. The requirements for a security architecture can be summarized as follows: 1) Authentication of Software Configuration Each ECU only communicate with ECUs whose software configurations have been certified by the manufacturer. 2) Authenticated and Encrypted Communication All communication between ECUs should be capable of proving the authenticity of the ECUs and the integrity of their messages, and even being encrypted. Any unauthenticated message should be separately processed or immediately discarded. 3) Flexibility of Replacement The above authentication or integrity check should work even if a ECU has been replaced with a new one and even if its software of ECU has been remotely updated. B. In-vehicle Communication Architecture Figure 1 has an overview of our proposed security architecture. Let {m}k denote an authenticated encryption of message m with key k such as in AES-CMAC [5]. Let Sigk (m) denote a symmetric-key message-signature pair using a keyed-hash function such as in HMAC [2]. The complete message form is (m, Hk (m)) where H· (·) is a keyed-hash function. Our proposed architecture consists of the center, Master ECU, and various ECUs. Each vehicle V is assumed to have one Master ECU, Em , and some ECUs Ex ∈ {E0 , E1 , . . .}. The center manages (1) a list of all valid software versions and their ROM hash values and their combinations for each vehicle type, denoted by a list of (version, H(ROM)) and a list of (type, version), and (2) shared symmetric key Ky to set up a secure channel with other components, Ey , such as the Master ECU and ECUs. Further, (3) the KPS key-generation matrix {Aij }, which is randomly and independently generated

978-1-4244-2324-8/08/$25.00 © 2008 IEEE. This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE "GLOBECOM" 2008 proceedings.

Fig. 1.

Overview of In-vehicle Communication

for each vehicle, is identified by V. The Master ECU holds (1) a key, Km , shared with the center to set up a secure channel, (2) a list of acceptable hash values for a type of vehicle in which this Master ECU is implemented and (3) a KPS key-generation algorithm, Fm (y). Each ECU holds (1) a key, Kx , shared with the center to set up a secure channel and (2) a KPS key generation algorithm, Fx (y), delivered during the initialization phase through the secure channel. This is summarized in Table I. 1) Initialization at Production: First, the Master ECU at the time of factory production is assumed to have a unique pair of a serial number and a key, (Em , Km ), and this pair is securely sent to the center. The Master ECU is then shipped to an assembly factory. At a certain stage of assembly, the following protocol (Table II-(A)) is executed to initialize the Master ECU. (Step 1) The Master ECU identifies itself by sending its serial number Em to the center. Then, the center, C, retrieves Km from Em and generates a random number, Rm , to be used as a session key. (Step 2) The center sends Rm encrypted by Km to the Master ECU. The Master ECU decrypts Rm , and (Step 3) the Master ECU attempts attestation with its newly measured H(ROMm ), and identifies its vehicle number V. (Step 4) The Center verifies the attestation of the Master ECU, and if the measured H(ROMm ) is in the list of valid hash values of the Master ECU’s ROM, it then randomly generates KPS matrix {Aij }, and sends Fm (y) and a list of valid (version, hash) pairs for each ECU. Each ECU is also assumed to have a unique pair of a serial number and a key: (Ex , Kx ) and this pair is securely sent to the center. At the time of final assembly, each ECU conducts a similar protocol to the Master ECU (Table II-(A)). The difference is in (Step 4), where the center sends a KPS key-generation algorithm and the correct hash value of the Master ECU’s ROM, H(ROMm ), to the ECUs. After the above protocol is executed, all the Master ECU

TABLE II I NITIALIZATION AT P RODUCTION (A) Initialization of Master ECU: Em (Step (Step (Step (Step

1) 2) 3) 4)

: : : :

Em → C C → Em Em → C C → Em

(Em , TYPE = MasterECU) {Rm }Km {V, H(ROMm )}Rm {Fm (y), {(version, H(ROMx ))}}Rm

(B) Initialization of each ECU: Ex (Step (Step (Step (Step

1) 2) 3) 4)

Ex → C C → Ex Ex → C C → Ex

: : : :

(Ex , TYPE = ECU) {Rx }Kx {V, H(ROMx )}Rx {(Fx (y), H(ROMm ))}Rx

C: Center, Em : Master ECU, Ex : ECU, V: Vehicle Number

and other ECUs store the necessary information as described in Table I. 2) Initial Attestation Protocol: When a driver starts a vehicle, the following initialization occurs at the time the bootstrap protocol is run. Also see Table III. (Step 1) The Master ECU generates random numbers r1 , r2 , and broadcasts r1 to all ECUs. (Step 2) Each ECU runs an attestation process to the Master ECU using a random number, r1 . It measures the hash value of its ROM, H(ROMx ), and send this to the Master ECU SigFx (Em ) {Ex , H(ROMx ), r1 , r}, where r1 is used to refresh make this attestation message in every execution of the protocol and r is used as a challenge to the following attestation protocol run by the Master ECU. (Step 3) The Master ECU checks whether the attestation message is correct, i.e., that the signature is correctly confirmed using key Fm (Ex ) and the newly measured hash value from the ECU is in a list of valid hash values. If all these checks pass, the Master ECU measures its hash value, H(ROMm ), and sends back {r2 , r, H(ROMm )}Fm (Ex ) to the ECU Ex .

978-1-4244-2324-8/08/$25.00 © 2008 IEEE. This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE "GLOBECOM" 2008 proceedings.

TABLE III I NITIAL ATTESTATION P ROTOCOL (Step 1) Em → all : (Step 2) Ex → Em : (Step 3) Em → Ex :

broadcast r1 SigFx (Em ) {Ex , H(ROMx ), r1 , r} {r2 , r, H(ROMm )}Fm (Ex )

r1 , r2 : Random numbers generated by Master ECU r: Random number independently generated by each ECU

3) Secure and Authenticated Communication: After the initial attestation protocol, each ECU Ex (x ∈ {0, 1, . . .}) that succeeded in the attestation process stores r2 in its secure storage as well as the initial keys as in Table I. To achieve the security requirement described in Section III-A, our construction has the following three features: (1) an encryption key for every pair of ECUs is generated by KPS, (2) each message contains r2 in an encrypted form as evidence that the sender has been accepted through attestation against the Master ECU, and (3) each message contains a counter that prevents a so-called replay attack. The message formats are given in the following. • Encrypted Message (Ex → Ey ) {payload, r2 , counter}Fx (y)

•

where the notation {m}k means authenticated encryption of message m with key k such as AES-CMAC. Signed Message (Ex → Ey ) (payload, counter), HFx (y) (payload, r2 , counter)

where Hk (m) is a keyed-hash of message m with key k such as HMAC. A counter is used to prevent replay attacks. We assume each ECU has a sending counter and a set of receiving counters where each receiving counter corresponded to one of the other ECUs, denoted by counter(x), where x ∈ {0, 1, . . .}. When submitting a message, the ECU increments its sending counter and places its counter value in the message. When receiving a message from ECU Ex with the counter value, c, in the receiving message, the ECU checks its counter value by using the following inequality: counter(x) < c < counter(x) + K where K is some constant such that 2|counter| À 2|K| is determined by the frequency of receiving message and the packet loss rate. Once this check and cryptographic verification have succeeded, the counter is updated as follows: counter(x) ← c. IV. E VALUATION AND A NALYSIS We have developed an experimental environment to compare the performance of the TPM-based architecture with the one we propose. The TPM-based architecture we compare is designed similarly to ours except that it is based on PKI/RSA, in which we assume one Master ECU acting as a certification

authority. The Master ECU signs the certificate of an ECU after it has succeeded in its attestation process with the Master ECU. With this certificate, authenticated or private communication between ECUs is conducted based on RSA signature/encryption. The most computationally intensive part for the TPM is signing (TPM ORD Sign) and decrypting (TPM ORD UnBind). In these experiments, we have configured a payload of 16 bytes and use an Intel Core 2 Duo based PC, which has 1.06GHz CPU and 1GB RAM. Table IV shows the performance of our proposed architecture for all protocols described in the previous section. It reveals that the initial attestation process requires a bursty load to the Master ECU. In a vehicle with 200 ECUs, if we set T =100 corresponding to 50% of the number of ECUs, it requires 8.940ms for the Master ECU to process all the attestation protocol from all 200 ECUs. Table V compares the performance of several platforms. If we compare (A) KPS and (B) RSA, we can easily see that KPS is much faster than RSA. Taking marginal security parameters such as RSA1280 (aggressive in security) and KPS T =300 (conservative in security), where RSA1280 is estimated to be broken within one year around the year 2020 by the world’s fastest computer and where T =300 is possibly assumed to be 50% of the number of ECUs implemented in a vehicle around 2020, our KPS-based architecture is 42 times faster than the RSA-based one. Longer RSA keys and a smaller KPS threshold T will further broaden the speed gap. The cost of breaking RSA1280 in 2020 is roughly estimated to be $109 ∼ $1010 . However, it is generally difficult to estimate the cost of breaking 300 tamper-resistant devices. If the average cost of recovering a key from one tamper-resistant device is estimated to be $10,000 without breaking almost any of the original device, the total cost is only $3,000,000. However, it is usually not easy to recover keys without any faults. More realistic scenario is, with some probability, p ∈ [0, 1], an attacker succeeds in recovering a key from one ECU, but with probability, (1−p), the attacker fails to recover a key from the ECU and completely destroys it by the attack. In this setting, the probability for the attacker to succeed in recovering more than T keys out of N ECUs follows a binominal distribution: µ ¶ N X N k p (1 − p)N−k . P (X > T ) = k k=T +1

For large N , the probability distribution can be approximated with normal distribution N (µ, σ2 ) where µ = Np and σ = p N p(1 − p). In the case N = 600, T = 300 and p = 0.4, the average number of keys successfully recovered from one vehicle is (µ =)240 and its standard deviation is (σ =)12. Therefore, the probability that the number of recovered key exceeds 300(= T ) is approximately 3 × 10−7 . This means millions of vehicles have to be broken to recover more than 300 keys from one vehicle. Assuming the average cost of getting a vehicle to be $10,000 and zero cost for tampering each ECU, the total cost is $3 × 1010 which is comparable with the RSA1280 case.

978-1-4244-2324-8/08/$25.00 © 2008 IEEE. This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE "GLOBECOM" 2008 proceedings.

TABLE IV P ERFORMANCE OF P ROPOSED A RCHITECTURE (A) Initial Attestation Protocol Master ECU ECU

T =30 174µs 186µs

T =100 447µs 450µs

T =300 721µs 726µs

T =30 83µs 87µs

T =100 214µs 222µs

T =300 353µs 358µs

T =30 86µs 83µs

T =100 218µs 223µs

T =300 353µs 360µs

[9] M. Wolf, A. Weimerskirch, and C. Paar, “Secure In-Vehicle Communication,” Embedded Security in Cars, Springer Berlin Heidelberg New York, ISBN 978-3-540-28384-3, 2006, pp.95–109.

(B) Encrypted Message Sender ECU Receiver ECU (C) Signed Message Sender ECU Receiver ECU

TABLE V P ERFORMANCE C OMPARISON (A) KPS Performance “decryption” (Intel Core2Duo 1.06GHz) T =30 87µs

T =100 222µs

T =300 358µs

(B) RSA Performance “decryption” (Intel Core2Duo 1.06GHz, OpenSSL) RSA512 1, 247µs ∗ estimated

RSA1024 5, 811µs

RSA1280 (15, 000µs)∗

RSA2048 32, 265µs

V. C ONCLUSION We have proposed a new attestation-based security architecture for in-vehicle communication. It satisfies criteria of (1) authentication of the software configuration, (2) authenticated and encrypted communication, and (3) flexibility of replacement. Our preliminary experiment revealed that our proposed KPS-based architecture has a lower security overhead than the RSA-based one by more than an order of magnitude. We conclude that it can soon be applied even to critical in-vehicle communication. R EFERENCES [1] A. Adelsbach, U. Huber, and A. R. Sadeghi, “Secure Software Delivery and Installation in Embedded Systems,” Embedded Security in Cars, Springer Berlin Heidelberg New York, ISBN 978-3-540-28384-3, 2006, pp.111–122. [2] M. Bellare, H. Krawczyk, and R. Canetti, “Hmac: Keyed-hashing for message authentication,” RFC 2104, February 1997. [3] Y. Dodis and N. Fazio, “Public key broadcast encryption for stateless receivers,” 2002 ACM Workshop on Digital Rights Management, LNCS 2696, Springer-Verlag Berlin Heidelberg New York, ISBN 9783540404101, 2003, pp.61–80. [4] T. Matsumoto and H. Imai, “On the Key Predistribution System: A Practical Solution to the Key Distribution Problem,” CRYPTO 1987: pp.185–193. [5] J. Song, J. Lee, R. Poovendran, and T. Iwata, “The AES-CMAC Algorithm,” RFC 4493, June 2006. [6] W. Stephan, S. Richter, and M. M¨uller, “Aspects of Secure Vehicle Software Flashing,” Embedded Security in Cars, Springer Berlin Heidelberg New York, ISBN 978-3-540-28384-3, 2006, pp.17–26. [7] Trusted Computing Group, Architecture Overview, https://www.trustedcomputinggroup.org/specs/IWG. [8] Trusted Computing Group, TPM Specification Version 1.2, https://www.trustedcomputinggroup.org/downloads/specifications.

978-1-4244-2324-8/08/$25.00 © 2008 IEEE. This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE "GLOBECOM" 2008 proceedings.