[Security] Can a compromised machine reprogram the mooltipass?

[Lyle]

Can a compromised machine reprogram the mooltipass?

I am aware that the mooltipass "aims at reducing the number of attack vectors to a minimum". If one assumes the machine is compromised, then a keylogger is possible. But as has already been discussed ad nauseam, this is not of concern since it is a less common attack vector, and the strategies to mitigate such a vulnerability would drastically impact the usability and simplicity of the device. I fully agree with this sentiment.

My main concern is that if one assumes the host machine is compromised, you would expect that only the password that the mooltipass spews out will be compromised. That is, only a single service that the user makes use of is compromised since using the mooltipass encourages distinct passwords for each service, which is largely why this project exists in the first place. If a compromised machine can flash new software onto the mooltipass and still make it look like the legit interface, then one can assume that the entire database of passwords stored on the smartcard is compromised, given that the user has already entered the correct pin with the newly flashed malicious software. This turns it into a very similar situation as the recently revealed usb firmware hack(BadUSB), since a reflash does not limit itself to just compromising the mooltipass, but other machines that the compromised mooltipass is plugged into after the fact.

Given the above considerations, can the mooltipass as is prevent this from happening?
If not, I can see 3 possible solutions;
1. A physical jumper or switch or
2. An additional menu option to enable programmability at the user's discretion.
3. Somehow disabling it altogether.

Option 3 is a bad option since it would not allow security patches.

You guys have an awesome project. Looking forward to hearing from you guys.

This message and attachments are subject to a disclaimer. Please refer to http://www.it.up.ac.za/documentation/governance/disclaimer/ for full details.

[Lyle]

A crap. I posted with my university account. My account is managed by my university, that is why that annoying disclaimer was added. Sorry about that, I did not realise it would show on google group posts. Sigh.

[Bjorn Wielens]

As it currently functions, one has to plug in the mooltipass with a smartcard inserted the "wrong way around" (i.e. no chip contact) to enable DFU mode - so it's not possible to do a drive-by reprogram. When the device isn't in DFU mode (during regular use) the avr device isn't accessible for programming - only the two HID devices.

--
You received this message because you are subscribed to the Google Groups "mooltipass" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mooltipass+...@googlegroups.com.
To post to this group, send email to moolt...@googlegroups.com.
Visit this group at http://groups.google.com/group/mooltipass.
For more options, visit https://groups.google.com/d/optout.

[mathieu...@gmail.com]

(currently writing a detailed answer)

Bjorn: this technique won't be available in the production ready units

[Bjorn Wielens]

Fair enough, though I did say "As it currently functions" ;)

So long as there's a unique user action required on the update such that they are knowingly updating their firmware, the issue should be mitigated.

[Lyle]

Awesome. Thanks for getting back to me on that.

[mathieu...@gmail.com]

Hey Lyle,

You raise an excellent point.

Allowing firmware updates on the Mooltipass have actually been a hot topic a few months back and I'll explain why:

- not allowing firmware updates would make all sold Mooltipass devices vulnerable if an attack was to be found in the future

- allowing multiple safe updates requires public/private key cryptography (or similar) to check that the firmware updates are genuine

Our current solution is here: https://github.com/limpkin/mooltipass/blob/master/source_code/src/USB/usb_cmd_parser.c#L1124

In short, all devices shipped to the campaign backers will contain a unique and random (eg not generated with a PRNG) password that will allow the Mooltipass to go in bootloader mode to update itself. This password is long enough that bruteforcing isn't realistically feasible. This allows a secure enough (worst case is that someone grabs your password before you actually have the occasion to use it to update your MP, but in that case the update procedure won't work, which would let you know that your MP is compromised) update procedure. As for the other updates... it's currently in the talks.

This of course assumes that the Mooltipass physical integrity isn't compromised. Obviously, if someone tears it open he'd be able to reprogram it.

let me know if i'm clear,

Mathieu

[Lyle]

Bjorn: We will know more once Mathieu finishes his answer. So is there a documented plan of action to prevent malicious modification?

