The Making of a Secure Open Source Password Keeper
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Stephan, Mathieu
The Mooltipass Offline Password Keeper project was started three years ago bya small community to provide a safe and offline way of storing credentials. Since then, about 50 individuals from around the globe have contributed to theproject, bringing two models of the Mooltipass device to market. Mooltipass devices are currently used by thousands of people, several majorcompanies, and government agencies. This talk will describe the Mooltipasshardware, firmware and software architectures with a focus on what it took tomove from idea to commercial product, while having all the development andproduction files publicly available on GitHub. While writing for Hack-a-Day, in December 2013 project creator Mathieu Stephanhad the crazy idea of creating an open hardware device using a team spread allover the globe. He posted a call for developers on hackaday.com, whichresulted in a team of 20 individuals. Over the course of three years, using avariety of free (Trello, Google groups, IRC) and open source (KiCad, Gimp,GCC) tools the Mooltipass team developed a complete solution composed of: * Firmware for the devices (AES encryption, storage management, graphics, random number generation, smartcard management) * Two models of physical device each composed of a PCB, case, screen, usb and smartcard connectors * Several open source software solutions to provide computer integration with the device, depending on the users' preferences: a cross platform daemon (Windows, Linux, Mac) [moolticute], a python management tool [mooltipy], a chrome and firefox extension, and a chrome app to provide native integration with websites Having a complete, unremunerated teamworking on the Mooltipass project duringtheir spare time created interesting management challenges, particularly withrespect to establishing and enforcing coding rules and commenting practices.The first crowdfunding campaign successfully raised $125k in December 2014,which was more than sufficient to start the ball rolling. The secondcrowdfunding campgin for the Mooltipass Mini raised $168k last October.
 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 quick show of hands. Who here knows about the multipass? It's not too bad. 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. That is aluminum. 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? It's a small device. Every time you need to log in on the website, it's going to light up. It asks you, do you want to log in on that website? Here, we have 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 multi-pass. 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 it 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 the 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, okay, let's try to create a device that everyone can work on. Everyone, literally everyone from all over the globe. So I created, I made a quick article, which is only 150 words, something like that, saying, okay, 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, we assigned 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. The 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 lay it up, 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's, 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, all the discussions related to the development can be found there. We didn't want to use Skype for any direct conversation, 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 lists, 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, okay, 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, okay, 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, okay, 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 Atlation, information. So we used Trello to keep an eye on who is doing what and what is the current state. And we had a 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. So 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 final, 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 a 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 a contributor what he needs, what needs to be done, and how you can help. And sometimes other contributors will try to help them as well. 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, and has assembled. I actually sold 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 Hackaday 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, 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 sold 20 prototypes shipped to testers, contributors. We received some feedback, and finally, we went for an aluminum case, which is the final look. And white 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 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 going to 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 multipass 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 multipass are working well, so it was just the exception. But it's one way of getting in touch with customers. The case manufacturer, so CNC shops, so I mentioned we have aluminum casing, so you want to have it manufactured. This was an even stupid choice. I look on Alibaba for CNC shops, received several quotes, 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. He is one of the guys in China next to Shenzhen, that basically I can send a 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 tolerances 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 is a functional testing of the multipass. I say, okay, connect the multipass, rend the 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 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, I 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 a geek, I can't think of everything, I can't think of what is really needed by most people, so I make prototypes run, send it all there, and then I get ideas. So firmware, let's start with the tricky part. It's the 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 routine. 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 multipass, you have a flash that will store your logins, passwords, small files. We have two types of data, credentials, 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 cards on the Internet. It is an HTML one. I think it is already 10 years old, something like that. But at least it uses 16-bits pin codes from 00 to FFF. We chose to offer the possibility to enter some DAD pin codes, so you can go crazy for your pin code. It is permanently locked after four incorrect pins. 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 is 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. It does not lead to the same result, even if we are using CTR mode inside the AES routine. So what you are using for 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 8 bytes per second. It is not great. It is actually perfect for what we need, because you are going to generate a password once every 10 minutes, whatever. So it is actually quite nice for what we need. 8 bytes a second. USB. As I said, we offer native integration in the browser itself. You go to a website, the multi-pass lights up, and you approve the request. This is done through an HID proprietary channel, which is just a fancy way of saying that I am sending 64 bytes every millisecond. And you also have manual password recall where you go on the device itself, go to 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 is a composite device. So keyboards are supported by all computer, 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 used run length encoding compressions to make sure that the memory dedicated to the graphics is 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 we had to, this is the part that 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 read 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 assembly, even if we have been working with him 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, 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 if you 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 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. So this 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 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 passwords 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 the 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 and SSH agents. 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 hope you guys have been a bit fast. Thank you. So just a question on the AIS keys. If I buy a device, am I entitled to flash my AIS keys? Can you speak closer to the microphone? 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? Okay, so you're asking how the firmware is updated using the boot loader. Are you asking about how? So I can go into details about that. So to update a 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 a firmware itself. So it is in a two-pass process. First, the first pass is going to check the check-stand. 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. So... 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 are flashed, that the firmware has not been tempered 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 far-reday 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. Okay, yeah. This... I didn't talk about so getting CE, CE 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, layouts, a quick description of the project, a quick getting started guide. So the manufacturing, the 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 big 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, 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. Yes, so this is the part I mentioned on the talk that I'm digging into. 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 the correct one, because what I didn't mention, I should have mentioned, is that any tampering with a firmware will lead to a completely erased device. This is a protection mechanism, but 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 a 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 the 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 decap 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 decap 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 multi-pass 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 a small error that 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, I think a bit more, 12 units, the AEPROM 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. I spent, I think, three days trying to see what was the problem and it was an AEPROM. So they will be still unknowns that will happen. So unfortunately this happened because we changed the process of programming the microcontrollers. But once you have 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 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 faulty 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 with some additional rig we need to make. But at least we don't need to disorder and we solder everything. The manufacturer can do that. On prototype friends, 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? 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. At the hardware level, did someone check the design? 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 5 processor. Unfortunately, you have to trust the silicon. There's no way around that. Okay, thank you. How do you handle backup and restores? Okay, 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, okay, 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. Seems very good. Perfect. Thank you very much.
 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 quick show of hands.  Who here knows about the multipass?  It's not too bad.  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.  That is aluminum.  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?  It's a small device.  Every time you need to log in on the website, it's going to light up.  It asks you, do you want to log in on that website?  Here, we have 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 multi-pass.  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 it 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 the 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, okay, let's try to create a device that everyone can work on.  Everyone, literally everyone from all over the globe.  So I created, I made a quick article, which is only 150 words, something like that,  saying, okay, 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,  we assigned 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.  The 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 lay it up,  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's, 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, all the discussions related to the development  can be found there.  We didn't want to use Skype for any direct conversation,  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 lists, 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, okay, 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, okay, 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, okay,  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 Atlation,  information.  So we used Trello to keep an eye on who is doing what  and what is the current state.  And we had a 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.  So 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 final,  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 a 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 a contributor what he needs,  what needs to be done, and how you can help.  And sometimes other contributors will try to help them as well.  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, and has assembled.  I actually sold 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 Hackaday 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,  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 sold 20 prototypes shipped to testers, contributors.  We received some feedback, and finally, we went for an aluminum case,  which is the final look.  And white 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 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 going to 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 multipass 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 multipass are working well, so it was just the exception.  But it's one way of getting in touch with customers.  The case manufacturer, so CNC shops, so I mentioned we have aluminum casing,  so you want to have it manufactured.  This was an even stupid choice.  I look on Alibaba for CNC shops, received several quotes, 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.  He is one of the guys in China next to Shenzhen, that basically I can send a 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 tolerances 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 is a functional testing of the multipass.  I say, okay, connect the multipass, rend the 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 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, I 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 a geek, I can't think of everything, I can't think of what is really needed by most people,  so I make prototypes run, send it all there, and then I get ideas.  So firmware, let's start with the tricky part.  It's the 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 routine.  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 multipass, you have a flash that will store your logins, passwords, small files.  We have two types of data, credentials, 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 cards on the Internet.  It is an HTML one. I think it is already 10 years old, something like that.  But at least it uses 16-bits pin codes from 00 to FFF.  We chose to offer the possibility to enter some DAD pin codes, so you can go crazy for your pin code.  It is permanently locked after four incorrect pins.  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 is 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.  It does not lead to the same result, even if we are using CTR mode inside the AES routine.  So what you are using for 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 8 bytes per second. It is not great.  It is actually perfect for what we need, because you are going to generate a password once every 10 minutes,  whatever. So it is actually quite nice for what we need.  8 bytes a second.  USB. As I said, we offer native integration in the browser itself.  You go to a website, the multi-pass lights up, and you approve the request.  This is done through an HID proprietary channel, which is just a fancy way of saying that I am sending 64 bytes every millisecond.  And you also have manual password recall where you go on the device itself,  go to 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 is a composite device.  So keyboards are supported by all computer, 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 used run length encoding compressions to make sure that the memory dedicated to the graphics is 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 we had to, this is the part that 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 read 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 assembly, even if we have been working with him 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, 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 if you 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 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.  So this 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 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 passwords  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 the 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 and SSH agents.  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 hope you guys have been a bit fast.  Thank you.  So just a question on the AIS keys.  If I buy a device, am I entitled to flash my AIS keys?  Can you speak closer to the microphone?  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?  Okay, so you're asking how the firmware is updated using the boot loader.  Are you asking about how?  So I can go into details about that.  So to update a 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 a firmware itself.  So it is in a two-pass process.  First, the first pass is going to check the check-stand.  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.  So...  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 are flashed,  that the firmware has not been tempered 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 far-reday 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.  Okay, yeah. This... I didn't talk about so getting CE,  CE 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, layouts,  a quick description of the project, a quick getting started guide.  So the manufacturing, the 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 big 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, 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.  Yes, so this is the part I mentioned on the talk that I'm digging into.  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 the correct one,  because what I didn't mention, I should have mentioned,  is that any tampering with a firmware will lead to a completely erased device.  This is a protection mechanism, but 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 a 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 the 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 decap 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 decap 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 multi-pass 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 a small error that 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, I think a bit more, 12 units,  the AEPROM 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.  I spent, I think, three days trying to see what was the problem and it was an AEPROM.  So they will be still unknowns that will happen.  So unfortunately this happened because we changed the process of programming the microcontrollers.  But once you have 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 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 faulty 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 with some additional rig we need to make.  But at least we don't need to disorder and we solder everything.  The manufacturer can do that.  On prototype friends, 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?  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.  At the hardware level, did someone check the design?  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 5 processor.  Unfortunately, you have to trust the silicon.  There's no way around that.  Okay, thank you.  How do you handle backup and restores?  Okay, 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, okay, 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.  Seems very good.  Perfect. Thank you very much.
