Verified channel to server from app on iPhone

Question

I'm working on a game for the iPhone and would like it to be able to submit scores back to the server. Simple enough, but I want the scores to be verified to actually come from a game-play. With the (defacto) prohibition on real crypto with the export conditions, what would be the best way to get information back in a secure/verified channel?

All my thoughts lead back to an RSA-style digital signature algorithm, but would prefer something less "crypto" to get past that export question.

Thanks!

Answer 1

Couldn't you just use a client certificate (signed by you) and establish an HTTPS connection to your server, which has been configured to only accept connections begun with a client certificate signed by you?

Answer 2

generate a random, something fairly long, then tack the score to the end, and maybe the name or something else static, then sha1/md5 it, and pass both to the server, verify that the random hashes, to be equal to the hash.

After-thought: If you want to make it harder to reverse engenier, then multiply your random by the numerical representation of the day (monday=1, tuesday=2,...)

Answer 3

To make a long story very short, you're allowed to export digital signature code with very few restrictions. To learn more, start at the BIS export FAQ.

You probably want to look at EAR 742.15(b)3, which covers the digital signature exemptions.

Of course, I Am Not A Lawyer, and the rules may have changed in the last year.

Answer 4

One idea that might be Good Enough:

• Let Secret1, Secret2, Secret3 be any random strings.
• Let DeviceID be the iPhone's unique device ID.
• Let Hash(Foo + Bar) mean I concatenate Foo and Bar and then compute a hash.

Then:

1. The first time the app talks to the server, it makes a request for a DevicePassword. iPhone sends: DeviceID, Hash(DeviceID + Secret1)

2. The server uses Secret1 to verify the request came from the app. If so, it generates a DevicePassword and saves the association between DeviceID and DevicePassword on the server.

3. The server replies: DevicePassword, Hash(DevicePassword + Secret2)

4. The app uses Secret2 to verify that the password came from the server. If so, it saves it.

5. To submit a score, iPhone sends: DeviceID, Score, Hash(Score + DevicePassword + Secret3)

6. The server verifies using Secret3 and the DevicePassword.

The advantage of the DevicePassword is that each device effectively has a unique secret, and if I didn't know that it would make it harder to determine the secret by packet sniffing the submitted scores.

Also, in normal cases the app should only request a DevicePassword once per install, so you could easily identify suspicious requests for a DevicePassword or simply limit it to once per day.

Disclaimer: This solution is off the top of my head, so I can't guarantee there isn't a major flaw in this scheme.

Answer 5

Using real crypto won't actually buy you anything here. You basically have the reverse of the typical DRM problem. In that case, you want to prevent people from decrypting content, but they have to decrypt it to watch it, so you have to give them to key anyway.

In your case, you want to prevent people from signing fake scores, but they have to be able to sign real scores, so you have to give them the key anyway.

All you need to do is make sure your scheme requires more effort to crack than the potential rewards. Since we're talking about a game leader board, the stakes are not that high. Make it so that someone using tcpdump won't figure it out too quickly, and you should be fine. If your server is smart enough to detect "experimentation" (a lot of failed submissions from one source) you will be safer than relying on any cryptographic algorithm.