Smart Cards – what happens in the background?

Bei unseren Smart Cards stehen die Private-Public-Key-Verfahren mit RSA und ECC im Vordergrund. Lassen wir die Mathematik mal noch etwas aussen vor, ist es dennoch wichtig, den strukturellen Aufbau der Verfahren und die Konzepte zu verstehen. Insbesondere der Private Key muss auf einem sicheren Medium gespeichert werden – und die Smart Card ist der ideale Ort dafür.

Da sind vor allem die Themen: Warum vertrauen wir Zertifikaten? Warum ist die Verschlüsselung so sicher? Und woher wissen wir, dass eine signierte Nachricht dann wirklich vom Besitzer des privaten Schlüssels kommt und nicht verändert wurde?

Ich fange gerne bei «Trust» an. Als nächsten Schritt werden wir die grundsätzlichen zwei Operationen mit den Schlüsseln betrachten: digitale Verschlüsselung (Digital Envelope) und digitale Signatur (Digital Signature). Also was wird bei den Verfahren mit welchem Schlüssel verschlüsselt und entschlüsselt.

Um zu verstehen, wie eine gesamte Zertifikatskette funktioniert und warum wir Zertifikaten vertrauen, werden folgende 5 Elemente geprüft. Die verwendeten digitalen Verfahren werden später im Detail betrachtet.

Trust Chain

Die Trust Chain ergibt sich durch die digitale Signatur des Zertifikats durch den übergeordneten Zertifikatsaussteller (CA). Basierend auf einem «Digest» – ein String von festgelegter Länge der mit Hash-Verfahren gewonnen wird und mit dem Private Key der übergeordneten Instanz (CA) verschlüsselt wird – kann jeder diese Signatur mit dem Public Key prüfen.

Certificate Revocation

Weiterhin wird mit der CRL oder dem OCSP-Service geprüft, ob das Zertifikat mittlerweile zurückgezogen wurde. Auch hier kommt die Signatur zum Einsatz, um die Echtheit der Informationen zu verifizieren.

Certificate Validation

Zertifikate sind wie Ausweise (Personal ID) nur eine bestimmte Zeit gültig. Die Informationen im Zertifikat können nicht verändert werden, da sonst die Signatur nicht mehr passt.

Subject

Auch sollte das Zertifikat für den richtigen ausgestellt sein. Das was da drauf steht, sollte auch drin sein. Das sieht man am ehesten beim WebServer. Host Header Name im http Request muss auf das Subject-Zertifikat passen.

Verwendete Algorithmen

Seit einiger Zeit werden auch die verwendeten Hash-Verfahren geprüft. Wie alles sind diese Verfahren nicht für die Ewigkeit gemacht und haben eine Halbwertzeit. SHA-1, MD5, .. sollten nicht mehr verwendet werden.

«Denn alles was besteht, ist wert, dass es zu Grunde geht» oder nennen wir es die zunehmende Entropie des Seins.

Nun zu den zwei generellen Schlüsseloperationen: Digital Envelope und Digital Signature.

Es gibt nur zwei Varianten (Auswahl mit Reihenfolge) bei zwei Elementen. Entweder wir verschlüsseln etwas mit dem Private Key und Entschlüsseln es mit dem Public Key oder wir verschlüsseln etwas mit dem öffentlichen Schlüssel und entschlüsseln es dann mit dem privaten Schlüssel (Digital Signature or Digital Envelope). Da ja nur der Empfänger die Nachricht entschlüsseln soll, nehmen wir dessen Public Key. Damit kommt nur noch der Benutzer an den Inhalt der Nachricht, der den Zugriff auf den privaten Schlüssel hat.

Bei dieser Variante verschlüsseln wir mit dem Public Key und entschlüsseln mit dem Private Key. Wichtig ist hier zu unterstreichen, dass wir den Public Key der Empfänger verwenden, denn nur der soll ja die Nachricht auch lesen können.

