usb armory vs yubi key vs nitrokey vs FST-01

[Robert Sevat]

Hey,

I saw your talk at 31c3 and I'm quite interested, but I still have some concerns / questions. I've been looking around for a while now for a usb device to use to store pgp/ssh keys and a password manager database. So far I haven't found any device that satisfies all my concerns / requirements. So far the usb armory has the most potential however.

My main concern with the usb armory is; how does this protect you against a key logger?

What prevents a keylogger that logs you typing in your master password / pin from simply dumping all passwords in your password database?

The keys are save on the device, you need to actually exploit the armory to get access to them. But for keys there exist other cheaper solutions.

For ssh I use a bastion/jump host on which I use keys via sudo with 'sudo ssh $hostname' being whitelisted. So my user has no read access to my keys but can use them.
For pgp there are other devices that keep the pgp key on the device. For example, the FST-01, specifically made for pgp by a gnupg developer. The disadvantage is that it is a slow device and signing of 2048 bit keys takes 1.5 seconds. There also exists the nitrokey that can also do pgp/ssh and password managers etc.. But it is based on the fst-01 so unfortunately this device is also slow.

So that's a massive advantage of the usb armory, it's speed. But the usb armory suffers from the same problem as that nitrokey does for a password manager, key logging.

That's something where the yubi key has a big advantage due to the physical button on the device, you have to touch the button when doing authentication. I think this is a great solution to render a lot of key logging ineffective. They might be able to log your master password and some of the passwords you use while the key logger is active, but so long as they don't have physical access to your key, they still can't dump all your passwords. Unfortunately yubi keys are a lot harder to backup and you have to rely on their 3rd party authentication service to get the most out of it. But we could get the best of both worlds if we could add a button to the usb armory.

Would it be possible to connect a button to the gpio pins?

One other thing that for example the nitrokey has is it's 'tamper proof' usb casing. This was also asked during the Q/A after your 31c3 talk by one of the guys and you suggested they prototype a case and sell it. So I guess we as a community could do this. But I'd be perfect if the usb armory were sold with a tamper proof case with a small button in it.

I guess the answer to my question could be to use rfc 4226 OTP passwords with the password manager which reduces the problem of a key logger quite a bit but aside from the lack of support for it, it still doesn't render a key logger 100% unusable like a physical button would. It can still get authentication tokens at any time without physical access to the device.

Or maybe there are other things we could do to make a physical button unnecessary that I haven't thought of yet? Or maybe this falls under the category 'too paranoid', but I think a button / tamper proof case would only increase the cost slightly while making the product a lot more versatile / complete.

I'd love to hear your thoughts on this.

Kind Regards,
Robert Sevat

[Andrea Barisani]

On Sunday, January 4, 2015 9:58:59 PM UTC+1, Robert Sevat wrote:

Hey,

I saw your talk at 31c3 and I'm quite interested, but I still have some concerns / questions. I've been looking around for a while now for a usb device to use to store pgp/ssh keys and a password manager database. So far I haven't found any device that satisfies all my concerns / requirements. So far the usb armory has the most potential however.

My main concern with the usb armory is; how does this protect you against a key logger?
 

What prevents a keylogger that logs you typing in your master password / pin from simply dumping all passwords in your password database?

In standalone mode this is not a concern, when connected in device mode I understand that some are concerned by this.

First of all a pure keylogger might be defeated by some scrambling mechanism for pin/passphrase input, however this just raises the bar as at that point capturing the screen would defeat this.

The way I see it a robust application does only rely on passphrase to unlock private key material *on* the USB armory itself, while not giving access to it. This means that the passphrase (something you know) takes place in 2 factor authentication as private key material (something you have) remains on the USB armory.

This would mean that interception of the mere passphrase would not compromise your private key material and therefore provide only the (weakest) half of your secrets, unusable on their own.

This is quite a common pattern and applications that we will develop for the USB armory will take such considerations in mind.

 

That's something where the yubi key has a big advantage due to the physical button on the device, you have to touch the button when doing authentication. I think this is a great solution to render a lot of key logging ineffective. They might be able to log your master password and some of the passwords you use while the key logger is active, but so long as they don't have physical access to your key, they still can't dump all your passwords. Unfortunately yubi keys are a lot harder to backup and you have to rely on their 3rd party authentication service to get the most out of it. But we could get the best of both worlds if we could add a button to the usb armory.

The yubi key provides a single specific functionality which is not comparable to the full spectrum of applications that can be executed *on* the USB armory itself.

 

Would it be possible to connect a button to the gpio pins?

Yes.

 

One other thing that for example the nitrokey has is it's 'tamper proof' usb casing. This was also asked during the Q/A after your 31c3 talk by one of the guys and you suggested they prototype a case and sell it. So I guess we as a community could do this. But I'd be perfect if the usb armory were sold with a tamper proof case with a small button in it.