[Brendon O'Halloran]

You could make something in software; similar to the way installing an app from an "unknown" source in android works. Have a prompt come up. From there the user can choose to deny the system from programming the mooltipass or allow it to program it.

[Charles Engen]

I like Brendon's idea to prompt from the device to update so at least its not able to be done without user input and acknowledgement.

- Charlie

On Wed, Nov 5, 2014 at 5:01 AM, Brendon O'Halloran <brendon.o...@gmail.com> wrote:

You could make something in software; similar to the way installing an app from an "unknown" source in android works. Have a prompt come up. From there the user can choose to deny the system from programming the mooltipass or allow it to program it.

[mathieu...@gmail.com]

Combined with our current password approach... excellent idea

[Lyle]

Mathieu,

Thanks for the detailed answer, I really appreciate it. I started reading through the source a bit, well, skimming mostly. I have a few follow up questions is you or anyone else is up to it?

"This of course assumes that the Mooltipass physical integrity isn't compromised. Obviously, if someone tears it open he'd be able to reprogram it."

I agree. That being said, there is an easier way to compromise the device if you have physical access, even though it is not strictly necessary if the user is careless.
It works like this, if I did not misunderstand anything.
When exporting the eeprom, it is not encrypted from what I can see from skimming the source. Only the credentials stored on the smartcard are encrypted when exported, which is a different operation, if I understand correctly.
The EEPROM stores the random password at EEP_BOOT_PWD. This key is dumped indiscriminately along with the rest of the EEPROM content. If an adversary has access to the device, he/she can approve the export operation and then extract the password, after which the adversary can reprogram the device.
Now for the part about the user being careless. From reading the source, which I might have read incorrectly, exporting the EEPROM requires user permission. If the user is careless enough to allow an export that was initiated by a malicious program on the host machine, then this program has everything it needs to compromise the device.

My concern is that the security measures in place to protect the credentials(ie reprogramming the device) is a random password, yet this random password is not protected with the same degree of concern. I am not sure if this is a big issue, I am just trowing some thoughts your way.

Thanks for graciously humoring me.

[mathieu...@gmail.com]

Hey Lyle,

Thanks for the detailed answer, I really appreciate it. I started reading through the source a bit, well, skimming mostly. I have a few follow up questions is you or anyone else is up to it?

>> My pleasure to reply to an interesting discussion that may lead to better solutions! 

When exporting the eeprom, it is not encrypted from what I can see from skimming the source.

>> only the current user's eeprom areas can actually be exported (see 0x5B, 0x5E in https://github.com/limpkin/mooltipass/tree/master/source_code/src/USB) and not the password. You may be confused by the NODE_BLOCK_IMPORT_EXPORT define that isn't activated in the production version (or beta tester version for the matter).

Good find though :)

[Lyle]

I will do some more reading, thanks.

[Henryk Plötz]

Moin,

Am Wed, 5 Nov 2014 20:29:07 +0100 schrieb "mathieu...@gmail.com"
<mathieu...@gmail.com>:

> >> only the current user's eeprom areas can actually be exported (see
> >> 0x5B,
> 0x5E in
> https://github.com/limpkin/mooltipass/tree/master/source_code/src/USB)

> and *not *the password. You may be confused by the

> NODE_BLOCK_IMPORT_EXPORT define that isn't activated in the
> production version (or beta tester version for the matter).

Still, he has a point that I hadn't thought about earlier: If there's
no additional protection on the backup feature, an attacker can do this:
a) prepare a malicious mooltipass M in advance (e.g. buying one and
then doing a 'firmware update' on their own hardware, as is their
right)
b) in a moment of short access to a victim's mooltipass V:
b1) do an export from that device V
b2) import the data onto the malicious device M
c) swap V and M, e.g. leave the malicious device where the victim left
it, and take the original victim's device with them.

On short notice I can't think of an effective way to prevent that
without sacrificing the interchangeability of mooltipass and keycards,
and hence the whole point of back-ups.

--
Henryk Plötz
Grüße aus Berlin
~ Help Microsoft fight software piracy: Give Linux to a friend today! ~

[mathieu...@gmail.com]

Hey Henryk,

Your b) needs to have a victim's mooltipass unlocked... and we could implement an additional PIN verification screen before entering the memory management mode.

Mathieu

[mathieu...@gmail.com]

We could actually make the parrallel with not inserting your credit card in modified ATM machines...

[Daniel Wedlund]

