How does AWS Secret key and access key work

Question

Those keys are too short to be public/private RSA keys. What are they? How does it use them to authenticate the client?

My guess is:

1. AWS access key ID is a form of unique user/account identifier
2. AWS secret key is like private key
3. When AWS CLI sends a API request, the payload is signed by generating an HMAC with the secret key as the key
4. The HMAC, AccessKeyID and the payload is sent to AWS service
5. AWS service verifies the identity of the sender and integrity of the message by recomputing the HMAC code.
6. If it's verified the request is accepted and processed.

Is this accurate? Why does AWS do this instead of asking user to upload a RSA public key? Why is this safer?

EDIT: I think this is how it works -- https://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html#ConstructingTheAuthenticationHeader

Answer 1

AWS has designed their own custom authentication algorithm. You are referencing the older signature version (v2), a newer one (v4) was released in 2014. Details are outlined here: Authenticating Requests (AWS Signature Version 4) . A major difference is that the request is not signed with the secret itself, but with a signing key which is generated using the secret. It also uses HMAC-SHA256 for signing.

Why does AWS do this instead of asking user to upload a RSA public key? Why is this safer?

Using asymmetric keys would be safer since AWS would only store a public key instead of the secret, which is stored by both the user and AWS.

Answer 2

Your description is accurate. I can't speak on behalf of Amazon but I'm sure the main reason why they chose to use this rather than using X.509 certificates; and I mean it with all due respect: People are stupid.

The main targeted user base has no knowledge about this sort of thing (just look at the thousands of "open" MongoDB-instances where you can read all the personal data of millions of people without authentication), so requiring the creation of private keys and public certificates will lead to a lot of troubles, security and support wise. With the implementation as it is Amazon can provide you with keys that are created by using "good random" and a short documentation how to use it to access their services.

Just google for any description, how to set up TLS-client authentication that includes the creation of the certificates and compare it with the documents explaining how to set up the same for AWS. Amazon wants you to be able to use their services as fast as possible so you can start paying money as fast as possible and don't bother looking for other service providers that might offer the same.

Another reason is that asymmetric ciphers require by large factors more resources than symmetric ciphers or hashing algorithms without any additional benefit for this particular use case. Amazon already knows who you are and doesn't need all the fancy stuff that can be implemented with X.509 (key usages, CRL-lists, etc.)

Answer 3

Question/answer one by one:

1. AWS access key ID is a form of unique user/account identifier

• Correct, AWS access key is a unique identifier for a user. BTW, in some cases, it could be considered as sensitive data, sharing access key can lead to tracking like who accesses which systems and when, check this post for more details. If you are an administrator, regularly rotate the access keys for IAM users

2. AWS secret key is like private key

• Correct, consider your Access key as user name and Secret key as the password.

3. When AWS CLI sends a API request, the payload is signed by generating an HMAC with the secret key as the key
4. The HMAC, AccessKeyID and the payload is sent to AWS service

aws-cli using signing API Requests technique. It sends HTTP Authorization header with the next payload:

• Algorithm you used for signing (AWS4-HMAC-SHA256)
• Credential scope (with your access key ID)
• List of signed headers
• Calculated signature. The signature is based on your request information, and you use your AWS secret access key to produce the signature. The signature confirms your identity to AWS.

Example:

GET https://iam.amazonaws.com/?Action=ListUsers&Version=2010-05-08 HTTP/1.1
Authorization: AWS4-HMAC-SHA256 Credential=AKIDEXAMPLE/20150830/us-east-1/iam/aws4_request, SignedHeaders=content-type;host;x-amz-date, Signature=5d672d79c15b13162d9279b0855cfba6789a8edb4c82c400e06b5924a6f2b5d7
content-type: application/x-www-form-urlencoded; charset=utf-8
host: iam.amazonaws.com
x-amz-date: 20150830T123600Z

Another option is to use a query string, in this case, the content of HTTP Authorization header will be encoded in URL.

Both aws-cli and aws sdk already provide these steps under the hood. But if you want to make your own software for low level interacting with AWS, follow these steps:

• Create a Canonical Request for Signature Version 4
• Create a String to Sign for Signature Version 4
• Calculate the Signature for AWS Signature Version 4
• Add the Signature to the HTTP Request

Under the hood, tools like aws-cli rely on boto-core. Here you can find the implementation of steps above.

5. AWS service verifies the identity of the sender and integrity of the message by recomputing the HMAC code.
6. If it's verified the request is accepted and processed.

• Both statements are correct.

Why does AWS do this instead of asking user to upload a RSA public key?

More or less I agree with @Lothar's reflections.