A commercial-grade AVR or ARM controller is unfit to be used in a security product. In most cases, these controllers are easy to attack, from breaking in via a debug/JTAG/TAP port to probing memory contents. Various forms of fault injection and side-channel analysis are possible, sometimes allowing for a complete key recovery in a shockingly short period of time.While I understand those concerns, they eventually come down to the trust you have in an organization. Not only do we have to trust Yubico, but also hardware manufacturers and designs they have chosen. Every step in the hidden supply chain is then trusted to make correct technical decisions and not introduce any backdoors. History, unfortunately, is not on Yubico's side: Snowden revealed the example of RSA security accepting what renowned cryptographer Bruce Schneier described as a "bribe" from the NSA to weaken its ECC implementation, by using the presumably backdoored Dual_EC_DRBG algorithm. What makes Yubico or its suppliers so different from RSA Security? Remember that RSA Security used to be an adamant opponent to the degradation of encryption standards, campaigning against the Clipper chip in the first crypto wars. Even if we trust the Yubico supply chain, how can we trust a closed design using what basically amounts to security through obscurity? Publicly auditable designs are an important tradition in cryptography, and that principle shouldn't stop when software is frozen into silicon. In fact, a critical vulnerability called ROCA disclosed recently affects closed "smartcards" like the YubiKey 4 and allows full private key recovery from the public key if the key was generated on a vulnerable keycard. When speaking with Ars Technica, the researchers outlined the importance of open designs and questioned the reliability of certification:
Our work highlights the dangers of keeping the design secret and the implementation closed-source, even if both are thoroughly analyzed and certified by experts. The lack of public information causes a delay in the discovery of flaws (and hinders the process of checking for them), thereby increasing the number of already deployed and affected devices at the time of detection.This issue with open hardware designs seems to be recurring topic of conversation on the Gnuk mailing list. For example, there was a discussion in September 2017 regarding possible hardware vulnerabilities in the STM MCU that would allow extraction of encrypted key material from the key. Niibe referred to a talk presented at the WOOT 17 workshop, where Johannes Obermaier and Stefan Tatschner, from the Fraunhofer Institute, demonstrated attacks against the STMF0 family MCUs. It is still unclear if those attacks also apply to the older STMF1 design used in the FST-01, however. Furthermore, extracted private key material is still protected by user passphrase, but the Gnuk uses a weak key derivation function, so brute-forcing attacks may be possible. Fortunately, there is work in progress to make GnuPG hash the passphrase before sending it to the keycard, which should make such attacks harder if not completely pointless. When asked about the Yubico claims in a private email, Niibe did recognize that "it is true that there are more weak points in general purpose implementations than special implementations". During the last DebConf in Montreal, Niibe explained:
If you don't trust me, you should not buy from me. Source code availability is only a single factor: someone can maliciously replace the firmware to enable advanced attacks.Niibe recommends to "build the firmware yourself", also saying the design of the FST-01 uses normal hardware that "everyone can replicate". Those advantages are hard to deny for a cryptographic system: using more generic components makes it harder for hostile parties to mount targeted attacks. A counter-argument here is that it can be difficult for a regular user to audit such designs, let alone physically build the device from scratch but, in a mailing list discussion, Debian developer Ian Jackson explained that:
You don't need to be able to validate it personally. The thing spooks most hate is discovery. Backdooring supposedly-free hardware is harder (more costly) because it comes with greater risk of discovery. To put it concretely: if they backdoor all of them, someone (not necessarily you) might notice. (Backdooring only yours involves messing with the shipping arrangements and so on, and supposes that you specifically are of interest.)Since that, as far as we know, the STM microcontrollers are not backdoored, I would tend to favor those devices instead of proprietary ones, as such a backdoor would be more easily detectable than in a closed design. Even though physical attacks may be possible against those microcontrollers, in the end, if an attacker has physical access to a keycard, I consider the key compromised, even if it has the best chip on the market. In our email exchange, Niibe argued that "when a token is lost, it is better to revoke keys, even if the token is considered secure enough". So like any other device, physical compromise of tokens may mean compromise of the key and should trigger key-revocation procedures.
There we see the performance of the four keycards I tested, compared with the same operations done without a keycard: the "CPU" device. That provides the baseline time of GnuPG decrypting the file. The first obvious observation is that using a keycard is slower: in the best scenario (FST-01 + ECC) we see a four-fold slowdown, but in the worst case (also FST-01, but RSA-4096), we see a catastrophic 200-fold slowdown. When I presented the results on the Gnuk mailing list, GnuPG developer Werner Koch confirmed those "numbers are as expected":
Algorithm Device Mean time (s) ECDH-Curve25519 CPU 0.036 FST-01 0.135 RSA-2048 CPU 0.016 YubiKey-4 0.162 Nitrokey-Pro 0.610 YubiKey-NEO 0.736 FST-01 1.265 RSA-4096 CPU 0.043 YubiKey-4 0.875 Nitrokey-Pro 3.150 FST-01 8.218
With a crypto chip RSA is much faster. By design the Gnuk can't be as fast - it is just a simple MCU. However, using Curve25519 Gnuk is really fast.And yes, the FST-01 is really fast at doing ECC, but it's also the only keycard that handles ECC in my tests; the Nitrokey Start and Nitrokey HSM should support it as well, but I haven't been able to test those devices. Also note that the YubiKey NEO doesn't support RSA-4096 at all, so we can only compare RSA-2048 across keycards. We should note, however, that ECC is slower than RSA on the CPU, which suggests the Gnuk ECC implementation used by the FST-01 is exceptionally fast. In discussions about improving the performance of the FST-01, Niibe estimated the user tolerance threshold to be "2 seconds decryption time". In a new design using the STM32L432 microcontroller, Aurelien Jarno was able to bring the numbers for RSA-2048 decryption from 1.27s down to 0.65s, and for RSA-4096, from 8.22s down to 3.87s seconds. RSA-4096 is still beyond the two-second threshold, but at least it brings the FST-01 close to the YubiKey NEO and Nitrokey Pro performance levels. We should also underline the superior performance of the YubiKey 4: whatever that thing is doing, it's doing it faster than anyone else. It does RSA-4096 faster than the FST-01 does RSA-2048, and almost as fast as the Nitrokey Pro does RSA-2048. We should also note that the Nitrokey Pro also fails to cross the two-second threshold for RSA-4096 decryption. For me, the FST-01's stellar performance with ECC outshines the other devices. Maybe it says more about the efficiency of the algorithm than the FST-01 or Gnuk's design, but it's definitely an interesting avenue for people who want to deploy those modern algorithms. So, in terms of performance, it is clear that both the YubiKey 4 and the FST-01 take the prize in their own areas (RSA and ECC, respectively).
In practice smart card security has been proven to work well (at least if you use a decent smart card). Therefore the Nitrokey Pro should be used for high security cases. If you don't trust the smart card or if Nitrokey Start is just sufficient for you, you can choose that one. This is why we offer both models.So far, I have created a signing subkey and moved that and my authentication key to the YubiKey NEO, because it's a device I physically trust to keep itself together in my pockets and I was already using it. It has served me well so far, especially with its extra features like U2F and HOTP support, which I use frequently. Those features are also available on the Nitrokey Pro, so that may be an alternative if I lose the YubiKey. I will probably move my main certification key to the FST-01 and a LUKS-encrypted USB disk, to keep that certification key offline but backed up on two different devices. As for the encryption key, I'll wait for keycard performance to improve, or simply switch my whole keyring to ECC and use the FST-01 or Nitrokey Start for that purpose.
[The author would like to thank Nitrokey for providing hardware for testing.] This article first appeared in the Linux Weekly News.
#! /bin/sh generate_change_file() local version=$(dpkg-parsechangelog -Sversion) local package=$(dpkg-parsechangelog -Ssource) echo "Generating source changes file" dpkg-genchanges -S > ../$ package _$ version _source.changes cd /tmp/buildd/*/debian/.. generate_change_fileNext time you build a package, you should find, alongside the <package>_<version>_<arch>.changes file, a <package>_<version>_source.changes which you can use with usual tools (lintian, debsign, dput ) to upload it to the Debian archive. Note that if you do that, you have to make sure that your debian/rules support building separately the arch-dependent and arch-independant packages. To check that, you can call pdebuild like this:
pdebuild --debbuildopts -A # binary-only build, limited to arch-independant packages pdebuild --debbuildopts -B # binary-only build, limited to arch-dependant packages
wpa_supplicant -iwlan0 -c wpa_supplicant.conf
scan_resultsand identity the bssid of the Livebox
wps_pbc <bssid>; some text should appear in the wpa_cli window, and it should eventually connect successfully (at that point you can even run a dhclient on wlan0)
mkdir linux-grsec && cd linux-grsec git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git git clone git://anonscm.debian.org/users/corsac/grsec/debian-grsec-config.git mkdir build cd linux-stable ../debian-grsec-config/bin/get-grsec.sh stable2 # for 3.14 branch ../debian-grsec-config/bin/kconfig.py ../build/.config ../debian-grsec-config/configs/config-3.14-2-amd64 ../debian-grsec-config/configs/hardening ../debian-grsec-config/configs/grsec make KBUILD_OUTPUT=../build -j4 oldconfig make KBUILD_OUTPUT=../build -j4 deb-pkgThen you can use the generated Debian binary packages. If you use the Debian config, it'll need a lot of disk space for compilation and generate a huge linux-image debug package, so you might want to unset CONFIG_DEBUG_INFO locally if you're not interested. Right now only the deb files are generated but I've submitted a patch to have a .changes file which can be then used to manipulate them more easily (for example for uploading them a local Debian repository). Note that, obviously, this is not targeted for inclusion to the official Debian archive. This is still not possible for various reasons explained here and there, and I still don't have a solution for that. I hope this (either the scripts and config or the generated binary packages) can be useful. Don't hesitate to drop me a mail if needed.
Mar 25 22:10:13 lxc-sync login: pam_loginuid(login:session): Cannot open /proc/self/loginuid: Read-only file system Mar 25 22:10:13 lxc-sync login: pam_loginuid(login:session): set_loginuid failed Mar 25 22:10:13 lxc-sync login: pam_unix(login:session): session opened for user root by LOGIN(uid=0) Mar 25 22:10:13 lxc-sync login: Cannot make/remove an entry for the specified sessionThe last message isn't too useful, but the first one gave the answer. Since LXC isn't really ready for security stuff, I have some hardening on top of that, and one measure is to not have rw access to /proc. I don't really need pam_loginuid there, so I just disabled that. I just need to remember to do that after each LXC upgrade. Other than that, I have to boot using SystemV init, since apparently systemd doesn't cope too well with the various restrictions I enforce on my LXCs:
lxc-start -n sync Failed to mount sysfs at /sys: Operation not permitted(which is expected, since I drop CAP_SYS_ADMIN from my LXCs). I didn't yet investigate how to stop systemd doing that, so for now I'm falling back to SystemV init until I find the correct customization:
lxc-start -n sync /lib/sysvinit/init INIT: version 2.88 booting [info] Using makefile-style concurrent boot in runlevel S. hostname: you must be root to change the host name mount: permission denied mount: permission denied [FAIL] udev requires a mounted sysfs, not started ... failed! failed! mount: permission denied [info] Setting the system clock. hwclock: Cannot access the Hardware Clock via any known method. hwclock: Use the --debug option to see the details of our search for an access method. [warn] Unable to set System Clock to: Wed Mar 25 21:21:43 UTC 2015 ... (warning). [ ok ] Activating swap...done. mount: permission denied mount: permission denied mount: permission denied mount: permission denied [ ok ] Activating lvm and md swap...done. [....] Checking file systems...fsck from util-linux 2.25.2 done. [ ok ] Cleaning up temporary files... /tmp. [ ok ] Mounting local filesystems...done. [ ok ] Activating swapfile swap...done. mount: permission denied mount: permission denied [ ok ] Cleaning up temporary files.... [ ok ] Setting kernel variables ...done. [....] Configuring network interfaces...RTNETLINK answers: Operation not permitted Failed to bring up lo. done. [ ok ] Cleaning up temporary files.... [FAIL] startpar: service(s) returned failure: hostname.sh udev ... failed! INIT: Entering runlevel: 2 [info] Using makefile-style concurrent boot in runlevel 2. dmesg: read kernel buffer failed: Operation not permitted [ ok ] Starting Radicale CalDAV server : radicale.
grep -l 'libssl.*deleted' /proc/*/maps tr -cd 0-9\\n xargs -r ps u Some people seem to indicate that the 64kB leak can enable an attacker to get pretty much anything from the process memory space, including the certificate private key. While we weren't able to confirm that yet, that's not really impossible, so you might also want to regenerate those private keys, although that's not something you should do in a rush either.
corsac@scapa: gpg --edit-key 71ef0ba8 gpg (GnuPG) 1.4.14; Copyright (C) 2013 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Secret key is available. pub 4096R/71EF0BA8 created: 2009-05-06 expires: never usage: SC trust: ultimate validity: ultimate sub 4096g/36E31BD8 created: 2009-05-06 expires: never usage: E sub 2048R/CC0E273D created: 2012-10-17 expires: 2013-10-27 usage: A sub 2048R/A675C0A5 created: 2012-10-27 expires: 2013-10-27 usage: S sub 2048R/D98D0D9F created: 2012-10-27 expires: 2013-10-27 usage: E [ultimate] (1). Yves-Alexis Perez <email@example.com> [ultimate] (2) Yves-Alexis Perez (Debian) <firstname.lastname@example.org> gpg&> key 2 pub 4096R/71EF0BA8 created: 2009-05-06 expires: never usage: SC trust: ultimate validity: ultimate sub 4096g/36E31BD8 created: 2009-05-06 expires: never usage: E sub* 2048R/CC0E273D created: 2012-10-17 expires: 2013-10-27 usage: A sub 2048R/A675C0A5 created: 2012-10-27 expires: 2013-10-27 usage: S sub 2048R/D98D0D9F created: 2012-10-27 expires: 2013-10-27 usage: E [ultimate] (1). Yves-Alexis Perez <email@example.com> [ultimate] (2) Yves-Alexis Perez (Debian) <firstname.lastname@example.org> gpg> expire Changing expiration time for a subkey. Please specify how long the key should be valid. 0 = key does not expire <n> = key expires in n days <n>w = key expires in n weeks <n>m = key expires in n months <n>y = key expires in n years Key is valid for? (0) 429d Key expires at mar. 28 oct. 2014 12:43:35 CET Is this correct? (y/N) yAt that point, a pinentry dialog should ask you the PIN, and the smartcard will sign the subkey. Repear for all the subkeys (in my case, 3 and 4). If you ask for PIN confirmation at every signature, the pinentry dialog should reappear each time. When you're done, check that everything is ok, and save:
gpg> save corsac@scapa: gpg --list-keys 71ef0ba8 gpg: checking the trustdb gpg: public key of ultimately trusted key AF2195C9 not found gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model gpg: depth: 0 valid: 4 signed: 5 trust: 0-, 0q, 0n, 0m, 0f, 4u gpg: depth: 1 valid: 5 signed: 53 trust: 5-, 0q, 0n, 0m, 0f, 0u gpg: next trustdb check due at 2013-12-28 pub 4096R/71EF0BA8 2009-05-06 uid Yves-Alexis Perez <email@example.com> uid Yves-Alexis Perez (Debian) <firstname.lastname@example.org> sub 4096g/36E31BD8 2009-05-06 [expires: 2014-10-28] sub 2048R/CC0E273D 2012-10-17 [expires: 2014-10-28] sub 2048R/A675C0A5 2012-10-27 [expires: 2014-10-28] sub 2048R/D98D0D9F 2012-10-27 [expires: 2014-10-28]Now that we have the new subkeys definition locally, we need to push it to the keyservers so other people get it too. In my case, I also need to push it to Debian keyring keyserver so it gets picked at the next update:
corsac@scapa: gpg --send-keys 71ef0ba8 gpg: sending key 71EF0BA8 to hkp server subkeys.pgp.net corsac@scapa: gpg --keyserver keyring.debian.org --send-keys 71ef0ba8 gpg: sending key 71EF0BA8 to hkp server keyring.debian.orgMain smartcard now back in safe place. As far as I can tell, there's no operation needed on the daily smartcard (which only holds the subkeys), but you will need to refresh your public key on any machine you use it on before it gets the updated expiration date.