I'm working on a mobile API for something rather sensitive. The first time a device connects each user generates an ECDSA keypair. During all subsequent calls, an SHA256 hash is made of all the input variables along with an nonce or timestamp. The hash is then signed by the ECDSA key.
I do this to ensure that the user is who they claim, and it also prevents replay attacks, since each hash must be unique we also make sure it can only be used once. These hashes are byte arrays so I then hex encode them and add them to the params of the request. The method used is HTTP POST and I don't have multi-part form encoding enabled, because the hex encoded byte array should be a perfectly valid ascii string. On the device I have a test suite that validates the hash and the signature. The process is hash the input, encode the hash, decode the hash check the hash against the signature (which also just underwent the same process). It validates just fine on the device. However when I send the post request to the server, I hex decode the strings back into byte arrays (for hash and sig) the sig comes back as invalid (does not conform to spec). Note that the sig is checked for a number of attributes such as a leading byte 0x30 etc. This is where it is failing. The webserver never even gets the chance to validate that the signature matches the publickey. Now it's important to note that the mobile device is android and thus using java, while the web service is written in node and uses the npm ecdsa package. Nevertheless I've looked at the algorithms for decode and signature checking and they appear to be the same to me. Furthermore the ecdsa params are using the same named curve both on web and mobile. To my mind this means the problem is in the serialization and transmission steps. Even though the strings look identical when I view them (I have data logging on the device and server logs on the server), something must be getting munged. One alternative I had considered is using multi-part forms and base 64 encoding but that seems like overkill and later the mobile API might be used for more limited platforms where multi-part forms may not be available. Does anyone have some suggestions? This just seems to me like a problem that must've been solved years ago. Thanks! /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
