🎓 MyUniNotes

Search (CTRL+K)

SearchSearch

ÜB-7-GnC

Feb 09, 2025|Feb 13, 2025|24 min 40 sec

Security

Aufgabe 7.1: Ein Zertifikat

In der in der Vorlesung vorgestellten Public-Key Infrastructure (PKI) werden zur Authentifizierung X.509-Zertifikate verwendet. Gegeben sei nun das folgende so genannte X.509-End Entity Certificate (EEC):

Sie sollen nun einige Grundlagen zum X.509-Zertifikatsformat und den beschriebenen Informationen wiederholen. Beantworten Sie dazu bitte folgende Fragen:

1. Was versteht man im Allgemeinen unter einem X-Zertifikat?

Ein Public-Key-Zertifikat ist eine digital signierte Erklärung einer Entität, die besagt, dass der öffentliche Schlüssel (und einige weitere Informationen) einer anderen Entität einen bestimmten Wert hat.

Leichter formuliert: Ein X-Zertifikat ist eine digitale Bestätigung, dass ein bestimmter öffentlicher Schlüssel einer bestimmten Person oder Organisation gehört. Es wird von einer vertrauenswürdigen Stelle ausgestellt und dient dazu, sichere Kommunikation und Authentifizierung im Internet zu ermöglichen.

2. Was ist ein End Entity Certificate (EEC)?

End Entity = User oder Host oder Service

Ein End Entity Certificate (EEC) ist ein digitales Zertifikat, das direkt einer Endentität, wie einer Person, einem Server oder einer Anwendung, ausgestellt wird. Es bestätigt die Identität des Inhabers und ermöglicht eine sichere Kommunikation, indem es dessen öffentlichen Schlüssel authentifiziert.

3. Welcher Signaturalgorithmus wird verwendet?

sha1WithRSAEncryption

4. Welche Lebensdauer hat das angegebene Zertifikat?

  • Validity:
    • Not Before: Mar 4 14:56:16 2024 GMT
    • Not After : Apr 3 14:56:16 2024 GMT

→ Lebensdauer von einem Monat

5. Welche Erweiterungen sind im Erweiterungsfeld des Zertifikats spezifiziert? Geben Sie 3 Beispiele an.

X509v3 extensions:
    X509v3 Basic Constraints: critical
        CA: FALSE
    X509v3 Key Usage: critical
        Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment
    X509v3 Extended Key Usage:
        TLS Web Client Authentication, E-mail Protection

6. Welche Erweiterungen sind dabei kritisch und was bedeutet das? (Hinweis: RFC 2459)

  • X509v3 Basic Constraints: critical
  • X509v3 Key Usage: critical

→ Wenn eine kritische Extension nicht erkannt wird, muss das Zertifikat abgelehnt werden.

7. Recherchieren Sie, welche Certificate Policies in der Erweiterung spezifiziert sind.

In diesem Zertifikat tauchen folgende OIDs auf:

  • 1.3.6.1.4.1.22177.300.1.1.3.1.4
  • 1.2.840.113612.5.2.2.1

8. Handelt es sich bei dem angegebenen EEC um ein User-, Host- oder Proxy-Zertifikat?

User-Zertifikat

Aufgabe 7.2: Praxis – Zertifikate

In dieser Aufgabe erstellen Sie zunächst Ihren eigenen privaten Schlüssel, generieren einen Certificate Signing Request (CSR) und signieren diesen schließlich selbst zu einem Zertifikat. Anschließend wird mit einem vorgegebenen Zertifikat eine Nachricht verschlüsselt.

Schritt 1: Keys erstellen

Erstellen Sie zunächst einen privaten Schlüssel. Dieser Schlüssel wird benötigt, um den CSR zu generieren und später Ihr Zertifikat zu signieren.

openssl genrsa -out mykey.key 2048

Hinweis:
Der private Schlüssel mykey.key muss sicher aufbewahrt werden und nicht mit abgegeben werden.

Schritt 2: CSR erstellen

Mit dem privaten Schlüssel erstellen Sie nun einen Certificate Signing Request (CSR). Dabei werden Sie nach Informationen wie Land, Bundesland, Organisation, usw. gefragt.

