PRESTvO: PRivacy Enabled Smartphone-based access To vehicle On-board units

by   Bogdan Groza, et al.

Smartphones are quickly moving toward complementing or even replacing traditional car keys. We advocate a role-based access control policy mixed with attributes that facilitates access to various functionalities of vehicular on-board units from smartphones. We use a rights-based access control policy for in-vehicle functionalities similar to the case of a file allocation table of a contemporary OS, in which read, write or execute operations can be performed over various vehicle functions. Further, to assure the appropriate security, we develop a protocol suite using identity-based cryptography and we rely on group signatures that preserve the anonymity of group members for assuring privacy and traceability. To prove the feasibility of our approach, we develop a proof-of-concept implementation with modern smartphones, aftermarket Android head-units and test computational feasibility on a real-world in-vehicle controller. Our implementation relies on state-of-the-art cryptography, including traditional building blocks and more modern pairing-friendly curves, that facilitate the adoption of group signatures and identity-based cryptography in automotive-based scenarios.



There are no comments yet.


page 1

page 11

page 14


Traceable Policy-Based Signatures and Instantiation from Lattices

Policy-based signatures (PBS) were proposed by Bellare and Fuchsbauer (P...

Boardroom Voting: Verifiable Voting with Ballot Privacy Using Low-Tech Cryptography in a Single Room

A boardroom election is an election that takes place in a single room – ...

Cryptographically Secure Information Flow Control on Key-Value Stores

We present Clio, an information flow control (IFC) system that transpare...

HERMES: Scalable, Secure, and Privacy-Enhancing Vehicle Access System

We propose HERMES, a scalable, secure, and privacy-enhancing system, whi...

Pay as You Go: A Generic Crypto Tolling Architecture

The imminent pervasive adoption of vehicular communication, based on ded...

EC-SVC: Secure CAN Bus In-Vehicle Communications with Fine-grained Access Control Based on Edge Computing

In-vehicle communications are not designed for message exchange between ...

Grand Theft App: Digital Forensics of Vehicle Assistant Apps

Due to the increasing connectivity of modern vehicles, collected data is...
This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 Introduction and motivation

The generous interface of modern smartphones and their ubiquitousness opens road for adding access control to various car functionalities as well as for remote configuration and rights delegation. Figure 1 is a depiction of the interface that we implemented in PRESTO. Some car functionalities are outlined and four user roles are displayed: car owner, driver, passenger and a technician role. Table I summarizes over role rights which are marked in a similar fashion to access rights over files in a modern operating system.

In contrast, classical radio-frequency (RF) and/or mechanical vehicle keys are rigid and lack in terms of flexibility and functionalities. Perhaps surprising, despite their simplicity, classical RF keys have shown numerous flaws that led to a plethora of reported attacks, e.g., [16], [38], [43], [45]. So it seems that traditional car keys are lacking in many respects. The causes are numerous, including poor selection of cryptographic algorithms or poor randomness, etc. This merely complements a landscape with which we have became so familiar in the recent years where modern cars are clearly deficient in terms of security, e.g., [26], [10], [30].

Fig. 1: PRESTO user interface




Child Ocuppant



Start Engine
Open Trunk

Open Doors

Limit speed

Fuel Level


SW Update

Park car



Start A/C



Play music

Limit volume

Trip Computer

TABLE I: An example of role access rights

By using smartphones, specific applications can be targeted and the interface customized to gain access to virtually any device or component from the car. Moreover, rights delegation can address complex scenarios due to increased connectivity at a global scale. Replacing traditional keys with smartphones appears like a natural step for achieving increased usability and an improved user experience. This is in fact proved both by many research works (which we separately address in the related work section) but also by recent industry efforts such as the Car Connectivity Consortium which drives a global initiative of top players from the automotive domain for car-to-smartphone connectivity111

However, replacing traditional keys with smartphones comes with additional security and privacy challenges. First, smartphones can be compromised much easier than regular car-keys and second, various configuration options may leak private information about the driver. Thus addressing both security and privacy concerns is a must for any proposal of using smartphones for car access control.

Fig. 2: PRESTO system design

In principle, cryptography offers a rich tool-set with primitives that can assure various security objectives. Besides regular symmetric and asymmetric primitives, i.e., encryptions and signatures, more recent advances set room for more exotic cryptographic functionalities. These include identity-based cryptography where the identity of a user can be used to derive his public key or group signatures where the identity of a user can be preserved anonymously under the public-key of a group (still allowing an authority to trace the user if a dispute arises). There is no question that these cryptographic functionalities will be sooner or later adopted by the industry. The AUTOSAR standard already defines interfaces for regular cryptographic building blocks in the automotive domain [33], [34]. Identity-based signatures are part of an ISO standard [24] published long ago and it targets embedded devices such as smartcards. There are numerous research works that advocate for the use of these cryptographic building blocks for car access control, these are summarized in Table II and will be discussed in the related work section. However, the heterogeneity of the addressed environment, where smartphones interact with in-vehicle units, raises performance concerns. Our work builds upon various cryptographic building blocks (identity-based signatures, group signatures, etc.) and besides designing a car access protocol we try to bring answers regarding the feasibility of deploying this solution both on mobile devices and on in-vehicle components.

System design goals. We now briefly discuss the design goals of our proposal. Figure 2 gives an overview of the addressed system. A user requests a particular functionality of the car which is to be executed by some in-vehicle electronic control unit (ECU). Access is mediated by PRESTO. First an authentication service is called which verifies the identity of the user and the role he invoked. If the identity and roles are verified, the role along with the request is passed to the access control service which in turn verifies authorization for the particular request and returns the access decision. In case of a positive decision, the request is passed to the car which in turn responds according to the request, i.e., by executing the particular functionality and sending a response message. The user receives a response from PRESTO which may be negative if his function request could not be approved or a confirmation otherwise. We design the protocol behind PRESTO with both security and privacy in mind and also without forgetting that we address functionalities inside a car and target real-world automotive-grade embedded devices. The following summarizes the goals of our work:

  1. secure access control to all vehicle functionalities mediated by the use of smartphones is the prime intention of our work,

  2. a flexible access control policy determined by roles and attributes which lies middle of the road between RBAC and attribute-based access control (ABAC) which seems the best option due to the variety of car-usage scenarios,

  3. remote rights delegation and also rights revocation directly from the smartphone is a natural functionality,

  4. user privacy, by which we keep the identity of the user anonymous to the car and manufacturers, is enforced by the use of group signatures that hide the identity of a specific user inside a group,

  5. user traceability in case when a dispute arises is a mandatory procedure due to legal implications, e.g., the car may be involved in an accident and it becomes necessary to be able to trace a particular user,

  6. flexible use of wireless interfaces WiFi, Bluetooth and NFC according to existing support on the hardware that we used (smartphones and vehicle head-units),

  7. comprehensive performance tests on real-world automotive grade controllers are a must in order to prove that implementation is realistic with respect to state-of-the-art in automotive on-board units.

1.1 Related Work

Paper Main Concept Platform for Key Deployment Comm. intrf. Other cryptographic rq. Car AC Rights deleg.

Access control rights delegation with trusted execution environment on Android Nexus S (Android 2.3.3 patched with TrustDroid security extensions) NFC

Car access and rights delegation from an Android smartphone, security reinforced by smart-card Samsung Galaxy S3, Arduino Uno (8-bit microcontroller for car immobilizer) NFC

Secure vehicle-to-cloud communications based (uses OAuth & HSM) NFC

Rights Management with NFC Smartphones and Electronic ID Cards Blackberry Bold 990 NFC

Pairing cars and smartphones by OOB (out-of-band) channels: light and sound (augmented by the Encrypted Key Exchange protocol, Diffie-Hellman version) Motorola Droid 1, Android 2.2.3 (Froyo) BT

Car sharing functionality with secure multiparty computation Intel Core i7, 2.6 Ghz CPU, 8GBof RAM NFC, BT Secure multi-party computation

Car sharing by short-range wireless communication (RFID, NFC, BLE) with two-factor authentication Samsung S4 (Android 5.0), Google Nexus 5 Android 5.1 (Lollipop), + Giesecke & Devrient Mobile Security Card (MSC) with DESFire applet, contactless Mifare DESFire EV1 smartcard, Samsung Galaxy Gear SM-V700 smartwatch (Android 4.2) NFC, BLE

Car sharing in a hierarchical system between KGC (key generation center), owner/rental company, user Android Nexus 5 NFC Identity-based encryption and signatures

Rights delegation to a car from a low-cost embedded platform by using only symmetric crypto-primitives MSP430 (16-bit microcontroller from Texas Instruments for key), Freescale S12 (as car immobilizer) RF

Our Work
Car access and rights delegation, preserving anonymity by using group signatures, eliminating PKI by using identity-based cryptography LG, Samsung J5, ERISIN & PNI car head-units, Infienon TC297 (for car immobilizer) NFC, BT, WiFi Identity-based signatures, group signatures

TABLE II: Summary of some existing proposals for car keys with enhanced capabilities (in chronological order by year of publication)

Related work on vehicle access control and rights delegation is extensive. There are not many research focusing on traditional car immobilizers, e.g., [28], but quite a large number of more recent works address the use of smartphones for accessing vehicle functionalities. We survey next over existing proposals and present a summary of some them in chronological order in Table II. We also point out in the table whether the work uses any enhanced cryptographic capabilities, e.g., identity-based signatures, group signature, etc., besides the regular symmetric/asymmetric primitives which are present in all of the works.

The use of smartphones for access-control systems inside buildings and as replacement of traditional physical keys has been explored as early as the works of [4], [3].

In [7] a full platform for car access and rights delegation from an Android smartphone is presented. The security is reinforced by the use of a smart-card and the authors present both a proof-of-concept implementation and strong security arguments by model checking with ProVerif. A hierarchical car sharing architecture is proposed in [44]. The authors consider only a simplified hierarchy with 3 levels: a key generation center, the owner or the rental company and the end-user. A proof of concept implementation is presented on an Android Nexus 5 smartphone, the protocol relies on identity based encryptions and signatures. The authors of [13] propose a generic smartphone-based NFC access control system that allows access rights delegation. The access control system is based on a multi-level smartphone security architecture designed to provide trusted execution and storage environments. Formal security analysis as well as a proof of concept implementation on a simplified system model are provided. Several NFC-based use cases for the automotive environment are also described and implemented in [35].

Another secure access control system for car sharing is proposed in [12]. It employs two-factor authentication provided by an RFID token and a soft token to enable access to offline cars. The proposed instantiation uses a secure execution platform that can be implemented on devices such as smartcards or smartwatches. Another approach for car sharing is proposed in [37]. The paper presents a decentralised protocol that provides both security and privacy allowing owners to share their cars. Protocol analysis and a proof-of concept implementation are also considered.

Other works that use smartphones for gaining access to vehicles are [1] and [6]. The Green Move project described in [1] is a vehicle sharing system. In this project, the vehicles are equipped with Green e-box devices, which communicate with a smartphone via Bluetooth and with the cloud (Green Move Center) via HTTP. Using the smartphone application, the user retrieves the valid electronic key from the Green Move Center, which contains an encrypted ticket, the start time of reservation as well as all the information to identify the car. The encrypted ticket is used to lock/unlock the doors. In [6], the Terminal Mode technology is described. This technology integrates the smartphone into the car head unit. In this scenario, the input and output functions are the responsibilities of the car head unit, while the smartphone acts as the application platform. New functionalities can be added to the car head unit by easily upgrading the smartphone.

Some works are focused on cost-efficient solutions. The implementation of a dedicated device for car-rights delegation on low-cost MSP430 microcontrollers from Texas Instruments is discussed in [19]. A keyless car access system using RFID cards (e-driver licenses) is proposed in [23]. In this scenario, each driver license is assigned to the driver’s identity based on an RFID card using a serial number stored in the cloud database. If the serial number exists in the database, the driver can use the car and the owner knows who is driving the car based on information provided by a smartphone application.

Pairing mobile devices with cars has also been targeted. A secure pairing between mobile devices and vehicles based on out-of-band (OOB) channels is proposed in [22]. The authors present several key agreement protocols using light and sound as OOB channels. Protocol analysis with AVISPA [2] as well as implementations are also provided.

Privacy concerns for smartphone applications in the automotive domain have been also addressed for pay-by-phone parking systems [18] or GPS tracking [29].

1.2 Selecting setup components

Table III provides a summary of the devices that we used in our setup. We discuss these in detail next.

Device Android CPU Memory WiFi BT

LG Optimus P700
4.0.3 1.0 GHz Cortex-A5 4 GB (2.4 GB user available) 512 MB RAM Wi-Fi 802.11 b/g/n, Wi-Fi Direct, hotspot, DLNA 3.0, A2DP

Samsung J5
5.1.1 Quad-core 1.2 GHz Cortex-A53 8 GB, 1.5 GB RAM Wi-Fi 802.11 b/g/n, Wi-Fi Direct, hotspot 4.1, A2DP

Samsung S5
6.0.1 Quad-core 2.5 GHz Krait 450 16 GB, 2 GB RAM Wi-Fi 802.11 a/b/g/n/ac, dual-band, Wi-Fi Direct, hotspot 4.0, A2DP, EDR, LE, aptX

Samsung S7
6.0.1 Octa-core (4x2.3 GHz Mongoose & 4x1.6 GHz Cortex-A53) 32 GB, 4 GB RAM Wi-Fi 802.11 a/b/g/n/ac, dual-band, Wi-Fi Direct, hotspot 4.2, A2DP, LE, aptX

Head-unit PNI/ERISIN
7.1.1 Quad-core 1.63 GHz Cortex A7 12 GB, 1/2 GB RAM Wi-Fi 802.11 b/g/n, hotspot, 4.0, A2DP, BR/EDR

Infineon TC
N/A Triple Core 300MHz TriCore 8 MB Flash, 728KB RAM N/A N/A

TABLE III: Devices from our experiments: smartphones, head-units and in-vehicle control unit

Android head units and smartphones. For our experimental setup we acquired two Android head-units with similar computational/communication capabilities. The first of them from ERISIN was designed to replace SEAT and VW head units. The head unit provides a 9-inch capacitive display with 1024 x 600 resolution running the Android 7.1 Nougat OS. The CPU it uses is an Allwinner Quad-Core T3 SoC (Quad-core Cortex A7, 1.63GHz and Mali400 MP2 GPU), 2GB RAM and 16GB internal memory. The storage can be increased by using microSD cards or USB connected memory devices. The T3 SoC integrates a high number of peripherals providing support for a multitude of standards: USB, SATA, UART, TWI, SPI, EMAC, GMAC, PS2. The unit offers wireless Bluetooth and Wi-FI 802.11b/g/n connectivity. In addition it integrates: GPS, AM/FM radio tuner, RDS, DAB/DAB+ and CAN communication. Also this unit includes an USB connected rear view camera. Diagnostics information can be retrieved by using the included Bluetooth OBD2 Module. The second aftermarket head unit, PNI A8020 HD, is a generic replacement head unit. This is a lower cost version but is essentially deployed on almost the same hardware. It comes with a 7-inch capacitive display and 1GB RAM but it uses the same Allwinner Quad-Core T3 SoC along with the same level of connectivity.

Vehicle on-board units. The on-board unit functionality can be built either as a stand-alone unit or as part of an ECU responsible for several other functionalities related to the body domain. We advocate for the latter since car access control is traditionally implemented as part of the body control module (BCM). The protocols implemented by the car access functionality are based on computationally intensive public key cryptography. Moreover, an embedded platform suitable to serve as the on-board unit as well as to implement other vehicle body functions should be able to perform all its designated functionalities in a timely manner. This calls for the use of a high performance automotive grade embedded platform capable of performing public key cryptography operations. We selected the TC297, an Infineon Aurix microcontroller, which can act in a real car as the BCM with on-board unit functionality. The multicore architecture of Aurix 32 bit microcontrollers is built to offer high performance. Covering automotive communication technologies such as CAN (and CAN-FD), FlexRay and Ethernet, the TC297 is suitable for a wide range of automotive applications. Additionally, the Aurix family introduces a hardware security module which provides random number generation, AES128 HW acceleration and a trusted execution environment for cryptographic algorithms. All these features make the TC297 a suitable candidate for the designated application.

1.3 Selecting communication interfaces

A short discussion on the three communication interfaces, i.e., Bluetooth, WiFi and NFC, that we use in our deployment now follows. While each of them can be used for any of the protocol components, pros and cons exist. Also, some restrictions may occur due to the unavailability of some of them in existing components. For example, the head units that we use are not equipped with NFC readers while their Bluetooth connectivity allows only for media streaming. We do give next a brief overview of these interfaces and how they are used in our practical implementation.

Bluetooth is a technology for wireless data transfer between devices for a short range with low power consumption. The maximum packet size that can be transferred on Bluetooth BR/EDR is 1021 bytes. In the last years, Bluetooth technology has been frequently used to communicate between the user and the car. The main use case is for the car infotainment system and in-vehicle wearables applications but also for car access control and maintenance tools. Bluetooth devices use profiles to specify the features that are supported and the type of data that can be transmitted/received. The infotainment units used in our work have four Bluetooth Profiles: Advanced Audio Distribution Profile (A2DP), Audio/Video Remote Control Profile (AVRCP), Hands-Free Profile (HFP), and Headset Profile (HSP). These profiles can be used only for multimedia functionalities. The smartphones that we used on this work have a richer set of Bluetooth profiles: Advanced Audio Distribution Profile (A2DP), Hands-Free Profile (HFP), Headset Profile (HSP), File Transfer Profile (FTP), Message Access Profile (MAP), Object Push Profile (OPP), and Phone Book Access Profile (PBAP). To transfer packets of bytes between two devices, both devices have to support at least one of the Bluetooth Profiles that uses the OBEX protocol (Object Exchange). The Bluetooth profiles that use OBEX are FTP, OPP, and MAP. Since our infotainment units do not have any Bluetooth profile with OBEX support, we used Bluetooth only between smartphones and relied on WiFi for communicating with the infotainment unit as we discuss next. However, Infotainment units with OBEX support for Bluetooth exist, so this is not a technical limitation for our protocol, it is just a small limitation of our setup.

Wireless networking (Wi-Fi) is a technology for communication with high speed data transfer. In automotive, Wi-Fi technology is sometimes used by infotainment systems and is an essential component for the connecting cars in vehicle-to-vehicle communication (V2V), vehicle-to-infrastructure (V2I) or vehicle to pedestrian communications, etc. A number of recent works have also focused on the use of WiFi for phone-to-phone communication inside vehicles, e.g., [36]. Consequently, we consider that deploying part of our protocol over WiFi is realistic and will benefit from a higher data rate. In particular we use Wi-Fi technology for access to the car from the smartphone in one protocol components that relies on larger group signatures.

Near-field communication (NFC) is a set of communication protocols which offers the possibility to establish a short-range communication between two electronic devices. NFC relies on RFID, having the operating frequency at 13.56 MHz and the bit rate between 106 kbit/s and 424 kbit/s. The communication range is up to 20 cm. A full NFC capable device can operate in one of the following three modes: card emulation, reader/writer and peer-to-peer. The first mode permits a smart NFC-enabled devices to act like smart cards, the second mode may be used for the reading and writing of NFC tags and the last mode, peer-to-peer, offers the possibility for two NFC-enabled smart devices to communicate in an ad-hoc manner. Each device that participates to the communication can be either the initiator or the target. A passive target can be powered by the RF field generated by the initiator. When compared to Bluetooth, which is also a short-range communication technology, NFC operates at a much shorter range and at slower speeds. On the other hand, the power consumption is an advantage of NFC as it consumes less power than Bluetooth. Another advantage of NFC is that it doesn’t require pairing and, from the security point of view, a shorter communication range may preclude adversaries from intercepting the communication channel. Still, attacks have been reported on NFC as well, e.g., [42], [17]. We do use NFC for sharing access rights between smartphones but still rely on cryptographic building blocks to assure security.

2 Design concept

Fig. 3: Overview of role-based access control in PRESTO-AC

In this section we discuss the design concept behind our proposal. Subsequently, we give precise details on each component of the proposed protocol suite.

2.1 Access control concept

We now present the concept behind our access control policy. The access control procedure is based on role-based access control (RBAC) to which we add some attributes that are needed for the roles. Using RBAC seems natural in automotive environments since manufacturers can easily define specific roles for a car, e.g., driver, passenger, child occupant, etc., and each role may offer specific access rights to users. In contrast, Discretionary Access Control (DAC) would require storing access control lists for each object and such lists are harder to manage. Moreover, RBAC is well understood and standard specifications exist, e.g., [15]. Numerous extensions of it have also been discussed, e.g., using attributes [27], location-aware policies [11], public-key certificates [8], or trust [9], etc. This opens road for many future applications and while the basic RBAC may be somewhat rigid it can be easily augmented and made more flexible.

A graphical depiction of the proposed access control model is suggested in Figure 3. Following at least in part accepted/standardized definitions from [15], we briefly summarize core elements:

  1. Users can either be humans or entities instantiated by software agents, however, in the protocol descriptions that follow, we generally assume that users are humans requesting a particular action from the car,

  2. Role represents the role played by an entity (human or agent). Roles include car owners, drivers, technicians, child occupants, etc., which are all played by users. Other roles such as the car rental company or the manufacturer may be played by software agents that delegate rights over the car or execute various tasks, e.g., a software update, etc.,

  3. Attributes are characteristics associated to a user, they include: time, location, driver license, age, etc. For example, a technician may perform a particular update or access to a component only if he is in the range of a particular location (e.g., the authorized garage). Attributes are either numerical or boolean, each attribute can be set to when a particular attribute is not applicable to a particular user or in a particular scenario. For example, it may be irrelevant whether a technician has or not a driving license or sometimes location information may be unavailable while certain rights should be executed on the car.

  4. Objects

    constitute the car functionalities intuitively viewed by us as files that may be classified into

    macro-objects intuitively viewed by us as folders. Macro-objects are the car functional domains related to engine, chassis, body and infotainment. Objects are the associated functionalities, e.g., adjusts seats or lights, use the infotainment unit, etc. To simplify our model in Figure 3 we have only considered macro-objects associated to four functional domains: engine, chassis, body and infotainment. This instantiation may be easily extended, we present what it seems sufficient for most scenarios that we could imagine.

  5. Actions are the activities that can be performed on an object. We view permissions over car functionalities similar to traditional Unix-like systems. Similarly to Unix files and folders we consider three types of actions: read which means to simply list the content that is as available, write which means to modify specific values and execute which means the ability to run the particular functionality. That is where each action is instantiated by a binary flag. The read permission allows a user read data, for example the user may read the fuel level, the mileage counter or the status of many other subsystems in the car. Write permissions are necessary to set specific values, for example setting the date and time, the cruise speed or resetting the trip computer. Execution rights, are required by specific programs, such as a movie player or by a software update. A technician may be entitled to make a software update, but not to play movies from Netflix, while for the passenger it’s the reverse.

  6. Permissions are the authorization given to a role over an object which makes . For example, a potential car buyer may authorized to list all functionalities in the car on his mobile phone, but without the possibility to run them. On the contrary, the manufacturer may be entitled to update the functionality. For simplicity, in the instantiation from Figure 3 we consider that permissions from a macro-object propagate identically over the objects below, but this can be changed according to practical needs.

Defining roles, persistent and ephemeral delegation. We consider that roles are predefined by the producer during the manufacturing process. Subsequently, the car owner is responsible for assigning the group public keys for each role. In this way the manufacturer cannot control a car owned by some individual but it does have control over the rights given to each role which is necessary to avoid misuse of a particular service. We consider that the owner of the car assumes a root role and that the root is the only role allowed to install public keys in the car. Rights delegation by assigning a role can be persistent or ephemeral. Ephemeral delegation is designed to be short lived, e.g., a car that is rent for weeks or days. Persistent delegation is designed to be long lived and makes role owners indistinguishable one from another, e.g., rights delegation to family of the car owner. It is obvious that the environment inside the car, e.g., mirror or seat position, does leak some information about the car occupant but addressing such issues is out of scope for us. We address privacy only from a protocol design perspective, i.e., the protocol run should not leak information about the role player in case of persistent users. Any other role can make ephemeral delegations of his access rights but persistent delegation can be done by the root only.

Rights revocation can be done by the root or the user that delegates another. Both persistent and ephemeral users can be revoked. Revocation requires a certificate revocation list that is maintained in the cloud so the car must have Internet connectivity, e.g., via 4G. While this is not a complicated demand for modern cars, it may be the case that in certain situations the car does not have such connectivity. In this situation, rights are to be revoked as soon as the car connects to the Internet or as soon as they expire based on the attributes.

2.2 Cryptographic tools

Symmetric primitives. Our protocol makes use of standard Message Authentication Codes (MACs) and symmetric encryption which are instanced by SHA2 and AES in our proof-of-concept implementation. Besides these, we use more advanced cryptographic building blocks such as identity-based signatures and group signatures. We discuss these in more detail next. While symmetric primitives are present in all protocol actions along with asymmetric primitives, they play an exclusive role in the on-the-fly execution procedure which is designed for fast interaction with the car.

Public-key primitives. Besides the more complex identity-based and group-based primitives that we discuss next, our protocol uses regular asymmetric encryptions. These are necessary in order to create a secure tunnel between participants based on regular symmetric session keys. We choose to rely on regular RSA [31] encryption because of its simplicity. While this leads to larger keys when compared to ECC, this is not a problem in the interaction between modern smartphones. Moreover, the identity-based and group-based signatures are far larger and thus the overhead induced by RSA is of less concern.

Identity-based signatures provide a more flexible framework which removes the need for exchanging digital certificates. The idea of identity-based signature originates from Shamir [32]. In our proof-of-concept implementation, we use the Guillou-Quisquater scheme [20] which is also in the ISO/IEC 14888-2:2008 standard and which was also commonly proposed for use in embedded devices such as smart-cards [21]. While the scheme is more computational intensive than the regular RSA, it can be easily handled by modern Android devices (as we discuss in the experimental section) and it removes the need for digital certificates. We now give the formal description of this scheme. The Guillou-Quisquater identity-based signature scheme is a collection of four algorithms:

  1. is the key setup algorithm that generates the master secret key and the public key . In case of the GQ algorithm, the algorithm, generates two random primes , , each having bits in length, it selects random integer , computes and . The master secret key is and the public key is .

  2. is the key derivation algorithm that uses the master secret key and the identity of the user to generate his private key. In case of the GQ algorithm, the identity of a principal is mapped (by a publicly known redundancy function) to a number then the algorithm computes . The user secret key is (since this is an identity-based scheme, the public key to verify the signatures of this user is and the identity of the user ).

  3. is the signature algorithm that takes as input the user’s secret key and a message then returns the signature . The GQ signing algorithm selects a random , computes , the hash of message denoted as , then and where is an integer such that . The signature is .

  4. is the verification algorithm which takes as input the public-key , the message and the signature and returns true if the signature is correct otherwise it returns . To verify that the signature is correct, the algorithm derives from the identity , computes , computes the hash of messages and , then the verifier and checks if then returns true if so or otherwise.

Group signatures are used in order to provide the anonymity for group members. That is, the receiver of the signature can verify that it originates from a group member, but he cannot trace the particular group member. We use the scheme proposed by Boneh et al. in [5]. Technical details are dense, we stick to a brief formalism that help us clarify the operations required by the group signature. The group signature is a collection of three algorithms:

  1. is the key generation algorithm that takes the number of group users and returns the group secret master key , the group public key

    and the vector containing the group secret keys

    that will be distributed to the group users,

  2. is the signature algorithm that takes as input the group public key , the secret key of the signer and a message then returns the signature ,

  3. is the verification algorithm which takes as input the group public-key , the message and the signature and returns true if the signature is correct otherwise it returns ,

  4. is the tracing algorithm that can determine the signer based on the group secret key , the group public-key , the message and the signature .

Additionally, the group signature has mechanisms for revoking the keys. This will require updating the public key of the group. For simplicity, we skip formalism for this procedure.

As a general rule we assume that all signatures are time-stamped, i.e, they contain a timestamp and a loose time synchronization exists between all devices in the scheme. Such a requirement is in fact ubiquitous in Internet security and should not raise additional concerns for our scenario. To avoid overloading our notations, the timestamp is not explicitly mentioned in the signatures.

2.3 Protocol steps

The procedures required by the protocol are discussed next.

I) Setup (by manufacturer) 1. : II) Set root (by seller & manufacturer) 1. : 2. : ,                       3. : 4. : III) Upload role public keys (by root only) 1. : ,                       2. : 3. :                      4. :
Fig. 4: Protocol procedures for car setup and group key upload

