Printer Friendly

Safe and Secure Software Updates Over The Air for Electronic Brake Control Systems.

INTRODUCTION: SOFTWARE UPDATES OF ELECTRONIC BRAKE CONTROL UNITS

In recent years OEMs increasingly suffer from software issues and their resulting costs for recalls. With very little additional effort the upcoming emergency call feature and its wireless phone connection can be used to install an internet connection into the vehicles' networks. Thus it is obvious that all OEMs are planning to use this internet connection for updating vehicles' software over the air like it is common use for computers and mobile devices.

In the past the software of electronic brake controllers (EBC) was only updated at the manufactures' sites. For changing a vehicle's software typically the whole ECUs got replaced.

Updating Software on Board

In more modern vehicle generations EBCs can get software updates via the vehicles network using the onboard diagnostic (OBD) interface and a diagnostic system in a service station.

With ISO 14229-1:2013 the service and maintenance operations of vehicles got standardized with the so called Unified Diagnostic Services (UDS). It defines a diagnostics mode and protocol for service and maintenance. Within the diagnostic mode software updates are handled within so called update sessions.

In an UDS update session the Flash memories inside the ECUs can get erased, reprogrammed and verified. Finally when exiting these sessions and modes all ECUs of the whole vehicle are getting a reset and resume normal operation now with the new software versions.

SOTA Updates

The typical approach of OEMs system architects for SOTA is to implement a so called telematics control unit TCU which interfaces to the modem for the mobile communication. The TCU is connected to the gateway of the classical vehicle's onboard network. On vehicles side all software update operations are controlled and executed by the vehicle itself using onboard services and without additional external tools like e.g. a diagnostic system.

Inside the ECUs e.g. EBC

Service and maintenance modes provide functions for updating software of ECUs like electronic braking units.

Within AUTOSAR the so called ECU state manager handles the transitions between normal operation and service modes. In order to enter a service mode all ECUs of a vehicle receive dedicated commands via the network.

In OEMs' first approach for ECUs including EBCs the functions of the service mode can be used regardless whether the update is executed via OBD or over the air (OTA). This approach has the advantage, that the UDS protocol and already existing update functions in the EBCs can get reused for SOTA without changing the EBCs.

New level of Protection Requirements for SOTA

Regarding security the method of doing updates via OBD has a big advantage: The OBD connector can get physically protected by locking a vehicle. This reduces the risk of criminal activities to attack the security and safety of vehicles via OBD without detection. In addition only single vehicles can get attacked at a time.

With a SOTA feature the TCUs wireless data connection does not provide such mechanical protection. The wireless internet connection and the update services of the vehicle are active all the time and thus vulnerable for getting attacked. Another fact makes the situation even worse: Via SOTA it is possible to attack a whole fleet at the same time.

The possibility to attack vehicles was already demonstrated in details in 2015. Not just since then most OEMs and Tierls were aware of these threats and organized the development of features to make SOTA secure. Secure Hardware Extension (SHE) [11] and EVITA [12] standards are examples of these activities.

ELEMENTS FOR UPDATING A VEHICLE'S SOFTWARE

In figure 2 the building blocks for SOTA inside of vehicles are shown.

Telematics Unit

The telematics unit (TCU) provides the mobile communication functions using mobile phone networks. They provide the emergency call feature as well as an internet connection e.g. using the UMTS protocol.

Central Onboard Update Server Within Gateway

At service stations there is a tool like a diagnostic system which is typically outside of the vehicle and is connected via the OBD interface. The diagnostic tool is connected to the OEMs server for software updates via the internet. For software updates over the air these functions need to get integrated into an onboard ECU within the vehicle's network. In this paper such function is called onboard update server and is for example integrated in the gateway.

The operations and tasks of a SOTA process and their execution in the update server are done in two phases.

1. Download of the service pack from the OEM server OTA and store it in a central storage

2. Update of the target ECUs

In a first phase the onboard update server autonomously handles all communication tasks with the OEMs server. It uses the telematics unit for setting up an internet connection downloads the service pack and stores it in a central storage.

In a second phase of the update process the update server executes and controls the update process itself. It initiates the update process and distributes the software to the ECUs e.g. the EBC.

The onboard update server needs the following hardware:

* Fast data connection to the TCU which can handle the download data rate

* Significant amount of local nonvolatile memory e.g. Flash memory in order to store the downloads: 128MB to 1GB

* Fast connection to the vehicle's network

Typically the update server is located inside the central gateway module though there are other options. There are basically two reasons why to place the update service into the central gateway module:

1. The gateway has a parallel access to most busses of the vehicle's network and thereby it can operate several tasks simultaneously and speed up the process.

