Hardware Security for Trustworthy C2X Applications Marko Wolf

Transcription

1 Hardware Security for Trustworthy C2X Applications Marko Wolf C2C-CC/CAMP Harmonization Workshop, Wolfsburg, Germany,

2 Outline 1. Three General Reasons for Automotive Hardware Security Modules (HSM) 2. Three Particular Reasons for Automotive Hardware Security Modules for Car-2-X Communications (C2X) 3. Status Quo for Availability of Automotive Hardware Security Modules 4. Trust Assurance and Evaluation Schemes for C2X Vehicle Stations using Hardware Security 5. Conclusions and Challenges Not public! Only for internal use. 2

3 1. Three General Reasons for Automotive HSMs

4 R #1: Software Security Vulnerabilities The future of digital systems is complexity, and complexity is the worst enemy of security. (Bruce Schneier) Because, complex software systems have more lines of code and therefore more security bugs have more interactions and therefore more security bugs are harder to test and therefore are more likely to have untested portions are harder to design securely, implement securely, configure securely and use securely Not public! Only for internal use. 4

5 R #1: Software Security Vulnerabilities Some real-world numbers ~ LOC software in modern premium cars 1) ~0.5 bugs per 1000 LOC for stable safety-related software 2) ~ potential software bugs per car ~1% of all software bugs are security vulnerabilities 3) ~500 potential software security vulnerabilities per car Hardware security can help to protect central security assets (e.g., identities, signing keys, encryption keys) against any software security vulnerabilities via physical shielding, which cannot be circumvented by any software (vulnerability). 1) Robert N. Charette: This Car Runs on Code. IEEE Spectrum, ) Linda Laird & Carol Brennan: "Software Measurement and Estimation: A Practical Approach.", Wiley & Sons, ) Cf. for instance for Mozilla JavaScript Engine (JSE), 2012 Not public! Only for internal use. 5

6 R#2: Hardware Vulnerabilities Hostile Automotive Security Environment Is a Specific POI! Physical (non-invasive, semi-invasive, invasive) attacks Disabling, manipulating of any (physical) inputs, outputs and processing Asset manipulations or read-outs via debug interfaces, fault attacks, sidechannels, micro probing, cutting etc. Offline attacks Attacker has virtually unlimited time Attacker has virtually unlimited trials Attacker and attack are hard to detect Insider attacks Attacker can be also legitimate owner with extended (physical) access rights Attacker can prevent emergency protection measures or security updates Attacker seldom fears non-technical protection measures (e.g., legal penalties) Hardware security can help to deter, detect, or hinder special powerful POI attackers. Not public! Only for internal use. 6

7 R#3: Performance Requirements & Cost Efficiency Security mechanisms are often computationally intense (e.g., millions of 1024 bit integer operations for one RSA operation), however, upgrading general purpose hardware is expensive, energy-consuming Physical protection is needed (cf. R#2), but physical protection of complete component is too expensive Hardware security can accelerate cryptographic mechanisms by applying HW accelerators Hardware reduces security costs by Adding some highly optimized special circuitry instead of costly overall upgrade of general purpose hardware Avoiding costly hardware-protection of complete ECU Not public! Only for internal use. 7

8 Automotive Hardware Security Automotive Hardware Security (Module) helps to: Shield security assets against SW vulnerabilities Deter, detect, and hinder (HW) POI vulnerabilities Accelerate computationally intense security Reduce security costs for performance requirements and physical protection Not public! Only for internal use. 8

9 2. Three Particular Reasons for Automotive HSMs for C2X

10 Three Particular Reasons for Automotive HSMs for C2X: C2X System Overview Additional C2X hardware connected to on-board networks for (sensor) data acquisition and for (actuator) data provision Additional C2X software for communication and applications Wireless (wide-range) external interfaces even with Internet access Not public! Only for internal use. 10

