+vapier

Hi vapier, do you think there are some other better way so we can get an authorized list of "MP and PreMP key hashes of root and recovery keys"?

VERSION.signer was not intended to be machine readable.  please don't start making anything rely on its format.  i'm inclined to just delete it before someone starts ...

we don't currently publish the public keys or their hashes anywhere.  we have issue 343499 to track doing so though.  i think that request would cover everything you want ?

I don't think there is any "authorized list" outside of HWID. Note that just because a key is in chromeos-firmwareupdate does not make it authorized. We have fully invalid default keys, and OEMA is not authorized to sign devices with OEMB's keys. So key must match model / wl name as well as OEM's authorization, which is currently defined by the HWID file provided.

Key correctness is a required security feature, so I think it should be verified by GRT whether or not it is in HWID.

Re#4

Currently no such list outside HWID, but I think we do need one.

The challenge today is, no one dealing with HWID knows what's the expected value. Usually partner simply runs gooftool probe, and try to submit a key hash with whatever they have probed on that device. And in Google side, I think device PM & SIE have no clear way to figure out if that value is correct but giving a rubber stamp.

This was not that bad when all images have single project, single firmware - that we know the DEV key hash, so different hash will only appear twice - PreMP and MP, very clear. But today, as most projects are doing unified builds, or white label, there are dozens of keys may appear in one single image, and we have no way to know if partner has used the correct key - maybe he used flashrom to put a raw image , or if his SKU / WL tag was wrong so the hash was for OEMB.

As a result, I think we do need an authorized source to make sure the key is assigned properly, and it does need device-specific list (i.e., able to know the keys is for OEMA instead of OEMB). Vapier's issue 343499 may be a good answer to this. Firmware updater was one temporary solution before we have anything better and can have the hash automatically done.
 
And one last thing, yes I agree this must be done in GRT - and must be verified within the finalize step (gooftool finalize) so we know all partners won't forget to include it.

In fact I think this issue is revising what has been discussed in  issue 807222  and issue 760881.

re#3,

I just don't understand why info in chromeos-firmwareupdate of recovery image can't be trusted since factory flow already extract it out and execute it for updating firmware version including "re-key process". So based on the same chromeos-firmwareupdate package, in the GRT we can at least make sure "current public key in firmware MUST be the same in the corresponding key in chromeos-firmwareupdate". Isn't all our current process including HWID are all based on info of chromeos-firmwareupdate itself?

Since re-key is done by chromeos-firmwareupdate, no matter we reveal public key info in VERSION.signer or not factory or users (in dev mode) can always get them easily. So why do we want to hide them?

re#5,

Refer to [1] from issue 760881, the idea [2] is also similar to the plan here. I just tried to eliminate the process in GRT side by collecting hash information first in signer side.  

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=760881#c6
[2] The plan is to utilize and trust the firmware updater inside release image, instead of baking more firmware hashes that no one really confirmed if they're correct or not in HWID config database.

re#5,

> And in Google side, I think device PM & SIE have no clear way to figure out if that value is correct but giving a rubber stamp.

No, this is not true. Since key hash is probed from DUT after applying chromeos-firmwareupdate, we will extract that chromeos-firmwareupdate then leverage futility tool to get hash info of a corresponding rootkey.xxx in order to do comparison. The point is this process can be done like the proposal here automatically.

re#4

> We have fully invalid default keys, and OEMA is not authorized to sign devices with OEMB's keys. So key must match model / wl name as well as OEM's authorization, which is currently defined by the HWID file provided.

Since sku id is root of trust, we can base on it to know what key-id (or called signature?) (from cros_config or mosys platform signature) is correct in order to do matching. Basically HWID database is selected by the same way. So the concern above can be also verified by the plan here.

re #6: We can probably trust chromeos-firmwareupdate for the model -> key hashes, however we can't determine which key is the right key for this OEM line. We'd need a separate model/whitelabel_tag check in GRT or HWID to look up the expected key.

Update the discussion with stimim and yhong offline:

1. data format in VERSION.signer is a known concern.
2. Conclusion: if we trust SKU ID (defined as root of trust?) in the device and chromeos-firmwareupdate from release partition then basically this approach should be workable.
3. Concerns:
  a. Refer to Coral project, there would be a default key in MP keyset which can't be shipped with projects. The purpose of it is just like a premp key in MP keyset for these developing projects.
     - Maybe we can indicate this status in the master config since it will only happened in uni-build (ex: in the firmware section, we can indicate key-id and it's status.).
  b. Similar case with 3-a, for non-unibuild device how to prevent factory put recovery image with pre-MP key into release partition.
     - Currently VERSION.signer can expose the name of keyset which can indicate the status of MP / PreMP?

Update the discussion with Nick offline:

1. What if SKU ID itself is wrong and indicate to the wrong OEM's model? Then we might ship the device with wrong OEM's key (if other config in HWID can't catch it out).

  - This should not happen because we encode SKU ID into HWID database. If SKU ID is out of this range then HWID verify will fail.

2. Is it possible that device is shipped with dev key (dev image in the release partition)?

  - No, dev key is a fixed value and we already check it in the `gooftool finalize`.

3. Is it possible that whitelabel_tag is wrong in a whitelabel project?

  - Yes, it is possible but this is the same issue of FW key in HWID so it is not caused by the approach here.

As the result, it looks like this approach is still workable. If anyone has other concern please let me know. Thanks.

it's not clear from the last few comments what you mean when you say "this approach".  there's been a lot of different ideas/variations posted here.

can you put together a doc or a markdown file so we can refer to it as the "final" answer so there's no uncertainty ?  this bug is great for discussion of ideas and pros/cons, but bugs are never great for documenting the final agreed upon decisions.

re#13,

What approaches I can see here are two only:
  1. Comment 3 & 11: Vapier's issue 343499 may be a good answer to this
  2. Description of issue

And Comment 10 and 11 shows 2 would be good to go after discussions. But yes, I indeed need to have a conclusion in the doc just as you mentioned. Thanks for the suggestion.

This bug has an owner, thus, it's been triaged. Changing status to "assigned".