From a641f31a2940c609e52251cd3c4e4cb4b774d6bf Mon Sep 17 00:00:00 2001 From: Daniel Micay Date: Tue, 17 Mar 2020 21:35:44 -0400 Subject: [PATCH] add more information on encryption signing keys --- static/build.html | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/static/build.html b/static/build.html index 6951782b..79ea1a50 100644 --- a/static/build.html +++ b/static/build.html @@ -427,12 +427,19 @@ mv vendor/android-prepare-vendor/DEVICE/BUILD_ID/vendor/google_devices/* vendor/ factory reset. Note that the keys are used for a lot more than simply verifying updates and verified boot.

-

You should set a passphrase for the signing keys to protect them at rest. The - GrapheneOS release signing script expects the same passphrase to be used for each of - the keys. If you use swap, make sure that it's encrypted to avoid leaking unencrypted - keys to storage.

+

The sample certificate subject (CN=GrapheneOS) should be replaced with + your own information.

-

The sample certificate subject should be replaced with your own information.

+

You should set a passphrase for the signing keys to keep them at rest until you + need to sign a release with them. By default, the keys are encrypted using scrypt for + key derivation and AES256 as the cipher. If you use swap, make sure it's encrypted, + ideally with an ephemeral key rather a persistent key to support hibernation. Even + with an ephemeral key, swap will reduce the security gained from encrypting the keys + since it breaks the guarantee that they become at rest as soon as the signing process + is finished. Consider disabling swap, at least during the signing process.

+ +

The encryption passphrase for all the keys generated for a device needs to + match.

To generate keys for crosshatch (you should use unique keys per device variant):