SLP238 Zach Herbert & Ken Carpenter – Passport by Foundation Devices: Air Gapped Hardware Wallet

Posted in: bitcoin Posted on Posted in: , , , , , , ,

The market for high quality hardware wallets is becoming more competitive with new entrants over time. Zach Herbert & Ken Carpenter of Foundation Devices join me to talk about their new upcoming product, Passport. Passport is fully air gapped (QR or microSD), PSBT, and designed with an open source mindset. We chat: 

  • Zach and Ken’s history with Obelisk prior to Foundation
  • Overview of Passport
  • Features
  • Approach with software
  • QR air gapping
  • Seed Generation
  • Firmware updates
  • Pricing and Timing

Guest links:

Relevant episodes:

Sponsors:

Stephan Livera links:

Podcast Transcript:

Stephan Livera: Zach and Ken, welcome to the show!

Zach Herbert: Thanks for having us!

Ken Carpenter: Yeah! Thanks! Good to be here!

Stephan Livera: So guys, great to chat with you and I have had a chance to look at your device that you’ve given me as a tester. But obviously just for the listeners who may not know you, can you just give us a little bit of background on yourselves, where you came from, and what you were working on before all of this Bitcoin stuff?

Zach Herbert: Yeah definitely! I can go ahead and get us started. I have been following Bitcoin since around 2013. I lurked for a few years on Bitcoin Twitter and Reddit, and then did a few smaller projects. Around 2016 I was selling hardward wallets on OpenBazaar if you remember that decentralized marketplace. That was a fun and interesting experience. I have a mechanical engineering background and I dropped out of business school actually to join up with a local company in the cryptocurrency space in Boston. So I went through the phase of getting really into Bitcoin for the ideals of decentralization, and then getting into some of the other cryptocurrency stuff and then realizing that Bitcoin is what actually is important. So I and Ken also worked for a company called Nebulus in Boston that was making a couple different products. And one of them was Obelisk. And we were making cryptocurrency mining ASICs for Siacoin and for Decred. And so from 2017–2019 we actually learned how to make hardware and we crowdfunded and sold and shipped over $26 million in mining hardware over a couple different generations all manufactured in the USA. Around mid-2019 we started to get really excited about the idea of building a Bitcoin hardware wallet. We actually were really inspired by your podcast series with hardware wallets. I think that was around summer of 2019. Specifically that interview with Michael Flaxman where he was saying, Every Bitcoin hardware wallet sucks! And so a lot of those ideas resonated with us and we just kept talking about it. Ultimately myself, Ken, and two of our other teammates decided to quit our jobs in the beginning of this year and start Foundation Devices with the goal of making the Open Hardware Foundation for Bitcoin and a sovereign decentralized Internet, starting with our first product which is a Bitcoin hardware wallet called Passport.

Stephan Livera [05:53]: Gotcha. And Ken let’s little hear a little bit from you also!

Ken Carpenter: Yeah sure! So my background is computer science, so I’m the software guy, software engineer and architect. In my career I’ve done everything from embedded systems and network protocols, device drivers, embedded databases, wrote a lot of C code, a lot of C+++. Worked for companies like Electronic Arts, Arista Networks, I worked for a high frequency trading company in Manhattan, developing data analysis and visualization tools, and around 2017 I got interested in cryptocurrency so I was a bit of a late bloomer I guess. I was interested in Siacoin which was made by Nebulus, and as I got more interested in that I got involved with the community there, I actually ended up quitting my job at the high frequency trading company and joining Obelisk as an employee. While I was there I was responsible for the firmware for the miners, the web-based user interface, I wrote the customer portal front-end and back-end, and actually I was the VP of sales, too, which was interesting! Also involved with a lot of customers who were working to find colocation facilities to host their miners. Over the course of that project brought two generations of software and hardware to market as Zach was mentioning. And that brought us up to today where now I’m head of software for Foundation Devices.

Stephan Livera [07:26]: I just wanted to touch on some of this Obelisk stuff because there’s been a little bit of chatter and I just think it’d be a good opportunity to just address and discuss that also to give the listeners a bit of your perspective on what happened with Obelisk as well because from what I’ve read, it seemed that there were some users complaining that they didn’t get what they’d purchased. Also I understand Zach you were not the CEO, you guys were working at this company, but could you just address some of those concerns that have been raised?

