2260721_en-US

[#1]

S32K3_HSE on how secure boot combined with HSE prevents malicious version fallbacks

Hello:

There is a question about S32K3 about mass production, information security. It's about bt version fallback. Let's say I have a bt version that is higher, and someone gets a bt that has a vulnerability from a previous version that is lower, and then attempts to swipe that bt version in. Is there any way to avoid this at the secure boot level? Because secure boot also verifies the MAC information of the fixed flash address. If I write a low version of the signature checking data is also OK, how to avoid this situation? Is it possible to use the HSE internal secure area for this kind of signature verification? Or do I need to do version management with the upgraded version? Which approach is currently used by everyone?

Re: S32K3_HSE关于安全启动结合HSE如何防止恶意版本回退

Hi @rujunzhou 

Common approach is like this: use a signed version field in the app header and an HSE monotonic counter as the freshness gate. Before installing a new update, read the HSE counter (device’s minimum accepted version) and compare it against the authenticated fw_version in the update image. If fw_version < counter, reject the update, else proceed. After a successful update, increment the monotonic counter so the device can’t accept older, vulnerable images later.

Regards,

Lukas