Übungsaufgaben zur Kryptografie: Verschlüsselung, Signatur, Zertifikate und Passwörter

Kopiere den Text in ein KI-Sprachmodell Deiner Wahl und passe Kompetenzstufe, Anzahl, Bearbeitungszeit und Szenario bei Bedarf an. Wie die Aufgaben aufgebaut sind, beschreibt der Artikel Wie sind die Aufgaben aufgebaut?. Prüfe die Ergebnisse mit dem Lehrartikel: KI-Sprachmodelle machen Fehler.

Erstelle neue Übungsaufgaben zum Thema „Kryptografie: Verschlüsselung,
Signatur, Zertifikate und Passwörter“.

Bauplan: Halte Dich an Aufbau, Kompetenzstufen, Operatoren,
Anforderungsbereiche, Punkte und Zeitschätzung, die im Artikel
https://oer-informatik.de/aufgaben-aufbau beschrieben sind.

Fachliche Grundlage:
- https://oer-informatik.de/kryptografie
- https://oer-informatik.de/tls-pki-betrieb
- Stilbeispiel: https://oer-informatik.de/kryptografie-uebungsaufgaben

Die Aufgaben sollen Inhalte zu diesen Schlagwörtern abdecken:
- Kryptografie
- Hybride Verschlüsselung
- TLS
- Zertifikat
- Digitale Signatur
- Hashfunktion
- HMAC
- Passwort-Hashing

Kompetenzstufe: Kernkompetenz (alternativ: Basiskompetenz, Profilkompetenz, Expertise)
Anzahl: 1 Aufgabe mit Teilaufgaben
Bearbeitungszeit in Minuten ca.: <5 bis 30 min>
Szenario: eines der Szenarien aus dem Bauplan

Vorgehen:
1. Lies zuerst die verlinkten Artikel. Kannst Du keine Webseiten
   abrufen, sag mir das, statt zu raten.
2. Steht bei einer Angabe noch ein Platzhalter in <…>, frag mich
   zuerst danach. Richte Punkte und Zahl der Teilaufgaben nach der
   Bearbeitungszeit (ca. 0,9 min je Punkt).
3. Gib je Aufgabe Titel mit Kompetenzstufe, Ausgangssituation und
   Teilaufgaben mit Operator und Punktzahl aus, dazu die geschätzte
   Bearbeitungszeit.
4. Gib die Beispiellösungen mit Punkteverteilung erst aus, wenn ich
   danach frage.

Zutreffend sind:

• „Mit dem veröffentlichten Schlüssel kann jede Person Nachrichten für Andrea Wolf verschlüsseln.“
• „Nur wer den privaten Schlüssel von Andrea Wolf besitzt, kann die Formulare entschlüsseln.“

Die übrigen Aussagen sind falsch: Ein gemeinsames Geheimnis ist gerade nicht nötig, der öffentliche Schlüssel entschlüsselt nicht, und asymmetrische Verfahren sind deutlich langsamer als AES. Je richtig gekennzeichneter Aussage 1 Punkt, je falsch gekennzeichneter 1 Punkt Abzug (mindestens 0 Punkte).

• Fehler in Schritt 2: Was mit dem privaten Schlüssel der Eltern „verschlüsselt“ wird, kann jede Person mit deren öffentlichem Schlüssel wieder lesbar machen – das ist eher eine Signatur als eine Verschlüsselung. Richtig: „Laden Sie den öffentlichen Schlüssel von Andrea Wolf von der Schulwebseite und verschlüsseln Sie das Formular damit.“ (2 Punkte)
• Fehler in Schritt 3: Ein privater Schlüssel wird nie weitergegeben. Wer die zweite E-Mail mitliest, könnte sonst alles entschlüsseln, was für diesen Schlüssel bestimmt ist. Richtig: „Schicken Sie nur das verschlüsselte Formular an Andrea Wolf.“ (2 Punkte)
• Begründung: Zum öffentlichen Schlüssel von Andrea Wolf passt nur ihr privater Schlüssel, und den besitzt nur sie. Damit ist die Vertraulichkeit des Formulars gesichert. (1 Punkt)

Schritt 1 ist für die Verschlüsselung gar nicht nötig; ein eigenes Schlüsselpaar brauchen die Eltern erst, wenn sie signieren wollen (siehe d). Technisch verschlüsseln E-Mail-Programme hybrid: Das PDF wird mit einem zufälligen Sitzungsschlüssel symmetrisch verschlüsselt, nur dieser wird mit Andrea Wolfs öffentlichem Schlüssel geschützt.

Erwartet wird eine begründete Ablehnung, z. B.:

• Das ZIP-Passwort ist ein gemeinsamer symmetrischer Schlüssel für alle Familien. Wer den Elternbrief kennt – also jedes Elternteil, jede*r Schüler*in und alle, die ihn weiterleiten –, kann abgefangene Formulare anderer Familien öffnen. Geheim ist das Passwort damit nicht. (1 Punkt)
• Ein Wechsel des Passworts erfordert einen neuen Brief an alle; ein bekannt gewordenes Passwort betrifft sofort alle bisherigen Formulare. (1 Punkt)
• Beim asymmetrischen Verfahren darf der öffentliche Schlüssel dagegen ganz offen auf der Webseite stehen, nur Andrea Wolf kann entschlüsseln. Der Vorteil des ZIP-Archivs (kein Schlüsselpaar, mit Bordmitteln zu öffnen) wiegt das nicht auf. (1 Punkt)

Erstellen (beim Elternteil, 2 Punkte):

• Vom Formular wird ein Hashwert gebildet.
• Der Hashwert wird mit dem privaten Schlüssel des Elternteils signiert („verschlüsselt“); die Signatur wird mit dem Formular verschickt.

Prüfen (bei Andrea Wolf, 2 Punkte):

• Andrea Wolf prüft die Signatur mit dem öffentlichen Schlüssel des Elternteils und erhält so (vereinfacht, bei RSA) den ursprünglichen Hashwert.
• Sie bildet selbst den Hashwert des empfangenen Formulars und vergleicht beide. Stimmen sie überein, ist das Formular unverändert und stammt vom Besitzer des privaten Schlüssels.

Hinweis: Damit Andrea Wolf weiß, dass der öffentliche Schlüssel wirklich zu diesem Elternteil gehört, braucht es ein Zertifikat oder einen Abgleich auf anderem Weg.

