Precursor: Open Source Hardware Development Platform (Feat. Nicolas Dorier as guest host)

Hi and welcome to Stephan Livera podcast. Today for episode two hundred and forty-one, I've got a really interesting discussion for you. My guest is Bunnie. He is a hacker and open hardware activist. He hold a PhD in electrical engineering, and he's got a really interesting project that I think many Bitcoin people would be interested in. And joining me as a guest co-host is Nicolas Dorier, who I'm sure Sure, if you're a regular listener, you know who he is. He is the creator of BTC Pay Server, and I've got some episodes, which I'll link in the show notes as well for those of you interested. But I think there's a really interesting topic around how can we move towards more open hardware, and in the Bitcoin world, we say don't trust, verify. So this is gonna be an interesting one for you. SLP is brought to you by Swan Bitcoin. Bitcoin has emerged as a major player on the global stage. It has been significantly de-risked over the past year with major investors, institutions and companies making big investments. At this point, everyone should probably own at least a little. A common way people get started is establishing their initial position with a one time buy and then start dollar cost averaging with automatic recurring buys. Swan Bitcoin was built to do just this. With Swan, you can create a recurring purchase plan like a hundred dollars a week or twenty dollars a day and you can make one time buys. Swan supports bank wires for larger amounts and ACH transfers for smaller one time buys is rolling out to members now. Swan is available in all states and territories of the US, including New York. Swan is the best place to send your friends and family when they're ready to start buying Bitcoin. There's no altcoins, just send them there. SwanBitcoin dot com slash livera and Swan will drop ten dollars of free Bitcoin into their account when they become a member. And now that we're entering a bull run, are you thinking about your Bitcoin security? Unchained Capital are building Bitcoin native financial services, but on the foundation of multi-signature, so this is a great option for you if you want some Guided assistance on how to set up a multi-signature vault, so you can take two hardware wallets, and if you use the commercial platform, there's no setup or storage fees if you build it on your own. But if you want some additional guidance, they've got the concierge package, so they will ship you two hardware wallets, they'll teach you about multi-signature, they'll answer your questions on a call, and deposit a thousand dollars of Bitcoin in your vault. Now, that normally costs fifteen hundred dollars, but you get fifty dollars off by using the code LIVERA. Unchained For those of you interested in self-directed Bitcoin retirement accounts, or if you're a company looking to move Bitcoin to treasury, Unchained Capital have a range of business accounts and features that will support you in moving your corporate treasury to Bitcoin, where your team controls the private keys. Go to unchained-capital dot com. And if you've got hardware wallets, well, you need to make sure those are backed up. Go to cyphersafe dot io and they are producing metal backup seed products like the Cipher Wheel, and they've got a relatively new product, the Bitcoin Recovery Tag, specifically helping you with recovery. It's an extra stainless steel tag with info like the original wallet, the gap limit, derivation types, scripts used, and all the major hardware wallets all have their own type of recovery tag specifying data for that hardware wallet type. You can attach this to your Seed word backup with a stainless steel cable included, and there's even a website link for recovery to help you or your heirs with recovering the coins on Electrum, so it really adds that value of helping you recover in practice. Bitcoin Recovery Tag works with any seed word backup device, including CypherWheel, CryptoSteel, CryptoKeys, BillFodle, and others. Go and buy yours at cyphersafe.io and use the code LIVERA for a discount. Bunnie and Nicola, welcome to the show.

Yeah, hey, great to be here. Thanks for having us. Thanks

a lot. Great. My listeners are already very familiar with Nicola, and Nicola's kind of gonna be a co-host this, this episode, guest co-host. And, Bunnie, let's hear a little bit about you. Where did you come from? What was your background?

Yeah, I guess you could say I'm more of electrical engineering background. I do a lot of open hardware work. I've designed things ranging from like 802.11, like, Lately, I've been looking a lot at building secure open source systems, things that you can trust, trying to figure out how deep the rabbit hole goes, because in my background, since I have a lot of background doing things like integrated circuits and building technology at that level, I, I have a sort of grasp of how little control we have over what happens at certain lower layers of technology, and, and so lately I've been, latest project I have, going on is Precursor, which is sort of an attempt to try and wrestle back some of that control, trying to peel back some Layers and get them back into the user's hands.

For Bitcoiner, I think a nice way as well to present Bunnie is like, it's like the pitch wheel of open hardware basically. The only difference is that you don't have a pitch wheel fact website about him, but maybe that will come.

So I think one interesting question, and I, and I know you've done a talk on this question as well, is around how we might initially, at the first glance, think, "Oh, okay, open source means it's more secure and we can trust it more," and yet I think you Necessarily, like, that doesn't go all the way. Why is that?

Right. So open source is a necessary but not sufficient condition for trust. The problem at the end of the, end of the day, imagine like a browser, you can get the, the source code for your browser and you can compile it, and even if you could compile it, do you really know what's going on the inside? You really don't, because there's just like so many millions of lines of code on the inside, and all it takes is one, you know, sort of bad line of code

Trust is something, it can't be so complicated that's intractable for you to audit or to understand at the end of the day. So trustability almost becomes a property of a system that you have to design in from the top. When you talk about sort of, trustability from this absolute, you know, sort of self-sovereign standpoint, there's trust from the standpoint of like, oh, you know, this is an Apple iPhone, I trust it because of a brand, right? But I, I don't, you know, that in and of itself is more like a faith

Opinions and repercussions if they violate the trust and, you know, oh, you know, against their corporate interest currently to sort of violate the trust, whatever it is, because of the branding and whatnot. But that's not a sort of a brass tacks physics based trust, right? And when you're talking about trust from this standpoint, I'm like, you know, if you want to stay and have an evidence based thread based on things that you can measure with your, you know, own two eyes and own two hands and sort of convince yourself on from the bottom up, a system has to be Right? To say that you're gonna spend, you know, five years auditing your browser source code is not feasible because five years from now, you're gonna have a set of patches that's gonna be absolutely essential for you to be secure, anyways. And then, you know, for you audit those patches, it'll take another, some months or whatever it is. And so you have this eternal cycle of, of sort of patches you have to keep looking at, and you're never getting work done, and also you never really catch up with the current status quo. And that's, that's one of the

