Secure Software Upload in an Intelligent Vehicle via Wireless Communication Links

Transcription

1 Secure Software Upload i a Itelliget Vehicle via Wireless Commuicatio Liks Syed Masud Mahmud, Member, IEEE, Shobhit Shaker, Studet Member, IEEE Iria Hossai, Studet Member, IEEE Abstract The demad for drive-by-wire, telematics, etertaimet, multimedia, pre-crash warig, highway guidace, remote diagostic, etc. will sigificatly icrease the complexity of a vehicle s software modules. From time to time, the vehicle s software may eed to be updated due to may reasos such as the itroductio of ew features i vehicles, chagig the avigatio map, fixig software bugs, etc. Software updates must be doe i secure modes to avoid ay future disasters due to malfuctios of the vehicle. I this paper, we propose a architecture for secure software uploads i vehicles. We provide a detailed descriptio of the secure software upload process. Key words Software update, security, key maagemet, itelliget vehicles. I. INTRODUCTION ABOUT half a cetury ago a vehicle was mostly a mechaical device. Today, a sigificat part of a vehicle s maufacturig cost goes towards the implemetatio of electroic compoets. The demad for drive-by-wire, telematics, etertaimet, multimedia, precrash warig, highway guidace, remote diagostic, etc. will sigificatly icrease the complexity of i-vehicle commuicatio etworks, hardware ad software modules. From time-to-time, it will be ecessary to upgrade vehicles software modules. For example, the map of a vehicle s avigatio system may eed to be updated whe ew roads, houses ad offices are built. A compay may eed to moitor its ewly desiged vehicles, via wireless commuicatio liks, to determie the performace of the vehicles i terms of fuel efficiecy, emissio ad other drivig coditios. The compay ca the improve, if Mauscript received December 5, 004. Syed Masud Mahmud is with the Departmet of Electrical ad Computer Egieerig, Waye State Uiversity, Detroit, MI 480 USA (Phoe: ; fax: ; smahmud@eg.waye.edu). Shobhit Shaker is with the Departmet of Electrical ad Computer Egieerig, Waye State Uiversity, Detroit, MI 480 USA ( sshaker@waye.edu). Iria Hossai is with the Departmet of Electrical ad Computer Egieerig, Waye State Uiversity, Detroit, MI 480 USA. ( ihossai@waye.edu) ecessary, the performace of its vehicles by remotely adjustig some software parameters i the vehicles electroic modules. Updatig software modules i the future itelliget vehicles, o a regular basis, will be required to keep the vehicles compatible with the ifrastructure of the itelliget trasportatio system. Remote software upload, via wireless commuicatio liks, has may advatages over upload at a service statio. Some of the advatages are as follows: The cosumers do ot eed to take their vehicles to service statios. Thus, remote software upload operatios will save cosumers valuable time. The persoel at the service statios do ot eed to sped time o vehicles o a idividual basis elimiatig labor costs from the auto maufacturers as well as from the cosumers. The auto maufacturers ca immediately fix bugs or upload ew features i software modules without beig delayed for a log period of time, which may save a sigificat amout of moey from legal costs. To upload software i vehicles, it is critically importat that this be doe i a secure eviromet. Otherwise, the system would be susceptible to security attacks, which will compromise its safety ad fuctioality. This paper presets a mechaism for secure software upload i a itelliget vehicle. The scope of this paper is software upload for oe vehicle oly. Thus, if the same software eeds to be uploaded i multiple vehicles, the the upload operatio must be repeated for each vehicle oe at a time. The rest of the paper is orgaized as follows. Sectio II presets some basic materials o secure commuicatios. Sectio III describes our architecture. Sectio IV shows system requiremets, ad Sectio V presets the coclusios. II. SOME BASIC MATERIALS Durig the last several years, iterest i usig the wireless commuicatio techologies have grow sigificatly. Bluetooth features are becomig very commo i cell phoes, PDAs, laptops, etc. More ad more homes are gettig broadbad coectios ad usig Wi-Fi techology for wireless i-home etworkig. The /05/$

