This has some major security and convenience advantages over keeping keys in a file. Firstly, you can generate the keypair actually on the card so that the only device that ever has, and will ever have, the private key is the smartcard. Secondly, the key is secured by a pin and, by default, it will block the card after 3 incorrect pin attempts and after 3 incorrect attempts to unblock the card it will permanently erase the secure storage on the card. Also you can easily make use of your keypair on multiple computers, even untrusted machines, without compromising security. I keep my smartcard in my wallet, so I always have access to it where ever I go.
Alternatively, if you don't want an actual card you can get smartcard-like devices are are physically similar to a USB stick.
Why three? Can someone actually guess your pin in 4 tries? I hate the number 3 used for these things. Raise it to 20 and you'll have virtually the same amount of security, but the false positives will drop to 0.
http://i.imgur.com/hHxlh2f.png
The whole thing is even more complex that that. You can actually have different pins for different roles. For example, you could setup a different pin that can only be used for authentication with a specific keypair/certificate. Also a pin does not even have to be a pin as such. The admin pin on the card (i.e the role that can unblock the user pin) is actually a challenge-response as it is designed so that a user can phone up IT support or something and tell them the challenge from the card and IT support can give them a response that will then unblock their normal pin.
Am I right, or I'm missing something?
The other philosophy is to generate the key on the RSA card, and never allow the card to export it. Then you consider the private key dispensable and will have to update all systems to accept a new card's private key.
There are plenty of tutorials online, but none are particularly good. I've been meaning to regenerate my keys, so maybe I'll take notes and try to write up a good one.
Here are a few links:
http://wiki.debian.org/Smartcards/OpenPGP http://www.gnupg.org/howtos/card-howto/en/smartcard-howto.ht... https://www.crypto-stick.com/
The last one is interesting - it's a smart card reader and integrated smart card built into a usb stick.
I use the Minidriver manager tool from: http://www.gemalto.com/products/dotnet_card/resources/develo... although you could use something like pkcs11-tool.
Generating a RSA keypair is as simple as right clicking on an empty container, selecting OBKG Container and filling this out:
http://i.imgur.com/uMY53OD.png
It will display the public key but it is in hex and uses Microsoft's PublicKeyBlob structure. OpenSSL will convert this to PEM for you though, which is what you want for SSH authentication. Something like:
openssl rsa -pubin -inform MSPUBLICKEYBLOB -in "C:\path\to\my\publickey" -outform PEM -out "C:\path\to\my\publickey.pem"
OpenSSH can use a pkcs11 library for authentication (-I option), which is also avaliable from Gemalto's website (these are generally specific to the smartcard), and on Windows there is a version of PuTTY called PuTTY SC that will also let you use the pkcs11 library.
> -in test_rsa_key.old -passin 'pass:super secret passphrase' \
> -out test_rsa_key -passout 'pass:super secret passphrase'
Is there a way to do this without including the password on the command line? Because somehow I don't think having your private key's password in your .bash_history will improve the security of your key.
[edit] Oh I see, just don't specify and it'll ask. I get that he's doing this with a sample key, but you just know someone's going to scan through this and do that command on their real key.
[1]: http://www.linuxjournal.com/content/using-bash-history-more-...
Provide your current passphrase at the first prompt ("Enter passphrase for <infile>:") and your new passphrase at the second and third prompts ("Enter Encryption Password:" and "Verifying - Enter Encryption Password:"). You may use the same or a different passphrase on your new key.
Of course, most things that require passwords will request that you manually enter one if you leave the arg off.
By design, ssh does not make use of certificates. So there is no way for ssh to know upon connecting to a host for the first time whether the public key presented by that host is authentic. After the first connection, ssh caches the keys in ~/.ssh/known_hosts, and will then give you a big warning if the key changes. I imagine when this happens many folks blindly delete the the cached key and re-connect.
So you should be aware of the potential for MITM attacks to occur unless you have some out-of-band mechanism for distributing or authenticating host keys.
Edit: huh, apparently ssh added support for certificates. "ssh-keygen supports signing of keys to produce certificates that may be used for user or host authentication." So now you just need to distribute your CA certificate everywhere and you're golden. http://justanothergeek.chdir.org//2011/07/howto-authenticate...
As opposed to writing down the key signature of your server's host keys on a card in your wallet? You only need to look at it the first time you connect to the server, and it's a lot less of a pain in the ass than trying to install custom CA certs on every machine you SSH from.
With the CA you have to have a base trust in a CA cert, with GPG you trust whatever you want.
https://blog.linode.com/2013/04/16/security-incident-update/
Making your passphrase twice harder to crack is nice.. but whats 15 days instead of 7? Making your passphrase 10000x harder to crack would also be nice... but why care, if i have access to the file, i can just record your keystrokes when you type the passphrase.
And that's why you can use an ssh-agent, and probably why OpenSSH doesn't care much about changing the key format.
If you do not trust your laptop, the problem is still there. You can still capture the keystrokes easily if you have access to the file, anyways.
I would suggest using something like a cryptostick or any openpgp smartcard when the laptop is not trusted (actually, even if its relatively trusted I would still recommend it!). This ensures the key is never transferred somewhere it can be copied.
But it does not ensure that the computer will add another entry to the authorized_keys file in the host as soon as you access it. Or install a rootkit there with another kind of backdoor.
If you don't trust your computer, don't give it access to your servers.
There is no real way around the evil maid attack. If I login from a compromised computer, if that computer is compromised by a competent attacker, it's over.
The advantage of a smartcard, if and only if you've got a smartcard that requires some action to authenticate (like a physical pin pad) is that only the servers I've logged into while compromised are compromised (assuming you don't have some kind of jelly doughnut setup where all servers can login to all other servers) whereas if I have an encrypted private key, well, if I decrypt it while the attacker is on the box, the attacker has compromised /all/ servers I have a login on.
If you need to access a server you'll always need a computer. authorized_keys are public keys only. it does not matter if other computers have your public key. all it does is give you access.
the private key of your ssh key(s) give access to several servers, thats why its the part that you want to protect. if one server has a rootkit, well, that sucks. but if that rootkited server can access all the servers YOU can access, you're screwed.
You mean like doing 10000x iterations of md5? Btw, it's not even 15 days instead of 7 any more. You need to measure it purely in money. EC2 cost is nodes * time, so if you need to double the time it is just doubling the cost.
Edit: For example, you can view what is currently running on the smartcard: http://i.imgur.com/Pgwz4la.png or view the filesystem on the smartcard: http://imgur.com/aLsV6pf
In other words, how much additional security does password-protecting your private key gain you?
Someone took your laptop, they could now have one of two things:
(a) - Just your laptop
(b) - your laptop and every server you're using your key for access to.
b is prevented by the passphrase.
a) just your laptop, b) your laptop and all files, or c) your laptop and all your files, and access to servers as per above.
I like "a" the best, and it's achieved through full-disk encryption. You don't even need a new passphrase for that, considering that you probably already password-protect your computer.
I'm not an encryption expert. Can someone else weigh in on this?
openssl pkcs8 -topk8 -v2 aes-128-cbc -in ~/.ssh/id_rsa -out test_rsa_pkcs8
openssl list-cipher-commands
man enc
[1] https://github.com/dcuddeback/des_crack
[2] https://en.wikipedia.org/wiki/Data_Encryption_Standard#Repla...
ssh-keygen -t rsa -N 'boobooboo' -f test_rsa_key
history
...
964 ssh-keygen -t rsa -N 'boobooboo' -f test_rsa_key
From man bash:
HISTCONTROL
A colon-separated list of values controlling how commands are
saved on the history list. If the list of values includes
ignorespace, lines which begin with a space character are not
saved in the history list. A value of ignoredups causes lines
matching the previous history entry to not be saved. A value of
ignoreboth is shorthand for ignorespace and ignoredups. A value
of erasedups causes all previous lines matching the current line
to be removed from the history list before that line is saved.
Any value not in the above list is ignored. If HISTCONTROL is
unset, or does not include a valid value, all lines read by the
shell parser are saved on the history list, subject to the value
of HISTIGNORE. The second and subsequent lines of a multi-line
compound command are not tested, and are added to the history
regardless of the value of HISTCONTROL. $ echo "this will not be saved in history"
$echo "this will be saved in history"
export HISTCONTROL=ignoredups:ignorespace
fish, OTOH, seems to do this by default.
read password
> secret-password-followed-by-enter-here
sensitive-command --password $password
unset password
I think this approach should be more secure than trying to set memorable passphrases for all my keys. Thoughts?
For managing passphrases, I strongly recommend the program keychain:
http://www.funtoo.org/Keychain
It's a thin wrapper around ssh-agent, but ultimately means I only need to enter my passphrase once.
The nifty feature is that you can add a command to your .login to clear your passphrase, so it's safe to use on remote hosts - if someone else is able to ssh in, they only get access to that host, not others that your ssh key allows access to.
It's not as good as PBKDF2, but it's better than nothing and is probably why stretching isn't used.
As for the argument about being susceptible to a dictionary attack, well if you go to the trouble of using key-based auth then use a dictionary word you're kind of asking for it really.
That's valid; however, when you can compute 33.1B MD5 hashes a second, who needs rainbow tables? http://blog.zorinaq.com/?e=43
Six and seven digit passphrases are easily brute-forced.
What excites me about their project is a very simple file-system based interface they are planning to implement for their upcoming version. Plug the key in, it looks like a regular USB key, put a file in a specific place, get an encrypted/signed/whatever file from the file system from another place. No driver or software required. I hope their project takes off and people start buying these keys. The price is a little high right now (59,00 €) and it is currently not available.
s2k3 is an iterated-and-salted s2k algorithm from RFC2440, the protected private key format is: https://gitorious.org/gnupg-org/gnupg/blobs/master/agent/key...
The number of iterations is at least 65536, whereas with pkcs8 openssl uses 2048 iterations by default.
More details on how to use SSH keys with GPG agent: http://budts.be/weblog/2012/08/ssh-authentication-with-your-...
That way, if someone steals my (FDE, managed) laptop or phone, I can revoke just the credentials on that client device, not losing access to all my servers.
Using tamper-resistant storage for the keys is a great idea; I wonder if anyone has done TPM for ssh on windows, or just trousers on linux. Sadly for Macs the only option is some kind of external USB token :( I kind of wish someone made a bluetooth 4.0 le device which could hold keys and be used as a smartcard/key device, maybe with trusted user I/O too. Maybe in a watch form factor.