Encryption Key Storage and floating point encryption

Question

I am working on a web application where I need to encrypt some fields based on user configuration and display the decrypted information. The field values can be text or integers or floats.

We are planning to use AES-128 but I am not sure of the number of keys to be used. What I mean by that is the application has activities which may contain sensitive data which needs to be encrypted. Is it better to have a single key for the entire application or generate keys on a per activity basis? Moreover, what is the best practice for storing keys? Should they be stored in the same database or in a dedicated key-value store?

At a proof of concept level, how to handle Encryption for floating point numbers? I've tried converting to strings and re-converting to floats but the databases give precision issues.

Answer 1

Encryption works on sequences of bits. It can encrypt anything that can be represented as bits. It cannot encrypt anything that has not been converted to bits. Fortunately, anything in a computer, by definition, is, at some level, a sequence of bits.

Conversion of floating-point integers into bits and back is a common thing to do, subject to some standards such as IEEE 754. Some programming languages already offer functions for doing such conversion in a deterministic, well-defined way that maximizes interoperability; e.g. in Java.

As for key management... the most important point to understand is that encryption is not some kind of magic security sauce that improves security simply by being applied more or less generously. Encryption does not create confidentiality; it concentrates it. Suppose you have some (possibly big) chunk of data D, that you want to keep confidential even against people who can peek at the data where it is stored. By encrypting D (if it is done properly) with a key K, you have reduced the confidentiality issue to that of K: if attackers cannot see K, then they won't be able to see D even if they see the encrypted version of D. But you still have to think about how to keep K out of reach of these attackers.

For instance, if your attackers can take a dump of your database, full of data which was encrypted with K, and K is also stored in the database, then encryption was totally useless. Encryption can make sense only insofar as the key can be kept out of reach of attackers through some other methods (of course, the key being small and not changing often, it makes that task easier). Otherwise, encrypting all the data becomes, in fact, some elaborate dance that will spend CPU cycles, increase development costs and appease auditors, without actually making things more secure.

Encryption is a tool, not a goal. You don't encrypt because you want to encrypt (well, unfortunately, encryption is often applied for that exact reason). You encrypt because, within a given security model, you have determined that there is a confidentiality issue for data that is stored or transferred, and encryption can help in reducing that risk by mathematically moving out large chunks of hardware and software out of the exposure window. The model and the system architecture will tell you who (in terms of both people and system components) is supposed to access the data, and who should not; in other words, where the encryption/decryption key will have to be known; this, in turn, implies what kind of key management you need (number of keys, lifecycle of keys...).

Answer 2

To expand on Thomas' answer regarding where you store encryption keys (assuming you've decided that yes, you need to encrypt):

It depends on the use case. Since you mentioned a web app, I'll limit this discussion to client-server systems.

• If the server doesn't need to be able to read the data at all and is just storing it for the user's client to access, you can encrypt the data client-side before uploading it to the server, using a key that is either directly created from something the user has (password, key file, Yubikey, etc.) and never sent to the server, or is protected (encrypted) with such a client-only key and the actual encryption key is stored on the server but only in encrypted form (this latter construction makes changing passwords, etc. easier, because you don't need to re-encrypt all of the user's data, just their master key). This model is called "end-to-end" encryption - the server that sits in the middle cannot read the data - and is commonly used for things like password managers (LastPass, 1Password, etc.).
• If the server needs to be able to access the data while it's in use, but the data should be encrypted "at rest", then you should store the data and the key in different places. A typical option here is to store the key using a hardware security module (HSM), which is a physical, tamper-resistant device that stores secrets (and sometimes performs cryptographic operations) and enforces access restrictions to those secrets. For example, you could have the user's data encrypted with a key that is stored in the HSM, but the actual data storage is on some other hardware. An attacker who manages to break into the data storage (or steal backup tapes, or whatever) gets nothing of value without also getting access to the (separate) HSM (or the key it stores). However, this provides no protection against an attacker who comes in via the (web) server, as the server already has the ability to decrypt the data.
• There are variations on the second bullet if a HSM or similar trusted separate system is impractical. You can use an external key management service (KMS), possibly provided by the same provider as your storage (most major IAAS cloud providers offer KMS functionality), which is essentially just using somebody else's HSM; it requires you to trust the provider (which is less important if you encrypt and decrypt the data without giving them the key) and you have to configure the system correctly (a recent major breach was possible because the load balancer on a company's AWS account had access to the KMS, which it absolutely didn't need), but that's true of every cryptosystem. Security is hard.