Zach Herbert: Yeah, absolutely! We’re actually really proud of the work we did at Obelisk. I joined right as the company was getting started as an early employee in the summer of 2017. And as you know, later in that Fall was the big crazy bull market. And so we launched this crowdfunding campaign for these ASIC miners without even having a photograph or an image or any really information about what the device would look like. So we said, Give us money and in 12 months from now we’ll give you a miner. As you know with a lot of hardware crowdfunding projects, they can often spiral out of control. That did not happen here. We actually shipped every device that we sold, we shipped over 12,000 ASIC miners. As Ken mentioned, across two generations of chips and three generations of industrial design. And we manufactured all of that in the US. We were an average of three or four months late depending on the batch that you ordered from. We were saying we would ship by August 31st I believe it was, of 2018, and I think the first shipment started going out in October or November, but we shipped everything. And it was all within about 20–30% towards the target spec that we were aiming for back when we started the sale. So I think the main contention is that the altcoin mining space is a total mess. And that’s one of the reasons why we didn’t want to be in that space anymore. Because it feels a lot like gambling. You can deliver exactly what you promise, or really close to what you promise, but what actually matters is the price of these underlying cryptocurrencies, and then also the other mining manufacturers. And so, Bitmain and INNOSILICON ended up flooding the market, especially on the Decred mining side, and none of the miners — when they received their devices in 2018 on the Decred side — made any money. So we did some cool stuff! For example, we knew that when we shipped these devices they probably weren’t gonna be profitable for the Decred miners and so we offered to do buybacks so that you could at least recoup some of your money and you can choose to reinvest that elsewhere. We were trying to be very, very friendly from a customer service perspective. We were extremely transparent throughout, so ultimately we’re really proud of what we did, and having shipped over 12,000 devices with only very minor delays.

Stephan Livera [10:45]: And so perhaps you want to also tell us a little bit more about the starting of Foundation? How did that come about?

Zach Herbert: Yeah so we just felt this unshakable itch to be founders and to be working on Bitcoin. So — I’ll let Ken comment for himself personally, but for me personally when I got into Bitcoin, I was very interested in it from the decentralization and efficiency perspective. So I was all about, Let’s get rid of these intermediaries, let’s get rid of these trusted third parties like banks and governments, and let’s just allow people to transact directly peer to peer online! Over time, though, I started to go really down the rabbit hole from podcasts like this one and Tales From the Crypt, from books like The Bitcoin Standard, and I just got so enamored with the Austrian economics perspective and about Bitcoin being the perfect money. And so between that and then being frustrated with the existing hardware wallets, then also knowing that we as a team had the potential to just design better hardware than what exists on the market today, we just felt like we had to do it! So we founded the company in mid-March and we officially started the company in April of this year. We raised a little bit of money from some small funds and angel investors, and we worked from April until now and we’re at the point now where we’re gonna be manufacturing in early or mid-January.

Ken Carpenter [12:30]: Yeah I would just add to that: our experience previous to that at Obelisk was that we were working like founders but we were not compensated or dealt with as founders, and so we felt like, Okay, well, we can do all of this stuff on our own and actually be the founders and be the ones making the decisions! And then be responsible for those decisions. That for me was a big part too, just having the autonomy and the fact that those of us who moved on to Foundation all had really aligned goals. Along the lines of what Zach was talking about as far as Bitcoin and design and better hardware.

Stephan Livera [13:16]: Great. So perhaps you could just tell us a little bit about the team. As far as I understand there are four main co-founders, and you’re slowly building up the team over time?

Zach Herbert: Exactly. I, like I mentioned before, have a background in mechanical engineering. I’m really obsessed with product design. I’ve always been obsessed with Apple as a company, and so as you can imagine as I’ve embraced Bitcoin and open source, I’ve fallen more and more out of love with Apple, and hoping that we can do similar great hardware designs but have it all open. And we also have Matt as one of our co-founders. He’s head of our circuit engineering. He was at Intel for a few years. He has a bachelor’s and master’s in electrical and circuit engineering. He’s a little bit of a circuit prodigy. And we also have Jacob who’s our head of supply chain who was at Formlabs previously. And then we have Ken of course as well here who’s our head of software and has an extensive background as he mentioned in every layer of the stack from firmware up to actually doing mobile apps.

Ken Carpenter: Zach always tells me to shorten my intros because I keep talking too much so that was a really abbreviated intro that I gave!

Zach Herbert: Yeah and we’re hoping to grow the team. So far we’ve done everything with our team of four. Between the four of us we can really hit every discipline of bringing hardware to market. A lot of the times, hardware teams struggle, especially on the supply chain and operations stuff — being able to source all these components and then manufacture them. We benefit from those experiences at Obelisk where we did so much manufacturing in the US. So we built up a lot of connections within different suppliers and manufacturers here, and so Passport is being fully assembled — circuit boards and everything — in the USA, which is also something that we’re really proud of.

Stephan Livera [15:07]: Cool. So I’ve had the chance to use the demo unit also. Perhaps you could just tell the listeners — what are you trying to achieve with the Passport device itself, which is the first product?

Zach Herbert: Passport is our effort to make hardware wallets as easy and secure as possible, while also giving you a device that you can feel proud of using, that feels elegant and up to the task, and maybe even worthy of your Bitcoin. So we’ve used all the hardware wallets of course over the years, and have been personally frustrated by whether it’s difficulty using the devices — for example, difficulty doing things as simple as entering a PIN number — to also being concerned from a security perspective about not having an air gap. And I think Michael Flaxman probably explained all these shortcomings much better than we can over a year ago on your podcast, but we think that things like PSBTs are really important, having a true air gap is really important, allowing for really easy text entry and navigation to encourage best practices when it comes to passphrases or other things like that is really important. So we just want to make that is so easy to use that maybe we can actually pull users off of Coinbase and other centralized exchanges, and also have this really great open source security model, where not only is the firmware completely open, but the hardware designs themselves are completely open, both for auditability and also so anyone can build off of our work.

