Designing Wireless Automotive Keys with Rights Sharing Capabilities

on the MSP430 Microcontroller

Bogdan Groza, Tudor Andreica and Pal-Stefan Murvay

Faculty of Automatics and Computers, Politehnica University of Timisoara, Romania

Keywords:

Automotives, RF Keys, MSP430.

Abstract:

We explore the ultra-low-power microcontroller MSP430 from Texas Instruments as potential platform for

developing vehicle keys. Radio frequency (RF) keys are still a relevant research subject as they are a common

target for adversaries while automotive manufacturers show an increased interest in adding new functionalities

to traditional keys while keeping them inexpensive. MSP430 is a low-cost, ultra-low-power, 16-bit capable

microcontroller which can handle some cryptographic primitives that can be further used for designing secure

authentication protocols. In this work we do explore the design and implementation options for a protocol

that can be deployed in a car-sharing scenario where multiple users can share or gain access rights to the same

vehicle. Due to inherent constraints of our platform, we keep the protocol simple and rely on inexpensive

symmetric key primitives while still providing advanced options, e.g., rights sharing capabilities.

1 INTRODUCTION AND

RELATED WORK

Despite their apparent simplicity and a rather long de-

velopment history, car keys are still an interesting re-

search subject. This happens because of several re-

asons. First, breaking car keys remains an attractive

subject for hackers due to the inherent value of cars

and nonetheless of the personal belongings inside the

car. As cars are frequently left unattended in remote

locations they are easily accessible to adversaries. Se-

cond, while increasing security is always possible by

using more expensive technologies (e.g., SoA cryp-

tographic designs, etc.) car manufacturers are fre-

quently trying to cut on production costs. Thus one

needs to achieve security at the lowest possible price.

Third, in the recent years there has been a spectacular

growth in functionalities that are present inside cars,

due to the massive growth of technologies that are

helpful to the driver and also entertaining for passen-

gers. Remote controlling such functionalities beco-

mes an immediate necessity and the vehicle key can

be the link to these functionalities.

In this work we try to answer these necessities by

exploring the MSP430 platform from Texas Instru-

ments as potential platform for the development of

RF vehicle keys. The main motivation comes from

the fact that MSP430 is a low-cost, ultra-low power

device that is widely available on the market. Nonet-

heless, it is a capable 16-bit controller with enough

memory to handle basic cryptographic primitives that

are mandatory for the design of a security protocol.

1.1 Targeted Scenario

The targeted scenario is depicted in Figure 1. The

scenario that we target is a car sharing scheme where

a user obtains access to a vehicle from an authorized

car-sharing center and has the ability to delegate part

of his rights further. We consider that the car sharing

center can advertise the position of existing cars, i.e.,

their GPS coordinates, via a smart-phone based appli-

cation (car-sharing by smart-phone apps is a realistic

scenario and such schemes are already deployed in

practice as several third-party solutions can be found

on the web).

However, rather than relying on access via smart-

phones, which are not yet a perfect platform in terms

of security, we want to rely on microcontroller-based

RF keys which cannot be compromised by malicious

applications. That is, a user that already has a car-key

from the car-sharing center, can locate all available

cars, choose the one that is in his closest vicinity and

use it if he has the rights. Requests for the particular

vehicle can be made from the smart-phone applica-

tion, but further access is gained with the RF key.

Moreover, we want a key to express the ability to

delegate a subset of existing rights to another key wit-

Groza, B., Andreica, T. and Murvay, P-S.

Designing Wireless Automotive Keys with Rights Sharing Capabilities on the MSP430 Microcontroller.

DOI: 10.5220/0006280601730180

In Proceedings of the 3rd International Conference on Vehicle Technology and Intelligent Transport Systems (VEHITS 2017), pages 173-180

ISBN: 978-989-758-242-4

173

User

Rights delegation

Physical car key

(with MSP430 controller)

Key issuing

Authority building

Secondary

User

Rights verification

Car-sharing center

Physical car key

(with MSP430 controller)

Car

Rights claim

Figure 1: Car access-rights sharing scenario.

hout involving the sharing center. Such a functiona-

lity may be useful in case when a group rents a num-

ber of cars and then at some point decides to change

cars between users or further keep a single car and