2. The gateway is already today a security critical ECU because it performs other security critical tasks like bus separation and firewalling and thus should already provide a high level of security protection hardware e.g. TPM or HSM.

Service Packs and Individual Service Packs

Software updates are typically handled in so called service packs. In the front end of the update process the new software version is being released. In a second step the files of the software are formatted into a service pack such that they can get handled by the update services. These service packs are stored at the OEMs' update server for distribution to the vehicles.

The update flow shall prepare for the option to update several ECUs in one service operation. This is typically required in cases when only the combination of updates for multiple ECUs were released to drive on the road. Thus a service pack may contain several individual service packs.

For the OEMs' update server there is no difference whether the update is executed at a service station or over the air. For updates in a service station the diagnostic system handles the update operations. In an OTA process the vehicle itself has to act and handle the process. The transport media for both options is the internet.

HARDWARE OPTIONS AND METHODS FOR SECURE CONNECTED VEHICLES

Connected vehicles need secure communication, secure update processes and firewalls in order to protect them from malicious attacks.

The most critical part of protection is to be applied for securing the keys. In vehicles network communication there are typically several keys which are used for different purposes, e.g. for unlocking Flash memories or debug ports, for cyphering messages, for signatures and certificates, for exchanging checksums in form of a secure HASH, or keys for exchanging keys.

The storage for keys is the most critical location from security point of view. Special hardware units with high level protection measures are required in order to protect the keys from external access. These hardware units are typically also responsible for operating all security processes where those keys are being used.

Infineon offers two types of hardware units for protected key storage and security operations, TPM and HSM. These are described later in this paper.

Depending on the key length, keys are more or less secure and the security processes take more or less time.

Asymmetric encryption methods are regarded as more secure than symmetric ones. Symmetric encryption methods are using the same key at both ends of a communication channel. Asymmetric methods are using two keys, a private and a public key. The public key is used to encrypt messages. After that these messages can only get decrypted by the owner of the corresponding private key. For example the OEM's server has the public key of a vehicle and thus can send to this vehicle messages which only can be decrypted by that vehicle. Symmetric methods are typically significantly faster than asymmetric.

Both methods are typically combined to improve the communication throughput without losing the security level. In order to set up a secure communication channel, asymmetric methods are used to exchange symmetric keys which then will be valid for a short period of time and might be changed several times during the conversation.

Inside the vehicles typically symmetric AES128 keys are being used for cyphering. The same method but with frequently changing keys is used to transport service packs from the OEM's server to the vehicle.

Malicious Attacks and Their Prevention

There are mainly two types of attacks to the networks of vehicles, attacking the protection of the vehicle itself and attacking the systems of the OEMs or Tier1s. In this paper the first type is elaborated.

Protection of networks and its security architecture must get planed. With a security assessment the attack scenarios and threads are listed and classified according to their criticality for the system. In a second step the security efforts and hardening measures can get defined.

Attacks to protected systems are often performed by operating those in a non-specified mode or certain functions are manipulated to perform a task which it is not supposed to do. A general concept to mitigate these attacks is to separate the system in various security domains which are isolated from each other.

Example of security domains are:

1. Hardware security domains which isolate the cryptographic processing and key storage from the rest of system

2. Different privilege level in operating systems

3. The isolation between domains within the vehicle by a gateway incorporating firewalling

To create security domains soft- and hardware support is required.

Vehicle Security Architecture for SOTA

Well-defined security architectures make vehicles' electronic networks secure without reducing its performance.

The following chapter describes the security aspects of the three building blocks which are recommended for a secure architecture for SOTA:

1. The telematics control unit establishes the data link and is executing the service authentication. An automotive microcontroller is typically used to connect the modem and its application processor to the vehicle's network.

2. The Central Update server provides all SOTA services like they used to be executed in the service station by the diagnostic system connected via OBD. In this paper and as an example the central update server is implemented within the central gateway. The service pack is stored in a central storage within the gateway and is verified for the first time. The central storage may contain several versions and act as storage for all software updates. This storage is likely to be implemented in a dedicated flash memory of decent size.

The OBD interface remains connected with the central gateway, and may provide alternate options and functions.

3. The Target ECU e.g. the EBC which will receive the update and will execute the secure update.

The control units are connected by different bus systems with different data rates and communication protocols. The type of bus can have a significant impact on the update duration depending on the implementation model as it will be described later in this paper.

Trusted Platform Module

The Trusted Platform Module (TPM) is a standardized embedded hardware device intended for security purposes. Its technical specification was defined by the Trusted Computing Group (TCG). TPMs were first introduced to enhance the security of portable personal computer like business laptops.

The most important capabilities of a TPM on computer platforms are integrity checks of critical parts of the software, storing private keys used in cryptographic operations, creating true random numbers, storing certificates used in the Public Key Infrastructure (PKI), creating symmetric and asymmetric keys and securely executing cryptographic algorithms where private keys are processed.

