Encrypted content in games

Question

I have been having this idea of using encryption to prevent users from figuring out content in my program outside of the program itself. Like users may find textures never used in the game meant to be part of some kind of Easter egg while going though the games data. This may e.g. ruin it for everybody if posted online.

Imagine a secret room where the player have to press the correct numbers on a security door in the game, which if correct should generate the correct decryption key and then decrypting that part of the level and opening the door. Thus making the Easter egg otherwise inaccessible even when looking through the game-data since the key isn't actually stored, it's generated based on user-input.

Here is another example of what I was imagining. I have a puzzle game with let's say 20 levels, each one encrypted using a different key. Instead of storing the decryption key with the program directly allowing someone to decompile the program and find it, I instead generate the encryption/decryption key based on the solution of the previous puzzle. This way the player would have to actually figure out the puzzle before getting any information about the next level, even when looking through the game-data.

The player, if knowledgeable, could possible brute-force it "easily" given that the number of puzzle solutions is probably less that the number of decryption keys. It is really a matter complexity of the puzzle and is not very important here. Though I did post an answer regarding it over here

Is there programs/games today that has done something like this? Storing encrypted content in their games? And if not why? Is there a lot of rules and regulation about it, either at the store or country level? Does anyone see any obvious pitfalls that I'm missing? Ignoring things like user-experience, the idea seems sound to me and makes me curious why I haven't seen this before.

Edit: It may not be clear exactly what I'm saying, so here is a more concrete example.

Let's say I have a function that takes in a string of 20 characters and generates a symmetric key which I can use to encrypt/decrypt some content in the game. The only way the user could get to that content is to know those 20 characters and generate the same key. This key is never directly stored and is generated on the fly based on user input. These characters would be hidden in the game in what could be books, dialog with NPCs, maybe even outside of the game on the back of the box even.

So with 2*10^28 possible combinations to try it would probably be more likely people will find the content in the way intended rather that by looking through the game-data.

Edit 2: The content in question would be encrypted with an arbitrary and secret key before being shipped to the consumer. This key will obviously not be shipped with the game. He or she would have to somehow puzzle the key back together given a series of clues made based on the key, and that are hidden throughout the game or somewhere else. This system would however be transparent for the user as you wouldn't know the content was encrypted unless you actually looked through the game-data.

As a lot has mention this has one obvious downside in that its use case is limited. Once a single person has figured it out he/she may share it with everybody else, if not the key/solution then the content itself. However if your intention is to keep something so secret that a single person shouldn't be able to solve it and people have to work together to solve it, or you are afraid that your easter egg is so well hidden (by design) that it is more likely someone will find it in the code rather through game play. Then I think this could work great.

I would personally recommend to only use it maybe once per game and only for things that does not affect core game-play, e.g. easter eggs, a secret ending. Any puzzle would have to be so complicated or well hidden for it to slow people down enough to make encrypting the content worth it and if this puzzle stood in the way of people progressing then nobody is probably having any fun.

Answer 1

This question is asking whether it is possible (not just commercially viable or some other interpretation) to force at least 1 user to solve a puzzle instead of hacking to unlock certain game content.

To my knowledge this is definitely possible. In fact, it is bizarre to me that other answers are saying it is outright not possible, even when it has been very explicitly stated that the key is neither generated nor stored, merely read in from the game state (which could have googleplexes of possible values). The argument that "the game knows how to decrypt it" so it won't work would then imply that any open source encryption/decryption software (for example, TrueCrypt) is inherently insecure because you know "how" to decrypt containers (just enter a string based on keyboard input, it's simple right?).

In the absolute simplest case, imagine that the game itself is a keyboard simulator and it asks the question "what is the password to my encrypted files?", clearly we all agree that having the source code to the game wouldn't help. Now imagine the game asks the questions "what is the name of the largest animal on Earth concatenated with the name of the smallest animal?". Is it not clear that even having the game's source code would not help, and you still have to solve the puzzle?

With respect to whether this is possible the answer is absolute YES, this is possible.

Answer 2

It's been tried. Many, many times. There's an entire sub-industry dedicated to attempting to use encryption to keep users from accessing a program as they see fit. And it never works. The best protection schemes tend to last about a month before they're cracked, and the thing about the Internet is, once it's cracked once, it's cracked everywhere forever as soon as someone posts it. The obvious pitfall that you're missing is that in order for your program to use the data, it has to contain all of the information necessary to decrypt it, and if the computer can do that, a person with access to the computer can do that.