reconﬁgure all keys to work with the particular car.

To make access rights veriﬁable by neutral third par-

ties, e.g., authorities, that must be able to trace back

the key to the original user/issuer (for example in case

of misuse) we do store digitally signed access rights

on the key as soon as the user successfully claims his

rights over the ﬁrst car.

1.2 Related Work

Automotive RF keys were commonly analyzed by the

research community and there are numerous results

that showed them as insecure, e.g., (Francillon et al.,

2011; Tillich and W

ojcik, 2012; Verdult et al., 2012;

Shoukry et al., 2013; Wetzels, 2014). Besides poor

security, these classical car keys cannot answer to the

demands of our practical scenario. They merely im-

plement simplistic challenge-response protocols that

are useless for right delegation and veriﬁcation by

neutral parties. Recently, the use of smart-phone-

based technologies has been discussed (Busold et al.,

2013), (Timpner et al., 2013), (Hong et al., 2016) and

these approaches open road for complex car sharing

procedures. However, our work tries to avoid the use

of a secondary smart-device in order to save costs,

remove the need for carrying a mobile phone and

possibly increase security (as smartphones are easier

to compromise). Consequently, our protocol design

relies on distinct cryptographic constructions as we

need to adapt to a platform with low computational

capabilities.

2 PROTOCOL DESIGN

We begin by presenting the protocol design then pro-

ceed to a discussion on the choice of the crypto-

graphic primitives.

2.1 Protocol Details

The proposed protocol suite is summarized in Fi-

gure 3. Brieﬂy, the role of the protocol components

is the following:

1. Key issuing is the procedure designated for

releasing a new car key. This happens at the car

sharing center ShCenter and we assume that it

happens in a secure environment. Therefore,

no security measures are needed on the chan-

nel. By this procedure, each key receives an

identiﬁer ID

RFKey

, a secret key shared with the

sharing center K

RFKey,ShCenter

, the access rights

rights = {raccess,time,ltime, owner:ShCenter}

and the signature from the sharing cen-

ter over the key identiﬁer and rights

sig rights = Sig

ShCenter



RFKey

,rights



. The

sharing center also stores freshness related

information such as the time of registration and

the lifetime of the user access rights, i.e., time

and ltime. While the key cannot perform time-

synchronization with a remote server and cannot

keep a secure timer (the key is dependent on

battery which may be disabled by an adversary),

we also keep this freshness related information

on the key to be veriﬁed by third parties. Since

access to the vehicle is granted with the consent

of the sharing center, it is sufﬁcient for the sharing

center to keep a secure timer and the car can

synchronize with it.

VEHITS 2017 - 3rd International Conference on Vehicle Technology and Intelligent Transport Systems

174

2. Rights claim key-to-car is the procedure in which

the user is claiming his rights over a car. First,

the car receives the identiﬁer of the key ID

RFKey

the access rights rights along with their signature

sig rights. If the signature is not authentic or the

lifetime of the key has expired, the protocol stops.

A random value rnd

RFKey

is further used in the

challenge-response protocol to ensure freshness.

The car needs to contact the sharing center for es-

tablishing a shared cryptographic key and further

sends all the information that was received from

the key along with its own fresh random value

rnd

Car

. We assume that the communication chan-

nel between the car and the sharing center is se-

cure. This is a natural hypothesis since modern

cars are equipped with 3G/4G communication and

SSL/TLS capabilities are already present on auto-

motive grade embedded devices. Designing a se-

curity protocol for the communication channel be-

tween the car and the sharing center would be out

of scope for our work. The sharing center veriﬁes

the access rights, note that it may be that the key

acquired the rights from the sharing center or from

another key as discussed in the last procedure pro-

cedure. In the ﬁrst case the sharing center has to

verify its own signature by using the public key,

in the second it has to verify a MAC (Message

Authentication Code) with the secret key that is

shared with the initial owner of the access rights.

The car receives the shared key with the RF phy-

sical key which is computed by the sharing cen-

ter as K D



rnd

RFKey

,rnd

Car

RFKey,ShCenter



. Ad-

ditionally, the car receives a signature over the

granted access rights and the new owner-car pair,

i.e., RFKey,Car. Whenever the access rights ex-

