3

I'm working on a software which deals with lots (several millions) of RSA private keys. Keysize is 2048, I'm going to store them in database in PEM format.

I want keys to be encrypted to mitigate risks of hostile access to database. Naturally, applying passphrase with PKCS#8 comes to mind.

However, I'm not sure it is safe to apply same passphrase to millions of private keys. If someone gets the database, will it be possible for them to decrypt keys, knowing the fact that same passphrase where used?

If PKCS #8 is not safe in this scenario, what better options I have, given fact that I can use same passphrase (or limited number of them) to encrypt data?

Serhii Yakovenko
  • 131
  • 1

6 Answers6

2

Buy yourself an HSM.

Then its your choice :

  1. Store the keys on the HSM; or
  2. Create an encryption key on the HSM and encrypt the keys stored in the databse using the key stored in the HSM.

An HSM-based solution of some description is the only real way to get real assurance against attack. HSMs are robustly designed for security and explicitly designed to make it impossible to gain access to key-data stored on the HSM.

Little Code
  • 375
  • 2
  • 11
2

I'm working on a software which deals with lots (several millions) of RSA private keys. ... apply same passphrase to millions of private keys

You're definitely doing something fundamentally wrong, there is no good way to protect millions of keys in a single server. I'd suggest finding another design where you won't need millions of private keys. What problem do you think you can solve by having a million keys? What's wrong with just having a single RSA key representing you?

what better options I have

Just use a full disk encryption and no need for per-record encryption. You'll have effectively the same level of security, and it will be much easier to manage, which means less likely to make errors that could compromise security.

If you want a suggestion that improves security, then you'll have to describe a bit more what it is you're building, otherwise any advice here are going to go nowhere.

Likely though, you probably can do something like the CA system where you only have a few air gapped root CA keys which are only used to issue intermediate CAs certificates. It's the intermediate CA certificates which are used for day to day issuances of access certificates. You shouldn't have a single server with millions of private keys, but instead your single server should store certificates instead (certificate is public key + attributes + expiry date + cryptographic signature made by the CA). You only need one private key for each person, but you can create multiple certificates from a single key, asserting various attributes (claims) about the owner of the private key. The owner of the private key can submit these claims to the relying party, which verifies whether the owner of the key are allowed access or not.

Lie Ryan
  • 31,089
  • 6
  • 68
  • 93
1

Using a different passphrase for each key means you then have the problem of working out where to keep the passphrases. It is a little better in that the passphrase can be stored separately - and realising (compromising?) the asset requires compromise of both the passphrase and the protected key.

The number of entries you describe rather implies that you will need some automation over bringing the key and the passphrase together (e.g. a html5 application connecting to 2 different services with separate authentication). That is the weak link in the application. But you've not told us anything about the front end of the system.

symcbean
  • 18,278
  • 39
  • 73
0

In the past I made something similar and we decided to add a field to the table that holds the keys in a token. That token was the key of other table, that was in a different database, that holds the passphares of the other. Probably there is a better way but this was enough for us.

Limit
  • 3,191
  • 1
  • 16
  • 35
camp0
  • 2,172
  • 1
  • 10
  • 10
0

I have a schema available that can be used for PKI including escrow that might help. It is part of a bigger project that deals with the complexity of encryption key lifetimes.

jas-
  • 931
  • 5
  • 9
0

First: Yes, use PKCS#8. It's the standard and widely used. A custom encryption implementation will likely be flawed, less convient, and have less tooling.

Regarding password sharing across keys:

It all depends, but in the end, you'll want to appropriately restrict access to the keys so that an operation only gets access to the keys it needs.

If these keys are all used by the same person/process simultaneously, there isn't much of a point to encrypting them with different passwords, since the passwords will have to be all accessed together anyway.

On the other hand, if you store one key per employee (for example), each employee can get the password to their key and their key only. That way, one password getting compromised doesn't put every private key at risk.

Of course, you can go in between, grouping keys together, etc, depending on what is most appropriate for your situation.

user171782
  • 31
  • 1