tags:

views:

65

answers:

4

I understand how the relation between issuer and subject certificates enables verification of the subject's authenticity. If I connect to a networked device, and it sends me its certificate to identify itself, then I can verify that it was issued by a trusted party and that it has not been tampered with in any way. However, suppose I simply upload this certificate onto another device. Then what prevents me from having this device identify itself with the copied certificate?

+2  A: 

Nothing prevents you from doing that. I see that all of the time at work. The only thing that keeps someone from taking your cert and installing it someplace is that there is a password associated with the certificate. So you do not know that the device is who it says it is really, but you know that someone who knew the password for the certificate was able to install it on the device. UserID and Password authentication has its pros and cons, and so do certificates.

Rob Goodwin
Is the private key used for authentication? I thought it was only used for creating child certificates...
StackedCrooked
No, I just had authentication on the brain as I was looking into that when I saw your question
Rob Goodwin
+1  A: 

For a client device to authenticate to, say, a remote server, the client needs to be in possession of the private key associated with the certificate rather than just the certificate.

In client side SSL authentication, for example, the client signs (encrypts) some challenge with its private key. This private key corresponds to the public key in its certificate. Unlike the public key in the certificate, the client must keep its private key secure.

The server then uses the public key in the client's certificate to verify the client's signature.

However, The server should only rely on the public key in the certificate to verify the client signature, if it trusts the issuing CA, the certificate is still in its validity period, and hasn't been revoked.

bignum
+2  A: 

In my opinion this is a common misunderstanding of certificates driven in part by various marketing departments. A certificate of any type does not guarantee the device on the other end of the communication link is what you think it is.

All a certificate can really do is provide a public key/private key mechanism of securing the information that you are passing between two devices. This prevents 3rd parties from sniffing the data as it crosses the, potentially hundreds, of devices between them.

It can not guarantee what the device on the other end is or who owns it. Some cert issuers will try and validate who the certificate requestor is prior to issuing a cert. However, even that process is flawed and very easily subverted.

Chris Lively
+1  A: 

A device may try to pretend that it is the device identified by a certificate. Doing so will not do any good, though, as long as the data passed to it is encrypted using the public key provided in the certificate, because the incorrect device will not have possession of the private key.

The best it could achieve is a denial of service attack by throwing away the communications passed to it.

Jeffrey L Whitledge