Ken Carpenter [16:46]: Right, we’re seeing ahead here to Bitcoin exploding! And we just don’t think any of the wallets today are gonna get us to the hundreds of millions more people that are gonna be coming into Bitcoin. We just think we need to improve the user experience significantly to get those people on board.

Zach Herbert: We look at the hardware wallet space today as being very similar to the MP3 player space before the iPod came out. We’re not claiming that we’re the iPod, but we’re definitely striving to follow those similar principles in terms of design and UX. We’re just looking to make a product that millions of people can use. And our biggest fear is that we’re gonna see a massive amount of new users over the next few years during this bull market, and then throughout this decade, and that because it’s difficult to store your own keys, we’re gonna see all those users go to Coinbase or go into Grayscale or something like that. And it’s already quite scary where I think it’s maybe over 1% of the Bitcoin supply is with Coinbase custody right now, and that’s just not an environment that we want, and so we just wanna be able to provide users with actual sovereignty and ownership over their keys. But without them having to deal with a lot of the complexities and all the quirks of using today’s generation of hardware wallets.

Stephan Livera [18:26]: Cool. And so one interesting aspect here and when you’re doing a hardware wallet, some hardware wallet manufacturers in this space have chosen to try to provide the full stack, if you will. Like for example Ledger Live or Trezor’s web wallet. Whereas other hardware wallet manufacturers have opted more to just say, No we’re just making the hardware! You go and use the wallet software. So tell us a little bit about your approach on that part?

Zach Herbert: Yeah so our approach is definitely the second approach, and very much inspired by Coldcard’s approach. We think that at its essence, hardware is a delivery mechanism for great software. And we think that the software developers that are working on all these different projects, whether that’s Specter or Casa or whether it’s the team at Unchained Capital or whether it’s these newer multisig wallets like Lily or Nunchuk just came out a few weeks ago — there’s so much innovation on the software side. Our goal as a hardware manufacturer is to give all the software developers access to just a great device that they can really easily integrate with their applications, and then provide their users with more security. What that does is it allows for faster innovation on the software side. For example, Ledger’s Live app only just added full node integration like a week ago, but you’ve seen so many other wallets that have full node integration over the last few years, because when you’re more agile on the software side you can move faster. So that I think is key and important to us. And then there’s also the privacy concerns: if you start to trap users into this ecosystem where you use your corresponding desktop app to also be a place where they can buy Bitcoin or other cryptocurrencies and then swap between them and all that kind of stuff, you start to create a walled garden, and you also start to collect a lot of data about these users. You know xPubs, you know IP addresses, you know all this information. We don’t actually want any of this information! And so we try to carry that practice through even in our website and e-commerce store and we self-host everything on WordPress or Woocommerce, we self-host our own analytics. We don’t want to be giving data to anyone, and we want to be collecting the most minimal data as possible about our customers because there’s serious privacy concerns when you’re building this kind of stuff.

Stephan Livera [21:06]: Of course. I broadly agree with you. Perhaps just to — it might be fair to give a bit of a context there for some of the OG hardware manufacturers like Trezor and Ledger. They were started in a different era, you know? Before some of the software that we have today was available. Maybe part of it is like, they had to do things a certain way because they were around at a time when the tooling just wasn’t there. But now we do have better tooling and we have things like Specter desktop and we have things like Blue wallet which we might chat a little bit about. Certainly I think the approach of each party trying to specialize harder into their area and say, Okay I’m a hardware manufacturer and I’m just gonna focus on making the best possible hardware wallet I can! I think that makes a lot of sense to me! Perhaps the challenge then is, How do you make it all interoperable? I guess PSBT is part of the answer here. But how do you figure out or think about working with the different wallets that are available out there?

Zach Herbert [22:08]: Yeah so I think PSBT is definitely key here, and luckily there’s been a lot of great work that’s been done. When we actually started the company — you know, Passport uses QR codes as the primary means of communication to establish a really secure air-gap — we did not know what standard we would be using for QR codes. Luckily, Blockchain Commons, which is a non-profit group in this space, was working on that. So they basically developed this, it’s called [Uniform Resources specification (URs)] and that’s actually what we use to have interoperability with the QR codes.

Ken Carpenter [22:50]: So they’re also working on other standards to help hopefully make it easier for wallets to interoperate both between the software and the hardware wallets. So we’re part of the working groups there and keeping up with what they’re working on and providing our input on what we think the standard should be.

Zach Herbert: The goal is basically that 1) we have a universal standard for communicating data over multiple QR codes with an air gap, and it looks like with this URs standard from Blockchain Commons we’ve achieved that. And that’s currently used by all of the different wallets that are using URs whether that’s Cobo, Specter, Blue wallet — some of them are using an earlier beta version which is UR 1.0, but they should all be upgrading to UR 2.0 over the next several months, which is the final version released by Blockchain Commons. And then 2) Blockchain Commons is also doing some other cool stuff like standardizing the export, so that when you go ahead and you export your xPubs, you are able to export all of your xPubs and your various derivation paths in a single set of QR codes. Because right now it can be complicated — each software wallet requires an export from the hardware wallet in different formats. So with Passport we actually have a cool menu to make it really easy to pair up Passport with all of the different software wallets. We’re doing a lot of manual work on the back end to figure out, Okay, what format did they need this data in? So hopefully over the next several months we’ll be able to converge on the format for that as well, and then it gets really easy because you get to pretty instantly pair your hardware wallet with your software wallet, and then you get to pass data over multiple QR codes with the same protocol, and then you can have an explosion of air gapped singlesig and multisig hardware wallet transactions communicating with software wallets on desktop and on mobile!

