1. Secure Software Update Over-the-Air for Ground Vehicles Specification and Prototype André Weimerskirch, Brian Anderson This work is sponsored by DHS Cybersecurity Division – Science and Technology Directorate November 19, 2015 1

2. Background n Firmware updates over-the-air can fix automotive security vulnerabilities quickly n However, firmware update implementations (wired or wireless) have been shown to be vulnerable to attacks in the past. n Some companies already offer solutions; however, solutions are proprietary, limited to only a few components, and not tested for their security. 2

3. Objective n Develop an open standard for secure over- the-air (SOTA) automotive software updates that is flexible enough to cover the requirements of the major stakeholders. n Create a proof-of-concept secure reference implementation n Account for the cyber physical and safety aspects n Focus on automotive platform, usability, security, and the supply chain 3

4. Objective: Stakeholders n A main objective is to include stakeholders from the beginning o OEMs, suppliers, user representatives? n All results, including source code, will be made available to interested stakeholders 4

5. Technical Approach 1. A central server queries for firmware versions 2. The central server digitally signs code 3. Signed code is securely transferred to the vehicle 4. An in-vehicle unit verifies the code and prepares for the update 5. ECUs updates are executed 6. Update status (success/fail) is reported and rollback executed, as needed 5

6. Technical Approach: Questions n So far, so easy... n Who signs the code? (e.g. OEM and/or T1) n Is firmware downloaded first, and updated later? n If stored, where is it stored until an update is executed? n Do keys in the vehicle need protection? What level? n Should keys be updated? How often? Is revocation needed? n How do we test the security of the design? How do we test the implementation for flaws or intended/unintended backdoors? n How can developers and test drivers easily update firmware and calibration files, without creating a weak backdoor? n What other questions/answers are needed... 6

7. Project Organization n 2 year project o Oct. 2015 – Sept. 2017 7

8. Milestones and Deliverables Initial Requirements and Requirements Workshop Final Requirements, Initial Design, and Initial Test Plan Design and Testing Workshop Final Design and Prototype Implementation Tested Prototype Implementation and Integrated Vehicle Implementation Tested Integrated Implementation 1 2 3 4 5 6

9. Stakeholder Involvement n Stakeholder workshop planned for February 9th, 2016, in Ann Arbor, Michigan o Please contact Andre if you are willing to participate: andrewmk@umich.eduandrewmk@umich.edu n More details about project, and initial requirements will be presented at the workshop, and feedback will be collected 9

10. Contact André Weimerskirch 2901 Baxter Road, Ann Arbor, MI 48109 Email: andrewmk@umich.edu Office: 734-936-1046 Mobile: 734-474-5255 Email: andrewmk@umich.edu Brian Anderson 6220 Culebra Road, San Antonio, TX 78238 Email: banderson@swri.org Office: 210-522-6696 Mobile: 210-213-7838 Email: banderson@swri.org 10

11. Tasks, Schedule and Milestones Task #TaskTask Start Date Task Due Date MilestonesMilestone Due Date 1RequirementsMonth 1Month 6Initial RequirementsMonth 3 WorkshopMonth 3 Final RequirementsMonth 6 2DesignMonth 1Month 12Initial DesignMonth 6 WorkshopMonth 9 Final DesignMonth 12 3Implementation & Integration Month 1Month 18Prototype ImplementationMonth 12 Final Vehicle-Integrated ImplementationMonth 18 4Testing and Evaluation Month 1Month 24Test & Evaluation PlanMonth 6 Workshop (combined with Task 2 workshop)Month 9 Refined Test & Evaluation PlanMonth 10 Test & Evaluate Prototype ImplementationMonth 18 Test & Evaluate Final Vehicle-Integrated Implementation Month 24 11