 Thanks for coming here. Thanks for being interested in password management solutions. I know that most of us have problems trying to remember passwords that are secure enough or are easy to remember. So this talk is going to be about that. So first, I'm going to present myself. My name is Mathieu Stéphane. I'm an Embedded Systems Engineer. I'm a former writer for Hackaday.com. I'm pretty sure that most of you know what Hackaday.com is. It's an electronics content gathering website. So basically, a website that explains the different projects of different open source enthusiasts. I also have my website. And I'm the founder of the Multipass open source project. So a quick show of hands. Who here knows about the multipass? It's not too bad. OK, cool. So hopefully, at the end of this talk, you will know a bit more about it. So what is the multipass? So multipass is an hardware approach of storing logins and passwords. So it's a dedicated device that will store for you all your credentials and also some small files. It is natively supported by Chrome and Firefox. We developed some extension. I will detail on this point later. And what is great is it is recognized as a keyboard. So basically, it's going to type your logins and passwords for you. So it will be compatible with any application on any operating system and even on smartphones. It is made of an aluminum case. It allows multiple users. And of course, it's open software and open hardware. And I'm French, you know? So internally, I will detail on this point later. It's basically a small box with a microcontroller, some flash memory to store your logins and passwords, which are encrypted, of course, some OLED screen and a clickable wheel for user interaction. The encryption key that is used to encrypt your logins and passwords is stored on a dedicated smart card. So basically, every user is uniquely identified using this smart card. So it's cool. And also, what does it look like, actually? So if you have this small device, every time you need to log in on the website, it's going to light up, asks you, do you want to log in on that website? Here, we implemented some knock detection, but you can also approve on the wheel itself. So this is native browser integration on Chrome or Firefox. But we also have an active way of entering logins and passwords. So basically, you use your multipass. You say, I want to log in on that website. Here, you can see it is connected to my phone using an USB on the go cable. So just browse through the login and password you want to enter. And you can approve the prompts on the device itself. So why this talk? This complete project has been made from a community located all over the globe. So the goal of this talk is to describe how we started from nothing, how we created a project from scratch, how 20 people collaborated together, how we could communicate, even though we were literally on the other side of the globe, how we created two devices from the ground up, and how we also created the different applications, the different software running on the computer itself, and also how we raised around 300k using Indiegogo or Kickstarter. So I'm going to start by the beginning, how we managed to get a lot of contributors, how we set up the project infrastructure. As I mentioned, at the time, I was a writer for Hackaday.com. So I figured, OK, let's try to create a device that everyone can work on, literally everyone from all over the globe. So I made a quick article, which is only 150 words, something like that, saying, OK, I want to create this device. Is there anyone else that wants to work on it? Luckily enough, Hackaday was kind enough to allow me to use the Hackaday name. Not exactly saying it is made by Hackaday, but it is developed on Hackaday. I had a few papers to sign also. So we made a call for contributors. We received, I think, 30, 40 applications. And of course, because we wanted to get the applicants interested in what they would be doing, the tasks were assigned of what they wanted to do, how much spare time they had, and their real-life expertise in that order. So as I mentioned, the contributors are located all over the globe. So this is a quick map of where they are. Of course, me, I'm located in Switzerland. Hardest guy to work with was located in New Zealand, which is 12 hours. So we had to go to bed quite late at this time. Anyway, so first step first, you have 30 contributors, how do you try to work together? So it took us, I think, one month and a half to agree on some ground rules. As you may know, everyone has their own way of creating code, tabs, versus faces, or if I want to put my bracket on the dedicated line. These are points that seem quite trivial, but when you have 30 contributors from all over the globe that have their own and unique way of doing stuff, it can't get messy. So we used some emails to try to find a consensus, to find the rules that everyone could agree on. We used GitHub for code versioning control. One of the core rules was to document all source code, mainly because if someone was to leave the project, we want to have some documentation of what he has done. So the guy that would pick up on his work would be able to continue working without spending I don't know how many days trying to understand what he has done. Everyone is working on a dedicated file of order, so we don't spend hours or days trying to merge files together, depending on how the code is made, of course. And as I mentioned, the coding convention was quite a friction point between the contributors. So how to talk with each other? We all have different availabilities. People are not paid. I'm not paid by this project. So basically, it all depends on our wives, children, to allow us on the project we want. So some contributors will not be able to work on the code for a week, two weeks. So how do we keep a trace of what has been done? So we chose to use Google Groups, mainly because it was easy. All the traces related to other discussions, related to the development, can be found there. We didn't want to use Skype for any direct conversation being, mainly because it would not leave a trace and it would lead to developers being out of the loop. So as much as possible, use mailing list or sometimes IRC. The main challenge, as you can guess, is to keep the momentum going. You have a project. People are working on their own time in different places. So you never realize what you have done so far, where the project is at. You don't know, OK, where are we now? What are we going to do? And you might lose motivation. So every time, every, I think, one or two weeks, we said, OK, this guy has done that. The project is close to the end. We are close to having a password manager that is working well. So as I mentioned, keeping everyone involved. This project is open source, and the name itself has not been chosen by me. We kept the Hackaday community involved at all times. So every month, also, we were saying, OK, for example, we have done the hardware case there. What do you think of it? We still don't have a name for the project itself. So several readers suggested some names. You can see Spark, Pesky, Multipass. And since Multipass was a good success, we had 33% in a vote we organized on Hackaday itself. So this way, we could keep the readers involved and, more importantly, get their opinions on what the project was at and what we should do and what we shouldn't do. I was saying it's hard to know where the project is at. So we used Trello before it was bought by Atlassian information. So we used Trello to keep a nice view of who is doing what and what is the current state. So it's a very nice way to see if this task is done, if you are behind on some, for example, the graphics and all that. So you can see, for example, here, different tasks that were assigned to different people and what are the tasks that needs to be done, which ones are done. It's a nice way to see where the project is at in a quick glance. So everyone is working for free. How do you try to have some products commercialized and ready to go to Indigo or Kickstarter? Whether you want it or not, you have deadlines. You have an objective, which is, for example, to go on Kickstarter in two months or three months. And of course, if there is one part of the firmware that is late, you want to talk with that guy, see what he needs, what can be done, so you can arrive at the firmware version one as soon as possible. So we encouraged the different developers to try to find solutions by themselves. We encouraged innovation. As I said in the beginning, the tasks were assigned on what they wanted to do, so motivation usually was not a problem, but in some cases, life gets in the way. I don't know, someone had a baby, so we had to replace that guy. So anyway, we tried to motivate people by showing their work to the community. Estimated time of arrival for tasks is always a tricky subject. You want to try to see with the contributor what he needs, what needs to be done, and how you can help. And sometimes, all the contributors will try to help them as well, so it can be spontaneous. So now we've talked about the community. I'm going to dig into the hardware. I will start from the hardware, firmware, and software. So at a very low level, this is what the multi-pass looks like. This was the very first prototype. Hand assembled, I actually soldered, I think 10 or 15 prototypes myself, that were directly shipped to the contributors. It does not look pretty, but at least you can start coding on it. Cases, I mentioned every major decision was made by the Hackerday readership, so we asked for design ideas. We had these different designs, and we organized a new vote. For the new vote, it was this final look that was chosen. It was in December 2014. We went on Indiegogo. We raised, I think, 130K in December. Then, because the multi-pass project started to have some success, people were starting to warm up to the idea of having a dedicated device for storing their logins and passwords. Also, mainly because last pass was compromised, or there are always news that try to promote all way of storing logins and passwords. So, after the multi-pass standard, multi-pass original, we chose to continue on a smaller version of the multi-pass, which could be easily carried inside your pocket, something that is easier to carry around, which is cheaper, sturdier. The first version was also and assembled by myself. I think I soldered 20 prototypes, shipped to testers, contributors. We received some feedback, and finally, we went for an aluminum case, which is the final look, and wire aluminum, so we could make sure that it would be tamper-evident. So, this is me trying to test the robustness of the adhesive that keeps the case together. So, this is me standing up on the case, trying to tear it apart. I didn't succeed. So, just to make sure that, actually, our device is robust enough, so someone opening the device, implementing a sniffer, whatever, would be evident. Of course, I've done it myself, but other people wanted to make sure for themselves, so this is a disassembly test by someone, a friend of someone who is in the audience. I wanted to make sure that, actually, his device could not be opened without him noticing. As you can imagine, it's quite evident that it has been opened. Then, yeah, I'm gonna put a few flu slides about organizing the mass production. So, you have a hardware. How are you going to produce 1,000 of them, 4,000 of them? So, I went to China just to meet the different guys I met on the internet to produce the multipaths. Finding a manufacturer can be quite tricky. This particular manufacturer, it's a funny story. Basically, I ordered some power supply on the internet, plugged it into my power socket and the complete fuse of the building blew up. I contacted the guy and then I learned that actually he offered manufacturing services and this is the guy. And actually, the multipaths are working well, so it was just the exception. But it's one way of getting in touch with assemblers. The case manufacturer, so CNC shops. So, I mentioned we have aluminum casing, so you want to have it manufactured. This was an even stupider choice. I looked on Alibaba for CNC shops, received several codes, and I took the cheaper one. Like, really the cheapest. I figured, okay, at least I will have some prototypes and let's see if they are reliable. Turns out, he is extremely reliable. It's one of the guys in China next to Shenzhen that basically I can stand the design, I can trust him to have it done. Communication is always a tricky subject. I speak a little Chinese, but not too much. So, I kind of cheated. I have a Chinese wife that was doing the translation job. So, communication, how are you going to teach your manufacturer how to assemble the multipass? It's a security device, so this can be quite tricky. We have tight entrances for the case. You have functional tests. So, it turns out, for me, the most easy way to get him to do stuff is to make a YouTube video. As stupid as it sounds, basically I have a camera on top of me filming what I'm doing. So, for example, here it's a functional testing of the multipass. I say, okay, connect the multipass, rend this script, then you will have a label which is printed out. It means that the device is ready to be assembled. The advantage of that is that the assembler can look at the video, I don't know, four or five times trying to see what he didn't understand, and then my wife would call him to make sure he understood. So, of course, quality control is always tricky. So, you want to make a first prototype run of 50, 100 units, and so you can make sure that the assembler can do his job properly. As you can see, there is a few marks of adhesive there. So, this is actually not a big photo piece. Basically, forgot to let the glue dry for 24 hours. So, the more prototypes you make, the more data you will have on what mistakes can be done, things you never thought would be possible because you can't see everything going anyway. So, at least make 10, 20 prototypes run, send it to testers, send it to multipass enthusiasts so you can get feedback as much as quickly as possible so you can add some features. For example, on the multipass itself, I guess 30 or 40% of the features were suggested by the testers themselves. You are, I'm a geek, I can't think of everything, I can't think of what is really needed by most people. So, actually, I make prototypes run, send it all there, and then I get ideas. So, firmware, let's start with the tricky part. It's a security device. All the passwords are encrypted using AES. So, even if you are creating a security device, we want to create all the source code ourselves, but there is one exception, which is the encryption routines. So, for that, we chose to some library, which is called AVR Cryptolib, but we checked it against necessary vector sets. So, basically, we used the code, implemented a few securities, so we don't have side-channel attacks, and we checked it against some vector sets to make sure that the encryption routines lead to the good output. So, this is the only part of the code we did not create ourselves, but at least we checked it. As I mentioned, we have encrypted storage. Inside the multi-pass, you have a flash that will store your logins, passwords, small files. We have two types of data, credentials and encrypted blobs. So, if you have a quick text file you want to store, also SSH keys, also this is possible on our newer application. We have some sorted linked list data structures. So, basically, when you scroll through your credentials, they are alphabetically sorted, which makes sense. And the encryption key for all your credentials are stored into a dedicated smart card. Talking about smart cards, how do you find a smart card? A smart card is extremely hard to find a smart card that can do what you want because manufacturers are not interested in selling 100,000 or 10,000 smart cards to some people they don't know, especially open source enthusiasts. So, it took me, I think, one month or two months trying to find a smart card that could fit the bill. So, basically, what we need is just a read-protected memory that could store your encryption key. So, we found some smart card on the internet. It is a net mail one. I think it is already 10 years old, something like that. But, at least, it uses a 16-bit PIN code. So, from 00 to FFF, we chose to offer the possibility to enter, I don't know, some DAD PIN codes so you can go crazy for your PIN code. It is permanently locked after four incorrect PINs. So, at least if someone gets a hold of your multi-pass device or smart card, you can try four times. So, good luck. And, more importantly, it's very cheap, less than a dollar. I think less than 50 cents now. So, quite easy to source and to offer to different customers. Random number generation. So, you have an encryption key. You want this encryption key to be completely random. Of course, there is also, when you store a password, you want to add some padding to make sure that you are not encrypting the same encryption function does not lead to the same result, even if we are using CTR mode inside the AES routine. So, what you are using for a random number generation, also used for password generation, it is based on the jitter between the watchdog timer, which is basically an RCLC leader, and the crystal. So, this only generates eight bytes per second. It's not great. It's actually perfect for what we need because you are going to generate a password once every 10 minutes, whatever. So, it's actually quite nice for what we need. Eight bytes a second. USB. As I said, we offer native integration in the browser itself. You go to websites, the multi-pass lights up, and you approve the request. This is done through a HID proprietary channel, which is just a fancy way of saying that I'm sending 64 bytes every millisecond. And you also have manual password recall where you go on the device itself, go to, I don't know, the login github.com, and then you press, and the login and password is directly pressed for you. So, basically the multi-pass simulates key presses. So, this is done through the HID Keyboard channel. So, it's a composite device. So, keyboards are supported by all computers, smartphones, tablets out there. But the problem is that, I don't know if you know, if you have a keyboard, you press the A, B, C key. The keyboard is not sending A to your computer. It is saying to the computer, the user has pressed a key whose unique code is 52. Then your computer is going to match this number to A or B, depending on your local. So, which local, I think is the correct word. So, this means that you need to generate a lookup table for every keyboard out there. This took quite a while. We have a few Python scripts on our repository, and one of them is actually to do a brute force on all the key codes to see which key code maps to which ASCII character. This was a painful process, but it worked, at least. Graphics library, we didn't use any library out there because we wanted some very quick refresh time on the display itself. For the multi-pass original, we use run length encoding compressions to make sure that the memory dedicated to the graphics is as small and used in an optimal manner. We have many different scripts to convert bitmaps, fonts into binary blobs that are stored inside the external flash of the multi-pass. And this particular flash and your firmware can be updated securely. So, this means that we had to... This is the part I created, actually. We have a bootloader that allows signed firmware updates. We are using AES to generate the hashes. So, for every multi-pass device out there, there are several unique elements stored inside their memory. We have a unique AES key, which is used to sign the firmware updates. There is a unique AES key for hash generation. So, basically, you connect your multi-pass, you insert your card, it's going to display a hash. So, if the hash is the same as you have seen before, you know that your device has not been compromised. We also have some re-protected universal identifier. This is used to make sure that your device has not been tempered with during shipping. So, if you want more details about that, I can answer during the Q&A. So, unique sign-in keys for every multi-pass out there means generating a unique firmware to be flashed into the device for the mass production. So, you never trust your assembler. So, what we have done is created our own mass programming rig. It looks a bit crude, but it works perfectly. So, basically, you have nine different sockets on which you put your microcontroller. We have also a complete set of scripts that we generate a unique X file to be flashed on the microcontroller and program a unique serial number. So, all the programming of the microcontrollers is done by ourselves. We didn't want to trust the other assembler, even if we have been working within for a couple of years. So, we want to make sure that the critical parts are programmed by us. So, this is why this cute programming rig was made. Now, to the multi-pass software. So, I've started very low. I'm going to talk about what is running on the computer, for example, to implement native browser integration. So, first, we developed Chrome app and extension. Why we chose to go this way is that it's already cross-platform compatible. The installation process is really as simple as two clicks. So, if you use Chrome, if we also support Firefox, I will talk about that later. If you use Chrome, you basically go to our web page, click on two links. It will install an extension that is used to detect whenever you need to log in. So, basically, on the web page you visit. And it will also install an application. The application is here to make the interface between the extension and the multi-pass hardware. So, every time the extension detects a login form, it will ask the app to query the multi-pass for the login for this given website. So, why Chrome apps? They natively support USB, HID. So, you don't need to install a program. You don't need to add separate drivers. It's as simple as connect the multi-pass, click twice, and it works. Of course, for Linux users, you will need a Udev rule, but there is nothing we can do about that. So, this is the management interface. Multi-pass app, as I mentioned, you want to see when your credentials were last used, what you have now, what you want to, what is the password for this given website if you want to change it. So, this is some nice management interface. Interestingly enough, this is the only bit of the multi-pass ecosystem that was not made by your contributor. Apparently, it's very hard to find JavaScript developers that want to do that for free. Anyway, so, if you're a JavaScript developer and want to work on it, contact me. But, yeah, so we found several freelancers. Working with freelancers is always interesting. You never know what motivates him, so it's a bit harder to manage a freelancer than a contributor, but anyway, at the end, we have a nice application that is working like we want. We also have a Python tool. So, in case you're not into Chrome apps or extensions, you can recall your logins and password directly using a command-laying tool based on Python. You can also use small file storage recall directly stored on the device itself. What is nice is that it can interface with multiple applications. One application can call this utility to recall your login and password. So, quite convenient if you are developing your own app and want to query your credentials on the multi-pass itself. And also, we are currently working on a cross-platform tool. So, the main reason for that is that Chrome announced in 2018 that it is going to drop the Chrome apps. So, we are currently actively working on the C++ NQT tool, which is called Multicute. His creator is here. First time I meet him, by the way. So, basically, he's here to do the job of the Chrome app. Interface between the multi-pass hardware, Chrome Safari Firefox. For example, I'm using it with Firefox right now. He also created using Go, an SSH agent. So, every time you need to log into a server using your SSH key, you basically have this SSH agent running that will query your SSH key from the multi-pass. And as the Chrome app, we have a management interface that we're also working on to provide smart database synchronizations across your multi-pass units. And also a command-line interface because we are geeks, after all. And so, what's next? As I mentioned, we only started working, I think, six months ago on this new tool. If you're a C++ QT developer and want to work on something security-related, contact me, I have actually seven units right now to give up for free if you want to have fun at our ecosystem. The file storage functionality is not yet present. It's present command-line based on multi-QT, but we would like to have a nice graphical user interface to store your files and recall them. And we also want to create two-factor only firmware for the multi-pass. So, as I mentioned, multi-pass is only made to store your logins and passwords, but we not implement second-factor authentication on the main firmware. The main reason is that you would have one device for logins, passwords, and two-factor authentication-related functionalities, which doesn't really make sense. But so, we are currently working. We would like to work on a second-factor authentication firmware. And if you have questions, please go on. I realize I've been a bit fast. So, just a question on the AIS keys. Are you, as if I buy a device, am I entitled to flash my AIS keys? Closer to the microphone line. Sorry, am I allowed to update my own AIS keys on the device? If I buy one, how do you manage the AIS security chain for getting you updates for firmware on my device? OK, so you're asking how the firmware is updated using the boot loader. Are you asking about how? Right. So, I can go into details about that. So, to update, the firmware is quite simple. On our application, it's as simple as selecting a file that will be temporarily stored into our external flash. Then the device will reboot. It will look at the flash, compute a hash, a given hash on this complete file. If the hash is correct, then it is going to update the firmware itself. So, it is in a two-pass process. First, the first pass is going to check the checksum. Then, it is going to do a second pass. Basically, it's going to see each block, flash it to the firmware, but still set a given Boolean that will prevent the device from booting. So, we are deliberately breaking the device until it is completely flashed, and the hash has been checked again. Thank you very much. Hi, thanks for a great talk. I was wondering, what have you done to stop the hardware manufacturers putting backdoors into your devices? So, you've got all these random people involved in your manufacturing chain. How can you make sure that the device is secure? If I'm going to store all my passwords on this, it has to be absolutely secure. So, the security of our device relies on its physical integrity. So, we know for sure because of the firmware that we have flashed that the firmware has not been tampered with. This is a guarantee we provide. So, the only way, the only attack way that could be done during the manufacturing process is to implement a sneaker in the hardware itself. But this, basically because most of the units will go through Switzerland, where I live, and I will desert some of them. So, actually this could be easily detected. And even if there was a sneaker, the case is made of aluminum. So, it might be a bit tricky to, it's not a perfect Faraday cage, of course, but at least it's something. And the torrents are quite tight. So, the sneaker you would have to put there would be quite small. Great work. Can you tell us a bit about certification? I noticed various marks on the back indicating that it has passed some certification like CE. Sorry, I didn't get that. Can you tell us a bit about the certification of the device? I noticed there was a CE mark and so on on the back. OK, yeah. This, I didn't talk about so getting CE, FCC certification. Contrary to most Kickstarter companies out there, we have done it before the Kickstarter. Once we were sure that the hardware was final, I know a couple of certification centers in Shenzhen directly. You would think that Chinese certification centers are not reliable and actually they're not joking at all. So, basically, you send all your schematics, layout, a quick description of the project, a quick getting started guide. So, the manufacturing certification center can try to make sure that the device is working and will characterize the RF emissions. Interestingly enough, they need to take pictures of the device and they need to take pictures of inside the device. So, this means that they had to tear open the case. I didn't include the picture in the presentation, but they also tried to open the case and it was not pretty at all. Yeah. Thank you. Have you considered making a Bluetooth version in what are security implications of that? Yeah, so, this is a bit of a tricky subject. So, we want this device to, it's a hardware device to store passwords. The problem with Bluetooth and any protocol is that you would need to insert a lithium-ion battery and then you will have to add the transceivers. You have additional certifications, you need to pass. Shipping products with lithium batteries is not easy. It's a bit of a pain. So, we preferred designing a device which is as simple as possible to reduce the cost and but we are actually thinking of making a upgraded version of the multipath with different protocols. But then Bluetooth security and all that, then you start to have, you would like to implement some secure layer on top of Bluetooth depending on if you trust that first action. So, it's a bit of a tricky subject. At least with USB, you make sure that it stays in the wire and using the air, yes, depends on the people. Hello. Yes, thank you. That's a very interesting product. I really like the idea. Question is, what steps have you taken to protect it from attacks by the host? Attack by what? The host, the computer you plug it into. Yeah, so this is the part I mentioned on the talk that I'm digging to. So, the device itself has a universal identifier. This identifier can only be requested by entering a password on our app. So, basically say, okay, give me the unique identifier. This is the password. So, you can make sure that the identifier is a correct one because what I didn't mention, I should have mentioned, is that any tampering with the firmware will lead to a completely erased device. This is a protection mechanism by the microcontroller itself. So, if someone was to tamper with the firmware, all your identifiers would be erased. So, this is also another reason why we need to know who purchased what. So, when you receive your device, you contact me directly. I can make sure I can identify you using, I guess, your postal address or some elements that could not be retraced. So, I can make sure that I'm sending you the correct password. Then you can tell me, okay, this is the identifier that I have. Is it the correct one? So, I can tell you yes. So, you can make sure the firmware itself has not been tampered with. Yes, but what about things like buffer overflows, power attacks, things like that? This is the perfect thing, actually. So, buffer overflows, so I didn't mention the name of the microcontroller. The microcontroller we are using is a simple 8-bit, 16-MHz microcontroller from Atmel, and it has an Harvard architecture. So, buffer overflows and all that are not going to lead to executed code. Thank you. Thanks for the great talk. Thanks. You said that you are using a smart card with a re-protected memory. So, do you use encryption and decryption on the smart card or are you extracting the key when correct pin is present? We are extracting the card when we are extracting the encryption key once the card is unlocked. So, if you are saying that someone that could de-cap the smart card and with a microscope look at the bit, yes, you would be able to get your encryption key, but not everyone has, I don't know, how much money to de-cap smart cards. Makes sense. Thank you. What kind of yield do you get in manufacturing and have you had any defects or chips replaced without your knowledge? So, this is why I mentioned that you need to have as many prototypes run as possible to make sure that all the potential mistakes from the mass production run can be anticipated. So, for example, the mass production run of the multipass mini is ongoing, but I think right now if you just take the mistakes from the assembler, we are at 94%. But there is an additional 15% because of small error that have means you have seen the programming rig. So, I'm making some checks to make sure that the firmware is correctly flashed, but apparently there are some silent errors we are using AVRdude to program the microcontrollers. So, on 10 units of the one of the units we received, or I think a bit more, 12 units, the APROM was not programmed. So, it's quite interesting because during the functional test, the assembly is going to do all the tests, the screen lights up, the label is printed, everything is all right. But when we received the device, we connected the device and nothing was lighting up, nothing was happening. So, I spent I think three days trying to see what was the problem and it was an APROM. So, they will be still unknowns that will happen. So, unfortunately this happened because we changed the process from programming the microcontrollers. From once you've made two or three prototypes, it will be all right because your quality control document will be as thorough as possible and it should be all right. Have you had any components replaced without your knowledge like for cheaper components? So, you're asking if it's possible to find cheaper components. If your manufacturer replaced components during the manufacturing process for ones that they found cheaper, for example. It's possible for the assembler to replace some 40 components. For example, in the 10, 12 units I mentioned, this reprogramming will consist in removing two components, putting on a mass programming ring custom made. So, it's some additional rig we need to make, but at least we don't need to disorder and resolder everything. The manufacturer can do that. On prototype brands, it will not be a problem. If you see a mistake in the layout, something at the last minute, he will be able to do that. He will not be super happy, but he will do it. Mass production, forget about it. It's just not possible. He will not do that on several thousand components, especially because the manufacturing process is completely different. Thank you. You're welcome. Hi. Did you run any security audit from an independent security expert? So, you're asking if our code source was checked by external parties. Yes, it has been checked by three or four different organisms, all the time static analysis. So, we have the reports online, if you're interested to see what the output is. We passed all three checks. You might have seen that some people working in some national agencies are using the multi-pass. They were the first one to make sure that the code was not... We didn't hide any Easter bags. But anyway, what I think they appreciate quite well is that no one is paid. We do this for fun. We don't have any ulterior motive. We just do this to try to promote a nice way to store login and password. We don't have the best way... It's not the perfect way of storing logins and passwords, but it's still better than software-based password keepers where you will have your main password and your database inside your computer memory. And at the hardware level, did someone check the design or...? So, there is a risk talk, the open source processor talk, I think in two hours, that would be quite interesting. Unfortunately, we are forced to trust the microcontroller manufacturer. We accept the risk five processor. Unfortunately, you have to trust the silicon. There's no way around that. OK, thank you. How do you handle backup and restores? OK, yes, I should have mentioned it as well. So, it is possible... The smart card that stores your encryption key can be cloned on the device itself. So, you have your device, you go into the settings menu, say, OK, I want to clone my smart card and set your smart card, remove it, put a blank one, it will be cloned. So, this is a way to making clones of your smart card. The database itself can be exported to the computer. Anyway, the database is encrypted, so we don't care if it gets exported anywhere. You can try to encrypt it, it will not work. So, if you use your card, luckily you will have made a clone before. And if you lose your device, either you make a new one from the different files we have on GitHub, or you purchase a new one from us and you restore your database. Thank you. All right, seems very good. Perfect, thank you very much.