Developed On Hackaday: Let’s Build Some Hardware!

We’re pretty sure that most of you already know that a few months ago Hackaday was bought by SupplyFrame, who therefore became our new evil overlords. We do hope you’ve noticed that they’re actually quite nice, and in their divine goodness they recently gave the go-ahead on this series called Developed on Hackaday.

A new project will be made by the Hackaday staff & community and will hopefully be brought to the consumer market. For those who don’t have the time/experience to get involved in this adventure, we want to show and document what it takes to bring an idea to the marketable product stage. For the others, we would like to involve you in the design/development process as much as possible. Obviously, this project will be open source hardware/software. This time around, the hardware will mainly be developed by yours truly. You may already know me from the whistled platform (currently sold on Tindie) or from all the different projects described on my website, which makes this new adventure far from being my first rodeo.

What’s in it for the contributors? During all the steps of this project, we’ll offer many rewards as well as hand-soldered first prototypes of the device so you can start playing/testing it. Nothing is set in stone so every suggestion is welcome. Should we make a Kickstarter-like campaign to manufacture the final product, we’ll only do so once our prototype is final, our partners are chosen and all details of the production process are set and confirmed. In that case, we will just need to gather the required funds to make the device a reality. What are we going to build? Keep reading to find out.

So what about this new device? After many discussions with the writers, we decided we would make something useful for Hackaday readers. We wanted something simple that would simplify users’ lives and therefore settled on a secure offline password keeper. Keep in mind that the following description is just a draft, so your input is welcome in the comments section. Please keep it constructive as the way the comments are formatted is not optimal for this kind of discussion (we’re currently working on that).

The concept behind this product is to minimize the number of ways your passwords can be compromised, while generating long and complex random passwords for the different websites you use daily. As a side note, you may already know that most people often don’t use secure passwords, except red-haired women. Hypothetically, password keeping software could be circumvented by reading the key + encrypted passwords on the computer’s RAM. Ideally, the product should be so simple that my grand mother could use it (I’ll let you image her email password…). It will be as small as possible so it could fit in your pocket. Simply visit a website and the device will ask for confirmation to enter your credentials when you need to login.

smartcard-connectorsWhat about the hardware? We thought a good solution was to make a device that uses a smart card, connected to your computer via USB (to keep costs low). The device will store your AES-256 encrypted passwords and the smart card will keep your AES-256 key (as well as a few other passwords). The smart card will be (for the sake of simplicity) a read protected EEPROM that requires a PIN code to unlock its contents. As with your credit card, too many tries will permanently lock the smart card. Therefore, the project’s main components will be: a smart card connector, a microcontroller (Arduino compatible?), an OLED screen and its touchscreen panel. The OLED screen will provide good contrast and therefore better visibility. On the software side, we’ll ‘only’ need to write a simple script running on the users’ browsers. The browser script will send the current website URL to the device (via HID reports).

We prefer a contact based smart card for several reasons. They’re much easier to source, are cheaper and can’t be easily sniffed without you noticing it. We hope that making this an open project will ensure any future problems are handled. We also want the device to be as hackable as possible, and an Arduino compatible device with a touch sensitive OLED screen and USB connectivity will surely interest beginners out there.

So what’s next? We need a project name, so please give us some feedback in the comments section. You can also directly contact me: mathieu[at]hackaday[dot]com if you’d like to contribute (we need designers, coders, webmasters…), be part of the beta tester team or if you already know potential partners for this project. We look forward to your comments!

[Smartcard Image SourceCC-BY-SA]

142 thoughts on “Developed On Hackaday: Let’s Build Some Hardware!

  1. It should store other secret creds, such as encryption keys or Bitcoin wallet private keys as well; it should be possible to use the device as your procedure for decrypting your root filesystem and booting your operating system.

    If it works as a hardware security module; possibly options of offloading whole system encryption operations to the device, to mitigate the threat of keys being stolen from system RAM.

    There should be an optional “additional authentication” for some passwords or secrets, such as banking credentials, requiring that the encryption key on the unit also be encrypted with yet another key, stored on a remote server.

    After the smartcard and PIN are authenticated, software on your computer starts a RSA-encrypted challenge-response protocol, to provide the additional secret key needed to the device.

    A remote server can be used, allowing the device or smartcard to be “revoked” by the remote server, if lost; the remote server will provide an encrypted digitally signed message, to either allow access to the key, deny access, permanently destroy the key, OR a “Wipe this device” command.

    Using additional authentication requirements of the user’s choosing — such as an extra password, or additional two-factor auth devices, to be verified by the software, and the remote offsite server.

  2. A few people have commented on corporate security policies and not being able to plug in random devices. What about a portable/offline version? Why does this device need to be plugged into a computer – is it just for ease of entering the password and as a power supply?
    What about a portable version with a keypad, display, and battery?

  3. I’m not sure if this is quite what you need for your project, but I noticed a while back that the gnome-keyring project includes software that emulates a smart card and communication to and from it. That could be useful for seeing how it is done.

  4. I love the idea. I’ve never been very trusting of the ‘keychain’ applications out there.

    Personally, I like minimalist designs. For example, if you had a list of ‘destinations’ that you can search through, and for each destination have a stored username and password. Press one button and it spits out the user name, press another and it spits out the password. That also shortcuts the need for program interaction, which reduces the attack area of the device.

  5. PassCard, KeyCard, MiKey, MiPass, additional permuations thereof to find one not already Trademarked…

    And Darn, I’ve been thinging about exactly the same thing, shame I’m not actually got the wherewithall to do it. Yes please, I’ll take one!

  6. Storing username/password login credentials for Web sites is good, but another thing you may be able to do with this proposed hardware platform is standard PKCS11 plus a secure touchscreen interface. A couple possibilities:

    1. An SSH agent that not only stores private keys in the smartcard, but also tells you when said keys are used, and possibly requires you to physically confirm the use of a key beforehand (so that SSH keys can’t be misused at will if the device is unlocked and the host machine is compromised—an issue with ordinary SC readers).

    2. A PGP/GPG signing interface that lets you (securely) review the hash/text you are signing.

    Both of these have been on my wish list for a long time.

  7. I just need to ask the device for the password, get the user to enter the pin and then I get the password back in clear? Just like that? How is this secure? Should it not *only* sign some challenge and then make sure that the key *never* leaves the card?

  8. just an Idea for the ultra paranoid, what about a failsafe pin? if you enter it, it wipes or hides certain/all stored passwords from the card. or better yet you set the rules up(ie which passwords get removed or hidden) and then depending on which pin gets input, you can remove/hide those passwords, while still gaining access to the remaining passwords. thus pin 9875 shows only your work passwords, while 5928 deletes any passwords to email accounts.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.