| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
Except for torture tests, we never really used the hideously complex
multi-block capabilities of the ksng version of the flash keystore,
among other reasons because the only keys large enough to trigger the
multi-block code were slow enough to constitute torture on their own.
So we can preserve backwards compatabliity simply by including the
former *chunk fields (renamed legacy* here) in the CRC and checking
for the expected single-block key values. We probably want to include
everything in the CRC in any case except when there's an explicit
reason omit something, so, this is cheap, just a bit obscure.
At some point in the future we can phase out support for the backwards
compatible values, but there's no particular hurry about it unless we
want to reuse those fields for some other purpose.
|
|
Most keystore methods already followed this rule, but hal_ks_*_init()
and hal_ks_*_logout() were confused, in different ways.
|
|
The internal keystore API has changed enough since where the "logout"
branch forked that a plain merge would have no prayer of compiling,
must less running. So this merge goes well beyond manual conflict
resolution: it salvages the useful code from the "logout" branch, with
additional code as needed to reimplement the functionality. Sorry.
|
|
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.
|
