My team and I are working on an API/Middleware system that will require all requests made to the middleware layer to sign the request with a public and private key for security. Most of these requests are going to be made server to server with the exception of mobile applications such as iPhone and Android apps that will directly query data from the middleware.
We have implemented our signature libraries very closely mirroring the way the Amazon Market API works using sorted query strings and doing HMAC 256 hashing with public and private keys to generate a signature that is compared upon receipt using the same algorithm.
Unfortunately, we just learned (a little late in the game) that in order to release iPhone apps through the app store you have to meet certain government criteria in order to implement the crypto libraries (read as export restrictions). Now we are being forced to decide if we should re-write our signing algorithms to use a much more simple method such as appending a private key to the query string and SHA1() hashing it for comparison.
I HATE taking a highly secure method and reducing it to just hashing in a private key, but I’m not familiar enough with security and crypto to know what I am losing in the long run by dropping HMAC 256. (Note: the query string already includes the public key)
For example, we currently order our query string and perform an operation like this to sign it:
$signature = base64_encode( hash_hmac( 'sha256', $querystring, $private_key, TRUE ) );
If we are forced to not use the crypto class in our apps then our signatures would look like this:
$signature = base64_encode( sha1( $querystring . $private_key ) );
Technically we may meet the criteria to use the library in our app, but I don’t know if I want to risk the legal ramifications if the US Gov’ment decides that what we are doing doesn’t exactly meet their legal description of ‘authentication’.
Any and all advice from you security gurus out there is much appreciated! What am I losing by using the second code example, does it make hacking our middleware any easier?
In case anyone else ends up in a similar situation, at least in our circumstance, the encryption method we are using (described above) does fit within the legal requirements and works with Apples ToS. We basically implemented an Amazon AWS style authentication, though in hindsight OAuth 1.0 would have been just a little stronger method with pre-built libraries to help along the way.
IF you were to do this type of authentication in an app today I would definitely suggest looking to OAuth.