---
title: Silicon Salon Notes 2021-09-14
tags: Notes
---

# Silicon Salon Notes 2021-09-14

#### 2022-09-14 9am PDT

Slides (follow along):

https://hackmd.io/9v0ABBXoTyyqzUcF3vDEsg?view

These Notes:

https://hackmd.io/4UynsiS_SBO9EIDGuZ2AHw?edit

Overflow notes (if we reach the limit): https://hackmd.io/dGMAkoo7RYqXhVpM2vy8hg

## Attendees

NOTE: This document is public. Don't add your name here, or any private contact details, if you don't want them be listed as a participant in the final output from this Silicon Salon. [Chatham House rules apply](https://hackmd.io/@bc-silicon-salon/rkxbd6rFw9#/14) for all quotes.

* Christopher Allen (@ChristopherA)
* Bryan Bishop (@Kanzure)
*

## Notetaking

# Introduction

A lot of this is about conversations between people who care. You guys clearly care [so we have what we need]. We had about a dozen registrations from people that I've never heard of before. Hopefully there weren't any snafus with eventbrite notifications or things of that nature. New people, that's good, right? Or they at least paid the $25 ticket. We're going to wait just a couple of minutes before getting started. We'll be introducing everyone as we go along. There's a few high-level things I want to mention.

Rebooting the Web of Trust is in The Hague in 2 weeks. We will be diving deeper into the collaborative seed tooling and some of the directed graph work that we have been doing there that will facilitate credentials and alternatives to decentralized identifiers under JSONID etc. I don't know if any of you are interested in that category but it's another focus area of Blockchain Commons.

For those of you who are doing bitcoin, we are now working on a full-round trip of creation of multisig accounts, verifying that multisig accounts are valid, and spending PSBTs using airgaps. We would love to have more partners in that area. It will probably come back to the Silicon Salon group as more chips become available to support things like Schnorr and taproot and some of the other newer primitives. I'm looking forward to that.

Further discussion will be facilitated after the presentations and it will be anonymized. Please don't quote someone directly; we'd like to have free expression of different kinds of ideals and other work without it impacting eachother's work. Let's try to keep attributions to be only with permission. Someone will be presenting first; you can obviously quote anything in his actual presentation because we will make that available. But if he says something interesting afterwards, and you want to quote it, then ask him first about attribution. All of this content will be put on the siliconsalon.info site like we did last time.

This meeting is being recorded.

Thank you everyone for joining us this morning. This is our second Silicon Salon, this time on the topic of supply chain security, firmware and boot and those associated topics. This is a collaborative session. If you want to view the slides directly, there is a URL for them which I will put in the chatroom. There also is collaborative notes. If you're familiar with Bryan Bishop's work, he is amazing at transcribing things, but if you have spceific comments or corrections, links you want to add, etc, then rather than putting them in the chat here that I just sent you these two links through, it's better to put the links directly into the hackmd that way we will have them be captured.

What is Blockchain Commons? Our goal is to bring together blockchain, web3, and web5 and other stakeholders together to collaboratively develop interoperable infrastructure. We design decentralized solutions where everyone wins. To do that, we have to act as a neutral not-for-profit that enables people to control their digital destiny. I am Christopher Allen and architect of Blockchain Commons and coauthor of the DID standard, organizer of Rebooting Web of Trust, and back in the day co-author of the TLS 1.0 standard.

What is Silicon Salon? Our goal with these is to facilitate wallet developers and semiconductor chip manufacturers to identify problems and assess needs. That's very much what we're doing in this salon. We want to take the results from these group salons and learn to collaboratively engineer interoperable specifications. There's silicon logic, cryptographic logic, APIs, and then all the topics today. There's a lot of opportunities for cooperation here. How do we create the right incentives for cooperation? We want to evangelize these solutions to the larger ecosystem, and we want to support our partners with reference code and test suites so that they can develop their own versions of all of these different tools.

Who are you? We have some semiconductor chip designers, we have Bunnie Studios, Tropic Square, wallet hardware manufacturers like Proxy and Foundation Devices, the team behind Validated Lightning Signer, and others from Blockchain Commons involvement, and we have other people in the ecosystem that play other parts like Bitmark with NFT, Unchained Capital offers some collaborative custody, Blockchain Bird promoting blockchain self-sovereignty, and then the Human Rights Foundation. Among us, we have some cryptographers, protocol designers, and engineers. These are the people participating in these types of events.

Our last event was focused on the high-level of requirements for secure hardware, pain points and architectures. We had 5 presentations. Out of all the different discussions, we decided the most important thing to start with was boot, firmware and supply chain which we will be exploring today. How do we boot securely? How do we ensure the firmware is secure? How can firmware be updated? How do we ensure the supply chain has not been compromised?

The process today is starting with multiple presentations, probably about an hour and a half. We will take a brief standing break and then we will go through a Q&A on a lot of these different topics, brainstorm with each other, and reserving the last 15 minutes for "who are the next steps and who else do we want to be involved in the next Silicon Salon that we could invite who otherwise might not attend". I hope you can stay for the whole meeting.

Chatham house rules: you are free to use this information, but not attributing identities to quotes. Although we are recording, we will not be sharing the recording of the Q&A. We are only recording to be able to provide the presentations and anonymized summaries. If we take a quote even without your name, and you don't want it, we will be glad to remove that from the final summary.

We have 5 presentations today beginning with Bunnie Studios, then Cramium, Proxy, Foundation Devices, and conclude with Validated Lightning Signing. We are starting with level0 or layer minus 1 the silicon layer, and then layer zero, and Validated Lightning Signer is dealing with requirements on layer 2 so it's good that we have a good mix on the hardware requirements today. Bunnie, do you want to share your screen?

# Bunnie Studios

Secure bootloader and self-provisioning

I just got back from some travels in the United States and now I'm in the Singapore time zone. I got COVID while traveling, and I'm just getting over the end of it so I might crash out before the end of this session and I'll catch up on the notes.

I was asked to talk a bit about the project I'm working on called Precursor and specifically about the secure bootloader and self-provisioning aspects of it.

First I will familiarize people with what Precursor is. This is a picture of the device itself. It's basically a mobile handheld device that you can put in your pocket and walk around with it. It's desgined for communication, voice comms, authentication, a password vault application that we can use to keep TOTP and U2F FIDO passwords that sort of thing. There seems to be enthusiasm about turning it into a cryptocurrency wallet of some sort, but that's not our direct mission. We're focused on communication applications.

The types of people we design this for are primarily at-risk users like politically or financially, perhaps people under threat from advanced persistent threats, or developers and enthusiasts who are interested in secure technology. We also put emphasis on the device design from a bottom-up so that it's not an English-only speaking audience but a global audience. On a piece of hardware like this, you can swap out keyboard overlays with an overlay that has different language glyphs on it for example.

## Why a device?

Anothe rquestion I wanted to cover before getting into the nitty gritty... why are we doing a device and not just a chip? When we think about security, it's not just private keys, but all your private matters. If you want to protect the end-user secrets, then you have to think about the screens and keyboards being logged so this boils down to a secure IO problem where if you're on Android and you install an IME then this pop-up will show saying hey by the way this thing can keep all your passwords and personal data and you click OK because, what can possibly go wrong? I have a security enclave, where I put my secrets, but I just consented to a keyboard logger, and this is a wonderful backdoor that makes some regimes not care about end-to-end encryption at all because some IMEs are very hard and only a few of them can't handle certain languages.

We want to make sure from the tips of your fingers, to the pixels hitting your eyes, that the entire path is trusted and you have some onfidence that the data -- you know the provenance of the data.

## System level diagram

We have a trusted domain and a non-trusted domain. We throw the wifi stuff and power control into the untrusted domain, and in the trusted domain we have a soft FPGA and audio and keyboard and other things are in the trusted domain.

## Long-term arc

We use an FPGA system to let us vet out use cases, develop apps, but eventually we want to tape this out to ASIC. The fact that we're using FPGA helps us get around a supply chain problem because we can say, well a user can goahead and compile their own CPU with a random seed and makes it harder to insert a backdoor at the CPU level. For cost reasons and reach and performance reasons, we will eventually migrate to an ASIC but I'm very happy that we have a full system that we can run on an FPGA right now that we can vet all the use cases and kernel and the apps. It's a handy dev platform to have such full coverage of the end-application before we do an ASIC.

## Security is a system, not a component

We include the software supply chain in our threat model. We like to think about all the pieces that go into building the hardware, in addition to the pieces that go into the firmware. I had a talk called "From boot to root in one hour". That's the long version of this talk. Boot to root in one hour goes through basically everything from the reset vector itself, it goes all the way back to the SoC Verilog and python descriptions and talks about the process of compiling it, the boot vectors, the secure bootloaders, train of trust, to the root keys provisioned on the device. If you want to take a deep dive, watch that presentation.

We try to track all of the pieces we're putting into the software supply chain so that we know at least how big the attack surface is. Realistically these tools are so complicated that I can't say with any confidence that we know there are no backdoors in any given tool, but at least we have enumerated the tools and the problems we could have with them. In particular, when we think about the firmware side, when we write rust code we try hard to not pull in lots of third-party libraries. Libraries are too bloated to minimize software supply chain attack surface. This all compiles down into FPGA stuff.

## SoC

It's a RISC 32 CPU that gets compiled into the FPGA. On the right hand side of this diagram, we have some memory mapped on, then we have the cryptography complex with all our crypto-hardware primitives in it. From the standpoint of doing secure boot, these are the areas we want to look at: the CPU, some on-chip RAM and ROM, and then we have some keyrom the size of that dictated by the size of the FPGA and we don't use all the bits in there right now. We have a Curve25519 engine in hardware and a sha512 engine in hardware. Those are secure-boot-relevant items.

## Layout of Artifacts

In terms of the artifacts involved in boot, the actual source code... everything in this project is open-source and published online. You can look at the kernel signature check code. The lifecycle of the secrets is that they start with the sort of inside the SPI-ROM... the lower half is the SPI-ROM containing code at rest, the bitstream is encrypted with an aes256 key decrypted by the FPGA, which creates a soft-core, and inside the soft-core has a boot ROM itself and it has a set of keys... and then it does a signature check on the next-level loader, and we have only 30 kilobytes of space. This is a minimal just a signature check shim and run thing. The loader itself then goes and inspects the kernel, sets up the page tables, pulls in the kernel, and then the kernel after it's loaded will finally turn itself back around again and check that both the gatewear itself has not been modified and the lader itself has the correct attributes to it. The whole thing seals itself into a circle at the end of the day.

## Bootloader

The bootloader is in rust except for a small canary pattern assembly stub. Clear the cache, set where the stack pointer is going to be, then jump to rust. It's as small as you can get in terms of an assembly stub. Nothing ugly going on here.

## Chain of Trust

The Chain of Trust starts there. We try to keep the loader minimal. We check the Ed25519 signature against a known set of public keys of the loader itself. The bootloader has some rudimentary graphics on it and drive the LCD and the user would know if the signature check fails and it will print a message. It has countermeasures on ... to fuse out the ROM and make it inaccessible if someone is trying to get secrets out that way.

That jumps to the loader itself, which then again takes another set of public keys, and very importantly at this point here, at this middle box where I'm talking about the loader, we handle all of the suspend and resume things that might happen before we go into the kernel. Suspend and resume is actually a big pain in the ass to deal with in almost any sort of OS because essentially when you're resuming it breaks a lot of ... you can break a lot of security assumptions there. You are taking a machine that basically shutdown completely, wedging values into registers, so it's nice to be able to have an FPGA system because when we have abstraction breaking issues in terms of resume we were able to fix them in hardware and not put horrible bodges inside the OS to deal with that.

If it turns out that resume, the resume process is pretty quick and it short-circuits where we lft off, or we clear the full RAM to make sure no previous session secrets are there. Then there's a long sequence of events where we setup text sections, create virtual memory pages, map all the threads, and then start running the OS itself.

That's the chain of trust in the whole thing it goes through. These two codefiles will walk you through it. They're not too big.

## Key ROM layout

Before I talk about the Key ROM layout, let me talk about the threat model. Most ASIC secure boot is designed on the assumption that you don't trust the user but you have ultimate trust in the manufacturer and the goal is to enforce manufacturer's policies on the user like DRM or some usage case or force an update, and often the aim is to prevent users from running arbitrary code on their devices.

Our threat model is different. We don't trust our manufacturer. We don't trust the supply chain or anyone else's. Our goal is to empower user to control and protect their own hardware, and as much as possible we want to make it complex to tamper with the hardware and we want to prevent remote exploit persistence so that if someone gets a foothold into the device then they shouldn't be able to put code in rest that gets loaded on the next boot without the user knowning.

The key ROM layout is-- the highest privilege key is a self-signing key, it's actually generated entirely in the device itself and that's used to protect code at rest on the device. Normally in a typical ASIC route, this is a factory-burned key that the factory knows and the users have no access to. We also provide a developer public key which is well-known and we use that to publish updates. Anyone can sign with it, the purpose more is to integrity check that data wasn't corrupted on the fly, but it can't do anything for an adversary because anyone can sign it. Then there's a third-party key where if someone wanted to do a certificate authority and publis hcode and say here's a codebase you can use, people can go ahead and opt to trust that particular CA to sign the code. The

The sign of this ROM is oversized.. didn't make sense to go any smaller. We do some anti-rollback, a global anti-rollback that is implemented because we don't have single e-fuses but we can code an 8-bit word. We can have up to 255 rollback states. We hash all the keys repeatedly. On the first boot, we will hash them 255 times, and every time we want an anti-rollback, we increment the counter and hash it one less time. If we set the rollback bit, then anyone who is authorized to run at that rollback level can hash their current key one more time and decrypt an old image, but you can't predict what the next image will be because it's tantamount to reversing the hash.

The private keys themselves are protected by a password, so even if you are able to dump the entire key ROM you can't sign a code image without the user providing another factor as well. This is another layer of protection, acknowledging that keys are often dumped and extracted.

The whole documentation for this and its discussion is available in the link on the slide.

## Rust pro's/cons

We wrote everything for our bootloaders in rust. The advantage is that rust is a memory-safe language, it's strongly typed, it has pretty good community support for cryptography like through cryptography.rs, but the cons are that you get a larger binary size compared to hand-rolled assembly. If you are targeting an ASIC, then every square mm counts. We were only able to get our bootloader down to 32 KiB. It includes drivers for ed25519... we had to use hardware crypto blocks to keep that binary down to a minimum. We also have some character graphics in there.

There was a steep learning curve with rust; I have a blog post about that that you can read from this slide.

## Self-provisioning

I want to talk about self-provisioning side of things. Self-provisioning is setting up your keys, on the device itslef. The first step is to get a good TRNG. If you don't have a good TRNG, then everything is lost and you can't even really begin. Re-design everything until you do.

We have two TRNGs in our system. We have an Avalanche generator which is an external discrete solution because we can't necessarily trust what's on the chip, and that has an independent hardware monitor of its own to monitor its health. Then there's a ring oscillator in the chip itself. An external discrete TPRNG is pretty easy to tamper with, especially with an Evil Maid style attack. We combine these two and hopefully get the best of both worlds.

The Avalanche generator requires an ADC which is expensive from a BOM cost perspective but it's free on an FPGA. Those get XORed together, get put into a ChaCha CSPRNG... ChaCha8 is not necessary for good performance but it's there because I like belts and suspenders. We have dual FIFO ports for kernel + user output.

We actually have a port dedicated to the kernel itself just for TRNGs because importantly it needs TRNGs early on and then there's a server port where it saves the data.

The next step is to generate your keys. If you're doing RSA, then this is hard because you have to find primes and there's weak keys. But we're using Curve25519 and AES. There are no weak keys: you get a good quality random number, and then you have your keys, and you save them. This is very specific to an FPGA.

When our device boots, it comes out of the compiler with nothing in the key ROM box. It's basically empty. It's just a bunch of random junk. It's not the data you're going to use. The FPGA config engine has no key. That's the state that things start in. We self-provision keys and put them into where they would be located inside of the crypto ROM itself, inside the soft SoC itself. The problem though is that the next time we reload the SoC we will get the old image without the keys inside. So we reverse engineered the bitstream format for the FPGA, we decrypt the FPGA on the fly because we have a copy (it's a zero key), then we patch in our new keys into the bitstream and then we write them back out into the right position in the bitstream and use the new key to encrypt the overall bitstream itself. It's an interesting bootstrapping process. At the end of the day, we can go ahead and blow the hardware encryption key on the device itself and do it in a way where you can't do read-back, AES only boot, and at that point in time the device will be fully sealed, in theory, except for oracle attacks on AES or hardware problems in the FPGA. Otherwise, it's a good way to lock away data after self-provisioning.

