Safety and security related features in AUTOSAR

Transcription

1 Safety and security related features in Dr. Stefan Bunzel Spokesperson (Continental) Co-Authors: S. Fürst, Dr. J. Wagenhuber (BMW), Dr. F. Stappert (Continental) Automotive - Safety & Security June, 2010, Stuttgart

2 Overview Background of safety and security in automotive E/E development Overview software architecture Safety related features Security related features 2 Safety and security related features in

3 Safety and Security in Automotive E/E Development Functional Safety Security E/E System Reliability Safety: With the trend of increasing complexity, software content and mechatronic implementation, there are increasing risks from systematic failures and random hardware failures. (ISO DIS Road vehicles Functional safety) Security: means protecting a system and its information and data from unauthorized access, use, disclosure, disruption, modification or destruction 3 Safety and security related features in

4 Functional Safety in Automotive E/E Development IEC Functional safety of electrical/electronic/ programmable electronic safety-related systems, 1998 Generic standard Adaptation to E/E systems in road-vehicles ISO DIS Road vehicles Functional safety, 2009 ISO 26262: provides an automotive safety lifecycle (management, development, production, operation, service, decommissioning) and supports tailoring the necessary activities during these lifecycle phases; provides an automotive specific risk-based approach for determining risk classes (Automotive Safety Integrity Levels, ASILs); uses ASILs for specifying the item's necessary safety requirements for achieving an acceptable residual risk; and provides requirements for validation and confirmation measures to ensure a sufficient and acceptable level of safety being achieved. 4 Safety and security related features in

5 Why Security in Automotive E/E Development? Political and Social Issues esafety Initiative EU esecurity Workgroup Product Liability Thatcham Legal regulations requiring additional security measures in vehicles (Regulation EC 692/2008) EU 5 / EU 6 Political and administrative workgroups realize the dependency between safety ( Betriebssicherheit ) and security ( IT Sicherheit ) resulting in new legal requirements regarding security in the automotive domain 5 Safety and security related features in

7 Vision aims to improve complexity management of integrated E/E architectures through increased reuse and exchangeability of SW modules between OEMs and suppliers. OEM b OEM a Platform b.1 Platform b.2 Platform b.n Exchangeability between suppliers OEM c solutions Platform a.1 Platform a.2 Platform a.n Exchangeability between manufacturers applications OEM f Platform f.1 Platform f.2 Platform f.n Supplier A Chassis Safety Body/ Comfort OEM e Supplier C Platform e.1 Platform e.2 Platform e.n Supplier B Chassis Safety Telematics Body/Comfort Powertrain Telematics Platform c.1 Platform c.2 Platform c.n OEM d Platform d.1 Platform d.2 Platform d.n Exchangeability between vehicle platforms 7 Safety and security related features in

8 Vision aims to standardize the software architecture of ECUs. paves the way for innovative electronic systems that further improve performance, safety and environmental friendliness. Yesterday Hardware Application Hardware standardized HW-specific Customer needs Adaptive Cruise Control Lane Departure Warning Advanced Front Lighting System.. Using standards Communication Stack OSEK Diagnostics CAN, FlexRay Hardware and software will be widely independent of each other. Development can be de-coupled by horizontal layers. This reduces development time and costs. The reuse of software increases at OEM as well as at suppliers. This enhances quality and efficiency. 8 Safety and security related features in

9 Core Partners and Members Status: May 6, Core Partner 11 Development Members 39 Premium Member 57 Associate Members 5 Attendees General OEM Generic Tier 1 Standard Tools and Services Semiconductors Up-to-date status see: 9 Safety and security related features in

10 9 Project Objectives and 3 Main Working Topics PO1: Implementation and standardization of basic system functions as an OEM wide Standard Core solution PO2: Scalability to different vehicle and platform variants PO3: Transferability of functions throughout network PO4: Integration of functional modules from multiple suppliers Application s Architecture Methodology PO5: Maintainability throughout the whole Product Life Cycle PO6: Increased use of Commercial off the shelf hardware PO7: updates and upgrades over vehicle lifetime PO8: Consideration of availability and safety requirements PO9: Redundancy activation 10 Safety and security related features in

11 Specifications vs. Products Core Partners, Premium, and Development Members Develop compliant products SW modules Tools ECUs Cars Members Partnership Cooperate on standards, compete on implementations. Standard Specifications Architecture Methodology Appl. s Releases R4.0, R3.1, R3.0, Build Apply 11 Core Partners, Premium, Development, and Associate Members Safety and security related features in