• Schluss: Das PDF ist nicht mehr dasselbe wie beim Archivieren – schon ein einziges geändertes Bit ergibt einen völlig anderen Hashwert. Die Integrität dieses Formulars ist nicht mehr belegt; es darf nicht mehr als Nachweis gelten. (1 Punkt)
• Grenze: Der Hashwert sagt nicht, was geändert wurde, wer es war und ob es Absicht oder ein Speicherfehler war. Dafür braucht es Protokolle und eine Sicherungskopie zum Vergleich. (1 Punkt)
• Getrennte Liste: Wer PDF und Liste ändern kann, berechnet einfach den neuen Hashwert und trägt ihn ein – die Manipulation fiele nie auf. Die Liste muss deshalb an einem Ort liegen, auf den die Bearbeiter*innen der PDFs keinen Schreibzugriff haben, oder selbst signiert sein. (1 Punkt)

1. 2 · b) 5 · c) 3 · d) 4 · e) 3 · Summe 17 Punkte

Je Fehler 2 Punkte (Begründung 1 Punkt, Korrektur 1 Punkt):

• SHA-256 ist eine Hashfunktion: Sie bildet nur einen Prüfwert und kann nicht entschlüsseln – die Sicherung wäre unbrauchbar. Korrektur: ein symmetrisches Verfahren wie AES (bei LUKS üblich: AES im Modus XTS); symmetrisch, weil große Datenmengen schnell ver- und entschlüsselt werden müssen.
• Passphrase auf dem Etikett: Wer die Festplatte findet oder stiehlt, hat den Schlüssel gleich dazu; die Verschlüsselung ist wertlos. Korrektur: Passphrase getrennt von der Festplatte hinterlegen (siehe d).
• Login-Passwort als Passphrase: Wird eines der beiden bekannt (z. B. durch Phishing), ist auch das andere offen; zudem müssten alle, die die Platte nutzen, Jonas’ Login kennen. Korrektur: eigene, lange Passphrase nur für die Sicherungsplatte.

• ba) Nein: Ohne Passphrase sind die Daten nur Zufallsrauschen, auch wenn jemand die Festplatte an einen anderen Rechner anschließt (Voraussetzung: Passphrase nicht notiert und ausreichend lang). (2 Punkte)
• bb) Ja: Im entsperrten Zustand liest das System die Daten entschlüsselt; die Schadsoftware kann sie lesen, kopieren oder verändern. Deshalb die Festplatte nur für die Dauer der Sicherung einbinden und danach sofort wieder sperren. (2 Punkte)

• Gestärkt wird die Vertraulichkeit: Nur wer die Passphrase kennt, kann die Testdaten lesen. (1 Punkt)
• Verfügbarkeit: Ist die Passphrase vergessen oder Jonas nicht erreichbar, oder ist der Bereich der Festplatte beschädigt, in dem LUKS die Schlüsselinformationen ablegt (LUKS-Header), kommt niemand mehr an die Sicherung – auch Let’s Meet selbst nicht. Eine verschlüsselte Sicherung braucht deshalb eine geregelte Hinterlegung der Passphrase und eine Sicherung des Headers. (2 Punkte)

Zum Beispiel ein gemeinsamer Tresor im Passwortmanager des Entwicklungsteams (1 Punkt):

• getrennt: Die Passphrase liegt verschlüsselt im Passwortmanager, nicht bei der Festplatte; wer die Platte findet, hat sie nicht. (1 Punkt)
• nur Berechtigte: Freigabe nur für Yusuf Demir und Jonas Weber, Anmeldung am Passwortmanager mit MFA, Zugriffe werden protokolliert. (1 Punkt)

Ebenfalls richtig: versiegelter Umschlag im Firmentresor mit dokumentierter Schlüsselausgabe. Ungeeignet sind Orte, die mit der Festplatte zusammen unterwegs sind (Tasche, Etikett, Notizzettel).

Je Zeile 1 Punkt.

1. 6 · b) 4 · c) 3 · d) 3 · e) 4 · Summe 20 Punkte

Entschlüsseln von V: 0000 1100 XOR 0101 1010 = 0101 0110 = 0x56 = V.

Bewertung: je Zeichen richtig verschlüsselt 1 Punkt, Rückrechnung 1 Punkt.

• Symmetrisch: Programm und Server benutzen denselben geheimen Schlüssel (0x5A), Ver- und Entschlüsseln ist dieselbe XOR-Operation. (1 Punkt)
• Schlüssel gewinnen: Er verknüpft das erste Geheimtext-Byte mit dem bekannten Klartext: 0x0C XOR 0x56 = 0000 1100 XOR 0101 0110 = 0101 1010 = 0x5A. Damit kennt er den Schlüssel und kann alle Bestellungen aller Händler entschlüsseln. (2 Punkte)

• Behoben (1 Punkt): Der Schlüssel ist lang genug gegen Durchprobieren; bekannter Klartext verrät ihn nicht mehr, gleiche Zeichen ergeben keine gleichen Geheimtexte mehr; GCM erkennt zudem veränderte Daten.
• Bleibt (2 Punkte): Der Schlüssel steckt weiter in jeder Installation. Wer ein Programm dekompiliert oder den Speicher ausliest, kann den Verkehr aller Händler mitlesen und fälschen. Ein Schlüsselwechsel geht nur per Update bei allen 37 Händlern; einzelne Händler lassen sich nicht ausschließen.
• Lösung (2 Punkte): Übertragung per HTTPS (TLS): Der Shop-Server besitzt ein Schlüsselpaar und ein Zertifikat. Für jede Verbindung wird ein eigener Sitzungsschlüssel vereinbart, mit dem die Daten symmetrisch (AES-GCM) verschlüsselt werden. Im Programm steckt kein Geheimnis mehr, nur das Vertrauen in die CA. Zusätzlich können sich die Händler mit eigenen Zugangsdaten oder Client-Zertifikaten anmelden.

Bezeichnung: hybride Verschlüsselung. Bewertung: Reihenfolge 2 Punkte (1 Punkt bei einer Vertauschung), Kennzeichnung je 0,5 Punkte, Bezeichnung 1 Punkt. (Bei TLS 1.3 kommt der Schlüsselaustausch zuerst; das Zertifikat wird bereits verschlüsselt übertragen.)

Erwartet wird eine begründete Ablehnung mit drei Argumenten (je 1 Punkt), z. B.:

• RSA ist um Größenordnungen langsamer als AES; bei vielen Bestellungen und Händlern stiege die Last auf Server und Clients stark.
• RSA kann nur Blöcke verschlüsseln, die kleiner als der Schlüssel sind (bei 3072 Bit höchstens rund 384 Byte abzüglich Auffüllung); längere Daten müssten zerstückelt werden.
• Ohne wechselnden Sitzungsschlüssel fehlt Forward Secrecy: Wer später den privaten Schlüssel stiehlt, kann alle mitgeschnittenen Bestellungen nachträglich entschlüsseln.
• Für die Antworten bräuchte der Server zusätzlich die öffentlichen Schlüssel aller Clients.

Geg.: n = 40 Beteiligte