Car setup at the manufacturer. The procedures for setting up the car and installing the root (which is the owner) are graphically depicted in Figure 4. We consider that these steps are done in a secure environment. Generally, this should be the case since if the production environment is insecure then the software on the ECUs may already be altered which may have more disastrous consequences. Still, if this is not the case, secure channels can be introduced during setup but this is out-of-scope for our work. We assume that during production, the manufacturer installs the secret key of the car, i.e., , inside each car. Each car also has a unique identifier and the manufacturer is also responsible for installing the roles and rights which are expressed as a vector product . Since we rely on identity-based signatures, all public keys will be derived by the car from the identities of the principals with which it interacts. Any other public parameters related to the identity-based cryptographic schemes will be installed in the car at this stage, i.e., step 1.

Setting the root owner during car purchase. The manufacturer is also responsible for giving rights to the seller as expressed in Protocol II from Figure 4. This happens by simply signing an installation message containing the identity of the seller and the identity of the car, i.e., . Both the request of the seller and the confirmation from the manufacturer are signed using an identity-based scheme, i.e., . When the car is purchased, the owner first presents the owner data (these are physical credentials as a passport or identification card, etc.). Due to legal issues it does not seem viable to hide driver’s personal information from the seller, thus the owner has to present his physical credentials in some way. We assume that the seller is trustworthy and keeps the confidentiality of the new owner. The owner choses and presents a pseudonym and a public key and fixes the start of the contract as . The life-time of the purchasing contract is set to which seems a natural choice but can be changed according to practical needs. We use pseudonyms to assure driver’s privacy in front of the car manufacturer. The seller verifies the legal information and if all the criteria are met, it installs the owner data inside the car by sending the owner request message with its signature . For simplicity we also included here the messages for setting the identity of the seller inside the car, i.e., , but these can be set as well at some previous stage. We assume that the seller installs the data received from the manufacturer in a secure manner inside the car, e.g., by using the OBD port which is a wired channel (the secure channel is suggested by the double arrow ).