An interesting point you're making as well, like you, you mentioned that most people see security like as a trust in a label. So on my side, like I got this kind of experience as well in the, in the banking and industry basically for custody, where it doesn't mat- doesn't matter how well at the low level the thing is secure, basically at the end of the day, they trust the label, like, some piece of equipment that they have been using for twenty years and that never failed them. It's kind of the same trust inside the label that the consumer have, but I That you have big audience that don't trust the label, one of them, of course, is the Bitcoiners, but I think like other, another type that also mentioned you as actually is like whistleblowers, like Edward Snowden or, or, or the like that really wish this kind of device, right?

Right, right. Yeah. That's absolutely right. And so, I mean, in a way, at a sociological level, trusting on labels is a thing that we almost have to do because we don't have enough time in the day to look at absolutely everything in our life, Tangential, but another thing I worry about is like my food. How do I know there isn't like heavy metal on the inside or some pesticide or something that can make me sick on the inside? You can worry yourself sick worrying about these types of things and never eat, but you-- at some point, I just have to trust that this restaurant is gonna serve me good food, and maybe, you know, the argument is that the, the person, the chef, eats the food too, right? So they'll-- at the very least, they'll be sick, as sick as I will be,

It's appropriate and you have to fall back on it, but I feel like on the technology front, we've just surrendered so much to just black boxes with no explanation on the inside, and the entire-- and the other key point is that the trust system can come unraveled so quickly with a single backdoor patch, right? Like everything, it's like it's just castles built upon sand right now.

Yes, I think that's a really interesting way to put it. And so in the Bitcoin world, we have a saying, "Don't trust, verify," but as you say, there's only so much that's practical for the average person, the normal person out there, and maybe you'll get someone who's a little bit more enthusiastic and they're willing to go through these things. And in the software world, that's things like compiling the software or doing, you know, GPG verify to check that the signature matches and doing some level of what we might call, you know, web of trust or

Signed off on this thing, and I know these other guys signed off there, but I think the interesting point is that it's not so easy to do with hardware, right?

Yeah, I mean, I, I think part of the problem, there's a couple of levels of issues in hardware. One is obviously, do you even trust the base design itself? Like, does this piece of hardware, the manufacturer who makes it, are they reliable? Is it, does it have the features they say it does? Does it not have extra features they didn't tell you about? Right? These are sort of the The key point of difference between software and hardware. In software, you have cryptographic tools to transfer trust. We can hash things and we can sign them and we can verify them very quickly at the point of use. So if, if Nicholas goes ahead and signs off on a package and says that, you know, I've looked at the source code and this is good and you can use it, you can reproduce sort of his efforts by hashing it in a way and then checking the signature and you can say, well, at least I know that I have exactly that piece of code that he signed off on and I'm You can't do that, right? You can't-- there's no hash function for hardware, there's no easy way for you to, you know, snap a finger and say, "This is exactly the Bitcoin wallet that the manufacturer intended me to have." You know, what if, what if someone put, you know, a small chip on the inside to record your keystrokes? What if, you know, what if there's a little exfiltration device on the inside to exfiltrate your keys, whatever it is? These types of things do happen in the wild. They sound a little crazy,

While, like just people being finding them inside of their earphones or whatnot, right? It's, they do happen, and that's also a level of thing to worry about, particularly when you start talking about things like Bitcoin, which have inherent value in and of itself.

I remember in one of your talks you were really-- I don't remember, I think it was a talk you made at the beginning of this year where you were explaining this trust problem, it was very well, well said, and basically your, your, your goal seemed to move the ver- Verification of hardware at the place of use, if that's what you think. So how do you feel you are far from this ideal with the, like, precursor and also with the bitrusty environment you're working on right now?

Right. So what Nicholas is referring to is that in the security world, they have this phrase called the time of check versus time of use problem. So if you go ahead and check that your browser was okay on the server, right? And then you went ahead and downloaded it, and someone, man in the middle, your download, and you didn't check it again. That It's called a time of check versus time of use. It was okay in the server, but the time of use was actually after you downloaded, someone can go ahead and modify it before you use it. And so in software, as a well-known principle, you always try to check it right before you use it. The exact copy you're gonna run is the thing that you've hashed and checked against the signature, right? Not some other copy in the cloud or on your disk. In hardware, similar concept is the place of check is the place of use. So a lot of, like, one of

the Will, you know, help solve this problem of trust in the supply chain. And it's, it's laudable on a number of fronts, but I think it's more of a political stunt to try and create local jobs or whatever, which is fine, you can do that, right? But the reason why it doesn't help the place of check, place of use problem is that it's been established that, a common vector for exploits is the couriers who deliver the package or if you're buying off of a distribution site like, you know, Amazon or something, you know, the customers

Pre-verified seals, modify the firmware, implant something inside, and then re-restore the seals, and then send it back to Amazon, and then the distributor is like, "Okay, well, they returned the product, all the seals are in place, we're just resell it to someone else. " You can't target who it goes to, but the fact of the matter is you're starting to put these devices out which have these implants on the inside, so they're-- and these are vectors that are completely close to the end user. They don't, they don't know nothing about where the The place of check isn't the place of use, right? Like you, you still have this big disconnect in terms of a very, a trivial exploit path. And, and, and when I say trivial, I mean also part of the problem is if you think about the incentives involved, you're trying to ship, maybe, say, you know, a Bitcoin wallet and you want to secure a million dollars of Bitcoin on it. And the person delivering it to you, how much are they being paid? What's their state in guaranteeing the integrity of that, packet, right? That person, you Aligned interest in terms of getting you the level of integrity of the hardware that you're expecting to secure your secrets with, right? And so this becomes sort of the existential problem that Precursor is trying to deal with. And so I guess I haven't mentioned in detail what Precursor is yet on the podcast for the, for listeners who don't know. So Precursor is a, open hardware development platform for secure applications, and its goal is to address these issues we're talking about so far, in this podcast. You can go to, Precu- Precursor. dev, that's the website, and it'll, bounce you to our current crowdfunding site where we just closed a round of crowdfunding for it, and we plan on shipping the product in this year, it's out now twenty twenty-one, at the late, late part of this year. And the idea is to explore the primitives and the necessary tools that we need to close this time of check to time of use gap. One of the cool parts about Precursor is that we use what's called a Field Programmable Gate Array, FPGA, as the computing element, which means that instead of trusting The CPU, which has your instructions, which has your encodings, which has all the debug backdoors, all this sort of stuff, normally we just trust ARM or Intel or someone like this to, you know, just create that CPU and we just take it, it's a black box. Crazy that we take it as a black box, we all do. We don't know what hidden instructions are on the inside of it, right? Instead of that, you're given the source code description of a RISC-V CPU and you can compile it yourself into the gates on the FPGA and then load it onto the The stuff right out of the box, right? But the point is that you can do it, you're empowered to do it. And then people say, "Well, then, but what of course, what if, you know, the FPGA itself is a piece of closed source silicon, you know, it's turtles all the way down. " This is true. It's true that, you know, there are still attack surfaces on everything, you can't seal all the doors. But we've really moved the goalposts forward because in the case of just getting a closed source CPU blob, someone could put