openssl req -new -key mykey.key -out myrequest.csr

Schritt 3: Zertifikat selbst signieren

Nun signieren Sie den CSR mit Ihrem eigenen privaten Schlüssel, um ein selbstsigniertes Zertifikat zu erstellen. Hier legen Sie z. B. fest, dass das Zertifikat 365 Tage gültig sein soll.

openssl x509 -req -in myrequest.csr -signkey mykey.key -out mycert.crt -days 365

Ihr Zertifikat mycert.crt enthält nun den zugehörigen öffentlichen Schlüssel und kann zur Verschlüsselung von Nachrichten verwendet werden.

Proxy-Zertifikat

Frage: Können Sie von diesem ein Proxy-Zertifikat ableiten?
Antwort:
Ein Proxy-Zertifikat besitzt spezielle Eigenschaften und Erweiterungen, die über ein Standard-X.509-Zertifikat hinausgehen. Daher können Sie aus einem selbstsignierten Zertifikat, wie oben erstellt, kein direktes Proxy-Zertifikat ableiten. Für den Einsatz von Proxy-Zertifikaten sind zusätzliche Konfigurationen und oftmals spezifische Softwarelösungen erforderlich.

Teilaufgabe 7.2.1: Upload Ihres Zertifikats in Moodle

  • Aufgabe:
    Laden Sie Ihr Zertifikat (mycert.crt) im entsprechenden Dateiformat (oder verpackt in einem Zip-Archiv) in Moodle hoch.
  • Wichtig:
    Geben Sie nicht den privaten Schlüssel (mykey.key) mit ab, da wir das Zertifikat verwenden, um Ihnen eine verschlüsselte Nachricht zukommen zu lassen, die nur mit Ihrem privaten Schlüssel entschlüsselt werden kann.

Teilaufgabe 7.2.2: Upload einer verschlüsselten Nachricht in Moodle

Für diese Teilaufgabe nutzen Sie ein von uns bereitgestelltes Zertifikat, um eine Nachricht zu verschlüsseln. Gehen Sie dazu wie folgt vor:

1. Zertifikat herunterladen

Laden Sie das Zertifikat von der folgenden Adresse herunter (zum Beispiel mit wget):

wget http://www.nm.ifi.lmu.de/teaching/Vorlesungen/2024ws/gridcloud/lrz24.crt

2. Public Key extrahieren

Extrahieren Sie aus dem heruntergeladenen Zertifikat den Public Key:

openssl x509 -pubkey -noout -in lrz24.crt > public.key

Dies erstellt die Datei public.key, welche den öffentlichen Schlüssel enthält.

3. Nachricht erstellen

Erstellen Sie eine Textdatei (z. B. message.txt) mit einer beliebigen Nachricht. Zum Beispiel:

echo "Dies ist eine geheime Nachricht." > message.txt

4. Nachricht verschlüsseln

Verwenden Sie den extrahierten Public Key, um die Nachricht zu verschlüsseln. Dazu können Sie openssl rsautl verwenden:

openssl rsautl -encrypt -pubin -inkey public.key -in message.txt -out message.enc

Die Datei message.enc enthält nun die verschlüsselte Nachricht, die Sie in Moodle hochladen.

Zusammenfassung der Lösungsschritte

  1. Keys erstellen:
    • Erzeugen Sie einen privaten Schlüssel:
      openssl genrsa -out mykey.key 2048
  2. CSR erstellen:
    • Erstellen Sie den Certificate Signing Request:
      openssl req -new -key mykey.key -out myrequest.csr
  3. Zertifikat selbst signieren:
    • Signieren Sie den CSR zu einem selbstsignierten Zertifikat:
      openssl x509 -req -in myrequest.csr -signkey mykey.key -out mycert.crt -days 365
  4. Proxy-Zertifikat:
    • Ein Proxy-Zertifikat lässt sich nicht direkt aus einem Standard-Zertifikat ableiten.
  5. Upload in Moodle (Teil 7.2.1):
    • Laden Sie ausschließlich mycert.crt hoch.
  6. Verschlüsselte Nachricht (Teil 7.2.2):
    • Laden Sie das bereitgestellte Zertifikat herunter:
      wget http://www.nm.ifi.lmu.de/teaching/Vorlesungen/2024ws/gridcloud/lrz24.crt
    • Extrahieren Sie den Public Key:
      openssl x509 -pubkey -noout -in lrz24.crt > public.key
    • Erstellen Sie Ihre Nachricht (z. B. message.txt).
    • Verschlüsseln Sie die Nachricht:
      openssl rsautl -encrypt -pubin -inkey public.key -in message.txt -out message.enc
    • Laden Sie die verschlüsselte Datei message.enc in Moodle hoch.

