Getting Ethereum Signer running on open-source operating system and chip

Transcript

[music] [music] So hi everybody while we are setting up the slides uh and I am setting up the mic. Uh yes I can tell you that this workshop uh there is going to be a lot of talking uh because I am introducing you to a new kind of board a new kind of chip uh fully open source I mean from the RTL of the chip to the operating system to the applications that you are going to load on it. Uh so there will be a lot of talking before you move to actually doing something on your laptop. So if you were there to uh try to do something

with your fingers, uh there will be a lot of listening instead. So just to just to warn you, uh the workshop is going to be much more fun with a board. Uh so that you can actually try things on. Uh if you don't have one, uh you can ask Miam who is going to come just so that you can see her. Uh and you can ask her for a board. Uh you will need to have a USBC cable. uh and then you will be able to do a couple things with it uh during the workshop. So I will stop a bit uh when you have something to do. Uh but yeah [snorts] uh and you need a USBC cable. You will need to download a couple things. Uh it might be a little bit large. So if you are um depending

how the Wi-Fi works, uh you might only be able to run a few things, but um I think it's still going to be entertaining. Uh, and if you have a board later, you will be able to do a lot of things with it. Uh, if you are watching live, uh, by any chance, uh, so you don't have a board and I can't, uh, give one to you, uh, teleport one to you, uh, you can go to the crossbar booth, uh, level three, uh, after this talk, get one, and that's it. So, I'm just waiting for the slides.

Yeah. Isn't it? >> Oh, okay. So, yeah, please uh bear with me for a couple minutes. Okay.

Yeah. So, there are actually slides. Uh, so this is going to get a bit better. Uh, how do I move forward? I can. Okay. Well, the short story of my laptop just while you are waiting uh is that it's very secure. So, it needs to be connected to power to uh recover from sleep for some reason. Uh so, yeah, it's absolutely involuntary, but yes.

Uh I don't see a clicker. No. Oh, sorry. No, this is a clicker then. Yes. And yeah, it doesn't seem to click. Oh, it does click. Yes. No. Uh, no. It seems to move by itself. Oh, can I am supposed to point it somewhere? Maybe like here. Here. Oh, that.

That. Okay. Or there. there. Don't know. I'm trying stuff. Uh maybe if you can move back to the first slide then I mean I can tell you when to move to the next slide. Okay, cool. Thank you. Uh so sorry for the setup but yeah well now we can we

can start I think. Uh and yes since I have no feedback I will just turn from time to time. Okay, cool. Uh, okay, that's good. So, we can move to the we can move to the second slide. So, that's the intro. I'm going to show you this uh in this uh in this presentation.

I'm going I have been referencing a lot of other presentations and given them to code. Uh so here you have a list of all the presentations that I referenced. Uh that can be useful if you want for example to do more hardware stuff with the board because [snorts] we will be focusing on the software part. Uh but if you want to go into connecting a lead or connecting a screen to the board, it's completely something you can do. So here is the reference of the stuff of the different material I used and there are uh there is a list of other references at the end of the slides.

Uh so you can move to the next one. Yes. Um so regarding the regarding the agenda uh we will be talking first about what the board is. Uh then talk about the operating system that is going to run on the board. Um then yeah then getting started actually how to use the board how to do something with it. Uh what the bootflow looks like. Uh so because it's an operating system which is secure uh so you have a secure bootflow on it. Uh how to audit the chip before doing anything. Um this is very important because uh as I said the chip is fully verifiable but when you start loading software on it it will trigger a flag.

uh and if you do that um what you see from the audit is not reliable anymore. So even if you got the board and you are very impatient and you want to try something at least wait till the audit part otherwise the audit will be more or less meaningless. And finally I will tell you how to load the application which is a sample serer. Um I have made an Ethereum serer which is a rust crate open source that can be used with a lot of different applications and this is one uh of the example of a burner wallet running on this board or can move to the next one and again to the next one. Um so what is this chip? Um because yeah I've been talking about this chip which

