06 Apr, 2016
3 commits
-
Extract the signature digest for an X.509 certificate earlier, at the end
of x509_cert_parse() rather than leaving it to the callers thereof since it
has to be called anyway.Further, immediately after that, check the signature on self-signed
certificates, also rather in the callers of x509_cert_parse().We note in the x509_certificate struct the following bits of information:
(1) Whether the signature is self-signed (even if we can't check the
signature due to missing crypto).(2) Whether the key held in the certificate needs unsupported crypto to be
used. We may get a PKCS#7 message with X.509 certs that we can't make
use of - we just ignore them and give ENOPKG at the end it we couldn't
verify anything if at least one of these unusable certs are in the
chain of trust.(3) Whether the signature held in the certificate needs unsupported crypto
to be checked. We can still use the key held in this certificate,
even if we can't check the signature on it - if it is held in the
system trusted keyring, for instance. We just can't add it to a ring
of trusted keys or follow it further up the chain of trust.Making these checks earlier allows x509_check_signature() to be removed and
replaced with direct calls to public_key_verify_signature().Signed-off-by: David Howells
-
Retain the key verification data (ie. the struct public_key_signature)
including the digest and the key identifiers.Note that this means that we need to take a separate copy of the digest in
x509_get_sig_params() rather than lumping it in with the crypto layer data.Signed-off-by: David Howells
-
Allow authentication data to be stored in an asymmetric key in the 4th
element of the key payload and provide a way for it to be destroyed.For the public key subtype, this will be a public_key_signature struct.
Signed-off-by: David Howells
04 Mar, 2016
1 commit
-
Make the identifier public key and digest algorithm fields text instead of
enum.Signed-off-by: David Howells
Acked-by: Herbert Xu
29 Feb, 2016
3 commits
-
The ASN.1 GeneralizedTime object carries an ISO 8601 format date and time.
The time is permitted to show midnight as 00:00 or 24:00 (the latter being
equivalent of 00:00 of the following day).The permitted value is checked in x509_decode_time() but the actual
handling is left to mktime64().Without this patch, certain X.509 certificates will be rejected and could
lead to an unbootable kernel.Note that with this patch we also permit any 24:mm:ss time and extend this
to UTCTime, which whilst not strictly correct don't permit much leeway in
fiddling date strings.Reported-by: Rudolf Polzer
Signed-off-by: David Howells
Acked-by: Arnd Bergmann
cc: David Woodhouse
cc: John Stultz -
The format of ASN.1 GeneralizedTime seems to be specified by ISO 8601
[X.680 46.3] and this apparently supports leap seconds (ie. the seconds
field is 60). It's not entirely clear that ASN.1 expects it, but we can
relax the seconds check slightly for GeneralizedTime.This results in us passing a time with sec as 60 to mktime64(), which
handles it as being a duplicate of the 0th second of the next minute.We can't really do otherwise without giving the kernel much greater
knowledge of where all the leap seconds are. Unfortunately, this would
require change the mapping of the kernel's current-time-in-seconds.UTCTime, however, only supports a seconds value in the range 00-59, but for
the sake of simplicity allow this with UTCTime also.Without this patch, certain X.509 certificates will be rejected,
potentially making a kernel unbootable.Reported-by: Rudolf Polzer
Signed-off-by: David Howells
Acked-by: Arnd Bergmann
cc: David Woodhouse
cc: John Stultz -
There are still a couple of minor issues in the X.509 leap year handling:
(1) To avoid doing a modulus-by-400 in addition to a modulus-by-100 when
determining whether the year is a leap year or not, I divided the year
by 100 after doing the modulus-by-100, thereby letting the compiler do
one instruction for both, and then did a modulus-by-4.Unfortunately, I then passed the now-modified year value to mktime64()
to construct a time value.Since this isn't a fast path and since mktime64() does a bunch of
divisions, just condense down to "% 400". It's also easier to read.(2) The default month length for any February where the year doesn't
divide by four exactly is obtained from the month_length[] array where
the value is 29, not 28.This is fixed by altering the table.
Reported-by: Rudolf Polzer
Signed-off-by: David Howells
Acked-by: David Woodhouse
Acked-by: Arnd Bergmann
cc: stable@vger.kernel.org
10 Feb, 2016
1 commit
-
This patch converts the module verification code to the new akcipher API.
Signed-off-by: Tadeusz Struk
Acked-by: Herbert Xu
Signed-off-by: David Howells
12 Nov, 2015
1 commit
-
This fixes CVE-2015-5327. It affects kernels from 4.3-rc1 onwards.
Fix the X.509 time validation to use month number-1 when looking up the
number of days in that month. Also put the month number validation before
doing the lookup so as not to risk overrunning the array.This can be tested by doing the following:
cat <
Signed-off-by: David Howells
Tested-by: Mimi Zohar
Acked-by: David Woodhouse
Signed-off-by: James Morris
21 Sep, 2015
1 commit
-
hour, min and sec are unsigned int and they can never be less than zero.
Signed-off-by: Sudip Mukherjee
Signed-off-by: Herbert Xu
13 Aug, 2015
2 commits
-
Make the X.509 ASN.1 time object decoder fill in a time64_t rather than a
struct tm to make comparison easier (unfortunately, this makes readable
display less easy) and export it so that it can be used by the PKCS#7 code
too.Further, tighten up its parsing to reject invalid dates (eg. weird
characters, non-existent hour numbers) and unsupported dates (eg. timezones
other than 'Z' or dates earlier than 1970).Signed-off-by: David Howells
Reviewed-by: David Woodhouse -
The key identifiers fabricated from an X.509 certificate are currently:
(A) Concatenation of serial number and issuer
(B) Concatenation of subject and subjectKeyID (SKID)
When verifying one X.509 certificate with another, the AKID in the target
can be used to match the authoritative certificate. The AKID can specify
the match in one or both of two ways:(1) Compare authorityCertSerialNumber and authorityCertIssuer from the AKID
to identifier (A) above.(2) Compare keyIdentifier from the AKID plus the issuer from the target
certificate to identifier (B) above.When verifying a PKCS#7 message, the only available comparison is between
the IssuerAndSerialNumber field and identifier (A) above.However, a subsequent patch adds CMS support. Whilst CMS still supports a
match on IssuerAndSerialNumber as for PKCS#7, it also supports an
alternative - which is the SubjectKeyIdentifier field. This is used to
match to an X.509 certificate on the SKID alone. No subject information is
available to be used.To this end change the fabrication of (B) above to be from the X.509 SKID
alone. The AKID in keyIdentifier form then only matches on that and does
not include the issuer.Signed-off-by: David Howells
Reviewed-By: David Woodhouse
07 Aug, 2015
1 commit
-
Extract both parts of the AuthorityKeyIdentifier, not just the keyIdentifier,
as the second part can be used to match X.509 certificates by issuer and
serialNumber.Signed-off-by: David Howells
Tested-by: Vivek Goyal
06 Oct, 2014
1 commit
-
Earlier KEYS code used pure subject key identifiers (fingerprint)
for searching keys. Latest merged code removed that and broke
compatibility with integrity subsytem signatures and original
format of module signatures.This patch returns back partial matching on SKID.
Reported-by: Dmitry Kasatkin
Signed-off-by: Dmitry Kasatkin
Signed-off-by: David Howells
03 Oct, 2014
1 commit
-
Module signing matches keys by comparing against the key description exactly.
However, the way the key description gets constructed got changed to be
composed of the subject name plus the certificate serial number instead of the
subject name and the subjectKeyId. I changed this to avoid problems with
certificates that don't *have* a subjectKeyId.Instead, if available, use the raw subjectKeyId to form the key description
and only use the serial number if the subjectKeyId doesn't exist.Reported-by: Dmitry Kasatkin
Signed-off-by: David Howells
17 Sep, 2014
1 commit
-
Make use of the new match string preparsing to overhaul key identification
when searching for asymmetric keys. The following changes are made:(1) Use the previously created asymmetric_key_id struct to hold the following
key IDs derived from the X.509 certificate or PKCS#7 message:id: serial number + issuer
skid: subjKeyId + subject
authority: authKeyId + issuer(2) Replace the hex fingerprint attached to key->type_data[1] with an
asymmetric_key_ids struct containing the id and the skid (if present).(3) Make the asymmetric_type match data preparse select one of two searches:
(a) An iterative search for the key ID given if prefixed with "id:". The
prefix is expected to be followed by a hex string giving the ID to
search for. The criterion key ID is checked against all key IDs
recorded on the key.(b) A direct search if the key ID is not prefixed with "id:". This will
look for an exact match on the key description.(4) Make x509_request_asymmetric_key() take a key ID. This is then converted
into "id:" and passed into keyring_search() where match preparsing
will turn it back into a binary ID.(5) X.509 certificate verification then takes the authority key ID and looks
up a key that matches it to find the public key for the certificate
signature.(6) PKCS#7 certificate verification then takes the id key ID and looks up a
key that matches it to find the public key for the signed information
block signature.Additional changes:
(1) Multiple subjKeyId and authKeyId values on an X.509 certificate cause the
cert to be rejected with -EBADMSG.(2) The 'fingerprint' ID is gone. This was primarily intended to convey PGP
public key fingerprints. If PGP is supported in future, this should
generate a key ID that carries the fingerprint.(3) Th ca_keyid= kernel command line option is now converted to a key ID and
used to match the authority key ID. Possibly this should only match the
actual authKeyId part and not the issuer as well.Signed-off-by: David Howells
Acked-by: Vivek Goyal
03 Jul, 2014
1 commit
-
Export certificate parse and free functions for use by modules.
Signed-off-by: David Howells
Acked-by: Vivek Goyal
Reviewed-by: Kees Cook
Reviewed-by: Josh Boyer
01 Jul, 2014
1 commit
-
PKCS#7 validation requires access to the serial number and the raw names in an
X.509 certificate.Signed-off-by: David Howells
Reviewed-by: Kees Cook
Reviewed-by: Josh Boyer
26 Oct, 2013
1 commit
-
This patch makes use of the newly defined common hash algorithm info,
replacing, for example, PKEY_HASH with HASH_ALGO.Changelog:
- Lindent fixes - MimiCC: David Howells
Signed-off-by: Dmitry Kasatkin
Signed-off-by: Mimi Zohar
26 Sep, 2013
2 commits
-
Embed a public_key_signature struct in struct x509_certificate, eliminating
now unnecessary fields, and split x509_check_signature() to create a filler
function for it that attaches a digest of the signed data and an MPI that
represents the signature data. x509_free_certificate() is then modified to
deal with these.Whilst we're at it, export both x509_check_signature() and the new
x509_get_sig_params().Signed-off-by: David Howells
Reviewed-by: Kees Cook
Reviewed-by: Josh Boyer -
Store public key algo ID in public_key struct for reference purposes. This
allows it to be removed from the x509_certificate struct and used to find a
default in public_key_verify_signature().Signed-off-by: David Howells
Reviewed-by: Kees Cook
Reviewed-by: Josh Boyer
22 Apr, 2013
1 commit
-
Per X.509 spec in 4.2.1.1 section, the structure of Authority Key
Identifier Extension is:AuthorityKeyIdentifier ::= SEQUENCE {
keyIdentifier [0] KeyIdentifier OPTIONAL,
authorityCertIssuer [1] GeneralNames OPTIONAL,
authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL }KeyIdentifier ::= OCTET STRING
When a certificate also provides
authorityCertIssuer and authorityCertSerialNumber then the length of
AuthorityKeyIdentifier SEQUENCE is likely to long form format.
e.g.
The example certificate demos/tunala/A-server.pem in openssl source:X509v3 Authority Key Identifier:
keyid:49:FB:45:72:12:C4:CC:E1:45:A1:D3:08:9E:95:C4:2C:6D:55:3F:17
DirName:/C=NZ/L=Wellington/O=Really Irresponsible Authorisation Authority (RIAA)/OU=Cert-stamping/CN=Jackov al-Trades/emailAddress=none@fake.domain
serial:00Current parsing rule of OID_authorityKeyIdentifier only take care the
short form format, it causes load certificate to modsign_keyring fail:[ 12.061147] X.509: Extension: 47
[ 12.075121] MODSIGN: Problem loading in-kernel X.509 certificate (-74)So, this patch add the parsing rule for support long form format against
Authority Key Identifier.v3:
Changed the size check in "Short Form length" case, we allow v[3] smaller
then (vlen - 4) because authorityCertIssuer and authorityCertSerialNumber
are also possible attach in AuthorityKeyIdentifier sequence.v2:
- Removed comma from author's name.
- Moved 'Short Form length' comment inside the if-body.
- Changed the type of sub to size_t.
- Use ASN1_INDEFINITE_LENGTH rather than writing 0x80 and 127.
- Moved the key_len's value assignment before alter v.
- Fixed the typo of octets.
- Add 2 to v before entering the loop for calculate the length.
- Removed the comment of check vlen.Cc: Rusty Russell
Cc: Josh Boyer
Cc: Randy Dunlap
Cc: Herbert Xu
Cc: "David S. Miller"
Acked-by: David Howells
Signed-off-by: Chun-Yi Lee
Signed-off-by: Rusty Russell
10 Oct, 2012
2 commits
-
Fix printk format warning in x509_cert_parser.c:
crypto/asymmetric_keys/x509_cert_parser.c: In function 'x509_note_OID':
crypto/asymmetric_keys/x509_cert_parser.c:113:3: warning: format '%zu' expects type 'size_t', but argument 2 has type 'long unsigned int'Builds cleanly on i386 and x86_64.
Signed-off-by: Randy Dunlap
Cc: David Howells
Cc: Herbert Xu
Cc: linux-crypto@vger.kernel.org
Signed-off-by: Rusty Russell -
The current choice of lifetime for the autogenerated X.509 of 100 years,
putting the validTo date in 2112, causes problems on 32-bit systems where a
32-bit time_t wraps in 2106. 64-bit x86_64 systems seem to be unaffected.This can result in something like:
Loading module verification certificates
X.509: Cert 6e03943da0f3b015ba6ed7f5e0cac4fe48680994 has expired
MODSIGN: Problem loading in-kernel X.509 certificate (-127)Or:
X.509: Cert 6e03943da0f3b015ba6ed7f5e0cac4fe48680994 is not yet valid
MODSIGN: Problem loading in-kernel X.509 certificate (-129)Instead of turning the dates into time_t values and comparing, turn the system
clock and the ASN.1 dates into tm structs and compare those piecemeal instead.Reported-by: Rusty Russell
Signed-off-by: David Howells
Acked-by: Josh Boyer
Signed-off-by: Rusty Russell
08 Oct, 2012
1 commit
-
Add a crypto key parser for binary (DER) encoded X.509 certificates. The
certificate is parsed and, if possible, the signature is verified.An X.509 key can be added like this:
# keyctl padd crypto bar @s
Signed-off-by: Rusty Russell