Page 60 - ATZ11 November 2019 Professional

DEVELOPMENT CYBERSECURITY

sary IT measures and methods. The Backend
specifications and recommendations
of the BSI are regarded as minimum
Provider 1
requirements and must be taken into (for example OEM)
account and implemented in the devel- Operating system
TEE
opment process of safety-critical systems Services
such as virtual vehicle keys. Internation- Web
ally accepted standards, such as the
Hardware
Common Criteria (CC) Standard and 3
2
the Federal Information Processing Telematik 1
WLAN …
Standard (Fips), valid in the USA, BLE
must be observed analogously to BSI
specifications.
User
As a founding member of RCAR [2], interaction
physical, …
an international association of motor
vehicle research institutes run by insur- Vehicle Internet, GSM, Internet,… Internet, GSM, … Smartphone
ance companies, the AZT has contrib- Domains Operating system
uted the requirements to the responsible Comfort Apps TEE
working group. The work on the interna- ECUs
ECU App
tional document was completed in May,
BLE, NFC, WLAN, …
2019, and since June, 2019, the require- TEE GW Hardware
ments for VFS have been published as Telematik Telematik
WLAN NFC WLAN NFC
RCAR Standard [3]. BLE, NFC,
BLE 5G BLE 5G
V V V Virtual Keeeeeeeeeeeeeeeeeeeeeeeeeeeeeeyyyyyyyyyyyy ||||||||||| AAAAAAAAAAAZZZZZZZZZZZTTTTTTTTTTTTTTTTTTTTTTTT ||||||||||| NNNNNNNNNNNaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaatttttttttttttttttttaaaaaaaaaaaaaallia DDDDDDDDDDDDDDDDDDDDzzzzzzzzzzziamccccchhhhhhhhhhhukk
Virtual Key | AZT | Natallia Dziamchuk
This standard is taken into account in 2 21-Aug-191-Aug-1999999999999999999 WLAN, …
the evaluation of new networked vehicle
models with keyless access systems by FIGURE 2 Ecosystem virtual vehicle key (© AZT)
RCAR institutes worldwide. Based on
this, test results will be published, for
example the five-star safety rating sys-
tem of Thatcham [4] in the UK, and are vice providers can have their data and detail. In addition, although the ac -
then also freely available to consumers. business processes carried out on one cess systems are developed by a few
This positioning of the international or more backends or data platforms. well-known global suppliers, vehicles
insurance industry is a supplement In the classic product development equipped with model-dependent compo-
to the Digital Key specification of the process of automobile manufacturers, nents of varying price and quality end
Car Connectivity Consortium (CCC) [5], the decision on the geometric and func- up on the road. If a hardware-side secu-
which is defined as an industry standard tional arrangement of components and rity gap will be discovered in one of the
primarily for development purposes from the associated costs in the various con- older components, which can no longer
the point of view of automobile and figuration alternatives of new vehicle be closed by a software update in a
smartphone manufacturers. models is made even before series devel- timely manner or only can be solved
opment begins. With an average life with large financial and logistical costs,
cycle of 9.5 years, a vehicle stays on the an entity and possibly the entire ecosys-
ECOSYSTEM VIRTUAL VEHICLE KEY
market considerably longer than prod- tem is at risk of a potentially scalable
The virtual vehicle key ecosystem, ucts from the consumer electronics attack for an undefinable period of time.
shown in FIGURE 2, consists of three industry. This raises the question of how According to automobile manufactur-
entities: a vehicle, a mobile device and compatibility between the newest mobile ers, vehicle owners are responsible for all
a backend, which communicate with devices and older vehicles can be guar- their vehicle keys – for the physical key
each other through various interfaces anteed. Even though the interface for an set and now also for all active virtual
(NFC, BLE, GMS, etc.). over-the-air update is currently being keys. The allocation and cancellation
The ecosystem can be scaled to a large implemented by the automotive industry of usage authorizations are managed by
number of vehicles, users and mobile and enables a secure software update, him mainly on a mobile device. From the
devices (for example also combinations the issue of compatibility between these practical point of view, the physical key is
of smartphone and Smartwatch) and two entities will remain open. tangible for a vehicle owner and visible
backends. Various car sharing concepts on the key board. The virtual vehicle key
can be derived from this, such as multi- is not really tangible and only abstractly
ATTACK VECTORS
user cases. Here, several users have comprehensible. Any unauthorized data
access to one vehicle or vice versa, as in Considering the expected large hardware manipulation of the driving authoriza-
a multi-key case, where different keys on gap over the lifetime of these two enti- tions on the smartphone is not necessar-
a single smartphone allow access to sev- ties, the resulting risks to which the key ily immediately noticeable or verifiable
eral vehicles. Private car-sharing provid- user is involuntarily exposed in everyday for the key users and can lead to a lack
ers or fleet operators as independent ser- life can currently not be predicted in explanation in case of theft.
54