Stephan Livera [24:50]: Yeah it’s certainly a great vision! Now is probably a good time to talk through my experience of trialing the unit out. So I’ve got a test unit as I mentioned earlier. I put in the batteries, spawn it up, at the start there was the, Verify on the website that this is the legitimate device, and then I spun up a small seed just with $5 on it as you guys had and basically imported that into Blue wallet using the QR codes. And so when you do that — because the entire device is air gapped, right ?— so everything is QR or SD card, basically. So I did it with a QR code and from my perspective I thought it was an interesting experience. Certainly very different to the typical, Plug in a USB or Do the SD card. And yeah Blue wallet picked it up very quickly. For me it was just about making sure you had the right lighting so the cameras could talk to each other. But once you get through that, the scanning worked pretty simply! So I thought that was pretty cool. Can you tell us a little bit about your thoughts there around how it’s gonna work with multisig?

Zach Herbert [26:14]: Yeah. It works very similar for multisig, to singlesig. I think the biggest difference with multisig is that 1) you typically have more data so that means more QR codes. Luckily as you probably saw from Blue wallet for Passport, they can pass QR codes back and forth pretty quickly. So you could pass — I believe for the tests you were doing it’s typically for singlesig 2–4 QR codes — and for multisig it could be a bunch more. But even holding up your phone to your hardware wallet for 5–10 seconds is going to be much faster than passing a micro SD back and forth or plugging into USB. And so we think the QR codes make multisig really great. The other big thing about multisig is being able to import that quorum of your different public keys and derivation paths so that you can actually verify addresses on device. That’s also something great that QR codes work for. It’s really easy to pass that information to the device in an air gapped way, using just a few QR codes that are encoded with this URs 2.0 protocol.

Ken Carpenter [27:31]: We’d like to work with the wallets to figure out what the right format is there and just make it super simple to import that quorum information.

Stephan Livera: Yeah and if you go back a year, one of the challenges that Michael Flaxman and others were talking about was this idea of, How do you make sure you actually have access to the change? And that you’re not signing to some quorum that doesn’t include only your three devices. Whereas as I understand then, once you register the other devices in the quorum, that’s now starting to give you additional protections against this kind of thing.

Zach Herbert [28:09]: Exactly! One thing that we haven’t looked at closely yet because we’ve been pretty heads down, but I did listen to your podcast with Stepan [Snigirev] from a couple weeks ago, and I believe Specter, while it’s experimenting with the idea of, When you display or you pass an address, you’re also passing the corresponding derivation path for that address, and that makes it extremely easy to verify on the hardware wallet that the address belongs to your device. Otherwise what you end up having to do is you have to brute force or pre-derive a lot of different potential addresses on the hardware wallet in order to compare. But if you have the derivation path, you can just immediately go and check if the addresses match. Hopefully throughout 2021 we’ll see some standards form on that side to make it just brain-dead simple to instantly verify that a singlesig or multisig address belongs to the hardware wallet. And I do think that the various multisig services — I hope all of them add this in 2021! Not all of them have the ability to export the multisig quorum information to a hardware wallet. I know Specter does, I believe Unchained Capital does now, I think they started that with Trezor, I think it’s also supported by Coldcard. I don’t believe that Casa does at this time, I don’t think that Blue wallet does either right now. So I think we’ll see a lot of progress on that in 2021 and hopefully by the end of next year we’ll just have really really easy standards to just verify an address on the hardware wallet and get people used to that as part of the flow. Because I think that’s something that people aren’t really used to right now. Oftentimes you just quickly create a receiving address and then send to that address. I think being able to quickly scan a QR code of that address from your own hardware wallet and get the thumbs up that the address belongs to you is going to be a killer feature!

Stephan Livera [32:20]: It’s interesting to see the way that security in this space is quickly ramping up. Perhaps in the past some of these things were available only to professional level or highly technical Bitcoin wizards! Whereas now some of these things are coming down the technical competence level requirements. It’s making some of these higher security aspects available to the everyman or at least it’s going to start out with the more tech-savvy people. Some of the points that some of the listeners might be thinking at this point is good to address—it’s common that in this space, people want something to be battle tested before they trust it with any serious amounts of funds. How are you thinking about that with, Well, it’s a first edition of a hardware wallet, listeners might be unclear that, Okay, it’s the first edition. Who knows if the first edition will really work? Maybe there will be hardware security hacks on it and things like that? How are you planning to get through that?