Ges.: N_{\text{sym}}, N_{\text{asym}}

Symmetrisch braucht jedes Paar einen Schlüssel:

N_{\text{sym}} = \frac{n \cdot (n-1)}{2} = \frac{40 \cdot 39}{2} = \underline{\underline{780 \text{ Schlüssel}}}

Asymmetrisch braucht jede Person ein Schlüsselpaar:

N_{\text{asym}} = 2 \cdot n = 2 \cdot 40 = \underline{\underline{80 \text{ Schlüssel}}} \quad (40 \text{ Schlüsselpaare})

Bewertung: je Formel 1 Punkt, je Ergebnis 1 Punkt. Die Antwort „40 Schlüsselpaare“ ist ebenfalls richtig.

• Zugesichert – Echtheit (2 Punkte): Eine Zertifizierungsstelle hat mit ihrer Signatur bestätigt, dass der öffentliche Schlüssel zu shop.csb-rad.example gehört, und der Browser hat Kette, Gültigkeit und Domainnamen geprüft. Der Händler spricht also wirklich mit dem Server dieser Domain und nicht mit einem Man-in-the-Middle.
• Zugesichert – geschützte Übertragung (1 Punkt): Mit dem geprüften Server wird ein Sitzungsschlüssel vereinbart; Zugangsdaten, Preise und Schließungscodes sind unterwegs vertraulich und gegen Veränderung geschützt.
• Nicht zugesichert (2 Punkte): Das Schloss sagt nichts über die Seriosität des Betreibers: Auch eine Phishing-Seite wie csb-rad-shop.example erhält in wenigen Minuten ein gültiges Zertifikat – der Händler muss also die Adresse prüfen. Außerdem schützt TLS nicht vor Schadsoftware auf dem eigenen PC und nicht vor Datenlecks auf dem Server.

• Die API schickt beim Verbindungsaufbau ihr Zertifikat, das von einer Zertifizierungsstelle (CA) signiert ist, meist mit Zwischenzertifikat. (1 Punkt)

• Der Shop-Server hat in seinem Trust Store die Stammzertifikate vertrauenswürdiger CAs. Er prüft die Signatur des Server-Zertifikats mit dem öffentlichen Schlüssel des Zwischenzertifikats und dieses mit dem der Stamm-CA (Vertrauenskette). (2 Punkte)

• Zusätzlich prüft er Gültigkeitszeitraum, Domainname (api.schliesstec.example) und ob das Zertifikat gesperrt ist (CRL/OCSP); im Handshake beweist der Server den Besitz des privaten Schlüssels. (1 Punkt)

Je Angabe 0,5 Punkte, z. B.: Inhaber/Domainname (Subject, Subject Alternative Name), öffentlicher Schlüssel und Verfahren, Aussteller (CA), Gültigkeitszeitraum (gültig ab/bis), Seriennummer, Verwendungszweck, Signatur der CA, Signaturverfahren, Versionsnummer.

Erwartet wird eine begründete Ablehnung des Vorschlags, z. B.:

• Akzeptiert der Client jedes Zertifikat, ist die Authentizität des Servers nicht mehr geprüft. Ein Angreifer im Netz könnte sich mit einem eigenen Zertifikat als MES ausgeben (Man-in-the-Middle), Fertigungsaufträge mitlesen oder verfälschen. Die Verschlüsselung bringt dann wenig, weil man nicht weiß, mit wem man verschlüsselt. (2 Punkte)

• Selbstsignierte Zertifikate sind bei OPC UA mit wenigen festen Partnern aber vertretbar, wenn sie gezielt als vertrauenswürdig eingetragen werden: Zertifikate austauschen, den Fingerabdruck über einen zweiten Weg (z. B. Telefon mit Ole Petersen) abgleichen und in die Vertrauensliste (Trust List) beider Seiten aufnehmen. Alternativ eine gemeinsame bzw. interne CA nutzen. Ablaufdaten überwachen, Sicherheitsmodus „Sign & Encrypt“ wählen. (2 Punkte)

Eine Zustimmung ist nur dann mit Punkten zu bewerten, wenn sie auf eine reine, abgeschottete Testumgebung beschränkt wird und die Gefahr benennt.

1. 11 Punkte (3 + 3 + 5) · b) 12 Punkte (5 + 3 + 4) · c) 15 Punkte (5 + 4 + 2 + 4) · Summe 38 Punkte

Je Zelle 1 Punkt.

V3 (HMAC je Schild), weil

• es um Integrität und Authentizität der Anzeigen geht, nicht um Vertraulichkeit – der Sessionplan ist öffentlich, Verschlüsselung (V1, V2) löst das eigentliche Problem nicht; (1 Punkt)
• ein HMAC auf dem ESP32 mit Akku kaum Rechenzeit und Energie kostet, anders als RSA-Operationen; (1 Punkt)
• es nur zwölf bekannte Geräte sind, auf die Emre Aksoy die Schlüssel vor dem Barcamp einspielen kann – ein vorab verteilter Schlüssel ist hier kein Hindernis. (1 Punkt)

Ebenfalls richtig: eine digitale Signatur des Info-Servers (z. B. Ed25519), die alle Schilder mit demselben öffentlichen Schlüssel prüfen, oder AES-GCM mit Schlüssel je Schild – jeweils mit passender Begründung.

Je richtiger Angabe 1 Punkt:

1. kein Schlüssel (Hashfunktionen arbeiten ohne Schlüssel)

2. Hashwert H mit dem privaten Schlüssel signieren (bei RSA anschaulich: verschlüsseln) = Signatur

3. öffentlicher Schlüssel des Orga-Teams

4. Hashwert H2 des empfangenen Hinweistexts mit demselben Verfahren (SHA-256) bilden

5. H1 und H2 vergleichen

6. Hinweis anzeigen (Hinweis ist echt und unverändert)

• Erfüllt: Integrität (jede Änderung am Text ergibt einen anderen Hashwert) und Authentizität (nur das Orga-Team besitzt den privaten Schlüssel), zudem Verbindlichkeit: Das Orga-Team kann nicht bestreiten, den Hinweis geschickt zu haben. (2 Punkte)

• Nicht erfüllt: Vertraulichkeit – der Hinweistext wird im Klartext mitgeschickt und kann mitgelesen werden. Das ist hier unproblematisch, weil er ohnehin öffentlich angezeigt wird. (1 Punkt)

Zwei aus (je 1 Punkt Eigenschaft, 1 Punkt Begründung):

