I was fortunate enough to attend Velocity in Amsterdam this year, which followed several major themes – one of which being security. This post was inspired by a presentation given by Alex Schoof entitled “Managing Secrets at Scale”.
Alex covered many areas, including how to control the use of secrets, how they can be made highly available and how to scale their use. However, I was most interested by how to store secrets securely as this is a problem I am facing in a project currently.
Everyone knows that secrets should be encrypted when stored. However, this soon becomes a chicken and egg problem. Ultimately a ‘master’ key needs to be made available which can decrypt the stored secrets. Three groups of methods for key storage were discussed: hardware solutions, key management services and secret splitting.
A Hardware Security Module (HSM) such as iOS’s Secure Enclave is capable of generating and storing cryptographic keys securely. It is not possible to request private key data from the module. Instead, a well defined API is used to perform operations with those keys, such as signing or decryption. This ensures the keys never enter the systems memory, making it much more difficult for an attacker.
Meanwhile, a Trusted Platform Module (TPM) is a chip which can be embedded onto a motherboard. TPM’s have a key burnt into them at production time and may be capable of generating and storing other keys. Microsoft’s BitLocker, for example, can utilise an onboard TPM to reduce the attack surface of an encrypted drive.
Back on the mobile scene, as of Android 4.3 hardware-backed storage is supported. However, this is dependent on the manufacturer supplying a hardware solution. There are also other scenarios where a local hardware solution is not an option – such as in the cloud.
Key Management Services
Services such as AWS KMS and Azure Key Vault provide key management similar to a HSM but over a network. Instead of storing your keys locally, keys are stored in their own solution stacks; the responsibility of securing secrets is delegated. This means you don’t have to worry about them (as much).
A key benefit to using services like AWS KMS or Key Vault is that they are guaranteed to have a certain level of availability and scalability. Audit logging is also often taken care of and the likes of Microsoft and Amazon are quick to show off their compliance with standards such as FIPS 140-2.
A third option is to split up a secret and distribute it amongst several parties. For example, a secret could be split into three pieces; one piece could be stored in a hardware solution, one piece in a persons memory and another on a USB stick. Only when all three pieces are brought back together could the secret be used.
One way to split a secret is to use Shamir’s Secret Sharing method. In Shamir’s method, the secret is split into n pieces and at least k of these n pieces are required to reconstruct the key. If k is equal to n, all pieces must be present for reconstruction.
Shamir’s secret sharing works by defining a polynomial function over a finite field whose size, p, is prime and greater than the secret S and the number of pieces required, n. If we want to ensure that at least k pieces are needed in order to reconstruct the secret, the polynomial must be of order k-1. The secret becomes the constant term and the values of the coefficients a1 to ak-1 are chosen randomly from the fields set.
f(x) = S + a1x + a2x2 + … + ak-1xk-1
The n distributable pieces become: Di = (xi, f(xi) mod p) for 1 ≤ i ≤ n
To reconstruct the secret, we can use the Lagrange form of the polynomial:
f(x) = ∑ f(xj) ⋅ lj(x) (0 ≤ j ≤ k)
where lj = Π (x – xm) / (xj – xm) (0 ≤ m ≤ k, m ≠ j)
Then, as long as we have k pieces, we can recover the secret by substituting x=0.
Of course, storing a secret securely is only a small part of creating a secure system. A secret’s use must be restricted and its transmission must be treated carefully, if not avoided altogether. The ability to revoke and cycle secrets is also often necessary.
Taking this into account, it is clear that security can not be an afterthought. Whatever the security solution is, it should be considered at the very start of development to ensure integration is as simple as possible.
Alex Schoof’s slides can be found here.