Developed on Hackaday: License Incompatibilities and Project State

mooltipass top pcb

It has been a while since we wrote an article about our ongoing offline password keeper project, aka the Mooltipass. Our last post was asking our dear readers to vote for their favorite card art, so what have we been doing since then?

For the last few weeks we’ve mostly been improving our current PCBs and case design for the production process to go smoothly. The final top PCB shown above has been tweaked to improve his capacitive touch sensing capabilities, you may even see a video of the system in action in the Mooltipass project log on hackaday.io. We’ve also spent some time refining the two most popular card art designs so our manufacturers may print them correctly. We’ll soon integrate our updated USB code (allowing the Mooltipass to be detected as a composite HID keyboard / HID generic) into the main solution which will then allow us to work on the browser plugin.

It’s also interesting to note that we recently decided to stop using the GPL-licensed avrcryptolib. Our current project is CDDL licensed, allowing interested parties to use our code in their own project without forcing them to publish all the remaining code they created. The GPL license enforces the opposite, we therefore picked another AES encryption/decryption implementation. This migration was performed and checked by our dedicated contributor [Miguel] who therefore ran the AES NESSIE / CTR tests and checked their output, in less than a day.

We’re about to ship the first Mooltipass prototypes to our active contributors and advisers. A few weeks later we’ll send an official call for beta testers, just after we shown (here on Hackaday) what the final product looks like. Don’t hesitate to ask any question you may have in the comments section, you can also contact us on the dedicated Mooltipass Google group.

Developed on Hackaday: Olivier’s Design Rundown

The Hackaday writers and readers are currently working hand-in-hand on an offline password keeper, the Mooltipass. A few days ago we presented Olivier’s design front PCB without even showing the rest of his creation (which was quite rude of us…). We also asked our readers for input on how we should design the front panel. In this new article we will therefore show you how the different pieces fit together in this very first (non-final) prototype… follow us after the break!

[Read more...]

Developed on Hackaday: The Top PCB dilemna

The Hackaday community offline password keeper is slowly coming together. A few days ago we received the top PCB for Olivier’s design (shown above). If you look at the picture below, you may see the problem we discovered when opening our package: the soldermask was the wrong color! Given the board is meant to be placed behind a tinted acrylic panel, this was quite a problem…

After using some spray paint, we managed to get to the point shown in the bottom left of the picture. The next task was to find the best way to illuminate the input interface with reverse mount LEDs. Using a CNC mill we machined openings (top right PCB) but also removed some epoxy on both PCB’s sides, thinking it would provide a better light diffusion. We then wrote part of the Mooltipass PWM code and took these pictures:

[Read more...]

Developed on Hackaday: 2 Days Left to Submit your Design!

We’re sure that many of Hackaday readers already know that one of the two main components of the Mooltipass project is a smart card, containing (among others) the AES-256 encryption key. Two weeks ago we asked if you’d be interested coming up with a design that will be printed on the final card. As usual, many people were eager to contribute and recently sent us a few suggestions. If you missed the call and would like to join in, it’s not too late! You may still send your CMYK vector image at mathieu[at]hackaday[dot]com by sunday. More detailed specifications may be found here.

In a few days we’ll also publish on Hackaday a project update, as we recently received the top and bottom PCBs for Olivier’s design. The low level libraries will soon be finished and hopefully a few days later we’ll be able to ship a few devices to developers and beta testers. We’re also still looking for contributors that may be interested in helping us to develop browser plugins.

The Mooltipass team would also like to thank our dear readers that gave us a skull on Hackaday projects!

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:

[Read more...]

Follow

Get every new post delivered to your Inbox.

Join 93,886 other followers