ImageSigning

SecureBoot in Ubuntu (Image signing)

Introduction

There are two different ways an image can be signed:

How an image is signed depends on what is available in the UEFI db.

Canonical only

  • Requirement: Canonical's master CA is in db.

  • When to use: when OEM is willing to ship Canonical's key and the firmware is known to not support verifying another entry in the PE/COFF certificate table.
  • Pros: Autonomy (we control our keys), allows for preventing Windows boot, no dependency on Microsoft
  • Cons: OEM must add entry to db

OpenSSL by default creates certificates in PEM format. For maximum interoperability with OEMs we want to create a DER encoded PKCS#7 certificate to include in the PE/COFF certificate table. This certificate should include the master certificate and the signing certificate.

  1. Create the DER encoded PKCS#7 certificate:

    $ openssl crl2pkcs7 -nocrl -certfile ./archive-subkey-public.crt -certfile ./master-public.pem -outform DER -out canonical-signing-cert.pkcs7

  2. Verify PKCS#7 DER certificate for correctness (output is for example purposes):

    $ openssl pkcs7 -in ./canonical-signing-cert.pkcs7 -inform DER -text -print_certs -noout
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1 (0x1)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=UK, ST=England, L=London, O=Canonical Ltd., OU=Secure Boot, CN=Canonical Ltd. Master Certificate Authority Example
        Validity
            Not Before: Feb 28 22:37:47 2012 GMT
            Not After : Feb 27 22:37:47 2027 GMT
        Subject: C=UK, ST=England, O=Canonical Ltd., OU=Secure Boot, CN=Canonical Ltd. Archive Signing Example
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:cd:a2:1f:62:70:27:db:f5:cf:9c:17:6c:9b:20:
                    48:a1:7a:4c:2a:e4:2b:bb:60:30:9d:7d:13:d9:53:
                    0f:8a:bc:1e:5e:18:b5:c5:05:54:19:52:95:44:f6:
                    71:e1:33:de:68:1b:8d:c8:3e:88:3a:a6:42:07:05:
                    0c:e9:0e:a4:ff:87:38:d3:11:0e:a4:ff:f5:26:83:
                    99:af:fa:81:ba:0a:d6:e8:e8:c0:0c:85:cc:7d:66:
                    15:bf:74:59:83:65:55:aa:3e:dc:eb:66:74:8a:ef:
                    5d:7b:01:db:02:9f:ea:77:29:b7:dc:23:f3:21:e6:
                    9d:5b:32:a4:77:f2:15:5c:02:58:ae:b4:89:b7:48:
                    41:06:1c:86:28:e0:39:da:2b:6f:df:19:18:20:c2:
                    f9:25:e8:72:16:4d:67:43:b0:eb:f8:1a:2f:ac:64:
                    8d:cf:3d:5a:7a:bd:a3:e2:83:1b:57:18:66:19:6e:
                    b1:30:f0:00:33:37:7c:33:56:8a:8c:fb:e4:6e:c4:
                    f0:9f:3a:5b:21:6a:3f:85:50:31:40:33:0b:e3:eb:
                    09:c1:30:14:a0:be:13:cc:b9:60:0a:e9:e7:ec:6f:
                    a0:40:c0:5d:e4:9c:aa:4a:01:a2:4d:f4:f4:f5:b0:
                    9f:7a:df:83:0e:5a:d4:81:cf:b2:5a:15:ad:20:08:
                    59:f3
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Extended Key Usage: 
                Code Signing, 1.3.6.1.4.1.311.10.3.6
            Netscape Comment: 
                OpenSSL Generated Certificate
            X509v3 Subject Key Identifier: 
                C0:99:69:8A:F8:10:38:53:72:1C:96:8E:D0:EB:50:9A:91:B9:96:1C
            X509v3 Authority Key Identifier: 
                keyid:50:F4:8B:B0:52:4E:25:14:48:79:7B:E6:A1:8A:E2:26:6D:2A:18:A3

    Signature Algorithm: sha256WithRSAEncryption
        b0:14:e3:01:51:12:d4:b5:d8:51:a5:1b:db:bd:a3:02:ad:b4:
        87:26:09:10:c2:0c:55:93:c4:97:53:01:c0:13:cc:91:43:96:
        3a:0a:6d:ef:36:f1:55:3f:b6:83:ed:fd:5a:b6:b6:ce:98:35:
        ab:61:38:70:66:ab:54:4d:96:36:85:30:89:98:19:d6:03:06:
        a4:eb:9d:3c:ee:60:2d:5d:9d:4d:80:11:9d:0e:9c:a1:ad:ec:
        84:72:5f:cb:24:f0:50:4c:bc:e2:8d:3b:ca:36:1c:c2:15:94:
        04:cf:d2:21:94:37:1d:85:b7:a3:39:21:5f:e7:ac:69:f7:23:
        4f:5d:45:52:eb:2e:94:d2:f4:f7:85:ea:85:90:7a:24:fa:0d:
        9a:41:a6:b4:25:7e:60:38:2e:32:25:c7:7f:40:c6:7f:c2:88:
        85:d8:38:67:31:96:b8:ca:2b:c0:95:1b:8b:d9:8a:6e:57:62:
        7b:1e:89:16:ac:79:ce:b7:2c:8b:c9:c7:74:f0:39:ef:70:6c:
        26:af:87:a2:a0:97:25:41:35:77:27:b7:10:f0:6b:04:16:38:
        fa:cb:f9:68:c3:37:31:ed:09:b8:25:ac:f3:6f:76:ff:3b:5c:
        91:19:1d:06:eb:a9:e3:c8:41:56:1d:95:dc:30:f9:67:89:16:
        ec:35:85:80

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            85:70:3c:04:b8:e2:b4:b9
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=UK, ST=England, L=London, O=Canonical Ltd., OU=Secure Boot, CN=Canonical Ltd. Master Certificate Authority Example
        Validity
            Not Before: Feb 28 22:13:53 2012 GMT
            Not After : Feb 27 22:13:53 2027 GMT
        Subject: C=UK, ST=England, L=London, O=Canonical Ltd., OU=Secure Boot, CN=Canonical Ltd. Master Certificate Authority Example
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:ce:1f:25:08:3a:4b:b6:93:b0:bf:14:50:04:26:
                    9a:e1:7c:26:63:d9:fc:d3:8a:96:fa:5e:b5:88:5d:
                    01:31:b0:77:c7:5f:50:a8:9c:d1:72:e0:93:81:5e:
                    de:78:33:64:ac:9b:4f:31:11:44:3b:3b:fd:fa:0f:
                    f3:81:b4:66:72:21:4e:54:cd:6b:a3:52:0e:08:2f:
                    fc:cf:b7:a3:0f:ef:7f:80:d8:72:b0:7c:42:b5:26:
                    b8:46:9c:b5:0d:a5:48:76:d6:47:6e:3a:2b:c5:0b:
                    2f:87:73:0e:a7:59:8d:ed:0f:03:6c:e4:d3:47:fe:
                    26:ec:21:e2:a5:f4:f3:b1:87:a8:7d:3b:13:30:83:
                    49:9b:ce:a9:59:d9:45:b4:e6:68:88:d8:3a:df:91:
                    86:4e:78:ae:e5:09:16:55:d4:e6:de:19:a4:57:92:
                    00:e7:80:ca:a7:e0:ab:4d:4c:ca:f5:e4:41:7b:cd:
                    64:b5:d2:c6:ca:24:e3:ca:b3:ad:58:05:3f:e1:4e:
                    6a:e7:3d:e3:aa:a2:19:e4:b6:e5:f9:8d:d6:bd:46:
                    60:5d:44:f1:52:ae:40:fa:5c:64:45:73:ca:f8:79:
                    09:a0:56:26:5a:0f:dc:cb:f6:8f:c7:2f:df:59:ad:
                    c5:ea:9f:66:14:c2:7e:9c:66:70:bf:c4:07:83:29:
                    89:e5
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier: 
                50:F4:8B:B0:52:4E:25:14:48:79:7B:E6:A1:8A:E2:26:6D:2A:18:A3
            X509v3 Authority Key Identifier: 
                keyid:50:F4:8B:B0:52:4E:25:14:48:79:7B:E6:A1:8A:E2:26:6D:2A:18:A3

            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Key Usage: 
                Digital Signature, Certificate Sign, CRL Sign
    Signature Algorithm: sha256WithRSAEncryption
        16:c7:0b:98:9d:f5:bd:c4:1c:17:02:94:02:34:a2:44:fb:88:
        f0:51:02:21:a4:93:ca:0e:7e:fe:32:10:c1:45:cf:33:08:15:
        d9:29:49:c3:ee:28:d7:b6:f0:88:bf:ba:6e:78:23:83:72:2a:
        72:99:1b:36:45:ab:4b:ba:42:50:40:3d:84:fe:7d:ae:c3:94:
        46:62:05:06:77:33:ab:2f:e1:4a:7a:d2:48:53:e7:e1:c9:c0:
        68:45:08:30:47:b1:23:3a:ab:f6:d3:ab:c0:b9:4d:b0:ee:50:
        2b:a5:d0:be:51:5c:3b:ed:d9:79:98:e9:38:c9:7a:b6:8d:a8:
        fa:66:9b:5e:17:b1:28:6f:21:32:4f:44:36:51:93:d7:3e:47:
        2e:10:3d:c3:f6:4a:f3:e9:bd:a1:71:0e:d3:7b:86:a1:73:4b:
        63:af:74:26:82:1d:cc:03:38:2f:3c:11:91:b8:4d:a8:ef:e3:
        29:67:29:41:e9:66:85:e1:10:e0:b0:3f:b8:cd:2f:a3:10:da:
        80:5a:da:69:1e:db:35:66:5c:0e:ca:32:94:62:c4:5b:58:8b:
        2d:71:cf:74:cd:51:40:85:29:0d:ea:9b:59:9d:db:bc:86:22:
        49:2e:8f:cd:14:6c:ac:db:df:d4:ab:c8:53:ec:55:34:90:4a:
        d8:48:36:05

  3. Sign the image with the signing private key (pseudocode):

    $ signing-tool --sign --private-key=./private/archive-subkey-private.key --cert=./archive-subkey-public.crt --ca=./master-public.pkcs7 <PE/COFF image>

  4. Verify the image signature (pseudocode):

    $ signing-tool --verify --ca=./master-public.pkcs7 ... <PE/COFF image>