a

Discover this, right? You, you know, you can put a, a lock on it so that you can't fuzz it out and, but you can only be activated with certain instruction sequences, whatever it is, and it doesn't take a lot of gates to do that sort of thing, right? With, with the source code at least, with our device, you can look at it and see none of these things exist. The instruction decoders are decoding only the instructions we say there are, no more, no less, and they're doing it properly. And then, once you compile it down to the Fifty thousand gate or whatever, several hundred thousand gate device, right? And because of that unpredictability, it makes it very difficult for someone a priori to implant something that will pull out that one critical bit, right? So now any implant that tries to pull out or replicate would be a trivial attack on a closed source piece of silicon, now becomes a very large, you know, you're almost like implanting every bit of your RAM, you could imagine, as opposed to sort of just looking at a single word bank at a well-known location. Right? And so now we're talking about orders of magnitude difficulty in terms of executing implants and detectability on fundamental parts, such as, you know, the CPU and the structure and the, and the integrity of it.

So if I've understood you correctly, then you're saying that essentially in the current world with, you know, ARM and Intel and so on, it's all-- a lot of it is closed source and would not be apparent from a visual inspection. And so what you're saying is, this is taking us one step closer to that vision of the- The end user is able to more clearly detect if there's something different about the device because the, as I understand you, I might get this part wrong, but the memory allocation is more random and therefore that just necessitates a bigger, I guess, change to the physical device. Yeah, yeah, I'm covering a lot of

ground in a short period of time here. Let's, let's tease apart specs of, of the design. One is the physical device itself, and one is the what, what's inside the actual chips. So let's, let's start, let's start with the fea physical device itself. And so this is actually a little bit of a side jog from what we were talking about Intel and, and AMD. So first, you have to trust that the physical device itself is correct before we talk about anything else. Precursor is made to facilitate that type of inspection. It's very simply constructed, a single sided circuit board. We give you reference images of it so you don't have to be technical to understand what you're going. You just have to, you know, sort of visually do a diff between the two things, to see if anything's different on the inside. And, and it, it's simply constructed, so it's not like you're, you know, you need, you need crazy amounts of microscopes or whatever it is to do that type of thing. But that only gets you as far as a very gross physical, like, did someone, you know, what, what is this extra little black blob here with wires on it? Is that supposed to be there? No, okay, that must be an implant on the microphone or something like this, right? That, that's the kind of thing you can tell at that level, right? Now, when you That happens all inside those little black blobs of epoxy, right? We-- is-- in, in, in order to inspect those, you would have to have, you know, a desktop-sized microscope that costs several million dollars. It's not practical for end users to do that. And so our answer to that is that we then turn the CPU, CPU into almost basically a software description of a CPU. So all those tricks we talked about in terms of, signing and hashing, and, and so forth, you know, we could have a third party Auditor, look at our CPU code, the description of our, our architecture, so our, our equivalent description of an Intel or ARM CPU. We gave that to you at a level that, you know, someone like Nicolas could look at. He could sign off and say, "This is good." You can take that code and confirm its integrity all the way to the point of your house, right? And then you can compile that code yourself into the gates of one of these black boxes, right? Now, we're, we're all admitting that we can't know what's inside the black box. But where the key trick happens is that inside the black box, when we view our gates, it's a generic sea of gates. There are thirty, forty thousand called LUTs on the inside, and we don't know what does what. They're all just generic, you know, they do simple operations like adds and subtracts and, a little bit simpler than that, but just, let's just say it, let's, let's say it's at that level, right? And, and then we have a program that maps our description of the CPU to those, those lookup tables, those Changes in this, in the source, we basically put a random seed on the inside, is, is the trick that we use. And it, and we, and, and it, and it foils people's attempt to take that generic set of gates and bias it in a way that will allow someone to exploit the code that we put on the inside. That's the basic argument. So we basically turn, we take that hard, gnarly hardware problem of knowing what's inside of our CPU, we turn it into a software problem, and we put it into a generic set of gates which has a mapping

Predict where your exact implementation will go, and that's where the security property comes from. It's sort of a, you know, if you, if you run the numbers, it becomes cryptographically secure at the sort of complexity levels that we're talking about.

It's interesting, basically like those, so FPGA basically for listeners is like really like the 3D printer of electronics. Basically, you have this and you just fit that out any source code you want and they do whatever you want, and in this case is making a CPU out of it. So FPGA looks like Anybody else, it's, it's really harder, at the component level to, to pull out some kind of, attacks in the middle, because when the FPGA is shipped, basically like, can be anything, it can, it can be used for anything. There is one--

Yeah, that's a really good example, the 3D printer for hardware. Inside, like, like logic, I mean, it's not physically extruding things, but it's, you know, it's, it's a very similar concept.

I, what I really also as well with the FPGA I can learn what, how to make my own CPU, and I think it's very powerful. It's really powerful concepts, basically like it's something that can't be stopped. I guess FPGA, like there is lots of manufacturer everywhere in the world. So I guess from political condition, like say the US can prevent China from making CPU and like try to impose tariff on CPU from some specific manufacturer in, in China. But when we are talking about FPGA, since FPGA are like kind of commodity hardware, I guess it can be manufactured quite anywhere. Where and so that, that touch another topic that later I won't find out. I guess it will make the precursor more easily sourceable, because basically the, the FPGA like they're produced anywhere, right?

I mean, I, I think meta level you're correct in that, you know, so in practice we have to design in a single chip, right? Because we have to make a circuit board at the end of the day and validate it. There's other laws that we have to deal with, like EMC compliance. We can't just swap out chips and then use the same FCC designation.

It's Precursor will be able to do this though.