## Conclusion

That's secure boot and self-provisioning in a nutshell.

https://precursor.dev/

Q: Will you be doing skywater PDK?

Yes, we're looking at that. We won't be able to fit all our ROM in the device. Maybe copackaging some RAM and ROM and then blobbing over the whole thing once it's verified by the end user.

Q: The FPGA doesn't fit into the form factor of the device does it?

It does. This is an actual real live device.

Q: Why not a camera? That was my biggest challenge with the Precursor when I want to try to use it.

There's a couple of reasons. One of them is that we are extremely disciplined on the hardware supply chain part of not putting anything into the trusted domain that we can't fully have some mechanism to inspect. The FPGA is fully inspectable; the keyboard is inspectable; the LCD you can check under a microscope... if we put a camera IC in there, it has a lot of crap on the inside that we can't see anything about. You can say we're maybe being too extreme there, but that's one reason. Another reason is that because we're running a 100 MHz FPGA, it would be a low resolution low framerate basically stills only. Thta's the other reason we didn't put a camera in there. However, there's enough space on the inside for a camera and there's a GPIO flatflex and there's enough pins and you could put a small maybe CSI camera on the inside if you had the time and inclination to mill a little hole. I haven't had time to do that myself, but it was a thought and I know people would like to have it.

Q: You also have wifi on that. What stacks are you dealing with? I know it's in the not-trusted zone.

