1

I guess the example can make it easier.

Assume each Client on a network has an identifier(some alphanumeric sequence) which identifies it uniquely on the network. Each time the Client corresponds with the Server over the network(encrypted), the Client sends its identifier to identify itself. Now if somehow this identifier is read off the memory of the device in some way, that device can be impersonated.

Is there any way this weakness in a system can be done away with? We sure can force the Client to change its identifier at end of every session and inform the Server of the new identifier, but this would again remain stored in memory.

I hope I have managed to explain in clear enough. Thanks for your time and attention already.

/////////// Edit /////////// I am strictly looking for a solution which works in the case of a completely subverted Client program/OS/environment, which means the attacker can wilfully hook into any of the system events and processes.

/////////// Edit /////////// I'm thinking of using a combination of these ideas. So in case someone comes looking here, this might help. http://en.wikipedia.org/wiki/One-way_function & http://en.wikipedia.org/wiki/Oblivious_transfer

kumar
  • 211
  • 3
  • 11
  • 3
    There is no real solution in the case where an attacker has unrestricted access to the client's physical hardware. The only near solution is to attempt to detect tampering and in response wipe identifier and disable the client. This protect leaves you vulnerable to attacks on client availability. see [Anti-Tamper-Protection](http://www.onr.navy.mil/en/Media-Center/Fact-Sheets/Anti-Tamper-Protection.aspx) – this.josh Feb 02 '12 at 09:35
  • Write your own firmware on ROM. Encase in solid lead. ;) – StrangeWill Feb 06 '12 at 17:08

5 Answers5

4

All modern authentication systems assume at the basic level that the client holds some type of information that can be used to prove it’s identity and that information should be kept secret. That could be a user name, password, public/private key pair, etc...

If that information is compromised then the authentication chain is broken and the secret needs to be changed.

In your questions and comments you mention that the client is completely subverted which basically rules out an authentication system and that user interaction is not possible. Obviously this is no small matter and could be made much harder with other layers of protection to prevent the host from being compromised in the first place.

However assuming the client is completely compromised the question is not how you implement an authentication system but how you perform integrity verification of the client. This could be achieved through behavioural analysis more specifically in the realm of Intrusion Prevention/Detection. If you can’t trust the client then use of an endpoint agent on the client would not be an option and your detection method would need to be completely external from the client.

This leaves you with possibly two options that I can think of:

  • Network based Intrusion Prevention to quarantine suspicious clients from the network.
  • Hypervisor based protection such as VMware’s vmSafe API (vmSafe) which allows out-of-box inspection of a client. Which means that you can hook into an API that allows you to inspect what is running on the CPU and in memory without being inside the attack surface and vulnerable to an attack. In this case protection for root kit and virus detection is already available.

In both cases your exact requirements may not be met, it is unclear your exact intent however it is possible. However these solution would still be used with an authentication system on the client, just used to help detect if the client is compromised.

Hope that helps, if not perhaps you can give some specifics on the exact implementation.

Bernie White
  • 2,866
  • 17
  • 18
  • You got it right. This much is clear after all the conversations on this page that I need to be looking for integrity verification. Now am finding how to fingerprint the execution of the client program or possibly tap into behavioral analysis from a remote site to effect what I want. Thanks for the hints. – kumar Feb 02 '12 at 13:31
  • Yes basically you will need to build up at whitelist of the good and deny, block execution or quarantine based on any behaviour that deviates from that baseline. – Bernie White Feb 02 '12 at 19:25
  • You should plan how you handle baseline shifts for legitimate reasons such as OS and application updates. – Bernie White Feb 02 '12 at 20:18
3

No. The model you've described dictates that you always trust the client.

Anything {hashing or keying or computation of a new value} done by the client will at some point be resident in the client's memory.

