1libsecureboot 2************* 3 4This library depends one way or another on verifying detached digital 5signatures. 6To do that, the necessary trust anchors need to be available. 7 8The simplest (and most attractive for an embedded system) is to 9capture them in this library. 10 11The makefile ``local.trust.mk`` is responsible for doing that. 12The file provided is just an example and depends on the environment 13here at Juniper. 14 15Within Juniper we use signing servers, which apart from signing things 16provide access to the necessary trust anchors. 17That signing server is freely available - see 18http://www.crufty.net/sjg/docs/signing-server.htm 19 20X.509 certificate chains offer a lot of flexibility over time and are 21a great solution for an embedded vendor like Juniper or even 22FreeBSD.org, but are probably overkill for personal or small site use. 23 24Setting up a CA for this is rather involved so I'll just provide a 25link below to suitable tutorial below. 26 27Using OpenPGP is much simpler. 28 29 30OpenPGP 31======== 32 33This is very simple to setup and use. 34 35An RSA key pair can be generated with:: 36 37 GNUPGHOME=$PWD/.gnupg gpg --openpgp \ 38 --quick-generate-key --batch --passphrase '' "keyname" RSA 39 40The use of ``GNUPGHOME=$PWD/.gnupg`` just avoids messing with personal 41keyrings. 42We can list the resulting key:: 43 44 GNUPGHOME=$PWD/.gnupg gpg --openpgp --list-keys 45 46 gpg: WARNING: unsafe permissions on homedir 47 '/h/sjg/openpgp/.gnupg' 48 gpg: Warning: using insecure memory! 49 /h/sjg/openpgp/.gnupg/pubring.kbx 50 --------------------------------- 51 pub rsa2048 2018-03-26 [SC] [expires: 2020-03-25] 52 AB39B111E40DD019E0E7C171ACA72B4719FD2523 53 uid [ultimate] OpenPGPtest 54 55The ``keyID`` we want later will be the last 8 octets 56(``ACA72B4719FD2523``) 57This is what we will use for looking up the key. 58 59We can then export the private and public keys:: 60 61 GNUPGHOME=$PWD/.gnupg gpg --openpgp \ 62 --export --armor > ACA72B4719FD2523.pub.asc 63 GNUPGHOME=$PWD/.gnupg gpg --openpgp \ 64 --export-secret-keys --armor > ACA72B4719FD2523.sec.asc 65 66The public key ``ACA72B4719FD2523.pub.asc`` is what we want to 67embed in this library. 68If you look at the ``ta_asc.h`` target in ``openpgp/Makefile.inc`` 69we want the trust anchor in a file named ``t*.asc`` 70eg. ``ta_openpgp.asc``. 71 72The ``ta_asc.h`` target will capture all such ``t*.asc`` into that 73header. 74 75Signatures 76---------- 77 78We expect ascii armored (``.asc``) detached signatures 79Eg.:: 80 81 gpg -a --detach-sign manifest 82 83should produce the expected signature in ``manifest.asc`` 84 85We only support version 4 signatures using RSA (the default for ``gpg``). 86 87 88OpenSSL 89======== 90 91The basic idea here is to setup a private CA. 92 93There are lots of good tutorials on available on this topic; 94just google *setup openssl ca*. 95A good example is https://jamielinux.com/docs/openssl-certificate-authority/ 96 97All we need for this library is a copy of the PEM encoded root CA 98certificate (trust anchor). This is expected to be in a file named 99``t*.pem`` eg. ``ta_rsa.pem``. 100 101The ``ta.h`` target in ``Makefile.inc`` will combine all such 102``t*.pem`` files into that header. 103 104Signatures 105---------- 106 107For Junos we currently use EC DSA signatures with file extension 108``.esig`` so the signature for ``manifest`` would be ``manifest.esig`` 109 110This was the first signature method we used with the remote signing 111servers and it ends up being a signature of a hash. 112Ie. client sends a hash which during signing gets hashed again. 113So for Junos we define VE_ECDSA_HASH_AGAIN which causes ``verify_ec`` 114to hash again. 115 116Later I added a FakeHash class to the signing server so we could 117generate signatures compatible with our previous RSA scheme and 118others. 119 120Otherwise our EC DSA and RSA signatures are the default used by 121OpenSSL - an original design goal was that a customer could verify our 122signatures using nothing but an ``openssl`` binary. 123 124 125Self tests 126========== 127 128If you want the ``loader`` to perform self-test of a given signature 129verification method on startup (a must for FIPS 140-2 certification) 130you need to provide a suitable file signed by each supported trust 131anchor. 132 133These should be stored in files with names that start with ``v`` and 134have the same extension as the corresponding trust anchor. 135Eg. for ``ta_openpgp.asc`` we use ``vc_openpgp.asc`` 136and for ``ta_rsa.pem`` we use ``vc_rsa.pem``. 137 138Note for the X.509 case we simply extract the 2nd last certificate 139from the relevant chain - which is sure to be a valid certificate 140signed by the corresponding trust anchor. 141 142-------------------- 143