Secure yourself, Part 1: Air-gapped computer, GPG and smartcards | Hacker News Reader

Secure yourself, Part 1: Air-gapped computer, GPG and smartcards

viccuad.me

171 pointsviccuad58 comments

I would enjoy a "pragmatic security" article about how individuals could adopt enterprise-standard security without too much technical knowledge or additional hardware. This could target freelancers or travelers, but I think that there are a lot of engineers who want to secure their personal laptop in a manner similar to their company laptop.

Some ideas:

* Disk encryption

* Always-on VPNs, like Cloak

* Encrypting DNS

* 1Password and proper secret management

* Privacy screens (e.g. in coffee shops or on airplanes. Sounds stupid - but surprisingly important.)

* Two-step verification, both in software and hardware (Yubikey)

* Good browser extensions - e.g. https everywhere, ad blocking (for security purposes)

* USB condoms on all phone charger cables

etc.

author here: that's what I'm intending with this blog post series more or less; after 4 or 5 submissions I should be fairly close to that.

I've read so many different multi-factor authentication schemes, and they're often brilliant, but I've yet to come across one that would pass the "my grandpa could use it" usability test.

The holy grail for security, to me, will be something (an OS with it elegantly integrated for example) that the user has to try hard not to use, but doesn't feel like they're having an O'Reilly encryption book rammed down their gullet either.

I've only recently starting looking at this, but I think the Fido Alliance is doing good work in this direction:

https://fidoalliance.org/

"quite possible that this kind of device will be the norm in 10 years"

I want to believe this, but I just can't see people caring, ever. The worst has already happened. Edward Snowdon has exposed that government can, and does, look at you penis and we still don't care.

Looking at your penis is hardly the worst that can happen. People will really start to care when the data is used for a violent crackdown of a popular domestic political movement.

https://en.wikipedia.org/wiki/Palmer_Raids

Or you know, maybe they'll care about the violent crackdown part?

What is it about technology where people think the failure was information, not the bunch of dudes cracking you in the head with rifle butts, the legislators who approved the action and the public which votes them into office (including all the people who say they're so outraged with everything they'll just refuse to vote or engage with the political process - because yeah, that's sure showing them).

Well we are coming up on the hundred year anniversary of that so it could happen. I try to get my grandma to use encryption but she won't.

Why would you even care if this was standard or not. People value their privacy differently.

i dunno. you should be asking US companies are they feeling any impact in sales to non US companies, before drawing any conclusions.

When's the Part 2 gonna be published?

Will there be a blog post about using gpg-agent as a ssh-agent? :)

BTW, Androids openkeychain supports fully yubikey neo, this is a great addition to using the pass(1) on from mobile with yubikey neo.

https://github.com/zeapo/Android-Password-Store http://www.openkeychain.org/

For a little while, I used a YubiKey NEO-n as an OpenPGP smartcard, with gpg-agent running as an ssh-agent (so that my SSH key was only present on my smartcard).

While great in theory, the authentication time made it totally impractical to connect to multiple servers at once.

I know this doesn't invalidate the general idea of using gpg-agent as ssh-agent -- just an anecdote.

Can you elaborate on 'authentication time made it totally impractical' ?

Does this mean it was slow? I'm using gpg-agent on osx with a neo-n to ssh into boxes and it's not noticeably slow.