Setting group public keys. This procedure is graphically suggested in Protocol III from Figure 4. The owner is the only entity entitled to add group public keys. He starts a challenge-response interaction with the car by sending a message with a nonce , his identity and the car . This message is signed with an identity-based scheme as . The car replies with a message containing its own nonce and this message is as well signed as . The owner responds in by including both the nonce that he sent and the one received from the car, the message also contains the name of the role and the group public-key along with start time and validity period (we consider that validity is indefinite since the roles are persistent but this can be changed according to specific needs). The car confirms that the group public-key of the role was installed by signing message and a confirmation tag .

IV) Persistent or ephemeral delegation, i.e., 1. : ,                                  2. : ,                                               where 3. : 4. :
Fig. 5: Protocol procedures for persistent and ephemeral rights delegation

Rights delegation scenario. Both the persistent and ephemeral rights delegation procedures are suggested in Figure 5, i.e., . The distinction between the two cases is in step 2 where the content of the authentication token is different between the two. A persistent user will receive a group public key while ephemeral users will receive a signed proof of their execution rights. For the later case, the delegation holds for a specified amount of time between and . We now describe the rest of the protocol which is identical regardless of the case. The user makes a request to the owner by sending his pseudonym , an ephemeral public-key , a nonce and the role and attributes for which he requests the rights. The message is signed by the user with an identity-based signature, i.e., . The owner replies with a message containing a nonce , the encrypted authentication token and a truncated value from the signature of the previous message, i.e., . The message also contains the signature of the owner which is a group signature for the group that he is part of, i.e., . The reason for encrypting the authentication token and not yet disclosing the key is for the confirmation that the token was received in the next step. Otherwise, a delegated user may claim that he did not receive the token. In the next step the user confirms this with an identity-based signature on both previous messages, i.e., . Now the owner discloses the session key in an encrypted manner such that only the user (which has the ephemeral public-key) can decrypt in the last message . The authentication token will be used in the next procedure for executing functionalities on the car.