Absolutely, yeah. So, so at the point, yeah, basically the key point is that even if, if my venture were to fail, or if I were to, for some reason tomorrow cease to exist, right? Someone else could pick it up, the source code is there, they can pick their f-favorite FPGA in a matter of probably days, if not weeks, relay out the core design, and then use a different FPGA, and you'd be up and running again, right? So you're not-- There's no, I think your Whereas right now, if you wanted an alternative to, there's Intel and AMD, that's it. I mean, like, yeah, really hard to get a real, a functional alternative to that.

There was also one point I wanted to know, so in current Bitcoin wallet, lots of hardware wallet are using what they call a secure element, and, apparently that those security elements are kind of a big blob of, trust me, don't verify stuff. On your side, how do you protect the kind of secret without relying on such blob that actually can be very easily targeted? Because for sure it will be doing something secret, so it's a very honeypot of backdoor, I guess.

Yeah. That's a really good question. So now there's a second dimension, or rather than third or fourth dimension of security, which is tamper resistance, right? So up until this point, we've been talking about, do we even, have we taken the red pill yet, right? Basically, are we in reality? Because if someone gives you a piece of hardware that's been tampered with, you're sort of in the matrix, right? There's, you can't The real world or has someone put us in a cage and we don't even realize it. There's, the second aspect is once you know that you're in the real world, how do you know that you're continued to be in that world and someone hasn't tampered with it? And also, can you basically leave your wallet somewhere, walk away, and then know that even if someone stole it, you know, your secrets are safe, right? That's the tamper resistance aspect. I can go into this for days, right? this is a huge subject of research in the, in the Keys from Silicon, and I've done this, and some of my colleagues have done this. Our general opinion is, is that there's no-- even the super ultra secure, tamper resistant guys, they'll hold up maybe like a day or two against a well-equipped lab, right? There's just not-- there's no amount of-- and if you get into the circles and you start talking about the guys, about the unpublished work, you would just, your jaw would drop, like it's just like the, the most powerful technique recently is this technique called backside imaging. So it used to be that

Now actually a lot of chips these days, they, they thin them down before they put them in the device to make the devices thinner. The chips are so thin that you can actually see the parasitic photons that the trans-transistors emanate coming out the backside of the chip. So the chip as mounted, if you just look at it with a very sensitive camera, and this is, you know, cryogenically cooled stuff, so it's not like everyday sorts of stuff, you can actually see the patterns of bits firing real time without doing anything, you just turn it on and you can, you Security chips with all these-- they talk about secure meshes on top and puffs and like all this anti- you just turn them on, they're, they're just emitting out the backside all their secrets, right? You just have to have a good enough, you know, device and, and depackage it well enough to sort of see it, see it sort of thing. So that-- this is where we're at today, right? This is tamper resistance issues that we have today, right? You know, from that respect, I had an article that I wrote as part of my precursor campaign, Of untruth in advertising in this is that people don't even know how scared they should be, right, of what's on it. And so just the goal I have in Precursor is to be brutally honest as to what we can and cannot do, right? And so I took my own design, another one of my lives, I've, you know, I've done things like extract the security keys from the original Xbox, I've done a lot of security work in the past, right? I took my best crack at my own design, and of course, I found problems, right? This isn't Tamper resistance standpoint is as strong as the epoxy that you can put on it, right? Basically, if you can break off the epoxy and the metal shield, and you're a skilled attacker, you can extract the keys, right? With enough time, a couple hours, right? But it's, at this point, you'll definitely know someone has attacked it. You would see the evidence of the attack. It does take some time, but I would say that's roughly equivalent to about the security actually a lot of devices offer. And honestly, people say, "Oh, like, you know, my smartphone Plug in a USB cable, run this software, it's jailbroken. So it's, it's, you know, that's a, that's a zero touch break. There's no evidence of, of, of any sort of tampering with that type break issue, right? So at least this one here doesn't have any issues or that bad. But yeah, so someone physically took your device and they had a, a specially designed CNC mill to sort of remove the epoxy from it, they could, read out the keys. and to, to react to that, we, I introduced

Program what are called vaultel keys, the RAM back. So unfortunately, it, it really doesn't fit the use case of sort of archival storage of, of high value secrets like Bitcoin, because the problem is, is that if you forget to charge your battery, you lose everything in the wallet, right? It, it's, it's not the right solution for, for that. But for, for example, if you're, you have a device and it's to communicate with friends and you want to keep it very secure and if it gets in the wrong hands, you wanna make sure all the comms

That is a, that gives you a bounded sort of risk on very volatile, high value secrets, but the, the problem in Bitcoin of, of storing long term non volatile secrets, you know, sort of like your wallet keys, like, you know, that type of thing, it's very hard, probably.

Yeah. So it's almost like a dead man switch, if you will. Hey. So I guess we could just talk a little bit about some of the potential applications of Precursor. So I think you've mentioned that it could be like a password manager or a Bitcoin wallet or some kind of messaging Basically the main uses that you can think of.

Right. So basically Precursor itself came from a project that was originally called B-Triusted, and the genesis of it was I actually did a research paper with Ed Snowden on the introspection engine, which was an attempt to convert an iPhone into a trustable device by monitoring its radios and saying like, okay, if the radios aren't behaving the way you expect, then the iPhone's been compromised and therefore, you know, you should burn it or break it, throw it away, whatever it is. The outcome of that paper was that the iPhone was just too Coming out that we couldn't create a reliable trigger, a foolproof trigger that wouldn't make eventually just ignore all alarms, right? And, you know, the vendor itself would, you know, iPhones turn on even in airplane mode to do scans of the environment, we don't know why, apparently it's vendor sanctioned behavior, Apple doesn't comment on it, but that's just how it is, right? So, you know, when you have the situation where vendors are doing things already sketchy and you can't-- how are you supposed to find malware in that situation, right? So I thought about that