• Kollisionsresistenz: Es lässt sich praktisch keine zweite Datei mit demselben Hashwert finden. Ohne sie könnte ein Angreifer eine Schadversion bauen, die denselben Wert ergibt.
• Lawineneffekt: Schon ein geändertes Bit ergibt einen völlig anderen Hashwert. Ohne ihn fielen kleine Veränderungen beim Vergleich kaum auf.
• Deterministisch: Dieselbe Datei ergibt überall denselben Wert. Ohne das könnte Emre Aksoy seinen Wert gar nicht mit dem veröffentlichten vergleichen.
• Einwegfunktion: Aus dem Hashwert lässt sich keine passende Datei zurückrechnen. Ohne sie könnte ein Angreifer zum veröffentlichten Wert eine eigene Datei erzeugen.

• Prüfung (2 Punkte): Er berechnet nach dem Download selbst den SHA-256-Hashwert der Datei (z. B. Get-FileHash .\badgedesk-setup.exe -Algorithm SHA256) und vergleicht ihn mit dem veröffentlichten Wert. Stimmen beide überein, ist die Datei vollständig und unverändert übertragen worden.

• Grenze (2 Punkte): Der Hashwert steht auf derselben Seite wie der Download. Haben Angreifer die Projektseite übernommen, tauschen sie Datei und Hashwert aus – die Prüfung ergibt dann „gleich“, obwohl die Datei manipuliert ist. Der Hashwert belegt also nicht die Herkunft (Authentizität); dafür braucht man eine digitale Signatur bzw. Codesignierung oder einen Hashwert aus einer anderen, vertrauenswürdigen Quelle.

• Ursache (2 Punkte): Windows kann zwar prüfen, dass die Datei seit dem Signieren nicht verändert wurde. Das selbst ausgestellte Zertifikat führt aber zu keinem Stammzertifikat, dem die Tablets vertrauen – wer signiert hat, bleibt unbestätigt. Jede*r könnte sich ein Zertifikat auf den Namen „Mia Schröder“ ausstellen.
• Möglichkeiten (je 1 Punkt):
  • Ein Code-Signing-Zertifikat der internen CA der Schul-IT beantragen und im Build-Skript verwenden; das Stammzertifikat dieser CA verteilt Svenja Krämer über das Gerätemanagement auf die Tablets.
  • Ein Code-Signing-Zertifikat einer öffentlichen CA kaufen, der Windows ohnehin vertraut.
  • Ebenfalls richtig: Mias Zertifikat per Gerätemanagement gezielt als vertrauenswürdiger Herausgeber auf den verwalteten Tablets eintragen.

Beim Signieren zusätzlich einen Zeitstempel setzen, damit die Signatur auch nach Ablauf des Zertifikats gültig bleibt.

Erwartet: Ablehnung mit Begründung und Gegenentwurf, z. B.:

• Stellungnahme (3 Punkte): Verschlüsselte Passwörter lassen sich entschlüsseln. Der AES-Schlüssel liegt auf demselben Server wie die Datenbank bzw. im Programm; wer beides erbeutet (Einbruch, Datensicherung, Innentäter), hat alle Passwörter im Klartext – und weil viele Menschen Passwörter mehrfach verwenden, auch Zugänge zu anderen Diensten. Passwörter per E-Mail zurückzuschicken ist selbst eine Schwachstelle; richtig ist ein zeitlich begrenzter Link zum Setzen eines neuen Passworts.
• Speichern (1 Punkt): als Hashwert mit zufälligem Salt mit einem bewusst langsamen Passwort-Hashverfahren wie Argon2id oder bcrypt.
• Login prüfen (2 Punkte): Salt und Parameter des Kontos aus der Datenbank lesen, das eingegebene Passwort damit erneut hashen und das Ergebnis mit dem gespeicherten Hashwert vergleichen. Das Portal muss das Passwort dafür nie kennen oder zurückrechnen.

• bcrypt erzeugt für jedes Konto einen zufälligen Salt (hier die 22 Zeichen nach $2b$12$), der vor dem Hashen mit dem Passwort verknüpft und mitgespeichert wird. Gleiche Passwörter ergeben deshalb verschiedene Hashwerte. (1 Punkt)

• Gewollt, weil ein Angreifer so nicht erkennt, wer dasselbe Passwort nutzt, und vorberechnete Tabellen (Rainbow Tables) nutzlos werden: Er müsste jedes Konto einzeln angreifen – mit dem Kostenfaktor 12 zudem sehr langsam. (1 Punkt)

• Transportverschlüsselung (TLS, hybrid) schützt nur die einzelnen Übertragungsstrecken, z. B. vom Schulserver zum nächsten Mailserver. Auf den Servern liegt die E-Mail im Klartext vor; ob auch die weiteren Strecken verschlüsselt sind, hat der Absender nicht in der Hand. (1 Punkt)

• Ende-zu-Ende-Verschlüsselung (S/MIME, OpenPGP) verschlüsselt die Nachricht beim Absender mit dem öffentlichen Schlüssel der Empfänger*in; nur diese kann sie entschlüsseln. Server dazwischen sehen nur Geheimtext. (1 Punkt)

• Beurteilung (2 Punkte): Eine Teilnahmebescheinigung enthält nur wenige, wenig sensible personenbezogene Daten (Name, Veranstaltung, Datum). Transportverschlüsselung ist hier angemessen und Stand der Technik; Ende-zu-Ende-Verschlüsselung würde voraussetzen, dass alle 400 Teilnehmenden Zertifikate oder Schlüssel haben, was unrealistisch ist. Bei sensiblen Daten (z. B. Angaben zu Barrierefreiheitsbedarf oder Gesundheit) wäre sie dagegen nötig bzw. ein Download aus einem geschützten Portal besser. Eine andere, schlüssig begründete Beurteilung ist ebenfalls richtig.

1. 9 Punkte (6 + 3) · b) 9 Punkte (6 + 3) · c) 12 Punkte (4 + 4 + 4) · d) 8 Punkte (6 + 2) · e) 4 Punkte · Summe 42 Punkte

• Feste Länge: Beide Werte haben 64 Hexadezimalziffern = 256 Bit, unabhängig von der Länge der Eingabe. (1 Punkt)
• Lawineneffekt: Nur ein einziger Buchstabe ist anders (R/r), trotzdem sind die Werte völlig verschieden; aus der Ähnlichkeit der Passwörter lässt sich nichts ablesen. (1 Punkt)
• Login-Prüfung (2 Punkte): Der Shop berechnet den Hashwert des eingegebenen Passworts mit demselben Verfahren und vergleicht ihn mit dem gespeicherten. Stimmen beide überein, war das Passwort richtig. Zurückgerechnet wird nichts – das geht bei einer Einwegfunktion auch nicht.

