Sicherheitsaspekte für Flashing Over The Air in Fahrzeugen. Axel Freiwald 1/2017

Transcription

1 Sicherheitsaspekte für Flashing Over The Air in Fahrzeugen Axel Freiwald 1/2017

2 All OEMs Will Implement Software OTA As Soon As Possible IHS Study Motivation: Save on recalls caused by software bugs Evolution not Revolution: Implement into vehicle s network with as little changes as possible Wireless SOTA Revenue Cost Savings per Year Functional SOTA Update Revenue SOTA Royalty Revenue Challenges: Cyber Security Safety 2

3 Secure OTA Architecture A brief explanation Step 1: Download while driving Software download to central storage Unnoticed by the customer Vehicle shall be at any time safe and operational Auto Apps Software Update Security Updates Performance Upgrade Step 2: Update from central storage After customer approval In the background or at key-off Permissible update time (100s to 15min) Confirmation to Backend Safety and security must be ensured throughout the process 3

4 Evolutionary Software OTA Flow From Software Development to Vehicle Reboot Transport via Internet Service pack at OEMs update server Formatting for Update Handling Generate and release new Software version transport Over The Air Telematics unit TCU Receive and decrypt from secure wireless protocol Download service pack Check OEM authenticity Setup encryption services Service pack stored in vehicles central storage Verify data Unpack for ECUs Updating the vehicle i.e. using UDS Start UDS programming session Send service packs to ECUs in small blocks using UDS protocol (UDS, ISO :2013) Update inside ECUs: Secure Flash Bootloader and HSM Erase Flash Decrypt and unzip blocks (end to end protection) Write new code into Flash Update and verify signatures (HASH) Reboot the vehicle with new SW versions Exit update mode Restart all ECUs within the car 4

5 Secure Update: OTA vs OBD Equal Basics for both flows to update ECUs via OBD or OTA : Precondition: The new SW version must meet all legal requirements (Fahrzeugfreigabe). The service pack is distributed from the OEMs server via the internet. ECUs receive the commands and service packs via their bus interfaces i.e. in UDS format. Inside the ECUs the functions for updating software are handled by e.g. the Secure FLASH Bootloader Restrictions: o Not all code can get updated. i.e. the secure FLASH Bootloader itself is excluded. o For multiple ECU updates all updates must be successful. Partially updated vehicles are not allowed to drive. Differences OTA to OBD updates: With OBD updates the external diagnostic tool provides the update service. With OTA the update service must be implemented inside of the vehicle. OTA updates shall get started by drivers without technical background. Special safety measures apply to ensure that nobody gets harmed during and after the update. The update flow must be power fail prove. Long update times are more vulnerable for power fails. LAN Diagnostic Tool = UDS Update client OBD UDS ECU ECU UDS Onboard Diagnostic Service 5

6 SW OTA Comes Along With Security Threats Security Threats are Safety Threats Cloud connections are typically active all the time and thus OTA interfaces are potentially accessible for hackers. SW OTA services provide doors for attacks which might endanger the operation of vehicles. Typical examples: Functional changes, Tuning, Trojans Already the potential to attack vehicles is threatening Tier1s, OEMs and politicians. 6

7 Protection and Safety Interests for OEMs and Tier1s transport OEM targets: vehicle and server protection and safety responsibility Certified Signatures vehicle level: Secure Update Service Tier1 targets: ECU-IP protection and safety responsibility Encrypted SW Secure HASH ECU level: Secure Flash Boot Loader End to End Protection Required 7

8 Security is a global system requirement The whole process must be secured from all sides Keys and passwords must get especially protected Extra trust zones for key storage and key management: Vehicle: TPM and HSM OEM & Tier1: security server All parties involved with key handling are requested to have high security levels. OEMs and Tier1s challenge: production and service 8

9 SOTA Flow Security Elements From Infineon Service Authentication Mutual authentication between car and OEM update server Encrypted transport channel OPTIGA TPM Verification and Central Storage Service Pack reception 1 st verification Store in car s central memory HSM Update of Target ECU Service Pack reception 2 nd verification Flashing of code memory HSM 9

10 Firewall Trust Zone: Hardware Security Module (HSM) AURIX TC3xx: Full compliant TriCore0 TriCore1 Flash HSM 32-bit CPU Sec APP Security CPU Sec APP AES RNG ECC Sec RSA APP sec APP HSM SRAM 96kB Boot ROM Hardware Security Module (HSM) SRAM Peripherals Bridge Peripherals Peripherals AES 128 PKC ECC256 HASH SHA 2 TRNG Timer Trusted Execution Environment A highly flexible and programmable solution HW accelerator matching performance for automotive protocols: AES128 PKC ECC-256 SHA224/256 Crypto- and Algorithm Agility by Software AIS31 compliant 128bit True Random Number Generator (TRNG) with high Random Entropie over Lifetime 10