2 automotive idustry has also started itroducig wireless techology, such as Bluetooth, for its i-vehicle etworkig []. If secure wireless etworks ca be implemeted at reasoable costs, the cosumers demad for i-vehicle wireless etworks may icrease sigificatly. The govermet may also madate auto compaies to have wireless etworks i vehicles so that the vehicles ca commuicate with each other to issue pre-crash warigs; ad law-eforcig authorities ca moitor vehicles emissio, speed ad other items related to violatios of traffic laws. Auto compaies ad suppliers must use secure wireless liks to upload software i their vehicles. Otherwise, hackers may tamper with software code durig the uploadig process, leadig to possible disasters durig the operatio of the vehicles. The curret techiques that are used for settig up a secure commuicatio lik are maily cliet-server based techiques such as SSL ad VPN. Brief descriptios of these techiques are show below. A. SSL (Secure Socket Layer) The SSL protocol is the Web stadard for ecryptig commuicatios betwee users ad SSL (secure socket layer) eabled e-commerce sites []. The SSL layer rus o the top of TCP/IP layer. The SSL security protocol provides data ecryptio, server autheticatio, message itegrity, ad optioal cliet autheticatio for a TCP/IP coectio. The SSL protocol icludes two sub protocols [3]: the SSL record protocol ad the SSL hadshake protocol. The SSL record protocol defies the format used to trasmit the data. The SSL hadshake protocol ivolves usig the SSL record protocol to exchage a series of messages betwee a SSL eabled server ad SSL eabled cliet whe they first establish a coectio. This exchage of messages is desiged to facilitate the actios like: autheticatio of the server to the cliet, autheticatio of the cliet to the server, selectio of cryptographic algorithms that they both support, use of public key ecryptio techiques to geerate shared secrets, etc. B. VPN (Virtual private etwork) VPN is a private etwork that uses a public etwork (usually the Iteret) to coect remote sites or users together [4]. Istead of usig a dedicated, real-world coectio such as a leased lie, a VPN uses "virtual" coectios routed through the Iteret from the compay's private etwork to the remote site or employee. VPN maily uses IPSec (iteret protocol ad security) protocol, which i tur uses the tuelig method for makig data packets immue to attacks. IPSec ca ecrypt data betwee various devices, such as router-to-router, firewall-to-router, PC-to-router, PC-to-server, etc. Tuelig is the process of placig a etire packet withi aother packet ad sedig it over a etwork. The etwork ad both parties uderstad the protocol of the outer packet, called the tuel iterface. C. Symmetric ad Public Key Ecryptio There are maily two types of ecryptio techiques: the symmetric-key ad public-key ecryptios [5]. I the symmetric-key ecryptio, both parties use the same key to ecrypt ad decrypt messages. I this ecryptio techique, both parties must have the same key i their system before they are goig to exchage messages. The public-key ecryptio uses a combiatio of a private key ad a public key. A computer (say X) ca sed its public key to other computers with which it wats to establish commuicatios, but it will securely keep its ow private key. A message that is ecrypted by the public key of X, ca oly be decrypted by X usig its private key. The ecryptio/decryptio process usig public/private key mechaism is very time-cosumig compared to that usig symmetric key mechaism. Normally, two parties use the public/private key techique to exchage their symmetric key. For example, if aother computer (say Y), which has the public key of X, wats to establish a secure commuicatio lik with X, the Y geerates a symmetric key ad seds it to X after ecryptig it usig the public key of X. X the uses its private key to decrypt the message set by Y, ad collects the symmetric key from the decrypted message. After that, X ad Y commuicate usig the symmetric key geerated by Y. III. THE PROPOSED ARCHITECTURE FOR SECURE SOFTWARE UPLOAD Here we preset ad discuss the architecture for secure software upload i vehicles electroic modules. We assume that all the vehicles are equipped with wireless iterface uits to commuicate with the ifrastructure of the Itelliget Trasportatio System (ITS). A compay s server ca commuicate with a selected group of vehicles via either the cellular etwork or the ITS ifrastructure. Sice the cell phoe towers cover almost all the road systems of the coutry, the same tower ca also be used as the Itelliget Trasportatio Tower (ITT). A. Autheticatio Keys We assume that at the time of maufacturig a vehicle, a set of autheticatio keys is istalled i the vehicle. The same set of keys is also kept i a cetral server. Every time a vehicle is goig to be autheticated by a ITT, the ITT gets the set of keys of the vehicle from the cetral server, ad uses oe key to autheticate the vehicle. Differet autheticatio keys are used to autheticate the vehicle at differet times. Whe all the keys of the set are used for autheticatig the vehicle, a ew set of keys is geerated ad set to the vehicle. The ew set of keys is also kept i the cetral server. Successive autheticatios of the vehicle are doe usig the ew set of keys. After autheticatig the 588