Wer die Tabelle erbeutet, kann mit Grafikkarten Milliarden Passwortkandidaten pro Sekunde hashen und mit den gespeicherten Werten vergleichen (Wörterbuch- und Brute-Force-Angriff); ohne Salt fallen gleiche Passwörter sofort auf, und vorberechnete Tabellen helfen. (1 Punkt) Geeigneter ist ein bewusst langsames Passwort-Hashverfahren mit Salt wie Argon2id oder bcrypt. (1 Punkt)

Je Art 0,5 Punkte, je Aufgabe 1 Punkt.

Nein. Der Sitzungsschlüssel entsteht per X25519 aus Einmalwerten, die nach der Verbindung verworfen werden; der RSA-Schlüssel hat nur signiert und nie einen Sitzungsschlüssel transportiert. Mit dem gestohlenen Schlüssel kann der Angreifer sich künftig als Shop ausgeben, alte Aufzeichnungen bleiben aber geschützt (Forward Secrecy). (1 Punkt Entscheidung, 1 Punkt Begründung)

Risiko (2 Punkte): Benutzername und Passwort werden im Klartext übertragen und können im selben Netz oder auf jedem Netzknoten mitgelesen oder verändert werden (Man-in-the-Middle).

Schritte (je 1 Punkt, zwei aus): Zertifikat für den Server beantragen bzw. ausstellen und installieren; HTTPS im Webserver aktivieren; HTTP dauerhaft auf HTTPS umleiten; HSTS setzen.

Das Zertifikat wurde selbst erstellt (selbstsigniert) oder von einer internen CA ausgestellt, deren Stammzertifikat auf dem Client nicht als vertrauenswürdig hinterlegt ist; der Browser kann den Aussteller nicht prüfen. (Auch möglich: Zwischenzertifikat fehlt auf dem Server.)

In der Datei stehen nur öffentliche Schlüssel (1 Punkt). Bei der Anmeldung signiert der Client Daten der laufenden Sitzung mit seinem privaten Schlüssel; der Server prüft die Signatur mit einem der eingetragenen öffentlichen Schlüssel. Passt einer, ist der Besitz des privaten Schlüssels bewiesen, ohne dass er übertragen wurde (1 Punkt). Wer in die Datei schreiben kann, kann sich also selbst Zugang verschaffen – sie muss vor Schreibzugriffen anderer geschützt sein.

• Eintrag 1 (Ed25519, Cem): modernes, sicheres Verfahren, eindeutig einer Person zugeordnet – behalten; den privaten Schlüssel auf dem Notebook mit einer Passphrase schützen. (1 Punkt)
• Eintrag 2 (RSA 1024 Bit, alter Server): Die Schlüssellänge gilt als zu kurz (empfohlen sind mindestens 3000 Bit oder gleich Ed25519); der Server von 2016 ist vermutlich außer Betrieb, und niemand weiß, wer den privaten Schlüssel noch hat – entfernen, falls ein automatischer Zugang wirklich gebraucht wird, durch einen neuen Ed25519-Schlüssel ersetzen. (2 Punkte)
• Eintrag 3 (Praktikum 2025): Das Praktikum ist vorbei – entfernen. Schlüssel sollten beim Ausscheiden von Personen sofort gelöscht und die Datei regelmäßig überprüft werden. (1 Punkt)

Geg.: v = 10^{12}\ \tfrac{\text{Schlüssel}}{\text{s}}, Schlüssellängen n_{\text{DES}} = 56 Bit, n_{\text{AES}} = 128 Bit

Ges.: t_{\text{DES}} in h, t_{\text{AES}} in a

\begin{aligned} \text{I:}\quad N &= 2^{n} \\ \text{II:}\quad v &= \frac{N}{t} &&\quad | \cdot t \quad | : v \\ t &= \frac{N}{v} \\ \text{I in II:}\quad t &= \frac{2^{n}}{v} \\ t_{\text{DES}} &= \frac{2^{56}}{10^{12}\ \tfrac{1}{\text{s}}} = \frac{72\,057\,594\,037\,927\,936}{10^{12}}\ \text{s} \approx 72\,057{,}594\ \text{s} \\ &= \frac{72\,057{,}594\ \text{s}}{3600\ \tfrac{\text{s}}{\text{h}}} \approx \underline{\underline{20{,}016\ \text{h}}} \\ t_{\text{AES}} &= \frac{2^{128}}{10^{12}\ \tfrac{1}{\text{s}}} \approx 3{,}403 \cdot 10^{26}\ \text{s} \\ &= \frac{3{,}403 \cdot 10^{26}\ \text{s}}{365{,}25 \cdot 24 \cdot 3600\ \tfrac{\text{s}}{\text{a}}} \approx \underline{\underline{1{,}078 \cdot 10^{19}\ \text{a}}} \end{aligned}

DES ist in weniger als einem Tag vollständig durchsucht (im Mittel nach der Hälfte, also rund 10 h) und damit unsicher. Für AES-128 bräuchte der Angreifer knapp das Milliardenfache des Alters des Universums (ca. 1{,}4 \cdot 10^{10} a). Bewertung: Formel/Ansatz 1 Punkt, DES 1 Punkt, AES 1 Punkt, Vergleich 1 Punkt.

• Beim ersten Verbinden hat SSH den öffentlichen Host-Schlüssel des Servers in known_hosts gespeichert und vergleicht ihn bei jeder Verbindung mit dem Schlüssel, den der Server vorlegt. (1 Punkt)
• Nach einer Neuinstallation hat der Server neue Host-Schlüssel – die Meldung ist also erwartbar. Genauso sähe aber ein Man-in-the-Middle aus, der sich als Server ausgibt. (1 Punkt)
• Vorgehen: den Fingerabdruck (Hashwert) des neuen Host-Schlüssels auf einem sicheren Weg ermitteln, z. B. über die Serverkonsole des Hosters mit ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub, und mit dem angezeigten Wert vergleichen. Nur wenn beide übereinstimmen, den alten Eintrag mit ssh-keygen -R <Servername> löschen und neu verbinden. (1 Punkt)

Der Code bildet nur einen einfachen SHA-256-Hashwert ohne geheimen Schlüssel. Ein Angreifer kann zu jeder selbst erfundenen Meldung denselben Hashwert berechnen und mitschicken – die Prüfung ergibt dann immer „echt“. (1 Punkt) So erkennt man höchstens zufällige Übertragungsfehler, aber weder gezielte Veränderung noch den Absender; echte Meldungen der SchließTec würden sogar abgelehnt, weil deren Wert ein HMAC ist. (1 Punkt)

• CSB-Rad berechnet selbst einen HMAC-SHA256 aus Meldung und vereinbartem geheimem Schlüssel und vergleicht ihn mit dem mitgeschickten Wert; ohne den Schlüssel kann niemand einen passenden Wert erzeugen. Stimmt er, ist die Meldung unverändert (Integrität) und stammt von jemandem, der den Schlüssel kennt (Authentizität). (2 Punkte)

