2

So, I'm just a programmer -- I don't know much about cryptography so bare with me and my lack of knowledge in this realm. But essentially, I'm wanting to cache data that could be potentially volatile ( ie -- change or delete over time ). One solution I've thought of would be to encrypt the data ( server side ) and administer the key to the client -- here's the catch though: it expires within a given time frame ( ie, two or three days ). It can be refreshed or renewed, at every connection to the server but if the key is not refreshed, then ultimately I would like it to not be any good. That would mean the encryption method would need to use time as a factor ( so perhaps using a modulus / floor / round operator based on the current time to give you the actual encrypted data / things necessary to fully decrypt the data ). My only concern of course is that clients can modify the current time on their system. Perhaps I can find a trust-worthy source for the current time.

( Also, I understand that it is fundamentally silly to give data to a client when it's expected to be taken away, but I still am interested in finding a solution to this. ).

Does anybody know of something, or is there something that can steer me in the proper direction / achieve similar effects to what I'm after?

Improve this question
5
  • You are right about the time. If you were to go down that road you'd be much better off with a random IV. You describe what you think may be an acceptable random generator but you correctly note that it's not. So, go with a CSPRNG and that'll solve your problems.
    – rath
    Commented Oct 13, 2013 at 5:12
  • If I read this correctly, you are trying to prevent the client from decrypting data at a date/time after some expiration. Before that date/time, the client can perform teh decryption. Further you are relying on the client to behave properly, and neither decrypt and duplicate the data before expiration nor feed the decrypt function a fake data/time which would properly decrypt. Does that sound about right?
    – atk
    Commented Oct 13, 2013 at 22:55
  • Correct. Although, ultimately I could never prevent the client from simply screen-shotting something. But I would, at the very least, slow them down from extracting formatted data.
    – Full Metal
    Commented Oct 14, 2013 at 1:43
  • @FullMetal: if you trust the client to play by the rules, why bother with some complex crypto scheme? Wh6 not just package some metadata in the download that says "please don'r read after date"? If you don't trust the client, why do you think that adding such a small amount of work for your attacker and such a big amount of work for yourself will be successful?
    – atk
    Commented Oct 14, 2013 at 12:13
  • That's a very good point. I'm mostly doing this as a proof-of-concept ( Maybe I'll instead choose to use a native implementation instead of something so easily / readily read as javascript ). Perhaps, I could use Javascript to primarily fetch resources, then use NACL ( Native code in browser ) to decrypt it. But you're definitely right -- the trust factor is sort of self-defeating in the end.
    – Full Metal
    Commented Oct 14, 2013 at 18:47

1 Answer 1

Reset to default
1

The data (including the key in any form) are passive and they can not verify what time it is now. So it must be a decryption tool that will verify the time. With this in mind you can put the time right into the key (and wrap it with some static key for increased security).

The decryption software residing on the client side will become a weak place, though. Time can be changed by the user but that's not a problem - you can use TSP protocol (RFC 3161) to obtain current time from the reliable TSP server. However the part that will decrypt the key, extract time and verify it becomes the weakest link. You will have to protect it seriously to prevent deobfuscation, decompilation and consequent modification. While no universal solution exists to this task, tools like VMProtect (I mention it cause it uses built-in virtualization) make hackers life a bit harder and will save you from tricks of the average user.

Let's try to invent the key scheme now.

The encryption key K1 is used to encrypt the data. That is the random session key, possibly different for every client installation.

The key K2 is used to encrypt K1. K2 is constructed as "random_part_X + f(random_part_X + year + day_of_year mod 3), where f can be an HMAC or just a hash (that requires additional thinking). Encrypted_K1 and random_part_X are shipped from your server every 2-3 days. It is encrypted with "static" K3 key stored in your decryption software.

When the client-side software needs to use K2 key, it decrypts K2 and has random_part_X. Then it requests time from the trusted source and performs f(random_part_X + year + day_of_year mod 3) thus reconstructing K2. Now K2 is used to decrypt the received encrypted_k1 and obtain K1 itself. Finally K1 is used to decrypt the data.

If the attacker gets K1, he will be able to decrypt all of the data. So the scheme (a) needs to be complicated further, and (b) you might want to encrypt different pieces of data with different K1 keys. And then again you need to care about possible de-obfuscation, decompilation and debugging of the code that gets K1.

Improve this answer
3
  • > You will have to protect it seriously to prevent deobfuscation, decompilation and consequent modification Well, this is javascript we're talking about. I guess I could replace the method names with something really obscure ( lol_hurp_mothers ) and make them scratch their heads for a bit. But at the same time, nothing could also stop them from simply filtering their http requests / dns and spoofing data.
    – Full Metal
    Commented Oct 14, 2013 at 1:47
  • Although, I do like this encryption flow you suggested, and I did not know about RFC 3161 ( there should be a book published on all of those things, really ). The primary reason of the cache is to permit offline/disconnected access, so at that point it would be necessary for me to trust the client. I guess what I'm looking for is ultimately very difficult to engineer / impossible without some degree of vulnerability -- especially with javascript and a web browser. ( I may look into NACL, however ).
    – Full Metal
    Commented Oct 14, 2013 at 1:52
  • @FullMetal Indeed with JavaScript on the client you are pretty much out of luck unfortunately - you will need to write plenty of cryptographic stuff in JS and JS-in-browser in general is not for cryptography (see matasano.com/articles/javascript-cryptography ). On the other hand, if the data is just the cache and you don't store all data on the client, then probably there's no reason to bother too much about protection.
    – Eugene Mayevski 'Callback
    Commented Oct 14, 2013 at 5:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .