Modern automotive Electronic Control Units (ECUs) keep safety-relevant data—calibration values, motor configuration, runtime counters and diagnostic records—in non-volatile memory. As dedicated EEPROM components have disappeared from the bill of materials, this storage role is now handled by firmware that emulates EEPROM behaviour on top of the microcontroller's internal Flash. Vendor frameworks and the AUTOSAR module address the resulting layer only as a memory-management problem, focused on endurance and recovery from power loss. None of them treat it as a security boundary, even though it is the gatekeeper for data that directly influences how the ECU drives the physical system. This thesis closes that gap. The work targets a TLExxxx-class smart-power microcontroller platform, with an Infineon AUTOSAR-compliant FEE driver as the algorithmic baseline, and follows ISO/SAE 21434 Clause 15. Data Flow Diagrams expose the diagnostic, API and Flash-driver trust boundaries; nine assets are identified across storage, metadata, control firmware and HSM-held keys; STRIDE is applied per element; and a TARA evaluates thirteen scenarios, including a time-of-check / time-of-use case introduced by the asynchronous Fee_MainFunction() model. The cybersecurity objectives drive the architecture. The proposed design is a security extended layer above the standard Fee_Read/Fee_Write API that preserves the asynchronous execution model and the MEMIF state machine. Storage is dual-sector and log-structured with one dataset per wordline; integrity is layered (hardware ECC, CRC-16/CCITT, optional HSM-derived CMAC); a monotonic version counter prevents replay; and the API enforces caller identity, write/erase privilege separation and per-group rate limiting. Every high- and critical-risk threat in the assessment is mapped to a specific countermeasure, and the design is compared against AUTOSAR FEE, STMicroelectronics AN3390 and two Infineon products (a non-AUTOSAR middleware and an AUTOSAR-compliant FEE driver) to show that none of them addresses cybersecurity at this layer. The algorithmic core is also realised as an executable prototype whose automated tests, traceable to the same threats and requirements, confirm its behaviour at the design level; validation on target hardware is left as the immediate next step. The contribution is a replicable engineering process for treating EEPROM emulation as a security concern in its own right within automotive cybersecurity engineering, with each architectural decision traceable to a risk derived from ISO/SAE 21434.
Secure Software-Based EEPROM Emulation for Embedded Systems
MERSHA, MAHLET KINFE
2025/2026
Abstract
Modern automotive Electronic Control Units (ECUs) keep safety-relevant data—calibration values, motor configuration, runtime counters and diagnostic records—in non-volatile memory. As dedicated EEPROM components have disappeared from the bill of materials, this storage role is now handled by firmware that emulates EEPROM behaviour on top of the microcontroller's internal Flash. Vendor frameworks and the AUTOSAR module address the resulting layer only as a memory-management problem, focused on endurance and recovery from power loss. None of them treat it as a security boundary, even though it is the gatekeeper for data that directly influences how the ECU drives the physical system. This thesis closes that gap. The work targets a TLExxxx-class smart-power microcontroller platform, with an Infineon AUTOSAR-compliant FEE driver as the algorithmic baseline, and follows ISO/SAE 21434 Clause 15. Data Flow Diagrams expose the diagnostic, API and Flash-driver trust boundaries; nine assets are identified across storage, metadata, control firmware and HSM-held keys; STRIDE is applied per element; and a TARA evaluates thirteen scenarios, including a time-of-check / time-of-use case introduced by the asynchronous Fee_MainFunction() model. The cybersecurity objectives drive the architecture. The proposed design is a security extended layer above the standard Fee_Read/Fee_Write API that preserves the asynchronous execution model and the MEMIF state machine. Storage is dual-sector and log-structured with one dataset per wordline; integrity is layered (hardware ECC, CRC-16/CCITT, optional HSM-derived CMAC); a monotonic version counter prevents replay; and the API enforces caller identity, write/erase privilege separation and per-group rate limiting. Every high- and critical-risk threat in the assessment is mapped to a specific countermeasure, and the design is compared against AUTOSAR FEE, STMicroelectronics AN3390 and two Infineon products (a non-AUTOSAR middleware and an AUTOSAR-compliant FEE driver) to show that none of them addresses cybersecurity at this layer. The algorithmic core is also realised as an executable prototype whose automated tests, traceable to the same threats and requirements, confirm its behaviour at the design level; validation on target hardware is left as the immediate next step. The contribution is a replicable engineering process for treating EEPROM emulation as a security concern in its own right within automotive cybersecurity engineering, with each architectural decision traceable to a risk derived from ISO/SAE 21434.| File | Dimensione | Formato | |
|---|---|---|---|
|
final (1).pdf
Accesso riservato
Dimensione
2.57 MB
Formato
Adobe PDF
|
2.57 MB | Adobe PDF |
The text of this website © Università degli studi di Padova. Full Text are published under a non-exclusive license. Metadata are under a CC0 License
https://hdl.handle.net/20.500.12608/110967