Support for revoking/invalidating keys

[aditihilbert]

Fabio Utzig added a comment - 22/May/17 11:25 AM
I haven't seen this ticket before, but one suggestion to implement this would be to have another partition to put keys. We could build mcuboot with the original key, and if it needs to be revoked we write a new key to some special partition. If the key is available on the partition we assume it is to be used instead of the one linked in mcuboot. This, of course, assumes we control the fw by using our key.

One problematic situation would be if we loose control of the key, before we are able to update the fw someone can use the stolen key to update the fw first and assume control.

But this should be enough to start a discussion...

[mbolivar]

I think if we are going to support revoking keys, we should be sure that they can be permanently revoked.

In this proposal, though, we'd be storing keys in a location that can be updated later (say if the application were compromised and persuaded to "un-revoke").

[d3zd3z]

Some thoughts.

First, key revocation becomes a lot more important when we allow key chains instead of just individual keys (this could be either x.509, or our own mechanism to allow a chain of signatures).

Revocation should happen immutably, but there isn't always very good hardware support it. Some devices have one-time programmable flash, which fits very well with this. Another option is to have a small partition to hold revocation (with, say two flash partition). This would need to be protected from modification by regular apps.

This (along with things like hardware anti-rollback) starts to make MCUboot more dependent on hardware-specific features, which means we should probably come up with a mechanism for optional APIs to the BSP code, possibly with defines to determine which to use.

[joh06937]

I was just writing up a new issue before noticing this idea was already posted here.

I'll second this idea, though my thought was to keep it a little simpler and provide the ability for a developer to provide N public keys during compilation of MCUBoot and invalidate "older" ones during run-time when an application update uses (successfully) a "newer" one.

It looks like the boot loader has support for having multiple public keys available for validating applications (though, in an SDK I'm using that includes MCUBoot and Zephyr, there wasn't any sanctioned way I found to provide this; I had to make a few customizations to Kconfig/CMake to outsource the generation of the C array and manually put bootutil_keys[] and bootutil_key_cnt together in my application). I simply changed the access to the array to instead use an API (same for getting the count), and then added an API for "invalidating" any keys that need to be invalidated. Right now, the system could have maybe a __weak implementation that does nothing -- keeping functionality exactly as it exists now -- but then a developer on a particular platform could implement an invalidation function.

[d3zd3z]

Right now, the system could have maybe a __weak implementation that does nothing -- keeping functionality exactly as it exists now -- but then a developer on a particular platform could implement an invalidation function.

Something like this will be a good idea. The implementations tend to be rather hardware specific, and will probably be tied to a specific platform. We have had some issues with __weak in the past, and ended up deciding to use conditional code to determine whether it got called.

[utzig]

... though my thought was to keep it a little simpler and provide the ability for a developer to provide N public keys during compilation of MCUBoot and invalidate "older" ones during run-time when an application update uses (successfully) a "newer" one.

I believe this would add N times the possibility of leaking some key or someone brute-forcing the private key. If I break any of the N keys, I could now use it to sign an image and send a revocation of all other keys. What do you think?

[d3zd3z]

I believe this would add N times the possibility of leaking some key or someone brute-forcing the private key. If I break any of the N keys, I could now use it to sign an image and send a revocation of all other keys. What do you think?

There are kind of two issues here. One is about the security of having multiple possible signing keys. This does reduce the security of the signatures by log2(N) bits. So, definitely important to think about, but probably within the realm of a reasonable security tradeoff.

The other has to do with what policy is around revoking keys. We haven't really thought about this, but I think it is something that will be useful in the real world. The key revocation above would still require a place to store the revoked keys, since it wouldn't be too difficult to just remove the newer image with the revoked keys in it.

[github-actions]

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

[d3zd3z]

This is a long-term goal. I'll create a label for this.