11 OPTIGA TPM Trusted Platform Module Temper proof design and architecture: CC EAL4+ certified Individual private key by hardware Unlimited number of asymmetric /symmetric keys Certified true random number generator TRNG: AIS31 TPM use case in vehicles: Main trusted anchor for the vehicle Asymmetric cryptography in authentication services Central generation, storage, and processing of individual keys for the vehicle including production and service Flexible Authorization mechanisms to protect against duplication/misuse OPTIGA TPM TPM use case in SOTA process: Mutual authentication of vehicle with OEMs servers Key generation (SHA) 11

12 Secure SW OTA Front End Security Elements and Formatting Step 5: Over The Air Update download is established by Provision of authentication and encryption services File of service pack is formatted and encrypted for wireless data transport Step 4: Service pack into update server OEM For updating multiple ECUs in one operation all individual UDS service packs of all effected ECUs are integrated to one package Service pack is signed with OEM signature Service pack is loaded into update server as one file SW update server signed service pack keys OTA security server signature OEM security server Step 3: UDS Formatting Individual service pack is wrapped to get handled by the protocol of the Unified Diagnostics Services (UDS, ISO :2013) individual service pack UDS formatted Step 2: Formatting for Secure Flash Bootloader zip encrypt sign with keys and signatures from Tier1 ECU specific individual service pack individual service pack keys signature Tier1 security server Step 1: Engineering New software version for ECU Verified and released TIER1 files from tools new SW 12

13 Paradigm Shift: Vehicles Get Attacked Every Day. The Task Is To Reduce The Damage Security risk mitigation: successful hacks must not endanger the whole fleet Individual keys for each vehicle - No fleet keys The number of persons who can see the keys shall go down to zero. Keys shall get generated and distributed automatically within a secure environment without personal interaction of people. Automatic key and password change Frequent change of keys: successful attacks do not get control for a long time Session keys for data transport Use of intermediate keys for production and service Transport keys Service keys 13

14 OTA Overview And Example For 4MB Updates Typical network topology (Background Slide) OBD Infotainment ETH Ethernet ca.16s for 4MByte 1) 50% Dynamic segment usage 2) ISO CAN FD, 64 Bytes data field, 2 MBaud, 50% bus load 3) Classical CAN, 8 Bytes data field, 500 kbaud, 50% bus load 4) Bandwidth depending on used protocol e.g. UCP or TCP/IP 5) AURIX TM, 65nm generation Telematics Unit e.g. TC29x Comfort CAN TC23x TC2xx CAN-FD Chassis Modem TPM Central Gateway FlexRay (or CAN) EPS e.g. TC23x ABS e.g. TC23x CAN ca.290s for 4MByte Central Storage FlexRay ca.30s for 4MByte Drive Train CAN-FD EMS e.g. TC27x TCU e.g. TC27x Cellular Update Roof Antenna CAN-FD ca. 66s for 4MByte 1. Bus-Transfer (4MByte) Usable Date Rate 1) FlexRay (10MBit/s): ca. 300 KByte/s ca. 13,6s 2) CAN-FD (2MBit/s): ca. 88,5 KByte/s ca. 47,4 s 3) CAN (500kBit/s) : ca. 16,8 KByte/s ca. 250s 4) Ethernet (100MBit/s): ca MByte/s ca. 1 s 2. Processing & Reprogramming inside ECU (4MByte) AES-128 Hash: ca. 0,16s and + Erase 5) : ca. 8s and + Programming: ca. 4s (5V burst mode) % communication overhead (e.g. for 8KByte block transfer) 14

15 Three topology proposals to minimizing the downtime of one ECU classic approach Downtime: Minutes (CAN), Secs (Ethernet) State of the art today No cost adder A/B swap Downtime: Seconds Products available today Medium to small cost adder update from local storage Downtime: None Products under evaluation, not available today High cost adder 15

16 Summary Software Over The Air impacts the overall car architecture Security is essential; on product and process level - Certified products such as TPM are best practice for securing critical external interfaces HSM is mandatory for Secure Flash Bootloader implementation Revolution of network topology is unlikely - Smooth SOTA migration path required - Key will be the customer acceptance of potential downtime - Solutions are available today without significant cost impact Infineon can support SOTA with AURIX TM and OPTIGA TM TPM 16

17