Die Signaturverifikation bildet das Gegenstück zur Signaturberechnung. Sie dient dazu, die Authentizität der Nachricht mit Hilfe des öffentlichen Schlüssels des Authenticator zu verifizieren. Unter Verwendung des sicheren Hash-Algorithmus, der schon bei der Signaturberechnung zum Einsatz kam, wird der vom Authenticator signierte Message Digest berechnet, der zusammen mit dem öffentlichen Schlüssel Q(x,y), den Signaturkomponenten r und s zum Ergebnis führt. In Bild 4 ist dieser Ablauf dargestellt.
Die einzelnen Schritte des Verifikationsprozesses sind in Gleichung 4 zu sehen. Als Ausgangswerte werden der Message Digest h(m), der öffentliche Schlüssel Q (x, y), die Signaturkomponenten r und s sowie der Basispunkt G (x, y) verwendet:
(4) w = s–1 mod n
u1 = (h(m) ∙ w) mod n
u2 = (r ∙ w) mod n
(x2, y2) = (u1 × G(x, y) + u2 × Q(x, y))
mod n
Die Verifikation ist erfolgreich, wenn x2 = r ist, denn das liefert die Bestätigung, dass die Signatur tatsächlich mit dem privaten Schlüssel des Nachrichtenurhebers berechnet wurde.
Hardware-Konfiguration
Die Implementierung eines sicheren Authentifizierungssystems erfordert die Verbindung eines Host-Systems mit einem Peripheriemodul (Bild 5). Der Host-Controller nutzt einen seriellen Bus für die Kommunikation mit dem Authenticator. Hierfür kommt jeder Bustyp in Frage. Die einadrige Schnittstelle mit Massereferenz (kein Takt, kein Vcc) ist jedoch besonders attraktiv, weil es die Komplexität der Verbindung minimiert, das Design vereinfacht und somit die Kosten senkt. Neu in Bild 5 sind auf Seiten des Host die Datenelemente „System Public Key“ und „System Constant“ sowie auf Seiten des Peripheriemoduls die Abschnitte „Device ID#“ und „Public Key Certificate“.
Einrichten des Authenticator
Bevor ein Authenticator in einer Applikation verwendet werden kann, muss er entsprechend eingerichtet werden. Den ersten Schritt hierbei bildet das Berechnen und Installieren des Schlüsselpaars (siehe Bild 2). Das Schlüsselpaar kann extern berechnet und in den Authenticator geladen werden. Alternativ kann der Authenticator selbst einen Funktionsblock enthalten, der diesen Schritt – auf externen Befehl – ausführt. Unbedingt notwendig ist ein Schreibschutz für das generierte Schlüsselpaar, damit unbefugte Änderungen ausgeschlossen sind.
Eine Applikation hat die Wahl unter zwei Nutzungs-Szenarien. In Szenario 1 werden alle Authenticator-Einheiten mit demselben Schlüsselpaar programmiert. In dem Fall kennen sämtliche Hosts im System den gültigen öffentlichen Schlüssel. Jeder Authenticator mit diesem öffentlichen Schlüssel wird als Teil der Applikation betrachtet und es sind keine weiteren Maßnahmen zum Verifizieren des Authenticator selbst erforderlich.
In Szenario 2 verfügt jeder Authenticator über ein eigenes, einzigartiges Schlüsselpaar. Hier liefert die erfolgreiche Signaturverifikation noch keinen Beleg dafür, dass ein bestimmter Authenticator ein Bestandteil einer bestimmten Applikation, d.h. des Systems ist. Die Einbindung eines Authenticator in ein System erfordert die Einführung eines Zertifikats, das ebenso wie eine Signatur aus dem öffentlichen Schlüssel des Authenticator, der eindeutigen Bausteinkennung des Authenticator (Device ID#), einer Systemkonstante und dem privaten Schlüssel des Systems berechnet wird.
Bild 6 zeigt die Berechnung des Zertifikats, wie sie von einem auch als Zertifizierungs-Autorität bezeichneten Schlüsselmanagement-System ausgeführt werden könnte. Die beiden Komponenten cr und cs des Zertifikats werden anschließend schreibgeschützt im Speicher des Authenticator abgelegt. Damit ist die Einrichtung des Authenticator abgeschlossen. In Szenario 2 muss das Host-System also den öffentlichen Schlüssel des Systems sowie die Systemkonstante kennen, um die Gültigkeit des öffentlichen Schlüssels des Authenticator in der Applikation verifizieren zu können.
Die Infrastruktur, die das Management der Zertifikate unterstützt, wird als Public-Key-Infrastruktur bezeichnet. Mit Hilfe einer solchen Infrastruktur ist es möglich, Zertifikate zu generieren und die Mittel für deren Verifikation bereitzustellen. Ein weiterer Vorzug einer solchen Infrastruktur ist die Fähigkeit, Produkte zu unterstützen, die von Fremdfirmen oder Subunternehmern hergestellt werden. Angenommen, ein Subunternehmer hat Produkte mit eingebetteten ECDSA-Authenticator-Einheiten hergestellt und jede der Authenticator-Einheiten besitzt ihr eigenes, statistisch einzigartiges Schlüsselpaar. Durch das Signieren ihres öffentlichen Schlüssels zum Generieren des Zertifikats werden die Produkte dann Teile des Systems.