looks very mysterious but to give you more information uh it is something that has been developed by Bunny that you might know as well quite famous hardware hacker uh it's a Vex 5 core so it's a fork of Vex 5 so an open source RI 5 CPU which is running at um which is running at a nice speed so Oops. [snorts] Yeah. So it's running at 350 MHz and it is assisted by a couple other cores that you can use to um interact with the with hardware a little bit faster. So today we will focus on the Vex 5 core since we won't be interacting with other hardware components. Um the board has

4 megabytes of rea is a flash technology. So you can imagine that it has 4 megabytes of flash. um the OS the boot and everything is going to take about three megabytes. Uh so you have one megabyte for applications. This is something you can change. I mean if you are if you want to recompile everything you can have more space for your application but if you don't change a kernel if you don't change the default partitions um you are going to have 1 megabyte for your applications. Um then the interesting part you have 2 megabytes of SRAMM which is quite big for an unbed system.

Usually you you are dealing with the months in the hundred of kilobytes. Uh so with two megabytes uh it's big enough to do some cool crypto stuff. Maybe not to generate proof at least not until clone manage to make them a lot smaller but you can you can try and anyway you got a lot of RAM so it's fun. Um then what else? You have crypto accelerators because it's a secure chip. You have a true random number generator uh using noise from the chip which can be very useful to generate your entropy. Of course you're still free to mix it with other sources. And you have a couple other peripherals that we won't really be talking about. Uh we will mostly be interacting with USB today. Uh but let's say at some point you want to connect

the screen, you could be playing with SPI, but today we just deal with a very bare USB board. Next uh yeah, so I just going I'm going quickly over that because uh yeah, I think that people will be familiar with programming. I will just mention uh two specific terms. So first the MMU which is a memory mapping unit. Um the main concept of an MMU is that you can map uh physical memory to virtual memory. Um it's useful usually in much bigger system but here we will see that the MMU is used to implement Rust memory management exactly as Rust is doing it.

Uh so it's a chip that is really um made to handle Rust applications which is pretty unique. Uh and then you have some um you have oneway counters on the chip which are backed by hardware. Um so those are those are counters that can only go up unlike crypto. So you can use that for a lot of stuff. I mean you can use off you can use it as a flag for example to mark a difference in your application. when the board switch to developer mode, it will use a one-way counter so that it cannot go back to a regular state and you know that the board could have been pumpered and [snorts] you could use that to implement a pin. I mean there are a lot of uh cool use cases with that and it's very hardware specific. So that's why I think

it's important to mention those two and for the others they are mostly for your reference. Um now if we want to compare uh this board with other boards that are usually u used I mean for do-it-yourself applications um this one is you will notice that it is basically it has a lot of memory uh it is very open um it is something that it has a lot of um security features that you won't find in other boards and yeah what else um it is rest native so which is something that other BS don't have and it is rather cheap uh for the list of um for the list of features. Um yes. So next slide. Um

it looks like this. So if you have the board in your hand, it's very uh easy to see that. Uh if you don't have it, here is a picture you can get later. Uh it's super simple. So it's basically the chip. Few components to make the chip, passive components to make the chip work. uh USB you have two buttons, one button for reset, one prog button that will be used uh to launch applications or to go back to boot one depending to go back to the boot um depending on the configuration of the board. Can move to the next one. [snorts] Um you will see uh one of the unique feature of the chip is that the chip and the package have been designed to be inspected which means that you can actually got you can take the RTL of the

chip from GitHub. You can compile it uh and then you can come to crossbar booth here and verify that the chip that you have is is matches what you can compile from the open source definition of the chip. Um so this is something that is absolutely unique. Uh I don't think there is any other chip that can be inspected this way. Um to give you a high level overview of what it looks like. On the next slide you are going to see big blocks of the chip. So it's not those are the different units you can have on the chip. So memory uh CPU accelerators other peripherals. And you'll see that it's not a perfect map. So it's still very high level but it's good enough to

know that nobody has been modifying your chip because if you are modifying a component like that you will end up with a different design because it's very difficult to map the same uh peripheral at the at the same location. Um, so you would see a difference. And the idea is that with everything that's going on with people getting creative with implants, uh, and everything, I have not seen a cheap implant yet, but why not? And [snorts] this technology makes it much harder to do something like that. Then we will be talking about the operating system called Zeus.