The_Making_of_a_Secure_Open_Source_Password_Keeper_From_the_Electronics_to_the_0_131.png The_Making_of_a_Secure_Open_Source_Password_Keeper_From_the_Electronics_to_the_132_431.png The_Making_of_a_Secure_Open_Source_Password_Keeper_From_the_Electronics_to_the_432_1451.png The_Making_of_a_Secure_Open_Source_Password_Keeper_From_the_Electronics_to_the_1452_2651.png The_Making_of_a_Secure_Open_Source_Password_Keeper_From_the_Electronics_to_the_2652_3359.png The_Making_of_a_Secure_Open_Source_Password_Keeper_From_the_Electronics_to_the_3360_3935.png The_Making_of_a_Secure_Open_Source_Password_Keeper_From_the_Electronics_to_the_3936_4487.png The_Making_of_a_Secure_Open_Source_Password_Keeper_From_the_Electronics_to_the_4488_7055.png The_Making_of_a_Secure_Open_Source_Password_Keeper_From_the_Electronics_to_the_7056_7511.png The_Making_of_a_Secure_Open_Source_Password_Keeper_From_the_Electronics_to_the_7512_11471.png The_Making_of_a_Secure_Open_Source_Password_Keeper_From_the_Electronics_to_the_11472_13571.png The_Making_of_a_Secure_Open_Source_Password_Keeper_From_the_Electronics_to_the_13572_15635.png The_Making_of_a_Secure_Open_Source_Password_Keeper_From_the_Electronics_to_the_15636_15851.png The_Making_of_a_Secure_Open_Source_Password_Keeper_From_the_Electronics_to_the_15852_16223.png The_Making_of_a_Secure_Open_Source_Password_Keeper_From_the_Electronics_to_the_16224_18911.png The_Making_of_a_Secure_Open_Source_Password_Keeper_From_the_Electronics_to_the_18912_24503.png The_Making_of_a_Secure_Open_Source_Password_Keeper_From_the_Electronics_to_the_24504_24551.png The_Making_of_a_Secure_Open_Source_Password_Keeper_From_the_Electronics_to_the_24552_29627.png The_Making_of_a_Secure_Open_Source_Password_Keeper_From_the_Electronics_to_the_29628_31943.png The_Making_of_a_Secure_Open_Source_Password_Keeper_From_the_Electronics_to_the_31944_32855.png The_Making_of_a_Secure_Open_Source_Password_Keeper_From_the_Electronics_to_the_32856_34463.png The_Making_of_a_Secure_Open_Source_Password_Keeper_From_the_Electronics_to_the_34464_35447.png The_Making_of_a_Secure_Open_Source_Password_Keeper_From_the_Electronics_to_the_35448_35783.png The_Making_of_a_Secure_Open_Source_Password_Keeper_From_the_Electronics_to_the_35784_39611.png The_Making_of_a_Secure_Open_Source_Password_Keeper_From_the_Electronics_to_the_39612_41351.png The_Making_of_a_Secure_Open_Source_Password_Keeper_From_the_Electronics_to_the_41352_42959.png The_Making_of_a_Secure_Open_Source_Password_Keeper_From_the_Electronics_to_the_42960_50471.png The_Making_of_a_Secure_Open_Source_Password_Keeper_From_the_Electronics_to_the_50472_50687.png The_Making_of_a_Secure_Open_Source_Password_Keeper_From_the_Electronics_to_the_50688_54275.png The_Making_of_a_Secure_Open_Source_Password_Keeper_From_the_Electronics_to_the_54276_55295.png The_Making_of_a_Secure_Open_Source_Password_Keeper_From_the_Electronics_to_the_55296_55427.png The_Making_of_a_Secure_Open_Source_Password_Keeper_From_the_Electronics_to_the_55428_56963.png The_Making_of_a_Secure_Open_Source_Password_Keeper_From_the_Electronics_to_the_56964_57347.png The_Making_of_a_Secure_Open_Source_Password_Keeper_From_the_Electronics_to_the_57348_58631.png The_Making_of_a_Secure_Open_Source_Password_Keeper_From_the_Electronics_to_the_58632_60419.png The_Making_of_a_Secure_Open_Source_Password_Keeper_From_the_Electronics_to_the_60420_61319.png The_Making_of_a_Secure_Open_Source_Password_Keeper_From_the_Electronics_to_the_61320_61823.png The_Making_of_a_Secure_Open_Source_Password_Keeper_From_the_Electronics_to_the_61824_62087.png The_Making_of_a_Secure_Open_Source_Password_Keeper_From_the_Electronics_to_the_62088_62855.png The_Making_of_a_Secure_Open_Source_Password_Keeper_From_the_Electronics_to_the_62856_63210.png