Zach Herbert [33:23]: I think that’s definitely very valid! There’s a couple different things there. One is that users should definitely slowly adopt Passport, right? We’re definitely not recommending that you go buy a Passport and then you throw all of your sats onto it in a singlesig setup. So I think multisig helps a lot there. There’s definitely a need for another air gapped multisig-friendly hardware wallet. In Michael Flaxman’s latest guide, I’m pretty sure that in his 2-of-3 multisig setup — for the third key — he wasn’t happy with any of the hardware wallets and so he recommended creating a seed offline and storing that offline on paper or on metal. And so we hope that we can be that third option! That way if there is a bug or if there is a vulnerability, it won’t impact you, right? It won’t impact loss of funds. There’s a couple of other things that we’re we’re doing. One is, the hardware architecture we’re using is not like invented by us — it’s the same architecture that Coldcard and Bitbox 02 use — which is when you have the standard microprocessor and then a secure element chip. In this case we’re using the same secure element chip as both Coldcard and Bitbox 02. From that perspective it’s not like we’ve invented some new architecture. The open source component also really helps because all of the hardware and all of the firmware is completely open. If we were closed source then that would be a really really hard sell. I’m not sure if Ken wants to add anything about the firmware, but we are having the Wallet.fail guys do our security audit.

Ken Carpenter [35:17]: Yeah that was what I was gonna mention. We’re gonna make sure that the code is fully audited before we ship it to any customers. We take it pretty seriously though. We know it’s the first time, but we want to store our Bitcoin on this thing too! We’re gonna make sure that we don’t lose our money, and we’ll sure that you don’t lose your money.

Zach Herbert: While we basically designed Passport — from a hardware perspective — from the ground up, and we started off with a fresh micro-Python project and did all of our hardware bring-up for all the various components and did a lot of the low-level firmware stuff, we have ported over a lot of Coldcard’s open source firmware as well, including the code that they use to create the Bitcoin transactions, and we looked at a lot of the code that we used for communicating with a secure element, and some of the security features too. So one of the great things about open source — especially when you’re dealing with GPL 3 code, which is very copyleft code where you open source your code and you only let other people use it if they’re going to open source their work in return — so one of the benefits of that is we have not started completely from scratch even though we’ve made a lot of changes, and that’s why it’s going to be really important to have experts look at what we’ve done and test it out. We have not just gone in, started completely from scratch and just messed around and put together some V1 of firmware that is completely untested! We’ve tried to use some building blocks and then architecture from existing devices so that we’re not just flying blind here. Hopefully that will help us a lot and help us avoid rookie mistakes that you would expect from a new hardware wallet manufacturer.

Ken Carpenter [37:03]: Yeah. So we tried to use the things that were solid, more or less unchanged, and then anywhere that we thought we wanted to do something differently, we spent quite a bit of time thinking about what changes we were making and the security model around those. I think we’re gonna be good — we’ll see what the audit has to say! And we’re planning to publish the result of that audit as well.

Stephan Livera: Excellent! I think another point that listeners might be thinking is: it also takes monitoring what’s going on in the Bitcoin space. As a quick example, as I understand there was that SegWit vulnerability earlier in the year. Technically this had actually been disclosed — I believe it was Gregory Sanders (@theinstagibbs) who had disclosed it maybe a couple years ago on the Bitcoin mailing list — actually what happened earlier this year was Saleem Rasheed had gone and done an exploit based on that, and so then that triggered off a round of Trezor updating their firmware and so on. The question I’m getting to is — it essentially takes a lot of: following the space and knowing what’s going on, probably some familiarity with Bitcoin Core and Bitcoin Core code, so how are you looking at that and trying to stay on top there?

Ken Carpenter [38:19]: Zach has been really great about following the news side of things and then pointing me to things. Because I’ve been really heads down getting the code working. One of the things I’ll be doing in the coming few weeks is going back over a lot of those issues that have been found over the time since we first started working on it, and integrating some of the patches and addressing some of the vulnerabilities. But I’ve also started looking at some of the Bitcoin Core, just to get a cursory level of familiarity with the code before I can start diving in. It’s definitely on our list to get more familiar with that code, and also we’re looking to hire more people in the future to help augment that knowledge.

Zach Herbert: Exactly. And then I think by sharing some common code with Coldcard helps us a lot, and then just looking at all the different updates from Ledger, Trezor, Bitbox, and from Coldcard on every release cycle has allowed us to get really comfortable with everything. We started the software project in April, and so we’re completely up to date with all the vulnerabilities from before April, and then over the next several weeks before we ship — as Ken mentioned — we’re going to be making sure that we address all the stuff that’s happened since April. That Segwit vulnerability was definitely interesting, where you can get someone to sign multiple transactions and then piece together basically a fraudulent transaction and steal their coins. Coldcard fixed that in an interesting way by storing a hash of the transaction on the Coldcard. I know that also that vulnerability created a lot of controversy. I believe that was the same fix that caused Trezor to close down a lot of derivation paths which broke compatibility with various software wallets. So we’re really cognizant of — as we make sure that we’re caught up with everything in the space and keeping track of all the vulnerabilities, we wanna make sure that we fix things in a way that makes the software wallet developers happy as opposed to breaking any functionality, which was pretty contentious earlier this year. I know that some things like BTCPay was affected, Casa was affected, a bunch of stuff was affected with how that specific Segwit vulnerability was fixed.

