Embedding Trust into Cars Secure Software Delivery and Installation

Transcription

1 Embedding Trust into Cars Secure Software Delivery and Installation André Adelsbach, Ulrich Huber, Ahmad-Reza Sadeghi, Christian Stüble Horst Görtz Institute for IT Security, Bochum, Germany Third Workshop on Embedded Security in Cars (escar 2005) Cologne, November 29, 2005

2 AGENDA System model and assumptions Design options for a security architecture Fulfillment of functional requirements Compatibility assessment Rights Enforcement Determination of installation target 1

3 AGENDA System model and assumptions Design options for a security architecture Fulfillment of functional requirements Compatibility assessment Rights Enforcement Determination of installation target 2

4 The system model contains five different roles which correspond to the current players in the automotive industry ROLES IN THE SYSTEM MODEL AND THEIR COUNTERPARTS IN THE AUTOMOTIVE INDUSTRY Non-trusted Trusted OEM* Develops and assembles the vehicle in cooperation with his suppliers Examples: car manufacturers such as Daimler Chrysler, GM, Toyota, etc. Maintenance service provider (MSP) Maintains the vehicle via HW* repair/replacement and SW installation using specific equipment Examples: car dealers, garages, road service teams, etc. Vehicle Vehicle Owner/User Owns/uses the vehicle which contains several HW components whose SW can be updated Examples: you and me Maintenance SW Licenses Software application programmer (SAP) Develops and distributes SW* components for the vehicle to be installed at and after assembly time Examples: suppliers such as Bosch, Delphi, Denso, Siemens, Visteon, etc. Additional role: trusted third party (TTP) License provider (LP) Generates licenses for SW components of the SAPs and distributes them to vehicle owners via the MSPs Examples: not existing, but might be assumed by joint ventures of OEMs and/or SAPs * OEM: overall equipment manufacturer, SW: software, HW: hardware 3

5 Each role in the system model has specific requirements regarding software installation REQUIREMENTS OF ALL ROLES IN THE SYSTEM MODEL Straightforward Advanced OEM Correctness Compatibility enforcement MSP clearance enforcement Integrity Maintenance service provider (MSP) Correctness Non-repudiation MSP clearance enforcement Non-discrimination Frame-proofness Vehicle Owner/User Correctness Non-repudiation Authenticity Software application programmer (SAP) All OEM requirements Rights enforcement Confidentiality Non-discrimination License provider (LP) Correctness Non-repudiation 4

6 There is an exemplary SW installation protocol that consists of four basic steps FOUR STEPS OF AN EXEMPLARY SW INSTALLATION V* MSP* 1 SW request: SWReq(k,m,r n ) σ req 2 SW delivery: SWDel(s enc, γ lic ) 3 Installation ExtInstConf(γ lic, ind) confirmation: σ inst σ conf SW delivered to vehicle 4 Acknowledgment of confirmation: σ ack ConfAck (σ conf ) Based on asymmetric cryptography * V: Vehicle, MSP: Maintenance Service Provider Source: Technical Report "Secure Software Delivery and Installation in Embedded Systems", 5

7 AGENDA System model and assumptions Design options for a security architecture Fulfillment of functional requirements Compatibility assessment Rights Enforcement Determination of installation target 6

8 We propose to enhance the existing vehicle electronics architecture with a trusted component v 0 and individual secrets shared between v 0 and the other components ENHANCEMENT OF THE EXISTING VEHICLE ELECTRONICS ARCHITECTURE WITH A TRUSTED COMPUTING BASE Non-trusted Trusted Existing vehicle architecture Adding a trusted computing base V V I/O v 0 I/O v 1 v 2 v n v 1 v 2 v n Diagnostic tester performs SW delivery and installation directly over the internal communication network* No or low tamper resistance of ECUs** Adversary can install SW** in any ECU Diagnostic tester connects to a trusted component v 0 that uses tamper-resistant hardware v 0 shares an individual secret with each ECU to secure internal communication Trust assumption on v i may depend on the value of its software * The internal communication network consists of data busses such as CAN, LIN and MOST. ** ECU: Electronic Control Unit, SW: software v 0 authenticates every flash process 7

