[crypto] Allow certificate chains to be long-lived data structures
At present, certificate chain validation is treated as an
instantaneous process that can be carried out using only data that is
already in memory. This model does not allow for validation to
include non-instantaneous steps, such as downloading a cross-signing
certificate, or determining certificate revocation status via OCSP.
Redesign the internal representation of certificate chains to allow
chains to outlive the scope of the original source of certificates
(such as a TLS Certificate record).
Allow for certificates to be cached, so that each certificate needs to
be validated only once.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[crypto] Do not allow build-time cryptography settings to be overridden
If a root certificate has been explicitly specified at build time
using TRUST=/path/to/cert then do not allow this to be overridden even
from a trustworthy settings source (such as VMware GuestInfo).
Similarly, if a client certificate (and private key) has been
explicitly specified at build time, then do not allow it to be
overridden at runtime.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[crypto] Allow trusted root certificate to be changed without a rebuild
Changing the trusted root certificate currently requires a rebuild of
the iPXE binary, which may be inconvenient or impractical.
Allow the list of trusted root certificate fingerprints to be
overridden using the "trust" setting, but only at the point of iPXE
initialisation. This prevents untrusted sources of settings
(e.g. DHCP) from subverting the chain of trust, while allowing
trustworthy sources to change the trusted root certificate without
requiring a rebuild.
The basic idea is that if you are able to manipulate a trustworthy
source of settings (e.g. VMware GuestInfo or non-volatile stored
options), then you would be able to replace the iPXE binary anyway,
and so no security is lost by allowing such sources to override the
list of trusted root certificates.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Use explicit size in memset because 8 bytes must be set always.
This problem was reported by cppcheck.
Signed-off-by: Stefan Weil <sw@weilnetz.de>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[crypto] Add support for Cryptographic Message Syntax (PKCS #7)
The Cryptographic Message Syntax (PKCS#7) provides a format for
encapsulating digital signatures of arbitrary binary blobs. A
signature can be generated using
openssl cms -sign -in <file to sign> -binary -noattr \
-signer <signer>.crt -inkey <signer>.key -certfile <CA>.crt \
-outform DER -out <signature>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[crypto] Shrink raw certificate data to fit certificate
The certificate may be part of an ASN.1-encoded certificate chain, and
so may not be the only object contained within the ASN.1 cursor.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[crypto] Avoid an error when asn1_shrink() is already at end of object
asn1_skip() will return an error on reaching the end of an object, and
so should not be used as the basis for asn1_shrink().
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[crypto] Generalise X.509 OID-identified algorithm to asn1.c
The concept of an OID-identified algorithm as defined in X.509 is used
in some other standards (e.g. PKCS#7). Generalise this functionality
and provide it as part of the ASN.1 core.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[build] Allow a client certificate to be specified at build time
Allow a client certificate and corresponding private key to be
specified at build time using the syntax
make CERT=/path/to/certificate KEY=/path/to/key
The build process uses openssl to convert the files into DER format,
and includes them within the client certificate store in
clientcert.c. The build process will prompt for the private key
password if applicable.
Note that the private key is stored unencrypted, and so the resulting
iPXE binary (and the temporary files created during the build process)
should be treated as being equivalent to an unencrypted private key
file.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[crypto] Force caller to provide temporary storage for modular calculations
bigint_mod_multiply() and bigint_mod_exp() require a fixed amount of
temporary storage for intermediate results. (The amount of temporary
storage required depends upon the size of the integers involved.)
When performing calculations for 4096-bit RSA the amount of temporary
storage space required will exceed 2.5kB, which is too much to
allocate on the stack. Avoid this problem by forcing the caller to
allocate temporary storage.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[crypto] Use real prototypes for AXTLS' AES_encrypt() and AES_decrypt()
Avoid a compiler warning on some versions of gcc by using real
function prototypes.
Reported-by: Rob Shelley <Rob@cirris.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[crypto] Add big-integer library for RSA calculations
RSA requires modular exponentiation using arbitrarily large integers.
Given the sizes of the modulus and exponent, all required calculations
can be done without any further dynamic storage allocation. The x86
architecture allows for efficient large integer support via inline
assembly using the instructions that take advantage of the carry flag
(e.g. "adcl", "rcrl").
This implemention is approximately 80% smaller than the (more generic)
AXTLS implementation.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[crypto] Upgrade AES and RSA code to upstream axTLS version 1.4.5
All axTLS files are now vanilla versions of the upstream axTLS files,
with one minor exception: the unused "ctx" parameter of
bi_int_divide() has been marked with "__unused" to avoid a compilation
error.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Replace MD5 implementation with one which is around 20% smaller. This
implementation has been verified using the existing MD5 self-tests.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Replace SHA-1 implementation from AXTLS with a dedicated iPXE
implementation which is around 40% smaller. This implementation has
been verified using the existing SHA-1 self-tests (including the NIST
SHA-1 test vectors).
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[rng] Add get_random_nz() function required by RSA algorithm
RSA requires the generation of random non-zero bytes (i.e. a sequence
of random numbers in the range [0x01,0xff]). ANS X9.82 provides
various Approved methods for converting random bits into random
numbers. The simplest such method is the Simple Discard Method.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
ANS X9.82 specifies that the start-up tests shall consist of at least
one full cycle of the continuous tests.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Michael Brown