DE102013202494A1

DE102013202494A1 - Authentifizierung von medizinischen Clientgeräten in einem Geräteverbund

Info

Publication number: DE102013202494A1
Application number: DE102013202494.0A
Authority: DE
Inventors: Georg Heidenreich; Wolfgang Leetz
Original assignee: Siemens AG
Current assignee: Siemens AG
Priority date: 2013-02-15
Filing date: 2013-02-15
Publication date: 2014-08-21
Also published as: WO2014124809A1

Abstract

Die Erfindung betrifft ein Authentifizierungsverfahren und ein -system, einen Client (C) und ein Trustgerät (T) zur Anwendung in einem Authentifizierungssystem und ein Produkt. Mit diesem Authentifizierungsverfahren ist es möglich, Nachrichten (N) eines Client (C) auf einem Trustgerät (T) zu authentifizieren, ohne dass eine Public-key-Infrastruktur implementiert werden muss. Dazu wird in einer Initialisierungsphase für einen Client (C) jeweils einmalig ein Verschlüsselungsmittel (key) zwischen Trustgerät (T) und Client (C) ausgetauscht. In der Authentifizierungsphase erzeugt der Client (C) aus einer Nachricht (N) ein Authentifizierungspaket (P), das an das Trustgerät (T) gesendet wird. Das Trustgerät (T) empfängt das Authentifizierungspaket (P) und extrahiert die darin enthaltenen Datensätze (N, X, A), um auf einen Speicherbaustein (10) zurückzugreifen, um das Verschlüsselungsmittel (key) zu ermitteln, das dem jeweiligen Client (C) zugeordnet ist. Daraufhin wird das Verschlüsselungsmittel (key) auf die behauptete Identität des Client (C) angewendet, um eine referenzverschlüsselte Nachricht (X‘) zu erzeugen und mit der empfangenen, verschlüsselten Nachricht (X) auf Übereinstimmung zu vergleichen. Bei Übereinstimmung gilt der Client (C) als authentifiziert.

Description

Die vorliegende Erfindung betrifft ein Authentifizierungssystem, ein Clientgerät, ein Trustgerät und ein Verfahren zur Authentifizierung eines medizinischen Clientgerätes an einem Trustgerät in einem Geräteverbund, sowie ein Computerprogrammprodukt.
Die vorliegende Erfindung liegt damit auf den Gebieten der Informations- und Netzwerk-Technologie und der Medizintechnik und hat zum Ziel, einen Anwender eines Clientgerätes und/oder das jeweilige Clientgerät bei einem Kommunikationspartner zu authentifizieren. Dabei geht es darum, dass zunächst der Client seine Identität nur behauptet und durch das Mittel der Authentisierung diese Behauptung gegenüber dem Kommunikationspartner (in diesem Fall: von dem Trustgerät) nachgewiesen kann.
Im Stand der Technik sind zur Authentifizierung drei grundlegende Ansätze bekannt: Zum einen gibt es die Wissensbasierte Authentifizierung (beide Kommunikationspartner wissen etwas, z.B. eine PIN, ein Passwort etc.), eine Besitzbasierte Authentifizierung (zumindest ein Kommunikationspartner besitzt etwas, z.B. eine Chipkarte, einen physikalischen Schlüssel etc.) oder eine Merkmals-basierte Authentifizierung, wie z.B. eine biometrische Authentifizierung, Fingerabdruck, Iriserkennung etc. Die vorliegende Erfindung basiert auf einer Wissens-basierten Authentifizierung und insbesondere auf einem symmetrischen Verschlüsselungsverfahren.
Im Bereich der Medizintechnik werden zum Datenaustausch Computernetze eingesetzt, die üblicherweise über ein Client-Server-Netzwerk gemäß unterschiedlichen Protokollen (z.B. DICOM – Digital Imaging and Communications in Medicine) kommunizieren. So interagiert beispielsweise eine Workstation bzw. ein Computer zur Datenakquisition eines Magnetresonanztomographen („MRT“) mit einem Client, der als Befundungsstation an einem entfernten Ort (z.B. in einer externen Arztpraxis) positioniert sein kann. Um die medizinischen und damit auch zu schützenden medizinischen Daten auszutauschen, muss sich der Client bei seinem Kommunikationspartner (in diesem Fall z.B. einem MRT-Server) authentisieren.
Ein anderes Anwendungsszenario betrifft mobile medizinische Geräte (intrakorporal oder extrakorporal), wie beispielsweise Herzschrittmacher, Blutdruckmessgeräte, Sensorgeräte etc., die die erfassten Daten an andere medizinische Geräte (z.B. einem zentralen Server) senden und weitere Daten mit diesen austauschen. Auch hierbei müssen sich die Kommunikationspartner gegenseitig authentisieren bzw. authentifizieren.
Asymmetrische Kryptosysteme, die auf der Verwendung von öffentlichen und privaten Schlüsseln basieren, erfordern immer eine zentrale Instanz, um die im Einsatz befindlichen Schlüssel zu verwalten, zuzuweisen und vorzuhalten.
Im Stand der Technik war es bisher bekannt, asymmetrische Verschlüsselungsverfahren einzusetzen, umfassend ein Schlüsselpaar von unterschiedlichen Schlüsseln zur Verschlüsselung und zum Entschlüsseln. Das, bei einem asymmetrischen Kryptosystem (auch Public-Key-System genannt) verwendete Schlüsselpaar wird auch als privater und öffentlicher Schlüssel bezeichnet. Gemäß einer ersten Gruppe von Authentifizierungssystemen werden der geheime (oder private) Schlüssel zur Verschlüsselung und der öffentliche Schlüssel zur Authentifizierung bzw. zur Entschlüsselung verwendet.
Möchte nun ein Empfänger einer Nachricht die Identität des Senders der Nachricht authentifizieren, so ist es bei dieser Art von asymmetrischen Authentifizierungssystemen des Standes der Technik vorgesehen, dass der Empfänger eine sogenannte senderverschlüsselte Signatur entschlüsselt, die er zusammen mit der Nachricht vom Sender empfangen hat. Dazu verwendet er den öffentlichen Entschlüsselungsschlüssel des Senders. Die Verwaltung des öffentlichen Schlüssels erfolgt durch eine Zertifizierungsinstanz (Third-Party-Trustee). Die beiden Kommunikationspartner interagieren somit immer zwangsläufig mit der Zertifizierungsinstanz. Das Ergebnis des Entschlüsselungsvorganges wird mit der empfängerseitig nachgebildeten Signatur verglichen. Diese Signatur ist die Identität des Senders oder eine mathematische Abbildung davon. Dazu können die Adresse des Senders und optional noch weitere Daten verwendet werden. Falls die beiden Ergebnisse übereinstimmen, gilt der Sender beim Empfänger als authentifiziert.
Eine weitere Gruppe von bekannten asymmetrischen Authentifizierungssystemen besteht darin, einen client-spezifischen Entschlüsselungsschlüssel geheim bzw. privat beim Client zu halten und den dazugehörigen Verschlüsselungsschlüssel öffentlich vorzuhalten. Die Verwaltung des öffentlichen Schlüssels erfolgt durch eine Zertifizierungsinstanz. Auch hier interagieren die beiden Kommunikationspartner somit immer zwangsläufig mit der Zertifizierungsinstanz. Bei diesem Ansatz verschlüsselt der Empfänger ein sogenanntes Geheimnis (in der Regel eine zufallserzeugte Zahl) mit dem öffentlichen Schlüssel des Clients und sendet die resultierende „Challenge“ an den Client. Daraufhin authentisiert der Client seine Nachricht an den Empfänger, indem er die Signatur mit dem geheimen Schlüssel entschlüsselt und die resultierende „Response“ mit der Nachricht an den Empfänger sendet. Der Empfänger authentifiziert den Client, indem er diese entschlüsselte „Response“ mit dem originalen Geheimnis auf Übereinstimmung vergleicht.
Bei beiden vorstehend erwähnten Verfahren aus dem Stand der Technik erweist es sich als nachteilig, dass stets eine dritte Partei als Zertifizierungsinstanz notwendig ist, um die öffentlichen Schlüssel zu verwalten. Insbesondere im medizintechnischen Umfeld ist dies hinderlich, da dies zum Einen einen erhöhten Verwaltungsaufwand bedeutet und auch in der klinischen Praxis zu einem Zeitnachteil führt, da Zugriffe auf externe dritte Instanzen ausgeführt werden müssen, um eine Authentifizierung durchführen zu können, die erforderlich ist, um überhaupt auf die medizinisch relevanten Datensätze zugreifen zu können. Da es im medizinischen Umfeld viele Anwendungsfälle gibt, die sehr zeitkritisch sind (beispielsweise in der Intensivmedizin) ist dieser Nachteil nicht tragbar.
Die vorliegende Erfindung hat sich deshalb zur Aufgabe gestellt, ein Authentifizierungssystem mit einem Clientgerät und mit einem Trustgerät, sowie ein Verfahren zur Authentifizierung und ein Computerprogrammprodukt bereitzustellen, das die vorstehend erwähnten Nachteile überwindet und nicht mehr den Einsatz einer Zertifizierungsinstanz erfordert. Des Weiteren soll das vorgeschlagene Authentifizierungssystem die Möglichkeit bieten, dass sich ein Client jeweils gegenüber einer Vielzahl von Empfangsgeräten bzw. Trustgeräten authentisiert. Darüber hinaus soll der Authentifizierungsvorgang verkürzt und einfacher ausgeführt werden.
Die vorstehende Aufgabe wird durch die beiliegenden nebengeordneten Patentansprüche gelöst, insbesondere durch ein Authentifizierungssystem, ein Clientgerät, ein Trustgerät, ein Verfahren zur Authentifizierung und ein Computerprogrammprodukt. Vorteilhafte Weiterbildungen der Erfindung finden sich in den Unteransprüchen.
Im Folgenden wird die Erfindung anhand des Verfahrens beschrieben. Hierbei erwähnte Ausführungsformen, alternative Lösungen, weitere Merkmale und Vorteile sind ebenso auch auf die anderen Anspruchsformen zu übertragen (also auf das Client- oder Trustgerät, auf das System oder das Programm) und umgekehrt. Demnach können auch die Merkmale, die im Zusammenhang mit dem Verfahren beansprucht und/oder beschrieben sind, auch auf das System, die Geräte oder das Produkt angewendet werden und umgekehrt. Dabei sind die jeweiligen funktionalen Merkmale des Verfahrens durch entsprechende Mikroprozessorbausteine, Speichermodule oder Hardwareeinheiten implementiert, die jeweils dazu ausgebildet sind, die Funktionalität zu übernehmen.
Gemäß einem Aspekt bezieht sich die Erfindung auf ein Verfahren zur Authentifizierung eines Client an einem Trustgerät, wobei das Verfahren folgende Verfahrensschritte umfasst:

– Seitens des Trustgerätes: Initialisieren der Authentifizierung durch folgende Schritte: – Erzeugen eines client-spezifischen Verschlüsselungsmittels auf dem Trustgerät, – Speichern des client-spezifischen Verschlüsselungsmittels in einem Speicher auf dem Trustgerät mit einer Zuordnung zwischen dem jeweiligen Client bzw. einer Clientadresse oder Client-Identität und des für ihn erzeugten Verschlüsselungsmittels, – Senden des erzeugten Verschlüsselungsmittels an dem Client
– Seitens des Client: Anwenden des empfangenen Verschlüsselungsmittels auf eine Nachricht zum Berechnen einer verschlüsselten Nachricht bzw. einer verschlüsselten Form der Nachricht.
– Seitens des Client: Versenden eines Authentifizierungspaketes, umfassend die Nachricht, die verschlüsselte (Form der) Nachricht und eine Clientadresse an das Trustgerät.
– Seitens des Trustgerätes: Validieren der Authentizität des Client durch folgende Schritte: – Ermitteln des client-spezifischen Verschlüsselungsmittels durch Zugriff auf den Speicher, das jeweils in der empfangenen Clientadresse, vorzugsweise eineindeutig, zugeordnet ist. – Anwenden des ermittelten Verschlüsselungsmittels auf die empfangene Nachricht zum Berechnen einer referenzverschlüsselten Nachricht. – Vergleich der referenzverschlüsselten Nachricht mit der empfangenen verschlüsselten Nachricht aus dem Authentifizierungspaket auf Identität und bei Identität:
– Authentifizieren des Client auf dem Trustgerät.

Im Folgenden werden die im Rahmen dieser Anmeldung verwendeten Begrifflichkeiten näher erläutert. Grundsätzlich können alle der in dieser Beschreibung erläuterten Aspekte, Merkmale und Ausführungsformen der Erfindung auch kombiniert werden.
Der Begriff Authentifizierung bezieht sich auf den Nachweis der Identität des Senders beim Empfänger in einem computergestützten klinischen Netzwerk, das Daten über ein Bussystem oder ein Netzwerk (vorzugsweise DICOM) austauscht. Die Authentifizierung erfolgt automatisch und somit ohne die Notwendigkeit von Benutzereingaben. Die Authentifizierung basiert vorzugsweise auf einer symmetrischen Verschlüsselung. Desweiteren kann die Authentifizierung ausgeführt werden, indem nur Sender (Client) und Empfänger (Trustgerät) miteinander in Datenaustausch stehen und ohne den Zugriff auf eine dritte Zertifizierungsinstanz. Die Authentifizierung kann zum Nachweis der Identität (Verwendung zum Identitätsnachweis) des Client als Anwender des Clientgerätes oder des Clientgerätes verwendet werden. In einer weiteren Ausführungsform ist es ebenso möglich, Nachrichten oder Nachrichtenkonvolute zu authentifizieren, die von einem Clientgerät gesendet werden (Verwendung zum Herkunftsnachweis). Dabei können der zu authentifizierenden Nachricht auch noch weitere Variablen, wie etwa eine Zeitangabe oder Zufallsgrößen, hinzugefügt sein, um die Sicherheit des Verfahrens zu erhöhen.
Bei dem Clientgerät und bei dem Trustgerät handelt es sich um Datenverarbeitungsanlagen und insbesondere um spezielle Datenverarbeitungsanlagen, die in der Medizintechnik zum Einsatz kommen (diese umfassen medizintechnische Anlagen, Workstations, Speicher- und Archivierungssysteme, Befundungssysteme, bildgebende Anlagen etc.). An dieser Stelle sei speziell darauf hingewiesen, dass die Authentifizierung für den klinisch-medizinischen Bereich und für die dort eingesetzten Geräte ausgelegt ist. Da die medizinischen Geräte in der Regel eine spezifische Datenein- und ausgabeschnittstelle erfordern, werden Authentifizierungssysteme für diese Geräte bislang in der Regel nicht eingesetzt oder können nur beschränkt verwendet werden. In einer bevorzugten Ausführungsform sind Clientgerät und/oder Trustgerät in ein medizinisches Netzwerk eingebettet und dienen zum Austausch von medizinischen Daten nach dem DICOM-Protokoll. Alternativ oder kumulativ können hier noch andere Protokolle verwendet werden, beispielsweise beim Austausch über die Klinikgrenzen hinaus, (beispielsweise über das Internet, z.B. mit dem http/s-Protokoll). Das Clientgerät und das Trustgerät sind zum Einsatz in einem Authentifizierungssystem gemäß beiliegendem Anspruch 1 ausgebildet. Das Clientgerät umfasst eine Verschlüsselungseinheit und ein Paketierungsmodul; das Trustgerät umfasst in der bevorzugten Ausführungsform einen Verschlüsselungsgenerator, einen Speicherbaustein, eine Sendekomponente, eine Validierungskomponente mit Speicherzugriffsmitteln, einer Referenzverschlüsselungseinheit und einem Komparator. Diese Bausteine werden später unter Bezugnahme auf das Authentifizierungssystem näher erläutert.
Das erfindungsgemäße Authentifizierungsverfahren gliedert sich in zwei Phasen bzw. Zeitabschnitte:

1. Eine Initialisierungsphase, die grundsätzlich nur einmal für jeden Client bzw. für jedes Clientgerät ausgeführt werden muss. Die Initialisierungsphase umfasst die Schritte: Erzeugen eines Verschlüsselungsmittels auf dem Trustgerät, Speichern des erzeugten Verschlüsselungsmittels mit einer Zuordnung des Verschlüsselungsmittels zu dem jeweiligen Client auf einem Speicher, der von dem Trustgerät zugreifbar ist und das Senden des erzeugten Verschlüsselungsmittels an den Client. Die Initialisierungsphase wird ausschließlich auf dem Trustgerät ausgeführt und ist der eigentlichen Authentifizierung vorgeschaltet. Diese initiale, erste Authentifizierung wird üblicherweise von einem Administrator oder automatisiert durch eine zentrale Instanz durchgeführt. Sie wird grundsätzlich nur einmal durchgeführt auf der Basis von Client-Adressen (z.B. IP-Adresse oder MAC-Adresse (Media-Access-Control-Adresse, der Sicherungsschicht des ISO-OSI-Schichtenmodells) oder auf Basis eines symbolischen Rechnernamens) oder anderen technischen Merkmalen des Clients, die zum Zeitpunkt der Initialisierung als eindeutig gelten.
2. Eine Authentifizierungsphase. Diese Phase wird sowohl auf dem Client als auch auf dem Trustgerät ausgeführt und kennzeichnet sich durch die Ausführung aller restlichen Schritte des Verfahrens, also insbesondere aller Schritte, die nicht der Initialisierungsphase (wie vorstehend beschrieben) zugewiesen sind. Die Authentifizierung wird üblicherweise mehrfach durchgeführt und kann bei ausgewählten oder allen Nachrichten angewendet werden, die zwischen Clientgerät und Trustgerät ausgetauscht werden müssen.