It's a chip from Silicon Labs. We just run the vendor's code; it's an encrypted blob that we get. So just whatever code is on it. We basicaly, it presents us an ethernet-like MAC interface. It plugs into a small tcp, we got TLS running on it recently. All the wifi stuff is just out-of-band signaling that we ues to setup the Access Point and SSID and get SSID scans back and that happens in this kind of parallel universe. The firmware provided by the vendors is pretty nifty and it's a blob and we can't inspect it.

# Bootloader (Cramium Labs)

Good morning. I work for Crossbar and Cramium. We have a new subsidiary of Crossbar called Cramium Labs which works on crypto controllers. Crossbar has been around for 12 years mostly working on resistive memories. Cramium Labs is a subsidiary that uses some of that Crossbar memory technology focusing on cryptocurrency and security where it has more crypto engine demands. This is a brand new division, but about 9 months in development. You can find more information in the link here.

## Bootloader

The question we have today is about the bootloader. We're making chips, not systems, at this point. What should the bootloader do for this community? Should it be very minimum code that only opens up the communication port and OEM will take care of everything else? Should it do all the crypto engines at the API level, and let the OEM do more of the IOs and displays, and customizations? This is the question for this group. Or should it be something in between? How much does the OEM trust the manufacturer? Bunnie mentioned that there's basically no trust. But what can we do to improve that perception?

## Block diagram

Here's a block diagram of a typical crypto processor. This is not necessarily what we're working on but this is pretty standard. It has a lot of accelerators here in the block diagram. All the primitives. It has a large megabyte of non-volatile memory. Besides code, there is also configurations, keys, secrets, and bootloaders and user code and so forth. You maybe only need an external SD card for updates. Other than that, all the code would be running here.

If the code is not big enough, then some of this NVM could be used for updates so there's no reason to use SD cards there because you can use the empty space for that. Once it's validated, you can go back to having free space.

It's a microcontroller, so of course it has IO ports. This is pretty typical. These are the crypto functions that we use to implement the functions themselves: some of them are hash functions, symmetric encryption, elliptic curve cryptography, EdDSA, ECDH, key derivation, secp256k1 curve, Curve25519.... Acceleratorsare designed so that the information remains in the crypto engine for the next atomic operation, so you can use those atomic operations within the crypto accelerators that none of the intermediate values will leave the crypto engines. You only give the inputs, and at the end you get the outputs. That is, if you choose to code it that way.

## Minimalism view

If you look at the minimalistic view of what the firmare looks like with a product like that, there's a small bootloader. This non-volatile memory here is expanded on the right-side of this diagram. Of All the chip bootloader does is open up the ports and let the OEM download an OEM bootloader, so it really doesn't do anything. There's also manufacturer areas and trims and categorization data and so on. Maybe we just move the lifecycle of the device from chip to OEM. Very small amounts of code. This code is just for loading the OEM bootloader once the OEM bootloader is loaded then, you don' t even use that. So there's absolutely no trust in the software that is loaded into this.

## Lifecycle progression

If you look at the lifecycle progression, during the test of the controller we do this part, then we ship it to the OEM and they move the lifecycle from chip to OEM, and maybe they will use some of the slots while doing that, like adding secrets and keys and so on, and it will configure how those slots are going to be used.

It also loads the OEM bootloader, and the chip bootloader would no longer be used, and the reset vector would move from here to here. So this part of the memory can be reused because the OEM still can do everything that the chip bootloader does and a lot more.

The way we're thinking right now is only one-way lifecycle progressions that can only go forward. Once you go from chip to OEM, you can't rollback the chip for security reasons. One of the questions I have at the end is, do we need to go back to some test mode or something where we can have a post-mortem when some parts come back? How do we know what went wrong if we don't have full access into user mode into the chip without being backdoored? You don't want to have a backdoor...

## Full-feature software

The other option is to have full-feature software where everything here, like the cryptographic algorithms, are loaded into the chip bootloader. All the crypto functions get loaded during manufacturing. So you have the tirms and everything of course, but we still move the lifecycle to OEM, but now we put a lot of information into the chip and we might use some keys and passwords space and some of the configurations of those slots.

In this case, not only does it open up the ports, it also.... it has all the crypto functions and once itgets loaded, you can only execute from that, you cannot .. you might have some keys or things like that. It cannot be read or written to, if it is only execute.

It could also additionally have an OEM bootloader that adds additional crypto functions that were not part of the standard offering. Once they add that, they would have to lock it up again, and it needs to be executable-only again.

There's always user space for customizations and upgrades, for post-production updates. This is the standard user code upgradeable, it's signed and it's upgradeable.

## Lifecycle progress

The lifecycle would go from OEM to user mode, this was the OEM lifecycle. So we ship the parts, but then, the user will fill in the rest of the- they will add in the seeds, PINs, and things like that, and of course, the user code then gets loaded also. Once you go to this lifecycle, then this is the finished product.

## Questions?

The questions I have are, what can we do to improve this? How can we use architecture to gain your trust in the chip? The whole idea is that we want to reduce the time to market. If you already have all the codes, then, what other tools can we send to increase your trust in the code and hardware that we are shipping?

Do we need to have some features like supply chain authentication of the chip itself? Should it be also done at the chip level to check authenticity of the chip? Is it important to support reverse lifecycle progression, which could destroy all the secrets? Is that something that is desirable? But then how do you trust that we do really destroy the secrets, and so on?

What should we consider features that should be shipped in such a product? What features should we be concentrating on?

Q: Thanks for the presentation. My biggest thing would be to see the code be open-sourced and be made available whatever that code happens to be. The most trustable for me would be if I had the code, I could compile it and load it into the chip at the factory. That removes the trust from you. You could provide the code, we can compile it and modify it, and then at the factory we know exactly what's going into the device.

So you would prefer the minimalist vision, with the source code? In this market, of course, it has ot be open-source code.

Q: What's in that chip bootloader? I want as little as possible in there.

All it does is let you .. one of these ports to.. That's all it does.

# Proxy

I am Simon, one of the founders of Proxy. I will remind people what we're building in case you haven't seen the previous presentation, then I will talk a little bit about the steps we're currently taking to ensure hardware integrity.

## What we are building

We are a hardware + software kind of shop. The primary product is a non-custodial wallet for digital identity documents, digital assets, and key management but it also includes things like driver license, FIDO authenticator, and other identity and authentication use cases like that.

Our main focus is on making a product that is easy to use, has good safe enough defaults so that users can't hold it wrong. We want to make some of this cool technology that we're all familiar with to be more accessible to the next 100 million people. How do we make sure it's easy to use, understandable, and it can't be accidentally misused?

Part of this suite in addition to a software mobile wallet we're making a wearable hardware wallet that acts as a companion to the software application. It can be a co-signer in multisig transactions, and it can also be a single signer but that isn't a use case we're focused on because it opens up a lot of tricky situations. We are mostly focusing on it acting as a co-signer and it can also participate in wallet recovery.

The form factor is a ring, so it's extremely constrained in terms of size and power.

## Components

