[Cryptech Core] Proposal for new FPGA architecture

Paul Selkirk paul at psgd.org
Wed Nov 7 22:37:03 UTC 2018


I have to admit, I've read through this several times, and I'm still not
sure I understand it completely. However, rather than get deep in the
weeds on details, I want to address what I think are the main points.

If I understand correctly, the proposal is to unwrap private keys to a
buffer in the core_selector (on the FPGA), then send that key (or
components thereof) directly to other cores to do, say, a signing operation.

The first problem is that the unwrapped key is actually ASN.1-encoded
data. core_selector would need to recursively decode the key in
hardware, to extract the usable key components.

Secondly, RSA keys contain some "precalculated" speed-up fields that are
specific to the systolic modexpa7 core. These are actually only
generated on the first use of the key, so the key needs to be updated in
the keystore, with these additional fields. So core_selector would also
need to be able to do the ASN.1 encoding, in key-specific formats, and
hand it off to keywrap.

Finally, there's the issue of multi-tasking. The software supports
multiple concurrent clients. If one task loads a key, then yields to
another task, which loads another key into the same core_selector
buffer, then we have a problem. (And task yields happen frequently, e.g.
on every call to hal_io_wait.) This might be alleviated by partitioning
the buffer into multiple key caches (with coordination between tasks and
core_selector about who has what piece).

If we had fully-featured signing cores, then we could unwrap and decode
keys directly to them, but at the moment we have pieces - modexp and
point multipliers - and the software is intimately involved in all
aspects of key generation, signing, and verification.

Or I might have missed the point entirely.

				paul


More information about the Core mailing list