Das Biometrische Protokoll

Hier wird das Konzept des biometrischen Protokolls erläutert. Es wird versucht ein recht allgemeines Protokoll für die Übertragung von biometrischen Daten zu erstellen. Natürlich unterscheiden sich die Protokollschritte in Abhängigkeit von der verwendeten Erfassungseinheit. Bei einer Voll autonomen Erfassungseinheit fallen andere Protokollschritte an, als bei einer Nicht autonomen Erfassungseinheit.
Das Protokoll soll aber so erstellt werden, dass diese Fälle mit nur wenigen unterschiedlichen Protokollschritten abgebildet werden können. Hauptsächlich liegt der Unterschied bei der Übertragung der Daten und den eventuell notwendigen Kalibrierungsschritten. Kann die Erfassungseinheit dieses nicht selbständig leisten, so müssen die notwendigen Schritte vom Server aus getriggert werden und fliessen somit in das Protokoll. Auch der Abschluss der zu übertragenden biometrischen Daten kann entweder bei der Erfassungseinheit liegen oder beim Server.
Zunächst wird das Protokoll für eine Voll autonome Erfassungseinheit aufgezeigt. Anschliessend werden dann die unterschiedlichen Schritte bei einer Nicht autonomen Erfassungseinheit erklärt.

Biometrisches Protokoll für eine Voll autonome Erfassungseinheit

Die nachfolgende Abbildung illustriert einen erfolgreichen Authentikationsprozess. Es zeigt also den idealen Ablauf einer Kommunikation zwischen den beiden Teilnehmern. Es erscheinen keine Fehlerereignisse oder eventuelle notwendige Rescans in diesem Ablauf. Das zu erstellende Protokoll hingegen muss solche Situationen natürlich behandeln. Anhand dieser Abbildung werden anschliessend die einzelnen Schritte genauer erläutert.

Figure: Biometrisches Protokoll für VAE

Auth_req+ClientID

: Der Client initiiert eine Verbindung mit dem Server zum Zweck einer Biometrischen Authentikation. Dazu schickt er ein Paket mit der Aufforderung eines neuen Authentikationsprozesses zum Server. In diesem Paket überträgt der Client auch seine ClientID. Diese ClientID dient dem Server, die unterschiedlichen Clients zu unterscheiden und kann für bestimmte Auswahlprozesse auf dem Server genutzt werden, z.B kann der Server eine Liste mit zeitlich zulässigen Clients führen oder auch anhand der ClientID herausfinden, welche Funktionalität diese Erfassungseinheit bereit hält.

Auth_conf&Role+UserID_req

: Der Server antwortet auf ein
Auth_req+ClientID mit entweder einer Bestätigung Auth_conf&Role+UserID_req, so dass der Prozess fortgesetzt werden kann oder lehnt die Verbindung mit
Auth_conf[DENY] ab. Soll der Prozess fortgeführt werden, fordert der Server den Client auf, ihm den Authentisierungskontext zu nennen. Zu diesem Zweck benötigt der Server sowohl eine Benutzerkennung, als auch die Role für den Nutzer, der sich authentisieren möchte.

Role+UserID

: Die Erfassungseinheit muss zunächst die geforderten Daten für die Benutzerkennung und die zugehörige Role beschaffen. Dazu könnte eine Interaktion mit dem Benutzer stattfinden, bei der er diese Daten der Erfassungseinheit mitteilt (Tastatureingabe/SmartCard). Es könnte aber auch sein, dass die Role für diese Erfassungseinheit fest vorgegeben ist. In diesem Fall wird die Role von der Erfassungseinheit erstellt und der Nutzer muss lediglich seine Benutzerkennung mitteilen. Es sind auch Erfassungseinheiten vorstellbar, die überhaupt keine Möglichkeit vorsehen, eine Benutzerkennung und eine Role von dem sich Authentisierenden zu erhalten. In diesem Fall sollte ein zuvor definierter Benutzername mit zugehöriger Role von der Erfassungseinheit übertragen werden, damit der Server weiß, dass er den Nutzer nur anhand seiner biometrischen Daten ermitteln soll. Egal welche Funktionalität die Erfassungseinheit besitzt, lassen sich alle diese Fälle aber mit diesem Protokollschritt abbilden.

