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 <fred...@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
_______________________________________________ Tech mailing list Tech@cryptech.is https://lists.cryptech.is/listinfo/tech