Thinking on this again now, perhaps using a shorter key (I'm sure I would have chosen 4k RSA) would have helped. Regardless, I did find that connecting to 50+ hosts at the same time, most of them would hit my 3 second connect timeout with the neo-n and gpg-agent.

This is a somewhat unusual use-case, I will grant, but I also found a somewhat-noticeable delay in connecting to a single server, on the order of several hundred milliseconds.

I wonder if it would all be fine with a 2k key.

I might be mistaken, but I think Yubikeys only support 2k keys? I'm reasonably sure mine does anyway.

I got this just this second on my debian8 system.

:~$ time ssh an6n@mybox exit

real 0m1.910s

user 0m0.024s

sys 0m0.000s

Could you also list timings with just regular ssh-agent?

I will not give up on this setup, minus the Yubikey (would love to one day), but it recently broke it when I updated via F-Droid, and it has not been the same since.

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

Still, the only password manager simple enough that I can understand it and will actually use.

http://git.zx2c4.com/password-store/

author here: All of that should be on Part 2, in a week or so.

Part 2 will cover emails (Thunderbird, mutt), pass as a password store, setting up OpenKeychain + a Yubikey Neo on an Android phone, K-9 Mail on Android, Yubico authenticator for Android as a 2-step auth, ssh, and Keybase. Future parts would cover hdd encryption via LUKS, authentication for sudo and more, GPG by NFC on your desktop, GPG intents to open doors, etc.

The airgapped computer loads propriety Chinese blobs to boot and is pulling it's encryption software over the network via HTTP.

Sure, but what code is the sd card running? All sd cards have drm protection (which interestingly, hasn't been cracked) and memory that isn't user accessible (see wikipedia), as part of the standard. And they are riddled with security vulnerabilities that allow remote code execution on them ( see http://www.bunniestudios.com/blog/?p=3554).

I mean that's a level of paranoia I usually don't hold to, but if you are going to go all out, I have to wonder if there is a more secure form of non volatile memory.

Those instructions don't load any proprietary binary blobs - the boot loader is an unmodified official release of u-boot that you can compile yourself. The only things you need blobs for on this era of Allwinner hardware are 3D acceleration and hardware video decode/encode.

author here: No, I'm using no blobs; just the mainline Kernel and U-Boot. All the software stack is leveraged on Debian.

My mistake. They've released their u-boot source and you aren't loading the binary video drivers.

Verify package signatures via air-gapped machine prior to install, they did mention downloading to usb using another machine.

I'm a little worried about generating a new "master" RSA key nowadays, since it seems like ECC is right on the horizon of going mainstream. I would generate a new Ed25519 key today with GPG 2.1, but Curve25519 encryption isn't supported yet (only signing is). Does anyone else have the same feeling of apprehension?

going full ECC now will isolate you: a lot of people don't use gpg 2.1. Additionally, a lot of people are reluctant to use ECDSA, and would only use EdDSA.

I honestly think RSA is a good decision for now.

You can always add subkeys of any type (your primary key is the core of your certificate and is your cryptographic identity though).

There's no reason you can't transition from a master RSA key to a master DSA key?

A good walk through, and of course a sad reminder that even simple public key cryptography still has crap tooling. There should be some kind of x-prize for making tools that lets anyone communucate securely withiut walking through what looks like a 1999 gentoo install.

Collect some friends to pool money and kick off this prize yourself. From the makers of the XPRIZE: https://herox.com/

Here's a 2014 paper from Qubes, http://www.invisiblethingslab.com/resources/2014/Software_co...

"Many people believe the Holy Grail of secure isolation is to use two or more physically separate machines. This belief seems so natural, that we often don't give it much thought. After all, what better isolation could we possible get than physical "airgap"?

I would like to discuss two exemplary scenarios involving isolation: one for securing the Tor process and another for securing email operations, and compare the pros and cons of using the physical isolation vs. the software compartmentalization as currently possible on Qubes OS."

There's no contest between physical vs. virtual isolation. Theo de Raadt and @thegrugq are right when they're saying you shouldn't put much trust in virtualisation-as-isolation model. Just look at the recent VENOM bug.

How easy is it for somebody to get your PGP key off a yubikey if they stole it? In particular since physical devices can be fuzzed, etc, it might be worse than an encrypted keychain on device for some people?

The Yubikey NEO used the NXP a700x microcontroller family the last I checked (NEO-n might as well but I'm not sure).

You can read about the security features of the chip at NXP's website[1] to get a sense for what they're designed to defend against, but despite the very real possibility of a successful key retrieval attack on the card, in general it would be MUCH easier for an attacker to obtain your on-disk keychain files and figure out the password. Particularly if they don't want you to be aware the key has been compromised.

[1] http://www.nxp.com/products/identification_and_security/auth...

Smart cards/hardware tokens try to not make themselves easy targets, and many such microcontrollers have attempts (of varying success) to defend against limited degrees of physical access and make attacks evident. But in any case, given sufficient time and resources, the attacker will always win.

Bottom line: It depends largely on who stole it and for how long - however, if someone knew enough to target stealing your hardware token/smart card, you are under targeted attack and your key's probably toast: revoke it.

I would also gently caution that the elliptic curve routines provided by NXP should not be used over special prime fields (elliptic curves that are fast in software, i.e. just about everything except Brainpool) as they abuse the large (RSA) multiplier whose side-channel blinding was not designed for non-random fields. (Unless they've rewritten it since I last saw it?)

After three pin attempts, the key is wiped.

I don't know how difficult it would be to obtain the key from the device. However, if you have a strong passphrase on the key itself, then even if an attacker obtained the key, there would not be a lot to worry about. Just revoke it and move on. They'll likely never guess the passphrase.

The passphrase you set on a GPG private key only applies to keys stored on-disk in the keychain or exported from the keychain. Once you import one into a Yubikey or other OpenPGPCard device, there is no passphrase anymore, you're relying on the card itself to protect it against side-channel attacks, prevent unauthorized or insecure export of the key (Yubikeys don't allow this at all though), and authorize the use of it via the PIN code.

Thanks for that explanation. I've never placed any of my GPG keys on a Yubikey. I just assumed that the key password remained.

If you're that confident in your pass-phrase, you could just push your private key to github. Might want to consider that there is some overlap between being able to steal your yubi-key, and being able to install a hardware (or software) key logger...

Doesn't Allwinner board require blobs to boot?

Author here: No. I'm just using the mainline Kernel with Simple Framebuffer support, and U-Boot. U-Boot does the booting, yet there is firmware on the Soc for the first stage booting.

2 rpis with key transfer and cyphertext transmitted over Rx/Tx. Air gapped is the only place you ever have plaintext. Cheap, small, and relatively easy to implement, but if a system like this fits somewhere in how you deal with your threat model, then your opsec is probably already compromised.

Good write up. It'd be good to publish md5 hashes of the files you recommend to download.

This guide doesn't take into account side-channel attacks.[0]

[0]http://en.wikipedia.org/wiki/Side-channel_attack

Let's get a superconducting Faraday cage for this tutorial.

That, some mylar[0], and a blanket[1]!

[0]http://i.imgur.com/kdNOe5u.jpg (founder of thepiratebay.org)

[1]http://security.stackexchange.com/a/82374 (Snowden)

I'd like to be notified of subsequent parts but the atom feed is broken: http://viccuad.me/atom.xml

Fix please?

Author here: oh god, nice catch. will fix it :)

edit: fixed

Perfect - thank you.

Simpler version is to encrypt root partition and have kernel with boot loader on separate sd card or usb flash drive.

I used to run this until I couldn't ignore that it was pointless because it offloads the attack vector to something I can easily lose, have taken or replaced.

Or someone could come in an pop in a drive with their own kernel.

Nevermind the reality that I'd never completely follow through with the security measures needed on a personal machine. I'd just be giving myself an active role in my home's security theater.

I just encrypt my home folder and don't trust machines/networks for important things.

The card also contains certificate protected by password.

Your initial comment was a bit brief; Now I realize you meant "just use full disk encryption/luks with the bootloader and boot-partion on a removable device -- to lessen the chances that the password prompt has been modified to capture your password (back-door bootloader, backdoor kernel/initrd)".

Still somewhat vulnerable to a replaced BIOS and/or a hardware key logger (I gather the idea is: I can keep my usb key safe easier than my laptop. I'm not sure if that's true in a meaningful way).

Very nice guide, but a couple of things:

1) No mention of full-disk encryption on both machines. This is trivial, and especially with flash-storage I consider it mandatory. There's hardly any reason not to do fde.

This protects data at rest, and makes the system(s) somewhat tamper proof. You're still counting on the BIOS and keyboard to be safe (not booting into a vm, no hardware keylogger) -- but at least it makes it a little harder to compromise the system.

One could use/add the neo passphrase to the boot procedure, but it is easy to copy (just get hold of the neo, plug it in, push button) -- and there's no way to know the key has been compromised.

With a manually entered pass phrase, the input path needs to be compromised (eg: hardware key logger). In many theat scenarios the two are similar -- but there's a difference between someone lifting the yubikey for 10 seconds when you're passed out at a party, and someone breaking-and-entering to your apartment and installing a hw key logger/bios back door etc.

2) I've been running FDE/LUKS on my laptop(s) -- and have been considering to add a passphrase on an usb dongle (I don't have a yubikey neo, and my old yubikey II that I got as a promo seem to have stopped working, the button does nothing -- not sure why). This is a trade-off, as anything else.

The constraint of having to be able to type in a pass phrase blindly (and quickly), does not mix well with having a pass phrase that is at least equivalent to a 128 bit random key. If you just want a random phrase of lower-case letters (easier to touch type, don't have to remember where capital letters go/avoid errors with shift) you need ~28 random characters (with a set of ~67 characters, you get down to ceiling(128/log2(67))=22 -- with more room for errors while typing)).

Another thing, is that any such "unlocked" key needs manual intervention to be removed. So if someone steals your laptop and your yubi/usb-key with a static passphrase/key -- they can be expected to gain access, and you can't do anything about it.

This is of course true if they capture your pass phrase with a keylogger before stealing the laptop as well (I wonder a bit about this account[1] from the DPR case -- if it is misinformation of incompetence -- but I'd assume the smartest thing to do was a sneak-and-peak warrant installing a hw key logger (or just a camera) in order to make sure that they had most of the passwords/pass phrases. Seems strange that they weren't able to obtain probable cause for that).

[1] http://www.wired.com/2015/05/silk-road-2/ (If TL;DR search for library)

Fix your RSS so feedly can find your most recent posts.

author here: fixed!

Obligatory xkcd: https://xkcd.com/538/

Reply on news.ycombinator.com