9 An additional trusted component eases the workload of regular components and fits better with the trust model, but induces additional costs and modifications PROS AND CONS OF AN ADDITIONAL TRUSTED COMPONENT Pros Computationally demanding subroutines of delivery protocol reside in trusted component instead of in each component, e.g., asymmetric cryptography Trusted component stores the vehicle s identity, avoiding a secret shared between all components, e.g., a signature key Vehicle owner doesn t have to trust the diagnostic tester, e.g., with respect to generation of signatures on behalf of the owner Cons Additional costs for hardware in each vehicle and development of the trusted component s software Trusted component does not strengthen any of the weaker components Modification of all ECUs* is still necessary in order to embed and protect the shared secret * ECU: electronic control unit 8

10 For construction of the trusted component, we assume four hardware and software components to be available: tamper-resistant hardware, a secure operating system, insecure mass memory, and a trustworthy module ASSUMPTIONS ON AVAILABLE HARDWARE AND SOFTWARE COMPONENTS FOR BUILDING THE TRUSTED COMPONENT 1 Tamper-resistant hardware 2 Secure operating system (OS) Central processing unit (CPU), memory and communication channels between them are tamper-resistant Memory components have high cost per byte of memory due to protection measures OS provides a protected environment for applications Isolation of processes Monitoring of boot process May be based on microkernel architectures, e.g., PERSEUS 3 Insecure mass memory 4 Trustworthy module (TM) Memory components with high storage capacity, e.g., random access memory (RAM) or hard disk Memory components have low cost per byte of memory due to lack of protection measures Provides security functionalities to be used by the secure OS Attestation (Assessment of the current configuration of v i ) Sealing (Binding of cryptographic secrets to a specific configuration) Example: Trusted Platform Module* * For details, see specification of the Trusted Computing Group at 9

11 We show three exemplary architectures for the trusted component that differ in their trust assumptions, complexity and flexibility QUICK OVERVIEW OF THREE POSSIBLE ARCHITECTURES FOR THE TRUSTED COMPONENT EXAMPLES Non-trusted Trusted Independent component Integrated component using secure memory Integrated component with insecure memory v 0 s 0 s 1 s m s 0 s 1 s m Memory OS CPU Memory OS CPU Mass memory TM Pros and cons Neither secure OS nor TM needed High cost per byte of memory Cost of the CPU attributable only to v 0 Pros and cons Cost of CPU shared with other SW components High cost per byte of memory Needs a secure OS Pros and cons Low cost per byte of memory due to small tamper-resistant memory Flexibility, e.g., for OS updates (open system) Needs secure OS and TM 10

12 The independent component derives its security from its complete tamper resistance and the closedness of the system, which may lead to an unfavorable cost structure SECURITY OF INDEPENDENT COMPONENT THROUGH TAMPER RESISTANCE AND CLOSEDNESS Design guidelines CPU and memory need to be tamper-resistant Tampering with ECU may additionally be complicated by using a strong mechanical casing and seal HW and SW need to be certified by a trusted third party; only this party may flash v 0, and only partially* Discussion Typical example of a closed system: Corresponds to trust assumptions on consumer electronics devices such as pay TV decoders Only v 0 uses the HW, whose cost is therefore attributable only to v 0 No use of inexpensive mass memory, therefore high cost per byte of memory * For example, the TTP might sign an update of v 0. Then v 0 updates itself (partially) after signature verification. 11

13 The integrated component using secure memory derives its security from its physical tamper resistance and the closedness of the trusted computing base, including a secure OS SECURITY OF INTEGRATED COMPONENT THROUGH TAMPER RESISTANCE AND ISOLATION Non-trusted Trusted s 0 s 1 s m Memory OS CPU Existing multimedia or dashboard ECU as candidate for integration of s 0 Design guidelines (additional to previous) Additional SW components s i may be installed in the same HW Secure OS needs to provide isolation to protect s 0 from other s i Only the TCB* needs to be certified by a trusted third party, which alone may perform updates of this TCB Discussion TCB still a closed system: Corresponds to trust assumptions on a pay TV decoder that allows SW installation, but no OS updates HW cost is attributable to s 0 and the other s i, which leads to (relative) cost reduction Still no use of inexpensive mass memory, therefore high cost per byte of memory * TCB: Trusted computing base, includes s 0, OS, memory and CPU 12