I will talk about the hardware pieces mostly. We have an MCU with a built-in bluetooth stack, bluetooth core. These are all off-the-shelf components. No custom silicon. We have a secure element with an NFC frontend antennae. We have capacitive sensors and fingerprint sensor as well. We provide active-wearer detection and lock the device when removed, and things like that.

The secure element keeps user secret, and also keeps component auth codes which I will talk about in a little bit. It provides resistance to sidechannel attacks, and it's pretty much the place where we store any user secrets and we're also using it as a TRNG source.

As I mentioned, we have an extremely constrained form factor and we're baking all of this into a tiny tiny volume and there's not much board space, physical volume space, or power available. It's pretty tight in there.

## System security perspective

As I mentioned before, the entire system has to operate as one unit. The only secure input/output we have is via NFC. It is directly integrated into the secure element and it's not connected to the MCU and the MCU can't intercept the communication. BLE is a transparent transport for the same... NFC APDU... so it's the same exact channel being established end-to-end between the mobile app and the secure element. Bluetooth is also used for high-bandwidth use cases like loading firmware which aren't transaction critical, but as far as regular operation it's just a transparent envelope.

The secure element itself isolates our applets from any of the pre-installed applets that provide payment functionalities which are not our NFC use case but are also on the device as a feature set.

## Hardware integrity

Some of the things that we use to ensure that all the components in the piece of hardware you receive are binding these components together with keys generated from physically unclonable functions on a couple of these components. The PUF is in the MCU and then we have the fingerprint sensor.

Physically unclonable functions are generally some property derived from the physical structure of the silicon itself. It has to be unique and unclonable, and it has to be immutable per chip. The key doesn't need to be programmed, so there's few opportunities to intercept and get this root key programming and the key doesn't exist when the power is off. The key is re-generated each time it is used from the physical hardware itslef.

We use these to derive other keys as you will see in a moment.

At manufacturing time, we capture the generated PUF authentication codes from the secure element. The secure element is the only sort of secure storage on the device. It's the only one that is resistant to phsical attacks and resistant to readouts. So that's why we're storing the auth codes, it's a one-time write into the SE and they can be readout but they can't be updated again.

At runtime, we use these auth codes to reconstruct the key using the physical properties. Then derive the actual session keys or encryption keys or whatever from that. We want to minimize the amount of time a reconstructed key is in memory, so it's only done very briefly, and then the constructed key is nuked again once you have derived the session keys. Effectively this bonds together the fingerprint sensor, and the MCU and SE such that they are basically permanently paired.

From the MCU, we key-wrap bus encryption keys which are used for communicating between the MCU and the SE which is a secure communication protocol. They are key-wrapped using this PUF key. Similar to the fingerprint sensor and data matching, the bus comms is often the weakpoint of many devices which are composed of multiple components. It's the easiest to intercept because you can just put in a few probes and pick up stuff for SPI or an IC2 bus. Encrypting everything that goes over memory buses or comms buses is a pretty important step.

We also use this to encrypt sensitive data in flash as well. From the fingerprint sensor side again, there's encryption on the bus again.

Swapping out any of these components breaks the communication. One of the attack vectors we have seen is that if you can't compormise the code or inject code running on the MCU for example, you can often take the MCU off and introduce an MCU that already has compromised code on it. This sort of setup prevents that exact vector.. It can also be used as part of a more comprehensive authenticity check, you can use it to mutually auth all the components not just on the SE or one of the components but actually confirm that all the critical components of the system are still the same ones that were placed there at manufacture time.

## Software firmware integrity

A lot of this is pretty standard because we use off-the-shelf components and we don't have much freedom in customizing this, unfortunately. That's why we're here though, to fix this.

We don't use the chip-provided bootloader because it doesn't have the functionality that we want it to have. It's our own bootloader that won't accept unsigned images, it has downgrade protection, and things like that, and standard MCU memory protection, disabling debugging, all those things apply. Of course they are not guarantees, there have been plenty of glitching attacks and things like that which have allowed MCU memory protection to be removed and debug interfaces to be either re-enabled or at least used to dump memory from a supposedly protected chip. These are definitely not super strong and they could be improved.

The secure applets themselves, we wanted to make sure they are field upgradeable because it's common for them to not be because of how Javacard secure elements work where the data is part of the applet. So once your applet is perosnalized and you have loaded some user keys on there, you effectively can't upgrade that applet because upgrading it would wipe the user information. We have separated our applets between business logic and data storage. The user data storage is extremely simple applet, and it's not field upgradeable, but all the business logic is field upgradeable so we can fix bugs and all those kinds of things.

## Device authentiticty check

This is a work in progress for us. At the manufacturing time, we can register a generated key from the secure element as long as they collected communication codes from the other peripherals and we can store those on our backend. Upon receiving a device, the user can scan it with their phone and NFC, it will issue a challenge and read back a signature or cryptogram that can be verified as a device that was effectively manufactured by us and it's not a clone or a substituted device.

## Do better list

I will wrap up with a few points that I think, I'm not super happy with these.

Secure code integrity checks: a lot of the MCU code verification relies on code running on the MCU itself and it's subject to silicon vendor bugs, glitch attacks, etc. I don't know if there is a way to make this better without having a fully integrated system like the ones we saw presented before. For us, the less reliance we have on the authenticity of the MCU, the better, because of these reasons. Ideally I would like the code integrity checks to participate in device authenticity as well. Not only have you verified the components are still the same but you can verify the hash of your bootloader code for example and be able to do that in a way that doesn't depend on our code itself.

Transparent encryption of memory reads and writes would be nice. Right now we're doing it manually for things we consider sensitive like bio templates. We cannot use DMA between different components directly.. on chip memory controllers that provide for transparent encryption of reads and writes would be interesteing.

We're also looking at physical tamper evidence, like a transparent housing or etching things on it.

Finally, we're interested in authenticity check using WebBluetooth and WebNFC so that you don't have to rely on an app you can't inspect. It should be directly from the browser, and you can use TLS connection from the web server. This is possible right now with mobile Chrome browser, but not from other browsers.

## Questions

Q: Is there a standard for chip supply chain authentication, like curves, or formats, or the protocol workflow?

A: Not to my knowledge.

Q: ...

A: I don't think, it's very much an architectural thing. What do we need to do to verify code on the MCU? You need full access to the MCU's memory space so that you can generate your own hash of the code and then check the signature. Right? Generally there hasn't been a reverse link where the code running on the SE can reach out to the rest of the running system, which is somewhat intentional and enforced by the payment networks because they want it completely firewalled and isolated which makes verification of the specific applet running on the SE much easier but it doesn't have generic memory access to the rest of the system for example and it can't actually do code verification. So now you're stuck with the MCU itself, or maybe a somewhat protected bootloader calculating the hash of a firmware image or passing it into a SE for signature verification which opens it up to some interesting attacks like injecting code is able to still ... you can inject code into empty spaces between functions and whitespaces or things like that, and that code can return the hash that still verifies while allowing arbitrary code to run. To me it seems like an architectural thing that as far as I can see can only be solved by merging the two and making sure it is trusted silicon I guess, or verifiable silicon at least, that has access to the entire chip that is verifying the firmware code in a hardened environment similar to what we saw from the FPGA presentation or something like that. Or maybe Crossbar is working on a hardened MCU that is part of the same package; something like that would make it possible.

# Foundation Devices

Passport is a next-generation bitcoin hardware wallet. It has a camera, a color screen, and microSD. We have no wifi or bluetooth. On this generation device, that's not something we will do. We will always have an airgapped device.

Improvements over the previous one includes a color screen, removable lithium ion battery, and you can use it while plugged in ... newer slimmer design and more fancy, basically.

## Security

Some of the philosophical points we have are to be as transparent as possible with open-source software, schematics, bill of materials, this is all online on our github right now. We only purchase components through reputable suppliers and distributors, almost always US distributors right now. We want to use generaly available components, nothing that is funky or hard to acquire if you wanted to build your own Passport from scratch without our knowledge or permission.

We want to minimize the amount of blackbox silicon which is chips running unknown firmware or any binary blobs. Bunnie's solution for putting things into an untrusted zone is kind of the same approach we're taking. As much as possible, we treat that as a dumb transport. If it's some bluetooth wifi NFC chip, we do that, otherwise we try to run code that we write ourselves. We also assemble everything in the US, including circuit boards.

We use STM32H753 MCU, which we use in combination with the ATECC608a secure element which is connected by a single wire serial channel.

## Supply chain security

