123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175 |
- This directory contains a reference implementation for Chrome OS
- verified boot in firmware.
- ----------
- Directory Structure
- ----------
- The source is organized into distinct modules -
- firmware/
- Contains ONLY the code required by the BIOS to validate the secure boot
- components. There shouldn't be any code in here that signs or generates
- images. BIOS should require ONLY this directory to implement secure boot.
- Refer to firmware/README for futher details.
- cgpt/
- Utility to read/write/modify GPT partitions. Similar to GNU parted or any
- other GPT tool, but this has support for Chrome OS extensions.
- host/
- Miscellaneous functions needed by userland utilities.
- futility/
- The "firmware utility" tool, used to create, sign, and validate Chrome OS
- images.
- utility/
- Random other utilities, not necesssarily related to verified boot as such.
- tests/
- User-land tests and benchmarks that test the reference implementation.
- Please have a look at these if you'd like to understand how to use the
- reference implementation.
- build/
- The output directory where the generated files will be placed, and where
- tests are run.
- scripts/
- Tools and scripts used to generate and use new signing keypairs. These are
- typically used only on a secure machine.
- --------------------
- Building and testing
- --------------------
- The suite can be built on the host or in the chroot environment.
- Building on the host could fail if certain packages are not installed. If
- there are host environment build problems due to missing .h files, try
- researching what packages the files belong to and install the missing packages
- before reporting a problem.
- The commands are the more-or-less expected ones:
- make
- make runtests
- make install [ DESTDIR=/usr/local ]
- ----------
- Some useful utilities:
- ----------
- futility vbutil_key Convert a public key into .vbpubk format
- futility vbutil_keyblock Wrap a public key inside a signature and checksum
- futility vbutil_firmware Create a .vblock with signature info for a
- firmware image
- futility vbutil_kernel Pack a kernel image, bootloader, and config into
- a signed binary
- dumpRSAPublicKey Dump RSA Public key (from a DER-encoded X509
- certificate) in a format suitable for use by
- RSAVerify* functions in crypto/.
- verify_data.c Verify a given signature on a given file.
- ----------
- Generating a signed firmware image:
- ----------
- * Step 0: Build the tools, install them somewhere.
- * Step 1: Generate RSA root and signing keys.
- The root key is always 8192 bits.
- $ openssl genrsa -F4 -out root_key.pem 8192
- The signing key can be between 1024-8192 bits.
- $ openssl genrsa -F4 -out signing_key.pem <1024|2048|4096|8192>
- Note: The -F4 option must be specified to generate RSA keys with a public
- exponent of 65535. RSA keys with 3 as a public exponent (the default)
- won't work.
- * Step 2: Generate pre-processed public versions of the above keys using
- dumpRSAPublicKey. This utility expects an x509 certificate as
- input, and emits an intermediate representation for further
- processing.
- $ openssl req -batch -new -x509 -key root_key.pem -out root_key.crt
- $ openssl req -batch -new -x509 -key signing_key.pem -out signing_key.crt
- $ dumpRSAPublicKey root_key.crt > root_key.keyb
- $ dumpRSAPublicKey signing_key.crt > signing_key.keyb
- ************** TODO: STUFF PAST HERE IS OUT OF DATE ***************
- At this point we have all the requisite keys needed to generate a signed
- firmware image.
- .pem RSA Public/Private Key Pair
- .crt X509 Key Certificate
- .keyb Pre-processed RSA Public Key
- * Step 3: Use utility/firmware_utility to generate a signed firmare blob.
- $ utility/firmware_utility --generate \
- --root_key root_key.pem \
- --firmware_sign_key signing_key.pem \
- --firmware_sign_key_pub signing_key.keyb \
- --firmware_sign_algorithm <algoid> \
- --firmware_key_version 1 \
- --firmware_version 1 \
- --in <firmware blob file> \
- --out <output file>
- Where <algoid> is based on the signature algorithm to use for firmware
- signining. The list of <algoid> specifications can be output by running
- 'utility/firmware_utility' without any arguments.
- Note: --firmware_key_version and --firmware_version are part of a signed
- image and are used to prevent rollbacks to older version. For testing,
- they can just be set to valid values.
- * Step 4: Verify that this image verifies.
- $ utility/firmware_utility --verify \
- --in <signed firmware image>
- --root_key_pub root_key.keyb
- Verification SUCCESS.
- Note: The verification functions expects a pointer to the
- pre-processed public root key as input. For testing purposes,
- root_key.keyb can be stored in RW part of the firmware. For the
- final firmware, this will be a fixed public key which cannot be
- changed and must be stored in RO firmware.
- ----------
- Generating a signed kernel image:
- ----------
- The steps for generating a signed kernel image are similar to that of
- a firmware image. Since verification is chained - RO firmware verifies
- RW firmware which verifies the kernel, only the keys change. An additional
- kernel signing key must be generated. The firmware signing generated above
- is the root key equivalent for signed kernel images.
|