So has been designed by Bunny as well. uh and it's a very simple micro kernel which is using the MMU to be um to to run multiple applications and to securely isolate uh those different applications. Uh it's written in Rust. Applications are written in Rust and as I said it's very very rust oriented. We will see why a little bit later. An overview of Rust of Zeus sorry. So the way it's working um you have the boot you have a secure boot. So boot zero uh is a boot um layer that is never going to change. It will verify boot one and start boot one. Boot one can be replaced. Um then boot one can either

start a loader application if you want to update the operating system or it will start the kernel and then the applications are basically across the kernel and they are running. So here um the operating system is a bit monolithic because thank you just checking okay so I will keep Oops. [clears throat] Let's go back to this.

[cough] Nope. Uh can we go back? Yeah, thank you. Sorry. I think we will keep doing it that way if you don't mind. [snorts] So yeah, so the can the the way you create applications today is still monolytic because there is no application loader yet. So when you want to change an application, you are going to rebuild uh the full image and reflash the full image. Then um you to flash an image you will just copy it to the flash memory that is exposed by boot one when you start it.

[clears throat] Sorry. And yeah so this is the this is the way the applications are mapped on. So we can move to the can move to the next slide. Um so zoo is message oriented. So the way applications are going to communicate with each other is that they are going to send messages to one another. So for example, if you have an application that want to send a log, it will ask the kernel to send a message to the log application. The [snorts] log application is going to send the logs over USB.

So it will send a message to the kernel to talk to the USB application. Uh and it works like that. So you will have a lot of messages bouncing between the different applications can move on. So just for people who are not used to Rust uh the rest memory model is quite unique. It's something called uh mutables or shared which means that you can have many readers on one or one writer and never both. And sorry what we will see here is that um Zeus will enable us to enforce the Rust memory management model directly in hardware. So that's a combination of the

chip plus the operating system that makes it uh extremely well suited to run rest code. move to the next slide and again because so we can again move to the next because just an example uh yes so again the way it's going to work um using the MMU is that when you are sending a message uh to an application you are not going to copy things you are just going to map a different page to the MMU so once uh when you send the message the ownership of the um of the data is going to be passed to the next application using the MMU. So just using the mapping and then map back. So it's very

efficient. Uh you don't have copies and it completely maps what trust is doing internally. Can move on and move on again because the same thing explained differently. [laughter] You have a few uh types for the messages that you are going to send. Uh I'm going to go very quickly over that because in any case I don't think many of you will be writing code. Uh you will be defining your IDL, you will be defining your interface, your messages. Uh you will send it to your favorite agent and the agent will come out with something that you can use and actually that's how I develop on Rust. Um because I'm a C developer but it works very well and the code is acceptable. So that's that's

quite good news. I mean especially now in in October pretty good code. So can move on. Um the way the memory is used like any other a lot of embedded system memories the peripherals are are directly mapped to the memory. So if you look at the reference of the chip uh you'll see that you can just um you can just access those peripherals by accessing the memory. So that's nothing nothing weird on that. Can move on.

The way uh you are going to communicate between uh global services and the different applications. We have seen the log services for example is that you don't need to know the number of the process. You are going to ask a naming service for the service you want to access and then send the messages to this service. So this makes it very flexible to write your applications because uh you just have to know which application you are going to connect and then you can send your messages. Next one. Uh I think there was one before but yeah. Uh yes and there is a version of the standard library which is available. Uh since you only have one megabyte of

flash uh I don't think you are going to be using it but it's for your information. If you want to build something that is a bit bigger that doesn't have an implementation for no std, you can use a standard library and you can and you can compile and then you can run it. Not something I would recommend to do, but just know that it exists. Uh if at some point you want to run something very generic on um on this chip can move on. Uh getting started. Now we are getting to the part where you can do something with the board. Getting exciting.

Um yeah, >> so just a reminder that what you you want to run an audit before doing anything else. So because if you start loading an application on it, it's going to trigger this flag and then the data sent back by the audit is not really reliable because you could have a different boot and the chain of trust is broken. Okay, next one. So what are you going to need? Uh you are going to need first a board uh a data cable.