pire, the car will deny access to the user. Now

the car answers in a challenge response man-

ner with a MAC computed over the participant

identities, the random values and the shared key

RFKey,Car

. The physical key can already compute

this shared key as it already is in possession of

RFKey,ShCenter

, then verify the response and ans-

wer to the challenge with a MAC over the va-

lues in reverse order, i.e., MAC

RFKey,Car

(ID

RFKey

Car

,rnd

RFKey

,rnd

Car

3. Car access is the basic procedure in which a

user asks for a particular functionality to the

car, e.g., open doors, windows, start the en-

gine, etc. A challenge-response protocol with

the shared key is used to prove the identity

of each participant. The key simply asks the

functionalities that it wants to perform func and

the car responds with some random material

rnd

Car

. Then the key replies to the challenge

Table 1: Summary of notations.

RFKey an radio-frequency vehicle access key

Car the vehicle to which access is requested

ShCenter the vehicle sharing center

ID id associated to an RF key or car

raccess access rights to the vehicle

func functionalities (requested from vehicle)

rnd random value

Sig digital signature

K D key-derivation process

H hash function

MAC message authentication code

with a MAC computed via the secret shared

key over the identities, functionalities, its own

random material and the received random value,

i.e., MAC

RFKey,Car

(ID

RFKey

,ID

Car

,func, rnd

RFKey

,rnd

Car

) .

4. Rights delegation key-to-key is the procedure in

which the owner of one key, can designate a sub-

set of his rights to another key. First, the key sends

a request message with its own ID. The users have

to verbally agree and check on the display of their

keys that the key IDs are correctly set. The se-

cond key responds with the granted access rig-

hts raccess

and a MAC over them denoted as

sig rights = MAC

RFKey,ShCenter



RFKey

,rights



. Finally, the requester conﬁrms that the requested

access rights have been received. For practical re-

asons, considering a rather classical interface for

the key, the requester can simply push the buttons

of the key corresponding to the access rights and

these are to be conﬁrmed by the other party. While

the physical design of the key is out of scope for

our work, for clarity, we do suggest it in Figure 2.

We consider that the insecure RF channel of this

step is protected by the visual channel between

the user and the key. Since there is no secretly

shared value between the two keys, relying on

user’s feedback is the only alternative.

5. Veriﬁcation by neutral third parties, e.g., authori-

ties, is not presented as a distinct protocol compo-

nent as this procedure is straight-forward from the

certiﬁcation chain. The neutral third party needs

to be in possession of the public-key certiﬁcate of

the sharing center and the RF key must externa-

lize the signed access rights by the sharing center.

This can be straight-forwardly achieved.

Designing Wireless Automotive Keys with Rights Sharing Capabilities on the MSP430 Microcontroller

175

Figure 2: Suggestive depiction of the envisioned RF key

from our work.

2.2 Choice of Cryptographic Primitives

Given the limited amount of memory, i.e., 1KB of

RAM and 32KB of Flash (part of which is also needed

for other non-security related tasks) and the absence

of cryptographic hardware, symmetric key crypto-

graphy seems to be the only alternative. Symmetric

primitives can be efﬁciently performed on MSP430

as will be detailed in the next section. The protocol

relies only on simple hash functions and immediate

derivatives: MACs and key-derivation functions.

More ﬂexibility can be achieved by the use of

public-key primitives, but these are for the moment

too expensive for our setup. We give here only a brief

discussion on this alternative. Asymmetric primitives,

such as the RSA or DSA, do not appear to be an op-

tion due to technical limitations. This scenario may be

interesting for reviving a cryptographic construction

that today is somewhat out-of-focus: one-time sig-

nature schemes. While several limitations exists we

brieﬂy discuss here the possibility to use them. Such

schemes were proposed in the ’80s speciﬁcally for

highly constrained devices. While there are also se-

veral more recent proposals, none of them shows dra-

matic improvements in performance compared to the

simplest construction which is the genuine Merkle di-

gital signature scheme (Merkle, 1988). The main dra-

wback of Merkle-like signatures is that they require

signiﬁcant storage for each of the signed bits.

One improvement of the Merkle scheme (see Note

11.95 from (Menezes et al., 1996)) offers a time-

memory trade-off that requires roughly 2λdk/log

λe

computations and a signature of size 2dk/ log

λe hash

outputs for signing k bits. Considering that the sig-

nature is performed over a hash (i.e., the traditio-

nal hash-then-sign paradigm) and that for short-term

use 80 bits of security are sufﬁcient, we try to get

some rough computational estimates. For example,

by setting λ = 16 the 80 bit output to be signed leads

to a signature of 2 ∗ 80/ log

16 ∗ 80 = 2 ∗ 20 ∗ 80 =

3200 bits. The number of computations is 2 ∗ 16 ∗

80/log

16 = 2 ∗ 16 ∗ 20 = 640 hash function compu-

tations. By using in advance some of the computa-

tional results from the following section, the compu-

tational time is under 1 second. Consequently, using

one-time signatures may be a possible alternative.

The only limitation is the one-time nature of such

signatures. Since the aforementioned signature will

require a key of 3200 bits and the controller has a

memory of 32KB, assuming that at most half of the

memory is used by the application data (a realistic

assumption), 4 such keys can be stored in memory.

By the use of Merkle trees these can be efﬁciently

linked to an original key, thus signing multiple times

is possible. While theoretically Merkle trees can be

extended indeﬁnitely, this will not be possible since

storing the entire path of a signature will require too

much memory. Thus, in case of one-time signatures,

the sharing capabilities will be restricted to several

sharing operations with the controllers of our setup.

While we do rely on the simpler MAC-based proto-

col, one-time signatures may be considered for further

extensions.

3 TECHNICAL DETAILS AND

EXPERIMENTAL RESULTS

We ﬁrst clarify the computational capabilities behind

MSP430 microcontrollers, then we proceed to some

details on the proposed network setup and provide re-

sults on energy consumption which are relevant for a

RF key that relies on a small battery.

3.1 Computational Capabilities Behind

MSP430

The 16-bit MSP430 family of microcontrollers fea-

tures a multitude of conﬁgurations for a wide range

of applications which require low power consump-

tion including automotive products and wireless sen-

sor networks. The computational efﬁciency of va-

rious cryptographic primitives running on this plat-

form was presented in several works. Some compu-

tational results on running SHA1 and SHA2 on an

MSP430 are given in (Romann and Salomon, 2014)

while (Buhrow et al., 2014) presents speed and energy

efﬁciency measurements for several versions of AES

and Speck. A number of papers (Hinterw

alder et al.,

VEHITS 2017 - 3rd International Conference on Vehicle Technology and Intelligent Transport Systems

176

Key issuing (secure environment at car-sharing center)

1. ShCenter 99K RFKey: ID

RFKey

RFKey,ShCenter

= K D(K

master

,ID

RFKey

rights = {raccess,time, ltime, owner:ShCenter},sig rights = Sig

ShCenter



RFKey

,rights



Rights claim key-to-car (insecure environment)

1. RFKey → Car: ID

RFKey

,ID

Car

,rnd

RFKey

,rights, sig rights

2. Car 99K ShCenter: ID

Car

,ID

RFKey

,rnd

RFKey

,rnd

Car

,rights, sig rights

3. ShCenter 99K Car: K

RFKey,Car

= K D



rnd

RFKey

,rnd

Car

RFKey,ShCenter



Sig

ShCenter



RFKey

,ID

Car

,rights



4. Car → RFKey: ID

Car

,ID

RFKey

,rnd

Car

,MAC

RFKey,Car



Car

,ID

RFKey

,rnd

Car

,rnd

RFKey



sig car rights = Sig

ShCenter



RFKey

,ID

Car

,rights



5. RFKey → Car: ID

RFKey

,ID

Car

,MAC

RFKey,Car



RFKey

,ID

Car

,rnd

RFKey

,rnd

Car



Car access (insecure environment)

1. RFKey → Car: ID

RFKey

,ID

Car

,func, rnd

RFKey

2. Car → ShCenter: ID

Car

,ID

RFKey

,rnd

Car

3. RFKey → Car: ID

RFKey

,ID

Car

,MAC

RFKey,Car



RFKey

,ID

Car

,func, rnd

RFKey

,rnd

Car



Rights delegation key-to-key (insecure environment

)

1. RFKey

→ RFKey

: ID

RFKey

, rightsRequest

2. RFKey

→ RFKey

: ID

RFKey

,ID

RFKey

,rights

= {raccess

,time

,ltime

,owner:RFKey

sig rights = MAC

RFKey,ShCenter



RFKey

,rights



3. RFKey

→ RFKey

: ID

RFKey

,ID

RFKey

,rights

users will have to check and conﬁrm on the visual display of the physical key that rights are shared between the correct

identities RFKey

and RFKey

Figure 3: Components of the proposed protocol suite: key issuing, rights claim, car access and rights delegation.

UART

Key

MSP430

S12

Figure 4: Expected network connectivity.

2014), (Szczechowiak et al., 2008), (Wenger and Wer-

ner, 2011) focus on the implementation and evalua-

tion of elliptic curve cryptography on MSP430 family

members proving the feasibility and limits of such ap-

proaches on this group of constraint devices.

We selected the MSP430F2274, a member of the

MSP430F2X/4X subfamily, as a candidate platform

for implementing the proposed wireless access sy-

stem. Versions of the MSP430F227 are available with

aerospace qualiﬁcations which are even more strict

than the ones in the automotive domain. With its 1KB

of RAM, 32KB of Flash and a maximum operating

frequency of 16MHz our choice ﬁts the device cate-

gory used for automotive key applications.

In previous work (Murvay et al., 2016) we evalu-

ated the capabilities of this device for executing cryp-

Designing Wireless Automotive Keys with Rights Sharing Capabilities on the MSP430 Microcontroller

177

Table 2: Execution speed (milliseconds) on MSP430 at

16MHz of some hash functions based on previous work

(Murvay et al., 2016).

Input size Cryptographic primitive (block size)

(bytes)

MD5 SHA1 SHA2 Blake2

128 160 256 256

8 0.427 3.642 3.691 2.263

64 0.709 7.304 7.117 2.270

576 2.985 36.74 34.50 16.85

1536 7.253 91.95 85.85 44.19

4096 18.63 239.2 222.8 117.1

tographic primitives. The test results showed that

the MSP430 core can successfully handle symme-

tric cryptographic primitives as proved by measure-

ments illustrated in Table 2 which presents the execu-

tion speed for several hash functions

when executed

for various input sizes at an operating frequency of

16MHz. Note that here we refer to the performance

of the core since the results are only dependent on the

operating frequency and are indicative on the com-

putational capabilities of the entire MSP430 family

when the same frequency is employed.

Code size for each hash function implementation

is provided in Table 3 along with the Flash memory

occupation percentage relative to the MSP430F2274

memory size. The evaluated primitives occupy less

than 20% of the Flash memory area when no optimi-

zations are applied leaving sufﬁcient space for imple-

menting the communication protocol and other appli-

cation features. If needed, occupied space could be

decreased by applying code size optimizations.

Table 3: Flash memory consumption of primitive imple-

mentations on MSP430 based on previous work (Murvay

et al., 2016).

MD5 SHA1 SHA2 Blake2

128 160 256 256

bytes % bytes % bytes % bytes %

6394 19.98 1338 4.18 2610 8.16 4046 12.64

Since the available RAM memory is not suf-

ﬁcient both for program execution and for storing

cryptographic keys the Flash memory remains the

only storage alternative in the absence of an EE-

PROM. The amount of Flash memory available for

key storage is limited by the space required for storing

the actual program object code and by the foreseen

number of required re-writes of the key storage space

during the lifetime of the product. The MSP430 Flash

is guaranteed for 10.000 erase cycles. If more re-

MD5 and SHA1 are known to be insecure and we keep

them just as a bottom line for performance

write cycles are required this can be achieved by EE-

PROM emulation at the cost of a signiﬁcantly reduced

storage space depending on the key storage structure.

Our experimental setup consists of two MSP430

Wireless Development Tools(EZ430-RF2500) made

by Texas Instruments and a NXP ZK-S12-B Kit. The

two MSP430 boards are used both for wireless com-

munication as well as for the proposed protocol im-

plementation. One of them is integrated in the car key,

while the other one is connected to the car’s BCM.

The S12 board contains a MC9S12C128 microcon-

troller and is used to stand for the BCM.

3.2 Details on Connectivity

It is relevant to point out that designing the key al-

one is not sufﬁcient without the corresponding coun-

terpart inside the vehicle. Thus, the network design

that we consider consists in a secondary MSP430 con-

troller that is placed inside the car and communi-

cates with the BCM (Body Control Module) of the

car, a unit which is responsible to all functionali-

ties related to the body (windows, doors, trunk, etc.).

For illustration purposes we choose a board equip-

ped with a Freescale S12 core, a controller that is

used in real-world BCMs. We ﬁnd that the commu-

nication between the two devices can be easily done

by using the UART (Universal Asynchronous Recei-

ver/Transmitter) interface. For our experimental se-

tup we chose to use a baud-rate of 4.8 kBaud, but the

baud-rate can be conﬁgured anywhere in a range bet-

ween 1.2 and 38.4 kBaud. This setup is suggested in

Figure 4.

A second detail on connectivity is that traditional

vehicle RF keys operate in the Ultra high frequency

(UHF) at 433 MHz. Microcontrollers from the MSP

family do posses sub-1GHz communication capabili-

ties. Our MSP430 experimental devices do commu-

nicate in the 2400-2483.5 MHz band. Using this fre-

quency band is not an issue in general as it is already

used in the automotive domain, e.g., for car alarms.

Moreover, all of the present results will hold on any

other MSP-based system core that uses a sub-1GHz

transceiver.

3.3 Energy Consumption

Figures 5 and 6 depict the energy consumption, acqui-

red by the use of an Agilent oscilloscope, as the

MSP430 microcontroller transits between several sta-

tes including a hash function computation state for

SHA1 in the former ﬁgure and SHA256 in the latter.

The voltage scale is at 50mV per division while

the time scale was set to 1s per division. The inten-

VEHITS 2017 - 3rd International Conference on Vehicle Technology and Intelligent Transport Systems

178

tion is to highlight the power consumption for crypto-

graphic functions in contrast to other functionalities.

In the ﬁrst state (1), the microcontroller is in low-

power mode, then in the second state (2) the control-

ler is in normal mode and runs no tasks in the back-

ground. This is followed by a third state in which an

LED is lit (3) and the fourth state in which it executes

the corresponding hash function (4). Then in the last

state (5) several messages are sent via RF. It is easy

to see that the energy consumption for executing the

cryptographic primitive is very low compared to the

RF transmission or even lighting a 2mA rated LED.

Consequently, the cryptographic functionalities will

not have a more signiﬁcant contribution to the bat-

tery depletion rate than regular tasks, e.g., reading a

button or making an LED blink. There is no noticea-

ble difference between the power consumption recor-

ded during the computations of the two hash functions

which . Moreover, executing SHA1 and SHA256 on

the MSP430 platform is very similar in terms of du-

ration (e.g. a hash execution on an 8 byte input takes

455µs for SHA1 and 461µs for SHA256). This ma-

kes the two plots look very similar although they re-

present execution cycles involving two different hash

functions.

Figure 5: Energy consumption during SHA1 computations

(4) compared with the consumption obtained for periods

of low-power mode, normal mode without tasks, turned-on

LED and during the RF transmissions.

4 CONCLUSION

Our work sets the ﬁrst steps in the use of the MSP430

platform from Texas Instruments for vehicle RF keys.

So far the results prove that basic security functiona-

lities (e.g., symmetric functions, challenge-response

protocols) are straight-forward to deploy while more

advanced security functionalities (e.g., digital signa-

tures) are also within reach. The main scope of our

Figure 6: Energy consumption during SHA256 compu-

tations (4) compared with the consumption obtained for

periods of low-power mode, normal mode without tasks,

turned-on LED and during the RF transmissions.

work was to clarify some of the technical constraints

on MSP430 raised by the proposed scenario. A full-

scale implementation, security proofs for the presen-

ted schemes, as well as their redesign in case of ﬂaws,

is a relevant subject for future work in case that the

ideas prove promising for further investigations.

ACKNOWLEDGEMENTS

This work was supported by a grant of the Romanian

National Authority for Scientiﬁc Research and Inno-

vation, CNCS-UEFISCDI, project number PN-II-RU-

TE-2014-4-1501 (2015-2017).

REFERENCES

Buhrow, B., Riemer, P., Shea, M., Gilbert, B., and Daniel,

E. (2014). Block cipher speed and energy efﬁciency

records on the MSP430: System design trade-offs for

16-bit embedded applications. In International Confe-

rence on Cryptology and Information Security in Latin

America, pages 104–123. Springer.

Busold, C., Taha, A., Wachsmann, C., Dmitrienko, A.,

Seudi

e, H., Sobhani, M., and Sadeghi, A.-R. (2013).

Smart keys for cyber-cars: Secure smartphone-based

NFC-enabled car immobilizer. In 3rd ACM Confe-

rence on Data and Application Security and Privacy,

pages 233–242. ACM.

Francillon, A., Danev, B., Capkun, S., Capkun, S., and Cap-

kun, S. (2011). Relay attacks on passive keyless entry

and start systems in modern cars. In NDSS.

Hinterw

alder, G., Moradi, A., Hutter, M., Schwabe, P., and

Paar, C. (2014). Full-size high-security ECC imple-

mentation on MSP430 microcontrollers. In Interna-

tional Conference on Cryptology and Information Se-

curity in Latin America, pages 31–47. Springer.

Designing Wireless Automotive Keys with Rights Sharing Capabilities on the MSP430 Microcontroller

179

Hong, J., Shin, J., and Lee, D. (2016). Strategic manage-

ment of next-generation connected life: Focusing on

smart key and car–home connectivity. Technological

Forecasting and Social Change, 103:11–20.

Menezes, A. J., Van Oorschot, P. C., and Vanstone, S. A.

(1996). Handbook of applied cryptography. CRC

press.

Merkle, R. C. (1988). A digital signature based on a con-

ventional encryption function. In A Conference on the

Theory and Applications of Cryptographic Techniques

on Advances in Cryptology, CRYPTO ’87, pages 369–

378, London, UK. Springer-Verlag.

Murvay, P.-S., Matei, A., Solomon, C., and Groza, B.

(2016). Development of an AUTOSAR Compliant

Cryptographic Library on State-of-the-Art Automo-

tive Grade Controllers. In Proceedings of the 11th In-

ternational Conference on Availability, Reliability and

Security, ARES.

Romann, R. and Salomon, R. (2014). Salted hashes for mes-

sage authentication-proof of concept on tiny embed-

ded systems. In Intelligent Embedded Systems (IES),

2014 IEEE Symposium on, pages 42–46. IEEE.

Shoukry, Y., Martin, P., Tabuada, P., and Srivastava, M.

(2013). Non-invasive spooﬁng attacks for anti-lock

braking systems. In Cryptographic Hardware and

Embedded Systems-CHES 2013, pages 55–72. Sprin-

ger.

Szczechowiak, P., Oliveira, L. B., Scott, M., Collier, M.,

and Dahab, R. (2008). NanoECC: Testing the Limits

of Elliptic Curve Cryptography in Sensor Networks,

pages 305–320. Springer Berlin Heidelberg.

Tillich, S. and W

ojcik, M. (2012). Security analysis of an

open car immobilizer protocol stack. In Trusted Sys-

tems, pages 83–94. Springer.

Timpner, J., Sch

urmann, D., and Wolf, L. (2013). Se-

cure smartphone-based registration and key deploy-

ment for vehicle-to-cloud communications. In Pro-

ceedings of the 2013 ACM Workshop on Security, Pri-

vacy and Dependability for CyberVehicles, pages 31–

36. ACM.

Verdult, R., Garcia, F. D., and Balasch, J. (2012). Gone in

360 seconds: Hijacking with hitag2. In Proceedings of

the 21st USENIX conference on Security symposium,

pages 37–37. USENIX Association.

Wenger, E. and Werner, M. (2011). Evaluating 16-bit pro-

cessors for elliptic curve cryptography. In Internatio-

nal Conference on Smart Card Research and Advan-

ced Applications, pages 166–181. Springer.

Wetzels, J. (2014). Broken keys to the kingdom: Security

and privacy aspects of rﬁd-based car keys. arXiv pre-

print arXiv:1405.7424.

VEHITS 2017 - 3rd International Conference on Vehicle Technology and Intelligent Transport Systems

180