Verifying downloads

Last week I stumbled across a post from last year, where somebody described how it was impossible to download an important infrastructure program securely on Windows. My first reaction was of course to pity the poor souls that are still stuck with Windows. How easy is it to just type apt-get install and have all the downloading and validation and installation conveniently handled for you.

Today I was going to set up my new server. First I downloaded the current iso file from ubuntu.com. Before installing it onto an USB stick, I thought about this blog post again. Actually I should validate this ISO! I knew before, but I usually didn’t bother. So I gave it a try. I had to search a bit for it on the download page. The easiest is if you manually pick a mirror. Then you will find the hash sum files in the index page. Some websites along the way were encrypted, others were not. The downloads themselves were not. But that didn’t matter since the hashes were GPG signed. I don’t have to do this all too often, so I  just followed the community howto. My downloaded iso file was valid, so I moved on installing it.

The hardware is actually from computer-discount.ch. For quite some time I was searching for ways to buy computer equipment with BitCoin. The American big name tech companies that accept BitCoin either do it only outside of central Europe, or don’t deliver here. So I was quite excited to find this company from Ticino. The experience so far is very good.

connecting home securely

It has been probably close to a decade that I run a small server at home. At first it was only because I could not find a web hosting company that would serve my fcgi libwt apps at an affordable price. Then I added this blog to it. In the meantime I added a lot of other stuff as well. One of the more important things became ssh. Not only for remote shell sessions, but also for securely copying files and tunneling. In fact I use ssh tunnels instead of a more traditional VPN.

Discovery

Static IP addresses are expensive in Switzerland. So I used dyndns from the start. At first the free offering, and then switched to a paid plan long before they discontinued the free offering. Just last week I received a note that they grabed the annual fee from my (scheduled to be deactivated) credit card. Generally I strongly dislike services that automatically grab money from my accounts. They didn’t even mention that the fee doubled. That’s one side of the story, the other is that dyndns is an American company. They could take my domain name hostage without even telling me.  So there has to be a better alternative. In fact there is one. It’s good technology wise, but not generally available to the unintroduced yet.

DyName for namecoin

I wrote about namecoin in a previous blog post. One of its main uses is a censorship resistant domain name registration. And the simple python script from DyName is to namecoin what dyndns and ddclient are to traditional domain names. Just prepare your registered name to include a dd entry, edit your config file, and call the script periodically from cron. That way you separate the private key where your name is registered from the hot wallet on the server. My provider used to reassign new ip addresses more frequently, now it’s about once every two months I would guess. The transition with namecoin was very smooth the last two times. I have a script that queries namecoin for the current ip address and then connects. There are dns resolvers and browser plugins or even public dns servers that would resolve namecoin domains. My experience with them was not as smooth as with the namecoin core itself. But I’m sure these parts will improve as well. So, with namecoin we have high confidence, that the ip address is correct that we are connecting to, but it can’t protect against man in the middle attacks. SSH has means to protect from that. The ssh client has a list of known ip addresses or host names and corresponding key fingerprints. But after an ip address change, there is no entry for the new destination, so ssh prints an error message and refuses to connect until you accept to add a new entry to your known_hosts file.

ssh known hosts

When you search for the error with your preferred search engine, you’ll find advices to delete offending lines in your known_hosts file. This of course is not what we need here. Just accepting to add a new entry the next time you connect would circumvent the protection against MITM that ssh provides. Since we already have the key fingerprint from the previous address, there is another more secure solution. If you have only one entry in your known_hosts file, you can skip the next few lines. Maybe you know which fingerprint is valid, for example because the file already contains a couple of lines with the same key fingerprint because the ip address changed a couple of times, and you just accepted it.

If you are not sure, which fingerprint you need, ask the server what it provides:

$ ssh-keyscan 85.3.164.135
# 85.3.164.135 SSH-2.0-OpenSSH_6.7p1 Ubuntu-5ubuntu1
85.3.164.135 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBE7WE5vtqSxUnQRX5CjOzEzUAdewqHRV5MXcSCQcylcKanpnDHRE4yVlEn770MFP6EfJ61ukdNYMDnSO9eoRiZY=

Now search for this fingerprint in your known_hosts file, and copy the whole line. On the new line, you replace the first hash with the actual new ip address in clear text. You could leave it like that, but you can also hash it with the following command.

$ ssh-keygen -H -f ~/.ssh/known_hosts

After writing all this I started wondering if it would be possible to keep the host key on an external hardware device like a NitroKey or a YubiKey. I already keep my client key for authenticating to the ssh server on one of these.  That’s something to find out in a future post maybe.

