limpkin

not trying to discard the work done here.... but from what I see the script "simply" uses dd to output the sdcard contents into a file, which is then used by foremost. I may be missing the point here, but why not simply tell users to directly type the two commands?

it is!

I designed www.themooltipass.com, a hardware-based password keeper, fully open hardware / firmware / software.

I wonder if he'll do an article on webauthn... that seems fairly promising as well!

The mooltipass project actually is looking for contributors for its next gen device! If you'd like to work on hardware (low power measurements, rf design), firmware (https://mooltipass.github.io/minible/) or software (https://github.com/mooltipass/moolticute) do not hesitate to drop us a message :).

Moolipass project creator here! It's surprising and wonderful to see our project mentioned here. Adding a time delay between PIN attempts definitely is a good idea. I'm afraid the number of maximum attempts is fixed by the hardware we're using.

An attack on the supply chain would have to happen at the very last stages when the device is assembled, as the assembler would otherwise notice the added component. I would even dare to say that the attack on the supply chain you're describing can only be done by the device assembler itself.

Disclosure: I'm the creator of Mooltipass.

When creating the Mooltipass offline password keeper we actually spent a considerable amount of time thinking about solutions for the particular problem explained on this website.

We therefore opted for the following techniques:

- only allow signed firmware updates, signed using an encryption key unique to each device

- given that firmware flashing using external programmers requires complete flash/eeprom erase, we implemented a challenge/response protocol to check for tampering during shipping.

Obviously things are way easier when you don't allow custom firmwares to be flashed on a device. But as a general rule I wouldn't trust a device that would allow other programs to run on it (eg phones, computers...)

Wait... so the ledger allows any firmware to be uploaded without signature checking? damn :(

I'm afraid I don't have great suggestions, but if you're around Lausanne one of these days, do not hesitate to ping me to have a chat about it.

Open source projects would definitely be the way to go... what are your skills?

- reddit

- content gathering websites (such as hackaday, if electronics)

- applying to conferences

- IRC

- related topic forums

Last time I looked into this AM335X chip and its PRUs, the information required to use and program them was very scarce. The SOC as a whole is not exactly developer friendly...

"So, we reverse-engineer the LoRa physical layer using the patents filed by Semtech [27, 57], which is the key LoRa chipset manufacturer. We also use the Semtech 1276 starter kit [10] that provides an interface to transmit LoRa packets with various bitrates and an arbitrary payload. Finally, we analyze the transmissions from the LoRa chipsets on a USRP."

This is some impressive work.

Creator of the device here. I'll address the few points that were raised in the comments section:

- Our device is used by thousands of users from all ages... even by elderly people

- We're about to launch a smaller and simpler version (no tactile interface, just a clickable scroll wheel), which will be sold at less than $50. Mooltipass Mini Prototypes have already been used for 2 months, with a better acceptance factor than the standard version

- We made a password keeping solution seeing that still very few services implement the different mechanisms created by the FIDO alliance (U2F & others). Unfortunately passwords are here to say for several years at least.