| Age | Commit message (Collapse) | Author |
|---|
|
key export/import (kekek = none, kek_len = 0), rather than separate RPCs.
|
|
Exported keys are wrapped with the MKM KEK, not a transit KEK, and can
only be imported back to the same HSM.
The idea is to support operators who have more keys than will fit on the
HSM, so they will cycle keys into and out of the HSM as needed.
NOTE that hashsig is, as always, special. The hashsig key has an internal
index that is updated on every signature. To prevent a hashsig key from
being re-imported with an old index (which would compromise the security
of the key), the hashsig key is disabled on export, and must be deleted
from the HSM before being re-imported.
|
|
|
|
|
|
|
|
|
|
|
|
Consistent user complaints about HSM login taking too long.
Underlying issue has both superficial and fundamental causes.
Superficial: Our PBKDF2 implementation is slow. We could almost
certainly make it faster by taking advantage of partial
pre-calculation (see notes in code) and by reenabling use of FPGA hash
cores when when checking passwords (which mgiht require linking the
bootloader against a separate libhal build to avoid chicken-and-egg
problem of needing FPGA to log into console to configure FPGA).
Fundamental: The PBKDF2 iteration counts we used to use (10,000
minimum, 20,000 default) are in line with current NIST
recommendations. The new, faster values (1,000 and 2,000,
respectively) are not, or, rather, they're in line with what NIST
recommended a decade ago. Well, OK, maybe the Coretex M4 is so slow
that it's living in the past, but still. The fundamental issue is
that anybody who can capture the encoded PIN can mount an offline
dictionary attack on it, so we'd like to make that expensive.
But the users are unhappy with the current behavior, so this change
falls back to the ancient technique of adding a delay (currently five
seconds, configurable at compile time) after a bad PIN, which makes it
painful to use the login function as an oracle but does nothing about
the offline dictionary attack problem.
Feh.
Note that users can still choose a higher iteration count, by setting
the iteration count via the console. It's just not the default out of
the box anymore.
|
|
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.
|
|
|
|
can find tfm.h again.
|
|
I can't see protecting the well-known default password against a
brute-force attack, and 100k iterations takes almost a minute, which
makes a terrible first impression.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
whines about some platform-dependent integer size issue, it's best to
use both an explicitly sized format (eg, "%lu") and an explicit cast
(eg, "(unsigned long)") when silencing the warning, otherwise it'll
just pop up again in different form on the next platform tested.
|
|
- TRNG cores are contiguous (but they still have their own mux, so occupy
a block of 16 cores).
- Use Rob's updated libhal in my new apps.
|
|
|
|
|
|
solution is to change to bs=32.
|
|
|
|
Are we having fun yet?
|
|
|
|
utility program, based on Paul's example in the core/platform/novena
repository.
|