12 Architecture Overview of Layers Top View The Architecture distinguishes on the highest abstraction level between three software layers running on a microcontroller. The Application Layer The Run Time Environment (RTE) Basic (BSW) Application Layer RTE Basic (BSW) Microcontroller 12 Safety and security related features in

13 Basic Coarse View and Detailed View The Basic consists of the layers: Services, ECU, Microcontroller and Complex Drivers. The BSW layers are further divided into functional groups. Examples of Services are System Memory Communication Services Application Layer Application Layer RTE RTE Services Layer System Services Memory Services Communication Services I/O Hardware ECU Layer ECU Layer Microcontroller Layer Complex Drivers Onboard Device Microcontroller Drivers Memory Hardware Memory Drivers Communication Hardware Communication Drivers I/O Drivers Complex Drivers Microcontroller Microcontroller 13 Safety and security related features in

14 Architecture Layered Architecture Application Layer Breakdown to / Implementation on ECU Runtime Environment (RTE) Services Layer ECU Layer Microcontroller Layer Hardware Complex Drivers Application Component ECU Architecture Actuator Component Sensor Componen t... Application Componen t Runtime Environment Operating System Services Basic Communication ECU Microcontr. Complex Device Drivers ECU-Hardware 14 Safety and security related features in

15 Development Methodology Principle ECU I SWC 1 SWC Description SWC 1 RTE Basic SWC 2 SWC 3... Virtual Functional Bus ECU Description SWC 3 SWC Description ECU II SWC Description ECU Description SWC 2 RTE Basic... SWC Description SWC n ECU m SWC n ECU Description RTE Basic description templates: SWC description: application software ECU description: ECU characteristics and configuration System description: network and assignment of SWCs to ECUs Descriptions for SWCs + ECUs + system description allow a tool-based deployment of SWCs to ECUs FlexRay Gateway CAN System Description 15 Safety and security related features in

17 methodology according to ISO26262 Functional Safety Concept 3-8 Specification of Technical Safety Requirements 4-6 SYSTEM Specification of SW Safety Requirements 6-6 SW architectural design Safety and security related features in

18 methodology according to ISO26262 Functional Safety Concept 3-8 Specification of Technical Safety Requirements 4-6 SYSTEM Supports safety by offering standard safety mechanisms Core Tests, Flash tests E2E protection Memory partitioning Specification of SW Safety Requirements REQ 6-6 architectural design 6-7 SW REQ SPECIFICATIONS REQ REQ Requirements (SRS) REQ REQ Specifications (SWS) REQ Some safety requirements in ISO26262 part6 are related to SW implementation BSWs BSWs Config SW-Cs Safety related CDDs SW implementation 18 Safety and security related features in

19 Safety Features Memory partitioning: separate software applications from each other in order to avoid any data corruption between applications Defensive behavior: prevent data corruption and wrong service calls in the basic software on microcontrollers having no hardware support for memory partitioning. End-to-end communication protection: protect applications against the effects of faults within the communication link Program flow monitoring: control the temporal and logical behavior of applications Time determinism and timing constraints modeling: model and implement proper and deterministic timing behavior synchronized time bases (i.e. a global time ) across ECU networks, synchronized execution and deterministic timing of application software components controlling the timing behavior and detection of timing violations at runtime timing constraints like end-to-end (e.g. sensor-to-actuator or communication) delays, minimum/ maximum execution times of runnable entities, or constraints on the triggering rate of events. Hardware testing and checking: basic software modules to test hardware (e.g. RAM-Test, Core-Test) and to check the integrity of stored data (e.g. EEPROM Manager) 19 Safety and security related features in

20 Release 4.0 Partitioning Partitions are used as fault containment regions Partitions can be terminated or restarted during run-time as a result of a detected error Partitions are configured in the ECU-C Partition 0 (No ASIL) Partition 1 (ASIL A) Partition 4 (ASIL D) Application Component Operating System Actuator Component Basic Sensor Component... Application Component Runtime Environment (RTE) with build-in protection layer Services Communication Partition 5 (ASIL D) ECU Microcontroller Complex Device Drivers ECU-Hardware 20 Safety and security related features in

21 Release 4.0 Example for Partitioning 1. A violation (error) has occurred in the system (e.g., memory or timing violation) 2. The partition is terminated by the OS, cleanup possible communication is stopped 3. The partition is restarting, initial environment for partition set up 4. The partition is restarted and up and running Partition 0 (No ASIL) Partition 1 (ASIL A) Partition 4 (ASIL D) Application Component Operating System Actuator Component Services Basic Sensor Component Stop ECU-Hardware... Application Component Runtime Environment (RTE) with build-in protection layer Communication Partition 5 (ASIL D) ECU Microcontroller Complex Device Drivers 21 Safety and security related features in

