<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jul 26, 2017 at 9:39 AM, Ron Garret <span dir="ltr"><<a href="mailto:ron@flownet.com" target="_blank">ron@flownet.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><br><div><span class="gmail-"><div>On Jul 25, 2017, at 7:47 PM, Bill Cox <<a href="mailto:waywardgeek@gmail.com" target="_blank">waywardgeek@gmail.com</a>> wrote:</div><br class="gmail-m_652016558390785333Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">I also am a fan of the <a href="https://sc4.us/hsm/" target="_blank">low cost open SC4-HSM</a>,</div></blockquote><div><br></div></span><div>Thank you!  :-)</div><span class="gmail-"><br><blockquote type="cite"><div dir="ltr"> but I am interested in devices with better physical security.</div></blockquote><div><br></div></span><div>Can you elaborate on what you mean by this?  The SC4-HSM can be made secure against an adversary with physical possession of the device.  If you’re willing to type in a pass-phrase, it can even be made secure against an adversary capable of decapping the SoC.  What more do you want?</div><span class="gmail-HOEnZb"><font color="#888888"><div><br></div><div>rg</div><div><br></div></font></span></div></div></blockquote></div><div class="gmail_extra">I have a different threat model than most HSMs:  I assume the attacker could be:</div><div class="gmail_extra"><br></div><div class="gmail_extra">- Malware on the host computer</div><div class="gmail_extra">- The owner of the device, so pass phrases do not help</div><div class="gmail_extra">- A botnet of HSM emulators, so I'll need hardware attestation</div><div class="gmail_extra">- A group of hackers motivated enough to buy a large number of HSMs and PWN them to control the network</div><div class="gmail_extra"><br></div>I think it would be useful to have:</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_extra">- Basic tamper resistance</div><div class="gmail_extra"><br></div><div class="gmail_extra">Having an accessible debug port would be bad.  This would allow an attacker to see secret keys.  There is a debug port on the  STM32F405R.  Do you somehow disable it?</div><div class="gmail_extra"><br></div><div class="gmail_extra">Neither a safe nor passphrase would help, because the owner is in the threat model.  I do not want to lock it down like a Tivo, but instead have the hardware erase all secrets, including the attestation key, before allowing the owner to reprogram the entire device.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Tamper detection would be useful.  Random physical auditing of nodes could help determine when the fraction of PWNed nodes is getting too high, but only if we can tell when a device has been PWNed.  We could use glitter nail polish and a photo of the original device to detect physical intrusion.  It is also important to thwart side-channel attacks, such as extracting secrets using timing, power analysis, or RF emissions.  We do not need to defend against experts since they are rare, but a you-tube video should not be enough to enable most HSM owners to easily PWN their device through side-channels.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">- Verifiable boot and firmware updates.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I'll need to be able to run a boot loader that verifies firmware signatures before upgrading, and in some cases, it will need to erase secrets before upgrading.  Can the STM32F405R do that?</div><div class="gmail_extra"><br></div><div class="gmail_extra">- ECC (P256 is fine), AES, and SHA256 acceleration to enable reasonable transactions per second (as in more than 1).</div><div class="gmail_extra"><br></div><div class="gmail_extra">The main metric here is hardware cost per transaction per second.  The K81 is pretty fast at 150 MHz, but it is slower than the  STM32F405R, and the K81 costs about 30% more.  I'm assuming the crypto engines are equivalent...</div><div class="gmail_extra"><br></div><div class="gmail_extra">- Several KiB of SRAM, say a minimum of 4KiB</div><div class="gmail_extra"><br></div><div class="gmail_extra">SRAM is divided up between applications, and one applications cannot read another's SRAM.  More SRAM is better.  The K81's 256KiB of SRAM is more than I need as is the 192KiB on the  STM32F405R.</div><div class="gmail_extra"><br></div><div class="gmail_extra">- A lot of flash, say at least 100KiB</div><div class="gmail_extra"><br></div><div class="gmail_extra">Flash would be divided between the virtual machine emulator and the application it runs, so each app only gets a fraction of flash memory.  The K81's 256KiB of flash seems low, but probably good enough.  The 1MiB of the  STM32F405R is a nice upgrade.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Do you think a SC4-HSM might be close to supporting this application's needs?  If not, would you have any interest in having my help developing a new HSM that would?</div><div class="gmail_extra"><br></div><div class="gmail_extra">Bill</div></div></div>