crypto: x509 - Add OID for NIST P521 and extend parser for it

Enable the x509 parser to accept NIST P521 certificates and add the
OID for ansip521r1, which is the identifier for NIST P521.

Cc: Davi

crypto: x509 - Add OID for NIST P521 and extend parser for it

Enable the x509 parser to accept NIST P521 certificates and add the
OID for ansip521r1, which is the identifier for NIST P521.

Cc: David Howells <[email protected]>
Tested-by: Lukas Wunner <[email protected]>
Reviewed-by: Jarkko Sakkinen <[email protected]>
Signed-off-by: Stefan Berger <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>

show more ...

Revert "crypto: pkcs7 - remove sha1 support"

This reverts commit 16ab7cb5825fc3425c16ad2c6e53d827f382d7c6 because it
broke iwd. iwd uses the KEYCTL_PKEY_* UAPIs via its dependency libell,
and appar

Revert "crypto: pkcs7 - remove sha1 support"

This reverts commit 16ab7cb5825fc3425c16ad2c6e53d827f382d7c6 because it
broke iwd. iwd uses the KEYCTL_PKEY_* UAPIs via its dependency libell,
and apparently it is relying on SHA-1 signature support. These UAPIs
are fairly obscure, and their documentation does not mention which
algorithms they support. iwd really should be using a properly
supported userspace crypto library instead. Regardless, since something
broke we have to revert the change.

It may be possible that some parts of this commit can be reinstated
without breaking iwd (e.g. probably the removal of MODULE_SIG_SHA1), but
for now this just does a full revert to get things working again.

Reported-by: Karel Balej <[email protected]>
Closes: https://lore.kernel.org/r/[email protected]
Cc: Dimitri John Ledkov <[email protected]>
Signed-off-by: Eric Biggers <[email protected]>
Tested-by: Karel Balej <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>

show more ...

x509: Add OIDs for FIPS 202 SHA-3 hash and signatures

Add OID for FIPS 202 SHA-3 family of hash functions, RSA & ECDSA
signatures using those. Limit to 256 or larger sizes, for
interoperability reas

x509: Add OIDs for FIPS 202 SHA-3 hash and signatures

Add OID for FIPS 202 SHA-3 family of hash functions, RSA & ECDSA
signatures using those. Limit to 256 or larger sizes, for
interoperability reasons. 224 is too weak for any practical uses.

Signed-off-by: Dimitri John Ledkov <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>

show more ...

crypto: pkcs7 - remove sha1 support

Removes support for sha1 signed kernel modules, importing sha1 signed
x.509 certificates.

rsa-pkcs1pad keeps sha1 padding support, which seems to be used by
virt

crypto: pkcs7 - remove sha1 support

Removes support for sha1 signed kernel modules, importing sha1 signed
x.509 certificates.

rsa-pkcs1pad keeps sha1 padding support, which seems to be used by
virtio driver.

sha1 remains available as there are many drivers and subsystems using
it. Note only hmac(sha1) with secret keys remains cryptographically
secure.

In the kernel there are filesystems, IMA, tpm/pcr that appear to be
using sha1. Maybe they can all start to be slowly upgraded to
something else i.e. blake3, ParallelHash, SHAKE256 as needed.

Signed-off-by: Dimitri John Ledkov <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>

show more ...

crypto: pkcs7 - remove md4 md5 x.509 support

Remove support for md4 md5 hash and signatures in x.509 certificate
parsers, pkcs7 signature parser, authenticode parser.

All of these are insecure or b

crypto: pkcs7 - remove md4 md5 x.509 support

Remove support for md4 md5 hash and signatures in x.509 certificate
parsers, pkcs7 signature parser, authenticode parser.

All of these are insecure or broken, and everyone has long time ago
migrated to alternative hash implementations.

Also remove md2 & md3 oids which have already didn't have support.

This is also likely the last user of md4 in the kernel, and thus
crypto/md4.c and related tests in tcrypt & testmgr can likely be
removed. Other users such as cifs smbfs ext modpost sumversions have
their own internal implementation as needed.

Signed-off-by: Dimitri John Ledkov <[email protected]>
Reviewed-by: Jarkko Sakkinen <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>

show more ...

spnego: add missing OID to oid registry

Add missing OID to the registry. Some servers and clients (including
Windows) now request "NEGOEX - SPNEGEO Extended Negotiation Security")

See https://datat

spnego: add missing OID to oid registry

Add missing OID to the registry. Some servers and clients (including
Windows) now request "NEGOEX - SPNEGEO Extended Negotiation Security")