Tamper proofing is not an issue on the USB armory, there is no persistent storage on the board and removable storage (microSD) must be encrypted rather than relying on "tamper proofing" to ensure maximum security.

 

I guess the answer to my question could be to use rfc 4226 OTP passwords with the password manager which reduces the problem of a key logger quite a bit but aside from the lack of support for it, it still doesn't render a key logger 100% unusable like a physical button would. It can still get authentication tokens at any time without physical access to the device.

A button is no substitute for a passphrase, you are mixing and matching different concepts and applications here. Please make a specific use case example to discuss this further, however I hope I have answered your concerns already.

 

Thanks for the feedback!

[Robert Sevat]

Op zondag 4 januari 2015 23:46:02 UTC+1 schreef Andrea Barisani:

On Sunday, January 4, 2015 9:58:59 PM UTC+1, Robert Sevat wrote:

Hey,

I saw your talk at 31c3 and I'm quite interested, but I still have some concerns / questions. I've been looking around for a while now for a usb device to use to store pgp/ssh keys and a password manager database. So far I haven't found any device that satisfies all my concerns / requirements. So far the usb armory has the most potential however.

My main concern with the usb armory is; how does this protect you against a key logger?
 

What prevents a keylogger that logs you typing in your master password / pin from simply dumping all passwords in your password database?

In standalone mode this is not a concern, when connected in device mode I understand that some are concerned by this.

First of all a pure keylogger might be defeated by some scrambling mechanism for pin/passphrase input, however this just raises the bar as at that point capturing the screen would defeat this.

The way I see it a robust application does only rely on passphrase to unlock private key material *on* the USB armory itself, while not giving access to it. This means that the passphrase (something you know) takes place in 2 factor authentication as private key material (something you have) remains on the USB armory.

This would mean that interception of the mere passphrase would not compromise your private key material and therefore provide only the (weakest) half of your secrets, unusable on their own.

This is quite a common pattern and applications that we will develop for the USB armory will take such considerations in mind.

I agree, I don't think scrambling is the way, it only slightly raises the bar for a keylogger. Almost all half decent keyloggers include functionality to take screenshots on every mouse click / keystroke.

I'm aware of the fact that private key material never leaves the usb armory and therefore can't be compromised by a keylogger.  In the case of a keylogger I'm more specifically talking about running a password manager on the device. If the keylogger logs the pin/masterpassword of the password manager, nothing is stopping it from simply dumping say all ~100 passwords in the password manager.
 

 

That's something where the yubi key has a big advantage due to the physical button on the device, you have to touch the button when doing authentication. I think this is a great solution to render a lot of key logging ineffective. They might be able to log your master password and some of the passwords you use while the key logger is active, but so long as they don't have physical access to your key, they still can't dump all your passwords. Unfortunately yubi keys are a lot harder to backup and you have to rely on their 3rd party authentication service to get the most out of it. But we could get the best of both worlds if we could add a button to the usb armory.

The yubi key provides a single specific functionality which is not comparable to the full spectrum of applications that can be executed *on* the USB armory itself.

 

Would it be possible to connect a button to the gpio pins?

Yes.

 

One other thing that for example the nitrokey has is it's 'tamper proof' usb casing. This was also asked during the Q/A after your 31c3 talk by one of the guys and you suggested they prototype a case and sell it. So I guess we as a community could do this. But I'd be perfect if the usb armory were sold with a tamper proof case with a small button in it.

Tamper proofing is not an issue on the USB armory, there is no persistent storage on the board and removable storage (microSD) must be encrypted rather than relying on "tamper proofing" to ensure maximum security.

 

I guess the answer to my question could be to use rfc 4226 OTP passwords with the password manager which reduces the problem of a key logger quite a bit but aside from the lack of support for it, it still doesn't render a key logger 100% unusable like a physical button would. It can still get authentication tokens at any time without physical access to the device.

A button is no substitute for a passphrase, you are mixing and matching different concepts and applications here. Please make a specific use case example to discuss this further, however I hope I have answered your concerns already.

 

Thanks for the feedback!

I'm aware that a button is no substitute for a passphrase, I'm thinking more of it as an addition to a passphrase. Scenario:

I run a password manager application on my usb armory that is accessible over ethernet cdc. My password manager has ~100 logins stored for a wide range of things, i.e; banking, forums, user accounts, backup passphrases. A lot of these credentials I only need to access very infrequently, for example backup passphrases or encryption passwords for servers that only reboot once every 6 months. In the password manager application on my usb armory I can request the password I need, type in the master passphrase and get access to it.

Attack scenario 1: I am compromised by a keylogger and it takes me a month to notice this. This keylogger logs my master passphrase. It can now dump all my ~100 logins in 1 go, since the passphrase is the only thing protecting all those logins.

Attack scenario 2: I need to access some random forum on an untrusted pc that has a keylogger installed. This keylogger logs my master passphrase, it now dumps all my ~100 logins.

