2019-05-20 20:08:01 +03:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0-or-later */
|
2012-09-22 02:30:46 +04:00
|
|
|
/* ASN.1 Object identifier (OID) registry
|
|
|
|
*
|
|
|
|
* Copyright (C) 2012 Red Hat, Inc. All Rights Reserved.
|
|
|
|
* Written by David Howells (dhowells@redhat.com)
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef _LINUX_OID_REGISTRY_H
|
|
|
|
#define _LINUX_OID_REGISTRY_H
|
|
|
|
|
|
|
|
#include <linux/types.h>
|
|
|
|
|
|
|
|
/*
|
|
|
|
* OIDs are turned into these values if possible, or OID__NR if not held here.
|
|
|
|
*
|
|
|
|
* NOTE! Do not mess with the format of each line as this is read by
|
|
|
|
* build_OID_registry.pl to generate the data for look_up_OID().
|
|
|
|
*/
|
|
|
|
enum OID {
|
|
|
|
OID_id_dsa_with_sha1, /* 1.2.840.10030.4.3 */
|
|
|
|
OID_id_dsa, /* 1.2.840.10040.4.1 */
|
|
|
|
OID_id_ecPublicKey, /* 1.2.840.10045.2.1 */
|
2021-03-17 00:07:37 +03:00
|
|
|
OID_id_prime192v1, /* 1.2.840.10045.3.1.1 */
|
|
|
|
OID_id_prime256v1, /* 1.2.840.10045.3.1.7 */
|
2021-03-17 00:07:31 +03:00
|
|
|
OID_id_ecdsa_with_sha1, /* 1.2.840.10045.4.1 */
|
|
|
|
OID_id_ecdsa_with_sha224, /* 1.2.840.10045.4.3.1 */
|
|
|
|
OID_id_ecdsa_with_sha256, /* 1.2.840.10045.4.3.2 */
|
|
|
|
OID_id_ecdsa_with_sha384, /* 1.2.840.10045.4.3.3 */
|
|
|
|
OID_id_ecdsa_with_sha512, /* 1.2.840.10045.4.3.4 */
|
2012-09-22 02:30:46 +04:00
|
|
|
|
|
|
|
/* PKCS#1 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1)} */
|
|
|
|
OID_rsaEncryption, /* 1.2.840.113549.1.1.1 */
|
|
|
|
OID_md2WithRSAEncryption, /* 1.2.840.113549.1.1.2 */
|
|
|
|
OID_md3WithRSAEncryption, /* 1.2.840.113549.1.1.3 */
|
|
|
|
OID_md4WithRSAEncryption, /* 1.2.840.113549.1.1.4 */
|
|
|
|
OID_sha1WithRSAEncryption, /* 1.2.840.113549.1.1.5 */
|
|
|
|
OID_sha256WithRSAEncryption, /* 1.2.840.113549.1.1.11 */
|
|
|
|
OID_sha384WithRSAEncryption, /* 1.2.840.113549.1.1.12 */
|
|
|
|
OID_sha512WithRSAEncryption, /* 1.2.840.113549.1.1.13 */
|
|
|
|
OID_sha224WithRSAEncryption, /* 1.2.840.113549.1.1.14 */
|
|
|
|
/* PKCS#7 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-7(7)} */
|
|
|
|
OID_data, /* 1.2.840.113549.1.7.1 */
|
|
|
|
OID_signed_data, /* 1.2.840.113549.1.7.2 */
|
|
|
|
/* PKCS#9 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)} */
|
|
|
|
OID_email_address, /* 1.2.840.113549.1.9.1 */
|
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 <luto@kernel.org>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Marcel Holtmann <marcel@holtmann.org>
Reviewed-by: David Woodhouse <David.Woodhouse@intel.com>
2015-08-05 17:22:27 +03:00
|
|
|
OID_contentType, /* 1.2.840.113549.1.9.3 */
|
2012-09-22 02:30:46 +04:00
|
|
|
OID_messageDigest, /* 1.2.840.113549.1.9.4 */
|
|
|
|
OID_signingTime, /* 1.2.840.113549.1.9.5 */
|
|
|
|
OID_smimeCapabilites, /* 1.2.840.113549.1.9.15 */
|
|
|
|
OID_smimeAuthenticatedAttrs, /* 1.2.840.113549.1.9.16.2.11 */
|
|
|
|
|
|
|
|
/* {iso(1) member-body(2) us(840) rsadsi(113549) digestAlgorithm(2)} */
|
|
|
|
OID_md2, /* 1.2.840.113549.2.2 */
|
|
|
|
OID_md4, /* 1.2.840.113549.2.4 */
|
|
|
|
OID_md5, /* 1.2.840.113549.2.5 */
|
|
|
|
|
2021-06-08 17:53:14 +03:00
|
|
|
OID_mskrb5, /* 1.2.840.48018.1.2.2 */
|
|
|
|
OID_krb5, /* 1.2.840.113554.1.2.2 */
|
|
|
|
OID_krb5u2u, /* 1.2.840.113554.1.2.2.3 */
|
|
|
|
|
2014-07-01 19:02:52 +04:00
|
|
|
/* Microsoft Authenticode & Software Publishing */
|
|
|
|
OID_msIndirectData, /* 1.3.6.1.4.1.311.2.1.4 */
|
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 <luto@kernel.org>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Marcel Holtmann <marcel@holtmann.org>
Reviewed-by: David Woodhouse <David.Woodhouse@intel.com>
2015-08-05 17:22:27 +03:00
|
|
|
OID_msStatementType, /* 1.3.6.1.4.1.311.2.1.11 */
|
|
|
|
OID_msSpOpusInfo, /* 1.3.6.1.4.1.311.2.1.12 */
|
2014-07-01 19:02:52 +04:00
|
|
|
OID_msPeImageDataObjId, /* 1.3.6.1.4.1.311.2.1.15 */
|
|
|
|
OID_msIndividualSPKeyPurpose, /* 1.3.6.1.4.1.311.2.1.21 */
|
2012-09-22 02:30:46 +04:00
|
|
|
OID_msOutlookExpress, /* 1.3.6.1.4.1.311.16.4 */
|
2014-07-01 19:02:52 +04:00
|
|
|
|
2021-06-08 17:53:14 +03:00
|
|
|
OID_ntlmssp, /* 1.3.6.1.4.1.311.2.2.10 */
|
|
|
|
|
|
|
|
OID_spnego, /* 1.3.6.1.5.5.2 */
|
|
|
|
|
2021-08-21 02:10:36 +03:00
|
|
|
OID_IAKerb, /* 1.3.6.1.5.2.5 */
|
|
|
|
OID_PKU2U, /* 1.3.5.1.5.2.7 */
|
|
|
|
OID_Scram, /* 1.3.6.1.5.5.14 */
|
2014-07-01 19:02:52 +04:00
|
|
|
OID_certAuthInfoAccess, /* 1.3.6.1.5.5.7.1.1 */
|
2012-09-22 02:30:46 +04:00
|
|
|
OID_sha1, /* 1.3.14.3.2.26 */
|
2021-03-17 00:07:39 +03:00
|
|
|
OID_id_ansip384r1, /* 1.3.132.0.34 */
|
2014-07-01 19:40:19 +04:00
|
|
|
OID_sha256, /* 2.16.840.1.101.3.4.2.1 */
|
2015-08-30 18:59:57 +03:00
|
|
|
OID_sha384, /* 2.16.840.1.101.3.4.2.2 */
|
|
|
|
OID_sha512, /* 2.16.840.1.101.3.4.2.3 */
|
|
|
|
OID_sha224, /* 2.16.840.1.101.3.4.2.4 */
|
2012-09-22 02:30:46 +04:00
|
|
|
|
|
|
|
/* Distinguished Name attribute IDs [RFC 2256] */
|
|
|
|
OID_commonName, /* 2.5.4.3 */
|
|
|
|
OID_surname, /* 2.5.4.4 */
|
|
|
|
OID_countryName, /* 2.5.4.6 */
|
|
|
|
OID_locality, /* 2.5.4.7 */
|
|
|
|
OID_stateOrProvinceName, /* 2.5.4.8 */
|
|
|
|
OID_organizationName, /* 2.5.4.10 */
|
|
|
|
OID_organizationUnitName, /* 2.5.4.11 */
|
|
|
|
OID_title, /* 2.5.4.12 */
|
|
|
|
OID_description, /* 2.5.4.13 */
|
|
|
|
OID_name, /* 2.5.4.41 */
|
|
|
|
OID_givenName, /* 2.5.4.42 */
|
|
|
|
OID_initials, /* 2.5.4.43 */
|
|
|
|
OID_generationalQualifier, /* 2.5.4.44 */
|
|
|
|
|
|
|
|
/* Certificate extension IDs */
|
|
|
|
OID_subjectKeyIdentifier, /* 2.5.29.14 */
|
|
|
|
OID_keyUsage, /* 2.5.29.15 */
|
|
|
|
OID_subjectAltName, /* 2.5.29.17 */
|
|
|
|
OID_issuerAltName, /* 2.5.29.18 */
|
|
|
|
OID_basicConstraints, /* 2.5.29.19 */
|
|
|
|
OID_crlDistributionPoints, /* 2.5.29.31 */
|
|
|
|
OID_certPolicies, /* 2.5.29.32 */
|
|
|
|
OID_authorityKeyIdentifier, /* 2.5.29.35 */
|
|
|
|
OID_extKeyUsage, /* 2.5.29.37 */
|
|
|
|
|
2021-08-21 02:10:36 +03:00
|
|
|
/* Heimdal mechanisms */
|
|
|
|
OID_NetlogonMechanism, /* 1.2.752.43.14.2 */
|
|
|
|
OID_appleLocalKdcSupported, /* 1.2.752.43.14.3 */
|
|
|
|
|
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: linux-integrity@vger.kernel.org
Signed-off-by: Vitaly Chikunov <vt@altlinux.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-04-11 18:51:20 +03:00
|
|
|
/* EC-RDSA */
|
|
|
|
OID_gostCPSignA, /* 1.2.643.2.2.35.1 */
|
|
|
|
OID_gostCPSignB, /* 1.2.643.2.2.35.2 */
|
|
|
|
OID_gostCPSignC, /* 1.2.643.2.2.35.3 */
|
|
|
|
OID_gost2012PKey256, /* 1.2.643.7.1.1.1.1 */
|
|
|
|
OID_gost2012PKey512, /* 1.2.643.7.1.1.1.2 */
|
|
|
|
OID_gost2012Digest256, /* 1.2.643.7.1.1.2.2 */
|
|
|
|
OID_gost2012Digest512, /* 1.2.643.7.1.1.2.3 */
|
|
|
|
OID_gost2012Signature256, /* 1.2.643.7.1.1.3.2 */
|
|
|
|
OID_gost2012Signature512, /* 1.2.643.7.1.1.3.3 */
|
|
|
|
OID_gostTC26Sign256A, /* 1.2.643.7.1.2.1.1.1 */
|
|
|
|
OID_gostTC26Sign256B, /* 1.2.643.7.1.2.1.1.2 */
|
|
|
|
OID_gostTC26Sign256C, /* 1.2.643.7.1.2.1.1.3 */
|
|
|
|
OID_gostTC26Sign256D, /* 1.2.643.7.1.2.1.1.4 */
|
|
|
|
OID_gostTC26Sign512A, /* 1.2.643.7.1.2.1.2.1 */
|
|
|
|
OID_gostTC26Sign512B, /* 1.2.643.7.1.2.1.2.2 */
|
|
|
|
OID_gostTC26Sign512C, /* 1.2.643.7.1.2.1.2.3 */
|
|
|
|
|
2020-09-20 19:21:01 +03:00
|
|
|
/* OSCCA */
|
|
|
|
OID_sm2, /* 1.2.156.10197.1.301 */
|
|
|
|
OID_sm3, /* 1.2.156.10197.1.401 */
|
|
|
|
OID_SM2_with_SM3, /* 1.2.156.10197.1.501 */
|
|
|
|
OID_sm3WithRSAEncryption, /* 1.2.156.10197.1.504 */
|
|
|
|
|
2021-01-27 22:06:14 +03:00
|
|
|
/* TCG defined OIDS for TPM based keys */
|
|
|
|
OID_TPMLoadableKey, /* 2.23.133.10.1.3 */
|
|
|
|
OID_TPMImportableKey, /* 2.23.133.10.1.4 */
|
|
|
|
OID_TPMSealedData, /* 2.23.133.10.1.5 */
|
|
|
|
|
2012-09-22 02:30:46 +04:00
|
|
|
OID__NR
|
|
|
|
};
|
|
|
|
|
|
|
|
extern enum OID look_up_OID(const void *data, size_t datasize);
|
2021-03-17 00:07:36 +03:00
|
|
|
extern int parse_OID(const void *data, size_t datasize, enum OID *oid);
|
2012-09-22 02:30:51 +04:00
|
|
|
extern int sprint_oid(const void *, size_t, char *, size_t);
|
|
|
|
extern int sprint_OID(enum OID, char *, size_t);
|
2012-09-22 02:30:46 +04:00
|
|
|
|
|
|
|
#endif /* _LINUX_OID_REGISTRY_H */
|