This is neat, although it throws a wrench into my recent move encrypt my AWS secret access key with my TPM to prevent the key from being used anywhere besides my laptop[0].
[0]: https://github.com/psanford/awsv4signer/tree/main/examples/t...
[0]: https://github.com/psanford/awsv4signer/tree/main/examples/t...
We haven’t released the code yet but are in the process. If you think this could work for you or you’d just like to see how we did it DM me on Twitter @timmattison and I’ll give you the code ASAP.
The TPM is a good option because every non-Mac ships with one already (and there are similar facilities available on macs).
[0]: https://github.com/tpm2-software/tpm2-tools/issues/1597#issu...
On the auth side, the major change since then is that you can use the IoT credentials provider to provide certificate based auth to all services (https://docs.aws.amazon.com/iot/latest/developerguide/author...). You don’t need to be using any of the other IoT services. It was created to make it easier for devices to use AWS services but can be used by anyone/anything.
What we did was combine the AWS CLI feature to source credentials from an external process (https://docs.aws.amazon.com/cli/latest/userguide/cli-configu...) with a script to do the certificate based auth. This allows you to obtain STS credentials using a certificate and pass them to the CLI (access key, secret key, session token). Your secure hardware just needs to do the normal work of assisting in the mutual TLS auth which in our case was done with curl and Zymbit’s OpenSSL engine. We are releasing that code along with a SoftHSM2 setup so people can see how it works in a test environment.
It's not as good as having something that supports a hardware token, of course, but it's better than the default awscli suggestion to keep the secrets around in plaintext either on disk or in env vars.
Singular it does, per IAM user.
I'm not claiming it's ideal, but it works, with one Yubikey per IAM user:
https://aws.amazon.com/premiumsupport/knowledge-center/authe...
Thanks, but you cannot[0] use hardware keys on the terminal.
However, that secret is no longer used for the signing. Instead it's combined with a date and service-description to generate a public-private keypair, which is itself not secret (both AWS and you can derive this if you know the algorithm). Your requests are now signed with this private key (client side) and can be verified by the services with the public key (server side).
AWS still knows your secret, but it keeps it in a more secured location verses out on the farms. The farms would need a way to request your public key for the day from the secured location, so they can verify the sender. But, the farms no longer have access to your secret key, so cannot sign other requests masquerading as you.
Once the key is loaded into the TPM as an HMAC key, you can no longer get the plaintext key back out. You have to use the TPM to perform any HMAC operations using the key.
At least on MacOS it uses keychain. There are other storage backends for other platforms.
With the secret stored in a tpm it cannot be extracted. Instead you ask the tpm execute the hmac() function on your behalf with the secret only it can read.