Symmetric key storage

烈酒焚心 提交于 2019-12-02 19:05:35

There only two real solutions for (the technical aspect of) this problem. Assuming it's only the application itself that needs access the key...

  1. Hardware Security Module (HSM) - usually pretty expensive, and not simple to implement. Can be dedicated appliance (e.g. nCipher) or specific token (e.g. Alladin eToken). And then you still have to define how to handle that hardware...

  2. DPAPI (Windows Data Protection API). There are classes for this in System.Security.Cryptography (ProtectedMemory, ProtectedStorage, etc). This hands off key management to the OS - and it handles it well. Used in "USER_MODE", DPAPI will lock decryption of the key to the single user that encrypted it. (Without getting too detailed, the user's password is part of the encryption/decryption scheme - and no, changing the password does not foul it up.)

ADDED: Best to use DPAPI for protecting your master key, and not encrypting your application's data directly. And don't forget to set strong ACLs on your encrypted key...

roo

In response to #3 of this answer from the OP

One way for authorized members to be able to view the encrypted data, but without them actually knowing the key would be to use key escrow (rsa labs) (wikipedia)

In summary the key is broken up into seperate parts and given to 'trustees'. Due to the nature of private keys each segment is useless to by its self. Yet if data is needed to be decrypted then the 'trustees' can assemble thier segments into the whole key.

We have the same problem, and have been through the same process.
We need to have a process start up on one computer (client) which then logs in to a second computer (database server).

We currently believe that the best practice would be:

  • Operator manually starts the process on client PC.
  • Client PC prompts operator for his personal login credentials.
  • Operator enters his credentials.
  • Client PC uses these to login to the database server.
  • Client PC requests its own login credentials from database server.
  • Database server checks that operator's login credentials are authorised to get the client process' credentials and returns them to the client PC.
  • Client PC logs out of datbase server.
  • Client PC logs back into database server using its own credentials.

Effectively, the operator's login password is the key, but it isn't stored anywhere.

Microsoft Rights Management Server (RMS) has a similar problem. It just solves it by encrypting its configuration with a master password. ...A password on a password, if you will.

Your best bet is to physically secure the hardware the key is on. Also, don't ever write it to disk - find some way to prevent that section of memory from being paged to disk. When encrypting/decrypting the key needs to be loaded into memory, and with unsecure hardware there's always this venue of attack.

There are, like you said, hardware encryption devices but they don't scale - all encryption/decryption passes through the chip.

I think I misunderstood your question. What you're asking for is not in scope of how the application handles its key storage, but rather how your company will store it.

In that case, you have two obvious choices:

  • Physical: Write to USB drive, burn to CD, etc. Store in physically secure location. But you run into the recursive problem: where do you store the key to the vault? Typically, you delegate 2 or more people (or a team) to hold the keys.

  • Software: Cyber-Ark Private Ark is what my company uses to store its secret digital information. We store all our admin passwords, license keys, private keys, etc. It works by running a Windows "vault" server that is not joined to a domain, firewalls all ports except its own, and stores all its data encrypted on disk. Users access through a web interface that first authenticates the user, then securely communicates with the vault server via explorer-like interface. All changes and versions are logged. But, this also has the same recursive problem... a master admin access CD. This is stored in our physical vault with limited access.

Use a hard-coded key to encrypt the generated key before writing it out. Then you can write it anywhere.

Yes you can find the hard-coded key, but so long as you're assuming it's OK to store a symmetric key anywhere, it's not less secure.

Depending on your application you could use the Diffie-Hellman method for two parties to securely agree on a symmetric key.

After an initial, secure exchange, the key is agreed upon and the rest of the session (or a new session) can use this new symmetric key.

You can encrypt the symmetric key using another symmetric key that is derived from a password using something like PBKDF2.

Have the user present a password, generate a new key used to encrypt the data, generate another key using the password, then encrypt and store the data encryption key.

It isn't as secure as using a hardware token, but it might still be good enough and is pretty easy to use.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!