It's been called "the fundamental problem of cryptography": Alice wants to send a message to Bob, without Charlie being able to read it even if he gets ahold of it. The problem with the approach you're proposing is that Bob and Charlie are the same person in this case.

I can understand the desire not to spoil your users, but if people want spoilers they'll find them, and if they don't, they'll tend to actively avoid spoilers. But if you want to truly make a great game, go the opposite route: radical openness. Look at stuff like Neverwinter Nights, Starcraft, or the Elder Scrolls series, games that stay popular for years and years after release. They do so because they ship powerful design tools with the game that allow users to dig into everything, figure out how it works, and build and share their own content. A game is just a game, until it becomes a community, and communities endure.

Answer 3

I've been around long enough to know that if the content is there, someone will find it. Making it harder will just attract more determined people. The more popular your product, the more interesting it becomes. Partially because it's a challenge, partially because there are so many places you can gain "cred" by posting this kind of information.

If the key is generated locally by the game, you can find a way to cheat through the game until the point where the key is generated, or simply dig out the right piece of code. If the key is sent to you from a server on completing certain steps in the game, someone will trick your server into believing they have gotten far enough.

In the end, your game will benefit a lot more from the time you spend making it fun and engaging, over making it hard to find out what the next level color is.

Answer 4

The main reason why this ought to be on gamedev.SE is that doing this encryption has gameplay consequences.

You want the solution to one puzzle to be the encryption key for the next. That is, the actual data of that solution must decrypt the next puzzle. This means that the decryption key is not part of your game's data anywhere; it is generated by the player.

And here's the consequence. Decryption is usually binary. Either you have the exact decryption key needed to un-encrypt the data, or you do not.

The consequence here is that whatever game you design must be so narrowly focused that there is only one possible solution to every level. So your puzzle mechanics must be very carefully designed such that the player cannot solve the puzzle in a different way from your intent.

Take Portal, Test Chamber 10 for example. You're supposed to go left, do some stuff, then go right and do some stuff, all to lower a platform.

Or you can just give yourself some velocity and fling yourself up to the platform when you walk right in.

GLaDOS: So you made a puzzle game. A puzzle game that punishes the people who most enjoy puzzle games. Good job. But at least those hackers won't get at your precious data. Because people who enjoy solving puzzle games are the exact kinds of people who look up solutions to puzzle games online.

So that's totally worth it.

So, puzzle games like Adventures of Lolo, SpaceCHEM, and Portal (among millions of others) are right out. Instead, you have to design your game such that it is impossible to create a puzzle that has more than one solution. That requires a very great deal of care, and usually requires substantially restricting gameplay.

GLaDOS: So you made a puzzle game. A game that's meant to be played by people who like finding creative solutions to puzzles. And you made a game that has no creative solutions to puzzles. *slow-clap*

I'm not saying that you can't create such a game. Or that such a game can't be good. Only that such a game would have to be designed in a certain way.

Oh, and you have to design this gameplay such that it is impossible (or highly difficult) to mechanically find a solution.

GLaDOS: So you made a puzzle game. A puzzle game that's more interesting to hack than to play. Good job.

---

Of course, there is one caveat to this: the meaning of "solution". Or more to the point, what elements of a solution do you take into account?

For any game that involves a moving character, you're probably not going to use the character's exact movements to construct the decryption key. For example, if you have a puzzle game where the player needs to pick up certain items to "solve" the puzzle, you could make the key depend on the order in which those items are touched.

Of course, this runs into that problem above, where a player finds a way to do things out-of-order. Which again means you have to design the puzzle such that there is only one order you could possibly pick things up in.

Furthermore, whatever elements you use to construct the decryption key need to provide sufficient entropy to make brute-force decryption hard. Using the order-of-collection mechanic above, each new item is effectively one extra bit. If a level only has 8 items, you're doing 8-bit encryption. Which is crap; most smartphones can handle that in seconds.

Nowadays, you need at least 128 to make it even slightly challenging. Which now means that each level needs to have lots of stuff in it, yet again impacting your game design.

Answer 5

The answers here are good; I would look at it from another perspective though. What you are describing is a feature. Features have costs and benefits. The costs include both the dollar costs of creating the feature, and the "opportunity costs". Those are: in a world where you have finite dollars and finite hours and finite programmers, every feature you do means an infinite number of possible features that were not done in its place.

So the question is: can you state the costs of this feature in real terms? There are no free features, so be realistic about the costs. Are you willing to pay a thousand dollars for this feature? A hundred thousand? A million? What features are you willing to cut in order to have this feature?