3 vehicle, the ITT or the cetral server issues a symmetric key to the vehicle. The ITT ad/or the cetral server ca securely commuicate with the vehicle usig the symmetric key. B. Key Maagemet for Software Upload Assume that automotive compay X wats to upload software i oe of its vehicles (say Vehicle V). Let Y be the supplier of the software. X geerates a set of lik keys (P, P,.., P N ) ad seds it to Y usig a secure lik such as SSL or VPN. Note that the lik keys will be used to establish secure liks betwee Supplier Y ad the target Vehicle V. X the securely seds the same set of lik keys to Vehicle V usig either the cellular etwork or the ifrastructure of ITS. Now, both Vehicle V ad the Supplier Y have the same set of lik keys. The supplier ad the vehicle ca establish a secure lik usig oe of these lik keys, say P. Other lik keys will be used to establish future secure liks betwee the vehicle ad the supplier. Sice a give lik key is ot goig to be used more tha oce, both the supplier ad the vehicle delete the key P from the set of lik keys after they have established a secure lik for the first time. After that, the supplier ad the vehicle geerate some symmetric ecryptio keys. Usig these ecryptio keys, the supplier ca sed ecrypted software to the vehicle. Figure shows the key trasfer ad software upload process. Sice each vehicle has its ow set of keys, either the vehicle or the software vedor ca sed ay uauthorized software to other vehicles without the coset of the automotive compay. Automotive Compay X Step: Lik keys P, P,.. P N, are set i secure mode usig SSL, VPN or other techology. Supplier Y Step: Lik keys P, P,.. P N, are set i secure mode usig the previously exchaged symmetric ecryptio key. Vehicle V Step3: a. A secure lik is established usig oe lik key. b. The supplier ad the vehicle exchage a set of symmetric ecryptio key(s). c. The supplier seds software i ecrypted mode. Figure : Key trasfer ad software upload process. C. Sedig Multiple Copies of the Software ca Sigificatly Improve the Security Level To icrease the security level of the software upload process, we recommed that the supplier should sed at least two copies of the software to the vehicle. These two or more copies of the software must be set after some radom time itervals. First, the supplier will establish a secure lik with the vehicle usig oe of the lik keys, ad the sed a copy of the software. After a radom time iterval, the supplier will agai establish a secure lik with the vehicle usig aother lik key, ad sed the secod copy of the software. The vehicle must have memory buffers to keep copies of the software. After receivig both copies of the software, the vehicle checks whether the two copies are exactly same. Sice the two copies of the software are set from the supplier to the vehicle at two differet times, it is very ulikely that a hacker will be able to chage both copies of the software exactly at the same poit i the code. Thus, it is very ulikely that the two copies of the software will be exactly same if oe or both of them are chaged. If the two copies of the software are the same, the vehicle seds a positive ackowledge sigal to both X (automotive compay) ad Y (supplier). If the two copies of the software are ot same, the the vehicle asks the supplier to retrasmit the umatched packets. To avoid hackers from detectig a predicted order of packet trasmissio, the packets of the software ca be set i some radom orders. I that case, eve if a hacker ca chage oe packet of the first copy of the software, it will be difficult for the hacker to detect the same packet i the secod copy of the software. As a result, it will be more difficult for the hacker to chage the same packet i both copies of the software. After receivig two idetical copies of the software, the vehicle iitiates a process for replacig the old software of a module by a copy of the ew software. The process of replacig the old software is iitiated whe the vehicle is ot i motio ad the igitio is off. If the vehicle is i motio, the it may issue a warig to the driver idicatig that ew software is ready to be loaded i a module. The the driver may stop the vehicle ad tur the igitio off at his/her coveiece. The vehicle the keeps a backup copy of the old software i a temporary buffer. After that, the vehicle loads the ew software ito a module. The backup 589