You are going to then to play with have a default installation of rust uh git uh a terminal. Yeah. Yeah. Screen as a terminal and couple other things. So the way you are going to connect on Linux um you are going to look at the device uh which are which is going to be mounted as both uh a mass storage and um a TTY. Um so you can use screen to connect to the TTY and then issue commands. That's it.

Uh okay. Yes. Can move to the next one. [snorts] Uh same thing on Mac. Uh so I don't have a Mac so this is uh fully generated by code but I have verified that it works. So you can actually look at um the name of the device in dev uh then connect to it then issue your command. So it's very it's very very similar but once you have this you can start communicating with the device. Um when you receive the device there is no application. So boot zero is just starting boot one and you are communicating with boot one.

So what can what else can you do with boot one? Uh other than the audit and I think the most uh useful thing I can think about is that you can change a parameter called boot weight uh which will change the way applications are run. Uh by default applications are not run when you power the board and you need to hit the pro button uh to switch to your application. If you change the value of boot weight, if you put it to if you put it to false, uh then the board will directly start your applications. And if you want to reflash, you need to go back to boot one to run back boot one. And in that case, you need to handle you need to hold prog while you are plugging um the chip. So it just to just to remember that if you

see that your application is not starting after flashing, uh just hit prog and see what happens. Uh it can be in one mode or in another mode. in case you forget uh it's a nice uh thing to remember. So next yeah so now we are I am just getting a little bit more details about the boot flow but I already gave plenty of them so it will be quick. Next [cough and laughter] so boot zero it cannot be flashed. Uh it is in the chip then it is the memory is marked as not writable. Um the only role of boot zero is to verify boot one and then to erase uh chip some chip secrets if uh the chip is running in developer

mode. Um after that you have boot one. Uh the role of boot one is to let you flash stuff and start the operating system if there is um something to if there is the operating system or the loader if you are going to update the operating system. Can move to the next one. Oh yeah. Yes. Yeah. So yes, that's it. We can move to the next one because I already go gave those details.

So yeah, it's a bit more details. I mean we can you can look at it in the presentation later but yeah you get the um you have already the general idea of how it works. So let's move on. Um yes. So the way things work here um is that the contours are going to be um so the contours the oneway contours are never going to be reset. So even if you switch to developer mode the contours are going to stay to the same value. Uh the chip keys are going to be erased if you if you do something uh but anything else I mean even the values you write in the different slots of ream are not going to be reset when you switch to

developer mode. Um but the thing is there is only one developer mode something to remember. So if you put your board into developer mode, anybody can then load an application and read the value of what you have written in memory. Um so remember that developer mode means that the chip is going to work in developer mode. It doesn't mean that you can uh launch something commercially in developer mode. It would be a very bad idea. Um, so if you need to launch something commercially on a bow chip, uh, it's best to contact Bunny uh, to get a signing key and to do something uh, correctly. U, but it's a perfect developer device. Just don't run it uh, commercially. I mean, don't start selling uh, Dowos in developer mode.

It's not a good idea. So the audit now uh we'll see how we can run the audit and how we can verify that boot zero boot one and everything on it is actually genuine. So it's quite simple. Uh you are just going after connecting the chip after connecting boot one uh you are going to type audit and audit will give you this output. So you will see an output with uh a bit of uh a bit of data that you are going to keep in a in a file. So you can refer to it later and see what you can and see what you can flash. So next slide.

Yeah. More descriptions of what you are going to see in boot one. Uh you can move to the next slide directly. Uh same again you can move to the next. Okay. So here's the important thing when you check the audit is to look at what you must not see. So if you see any of this it means that your board is already in developer mode uh which means that either uh you put it in developer mode and you forgot about it uh or someone gave you a chip that is not genuine. In that case you can start to panic but otherwise yeah there are the the audit is the audit is letting you verify basically um what is the code of the components burn into the chip and

currently running inside the chip plus [snorts] the state again when you switch to developer mode it's permanent you cannot go go out of developer mode this is why during doing the audit before flashing anything is very important so you will get an you will get some flash some hash codes I mean of the different part of the code and then once you have those hashes um the point is since the build is deterministic you can go back to GitHub I mean according to the version that you get and you are going to be able to build it uh and check that the hashes match what has been committed for this release so here you got the instructions to do it uh the build system is using gigs uh

