![](bg7.png)
upload the features generated at the
manufacturing phase to the MMB using a
privileged access. The second data flow (2)
relates to events generated by the sensors
embedded in the vehicle. This encompasses the
information about incidents including crashes
and airbag deployment. The third data flow (3)
concerns the events generated by the OBU
without direct human intervention. For instance,
physical damages occurring on the OBU as well
as driving anomalies fall into this category. It is
noteworthy that all the data stored in the MBB
are (relatively) timestamped by the SU without
the intervention of external timestamping
servers.
• Auxiliary black-box (ABB): This module is used
to store data related to the applications in which
the vehicle is involved. Unlike the information
stored on the MBB, ABB entries have a finite
lifetime and cannot excess a storage space quota.
This is necessary due to the panoply of potential
applications that can enrich modern VCSs. The
security policies regulating the storage of these
application data are also stored in the ABB.
Three data flows can be considered with respect
to the ABB. The first flow (4) corresponds to
data that pass through the Data Recording
Module (DRM) and that may originate from the
application provider platform or from a local
passenger. These events do not require
authentication by the SU. The second data flow
(5) is similar to (4) except that the stored
information passes through the User
Authentication Module (UAM) prior to the
DRM. It is used for sensitive application and
user data. The third data flow (6) concerns the
security policies that are stored on the ABB.
Such information must be authenticated since the
addition or the modification of security policies
is restricted to authorized users.
The alert reader would have noticed that the MBB
and the ABB are physically separated in the sense
that no communication occurs between them. This is
perfectly sound since these two modules are
accessible by different entities. On the one hand,
write access to the MBB is hardly restricted to the
manufacturer, in the initialization phase, while read
access is restricted to the transportation regulation
authorities, in the operating phase. A tamper-proof
capability is also made available to prohibit write
access through the privileged access port (even to
the manufacturer) once the vehicle is in the
operating phase (i.e., has passed the initialization
phase). On the other hand, access modes are richer
for the ABB since different scenarios, depending on
the available applications should be considered.
More practically, data stored in the ABB can be, for
example, (partially) retrieved by the owner, a private
company (in the case of fleet management), and also
experts authorized by regulatory courts.
Through the previous discussion, it appears that
the SU is a mandatory interface to write data into the
black-box modules. Basically, the SU supports four
access modes:
Privileged access:
The SU enables this special
mode to manage the basic characteristics and
parameters of the vehicle. Privileged write access is
granted only to the manufacturer, during the
initialization phase, in order to store the VIN.
However, read access should be possible to the
entities authorized to verify the authenticity of VIN
(such entities are often agencies under the control of
the department of transportation).
Sensor events:
Modern vehicles are richly
equipped with sensors based on various technologies
(e.g., temperature sensors, velocity sensors, contact
sensors, light sensors). Depending on its sensitivity,
the information gathered by these sensors are stored
either in the MBB or in the ABB. With the
development of sensing and networking
technologies, a trend that will probably be developed
in the near future is to inter-connect the embedded
sensors.
Passenger events:
Since the driver and the
passengers are able to interact with the OBU, the
corresponding events should be handled by the SU
in order to perform authentication and timestamping
procedures. Different passenger clearance levels
should be defined in order to deploy access control
policies to the SU according to the source privilege.
Application events:
When interacting with the
available applications, several event records should
be stored to serve as proofs or evidences. Such
records range from payment receipts to
timestamping tokens. To promote fairness between
the multiple applications, lifetime and space quota
policies should be enforced by the SU.
In the privileged access mode, a user should be
authenticated before inserting modifications to the
SPMM. The possible actions that can be made:
- Add a new policy
- Modify an existing policy
A policy is defined as follows:
Security_policy = {lifetime,protection_type,access_mode}
Protecting_type:= enciphered,signed,hashed
Access_mode Є {users_class} x {read,write}
User_class:= owner | driver
The owner car associate the data related to a given
application to specific security policy. The maximum
A NOVEL MODULAR BLACK-BOX ARCHITECTURE FOR SECURE VEHICULAR NETWORKS
99