| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Uncoordinated attempts to allocate two modexpa7 cores leads to deadlock if
multiple clients try to do concurrent RSA signing operations.
The simplest solution (back off and retry) could theoretically lead to
resource starvation, but we haven't seen it in actual testing.
|
|
This branch was sitting for long enough that master had been through a
cleanup pass, so beware of accidental reversions.
|
|
|
|
|
|
Snapshot of mostly but not entirely working code to include the extra
ModExpA7 key components in the keystore. Need to investigate whether
a more compact representation is practical for these components, as
the current one bloats the key object so much that a bare 4096-bit key
won't fit in a single hash block, and there may not be enough room for
PKCS #11 attributes even for smaller keys.
If more compact representation not possible or insufficient, the other
option is to double the size of a keystore object, making it two flash
subsectors for a total of 8192 octets. Which would of course halve
the number of keys we can store and require a bunch of little tweaks
all through the ks code (particularly flash erase), so definitely
worth trying for a more compact representation first.
|
|
|
|
|
|
Work in progress. Probably won't even compile, much less run.
Requires corresponding new core/math/modexpa7 core.
No support (yet) for ASN.1 encoding of speedup factors or storage of
same in keystore.
No support (yet) for running CRT algorithm in parallel cores.
Minor cleanup of ancient bus I/O code, including EIM and I2C bus code
we'll probably never use again.
|
|
Need to refactor init sequence slightly (again), this time to humor
the bootloader, which has its own special read-only view of the PIN
block in the token keystore.
|
|
|
|
|
|
Support for variable-length keystore objects significantly complicates
the keystore implementation, including serious some serious code bloat
and a complex recovery algorithm to deal with crashes or loss of power
at exactly the wrong time. Perhaps we don't really need this?
So this is an experiment to see whether we can replace variable-length
keystore objects with fixed-length, perhaps with a compile time option
to let us make the fixed object length be 8192 bytes instead of 4096
bytes when needed to hold things like large RSA keys.
First pass on this is just throwing away nearly 1,000 lines of
excessively complex code. The result probably won't even compile yet,
but it's already significantly easier to read.
|
|
|
|
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.
|
|
Now that we use PKCS #8 format for private keys, all key formats we
use include ASN.1 AlgorithmIdentifier field describing the key, so
specifying key type and curve as arguments to hal_rpc_pkey_load() is
neither necessary nor particularly useful.
|
|
Still missing Python script to drive backup process, and need to do
something about setting the EXPORTABLE key flag for this to be useful.
|
|
|
|
|
|
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.
|
|
PKCS #11 supports zero-length attributes (eg, CKA_LABEL) so hack of
using zero length attribute as NIL value won't work, instead we use a
slightly more portable version of the hack PKCS #11 uses (PKCS #11
stuffs -1 into a CK_ULONG, we stuff 0xFFFFFFFF into a uint32_t).
ks_attribute.c code was trying too hard and tripping over its own
socks. Instead of trying to maintain attributes[] in place during
modification, we now perform the minimum necessary change then re-scan
the block. This is (very slightly) slower but more robust, both
because the scan code has better error checking and because it's the
scan code that we want to be sure is happy before committing a change.
Rename hal_rpc_pkey_attribute_t to hal_pkey_attribute_t.
|
|
|
|
hal_rpc_pkey_list() was a simplistic solution that worked when the
keystore only supported a handful of keys and we needed a quick
temporary solution in time for a workshop. It doesn't handle large
numbers of keys well, and while we could fix that, all of its
functionality is now available via more robust API functions, so
simplifying the API by deleting it seems best.
Since this change required mucking with dispatch vectors yet again, it
converts them to use C99 "designated initializer" syntax.
|
|
|
|
pkey attribute API is now just set_attributes() and get_attributes().
|
|
Passes minimal unit-testing and the same minimal tests report that it
does deliver the desired performance speed-up. More testing and much
cleanup still needed.
Attribute API not quite stable yet, we're probably going to want to
remove all the singleton attribute operations from the RPC protocol,
and it turns out that ks_delete_attributes() has enough code in common
with ks_set_attributes() that it makes more sense to handle the former
as a special case of the latter.
|
|
This is not yet complete, only the ks_volatile driver supports it,
ks_flash will be a bit more complicated and isn't written yet.
At the moment, this adds a complete duplicate set of
{set,get,delete}_attributes() functions in parallel to the earlier
{set,get,delete}_attribute() functions. We will almost certainly want
to get rid of the duplicates, probably (but not necessarily) the
entire single-attribute suite. At the moment, though, we want both
sets so we can compare execution speeds of the two sets of functions.
|
|
Incidental minor refactoring of hal_rpc_server_dispatch().
|
|
The debugging code was for tracking down what turned out to be a race
condition in the Alpha's flash driver code (see sw/stm32); much of
this was temporary, and will be removed in a (near) future commit, but
some of the techniques were useful and belong in the repository in
case we need to pull them back for something similar in the future.
hal_ks_index_fsck() attempts to diagnose all the things I found wrong
in the ks_flash index after one long series of errors. As presently
written, it doesn't attempt to fix anything, just diagnose errors: the
intent is that we can call this, before and after every modification
if necessary, to poinpoint exactly which calls introduce errors. Once
things stablize a bit, we may want to crank down the number of calls
to this (it's a bit expensive, since it checks the entire index), and
perhaps add the ability to clean up whatever errors it might find; the
latter might be a good candidate for a CLI command.
|
|
|
|
This is more complicated than I'd have liked, because the PKCS #11
semantics are (much) more complicated than just "are you logged in?"
New code passes basic testing with libhal.py and the PKCS #11 unit
tests, but there are still unexplored corner cases to be checked.
Private token objects remain simple. Code which does not need PKCS
HAL_KEY_FLAG_TOKEN and avoid HAL_KEY_FLAG_PUBLIC.
|
|
In retrospect it's obvious that this never needed to be an
input/output argument, as its value will always be the same as the
last value in the returned array. Doh. So simplify the RPC and call
sequence slightly by removing the unnecessary output value.
|
|
Passes PKCS #11 "make test" but nothing uses the new attribute code yet.
Refactored some of the flash block update code.
Attribute code is annoyingly verbose, might be possible to refactor
some of that.
|
|
Mostly this is another checkpoint (still passes PKCS #11 "make test").
ks_volatile.c now contains support for per-session object visibility;
this may need more work to support things like a CLI view of all
objects regardless of session. Adding this required minor changes to
the keystore and pkey APIs, mostly because sessions are per-client.
ks_volatile.c also contains an untested first cut at attribute
support. Attribute support in ks_flash.c still under construction.
|
|
RPC calls which pass a pkey handle don't need to pass a session
handle, because the session handle is already in the HSM's pkey slot
object; pkey RPC calls which don't pass a pkey argument do need to
pass a session handle.
This change percolates down to the keystore driver, because only the
keystore driver knows whether that particular keystore cares about
session handles.
|
|
This is mostly to archive a commit where PKCS #11 "make test" still
works after converting the ks_volatile code to use SDRAM allocated at
startup instead of (large) static variables.
The attribute code itself is incomplete at this point.
|
|
The main reason for supporting multi-block objects is to allow the
PKCS #11 code to attach more attributes than will fit comfortably in a
single flash block. This may turn out to be unnecessary once we've
fleshed out the attribute storage and retrieval code; if so, we can
simplify the code, but this way the keystore won't impose arbitrary
(and somewhat inscrutable) size limits on PKCS #11 attributes for
large keys.
This snapshot passes light testing (PKCS #11 "make test" runs), but
the tombstone recovery code in ks_init() is a bit involved, and needs
more testing with simulated failures (probably induced under GDB).
|
|
|
|
|
|
Now that key names are UUIDs generated by the HSM, there's no real
need to specify type key type when looking up a key, and removing the
`type` argument allows a few simplifications of both the internal
keystore API and of client code calling the public RPC API.
|
|
Changes to implement a revised keystore API. This code probably won't
even compile properly yet, and almost certainly will not run, but most
of the expected changes are complete at this point. Main points:
* Key names are now UUIDs, and are generated by the HSM, not the client.
* Keystore API no longer assumes that key database is resident in
memory (original API was written on the assumption that the keystore
flash would be mapped into the HSM CPU's address space, but
apparently the board and flash drivers don't really support that).
A few other changes have probably crept in, but the bulk of this
changeset is just following through implications of the above, some of
which percolate all the way back to the public RPC API.
|
|
|
|
|
|
|
|
Find a suitable core, and mark it busy. Don't forget to release it as soon
as you're done. This has a knock-on effect of un-const'ing core arguments
and struct fields in a lot of places, and it moves some core checks around.
|
|
|
|
|
|
|
|
|
|
|
