Towards Standardization of In-Car Sensors

Zubair Nabi1 , Atif Alvi1 , and Rashid Mehmood2

1
Computer Science Department
Lahore University of Management Sciences, Pakistan
{zubair.nabi,atif.alvi}@lums.edu.pk
2
School of Engineering
Swansea University, UK
r.mehmood@swansea.ac.uk

Abstract. In this paper we propose standardization of the firmware of

in-car sensors to achieve software homogeneity across vendors. Such stan-
dardization enhances the reliability of the code by adhering to pre-set
practices and definitions. It also increases the throughput of the pro-
grammers and opens up hardware platforms to third party developers.
We make our case by advocating the use of TinyOS. TinyOS applications,
coded in nesC introduce event-driven execution and component-centric
design. Furthermore, programming in nesC reduces code size and poten-
tial bugs. We use the tyre pressure monitoring system of a car as a case
study to illustrate our model. In our implementation, TinySec is em-
ployed to address the security and privacy problems that plague current
systems. Throughout the paper we show that the use of a common soft-
ware stack automatically leads to hardware standardization and security
improvement.

Key words: VANETs, In-Car Sensors, Wireless Sensor Networks, TinyOS,

TinySec, TinyDB, Security

1 Introduction
The average car today has 100 million lines of code and the cost of software and
electronics accounts for 35 to 40 percent of the overall cost of the car [1]. This
huge amount of code makes up the firmware of both sensors and the Electronic
Control Units (ECU) used to control them. A typical intra-vehicular network
consists of hundreds of sensors connected to ECUs. This network can be a hybrid
of both wired (CAN-bus [2], FlexRay [3] etc.) and wireless standards (Bluetooth,
ZigBee [4] etc.). These in-car sensors measure temperature, tyre pressure, fuel
injection, engine knocking, air supply etc. to provide stability, safety and comfort
to the occupants. To rein in the proliferation of in-car sensors, manufacturers
are moving towards wireless connections. Wireless connectivity can save space,
reduce the car weight and induce flexibility into the network.
Moreover, in-car sensors which are wirelessly connected, can be likened with
Wireless Sensor Networks (WSN) [4]. Sensor nodes or Motes gather sensory in-
formation, perform basic processing and transmit data to other nodes in the
2 Zubair Nabi et al.

network. A typical mote consists of a CPU, radio, power source, and a variety of
optional sensory elements. The CPU is typically an embedded microcontroller
which performs all the processing. These microcontrollers run embedded oper-
ating systems – with TinyOS [5] as the most popular choice. TinyOS is an open
source, event-based embedded operating system which supports concurrent pro-
grams with constrained memory requirements. The core OS has a signature of
just 400 bytes which makes it an ideal choice for lower-power nodes.
In recent years, researchers have diverted their focus to standardization
of various automotive software stacks. Of these, two deserve a mention: AU-
TOSAR [6] and EM2P [7]. AUTOSAR (Automotive Open System Architecture)
is an ECU firmware standardization effort by manufacturers, vendors and tool
developers which aims to define a common E/E (electrical/electronic) compo-
nent based software architecture to facilitate scalability, integration, transfer-
ability and maintainability. AUTOSAR has safety as one of its prime goals and
invites novel techniques to fulfil the stringent safety requirements of automo-
tive applications. Likewise, EM2P (Emma Embedded Middleware Platform) is
a middleware platform designed as part of the EMMA project. It enables the
development of new applications for existing embedded sensors. EM2P hides the
complexity of the underlying hardware and allows hardware vendors to open
their interfaces to third party developers. It also links disparate sensors together
by introducing a common wireless communication interface. Additionally, there
has been increasing interest in the security deficiencies and mechanisms in vehic-
ular networks. This includes exploiting vulnerabilities in wireless Tyre Pressure
Monitoring sensors [8], and using the CAN-bus to infiltrate ECUs [9].
Therefore, in this paper we advocate the use of a common software and
communication stack to achieve 1) Hardware homogeneity 2) Code reliability
and 3) Security enrichment.
The rest of the paper is organized as follows. We give an overview of the
TinyOS programming model in § 2. § 3 presents our Tyre Pressure Monitoring
system case study. Related work is summarized in § 4. We conclude in § 5.

