Encrypting my data and keeping it safe in Unity

Question

I have a RPG kit in the Unity Store and I wanted to add some protection for the consumers for when they want to save pretty much any information. From the gear the character is wearing to inventory, bombs, keys, locations where objects were moved etc. I already have all that working it is just I was using the Unity C# serializer but ran into the issue when I deserialize when I add more to the class that holds the saved information. So I used JsonUtility, I turned the saved class into Json data and was going to put it in PlayerPrefs but I wanted to offer some extra protection for the consumers so I looked into AES and Asymmetrical Encryption.

This is my quick run down and as of now for when I save my data :

1) I generate a random string for my "Key" with AES.
2) I Symmetrically Encrypt my data (AES).
3) I then Asymmetrically Encrypt the AES "Key".
4) Store the Asymmetrically Encrypted "Key" and the AES encrypted data in PlayerPrefs.

I feel though since I stored the Asymmetrically Encrypted "Key" in PlayerPrefs that it still holds the same amount of security as if I was to just store the random generated AES "Key" in PlayerPrefs as the key is there for any reversal process.

Am I correct in thinking this? Is there a step I am missing or need to change?

Answer 1

I'm going to start off with a slightly dickish response, namely, if you are uncertain about this stuff you should focus on finding a (reputable) library that will handle these sorts of things for you. I'm not all that familiar with Unity, so if such a library exists, I hope someone else can provide an answer pointing to it. As I'm sure you are aware, even major corporations mess these kinds of things up.

That said, I don't really understand from whom you are trying to protect this data. (I also don't understand why this would be sensitive but that's not important.) As far as I can tell the PlayerPrefs are stored locally so the kinds of attackers you are considering are 1) other applications on the device, 2) other users on the device, 3) attackers with physical access to the persistent memory e.g. the SD card. Most of these are already protected against via operating system mechanisms. But to be completely clear, doing encryption yourself will increase protection beyond what the operating system is doing. The argument comes down defining a threat model and doing the cost-benefit analysis of mitigating the threats. The cost-benefit analysis will include the development and maintenance costs for you, and the key management costs for the user, e.g. if the user loses their key, they lose their data and nothing can be done about it.

Addressing your second to last paragraph, if you just stored the symmetric key with the encrypted data you would have no security. You might as well store the unencrypted data.

Your four step scheme should work (though there are details you need to get right), but it seems to be overkill. If the symmetric key is encrypted, then I'll need to have access to the private key to decrypt it. If I can securely store the private key, why don't I just store the symmetric key where I store the private key? Alternatively, unless it is a large amount of data, why not just encrypt the data directly with the private key? Or even, if I can store keys securely, why don't I just store the data there?

I only see something like your four step procedure being useful if the asymmetric keys are managed by the OS but no symmetric key management is provided, and you need to encrypt large amounts of data. In fact, decent crypto libraries will usually handle automatically generating a symmetric key and storing it encrypted with the ciphertext so you don't have to worry about it and you don't need to worry about size limitations or performance.