11 Three Particular Reasons for Automotive HSMs for C2X C2X #1: Strong computing performance & efficiency requirements for ECC-based C2X cryptography as required by IEEE and C2C-CC for efficient authenticity/integrity/conf. enforcement (e.g., secure boot) of C2X software, which is rather large for enabling efficient certificate management (e.g., 12 physically protected / enforced parallel certs/day vs. 300 logically protected certs/day to prevent Sybil attacks using multiple valid pseudonyms in parallel) Not public! Only for internal use. 11

12 Three Particular Reasons for Automotive HSMs for C2X C2X #2: Strong safety & dependability requirements Use cases may have strong safety implications while relying on lots of complex software (cf. R#1) and introducing long-range wireless interfaces in parallel relying on correctness and authenticity of incoming C2X messages Lack of misbehavior detection, misbehavior reporting, and misbehavior counteraction esp. in early deployment stages C2X definitely will be attacked while there is no period of grace! Even single easy to accomplish successful attacks could kill C2X immediately and long-lasting particularly in a safety-sensible world like automotive Not public! Only for internal use. 12

13 Three Particular Reasons for Automotive HSMs for C2X C2X #3: Strong legal & (re-)liability requirements for security & privacy Compare recent development in smart meter security as example (first implementations lacked on security &privacy CC certification becomes mandatory) Cf. legal privacy requirements, for instance, European directives 2010/40/EU (ITS framework), 95/46/EC (personal data processing), or 2001/58/EC (public electronic communication networks) Cf. legal liability requirements, for instance, European directives 2007/46/EC (vehicle approval framework), 2001/95/EC (product safety), or 85/374/EEC (consumer protection) And of course for legal safety requirements (cf. C2X#2) Not public! Only for internal use. 13

14 3. Status Quo for Availability of Automotive HSMs

15 Status Quo of Automotive HSMs: HIS Secure Hardware Extension (SHE) SHE Objective: Cost-efficient automotive-capable IC security extension for minimum of ECU security. Industry project finished in 2009 with official OEMcontrolled specification (i.e., HIS consortium) for semiconductor manufacturers Results Isolated AES-128 hardware engine and hardware protected cryptographic keys with access control (e.g., secure boot) Commercially available from Infineon, FreeScale, NEC etc. Outlook: Mandatory security extension for several German automotive OEMs Not public! Only for internal use. 15

16 Status Quo of Automotive HSMs: EVITA Hardware Security Modules Objective: Automotive-capable HSM for in-vehicle and V2X communication security and ECU software security EC funded research project (BMW, Bosch, Continental, ESCRYPT, Fujitsu, Infineon) finished in 2011 Results Outlook Open specification for three HSM classes light, medium, full Corresponding software security framework EMVY Vehicle-integrated FPGA prototypes incl. simtd vehicles EVITA Medium modules available soon EVITA Full prototype available Not public! Only for internal use. 16

17 4. Trust Assurance and Evaluation Schemes for C2X Vehicle Stations

18 How I can trust a C2X message? How can I trust* ) an incoming C2X message, in particular, for actively changing my driving behavior? Because it is difficult to sent you a faulty message. Why it is difficult to sent me a faulty message? Because C2X communication is well-protected against encroachments yielding to faulty messages by well-proven intl. accepted = trustworthy set of mechanisms / standards Because the C2X sending stations are well-protected, so that it is difficult to compromise them to send faulty messages. Are they? How? And how can I be sure? A trusted party has evaluated the sending endpoint acc. a well-proven intl. accepted = trusted security standard and issued a certificate you can verify about its opinion how difficult it is to compromise this sender. * ) Classical IT security definition: One (trustor) relies on another (trustee) to act as expected. Not public! Only for internal use. 18

19 Trustworthiness of C2X (sending) stations Why? How? For being able to put trust into others C2X messages. Trusted security evaluation and securely verifiable certification according to an accepted = trustworthy evaluation standard. Same (minimum) trust evaluation criteria for all? Could be (difficult), but better use different trust assurance evaluation criteria = different assurance trust levels for different C2X applications depending on their individual minimum trust requirements. How could such trust assurance levels (TAL) look like? Not public! Only for internal use. 19