22 Release 4.0 Safety End to End (E2E) Communication Protection Libraries OS-Application 2 Receiver 1 OS-Application 1 Sender System Services SW IOC HW Runtime Environment (RTE) Memory Services Communication Services SW SW I/O Hardware CDD Typical sources of interferences causing errors Detected by E2E protection SW-related sources Onboard Device Memory Hardware Communication Hardware SW HW-related sources Microcontroller Drivers Memory Drivers Communication Drivers I/O Drivers HW HW Microcontroller 1 / ECU 1 Microcontroller 2 / ECU 2 22 Safety and security related features in

23 Release 4.0 Safety End to End (E2E) Communication Protection Libraries Direct function calls E2E Lib System Services SW OS-Application 2 Receiver 1 E2E protection wrapper IOC Onboard Device Microcontroller Drivers HW Runtime Environment (RTE) Memory Services Memory Hardware Memory Drivers Communication Services SW Communication Hardware Communication Drivers OS-Application 1 Sender E2E protection wrapper I/O Hardware SW SW I/O Drivers CDD HW RTE wrapper HW Typical sources of interferences causing errors Detected by E2E protection SW-related sources HW-related sources Microcontroller 1 / ECU 1 Microcontroller 2 / ECU 2 23 Safety and security related features in

25 Security Use Case Examples Secure Programming of ECUs Programming only by authorized entities Programming only with original OEM approved software Application (in bootloader) uses standard cryptographic routines and services, e.g. hash, signature verification, and public key encryption (= asymmetric encryption) Electronic Immobilizer Protect the vehicle from any unauthorized driving Technical details are totally OEM dependent But: Immobilizer application always uses a specific set of cryptographic routines and services Electronic enabling of functions Only a specific subset shall be enabled for regular usage of the car Uses special data structures with cryptographic signature Secure diagnosis Only dedicated entities are allowed to use certain diagnostic services 25 Safety and security related features in

26 Security and Cryptographic Architecture Security Use Cases and corresponding security applications Each main security use case corresponds to a security application Secure Flashing Authentication & Signature Function Enabling SWC My Use Case myapp MD5 xxx-mac RSA MD5 RSA DES DH SHA-1 HMAC RSA AES basic cryptographic routines Each security application uses a different set of cryptographic services Communality of cryptographic routines may lead to slightly different crypto implementations or to duplicated code 26 Safety and security related features in

27 Security and Cryptographic Architecture Security Use Cases and corresponding security applications Separation of security application and cryptographic routines Secure Flashing Authentication & Signature Function Enabling SWC Crypto Module MD5 SHA-1 SHA-256 ECC RSA AES DES DH Crypto Module manages requests for cryptographic services from applications and dispatches to a pool of cryptographic basic routines Standard generic interface from above for applications Standard generic interface from below for basis routines (cryptographic services as plugins) Management of internal states Transparent access to crypto hardware devices 27 Safety and security related features in

28 Security and Cryptographic Architecture Security Use Cases and corresponding security applications Crypto Module exposes an interface for security applications to allow for a generic access to standardized cryptographic routines Secure Flashing Authentication & Signature Function Enabling SWC Generic Crypto Access Crypto Module Generic Crypto Plug-In MD5 SHA-1 SHA-256 ECC RSA AES DES DH Crypto Module exposes an interface for cryptographic routines to allow for arbitrary implementations to plug-in into crypto module and for use by security applications Cryptographic routines may be offered by different vendors each specified for certain technologies (RSA, ECC, ) Security application is not aware of special realization of crypto routine Crypto routine may be realized even in hardware without notice of application 28 Safety and security related features in

29 Security in Embedding of Crypto Module Appl. 1 Appl. 2 Application Layer Crypto service manager (CSM) in system services of service layer Driver (HW) * Runtime Environment (RTE) CSM Basic Crypto Routines (SW) Services Layer System Services configurable and common access to cryptographic methods Microcontroller Crypto Service Manager ECU Layer SPI- Driver Microcontroller Layer Optional (*): Support for cryptographic hardware Crypto HW * 29 Safety and security related features in

30 Summary has become a global standard for embedded automotive software, providing specifications for architecture Development methodology application interfaces Already former releases (R2.1, R3.0, R3.1) can be used for safety related systems. With the R4.0 and further releases safety related systems are more and more supported. Security in enables the use of state-of-the-art cryptography in the automotive domain with standardized interfaces is a key enabler for managing the growing E/E complexity First series cars with technology are on the road 30 Safety and security related features in

31 Thank you for your attention! Become a member and get exploitation rights for the standard. Published Releases For information only, see disclaimer. 31 Safety and security related features in