New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 807222 link

Starred by 1 user

Issue metadata

Status: Duplicate
Merged: issue 760881
Owner:
Last visit > 30 days ago
Closed: Mar 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 3
Type: Feature



Sign in to add a comment

factory: Adds a gooftool sub-command to verify if the firmware key is premp/mp key

Project Member Reported by yhong@chromium.org, Jan 30 2018

Issue description

Currently the verification process is done by the HWID pytest.  But as it is not directly related to the HWID framework itself, it would be more clear to do the verification in `gooftool verify` instead of in `hwid verify`.
 

Comment 1 by yhong@chromium.org, Jan 30 2018

@hungte, could you give me some hint about obtaining key type (dev/premp/mp) from the release image partition?

Comment 2 by yhong@chromium.org, Jan 30 2018

Looks like we can get the key type by looking "VERSION.signer", which we can get by extracting the "chromeos-firmwareupdate" file.

Comment 3 by hungte@chromium.org, Jan 30 2018

Cc: chromeos-factory-eng@google.com
Components: Factory
You can try to grab a latest signed recovery build and see the contents of output from "chromeos-firmwareupdate -V", which should contain some info.

Also, as you've mentioned, VERSION.signer should tell some info as well.

If you need some better way, feel free to revise firmware updater.

Comment 4 by yhong@chromium.org, Jan 31 2018

For verifying if the release image is signed by mp keys, we can do following steps:
1. Mount the release image.
2. Extract the firmware by the command
   $ <release_rootfs>/usr/sbin/chromeos-firmwareupdate --sb_extract /tmp/tmpfolder
3. Grep if there's a string "Signed by.*<BoardName>MpKeys" inside "/tmp/tmpfolder/VERSION.signer"

Not sure if above steps are strong enough or not.


Also, for uni-build, we might also have to check if the signer name is correct or not.

Comment 5 by hungte@chromium.org, Jan 31 2018

Cc: stimim@chromium.org
I think checking VERSION.signer is good enough.

Comment 6 by hungte@chromium.org, Jan 31 2018

and we should log the hash of keys we've found as well.
also, it's even better if we can also check if the key hash is DEV (we do have hash for DEV keys), no matter what is filled in the VERSION.signer.

Comment 7 by yhong@chromium.org, Jan 31 2018

Do you mean checking if the ro firmware key hash is DEV or not?  We do check if the ro firmware key hash is DEV or not in Gooftool.VerifyKeys method.

Comment 8 by hungte@chromium.org, Jan 31 2018

I was thinking to check if the firmware has VERSION.signer as MP but it's actually modified with a DEV-signed image. Partner may do this unexpectedly when they receive instruction like 'let's change firmware to XXXX'.

But well, if VerifyKeys will catch DEV keys then I'm fine.
I has introduced a CL to put hash of loem keys into VERSION.signer as well. For whitelabel and uni-build, I think we can also verify that whether the rootkey in current firmware is the same with one noted in VERSION.signer based on model or loem name. In this case we can prevent firmware from been re-keyed to wrong one.

On the other hand, hwid database-builder might also support to read hash of rootkey from VERSION.signer so partner don't need to spend time on probing it from a real device after flashing firmware.
Cc: marcochen@chromium.org
Mergedinto: 760881
Status: Duplicate (was: Started)

Sign in to add a comment