There's a lot of details in the supply chain and its complexity. Where are the components? What about proof of custody along the way to the factory? Who is on the floor at the factory? Shipping the device. Getting it into the user's hands. Security at each step is very important and we do things for each of those, but today we are only talking about the silicon parts.

## PCB assembly

We have a pick-and-place machine that puts these components onto PCBs. We connect to test points over GPIOs on the boards, which lets us do things to verify things that the board was assembled properly and the voltage levels are right and the bootloader and firmware can be installed. We wrote a tool in rust to control the fixture and provisioning.

## Factory provisioning

We didn't want to rely on factory provisioning tools from chip vendors. So the first thing we do is load a test bootloader on to the MCU and we run through a series of hardware tests to make sure everything was assembled properly, like testing the screen controller, the secure element, making sure we can communicate with everything.

One of the important security steps is that we have a supply chain secret that is copied to Passport. One thing we didn't do for this round which we might change later is that we didn't want a per-device unique key that we would have to remember because there was some concern from some people that we would be tying this unique ID to someone's physical address or email address to associate a unique ID with them that we could at some point use to associate future transaction data or something.

We flash the normal bootloader and then we restart the Passport device. During the first boot, the MCU and secure element get configured.

## Passport first boot

MCU has a section in bootloader flash where we store the secrets. If we have configured those, we go to the normal boot process, and if we haven't provisioned them then we will do that. Also, the secure element has to be configured and there's two aspects: the slot configuration for what each slot is used for, and how is it protected? Is it readable, writable, and under what conditions? If it's been done already, the bootloader skips ahead and boots up as normal otherwise we will cover those slots down below.

On first boot, the MCU generates a random one-time pad and a pairing sequence and a transaction cache encryption key. Random numbers on Passport are using Bunnie's Avalanche noise source, so thanks for that Bunnie. We also pair this with other sources of randomness that we XOR together including the MCU and SE.

These are basically stored into the internal bootloader flash once they have been generated. The pairing secret is also stored in the SE.

## Secure element

This is a bit of a visual overview of how we configure the slots. There are 15 slots on this device. Slot 8 is particularly large,but we didn't have a need for that. We have a PIN hash, which is a hash of the user's PIN, a PIN attempt random number which is also used as part of the hashing process, some login counting to restrict how many attempts the user has to access the device; the supply chain private key that we talked a little bit about earlier; the user's bitcoin seed, obviously that's important to store. There's also a firmware pubkey that allows you as a user or developer to load your own code. There's a timestamp to prevent downgrade attacks, and then a hash value to make sure the firmware loaded on the device is what it's supposed to be, and that's what the SE uses to set a secure GPIO pin to turn an LED from red to blue.

## Pairing secret in slot 1

This pairing secret is used to prove the secure element and MCU are a matched set. This is to prevent an attacker from swapping out device components. If you swap out both of them, you are starting from scratch and wouldn't have access to secrets anyway. But without the pairing secret, you can't communicate with the SE.

There's a back-and-forth dance we do to prove that we have knowledge of the secret using an HMAC.

Once you do this, now you can issue the next command: now that I have proven that we know who we are, how do I specify a slot that I want to read or write a slot? And this process repeats every single time we want to read or write a slot.

## Pin stretch in slot 2

We ask the ... we do this so that PIN attempts take longer; so we just repeatedly hash it to take up some time on each PIN attempt.

## Pin attempt hash

The pin attempt hash is a secondary value we use to help limit the number of PIN attempts. We hash it with the result of the key stretched PIN that was used from slot 2.

Once we take the user's PIN, we have keystretched it, we hash it with the value from slot 4, and now assuming ... we XOR it with the one-time pad value that was stored in the MCU flash, so this is an encrypted version of the PIN hash. So even if they reverse engineer or decap the SE and extract the values, they would still not have access to the PIN.

What's important is that as you will see, a lot of these slots have an arrow pointing from a slot to slot 3. What this means is that they require authentication from slot 3 in order to read and write these other slots, depending on a slot's particular configuration. In addition to the unlocking dance, you have to do an unlock to prove that you have knowledge of the PIN. You can't read or write any of these slots that are marked in green without having proven you know the PIN hash.

This value is only readable if the value of the monotonic counter is less than the match count. As the user enters PIN attempts, if they get it wrong, then we increment the counter. Every time we read the PIN attempt hash, we are counting a PIN attempt. So if you keep doing htat, you will eventually run out of attempts, and this slot would be unreadable, and you will therefore be inaccessible all the other slots that relied on slot 3.

Last login counter is used for showing the number of failed attmepts, but it doesn't have to actually be in the SE.

The match count (slot 6) is a little bit weird. It has to be a multiple of 32. Every time you successfully login, we have to bump this to a multiple of 32, meaning we have to bump the monotonic counter up. Say we have 21 attempts, so we have to bump the counter up until it's 21 less than the match count. A little bit weird, but that's hardware for you.

The supply chain private key (slot 7); this slot in the diagram is marked as not readable and not writable. After we configure the slot, this value can't be read by the MCU and can't be modified. We use this to do an HMAC challenge-response with the Foundation validation server to prove that this Passport is a genuine part.

In slot 9, this is the user's seed. The user's entropy bytes are in here and the byte values we usually use to lookup your seed words. These are XORed with the one-time pad from the MCU before storing these. If you were to remove the SE, and use laser fault attacks to extract this, you would still get an encrypted version of the seed; the MCU is easier to compromise than the SE, but again everything helps.

In slot 10, this is the user's firmware pubkey so that the user can choose to trust another pubkey. This is for advanced users that want to burn their own firmware or for developers who want to do experimentation on Passport. The bootloader will only load firmware signed by Foundation keys or those that are signed by this pubkey in slot 10. Only a user that has proven knowledge of the PIN is able to set and install a pubkey into slot 10.

In slot 11, this is the latest firmware timestamp that we have most recently installed. It is only updated when installing Foundation signed firmware. It is not updated when you install custom user build or any of our beta releases because essentially our beta releases rely on te user firmware key as well. The bootloader will refuse to install older firmware, to prevent downgrade attacks.

In slot 14, this is the hash that we use for turning the security LED from red to blue at boot. This is a combination of the device hash and the firmware hash. The device hash is a combination of the SE serial number, MCU OTP, pairing secret, and the MCU unique ID. If any of these values change, then the security LED will not turn blue on boot and then you should not continue to use your device. This value is updated whenever we update or install valid signed irmware image.

Supply chain validation-- slot 7 contains the private key. There are two methods we use. One was a manual method, which was used in the first version of our Passport Founders edition... but now we use the mobile app for the newest version of Passport which is the one with the color screen, and this is the preferred mehtod obviously if you have the newer device.

In the manual version, which you can still use this on the new Passport, if you happen to be a user that doesn't want to isntall the mobile app, you can still validate using the old manual process. You can do that by going to the website, so you go on your phone or computer, we generate a random challenge, we hash it with the supply chain private key; we sign the challenge with a separate private key of the server, the Passport knows the corresponding public key because it's baked into the firmware, and the Passport checks that this was really signed by the Foundation server... then it asks the SE to perform the HMAC on the challenge, and then return a response. Then we do the same process to turn the bytes into a bip39 seed and we show the first 4 words of that phrase. If those words match up, the user enters those 4 words into the validation website, then the website knows whether you pass or fail because it knows what those 4 words should be.

It's a similar process for Envoy except the user doesn't have to do the typing. Envoy doesn't have to go to the web browser. The user fetches the random challenge from the server directly, it gets presented as a QR code on the mobile phone. The user scans the challenge with Passport, it does the same process to check for a signature, it does an HMAC, it makes a response, and then it is ... scanned by Envoy, and then sends it on to the server and receives a pass or fail result which Envoy then displays to the user.

## Future improvements

That covers supply chain and slot configuration. But some of the future improvements we want is that, with slot 9 which is the secret seed value we would like to encrypt that with the user's PIN. Right now we store a PIN hash in slot 3, but we would like to take an alternate version of this PIN hash and XOR the PIN hash with that as well because tihs would mean you also have to know the PIN. Even if you compromise the MCU and the SE, well without knowledge of the PIN you would still be unable to decrypt the seed. So you would still be looking at a bruteforce attack on the PIN even after decrypting it or obtaining the secure value from the MCU or SE.

Also, the SE library that Microchip provides incorporates some PKI features and they use this part in a lot of supply chain validation processes. For example, I think laser toner cartridges are using this to prove that the part is genuine. We're investigating that as a possible way of doing supply chain validation in the future.