Stephen Livera [40:54]: Also I wanted to chat about seed generation and some of the different options available there. Can you tell us a little bit about the approach with seed generation and getting sufficient entropy and sufficient randomness there?

Zach Herbert: Yeah definitely! I’ll probably give just a higher level view of how we think about seeds and then Ken can take us through some of the nitty gritty, because we do something different than all the other hardware wallets with our main source of entropy. The way we think about seeds though — we kind of share Casa’s perspective on this, where we think that for normal people, seeds are really challenging to deal with. Our ideal scenario is that we never show the seed to the user. And that’s a different approach than what I think all the other hardware wallets take. The reason for that is because, as Bitcoin scales to millions and hundreds of millions of people, I think a majority of people still don’t really know what the seed phrase represents. If you look at the recent Ledger and now Trezor phishing scams going on right now — and I’ve actually clicked through these websites to test them out for fun — they typically revolve around tricking a user into entering their seed in a web browser. I think that that just doesn’t work in the long term for a normal person to be expected to write down and manage these seeds. So I think that multisig is really really important there. And one thing we’re doing as well — that you did not see in your demo because we haven’t finished this feature yet — but it’s the same way that Coldcard provides an option to do Micro SD backups. We actually include two industrial grade Micro SD cards with every Passport purchase. And one of them is for users to, if they want, backup their device to the Micro SD card, and that’s encrypted and they can write down a few BIP39 words off the word list in order to serve as the password to that SD card — but then they never actually see the seed. They never have to write down the seed. In order to get the seed out, you have to have both the Micro SD card and the password. And I think that’s a much better solution for the average user than writing the seed down. In terms of entropy, we have a few different sources of entropy in the device. We do have the embedded true random number generator in the secure element. We have the random number generator in the microprocessor. We also have an ambient light sensor, but we have something really really cool called an avalanche noise source

Ken Carpenter [43:30]: Yeah what we did there is—following some work by Bunny— it’s basically a circuit which is a combination of off the shelf components like resistors and capacitors and whatnot, and the combination of these components actually generates random noise. And we sample the noise and then use that sampled noise through a whitening algorithm and come up with random numbers. And we’ve done some work running it through random number analysis. We’re still doing some more work there but it’s looking really really good as a random source on its own. And then what we’re gonna do is probably combine that with the RNG on the MCU and the SC and maybe the ambient light sensor to get a bunch of different sources and combine them together.

Zach Herbert [44:22]: And one of our key philosophies as a company is to minimize or eliminate what we refer to — and what Bunny, who’s a famous hardware hacker who’s doing the B-Trusted and Precursor projects right now — what he refers to as blackbox silicon. Meaning that, in all of these electronic devices on the market, you have a ton of chips that are basically executing blackbox firmware. So the chip itself is a blackbox because we can’t, for example, go to ST Microelectronics — who makes our microprocessor — we can’t go them and say, Hey, can you give us your chip design so we can audit it? That’s a complete blackbox. Likewise, we can’t go to Microchip — who makes the secure element — and say, Hey can you give us the design of the block on your chip that has the true random number generator? And so what’s crazy in the electronics world is that pretty much every key or advanced component has an embedded chip running unknown firmware! That’s also true of most LCD screens and capacitive touch panels. So if you have a touchscreen, for example, on a hardware wallet, it probably has two chips that are running unknown firmware. And so the great thing about using this avalanche noise source is that we’re able to create entropy without trusting any blackbox silicon. One of our design goals over the next, probably few generations of Passport devices, is to further and further reduce the use of blackbox silicon to the point where every single chip in the device is open or we know exactly what kind of code is running on that. That’s something that we’re striving for from the philosophical perspective.

Stephan Livera [46:08]: Admirable goal! In terms of that, I also wanted to ask about the firmware and how firmware updates would be done. How would they be verified and put into the new device. Can you talk us through that process?

Ken Carpenter: Sure. So what we’re doing is we’re only allowing firmware that’s signed by Foundation, first of all — with a caveat that I’ll mention later. We’re doing a scheme where we have two signatures that are required for each firmware update. Let’s say we have five keys that are available: any two of those could sign a firmware update. Those would be held in different locations, so it gives a bit of friction to creating a firmware update for us, which is something we want. For example, I couldn’t go rogue and publish a firmware update on my own — it would take at least two of us to go rogue. And so the idea there is to provide that friction. And then on the bootloader, the bootloader is the one that is in control of deciding when firmware can be installed or not. It will validate the signatures on the firmware, and we have the blue and the green light on the device, and it will only turn the light blue when the firmware has been validated and confirmed that it was signed by Foundation Devices. That’s the first thing. We are looking at adding the ability for a customer to add their own signing key and keeping that key in the secure element. That would be a way for really advanced users to build their own code and load that onto the device. So if we were to look at how that works: the user is gonna get their key onto the device and load their firmware through the SD card, and the bootloader will pause on every boot if there’s non-Foundation firmware on there, just so that no user would be fooled in thinking that, Hey I’m running legitimate Foundation firmware here. There’s always gonna be an indication that it was firmware that was loaded by a third party. We’re also looking at a hardcore unit which would come completely unprogrammed. It would be probably a different SKU with a little bit different looking hardware, maybe different colors to the device and to the printed circuit board. But that would come without a loaded bootloader on it, even. And so you could basically hook up your own JTAG programming device and flash your own bootloader, flash your own firmware, and then decide to lock it down at any time if you wanted to do so. Maybe they’ll be like 10 or 20 people in the world that want that, but we want to be able to support those people if they want to do that kind of level of validation and verification on their own.

