| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Various fixes extracted from the abandoned(-for-now?) reuse-cores
branch, principally:
* Change hal_core_alloc*() to support core reuse and to pick the
least-recently-used core of a particular type otherwise;
* Replace assert() and printf() calls with hal_assert() and hal_log(),
respectively. assert() is particularly useless on the HSM, since it
sends its error message into hyperspace then hangs the HSM.
|
|
|
|
|
|
|
|
|
|
|
|
pkey_open() now looks in both keystores rather than requiring the user
to know. The chance of collision with randomly-generated UUID is low
enough that we really ought to be able to present a single namespace.
So now we do.
pkey_match() now takes a couple of extra arguments which allow a
single search to cover both keystores, as well as matching for
specific key flags. The former interface was pretty much useless for
anything involving flags, and required the user to issue a separate
call for each keystore.
User wheel is now exempt from the per-session key lookup constraints,
Whether this is a good idea or not is an interesting question, but the
whole PKCS #11 derived per-session key thing is weird to begin with,
and having keystore listings on the console deliberately ignore
session keys was just too confusing.
|
|
Still missing Python script to drive backup process, and need to do
something about setting the EXPORTABLE key flag for this to be useful.
|
|
|
|
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.
|
|
Support for core/pkey/ecdsa256 and core/pkey/ecdsa384.
|
|
|
|
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.
|
|
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.
|
|
|
|
|
|
|
|
which was using the old (pre-hal_core_t) calling sequence.
|
|
|
|
|
|
|
|
the simpler format which PKCS #11 uses, since we have to support the
latter in any case and it's not worth the complexity of supporting both.
|
|
public key extraction functions on hold pending ASN.1 cleanup.
|
|
|
|
|
|
|
|
Compiles, not yet tested.
|
|
bit more obvious when we've forgotten to do this than when we've
forgotten to call fp_init() or memset(). Convert rsa.c to use the
one-element-array idiom so we can get stop prefixing every bignum
reference with "&".
|
|
|
|
mixed Jacobian-affine addition, so go with that. Minor additional
clean-up and comments.
|
|
mixed Jacobian-affine coordinates, per a suggestion from Pavel. Old
code still present under compile time conditional for easy comparison,
but will probably go away soon along with a bit of minor cleanup.
|
|
|
|
than necessary when writing private key to DER.
|
|
|
|
|
|
RSA code; use simpler model (pointer to incomplete structure) used in
ECDSA code. Refactor RSA code to use shared ASN.1 routines.
|
|
and code comments.
|
|
|
|
|
|
|
|
|
|
|
|
|