Aufgabe 7.3: Proxyezertifikat

In dieser Fallstudie sollen Sie ein Protokoll entwerfen, das die Delegation von Rechten über Proxy-Zertifikate ermöglicht.

Fallbeschreibung

Hintergrund

In der Vorlesung wurden das Grid-Problem und die Kernkonzepte zur Authentifizierung und Autorisierung in Grids besprochen. Daraus leiten Sie sich das allgemeine Grid Security Problem ab, nämlich das Bereitstellen von Mechanismen, die es erlauben, in heterogenen Umgebungen auf Ressourcen zuzugreifen trotz unterschiedlicher Sicherheitsvorschriften und Prozeduren. Wir wollen uns hier auf den Teilaspekt der Delegation von Rechten konzentrieren.

Terminologie

Verwenden Sie bei der Bearbeitung des Falles die aus den Standards bekannte Terminologie für Authentifizierung und Autorisierung:

  • Ein subject ist ein Teilnehmer, der im Rahmen einer abgesicherten Grid-Operation auf ein object zugreifen möchte.
  • Ein credential bezeichnet die Identität eines subject. Beispiele: Passwörter, Zertifikate.
  • Autorisierung ist der Prozess zur Bestimmung der Zugriffsberechtigung eines subjects auf ein object.
  • Ein End Entity Certificate (EEC) ist ein X-Zertifikat, das zu einer Entität gehört, die keine CA ist, also zum Beispiel zu Personen oder Hosts.
  • Ein proxy-Zertifikat ist ein kurzlebiges X-Zertifikat, das von einem EEC abgeleitet wird.
  • Ein proxy credential besteht aus einem proxy-Zertifikat und dem dazu gehörenden privaten Schlüssel.
  • Eine Grid Security Infrastructure (GSI) besteht aus Bibliotheken und Werkzeugen zur Authentifizierung und zur sicheren Kommunikation auf der Basis von Public Key-Infrastrukturen (PKI), dem SSL/TLS Protokoll (RFC 5246) und X Proxy-Zertifikaten.

Aufgabenstellung

Ihre Aufgabe besteht darin, ein Delegationsprotokoll zu entwerfen. Das nachfolgende User Proxy Creation Protocol nehmen Sie bitte als Beispiel. So ähnlich sollte die Lösung Ihrer Aufgaben aussehen. Versuchen Sie, die Funktionalität Ihres Delegationsprotokolls in der richtigen Reihenfolge zu spezifizieren. Die grafische Darstellung bleibt Ihnen überlassen.

Beispiel: User Proxy Creation Protocol

Ein User Proxy ist ein Prozess, der an User Stelle agiert. Er wird typischerweise definiert als

session manager process given permission to act on behalf of a user for a limited period of time.
(Foster et al., 1998)

Das User Proxy Creation Protocol erzeugt ein zeitlich beschränktes credential für den User Proxy mit eventuellen zusätzlichen Einschränkungen wie Host-Namen, Zielkonten oder ähnliche.

Die Protokollschritte 1 bis 6 sind in Abbildung 4 dargestellt.

Delegation Protocol

Schritte im Einzelnen

Schritt 1:
Der User greift über den lokalen Authentifizierungsprozess (zum Beispiel username, password) auf den Gridknoten zu, auf dem der User Proxy erzeugt werden soll.

Schritt 2:
Ein neues (public, private)-Schlüsselpaar wird auf dem Gridknoten erzeugt.

Schritt 3:
Ein neues proxy-Zertifikat wird mit Hilfe des in Schritt 2 generierten öffentlichen Schlüssels erzeugt. Signiert wird dieses Zertifikat mit dem privaten Schlüssel des Users.