14 The integrated component with insecure mass memory derives its security from the physical tamper resistance of the trusted HW components and sealing of all secrets with a trustworthy configuration of the trusted computing base SECURITY OF INTEGRATED COMPONENT THROUGH TAMPER RESISTANCE, ISOLATION AND SEALING Non-trusted Trusted s 0 s 1 s m Memory OS CPU Mass memory TM Existing multimedia or dashboard ECU as candidate for integration of s 0 Design guidelines (additional to previous) After encryption*, program code and application data may be stored in insecure mass memory; after reading from mass memory, integrity needs to be verified Again, the TCB** needs to be certified and exclusively updated by a trusted third party Security-critical data needs to be sealed with a valid configuration of the TCB Discussion TCB is now an open system: Corresponds to trust assumptions on a desktop PC with a TPM HW cost is attributable to s 0 and the other s i, which leads to (relative) cost reduction Use of inexpensive mass memory, therefore low cost per byte of memory * For acceptable performance, encryption may need to be implemented in hardware, e.g., using AES. ** TCB: Trusted computing base, includes s 0, OS, memory, CPU and TM 13

15 AGENDA System model and assumptions Design options for a security architecture Fulfillment of functional requirements Compatibility assessment Rights Enforcement Determination of installation target 14

16 In addition to security requirements, the trusted component would enable fulfillment of functional requirements such as compatibility assessment, rights enforcement and determination of the installation target EFFICIENT FULFILLMENT OF ADDITIONAL REQUIREMENTS USING THE TRUSTED COMPONENT v 0 Covered in previous sections Topic of this section Cryptographic functionality Security requirements Secure storage Verifiable boot Requirements on v 0 Isolated execution Compatibility assessment Functional requirements Rights enforcement Determination of installation target 15

17 As an alternative to current compatibility assessment that is based on vehicle software configurations and MSP* decisions, the trusted component could assess compatibility based on standardized properties COMPATIBILITY ASSESSMENT: ALTERNATIVE APPROACH USING PROPERTIES MAINTAINED BY THE TRUSTED COMPONENT From MSP* decisions based on the vehicle s SW* configuration Allowed configurations list to decisions by the trusted component based on properties SW property sheet Fjord Siesta 09/ /2004 Diesel, left-hand drive Gasoline, automatic transmission Haves Adaptive Cruise control Needs Speed control Brake control For each SW component to be installed, the MSP decides compatibility based on allowed SW configurations, derived from Vehicle model Production date Engine, etc. Assessment is a lookup in a compatibility table, which can easily grow large and may become outdated Trusted component v 0 maintains a list of properties (or functionalities) of each SW component, e.g., controllability of engine speed, measurability of distances Each new SW component comes with a list of haves and needs Compatibility is given if and only if the SW component provides the haves of its prior version and finds the needs * MSP: maintenance service provider, SW: software 16

18 Given a trusted component v 0, computationally demanding subroutines of the license delivery protocol might move from the individual components to v 0 RIGHTS ENFORCEMENT: REDUCED WORKLOAD ON REGULAR COMPONENTS DUE TO TRUSTED COMPONENT From direct license delivery to delivery of simple parameters LP* license receipt v i license LP v 0 v i receipt parameters acknowledgement asymmetric crypto asymmetric crypto shared secret LP directly delivers the license to the ECU that executes the SW To fulfill the non-repudiation requirement, an implementation is likely to involve asymmetric cryptography** All ECUs need to be capable of executing the protocol LP delivers the license to the trusted component v 0, SW* is parameterized v 0 translates the terms and conditions into simple parameters and authenticates them with the shared secret** Performance requirements on the components v i decrease * LP: license provider, SW: software ** For example, authentication may be achieved with symmetric message authentication codes (MACs). 17

19 With the announcement of an industry-wide standard for an electronics architecture, the trusted component may help to determine the target ECU of a SW installation at runtime based on the vehicle s configuration DETERMINATION OF INSTALLATION TARGET: VEHICLE CONFIGURATION MAINTAINED BY THE TRUSTED COMPONENT Current situation AUTOSAR** standards Proposed solution with v 0 SW requirements SW* ECU* Memory req. Location req. Proximity req. For each SW and vehicle, there is only one target ECU for installation Neither at production time nor during the lifecycle, SW functionality can move from one ECU to another Industry-wide standards for vehicle electronics architecture RTE* provides abstraction from SW versions and specification of interfaces Target ECU may depend on available memory, location, etc. Trusted component v 0 stores current vehicle configuration Free flash memory per ECU Physical location of ECUs Mapping functionalities ECUs At SW installation time, v 0 determines optimum target ECU based on SW requirements and vehicle configuration * SW: software, ECU: electronic control unit, RTE: run-time environment ** AUTOSAR: Automotive Open System Architecture, URL 18

20 CONTACT TO THE AUTHORS Ulrich Huber Ahmad-Reza Sadeghi Horst Görtz Institute for IT Security Ruhr Universität Bochum Universitätsstraße Bochum GERMANY Website: 19