TristanK
  • 423
  • 2
  • 8
  • Are there any known methods or systems wherein other clients present in the network help authenticate a client to the server which doesn't involve the infected client actively taking part in the process? – kumar Feb 01 '12 at 21:47
  • I think it'd help to describe what your requirements are in terms of "authentication". If the client doesn't take part, what are you authenticating, exactly? – TristanK Feb 01 '12 at 23:46
  • By authenticating a client to a server I mean, the server can unambiguously deduce that the client isn't compromised and that it can be trusted to be the only one in possession of its identifier. So any check/test which fails whenever an infected/zombie/impersonating client tries to connect to the server is good to go. I realise the answer am looking for is near-impossible, but I would like to persist for a little longer. – kumar Feb 01 '12 at 23:54
  • 3
    That is not possible. – TristanK Feb 02 '12 at 06:49
2

Most likely there is no solution to the problem you have sketched.

But... One approach you could look at more closely is to use a TPM. A TPM is a piece of trusted hardware that can be used to store cryptographic secrets, and can arrange to release it only to trusted software. Depending upon the particular needs of your application, it is remotely possible that this might provide at least a partial solution to your problem.

However, there are a bunch of caveats with TPMs. TPMs are not intended to be secure against physical attacks, so if the attacker has physical access to the device, forget it, it's not secure. Also, there is not a lot of software support for this, so you'd be on the bleeding edge, and there would be major engineering challenges. Also, not all machines contain a TPM.

See also Status of Trusted Computing and Remote Attestation deployment and Verifying server software integrity?.

But again, the bottom line is most likely that the problem as you have sketched it cannot be solved through technical means.

Community
  • 1
D.W.
  • 98,420
  • 30
  • 267
  • 572
  • It does seem like the chances are bleak or else I would be on the verge of a major breakthrough and going nuts by now. BTW, I was looking at http://en.wikipedia.org/wiki/Zero-knowledge_proof but then implementing something usable enough on the Human-Machine Interface seems like a challenge(assuming the human brain to be far less likely to get compromised without being noticed). – kumar Feb 06 '12 at 10:49
0

In a scenario where you always trust the client but want to assume the worst case you're really only going to have two options

1) Trust users far more than their machines (which isn't that far-fetched of an idea) i.e.: a password is far more secure than a password file etc.

2) Trust something physical (something along the lines of an RSA token possibly, or even something as "simple" as hashing the identifier from a serial number or something akin to that

doyler
  • 602
  • 4
  • 11
  • 1
    [1] can't be done in our case as there is no user involvement, and even if there was, a password type event can be trapped or read off while in memory. For [2], the result of the hash resides in the memory as well. I'm guessing anything residing in memory is readable. – kumar Feb 01 '12 at 23:12
  • 1
    To solve for 2 my best suggestions (assuming windows) Set BIOS to do mem tests Disable/encrypt page file Use the VBScript FreeMem command (FreeMem=Space()) You could also try Clearmem.exe Run a program using heavy calculations and run that afterwards/before/while idle – doyler Feb 02 '12 at 03:12
-1

I'd suggest a private-public key model similar to ssh in addition to your identifier. If client on A wants to connect to B (that A has connected to previously), A checks that B hasn't changed by issuing a challenge to B based on server B's public host-key (which A stored from their previous interactions) which B can only answer with B's private host-key. Then A can authenticate with B (either by sending password over an encrypted channel; or using private/public key) and log on to system B.

Sure, if an attacker M got the private host-key for B, they could impersonate B; but you need to do your best to protect your private keys from being read off disk or memory (encrypt the disk; limit read permissions; keep up to date on security patches; etc).

dr jimbob
  • 38,768
  • 8
  • 92
  • 161
  • I'm glad you answered. Thing is I really want to assume the worst scenario possible, by which I mean the Client service/OS/environment is infected and the Client identifier can be communicated back to the attacker. How to prevent this from bringing down the whole system?? I'm aware that PPP servers inform their clients of the identifiers and are considered as among the best practices, but they too get stored somewhere in memory. Am I missing something? – kumar Jan 30 '12 at 22:21