The following subsections show how some of these features can be used in the automotive domain.

Vehicle Identification

Identifying vehicles only by their VIN or by their IP address is not secure and can easily be attacked. This is a fact which is already well known from computers.

Secure identification methods are also called authentication and are using asymmetric cryptography with a public and private key. A TPM can securely store private keys and use them to securely sign random numbers used in authentication protocols.

Secure Boot and Integrity Check

On PC platforms a TPM is used to ensure a secure boot as a first step for checking the integrity of the device.

In vehicles the secure boot and integrity check is performed in two levels. The secure boot is performed at every safety critical ECU locally. Typically this service is executed by the HSM inside of the microcontroller. The integrity of the vehicle is ensured by exchanging certificates of a successful boot with the TPM. Thus the central TPM is just indirectly involved in secure boot operations.

Random Number Generator as Basis for Secure On-Board/Off-Board Communication

The TPM provides a certified true random number generator which can be used to enhance security protocols. In the past, many security protocols have been broken due to the usage of poor (predictable) random numbers. True random numbers are used first to create challenges within authentication protocols and second to generate session keys. Session keys are used for a defined period of time for fast encrypted data transport.

TPM: Central Secure Element Within the Vehicle

In vehicles the TPM can act as the main trusted anchor. The TPM is highly recommended to operate as the entity to store sensitive private keys and process certificates.. It can generate individual asymmetric keys for the ECUs at production, service and in case of updates and use them for authentication.

TPMs are produced and personalized with key injection procedures in a security certified manufacturing environment. Those injected credentials are best secured in the respective TPM, being tamper- as well as resistant against side-channel attacks. In that way, the named credentials (certificates, keys) are secured over the complete supply chain, no further need to take measures to protect them against unauthorized access during transportation and production process and later on of the car itself.

In other words each TPM stores a highly secure random number which is used to provide unlimited numbers of unique asymmetric keys which cannot be read by others. Only the public parts of these keys are shared with trusted communication partners for example with the OEM server. One single TPM in a vehicle significantly improves the protection of all other keys with just little impact on the total cost of security.

Furthermore the TPM shall also be used to generate and update vehicle specific keys for ECUs at production, service, and update operations. Such services are executed within the vehicle and thus make key generation processes very efficient and secure at the same time.

The OPTIGA[TM] TPM from Infineon has a CC EAL4+ certified temper proof design and architecture. It provides an individual private key by hardware and unlimited number of asymmetric/symmetric keys. It also comprises an AIS31 certified true random number generator.

Hardware Security Module HSM

Microcontrollers with HSM provide a dedicated domain which can isolate security functions from the application functions. Like many other suppliers Infineon offers such products within the AURIX[TM] microcontroller family.

Currently the main function of the HSM is to act as a trusted execution environment for storing and processing keys. This includes security services and operations where these keys are being used like cyphering, integrity checks of boot sectors, and secure HASH (SHA) calculations.

With HSM the level of security is scalable. The HSM is a fully programmable 32bit microcontroller with own memory and peripheral resources. Typical peripherals of HSM are true random number generators, hardwareaccellerators for cyphering and secure HASH calculations, and timers.

For initial integrity checks the HSM provides the implemented 'secure boot' feature. Before allowing the application software to execute its code after reboot, the HSM computes a secure checksum (e.g. AES128 MAC or SHA256) and by this checks the trust level of the application software. Even on-the-fly code checks of the application software (e.g. for the secure Flash Boot Loader) can be easily applied in case of SOTA.

Protecting EBCs

An EBC module is a typical example of a safety critical ECU. It needs protection in two ways: the vehicles safety and the IP of the Tier1 need to get protected from unauthorized access.

EBCs are typically protected by mechanisms and hardware support based on either SHE or EVITA-medium standards. Software downloads shall use encryption ad being decrypted inside the ECU. Especial care shall be taken to protect the used encryption keys and authentication signatures.

It is strongly recommended that EBCs have either a SHE [11] module or an EVITA [12] compliant Hardware Security Module (HSM).

The HSM module inside of the AURIX[TM] microcontroller provides these services according to the standards.

SECURE SOTA FLOW INSIDE THE VEHICLE

The SOTA process can be separated into two phases.

1. The reception and the intermediate storage of the new software which can be done while the vehicle is in use (as we already explained before). In our example this function is performed in the gateway.

2. The update of the target ECUs

There are basically three security methods used for protecting the vehicle and the ECUs: Authentication, encryption, secure hashing

Authentication uses encrypted certificates with the main purpose to securely identify the originator of a message.

Various methods of encryption are being used for messages and data. The methods differ in the cyphering speed and in the security level.

