| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Borrowing an idea from PyCrypto, we substitute CSPRNG output for the
value of a decrypted KEK if the PKCS #1.5 type 02 block format check
fails. Done properly, this should be very close to constant-time, and
should make it harder to use hal_rpc_pkey_import() as an oracle.
|
|
In the long run this code will fork for two different purposes:
a) A user backup script, which need not handle ASN.1 or crypto, thus
can (and should) be really simple; and
b) Unit test code for the key export and import functions.
So far, hal_rpc_pkey_export() appears to be working, at least under
light testing (result of unpacking everything looks like a key,
anyway, haven't tested the unpacked key yet).
Still need to write test code for hal_rpc_pkey_import().
|
|
Among other things, it turns out that this works better if one
remembers to write the RPC server dispatch code as well as the client
code, doh.
|
|
|
|
|
|
Still missing Python script to drive backup process, and need to do
something about setting the EXPORTABLE key flag for this to be useful.
|
|
Handle AlgorithmIdentifier.parameters as in SubjectPublicKeyInfo: the
field is OPTIONAL, but it's usually set to NULL if no OID is present.
I have a vague memory that this is fallout from a specification error
years ago in which the OPTIONAL was accidently left out. Whatever.
|
|
|
|
|
|
|
|
|
|
A few parsing problems remaining, mostly with objects large enough
that PKCS #8 may have pushed them over some buffer size or another.
These are all with RSA, where the Python code (PyCrypto) already
supported PKCS #8, so most likely it's a problem in the new C code.
Python ECDSA PKCS #8 shim code is nasty and could use some cleanup.
If practical, we might want to sub-class ecdsa.keys.SigningKey; we
might also want to flesh this out into something we can send upstream
to the author of the Python ecdsa library.
|
|
|
|
Compiles, not yet tested. Existing tests need conversion to PKCS #8
before we can do anything useful with this.
Once everything uses PKCS #8 instead of algorithm-specific formats, we
can revisit API issues like whether hal_rpc_pkey_load() should still
be taking `type` and `curve` arguments.
|
|
|
|
This will almost certainly merge into test scripts or libhal.py at
some later date, right now just get it into git for archive.
|
|
|
|
|
|
Support for the core/pkey/ecdsa{256,384} cores is cooked before the
branch on which it was based. Oops. Time to backport.
See pymux branch for original commit history. git should do the right
thing when the pymux branch is cooked enough to merge back to the ksng
or master branches.
|
|
Support for core/pkey/ecdsa256 and core/pkey/ecdsa384.
|
|
Exporting CFLAGS as an environment variable turns out to interact
badly with certain other settings here. I *think* this only happens
when we use one of the shorthand targets which re-runs make in the
same directory with non-default settings, but this is complicated
enough without having to remember which voodoo triggers it. So
instead of exporting CFLAGS as an environment variable we just pass it
on the command line in the handful of cases where it's needed.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The stock assert() implementation turns out to be problematic in the
stm32 environment, due to the lack of an output device, which makes
"assert(foo)" equivalent to "if (!foo) abort()", leading to silent
hangs.
We probably ought to reimplement assert() to do something more useful,
but, for now, avoid using it for "impossible" conditions which we do
seem to be triggering anyway, like the occasional point-not-on-curve
errors we get for points we ourselves have picked when testing
multiple ECDSA clients in parallel. This should never happen, and we
need to figure out what's causing it, but hanging the HSM when it
happens does not help very much.
assert() is somewhat problematic in an embedded environment in any
case, since anything that can go wrong really should have some kind of
recovery action, but in some of the low-probability cases it's far
from obvious what sane recovery action we could possibly take.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
libhal and PKCS #11 have slightly different models of private keys: in
libhal, a "private key" object is really a keypair, while in PKCS #11
a private key really is a naked private key. This was a deliberate
design decision in libhal, both for simplicity and to better support
user interfaces other than PKCS #11, so we'd rather not change it.
This difference doesn't matter very much for RSA keys in PKCS #11,
where the private key components are a superset of the public key
components anyway, but the PKCS #11 template for ECDSA private keys
doesn't allow setting public key components with C_CreateObject().
Fortunately, computing the public components of an ECDSA key pair from
the private key is straightforward, so we just do that when needed.
|
|
|
|
|
|
|
|
Merge Paul's review comments.
|
|
|
|
Log exceptions immediately when failing a test; doesn't replace
backtrace at end of test run, but since a full test run can take a
while it's useful to know what failed closer to when it happened.
More conditionals to skip tests which require external Python crypto
packages when those packages aren't installed.
|
|
|
|
|
|
|
|
|
|
Attempts to use Pavel's ecdsa256 base point multiplier instead of
software point multiplier when selecting new random points (that is,
when generating P-256 keys or P-256 signatures). Resulting points
pass the point validation test (point_is_on_curve()) but the resulting
signatures are invalid. Don't know why yet. Seems like an odd
combination, as one would expect random garbage to fail validation.
In any case: this commit is intended to archive progress so far, and
perhaps see if somebody else can spot what's wrong. As presently
coded, this wouldn't be suitable for production use even if it worked.
NB: As I understand it, the ecdsa256 core is *not* a general purpose
point multiplier even just for the P-256 curve. Rather, it is
strictly a base point multiplier: it takes a single scalar as input,
and returns the X,Y affine coordinates of the curve's base point
multiplied by that scalar. This is essentially the eliptic curve
portion of the computation involved in picking a random point for key
or signature generation, but is not useful for signature validation.
See the README.md in Pavel's source repository for further details.
|
|
Probably reached the point of diminishing returns for trying to get
probing to work better. Best option, where practical, is to avoid
probing completely; when necessary, best run it once then avoid
repeating it. cryptech_muxd will probe if requested, but probing is
never going to be reliable. Dedicated VID:PID would be much better.
|
|
|
|
|
