1

Would it be wise to:

  • Generate a lot of priv./pub. key pairs, and store them in a file on the server machine(Linux). (Let's say in a companies server room)

  • Then encrypt the file with AES, and store the AES key in server source code, directly.

  • Then, when the server needs one random key pair, it decrypts the file, and takes a random pair.

I know nothings always a 100% safe, but

EDIT: The Server is local, while clients are remote. (over TCP)

My question: Is this a more or less safe approach, and can someone steal/read the file somehow remotely, even tho I set the file permissions to my user only?

SubSpecs
  • 13
  • 4
  • Do you have a reason to create the key pairs ahead of time, instead of just creating them when they are needed? – Sjoerd Sep 12 '18 at 11:43
  • @Sjoerd yes, generating them each time is a bit too slow for me. I generate a key pair for each client slot on my server. And generating ~60k key-pairs takes way too long, even multi-threaded. Don't ask, I need them all. I don't use a master RSA key-pair for the server, I generate a unique one for each client slot, once, at startup. – SubSpecs Sep 12 '18 at 11:53

1 Answers1

1

There's always a chicken and egg problem when you want to store private keys securely, but the app needs automated access to them. If you poke around this site you'll find plenty of related questions, for example:

Ask yourself what your threat model is; if you're only worried about remote attackers, then focus your efforts on hardening the perimeter of your server. If nobody can get in to your server, then encrypting it with AES might already be overkill.

If your threat model includes malicious users on that system, users introducing malware onto the server, or if whatever app the server is running is complex enough that it could become compromised, then protecting the keys at rest becomes a good idea. As you say, nothing is 100% secure; a software-based approach will always be breakable by someone with root access to the server and enough time to study memory dumps of your program. It sounds like what you're doing is reasonable. Some possible improvements:

  • Rather than have the AES key embedded in the source code, have an admin enter a password at process startup that is used to derive the AES key. That way an attacker really does need to be on your server taking memory dumps rather than being able to extract it from your binary or source code, which I assume is easier to acquire than a memory dump of a prod server.
  • You could maybe encrypt each private key with its own AES key just to increase the barrier between getting one key and getting all the keys.
  • The next big step up would be to generate the keys on dedicated crypto hardware so that the private keys are never on the server at all. Cheap option: a bunch of PKI Smart Cards dangling out of the server on USB dongles. Expensive option: a network HSM.
Mike Ounsworth
  • 57,707
  • 21
  • 150
  • 207
  • The server is local, while the users connecting to it are not. The file with the pairs is stored on the same server. Smart Cards I guess are not a bad option, or a HSM would be ideal, tho it's expensive. And for a starting company, this is (for now) not the solution. The only thing I want is to know, if maybe my approach might have some obvious security faults / easily hackable (remotely). – SubSpecs Sep 12 '18 at 12:23
  • @SubSpecs Like I said in my answer, your approach seems reasonable. As you point out, this is not the type of thing where you will even be "fully secure", instead it's a question of how much money and effort you're willing to spend vs how much you expect attacker's to spend (see the Threat Modelling link). It's up to you to decide what level of security is appropriate. – Mike Ounsworth Sep 12 '18 at 13:04
  • When you say "users are remote", what does that mean? How are they connecting? What ports are open on the server? What applications is it exposing over those ports? – Mike Ounsworth Sep 12 '18 at 13:05
  • Like a server-client example, over tcp. Port can be any, and nothing else is running on the machine. A clean linux os. Also yes, the risk is high. And I don't think I can buy that many smart cards, like for my purposes I'll need a lot of them. HSM is too expensive, like 11-16k~ for one. That's why I posted a scenario like this, so I could get a good idea from the community if my approach is not easily exploitable. – SubSpecs Sep 12 '18 at 13:10
  • @SubSpecs Hmm. I can't say if the level of security you're proposing (software encryption of keys) is appropriate without doing a proper threat analysis of your system. If the risk is high, then I would assume you also have a high budget for security tooling and staff? I would hire a pen tester to test your app and see if there are any vulnerabilities that let an attacker get she'll access through that port. – Mike Ounsworth Sep 12 '18 at 13:16