so the deterministic build uh built on nix uh You can run that yourself. Please do not run it at the conference because otherwise I think you are going to ruin the Wi-Fi for pretty much everybody, but you can run that on a decent connection and rebuild everything. We check the ashes. So you can do it I mean in you can do it in in two ways. So you can just save the content of your audit results here and then start developing and then yeah and then check that later. Um because anyway you are going to be using the board for development. So it's mostly for reference that we are checking the audit.

So the audit is going to show you a few things. Uh it's going to show you that you can verify is a boot which is written into the chip. Uh yeah. No. Okay. So it's going to it's going basically to to tell you if you're in developer mode or not, which is the most important thing before uh you know that the chip is really uh what it should be. So and [snorts] after doing this you can as I said in the beginning uh do a physical validation of the chip. So look at everything that's running in the core and making sure that the chip is a real chip. And after you do that you basically have validated everything uh from the chip to the code. So you

know that you have the most verified chip in the universe. Move on. Yeah. So there are newer versions of boot one. Uh, one of the thing you can do after verifying is flashing the latest version by the way because there are some bug fixes but I'm not talking about that here. Yes. And [snorts] now I am going to talk about the Ethereum universal signer that you can run because um this is an Ethereum conference. Uh so you might want to sign some stuff. Uh so let's move on.

Um the way if you look at at a gen at the generic component of a hardware wallet we can have a couple boxes on there. Um so you have the seed management u what the hardware wallet is handling your seed is storing your seeds or not because you could have a stateless hardware wallet that is not storing seeds. Um then you have the cryptography which will be running everything related to bitcoin cryptography bitcoin signing and so on. uh the genuiness that can let you prove that the device is authentic by running um a challenge asking the asking the device to sign it comparing to something that you're comparing to something that you expect. Uh an important thing here is that the bow chip is not going to use

any kind of genuiness uh because the process to verify it is a bit different. So you have no secret in the chip. You are just going to verify all the boot chain as I said. uh so you cannot prove remotely uh that the device is genuine uh because you don't have a mechanism to do that but it could be completely doable. So typically if you want to hack on it uh that's an example of something you could do you could set a key in boot one and then erase it under some conditions this would be your genuine nest but basically uh it's up to you to implement it. It's not something that is done at the factory. Uh at the factory everything is done to avoid having private keys, secret keys in the chip or unique authentications.

Um no no sorry there are more boxes. Sorry. [snorts] Um then the application management layer uh on the application management it's how you are going to deal with dynamic applications. Here we don't have dynamic applications. So we don't have anything for application management. You are just going to refresh stuff. uh the UX so everything related to uh how actually the signer the hardware wallet is going to display things. Uh here you have no screen. Uh so the choice I've made for this quick demonstration is to have a burner wallet. So the wallet will just generate a seed when it boots and then we'll sign anything uh when you send a command. So of course it's not very secure. It's not something that you want to you don't

want to put real funds on it. Uh but it gives you some good basis to start hacking on it and to start either adding a screen on the dabau if you want or adding some mechanism to wait until you push a button to sign or even to have a remote screen on your phone if so you could establish a cryptographic uh channel with your phone and use it as a remote screen. I mean possibilities are rather endless. So I will let you hack on it. It's just an example. So remember don't do not store all your money on that. it's not going to be very safe. Um and then yeah the transport which is going to use either QR code or USB or B.

In that case for this device we only have USB but we are going to use the same protocol that we are using for QS. So for ERC 45 uh to7 um which is CEO. So the sar messages that are sent to the device are exactly the sore messages that are defined for 4527 uh which is quite convenient because we have enough memory to handle everything um using this standard. So it makes it quite simple to develop the application and to reuse the to reuse this common crate for everything. Um then yeah so speaking about the common crate which is the thing that we will be talking about now.

So what is the general generic signer doing? It's handling everything related to Ethereum signing. So decoding your transaction, decoding the C bar in 4527 so that you get something that is usable by your application. Signing knowing how to sign a transaction, how to sign a type data, how to sign generic data. It's absolutely not related to any to any operating system. So if you are writing something on rest on a hardware wallet, you can take it and you can use it basically. So it's quite opinionated uh because first it's running on rust. Uh of course uh if you want to be on Zeus you have to be on rust. So it's definitely uh biased a little bit towards goose uh for but

