[Cryptech Tech] Alpha board BOM and PCB design requirements

[Warren Kumari]

On Thursday, March 12, 2015, Fredrik Thulin <fredrik at thulin.net> wrote:

> On Wednesday, March 11, 2015 12:42:03 PM Павел Шатов wrote:
> ...
> > First of all, FPGAs have volatile internal configuration latches. FPGA
> > must be programmed every time it is powered up. When in Slave mode, FPGA
> > just sits and waits for someone to load bitstream into it and release
> > reset. When in Master mode, FPGA actively tries to read bitstream from
> > external memory and start working by itself. Mode can be switched by
> > applying either 0 or 1 to dedicated mode pins of an FPGA. Novena
> > actually supports both modes. By default it places on-board FPGA in
> > Slave mode (you have to run configure script to program an FPGA). Novena
> > also has dedicated EEPROM memory for FPGA bitstream, you can program
> > this memory and then insert a jumper to make FPGA automatically load
> > this bitstream upon power up.
>
> Thanks for the explanation. Another jumper to choose master/slave mode
> seems
> warranted then.
>
> > If Basil wants to physically disable writing to an FPGA, then you need
> > Master mode and a separate EEPROM for bitstream. I can suggest M25P128
> > from Micron for example (Artix-7 has 77 Mbits of config memory, so 128
> > Mbits memory is required at least). This memory has a dedicated write
> > protection pin, that can be connected to a jumper.
>
> Thanks for the suggestion. I don't have time to look more closely at that
> memory right now, but I take your word for it. I'll update the wiki with
> the
> suggestion to have PCB footprint for that EEPROM, unless someone has
> another
> suggestion.
>
> ...
> > If we go for discrete chips, we will have a more compact board. I was
> > asking from this perspective.
>
> From the Skype core call this Tuesday it seems we need to talk through
> whether
> a compact design is a design goal (or anti-design goal) for the Alpha or
> not
> during the f2f meeting next week.
>
> ...
> > So yes, we will need a wall adapter (12V maybe?)
>
> Sounds good.
>
> > > Related, when we talk battery do people think CR2032, 12V 6Ah Sealed
> Lead
> > > Acid battery or something else?
> >
> > Depends on what you want to be battery-powered. CR2032 should be enough
> > to power tamper detection circuit for several years.
>
> Yes. Operationally, maybe it makes sense to have a beefier battery on the
> HSM
> to avoid frequent lock-ups needing security officers to unlock the device
> if one
> doesn't have the most stable power? I don't know. Maybe we should just say
> "have 12v screw terminals for optional battery power source" in addition
> to a
> mandatory CR2032 for the tamper subsystem?
>
>
Well, one thing to keep in mind is that the CR2032 (or whatever) is going
to have to have enough power to monitor all of the tamper sensors
(temperature, vibration, optical, pressure, wire mesh, perhaps more exotic)
*and* have enough power left over to securely erase the MKM. Something that
we have not really discussed (but probably should) is having a process that
moves the MKM around every now and then, so that we don't get cell burn-in
(which apparently happens with SRAM too).

All of this suggests (to me at least) that we will need something much
beefier than a little coin-cell. For example, one of the HSMs I took apart
had 2 D cell NiCad batteries inside the tamper boundary.  One of the
standard "lifetime" items in many HSMs is the battery - often opening to
replace it makes the key material evaporate... Having an external battery
connector doesn't seem to be very common - either because the vendor thinks
it might leak EMF, or, more likely because they'd like to sell you a whole
new HSM every 5 - 10 years.



> > Btw, you want to
> > use MSP430 in this circuit. What is it going to do? Read some sensors
> > and toggle its outputs accordingly?
>
> Yes, and use SPI to erase the MKM in case any of the tamper sensors are
> triggered.
>
> > I suggest to use something smaller,
> > like PIC18 or PIC16 from Microchip. These processors are 8-bit and have
> > an order of magnitude less power consumption.
>
> We opted for the MSP430 since it is well known to us (me).
>
> > How is MSP430 programmed, btw? Will we need a special programming cable
> for
> it?
>
> The wiki mentions the use of the Spy-bi-wire interface to program it.
> Would be
> three pads IIRC. FWIW the MSP430 also supports serial programming using
> it's
> BSL. We could add the ability to program it from the ARM (if a programming-
> enabled jumper is present presumably).
>

I guess we could have the main tamper sensors all driven by a largish
battery (and kept charged by AC power when available), and have a small
coin cell inside the envelope. The battery / AC could power everything in
the envelope uner normal conditions, but live outside the envelope. The
main thing that coin cell would need to power is simply a check if it is
still getting 12V from the main battery -- as soon as that goes away it
assumes someone has cut power and zeroize. A CR2032 should be able to power
am MSP420 for the short while it would need to securely erase the key (as,
I guess, could a few chunky caps?)

W

[ Written on a plane. Apologies if this was all discussed already ]


> /Fredrik
>
> _______________________________________________
> Tech mailing list
> Tech at cryptech.is <javascript:;>
> https://lists.cryptech.is/listinfo/tech
>


-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cryptech.is/archives/tech/attachments/20150314/62e820b0/attachment.html>