Execute functionality. Procedures for triggering the execution of a functionality inside the car are graphically suggested in Figure 6. The execute scenario calls for two distinct procedures that achieve the same goal. The first version relies on asymmetric primitives while the second (on-the-fly) relies on a session key and symmetric primitives alone. Obviously, the first procedure is more expensive and we assume that once a session key is established, only the second (faster) procedure is to be invoked. First, the user playing either a persistent or ephemeral user, i.e., , sends a message presenting his role and attributes along with a nonce to assure freshness. This message comes along with signature which is either a group signature (in case of persistent users) or an identity-based signature (in case of ephemeral users). For the later case, the user will also present the credentials based on which he acquired his rights from the owner, i.e., (these were received during the delegation procedure). The car replies as challenge with an ephemeral public-key , a nonce , a session identifier included in . These are signed by the car with an identity-based signature and presented as . The message also includes a 64 bit truncation of the original signature from the user, i.e, . Now the user generates a session key which is encrypted with the ephemeral public-key . The user presents the desired action on the car as an encrypted message, i.e., (note that this message also includes the last 64 bits of the car signature, i.e., ). The message is accompanied by a regular MAC, i.e, , which is performed with the session key . For the on-the-fly version of the protocol, the signatures are replaced with symmetric key Message Authentication Codes (MACs). The session identifier links the on-the-fly execution with the session key from the previous procedure (the life-time of this session key can be hours, or days, depending on the practical circumstances). The user presents his request encrypted with the session key and authenticated with a MAC, i.e., . The car replies with a nonce and this message along with the truncated value of is also authenticated by a MAC in . Finally, the user answers to this challenge with which is a MAC computed on the previous message with the session key .