See https://datatracker.ietf.org/doc/html/draft-zhu-negoex-02

Reviewed-by: Namjae Jeon <[email protected]>
Signed-off-by: Steve French <[email protected]>

show more ...

oid_registry: Add OIDs for missing Spnego auth mechanisms to Macs

In testing mounts to Macs, noticed that the OIDS for some
GSSAPI/SPNEGO auth mechanisms sent by the server were not
recognized and w

oid_registry: Add OIDs for missing Spnego auth mechanisms to Macs

In testing mounts to Macs, noticed that the OIDS for some
GSSAPI/SPNEGO auth mechanisms sent by the server were not
recognized and were missing from the header.

Reviewed-by: Paulo Alcantara (SUSE) <[email protected]>
Signed-off-by: Steve French <[email protected]>

show more ...

cifs: decoding negTokenInit with generic ASN1 decoder

Decode negTokenInit with lib/asn1_decoder. For that,
add OIDs in linux/oid_registry.h and a negTokenInit
ASN1 file, "spnego_negtokeninit.asn1".

cifs: decoding negTokenInit with generic ASN1 decoder

Decode negTokenInit with lib/asn1_decoder. For that,
add OIDs in linux/oid_registry.h and a negTokenInit
ASN1 file, "spnego_negtokeninit.asn1".
And define decoder's callback functions, which
are the gssapi_this_mech for checking SPENGO oid and
the neg_token_init_mech_type for getting authentication
mechanisms supported by a server.

Signed-off-by: Hyunchul Lee <[email protected]>
Reviewed-by: Aurelien Aptel <[email protected]>
Reviewed-by: Paulo Alcantara (SUSE) <[email protected]>
Signed-off-by: Steve French <[email protected]>

show more ...

oid_registry: Add TCG defined OIDS for TPM keys

The TCG has defined an OID prefix "2.23.133.10.1" for the various TPM
key uses. We've defined three of the available numbers:

2.23.133.10.1.3 TPM Lo

oid_registry: Add TCG defined OIDS for TPM keys

The TCG has defined an OID prefix "2.23.133.10.1" for the various TPM
key uses. We've defined three of the available numbers:

2.23.133.10.1.3 TPM Loadable key. This is an asymmetric key (Usually
RSA2048 or Elliptic Curve) which can be imported by a
TPM2_Load() operation.

2.23.133.10.1.4 TPM Importable Key. This is an asymmetric key (Usually
RSA2048 or Elliptic Curve) which can be imported by a
TPM2_Import() operation.

Both loadable and importable keys are specific to a given TPM, the
difference is that a loadable key is wrapped with the symmetric
secret, so must have been created by the TPM itself. An importable
key is wrapped with a DH shared secret, and may be created without
access to the TPM provided you know the public part of the parent key.

2.23.133.10.1.5 TPM Sealed Data. This is a set of data (up to 128
bytes) which is sealed by the TPM. It usually
represents a symmetric key and must be unsealed before
use.

The ASN.1 binary key form starts of with this OID as the first element
of a sequence, giving the binary form a unique recognizable identity
marker regardless of encoding.

Signed-off-by: James Bottomley <[email protected]>
Reviewed-by: David Howells <[email protected]>
Acked-by: Jarkko Sakkinen <[email protected]>
Signed-off-by: Jarkko Sakkinen <[email protected]>

show more ...

x509: Add OID for NIST P384 and extend parser for it

Prepare the x509 parser to accept NIST P384 certificates and add the
OID for ansip384r1, which is the identifier for NIST P384.

Summary of chang

x509: Add OID for NIST P384 and extend parser for it

Prepare the x509 parser to accept NIST P384 certificates and add the
OID for ansip384r1, which is the identifier for NIST P384.

Summary of changes:

* crypto/asymmetric_keys/x509_cert_parser.c
- prepare x509 parser to load NIST P384

* include/linux/oid_registry.h
- add OID_ansip384r1

Signed-off-by: Saulo Alessandre <[email protected]>
Tested-by: Stefan Berger <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>

show more ...

x509: Add support for parsing x509 certs with ECDSA keys

Add support for parsing of x509 certificates that contain ECDSA keys,
such as NIST P256, that have been signed by a CA using any of the
curre

x509: Add support for parsing x509 certs with ECDSA keys

Add support for parsing of x509 certificates that contain ECDSA keys,
such as NIST P256, that have been signed by a CA using any of the
current SHA hash algorithms.

Cc: David Howells <[email protected]>
Cc: [email protected]
Signed-off-by: Stefan Berger <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>

