[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>
OIDs are theoretically part of a global hierarchy. However, the
hierarchy is sufficiently disorganised as to be essentially
meaningless for all purposes other than guaranteeing uniqueness.
Ignore the hierarchical nature of OIDs and treat them as opaque.
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>
[tls] Treat handshake digest algorithm as a session parameter
Simplify code by recording the active handshake digest algorithm as a
session parameter. (Note that we must still accumulate digests for
all supported algorithms, since we don't know which digest will
eventually be used until we receive the Server Hello.)
Signed-off-by: Michael Brown <mcb30@ipxe.org>
TLSv1.1 and earlier use a hybrid of MD5 and SHA-1 to generate digests
over the handshake messages. Formalise this as a separate digest
algorithm "md5+sha1".
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Validate the server certificate against the trusted root certificate
store. The server must provide a complete certificate chain, up to
and including the trusted root certificate that is embedded into iPXE.
Note that the date and time are not yet validated.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[build] Allow trusted root certificates to be specified at build time
Allow trusted root certificates to be specified at build time using
the syntax
make TRUST=/path/to/certificate1,/path/to/certificate2,...
The build process uses openssl to calculate the SHA-256 fingerprints
of the specified certificates, and adds them to the root certificate
store in rootcert.c. The certificates can be in any format understood
by openssl.
The certificates may be server certificates or (more usefully) CA
certificates.
If no trusted certificates are specified, then the default "iPXE root
CA" certificate will be used.
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>
Michael Brown