4 copy ca be used to udo the upload operatio if there are ay problems with the vehicle s fuctioality after the upload operatio. After successfully uploadig the software i a vehicle, the automotive compay (X) decides whether or ot to keep the remaiig lik keys i the vehicle. If X determies that Y has o more software to upload, the X seds a sigal to the vehicle to delete the remaiig lik keys. This way, the vehicle ca keep itself protected from ay isider attacks by the employees of Y. I the future, if Y wats to upload aother software i the vehicle, the X issues aother set of lik keys to both Vehicle V ad Supplier Y, ad the etire process of software upload is repeated. D. Oly Oe Copy of the Software Appeded with a Message Digest (MD). If oly oe copy of the software is to be set, the the security level of the upload process ca be icreased by appedig a message digest (MD) with the software. The supplier ca create a 8-bit message digest of the software usig the MD5 algorithm [6]. The supplier ca the ecrypt the message digest ad sed it alog with the software. O the other had, the vehicle ca also create a 8-bit message digest based o the software received by the vehicle. After that, the vehicle ca decrypt the message digest set by the supplier ad compare it with its calculated message digest. If both match, the the vehicle ca accept the software. This particular techique, which uses a message digest (MD), has some disadvatages over the other techique that seds at least two copies of the software. If a hacker ca successfully chage oe packet of the software, the the decrypted message digest will ot match with the vehicle s calculated message digest. As a result, the supplier will eed to retrasmit the etire software, because the supplier does ot kow which particular packet is chaged. If a hacker ca successfully chage a packet of every trasmissio, the the vehicle will ever be able to upload the software. E. Two Copies of the Software with a Message Digest (MD) A better way of uploadig software i a vehicle would be sedig two copies of the software alog with the message digest i each copy. If some packets of the first copy (icludig the message digest) do ot match with the correspodig packets of the secod copy, the the vehicle asks the supplier to sed the umatched packets. After receivig two idetical copies of the software, alog with the message digest, the vehicle calculates a message digest based o the software received from the supplier. The vehicle the compares this calculated message digest with the message digest received from the supplier. If they match, the vehicle accepts the software. If they do ot match, the the hacker was able to chage both copies of some packets (icludig the message digest). The vehicle the asks the supplier oly to sed oe or more copies of ecrypted message digest. The supplier seds the additioal copy(copies) of the message digest after some radom time iterval. After receivig the additioal copy of the message digest, the vehicle compares it with the calculated message digest. If they match, the vehicle accepts the software. Otherwise, the vehicle rejects the software. Figure shows the flow diagram of the software upload process where two copies of the software are set alog with the message digest (MD) i each copy. Yes Yes Vehicle received two copies of the software. Yes Are the two copies same? Received MD = Computed MD? Vehicle requests retrasmissio of MD Received MD = Computed MD? Vehicle accepts the software. Figure : Software upload algorithm. F. Uploadig Software i Multiple Vehicles Software upload i oly oe vehicle will be ecessary if a particular vehicle has some uique problems with its fuctioality. Uploadig software oly i oe vehicle is a uicast process. The scope of our curret work, preseted i this paper, is software upload i oe vehicle oly. However, if the automotive compay wats to add ew features to a large umber of vehicles, the software upload operatios will be required for multiple vehicles. Uploadig software i multiple vehicles is a multicast process. May differet multicast algorithms have bee desiged for mobile devices [7], [8]. Some of these algorithms ca be used to exted our work for software upload i multiple vehicles. We ited to do that i our future work. G. Protectio of Keys i the Servers of the Automotive Compay ad the Software Vedor All keys must be appropriately protected i the servers of No No No Vehicle requests retrasmissio of umatched packets. Vehicle receives umatched packets. Vehicle rejects the software. 590