Schritt 4:
Ein neuer User Proxy Process wird auf dem Gridknoten erzeugt.

Schritt 5:
Dem neu erzeugten User Proxy Process werden das proxy-Zertifikat (5a) und der assoziierte private Schlüssel (5b) zugeordnet.

Schritt 6:
Der User Proxy Process kann nun das proxy credential benutzen, um seine Identität zu beweisen.

Hier ist nun Ihre Aufgabe. Gegeben sei ein subject auf Host A, das einem anderen subject auf Host B die Verantwortung übertragen möchte, in seinem Namen einen Grid-Job auf Host C auszuführen (und dabei auf objects auf C zuzugreifen). Der Einfachheit halber (aber formal ungenau) bezeichnen wir das subject auf A, B oder C kurz selbst mit A, B oder C.

Grundprinzip des Delegationsprotokolls

  • A besitzt ein von einer CA signiertes Zertifikat.
  • A erzeugt dann ein proxy-Zertifikat und sendet dieses an B.
  • B benutzt das proxy-Zertifikat, um Grid-Jobs an Stelle von A auf C ausführen zu lassen.

Vervollständigung des Delegationsprotokolls

Abbildung 5 zeigt die drei Entitäten und ihre Initialisierung.
Vervollständigen Sie nun das Delegationsprotokoll zwischen A, B und C.
Gehen Sie davon aus, dass zwischen A und B eine sichere Kommunikation eingerichtet ist (über eine wechselseitige Authentifizierung).

Ablauf der Proxy-Zertifikat-Delegierung

  1. Verbindung und Authentifizierung

    • Der Initiator auf Host A verbindet sich mit dem Zieldienst auf Host B.
    • Beide Parteien führen eine gegenseitige Authentifizierung durch:
      • Der Initiator nutzt sein bestehendes Proxy-Zertifikat.
      • Der Zieldienst verwendet sein eigenes Public-Key-Zertifikat (nicht abgebildet).
    • Nach der Authentifizierung wird ein integritätsgeschützter Kanal eingerichtet.
    • Diese Schritte können mit dem SSL-Protokoll durchgeführt werden.

  2. Schlüsselgenerierung durch den Zieldienst

    • Der Initiator signalisiert seinen Wunsch zur Delegierung durch anwendungsspezifische Mittel.
    • Der Zieldienst erzeugt ein neues Schlüsselpaar (privater und öffentlicher Schlüssel).

  3. Erstellung und Übermittlung der Zertifikatsanforderung

    • Mit dem neuen öffentlichen Schlüssel wird eine signierte Zertifikatsanforderung erstellt.
    • Diese wird über den gesicherten Kanal an den Initiator zurückgeschickt.

  4. Signierung durch den Initiator

    • Der Initiator verwendet seinen privaten Schlüssel aus dem eigenen Proxy-Zertifikat, um:
      1. die Zertifikatsanforderung zu signieren.
      2. ein neues Proxy-Zertifikat zu erstellen, das den neu generierten öffentlichen Schlüssel des Zieldienstes enthält.

  5. Bereitstellung des neuen Proxy-Zertifikats

    • Das neue Proxy-Zertifikat wird über den gesicherten Kanal an den Zieldienst zurückgesendet.
    • Der Zieldienst speichert es zusammen mit seinem neu generierten privaten Schlüssel.
    • Das Proxy-Zertifikat steht anschließend für Anwendungen auf dem Zieldienst zur Verfügung, die im Namen des Benutzers laufen.
---
config:
  look: neo
  theme: neo-dark
---
sequenceDiagram
    participant A as Host A (Initiator)
    participant B as Host B (Target Service)

    A->>B: Step 1 - SSL
    B->>B: Step 2 - Generate New Private Key
    B->>A: Step 3 - Certificate Request
    A->>A: Step 4 - Sign with Existing Proxy Certificate and Private Key
    A->>B: Step 5 - New Proxy Certificate
    B->>B: New Proxy Certificate Received
×

MyUniNotes is a free, non-profit project to make education accessible for everyone. If it has helped you, consider giving back! Even a small donation makes a difference.

These are my personal notes. While I strive for accuracy, I’m still a student myself. Thanks for being part of this journey!

Graph View

Backlinks