Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Hardware Security: Increased Security Driving Hardware Requirements


Published on

Visteon presented at TU-Automotive Detroit in Novi, Michigan, on June 7, 2018.

Published in: Automotive
  • Be the first to comment

Hardware Security: Increased Security Driving Hardware Requirements

  1. 1. Hardware Security: Increased Security Driving Hardware Requirements June 7th, 2018 Jorge Shimabukuro
  2. 2. An Automotive Technology Company on the Move • A top-five Tier 1 connected car supplier* • Largest supplier focused exclusively on cockpit electronics • Leading the transition of digital cockpits to autonomous driving 2
  3. 3. Industry-Leading Cockpit Electronics Product Portfolio Only pure-play in automotive cockpit electronics Source: Rankings from 2016 ABI Research and IHS Markit. Instrument clusters Head-up displays Infotainment Displays Self-drivingConnectivityCockpit computer Visteon Market Position Top 5 Connected car Tier 1 supplier 3
  4. 4. Cockpit Technology Trends 4 20102005 2015 2020 2025 ECU Consolidation Connected Car HMI for Level 3 Autonomous Digital Cockpit
  5. 5. ECU Consolidation in Automotive Electronics Complex network of Inter-dependent ECUs Yesterday ECUs in car 30 - 100+ Consolidation of ECUs into domain controllers Less ECUS but more Interfaces Cockpit Controller Today Tomorrow Cockpit Controller ADAS/AD Controller 5
  6. 6. Domain Controller Chicago Overall Security Architecture Secure Architecture Driving Hardware Security Requirements Cluster File System HMI HMI Applications File Systems & Tools Operating System Hardware Domain Management Layer Hypervisor Vehicle Interface S e c u r e O S 6 AUTOSAR File System Apps IVI External Network OTA Internal Vehicle Network ECU ECU ECU ODB2 S e c u r i t y
  7. 7. Hardware Requirements • External Network Services (Telematics, Back End, OTA, Apps) • Internal Vehicle Network must meet both performance and security requirements • Individual ECU/Domain controller security needs driving Hardware requirements 7 Security Solutions Must Work Together At All Layers Down to Hardware Domain Controller Processor(s) Secure Boot, Hardware Security Modules, Secure Hardware Extensions, Cryptographic HW, Debug/JTAG protection, OTP Security Protection, Secure Storage, Secure OS, Vehicle interface Secure Hardware Extensions Memory Security Peripherals/Sensors/Actuators Network Interfaces
  8. 8. Authenticity - Integrity Domain Controller Secure Boot 8 Secure Boot Trusted Chain with Hardware as Root of Trust System Apps APP Hypervisor Boot Loader Secure Boot Chain Runtime Kernel • Various methods for ensuring firmware / software authenticity can be used at each step. • Processor(s) can achieve verification when combining hardware cryptographic verification support for algorithms such as RSA, ECDSA, CMAC and secure key storage. • Root of Trust: FUSE / OTP Security Protection. Sets enforcement of security features and allows binding of verification keys to HW.
  9. 9. HSM / SHE - Security Cryptographic HW and SW Support Cryptographic algorithms must have HW acceleration support to reduce system impact • Typical cryptographic algorithms required: • Encryption/decryption (AES-various) • Asymmetric signature generation/verification (RSA, ECDSA). • CMAC generation/verification - AES-128 as specified by [NIST800_38B]. • Secure Key management considerations require hardware backed operations • Symmetric Keys must be able to be received from external source (Vehicle Network dependencies) • Ensure Runtime and HLOS support required drivers and functions • Secure Key handling such that symmetric keys are not in plain memory in HLOS 9 Cryptographic Support At HW Level must also integrate with Operating System
  10. 10. Secure Storage: Storing Security Data Data stored in Flash protected by HW backed encryption OS microcontroller File System OS Crypto Driver/Service Secure Storage Files : Storage [Device Keys] Data 3 [AES-Encryption] 2 5 4 1 Data Secure Storage: • Raw or File System storage extends HW storage size • Data, certificates, keys in secure storage protected by encryption • OS integration with HW backed drivers for cryptographic operations offer confidentiality while maintaining system performance 10
  11. 11. Modeling Secure On Board Communication • Receiving Data: confirming message authenticity via cryptographic verification • Sending Data use case and generating message signature via message authentication code generation 11 Derive Use Cases To Better Understand Hardware Implications 2 Send Data 1 Generate Signature with appropriate Data and key CMAC GENERATE [ KEY, DATA] 3 4 Signed Data ready for Sending Signature Generated 1 DATA with CMAC Signature. CMAC received was generated by external ECU with System AES Symmetric keys Receive Data CMAC Signature is to be verified with corresponding System AES Symmetric key 2 3 Verify Signature - CMAC VERIFY[ KEY, DATA, SIGNATURE ] ✔ 4 Signature Confirmed ✔ DATA is Confirmed to be valid/authentic and can be used System Prepares Data for Transmission
  12. 12. Additional Requirements • Manufacturing Implications • HW security features lock down (Fusing) during EOL • Certificate/Key Management • JTAG protection and debug interface locking • Hardware validation implications • Follow a cybersecurity process 12 End to end comprehensive secure solutions aided by J3061 cybersecurity process SAE J3061 Cybersecurity Framework Security Requirements Secure Design Threat and risk analysis Features Security tests Code Analysis Security operations System Validation Fuzz testing Pen testing Incident Response Process Secure Manufacturing
  13. 13. 13