End to end encryption of service packs shall be used for the update process. SOTA data for electronic braking ECUs shall be encrypted by the Tier1 with their dedicated keys and will get decrypted inside of the braking ECU only. Throughout the whole transport these data shall not be readable by others.

According to the EVITA standard a medium level is sufficient here. The typical encryption for ECUs' data is using AES128 symmetric encryption. AES128 typically fulfills the speed requirements. The medium protection can get enhanced by the other two methods.

A hash is mainly a special checksum with a very high detection of changes Secure Hash Algorithms (SHA) are using security protection mechanisms. For SOTA e.g. a SHA256 is proposed. The hash is calculated by the receiver of a data block. In parallel to the data an encrypted compare value of the hash is transferred. The received data are only accepted if the calculated hash matches the compare value. HSM modules typically offer hardware accelerators for SHA calculation.

Secure transport via the internet: Secure transports via the internet are established functions of network communication, which are not further discussed in this paper.

The secure SOTA process within the vehicle begins when receiving the data via a wireless internet connection. After removing the secure wireless transport protocol layers the data are stored in a central storage, for example inside of the central gateway.

The considerations on the proposed security flow can be broken down in three main steps (figure 4) and is explained in the sub-chapters "Authentication", "Verification" and "Secure distribution of the update within the vehicle".

Authentication

The service authentication is an essential element for the security of the SOTA process. Authentication methods are used for both, connecting to the OEM's update server for identifying the vehicle and within the vehicle to identify the source of a message. Typically asymmetric keys are used for authentication.

In the so called mutual authentication method two parties use the others public key to exchange certificates. Certificates are an encrypted form of signatures combined with clear text information.

In the SOTA process, the vehicle and the OEM server need to authenticate mutually. Therefore both, the OEM server and the vehicle need to know the others public key.

The update of safety critical ECUs like braking control units needs a high level of security, too. Thus also within the vehicle mutual authentication shall be used for authenticating safety critical ECUs.

The highest level of a secure authentication process shall also be used for exchanging and updating keys including HASH keys during the update process and to ensure proper integrity checks after the update with the new software in the vehicle. Thus it is obvious that the keys for such authentication need highest protection against any kind of attacks including side channel attacks.

Service Pack Verification

After successful authentication, the server is able to identify the vehicle and further receive additional information to provide the right service pack.

Mitigation procedures due to verification errors and potential transmission errors should not impact the time the vehicle cannot be used. It is therefore assumed that a first verification of a service pack is already done within the central storage in phase one.

Since the gateway verifies the integrity of an encrypted service pack without decrypting it, just by calculating a secure HASH, no further measures have to be implemented to assure authentic communication between telematics unit and gateway.

The gateway uses the HSM for the verification of the service pack. Since the verification process is only using public certificates and no secret keys, security requirements are lower than in the authentication process. Additionally the performance of the verification will benefit from high performance crypto accelerators and fast communication busses of the HSM.

For the time being we assume that the firmware update is signed and verified as a whole but it is also possible to separate the firmware in smaller blocks which are each signed individually. This would also offer the possibility to repeat the authentication process and by this create a new session key. Thereby, the time a session key is used is shortened. This is a barrier against side channel attacks requiring the repetitive use of the same key over a longer period of time.

Only after this phase is successfully finished, phase two (the update of the target ECU) should be initiated.

Secure Distribution of the Service Pack Within the Vehicle

For electronic brake control units this step is most relevant. The functions and services of this step are equal for both, updates via OBD and updates OTA. Within the braking ECU the update process is being executed by the so called secure Flash Boot Loader.

Via secure and authentic communication, the gateway signals to the braking ECU, that the individual service pack can be transferred and the transfer starts after confirmation of the target ECU.

The communication and data transport between the gateway and the target ECU can be secured by message authentication codes (MAC). It is assumed that the MAC is based on symmetric keys using e.g. CMAC and AES..

Besides MAC the transfer process of the service packs via the internal busses requires no further security measures in case the package itself was encrypted by the issuing OEM or Tier1. The integrity of the update is finally verified and decrypted inside the target ECU.

For braking ECUs this means the ECU verifies the individual service pack for a second time by using the HSM.

The typical function executing these tasks within an ECU is the secure FLASH Boot Loader which will be explained next.

Secure Flash Boot Loader

Within each ECU the Secure FLASH Boot Loader (SFBL) handles all required firmware update functions in a secure way. The difference between a secure and a non-secure FLASH Boot Loader is mainly the usage of additional crypto algorithms and the use of the HSM for execution of security functions.

The complete re-flashing process has to be handled out of the limited SRAM sizes of the microcontroller. Thus service packs are formatted and transported in smaller blocks e.g.4kBytes.

