MPC5777C CSE Secure Boot Usage & Rationale

[manoel-serafim]

Hi there!

While studying the CSE Secure Boot on the MPC5777C, I noticed that its effective scope seems quite limited. Since the BOOT_MAC is initialized and stored by the CSE on first boot (based on whatever content is present in flash at that time), subsequent boots only verify that the content has not changed relative to that initial state. [1] Is this last affirmative accurate?

This appears to make the SECURE_BOOT primarily an immutability check, rather than an authenticity verification of a MAC/message pair. Of course, authenticity is implicitly guaranteed if the first boot image is trusted and this does not present an issue.

However, given this, [2]what is the concrete advantage of using CSE Secure Boot over protecting the same flash region using PASS module password-based locking via DCF? In both cases, the end result seems to be enforcing immutability.

[3]Is the only benefit of the CSE the protected storage of user configured KEYs, rather than the CMAC verification itself?

[petervlna]

Hello,

Does CSE secure boot only verify that flash content has not changed since the first boot?

Not exactly.
It is true that on the first successful secure boot, the CSE computes and stores the BOOT_MAC (using the user‑defined BOOT_KEY) corresponding to the flash boot block contents.
On every subsequent boot:

The CSE recomputes the CMAC of the same flash region.
It compares it with the stored BOOT_MAC (which is stored securely inside the CSE NVM).

So yes, from that point forward it is an integrity / anti‑tamper check, not an authenticity check against an external golden reference.
But this mechanism is still an authenticity check, because:

The BOOT_MAC is computed using a secret key (BOOT_KEY) that only the CSE knows.
Only someone who knows the BOOT_KEY can generate another valid BOOT_MAC for modified code.

Thus the secure boot guarantees:

“Only code authenticated with the secret BOOT_KEY can ever be accepted by the device.”

If your system is in field and the BOOT_MAC is locked, unauthorized modification (even by someone with physical access to flash) will brick the boot authentication.

What is the concrete advantage of CSE Secure Boot vs. PASS/DCF password‑protected flash locking?

DCF/PASS locking enforces immutability using an access control mechanism, while: CSE Secure Boot enforces authenticity + integrity using cryptographic guarantees.

1. DCF/PASS locking is not cryptographic

• PASS module passwords are static values stored in flash.
• If an attacker can read or bypass flash protections, or glitch during password comparisons, the flash can be rewritten.

2. PASS/DCF does not verify that code has not been tampered with

• PASS module never checks flash contents at boot.
• If attacker can rewrite flash (by bypassing debug protections, partial flash injection, power fault/glitching), the PASS module does not detect it.

3. CSE stores BOOT_KEY and BOOT_MAC inside secure embedded NVM protected by hardware

4. CSE secure boot defends against broader threat models

5. CSE Secure Boot allows controlled re‑provisioning

Is the only benefit of CSE simply that it securely stores keys?

CSE secure boot provides:
Authenticity (cryptographically ensured)
  Only someone with BOOT_KEY can provision a new boot image.
Integrity checking on every boot
  Flash corruption → boot failure.
Hardware‑rooted security
  Keys stored in CSE RAM/NVM + access controlled hardware state machine.
Strong protection against physical attacks
  Glitching and probing the PASS module is trivial compared to bypassing the CSE FSM.
Prevents malicious hardware or firmware modifications
  Critical for automotive security standards (ISO 21434, UNECE R155).
Works even if the PASS/DCF protections are bypassed

Best regards,

Peter