We do not present additional procedures for rights revocation. All of the included asymmetric primitives have well-known revocation mechanisms. This includes the group signature in [5] for which the procedure is less obvious. While deploying such revocation mechanisms is not straight-forward, e.g., the car needs to keep a revocation list and update it accordingly, adding more details here is technically out of scope for our work.

V) Execute (by persistent or ephemeral role, i.e., ) 1. :                         2. : ,                                                            3. : ,                                                          VI) Execute on-the-fly (by session key) 1. :                                   2. : 3. :
Fig. 6: Protocol procedures for execution and on-the-fly execution

2.4 Adversary model and security arguments

As adversary model, we consider the general Dolev-Yao [14] intruder that has full control over the communication channel, i.e., he can eavesdrop, replay, inject or modify existing packets. Specific attacks related to the software implementation are out of scope for the current analysis. But as for future, more practical embodiments of our work, the use of specific Android security mechanisms or relying on hardware security, e.g., TPM 2.0 functions, may be projected.

Since we rely on existing cryptographic blocks that are assumed to be secure, rather than deriving more complicate cryptographic proofs, we consider that a proof by formal analysis (model-checking) offers better support for the security of our protocol. We choose to rely on the IF language for modelling which is the base language for the three model-checkers of the AVISPA platform [2]. In particular, we choose to rely on the CLAtse model-checker [40] from the AVISPA platform. Model-checkers assume the underlying cryptographic blocks to be perfect and model the intruder as a Dolev-Yao adversary. For brevity, we choose to model the last 2 protocol fragments V) and VI), i.e., execute (by persistent or ephemeral role) and execute on-the-fly (by session key) since these are the actual protocol components that grant access to the car. Modelling the entire protocol would require a large amount of work and would be out-of-scope for the technological readiness level that we target in the current work, i.e., proof-of-concept. By using the IF language of the AVISPA platform [2], we model each protocol step as a transition from the left-hand side (LHS) facts to the right-hand side (RHS) facts. The LHS and RHS are conjunctions of positive and negative facts and are not persistent (the RHS suppresses the LHS). The Dolev-Yao adversary is modelled by the iknows predicate which cumulates facts in a persistent manner, i.e., the intruder never forgets what he learns.

