TEE security level/generation support?

[vesajaaskelainen]

There has been concepts like ARM's Trusted firmware version counter or TrustedFirmwareNVCounter that can be implemented in different means. In previous life we had security generation concept that kinda matches the idea.

If implemented in OTP eFuses then once could burn eFuses either in factory to match the expected level or in addition during runtime to update it when time goes on.

Now this check could be before OP-TEE is even loaded but I suppose that is not so viable in all platforms as it would require special image header handling -- so check within OP-TEE should be good enough.

What we did in previous life was to make sure that TA's are not lower security generation than what the TEE OS is. Eg. one cannot mix TA from previous problematic release when TEE OS has been upgraded to newer level.

I believe this kind of concept is missing in OP-TEE.

I suppose there should be following:

• Non-volatile TEE security level
• Current TEE security level
• In TA header matching field

During OP-TEE boot we would need to check that OP-TEE OS would not be too old and if failure then panic() or alternative go to some kind of soft lock down mode so that REE environment could try to recover to working firmware version.

• Here the check would be if OP-TEE OS current TEE security level would be smaller than OTP eFuses -> panic().

Now in order to gradually bring up updates then non-volatile TEE security level comes into picture.

• If OTP eFuses "tee security level" value is too small then burn additional fuses to bring it up to non-volatile TEE security level
• Now if the system does feature A/B firmware bank solution support then it is possible to downgrade to previous version up till the OP-TEE OS embedded current TEE security level is too old.
• One would increment non-volatile TEE security level in delayed fashion as it causes absolute downgrade barrier

Now TA probably should be checked against current TEE security level as it is expected that Root FS and OP-TEE OS matches from same build.

This should not be confused with device firmware downgrade prevention which functions in different level (and has larger version space) -- this is all about TEE environment.

As OTP eFuses gives easily range like 0..31 -- settings life cycle should be part of the vendor's responsibility.

Any toughs on the matter?

[jenswi-linaro]

This should not be confused with device firmware downgrade prevention which functions in different level (and has larger version space) -- this is all about TEE environment.

How is this different? Where would you use one and not the other and vice versa?

[vesajaaskelainen]

This should not be confused with device firmware downgrade prevention which functions in different level (and has larger version space) -- this is all about TEE environment.

How is this different? Where would you use one and not the other and vice versa?

When you know that there is security issue in TEE environment that needs to be installed on the field you need to plan the upgrade path how to deploy that. In the end you want that TEE environment cannot be downgraded to previous version. TEE environment could also be handled by different team that has better knowledge on that level of things.

Now the firmware downgrade prevention works in more fine-grained versions.

Let's try to draw it.

gitGraph
       commit id: "Initial 1.0.0 release"
       commit id: "Patch release 1.0.1"
       branch tee-fix
       checkout tee-fix
       commit id: "Fix TEE security fix"
       commit id: "Increase Current TEE security level"
       checkout main
       merge tee-fix
       commit id: "Patch release 1.1.0"
       commit id: "Patch release 1.1.5"
       branch app-security-fix
       checkout app-security-fix
       commit id: "Fix OS/APP security fix"
       checkout main
       merge app-security-fix
       commit id: "Patch release 1.1.6"
       commit id: "Patch release 1.2.0"
       commit id: "Patch release 1.4.0"
       branch tee-force-upgrade
       checkout tee-force-upgrade
       commit id: "Increase Non-volatile TEE security level"
       checkout main
       merge tee-force-upgrade
       commit id: "Patch release 1.5.0"
       commit id: "Patch release 1.8.0"
       commit id: "Patch release 2.0.0"

Now on release 1.0.1 it was noticed that there was a security problem that needs a fix that needs to be applied to TEE environment that requires that all assets are at certain level. In order to enable customers to deploy the fix in good manner beforehand fix is bundled before enforcement and to make sure that also user space has correct versions of software components (eg. to fight against mix'n'match hacking).

On release 1.5.0 it is considered that upgrades are now applied and there might be also other reasons too that would create upgrade barrier and then enforce is programmed.

Now if device would be manufactured eg. with 1.5.0 release then it would be enforced that you cannot anymore install order firmware as eFuses would be against you.

Now in earlier devices there could be soft downgrade prevention that would not allow you to downgrade from 1.4.0 to 1.2.0 release. If you find out how to beat the soft downgrade prevention then you could install earlier version.

This "soft" downgrade prevention could then utilize TEE services to store firmware version numbers or such to make that a bit harder to beat. That soft downgrade logic is often left to firmware to determine how to go downgrade. And different downgrade preventions paths should be designed to be a bit in sync so that there is no conflict.

But in some product types you cannot just enforce that you always need to go forward. Eg. some device operator's verity that is the new 2.0.0 release working if not then let's go back to 1.5.0.

Version numbers like 2.0.0 sound like major upgrade for logical point but that cannot always be required. But once passed something that major upgrade can be considered working then can set the hard limit.

Writing version numbers to eFuses that change more or less means that extra bit is burned. Thus you get often eg. 32 bit eFuses and then those are consumed one bit a time givin you 31 different versions as all bits set means that no more control left but anything goes. Thus hard downgrade prevention needs different versioning than common a.b.c versioning.

Now as eFuses are a bit scarce and TEE problems are not happening as often like what Linux kernel + user space needs updates. Then it is better to use eFuses for TEE downgrade prevention as in theory it is a security base for the system. When that is good then other systems can trust that firmware downgrade version information is most likely good.

TEE security level is for security environment hard versioning to making sure that eg. if you USB/SD boot you cannot anymore bring old firmware to the device when certain point has been passed. This of course requires that the mechanism is there in the first release that is secure boot signed with release keys.

[jenswi-linaro]

Thanks for the explanation, sounds like a nice compliment. There are some pitfalls but it looks like you've identified those too.

[github-actions]

This issue has been marked as a stale issue because it has been open (more than) 30 days with no activity. Remove the stale label or add a comment, otherwise this issue will automatically be closed in 5 days. Note, that you can always re-open a closed issue at any time.

[vesajaaskelainen]

keep-alive

Feature flag to keep bot on bay?