yeah it can run with anything rust based. Uh it's minimalistic uh which doesn't mean that there are no features. Um so it has a lot of features. Um I want to implement a reference for clear signing on it. Clear signing with with descriptors that could be shared between different hardware wallets. But it means that you can take the crate that you want and if you don't need everything for example if you don't need the cryptography stack because you already have one uh implemented in hardware you can just choose not to compile with it uh but still use um everything related to Ethereum decoding and yeah and it has props in mind uh so I always choose to pick uh minimalistic

applications for example here u before implementing 7730. So before implementing class signing uh I choose to just uh refer to something that I have been calling um that I have been calling verifiable signing. So sending hashes of what you are going to sign and you can then turn those hashes into 7730 but on the on your computer because uh what you need is a source of truth and the most simple source of source of truth you can get for what you're signing is a hash which is clearly verifiable of what you are signing uh and then you have no external dependencies and you can add the external dependencies outside of the

hardware wallet. So it makes it super simple. Um if we want to look a bit at the architecture of the serer so how it's going to work. Um so here you see different applications using the serer uh I have an application running on a commercial device made by foundation called passport. So this one we have a full UI it's a it's a colored screen uh the UI will be running with a framework called slint. Uh I have another one which is using the defcon 34 batch uh which is a daba with a screen and and some additional memory. So it's something that you can uh it's something on which and a camera. So it's something that you can use um the serer on and of course the uh well another device which

is so the dauo application and another device used um designed by crossbar which is called lost that you can see on their booth as well uh which is in a common form factor I mean it's more related to a common hardware wallet form factor with a screen buttons uh ble uh and any ink u but all those applications are going to use uh the same ser they are just using different part of the serer and then implementing uh implementing additional things uh related to the other components.

regarding the UX, regarding the transport that I named um that I was talking about before and yeah for everything that is Ethereum related um this um library is um using alloy so which is a famous Ethereum rest library um so you can see it as um you can see it as a well as a way to use more easily in your application so it's basically kind of wrapper around a log that you can use on very small devices.

Um so here yeah again a definition of the I mean just a small list of the different implementation that I have for the generic signer. So passport prime which is going to be a complex device uh running QoS which is a fork of sus. Oh thank you. Yes. Wow. Thank you. third one uh did the charm. I think that's it more or less. Uh [snorts] yes, but yeah, I still have to I still have to look at the screen but that's okay.

Um so yeah, so uh you have the ink USB and B uh the defcon 34 batch which has a camera uh the dabau which has nothing I mean only USB but all of them are using the same crate. So that's the message that I want to send. So this crate is very generic. Please use it uh and please comment on it. open issues, uh, send new, uh, send new implementations. Um, you'll see it's, uh, it's quite easy to use. Um, so this application again is a burner wallet. Uh, you can run it either on the board or on an emulator.

So if you don't have the board, you can you can still use it on an emulator and do everything that you would do on the board, but of course, uh, it's way more fun on the board. So, how is that going to run? uh you have a Python client which is going to talk to the device. uh the way it talks to the device is either through USB hid because the application is going to uh create a new USB uh interface which is using USB HID uh and if you um communicate with your emulator you're going to send the same messages over a TCP socket um then you are going to use yes the ease burner uh which is passing the messages and delegating the messages

either to USB or to the other transports So the way the messages are encoded uh it's just the C bar that you expect in 4527 uh plus a small header just listing um the size of the message that you are sending but it's uh yeah so the protocol is minimalistic by design as well. So you will need to fork two things that are on my GitHub at the moment because it's a it's a demo I mean for the it's a demo for defcon. Uh then fork the full Zus uh operating system because you need some tags for the builds that are not in my repo. Um so it's a way to it's a way just to make the build work well. Uh and