Role+UserID_conf

: Bei dieser Nachricht bestätigt der Server den Authentisierungsprozess, falls der Benutzer mit der angegebenen Role bekannt ist. Sollte der gewählte Benutzer oder seine Role nicht mit den Serverdaten übereinstimmen, besteht die Möglichkeit, erneut ein Role+UserID_req zu senden oder aber den gesamten Authentisierungsprozess mit einem Role+UserID_deny abzubrechen. Das erneute Versenden eines Role+UserID_req bietet die Möglichkeit, eine bestimmte Anzahl von Wiederholungen bei der Auswahl der Role und der UserID zu erlauben.

Data_Channel_req

: Hat der Client eine positive Rückantwort vom Server auf die UserID und die Role erhalten, so schickt er diese Nachricht an den Server mit der Bitte, einen Datenkanal zu eröffnen. Es besteht auch die Möglichkeit, dass in dieser Nachricht, um mehrere Datenkanäle gebeten wird. Dieses wäre dann der Fall, wenn die Erfassungseinheit ein Multimodales System ist und somit mehrere biometrische Charakteristika aufzeichnen kann. Gerade wenn es sich um eine nicht autonome Erfassungseinheit handelt, würden hier für die verschiedenen biometrischen Datenströme unterschiedliche Datenkanäle erbeten.

Data_Channel_Info

: Der Server bereitet alles für den Empfang der biometrischen Daten vor und schickt anschliessend dem Client die notwendigen Informationen für die Datenkanäle zurück. Er teilt ihm also die IP-Adresse und die Port-Nummer mit. Bei mehreren Datenkanälen efolgt in dieser Nachricht zudem eine Zuordnung der IPs und Ports zu den zu übersendenden biometrischen Daten. Es wäre auch möglich, den Empfang der biometrischen Daten nicht auf dem Authentisierungsserver zu realisieren, sondern explizit ausgewählte Rechner für diese Aufgabe vorzuhalten. Aus diesem Grund wird die IP-Adresse mit übermittelt.

Data_Channel_conf

: Der Client baut mit der vom Server erhaltenen Information eine oder mehrere Verbindungen zu den Datenkanälen-Gegenstellen auf und schickt anschliessend die Bestätigung Data_Channel_conf. Somit weiß der Server, dass der Aufbau der benötigten Datenkanäle abgeschlossen ist. Sollte es dem Client nicht möglich sein, die Datenkänale aufzubauen, so teilt der Client dem Server dieses mit, indem er erneut ein Data_Channel_req an den Server sendet. In der erneut versendeten Data_Channel_req brauchen nur die notwendigen Verbindungsdaten für die Datenkanäle zu stehen, die nicht erfolgreich aufgebaut werden konnten. Schon aufgebaute Kanäle bleiben bestehen.

Scan_req+Sec_Info

: Der Server löst jetzt einen Scan auf der Erfassungseinheit aus. Zusätzlich besteht die Möglichkeit, bestimmte sicherheitserhöhende Parameter für den Scan der Erfassungseinheit mitzuteilen. Es handelt sich dabei um Parameter, die das Umfeld des Scan beeinflussen. Bei einem Irisscan könnte dies die Auswahl von Lampen an der Erfassungseinheit sein, die sich als Reflektionen auf der Aufzeichnung widerspiegeln. Bei Spracherkennung wäre auch die Vorgabe eines zu sprechenden Satzes möglich. Je nach verwendetem biometrischen Verfahren lassen sich hier also Parameter übertragen, die der Server vorgibt. So wird es möglich, dass der Server eine Lebenderkennung durchführen kann.

Meta+Kalib_Data