2 Background
TinyOS applications are written in nesC [10]—a programming language tailor-
made for networked embedded systems. nesC enables event-driven concurrent
execution and component-centric application design. TinyOS applications com-
piled in nesC run as single images on sensor nodes.
TinyOS applications are made up of one or more components. Compo-
nents can either be modules or configurations. Modules (which can be Private
or Public) implement one or more interfaces, where interfaces represent the
functionality of the components. Configurations assemble components together.
For example, a simple application say, TemperatureSensor would consist of
TemperatureSensor.nc (interface file), TemperatureSensor.h (header file), and
TemperatureSensorC.nc (public module) or TemperatureSensorP.nc (private
module).
 Towards Standardization of In-Car Sensors 3

Base
Station
Sensor-2

Sensor-1

Fig. 1. Tyre pressure monitoring system which consists of 4 sensors—one for each
tyre—and a base station on the CAN-bus. Original image from [13].

Also, sensor data from TinyOS can be acquired using a stream processing
system: TinyDB [11]. TinyDB exposes an SQL-like interface to the user to define
the data to be extracted and the rate of extraction. Extracted data is aggregated
and routed to a PC using in-network processing algorithms. Data security can
be enabled through TinySec [12], which is an in-software link layer security
architecture with minimal impact on performance1

3 Case Study: Tyre Pressure Monitoring System

In this section we explain the basic model of a Tyre Pressure Monitoring System
(TPMS). We then present the software implementation of a TPMS in TinyOS
using nesC. We also describe the security checks that are incorporated into our
implementation through TinySec.
To improve safety, fuel efficiency and the overall driving experience,
TPMSs [14] based on wireless sensors will find their way into all vehicles in
the United States and the European Union by 2012. A TPMS consists of sensor
modules inside each tyre that relay information (temperature, pressure, etc.) in
real time via an RF channel to an ECU. As shown in Figure 1, this Base Station
or ECU is connected to the rest of the networks via the CAN-bus. The TPMS
ECU analyzes pressure data from all tyres and raises a flag if any one of the
tyres experiences any reading fluctuation.
Although, the deployment of TPMSs is on the rise, their software and secu-
rity requirements are yet to be explored in detail. Rouf et al. [8] have evaluated
the privacy and security mechanisms employed by commercial TPMSs. Their
study has shown that TPMSs have little or no security checks in place. In fact,
messages can be reverse-engineered to track vehicles which raises significant pri-
vacy concerns. Moreover, sensor data packets can be spoofed due to lack of basic
authentication or validation. As a result, tyre pressure warning messages can be
remotely injected to launch an attack.
1
As shown in [12], TinySec has a negligible computational, bandwidth, size and energy
overhead.
4 Zubair Nabi et al.

Fig. 2. Demo run of TOSSIM for the TPMS Application.

3.1 Application Development

