| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
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.
|
|
New keystore code requires slightly different cleanup to avoid leaking
pkey handle table slots. Pricetag for reducing the amount of data
duplicated between pkey and keystore layers.
|
|
Fixes for various minor issues found while integrating with sw/stm32.
Moving the in-memory keystore (PKCS #11 session objects, etc) from the
client library to the HSM was on the near term to-do list in any case,
doing it now turned out to be the easiest way to solve one of the
build problems.
|
|
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.
|
|
PKCS #11 expects a DigestInfo rather than a raw digest when passing a
pre-computed digest for PKCS #1.5 signature or verification, so the
rpc_pkey signature and verification calls do too. This requires
special case handling of RSA when the user passes a digest handle in
mixed mode. Annoying, but PKCS #1.5 is weird enoug that there's no
way to avoid some kind of special case handling, this approach has the
advantage of not requiring us to parse and reconstruct the ASN.1, and
is probably what PKCS #11 has trained software to expect in any case.
|
|
|
|
|
|
hsmbully tests strange RSA key sizes (eg, 3416 bits) which don't fall
on word boundaries, at which point we have buffer padding and
alignment issues when performing RSA signature verification.
|
|
Temporary nature of null string as key name is not enforced by the
keystore code, it's just a convention to allow callers to generate a
keypair, obtain the public key, hash that to a Subject Key Identifier
(SKI), and rename the key using the SKI as the new name.
This is a compromise to let us use SKI-based key names in PKCS #11
while keeping the keystore code simple.
|
|
|
|
|
|
|
|
|
|
silliness, with a bit of PKCS #1.5 padding silliness for desert.
|
|
committing now so Paul has a chance to look at the current RPC API.
|
|
|
|
|
|
|
|
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.
|
