4

Is there any mechanism in SSL/TLS which allows a certificate to be bound to a device? Example:

There is a client who talks to a server, and during SSL/TLS setup, there is mutual authentication. The server verifies that the client presented a certificate which is valid (Expiration date, CRL/OCSP, etc.) and has whatever required fields the server wants to see (x.example.com domain, signer of XYZ Corp, etc.).

However we would also like the server to relate certain characteristics of the client certificate (thumbprint, serial, etc.) to the client itself (IP, Hostname, NetBT, etc.). Is there any built-in or third-party mechanism that does this, or am I missing something?

The concern is that a certificate will be exported from a client by someone with elevated privileges (We will have strict ACLs but we are assuming these are ineffective at stopping the attacker), and then installed on a second device. I understand that, if someone had elevated privileges on a machine they could just do whatever badness they wanted to do on that box using the existing environment, but if they are able to use the certificate on a second device, they could bypass security controls (local firewalls, av, etc.) and security audits (firewall is enabled, av is on, actions are logged and sent to syslog server, etc.).

JZeolla
  • 2,936
  • 1
  • 18
  • 25

2 Answers2

2

From the point of view of the server, all that can be seen is the client certificate (a public object, which is basically a bunch of bytes that everybody knows) and also a signature from the client (the signature is computed during the SSL handshake). The signature, being verified, offers some guarantee to the server that whoever is talking to it also knows the private key (which corresponds to the public key in the certificate).

The private key is everything. In cryptography in general, you are what you know. "The client device" is then defined as "whatever systems who can compute signatures verifiable with the device's public key". If an evil admin can slurp all the private information from a device, then he will be able to get the private key and impersonate the device with, say, another hardware element or even a PC. There is nothing you can do about that server-side: from the server, there are only zeros and ones over wires to be seen. The server cannot know that any piece of hardware even exists.

In order to achieve the kind of resistance you are after, then you need some tamper-resistance: make it impossible, or at least very hard, to extract all of the private information from a client device. That's typical smart card area. Now you see why mobile phones have a SIM card...

Community
  • 1
Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
1

It sounds like you're trying to tie a piece of software or an identity to a single physical computer. This can't be done. In some circumstances some solutions will work some of the time, assuming no one tries to circumvent them. But in the general sense, this is an impossible problem.

One solution as hinted by Thomas is to use a cryptographic hardware token which has a private key that the token will not reveal. You can then tie the software or identity to the hardware token (not the workstation), requiring the token to be present for whatever operation you intend. The distinction here is that physical security tokens can be designed to prevent tampering. General-purpose computers cannot.

tylerl
  • 82,225
  • 25
  • 148
  • 226
  • I suspect there is something you can do with [physical unclonable functions (PUFs)](https://en.wikipedia.org/wiki/Physical_unclonable_function) available in [normal workstations](http://puffin.eu.org/), but I'm not aware of any work to bind PKI style certificates to PUFs. – Michael Jul 23 '13 at 21:08
  • @Michael or... just use a TPM chip. It's a type of crypto token that manufacturers can include on the board. No sense messing with something nobody supports. – tylerl Jul 23 '13 at 21:46