The first model that we analyze is the simple on-the-fly execution. We defined two actions, i.e., open car and start car, and ask the model checker if it can produce a trace that can trigger a start of the car given that the honest user is set to open the car. This covers the scenario in which the adversary can manipulate the commands of the genuine user. The model-checker answered that the protocol is safe. To test the correctness of our model we also added the session key to the intruder knowledge a case in which the model-checker immediately returned the attack (this proves that if the session key would have been leaked by any mean, the intruder would have been able to start the car). We also checked the consistency of the model by verifying that the genuine user can set the car in the open open state which proved to be correct.

Figure 7 shows the trace output by the model-checker when we tested that the genuine user can open the car (in case of the attack there is no trace since an attack cannot be found and the model is found to be safe). In the trace it can be easily seen that the intruder mediates the communication channel by intercepting all messages. Compound messages are built with the pair operator and symmetric encryption is modeled by the scrypt predicate. Finally, the car reaches the state state_car(2,usr,sid,kses,open,n4(NC)) which means that the user usr managed to open the car under session key kses and a random challenge nonce n4(NC) which is generated as a fresh symbolic term by the model checker.

We then proceed to the analysis of the execute procedure by persistent or ephemeral roles. The AVISPA toolset does not offer specific support for identity-based signatures or group signatures but formally speaking they do not differ in terms of the signing/verification procedures from regular signatures (the differences are in how the keys are derived and linked to an identity). In the IF language, a signature is modelled as encryption with the inverse of the public-key (similar to the RSA mechanism). For example, the response of the car in step 2 of protocol v) is symbolically expressed as iknows(crypt(inv(PkCar), pair(PkCarE, pair(NC, pair(SID , crypt(inv(PkUsr), pair(NU, pair(Role, Atr)))))))). Here, crypt(inv(PkCar),_) denotes the signature of the car on the message. We conducted similar tests as in the case of the on-the-fly procedure and the protocol proved to be safe.


i -¿ (car,4): pair() (car,4) -¿ i: pair(n4(NC), pair(scrypt(kses,pair(sid,open)), scrypt(kses,pair(n4(NC), scrypt(kses,pair(sid,open)))))) & Remove state_car(0,usr,sid,kses,open,nc); & Add state_car(1,usr,sid,kses,open,n4(NC)); & Built from trans2

i -¿ (usr,3): pair() (usr,3) -¿ i: pair(sid,pair(scrypt(kses,open), scrypt(kses,pair(sid,scrypt(kses,open))))) & Remove state_usr(0,usr,sid,kses,open,nc); & Add state_usr(1,usr,sid,kses,open,nc); & Built from trans1

i -¿ (usr,5): pair(scrypt(kses,pair(n4(NC), scrypt(kses,pair(sid,open)))), pair(n4(NC),scrypt(kses,pair(sid,open)))) (usr,5) -¿ i: scrypt(kses,scrypt(kses,pair(n4(NC), scrypt(kses,pair(sid,open))))) & Remove state_usr(1,usr,sid,kses,open,nc); & Add state_usr(2,usr,sid,kses,open,n4(NC)); & Built from trans3

i -¿ (car,6): scrypt(kses,scrypt(kses,pair(n4(NC), scrypt(kses,pair(sid,open))))) (car,6) -¿ i: pair() & Remove state_car(1,usr,sid,kses,open,n4(NC)); & Add state_car(2,usr,sid,kses,open,n4(NC)); & Built from trans4

Fig. 7: Output trace for regular user connection to the car

3 Experiments

In this section we discuss experimental results on Android phones and Infotainment units as well as on automotive-grade controllers. We discuss both computational requirements for some of the cryptographic primitives that we use as well as the protocol running time for several of the procedures that we previously described.

3.1 Android and vehicle on-board unit implementation

Figure 8 depicts the experimental setup with the after-market Android headunits on which we deployed our implementation.

We have implemented in Android Studio the last three procedures of our protocol: persistent and ephemeral delegation, execute and execute on-the-fly. We tried to keep our implementation as simple and scalable as possible. Therefore, the protocol implementation relies on a simple finite state machine. The state machine consists of three states for each of the execute and execute on-the-fly procedure, and of four states for the delegation procedure, adhering to the previous formal protocol description. The states correspond to the messages that are exchanged during the procedures. For the group signature scheme we have used the Pairings_in_C library 222 [41]. The library also contains an Android Demo that implements the group signature by Boneh et al. [5], which was easily adapted and integrated in our protocol. The identity-based signature scheme used in our protocol was independently implemented by us, while the rest of the cryptographic functions are from standard Java libraries.

For the NFC communication, we have used the NFC card reader and NFC card emulation modes. As basis for our NFC implementation we used various samples from Android CardReader and Android CardEmulation Sample provided by Google 333 The payload size of the NFC frames that were transmitted between the device running in card reader mode and the device running in card emulation mode was 254 bytes. Hence, the messages exchanged in the implemented procedures were divided in several NFC frames.

Wi-Fi communication is based on TCP IP and we used two sockets, a server socket that listens the incoming connections requests and a client socket that initializes the connection. In our application, the smartphone is configured as a client and the head unit is configured as a server. The headunit also plays the role of the access point and mobile-phones connect directly to it.

Fig. 8: Android headunits from our experiments

For our experimental evaluation the on-board unit is represented by the TC297 microcontroller clocked at 300MHz and equipped with 8MB of flash and 728KB of RAM. We evaluated the computational performance of the TC297 by measuring the execution time for the basic building blocks of our protocol. We base our implementations on the Miracl (Multiprecision Integer and Rational Arithmetic Cryptographic Library) library 444

3.2 Results

The computational time of the required cryptographic primitives on several platforms is summarized in Table IV. The GQ signature implementation was developed by us both in C++ and Java while the rest of the implementations come from the aforementioned libraries.

On the Android devices, the computational time for the Group Signature (GS) is the highest along with the 2048-bit version of the GQ signature and tops between 250-500. For the later, it may be that our implementation can further be optimized. For the Tricore in-vehicle unit the execution time becomes unacceptable with the 2048-bit version of GQ but it is usable on the 1024-bit version of GQ. Also, since GS and the 2048-bit version of GQ have similar run-times on Android, we suspect that we could further optimize the C++ code on Infineon to obtain similar performances. Since GQ and GS are used less often, the protocol should cope for a real-world car access scenario. We assume that the on-the-fly execution, which relies only on symmetric-key cryptography is the regular way to access the car while the identity/group-based execution is only triggered once to establish a session key. The DSA and RSA have much shorter runtime than the GS and GQ, but of course these traditional building blocks do not offer the advantages of group or identity-based signatures.