Zach Herbert [48:54]: Yeah and one thing that’s important to note is that, even if you’re using a hardware wallet that lets you build your own firmware from source and install it onto the device, there’s already a bootloader on the device that cannot be changed. It’s code that’s loaded in at the factory, and once it’s there it’s permanently there on the device and it cannot be updated with the firmware update. And so our design philosophy with the bootloader is to make it as minimal as possible so that it barely does anything except very basic functionality like figuring out what firmware updates to allow. And then as Ken mentioned, there’s definitely some tiny percent of users that just want to load up their own bootloader and so, it’s not too complicated for us to give that to users because it just means basically diverting a device at the factory that we would have programmed and sealed — we’re just sending that off to a very advanced technical user, maybe with a little kit where they can hook it up to their computer and they can build everything from source themselves. So while we’ve made some key design decisions — we’re restricting it only to allow firmware signed by Foundation Devices, we are still offering some of these power user features because we think, from a sovereignty perspective, that it’s really really important for the people that want to be able to build their stuff from source—they should be able to build that stuff from source — and we as a company should never stop them from doing that. Because then it’s a very slippery slope to be an Apple-like walled garden.

Stephan Livera [50:34]: Gotcha. I also thought it would be good to talk a little bit about in terms of attack surface of the device. The main two methods that I’ve seen from using the device, you see the QR code and the SD card. So can you talk to us a little bit about why you chose those methods and not having USB?

Ken Carpenter: Yeah. So we know that when you plug something into a computer, you’re potentially connecting it to the Internet. If there is any kind of malware installed on that computer, it would have access, potentially, to data over the USB. And we just wanted to close that down completely as a potential attack vector. If you’ve got an air gapped wallet that also has a USB connector, there’s just the ability for you to get lazy: you don’t want to do the air gapped way today, so you plug it in, and then you get pwned. With Passport, that’s just not even an option. What we want to do as a company is provide people with options that basically do the right thing and encourage them to do the right thing whenever possible — like, the secure thing. This is a way, we think, that achieves that, where the only way you can interact with the device is through Micro SD card and through QR codes. So we’re just cutting off entire vectors for attack, and mistakes.

Zach Herbert [52:00]: And ideally when we first set out to do this, being kind of silly, we didn’t want to even put a Micro SD card slot on the device at all. Because a Micro SD card is almost like a mini computer! You could theoretically have a compromised Micro SD that has some tiny little chip or circuit on it or something that monitors or modifies the data that’s being passed. The unfortunate truth is that, as of right now, 1) we’re using micro-Python and so our firmware updates are by nature going to be too large for QR codes. You know, we would love to be able to do a firmware update via QR codes. It seems kind of silly if you’re talking about hundreds of QR codes, but if you’re making some minimal changes to certain lines of code and you’re able to just pass the delta, it could be possible on a future unit, especially if we try to move to something like color QR codes or something like that in the future that can transmit a lot more data. That’s something that we’re keeping our eyes on. Just QR codes themselves are fantastic in terms of the auditability! You can always scan the QR codes and really quickly — either on mobile or on desktop — you can verify the output of that. So it’s much much harder to pass something malicious through QR codes. And just to add on to what Ken was saying about USB and maybe something about Bluetooth. There’s so many Bluetooth vulnerabilities all the time. We really don’t think a hardware wallet should have Bluetooth. You could just Google “Bluetooth vulnerabilities” I think there are like 3 this year that are pretty bad. And then with USB you can do a lot of tricky things with USB. And even basic dumb attacks that you wouldn’t even expect! Like Ledger had a vulnerability for example where you can modify the normal MCU on the Ledger — which is like the non-security chip on the device — and it could act as a keyboard! And so your first instinct might be like, Okay, that’s a weird attack. What’s the big deal there? But if you combine those avenues of attacks with the types of phishing scams that we’re seeing today, if you all of a sudden have the ability to open a web browser and take the user to a website, maybe that website is actually malicious and it’s asking for your seed and it tricks some large number of users. So we really don’t think that USB or Bluetooth belong in a hardware wallet. We also don’t think that SD cards do either but we’re at a point where I don’t think it’s possible to remove that. As Ken was mentioning, our goal is to always encourage the best user behavior and not give users any reason to trade off security for convenience which is what technology like USB and Bluetooth does.

Stephan Livera [55:06]: Turning now to the hardware wallet ecosystem and the security ecosystem. As you’ve mentioned, you’re aiming to be an open software, open source, open hardware approach where possible. How are you thinking about contribution into the ecosystem. Are there going to be code contributions or do you have any other considerations in mind there?