import hashlib
import hmac

def meldung_echt(body: bytes, signatur: str, schluessel: bytes) -> bool:
    erwartet = hmac.new(schluessel, body, hashlib.sha256).hexdigest()
    return hmac.compare_digest(signatur, erwartet)   # Vergleich in konstanter Zeit

• Gegen Wiedereinspielen: Zeitstempel oder eindeutige Meldungsnummer in den HMAC einbeziehen und Meldungen ablehnen, die zu alt sind oder deren Nummer schon verarbeitet wurde. (1 Punkt)

• Signatur des Servers prüfen: Zeile 6 (öffentlicher Schlüssel, ggf. mit Zeile 5). Der Sitzungsschlüssel für die Vertraulichkeit entsteht bei TLS 1.3 per Diffie-Hellman; ein ECDSA-Schlüssel kann ohnehin nicht verschlüsseln. (1 Punkt)
• Bindung und Authentizität: Zeile 8 (Signatur der CA, die Inhaber und Schlüssel bestätigt; Zeilen 2 und 4 als Ergänzung richtig). Der Fingerabdruck (Zeile 9) ist nur ein vom Browser berechneter Hashwert über das Zertifikat und belegt allein nichts. (1 Punkt)

Je Fall 1 Punkt Niveau, 1 Punkt Begründung:

• ga) einfache elektronische Signatur: Name unter der E-Mail genügt; interne Abstimmung ohne besondere Formvorschrift und mit geringer Beweisanforderung.
• gb) fortgeschrittene elektronische Signatur: eindeutig CSB-Rad zugeordnet, mit einem Schlüssel unter alleiniger Kontrolle erstellt, nachträgliche Änderungen werden erkannt – z. B. PDF-Signatur mit einem Zertifikat von CSB-Rad. Eine Schriftform ist nicht vorgeschrieben, die qualifizierte Signatur wäre unnötig aufwendig.
• gc) qualifizierte elektronische Signatur (QES): Nur sie ist der handschriftlichen Unterschrift gleichgestellt und ersetzt die gesetzliche Schriftform (§ 126a BGB); sie beruht auf einem qualifizierten Zertifikat eines qualifizierten Vertrauensdiensteanbieters nach Identitätsprüfung und einer sicheren Signaturerstellungseinheit.

• Jeder Block enthält den Hashwert des vorherigen Blocks; sein eigener Hashwert wird über seine Daten und diesen Vorgänger-Hashwert gebildet. (1 Punkt)
• Ändert der Händler den alten Eintrag, ändert sich wegen des Lawineneffekts dessen Hashwert. Der im folgenden Block gespeicherte Vorgänger-Hashwert passt nicht mehr – die Kette ist ab dieser Stelle gebrochen. (1 Punkt)
• Die anderen Teilnehmenden besitzen eigene Kopien und erkennen die Abweichung; ohne Konsens wird die veränderte Kette nicht anerkannt. Um die Änderung zu verbergen, müsste er alle folgenden Blöcke neu berechnen und die Mehrheit überzeugen. (1 Punkt)

Erwartet wird eine begründete Entscheidung mit zwei Argumenten (je 1 Punkt), z. B.: Eine gemeinsame Datenbank reicht hier aus – sie ist einfacher zu betreiben und schneller, Fehler und Löschpflichten (DSGVO) lassen sich umsetzen, und die Partner vertrauen CSB-Rad als Betreiber ohnehin. Eine Blockchain lohnt sich erst, wenn viele Beteiligte zusammenarbeiten, die keinem zentralen Betreiber vertrauen wollen, denn der Betreiber einer Datenbank könnte auch das Änderungsprotokoll verändern. Die Gegenposition ist mit passender Begründung ebenfalls richtig.

1. 6 (4 + 2) · b) 8 (6 + 2) · c) 6 (4 + 2) · d) 13 (2 + 4 + 4 + 3) · e) 5 (2 + 3) · f) 2 · g) 6 · h) 5 (3 + 2) · Summe 51 Punkte

Zwei aus (je 2 Punkte):

• Identität prüfen und Zertifikate ausstellen: Die CA prüft (ggf. über eine Registrierungsstelle), ob der Antragsteller die Domain bzw. Identität besitzt, und signiert dann das Zertifikat mit ihrem privaten Schlüssel; dadurch wird der öffentliche Schlüssel vertrauenswürdig an den Inhaber gebunden.
• Zertifikate verwalten und sperren: Sie veröffentlicht Zertifikate und deren Status und widerruft kompromittierte Zertifikate über Sperrlisten (CRL) bzw. OCSP.
• Vertrauensanker schützen: Sie schützt ihren privaten Schlüssel (HSM, Offline-Root), denn darauf beruht das Vertrauen aller Clients.

1. bc-app: externe CA (1 Punkt). Argumente (je 1 Punkt): Gäste nutzen eigene, nicht verwaltete Geräte, auf denen nur öffentliche Stammzertifikate installiert sind – ein Zertifikat der Schul-CA würde Warnungen auslösen; keine Verteilung eines Stammzertifikats nötig; öffentliche Domain kann automatisiert per ACME bestätigt werden, oft kostenlos.
2. MQTT-Broker: interne CA (1 Punkt). Argumente (je 1 Punkt): Nur eigene, verwaltete Geräte (Türschilder, Infomonitore) verbinden sich, das Stammzertifikat kann bei der Einrichtung eingespielt werden; interne Namen und Adressen kann keine öffentliche CA bestätigen; volle Kontrolle über Laufzeiten und sofortige Ausstellung; keine Abhängigkeit von externem Anbieter.

Andere schlüssige Entscheidungen mit passenden Argumenten sind ebenfalls richtig.

Je Schritt 1 Punkt, z. B.:

1. Auf bc-app ein Schlüsselpaar erzeugen; den privaten Schlüssel mit restriktiven Dateirechten bzw. Passwort schützen.
2. Eine Zertifikatsanforderung (CSR) mit dem öffentlichen Schlüssel und dem Domainnamen barcamp.rrb-bielefeld.example erstellen.
3. Den CSR bei der CA einreichen; die CA prüft die Kontrolle über die Domain und stellt das signierte Zertifikat aus (bei ACME automatisch).
4. Zertifikat und Zwischenzertifikat auf dem Webserver installieren und in der Konfiguration einbinden, Dienst neu laden.
5. HTTPS testen, HTTP auf HTTPS umleiten, veraltete TLS-Versionen abschalten.
6. Automatische Erneuerung einrichten und überwachen.