fido universal 2nd factor authentication

In the time since my rant about passwords, more and more sites adopt OAuth. I don’t like this development. Usually they offer login with facebook, sometimes with google or twitter and rarely with linkedin. The problem with OAuth is that the site operator decides what providers are supported. With OpenID on the other hand, I can host my own OpenID provider and secure it with whatever 2nd factor authentication I choose. It’s sad to see that OpenID lost traction, and is actually removed in many places. One concern about OAuth is that exactly the companies that track you the most, get this extra information about where you log into and when. And on top of that you usually have to grant the site you log into the permission to tweet or post on your behalf. But what bothers me most, is that you grant your id provider more power than you are probably ready to admit. Say for example you use google as your id provider for every site you can, because it is just so convenient. Then one day google decides for whatever reason to block your account. As a result you are locked out not just from all google services, but out of most of the sites you care. And it does happen that google blocks accounts for no good reason.

Most BitCoin exchanges these days offer some sort of 2nd factor authentication. Some use YubiKeys, some use GoogleAuthenticator and some send you text messages. They are somewhat similar as they all use something called “one time passwords“. Only how the user gets them is different. Text messages seem like an ugly hack, and phones known to be insecure.  That’s also why I don’t like the Google Authenticator as it is just software running on the regular processor of your smart phone. The YubiKey is clearly the best option out of these, but it also has its weakness. If you use it for different purposes, an OTP generated for one site could be reused for a different site. As it emulates a keyboard it’s a one way track and it has no way of knowing where it is used. This is why the now defunct MtGox distributed dedicated YubiKeys. At least some parts they did right .But there is something in the works to solve all of this…

Last week I received a new USB security token. It’s a PlugUp fido u2fa device. It has exactly the same form factor as the HW1 BitCoin hardware wallet. And that is actually how I paid it. Not directly, but through Brawker. The device implements the new FIDO universal 2nd factor authenticator standard. Finally a conglomerate of big name companies got together to solve the password authentication problem.

When I first read up on it, I found lots of marketing speech, and overly detailed specification, but not the kind of technical overview I was looking for. But it seemed interesting enough to give it a try. So far, there are USB devices available from only two vendors: Yubico and PlugUp. Even though I love the YubiKey NEO, the price was too high just to give it a try. The PlugUp device is much cheaper but also less rigid. Also there are not a lot of places where you can use it so far. But looking at all the companies that form the alliance, that is hopefully going to change.  The only place I could use was to log into my google account, and only with the Chromium browser. My browser of choice is Firefox, but it doesn’t look as if fido support is imminent. I did like what I saw so far. You can register multiple devices per account. And you can use the same device for multiple accounts. There were no technical hiccups. It just worked.

But still I thought, I would prefer a solution based on OpenPGP Card with EnigForm. With GPG, I can manage my identity myself, how I want it. Of course this is great for power users, but not something regular users want or can do. FIDO is targeted at regular users, and I think they found a good compromise. It appeared that from the security standpoint they should be similar, in that both work in a challenge response scheme. The server knows the public key, and lets the device sign something.

Then I found the technical information I was looking for on this blog. Now that looks promising. The device generates a new set of keys for every site. That is perfect for authentication, i.e. making sure it’s the same user as last time. If you want to compartmentalize your identity, you don’t even have to do it by hand. But it doesn’t help with identification. GPG would be better in that regard. So while GPG would be enough to identify a user, with fido the user will still have to fill in some required information. But most important, with both approaches fido and GPG/EnigForm, you don’t need a central service like with OpenID or OAuth that can track you.

Once fido gains more traction, the new YubiKey NEO will be perfect, as it combines fido u2fa with an OpenPGP applet. In the meantime, you can check which sites offer what type of 2nd factor auth at dongleauth.info

We have been using passwords for too long

Every time I have to register to a website using a password, I grow more annoyed. Passwords were fine when you only had one, to log in to your corporate mainframe. But these days, computers are better at cracking passwords than humans at remembering them.

It only gets worse with the more sites you maintain profiles. You shouldn’t use the same password all over. If it was hacked, your entire online identity could be compromised. And nobody can remember good strong passwords for every site he visits. Password managers are no solution. You need to have them with you all the time. They are protected by a master password. So if an attacker can get hold of your database and your master password, which is easily attainable with a trojan, then good luck. He even gets a list of sites to visit.

OpenId and OAuth are a step in the right direction. In theory, you could maintain your identity with a central entity, and use it as a proxy to authenticate you. You have to choose that central entity that manages your identity well, as is can now track your every move. Hence, It would be best, if you could host it yourself. But it is usually still only protected by a password. Since you now only have to remember one, it’s easier to choose a strong one. But again, if an attacker gets hold of your password, he can impersonate you.

So, we need hardware based two factor authentication (something you have and something you know). For about one and a half years I’ve been using a CryptoStick for said two factor authentication. It works great for email, files, ssh, package signing, full disk and disk image encryption, but I couldn’t figure out so far how to use it for web authentication. They mention a service for a SmartCard backed OpenId. That would be just what I want, but I couldn’t figure out how to make it happen. Continue reading “We have been using passwords for too long”

locally encrypted remote storage

Unlike the ordinary users, tech savy people are well aware of what can happen to your data, if you store it on cloud services such as dropbox. There are services that promise to encrypt your data locally, so that they can’t access them, a prominent one being wuala. On one hand, I don’t know if their client is open source, thus if you can check that you are really the only one capable of decrypting your data. And on the other hand it’s a paid service.

Usually, you can do almost everything that commercial products or services offer, free of cost but with a little investigative and manual effort on linux. This one seemed harder than usual, though. Continue reading “locally encrypted remote storage”

Full disk encryption with the crypto stick

Last week I finished the udacity applied cryptography course. I did not as well as in the other courses, nonetheless I learned a lot and it was (as always) really interesting. We learned about symmetric and asymmetric encryption, hashes as well as key exchange and management. Each week in addition to the regular homework, we got a challenge question. For most of them, I invested some time, but then had to surrender. Well, I still managed to complete some of the challenges. The most fun for me was a side channel attack on the diffie hellman key exchange protocol. We had information on how many multiplications were required for the fast exponentiation of the RSA key on one end. That was enough to decypher the secret message. It was a good illustration of what has to be taken into account when developing real world cryptographic algorithms. And it reminded me of how some smart cards were hacked by closely monitoring the power consumption.

Now, it was time to put my crypto stick to use. My netbook still ran Ubuntu Maverick due to the horrible graphics card (gma500). So I waited for the release of Linux Mint 13 LTS. In the 3.3 line of kernels there is a poulsbo driver already included.

First I prepared the crypto stick according to this tutorial. After initially generating the keys on the stick for maximum security, I let myself convince to generate them on the computer to be able to make backups. I could not regenerate the authentication key so far, and thus I can’t use it for ssh at the moment. I’m still looking for a solution on that.

Then I installed the operating system along with the full disk encryption according to this tutorial. At first it didn’t work, but then I discovered that there was a mount command missing in the tutorial and thus the generated ramdisk was not written to the correct boot partition.

Here is how it works (as I understand it):

  • grub loads the kernel along with the initial ramdisk which contains everything necessary to communicate with the card.
  • The ramdisk also contains the keyfile for the encrypted root partition. Upon entering the correct pin, the smart card decrypts the key file (asymmetrically).
  • The key file in turn is used to (symmetrically) on the fly decrypt (and encrypt) all accesses to the root partition.

It was new to me how to put stuff into the vmlinuz ramdisk. Apparently the script to ask for the key and decrypt the key file, as well as the keyfile itself and all the other required stuff can be added by installing a hook that is executed whenever a new ramdisk is created. For example when installing a new kernel.

Not that I would have something stored on the harddisk, that would require such a level of security. But it’s interesting to set up and see how it works in action. The crypto stick adds a fair bit of security. As it has a smart card built in, a trojan couldn’t get hold of the private key, and a 2048 bit key is way harder to crack than a password that one can remember and type in every time.

Playing with Smart-Cards

Ever since reading the book “Kryptographie und IT-Sicherheit” where I first learned about how SmartCards work, I wanted to do some SmartCard programming. In the book it describes some inner workings of Smart Cards, and that some of them have a small Java VM inside. But it turned out that the entry was not as easy as in many other fields. First of all, you have many smart cards (SIM of your mobild phone, Credit Card, Debit Card, Health insurance card, …), but usually they are protected so you can’t install anything of your own. Technically, it would be possible to have many applications on the same card, like CreditCard, DebitCard, HealthInsurance, PublicTransport, and so on. But with very few exceptions, the issuers don’t feel confortable sharing a card with someone else. Then there seem to be many different standards, and the companies seem to bee keen to obscure as much as they can. And then you also need kind of specialized hardware, but that’s the easier part.

Continue reading “Playing with Smart-Cards”