An NFC PGP SmartCard for Android | Hacker News Reader

An NFC PGP SmartCard for Android

grepular.com

71 pointsmike-cardwell18 comments

That looks quite nice. I do have the same Yubikey and use my subkeys like that - but via USB/on laptop and desktop.

For Android: I'd like to see support for this in Boxer. While I do prefer open software, K-9 has been quite unstable for me and has a terrible UX (ever noticed how server-side search is supposed to be used? Or the lack of any error messages at all?). Looking at a bacon/OnePlus One running 12s here the new client looks like a great improvement - but this is one feature I haven't found (or rather, that doesn't seem to exist).

After I installed 12s on my OnePlus One the other day, first thing I did was try Boxer against https://emailprivacytester.com/ - It failed on the link prefetch test. I reported it and they said they'd look into it. I've heard that the iOS version of Boxer fails quite badly but I've not tested that myself.

[edit] The main problem with K-9 Mail IMO, is that it only supports inline PGP. I.e, it doesn't have PGP/MIME support. It's open source, and there is a ~$1000 bug bounty for this functionality at https://www.bountysource.com/issues/815255-pgp-mime if anyone wants an Android project.

Thanks for the link to that test site - I didn't know about that.

As for K-9: Apart from doing calls I really just use my phone for mails and K-9 isn't the right choice for me, sadly. I would really love to use an open client, but while I can compromise on quite a bit (trying to migrate to a CM without any GApps is next on the list), a decent mail client is mandatory.

(Incidentally that's the reason why I can't use Fx OS so far, the situation is worse over there)

Interesting enough: Testing K-9 and Boxer on that site I get one violation in each. Boxer with a 'Link Prefetch' as you said, K-9 with a 'Meta refresh'

This setup also works with the ZX2C4 password store for android. It's superb :)

https://github.com/zeapo/Android-Password-Store

This was the main reason I picked up the yubikey, but I simply could not get GPG to recognize the yubikey to import my keys. I'm sure I simply missed some important step, but I couldn't figure it out with either GPG for windows or GPG in a linux VM.

I wish there more smart card devices available for use with PGP that were as widely purchasable as the yubikey.

The hardest part about getting the Yubikey to work, at least under Ubuntu, is dealing with the marriage to gnome-keyring. Uninstalling it and the associated autostart gpg-agent files (see http://www.bootc.net/archives/2013/06/09/my-perfect-gnupg-ss...) seems to do the trick. The documentation for doing this is _horrendous_

As long as the smartcard interface is enabled at all, it should 'just work'. You may need to do the initial pin reset, but otherwise Neo even comes with the pgp application preloaded.

There is a bug in the latest GPG version that makes it unable to detect smartcards.

2048 key limit kind of sucks though..

Even if the Yubikey supported larger RSA keys (3072 or 4096-bit), you might not want to use them. Decryption is quite slow with a 4096-bit key on a smartcard (for example, it takes ~5 seconds to decrypt with a 4096-bit key using a g10code smartcard), which seriously hampers usability. Increasing RSA key size also has diminishing security returns [0], so in an ideal world you'd be using ECC instead, to get a strong 256-bit security level with good performance. Unfortunately, both the OpenPGP smartcard spec and smartcard hardware need to be updated to add support for ECC (and who knows how long that might take).

It's worth noting that, while many people refer to the NIST guidelines that say that RSA 2048-bit keys are acceptable until 2030, NSA's Suite B doesn't include RSA at all and only recommends ECC. The problem is that the state of the art in open source cryptography software and hardware has not caught up to NSA in the 10 years since Suite B was published.

If you really want to use your Yubikey, a reasonable compromise might be to generate a 4096-bit RSA master key (stored offline), and put 2048-bit subkeys on your Yubikey, which you would want to rotate periodically. This gives you the benefits of a strong key for establishing your identity in the Web of Trust and the better performance characteristics of 2048-bit keys on smartcards. The downside is a higher upfront setup cost, and periodic maintenance cost on both your part and on the part of the people you communicate with, since you will want to rotate your subkeys and they will need to refresh their copy of your key whenever you do that.

Given what we know from the Snowden documents, spy agencies seem to attack endpoint security often and don't seem to be able to crack commonly used encryption schemes, including RSA (although they can almost certainly factor 1024-bit keys, given current estimates for the costs of such an operation). Therefore, the improved endpoint security afforded by using a GPG smartcard might make using a smaller key size a worthwhile tradeoff.

On the other hand, GPG does not provide forward secrecy, so while it's important to rotate keys and delete old messages as much as possible as part of OPSEC for your local machine, if NSA is capturing your GPG messages from the wire for later decryption, you'd probably want to prefer using the strongest keys possible. This is an area where increased StartTLS deployment (especially with forward secure ciphersuites) can help.

Finally, it's important to note that when you argue in favor of 4096-bit keys over 2048-bits keys, you are saying "I believe my adversary can factor a 2048-bit RSA key, but not a 4096-bit RSA key". If your adversary can factor a 2048-bit RSA key, and they really want to read the email that's been encrypted with your 4096-bit key, I would argue there are a lot of options available to them, such as:

1. MITM a software update for your mail client or operating system. It depends on the specifics of your system, but many systems today use 2048-bit (or weaker) keys for authenticating software updates.

2. MITM any website you visit (most CA's have 2048-bit roots, so it doesn't even matter if all the sites you visit have 4096-bit keys) and use a browser exploit to deliver some malware that exfiltrates your email when you decrypt it.

[0]: https://www.yubico.com/2015/02/comparing-asymmetric-encrypti...

The final part of your post is fundamentally flawed. You are saying that if one part of your trust chain is limited to a certain security level, then it makes no sense to make any part stronger. Following this practice would make security a lot worse. One example result of your reasoning is "As long as there are 1024-bit root CA's I don't encrypt anything because I could be MITM anyway".

> You are saying that if one part of your trust chain is limited to a certain security level, then it makes no sense to make any part stronger.

Security is only as strong as the weakest link. My argument is that if your adversary is powerful enough to factor an RSA-2048 bit key (but cannot factor an RSA-4096 bit key), then it is likely they would also be powerful enough to compromise your data via one of the "weaker links" that I described, rendering the stronger key worthless.

I am not saying that it makes no sense to make any part stronger, just reminding you that crypto is not magic security dust and bigger keys don't necessarily make you safer in the context of an exploitable endpoint environment.

The goal of this final part was to reinforce my argument that the security benefits of using a smartcard outweigh the benefits of using larger RSA keys, and so I am encouraging the use of a Yubikey as a GPG smartcard despite the limitation of only allowing up to 2048-bit keys. Hopefully they will support larger keys and/or ECC in the future and we can all switch to that when it is available.

Does anyone know of a reasonably priced (or unreasonably priced, for that matter) smartcard that can do ECC of any kind? ECC25519?

doesnt seem to work for ed25519 keys :(

As far as I know the blocker is that ed25519 is not in the openpgp standard. If that's wrong, please provide source.

That's the big blocker - but, without wishing to be too mean to NXP (sorry Joppe!), the A700x MX51 microcontroller used in the YubiKey Neo is pretty old. Really, most crypto chips are at their core: they almost always just make them out of old ones with new bits glued on to (reasonably) try to reduce (high) NIST/etc certification costs. (Seriously, it's still carting a hardware DES implementation around.)

I believe it has a 2048-bit multiplier with a particular (patented?) form of blinding to protect against side-channel attacks. That's used for RSA; it can't do 3072/4096 bit RSA keys without tricks as it stands unfortunately.

The existing NXP ECC implementation is also not in JCOP's applets by default, I think? From what I saw, it (ab)uses the RSA multiplier. That can go up to 320 bit curves in theory without running out of scratch space, and is a generic implementation of prime fields over GF(p), so you'd think it'd be able to do some operations on Curve25519 fine in principle.

And it can, but in my testing it did what I thought it'd do, and leaked side-channels when used with the NIST curves and djb's curves, because the blinding on the RSA multiplier was simply not designed to cope with the regular structure of the special prime fields that most elliptic curves use. And the performance of random prime fields (like Brainpool) in software is awful, so no-one else wants to use those.

You've also got the problem that the existing implementation there can only do ECDSA (not the EdDSA used by Ed25519) and doesn't have SHA-512 around, too.

A pure software implementation that avoids using the RSA multiplier would be much safer, and I think in principle would be able to do the other CFRG favourite, Ed448-Goldilocks, as well. That is what some HSM vendors are doing. It'd be a very tight fit on the NXP A700x, however. I'll leave that to NXP, if they want to.

I myself want an open crypto chip, not one that still needs blobs in 2015. And I've seen a few movements in that direction.

> I myself want an open crypto chip, not one that still needs blobs in 2015. And I've seen a few movements in that direction.

Who's working on this? Anyone else than the team behind cryptech.is?

A good, open, microcontroller design with no caches, USB (or something), a TRNG, an onboard voltage/clock regulator, registers/RAM which zeroises on faults/parity/intrusion sensors, a fresh approach to avoiding SPA/DPA attacks, some EEPROM (also with parity & zeroisation traps), and ideally a way for a host to automatically read (/audit) all the software running on it (Harvard arch?) would do the trick. It doesn't have to be fast, but it does have to be safe.

I gave it a try, but it really needs someone with actual ASIC design experience instead, I think! I'd love to see one of the vendors do something like that - as you can see there are plenty of waiting customers, but I'm not holding my breath.

Cryptech are probably the strongest contenders for now?

Reply on news.ycombinator.com