Sicherheit und Nutzerfreundlichkeit

Zertifikate sollen sicherstellen, dass man eine verschlüsselte Verbindung mit der Person oder dem System erhält, mit der/dem man kommunizieren möchte. Das ist zweiseitig zu sehen: der Client möchte mit dem richtigen Server verbunden werden, der Server kann die Identität des Client über dessen Zertifikat feststellen (alternativ zu separaten Name/Kennwort-Menüs). Im EI-Schema wird deshalb immer im beidseitigen Authentifzierungsmodus gearbeitet; im X.509-Schema wird oft auf die Anforderung des Client-Zertifikats verzichtet.

Zertifikate sind im EI-Schema allerdings in der Regel selbstsigniert, so dass eine dritte Partei, die für die Echtheit der Identität einsteht, nicht vorhanden ist. Zu klären ist daher, wie trotzdem eine hohe Authentifizierungssicherheit erreicht werden kann. Wir beschreiben dies für EI-Zertifikate und verweisen in Fußnoten auf Abweichungen bei Vorlage von X.509-Zertifikaten.

Erstregistrierung

Wird ein Zertifikat einer bis dahin unbekannten Familie empfangen, wird es vom Management akzeptiert. Grund dieser Akzeptanz ist, dass erste Kontakte in der Regel nicht mit extremen Sicherheitsanforderungen verknüpft sind.

Beispiel: bei einer Webshopwebseite wird man sich erst nach den Produkten umsehen wollen, was noch keine besondere Authentifizierung verlangt. Wird ein Kauf getätigt, bei dem kritische Daten ausgetauscht werden, ist das meist erst nach mehreren Besuchen der Seite der Fall.

Die implizite Authentifizierungssicherheit entsteht durch wiederholten Besuch der Seite. Es kann zwar nicht ausgeschlossen werden, dass ein Hacker einen Man-in-the-Middle-Angriff durchführt, man also mit dem falschen Partner verbunden ist, aber da im EI-Schema immer verschlüsselt wird, muss der Hacker bei jeder Verbindung anwesend sein. Ist das nicht der Fall, wird ein anderes Zertifikat präsentiert, und da der Nutzungszweck im Management notiert wird, fällt dies dem Management auf und es erfolgt eine Meldung an den Nutzer. Da der Aufwand des Hackers für solche Angriffe hoch ist und der erste erfolgreiche Hack bereits bei der ersten Verbindung, bei der noch nicht abzusehen ist, wie sich der Kontakt weiter entwicḱelt, erfolgen muss, steigt die Wahrscheinlichkeit, dass der Hacker auffällt, mit jedem weiteren Kontakt.

Konflikte

Im Falle eines Konflikts hat das erste Zertifikat zwar Vorrang, aber sowohl das erste als auch das zweite Zertifikat können das korrekte sein. Das System kann das nicht entscheiden. Wenn der Nutzer Sicherheit will, muss er die Zertifikate prüfen und das korrekte Zertifikat mit “EI_VERIFIED” kennzeichnen, das gefälschte mit “EI_EXCLUDED” verbieten). Bei weiteren Konflikten wird stets das verifizierte Zertifikat verwendet (es ist möglich, beide Zertifikate mit “EI_VERIFIED” oder “EI_EXCLUDED” zu kennzeichnen, d.h. beide können verwendet oder ausgeschlossen werden).

Zertifikate mit besonderen Sicherheitsanforderungen können beim ersten Kontakt verifiziert werden (z.B. Homebanking); alternativ ist eine Signatur mit einer TRUSTED_CA möglich, die implizit zu einem “IS_SIGNED_BY_TRUSTET” führt, das immer bevorzugt wird.

Ist im Konfliktfall ein Zertifikat TRUSTET, das andere nicht, wird das 2. Zertifikat gesperrt. Ist ein TRUSTED-Zertifikat vorhanden, wird das neue gesperrt, ist das neue vom Typ TRUSTED_CA, wird das alte gesperrt.

Aufgrund des Aufwands für einen Hacker und der hohen Wahrscheinlichkeit, dass er doch auffällt, gehen wir davon aus, dass Konfliktfälle, die vom Nutzer zu lösen sind, eher selten bis sehr selten auftreten, obwohl die Zertifikate selbst i.d.R. nicht fremdbestätigt sind.