3
$\begingroup$

I am trying to achieve the following:

Encrypted files are stored on users filesystem. The user uses my client to authenticate against a server. Once he is authenticated successfully he gets a token to decrypt the files.

Things I want to ensure: the user should not be able to cache the token for later use. like a one time token, so that he is no longer able to decrypt the files in some time in the future.

The client and server do only exist in my head, so anything that is possible can be applied to it. I am looking for algorithms/protocols to achieve my requirement.

$\endgroup$
1
  • 1
    $\begingroup$ I don't think you're asking for what you really want. I think you're asking for what you think will give you what you want. You'll get a better answer if you state requirements rather than implementation details. (For example, it's not clear why you care whether the user decrypts the files in the future or stores the decrypted files and simply accesses them in the future. Isn't the effect the same? So why allow the user to decrypt the files now but not later?) $\endgroup$ Commented Jun 1, 2012 at 15:43

2 Answers 2

6
$\begingroup$

I don't think that's possible, at least not without the kind of intrusive mechanisms you'd need for reliable DRM.

Basically, if the user gets a key that lets them decrypt the files, what's to stop them from just decrypting them all and keeping the decrypted versions?

The only way this could possibly work if you only allowed access to the files through a program you control, which would present them to the user in a way that makes them hard to copy (like rendering video directly to the screen). Then you'd need to prevent the user from modifying the program or running it under a debugger, or finding some way to copy the data anyway as it's presented (e.g. through the "analog hole").

All that's easier said than done — and once you've done it (as well as you can), you may find out that it still won't stop a clever and determined user from copying the data, but that it will piss off ordinary users because all the restrictions make them feel like they're working in a straitjacket.

$\endgroup$
2
  • 1
    $\begingroup$ exactly. i think DRM is the keyword i was looking for or even IRM. and of course, i want to protect corporate data, so the ordinary user argument does not count! ;-) $\endgroup$
    – esskar
    Commented May 29, 2012 at 20:22
  • 5
    $\begingroup$ @esskar Don't bother spending money on draconian DRM that won't actually do anything. Instead, get a lawyer to draft up an NDA for all staff that have access to your valuable assets (e.g. source code, design specs, etc) and implement strong working practices to ensure that data can't be leaked accidently. Keep an air-gap between your development network and your internet-access/email network. That way, you can take disciplinary action if someone violates procedure, or legal action if someone violates their NDA. $\endgroup$
    – Polynomial
    Commented May 30, 2012 at 8:36
1
$\begingroup$

In a practical sense you could use a HSM for this where an asymmetric (RSA) private key is stored. In at least some HSM's it is possible to set a maximum usage count. You could program a similar usage scenario within a smart card. The HSM and smart card then implement the trusted execution environment necessary for the question to be solved.

So such tokens exist, but they are actual hardware tokens, where a certain level of trust is embedded in the crypto-system itself. You could of such a system as a system where the hardware token + supply chain of the HSM / smart card acts as trusted third party.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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