Each of these blocks is received and handled by the SFBL individually. The security protection of each block may consist of MAC certificates and encryption.

Encryption is typically used for end to end protection of the service pack throughout the transport from the Tier1 to the ECU best with an ECU specific symmetrical AES128 key.

Another security function of the SFBL is the generation and checking secure cryptographic CRC (cyclic redundancy check) i. e. with a SHA256 algorithm.

A secure hash is used for integrity checks. It can get generated by the SFBL after a complete ECU service pack is stored in the program FLASH of the braking ECU, or with any reset and restart of the.

An important step of an update process is to transfer the SHA256 compare values into the HSM key storage separately with each software update and by using higher protection levels like asymmetric encryption.

Besides security operations, the SFBL handles all operations for erasing and programming of the microcontroller's Flash. The Flash operations are regarded as a critical phase of the SOTA process. In order to avoid any kind of brain dead situations the SFBL must be able to handle environed disruptions, and resume SOTA operations after for example loss of power. A 'brain dead' situation for an ECUs means it is no longer able to resume operation after restart. In case of SOTA this might lead to a nonoperational vehicle in a remote location.

As a general recommendation all updates of critical software which might affect any basic operation or security related task (HSM) or a brain dead critical routine should not be part of a SOTA operation. Critical software can only get updated in the protected environment of a service station. Conclusion: the SFBL itself is excluded from the SOTA update procedure.

FRONT END VIEW OF A SECURE SOFTWARE UPDATE FLOW

In previous chapters the flow of the secure SOTA process within the vehicle was described. In this chapter the operations for generating a secure service pack are explained. This flow is equal for doing updates OTA or at the service station.

As mentioned before the protection of passwords and security keys is the essential task for making connected vehicles in general and especially software updates secure.

All participating parties of an update process are requested to install security services and a secure flow for handling their keys such that unauthorized people cannot get hold of any keys. Protecting the keys in the front end process at the Tier1s and OEMs must be done with equal levels of security as within the vehicles.

Security Infrastructure at OEMs and Tier1s

The files with the new software versions are formatted several times, by the Tier1s and the OEM in order to generate a service pack.

In a first formatting process the software file is formatted, encrypted and signed for being handled by the secure Flash bootloader. The keys for encryption, the signatures for authentication and secure HASH data are typically handled by the Tier1s. The result of this step is an individual service pack.

The second formatting process combines multiple individual service packs into one service pack which in total represents all changes for the vehicle's new software release. The OEM will sign the service pack for authentication and provide secure HASH data for integrity checks of the service pack. The OEM also provides HASH key updates for all non-participating ECUs which participate at authentication processes on vehicle level and thus should be aware of the changes in the network.

For both formatting steps both parties need to have a security server which allows them to generate, store and update keys. Such service is used not only for updating software but also during the production of vehicles. It must be protected against any kind of attacks.

There are several service providers which offer complete solutions for security servers and key generation and handling.

OPTIONS TO IMPROVE THE UPDATE SPEED

Plan to Reuse Existing Update Methods for SOTA

Software updates and recalls are expensive for OEMs. SOTA is regarded as the best option to significantly reduce these expenses. There are already mechanisms implemented to update the vehicles' software at service stations. These mechanisms shall be reused in order to get SOTA as soon as possible.

While doing software update at the service station the vehicle is typically in a predicted environment and out of operation for a longer time. For SOTA the situation might be different. The location of the vehicle can be anywhere, the environment can vary and even the time while the vehicle cannot be used directly influences safety and the owner's acceptance of the update process.

It must be absolutely ensured, that the vehicle will not move while changing the software. In contrast to software updates at service stations the SOTA concept even must consider different levels of technical knowhow for all possible drivers, who might start an update. This requirement is not just critical for updating the EBC itself but also for updating other ECUs within the car.

For SOTA at braking units it must get considered that during the update process the brakes cannot be released by the driver on one side, but on the other side it must be possible to release the brakes for bringing the vehicle to a service station in case the update process failed and the vehicle must get towed.

Users are used from mobile computing devices to follow a list of rules when doing OTA updates. One typical rule is to ensure that there is enough power available for the time of the update. In this point updating vehicles is more critical than for example updating a mobile phone because drivers typically do not have a power supply at hand. Thus another critical parameter of the SOTA process is the time it takes to execute the update. Short update times prevent problems with the battery and in parallel prevent drivers from trying to disturb or interrupt the update process

Bottleneck Vehicle's Network

Transportation speeds of different vehicle network protocols and specific bus implementations have been recognized as the main bottleneck in the SOTA process since the data need to be transferred from the central storage to the target ECUs. Network topologies differ significantly from OEM to OEM and have a high influence on the downtime.

