DE19515613A1 - Verfahren zur Authentikation und elektronischen Unterschirft bei Kommunikationsverbindungen - Google Patents

Description

Die Erfindung bezieht sich auf ein Verfahren der im Ober­ begriff des Patentanspruch 1 näher beschriebenen Art. Verfahren solcher Art sind mit mathematischer Asymmetrie unter Bezeichnungen wie RSA, DSS, EL Gamal, FS, usw. allgemein bekannt.

Andererseits sind auch eine Reihe von symmetrischen Krypto- Verfahren bekannt, die einfacher und weniger aufwendig in der technischen Realisierung sind, aber dafür einen wesent­ lich höheren Aufwand für die Schlüsselverwaltung benötigen.

Aufgabe der Erfindung ist es, mathematisch symmetrische Verfahren so zu gestalten, daß sie hinsichtlich der Schlüs­ selverwaltung und der Sicherheitsfunktionen Eigenschaften wie asymmetrische Verfahren aufweisen, ohne den technischen Aufwand der mathematischen Asymmetrie zu betreiben.

Diese Aufgabe wird mit der im Kennzeichen des Patentan­ spruchs 1 beschriebenen Verfahrensweise gelöst.

Vorteilhafte Weiterbildungen des Verfahrens sind in den Kennzeichen der Unteransprüche 2 bis 4 beschrieben.

Das Wesentliche des Verfahrens besteht darin, daß die für Authentikation und elektronische Unterschrift erforderliche Asymmetrie nicht auf "mathematischem", d. h. kryptografi­ schem Wege erreicht wird, sondern durch die Kombination herkömmlicher symmetrischer Kryptoverfahren mit asymmetri­ schen Verarbeitungsprozessen in einer zwar verteilten, aber sicheren Implementationsumgebung.

In allen Anwendungsbereichen, in denen eine sichere Hardwareumgebung wie Sicherheitsmodule also z. B. auch Prozessorchipkarten an die Benutzer ausgegeben werden können, kann mit Hilfe dieses Verfahren auf die Verwendung asymmetrischer Kryptoverfahren verzichtet werden.

Die Anwendungsmöglichkeit umfaßt alle Bereiche, in denen Authentikationsverfahren und elektronische Unterschriften angewendet werden und damit nicht nur die in den nachfol­ genden Ausführungsbeispielen näher beschriebenen Verfahren. Letztere sind nur zur Erläuterung und stellvertretend für vielerlei Varianten näher ausgeführt. In den zugehörigen Zeichnungen sind zwei mehr und dazu jeweils zwei weniger unterschiedliche Varianten dargestellt. Es zeigen die

Fig. 1 die Variante I,

Fig. 2 die Variante Ia,

Fig. 3 die Variante II und

Fig. 4 die Variante IIa.

Diese in Fig. 1 dargestellte Variante I kann zur Erzeugung einer elektronischen Unterschrift und für Authentikations­ zwecke eingesetzt werden.

Der Prozeß: SIGN = Signatur-Prozeß und VERIFY = Verifi­ zierungs-Prozeß läuft in der sicheren Umgebung des unpersonalisierten Sicherheitsmoduls SM, z. B. Prozessorchipkarte, ab.

Im vom Trust Center personalisierten Sicherheitsmodul SM-A und im Sicherheitsmodul SM-B der Ausgabestelle verlaufen die darin dargestellten Prozesse, wobei
CAs = der geheime symmetrische Schlüssel der Ausgabestelle,
A = die Identität des Benutzers A,
B = die Identität des Benutzers B,
SM-A = der Sicherheitsmodul SM des Benutzers A und
SM-B = der Sicherheitsmodul SM des Benutzers ist.

A unterschreibt Nachricht "data":

SIGN: CAs[A, data]

im Sicherheitsmodul SM-A des Benutzers A. Dieser Prozeß läuft in der sicheren Hardwareumgebung des Sicherheitsmodul SM des Benutzers A ab.

Im Sicherheitsmodul SM-A des Benutzers A kann statt "data" auch dessen Hashwert h (data) verwertet werden. Zusätzlich können "Timestamps", Seriennummern, entsprechend CCITT X 509 u. a. verwendet werden.

A sendet die unterschriebene Nachricht an B:

A→A, data, CAs [A, data] → B oder z. B.
A, data, CAs [A, h(data)]

Es kann auch der Klartext von "A, data" mitgesendet werden.

B verifiziert die von A empfangene Nachricht:

im Sicherheitsmodul SM-B des Benutzers B.

Alle Prozeßschritte laufen immer in enger Verbindung miteinander ab. Das Sicherheitsmodul SM-B gibt an die Außenwelt nur das Ergebnis des 3. data-data Gesamtprozesses bekannt.

