Snapchat clone: How do I secure pre-downloaded notifications so that they cannot be opened outside of the app?

Question

Say I'm making a snapchat clone app for Android and iOS. Let's say that I get a snapchat from Baz. I want to pre-download the audio for this snapchat. However, as the developer, I want to secure this audio from being viewable outside of the app.

I've been thinking of encrypting it using AES with an IV and key that are both generated from a pseudo-random function that takes the user's unique ID as input. However, if an attacker found out that this was the way we encrypt our files, and had access to our PRF, he would easily be able to decrypt it and store it permanently. The thing is, I don't have enough background in cryptography or android programming to tell if that's really a concern or not. The attacker has to learn a lot about our cipher in order to break it, but he could gain pretty much all of that from looking at the unobfuscated source of our app.

Is my suggested approach cryptographically secure? What other, better or simpler approaches could I take to solving this problem?

Answer 1

In principle, there is no way to solve this problem. Snapchat is a lie. If Alice is motivated and knowledgeable, she can arrange to make persistent copies of any snapchats that she can view. There are probably dozens of ways to do this: making screenshots, reverse-engineering the app to steal the decryption key, rummaging through memory to find the data and making a copy, etc.

There's no way you can prevent a motivated, knowledgeable user from making a permanent copy. Trying to stop that is like trying to make water not wet.

All you can do is raise the bar a little bit, so that it's non-trivial to make a permanent copy (i.e., make it so unknowledgeable or unmotivated users are unlikely to succeed). That's a risk reduction approach. But nothing will be secure in principle. As a result, this is not really a question cryptography can solve. It's more a question about security. You might want to try asking on Security.SE.

Answer 2

Kerckhoffs's principle (also called Kerckhoffs's desiderata, Kerckhoffs's assumption, axiom, or law) was stated by Auguste Kerckhoffs in the 19th century: A cryptosystem should be secure even if everything about the system, except the key, is public knowledge. Kerckhoffs's principle was reformulated (or perhaps independently formulated) by Claude Shannon as "the enemy knows the system"

Answer 3

You're trying to solve an unsolvable problem. Somebody can simply take a screenshot of the picture, make a recording of the audio recording, take a video of the exchanged video.

Anybody with access to the receiving device already has access to any encryption/decryption keys you might use. They then simply sniff the connection and store the media permanently.

Answer 4

It is a concern, but not for the casual user. You could have the application only get the key when the viewing window starts and remove it when it's done, but there is no way to prevent a memory dump and then manually trying to extract the key.

There is no cryptographic or programing way to save yourself here. If you want to control the way someone can consume media which they actually do have access to consume, you are firmly in the realm of DRM and it is a losing battle.

Answer 5

Is my suggested approach cryptographically secure?

Indeed, an attacker will look at your implementation and exploit the fact that you're relying on a PRF that the attacker can access. You would at least need to separate the PRF from the rest to be secure. Especially, since you state that you would be feeding a unique user-id to the PRF during your (let's just call it) “authorization process”. If we assume that the unique key doesn't change, we're somewhat shifting towards a key-reuse problem too, which opens up additional attack vectors; especially with your example implementation. But I won't go into too many details as that would quickly become too broad. Short story is: you’re correct – your described implementation is not secure… at all.

What other, better or simpler approaches could I take to solving this problem?

Potential solutions could easily be found in public key cryptography. Or, you could try to rely on an authorized data-exchange with a webserver using a secured HTTPS connection so that the server provides the PRF functionality, but that's less secure and I'm not really sure if it would actually satisfy all your cryptographic needs.

Personally, I would advise to go for public-key crypto when it comes to a communication app like you describe it in your question, because it's the usual way to handle the situation/functionality you describe. It may sound a bit boring, but there's no need to reinvent the wheel as long as well-vetted options are available. Especially, if your cryptographic knowledge isn't (at least) on a professional level. And even then, pros will tend to go for tested crypto-implementations instead of trying to create their own crypto-solution. Chances you're messing things up (like the PRF you're relying on would be shared with attackers) is too big to take… a minor flaw in your crypto can quickly grow into a 100% insecure app.

Now, you didn't mention any programming language, so I can't point you to any specific direction, but public-key solutions (libraries etc.) are available for almost any programming language. It should be easy to find something appropriate for your purposes. And if any question related to public key crypto itself arises along the way, please feel invited to post another question here as Crypto.SE.