20 Trust Assurance Levels (TAL) for C2X stations Trust Ass. Level (TAL) Minimum Target of Evaluation (TOE) Minimum Evaluation Assurance Level (EAL) (Hardware) Security Functionality Prevented Attacker acc. to CC Security Implications C2X Use Case Examples 0 None None None None Not reliable against security attacks in general Some limited,e.g. using trusted C2I infrastructures 1 + C2X box software EAL 3 Only software security mechanisms Minimum Level Basic Not reliable against simple hardware attacks (e.g., offline flash manipulation) Non-safety, but most privacy relevant use cases 2 + C2X box (sec.) hardware EAL 4 + dedicated hardware security (i.e., secure memory & processing) + tamper evidence Enhanced Basic Not reliable against more sophisticated hardware attacks (e.g., side-channel attacks) C2C-CC day one use cases (e.g., passive warnings and helpers) 3 + tamper-protected (sec.) hardware EAL 4+ (AVA_VAN.4 vulnerability resistance) + basic tamper resistance Moderate C2X box secure as stand alone device, but without trustworthy invehicle inputs Safety relevant relying not only on V2X inputs 4 + relevant in-vehicle sensors and ECUs EAL 4+ (AVA_VAN.5 vulnerability resistance) + moderate high tamper resistance Moderate High C2X box is trustworthy also regarding all relevant in-vehicle inputs All Not public! Only for internal use. 20

21 Evaluation & Certification of Trust Levels Remember: A trusted party has evaluated the sending endpoint acc. a well-proven intl. accepted = trusted security standard and issued a certificate you can verify about its opinion how difficult it is to compromise this sender. Possibilities for trusted evaluation parties Public security evaluation institution such as BSI, NIST etc. OEM-accredited evaluation labs Self-certification, of course with some inherent trust limitations Possibilities for trusted security evaluation standards Generic NIST FIPS (2001) and draft (2013?) Generic ISO Common Criteria Version 3.1 (ISO 15408, 2007) Custom scheme such as successful EMVCo approach from payment card industry by international OEM consortium Not public! Only for internal use. 21

22 Security Evaluation Standards Benchmark NIST FIPS 140-X Well-proven approach with 4 predefined levels, but not truly a security standard, rather correct use of cryptography and security functionality Not truly international standard, but very US-driven (i.e., needs regional or customer individual re-certifications) Difficult and slow to adapt (cf. >10 years for FIPS 140-3) ISO Common Criteria 3.1 State-of-the-art, well-proven, internationally accepted standard Necessary infrastructure (e.g., labs, certification bodies) already available Costly, timely, but with limited durability (2 years) only Rather generic, while difficult and slow to adapt Not public! Only for internal use. 22

23 Security Evaluation Standards Benchmark CC adapted custom OEM C2X evaluation scheme Reuse CC approach with more efficient and more specific C2X adaptions Can be easily extended, adapted etc. since it would be under full control of OEM consortium Not yet existing anything, i.e., no standards, no labs, no consortium or overall accepted agreement Costly and timely establishment & maintenance of corresponding infrastructure Even though the initialization costs and time are considerable, in the long run, the custom CC adapted approach will be the most efficient & flexible approach. Not public! Only for internal use. 23

24 5. Conclusions & Challenges

25 Conclusions Hardware security is essential for automotive security Hardware security is essential especially for C2X Four pre-defined trust assurance levels (TAL) for origin of incoming C2X messages based on a well-proven intl. accepted = trusted security evaluation standard Not public! Only for internal use. 25

26 Challenges Fully C2X-capable hardware security modules not yet commercially available C2X (hardware) security (evaluation) standards have to be created, widely accepted, and reliably implemented (e.g., strongly connected w/ PKI solution) Security cannot be measured absolutely nor it s static, but a moving target. So the best result that can be expected from a security evaluation is: from today s perspective no exploitable vulnerabilities were found Not public! Only for internal use. 26

27 Thank you for your attention! Dr.-Ing. Marko Wolf Senior Security Engineer Not public! Only for internal use. 27