Vorteil dieser Variante I ist, neben der Vermeidung eines asymmetrischen Kryptoverfahrens, daß für das Unterschrifts­ verfahren praktisch alle Prozessorchipkarten als SM geeig­ net sind. Demgegenüber werden für asymmetrische Verfahren spezielle Controller benötigt. Unterschriftsverfahren sind damit nicht mehr von nur einem oder ganz wenigen (asymme­ trischen) Kryptoverfahren abhängig. Es lassen sich jedoch teilweise beliebige symmetrische Kryptoverfahren bei belie­ bigen Schlüssellängen einsetzen.

Durch die Verwendbarkeit von symmetrischen Kryptoverfahren werden die Rechenzeiten für Signatur- und Verifikationspro­ zesse erheblich verringert.

Bei einem erfolgreichen Angriff auf ein einmal eingesetztes Kryptoverfahren stehen andere (symmetrische) Ersatzverfah­ ren sofort zur Verfügung.

Es können die gegenüber asymmetrischen Verfahren erheblich einfacheren Schlüsselerzeugungsverfahren angewendet werden.

Diese Variante I bietet zusätzlich den Vorteil, daß das gesamte System mit nur einem einzigen Schlüssel arbeitet; ihr spezieller Nachteil ist: chosen plain text - Angriff vereinfacht möglich.

Die besonderen Eigenschaften eines asymmetrischen Verfah­ rens werden unter Verwendung eines erheblich weniger kom­ plexen, beliebigen symmetrischen Verfahrens nachgebildet durch die feste Einbindung zweier unterschiedlicher, "asymmetrischer" Prozesse, die hier "SIGN" und "VERIFI" genannt sind, in die sichere Umgebung eines Sicherheits­ moduls SM.

Die Beglaubigung der Identität von A findet nicht mehr in der Ausgabestelle statt. Vielmehr ist der geheime Beglaubi­ gungsschlüssel CAs der Ausgabestelle unauslesbar in der sicheren Umgebung aller SM gespeichert. Er wird nur im SIGN-Prozeß und im VERIFY-Prozeß intern im Sicherheitsmodul SM verwendet. Die "Beglaubigung" der Ausgabestelle findet somit jedesmal neu zum Anlaß der Erzeugung einer individu­ ellen Unterschrift statt.

Die in Fig. 2 dargestellte Variante Ia ist eine Abart der Variante I. Sie dient jedoch nicht zur Erzeugung und Veri­ fizierung einer Unterschrift, sondern zur Vereinbarung eines authentischen Sitzungsschlüssels "Ks" zwischen zwei Benutzern A und B, die eine gegenüber Dritte vertrauliche Kommunikation (Verschlüsselung von Nachrichten) aufbauen wollen.

In der Fig. 2 bedeuten:
SEAL Ks = Prozeß zur Verschlüsselung eines authentischen Sitzungsschlüssels und
RETRIEVE Ks = Prozeß zur Verifizierung und Entschlüsselung eines authentischen Sitzungsschlüssels.

A erzeugt einen authentischen, vertraulichen Sitzungs­ schlüssel: (hier 1-Way Token gemäß CCITT X.509)

SEAL Ks: CAs [A, B, rA, Ks]

im Sicherheitsmodul SM-A des Benutzers A.

A sendet Sitzungsschlüssel an B:

A → CAs [A, B, rA, Ks] → B

Es kann auch der Klartext von "A, B, rA" mitgesendet werden.

B verifiziert und entschlüsselt Sitzungsschlüssel:

Der Sitzungsschlüssel Ks kann nun für Verschlüsselungs­ zwecke innerhalb und ggf. auch außerhalb der Sicherheits­ module SM eingesetzt werden.

