Principles of Automotive cyber-security Safety by Design Third-Party Collaboration Logging/Evidence Capture Over the Air Security Updates Segmentation & Isolation End-To-End Validation

Security Design Philosophy Cyber-Security Security Design Philosophy Block everything except what you must let through. What you do let through, authenticate and sign or encrypt. (If you care about integrity you sign, if care about privacy you encrypt) Log what gets through and what gets blocked.

Todays Common Automotive Architectures Cyber-Security Todays Common Automotive Architectures OBD CAN/MOST (multiple busses) ECU ECU ECU GW TCU LIN FlexRay Cell WiFi All ECU’s reside on common CAN Bus OBD2 port has full CAN Access TCU has full CAN Access

Quick/Interim Security Architecture Cyber-Security Quick/Interim Security Architecture OBD FW CAN/MOST (multiple busses) ECU ECU ECU GW TCU LIN FlexRay Cell WiFi Add a Firewall between CAN and OBD2 port FW can have static rules or OTA updateable rules Protects most vulnerable OBD2 port.

Next Generation Architecture Cyber-Security Next Generation Architecture OBD GW/TCU FW/IDS CAN/MOST (multiple busses) FlexRay WiFi ECU ECU ECU LIN Cell V2X GW and TCU functionality are combined GW serves as a Firewall for all external busses GW has IDS software to detect attacks GW has certificate for receiving encrypted updates and external communication GW manages OTA updates

Future Generation Architecture Cyber-Security Future Generation Architecture OBD GW/TCU FW/IDS Ethernet/CAN (multiple busses) FlexRay WiFi ECU ECU ECU LIN Cell V2X CAN migrates to faster Ethernet Bus Each ECU has a unique certificate Most Ethernet traffic is encrypted (e.g. all control messages) Status message on Ethernet are digitally signed, but not encrypted GW manages certificates for ECU’s

Layered Security Model Cyber-Security Layered Security Model Device - TCU Vehicle Interface Controller (VIC) is isolated from Host Processor for CAN security VIC Processor OEM security between VIC and CAN Bus Proprietary protocol between VIC and Host Processor Host/NAD Processor Only approved apps can communicate to VIC Only OEM Data Center can send CAN commands Network Private network from vehicle to OEM Data Center Data Center is on a private network Data Center should be a Tier 1 data center that is SAS70 Type II audited and PCI Compliant Level 1 All commands are authenticated and encrypted Internet All remote devices (phones, computers, etc.) communicate only with Data Center; they do not communicate with the TCU directly Each command is authenticated against vehicle and user database

Cyber-Security Cloud Software Secure JTAG Secure Boot Three JTAG modes JTAG enabled: used during development Secure JTAG: provides challenge/response before access JTAG disabled: disables complete access to JTAG (set after production, for most secure) Secure Boot Verifies signature(s) of OS before booting into the OS Bootloader is read/write protected after flashing so cannot be read or modified. Software Integrity Verification Verifies each application signature before executing Requires chain of trust to application provider Secure Storage Filesystem is encrypted Prevents reading filesystem if physically removed from device Secure Application Environment Provides protected execution environment for each application Protects applications from accessing other applications memory Can be accomplished with Virtual Machines (VM), Linux Containers or Android Application Sandboxes

Cyber-Security Cloud Software Authentication Protocols Basic Authentication w/ TLS Username/password that is Base64 encoded.  Uses TLS for Oauth1.0a Cryptographic signature that combines the token secret, nonce, and other request based information.  token secret is never sent across the network, which completely eliminates the possibility of anyone seeing a password in transit. Doesn’t require TLS Generating and validating signatures can be resource intensive Oauth2 Not an evolution of Oauth1 Doesn’t use signatures Requires TLS for encryption Not widely used or recommended

Cyber-Security API Security (REST) Session based authentication Cloud Software API Security (REST) Session based authentication Establish token via a POST or by using an API key as a POST body argument Protect session state Anti-replay – Never put usernames, passwords, tokens or API’s in the URL

