2. 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

3. 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.

4. 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

5. 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.

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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

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

14. 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

15. 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.

16. 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

17. 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

18. 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

19. 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

20. 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

21. 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

22. 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.