There is a 608a and a 608b SE. There are supposedly some improvements in the b variant, but the level of improvements is not disclosed by Microchip even though we're under NDA. Some people think it may provide additional resistance to laser fault attacks, so we will be upgrading to this new chip on the next pass of next batch of Foundation devices. The device is slower at some operations, but other than timing it is a backwards compatible upgrade. Even for the marketing perception, it seems to be a good idea to upgrade.

## Silicon dreams

What would we want in an ideal secure element in the future?

Some of the current limitations of the SE right now is that it supports a small number of seeds or secrets. We would like to have potentially dozens of root seeds that we are protecting. There's also a single monotonic counter for this which limits you to a single PIN. It would be nice to have multiple monotonic counters or equivalent functionality to track separate login attempts on other PINs.

Running crypto on chip-- right now our SE is really dumb compared to the SEs that Cramium is talking about developing which would be able ot execute arbitrary code. Ours just has some hashing, HMAC, and storing values and retrieving values. But if at least being able to do signatures in the SE would be fantastic, so that we don't have ot.... we have to temporarily bring a secret into memory and then erase it, it would be great to not have to do that.

Having the MCU and SE in the same die or package could be good. I think that's the path that Cramium is on. Ours are separate right now, we kind of like it being separated. In some ways, it's nice that they are separate because there's no way for them to interfere. Maybe they can still be on a single chip but maintain their separation?

Configurable rate limiting to control PIN attempt frequency. I haven't thought about how to do this in hardware. Right now we limit PIN attempts by taking time in the chip to do key stretching. Maybe there could be another mechanism that wouldn't use as much power maybe?

An early issue that we had was- being able to dump the internal state of the secrets might be interesting as a developer version of the SE. It's a black box, and someitmes when you're doing something wrong it can be hard to tell what you're doing wrong. So being able to see the values in there would be helpful.

## Questions

Q: You were saying you would like the chip bootloader to do absolute minimum and you do the rest. You also said you wanted to have it such that someone else could create a product using all the same chips a parallel device. Do you foresee that you might offer a version of Passport that is pre-your-firmware?

A: Yes. I have in my hand a board here with a socket for the SE, so you can place your own SE on it. We will probably put this up for sale in a limited number of devices. There's probably no more than 10 people in the world that might want that. We will be putting that out sometime in the next couple of months. That will come with an MCU which is not locked down. On this particular chip, they call it RDP-levels 0, 1, and 2. At the factory we lock it down to level 2 meaning JTAG is disabled, but when I'm developing I leave it at level 0 so that I can load firmware and debug and things like that. So this version of the product will let you do that. I went through so many SE chips during development and it was useful to pop in a new one.

Q: In the literature on Byzantine Fault Tolerance, and I allow a node to deviate from some communication then the usual result is you need 3f + 1 and if you want 1 to be able to fail you need a minimum of 4... it also means that it's fundamentally impossible for one device to ... if the hardware can deviate from its behavior, or the software can deviate.. Your hardware can have 2 RAMs like one that has the expected firmware and the other has another one. Say the hardware works, but the software is not trusted. I only have two things there. It's fundamentally impossible to solve the problem of one of these devices being faulty. In the literature, it says I need more devices cross-verifying each other. The minimum number would seem to be 4. How could this be applied to hardware? I think the result should be analogous in hardware. This throws me into the realm of using a byzantine fault tolerance or multi-party computation to solve this problem.

A: That's an interesting idea. These devices don't communicate, but you can imagine a shared website or some way of exchanging QR codes or something across devices to see if they all agree. I don't know.

We will talk about this a little bit more. There are some emerging zero-knowledge techniques for some of this like for multi-vendor verification of results... I have seen napkin sketches that have heterogenous hardware, like 2 of the 3 chips to validate the other 2 chips so there's some quorum things as well.

Q: I thought it was interesting that for the authenticity check you're moving from a browser-based check to an app, and we're trying to do the opposite. It highlights some of the tradeoffs you have to make in the different...

A: We thought about that as well quite a bit, which is why we continue to provide the manual option for users. It's easier to not go through it, for sure.

Q: Making it user friendly would be interesting. That's why I was looking at bluetooth to make that user friendly. So that was interesting. On your SE wishlist, you said that pretty much all of that list can be done with ... but then you have to trust the primitives are implemented correctly, or you can't replace runtime on the chip because they are certified. That would be true for even a non-javacard, how do you trust their ECDSA is implemented correctly and isn't using a compromised nonce or something like that?

A: We are investigating other secure elements for future products. Maybe you can share which Javacard you're using.

# Validating Lightning Signer

It turns out that Qubes really doesn't like screensharing. That kind of makes sense, I guess.

## Introduction

I want to give an overview of VLS. What is VLS? The VLS project is an open-source project and not a company. We're building a body of software that everyone can build and use and it's not a commercial venture at the moment.

We're focused on designing software that can be used to improve the security of lightning nodes. Lightning is a layer 2 protocol on top of bitcoin. It augments the bitcoin protocol with fast transactions and much more economical fees and some significant improvements in privacy.

The basic concept of VLS is to not have the private keys or other secrets in the online node itself. Instead, ask a remote signer using VLS to sign the relevant messages.

An interesting aspect of the VLS project is that the software is applicable to use cases that are very different. Originally we were thinking about using the VLS software inside a hardware security module to secure an enterprise-scale lightning node. As we went on, we discovered other cases where inexpensive consumer devices could provide custody to end users and this was important for different reasons.

## Team

Our team is small. devrandom and I started working on the VLS project in late 2019. It looks like we have paralleled COVID19... oh well. Previously we both worked together and separately on security software, often related to bitcoin custody. We were well versed in this topic and thought about it a lot. We were recently joined by Jack to help us tune to specific market needs.

## Why is VLS needed?

It is important to understand that lightning nodes are much more challenging to secure than bitcoin hot wallets.

A company that has successfully managed a bitcoin hot wallet will find that operating a secure lightning node involves much more work. The fundamental work of a bitcoin hot wallet is to move the funds from the hot wallet to cold storage. In fact, you only need to leave an amount to cover short-term disbursement. This approach doesn't work at all in lightning, though, because all funds must be in the committed channels and they must be controlled by hot keys. Funds can't be kept cold until needed.

Say a large retailer that has 1 million channels each with $100 dollars. This would be an internet-connected node that has $100 million dollars in hot keys. This is scary, and it's a target of attackers.

Using VLS makes this more secure. It doesn't contain the private keys and secrets. It delegates to a remote signer using VLS which signs all the necessary messages. The remote signer using VLS benefits from minimized attack surface. No gossip, routing, dozens of other things lightning nodes do, just to sign messages securely.

You can also do security-enhanced execution environments; the remote node can run in a specialized environment which is much harder to hack.

One of the things we're doing with VLS is that we guarantee protection of node funds even if the node itself is entirely compromised by an attacker. The thing an attacker would do is compromise your node, then he would have you sign a set of malicious messages like let's close the channel but send me all the money which would mean you lose your funds. But VLS enforces a list of policies ensuring that funds aren't drained from the lightning node via malicious messages. This requires us to hold more state than a blind signing situation.

A completely different use case is providing custody of lightning funds to end-users when they are using cloud-based lightning nodes. If a end user wanted to have a small scale lightning node, an emerging concept is to put the lightning node itself into the cloud and have the end-user direct the node to do them things on their behalf. That makes a lot of sense because it keeps the resource intensive stuff like route finding and gossip in the cloud where it can be better managed. But without VLS, the end-user needs to trust the LSP. If the LSP was compromised or became evil, it oculd craft evil messages which could take oyu rmoney away.

By using a validating lightning signer, in possession of the end user, we get around that problem. The user has actual custody, and that signer will refuse to sign messages that will drain the funds.

## Embedded device requirements

We have designed VLS software to run in security-enhanced execution environments. To us, that means it's written in rust and it tries to avoid using STD features in the core. The stuff that would run in the SE is not using STD features which are large.

The rust itself has thread and memory safety and no garbage collection which are also probably helpful for writing secure software.

The VLS requirements for an embedded device today is that our code fits in 800k of flash. We're still working on the software but that's a good idea of how much flash we will need. We will need 1 kilobyte of RAM per channel, and then a modest fixed amount globally for allow lists and other such things.

The non-volatile storage is the same as the RAM. There is one gotcha in lightning: historical payment hashes grow without bound so we have other ways of mitigating those for use cases that cannot afford to store the historical payment hashes.

We also need an environment that is capable of secp256k1 ECDSA and Schnorr signatures used in bitcoin today.

