2

I have a game that I am developing which uses a locally-stored internal database. It does not matter to me whether a user can read the file (which, to me, means I don't need a symmetric cipher), but I don't want it to be possible for a user to alter it without completely breaking the game (essentially, to make cheating more difficult). Obviously file permissions alone wouldn't protect against someone on an administrator account or with a rooted device.

My thought was to use an asymmetric cipher where, opposite how it usually goes, the decryption key is public and the encryption key is private. I would then distribute the already-encrypted database and the game could decrypt it. I believe that this would prevent alterations, because the user would have to be able to properly re-encrypt the altered file for the game to be able to read it (unless they also altered the game binaries), which they wouldn't be able to do.

However, I've done a bit of searching and I can't seem to find this method mentioned anywhere, so I don't know if it is a good idea or if I've overlooked something. Is this a good approach?

Also, I want to use SQLite. I know of SQLCipher, but that uses AES so obviously that wouldn't work for me (because it's symmetric and therefore the user could intercept the encryption key by obtaining the key which is used to decrypt). Are there any public-key SQLite encryption libraries?

Cryptographeur
  • 4,317
  • 2
  • 27
  • 40
Mike Carpenter
  • 107
  • 5
  • 2
    Sounds like you want a [tag:signature] rather than encryption – Cryptographeur Mar 04 '14 at 00:36
  • Say you sign the data, or encrypt it, or otherwise have some other protection mechanism. What's to stop the user from modifying the data in-memory once loaded and verified? – Stephen Touset Mar 04 '14 at 01:04
  • @StephenTouset I don't need to make it literally impossible. If it has to be modified in-memory, that for me is reasonably prohibitively difficult. It's a single-player game, I just don't want to make it so trivial to cheat that editing a database file is sufficient, which far more people are capable of or willing to do than edit in-memory. – Mike Carpenter Mar 04 '14 at 01:09
  • Apart from editing in memory, I suppose someone could debug your application and find the key you use to sign the data. You will have to obfuscate that if you want to raise the bar a little more. – xxxxxxxxx Mar 04 '14 at 07:31
  • @izaera The database is static and would only ever change in bugfixes or updates, so that key wouldn't be anywhere in the distribution at all. No signing of any file would ever happen on any machine but my own. – Mike Carpenter Mar 04 '14 at 19:22
  • Why do you even encrypt the database, if you don't care if the user can read it? It seems to me, you are only looking for integrity of the database, and then even digital signatures are unnecessarily complex. All you need to do is a decent hash function, and then compare the database to a stored hash value (either hard code the hash value in the sourcecode, or use a keyed hash function and hide the key in your source code and store the resulting hash just anywhere else). Other variations could use HMAC, etc. – tylo Mar 06 '14 at 13:17

1 Answers1

3

What you describe is a digital , which works using methods very similar to the one you suggest. Examples include and RSA signature schemes (the second of which I would recommend you read).

Digital signatures allow you to provide a public signature that 'proves' you provided the message. As the author, you would produce database $m$ and a signature $s=s(m)$ confirming it is what you wanted. You then provide your program with an algorithm $V$, called a verifier. The verifier tests whether $s$ is a valid signature for $m$. If the signing algorithm was deterministic, an example verifier could just recompute the signature.

As with all crypto code, be wary of implementing a signing algorithm yourself, since there are lots of subtle pitfalls you may hit, such as the RSA homomorphic property.

Community
  • 1
Cryptographeur
  • 4,317
  • 2
  • 27
  • 40