Short Stories

A security architecture concept for vehicular network nodes

A security architecture concept for vehicular network nodes
of 5
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
  A Security Architecture Concept for VehicularNetwork Nodes Stephan EichlerInstitute of Communication Networks, Technische Universität MünchenArcisstr. 21, D-80333 München, GermanyE-Mail:  Abstract —Many proposals how to secure vehicular networkshave been made in the literature. In this paper we address thesecurity requirements existing in a Vehicular Network (VN) andpresent how to set up and implement the security architecturein a vehicular network node. Thereby, we take into account fullydecentralized services as well as centralized Telematics servicesrelying on a server infrastructure. The suggested system conceptis a holistic approach providing security for all requirementsand all system layer components. Besides security we also lookinto privacy aspects of a vehicular network node. Moreover,we suggest how privacy management has to be integrated intothe node architecture to be effective. In addition, we brieflyoutline the backend infrastructure needed to use the node securityarchitecture concept. I. I NTRODUCTION Vehicular networks have become a prominent research area,as they promise to be an important building block for in-vehicle infotainment and safety applications. A very importantrequirement for the success of future Vehicular Networks(VNs) is their reliability and most important their securityand trustability. Hence, the selection of efficient, scalable, andadapted security mechanisms and their integration into boththe support infrastructure and the in-vehicle architecture arevery crucial aspects. The term Vehicular Networks used in thispaper includes both, Vehicular Ad Hoc Networks (VANETs)as well as communication to and from a vehicle using e.g.cellular networks to a dedicated server.The different means of communication to be integrated infuture vehicles will be used for several different types of ser-vices. The cellular systems are most suitable for services usinga server infrastructure and a backend network. Since they fol-low a centralized network concept this mean of communicationis ideal for a vehicle-to-backend (V2B) access. The backendin this context would be one or several servers, providinginformation and services to the passengers of the respectivevehicle. However, since this communication method neitherallows for the distribution of information using broadcast noris it suitable for direct vehicle-to-vehicle (V2V) or vehicle-to-infrastructure (V2I) communication, the Dedicated ShortRange Communication (DSRC)-based ad hoc communicationtechnology needs to be integrated additionally. This separationof centralized and distributed communication means, due tothe different nature of the services provided, is reflected in thedifferent security requirements for the related services and thecommunication itself.In numerous publications several security aspects of VNshave been discussed, however, most of the previously pro-posed mechanisms and protocols are detached solutions. Nointegrated solution for security, privacy, communication, andits architecture setup in a vehicular node has been presentedso far. However, the different components of a VN scenarioand the security mechanisms they are relying on, have tobe harmonized with each other. Otherwise, either securityor protocol efficiency, sometimes even both, will be limited.Therefore, a careful selection of security mechanisms aftera thorough requirements analysis is necessary, to come to aholistic security concept for vehicular nodes. In the courseof the paper we present how the in-vehicle security setupneeded for VNs should be realized. Further we briefly outlinethe required backend security components. The terminologyrelated to security and especially privacy use in this paper isbased on [1].The paper is structured as follows. In Sec. II typical servicesof VNs and the security requirements are outlined. Our maincontribution, the security architecture concept, is introducedin Sec. III. Important related work and further reading ispresented in Sec. IV. The paper closes with a conclusion inSec. V.II. S ERVICES AND S ECURITY R EQUIREMENTS IN V EHICULAR N ETWORKS The typical service categories and resulting security require-ments have to be outlined before we can elaborate on thesecurity architecture itself. In VNs two different service cat-egories dominate: Services provisioned by a dedicated serverinfrastructure, in the following referred to as platform services ,and decentralized ad hoc services primarily using broadcast-based information dissemination, in the following referred toas VANET services .The security requirements are mainly biased by the servicecategories, but additionally some system characteristics poseadditional requirements on the security setup. Concerning theVANET services, privacy is a very crucial aspect for thesystem.  A. Services and Applications The idea to integrate Telematics services and new appli-cations for vehicle passengers into future vehicles is the main1–4244–0983–7/07/$25.00c  2007 IEEE ICICS 2007  argument for communication to and from vehicles. Two servicecategories dominate and are outlined in the following. Platform Services: The first category of service appli-cations relies on a dedicated service infrastructure with atleast one content server in the backend. The user of such aservice will need a subscription and has to be registered at theso-called Control Center, managing users, services, and thewhole platform system itself. The users access the servicesthrough an in-vehicle terminal called Telematics Control Unit(TCU). The services are provisioned by one of several serviceproviders in the backend. The main characteristic for thisservice category is the centralized management in the backend.Crucial for a transparent and user-friendly service provisioningis the use of a central security basis. In the course of theEuropean research project Global System for Telematics (GST)a possible implementation for platform services has beendeveloped ( ). The focus of these services is safety, however, infotainment services willalso play a big role in promoting such a system. Exampleservices are provisioning of up-to-date traffic information,warning messages, parking information; any service makingtravelling more safe and enjoyable is imaginable. VANET Services: The second service category groups allservices based on the use of ad hoc communication technology.The services use an ad hoc communication technology likeDSRC to distribute and receive safety messages primarily.These services rely on different message broadcast strategies,since their main task is to distribute information quickly andefficiently. VANET services will mainly be used to distributesafety messages like collision warnings, traffic status informa-tion, and danger warnings, not relying on any infrastructurein relation to the content. The vehicles act as both contentgenerators/providers and as content consumers. No centralizedinfrastructure components are required to provide these ser-vices. With supporting infrastructure like gateway nodes anadditional commercial service portfolio is thinkable [2].  B. Categories of Security Requirements Similar to the services also the security requirements canbe grouped into different categories. Here we focus on a cate-gorization which is related to the architecture design presentedin Sec. III. Service Security: Different services need different se-curity mechanisms, however, many of the common securityfeatures are needed by all services. Data authenticity andintegrity, independent of the service category is a crucialneed. Services that have to be subscribed and paid for, whichis relevant for platform services primarily, require a userand service center authentication in addition. Further, accesspolicies are needed to be able to do a subscription managementand user authorization for different service variants. As soonas money is involved, a secure and reliable billing is essential.Since platform services use point-to-point communication withdefined endpoints and they exchange sensible data, confiden-tiality of the content is crucial. In contrast, VANET services End−to−End communication (encrypted)Peer−to−peer communication (encrypted)Communication (not encrypted)Client System Gateway Service Center Fig. 1. Communication security for heterogeneous communication chains will not use confidential data exchange, due to the distributivenature of the services. Communication Security: Security related to communi-cation has specific requirements especially in relation to theplatform services. Here different communication scenarios arefeasible (see Fig. 1). Besides the rather unlikely case of afully unencrypted communication three other cases are re-quired. These are an encrypted end-to-end communication, anencrypted end-to-end communication using one or several en-crypted point-to-point links enabling e.g. protocol conversions,and a discontinuous encrypted end-to-end communication withone or several encrypted point-to-point links, allowing someor all intermediate nodes to access the content. These het-erogeneous communication chains are important especially if different means of communication are used and conversionsare necessary.In addition to the heterogeneous communication setupspeers need to be able to hold and manage security ses-sion information. To set up an encrypted and authenticatedcommunication relation a session management is needed toauthenticate the peers, negotiate the secret keys, and exchangeauthenticated content. If any one step during the secure sessionestablishment phase fails, the communication setup has tobe stopped. Since VANET services do not rely on dedicatedcommunication relations, they have no specific requirementsfor communication security except privacy, which is explainedbelow. System Security: A very important category for securityrequirements is system security. The security of the system isthe most crucial aspect, since everything else is based on thesystem setup. Communication is using the system as well asthe service applications running on it. Hence, the security basishas to be set up carefully and protected well. Since most TCUswill host both service categories, their respective requirementsneed to be fulfilled on the same system. To reduce the overheada single trust basis needs to be defined, which is capable of providing all required security mechanisms. The trust basiswill be located in the backend, however, all nodes will obtaincredentials and certificates reflecting the trust. The security of the system has to ensure these security credentials are protectedand can not e.g be transferred or shared between nodes. Sincemost nodes of a VN operate in a hostile environment outsideof the influence of the VN operator, the system security isessential. Privacy: Especially for the VANET services it is re-quired to ensure privacy. Since nodes disseminate e.g. location  RDS/TMCGPRS/UMTSIEEE 802.11DxB Communication Interfaces Singlehop MultihopBroadcast / Geocast IP−NetworkingAd Hoc FixedSecurity ModuleManagementCertificate / Key Security/Privacy EntertainmentInformation ServicesHuman Machine Interface SafetyPositioning / GPSSensor InteractionTime Support Functions Communication API Fig. 2. General in-vehicle system architecture information and digitally sign the content to ensure integrity,different messages sent by the same node can be linked witheach other. This enables data collection and the generation of movement protocols for nodes. Moreover, users are unlikelywilling to participate in a system breaching their privacy. If notenough nodes exist in a VANET its use will be very limited.Hence, privacy is a very crucial requirement in this scenario;the unlinkability of nodes and events has to be ensured. Thedemand for privacy has implications for the whole systemsetup, since any trace independent of its srcin can be usedto link events and messages, therefore, breaching the privacyrequirements.III. S ECURITY A RCHITECTURE S ETUP In the following section we detail the security setup fora vehicular network node. First, an outline on the generalarchitecture is given. In the second step the implicationsof security and privacy for the communication stacks areexplained. Finally, the architecture concept is explained indetail.  A. In-Vehicle System Outline The general in-vehicle system architecture can be groupedinto three component blocks: The main system stack (in-terfaces, communication, services, Human-Machine Interface(HMI)), the security and privacy components, and the supportcomponents (e.g. in-vehicle sensors). This general architectureand the main component interactions are depicted in Fig. 2.The primary component stack is shown in the center of Fig. 2. The system will rely on several communication in-terfaces, prominent examples are the IEEE 802.11 standardfamily, and cell-based communication systems like GeneralPacket Radio Service (GPRS) and Universal Mobile Telecom-munications Standard (UMTS). In addition, broadcast com-munication like Digital Audio Broadcast (DAB) or DigitalVideo Broadcast (DVB) might complement the conventionalcommunication means. Traffic related broadcast communica-tion is provided by the Radio Data System (RDS) or theTraffic Message Channel (TMC) already today, this will alsobe the case in future implementations. The communicationlayer components are primarily relevant for DSRC and thecell-based communication. We can differentiate between mereX-cast communication and Internet Protocol (IP) networking. Layer      S    e    c    u    r     i     t    y Communication InterfaceTCP UDPApplication      P    r     i    v    a    c    y NetworkV2VIP Fig. 3. Integration of security and privacy in the communication stack  Depending on the type of data and the respective serviceone of the communication variants will apply. The serviceapplications in the third component layer interact with the com-munication layer primarily to receive and send data content.The interaction with the user is carried out through a HMI.In order that the primary component stack can operate,miscellaneous support functions are required. The most rel-evant ones are given as examples in Fig. 2. The interactionwith sensors is crucial to generate information and detectevents that the VANET services can use and disseminate.Node positioning is also a crucial support function needed forservices as well as geocast-based message distribution. Thesupport functions primarily interact with the services and thecommunication components.The third component block contains the security and privacycomponents. Since the security components need to interactwith most system components in the main thread we suggest tobundle the security functionality externally in this extra block.This has several reasons. Besides the mentioned interactiondiversity it is not reasonable to multiply identical securityfunctions needed for several other layers and blocks. Thiswould complicate the system implementation and increase thesystem’s complexity. In fact a separate security implementationproviding all required mechanisms for the whole system canbe verified much better, reducing the probability of a falseimplementation often leading to compromised systems. Inaddition, the requirement for a secured overall system callsfor a hardware security implementation, which then is capableof sufficiently protecting the security basis. This hardwarecomponent, detailed below, shall be implemented in the systemonly once. Hence, a single security application programminginterface (API) is required.  B. Security in the Communication Stack  A very crucial implementation task is the integration of security and especially privacy into the communication stack.In Fig. 3 the typical communication stack for a vehicular nodeis depicted. The communication stack is split into two parallelpaths: The V2V and the conventional IP-based communicationpath.A security integration is mainly required for the applicationlayer. Especially for the VANET services the security canbe handled solely in the application layer, as long as nosecure routing mechanism shall be used in the lower layers.But for a mere broadcast application a security integration in  TransferSecure Communications EngineAuthentication BrokerAuthorization BrokerSecure CommunicationApplication      S    e    c    u    r     i     t    y     M    o     d    u     l    e Fig. 4. Security in the communication stack for platform services the application layer is sufficient. However, security for theplatform services also has to be integrated in the network layers. One possibility to realize this is to use a specificsecurity layer in the communication stack (see Fig. 4), assuggested by the GST project [3]. The functionalities shownin Fig. 4 can mainly be handled by the security componentsblock depicted in Fig. 2, since most functions are standardmechanism also used by other layers. Specific for this securitylayer is the secure communications engine , which is managingthe security sessions of the node.Whereas the security integration into the communicationstack is straight forward, the privacy integration needs moreattention and care. As it is shown in Fig. 3 the privacy block has strong links to all communication stack blocks. This iscrucial for the success of the privacy concept. To provideprivacy effectively, the whole system architecture has to beevaluated and included in the privacy concept. In contrastto security mechanisms it is not sufficient for privacy to beincluded in one layer (e.g. application). To provide a highdegree of anonymity the privacy concept has to ensure theunlinkability of ”traces“ a node leaves behind. Since all layersin the communication stack generate characteristic labels, suchas IP-addresses, Medium Access Control (MAC)-addressesor session identifiers, the privacy component has to havecontrol over every communication layer and the generation of labels. If any label changes all other labels have to change aswell, otherwise the messages can be linked by the unchangedlabel(s). Hence, a single privacy component has to control allinvolved communication- and label-generating blocks in thesystem. Otherwise no reliable privacy concept can be provided. C. Integration of Security – Security API and Security Module The most important component for a secure vehicular net-work node is the security component. The security componenthas to fulfill all security and privacy requirements outlinedin Sec. II and provide respective mechanisms. We suggest toimplement it with two parts, a security software API and ahardware security module referred to as Security Module. Asthe Security Module can not function alone it can be seensomewhat integrated into the API, which provides all necessaryfunctionality to use the hardware component. Refer to Fig. 5for the full security API definition.The API can be split into five blocks. The four softwarecomponents (Public Key Infrastructure (PKI), Secure Com- PrivacyPKI Secure StorageSecure LogAuthenticationAuthorizationPolicy DatabaseSoftware VerificationPositionTime Platform Security Sign VerifyHashing De−/EncryptKey AgreementRNG Security Mechanisms Key GenerationCertificatesKeys Credentials Communication MgmtSecure Session Mgmt Secure Communication Pseudonym MgmtLayer PrivacyCertificate CacheCSI Management Security Module EnforcementCert. Chain Mgmt Security API Fig. 5. Security API and Security Module for a vehicular network node munication, Privacy, and Platform Security) use the securitymechanisms and the secure storage functionality of the fifthcomponent, the Security Module. The Security Module is themost crucial component of the system concerning security.It is a tamper proof hardware security component similar toa Trusted Platform Module (TPM) or a Smartcard. For thesecurity level of the whole system it is crucial to implementthe core security functions using a tamper proof hardwarecomponent. This is the only way to sufficiently secure creden-tials, certificates, and key material on a platform being usedin the field. The key materials will be generated and storedwithin the Security Module and can not ”leave“ it at any timewithout destroying the component. This feature of the systemis required to maintain a high degree of security and minimizethe number of overall certificate revocations throughout thesystem. However, this requires a hardware component whichis also capable of using the credentials and keys, generatee.g. secure random values, and encrypt/decrypt messages. Theoverall policy must be: No security credentials and keys thatsrcinate from a Security Module may leave the module in anyway, all security operations have to run on the module itself.The trust of the system and the related credentials for eachnode are handled in the PKI API-component. All security-related communication is handled by the Secure Communica-tion component. The general security features (authentication,confidentiality, policy enforcement, secure software updates,etc.) are handled by the Platform Security component of the API. The management of privacy and the handling of pseudonyms as well as the layer management (refer to Sec. III-B) is handled by the Privacy component.  D. Supporting Backend Security Functionalities The trust anchor for the system is located in the backend.A PKI is used to install trust in the system. The PKI actorsprovide certificates and credentials to trusted network nodesand revoke compromised certificates. In addition the backendcomponents provide the user and subscription managementneeded for the platform services. More details can be foundin [4], [5], [6].  IV. R ELATED W ORK In [7] the authors present a concept for the integrationof security in Telematics systems. They stress that securityhas to be embedded during the design phase to make it anintegral part of the system architecture. In our contribution thedesign rules of [7] have been taken into account to ensure asound system architecture. The first publications concerningtelematics and VNs in relation with security are [8] and [9].In [8] the security issues of a VN are introduced and the”DAHNI“ infrastructure is proposed. The paper is a goodstarting point to the topic. The second paper focuses more onservice provider-based telematics services and their securityissues. A system concept is introduced which is mainly usefulfor protecting private data on the system.Hubaux et al. identify security and privacy needs forVANETs in [10]. Besides a review on services they look intoprivacy aspects and the determination of a privacy metric forVANETs using entropy. Further they identify the need for atamper proof positioning device for such a system. In [11]Parno and Perrig review VANET characteristics to identifybeneficial aspects for a secure network. Further, they discusssecurity primitives for such a system. They analyze attackerstrategies and attacks and present security mechanisms againstthem. A more general overview on security issues related toMobile Ad Hoc Network (MANET) and VANET architectureshas been thoroughly surveyed in [12].The security approach followed in the GST project has firstbeen introduced in [3]. In the paper the security concept forheterogeneous communication relations as well as the securitylayer in the communication stack have been introduced. Thepaper outlines the requirements for centralized service archi-tectures. In a follow-up paper a specific service architectureconcept for anonymous but authenticated service usage hasbeen presented [13]. Here, the GST architecture is used toenable anonymous service usage, while the user can still berewarded for participating in the data provisioning process.Plößl et al. present in [14] a security architecture forVANETs. In their paper they introduce services and securityrequirements. Using this information a security architecture isoutlined. However, the concept described is still very muchon a higher level, leaving out crucial aspects of implementa-tion and privacy. In [15] also a security architecture conceptprimarily for VANETs has been outlined. The authors concen-trate on the overall system setup and explain a general PKIsystem setup. Moreover, compared to our contributions bothpublications leave out the detailed description of the in-vehiclesystem setup related to security.V. C ONCLUSION Even though securing vehicular networks is a challengingtask, many efficient and useful approaches exist as of today.We presented a holistic security approach for the in-vehiclenode architecture, taking into account the various securityrequirements. The trust anchor of future networks will bebased on a Public Key Infrastructure which is located in thebackend network architecture. Every node will be equippedwith at least one or more certificates to be able to communicatewith other nodes in the network. The security of the in-vehicleplatform will be based on a hardware security module like aTrusted Platform Module (TPM). The security of the wholesystem is very much based on the security of the systemplatform in the vehicles. Hence, the in-vehicle platform needsa hardware security component as the core security buildingblock. This ensures a tamper resistant system, allowing thebonding of security properties and certificates to a vehicle.For this integration it is crucial that all security mechanismsare handled by the hardware module. Security is one of theimportant factors for the success of future vehicular networks,hence, its integration into the system has to be done verycarefully making it an integral part of the system.R EFERENCES[1] A. Pfitzmann and M. Hansen, Anonymity, Unlinkability, Unobservability,Pseudonymity, and Identity Management – A Consolidated Proposal for Terminology , 0.28 ed., TU Dresden and ULD Kiel, May 2006. [Online].Available:[2] T. K. Mak, K. P. Laberteaux, and R. Sengupta, “A multi-channel VANETproviding concurrent safety and commercial services,” in Proceedingsof the 2nd ACM International Workshop on Vehicular Ad Hoc Networks(VANET) . New York, NY, USA: ACM Press, 2005, pp. 1–9.[3] S. Eichler, J. Billion, R. Maier, H.-J. Vögel, and R. Kroh, “On providingsecurity for an open telematics platform,” in Proceedings of the 5th International Conference on ITS Telecommunications , June 2005.[4] C. Schwingenschlögl and S. Eichler, “Certificate-based key managementfor secure communications in ad hoc networks,” in Proceedings of the5th European Wireless Conference: Mobile and Wireless Systems beyond 3G , Feb. 2004.[5] C. Schwingenschlögl, S. Eichler, and B. Müller-Rathgeber, “Performanceof PKI-based security mechanisms in mobile ad hoc networks,” AEÜ - Journal of Electronics and Communications , vol. 60, no. 1, pp. 20–24,Jan. 2006.[6] H.-J. Vögel, B. Weyl, and S. Eichler, “Federation solutions for inter- andintradomain security in next-generation mobile service platforms,” AEÜ - Journal of Electronics and Communications , vol. 60, no. 1, pp. 13–19,Jan. 2006.[7] O. Tettero, D. J. Out, H. M. Franken, and J. Schot, “Information securityembedded in the design of telematics systems,” Computers & Security ,vol. 16, no. 2, pp. 145–164, 1997.[8] M. E. Zarki, S. Mehrotra, G. Tsudik, and N. Venkatasubramanian,“Security issues in a future vehicular network,” in Proceedings of European Wireless, Next Generation Wireless Networks , vol. 1, Feb.2002, pp. 270–274.[9] S. Duri, M. Gruteser, X. Liu, P. Moskowitz, R. Perez, M. Singh, and J.-M. Tang, “Framework for security and privacy in automotive telematics,”in Proceedings of the 2nd International Workshop on Mobile Commerce .ACM Press, 2002, pp. 25–32.[10] J. P. Hubaux, S. Capkun, and J. Luo, “The security and privacy of smartvehicles,” IEEE Security & Privacy , vol. 4, no. 3, pp. 49–55, May 2004.[11] B. Parno and A. Perrig, “Challenges in securing vehicular networks,” in Proceedings of the 4th Workshop on Hot Topics in Networks (NotNets) ,Nov. 2005.[12] D. Djenouri, L. Khelladi, and N. Badache, “A survey of security issuesin mobile ad hoc and sensor networks,” IEEE Communications Surveys& Tutorials , vol. 7, no. 4, pp. 2–28, 2005.[13] S. Eichler, “Anonymous and authenticated data provisioning for floatingcar data systems,” in Proceedings of the 10th IEEE InternationalConference on Communication Systems (ICCS) , Oct. 2006.[14] K. Plößl, T. Nowey, and C. Mletzko, “Towards a security architecturefor vehicular ad hoc networks,” in Proceedings of The 1st InternationalConference on Availability, Reliability and Security (ARES) , 2006, pp.374–381.[15] M. Raya, P. Papadimitratos, and J.-P. Hubaux, “Securing vehicularcommunications,” IEEE Wireless Communications , vol. 13, no. 5, pp.8–15, Oct. 2006.
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks