<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Jul 26, 2017, at 11:10 AM, Bill Cox <<a href="mailto:waywardgeek@gmail.com">waywardgeek@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><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></div></blockquote><div><br></div><div>I think we may have a fundamental disconnect here. The SC4-HSM is not intended to be used in a data center. It’s intended to be used by an individual who has it in their physical possession and plugs it in to a USB port of a host that is also by necessity in their physical possession. So there is no “network” that an attacker could possibly control.</div><div><br></div><div>Also, the SC4-HSM has an on-board display and push-buttons which are integral to its security model. You could emulate an SC4-HSM, but absent some really major breakthroughs in virtual reality technology you could not hide the fact that you were emulating it. :-)</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra">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></div></blockquote><div><br></div><div>Yes. There are two ways to disable the debug port, one temporary, the other permanent. These are described in detail in the documentation.</div><div><br></div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_extra">Neither a safe nor passphrase would help, because the owner is in the threat model.</div></div></div></blockquote><div><br></div><div>I don’t understand this at all. How can the owner of a device be an attacker? That seems impossible by definition.</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_extra">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></div></blockquote><div><br></div><div>Yes, this is exactly how the reversible lock-down feature works.</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_extra">Tamper detection would be useful.</div></div></div></blockquote><div><br></div><div>The SC4-HSM does not have this, though it could be added. However, this would undermine what I consider to be one of the SC4-HSM’s significant features: the ability to open the device and visually inspect the circuitry to insure that what is in the package is what is supposed to be there. If you’re willing to trust your vendor then you might as well just use an iPod Touch.</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_extra">- Verifiable boot and firmware updates.</div></div></div></blockquote><div><br></div><div>The SC4-HSM gives you access to DFU mode, which gives you direct hardware-level access to the flash. There is no bootloader. (You could, of course, upload one if you wanted to, but why would you want to?)</div><div><br></div><div>In addition, all of the current firmware and the tool chain is open-source. It doesn’t get any more verifiable than that. (Note however that the current version of the firmware has NOT been audited. Verifiable != verified.)</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_extra">I'll need to be able to run a boot loader that verifies firmware signatures before upgrading</div></div></div></blockquote><div><br></div><div>The SC4-HSM is designed to minimize the trust you need to put in third parties. The only part of the design that is not independently verifiable is the SoC chip itself. Everything else is either open to inspection or under the user’s direct control. This is *more* secure than firmware signatures because those require that you trust both the bootloader and the signer of the firmware.</div><div><br></div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_extra">, and in some cases, it will need to erase secrets before upgrading. Can the STM32F405R do that?</div></div></div></blockquote><div><br></div><div>Yes. See above.</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><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></div></blockquote><div><br></div><div>The STMF405 does not have AES and SHA in hardware, but the STMF415 does (that is the only difference between these two chips). The current production run has 405 chips but I would be more than happy to make a batch of HSMs with 415s if that were desirable. However, the limiting factor on performance for any given application is much more likely to be the USB2 interface than the fact that you have to do your crypto in software.</div><div><br></div><div>The SC4-HSM computes an Ed25519 signature in about half a second. I haven’t timed P256, but it seems about the same.</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><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></div></blockquote><br></div><div>As you have noted, the SC4-HSM has more than enough RAM and Flash for your needs, but it was not designed for high-throughput. It was designed to be e.g. a U2F token or a bitCoin wallet for personal use by a single individual who carries it around in their pocket. A significant portion of the cost is in the display (not just the hardware but the assembly costs associated with it) which you don’t need in a data center.</div><div><br></div><div>However, if you want to explore a low-cost HSM for data center use I would be more than happy to discuss it with you.</div><div><br></div><div>rg</div><div><br></div></body></html>