show more ...

x509: Detect sm2 keys by their parameters OID

Detect whether a key is an sm2 type of key by its OID in the parameters
array rather than assuming that everything under OID_id_ecPublicKey
is sm2, whic

x509: Detect sm2 keys by their parameters OID

Detect whether a key is an sm2 type of key by its OID in the parameters
array rather than assuming that everything under OID_id_ecPublicKey
is sm2, which is not the case.

Cc: David Howells <[email protected]>
Cc: [email protected]
Signed-off-by: Stefan Berger <[email protected]>
Reviewed-by: Tianjia Zhang <[email protected]>
Tested-by: Tianjia Zhang <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>

show more ...

oid_registry: Add OIDs for ECDSA with SHA224/256/384/512

Add OIDs for ECDSA with SHA224/256/384/512.

Signed-off-by: Stefan Berger <[email protected]>
Acked-by: Jarkko Sakkinen <[email protected]

oid_registry: Add OIDs for ECDSA with SHA224/256/384/512

Add OIDs for ECDSA with SHA224/256/384/512.

Signed-off-by: Stefan Berger <[email protected]>
Acked-by: Jarkko Sakkinen <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>

show more ...

X.509: support OSCCA certificate parse

The digital certificate format based on SM2 crypto algorithm as
specified in GM/T 0015-2012. It was published by State Encryption
Management Bureau, China.

Th

X.509: support OSCCA certificate parse

The digital certificate format based on SM2 crypto algorithm as
specified in GM/T 0015-2012. It was published by State Encryption
Management Bureau, China.

This patch adds the OID object identifier defined by OSCCA. The
x509 certificate supports SM2-with-SM3 type certificate parsing.
It uses the standard elliptic curve public key, and the sm2
algorithm signs the hash generated by sm3.

Signed-off-by: Tianjia Zhang <[email protected]>
Tested-by: Xufeng Zhang <[email protected]>
Reviewed-by: Vitaly Chikunov <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>

show more ...

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 36

Based on 1 normalized pattern(s):

this program is free software you can redistribute it and or modify
it under the terms of the

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 36

Based on 1 normalized pattern(s):

this program is free software you can redistribute it and or modify
it under the terms of the gnu general public licence as published by
the free software foundation either version 2 of the licence or at
your option any later version

extracted by the scancode license scanner the SPDX license identifier

GPL-2.0-or-later

has been chosen to replace the boilerplate/reference in 114 file(s).

Signed-off-by: Thomas Gleixner <[email protected]>
Reviewed-by: Allison Randal <[email protected]>
Reviewed-by: Kate Stewart <[email protected]>
Cc: [email protected]
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

crypto: ecrdsa - add EC-RDSA (GOST 34.10) algorithm

