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.
Seems like a good project, wouldn’t it make sense to use the same hardware and re write the code in C, show how Arduino is only a very small slice of prototyping and if you want something to resemble something like a end product you have to do the hard work and code. I know the problem is with the bootloader but why not use this project to demonstrate the limits of Arduino, in this case security. With the Atmel chips isn’t there a way to make them write protected / One time programmable?
The chip level lock bits are only protected from the average person to read the contents. The chip can still be erased and new trojan code be compiled from open source and loaded.
Remove all the other access points: i.e. disable the Serial In Circuit Programming (SPIEN), Debug Wire (DWEN), External Reset (RSTDISBL), no headers for ISP and thus outside of parallel mode, the bootloader is the only mean of altering the application firmware. We can also make that a bit more messy for the average hacker by using replacing a BGA or MLF package, but someone could simply buy and swap the PCB without a locked down chip. :/
The source code can remain open source, but the encryption key has to be private for signing the firmware code and only downloaded from a trusted site. For those who believe more in open source than security can opt for a non-DRM device and tinker on their own.
Agreed. I added code hot-swapping to Gamebuino’s boot loader last week for the RWW section but I see no reason why it couldn’t be done in NRWW. Start with something like optibooot, add decryption to the STK_PROG_PAGE upload handler and remove STK_READ_PAGE. Both code and bootloader can now be securely patched and the only thing a hacker can do is a full chip erase.
Great suggestion. How much space would it take to implement public/private key cryptography in this case?
Doesn’t need to be private/public, both ends are secure. I’ve written an XXTEA decryption routine in 284 words, I’m pretty sure it could be squeezed into 256 with a bit of hand tweaking.
great! would you be interested in helping us? :)
Still.. I’m having difficulties accepting the fact that access to a single key may compromise all mooltipass devices at once…
That depends on what you’re trying to achieve. If you want to verify the firmware hasn’t been compromised, you need a public/private keypair, as I detailed in my comment below.
arachnidster please correct me if I’m wrong but I really don’t see the benefit of a private/public key pair in a case like this. Giving the boot loader the public key doesn’t make sense because people need to flash their own firmware, so they all need the private key. Similarly giving the boot loader a public key doesn’t make sense because it only has to receive uploads from a single party (i.e. the owner).
Mattieu: in the case of a symmetric key you initially ship the firmware with no key at all and it’s up to the user to generate the key and program it into the device in order to activate it. If you want you can also program a reset command to clear the key, but the handler for said command would of course also have to re-flash the hot-swappable part of the firmware beforehand. (Btw I’m planning on uploading a demo of encrypted hot-swappable boot loader functionality sometime over the next week or so, if it’s something you guys might be interested in then I’ll be sure to msg you).
Myndale, anyone compiling their own firmware will need to use their own keypair. Having a private key in the device and a public key in the software that talks to it allows you to guarantee that the device is running the firmware you think it is (or at least, running firmware flashed by someone who had the private key).
Thus, if an attacker were to reflash your device, the only ways to do this undetectably would be a) if they have access to the private key that was on the device already, or b) if they can modify the software in your computer to use a different public key. In the latter case you’re already hosed!
(Last post, I promise, then I’ll take it to the forum). It’s the “if they have access to the private key” bit that makes me nervous. I agree with you in principle but IMO the public/private key signature check shouldn’t be done in the device. If you do implement it like that and the private key is compromised (which does happen) then every device is immediately vulnerable to attack. However, if you use public/private key to sign your delivered firmware/utilities etc but then make the user actually encrypt with their own symmetric key before flashing to the device then they have to personally authenticate every update from that point on. In the unlikely event that the private key is compromised you simply revoke that key on the key server and you instantly restrict damage to only those units that have already been compromised. (The fact that symmetric decryption also happens to be both faster and smaller is a coincidental bonus).
http://www.atmel.com/Images/doc2589.pdf “Atmel AVR231: AES Bootloader”
>Implements the Advanced Encryption Standard (AES):
– 128-, 192-, and 256-bit keys
• AES Bootloader fits into 2kB
Let’s hope that a potential contributor would like to work on that then :)
I found a bit of a problem with the non-programmable one.
If someone finds a bug, it won’t be possible to upload new firmware over USB.
agreed… that’s why we’re going to need a lot of beta testers! (hint hint)
Maybe have a jumper, or a “conceptual jumper”, so the device stays in lower-security, flashable mode, until the dust’s settled and everybody’s happy with the devices. Then once the final firmware is done, it’s uploaded then deactivates the ability to rewrite it in the future. Using the security bits on the chip, probably.
You could also do the PIN-unlock at the bootloader level so you couldn’t change the software in the main without the PIN.
Also I’m not sure there is a point – perhaps you should offer some prize to the first one who can compromise the “secure” mooltipass without it being easily detectable.
Seems like it should be fairly trivial to add in a few signatures. If you are willing to go the ‘sealed case’ route, a simple password (assigned per device) would be sufficient. It would require minor modifications to the arduino software (and possibly to avrdude) so that you could have a password file that lives in your project directory which is uploaded before the main program to unlock the bootloader (in this use case the bootloader itself wouldn’t even need to be protected, if the user desired to overwrite the bootloader with an insecure one that is their choice).
It gets more complicated if you want to also be able to secure against people cracking the box open, in that case even writeprotecting the whole chip is somewhat worthless since the attacker could just pop a whole new micro in. You would need to implement a signature program where HAD can sign firmware with their private key, which is then checked by the client program (on the users computer) using the HAD public key. To keep the device re-programmable by the user, HAD could implement a simple chain of trust, and sign the bootloader with another another private key (assigned per device) contained in it which it uses to check the main fimware on boot, and give that key to the user along with the device (in fact it could even be stored on the device if you are clever!), so that the user could sign their own firmware.
I agree with you that it’d be the best solution.
However, how would you implement the password per device? a random() function that would output the number and be output at assembly?
I’m guessing public/private key cryptography may be too complex to implement…
Possibly unrelated, but whenever I read solutions like “this key isn’t enough, add more keys” it reminds me of the original xbox. Just make sure the key isn’t stored on a different chip to the one that uses it ;)
What exactly is the point of this? I tried reading the project page, but there is so little information there, that it might as well not even exist. I looked thru some of the google group posts and still dont understand how exactly this makes things more secure.
For instance in the “PIN enter method post”, Mathieu says the PIN should be entered on the device so malware on the host PC can’t intercept it. But if this were the case, wouldn’t the malware on the host PC be able to intercept the password the device returns, or if it is displayed on the device LCD, capture it with a key stroke logger?
You can capture the password one at a time when you access a website on a PC with a keylogger. You don’t want to give away the encryption/access key to *all* the stored passwords on the device by having to enter that particular key on a PC with the keylogger!
lol wut? the malware will access all the passwords stored on the device. You are eventually going to use all the passwords at some point in time, the only difference is that it will take a little bit longer for the malware to do it.
Really it seems as if this project is nothing more than an excuse for someone to justify the cost of their 3d printer and arduino.
not sure if you’re serious or trolling here…
Yes, and you can also shoot pigeons with a flak cannon. There’s real world problems and then there’s the funny silly ones :0) People who want military security probably wouldn’t use this anyway :)
You can’t say “it isn’t very GOOD security but then we’re not the military or anything”! If you’re inventing a security device, criterion #1 is security!
Hopefully someone on the project has experience and understands all the demands and necessities of computer security. Conceptually an LCD and an Arduino and maybe some buttons is the easy part! The security model’s the really hard bit. You don’t have to be NSA-proof but it should at least be good enough to actually bother with. Not sure how big the market is for people who kinda want security but aren’t really all that arsed about it.
Is there a high-level description of what the security is going to look like? I kind of assumed that the “Alice and Bob” view of security was going to be the first thing you guys sketched out. Based on the types of things that it sounds like you’re focusing on in terms of security I’m a bit worried.
Securing these devices is going to be really difficult on a number of fronts. I see you have people making informed suggestions on your google groups page (i.e. using CBC instead of ECB, though it likely won’t matter for your usecase because the blocksize likely far exceeds the size of the data being held).
What I want to see is a diagram which shows something like: “user plugs in mooltipass -> device registers as an HID device and requests a sufficient amount of current -> mooltipass screen turns on -> requests for user’s pin appears on mooltipass screen -> user enters pin on mooltipass keypad/touchscreen/? -> mooltipass accepts pin, performs a _______ hash of the pin to form a key, compares it with ??? stored in !!!!! -> smartcard somehow gets involved and responds with something? -> …? -> profit!”
Make sure that you’re as close to conceptually perfect as possible with your security plan before you move into implementation. You may implement everything perfectly, but without first scrutinizing the concept with a magnifying glass the size of New York it’s not possible to be confident in the final product.
In the google groups we actually mentioned we were going to use CTR mode….
Have a look at the 2014-02-23.limpkin_berlin.pptx file in the presentation directory in the main repository, it gives a great overview of what you’re asking for.
Looking through the presentation it’s unclear to me how the stage “ebay.com credentials?” was reached in the diagram on slide 10. I’ve repeatedly seen the comment of having the computer communicate with the device via “HIDSet_Reportrequests” but this seems to demand that there is software on the computer in question to transmit the URL which you’ll be using to the device (while the driver may contain the functionality there has to be a known protocol for the set report requests to follow). I don’t see any mention of how to get that onto the computer in general, does the mooltipass require an executable on the computer? Does the mooltipass initially mount as a read-only HID mass-storage device to dump this executable onto the computer?
Slide 15 shows “[0x00 + random numbers]” used as padding (which should effectively be [random numbers], I think the “+” is unclear), then shows that 0x00 is a separate byte. Is there a reason for the 0x00? Null termination of the “string”? Why not store the length in bytes as the first byte as opposed to depending on null termination in the password itself? This would meant that malicious users attempting to brute force the decrypt password wouldn’t have a hint that they got it right based on a null in the first 33 bytes.
I’m also super bewildered by the statements about moving between multiple devices. Where are the passwords stored? It sounds like the smartcard contains the AES-256 private key only, which means that you have a single-pass encrypted password stored on reasonably compromise-able media. Pulling the data out for copying between multiple mooltipass devices should also be strongly documented.
This also seems pretty susceptible to me putting in a malicious smartcard which accepts any pin and then outputs 0x00000000 for the key in order to get the mooltipass to dump out the encrypted data for offline hacking (I actually don’t recall if AES-256 has unsafe keys like that, but you should verify). If you’re trying to secure the encrypted passwords inside the mooltipass itself you’re going to want to put some sort of checksum/data verification inside the decrypted data so that the mooltipass doesn’t transmit something off the device unsafely.
Things like this are what’s missing in the non-code documentation for how the mooltipass should work.
Correction, if you can get the device to dump the encrypted data in its entirety, since this is reversible encryption I could just decrypt it using the key from my malicious smart card. There are plenty of ways to defend against attacks like these though, I would just want to know what the documented plan was, or that someone on the team was considering attacks like these.
AES doesn’t work t his way…
Allow me to better explain.
For sake of clarity let me define some terms up front:
Let ENC(A, K) be defined as a block of data “A”, padded as appropriate, and encrypted with key “K”
Let DEC(B, K) be defined as a block of data “B” decrypted using key “K”, with the padding removed
Let SK be defined as the key on the smartcard
As a short example: ENC(“p@ssw0rd”, SK) would be the AES-256 encrypted value of “p@ssw0rd” followed by a trailing 0x00 byte and the random padding
DEC(ENC(“p@ssw0rd”, SK), SK) would simply be the string “p@ssw0rd”
As for my comment:
On the device, we have a stored password. We’ll recycle the password above, and say that on some storage medium we have ENC(“p@ssw0rd”, SK)
I insert a malicious card into the mooltipass (a separate Arduino/PIC/Arm/whatever which emulates a smartcard), and then hook up the connectors so that it can enter the pin automatically and quickly (in this case it will mash in 0000 as fast as possible). The mooltipass will forward the pin to the malicious smartcard, and the smartcard will return MK, the malicious key.
The mooltipass will then run DEC(ENC(“p@ssw0rd”, SK), MK), and attempt to output the result to the USB port. Since I’m assuming I have control of everything but the moolitpass data, I have my host accept the output (even the things which would normally be invalid keys).
I now run ENC(response_from_mooltipass, MK) which is equivalent to ENC(DEC(ENC(“p@ssw0rd”, SK), MK), MK) which unravels to just ENC(“p@ssw0rd”, SK). Since I now have this external to the mooltipass, I can brute force attempt to discover SK very, very quickly.
This seems like a practical attack that doesn’t require very much effort beyond a simple libusb-based program on a host to communicate with the mooltipass, and a cheap microcontroller to dump the fake key in as a malicious smartcard.
In this case, wouldn’t it be much simpler to simply unsolder the flash chip, get the contents, and run a bruteforce attack on the encrypted password (as long as it may take)?
I guess since SK’s keyspace is huge and the plaintext is unknown this is actually a pretty impossible brute force attack. I always forget that symmetric key crypto with unknown plaintext is so secure of necessary information to even start hacking away at it. Add to that in that in my head we’re having a discussion about password storage and I’m mostly stuck on the concept of hashing which means that guessing plaintext and checking against the stored information seems plausible.
While I’ve clearly failed to make my case for why you should have these things documented in a non-code fashion, I would still like to see a more detailed diagram of the interactions and storage mediums, etc. Along with a few more detailed discussions about the protocol for duplicating the password store, interactions with the PC (i.e. who knows how to send the HID protocol stuff), and anything else. It would just be nice from a security discussion perspective.
hum, adding “arduino headers”? really?
comon. this is a one purpose thing you’re trying to make.
Breaking out the signals to an (additional) header or so on the pcb, mkay…
Personally i would not expect this device to be resistant to physical tampering.
A way to make sure the bootloader/firmware cannot be updated without some of physical acknowledgment /pin /password on the device itself.
that would be enough to make sure whatever software/malware/hack is running on the PC side cannot change it.
All the rest is imho overkill, if someone cracs open the case and reflash it using the ISP header or so…
well yeah, what are you going to do about this? (let alone what are the odds..).
at the end If someone comes along and replaces the mooltipass (or the pcb) you have with a mooltipass “clone” that “phones home” all your “physical” restrictions are useless anyway
I don’t see why the idea of being able to connect an Arduino based platform with an OLED screen and capacitive buttons to any Arduino shield would be a bad one…
Tamper-proofing is relevant against hardware sniffers, we just want to design the case in such a way that any tampering would leave some traces for the user to notice (which is not that hard).
We just want to cover all your bases… you can’t replace a mooltipass with another if it hasn’t your credentials in it…
“we just want to design the case in such a way that any tampering would leave some traces for the user to notice (which is not that hard)”
The point for me is that this is (in my eyes) a single purpose device.
if there are provisions for headers and this does not make the device unneeded larger or can then be populated/used for people who just want to use the pcb or cut extra holes in the case, fine, go for it, nice :)
But the mooltipass should be as “pocketable” (small) as possible imho.
Making it Arduino compatible actually didn’t make it bigger… rest assured that size is a constraint for our design.
It does seem bizarre, for a device that’s never meant to be opened or re-programmed, to make it Arduino-compatible. What’s the point?
and by the way, was under the impressions all my credentials would be stored on the smart card, not on the mooltipass.
if not, then what’s the use of the card?
Some of them will.
In short, the card also provides the “secure element” of the system. Have a look at the other mooltipass articles / google group discussions where you’ll be able to see this topic discussed in great lengths.
cheers, been away and did not follow all the stuff and missed the “read only” part of the smart card usage
that makes it less attractive to me, but if it’s a design decision then fine.
Instead of asking people to spend a hour or two searching HaD and reading countless articles and google group discussions, how about you make your project page less shitty and have more content than a one paragraph description. You really ought to stop posting articles about this here until then.
The problem I see here is that we cannot stop someone just replacing the device with a new one that looks the same (that they made in advance).
Instead we can store the user’s name and have the device say “Hello ” when turned on. Provided we protect where the name is stored this protects against changing the program or making a device that looks the same.
Sadly to prevent sniffing the wires directly you’d still need tamper evident packaging. Just put the conections inside and make people break open their packaging to change the program.
Your attack scenario would involve the hacker cracking open the user’s device, unsoldering the memory chip, re-soldering it to another device, then assembling the latter.
Having the device say “Hello x” is not a problem if you have access to the source files. A possible protection against this kind of attack would be to have the user sign his device physically.
My thoughts were that you could store the name on the microcontrollers internal memory and then set a flag bit to protect it? This prevents memory chips being removed and moved.
I don’t think how this functionality could be implemented if there’s no backup power on the board
You won’t have a lot of security for an external FLASH chip as they don’t have any protection mechanisms other than encryption. The data should either reside inside the microcontroller protected FLASH or a Smartcard. So may be compute a hash of the FLASH content and store it. Now that doesn’t prevent someone from making an identical copy of the *external* FLASH chip.
You could easily get an ARM chip with 1MB of FLASH, but *no* you want Arduino compatibility.
Unfortunately, if the attacker have the time to prepare a similiar device, and the attacker have a chance to exchange to original for the fake. it is very likely the attacker also know or can find out what to burn into the “hello …” field of his fake.
That’s true I guess. I guess it would need to more obscure than a name? Also a pin or something to prevent an attacker from just booting it up and finding out the word would be a bonus.
Put something inside (a tiny fuse, perhaps) that gets blown (or some other set only device, at least from a software perspective) if the bootloader is invoked, allowing the software to know if it has been tampered with,
Or require a trace inside to be cut or a jumper to be removed or added in order to enable the bootloader.
A software solution is possible: Embed a private key that is used to sign all communications with the computer. Provide the corresponding public key with the software.
Anyone wanting to develop their own can use their own public/private keypair, but they will need to supply the new public key to the software – making it impossible to change the firmware without it becoming immediately obvious.
I’m curious as to how it will lock a smart card down after too many attempts.
Does the smart card edit itself? It seems likely that I could read the data from the smart card onto the computer to allow me to test a huge number of passwords against thte data very quickly there.
The smartcard locks itself, preventing read accesses
I tell you what I’d like… a smart wristwatch I can write games and software for. Is it too late to ask for that?