4

I'm setting up a system where devices are going to be tested right after production. Each device has an individually given AES-key, which must be known in order to communicate. Those individual keys are delivered by the device manufacturer in a shipment-file (one per ~1000 devices), which is itself RSA encrypted. Only the test authority has the private key to decrypt such shipment files.

The current plan was first to export the device keys from the shipment files into a central database. This will be done once for a delivery of ~1000 devices. The test application will then access this database to get out the individual device keys.

Putting all device keys directly into the database does work but isn't a very attractive solution: everybody gaining access to the database automatically gains access to the device keys.

Keeping in mind that this is very vulnerable, how can I improve security? I could AES encrypt the device keys before writing into the database, but then the test application has to know this private AES key. The problem just shifts to "how to keep this internal key secret". So it is a little better, but still unsatisfactory.

What else would be an acceptable solution? Maybe using a smart card?

| improve this question | |
4

The best option is to use a hardware security model (HSM) to encrypt/decrypt data in your database. But HSMs are expensive and can be awkward to use.

Without hardware support, you're going to have the chicken and the egg problem of where do you store the initial key. That said, adding one more layer of encryption, encryption before being stored in the database, and storing the AES master password in a configuration file for the client does add security. An attacker who gets access to your DB, say due to a SQL injection vulnerability or DB misconfiguration, will still need to get access to the AES system master. So they'll need to compromise your configuration file or get access to your client's memory.

Be sure to rotate the AES master password frequently (maybe for each batch). This will reduce the harm caused by a DB compromise and key theft. I would also not store the AES master password in clear text. You can encrypt it with a 2nd static AES password that is hardwired into the code. This adds minimal security, but it prevents employees from accidentally printing the configuration file and exposing the password.

| improve this answer | |
  • HSMs would certainly be the best case but white box encryption as an alternative remains with the chicken and egg problem as indicated here. You could re-purpose a Linux server as a HSM and use logins where different 'custodians' have half a password each for access. This enforces dual control. This system can store the Key Encryption Keys and perform decryption operations on the Data Encryption Key cryptograms. That can restrict all key operations to that box. You could cluster that as two boxes so the KEK is stored in shared virtual memory so reboots don't require user interaction. – AndyMac Mar 27 '18 at 13:05
2

As designed, the system requires AES keys "all over the place." You don't say what the devices are but the first thing that springs to mind is to move away from the use of AES to a public key system.

(This might not work if the devices are very computationally constrained, like a smart card, but most devices can now handle public keys.)

| improve this answer | |
  • The devices are smart meters. It is not an option to change to another security mechanism - not only there are millions of devices involved, but also, it is not within my scope to make such decision. They are manufactured at Company A and calibrated at Company B. Therefore, A sends the cryptographic key material within a shipment file to B. There, keys must be extracted in order to perform tests on individual meters. After calibration, keys for the role "calibration" are compromised and must be renewed at the end customer (company C). – michael Mar 26 '18 at 18:05
  • Wow. Whose smart meters work like that? You can tell us, we'll keep it a secret. :) – Adam Shostack Mar 26 '18 at 21:13
  • 1
    @AdamShostack is right. Move to pubkey. Your design totally sucks. The device MUST NOT use preshared symmetric keys. This is why I do not want this crap in my house! – cornelinux Mar 26 '18 at 21:30
  • Thanks @cornelinux! However, let's respect the OP and his constraint, while encouraging him to find a way to publicize this important design flaw. (I'd think that DHS and the UK's GCHQ would be interested in this, that whistleblowing is probably protected activity.) – Adam Shostack Mar 26 '18 at 21:38
  • Interesting twist with the whistle. And you are probably right. But as OP says, he is currently in the process of "setting it up" - to me it looks like, that it is not "too late", to get things right. It is great that he has his concerns and is asking. But the annoying thing is, that such companies do not invest in a security design in the first place - although we saw this problem too often in the last 10 or even twenty years and they should have learnt by now. I am totally ok with OP and did not mean to offend michael, but I am not OK not with the original decisions of your employer ;-) – cornelinux Mar 27 '18 at 6:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.