Add Elliptic Curve Russian Digital Signature Algorithm (GOST R
34.10-2012, RFC 7091, ISO/IEC 14888-3) is one of the Russian (and since
2018 the CI

crypto: ecrdsa - add EC-RDSA (GOST 34.10) algorithm

Add Elliptic Curve Russian Digital Signature Algorithm (GOST R
34.10-2012, RFC 7091, ISO/IEC 14888-3) is one of the Russian (and since
2018 the CIS countries) cryptographic standard algorithms (called GOST
algorithms). Only signature verification is supported, with intent to be
used in the IMA.

Summary of the changes:

* crypto/Kconfig:
- EC-RDSA is added into Public-key cryptography section.

* crypto/Makefile:
- ecrdsa objects are added.

* crypto/asymmetric_keys/x509_cert_parser.c:
- Recognize EC-RDSA and Streebog OIDs.

* include/linux/oid_registry.h:
- EC-RDSA OIDs are added to the enum. Also, a two currently not
implemented curve OIDs are added for possible extension later (to
not change numbering and grouping).

* crypto/ecc.c:
- Kenneth MacKay copyright date is updated to 2014, because
vli_mmod_slow, ecc_point_add, ecc_point_mult_shamir are based on his
code from micro-ecc.
- Functions needed for ecrdsa are EXPORT_SYMBOL'ed.
- New functions:
vli_is_negative - helper to determine sign of vli;
vli_from_be64 - unpack big-endian array into vli (used for
a signature);
vli_from_le64 - unpack little-endian array into vli (used for
a public key);
vli_uadd, vli_usub - add/sub u64 value to/from vli (used for
increment/decrement);
mul_64_64 - optimized to use __int128 where appropriate, this speeds
up point multiplication (and as a consequence signature
verification) by the factor of 1.5-2;
vli_umult - multiply vli by a small value (speeds up point
multiplication by another factor of 1.5-2, depending on vli sizes);
vli_mmod_special - module reduction for some form of Pseudo-Mersenne
primes (used for the curves A);
vli_mmod_special2 - module reduction for another form of
Pseudo-Mersenne primes (used for the curves B);
vli_mmod_barrett - module reduction using pre-computed value (used
for the curve C);
vli_mmod_slow - more general module reduction which is much slower
(used when the modulus is subgroup order);
vli_mod_mult_slow - modular multiplication;
ecc_point_add - add two points;
ecc_point_mult_shamir - add two points multiplied by scalars in one
combined multiplication (this gives speed up by another factor 2 in
compare to two separate multiplications).
ecc_is_pubkey_valid_partial - additional samity check is added.
- Updated vli_mmod_fast with non-strict heuristic to call optimal
module reduction function depending on the prime value;
- All computations for the previously defined (two NIST) curves should
not unaffected.

* crypto/ecc.h:
- Newly exported functions are documented.

* crypto/ecrdsa_defs.h
- Five curves are defined.

* crypto/ecrdsa.c:
- Signature verification is implemented.

* crypto/ecrdsa_params.asn1, crypto/ecrdsa_pub_key.asn1:
- Templates for BER decoder for EC-RDSA parameters and public key.

Cc: [email protected]
Signed-off-by: Vitaly Chikunov <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>

show more ...

PKCS#7: Add OIDs for sha224, sha284 and sha512 hash algos and use them

Add OIDs for sha224, sha284 and sha512 hash algos and use them to select
the hashing algorithm. Without this, something like t

PKCS#7: Add OIDs for sha224, sha284 and sha512 hash algos and use them

Add OIDs for sha224, sha284 and sha512 hash algos and use them to select
the hashing algorithm. Without this, something like the following error
might get written to dmesg:

[ 31.829322] PKCS7: Unknown OID: [32] 2.16.840.1.101.3.4.2.3
[ 31.829328] PKCS7: Unknown OID: [180] 2.16.840.1.101.3.4.2.3
[ 31.829330] Unsupported digest algo: 55

Where the 55 on the third line is OID__NR indicating an unknown OID.

Reported-by: Valdis Kletnieks <[email protected]>
Signed-off-by: David Howells <[email protected]>
Tested-By: Valdis Kletnieks <[email protected]>
Signed-off-by: James Morris <[email protected]>

show more ...

PKCS#7: Appropriately restrict authenticated attributes and content type

A PKCS#7 or CMS message can have per-signature authenticated attributes
that are digested as a lump and signed by the authori

PKCS#7: Appropriately restrict authenticated attributes and content type

A PKCS#7 or CMS message can have per-signature authenticated attributes
that are digested as a lump and signed by the authorising key for that
signature. If such attributes exist, the content digest isn't itself
signed, but rather it is included in a special authattr which then
contributes to the signature.

Further, we already require the master message content type to be
pkcs7_signedData - but there's also a separate content type for the data
itself within the SignedData object and this must be repeated inside the
authattrs for each signer [RFC2315 9.2, RFC5652 11.1].

We should really validate the authattrs if they exist or forbid them
entirely as appropriate. To this end:

(1) Alter the PKCS#7 parser to reject any message that has more than one
signature where at least one signature has authattrs and at least one
that does not.

(2) Validate authattrs if they are present and strongly restrict them.
Only the following authattrs are permitted and all others are
rejected:

(a) contentType. This is checked to be an OID that matches the
content type in the SignedData object.

(b) messageDigest. This must match the crypto digest of the data.

(c) signingTime. If present, we check that this is a valid, parseable
UTCTime or GeneralTime and that the date it encodes fits within
the validity window of the matching X.509 cert.

(d) S/MIME capabilities. We don't check the contents.

(e) Authenticode SP Opus Info. We don't check the contents.

(f) Authenticode Statement Type. We don't check the contents.

The message is rejected if (a) or (b) are missing. If the message is
an Authenticode type, the message is rejected if (e) is missing; if
not Authenticode, the message is rejected if (d) - (f) are present.

The S/MIME capabilities authattr (d) unfortunately has to be allowed
to support kernels already signed by the pesign program. This only
affects kexec. sign-file suppresses them (CMS_NOSMIMECAP).

The message is also rejected if an authattr is given more than once or
if it contains more than one element in its set of values.

(3) Add a parameter to pkcs7_verify() to select one of the following
restrictions and pass in the appropriate option from the callers:

(*) VERIFYING_MODULE_SIGNATURE

This requires that the SignedData content type be pkcs7-data and
forbids authattrs. sign-file sets CMS_NOATTR. We could be more
flexible and permit authattrs optionally, but only permit minimal
content.

(*) VERIFYING_FIRMWARE_SIGNATURE

This requires that the SignedData content type be pkcs7-data and
requires authattrs. In future, this will require an attribute
holding the target firmware name in addition to the minimal set.

(*) VERIFYING_UNSPECIFIED_SIGNATURE

This requires that the SignedData content type be pkcs7-data but
allows either no authattrs or only permits the minimal set.

(*) VERIFYING_KEXEC_PE_SIGNATURE

This only supports the Authenticode SPC_INDIRECT_DATA content type
and requires at least an SpcSpOpusInfo authattr in addition to the
minimal set. It also permits an SPC_STATEMENT_TYPE authattr (and
an S/MIME capabilities authattr because the pesign program doesn't
remove these).

(*) VERIFYING_KEY_SIGNATURE
(*) VERIFYING_KEY_SELF_SIGNATURE

These are invalid in this context but are included for later use
when limiting the use of X.509 certs.

(4) The pkcs7_test key type is given a module parameter to select between
the above options for testing purposes. For example:

echo 1 >/sys/module/pkcs7_test_key/parameters/usage
keyctl padd pkcs7_test foo @s </tmp/stuff.pkcs7

will attempt to check the signature on stuff.pkcs7 as if it contains a
firmware blob (1 being VERIFYING_FIRMWARE_SIGNATURE).

Suggested-by: Andy Lutomirski <[email protected]>
Signed-off-by: David Howells <[email protected]>
Reviewed-by: Marcel Holtmann <[email protected]>
Reviewed-by: David Woodhouse <[email protected]>

show more ...

pefile: Parse the "Microsoft individual code signing" data blob

The PKCS#7 certificate should contain a "Microsoft individual code signing"
data blob as its signed content. This blob contains a dig

pefile: Parse the "Microsoft individual code signing" data blob

The PKCS#7 certificate should contain a "Microsoft individual code signing"
data blob as its signed content. This blob contains a digest of the signed
content of the PE binary and the OID of the digest algorithm used (typically
SHA256).

Signed-off-by: David Howells <[email protected]>
Acked-by: Vivek Goyal <[email protected]>
Reviewed-by: Kees Cook <[email protected]>

show more ...

PKCS#7: Implement a parser [RFC 2315]

Implement a parser for a PKCS#7 signed-data message as described in part of
RFC 2315.

Signed-off-by: David Howells <[email protected]>
Acked-by: Vivek Goyal

PKCS#7: Implement a parser [RFC 2315]

Implement a parser for a PKCS#7 signed-data message as described in part of
RFC 2315.

Signed-off-by: David Howells <[email protected]>
Acked-by: Vivek Goyal <[email protected]>
Reviewed-by: Kees Cook <[email protected]>

show more ...

X.509: Add utility functions to render OIDs as strings

Add a pair of utility functions to render OIDs as strings. The first takes an
encoded OID and turns it into a "a.b.c.d" form string:

int spr

X.509: Add utility functions to render OIDs as strings

Add a pair of utility functions to render OIDs as strings. The first takes an
encoded OID and turns it into a "a.b.c.d" form string:

int sprint_oid(const void *data, size_t datasize,
char *buffer, size_t bufsize);

The second takes an OID enum index and calls the first on the data held
therein:

int sprint_OID(enum OID oid, char *buffer, size_t bufsize);

Signed-off-by: David Howells <[email protected]>
Signed-off-by: Rusty Russell <[email protected]>

show more ...

X.509: Implement simple static OID registry

Implement a simple static OID registry that allows the mapping of an encoded
OID to an enum value for ease of use.

The OID registry index enum appears in

X.509: Implement simple static OID registry

Implement a simple static OID registry that allows the mapping of an encoded
OID to an enum value for ease of use.

The OID registry index enum appears in the:

linux/oid_registry.h

header file. A script generates the registry from lines in the header file
that look like:

<sp*>OID_foo,<sp*>/*<sp*>1.2.3.4<sp*>*/

The actual OID is taken to be represented by the numbers with interpolated
dots in the comment.

All other lines in the header are ignored.

The registry is queries by calling:

OID look_up_oid(const void *data, size_t datasize);

This returns a number from the registry enum representing the OID if found or
OID__NR if not.

Signed-off-by: David Howells <[email protected]>
Signed-off-by: Rusty Russell <[email protected]>

show more ...