These types of things. This, this is kind of the genesis of a lot of these principles, was that effort. And so the direct target of that has always been sort of like supporting activists, journalists, people who are working in dangerous situations who need very high levels of, of security and they're up against like state level actors who have very little penalty for killing the person in question and a lot of motivation to do it, right? So this is, we're talking about, you know, high-stakes poker here, right? Which is why Precursor Design is so incredibly paranoid. And, and then- That was the, the, the goal was to, to make it a product called Be Trusted, and we wanted to be just out of the box simple, safe defaults. You didn't have to be a tech wizard to use it. Basically, if you had one of these devices, and, and you, you could do a basic amount of inspection on it, you knew you're okay. Precursor came about because we got the hardware of that finished, but the software for it is still a long way off. Software is, turns out, is very hard, it's very complicated, and that's where all Creating really good software that's simple, auditable, and understandable takes a very long time. And so we made the decision that, you know, there's other people and other communities who may benefit from a piece of hardware that's designed to this level of, of security and paranoia. For example, people just want to manage passwords, people want authenticator tokens they can trust, true two-second factors, people want Bitcoin wallets. These types of things are applications that could probably use the same hardware platform that we've created. and so we branded it Precursor to give it very, make it very It is a, it's a predecessor, it's a harbinger of other things, it's, it's something that you add your code to to become that application, and that's why we bill it as an open source hardware development platform, it's not a product in and of itself. And the idea is put it out there and other, maybe other communities will find things, maybe this is part of the reason why I'm on your podcast is to let your people know about this, possibility and maybe get interest and, and see what things I didn't expect could be useful to run on a platform

A moment after a word for the sponsors of the show. Lend at HodlHodl is a global Bitcoin backed lending platform so you can lend and borrow anonymously on your own terms. HodlHodl offers a peer to peer lending solution and they ensure secure and transparent collateral storage by providing multi signature escrow for each deal so you can grow your savings and earn attractive returns on your investment. If you've got stablecoins lying around, you can go and create an offer and earn interest by lending on the platform, or if you're holding Bitcoin's and you need some liquidity, you can borrow stablecoins and keep on hodling. So with the HODLHODL Lend platform, you set your own terms and put up offers depending on how long you wanna borrow or lend and the interest rate. Go and check it out at lend dot hoddlhoddle dot com. And finally, Knox. Knox is a Bitcoin custodian dedicated to ensuring comprehensive insurance coverage for client assets. Much of what passes as insurance today isn't purchased for the sake of protection, but for pure marketing reasons. Knox believes insurance should exist to make fund recovery possible. There's no sharing coverage between customers. Knox takes a unique approach when it comes to purchasing insurance for customer assets. Coverage is set aside exclusively for every customer in a one to one capacity, all with a comprehensive policy covering a range of loss and theft events, including internal collusion. If you are a Bitcoin company, RIA, fund, trust, or family office, make sure to contact Knox to discuss Bitcoin custody and insurance. Back to the show. I'm curious as well, so other, you know, people who are interested In these kinds of things, they might also have looked at other projects like, say, the Libram Five or the Pine Phone. How would Precursor distinguish from those kinds of projects?

Yeah, so that's a good question. The Libram Five, Pine Phone, those are wonderful open source projects, and they are-- they will, they do have open source down to the schematic level of the hardware, but the problem is, is they still have the, the CPU problem I described to you, in that like we don't know what goes in, like I think if they're ARM-based CPUs, From vendors that don't share the source code of the CPU. So there's a, there's a layer there that they can't get into in terms of trust and reliability. And also they, they aren't on the reduced attack surface train. They, they're not about the sort of simplified trust and respectability. They're more looking to replace your full-featured smartphone with a device that has a better trustability aspect to it, but you still have the complexity problem in the devices. And so, and that, that's a deliberate choice end users should be allowed to make. Like, I don't think that you can live your life practically in this complicated technological world with a device that is so simple that you could inspect it. There's just sort of like this Faustian choice we have to make as humans. We don't have enough time in our lifetimes to learn all of technology, but we need to know-- learn enough to be able to secure ourselves, right? And the sort of dichotomy I'm sort of approaching, at least personally, that, you know, what I do is like there's a set of things I do on devices that I don't know if they

Browsers are convenient, you know, Intel computers are cheap, right? Let's go ahead and use these things and do day-to-day things that don't matter. But then the things that I really do care about, the things that are risky and high value, I then put into this device that I trust, right? That's the dichotomy that I'm trying to move towards. Is that so you actually would imagine, like a Librem or a PinePhone would work hand in hand with a Precursor device. You would actually carry both of them, one of them for your, your daily browser

I wanted to come back where you were saying that a motivated attacker basically could probably find out way of reading secret, but I saw that, you plan as well to have a custom-made file system for, for the precursor that is plausible deny- with plausible deniability. And actually, it's a very familiar concept, Bitcoiner, because, like with Bitcoiner, there is one thing they are doing to protect themselves against, for two things. So one of the thing, they're protecting themselves from extraction of- Secret from directly from the device. One thing is that they choose a password on top of it, so to get the private key, you need basically what is written in the device plus this password, and the password is never stored. but the na-the nice thing is, as well in our protocol, like if you put a different password, you get a different wallet, so that's how we use plausible, plausible deniability. If I understand you, you're doing it at the OS level, right?

Right. Right. Yes, that's right, absolutely. So to clarify, we also password unlocks. We don't rely fully on the device's security for anything at the end of the day, so yes, the, the secondary passwords are important, and yes, we also intend to implement a sort of a tree of passwords, if you will, so that the secrets unravel over time. And, and this is part-- this is one of the, you know, I said the software is really hard, and, you know, plausible deniability is a really hard problem, and we are actually going all the way down to the file system level and re-implementing the file system so that even an Constantly, could not tell that there were certain secrets on the inside. We make the free space of your disk look exactly like erased files, and so if you forget your password, you literally have deleted the file. It's literally the same operation. The operating system to delete a file, if you request to do one, all it'll do is just re-encrypt it to a random key and then delete the key. That's what it does, right? And so plausible deniability at that level, the other trick that we're doing is that we plan to do is that instead of every file being like normally Size, you open it, you scan through the file to position, you read it, that's sort of like the POSIX abstraction for a file. Our files are actually databases on the inside, so once you refer to them, you open them, they have keys, and you can sort of query them for the, the contents. What this allows us to do is that as you type in more passwords to your system, we can actually merge in secure overlays. So your contact book will, when you type in your initial password, will just have your everyday contacts, your mom, your girlfriend, whatever it is, things And if you type in another password, it actually can across all the files and all your applications, add an overlay to it of that particular password linked contacts. That's the goal, right? And so now, in addition to that, you don't have to reload your applications or whatever it is, it just, you now see a new set of chat history, new things just appear. When you clear that password, they, they go away. And then you can have multiple password set. And so the idea is at some point in time, you know, if someone says, "I force you to show me You enter the passwords that you remember at the time, and you hand it to them, and that's it. They, they can't say that you-- there are more passwords or not more passwords. They could do a low-level disk scan, they won't find any evidence that there's files that aren't decrypted or there's things that aren't being accessed, 'cause that's what the free space looks like. All the free space looks like, you know, a, a file that you might have forgot the password to. That's kind of the way we're trying to structure the, the operating system,

