Grammatikbasierte Zertiﬁkate am Beispiel von ... · dem XPath-Standard aus den Namen der in den...

Grammatikbasierte Zertifikateam Beispiel von Sicherheitsauditierungen

in verteilten IT-Systemen

Von der Fakultät Informatik, Elektrotechnik und Informationstechnikder Universität Stuttgart zur Erlangung der Würde

eines Doktor-Ingenieurs (Dr.-Ing.) genehmigte Abhandlung

vorgelegt von

Matthias Kabatnik

geb. in Stuttgart-Bad Cannstatt

Hauptberichter: Prof. em. Dr.-Ing. Dr.-Ing. E.h. Dr. h.c. Paul J. Kühn

1. Mitberichter: Prof. Dr.-Ing. Günter Schäfer, Techn. Univ. Ilmenau

2. Mitberichter: Prof. Dr.-Ing. Andreas Kirstädter

Tag der Einreichung: 14.06.2013

Tag der mündlichen Prüfung: 25.02.2015

Institut für Kommunikationsnetze und RechnersystemeUniversität Stuttgart

2015

Inhaltsverzeichnis

Inhaltsverzeichnis i

Kurzfassung vii

Abstract xi

Abbildungsverzeichnis xv

Tabellenverzeichnis xvii

Abkürzungsverzeichnis xix

1 Motivation und Zielsetzung 11.1 Sicherheitsanalysen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Auditierungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2.1 Häufigkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2.2 Dokumentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.2.3 Vorgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.3 Ziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.3.1 Flexibilität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.3.2 Erhöhung der Verbindlichkeit . . . . . . . . . . . . . . . . . . . . . . . 91.3.3 Verständlichkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.3.4 Automatisierte Auswertung . . . . . . . . . . . . . . . . . . . . . . . . 101.3.5 Delegation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.4 Überblick über die Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2 Zertifizierungssysteme 132.1 Grundbegriffe kryptographischer Kommunikationssicherung . . . . . . . . . . . 132.2 Signaturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2.1 Signaturbegriff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.2.2 Signaturarten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.2.3 Verwendung von Signaturen . . . . . . . . . . . . . . . . . . . . . . . . 19

2.3 Standardisierte Signaturformate . . . . . . . . . . . . . . . . . . . . . . . . . . 22

i

ii INHALTSVERZEICHNIS

2.3.1 PKCS#1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.3.2 PKCS#7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.3.3 XML basierte Signaturen . . . . . . . . . . . . . . . . . . . . . . . . . . 242.3.4 Pretty Good Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.3.5 Portable Document Format . . . . . . . . . . . . . . . . . . . . . . . . . 262.3.6 S/MIME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.4 Digitale Zertifikate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.4.1 Zertifikatsbegriff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.4.2 Zertifikatsarten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.5 Schlüsselzertifikate am Beispiel des X.509-Standards . . . . . . . . . . . . . . . 292.5.1 Zertifikatsinhalt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.5.2 Erweiterungsfelder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.5.3 Kodierung der X.509-Zertifikate . . . . . . . . . . . . . . . . . . . . . . 312.5.4 Zertifizierungsrichtlinien . . . . . . . . . . . . . . . . . . . . . . . . . . 322.5.5 Gültigkeitsprüfung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322.5.6 Rückrufmechanismen . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.6 Standardisierte Zusicherungen und Zertifikate . . . . . . . . . . . . . . . . . . . 352.6.1 Pretty Good Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362.6.2 SPKI/SDSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362.6.3 Kerberos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362.6.4 SAML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382.6.5 XACML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392.6.6 PERMIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392.6.7 SecPAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402.6.8 Ponder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402.6.9 PolicyMaker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412.6.10 Keynote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

2.7 Bewertung der bestehenden Mechanismen . . . . . . . . . . . . . . . . . . . . . 42

3 Methoden zur Sicherheitsanalyse 453.1 SVO-Logik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.1.1 Vorgehensweise bei SVO-Analysen . . . . . . . . . . . . . . . . . . . . 463.1.2 Notation der SVO-Logik . . . . . . . . . . . . . . . . . . . . . . . . . . 463.1.3 Schlussregeln der SVO-Logik . . . . . . . . . . . . . . . . . . . . . . . 483.1.4 Subjektive Sichtweise . . . . . . . . . . . . . . . . . . . . . . . . . . . 483.1.5 Erweiterung der SVO-Logik . . . . . . . . . . . . . . . . . . . . . . . . 51

3.2 Angewandter Pi-Kalkül . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523.2.1 Prozesskalküle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523.2.2 Der Pi-Kalkül . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523.2.3 Erweiterung zum angewandten Pi-Kalkül . . . . . . . . . . . . . . . . . 533.2.4 Funktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

3.3 Automatisierte Protokollanalysen mit Proverif . . . . . . . . . . . . . . . . . . . 583.3.1 Notation und Semantik . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

INHALTSVERZEICHNIS iii

3.3.2 Nachweis von Vertraulichkeit . . . . . . . . . . . . . . . . . . . . . . . 613.3.3 Nachweis von Authentizität . . . . . . . . . . . . . . . . . . . . . . . . 61

4 Grammatikbasierte Zertifikate 634.1 Darstellungsformen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

4.1.1 Textuelle Darstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634.1.2 Strukturierte Darstellung . . . . . . . . . . . . . . . . . . . . . . . . . . 64

4.2 Zusicherungen als Textbausteine . . . . . . . . . . . . . . . . . . . . . . . . . . 664.2.1 Formerfordernis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664.2.2 Vorgabe von Textbausteinen . . . . . . . . . . . . . . . . . . . . . . . . 664.2.3 Variable Bestandteile . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

4.3 Nutzung kontextfreier Grammatiken . . . . . . . . . . . . . . . . . . . . . . . . 694.3.1 Prinzip der kontextfreien Grammatik . . . . . . . . . . . . . . . . . . . 704.3.2 Beispiel einer Grammatik . . . . . . . . . . . . . . . . . . . . . . . . . 714.3.3 Das Wortproblem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724.3.4 Syntaxbaum als strukturierte Darstellung . . . . . . . . . . . . . . . . . 744.3.5 Optimierung durch abstrakte Syntaxbäume . . . . . . . . . . . . . . . . 744.3.6 Rückgewinnung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

4.4 Entwurf grammatikbasierter Zertifikate . . . . . . . . . . . . . . . . . . . . . . 774.4.1 Aufbau grammatikbasierter Zertifikate . . . . . . . . . . . . . . . . . . . 774.4.2 Aktualität der Zusicherung . . . . . . . . . . . . . . . . . . . . . . . . . 794.4.3 Prüfung von Formerfüllung . . . . . . . . . . . . . . . . . . . . . . . . 804.4.4 Signaturvarianten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

4.5 Gesamtarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 834.6 Festlegung von Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

4.6.1 Beschränkung des Primärtextes . . . . . . . . . . . . . . . . . . . . . . 864.6.2 Beschränkung der Grammatik . . . . . . . . . . . . . . . . . . . . . . . 864.6.3 Beschränkung der strukturierten Daten . . . . . . . . . . . . . . . . . . 87

4.7 Delegation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 914.7.1 Begriffe der Delegation . . . . . . . . . . . . . . . . . . . . . . . . . . . 914.7.2 Delegationsvorgang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 924.7.3 Delegationszertifikat . . . . . . . . . . . . . . . . . . . . . . . . . . . . 934.7.4 Delegationsprüfung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

4.8 Grammatikverteilung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 954.8.1 Vertraulichkeit von Grammatiken . . . . . . . . . . . . . . . . . . . . . 954.8.2 Daten- und Funktionsmodell des Grammatikservers . . . . . . . . . . . . 964.8.3 Sicherheitseigenschaften des Grammatikservers . . . . . . . . . . . . . . 98

5 Implementierung und formale Bewertung 995.1 Realisierung grammatikbasierter Zertifikate . . . . . . . . . . . . . . . . . . . . 99

5.1.1 ANTLR-Parser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1005.1.2 Syntax für Grammatiken . . . . . . . . . . . . . . . . . . . . . . . . . . 1005.1.3 Parser-Erzeugung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

iv INHALTSVERZEICHNIS

5.1.4 Erstellung von GC-Grammatiken . . . . . . . . . . . . . . . . . . . . . 1055.1.5 Erstellung von Zusicherungen . . . . . . . . . . . . . . . . . . . . . . . 1075.1.6 Zertifikatskodierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1085.1.7 Anwendungsbewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

5.2 Semantik der grammatikbasierten Zertifikate . . . . . . . . . . . . . . . . . . . . 1175.2.1 Axiome zur Interpretation . . . . . . . . . . . . . . . . . . . . . . . . . 1175.2.2 Kompetenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1185.2.3 Korrektheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

5.3 Vergleich der Signaturverfahren . . . . . . . . . . . . . . . . . . . . . . . . . . 1195.3.1 Primärtext mit Primärsignatur (p-p) . . . . . . . . . . . . . . . . . . . . 1195.3.2 Sekundärdaten mit Sekundärsignatur (s-s) . . . . . . . . . . . . . . . . . 1215.3.3 Sekundärdaten mit Primärsignatur (s-p) . . . . . . . . . . . . . . . . . . 1225.3.4 Diskussion der Aussagekraft . . . . . . . . . . . . . . . . . . . . . . . . 124

5.4 Grammatikverteildienst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1255.4.1 Algorithmen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1255.4.2 Protokollablauf und Prüfschritte . . . . . . . . . . . . . . . . . . . . . . 1255.4.3 Sicherheitseigenschaften der Grammatikverteilung . . . . . . . . . . . . 1285.4.4 Analyse und Erweiterung . . . . . . . . . . . . . . . . . . . . . . . . . . 130

5.5 Beschränkung und Delegation . . . . . . . . . . . . . . . . . . . . . . . . . . . 1325.5.1 Delegationszertifikat . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1325.5.2 Beschränkungsarten . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1345.5.3 Skalierung durch Module . . . . . . . . . . . . . . . . . . . . . . . . . . 1355.5.4 Speicherung und Prüfung von Beschränkungen . . . . . . . . . . . . . . 1365.5.5 Formale Beschreibung der Delegation . . . . . . . . . . . . . . . . . . . 1385.5.6 Prüfablauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1395.5.7 Eigenschaften der Delegation . . . . . . . . . . . . . . . . . . . . . . . 142

6 Zusammenfassung 1436.1 Erreichte Ziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1436.2 Grenzen des Verfahrens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1446.3 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

Anhang

A Übersicht über SVO-Logik 147A.1 Sprachelemente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147A.2 Axiome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148A.3 Ergänzungen für grammatikbasierte Zertifikate . . . . . . . . . . . . . . . . 150

B Anwendungsbeispiele für formale Analysemethoden 151B.1 SVO: Prüfung signierter Daten mit PKI-Diensten . . . . . . . . . . . . . . . 151B.2 Proverif: Anwendungsbeispiel PKI-Dienste . . . . . . . . . . . . . . . . . . . 156

INHALTSVERZEICHNIS v

C Verwendete Grammatiken 161C.1 Meta-Grammatik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161C.2 XML-Schema für grammatikbasierte Zertifikate . . . . . . . . . . . . . . . . 163C.3 Grammatik für Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . 165C.4 Grammatik für Delegationszusicherungen . . . . . . . . . . . . . . . . . . . 166

D Erstellung von Grammatiken 169D.1 Beispiel für Top-Down-Verfahren . . . . . . . . . . . . . . . . . . . . . . . . 169D.2 Definitionen der vim-Makros für Umformungen . . . . . . . . . . . . . . . . 171

E Beispiel eines XML-kodierten grammatikbasierten Zertifikats 173

F Modellierung in Proverif 175

Literaturverzeichnis 183

vi INHALTSVERZEICHNIS

Kurzfassung

In dieser Arbeit wird ein neues Verfahren zur Erstellung von signierten Zusicherungen in Formsog. grammatikbasierter Zertifikate (Grammar-based Certificates, GC) vorgestellt und bewertet.

Der dabei betrachtete Anwendungsfall ist die räumlich und zeitlich verteilte Ausführung vonSicherheitsauditierungen von IT-Infrastrukturen. Dabei wird entsprechend eines vorgegebenenPrüfplans eine große Zahl von Informationen zum Zustand der IT-Systeme einschließlich derunterstützenden Infrastruktur und der angewendeten Prozesse erhoben und zur Auswertung ma-nipulationssicher übermittelt. Die Prüfergebnisse werden zusammengeführt und – im Idealfallautomatisiert – bewertet. Die angewendeten Bewertungskriterien können dabei Prüfvorschriftenwie der Grundschutz des Bundesamtes für Sicherheit in der Informationstechnik (BSI), unterneh-mensweite Sicherheitsrichtlinien und systemspezifische Festlegungen eines Sollzustandes sein.

Die Aufgabe der GC und der zugehörigen Mechanismen ist die Bereitstellung von geeignetenDatenformaten und Verarbeitungsschritten, um eine sichere, verbindliche Übermittlung und Prü-fung der im Rahmen der Auditierung erhobenen Informationen zu ermöglichen. Sie müssendabei verschiedenen Anforderungen des Anwendungsfeldes gerecht werden. Zunächst müssendie Ausdrucksmöglichkeiten der GC ausreichend flexibel sein, um die Vielzahl der benötigtenZusicherungen in unterschiedlichsten Umgebungen unterstützen zu können. Daneben müssengemachte Zusicherungen eine hohe Verbindlichkeit aufweisen, da auf Basis von Auditierungser-gebnissen teilweise sicherheitsrelevante Entscheidungen getroffen werden.

Daneben gibt es zwei weitere – scheinbar widersprüchliche – Anforderungen. Einerseits sollenzur Übermittlung der Auditierungsergebnisse Datenformate verwendet werden, die eine einfacheautomatische Auswertung ermöglichen, andererseits sollte der Ersteller einer signierten Zusiche-rung auch ohne Kenntnis der Kodierungsart die Bedeutung der signierten Daten kennen, um dieVerantwortung für die gemachten Aussagen übernehmen zu können. Dazu sollte die unterschrie-bene Zusicherung möglichst verständlich und im Idealfall in natürlicher Sprache vorliegen.

Die GC erfüllen diese Anforderungen, indem für natürlichsprachliche Zusicherungen, die einemformalen Aufbau, z. B. entsprechend der Vorgaben des BSI-Grundschutzes, genügen, kontext-freie Grammatiken definiert werden. Die Grammatiken ermöglichen, eine Zusicherung in natür-lichsprachlicher Darstellung eineindeutig in einen abstrakten Syntaxbaum zu überführen, der alsGC kodiert, signiert und automatisch verarbeitet werden kann.

vii

viii Kurzfassung

Ein solches Zertifikat enthält neben dem in XML kodierten abstrakten Syntaxbaum insbesondereeine Referenz auf die verwendete Grammatik in Form eines Hashwertes sowie weitere zertifikats-typische Daten. Der abstrakte Syntaxbaum wird dabei so optimiert, dass zwar redundante, in derGrammatik enthaltene Elemente entfernt werden, jedoch nur so, dass mit Hilfe der Grammatikaus dem Zertifikat der ursprüngliche natürlichsprachliche Text der Zusicherung zurückgewonnenwerden kann.

Diese Kodierung der Zusicherungen bietet neben der Automatisierbarkeit zwei weitere Vorteile.Zum einen lässt sich die zu übermittelnde Datenmenge bei Zusicherungen mit langen, statischenTextpassagen deutlich reduzieren. Zum anderen kann durch geeignete Wahl der Nicht-Terminal-Bezeichner und der Produktionsregeln der Grammatik die Namensgebung der XML-Strukturendurch Begriffe des Anwendungsfalles so verständlich ausgeführt werden, dass die Parametrisie-rung einer automatischen Verarbeitung anwenderfreundlich gestaltet werden kann.

Als weitere Anforderung an die GC wird in dieser Arbeit die Möglichkeit zur Delegation derBerechtigung, Zusicherungen ausstellen zu dürfen, betrachtet. Aufbauend auf dem Grundme-chanismus der GC wurde ein Verfahren entwickelt, das zur Beschreibung von Anforderungen anZusicherungen und zur Festlegung von Beschränkungen der Rechte im Rahmen einer mehrstu-figen Delegation dient. Das Verfahren wird mit Hilfe einfacher Pfadangaben realisiert, die nachdem XPath-Standard aus den Namen der in den abstrakten Syntaxbäumen verwendeten Knotengebildet werden.

Da für die Bearbeitungsschritte Kodierung und Rückgewinnung die Kenntnis der jeweils verwen-deten Grammatik notwendig ist und die Grammatiken teilweise selbst vertraulich sein können,wurde ein Grammatikverteildienst konzipiert, der es ermöglicht, Grammatiken ggf. verschlüsseltabrufbar zu halten ohne selbst vertrauenswürdig im Hinblick auf die Vertraulichkeit der Gram-matiken sein zu müssen. Dabei garantiert der Dienst unter Verwendung kryptographischer Au-thentisierung eine Trennung der administrativen Zugriffe verschiedener Anwender.

Mit den drei vorgestellten Mechanismen lässt sich die gesamte Kette der Aufgaben bei derDurchführung einer Auditierung unterstützen. Ausgehend von der Festlegung von möglichen Zu-sicherungstexten durch die Grammatiken können die spezifischen Anforderungen z. B. in Formvon Sicherheitsrichtlinien und die zu untersuchenden Systeme spezifiziert werden. Es könnenim Zusammenspiel mit einer Public Key Infrastruktur die notwendigen Berechtigungen zur Er-stellung von Zusicherungen erteilt und die benötigten Grammatiken sicher verteilt werden. Dieangeforderten Zusicherungen können so erstellt werden, dass sie für alle Beteiligten verbindlichin natürlichsprachlicher Form anzeigbar sind und verlustfrei als strukturierte Daten im XML-Format übertragen werden können. Schließlich lassen sich die Authentizität, die vorliegendeKompetenzzusicherung und die Erfüllung der anfangs definierten Anforderungen automatisiertprüfen.

Das Verfahren wurde prototypisch implementiert. Die Implementierung umfasst die Spezifikati-on einer Meta-Grammatik zur Erstellung einer anwendungsspezifischen Grammatik (Grammar-based Certificate Grammar, GCG), ein einfaches Verfahren, um aus Beispieltexten einer Zusi-cherung eine passende Grammatik für den jeweiligen Prüfbereich abzuleiten, und Generatoren,die eine GCG in Grammatiken für den existierenden ANTLR-Parser-Generator übersetzen.

Kurzfassung ix

Zu jeder Grammatik wird ein Parser-Paar erzeugt. Der erste Parser gewinnt aus dem natürlich-sprachlichen Text der Zusicherung den abstrakten Syntaxbaum, der in ein Zertifikat aufgenom-men wird. Der zweite Parser ist ein sog. Baumparser, der den im Zertifikat enthaltenen optimier-ten Syntaxbaum wieder in die ursprüngliche Zusicherung zurück wandeln kann. Ebenso kön-nen automatisiert validierende Editoren bereitgestellt werden, die durch Vorgaben vordefinierterTextbausteine und kontinuierliche Syntaxprüfung die Eingabe grammatikkonformer natürlich-sprachlicher Zusicherungen unterstützen.

Der Grammatikverteildienst wurde als Web-Dienst mit dahinter liegender Datenbank implemen-tiert. Es wurde ein dazu passendes Client-Programm als Kommandozeilenwerkzeug realisiert.

Durch die Implementierung konnte die Funktionsfähigkeit der Mechanismen und die Praktika-bilität des Ansatzes gezeigt werden. Aus der Implementierung konnten darüber hinaus Erkennt-nisse über die Grenzen der Einsatzmöglichkeiten des Verfahrens abgeleitet werden.

Die grammatikbasierten Zertifikate und der Delegationsmechanismus beruhen auf einer Reihevon Interpretationsvereinbarungen, die festlegen, wie Datenstrukturen umgewandelt und ausge-wertet werden müssen. Da es sich dabei um sicherheitskritische Informationen handelt, ist esvon entscheidender Bedeutung, dass diese Interpretationen präzise durch eine formale Seman-tik festgelegt werden. Es muss außerdem gezeigt werden, dass bei korrekter Anwendung dieserInterpretation auch in Gegenwart eines Angreifers korrekte Schlüsse gezogen werden können.

Daher wurden die neu entworfenen Mechanismen zur Zertifizierung und Delegation einer forma-len Analyse auf Basis der SVO-Logik, einer sog. Belief-Logik von Syverson und van Oorshoot,unterzogen. Hierzu wurde die Logik so erweitert, dass sie allgemein die Zusicherung von Aktua-lität von Nachrichten beschreiben kann. Zur Modellierung und Analyse der neuen Mechanismenwurden neue spezifische Schlussregeln eingeführt, die die Verarbeitung und Interpretation vongrammatikbasierten Zertifikaten beschreiben.

Mit diesen Regeln wurde für die GC eine eindeutige Semantik in der Terminologie der SVO-Logik festgeschrieben. Dadurch war es möglich, auf formale Weise zu zeigen, welche Nachrich-ten und welches initiale Wissen notwendig und hinreichend sind, damit ein Zertifikatsempfängerdurch Signaturprüfungen, Kompetenzzusicherungen und die eingeführten Interpretationsregelneine Zusicherung als Tatsache akzeptieren kann.

Durch Einführung der grammatikbasierten Zertifikate wurde ein Werkzeug mit formalem Rah-men geschaffen, das die Durchführung von Sicherheitsauditierungen umfassend unterstützenkann. Die grammatikbasierten Zertifikate erweitern darüber hinaus die bestehenden Zertifizie-rungs- und Autorisierungsmethoden um einen neuen flexiblen Mechanismus, der den techni-schen Zertifizierungsbegriff verallgemeinert und damit neue Anwendungsfelder erschließt.

x Kurzfassung

Abstract

Grammar-based Certificates Applied to the Example of Security Audits ofDistributed IT Infrastructures

This work presents and evaluates a new method to issue signed assertions, the so-called grammar-based certificates (GC).

The underlying field of application is the process of security audits of IT infrastructures, perfor-med in a timely and spatially distributed manner. In these audits much information is collectedabout the status of IT systems including their supporting infrastructure and the applied processes.Transmitted under integrity protection the audit results are brought together for a —preferablyautomated— evaluation. The applied evaluation criteria may stem from different sources likethe IT-Grundschutz of the Bundesamt für Sicherheit in der Informationstechnik (BSI), corporatesecurity policies, and target state definitions for specific systems.

The GC and the related mechanisms provide appropriate data formats and data processing func-tionality to achieve a secure, binding transmission and evaluation of the audit data. The appli-cation field implies several requirements on the provided new functionality. The expressivenessof GC must be flexible enough to support the multitude of assertion types for different environ-ments. For the given assertions a high level of commitment or even liability is essential sincesecurity relevant decisions are made based on the audit results.

There are two more —apparently contradictory— requirements. On the one hand the data formatsused for transmission should enable an automated evaluation. On the other hand the issuer of asigned assertion should know the exact meaning of the transmitted data without knowledge aboutthe type of coding in order to take responsibility for his statements. Therefore, a given assertionshould be as intelligible as possible, preferably it should be natural language.

The GC satisfy these requirements by defining context free grammars for assertions in naturallanguage that comply with an arbitrary but fixed formal structure which corresponds to speci-fications like BSI-Grundschutz. The grammars can be used to transform an assertion in naturallanguage in a bijective way to an abstract syntax tree. This syntax tree can be coded into a GC,signed and processed automatically.

xi

xii Abstract

In addition to the abstract syntax tree coded in XML, a GC contains a hash value of the appliedgrammar as reference and further information specific to certificates. The abstract syntax tree isoptimized by omitting all elements that are redundant with respect to the grammar, maintainingthe possibility to recover the original text in natural language.

Besides the automated processing, this coding of assertions offers two additional benefits. First-ly, the amount of transmitted data can possibly be reduced considerably for assertions with longstatic phrases. Secondly, with a suitable selection of the grammar’s non-terminal labels and pro-duction rules the naming of the XML structures can use intelligible terms of the applicationcase. Thus, the parameterization of the automated processing of assertions can be designed in auser-friendly way.

A further requirement on the GC addressed by this work is the possibility to delegate the rightto issue assertions. Based on the GC mechanism a method has been developed that makes useof simple path expressions. These expressions are based on the XPath standard and can be buildwith the names of the nodes of the abstract syntax tree. They can be used to declare requirementson assertions and restrictions when the right to make assertions is delegated in chains.

As the knowledge of the underlying grammar is essential for coding and recovery and as gram-mars might be confidential by themselves, a grammar distribution service has been designed.This service can handle encrypted grammars and can make them available without the neces-sity to be trustworthy regarding the confidentiality of the grammars. Moreover, the service canguarantee a segregation of users based on cryptographic authentication.

The three mechanisms presented can support the whole chain of tasks of an audit. Starting withlaying down the possible wordings for an assertion type by defining a suitable grammar, specificrequirements of security policies and the targets for an audit can be expressed. In combinationwith a public key infrastructure all necessary rights to issue assertions can be granted or passedon. The used grammars can be distributed securely. The requested assertions can be created withthe possibility to be presented in a binding version in natural language to all participants. Theassertion can be transmitted loss-free as structured data coded in XML. Finally, the authenticity,the presented assertions of jurisdiction and the compliance with the initial requirements can beevaluated automatically.

The process has been implemented as a prototype. The implementation comprises the specifi-cation of a meta-grammar for the design of an application specific grammar (grammar-basedcertificate grammar, GCG), a simple method for transforming example assertions into a suitablegrammar for the underlying application field, and generators that translate a GCG into grammarsfor the existing ANTLR parser generator.

For every grammar a pair of parsers is generated. The first parser builds the certificate’s abstractsyntax tree from the natural language text. The second parser is a so-called tree parser that re-covers the original assertion from the optimized syntax tree. Moreover, validation editors can beprovided, that support the input of grammar-compliant natural language assertions by offeringpredefined text blocks and a continuous syntax check.

Abstract xiii

The grammar distribution service was designed as a web service using a separated database in theback-end network. A suitable client program has been designed that realizes the service accesson the command line.

The implementation confirmed the operational capability of the mechanisms and the applicabilityof the approach. Additionally, the implementation provides insight into the limitations of theprocess concerning it’s possible use cases.

The grammar-based certificates and the delegation mechanism are founded on a set of agreementson the interpretation of the data, that lay down the way how data structures must be transformedand how they shall be evaluated. Since this information is security critical it is of decisive im-portance that these interpretations are given a precise formal semantics. It has to be shown thateven in the presence of an attacker the correct conclusions can be drawn from the grammar-basedcertificates.

Therefore, the new mechanisms for certification and delegation were formally analyzed by meansof the SVO logic, a belief logic by Syverson and van Oorshoot. To suit the problem, this logichas been extended, thus it can capture the assertion of timeliness of a message in a general way.New specific deduction rules were established that model and analyze the processing and theinterpretation of grammar-based certificates.

These rules set up a unique semantics in terms of the SVO logic. Thus, it was possible to showformally which messages and initial knowledge is necessary and sufficient that a certificate’srecipient can derive enough knowledge by means of signature checks, jurisdiction statementsand the provided interpretation rules to accept an assertion as a fact.

By the introduction of the grammar-based certificates a tool with a formal framework has beencreated that can support security audits in a comprehensive way. Moreover, the grammar-basedcertificates extend the existing methods for certification and authorization by a new flexible me-chanism that generalizes the technical certification term. Thus, grammar-based certificates helpto explore new application fields.

xiv Abstract

Abbildungsverzeichnis

1.1 Prüfhäufigkeit für Annahmen und Vorgaben . . . . . . . . . . . . . . . . . . . . 51.2 Allgemeines Prüfverfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1 Übersicht über verwendete kryptographische Grundbegriffe . . . . . . . . . . . . 152.2 Zusammenhang zwischen Inhalt und Signatur . . . . . . . . . . . . . . . . . . . 152.3 Signaturerstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.4 Signaturprüfung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.5 Verteilung signierter Information . . . . . . . . . . . . . . . . . . . . . . . . . . 212.6 Beispiel einer Zertifikatshierarchie . . . . . . . . . . . . . . . . . . . . . . . . . 332.7 3-Phasen-Architektur von Kerberos . . . . . . . . . . . . . . . . . . . . . . . . 372.8 Qualitativer Vergleich der Zielerfüllung für Automatisierbarkeit und Flexibilität . 44

3.1 Direkte Prozesskommunikation . . . . . . . . . . . . . . . . . . . . . . . . . . . 543.2 Beispiel kommunizierender Prozesse . . . . . . . . . . . . . . . . . . . . . . . . 56

4.1 Strukturierte Darstellung des Informationsgehalts einer Zusicherung . . . . . . . 654.2 Beispiel eines einfachen Syntaxbaumes . . . . . . . . . . . . . . . . . . . . . . 734.3 Konkreter Syntaxbaum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 744.4 Abstrakter Syntaxbaum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 754.5 Unterschiedlich starke Kontextbindung . . . . . . . . . . . . . . . . . . . . . . . 814.6 Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

5.1 Automatisierte Editor- und Parsergenerierung . . . . . . . . . . . . . . . . . . . 1005.2 XText-gesteuerte Eingabe einer Zusicherung . . . . . . . . . . . . . . . . . . . . 1095.3 Eingabemaske für Prüfergebnis . . . . . . . . . . . . . . . . . . . . . . . . . . . 1095.4 Verarbeitungsschritte bei der Erstellung grammatikbasierter Zertifikate . . . . . . 1105.5 Graphische Darstellung für uneindeutige Grammatik . . . . . . . . . . . . . . . 1155.6 Token-Anforderung und Einstellen einer verschlüsselten Grammatik . . . . . . . 1265.7 Löschen einer Grammatik mit Delegation . . . . . . . . . . . . . . . . . . . . . 1275.8 erweiterte Token-Anforderung . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

xv

xvi ABBILDUNGSVERZEICHNIS

Tabellenverzeichnis

2.1 Aufbau eines Schlüsselzertifikates nach X.509 . . . . . . . . . . . . . . . . . . . 30

3.1 Formelausdrücke der SVO-Logik . . . . . . . . . . . . . . . . . . . . . . . . . . 473.2 Schreibweisen des angewandten Pi-Kalküls . . . . . . . . . . . . . . . . . . . . 533.3 Äquivalenzen des Pi-Kalküls . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553.4 Gegenüberstellung der Schreibweisen von Pi-Kalkül und Proverif . . . . . . . . 59

4.1 Kontextfreie Grammatik für Zusicherungen nach Grundschutz-Maßnahme M 5.72 724.2 Grundstruktur X.509-Zertifikate und GC . . . . . . . . . . . . . . . . . . . . . . 784.3 Felder X.509-Zertifikate und GC . . . . . . . . . . . . . . . . . . . . . . . . . . 784.4 Inhalt von Delegationszertifikaten im Vergleich zu GC . . . . . . . . . . . . . . 94

5.1 Exemplarischer Vergleich der Kodierungsverfahren hinsichtlich der Datenmenge 1125.2 Ergebnisse der Proverif-Analyse des Grammatikverteildienstes . . . . . . . . . . 133

xvii

xviii TABELLENVERZEICHNIS

Symbol- und Abkürzungsverzeichnis

Symbole

⊥ ungültig, leer

¬ Negation

� Semantische Implikation

` Herleitungsbeziehung

∨ Disjunktion

∧ Konjunktion

→ Implikation der SVO-Logik

⇒ allgemeine Implikation

7→ Übermittlung von Nachrichten

; Korrespondenz zwischen Ereignissen

E Ersteller einer Signatur

F logisch falsch

Φ Menge aller Formeln in SVO-Analysen

ϕ beliebige Formel aus Φ

ΦG Kodierungsfunktion auf Basis der Grammatik G

Φ−1G Dekodierungsfunktion auf Basis der Grammatik G

H Bezeichner für Hash-Funktion

I Inhalt eines zu signierenden Dokumentes

K̃ korrespondierender Schlüssel

xix

xx Symbol- und Abkürzungsverzeichnis

K Bezeichner für kryptographische Schlüssel

k Bezeichner für symmetrische und öffentliche Schlüssel

K−1 privater Teil eines asymmetrischen Schlüsselpaares

M Menge aller Nachrichten (messages) in SVO-Analysen

P Prinzipal P

PKδ Öffentlicher Schlüssel für Schlüsselaushandlungen

PKϕ Öffentlicher Verschlüsselungsschlüssel

PKσ Öffentlicher Signaturschlüssel

ψ beliebige Formel aus Φ

Q Prinzipal Q

ρ Prüffunktion für strukturierte Daten

ρg Prüffunktion für Grammatikregeln

ρp Prüffunktion für Primärtexte

r Zusammengesetzte Beschränkung

Σ Menge der Funktionen und Konstanten des Pi-Kalküls

Σ Vorrat aller erlaubter Zeichen für Textbausteine

S Signatur

Θ Menge primitiver Terme der SVO-Logik

T logisch wahr

wmax Anzahl maximal erlaubter weiterer Delegationsstufen

X Menge der zulässigen XPath-Ausdrücke

X Bezeichner für Daten

x XPath-Ausdruck

Y Bezeichner für Daten

Akronyme

AIDE Advanced Intrusion Detection Environment

ANTLR Another Tool for Language Recognition

Symbol- und Abkürzungsverzeichnis xxi

AS authentication service

ASN.1 Abstract Syntax Notation Number 1

AST abstract syntax tree

AWK Skript-Sprache von Aho, Weinberger und Kernighan

CA Certification Authority

CCS Calculus of Communicating Systems

CMS Cryptographic Message Syntax

CN Common Name

CRL Certificate Revocation List

CSP Communicating Sequential Processes

DAC Discretionary Access Control

DER Distinguished Encoding Rules

DSA Digital Signature Algorithm

DSS Digital Signature Standard

EAL Evaluation Assurance Level

EBNF Extended Backus Naur Form

ECC Elliptic Curve Cryptography

ECDSA Elliptic Curve Digital Signature Algorithm

ETSI European Telecommunications Standards Institute

FDR Failures-Divergence Refinement

GC Grammar-based Certificate

GCG Grammar-based Certificate Grammar

GCR GC-spezifische Prüffunktion für Restriktionen

GCV Prädikat für GC-spezifische Verifikation

GDC Grammar-based Delegation Certificate

GPG GNU Privacy Guard

GT Prädikat für Greater-than-Relation

xxii Symbol- und Abkürzungsverzeichnis

HTTP HyperText Transfer Protocol

IETF Internet Engineering Task Force

IP Internet Protocol

IT Informationstechnik

LISP LISt Processing Language

LOTOS Language of Temporal Ordering Specification

LSAT Linux Security Audit Tool

MAC Mandatory Access Control

MIT Massachusetts Institute of Technology

MP Modus Ponens

Nec necessitation

NIST National Institute of Standards and Technology

O Organisation

OASIS Organization for the Advancement of Structured Information Standards

OCSP Online Certificate Status Protocol

OID Object ID

OpenVAS Open Vulnerability Assessment System

PDF Portable Document Format

PDP Policy Decision Point

PERMIS PrivilEge and Role Management Infrastructure Standards validation

PGP Pretty Good Privacy

PK Public Key

PKCS#1 Public Key Cryptography Standard No. 1

PKCS#7 Public Key Cryptography Standard No. 7

PKI Public Key Infrastructure

PMI Privilege Management Infrastructure

PSS Probabilistic Signature Scheme

Symbol- und Abkürzungsverzeichnis xxiii

RBAC Role Based Access Control

RFC Request for Comments

RIPEMD-160 RACE Integrity Primitives Evaluation Message Digest

RSA Signaturschema nach Rivest, Shamir und Adleman

RSASSA RSA Signature Scheme with Appendix

S/MIME Secure / Multipurpose Internet Mail Extensions

SAML Security Assertion Markup Language

SDSI Simple Distributed Security Infrastructure

SE1 1. Schritt zur Signaturerstellung

SE2 2. Schritt zur Signaturerstellung

SecPAL Security Policy Assertion Language

SHA-256 Secure Hash Algorithm Version 256

SOAP Simple Object Access Protocol

SPKI Simple Public Key Infrastructure

SSL Secure Socket Layer

SSO Single Sign On

SV Signaturvalidierung

SVO Belief-Logik nach Syverson und van Oorshoot

TGS ticket granting service

TGT Ticket Granting Ticket

URI Unified Resource Identifier

URL Unified Resource Locator

USB Universal Serial Bus

UTC Coordinated Universal Time

W3C World Wide Web Consortium

XACML eXtensible Access Control Markup Language

XAdES XML Advanced Electronic Signatures

XML eXtensible Markup Language

ZAS zentraler Auditierungsserver

xxiv Symbol- und Abkürzungsverzeichnis

1 Motivation und Zielsetzung

Informationsverarbeitende Systeme durchziehen heute alle Lebensbereiche von Wirtschaft, Poli-tik, Medizin, Verwaltung bis hin in nahezu alle privaten Haushalte. Entsprechend wird auf diesenSystemen eine enorme Menge von Daten aller Art verarbeitet und gespeichert. Aus diesem Grundist die Sicherheit dieser Systeme vor missbräuchlicher Nutzung, Ausspähung und Manipulationeine Forderung, deren Erfüllung für Firmen, Behörden und Privatpersonen von sehr hoher Be-deutung ist.

In vielen der genannten Bereiche werden die Betreiber dieser Systeme sowohl durch ihre eigenenInteressen als auch durch den Gesetzgeber gezwungen, ihre Systeme gegen drohende Angriffevon außen und innen zu sichern.

Die datenverarbeitenden Systeme müssen sowohl auf der physikalischen Ebene vor unberech-tigtem Zugriff als auch auf der logischen Ebene, d. h. an den Schnittstellen zum Austausch vonKommunikationsdaten, vor Belauschen und Manipulation ihrer Daten geschützt werden. Speziellbei großen Systemen, die sowohl logisch als auch räumlich verteilt sind, spielen dabei neben ei-nem Systemdesign, das Sicherheitsanforderungen berücksichtigt, vor allem die Parametrisierungund organisatorische Randbedingungen wie z. B. Rollenkonzepte eine erhebliche Rolle.

Für Standardanwendungen wie z. B. Web-basierte Client-Server-Dienste, aber auch für spezielleAnwendungsfälle, wird oftmals anhand von Kriterien- und Maßnahmenkatalogen die Korrektheitder Parametrisierung der Systeme geprüft. Neben diesen Katalogen sind häufig auch unterneh-mensspezifische Sicherheitsrichtlinien, Arbeits- und Verfahrensanweisungen und einzelvertrag-lich geregelte Anforderungen von Kunden zu berücksichtigen.

Eine umfassende Prüfung einer Infrastruktur umfasst teilweise hunderte von Details. Die Fest-stellung der dafür benötigten Sachverhalte erfolgt oftmals nicht nur durch eine Person, sonderndurch Befragung einer ganzen Reihe von Personen, die jeweils für Teilbereiche des zu sichern-den Systems verantwortlich sind. Diese haben die einzelnen Maßnahmen umzusetzen und fürderen Korrektheit zu garantieren. Hierzu sichern die Befragten beispielsweise die vollständigeDurchführung von Schutzmaßnahmen oder die Korrektheit einer sicherheitsrelevanten Parame-trisierung zu.

Es ist die Aufgabe desjenigen, der eine erstmalige Sicherheitsanalyse oder wiederholte Auditie-rung eines großen Systems durchführt, die Zusicherungen aller Beteiligten zusammenzuführenund zu prüfen, ob damit die Gesamtheit der sicherheitsrelevanten Vorgaben erfüllt ist.

1

2 Kapitel 1. Motivation und Zielsetzung

Die Einholung der Zusicherungen kann durch verschiedene Methoden erfolgen. Neben demklassischen Interview mit ggf. gegengezeichnetem Protokoll besteht auch die Möglichkeit zurNutzung elektronischer Kommunikation. Werden Zusicherungen jedoch über diesen Weg ausge-tauscht, müssen diese sowohl in Hinblick auf Authentizität und Integrität und u. U. auch bezüg-lich ihrer Vertraulichkeit geschützt werden.

Die vorliegende Arbeit stellt einen Ansatz vor, bei dem Zusicherungen in elektronischer Formunter Verwendung von neu eingeführten speziellen Zertifikaten – den sog. grammatikbasiertenZertifikaten – ausgetauscht werden.

Im Kern bieten die grammatikbasierten Zertifikate die Möglichkeit, Zusicherungen sowohl inverständlicher Darstellung als auch in einer strukturierten Form für die automatische Weiterver-arbeitung zu kodieren, sowie die Möglichkeit, beide Formen eindeutig in die jeweils andere Formzu überführen.

In diesem Kapitel wird zunächst ein Überblick über die Abläufe und Zusammenhänge bei Si-cherheitsauditierungen und -evaluierungen gegeben. Im Anschluss werden Anforderungen anelektronische Zusicherungen aufgestellt, die zur Unterstützung eines Auditierungsprozesses er-füllt werden sollen.

1.1 Sicherheitsanalysen

Das Ziel einer Sicherheitsanalyse ist es, für ein zu untersuchendes System zu bestimmen, obes geeignet ist, eines oder mehrere vorgegebene Schutzziele gegen einen Angreifer einer be-stimmten Stärke zu schützen. Es gibt unterschiedliche Vorgehensweisen bei der Durchführungeiner solchen Analyse. Ein bekanntes Verfahren ist die Vorgehensweise nach IT-Grundschutz desBundesamtes für Sicherheit in der Informationstechnik (BSI) [Bun08b]. Dieses Verfahren wirdi. d. R. auf IT-Infrastrukturen und ihr organisatorisches und physikalisches Umfeld angewendet.

Daneben gibt es andere Verfahren, die für Sicherheitsanalysen bei einzelnen Protokollen [BAN89,Kem89], Diensten und Anwendungen [Gro03] oder ganzen Architekturen [Vin02] angewendetwerden.

Bei der Vorgehensweise nach IT-Grundschutz werden zunächst für das System eine Struktur-analyse und eine Schutzbedarfsfeststellung durchgeführt. Die Strukturanalyse erhebt die zu ei-ner zu prüfenden Infrastruktur gehörenden Komponenten. Ausgehend von den zu schützendenGeschäftsprozessen und den damit verbundenen Daten werden die beteiligten Komponenten er-mittelt. Dabei werden sowohl logische als auch physikalische Elemente bis hin zu den genutztenRäumen erfasst.

Die Schutzbedarfsfeststellung legt fest, für welche Systemelemente welche Schutzziele hinsicht-lich Vertraulichkeit, Integrität und Verfügbarkeit bestehen. Durch die Bedrohungsanalyse werdenSzenarien festgelegt, die eine Gefährdung für die identifizierten Schutzziele darstellen.

Aus den Ergebnissen dieser Analysen wird eine Liste von zu erfüllenden Systemeigenschaftenund Maßnahmen erstellt, mit denen die Bedrohungen ausgeschaltet oder zumindest minimiert

1.2 Auditierungen 3

werden können. Die nicht vollständig ausgeschlossenen Bedrohungen müssen in einer Risiko-analyse bewertet werden.

Als Unterstützung können Programme wie das Grundschutz-Tool des BSI eingesetzt werden[Bun08a]. Dieses Werkzeug ermöglicht die hierarchische Modellierung einer IT-Infrastrukturanhand eines Baustein-Kataloges. Den Elementen des Modells sind Fragen- und Maßnahmenka-taloge zugeordnet, die eine systematische Abarbeitung von sicherheitsrelevanten Aspekten derInfrastruktur ermöglichen. Der Datenbestand wird in Form einer Datenbank gehalten, die auchin Teilen ex- und importiert werden kann und somit die Erfassung der Informationen durch un-terschiedliche Anwender ermöglicht.

Um sicherzustellen, dass das entworfene System auch in der späteren Realisierung die Anforde-rungen erfüllt, wird in einer Umsetzungsprüfung die korrekte Ausführung und die Funktionsfä-higkeit der identifizierten Maßnahmen verifiziert.

Wird die Prüfung bestanden, so können je nach verwendetem Prüfkatalog verschiedene Sicher-heitszertifizierungen erteilt werden. Beispiele hierfür sind der Evaluation Assurance Level (EAL)gemäß Common Criteria [Com12], die Erklärung der Konformität mit bestimmten Anforderun-gen des BSI-Grundschutzkataloges [Bun11] oder die Erfüllung der ETSI-Norm der Anforderun-gen an die Zertifizierungsrichtlinien einer Zertifizierungsstelle (Certification Authority, CA) fürqualifizierte Zertifikate [Eur07].

1.2 Auditierungen

Um die Systemsicherheit auch nachhaltig garantieren zu können, müssen die notwendigen Prüf-schritte auch für wiederholte Prüfungen (Sicherheitsauditierungen) aufbereitet und z. B. in Li-stenform als sog. Prüfkataloge für die Verantwortlichen zur Verfügung gestellt werden.

Für eine kontinuierliche Sicherstellung eines Sollzustandes durch Audits ist es daher notwendig,die Prüflisten regelmäßig abzuarbeiten und die Prüfergebnisse aufzubereiten. Die Verantwortunghierfür liegt in der Regel beim Sicherheitsmanager eines Unternehmens, der die Audits anstoßenund die Ergebnisse aus den Fachbereichen entgegennehmen und bewerten muss.

Bei IT-Systemen mit speziellen Anwendungen gibt es neben den anwendungsspezifischen Si-cherheitsmaßnahmen, deren Notwendigkeit durch die Sicherheitsanalyse festgestellt wurde, aucheine große Anzahl von standardisierten Maßnahmen, die in Abhängigkeit von den eingesetztenBetriebssystemen und den darauf eingesetzten Diensten immer wieder angewendet werden kön-nen. Für diese Basisfunktionalitäten gibt es eine Reihe von standardisierten Schutzmechanismenund zugehörigen Prüfaufgaben.

Beispiele für Prüfaufgaben sind

q Die Vorgabe für die Maske der Standard-Dateirechte (umask) ist gemäß Sicherheitsrichtli-nie gesetzt.


q Die minimale Passwortlänge ist größer oder gleich acht Stellen.

q Die USB-Buchsen des Servers sind versiegelt.

q Die Notentriegelung einer Sicherheitstür führt zu einem Alarm.

q Für alle Änderungen an Firewall-Regeln liegen Änderungsanforderungen (Change Re-quests) vor.

Regelmäßig durchgeführte Audits müssen sowohl die standardisierten als auch die speziellenSchutzmechanismen abdecken.

Bei verteilt arbeitenden Produktivsystemen müssen Informationen über die Eigenschaften di-verser Rechnersysteme, Kommunikationsstrecken, physikalische Eigenschaften der Umgebungund die Qualität der Ausbildung und Verlässlichkeit des Bedienpersonals durch den Prüfer (oderEvaluator) eingeholt werden.

Die große Menge an Informationen bringt es mit sich, dass für die Auskünfte während derPlanungs-, Realisierungs- und Prüfungsphasen i. d. R. auch eine größere Zahl von Personen zuden jeweils ihnen übertragenen Verantwortungsbereichen befragt wird.

Zu diesem Personenkreis gehören im Wesentlichen Netzwerkadministratoren, Sicherheitsmana-ger, Datenschutzbeauftragte und Anwendungsadministratoren. Diese Informationsgeber müssenin Interviews oder schriftlichen Äußerungen zu den jeweils aus Sicherheitssicht relevanten Fra-gen (z. B. aus dem IT-Grundschutz) Stellung beziehen.

Neben diesen grundsätzlichen Eigenschaften sind zur Beschreibung eines Prüfbedarfs vor allemdie Häufigkeit der Prüfungen, die geforderte Dokumentation der Prüfergebnisse und das Mana-gement der Prüfergebnisse beim Abgleich mit den Vorgaben relevant. Diese Aspekte werden inden folgenden Abschnitten betrachtet.

1.2.1 Häufigkeit

In einer initialen Umsetzungsprüfung werden die beim Entwurf der Systemarchitektur und denSicherheitsanalysen getroffenen Annahmen, die abgeleiteten Maßnahmen und deren korrekteUmsetzung auditiert. Oftmals werden Umsetzungsprüfungen durch externe Prüfstellen ausge-führt, die das Ergebnis wiederum durch Ausstellung entsprechender Zertifizierungen öffentlichbelegen.

Bei den periodisch – teilweise im mehrjährigen Rhythmus – durchgeführten Wiederholungs-prüfungen werden auch die Grundkonzepte und -annahmen einem Review unterzogen und dieKorrektheit der abgeleiteten Schutzmaßnahmen hinterfragt. Abbildung 1.1 zeigt die Häufigkeitverschiedener Prüfungsarten periodischer und zufallsabhängiger Audits.

Für die ebenfalls durchzuführenden Auditierungen gibt es diverse zeitliche Schemata. Teilweisewerden nach einem engmaschigen periodischen Zeitplan sicherheitskritische Eigenschaften und

1.2 Auditierungen 5

Parametrisierungen der Infrastruktur auditiert. Dies ist z. B. bei der täglichen automatisiertenIntegritätsprüfung der Fall. Daneben werden aber auch periodische Prüfungen mit längeren Ab-ständen sowie unangekündigte oder anlassbezogene Prüfungen, die beiden letztgenannten ohnefestes Zeitschema, durchgeführt.

Entwurf undAufbau Betrieb

internes AuditTyp 1

periodischeUmsetzungsprüfung

internes AuditTyp 2

internes AuditTyp n

Abbildung 1.1: Prüfhäufigkeit für Annahmen und Vorgaben

Die häufigen Prüfungen sind notwendig, da i. A. ein System aus verteilten IT-Komponenten nichtunverändert bleibt, wie dies bei einer einmal ausgelieferten unveränderbaren Chipkarte der Fallist. Neben Software-Aktualisierungen werden Komponenten gegen leistungsfähigere Modelleausgetauscht, Dienste werden weiter entwickelt und in die Systemumgebung eingebracht. Durchdiese Arbeiten kann es zu – möglicherweise ungewollten – Veränderungen an den Systemenbzw. ihrer Parametrisierung kommen. Daneben kann nicht mit völliger Sicherheit ausgeschlos-sen werden, dass Dienste oder Infrastrukturkomponenten Schwachstellen aufweisen, über die eseinem Angreifer gelingen kann, Systemeigenschaften so zu verändern, dass die Schutzziele nichteingehalten werden können.

Inhalte periodischer Prüfungen sind beispielsweise die Sichtung der auf einem Serversystemangelegten Accounts für Mitarbeiter mit administrativem Zugriff, die Kontrolle der Einstellungenfür Passwortregeln, die tägliche Log-Analyse etc.

Neben den manuellen Prüfungen gibt es auch automatische Werkzeug-gestützte Auditierungen.Dabei kommen diverse Programme zum Einsatz. Beispiele für frei verfügbare Programmun-terstützung sind das Linux Security Audit Tool (LSAT) [Min08] oder das Open Vulnerabili-ty Assessment System (OpenVAS) [DAdB+11]; ein führendes kommerzielles Werkzeug ist derSchwachstellen-Scanner Nessus [Ten11]. Zur Überwachung der Integrität des Dateisystems ei-nes Servers kommt beispielsweise das Advanced Intrusion Detection Environment (AIDE) zumEinsatz [vH11].


Automatisierte Prüfungen können teilweise in sehr engem Zeitraster (z. B. stündlich) erfolgen.Demzufolge fällt eine große Anzahl von Ergebnissen an, die im Idealfall ebenfalls automatischweiterverarbeitet und bewertet werden.

1.2.2 Dokumentation

Prüfergebnisse werden häufig in Form von Listen mit Prüfschritt und Ergebnis oder auch durchfrei formulierte Texte dargestellt. Bei automatisierter Prüfung können die Ergebnisse noch kom-pakter sein. Beispielsweise erzeugt die Prüfung der Datei-Integrität mit AIDE bei Abwesenheitvon Abweichungen eine Meldungszeile### All files match AIDE database. Looks okay!Diese Log-Zeile kann dann ggf. durch ein Monitoring-System wie nagios noch in einen OK-Status eines sog. Probes umgesetzt werden.

Während bei Ausgaben von Prüfwerkzeugen teilweise eine automatische Verarbeitbarkeit ge-geben ist, wird dies bei Verwendung von freien Formulierungen (z. B. in einer E-Mail einesSystemadministrators an das Sicherheitsmanagement) i. d. R. nicht der Fall sein. Hier ist somitsehr oft die manuelle Auswertung und abschließende Bewertung notwendig.

Die Ergebnisse einer Auditierung oder Sicherheitsprüfung sind darüber hinaus selbst schützens-wert. Gelänge es einem Angreifer, die Meldungen über ein kompromittiertes System, welche andas Monitoringsystem gesendet werden, ebenfalls zu manipulieren, so würde die Sicherheit desSystems falsch bewertet.

Es ist daher wichtig, auch die Dokumentation von Prüfschritten in ihrer Integrität und Authenti-zität zu schützen. Dies erfolgt teilweise durch den Einsatz digitaler Signaturen (z.B. bei E-Mails),welche die Quelle und Korrektheit einer Nachricht für den Empfänger nachvollziehbar machen.

1.2.3 Vorgaben

Durch das Sicherheitskonzept, Betriebsführungshandbücher, Programmdokumentationen und An-forderungen an die Einsatzumgebung aus Produktevaluierungen ergibt sich ein Soll-Zustand fürdie IT-Infrastruktur. Bei einer Prüfung wird der Ist-Zustand erfasst, mit dem Soll-Zustand ver-glichen und einer Bewertung unterzogen. Dabei ist es grundsätzlich frei wählbar, wo die Ver-gleichsoperation und die Bewertung stattfindet.

Am Integritätsprüfprogramm AIDE lässt sich dieses Prinzip gut verdeutlichen. Nach einer fri-schen Systeminstallation oder nach einer autorisierten Veränderung an einem integritätsüber-wachten System wird der Zustand aller statischen Dateien (Hash-Werte des Inhalts, Zugriffs-rechte, Eigentümer, etc.) erfasst und in einer Referenzdatenbank abgelegt. Jede anschließendePrüfung ermittelt erneut den Ist-Zustand und vergleicht die gefundenen Eigenschaften mit derReferenzdatenbank. Es werden dann die Abweichungen zum Soll-Zustand an eine bewertendeStelle übermittelt.

1.2 Auditierungen 7

Bewertung

Soll-Daten

Prüfplan

Prüfumfang

IST

SOLL

EVG-Eigenschaften

DELTA

Speicherung

IST-Erhebung

SOLL-IST-Vergleich

Evaluationsgegenstand

Ergebnis

Abbildung 1.2: Allgemeines Prüfverfahren

Diese Vorgehensweise lässt sich auf beliebige manuelle Prüfungen durch Auditoren übertragen.In Abbildung 1.2 wird das Verfahren in allgemeiner Form gezeigt.

Wenn bei der Übermittlung von Informationen von einem Bereich zum anderen eine Übertra-gung der Daten über unsichere Kommunikationskanäle erfolgt, ist ein Schutz der Daten vor Ver-änderung und die Sicherstellung der Authentizität zwingend notwendig, da anderenfalls durchentsprechende Manipulation der Daten die Bewertung zu einem falschen Ergebnis gelangt.

Die Vorgaben bestehen somit aus einem Prüfplan, der die Prüfschritte und Prüfgegenstände fest-legt, sowie einer Vorgabe des Soll-Zustandes. Abweichungen vom Soll-Zustand werden bewertetund das Ergebnis mit anderen Prüfungen zusammengeführt. Gegebenenfalls werden aufgrund dergetroffenen Bewertungen auch unmittelbar Maßnahmen zur Wiederherstellung des Sollzustan-des abgeleitet.

Die einzelnen Schritte können dabei von unterschiedlichen Rolleninhabern wahrgenommen wer-den. So kann beispielsweise der Systemadministrator die Ist-Erhebung durchführen, das Sicher-heitsmanagement vergleicht danach die Ergebnisse mit den Vorgaben und bewertet die Abwei-chungen.


1.3 Ziele

Ein wesentlicher Aufgabenschwerpunkt bei der Realisierung und beim Betrieb sicherheitskriti-scher IT-Infrastrukturen ist eine kontinuierliche Sammlung von Informationen über das zu si-chernde System.

Während des Betriebs der Infrastruktur kommen zu Sicherheitsprüfungen durch Personen auchInformationen aus automatisch arbeitenden Systemen hinzu, die den ordnungsgemäßen Zustanddes oder der Systeme in Hinblick auf Integrität und Verfügbarkeit kontinuierlich überwachen.Hierzu gehören beispielsweise Integritätsprüfprogramme wie AIDE [vH11] oder allgemeineMonitoring-Programme wie nagios [NE11].

Auf Basis der Aussagen der Informationsgeber kann dann die Evaluation oder Auditierungdurchgeführt werden und eine Sicherheitseinschätzung für das untersuchte System durch einenPrüfer abgegeben werden. Bei sehr umfangreichen Untersuchungen können die Informationenauch hierarchisch eingeholt werden, d. h. ein für einen Bereich Verantwortlicher befragt seiner-seits Untergebene oder Kollegen und führt die dabei erhaltenen Informationen entweder selbstzusammen oder reicht diese entsprechend an die bewertende Stelle weiter.

Ein solcher sicherheitskritischer Prozess soll durch den gezielten Einsatz von digitalen Signatu-ren, geeigneten Zertifikatsformaten und automatisierten Kommunikations- und Auswertungsme-chanismen verbessert werden.

Wie bereits erwähnt, ermöglichen Programme wie das BSI-Grundschutz-Tool die elektronischeErfassung und Auswertung der gesammelten Informationen. Es ist teilweise ebenfalls möglich,die Informationen verteilt zu erfassen und durch Export- bzw. Importfunktionen zur Auswertungzusammenzuführen. Hierbei sind Zugriffskontrollmechanismen auf Betriebssystem- oder Daten-bankebene wirksam, so dass Berechtigungen für die Eingabe bestimmter Informationen an diejeweils Verantwortlichen vergeben und durchgesetzt werden können.

Diese Mechanismen ermöglichen jedoch nur eine Authentisierung der Daten, nicht aber einerechtliche Bindung des Informationsgebers an die Aussage. Des Weiteren ist die verteilte In-formationssammlung nur mit Instanzen eines Programms möglich, wenn keine standardisiertenSchnittstellen zum Datenaustausch bestehen. Eine Plattform- und Programm-übergreifende Er-fassung der Daten ist daher oft nicht möglich.

Ziel der in diesem Kapitel vorgestellten Vorgehensweise auf Basis neu einzuführender gramma-tikbasierter Zertifikate ist es, die Prozesse der Erfassung sicherheitsrelevanter Informationen fürSicherheitsaudits hinsichtlich der Verbindlichkeit durch den Einsatz von digitalen Signaturen zuverbessern. Gleichzeitig sollen jedoch auch im Sinne der mehrseitigen Sicherheit die Interessender Informationsgeber berücksichtigt werden.

1.3.1 Flexibilität

Das vorgestellte Anwendungsfeld erfordert Zusicherungen zu sehr verschiedenen Themen, dievon technischen Details aus Systemkonfigurationen über konkrete Systemzustände bis zur Erfül-lung organisatorischer Vorgaben reichen.

1.3 Ziele 9

Dadurch werden für die Zusicherungen entsprechend vielfältige Ausdrucksmöglichkeiten be-nötigt, die durch die bereitzustellenden Mechanismen nicht an sich beschränkt sein dürfen. Essollen daher prinzipiell beliebige Aussagen darstellbar sein.

Werden auf dieser Basis für einen Anwendungsfall bestimmte Aussageformen gewählt, so sollendiese wiederum flexibel im Sinne einer Parametrisierung gestaltbar sein. Dadurch sollen im Rah-men einer konkreten Auditierung für gleichartige Zusicherungen Bausteine bereitgestellt werden,die z. B. durch Einsetzen der jeweils untersuchten Systeme für den vorliegenden Untersuchungs-gegenstand ausgeprägt werden oder unterschiedliche Prüfmethoden und -ergebnisse darstellenkönnen.

1.3.2 Erhöhung der Verbindlichkeit

Aus Sicht eines Prüfers ist es wünschenswert, dass die durch die Informationsgeber erteiltenAuskünfte so verlässlich wie möglich sind, da eine Sicherheitsanalyse nur so gut sein kann wiedie Qualität der Ausgangsinformationen, auf denen sie beruht. Im Idealfall übernimmt der je-weilige Informationsgeber die Verantwortung für die Richtigkeit seiner Auskünfte. Diese Ver-antwortungsübernahme ist jedoch nur dann aus den in elektronischer Form vorliegenden Datenabzulesen, wenn diese sowohl eindeutig einem Aussteller zuzuordnen sind als auch eine Zusi-cherung der Verantwortungsübernahme existiert. Diese Zusicherung kann durch organisatorischeRahmenbedingungen wie Verfahrensanweisungen gegeben oder explizit in den Daten enthaltensein. Die höchste Verbindlichkeit wird dabei durch den Einsatz einer qualifizierten digitalen Si-gnatur erreicht.

Durch eine geeignete Vereinbarung der Interpretation der Aussagen bzw. eine entsprechendeFormulierung der signierten Inhalte kann damit der Informationsgeber für die Korrektheit derInformation die Haftung übernehmen oder die Bereitschaft zur Aktualisierung der Aussagen imBedarfsfall zusichern.

1.3.3 Verständlichkeit

Wird einerseits die Bindung eines Informationsgebers an seine Aussagen durch den Einsatz vonSignaturen verstärkt, so muss andererseits sein Interesse an überschaubaren und damit bewert-baren Konsequenzen der verbindlichen Abgabe seiner Aussage berücksichtigt werden, da sonstmit einer zu geringen Akzeptanz für diesen Mechanismus zu rechnen ist.

Zum einen muss sichergestellt werden, dass sowohl Informationsgeber als auch Informationsan-wender die gemachten Aussagen in gleicher Weise interpretieren, bzw. der Interpretationsspiel-raum dieser Aussagen muss soweit verkleinert werden, dass die Aussagen für beide Seiten inder gleichen, natürlichsprachlichen Form vorliegen. Diese Darstellungsform ist dann zwar ihrer-seits z. B. im Fall der Verwendung einer Fachsprache interpretationsbedürftig, jedoch umfasstdie notwendige Interpretation nicht mehr die Dekodierung der signierten Daten. Die technischeAufbereitung von Aussagen in Form signierter Zertifikate soll also keinen weiteren Interpretati-onsspielraum hinzufügen.


Zum anderen muss dem Informationsgeber die Möglichkeit gegeben werden, die Gültigkeit sei-ner Zusicherung zeitlich einzuschränken, da er die Verantwortung für den Zustand eines System-bereichs nicht auf beliebige Zeit übernehmen will oder kann. Grundsätzlich sollte es dem Infor-mationsgeber daher möglich sein, eine beliebige zeitliche Beschränkung an seine Aussagen zubinden, wobei organisatorische Vorgaben durch den technischen Mechanismus unberührt bleibenmüssen. Alternativ bzw. ergänzend können Mechanismen zum Widerruf einer gegebenen Zusi-cherung sinnvoll sein, wenn dem Informationsgeber bekannt wird, dass die Grundlage seinerZusicherung nicht mehr gültig ist.

1.3.4 Automatisierte Auswertung

Die Kodierung der erstellten Zertifikate muss so gestaltet sein, dass sie eine automatisierte Aus-wertung ermöglicht. Beispiele für eine solche Auswertung sind der Vergleich von gegebenenZusicherungen gegen einen Prüfkatalog zur Feststellung der Vollständigkeit oder die Feststel-lung der Erfüllung von Vorgaben aus Sicherheitsrichtlinien.

Die automatisierte Verarbeitung fordert daher eine wohldefinierte Form (Syntax) der Zertifika-te. Die verwendete Kodierung sollte einerseits flexibel, andererseits auch etabliert sein, um ineinfacher Weise die notwendigen Verarbeitungsmechanismen implementieren zu können.

Überdies sollte im Zertifikat die Datenmenge möglichst gering gehalten werden, um die Sy-stemressourcen zu schonen. Hierzu muss die Kodierung so gestaltet werden, dass lediglich dernotwendige Informationsgehalt in das Zertifikat aufgenommen wird, nicht jedoch die dahinterstehende natürlichsprachliche Darstellung.

1.3.5 Delegation

Um im Fall der Untersuchung großer Systeme mit hierarchisch organisierten Verantwortungs-strukturen den Abstimmungsaufwand über Verantwortungsbereiche und mögliche Informations-geber für den Prüfer zu vereinfachen, sollte es auch möglich sein, die eingehenden Informationennicht nur auf ihre Authentizität zu prüfen, sondern auch die jeweilige Berechtigung des Informa-tionsgebers automatisiert zu validieren.

Hierzu müssen Möglichkeiten geschaffen werden, die es erlauben, die Berechtigung eines In-formationsgebers hinsichtlich bestimmter Aussagetypen oder Systemkomponenten z. B. in Be-rechtigungszertifikaten auszudrücken, so dass bei Eintreffen einer signierten Zusicherung diesegegen die aus den Berechtigungszertifikaten abgeleiteten Rechte validiert werden kann. Die De-legationszertifikate müssen geeignet sein, hierarchische Verantwortungsstrukturen abzubilden,so dass es beispielsweise genügt, in einem Programm zur Auswertung von zertifizierten Sicher-heitsaussagen lediglich wenige Vertrauensanker zu hinterlegen. Dieses Vertrauen wird dann beider Auswertung von Zertifikatsketten transitiv auf Delegierte übertragen. Andererseits darf dieWeitergabe von Rechten nicht über zu viele Stationen erfolgen, da es bei Sicherheitsaudits i. d. R.Absprachen zwischen den Auditoren und den Informationsgebern geben muss.

1.4 Überblick über die Arbeit 11

1.4 Überblick über die Arbeit

Der Anspruch der Arbeit ist die Bereitstellung und Bewertung eines neuen Zertifizierungsme-chanismus, der den im Abschnitt 1.3 aufgestellten Zielen gerecht wird. Diese sog. grammatik-basierten Zertifikate stellen eine Möglichkeit zur integritätsgeschützten, verbindlichen Übermitt-lung von kompakt kodierten Zusicherungen im Rahmen von Auditierungen bereit. Sie bietendabei flexible Ausdrucksmöglichkeiten und unterstützen beweisbar gleichwertige Darstellungs-formen. Dies sind einerseits die für den Anwender verständliche Form in natürlicher Spracheund andererseits strukturierte XML-Daten, die automatisch verarbeitet werden können.

In Kapitel 2 werden zwei wesentliche Grundbausteine gesicherter elektronischer Kommunikati-on – Verschlüsselung und Signaturen – eingeführt. Es werden Zertifikate am Beispiel von Public-Key-Infrastrukturen auf Basis der X.509-Spezifikation vorgestellt und verschiedene Verfahrenzur Übermittlung von signierten Zusicherungen wie Berechtigungen u. ä. betrachtet. Eine Be-wertung der vorgestellten Zusicherungs- und Zertifizierungsverfahren mit den in diesem Kapitelaufgestellten Anforderungen motiviert den nachfolgenden Entwurf neuer Mechanismen.

Anschließend werden in Kapitel 3 Methoden zur Analyse von Sicherheitseigenschaften in Kom-munikationssystemen vorgestellt, die im weiteren Verlauf der Arbeit angewendet werden. Diesessind zum einen die Belief-Logik SVO von Syverson und van Oorshoot, sowie der Pi-Kalkül unddas darauf aufsetzende Model-Checking-Werkzeug proverif. Diese Methoden ermöglichen diepräzise Modellierung von Kommunikationsprotokollen und bieten die Möglichkeit, die Modellehinsichtlich der erreichbaren Zusicherungen und der Einhaltung von Vertraulichkeits- und Inte-gritätszielen zu evaluieren.

In Kapitel 4 wird das neue Konzept der grammatikbasierten Zertifikate auf Basis kontextfreierGrammatiken vorgestellt. Auf Basis dieses neuen Zertifikatstyps werden weitere Mechanismenentworfen, die dazu dienen, die in diesem Kapitel für den Anwendungsfall der Sicherheitsprü-fungen geforderten Eigenschaften bereitzustellen. Diese Mechanismen umfassen die Möglich-keit zur präzisen Definition von Anforderungen für Sicherheitsprüfungen, die Beschreibung undggf. Einschränkung von Rechten zur Erstellung von Zusicherungen im Falle der Delegation unddie ggf. vertrauliche Verteilung kontextfreier Grammatiken durch einen zentralen Dienst.

Schließlich wird in Kapitel 5 die Implementierung der neuen grammatikbasierten Zertifikate undder zugehörigen Mechanismen vorgestellt und die zugrunde liegenden Konzepte einer formalenAnalyse mittels der in Kapitel 3 eingeführten Werkzeuge unterzogen. Dabei wird eine formaleSemantik für die grammatikbasierten Zertifikate und die Delegationsmechanismen angegebenund die Wirksamkeit der Mechanismen mittels der SVO-Logik gezeigt.

Eine Zusammenfassung der Ergebnisse und ein Ausblick schließen die Arbeit ab.


2 Zertifizierungssysteme

Die schriftliche Bestätigung von Sachverhalten ist eine sehr alte Vorgehensweise. So wurden be-reits im Mittelalter Urkunden für z. B. Stadtrechtsverleihungen, Kaufverträge, usw. gefertigt. Siewurden genutzt, um Ansprüche oder Sachverhalte auch in Abwesenheit des Ausstellers gegen-über Dritten zu beliebigen Zeitpunkten an beliebigen Orten belegen zu können.

Die bereits früh entwickelten Formen von Urkunden mit formalem Aufbau haben sich bis heuteerhalten und Verträge und Zertifizierungen werden auch heute noch nach festen Kriterien mitspezifischen Verifikationsmerkmalen aufgebaut, die eine Prüfung durch Dritte ermöglichen.

Bei der Digitalisierung solcher Dokumente werden jedoch neue Anforderungen gestellt. DieDokumente existieren nicht mehr in Form physischer Entitäten wie Papier mit Unterschrift undSiegel sondern sind zunächst ein beliebig kopier- und manipulierbarer Datenstrom.

Die Verfügbarkeit der asymmetrischen Kryptographie hat es jedoch möglich gemacht, Nachwei-se des Ursprungs und damit auch Zusicherungen von Inhalten elektronisch mit digitalen Signa-turen nachzubilden.

Es werden in diesem Kapitel Grundverfahren von digitalen Signaturen und Zusicherungen (Zerti-fikaten) dargestellt und spezielle Formen von Zusicherungen aus den Bereichen Schlüsselvertei-lung und Autorisierung vorgestellt. Daneben werden teilweise bereits Schreibweisen eingeführt,die der im nachfolgenden Kapitel eingeführten, nach ihren Autoren Syverson und van Oorschotbenannten SVO-Logik entnommen sind.

Die dargestellten Verfahren stellen den Stand der Technik dar und werden abschließend qualitativhinsichtlich ihrer Eignung bewertet, die in Abschnitt 1.3 aufgestellten Ziele zu erreichen.

2.1 Grundbegriffe kryptographischer Kommunikationssicherung

Zur Absicherung von Kommunikationsvorgängen über elektronische Medien werden i. d. R. kryp-tographische Verfahren eingesetzt. An dieser Stelle werden die in dieser Arbeit zur Benennungeingesetzter Schlüssel und Verfahrensschritte verwendeten Begriffe zusammengestellt.

Kommunikationsvorgänge können hinsichtlich verschiedener Ziele schützenswert sein. Für dieseArbeit sind folgende Ziele relevant:

13

14 Kapitel 2. Zertifizierungssysteme

Vertraulichkeit Beim Erhalt der Vertraulichkeit werden die Kommunikationsinhalte vor un-autorisierter Kenntnisnahme durch Dritte geschützt. Lediglich der Sender und die durchden Absender vorgesehenen Empfänger einer Kommunikation sollen auf die Inhalte zu-greifen können.

Integrität Bei der Absicherung der Integrität werden die Kommunikationsinhalte vor unautori-sierter Veränderung geschützt bzw. eine Veränderung zuverlässig erkennbar gemacht. Inte-gritätsgeschützte Inhalte erreichen die Empfänger nur in der durch den Absender erzeugtenForm.

Authentizität Ein Kommunikationsinhalt gilt als authentisch, wenn er eindeutig und korrektdurch einen Empfänger einer Quelle zugeordnet werden kann.

Nicht-Abstreitbarkeit Der Urheber eines Kommunikationsinhaltes kann seine Urheberschaftnicht verleugnen. Diese Eigenschaft wird auch als Zurechenbarkeit bezeichnet.

Die geschützte Kommunikation kann dabei über Distanzen (Nachrichtenübertragung), über dieZeit (Speicherung von Information) oder beides sein.

Der gewünschte Schutz wird dabei i. d. R. durch den Einsatz von kryptographischen Verfahrenerreicht. Es werden im Folgenden die bekannten Standardverfahren Verschlüsselung und Signa-tur betrachtet.

Beim Einsatz von Verschlüsselung werden die zu schützenden Daten als Klartext bezeichnet.Durch den Einsatz eines geeigneten Rechenverfahrens, der Verschlüsselung (auch Chiffrierung)wird der Klartext mit Hilfe eines durch einen Schlüssel parametrisierten Algorithmus in das sog.Chiffrat überführt. Dieses kann nur durch den Einsatz der Entschlüsselung (auch Dechiffrierung)in den ursprünglichen Klartext zurück gewandelt werden.

Beim Einsatz von Signaturen wird zu einem Text, dessen Integrität zu schützen und dessen Au-thentizität zu belegen sind, durch die Operation der Signaturerstellung mittels eines Signatur-schlüssels eine Signatur (auch digitale Unterschrift) erstellt. Diese kann genutzt werden, um imRahmen der Signaturprüfung unter Verwendung des Signaturprüfschlüssels die Authentizität dessignierten Textes nachzuweisen.

Abbildung 2.1 veranschaulicht graphisch diese Zusammenhänge.

2.2 Signaturen

2.2.1 Signaturbegriff

Der Begriff Signatur (von lat. signatura von lat. signare = unterzeichnen, mit einem Zeichenversehen) steht für ein eindeutig einer Person zugeordnetes Namens- oder sonstiges Zeichen, dasBestandteil eines Dokumentes ist. Im Idealfall ermöglicht eine Eindeutigkeit des Namenszei-chens die eindeutige Zuordnung des Zeichens (z. B. einer eigenhändigen Unterschrift) zu einer

2.2 Signaturen 15

Klartext Chiffrat

(öffentlicher)Verschlüsselungsschlüssel

(privater)Entschlüsselungsschlüssel

Verschlüsselung

Entschlüsselung

Text Signatur

(privater)Signierschlüssel

(öffentlicher)Signaturprüfschlüssel

Signaturerstellung

Signaturprüfung

Abbildung 2.1: Übersicht über verwendete kryptographische Grundbegriffe

Person. Ziel einer Signatur ist i. d. R. die Sicherung der Authentizität eines Dokumentes. Darüberhinaus kann die Signatur jedoch auch als Nachweis der Kenntnis oder des Einverständnisses mitdem signierten Inhalt eines Dokumentes eingesetzt werden. Im Folgenden werden die BegriffeSignatur und Unterschrift synonym verwendet.

Der Zusammenhang zwischen signiertem Inhalt und Signatur wird in Abbildung 2.2 skizziert.

I Verbindendes Element

Signatur

Signierte Information

S

Abbildung 2.2: Zusammenhang zwischen Inhalt und Signatur

Das verbindende Element fügt Inhalt I und Signatur S eindeutig zusammen, so dass der Bezugzweifelsfrei erkennbar ist. Bei herkömmlichen Dokumenten ist dieses verbindende Element diephysische Einheit des Trägermediums (z. B. das Papier), auf das Inhalt und Signatur aufgebrachtwurden. Bei elektronischen Signaturen übernimmt diese Funktion ein Rechenverfahren (Ver-schlüsselung des Dokumentes oder eines Hashwertes H(I) des Dokumentes mit dem privatemSchlüsselK−1) bzw. der durch Anwendung des Verfahrens erzeugte funktionale Zusammenhangzwischen Signatur, signiertem Text und Signaturschlüssel.

2.2.2 Signaturarten

2.2.2.1 Grundprinzip der Signaturerstellung

Die prinzipielle Vorgehensweise bei der Erstellung einer Signatur wird in Abbildung 2.3 darge-stellt.


Verfahrensschritte 1 und 2

zur Signaturerstellung (SE)

Signaturersteller

(geheime)

Signaturinformation

I

E

K −1SE 1

SE 2S

Abbildung 2.3: Signaturerstellung

2.2.2.2 Manuelles Verfahren

In einem ersten Schritt wird die zu signierende Information I erstellt und das verbindende Ele-ment bereitgestellt. Dies kann beispielsweise durch Aufschreiben der zu signierenden Informati-on auf ein Blatt Papier erfolgen. Dieser erste Schritt muss nicht vom Signaturersteller ausgeführtwerden, sondern kann zeit- und ortsunabhängig durch einen Dritten erfolgen.

Der Signaturersteller erhält die zu signierende Information mit dem verbindenden Element (Textin gedruckter Form) und wendet ein Verfahren zur Erstellung der Signatur an, wobei eine nurihm bekannte Information oder eine für ihn spezifische Eigenschaft angewendet wird. Bei derUnterschrift wird ein nur vom Signaturersteller erzeugbarer Schriftzug mit dokumentenechtenSchreibgeräten auf das Dokument aufgebracht. Dieser Schriftzug kann i. d. R. nur mit dem Wis-sen (eingeübter Bewegungsablauf) und der Handgeometrie des Signaturerstellers erzeugt wer-den. Eine alternative Methode ist das Aufbringen eines Fingerabdrucks, bei dem eine eindeutigeEigenschaft des Signaturerstellers (Formgebung der Papillarleisten) zum Einsatz kommt. In mo-dernen biometrischen Zugangskontrollsystemen wird mit daktyloskopischen Verfahren, z. B. dieInfrarot-Abtastung, diese Eigenschaft zur Authentifizierung von Personen benutzt.

2.2.2.3 Elektronische Signatur

Wird das Prinzip der manuellen Signatur auf ein elektronisches Dokument übertragen, so kannbeispielsweise als verbindendes Element eine Datei dienen, in der die zu signierende Informa-tion in Form einer Zeichenfolge gespeichert wird. Zusätzlich können in diese Datei Bilddateneingefügt werden, die eine Digitalisierung der eigenhändigen Unterschrift des Unterzeichnendenrepräsentieren. Diese einfache Form einer digitalen Unterschrift hat jedoch den Nachteil, dass dieBindung zwischen Dokumentinhalt und Unterschrift nur logischer Natur ist, also auf Vereinba-rungen beruht (z. B. ist im Dateisystem eines Rechners abgelegt, welche gespeicherten Zeichenzu einer Datei gehören). Auch wenn die logische Zuordnung innerhalb von Systemen geschütztwerden kann, so ist der Schutz bei Übertragung über nicht vertrauenswürdige Bereiche (z. B.Versenden per E-Mail) nicht mehr aufrecht zu halten. Ein Angreifer kann problemlos Inhalt oderSignatur austauschen. Darüber hinaus ist es auch möglich, das digitalisierte Abbild der Signatur

2.2 Signaturen 17

beliebig oft zu kopieren und anderweitig zu verwenden. Auf Basis einer solchen elektronischenSignatur ist es daher nicht möglich, die Authentizität einer in einem elektronischen Dokumententhaltenen Aussage zu beweisen.

2.2.2.4 Kryptographische Signatur

Eine Verbesserung der Signatureigenschaften bei elektronischen Dokumenten kann durch Über-gang von einer logischen Verknüpfung zwischen Dokumentinhalt und Signatur auf eine krypto-graphische Verbindung erreicht werden. Damit ermöglichen digitale Signaturen mit Hilfe kryp-tographischer Mittel, den Absender einer Nachricht eindeutig zu bestimmen. Eine solche kryp-tographische Signatur wird auch technische Signatur genannt.

Nach [MvOV96] ist eine kryptographische Signatur ganz allgemein ein Datum, das eine digitaleNachricht einer Nachrichtenquelle überprüfbar zuordnet. Die Basis für dieses Verfahren ist eindigitales Signaturschema, das aus einem Algorithmus zur Generierung und einem Algorithmuszur Überprüfung von Signaturen besteht. Generell lassen sich nach [PMH96] dabei Signaturver-fahren mit Nachrichtenrückgewinnung von Signaturverfahren mit Anhang unterscheiden. Erstge-nannte ermöglichen die Berechnung des signierten Dokumentes aus der Signatur während letz-tere zusätzlich das signierte Dokument zur Überprüfung der Signatur benötigen. Im Folgendenwerden überwiegend Signaturverfahren mit Anhang betrachtet, da diese effizienter bei langenNachrichten sind.

Bekannte Vertreter der Signaturschemata sind das Signaturschema nach Rivest, Shamir und Ad-leman (RSA) [RSA78] sowie der Digitale Signatur Algorithmus (Digital Signature Algorithm,DSA) des National Institute of Standards and Technology (NIST)[Nat94], der wiederum aufdem Signaturschema von El Gamal [Gam85] basiert. Daneben haben in den letzten Jahren dieVerfahren zur Erzeugung von Signaturen auf Basis von elliptischen Kurven (Elliptic Curve Cryp-tography, ECC)[KMV00] an Bedeutung gewonnen, die wiederum für die Definition des EllipticCurve Digital Signature Algorithm (ECDSA) verwendet werden [JMV01].

Ein digitales Dokument kann durch Bereitstellen einer verschlüsselten Zusammenfassung desDokumentes digital signiert werden. Dabei muss die Zusammenfassung eindeutig dem Doku-ment zuordenbar sein und die Verschlüsselung muss so gestaltet sein, dass nur genau eine Personoder Instanz diese erzeugt haben kann.

Eine Dokumentzusammenfassung in diesem Sinne wird durch sog. Einweg-Hash-Funktionenbereitgestellt, die einen z. B. 160 oder 256 Bit langen Wert aus dem Inhalt des Dokumentesberechnen. Beispiele für Hash-Algorithmen sind RACE Integrity Primitives Evaluation Messa-ge Digest (RIPEMD-160)[ISO04] und Secure Hash Algorithm Version 256 (SHA-256)[Nat02].Letzterer wird derzeit zur Anwendung empfohlen. Es existieren jedoch auch stärkere Verfahrenmit längeren Hashwerten (SHA-384 und SHA-512 [Nat02, Nat04] ), die voraussichtlich in denkommenden Jahren die derzeitige Empfehlung in der technischen Richtline 02102 des Bundes-amtes für Sicherheit in der Informationstechnik [Bun08c], dem sog. Algorithmenkatalog, ablösenwerden. Darüber hinaus wurde der Keccak-Algorithmus [BDPA09] durch das NIST als SHA3-Algorithmus ausgewählt [jCPB+12].


Das Verfahren zur Referenzierung von Dokumenten durch Hash-Werte lässt sich ebenfalls mitder Darstellung in Abbildung 2.3 erläutern. Das zu signierende Dokument entspricht der Infor-mation I . Diese wird durch Anwendung der Einweg-Hash-Funktion im Schritt Signaturerstel-lung 1 (SE1) auf einen Wert H(I) abgebildet. Dieser Wert ist eindeutig dem Inhalt I zuzuordnen.Durch Verschlüsselung des Wertes H(I) mit dem privaten Schlüssel K−1 des SignaturerstellersE entsteht im Schritt SE2 die eigentliche Signatur

S = {H(I)}K−1

(zu lesen als: der Hashwert von I verschlüsselt unter dem privaten Schlüssel K−1). Es handeltsich damit um eine Signatur ohne Nachrichtenrückgewinnung. Daher müssen die signierten Da-ten und die Signatur gemeinsam als (I, S) zur Durchführung einer Signaturprüfung vorliegen.Hierfür wird die kürzere Schreibweise der SVO-Logik verwendet:

bIcK−1 = (I, S) = (I, {H(I)}K−1)

Die elektronische Signatur kann in ihrer Qualität durch das Einhalten von technischen und orga-nisatorischen Maßnahmen in ihrer Aussagekraft maßgeblich beeinflusst werden. Spezielle An-forderungen an Eigenschaften werden für die fortgeschrittene und die qualifizierte Signatur ge-stellt.

2.2.2.5 Fortgeschrittene Signatur

Eine fortgeschrittene Signatur ist nach [Bun01a] eine elektronische Signatur, die es ermöglicht,den Signaturschlüsselinhaber eindeutig zu identifizieren. Dies wird durch die Forderung der al-leinigen Kontrolle einer Person oder Instanz (Signaturschlüssel-Inhaber) über die Mittel zur Er-stellung der Signatur und einen durch die Signatur bedingten Integritätsschutz ermöglicht.

2.2.2.6 Qualifizierte Signatur

Unter einer qualifizierten elektronischen Signatur wird nach [Bun01a] eine Signatur verstanden,die alle Eigenschaften einer fortgeschrittenen Signatur aufweist und die zusätzlich auf Basis einesasymmetrischen Schlüsselpaares erzeugt wurde, für dessen öffentlichen Schlüssel zum Zeitpunktder Erstellung der Signatur ein qualifiziertes Zertifikat vorlag und die mit Hilfe einer als sichereingestuften technischen Umgebung erzeugt wurde.

Die „Qualifizierung” der Zertifikate wird dabei durch eine Reihe von Anforderungen technischerund organisatorischer Art erreicht, die das Sicherheitsniveau betreffen. Als Beispiele können hierdie Speicherung der privaten Schlüssel und die Signaturerstellung in evaluierten Umgebungen(z. Z. lediglich durch spezielle Chipkarten erfüllt), Anforderung an das Schlüsselmanagementwie geteilte Geheimnisse, Protokollierung und Auditierung, aber auch die organisatorischen Ab-läufe bei der Registrierung usw. genannt werden.

2.2 Signaturen 19

2.2.3 Verwendung von Signaturen

Signaturen werden auf unterschiedlichen Ebenen innerhalb von Kommunikationssystemen an-gewendet. Auf Sitzungsebenen können Signaturen zur Identifikation und Authentisierung vonberechtigten Systembenutzern an Stelle von Passwortmechanismen oder anderen geteilten Ge-heimnissen eingesetzt werden. So lassen sich Signaturschlüssel z. B. beim Aufbau von SSL-Verbindungen zwischen Browser und Webserver einsetzen.

Auf der Anwendungsebene können Signaturen zum Schutz von Dokumenten wie beispielsweisePDF-Dateien oder zur Authentisierung von E-Mail-Kommunikation eingesetzt werden.

Die Kernaufgabe der Signatur ist es, die Urheberschaft eines signierten Datums eindeutig beleg-bar zu machen.

Hierzu spielen zwei Eigenschaften zusammen: zum einen wird durch die Anwendung des Si-gnaturverfahrens ein Integritätsschutz über die signierten Daten gelegt. Zum anderen kann durcheine exklusive Zuordnung des asymmetrischen Schlüsselpaares zu einer ausstellenden Instanz ei-ne Aussage über den Urheber der signierten Daten gemacht werden. Beide Eigenschaften werdenbei der Signaturprüfung eingesetzt.

Im Fall einer Signatur ohne Nachrichtenrückgewinnung liegt beim Prüfenden die Information(I ′, {H(I)}K−1) vor. Ist er im Besitz des öffentlichen PrüfschlüsselsK, so kann er diesen zur Ent-schlüsselung des Hashwertes und damit zur Signaturprüfung verwenden. Das erhaltene Datumwird als I ′ bezeichnet, da die Integrität, also die Übereinstimmung mit dem ursprünglich gesen-deten Datum I , noch nicht nachgewiesen ist. Zur Prüfung werden zwei Signaturprüfschritte (SP)durchgeführt: Berechnung des Hashwertes über I ′ (SP1) und Entschlüsselung des verschlüssel-ten Hashwertes über I (SP2). Auf diese Terme wird folgender Zusammenhang angewendet:

H(I ′) = {{H(I)}K−1}K ⇔ I = I ′ (2.1)

Ist diese Identität gegeben, so liegt mit I ′ das gleiche Datum vor, dass zur Bildung von H(I)verwendet wurde, damit stellt das vorliegende Werte-Paar eine korrekte angehängte Signaturvon I dar:

(I ′, {H(I)}K−1) = bIcK−1

Aus der Tatsache, dass die Prüfoperation (2.1) mit diesem asymmetrischen öffentlichen Schlüsseldurchgeführt wurde, lässt sich aufgrund der Grundeigenschaft der asymmetrischen Verschlüsse-lung ableiten, dass die Signatur unter Anwendung des korrespondierenden privaten SchlüsselsK−1 gebildet wurde.

Ist der Prüfschlüssel (Public Key, PK) für Signaturen (Index σ) der exklusiven Verwendung durcheinen Ersteller E zugeordnet, so wird dies durch das Prädikat

PKσ(E,K)


ausgedrückt. Das Prädikat PKσ(E,K) impliziert dabei die Annahme der alleinigen Kontrollevon E über K, wie sie in der Definition der fortgeschrittenen Signatur (vgl. Abschnitt 2.2.2.5)gefordert wird.

Mit einer solchen Zuordnung kann die Signatur über I nur vom Inhaber E des zu K gehörendenprivaten Schlüssels stammen und somit wird der Ursprung des Datums E zugeordnet. Somit giltI als authentisch in Bezug auf E.

Abbildung 2.4 veranschaulicht die beschriebenen Prüfschritte.

Verfahrensschritte 1 und 2

zur Signaturprüfung (SP)

(öffentliche)

Prüfinformation

Signaturprüfer

Signatur−

ersteller

I=I’

SP 2

SP 1PK(E,K)

P E

K −1SE 1

SE 2S

Abbildung 2.4: Signaturprüfung

Diese Signaturvalidierung (SV) kann für angehängte Signaturen auch durch ein entsprechen-des dreistelliges Prädikat SV(X,K, Y ) ausgedrückt werden. Dieses wird gelesen als „X gehtaus Y durch Anwendung des zu K gehörenden privaten Schlüssels hervor“. Somit ist z. B.SV(bIcK−1 , K, I) wahr.

2.2.3.1 Technische Interpretation von Signaturen

Wurde eine Signatur mit Rückgewinnung über ein Dokument erfolgreich geprüft, so kann darausabgeleitet werden, dass es dem Unterzeichnenden vorlag, er also zumindest temporär im Besitzdes Dokumentes war.

Im engeren technischen Sinn ist bei Signaturerstellung mit Hashwert zwar lediglich abzuleiten,dass dem Signaturersteller der Hashwert und nicht zwangsläufig das Dokument vorlag, in derUmsetzung guter Signaturprogramme wird jedoch der Hashwert erst bei der Signaturerstellunggebildet, so dass das zu signierende Dokument vorliegen muss.

Im Allgemeinen wird daher angenommen, dass der Unterzeichnende den Inhalt des Dokumentes,das er unterschrieben hat, auch kennt. Hierbei ist jedoch zwischen menschlichen Anwendern undtechnischen Programmen zu unterscheiden.

Im Fall der Nutzung von Signaturen zur Authentisierung gegenüber Web-Anwendungen oderServern werden bei den eingesetzten Protokollen i. d. R. Zufallswerte (Nonces) eingesetzt, die

2.2 Signaturen 21

durch eine Signatur des zu Authentisierenden genutzt werden, um beispielsweise einen Session-Kontext dem Eigentümer des verwendeten Signaturschlüssels zuzuordnen. In einem solchen Fallkennt der menschliche Nutzer die signierten Daten nicht, da diese vom Client-Programm üb-licherweise nicht zur Anzeige gebracht werden. Das ist auch der Grund, warum oftmals fürVerschlüsselung und Signaturerstellung getrennte Schlüssel verwendet werden. Bei doppelterNutzung eines Schlüssels für beide Anwendungsfälle könnte ein Angreifer durch Betrieb einerbösartigen Webseite durch geeignete Wahl des zu signierenden Wertes eine Signatur erschlei-chen.

Daher wird für die weiteren Betrachtungen die Verwendung eines Signaturschlüssels exklusivfür die Erstellung von Signaturen festgelegt.

Die technische Interpretation besagt somit, dass die erfolgreiche Signaturprüfung eines Datumsdie Beteiligung des Zertifikatsinhabers an der Erstellung der Signatur nachweist. Damit ist eben-falls ein schwacher Integritätsschutz gegeben (Änderungen an den signierten Daten sind erkenn-bar).

Die digitale Signatur schafft somit einen kryptographischen Kanal für die signierten Daten miteinem Eingangspunkt beim Signaturersteller und vielen Endpunkten bei den jeweiligen Empfän-gern der signierten Nachricht, der vor Manipulation durch Dritte schützt (vgl. Abbildung 2.5).

K

Ersteller Signaturprüfer Px

I K

K

K-1 S

P1IP2

IP3

Ikryptographischer

Kanal

Abbildung 2.5: Verteilung signierter Information

2.2.3.2 Weitergehende Bedeutung von Signaturen

Aus dem Vorhandensein einer Signatur zu einem Datum lässt sich außer der Authentizität zu-nächst keine weitere Aussage ableiten. Erst durch Betrachtung der signierten Inhalte oder nichttechnischer Randbedingungen können weitere Aussagen zur Bedeutung einer Signatur getrof-fen werden. Daher muss stets zwischen der eigentlichen (technischen) Signatur mit ihrer tech-nischen Funktion und einer darüber hinausgehenden Interpretation (speziell mit Rechtsfolgen)unterschieden werden.

Handelt es sich um eine Erklärung (i. S. einer Willenserklärung), so wird angenommen, dass die-se im Sinne des Unterzeichnenden ist. Hat das Dokument einen bestätigenden Charakter odergeht aus der Art der Anbringung der Signatur der Wille zur Bestätigung eines Sachverhalts her-vor, so wird angenommen, dass der Signierende von der Richtigkeit des Sachverhalts überzeugtist.


Werden die Signaturen jedoch auch im Rahmen von Rechtsgeschäften eingesetzt, so ergeben sichweitere Aspekte. Die Form der zu signierenden Daten erhält ein höheres Gewicht und erweiterteorganisatorische Randbedingungen müssen eingehalten werden.

Bei der Verwendung der Signaturen zur Erreichung von Schutzzielen der Nicht-Abstreitbarkeit(engl. non-repudiation), wie dies bei Abgabe einer Willenserklärung z. B. bei einem Vertrags-schluss oder einer Antragstellung der Fall ist, müssen organisatorische Randbedingungen be-achtet werden. In Deutschland sind hier die Festlegungen des Signaturgesetzes [Bun01a] undder zugehörigen Signaturverordnung [Bun01b] relevant, die ihrerseits die Direktive der Europäi-schen Union zum Rahmenwerk für elektronische Signaturen [EU-00] berücksichtigen.

Diese legen technische und organisatorische Maßnahmen fest, die auf ein möglichst hohes Maßan Sicherheit hinsichtlich der Nicht-Abstreitbarkeit von qualifiziert signierten Dokumenten ab-zielen. So sind die Verwendung einer Public Key Infrastruktur mit zertifikatsbasierter Verteilungdes öffentlichen Schlüssels, die sichere Speicherung des privaten Schlüssels auf einer Chipkar-te und die persönliche Registrierung des Schlüsselinhabers bei einer Registrierungsstelle vor-geschrieben. Die verwendeten Schlüsselzertifikate müssen ebenfalls Formvorgaben entsprechenund die ausgebende Zertifizierungsstelle muss bestimmten Sicherheitsanforderungen entspre-chen.

Diese Rahmenbedingungen werden teilweise von Standardisierungsgremien aufgegriffen und inden entsprechenden Standards berücksichtigt [SNP04, TT09].

Neben der Aufgabe der Sicherung der Authentizität eines Dokumentes verändert das Vorhanden-sein einer Signatur ggf. die juristische Form eines Dokumentes. So geht eine Willenserklärung inTextform (eine in lesbaren Schriftzeichen fixierte Erklärung oder Mitteilung) erst durch Hinzufü-gen des Namens des Ausstellers und seiner Unterschrift in die vom Gesetz geforderte Schriftformbzw. im Falle eines elektronischen Dokumentes durch Hinzufügen der qualifizierten Signatur indie elektronische Form über (§126a BGB und §3 Satz 2 SigG).

Die Schriftform für Erklärungen ist im Bürgerlichen Gesetzbuch [Bun02] für verschiedene Artenvon Rechtsgeschäften vorgeschrieben, z. B. Miet- und Pachtverträge auf bestimmte Zeit (§550,§585a), Zeugnisse (§630) und Bürgschaften (§766). Durch §126 BGB ist die elektronische Formder Schriftform grundsätzlich gleichgestellt, sofern durch das Gesetz nicht eine Ausnahme be-stimmt ist. Beispiele für solche Ausnahmen sind Bürgschaften (§766), Testamente (§2247) undDarlehensverträge (§492).

Es ist allerdings festzustellen, dass entweder aus den signierten Daten selbst oder den Umständender Signaturerstellung (z. B. Art der Anwendung) der Charakter der Willenserklärung oder Bestä-tigung hervorgehen muss, damit diese juristisch motivierten Überlegungen angewendet werdenkönnen.

2.3 Standardisierte Signaturformate

Bei den im Weiteren beschriebenen standardisierten Signaturformaten besteht die eigentlicheSignatur in der bereits oben beschriebenen kryptographischen Operation mit Hilfe eines asym-

2.3 Standardisierte Signaturformate 23

metrischen Schlüssels über einem Hashwert der zu signierenden Daten. Der Unterschied liegtjedoch jeweils in der Einbettung eines solchen Signaturwertes in zusätzliche Daten, die Infor-mationen über die Art und Weise der Erstellung der Signatur und damit ggf. über ihre Semantikenthalten. Ein weiteres Unterscheidungsmerkmal sind zusätzlich organisatorische Randbedin-gungen, die von den Ausstellern solcher Signaturen und den Zertifizierungsstellen für die öf-fentlichen Schlüssel eingehalten werden müssen. Teilweise enthalten die Daten, die die Signaturergänzen, Hinweise auf diese Randbedingungen und verändern damit die Aussage oder Aussage-stärke einer digitalen Signatur. Es wird mit PKCS#1 zunächst ein Grundverfahren beschrieben,das teilweise wiederum in anderen Formaten verwendet wird. Bei den darauf aufsetzenden Signa-turverfahren wird neben einer kurzen Formatbeschreibung auch auf die jeweiligen Festlegungenzur Bedeutung der Signaturen eingegangen.

2.3.1 PKCS#1

Der Public Key Cryptography Standard No. 1 (PKCS#1) wurde in seiner jüngsten Fassung 2012durch die RSA Laboratories veröffentlicht [RSA12]. Er legt Verfahren zum Umgang mit RSA-Schlüsseln fest, die auf dem im Jahr 1977 von Ron Rivest, Adi Shamir und Leonard Adlemanentwickelten asymmetrischen Verschlüsselungsverfahren auf Basis großer Primzahlen und desFaktorisierungsproblems beruhen [RSA78].

Dieser Standard definiert Verfahren zur Erstellung einer angehängten Signatur (d. h. es ist keineRückgewinnung des signierten Textes aus der Signatur möglich). Sie sind die Grundlage vielerAnwendungen, die in den folgenden Teilkapiteln erläutert werden.

Das als RSASSA-PSS bezeichnete Signaturschema erzeugt aus der zu signierenden Nachrichtzunächst einen Hashwert, der als Oktettfolge vorliegt. Nach Umwandlung dieser Oktettfolge ineine Ganzzahl wird auf diese die Verschlüsselungsoperation mit dem privaten Schlüssel des Sig-naturerstellers angewendet. Das Ergebnis wird von einer Ganzzahl wieder in eine Oktettfolgeumgewandelt und stellt die Signatur S dar.

Zur Prüfung wird aus der Signatur wieder mit Formatwandlungen und Anwendung des aus Mo-dulus n und Exponent e bestehenden öffentlichen Schlüssels (n, e) [RSA78] der Hashwert zu-rückgewonnen und mit einem neu berechneten Hashwert über die zu prüfende Nachricht vergli-chen.

2.3.2 PKCS#7

Ebenfalls von den RSA Laboratories wurde der Public Key Cryptography Standard No. 7 (PK-CS#7) mit dem Titel Cryptographic Message Syntax Standard [RSA93] im Jahr 1993 veröffent-licht.

Dieser Standard legt Kodierungsschemata für signierte und verschlüsselte Nachrichten auf Basisder ASN.1-Kodierung fest. Die damit definierten Objekt-IDs decken die verschiedenen Anwen-dungsfälle ab: signedData, envelopedData, signedAndEnvelopedData, digestedData, encrypted-Data. Das Prinzip des Umschlags (envelope) verknüpft verschlüsselte Inhalte mit dem für einen


oder mehrere Empfänger asymmetrisch verschlüsselten symmetrischen Schlüssel, der zur Siche-rung des Inhalts verwendet wurde.

Gemeinsam mit den signierten Daten können auch Metainformationen wie die verwendeten Al-gorithmen und zusätzliche Prüfinformationen wie Zertifikate und Rückruflisten von Zertifikatenzusammen mit den signierten Daten und der Signatur kodiert werden.

Der Standard war insbesondere entworfen worden, um das ebenfalls 1993 bei der IETF standar-disierte Verfahren zur Bereitstellung gesicherter E-Mail-Kommunikation Privacy Enhancementfor Internet Electronic Mail [Lin93, Ken93, Bal93, Kal93] zu unterstützen. Dieses wurde spätervom S/MIME-Verfahren abgelöst (vgl. Abschnitt 2.3.6), in das auch die Weiterentwicklung derFestlegungen des PKCS#7 übernommen wurden.

2.3.3 XML basierte Signaturen

Das World Wide Web Consortium (W3C), das für viele Standardisierungen von Datenformatenund Protokollen im Anwendungsumfeld des Internets verantwortlich ist, hat im Rahmen sei-ner Spezifikationen der eXtensible Markup Language (XML) auch Festlegungen für digitaleSignaturen getroffen. Dies sind u. a. die Empfehlung XML-Signature Syntax and Processing[BBF+08] sowie die Empfehlung XML Advanced Electronic Signatures (XAdES)[CKPR03].

Das in [BBF+08] entworfene Signaturschema bettet digitale Signaturen in ein XML-Dokumentein, das Angaben über die verwendeten Signaturalgorithmen, Schlüssel u. a. enthält.

Der prinzipielle Aufbau einer XML-kodierten Signatur hat die Form

<Signature ID?><SignedInfo>

<CanonicalizationMethod/><SignatureMethod/>(<Reference URI? >

(<Transforms>)?<DigestMethod><DigestValue>

</Reference>)+</SignedInfo><SignatureValue>(<KeyInfo>)?(<Object ID?>)*

</Signature>

Das Referenzelement, das beliebig oft verwendet werden kann, ist ein Verweis auf die eigent-lichen Daten, aus denen mit dem angegebenen Verfahren (DigestMethod) ein Hashwert (Di-gestValue) abgeleitet wurde. Der signierte Bereich des XML-Dokumentes (SignedInfo) wirdvor der Berechnung eines Hashwertes noch auf eine vereinheitlichte Darstellung mit dem re-ferenzierten Verfahren (CanonicalizationMethod) gebracht. Schließlich wird dieser Bereich mitden angegebenen Hash- und Signaturalgorithmen (SignatureMethod) signiert. Eine Referenz auf

2.3 Standardisierte Signaturformate 25

den zugehörigen Prüfschlüssel kann in KeyInfo angegeben werden. Innerhalb des Object-Tagskönnen Erweiterungen angegeben werden, die XMLSIG zur Ergänzung der Signatur um einSignatureProperties-Objekt nutzt. Diese Signature Properties können beispielsweise den Zeit-punkt der Signaturerstellung oder eine Gerätenummer der Signatur-Hardware enthalten.

Eine Besonderheit an XML-Signaturen ist das Verwenden der Referenzen auf die eigentlichzu signierenden Daten. Diese werden durch das URI-Attribut adressiert und können entwederexterne Dateien oder Teile eines externen oder des aktuellen XML-Dokumentes referenzieren.

Die XML-Signaturen ermöglichen darüber hinaus die Aufnahme einer Angabe zur Semantikinnerhalb eines zusätzlichen Objektes. Im nachstehenden Beispiel aus [BBF+08] wird ein Zeit-stempel als zur Signatur gehörendes Metadatum aufgenommen, das den Zeitpunkt der Signaturnachvollziehbar macht.

<Object><SignatureProperties>

<SignatureProperty Id="AMadeUpTimeStamp" Target="#MySecondSignature"><timestamp xmlns="http://www.ietf.org/rfcXXXX.txt">

<date>19990914</date><time>14:34:34:34</time>

</timestamp></SignatureProperty>

</SignatureProperties></Object>

2.3.4 Pretty Good Privacy

Pretty Good Privacy (PGP) ist ein ursprünglich von Phil Zimmermann Anfang der NeunzigerJahre entwickeltes Programm, dessen Ziel die Bereitstellung von Kryptographie für jedermannwar. Zur Signaturerstellung verwendet das Programm den Digital Signature Algorithm des Di-gital Signature Standard (DSS) [Nat94]. Weitere Festlegungen zur Kodierung der Nachrichten-formate zum Austausch von PGP-Signaturen sind in den OpenPGP-Festlegungen [CDF+07] zufinden.

Diese definieren ein eigenes binäres Datenformat, das aus Datentypen sog. Pakete zusammen-setzt. Diese können signierte Daten, Schlüssel usw. enthalten. Die Signaturen werden wie im Fallvon PKCS#1 ebenfalls durch Verschlüsselung von Hashwerten erzeugt.

Am Beispiel von OpenPGP lässt sich der fließende Übergang zwischen Signatur und Zertifikataufzeigen. Wird eine Signatur über einen öffentlichen Signaturschlüssel erstellt, so kann die-ser Signatur in einer zusätzlichen Kennung (Typ-Feld) eine entsprechende Zertifikatssemantikzugeordnet werden.

There are a number of possible meanings for a signature, which arespecified in a signature type octet in any given signature.[...]These meanings are as follows:


0x00: Signature of a binary document.This means the signer owns it, created it, or certifies that ithas not been modified.

[...]0x11: Persona certification of a User ID and Public Key packet.

The issuer of this certification has not done any verificationof the claim that the owner of this key is the user IDspecified.

[...]0x13: Positive certification of a User ID and Public Key packet.

The issuer of this certification has done substantialverification of the claim of identity.

Neben den beiden zur Authentisierung von Dateien (einschließlich Information zur Kodierung)vorgesehenen Typen 0x00 und 0x01 sind einige Typen aufgeführt, die die Signaturen im Zusam-menhang mit der Weitergabe von Schlüsselmaterial Dritter verwenden. Hierbei wird der Signaturnicht nur eine spezielle Bedeutung zugewiesen, sondern auch die Qualität der bestätigten Aussa-ge klassifiziert.

Als Hash-Verfahren werden durch OpenPGP u. a. SHA-1 sowie die SHA-2-Familie unterstützt.Als PGP-Schlüssel werden DSA-Schlüssel mit einer Länge von bis zu 3072 Bit oder ein ElGamal-Schlüssel verwendet.

2.3.5 Portable Document Format

Das von der Firma Adobe entwickelte Portable Document Format (PDF), das im Jahr 2008 durchdie ISO standardisiert wurde [Int08], unterstützt seit der Version 1.3 digitale Signaturen innerhalbvon PDF-Dokumenten. Die Signaturen können sich dabei auf das gesamte Dokument (ohne denSignaturwert selbst) oder auf Teile des Dokumentes beziehen.

Die zur Aufnahme der Signaturen vorgesehenen Datenstrukturen enthalten neben den notwen-digen kryptographischen Elementen und Zeitangaben auch die Möglichkeit zur Angabe zusätz-licher Informationen. Diese sind als Freitext gestaltet und können z. B. die Kontaktadresse desSignaturerstellers enthalten. Ein Feld dient der Angabe einer Signaturbedeutung. Hier lassensich Inhalte wie „Ich stimme dem Inhalt zu”, „Ich habe den Inhalt zur Kenntnis genommen”oder „Ich genehmige den Inhalt” hinterlegen. Dieses als Signaturgrund (Reason) bezeichneteFeld kann dann durch die auswertende Applikation angezeigt werden und der Signatur damiteine Bedeutung zuordnen.

In der Version 1.5 wurde die PDF-Funktionalität noch um Signaturen zur gesicherten Festle-gung von Anwendungsrechten erweitert. Dabei werden die Rechte zum Drucken, Exportieren,Verändern etc. in einem durch eine Signatur geschützten Bereich festgelegt.

In der ETSI-Standard-Reihe PAdES [Eur09] werden Verfahren zur Erstellung von Signaturenüber PDF-Dokumente, Signaturen über Formulardaten in PDF-Dokumenten, der Einsatz vonZeitstempeln, Mehrfach-Signaturen und Signaturen zur Langzeitarchivierung von PDF-Dokumentenbeschrieben.

2.4 Digitale Zertifikate 27

2.3.6 S/MIME

Secure / Multipurpose Internet Mail Extensions (S/MIME) ist ein Standard zum Austausch digi-tal signierter und/oder verschlüsselter E-Mail. Er wurde ursprünglich von RSA Data Security Inc.entwickelt (damals als PKCS#7) veröffentlicht und in RFC 2315 aufgegriffen [Kal98]. Seit 2004werden die Formate zum Austausch verschlüsselter und/oder signierter E-Mail durch die Cryp-tographic Message Syntax (CMS) gemäß RFC 5652 [Hou09] und RFC 4853 [Hou07] festgelegt.Es wird durch eine große Zahl von E-Mail-Programmen bereitgestellt und ist im kommerziellenUmfeld die wichtigste Form der gesicherten elektronischen Kommunikation über E-Mail.

Die CMS bietet die Möglichkeit, die Signatur des eigentlichen Dokumentes noch durch sog.signierte Attribute zu ergänzen. Diese werden dadurch fest in die Signatur integriert und kön-nen dadurch zur Interpretation der Signatur beitragen. Beispiele für signierte Attribute sind derSignaturzeitpunkt, Verweise auf Signaturerstellerzertifikate, Verweise auf Sicherheitsrichtlinienund Sicherheitslabel, mit denen z. B. die Vertraulichkeitsstufe einer Information festgelegt wer-den kann [Hof99, Sch07, ets12].

2.4 Digitale Zertifikate

2.4.1 Zertifikatsbegriff

Ein Zertifikat (von lat. certificatum von lat. certus = sicher, gewiss, zuverlässig und facere =machen, errichten) ist ein Dokument, das die Zusicherung der Korrektheit eines Sachverhaltsenthält. Die Zusicherung wird vom Aussteller des Dokumentes unterschrieben und damit derenEchtheit nachgewiesen.

Ein Zertifikat hat die Aufgabe, dem Anwender die Prüfung des im Zertifikat genannten Sach-verhalts zu ersparen, indem dieser durch einen für den Anwender vertrauenswürdigen Drittenbestätigt wird.

Im Allgemeinen weisen Zertifikate gewisse Form- und Inhaltsmerkmale auf, die eine Erkennungdes Bestätigungscharakters des Dokumentes ermöglichen. So sind beispielsweise Urkunden beider Ausstellung von Zertifizierungen nach ISO 9001 durch entsprechende Überschriften undFormulierungen so gestaltet, dass die Bestätigungsabsicht der erklärenden Stelle (z. B. Dekra)klar erkennbar ist. Einleitende Sätze im textlichen Inhalt wie „Hiermit bestätigen wir ...” oder„Der Unterzeichnende garantiert die Richtigkeit ...” können ebenfalls ein Erkennungsmerkmalfür die Bestätigungsabsicht sein.

Da die Bestätigung durch einen Dritten nur dann sinnvoll einsetzbar ist, wenn der Dritte be-kannt und bzgl. des bestätigten Sachverhalts als kompetent und vertrauenswürdig angesehenwird, muss er zweifelsfrei identifiziert und die von ihm gemachte Aussage auch authentifiziertwerden. Um dies zu ermöglichen, enthalten Zertifikate i. d. R. Angaben zum Bestätiger, also demAussteller des Zertifikates, und entsprechende Echtheitsnachweise wie Siegel und Signaturen.Teilweise kann eine Ausstellerangabe entfallen, wenn aus dem Echtheitsnachweis der Aussteller


hervorgeht. Die Ausstellerangabe ist jedoch auch dann sinnvoll, wenn sie lediglich zur Unter-stützung der Auswahl der korrekten Prüfinformation dient (z. B. passende Unterschriften- oderStempelprobe).

2.4.2 Zertifikatsarten

Zertifikate lassen sich nach der Art der enthaltenen Zusicherungen klassifizieren. In der Informa-tionstechnik haben vor allem Schlüssel- und Attributszertifikate eine herausragende Bedeutung.Ein weiteres Anwendungsfeld von Zusicherungen sind Verfahren zur (verteilten) Verwaltung vonVertrauensbeziehungen und der Zugriffssteuerung. Diese im Englischen als Trust Managementbzw. Access Control bezeichneten Verfahren verfügen über ihre eigenen Zusicherungsarten undumfassen daher im o. g. Sinne ebenfalls eine Art Zertifizierung.

2.4.2.1 Schlüsselzertifikate

An erster Stelle sind die Schlüsselzertifikate (public key certificates) zu nennen, die auch als Iden-titätszertifikate bezeichnet werden. Diese haben die Aufgabe, einer Identität (Person, Institutionoder Kommunikationssystem wie Server u. ä.) einen öffentlichen Schlüssel zuzuordnen. Diesgeschieht durch Aufnahme eines möglichst eindeutigen Bezeichners der Identität des Schlüssel-inhabers und des öffentlichen Schlüssels in die Bestätigung. Ein solches Zertifikat soll aussagen,dass das im Zertifikat genannte Subjekt alleinige Kontrolle über den privaten Schlüssel hat, derzu dem im Zertifikat genannten öffentlichen Schlüssel gehört. Damit weist ein Zertifikat das Vor-liegen der Voraussetzungen zur Erstellung von fortgeschrittenen oder qualifizierten Signaturenentsprechend der Abschnitte 2.2.2.5 bzw. 2.2.2.6 nach.

Die Kernaussage eines Schlüsselzertifikates lässt sich durch ein zweistelliges Prädikat darstel-len, das über eine Relation über Identitäten und Schlüssel definiert ist. Dabei wird der jeweiligeEinsatzzweck des Schlüssels unterschieden:

PKσ(E,K1) K1 ist ein Signaturschlüssel von EPKϕ(E,K2) K2 ist ein Verschlüsselungsschlüssel von EPKδ(E,K3) K3 ist ein Schlüsselaushandlungsschlüssel von E

Daneben enthalten Schlüsselzertifikate eine Reihe weiterer Metadaten, auf die anhand eines Bei-spiels in Abschnitt 2.5 eingegangen wird.

Eine Abwandlung von Schlüsselzertifikaten enthält statt der Identität des Schlüsselinhabers le-diglich ein Pseudonym. Die Zuordnung zwischen Pseudonym und wahrer Identität ist i. d. R. nurdem Zertifikatsaussteller bekannt. Ein Anwendungsfall eines Pseudonymzertifikates ist z. B. einZertifikat über einen Signaturschlüssel, der für die Rechnungserstellung im Namen eines Unter-nehmens verwendet werden soll. Die Identität des Mitarbeiters, der den Schlüssel kontrolliert,wird durch ein Pseudonym wie z. B. CN=Rechnungsstelle, O=Firma XYZ ersetzt.

2.5 Schlüsselzertifikate am Beispiel des X.509-Standards 29

2.4.2.2 Attributszertifikate

Die zweite wichtige Gruppe wird durch die Attributszertifikate gebildet. Diese ordnen einer Iden-tität statt eines Schlüssels eine Eigenschaft (Attribut) zu. Das können zum einen Bestätigungenvon mit dem Subjekt fest verbundenen Eigenschaften sein, wie Zulassungen zu einer Berufs-gruppe, Volljährigkeit, etc. Zum anderen können in einem Zertifikat dem Subjekt auch Rechteund/oder Rollen zugeordnet werden. Ein typischer Anwendungsfall für Attribute ist das Ver-knüpfen von Privilegien wie Zugriffsrechte u. ä. mit einem berechtigten Subjekt. Diese spezielleForm der Attributszertifikate wird als Berechtigungs- oder Delegationszertifikat bezeichnet.

Das Subjekt kann direkt durch Angaben eines Namens oder, im Fall von digitalen Subjekten(z. B. Programmcode), durch einen Objekt-Hashwert bestimmt werden. Eine zweite Möglichkeitbesteht in der Referenzierung eines Schlüsselzertifikates, so dass die Attribute für den Halterdes Schlüsselzertifikates gelten. Ein spezieller Fall eines Objekt-Hashwertes ist der Hash einesöffentlichen Schlüssels, bei dem dann wiederum dem Besitzer des Schlüssels die Attribute zuge-ordnet werden.

Der RFC 5755 [FHT10] spezifiziert Attributszertifikate, die auf Basis des X.509-Standards bzw.des RFC 5280 [CSF+08] die Zusicherung von beispielsweise Rollen, Gruppenzugehörigkeiten,Sicherheitsfreigaben u. a. ermöglichen.

2.4.2.3 Mischformen

Neben der Reinform der oben genannten Zertifikatsarten existieren auch Mischformen. Hier-bei werden in Schlüsselzertifikate zusätzlich Attributsangaben in Form von Erweiterungen (engl.extensions) aufgenommen. Der Common-PKI-Standard [TT09] definiert beispielsweise Erweite-rungen wie Berufszulassung (admission) und Vertretungsberechtigungen (procuration), die wahl-weise als Attributszertifikat oder als Extension im Schlüsselzertifikat verwendet werden können.

2.5 Schlüsselzertifikate am Beispiel des X.509-Standards

Die International Telecommunication Union (ITU-T) hat im Rahmen ihrer X.500-Serie, die For-mate und Mechanismen für Verzeichnisdienste bereitstellt, auch einen Standard X.509 für Zertifi-kate erstellt. X.509-Zertifikate sind derzeit die bedeutendsten Zertifikate, da mit ihnen sehr vieleSicherheitsmechanismen parametrisiert werden. Wichtige Vertreter sind z. B. die Verschlüsse-lungsmechanismen der WWW-Browser (Secure Socket Layer) und Secure/Multipurpose Inter-net Mail Extensions [DHR+98, DHRW98], die beide auf X.509-Zertifikaten aufsetzen und damitdie beiden wichtigsten Kommunikationsanwendungen WWW und E-Mail abdecken.

Das Ziel der X.509-Festlegungen ist es, ein Rahmenwerk für den sicheren Austausch von Infor-mationen über die Zuordnung öffentlicher Schlüssel oder Attributen zu Personen oder Institutio-nen bereitzustellen und so Authentisierungs- und Zugriffssteuermechanismen zu unterstützen.


Feldbezeichner Bedeutung

Version gibt den Typ des Zertifikates und damit die möglicherweiseenthaltenen Felder an

Seriennummer Eindeutige Nummer innerhalb aller vom Aussteller erstell-ten Zertifikate

Algorithmenkennung Signatur- und Hashalgorithmen, die für die Erstellung derdigitalen Unterschrift des Ausstellers verwendet wurden

Ausstellerkennung Name der ausstellenden Instanz

Subjektkennung Name des Zertifikatshalters (Subjekt)

Öffentlicher Schlüssel der dem Subjekt zugeordnete öffentliche Schlüssel

Gültigkeitsintervall Zeitangaben nicht vor und nicht nach, die die Gültigkeits-dauer des Zertifikates angeben

Erweiterungen Felder für zusätzliche Informationen

Tabelle 2.1: Aufbau eines Schlüsselzertifikates nach X.509

2.5.1 Zertifikatsinhalt

X.509-Zertifikate enthalten in der Version 3 die in Tabelle 2.1 aufgeführten Angaben.

Neben Subjekt- und Schlüsselfeldern, die den eigentlichen Kern der Zusicherung des ID-Zertifikatesausmachen, wird der Aussteller genannt. Diese Angabe dient einerseits zur Bewertung der Glaub-würdigkeit des Zertifikates und zum Auffinden des benötigten Prüfschlüssels für das Zertifikat.

Die Algorithmenkennung wird für die technische Durchführung der Signaturprüfung benötigt.Sie beschreibt sowohl die Art des Schlüssels (z. B. RSA oder ECC) und den verwendeten Hash-Algorithmus (z. B. SHA-256).

Das Gültigkeitsintervall ist eine Meta-Information, die die Dauer der Verwendbarkeit der Aussa-ge über die Zuordnung von Identität und Schlüssel einschränkt.

Zusätzlich können noch optionale eindeutige Kennungen für Aussteller und Subjekt in Formvon Bitstrings aufgenommen werden, falls die entsprechenden Angaben der Pflichtfelder dieseEindeutigkeit nicht gewährleisten.

2.5.2 Erweiterungsfelder

Der X.509-Standard sieht eine Reihe von Erweiterungen vor, die dazu dienen, die Semantik einesZertifikates genauer festzulegen. Daneben ist es auch möglich, beliebige anwendungsspezifischeErweiterungen zu definieren.

Die standardisierten Erweiterungen enthalten unter anderem


q Informationen über die Zertifizierungsrichtlinie

q Einschränkungen zur möglichen Verwendung des Schlüssels

q Bezeichner für den Schlüssel

q zusätzliche Information über Aussteller und Subjekt (z. B. alternative Namensformen, E-Mail-Adressen etc. )

q Einschränkungen der Zertifikatsketten

q Angaben über Ausgabestellen für Revokationslisten

Erweiterungsfelder können als kritisch markiert werden. In diesem Fall muss eine Anwendungden Feldinhalt bei der Auswertung des Zertifikats interpretieren können, anderenfalls muss siedas Zertifikat als ungültig verwerfen.

2.5.3 Kodierung der X.509-Zertifikate

Bei der Spezifikation von X.509-Zertifikaten wurde u. a. großer Wert auf eine platzsparende Ko-dierung gelegt. Daher sind die Datenfelder gemäß der Distinguished Encoding Rules (DER)entsprechend ihrer in ASN.1 vorliegenden Definition kodiert.

Diese Kodierung ist redundanzarm und so enthalten X.509-Zertifikate neben den eigentlichenFeldwerten kaum Informationen, die direkt etwas über die Bedeutung der Felder aussagen. Le-diglich die Feldtypen sind eindeutig kodiert und können unter Verwendung des Standards inter-pretiert werden. Es wird bei ASN.1 eine sog. Object ID (OID) angegeben, um den nachfolgendenDatentyp zu charakterisieren. Für eine Adresse zum Abruf von Sperrlisten ist dies beispielsweisedie OID id-ce-CRLDistributionPoints mit dem Wert 2.5.29.31.

Bei der Dekodierung für menschliche Anwender kann die Bedeutung demzufolge nicht unmittel-bar aus dem Zertifikat entnommen werden. Sie ist fest in den Dekodier- und Anzeigeprogrammenhinterlegt, da sie lediglich als allgemeiner beschreibender Text im Standard vorliegt. Beispiels-weise heißt es für das Feld CRL distribution points:

This field identifies the CRL distribution point or points to which a certificate usershould refer to ascertain if the certificate has been revoked. A certificate user canobtain a CRL from an applicable distribution point or it may be able to obtain acurrent complete CRL from the authority directory entry.

Mittels eines Programms wie openssl wird der Feldinhalt mit entsprechendem Label angezeigt.


X509v3 CRL Distribution Points:Full Name:URI:ldap://ldap.nrca-ds.de:389/CN=CRL,

O=Bundesnetzagentur,C=DE,dc=ldap,dc=nrca-ds,dc=de?certificateRevocationList;binary?base?objectClass=cRLDistributionPoint

Alle weiteren Informationen über die Bedeutung müssen dem Standard oder der Sekundärlitera-tur entnommen werden.

2.5.4 Zertifizierungsrichtlinien

Eine weitere Festlegung zur Bedeutung der Zertifikatsinhalte sind sog. Zertifizierungsrichtlinien(certificate policies). Sie definieren Verpflichtungen hinsichtlich der eingesetzten Verfahrenswei-sen, die Aussteller, Inhaber und Anwender von Zertifikaten eingehen, wenn ein Zertifikat durcheine CA ausgestellt wird, die sich auf diese Richtlinien beruft bzw. ein solches Zertifikat ein-gesetzt oder akzeptiert wird. Der X.509-Standard und die zugehörigen RFCs gehen nicht aufden Inhalt von Richtlinien ein und benennen lediglich den Mechanismus der Bindung: durch dasAkzeptieren des öffentlichen Schlüssels der Root-CA als Vertrauensanker oder durch Verwen-dung eines Zertifikates mit expliziter Policy-Referenz akzeptieren die Anwender die jeweiligenZertifizierungsrichtlinien [CFS+03].

Die Richtlinien können sowohl den Inhabern von Zertifikaten Verpflichtungen auferlegen, alsauch die Anwendungsbereiche der Zertifikate bzw. der darin enthaltenen Schlüssel einschrän-ken. Darüber hinaus kann auch der Kreis der möglichen Zertifikatsanwender vorgegeben werden.Hiervon wird insbesondere bei qualifizierten Zertifikaten Gebrauch gemacht, wenn Zertifikats-inhaber vertraglich an besondere Sorgfaltspflichten beim Umgang mit dem Schlüsselmaterialverpflichtet werden.

2.5.5 Gültigkeitsprüfung

Bei der Zertifizierung öffentlicher Schlüssel werden die Zertifikate der Endbenutzer (Anwender-zertifikate) durch einen Aussteller (CA) bereitgestellt. Der Schlüssel des Ausstellers wird i. d. R.wiederum durch mindestens eine weitere CA bestätigt. Die letzte Ausstellerinstanz in der Kettevon Ausstellerzertifikaten wird als Wurzel bezeichnet und durch ein selbstausgestelltes Zertifikatgebildet, bei dem Aussteller und Subjekt identisch sind und das selbstsigniert ist. Bei selbstsi-gnierten Zertifikaten gehört der öffentliche Schlüssel im Zertifikat zum privaten Schlüssel, mitdem das Zertifikat signiert wurde. Ein selbstsigniertes Zertifikat kann nicht mit einem weiterengeprüft werden und das Vertrauen in dieses Zertifikat muss über einen anderen Weg etabliertwerden.

Die Wurzelinstanz stellt häufig auch zusätzliche Zertifikate für Schlüssel aus, die zur Signaturvon Sperrlisten oder Online-Auskünften zum Zertifikatsstatus benötigt werden (vgl. Abbildung2.6).


Wurzel-Zertifikat

Aussteller-Zertifikat

End-Entity-Zertifikat

signiert

signiert

signiert

CRL-Signer OCSP-Signer

signiert signiert

Abbildung 2.6: Beispiel einer Zertifikatshierarchie

Ein Zertifikat eines Ausstellers für einen anderen Aussteller wird als Kreuzzertifikat (cross certi-ficate) bezeichnet. Diese können sowohl hierarchisch als auch auf gleicher Ebene zur Anerken-nung einer parallelen CA-Kette verwendet werden [Tur00, CSF+08].

Um ein Anwenderzertifikat zu überprüfen, muss eine Kette von Zertifikaten vorliegen, bei derjeweils eine Ebene die nächste zertifiziert, d. h. für jede CA außer der obersten Root-CA liegt einvon einer hierarchisch übergeordneten CA ausgestelltes Zertifikat vor.

Bei der Überprüfung wird zunächst die zeitliche Gültigkeit der Zertifikate und die korrekte Ver-kettung von Aussteller und Subjektnamen überprüft. Gegebenenfalls werden die Vorgaben zu denZertifizierungsrichtlinien auf Eignung für den jeweiligen Anwendungsfall geprüft. Die jeweili-gen Signaturen müssen durch die von den übergeordneten Instanzen zertifizierten öffentlichenSchlüsseln prüfbar sein. Es werden die Berechtigungen zur Ausstellung von Zertifikaten anhandder erlaubten und ausgeschlossenen Namensräume bestimmt. Eine detaillierte Darstellung zurBildung von Zertifikatspfaden zur Prüfung gibt [CDH+05].

Für die verwendeten Zertifikate können online zusätzlich noch aktuelle Sperrlisten geholt odereine Abfrage an einen im Zertifikat angegebenen Validierungsdienst gesendet werden, um zuprüfen, ob das Zertifikat nicht zwischenzeitlich gesperrt wurde.

Das letzte Zertifikat einer Kette ist nicht mehr über den beschriebenen Mechanismus zu prüfen.Es wird daher auch als Vertrauensanker bezeichnet, d. h. der Anwender muss bei der Zertifikats-prüfung auf die Richtigkeit dieses Wurzelzertifikates vertrauen.

Da sich der Prüfprozess letztlich auf die Korrektheit des letzten Zertifikates einer Kette abstützt,kommt diesem Vertrauensanker eine besondere Bedeutung zu. Es ist daher beispielsweise nicht


möglich, den Vertrauensanker über den gleichen (ungeschützten) Kommunikationsweg zur Ver-fügung zu stellen, über den die signierte Information übertragen werden kann. Ein übliches Ver-fahren zur Verteilung ist die Auslieferung innerhalb von Betriebssystemen oder Progammpa-keten. Dabei muss der Anwender dem Hersteller oder Distributor seines Betriebssystems bzw.Programmpaketes vertrauen oder einen Vergleich eines Hashwertes (sog. Fingerprint-Vergleich)mit dem Herausgeber des Root-Zertifikates durchführen.

2.5.6 Rückrufmechanismen

Ein Grundproblem der Ausgabe von Zusicherungen in Form von Zertifikaten ist die nachhalti-ge Sicherstellung der Gültigkeit der zugesicherten Information. Ein Zertifikat sichert einen be-stimmten Sachverhalt für die im Zertifikat enthaltene Gültigkeitsdauer zu. Teilweise ist mit derZusicherung auch eine gewisse Haftung des Ausstellers verbunden (z. B. Warranty CertificateExtension nach [LPS05]).

2.5.6.1 Zertifikatssperrung

Ändert sich der zugesicherte Sachverhalt vor Ablauf der Gültigkeitsdauer oder wird ein kryp-tographischer Schutzmechanismus unterlaufen (z. B. durch Aufdeckung des privaten Signatur-schlüssels), so muss die Zusicherung zurückgenommen werden. Es liegt in der Regel sowohlim Interesse des Ausstellers als auch des Anwenders, dass die Gültigkeit eines Zertifikates zumZeitpunkt der Anwendung sichergestellt werden kann.

Zu den Gründen für das Ungültigwerden eines Schlüsselzertifikates zählen u. a. die Änderungdes Inhalts von Zertifikatsbestandteilen (Namen, Schlüssel, Attribute usw.), der Wegfall des Zer-tifizierungsgrundes (z. B. Arbeitgeberwechsel des Zertifikatshalters) oder der Verlust des Schlüs-sels.

Wird eine Zertifikatsaussage ungültig, so muss dieser Umstand möglichst schnell, effizient undzuverlässig an die potenziellen Anwender des Zertifikates übermittelt oder ihnen diese Informati-on zumindest zugänglich gemacht werden. Der Vorgang der Zurücknahme ungültiger Zertifikatewird als Zertfikatssperrung oder als Zertifikatsrückruf (von engl. revocation) bezeichnet. Hierzugibt es eine Reihe von Mechanismen.

In [Mye98] werden vier Klassen von Mechanismen unterschieden: Rückruflisten (Certificate Re-vocation List, CRL), Online-Abfragen, vertrauenswürdige Verzeichnisdienste und Zertifikate mitkurzer Lebensdauer. Im Bereich der X.509-Zertifikate sind vor allem die beiden erstgenanntenMechanismen von Bedeutung.

2.5.6.2 Rückruflisten

Das Grundprinzip der Rückrufliste (Certificate Revocation List, CRL) beruht auf der Veröffent-lichung einer Liste von Zertifikatsseriennummern einer CA, die vor dem Ablauf ihrer Gültigkeit

2.6 Standardisierte Zusicherungen und Zertifikate 35

gesperrt wurden. Die Liste selbst enthält einen Zeitstempel, da sie i. A. lediglich eine Moment-aufnahme ist, und wird vom Aussteller digital signiert.

Zu jedem gesperrten Zertifikat wird in der Liste der Sperrzeitpunkt und optional auch der bei derSperrung genannte Sperrgrund bekannt gegeben.

2.5.6.3 Direkte Abfrage des Zertifikatsstatus

Durch die IETF wurde in [MAM+99] ein Mechanismus spezifiziert, der die direkte Abfrage desStatus eines oder mehrerer explizit genannter Zertifikate ermöglicht. Im Gegensatz zu den Lö-sungen auf Basis von CRLs wird die signierte Auskunft erst zum Zeitpunkt der Abfrage erstelltund kann damit eine Auskunft mit der maximal möglichen Aktualität bereitstellen.

Dieses Online Certificate Status Protocol (OCSP) besteht aus einer einfachen Anfrage (request),in der der Zertifikatsanwender dem sog. OCSP-Responder eine oder mehrere Zertifikatsiden-titäten (bestehend aus einem Hashwert über je den CA-Namen und den CA-Schlüssel sowiedie Seriennummern der Zertifikate) und optionale Anfrageparameter wie einen Zufallswert zumSchutz vor Angriffen durch Wiedereinspielen alter Nachrichten oder die gewünschten Antwort-typen übermittelt.

Im OCSP-Responder sind in Form einer Datenbank alle Zustände der Zertifikate einer zugeord-neten CA hinterlegt, so dass dieser eine Antwort generieren kann. Die Antwort ist in der Regeldigital signiert. Der dafür verwendete Schlüssel muss entweder der zugeordneten CA, einemallgemein vertrauenswürdigen OCSP-Dienst oder einer durch die CA mit dem OCSP-Dienstbeauftragten Instanz gehören. Zu jedem angefragten Zertifikat enthält die Antwort eine Status-information aus den drei Möglichkeiten „good”, „revoked” und „unknown”. Bei Vorliegen vonSperrinformationen kann es sich um eine vorübergehende Sperrung (on-hold) oder den endgül-tigen Widerruf des Zertifikates handeln.

2.6 Standardisierte Zusicherungen und Zertifikate

Im vorangehenden Abschnitt wurde das Prinzip einer kryptographisch geschützten Zusicherungam Beispiel der Zertifikate nach X.509 ausführlich vorgestellt. X.509-Zertifikate decken jedochnur einen speziellen Bereich der Zusicherungen ab. Neben diesen Zertifikaten gibt es noch wei-tere Formen von Zertifizierungen und Zusicherungen, auf die im Folgenden eingegangen wird.

Neben weiteren Formen von Schlüsselzertifikaten werden insbesondere Mechanismen aus demBereich Attributszertifikate vorgestellt, die im Bereich von Autorisierungs- und sog. Trust-Ma-nagement-Systemen verwendet werden. Bei diesen Systemen sind naturgemäß Zusicherungen(assertions) und teilweise die Weitergabe von Rechten (delegation) ein wichtiger Bestandteil.Diese kommen den in Kapitel 1 geforderten Möglichkeiten für die Bestätigung von Sachverhal-ten durch ihr breiteres Anwendungsfeld näher als die reinen Schlüsselzertifikate.


2.6.1 Pretty Good Privacy

In PGP-Zertifikaten werden Kennungen in Form von E-Mail-Adressen öffentlichen Schlüsseln(i. d. R. RSA) zugeordnet. Im Gegensatz zu der in X.509 vorgesehenen zentralen Key-Manage-ment-Infrastruktur mit Zertifizierungsstellen (CAs) wird in der „Pretty Good Privacy”-Welt aufdie Zertifizierung durch andere Schlüsselinhaber vertraut. Auf diese Weise entsteht ein so ge-nanntes Web of Trust, also ein Netzwerk sich gegenseitig vertrauender Benutzer, die wiederumandere in diese Gemeinschaft einbinden können.

2.6.2 SPKI/SDSI

Im RFC 2693 der IETF [EFL+99] stellt eine Autorengruppe um C. Ellison eine spezielle Vari-ante der Anwendung von Zertifikaten unter der Bezeichnung (Simple Public Key Infrastructure,SPKI) vor. Kerngedanke dabei ist die Verwendung der öffentlichen Schlüssel anstelle von Be-nutzernamen als Kennungen. Die zugehörige Theorie wird in [HK00] formal dargestellt.

Während die in Abschnitt 2.4.2.2 vorgestellten Attributszertifikate einer Identität ein Attributzuordnen und über die Identität und ein Schlüsselzertifikat wiederum ein für die Authentisierunggeeigneter Schlüssel ermittelt werden kann, wird dieser Ansatz von SPKI umgekehrt.

SPKI verfolgt einen schlüsselzentrischen Ansatz. Hierbei werden Attribute unmittelbar kryp-tographischen Schlüsseln zugeordnet. Dadurch vereinfacht sich die auf Attributen beruhendeAutorisierungsprüfung im Vergleich zu dem oben beschriebenen Ansatz.

Bei Überprüfung der berechtigten Nutzung wird nur die Tatsache geprüft, ob die das Zertifikatvorweisende Instanz den zugehörigen privaten Schlüssel besitzt. Die Kenntnis des Identitäts-zertifikates ist an dieser Stelle nicht mehr notwendig. Sogar die Kenntnis der zum öffentlichenSchlüssel gehörenden Identität ist für den Prüfenden nicht mehr notwendig. Voraussetzung isthierbei jedoch die Annahme der korrekten Attributierung durch den Aussteller des Attributszerti-fikates. Zur Kodierung der Zertifikate werden die von LISP bekannten S-Expressions verwendet.SPKI umfasst ein Delegationskonzept, bei dem jede beteiligte Instanz Rechte delegieren kann,sofern in einem Berechtigungszertifikat das propagate-Feld enthalten ist.

2.6.3 Kerberos

Kerberos ist ein am Massachusetts Institute of Technology (MIT) entwickeltes Protokoll sowieeine zugehörige Dienstarchitektur auf Basis eines zentralen Servers. Kerberos stellt einen Single-Sign-On-Dienst für vertrauenswürdige Systeme mit unsicheren Kommunikationsverbindungenbereit.

Der zentrale Server authentifiziert einen Dienstnutzer und stellt für ihn ein sog. Ticket für dieNutzung eines Dienstes aus. Der Vermittler agiert als vertrauenswürdiger Dritter aus Sicht desDienstes und des Nutzers. Zum Einsatz kommt das Kerberos-Protokoll, das in seiner aktuellenVersion 5 im RFC 4120 [NYHR05] definiert ist und auf [NT94, KN93] beruht. Es ermöglicht


den kryptographischen Schutz der ausgetauschten Authentisierungsdaten auf Basis symmetri-scher Schlüssel und kann durch zusätzliche Maßnahmen auf asymmetrische Verfahren erweitertwerden [Dow03, ZT06]. Die Instanz des Vermittlers verteilt sich auf zwei Dienste, den Authenti-sierungsdienst (engl. authentication service (AS)) und den Ticket-Erstellungsdienst (engl. ticketgranting service (TGS)).

Authentication Server

(AS)

Ticket Granting Server

(TGS)

Anwendungs-Server

DienstnutzerAS_REQ

AS_REP

TGS_REQ

TGS_REPAP_REQ AP_REP

1

2

3

Abbildung 2.7: 3-Phasen-Architektur von Kerberos

Phase 1 Der Anwender leitet mit AS_REQ eine Authentisierung ein, die mit einer AS_REP-Nachricht beantwortet wird. Die Antwort enthält ein sog. Ticket Granting Ticket (TGT).

Phase 2 Mittels des TGT kann der Anwender vom TGS weitere Tickets zur Nutzung mit denAnwendungsservern anfordern (Nachrichten TGS_REQ und TGS_REP).

Phase 3 Das erhaltene und für den Zielserver verschlüsselte Ticket übermittelt der Anwender anden gewünschten Dienst und erhält damit Zugriff auf diesen.

Die Tickets die in Phase 2 ausgestellt und in 3 angewendet werden, sind Zusicherungen, mitdenen der TGS dem zu nutzenden Dienst bestätigt, dass der Nutzer, für den dieses Ticket er-stellt wird, über die notwendigen Berechtigungen verfügt. Es enthält einen Sitzungsschlüssel,der für die Sitzung zwischen Nutzer und Dienst verwendet wird. Das Ticket wird auch als Zerti-fikat bezeichnet [NT94] und enthält neben den Kennungen des Anwenders und des gewünschtenDienstes auch Angaben von welchen IP-Adressen aus das Ticket genutzt werden darf, Beginn derGültigkeit und Lebensdauer sowie einen Sitzungsschlüssel. Das Ticket gilt als ausreichende Au-torisierung zur Dienstnutzung. Im Feld authorization-data können zusätzlich Einschränkungenaufgenommen werden, die die Autorisierung weiter einschränken.

Die Bestätigung über die Client-Autorisierung, die der Server erhält, ist lediglich implizit undberuht auf der Verteilung des Sitzungsschlüssels. Eine Interpretation des Ticket-Inhaltes im Sinneeiner Aussage wird nicht vorgenommen.


2.6.4 SAML

Die Security Assertion Markup Language (SAML) ist ein XML-Rahmenwerk, das es ermög-licht, Aussagen für die Authentisierung und Autorisierung von Kommunikationspartnern auszu-drücken. Der SAML-Standard [CKPE05] wurde vom Security Services Technical Committee derOrganization for the Advancement of Structured Information Standards (OASIS) herausgegeben,die von einer großen Zahl von Industrieunternehmen unterstützt wird.

Ziel des Standards ist die Unterstützung von Web-basierten Single-Sign-On-Lösungen. Dazuwerden geeignete Kodierungsformate und Protokolle definiert, mit denen verschiedene Artenvon Zusicherungen dargestellt und kommuniziert werden können. Dabei werden unterschieden

q Authentication Statements, die eine Aussage über die Art und den Ort der Authentisierungeines Subjektes bereitstellen

q Attribute Statements, die erweiterte Informationen zu einem Subjekt angeben

q Authorization Decision Statements zur Zuordnung von Rechten zu einem Subjekt

Es besteht darüber hinaus im Rahmen von SAML die Möglichkeit, zusätzliche Erweiterungenzu definieren, mit denen andere Informationen ausgedrückt werden.

Der Standard definiert ein Challenge-Response-Protokoll, mit dem Anfragen in SAML übertra-gen werden können. Über sog. Bindings wird die Abbildung der Kommunikationsabläufe aufKommunikationsprotokolle wie HTTP oder SOAP festgelegt.

Zusicherungen (assertion-Tag) in SAML müssen eine Reihe von Informationen wie Versions-nummer, Ausstellername und Ausstellungszeitpunkt enthalten. Als weitere Informationen kön-nen zusätzliche Bedingungen und Hinweise in der Zusicherung enthalten sein. Die Bedingungen(Condition) müssen bei der Auswertung berücksichtigt werden und können Einschränkun-gen zeitlicher Art oder der möglichen Empfänger enthalten. Weitere Hinweise z. B. auf Belegefür die Zusicherungen oder auf Verteilpunkte von erneuerten Zusicherungen können in einemAdvice-Element angegeben werden, dessen Auswertung optional ist.

Die Art der eigentlichen Zusicherung kann durch Auswahl eines oder mehrerer Elemente ausden Erweiterungen bzw. bereits standardisierten Zusicherungen ausgedrückt werden. Die vorde-finierten Typen sind die bereits oben aufgeführten Aussagen zu Authentisierung, Attributen undAutorisierungsentscheidungen. Als Erweiterungen stehen Aussage (Statement) und subjekt-bezogene Aussage (SubjectStatement) zur Verfügung.

Die drei vordefinierten Zusicherungen des SAML-Standards sind vom SubjectStatement-Typ abgeleitet und sind daher Subjekt-zentrisch.

Mit einer Authentisierungszusicherung wird durch die ausstellende Instanz bestätigt, dass das re-ferenzierte Subjekt zum angegebenen Zeitpunkt mit der genannten Methode authentifiziert wur-de. Es ist möglich, die IP-Adresse und den Domain-Namen sowie eine Instanz anzugeben, dieweitere Informationen über das Subjekt bereitstellen kann.


Bei der Zusicherung eines Attributes werden Attribute in Form einer Zeichenkette benannt, diedem Subjekt zugeordnet werden können. Zusätzlich werden ein Namensraum und ein darin ent-haltener Attributsname angegeben und damit implizit die Semantik des Attributs festgelegt.

Die Zusicherung einer Autorisierungsentscheidung gibt an, ob einem Subjekt der Zugriff auf ei-ne bestimmte Ressource gewährt wird. Die Ressource wird durch einen URI und die gewünschteAktion durch eine Zeichenkette und einen relevanten Namensraum spezifiziert. Es können dar-über hinaus in einem Evidence-Feld die der Entscheidung zugrunde liegenden Zusicherungenangegeben oder referenziert werden.

2.6.5 XACML

Die ebenfalls vom OASIS-Konsortium entworfene eXtensible Access Control Markup Language(XACML) in der Version 2.0 definiert eine auf XML basierende Syntax zur Beschreibung vonZugriffsrichtlinien (access control policies) sowie ein Schema für die Abfrage von Zugriffsricht-linien [Mos05].

Neben vordefinierten Datentypen und Vergleichsoperationen gibt es auch die Möglichkeit, dieSprache durch Erweiterungen zu ergänzen. XACML definiert mit Hilfe von XML Baumstruk-turen, bei denen die Bäume für Zugriffsziele einer Richtlinie stehen und die Blätter Regeln fürZugriffsentscheidungen aus der Menge „Deny“, „Permit“, „NotApplicable“, „Indeterminate“ re-präsentieren. Richtlinien und Mengen von Richtlinien werden grundsätzlich für ein Zugriffszieldefiniert.

In der aktuell in Bearbeitung befindlichen Version 3.0 [PL10] werden zusätzlich noch Dele-gationsmechanismen eingeführt. Hierbei werden die Rechte zur Delegation streng von den zudelegierenden Zugriffsrechten getrennt und in einer eigenen Policy ausgedrückt.

Die Ausdrucksmöglichkeiten von XACML sind wesentlich umfassender als die von SAML. Diezentralen Zusicherungen in XACML sind die Zugriffsrichtlinien, mit denen ein Policy DecisionPoint (PDP) parametrisiert werden kann, um den Zugriff auf eine Ressource zu steuern. In denPolicies können verschiedene Angaben zum Anfragenden, zum eingesetzten Authentifizierungs-verfahren, zu verschiedenen Ereignis-Zeiten usw. mit anderen Daten als Parameter für Funk-tionen dienen. Beispiele für solche Funktionen sind string-equal, integer-add, double-divide,date-add-year MonthDuration und string-is-in.

Dadurch lassen sich innerhalb der Policies Algorithmen zur Bestimmung der Zugriffsentschei-dung definieren.

2.6.6 PERMIS

PrivilEge and Role Management Infrastructure Standards validation (PERMIS) ist ein Systemzur Generierung, Verwaltung und Prüfung von Benutzerberechtigungen auf Basis des Modellsder rollenbasierten Zugriffssteuerung (Role Based Access Control, RBAC), wie sie von Ferraio-lo und Kuhn beschrieben wurde [FK92]. Die zugrunde liegende Architektur wird in [COB03,


CO04] beschrieben und setzt auf der Privilege Management Infrastructure (PMI) des X.509-Standards [IT05] auf. Die dort eingeführten Mechanismen werden durch Permis mit einer XML-basierten Policy-Sprache erweitert, die zur Definition und Vergabe von Berechtigungen einge-setzt wird.

Die XML-Strukturen ermöglichen die Definitionen von Rollen, denen wiederum erlaubte Aktio-nen in Bezug auf Zielobjekte zugeordnet werden können.

2.6.7 SecPAL

Security Policy Assertion Language (SecPAL) ist eine auf einfachen Konstrukten basierendeBeschreibungssprache für Sicherheitsrichtlinien und Autorisierungsabfragen, die nahe an einernatürlichen Sprachdarstellung liegt [BFG07, BFG10]. Die Sicherheitsrichtlinien können mit Va-riablen entworfen werden. Im Rahmen von Autorisierungsbestätigungen werden diese Varia-blen entsprechend vorliegender Autorisierungen mit konkreten Werten belegt. Beim Entwurfvon SecPAL wurde Wert auf eine verständliche Darstellung gelegt, so dass es neben der in XMLkodierten Form auch noch eine Darstellung nahe an natürlicher Sprache gibt. Ein Beispiel einerAutorisierung in Anlehnung an [BFG07] lautet

FileServer says STS can say∞ x can execute y from t1 till t2 if t2− t1 ≤ 8 hours.

Dieser Ausdruck besagt, dass die Instanz FileServer der Instanz STS das weiter delegierbareRecht vergibt, beliebigen weiteren Instanzen (dargestellt durch x) das Recht zur Ausführung derRessource y für Zeitintervalle kleiner als 8 Stunden einzuräumen.

Zusicherungen in SecPal können mit einer zeitlichen Beschränkung ihrer Gültigkeit versehenwerden und es können Widerrufe von Zusicherungen formuliert werden.

Es besteht die Möglichkeit, Rechte zu delegieren. Dabei können die Prinzipien der diskreten Zu-griffssteuerung (Discretionary Access Control, DAC), der erzwungenen Zugriffssteuerung (Man-datory Access Control, MAC), von hierarchischen Rollenmodellen u. a. berücksichtigt werden.Wie auch die Zusicherungen können Delegationen mit zeitlichen und weiteren Beschränkungenversehen werden.

Die Ausdrucksstärke von SecPAL ist auf den Anwendungsfall der (delegierten) Zugriffsrech-te beschränkt, kann jedoch bezüglich der zugesicherten Rechte z. B. durch Definition weitererparametrisierter Ausdrücke erweitert werden.

2.6.8 Ponder

Ponder [DDLS00] ist eine deklarative Sprache zur Formulierung von Sicherheitsrichtlinien inverteilten Systemen und ermöglicht neben der Definition von Zugriffsregeln und Autorisierungenauch die Beschreibung von Verpflichtungen (z. B. die Forderung der Anwendung einer bestimm-ten Dienstfunktion auf Zielobjekte) und Verbote (i. S. von negativen Autorisierungen). Es ist in


Ponder möglich, Regeln zu delegieren und durch zusätzliche Beschränkungen wie beispielswei-se Zeiten einzuschränken. Desweiteren bietet Ponder die Möglichkeit, Regeln in Gruppen zu-sammenzufassen sowie die Verträglichkeit von Regeln zueinander zu definieren und bestimmteKombinationen auszuschließen.

Die Sprache ist über EBNF-Syntax definiert und verwendet teilweise Elemente der Object Cons-traint Language version 3 (OCL) syntax der Open Management Group. Die Sprachkonstruktesind objektorientiert.

In Ponder können Aktionen, die als Funktionsbezeichner ggf. mit Parametern dargestellt werden,delegiert werden.

2.6.9 PolicyMaker

PolicyMaker [BFL96] ist ein Rahmenwerk für Kryptografie-basierte Dienste zum Schutz vonVertraulichkeit und Authentizität mit expliziter Beschreibung von Vertrauensaspekten auf Basiseiner einfachen Programmiersprache, die vertrauenswürdige Aktionen, Autorisierungen und Be-rechtigungsnachweise als Prädikate spezifiziert. Der Kern von PolicyMaker ist eine Prüffunktion,der eine Anfrage zur Ausführung einer Aktion und dazu passende Autorisierungen und Zertifika-te übergeben werden. Die Prüffunktion entscheidet, ob die Anfrage angenommen werden kann,d. h. die Aktion ausgeführt werden darf, oder ob sie verworfen werden muss. Ergänzend kön-nen zusätzliche Einschränkungen zurückgegeben werden, mit denen eine abzulehnende Anfrageangenommen werden könnte.

Eine Besonderheit von PolicyMaker ist, dass die Aktionen als beliebige anwendungsspezifischeZeichenketten formuliert werden können. Berechtigungen werden in Form von Prüfungen durchreguläre Ausdrücke oder Programmcode für einen speziellen AWK-Interpreter spezifiziert, diebei der Prüfung der Anfragen auf die Zeichenketten im Sinne eines Filters angewendet werden.

Auf diese Weise ermöglicht PolicyMaker das Vertrauensmanagement für beliebige Anwendungs-bereiche nutzbar zu machen.

2.6.10 Keynote

Keynote ist ein Trustmanagement-System und baut auf dem PolicyMaker-Projekt auf.

KeyNote legt in [BFIK99] eine spezielle Sprache für Berechtigungen und Anfragen fest. Die-se ist vergleichbar mit Label-Wert-Paaren eines E-Mail-Headers. Die Autoren verfolgen dabeidas erklärte Ziel, die Zusicherungen auch für den menschlichen Benutzer in lesbarer Form zukodieren.

Die Autoren definieren als Elemente eines Trustmanagement-Systems fünf Punkte. Diese um-fassen

q eine Sprache zur Beschreibung von Aktionen, die für die Sicherheit eines Systems relevantsind (z. B. Lesen einer Datei)


q Möglichkeiten, um Akteure innerhalb des Systems identifizieren zu können

q eine Sprache zur Formulierung von Anwendungsrichtlinien zur Verwaltung der im Systemmöglichen Aktionen, zu denen Akteure ermächtigt werden können

q eine Sprache zur Spezifikation von Berechtigungsnachweisen, die es Akteuren ermöglicht,an andere Akteure Berechtigungen zu delegieren

q eine Prüfinstanz, die die Erfüllung von Richtlinien auf Basis einer Menge von Berechti-gungsnachweisen verifiziert

Der RFC spezifiziert sprachliche und algorithmische Mittel, um diese fünf Elemente bereitzustel-len. Aktionen werden dabei in Form einfacher Prädikate ausgedrückt und als Bezeichner-Werte-Paare kodiert, die frei durch den Applikationskontext bestimmt werden können. Als Akteurekönnen Personen, Systeme und – wie bei SPKI – auch kryptographische Schlüssel verwendetwerden.

Prüfausdrücke können mit Hilfe der Feldnamen, Vergleichsoperationen, boolschen Verknüpfun-gen und regulären Ausdrücken erstellt werden und einen Wert der möglichen Freigabestufen(z. B. „approve“, „reject“ oder „Kein Zugriff“, „Lesezugriff“, „Vollzugriff“) enthalten.

Für die Validierung einer Aktion kann eine Applikation eine Anfrage an die Prüfinstanz (Com-pliance Checker) stellen, der sie die Identität des Akteurs, die gewünschten Aktionen und einenSatz von Berechtigungen schickt. Der Compliance Checker wertet die übergebene Anfrage mitHilfe der in den Berechtigungen enthalten Prüfausdrücke aus und gibt die Freigabestufe zurück.

Die Semantik der Felder einer Anfrage überlässt Keynote vollständig der Applikation und be-trachtet lediglich die Auswertung der Bedingungen.

2.7 Bewertung der bestehenden Mechanismen

Die in diesem Kapitel vorgestellten Mechanismen ermöglichen es, unterschiedliche Arten vonNachweisen der Authentizität bzw. von Zusicherungen zu geben. Um jedoch die in Kapitel 1beschriebenen Aussagen darstellen und dabei die in Abschnitt 1.3 vorgestellten Ziele erfüllen zukönnen sind sie jeweils nur teilweise geeignet.

Die Flexibilität bei der Gestaltung von Zusicherungen ist naturgemäß bei reinen Signaturver-fahren gegeben, da diese keine Festlegung der jeweils signierten Inhalte vornehmen. Die Trust-Management-Verfahren haben überwiegend einen begrenzten Anwendungsbereich.

Bei den Zertifikaten nach X.509, SPKI und PGP ist der Informationsgehalt eng auf die Anforde-rungen der sicheren Schlüsselverteilung zugeschnitten.

Bei den Verfahren Kerberos, SAML, XACML, PERMIS, Ponder und SecPAL steht die Ertei-lung von Autorisierungen von Dienstnutzungsberechtigungen im Mittelpunkt. Die sprachlichenMittel sind daher darauf spezialisiert. PolicyMaker nimmt eine Sonderstellung ein, da hier keine

2.7 Bewertung der bestehenden Mechanismen 43

Vorgaben zum Inhalt gemacht werden. Es ist somit prinzipiell geeignet, beliebige Zusicherungenzu unterstützen. Das darauf aufsetzende KeyNote hat wiederum einen Anwendungskontext fürAutorisierungen.

Zur Erhöhung der Verbindlichkeit tragen alle Verfahren bei, da sie über Signaturen abgesichertsind. Diese Signaturen sind teilweise fester Bestandteil oder sogar Gegenstand des Verfahrens(X.509, PGP, S/MIME, ...). Bei anderen müssen die Signaturen gesondert betrachtet werden(Ponder, PolicyMaker, Keynote, ...). Bei allen Verfahren lassen sich durch den Einsatz von Si-gnaturen die Integrität und Authentizität der gegebenen Zusicherungen oder Aussagen belegen.

Die gewünschte Verständlichkeit ist bei den vorgestellten Zusicherungen nur durch zusätzlicheMaßnahmen wie spezielle Anzeigeprogramme erreichbar. Wie bei X.509 aufgezeigt, wird einefür den Anwender verständliche Bedeutung durch Definitionen in den Standards festgelegt undnicht fest, d. h. per Kodierung, an die Zertifikate gekoppelt.

Bei Verfahren wie SPKI/SDSI ist durch die Verwendung sprechender Labels in den S-Expressionsdie Bedeutung in lesbarer Form vorhanden. Jedoch muss der Zusammenhang zwischen den ein-zelnen Elementen ebenfalls mit Kenntnis der Standards abgeleitet werden.

Eine etwas bessere Form bietet hierbei SecPAL, das für seinen engen Anwendungsbereich eineSprache verwendet, deren Darstellung Sätzen der natürlichen Sprache sehr nahe kommt.

Signaturverfahren, die lediglich ein Dokument signieren (PDF, S/MIME) können eine sehr hoheVerständlichkeit der zugesicherten Daten erreichen, da in diesem Fall direkt mit einer natürlich-sprachlichen Form gearbeitet werden kann.

Hinsichtlich der Automatischen Auswertung sind alle Verfahren zur Zertifikats- und Zusiche-rungsverarbeitung sehr gut geeignet, da diese Eigenschaft ein Entwurfsziel solcher Zertifizie-rungssysteme ist. Bei den reinen Signaturen z. B. über natürlichsprachliche Texte gibt es keinevorgegebene Möglichkeit zur automatisierten Verarbeitung der signierten Daten.

PDF-Dokumente nehmen bei der Automatisierbarkeit eine Mittelstellung ein, da es hier mög-lich ist, Formulare zu definieren, die sowohl signiert als auch automatisch verarbeitet werdenkönnen. Diese können dabei neben den Formularfeldern natürlichsprachlichen erläuternden Textenthalten.

In Abbildung 2.8 wird ein Einordnung der Verfahren hinsichtlich Automatisierbarkeit und Fle-xibilität graphisch veranschaulicht.

Die Bereitstellung von Delegationsmechanismen ist ebenfalls unterschiedlich stark ausgeprägt.SPKI/SDSI unterstützt die Weitergabe von Berechtigungen durch die Berechtigten. Kerberosunterstützt Delegation eingeschränkt durch Weitergabe von Berechtigungen eines Anwenders aneinen Server. Ponder ermöglicht komplexe, in der Länge beschränkbare Delegationsketten mitdiversen Einschränkungsmöglichkeiten. PERMIS unterstützt ebenfalls mehrstufige Delegationeinschließlich Delegationsrichtlinien [CZO+08]. SAML kann ebenfalls um Mechanismen derDelegation erweitert werden [WVH05]. PolicyMaker definiert selbst keine Delegationsmecha-nismen. Erst im darauf aufsetzenden KeyNote wird ein entsprechender Mechanismus zur Wei-tergabe von Autorisierungen unterstützt. Die Zertifizierungsmechanismen unterstützen nur eine


Automatisierbarkeit

Flexibilität

PDF

SecPal

S/MIME

gerin

gmittel

hoch

hoch

gering mittel

SPKI/SDSI

X.509Ponder

XACMLKeynote

PERMISPGP

PolicyMaker

Abbildung 2.8: Qualitativer Vergleich der Zielerfüllung für Automatisierbarkeit und Flexibilität

spezielle Art der Delegation. Bei X.509 erfolgt Delegation implizit durch Erstellen von Ausstel-lerzertifikaten, die zur Erstellung von Zertifikaten auf der nächsten hierarchischen Ebene berech-tigen. Bei PGP kann durch Signaturen Dritter das mögliche Vertrauen in einen Schlüsselinhaberangehoben und dieser dadurch in eine verbesserte Bestätigerrolle gebracht werden.

Zusammenfassend muss festgestellt werden, dass keines der untersuchten Verfahren alle An-forderungen erfüllen kann. Dieser Umstand wird sowohl durch die hohe Spezialisierung derFunktionalität wie z. B. bei X.509 als auch durch die allgemeine Verwendbarkeit wie bei denSignaturverfahren wie S/MIME bedingt.

Es wird deshalb mit dem Ansatz der grammatikbasierten Zertifikate in Kapitel 4 eine Möglichkeitgeschaffen, allen Anforderungen in ausgewogenerer Weise gerecht zu werden.

3 Methoden zur Sicherheitsanalyse

In diesem Kapitel werden zwei Verfahren zur formalen Verifikation von Sicherheitseigenschaf-ten in Protokollen bzw. kommunizierenden Systemen vorgestellt, die in den weiteren Teilen derArbeit zur Anwendung kommen. Der Fokus liegt dabei auf den Eigenschaften Vertraulichkeitund Authentizität sowie der Bewertung der jeweils notwendigen Voraussetzungen.

Das erste Verfahren ist die sog. SVO-Logik, eine Belief-Logik, mit der Überzeugungen und Be-obachtungen bei Anwendung von Kommunikationsprotokollen modelliert werden können. An-hand des Modells und einer Menge von Ableitungsregeln können aus Sicht der Kommunika-tionspartner die jeweils gültigen Schlussfolgerungen im Hinblick auf Sicherheitseigenschaftenabgeleitet werden.

Das zweite Verfahren ist der angewandte Pi-Kalkül und Proverif, eine Implementierung diesesKalküls zur Durchführung von Modellchecking-Analysen der Sicherheitseigenschaften in kom-munizierenden verteilten Systemen. Die Modellierung umfasst dabei sowohl die ausgetauschtenNachrichten als auch die (sicherheitsrelevanten) Verarbeitungsschritte innerhalb der beteiligtenInstanzen.

3.1 SVO-Logik

Um eine Bewertung von Kommunikationsprotokollen im Hinblick auf die jeweils für die Kom-munikationspartner nachweislich erreichbaren Überzeugungen zu ermöglichen, wird im Folgen-den mit der SVO-Logik eine sog. Belief-Logik vorgestellt.

Im Jahr 1996 entwickelten Syverson und van Oorschot die nach ihnen benannte SVO-Logik[SO96]. Diese ist eine Weiterentwicklung der durch die BAN-Logik begründeten Reihe von Lo-giken und vereint neben den Fähigkeiten der von Burrows, Abadi und Needham entwickeltenBAN-Logik [BAN89] auch noch die Aussagefähigkeiten der GNY-Logik [GNY90] von Gong,Needham und Yahalom sowie der ebenfalls auf BAN aufsetzenden Logiken AT [AT91] von Aba-di und Tuttle und VO [vO93] von van Oorschot.

Wesentlicher Beitrag der SVO-Logik ist die Definition einer formalen Semantik der Logik. ImFolgenden wird die später in [SC01] eingeführte Schreibweise verwendet.

Bei einer Belief-Logik handelt es sich um eine Sammlung von formalisierten Ableitungsregeln,die den Austausch von Information z. B. in Kommunikationsprotokollen aus der beobachtenden

45

46 Kapitel 3. Methoden zur Sicherheitsanalyse

Sicht eines an der Kommunikation Beteiligten beschreiben. Beteiligte können Personen oderProzesse sein, die eigenständig handeln (im Weiteren auch als Prinzipale bezeichnet). Aus Infor-mationen, die dieser sieht, sowie seinem vorhandenen Vorwissen, kann er durch Anwendung derAbleitungsregeln Schlussfolgerungen ziehen.

3.1.1 Vorgehensweise bei SVO-Analysen

Eine Analyse eines Protokolls auf Basis einer Modellierung in SVO-Logik wird in mehrerenSchritten durchgeführt.

Zieldefinition Es wird festgelegt, welche Überzeugungen bei einem oder mehreren Kommu-nikationspartnern erzielt werden müssen. Ein Beispiel ist die Etablierung eines geteiltenGeheimnisses zwischen den Beteiligten A und B. Eines der entsprechenden Ziele lautetdann „A glaubt, dass der Schlüssel k ein geteiltes Geheimnis zwischen A und B ist“. InSVO-Schreibweise ist dies „A believes A k←→B“.

Prämissen – Initiales Wissen Die für die Untersuchung notwendigen Prämissen werden auf-gestellt. In diesen Prämissen werden alle Annahmen bzgl. eines initialen Kenntnisstandesder Beteiligten festgehalten. Hierzu gehören u. a. welche Schlüssel sie besitzen und wemdiese ggf. zugeordnet werden, welche Zufallswerte als „frisch“ in Bezug auf den aktuellenProtokolllauf angesehen werden, usw.

Prämissen – Protokollbeschreibung Die empfangenen Nachrichten werden aus der subjekti-ven Sicht des oder der Beteiligten modelliert. Hierbei wird neben dem Verständnis derNachrichten (welche Daten sind bekannt, welche sind neu) auch die Interpretation derNachrichten durch den Empfänger beschrieben (z. B. die Übermittlung eines bestimmtenWertes k bedeutet im Rahmen des Protokolls, dass dieser Wert k als Sitzungsschlüsselzwischen den Beteiligten verwendet werden soll). Die dabei entstehenden Ausdrücke er-weitern die im vorhergehenden Schritt aufgestellten Prämissen.

Ableitungen Durch Anwendung der Ableitungsregeln des Kalküls wird versucht, die Formelnabzuleiten, die durch die festgelegten Ziele vorgegeben sind. Hierbei kommen die axioma-tischen Ableitungsregeln des Kalküls und die aufgestellten Prämissen zur Anwendung.

Bewertung Abschließend wird bewertet, ob einerseits das bzw. die Ziele erreicht werden konn-ten und welche Prämissen hierzu nötig waren. Werden unterschiedliche Protokolle mitein-ander verglichen, so können bei gleichem Ziel die jeweils anzunehmenden Prämissen zurBewertung herangezogen werden.

3.1.2 Notation der SVO-Logik

Die hier vorgestellte Schreibweise der Ausdrücke der SVO-Logik basiert auf den Darstellungenin [SO96] und [SC01].

3.1 SVO-Logik 47

Formel1 Semantik

Pk←→Q k ist ein zwischen P und Q geteiltes Geheimnis

PKσ(P, k) k ist ein öffentlicher Signaturschlüssel von PPKϕ(P, k) k ist ein öffentlicher Verschlüsselungsschlüssel von PPKδ(P, k) k ist ein öffentlicher Schlüssel von P zur SchlüsselaushandlungSV(X, k, Y ) Die Formel ist wahr, wenn mit k geprüft werden kann, dass X aus Y durch

Verwendung des zu k gehörenden Signaturschlüssel hervorgeht.P received X P hat die Nachricht X empfangen.P has X P ist in Besitz der Nachricht X .P said X P hat (irgendwann) in der Vergangenheit die (Teil-)Nachricht X gesendet.P says X P hat im aktuellen Protokolllauf die (Teil-)Nachricht X gesendet.fresh(X) X war in keiner Nachricht enthalten, die vor dem aktuellen Protokolllauf ge-

sendet wurde.P believes ϕ P kann sich so verhalten, als ob ϕ wahr ist.P controls ϕ P hat die Kompetenz (Jurisdiktion) über ϕ. Mit anderen Worten: wenn P ϕ

sagt, so gilt ϕ als wahr.1 mit P,Q: Prinzipale, X, Y : Nachrichten, k: Schlüssel und ϕ: Formel

Tabelle 3.1: Formelausdrücke der SVO-Logik

Grundbausteine der Logik sind primitive Terme, die für Konstanten (L,M,N, . . .), Identitäten(A,B, P,Q, . . .) sowie symmetrische, private und öffentliche Schlüssel (K, k, k−1, KA, . . .) ver-wendet werden. Diese primitiven Terme werden in der Menge Θ zusammengefasst.

Ausgehend von Θ definiert SVO zwei verschiedene Sprachen. Zum einen werden Formeln aus-gedrückt, denen ein Wahrheitswert (wahr: T, falsch: F) zugeordnet werden kann, zum anderenwird eine Schreibweise für Nachrichten festgelegt.

Die Elemente der Menge aller Nachrichten M sind wie folgt definiert: Alle Elemente aus Θsind Nachrichten. Jede Funktion, deren Argumente Nachrichten sind, ist eine Nachricht. Hierzugehört insbesondere auch die Tupel-Bildung der Form (x1, . . . , xn) mit xν ∈ Θ sowie die un-ten angegebenen Ausdrücke für verschlüsselte und signierte Nachrichten. Jede Formel ist eineNachricht.

Alle Ausdrücke in Tabelle 3.1 sind Formeln und bilden durch Konjunktion (∧) und Negation (¬)wiederum Formeln.

Für verschlüsselte und signierte Nachrichten wurden folgende Schreibweisen festgelegt:

bXcK beschreibt eine mit dem SchlüsselK ausgeführte Signatur überX . Die Schreibweise stehtfür das Paar aus Signatur nach einem Schema ohne Rückgewinnung der signierten Nachrichtund den Daten selbst. Zur Prüfung der Signatur wird der korrespondierende Schlüssel K̃ zuK benötigt. Ist K = k−1, so ist K̃ = k. Für Verschlüsselung wird die Schreibweise {X}Kverwendet. Zur Entschlüsselung wird wieder K̃ verwendet. Für asymmetrische Verfahren gilt:K = k und K̃ = k−1. Im symmetrischen Fall ist K = K̃ = k.


Zusätzlich wurden folgende Annotationen definiert: 〈X〉∗P bedeutet „X in der Wahrnehmungvon Prinzipal P“. Diese spezielle Form der Darstellung ist notwendig, da P eine empfangeneNachricht nicht immer vollständig interpretieren kann. Beispielsweise kann der Empfänger einerNachricht H(Y ) diese nur dann als Hashwert über Y erkennen, wenn ihm auch Y vorliegt.Dennoch ist der empfangene Bitstring nicht beliebig, da der Empfänger diesen – auch ohnekorrekte Interpretation – wiedererkennen kann. Die Schreibweise X from Q bezeichnet einDatum X , das von Q stammt.

3.1.3 Schlussregeln der SVO-Logik

Die SVO-Logik besteht in der modifizierten Form aus [SC01] aus 22 als Axiome bezeichnetenSchlussregeln. Diese setzen die Prämissen ϕ1 . . . ϕn mit den Folgerungen ψ1 . . . ψm durch dieSchreibweise

ϕ1 ∧ . . . ∧ ϕn → (ψ1 ∧ . . . ∧ ψm) ϕi, ψj ∈ Φ

in Bezug. Dabei steht das Zeichen „→“ für die logische Implikation.

Zur Durchführung von Ableitungen kommen zwei Schlussregeln zum Einsatz. Die erste Regelist Modus Ponens (MP):

ϕ, ϕ→ ψ

ψ(MP)

Aus den Prämissen ϕ und ϕ→ ψ lässt sich die Schlussfolgerung (Conclusio) ψ ziehen.

Die zweite Regel ist die Ableitung notwendiger Prämissen, engl. necessitation (Nec).

` ϕ` P believes ϕ

(Nec)

Jede Aussage ϕ, die aus den Axiomen abgeleitet werden kann, wird von P als richtig angesehen(geglaubt). Das Symbol „`“ steht für die Herleitungsbeziehung.

Im Folgenden werden einige der Axiome anhand eines Beispiels eingeführt. Die vollständigeAuflistung aller Axiome findet sich in Anhang A.

3.1.4 Subjektive Sichtweise

Die besondere Eigenschaft der Belief-Logik ist die Modellierung der subjektiven Sicht einesoder mehrerer an der Kommunikation Beteiligter. Es ist also bei der Betrachtung nicht von Be-deutung, wer an wen welche Informationen sendet, sondern welche Nachrichten der jeweils Be-troffene beobachtet bzw. empfängt und welche Schlüsse er – ggf. unter Einbeziehung von bereitsvorhandenem Wissen – daraus ziehen kann.

3.1 SVO-Logik 49

Als Einführung wird zunächst ein einfaches Beispiel betrachtet. Ein Anwender A eines DienstesB kann an den Dienst einfache Kommandos Cx schicken, die vom Dienst ausgeführt werden.

Wird in einem ungeschützten Protokoll die Identität A des Nutzers, das Kommando C1 undzur Legitimation ein Passwort PW an B übertragen, so führt dies nur dann zu einem korrektenVerhalten des Servers, wenn die Nachricht wirklich vonA geschickt wurde. Die übliche Notationsolcher Übertragungen, die Sender und Empfänger in der Form „A sendet anB“ darstellen, führthäufig zu einer Vernachlässigung der Betrachtung von Bedrohungen, da die Darstellung bereitsA als Sender impliziert (die sendet an-Beziehung wird durch das Zeichen 7→ dargestellt):

A 7→ B : A,PW,C1

Die zugehörige subjektive Darstellung ist

B received (A,PW,C1)

Es liegt also in der Schreibweise keine Information über die (tatsächliche) Quelle vor.

Dieser Perspektivenwechsel ist ein wesentlicher Beitrag, den Belief-Logiken leisten, um einefehlerhafte Interpretation zu vermeiden. Identische Nachrichten führen in der SVO-Schreibweiseauch auf eine identische Wahrnehmung beim Empfänger.

A 7→ B : A,PW,C1 ; B received A,PW,C1

E 7→ B : A,PW,C1 ; B received A,PW,C1

Hiermit ist für den Empfänger nicht unterscheidbar, ob die Nachrichten von einem legitimiertenAnwender A (Alice) oder von einem Angreifer E (Evil) stammen.

Die SVO-Logik bietet eine Reihe von Regeln an, die es ermöglichen, aus vorhandenen Daten,Überzeugungen und Beobachtungen korrekte Schlussfolgerungen zu Protokollabläufen zu zie-hen. Diese Regeln sind in Anhang A aufgeführt.

Entsprechend der oben beschriebenen Vorgehensweise werden die Prämissen aufgestellt. Nebender Modellierung des initialen Wissens (Zuordnung von öffentlichen Schlüsseln, Frische vonZufallswerten, Auswertungen von Signaturen, ...) werden bei der Modellierung der Nachrichtendes Protokolls folgende Aspekte berücksichtigt:

q Empfangene Nachrichten gemäß der Protokollbeschreibung. Diese Darstellung dient zurDokumentation und als Ausgangspunkt zur Festlegung der weiteren protokollbezogenenPrämissen.

q Verständnis der empfangenen Nachrichten zur Unterscheidung der bekannten und der neu-en Elemente. Neue Elemente X aus Sicht von A werden als 〈X〉∗A geschrieben.

q Interpretation der Nachrichten durch den Empfänger. Hierbei können u. a. Symbole durchFormeln ersetzt werden (z. B. kann die durch den Schlüssel von B signierte Übertragungder Kennung von B und einer für A neuen Bitfolge 〈KAB〉∗A als Aussage interpretiertwerden, dass diese als neuer symmetrischer Schlüssel zwischen A und B fungieren soll: es

wird daher bB, 〈KAB〉∗AckB durch bA 〈KAB〉∗A←→ BckB ) ersetzt.


Das oben eingeführte Beispiel wird nun um die Signatur des Befehls durch den Anwender er-weitert. Hierbei ist (KA, K

−1A ) das Schlüsselpaar von A. Damit sich der Server auch von der

Aktualität der Anfrage überzeugen kann, werden zwei zusätzliche Protokollschritte eingeführt.A sendet zunächst eine Initialnachricht mit seiner Kennung an den Server und erhält als Antworteinen durch den Server bestimmten frischen Zufallswert N .

Damit sieht das erweiterte Protokoll wie folgt aus:

A 7→ B : A

B 7→ A : N

A 7→ B : bC1, NcK−1A

Das zu zeigende Ziel ist die Überzeugung von Server B, dass die empfangene Nachricht aktuellvon A gesendet wurde: B believes A says C1 .

Die Prämissen, die das initiale Wissen von B beschreiben, sind:

B believes PKσ(A,KA) (P1)B believes fresh(N) (P2)B believes SV(bC1, NcK−1

A, KA, (C1, N)) (P3)

Die beiden ersten Nachrichten des Protokolls werden nicht modelliert, da sie ungeschützt über-tragen werden und beliebig manipulierbar sind und somit nicht zur Ableitung beitragen können.Die empfangene signierte Nachricht wird geschrieben als:

B received bC1, NcK−1A

(P4)

Da die Nachricht keine für B neuen Terme enthält, ist das Termverständnis identisch zur emp-fangenen Nachricht.

B believes B received bC1, NcK−1A

(P5)

Diese Prämissen können nun für Ableitungen (als C1, C2, ... nummeriert) eingesetzt werden. MitAxiom (Ax6)

(PKσ(Q,K) ∧R received X ∧ SV(X,K, Y ))→ Q said Y

sowie (P1), (P3) und (P4) kann B ableiten, dass die Information authentisch ist.

B believes A said (C1, N) (C1)

Mit (Ax19) ist aus der Frische von N (P2) die Frische von (C1, N) ableitbar.

B believes fresh(C1, N) (C2)

Schließlich kann mit (Ax21) die Aktualität der Nachricht gezeigt werden:

B believes A says (C1, N) (C3)

Durch (Ax17) kann schließlich das Ziel erreicht werden

B believes A says C1 (C4)

3.1 SVO-Logik 51

3.1.5 Erweiterung der SVO-Logik

Ob eine Nachricht bzw. eine Aussage in einem aktuellen Protokolllauf gültig ist, kann in derSVO-Logik lediglich über den Frische-Begriff abgeleitet werden. Bei Zertifikaten wird jedochkein frischer Nonce-Wert verwendet, sondern eine Statusauskunft z. B. von einem OCSP-Diensteingeholt. Die Aussage des Dienstes besagt, dass ein zuvor ausgestelltes Zertifikat als gültig an-zusehen ist, oder anders ausgedrückt, dass der Ersteller der Aussage diese nach wie vor aufrechterhält und sie deshalb so betrachtet werden kann, als wäre sie im aktuellen Protokolllauf geäußertworden. Dieser Mechanismus soll durch ein neues Prädikat current im Rahmen der SVO-Logikbeschrieben werden.

Zur genauen Definition des Prädikats wird das in [SO96] eingeführte Zustandsmodell verwendet:Die Beteiligten eines Protokolllaufs sind P1, . . . , Pn sowie ein Angreifer Pe. Zu jedem Pi wird einlokaler Zustand si definiert, der durch eine Menge von Überzeugungen der Form Pi believes . . .dargestellt werden kann. Durch Ereignisse wie die Generierung neuer Werte und den Empfangvon Nachrichten ändert sich jeweils zu einem diskreten Zeitpunkt ein lokaler Zustand. Der Initi-alzustand der aktuellen Authentisierung (hier auch der aktuellen Auditanfrage) liegt bei t = 0.Die lokalen Zustände si zum Zeitpunkt t können zu einem globalen Zustand r(t) zusammenge-fasst werden, der auch als (r, t) geschrieben wird.

Die Schreibweise (r, t) � ϕ bedeutet, dass ϕ im globalen Zustand r und damit auch in allenlokalen Zuständen zum Zeitpunkt t gültig ist (Semantische Implikation, �). So sind z. B. dieWahrheitsbedingungen für die Kompetenz in [SO96] wie folgt definiert: „(r, t) � P controls ϕ“g.d.w. die Aussage „(r, t) � P says ϕ“ die Aussage „(r, t′) � ϕ für alle t′ ≥ 0“ impliziert.

In diesem Modell kann für das neue Prädikat current(Q,ϕ) formal definiert werden:

(r, t) � current(Q,ϕ)

g.d.w. die Aussage Q said ϕ die Aussage Q says ϕ impliziert. (3.1)

Zur Anwendung des Prädikates wird folgende Ableitungsregel ergänzt:

Q said ϕ ∧ current(Q,ϕ)→ Q says ϕ (Ax23)

Die Korrektheit dieser Implikation ist offensichtlich, da sie den Festlegungen der Wahrheitsbe-dingungen in (3.1) entspricht. Das current-Prädikat ähnelt dem fresh-Prädikat hinsichtlich derWirkung auf eine vormals gesagte Nachricht (Ax21), ist insgesamt jedoch deutlich schwächer,da keine Übertragung der Eigenschaft wie bei Frische durch (Ax19) und (Ax20) erfolgen kann.

In Anhang A wird in Abschnitt B.1 ein ausführliches Beispiel zur Anwendung der SVO-Logikbei der Prüfung signierter Daten unter Einbeziehung von PKI-Diensten gezeigt, das dieses neuePrädikat verwendet.


3.2 Angewandter Pi-Kalkül

Die in den vorausgehenden Abschnitten vorgestellte Methode der SVO-Logik beschränkt sichbei der Beschreibung auf die subjektive Wahrnehmung von Nachrichten eines oder mehrerer Be-teiligter. Neben dieser Methode gibt es jedoch auch Verfahren, die die Kommunikation zwischenallen Beteiligten untersuchen und neben den ausgetauschten Nachrichten auch das jeweilige in-terne Verhalten der Kommunikationspartner zwischen dem Austausch von Nachrichten model-lieren.

3.2.1 Prozesskalküle

Eine solche Möglichkeit zur Analyse von kryptographisch gesicherten Protokollen ist eine for-male Beschreibung mittels eines geeigneten Prozesskalküls, der das relevante Verhalten aller amProtokolllauf Beteiligten einschließlich eines Angreifers modelliert.

In der Literatur finden sich zu Prozesskalkülen verschiedene Ansätze. Hierzu zählen u. a. dieProzessalgebra Communicating Sequential Processes (CSP) von Hoare [Hoa85], die in Form desModel-Checkers Failures-Divergence Refinement (FDR) [Oxf10] z. B. in [Low96] zur Analysevon sicheren Protokollen eingesetzt wird, der von Milner entwickelte Kalkül kommunizierenderSysteme (Calculus of Communicating Systems, CCS) [Mil80] und der darauf aufsetzende Pi-Kalkül, der in einer Variante, dem sog. angewandten Pi-Kalkül, im Folgenden vorgestellt undeingesetzt wird. Ein weiterer Vertreter für Prozesskalküle ist die Language of Temporal OrderingSpecification (LOTOS) [ISO89], eine für die Modellierung von Protokollen und Diensten in derTelekommunikation geschaffene Beschreibungsform, die z. B. zur Analyse parallel arbeitenderKommunikationsdienste eingesetzt werden kann [Kec00].

3.2.2 Der Pi-Kalkül

Der Pi-Kalkül ist ein Prozesskalkül, der 1992 von Robin Milner, Joachim Parrow und DavidWalker zur Modellierung kommunizierender Prozesse entwickelt wurde [MPW92].

Die Elemente, aus denen sich der Pi-Kalkül zusammensetzt, sind Systemmodelle aus parallelausgeführten Prozessen und Nachrichten, die auf benannten Kanälen zwischen diesen Prozessenausgetauscht werden. Dabei wird der Austausch von Nachrichten lediglich durch die in den Pro-zessen vorkommenden Sende- und Empfangsschritte modelliert. Die Prozesse enthalten Namenund Variablen. Mit den Namen werden sowohl Konstanten wie kryptographische Schlüssel alsauch Kanäle zwischen den Prozessen bezeichnet.

Die über benannte Kanäle ausgetauschten Nachrichten bilden die einzige Interaktion zwischenProzessen. Die Kanalnamen können ihrerseits als Nachrichten verschickt werden. Auf diese Wei-se können im Verlauf eines Protokolls neue Kommunikationsbeziehungen zwischen Prozessengeschaffen werden, indem diese durch Kenntnisnahme zuvor unbekannter Kanalnamen die da-durch bezeichneten Kanäle zur Kommunikation nutzen können.

3.2 Angewandter Pi-Kalkül 53

3.2.3 Erweiterung zum angewandten Pi-Kalkül

Abadi und Gordon entwickelten 1999 auf Basis des Pi-Kalküls zunächst den Spi-Kalkül [AG99],welcher den Pi-Kalkül um Funktionen zur Beschreibung von verschlüsselter Kommunikationerweitert. In 2001 entwickelten Abadi und Fournet daraus den angewandten Pi-Kalkül [AF01],der später noch gemeinsam mit Bruno Blanchet [AB05, BAF08] modifiziert wurde.

Der angewandte Pi-Kalkül erweitert den Ansatz von Milner um Funktionen und Gleichungen,die wiederum zur Beschreibung kryptographischer Funktionen wie Hashwertberechnung, sym-metrische und asymmetrische Verschlüsselung und Bildung von Zufallswerten dienen. Schlüsselund Zufallswerte werden dabei durch gebundene Namen repräsentiert.

Die Notation verwendet eine Menge Σ von Funktionen und Konstanten, Terme (L,M,N, . . .),Namen (a, b, c, k, n, s, . . .), Variablen (x, y, z, . . .) und angewendete Funktionen wie z. B.f(M1, . . . ,Ml).

Namen werden einmalig im Modell festgelegt und repräsentieren im gesamten Protokolllaufeine unveränderliche Größe. Variablen werden im Verlauf des Protokolls durch eine Ersetzungdynamisch mit einem Wert verknüpft.

Für die Beschreibung von Prozessen (P,Q,R, . . .) können die in Tabelle 3.2 aufgeführten Schreib-weisen eingesetzt werden.

Parallel laufende Prozesse P |QEmpfang einer Nachricht a(x).P

Versenden einer Nachricht a〈M〉.Pbedingte Ausführung von Prozessen if M = N then P elseQ

Termauswertung let x = g(M1, . . . ,Mn) in P elseQ

beliebig häufig instantiierte Prozesse !P

Erzeugung eines neuen gebundenen Symbols (νn).P

leerer Prozess (Null-Prozess) 0

Tabelle 3.2: Schreibweisen des angewandten Pi-Kalküls

Prozesse werden durch Konkatenation dieser Elemente geschrieben, die jeweils durch Punkteverbunden werden. Ein Beispiel für einen solchen Prozess ist

a(x).b(y).if y = s then x〈z〉 else0 .

Auf dem Kanal a wird ein Wert empfangen und im Weiteren die Variable x daran gebunden. Einzweiter Wert, an den y in der Folge gebunden wird, wird auf Kanal b empfangen. Wenn y gleichs ist, so wird x als Kanalname interpretiert und über diesen Kanal ein Name z ausgegeben. Liegtkeine Gleichheit vor, so wird keine Operation ausgeführt (dargestellt durch den Null-Prozess).


Wenn Variablen oder Namen neu erzeugt werden, so ist ihre Sichtbarkeit durch Bindung an dennachfolgenden (Teil-)Prozess beschränkt. Die Schreibweise ist (νx)P . Dieser Bindungsmecha-nismus wird z. B. für Nonce-Werte oder symmetrische Schlüssel verwendet, die zu Beginn oderwährend des ganzen Protokollablaufs nur innerhalb eines Teilprozesses bekannt sein dürfen undinsbesondere vor einem Angreifer geschützt werden müssen.

Darüber hinaus können auf Prozesse auch sog. aktive Ersetzungen angewendet werden. Diesewerden als {M/x} geschrieben und erzeugen eine Ersetzung der Variable x durch den TermM . Die Notation {M/x} entspricht der Form „let x = M in . . .“. Abadi und Fournet defi-nieren diese Form der Ersetzung als „gleitend“, d. h. sie wirkt sich auf alle Prozesse aus, diesich in der Prozessmenge befinden. Somit ist beispielsweise {M/x}|P |Q gleichbedeutend mit{M/x}|P{M/x}|Q{M/x}.

Die Wirkung einer Ersetzung kann auch auf einen oder mehrere Prozesse durch Definition einerneuen lokal gebundenen Variable beschränkt werden: (νx)({M/x}|P )|Q. Da x auf die Erset-zung und den Prozess P beschränkt ist, kann die Ersetzung auch nur innerhalb von P wirksamwerden; Q bleibt von der Ersetzung unberührt, da es per Definition kein x enthalten darf (dieswird ggf. durch Umbenennung sichergestellt).

Das Grundmodell zweier über einen Kanal c kommunizierender Prozesse P und Q ist in Abbil-dung 3.1 zu sehen.

Pc

Qc

Abbildung 3.1: Direkte Prozesskommunikation

Der Prozess P verfügt über eine „Ausgangsschnittstelle“ c, über die Informationen an Q über-tragen werden können. Q nimmt die Informationen an der „Eingangsschnittstelle“ c entgegen.Der Kanal ist bidirektional, die Zuordnung von Ein- und Ausgangsschnittstelle zeigt lediglichdie durch das Protokoll intendierte Nutzung. Für Kanäle, die nicht öffentlich sind, werden dieKanalbezeichner innerhalb der Kreise der Prozesse notiert.

In der Notation des angewandten Pi-Kalküls können die Prozesse wie folgt geschrieben werden:

P = c〈d〉.P ′

Q = c(x).Q′

Dabei ist P ein Prozess, der als ersten Verarbeitungsschritt über seine Ausgangsschnittstellec〈〉 zum Kanal c ein Datum d in diesen Kanal sendet. Danach werden alle Schritte des (Sub-)Prozesses P ′ ausgeführt. Die Punktschreibweise verkettet neben einzelnen Prozessschritten auchSubprozesse.

Der Prozess Q wartet auf eine Nachricht auf Kanal c, um diese der Variable x zuzuweisen, dieim folgenden Subprozess Q′ dann mit dem empfangenen Wert belegt wird. Die Präfixnotation


A ≡ A|0 (PAR-0)A|(B|C) ≡ (A|B)|C (PAR-A)

A|B ≡ B|A (PAR-C)!P ≡ P |!P (REPL)

(νn).0 ≡ 0 (NEW-0)(νu).(νv).A ≡ (νv).(νu).A (NEW-C)A|(νu).B ≡ (νu).(A|B) (NEW-PAR)

falls u 6∈ fv(A) ∪ fn(A)

(νx).{M/x} ≡ 0 (ALIAS){M/x}|A ≡ {M/x}|A{M/x} (SUBST){M/x} ≡ {N/x} falls Σ `M = N (REWRITE)

Tabelle 3.3: Äquivalenzen des Pi-Kalküls

für den Empfang von Informationen bewirkt auch eine Bindung von x an Q′. Außerhalb von Q′

ist x nicht bekannt.

Die im Rahmen des angewandten Pi-Kalküls definierten Prozesse liegen parallel zueinander ineinem Prozessraum. Diese Nebenläufigkeit von Prozessen kann durch das |-Symbol dargestelltwerden. Somit lassen sich die Beispielprozesse auch folgendermaßen schreiben:

P |Q = c〈d〉.P ′|c(x).Q′

Das Fortschreiten der Kommunikation zwischen den Prozessen kann durch Umformungen nachden Regeln des Kalküls beschrieben werden. Diese Umformungen werden als Reduktionen be-zeichnet und in der Form M → N geschrieben. Diese sind nach [AF01]

a〈x〉.P |a(x).Q→ P |Q (COMM)if M = N then P elseQ→ P (THEN)

für alle Aussagen M,N, wenn Σ `M = N

if M = N then P elseQ→ Q (ELSE)für alle Aussagen M,N, wenn Σ 6`M = N

Die (COMM)-Regel besagt, dass ein auf dem Kanal a gesendetes Datum durch einen auf Kanala hörenden Prozess aufgenommen wird. Die Vergleichsoperation M = N bewirkt eine fallab-hängige Fortsetzung der Prozessbearbeitung (THEN, ELSE).

Neben der Anwendung der Reduktion werden auch sog. strukturelle Äquivalenzen (≡) verwen-det. Eine strukturelle Äquivalenz besteht zwischen zwei Prozessen, wenn sie bis auf eine mögli-che Umbenennung von gebundenen Namen gleichwertig in ihrem Verhalten sind. Diese Äquiva-lenzen nach [AF01] sind in Tabelle 3.3 dargestellt.


Die freien Variablen und Namen eines Prozesses A werden durch die Ausdrücke fv(A) bzw.fn(A) bezeichnet. Die entsprechende Notation für gebundene Variablen und Namen ist bv(A)bzw. bn(A).

Mittels der Reduktionen und Äquivalenzen können die kommunizierenden Prozesse durch eineentsprechende Substitution wie folgt geschrieben werden:

P |R = c〈y〉.P ′|c(x)R′

→ P ′|R′{y/x} mit x 6∈ fv(P ′)

Alle Vorkommen von x in R′ werden somit durch den Wert y ersetzt.

Die Eigenschaft des Kalküls, auch Kanalbezeichner übertragen zu können, ermöglicht die Eta-blierung neuer Kommunikationsbeziehungen, wie im Folgenden, aus [MPW92] entnommenen,Beispiel dargestellt wird.

R

Q

P ba

a

b

Abbildung 3.2: Beispiel kommunizierender Prozesse

In Abbildung 3.2 hat Prozess P einen Kanal a zum Prozess R und einen Kanal b zum Prozess Q.Nun soll Q von P einen Kanalnamen zur Kommunikation mit R und eine numerische Konstanteerhalten und diese über den neu übermittelten Kanal übertragen.

Die zugehörige Prozessdefinition lautet:

P ≡ b〈a〉.b〈5〉.P ′

Q ≡ b(y).b(z).y〈z〉.0R ≡ a(x).R′

Damit ist die Kommunikation mit gebundenen Variablen zwischen P , Q und R :

(νa)(νb)(P |Q|R) = (νa)(νb)(b〈a〉.b〈5〉.P ′|b(y).b(z).y〈z〉.0|a(x).R′)

→ (νa)(νb)(b〈5〉.P ′|b(z).y〈z〉.0{a/y}|a(x).R′)

→ (νa)(νb)(P ′|y〈z〉.0{a/y}{5/z}|a(x).R′)

≡ (νa)(νb)(P ′|a〈5〉.0|a(x).R′)

→ (νa)(νb)(P ′|0|R′{5/x})≡ (νa)(νb)(P ′|R′{5/x})≡ P ′|R′{5/x} für a, b 6∈ fv(P ′) ∪ fv(R′)


3.2.4 Funktionen

Im angewandten Pi-Kalkül können beliebige Funktionen definiert werden, die Terme aus Σ mit-einander verknüpfen. So ist beispielsweise die Definition von mehrstelligen Termen durch ent-sprechende Funktionen möglich. So kann ein 3-Tupel durch eine Funktion DreiTupel(x, y, z)beschrieben werden. Der Zugriff auf die einzelnen Elemente des Tupels erfolgt durch entspre-chende Stellenfunktionen:

erstes(DreiTupel(x, y, z)) = x

zweites(DreiTupel(x, y, z)) = y

drittes(DreiTupel(x, y, z)) = z

Nach [Bla09] können solche Funktionen als Konstruktoren und Destruktoren verwendet werden.Hierbei werden Konstruktoren für Terme der Form f(M1, . . . ,Mn) definiert. Daneben werdenDestruktoren der Form g(M1, . . . ,Mn) definiert. Diese Destruktoren werden nicht selbst in Ter-men verwendet, sondern dienen zur Verarbeitung von Termen innerhalb der Prozesse. Hierzuliegt für g(M1, . . . ,Mn) eine Menge von Reduktionsregeln der Form g(M ′

1, . . . ,M′n) → M ′

vor, die häufig Konstruktoren und Destruktoren paarweise in Beziehung zueinander setzen. EinBeispiel ist

Konstruktor: f(x1, x2)

Destruktor: g(f(x1, x2), x2)→ x1

Zur Definition der symmetrischen Verschlüsselung werden zwei parametrisierte Funktionsbe-zeichner für Verschlüsselung (encryption) und Entschlüsselung (decryption) eingeführt.

y = encs(x, k)

decs(y, k) = decs(encs(x, k), k)→ x

Hierbei sind x der Klartext, y das Chiffrat und k ein symmetrischer Schlüssel. Die Definition desDestruktors erfolgt dabei wie bereits eingeführt in Form einer Reduktionsregel.

In gleicher Weise lässt sich die asymmetrische Kryptographie beschreiben. Hierbei ist jedochzunächst die Beziehung zwischen öffentlichem und privatem Schlüsselteil zu modellieren. Dieskann durch eine generierende Funktion geschehen, die einem vorhandenen privaten SchlüsselK−1 sein öffentliches Pendant K zuordnet.

Schlüsselgenerierung K = pk(K−1)

Asymmetrische Verschlüsselung enca(x, pk(K−1))

Asymmetrische Entschlüsselung deca(enca(x, pk(K−1)), K−1)→ x

Regeln für Signaturverfahren mit Rückgewinnung der Nachricht:



Signatur von p mit Schlüssel K−1 sign(p,K−1)

Signaturprüfung checksign(sign(p,K−1), pk(K−1))→ p

Abspaltung der Nachricht getmessage(sign(p,K−1))→ p

Für Signaturverfahren ohne Rückgewinnung (or) der Nachricht:


Signatur von p mit Schlüssel K−1 signor(p,K−1)

Signaturprüfung checksignor(signor(p,K−1), pk(K−1), p)→ true

Nicht-umkehrbare Hash-Funktionen werden nur durch einen Konstruktor dargestellt.

Hash-Funktion h(x)

Ohne Destruktor ist daher auch kein Rückschluss auf das Argument der Hashfunktion möglich,außer dieses ist zuvor bekannt: h(x) = h(x′)⇔ x = x′.

3.3 Automatisierte Protokollanalysen mit Proverif

Für Analysen bei Protokollmodellierungen im angewandten Pi-Kalkül wurde durch Bruno Blan-chet in [Bla01] eine auf Prolog basierende Verifikationsmethodik vorgestellt, die in Form desModell-Checkers Proverif implementiert wurde [Bla11].

Proverif stellt eine Beschreibungssprache bereit, mit der Prozesse im Modell des angewandtenPi-Kalküls beschrieben werden können. Proverif unterstützt dabei eine untypisierte und eine ty-pisierte Variante. Die Modellierung der Prozesse kann durch Proverif automatisiert in ein Horn-Klausel-System überführt werden und durch einen Theorembeweiser auf Basis des Resolutions-verfahrens hinsichtlich vorgegebener Beweisziele überprüft werden [Bla09].

Mit Hilfe von Proverif können sowohl die Eigenschaft der Wahrung der Vertraulichkeit bestimm-ter Informationen als auch die Garantie der Authentizität von Nachrichten für das modellierteProtokoll nachgewiesen werden.

3.3.1 Notation und Semantik

Alle im angewandten Pi-Kalkül definierten Funktionen können in Proverif mit einer etwas mo-difizierten Notation dargestellt werden. Tabelle 3.4 setzt die beiden Notationen in Beziehung.

Es können in Proverif eigene Datentypen definiert werden und Formeln für Konstruktoren undDestruktoren angegeben werden. Der folgende Ausschnitt zeigt die Funktionsdefinition für dieGenerierung eines öffentlichen Schlüssels (Typ: pkey) aus einem privaten Schlüssel (Typ: skey),die Definition einer zweistelligen asymmetrischen Verschlüsselungsfunktion und die zugehörigeReduktion für die Entschlüsselung.

3.3 Automatisierte Protokollanalysen mit Proverif 59

angewandter Pi-Kalkül Proverif mit DatentypenP |Q P | Qa(x).P in(a, x : bitstring);Pa〈M〉.P out(a,M );Pif M = N then P elseQ if M = N then P else Q(νn).P new n: bitstring; P!P !P0 0{M/x} let x : bitstring = M in . . .

Tabelle 3.4: Gegenüberstellung der Schreibweisen von Pi-Kalkül und Proverif

type skey.type pkey.fun pk(skey): pkey.fun aenc(bitstring, pkey): bitstring.reduc forall m: bitstring, sk : skey; adec(aenc(m, pk(sk)), sk) = m.

Der Datentyp bitstring ist dabei ein bereits von Proverif vordefinierter Typ.Die gezeigte Definition entspricht den oben eingeführten Ausdrücken enca(x, pk(K−1)) unddeca(enca(x, pk(K−1)), K−1)→ x.

Übertragungskanäle zwischen den Prozessen werden durch die Definition einer freien Variablenmit dem channel-Typ durch „free c:channel.“ definiert. Alle freien Variablen, Konstanten undFunktionen werden als öffentlich bekannt betrachtet, sofern sie nicht durch den Zusatz privateals nicht öffentlich gekennzeichnet sind.

Neue, gebundene Namen sind per Definition nicht öffentlich und müssen ggf. explizit an Pro-zesse übergeben werden. Bei der Erzeugung eines asymmetrischen Schlüsselpaares für einenProzess userB kann durch einen Parameter in der Prozessdefinition der private Schlüssel skBvom Typ secret signing key (sskey) dem Prozess bekannt gemacht werden:

let userB(skB :sskey, . . .) =new d :bitstring;

. . .

.

process. . .new skB :sskey;let pkB = pk(skB) in. . .(. . . | (!userB(skB , . . .)) | . . .)


Um Eigenschaftsprüfungen modellieren zu können, wird in Proverif ein Destruktorg(M1, . . . ,Mn) = M innerhalb einer bedingten Zuweisung verwendet:

let x = g(M1, . . . ,Mn) in P elseQ

Da ein Destruktor eine partielle Funktion ist, wird die bedingte Zuweisung nach [AB05] wiefolgt definiert: Gibt es eine Substitution σ so, dass für jedes M ′

i gilt σM ′i = Mi und σM ′ = M ,

so wird P{M/x} fortgeführt, anderenfalls Q.

Der folgende Beispielprozess zeigt eine symmetrische Ver- und Entschlüsselung mit Definitioneines Konstruktors (Zeile 6), der zugehörigen Reduktion (Zeile 7), der Anwendung des Kon-struktors (Zeile 12) und des Destruktors (Zeile 14).

01 (* öffentlicher Kommunikationskanal *)02 free net:channel.0304 (* Verschlüsselung mit symmetrischen Schlüsseln *)05 type ekey.06 fun senc(bitstring, ekey): bitstring.07 reduc forall m: bitstring, k : ekey; sdec(senc(m, k), k) = m.0809 process10 new K :ekey;11 new d :bitstring;12 let encdata = senc(d ,K ) in13 . . .14 let decdata = sdec(encdata,K ) in15 out(net, decdata)16 else 0

In diesem Prozess ist die Zuweisung an die Variable decdata nur dann möglich, wenn der De-struktor sdec für die gegebene Variablenbelegung definiert ist. In diesem Fall ist

g(M1,M2) = M ≡ sdec(

M1︷︸︸︷senc(d ,K ),

M2︷︸︸︷K ) =

M︷︸︸︷d

g(M ′1,M

′2) = M ′ ≡ sdec(

M ′1︷︸︸︷senc(m, k),

M ′2︷︸︸︷k ) =

M ′︷︸︸︷m

Somit kann die Substitution σ : {d/m,K/k} angewendet werden. Damit ist g(σM ′1, σM

′2) =

g(M1,M2) und g(M1,M2) = σM ′ und der Prozessschritt out(net, decdata) kann mit {d/decdata}ausgeführt werden und somit wird das Datum d über den Kommunikationskanal net ausgegeben.

3.3 Automatisierte Protokollanalysen mit Proverif 61

3.3.2 Nachweis von Vertraulichkeit

Liegt eine Prozessmodellierung in Proverif vor, so können in der Prozessbeschreibung Beweis-ziele definiert werden. Hierzu werden Abfragen (queries) formuliert, die durch den Theorembe-weiser ausgewertet werden sollen.

Dabei wird das Angreifer-Modell von Dolev und Yao [DY83] zugrunde gelegt. Dieses Modellbeschreibt einen Angreifer, der vollständige Gewalt über alle Nachrichten hat, die über öffentli-che Kanäle übermittelt werden. Das bedeutet, dass er Nachrichten mitlesen, verzögern, löschen,verändern oder nach Belieben neu erzeugen kann. Verschlüsselte Nachrichten können gelesenwerden, deren Bedeutung bleibt jedoch verborgen, solange der geheime Schlüssel nicht zur Ver-fügung steht. Das initiale Wissen des Angreifers umfasst zudem alle Funktionen und Namen, dienicht als privat markiert sind. Jede Nachricht, die übertragen wird, ergänzt die Wissensmengedes Angreifers. Um die Vertraulichkeit eines Datums nachzuweisen, muss dieses zunächst alsgebundener Name erzeugt werden, wie z. B. der geheime Signaturschlüssel von userB. Die zuuntersuchende Fragestellung wird dann formuliert als query attacker(new skB).

Proverif prüft dann, ob die Eigenschaft „not attacker (new skA).“ gegeben ist, also ob derSchlüssel skA nicht zur Wissensmenge des Angreifers gehört. Dabei werden das Initialwissen,alle Nachrichten, die über öffentliche Kanäle übertragen werden und alle daraus durch Funktio-nen ableitbaren Terme berücksichtigt.

Gelingt der Nachweis, so wird das Beweisziel als wahr ausgegeben. Anderenfalls wird es alsfalsch gekennzeichnet und ein möglicher Ableitungsweg angegeben, mit dem es dem Angreifergelingt, das betrachtete Datum herzuleiten.

Zur Anwendung kommt dieses Verfahren beispielsweise bei der Analyse von Sicherheitsproto-kollen in [AB05].

3.3.3 Nachweis von Authentizität

Blanchet erweitert den angewandten Pi-Kalkül um die syntaktische Struktur event(M).P , diedas Eintreten eines Ereignisses anzeigt [Bla09]. M ist dabei ein Satz von Parametern.

Um Authentizität nachzuweisen wird zunächst festgelegt, dass ein Ereignis E bei einem Emp-fänger B, das einem Sender A zugeordnet wird, dann als authentisch in Bezug auf A gewertetwird, wenn zwingend ein anderes Ereignis E0 bei A vorausgegangen sein muss. Diesen Zusam-menhang bezeichnet Blanchet als Korrespondenz:

E ; E0

Statt eines Ereignisses E0 können auch verbundene Ereignisse mit dem betrachteten Ereigniskorrespondieren:

E ; E1 ∧ E2 ∧ . . . ∧ En


In Abfragen in Proverif wird diese Abhängigkeit durch die Notation ==> geschrieben.

Ein Beispiel für den Nachweis von Authentizität ist die Übermittlung eines signierten Datumsvon A an B.

query d :bitstring; event(received(d)) ==> event(newdata(d)).

(* Definition Teilprozess User A *)let userA(skA:sskey) =

new d :bitstring;event newdata(d);out(net, sign(d , skA)).

(* Definition Teilprozess User B *)let userB(pkA:pskey) =

in(net, signedData:bitstring);let d ′ = checksign(signedData, pkA) in

event received(d ′).

processnew skA:sskey;(!userA(skA) |!userB(pk(skA)))

Im Teilprozess userA wird ein neues Datum d erzeugt, signiert und über den Kanal net übertra-gen. userB empfängt das Datum und führt eine Signaturprüfung mit dem öffentlichen Schlüsselpk(skA) von userA aus.

Für jedes erzeugte Datum d wird ein Ereignis newdata und nach erfolgreicher Signaturprü-fung entsprechend ein received-Ereignis registriert. Da die Signaturprüfung nur dann erfolgreichist, wenn das Datum von userA signiert wurde, so muss einem received-Ereignis ein newdata-Ereignis vorausgehen und die in der Abfrage geprüfte Korrespondenz

received(d) ; newdata(d)

ist erfüllt.

Im Beispielprozess ist es für einen Angreifer möglich, ein signiertes Datum beliebig oft wie-derholt an userB zu senden. Zum Nachweis von frischen, authentischen Nachrichten wurde dieinjektive Korrespondenz definiert:

E ; [inj]E0

Diese Korrespondenz ist nur dann erfüllt, wenn zu jedem Ereignis E genau ein Ereignis E0

ausgeführt wird.

Ein ausführliches Anwendungsbeispiel zur Anwendung der Proverif-Modellierung findet sich inB.2.

4 Grammatikbasierte Zertifikate

Die im ersten Kapitel formulierten Ziele spannen einen breiten Anforderungskorridor auf, dernicht durch die in Kapitel 2 vorgestellten Verfahren abgedeckt werden kann. Ein wesentlichesProblem der vorliegenden Aufgabenstellung liegt im vordergründigen Widerspruch der Anfor-derungen Verständlichkeit und automatisierte Auswertung bei gleichzeitig geforderter Verbind-lichkeit durch Signaturen und Delegierbarkeit.

Wird eine Zusicherung als Textdokument erstellt, in der der Informationsgeber den genauenWortlaut seiner Erklärung niederlegt und anschließend signiert, so ist zwar die Verständlichkeitgegeben, jedoch eine automatische Weiterverarbeitung nicht einfach möglich.

Werden hingegen die wesentlichen Informationselemente einer Zusicherung strukturiert für dieautomatische Weiterverarbeitung aufbereitet und signiert, so ist zwar den Anforderungen dermaschinellen Verarbeitung Genüge getan, ein rechtssicheres Verständnis beim Informationsgeberoder bei Interpretation der Daten durch einen menschlichen Anwender ist jedoch schwierig odernicht möglich.

In diesem Kapitel wird ein neues Konzept grammatikbasierter Zertifikate vorgestellt, das es er-möglicht, die vorgegebenen Ziele zu erfüllen.

4.1 Darstellungsformen

Die Darstellung von Zusicherungen kann auf unterschiedliche Art und Weise erfolgen. Im Fol-genden werden zwei Darstellungsformen für Zusicherungen betrachtet, die jeweils einen Teil derAnforderungen abdecken können. Diese Darstellungsformen sind die textuelle und die struktu-rierte Form. Die beiden Formen werden durch ein Beispiel veranschaulicht.

4.1.1 Textuelle Darstellung

Bei der textuellen Darstellung handelt es sich um einen natürlichsprachlichen Text, der dem An-wender direkt ohne Hinzunahme von Auswertungswerkzeugen oder Interpretationsfestlegungenverständlich ist.

Diese Vorgabe schließt jedoch explizit keine Allgemeinverständlichkeit ein. Es kann sich beiden Texten – insbesondere im Fall der Zusicherung von Sicherheitseigenschaften – um eine

63

64 Kapitel 4. Grammatikbasierte Zertifikate

Fachsprache für ein spezielles Anwendungsfeld handeln. Im Rahmen dieser Arbeit wird davonausgegangen, dass es sich bei den Texten um Aussagesätze handelt, deren Wahr-sein durch dieErstellung einer Zusicherung bestätigt wird.

Als Beispiel zur Einführung der unterschiedlichen Darstellungsformen wird eine Auditierungdes Einsatzes von Kryptoservern mit Hochsicherheitsmodulen (HSM) betrachtet. Im Rahmeneiner solchen Prüfung wird häufig nachvollzogen, nach welchen Prüfverfahren wie FIPS oderCommon Criteria ein Gerät zertifiziert wurde. Darüber hinaus wird geprüft, ob das Gerät logischund physikalisch noch in unverändertem Zustand ist und somit auch die Prüfgrundlage für dieerteilten Zertifizierungen noch gegeben ist. Alternativ können für durchgeführte Änderungendurch Herstellererklärungen wiederum neue Firmware-Module legitimiert werden.

Ein entsprechendes (verkürztes) natürlichsprachliches Protokoll einer solchen Prüfung könntebeispielsweise folgende Formen haben:

Es wurde der Kryptoserver cryptsrv1 in Serverschrank S-7009 auditiert.Das HSM hat folgende Zertifizierungen:– FIPS 140-2 Level 3– ZKA-ZulassungDie Firmwaremodule entsprechen dem Evaluierungszustand.Die Siegel an den Schnittstellen sind ungebrochen.

oder auch

Es wurde das Kryptomodul nciphercrypt1 im Hostsystem lcryptsrv in ServerschrankS-8011 auditiert.Das HSM hat folgende Zertifizierungen:– FIPS 140-2 Level 3Die Firmwaremodule entsprechen nicht dem Evaluierungszustand.Folgende Module wurden veraendert bzw. ergaenzt:– pin-1.0.2.mod– basefunc-1.3.4.modDie Siegel an den Schnittstellen sind ungebrochen.

Die Aussagen sind lesbar und im Anwendungsbereich Sicherheitsprüfungen direkt durch denAnwender interpretierbar. Im Weiteren wird die natürlichsprachliche textuelle Form als primäreForm oder auch Primärtext p bezeichnet.

4.1.2 Strukturierte Darstellung

Zur einfachen automatisierten Weiterverarbeitung der gegebenen Informationen ist eine struktu-rierte Darstellung der Informationen unerlässlich.

4.1 Darstellungsformen 65

Eine mögliche Strukturierung besteht darin, jede Information, die in der textuellen Form enthal-ten ist, durch ein (ggf. hierarchisch angeordnetes) Strukturelement darzustellen. Diesem Struktu-relement wird außerhalb der strukturierten Daten die Bedeutung zugeordnet, die aus dem Satz inder textuellen Darstellung hervorgeht. Im allgemeinen Fall stehen einzelne Informationselemen-te in ebenfalls hierarchischen Beziehungen zueinander, so dass dadurch baumartige Strukturenentstehen, die ermöglichen, den in den Blättern angeordneten Angaben und den Bezeichnern vonKnoten jeweils durch ihre Position im Baum eine Bedeutung zuzuordnen. Dabei lassen sich ausden jeweils übergeordneten Knoten des Baumes die Zusammenhänge von Teilbäumen in einemübergeordneten Kontext ableiten.

Der Informationsgehalt der Auditierung aus dem zweiten Beispiel im vorigen Abschnitt ist inAbbildung 4.1 auf diese Weise graphisch als Baumstruktur dargestellt. Es sind gegenüber dertextuellen Darstellung zusätzliche Metainformationen enthalten (Typ Name) und nicht jede Kon-textinformation ist ablesbar (aus dem Teilbaum Firmware ist beispielsweise nicht erkennbar,dass die Nennung der darunter liegenden Firmware-Module eine Abweichung von der Standard-Firmware impliziert).

Abbildung 4.1: Strukturierte Darstellung des Informationsgehalts einer Zusicherung

Die analoge Darstellung in maschinenlesbarer Form kann beispielsweise durch das XML-Formatgeleistet werden:

<?xml version="1.0" encoding="UTF-8"?><Satz>

<HSMSystem><Modul>

<Name>nciphercrypt1</Name><Host>lcryptsrv</Host><Schrank>S-8011</Schrank>

</Modul></HSMSystem><Zertifizierung>FIPS 140-2 Level 3</Zertifizierung><Firmware>

<FWModul>pin-1.0.2.mod</FWModul><FWModul>basefunc-1.3.4.mod</FWModul>

</Firmware><Siegel>ungebrochen</Siegel>

</Satz>


Bei den gewählten Darstellungsformen handelt es sich um sog. semi-strukturierte Daten, da siezwar eine Struktur aufweisen, diese jedoch im Gegensatz zu starren Strukturen wie in Daten-banktabellen variieren kann. Im weiteren wird jedoch lediglich der Begriff strukturierte Datenhierfür verwendet. Diese Darstellungsform wird auch als sekundäre Form bezeichnet. Mit die-sem Begriff wird impliziert, dass diese Form aus der primären, textuellen Form unter noch zubetrachtenden Randbedingungen ableitbar ist.

Auf diese Weise strukturierte Daten können einfach weiterverarbeitet werden. Für eine korrekteInterpretation werden jedoch zusätzliche Informationen benötigt.

4.2 Zusicherungen als Textbausteine

4.2.1 Formerfordernis

Der Einsatz von Zusicherungen mit der Möglichkeit zur automatisierten Auswertung ist in ersterLinie da sinnvoll, wo wiederholt gleichartige oder ähnliche Zusicherungen benötigt werden.

Bei Sicherheitsanalysen nach Kapitel 1 werden i. d. R. eine große Zahl vorgegebener Prüfschrit-te abgearbeitet und die zugehörigen Ergebnisse dokumentiert. Werden die Prüfungen periodischdurchgeführt, so ist neben der genauen Vorgabe auch eine festgeschriebene Form der Dokumen-tation wie Formulare oder Textbausteine sinnvoll. Durch Vorgabe solcher Bausteine kann so-wohl sichergestellt werden, dass die durch den Auditor getroffene Aussage den inhaltlichen undformalen Anforderungen an eine Sicherheitsüberprüfung genügt als auch die Vergleichbarkeitverschiedener Durchführungen der gleichen Prüfung gewährleistet wird.

Es stellt daher keine Einschränkung des Anwendungsfalles dar, für die textuelle Darstellung einerZusicherung zu fordern, dass sie zunächst beliebig gewählt werden kann, dann jedoch hinsicht-lich der verwendeten Formulierungen fest bleibt.

Zusicherungen, die zum gleichen Anwendungsfall wie beispielsweise der Auditierung der HSMsim vorigen Abschnitt gehören, sollen daher grundsätzlich aus gleichartigen Bestandteilen (Text-elementen, Phrasen, ...) bestehen und ggf. variable Elemente wie z. B. Namen enthalten. Es wirddaher angenommen, dass es für einen konkreten Anwendungsfall eine Beschreibung gibt, aus dersich ableiten lässt, wie die Formulierung einer Zusicherung gestaltet sein muss. Die Festlegungsoll sich dabei auf die vollständige Ausgestaltung des Textes beziehen, d. h. alle Freiheitsgradebei der Erstellung von Zusicherungen sollen definiert sein. Es handelt sich also bei den Zusiche-rungen nicht um frei wählbare Aussagen, die bestimmte Strukturen aufweisen. Diese Texte sindsomit Elemente einer Domänen-spezifischen Sprache.

4.2.2 Vorgabe von Textbausteinen

Unter einem Textbaustein werden vorgefertigte Textelemente verstanden, die ggf. miteinanderkombiniert werden können und Platzhalter für individuelle Ergänzungen vorsehen. Im erstenSchritt werden statische Textelemente definiert.

4.2 Zusicherungen als Textbausteine 67

Ein statischer Textbaustein wird definiert als eine festgelegte Folge von Zeichen aus einem Zei-chenvorrat Σ. Der Zeichenvorrat umfasst dabei die Buchstaben der natürlichen Sprache, Ziffernsowie Leer- und Satzzeichen. Ein Beispiel eines Zeichenvorrats für deutsche Zusicherungen ist

Σ = {’a’, . . . , ’z’, ’A’, . . . , ’Z’, ’ä’, ’ö’, ’ü’, ’Ä’, ’Ö’, ’Ü’, ’ß’} ∪{’0’, . . . , ’9’} ∪ {’,’, ’.’, ’:’, ’;’, ’_’, ’-’, ’ ’}

Für statische Textbausteine T wird festgelegt, dass diese nicht leer sein dürfen, also T ∈ Σ+. DieNotation Σ+ beschreibt die Menge aller möglichen Folgen von Zeichen aus Σ mit Mindestlängeeins. Ein Beispiel für einen statischen Textbaustein ist

Alle Personen mit Zugang zum geprüften System wurden sicherheitsüberprüft. Esliegen für alle Personen Führungszeugnisse vor, die innerhalb der letzten zwei Jahreausgestellt wurden.

Zusicherungen können aus mehreren Textbausteinen zusammengesetzt werden. Diese werdendurch Aneinanderreihung gebildet. Eine natürlichsprachliche Darstellung p kann damit alsp = T1T2T3 . . . Tn mit T1, . . . , Tn ∈ Σ+ geschrieben werden. Die Bezeichner für die Textbau-steine können beliebig gewählt werden.

4.2.3 Variable Bestandteile

Da es für Zusicherungen i. d. R. verschiedene Varianten gibt und Zusicherungen z. B. für ein kon-kretes System individualisiert werden sollen, ist es notwendig, variable Bestandteile vorzusehen,die durch den Bestätiger ausgewählt oder eingesetzt werden können.

4.2.3.1 Bausteinebene

Werden für eine Zusicherung Varianten vorgesehen, die sich jeweils durch einen eigenen Text-baustein darstellen lassen, so kann dies durch die Notation Tx|Ty dargestellt werden. Es könnendabei wahlweise die Textbausteine Tx oder Ty eingesetzt werden. Zur Anwendung kommt ei-ne solche Auswahlmöglichkeit für Alternativen wie z. B. Die Eignung der Komponente wurdedurch eine Evaluationsurkunde belegt. und Für die Komponente wurde als Eignungsnachweiseine Herstellererklärung abgegeben. Damit lassen sich Mengen von darstellbaren Primärtextenz. B. in der Form T1(Tx|Ty)T2 ausdrücken.

Auswahlmöglichkeiten lassen sich durch eigene Bezeichner kennzeichnen und in einer Men-ge der variablen Textbausteine zusammenfassen. Jeder dieser variablen Textbausteine legt fest,durch welche anderen statischen oder variablen Textbausteine er ersetzt werden kann. Ein varia-bler Textbaustein stellt somit eine Ersetzungsregel dar.

Ein variabler Textbaustein kann als Anfangspunkt festgelegt werden. Durch fortgesetzte Anwen-dung von Ersetzungsregeln können solange variable Textbausteine ersetzt werden, bis lediglicheine Verkettung von statischen Textbausteinen übrig bleibt.

Ein einfaches Beispiel soll diese Zusammenhänge verdeutlichen. Für Aussagen der Form


Das geprüfte System wurde nach BSI-Grundschutz gehärtet. Für alle individuellenBenutzerkonten wurden genehmigte Anträge vorgelegt.

Das geprüfte System ist entsprechend der Arbeitsanweisung AA-2010-237 gehärtet.Es gibt keine individuellen Benutzerkonten.

können folgende Textbausteine festgelegt werden.

Statische BausteineH1 ‘Das geprüfte System wurde nach BSI-Grundschutz gehärtet. ’H2 ‘Das geprüfte System ist entsprechend der Arbeitsanweisung AA-2010-237 gehärtet. ’B1 ‘Für alle individuellen Benutzerkonten wurden genehmigte Anträge vorgelegt. ’B2 ‘Es gibt keine individuellen Benutzerkonten. ’

Variable BausteineVH H1|H2

VB B1|B2

Z VHVB

Eine Zusicherung (Baustein Z) besteht aus einem variablen Baustein VH für die Härtungsop-tionen und einem variablen Baustein VB für die Angaben zu den Benutzerkonten. Für VH undVB stehen jeweils zwei Alternativen zur Verfügung, so dass insgesamt vier Varianten für dieZusicherung möglich sind.

4.2.3.2 Feldebene

Zusicherungen können auch durch frei oder in Grenzen wählbare Angaben individualisiert wer-den. Ein Beispiel für eine solche Angabe sind Servernamen, die nicht in den Textbausteinenenthalten sind oder Zahlwerte wie Port-Nummern, IP-Adressen, usw. Für diese Angaben wer-den üblicherweise Formatvorgaben in Form von Datentypen wie Integer, String oder Timestampgemacht. Häufig werden zu diesen Datentypen auch Prüfausdrücke in Form von regulären Aus-drücken definiert.

Reguläre Ausdrücke sind formalisierte Vorlagen zur Durchführung eines Mustervergleichs mitZeichenketten. Dabei enthalten diese Vergleichsmuster u. a.

q normale Zeichen, die in der Zeichenkette enthalten sein müssen

q Platzhalter für beliebige Zeichen: ‘.’

q Platzhalter für bestimmte Zeichenmengen: [A-Z], [0-9], . . .

q Quantoren: *, +, ?

q Klammern zur Gruppierung: (abc)+

q Alternativen: (abc | cde)

4.3 Nutzung kontextfreier Grammatiken 69

Die Quantoren geben dabei die mögliche Häufigkeit des davor stehenden Elementes an (*: kein-mal oder beliebig oft, +: einmal oder beliebig oft, ?: keinmal oder einmal).

Ein Integer-Wert ohne führende Nullen wird beispielsweise durch den regulären Ausdruck[1-9][0-9]+ beschrieben. Eine ausführliche Darstellung regulärer Ausdrücke findet sich in[Fri06].

Solche gestaltbaren Felder können durch Zuordnung eines variablen Textbausteins zur Bezeich-nung eines Datentyps und damit mittelbar zu einem Prüfausdruck realisiert werden.

Beispielsweise kann ein Servername anstelle des Ausdrucks „Das geprüfte System ...“ angege-ben werden. Damit wird das oben angegebene Beispiel wie folgt modifiziert:

Statische BausteineH0 ‘Der Server ’H1 ‘ wurde nach BSI-Grundschutz gehärtet. ’H2 ‘ ist entsprechend der Arbeitsanweisung AA-2010-237 gehärtet. ’B1 ‘Für alle individuellen Benutzerkonten wurden genehmigte Anträge vorgelegt. ’B2 ‘Es gibt keine individuellen Benutzerkonten. ’

Variable BausteineVH H1|H2

VB B1|B2

S1 StringZ H0S1VHVB

Frei wählbare Zeichenketten werden zur Unterscheidung vom festgelegten umgebenden Textdurch Anführungszeichen abgetrennt. Eine konkrete Ausprägung für den Anfang der oben de-finierten Zusicherung kann damit beispielsweise heißen: Der Server “mailsrv1” wurde nachBSI-Grundschutz gehärtet.

4.3 Nutzung kontextfreier Grammatiken

Ob eine Zusicherung in Form einer Zeichenkette die Anforderungen an die Strukturvorgabeneines bestimmten Anwendungsfalles erfüllt und damit ein geeigneter Primärtext ist, soll mittelseiner Prüffunktion entschieden werden.

Diese Anforderung lässt sich durch die Vorgabe einer sog. kontextfreien Grammatik für die in-nerhalb eines Anwendungsfalles zulässigen Zusicherungen umsetzen. Die Prüfung der syntakti-schen Korrektheit einer Zusicherung kann durch einen für diese Grammatik entworfenen Parsererfolgen.

Durch die Vorgabe der Grammatik erkennt der Parser die Strukturen und Formate der Eingangs-daten, kann diese in ihre Bestandteile zerlegen und ggf. fehlerhafte Eingangsdaten zurückweisen(validierender Parser). Damit ist es auch möglich, durch geeignete Gestaltung der kontextfrei-en Grammatik die hierarchisch aufeinander aufbauenden Informationsbestandteile, die für einestrukturierte Darstellung benötigt werden, zu extrahieren.


Kontextfreie Grammatiken kommen i. d. R. zur Beschreibung von Programmiersprachen undähnlich syntaktisch konkret festgelegten Textdarstellungen zum Einsatz. Die Elemente zur De-finition einer Grammatik entsprechen den bereits eingeführten Elementen zur Beschreibung derZusicherungen.

4.3.1 Prinzip der kontextfreien Grammatik

Die statischen Textbausteine einer Zusicherung werden als Terminale und die variablen Baustei-ne als Nicht-Terminale bezeichnet. Entsprechend sind die Mengen T als Menge der TerminaleundN als Menge der Nicht-Terminale definiert. Die Ersetzungsregeln für Nicht-Terminale wer-den als Produktionen bezeichnet und in einer Menge P zusammengefasst. Zusätzlich wird einStartsymbol S definiert.

Zusicherungen lassen sich somit durch eine anwendungsfallspezifische formale Grammatik

G =< N , T ,P , S >

beschreiben.

Die Grammatik soll kontextfrei sein, d. h. die Produktionsregeln sind jeweils für genau ein Nicht-Terminal auf der linken Seite definiert: P ⊂ N × (N ∪ T )+. In der Chomsky-Hierarchie vonGrammatiken entspricht dies dem Typ 2 [Cho59].

Ein Element p aus P wird geschrieben als p = N → α. Das Nicht-Terminal N kann bei Anwen-dung der Produktionsregel p durch die Symbolfolge α ersetzt werden.

Soll eine Zeichenfolge, die den Regeln der Grammatik G entspricht, konstruiert werden, so wer-den ausgehend von S die Produktionsregeln solange angewendet, bis durch Ersetzungen keinNicht-Terminal mehr in der Symbolfolge enthalten ist.

S →G α1 →G . . .→G α2 →G w

w ∈ T + wird als Ableitung von S (oder Wort) bezeichnet. Die Folge von Anwendungen derProduktionsregeln kann auch verkürzt als S →∗G w geschrieben werden.

Die Menge aller dieser aus S ableitbaren Symbolfolgen (oder auch Worte w) wird Sprache vonG genannt (Schreibweise L (G)):

L (G) = {w|∃S →∗G w,w ∈ T +}

In der Menge T kann auch das Symbol ε enthalten sein, das das sog. „leere Wort“ repräsentiert.

Neben der Kontextfreiheit wird für den vorliegenden Anwendungsfall gefordert, dass die Gram-matik so gestaltet sein soll, dass keine Ableitung das leere Wort ergibt (ε 6∈ L (G)).


4.3.2 Beispiel einer Grammatik

Als Beispiel wird für die folgenden drei Varianten einer Zusicherung eine mögliche Grammatikangegeben.

Auf dem Server cntsrv1 wurden alle nicht benötigten Dienste abgeschaltet.Die Korrektheit der Dienstkonfiguration wurde mittels netstat-Befehl geprüft.Die aktiven Dienste sind:ssh auf Port 22http auf Port 80https auf Port 443

Auf dem Server cntsrv2 wurden alle nicht benötigten Dienste abgeschaltet.Die Korrektheit der Dienstkonfiguration wurde mittels Portscan geprüft.Die aktiven Dienste sind:ssh auf Port 22http auf Port 80https auf Port 443

Auf dem Server mailsrv wurden alle nicht benötigten Dienste abgeschaltet.Die Korrektheit der Dienstkonfiguration wurde mittels netstat-Befehl geprüft.Die aktiven Dienste sind:ssh auf Port 22smtp auf Port 25

Im festen Grundaufbau der Aussage variieren Servername, Prüfmethode und die Liste mit denjeweiligen Diensten und Ports.

Eine entsprechende Grammatik fasst konstante Teile in Terminalsymbole zusammen. Dies kön-nen auch Teilsätze wie „Auf dem Server“ sein. Die Bezeichner der Nicht-Terminale werdendabei so gewählt, dass sie dem semantischen Gehalt des jeweils durch die Ersetzungsregel abge-deckten Teilstrings gerecht werden.

Der durch die Grammatik eingeräumte Freiheitsgrad ist gestaltbar. So könnte anstelle einer Listevon Servernamen auch ein Literal vom Typ STRING angegeben werden. In diesem Fall kann derErsteller der Zusicherung einen beliebigen (in Hochkomma gefassten) Servernamen eintragen.

Das eingeführte Beispiel kann durch die in Tabelle 4.1 dargestellte Grammatik erzeugt werden.

Die Verwendung des |-Symbols dient der verkürzten Darstellung von Alternativen:

A→ B|C|D ≡

A→ BA→ CA→ D

Die Quantoren ?,+ und ∗ sind identisch zu denen der regulären Ausdrücke in Abschnitt 4.2.3.2definiert. Die Zeichenfolge ’\n’ steht für einen Zeilenumbruch.

Somit stellt die Grammatik G eine Beschreibung für die erlaubten Zusicherungsformen dar. Alleerlaubten Zusicherungsformen bilden gemeinsam eine Klasse von Zusicherungen.


P =

Satz → Mn5_72Mn5_72 → ’Auf dem Server ’ Server ’ wurden alle nicht

benötigten Dienste abgeschaltet.\n’ Pruefung? ’Dieaktiven Dienste sind:\n’ Dienste?

Dienste → Dienst+Dienst → Dienstname ’ auf Port ’ Portnummer ’\n’

Portnummer → INTDienstname → ’ssh’ | ’dns’ | ’smtp’ | ’http’ | ’https’ | ’ntp’

Pruefung → ’Die Korrektheit der Dienstkonfiguration wurdemittels ’ Methode ’ geprüft.\n’

Methode → ’Portscan’ | ’nmap-Befehl’ | ’netstat-Befehl’Server → ’cntsrv1’ | ’cntsrv2’ | ’cntsrv3’ | ’mailsrv’

INT → (’0’|’1’|’2’|’3’|’4’|’5’|’6’|’7’|’8’|’9’)+

N =

{Dienst, Dienste, Dienstname, INT, Mn5_72, Methode, Portnummer, Pruefung,Satz, Server

}

T =

’Auf dem Server ’, ’Die Korrektheit der Dienstkonfiguration wurde mittels ’,’Die aktiven Dienste sind:\n’, ’Portscan’, ’\n’, ’ auf Port ’, ’cntsrv1’, ’cntsrv2’,’cntsrv3’, ’dns’, ’ geprüft.\n’, ’http’, ’https’, ’mailsrv’, ’netstat-Befehl’,’nmap-Befehl’, ’smtp’, ’ssh’, ’ wurden alle nicht benötigten Diensteabgeschaltet.\n’

S = Satz

Tabelle 4.1: Kontextfreie Grammatik für Zusicherungen nach Grundschutz-Maßnahme M 5.72

4.3.3 Das Wortproblem

Das Wortproblem ist das Entscheidungsproblem, ob ein Wort w – i. S. einer Ableitung – zurSprache L (G) einer Grammatik G gehört. Für die Aufgabenstellung Zusicherungen entspre-chend einer vorgegebenen Syntax auszustellen, stellt sich dieses Entscheidungsproblem, wenngeprüft werden soll, ob eine gemachte Zusicherung aus dem durch die Grammatik vorgegebenenSprachumfang stammt.

Um diese Prüfung durchzuführen, werden i. d. R. validierende Parser eingesetzt. Hierbei wird diezu prüfende Zeichenfolge (z. B. die gegebene Zusicherung) symbolweise auf Basis der Produk-tionsregeln der Grammatik analysiert.

Für die Ausführung des Parsings gibt es eine Reihe von Parsing-Algorithmen. Diese werdenim Allgemeinen nach ihrer Arbeitsweise klassifiziert. Es werden die grundsätzlichen Verfah-ren Top-Down-Parser und Bottom-Up-Parser unterschieden. Typische Vertreter dieser Katego-rien sind u. a. die LL- bzw. die LR-Parser. Die LL-Parser nach dem Top-Down-Prinzip parsenvon Links nach Rechts und führen dann eine Linksableitung durch, bei der die Abarbeitung der


Nicht-Terminale in den Produktionsregeln von der linken Seite her erfolgt. Die LR-Parser füh-ren als Bottom-Up-Parser eine Rechtsreduktion durch, d. h. sie arbeiten die Produktionsregelnvon der rechten Seite her ab und ersetzen Symbolsequenzen durch Nicht-Terminale bis hin zumStartsymbol [GJ90].

Auf die konkrete Auswahl eines Parsing-Verfahrens und die daraus resultierenden Anforderun-gen an die Grammatik wird in Kapitel 5 eingegangen.

Bei der Prüfung der Zugehörigkeit einer Zeichenfolge w zum Sprachumfang L (G) einer Gram-matik G werden, sofern w ∈ L (G) gilt, die Entscheidungen des Erstellers der Zeichenfolgenachvollzogen. Die jeweils angewendeten Produktionsregeln können dann in einer Baumstruk-tur dokumentiert werden, dem sog. Syntaxbaum.

Für die einfache Grammatik

S → X | bY

X → aXY | aY

Y → bY | c

ergibt sich für die Eingangsfolge aabcbbc der Syntaxbaum nach Abbildung 4.2.

S

X

X Y

Y

Y

Y

Y

a

a

b

c

b

b

c

Abbildung 4.2: Beispiel eines einfachen Syntaxbaumes

Durch eine Tiefensuche, die die Blätter des Baumes von links nach rechts durchläuft, kann die er-zeugende Eingangsfolge abgelesen werden. Ein Syntaxbaum, der direkt aus dem Parse-Vorganggewonnen wird und alle dabei genutzten Token bzw. Zeichen enthält, wird als konkreter Syntax-baum bezeichnet.

Wird eine Grammatik G zur Beschreibung einer Klasse von Zusicherungen verwendet, so sollendie Elemente w ∈ L (G) als gültige Zusicherungen über G bezeichnet werden.


4.3.4 Syntaxbaum als strukturierte Darstellung

Ein konkreter Syntaxbaum entspricht – bei geeigneter Wahl der Grammatik – der in Abschnitt 4.1.2vorgeschlagenen strukturierten Darstellung einer Zusicherung.

Ein möglicher Syntaxbaum für die bereits auf Seite 72 dargestellte Grammatik kann Abbil-dung 4.3 entnommen werden.

\n

\n

\n

Abbildung 4.3: Konkreter Syntaxbaum

Das Nicht-Terminal INT war bei der Erstellung des Syntaxbaumes nach Abbildung 4.3 als sog.Lexem deklariert. Dadurch wird kein INT-Knoten eingefügt, sondern die durch die INT-Produk-tionsregel abgedeckten Zeichen werden als eine zusammengefasste Zeichenkette in den Baumaufgenommen.

Der Informationsgehalt des Syntaxbaumes umfasst somit zum einen den ursprünglichen Textder Zusicherung. Zusätzlich ist diese Information noch durch die Zuordnung zu den einzelnenKnoten strukturiert. Aus der Strukturinformation der Knoten lässt sich den verschiedenen Teilender Zusicherung (die jeweils durch die Teilbäume gebildet werden) eine entsprechende Knoten-beschriftung und damit ggf. eine Bedeutung zuordnen. Die zur Kodierung des Syntaxbaumesbenötigte Datenmenge ist jedoch auch entsprechend größer als der ursprüngliche Primärtext.

Bei der automatischen Verarbeitung eines solchen Syntaxbaumes kann, ausgehend vom Wurzel-symbol, ein Teilbaum extrahiert werden. Soll beispielsweise die Prüfmethode extrahiert werden,so wird der Teilbaum Satz/Mn5_72-Pruefung/Methode betrachtet.

4.3.5 Optimierung durch abstrakte Syntaxbäume

Der konkrete Syntaxbaum enthält alle Terminale, die in den bei der Analyse angewendeten Pro-duktionsregeln enthalten sind. Liegen jedoch sowohl der Syntaxbaum als auch die zugehörige


Grammatik vor, so ist die Angabe etlicher Terminale redundant. Ein Beispiel einer redundan-ten Angabe ist das Terminal „ auf Port “ im Knoten bzw. der Produktionsregel Dienst. Aus derGrammatik geht hervor, dass dieser Bestandteil immer an dieser Stelle enthalten sein muss.

Diese bei Programmiersprachen häufig auch als „syntaktischer Zucker“ bezeichneten Teile sindzwar in der primären Darstellungsform für die Lesbarkeit und die Verständlichkeit notwendig,werden jedoch in der sekundären Form für eine Auswertung der Daten und für eine Rückgewin-nung des Textes nicht zwangsläufig gebraucht.

Daher können alle Terminale, für die keine Wahlmöglichkeiten vorgesehen sind, aus dem Syn-taxbaum entfernt werden, da sie keine Information (bei vorhandener Grammatik) tragen. Derentsprechend optimierte sog. abstrakte Syntaxbaum (engl. abstract syntax tree (AST)), der demBeispiel aus Abbildung 4.3 entspricht, ist in Abbildung 4.4 zu sehen.

Abbildung 4.4: Abstrakter Syntaxbaum

Um genau bestimmen zu können, was unter einem redundanten Terminal zu verstehen ist, sollenzunächst einige Festlegungen getroffen werden.

Für die betrachteten Grammatiken sollen folgende Eigenschaften gegeben sein:

q Die Grammatik liegt ohne Klammern vor.

q Quantoren (?,+, ∗) werden nur auf Nicht-Terminale angewendet.

q Die Grammatik G ist eindeutig.

Da Klammern beim Analysevorgang zu implizit definierten Knoten im Syntaxbaum führen, istdie Entfernung durch Ersetzen jedes geklammerten Ausdrucks durch ein neues Nicht-Terminalsinnvoll. Dadurch erhalten die zugehörigen Knoten im Syntaxbaum einen explizit gewähltenBezeichner und können in späteren Verarbeitungsschritten besser referenziert werden.


Werden Quantoren (?,+, ∗) auf Terminale angewendet, so kann ein solches Terminal nicht ausdem Syntaxbaum entfernt werden, da sein Vorhandensein einen Informationsgehalt hinsichtlichder Wahlmöglichkeiten darstellt. Wird ein quantisiertes Terminal benötigt, so kann ein zusätzli-ches mit einem Quantor versehenes Nicht-Terminal definiert werden, das auf seiner rechten Seitelediglich aus dem zu quantisierenden Terminal besteht.

Die Eigenschaft der Eindeutigkeit einer Grammatik besagt, dass es zu jedem mit der Grammatikerzeugbaren Wort genau eine Ableitung gibt. Diese Eigenschaft ist für das korrekte Funktioniereneines Parsers notwendig und kann durch Tests nachgewiesen werden [Sch01].

Bei der Rückgewinnung müssen in jedem Knoten des AST genügend Informationen enthaltensein, um eindeutig die Produktionsregel zu identifizieren, aus der der Knoten des AST abgeleitetwurde.

Da der Knotenname dem Nicht-Terminal der linken Seite der verwendeten Produktionsregel ent-spricht, sind die unterhalb des Knotens liegenden Knoten bzw. Blätter nur für die Differenzierunginnerhalb der Produktionsregeln eines Nicht-Terminals notwendig.

Die Größe des Entscheidungsraumes eines AST-Knotens entspricht der Anzahl der zugehörigenProduktionsregeln (hierbei werden über „|“ getrennte Regelalternativen als eigenständige Regelngezählt). Für eine Grammatik G = 〈N , T ,P , S〉 und ein Nicht-Terminal N ∈ N ist die Mengeder zugehörigen Produktionsregeln

PN = {P |P ∈ P ∧ LS(P ) = N}

Die Funktion LS liefert das Nicht-Terminal der linken Seite der Produktion. Die Größe deszugehörigen Entscheidungsraumes ist |PN |. Alle Produktionsregeln aus PN haben paarweisedisjunkte rechte Seiten. Werden nun aus den Produktionsregeln aus PN alle Terminale entfernt,so entsteht eine neue Menge P ′N .

Wenn nach dem Entfernen der Terminale zwei oder mehr der neu entstandenen Produktionsre-geln die gleiche rechte Seite aufweisen, so sind diese Regeln nicht mehr unterscheidbar. Somitist |P ′N | < |PN |. Ist jedoch |P ′N | = |PN |, so ist der Entscheidungsraum auch nach Streichungder Terminale gleich groß. Die Speicherung der Terminale im AST ist somit redundant und siekönnen daher aus dem AST entfernt werden.

4.3.6 Rückgewinnung

Die Transformation, die einen Primärtext p mittels einer Grammatik G in einen konkreten unddurch Vereinfachung in einen abstrakten Syntaxbaum X transformiert, wird im Folgenden durchΦG beschrieben. Dabei steht das Symbol ⊥ für „falsch“ oder „ungültig“.

ΦG(p) =

{X wenn p ∈ L (G)⊥ sonst (4.1)

Φ−1G (X) =

{p wenn X = ΦG(p), X 6= ⊥⊥ sonst (4.2)

4.4 Entwurf grammatikbasierter Zertifikate 77

Damit übernimmt ΦG sowohl die Prüfung des Wortproblems als auch die Kodierung der struk-turierten Daten. Die Umkehrfunktion Φ−1G soll als Rückgewinnung des Primärtextes bezeichnetwerden.

Bei der Rückgewinnung kann wie bei der Tiefensuche zur Ermittlung des ursprünglichen Textesauf dem konkreten Syntaxbaum vorgegangen werden. Allerdings ist hierzu ein sog. Baumparsernotwendig, der bei der Bearbeitung eines Knotens jedes aufgrund der Redundanz zuvor entfernteTerminal wieder an der richtigen Stelle einfügt.

Wird z. B. einer der „Dienst“-Knoten aus Abbildung 4.4 bearbeitet, so hat dieser lediglich dieKindknoten „Dienstname“ und „Portnummer“. Ein Vergleich mit Abbildung 4.3 bzw. der zu-gehörigen Produktionsregel zeigt, dass nach Auswertung des ersten Kindknotens „Dienstname“das Terminal „ auf Port “ und nach dem letzten Knoten das Terminal „\n“ ergänzt werden muss.

Der Vergleich des konkreten Syntaxbaumes in Abbildung 4.3 mit der abstrakten Variante inAbbildung 4.4 zeigt außerdem, dass die Abstraktion in Anwendungsfällen mit Terminalen, dieganze Textpassagen enthalten, zu einer erheblich kürzeren Kodierung führen kann.

Bei größeren Mengen zu speichernder Zusicherungen ist damit die Kodierung einer Zusicherungin der sekundären Form auch dann sinnvoll, wenn keine Verarbeitung der strukturierten Datenerfolgt, sondern ggf. nur der Primärtext zurückgewonnen werden soll.

4.4 Entwurf grammatikbasierter Zertifikate

Für die geschützte, vertrauenswürdige Übertragung von Zusicherungen existieren bereits etli-che Verfahren für spezielle Anwendungsfälle (vgl. Kapitel 2). Daher ist hier kein neuer Entwurfnotwendig und es wird für das Grundgerüst der grammatikbasierten Zertifikate (Grammar-basedCertificates, GC) auf den bewährten Mechanismus der X.509-Zertifikate zurückgegriffen. Damitkönnen Verarbeitungsschritte wie Signaturprüfung, Abruf von Sperrinformation und die Etablie-rung öffentlicher Schlüssel als gegeben vorausgesetzt werden.

Im Weiteren wird grundsätzlich angenommen, dass Bestätiger von Zusicherungen über geeig-netes asymmetrisches Schlüsselmaterial und zugehörige gültige Schlüsselzertifikate (z. B. nachX.509) verfügen. Ebenso sollen bei den Empfängern von signierten Dokumenten die jeweiligenZertifikate der Bestätiger bekannt und die zugehörige CA-Hierarchie nach Abschnitt 2.5.5 alsvertrauenswürdig eingestuft sein.

4.4.1 Aufbau grammatikbasierter Zertifikate

Das GC erhält die gleiche Grundstruktur wie die X.509-Zertifikate, die jedoch noch um eineKennung gcertIdentifier für grammatikbasierte Zertifikate erweitert wird. Tabelle 4.2 zeigt dieverwendeten Datenstrukturen und ihre Bezeichner, die denen eines Schlüsselzertifikates nach[CSF+08] entsprechen.

Tabelle 4.3 zeigt den Vergleich der Felder von X.509-Zertifikat und GC.


X.509 GC— gcertIdentifiertbsCertificate tbsGCertificatesignatureAlgorithm signatureAlgorithmsignatureValue signatureValue

Tabelle 4.2: Grundstruktur X.509-Zertifikate und GC

X.509 GCversion VersionserialNumber SerialNumbersignature Signatureissuer Issuervalidity Validitysubject –subjectPublicKeyInfo –– GrammarReference– Assertion

ParseTreePrimarySignature

– NonceissuerUniqueID –subjectUniqueID –extensions Extensions

authorityKeyIdentifier AuthorityKeyIdentifierx509CRLDistributionPoints CRLDistributionPointauthorityInformationAccess AuthorityInformationAccess

Tabelle 4.3: Felder X.509-Zertifikate und GC

Das eigentliche Nutzdatum der X.509-Zertifikate, die Zuordnung eines Subjektes zu einem öf-fentlichen Schlüssel, entfällt; damit entfallen auch die Felder subject und subjectPublicKeyInfo.Dafür erhält das GC die Zusicherung (Assertion) mit dem abstrakten Syntaxbaum (ParseTree),also die kodierte Form der Zusicherung, sowie eine zur Interpretation des Syntaxbaumes not-wendige Referenz auf die zugrunde liegende Grammatik (GrammarReference).

Die Grammatikreferenz besteht aus einer Kennung des verwendeten Hashalgorithmus, dem ei-gentlichen Hashwert über die Grammatikdatei und einem optionalen URI, der den Ort und dasZugriffsprotokoll zum Abruf der Grammatikdatei bezeichnet. Alternativ zum URI bzw. zusätzlichkann die Adresse eines speziellen Grammatikservers angegeben werden, über den die Gramma-tik ebenfalls abgerufen werden kann.

Grammatikbasierte Zertifikate können bzw. müssen wie X.509-Zertifikate durch Erweiterungen(Extensions) ergänzt werden. Wird dem Aussteller einer Zusicherung bei Sicherheitsüberprüfun-gen eine geeignete Infrastruktur zur Verfügung gestellt, so kann dieser – wie eine CA – die von


ihm gemachten Zusicherungen ggf. entsprechend der Prinzipien aus Abschnitt 2.5.6 widerrufen.

Für den betrachteten Anwendungsfall der Sicherheitsauditierungen wird ein zentraler Auditie-rungsserver (ZAS) vorgesehen, auf dem alle Zusicherungen und ggf. ihre Rückrufe zusammen-geführt werden.

In den Erweiterungen des GC werden daher, neben der Schlüsselkennung des Ausstellers (au-thority key identifier), auch ein optionaler Verteilpunkt für Sperrlisten CRL Distribution Pointund ein optionaler Verweis auf einen Statusauskunftsdienst Authority Information Access für GCvorgesehen.

Der ebenfalls neu eingeführte optionale Zufallswert Nonce kann zur Überprüfung der Frische derZusicherung eingesetzt werden. Zusätzlich wird zu einer Zusicherung eine Struktur zur Aufnah-me einer Signatur über den Primärtext vorgesehen (PrimarySignature).

Diese im GC enthaltenen Informationen, deren Kodierung als vollständiges Zertifikat noch inKapitel 5 beschrieben wird, haben das Ziel, den Akzeptor von der Korrektheit der Zertifikats-aussage zu überzeugen. Hierbei liefern die Signaturen bereits die Authentizität der Nachricht.Darüber hinaus müssen aber auch die Aktualität der Zusicherung und die Erfüllung der Form-vorgaben betrachtet werden. Diese Aspekte und die verschiedenen Varianten, die InformationenPrimärtext und strukturierte Daten und ihre jeweiligen Signaturen zu nutzen, werden in den fol-genden Abschnitten betrachtet.

4.4.2 Aktualität der Zusicherung

Die Aktualität der Zusicherung soll der in Abschnitt 3.1.5 im Rahmen der Erweiterung der SVO-Logik gegebenen Definition entsprechen. Zur Prüfung dieser Eigenschaft können drei Mechanis-men eingesetzt werden.

Zum Ersten ist die Verwendung des optionalen Nonce-Parameters möglich, der dem Erstellerim Rahmen einer Anforderung einer Zusicherung mitgeteilt und von diesem im erstellten GCaufgenommen wird.

Zum Zweiten besteht die Möglichkeit, wie im Fall der X.509-Zertifikate einen Statusauskunfts-dienst oder Rückruflisten einzusetzen. Ein solcher Dienst sichert die Aktualität i. S. der einge-führten current-Aussage in Bezug auf einen Aussteller und die Seriennummer eines GC zu undermöglicht, ein einmal ausgestelltes Zertifikat als frisch zu akzeptieren.

Die dritte Möglichkeit besteht darin, im Gültigkeitsintervall eine so kurze Gültigkeit zuzusichern,dass weder ein Wiedereinspielen kritisch ist noch die zugesicherte Information innerhalb desIntervalls widerrufen werden müsste.


4.4.3 Prüfung von Formerfüllung

Eine Zusicherung im Sinne grammatikbasierter Zertifikate erfüllt definitionsgemäß nach (4.1)und (4.2) die Formerfordernis, wenn der Primärtext p ∈ L (G) erfüllt und somit ein strukturiertesDatum X = ΦG(p) existiert.

Durch Ausführen von ΦG(p) oder Φ−1G (X) lassen sich der Primärtext p bzw. das strukturierte Da-tumX im Hinblick auf die Erfüllung der korrekten Form validieren. Daher muss beim Anwenderauch im Fall der Signatur und Übertragung des Primärtextes die GrammatikG zur Durchführungder Formprüfung mittels ΦG(p) vorliegen.

4.4.4 Signaturvarianten

Die GC enthalten neben dem Feld zur Signatur der Zertifikatsdaten, die den AST enthalten,auch die Möglichkeit eine Signatur des Primärtextes zu übertragen. Damit können verschiede-ne Signaturvarianten unterschieden werden. Die Signaturfunktion kann auf Primärtexte, auf diedaraus abgeleiteten strukturierten Daten oder auf beide als kombiniertes Verfahren angewendetwerden. Die Signatur des Primärtextes soll als Primärsignatur, die der strukturierten Daten alsSekundärsignatur bezeichnet werden.

Da Primärtext und strukturierte Daten voneinander abgeleitet werden können, können statt einesumfangreichen signierten Primärtextes auch die strukturierten Daten gemeinsam mit der Primär-signatur übertragen werden. Dieses Vorgehen soll als hybrides Verfahren bezeichnet werden.

In dem folgenden Teilkapitel werden die verschiedenen Verfahren erläutert. Eine formale Be-schreibung der Mechanismen und ein bewertender Vergleich erfolgt in Kapitel 5.3.

4.4.4.1 Signierter Primärtext

Formuliert ein Bestätiger B eine Zusicherung, so kann diese in ihrer primären Form p mit sei-nem privaten Schlüssel K−1B signiert und die entstehende Primärsignatur an den Anwender Aübertragen werden.

B 7→ A : bpcK−1B

Dies stellt die einfachste Form der Zusicherung dar und entspricht z. B. der Vorgehensweise beider Signatur von E-Mails mit Zusicherungen. Die Betrachtung der allein stehenden Primärsigna-tur wird der Vollständigkeit halber durchgeführt. Ihre zusätzliche Bedeutung erhält die Primärsi-gnatur mit dem unten beschriebenen hybriden Verfahren.


4.4.4.2 Signierte strukturierte Daten

Diese Variante ist die Hauptform der grammatikbasierten Zertifikate. Hierbei wird statt des Pri-märtextes die strukturierte Kodierungsform, also der abstrakte Syntaxbaum, signiert übertragen.So müssen zwei Aspekte genauer betrachtet werden.

Erstens hängt die Interpretation der strukturierten Daten von der für die Rückgewinnung ver-wendeten Grammatik ab. Die Grammatik bildet den Interpretationskontext für die im Zertifikatenthaltene Zusicherung. Somit genügt es nicht, lediglich den URI für die Grammatik zu hinter-legen, da die dadurch implizierte Bedeutungsinterpretation durch Veränderung der hinterlegtenGrammatik unbemerkt verändert werden könnte. Das Problem nicht festgelegter Kontextinfor-mation wird in Abbildung 4.5(a) verdeutlicht.

Kontext B

Kontext A

Interpretation

Bedeutung B

AAnwendungsinformation

Zertifikat

Bedeutung

(a) Zertifikat ohne Kontextvorgabe

Kontextreferenz Kontext

Kontextauswertung

Interpretation=f(t)

=f(t)

Anwendungsinformation

Zertifikat

Bedeutung

(b) Zertifikat mit Kontextreferenz

Kontextverifikation

Kontexthash

Kontextreferenz Kontext

Kontextauswertung

Interpretation

Anwendungsinformation

Zertifikat

Bedeutung

(c) Zertifikat mit Referenz und Hashwert

Abbildung 4.5: Unterschiedlich starke Kontextbindung

Auch eine konkrete Adressierung einer Kontextinformation ist nicht ausreichend, sofern diesenicht über die Zeit konstant sondern variabel ist, da in diesem Fall die Interpretation ebenfallseiner zeitlichen Variabilität unterworfen sein kann. Diesen Effekt verdeutlicht Abbildung 4.5(b).


Um diese Mehrdeutigkeit zu vermeiden, muss die zur Interpretation des Zertifikatsinhalts benö-tigte Grammatik innerhalb der signierten Daten eindeutig referenziert werden (vgl. Abbildung 4.5(c)).Dies kann durch die Einbettung des Hashwertes der Grammatik in die Signatur erfolgen.

Der Kern einer Zusicherung p gemäß Grammatik G auf Basis der strukturierten Daten X siehtdaher wie folgt aus:

B 7→ A : bX,H(G), . . .cK−1B

wobei gelten muss, dass X = ΦG(p) ist.

Der zweite wichtige Aspekt ist die Festlegung der grundsätzlichen Interpretation eines Syntax-baumes bei gleichzeitiger Angabe des Hashwertes einer Grammatik. Hierzu wird eine Definitionaufgestellt, deren Akzeptanz Grundlage für die Nutzung grammatikbasierter Zertifikate ist.

Wird ein strukturiertes Datum X im Kontext eines grammatikbasierten Zertifikats zusammen miteinem Hashwert einer Grammatik G, mit der aus einem Primärtext p das strukturierte Datum Xerzeugt werden kann, geäußert, so ist dies gleichbedeutend mit dem Äußern von p.

Nur in Anwendungsfällen, in denen dieser Zusammenhang durch einen Akzeptor eines GC alsgültig erachtet wird, kann er durch das GC von der Korrektheit des Primärtextes überzeugt wer-den. Die Akzeptanz kann entfallen, wenn die signierten strukturierten Daten als Bestätigung aus-reichen. In einem solchen Fall kann der Zusammenhang mit einem Primärtext über p = Φ−1G (X)dennoch für eine Berechtigungsprüfung genutzt werden und bei der Erstellung der Zusicherungzur Erhöhung des Verständnisses beim Ersteller dienen.

4.4.4.3 Hybrides Verfahren

Es ist auch möglich, bei Erstellung einer Signatur über den Primärtext (der ggf. auch die Nonceenthält) statt des signierten Primärtextes die strukturierten Daten zu übertragen, um beispiels-weise die Datenmenge zu reduzieren.

B 7→ A : bX, . . .cK−1B,H(G)

In diesem Fall muss ebenfalls eine Kennung der Grammatik übertragen werden. Vor der Signatur-prüfung ist die Rückgewinnung der Nachricht durchzuführen. Erst danach kann die eigentlicheSignaturprüfung erfolgen, in die dann der rückgewonnene Primärtext eingeht.

Der Hashwert der Grammatik muss bei diesem Verfahren nicht übersigniert werden, da im Falleiner manipulierten Grammatik zwar ein anderer Primärtext erzeugt werden könnte, dieser je-doch beim Vergleich der Hashwerte mit der Primärsignatur auffällt.

4.5 Gesamtarchitektur 83

4.4.4.4 Kombiniertes Verfahren

Beim kombinierten Verfahren werden sowohl die Primärsignatur als auch die Sekundärsignaturübertragen.

B 7→ A : bp, . . .cK−1B, bX,H(G), . . .cK−1

B

Dieser Modus ist z. B. dann sinnvoll, wenn beispielsweise der Primärtext mit einer qualifiziertenSignatur versehen wird, um Rechtsverbindlichkeit nach Signaturgesetz zu erreichen, die Absi-cherung der strukturierten Daten jedoch mittels einer fortgeschrittenen Signatur erfolgt.

4.5 Gesamtarchitektur

Um auf Basis der definierten grammatikbasierten Zertifikate die funktionalen Anforderungen ausKapitel 1 realisieren zu können, werden weitere Mechanismen benötigt, deren Zusammenspielin Abbildung 4.6 gezeigt wird.

Wenn durch eine geplante Auditierung Bedarf an Zusicherungen entsteht, werden – sofern nochnicht vorhanden – eine oder mehrere entsprechende Grammatiken erstellt, die i. d. R. einen grö-ßeren Sprachumfang als den konkret benötigten beschreiben.

Da die Grammatiken sowohl bei der Erstellung als auch bei der Prüfung an unterschiedlichenOrten und zu unterschiedlichen Zeitpunkten benötigt werden und auch für spätere Anwendungs-fälle erneut genutzt werden können, wird zur Speicherung und Verteilung der Grammatiken einzentraler Server vorgesehen, über den die Grammatik durch Indizierung über den Grammatik-Hashwert abgerufen werden kann.

In den meisten Fällen, in denen Zusicherungen gemäß einer Grammatik angefordert und auto-matisch ausgewertet werden, umfassen die tatsächlich benötigten Zusicherungen lediglich ei-ne Teilmenge des Sprachumfangs der Grammatik. Entsprechend müssen diese Teilmengen alsAnforderungen spezifiziert und dem Aussteller und Prüfer der Zusicherungen bekannt gemachtwerden. Die so kodierten Anforderungen stellen somit die elektronische Entsprechung zu einemPrüfkatalog gemäß Kapitel 1.3.4 dar.

Ein weiterer Mechanismus, bei dem die Definition von Teilmengen des Sprachumfangs einerGrammatik benötigt wird, ist die Vergabe von Berechtigungen zur Ausstellung einer Zusicherung(vgl. Abschnitt 1.3.5). Dabei kann ein Berechtigter die erhaltene Berechtigung ggf. an weiterePersonen delegieren, so dass eine Delegationskette entstehen kann. Die Nachweise über dieseDelegationsschritte werden in Form von Delegationszertifikaten prüfbar dokumentiert und müs-sen bei der Analyse eingehender Zusicherungen ebenfalls ausgewertet werden. Daher müssen siean die prüfende Instanz (hier der ZAS) übermittelt werden.

Schließlich werden die Zusicherungen auf Basis der Grammatik erstellt und als grammatik-basiertes Zertifikat kodiert und signiert. Nach der Übermittlung findet zunächst eine Prüfungdes Zertifikats (Signatur, Gültigkeitsdauer, Sperrinformationen) statt. Danach kann mit Hilfe der


(initiale)Berechtigung

Delegation 1

Grammatik-Bereitstellung

AST

Delegations-empfänger

Delegation n

ErstellungZusicherung

KodierungAST

ErstellungZertifikat

Übermittlung

PrüfungZertifikat

PrüfungAST

PrüfungDelegation

Rückgewinnung

Verarbeitung

FestlegungAnforderung

Grammatik-ErstellungGrammatik-

ErstellungGrammatik-Erstellung

PrüfungAnforderungs-

abdeckung

Delegations-zertifikate

Aussteller

Prim

är-

text

Prim

är-

text

Transportsicherung

Bedarfs-träger

1

n

...

ZentralerAuditserver

(ZAS)

Grammatikserver

Zusicherungs-bedarf

Abbildung 4.6: Architektur

Grammatik geprüft werden, ob der übertragene AST korrekt ist. Durch diese Prüfung kann auchder Primärtext zurückgewonnen werden.

Der AST bildet auch die Grundlage für die Prüfung der Berechtigung auf Basis der durch Dele-gationszertifikate belegten Delegationskette, die ggf. noch Beschränkungen der Berechtigungenenthalten kann.

Den Abschluss bildet die Prüfung gegen die anfangs festgelegten Anforderungen. Werden die-se vollständig durch die eingegangenen Zusicherungen abgedeckt, so ist der Bedarf des Auditsgedeckt.

4.6 Festlegung von Anforderungen 85

4.6 Festlegung von Anforderungen

Im Prüfkatalog eines Audits sind die Anforderungen durchzuführende Prüfungen, deren (i. d. R.positives) Ergebnis durch den Prüfer zugesichert werden soll. Diese Prüfvorschrift wird häufigschriftlich vorgehalten. Ein Beispiel, das eine Prüfung der physikalischen Sicherheit von Krypto-modulen nach der Maßnahme M-4.87 des BSI-Grundschutzkataloges etwas verkürzt1 beschreibt,lautet:

Für die Prüfung von Hochsicherheitsmodulen sind folgende Prüfschritte durchzu-führen:

Der HSM-Typ (Kryptoserver oder Modul), der Host-Name, sowie der Aufstellungs-ort (Serverschrank) sind zu dokumentieren.

Die für das HSM geltenden Zulassungen sind zu erheben und der Fortbestand derGültigkeit ist zu prüfen. Relevante Zulassungen sind

q FIPS 140-2 Level 3

q FIPS 140-2 Level 4 Phys. Security

q Common Criteria EAL 4+

q ZKA-Zulassung

Der Versionsstand der Firmware-Module ist zu erheben, zu dokumentieren und mitdem in den Zulassungen vorgegebenen Stand zu vergleichen und die Übereinstim-mung festzustellen.

Bei Abweichungen der Firmware-Module (Art oder Versionsstand) ist dies sowieggf. das Vorliegen einer passenden Herstellererklärung zu dokumentieren.

Die Unversehrtheit der Siegel an nicht genutzten Schnittstellen ist zu prüfen und zudokumentieren.

Zwei Zusicherungen entsprechend dieser Vorschrift wurden in Abschnitt 4.1.1 auf Seite 64 ge-zeigt. Für die zweite Zusicherung ist auf Seite 65 die zugehörige XML-Darstellung der struktu-rierten Daten angeben.

Um den konkreten Prüfbedarf auszudrücken, sei eine Prüfung nach oben angegebener Vorschriftmit dem Hinweis auf das zu prüfende System „nciphercrypt1“ angefordert.

Zur automatisierten Prüfung der Anforderungen ist es notwendig, den gewünschten Zusiche-rungsgehalt formalisiert auszudrücken. Für das genannte Beispiel wären dies z. B. der Namedes HSM-Moduls, die erforderliche ZKA-Zulassung und ungebrochene Siegel. Bezüglich der

1Zur besseren Übersichtlichkeit wurde u. a. auf Typenbezeichnungen, Seriennummern, etc. verzichtet und For-mulierungen gekürzt.


Firmware-Module sei wahlweise ein unverändertes System oder das Vorliegen einer Hersteller-erklärung zulässig.

Bei entsprechend weit gefassten L (G) lassen sich Zusicherungen abweichend von dieser Anfor-derung abgeben. So weisen die gezeigten XML-Daten auf Seite 65 zwar veränderte Firmware-Module, jedoch nicht das Vorliegen einer Herstellererklärung aus. Diese Abweichung von dengeforderten Eigenschaften soll automatisiert erkannt werden können.

Um Beschränkungen auszudrücken, kann an allen drei wesentlichen Bestandteilen der Mechanis-men der grammatikbasierten Zertifikate angesetzt werden: Primärtext, Grammatik und struktu-rierte Daten. Die beiden erstgenannten Verfahren werden nur kurz vorgestellt, da die Beschrän-kung der strukturierten Daten die Möglichkeiten dieser beiden Verfahren mit abdecken kannund daher als Basis für die benötigten Beschränkungs- und Delegationsmechanismen ausgewähltwurde.

4.6.1 Beschränkung des Primärtextes

Eine über den durch die Grammatik bestimmten Rahmen hinausgehende Beschränkung einesPrimärtextes p ist – wie auch die Prüfung, ob p ∈ L (G) – eine Eigenschaftsprüfung und istdaher parallel zu der bereits eingeführten Beschränkung durch die Grammatik zu sehen.

Somit kann zunächst eine allgemeine auf den Primärtext bezogene Eigenschaftsprüfung ρp defi-niert werden.

Die Prüffunktion ρp liefert als Ergebnis einen Wahrheitswert aus (T,F) und hat zwei Argumente:den Primärtext p und einen Ausdruck r, der eine Eigenschaft beschreibt, die p erfüllen muss.

Somit gilt

ρp(p, r) = T, wenn p die Eigenschaft r erfüllt.ρp(p, r) = F, wenn p die Eigenschaft r nicht erfüllt.

Die Realisierung einer solchen Prüffunktion kann u. a. beliebige Grammatiken wie z. B. reguläreAusdrücke einsetzen. Das bereits eingeführte Prädikat p ∈ L (G) zur Prüfung von p gegen dieGrammatik ist eine solche Prüffunktion. Da dieser Mechanismus jedoch nicht zweifach ange-wendet werden soll, wird dieser Ansatz nicht weiter betrachtet.

4.6.2 Beschränkung der Grammatik

Eine Alternative zur Prüfung des Primärtextes ist die Beschreibung einer angepassten GrammatikG′ durch Definition von Filterregeln ρg, die auf die Produktionsregeln der Basisgrammatik Gangewendet werden.

Hierbei können für Nicht-Terminale mit n > 1 Produktionen bis zu n− 1 Produktionen gestri-chen werden. Desweiteren können nach vorhergehenden Streichungen alle Regeln für die Nicht-Terminale gestrichen werden, die in keiner Regel auf der rechten Seite enthalten sind.


Als Eigenschaftsprüfung ρg werden Prädikate über die Produktionsregeln definiert, die in Ana-logie zu den Regeln für Primärtexte alle erfüllt sein müssen.

P ′ = {P |P ∈ P ∧ (n∧ν=1

ρg,ν(P, rν))} (4.3)

Beispiel: Aus der einfachen Grammatik G

S → X | bY

X → aXY | aY | daZ

Y → bY | c

Z → bd | dd

soll die RegelX → daZ gestrichen werden. Dann können auch die Regeln Z → bd und Z → ddgestrichen werden, da diese nicht mehr erreichbar sind.

Die zugehörigen Beschränkungen können z. B. als

ρg,1 : RS(P ) 6= daZ

ρg,2 : LS(P ) 6= Z

geschrieben werden.

Die Sprache der daraus resultierenden Grammatik G′ ist eine Untermenge der Sprache von G,also L (G′) ⊆ L (G), da PG′ ⊂ PG:

Für jede Ableitung S Pa⇒G′ w0Pb⇒G′ . . .

Px⇒G′ w mit Pa, Pb, . . . , Px ∈ P ′ existiert eine identischeAbleitung S Pa⇒G w0

Pb⇒G . . .Px⇒G w, da alle Pν ∈ P ′ auch in P enthalten sind. Damit ist auch

∀w′∃w(w′ ∈ L (G′) ∧ w ∈ L (G) ∧ w′ = w) erfüllt und damit schließlich L (G′) ⊆ L (G).

4.6.3 Beschränkung der strukturierten Daten

Der dritte Ansatzpunkt für die Definition von Beschränkungen ist der abstrakte Syntaxbaum. Wiebei Beschränkungen auf Basis der Grammatik sind Beschränkungen der beim Parsing-Vorgangentstehenden strukturierten Daten direkt mit den semantisch motivierten Knoten formulierbar.

4.6.3.1 XML-Kodierung der strukturierten Daten

Um konkrete Beschränkungsmöglichkeiten darstellen zu können, wird zunächst eine geeigneteRepräsentationsform für strukturierte Daten festgelegt.

q Jede genutzte Produktionsregel, die auf der rechten Seite auch Nicht-Terminale enthält,wird durch einen mit dem linksseitigen Nicht-Terminal beschrifteten Knoten dargestellt,der als Subknoten die Knoten der auf der rechten Seite enthaltenen Nicht-Terminale ent-hält.


q Jede genutzte Produktionsregel, die auf der rechten Seite nur Terminalsymbole enthält,wird durch einen mit dem linksseitigen Nicht-Terminal beschrifteten Knoten dargestellt,der als Subknoten die nicht-redundanten Terminale enthält.

q Für Blätter des Baumes, die aus Lexemen gebildet werden, wird der Primärtext des jewei-ligen Lexems direkt in den strukturierten Daten abgelegt.

Als textuelle Darstellungsform für die AST-Strukturen wird eine Darstellung in XML festge-legt. Hierbei ist jeder innere Knoten ein XML-Element, dessen Start- und Ende-Tag mit demNicht-Terminal als Tag-Namen versehen werden, wie dies bereits in den weiter oben gezeigtenBeispielen vorgestellt wurde.

Bei Blättern des Baumes (Terminale und Lexeme) erfolgt die Darstellung durch den speziellenElementtyp GCELEMENT. Dieser enthält ein Attribut type, das für Terminale den Wert TOKENund für Lexeme den Lexem-Bezeichner (z. B. STRING, INT, REAL, usw. ) enthält.

<Zertifizierung><GCELEMENT type="TOKEN">FIPS 140-2 Level 3</GCELEMENT>

</Zertifizierung><Firmware>

<FWModul><GCELEMENT type="STRING">pin-1.0.2.mod</GCELEMENT>

</FWModul>...

</Firmware>

Durch die Attributierung können die als Text-Element gespeicherten Terminale und Lexemewahlweise als Zeichenkette oder nach Typ-spezifischer Umwandlung z. B. als Ganzzahl verar-beitet werden.

4.6.3.2 XPath-Ausdrücke

Durch die Verwendung von XML kann für die weiteren Schritte der bewährte Mechanismus derXPath-Ausdrücke [BBC+07] zum Einsatz kommen. Mit XPath-Ausdrücken lassen sich unter-schiedliche Teile eines XML-Dokumentes adressieren und durch die Verwendung von Funktio-nen auch Eigenschaftsprüfungen durchführen.

XPath-Ausdrücke sind den Pfadangaben unter Unix ähnlich. Die Basis der Ausdrücke sind durchSchrägstrich getrennte Bezeichner. Statt Verzeichnisse benennen die Bezeichner jedoch Knotender XML-Struktur. Der Ausdruck /Satz/HSMSystem/Modul bezeichnet alle Modul-Elemente,die Unterknoten des Knotens HSMSystem sind, der wiederum ein Knoten unter dem oberstenKnoten Satz ist. Positionsangaben können auch relativ sein. So steht die Verwendung eines dop-pelten Schrägstriches an erster Stelle für einen Knoten an einem beliebigen Punkt unterhalb desStartknotens.


Daneben können auch Eigenschaften von Knoten angegeben werden. Soll z. B. geprüft werden,ob für die Prüfung das nmap-Verfahren zugesichert wurde, so kann dies durch den Prüfausdruck//Pruefung/Methode/GCELEMENT[text()=’nmap-Befehl’]

erfolgen. Der Ausdruck wird als „Die XML-Struktur enthält einen Knoten ‘Pruefung’ mit einemUnterknoten ‘Methode’ mit einem Unterknoten ‘GCELEMENT’, dessen Inhalt ‘nmap-Befehl’ist.“ gelesen.

Ein anderes Beispiel ist die Prüfung, ob ein ssh-Dienst auch auf Port 22 konfiguriert ist://Dienst[Dienstname/GCELEMENT[text()=’ssh’]]/Portnummer/GCELEMENT[text()=22]

Für den vergleichenden Zugriff auf die Textteile in den Blättern des AST wird eine Kurzschreib-weise eingeführt, mit der sich die XPath-Ausdrücke kompakter schreiben lassen.

Folgt nach einem XPath-Ausdruck eine in einfachen Hochkommata stehende Zeichenkette, sowird diese durch einen GCELEMENT-Knoten ersetzt, dessen Textinhalt mit der in Hochkom-mata stehenden Zeichenkette verglichen wird.

Beispiel: Der Ausdruck //Dienst[Dienstname/’ssh’]/Portnummer/’22’ ist die verkürzteDarstellung des oben angegebenen Beispiels zur Prüfung auf einen an Port 22 gebundenen ssh-Dienst. Durch diese Schreibweise wird eine verbesserte Lesbarkeit der Prüfausdrücke erzielt.

4.6.3.3 Prüffunktion für abstrakte Syntaxbäume

Analog zur Prüffunktion für den Primärtext wird eine Prüffunktion zur Auswertung von XPath-Ausdrücken gegen eine als strukturiertes Datum vorliegende Zusicherung definiert. Die verwend-baren XPath-Ausdrücke werden dabei auf die Menge X der Ausdrücke eingeschränkt, deren Er-gebnis eine (ggf. leere) Menge von Elementen aus dem XML-Dokument der Zusicherung sind(im Gegensatz zu Abfragen, die z. B. eine Anzahl von Treffern zurück liefern).

Die XML-kodierte AST-Form einer Zusicherung seiX . x ∈ X ist ein beliebiger XPath-Ausdruck.Die Anwendung des XPath-Ausdrucks auf X wird als Funktion χ(X, x) geschrieben, derenRückgabewert eine Menge von Elementen aus X ist.

In einem ersten Schritt wird die Prüffunktion ρ(X, x) für abstrakte Syntaxbäume auf Basis einesAST X gemäß einer Grammatik G und eines XPath-Ausdrucks x ∈ X definiert:

ρ(X, x) =

{T genau dann, wenn χ(X, x) 6= ∅F genau dann, wenn χ(X, x) = ∅

Für die Verwendung in SVO-Logiken wird eine alternative Schreibweise GCR(X, x) eingeführt.

Um die gleichzeitige Prüfung mehrerer Eigenschaften ausdrücken zu können, werden zusam-mengesetzte Beschränkungen (restrictions) r definiert, die aus XPath-Ausdrücken bestehen, dieüber and- und or-Junktoren verknüpft und ggf. auch über die not-Funktion invertiert werden


können. Die Bedeutung dieser in Prefix-Notation geschriebenen Verknüpfungen ist intuitiv er-schließbar:

and(r1, r2) : Es müssen r1 und r2 erfüllt sein.or(r1, r2) : Es müssen r1 oder r2 oder beide erfüllt sein.

not(r1) : r1 darf nicht erfüllt sein.

Zusammengesetzte Beschränkungen r können nun rekursiv mit Hilfe der XPath-Ausdrücke undder Junktoren definiert werden:

Beschraenkung→ XPathBeschraenkung→ not(Beschraenkung)

Beschraenkung→ and(Beschraenkung,Beschraenkung)

Beschraenkung→ or(Beschraenkung,Beschraenkung)

Um eine zusammengesetzte Beschränkung auszuwerten, wird die Definition der Prüffunktionρ(X, r) erweitert.

wenn r ∈ X ρ(X, r) =

{T genau dann, wenn χ(X, r) 6= ∅F genau dann, wenn χ(X, r) = ∅ (4.4)

sonstρ(X, not(r)) = ¬ρ(X, r) (4.5)

ρ(X, and(r1, r2)) = ρ(X, r1) ∧ ρ(X, r2) (4.6)ρ(X, or(r1, r2)) = ρ(X, r1) ∨ ρ(X, r2) (4.7)

Damit ist auch

ρ(X, and(r1, r2)) = ρ(X, and(r2, r1)) (4.8)ρ(X, or(r1, r2)) = ρ(X, or(r2, r1)) (4.9)

Eine leere (also nicht wirksame) Beschränkung wird als r = ⊥ geschrieben. Sie kann durcheinen XPath der Form „/*“ kodiert werden. Damit ist

ρ(X,⊥) = T für beliebige, nicht-leere X . (4.10)

Es gilt

ρ(X, and(r,⊥)) = ρ(X, r) ∧ ρ(X,⊥) = ρ(X, r) ∧T = ρ(X, r) (4.11)ρ(X, or(r,⊥)) = ρ(X, r) ∨ ρ(X,⊥) = ρ(X, r) ∨T = T (4.12)ρ(X, not(⊥)) = ¬ρ(X,⊥) = ¬T = F (4.13)

Damit sind nun zusammengesetzte Prüfausdrücke möglich, die ihrerseits wieder mittels einerGrammatik kodiert werden können. Die Grammatik ist in Anhang C.3 enthalten.

4.7 Delegation 91

In Analogie zu (4.3) können auch im Fall der Beschränkung auf Basis der zusammengesetz-ten Prüfausdrücke mehrere Anforderungen in Form von XPath-Ausdrücken x1, . . . , xn gestelltwerden. Diese werden jedoch statt auf Produktionsregeln mittelbar über die strukturierte Dar-stellung der Primärtexte auf den Sprachumfang angewendet. Die strukturierten Daten X könnendabei auch durch die Kodierungsfunktion X = ΦG(p) dargestellt werden. Es gilt für den einge-schränkten Sprachumfang L (G, r):

L (G, r) = {p|p ∈ L (G) ∧ ρ(ΦG(p), r)} (4.14)

da alle xν zu einer Beschränkung r = and(x1, and(x2, . . .)) zusammengefasst werden können.

Für r = ⊥ ist L (G, r) = L (G), da mit (4.10) gilt:

L (G,⊥) = {p|p ∈ L (G) ∧ ρ(ΦG(p),⊥)}= {p|p ∈ L (G) ∧T}= {p|p ∈ L (G)}= L (G) (4.15)

Durch Und-Verknüpfung einer Einschränkung r0 mit einer Einschränkung r1 ergibt sich eineTeilmenge des Sprachumfangs, da es sich um eine Schnittmengenbildung handelt:

L (G, and(r0, r1)) = {p|p ∈ L (G) ∧ ρ(ΦG(p), and(r0, r1))}= {p|p ∈ L (G) ∧ ρ(ΦG(p), r0) ∧ ρ(ΦG(p), r1)}= {p|p ∈ L (G) ∧ ρ(ΦG(p), r0) ∧ p ∈ L (G) ∧ ρ(ΦG(p), r1)}= {p|p ∈ L (G) ∧ ρ(ΦG(p), r0)} ∩ {p|p ∈ L (G) ∧ ρ(ΦG(p), r1)}= L (G, r0) ∩L (G, r1)

4.7 Delegation

Eine wichtige Anforderung an grammatikbasierte Zertifikate ist die Möglichkeit, die Berechti-gung, Zusicherungen zu erstellen, an Dritte zu delegieren. Dabei ist es auch notwendig, dass diedelegierten Aussagenmengen in ihrem Umfang eingeschränkt werden können.

In diesem Abschnitt werden zunächst einige Grundbegriffe der Delegation erläutert und ein De-legationsmechanismus für GC-Zusicherungen beschrieben. Danach werden der Informationsge-halt für Delegationszertifikate und die notwendigen Prüfschritte für diese Zertifikate betrachtet.

4.7.1 Begriffe der Delegation

Bei der Delegation überträgt eine Person, die bereits das Recht hat, Aussagen innerhalb eines be-stimmten Kontextes zu erstellen, dieses Recht auf eine andere Person. Dabei kann unterschiedenwerden, ob der Übergang des Rechtes die erneute Weitergabe (Unterdelegation) umfasst oder obdies nicht möglich ist.


Ausgangspunkt für die Delegation ist das Vorliegen einer Berechtigung. Diese wird im Zusam-menhang mit einer späteren Weitergabe (Delegation) als initiale Berechtigung bezeichnet.

Der Inhaber eines Rechtes, der dieses Recht weitergeben will, wird als Delegierender bezeichnet.

Die über eine Delegation weitergereichte Berechtigung wird als delegiertes Recht und der Emp-fänger des delegierten Rechtes als Delegationsempfänger oder als Delegierter bezeichnet.

Die Delegation eines Rechtes kann auf unterschiedliche Art und Weise erfolgen. Wird von einemVorgesetzten eine Aufgabe an einen Untergebenen delegiert und die Arbeitsergebnisse wiederdurch den Vorgesetzten entgegengenommen, so reicht für die Delegation die Absprache zwischenVorgesetztem und Mitarbeiter.

Umfasst die Delegation mehrere Stufen oder die Kommunikation der auf Basis der delegiertenRechte gemachten Aussagen gegenüber Dritten, so müssen auch diese weiteren Beteiligten vonder Delegation in Kenntnis gesetzt werden. Die dabei übermittelte Information wird im Folgen-den als Delegationsnachweis bezeichnet.

Eine mehrstufige Delegation soll als Delegationskette bezeichnet werden. Der Beginn der Dele-gationskette liegt beim Initiator der Delegation.

4.7.2 Delegationsvorgang

Für die vorliegende Arbeit ist der Inhalt einer Delegation auf das Recht beschränkt, Aussageni. S. von Zusicherungen entsprechend einer vorgegebenen Grammatik zu machen. Die zugrundeliegende Grammatik soll dabei wie eingeführt durch die Angabe eines Hashwertes über eineGrammatikdatei bestimmt werden. Die durch die Grammatik G definierte Sprache L (G) sollim Rahmen einer Delegation als Basisberechtigung bezeichnet werden.

Wie bei der Festlegung der Anforderungen in Kapitel 4.6 ist auch bei der Delegation von Zu-sicherungen ein Mechanismus zur Einschränkung der möglichen Aussagen sinnvoll. Beispielehierfür sind die Beschränkung von Auditierungen auf Systeme eines Zuständigkeitsbereichs oderdie Einschränkung der für eine Auditierung zugelassenen Methoden u. ä.

Im Rahmen jeder Delegationsstufe kann daher eine zusammengesetzte Beschränkung in Analo-gie zu Kapitel 4.6.3.3 definiert werden, die erfüllt werden muss, damit ein Zertifikat akzeptiertwird. Die Beschränkungen aller Stufen werden vor der Prüfung Und-verknüpft. Die Auswer-tung der so verknüpften Beschränkungen kann analog zur Auswertung der Anforderungen anZusicherungen erfolgen.

Die Delegation wird i. d. R. durch Ausstellen eines Delegationszertifikates durchgeführt. Die we-sentlichen Bestandteile der Aussage eines solchen Zertifikates sind die Kennung des Delegati-onsempfängers B, die Basisberechtigung in Form eines Hashwertes einer Grammatik G, eineoptionale Datenstruktur R, die die bei dieser Delegation anzuwendenden Beschränkungen be-schreibt und die Angabe einer Ganzzahl w ≥ 0, die beschreibt, wie viele weitere Delegations-stufen nach der aktuellen noch erlaubt sind.

4.7 Delegation 93

Das Vorliegen eines solchen Delegationszertifikates bedeutet, dass B Zusicherungen mit der Ba-sisberechtigung L (G) erstellen darf. Die Zusicherungen sind dabei durch R beschränkt. Zusätz-lich sind alle Beschränkungen wirksam, die für den Aussteller des Zertifikates gelten, da diesernicht mehr Rechte delegieren können soll, als ihm selbst gewährt wurden. Ist w > 0, so soll Bseinerseits dieses Recht weitergeben dürfen.

Damit eine auswertende Stelle diesen Delegationsnachweis akzeptiert, muss der Akzeptor vomRecht des Ausstellers zur Delegation überzeugt sein. Dieses Recht, weitere Beteiligte mit Zusi-cherungsrechten zu versorgen, kann z. B. im ZAS durch eine tabellarische Zuordnung realisiertwerden. Dabei wird einer Ausstellerkennung Q eine Basisberechtigung H(G) mit Beschränkun-gen R und der Anzahl wmax maximal erlaubter weiterer Delegationsstufen zugeordnet. Die ggf.eingeschränkte Basisberechtigung bildet die Initialberechtigung für Delegationsketten, die vonQ ausgehen.

Ist wmax = 0, so ist für Q keine weitere Delegation möglich. Bei wmax = 1 kann Q nur dasRecht zur Ausstellung von Zusicherungen gemäß der hinterlegten Initialberechtigung L (G,R)durch ein Delegationszertifikat mit w = 0 weitergeben. Für den Fall wmax > 1 ist Q berechtigt,Delegationszertifikate mit 0 < w ≤ wmax zu erstellen. Damit kann Q Delegationsketten mit einerLänge von bis zu wmax − 1 Stufen beginnen.

Ergänzend zu dieser nicht-formalen Darstellung wird für das Delegationsverfahren in Kapi-tel 5.5.5 eine Semantik auf Basis der SVO-Logik angegeben.

4.7.3 Delegationszertifikat

Ein Delegationszertifikat (engl. Grammar-based Delegation Certificate (GDC)) ist eine Zusiche-rung mit vergleichbarem Informationsinhalt wie ein grammatikbasiertes Zertifikat. Eine Gegen-überstellung der Inhalte zeigt Tabelle 4.4.

Das Delegationszertifikat enthält – wie ein X.509-Zertifikat – einen Subject-Eintrag für den De-legationsempfänger, dementsprechend enthält das Issuer-Feld den Delegierenden. Die Gramma-tikreferenz (Hashwert von G) erzeugt die Basisberechtigung und begründet das Recht, Zusiche-rungen aus L (G) abzugeben.

Die Aufnahme eines AuthorityInformationAccess- oder eines CRLDistributionPoint-Elementesist notwendig, wenn Delegationen längerfristig gelten sollen, da in diesem Fall der Mechanismusder Nonce nicht eingesetzt werden kann.

Da keine der zusätzlichen Informationen der GDC ein bestehendes Feld der GC umdeutet, kön-nen die neuen Felder Subject, Restriction und PathLength auch zu einer Aussage zusammen-gefasst und als GC kodiert werden. Da die Grammatikreferenz des GC in diesem Fall für eineGrammatik zur Beschreibung der GDC-Zusicherung verwendet werden muss, muss auch dieGrammatikreferenz für die Basisberechtigung in die Zusicherung aufgenommen werden.

Es wird daher eine spezielle Grammatik GD zur Erstellung von Delegationsaussagen festgelegt.Durch Einsetzen dieser Grammatik in ein GC wird ein Delegationszertifikat erstellt. Eine kon-krete Umsetzung wird im Rahmen der Implementierung in Kapitel 5 vorgestellt.


GC GDCVersion VersionSerialNumber SerialNumberSignature SignatureIssuer IssuerValidity Validity– SubjectGrammarReference GrammarReferenceAssertion –– RestrictionNonce –– PathLength

Tabelle 4.4: Inhalt von Delegationszertifikaten im Vergleich zu GC

Um zirkuläre Abhängigkeiten und Überlagerung von Mechanismen zu vermeiden, darf die Gram-matik GD nicht selbst Gegenstand einer Delegation sein. Damit muss auch festgelegt werden,dass jeder Beteiligte berechtigt ist, Aussagen nach L (GD) zu erstellen.

4.7.4 Delegationsprüfung

Jeder Akzeptor einer Aussage benötigt zur Prüfung der Legitimation der Aussage eine krypto-graphisch verkettete Liste von Delegationszertifikaten oder anders gesicherter Delegationsaussa-gen. Es ist dabei zum einen möglich, die relevanten Delegationszertifikate an die als GC kodierteAussage anzuhängen und gemeinsam an den Akzeptor zu übermitteln. Die andere Möglichkeitbesteht darin, die Delegationszertifikate sowohl dem Delegierten als auch dem Ursprung der De-legationskette zum Zeitpunkt der Ausstellung der Delegation zukommen lassen.

Die Delegationsprüfung erfolgt dann in mehreren Schritten.

q Kontextprüfung (Aussage und Delegation beziehen sich auf die gleiche Grammatik)

q Vollständigkeitsprüfung der Zertifikatskette

q Gültigkeitsprüfung aller verwendeten Zertifikate (Zeitraum und ggf. Sperrinformation)

q Prüfung der Signaturen der Delegationszertifikate

q Prüfung der Zusicherung gegen die Basisberechtigung (Grammatik)

q Prüfung der ggf. vorhandenen Beschränkungen

Eine Alternative zur jeweiligen Prüfung der vollständigen Kette ist die Verwendung einer Be-rechtigungsdatenbank im ZAS, in der die Rechte für einzelne Instanzen schritthaltend mit der

4.8 Grammatikverteilung 95

Ausstellung von Berechtigungszertifikaten mitgeführt werden. Hierbei muss jeder Aussteller ei-ner Berechtigung diese an den ZAS übertragen. Vor dem Einstellen der Information wird geprüft,ob bereits eine Berechtigung für den Aussteller des Berechtigungsnachweises vorliegt. Nur wenndies der Fall ist, wird die neue Berechtigung aus dem Delegationszertifikat aufgenommen. Diejeweils anzuwendenden Beschränkungen müssen ebenfalls mitgeführt werden.

4.8 Grammatikverteilung

Eine Grammatikdatenbank und ein darauf aufsetzender Grammatik-Server haben die Aufgabe,Dateien, die die textuelle Darstellung einer Grammatik enthalten, auf Anfrage auszuliefern. Da-bei wird der Hashwert H(G) einer Grammatik, die z. B. in EBNF-Notation vorliegt, als Referenzgenutzt. Für den häufigen Vorgang der Auslieferung einer Grammatik soll für den Grammatik-Server ein möglichst geringer Aufwand entstehen. Desweiteren soll das notwendige Vertrauen ineinen solchen Verteildienst lediglich auf die Sicherung der Verfügbarkeit beschränkt werden.

Im einfachsten Fall können Grammatiken an den Server übergeben werden. Der Server berech-net den zugehörigen Hashwert und speichert diesen als Index für den Abruf der Grammatik.Falls der Server vor Missbrauch geschützt werden soll, so müssen zusätzlich Autorisierungs-und Authentisierungsfunktionen unterstützt werden.

4.8.1 Vertraulichkeit von Grammatiken

Grammatikdaten sind im Falle von Bestätigungen für Sicherheitsanalysen u. U. selbst hinsicht-lich ihrer Vertraulichkeit zu schützen. Daher soll im Folgenden der Anwendungsfall einer ver-schlüsselten Speicherung in einem Grammatik-Server betrachtet werden.

Die Verwendung öffentlicher Schlüssel zur Vorabverschlüsselung ist nicht geeignet, da in die-sem Fall öffentliche Schlüssel jedes möglichen Delegierten und jedes Prüfers einer Zusicherungvorab bekannt sein und die Speicherung verschlüsselter Grammatiken mehrfach erfolgen müs-ste. Eine Client-spezifische asymmetrische Verschlüsselung bei Abruf der Grammatik durch denServer setzt wieder Vertrauen in die Wahrung der Vertraulichkeit durch den Dienst voraus. DieNotwendigkeit dieser Eigenschaft wurde jedoch bereits ausgeschlossen. Daher wird die Verwen-dung eines (beliebigen) symmetrischen Verschlüsselungsverfahrens angenommen.

Der Ersteller E einer Grammatik wählt zusätzlich einen symmetrischen Schlüssel S aus, den erzur Verschlüsselung der Grammatikdaten vor der Übertragung an den Grammatikserver verwen-det. Die Übertragung an den Grammatikserver erfolgt als Tupel aus Hashwert der Grammatik,der zum Abruf der Daten benötigt wird, und dem Chiffrat der zugehörigen Grammatik.

Neben der Ermittlung des Hashwertes durch den Server muss es auch die Möglichkeit geben, denHashwert einer verschlüsselten Grammatik G1 explizit anzugeben. Ohne eine Berechtigungs-prüfung kann ein Angreifer eine Nachricht an den Grammatikserver so manipulieren, dass derHashwert der Grammatik für die weitere Verwendung blockiert ist.


Der Dienst muss zur Sicherung der Verfügbarkeit daher um einen Legitimationsmechanismuserweitert werden, der nur Berechtigten das Einstellen von verschlüsselten Grammatiken ermög-licht. Auf Basis dieser Berechtigungen kann auch das Löschen von Einträgen dem jeweiligenErsteller der Grammatik gestattet werden.

4.8.2 Daten- und Funktionsmodell des Grammatikservers

Sollen verschlüsselte Grammatiken auf dem Grammatikserver über den Hashwert der unver-schlüsselten Grammatik abgerufen werden, so müssen sowohl das Chiffrat als auch der Hashwertgemeinsam eingestellt werden. Das Einstellen darf nur durch einen autorisierten Akteur erfolgen.Hierzu werden Referenzen auf alle berechtigten öffentlichen Schlüssel in einer Autorisierungs-tabelle, beschrieben durch die Menge A0, hinterlegt. Eine Schlüsselreferenz wird durch einenHashwert über den jeweiligen Schlüssel gebildet. Hashwert und Chiffrat werden zusammen mitdem Schlüssel des Einstellers im Hauptdatenbestand D als 3-Tupel gespeichert. Wird eine Gram-matik im Klartext eingestellt, so ist die Speicherung des öffentlichen Schlüssels optional.

Bei der Definition des Funktionsmodells werden folgende Größen verwendet:

q Client C

q Grammatikersteller E mit öffentlichem Schlüssel KE

q Server G mit öffentlichem Schlüssel KG

q Schlüsselreferenz K̂ν auf Schlüssel Kν

q Grammatiken G1, G2 mit den Hashwerten H1 = H(G1) und H2 = H(G2)

q Symmetrischer Schlüssel S

q Zufallswerte r1, r2 und zufällige Token t1, t2

q Variablen X, Y, Z

q das Symbol ⊥ zur Kennzeichnung ungültiger oder leerer Datenelemente

Für die Kommunikation zwischen Nutzern und dem Server werden Nachrichten der Form (Label,Parameter 1, [Parameter 2], ...) definiert.

Grammatiken können durch beliebige Nutzer mit einer reqG-Nachricht, die den Hashwert dergewünschten Grammatik (z. B. H1) enthält, abgerufen werden. Die Anfrage wird vom Servermit einer respG-Nachricht beantwortet:

C 7→ G : (reqG, H1)

G 7→ C : (respG, H1, G1)

4.8 Grammatikverteilung 97

Die Antwort wird nur dann erteilt, wenn ein Datensatz mit einem entsprechenden Hashwert inder Datenbank enthalten ist, also (H1, Y, Z) ∈ D gilt. Bei unverschlüsselten Grammatiken istY = G1 und Z = ⊥, bei verschlüsselten Grammatiken ist Y = {G1}S und Z = K̂E . Derdritte Wert nimmt im Fall von verschlüsselten Grammatiken eine Referenz auf den öffentlichenSchlüssel der Instanz auf, die die Grammatik eingestellt hat. Ist kein passender Hashwert in derDatenbank, so lautet die Antwort (NULL, H1,⊥).

Das Einstellen einer unverschlüsselten Grammatik ohne Autorisierung beantwortet der Servermit einer entsprechenden respG-Nachricht, die auch auf eine entsprechende Anfrage nach derGrammatik erfolgt.

C 7→ G : (addG, G1) (GS1)G 7→ C : (respG,H(G1), G1) (GS2)

Die Grammatik wird dann eingestellt, wenn nicht bereits ein Datensatz mit diesem Hashwert ent-halten ist (∀(X, Y, Z) ∈ D |X 6= H(G1)). Für fehlgeschlagene Operationen wird der Nachrich-tentyp ERR für Meldungen definiert, die den Anfragenden über die Fehlerursache informieren.Diese Nachrichten können in einer konkreten Implementierung festgelegt werden.

Für das Einstellen verschlüsselter Grammatiken und deren Löschung wird eine Autorisierungvorgesehen. Dazu muss zunächst die Schlüsselreferenz des Erstellers in die Menge der berech-tigten Schlüssel aufgenommen werden (K̂E ∈ A0).

Um eine autorisierte Operation ausführen zu können, muss E zunächst ein Legitimationstokenvom Server anfordern, der zuvor die Bedingung K̂E ∈ A0 prüft.

E 7→ G : breqT, r1, K̂EcK−1E

(GS3)

G 7→ E : brespT, r1, t1cK−1G

(GS4)

Bei der Beantragung in (GS3) wird die Anfrage signiert und enthält einen Zufallswert r1, dergegen Wiedereinspielen von Server-Antworten schützt.

In der Antwort (GS4) erhältE ein Token t1, das für eine Einstell- oder Löschoperation verwendetwerden kann. Das Token wird auf Serverseite in Verbindung mit K̂E gespeichert.

Zur Einstellung einer Grammatik sendet E Hashwert, Chiffrat und Token signiert an G.

E 7→ G : baddHG,H(G2), {G2}S, t1, K̂EcK−1E

(GS5)

G 7→ E : (respG,H(G2), {G2}S) (GS6)

Ist bereits eine Grammatik mit diesem Hashwert eingestellt, so antwortet der Server mit demNachrichtentyp DUP.

Zum Löschen der Grammatik wird analog ein Token beantragt und damit die entsprechendedelG-Anfrage legitimiert.

E 7→ G : bdelG,H(G2), t2, K̂EcK−1E

(GS7)

G 7→ E : (respG,H(G2),⊥) (GS8)


Ist keine Grammatik unter dem genannten Hashwert eingestellt, so antwortet der Server mit demNachrichtentyp NULL. Falls der Eintrag einem anderen Schlüssel zugeordnet ist, so wird eineNachricht vom Typ NOTOWNER zurück gesendet.

Desweiteren wird die Möglichkeit zur Delegation des Einstellens und Löschens von Gramma-tiken vorgesehen. Hierzu kann die Anforderung eines Tokens um die Angabe des öffentlichenSchlüssels KD eines zu berechtigenden weiteren Akteurs ergänzt werden.

E 7→ G : breqT, r2, KD, K̂EcK−1E

(GS9)

G 7→ E : brespT, r2, t2cK−1G

Der erstellte Token wird im Grammatikserver zusammen mit dem Schlüssel des Delegierten undder zugehörigen Schlüsselreferenz gespeichert.

Zur Unterstützung des Delegationsmechanismus sollen die autorisierten Schlüsselreferenzen at-tributiert werden. Daher wird die Menge A0 in eine Menge A aus Drei-Tupeln der Form (K̂, t, d)überführt. Für jeden autorisierten Schlüssel K lässt sich durch t ∈ {T,F} das Recht, Tokenanzufordern und durch d ∈ {T,F} das Recht zur Delegation ausdrücken. Sofern der Server dieZertifikate nicht gesondert speichert, kann dieses Tupel auch um eine Stelle für den Schlüsselbzw. für ein Zertifikat zu diesem Schlüssel ergänzt werden.

Nur wenn das d-Recht für den Absender der Token-Anforderungen mit Angabe des SchlüsselsKD eines Dritten gesetzt ist, wird dessen Schlüsselreferenz in A als (K̂D,F,F) aufgenommenund die Zuordnung des Token t2 zu K̂D wird im Dienst gespeichert.

4.8.3 Sicherheitseigenschaften des Grammatikservers

Die Sicherheitseigenschaften, die durch Serverfunktion und Protokoll erbracht werden sollen,sind:

q Eine Grammatik darf nur dann vom Server akzeptiert werden, wenn diese durch einenvertrauenswürdigen Client eingestellt wird. Dabei wird Vertrauenswürdigkeit durch Ein-tragung in die Autorisierungstabelle oder durch Delegation begründet.

q Dem Akzeptieren eines Löschauftrags durch den Server muss die Annahme der zugehöri-gen Grammatik vom gleichen Client vorausgegangen sein.

q Dem Akzeptieren eines Löschauftrags durch den Server muss die Erstellung des Lösch-auftrags durch den vertrauenswürdigen Client vorausgegangen sein.

q Jede Anforderung zur Einstellung oder Löschung einer verschlüsselten Grammatik darf zumaximal einer Aktion führen.

Diese Eigenschaften werden in Kapitel 5 formal untersucht und nachgewiesen.

5 Implementierung und formaleBewertung

Für die in Kapitel 4 entworfenen grammatikbasierten Zertifikate wurde eine prototypische Rea-lisierung der für ihre Verarbeitung nötigen Mechanismen erstellt, deren Datenformate und Funk-tionsbausteine die Anforderungen aus Kapitel 1.3 umsetzen.

Der Entwurf wurde darüber hinaus einer formalen Analyse unterzogen. Zum einen wird eine for-male Semantik der grammatikbasierten Zertifikate und der Delegationsmechanismen auf Basisder SVO-Logik angegeben, zum anderen wird eine Proverif-Modellierung des Grammatikver-teildienstes zum Nachweis seiner Sicherheitseigenschaften eingesetzt.

5.1 Realisierung grammatikbasierter Zertifikate

Die Realisierung setzt das Prinzip der Gesamtarchitektur aus Abschnitt 4.5 mittels verschie-dener Komponenten um. Diese wurden teilweise unter Verwendung existierender Werkzeugeentwickelt. Die Hauptbestandteile der Implementierung sind:

q Syntax für Grammatiken zur Beschreibung grammatikbasierter Zertifikate (Grammar-basedCertificate Grammar, GCG)

q Makro-gestütztes Verfahren zur Erstellung von GCGs

q Parsergenerator zur Erstellung von Parsern für Zusicherungen

q XML-Schema und entsprechende Kodier- und Signierfunktionen zur Kodierung gramma-tikbasierter Zertifikate

q Parsergenerator für Baumparser zum Einlesen strukturierter Daten und zur Rückgewin-nung des Primärtextes

Eine Übersicht über alle vorgestellten Grammatik- und Parser-Generatoren gibt Abbildung 5.1.

99

100 Kapitel 5. Implementierung und formale Bewertung

GC-

Grammatik

GenerierungParser

Grammatik

GenerierungParser

KodierungAST

GenerierungBaumparserGrammatik

GenerierungBaumparser

Rückgewinnung

GenerierungGC-Editor

GenerierungXText

Grammatik

ErstellungPrimärtext

t_gcg.pl

ANTLR

Eclipse

Zusicherung Verarbeitung

Abbildung 5.1: Automatisierte Editor- und Parsergenerierung

5.1.1 ANTLR-Parser

Als Basis für die prototypische Implementierung wurde der ANTLR-Parsergenerator von Te-rence Parr gewählt[Par07]. ANTLR steht für Another Tool for Language Recognition und er-möglicht die automatisierte Erstellung von Parsern in Java auf Basis vorgegebener Grammatiken.

Ein besonderer Vorteil von ANTLR ist die Unterstützung von sog. Baumparsern, die es ermögli-chen, auch Baumstrukturen, wie sie in Form des AST vorliegen, zu verarbeiten. Darüber hinausbietet die Syntax der Grammatiken von ANTLR die Möglichkeit, durch die Modifikationszei-chen ’!’ und ’^’ die Struktur des durch den Parser aufgebauten AST zu steuern.

Mit dem ’!’-Zeichen lässt sich die Aufnahme eines Tokens oder Terminals in den AST unter-drücken. Diese Funktion ist essentiell für die Erstellung der optimierten ASTs nach Kapitel 4.3.5,da die Optimierung auf genau dieser Unterdrückung ausgewählter Elemente des AST beruht.

5.1.2 Syntax für Grammatiken

In Kapitel 4.3 wurde die Verwendung kontextfreier Grammatiken zur Analyse von Zusicherun-gen vorgeschlagen. Für die Implementierung wurde daher die im Folgenden beschriebene kon-krete Syntax für Grammatiken festgelegt.

Zunächst sind die grundsätzlichen Sprachelemente zu spezifizieren.

Die Bezeichner (IDENTIFIER) für Nicht-Terminale aus N beginnen mit einem Großbuchsta-ben und bestehen aus Groß- und mindestens einem Kleinbuchstaben. Daneben sind Ziffern und

5.1 Realisierung grammatikbasierter Zertifikate 101

Unterstriche zulässig. Terminale werden durch Zeichenketten in einfachen Hochkommata darge-stellt.

Daneben sind die Lexeme INT, REAL, HEX, STRING und DATE definiert, die wie Terminaleverarbeitet werden und die jeweiligen frei wählbaren Bestandteile der Primärtexte repräsentieren.Die Lexeme werden in einer Menge L zusammengefasst.

Eine GCG-Datei besteht aus Regeln der Form

IDENTIFIER ’:’ regelRHS ’;’

Der Regelkörper regelRHS besteht aus einer oder mehreren durch das ’|’-Symbol getrenntenVarianten für das vorstehende Nicht-Terminal.

Jede Variante des Regelkörpers ist definitionsgemäß aus einem oder mehreren Elementen ausT ∪ N und Lexemen zusammengesetzt. Alle Elemente können durch ?, * und + quantifiziertwerden.

Es wurde bewusst auf die Möglichkeit zur Verwendung von Klammern zur Gruppierung vonElementen verzichtet. Bei der Generierung eines Parsers werden Klammern durch automatischerzeugte Nicht-Terminale (z. B. PAREN-1) ersetzt. Dieser Vorgang soll jedoch explizit durch denErsteller der Grammatik durchgeführt werden, indem er für die üblicherweise durch die Klam-mern gruppierten Terme neue Nicht-Terminale mit entsprechenden Produktionsregeln definiert.Dadurch können sinnvolle Nicht-Terminal-Bezeichner gewählt werden und der gruppierte Be-standteil der Zusicherung wird dadurch im Syntaxbaum durch einen entsprechend benanntenKnoten verständlicher repräsentiert.

In Anlehnung an die Syntax der Grammatiken des vorgestellten Parser-Generators ANTLR wer-den zusätzliche Modifikatoren (’!’ und ’^’) definiert, die die Generierung der AST beeinflussenkönnen.

Enthält eine Regel auf ihrer rechten Seite keine Nicht-Terminale, so soll sie als terminale Regelbezeichnet werden und kann in der einfachsten Form aus einem Terminal oder einem Lexembestehen. Wird die rechte Seite um weitere Terminale erweitert, so müssen alle Terminale bisauf eines durch ein nachgestelltes ’!’ als unsichtbar markiert werden. Auf diese Weise wird nureines der Terminale bzw. das Lexem in den AST aufgenommen. Dadurch vereinheitlicht sich dieAuswertung des AST.

Umgekehrt kann in einer Regel, die auch Nicht-Terminale enthält und somit einen inneren Kno-ten des AST beschreibt, ein Terminal durch ein nachgestelltes ’^’ markiert werden. In diesemFall wird das Terminal in den AST innerhalb eines inneren Knoten aufgenommen.

Die exakte Syntax der GC-Grammatiken wurde durch eine ANTLR-Grammatik modelliert undist in Anhang C.1 enthalten.


5.1.3 Parser-Erzeugung

Zur Verarbeitung der Primärtexte und der ASTs werden entsprechende Parser benötigt. Der Pri-märtext wird durch einen gewöhnlichen auf Textdaten arbeitenden Parser in einen AST umge-setzt. Zur Verarbeitung von ASTs wird ein sogenannter Baumparser benötigt, der auf der hierar-chischen Datenstruktur des AST arbeitet und als Ergebnis wieder den ursprünglichen Primärtextliefert.

Beide Parser-Typen können durch ANTLR bereitgestellt werden. Jedoch ist es notwendig, aus ei-ner GC-Grammatik eine ANTLR-Parser-Grammatik und eine ANTLR-Baumparser-Grammatikzu erzeugen, die das gewünschte Ergebnis liefern.

Zu diesem Zweck wurde im Rahmen dieser Arbeit ein Grammatik-Generator entwickelt, derauf Basis einer gegebenen GC-Grammatik die benötigten ANTLR-Grammatiken erzeugt. DerGenerator wurde in Perl geschrieben (Programmname: trans_gcertgrammar.pl, kurz: t_gcg.pl)und übersetzt die Grammatiken unter Berücksichtigung der entsprechenden Optimierungen desAST gemäß Abschnitt 4.3.5.

Je nach gewünschter Zielgrammatik wird der Grammatik-Generator in verschiedenen Modi auf-gerufen.

5.1.3.1 Generierung der Parser-Grammatik

Im Modus zur Erzeugung einer Parser-Grammatik werden die Produktionsregeln der GC-Gram-matik in Regeln der ANTLRv3-Grammatik umgesetzt. Hierbei wird jeder Regel ein speziellesKonstrukt zur Generierung eines Teils des AST mitgegeben. Im Folgenden sollen einige Beispie-le dieses Vorgehen veranschaulichen.

Eine einfache terminale Regel, die das Nicht-Terminal Name auf eine Zeichenkette abbildet,

Name : STRING;

wird auf eine entsprechenden ANTLRv3-Regel abgebildet:

r_Name : STRING -> ^(Name STRING);

Da in ANTLR Nicht-Terminale mit Kleinbuchstaben beginnen müssen, wird dem Regelnamenein Präfix ’r_’ vorangestellt. Der Regelkörper ist um die Bildungsvorschrift für den AST erwei-tert. Diese beginnt mit dem Pfeil ’->’ und beschreibt das Einfügen eines Knotens ’^( ... )’ inden AST. Dieser erhält das Label Name und enthält die eingelesene Zeichenkette. In der XML-Darstellung entspricht dies dem XML-Knoten

<Name><GCELEMENT type="STRING">nciphercrypt1</GCELEMENT>

</Name>


Enthält die GC-Regel weitere durch ’!’ gekennzeichnete Terminale, so werden diese zwar einge-lesen, jedoch nicht im AST berücksichtigt:

Zertifizierung : ’- ’! ’FIPS 140-2 Level 3’ ’\n’![...]| ’- ’! ’ZKA-Zulassung’ ’\n’!;

r_Zertifizierung : ’- ’ ’FIPS 140-2 Level 3’ ’\n’-> ^(Zertifizierung ’FIPS 140-2 Level 3’ )[...]

| ’- ’ ’ZKA-Zulassung’ ’\n’-> ^(Zertifizierung ’ZKA-Zulassung’ );

Die Spiegelstriche und Zeilenumbrüche werden lediglich für die bessere Lesbarkeit des Primär-textes benötigt und entfallen daher. Ein entsprechender Abschnitt aus einem XML-codierten ASTenthält somit Knoten mit Label Zertifizierung. Die GCELEMENT-Knoten vom Typ TOKEN wer-den nicht beim Parsing-Vorgang sondern erst in der abschließenden XML-Kodierung eingefügt.

<Zertifizierung><GCELEMENT type="TOKEN">FIPS 140-2 Level 3</GCELEMENT>

</Zertifizierung><Zertifizierung>

<GCELEMENT type="TOKEN">ZKA-Zulassung</GCELEMENT></Zertifizierung>

Bei GC-Regeln, die auf der rechten Seite Nicht-Terminale enthalten, werden definitionsgemäßalle Terminale nicht in den AST aufgenommen und nur die Nicht-Terminale berücksichtigt.

Server : ’der Kryptoserver ’ Servername Schrank;

r_Server : ’der Kryptoserver ’ r_Servername r_Schrank-> ^(Server r_Servername r_Schrank );

Neben der Erzeugung der Produktionsregeln werden zusätzliche, fest definierte Lexeme und not-wendige Header erzeugt. Die resultierende Grammatik ist eine kombinierte Parser- und Lexer-Grammatik. Als Parsing-Mechanismus wird die k(*)-Methode (adaptive Vorausschau mit Über-gang zu Backtracking) vorgegeben.

5.1.3.2 Generierung der Baumparser-Grammatik

Die Erzeugung der ANTLRv3-Grammatik zur Erstellung eines Baumparsers für ASTs erfolgtnach dem umgekehrten Prinzip wie die Erstellung des Primärtext-Parsers. Im Parsing-Ausdruckwerden statt (Nicht-)Terminale Baumausdrücke verwendet. Die dabei auftauchenden Nicht-Ter-minale oder Lexeme werden mit automatisch generierten Labels der Form r1, r2, . . . versehen.Diese werden bei der Anwendung des Template-Mechanismus von ANTLR verwendet. Hierbei


wird als abgeleiteter Ausdruck eine Zeichenkette erzeugt, die durch Platzhalter mit den Inhaltender geparsten Baumknoten des AST erweitert werden kann. Dieses Vorgehen wird mittels desbereits im vorangegangenen Abschnitt vorgestellten Beispiels illustriert. Hierbei werden jeweilsdie Parser- und die Baumparser-Regel gegenübergestellt.

Die einfache Speicherung eines Nicht-Terminals kann mit einem ebenfalls sehr einfachen Tem-plate zurückgewonnen werden.

r_Name : STRING -> ^(Name STRING);

r_Name : ^(Name r12=STRING )-> template(p12={$r12.text})

"<p12>";

Die Baumparser-Regeln erhalten die gleichen Namen wie die des Primärtextparsers. Die rechteSeite der Regel ist analog zur Knotengenerierung aufgebaut: ein Knoten mit Label Name undeiner Zeichenkette. Beim Einlesen der Zeichenkette wird dazu ein internes Objekt mit einem Be-zeichner (hier r12) angelegt. Für die Befüllung des Templates kann auf die Zeichenkette durchdie text-Methode des über $r12 referenzierten Objektes zugegriffen werden. Diese wird der Va-riablen p12 zugewiesen. Diese Variable kann – in spitze Klammern gesetzt – in der Template-Zeichenkette verwendet werden.

Wurden bei der Knotengenerierung redundante Terminale verworfen, so müssen diese in derTemplate-Zeichenkette wieder aufgenommen werden. Die Information der redundanten Zei-chenketten wird somit aus der GC-Grammatik in die ANTLR-Grammatik übernommen und istschließlich im Baumparser enthalten.

r_Zertifizierung: ’- ’ ’FIPS 140-2 Level 3’ ’\n’-> ^(Zertifizierung ’FIPS 140-2 Level 3’ )

...| ’- ’ ’ZKA-Zulassung’ ’\n’-> ^(Zertifizierung ’ZKA-Zulassung’ );

r_Zertifizierung: ^(Zertifizierung ’FIPS 140-2 Level 3’ )-> template()

"-<\ >FIPS<\ >140-2<\ >Level<\ >3<\n>"...

| ^(Zertifizierung ’ZKA-Zulassung’ )-> template()

"-<\ >ZKA-Zulassung<\n>"

In diesem Beispiel werden lediglich die eingelesenen Terminale ergänzt und die ausgelassenenZeichenketten ’- ’ und ’\n’ wieder eingefügt (Leerzeichen und Zeilenumbrüche werden ebenfallsin spitze Klammern gesetzt).


Für Regeln mit Nicht-Terminalen wird wie bei den Lexemen der Inhalt durch Objekte aufge-nommen, mit denen Platzhalter für die Templates belegt werden können.

r_Server : ’der Kryptoserver ’ r_Servername r_Schrank-> ^(Server r_Servername r_Schrank );

r_Server : ^(Server r7=r_Servername r8=r_Schrank )-> template(p7={$r7.st}, p8={$r8.st})"der<\ >Kryptoserver<\ ><p7><p8>";

Im Beispiel wird ein Server-Knoten des AST eingelesen. Dieser enthält zwei Unterknoten, derenrekursiv geparster Inhalt den beiden Objekten r7 und r8 zugewiesen wird. Das Template sorgtfür die Rückgewinnung des Terminals ’der Kryptoserver ’ und hängt daran den (mittels der st-Funktion) zurückgewonnenen Text aus den beiden Unterknoten an.

5.1.4 Erstellung von GC-Grammatiken

Grundsätzlich sind Ersteller von Grammatiken für grammatikbasierte Zertifikate im Rahmender in Anhang C.1 festgelegten Syntax frei bei deren Gestaltung. Da jedoch beim Entwurf vonGrammatiken eine große Zahl von Fehlern gemacht werden kann, wurde ein einfaches Verfah-ren entwickelt, um aus einem vorgegebenen Beispieltext durch einen kleinen Satz von erlaubtenUmformungsschritten eine passende Grammatik zu dem gewählten Beispiel und vergleichbarenTexten im gleichen Anwendungskontext abzuleiten. Zur weiteren Unterstützung wurde exem-plarisch ein Satz von Makros für den Editor vim entwickelt, mit denen die Umformungsschrittedurch einfaches Markieren und Aufruf des passenden Makros durchgeführt werden können.

Das Verfahren startet mit einem Beispieltext, der als Textdatei im Editor vorliegt. Der Text soll-te idealerweise bereits auf eine vorgegebene Breite (z. B. 72 Zeichen) umgebrochen sein undinhaltlich sinnvoll durch Absätze strukturiert sein. So können beispielsweise Aufzählungen alszeilenweise organisierte Listen mit vorangestellten Spiegelstrichen o. ä. gestaltet werden.

In einem ersten Schritt (Makro gca) wird die Textdatei in eine Grammatik überführt, indem jedeZeile in ein Terminal umgewandelt wird und die entstehende Folge von Terminalen in eine Regelmit dem Startsymbol S eingefasst wird. Die so entstehende Grammatik hat bei einer n-zeiligenAusgangsdatei die Form

S : T1T2 . . . Tn;

Allgemein wird im Weiteren zur Darstellung der rechten Seite einer Regel die SchreibweiseABC verwendet. Hierbei sind A, B und C Folgen von Elementen, die aus den Mengen derTerminale, Nicht-Terminale und Lexeme bestehen, so dass A,C ∈ (N ∪ T ∪ L)∗ und B ∈(N ∪ T ∪ L)+ ist.


Jedes Terminal besteht aus Zeichenfolgen der Form ′αβγ′ mit Mindestlänge eins, wobei für dieLängen der Teilzeichenketten gelten soll

|α| ≥ 0 |β| ≥ 1 |γ| ≥ 0

Ausgehend von dieser trivialen Grammatik sind die im Folgenden beschriebenen Umformungenerlaubt. Bei den Umformungen wird jeweils der Aufruf für den zugehörigen Makro-Baustein imEditor in Klammern genannt.

Umwandlung einer Elementfolge in ein Nicht-Terminal (gctr): eine Folge B von Elementen derrechten Seite einer Regel für das Nicht-Terminal N1 wird durch ein neues Nicht-Terminal N2

ersetzt und eine entsprechende neue Regel angelegt. Die Änderungen in der Grammatik sinddabei

N1 → A B C ⇒{N1 → A N2 CN2 → B

Dabei kann N2 auf der rechten Seite von N1 durch Quantoren ergänzt werden (*, +, ?). DemRegelkopf von N2 kann optional der Knoten-Modifikator ’!’ zur Unterdrückung der Ausprägungeines Knotens im AST hinzugefügt werden. Diese Modifikatoren werden durch das Makro vomBenutzer abgefragt.

Umwandlung einer Teilzeichenkette innerhalb eines Terminals in ein Nicht-Terminal (gcsr): eswird eine Teilzeichenkette β eines Terminals durch ein neu zu definierendes Nicht-Terminal N2

ersetzt. Dabei entstehen aus den Teilzeichenketten des umgewandelten Terminals T = ′αβγ′

neue Terminale ′α′, ′β′ und ′γ′.

N1 → A ′αβγ′ C ⇒{N1 → A ′α′ N2

′γ′ CN2 → ′β′

Die neuen Terminale ′α′ und ′γ′ werden nur dann eingesetzt, sofern |α| > 0 bzw. |γ| > 0 gilt. Derneue Nicht-Terminal-Bezeichner kann wie bei der Umwandlung von Elementfolgen quantifiziertbzw. modifiziert werden.

Hinzufügen einer (terminalen) Regelalternative (gcra): eine bestehende Regel wird um eine ggf.weitere Alternative erweitert.

N1 → . . . | A1 B1 C1 ⇒ N1 → . . . | A1 B1 C1 | ′αβγ′

Verkürzung des gespeicherten Terminals innerhalb einer terminalen Regel (gcsa): Aus dem imAST gespeicherten Terminal einer terminalen Regel N wird eine Teilzeichenkette β als im ASTzu speichernder Teil markiert. Die restlichen Teilzeichenketten werden zu unsichtbaren Termi-nalen umgewandelt.

N → A ′αβγ′ C ⇒ N → A ′α′! ′β′ ′γ′! C


Hierbei dürfen A und C nur aus unsichtbaren Terminalen der Form ′ανβνγν′! bestehen. Die

unsichtbaren Terminale werden wiederum nur dann eingesetzt, sofern |α| > 0 bzw. |γ| > 0 gilt.

Ersetzung einer Elementfolge durch ein Element X ∈ N ∪ L: eine Folge von Elementen kanndurch ein Nicht-Terminal ersetzt werden (z. B. wenn dieses bereits die Folge dieser Elementeabdeckt) oder ein Terminal (Elementfolge der Länge 1) kann durch ein passendes Lexem ersetztwerden.

N → A B C ⇒ N → A X C mit X ∈ N ∪ L

Entfernen einer Regelalternative (gcda): In Regeln mit mindestens zwei Alternativen kann eineAlternative gelöscht werden. Als Beispiel soll eine Alternative der Form A2 B2 C2 aus einerRegel N entfernt werden.

N → A1 B1 C1 | A2 B2 C2 | A3 B3 C3 ⇒ N → A1 B1 C1 | A3 B3 C3

Die hier vorgestellten Umformungen ermöglichen es, aus einem Beispieltext einer Zusicherungin einem Top-Down-Verfahren schrittweise eine Grammatik abzuleiten, die eine Klasse von Zu-sicherungen für den vorliegenden Anwendungsfall abdeckt. Da nach der initialen Erstellung jedeUmformung des Textes so ausgeführt wird, dass wiederum eine gültige Grammatik entsteht,können viele Fehler bei der Erstellung vermieden werden.

Ein ausführliches Beispiel, das die Umwandlung eines konkreten Zusicherungstextes durch dieoben eingeführten Umwandlungsschritte zeigt, ist in Anhang D.1 enthalten.

Zur Prüfung der entstandenen Grammatik gibt es zwei weitere Werkzeuge. Zum einen wurde einParser für die Syntax-Prüfung auf Basis der in Anhang C.1 definierten Meta-Grammatik erstellt,der die syntaktische Korrektheit der erstellten Grammatik prüft. Zum anderen werden bei derGenerierung der ANTLR-Parser Mehrdeutigkeiten und Rekursionen erkannt, die dann korrigiertwerden können. Diese Fehlerfälle treten jedoch bei der Modellierung der natürlichsprachlichenZusicherungen selten auf, da speziell die Terminale, die auf Basis ganzer Sätze entstehen, imGegensatz zu den kompakten Elementen einer Programmiersprache sehr gut voneinander zudifferenzieren sind.

5.1.5 Erstellung von Zusicherungen

Bei der Erstellung von Zusicherungen auf Basis einer vorgegebenen GC-Grammatik ist es eben-falls sinnvoll, den Anwender durch Hilfswerkzeuge zu unterstützen.

Grundsätzlich wäre es zwar möglich, die Zusicherung mittels eines einfachen Editors zu schrei-ben und im Anschluss einem Parser auf Basis der Grammatik zuzuführen. Allerdings ist dieserProzess sehr fehleranfällig, da jedes Zeichen einschließlich aller Zeilenumbrüche und Leerzei-chen relevant ist und im Rahmen der erlaubten Vorgaben liegen muss.

Daher wurde auf Basis des XText-Projektes [Ecl] der Eclipse Foundation ein Mechanismus zurBereitstellung spezieller Editoren für die Zusicherungen entworfen. Das XText-Projekt stellt,


ebenfalls unter Verwendung der ANTLR-Bibliotheken, ein Entwicklungsrahmenwerk für an-wendungsspezifische Sprachen bereit. Ein wesentliches Element des Rahmenwerkes ist die Ge-nerierung von sprachspezifischen Editoren, die es ermöglichen, den Anwender bei der Eingabegrammatikkonformer Texte zu unterstützen.

XText-Grammatiken weisen starke Ähnlichkeit mit den ANTLR-Grammatiken auf, so dass esleicht möglich ist, aus einer vorgegebenen GC-Grammatik eine entsprechende XText-Grammatikabzuleiten. Hierzu wurde der Grammatik-Konverter t_gcg.pl um eine weitere Zielgrammatikerweitert.

Das folgende Beispiel zeigt einen Ausschnitt aus einer XText-Grammatik:

Dienst: gc_Dienstname_1=Dienstname l2=’ auf Port ’gc_Portnummer_3=Portnummer l4=’\n’;

Dienstname: l1=’ssh’ | l1=’dns’ | l1=’smtp’ | l1=’http’| l1=’https’ | l1=’ntp’;

Portnummer: gc_Portnummer_1=INT;

Aus den so entstehenden XText-Grammatiken kann in der prototypischen Implementierung mitHilfe der Eclipse-Entwicklungsumgebung über einen vordefinierten automatisierten Workflowein Editor bereitgestellt werden, der an jeder Stelle der Eingabe dem Anwender die erlaubtenTextteile zur Auswahl anbietet und nach Auswahl in den Text einfügt. Als korrekt erkannte Text-teile (automatisch oder manuell eingefügt) werden deutlich sichtbar durch farbige und fett ge-druckte Fonts markiert.

Abbildung 5.2 ist ein Bildschirmfoto, das die Anwendung des Editors zeigt. Der zu Demon-strationszwecken fälschlicherweise klein geschriebene Begriff portscan ist durch Wellenlinienmarkiert. Ein Kontextdialog stellt die möglichen Dienstbezeichner zur Auswahl.

Eine Alternative zur Unterstützung der Erstellung von Zusicherungen ist die Verwendung einerApplikation, die beispielsweise in Dialogform die notwendigen Eingaben erfragt. Diese kann– im Gegensatz zum Texteditor – direkt strukturierte Daten erzeugen. Ein Beispiel für einensolchen Dialog ist in Abbildung 5.3 zu sehen.

Um auch im Fall der Dialog-gestützten Eingabe für das gleiche Verständnis der gegebenen Zusi-cherung beim Anwender wie bei Erstellung des Primärtextes zu sorgen, kann vor Erstellung derSignatur eine Rückgewinnung mit den strukturierten Daten durchgeführt werden.

Die verschiedenen Arten zur Erstellung eines GC sind in Abbildung 5.4 dargestellt.

5.1.6 Zertifikatskodierung

Für die prototypische Implementierung wurde ein XML-Datenformat gewählt, mit dem die Zer-tifikatselemente aus Kapitel 4.4.1 umgesetzt werden. Das Datenformat wurde in einer XML-Schema-Datei spezifiziert, die in Anhang C.2 enthalten ist.


Abbildung 5.2: XText-gesteuerte Eingabe einer Zusicherung

Abbildung 5.3: Eingabemaske für Prüfergebnis

Das gesamte GC wird von einem GrammarbasedCertificate-Element eingefasst, das mit einemID-Attribut mit dem Wert tbsGCertificate gekennzeichnet ist. Dieses markiert die gesamte XML-Datenstruktur für die spätere Signatur.

Die Versionsnummer ist auf 1.0 festgelegt. Die Seriennummer eines GC wird durch die Be-rechnung des md5-Hashwertes über die Konkatenation von inhaltsspezifischen und zufälligenWerten gebildet. Im Prototyp gehen in diesen Hashwert die strukturierten Daten, der öffentlicheSchlüssel des Ausstellers der Zusicherung, die aktuelle Zeit und ein Zufallswert ein.

Im Issuer-Element wird für jedes Element des DistinguishedName des Ausstellers ein Tag mit


Primärtext p

StrukturierteDaten X

StrukturierteEingabe

Anzeige

SignaturG

Grammatik-gesteuerter

Editor

Ableitung

Abbildung 5.4: Verarbeitungsschritte bei der Erstellung grammatikbasierter Zertifikate

dem entsprechenden Inhalt aufgenommen. Die Tags entsprechen dabei in Reihenfolge, Schreib-weise und Inhalt der Darstellung nach RFC 2253 [WKH97].

Der Gültigkeitszeitraum wird im Validity-Element mit den Elementen NotBefore und NotAfterangegeben. Diese Angaben sind XML-konforme Zeitangaben in UTC-Zeit. Es ist zulässig, inAnwendungsfällen, in denen ein Sachverhalt lediglich zu einem bestimmten Prüfzeitpunkt fest-gestellt wird, nur die NotBefore-Angabe aufzunehmen.

Die Grammatik-Referenz wird z. B. mittels des SHA256-Hashalgorithmus gebildet und kannneben Hashwert und Algorithmus-Angabe auch die optionalen Elemente URI (Ablageort derGrammatik) und GrammarServer enthalten. Das letztgenannte weist auf einen Grammatikserverhin, bei dem über den Grammatik-Hash die Grammatik abgerufen werden kann.

<GrammarReference><DigestMethod>sha256</DigestMethod><DigestValue>BWGaLRe9975oI ... lwvhSs9XjNBXA=</DigestValue><URI>http://security.example.com/grammars/m572.gcg</URI><GCGrammarServer>http://gcgsrv.example.com/grammarserver</GCGrammarServer>

</GrammarReference>

Für die Algorithmen-Bezeichner sind sha256, sha384 und sha512 zulässig. Grundsätzlich lassensich hier weitere Verfahren als erlaubt aufnehmen (z. B. die anstehende SHA-3-Familie).

Innerhalb eines Assertion-Elementes wird ein ParseTree-Element eingefügt, das die XML-kodierteForm des AST der Zusicherung nach Abschnitt 4.6.3.1 enthält.

Das Assertion-Element kann auch mehrfach aufgenommen werden. Für diesen Fall kann esoptional sowohl ein Validity- als auch ein GrammarReference-Element enthalten. Diese Anga-ben übersteuern die Validity- und GrammarReference-Elemente auf der Ebene des Assertion-Elementes bei der Interpretation des AST der vorliegenden Zusicherung.


Als optionales Element kann zusätzlich das Nonce-Element aufgenommen werden, das als Frische-Nachweis in Bezug auf eine konkrete Zusicherungsanfrage verwendet werden kann. Das Text-element dieses XML-Knotens enthält die base64-kodierte Form des binären Nonce-Wertes:

<Nonce>AoqSG5dNfIcBZ3GVx+P90Q==</Nonce>

Die Assertion-Elemente können darüber hinaus die Primärsignatur aufnehmen. Diese bestehtaus den beiden base64-kodierten Elementen SignatureAlgorithm und SignatureValue sowie denoptionalen Elementen X509Certificate, PrimarySigner und PrimaryAuthorityKeyIdentifier. Pri-marySigner ist dabei wie das Issuer-Element aufgebaut.

Der Einsatz der Primärsignatur ist z. B. dann sinnvoll, wenn der Primärtext rechtsverbindlich miteiner qualifizierten Signatur unterzeichnet wird, das GC-Zertifikat jedoch mit einem fortgeschrit-tenen Schlüssel transportgesichert wird.

Der Nonce-Wert kann nicht pro Assertion angegeben werden, da die Frische der gesamten Nach-richt hinsichtlich einer Anfrage nachgewiesen werden soll.

Innerhalb des Extensions-Elementes werden Informationen über den Aussteller in Form des op-tionalen Authority Key Identifiers angegeben. Daneben können Informationen zu ggf. erhältlichenSperrinformationen in einem AuthorityInformationAccess- und einem CRLDistributionPoint-Ele-ment eingefügt werden. Diese Elemente sind in Aufbau und Bedeutung stark an die gleichnami-gen Informationen aus RFC 5280 [Day73] angelehnt.

Die gesamten XML-Daten werden nach dem XML Standard Digital Signature signiert. Hier-bei wird lediglich der Signaturwert in das signierte Dokument aufgenommen. Die optionalenSchlüsselinformationen nach Abschnitt 2.3.3 (KeyInfo) brauchen i. d. R. nicht in das Zertifikataufgenommen werden, da im Issuer-Element und im Authority Key Identifier ausreichende In-formationen vorliegen, um ein entsprechendes Zertifikat abrufen und für die Prüfung verwendenzu können.

Das XML-Format wurde aus zwei Gründen als Kodierung für die Zertifikate gewählt. Zum einenkönnen zur Festlegung und Prüfung von Beschränkungen die XPath-Werkzeuge verwendet wer-den. Zum anderen ist das XML-Format durch die Tags selbst erklärend. Abgesehen von der Aus-wertung per XPath lassen sich aber für Übertragung und Speicherung durchaus auch andere For-mate verwenden. Innerhalb des Prototyps wird ein Zwischenformat in Form von S-Expressionsverwendet, dessen Informationsgehalt gleich der XML-Darstellung ist. Es wurden entsprechendeDatenkonverter für die Umwandlung von S-Expressions in XML und umgekehrt implementiert.

So kann das bereits bekannte XML-Fragment

<Dienst><Dienstname>

<GCELEMENT type="TOKEN">ssh</GCELEMENT></Dienstname><Portnummer>

<GCELEMENT type="INT">22</GCELEMENT></Portnummer>

</Dienst>


gleichwertig durch eine deutlich kompaktere S-Expression dargestellt werden:

(Dienst (Dienstname ’ssh’) (Portnummer 22))

Hierbei ist die Information, dass es sich bei ssh um ein Token handelt ist bei dieser Kodierungdurch die einfachen Hochkommata enthalten; Lexeme werden wie im Primärtext kodiert.

Bei den kurzen Texten der Beispiele dieser Arbeit erhöht die XML-Kodierung die Zeichenmengeder Zusicherung, mit der alternativen Kodierung lässt sich jedoch die zu übertragende Datenmen-ge reduzieren. In Tabelle 5.1 wird dies für einige Testfälle dargestellt. Erst wenn die Primärtexte

Primärtext XML-Darstellung S-Expressionswaf.1.tst 309 751 194m173.1.tst 865 1368 388m173.3.tst 753 1133 312m572.2.tst 134 650 134m487.3.tst 433 822 240m487.5.tst 461 931 285

Tabelle 5.1: Exemplarischer Vergleich der Kodierungsverfahren hinsichtlich der Datenmenge

eines Anwendungsfalles längere Textpassagen enthalten, kann auch mit der XML-Kodierungeine Reduktion der Datenmenge erzielt werden.

Eine Alternative zu den S-Expressions bietet noch die bei X.509-Zertifikaten übliche ASN.1-Kodierung, mit der ebenfalls sehr kompakte Kodierungen erzielt werden können. Eine Verbesse-rung aller Verfahren kann darüber hinaus erzielt werden, wenn die Nicht-Terminale einer Gram-matik z. B. in alphabetischer Reihenfolge sortiert und nummeriert werden und statt der teilweiselangen Bezeichner nur ihre Indizes übertragen werden.

Speicher-reduzierenden Kodierungsverfahren für Zusicherungen können daher im Bedarfsfalleingesetzt werden, werden aber im Rahmen der prototypischen Implementierung nicht weiterbetrachtet.

5.1.7 Anwendungsbewertung

Die Anwendung der entwickelten Werkzeuge wurde mit einer ganzen Reihe von Anwendungs-fällen geprüft. Hierzu wurden vor allem Formulierungen für Zusicherungen gewählt, die Fra-gestellungen aus dem IT-Grundschutz und vergleichbaren Auditierungsaufgaben abdecken. Da-neben wurden aber auch andere Anwendungsfälle wie die Berichterstattung nach einer periodi-schen Durchführung von Schwachstellen-Scans (z. B. mit dem Schwachstellenscanner Nessus)und die Automatisierung von Meldungen des aide-Intrusion-Detection-Systems betrachtet.


5.1.7.1 Beispiel einer Prüfung

Als Beispiel für eine Prüfung gemäß IT-Grundschutz wird eine Zusicherung zum Einsatz vonZugangssicherungsverfahren für Rechenzentren gemäß Maßnahmenkatalog M1.73 vorgestellt.

Bei der Auditierung von Rechenzentren wird i. d. R. das Verfahren betrachtet, mit dem der Zu-gang zu den Rechenzentrumsräumen für Bedienstete und Besucher kontrolliert und dokumentiertwird. Der folgende Text dient als Anfangspunkt zur Erstellung der Grammatik.

Für das Rechenzentrum in Haus 2, Raum RZ-01 wurden die Zugangskontrollen auditiert.Bei der Autorisierungsprüfung werden die Kriterien- Wissen- Besitzabgefragt.Besucher werden eindeutig verantwortlichen Personen zugeordnet.Die durchgehende Beaufsichtigung der Besucher ist sichergestellt.Die Zutritte zum Rechenzentrum werden für Berechtigte elektronisch protokolliert.Die Zutritte zum Rechenzentrum werden für Besucher schriftlich protokolliert.Die Austritte aus dem Rechenzentrum werden für Berechtigte elektronisch protokolliert.Die Austritte aus dem Rechenzentrum werden für Besucher schriftlich protokolliert.Die schriftliche Protokollierung wird durch den Beaufsichtigenden abgezeichnet.Beim Zugang zum Rechenzentrum kommt eine Vereinzelungsschleuse zum Einsatz.Für die Berechtigungsnachweise wird eine Anti-Passback-Funktion eingesetzt.

Die daraus erstellte Grammatik lautet damitSatz : ’Für das Rechenzentrum in ’ Ort

’ wurden die Zugangskontrollen auditiert.\n’Autorisierung Besucher Protokollierung VereinzelungPassback;

Ort : STRING ;

Autorisierung: ’Bei der Autorisierungsprüfung werden die Kriterien\n’AutKriterium+ ’abgefragt.\n’ ;

AutKriterium: ’- ’! ’Besitz’ ’\n’! |’- ’! ’Wissen’ ’\n’! |’- ’! ’biometrische Merkmale’ ’\n’!;

Besucher: Zuordnung Aufsicht? ;

Zuordnung: ’Besucher werden eindeutig verantwortlichen Personen ’!’zugeordnet’ ’.\n’! ;

Aufsicht: ’Die durchgehende Beaufsichtigung der Besucher ist ’!’sichergestellt’ ’.\n’! ;

Protokollierung: Zutritt Austritt ;

Zutritt: PZ_Berechtigt PZ_Besucher ;

Austritt: PA_Berechtigt PA_Besucher ;

PZ_Berechtigt: ’Die Zutritte zum Rechenzentrum werden für Berechtigte ’


ProtArt ’ protokolliert.\n’ ;

PZ_Besucher: ’Die Zutritte zum Rechenzentrum werden für Besucher ’ProtArt ’ protokolliert.\n’ Abzeichnung? ;

PA_Berechtigt: ’Die Austritte aus dem Rechenzentrum werden für Berechtigte ’ProtArt ’ protokolliert.\n’ ;

PA_Besucher: ’Die Austritte aus dem Rechenzentrum werden für Besucher ’ProtArt ’ protokolliert.\n’ Abzeichnung? ;

ProtArt!: ’nicht’ | ’elektronisch’ | ’schriftlich’ ;

Abzeichnung: ’Die schriftliche Protokollierung wird durch den Beaufsichtigenden ’!’abgezeichnet’ ’.\n’! ;

Vereinzelung: ’Beim Zugang zum Rechenzentrum kommt ’K_eine ’ Vereinzelungsschleuse zum Einsatz.\n’ ;

K_eine!: ’keine’ | ’eine’;

Passback: ’Für die Berechtigungsnachweise wird ’ K_eine’ Anti-Passback-Funktion eingesetzt.\n’ ;

Das zugehörige XML-kodierte grammatikbasierte Zertifikat wurde in Anhang E aufgenommen.

5.1.7.2 Grammatikerstellung

Bei allen Beispielen zeigte sich, dass die Methode der Erstellung einer Grammatik durch Umfor-mungen von Beispielzusicherungen gut anzuwenden war. Für den Fall optionaler Zusicherungs-anteile ist es dabei jedoch wichtig, dass die Formulierungen der Zusicherung dahingehend op-timiert sind, dass optionale Teile aus dem Text der Zusicherung ausgeschnitten werden können,ohne die Korrektheit des Textes zu verletzen. Es ist daher ggf. eine entsprechende Anpassungder Formulierungen notwendig.

Ein Beispiel für eine solche Anpassung ist die Nennung zweier jeweils optionaler Eigenschaf-ten in einem Satz Der Untersuchungsgegenstand erfüllte die Anforderung A und die Vorgabe B.Durch die Verwendung der Konjunktion ist ein Weglassen einer Teilzusicherung nicht einfachmöglich. In solchen Fällen sind Formulierungen mit jeweils eigenständigen Sätzen für Anforde-rung A und Vorgabe B zu bevorzugen: Der Untersuchungsgegenstand erfüllte die AnforderungA. Der Untersuchungsgegenstand erfüllte die Vorgabe B.

Bei Aufzählungen lässt sich eine quasi-tabellarische Form z. B. mit Spiegelstrichen sehr einfachin eine Grammatik überführen. Es lassen sich jedoch auch für aufzählende Formulierungen wieFür das Beispiel steht Version A, Version B und Version C zur Auswahl, bei der alle Anteile optio-nal sind, sofern mindestens ein Anteil vorkommt, entsprechende Grammatikstrukturen angeben.

Das Grammatikfragment der Form

Optionen: ’Für das Beispiel steht ’ Option L1_Option? ’ zur Auswahl. \n’ ;

Option!: ’Version A’ | ’Version B’ | ’Version C’ | ’Version D’ ;


L1_Option!: L2_Option* ’ und ’ Option;

L2_Option!: ’, ’ Option;

erzeugt für das angegebene Beispiel folgende strukturierte Daten:

<Optionen><GCELEMENT type="TOKEN">Version A</GCELEMENT><GCELEMENT type="TOKEN">Version B</GCELEMENT><GCELEMENT type="TOKEN">Version C</GCELEMENT>

</Optionen>

Wird bei der Erstellung der Grammatik die Eindeutigkeit verletzt, so wird dieses bei der Erstel-lung der Parser bemerkt und als Fehler angezeigt. Ist beispielsweise die letzte Regel des obenstehenden Beispiels fälschlicherweise als

L2_Option!: ’, ’ Option?;

ausgeführt (Nicht-Terminal Option wurde fälschlicherweise mit ’?’ quantifiziert), so werden Feh-lermeldungen der Form

warning(200): var_r.g:43:7: Decision can match input such as"’Version C’" using multiple alternatives: 1, 2

erzeugt. Bei Verwendung der Entwicklungsumgebung antlrworks kann dies auch graphisch wiein Abbildung 5.5 angezeigt werden:

Abbildung 5.5: Graphische Darstellung für uneindeutige Grammatik

Werden in Grammatiken Nicht-Terminale wie im Beispiel gezeigt mehrfach in Regeln verwen-det, kann es zu Mehrdeutigkeiten kommen. Diese mehrfache Verwendung geht über die Ge-staltungsmöglichkeiten der vorgestellten Top-Down-Methode hinaus und stellt eine Grenze zurErstellung von Grammatiken für wenig erfahrene Anwender dar.


5.1.7.3 Erstellung von Zusicherungen

Von den drei vorgestellten Eingabeverfahren einfacher Texteditor, Grammatik-gesteuerter Editorund Formular-basierte Eingabe hat sich der einfache Texteditor in den Fällen der Primärsignatur,des hybriden Verfahrens und des kombinierten Verfahrens als weitgehend unpraktikabel erwie-sen. Da bei den genannten Verfahren der Primärtext signiert wird, muss zur Prüfung eine zei-chengenaue Rückgewinnung erfolgen und somit besteht für den Primärtext kein Freiheitsgrad.Lediglich bei Verzicht auf eine Rückgewinnung (bei ausschließlicher Verwendung der Sekun-därsignatur) wäre eine tolerantere Grammatik z. B. durch beliebige Whitespace-Folgen denkbar.Dieser Anwendungsfall erfüllt jedoch nicht die Anforderung an die Erhöhung der Verbindlichkeitund kann daher als nicht relevant eingestuft werden.

Bei der Verwendung der Grammatik-gesteuerten Editoren auf Basis der automatisch generier-ten XText-Grammatiken ist diese Fehlerquelle ausgeschlossen. Hier zeigte sich bei Tests mitden realisierten Beispielen, dass die Eingabe durch die automatisch vorgegebenen, auswählba-ren Textbausteine sehr schnell erfolgen kann. Ebenfalls werden bestimmte Formatierungen wiez. B. die Anführungszeichen bei Eingabe von freien Zeichenketten (Typ String) automatisch er-zwungen.

Als nachteilig bei dieser Art der Eingabe haben sich Formulierungen in Zusicherungen erwie-sen, deren Bedeutung aus dem nächsten vorgegebenen Textelement nicht erfasst werden kann. Sowerden im o. g. Beispiel nach dem Setzen des Textbausteins Beim Zugang zum Rechenzentrumkommt als nächste Auswahl eine und keine angezeigt, ohne dass das nächste Element Verein-zelungsschleuse zum Einsatz. sichtbar ist. Es ist also notwendig, dass der Anwender auch beider XText-unterstützten Eingabe die jeweils geforderten Formulierungen ungefähr kennt, umdie korrekte Auswahl treffen zu können. Damit ist es also nur in den Fällen einsetzbar, in de-nen dieses Wissen vorausgesetzt werden kann bzw. durch entsprechende Vorgaben in Form vonPrüfvorschriften und Formulierungsvorgaben oder -beispielen vermittelt wird.

Für Fälle, in denen dies nicht erfüllt werden kann, müssen die vorgegebenen Formulierungen sogestaltet werden, dass die bei der Eingabe auswählbaren Textbausteine ausreichend selbsterklä-rend sind.

Bei der Verwendung von Formular-basierten Eingaben mit direkter Generierung der struktu-rierten Daten kann das notwendige Kontextwissen durch entsprechende Formulierungen bei derBeschriftung der Eingabe- und Auswahlfelder vermittelt werden. Daneben können auch sog.Tool-Tips und Hilfefunktionen verwendet werden, um zusätzliche Informationen zu geben.

Das zur Erhöhung der Verbindlichkeit gewünschte Signieren einer natürlichsprachlichen Erklä-rung wird bei der Formular-basierten Eingabemethode durch einen nachgelagerten Rückgewin-nungsschritt erreicht. In diesem werden die strukturierten Daten in den korrespondierenden Textumgesetzt und dem Anwender im Rahmen einer Signaturerstellung angezeigt.

Das Formular-basierte Verfahren erreicht auf diese Weise sowohl eine einfache Erhebung derDaten als auch die Erstellung einer Primärsignatur.

5.2 Semantik der grammatikbasierten Zertifikate 117

5.2 Semantik der grammatikbasierten Zertifikate

Die grammatikbasierten Zertifikate können sowohl die normale Zertifikatssignatur als auch dieoptionale Signatur über die Primärtexte enthalten. Welche Bedeutung diesen jeweiligen Signa-turen zukommt, d. h. welche Schlussfolgerungen ein Akzeptor eines solchen Zertifikats aus denZertifikatsdaten und den referenzierten Grammatiken ziehen kann, wird durch eine Analyse aufBasis der SVO-Logik gezeigt. Die Festlegung einer Semantik erfolgt dabei durch die Definitionvon zwei neuen Ableitungsregeln als Ergänzung der bestehenden Regeln der SVO-Logik. Die-se erweiterten Regeln werden dann dazu verwendet, die Auswertung eines grammatikbasiertenZertifikats formal durchzuführen.

Bei der Modellierung der Zertifikate werden die Mechanismen, die von den standardisiertenX.509-Zertifikaten übernommen wurden, nicht weiter betrachtet, da es sich hierbei um etablierteVerfahren handelt. Es wird daher davon ausgegangen, dass alle Personenzertifikate gegen bereitsvorhandene Vertrauensanker geprüft werden können und die grammatikbasierten Zertifikate ak-tuell gültig sind, so dass keine OCSP- oder CRL-Prüfungen betrachtet werden müssen. Damitwerden die Zusicherungen auf die charakteristischen Bestandteile der grammatikbasierten Zerti-fikate reduziert.

Im Kern enthält ein grammatikbasiertes Zertifikat Z den AST X und den Hashwert H(G) überdie zugrunde liegende Grammatik G. Alle weiteren Informationen wie Nonce-Wert N , Ausstel-ler, Seriennummer, Datum, usw. werden in den Meta-DatenM i. S. einer Menge zusammenge-fasst. Der zu signierende Teil des Zertifikats wird durch den Funktionsausdruck GC(X,H(G),M)dargestellt. Dieser Ausdruck beschreibt die Kodierung der angegebenen Daten als grammatikba-siertes Zertifikat ohne die Signatur. Das gesamte Zertifikat ist damit

Z = bGC(X,H(G),M)cK−1B

Werden Teile der Meta-Daten benötigt, wie beispielsweise der Nonce-Wert zum Nachweis derFrische, so können diese ausM herausgezogen werden, so dass z. B. (N,M′) =M ist:

Z = bGC(X,H(G), N,M′)cK−1B

Zur Auswertung muss der Empfänger den zweiten Wert H(G) als Hashwert über die Grammatikerkennen können. Dies setzt nach (Ax15) der SVO voraus, dass der Empfänger die GrammatikG besitzt. Mit dieser kann dann mittels Φ−1G eine Rückgewinnung durchgeführt werden, die ausdem AST X den Primärtext p erstellt.

5.2.1 Axiome zur Interpretation

Zur Darstellung des Zusammenhangs zwischen strukturierten Daten und Primärtext auf Basisder Grammatik G wird das 3-stellige Prädikat GCV eingeführt:

X = ΦG(p) ∧X 6= ⊥ ⇔ p = Φ−1G (X) ∧ p 6= ⊥ ⇔ GCV(X,G, p) (5.1)


Diese Darstellung ist an das SVO-Prädikat zur Signaturprüfung SV(X,K, Y ) angelehnt. Somitwird das Prädikat GCV mit (4.1) und (4.2) genau dann wahr, wenn die Rückgewinnung von p ausX mit Φ−1G (X) möglich ist oder umgekehrt aus X = ΦG(p) aus p gebildet werden kann. Damitgilt

GCV(X,G, p) ⇒ p ∈ L (G) (5.2)

Definition 1. Das Äußern eines strukturierten Datums X im Kontext eines grammatikbasiertenZertifikats zusammen mit einem Hashwert einer Grammatik G, mit der aus einem Primärtext pdas strukturierte Datum X erzeugt werden kann, ist gleichbedeutend mit dem Äußern von p.

Die Interpretation eines grammatikbasierten Zertifikates wird festgelegt als:

Q says GC(X,H(G),M) ∧GCV(X,G, p)→ Q says p (GC1)

5.2.2 Kompetenz

Zur Übernahme von Aussagen in die eigenen Überzeugungen ist jedoch noch die Betrachtungder Kompetenz notwendig. Der Kompetenzbereich (Jurisdiktion) wird dabei ebenfalls durch dieReferenzierung einer Grammatik definiert.

Der Sprachumfang L (G) einer Grammatik ist in extensionaler Darstellung eine Menge vonWorten {p1, p2, . . .} (hier auch als Sätze oder Zusicherungen bezeichnet). Daher wird eine ent-sprechende Kurzschreibweise festgelegt.

Definition 2. Die Kompetenz (Jurisdiktion) über den Sprachumfang einer Grammatik (Mengevon Aussagen) entspricht der Konjunktion der Kompetenz über die einzelnen Aussagen der Men-ge, geschrieben als

P controls L (G) = P controls {p1, p2, . . .}=def P controls p1 ∧ P controls p2 ∧ . . . für pν ∈ L (G) (5.3)

Für eine eingeschränkte Sprache L (G, r) nach (4.14) gehört p nur dann zum Sprachumfang,wenn sowohl p dem Sprachumfang der unbeschränkten Grammatik angehört, als auch das korre-spondierende X die Anforderungen an die Beschränkungen erfüllt. Daher kann folgende Regelaufgestellt werden:

P controls L (G, r) ∧GCV(X,G, p) ∧GCR(X, r)→ P controls p (GC2)

Für r = ⊥ ergibt sich mit (4.10) und (4.15) eine einfachere Form dieser Implikation:

P controls L (G) ∧GCV(X,G, p)→ P controls p

5.3 Vergleich der Signaturverfahren 119

5.2.3 Korrektheit

Zum Nachweis der Korrektheit von (GC1) wird zunächst die Prämisse als falsch angenommen.Da mit einer falschen Prämisse auf jede Konklusion geschlossen werden kann, ist auch (GC1)für diesen Fall wahr.

Ist die linke Seite wahr, so ist die Regel ebenfalls richtig, da das Prädikat GCV(X,G, p) nach(5.2) genau den in der Definition 1 geforderten Zusammenhang zwischen den Parametern X undp sicherstellt und somit die Implikation wahr ist. Somit kann aus der Äußerung des Zertifikatsdie Äußerung von p geschlossen werden. Damit ist (GC1) für alle möglichen Belegungen derPrämissen wahr und damit korrekt.

Für das Axiom (GC2) gilt: ist die Prämisse falsch, so ist (GC2) wahr. Ist die Prämisse wahr, so istaus GCV(X,G, p) nach (5.2) p ∈ L (G) und damit X = ΦG(p) ableitbar. Da auch GCR(X, r)wahr ist, folgt über (4.14), dass p ∈ L (G, r) ist. Damit ist aber nach (5.3) auch Q controls pwahr.

5.3 Vergleich der Signaturverfahren

Um die Aussagekraft signierter Zusicherungen in primärer und sekundärer Form und die jeweilsnotwendigen Prämissen und Ableitungsschritte miteinander vergleichen zu können, werden diesein SVO-Logik modelliert. Allen Modellierungen gemeinsam sind dabei folgende Annahmen:

Der Primärtext p korrespondiert mit den strukturierten Daten X durch eine Kodierung mittelsder Grammatik G, so dass GCV(X,G, p) = T ist.

Der Bestätiger B signiert die von ihm gegebenen Zusicherungen mit einem Schlüssel K−1B , des-sen öffentliches Pendant KB beim Akzeptor A bekannt und dem Eigentümer B zugeordnet ist.Desgleichen räumt A dem Bestätiger die Kompetenz über den Sprachraum L (G) der Gramma-tik G ohne Beschränkungen ein. Die Kompetenzbestätigung liegt A bereits vor und kann mitder einfachen Form von (GC2) angewendet werden. B hat zuvor von A im Rahmen der Bitteum eine Bestätigung eine Anfragenummer (Nonce-Wert N ) erhalten, die er im Rahmen seinerZusicherung als Frische-Nachweis beifügen kann.

Es werden in jedem Teilkapitel die Prämissen mit Px gezählt, die Schlussfolgerungen mit Cx. Beiallen Schritten der Herleitung werden jeweils die angewandten SVO-Axiome gemäß Anhang Asowie die verwendeten Prämissen und Zwischenergebnisse angegeben.

Das Ziel jeder Herleitung ist die Akzeptanz der Aussage p bzw. der lokalen Sicht 〈p〉∗A durch A.

5.3.1 Primärtext mit Primärsignatur (p-p)

Der Bestätiger signiert unmittelbar den Primärtext und überträgt diesen samt Signatur.


Die Prämissen sind:

A believes PKσ(B,KB) KB ist für A der öffentliche Schlüssel von B. (P1)A believes fresh(N) A betrachtet N als frisch. (P2)A believes B controls L (G) B hat Kompetenz über Aussagen aus Grammatik G. (P3)A received bpcK−1

BA empfängt die signierte Aussage p. (P4)

A believes A received b〈p〉∗AcK−1B

Interpretation von (P4) durch A (P5)

A believesSV(b〈p〉∗AcK−1

B, KB, 〈p〉∗A) A kann die Signatur positiv prüfen. (P6)

A believes GCV(X,G, p) A kann prüfen, dass p Element von L (G) ist. (P7)(5.4)

Im ersten Schritt stellt der Akzeptor die Authentizität der empfangenen Nachricht fest

A believes B said (〈p〉∗A) (C1)durch Ax6, Nec, P1, P5, P6, Ax1, MP

Somit ist zunächst die Authentizität des Primärtextes nachgewiesen. Jedoch kann keine Aussagezur Frische dieses Datums gemacht werden, es kann sich also auch um eine Wiedereinspielunghandeln.

Um die Frische dennoch nachweisen zu können, besteht die Möglichkeit, in der erteilten Zusi-cherung die Anfragenummer (Nonce) aufzunehmen. Somit ist

p = F (p′, N) (P8)

Da A von der Frische von N überzeugt ist, muss auch eine Zusicherung mit N frisch sein.

A believes fresh(〈F (p′, N)〉∗A) (C2’)durch Ax19, Nec, P2, Ax1, MP

A believes fresh(〈p〉∗A) (C2)durch P8

Durch die Frische kann die Nachricht der laufenden Anfrage zugeordnet werden (aktueller Pro-tokolllauf)

A believes B says (〈p〉∗A) (C3)durch Ax21, Nec, C1, C2, Ax1, MP

Die Ableitung der Kompetenz für die Aussage p erfolgt durch die Grammatikprüfung

A believes B controls 〈p〉∗A (C4)durch GC2, Nec, P3, P7, Ax1, MP


Abschließend erfolgt die Übernahme der Aussage in die eigene Sicht von A

A believes 〈p〉∗A (C5)durch Ax18, Nec, C3, C4, Ax1, MP

5.3.2 Sekundärdaten mit Sekundärsignatur (s-s)

Bei diesem Verfahren erstellt der Bestätiger ein grammatikbasiertes Zertifikat durch Signatur derstrukturierten Daten X = ΦG(p).

Die zugehörigen Prämissen lauten:

A believes PKσ(B,KB) (P1)A believes fresh(N) (P2)A believes B controls L (G) (P3)A received bGC(X,H(G), N,M)cK−1

B(P4)

A believes A received bGC(〈X〉∗A,H(G), N, 〈M〉∗A)cK−1B

(P5)

A believes SV(bGC(〈X〉∗A,H(G), N, 〈M〉∗A)cK−1B, KB,GC(〈X〉∗A,H(G), N, 〈M〉∗A) (P6)

A believes GCV(〈X〉∗A, G, 〈p〉∗A) (P7)(5.5)

Die Ableitung der Authentizität erfolgt auf Basis der Signatur

A believes B said GC(〈X〉∗A,H(G), N, 〈M〉∗A) (C1)durch Ax6, Nec, P1, P5, P6, Ax1, MP

Für die Ableitung der Frische der Nachricht wurde vom Ersteller der Nonce-WertN im Zertifikataufgenommen.

A believes B fresh(GC(〈X〉∗A,H(G), N, 〈M〉∗A)) (C2)durch Ax19, Nec, P2, Ax1, MP

Damit kann die Nachricht zum aktuellen Lauf zugeordnet werden.

A believes B says GC(〈X〉∗A,H(G), N, 〈M〉∗A) (C3)durch Ax21, Nec, C1, C2, Ax1, MP

Zur Ableitung der Aussage in primärer Darstellung wird die Rückgewinnung von p durchgeführt.

A believes B says (〈p〉∗A) (C4)durch GC1, Nec, C3, P7, Ax1, MP


Dem Bestätiger kann die Kompetenz für die Aussage p zugeordnet werden.


Die relevante Teilaussage ist ebenfalls eine aktuelle Äußerung des Bestätigers.

A believes B says 〈p〉∗A (C6)durch Ax17, Nec, C4, Ax1, MP

Damit kann die Aussage durch den Akzeptor übernommen werden.


5.3.3 Sekundärdaten mit Primärsignatur (s-p)

Bei diesem Szenario wird durch den Bestätiger der Primärtext signiert, jedoch lediglich die Si-gnaturdaten und die mit dem Primärtext korrespondierenden Sekundärdaten übertragen. Zur Si-gnaturprüfung muss der Empfänger zunächst die Nachricht aus den strukturierten Daten und derGrammatik zurückgewinnen.

Der SVO-Term für signierte Daten bXcK stellt eine komplette signierte Nachricht (Daten undSignatur) dar [SO96]. Um eine getrennte Übertragung von Nachricht und Signatur zu modellie-ren wird daher eine alternative Darstellung notwendig. Im Folgenden werden nur Nachrichtenbetrachtet, die Signaturen auf Basis von asymmetrisch verschlüsselten Hashwerten verwenden.Damit lässt sich die SVO-Schreibweise für signierte Nachrichten entsprechend schreiben.

bXcK−1 =def (X, {H(X)}K−1) (5.6)

Zur Beschreibung des Falles s-p verwendeten Prämissen sind:

A believes PKσ(B,KB) (P1)A believes fresh(N) (P2)A believes B controls L (G) (P3)A received (X,H(G), {H(p)}K−1

B) (P4)

A has G (P5)A believes A received (〈X〉∗A,H(G), {〈H(p)〉∗A}K−1

B) (P6)

A believes SV({H(〈p〉∗A)}K−1B, KB, 〈p〉∗A) (P7)

A believes GCV(〈X〉∗A, G, 〈p〉∗A) (P8)


Zusätzlich wird wie beim p-p-Verfahren als (P9) angenommen, dass die Zusicherung p denNonce-Wert enthält, also p = F (p′, N) ist.

In Prämisse P7 wird der in (5.6) gezeigte Zusammenhang berücksichtigt. Mit dem PrüfschlüsselKB kann die kryptographische Verknüpfung zwischen dem mit K−1B signierten Hashwert unddem Primärtext p nachgewiesen werden.

Zur Auswertung der empfangenen Nachricht wird durch A im Gegensatz zu den anderen Fällenzunächst der Primärtext zurückgewonnen, ehe die Authentizität der signierten Daten abgeleitetwird.

A has 〈X〉∗A (C1)durch Ax9, Nec, Ax12, Ax1, MP

Mit dieser Information kann A den Primärtext unter Nutzung der Funktion F = Φ−1G (X) zurück-gewinnen.

A has Φ−1G (〈X〉∗A) = A has 〈p〉∗A (C2)durch Ax14, Nec, Ax1, MP

Gleichheit durch (4.2)

Extrahiere einen Teil der empfangenen Nachricht.

A believes A received {〈H(p)〉∗A}K−1B

(C3)

durch Ax9, Nec, P6, Ax1, MP

Da A nach (C2) den Primärtext kennt, kann A den in der Signatur enthaltenen Wert 〈H(p)〉∗A alsHashwert von p erkennen.

A has H(〈p〉∗A) (C4)durch Ax14, Nec, C2, Ax1, MP

Damit kann (C3) wie folgt geschrieben werden:

A believes A received {H(〈p〉∗A)}K−1B

(C5)

durch C3, C4

Es erfolgt die Auswertung der Signatur.

A believes B said 〈p〉∗A (C6)durch Ax6, Nec, C5, P1, P7, Ax1, MP


Wie bei der reinen Primärtext-Signatur kann über den eingebetteten Nonce-Wert auf die Frischeder Nachricht geschlossen werden.

A believes fresh(〈F (p′, N)〉∗A) (C7’)durch Ax19,P2,Ax1,MP

A believes fresh(〈p〉∗A) (C7)durch P9

Es erfolgt die Zuordnung der Nachricht zur aktuellen Zusicherungsanfrage.

A believes B says (〈p〉∗A) (C8)durch Ax21, Nec, C7, C6, Ax1, MP

Die Berechtigung zur Zusicherung des Primärtextes wird abgeleitet.


Die Aussage kann durch A übernommen werden.


5.3.4 Diskussion der Aussagekraft

Durch die starke Kopplung zwischen den Darstellungsformen ist es möglich, in allen untersuch-ten Verfahren (p-p, s-s, s-p) die Aussage in die Überzeugungen des Akzeptors zu übernehmen.

Während der Fall p-p trivial ist, da die Auswertung des Wortproblems mittels (GC2) lediglichzur Feststellung der Autorisierung von B benötigt wird, sind in den beiden anderen Verfahren zu-sätzliche Verfahrensschritte notwendig, die über den Anwendungsfall normaler Authentisierungvon Daten hinausgehen.

In allen drei Verfahren wird (GC2) angewendet, um den Schluss von der Berechtigung hinsicht-lich der Grammatik auf die einzelne Aussage zu ermöglichen.

Wie beim Verfahren p-p kommt das Verfahren s-p ohne das spezielle Axiom (GC1) aus, da dieAnwendung der Rückgewinnung ausschließlich zur Verfügbarmachung des Primärtextes dient.Liegt der Primärtext vor, so kann wiederum das Verfahren wie bei p-p angewendet werden. Damitnimmt die Kodierung der Aussage p in Form strukturierter Daten X die Rolle einer speziellenÜbertragungskodierung ein und ist für die Sicherheitsbewertung vollständig transparent.

Der Hauptanwendungsfall der grammatikbasierten Zertifikate (s-s) nutzt hingegen das neue Axi-om (GC1), um aus der Signatur der strukturierten Daten die Authentizität des Primärtextes ab-zuleiten.

5.4 Grammatikverteildienst 125

Die dargestellten Schritte der Ableitung bilden auch eine Vorgabe für die durchzuführenden Prü-fungen und Umformungen innerhalb von Implementierungen. Für jedes Verfahren kann darausabgelesen werden, welche Daten oder Prüfergebnisse vorliegen müssen. So wird z. B. die Prü-fung der Sprachzugehörigkeit von p als Prämisse zu GCV(X,G, P ) bereits impliziert. Um diesePrämisse jedoch aufstellen zu können, muss der Anwender im Besitz der Grammatik sein unddie Rückgewinnung durchgeführt haben. Die Voraussetzungen zur Aufstellung der Prämissen zurKompetenz (B controls . . .) bzw. deren Ableitung werden bei der Betrachtung der Delegation inKapitel 5.5.5 betrachtet.

5.4 Grammatikverteildienst

Der in Kapitel 4.8 vorgestellte Grammatikverteildienst wurde als Webdienst implementiert. Basisder Implementierung ist eine MySQL-Datenbank, die die Grammatikdaten und die Autorisierun-gen speichert. Dazu wurde ein prototypischer Webdienst entwickelt, der Anfragen von Browsernbzw. Kommandozeilen-Werkzeugen verarbeitet.

5.4.1 Algorithmen

Als Sicherheitsmechanismen werden exemplarisch eingesetzt:

q X.509-Zertifikate mit 2048 Bit RSA-Schlüsseln und SHA256-RSA-Verschlüsselung alsSignatur

q AES-256-Verschlüsselung für Grammatiken auf Basis von GPG.

q SHA256-Hashwerte für Grammatiken

q 15-stellige Nonce- und Token-Werte

Bei den Zertifikaten können auch andere Schlüssellängen und Hashverfahren eingesetzt werden.Bei den Verschlüsselungsalgorithmen können ebenfalls andere Algorithmen und Kodierungs-verfahren gewählt werden. Es bietet sich dabei jedoch an, Werkzeuge einzusetzen, die mit demChiffrat auch den verwendeten Algorithmus ablegen (GPG, s/mime, u.a.), da diese Informationennicht gesondert im Grammatikserver gespeichert werden.

5.4.2 Protokollablauf und Prüfschritte

Die Kommunikation zwischen Client-Programm und Dienst erfolgt dabei über HTTP-Post-Nach-richten. Die notwendigen Signaturen über die Konkatenation der zu signierenden Werte werdenvor der URL-Kodierung durchgeführt und als zusätzlicher signature-Parameter übermittelt.

Im Folgenden werden die in den verschiedenen Funktionsbausteinen des Dienstes realisiertenSicherheitsoperationen im Rahmen von Sequenzdiagrammen dargestellt.


Ersteller GServer Datenbank

reqT

addHG

reqT autorisiertP1: Prüfe, ob für

P5: Prüfe auf und

P6: Prüfe Signatur mit

P3: ?

P4:Sig ?

Abbildung 5.6: Token-Anforderung und Einstellen einer verschlüsselten Grammatik

Abbildung 5.6 zeigt die Beantragung eines Tokens durchE. Die durchgeführten Prüfschritte sindmit Px gekennzeichnet. In Prüfschritt P1 wird das Vorliegen der Autorisierung für K̂E geprüft.Ist K̂E berechtigt, so liegen im Server auch der öffentliche Schlüssel KE und die Informationvor, ob K̂E das Recht zur Delegation besitzt.

Der Server sendet die signierte Antwort respT zurück und speichert t1. Der Client prüft in P3 dieGleichheit des zurückgesendeten Nonce-Wertes r1 und in P4 die Signatur der Nachricht mit KG.

Der Einsteller der Grammatik verwendet das Token t1 für die signierte Nachricht addHG mitder unter S verschlüsselten Grammatik G. Auf Server-Seite wird in P5 geprüft, ob die korrekteKombination aus Token t1 und K̂E vorliegt. In P6 wird die Signatur des Einstellers mit KE

geprüft und im Erfolgsfall die verschlüsselte Grammatik und ihr Hashwert in die Datenbank mitZuordnung zu K̂E geschrieben. Der Server schickt die definierte Antwort respG an den Einsteller.

In Ergänzung zu den in Abschnitt 4.8 definierten Anforderungen wurde zusätzlich eine Zähl-funktion für ausgestellte Token integriert. Dieser Zähler kann beispielsweise zur Abrechnung


von erstellten Berechtigungen dienen oder die Einhaltung von vorgegebenen Kontingenten er-zwingen.

Ersteller Delegierter GServer

reqT

Speicherung von

delGP5': Prüfe auf und

P6': Prüfe Signatur mit

P3: ?

P4:Sig ?

Eigentümer zu H(G)P7: Prüfe, ob

zu H(G)Lösche Grammatik


delegationsberechtigtP2: Prüfe, ob

Abbildung 5.7: Löschen einer Grammatik mit Delegation

Abbildung 5.7 zeigt die Anforderung eines Token zur Weitergabe an einen Dritten, der bereitszuvor eine Grammatik eingestellt hat und diese löschen möchte.

Die reqT-Nachricht ist um den optionalen Schlüssel KD des Dritten (z. B. kodiert durch einZertifikat) erweitert. Die Prüfung auf Server-Seite wird um P2 ergänzt (Delegationsberechtigungfür K̂E).

Nach Erhalt des Tokens wird dieser vom Ersteller an den Delegierten weitergegeben, den dieserbei sich zur späteren Verwendung speichert. Der Delegierte sendet die Löschnachricht delG mitdem Token t1 und dem Hashwert der Grammatik an den Server. Dieser führt wie bei der Einstel-lung der Grammatiken die Prüfschritte P5 und P6 aus. Vor Ausführung der Löschung wird in P7noch geprüft, ob die Zuordnung des Datenbankeintrags von H(G) zu K̂D vorliegt. Abschließendantwortet der Server definitionsgemäß mit einer respG-Nachricht auf die Löschanfrage.


5.4.3 Sicherheitseigenschaften der Grammatikverteilung

Die formale Prüfung, ob der Dienst die Eigenschaften erfüllt, wird mit Hilfe einer Proverif-Modellierung durchgeführt. Dabei wurden Erkenntnisse aus einer ersten Analyse durch eine Er-weiterung des Protokolls in Kapitel 5.4.4 aufgegriffen und deren Wirksamkeit in einem zweitenLauf bestätigt.

Das vollständige Proverif-Modell des Grammatik-Servers einschließlich der genannten Ergän-zung ist in Anhang F enthalten.

5.4.3.1 Teilprozesse

Die Modellierung basiert dabei auf einer Reihe von Teilprozessen, die jeweils einen Teil derFunktionalität der Anwendungsfälle übernehmen. Diese Prozesse stellen den Grammatikserverund einen Client C sowie einen Delegationsberechtigten D dar. Dabei wurden bis auf den Abrufvon Grammatiken lediglich die Funktionen Einstellung (addHG) und Löschung (delG) model-liert, da sie schützenswerte Ressourcen betreffen. Diese Teilprozesse sind:

processG Prozess des Grammatikservers (GServer) für Beantragung von Token (reqT), Einstel-lung (addHG) und Löschung (delG) von Grammatiken.

processGreqG Prozess des Grammatikservers, der auf Abruf einer Grammatik unter Angabedes Hashwertes antwortet

processCreqT Client, der für sich selbst Token beantragt

processDreq Delegationsberechtigter, der für Dritte Token beantragt

processCaddHG Einsteller-Prozess für verschlüsselte Grammatiken

processCreqG Client-seitiger Prozess zum Abruf einer Grammatik über Hashwert

processCdelG Client-seitiger Prozess zur Löschung von Grammatiken

Die Kommunikation zwischen C, D und GServer erfolgt dabei ausschließlich über den öffentli-chen Kanal net, und kann somit vollständig vom Angreifer kontrolliert werden.

5.4.3.2 Ereignisse

Zur Überprüfung der Sicherheitseigenschaften ist es zunächst notwendig, Ereignisse im Ablaufder Protokollbearbeitung zu definieren, die im Rahmen von sog. queries in Beziehung gesetztwerden, um (ggf. injektive) kausale Zusammenhänge innerhalb des Ablaufs nachweisen zu kön-nen.


Vor Instantiierung der unter Replikation stehenden oben vorgestellten Teilprozesse werden zu-nächst Schlüsselpaare für alle Beteiligten einschließlich des Angreifers erzeugt.

Je nach untersuchter Variante werden die Schlüssel in die Autorisierungstabelle aufgenommenund mit den Rechten zur Token-Beantragung und/oder Delegation versehen. Für jede berechtigteSchlüsselreferenz wird ein Ereignis authKeyid mit der Referenz als Parameter erzeugt.

Bei der Token-Beantragung wird vor Aussendung des Request auf der Seite des Anfragenden einEreignis reqToken bzw. reqDelegToken erzeugt, das mit dem Zufallswert r1 und der Schlüsselre-ferenz des Berechtigten parametrisiert ist.

Sobald der Server ein Token ausgestellt hat, ist dies durch das Ereignis genToken mit den Pa-rametern r1, Schlüsselreferenz des Berechtigten und Schlüsselreferenz des Anfragenden doku-mentiert.

Die Anfragen zur Einstellung und Löschung von Grammatiken erzeugen vor Aussendung aufClient-Seite die Ereignisse insertRequest bzw. deleteRequest, denen auf Server-Seite die Ereig-nisse grammarInsert bzw. grammarDelete gegenüber stehen.

5.4.3.3 Eigenschaftsprüfungen

Die im vorausgehenden Abschnitt definierten Ereignisse können in Form von Abfragen zur Prü-fung von Eigenschaften eingesetzt werden.

Zunächst wird für jedes Ereignis geprüft, ob es überhaupt im Rahmen des Protokolllaufs erreichtwerden kann. Danach werden die folgenden Prüfungen durchgeführt.

Der Einstellung der (verschlüsselten) Grammatik G muss eine Autorisierung des Einstellers K̂1

vorausgehen. Dies kann entweder direkt durch Aufnahme in die Autorisierungstabelle mit demRecht zur Beantragung von Token geschehen oder durch die dedizierte Beantragung eines Tokendurch einen Delegationsberechtigten K̂2 unter Angabe der Schlüsselreferenz K̂1 des Einstellersals Berechtigten erfolgen (injektive Beziehung). Mit den eingeführten Ereignissen ausgedrückt,lautet dies:

[inj ] grammarInsert(G, K̂1) ; authKeyid(K̂1) ∨([inj ] genToken(r, K̂1, K̂2) ∧ authKeyidDeleg(K̂2))

(GS-P1)

Eine Grammatik G soll nur dann durch einen Client K̂1 gelöscht werden können, wenn dieserdie Grammatik auch zuvor eingestellt hat. Dabei soll auf jeden Löschvorgang genau ein Einstell-vorgang kommen (injektive Beziehung):

[inj ] grammarDelete(G, K̂1) ; [inj ] grammarInsert(G, K̂1) (GS-P2)


Ein angenommener Löschauftrag muss in Analogie zur Einstellung von einem vertrauenswürdi-gen, d. h. autorisierten Client kommen.

[inj ] grammarDelete(G, K̂1) ; authKeyidReq(K̂1) ∨([inj ] genToken(r, K̂1, K̂2) ∧ authKeyidDeleg(K̂2))

(GS-P3)

Jedes Senden eines Einstell- oder Löschauftrages zu einer Grammatik mit Hashwert H darf nurgenau einmal pro Anfrage des Clients K̂ durch den Server ausgeführt werden.

[inj ] grammarInsert(H, K̂) ; [inj ] insertRequest(H, K̂) (GS-P4)

[inj ] grammarDelete(H, K̂) ; [inj ] deleteRequest(H, K̂) (GS-P5)

Mit diesen Prüfungen sind die geforderten Eigenschaften aus Kapitel 4.8.3 abgedeckt.

Durch die Einführung eines Zählers in der Implementierung zur Umsetzung von Abrechnungs-mechanismen kommt eine weitere Anforderung hinzu: Jede Anforderung eines Token mit Nonce-Wert r1 durch einen autorisierten Client K̂1 für eine zu berechtigenden Schlüsselreferenz K̂ darfnur zu genau einer Ausstellung eines Token führen, da andererseits ein Angreifer durch Wieder-einspielen von Requests dem Berechtigten Schaden zufügen kann. Diese Forderung wird formu-liert als:

[inj ] genToken(r, K̂, K̂1) ; [inj ] reqToken(r, K̂) ∨ [inj ] reqDelegToken(r, K̂)(GS-P6)

5.4.4 Analyse und Erweiterung

Die im vorigen Abschnitt vorgestellten Prüfungen wurden durch entsprechende Ereignisse undAbfragen in der Proverif-Modellierung des Dienstes (vgl. Anhang F) berücksichtigt.

Die Analyse wurde in vier Szenarien S1 bis S4 durchgeführt. In der ersten Stufe S1 wurde nurder Client-Prozess berechtigt, den Dienst zu nutzen, jedoch kein Delegationsrecht vergeben. Inder zweiten Stufe wurde dem Client das direkte Nutzungsrecht entzogen und dem Delegations-prozess die erweiterte Autorisierung mit Delegationsrecht gegeben.

In den Szenarien 3 und 4 erhält der Angreifer einen für die Dienstnutzung bzw. die Delegationautorisierten Schlüssel.


5.4.4.1 Erster Analyselauf

Im ersten Analyselauf zeigte sich ein Problem des Dienstentwurfs. Da bei der Definition derEigenschaften in Kapitel 4.8.3 die durch die Implementierung hinzugekommene Forderung nachkontrollierter Ausstellung von Token (GS-P6) nicht berücksichtigt wurde, war das Prüfziel (GS-P6) nicht erfüllbar. Allerdings war es möglich, die Eigenschaft

genToken(r, K̂, K̂1) ; reqToken(r, K̂) ∨ reqDelegToken(r, K̂) (GS-P6’)

nachzuweisen. Im Unterschied zu (GS-P6) ist die Korrespondenz nicht injektiv. Das bedeutet,dass zwar zur Auslösung der Token-Generierung die Anforderung durch einen Berechtigten er-folgt sein muss, jedoch kann es sich bei der empfangenen reqT-Nachricht um eine Wiederein-spielung handeln. Das Proverif-Werkzeug liefert einen entsprechenden Trace, der diese Vorge-hensweise demonstriert.

5.4.4.2 Ergänzung des Protokolls

Zur Beseitigung der Schwachstelle wurde den bereits entworfenen Protokollschritten noch einzusätzlicher Nachrichtenaustausch vorangestellt. Hierbei initialisiert der Client eine Token-Aus-stellung mit einer initReqT-Nachricht, die der Server mit einer initRespT-Nachricht beantwortet.In dieser Antwort erhält der Client einen Zufallswert r0, den er in seine reqT-Anfrage aufnehmenmuss.

Damit ergibt sich die angepasste Version des Protokolls zur Anforderung eines Tokens gemäßAbbildung 5.8. Durch die Einführung von r0 sind alle durch K−1E signierten Anfragen individua-lisiert und damit für den Server unterscheidbar bzw. dem aktuellen Protokolllauf zuzuordnen.

5.4.4.3 Analyse der erweiterten Protokollversion

Die Ergebnisse der Proverif-Analyse sind in Tabelle 5.2 dargestellt.

Die Analyse zeigt, dass die Prüfungen GS-P1, GS-P2 und GS-P3 für alle Szenarien S1 bis S4erfüllt sind. Damit sind alle Veränderungen in der Datenbank nur durch autorisierte Anwendermöglich. Die Mandanten-Trennung (Löschen von Grammatiken nur durch den Einsteller) istebenfalls in allen Fällen wirksam.

Für die Fälle S1 und S2 konnte darüber hinaus gezeigt werden, dass, sofern kein Angreifer zurDienstnutzung autorisiert ist, für die Aktionen „Ausstellung eines Tokens“ sowie „Einstellen undLöschen von Grammatiken“ jeweils eine entsprechende Request-Erstellung durch einen vertrau-enswürdigen Beteiligten vorausgeht.

Für die Fälle S3 und S4 ist dieser Nachweis nicht möglich, da in diesem Fall der Angreifer dieRequests erzeugt und somit die Ziele per se nicht erfüllt sein können. Die negativen Tests sinddaher nicht als Einschränkung des Dienstes zu werten. Somit erfüllt der hier spezifizierte undmodellierte Dienst alle an ihn gestellten Anforderungen.


Ersteller GServer Datenbank

reqT

P3: ?

P4:Sig ?


P0: ?

Abbildung 5.8: erweiterte Token-Anforderung

5.5 Beschränkung und Delegation

Nachdem die Realisierung der grammatikbasierten Zertifikate und des Grammatikverteildienstesvorgestellt und die Verfahren einer formalen Bewertung unterzogen wurden, sollen in diesemAbschnitt noch die Delegationsmechanismen sowie die Anwendung von Beschränkungen beider Anforderung von Zusicherungen, der Berechtigung von Bestätigern und der Auswertung vongrammatikbasierten Zertifikaten betrachtet werden.

Hierzu wird zunächst die Abbildung der verschiedenen Beschränkungsarten auf GC-Einschrän-kungen vorgestellt, wie sie für das Anwendungsfeld der Sicherheitsauditierungen vorgenommenwerden kann. Im Anschluss wird ein Mechanismus zur Verwendung von Modulen in Gramma-tiken und seine Anwendung bei Speicherung und Auswertung von Beschränkungen diskutiert.Abschließend wird eine formale Bewertung hinsichtlich der Ausdrucksstärke und Anwendbar-keit der Delegation durch Definition einer Semantik auf Basis der SVO-Logik gegeben.

5.5.1 Delegationszertifikat

In Abschnitt 4.7.3 wurde vorgeschlagen, die Delegationszusicherung in Form eines GC auf Basiseiner Grammatik GD zu kodieren. Im Rahmen der Implementierung wurde eine solche Gram-matik erstellt und in Anhang C.4 aufgenommen.

Anhand von Delegationszertifikaten auf Basis der Grammatik GD lässt sich nochmals die Ver-besserung der Verständlichkeit durch Rückgewinnung des Primärtextes belegen. Für eine Dele-gationsaussage zur BSI-Grundschutzmaßnahme 5.72 (vgl. Tabelle 4.1) für Max Mustermann mit

5.5 Beschränkung und Delegation 133

S1 S2 S3 S4 Erläuterung

Auth T F F F Autorisierung Anfragen CC

Deleg F F F F Autorisierung Delegation C

Auth F T F F Autorisierung Anfragen DD

Deleg F T F F Autorisierung Delegation D

Auth F F T T Autorisierung Anfragen AngreiferA

Deleg F F F T Autorisierung Delegation Angreifer

GS-P1 T T T T Grammatikeinstellung nur nach Autorisierung

GS-P2 T T T T Löschung einer Grammatik nur durch Inhaber

GS-P3 T T T T Löschung nur nach Autorisierung

GS-P4 T T F F nur eine Einstellung pro Einstellanfrage

GS-P5 T T F F nur eine Löschung pro Löschanfrage

GS-P6 T T F F nur eine Token-Erstellung pro Anfrage

Tabelle 5.2: Ergebnisse der Proverif-Analyse des Grammatikverteildienstes

einer Beschränkung des zu prüfenden Systems auf cntsrv1 und Festlegung der Prüfmethode aufPortscan ergibt sich folgender (in S-Expressions dargestellter) Syntaxbaum

(Satz (Berechtigter (CommonName "Max Mustermann")(EmailAddress "[email protected]")) (GrammatikName "BSI-M.5-72")(GrammatikReferenz (Algorithmus ’SHA256’)(Hashwert 0x05619a2d17bdf7be682269e3c09da133f258da9ba73e0970be14acf578cd0570)(Uri "http://security.example.com/grammars/m572.gcg")) (Weitergabe 3)(Beschraenkungen (Und (Pfad "//Methode/’Portscan’")(Pfad "//Server/’cntsrv1’"))))

Diese kompakte Information kann durch Rückgewinnung mit GD wie folgt dargestellt werden:

Hiermit wird an "Max Mustermann" ("[email protected]") das Rechtzur Erstellung von Aussagen gemäß der Grammatik "BSI-M.5-72" erteilt.

Die Grammatik hat den SHA256-Hashwert0x05619a2d17bdf7be682269e3c09da133f258da9ba73e0970be14acf578cd0570.

Die Grammatik kann unter der Adresse"http://security.example.com/grammars/m572.gcg"abgerufen werden.


Diese Berechtigung kann über maximal 3 nachfolgende Delegationsvorgängeweitergegeben werden.

Die auf Basis dieser Delegation gemachten Aussagen müssen folgendeBedingungen erfüllen:

und("//Methode/’Portscan’";"//Server/’cntsrv1’")

Bei der Festlegung dieses Formates wurden zur Angabe des Berechtigten lediglich der volle Na-me und die E-Mail-Adresse berücksichtigt. Diese Kombination reicht zur Identifikation für diemeisten, insbesondere Firmen-internen, Anwendungsfälle aus. Es ist dann jedoch notwendig,dass auch auf der Ebene der Issuer-Angaben im verwendeten GC-Zertifikat diese Informationenenthalten sind. Ergänzend können hier für geschlossene Anwendergruppen ggf. auch zusätzlichPersonalnummern o. ä. aufgenommen werden. Bei Anwendung in öffentlichen Bereichen ermög-licht eine Schlüsselkennung die eindeutige Identifizierung.

Die Länge der auf eine Delegation folgenden Zertifikatskette hängt vom gewählten Wert Weiter-gabe ab. Bei der Modellierung von Beispielen hat sich gezeigt, dass eine Maximallänge (aus-gehend von der initialen Berechtigung am ZAS) von wmax = 2 sinnvollerweise bei Sicherheits-auditierungen nicht überschritten werden sollte. In der Regel gibt es einen direkten Abstim-mungsbedarf zwischen den Auditoren und den Zusichernden, so dass viele Zwischenstufen inder Delegation entweder die Kommunikation erschweren oder überhaupt nicht relevant sind. Eintypisches Szenario ist der Kontakt zwischen Auditor und Teamleiter, der die zuständigen Mitar-beiter benennt und damit berechtigt. Maximal sollte jedoch nur noch eine weitere Führungsebeneeinbezogen werden.

5.5.2 Beschränkungsarten

Das bei Sicherheitsauditierungen in der Praxis häufig angewendete mehrstufige Konzept vonVorgaben bzw. Anforderungen kann durch die Beschränkungsmechanismen (Abschnitt 4.6) undDelegationszertifikate abgebildet werden.

Es werden im Rahmen einer Auditierung die Ebenen von Festlegungen betrachtet: zentrale Fest-legungen, Festlegung der Kompetenz und systemspezifische Festlegungen.

Die zentralen Festlegungen werden durch die Sicherheitsrichtlinie des Unternehmens (engl. se-curity policy) und auf das ganze Unternehmen anzuwendende Vorschriften wie z. B. Datensicher-heitsstandards der Herausgeber von Zahlungsverkehrskarten [PCI10] gebildet. Diese Richtlinienlegen grundsätzliche Anforderungen an Verfahren und Betriebsmodi von Systemen fest. Beispie-le hierzu sind vorgeschriebene Sicherheitsprüfungen für Personal, Passwort-Richtlinien (Länge,


Zeichenvorrat, Änderungsfrequenz), Härtungsvorgaben für Betriebssysteme oder Algorithmen-vorgaben für Verschlüsselungsmechanismen. Die daraus resultierenden Beschränkungen werdensollen als Policy-Beschränkung bezeichnet werden.

Die Festlegung der Kompetenz für die Beauftragten setzt die Verantwortungs- und Fähigkeitsbe-reiche der Zusichernden in Kompetenz-Beschränkungen um.

Da eine allgemein formulierte Grammatik sowie ein Prüfplan eine Menge konkreter Systeme ab-decken, müssen die durch den ZAS akzeptierten Zusicherungen auf die tatsächlich durch einenMitarbeiter betreuten Systeme eingeschränkt werden können. Ebenfalls ist es an dieser Stellesinnvoll, mögliche Aussageformen entsprechend der Fähigkeiten des Mitarbeiters einzuschrän-ken. Sieht eine Zusicherungsklasse verschiedene Verfahren oder Werkzeuge zur Erhebung derangeforderten Informationen zu, so kann es z. B. sinnvoll sein, die Zusicherung auf die Verfah-ren einzugrenzen, für die der Mitarbeiter bereits geschult wurde.

Um eine Eingrenzung der Systeme vornehmen zu können, müssen Zusicherungen Identifika-tionsdaten für ein System enthalten. Beispiele hierfür sind der logische Systemname oder Se-riennummern von Geräten. Werden Zusicherungen zu Personen wie z. B. Schulungsnachweisebenötigt, kommen Kennungen wie bei den Delegationszertifikaten zum Einsatz.

Mit systemspezifischen Beschränkungen können zusätzliche Festlegungen für einzelne zu unter-suchende Systeme getroffen werden. Diese kommen z. B. bei Systemen mit erhöhtem Schutzbe-darf zum Einsatz, bei denen die Festlegungen der allgemein gültigen Sicherheitsrichtlinie nichtausreichen.

5.5.3 Skalierung durch Module

Sollen übergreifende Sicherheitsrichtlinien auf unterschiedliche Untersuchungsfelder anwendbarsein, so sollte soweit möglich eine einheitliche Darstellung für die zu beschränkenden Teile einerZusicherung eingesetzt werden.

Zu diesem Zweck wurde ein Mechanismus entworfen, der die Aufnahme vorgefertigter Baustei-ne in zu erstellende anwendungsspezifische Grammatiken ermöglicht, ohne die Eigenschaftendes vorgestellten Ansatzes wesentlich zu verändern. Lediglich eine Einschränkung der Benen-nung von Nicht-Terminalen ist zu beachten.

Jeder Baustein hat dabei folgende Eigenschaften

q Jeder Baustein besteht aus Produktionsregeln, die – unter Hinzunahme der standardmäßigdefinierten Lexeme – eine abgeschlossene Sprache bilden, d. h. für jedes Nicht-Terminalauf der rechten Seite einer Regel existiert eine Produktionsregel.

q Alle Nicht-Terminale erhalten einen Baustein-spezifischen Prefix, der für alle frei erstelltenGrammatiken als reserviert gilt.

q Das Startsymbol mit Baustein-spezifischen Prefix ist bekannt.


Ein Baustein ist somit eine eigene Grammatik GB =< NB, TB,PB, SB >. Die Aufnahme einessolchen Bausteins erfolgt durch einen Include-Befehl innerhalb der aufnehmenden Grammatik.Dabei wird die aufzunehmende Grammatik durch ihren Hashwert sowie eine Quellenangabereferenziert.

Wird GB in eine Grammatik G′ aufgenommen, so ergibt sich daraus eine resultierende Gramma-tik G durch Vereinigung der korrespondierenden Mengen.

P = P ′ ∪ PBN = N ′ ∪NB mit N ′ ∩NB = ∅T = T ′ ∪ TBS = S ′

Die Produktionsregeln P müssen dann so umgeformt werden, dass mindestens eine Regel aufihrer rechten Seite SB enthält, damit die Einbindung der Grammatik GB wirksam wird.

Ein Beispiel für einen solchen Baustein mit dem Prefix Gm012 und dem Startsymbol Gm012_-Server ist eine Grammatik zur Benennung eines untersuchten Serversystems die u. a. den folgen-den Text erfolgreich validiert:

Für den virtuellen Server "vlsrv01" im Hostsystem "vhost17"mit Betriebssystem "RedHat", Version "5.9",wird folgende Zusicherung gegeben:

Dieser Baustein kann beispielsweise in die Bestätigung der Maßnahme M 5.72 (vgl. Tabelle 4.1)in die erste Regel aufgenommen werden:

Mn5_72→ Gm012_Server ’Auf dem Server wurden alle nichtbenötigten Dienste abgeschaltet.\n’ Pruefung? ’Dieaktiven Dienste sind:\n’ Dienste?

Durch die Prefixnotation können nun einheitliche XPath-Ausdrücke für alle Zusicherungen ver-wendet werden, die diesen Baustein eingebunden haben. So erfüllt jede Zusicherung, die sichauf einen virtuellen Server bezieht, den Prüfausdruck

//Gm012_Typ/’virtuell’

Bei mehrfacher Einbindung des Bausteins kann es notwendig sein, durch eine Erweiterung desXPath-Ausdrucks die gewünschte Stelle der Verwendung zu präzisieren.

5.5.4 Speicherung und Prüfung von Beschränkungen

Grundlage für alle Auditierungsaktivitäten bildet das in Abschnitt 1.2.3 beschriebene allgemeinePrüfverfahren, bei dem nach einer Erhebung der Gegebenheiten der Infrastruktur ein Prüfplanerstellt wird. Der Prüfplan legt die zu untersuchenden Systeme und Prozesse sowie die dabei zu


betrachtenden Fragestellungen fest. Diese Anforderungen sowie die Policy- und systemspezifi-schen Beschränkungen müssen auf dem Server hinterlegt und bei Eingang von Zusicherungenim zentralen Auditierungsserver geprüft werden.

Hierzu wird eine Zuordnung aus Selektionskriterien und XPath-Prüfausdrücken verwendet. AlsSelektionskriterium kann der Hashwert einer Grammatik, ein XPath-Ausdruck oder die Kombi-nation aus beiden verwendet werden.

Wird nur ein Grammatik-Hashwert verwendet, so wird der Prüfausdruck auf jede Zusicherungunter dieser Grammatik angewendet. Dies wird bei Policy-Beschränkungen angewendet, die di-rekt einer Grammatik (z. B. Auditierung der Authentisierungsmodule von Servern) zugeordnetwerden.

Die Verwendung eines XPath-Ausdrucks als Selektor kann bei Policy-Beschränkungen genutztwerden, die bezüglich eines Grammatikbausteins aufgestellt werden. Hierbei wird das Startsym-bol des Bausteins als Selektionskriterium verwendet. Auf diese Weise wird automatisch jedeGrammatik durch die Beschränkung abgedeckt, die den entsprechenden Baustein einbindet.

Die Verwendung der Kombination aus Grammatik-Hashwert und XPath-Ausdrucks kann für dieFestlegung von Anforderungen und systemspezifischen Beschränkungen genutzt werden. DerXPath-Ausdruck bestimmt dabei ein konkretes System. Dabei wird eine Grammatik zur Iden-tifikation von Systemen referenziert und durch den XPath-Ausdruck mit der Identität des ge-wünschten Systems parametrisiert.

Die Kompetenzen der Bestätiger werden nicht initial in der Datenbank des ZAS gespeichert.Sie werden durch die Delegationszertifikate kodiert, die im Verlauf des Ausrollens von Rechtenan den ZAS übermittelt werden. Lediglich die Anfänge der Delegationsketten werden zentralhinterlegt, d. h. welche Grammatiken durch wen mit welchen Beschränkungen delegiert werdendürfen. Hierzu werden weitere Details im nächsten Kapitel betrachtet. Der ZAS nimmt auchu. U. notwendige Rückrufe einer Delegation vom jeweiligen Ersteller entgegen, so dass er dieFunktion des Statusauskunftsdienstes implizit erfüllt.

Sind alle Anforderungen und Beschränkungen hinterlegt, so wird ein Auditauftrag erteilt, in des-sen Rahmen die Mitarbeiter die Prüfpläne erhalten. In diesem Zusammenhang kann auch dieAnfragenummer verteilt werden, die in die Zusicherung zur Etablierung der Frische aufgenom-men wird.

Die Erhebung des Ist-Zustandes erfolgt durch die Bestätiger in der herkömmlichen Weise mitbeliebigen manuellen oder automatisierten Verfahren. Die Bestätiger dokumentieren die Ergeb-nisse in Form von grammatikbasierten Zertifikaten, die an den ZAS gesendet werden.

Bei Erhalt einer Zusicherung prüft der ZAS zunächst (neben der eigentliche Zertifikatsprüfung),ob die Policy- und systemspezifischen Beschränkungen sowie die aus der Delegationskette vor-liegenden Beschränkungen eingehalten werden. Ist dies der Fall, so wird ermittelt, auf welcheAnforderungen die Zusicherung passt und diese kann dann als erfüllt markiert werden.


5.5.5 Formale Beschreibung der Delegation

Wie bereits die Zusicherungen für die Auditierungen soll auch für Delegationszertifikate eineformale Beschreibung zur Festlegung einer Semantik und zum Nachweis der Funktionsfähigkeitangegeben werden.

Analog zu den grammatikbasierten Zertifikaten wird für die DelegationszertifikateD die Schreib-weise

D = bGDC(B,H(G), R, w,M))cK−1A

eingeführt. Hierbei steht B für den zu Berechtigenden, H(G) ist der Hashwert der Grammatikfür die Basisberechtigung, R ist die anzuwendende Beschränkung, w der Indikator für das Rechtzur Weiterdelegation über eine bestimmte Zahl von Stufen (Ganzzahl, w ≥ 0) undM enthält dieweiteren Meta-Daten, die bei Bedarf herausgezogen werden können. Für R kann ⊥ geschriebenwerden, wenn keine Einschränkungen vorliegen.

Die Basisberechtigung ist nach Abschnitt 4.7.2 durch L (G) gegeben. Beschränkungen Rν wer-den aus der Menge X der zulässigen XPath-Ausdrücke und den Operatoren and(., .), or(., .) undnot(.) gebildet.

Da Delegationszertifikate oftmals keinen Nonce-Wert enthalten, da sie i. d. R. lange Gültigkeits-dauern haben und nicht explizit angefragt werden, wird für Delegationszertifikate angenommen,dass für sie die Zusicherung der Aktualität durch einen Statusauskunftsdienst übernommen wirdund diese Auskunft durch das current-Prädikat ausgedrückt.

Um die Berechtigung zur Delegation der Kompetenz zur Erstellung von Zusicherungen formal zufassen, wird die provides-Beziehung zwischen einem Prinzipal und einer Menge von Aussagensowie der Anzahl n erlaubter weiterer Delegationsschritte eingeführt.

Q provides (L (G, r0), n) mit n ≥ 0 (5.7)

Wie zuvor kann r0 = ⊥ sein, so dass L (G, r0) = L (G) ist.

Die Wahrheitsbedingungen lauten damit mit den Ganzzahlen n > 0 und w ≥ 0

(r, t) � Q provides (L (G, r0), n)

g.d.w. die Aussage(r, t) � Q says GDC(P,H(G), r1, w,M)

für alle 0 ≤ w < n die Aussagen(r, t′) � P controls L (G, and(r0, r1)) für alle t′ ≥ 0

und(r, t′) � P provides (L (G, and(r0, r1)), w) für alle t′ ≥ 0

impliziert.


Zur vollständigen Abdeckung des Wertebereichs wird außerdem festgelegt, dass für n = 0 gilt:

� P provides (L (G, r0), 0)

L (G, r0) bildet die maximale Aussagenmenge, die Q delegieren kann. Bei der Delegation kanneine zusätzliche Einschränkung r1 angegeben werden, die jedoch auch auf r1 = ⊥ gesetzt werdenkann, so dass die volle Aussagenmenge weiter delegiert wird.

Da die SVO-Logik keine Vergleichsoperatoren für Ganzzahlen enthält, wird hierzu ein neuesPrädikat GT (für greater than) bereit gestellt:

GT(n,m)⇔ n > m

Mit diesen Mitteln kann die Interpretation für Delegationszertifikate durch eine SVO-Regel de-finiert werden.

(Q says GDC(P,H(G), r1, w,M) ∧ Q provides (L (G, r0), n) ∧ GT(n,w))→(P controls L (G, and(r0, r1)) ∧ P provides (L (G, and(r0, r1)), w)) (GC3)

Die Korrektheit der Implikation ist für n > 0 wieder unmittelbar aus den Wahrheitsbedingungenersichtlich. Für n = 0 ist GT(n,w) für alle w falsch und damit die Implikation ebenfalls wahrund damit korrekt.

5.5.6 Prüfablauf

Mit den Ableitungsschritten des vorangegangenen Abschnitts kann die Auswertung einer Dele-gationskette durchgeführt werden. Als Beispiel wird eine Kette vom Sicherheitsmanagement S,über einen Abteilungsleiter A, einen Teamleiter T bis zu einem Mitarbeiter M gebildet. Ausge-hend von S wirdAmit dem provides-Recht für zwei Stufen ausgestattet. Dies wird in der lokalenDatenbank abgelegt und daher als Prämisse modelliert.

Die weiteren Bestätigungen durch A und T werden in Form eines GDC an S übermittelt, da Sals Initiator der Delegationskette am Ende die Zusicherungen von M erhält. Für die GDC undeine Zusicherung Z von M werden dabei folgende Kurzschreibweisen definiert:

GDCT = GDC(T,H(G), r1, 1,M)

GDCM = GDC(M,H(G), r2, 0,M)

Z = GC(X,H(G), N,M)

Die Prämissen sind

Kenntnis der öffentlichen Schlüssel


S believes PKσ(A,KA) (P1)S believes PKσ(T,KT ) (P2)S believes PKσ(M,KM) (P3)

Zweistufiges Delegationsrecht für AS believes A provides (L (G, r0), 2) (P4)

DelegationsnachweiseS believes S received bGDCT cK−1

A(P5)

S believes S received bGDCMcK−1T

(P6)

Gültige Signaturen der GDCS believes SV(bGDCT cK−1

A, KA,GDCT ) (P7)

S believes SV(bGDCMcK−1T, KT ,GDCM) (P8)

GDC sind aktuellS believes current(A,GDCT ) (P9)S believes current(T,GDCM) (P10)

Gültig signierte Zusicherung von MS believes S received bZcK−1

M(P11)

S believes SV(bZcK−1M, KM , Z) (P12)

Korrekte Sprach- und BerechtigungsprüfungS believes GCV(X,G, p) (P13)S believes GCR(X, and(and(r0, r1), r2)) (P14)S believes fresh(N) (P15)

Prüfung der Signaturen und Zuordnung der Nachrichten zu den Sendern

S believes A said GDCT (C1)durch Ax6, Nec, P1, P5, P7, Ax1, MP

S believes T said GDCM (C2)durch Ax6, Nec, P2, P6, P8, Ax1, MP

S believes M said Z (C3)durch Ax6, Nec, P3, P11, P12, Ax1, MP

Durch die Nachweise der Aktualität von einem Statusauskunftsdienst können die Delegations-


nachweise als aktuelle Äußerungen betrachtet werden:

S believes A says GDCT (C4)durch Ax23, Nec, C1, P9, Ax1, MP

S believes T says GDCM (C5)durch Ax23, Nec, C2, P10, Ax1, MP

Aus der Delegationsaussage GDCT kann die Berechtigung von T und daraus die Berechtigungvon M abgeleitet werden:

S believes T provides (L (G, and(r0, r1)), 1) (C6)durch GC3, Nec, C4, P4, GT(2, 1), Ax1, MP

S believes M controls L (G, and(and(r0, r1), r2)) (C7)durch GC3, Nec, C5, C6, GT(1, 0), Ax1, MP

Durch Nachweis der Frische der Zusicherung gilt diese ebenfalls als aktuell geäußert:

S believes fresh(Z) (C9)durch Ax19, Nec, P15, Ax1, MP

S believes M says Z (C10)durch Ax21, Nec, C9, C3, Ax1, MP

Die Kompetenz für p folgt aus der Prüfung der Grammatik und der Restriktionen.

S believes M controls p (C11)durch GC2, Nec, C7, P13, P14, Ax1, MP

Die zurückgewonnene Aussage wird M zugeordnet.

S believes M says p (C12)durch GC1, Nec, C10, P13, Ax1, MP

Mittels der M zugewiesenen Kompetenz kann die Aussage übernommen werden:

S believes pdurch Ax18, Nec, C11, C12, Ax1, MP

Damit wurde gezeigt, dass die Übernahme der notwendigen Überzeugungen auf Basis der auf-gestellten Prämissen möglich ist. Aus den Schritten dieses Nachweises können direkt die Funkti-onsbausteine und deren Anwendungsreihenfolge für eine Implementierung des Delegationsme-chanismus abgelesen werden.


5.5.7 Eigenschaften der Delegation

Die Implementierung und formale Analyse haben die Eigenschaften der spezifizierten und reali-sierten Delegationsmechanismen verdeutlicht.

Es ist mit dem gewählten Ansatz sowohl möglich, die Rechte zur Abgabe einer Aussage sehrfeingranular einzuschränken als auch dieses Recht an weitere Beteiligte weiterzugeben.

Besonderes Augenmerk verdient dabei die Eigenschaft, dass die Weitergabe von Aussagerech-ten in ihrer Wirksamkeit vom Kenntnisstand des Akzeptors abhängt, der die Auswertung derDelegationszertifikate durchführt. Liegen dem Akzeptor umfangreiche Aussagerechte für denAussteller der Delegation vor, so kann auch der Berechtigte entsprechend umfangreiche Rechteerhalten und umgekehrt. Je nach vorliegenden Berechtigungsprämissen oder Delegationszertifi-katen kann also die Sicht auf die Rechte der Beteiligten unterschiedlich sein. Die Angabe einesabsoluten Rechteumfanges ist in diesem Modell nicht möglich, da jeweils nur die subjektiveSicht des Akzeptors betrachtet wird. Dieses Modell trägt damit dem Umstand Rechnung, dassauch bei der menschlichen Delegation jeder einzelne über die jeweiligen Zuständigkeiten einesDelegierenden informiert werden muss.

Das Verfahren koppelt das Recht zur Erstellung von Zusicherungen und das Recht zur Weiter-delegation der Delegation durch (GC3). Diese Zusammenlegung wurde zur Vereinfachung derInhalte der Delegationszertifikate vorgenommen. Alternativ könnten statt des einen Indikators wauch zwei Rechte unterschieden werden. In diesem Fall müsste sich ein Delegationsberechtigteru. U. selbst das Zusicherungsrecht erteilen.

Die Anzahl der Stufen für eine Delegation ist durch den Initiator frei wählbar. Für die Implemen-tierung wurde hier für den Anwendungsfall jedoch die Einschränkung von wmax = 2 eingeführt,da bei Auditierungen längere Delegationsketten nicht sinnvoll sind.

Der Grundmechanismus, einen Sprachumfang auf verschiedenen Ebenen immer weiter einzu-schränken, ermöglicht keine Ausnahmen. Soll z. B. eine unternehmensweite Sicherheitsrichtli-nie aus technischen Gründen für ein System teilweise außer Kraft gesetzt werden, so darf dieRichtlinie nicht auf das System angewendet werden und es müssen alle Beschränkungen, diedennoch gelten sollen, gesondert modelliert werden. Dies bedeutet für solche Fälle zusätzlichenAufwand.

Bei Einsatz von Delegationszertifikaten ist es zwingend notwendig, die Aktualität der Zertifikatenachzuweisen. Hierdurch wird in jedem Fall ein Mechanismus für einen Rückruf und die zentraleVerteilung von Zustandsinformation benötigt. Wird zur Erhebung und Auswertung der Zusiche-rungen ein zentraler Auditierungsserver eingesetzt, so fallen diese Funktionen zusammen undder Aufwand ist vergleichsweise gering.

6 Zusammenfassung

6.1 Erreichte Ziele

Im ersten Kapitel wurden Anforderungen an einen neuen Ansatz für signierte Zusicherungenbei Auditierungen gestellt. Mit den neu entworfenen grammatikbasierten Zertifikaten und denzugehörigen Mechanismen können diese Anforderungen erfüllt werden.

Durch die Kodierung von Zusicherungen durch abstrakte Syntaxbäume auf Basis von kontext-freien Grammatiken wurde eine eineindeutige Beziehung zwischen den natürlichsprachlichenZusicherungen und den im Zertifikat enthaltenen strukturierten Daten geschaffen.

Damit ist der hohe Gestaltungsspielraum der Grammatiken nutzbar, um flexibel unterschiedlich-ste Zusicherungsarten zu unterstützen, sofern die Zusicherungen auf beliebige aber feste Text-bausteine eingeschränkt werden können. Hierbei können auch umfangreiche Textpassagen ver-wendet werden, da durch die zusätzliche Bereitstellung der Grammatiken beim Akzeptor derZertifikate das entwickelte Optimierungsverfahren zur Streichung redundanter Anteile aus demSyntaxbaum eingesetzt werden kann.

Durch den Einsatz von Signaturen in Kombination mit Rückrufmechanismen, die an den X.509-Standard angelehnt wurden, sind die Zusicherungen authentisierbar. Durch die beweisbare Zu-ordnung zu einem Ersteller können die Zusicherungen im Rahmen entsprechender organisatori-scher Festlegungen eine hohe Verbindlichkeit ermöglichen. Durch die technische Möglichkeit inden GC auch Signaturen des Primärtextes zu übertragen, lassen sich auch qualifizierte Signaturenmit hoher Rechtsverbindlichkeit in den Ansatz integrieren.

Da der Primärtext sowohl bei der Erstellung als auch bei der Auswertung der GC angezeigtwerden kann, lässt sich eine sehr hohe Verständlichkeit der Zusicherungen erreichen, da dieseumgangssprachlich oder in der Fachsprache des jeweiligen Anwendungsfalles erstellt werdenkönnen. Bei der Parametrisierung von Anforderungen und Einschränkungen können semantischsinnvoll belegte Bezeichner verwendet werden, so dass die XML-Daten der Zusicherungen undXPath-Ausdrücke der Beschränkungen ebenfalls mit Termen der anwendungsspezifischen Spra-che gestaltet werden können.

Mit diesen Kodierungsformen ist es möglich, Anforderungen von Zusicherungen, Beschrän-kungen des Sprachumfangs von Zusicherungen, Compliance-Prüfungen und die Zusicherungen

143

144 Kapitel 6. Zusammenfassung

selbst so bereit zu stellen, dass für diese eine vollautomatische Auswertung realisiert werdenkann.

Für die Berechtigung zur Erstellung von Zusicherungen wurde ein skalierbarer, mehrstufigerDelegationsmechanismus bereit gestellt, über den z. B. ausgehend vom Sicherheitsmanagementüber z. B. zwei Führungsebenen Mitarbeitern die notwendige Kompetenz zugesprochen werdenkann. Dabei ist es möglich, den Kompetenzumfang in jeder Delegationsstufe weiter einzuschrän-ken.

Für alle Mechanismen wurden Datenformate spezifiziert und eine prototypische Implementie-rung erstellt, die ihre Funktionsfähigkeit belegt.

Alle zur Anwendung der grammatikbasierten Zertifikate notwendigen Interpretationsvereinba-rungen wurden formal spezifiziert und einer Analyse auf Basis der SVO-Logik unterzogen. Aufdiese Weise konnte gezeigt werden, welche Überzeugungen aus den grammatikbasierten Zertifi-katen abgeleitet werden können und welche Prämissen dazu notwendig sind.

Die wichtigste Interpretationsvereinbarung ist (GC1). Anwender müssen beim Verfahren der si-gnierten abstrakten Syntaxbäume (s-s) die Gleichsetzung der Äußerung von XML-kodierten Da-ten mit dem zurückgewonnenen Primärtext akzeptieren. Dies ist nicht notwendig, wenn mit demp-s-Verfahren gearbeitet wird (Primärsignatur und Übertragung der strukturierten Daten). In al-len Fällen kann die Interpretationsvereinbarung (GC2) zur Berechtigungsprüfung im Hinblickauf einen für die Zusicherung vorgegebenen Sprachumfang eingesetzt werden. Die dritte Verein-barung (GC3) legt die Interpretation der Delegationszertifikate fest und ermöglicht die Nutzungvon Delegationsketten mit beschränkbarer Länge.

Die formalen Analysen bilden klare Vorgaben für Implementierungen, da sie alle notwendigenPrüfschritte exakt dokumentieren, so dass sich für Realisierungen ergibt, welche Daten vorgehal-ten und welche algorithmischen Verfahrensschritte ausgeführt werden müssen. Dadurch ist einesichere Realisierung der Anwendung grammatikbasierter Zertifikate deutlich vereinfacht.

6.2 Grenzen des Verfahrens

Das vorgestellte Verfahren weist durch einige seiner Eigenschaften und durch die zur Etablierungnotwendigen Aufwände hinsichtlich der Anwendbarkeit Grenzen auf.

Es wurde vorausgesetzt, dass die GC ein bestehendes Auditierungssystem unterstützen, d. h. dassgrundsätzlich die angeforderten Zusicherungen z. B. durch schriftliche Prüfpläne und Sicher-heitsrichtlinien bekannt sind. Die Auswertung der XPath-Ausdrücke ist trotz der Verwendungvon Begriffen des Anwendungsbereichs für den Endanwender nicht ohne entsprechende Unter-richtung möglich. Somit ist es also nicht sinnvoll, lediglich im Rahmen der elektronisch kodier-ten Festlegungen bei Autorisierungen, Prüfausdrücken für Policy-Vorgaben oder Delegationenneue Beschränkungen aufzunehmen; eine begleitende Dokumentation von Anforderungen undBeschränkungen in Textform bleibt weiterhin notwendig.

6.3 Ausblick 145

Desweiteren werden Einschränkungen, die im Rahmen der genannten Prüfausdrücke aufgenom-men werden, nicht in den automatisch generierten Eingabewerkzeugen berücksichtigt. Diese prü-fen zwar die Korrektheit in Bezug auf die Basisberechtigung, also L (G), nicht jedoch alle imNachgang geforderten oder ausgeschlossenen Wertebereiche. Die Überschreitung des Kompe-tenzbereiches durch einen Ersteller einer Zusicherung kann daher u. U. nicht durch das Eingabe-werkzeug erkannt werden, sondern führt erst bei der Auswertung der Zusicherung zur korrektenAblehnung.

Teilweise erzwingen Formulierungen bestimmte Konstrukte in der Grammatik und damit in denstrukturierten Daten, die beim direkten Entwurf eines Austausch-Formates vermieden werdenkönnten. Dies wird durch das Prinzip verursacht, dass es keine leeren Knoten (d. h. Blätter, dieein Nicht-Terminal repräsentieren) im AST gibt und somit jede Information durch ein Terminalkodiert werden muss. Dadurch werden teilweise einfache binäre Entscheidungen durch einenKnoten mit einem Wort aus dem jeweiligen Zusicherungstext dargestellt.

Da die Eingabe von Zusicherungen im Primärtextformat im Vergleich zur formularbasierten Ein-gabemethode vergleichsweise aufwändig ist, ist davon auszugehen, dass das letztgenannte Ein-gabeverfahren dominieren wird. Die Primärtextdarstellung wird in solchen Anwendungsfällenhauptsächlich während einer Einführungsphase relevant sein, in der Anwender die Bedeutungder von ihnen abgegebenen Zusicherungen erlernen. Später wird sie im täglichen Betrieb eineuntergeordnete Rolle spielen und lediglich zu Nachweisen z. B. im Fall externer Audits oder beijuristischen Fragen herangezogen werden.

Da die Erstellung von Grammatiken und das Einrichten von Berechtigungen trotz der unterstüt-zenden Werkzeuge einen unvermeidbaren Aufwand zur Bereitstellung erzeugt, ist davon aus-zugehen, dass das Verfahren nur in Fällen zum Einsatz kommt, die durch eine standardisierteGrundlage (z. B. IT-Grundschutz) eine breite Anwendergruppe ansprechen oder die durch peri-odische Ausführung zu einer großen Zahl von Nutzungen führen. Für Fälle von akut auftreten-dem Prüfbedarf wird das Verfahren eine untergeordnete Bedeutung haben.

6.3 Ausblick

Mit dieser Arbeit wurde das Grundprinzip der grammatikbasierten Zertifikate eingeführt, bewer-tet und erprobt. Die dabei erkannten Grenzen stellen einen Themenbereich dar, in dem weitereUntersuchungen sinnvoll sind.

Eine wichtige Aufgabenstellung ist die Endanwender-taugliche Darstellung der durch XPath-Ausdrücke spezifizierten Anforderungen und Einschränkungen. Hierbei können vor allem dieautomatische Erstellung von Beauftragungstexten zur Erstellung von Auditierungen sowie dieBereitstellung angepasster Eingabewerkzeuge, die die jeweils gültigen Einschränkungen berück-sichtigen, den Nutzwert erhöhen.

Eine weitere Fragestellung ist die Prüfung der Anwendbarkeit in anderen Anwendungsfeldernals der Auditierung von IT-Systemen. Hierbei ist insbesondere der Bereich online abgeschlos-sener Rechtsgeschäfte, die Kauf- und Dienstleistungsverträge umfassen, ein viel versprechender

146 Kapitel 6. Zusammenfassung

Bereich. Bei solchen Geschäften ist häufig die Akzeptanz umfassender Bedingungen notwen-dig, gleichzeitig muss jedoch aber auch der jeweils gewählte Dienstleistungsumfang, ggf. miteiner Reihe von Optionen, beauftragt oder eine verbindliche Bestellung diverser Waren bestätigtwerden.

Gerade beim Einsatz im kommerziellen Bereich, jedoch auch bei stark verteilten Auditierungs-szenarien z. B. in Großunternehmen, stellen sich darüber hinaus architekturelle Fragen nach dersinnvollen Platzierung von Funktionen wie Grammatikserver und Statusauskunftsdiensten. Diedaraus resultierenden Vertrauensbeziehungen bedingen ggf. weitere Berechtigungsmechanismenoder Kompetenzannahmen, deren Modellierung über den hier vorgestellten Ansatz hinausgeht.

Die bisher nur prototypische Implementierung sollte in produktiv nutzbare Werkzeuge über-führt werden. Hierbei ist insbesondere die Gestaltung der Komponente für den Ersteller vonZusicherungen interessant, da für alle Bereiche, in denen diese Rolle ad-hoc durch Anwenderübernommen wird, keine aufwändige Programmverteilung stattfinden kann. Ein möglicher An-satzpunkt ist die Kombination aus Web-basierten Eingabeformularen zur Erstellung der struktu-rierten Daten bei gleichzeitiger Integration einer Rückgewinnungs- und Anzeigekomponente imWeb-Browser, die für den Anwender die Funktionen Anzeige und Signatur der zu bestätigendenDaten in einem von ihm kontrollierten Bereich vertrauenswürdig bereit stellen.

Um eine solche allgemein verwendbare Infrastruktur realisieren zu können, ist es zudem unver-zichtbar, durch öffentlich zugängliche Standardisierung der grammatikbasierten Zertifikate eineBasis für den interoperablen Einsatz zu schaffen. Diese Maßnahme ist für unternehmensinter-ne Lösungen nicht zwingend notwendig, jedoch für die Nutzung außerhalb der geschlossenenAnwendergruppen kann sie, ggf. verbunden mit der Bereitstellung entsprechender Funktionsbi-bliotheken, grammatikbasierte Zertifikate als einen Baustein zur Realisierung verbindlicher undfür den Anwender nachvollziehbarer elektronischer Kommunikations- und Geschäftsprozesseüber das Gebiet der Auditierung von IT-Systemen hinaus etablieren.

A Übersicht über SVO-Logik

A.1 Sprachelemente

Formel1 SemantikbXck−1 mit dem privaten Schlüssel k−1 signiertes Datum X{X}k X verschlüsselt unter k

Pk←→Q k ist ein zwischen P und Q geteiltes Geheimnis

PKσ(P, k) k ist ein öffentlicher Signaturschlüssel von PPKϕ(P, k) k ist ein öffentlicher Verschlüsselungsschlüssel von PPKδ(P, k) k ist ein öffentlicher Schlüssel von P zur SchlüsselaushandlungSV(X, k, Y ) Die Formel ist wahr, wenn mit k geprüft werden kann, dass X aus Y

durch Verwendung des zu k gehörenden Signaturschlüssel hervorgeht.P received X P hat die Nachricht X empfangen.P has X P ist in Besitz der Nachricht X .P said X P hat (irgendwann) in der Vergangenheit die (Teil-)Nachricht X gesen-

det.P says X P hat im aktuellen Protokolllauf die (Teil-)Nachricht X gesendet.fresh(X) X war in keiner Nachricht enthalten, die vor dem aktuellen Protokolllauf

gesendet wurde.P believes ϕ P kann sich so verhalten, als ob ϕ wahr ist.P controls ϕ P hat die Kompetenz (Jurisdiktion) über ϕ. Mit anderen Worten: wenn P

ϕ sagt, so gilt ϕ als wahr.X from Q Nachricht X , die von Q stammtK̃ komplementärer Schlüssel zu K (K̃ = K im symmetrischen Fall, K̃ =

K−1 im asymmetrischen Fall)

Ergänzungen durch die vorliegende Arbeit

current(P,X) Wenn P X gesagt hat, so sagt P X auch im aktuellen Protokolllauf.P provides (L, n) P kann das Recht zur Erstellung von Zusicherungen aus der Sprache L

vergeben. n weitere Delegationsstufen sind möglich.GT(n,m) Ganzzahl n ist größer als Ganzzahl m1 mit P,Q: Prinzipale, X, Y : Nachrichten, k: Schlüssel und ϕ: Formel, n,m: Ganzzahlen

147

148 Anhang A. Übersicht über SVO-Logik

A.2 Axiome

A.2.1 Überzeugung

P believes ϕ ∧ P believes (ϕ→ ψ)→ P believes ψ (Ax1)

P believes ϕ→ ϕ (Ax2)

P believes ϕ→ P believes (P believes ϕ) (Ax3)

¬(P believes ϕ)→ P believes (¬P believes ϕ) (Ax4)

A.2.2 Quellenzuordnung

(PK←→Q ∧R received {X from Q}K)→ (Q said X ∧Q has K) (Ax5)

(PKσ(Q,K) ∧R received X ∧ SV(X,K, Y ))→ Q said Y (Ax6)

A.2.3 Schlüsselaushandlung

((PKδ(P,Kp)) ∧ (PKδ(Q,Kq)))→ PF0(Kp,Kq)←→ Q (Ax7)

ϕ ≡ ϕ[F0(K,K′)/F0(K

′, K)] (Ax8)

A.2.4 Empfang von Nachrichten

P received (X1, . . . , Xn)→ P received Xi (Ax9)

(P received {X}K ∧ P has K̃)→ P received X (Ax10)

P received bXcK → P received X (Ax11)

A.2 Axiome 149

A.2.5 Besitz von Information

P received X → P has X (Ax12)

P has (X1, . . . , Xn)→ P has Xi (Ax13)

(P has X1 ∧ . . . ∧ P has Xn)→ (P has F (X1, . . . , Xn)) (Ax14)

A.2.6 Verständnis von Informationen

P believes (P has F (X))→ P believes (P has X) (Ax15)

A.2.7 Aussagen

P said (X1, . . . , Xn)→ (P said Xi ∧ P has Xi) (Ax16)

P says (X1, . . . , Xn)→ (P said (X1, . . . .Xn) ∧ P says Xi) (Ax17)

A.2.8 Jurisdiktion

(P controls ϕ ∧ P says ϕ)→ ϕ (Ax18)

A.2.9 Frische

fresh(Xi)→ fresh(X1, . . . , Xn) (Ax19)

fresh(X1, . . . , Xn)→ fresh(F (X1, . . . , Xn)) (Ax20)

A.2.10 Prüfung von Frische

(fresh(X) ∧ P said X)→ P says X (Ax21)

A.2.11 Symmetrische Eignung von geteilten Schlüsseln

PK←→Q ≡ Q

K←→ P (Ax22)

A.2.12 Ergänzung: Aktualität

Q said X ∧ current(Q,X)→ Q says X (Ax23)

150 Anhang A. Übersicht über SVO-Logik

A.3 Ergänzungen für grammatikbasierte Zertifikate

A.3.1 Interpretation für grammatikbasierte Zertifikate

Q says GC(X,H(G),M) ∧GCV(X,G, p)→ Q says p (GC1)

A.3.2 Kompetenz für Sprachelemente

P controls L (G, r) ∧GCV(X,G, p) ∧GCR(X, r)→ P controls p (GC2)

A.3.3 Delegation

(Q says GDC(P,H(G), r1, w,M) ∧ Q provides (L (G, r0), n) ∧ GT(n,w))→(P controls L (G, and(r0, r1)) ∧ P provides (L (G, and(r0, r1)), w)) (GC3)

B Anwendungsbeispiele für formaleAnalysemethoden

Dieser Anhang enthält ausführliche Beispiele zur Demonstration der Anwendung der formalenAnalysemethoden SVO und Proverif aus Kapitel 3.

B.1 SVO: Prüfung signierter Daten mit PKI-Diensten

Als Beispiel für die Anwendung der SVO-Logik soll der Empfang eines signierten Datums unddie zugehörige Auswertung von Zertifikaten betrachtet werden. Alice (A) erhält von Bob (B)ein von ihm signiertes Datum D sowie das zur Prüfung notwendige Zertifikat. Alice verfügtlediglich über den Schlüssel KT des ausstellenden Trust Centers T sowie die Zertifikate seinerOCSP-Dienste und prüft die Gültigkeit des Zertifikats von Bob gegen das Ausstellerzertifikatund den OCSP-Responder O des Trust Centers.

Das Zertifikat, das B vorlegt, enthält neben Schlüssel KB und Identität B noch eine Seriennum-mer S, die Ausstellerangabe T und einen Verweis auf den zuständigen OCSP-Dienst O:

bS, T,B,KB, OcK−1T

(B.1)

Der OCSP-Responder verwendet das Datum g zur Kennzeichnung des Status good (alternativsind r: revoked, u: unknown) gemäß RFC 2560 [MAM+99].

Für die Modellierung werden keine Zeitangaben in den Zertifikaten betrachtet, sondern es wirddavon ausgegangen, dass die Kommunikation innerhalb des Gültigkeitszeitraums aller Zertifi-kate stattfindet, da Zeitangaben in den Zertifikaten ohne Nutzung von Abfrageprotokollen aufder Anwenderseite geprüft werden können und somit schon vor Anwendung des untersuchtenProtokollablaufs ihre Eignung sichergestellt werden kann.

B.1.1 Zielfestlegung

Es soll gezeigt werden, dass A zu der Überzeugung kommen kann, dass das Datum D von Bgesendet wurde.

A believes B said D

151

152 Anhang B. Anwendungsbeispiele für formale Analysemethoden

B.1.2 Protokollbeschreibung

Am Kommunikationsablauf aus drei Nachrichten sind A, B und der OCSP-Dienst (O) beteiligt.

(1) B 7→ A : (bDcK−1B, bS, T,B,KB, OcK−1

T)

(2) A 7→ O : (H(T ), S,N)

(3) O 7→ A : bH(T ), S, g,NcK−1O

Mit der ersten Nachricht (1) erhält A das signierte Datum und das Zertifikat von B. Mit Nachricht(2) fragt A bei O nach einer Statusauskunft bezüglich des Zertifikats mit dem Hashwert über dieAusstellerkennung H(T ), der Seriennummer S und fügt einen Zufallswert N (Nonce) hinzu. MitNachricht (3) antwortet O mit der Statusauskunft.

Bei der Analyse von Authentisierungsprotokollen kann die Zeit in Epochen eingeteilt werden,die durch den Beginn und das Ende eines Protokolllaufs definiert werden. Die aktuelle Epocheist somit die Zeit nach der ersten Nachricht des zu untersuchenden Laufes eines Authentisie-rungsprotokolls, in der eine Nachricht frisch sein kann (vgl. Tabelle 3.1).

B.1.3 Prämissen aus initialem Wissen

Im ersten Modellierungsschritt werden die Prämissen notiert, die das initiale Wissen und diegetroffenen Annahmen durch A beschreiben.

A believes PKσ(T,KT ) (P1)A believes PKσ(O,KO) (P2)A believes T controls PKσ(B,KB) (P3)A believes T controls (O controls current(T, Z)) (P4)A believes current(T,O controls current(T, Z)) (P5)A believes fresh(N) (P5)

A kennt die öffentlichen Schlüssel von T und jedem infrage kommenden O und kann diesekorrekt zuordnen (P1, P2). Bei der Modellierung wird nur ein beliebiger aber fester OCSP-Responder berücksichtigt.

(P3) besagt, dass A dem Trust Center die Kompetenz einräumt, Zertifizierungsaussagen zu ma-chen. Daneben kann das Trust Center Aussagen zur Aktualität der Zertifikate an O delegieren(P4). Diese Delegation im Rahmen der Ausstellung kann nicht widerrufen werden und ist daherzu allen Zeiten aktuell (P5). Z steht dabei für ein beliebiges Zertifikat.

A darf die Frische des von ihr erzeugten Zufallswertes N voraussetzen (P5).

B.1 SVO: Prüfung signierter Daten mit PKI-Diensten 153

B.1.4 Prämissen aus empfangenen Nachrichten

Bei der Modellierung der Nachrichten genügt es, die von A empfangenen Nachrichten zu be-trachten. Die von A gesendete Nachricht wird bereits durch (P5) abgedeckt, da die Kenntnis derFrische der einzige relevante Aspekt ist, der zum Wissen von A beiträgt. Die Nachrichten sindsomit

A received (bDcK−1B, bS, T,B,KB, OcK−1

T)

A received bH(T ), S, g,NcK−1O

Die Wiedererkennung bzw. das Verständnis der Elemente in den empfangenen Nachrichten wirddurch die folgenden Prämissen wiedergegeben und damit die subjektive Sichtweise berücksich-tigt. Dabei wurde die erste Nachricht bereits in die Bestandteile zerlegt und die jeweiligen Inter-pretationen der Felder durch SVO-Terme gefasst.

A believes A received b〈D〉∗AcK−1B

(P6)

A believes A received b〈S〉∗A, T,PKσ(B, 〈KB〉∗A), O controls current(T, Z)cK−1T

(P7)

A believes A received bcurrent(T, 〈S〉∗A, T,PKσ(B, 〈KB〉∗A)), NcK−1O

(P8)

In (P6) und (P7) sind für A das signierte Datum, die Seriennummer des Zertifikats sowie derPrüfschlüssel des Signierers neue Daten und werden daher in der 〈X〉∗A-Schreibweise notiert.Bei der Interpretation der Nachrichten wird die Nennung von B und KB definitionsgemäß alsSubjekt-Schlüssel-Beziehung interpretiert. Die Nennung von O wird als Kompetenzaussage ge-wertet, dass O die Aktualität von Zertifikaten zusichern kann, die T erstellt hat. Aus der Antwortdes OCSP-Responders in (P8) wird der Status g als Aktualitätszusicherung für das Zertifikat mitder Seriennummer S von Aussteller T und damit für das vorliegende Zertifikat interpretiert.

Zur Erhöhung der Lesbarkeit wird für die weiteren Umformungen bei den Größen KB, S undD auf die Notation 〈X〉∗A verzichtet, da keine der Größen im Weiteren als Funktionsergebnisinterpretiert wird.

Für die Zertifikatsaussage wird die Abkürzung ZB eingeführt:

ZB =def (S, T,PKσ(B,KB), O controls current(T, Z)) (B.2)

A kann die Signatur des Zertifikats erfolgreich mit dem Schlüssel von T prüfen.

A believes SV(bZBcK−1T, KT , ZB) (P9)

Ebenso seien die Prüfungen für die anderen Signaturen erfolgreich.

I =def current(T, (S, T,PKσ(B,KB))), N (B.3)A believes SV(bIcK−1

O, KO, I) (P10)

A believes SV(bDcK−1B, KB, D) (P11)

Mit den aufgestellten Prämissen und den Axiomen der SVO-Logik kann nun der Nachweis ge-führt werden, dass A von der Authentizität der signierten Nachricht überzeugt werden kann.


B.1.5 Durchführung von Ableitungsschritten

Mit den gegebenen Prämissen und Axiomen wird im Rahmen einer Ableitung versucht, das de-finierte Ziel herzuleiten. Die bei den Ableitungsschritten verwendeten Schreibweisen werden imFolgenden dargestellt. Für die Anwendung des i-ten Axioms (Axi) der SVO-Logik auf den kon-kreten Anwendungsfall werden dessen allgemeinen Variablen durch konkrete Bezeichner ausdem untersuchten Anwendungsfall ersetzt, dargestellt durch eine Substitutionsfunktion σ(τ), diealle xi durch yi ersetzt (Schreibweise {yi/xi}). Durch die Nec-Regel wird diese dann den Über-zeugungen von A hinzugefügt.

` σ(Axi)A believes σ(Axi)

Nec mit σ(τ) = τ{y1/x1} . . . {yn/xn}

Für weitere Schlussfolgerungen kann die Kombination aus Axiom (Ax1) und der Modus-Ponens-Regel angewendet werden.

A believes ϕ ∧ A believes (ϕ→ ψ), (A believes ϕ ∧ A believes (ϕ→ ψ))→ A believes ψA believes ψ

MP

Dieser Ausdruck kann auch kürzer geschrieben werden:

A believes ϕ ∧ A believes (ϕ→ ψ)

A believes ψAx1, MP

B.1.6 Ableitung

Im ersten Schritt stellt A die Authentizität des Zertifikates fest. Das zugehörige Axiom ist (Ax6).Dieses wird durch entsprechende Ersetzung und Übernahme in die Überzeugungen von A an-wendbar gemacht.

` σ((PKσ(Q,K) ∧R received X ∧ SV(X,K, Y ))→ Q said Y )

` A believes(

PKσ(T,KT ) ∧ A received bZBcK−1T∧ SV(bZBcK−1

T, KT , ZB)→ T said ZB

) Nec

(C1)

mit σ(τ) = τ{T/Q}{KT/K}{A/R}{bZBcK−1T/X}{ZB/Y }

Das der Formelzählung vorangestellte „C“ steht für Schlussfolgerung (Conclusio). Damit wirdjeweils das Ergebnis des Ableitungsschrittes referenziert.

Mittels der übernommenen Formel (C1) und den Prämissen (P1), (P7) und (P9) sowie der Schreib-weise aus (B.2) kann die Nachricht ZB dem Absender T über die said-Relation zugeordnet wer-den.

ϕ =

aus P1︷︸︸︷PKσ(T,KT )∧

aus P7︷︸︸︷A received bZBcK−1

T∧

aus P9︷︸︸︷SV(bZBcK−1

T, KT , ZB)

ψ = T said ZB

B.1 SVO: Prüfung signierter Daten mit PKI-Diensten 155

P1,P7,P9︷︸︸︷A believes ϕ∧

C1︷︸︸︷A believes (ϕ→ ψ)

A believes (T said ZB)Ax1, MP (C2)

Da jeder weitere Ableitungsschritt genau diesem Schema folgt, wird im Weiteren nur jeweils dasabgeleitete Ergebnis und die dazu verwendeten Prämissen, Zwischenergebnisse und Ableitungs-regeln angegeben.

Nach (C2) ist T said (S, T,PKσ(B,KB), O controls current(T, Z)) gegeben. Mit (Ax16)können Teilaussagen betrachtet werden:

A believes T said O controls current(T, Z) (C3)durch Ax16, Nec, C2, Ax1, MP

Da diese Aussage per Festlegung in (P5) als aktuell gilt, ist auch die Äußerung aktuell.

A believes T says O controls current(T, Z) (C4)durch Ax23, Nec, P5, C3, Ax1, MP

A akzeptiert die Aussage von T über O, da mit (P4) die notwendige Kompetenz vorliegt.

A believes O controls current(T, Z) (C5)durch Ax18, Nec, C4, P4, Ax1, MP

Die Auskunft des OCSP ist authentisch.

A believes O said (current(T, (S, T,PKσ(B,KB))), N) (C6)durch Ax6, Nec, P2, P8P10, Ax1, MP

Da N frisch ist, ist auch die Auskunft des OCSP frisch.

A believes fresh(current(T, (S, T,PKσ(B,KB))), N) (C7)durch Ax19, Nec, P5, Ax1, MP

Damit ist die Äußerung der Auskunft aktuell.

A believes O says (current(T, (S, T,PKσ(B,KB))), N) (C8)durch Ax21, Nec, C7, C6, Ax1, MP

Es wird nur ein Teil der Aussage benötigt.

A believes O says current(T, (S, T,PKσ(B,KB))) (C9)durch Ax17, Nec, C8, Ax1, MP


Da A durch die Aussage von T von der Kompetenz von O überzeugt ist, wird die Auskunft alsFakt übernommen.

A believes current(T, (S, T,PKσ(B,KB))) (C10)durch Ax18, Nec, C5, C9, Ax1, MP

Es wird der Zertifizierungsteil der Aussage von T betrachtet.

A believes T said (S, T,PKσ(B,KB)) (C11)durch Ax16, Nec, C2, Ax1, MP

Da die Aktualitätsaussage des OCSP vorliegt, ist die Äußerung aktuell.

A believes T says (S, T,PKσ(B,KB)) (C12)durch Ax23, Nec, C11, C10, Ax1, MP

Damit wird auch die Teilaussage der Schlüsselzuordnung aktuell von T geäußert.

A believes T says PKσ(B,KB) (C13)durch Ax17, Nec, C12, Ax1, MP

T hat als Trust-Center die Kompetenz, Aussagen über Schlüsselzuordnungen zu machen (P3).Damit übernimmt A die Schlüsselzuordnung.

A believes PKσ(B,KB) (C14)durch Ax18, Nec, P3, C13, Ax1, MP

Die Signaturprüfung belegt die Authentizität der Daten D.

A believes B said D (C15)durch Ax6, Nec, C14, P6, P11, Ax1, MP

B.2 Proverif: Anwendungsbeispiel PKI-Dienste

Zur Demonstration der Anwendung von Proverif wird das gleiche Beispiel wie im Fall der SVO-Logik verwendet (vgl. Kapitel B.1).

Während es bei der Betrachtung auf Basis der SVO-Logik ausreicht, die Beobachtungen durchA zu modellieren, werden in Proverif auch B und der OCSP-Dienst modelliert.

Das Verhalten der Beteiligten wird entsprechend der vorgestellten Modellierungsmöglichkeitenhinsichtlich der Generierung von Daten, Sende- und Empfangsvorgänge und Signatur- und Prüf-operationen dargestellt.

B.2 Proverif: Anwendungsbeispiel PKI-Dienste 157

1 (* Beispiel Signierte Daten und OCSP-Abfrage *)2 set traceDisplay = long .3 set verboseRules = true.45 (* Verschlüsselung mit symmetrischen Schlüsseln *)6 type key.7 fun senc(bitstring, key): bitstring.8 reduc forall m: bitstring, k : key; sdec(senc(m, k), k) = m.9

10 (* Asymmetrische Verschlüsselung *)1112 type skey.13 type pkey.1415 fun pk(skey): pkey.16 fun aenc(bitstring, pkey): bitstring.1718 reduc forall m: bitstring, sk : skey; adec(aenc(m, pk(sk)), sk) = m.1920 (* Hash-Funktion *)21 fun H(bitstring):bitstring.2223 (* Asymmetrische Schlüssel und Funktionen für Signaturen *)2425 type sskey.26 type spkey.2728 fun spk(sskey): spkey.29 fun sign(bitstring, sskey): bitstring.3031 reduc forall m: bitstring, ssk : sskey; getmess(sign(m, ssk)) = m.32 reduc forall m: bitstring, ssk : sskey; checksign(sign(m, ssk), spk(ssk)) = m.3334 (* Distinguished Name *)35 type distname.3637 (* Beteiligte *)38 const T:distname. (* Trust Center *)39 const O:distname. (* OCSP Service *)40 const A:distname. (* Alice *)41 const B:distname. (* Bob *)4243 (* Konstanten für OCSP-Auskünfte *)44 type ocspstatus.45 const good:ocspstatus.46 const revoked:ocspstatus.47 const unknown:ocspstatus.4849 (* Konvertierungsfunktion *)50 fun makeissuerref(distname):bitstring [data].5152 (* Allgemeines Kommunikationsmedium *)


53 free c:channel.5455 (* Tabelle mit vertrauenswürdigen Zertifikaten56 vgl. CA-Listen in Browsern *)57 table trustedKeys(distname, spkey).5859 (* Datenbank des OCSP *)60 table ocspDB(bitstring, bitstring).6162 (* Ereignisse *)63 event gotDatafrom(bitstring, distname).64 event newdata(bitstring, distname).6566 (* Prüfungen *)67 (* Erreichbarkeit des finalen Ereignisses *)68 query daten:bitstring, sender :distname;69 event(gotDatafrom(daten, sender)).7071 (* Daten werden nur als authentisch gesehen, wenn sie zuvor72 vom Sender geschickt wurden *)73 query daten:bitstring, sender :distname;74 event(gotDatafrom(daten, sender)) ==> event(newdata(daten, sender)).7576 let userA =77 (* empfange signiertes Datum und Zertifikat *)78 in(c, (signedData:bitstring, cert :bitstring));79 (* Zerlege Zertifikat *)80 let (serial :bitstring,81 issuer :distname,82 subject :distname,83 subjectkey :spkey,84 ocspref :distname) = getmess(cert) in85 (* hole Schlüssel aus Vertrauensliste *)86 get trustedKeys(= issuer , pkT ) in87 (* und prüfe die Signatur des Zertifikats *)88 let (= serial ,= issuer ,= subject ,= subjectkey ,= ocspref )89 = checksign(cert , pkT ) in90 (* Abfrage am OCSP mit nonce N *)91 new N :bitstring;92 out(c, (H(makeissuerref(issuer)), serial ,N ));93 (* warte auf Antwort vom OCSP-Dienst *)94 in(c, ocspresp:bitstring);95 (* Hole Prüfschlüssel entsprechend OCSPref aus Zertifikat *)96 get trustedKeys(= ocspref , pkO) in97 (* Signaturprüfung mit gleichzeitiger Prüfung auf ’good’ *)98 let (= H(makeissuerref(issuer)),= serial ,= N ,= good)99 = checksign(ocspresp, pkO) in

100 (* prüfe Signatur der Daten *)101 let data:bitstring = checksign(signedData, subjectkey) in102 (* Daten werden als authentisch von subject akzeptiert *)103 event gotDatafrom(data, subject)

B.2 Proverif: Anwendungsbeispiel PKI-Dienste 159

104 .105106 let userB(skB :sskey,BobsZert :bitstring) =107 (* generiere neues Datum *)108 new d :bitstring;109 (* Ereignis zur Verwendung in Prüfung *)110 event newdata(d ,B);111 (* Übertragung von signierten Daten und Zertifikat *)112 out(c, (sign(d , skB),BobsZert))113 .114115 let OCSP(skO :sskey) =116 (* Warte auf Anfrage *)117 in(c, (issuerhash:bitstring, serial :bitstring, nonce:bitstring));118 get ocspDB(= issuerhash,= serial) in119 (* Zertifikat vorhanden *)120 out(c, sign((issuerhash, serial , nonce, good), skO))121 .122123 process124 (* Schlüssel für Trust Center und OCSP erstellen ... *)125 new skT :sskey;126 new skO :sskey;127 (* ... und in die Liste der vertrauenswürdigen Schlüssel eintragen *)128 let pkT = spk(skT ) in insert trustedKeys(T, pkT );129 let pkO = spk(skO) in insert trustedKeys(O, pkO);130 (* Schlüssel für Bob *)131 new skB :sskey;132 let pkB = spk(skB) in133 (* Ausstellung des Zertifikats *)134 new s :bitstring;135 (* Zertifikat auch im OCSP hinterlegen *)136 insert ocspDB(H(makeissuerref(T)), s);137 let Bcer = sign((s ,T,B, pkB ,O), skT ) in138 (* Prozesse der (nach der Ausstellung) Beteiligten instantiieren *)139 ((!userA) | (!userB(skB ,Bcer)) | (!OCSP(skO)))140

Die Erreichbarkeit des Authentisierungsschrittes ist gegeben.

The event gotDatafrom(d_1550,B) is executed.A trace has been found.RESULT not event(gotDatafrom(daten_824,sender_825)) is false.

Die Korrespondenz zur Sicherstellung der Authentizität der empfangenen Daten ist ebenfallsnachweisbar.

Starting query event(gotDatafrom(daten,sender)) ==>event(newdata(daten,sender))


goal reachable: begin(newdata(d[!1 = @sid_821],B)) ->end(gotDatafrom(d[!1 = @sid_821],B))RESULT event(gotDatafrom(daten,sender)) ==>event(newdata(daten,sender)) is true.

Durch Einführung eines Phasenmodells können für das Modell auch die Sperrung des Zertifikatsund die Notwendigkeit der Prüfung des Nonce-Wertes nachgewiesen werden.

In die Prozesse wird eine Teilung in die Phasen 0 und 1 integriert. In Phase 1 veröffentlichtB seinen privaten Schlüssel (Schlüsselkompromittierung). Der OCSP-Dienst antwortet mit demStatus „revoked“. A empfängt und prüft Nachrichten auf die gleiche Weise wie in der erstenPhase.

Durch die negative Auskunft des OCSP-Dienstes ist das Ereignis gotDatafrom’ nicht erreichbar.

Wird die Prüfung des Nonce-Wertes unterbunden (Austausch des Terms =N’ durch N”:bitstring),so gelingt es dem Angreifer durch Kenntnis des privaten Schlüssels von B und Wiedereinspieleneiner in Phase 0 ausgestellten OCSP-Auskunft den Prüfpunkt gotDatafrom’ zu erreichen. DieKorrespondenz des Prüfpunktes mit dem Kontrollereignis beim Ausstellen der Nachricht schlägtfehl.

C Verwendete Grammatiken

Dieser Anhang enthält einige Grammatiken, die im Rahmen der Mechanismen und Beispieleverwendet wurden.

C.1 Meta-Grammatik

Die nachstehenden Meta-Grammatik, die in ANTLRv3-Syntax notiert ist, definiert die Formder Grammatikdateien für grammatikbasierte Zertifikate. Mit Parsern auf Basis dieser Meta-Grammatik kann somit die Wohlgeformtheit einer GC-Grammatik überprüft werden./*ANTLRv3-Grammatik zur Prüfung von Grammatiken für grammatikbasierte Zertifikate(C) 2012 Matthias Kabatnik

*/

grammar GCG;

options {output=AST;ASTLabelType=CommonTree;

}

gcgGrammatik: (knotenRegel | nonKnotenRegel)+ EOF;

knotenRegel: TOKIDENTIFIER ’:’ rhs ’;’;

nonKnotenRegel: (TOKIDENTIFIER|NTOKIDENTIFIER) INV ’:’ rhs ’;’;

rhs : (terminaleVariante|nonTerminaleVariante)( ’|’ (terminaleVariante|nonTerminaleVariante) )*

;

terminaleVariante: (terminal INV quantor?)*

terminalerBaustein quantor?(terminal INV quantor?)*

;

nonTerminaleVariante

161

162 Anhang C. Verwendete Grammatiken

: ((terminal VIS?| LEXEM) quantor?)*nonTerminalerBaustein quantor?((((terminal VIS?)|LEXEM)|nonTerminalerBaustein) quantor?)*

;

terminalerBaustein: terminal | LEXEM;

nonTerminalerBaustein: NTOKIDENTIFIER | TOKIDENTIFIER;

terminal : CHAR_LITERAL | STRING_LITERAL | WSMAKRO;

quantor : ’?’ | ’*’ | ’+’;

// Lexikalische Regeln

INV: ’!’ // markiert Terminale, Lexeme und terminale Knoten als; // unsichtber (INVisble)

VIS: ’^’ // erzwingt die Sichtbarkeit eines Terminals in einem; // inneren Knoteni (VISible)

WSMAKRO : ’WS’ // Lexem als Platzhalter für einzelne Leerzeichen;

/* Die folgenden Lexer-Regeln wurden teilweise aus der ANTLRv3-Grammatik(Copyright (c) 2005-2007 Terence Parr All rights reserved) übernommen

*/

SL_COMMENT: ’//’

~(’\r’|’\n’)*’\r’? ’\n’{$channel=HIDDEN;}

;

ML_COMMENT: ’/*’ .* ’*/’ {$channel=HIDDEN;};

CHAR_LITERAL: ’\’’ LITERAL_CHAR ’\’’;

STRING_LITERAL: ’\’’ LITERAL_CHAR LITERAL_CHAR* ’\’’;

fragmentLITERAL_CHAR

: ESC| ~(’\’’|’\\’);

fragmentESC : ’\\’ ( ’n’ | ’r’ |’t’

| ’b’| ’f’| ’"’| ’\’’

C.2 XML-Schema für grammatikbasierte Zertifikate 163

| ’\\’| ’>’| ’u’ XDIGIT XDIGIT XDIGIT XDIGIT| . // unknown, leave as it is)

;

fragmentXDIGIT : ’0’ .. ’9’ | ’a’ .. ’f’ | ’A’ .. ’F’

;

INT : ’0’..’9’+;

NTOKIDENTIFIER : ’a’..’z’ ID;

TOKIDENTIFIER // ID, die auch als Token (Knotenname) des AST zulässig ist: ’A’..’Z’(’A’..’Z’|’_’|’0’..’9’)* ’a’..’z’ ID;

fragmentID : (’a’..’z’|’A’..’Z’|’_’|’0’..’9’)*

;

LEXEM : (’A’..’Z’|’_’|’0’..’9’)+;

WS : ( ’ ’ | ’\t’ | ’\r’? ’\n’)+ {$channel=HIDDEN;};

C.2 XML-Schema für grammatikbasierte Zertifikate

<?xml version="1.0" encoding="UTF-8"?><xsd:schema xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:gc="http:///GCertSchema/

GrammarbasedCertificate/GrammarbasedCertificate.xsd" xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http:///GCertSchema/GrammarbasedCertificate/GrammarbasedCertificate.xsd">

<xsd:element name="GrammarbasedCertificate"><xsd:complexType>

<xsd:sequence><xsd:element name="Version" type="string"></xsd:element><xsd:element name="SerialNumber" type="xsd:hexBinary"></xsd:element><xsd:element name="Issuer" type="gc:entityType"></xsd:element><xsd:element name="Validity" type="gc:validityType"></xsd:element><xsd:element name="GrammarReference" type="gc:grammarReferenceType"></xsd:element><xsd:element name="Assertion" type="gc:assertionType" maxOccurs="unbounded"></xsd:

element><xsd:element name="Nonce" type="xsd:base64Binary" minOccurs="0"></xsd:element><xsd:element name="Extensions" type="gc:extensionsType" minOccurs="0"></xsd:element

></xsd:sequence><attribute name="ID" type="string" fixed="tbsGCertificate"></attribute>

</xsd:complexType></xsd:element>

<xsd:complexType name="validityType"><xsd:sequence>

<xsd:element name="NotBefore" type="xsd:timeInstant"></xsd:element><xsd:element name="NotAfter" type="xsd:timeInstant" minOccurs="0"></xsd:element>


</xsd:sequence></xsd:complexType>

<xsd:complexType name="grammarReferenceType"><xsd:sequence>

<xsd:element name="DigestMethod" type="gc:digestMethodType"></xsd:element><xsd:element name="DigestValue" type="xsd:base64Binary"></xsd:element><xsd:element name="URI" type="xsd:anyURI" minOccurs="0"></xsd:element><xsd:element name="GCGrammarServer" type="xsd:anyURI" minOccurs="0"></xsd:element>


<xsd:simpleType name="digestMethodType"><xsd:restriction base="string">

<xsd:enumeration value="sha256"></xsd:enumeration><xsd:enumeration value="sha384"></xsd:enumeration><xsd:enumeration value="sha512"></xsd:enumeration>

</xsd:restriction></xsd:simpleType>

<xsd:complexType name="assertionType"><xsd:sequence>

<xsd:element name="ParseTree" type="gc:wildcardType"></xsd:element><xsd:element name="Validity" type="gc:validityType" minOccurs="0"></xsd:element><xsd:element name="GrammarReference" type="gc:grammarReferenceType" minOccurs="0"></

xsd:element><xsd:element name="PrimarySignature" type="gc:primarySignatureType" minOccurs="0"></

xsd:element></xsd:sequence>

</xsd:complexType>

<xsd:complexType name="wildcardType"><xsd:sequence maxOccurs="unbounded">

<xsd:any processContents="lax"/></xsd:sequence>

</xsd:complexType>

<xsd:complexType name="extensionsType"><xsd:sequence>

<xsd:element name="AuthorityKeyIdentifier" type="xsd:base64Binary" minOccurs="0"></xsd:element>

<xsd:element name="AuthorityInformationAccess" type="gc:authorityInformationAccessType" minOccurs="0" maxOccurs="unbounded"></xsd:element>

<xsd:element name="CRLDistributionPoint" type="gc:cRLDistributionPointType" minOccurs="0"></xsd:element>


<xsd:complexType name="authorityInformationAccessType"><xsd:sequence>

<xsd:element name="AccessMethod" type="gc:accessMethodType"></xsd:element><xsd:element name="AccessLocation" type="xsd:anyURI"></xsd:element>


<xsd:simpleType name="accessMethodType"><xsd:restriction base="string">

<xsd:enumeration value="ocsp"></xsd:enumeration><xsd:enumeration value="caIssuers"></xsd:enumeration>


<xsd:complexType name="cRLDistributionPointType"><xsd:sequence>

C.3 Grammatik für Anforderungen 165

<xsd:element name="CRLDistributionPointName" type="xsd:anyURI" minOccurs="0" maxOccurs="unbounded"></xsd:element>

<xsd:element name="CRLIssuer" type="gc:entityType" minOccurs="0"></xsd:element></xsd:sequence>

</xsd:complexType>

<xsd:complexType name="primarySignatureType"><xsd:sequence>

<xsd:element name="SignatureAlgorithm" type="gc:signatureAlgorithmType"></xsd:element><xsd:element name="SignatureValue" tpye="xsd:base64Binary"></xsd:element><xsd:element name="X509Certificate" tpye="xsd:base64Binary" minOccurs="0"></xsd:

element><xsd:element name="PrimarySigner" tpye="gc:entityType" minOccurs="0"></xsd:element><xsd:element name="PrimaryAuthorityKeyIdentifier" tpye="xsd:base64Binary" minOccurs

="0"></xsd:element></xsd:sequence>

</xsd:complexType>

<xsd:simpleType name="signatureAlgorithmType"><xsd:restriction base="string">

<xsd:enumeration value="sha256WithRSAEncryption"></xsd:enumeration><xsd:enumeration value="sha384WithRSAEncryption"></xsd:enumeration><xsd:enumeration value="sha512WithRSAEncryption"></xsd:enumeration><xsd:enumeration value="ecdsa-with-SHA256"></xsd:enumeration><xsd:enumeration value="ecdsa-with-SHA384"></xsd:enumeration><xsd:enumeration value="ecdsa-with-SHA512"></xsd:enumeration>


<xsd:complexType name="entityType"><xsd:sequence>

<xsd:choice maxOccurs="unbounded"><xsd:element name="C" type="string"></xsd:element><xsd:element name="countryName" type="string"></xsd:element><xsd:element name="CN" type="string"></xsd:element><xsd:element name="commonName" type="string"></xsd:element><xsd:element name="L" type="string"></xsd:element><xsd:element name="localityName" type="string"></xsd:element><xsd:element name="ST" type="string"></xsd:element><xsd:element name="stateOrProvinceName" type="string"></xsd:element><xsd:element name="title" type="string"></xsd:element><xsd:element name="street" type="string"></xsd:element><xsd:element name="streetAddress" type="string"></xsd:element><xsd:element name="SN" type="string"></xsd:element><xsd:element name="surname" type="string"></xsd:element><xsd:element name="GN" type="string"></xsd:element><xsd:element name="givenName" type="string"></xsd:element><xsd:element name="name" type="string"></xsd:element><xsd:element name="O" type="string"></xsd:element><xsd:element name="organizationName" type="string"></xsd:element><xsd:element name="OU" type="string"></xsd:element><xsd:element name="organizationalUnitName" type="string"></xsd:element><xsd:element name="initials" type="string"></xsd:element><xsd:element name="emailAddress" type="string"></xsd:element><xsd:element name="serialNumber" type="string"></xsd:element>

</xsd:choice></xsd:sequence>

</xsd:complexType></xsd:schema>

C.3 Grammatik für Anforderungen

Satz: ’Die benötigten Zusicherungen müssen folgende Eigenschaften erfüllen:’


Beschraenkungen;

Beschraenkungen: Regel ’\n’| NoRestrictions;

NoRestrictions: ’\n’! ’Keine’ ’ Beschraenkungen\n’!;

Regel!: Pfad| Oder| Und| Inversion;

Pfad : ’\n’! STRING;

Inversion : ’\nnicht(’ Regel ’\n)’;

Oder: ’\noder(’ Regel ’\n;’ Regel ’\n)’;

Und: ’\nund(’ Regel ’\n;’ Regel ’\n)’;

C.4 Grammatik für Delegationszusicherungen

Satz: ’Hiermit wird an ’ Berechtigter’das Recht\nzur Erstellung von Aussagen gemäß der Grammatik ’GrammatikName ’ erteilt.\n\n’GrammatikReferenz Weitergabe Beschraenkungsblock ;

Berechtigter: CommonName ’ (’ EmailAddress ’) ’ ;

CommonName: STRING ;

EmailAddress: STRING ;

GrammatikReferenz: ’Die Grammatik hat den ’ Algorithmus ’-Hashwert\n ’Hashwert ’.\n\n’ Uri? GrammatikServer?;

Algorithmus: ’SHA256’ | ’SHA384’ |’SHA512’ ;

Weitergabe: ’Diese Berechtigung kann über maximal ’! INT’ nachfolgende Delegationsvorgänge\nweitergegeben werden.\n\n’!;

Beschraenkungsblock!:’Die auf Basis dieser Delegation gemachten Aussagen müssen folgende\n’’Bedingungen erfüllen:\n’ Beschraenkungen ;

Beschraenkungen: Regel ’\n’| NoRestrictions;

NoRestrictions : ’Keine’ ’ Beschraenkungen\n’!;

Regel!: Pfad | Oder | Und | Inversion;

C.4 Grammatik für Delegationszusicherungen 167

Pfad : ’\n’! STRING;

Inversion : ’\nnicht(’ Regel ’\n)’;

Oder : ’\noder(’ Regel ’\n;’ Regel ’\n)’;

Und : ’\nund(’ Regel ’\n;’ Regel ’\n)’;

Hashwert : HEX;

Uri : ’Die Grammatik kann unter der Adresse\n ’! STRING’\nabgerufen werden.\n\n’!;

GrammatikServer:’Die Grammatik kann vom Grammatikserver unter der Adresse\n ’!STRING ’\n abgerufen werden\n\n’! ;

GrammatikName : STRING ;


D Erstellung von Grammatiken

D.1 Beispiel für Top-Down-Verfahren

Dieser Abschnitt beschreibt ausführlich die Ableitung einer Grammatik aus einer konkreten Zu-sicherung durch Anwendung der in Kapitel 5.1.4 beschriebenen Vorgehensweise. Dabei werdendie in Anhang D.2 definierten Editor-Makros eingesetzt.

Der Ausgangstext ist eine simple Zusicherung, die in Kapitel 4.3 bereits als Beispiel verwendetwurde. Bei der Darstellung der Umformungen werden nur die jeweils relevanten Regeln darge-stellt. Die Zeilenumbrüche und Einrückungen wurden zur kompakteren Darstellung gegenüberder Originaldatei verändert.

Zunächst wird das Beispiel im Editor so erfasst.

Auf dem Server cntsrv1 wurden alle nicht benötigten Dienste abgeschaltet.Die Korrektheit der Dienstkonfiguration wurde mittels nmap-Befehl geprüft.Die aktiven Dienste sind:ssh auf Port 22http auf Port 80https auf Port 443

Durch Anwendung des gca-Makros wird aus diesem Text die initiale Grammatik erstellt:

Satz:’Auf dem Server cntsrv1 wurden alle nicht benötigten Dienste abgeschaltet.\n’’Die Korrektheit der Dienstkonfiguration wurde mittels nmap-Befehl geprüft.\n’’Die aktiven Dienste sind:\n’’ssh auf Port 22\n’’http auf Port 80\n’;’https auf Port 443\n’;

Durch Markieren von cntsrv1, Makro gcsr für Nicht-Terminal Server und mehrfache Anwen-dung von gcra in der Server-Regel wird eine Auswahl von Terminalen für die Nennung desuntersuchten Servers erstellt:

169

170 Anhang D. Erstellung von Grammatiken

Satz:’Auf dem Server ’ Server’ wurden alle nicht benötigten Dienste abgeschaltet.\n’’Die Korrektheit der Dienstkonfiguration wurde mittels nmap-Befehl geprüft.\n’’Die aktiven Dienste sind:\n’’ssh auf Port 22\n’’http auf Port 80\n’;’https auf Port 443\n’;

Server: ’cntsrv1’ | ’cntsrv2’ | ’cntsrv3’ | ’mailsrv’;

Markieren des Terminals ’Die Korrektheit ... geprüft\n’ und Anwendung von gctr mit dem op-tionalen Nicht-Terminal Pruefung formt die Satz-Regel um:

Satz:’Auf dem Server ’ Server’ wurden alle nicht benötigten Dienste abgeschaltet.\n’Pruefung?’Die aktiven Dienste sind:\n’’ssh auf Port 22\n’’http auf Port 80\n’;’https auf Port 443\n’;

Pruefung:’Die Korrektheit der Dienstkonfiguration wurde mittels nmap-Befehl geprüft.\n’

;

Die Teilzeichenkette ’nmap-Befehl’ wird mit gcsr in eine Methode-Regel ausgelagert und durchgcra um weitere Alternativen ergänzt:

Pruefung:’Die Korrektheit der Dienstkonfiguration wurde mittels ’ Methode’ geprüft.\n’;

Methode: ’nmap-Befehl’ | ’Portscan’ | ’netstat-Befehl’;

Die Aufzählung der Dienste wird durch eine Markierung von ’ssh auf Port ...’ bis ’... Port 443\n’mit dem Makro gctr in eine Dienste-Regel ausgelagert. Das in der Regel Satz aufgenommeneNicht-Terminal Dienste wird als optional markiert:

Satz:’Auf dem Server ’ Server’ wurden alle nicht benötigten Dienste abgeschaltet.\n’Pruefung?’Die aktiven Dienste sind:\n’Dienste?

Dienste: ’ssh auf Port 22\n’ ’http auf Port 80\n’ ’https auf Port 443\n’;

D.2 Definitionen der vim-Makros für Umformungen 171

Aus der Regel Dienste wird die Terminale ’http auf Port 80\n’ und ’https auf Port 443\n’gelöschtund das verbleibende Terminal mit gcst in eine Dienst-Regel gewandelt. Das Nicht-TerminalDienst wird +-quantisiert.

Dienste: Dienst+ ;

Dienst: ’ssh auf Port 22\n’;

Die Teilzeichenketten ’ssh’ und ’22’ werden mit gcsr in eine Dienstname- und eine Port-Regelausgelagert. Bei Dienstname werden durch gcra weitere Namensalternativen aufgenommen.

Dienst: Dienstname ’ auf Port ’ Portnummmer ’\n’;

Dienstname: ’ssh’ | ’dns’ | ’smtp’ | ’http’ | ’https’ | ’ntp’;

Portnummer: ’22’;

Durch Markieren des Terminals ’22’ und Anwendung von gcex mit dem Lexem INT wird diePortnummer-Regel zu:

Portnummer: INT;

Abschließend kann noch eine zusätzliche Knotenebene mit dem Kürzel der Grundschutzmaßnah-me durch Markieren aller Elemente der Satz-Regel und Makro gctr mit Nicht-Terminal Mn5_72erreicht werden.

Satz: Mn5_72;

Mn5_72: ’Auf dem Server ’ Server’ wurden alle nicht benötigten Dienste abgeschaltet.\n’Pruefung’Die aktiven Dienste sind:\n’Dienste?;

D.2 Definitionen der vim-Makros für Umformungen

" Makros zur Unterstützung der Erstellung von gc-Grammatiken" (c) M. Kabatnik, 2012"" gca - gc Anfang" Alle Zeilen in Hochkomma mit explizitem \n und Grundstrukturnmap gca :se tw=0<CR>:%s/^/<Tab><Tab><Tab><Tab>’/<CR>:%s/$/\\n’ /<CR>1GOSatz

<CR><Tab><Tab><Tab>:<Esc>$Go<Tab><Tab><Tab>;<Esc>

" gcmt - gc markiere Terminal" dabei Cursor innerhalb eines mit Hochkomma definierten Terminal-Strings

172 Anhang D. Erstellung von Grammatiken

nmap gcmt ?’<CR>vf’

" gctr - gc Terminal zu Regel umwandeln" Markiertes Terminal oder Elementfolge in Regel verschiebenvmap gctr di<gcName><gcQuant><Esc>$Go<CR><gcName><gcInv><CR><Tab><Tab><Tab

>:<Tab><Esc>p$Go<Tab><Tab><Tab>;<Esc>:%s/<gcName>/gcxID/g<CR>:%s/<gcQuant>/gcxQuant/g<CR>:%s/<gcInv>/gcxInv/g<CR>

" Zusatzfunktionen für gctr und gcsrcmap gcxID <C-R>=inputdialog("Bezeichner")<CR>cmap gcxQuant <C-R>=inputdialog("Quantifizierer (leer, ?, +, *)")<CR>cmap gcxInv <C-R>=inputdialog("Knotenunterdrückung (leer, !)")<CR>

" gcsr - gc Substring aus Terminal zu Regel umwandeln" Markierten Terminalteil in Regel verschiebenvmap gcsr mndi’ <gcName><gcQuant> ’<Esc>$Go<CR><gcName><gcInv><CR><Tab><Tab

><Tab>:<Tab>’<Esc>pa’<Esc>$Go<Tab><Tab><Tab>;<Esc>:%s/<gcName>/gcxID/g<CR>:%s/<gcQuant>/gcxQuant/g<CR>:%s/<gcInv>/gcxInv/g<CR>’n:%s/’’//g<CR>

" gcra - gc Regel Alternative" Cursor innerhalb Regel (nicht auf Semikolon), Alternative hinzufügennmap gcra /;<CR>i<Bar><Tab>’ ’<CR><Tab><Tab><Tab><Up><End><Left><BS>

" gcsa - Substring als AST-relevant markieren" Terminalteil für AST auswählen (durch Markierung)vmap gcsa di’! ’<Esc>pa’ ’<Esc>/’<CR>a!<ESC>:s/ \?’’! \?//g<CR>

" gcex - Ersetzen einer Elementfolge durch Nicht-Terminal oder Lexem" Die markierten Elemente (Terminale, Nicht-Terminale und Lexeme) werden

ersetztvmap gcex c<gcNonTermOrLexem><Esc>:s/<gcNonTermOrLexem>/gcxNTOL/g<CR>

" Zusatzfunktion für gcexcmap gcxNTOL <C-R>=inputdialog("Nicht-Terminal oder Lexem")<CR>

" gcda - gc delete alternative" Löschen der Regelalternative unter dem Cursornmap gcda ?[:<Bar>]<CR><Right>v/[<Bar>;]<CR><Left>d:s/$:$\?<Bar>$<Bar>\<

Bar>;$\?/\1\2/g<CR>

" gczf - Einfalten der Regel unter dem Cursor" Es wird ein eingefalteter vim-Bereich (zf) angelegtnmap gczf /;<CR>?:<CR>?\a<CR>bv/;<CR>zf<Down>/\a<CR>^

E Beispiel eines XML-kodiertengrammatikbasierten Zertifikats

<?xml version="1.0" encoding="UTF-8"?><gc:GrammarbasedCertificate xmlns:gc="http:///GCertSchema/GrammarbasedCertificate/GrammarbasedCertificate.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" ID="tbsGCertificate" xsi:schemaLocation="http:///GCertSchema/GrammarbasedCertificate/GrammarbasedCertificate.xsd GrammarbasedCertificate.xsd ">

<Version>1.0</Version><SerialNumber>05913426df2835c34919ff003666a121</SerialNumber><Issuer>

<emailAddress>[email protected]</emailAddress><CN>Matthias Kabatnik</CN><L>Leinfelden</L><C>DE</C>

</Issuer><Validity>

<NotBefore>2013-04-24T23:35:27Z</NotBefore><NotAfter>2013-07-24T23:35:27Z</NotAfter>

</Validity><GrammarReference>

<DigestMethod>sha256</DigestMethod><DigestValue>c84on+SIZOWu39JR4jzSxi6/TdwPqTEwtDuWllsrdOk=</DigestValue><URI>http://security.example.com/grammars/m173.gcg</URI><GCGrammarServer>http://gcgsrv.example.com/grammarserver</GCGrammarServer>

</GrammarReference><Assertion>

<ParseTree><Satz>

<Ort><GCELEMENT type="STRING">Haus 2, Raum RZ-01</GCELEMENT>

</Ort><Autorisierung>

<AutKriterium><GCELEMENT type="TOKEN">Besitz</GCELEMENT>

</AutKriterium><AutKriterium>

<GCELEMENT type="TOKEN">Wissen</GCELEMENT></AutKriterium>

</Autorisierung><Besucher>

<Zuordnung><GCELEMENT type="TOKEN">zugeordnet</GCELEMENT>

</Zuordnung><Aufsicht>

<GCELEMENT type="TOKEN">sichergestellt</GCELEMENT></Aufsicht>

</Besucher><Protokollierung>

<Zutritt><PZ_Berechtigt>

173

174 Anhang E. Beispiel eines XML-kodierten grammatikbasierten Zertifikats

<GCELEMENT type="TOKEN">elektronisch</GCELEMENT></PZ_Berechtigt><PZ_Besucher>

<GCELEMENT type="TOKEN">schriftlich</GCELEMENT><Abzeichnung>

<GCELEMENT type="TOKEN">abgezeichnet</GCELEMENT></Abzeichnung>

</PZ_Besucher></Zutritt><Austritt>

<PA_Berechtigt><GCELEMENT type="TOKEN">elektronisch</GCELEMENT>

</PA_Berechtigt><PA_Besucher>

<GCELEMENT type="TOKEN">schriftlich</GCELEMENT></PA_Besucher>

</Austritt></Protokollierung><Vereinzelung>

<GCELEMENT type="TOKEN">eine</GCELEMENT></Vereinzelung><Passback>

<GCELEMENT type="TOKEN">eine</GCELEMENT></Passback>

</Satz></ParseTree>

</Assertion><Nonce>AoqSG5dNfIcBZ3GVx+P90Q==</Nonce><Extensions>

<AuthorityKeyIdentifier>9CqNv5x5JBir+JvRmVTWSf9GlrE=</AuthorityKeyIdentifier></Extensions>

<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:SignedInfo><ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/><ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/><ds:Reference URI="#tbsGCertificate"><ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/><ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/></ds:Transforms><ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/><ds:DigestValue>M1qjouVeZYmx42mu/deY67ppNTw=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>Ar1JczWkjY+NEqltO5J9ZfI39xXFFsLk5PjWRXld0d05ooZ5zFFtejEfs3B5YR26EnBBtoWnyCVubd4umig5OvstVoQtIuXisLsmuyXZBHoJEVIlgREK0PG9gAldTOalPFFYVZjn+dSck5ByGgjM8bOMkOOx9FfPp/+eseYG1epgSO1p0BH+Rv6rGYAQqX6Mi87zVHFDWdgjiG7t/Bco9egO6x0abM456f+4hBtKAFh2X+p0/AQJkAUKUHMXdOJaBJaMLVQQTrcV0iZm1geCxnnuex02/HDp2g/gUj0rHIX2FnYPwMdcb6ydetzFr9BWoffjdeyQ+uqb62whtgqdDg==</ds:SignatureValue></ds:Signature></gc:GrammarbasedCertificate>

F Modellierung in Proverif

Die folgende Modellierung in Proverif stellt die Funktionalität des Grammatikverteildienstes mitMöglichkeit zur Delegation dar.

1 (* Analyse des Grammatikservers *)23 (* Angaben zur Steuerung der Ausgabe der Analyseergebnisse *)4 set traceDisplay = long .5 set verboseRules = true.67 (* Datentyp für Nachrichtentypen des Grammatikservers *)8 type gsMessage.9

10 const addG: gsMessage. const addHG: gsMessage. const respG: gsMessage.11 const reqG: gsMessage. const delG: gsMessage. const reqT: gsMessage.12 const respT:gsMessage. const initReqT:gsMessage. const initRespT:gsMessage.1314 (* Hashwert-Funktion ohne Reduktion, da nicht umkehrbar *)15 fun hash(bitstring): bitstring.1617 (************************************************18 * Definitionen für asymmetrische Kryptographie *19 ************************************************)2021 type pkey. (* public encryption key *)22 type skey. (* secret encryption key *)23 type pskey. (* public signing key *)24 type sskey. (* secret signing key *)2526 (* Einweg-Hashfunktion für KeyID-Bestimmung *)27 fun kidhash(pskey):bitstring.2829 (* Public encryption key wird aus privatem encryption key abgeleitet *)30 fun pk(skey):pkey.31 (* Public signing key wird aus privatem signing key abgeleitet *)32 fun psk(sskey):pskey.33 (* Signatur mit Wert und Signaturschlüssel *)34 fun sign(bitstring, sskey):bitstring.35 (* Prüfe Signatur und gib signierte Daten zurück *)36 reduc forall m: bitstring, k : sskey; checksign(sign(m, k), psk(k)) = m.37 (* Prüfe signierten Hashwert gegen die Vergleichsdaten und gib referenzierte Daten zurück *)

175

176 Anhang F. Modellierung in Proverif

38 reduc forall m: bitstring, k : sskey; checksignedhash(m, sign(hash(m), k), psk(k)) = m.3940 (* Zugriff auf signierte Inhalte ohne Prüfung der Signatur *)41 reduc forall m: bitstring, k : sskey; getsigneddata(sign(m, k)) = m.4243 (***********************************************44 * Definitionen für symmetrische Kryptographie *45 ***********************************************)46 type symkey. (* Symmetrischer Schlüssel *)4748 fun senc(bitstring, symkey):bitstring.49 reduc forall x :bitstring, y :symkey; sdec(senc(x , y), y) = x .5051 (* einziger öffentlicher Kommunikationskanal ist das Netz *)52 free net : channel.5354 (* verifizierte Annahmen zur Vertraulichkeit *)55 not attacker (new sskC ). (* privater Signaturschlüssel von C bleibt vertraulich *)56 not attacker (new sskG). (* privater Signaturschlüssel von G bleibt vertraulich *)57 not attacker (new G). (* Grammatik bleibt vertraulich *)5859 (* Definition von Ereignissen *)60 event authKeyidDeleg(bitstring).61 event authKeyidReq(bitstring).62 event reqToken(bitstring, bitstring).63 event reqDelegToken(bitstring, bitstring).64 event grammarInsert(bitstring, bitstring).65 event grammarDelete(bitstring, bitstring).66 event gotGrammar(bitstring).67 event authKeyid(bitstring).68 event genToken(bitstring, bitstring, bitstring).69 event genTokenDeleg(bitstring, bitstring).70 event deleteRequest(bitstring, bitstring).71 event insertRequest(bitstring, bitstring).7273 (* Prüfung der Erreichbarkeit einzelner Ereignisse, erwartetes Ergebnis74 ist: not event(xyz) .... is false. *)75 query G :bitstring,K :bitstring; event(grammarInsert(G ,K )).76 query G :bitstring; event(gotGrammar(G)).77 query K :bitstring; event(authKeyid(K )).78 query R:bitstring,K :bitstring; event(reqToken(R,K )).79 query R:bitstring,K :bitstring; event(reqDelegToken(R,K )).80 query H :bitstring,K :bitstring; event(grammarDelete(H ,K )).81 query R:bitstring,K :bitstring,T :bitstring; event(genToken(R,K ,T )).82 query H :bitstring,K :bitstring; event(deleteRequest(H ,K )).83 query H :bitstring,K :bitstring; event(insertRequest(H ,K )).8485 (* Prüfung der Protokollzusammenhänge*)86 (* Neueinstellung nur durch legitimierte Anwender GS-P1 *)87 query G :bitstring,K1 :bitstring,K2 :bitstring,R:bitstring;88 inj-event(grammarInsert(G ,K1 )) ==> (event(authKeyid(K1 )) ||

177

89 (inj-event(genToken(R,K1 ,K2 )) && event(authKeyidDeleg(K2 )) )).9091 (* Löschung nur, wenn vorher durch gleichen Akteur eingestellt GS-P2 *)92 query G :bitstring,K :bitstring;93 event(grammarDelete(G ,K )) ==> event(grammarInsert(G ,K )).9495 (* Löschung nur, wenn direkte Autorisierung des Antragstellers vorlag96 oder für den Antragsteller einer Delegationstoken beantragt wurde GS-P3 *)97 query G :bitstring,K1 :bitstring,K2 :bitstring,R:bitstring;98 inj-event(grammarDelete(G ,K1 )) ==> (event(authKeyid(K1 )) ||99 (inj-event(genToken(R,K1 ,K2 )) && event(authKeyidDeleg(K2 )) )).

100101 (* Neueinstellung nur nach individueller Beantragung GS-P4 *)102 query H :bitstring,K :bitstring; inj-event(grammarInsert(H ,K )) ==>103 inj-event(insertRequest(H ,K )).104105 (* Löschen nur nach individueller Beantragung GS-P5 *)106 query H :bitstring,K :bitstring; inj-event(grammarDelete(H ,K )) ==>107 inj-event(deleteRequest(H ,K )).108109 (* für jede Token-Erstellung liegt genau eine Anfrage (entweder110 direkt oder mit Delegation vor GS-P6 *)111 query R:bitstring,K1 :bitstring,K2 :bitstring;112 inj-event(genToken(R,K1 ,K2 )) ==> inj-event(reqToken(R,K1 )) ||113 inj-event(reqDelegToken(R,K1 )).114115 (* Tabellen zur vertrauenswürdigen Speicherung von Daten *)116 (* ’authorized’ enthält autorisierte Identitäten und deren zusätzlichen Rechte *)117 (* keyid, pubkey, tokreq, delegate *)118 table authorized(bitstring, pskey, bool, bool).119120 (* Tabelle zur Speicherung von Tokens *)121 (* keyid, token *)122 table tokens(bitstring, bitstring).123124 (* Grammatikdatenbank *)125 (* hash, Grammatik, Eigentümer *)126 table grammars(bitstring, bitstring, bitstring).127128 (* Grammatikserver zur Verarbeitung geschützter Grammatiken *)129 let processG(sskG : sskey) =130 (* empfange Startnachricht *)131 in(net, (= initReqT, keyid :bitstring));132 (* schicke Anfangswert *)133 new r0 :bitstring;134 out(net, (initRespT, keyid , r0 ));135 (* empfange eine Nachricht *)136 in(net,msg :bitstring);137 (* P0: zerlege Nachricht und prüfe auf r0 und keyid *)138 let (= reqT,= r0 , r1 :bitstring, delegKey :pskey,= keyid) = getsigneddata(msg) in139 (* P1: prüfe die Autorisierung und hole zugehörigen öffentlichen Schlüssel *)140 get authorized(= keyid , pubkey :pskey,= true, delegRight :bool) in


141 (* P2: prüfe Signatur der Daten *)142 let (= reqT,= r0 ,= r1 ,= delegKey ,= keyid) = checksign(msg , pubkey) in143 (* erzeuge neuen Token *)144 new token:bitstring;145 if (kidhash(delegKey) = keyid) || (delegRight = true) then (* Delegationsrecht *)146 (147 event genToken(r1 , kidhash(delegKey), keyid);148 (* sende Token zurück *)149 out(net, sign((respT, r1 , token), sskG));150151 (* empfange eine Nachricht *)152 in(net,msg2 : bitstring);153 (* P5: zerlege Nachricht und prüfe auf token und keyid *)154 let (= addHG, grammarHash:bitstring,155 G :bitstring,156 = token,157 = kidhash(delegKey)) = getsigneddata(msg2 ) in158 (159 (* P6: prüfe Signatur *)160 let (= addHG,= grammarHash,= G ,= token,= kidhash(delegKey)) =161 checksign(msg2 , delegKey) in162 (* stelle Grammatik ein *)163 event grammarInsert(grammarHash, kidhash(delegKey));164 insert grammars(grammarHash,G , kidhash(delegKey))165 (* P5’: zerlege Nachricht und prüfe auf token und keyid *)166 ) else let (= delG, grammarHash:bitstring,167 = token,168 = kidhash(delegKey)) = getsigneddata(msg2 ) in169 (170 (* P6’: prüfe Signatur *)171 let (= delG,= grammarHash,= token,= kidhash(delegKey)) =172 checksign(msg2 , delegKey) in173 (* P8: prüfe Besitzer der Grammatik *)174 get grammars(= grammarHash,G :bitstring,= kidhash(delegKey)) in175 event grammarDelete(grammarHash, kidhash(delegKey))176 )177 )178 .179180 let processGreqG =181 (* empfange Request für Grammatik *)182 in(net, (= reqG, grammarHash:bitstring));183 (* hole Grammatik aus Datenbank *)184 get grammars(= grammarHash,G :bitstring, owner :bitstring) in185 (* generiere Antwort *)186 out(net, (respG,G))187 .188189 let processCreqT (sskC : sskey, pskG : pskey) =190 (* beginne Token-Anforderung *)191 out(net, (initReqT, kidhash(psk(sskC ))));

179

192 (* empfange Init-Antwort des Servers *)193 in(net, (= initRespT,= kidhash(psk(sskC )), r0 :bitstring));194 (* neuer Zufallswert für Request *)195 new r1 :bitstring;196 event reqToken(r1 , kidhash(psk(sskC )));197 (* sende signierten Request an Server *)198 out(net, sign((reqT, r0 , r1 , psk(sskC ), kidhash(psk(sskC ))), sskC ));199 (* empfange Antwortnachricht *)200 in(net,msg :bitstring);201 (* P3: prüfe auf r1 *)202 (* P4: prüfe Signatur gegen Schlüssel von G *)203 let(= respT,= r1 , token:bitstring) = checksign(msg , pskG) in204 (* C sendet Token an sich selbst *)205 out(net, (kidhash(psk(sskC )), token))206 .207208 let processDreqT (sskD : sskey, pskG : pskey, delegKey :pskey) =209 (* Angreifer kann den Delegierten bestimmen *)210 (* in(net,delegKey:pskey); *)211 (* beginne Token-Anforderung *)212 out(net, (initReqT, kidhash(psk(sskD))));213 (* empfange Init-Antwort des Servers *)214 in(net, (= initRespT,= kidhash(psk(sskD)), r0 :bitstring));215 (* neuer Zufallswert für Request *)216 new r1 :bitstring;217 event reqDelegToken(r1 , kidhash(delegKey));218 (* sende signierten Request an Server *)219 out(net, sign((reqT, r0 , r1 , delegKey , kidhash(psk(sskD))), sskD));220 (* empfange Antwortnachricht *)221 in(net,msg :bitstring);222 (* P3: prüfe auf r1 *)223 (* P4: prüfe Signatur gegen Schlüssel von G *)224 let(= respT,= r1 , token:bitstring) = checksign(msg , pskG) in225 (* Sende Token an Delegierten (ggf. auch an C selbst) *)226 out(net, (kidhash(delegKey), token))227 .228229230 let processCaddHG(sskC :sskey, pskG :pskey,G :bitstring,GK :symkey) =231 (* Lese Token für C-Prozess ein *)232 in(net, (= kidhash(psk(sskC )), token:bitstring));233 event insertRequest(hash(G), kidhash(psk(sskC )));234 (* schicke signierte Nachricht mit verschlüsselter Grammatik *)235 out(net, sign((addHG, hash(G), senc(G ,GK ), token, kidhash(psk(sskC ))), sskC ))236 .237238 let processCreqG(grammarHash:bitstring,GK :symkey) =239 (* Sende Grammatik-Anfrage *)240 out(net, (reqG, grammarHash));241 (* empfange Antwort mit verschlüsselter Grammatik *)242 in(net, (= respG,= grammarHash, cipher :bitstring));


243 (* entschlüssele Grammatik *)244 let G :bitstring = sdec(cipher ,GK ) in245 event gotGrammar(G)246 .247248 let processCdelG(sskC :sskey, grammarHash:bitstring) =249 (* Lese Token für C-Prozess ein *)250 in(net, (= kidhash(psk(sskC )), token:bitstring));251 event deleteRequest(grammarHash, kidhash(psk(sskC )));252 (* schicke signierten Löschauftrag *)253 out(net, sign((delG, grammarHash, token, kidhash(psk(sskC ))), sskC ))254 .255256 (* Definition des Gesamtsystems *)257 process258 (* erzeuge Signaturschlüssel für Client-Prozess C *)259 new sskC :sskey;260 let pskC :pskey = psk(sskC ) in261 out(net, pskC );262263 (* erzeuge Signaturschlüssel für Client-Prozess D *)264 new sskD :sskey;265 let pskD :pskey = psk(sskD) in266 out(net, pskD);267268 (* Schlüssel für den Grammatikdienst *)269 new sskG :sskey;270 let pskG :pskey = psk(sskG) in271 out(net, pskG);272273 (* erzeuge symmetrischen Schlüssel für Grammatikverschlüsselung *)274 new GK :symkey;275 (* neue Grammatik *)276 new G :bitstring;277278 (* erzeuge Schlüsselpaar für den Angreifer und stelle es zur279 Verfügung *)280 new sskA:sskey;281 let pskA:pskey = psk(sskA) in282 out(net, sskA);283 out(net, pskA);284285 (* Autorisierungen für C, D und Angreifer *)286 insert authorized(kidhash(psk(sskC )), psk(sskC ), true, false);287 event authKeyid(kidhash(psk(sskC )));288 (* event authKeyidDeleg(kidhash(psk(sskC))); *)289 (* Variante: Instanz D erhält Delegationsrecht ->290 Parameter auf true setzen , events einkommentieren*)291 insert authorized(kidhash(psk(sskD)), psk(sskD), false, false);292 (* event authKeyid(kidhash(psk(sskD))); *)293 (* event authKeyidDeleg(kidhash(psk(sskD))); *)294 (* Variante: Angreifer wird ebenfalls mit Rechten ausgestattet ->

181

295 Parameter auf true setzen, events einkommentieren *)296 insert authorized(kidhash(psk(sskA)), psk(sskA), false, false);297 (* event authKeyid(kidhash(psk(sskA))); *)298 (* event authKeyidDeleg(kidhash(psk(sskA))); *)299300 (* Alle Teilprozesse unter Replikation instantiieren *)301 !processG(sskG) |302 !processCreqT (sskC , pskG) |!processDreqT (sskD , pskG , pskC ) |303 !processCaddHG(sskC , pskG ,G ,GK ) |304 !processCreqG(hash(G),GK ) |!processGreqG |!processCdelG(sskC , hash(G))305


Literaturverzeichnis

[AB05] ABADI, MARTÍN and BRUNO BLANCHET: Analyzing security protocols with se-crecy types and logic programs. Journal of the ACM, 52:102–146, January 2005.

[AF01] ABADI, MARTÍN and CÉDRIC FOURNET: Mobile values, new names, and securecommunication. Proceedings of the 28th Annual ACM Symposium on Principlesof Programming Languages (POPL0́1), pages 104–115, 2001.

[AG99] ABADI, MARTÍN and ANDREW D. GORDON: A calculus for cryptographic proto-cols: The spi calculus. Information and Computation, 148:36–47, 1999.

[AT91] ABADI, MARTÍN and MARK R. TUTTLE: A semantics for a logic of authenti-cation. In Proceedings of the Tenth Annual ACM Symposium on Principles ofDistributed Computing, pages 201–216. ACM Press, August 1991.

[BAF08] BLANCHET, BRUNO, MARTÍN ABADI, and CÉDRIC FOURNET: Automated ver-ification of selected equivalences for security protocols. Journal of Logic andAlgebraic Programming, 75(1):3–51, Feb–Mar 2008.

[Bal93] BALENSON, D.: Privacy Enhancement for Internet Electronic Mail: Part III: Al-gorithms, Modes, and Identifiers. RFC 1423 (Historic), February 1993.

[BAN89] BURROWS, MICHAEL, MARTÍN ABADI, and ROGER NEEDHAM: A Logic of Au-thentication. Proceedings of the Royal Society of London, Series A, Mathematicaland Physical Sciences, 426(1871):233–271, December 1989.

[BBC+07] BERGLUND, ANDERS, SCOTT BOAG, DON CHAMBERLIN, MARY F. FERNÁN-DEZ, MICHAEL KAY, JONATHAN ROBIE, and JÉRÔME SIMÉON: W3c recom-mendation: Xml path language (xpath) 2.0. http://www.w3.org/TR/2007/REC-xpath20-20070123/, January 2007.

[BBF+08] BARTEL, MARK, JOHN BOYER, BARB FOX, BRIAN LAMACCHIA, and ED SI-MON: XML-Signature Syntax and Processing. World Wide Web Consortium(W3C), http://www.w3.org/TR/xmldsig-core/, 10. June 2008.

183

184 LITERATURVERZEICHNIS

[BDPA09] BERTONI, GUIDO, JOAN DAEMEN, MICHAËL PEETERS, and GILLES VAN ASS-CHE: The road from panama to keccak via radiogatún. In HANDSCHUH, HELENA,STEFAN LUCKS, BART PRENEEL, and PHILLIP ROGAWAY (editors): SymmetricCryptography, number 09031 in Dagstuhl Seminar Proceedings, Dagstuhl, Ger-many, 2009. Schloss Dagstuhl - Leibniz-Zentrum fuer Informatik, Germany.

[BFG07] BECKER, MORITZ Y., CEDRIC FOURNET, and ANDREW D. GORDON: Designand semantics of a decentralized authorization language. In 20th IEEE ComputerSecurity Foundations Symposium (CSF), pages 3–15, 2007.

[BFG10] BECKER, MORITZ Y., CÉDRIC FOURNET, and ANDREW D. GORDON: Secpal:Design and semantics of a decentralized authorization language. Journal of Com-puter Security, 18(4):619–665, 2010.

[BFIK99] BLAZE, M., J. FEIGENBAUM, J. IOANNIDIS, and A. KEROMYTIS: The KeyNoteTrust-Management System Version 2. RFC 2704 (Informational), September 1999.

[BFL96] BLAZE, MATT, JOAN FEIGENBAUM, and JACK LACY: Decentralized Trust Man-agement. In Proceedings of IEEE Symposium on Security and Privacy, Oakland,May 1996. IEEE.

[Bla01] BLANCHET, BRUNO: An efficient cryptographic protocol verifier based on prologrules. In Proceedings of the 14th IEEE workshop on Computer Security Foun-dations, CSFW ’01, pages 82–96, Washington, DC, USA, 2001. IEEE ComputerSociety.

[Bla09] BLANCHET, BRUNO: Automatic verification of correspondences for security pro-tocols. Journal of Computer Security, 17:363–434, December 2009.

[Bla11] BLANCHET, BRUNO: Proverif: Cryptographic protocol verifier in the formalmodel. http://www.proverif.ens.fr/, 2011.

[Bun01a] BUNDESGESETZ: Gesetz über Rahmenbedingungen für elektronische Signaturenund zur Änderung weiterer Vorschriften. Bundesgesetzblatt Jahrgang 2001 Teil INr. 22, 21. Mai 2001.

[Bun01b] BUNDESVERORDNUNG: Verordnung zur elektronischen Signatur. Bundesgesetz-blatt I S. 3074, 16. November 2001.

[Bun02] BUNDESGESETZ: Bürgerliches Gesetzbuch in der Fassung der Bekanntmachungvom 2. Januar 2002 (BGBl. I S. 42, 2909; 2003 I S. 738). Bundesgesetzblatt, 2002.

[Bun08a] BUNDESAMT FÜR SICHERHEIT IN DER INFORMATIONSTECHNIK: BSIGrundschutz-Tool. https://www.bsi.bund.de/DE/Themen/weitereThemen/GSTOOL/gstool_node.html, 02 2008.

LITERATURVERZEICHNIS 185

[Bun08b] BUNDESAMT FÜR SICHERHEIT IN DER INFORMATIONSTECHNIK: BSI-Standard100-2: IT-Grundschutz-Vorgehensweise, Version 2.0. Bundesamt für Sicherheit inder Informationstechnik, Bonn, 2008.

[Bun08c] BUNDESAMT FÜR SICHERHEIT IN DER INFORMATIONSTECHNIK: Kryp-tographische Verfahren: Empfehlungen und Schlüssellängen (BSI-TR-02102).http://www.bsi.bund.de/literat/tr/tr02102/BSI-TR-02102.pdf, Juni 2008. Version1.0.

[Bun11] BUNDESAMT FÜR SICHERHEIT IN DER INFORMATIONSTECHNIK: IT-Grund-schutzkataloge: 12. Ergänzungslieferung, Stand 2011. https://www.bsi.bund.de,September 2011.

[CDF+07] CALLAS, J., L. DONNERHACKE, H. FINNEY, D. SHAW und R. THAYER: Open-PGP Message Format. RFC 4880 (Proposed Standard), November 2007. Updatedby RFC 5581.

[CDH+05] COOPER, M., Y. DZAMBASOW, P. HESSE, S. JOSEPH und R. NICHOLAS: InternetX.509 Public Key Infrastructure: Certification Path Building. RFC 4158 (Informa-tional), September 2005.

[CFS+03] CHOKHANI, S., W. FORD, R. SABETT, C. MERRILL und S. WU: Internet X.509Public Key Infrastructure Certificate Policy and Certification Practices Framework.RFC 3647 (Informational), November 2003.

[Cho59] CHOMSKY, NOAM: iOn Certain Formal Properties of Grammars. Information andControl, 2(2):137–167, 1959.

[CKPE05] CANTOR, SCOTT, JOHN KEMP, ROB PHILPOTT, and EVE MALER (EDS.): As-sertions and protocols for the oasis security assertion markup language (saml)v2.0. http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf, 15.March 2005.

[CKPR03] CRUELLAS, JUAN CARLOS, GREGOR KARLINGER, DENIS PINKAS, and JOHN

ROSS: XML Advanced Electronic Signatures (XAdES). World Wide Web Consor-tium (W3C), http://www.w3.org/TR/XAdES/, 20. February 2003.

[CO04] CHADWICK, DAVID W. and ALEXANDER OTENKO: Implementing Role BasedAccess Controls using X.509 Privilege Management - the PERMIS AuthorisationInfrastructure. In JERMAN-BLAZIC, BORKA, WOLFGANG SCHNEIDER, andTOMAZ KLOBUCAR (editors): Security and Privacy in Advanced Networking Tech-nologies, NATO Science Series, pages 26–39. IOS Press, unknown 2004. Proceed-ings of the NATO Advanced Networking Workshop on Advanced Security Tech-nologies in Networking, Bled, Slovenia, 15-18 September 2003.


[COB03] CHADWICK, DAVID W., ALEXANDER OTENKO, and EDWARD BALL: Role-based access control with x.509 attribute certificates. IEEE Internet Computing,07(2):62–69, March/April 2003.

[Com12] COMMON CRITERIA RECOGNITION ARRANGEMENT: Common Criteriafor Information Technology Security Evaluation – Version 3.1 Revision 4.http://www.commoncriteriaportal.org/cc/, September 2012.

[CSF+08] COOPER, D., S. SANTESSON, S. FARRELL, S. BOEYEN, R. HOUSLEY, andW. POLK: Internet X.509 Public Key Infrastructure Certificate and Certificate Re-vocation List (CRL) Profile. RFC 5280 (Proposed Standard), May 2008.

[CZO+08] CHADWICK, DAVID W, GANSEN ZHAO, SASSA OTENKO, ROMAIN LABORDE,LINYING SU, and TUAN ANH NGUYEN: PERMIS: a modular authoriza-tion infrastructure. Concurrency and Computation: Practice and Experience,20(11):1341–1357, August 2008. Online ISSN: 1532-0634.

[DAdB+11] DERAISON, RENAUD, MICHAEL ARBOI, ALEXIS DE BERNIS, AXEL NENNKER,BEIRNE KORNARKSI, and BENOIT BRODARD: Open Vulnerability AssessmentSystem (OpenVAS). http://www.openvas.org/, 2011.

[Day73] DAY, J.D.: Memo to FTP group: Proposal for File Access Protocol. RFC 520,June 1973.

[DDLS00] DAMIANOU, NICODEMOS, NARANKER DULAY, EMIL LUPU, and MORRIS SLO-MAN: Ponder: A Language for Specifying Security and Management Policies forDistributed Systems. Imperial College Research Report DoC 2000/1, October 2000.http://www-dse.doc.ic.ac.uk/Research/policies/ponder/PonderSpec.pdf.

[DHR+98] DUSSE, S., P. HOFFMAN, B. RAMSDELL, L. LUNDBLADE, and L. REPKA:S/MIME Version 2 Message Specification. RFC 2311 (Historic), March 1998.

[DHRW98] DUSSE, S., P. HOFFMAN, B. RAMSDELL, and J. WEINSTEIN: S/MIME Version 2Certificate Handling. RFC 2312 (Historic), March 1998.

[Dow03] DOWNNARD, IAN: Public-key cryptography extensions into kerberos. IEEE Po-tentials, 21(5):30–34, Januar 2003.

[DY83] DOLEV, D. and A. C. YAO: On the security of public key protocols. IEEE Trans-actions on Information Theory, IT29(12):198–208, March 1983.

[Ecl] ECLIPSE FOUNDATION: Xtext project. http://www.eclipse.org/Xtext/.

[EFL+99] ELLISON, C., B. FRANTZ, B. LAMPSON, R. RIVEST, B. THOMAS, and T. YLO-NEN: SPKI Certificate Theory. RFC 2693 (Experimental), September 1999.


[ets12] Electronic Signatures and Infrastructures (ESI) – CMS Advanced Electronic Signa-tures (CAdES). Technical Report ETSI TS 101 733 V2.1.1, European Telecommu-nications Standards Institute, March 2012. 2012.

[EU-00] EU-DIREKTIVE: Directive 1999/93/ec of the european parliament and of the coun-cil of 13 december 1999 on a community framework for electronic signatures. Of-ficial Journal of the European Communities L13/12, 19. January 2000.

[Eur07] EUROPEAN TELECOMMUNICATIONS STANDARDS INSTITUTE (ETSI): Elec-tronic Signatures and Infrastructures (ESI) – Policy requirements for certificationauthorities issuing qualified certificates. ETSI TS 101 456 V1.4.3 (2007-05), Mai2007.

[Eur09] EUROPEAN TELECOMMUNICATIONS STANDARDS INSTITUTE: Electronic Sig-natures and Infrastructures (ESI) – PDF Advanced Electronic Signature Profiles.www.etsi.org, Juli 2009.

[FHT10] FARRELL, S., R. HOUSLEY, and S. TURNER: An Internet Attribute CertificateProfile for Authorization. RFC 5755 (Proposed Standard), January 2010.

[FK92] FERRAIOLO, D. and R. KUHN: Role-based access controls. In Proceedings of15th NIST-NCSC National Computer Security Conference, pages 554–563, October1992.

[Fri06] FRIEDL, JEFFREY: Mastering Regular Expressions. O’Reilly Media, Inc., 2006.

[Gam85] GAMAL, TAHER EL: A public key cryptosystem and a signature scheme based ondiscrete logarithms. In Proceedings of CRYPTO 84 on Advances in cryptology,pages 10–18, New York, NY, USA, 1985. Springer-Verlag New York, Inc.

[GJ90] GRUNE, D. and C.J.H. JACOBS: Parsing techniques: a practical guide. EllisHorwood series in computers and their applications. Ellis Horwood, 1990.

[GNY90] GONG, LI, ROGER NEEDHAM, and RAPHAEL YAHALOM: Reasoning about Beliefin Cryptographic Protocols. In Proceedings of the IEEE Symposium on Securityand Privacy, pages 234–248, Oakland, California, May 1990. IEEE.

[Gro03] GROSS, THOMAS: Security Analysis of the SAML Single Sign-on Browser/Arti-fact Profile. In Proceedings of the 19th Annual Computer Security ApplicationsConference, Las Vegas, Nevada, December 8-12 2003. Applied Computer SecurityAssociates.

[HK00] HOWELL, JON and DAVID KOTZ: A Formal Semantics for SPKI. Technical ReportTR2000-363, Dartmouth College, Computer Science, Hanover, NH, March 2000.

[Hoa85] HOARE, CHARLES ANTONY RICHARD: Communicating Sequential Processes.Prentice Hall, 1985.


[Hof99] HOFFMAN, P.: Enhanced Security Services for S/MIME. RFC 2634 (ProposedStandard), June 1999. Updated by RFC 5035.

[Hou07] HOUSLEY, R.: Cryptographic Message Syntax (CMS) Multiple Signer Clarifica-tion. RFC 4853 (Proposed Standard), April 2007.

[Hou09] HOUSLEY, R.: Cryptographic Message Syntax (CMS). RFC 5652 (Standard),September 2009.

[Int08] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (ISO): ISO 32000-1:2008 – Document management – Portable document format – Part 1: PDF 1.7.ISO Standard, 2008.

[ISO89] ISO 8807: Information processing systems – Open Systems Interconnection – LO-TOS – A formal description technique based on the temporal ordering of observa-tional behaviour. International Standard Organization, Geneva, 1989.

[ISO04] ISO/IEC: ISO/IEC 10118-3:2004 – Hash-functions – Part 3: Dedicated hash-functions, 2004.

[IT05] ITU-T: Recommendation X.509 / ISO/IEC 9594-8: Information Technology -Open Systems Interconnection - The Directory: Public-key and attribute certificateframeworks, 8 2005.

[jCPB+12] CHANG, SHU JEN, RAY PERLNER, WILLIAM E. BURR, MELTEM SÃ¶NMEZ

TURAN, JOHN M. KELSEY, SOURADYUTI PAUL, and LAWRENCE E. BASSHAM:Third-round report of the sha-3 cryptographic hash algorithm competition. Tech-nical Report NISTIR 7896, National Institute of Standards and Technology (NIST),November 2012. http://dx.doi.org/10.6028/NIST.IR.7896.

[JMV01] JOHNSON, DON, ALFRED MENEZES, and SCOTT VANSTONE: The Elliptic CurveDigital Signature Algorithm (ECDSA). International Journal of Information Secu-rity, 1(1):36–63, July 001. DOI: 10.1007/s102070100002.

[Kal93] KALISKI, B.: Privacy Enhancement for Internet Electronic Mail: Part IV: KeyCertification and Related Services. RFC 1424 (Historic), February 1993.

[Kal98] KALISKI, B.: PKCS #7: Cryptographic Message Syntax Version 1.5. RFC 2315(Informational), March 1998.

[Kec00] KECK, DIRK OLIVER: Erkennung von Wechselwirkungen zwischen Mehrwertdien-sten durch Analyse ihrer Konfigurationen und Protokollabläufe – 79. Bericht überverkehrstheoretische Arbeiten. Dissertation, Universität Stuttgart, 2000.

[Kem89] KEMMERER, RICHARD A.: Analyzing Encryption Protocols Using Formal Verifi-cation Techniques. IEEE Journal on Selected Areas in Coimmunications, 7(4):448–457, May 1989.


[Ken93] KENT, S.: Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management. RFC 1422 (Historic), February 1993.

[KMV00] KOBLITZ, NEAL, ALFRED MENEZES, and SCOTT VANSTONE: The state of ellip-tic curve cryptography. Des. Codes Cryptography, 19:173–193, March 2000.

[KN93] KOHL, J. and C. NEUMAN: The Kerberos Network Authentication Service (V5).RFC 1510 (Proposed Standard), September 1993. Obsoleted by RFC 4120.

[Lin93] LINN, J.: Privacy Enhancement for Internet Electronic Mail: Part I: MessageEncryption and Authentication Procedures. RFC 1421 (Historic), February 1993.

[Low96] LOWE, GAVIN: Breaking and fixing the Needham-Schroeder public-key protocolusing FDR. In Tools and Algorithms for the Construction and Analysis of Systems,volume 1055 of Lecture Notes on Computer Science, pages 147–166. Springer,1996.

[LPS05] LINSENBARDT, D., S. PONTIUS, and A. STURGEON: Internet X.509 Public KeyInfrastructure Warranty Certificate Extension. RFC 4059 (Informational), May2005.

[MAM+99] MYERS, M., R. ANKNEY, A. MALPANI, S. GALPERIN, and C. ADAMS: X.509Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP. RFC2560 (Proposed Standard), June 1999. Updated by RFC 6277.

[Mil80] MILNER, ROBIN: A Calculus of Communicating Systems, volume 92 of LectureNotes in Computer Science. Springer, 1980.

[Min08] MINVIELLE, ROBERT: Linux security auditing tool (lsat).http://usat.sourceforge.net/, April 2008.

[Mos05] MOSES, TIM: eXtensible Access control Markup Language (XACML) Version2.0. http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-core-spec-os.pdf, February 2005.

[MPW92] MILNER, ROBIN, JOACHIM PARROW, and DAVID WALKER: A calculus of mobileprocesses, parts i and ii. Inf. Comput., 100(1):1–77, September 1992.

[MvOV96] MENEZES, A., P. VAN OORSCHOT, and S. VANSTONE: Handbook of AppliedCryptography. CRC Press, 1996.

[Mye98] MYERS, MICHAEL: Revocation: Options and challenges. In HIRSCHFELD, R.(editor): Proceedings of Financial Cryptography: Second International Confer-ence, FC’98, Anguilla, British West Indies, volume 1465 of Lecture Notes in Com-puter Science, page 165ff, Heidelberg, February 1998. Springer-Verlag.


[Nat94] NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY (NIST): Digital Sig-nature Standard (DSS). Number 186 in Federal Information Processing StandardsPublications (FIPS PUBS). National Institute of Standards and Technology (NIST),Geitherburg, MD, USA, May 1994.

[Nat02] NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY (NIST): SecureHash Standard. Number 180-2 in Federal Information Processing Standards Pub-lications (FIPS PUBS). National Institute of Standards and Technology (NIST),Geitherburg, MD, USA, August 2002.

[Nat04] NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY (NIST): SecureHash Standard, Change Notice 1. Number 180-2 in Federal Information Pro-cessing Standards Publications (FIPS PUBS). National Institute of Standards andTechnology (NIST), Geitherburg, MD, USA, Februar 2004.

[NE11] NAGIOS ENTERPRISES, LLC. http://www.nagios.com/, 2011.

[NT94] NEUMAN, B. CLIFFORD and THEODORE TS‘O: Kerberos: An AuthenticationService for Computer Networks. IEEE Communications Magazine, 32(9):33–38,September 1994.

[NYHR05] NEUMAN, C., T. YU, S. HARTMAN, and K. RAEBURN: The Kerberos NetworkAuthentication Service (V5). RFC 4120 (Proposed Standard), July 2005. Updatedby RFCs 4537, 5021, 5896, 6111, 6112, 6113.

[Oxf10] OXFORD UNIVERSITY COMPUTING LABORATORY: Failures-Divergence Refinement - FDR2 User Manual, October 2010.http://web.comlab.ox.ac.uk/projects/concurrency-tools/.

[Par07] PARR, TERENCE: The Definitive ANTLR Reference: Building Domain-SpecificLanguages. Pragmatic Programmers. Pragmatic Bookshelf, first edition, May2007.

[PCI10] PCI SECURITY STANDARDS COUNCIL: Payment Card Industry (PCI) – Daten-sicherheitsstandard – Anforderungen und Sicherheitsbeurteilungsverfahren. htt-ps://www.pcisecuritystandards.org/documents/pci_dss_v2.pdf, October 2010.

[PL10] PARDUCCI, BILL and HAL LOCKHART: eXtensible Access control Markup Lan-guage (XACML) Version 2.0. http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-cs-01-en.pdf, August 2010.

[PMH96] PETERSEN, HOLGER, MARKUS MICHELS und PATRICK HORSTER: Taxonomiedigitaler Signaturkonzepte. In: Proceedings Digitale Signaturen, Darmstadt, 1996.Vieweg Verlag.

[RSA78] RIVEST, R. L., A. SHAMIR und L. ADLEMAN: A method for obtaining digitalsignatures and public-key cryptosystems. Commun. ACM, 21(2):120–126, 1978.


[RSA93] RSA SECURITY INC.: PKCS #7 v1,5: RSA Cryptographic Message Syntax Stan-dard. ftp://ftp.rsasecurity.com/pub/pkcs/ps/pkcs-7.ps, November 1993. RSA Se-curity Inc. Public-Key Cryptography Standards (PKCS).

[RSA12] RSA LABORATORIES, EMC CORPORATION: PKCS #1 v2.2: RSA Cryptogra-phy Standard. http://www.rsa.com/rsalabs/pkcs/files/h11300-wp-pkcs-1v2-2-rsa-cryptography-standard.pdf, October 2012. EMC Corporation Public-Key Cryptog-raphy Standards (PKCS).

[SC01] SYVERSON, PAUL and ILIANO CERVESATO: The Logic of Authentication Proto-cols. In FOCARDI, R. and R. GORRIERI (editors): Foundations of Security Anal-ysis and Design — FOSAD’00, number 2171 in LNCS, pages 63–136. Springer-Verlag, 2001.

[Sch01] SCHRÖER, FRIEDRICH WILHELM: AMBER, An Ambiguity Checker for Context-free Grammars. Technical report, Fraunhofer Institute for Computer Architectureand Software Technology, 2001. http://accent.compilertools.net/Amber.html.

[Sch07] SCHAAD, J.: Enhanced Security Services (ESS) Update: Adding CertID AlgorithmAgility. RFC 5035 (Proposed Standard), August 2007.

[SNP04] SANTESSON, S., M. NYSTROM, and T. POLK: Internet X.509 Public Key Infras-tructure: Qualified Certificates Profile. RFC 3739 (Proposed Standard), March2004.

[SO96] SYVERSON, PAUL F. and PAUL C. VAN OORSCHOT: A Unified CryptographicProtocol Logic. Technical report, NRL Publication 5540-227, Naval ResearchLab, 1996.

[Ten11] TENABLE NETWORK SECURITY: Nessus vulnerability scanner.http://www.tenable.com/products/nessus, 2011.

[TT09] T7 E.V. and TELETRUST E.V.: Common PKI Specifications for Interoperable Ap-plications. http://www.t7ev.org/uploads/media/Common-PKI_v2.0.pdf, 20. Jan-uary 2009.

[Tur00] TURNBULL, JIM: Cross-Certification and PKI Policy Networking.http://www.entrust.com/resources/pdf/cross_certification.pdf, August 2000.

[vH11] HAUGWITZ, HANNES VON: Advanced Intrusion Detection Environment.http://aide.sourceforge.net/, 2011.

[Vin02] VINCK, BART: USECA: UMTS Security Architecture. ReportAC336/ATEA/WP23/DS/P/08/1, Advanced Communications Technologies &Services Programme (ACTS), March 2002.


[vO93] OORSCHOT, PAUL C. VAN: Extending cryptographic logics of belief to key agree-ment protocols. In Proceedings of the 1st ACM Conference on Computer andCommunications Security, pages 233–243. ACM Press, November 1993.

[WKH97] WAHL, M., S. KILLE, and T. HOWES: Lightweight Directory Access Protocol(v3): UTF-8 String Representation of Distinguished Names. RFC 2253 (ProposedStandard), December 1997. Obsoleted by RFCs 4510, 4514, updated by RFC 3377.

[WVH05] WANG, J., D. D. VECCHIO, and M. HUMPHREY: Extending the Security AssertionMarup Language to Support Delegation for Web Services and Grid Services. InProceedings of the International Conference on Web Services, Orlando, Florida,USA, 1005.

[ZT06] ZHU, L. and B. TUNG: Public Key Cryptography for Initial Authentication in Ker-beros (PKINIT). RFC 4556 (Proposed Standard), June 2006. Updated by RFC6112.

Date post:	15-Aug-2019
Category:	Documents
Upload:	ngokhanh
View:	215 times
Download:	0 times

Grammatikbasierte Zertiﬁkate am Beispiel von ... · dem XPath-Standard aus den Namen der in den...

Documents