Note that the signing tool must do the verification since it must skip the embedded signature when performing verification of the PE/COFF image. It should:

  • perform a hash calculation on the image and verify it matches the one in the embedded signature using the:
    • public key of the signing certificate on disk
    • public key of the signing certificate extracted from the embedded certificate
  • verify that --ca matches the master certificate embedded in the image
  • verify the certificate chain for the embedded certificate used to sign the image (ie, the signing certificate) and that it verifies up to the master certificate

NOTE: depending on the implementation of the signing tool, this certificate could be pre-genereated and given as an argument to the signing tool or generated dynamically by the tool during the signing process (with the master and signing certificates given as arguments).

TODO: update the signing procedures to use the actual command instead of pseudo-code

WinQual only

  • Requirement: WinQual signing certificate/key

  • When to use: when OEM is unwilling to ship Canonical's key and the firmware is known to not support verifying another entry in the PE/COFF certificate table.
  • Pros: widespread support (OEMs need only include Microsoft's entry in db), easy
  • Cons: Dependency on Microsoft, does not allow for preventing Windows boot, very limited flexibility with bootloader

Signing consists of signing the bootloader binary with our WinQual certificate, submitting this via the WinQual program. After some time, the image is verified and then Canonical receives a Microsoft-signed binary and updates the bootloader packaging to include it. This binary is used to boot the kernel directly.

WinQual-signed 1st stage (shim) and Canonical-signed 2nd stage (efilinux/grub2) (default)

  • Requirement: WinQual signing certificate/key, SecurityTeam/SecureBoot/KeyGeneration

  • When to use: when OEM is unwilling to ship Canonical's key and the firmware is known to not support verifying another entry in the PE/COFF certificate table.
  • Pros: widespread support (OEMs need only include Microsoft's entry in db), easy, provides more
  • Cons: Dependency on Microsoft, does not allow for preventing Windows boot

Signing consists of signing the 1st stage bootloader binary with our WinQual certificate, submitting this via the WinQual program. After some time, the image is verified and then Canonical receives a Microsoft-signed binary and updates the bootloader packaging to include it. This binary is used to boot a 2nd stage bootloader which is Canonical-signed. This second stage is signed using the same procedures as 'Canonical-only' (above).

Canonical and WinQual (historical)

Previous discussions assumed that the WinQual key pair would act as a sort of intermediate CA and did not require the round-trip through Microsoft's WinQual program, and thus allowed for Canonical to use a shared private key with different x509 certificates. While this was a novel idea and presented several advantages, because the PE/COFF specification only allows for one embedded signature and that Microsoft's WinQual program insists that the embedded signature be created with their key, this is no longer a possibility.

UEFI/SecureBoot/KeyManagement/ImageSigning (last edited 2017-12-04 22:05:09 by cyphermox)