SSL-Authentifizierung durch Vergleichen des Fingerabdrucks des Zertifikats?

Question

Frage für alle SSL-Experten da draußen:

Wir haben ein Embedded-Gerät mit einem kleinen Webserver darauf, und wir können unsere eigenen SSL-selbstsignierten Zertifikaten darauf installieren. Der Client ist in .NET geschrieben (aber das ist nicht so wichtig).

Wie kann ich das Gerät in .NET authentifizieren? Ist es genug, den Fingerabdruck des Zertifikats gegen einen bekannten Eintrag in der Datenbank zu vergleichen?

Mein Verständnis ist, dass der Fingerabdruck ein Hash des gesamten Zertifikats ist, einschließlich des öffentlichen Schlüssels. Ein Gerät, das fälschlicherweise als mein Gerät angesehen wird, könnte natürlich dasselbe öffentliche Zertifikat senden, aber es könnte den privaten Schlüssel nicht kennen, oder?

Oder muss ich meine eigene Vertrauenskette aufbauen, ein eigenes CA-Stammzertifikat erstellen, das Webserver-Zertifikat signieren und das auf dem Client installieren?

Answer 1

Was Sie vorschlagen, ist im Prinzip in Ordnung. Es wird zum Beispiel während key signing parties verwendet. Hier tauschen die Teilnehmer in der Regel nur ihren Namen und Fingerabdrücke ihrer öffentlichen Schlüssel aus und stellen sicher, dass die Person auf der Party wirklich ist, wer er/sie behauptet. Die Überprüfung von Fingerabdrücken ist viel einfacher als die Überprüfung eines langen öffentlichen Schlüssels. Ein anderes Beispiel ist das so genannte self certifying file system. Auch hier werden nur Hashes öffentlicher Schlüssel über einen sicheren Kanal ausgetauscht. (Das heißt, diese Hashes sind in URLs eingebettet.) In diesem Schema müssen die öffentlichen Schlüssel nicht sicher gesendet werden. Der Empfänger muss nur prüfen, ob der Hash der öffentlichen Schlüssel die in die URLs eingebetteten Hashes anpasst. Natürlich muss der Empfänger auch sicherstellen, dass diese URLs von einer vertrauenswürdigen Quelle stammen.

Dieses Schema und Ihre Vorschläge sind einfacher als die Verwendung einer Zertifizierungsstelle. Aber es gibt einen Nachteil. Sie müssen sicherstellen, dass Ihre Datenbank mit Hashes authentisch ist. Wenn Ihre Datenbank groß ist, wird dies wahrscheinlich schwierig sein. Wenn Sie CAs verwenden, müssen Sie nur sicherstellen, dass die Stammschlüssel authentisch sind. Dies vereinfacht normalerweise die Schlüsselverwaltung erheblich und ist natürlich ein Grund, warum CA-basierte Schemata beliebter sind als z. das oben genannte selbstzertifizierende Dateisystem.

Answer 2

In der gleichen Weise würden und sollten Sie nicht zwei Objekte als gleich betrachten, nur weil ihre Hash-Codes übereinstimmen, sollten Sie ein Zertifikat nicht als authentisch betrachten, nur weil sein Fingerabdruck in einer Liste von "bekannt" erscheint Zertifikat Fingerabdrücke ".

Kollisionen sind eine Tatsache des Lebens mit Hash-Algorithmen, auch gute, und Sie sollten sich vor der Möglichkeit schützen, dass ein motivierter Angreifer ein Rogue-Zertifikat mit einem passenden Fingerabdruck-Hash erstellen könnte. Die einzige Möglichkeit, dies zu verhindern, besteht darin, die Gültigkeit des Zertifikats selbst zu überprüfen, d. H. Die Vertrauenskette zu überprüfen, wie Sie es in Ihrer letzten Aussage angedeutet haben.

Answer 3

Kurz:

Nun in der Theorie Sie dann genau das tun, was für eine Zertifizierungsstelle für Sie tut. Also sollte es in Ordnung sein.

Längerer:

Wenn eine Zertifizierungsstelle signiert Ihre Public-Key/Zertifikat/Zertifikatsanforderung es nicht die gesamten Zertifikatsdaten unterschreiben. Aber nur der berechnete Hash-Wert der gesamten Zertifikatsdaten. Dies hält die Signatur klein.

Wenn Sie keine eigene CA erstellen oder eine kommerzielle/kostenlose verwenden möchten - , indem Sie den Fingerabdruck mit demjenigen vergleichen, dem Sie vertrauen, erhalten Sie die vertrauenswürdigste Konfiguration. Die vertrauenswürdigste Lösung wäre das Vergleichen des gesamten Zertifikats, da es auch vor Hash-Kollisionsangriffen schützt.

Wie die anderen hier erwähnten, sollten Sie sicherstellen, dass Sie einen sicheren Hash-Algorithmus verwenden. SHA-1 ist nicht mehr sicher.

ausführlichere Informationen zu diesem Thema:

• https://security.stackexchange.com/questions/6737
• https://security.stackexchange.com/questions/14330