Vier aus: Version, Seriennummer, Inhaber (Subject, Subject Alternative Name), öffentlicher Schlüssel des Inhabers mit Algorithmus, Aussteller (CA), Gültigkeitszeitraum, Verwendungszweck (Key Usage), Signaturalgorithmus, Signatur der CA. Je Bestandteil 1 Punkt. (Der Fingerabdruck ist kein Bestandteil, sondern wird berechnet.)

Je Schritt 1 Punkt:

1. ClientHello: Browser sendet unterstützte TLS-Versionen und Cipher Suites, Zufallszahl und seinen Diffie-Hellman-Anteil.
2. ServerHello: Server wählt Version und Cipher Suite und sendet seinen Diffie-Hellman-Anteil.
3. Beide berechnen daraus denselben Sitzungsschlüssel, ohne ihn zu übertragen; der weitere Handshake ist bereits verschlüsselt.
4. Server sendet Zertifikat (mit Zwischenzertifikat) und eine Signatur über den Handshake (CertificateVerify) mit seinem privaten Schlüssel.
5. Browser prüft Zertifikatskette bis zur Root-CA, Gültigkeit, Domainnamen und Sperrstatus sowie die Signatur; beide Seiten senden Finished.
6. Die Nutzdaten werden symmetrisch (z. B. AES-GCM) mit dem Sitzungsschlüssel verschlüsselt übertragen.

Eine Darstellung des älteren Ablaufs mit Schlüsseltransport per RSA erhält höchstens 4 Punkte, weil er in TLS 1.3 nicht mehr vorkommt.

• Korrektur Satz 1 (1 Punkt): Einen Sitzungsschlüssel per öffentlichem Schlüssel zu transportieren, war bei älteren TLS-Versionen möglich; TLS 1.3 kennt dieses Verfahren nicht mehr.
• Korrektur Satz 2 (1 Punkt): Diffie-Hellman (z. B. X25519) wird bei TLS 1.3 bei jeder Verbindung verwendet, auch mit Zertifikat.
• Aufgabe von Diffie-Hellman (2 Punkte): Browser und Server schicken sich nur öffentliche Anteile, die sie aus geheimen Zufallswerten berechnet haben; aus dem eigenen Geheimnis und dem fremden Anteil ergibt sich auf beiden Seiten derselbe Sitzungsschlüssel. Mitlesende können ihn nicht berechnen. Weil die Zufallswerte nach der Verbindung verworfen werden, bleiben alte Sitzungen auch bei späterem Diebstahl des Serverschlüssels geschützt (Forward Secrecy).
• Aufgabe des Schlüsselpaars (1 Punkt): Es dient nur noch der Authentifizierung: Der Server signiert den Handshake mit seinem privaten Schlüssel, der Browser prüft mit dem öffentlichen Schlüssel aus dem Zertifikat. Ohne diese Signatur könnte sich ein aktiver Man-in-the-Middle in den Diffie-Hellman-Austausch einklinken.

• Was signiert wird (2 Punkte): Die CA signiert nicht den ganzen Zertifikatsinhalt, sondern dessen Hashwert – hier mit SHA-1. Der Client bildet den Hashwert des vorgelegten Zertifikats selbst und prüft, ob die Signatur der CA dazu passt. Die Signatur gilt also für jeden Inhalt mit demselben Hashwert.
• Kollision (2 Punkte): Für SHA-1 lassen sich inzwischen mit vertretbarem Aufwand zwei verschiedene Eingaben mit gleichem Hashwert erzeugen, deren Anfang der Angreifer selbst wählt. Er könnte einen harmlosen Antrag so vorbereiten, dass die Signatur der CA auch für ein zweites, gefälschtes Zertifikat gilt (z. B. für einen anderen Servernamen oder mit CA-Rechten).
• Bewertung (2 Punkte): Die Aussage greift zu kurz. Entscheidend ist nicht das schon ausgestellte Zertifikat, sondern dass die CA überhaupt noch mit SHA-1 signiert; außerdem lehnen aktuelle Browser und Betriebssysteme SHA-1-Signaturen ab, sodass Ausfälle drohen. Daher: Zertifikat sofort mit SHA-256 neu ausstellen, die CA auf SHA-256 umstellen und prüfen, ob noch weitere SHA-1-Zertifikate im Einsatz sind. Eine Zustimmung ist nur mit Punkten zu bewerten, wenn sie die Kollisionsgefahr erkennt und z. B. auf ein abgeschottetes Netz mit kurzer Restlaufzeit beschränkt wird.

1. 10 (4 + 6) · b) 9 (5 + 4) · c) 11 (6 + 5) · d) 6 · Summe 36 Punkte

• Die Firewall baut selbst eine TLS-Verbindung zum echten Webserver auf und prüft dort dessen Zertifikat. (1 Punkt)
• Dem Browser legt sie ein Zertifikat für dieselbe Domain vor, das sie im Moment des Aufrufs erzeugt und mit ihrer eigenen CA signiert – daher der Aussteller. (1 Punkt)
• Das Stammzertifikat dieser CA (bzw. der CSB-Root-CA, unter der sie hängt) ist über die Geräteverwaltung auf allen Firmengeräten als vertrauenswürdig hinterlegt; die Kette ist für den Browser also gültig, eine Warnung bleibt aus. (1 Punkt)
• Zwischen beiden Verbindungen liegen die Daten entschlüsselt vor und werden geprüft. Die Firewall ist ein gewollter Man-in-the-Middle – kein Angriff, sondern die eingeschaltete TLS-Inspection. (1 Punkt)

• Sicherheit, dafür (1 Punkt): Schadsoftware, Phishing-Inhalte und Datenabfluss werden auch in verschlüsselten Verbindungen sichtbar; ohne Inspection sieht die Firewall nur den Servernamen.
• Sicherheit, dagegen (1 Punkt): Die Firewall-CA wird zum lohnenden Ziel – wer ihren Schlüssel erbeutet, kann jede Verbindung fälschen; dazu kommen hohe Rechenlast und Anwendungen, die nicht mehr funktionieren (siehe b).
• Datenschutz (1 Punkt): Ohne Ausnahmen werden auch Onlinebanking, Gesundheitsportale und private Nachrichten der Beschäftigten entschlüsselt; das ist ein erheblicher Eingriff, der Betriebsrat hat mitzubestimmen, die Datenschutzbeauftragte ist zu beteiligen.
• Regelung (2 Punkte): z. B. Ausnahmelisten für Kategorien wie Banking, Gesundheit und Behörden; private Internetnutzung in einer Betriebsvereinbarung regeln oder untersagen; Beschäftigte informieren; nur automatisierte Prüfung, Einsicht in Inhalte nur im begründeten Einzelfall nach Vier-Augen-Prinzip; Protokolle kurz aufbewahren.

Je Ursache 1 Punkt, je Lösung 1 Punkt. Die Ursachen 4 und 5 hätten auch im Browser Fehler ausgelöst.