Zach Herbert: Yeah absolutely. One thing is we’ve already made all of our hardware designs open source under CERN’s open hardware license. CERN being the research organization, the one that makes the Large Hadron Collider and other projects. It’s a really great license. It’s specifically designed for hardware. We’re using the strong variant of their license which is very similar to GPL. It’s a viral copyleft hardware license so anyone is welcome to use our hardware designs as long as they open source their work as well, and preserve the copyright attribution. What’s great about that is that if you wanna come and use some of our hardware designs, if you want to, for example, look at our implementation of the avalanche noise source — which we actually implemented from Bunny’s OHL open source designs from B-Trusted — anyone is welcome to do that and use that in their projects. Likewise we’ve also open sourced the first alpha version of our firmware as GPL V3 which is another viral copyleft open source license for software. So anyone is welcome to use that work. We have contributed to the Blockchain Commons URs standard. Ken ported over the URs libraries to Python and Micro-Python, and so we published that code is completely open course. Ken is that under BSD?

Ken Carpenter: Yes I think so. The 1.0 version I haven’t published yet but that’ll be up this week. The 2.0 is already up though.

Zach Herbert: So we’ve already done that. We’ve started to contribute a little bit financially to some of these open projects as well. So we’re a very small monthly contributor to Blockchain Commons. And then if there’s things we can do to make contributions back to other projects or even other hardware wallets like Coldcard, we’re totally open and interested in doing so. However, each hardware wallet is designed differently so sometimes it can be really hard to take code from one and move it to the other, especially when you have different hardware in the device — different components. Sometimes instead of just doing a quick pull request it looks more like porting work from project to project — but we’re totally open to that as well. We’ve also used other work and we’ve been really careful to give attribution to the different open source libraries. If you go into our repo on GitHub for Passport firmware, and you can just get there from foundationdevices.com/passport-firmware, we give credit to Coldcard, we also use Trezor’s crypto and modcryptocurrency libraries so they have proper credit and attribution in there, we use two different QR code libraries and we have a pull request pending with one of them, we’ve mentioned the Blockchain Commons stuff. So we’re trying to be really careful and really good about giving attribution to all the different open source work that we’ve built upon.

Stephan Livera [58:46]: Gotcha. Yeah I mean, this is one of those spaces where there’s always wars going on between different producers and makers of things. So I don’t want to get into the drama of that, but hopefully at least there can be some level of multisig Kumbaya going on and people will be just like, Hey we’re all gonna do well out of this! With a lot of people coming in, and if we all play nicely together then maybe that is a reasonable future that we can hope for. One other area to discuss is pricing of the device. On the website the preorder is listed at $299 USD. Can you tell us a little bit about why this price point? And for what kinds of people do you think this makes sense? Obviously a straight new hodler who only has $30 it’s not worth it for them. Who’s the kind of person it makes sense for?

Zach Herbert: This makes sense for anyone who holds at least a few thousand dollars of Bitcoin or more. This definitely does not make sense if you hold $1000 of Bitcoin. If you’re gonna do that and hold a smaller amount of Bitcoin you’re probably gonna just have it on Cashapp or River or one of these other services. Or using something like Blue wallet on your phone. We think that from a price point perspective, it’s not like we decided to just start at this price point and then that’s it — we worked at it from a first principles perspective. It’s more expensive to make a really high quality hardware design that uses a larger screen that’s more trustable. The screen actually is auditable, it has a no-embedded processor running a known firmware, no blackbox silicon, so the screen is more expensive, we have a really high quality keypad experience — that’s more expensive. We use high quality plastics, the main structure of the device is casted in zinc alloy and plated in real copper. We have a processor that I think is the fastest processor by a good margin in any hardware wallet. It’s running at 480 MHz at its fastest, compared to Trezor’s Model T which is 120 or Coldcard which is 80 MHz. It’s significantly faster, that’s both to run the camera and also have faster processing of PSBT transactions. We’re also assembling the device in the USA and we’re physically on the floor at our manufacturer. And so when you add all that stuff up it does make for a more expensive product. Any hardware wallet with a QR code that is open source, that is running parts from reputable companies like STM or Microchip or Omnivision for the camera, Sharp for the screen, it’s going to be more expensive than your USB wallet with a small screen. And I think that’s okay! Because, especially if Bitcoin finds itself in a really positive bull market scenario, I think that paying a little bit more money for a much better user experience, and a really great air gap. I think it’s a no-brainer purchase!

Stephan Livera: Excellent. I think that’s all we got time for for this one. It’s a good time to wrap up. Zach and Ken where can we find you online?

Zach Herbert: We’re at https://foundationdevices.com/. We currently are accepting preorders for Passport. The official estimated ship date is March 31st, but we will be manufacturing in mid-January. And so hoping to ship the devices as soon as possible in later January or early February. We do a lot of blogging and we talk more about open hardware on our blog and on our site. We have a weekly newsletter as well. Definitely hop on the site, check us out, give us a follow on Twitter! And let us know if you have any feedback, you can always e-mail us at hello@foundationdevices.com.

Stephan Livera: Fantastic well thank you so much Zach and Ken for joining me on the show today!

Zach Herbert: Thanks!

Ken Carpenter: Yeah thanks for having us!

Comments (2)

Leave a Reply