The use of TinyOS for this purpose enables us to address the challenges faced
by propriety software such as complex comprehensive data models and compati-
bility [15]. Heterogeneity of the various components and lack of standardization
has led to a large number of propriety tools and models. The relatively simple
mode of programming can enable the manufacturer to reduce both time and
cost pressure, as applications will have a shorter development cycle. Coding in
nesC can easily be made to follow the best practices for automotive systems as
described in the MISRA guidelines [16].
Appendix A shows the configuration file code for this application. TinyOS
automatically takes care of the underlying operating system functions and also
the network stack. It also enables automatic node and topology discovery.
We now describe the flow of the TPMS Application by using a simulation.
TOSSIM [17]—a simulator to capture the network behaviour of TinyOS enabled
sensor nodes—was used to simulate our model.
As shown in Figure 2, the application makes use of 5 motes. Mote 0 serves
as the Base Station while Motes 1-4 serve as tyre pressure sensors (one for
each tyre). We manually inject pressure readings to check the behaviour of the
network. A pressure reading of 30 psi is considered as normal while any value
below it raises a warning flag. To make the simulation as realistic as possible
we insert noise into the channel by providing TOSSIM bit error rates for each
link between nodes. TOSSIM uses this data to automatically generate Gaussian
packet loss probability distributions for the corresponding link. From timer event
4941406251 to 4941406263 the pressure readings received by the Base Station
(node 0) are normal (i.e. 30 psi). At timer event 4941406266 we intentionally
 Towards Standardization of In-Car Sensors 5

Receiver Mode Sender Mode

TINYSEC RECEIVE AUTHENTICATED TINYSEC AUTH ONLY or TINYSEC ENCRYPT AND AUTH
TINYSEC RECEIVE CRC TINYSEC DISABLED
TINYSEC RECEIVE ANY Any

Table 1. TinySec Modes.

insert a low pressure reading of 29 psi. This packet when received at the Base
Station raises a flag and as a result low pressure warning LEDs are toggled.

3.2 Security

TinySec security can be added to any application through its Make-

file. TinySec exposes different operation modes to the application
through two functions: setTransmitMode() and setReceiveMode().
Table 1 presents the compatibility of TinySec modes. Sender modes
TINYSEC AUTH ONLY and TINYSEC ENCRYPT AND AUTH work with receiver mode
of TINYSEC RECEIVE AUTHENTICATED. Additionally, security can be disabled at
the sender end through TINYSEC DISABLE and can be received with a mode of
TINYSEC RECEIVE CRC. Whereas, a receiver mode of TINYSEC RECEIVE ANY can
be used with any sender mode.
Encryption and Authentication can also be implemented on top of existing
software stacks but this would require substantial porting in some cases. TinySec
on the other hand already exists as a module inside TinyOS and does not face
any compatibility issues.
We now describe two scenarios where TinySec is effective in addressing se-
curity vulnerabilities in standard TPMSs.

Vehicle Tracking According to [8], a packet and its identifier from a tyre sensor
can be captured from a distance of 40m. Standard tyre sensor packets do not
employ encryption. Hence, these packets can be used to identify and maliciously
track any vehicle. This raises many privacy concerns.
TinySec uses cipher block chaining (CBC) [18] as the underlying encryp-
tion scheme with Skipjack as the default block cipher and an 8 byte Initial-
ization Vector (IV). Skipjack is the most appropriate choice for software im-
plementation on embedded microcontrollers with power constraints. By setting
setTransmitMode() to TINYSEC ENCRYPT AND AUTH we were able to encrypt all
sensor packets and ensure privacy.

Remote Spoofing Current TPMSs also do not employ any sort of authentica-
tion [8]. Therefore, anyone can inject malicious packets into the system. These
packets can be used to turn on the low pressure warning light and even crash
the TPMS ECU altogether.
TinySec uses cipher block chaining CBC-MAC [19] for authentication.
CBC-MAC is fast and memory efficient. We enable authentication by set-
ting setTransmitMode() to TINYSEC AUTH ONLY or TINYSEC ENCRYPT AND AUTH.
6 Zubair Nabi et al.

This allows our implementation of the TPMS to nullify the effect of remote
spoofing.

3.3 Software Configuration

TPM systems need to be reconfigured during seasonal changes and also when the
tyres themselves are changed. Traditionally, this reconfiguration is carried out by
technicians, which requires a trip to the mechanic. To simplify this calibration,
we make use of a rule layer on top of an ontology substrate. More precisely, we
add a layer of SWRL [20] on top of the ECU configuration to enable users to
calibrate on-board ECUs and sensors through the console. For instance, in case
of TPMS the user can change the summer code to winter through the following
SWRL rule:

TPMSECU(?s) ∧ temp(?t) ∧ swrlb : lessThan(?t, 5) → hasCode(?s, Winter) (1)

The above rule is in SWRL format [20]. The antecedent is composed of

conjunctions of certain conditions whose fulfilment results in the consequent.
In this case, if there is a TPM ECU (represented by the variable s) and some
sensor readings at hand that measure existing ambient temperature (t), and if
the current temperature is less than 5◦ C, then the TPM ECU has winter code
loaded into it (that has the correct winter tyre pressures). The rule can easily
be entered through a touch-screen GUI on the car console.

4 Related Work
In this section we summarize relevant related work and compare our work with
it.
Rouf et al. [8] present an analysis of the security mechanism of TPMSs and
suggest improvements to address the problems that they highlight. Their work
has already been discussed in Section 3. Reference [4] makes use of ZigBee to
implement a wireless sensor network in an automobile. Our work is different as
we focus on the software stack and the security mechanism of in-car wireless
sensor networks instead of the physical layer of communication. Reference [21]
presents a study of the usage of various security solutions for intra-car wireless
sensor networks. We carry their work one step forward by incorporating their
suggestions into a real application. Kosher et al. [9] have shown that it is possible
to infiltrate ECUs and disable a whole range of on-board safety-critical systems.
This infiltration can be leveraged to disable brakes, stop the engine etc. Also,
an attack can embed self-deleting malicious code into any ECU. The focus of
their work is the security of the CAN-bus while the focal point of our work is
the security of on-board wireless sensors. Our work is complementary to the
AUTOSAR [6] and the EM2P [7] initiatives but while the former focuses on
ECU configuration and the latter is a work in progress, we advocate the use of
existing technology and practices for in-car sensor standardization.
 Towards Standardization of In-Car Sensors 7

5 Conclusion and Future Work

We have shown that the use of TinyOS leads to improved software reliability. It
also simplifies and augments the security mechanisms. Using the tyre pressure
monitoring system as a case study, we demonstrated that application develop-
ment in TinyOS is far superior to current models in terms of scalability, and
reuse. Moreover, we have shown that TinySec can be used to fulfil the security
needs of any in-car sensor system.
Our future work includes deploying our model on an actual vehicle and ex-
ploring its performance under various scenarios. Currently, we are in the process
of designing and implementing a firewall for both intra and inter-vehicular com-
munication.

References
1. Charette, R.N.: This car runs on code. IEEE Spectrum (2009)
2. Tindell, K., Hansson, H., Wellings, A.: Analysing real-time communications: con-
troller area network (can). (1994) 259 –263
3. Berwanger, J., Ebner, C., Schedl, A., Belschner, R., Fluhrer, S., Lohrmann, P.,
Fuchs, E., Millinger, D., Sprachmann, M., Bogenberger, F., Hay, G., Krger, A.,
Rausch, M., Budde, W.O., Fuhrmann, P., Mores, R.: Flexray - the communication
system for advanced automotive control systems. In: SAE World Congress. (2001)
4. Tsai, H.M., Tonguz, O., Saraydar, C., Talty, T., Ames, M., Macdonald, A.: Zigbee-
based intra-car wireless sensor networks: a case study. Wireless Communications,
IEEE 14(6) (2007) 67 –77
5. Levis, P., Madden, S., Polastre, J., Szewczyk, R., Whitehouse, K., Woo, A., Gay,
D., Hill, J., Welsh, M., Brewer, E., Culler, D.: Tinyos: An operating system for
sensor networks. In Weber, W., Rabaey, J.M., Aarts, E., eds.: Ambient Intelligence.
Springer-Verlag, Berlin/Heidelberg (2005) 115–148
6. (AUTOSAR (Automotive Open System Architecture))
http://www.autosar.org.
7. (EMMA Project (Embedded Middleware in Mobility Applications))
http://www.emmaproject.eu.
8. Rouf, I., Miller, R., Mustafa, H., Taylor, T., Oh, S., Xu, W., Gruteser, M., Trappe,
W., Seskar, I.: Security and privacy vulnerabilities of in-car wireless networks: A
tire pressure monitoring system case study. In: Proceedings of the 19th USENIX
Security Symposium. (2010)
9. Koscher, K., Czeskis, A., Roesner, F., Patel, S., Kohno, T., Checkoway, S., McCoy,
D., Kantor, B., Anderson, D., Shacham, H., Savage, S.: Experimental security
analysis of a modern automobile. In: 2010 IEEE Symposium on Security and
Privacy, IEEE (2010) 447–462
10. Gay, D., Levis, P., von Behren, R., Welsh, M., Brewer, E., Culler, D.: The nesc
language: A holistic approach to networked embedded systems. In: PLDI ’03:
Proceedings of the ACM SIGPLAN 2003 conference on Programming language
design and implementation, New York, NY, USA, ACM (2003) 1–11
11. Madden, S.R., Franklin, M.J., Hellerstein, J.M., Hong, W.: Tinydb: an acquisi-
tional query processing system for sensor networks. ACM Trans. Database Syst.
30(1) (2005) 122–173
8 Zubair Nabi et al.