then you can then you can just build and flash the images. Uh so to flash the images you copy the free uh UF2 um files that have been created to the M storage. Uh you sync uh so think like uh you make sure that you eject properly the drive you push progue and that's it. Uh you should be running the iterum ser um so yeah that's it. That's a build. And when you are running the iterum ser the client you can run the client without any information. It will just use default data for signing so that you can verify that everything is going well. Um you can get an address. You can sign an Ethereum transaction. You can

sign uh a type message. You can sign a regular message. So you can do everything that you would like to do in on an Ethereum serer. Uh and then you can tweak it. Uh so we are moving to the interesting part. Um one thing that you will see is that when used it's going to use a different product ID for USB so that you can recognize if you are running boot one or if you are running the application. Um so that's one way to make sure that your application is running on the board. Again couple examples uh so what you can do but I already talked about it.

Uh and now uh the interesting things so what you can do if you want to tweak it it's very easy to tweak you'll see it's very small um you can you can so disable boot to boot immediately to the application uh if you want to run another application that is part of zeus for the dabau uh you have something called the console which is a shell that will let you uh play with peripherals or that will let you play with peripherals I mean that you could connect to the board So if you connect nothing it's not really useful but it's an example of another set of applications that you have. Um the way the build system works today is that everything is related to um the OS. So you are always building the OS and the

applications even if you don't want to change the OS but um then on the first time you need to flash everything but then if you just modify the applications um you just have to flash the app file you don't have to reflash the OS um to save a little bit of time and yeah again uh it's a burner so don't put your whole uh life savings on it it's a very bad idea just rather say it again than having people yelling at me because they lost some precious NFTs.

Uh and yeah, so list of resources you can use. Uh so everything that I that I said here might have been a bit boring if you didn't have the board, but yeah, hopefully you will take one uh you will hack it uh during is global. You will have a lot of fun with it. I know that myself I will try to implement some uh rail gun implementation for example so to have some nice privacy solution uh with um with a remote screen if possible so remote screen on a phone I mean it's I say if possible because as if time was limited in a hackathon but no we got infinite time because nobody's coding in hackathons anymore so yeah

that's it hope [snorts] you liked it uh sorry for everything. Uh sorry for being a bit late uh and for well playing [snorts] with my slides but hope you liked it and since we still have a little bit of time uh if you have some questions I will be happy to answer. Thank you. Why use a kernel? Yeah, it's a good question. Uh because it brings you a lot

of good things. I think it's nice to have multiple applications. It's nice to be to have for example, let's just say you want to have a you want to talk over USB. Uh it's a better model in my opinion to have a service to manage USB. uh to be able to schedule it uh to have a camel scheduling with USB rather than having some kind of big mess uh with a USB stack and your application doing everything and then coming back and forth to the USB stack. So I I just think it's a better design. >> Yeah, that's cool.

Yep. >> So they would run they would run audit. It's a very good question. So first you would get a key from Bunny to to sell it commercially. Uh then yes they would run the audit. uh and I think one important part is that you would like to be able to take out the different parts and to be able to run the iris verification of the chip itself. So if you want to push it into the max and use all the verifiability that you get with that chip uh it's much better if it can be taken apart and then used that way. So if you are familiar for example with a product called key card share uh which is adding a screen to an NFC card uh

basically it would be a great uh idea of a product that basically adds a screen to a dao uh do the audit do the audit verifies everything and then that lets you take the dabau away and implement implement your own iris inspection and verify that the chip is correct then you would have something that doesn't exist I mean elsewhere you would be able to verify everything from really from zero to to one. >> Um, so are you thinking about designing new risk 5 chips that have more SRAM? So this has two megaby or two megabytes of >> SRAM megabytes >> for like VOS 16 or any like postquantum

proof generation like are you thinking about designing chips with more uh SRAMM? >> Uh, so this would be a question for the chip designer. I mean, I'm just uh I'm just a poor user, so I I don't really know. Uh I I know that it's usually when you want to have more RAM, it's more common, I mean, to add the RAM externally uh and then to let the chip manage it. U so in a different package. Uh but then you run into additional issues. I mean, especially if you want your RAM to be on an encrypted bus. Uh then you have an attack vector because you have something going out. uh and you can listen to the communication between your chip and the RAM uh more um I mean yeah you can listen more to the