Also zur Optimierung des Aufwandes kombinieren wir symmetrische Verschlüsselung (die wir hier mal ausklammern, weil es nichts mit unserer Smart Card zu tun hat) und die asymmetrische Verschlüsselung. Also der symmetrische Schlüssel (Data Encryption – DEK) wird mit dem Public Key des Empfängers verschlüsselt und die Nachricht mit dem symmetrischen Schlüssel. Nur der Empfänger kann nun mit dem privaten Schlüssel den DEK erhalten und damit dann die Nachricht lesen.

Nun verwenden wir den Private Key, um etwas zu verschlüsseln und entschlüsseln mit dem Public Key.

Bei der digitalen Signatur ergeben sich zwei weitere wichtige Aspekte. Oben haben wir schon die Signatur-Verfahren verwendet, um nachzuweisen, dass das Zertifikat wirklich von der Zertifikatsinstanz stammt und nicht verändert wurde. Das nutzen wir auch bei der Certificate based Authentication (CBA). Man generiere irgendeine Zeichenkette. Uns würde hier ein Versuch aus dem Infinite-Monkey-Experiment reichen (en.wikipedia.org/wiki/Infinite_monkey_theorem). Diesen String verschlüsseln wir nun mit unserem privaten Schlüssel und schicken die Klartextinformation und den verschlüsselten Teil mit unserem Zertifikat, welches den Public Key enthält zur Gegenseite, die uns identifizieren will.

Hier nochmals am Beispiel einer Email. Wir generieren basierend auf der Nachricht einen Digest mit einem definierten Hash-Verfahren, dieser wird mit dem eigenen privaten Schlüssel verschlüsselt. Dann geht die Nachricht – im Klartext, der verschlüsselte Digest inklusive Zertifikat (mit Public Key) – zum Empfänger. Der kann nun, wie schon gezeigt, mit dem Public Key den verschlüsselten Digest entschlüsseln und den Digest aus dem Klartext selbst generieren. Passen der entschlüsselte Digest und der selbst generierte Digest, dann kommt die Nachricht vom Besitzer des privaten Schlüssels. Fast wie bei der Authentisierung.

Wenn sie diesem Zertifikat vertraut – Trust Chain – und den mit dem Public Key entschlüsselten String mit dem empfangenen Klartext vergleicht und beides passt, dann muss wohl auf der anderen Seite der Private Key verwendet worden sein. Voilà, wir wissen, wer auf der anderen Seite ist.

Der Private Key gehört auf die Smart Card und kommt dort nicht weg. Nur der Besitzer kennt den PIN für die Auslösung der Private Key Operation. Das ist bei OTP-Verfahren ganz anders. Da kann der Token Code weitergesagt werden. Macht das mal mit so einer Private Key Operation. Bei der Smart Card hat der Benutzer die Karte wortwörtlich in der Hand und selbst wenn auf dem Rechner etwas passiert, dann kann die Karte flux entfernt werden.

Zum einen sollten wir laut Bundesamt für Informationssicherheit oder NIST mehr als 2048 Bit Schlüssellängen verwenden und mit den Jahren und den steigenden Rechenkapazitäten, ohne die Quantencomputermöglichkeiten zu berücksichtigen, wird das nicht besser. Man kann auf ECC umsteigen oder wir warten auf die Quantenkryptografie. Aktuell sind wir bei Smart Cards beim Wechsel auf 4096 Bits oder bei ECC auf. Siehe auch meinen Artikel zur Key Length: www.tec-bite.ch/key-length-versus-life-time/.

Zum andern haben wir das Problem der Kollisionen bei den Hash-Verfahren. Natürlich können wir nicht eine beliebig endlich lange Zeichenkette auf eine 160 lange Bitfolge abbilden, aber es sollte nicht möglich sein, diese zu manipulieren, also durch gezielte Veränderungen des Originaldokuments aber dennoch den gleichen Hash-Wert zu erhalten. Die Hashes sollten auch wirklich zufällig sein. Wenn sich nur ein Bit im Original ändert, aus einem A ein B wird, sollte das möglichst Auswirkung auf die gesamte Bitfolge haben, es sollten sich also viele Bits ändern. Und, last but not least, Kollisionen sollten nicht vorhersagbar sein.