We were using bn_modexp() to perform a simple modular square.
A bn_modexp_word() does this faster.
BRANCH=none
BUG=b:68167013
TEST=generate 128 primes from prng seed and verify they're same as before; tcg_test passes
Change-Id: I411a7d3fe2d68f93dc40bf74b941a637f9aa20ed
Reviewed-on: https://chromium-review.googlesource.com/778057
Commit-Ready: Marius Schilder <mschilder@chromium.org>
Tested-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Events used when TPM task is running are defined in two different
places, one of them shared with other boards running on H1.
Let's avoid collision by redefining Cr50 only events to be different
from shared ones used by dcrypto.
BRANCH=cr50
BUG=b:68729265
TEST=verified that there is no more 'tpm_reset_request: already
scheduled' messages generated when TPM is reset when performing
long dcrypto operation.
Change-Id: Ic9517fa98be21f3ef5f19b82c593d96b0ddbaf6b
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/756914
Reviewed-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Duncan Laurie <dlaurie@google.com>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Add a PERSO_AUTH appid to sign data passed through the
AUTH mn50.
Add a signer command to start and generate signatures.
Clean UART init to avoid spurious nonprinting characters
that will contaminate the siugnature.
BUG=b:36910757
BRANCH=None
TEST=generates signature for uart and spi
Signed-off-by: Nick Sanders <nsanders@chromium.org>
Change-Id: I5fc3c4ee34898421060b57b774a09734f6a1bae5
Reviewed-on: https://chromium-review.googlesource.com/670984
Reviewed-by: Marius Schilder <mschilder@chromium.org>
To aid with severe flash space shortage, let's enable
CRYPTO_TEST_SETUP only if CR50_DEV is set to a value exceeding 1.
board/mn50/board.h used to define CR50_DEV without any value assigned
to it, correct this so that the check in dcrypto.h works when mn50 is
built.
BRANCH=cr50
BUG=b:65253310
TEST=compiling with CR50-DEV=1 vs CR50_DEV=2 saves more than
17.5 Kbytes per RW image.
Change-Id: Ic77fa45b1a8f7631efa91c08e63438d412196eed
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/690993
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The array storing deltas between sequential prime numbers could be
compressed, as the vast majority of the values in the array does not
require more than 4 buts to store.
The new storage format is as follows:
- each differential value (difference between two consecutive primes)
is halved and stored in 4 bits, two halved values are packed per
byte.
- I the first one of of the two sequential halved values exceeds 0xf,
it is stored in the array followed by a zero, stored as is (without
halving), thus taking two bytes.
- if the second one of the two sequential halved values exceeds 0xf,
both values are stored in the array as is, both prepended by zeros,
thus taking 4 bytes.
The code calculating the sequential primes parses the array according
to this format. Storing the primes in this format allows to shave from
the image size 1848 bytes.
BRANCH=cr50
BUG=b:65253310, b:65287300
TEST=verified that test_rsa test from the tpmtest suite passes.
verified that the list of prime numbers printed out when
PRINT_PRIMES is defined and test_rsa is ran is the same before
and after this patch.
Change-Id: Ifdc2858a48f868ef816ccb4e351d9f60703d16e7
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/664253
Reviewed-by: Nagendra Modadugu <ngm@google.com>
When compilation is enabled, this function prints all prime numbers
generated using the PRIME_DELTAS array.
BRANCH=cr50
BUG=none
TEST=verified that prime numbers are printed out when running rsa_test.py
Change-Id: I37961aad146c4aeecca9a84550f313450e6c5853
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/683074
Reviewed-by: Shawn N <shawnn@chromium.org>
Implement the RFC 6979 to get a deterministic integer k when doing the
ECDSA signing of the x.509 certificates used by U2F and particularly
individual attestation mechanism, rather than using the random generator
as per the original ECDSA algorithm.
So the generated certs have bit-for-bit identical signatures when the
content is identical.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=cr50
BUG=b:35545754
TEST=pass U2FTest and manually dump several individual attestation certs,
run the "rfc6779" console command when enabled.
Change-Id: I7b73eee6d5a863aae9a7eec49db884151bad5ab4
Reviewed-on: https://chromium-review.googlesource.com/558073
Commit-Ready: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Split bn_modexp() into three variants:
bn_modexp() for large exponents (as before)
bn_modexp_word() for single word public exponents
bn_modexp_blinded() for large exponents w/ randomization
We randomize bn_modexp_blinded() with:
1) pick 64 bit random R1 and compute R1 ** -1 and R1 ** pubexp, mod N.
2) multiply input by R1 ** pubexp
3) pick 64 bit random R2 and add (e*d*R2 - R2) to private exponent (i.e.
a random multiple of phi(N))
4) exponentiate
5) multiply output w/ R1 ** -1 to obtain expected result
Since we enlarge the exponent, bn_modexp_blinded() is slower than
bn_modexp(). We only use bn_modexp_blinded() when private exponents are
in play and we have phi(N) available.
Also refactored the combined p256 and rsa dcrypto binary blob into two
parts. And added unique first word to each dcrypto blob to make code
caching reliable.
The TPM task stack maxes out at 8040/8192 in tcg_test due to increased
stack usage of bn_modexp_blinded() but is still within safe bounds,
with 88 byte redzone.
BRANCH=cr50
BUG=b:35587382,b:35587381
TEST=buildall, tcg_test (200+)
Change-Id: Ied1f908418f31f8025363179537aa4ebd2c80420
Reviewed-on: https://chromium-review.googlesource.com/540684
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Marius Schilder <mschilder@chromium.org>
Holding the mutex just around the dcrypto_call is not enough: dcrypto
instruction memory content might change in presence of multiple calling
tasks.
Switching to broad acquire/release pattern instead.
Note to sub-projects: pair your dcrypto_init(_and_lock) w/ matching dcrypto_unlock
BUG=none
BRANCH=cr50
TEST=tcg_tests pass
Change-Id: Idb7f2d79ce533db95cab51d89e3869ecf9f3d499
Reviewed-on: https://chromium-review.googlesource.com/535916
Commit-Ready: Marius Schilder <mschilder@chromium.org>
Tested-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Nadim Taha <ntaha@chromium.org>
In the FIDO U2F Authenticator Transports Extension, the list of
transports will be extended to:
FIDOU2FTransports ::= BIT STRING {
bluetoothRadio(0), -- Bluetooth Classic
bluetoothLowEnergyRadio(1),
uSB(2),
nFC(3),
uSBInternal(4)
}
Given our implementation is internal, update the value from bit(2) uSB
to bit(4) uSBInternal.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=cr50
BUG=b:35545754
TEST=with follow-up CLs, run U2FTest on Eve
and manually verify the individual attestation certificate
with an ASN.1 parser.
Change-Id: I62fe72ffed9b7eb34e31164fded46f458e5cbc16
Reviewed-on: https://chromium-review.googlesource.com/536775
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Before this change, the current task id was cached in dcrypto_init() if
it hadn't already been called. This resulted in the task id of the first
caller to dcrypto_init() being cached until reset.
The cached task id was used when generating notifications that hardware
crypto operations were complete. This was fine as long as the task that
invoked dcrypto_init() was also the task that invoked dcrypto_call(). If
this wasn't the case, the task that invoked dcrypto_init() would be
notified of an event it wasn't expecting and the task that invoked
dcrypto_call() would not be notified and would time out.
This change locks a mutex and then caches the current task id in
dcrypto_call() before invoking the hardware operation so that the
correct task will be notified when the operation has completed.
BRANCH=none
BUG=none
TEST=make -j buildall
Change-Id: I30a920d85359cc990d77c88b1607bbe4cf674206
Reviewed-on: https://chromium-review.googlesource.com/522350
Commit-Ready: Carl Hamilton <carlh@chromium.org>
Tested-by: Marius Schilder <mschilder@chromium.org>
Tested-by: Carl Hamilton <carlh@chromium.org>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Add primitives to build x.509 certificates encoded in ASN.1 DER,
as a building block for the U2F feature.
Mostly copied over from the cr52 code-base.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=cr50
BUG=b:35545754
TEST=with follow-up CLs, run U2FTest on Eve
and manually verify the individual attestation certificate with an ASN.1
parser.
Change-Id: Ie90730d8c401c661c8ab3b1b19631337b7390e9c
Reviewed-on: https://chromium-review.googlesource.com/518134
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
This change configures the SHA engine to
a) enable random stalls at 12% during regular
operation through SHA API's, and b) enables
random stalls at 25% when doing key-ladder
operations.
TCG tests continue to complete in ~20 minutes
(i.e. no noticeable slowdown).
BRANCH=none
BUG=b:38315169
TEST=TCG tests pass
Change-Id: Id4b541cdd3d51c57979a93f71a6291cca8eb1844
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/508172
Commit-Ready: Nagendra Modadugu <ngm@google.com>
Tested-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Make the dcrypto ecdsa verify code check that r,s are in range, and
not depend on the caller C code to have done so.
For instance, s equal to 0 would result in infinite loop during
computation of its modular inverse.
BRANCH=none
BUG=b:35587381
TEST=TCG tests pass
Change-Id: I13f7811be030aed9feaa11c45dc68d4bfd08fb76
Reviewed-on: https://chromium-review.googlesource.com/508819
Commit-Ready: Marius Schilder <mschilder@chromium.org>
Tested-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
always_memset() implements a version of memset
that survives compiler optimization. This change
replaces instances of the (placeholder) call
dcrypto_memset() with always_memset().
Also add a couple of missing memsets and
fix related TODOs by replacing memset()
with always_memset().
BRANCH=none
BUG=none
TEST=TCG tests pass
Change-Id: I742393852ed5be9f74048eea7244af7be027dd0e
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/501368
Commit-Ready: Nagendra Modadugu <ngm@google.com>
Tested-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Andrey Pronin <apronin@chromium.org>
The cipher command implementation had to change to account for reduced
heap size and to improve coverage.
Note that the goal of this command is not to verify correctness of the
encryption services provided by the dcrypto, but to allow to exercise
the crypto engine on multiple passes, each time using the same clear
text but different initialization vector.
BRANCH=none
BUG=chrome-os-partner:62260
TEST=ran cipher command on a few devices:
> cip
Will wait up to 4074 ms
running 1000 iterations
blob size 7111 at 1e020
original data 8f3d99fbfcbd26dd0c4d8dc444d106ee
hashed data 826a4e9b04d214fbbd5fbf4e0fba8068
Encryption results: min 1128 us, max 1456 us, average 1180 us
Decryption results: min 1124 us, max 7348 us, average 1193 us
>
Change-Id: Idf72b355dce0f288d4a3d8a065bc08eb9c4f6bc3
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/434167
Reviewed-by: Nagendra Modadugu <ngm@google.com>
The previous implementation of DCRYPTO_app_cipher
consumed roughly 16ms to cipher a 16kB buffer
(i.e. performance that is far worse than the
hardware is capable of).
This change speeds up the implementation by about
85%, to the tune of roughly 2.2ms for a 16kB buffer.
The gains originate from various sources: loop
unrolling, data-pipelining, eliminating local
variables (to reduce register pressure), eliminating
support for unaligned input/output data, compiling
hot code with -O (rather the default -Os), and
using the hidden key-ladder, which need only be
setup once per reset.
This change also switches from AES-128 to AES-256.
BRANCH=none
BUG=chrome-os-partner:62260
TEST=make buildall succeeds;
cipher command succeeds;
TCG tests pass
Change-Id: I133741be6d9f1353d6ae732d0e863b4b18cc8c9e
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/433359
Commit-Ready: Nagendra Modadugu <ngm@google.com>
Tested-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Add support for verifying messages signed
with 4096-bit RSA keys. Such messages may
be generated by host side applications.
Also update tpmtest.py to test 4k verification.
BRANCH=none
BUG=none
TEST=added new tests to tpmtest.py; TCG tests pass
Change-Id: I7450bd710c154c68c030ce176bfe7becbfbcb729
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/428220
Commit-Ready: Nagendra Modadugu <ngm@google.com>
Tested-by: Marius Schilder <mschilder@chromium.org>
Tested-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
On boards based on the g chip cryptographic functions come from
hardware, they should be implemented in chip/g as opposed to a
particular board.
The common modules (like nvmem) should be using some generic API,
which hopefully will be implemented by other chips, or could be
replaced by a purely software implementation where crypto hardware
support is not available.
Crypto API definition is being added in include/ and the g chip
implementation (a wrapper around dcrypto functions) is being added in
chip/g.
test/nvmem_vars.h needed to be edited to avoid conflict with
<string.h>.
BRANCH=none
BUG=chrome-os-partner:62260
TEST=make buildall -j still passes. Booting reef with the new image
works fine too.
Change-Id: Ifef281215f89239966882ecbe3e90c8351b9b91a
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/431313
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Nagendra Modadugu <ngm@google.com>
This change introduces DCRYPTO_app_cipher(), an encrypt/decrypt
function that accepts an IV and corresponding data. Typical
restrictions on IV reuse apply. The key is derived from the hardware
based on the type of the RW image signature (dev vs prod).
A console command is added to exercise the cipher function.
Since stack requirements of the dcrypto code exceed the console task
allowance, the actual command is executed on the HOOKs task context.
BRANCH=none
BUG=chrome-os-partner:55331
TEST=make buildall -j passes. Running the cipher command from the
console succeeds:
> cipher
original data ad67d44cb4feffff6b3b334635eb9612
rv 0x01, out data 861dc395a2fc745ca886a703cb02a897, time 16636 us
rv 0x01, orig. data ad67d44cb4feffff6b3b334635eb9612, time 17004 us
sha1 before and after match!
>
Change-Id: I7686d8c8489c1b8a984859c3be4f82c338573c6f
Signed-off-by: nagendra modadugu <ngm@google.com>
Signed-off-by: Marius Schilder <mschilder@chromium.org>
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/428171
Reviewed-by: Nagendra Modadugu <ngm@google.com>
Add functions that derive application specific keys based
on FRK2. For the moment, derived keys need to be manually
copied into the AES engine. Since key-ladder state depends
on the code-signer (prod vs. dev), application derived keys
are also different in the two modes. Thus ciphertext blobs
produced by prod-signed code cannot be decrypted by dev-signed
code.
To minimize stack requirements on the hook_task, the SHA
context in DCRYPTO_appkey_init() is placed in allocated/freed
memory. This SHA object will become unnecessary once the
AES engine is seeded directly from the key-ladder.
BRANCH=none
BUG=chrome-os-partner:55331
TEST=pending
Change-Id: Ifb274b15e61be317e02ec31fc52f9a41e06dcba3
Signed-off-by: nagendra modadugu <ngm@google.com>
Signed-off-by: Marius Schilder <mschilder@chromium.org>
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/428170
Reviewed-by: Nagendra Modadugu <ngm@google.com>
There's no indication that the h/w AES function fails,
but checking the return value prevents applications
from silently proceeding and failing at a future time
(e.g. NVMEM encryption).
BRANCH=none
BUG=chrome-os-partner:55331
TEST=tpmtest.py passes
Change-Id: I8e3a9426ec31a1b0798aface55c636dc1c707b34
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/430371
Commit-Ready: Marius Schilder <mschilder@chromium.org>
Tested-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
DCRYPTO_HMAC_SHA256_init makes two calls to DCRYPTO_SHA256_init()
without an intervening HASH_final() call. This is incorrect usage
of the the hashing API, and results in the hardware SHA engine
getting locked for the life-time of the process (and resulting
in all future hash calls falling back to the software implementation).
This bug manifested itself when introducing NVRAM encryption, which
requires the hardware SHA engine to be available for key generation.
BRANCH=none
BUG=chrome-os-partner:55331
TEST=TCG tests pass
Change-Id: Ia4ccb6a6d64636c4618ef775291442975f3f1f92
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/430154
Commit-Ready: Nagendra Modadugu <ngm@google.com>
Tested-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
This function belongs in dcrypto as it relies heavily on the crypto
hardware; also, it will be handy to be able to use this function in
other cases.
BRANCH=none
BUG=chrome-os-partner:55331
TEST=buildall still builds. TPM manufacturing still works too.
Change-Id: If2e70eaa71a76e8374b98f4667cb54ea6253b760
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/428169
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Callers may not need computation of the public key.
Making this optional speeds this routine up.
Cr50 never passes in NULL for any argument, so is not affected.
BUG=none
TEST=build
BRANCH=none
Change-Id: Ia0077a35064f53b53f51867254aaa51eac6c55d8
Reviewed-on: https://chromium-review.googlesource.com/427058
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Marius Schilder <mschilder@chromium.org>
Perform PKCS1-padding-only signing for RSASSA if hashing algorithm is
TPM_ALG_NULL.
This feature is guarded by SUPPORT_PADDING_ONLY_RSASSA macro in
tpm2/Implementation.h.
BUG=chrome-os-partner:60967
BRANCH=none
TEST=On a unowned machine with TPM2: corp enroll, login, install
a network certificate (gECC or GMC), then:
a) retrieve the public key from the installed certificate
LIBCHAPS=`ls /usr/lib**/libchaps.so`
CERTID=`pkcs11-tool --module=$LIBCHAPS --slot=1 --type=cert \
-O | grep "ID:" | awk '{print $2}'`
pkcs11-tool --module=$LIBCHAPS --slot=1 --id=$CERTID \
--type=cert -r > /tmp/cert
openssl x509 -inform der -pubkey -noout -in /tmp/cert > /tmp/pub.key
b) sign a sample text using the private key for the certificate and
MD5-RSA-PKCS mechanism, not supported by TPM2_Sign command:
echo "ABCDEF" > /tmp/1.txt
pkcs11-tool --module=$LIBCHAPS --slot=1 --id=$CERTID --sign \
-i /tmp/1.txt -o /tmp/1.sig -m MD5-RSA-PKCS
c) verify signature:
openssl dgst -md5 -verify /tmp/pub.key \
-signature /tmp/1.sig /tmp/1.txt
Step (b) should succeed and step (c) should return "Verified OK".
Change-Id: I0d7a11c48cdb04e37748f7255b98e9e023481a96
Signed-off-by: Andrey Pronin <apronin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/420854
Reviewed-by: Darren Krahn <dkrahn@chromium.org>
Provide the calling stubs for p256 sign, verify, point mul, etc.
This also drops third_party/cryptoc/p256_ec and p256_ecdsa from the
image. And fewer routines from cryptoc/p256.c remain as well.
BRANCH=none
BUG=none
TEST=tcg_tests pass, test/tpm_test/tpmtest.py pass
Change-Id: Ib6c35f5d34a2c8434e78b44cbef8b69802734c50
Signed-off-by: Marius Schilder <mschilder@google.com>
Reviewed-on: https://chromium-review.googlesource.com/422942
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Commit-Queue: Marius Schilder <mschilder@chromium.org>
Tested-by: Marius Schilder <mschilder@chromium.org>
Trybot-Ready: Marius Schilder <mschilder@chromium.org>
Avoid building and including crypto test code in
prod builds: only define CRYPTO_TEST_SETUP when
CR50_DEV is defined.
At HEAD, this change drops the size of prod ec.RW.bin
from 200704 to 188416.
BRANCH=none
BUG=chrome-os-partner:54104
TEST=build succeeds
Change-Id: I1e6018ec917dbe71cb445206ce232b8ea7a46cb1
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/418489
Commit-Ready: Nagendra Modadugu <ngm@google.com>
Tested-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Andrey Pronin <apronin@chromium.org>
This change adds the plumbing for SHA-384 & 512.
The actual hash implementation is software only,
and a part of the third_party/cryptoc library.
BRANCH=none
BUG=none
CQ-DEPEND=CL:418263
TEST=TCG tests pass
Change-Id: Iba7e6d420fd7fa0bce4ad9061e00f9275ecf4d72
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/417888
Commit-Ready: Nagendra Modadugu <ngm@google.com>
Tested-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Andrey Pronin <apronin@chromium.org>
This change adds support for signing SHA-384 & 512 hashes
when using PKCS#1 padding (CR50 does not support
SHA-384 & 512 at the moment, the actual hashing is to be
done on the host).
BRANCH=none
BUG=chrome-os-partner:59754
TEST=TCG tests pass
Change-Id: I78e774639a7968cbb50e58cdd0bf479e64123630
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/415218
Commit-Ready: Nagendra Modadugu <ngm@google.com>
Tested-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Andrey Pronin <apronin@chromium.org>
Various cryptographic operations leak timing
information if comparisons are not executed
in constant time. This change adds DCRYPTO_equals(),
a constant runtime comparator.
Also replace crypto related callsites that used
memcmp() as a binary comparator.
BUG=none
BRANCH=none
TEST=tcg tests pass
Change-Id: I3d3da3c0524c3a349d60675902d1f2d338ad455f
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/410163
Commit-Ready: Nagendra Modadugu <ngm@google.com>
Tested-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
We previously used binary extended Euclid. That does not perform well
when inverting a small public exponent.
We also abused that routine to perform the division of n by one of its
factors. Really did not perform well there either.
This CL introduces a classic Knuth long division and a normal extended
Euclid based on that.
This drops the execution time of the common inversions into the single
msec range (vs. multiple seconds before..)
TEST=tcg_tests pass the usual 381/391; test/tpm_test/bn_test passes.
BUG=chrome-os-partner:57422
BRANCH=none
Change-Id: Ic9b4aecd0356fcab3e823dbd60c5b228a87447d3
Reviewed-on: https://chromium-review.googlesource.com/406940
Commit-Ready: Marius Schilder <mschilder@chromium.org>
Tested-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
If both e, and MOD are even, then no modular
inverse exists. This change adds handling
for this set of inputs. Adding this change
for completeness (there are no dcrypto library
call paths that generate both e and N as even).
BRANCH=none
BUG=chrome-os-partner:47524
TEST=bn_test passes
Change-Id: Ide64f980501175e9b6078efff92086d12bc1ae2d
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/376180
Commit-Ready: Nagendra Modadugu <ngm@google.com>
Tested-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
TCG test CPCTPM_TC2_2_22_02_08 installs an RSA key
for which p does not divide the modulus, and subsequently
the test is expected to fail accordingly.
This change adds the check necessary to pass this test --
a check that p divides N.
Also removed dangling function declaration for bn_mul().
BRANCH=none
BUG=chrome-os-partner:43025,chrome-os-partner:47524
BUG=chrome-os-partner:50115
TEST=TCG test CPCTPM_TC2_2_22_02_08 passes consistently
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/360968
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
(cherry picked from commit c4430ecac8f77a05ac4071679de1535e0da2779e)
(cherry picked from commit 832d04b5b8cebf702d2ec00051615f827d2d16e1)
Change-Id: If2ffc6260ae848d75e93263a37e84f0ed7d301a0
Reviewed-on: https://chromium-review.googlesource.com/362117
Commit-Ready: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Primes generated for RSA keys need to hold the following
property (public_exponent mod p) > 1 in order for the
private exponent to exist. This change adds this check
for the public exponent RSA_F4 (65537).
BRANCH=none
BUG=chrome-os-partner:43025,chrome-os-partner:47524
BUG=chrome-os-partner:50115,chrome-os-partner:55260
TEST=test full personalize + cros_ack verify cert flow
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/360662
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@google.com>
(cherry picked from commit 1c37f84ae7fae9f5841421447c7f235790ab6a93)
(cherry picked from commit b2c1678b27c79a2c93f5519e00161243fa0a5d88)
Change-Id: I87bd898cc3750bf1e492bc263edb6eac1edf2a17
Reviewed-on: https://chromium-review.googlesource.com/362115
Commit-Ready: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