## Wish list items

Our wish list items that would significantly improve security inlcude tamper-proof hardware which can protect us when the physical security of the device is compromised. If someone steals your VLS signing device, you would like it to not be used to extract your secret or operated.

Secure boot and firmware updates are obviously important. They protect against a bunch of different things, like evil maid attacks, like someone who has momentary access to your deivce, if they can load oyur device with different software then obviously they can steal your funds.

Finally, supply chain security is important especially whne dedicated devices are used. We had a broad specturm of use cases like a hobbyist hardware or stuff commonly available could be used in which case supply chain security isn't important. But if you build a custom device and optimie for VLS, then you would like to be careful with how those were produced and make sure they weren't tampered with in the supply chain.

We have a wide range of cost sensitivity. We will see both high-ends hardware security modules for large retailers, but at the same time we are also delivering benefit to consumers with very very inexpensive devices. The security tradeoffs will be different in those cases. In one case you have a $100 million honeypot and you will want to spend money to make sure there's no attack vectors; in another use case, you are protecting the user's spending money so maybe it's the best for protecting like $5 in that case.

We can run VLS inside a browser because we can compile to webassembly (wasm). We've been using little STM dev boards which are good for demos and proofs of concept. The folks at Stackwork are using VLS on a custom board.

## Sponsors

We would like to thank Spiral and Blockstream for supporting VLS development. We would also like to thank Blockchain Commons for helping us explore this space.

Please connect with us if you have more questions or want to explore what we can do together.

https://vls.tech/

## Questions

All of these presentations will be available hopefully later today including links and things of that nature. Any quick questions before we go to a bio break?

Q: Are there any security issues with number of channels?

A: We have a bimodal problem space here where the enterprises have millions of channels but also cost isn't as significant of an issue. However, the 1k number is more interesting for end-users or consumers. You could make a very small device, and an end user might not need more than one or two channels but let's just say a dozen. We're trying to point out that we don't need a lot of RAM for that. One historical piece of data is the historical payment hashes which need to be stored if you wish to recover when your counterparty has breached, and we have another way to protect against this for smaller devices, like by limiting the number of HTLCs in flight to a reasonable amount of money which is similar to the hot wallet cold storage tradeoff. Sorry if that's complicated.

Q: Why is Schnorr on your list? Are you using taproot-based lightning?

A: Not yet. It's on our roadmap. A lot of lightning will move to Schnorr-based. It has some advantages. There are also some interesting signer configurations which can take advantage of threshold signatures like by saying I want a quorum of these devices to all agree in order to sign this message. That's more distant on our roadmap but it's extremely attractive approach for all the obvious reasons. lnd already has some stuff working with taproot but we're still trying to figure out how to implement this all.

# Workshop session

I want to thank the presenters for some excellent presentations and for diving into what we're all about, sharing problems and priorities and approaches for solving these problems. Thank you very much for sharing this with us.

We'll have these presentations on our website siliconsalon.info hopefully later today or at least first thing tomorrow. You will note that we have a lot of transcript written. This is a live transcript of Bryan Bishop's of all that we have talked about so far. There's a lot of great details there. These will be posted up like he did at the last Silicon Salon on the transcript site as well. If you have something you want to edit or correct or add or be more clear on, then add it into the hackmd notes. We will be taking key takeaway quotes from the different presentations and adding them into the bottom on the website. If there's something that somebody said that blew your socks off and you want for us to highlight it, please send it to Shannon and I and we will make sure we get the key quotes into the document.

We have about 40 minutes for discussions. There are three categories: the boot questions, firmware questions, and the supply chain questions. Pretty open here.

# Boot

In the boot questions, we have had a variety of discussions about chip lifecycles, what functions should be available, when does the OEM takeover, what is supplied by the chip manufacturer? What keys? What firmware? How sophisticated? Some of the stages there you know- can go all the way out to the user sovereignty so that in theory with the card that Ken showed us could be practically a self-sovereign device. It's close to it, at least.

There's also an ongoing problem of how do we QA and debug things? Ken was also talking about making a version that allows you to get some access to internal state solely for debugging purposes. But there's a lot of cost of goods in having to deal with returns and other things and trying to figure out what goes wrong. One of their questions is, is it even feasible to try to securely delete state so that they can debug a particular bad chip?

There was a lot of discussion about firmware signing, anti-rollback, and self-sovereign devices. Are there any particular thoughst, observations or comments?

Q: One thing brought up by two participants is that it seems like some of the struggle is how to create logic that deals with any physical attack. Byzantine Fault Tolerance tries to do that by saying everything is unreliable and let's address it with logic. But there is an importance to physical security on the MCU itself. It seems like it's simpler than having to deal logically with the fact that you don't have physical security. Just an observation.

If you look at the Byzantine result, it's 3f + 1... if f=0, you only need 1 device. If you make a working device, that's a solution to the problem. Right? Well really it's a probability, what's the probability it has been hacked.

In some other work we're doing at Blockchain Commons, we're doing some collaborative seed recovery techniques but we're really designing it for a future where the world might be multisig with various kind sof homomorphic kinds of operations or key generation, or zero-knowledge proofs where as long as there's one trusted device it would work. There's also the byzantine type of stuff. Some people have been arguing, well, maybe we don't need secure hardware at all. I think that's taking it too far. We need at least one trusted device.

Trusted and untrusted implies a binary way of thinking about the world which may not be how it really works.

The trust model can be understood when there's a single trusted party. But on the other hand, the ability to independently verify everything from the chip assembly to the boards and reproducible code. With IETF standards, it's a big deal that we have heterogeneous code. Something can't be a standard if... one of the problems with Curve25519 is that it is poorly specced and a lot of the implementations of Curve25519 have spaces that aren't compatible with other Curve25519 implementations on the edges, so that's scary. It's fine as long as you're using the same C code but try to interop with someone else and you might have problems. Any thoughts on this tension of single source of truth incentive because of single party trust because they will go out of business if they're not secure, versus the more heterogeneous approaches?

I don't think heterogenous architectures have been explored much. I would like to see someone do multi-party computation. Imagine 4 general purpose chips that were doing MPC among each other. I haven't seen this path explored. People try to verify things on the board, which I argue may be impossible, or verify the supply chain which is very analog. Anyway, I think there's a direction here that has not been explored at all and is worth thinking about.

Most people haven't looked into FROST they don't understand that there is a step zero and step one in FROST which is that the configuration of something called VSS but you don't have to do a multi-party operation to create VSS. The advantage of VSS is that you can distribute it; unlike Shamir secret sharing, you can verify that other party's shares are avlid but you can also sign things in a FROST-type fashion with VSS as well. What would be a minimal secure element that maybe only does VSS and it only does it very slowly? It's on a large nanometer chip that has a sole design of being the third or fifth component on a board to help verify all the other components. I don't know. That's just a brainstormy thought.

VSS fundamentally requires multiple parties. All implementations of multi-party computation relies on VCC. They take some data, divide it with VSS, then each node does some computations on the shares, and then the shares get recombined somewhere. That's a direction of multiple devices.

We have someone here working on FROST for bitcoin. I think there's some interesting possibilities in that space. You talk of byzantine fault tolerance; ...ROAST allows you to avoid the byzantine problems. You can reach a consensus to sign when you have greater than 50% adversaries. I don't know what the limit is but it's interesting work besides the 30-year old 3f + 1 type solutions.

I want to throw something out there. In the context of BFT or MPC, the assumption is that all the nodes are identical and following the same protocol. In hardware stuff, your hardware compute units are wildly different like bootloaders, MCU, SE, software layers, etc. So if you accept my claim that it's impossible for software to verify hardware or hardware to verify software if you have only two devices. But if you have 2 devices verifying a general purposes CPU, is there a way to make sure the devices...

Keeler's theorem: Let A be a finite set, and let x and y be distinct objects that do not belong to A. Any permutation of A can be reduced to the identity permutation by applying a sequence of distinct transpositions of A ∪ {x,y}, each of which includes at least one of x, y. ... The proof reduces to treating individual cycles separately, since all permutations can also be represented as products of disjoint cycles.

# Firmware

What are the requirements of the chip manufacturers versus the OEMs and how much cooperation should there be to share the verifiability of what they are doing? Maybe there are parts of the chip for which we can provide a simulator but it's hard to provide a real-- it's just not accessible unless you're a manufacturer. But maybe you can offer a simulator and compare the simulator versus the chip.

Maybe we can chip away at the NDA problem since NDAs sometimes protect firmware.

