Electronic Control Unit Authentication in Autonomous Vehicles (ECU2A)

OUSD (R&E) CRITICAL TECHNOLOGY AREA(S): FutureG, Trusted AI and Autonomy, Advanced Computing and Software, Integrated Sensing and Cyber OBJECTIVE: The objective of the Electronic Control Unit Authentication in Autonomous Vehicles (ECU2A) Direct to Phase 2 (DP2) SBIR topic is to develop prototype systems to authenticate, monitor, and detect malicious activities in Electronic Control Units (ECUs) of modern intelligent military and civilian vehicles. DESCRIPTION: ECUs are one of the most critical embedded systems that control many subsystems in a vehicle [1]. A vehicle’s distributed network of ECUs is responsible for the control/functionality of the engine and transmission system, as well as for the control/functionality of the vehicle’s comfort and entertainment systems. Due to the extensive and growing use of ECUs in modern vehicles, and the associated increased costs and complexities they bring (e.g., due to multiple manufacturers, system integration requirements) [2], many vehicle manufacturers have adapted their manufacturing models and design flows to use the intellectual property of third-party ECU manufacturers, and outsource the fabrication of ECU hardware to offshore foundries to reduce the cost and time-to-market for their vehicles. Unfortunately, outsourcing ECU fabrication raises important security concerns [3, 4] for intelligent vehicles used by the civilian sector as well as US expeditionary forces abroad.The various Internet-of-Things (IoT) networks (e.g., Cellular, Local and Personal Area Networks, Low Power Wide Area Networks, and Mesh networks [5]) and the continuing increases in the scale of networked systems offers unprecedented interconnectivity of electronic devices, to include ECUs. Because of the ubiquitous nature and large attack surfaces of IoT networks, threats such as man-in-the-middle attacks, denial of service attacks, and hijacking of services attacks [6] can be successfully executed through bypassing the authentication process of ECUs. The consequences of such attacks can increase in severity if the ECUs are tampered with during production [7, 8, 9], prior to installation in the vehicle. Therefore, it is critical to have the ability to securely authenticate vehicular ECUs and to continuously monitor them for detection of malicious activity. PHASE I: The ECU2A SBIR topic is soliciting DP2 proposals only, which must include supporting documentation of Phase I feasibility. Phase I feasibility must be demonstrated through evidence of: a completed proof of concept/principal or basic prototype system; definition and characterization of system properties/technology capabilities desirable for DoD/IC/government and civilian/commercial use; and capability/performance comparisons with existing state-of-the-art technologies/methodologies (competing approaches). Entities interested in submitting a DP2 proposal must provide documentation to substantiate that the scientific/technical merit and feasibility described above has been achieved and also describe the potential commercial applications. DP2 Phase I feasibility documentation should include, at a minimum: • technical reports describing results and conclusions of existing work, particularly regarding the commercial opportunity or DoD/IC insertion opportunity, risks/mitigations, and technology assessments; • presentation materials and/or white papers; • technical papers; • test and measurement data; • prototype designs/models; • performance projections, goals, or results in different use cases; and, • documentation of related topics such as how the proposed ECU2A solution can enable secure authentication and continuous monitoring of ECUs in modern intelligent vehicles. The collection of Phase I feasibility material will verify mastery of the required content for DP2 consideration. DP2 proposers must also demonstrate knowledge, skills, and abilities in the technical areas of software engineering, network security, cyber security, analytics, and machine learning. For detailed information on DP2 requirements and eligibility, please refer to the DoD Broad Agency Announcement and the DARPA Instructions for this topic. PHASE II: The objective of the ECU2A DP2 SBIR topic is to develop prototype systems to authenticate, monitor, and detect malicious activities in ECUs of modern intelligent military and civilian vehicles.ECU2A will develop new hardware/software/component verification methods, algorithms, and machine learning models to improve vehicular ECU security. Strong ECU2A proposals should address several technical challenges, such as: • effective tools and algorithms for one-time ECU authentication and continuous ECU monitoring schemes; • models capable of rapidly identifying compromised ECUs;. • ECU software/hardware validation techniques, prior to and after installment; • zero-overhead, non-intrusive monitoring schemes, that do not require direct ECU access, for easy and secure deployment; • techniques to rapidly minimize the connection/communication between the source of malicious activity and a targeted ECU; • capabilities to detect hardware/software trojans with no reverse-engineering techniques; • monitoring methods for devices operating on a broad range of ECU components, and which have an air-gapped nature. Phase II will culminate in a demonstration of the application and validation of ECU2A-developed technologies for detecting malicious activity against one or more concrete technological use cases of integrated software systems.Schedule/Milestones/Deliverables: Proposers will execute the research and development (R&D) plan as described in the proposal, including the below: • Month 1: Phase I Kickoff briefing (with annotated slides) to the DARPA Program Manager (PM) including: any updates to the proposed plan and technical approach, risks/mitigations, schedule (inclusive of dependencies) with planned capability milestones and deliverables, proposed metrics, and plan for prototype demonstration/validation. • Months 4, 7, 10: Quarterly technical progress reports detailing technical progress to date, tasks accomplished, risks/mitigations, a technical plan for the remainder of Phase II (while this would normally report progress against the plan detailed in the proposal or presented at the Kickoff briefing, it is understood that scientific discoveries, competition, and regulatory changes may all have impacts on the planned work and DARPA must be made aware of any revisions that result), planned activities, trip summaries, and any potential issues or problem areas that require the attention of the DARPA PM. • Month 12: Interim technical progress briefing (with annotated slides) to the DARPA PM detailing progress made (including quantitative assessment of capabilities developed to date), tasks accomplished, risks/mitigations, planned activities, technical plan for the second half of Phase II, the demonstration/verification plan for the end of Phase II, trip summaries, and any potential issues or problem areas that require the attention of the DARPA PM. • Month 15, 18, 21: Quarterly technical progress reports detailing technical progress made, tasks accomplished, risks/mitigations, a technical plan for the remainder of Phase II (with necessary updates as in the parenthetical remark for Months 4, 7, and 10), planned activities, trip summaries, and any potential issues or problem areas that require the attention of the DARPA PM. • Month 24: Final technical progress briefing (with annotated slides) to the DARPA PM. Final architecture with documented details; a demonstration of the ability to authenticate, monitor, and detect malicious activities in ECUs; documented application programming interfaces; and any other necessary documentation (including, at a minimum, user manuals and a detailed system design document; and the commercialization plan). • Month 30 (Phase II Option period): Interim report of matured prototype performance against existing state-of-the-art technologies, documenting key technical gaps towards productization. • Month 36 (Phase II Option period): Final Phase II Option period technical progress briefing (with annotated slides) to the DARPA PM including prototype performance against existing state-of-the-art technologies, including quantitative metrics for assessment of prototype features/capabilities. PHASE III DUAL USE APPLICATIONS: ECU2A has potential applicability across DoD/IC/government and commercial entities. For DoD/IC/government, ECU2A is extremely well-suited for improving the security of intelligent vehicles used by US expeditionary forces abroad. ECU2A has the same applicability for the commercial sector.Phase III refers to work that derives from, extends, or completes an effort made under prior SBIR funding agreements, but is funded by sources other than the SBIR Program. The Phase III work will be oriented towards transition and commercialization of the developed ECU2A technologies. For Phase III, the proposer is required to obtain funding from either the private sector, a non-SBIR Government source, or both, to develop the prototype into a viable product or non-R&D service for sale in government or private sector markets. Primary ECU2A support will be to national efforts to help secure military and commercial intelligent vehicle ECUs against threats that target vulnerabilities. Results of ECU2A are intended to improve understanding of the threats and vulnerabilities associated with the increasing use of intelligent vehicles, across government and industry. REFERENCES: 1. Jaks, L. (2014). Security Evaluation of the Electronic Control Unit Software Update Process. Available at: http://kth.diva-portal.org/smash/get/diva2:934083/FULLTEXT01.pdf 2. Electronics Sourcing. (2022). How Many Chips are in Our Cars?https://electronics-sourcing.com/2022/05/04/how-many-chips-are-in-our-cars 3. R. Kurachi et al., "Evaluation of Security Access Service in Automotive Diagnostic Communication," 2019 IEEE 89th Vehicular Technology Conference (VTC2019-Spring), 2019, pp. 1-7, doi: 10.1109/VTCSpring.2019.8746714. Available at https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=8746714. 4. Spaan, R.. Secure updates in automotive systems. Nijmegen: Radboud University(2016): 1-71. Available at: https://www.ru.nl/publish/pages/769526/z_remy_spaan.pdf 5. IotaComm. 2020. Four Types Of IoT Wireless Networks. https://www.iotacommunications.com/blog/types-of-iot-networks/ 6. Huq, N. et al. “Cybersecurity for Connected Cars: Exploring Risks in 5G, Cloud, and OtherConnected Technologies.” Trend Micro Research. 2021. Available at: https://documents.trendmicro.com/assets/white_papers/wp-cybersecurity-for-connected-cars-exploring-risks-in-5g-cloud-and-other-connected-technologies.pdf 7. Cho, Kyong-Tak, and Kang G. Shin. "Fingerprinting electronic control units for vehicle intrusiondetection." 25th USENIX Security Symposium (USENIX Security 16). 2016. Available at https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper_cho.pdf 8. Kim, Kyounggon, et al. "Cybersecurity for autonomous vehicles: Review of attacks and defense."Computers & Security, Volume 103 (2021): 102150. ISSN 0167-4048, https://doi.org/10.1016/j.cose.2020.102150. 9. Wasicek, A. and Weimerskirch, A. “Recognizing manipulated electronic control units,” . SAE Technical Paper 2015-01-0202, 2015, https://doi.org/10.4271/2015-01-0202.. Available at https://ptolemy.berkeley.edu/projects/chess/pubs/1111/autoids_v2_preprint1.pdf. KEYWORDS: Electronic Control Units, Cyber Security, Intrusion Detection, Intelligent Vehicles