In the following approaches are presented that consider the impact of the network topology. The characteristics of different solutions can by roughly distinguished by the following parameters:

1. The way how service packs are getting distributed from central data storage to the specific ECUs

2. How many ECUs are able to change software in parallel

3. How long the vehicle is out of operation as a result of 1. and 2.

Options to Reduce the Downtime

Three different approaches are discussed to reduce the downtime of vehicles without interfering with specific solutions of the different OEMs:

1. Classic approach: Update of individual ECUs by loading and reprogramming individual service packs over the vehicle network to the embedded FLASH in one step.

2. A/B Swap: The main idea of the approach is, to have two blocks, A and B, of FLASH memory for code execution within the microcontroller. The SW download from the central storage to the target ECU and reprogramming of the "spare" memory can get executed in the background and as slow as necessary to ensure full operation of the vehicle.

3. Additional local storage memory on ECU level: service packs are distributed to this local memory in the background (during vehicle operation). The participating ECUs are than updating their software out of the local storage either at power-down or-up (thus out of the safety critical operation)

Classic Approach

In this paper the solution is called classic, because all existing ECUs which can get a software update via OBD can also be used with this approach (provided the gateway has the already described extended functionality). It does not require any changes of hardware within the ECUs. The drawback is, that especially with slower busses like CAN, the bus speed mainly defines the duration of the update process.

The table below shows examples for a 4MByte-update using different bus standards under realistic operation conditions. The realistic raw data rate (payload) of the respective communication protocol is determinate by the protocol overhead, the nominal data rate and application specifics.

Please note that in addition to transporting the update there is some extra time needed to decrypt the individual service pack and to erase and write the Flash memory.

The issue of the classic approach is obvious: when using the most common implementation of CAN with 500kbits/s and updating one ECU takes almost 5 minutes. In case of a service update of 20 MCUs (with 4 MBytes each), the vehicle could not be used for 1h40min.

This time window can be optimized by additional measures on network level. As one example, it is possible to transfer service packages in parallel, in case the central SOTA storage is located at the central gateway. Another meaningful approach to decrease the data foot print is to use data compression.

The classical approach is regarded as a very cost efficient solution. On the other side there might be enough peer pressure for the OEMs to look for quicker solutions especially to attract their customers in the premium market segments of vehicles even if that will add extra costs.

A/B Swap

A more elegant, but costly solution is the so called A/B SWAP method (in the middle of Figure 6). The main idea of A/B SWAP is to have two separate blocks of FLASH memory for code execution within each microcontroller of the single ECUs [5]. E.g. if block A is used for executing the actual code, then block B is spare FLASH memory. The new software version is programmed into block B in a background operation (while driving). After all ECUs have finished the background process, a command of the central SOTA controller (the gateway in our case) swaps code execution from block A to block B. The SWAP is completed with a final restart of the ECUs. The significant advantage of this approach is the fact that the downtime of the vehicle is very small. A restart takes less than a few milliseconds and can be added to the power-up or -down cycle as mentioned before. In case something went wrong within the vehicles network there is a fallback solution available within block A. If the new software image of any ECU turns out to be corrupted there is always the option to switch back to block A of all involved ECUs of the actual service update within a few milliseconds.

The drawback of the solution is that the size of embedded program FLASH is doubling and the mechanisms for swapping are not available in most microcontrollers today. In this context it's worth mentioning that most automotive applications (with a few exceptions e.g. in the infotainment domain) are operated in microcontrollers out of embedded Flash. This is mainly due to the high demands on system availability and functional safety of the vehicle.

The demand for a seamless memory swap mechanism is a particular challenge for any microcontroller supplier. In addition to the availability of components with the required memory sizes, the potential impact on the entire system architecture has to be carefully considered in order to come to a robust implementation of the swap mechanism. The potential impact of the overlay mechanism on the functional safety and security must be analyzed in details.

Doubling the FLASH of a microcontroller from e.g. 4MB to 8MB obviously increases the cost. This adder can be quite significant as microcontrollers - in contrast to application processors or stand-alone Flash memories - are based on an embedded technology (thus a combination of a memory and CMOS technology with corresponding yield implications). The challenge of the A/B Swap approach is even higher for components at the upper memory limit of the actual technology note. The biggest embedded FLASH memory sizes are today offered in the range of 8 to 16MB. The situation is aggravated by the fact that those MCUs in the car with the biggest embedded FLASH are the ones that are the most prone for potential software bugs or the most desired candidates for in the-field feature enhancements (a typical example is the engine control unit).

Update from Local Storage

The third approach is based on the fact that modern microcontrollers can erase and reprogram the program FLASH much faster than in the past. For example a 4 MBytes FLASH can get erased and reprogrammed within 8 s. Such speed improvements are key for the following approach that also allows avoiding long vehicle down times as described for the first approach.