I'm surprised that you do this because even like creating such kind of five system, I would expect that it's a huge endeavor. Like, I think the first one, have been done by Juliana Syng actually, if I, if I, if I'm correct. But I think there has been many other attempts, but like, don't see anything that has broke through. So I was surprised that basically you are developing that by yourself as well or, or, or are you doing this?

Yeah, no, I mean, it's, it's our team

Stays relatively stable now. In the next two years, I'm gonna spend sort of hashing out a lot of the software issues. There's another guy, Sean Cross, who's been absolutely instrumental. He's been writing all of the core OS stuff, and we have a couple other contributors who are working on the, the, you know, sort of graphics and rendering side of things. We're hoping to get more community to sort of contribute to the software, but, but yeah, it takes time. I mean, this is just a full admission that this is hard to do and it takes time,

Like I'm, you really need like some, I think you re-re want people starting, developers starting to use what you're doing basically. And like as a developer right now, I re want, imagine to make a Bitcoin wallet, say, like my only way right now for doing that would be to wait for the precursor, right?

I mean, we actually have, so the, there's a number of ways you can do it. So, so Precursor in and of itself, we have actually a software emulator for it online. If you go to, our repo and you look For x o u s hyphen core, Zeus core, we-- the, the operating system itself is written to, to run in what, what's called hosted mode, so you can either do it in a full hardware emulator or you can do it half of it, basically the UI rendering running on your, on your machine. It's really primitive, like all we have is message passing and stuff going on right now on, on the inside of it. But that's-- we're trying to facilitate some in that area early on. But, you know, you don't even have to use Zeus, our operating to almost any other platform that you want. And I imagine, more practically speaking, the early Bitcoin people probably don't wanna wait for us to implement all these fancy plausible deniability features and all of our fancy multilingual method inputs. Like we're, we're putting a lot of effort in before we even get to the application level. In which case, I fully expect someone's gonna just port some Artois to it or Linux or whatever it is, and then you're off to the races, right? It's just like any other platform. The problem is, is that when you port one of those Ar You don't get, you have, you're exposed to all the vulnerabilities in those real-time operating systems, right? The, the trust level, they're pretty good actually. I mean, honestly, they're, they're probably okay. But you don't rewriting everything for our system in Rust, so we get better guarantees on memory safety, whatnot. A lot of Artois is written in C, so, you know, if you have buffer overruns, good luck, right? These types of, there's these types of security properties that you have to deal with. Honestly, if you wanna port If you're experienced, you know, OS porter, and you could have enough functionality to build a Bitcoin wallet pretty, pretty simply on top of it. So that's kind of expect that's what's gonna happen before we get to our level of, security on our software side.

So in terms of the device, it doesn't have like a cellular modem, right? So it would be primarily out of the box, you would use it with Wi-Fi or how, how would that part of it work? Or is it mainly like you plug it in?

Yeah, that's the intention. Yeah, it The intent is that if you wanna use it on the go, you tether it to a phone or find a, a hotspot or something like this. We wanted to-- There's a lot of reasons why we're avoiding a cellular modem on this rev. There's no-- The system is architected so that later on, if we want to extend to include a cellular modem or something like this, it can. It just, from the standpoint of just holding really core to our principles of transparency, simplicity, you know, supply chain management, all these types of things, the cellular modems have a lot of challenges

the user might be looking for ways to, you know, pass back and forth data, and that might be a Bitcoin transaction to be signed, that kind of thing. So currently in the community, there's interest in using, you know, airgapped methods, things like, QR codes or SD card, micro SD cards. Are there any ideas around how the device could be either, you know, maybe a, a camera could be attached, or is it more like it would be plugged in to transfer across the unsigned transaction, that kind of thing?

Yeah, I think, if The easiest way to do it with the hardware you have would be to, to modulate it over the microphone. So it would still be plugged in via the microphone cable, like the headphone cable itself, you'd plug something into your, by the audio. I guess you could also plug in an actual microphone itself and just hold it to the speaker if you wanted to. But we have, we've actually had some experience doing air gap, acoustic modulation of data, which I think is fast enough for Bitcoin transactions. You're not gonna send a movie with acoustic modulation, but a few, a few

Bitcoin transaction is bit-is between one hundred bytes and like maximum one kilobytes, so I don't know if it's, it's good enough?

Yeah, yeah, yeah, yeah, yeah, yeah, yeah, we get rates easily. That would take like five to ten seconds to transfer something.

I think also another interesting property of doing this is that, transferring data by wi-- say by Wi-Fi, I guess it's relying on some chip that you can't easily inspect, but like, I guess transmitting data via acoustic is way more basic.

Yeah. Yeah, that's right. If we did it by, the good news is that for the audio path, the entire audio path is in the trusted domain, whereas the, if we were to add a video camera, we would have to add a chip, a fairly complicated chip that we don't- I don't know anything about, right? That would have to sort of process the video and whatnot. That being said, I did design the system so that a hacker could extend it, maybe to put a camera on the inside. The one of the thoughts I had was like, it'd be nice to get QR codes, whatever it is, if you want. It's, they're convenient, they're fast, they're easy to use, right? But, you know, I also, again, from the standpoint of just purity of the, of the hardware, I, I didn't want to sort And, and then all the DSP happens inside the CPU. And the good news is we have, from a, a different unrelated project, our team actually has a lot of experience with acoustic data modulation. One of the things we did, actually for the pandemic, we were, contracted to come up with some proposals for acoustic beacons for contact tracing, for, you know, p-privacy conscious people. And so we created ultrasonic data transfer methods for, you know, getting bits of cryptographic data back and forth between two tokens about a range of like a meter or so, something like this, right? But the data can be transferred, over that distance. And so we have that code base, and that's, that's a thing that if you just-- That works over free space. We have to deal with all the background noise and everything like this. If you plug it into a cable between, like, your computer-- And I would recommend doing that anyways, 'cause why would you want to broadcast your, your Bitcoin transaction anyways over free space? Put it over the wire anyways, even though, you know, wire is a wire. it should work quite well in terms of the