5 both the automotive compay ad the software vedor. However, this is ot a uique problem with our work. The same problem exists i all security systems. For example, the systems that use private- ad public-key mechaisms must guard the private keys. Whatever techiques ad mechaisms are used to guard the private keys of a system, similar techiques ad mechaisms could be used to protect the vehicle keys i the servers of the automotive compay ad the software vedor. The keys must be kept i tamper resistat devices. However, sice the scope of this paper does ot deal with the protectio of keys i servers, we do ot wat to discuss this issue ay further. H. The Wireless Gateway of a Vehicle A vehicle must have a wireless gateway for it to receive software via wireless liks. This wireless gateway would be like a ECU (electroic cotrol uit) of the vehicle. The wireless gateway should have access to the vehicle s wired bus (e.g. a CAN bus) so that software ca be set to the targeted ECU from the wireless gateway. Whe the igitio is off, the wireless gateway should be i a low power receive mode to avoid battery draiig. Upo detectio of a sigal for software upload, the wireless gateway will switch itself to the full power mode to commuicate with the earest ITT. After receivig the software the wireless gateway ca save the software i its ow buffer. Later o, whe the igitio is tured o, the software ca be trasferred to the targeted ECU. IV. SYSTEM REQUIREMENTS I this sectio, we show the requiremets of memory size, badwidth ad legth of ecryptio keys for secure software upload operatios. A. Memory Requiremet A vehicle eeds two memory buffers: oe to keep a backup copy of the curret software ad aother oe to keep a copy of the ew software. The size of each buffer should be at least equal to the logest code of a vehicle module. Normally, the egie cotrol module cotais the logest code. A buffer size of 5 Mbytes should be good eough to hold the software of the egie cotrol module. Thus, the two buffers together eed at most 0 Mbytes. B. Badwidth Requiremet Ulike vehicle-to-vehicle commuicatio for pre-crash warig that requires high badwidth, the badwidth requiremet of a vehicle s wireless lik for uploadig software is ot a serious issue. The software does t eed to be trasmitted from the supplier to the vehicle i a short period of time (say withi a few miutes). The supplier ca take as much time as eeded to sed the software to the vehicle. Sice the trasfer process of the two copies of the software from the supplier to the vehicle is trasparet to the driver of the vehicle, a very low badwidth (say Kbyte/sec) lik may be good eough. To avoid ay badwidth limitatios for the overall system, icludig the supplier, cellular ad ITS ifrastructure, the software ca be trasmitted at off peak hours (say after midight) whe there may be very little traffic from other types of commuicatio services. C. Size of Ecryptio Keys Loger ecryptio keys eed more CPU time to do ecryptio ad decryptio tha that eeded by shorter ecryptio keys. However, loger keys provide better security tha shorter keys. Let us compare the key legths for two differet cases of software upload process to provide the same level of security. I oe case, loger keys are used ad oly oe copy of the software is set from the supplier to the vehicle. I the secod case, shorter keys are used, but two copies of the software are set from the L L supplier. Let ad be the legth of keys for the first ad secod case, respectively. The probability that a packet L k of the first case will be chaged is, where k idicates how fast the hacker ca decrypt iformatio compared to the vehicle. For example, if k = the the hacker ca decrypt iformatio twice as fast as the vehicle. Let be the total umber of packets i the software. The probability that the vehicle will receive all packets i clea form is ( k ). The, the probability that at least oe packet will be chaged by the hacker is ( p = k ) Similarly, for the secod case, where two copies of the software are set, the probability that the first copy will be chaged is ( k ) (). The probability that the secod copy of the software will be chaged i the same packet, as i the first copy, is k. Hece, the probability that tampered software will be uploaded i the vehicle for the secod case is p ( ( ) ) k k = () To have the same level of security for both cases, we have to make p =, i.e. k = ( ( k ) ) k p ( ). ( ) Hece, L k k +... = ( ) k k +... k (3) Most of the e-commerce trasactios through the iteret use 8-bit keys. However, for ay reasoable key size 59