The proposal is to add a local memory buffer to each target ECUs in form of an additional external serial FLASH. The resulting overall update time for the selected 4MByte reference stays well below 9 s despite the comparable slow serial connection (including the necessary communication overhead).

The decisive advantages of the local memory solution in comparison to the A/B SWAB approach can be summarized as follows:

* Minimal interference with the existing system design and therefor manageable risk (including system safety & security, development effort and time for re-qualification),

* Relatively small extra cost compared to the amount of additional embedded Flash.

* Small form factor of the extra component

Comparison of the Three Approaches

Figure 8 gives an overview on the advantages and disadvantages of the different solutions.

The benefits of the third method outweigh the penalty of the slightly increased non-availability. These are the key advantages of the local storage in comparison to the first two methods:

* Download in background: Like with A/B SWAP downloading of service packs can be done in the background during normal operation without interference.

* Parallel update: Once the distribution is complete all ECUs can execute the update task in parallel. This is a big advantage compared with the classical approach.

* Low cost adder: The advantage is that serial FLASH devices are available for lower cost and with bigger sizes in automotive quality than integrated FLASH. The form factor of the external device is very small. Even the biggest sizes of code can get handled with this approach. Second it might be considered that the size of the central storage can get reduced. Inside of the local memory all necessary integrity checks can get executed in the same way as in the central storage, too.

* Low risk and development effort: Less modifications to an existing system design in comparison to A/B SWAP approach.

* Devices available from multiple suppliers: In contrast to the A/B SWAP the third solution can get implemented with existing standard components (e.g. serial NOR-FLASH types) which are already available in a wide range today.

It should be pointed out again that all considerations are based on the specific requirements of microcontrollers which are based on embedded FLASH. The A/B Swap might be beneficial for any processor operating from external memories. Nevertheless, safety and security requirements must be considered.

OEMS STATUS AND CONSIDERATIONS ON SOTA

The authors of this paper have good insight in the latest SOTA requirements of most OEMs. Their status in introducing security functions and SOTA is very different:

* All OEMs' are planning to introduce SOTA with the target to save costs for future software updates.

* Some OEMs already have implemented the internet connection into the vehicles network without implementing security functions and several ones already got hacked.

* A few OEMs are already far in installing security infrastructure on their facilities and security features throughout their vehicle communication networks. Protection of safety critical ECUs and especially the EBC has highest priority for this group.

* SOTA for EBCs is planned but not yet enabled. It shall get enabled only after the process has proven to be safe.

With SOTA the OEMs put the update process into the hands of the driver instead of having experts who are trained to follow the rules and steps of a process manual. In contrast to software updates at service stations the SOTA concept must consider all levels of expertise and behavior of all possible drivers, who might start an update.

Intermediate Solution - SOTA at the Service Station

The intermediate solution is to update vehicles at the service station but without using a diagnostic tool. Such updates can get started and handled by trained persons at the parking lot of a service station or dealer ship using the onboard SOTA functions. This approach has several advantages:

* The costs for such updates are expected to be less than 10% of what is calculated for updates via OBD.

* Trained experts can start SOTA updates on several vehicles in parallel.

* It is expected that drivers will better accept such procedure because after a few minutes they will be able to leave the service station with their car and the new software version. Updates via OBD typically take hours.

* In case of unexpected problems e.g. loss of power, a service station typically has the equipment to fix it without towing the vehicle e.g. external electric power supply

Thus many OEMs today are planning to introduce SOTA in an intermediate step first and to go for remote updates in a later stage. Especially for updating EBCs and other safety critical ECUs they wait until there is enough experience.

REFERENCES

(1.) ISO, ISO 14229-1:2013 Road vehicles--Unified Diagnostic services (UDS)--Part 1: Specification and requirements, ISO, 2013

(2.) ADAC e.V. "ADAC deckt IT-Sicherheitslucke bei BMW auf: Autos elektronisch geknackt", https://presse.adac.de, Jan. 2015.

(3.) Computerworld, Inc,, "Over-the-air software coming soon to your next car", http://www.computerworld.com, Feb. 2015.

(4.) WEKA FACHMEDIEN GmbH., "Warum die Autoindustrie neue Software Updates braucht", http://www.electronicnet.de, Mar. 2015

(5.) Lobdell, M., "Robust Over-the-Air Firmware Updates Using Program FLASH Memory Swap on Kinetis Microcontrollers", Freescale Application Note, AN4533, Rev. 0, Jun., 2012.

(6.) Infineon Technologies, AURIX - Highly integrated and performance optimized 32-bit microcontrollers for automotive and industrial applications, Infineon Technologies, 2016

(7.) CNN., "100 million car recalls since the start of 2014", http://money.cnn.com, May 2015.

