I have found all over the internet that HSM is the best place to store keys, but I am left with many unanswered questions.How does interaction takes place between server,HSM and database?. Is it like the server retrieves the keys from HSM to decrypt the data from database? If we could retrieve the keys from HSM why do we need a HSM in between? we can use a secure DB to store keys.I feel like I'm missing something.
Different HSMs work differently.
Some store the keys internally but there are storage limitations. Some encrypt the keys and the encrypted keys are stored on the server.
Some will handle data encryption/decryption so the key is never outside the HSM.
HSMs also have different levels of hardening from attacks over the com port, hardware access (tampering: removing screws, etc), vibration/shock, heat, etc. When an attack is noticed the key encryption keys are erased.
Some have admin access control requiring multiple people to be present, each using a smart card and enter a password. Additional physical security may be provided by physical access control.
Is there any sort of Operating System API that can encode/decode, or securely store a secret for you? On Linux, OSX, Windows
background: You need to store a password securely. If you encipher the password with your program, an attacker could disassemble your binary and retrieve the encryption key.
If there's another way to accomplish this, I'm also open for suggestions.
OS X has that capability. It's called a keychain. The way it works is that the OS allows access to the keychain item if your app is the one that originally stored it (usually using code signing to ensure that it is the same app) or if you have set an ACL to allow specific additional apps access to that item, and only when the keychain's owning user is currently logged in. The act of signing in with the user's password unlocks the keychain, so if the user loses his/her password, the keychain must be replaced with an empty one, because it becomes worthless at that point.
iOS provides a similar keychain, but it is unlocked by the device's passcode, and the keychain is per-app instead of shared across apps, which means keys can't be shared very easily across apps unless the apps themselves explicitly request access to a shared keychain.
I would assume that other OSes have similar features.
I am looking into ways of securing the channel between my client apps and the server.
I have a rich desktop client (win) and mobile client connecting to a webservice, exchanging data.
Using SSL certificates, server and clients may trust each other. On the secured connection i can exchange username and password and therefore authenticate the user.
However i have certain circumstances where a user must connect to the server via any of the two methods without his credentials but only a literal, like say, a license plate number.
I really want to make sure that in this case i ONLY allow client connects from devices i am sure i know, since there is no further checks on the authentication and a license plate number would be a pretty common literal.
How can i ensure that only "devices" which are known to my server, can interact with my server?
If you want to authenticate the device, you'll need to find a way for the device to prove what it is, without disclosing its secret.
A system similar to a number plate would be quite easy to spoof, for anyone in a position to see that number. Depending on how much control you have on this device, you might not be able to hide it, even if the connection to your server is secured with SSL/TLS.
A potential way to do this would be to use a cryptographic hardware token (or smart card). Some of these tokens can be configured to hold a certificate and private key, with the ability to use the private key without being able to export that private key. The cryptographic operations (signing and decryption) happen on the token itself.
You can use these to perform client-certificate authentication to your server. In this case, you would know that the client has that token. This could work on the condition that you know the CAs were issued its certificates only for key pairs in such tokens: there will be a cost in administering the CA to handle this.
This would at least allow you to tie the authentication to a particular token. Whether you can integrate this with your overall device depends on the kind of device you have.
Please check if TLS Pre-Shared Keys (RFC 4279) can be used for your scenario.
I've setup a Windows Azure database with the data accessible via oData. I'm trying to work out how to secure the connection between a WP7 device and the database. By secure I mean I only want users of the app to be able to access the data from within the app.
I've considered SSL but it's quite expensive for me - is there another way of securing this connection?
Thanks!
There are multiple definitions of "secure". You will need authentication, so Azure only lets the correct users access the data. This is usually handled by a user name and password supplied by the WP7 app.
The WP7 app needs to ensure it is talking to the correct server. SSL handles this using a digital certificate. There are other mechanisms but using something based on a public/private key pair is best because you can validate you are connecting to the correct server without being able to impersonate that server. However, the RSA algorithm used in most cases is computationally expensive.
The data sent between the WP7 app and Azure also needs to be confidential, including the user's password. This is normally handled by encryption. You an choose computationally less expensive algorithm or only encrypt certain data.
The data sent between the WP7 app and Azure also needs some form of tamper detection. Otherwise someone could corrupt the data sent or received. Maybe this is something you can accept for the app but it needs to be a way that an attack cannot easily reproduce. As Shanin's Maxim says, the attacker knows the system.
The problem is that SSL gives you all of these. Yes, it can be expensive but it is one of the best general purpose solutions available. You can change the cipher suites offered by Azure using using Group Policy, code or PowerShell.
If you do not want to use SSL, you need to know what you can sacrifice. In general I would not recommend doing your own encryption mechanism or protocol because us mere humans tend to screw it up.
My company is going to be storing sensitive data for our customers, and will be encrypting data using one of the managed .NET encryption algorithm classes. Most of the work is done, but we haven't figured out how/where to store the key. I've done some light searching and reading, and it seems like a hardware solution might be the most secure. Does anyone have any recommendations on a key storage solution or method?
Thanks for your replies, everyone.
spoulson, the issue is actually both the "scopes" that you mentioned. I suppose I should have been clearer.
The data itself, as well as the logic that encrypts it and decrypts it is abstracted away into an ASP.NET profile provider. This profile provider allows both encrypted profile properties as well as plain text ones. The encrypted property values are stored in exactly the same way the plain text ones are - with the obvious exception that they've been encrypted.
That said, the key will need to be able to be summoned for one of three reasons:
The authorized web application, running on an authorized server, needs to encrypt data.
Same as #1, but for decrypting the data.
Authorized members of our business team need to view the encrypted data.
The way I'm imagining it is that nobody would ever actually know the key - there would be a piece of software controlling the actual encrypting and decrypting of data. That said, the key still needs to come from somewhere.
Full disclosure - if you couldn't already tell, I've never done anything like this before, so if I'm completely off base in my perception of how this should work, by all means, let me know.
There only two real solutions for (the technical aspect of) this problem.
Assuming it's only the application itself that needs access the key...
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...
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...
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.