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.

  • 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. 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. Mar 23 '15 at 13:22

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
  • 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. 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). 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. 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. 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). Mar 23 '15 at 15:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.