kbs/plugins/resource: Add ID_KEY resource backend #698
Conversation
|
I'll take a look at the code tomorrow. On a high level, what does this give you that you can't get from an existing backend? Let's say I'm an admin. I post some bytes to the plugin and get back the wrapped bytes. I give those wrapped bytes to my guest. Then the guest can get the unwrapped version from Trustee. How is that different from an admin simply uploading a secret to Trustee and then giving the client the name of the secret? Also, are you worried about replay attacks? |
The issue with this is that there's no way of preventing the client from fetching a secret that they're not supposed to. If there is more than one VM attempting to attest, there's no stopping them from requesting the secrets of another VM. This simplifies it by only allowing that VM's secret available to it. We only care about one secret in this scenario. In other words, if an attacker knows the secret name, it can't just try to request it itself. The standard backend is a bit susceptible to this. This offers isolation, as it doesn't even really store any secrets, but relies on the client to store them. It also allows a key to be derived from an HSM (not a part of this series). If the admin also has access to the HSM, they can verify their "root key" is never compromised yet was used to encrypt data (in our case, block storage).
Yep. A man-in-the-middle could sniff the URL and just replay to get the decrypted secret. This is functional but unsafe, I'm thinking of adding a ECDH (ephemeral key) exchange. The public keys could be supplied via the request's body. |
tylerfanelli
force-pushed
the
resource-idkey
branch
4 times, most recently
from
a10c871 to
cadd86d
Compare
Other plugins may want to return a value once a resource has been added to the backend. As no backend uses this feature yet, they all return a None value for return values. This means there's no functional changes to any other backend due to this modification. Signed-off-by: Tyler Fanelli <[email protected]>
Implement the read_resource methods on the backend. Signed-off-by: Tyler Fanelli <[email protected]>
To prevent replay attacks, the ID_KEY backend will receive encrypted keys wrapped with ECDH ephemeral keys. To get the client's EC key, the client will supply it via the request body. Allow the request body to be passed to the resource read handler. No other resource backends use the request body at present, so the argument is ignored and the behavior is unchanged. Signed-off-by: Tyler Fanelli <[email protected]>
To prevent replay attacks, the ID-KEY resource backend requires an ECDH public key exchange. Create a ECDH secret key and allow others to fetch the public key through a GET request. Read ECDH data from clients from the request body and use data to complete exchange. Signed-off-by: Tyler Fanelli <[email protected]>
tylerfanelli
force-pushed
the
resource-idkey
branch
from
cadd86d to
2ccfeed
Compare
|
This is now ready for review, but has a few blockers before it can be considered for merging. You will notice the final commit is prefixed by a I've included the type (as well as the associated {de}serialization methods usually found in @fitzthum When you have the chance, would you mind reviewing? |
The ID_KEY resource backend creates a new key tied to a Trustee server instance and mostly pertains to workloads that want a key unwrapping as a result of a successful attestation.
Admins can POST to the repository giving a base64 encoded byte vector as the resource tag. This resource tag will then be encrypted with the key and returned to the admin. Upon successful attestation, attestation clients can then send the encrypted data that was provisioned by the admin to the backend via a GET request. The resource tag in this case must be a base64 encoding of the encrypted data's bytes. The data will then be decrypted and sent back to the attestation client.
I will likely provide another PR in the near future allowing the server's encryption key to be derived from an HSM module for security purposes. While it won't be required, it will be preferred.