views:

438

answers:

2

Question for all the SSL experts out there:

We have an embedded device with a little web server on it, and we can install our own SSL self-signed certificates on it. The client is written in .NET (but that doesn't matter so much).

How can I authenticate the device in .NET? Is it enough to compare the fingerprint of the certificate against a known entry in the database?

My understanding is that the fingerprint is a hash of the whole certificate, including the public key. A device faking to be my device could of course send the same public certificate, but it couldn't know the private key, right?

Or do I have to build up my own chain of trust, create my own CA root certificate, sign the web server certificate and install that on the client?

+2  A: 

In the same way you wouldn't and shouldn't consider two objects to be equal just because their hash codes matched, you shouldn't consider a certificate to be authentic just because its fingerprint appears in a list of "known certificate fingerprints".

Collisions are a fact of life with hash algorithms, even good ones, and you should guard against the possibility that a motivated attacker could craft a rogue certificate with a matching fingerprint hash. The only way to guard against that is to check the validity of the certificate itself, i.e. check the chain of trust as you're implying in your last statement.

Chris W. Rea
Huh? Cryptographic hash functions such as SHA1 have been designed such that it is infeasible to find two inputs that hash to the same output. Hence if their hash match then it is safe to assume that the inputs are equal. Hence it also is safe to assume that a motivated attacker can NOT craft two certificates with matching hashes (at least as long as the hash is not broken).Moreover, checking the signature of a self-signed certificate alone is not enough. You need to be able to trust the signing key.
Accipitridae
Collisions *are* a fact of life with hash algorithms. And despite some of these algorithms having been designed with the best of intentions, MD5 was dethroned already, and SHA-1 has been shown to have weaknesses as well.See http://www.crn.com/security/212700354 and http://www.rsa.com/rsalabs/node.asp?id=2834. I maintain it is better to check the certificate thoroughly and not rely only on the fingerprint.
Chris W. Rea
... and in order to check the validity of a signature you first hash your data and then check that it is the same hash value that was signed. Hence if you verify digital signatures then you actually do rely on the collision resistance of your hash algorithm.
Accipitridae
@Accipitridae: that's what I was thinking, too.
chris166
@Accipitridae: Good point. +1. Damned if we do, damned if we don't, and I suppose there's no easy working around the weaknesses. But, work is underway to replace the old algorithms. See http://csrc.nist.gov/groups/ST/hash/index.html
Chris W. Rea
+2  A: 

What you propose is in principle ok. It is for example used during key signing parties. Here the participants usually just exchange their name and fingerprints of their public keys and make sure that the person at the party really is who he/she claims. Just verifying fingerprints is much easier than to verify a long public key.

Another example is the so called self certifying file system. Here again only hashes of public keys get exchanged over a secure channel. (I.e. these hashes are embedded in URLs.) In this scheme the public keys don't have to be sent securely. The receiver only has to check that the hash of the public keys matche the hashes embedded in the URLs. Of course the receiver also has to make sure that these URLs come from a trusted source.

This scheme and what you propose are simpler than using a CA. But there is a disadvantage. You have to make sure that your database with hashes is authentic. If your database is large then this will likeley be difficult. If you use CAs then you only have to ensure that the root keys are authentic. This usually simplifies the key management significantly and is of course one reason, why CA based schemes are more popular than e.g. the self certifying file system mentioned above.

Accipitridae
The scalability is really a good reason for the PKI, thanks!
chris166