: Vor der Übertragung der eigentlichen biometrischen Daten über den oder die Datenkanäle teilt der Client dem Server Metadaten bezüglich der Aufzeichnung mit. Der Inhalt dieser Metadaten ist nicht weiter spezifiziert und könnte Zeit, Ort oder auch Umwelteinflüsse bei der Aufzeichnung beinhalten. Dies könnten Temperatur oder Wetterdaten sein oder bei akustischen Aufzeichnungen der Umgebungsgeräuschpegel. Zusätzlich werden Kalibrierungsdaten von der Aufzeichnung dem Server übersandt. Dies dient zum einen für statistische Auswertungen oder ist bei der nicht autonomen Erfassungseinheit notwendig, damit der Server die Parameter der Aufzeichnung ändern kann. Es versteht sich von selbst, dass bei der nicht autonomen Erfassungseinheit während der Übertragung der biometrischen Daten, diese Kalibrierungsdaten wiederholt an den Server gesendet werden müssen.

<Biometrik_Data>

: Jetzt werden die biometrischen Daten über einen oder mehrere Datenkanäle übertragen. Es kann sich um abgeschlossene oder Streamingdaten handeln. Da diese Daten nicht über den Kontrollkanal laufen, bleibt dieser frei für die Kalibrierungskommunikation.

Data_Sent

: Dieser Schritt ist eventuell optional und hängt von der Erfassungseinheit ab. Er kommt nur dann nicht zum Einsatz, wenn es sich um eine nicht autonome Erfassungseinheit handelt. Die Erfassungseinheit teilt in diesem Protokollschritt dem Server mit, dass sie die biometrischen Daten übermittelt hat. Optional kann in diesem Protokollschritt noch die Anzahl der Bytes mit angegeben werden, welche über den Datenkanal übertragen wurden.

Data_rcvd

: Der Server quittiert die empfangenen biometrischen Daten mit dieser Meldung dem Client. Bei einer nicht autonomen Erfassungseinheit wird diese Nachricht vom Server zum Client übermittelt, wenn der Server ausreichend Daten empfangen hat. Mit diesem Schritt wird die Übertragung der biometrischen Daten abgeschlossen. Sollte der Server einen erneuten Scan benötigen, so braucht er anschliessend nur erneut eine Scan_req+Sec_Info Nachricht an die Erfassungseinheit schicken und der Scanvorgang würde wiederholt.

Auth_Result

: Zum Schluss wird jetzt das Ergebnis der Authentisierung übermittelt, nachdem die empfangenen Daten dem biometrischen Authentisierungsprozess übermittelt worden sind, und das Ergebnis bekannt ist. Bei einer erfolgreichen Authentisierung schickt der Server Auth_allow an den Client. Bei Misserfolg wird ein Auth_deny verschickt. Hiermit endet die Kommunikation der beiden Stationen.

DFA Zustandsdiagramm des Kontrollprotokolls für die Erfassungseinheit und den Server:

$\,$
Bei den nachfolgenden Diagrammen, handelt es sich um die Darstellung des Kontrollprotokolls für eine Erfassungseinheit und eines für den Server. Diese Erfassungseinheit kann eine voll autonome oder auch eine halb autonome Erfassungseinheit sein. Das Protokoll wird als endlicher Automat (DFA) dargestellt. Die Kreise zeichnen Zustände aus, in denen sich die Erfassungseinheit befinden kann. Die Kanten werden durch empfangene Nachricht (recv) und zu sendende Nachricht (send) beschriftet. Der Wechsel in einen anderen Zustand ist nur dann möglich, wenn die Kantenbeschriftung erfüllt wird. Der Client muss die Nachricht unter recv empfangen und darauf die Nachricht unter send verschicken. Anschliessend gelangt der Client in den neuen Zustand, zu dem die Kante zeigt. Die roten Kanten führen zu einem misslungenen Authentikationsprozess und beenden die Kommunikation mit dem Server. Die grünen Kanten weisen auf Wiederholungen im Ablauf hin. Außerdem sind noch an jedem Zustand eine Schlinge⁷ und eine Kante, welche nicht mit eingezeichnet wurden. Die Schlinge gilt, wenn der Client in diesem Zustand eine Nachricht erhält, die an keiner seiner anderen abgehenden Kanten bei recv auftaucht. Die Kante führt wieder zum Startzustand. Diese Kante tritt ein wenn ein Timeout erfolgt. Ein Timeout findet dann statt, wenn nach einer vorzugebenden Zeit der Zustand nicht gewechselt wurde.

Figure 12: Kontrollprotokoll DFA Client

Figure 13: Protokoll DFA Server