Now say I have a usb armory that has a physical button on it. I can then write a password manager application that works exactly the same, except for every request for access to a password in addition to typing in my master passphrase, I have to touch the physical button on the device. Even if your passphrase gets logged, they can't simply dump all passwords from the device because the keylogger can't press the button. Those scenario's would then play out as follows:

Attack scenario 1: It only logs my master passphrase + say ~10-20 most frequently used passwords. But it can't extract any of the other passwords from the password database that haven't been used during that month.

Attack scenario 2: it only logs my master passphrase + the random forum password, nothing else can be extracted from the database.

The reason I've been wary towards password managers is because a single compromise screws up everything. Keys to the kingdom. Which is why I'm interested in devices like the usb armory, but even those are still quite vulnerable to that keys to the kingdom issue. The physical button makes it exponentially harder for malware to simply dump all passwords. You could also integrate it into pgp signing, since malware that logs the encryption passphrase of your pgp private key could then sign stuff on my machine (ok, they won't be able to extract the private key from the usb armory, but they can still sign things on my computer) by requesting the user to touch the phsyical button in addition to the passphrase you're making this also a lot harder.

So essentially with a button the usb armory you could create 2FA for the usb armory, something you know: passphrase of which ever application that runs on the usb armory + something you have, physical access to your usb armory.

I hope this more clearly explains why I think adding a button would be very good for security and I'd love to hear your thoughts on this.

Kind Regards,
Robert Sevat

[mathieu...@gmail.com]

(campaign backer and hackaday writer about the usbarmory here)

It's nice to see that we end up describing how the Mooltipass actually works.

Just a side note about yubikey and related devices: given that there's no screen on the device itself you can't actually check what request you're approving. I wonder if it'd be possible for a malicious program to actually "slip" a request just before an application makes one. 

The user would end up approving the malicious request and would only guess that the key is not normally functioning as his normal request isn't performed.

On a more general note, 2FAs always have a "critical" part where you set up your "partnership" between your key and the website/service, susceptible to a MIM attack. Though it'd be very tricky to do it if done through HTTPS, I just wanted to emphasize the fact that you can't have a perfect solution.

--
You received this message because you are subscribed to the Google Groups "USB armory" group.
To unsubscribe from this group and stop receiving emails from it, send an email to usbarmory+...@googlegroups.com.
To post to this group, send email to usba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/usbarmory/113c5169-af29-4452-a0da-2b898be093e8%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Andrea Barisani]

Mathieu is quite correct in saying that there is never going to be a perfect solution. It's all about balancing usability and the level of security the user needs. The advantage of the USB armory is that since it's just a standard Linux system it becomes quite easy for developers and users to implement/hack their preferred solution, at the same time we would like to lead the way with an acceptable compromise.

There are many ways to cut & paste a password in a manner that no keylogger or even screen capture malware would be able to detect, we need to decide if to focus on this or don't trust the USB host entirely.

Of course in the worst case scenario merely protecting the password is not enough, if we assume that the USB host is compromised then once session is established the password itself, depending on the specific website role, might become irrelevant. You can see where I'm going here.

We are pondering implementing a password manager that, forgetting the provisioning moment for a second, would act as a standard HTTP/HTTPS proxy that replaces dummy/placeholders passphrases on the fly with the actual ones stored on the USB armory. This would allow never leaking passwords to the USB host, again forgetting the provisioning moment. This would be relatively easy to implement as a squid plugin. Of course you would have to explicitly trust the TLS certificate that USB armory provides and trust it to perform correct TLS validation on your behalf (it might be possible to overlay/communicate TLS verification status via custom extension). This is an interesting possibility that some people might find appealing while others might find horrible and too convoluted.

Also keep in mind that the USB armory is powerful enough to export (via X forwarding) firefox for instance so that you can execute a browser directly on it and leverage on whatever built-in or add-on password manager.

This is just to illustrating that there are plenty of options and architectural decisions to make here, it's a (non trivial) matter to pick the correct balance of features and usability.

It would be nice not to re-invent the excellent Mooltipass (congrats btw!) ;) and provide something that leverages on the unique features of the USB armory in an innovative, KISS (Keep It Short and Simple) and secure manner.

All thoughts/preferences on any of the discussed approaches is welcome.

Thanks!

[syd2...@gmail.com]

How does the USB armory 2 factor security compare to the Trezor USB device? It has a small screen and 2 buttons and is said to be able to defeat keyloggers - and has received good reviews.

http://www.coindesk.com/review-bitcoin-vault-trezor-lives-name/

Also, can 2F authentication be used for user passwords on a computer? For example, a 2F authentication is used to login as the root user and issue commands. This makes it difficult for a hacker to steal the root password, so if a hacker breaks in they can only gain access to the system as a regular user and not root user. Or is 2F authentication just for signing in to websites and performing web transactions?