How the AWS signature works in depth

Question

I'm trying to understand how the AWS signature 4 works. I read the docs and I found a Python example where a signature is computed. I also ran into this answer which explains HMAC a bit.

I'm curious to understand what AWS does on the server side to "believe" in the request.

Are they running the same code as the example but setting the date with the parameter passed by the request and then matching the two hashes (HMAC seems to work that way)? If so, why are there so many values and two-step hash in the request (my guess is that is something related to the hash clash)?.

PS: since the approach (HMAC) uses ACCESS and SECRET keys as keys (it's symmetric key) it can be implemented only on a server side. This can't be done safely in a mobile app since the keys can be easily accessed. Is there a way to do so in a "less closed" (compared to server) environment such as a client app/mobile/etc. app?

Answer 1

The general Amazon API model involves the following steps

1. Build your API request with all the elements (within a program structure like an array)
2. Order and format the request elements
3. Calculate the HMAC of the formatted request
4. Send the full request to Amazon, with the HMAC

Amazon then takes the request, generates its own HMAC, and if it matches, it validates the request (provided your authentication tokens also match).

There's no way to ensure your security if you put your keys within an app. You would have to force any compiled client to contact your server and do the API request there.

Answer 2

The server side goes through the same process as the client to validate the request (+ a few other things e.g. checking the time/date is within 15 minutes of real time). The advantage of creating the derived signing key as described is that this key can now be used multiple times, as long as the date matches, to sign requests to the same region and service. This can be useful either to save some computation or for temporary use in a different component. Obviously you still want to take measures to secure that derived key but its loss has smaller impact than the loss of your "real" keys.

If you app needs to upload objects to S3 you might be able to use pre-signed URLs to avoid communicating the secret key to the client: http://docs.aws.amazon.com/AmazonS3/latest/dev/PresignedUrlUploadObject.html

Otherwise you will probably want to keep the access keys secret on a server and implement some other security between your clients and servers.