Meet Lynx, A (costly) Offline Password Keeper

Maybe because he didn’t want to wait for the Mooltipass to be produced, [davidhend] built himself his own offline password keeper, named Lynx.

It is based around an Arduino Pro 328, a 2.8″ TFT touch screen, an RFID card reader, an FTDI basic breakout and finally a li-ion battery. Lynx is therefore self-powered and uses an RFID card to later read the XOR-encrypted passwords located in a SD card. A USB serial connection is used to send the passwords to the computer, which also charges the battery. The current BoM cost is around $220 but we’re quite sure it can be made for much cheaper when not using pre-made boards. Looking at the official GitHub repository tells us that the XOR key is stored inside the microcontroller and that Lynx checks the RFID card code to allow encryption/decryption.

On a side note, we recently published a FAQ on the official Mooltipass GitHub. You’re welcome to let us know what questions we may have forgotten.

Developed On Hackaday: Security And Arduino Compatibility

2013-12_Developed_on_Hackaday

Some of our readers noticed that the Hackaday community open-source offline password keeper (aka Mooltipass) has two incompatible characteristics: being secure and Arduino compatible.

Why is that? Arduino compatibility implies including a way to change the device firmware and accessing the microcontroller’s pins to connect shields. Therefore, some ill-intentioned individuals may replace the original firmware with one that would log all user’s inputs and passwords, or in another case simply sniff the uC’s signals. The ‘hackers’ would then later come to extract the recorded data. Consequently, we needed a secure tamper-proof Mooltipass version and an Arduino-compatible one, while allowing the former to become the latter.

Olivier’s design, though completely closed, will have several thinner surfaces directly above the Arduino headers. As a compromise, we therefore thought of sending a bootloader-free assembled version to the people only interested in the password keeper functionality, while sending a non-assembled version (with a pre-burnt bootloader) to the tinkerers. The Arduino enthusiasts would just need to cut the plastic at the strategic places (and perhaps solder headers to save costs). The main advantage of doing so is that the case would be the same for both versions. The drawback is that each board would have a different firmware depending on who it is intended for.

What do our reader think? For more detailed updates on the Mooltipass current status, you can always join the official Google group.

Developed On Hackaday: Coding Conventions And GitHub Pull Requests

The Hackaday community is currently very busy coding the low-level libraries of our open-source offline password keeper project. And when many talented contributors work together on a common concept, interesting discussions take place. In our dedicated Google Groups, some of them were about the choice of naming/coding conventions and also how/when to approve GitHub pull requests. But don’t leave already… this topic is actually more interesting than it sounds.

The age difference between the older and younger firmware contributor is guessed to be approximately 30 years… and many things can happen in such a time frame. Even though our coders are writing in C, most of them code in other programming languages at school/work. They also use different text editors on different operating systems. Understandably, each one of them therefore has its preferred coding / naming convention and indent style. The Mooltipass conventions were selected based on majority voting, and after many emails we settled on an Allman style convention with camelCase:

main(void)
{
    if (foo)
    {
        functionCall();
    }
    else
    {
        foo = 0;
        anotherFunctionCall();
    }
}
– 79 characters line length as a soft requirement
– 4 spaces, no tabs

Most of the contributors believe that it is the best compromise between code clarity and cross-platform compatibility, but we would be curious to know our Hackaday readers’ opinions on this particular topic.

The second matter is a bit more of a management one. What is the best strategy to manage and review code changes made to a main GitHub repository, when a project is at its infancy and composed of (more or less) non-remunerated contributors?
It is perfectly understandable that interest, spare time and willingness to contribute may vary over time. Perhaps some of our readers may already be familiar with Agile software development, a group of software development methods based on iterative and incremental development, which promotes adaptive planning, evolutionary development and encourages rapid and flexible response to change. Do you think this can be applied to the Mooltipass project?

We would be curious to hear similar experiences on these topics, as we gladly accept constructive criticism. You may also want to join our dedicated Google group to check out the different discussions that already happened there. On a side note, we are also currently looking for capacitive wheel / touch button footprints libraries for Kicad.

Developed On Hackaday: The Current Project State

It has been quite a while since we updated our readers with the current state of the Mooltipass, the offline password keeper project developed by the Hackaday staff and community.

A few weeks ago we presented you the designs that our mechanical contributors had thought of. We organized a poll to get a feeling of what the favorite designs may be and around one thousand people expressed their opinions. The first three favorite designs with their corresponding votes were:

Continue reading “Developed On Hackaday: The Current Project State”

Final Key : A Mooltipass-like Device

Since the Hackaday community started working on our offline password keeper, Mooltipass, we’ve received several similar projects in our tips line. The Final Key may be the most professional looking one yet. Similarly to the Mooltipass, it is based on an Atmel ATMega32U4 but only includes one button and one LED, all enclosed in a 3D printed case.

The Final Key is connected to the host computer via USB and is enumerated as a composite Communication Device / HID Keyboard, requiring windows-based devices to install drivers. AES-256 encrypted passwords are stored on the device and can only be accessed once the button has been pressed and the correct 256 bit password has been presented through the command line interface. Credentials management and access is also done through the latter. Unfortunately, the Arduino source code can’t be found on [cyberstalker]’s website, so if you see interesting features that you would like to be integrated in Mooltipass you may send us a message to our Google Group.

Developed On Hackaday: The Designs

We know that many of our readers have been impatiently waiting to discover what the Hackaday community-developed offline password keeper project will look like. Today we present you several designs that our mechanical contributors came up with and we will ask you to give your opinion about them. Obviously these are just preliminary cases that may evolve along the way, but we will only produce the electronics for the designs you prefer.

All the designs are embedded after the break, with a multiple-choices poll to express your interest. You may also want to join the Mooltipass Google Group in case you’d want to talk about the designs in more depth or meet their creators. On the firmware side, I just finished soldering many mooltipass prototypes that will be shipped in the coming days to our firmware developers. As you may have noticed, this project is gaining speed!

Continue reading “Developed On Hackaday: The Designs”

Developed On Hackaday: We Have Pixels!

It has been a while since we kept you informed about the current state of the Mooltipass project. Well, several days ago we finally received the PCBs we got produced at Seeedstudio. Keep in mind that this first version (shown in the picture above) is only meant to check that the chosen components can suit our needs while our mechanical contributors work on their designs. Moreover, we may add empty footprints for our readers that may want to hack the device.

After a few hours of soldering and a few days of coding, we finally got a basic firmware running. The OLED screen is easily readable and has an amazing contrast (the picture doesn’t do it justice). So far we checked all basic functionalities of the on-board components and it’ll still take a few days/weeks to be certain that we can settle with them. We are therefore starting to ship a few platforms to the firmware developers that want to work on the core functions of the Mooltipass. So if you’re an experienced C developer and have some spare time, you may get onboard by contacting me at mathieu[at]hackaday[dot]com or by joining the Mooltipass Google Group.

In a few days we will publish the designs that our mechanical guys came up with and we’ll ask you to let us know which ones are your favorites. Depending on how things will go, we may produce PCBs for several of them to select our final design based on user experience and ease of use. We look forward to hearing your feedback in the comments section below!