12. Karlof, C., Sastry, N., Wagner, D.: Tinysec: a link layer security architecture for
wireless sensor networks. In: SenSys ’04: Proceedings of the 2nd international
conference on Embedded networked sensor systems, New York, NY, USA, ACM
(2004) 162–175
13. (Infinite dimensional stochastic hybrid systems)
http://www.ece.ucsb.edu/~hespanha/projects/CCR-0311084-EHS03/.
14. Chatmon, C., van Le, T., Burmester, M.: Secure anonymous rfid authentication
protocols. Technical Report TR-060112, Department of Computer Science, Florida
State University, Tallahassee, Florida, USA (2006)
15. Broy, M.: Challenges in automotive software engineering. In: ICSE ’06: Proceedings
of the 28th international conference on Software engineering, New York, NY, USA,
ACM (2006) 33–42
16. MISRA-consortium: Guidelines for the use of the c language in vehicle based
software. (1998)
17. Levis, P., Lee, N., Welsh, M., Culler, D.: Tossim: accurate and scalable simulation
of entire tinyos applications. In: SenSys ’03: Proceedings of the 1st international
conference on Embedded networked sensor systems, New York, NY, USA, ACM
(2003) 126–137
18. Bellare, M., Desai, A., Jokipii, E., Rogaway, P.: A concrete security treatment of
symmetric encryption: Analysis of the des modes of operation. In: In Proceedings
of 38th Annual Symposium on Foundations of Computer Sci ence (FOCS 97. (1997)
19. Bellare, M., Kilian, J., Rogaway, P.: The security of the cipher block chaining
message authentication code. J. Comput. Syst. Sci. 61(3) (2000) 362–399
20. SWRL: A semantic web rule language combining OWL and RuleML, W3C member
submission (2004)
http://www.w3.org/Submission/SWRL/.
21. Lee, H., Tsai, H.M., Tonguz, O.: On the security of intra-car wireless sensor
networks. (2009) 1 –5

Appendix A: Tyre Pressure Monitoring Code

configuration TyrePressureAppC { }
implementation
{
components TyrePressureC, MainC, ActiveMessageC,

new TimerMilliC(), new DemoSensorC() as PressureSensor,

new AMSenderC(AM_PRESSURE) as PressureSenderC;

TyrePressureC.Boot -> MainC;

TyrePressureC.RadioControl -> ActiveMessageC;
TyrePressureC.AMSend -> PressureSenderC;
TyrePressureC.Timer -> TimerMilliC;
TyrePressureC.Read -> PressureSensor;
}