Weitere Varianten z. B. mit 2-Way- oder 3-Way-Token, auch mit zusätzlichen Parametern (Klartext, Time Stamps usw., entsprechend CCITT X.509, sind ebenfalls im Rahmen der Erfindung vorgesehen.

Die Vorteile und Eigenschaften der Variante Ia entsprechen denen der Variante I.

Der wesentliche Unterschied der Variante II besteht darin, daß bei diesen Abarten zusätzlich benutzerindividuelle Schlüssel As und Bs zur Unterschriftserzeugung eingesetzt werden. Diese Maßnahme gleicht das hier beschriebene Be­ glaubigungs- und Unterschriftsverfahren in seinen Eigen­ schaften noch stärker an die einschlägig bekannten Verfah­ ren auf der Basis asymmetrischer Verfahren an (z. B. CCITT X.509) und erschwert bzw. verhindert den im Verfahren I möglichen "chosen plain text - Angriff". Dieser Vorteil wird mit einer erheblich höheren Anzahl an benötigten Schlüsseln (je einer pro Benutzer) erkauft. Im übrigen sind die Eigenschaften der in Fig. 3 dargestellten Variante II mit denen der Variante I identisch.

Der Prozeß: SIGN = Signatur-Prozeß und VERIFY = Verifi­ zierungs-Prozeß läuft wieder in der sicheren Umgebung des unpersonalisierten Sicherheitsmoduls SM, z. B. Prozessor­ chipkarte, ab:
SIGN - Signatur-Prozeß
VERIFY - Verifizierungs-Prozeß
SM - Sicherheitsmodul

Bei den weiteren in Fig. 3 dargestellten Prozeduren der vom Trust Center (Ausgabestelle) personalisierten Sicherheits­ module SM-A und SM-B bedeuten:
CAs = Geheimer, symmetrischer Schlüssel der Ausgabestelle,
A = Identität von Benutzer A,
B = Identität von Benutzer B,
SM-A = Sicherheitsmodul SM des Benutzers A,
SM-B = Sicherheitsmodul SM des Benutzers B,
As = geheimer Schlüssel des Benutzers A,
Bs = geheimer Schlüssel des Benutzers B,
CA⟨⟨A⟩⟩ = Zertifikat von A = CAs [A, As], A,
CA⟨⟨B⟩⟩ = Zertifikat von B = CAs [B, Bs], B.

Es können zusätzlich auch Time Stamps zur Festlegung einer begrenzten Gültigkeitsdauer für Zertifikate und Seriennum­ mern u. a. (z. B. gemäß CCITT X.509) verwendet werden.

A unterschreibt Nachricht "data":

SIGN: CAs [data]

Der Prozeß läuft in der sicheren Umgebung des Sicherheits­ moduls SM-A ab. Statt "data" kann auch Hashwert h (data) verwendet werden, auch können zusätzlich "Timestamps", Seriennummern, entsprechend CCITT X.509, verwendet werden.

A sendet unterschrieben Nachricht an B:

A → CA⟨⟨A⟩⟩, As [data] → B; oder z. B.:
CAs⟨⟨A⟩⟩, As [h (data) ]

wobei der Prozeß "h (data)" außerhalb des Sicherheitsmoduls SM erfolgen kann. Es kann auch der Klartext von "data" mit gesendet werden.

B verifiziert die von A empfangene Nachricht im SM-B:

Alle Prozeßschritte laufen immer in direkter Reihenfolge. Das SM gibt an die Außenwelt nur das Ergebnis des Gesamtprozesses bekannt.

Der VERIFY-Prozeß kann auch in 2 Prozesse "VERIFY certificate" und "VERIFY signature" aufgespalten werden.

Diese Variante II hat neben der Vermeidung eines asymmetri­ schen Kryptoverfahrens folgende Vorteile der Variante I:

• - Für das Unterschriftsverfahren sind praktisch alle Pro­ zessorchipkarten als SM geeignet. Dagegen werden für asymmetrische Verfahren spezielle Controller benötigt.
• - Das Unterschriftsverfahren ist damit nicht mehr von nur einem oder ganz wenigen (asymmetrischen) Kryptoverfahren abhängig. Es lassen sich vielmehr beliebige symmetrische (Kryptoverfahren mit beliebigen Schlüssellängen einsetzen.
• - Durch die Verwendbarkeit von symmetrischen Kryptoverfahren werden die Rechenzeiten für Signatur- und Verifikationsprozesse erheblich verringert.
• - Bei einem erfolgreichen Angriff auf ein einmal eingesetztes Kryptoverfahren stehen andere (symmetrische) Ersatzverfahren sofort zur Verfügung.
• - Es können die gegenüber asymmetrischen Verfahren erheblich einfacheren Schlüsselerzeugungsverfahren angewendet werden.

Die Variante II bietet zusätzlich den Vorteil, daß das System mit nur einem einzigen Schlüssel arbeitet (Nachteil: chosen plain text - Angriff vereinfacht möglich).

Die besonderen Eigenschaften eines asymmetrischen Ver­ fahrens werden unter Verwendung eines erheblich weniger komplexen, beliebigen symmetrischen Verfahrens nachgebil­ det durch die feste Einbindung zweier unterschiedlicher, "asymmetrischer" Prozesse, hier: "SIGN" und "VERIFY" genannt, in die sichere Umgebung eines SM.

Die Beglaubigung der Identität von A findet nicht mehr in der Ausgabestelle statt. Vielmehr ist der geheime Beglaubi­ gungsschlüssel CAs der Ausgabestelle unauslesbar in der sicheren Umgebung aller SM gespeichert. Er wird nur im SIGN-Prozeß und im VERIFY-Prozeß intern im SM verwendet. Die "Beglaubigung" der Ausgabestelle findet somit jedesmal neu zum Anlaß der Erzeugung einer individuellen Unterschrift statt.

Die in Fig. 4 gezeigte Variante IIa ist eine Abart der Variante II. Sie dient, wie die Variante Ia, nicht zur Erzeugung und Verifizierung einer Unterschrift, sondern zur Vereinbarung eines authentischen Sitzungsschlüssels "Ks" zwischen zwei Benutzern A und B, die eine gegenüber Dritten vertrauliche Kommunikation (Verschlüsselung von Nachrich­ ten) aufbauen wollen.

In der Fig. 4 bedeuten:
Ks = sitzungsindividueller geheimer Sitzungsschlüssel,
SEAL Ks = Prozeß zur Verschlüsselung eines authentischen Sitzungsschlüssels,
RETRIEVE Ks = Prozeß zur Verifizierung und Entschlüsselung eines authentischen Sitzungsschlüssels.

A verschlüsselt Sitzungsschlüssel Ks für B im SM-A:
(hier: 1-Way Token)
SIGN Ks: As [B, rA, Ks]
rA = Sitzungsnummer (challenge "A"),
Ks = Sitzungsschlüssel, kann auch von außen ins SM geladen werden oder fest im SM gespeichert sein oder per Zufallsgenerator im SM erzeugt worden sein.
B, n, Ks ↔ "data" aus Variante II.

A sendet authentischen Eröffnungs-Token an B:

A → CA⟨⟨A⟩⟩,As [B, rA, Ks]

Es kann auch der Klartext von "B, rA" mitgesendet werden.

B verifiziert die von A erhaltene Nachricht im SM-B:

Ks kann nun für Verschlüsselungszwecke innerhalb und außerhalb der SM eingesetzt werden.

Weitere Varianten z. B. mit 2-Way- oder 3-Way-Token, auch mit zusätzlichen Parametern (Time Stamps usw.) z. B. entsprechend CCITT X.509 sind ebenfalls im Rahmen der Erfindung möglich.

Die Vorteile und Effekte der Variante IIa entsprechen denen der Variante Ia.

Bezugszeichenliste

SIGN = Signatur-Prozeß;
VERIFY = Verifizierungs-Prozeß;
SM = Sicherheitsmodul, z. B. Prozessorchipkarte;
CAs = Geheimer, symmetrischer Schlüssel der Ausgabestelle;
A = Identität von Benutzer A;
B = Identität von Benutzer B;
SM-A = SM des Benutzers A;
SM-B = SM des Benutzers B;
Ks = sitzungsindividueller geheimer Sitzungs­ schlüssel, der auch von außen ins SM geladen werden oder fest im SM gespeichert sein oder per Zufallsgenerator im SM erzeugt sein kann;
SEAL Ks = Prozeß zur Verschlüsselung eines authentischen Sitzungsschlüssels;
RETRIEVE Ks = Prozeß zur Verifizierung und Entschlüsselung eines authentischen Sitzungsschlüssels;
As = geheimer Schlüssel des Benutzers A;
Bs = geheimer Schlüssel des Benutzers B;
CA⟨⟨A⟩⟩ = Zertifikat von A = CAs [A, As], A;
CA⟨⟨B⟩⟩ = Zertifikat von B = CAs [B, Bs], B;

Claims (4)

1 Verfahren zur Authentikation und elektronischen Unter­ schrift bei Kommunikationsverbindungen, bei denen kryptografische Verfahren in Verbindung mit hardware­ seitigen Sicherheitsmodulen bei den Benutzern verwendet werden, dadurch gekennzeichnet, daß mathematisch symmetrische Kryptoverfahren in Ver­ bindung mit wenigstens zwei fest und manipulationssi­ cher in der hardwareseitig verteilten Implementations- Umgebung der Sicherheitsmodule vor der Ausgabe inte­ grierten asymmetrischen Verarbeitungsprozessen verwen­ det werden.

2 Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß die Sicherheitsmodule vor der Ausgabe mit einer Benut­ zeridentität versehen und beglaubigt werden.

3 Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß alle Sicherheitsmodule vor der Ausgabe mit einem gehei­ men Beglaubigungsschlüssel CAs der Ausgabestelle verse­ hen werden und daß dieser nur intern im Sicherheitsmo­ dul während der wenigstens zwei asymmetrischen Verar­ beitungsprozesse verwendet wird.

4 Verfahren nach Anspruch 1 bis 3, dadurch gekennzeichnet, daß zwischen den Benutzern zusätzlich ein authentischer Sitzungsschlüssel erzeugt und verwendet wird.