communication between the chip and the RAM. So then you have to think about which data is important which data is not important and it just gets things more complicated. So I think uh for the moment the size of the size of RAM needed uh to do some some proving is a problem. Uh definitely I hope we have we will end up with provers that need less RAM. I mean for for very simple operations like uh if we want to prove for example something for a privacy protocol uh I hope we end up with lightweight proving systems or just different designs. So well I mean for I don't want to I don't want to shield rail gun again but I will uh if you see for example an different a different implementation between tornado cache and

and privacy pool and rail gun um is that in tornado and privacy pool you are computing the signature and the proof at the same time. So you are basically putting all the private data in the proof and then uh you would need to run the proof to in the device I mean to be secure in rail gun you run the signature uh in one part and the proof in a different part. So it lets you prove uh prove things in an environment that is not secure and that has a lot of RAM. Uh and in that case you just leak privacy if there is a problem which is not really a problem because in any case you are going to be able to read data on your PC. uh so you you don't really care I mean about privacy at that level. Uh so yeah I think I think changing the

design is probably a better idea than trying to compute [snorts] large proof in hardware but just my opinion long opinion. >> Yeah just to add on I don't know if you asked if the chip needs postquantum but we we will do a new chip probably that will have more postquantum accelerators. Um that would be a next chip. So just if you have some input on it, you can come by the police. >> Okay. >> Still have anything to see? >> Yeah. If you have more questions, don't hesitate. We [clears throat] still have time.

>> Okay. >> Like seven minutes. >> So my question is um currently we use this as a like burner wallet or something. not much funds that we can use on them, right? And my question is um how much does it take, how much adoption is um we expect until we can actually use this as a real use case uh to to like um insert more funds in the wallet or what would you see um a clear path until we can actually use it?

Uh I think I think as a development board it's great to test applications. Uh then if you want to run a real product using that uh you can I would say that you can totally do it today. U because the chip doesn't have doesn't have a lot of u security certifications but it's already more secure than a lot of non-secure chip secure chips that are used in your common hard wallet. Uh if you want to have additional guarantees you could do what everybody else does. Uh so you could say okay I'm using this chip as my main uh holder for secrets and for everything and add secondary uh wellproven security chips as your fallback. Uh so you could have so if you look at the architecture of traor for

example they are using an STM32 which is not that secure for their main CPU and then they are delegating secrets um to an to an optiga I think and to yeah to an optica and to tropic to tropic square so to tropic 01 instead of using that you could have a bow chip as the main as the main CPU and then have another part of the secret on a tropic square and then you would have that architecture which is already much more secure than what exists in the market. Uh and I think the ultimately the architecture that you would like is to have only the bow chip. But so to be very honest today I will tell you wait a bit because something that's new and when you create a new chip there can only there can always be I mean some possible attacks.

Um but if you do that with an additional chip in my opinion it's something that is completely ready to go commercial today. Uh yeah, more questions. Thank you.

So when you run the audit, you get a couple of properties. Uh can you explain what does boot receipts mean? And I think the second one is anti-roll back. >> Uh so not exactly but I think you can uh look at the you can look at the code. Uh the important parts are the hash of the boot zero and boot one uh that you can verify. I'm not exactly sure I mean what the other properties mean but it's something that you can verify in in ZUS because it's open source. Yeah, >> I see.

anyone >> uh c can you also use uh any other MPC wallets for signing like something like Fireblocks? >> Uh you could yes you could even implement an MPC algorithm on that. So there is I mean um Crossbar has been doing this I mean on uh on this chip. So you could even do that if you want.

Yeah, it's pretty open. >> And also can you set up policies based on uh access or user user level >> on policies based on what? Sorry. >> So for example for on transaction like level if you want to set policies like you like you do it on a MPC wallet. >> Yeah. Yeah. I mean if you want you can do it on the if you want you can do it on the hardware wallet directly. I mean it's open source so you can really do whatever you want. I mean that's the idea. Uh no, if you want to do this uh I would probably rather do some kind of uh server in the middle. I mean that is going to manage the policies uh rather than having directly the the chip doing it. But you are pretty free to use any

architecture you want because you can really do whatever you want. I mean that uh that's the general idea. Okay, we're done. >> [music]