I think once you start to prioritize things in terms of costs, benefits, and opportunities missed, you will realize that you have already spent too much time thinking about this feature when you could have been thinking about ways to make the game more fun.

Answer 6

The Alice Bob and Eve problem illustrates this well. As Mason pointed out in his answer, you can't keep a secret from Eve if Eve is also Bob.

Thus, any solution would consist of Bob not having all the necessary information. You would have to treat each level as an individual message, encrypted separately from each other, and have an external source of the messages for the next level that was able to gate-keep the messages properly.

But eventually, that becomes moot. If someone can play the game themselves, then can also write a program to ingest the game too. So all you're doing is forcing them to go back and forth from your external source (probably a server of some kind). Once they crack how to craft the messages to your server, it's the same old story.

But you're forgetting a key element here. It's a game. If someone cheats in a game, big whoop. You didn't write the game for cheaters. It's the same thing with quest walkthroughs or leveling guides: the people who want the challenge of figuring it out on their own will ignore the posted solutions. Even if you were able to make cracking the game impossible without playing it (we know it's logically impossible, but EVEN IF you could) it would only take one guy walking through before he posted everything necessary to beat it. So you're only delaying the inevitable.

Spend your time making an awesome game. There are Ten Things Every Game Needs and last I looked, encryption wasn't one of them.

Answer 7

I believe your idea is pointless.

When someone plays your game, they choose to play it, they are not doing it to win an award, they are doing it for fun.

Users know that the most fun comes from playing the way you meant and won't cheat, as your customers they already trust you as a storyteller.

Also as soon as someone has found the solution to a puzzle, i.e. your key, they can simply post it somewhere on the internet.
Players who want to cheat would still be able to do it.

---

However if your game present multiple solutions, like Super Mario Land secret levels, encrypting your assets will prevent an easy access those solutions.

While this seems a point in favor of your idea, in the end it is not.

Even with encryption it would still be possible to know that such secret solutions exist.
Once it is known that a secret solution exists, preventing the players from looking at the secret assets would be irrelevant as they would still want to access the hidden parts of the game through the game itself (yes, even if they have already seen every hidden texture/clip/audio/text).

You may prevent the leaking of the secret solutions existence by using some oblivious technique¹, but it would still be suspicious (why doing that if there are no secret solutions?), the players would lose interest in finding them and you would have less players, not more.
After all we can play a couple of hours more after having completed a game to trigger some Easter-eggs but we won't play a minute more if triggering them would require a titanic effort!

---

What you want to do is like a writing book where the next chapter is encrypted with a word of the current chapter, to prevent readers from spoiling themselves the ending.
Think about it, isn't it pointless?

_{¹Pretty much like VeraCrypt do it with Hidden volumes.}

Answer 8

I will not comment on commercial viability, however from a pure technical perspective it's an amusing challenge.

---

I would first note that anything that is not encrypted cannot be protected. You cannot gate the entry into a secret, crackers will find a way around the gate, instead you have to make the entire secret the gate itself. In terms of assets, this need not mean the entire textures, etc... just encrypting the plan and which are used and how is sufficient, and for performance reasons you will wish to encrypt as few data as possible.

---

Secondly, you are right that if the key is contained in the software then it will be teased from the software. Many games, when protecting content, try to use either security by obscurity or mechanisms that ensure that the game software has not been altered. Those are only delaying tactics.

Your idea of using the solution of an enigma as the key is rather interesting, however, using the key provided directly is likely to be easily brute-forced. Instead, treat the user input as a password and use a state-of-the-art password hashing scheme: the hash produced is the key.

However, even then, there is a mistake in your assumption that the key is not present in the game. If it was not, you could not steer your players toward it; therefore, rather than trying to brute-forced the safe, one could instead reverse engineer the game assets looking for clues. One potential puzzle I can think of is using textures to encode glyphs, and then the password would consist of a few of the available on the keyboard, as revealed by the locations the player should have visited (in order):

• the crux of the problem is that image recognition is still somewhat difficult for computers
• on top of which we layer the fact that CAPTCHA crackers are tuned for letters and digits, not custom glyphs
• on top of which we layer the fact that by combining multiple textures (with transparency) to reveal the glyph to the player no single asset in the game contains what the glyph should look like
• use other texture (with fragments) all over the place, but never in a way that generates a full glyph except in hidden places the player should never be able to reach

and any program to automatically extract the winning glyph combination will have a hell of a day.

---

Thirdly, the next difficulty is sharing. Once the solution to a secret is found, it will be revealed. Ideally, each individual should be handed a slightly different version of the software: one where the key is unique to their version of the game. To make it practical, I surmise it would be easier to separate the game (with its assets) from the "secrets" (encrypted) and "secret driver" (the key generator, which places lots of fragments of texture in many many different places, some of which form the passwords).

The obvious attack vector is tricking either the generator in always picking the same password or tricking the verifier in always accepting the same password (by downloading someone else's secrets file, for example).

Here, a potential solution would be to link the files to the user's account, and to salt the password as is usually recommended:

• when the user requests a set of files, randomly generate a salt and as many passwords as you have secrets then create the secret assets (you may want to limit this process to once/day/user for example, to avoid overloading your server)
• store the timestamp of the generation and the salt into the user's account information
• send back the timestamp and the personalized secret files to the user

Then, when the user is ready to submit a password:

• have the user log in (if she was not already)
• have the software send both the timestamp and glyph password
• if the timestamp is different from the one stored, advise the user she is using an obsolete set of secret files
• if the password has already been attempted too many times, advise the user she is using an obsolete set of secret files
• otherwise, hash the salt+password to produce the key
• otherwise, send the key back to the user so she can see her personalized files
• increase the number of times this password was attempted by this account

The goal here is to impede account sharing as much as possible:

• sharing an account to generate secret files is (a) limited, because only one can be generated per day and (b) useless, because the latest generated makes the other obsolete
• sharing an account and distributing the associated secret files is useless, because a given password can only be used N times before it doesn't yield the key any longer

And we are nearly there.

---

Finally, even there, a cracker could release a modified version of the game in which the secret assets are decrypted and directly integrated (bypassing your careful verification scheme).

The solution is simple (and makes nearly everything above obsolete¹): do not trust the client.

Create a leaderboard on your website, and keep track of the progress of players in their account. Players can claim they have finished the game all they want, but unless their account reflects this, everybody knows they've been cheating...

... this is called social pressure ;)

¹ Except the texture positioning file, which we used to prevent a program from guessing the key and yet make it possible for a user to obtain it.

Answer 9

It's an interesting idea; a variant on the puzzle discs and enter-the-word-from-the-manual copy protection systems. I think some of the "ARG" games work like this, where it's sort of understood that the players are acting collectively against the game designer.

Obviously once the first person decrypts it they'll publish it on the internet.

Generative or procedural content can work the same way: you don't see the same world as another player unless you share a "seed".

I can't see any legal problems with it, although Apple may reject it from their App store and you may have to provide the solution to get it approved on games consoles.

Answer 10

Contemplating extra security measures is entertaining, but it doesn't add concrete value to your product – it demonstrates your niftiness to the crackers that encounter your product. By principle, your antagonist will catch up with you.

Contrary to developers who thrive in creativity, crackers are analytic people – they can intuitively exploit your program. When developers tend to excessive security measures, they are in denial – that the cracker could reverse their protection scheme, again.

Whether you want to participate in this background-competition, that is your call – but don't let it distract from your end-product, which must please the customer. A quirky encryption scheme which turns the game into a slug doesn't help.

Answer 11

Mason Wheeler has it right: you can't do it. Someone can always reverse engineer your game if they want to.

You do not need to "protect" your game anyway in the way you describe. As soon as one person finds the Easter egg the secret is out of the bag. If each copy of the game has a different Easter egg, then only the hacker copy will be known. Do you really care that one hacker out of 1000 people found the Easter egg without going through gameplay?

Copyright law is such that noone can make money off your game without risking a serious lawsuit, so copyright protects you.

As far as random users putting your textures on their forum avatar, so what? Consider it grass roots advertising.

Getting obsessive about "protecting" stuff will just distract you from difficult realities like: making the game.

When I see people with no product talking about their IP protection schemes for things that don't even exist, its kind of a walkaway moment for me because it raises a huge bullshit red flag over the whole project.

Answer 12

Some possibilities:

• Plain old code obfuscation. It won't make the code impossible to decode but at least it will be hard.

• Server-side solution. You send some special commands to the server and the server can send you the code... or even download a DLC.

• You can use Steganography to hide executable code in other content.

This won't make your secret 100% secure but it seems that nobody will even loose money if the secret is revealed.

Answer 13

It is useless just as any other schema where you store both key and algorithm on client. If you ask "where's the key, I rely on users's input and don't store it myself?", remember that your puzzle have rules and resources by its definitions - it is solved by some algorithm, not by bruteforcing. This exact algorithm and its resources IS the key generation algorithm that you've just hardcoded into the game in obfuscated state. Anybody can retrieve your "non-existent" key by just writing a small program that solves your puzzle according to your rules.