x509_request_asymmetric_keys() doesn't need the lengths of the NUL-terminated
strings passing in as it can work that out for itself.
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
Fixes the following sparse warnings:
crypto/asymmetric_keys/pkcs7_key_type.c:73:17: warning:
symbol 'key_type_pkcs7' was not declared. Should it be static?
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: David Howells <dhowells@redhat.com>
crypto/asymmetric_keys/pkcs7_key_type.c needs to #include linux/err.h rather
than relying on getting it through other headers.
Without this, the powerpc allyesconfig build fails.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: David Howells <dhowells@redhat.com>
With DMA_API_DEBUG set, following warnings are emitted
(tested on CAAM accelerator):
DMA-API: device driver maps memory from kernel text or rodata
DMA-API: device driver maps memory from stack
and the culprits are:
-key in __test_aead and __test_hash
-result in __test_hash
MAX_KEYLEN is changed to accommodate maximum key length from
existing test vectors in crypto/testmgr.h (131 bytes) and rounded.
Signed-off-by: Horia Geanta <horia.geanta@freescale.com>
Acked-by: Kim Phillips <kim.phillips@freescale.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIVAwUAU71KqhOxKuMESys7AQKIwRAAgOXB0hjYkWKCHL2B1/8bNUtRKQKHsCms
4HgNuLQ4v+RjpXDd4u0HvjkuD2ADDZlBPNSylsLsrnSXS7gH/b36vetAi8zYR/6B
Tuvorh6BfnOkN61Xg0mwlnXkp9jisTwaZofMTDlpQ4gPAAy098Lb73ONIIlJFIH9
WrUH/LLcPqtexdOOFtXPTBH0uz+qu8tcQHAotkP7Uwr4lDliVu1u4F2HkxRPvLjc
IKSgb1mRa0AU0mKXbdqFREBhpVIOPS7r5mIisKnUh2d8LysSiA++zlD8/t2pfsVM
enR7fo9pBEtJwhCrkff2p39DijR4M7s+SYF9soa9+9HQADt9D4bEtliqejGEkuQP
CBl4LZ4eHlh1bjQbay+PixDmFxEbN14IKkvNaXBvoax8f0DdXV2URGxmhU0tM08U
SFt2FaHhlBOsn4mhSoKJQnfHla5MP06ukrz4T+Qn2xd+lAX9e/sEBUQqT26o5Mgt
3yTaBrg4PREYjPVhguKT04tWrMdtvxY0nKRuUUeEcT7EQNVB5v/efGaWCxLI5k3O
wbkq5JvzSdq+VJOrby8m37fnEN7pxmF7mwOPXYfe3WPwJeX7xiYRc2ZGFntKdNzn
zSNKC4/OYiNwn+2ANL89kcJ3pJyoJ57SsMPiXpCCekPIcLtvGddoCvZae6f171HA
ZzlbxkjIxg0=
=e1NL
-----END PGP SIGNATURE-----
Merge tag 'keys-pefile-20140709' into keys-next
Here's a set of changes that implement a PE file signature checker.
This provides the following facility:
(1) Extract the signature from the PE file. This is a PKCS#7 message
containing, as its data, a hash of the signed parts of the file.
(2) Digest the signed parts of the file.
(3) Compare the digest with the one from the PKCS#7 message.
(4) Validate the signatures on the PKCS#7 message and indicate
whether it was matched by a trusted key.
Signed-off-by: David Howells <dhowells@redhat.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIVAwUAU7vyohOxKuMESys7AQJRkQ//XhtkCB9qDPrD/Hq6s3SDB7FCPWk8eJ9M
GhawiLonBFgsRqWst20cW1syc+7ECjkTZU0vD5GqMHealXj9Fho+7jyf08ShP+jM
AFBRfjoHKklOuh4C1lhB5IglR1zAXpmLHA2mP/r58BjEpOBEwlmh8rri/9/kk6iX
hAV79d23IaoM4ueGb4vVy61ZpsKA0YQadJK1xRjXzFPAuS3f4i6W7uKG9QmsJ56m
DaP++rtyJPByRVb/tJqUeJAIPaXQg9JRXD8tNGJ2qCdulEbHJQhNzp2ukQEMmfhS
RaogNO7jcfdM/4BeIoRJxNt3VcvHChSdbXP1YO4V792BdxnjsXO8GdEKXp53ijoP
mZ6Z1JsmpFKPGvAWA0eQUMYU4vnRzAtIo4CgdsIAQYpGrxOOnv+28UWalm7NLC1l
++YCesD03atd/XrdSNF082Xh8TTcRKI1OBOtBDya2ZhKMy56Bj/l6rOYVBw+Au6E
Yfressl7jCRaaT/ZHefZwKsJ5ac+MTcwAk0LlKflg+f8vdpMDnUfZxhUheM2EwWw
RyTHHa6IWUyYIOTXQ88KF1PmNXgGWBhe90yrHO909yaNWBnvFbPdJ91DuXvKUjza
SZ0GLS2+Vt+6TnlzxaHITE1ly5m3avZDAosIqEhGKymG6EL0mg469vpNGJNUbvIp
5jZqJ8wSF5Q=
=aRKT
-----END PGP SIGNATURE-----
Merge tag 'keys-pkcs7-20140708' into keys-next
Here's a set of changes that implement a PKCS#7 message parser in the kernel.
The PKCS#7 message parsing will then be used to limit kexec to authenticated
kernels only if so configured.
The changes provide the following facilities:
(1) Parse an ASN.1 PKCS#7 message and pick out useful bits such as the data
content and the X.509 certificates used to sign it and all the data
signatures.
(2) Verify all the data signatures against the set of X.509 certificates
available in the message.
(3) Follow the certificate chains and verify that:
(a) for every self-signed X.509 certificate, check that it validly signed
itself, and:
(b) for every non-self-signed certificate, if we have a 'parent'
certificate, the former is validly signed by the latter.
(4) Look for intersections between the certificate chains and the trusted
keyring, if any intersections are found, verify that the trusted
certificates signed the intersection point in the chain.
(5) For testing purposes, a key type can be made available that will take a
PKCS#7 message, check that the message is trustworthy, and if so, add its
data content into the key.
Note that (5) has to be altered to take account of the preparsing patches
already committed to this branch.
Signed-off-by: David Howells <dhowells@redhat.com>
struct key_preparsed_payload should have two payload pointers to correspond
with those in struct key.
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Steve Dickson <steved@redhat.com>
Acked-by: Jeff Layton <jlayton@primarydata.com>
Reviewed-by: Sage Weil <sage@redhat.com>
Provide a generic instantiation function for key types that use the preparse
hook. This makes it easier to prereserve key quota before keyrings get locked
to retain the new key.
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Steve Dickson <steved@redhat.com>
Acked-by: Jeff Layton <jlayton@primarydata.com>
Reviewed-by: Sage Weil <sage@redhat.com>
You can select MPILIB_EXTRA all you want, it doesn't exist ;-)
Surprised kconfig doesn't complain about that...
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Acked-by: Marek Vasut <marex@denx.de>
Signed-off-by: David Howells <dhowells@redhat.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S. Miller" <davem@davemloft.net>
Instead of allowing public keys, with certificates signed by any
key on the system trusted keyring, to be added to a trusted keyring,
this patch further restricts the certificates to those signed only by
builtin keys on the system keyring.
This patch defines a new option 'builtin' for the kernel parameter
'keys_ownerid' to allow trust validation using builtin keys.
Simplified Mimi's "KEYS: define an owner trusted keyring" patch
Changelog v7:
- rename builtin_keys to use_builtin_keys
Signed-off-by: Dmitry Kasatkin <d.kasatkin@samsung.com>
Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
Instead of allowing public keys, with certificates signed by any
key on the system trusted keyring, to be added to a trusted keyring,
this patch further restricts the certificates to those signed by a
particular key on the system keyring.
This patch defines a new kernel parameter 'ca_keys' to identify the
specific key which must be used for trust validation of certificates.
Simplified Mimi's "KEYS: define an owner trusted keyring" patch.
Changelog:
- support for builtin x509 public keys only
- export "asymmetric_keyid_match"
- remove ifndefs MODULE
- rename kernel boot parameter from keys_ownerid to ca_keys
Signed-off-by: Dmitry Kasatkin <d.kasatkin@samsung.com>
Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
To avoid code duplication this patch refactors asymmetric_key_match(),
making partial ID string match a separate function.
This patch also implicitly fixes a bug in the code. asymmetric_key_match()
allows to match the key by its subtype. But subtype matching could be
undone if asymmetric_key_id(key) would return NULL. This patch first
checks for matching spec and then for its value.
Signed-off-by: Dmitry Kasatkin <d.kasatkin@samsung.com>
Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
Only public keys, with certificates signed by an existing
'trusted' key on the system trusted keyring, should be added
to a trusted keyring. This patch adds support for verifying
a certificate's signature.
This is derived from David Howells pkcs7_request_asymmetric_key() patch.
Changelog v6:
- on error free key - Dmitry
- validate trust only for not already trusted keys - Dmitry
- formatting cleanup
Changelog:
- define get_system_trusted_keyring() to fix kbuild issues
Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Dmitry Kasatkin <dmitry.kasatkin@gmail.com>
Validate the PKCS#7 trust chain against the contents of the system keyring.
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Digest the signed parts of the PE binary, canonicalising the section table
before we need it, and then compare the the resulting digest to the one in the
PKCS#7 signed content.
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
The pesign utility had a bug where it was using OID_msIndividualSPKeyPurpose
instead of OID_msPeImageDataObjId - so allow both OIDs.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
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 <dhowells@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Parse the content of the certificate blob, presuming it to be PKCS#7 format.
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
The certificate data block in a PE binary has a wrapper around the PKCS#7
signature we actually want to get at. Strip this off and check that we've got
something that appears to be a PKCS#7 signature.
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Parse a PE binary to find a key and a signature contained therein. Later
patches will check the signature and add the key if the signature checks out.
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
The patch corrects the security strength of the HMAC-SHA1 DRBG to 128
bits. This strength defines the size of the seed required for the DRBG.
Thus, the patch lowers the seeding requirement from 256 bits to 128 bits
for HMAC-SHA1.
Signed-off-by: Stephan Mueller <smueller@chronox.de>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
The current locking approach of the DRBG tries to keep the protected
code paths very minimal. It is therefore possible that two threads query
one DRBG instance at the same time. When thread A requests random
numbers, a shadow copy of the DRBG state is created upon which the
request for A is processed. After finishing the state for A's request is
merged back into the DRBG state. If now thread B requests random numbers
from the same DRBG after the request for thread A is received, but
before A's shadow state is merged back, the random numbers for B will be
identical to the ones for A. Please note that the time window is very
small for this scenario.
To prevent that there is even a theoretical chance for thread A and B
having the same DRBG state, the current time stamp is provided as
additional information string for each new request.
The addition of the time stamp as additional information string implies
that now all generate functions must be capable to process a linked
list with additional information strings instead of a scalar.
CC: Rafael Aquini <aquini@redhat.com>
Signed-off-by: Stephan Mueller <smueller@chronox.de>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
When the DRBG is initialized, the core is looked up using the DRBG name.
The name that can be used for the lookup is registered in
cra_driver_name. The cra_name value contains stdrng.
Thus, the lookup code must use crypto_tfm_alg_driver_name to obtain the
precise DRBG name and select the correct DRBG.
Signed-off-by: Stephan Mueller <smueller@chronox.de>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
The CTR DRBG requires the update function to be called twice when
generating a random number. In both cases, update function must process
the additional information string by using the DF function. As the DF
produces the same result in both cases, we can save one invocation of
the DF function when the first DF function result is reused.
The result of the DF function is stored in the scratchpad storage. The
patch ensures that the scratchpad is not cleared when we want to reuse
the DF result. For achieving this, the CTR DRBG update function must
know by whom and in which scenario it is called. This information is
provided with the reseed parameter to the update function.
Signed-off-by: Stephan Mueller <smueller@chronox.de>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
The initial format strings caused warnings on several architectures. The
updated format strings now match the variable types.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Reported-by: Randy Dunlap <rdunlap@infradead.org>
CC: Joe Perches <joe@perches.com>
Signed-off-by: Stephan Mueller <smueller@chronox.de>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
The structure used to construct the module description line was marked
problematic by the sparse code analysis tool. The module line
description now does not contain any ifdefs to prevent error reports
from sparse.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Stephan Mueller <smueller@chronox.de>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Find the intersection between the X.509 certificate chain contained in a PKCS#7
message and a set of keys that we already know and trust.
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Verify certificate chain in the X.509 certificates contained within the PKCS#7
message as far as possible. If any signature that we should be able to verify
fails, we reject the whole lot.
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Find the appropriate key in the PKCS#7 key list and verify the signature with
it. There may be several keys in there forming a chain. Any link in that
chain or the root of that chain may be in our keyrings.
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Digest the data in a PKCS#7 signed-data message and attach to the
public_key_signature struct contained in the pkcs7_message struct.
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Implement a parser for a PKCS#7 signed-data message as described in part of
RFC 2315.
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
This patch removes the build-time test that ensures at least one RNG
is set. Instead we will simply not build drbg if no options are set
through Kconfig.
This also fixes a typo in the name of the Kconfig option CRYTPO_DRBG
(should be CRYPTO_DRBG).
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
The DRBG-style linked list to manage input data that is fed into the
cipher invocations is replaced with the kernel linked list
implementation.
The change is transparent to users of the interfaces offered by the
DRBG. Therefore, no changes to the testmgr code is needed.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Stephan Mueller <smueller@chronox.de>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
For the CTR DRBG, the drbg_state->scratchpad temp buffer (i.e. the
memory location immediately before the drbg_state->tfm variable
is the buffer that the BCC function operates on. BCC operates
blockwise. Making the temp buffer drbg_statelen(drbg) in size is
sufficient when the DRBG state length is a multiple of the block
size. For AES192 this is not the case and the length for temp is
insufficient (yes, that also means for such ciphers, the final
output of all BCC rounds are truncated before used to update the
state of the DRBG!!).
The patch enlarges the temp buffer from drbg_statelen to
drbg_statelen + drbg_blocklen to have sufficient space.
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Stephan Mueller <smueller@chronox.de>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Print the driver name that is being tested. The driver name can be
inferred parsing /proc/crypto but having it in the output is
clearer
Signed-off-by: Luca Clementi <luca.clementi@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Per further discussion with NIST, the requirements for FIPS state that
we only need to panic the system on failed kernel module signature checks
for crypto subsystem modules. This moves the fips-mode-only module
signature check out of the generic module loading code, into the crypto
subsystem, at points where we can catch both algorithm module loads and
mode module loads. At the same time, make CONFIG_CRYPTO_FIPS dependent on
CONFIG_MODULE_SIG, as this is entirely necessary for FIPS mode.
v2: remove extraneous blank line, perform checks in static inline
function, drop no longer necessary fips.h include.
CC: "David S. Miller" <davem@davemloft.net>
CC: Rusty Russell <rusty@rustcorp.com.au>
CC: Stephan Mueller <stephan.mueller@atsec.com>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
PKCS#7 validation requires access to the serial number and the raw names in an
X.509 certificate.
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Josh Boyer <jwboyer@redhat.com>
As reported by a static code analyzer, the code for the ordering of
the linked list can be simplified.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Stephan Mueller <smueller@chronox.de>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
kvfree() helper is now available, use it instead of open code it.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
This adds 4 test vectors for GHASH (of which one for chunked mode), making
a total of 5.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
The DRBG test code implements the CAVS test approach.
As discussed for the test vectors, all DRBG types are covered with
testing. However, not every backend cipher is covered with testing. To
prevent the testmgr from logging missing testing, the NULL test is
registered for all backend ciphers not covered with specific test cases.
All currently implemented DRBG types and backend ciphers are defined
in SP800-90A. Therefore, the fips_allowed flag is set for all.
Signed-off-by: Stephan Mueller <smueller@chronox.de>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
All types of the DRBG (CTR, HMAC, Hash) are covered with test vectors.
In addition, all permutations of use cases of the DRBG are covered:
* with and without predition resistance
* with and without additional information string
* with and without personalization string
As the DRBG implementation is agnositc of the specific backend cipher,
only test vectors for one specific backend cipher is used. For example:
the Hash DRBG uses the same code paths irrespectively of using SHA-256
or SHA-512. Thus, the test vectors for SHA-256 cover the testing of all
DRBG code paths of SHA-512.
Signed-off-by: Stephan Mueller <smueller@chronox.de>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
