[Cryptech Tech] Aes keywrap core ready for test and benchmarking

[Joachim Strömbergson]

Aloha!

First: Thanks Paul for the driver work and posting the benchmarking.


On 2018-08-20 21:43, Paul Selkirk wrote:
> To reproduce this:
> 
> Checkout branch 'master' on repo:
>   user/js/keywrap

We should probably move the core to core/cipher.


> Enhancement requests:

(Thanks for writing these.)


>> The core does not implement the magic value calculation as specified
>> in RFC 5649. Nor does it do any padding of object to a complete 8
>> byte block. The caller needs to calculate the 64-bit magic value and
>> store it in the A registers.
> 
> It seems like this shouldn't be too hard to do in the core. It already
> has the length in the RLEN register, which directly gives it both the
> MLI field of the AIV ("magic value"), and the padding length.

No. Now that we have a working core adding this functionality is not a
big stretch. Esp the AIV is easy to calculate. The padding will require
some read-modify-write mangling. But it is basically a couple of extra
init states. No problem. I'll add tasks for doing this.


>> Due to address space limitations in the cryptech cores, the core
>> implements bank switching (with four banks). The caller must write
>> to the BANK register to ensure that subsequent writes to the DATA
>> addresses ends up in the correct bank. And similarly, the caller
>> needs to set the bank as needed when reading the wrapped/unwrapped
>> object from the core. Basically the first 128 words of the object is
>> stored in bank 0, the next 128 in bank 1 etc.
> 
> I would like to get rid of the bank switching, and unroll the block
> memory into a set of contiguous core register blocks (where each block
> is 256 4-byte register), as Pavel did for modexps6 and modexpa7. Of
> course, this would require agreement about the block memory size,
> between keywrap_mem.v, core/platform/common/config/core.cfg, and
> sw/libhal/core.c. At present, the HSM keystore uses fixed-size
> 8096-byte slots, so that's the practical limit. (In the long term,
> each core should encode its own length, right after its name and
> version, and we could remove the core-specific knowledge from
> core.c. But that's a project for another day.)

Ok. Expanding the address space is no big problem as long as it is ok to
do so. Lets discuss the details and I'll implement the fix. The banks
was just to allow us to keep the API address space to 256 addresses.
This is a minor change in terms of core logic.


> Finally, I would like this core to directly fetch the KEK from the
> MKM, rather than continuing to require the caller to fetch the KEK via
> the mkmif core, and feed it right back to the keywrap core. Keeping
> the KEK out of RAM can only improve the security of the device.

This would require the keywrap core to become the mkm master. No big
change really. Things to consider are for example how to generate and
store the MKM. And we need to consider how to test this functionality in
a good way to ensure that we don't end up killing HSMs.

But in general, instantiating the mkm core inside keywrap and adding a
simple FSM that perform read operation at init is not hard to do.

I can write a proposal and we can discuss it.

-- 
Med vänlig hälsning, Yours

Joachim Strömbergson
========================================================================
                               Assured AB
========================================================================

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <https://lists.cryptech.is/archives/tech/attachments/20180821/eb343ac7/attachment.sig>