Cyber-Security 1 1 1 2 5 4 3 1 2 3 4 5 OEM Systems Cloud-Based Servers Communication Module Other Vehicle ECUs Block Diagram 1 Policy Manager 1 1 OAUTH Server Diff Manager 2 Update Manager Flasher 5 4 Download Manager OMA-DM Encryption Encryption Encryption Encryption Encryption 3 1 2 3 4 5 Transport Layer Security RSA encrypted with communication module or OEM public key Encrypted Volume Username / Password Nonce;or Certificates Transport Layer Security OEM Customer Security Authentication Authentication Authentication Authentication Usernamer / password (OAUTH) Virtual Private Network (SSL/IPSEC) Certificate Transport Layer Security IPEC Transport Layer Security OEM Customer Security

Industry holes in this architecture Cyber-Security Industry holes in this architecture

Security Enhancements Cyber-Security Security Enhancements Firewall Need a firewall instance on every entry point Cellular, WiFi, Bluetooth, V2X, TPMS, CAN, OBD2, etc. Generally better to use White list rules only Rules/Policies should be updatable OTA Intrusion Detection System Detect abnormal traffic on bus’s. Certificate Management Need ability to revoke certificates Need ability to change/update certificates

Policy based Firewall Why needed? Security needs evolve and security policies will change. Detect and block DDOS attacks Need a separate blocking point from the routing engine, to protect against SW issues in the routing engine. Need to prevent the routing engine from getting overloaded. OTA updates to other modules may require that new information be accessible on different busses Need to understand when attacks are being made and to be able to take action.

Policy based Firewall Features Input/Output Filters on all GW interfaces OTA updateable DDOS detection Event based isolation of interfaces Reporting Engine Cloud Based Standalone or integrated with Lear OTA solution White List centric, but Black list capable

Connected Gateway Firewall Routing Engine Policy Manager OBD Input Filter Output Filter FlexRay Input Filter Output Filter Input Filter Output Filter CAN Input Filter Output Filter LIN Input Filter Output Filter Ethernet Cellular Input Filter Output Filter V2X Input Filter Output Filter

Intrusion Detection System Cyber-Security Intrusion Detection System CAN/MOST Anomaly Detection Abnormal/Conflicting CAN activity CAN Messages with invalid or cloned ID’s CAN Bus scans by an external/unauthorized tool ECU Integrity Alert when an ECU is re-flashed or modified Monitor flash signatures for changes Can/KeyFob Scan Detection Detect a diagnostic tool on the BUS performing diagnostics scans Detect scans being performed by unauthorized tools Actively developing internal expertise and external partners for an optimized approach to cyber-security

Certificate Management Certificate Authority (OEM) Certificate Manager UI Certificate Authority (Tier 1) GW or TCU will act as In-Vehicle Certificate Manager(CM) Will maintain a local CRL Has certificate for all Tier 1 manufactured ECU’s Will create new certificates for all ECU’s ECU is manufactured with unique keys and certificate signed by Tier 1’s CA In-Vehicle CM creates new keys and certificate when installed in vehicle. Certificate Manager GW or TCU Certificate Store ECU Certificate Store ECU Certificate Store ECU

Penetration Test Bed Penetration Test Bed A Collection of tools and processes that would allow us test devices to check for security weaknesses. Using community (hacker) developed tools Black Hat and White Hat testing Testing of our own devices as well as third parties Develop attack profiles for all threat entry points Develop threat prioritization framework Develop logging/notification framework

CyberSecurity plan for each product SAE J3061 Compliance CyberSecurity plan for each product New activities, documents and reviews during product design and development Adjusted for each project according to customer requirements Field Monitoring Incidence detection, reporting, and response Monitor ISAC and similar resources Hacker chatter Mentoring and education Share lessons learned company-wide Conferences (DefCon, BlackHat) Red Team that keeps track of available hacking tools Periodic process reviews

Security Design Philosophy Cyber-Security Security Design Philosophy Block everything except what you must let through. What you do let through, authenticate and sign or encrypt. (If you care about integrity you sign, if care about privacy you encrypt) Log what gets through and what gets blocked.