1

In a white-box attack context (e.g. PC, tablet, smartphone), there is no trusted entity, which can be used to guarantee some reasonable security. TPM is not considered a solution because it is not available on all platforms and is also disabled by default. This means that it is not possible to store a hash of a resource file, or some secret-key associated with this file on the system, such that the attacker (e.g. malware), will not be able to read/write/modify it.

How would one be able to detect any tampering of a non-confidential, small, resource file, in such a white-box attacker context?

My only guess is via white-box implementations of a cryptographic cipher such as AES. However, this is not a really secure approach and also requires a lot of extra memory resources.

Benny
  • 135
  • 6
  • Is the resource file modified on the system or is it static (never changed on the white boxed system)? – Uwe Plonus Jun 21 '13 at 07:30
  • The resource file is frequently changed, when the application that uses/needs it is running. This application would ONLY need to detect if the file has been changed when it starts. – Benny Jun 21 '13 at 07:39

1 Answers1

3

You can't.

Once you hand a user a device, it is theirs to do what they wish with. Even if you enforce it in hardware, a smart and well-equipped user would still be able to determine a work-around. This is the same principle that stops DRM from being effective.

If your security model relies upon integrity of a file being maintained regardless of malintent by the real owner of the device, then you need to change your security model. As someone once said: "a computer is only as secure as its administrator is trustworthy"

Polynomial
  • 132,208
  • 43
  • 298
  • 379
  • I totally agree with your point. However, I'm looking for a solution that would merely cause the attack to require more than a few days on average, on current commodity hardware. This is because software updates are done regularly every few days. In my attacker model the human user of the system is not the attacker. The human user is actually the victim. The common attacker is malware that may be unwillingly installed by the user. – Benny Jun 21 '13 at 09:02
  • It just doesn't work like that. You can't protect against physical access to the device, or unrestricted privileged remote access to the software. You might be able to make the latter *harder* if you enforce stuff in hardware, but there are always exploits. It's not something crypto can solve. – Polynomial Jun 21 '13 at 09:08
  • Sure, you are right that physical or remote access cannot be restricted. However, if the solution would be based on a good software-diversity technique, then the human cracker would have a very hard time generalizing the attack into malware that s/he can distribute to other users of my application. I'm not worried that the security gets broken on one or a few devices. The content of the resource file is not secret. My concern is that the attacker will be generalized into malware that breaks security so fast that the user/victim will not be able to notice it. – Benny Jun 21 '13 at 09:18