Posts

Showing posts with the label tpm

TPM chip protecting SSH keys - properly

Not long after getting my TPM chip to protect SSH keys in a recent blog post , it started to become obvious that OpenCryptoKi was not the best solution. It's large, complicated, and, frankly, insecure. I dug in to see if I could fix it, but there was too much I wanted to fix, and too many features I didn't need. So I wrote my own. It's smaller, simpler, and more secure. This post is about this new solution. Why not Opencryptoki? It generates at least some keys in software. As I've explained earlier, I want to generate the keys in hardware . It generates migratable keys. This is hardcoded, and some people obviously want migratable keys (for backup purposes). So a fix would have to involve supporting both. Opencryptoki has no way to send such parameters from the command line key generator to the PKCS11 library. So not only would I have to implement the setting , but the whol...

Should I generate my keys in software or hardware?

A Hardware Security Module (HSM) is any hardware that you can use for crypto operations without revealing the crypto keys. Specifically I'm referring to the Yubikey NEO and TPM chips , but it should apply to other kinds of special hardware that does crypto operations. I'll refer to this hardware as the "device" as the general term, below. Some background When describing the Yubikey NEO I'm specifically referring to its public key crypto features that I've previously blogged about, that enable using Yubikey NEO for GPG and SSH , not its OTP generating features. To generate keys for these devices you have two options. Either you tell the device to generate a key using a built in random number generator , or generate the key yourself and "import" it to the device. In either case you end up with some handle to the key, so that you command the device to do a crypto operation using the key with a given handl...

TPM chip protecting SSH keys

STOP! There is a better way. this post explains a simpler and more secure way. Update 2: I have something I think will be better up my sleeve for using the TPM chip with SSH. Stay tuned. In the mean time, the below works. Finally, I found out how to use a TPM chip to protect SSH keys. Thanks to Perry Lorier . I'm just going to note down those same steps, but with my notes. I've written about hardware protecting crypto keys and increasing SSH security before: GPG and SSH with Yubikey NEO Benchmarking TPM backed SSL TPM backed SSL SSH certificates but this is what I've always been after. With this solution the SSH key cannot be stolen. If someone uses this SSH key that means that the machine with the TPM chip is involved right now. Right now it's not turned off, or disconnected from the network. Update: you need to delete /var/lib/opencryptoki/tpm/your-username/*.pem , because otherwi...

Benchmarking TPM-backed SSL

Image
As you can plainly see from this graph, my TPM chip can do approximately 1.4 SSL handshakes per second. A handshake takes about 0.7 seconds of TPM time, so when two clients are connecting the average connect time is 1.4 seconds. This means probably not useful on server side, but should be good for some client side applications. To replicate the test, start a server: openssl s_server -keyform engine -engine tpm -accept 12345 -cert foo.crt -key foo.key -tls1 -CAfile foo.crt -verify 1 -status And then connect 100 times: for n in $(seq 100); do time openssl s_client -tls1 -connect localhost:12345 /dev/null 2>/dev/null;done 2> timelog Then just look at the "real" time in the timelog. (if in doubt, use bash. zsh gave me some crap in the log) Example GNUPlot: plot [1:] [0:2] '2' using (2/$1) w l title '2 clients','1' using (1/$1) w l title '1 client'

TPM-backed SSL

This is a short howto on setting up TPM-backed SSL. This means that the secret key belonging to an SSL cert is protected by the TPM and cannot be copied off of the machine or otherwise inspected. Meaning even if you get hacked the attackers cannot impersonate you, if you manage to kick them off or just shut down the server. The secret key is safe. It has never been outside the TPM and never will be. This can be used for both client and server certs. Prerequisites A TPM chip. Duh. May need to be turned on in the BIOS. Could be called "security chip" or something. If you don't have a TPM chip but still want to follow along (maybe add TPM support to some program) then you can install a TPM emulator. See links at the end on how to install a TPM emulator. A working CA that will sign your CSR. I will assume you're running your own CA, but you can send the CSR to someone else to sign if you want...