That in the market right now, but there is nobody that has done, that has gone by this route of using acoustic data, data. It's very interesting.

Yeah. The other cool thing about acoustic data modulations is that you can do it entirely, browser side, so you can have a JavaScript program that can modulate it. And another sort of fun hack is that you could even conceivably make a record, like if you want to really hardcore store something, take the thing, burn it into a record into the grooves of a record, and you can play it back later on into your

Of your digital data, like you can just, the record needle plus the analog amps, nothing will touch your data, no computer will touch it, right, as an archival format.

So that's cool, right? It's like those, steganographic techniques where they encode something into an image, kind of thing, but even crazier. Yeah, yeah, yeah,

yeah.

Cool. you mentioned also the trusted domain and an untrusted domain. Can you just, touch on that part for us a little bit?

Yeah. There's what's inside the box, you know, We have to have something that touches the outside world, and that's the untrusted domain. So the untrusted domain is basically a set of, firewalls and circuitry to, you know, we, we do everything, we worry about things like, you know, power emission side channels and sort of attack surfaces through USB, attack surfaces through WiFi. And so that, when we talk about untrusted domain, we have this set of chips that focus the attack surface down to an innum- an innumerable set of signals that we can think about, reason about, and test. And Just funnel them into the trusted domain, which as his name implies, that's where all the action happens, where all the private keys and everything's located, and that's where you-- you know, the trusted domain is basically what you want to audit and make sure everything's working correctly, and then the untrusted domain helps make sure that the rest of the world can't, you know, get an accidental side channel or something like this, some insight into what's happening inside the trusted domain. It's just another layer of, of security we added.

Nicola, any, kind of, final

Actually, so I have another question, but maybe it will, or my timing should take you to apply to that. But so we have, so in the Bitcoin community, most people are basic, I mean, most developers are more on the software side rather than the hardware side, but except a few individual, but lots of them are like happy to, like, try to build, you know, physical things. So for example, I'm thinking about, twenty, the, the Twitter handle is twenty i, twenty one is enough, is doing like a lightning network ATM and, basically This hardware construction is documenting everything, but the problem is that we, we are-- because we are mostly software developers, we are still like kind of immature in the way to open source what we are doing at the hardware level. So if you had, what kind of advice you will have to a company, for example, a hardware wallet company that is making a hardware wallet to properly open source entirely their design, what, what's the best way of doing this?

So, I mean, there are a set of, standards Created by the Open Source Hardware Alliance, OSHWA, that give pretty good guidelines about what you should publish to be in line with community norms for open source hardware, right? There's actually a certification process. You can actually get, register your design with the OSHWA license and get an actual certification number for your design as being compliant to those, standards. But basically, it involves, you know, releasing, you know, the schematics and the circuit board designs in a form format that is one that's both editable, but also one that's readable. It's a little bit tricky in the, in the hardware world because there are still a lot of proprietary design tools in use, and we, and that's just the reality of it. Like, like there's just not enough investment in the hardware realm to have a full open source stack all the way down to the chips. It's just not there yet. They're working on it, but we're getting there.

But one way of doing that, I would guess, is like, so I guess when you are creating your PCB,

Artifacts like, for example, the bomb or you call bill of material. Yeah, yeah. Yeah. You can generate the bill of material, but the bill of material can be just in text form, so like other people can easily review it. That's

right. That's

right. Or, or like even for the schematic, actually the schematic I guess could be exported in SVG and like, you know, it's, it become way easier to, to collaborate between people. But, but right now, like, not really spread, right? Not

Yeah, I mean, I think, I, I can A specific recommendation is, but I always ship my schematics both in the native tool format and in PDF format, so that anyone who just wants to read it can look at it without a special tool, but then someone who's a hardware designer and has the tools can also edit it without having to, you know, laboriously copy and reproduce all the schematics and make mistakes along the way.

Yeah, but one thing is that you do that. So basically what you're doing is that you make your hardware there, you have this fixed design, and then you upload it following the standard. But like, like you Precursor is kind of like a developer board. So what will happen, I guess, from when you would ship it, is that some people will build their own customized precursor by changing some parts of the hardware or like some whatever is doing. So, but by doing that, basically it's kind of more collaborative approach. Like it's not like they, they every develop everything on their side and then ship it at the end and then never touch it again. I think it will be more in need of collaboration between several developer and also give, having a way to compare different design, like of those my prec Sure that I modified with my own stuff is different from the original one.

Yeah.

That, that's why I, I understand that you have this, you have already this kind of tool that when you are finished to build, you can present it in a proper way, but like you also need this kind of collaboration

back

and forth. Yeah.

Yeah. There's, there's, the collaborative aspect of hardware is still, work in progress. There's a number of services currently trying to create like the GitHub for hardware, that type of thing. There's, there's a num- it's a little It all comes down to this, the exact same problem we're talking about earlier of the whole, what does this individual unit in your hand mean relative to the reference design? A classic problem in hardware is that even my design files, the ones that I create, aren't synchronized with what goes into the assembly machine on the factory floor. And the reason is that the manufacturer themselves will oftentimes modify it to improve the manufacturability of the design, right? So, wow. Yeah. A very simple example is like if I'm trying to cut a piece of metal, and I specify a square edge on it, right? The cutting bit itself is round, you can't get a perfect square corner on that cut.

Yeah.

So the manufacturer will make a modification, either they will add an, an extra drill point, or they'll actually, you know, round out the corner, whatever it is. You don't get exactly what was in your CAD file, right? And so, and so, and so what happens is I actually have to go through, send it to the manufacturer, they have to go through their drill bit, drill bit or whatever it is Radiuses are, and I have to go-- this whole process of like taking all that back, if someone wants to truly reproduce an exact copy of that design, it's actually quite hard, right? There's, there's these very small subtleties, and it's like, you don't have this problem in the software world because once you compile something, you should--

It's all just deterministic, yeah.

Yeah, it's deterministic. Like, it actually comes down to literally the details of the, the CNC machine that's working on the, on that metal case that impart a sort of, sort of In terms of collaboration, so that's one sort of extreme example, but just you can imagine now when you're in that level of, of like one hardware guy just patches in some blue wires on something and makes a new version, how do you capture that in the schematic? Like, you know, those flying wires, like as a part of the circuit board, how do you annotate that? This, you know, literal patches, not, you know, not patches, but literal patches need to be communicated. So there's a lot of challenges there, but in principle, the idea and what I really do hope