There are open-source java SDKs that you can potentially use. But you run into a problem where a lot of the secure element vendors will also supply an additional vendor library with additional cryptographic primitives maybe because they have an implementation of it that isn't quite compatible with the public javacard API or because they have some primitives or some hardware acceleration for algorithms which aren't in the javacard public specification yet or because the vendor implemented it in some weird way. Then any code that calls into those can't be published because you're calling essentially an API that is protected by an NDA and even the existence of that API is protected by the NDA.

There's a few things to try to do to maximize the amount of code that we can open-source running in a javacard VM. It's definitely an issue. Ultimately the runtime itself, the VM implementation itself is of course not open-source. I think one of the interesting things would be, an open-source javacard VM and a javacard runtime environment that has managed to pass let's say EVMco certification for payments. That would be really cool. It would probably require several companies with funds cooperating to make that happen. Those certifications can be quite expensive. The secure element vendors are not incentivized so much to pursue that or to open-source that because they are invested in that kind of certification.

Blockchain Commons has been working to define what we call "open development" which is that, well, throwing something over the wall and calling it open-source is quite arguably bullshit. Just because it's open-source doesn't mean it's secure; just because there are many eyes that could look at it, doesn't mean that there are many eyes that do actually look at it. What are the best practices? One of the items we have are these levels- open-source, inspectable, observable, reproducible, testable, cooperative, distributed, standardized, etc. I don't know if those are the right levels. There has been some questions whether Blockchain Commons should be involved in working with you to create standards for you to say this is the level you're at with your open development practices? There are so many people out there, I would be quite happy if most of them got to level 2 where bugs and feature requests are read and responded to which I think most of you guys do. Even chip designers are subject to NDAs from chip production facilities, so it's rare that even they get to see everything. You might not be able to get to the higher levels defined in this document, but that might be fine for one particular firmware whereas .. kind of at the OEM or higher layer. Is there an interest in having further discussion about what this means and how it applies?

There are often patent issues as well. You can't just release something and calling it open. There will be legal problems with that.

I think it's a redherring for us to consider getting payment network certifications or adhering to their standards. I hope that our industry will be big enough that we will develop our own standards that apply to us rather than payment terminals used in other industries. We're attaching to an SE chip that wasn't really designed for our use case. I would hope that we can have an SE from TropicSquare or Crossbar that is designed for the use cases that we're interested in and not ones that the payment card industry is interested in.

I agree. We are also using an SE not specifically designed for what we're trying to use it for. What sort of product is being built, whether single purpose or general purpose. Some of us want to work with existing payment terminals.

Also some hardware manufacturers have special arrangements with platform manufacturers. You can't just go to Apple and say hey I'm an Apple developer. They have to go to FIDO or some credit card organization and say somebody is asking for more functionality and that can be quite a closed process. You have no idea where you stand and how long it might take. When you deal with Apple, you do what they tell you to do. You don't get a lot of leverage. They decide how their platform shall be used and they decide all the bits if you want to participate in it, and that applies to their payment platform as well. But on the other hand, they can dictate silicon features that go into future chips and some of that does end up trickling down and being available to the rest of us.

# Supply chain

We have discovered a lot of these problems but is there anything- questions or problems that we haven't already discussed? I would like to move away from PINs that are- are there opportunities for other techniques? I don't know if CPACE or OPAQUE will work. Ken is doing some tricks with PIN hashing. With OPAQUE, your phone connected to an external device or your web app connected to an external device... the PIN is never actually transferred, it's really creating a diffie-hellman like pairing between the two such that you don't have to do PINs on the hardware. I don't know what the opportunities are there.

I think Blockstream Jade is doing a PIN server.

There's a reason why Blockchain Commons has an esplora instance in addition to blockstream.info-- I don't want to be dependent on a single server.

https://github.com/Blockstream/blind_pin_server

Someone brought up something I didn't understand. Did you say there are some privacy concerns with some supply chain validation? That someone might be identifying specifically their wallet.

We have a device serial number which is easy to read and then there's the value that is stored in the supply chain validation key which is not easy to read and it's not readable unless you decap the secure element.

Is that the same for every device? The supply chain validation should be stronger if you have a unique value in each one, right?

I agree. We might reconsider this in the future. Customers were telling us that they didn't like the idea of us retaining an ID in our database that was somehow associated with their device.

That's interesting.

Having a cryptographically strong unique ID is better than a scary plaintext serial number. The flip side of this is that securing your supply chain secret is hard because you need it on the manufacturing line, and how do you protect that? Who is manufacturing it? Who has access on the floor? What machine or hardware security module is connected to the manufacturing line? If there's a way to put unique things on devices but not require something on the verification... some sort of zero-knowledge proof of it? Devices can have a unique supply chain key burnt into them, so you don't have to protect it, but perhaps the backend doesn't need to... some protocol like that.

I saw someone with a different step of the manufacturing process they put a serial number that was not on the device physically that was never inside the device. But then that number in some fashion could be entered into the device to prove something. I don't know if there was some stupid trick like a XOR or what they were doing there but there might be something there where the secret that is physically on the device is used in some fashion.

We're getting close to the end of the hour.

One thing brought up in chat was going back to the discussion of verifying firmware. Daniel posted a link that talks about verifiable computation. I think it's a good idea. The basic idea is that you have some language, you make a transcript of the computation, you sign it with some kind of zero-knowledge proof and then the hardware can prove that some computation expected has happened. Another similar paper is ZEXE, Blockstream's simplicity is also capable of doing this because it's decidable and not turing complete which you could also do like chialisp.

There are some interesting things in that family where we don't have to do it all, but just enough to verifying something specific. We don't need a high-powered homomorphic technique but maybe we can demonstrate the verification code proofs are if you're limited to 6 opcodes maybe that's everything you need for bootstrapping. We don't have to verify all kinds of code, we need to verify our supply chain verification. We need to validate, rather, two v words- different meanings.

# The Bigger Picture

I wanted to close with a discussion about the bigger picture. This is the second Silicon Salon and we have dropped to the foundations. I don't know if there are some specific things we ought to take as action items. I think all of you have each other's contact information and can ask each other questions or I'd be glad to arrange for private meetings and things of that nature to review each other's specs or code or other different types of things.

Is there any particular low-hanging fruit in firmware that we ought to be working on together on?

One thing brought up as a question is whether there's any standard way for doing supply chain authentication, rather than everyone doing their own. There isn't one yet, but perhaps that's an opportunity to have a best practices design of how these things can be done especially given the potential privacy issues with customer PII. Maybe best practices and evaluation of tradeoffs.

We can add that topic to the Gordian architecture discussions since two of you are involved in that. Maybe there's a standard way both of your devices could verify each other, or a standard way of doing it.

FPGAs obviously have bitstreams and you can verify the bitstream. But has anyone been working on validating an FPGA? Could you load up a series of bitstreams on a FPGA device and have it run certain computations and prove that it executed those correctly to prove that the fabric was not modified and then you have some confidence that when you load a certain bitstream it's actually executing that versus not doing something else?

Bunnie probably has some things to say about that. I vaguely recall a paper on that. I think one of the limitations is that all the FPGAs themselves have bootloaders so you're just moving the target to another layer. And none of the FPGA bootloaders are open.

We might always have this problem of having to move to another thing that you have to trust.

Maybe. Pretty much every decent electrical engineering university can verify silicon chips that are above 75nm. Maybe our ultimate bottom root of trusts are on slow 180nm large silicon all used for bootstrapping a device.

We were thinking about this as well with the skywater PDK stuff. Is this an option? Even for the cryptography stuff, we don't need stuff to be super quick. Some of these slower process nodes might be acceptable for some of the needs that we have.

On the other hand, I'm looking forward to Crossbar's chip or rather Cramium's chip. There's a whole bunch of things like FROST or other operations that are very hard to do on a SE right now and even on current MCUs I think you might be pushing it. We'll find out. Ken you're on the fastest chip at this particular point.... homomorphic encryption in general, or homomorphic computation in general puts a lot of strain on the processor.

Try out the FROST code. Jesse's FROST code is pretty slow but it's just a bunch of elliptic curve adds and multiplies. If you can optimize that in hardware, I'd like to see those results.

The topic of the next Silicon Salon might be acceleration. We had a lot of discussion about oh well we want to do secp etc, but it could be a lot more useful to have silicon acceleration for very specific functions that are 64 bytes or whatever the magic numbers are. I've heard about ..... ((speaker lost audio)).