<br><br>On Thursday, March 12, 2015, Fredrik Thulin <<a href="mailto:fredrik@thulin.net">fredrik@thulin.net</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wednesday, March 11, 2015 12:42:03 PM Павел Шатов wrote:<br>
...<br>
> First of all, FPGAs have volatile internal configuration latches. FPGA<br>
> must be programmed every time it is powered up. When in Slave mode, FPGA<br>
> just sits and waits for someone to load bitstream into it and release<br>
> reset. When in Master mode, FPGA actively tries to read bitstream from<br>
> external memory and start working by itself. Mode can be switched by<br>
> applying either 0 or 1 to dedicated mode pins of an FPGA. Novena<br>
> actually supports both modes. By default it places on-board FPGA in<br>
> Slave mode (you have to run configure script to program an FPGA). Novena<br>
> also has dedicated EEPROM memory for FPGA bitstream, you can program<br>
> this memory and then insert a jumper to make FPGA automatically load<br>
> this bitstream upon power up.<br>
<br>
Thanks for the explanation. Another jumper to choose master/slave mode seems<br>
warranted then.<br>
<br>
> If Basil wants to physically disable writing to an FPGA, then you need<br>
> Master mode and a separate EEPROM for bitstream. I can suggest M25P128<br>
> from Micron for example (Artix-7 has 77 Mbits of config memory, so 128<br>
> Mbits memory is required at least). This memory has a dedicated write<br>
> protection pin, that can be connected to a jumper.<br>
<br>
Thanks for the suggestion. I don't have time to look more closely at that<br>
memory right now, but I take your word for it. I'll update the wiki with the<br>
suggestion to have PCB footprint for that EEPROM, unless someone has another<br>
suggestion.<br>
<br>
...<br>
> If we go for discrete chips, we will have a more compact board. I was<br>
> asking from this perspective.<br>
<br>
>From the Skype core call this Tuesday it seems we need to talk through whether<br>
a compact design is a design goal (or anti-design goal) for the Alpha or not<br>
during the f2f meeting next week.<br>
<br>
...<br>
> So yes, we will need a wall adapter (12V maybe?)<br>
<br>
Sounds good.<br>
<br>
> > Related, when we talk battery do people think CR2032, 12V 6Ah Sealed Lead<br>
> > Acid battery or something else?<br>
><br>
> Depends on what you want to be battery-powered. CR2032 should be enough<br>
> to power tamper detection circuit for several years.<br>
<br>
Yes. Operationally, maybe it makes sense to have a beefier battery on the HSM<br>
to avoid frequent lock-ups needing security officers to unlock the device if one<br>
doesn't have the most stable power? I don't know. Maybe we should just say<br>
"have 12v screw terminals for optional battery power source" in addition to a<br>
mandatory CR2032 for the tamper subsystem?<br>
<br></blockquote><div><br></div><div>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). </div><div><br></div><div>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.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> Btw, you want to<br>
> use MSP430 in this circuit. What is it going to do? Read some sensors<br>
> and toggle its outputs accordingly?<br>
<br>
Yes, and use SPI to erase the MKM in case any of the tamper sensors are<br>
triggered.<br>
<br>
> I suggest to use something smaller,<br>
> like PIC18 or PIC16 from Microchip. These processors are 8-bit and have<br>
> an order of magnitude less power consumption.<br>
<br>
We opted for the MSP430 since it is well known to us (me).<br>
<br>
> How is MSP430 programmed, btw? Will we need a special programming cable for<br>
it?<br>
<br>
The wiki mentions the use of the Spy-bi-wire interface to program it. Would be<br>
three pads IIRC. FWIW the MSP430 also supports serial programming using it's<br>
BSL. We could add the ability to program it from the ARM (if a programming-<br>
enabled jumper is present presumably).<br></blockquote><div><br></div><div>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?)</div><div><br></div><div>W</div><div> </div><div>[ Written on a plane. Apologies if this was all discussed already ] </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
/Fredrik<br>
<br>
_______________________________________________<br>
Tech mailing list<br>
<a href="javascript:;" onclick="_e(event, 'cvml', 'Tech@cryptech.is')">Tech@cryptech.is</a><br>
<a href="https://lists.cryptech.is/listinfo/tech" target="_blank">https://lists.cryptech.is/listinfo/tech</a><br>
</blockquote><br><br>-- <br>I don't think the execution is relevant when it was obviously a bad idea in the first place.<br>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.<br>   ---maf<br>