This camera, and we're totally okay with the attack surface of the camera, which is completely fine. You can add it in and make your own version with a camera. I actually designed it so that it's relatively trivial, like you can almost take the base unit, ninety-nine percent of the design is the same, and you have to just modify a couple components to mount a camera in there and write some software, and then you have like a very, a different function device, right? So, so the hardware itself, Precursor itself, is modularly designed to facilitate the sort of community, you know, What they like, what they don't like, but oftentimes what happens is it, it starts with a need. Someone has an itch they have to scratch. I am the closest thing to scratching it, and they just wanna hack whatever into it, and they just-- And I try to give them easier places to hack that hopefully will make it easier for the rest of the community to pull it back in. But, you know, people surprise me all the time. They come up with elaborate ways that are much harder than I would think. And then, you know, it's hard to share it back, and That's, that's the essence of community building at the end of the day.

Right. And building off that point you were just making there, is it also a question here that, you know, it's the size of this market right now, so it may be that, right now most people are complacent, they're not really that interested in, you know, this ideal of, you know, verifying for yourself or having at least the ability to do so. How does that change if, you know, let's say, you know, Bitcoin becomes a lot bigger and a lot more people are

You know, how things, how these devices are manufactured and designed and things like that, and, you know, kind of how much bigger do you think the market would have to get before this becomes more of a viable thing for,

yeah,

you know, a typical user as opposed to the really hardcore technical user?

Yeah, I think this, I guess this conflates two aspects. One is the security aspect and one is the open source aspect. From a security standpoint, I will fully admit Precursor takes one of the most extreme positions you can get in terms of trustability and security. We make a lot of Trust, right? That's because our threat model is so severe. Like, we really took it to an extreme in terms of designing it, which means that in practice, a more mass adopted unit will have more features and have more attack surfaces, but you have to find that balance. On the other hand, if we don't move the goalposts all the way to the end of the field, we'll never know where it ends, right? So this is-- that's the idea is, is to do that. So I think that there'll be probably some, some point in the mass adoption curve where we Or, you know, the cellular radio interfaces, those, we can, we can contain those, right? Those aren't actual attack surfaces, just theoretical attack surfaces. And then in terms of sort of the trustability and reliability of the hardware, I think that, you know, the, the open source aspect, I mean, sort of the, the ability to look at it and say what's there or not, that will be driven more by-- It's almost a cat and mouse game, you know, in an ideal world, you just-- Obviously, you just everyone keeps their word, right? And there Dirty se- secrets of, of being in security world is that security experts drive both the supply and demand for their trade. Right? So if a security expert isn't having enough work defending computers, they go into the business of making exploits, which then creates demand, right, for their They're actually one of the few trades that can sort of legally control supply and demand for their efforts right now, right? And so, in a way, you know, what the demand for this sort of open hardware stuff will depend a bit on, you know, what we find out in the wild. If it turns out that in practice, no one ever goes through, you know, no one finds Bitcoin valuable enough to go ahead and, you know, do a supply chain exploit to steal ten million dollars worth of Bitcoin, then there'll be no demand for this type of thing. But I think once you actually And like it's actually not a theoretical thing, but actually a real thing, and this has happened. And if people are like, "Okay, well, you gotta avoid that. This is like essential, that you have to have the standard of inspectability, otherwise you're vulnerable to this," then I think people take it more seriously. But unfortunately, human behavior is really bad at doing things that are just good for them, because, you know, going to the gym, eating well, getting exercise, very hard for people to do, right? 'Cause it's sort of all this preventative maintenance type of thing

Your time of, of doing something about it. So the market for open hardware and, you know, inspectability and, you know, are there gonna be exploits inside of my hardware? Like how important is to open it up and, and, and this reproducibility? I think it's gonna depend in part upon what the adversaries do. The other potential outcome maybe is that we have, and this would be the ideal, you know, we're all holding hands and rainbows in the world and all sort of thing, you know, we have such a fecund and diverse innovation ecosystem around this that the mod Hardware designs are just desirable because we're so productive and so interesting, right? Yeah, very well, very well. I wish we could get there, but that's-- I'm not holding my breath for that outcome. It's usually driven more by fear than by, inspiration and, and hope.

So I guess the realistic answer then is, someone has to get pwned for a lot of money before they start thinking about, before people start taking it more seriously.

Come on, yeah, I mean, come on. A, a Forbes article about someone being pwned for

We talk about it for the next decade, right?

All right, Bunny. Well, look, I know, we said about sixty minutes, so I wanna respect your time, but obviously, before we let you go, can you just give the listeners an update where you're at with Precursor fundraising and for anybody who wants to support you or take a part in it, how can they get involved and follow you?

Yes, Precursor itself, like I said, you can go to, precursor.dev. It's a short URL that'll land you at our crowdfunding site. We just A higher price right now than the crowdfunding, but you can get one, you can get in the queue for one basically, and we hope to ship later this year. At the moment, at this very moment, actually really, really good shape. we've got all the certification ready pro-prototypes put into the pipe. We're working against the Chinese New Year deadline. We have a lot of suppliers all over the world, some of them are, are in Asia, and so they, we have to get all these prototypes done before Chinese New Year. And so we're on track to get,

To get those certifications. And, and so I think we're-- I'm very optimistic at the moment that with the pandemic, vaccine coming around and whatnot, maybe the supply chain will stabilize a bit and we won't have as many surprises as we had last year in terms of building things. And yeah, if you wanna follow me, Twitter account at bunnie studios, b u n n i e s t u d i o s, that's my Twitter, or you can just, yeah, check out precursor.dev and that'll land you at all our stuff, including our GitHub. All of our GitHub is Hyphen IO is our GitHub, but that's because we originated, as, as talked in the pa-podcast, as a project called Be Trusted. So I, I think that's all the deets. Thanks.

Great, great. So I'll include all those in the show notes and, thank you very much for joining us. Yeah,

thanks for having me.

Bye. So those websites are Precursor dot dev and of course, to find the show notes and the transcripts for this episode, go to stephanolivera dot com slash two four one. Make sure you subscribe or press like

And I'll see you in the citadels.