What about having a short string, selected by the user, encrypted using his/her card. When his/her card is inserted in the device the string gets decrypted and the clear text message is displayed the user can easily verify that it actually is his/her selected string that is displayed.

Now the attacker needs to know also this "secret" string else the user will know that something has changed with the device... 

[mathieu...@gmail.com]

Do you mean a string that couldn't be exported via our synchronization process? That's definitely an interesting idea...

But considering Henryk's attack scenario the attacker could also read this string when the Mooltipass is on.

[Daniel Wedlund]

Yes, the string should not be exportable ... however one need to think of how to make such an attack practiacally impossible... and still think of the trade-off's on usability.

[mathieu...@gmail.com]

IMHO asking for the user to enter his pin code before entering memory management mode is actually enough to prevent the scenario described by henryk.

[Brendon O'Halloran]

Agreed. You could also implement a lock protocol upon someone other than the user trying to access the data stored on the card. Say someone did attempt to modify the info on the card and failed say 2 or more times - the card would then be locked via the MP. To unlock it, the user whose card it is would have to input the pin code once to unlock it. After unlocking it, they would have to input it again to enter memory management mode. 

[Lyle]

If I could throw another idea your way?
It seems that the concern is that there could be security issues with placing your smartcard into a compromised mooltipass.

Ideally one should be able to know that the mooltipass is compromised once one tries to access the smartcard contents.

The solution that I can think of has two interesting properties:
1. Even if the user discloses the pin to the compromised mooltipass, the mooltipass is unable to read the smartcard.
2. The compromised mooltipass will be unable to mascaraed as a working mooltipass, thereby letting the user know something is up.

It works as follows:

When setting up a new mooltipass to use a new smartcard, the mooltipass asks the user for a random 4 digit pin or it generates one for the user, lets call this pin P0. This 4 digit pin (P0) is what the user will input when he/she wants to unlock the smartcard. After which the mooltipass asks for the actual pin of the smartcard, lets call this P1. Then the mooltipass performs a XOR operation, that is P2 = P0^P1. The result(P2) is stored in the mooltipass eeprom.

Now every time the user wants to unlock the smartcard, the user provides P0 and not P1. The mooltipass then XORs P0(provided) and P2(stored in eeprom) to derive the actual smartcard pin(P1). This way, the mooltipass has to know P2, due to prior setup, in order to access the smartcard. Additionally, the actual pin is never disclosed to a malicious device. In such a situation that the user does enter the pin(P0) into a compromised mooltipass, the device is unable to unlock the smartcard and is therefore unable to compromise the credentials stored in the smartcard. This also serves to alert the user that something fishy is going on.

Above I only mentioned a new mooltipass and new smartcard setup. Obviously, doing this with an old smartcard and a new mooltipass is only slightly different. You simply need to provide the new mooltipass with P0 and P1 for the scheme to be initialised again.

Now tear me apart.

[mathieu...@gmail.com]

Hey Lyle,

This actually doesn't solve anything, I'll explain why:

- if the user wants to use another mooltipass at work (for example) he needs this P2 to unlock his smartcard

- this means he needs to export P2 in some way

- this means there should be a way in the app or mooltipass to export p2

- this means that the scenario described by Henryk (mooltipass unlocked, without pin asking when going to management mode) would still work.

For people joining the conversation, this is the current solution that solves Henryk's case:

- pin code required when going into memory management mode

- memory export encrypted with user provided password

The only attack scenario that remains is if a user voluntarily imports all his credentials in a compromised mooltipass. But as with fake ATM machines, there's not much we can do.

Mathieu

[Lyle]

"But as with fake ATM machines, there's not much we can do."

The solution that I proposed is specifically to address the fake ATM machine scenario. That is, a tampered with mooltipass that you have previously used and trusted is useless and raises the user's suspicion. Additionally, one's pin is never compromised.

"this means he needs to export P2 in some way"

No because P0 and P1 can be used to find P2. I am not sure why an export is necessary. When setting up the mooltipass(its a new device so you can trust it) at work P0 and P1 is provided. Unless of course this is deemed to sacrifice too much user friendliness when setting up a new mooltipass.

The idea is that once the user establishes trusted mooltipass devices, say one at home and one at work, these devices, even if they are tampered with, cannot compromise the user's passwords or PIN number.

[mathieu...@gmail.com]

The solution that I proposed is specifically to address the fake ATM machine scenario. That is, a tampered with mooltipass that you have previously used and trusted is useless and raises the user's suspicion. Additionally, one's pin is never compromised.

>> If I'm not mistaken, in your scenario you suppose that tampering with the Mooltipass affects the eeprom (which in practice is actually true given the fuses we will set). With our current setup, if someone tampers with the mooltipass and therefore change the eeprom contents, the Mooltipass won't be able to decrypt your passwords as the AES CTR value is stored in Eeprom so you'd know that something fishy was going on. Henryk, can you let us know if not knowing the CTR value actually is a good protection? It'd actually be fairly easy for us to XOR the user entered code with our AES CTR value (which is random) without asking the user for P0.

Please note that there is a much easier way for someone to get your pin code on a tampered mooltipass: sniff the signals going to the card. Our debate is therefore rendered a bit pointless (even though it's very interesting!).

No because P0 and P1 can be used to find P2. I am not sure why an export is necessary. When setting up the mooltipass(its a new device so you can trust it) at work P0 and P1 is provided. Unless of course this is deemed to sacrifice too much user friendliness when setting up a new mooltipass.

>> I'm not sure to follow you. Can you explain exactly what you'd do if you want to copy one mooltipass to another? On the other mooltipass you'd need to enter manually your P0 and P1? Does this mean that the user should always remember the P0 he always uses together with a P1 he only needs when setting up new devices? If that's that the case, user friendliness may actually be a constraint...

[Lyle]

"Can you explain exactly what you'd do if you want to copy one mooltipass to another? On the other mooltipass you'd need to enter manually your P0 and P1? Does this mean that the user should always remember the P0 he always uses together with a P1 he only needs when setting up new devices? If that's that the case, user friendliness may actually be a constraint..."

There is nothing stopping the user from using a different P0 for each mooltipass. But yes, your assumptions are correct.

"sniff the signals going to the card"

You are right, I did not think of hardware tampering. I suppose the only way to prevent this is to use a smartcard uses asymmetric encryption to accept the pin in an encrypted channel, if such a thing even exists.

"Our debate is therefore rendered a bit pointless (even though it's very interesting!)."

Agreed. I will keep an eye out(lurk) for anything I can assist with. I am eager to contribute. Thanks for humoring me.
Lyle

[mathieu...@gmail.com]

I suppose the only way to prevent this is to use a smartcard uses asymmetric encryption to accept the pin in an encrypted channel, if such a thing even exists.

>> It does exist. However you won't be able to source these cards as they are made by big groups that are not interested in sourcing them to us normal people. Henryk will therefore argue that a basic card can do the trick (which is very true) but we're still not sure about its capabilities, price for required functionalities and we will end up in our "what we can implement in a timely manner with our contributor based model" discussion :).

I am eager to contribute. Thanks for humoring me.

>> My pleasure!

[Schuyler St. Leger]

I see an implementation problem with the bootloader password. The memcmp method used (I believe it is http://svn.savannah.nongnu.org/viewvc/trunk/avr-libc/libc/string/memcmp.S?root=avr-libc&view=markup) will take a varying amount of time to return if the password is incorrect. An attack based on the time it takes for the Mooltipass to reply could work.

Here are the slides from a DEFCON talk on this attack. https://defcon.org/images/defcon-22/dc-22-presentations/Mcmillan/DEFCON-22-Paul-Mcmillan-Attacking-the-IOT-Using-timing-attacks.pdf

Schuyler St. Leger

[mathieu...@gmail.com]

Hey Schuyler,

You make an excellent point... though in our case given that the USB HID packets are only sent every ms (IIRC) and the time difference for the memcmp is much lower than 1ms it's unlikely this attack will be efficient.

Anyway, I actually was planning on encapsulating this particular bit of code the way we did for the aes related tasks: https://github.com/limpkin/mooltipass/blob/master/source_code/src/LOGIC/logic_aes_and_comms.c#L265

Thanks for taking the time to look in our code... that's quite awesome :)

Mathieu

[mathieu...@gmail.com]

implemented: https://github.com/limpkin/mooltipass/commit/822b51b6236a765cb52d0a7e0101557a8efe619b