| Age | Commit message (Collapse) | Author |
|---|
|
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).
|
|
* block_status is now a separate field from block_type, rather than
being a composite value.
* block_status is checked directly for allowed values in block_read(),
and is excluded from the CRC, simplifying the tombstone logic and
removing the need for a second CRC field.
* Added header fields to allow for objects too large to fit in a
single block (8192-bit RSA keys, any key with enough opaque
attributes attached). So far this is just the header changes, it's
not (yet) full support for multi-block objects.
|
|
Order of operations is tricky when updating flash blocks, because the
process is not atomic and we want to leave the index in a consistent
state if something fails.
|
|
|
|
block_read() no longer needs `fast` argument.
block_zero() now just zeros first page of block.
|
|
Running this check in constant time probably isn't necessary, but it
plugs a (somewhat far-fetched) timing leak and is easy enough. While
we're at this, we also skip the CRC check, which is irrelevant here.
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
|
|
The KEK (Key Encryption Key) is first fetched from the FPGA that gets it
from the volatile Master Key Memory (that in theory has tamper*kek_len =
len protection with wiping), and secondly from flash.
The flash option is meant for development/evaluation use using an Alpha
board where the Master Key Memory is not battery backed. For any serious
use of an Alpha, an option is to enter the master key into the volatile
MKM on each power-on as a way to unlock the keystore.
|
|
|
|
Thanks Rob!
|
|
|
|
|
|
|
|
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.
|
|
|
|
public key extraction functions on hold pending ASN.1 cleanup.
|