In Table V we summarize the complete run-time for several protocol procedures run between smartphones and head-units. These protocol fragments are tested over the three interfaces NFC, Bluetooth and WiFi. Since our car head-units did not support regular data transfer over Bluetooth, in this case we tested the execution only between two smartphones. The performance should be close however to the case when a head-unit is used. Sharing rights is done over NFC due to increased security as it works on a shorter range and is harder to spoof. Execution to the car head-unit is done over WiFi. The execution runtime is around 1 second which should be sufficiently fast assuming that only the first execution is done with the slower group or identity-based signatures. The rest of the executions are carried by the on-the-fly procedure costing only a few hundred milliseconds (since a common secret shared key exists). Figure 9 summarizes in a graphic form on some of the computational times from Tables IV and V.

Fig. 9: Execution time for: signatures on the ERISIN headunit (i) and Infineon Tricore in-vehicle board (ii), execute persistent/ephemeral J5-headunit over WiFi (iii) and delegate S5-S7 over NFC (iv)
PlatformPrimitive GS GQ 1024 GQ 2048 DSA 1024 RSA 1024 RSA 2048
Sign Ver Sign Ver Sign Ver Sign Ver Enc Dec Enc Dec

LG Optimus P700
259.21 364.35 36.90 68.70 218.50 424.80 4.54 8.22 0.91 9.81 2.15 52.59

Samsung S7
24.12 33.15 9.60 16.01 27.72 57.18 0.87 1.54 0.150 1.95 0.24 8.80

Samsung J5 SM-J500F
158.73 226.71 12.2 23.82 70.76 139.12 1.52 1.67 0.19 2.90 0.60 17.07

Samsung S5
68.09 96.54 17.9 34.98 102.98 203.25 2.37 4.23 0.26 4.04 0.78 24.91

Head-unit 1(Erisin)
181.39 261.60 22.60 39.60 113.10 220.30 4.62 6.32 0.35 4.52 0.97 26.86
Head-unit 2(PNI) 176.33 254.08 22.50 40.00 111.60 218.70 3.38 5.38 0.37 4.44 0.96 26.28

Tricore Tc297
511.60 745.60 308.00 652.00 2000.00 4120.00 39.20 48.00 7.20 70.00 26.00 462.00

TABLE IV: Computational time for cryptographic primitives on selected platforms (ms)
Comm. Execute Persistent Execute Ephemeral Execute OTF Delegate Persistent Delegate Ephemeral
1024 2048 1024 2048 1024 2048 1024 2048

NFC 943.77 1256.42 1110.77 1423.42
S7 - Head-unit 1(ERISIN) WiFi 760.88 892.55 942.21 1272.70 516.00
S7 - Head-unit 2(PNI) WiFi 721.65 851.92 1147.40 1474.49 451.00
Phone2Phone (S5-S7) BT 381.03 567.42 210.77 523.42 115.00
J5 - Head-unit 1(ERISIN) WiFi 811.43 1019.13 755.02 1203.72 381.80
J5 - Head-unit 2(PNI) WiFi 759.51 965.81 676.31 1121.61 274.50

TABLE V: Computational/communication time for protocol procedures (ms)

4 Conclusion

The increased computational power of modern smartphones and their generous user-interface facilitates the implementation of various car access control functionalities and more exquisite protocols with advanced functionalities. These can benefit from state-of-the-art cryptographic building blocks such as identity-based cryptography or group signatures. While some of these require more computational power or build upon more expensive pairing-friendly elliptical curves, computational capabilities of modern smartphones and of high-end in-vehicle units are satisfactory for handling them. The provided experimental results prove that adoption is possible both on modern smartphones as well as on modern in-vehicle controllers, e.g., an Infineon TriCore car controller. At a minimum, the RBAC access control policy for car functionalities is within reach for most of the in-vehicle units on the market. By this research we hope to open more road in addressing both the security and privacy in car access control scenarios.

