[Cryptech Tech] Introduction

[Jason van Aardt]

Thank you Fredrik,
I have managed to check out source from

*The performance I was thinking of was more along the lines of signing*
*performance... The UARTs run at 921600 bps and unfortunately that is not
our*
*current speed bottleneck ;).*


May I ask what  the current signing performance is?

*We're planning to replace the FTDI chips with an alternative design by
Peter*
*Stuge, using small STM32s to do higher speed USB in the short term. For
the*
*long term, the extremely loose plan is to maybe connect a GigE interface
to*
*the FPGA. We did route the 16 pin GPIO header with that in mind.*


Would a PCIe interface be considered? Would USB3 be favoured?
If I may ask what are the predominant use cases for the HSM at the moment?
Is it mainly foreseen as a HSM for use with a Laptop?

Using the Gigabit Serdes on the Artix, it would be possible to include two
Gigabit ethernet ports,
and use the device as a bump in the wire for a L2/L3 encrypter.

Thanks
Jason




On Mon, Feb 20, 2017 at 2:02 PM, Fredrik Thulin <fredrik at thulin.net> wrote:

> On måndag 20 februari 2017 kl. 13:37:49 CET Jason van Aardt wrote:
> > Hi Fredrik,
> >
> > Nice to meet you virtually, May I ask if there is perhaps a list of the
> > planned update/additions  for the next release of hardware?
>
> This is what we've got: https://trac.cryptech.is/wiki/PostAlphaPlan
>
> > What is the current performance if I may ask?
> > Is the FTDI connected USB2.0 UART interface the primary interface
> > currently? What is the throughput on the Serial side at the moment?
>
> The performance I was thinking of was more along the lines of signing
> performance... The UARTs run at 921600 bps and unfortunately that is not
> our
> current speed bottleneck ;).
>
> We're planning to replace the FTDI chips with an alternative design by
> Peter
> Stuge, using small STM32s to do higher speed USB in the short term. For the
> long term, the extremely loose plan is to maybe connect a GigE interface to
> the FPGA. We did route the 16 pin GPIO header with that in mind.
>
> > I can see that Tamper detection is a big topic to cover based on the
> > current hardware.
> >
> > I see from the circuit diagram that the hardware tamper detection would
> be
> > related to both additional hardware(Tamperswitch on lid? possible tamper
> > Foil continuity circuitry?) as well as related code on the ATtiny, to
> wipe
> > the Master Keys stored on the 23K640-I/SN?
>
> Right
>
> > As well as the Keystore memory, 128 Mbit (N25Q128A13ESE*) ?
>
> No, everything in there is encrypted by the Master Key. I don't think there
> could ever be time and power available to securely wipe the keystore
> memory in
> case of a tamper event?
>
> > Need to look at "Zerorise" function in case of rapid erase via panic
> button
> > SW2, and a mechanical mechanism so that it is easy to zerorise, but not
> > easy to do inadvertently.
>
> We have the AVR code to wipe the Master key memory when the PANIC-button is
> pressed already. https://trac.cryptech.is/browser/sw/tamper
>
> The PANIC button is just a proof-of-concept, but could also be seen as a
> "Zeroize" function as it stands today.
>
> > Are there currently counter measures implemented against side channel
> > attacks eg. differential power analysis?
> > Using variable clock rates, additional nondeterministic loops etc.
>
> Nope, nothing. Suggestions welcome.
>
> > May I ask what is the best way to get a latest hardware release board?
> > Though the ordering at https://www.crowdsupply.com/
> cryptech/open-hardware-> security-module?
>
> Yes, that would be the best way.
>
> /Fredrik
>
>


-- 
Kind Regards
*Jason van Aardt*

+27 794939762
Skype : Jason.vanaardt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cryptech.is/archives/tech/attachments/20170221/daf20363/attachment-0001.html>