Public-Key-Infrastrukturen - CDC - Technische Universität Darmstadt

Transcription

T ECHNISCHE U NIVERSITÄT DARMSTADT
FACHGEBIET T HEORETISCHE I NFORMATIK
P ROF. D R . J. B UCHMANN
J. B RAUN
7. Übung zur Vorlesung
Public-Key-Infrastrukturen
Sommersemester 2012
Aufgabe 1: Smartcards
Wir betrachten folgendes Szenario: Sie wollen auf Ihrem PC eine E-Mail verschicken und diese zur Wahrung der Authentizität
digital signieren. Zur Erstellung der Signatur verwenden Sie eine Smartcard mit einem geeigneten Signaturschlüssel und ein
Kartenlesegerät (Class 3) mit eingebauter Tastatur und einem Display (2*12 Zeichen). Sie erstellen also zunächst die E-Mail in
Ihrem Mailclient und setzen dann den Signiervorgang in Gang. Skizzieren Sie den Verlauf der Signaturerstellung! Insbesondere
soll daraus hervorgehen, welche Daten wo errechnet werden, wohin sie übertragen werden und in welcher Reihenfolge dies
geschieht.
Aufgabe 2: Smartcards (2)
Die Smartcard „E4 NetKey“ der Firma Telesec wird, wie in den Folien beschrieben, mit drei Schlüsselpaaren ausgeliefert. Dabei
ist je eines für die Erlangung der Schutzziele Authentizität (z.B. Zugriff auf eine Webseite via SSL mit Clientauthentifizierung),
Nicht-Abstreitbarkeit (z.B. Signatur eines Kaufvertrages) und Vertraulichkeit (z.B. verschlüsselte E-Mail) gedacht.
Warum ist das sinnvoll?
Überlegen Sie sich dafür, wie und wann die privaten Schlüssel jeweils eingesetzt werden!
Aufgabe 3: Gültigkeitszeitraum
Benutzen Sie für Ihre Antworten auch die Spezifikationen der Zertifikate und Sperrlisten im RFC 5280. Diese finden Sie unter
http://www.ietf.org/rfc/rfc5280.txt oder auf der PKI-Homepage.
a) Nennen Sie die Gültigkeitszeiträume der unten angegebenen Zertifikate.
b) Müssen diese mit den Gültigkeitszeiträumen der Schlüssel übereinstimmen? Bewerten Sie dabei die keyUsage-Extension
sowie die Informationen der CRL.
1
Serial No.:
Issuer:
NotBefore:
NotAfter:
Subject:
Public Key:
X509v3Extensions:
Subject Alternative Name:
Key Usage:
Certificate Policy:
Subject Key Identifier:
Authority Key Identifier:
Zertifikat 1
2593
CN=Uebung CA, OU=FB Informatik, O=TU Darmstadt, C=DE
Jun 2 09:43:55 2004 GMT
Jun 1 22:00:00 2005 GMT
CN=Bob, OU=CDC, OU=FB Informatik, O=TU Darmstadt, C=DE
key-0x4599AB34
email:bob@cdc.informatik.tu-darmstadt.de
critical
Digital Signature
not critical
1.3.6.1.4.1.8301.1.1.1.3
keyIdentifier:99:13:D5:FD:90:31:7B:56:7F:BD
keyIdentifier:0B:F8:2B:B7:B5:88:C8:03:7E:EB
authorityCertIssuer:CN=Master CA, OU=FB Informatik, O=TU Darmstadt, C=DE
authorityCertSerialNumber:03
Signature:
verifiable with 0xC37C64C0 (SHA1withRSA)
Serial No.:
Issuer:
NotBefore:
NotAfter:
Subject:
Public Key:
X509v3Extensions:
Key Usage:
Certificate Policy:
Zertifikat 2
2594
Jun 2 09:43:55 2004 GMT
Jun 1 22:00:00 2005 GMT
CN=Alice, OU=CDC, OU=FB Informatik, O=TU Darmstadt, C=DE
key-0x7773B534
email:alice@cdc.informatik.tu-darmstadt.de
critical
Encryption
not critical
1.3.6.1.4.1.8301.1.1.1.3
keyIdentifier:A2:F4:67:23:28:C2:C8:64:A8:45
Signature:
2
Serial No.:
Issuer:
NotBefore:
NotAfter:
Subject:
Public Key:
X509v3Extensions:
Key Usage:
Certificate Policy:
Zertifikat 3
2595
Apr 25 09:00:00 2005 GMT
Apr 25 09:00:00 2006 GMT
CN=Alice’s New Name, OU=CDC, OU=FB Informatik, O=TU Darmstadt, C=DE
key-0x7773B534
email:alice.new.name@cdc.informatik.tu-darmstadt.de
critical
Encryption
not critical
1.3.6.1.4.1.8301.1.1.1.3
keyIdentifier:A2:F4:67:23:28:C2:C8:64:A8:45
Signature:
Serial No.:
Issuer:
NotBefore:
NotAfter:
Subject:
Public Key:
X509v3Extensions:
Basic Constraints:
Key Usage:
Certificate Policy:
Zertifikat 4
1
CN=Master CA, OU=FB Informatik, O=TU Darmstadt, C=DE
Dec 1 08:59:59 2002 GMT
Dec 1 08:59:59 2007 GMT
key-0xA0906E89
critical
CA: TRUE
pathlen=1
critical
Digital Signature, Certificate Sign, CRL Sign
not critical
1.3.6.1.4.1.8301.1.1.1.3
keyIdentifier:54:23:AA:12:AB:CD:4E:5F:3A:11
Signature:
verifiable with 0xA0906E89 (SHA1withRSA)
3
Serial No.:
Issuer:
NotBefore:
NotAfter:
Subject:
Public Key:
X509v3Extensions:
Basic Constraints:
Key Usage:
Certificate Policy:
Zertifikat 5
3
Dec 1 09:34:55 2002 GMT
Dec 1 09:34:55 2007 GMT
key-0xC37C64C0
critical
CA: TRUE
pathlen=0
critical
Digital Signature, Certificate Sign, CRL Sign
not critical
1.3.6.1.4.1.8301.1.1.1.3
Signature:
verifiable with 0xA0906E89 (SHA1withRSA)
CRL A
Issuer:
ThisUpdate:
Apr 25 11:53:09 2005 GMT
NextUpdate:
May 25 11:53:09 2005 GMT
Revoked Certificates:
Serial Nr.:
2594
Revocation Date: Apr 25 08:55:36 2005 GMT
Reason:
Affiliation Changed
Serial Nr.:
2595
Revocation Date: Apr 25 11:52:39 2005 GMT
Reason:
keyCompromise
X509v2 CRL Extensions:
CRLNumber:
non-critical
500
Signature:
verifiable with 0xC37C64C0
Aufgabe 4: CRLs kombinieren
Folgende Notation wird in dieser Übung benutzt:
• F 12 ist die Full-CRL mit der CRLNumber 12.
• ∆45
30 ist die ∆-CRL mit der CRLNumber 45 und hat als Basis-CRL die CRL mit der CRLNumber 30.
Bei der Bearbeitung von Full-CRLs oder ∆-CRLs gelten folgende Regeln:
F x + ∆wy ` F y (wenn x ≥ w und y ≥ x )
(
F +F `
x
y
Fx
x≥y
y
x<y
F
(1)
(2)
4
Beantworten Sie mit Hilfe dieser Regeln, ob ein Benutzer vollständige Revokationsinformationen für den Zeitpunkt
thisUpdate der Full-CRL #14 hat. Falls nein, fügen Sie genau eine CRL (ausgenommen F 14 ) ein, damit das möglich
ist.
12
15
a) {F 1 , ∆51 , ∆10
5 , ∆10 , ∆10 }
b) {F 1 , ∆51 , F 5 , F 12 , ∆14
10 }
14
15
c) {F 1 , ∆52 , ∆10
5 , ∆12 , ∆10 }
Aufgabe 5: Neues Modell
In einer vorherigen Übung wurde ein formales Modell (Modell von Maurer) für ein Web of Trust vorgestellt. Zur Erinnerung:
Dieses Modell bietet die Möglichkeit, sich der Authentizität des öffentlichen Schlüssels eines Kommunikationspartners zu versichern. Dies geschieht, indem eine Person selbst schon andere authentische Schlüssel kennt, Personen als vertrauenswürdig
ansieht oder Zertifikate und Empfehlungen zu Hilfe nimmt. Dieses Modell reicht nicht aus, um reale Gegebenheiten bzw. Systeme aus der Praxis zu modellieren. Es ist zwar simpel und flexibel, erfährt aber Grenzen in seiner Anwendbarkeit. Denn gewisse
Aspekte, die uns in der Realität begegnen, lassen sich mit dem Modell von Maurer nicht darstellen. Wir diskutieren kurz die
Eigenschaften dieses Modells und deren Begrenzungen:
• Es legt großen Wert auf die Authentizität eines öffentlichen Schlüssels. Allerdings ist die Verbindlichkeit zwischen öffentlichem Schlüssel und den Informationen im Zertifikat von großer Bedeutung.
• Ohne die Zeit als Dimension können die zeitlichen Veränderungen in der PKI (Auslauf von Glauben/Zertifikaten, Revokationen) nicht im Modell abgebildet werden.
• Die Delegierung von einzelnen Attributen des Zertifikats ist nicht möglich. Entweder wird alles (per Recommendation)
weitergegeben oder nichts. In der Praxis kann es aber durchaus sinnvoll sein, nur bestimmte Eigenschaften (Properties)
weiterzugeben.
• Die Verifikation liegt außerhalb der Betrachtung. Durch Ableitungsregeln werden falsche Schlussfolgerungen ermöglicht,
wenn ein Zertifikat nicht mehr gültig ist.
Wegen der oben genannten Nachteile halten es die Autoren von „Modeling Public Key Infrastructure in the RealWorld“1 für
zweckmäßig, das Modell zu erweitern, und führen ein neues Konzept ein, welches den Anforderungen realer PKI-Systeme
besser gerecht wird.
Folgende Elemente sind im Rahmen der Erweiterung des Modells hinzugekommen:
• Die Authentizität des öffentlichen Schlüssels wird verallgemeinert, um die Verbindlichkeit zwischen öffentlichem Schlüssel und den Zertifikatseigenschaften zu erfassen.
• Die Zeit wird als Merkmal hinzugefügt, um Revokation und Auslauf modellieren zu können. Hierzu werden zwei Konzepte vorgestellt.
– Die Lebensdauer (lifespan) einer Aussage (statement) s ist gegeben durch ein Intervall I , das vom Zeitpunkt t j
bis zum Zeitpunkt t k reicht, also I = [t j , t k ]. Zum Zeitpunkt t > t k ist s abgelaufen und in Berechnungen nicht
mehr benutzbar.
– s ist aktiv zum Zeitpunkt t nur dann, wenn t ∈ I gilt.
1
Verfügbar unter http://www.cs.dartmouth.edu/~sws/pubs/ms05a.pdf.
5
• Die Domäne (domain) wird benutzt, um eine Menge von Properties anzugeben, die eine zertifikatausstellende Einheit
einem Subjekt zuweisen darf. Properties können etwa Attribute des Zertifikats sein, die in den Erweiterungen stehen. Als
typisches Beispiel sei die KeyUsage-Extension genannt. Die Domäne ist also alles, für das eine CA bürgen darf.
• Die Benutzung von Recommendations wird durch das Trust Transfer-Konzept ersetzt, damit eine Teilmenge der Zertifikationseigenschaften weitergegeben werden kann.
• Validity Templates werden eingeführt, um formatspezifische Definitionen der Gültigkeit einer Aussage zu erfassen.
Im erweiterten Modell gibt es somit folgende Schreibweisen für Aussagen über den Kenntnisstand:
a) Authentizität der Verbindlichkeit / Authenticity of binding
Aut(A, X , P , I ) bezeichnet den Glauben von A, dass die Einheit X die in P enthaltenen Properties während des Intervalls
I besitzt.
b) Vertrauen / Trust
Trust(A, X , D, I ) kennzeichnet den Glauben von A, dass die Einheit X vertrauenswürdig ist bezüglich der Ausstellung
von Zertifikaten über die Domäne D während des Intervalls I .
c) Zertifikate / Certificates
Cert(X , Y, P , I ) bedeutet, dass X ein Zertifikat für Y ausgestellt hat, welches die Verbindlichkeit zwischen dem öffentlichen Schlüssel von Y und der Menge von Properties P im Intervall I sicherstellt.
d) Übertragungen von Vertrauen / Trust Transfers
Tran(X , Y, P , I ) besagt, dass Y einen Vertrauensübertrag von X erhalten hat, so dass eine Verbindlichkeit zwischen dem
öffentlichen Schlüssel von Y und der Menge von Properties P im Intervall I besteht.
e) Zertifikatsgültigkeitsschablonen / Certificate Validity Templates
Valid〈A, C, t〉 bezeichnet den Glauben von A, dass das Zertifikat C zur Auswertungszeit t gültig ist.
f) Übertragungsgültigkeitsschablonen / Transfer Validity Templates
Valid〈A, T, t〉 bezeichnet den Glauben von A, dass die Vertrauensübertragung T zur Auswertungszeit t gültig ist.
Eine Aussage ist in diesem erweiterten Modell nur dann gültig, wenn sie entweder in ViewA enthalten ist oder aus ViewA
abgeleitet werden kann. Die Ableitungsregeln müssen angepasst werden, um diese neuen Elemente nutzen zu können.
∀X , Y, t ∈ I0 ∩ I1 , Q ⊆ D :
Aut(A, X , P , I0 ), Trust(A, X , D, I1 ), Valid A, Cert(X , Y, Q, I2 ), t ` Aut(A, Y, Q, I2 )
(3)
∀X , Y, t ∈ I0 ∩ I1 , Q ⊆ D :
Aut(A, X , P , I0 ), Trust(A, X , D, I1 ), Valid A, Tran(X , Y, Q, I2 ), t ` Trust(A, Y, Q, I2 )
a)
(4)
i) Warum ist eine Erweiterung des formalen Modells für ein Web of Trust notwendig?
ii) Welche Merkmale sind im erweiterten Modell hinzugekommen? Ergänzen Sie die Vergleichstabelle in Tabelle
1, um die Unterschiede zwischen dem ursprünglichen und neuen Modell anhand der zusätzlichen Komponenten
deutlich zu machen.
b) Gegeben sei folgende Sicht
ViewA = {Aut(A, X , P , I0 ), Cert(X , Y, P , I2 ), Cert(Y, Z, D, I2 ), Tran(X , Y, D, I2 ),
Tran(Z, B, D, I2 ), Trust(A, Z, D, I2 ), Trust(A, X , D, I1 )}
6
PKI-System
mehrere Formate
Revokation
Autorisierung
Delegierung
Zeitverhalten
Maurers Modell
erweitertes Modell
ermöglichendes neues Merkmal
Tabelle 1: Vergleichstabelle
von A mit I0 ∩ I1 6= ; und P ⊆ D .
i) Zeigen Sie, warum A sich sicher sein kann, dass B vertrauenswürdig ist.
ii) Für welchen Zeitraum ist B für A vertrauenswürdig?
c) Sei ViewB gegeben als
ViewB = {Aut(B, X , P , I ), Aut(A, Y, P , I ), Cert(X , A, P , I ), Cert(A, C, P , I ), Tran(X , A, P , I ),
Tran(C, B, P , I ), Trust(A, Y, P , I ), Trust(B, C, P , I ), Trust(B, X , P , I )}.
Entscheiden Sie, ob B gegenüber Y Vertrauen aufbringt.
d) Gegeben sei
ViewC = {Aut(C, B, P , I ), Cert(A, X , P , I ), Cert(B, A, P , I ), Cert(X , Y, P , I ),
Tran(A, X , P , I ), Tran(B, A, P , I ), Trust(C, B, P , I )}.
Prüfen Sie, ob C davon ausgehen kann, dass Y zum Zeitpunkt t ∈ I über die in P enthaltenen Eigenschaften verfügt.
7

Public-Key-Infrastrukturen - CDC - Technische Universität Darmstadt

Transcription

Similar documents

Governikus Add-In Benutzerhandbuch

Inverted files

Containerformate am Beispiel MP4

Outlook-Tipp: Signatur

080908_Skript Internetsicherheit - Elektronischer Rechtsverkehr im

Handbuch für die Nutzung des Groupware Dienstes MS