Age | Commit message (Collapse) | Author |
|
Cosmetic cleanup of pkey_slot along the way.
|
|
|
|
|
|
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.
|
|
Still not yet expected to compile, much less run, but getting closer.
|
|
|
|
|
|
|
|
|
|
Whack masterkey code to meet libhal coding standards, such as they
are.
Started layout of new ks_flash data structures but no changes to
functions or flash usage yet.
MKM initialization from flash placed under compile-time conditional
with warning because it's a dangerous kludge that should go away.
Started getting rid of obsolete keystore code; ks_mmap.c kept for now,
until I get around to merging the useful bits into ks_volatile.
|
|
|
|
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.
|
|
This will need refactoring once we have a proper test for whether the
HSM is initializing after receiving a fresh software load.
|
|
store unencrypted public keys (we don't allow this for private keys).
Yet another screwball feature to support PKCS #11, sigh. Anyway,
with this change, mixed-mode builds should work again.
|
|
|
|
|
|
|
|
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.
|
|
are secure (the one in ks_flash.c is a stub, and the others are for
cases where we have no secure hardware in which to store the KEK).
These are primarily for testing, since in the long run the entire
software implementation of AES-keywrap will be replaced by Verilog
which never lets software see the unwrapped key. Or so says current
theory. For the moment, we just need something that will let us test
the rest of the RPC and keystore mechanisms.
|
|
and dispatch.
|
|
committing now so Paul has a chance to look at the current RPC API.
|
|
|
|
public key extraction functions on hold pending ASN.1 cleanup.
|