• Maßnahme 1: Die Datei bleibt in der Git-Historie und in allen Klonen erhalten; wer Lesezugriff hatte, kann sie längst kopiert haben. (1 Punkt)
• Maßnahme 2: Wer die alte Datei samt altem Passwort besitzt, entschlüsselt sie weiterhin; ein neues Passwort ändert den Schlüssel selbst nicht. (1 Punkt)

Der private Schlüssel der Zwischen-CA muss deshalb als kompromittiert gelten: Damit ließen sich beliebige Zertifikate ausstellen, denen alle CSB-Geräte vertrauen.

• Reihenfolge (2 Punkte): sicherheitsorientiert 3 → 4 → 5, parallel dazu 6, zum Schluss 7: Die Sperrung kommt zuerst, damit mit dem gestohlenen Schlüssel ausgestellte Zertifikate sofort abgelehnt werden; Ausfälle bis zum Austausch werden in Kauf genommen. Ebenfalls richtig: 4 und 5 innerhalb weniger Stunden vorbereiten und erst dann sperren, wenn die Abwägung zwischen Ausfallzeit und Risiko begründet wird.
• Maßnahme 5 (2 Punkte): Nach der Sperrung gilt die Kette über die alte Zwischen-CA nicht mehr – alle Server, Notebooks, Tablets und VPN-Zugänge mit alten Zertifikaten fallen aus. Ohne Sperrung wiederum blieben gefälschte Zertifikate gültig. Nur der vollständige Austausch stellt Betrieb und Vertrauen wieder her.

Je Eintrag 2 Punkte (1 Punkt für die richtige Schlüsselart, 1 Punkt für die richtige Person).

1. 9 (4 + 5) · b) 6 · c) 6 (2 + 4) · d) 8 · Summe 29 Punkte

• Gelöst (1 Punkt): Ein langer, zufälliger PSK lässt sich nicht mehr erraten oder durchprobieren.
• Nicht gelöst (2 Punkte): Es bleibt ein gemeinsames Geheimnis für alle. Es steht in jeder Konfiguration, kann weitergegeben, abgeschrieben oder erfragt werden, und Anmeldungen lassen sich keiner Person zuordnen.
• Beispiel Ausscheiden (2 Punkte): Mit PSK müsste der Schlüssel auf dem Server und bei allen übrigen Administrator*innen gleichzeitig geändert werden – sonst behält die Ausgeschiedene Zugang. Mit Client-Zertifikaten wird nur ihr Zertifikat gesperrt, alle anderen arbeiten weiter. Liegt der private Schlüssel zudem nicht exportierbar im TPM oder auf einer Smartcard, kann er auch nicht kopiert worden sein.

Der Aufwand für eine PKI (Ausstellen, Verteilen, Erneuern, Sperren) darf als Gegenargument genannt werden; er ändert die Bewertung bei mehreren Administrator*innen aber nicht.

• cipher BF-CBC: Blowfish arbeitet mit nur 64 Bit Blockgröße; bei großen Datenmengen werden Angriffe auf wiederkehrende Blöcke möglich (Sweet32), CBC sichert die Integrität nicht selbst. Ersetzen durch AES im Modus GCM, bei aktuellen OpenVPN-Versionen z. B. data-ciphers AES-256-GCM:CHACHA20-POLY1305. (2 Punkte)
• auth MD5: MD5 gilt wegen Kollisionen als gebrochen. Ersetzen durch auth SHA256; bei GCM sichert das Verfahren die Nutzdaten selbst, auth betrifft dann nur noch den Steuerkanal. (2 Punkte)
• tls-version-min 1.0: TLS 1.0 ist veraltet und unsicher. Ersetzen durch tls-version-min 1.3 (mindestens 1.2). (1 Punkt)
• remote-cert-tls server: beibehalten – der Client akzeptiert nur ein Zertifikat, das für die Rolle „Server“ ausgestellt ist; ein anderes Client-Zertifikat kann sich so nicht als VPN-Server ausgeben. (1 Punkt)

Je Zeile 1 Punkt (6 Punkte). Empfehlungen (je 1 Punkt): (1) AES (z. B. AES-256-GCM); (2) SHA-256 (besser: signierte Hashwerte bzw. HMAC, damit ein Angreifer nicht Datei und Hash austauscht); (3) Ed25519-Schlüsselpaare.

Drei aus (je 2 Punkte: Argument + Bezug zu Let’s Meet):

• Nur noch sichere Verfahren: Veraltete Cipher Suites sind entfernt, nur authentifizierte Verschlüsselung (AES-GCM, ChaCha20-Poly1305) bleibt – Fehlkonfigurationen sind kaum möglich, die personenbezogenen Daten der Nutzenden sind besser geschützt.
• Forward Secrecy: Jeder Schlüsselaustausch nutzt Einmalschlüssel; aufgezeichneter Verkehr lässt sich auch dann nicht entschlüsseln, wenn der private Serverschlüssel später gestohlen wird – Profil-, Chat- und Standortdaten der Nutzenden bleiben auch rückwirkend geschützt.
• Verschlüsselter Handshake: Das Serverzertifikat und alle Handshake-Nachrichten nach dem ServerHello sind verschlüsselt; wer z. B. im öffentlichen WLAN mitliest, erfährt weniger darüber, mit welchen Diensten die App spricht.
• Schneller: Der Handshake braucht nur einen Hin- und Rückweg – das verkürzt die Ladezeit der App gerade im Mobilfunknetz.

Ergänzend: Die App-Clients (aktuelle Android- und iOS-Versionen, Browser) beherrschen TLS 1.3, eine Ausnahme ist also nicht nötig.

Gründe, drei aus (je 1 Punkt): Verschlüsselte Spalten lassen sich nicht mehr sinnvoll durchsuchen, sortieren, gruppieren oder indizieren (z. B. Suche nach Aktivitäten in der Nähe); jede Abfrage muss ent- und verschlüsseln, die Leistung sinkt; der Schlüssel muss der Anwendung ohnehin zur Verfügung stehen, gegen Angriffe über die Anwendung hilft es also kaum; Schlüsselverwaltung wird aufwendig, ein verlorener Schlüssel macht alle Daten unbrauchbar.

Bessere Lösung (2 Punkte): Datenträger und Datensicherungen vollständig verschlüsseln, nur besonders sensible Felder (z. B. Telefonnummern, Ausweisdaten der Verifizierung) zusätzlich einzeln verschlüsseln, Passwörter als bcrypt-/Argon2id-Hash speichern, Verbindungen per TLS, dazu Zugriffsrechte nach dem Minimalprinzip.

1. 5 · b) 6 · c) 9 · d) 6 · e) 5 · Summe 31 Punkte