1

I am receiving sensitive data over an HTTPS connection and need to store this on disk, encrypted so no one can tamper with it, but for reading later on. Each user in the system has a password.

The application needs to store the information received through HTTPS in case that no internet connection is available. One-time sync and then reading a file that contains the most important information. Of course, an automatic sync will take place when a connection can be made. The information is needed to ensure the user has permission to do certain actions, and so the user shouldn't be able to tamper with the file himself.

What is the best way to go about this?

1) Topics like this, this and this suggest using a password and something like PBKDF2 to generate a key, which can be used to encrypt the key that encrypts the data. Am I right in understanding this?

2) If so, should the key that encrypts the data also be derived from the user password? To me this sounds shady, to say the least.

3) I don't know enough about disassembly, but I'm afraid of the possibility that an adversary can hijack the binary, and tamper with the HTTPS-received data, before it will be encrypted. Is this a substantial risk? Should encryption be done on the server and if so, how does this change the protocol?

The product runs on OSX, Windows and possibly Linux in the future.

Community
  • 1
Stijn Frishert
  • 143
  • 1
  • 6
  • What OS are you doing this on? – Polynomial Mar 23 '15 at 13:18
  • OSX and Windows. We may need Linux support in the future. – Stijn Frishert Mar 23 '15 at 13:19
  • Who need to have access to the data? – M'vy Mar 23 '15 at 13:20
  • Ok. Part 3 confuses me a little - who needs to access the data? What's your threat model? – Polynomial Mar 23 '15 at 13:20
  • Good point. The application (c++) needs access to the data at future points, to check whether the user has permissions to do certain actions etc. I'll update the question. – Stijn Frishert Mar 23 '15 at 13:22
  • To elaborate, not even the user himself should be able to tamper with the data. – Stijn Frishert Mar 23 '15 at 13:45
  • @StijnFrishert Then rethink your security model. You're trying to invent a DRM system, which is a fatally flawed premise. The user's computer is *theirs to control*. If your security model involves treating it as trusted (it isn't) then your security model is wrong. More specifically: if the data is *ever* read or acted upon on the user's computer, then that data (and the code) is theirs to modify, thereby entirely bypassing your security controls. – Polynomial Mar 23 '15 at 13:52
  • Alright, in that case, thanks for the honest advice :). Any pointers on where to start (reading, website)? Offline support is unfortunately a non-negotiable feature. It has to be in there, and it's the thing that's giving me most headaches. – Stijn Frishert Mar 23 '15 at 13:55
  • Ah, hadn't read @Polynomial's comment before replying. As s/he said you must enforce all permissions (more precisely, all the permissions that have an effect outside the user's own machine) on the server. If your client insists you must grant offline access to a "protected" resource, make the resource locally available only when it's allowed for the user to access it. – Steve Dodier-Lazaro Mar 23 '15 at 14:02

1 Answers1

0

Let me make sure I understand. Your user will run a local application that is capable of decrypting your encrypted file and of storing it (or parts of it) in memory in a readable format.

Your adversary is the user; the user is assumed to want to hijack those permissions stored in the encrypted file. I also assume the user is root on that machine so she can inspect your client process.

On Linux, your user can run the process in such a way that a debugger can be attached to it. The user can then run your app and add a breakpoint on e.g. the open() system call, and start inspecting instructions one by one when your encrypted file is opened by your app, all the way to the moment it is ready. Then simple prints can let the user read the content of the variable containing the information they want. No assembler programming skills needed.

The problem is that you are relying on code run by your adversary to enforce permissions, and to keep a secret. This problem is impossible to solve (in practice; in academia, you can trust certain simple programs to perform certain actions on a rogue OS provided you trust the hardware to not be tampered with, see the Haven paper in OSDI 14).

What are the consequences of an attack? What capabilities does the user obtain if granting herself all the permissions this file contains? Are these capabilities influencing (1) local data, (2) your own server?

  1. the user can already do what she wants with her local data on her local machine
  2. do permission checks on the server side, and only grant new permissions on the server side
Steve Dodier-Lazaro
  • 6,798
  • 29
  • 45
  • Thank you for your answer as well, Steve. Both @polynomial and you are right, the problem is that the **attacker** and the **user** are in this case the same person. That's the first eye-opener. – Stijn Frishert Mar 23 '15 at 14:05
  • Then I suggest you clarify your use case (what permissions?) and your expectations about adversaries. How many cheaters can you afford? How capable are your users overall? Also, look up watermarking if you want to identify cheating users who leak illegitimately accessed data (especially relevant if you know their identity and can reliably take them to court, and if you can afford to detect unauthorised accesses or data leaks). – Steve Dodier-Lazaro Mar 23 '15 at 14:10
  • Polynomial is right, I am basically creating a DRM, and the capability an attacker would gain is usage of files s/he shouldn't have access to. Regarding your questions: 1) only the application knows how to interpret the files. I am looking for a way to restrict the application to interpret, use and serve the files to the user if no access should be given, even offline. 2) I am interested in this, but have no idea where to start. More information would be welcome. – Stijn Frishert Mar 23 '15 at 14:10
  • Was still typing before you replied ;) As said, the permissions are about the user consuming the files *through* the application. What makes this difficult is that the application should also be able to do this offline, after a one-time sync. – Stijn Frishert Mar 23 '15 at 14:13
  • The files to which the user has access do not change whilst offline, right? In this case simply store locally only the files the user has permission to view. (I assume in this reply that the user has the same permissions when offline and when logged in, e.g. not like Spotify which would given you full permissions to stream but not offline play without a premium account). – Steve Dodier-Lazaro Mar 23 '15 at 15:37
  • They indeed do not change, but simply storing only those files means another user on that computer would also be able to use them, or another user on *another* computer (copy-paste) and the problem ensues. Or am I misunderstanding you? – Stijn Frishert Mar 23 '15 at 15:40
  • After some research in your second option today, I'm considering using digital signatures (private key signing server side, public key validation client side). It's no problem if the contents of the file are read by an attacker, only if they are tampered with. Could this be a viable option? – Stijn Frishert Mar 23 '15 at 15:55
  • I'm assuming that you are streaming video/audio content to a user, but I may be wrong. Looking back at encryption / the threat model, you're right that the encryption mechanism probably does not matter much (still, use a key per file so that a private server key being compromised / a user key being shared or stolen does not lead to *future* files being automatically decrypted too, if the breach through which the original keys were stolen is fixed). – Steve Dodier-Lazaro Mar 23 '15 at 16:24
  • It's safe to assume that if a user is allowed to access some data, they can copy it and share it around, and other (privileged!) users on the same machine can as well. You need a watermarking scheme to attempt to identify leaking users... I don't know who to direct you to as this is far away from my area of knowledge/competence... I'm still not clear what you want to do though as you want to protect integrity but not confidentiality. Is this some collaborative editing app, and are you trying to prevent an attacker from changing a file on behalf of a user!? – Steve Dodier-Lazaro Mar 23 '15 at 16:27
  • You've already helped me immensely, Steve. Thanks! When the user logs in, s/he sends their user credentials. I could attach these to the permissions data, before digitally signing it and sending it back. This is effectively watermarking. I am not streaming vid/audio, but distributing a product much like eg Steam does. There's no problem if an adversary looks into their game files, as long s/he can't run them. The comparison doesn't hold up perfectly, but I hope you get the idea. – Stijn Frishert Mar 23 '15 at 17:09
  • I see! Watermarking refers to the ability to mark digital content with a signature. It's hard to watermark a binary and someone who could remove permission checks from a binary could also remove watermarks. Still, you could produce somewhat unique game binaries for each user (look up malware obfuscation techniques to hide the watermark, I guess), and then be able to identify users who leaked a game onto P2P networks. Good luck doing anything about preventing distribution though :-) – Steve Dodier-Lazaro Mar 23 '15 at 17:20
  • (Final comment for me :-) ) I take it from your signature idea that you would like the binary to verify the presence of a certificate, and authenticating the user to verify the certificate is signed for her to use the product? That would probably work too, but is still vulnerable to the check being edited out of the binary. You really need to look up the literature on this specific topic / talk to industry members here. – Steve Dodier-Lazaro Mar 23 '15 at 17:22
  • Yeap, these comments have become a thread of their own, haha! Indeed, tampering with the binary and editing out the check would then be one of my worries. I'll read up on the literature and see if I can ask some industry guys on the chat or somewhere. Thanks again, Steve (and Polynomial)! – Stijn Frishert Mar 23 '15 at 18:37