(8.) Shanker, R., Jonas, A., Devitt, S., Huberty, K. et al., "Autonomous Cars: Self-Driving the New Auto Industry Paradigm," Morgan Stanley Blue Paper, Morgan Stanley & Co. LLC, Nov. 6, 2013.

(9.) Statista Inc., "Car manufacturers' recall rate in the United States from 1985 to March 2014", http://www.statista.com, Sep. 2015.

(10.) "IHS Automotive Light Vehicle Engine Forecast: Engine Production", IHS Database, Nov., 2014.

(11.) Escherich, R., Ledendecker, I., Schmal, C., Kuhls, B. et al., "SHE--Secure Hardware Extension--Functional Specification", Version 1.1, Hersteller Initiative Software (HIS) AK Security, Oct. 16, 2009.

(12.) Weyl, B.; Wolf, M.; Zweers, F.; Gendrullis, T. et al.; "Secure on-board architecture specification", EVITA Deliverable D3.2, Aug., 2011.

(13.) Mercedes-Benz, "Electrical and electronic components in passenger cars up to 3.5t--General requirements, test conditions and tests--Part 1: Electrical requirements", MBN LV 124-1, Rev. Oct. 2010.

(14.) Liebetrau, T., Kelling, U., Otter, T., Hell, M., "Energy Saving in Automotive E/E Architectures", Infineon White Paper, Dec., 2012.

(15.) Miller C., Valasek C., "Remote Exploitation of an Unaltered Passenger Vehicle", Black Hat, Aug., 2015.

(16.) "BMW Group Connected Drive erhoht Datensicherheit. Auf Hinweise des ADAC schnell reagiert.", BMW Group Press Release, Jan. 2015

CONTACT INFORMATION

Dipl.-Ing. Axel Freiwald Infineon Technologies AG Am Campeon 85579 Neubiberg, Germany axel.freiwald@infineon.com

M.Sc. Thomas Furtner Infineon Technologies AG Am Campeon 85579 Neubiberg, Germany thomas.furtner@infineon.com

Gunn Hwang Principal Engineer Infineon Technologies Korea Co Ltd 534 Teheran-ro, Gangnam-gu, Seoul, Korea 135-708 francis.hwang@infineon.com

DEFINITIONS/ABBREVIATIONS

AES - Advanced Encryption Standard

AUTOSAR - AUTomotive Open System ARchitecture

CAN - Controller Area Network

CMAC - Cipher-based Message Authentication Code

CPU - Central Processing Unit

CRC - Cyclic Redundancy Check

EBC - Electronic Brake Control

ECU - Electronic Control Unit

EVITA - See [12]

HASH - Result of a cryptographic hash function

HSM - Hardware Security Module

IP - Intellectual Property

MAC - Message Authentication Code

MCU - Micro Control Unit

OBD - On Board Diagnostic

OEM - Original Equipment Manufacturer

FOTA - Over The Air

SFBL - Secure FLASH Boot Loader

SHA - Secure Hash Algorithm

SHE - Secure Hardware Extension

SOTA - Software Over The Air

TCU - Telematics Control Unit

TPM - Trusted Platform Module

UDS - Unified Diagnostic Services

UMTS - Universal Mobile Telecommunications System

Axel Freiwald

Infineon Technologies AG Germany

Gunn Hwang

Infineon Technologies Korea Co., Ltd.

All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of SAE International.

Positions and opinions advanced in this paper are those of the author(s) and not necessarily those of SAE International. The author is solely responsible for the content of the paper.

doi:10.4271/2016-01-1948
Table 1. Examples for transferring 4MBytes via various bus types

Protocol           Realistic Transfer  Time for transfer
nominal data rate  Rate                of 4MBytes

CAN                16.8kbytes/s
500kbits/s         50% bus load        250s
CAN-FD             88.5kbytes/s         47.4s
2Mbits/s           50% bus load
FlexRay            300kbytes/s          13.6s
10Mbits/s          50% dynamic
                   segment usage
Ethernet 100baseT  5 to 10 Mbytes/s      0.8 s to 1.6s
100Mbits/s         (UCP or TCP/IP)
COPYRIGHT 2017 SAE International
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2017 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Author:Freiwald, Axel; Hwang, Gunn
Publication:SAE International Journal of Passenger Cars - Electronic and Electrical Systems
Article Type:Technical report
Date:May 1, 2017
Words:7573
Previous Article:Modeling on GPS with Software-Centered Observation Errors.
Next Article:Elicitation Practices That Can Decrease Vulnerability to Off-Nominal Behaviors: Lessons from using the Causal Component Model.
Topics:

Terms of use | Privacy policy | Copyright © 2019 Farlex, Inc. | Feedback | For webmasters