Prevent or detect key copy

Question

This question can be classified as somewhat two interrelated questions - or two goals.

Main aim is basically to authenticate client to server, but remain secure even if someone steals the key from client.

Goal 1: Say I am using symmetric key to authenticate my (client's) request to server -e.g. using HMAC. What are the (modern/secure) ways to store this key on client's HDD so that if someone has access to my HDD, he/she can't copy the key, to use it for his/her purpose. e.g., create malicious request to server. If this Goal is completely and easily achieved we may even drop Goal 2.

Goal 2: Now, Goal 2. Additionally, if someone still managed to get the key, it should be possible to prevent attackers from accessing the server from a different computer from which the key was stolen. This goal can be seen as a way to strengthen our system if Goal 1 was not achieved. If we have good means to achieve Goal 2, our needs are fulfilled.

For example one way to solve our problem (both goals basically), is in addition to HMAC, to let the server accept connections only from some specific IPs (in case someone stole key, he/she can't connect from other PC). But this won't work if the IP isn't static. Any other ideas in this direction? To ensure from other computer (from where key was stolen) attacker can't access server.

Because like I said for example if we have a secure means to prevent attacker to access server form a different computer from which key was stolen, we may relax the requirement a bit on secure key storage as mentioned in Goal 1.

Note: Using passwords each time to encrypt/decrypt the main key is not an option because the software must work on automated fashion.

Software is running on Windows.

PS. To make it clear preferable are solutions which don't rely on HSM (or expensive hardware), if possible.

PPS. The answer with votes doesn't focus enough on Goal 1 and Goal 2.

Answer 1

There are two issues here (just like in your question). I'm going to explore both of them. First, the Conceptual Problem and then the Practical Implementation.

Conceptual Problem

Here's the deal, something that everyone should just know, but I've found is really hard for people to accept.

We cannot protect a computer from itself.

What I mean is that when trying to keep something secret on a computer, especially on the HDD, but really, also in memory, that thing will not really be secret. We can build very complex OSes and data silos, however, in the end, there's a Trusted Computing Base (TCB) and then there's everything else.

In this case, you've got a secret (Message Authentication Code Key or MAC key) or as the other post/commenters have suggested you'll have to use an asymmetric Pub/Priv Key. That key material is just information and you've got to put it somewhere and that location has to be accessible to programs running on the computer without human intervention. That means either it will be in the clear or it will be encrypted with some other Key (password from a human or yet another crypto key). You don't want human intervention, which means that the password or the second crypto key needs to be stored.

Now, we are in a recursive problem and there's no base case! Why? Because we cannot make a computer keep a secret from itself. At least, not if it has to use that secret, and your program needs to do just that. So, in the end, your key material or that encrypted key plus the second key used to encrypt it will be available to at least one process on the computer, and therefore, be copyable (as information) to any other device on the planet. Security blown.

Really, you might as well keep the key in the clear (unencrypted), in an O/S protected file, harden your servers to attack and monitor the network and servers for problems. Of course, people freak out when you suggest keep it in the clear b/c "OMG, you didn't ENCRYPT it?!" Ok, fine, so protect it with encryption, but don't lie to yourself about how safe it truly is. Laws to keep credit card data protected save Marketing Face, they don't really protect anything. The most important part of the laws are customer notification upon break in and theft of personal data. That is important.

In the end, someone could find a way to steal your MAC Key and whatever else you use to identify the remote server, and therefore, spoof the identity of the remote server. The best you can do is to use the crypto algorithms as they've been designed and for the purposes they were intended and then protect and monitor.

Bruce Schneier discusses this. (1) Proper algorithm selection and implementation. (2) Proper System configuration. (3) Active Monitoring.

Also, as an aside I recall reading a research paper that showed how to pick keys off a hard disk by scanning and looking for highly entropic regions of short (key) length. The idea is that most stored computer data is of regular form. Sections of data that don't have patterns (appear random) are most likely encrypted data or keys. Encrypted data will tend to be grouped. Keys will tend to be isolated. INOW, stored key data on a hard disk actually jumps out at you if you're looking for it in the right way.

Good luck with that.

Practical Implementation

Your improper use of a crypto algorithm has lowered your security resulting in an attack more likely than the theft of your machine key from your machine.

You're using MAC Keys as a means of identification. Please note that Eve the Eavesdropper could discover your MAC key by watching one exchange and then off line attacking the message+MAC to reveal the key. This could be an expensive attack; however, depending upon the system and the data, it could be worth the cost.

In this case, you've abused one crypto algorithm (Message Authentication) for another purpose - server identification and trust. Instead, you need to separate Authentication of the server from Authentication of the message (which is really misnamed and causes confusion, so I call it Integrity protection, which is what it is).

Any good Authentication algorithm (4 step handshake authenticating both client and server) creates session keys which can be used for Privacy (session encryption) and Integrity (message authentication). Note, I write keys because you shouldn't use the same key for both. The best algorithm you can use provide Perfect Forward Secrecy, which these days means DH at 2048 bits. However, DH is subject to MITM attacks, so you need a way to mitigate that. I would suggest using SPEKE or DHEKE, whichever one is no longer under patent protection. You could also do what TLS does and sign the DH ephemeral with an RSA key, but now you're into PKI.

At this point, I'd say that you could just use TLS+RSA and make sure it's properly configured and limit your root certificates or use two-way authentication in which you don't need Root Certs and each peer validates the other. This will provide exactly the type of security you'd like to have.

So, if you're going to roll your own authentication system, really dig into the philosophy of good crypto system design and do it right. You'll probably wind up replicating Kerberos or TLS, but you'll learn a lot. Here's what happens when you think you understand enough about this and still build it incorrectly.

Or, don't roll your own and just adopt Kerberos or TLS and take advantage of everything they have to offer.

I suspect you know which way I think you should go.

Answer 2

If someone has (physical) access to your hard drive, and it is not encrypted, they can duplicate any data that is on it. If it is encrypted, they can't duplicate data off it, but you can't access that data until you provide the decryption key, which might be a password, physical token, or combination of multiple factors. Depending on your application, this might be a viable approach - requiring a device with a specific MAC address or configuration - but it is very brittle, and a determined attacker would probably be able to work out this method. At the very least, they could steal the physical device, and then extract the required key.

Once they have duplicated the data, there is no way to determine which is the original and which is the copy - it's digital information, not a physical item. Apart from anything else, the data is copied when it is sent to your server, multiple times. A copy (possibly itself encrypted) probably sits on a log server at various ISPs, at the very least, and on any backup devices your server provider uses.

Therefore, there are two options which could work:

1. Prevent copying of the key except in specific circumstances
2. Allow detection of a key in some way

Option 1 is effectively solved by "use a HSM on your server, and for every system which uses your application". Data is sent to the HSM, and returned having been processed in some way using the key that is stored within it. That encrypted data is transmitted over the internet, and the operation is repeated in the other direction when it reaches your server. This is obviously quite an expensive proposition - even a basic HSM is not a cheap device.

Option 2 requires a more drastic rethink to your application. Symmetric keys offer confidentiality, but not authentication of the other party. There is no way to say whether a message that Alice (your server) receives is from Bob (legitimate client machine) or from Eve (malicious attacker). If you use asymmetric keys, data from Bob is encrypted with Bob's private key. Assuming that Bob is keeping his key secure, you can be assured that it came from Bob (or at least, that they have Bob's key). You can verify this since you can decrypt it with Bob's public key.

The problem here is that Eve can also decrypt it with Bob's public key. You now have authentication, but not confidentiality. You can fix this by getting Bob to first encrypt his data with his private key, then with your public key. You can decrypt the outer layer with your private key, and the inner layer with Bob's public key. Eve can't decrypt the outer layer, so it doesn't matter that she could decrypt the inner bit. When you send out data, you encrypt with your private key, and with Bob's public key. Bob can decrypt the outer layer with his private key, and the inner with your public key. Eve is again stuck outside.

Clearly this is a lot more complicated than a symmetric algorithm, but this allows you to relax slightly. You still need to protect your private key, and for your users to protect their private keys, but this is no worse than your current situation (don't forget that it's a symmetric key - any of your users could end up with the key being stolen), but with one advantage: if a user calls and says their private key has been stolen, you simply stop accepting that key. It doesn't affect your private key at all. It doesn't affect any of your other users at all.

There are advantages to symmetric encryption, most notably speed, but these can be incorporated into this system by encrypting a relatively short symmetric key with the slower asymmetric key method, and using that for the bulk of the data - that's how PGP works.

Answer 3

One thing I believe hasn't been mentioned yet, is that you could make use of virtualization or linux "sandboxing" (e.g. docker) combined with hard disk encryption

Separate your program into:

• A container with your main application
• A container with a software based HSM

Then an online attacker can only get to your secret keys by breaking through the container your application is in (not unheard of, but hard) or somehow getting access by ssh to your "root" account (if he can guess the password or you're running a vulnerable version of ssh).

If a thief steals your server while its off, he won't be able to get to the data because its encrypted.