Mit der Unterteilung des Authentifizierungsverfahrens in zwei Phasen, in eine Initialisierungsphase und in eine Authentifizierungsphase wird es möglich, den Authentifizierungsvorgang noch effizienter zu gestalten, in dem die Initialisierungsphase sozusagen vor- bzw. ausgelagert wird und auch von einem anderen Anwender (z.B. einem Administrator) bedient werden kann. Damit kann der Anwender an dem Clientgerät und/oder Trustgerät von zusätzlichen Authentifizierungsmaßnahmen entlastet werden.
Ein wesentliches Merkmal und ein zusätzlicher Vorteil des Authentifizierungsverfahrens sind darin zu sehen, dass das Authentifizieren ohne eine separate Zertifizierungsinstanz ausgeführt wird. Mit anderen Worten muss keine Zertifizierungseinheit bereitgestellt werden, die zusätzlich zum Clientgerät und zum Trustgerät in das Netzwerk eingebunden werden muss, um beispielsweise die Schlüssel zu verwalten. Damit kann das erfindungsgemäße Authentifizierungsverfahren wesentlich flexibler ausgeführt werden, da an ein Trustgerät auch spontan ohne weitere Vorbereitungsmaßnahmen eine Vielzahl von unterschiedlichen Clients angeschlossen werden können. Die Verwaltung der Schlüssel und die Speicherung der Zuordnungsrelationen erfolgt im Trustgerät. Das Trustgerät kann auch als zentraler Server ausgebildet sein. Alternativ kann das Trustgerät mit ausgelagerten Modulen über ein Netzwerk interagieren. So ist es beispielsweise möglich, dass die einzelnen Bestandteile des Trustgerätes (Verschlüsselungsgenerator, Speicher, Sendekomponente, Validierungskomponente) auf einem oder auf mehreren separaten Instanzen ausgelagert wird, die mit dem Trustgerät in Datenaustausch stehen. Bevorzugt ist es jedoch, dass die vorstehend genannten Module des Trustgerätes in das Trustgerät integriert oder eingebettet sind.
Wie vorstehend bereits erwähnt wird als Verschlüsselungsmittel ein symmetrisches Verschlüsselungsverfahren verwendet. Symmetrische Verschlüsselungsverfahren sind im Stand der Technik bekannt, speziell DES, 3DES, AES (Rijndael), IDEA, CAST, FEAL, Blowfish, Twofish, Mars, RC2, RC5, RC6, Serpent, Skipjack. (Vgl. hierzu: Wolfgang Ertel: Angewandte Kryptographie, Carl Hanser Verlag, S. 68–75; S. 94 und Bundesamt für Sicherheit in der Informationstechnik: IT-Grundschutz, M 3.23 Einführung in kryptographische Grundbegriffe, abrufbar unter: https://www.bsi.bund.de/ContentBSI/grundschutz/kataloge/m/m03/m03023.html).
Gemäß einem Aspekt werden zwei Verschlüsselungsmittel bei dem Authentifizierungsverfahren verwendet, ein Verschlüsselungsmittel und ein Referenzverschlüsselungsmittel. Vorzugsweise stimmen beide überein. Bei dem Verschlüsselungsmittel kann es sich um eine kollisionsresistente Verschlüsselungsfunktion und/oder um eine Einweg-Hashfunktion handeln. Mit einer Einweg-Hashfunktion wird es praktisch unmöglich, zu einem gegebenen Ausgabewert den dazugehörigen Eingabewert zu finden, den die Hashfunktion auf den Ausgabewert abbildet. Eine Einweg-Hashfunktion ist beispielsweise bekannt aus Christoph Ruland: Informationssicherheit in Datennetzen; DATACOM-Verlag; Bergheim, 1993; ISBN 3-89238-081-3; Seite 68ff. Die Einwegfunktion ist vorzugsweise so ausgebildet, dass sie in eine Richtung relativ leicht zu berechnen sind, aber in die andere Richtung sehr schwer. Mit anderen Worten kann in kurzer Zeit ein Ergebnis berechnet werden, das aber kaum oder nur sehr schwierig umzukehren ist. Gemäß einem Aspekt ist das Verschlüsselungsmittel als kryptographische Hashfunktion ausgebildet, die kollisionsresistent und/oder eine Einwegfunktion ist. Grundsätzlich bildet eine Hashfunktion eine Zeichenfolge beliebiger Länge auf eine Zeichenfolge mit geringerer Länge ab.
Der Begriff „Kollisionsresistenz“ bedeutet, dass es ebenfalls praktisch unmöglich ist, für einen gegebenen Wert X einen davon unterschiedlichen Wert X‘ zu finden, der denselben Hashwert ergibt. Vorzugsweise wird eine starke Kollisionsresistenz bei dem Verschlüsselungsmittel gewählt. Ebenso ist es jedoch auch möglich, hier nur eine schwache Kollisionsresistenz vorzusehen, bei der die beiden Nachrichten bzw. Eingabewerte der Hashfunktion frei gewählt werden dürfen.
Gemäß einem weiteren Aspekt der Erfindung umfasst das Verschlüsselungsmittel noch zusätzliche kryptographische Verfahren, um die Sicherheit zu erhöhen.
Gemäß einem weiteren Aspekt der Erfindung ist es vorgesehen, dass auf dem Client zunächst auf die erzeugte Nachricht eine Extrahierungsfunktion angewendet wird. Die Extrahierungsfunktion dient dazu, die Datenmenge zu reduzieren, sodass das Extrakt eine geringere Länge hat, als die ursprüngliche Nachricht. Im einfachsten Fall handelt es sich bei der Extrahierungsfunktion um ein Herauslösen von einzelnen Bits aus der Bitfolge der Nachricht. Allgemein können zum Extrahieren alle nicht-injektiven Funktionen verwendet werden, wobei vorzugsweise als Funktionswerte alle möglichen Werte des Ergebnistyps gleichhäufig verwendet werden, also z.B. 256 gleichhäufige Ergebnisse bei 8 Bit Ergebnislänge. Daraufhin wird das Verschlüsselungsmittel auf die extrahierte Nachricht angewendet und dann in dem Authentifizierungspaket an das Trustgerät zur Authentizitätsprüfung übertragen. Damit kann der Authentifizierungsvorgang noch schneller ausgeführt werden.
Gemäß einem Aspekt der vorliegenden Erfindung ist das Verschlüsselungsmittel stets Clientgeräte-spezifisch. Somit existiert eine eineindeutige Zuordnung zwischen Clientgerät und Verschlüsselungsmittel. Diese Zuordnung wird auf dem Trustgerät hinterlegt.
Gemäß einem weiteren Aspekt der vorliegenden Erfindung ist das Verschlüsselungsmittel eine Konkatenation einer Verschlüsselungsfunktion und einer Extrahierungsfunktion. Mit anderen Worten beschreibt das Verschlüsselungsmittel eine Funktion, die zunächst eine Nachricht extrahiert und daraufhin verschlüsselt.
Gemäß einem weiteren Aspekt der Erfindung ist es vorgesehen, dass das Verschlüsselungsmittel als ausführbare Applikationsdatei (beispielweise in standardisierten Internetprotokollen markiert mit einem standardisierten „Content-Type“ „MIME application/...“) von dem Trustgerät an das Clientgerät übertragen wird. In diesem Fall muss der Client nicht spezifisch ausgebildet werden und keine vorbereitenden Installationsmaßnahmen ausführen. Die Applikationsdatei dient dazu, eine Verschlüsselungseinheit und ein Paketierungsmodul auf dem Client zu implementieren. Damit kann jedes Gerät, das über eine entsprechende Netzwerkverbindung zum Trustgerät verfügt, zur Authentifizierung verwendet werden. Das Verfahren wird damit sehr flexibel. Beispielsweise können auch mobile Clientgeräte (wie z.B. Handhelds, Smartphones, Tablet-PCs etc.) zur Authentifizierung auf dem Trustgerät verwendet werden.
Wie oben bereits erwähnt, besteht eine weitere Aufgabenlösung in einem Authentifizierungssystem zur Authentifizierung eines Client an einem Trustgerät, dessen Aufbau nachfolgend näher erläutert wird. Der Begriff „Client“ und der Begriff „Clientgerät“ werden in dieser Beschreibung häufig synonym verwendet. Der Begriff „Client“ soll kennzeichnen, dass sich der jeweilige Rechner als Client eines Servers verhält, wobei das Trustgerät als Server ausgebildet sein kann. Selbstverständlich kann mit Hilfe des vorliegenden Authentifizierungsverfahrens auch der Anwender des jeweiligen Clientgerätes, also die Person authentifiziert werden. Das System umfasst:

– Ein Trustgerät mit: – einem Verschlüsselungsgenerator, der dazu bestimmt ist, ein client-spezifisches Verschlüsselungsmittel zu erzeugen, – einem Speicherbaustein, der zur Speicherung einer Zuordnung zwischen dem jeweiligen Client(gerät) und des für ihn erzeugten Verschlüsselungsmittels bestimmt ist, – einer Sendekomponente, die dazu bestimmt ist, das erzeugte Verschlüsselungsmittel an den Kommunikationspartner, hier: an den Client, zu senden, – einer Validierungskomponente, die dazu bestimmt ist, die Authentizität des Clients zu validieren, umfassend: – Speicherzugriffsmittel, die dazu bestimmt sind, das client-spezifische Verschlüsselungsmittel durch Zugriff auf dem Speicherbaustein zu ermitteln, wobei der Zugriff auf dasjenige clientspezifische Verschlüsselungsmittel erfolgt, das jeweils einer vom Client empfangenen Clientadresse zugeordnet ist. – Eine Referenzverschlüsselungseinheit, die dazu bestimmt ist, das ermittelte Verschlüsselungsmittel auf die empfangene Nachricht zur Berechnung einer referenzverschlüsselten Nachricht anzuwenden. – Einem Komparator, der dazu bestimmt ist, ein Authentifizierungspaket von dem Client zu empfangen und der weiterhin dazu bestimmt ist, die referenzverschlüsselte Nachricht mit einer empfangenen verschlüsselten Nachricht aus dem Authentifizierungspaket auf Identität zu vergleichen und, der weiterhin dazu bestimmt ist, bei Identität dem Client auf dem Trustgerät zu authentifizieren.
– Einem Clientgerät mit: – einer Verschlüsselungseinheit, die dazu bestimmt ist, das empfangene Verschlüsselungsmittel auf eine Nachricht zum Berechnen einer verschlüsselten Nachricht anzuwenden und – einem Paketierungsmodul, das dazu bestimmt ist, ein Authentifizierungspaket zu erzeugen, umfassend die Nachricht, die verschlüsselte Nachricht und eine Clientadresse und das weiterhin dazu bestimmt ist, das Authentifizierungspaket an das Trustgerät zu senden.

Bei dem Client und bei dem Trustgerät handelt es sich vorzugsweise um Rechner, Rechnerknoten oder ein Verbund von mehreren Netzwerkrechnern eines medizinischen Systems zum Austausch von medizinischen Daten. Üblicherweise werden dabei die Daten innerhalb eines internen Kliniknetzwerkes weitergeleitet. Da das Sicherheitsrisiko innerhalb des internen klinischen Netzwerkes nicht so hoch ist im Vergleich zu dem Szenario, bei dem die Daten extern versendet werden, genügt die Einhaltung von Sicherheitsvorschriften einer mittleren Ebene. Dies bedeutet allerdings, dass mögliche Angriffe innerhalb des klinischen Systems, die auf den Inhalt der im Kommunikationssystem ausgetauschten Nachrichten oder auf die Adressen der Kommunikationspartner abzielen, nicht ausgeschlossen werden können.
Gemäß einem Aspekt ist das Authentifizierungssystem zur Ausführung des Authentifizierungsverfahrens gemäß beiliegendem Verfahrensanspruch ausgebildet. In einer bevorzugten Ausführungsform umfasst das Trustgerät dazu den Verschlüsselungsgenerator, den Speicherbaustein, die Sendekomponente und die Validierungskomponente mit den weiteren Einheiten und Mitteln. Es ist jedoch ebenso möglich, das Trustgerät einfacher auszubilden, so dass der Speicherbaustein beispielsweise ausgelagert werden kann und auf einer separaten Instanz bereitgestellt wird, die in (anderweitig gesichertem) Datenaustausch mit dem Trustgerät steht. Desweiteren ist der Client mit der Verschlüsselungseinheit und dem Paketierungsmodul ausgebildet. Wie vorstehend bereits erwähnt, ist es jedoch auch möglich, das Verschlüsselungsmittel als Applikationsdatei an den Client zu übertragen, die dann die Funktionalität der Verschlüsselungseinheit und des Paketierungsmoduls übernimmt. Dann muss der Client keine weiteren Module und Bauteile aufweisen, sondern es kann sich um einen beliebigen medizinischen Client handeln.
Eine weitere Aufgabenlösung besteht in einem Client mit einer Verschlüsselungseinheit und einem Paketierungsmodul zur Anwendung in einem Authentifizierungssystem nach beiliegendem Authentifizierungsanspruch.
Eine weitere Aufgabenlösung besteht in einem Trustgerät mit einem Verschlüsselungsgenerator, einem Speicherbaustein, einer Sendekomponente und einer Validierungskomponente zur Anwendung in einem Authentifizierungssystem nach beiliegendem Anspruch.
An dieser Stelle sei darauf hingewiesen, dass das Authentifizierungsverfahren bzw. das Authentifizierungssystem zur Authentifizierung bei der Programmierung von Steuergeräten für medizintechnische Anlagen dient. Medizintechnische Anlagen sind beispielsweise komplexe Magnetresonanztomographen, Computertomographen, Positronen-Emissions-Tomographen, Ultraschallgeräte oder andere bildgebende Apparate. Sonstige medizinische IT-Systeme umfassen auch patientengebundene Sensoren oder auch interaktive Erfassungsgeräte die von Heilberuflern oder Patienten bedient werden. Das Verfahren mit den einzelnen Verfahrensschritten bzw. die Einheiten des Clientgerätes und des Trustgerätes können auch als sogenanntes „embedded system“ (eingebettetes System) in die medizintechnische Anlage und/oder in einen medizintechnischen Steuerrechner und/oder in einem sonstigen medizinischen IT-System eingebettet bzw. integriert sein. Das Verfahren dient der Speicherung, Verarbeitung und Weiterleitung von aufbereiteten Daten (in Form von authentifizierten Datensätzen), die über ein Gerätenetzwerk an andere Instanzen übertragen werden. Dabei werden Datensätze und Geräteadressen modifiziert, indem eine Authentifizierungsinformation mit dem eigentlichen Signal bzw. mit dem Datensatz oder der Geräteadresse übertragen werden. Durch den speziellen Authentifizierungs- und Verschlüsselungsmechanismus dient die vorliegende Erfindung der Sicherheit der gesamten Anlage und berücksichtigt die Gegebenheiten der Datenverarbeitungsanlage, in dem die zu übertragenen Datensätze und ausführbare Dateien authentifizierbar gemacht werden, ohne, dass eine zentrale Zertifizierungsinstanz implementiert werden muss. Die Nachricht, eine verschlüsselte Form der Nachricht und das Verschlüsselungsmittel selbst sind als Folge von Bits repräsentiert bzw. gespeichert.
Ein besonderer Vorteil des erfindungsgemäßen Authentifizierungsverfahrens bzw. -systems ist darin zu sehen, dass die Initialisierungsphase nur einmal ausgeführt werden muss, während die nachfolgenden Verfahrensschritte für jede Nachricht des Client an das Trustgerät ausgeführt werden. Damit kann das Verfahren sehr flexibel und effizient ausgeführt werden, da der aufwändigere und rechenintensive Vorgang zur Schlüsselgenerierung und Schlüsselversendung sozusagen zusammengefasst, gekapselt und im Vorfeld ausgeführt werden kann. Die Initialisierungsphase kann zeitlich von der Authentisierung entkoppelt werden und zu einem beliebigen Zeitpunkt vor der Authentisierung ausgeführt werden.
Gemäß einem Aspekt basiert die erfindungsgemäße Authentisierung darauf, dass vor der Ausführung der Initialisierungsphase der jeweilige Client eine Gelegenheit erhält, sich über einen anderen (sicheren) Kanal bei dem Trustgerät – sozusagen als Authentifizierungspartner – zu registrieren. Der zusätzliche Kanal kann beispielsweise eine andere (sichere) Datenleitung, ein anderer Kommunikationskanal (Telefon, SMS, Post etc.) sein. Dieses Merkmal erweist sich als besonders vorteilhaft für medizinisch-klinische Prozesse, bei denen eine Vielzahl von (oft unterschiedlichen) Kommunikationspartnern interagieren. Der Verwaltungsaufwand, der bei aus dem Stand der Technik bekannten Lösungen mit der Vorhaltung einer Zertifizierungsinstanz verbunden ist, entfällt bei der hier beschriebenen, erfundenen Lösung. Vorzugsweise wird als Verschlüsselungsmittel zum Entschlüsseln und zum Verschlüsseln der gleiche Schlüssel verwendet. Es handelt sich somit um ein symmetrisches Verschlüsselungsverfahren. Die Verwendung eines symmetrischen Algorithmus‘ bietet den Vorteil eines hohen Datendurchsatzes.
Gemäß einer Variante der Erfindung kann als Verschlüsselungsmittel eine Einweg-Hashfunktion vom Truster an den Client gesendet werden. Alternativ ist es möglich, einen geheimen Schlüssel als Verschlüsselungsmittel zu versenden.
Die vorstehend beschriebenen, erfindungsgemäßen Ausführungsformen des Verfahrens können auch als Computerprogrammprodukt mit einem Computerprogramm ausgebildet sein, wobei der Computer zur Durchführung des oben beschriebenen, erfindungsgemäßen Verfahrens veranlasst wird, wenn das Computerprogramm auf dem Computer bzw. auf einem Prozessor des Computers ausgeführt wird.
Eine alternative Aufgabenlösung besteht auch in einem Computerprogramm mit Computer-Programmcode zur Durchführung aller Verfahrensschritte des beanspruchten oder oben beschriebenen Verfahrens, wenn das Computerprogramm auf dem Computer ausgeführt wird. Dabei kann das Computerprogramm auch auf einem maschinenlesbaren Speichermedium gespeichert sein.
Eine alternative Aufgabenlösung sieht ein Speichermedium vor, das zur Speicherung des vorstehend beschriebenen, computerimplementierten Verfahrens bestimmt ist und von einem Computer lesbar ist.
Es liegt im Rahmen der Erfindung, dass nicht alle Schritte des Verfahrens zwangsläufig auf ein und derselben Computerinstanz (Clientgerät, Trustgerät) ausgeführt werden müssen, sondern sie können auch auf unterschiedlichen Computerinstanzen ausgeführt werden. Auch kann teilweise die Abfolge der Verfahrensschritte gegebenenfalls variiert werden.
Darüber hinaus ist es möglich, dass einzelne Abschnitte des vorstehend beschriebenen Verfahrens in einer verkaufsfähigen Einheit (z.B. Clientgerät) und die restlichen Komponenten in einer anderen verkaufsfähigen Einheit (z.B. Trustgerät) – sozusagen als verteiltes System – ausgeführt werden können.
In der folgenden detaillierten Figurenbeschreibung werden nicht einschränkend zu verstehende Ausführungsbeispiele mit deren Merkmalen und weiteren Vorteilen anhand der Zeichnung besprochen. In dieser zeigen:
1 eine übersichtsartige Darstellung von den Kommunikationspartnern mit den jeweiligen Modulen entsprechend einer bevorzugten Ausführungsform der Erfindung,
2 eine schematische Darstellung der ausgetauschten Datenpakete zwischen den Kommunikationspartnern entsprechend einer bevorzugten Ausführungsform der Erfindung und
3 ein Ablaufdiagramm gemäß eines Authentifizierungsverfahrens gemäß einem Ausführungsbeispiel.
Unter Bezugnahme auf die beiliegenden Figuren werden im Folgenden Ausführungsbeispiele des erfindungsgemäßen Authentifizierungsvorganges näher erläutert.
Wie in 1 näher dargestellt, kommuniziert ein Client bzw. ein Clientgerät C mit einem Trustgerät T. Üblicherweise sind Client C und Trustgerät T über eine Netzwerkverbindung NW verbunden. Client C und Trustgerät T sind als Teile eines medizintechnischen Systems, beispielsweise eines klinikinternen Netzwerkes, in ein Gesamtsystem eingebunden. Desweiteren können Client C und Trustgerät T auch Teil einer komplexen bildgebenden Anlage (z.B. MRT) sein. Um das Authentifizierungsverfahren ausführen zu können, umfasst das Trustgerät T einen Verschlüsselungsgenerator G, einen Speicherbaustein 10, eine Validierungskomponente V. Die Validierungskomponente V dient dazu, die Authentizität des Clients C zu validieren. Sie umfasst Speicherzugriffsmittel V1, eine Referenzverschlüsselungseinheit V2, einen Komparator V3. In der bevorzugten Ausführungsform sind alle der vorstehend genannten Module unmittelbar in das Trustgerät implementiert. Alternativ können einzelne Module auch ausgelagert werden.
Der Client umfasst eine Verschlüsselungseinheit K und ein Paketierungsmodul PM. Die Verschlüsselungseinheit K dient dazu, ein vom Trustgerät T empfangenes Verschlüsselungsmittel key auf eine auf dem Client generierte Nachricht N anzuwenden, um daraus eine verschlüsselte Nachricht X zu erzeugen. Das Paketierungsmodul PM dient nun dazu, ein Authentifizierungspaket P zu erzeugen. Das Authentifizierungspaket P umfasst die Nachricht N, die verschlüsselte Nachricht X und eine, für den Client C bzw. für das Clientgerät eineindeutig zugeordnete Clientadresse A. Das Authentifizierungspaket P wird an das Trustgerät T gesendet.
In 2 werden die Kommunikationspartner mit den ausgetauschten Datensätzen nochmals näher erläutert. In der in 2 dargestellten Ausführungsvariante ist der Speicherbaustein 10 nicht unmittelbar in das Trustgerät T integriert, sondern als separate Instanz bereitgestellt, die über einen entsprechenden Datenbus bzw. über ein Protokoll an das Trustgerät T sicher angeschlossen ist.
Zunächst wird in einer Initialisierungsphase, die der eigentlichen Authentifizierung vorgelagert sein kann und grundsätzlich nur einmal für jeden Client ausgeführt wird, ein clientspezifisches Verschlüsselungsmittel key auf dem Trustgerät T erzeugt. Bei dem Verschlüsselungsmittel handelt es sich um eine Verschlüsselungsfunktion, z.B. eine Einweg-Hashfunktion oder ein symmetrischer Schlüssel eines kryptographischen Verfahrens, das als ausführbares Computerprogramm in einem Speicherbaustein (z.B. in den Speicherbaustein 10 oder in anderen Speichern des Trustgerätes T) hinterlegt sein kann.
Nach Erzeugung des client-spezifischen Verschlüsselungsmittels key wird das Verschlüsselungsmittel mit einer Zuordnung auf den jeweiligen Client C, für den es erzeugt wurde, in dem Speicher 10 abgelegt. Wie in 2 durch den vom Trustgerät T auf den Client C weisenden Pfeil, der das Bezugszeichen „key()“ trägt, gekennzeichnet, wird daraufhin das erzeugte Verschlüsselungsmittel key an den Client gesendet.
Mit diesem Schritt ist die Initialisierungsphase des Authentifizierungsvorganges abgeschlossen. Daraufhin kann jede Nachricht, die am Client C erzeugt wird und an das Trustgerät T zu senden ist, auf dem Trustgerät T auf Authentizität validiert werden.
Dazu wird die Nachricht N auf dem Client C erzeugt. Daraufhin wird das empfangene Verschlüsselungsmittel key auf diese Nachricht N angewendet, um eine verschlüsselte Nachricht X zu generieren.
Daraufhin wird die verschlüsselte Nachricht X mit weiteren Datensätzen in einem Authentifizierungspaket P von dem Client C an das Trustgerät T gesendet. In einer bevorzugten Ausführungsform umfasst das Authentifizierungspaket P die Nachricht N, die verschlüsselte Nachricht X und die Clientadresse A. Dies ist in 2 mit dem unteren Pfeil gekennzeichnet, der vom Clientgerät C an das Trustgerät T gerichtet ist und mit dem Bezugszeichen „P(N, X, A)“ gekennzeichnet ist.
Nach Empfang des Authentifizierungspaketes P kann das Trustgerät T die Authentizität des sendenden Client C durch folgende Schritte überprüfen:

– Zunächst wird aus dem Authentifizierungspaket P die Clientadresse A herausgelöst. Die Clientadresse A dient zum Zugriff auf den Speicher 10, um aus dem Speicher 10 den für diese Adresse bzw. für diese client-spezifischen Verschlüsselungsmittel key zu ermitteln. Nach Ermitteln des client-spezifischen Verschlüsselungsmittel key auf dem Trustgerät T wird das so ermittelte Verschlüsselungsmittel key auf die empfangene Nachricht N‘ (also auf die Nachricht N‘, die das Trustgerät T vom Client C mit dem Authentifizierungspaket P empfangen hat) angewendet, um eine referenzverschlüsselte Nachricht X‘ zu berechnen.
– Daraufhin kann auf dem Trustgerät T ein Vergleich zwischen der referenzverschlüsselten Nachricht X‘ und der empfangenen, verschlüsselten Nachricht X aus dem Authentifizierungspaket P ausgeführt werden. Falls die referenzverschlüsselte Nachricht X‘ mit der empfangenen, verschlüsselten Nachricht X identisch übereinstimmt, gilt der jeweilige Client C auf dem Trustgerät T als authentifiziert.

Mit anderen Worten wird in der Initialisierungsphase eine Verschlüsselungsfunktion auf dem Trustgerät T erzeugt, die sowohl auf dem Trustgerät T, als auch auf dem Client bereitgestellt wird. Zur Authentifizierung des Client C wird dann diese Verschlüsselungsfunktion auf dem Client angewendet und in einem Authentifizierungspaket P wird das Verschlüsselungsergebnis mit weiteren Identifikationsdaten an das Trustgerät T gesendet. Aus den empfangenen Daten kann das Trustgerät T dann unter Zugriff auf seinen eigenen (privat abgelegten) Schlüssel diesen Schlüssel nochmals anwenden, um sozusagen eine Vergleichsverschlüsselung (oder Referenzverschlüsselung) auszuführen. Mit anderen Worten wird auf dem Client C und dem Trustgerät T dieselbe Verschlüsselungsberechnung ausgeführt. Falls beide Berechnungen zum selben Ergebnis führen, ist gewährleistet, dass sie dasselbe Verschlüsselungsmittel key verwendet haben und somit kann die Identität des Client C auf dem Trustgerät T sichergestellt werden.
Welches Verschlüsselungsmittel key nun zum Einsatz kommt, kann je nach Ausführungsform definiert werden. Wesentlich ist, dass Client C und Trustgerät T immer dasselbe Verschlüsselungsmittel key anwenden, um eine Vergleichsmöglichkeit bereitstellen zu können.
Der vorstehend beschriebene Ablauf des Verfahrens wird im Folgenden nochmals detailliert unter Bezugnahme auf 3 erläutert.
Nach dem Start des Verfahrens folgt eine Initialisierungsphase, die in 3 durch das Bezugszeichen „ADMIN/INITIAL“ bezeichnet ist. Diese Bezeichnung soll kennzeichnen, dass die Initialisierungsphase üblicherweise von einem Administrator ausgeführt werden kann und der eigentlichen Authentifizierung vorgelagert ist. Die Initialisierungsphase muss nicht unmittelbar der Authentifizierung vorangehen und wird grundsätzlich für einen Client C nur einmal ausgeführt.
Die Initialisierungsphase umfasst das Erzeugen 1 des clientspezifischen Verschlüsselungsmittels key, das Speichern 2 des Verschlüsselungsmittels key in dem Speicher 10 mit der Zuordnung zu dem jeweiligen Client C (unter Verwendung der jeweiligen Clientadresse A) und das Senden 3 des Verschlüsselungsmittels key an den Client C. Die Initialisierungsphase umfasst somit die Schritte 1, 2 und 3.
Wie in 3 dargestellt, umfasst die eigentliche Authentifizierung die folgenden Schritte:
Nachdem der Client C das Verschlüsselungsmittel key vom Trustgerät T empfangen hat, kann der Client C dieses Verschlüsselungsmittel key auf die Nachricht N anwenden, um die verschlüsselte Nachricht X zu berechnen. Der Verfahrensschritt des Berechnens trägt das Bezugszeichen 4.
Daraufhin erzeugt der Client C das Authentifizierungspaket P, umfassend die Nachricht N, die verschlüsselte Nachricht X und die Clientadresse A, an das Trustgerät T. Der Vorgang des Versendens trägt das Bezugszeichen 5.
Alle nachfolgenden Schritte werden auf dem Trustgerät T ausgeführt. Insbesondere erfolgt nach Empfang des Authentifizierungspaketes P der eigentliche Authentifizierungsvorgang durch das Validieren, das das Bezugszeichen 6 trägt und folgende Schritte umfasst:

– Im Schritt 6.1 wird das client-spezifische Verschlüsselungsmittel key durch Zugriff auf den Speicher 10 ermittelt. Der Zugriff erfolgt mit der Clientadresse A, die mit dem Authentifizierungspaket P auf dem Trustgerät empfangen worden ist.
– Das ermittelte Verschlüsselungsmittel key wird daraufhin im Schritt 6.2 auf die empfangene Nachricht N‘ zur Berechnung der referenzverschlüsselten Nachricht X‘ angewendet.
– Daraufhin kann dann im Schritt 6.3 ein Vergleich zwischen der referenzverschlüsselten Nachricht X‘ und der empfangenen verschlüsselten Nachricht X aus dem Authentifizierungspaket P ausgeführt werden. Falls die referenzverschlüsselte Nachricht X‘ mit der verschlüsselten Nachricht X identisch übereinstimmt, gilt der Client C auf dem Trustgerät T als authentifiziert.

In 3 sind auf der linken Seite die Instanzen gekennzeichnet (Trustgerät T/Client C), auf denen die jeweiligen Verfahrensschritte ausgeführt werden. In alternativen Ausführungsformen können einzelne Verfahrensschritte jedoch auch auf andere Module ausgelagert werden.
Wesentlich ist jedoch allen Ausführungsformen, dass keine zentrale Zertifizierungsinstanz notwendig ist, um die Verschlüsselungsmittel key der Clients C zu verwalten. Die Speicherung der Verschlüsselungsmittel key ist lediglich auf dem Trustgerät T selbst vorgesehen.
Wie vorstehend bereits beschrieben, wird üblicherweise als Verschlüsselungsmittel key eine Hashfunktion angewendet. Andere Ausführungsbeispiele sehen hier andere Verschlüsselungsmittel key vor, die jedoch folgende Eigenschaften haben:

– Schwer zu invertieren,
– schnell bzw. leicht zu berechnen und
– Nicht-Injektiv.

Vorzugsweise dient die Verschlüsselungsfunktion dazu, die erzeugte Bitlänge des Verschlüsselungstextes zu reduzieren.
In einem bevorzugten Ausführungsbeispiel werden unterschiedliche Hashfunktionen auf systemische Weise unter Anwendung einer symmetrischen Verschlüsselungsprozedur erzeugt, die an Stelle der Hashfunktion angewendet wird. Der Schlüssel ist somit auf dem Client C und dem Trustgerät T derselbe. Nach der Initialisierung fordert das Trustgerät T zusätzliche (externe) Mittel an, die die Authentizität des Client C sicherstellen (z.B. über einen separaten Kommunikationskanal). Sobald diese Mittel vorhanden sind, wird ein sicherer Schlüssel key erzeugt und an das Clientgerät C kommuniziert. Das Clientgerät C speichert den empfangenen Schlüssel key auf sichere Weise in einem sicheren Speicher. Das Trustgerät T verwaltet eine Liste mit Zuordnungen zwischen Clientadresse (als Identität) A und Verschlüsselungsmittel key paarweise in dem Speicher 10. Sobald ein neuer Schlüssel key für einen Client C erzeugt wurde, wird dieses Paar (A, key) in den Speicher 10 hinzugefügt. Daraufhin kann das Trustgerät T jede Nachricht N des Client C auf Authentizität überprüfen.
Dazu extrahiert das Clientgerät C einen definierten Abschnitt aus der Nachricht N. Ein wesentlicher Vorteil des Verfahrens besteht in der Abhängigkeit von X von der Nachricht N und dem geheimen Schlüssel key, wodurch abhörende Dritte das Authentisierungsmittel X nicht replizieren können. Dieser Abschnitt wird als Extrahierungsabschnitt bezeichnet und durch eine Extrahierungsfunktion ext erzeugt. Das Extrahierungsergebnis (nach Anwendung der Extrahierungsfunktion ext) wird mit dem Verschlüsselungsmittel key verschlüsselt und die daraus resultierende verschlüsselte Nachricht X wird zusammen mit der Clientidentität A und der erzeugten Nachricht N an das Trustgerät T übermittelt.
Das Trustgerät T kann daraufhin jedes Mal die Authentizität des sendenden Client C verifizieren, falls ein solches Authentifizierungspaket P vom Client auf dem Trustgerät T empfangen werden konnte. Dazu wird ein Look-Up in dem Speicher 10 ausgeführt, um den Schlüssel key zu finden, der der jeweiligen Sendeadresse/Identität A des Client C zugeordnet ist. Daraufhin kann die verschlüsselte Nachricht X entschlüsselt werden und das Ergebnis mit dem extrahierten Abschnitt aus dem empfangenen Datensatz auf Übereinstimmung verglichen werden. Falls der Vergleich eine Übereinstimmung indiziert, gilt der sendende Client C als authentifiziert. In diesem Fall ist die auf dem Client C verschlüsselte Form X der Nachricht N durch folgende Funktion definiert. X = key(ext(N). Auf dem Trustgerät T wird folgende Berechnung ausgeführt, die eine Entschlüsselung mit dem aus dem Speicher 10 zugegriffenen Schlüssel key umfasst. Die behauptete Identität A des Client C (empfangen durch das Authentifizierungspaket P) wird auf dem Trustgerät T verwendet, um den identitäts-spezifischen Schlüssel key aus dem Speicher 10 abzurufen und daraufhin auf die empfangene Nachricht dieselben Schritte anzuwenden, die der Client C angewendet hat, also zunächst die Extrahierungsfunktion ext, um die extrahierte Nachricht N_ext zu erzeugen und daraufhin die Entschlüsselung mit demselben Verschlüsselungsmittel key. Falls das Ergebnis übereinstimmt, gilt der Client C als authentifiziert.
Vorzugsweise hat die Extrahierungsfunktion ext dieselben Eigenschaften wie das Verschlüsselungsmittel key, und ist insbesondere schnell zu berechnen, kaum oder nur schwer umzukehren und injektiv.
In den vorstehend beschriebenen Ausführungsbeispielen ist es notwendig, das Clientgerät C und Trustgerät T sich im Vorfeld über das auszuführende Authentifizierungsverfahren zur Extrahierung der Nachrichten einigen. Mit anderen Worten muss die Extrahierungsfunktion ext im Vorfeld zwischen Client C und Trustgerät T verabredet sein.
In einem weiteren Ausführungsbeispiel werden die Algorithmen zur Berechnung der Extrahierungsfunktion ext und des Verschlüsselungsmittels key in Kombination, z.B. als „key(ext())“ in einem ausführbaren Format (beispielweise als ausführbare Datei „app“ einer standardisierten Rechner-Plattform) an den Client C gesendet, wobei der geheime Schlüssel key bereits in diese Algorithmen integriert ist. In diesem Ausführungsbeispiel wird somit eine mobile Software mit darin integrierten Algorithmen von Trustgerät T an den Client C gesendet. In diesem Ausführungsbeispiel ist es nicht mehr notwendig, dass sich Client C und Trustgerät T im Vorfeld über das anzuwendende Prozedere einigen. Damit kann eine weitere Flexibilität erreicht werden, da die auszuführenden Berechnungen und Funktionen bereits in die mobile Software integriert sind. Die jeweilige Applikation zur Berechnung von key(ext(N)) wird sowohl client- als auch trustseitig verwendet. Somit sind die beiden Berechnungsvorschriften, nämlich die Extrahierungsfunktion ext und das Verschlüsselungsmittel key als Konkatenation implementiert. In diesem Ausführungsbeispiel speichert das Trustgerät T neben der Zuordnung zwischen Clientidentität A und client-spezifischem Verschlüsselungsmittel key auch noch die mobile Softwareapplikation (z.B. als standardisierte „app“).
In einer weiteren Ausführungsform kann eine Erweiterung des vorstehend beschriebenen Authentifizierungsschemas angewendet werden. In dieser Ausführungsform extrahiert der Client C einen definierten Ausschnitt der erzeugten Nachricht N und verschlüsselt diese mit dem sicheren Verschlüsselungsmittel key und sendet es, wie vorstehend bereits beschrieben, im Rahmen des Authentifizierungspaketes P an das Trustgerät T. Das Trustgerät T führt daraufhin wieder einen Zugriff auf den Speicherbaustein 10 aus, um mit der Clientidentität (Adresse A des Client C) den client-spezifischen Schlüssel aus der Liste herauszulesen und den definierten Ausschnitt zu entschlüsseln und das Ergebnis mit dem Bestandteil des Authentifizierungpaketes P auf Übereinstimmung zu vergleichen.
In einer weiteren Ausführungsform kann zum Schutz gegen Abhören eine andere Erweiterung des vorstehend beschriebenen Authentifizierungsschemas angewendet werden. Dazu wird als Ausführung der Verschlüsselungsfunktion key() der Eingabewert derart modifiziert, dass eine zufällige Größe oder eine Zeitmarke hinzugefügt wird. Alle Komponenten und Schritte des Verfahrens bleiben wie vorstehend beschrieben. Durch das Mitführen der verschlüsselten Uhrzeit oder Zufallszahl in der verschlüsselten Form X wird es vermieden, dass (insbesondere bei Clientgeräten C, die Werte von einfachen Sensoren übermitteln) durch immer wiederholte gleiche Werte für eine Nachricht N auch gleiche Werte für die verschlüsselte Form X als Teil von dem Authentisierungspakte P über die Verbindung zum Trustgerät T übermittelt und für Dritte replizierbar werden.
Ein besonderer Vorteil der erfindungsgemäßen Lösung ist darin zu sehen, dass es möglich ist, auf eine Public-key-Infrastruktur zu verzichten. Damit kann das Authentifizierungssystem wesentlich flexibler und einfacher und auch kostengünstiger bereitgestellt werden. Zur Authentifizierung ist es deshalb nicht mehr nötig, auf eine zentrale Instanz (Zertifizierungsinstanz) zuzugreifen, um die Identität eines Client C zu validieren. Ein weiterer Vorteil ist darin zu sehen, dass beliebige Clients C auf einem Trustgerät T authentifiziert werden können, ohne dass auf den Clients C vorbereitende Maßnahmen ausgeführt werden müssen. Die Schlüssel sind vorteilhafterweise schnell und einfach zu erzeugen.
Abschließend sei darauf hingewiesen, dass die Beschreibung der Erfindung und die Ausführungsbeispiele grundsätzlich nicht einschränkend in Hinblick auf eine bestimmte physikalische Realisierung der Erfindung zu verstehen sind. Für einen Fachmann ist es insbesondere offensichtlich, dass die Erfindung teilweise oder vollständig in Soft- und/oder Hardware und/oder auf mehrere physikalische Produkte – dabei insbesondere auch Computerprogrammprodukte – verteilt realisiert werden kann.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Nicht-Patentliteratur

Vgl. hierzu: Wolfgang Ertel: Angewandte Kryptographie, Carl Hanser Verlag, S. 68–75; S. 94 und Bundesamt für Sicherheit in der Informationstechnik: IT-Grundschutz, M 3.23 Einführung in kryptographische Grundbegriffe, abrufbar unter: https://www.bsi.bund.de/ContentBSI/grundschutz/kataloge/m/m03/m03023.html [0021]
Christoph Ruland: Informationssicherheit in Datennetzen; DATACOM-Verlag; Bergheim, 1993; ISBN 3-89238-081-3; Seite 68ff [0022]

Claims

Authentifizierungssystem zur Authentifizierung eines Client (C) an einer medizintechnischen Anlage, die als Trustgerät (T) fungiert, mit: – Einem Trustgerät (T) mit: – einem Verschlüsselungsgenerator (G), der dazu bestimmt ist, ein client-spezifisches Verschlüsselungsmittel (key) zu erzeugen, – einem Speicherbaustein (10), der zur Speicherung einer Zuordnung zwischen dem jeweiligen Client (C) und des für ihn erzeugten Verschlüsselungsmittels (key) bestimmt ist, – einer Sendekomponente (S), die dazu bestimmt ist, das erzeugte Verschlüsselungsmittel (key) an den Client (C) zu senden, – einer Validierungskomponente (V), die dazu bestimmt ist, die Authentizität des Clients (C) zu validieren, umfassend: – Speicherzugriffsmittel (V1), die dazu bestimmt sind, das client-spezifische Verschlüsselungsmittel (key) durch Zugriff auf den Speicherbaustein (10) zu ermitteln, wobei der Zugriff auf dasjenige client-spezifische Verschlüsselungsmittel (key) erfolgt, das jeweils einer vom Client (C) empfangenen Clientadresse (A) zugeordnet ist. – Eine Referenzverschlüsselungseinheit (V2), die dazu bestimmt ist, das ermittelte Verschlüsselungsmittel (key) auf die empfangene Nachricht (N‘) zur Berechnung einer referenzverschlüsselten Nachricht (X‘) anzuwenden. – Einen Komparator (V3), der dazu bestimmt ist, ein Authentifizierungspaket (P) von dem Client (C) zu empfangen und der weiterhin dazu bestimmt ist, die referenzverschlüsselte Nachricht (X‘) mit einer empfangenen verschlüsselten Nachricht (X) aus dem Authentifizierungspaket (P) auf Identität zu vergleichen und, der dazu bestimmt ist, bei Identität den Client (C) auf dem Trustgerät (T) zu authentifizieren. – Einem Client (C) mit: – einer Verschlüsselungseinheit (K), die dazu bestimmt ist, das empfangene Verschlüsselungsmittel (key) auf eine Nachricht (N) zum Berechnen einer verschlüsselten Nachricht (X) anzuwenden, – einem Paketierungsmodul (PM), das dazu bestimmt ist, ein Authentifizierungspaket (P) zu erzeugen, umfassend die Nachricht (N), die verschlüsselte Nachricht (X) und eine Clientadresse (A) und das dazu bestimmt ist, das Authentifizierungspaket (P) an das Trustgerät (T) zu senden.
Client (C) mit einer Verschlüsselungseinheit (K) und einem Paketierungsmodul (PM) zur Anwendung in einem Authentifizierungssystem nach Anspruch 1.
Trustgerät (T) mit einem Verschlüsselungsgenerator (G), einem Speicherbaustein (10), einer Sendekomponente (S) und einer Validierungskomponente (V) zur Anwendung in einem Authentifizierungssystem nach Anspruch 1.
Verfahren zur Authentifizierung eines Client (C) an einer medizintechnischen Anlage, die als Trustgerät (T) fungiert, wobei das Verfahren folgende Verfahrensschritte umfasst: – Seitens des Trustgerätes (T): Initialisieren der Authentifizierung durch folgende Schritte: – Erzeugen (1) eines client-spezifischen Verschlüsselungsmittels (key) auf dem Trustgerät (T), – Speichern (2) des client-spezifischen Verschlüsselungsmittels (key) in einem Speicher (10) auf dem Trustgerät (T) mit einer Zuordnung zwischen dem jeweiligen Client (C) und des für ihn erzeugten Verschlüsselungsmittels (key),. – Senden (3) des erzeugten Verschlüsselungsmittels (key) an den Client (C) – Seitens des Client (C): Anwenden des empfangenen Verschlüsselungsmittels (key) auf eine Nachricht (N) zum Berechnen (4) einer verschlüsselten Nachricht (X). – Seitens des Client (C): Versenden (5) eines Authentifizierungspaketes (P), umfassend die Nachricht (N), die verschlüsselte Nachricht (X) und eine Clientadresse (A) an das Trustgerät (T). – Seitens des Trustgerätes (T): Validieren (6) der Authentizität des Client (C) durch folgende Schritte: – Ermitteln (6.1) des client-spezifischen Verschlüsselungsmittels (key) durch Zugriff auf den Speicher (10), das jeweils der empfangenen Clientadresse (A) zugeordnet ist, – Anwenden (6.2) des ermittelten Verschlüsselungsmittels (key) auf die empfangene Nachricht (N‘) zur Berechnung einer referenzverschlüsselten Nachricht (X‘), – Vergleich (6.3) der referenzverschlüsselten Nachricht (X‘) mit der empfangenen verschlüsselten Nachricht (X) aus dem Authentifizierungspaket (P) auf Identität und bei Identität: Authentifizieren des Client (C) auf dem Trustgerät (T).
Verfahren nach Patentanspruch 4, bei dem das Authentifizieren ohne eine separate, zum Client (C) und zum Trustgerät (T) zusätzliche Zertifizierungsinstanz ausgeführt wird.
Verfahren nach einem der vorstehenden Verfahrensansprüche, bei dem das Initialisieren für jeden Client (C) nur einmal ausgeführt wird und das Berechnen (4) einer verschlüsselten Nachricht (X) und das Versenden (5) des Authentifizierungspaketes (P) seines des Clients (C), das Validieren (6) seitens des Trustgerätes (T) für alle oder ausgewählte Nachrichten angewendet wird, die von Client (C) an das Trustgerät (T) gesendet werden.
Verfahren nach einem der vorstehenden Verfahrensansprüche, bei dem das Verschlüsselungsmittel (key) und ein Referenzverschlüsselungsmittel übereinstimmen.
Verfahren nach einem der vorstehenden Verfahrensansprüche, bei dem das Verschlüsselungsmittel (key) eine kollisionsresistente und/oder eine Einweg-Hashfunktion ist.
Verfahren nach einem der vorstehenden Verfahrensansprüche, bei dem das Verschlüsselungsmittel (key) eine symmetrische kryptologische Funktion ist.
Verfahren nach einem der vorstehenden Verfahrensansprüche, bei dem auf dem Client (C) zunächst auf die erzeugte Nachricht (N) eine Extrahierungsfunktion (ext) angewendet wird, um eine extrahierte Nachricht (N_ext) zu erzeugen und um daraufhin das Verschlüsselungsmittel (key) auf die extrahierte Nachricht (N_EXT) anzuwenden und in dem Authentifizierungspaket (P) an das Trustgerät (T) zur Authentizitätsprüfung zu übertragen.
Verfahren nach einem der vorstehenden Verfahrensansprüche, bei dem das client-spezifische Verschlüsselungsmittel (key) eine Konkatenation einer Verschlüsselungsfunktion und einer Extrahierungsfunktion (ext) ist und als mobile ausführbare Applikationsdatei (App) übertragen wird.
Verfahren nach einem der vorstehenden Verfahrensansprüche, bei dem eine Identität, eine Nachricht oder ein Nachrichtenkonvolut authentifiziert wird.
Computerprogrammprodukt ladbar oder geladen in einen Speicher eines Computers (C, T) oder eines tragbaren Datenträgers mit von dem Computer lesbaren Befehlen zur Ausführung des Verfahrens nach einem der vorstehenden Verfahrensansprüche, wenn die Befehle auf dem Computer (C, T) ausgeführt werden.