Acknowledgement. This work was supported by a grant of the Romanian National Authority for Scientific Research and Innovation, CNCS-UEFISCDI, project number PN-III-P1-1.1.-TE-2016-1317 (2018-2020)


  • [1] G. Alli, L. Baresi, A. Bianchessi, G. Cugola, A. Margara, A. Morzenti, C. Ongini, E. Panigati, M. Rossi, S. Rotondi, et al. (2012) Green move: towards next generation sustainable smartphone-based vehicle sharing. In Sustainable Internet and ICT for Sustainability (SustainIT), 2012, pp. 1–5. Cited by: §1.1.
  • [2] A. Armando, D. Basin, Y. Boichut, Y. Chevalier, L. Compagna, J. Cuéllar, P. H. Drielsma, P. Héam, O. Kouchnarenko, J. Mantovani, et al. (2005) The avispa tool for the automated validation of internet security protocols and applications. In International conference on computer aided verification, pp. 281–285. Cited by: §1.1, §2.4.
  • [3] L. Bauer, L. F. Cranor, M. K. Reiter, and K. Vaniea (2007) Lessons learned from the deployment of a smartphone-based access-control system. In SOUPS, Cited by: §1.1.
  • [4] L. Bauer, L. Cranor, R. W Reeder, M. Reiter, and K. Vaniea (2007) Comparing access-control technologies: a study of keys and smartphones. pp. . Cited by: §1.1.
  • [5] D. Boneh, X. Boyen, and H. Shacham (2004) Short group signatures. In Annual International Cryptology Conference, pp. 41–55. Cited by: §2.2, §2.3, §3.1.
  • [6] R. Bose, J. Brakensiek, K. Park, and J. Lester (2011) Morphing smartphones into automotive application platforms. Computer 44 (5), pp. 53–61. Cited by: §1.1.
  • [7] C. Busold, A. Taha, C. Wachsmann, A. Dmitrienko, H. Seudié, M. Sobhani, and A. Sadeghi (2013) Smart keys for cyber-cars: secure smartphone-based nfc-enabled car immobilizer. In Proceedings of the third ACM conference on Data and application security and privacy, pp. 233–242. Cited by: §1.1, TABLE II.
  • [8] D. Chadwick, A. Otenko, and E. Ball (2003) Role-based access control with x. 509 attribute certificates. IEEE Internet Computing 7 (2), pp. 62–69. Cited by: §2.1.
  • [9] S. Chakraborty and I. Ray (2006) TrustBAC: integrating trust relationships into the rbac model for access control in open systems. In Proceedings of the eleventh ACM symposium on Access control models and technologies, pp. 49–58. Cited by: §2.1.
  • [10] S. Checkoway, D. McCoy, B. Kantor, D. Anderson, H. Shacham, S. Savage, K. Koscher, A. Czeskis, F. Roesner, T. Kohno, et al. (2011) Comprehensive experimental analyses of automotive attack surfaces.. In USENIX Security Symposium, Cited by: §1.
  • [11] M. L. Damiani, E. Bertino, B. Catania, and P. Perlasca (2007) GEO-rbac: a spatially aware rbac. ACM Transactions on Information and System Security (TISSEC) 10 (1), pp. 2. Cited by: §2.1.
  • [12] A. Dmitrienko and C. Plappert (2017) Secure free-floating car sharing for offline cars. In Proceedings of the Seventh ACM on Conference on Data and Application Security and Privacy, pp. 349–360. Cited by: §1.1, TABLE II.
  • [13] A. Dmitrienko, A. Sadeghi, S. Tamrakar, and C. Wachsmann (2012) SmartTokens: delegable access control with nfc-enabled smartphones. In International Conference on Trust and Trustworthy Computing, pp. 219–238. Cited by: §1.1, TABLE II.
  • [14] D. Dolev and A. Yao (1983) On the security of public key protocols. IEEE Transactions on information theory 29 (2), pp. 198–208. Cited by: §2.4.
  • [15] D. F. Ferraiolo, R. Sandhu, S. Gavrila, D. R. Kuhn, and R. Chandramouli (2001) Proposed nist standard for role-based access control. ACM Transactions on Information and System Security (TISSEC) 4 (3), pp. 224–274. Cited by: §2.1, §2.1.
  • [16] A. Francillon, B. Danev, S. Capkun, S. Capkun, and S. Capkun (2011) Relay attacks on passive keyless entry and start systems in modern cars.. In NDSS, Cited by: §1.
  • [17] L. Francis, G. Hancke, K. Mayes, and K. Markantonakis (2010) Practical nfc peer-to-peer relay attack using mobile phones. In Proceedings of the 6th International Conference on Radio Frequency Identification: Security and Privacy Issues, pp. 35–49. Cited by: §1.3.
  • [18] R. Garra, S. Martínez, and F. Sebé (2017) A privacy-preserving pay-by-phone parking system. IEEE Transactions on Vehicular Technology 66 (7), pp. 5697–5706. Cited by: §1.1.
  • [19] B. Groza, T. Andreica, and P. Murvay Designing wireless automotive keys with rights sharing capabilities on the msp430 microcontroller. In Proc. 3rd Int. Conf. Veh. Technol. Intell. Trans. Syst., pp. 173–180. Cited by: §1.1, TABLE II.
  • [20] L. C. Guillou and J. Quisquater (1990) A “paradoxical” identity-based signature scheme resulting from zero-knowledge. In Proceedings on Advances in cryptology, pp. 216–231. Cited by: §2.2.
  • [21] L. C. Guillou, M. Ugon, and J. Quisquater (2001) Cryptographic authentication protocols for smart cards. Computer Networks 36 (4), pp. 437–451. Cited by: §2.2.
  • [22] J. Han, Y. Lin, A. Perrig, and F. Bai (2014) MVSec: secure and easy-to-use pairing of mobile devices with vehicles (cmu-cylab-14-006). Cited by: §1.1, TABLE II.
  • [23] Y. Huang and C. Lung (2018) Device with identity verification—apply in car driving as an example. In 2018 IEEE International Conference on Applied System Invention (ICASI), pp. 243–246. Cited by: §1.1.
  • [24] (2008) ISO/iec 14888-2:2008 information technology, security techniques, digital signatures with appendix. 2 edition, ISO. Cited by: §1.
  • [25] T. Kasper, A. Kühn, D. Oswald, C. Zenger, and C. Paar (2013) Rights management with nfc smartphones and electronic id cards: a proof of concept for modern car sharing. In Radio Frequency Identification, pp. 34–53. Cited by: TABLE II.
  • [26] K. Koscher, A. Czeskis, F. Roesner, S. Patel, T. Kohno, S. Checkoway, D. McCoy, B. Kantor, D. Anderson, H. Shacham, et al. (2010) Experimental security analysis of a modern automobile. In Security and Privacy (SP), 2010 IEEE Symposium on, pp. 447–462. Cited by: §1.
  • [27] D. R. Kuhn, E. J. Coyne, and T. R. Weil (2010) Adding attributes to role-based access control. Computer 43 (6), pp. 79–81. Cited by: §2.1.
  • [28] K. Lemke-Rust, A. Sadeghi, and C. Stüble (2005) An open approach for designing secure electronic immobilizers. In Information Security Practice and Experience, pp. 230–242. Cited by: §1.1.
  • [29] Z. Li, Q. Pei, I. Markwood, Y. Liu, M. Pan, and H. Li (2018) Location privacy violation via gps-agnostic smart phone car tracking. IEEE Transactions on Vehicular Technology 67 (6), pp. 5042–5053. Cited by: §1.1.
  • [30] C. Miller and C. Valasek (2014) A survey of remote automotive attack surfaces. Black Hat USA. Cited by: §1.
  • [31] R. L. Rivest, A. Shamir, and L. Adleman (1978) A method for obtaining digital signatures and public-key cryptosystems. Communications of the ACM 21 (2), pp. 120–126. Cited by: §2.2.
  • [32] A. Shamir (1984) Identity-based cryptosystems and signature schemes. In Workshop on the theory and application of cryptographic techniques, pp. 47–53. Cited by: §2.2.
  • [33] (2015) Specification of crypto abstraction library. 4.2.2 edition, AUTOSAR. Cited by: §1.
  • [34] (2015) Specification of crypto service manager. 4.2.2 edition, AUTOSAR. Cited by: §1.
  • [35] R. Steffen, J. Preißinger, T. Schöllermann, A. Müller, and I. Schnabel (2010) Near field communication (nfc) in an automotive environment. In Near Field Communication (NFC), 2010 Second International Workshop on, pp. 15–20. Cited by: §1.1.
  • [36] X. Sun, S. Hu, L. Su, T. F. Abdelzaher, P. Hui, W. Zheng, H. Liu, and J. A. Stankovic (2016) Participatory sensing meets opportunistic sharing: automatic phone-to-phone communication in vehicles. IEEE Transactions on Mobile Computing 15 (10), pp. 2550–2563. Cited by: §1.3.
  • [37] I. Symeonidis, A. Aly, M. A. Mustafa, B. Mennink, S. Dhooghe, and B. Preneel (2017) Sepcar: a secure and privacy-enhancing protocol for car access provision. In European Symposium on Research in Computer Security, pp. 475–493. Cited by: §1.1, TABLE II.
  • [38] S. Tillich and M. Wójcik (2012) Security analysis of an open car immobilizer protocol stack. In Trusted Systems, pp. 83–94. Cited by: §1.
  • [39] J. Timpner, D. Schürmann, and L. Wolf (2013) Secure smartphone-based registration and key deployment for vehicle-to-cloud communications. In Proceedings of the 2013 ACM workshop on Security, privacy & dependability for cyber vehicles, pp. 31–36. Cited by: TABLE II.
  • [40] M. Turuani (2006) The cl-atse protocol analyser. In Intl. Conf. on Rewriting Techniques and Applications, pp. 277–286. Cited by: §2.4.
  • [41] T. Unterluggauer and E. Wenger (2014) Efficient pairings and ecc for embedded systems. In International Workshop on Cryptographic Hardware and Embedded Systems, pp. 298–315. Cited by: §3.1.
  • [42] R. Verdult and F. Kooman (2011) Practical attacks on nfc enabled cell phones. In 2011 Third International Workshop on Near Field Communication, Vol. , pp. 77–82. Cited by: §1.3.
  • [43] R. Verdult, F. D. Garcia, and J. Balasch (2012) Gone in 360 seconds: hijacking with hitag2. In Proceedings of the 21st USENIX conference on Security symposium, pp. 37–37. Cited by: §1.
  • [44] Z. Wei, Y. Yanjiang, Y. Wu, J. Weng, and R. H. Deng (2017) HIBS-ksharing: hierarchical identity-based signature key sharing for automotive. IEEE Access 5, pp. 16314–16323. Cited by: §1.1, TABLE II.
  • [45] J. Wetzels (2014) Broken keys to the kingdom: security and privacy aspects of rfid-based car keys. arXiv preprint arXiv:1405.7424. Cited by: §1.