6 (say 40 bits or loger), the values of k ad L k are very small. Igorig the higher order terms of L Equatio (3) we get k = k L, i.e. = k. Hece, L log k L = + (4) ad Equatio (4) shows the relatioship betwee L to have the same level of security. I geeral, we ca show that if the supplier decides to sed m copies of the software, the the followig relatioship must hold to achieve the same level of security. L ( m ) log k L m = + (5) m m where, L is the legth of ecryptio keys whe m copies of the software are to be set. Table I shows the size of L m m eeded to achieve the same level of security for differet values of k (speed ratio of hacker s computer) ad m (umber of copies of the software to be set by the supplier). Table I: Size of L m L to achieve the same security level for differet values of k ad m. Size of L (i bits) for L = 8 bits m k m = m = 3 m = I the above aalysis, it is assumed that the hacker stays with the vehicle all the time. However, it may ot be possible for the hacker to stay with the vehicle 4 hours a day ad 7 days a week. If the duplicate copies of the software are set after some radom ad log average time itervals (say 4 to 48 hours), the the hacker may ot stay ear the vehicle whe the vehicle will be receivig the duplicate copies of the software. Thus, i real-life, a much higher level of security ca be achieved by sedig two or more copies of the software to the vehicle. D. Trade off betwee m ad m+ Copies of the Software Whe m+ copies of the software are set, the legth of the keys is shorter tha whe m copies of the software are set. Shorter keys eed less time to do ecryptios ad decryptios of the software. However, sedig m+ copies of the software eed more time tha sedig m copies of the software. I our future work we would like to evaluate the trade off betwee m ad m+ copies of the software by cosiderig various performace parameters such as FEMA, cost/beefit ad time to deploy the upgraded software. V. CONCLUSIONS I this paper, we have preseted architecture for secure software upload i vehicles. We proposed that the supplier should sed at least two copies of the software to the vehicle. We have give a detailed descriptio of key exchage mechaisms ad software upload process. If two or more copies of the software are set, the shorter keys ca be used to obtai the same level of security that ca be obtaied with loger keys whe oly oe copy of the software is set. I other words, with the same size of keys, a sigificatly higher level of security ca be obtaied if two copies of the software are set to the vehicle, istead of oly oe copy. The level of security ca be further icreased if the time iterval betwee the trasmissio of two copies of the software is a radom umber with a very log average value. Sice differet autheticatio keys are used for differet vehicles, either a vehicle or the software vedor ca upload software i ay other vehicles without the coset of the automotive compay. REFERENCES [] Top 0 Techo-Cool Cars, IEEE Spectrum, February 003, pp [] A Frier, P. Karlto, ad P. Kocher, The SSL 3.0 Protocol, Netscape, Nov [3] M.S Bhiogade, Secure Socket layer, IS 00 Proc. of the iformig sciece IT Educatio Cof., Jue 9-, 00, Cork, Irelad, pp g058secur.pdf [4] How Virtual Private Networks Work. Website of how stuff works. [5] Hadbook of Applied Cryptography By A. Meezes, P. Va Oorschot ad S. Vadstoe. CRC Press 996. [6] Roald Rivest, The MD5 Message-Digest Algorithm, RFC 3 April 99. [7] Sug-Ju Lee, Routig ad Multicastig Strategies i Wireless Mobile Ad hoc Networks, Ph. D. Dissertatio, Uiv. of Califoria Los Ageles, 000. [8] Thomas Kuz ad Ed Cheg, O-Demad Multicastig i Ad-Hoc Networks: Comparig AODV ad ODMRP, Proc. of the d Iteratioal Cof. o Distributed Computig Sys. (ICDCS 0), IEEE Comp. Society,