Wissenschaftlicher Teil

Ausgangspunkt

E-Mails sind nach wie vor eines der zentralen Kommunikationsmittel im digitalen Zeitalter. Trotz ihrer weitreichenden Verbreitung sind E-Mails in weiten Teilen unsicher, denn das zugrunde liegende Protokoll hinter E-Mail (SMTP) (RFC 5321) hat keine Mechanismen, die eine Authentizität oder Integrität des Absenders feststellen. Standardmäßig sind E-Mails zusätzlich nicht verschlüsselt, das bedeutet, die Nachrichten sind ohne weiteres im Klartext auf den E-Mail-Servern lesbar.

Daraus resultieren erhebliche Bedrohungen für Privatpersonen und Unternehmen. Phishing- oder Ransomware-Angriffe stellen nur einen kleinen Teil der Gefahren dar. Um diesen Risiken zu begegnen, wurden verschiedene Sicherheitsmaßnahmen entwickelt, darunter Protokolle zur Authentifizierung wie:

Weitere Sicherheitsmaßnahmen umfassen die Transportverschlüsselung von Server zu Server mittels TLS (RFC 8446) sowie Ende-zu-Ende-Verschlüsselung mit S/MIME (RFC 8551) oder OpenPGP (RFC 4880).

Trotz dieser Fortschritte bleibt die Implementierung und Nutzung dieser Technologien eine Herausforderung, insbesondere in Bezug auf Benutzerfreundlichkeit, Kompatibilität und flächendeckende Durchsetzung.

Protokoll

Aufbau

  • Protokoll beschreibung
    • IMPACT
      • create
      • register
      • challenge und response
    • challenge-email
    • response-email
    • deliver-email
  • Sicherheitsannahmen

Protokoll beschreibung

  • Ein Endnutzer kann das Ausstellen eines PGP-Zertifikates von einem beliebigen Endgerät aus beginnen. Es gibt dabei keine Einschränkungen, ob von einem Email-Client-UI, der Kommandozeile oder einem anderen Gerät. Es ist dabei egal, welches Endnutzer-UI genutzt wird.
  • Schritt 1: Der IMPACT-Client beginnt die Zertifikats-Ausstellung mit dem Versenden einer POST-Request an den Server-Endpunkt /user. Genauer beschrieben im Abschnitt IMPACT-CREATE.
  • Schritt 2: Der IMPACT-Server prüft die mitgelieferten Parameter, darauf ob der gewünschte Username schon vergeben ist und antwortet entsprechend auf die POST-Request. Wenn vorher noch nicht vergeben, ist der Account mit Username und Passwort nun aktiv.
  • Schritt 3: Der Endnutzer gibt zusätzlich zu seinen Login-Daten eine Email-Adresse mit einem zu signierenden Public-Key an. Dazu wird eine Post-Request an den Server-Endpunkt /certificate/challenge geschickt. Genauer beschrieben im Abschnitt IMPACT-REGISTER.
  • Schritt 4: Der Impact-Server verarbeitet die eingegangenen Informationen und generiert daraus 2 Token. Einer dieser Token wird als HTTP-Token und der andere als MAIL-Token angesehen. Die Token müssen base64url-encoded sein [RFC4648]. Der Impact-Server muss für jede Signierungs-Anfrage neue Token generieren.
  • Schritt 5: Der Server antwortet auf die Post-Request von IMPACT-Register mit der Challenge-Id und dem HTTP-Token. Das json Objekt muss folgenden Aufbau haben:
{"challenge_id":"<CHALLENGE-ID>","http_token":"<HTTP-TOKEN>"}

  • Schritt 6: Der Impact-Server generiert die Impact-Challenge-Email mit dem Betreff “ACME: ”. Der Aufbau der Email ist beschrieben in Abschnitt challenge-email.

  • Schritt 7: Signierung der generierten Challenge-Email mit Private-Key des Impact-Servers und Verschlüsselung mit Public-Key des Endnutzers. Genauer im Abschnitt challenge-email.

  • Schritt 8: Abschicken durch den Server, übertragen der Email und Empfangen der Email durch den Endnutzer

  • Schritt 9: Der Impact-Client entschlüsselt mit dem entsprechenden Private-Key die empfangene Impact-Challenge-Email und prüft die darin enthaltene Signatur des Impact-Servers auf Gültigkeit.

  • Schritt 10: Der Impact-Client fügt den HTTP-Token und den Email-Token in der Response-Email zusammen, signiert und verschickt sie. Der Email Betreff muss mit “Re: ACME: " beginnen. Genauer im Abschnitt response-email.

  • Schritt 11: Entschlüsseln der Email, auslesen der Token vom Email-Body.

  • Schritt 12: Auswerten der erhaltenen Tokens auf Gültigkeit und Signieren des Public-Keys des Endnutzers mit dem Private-Key vom Impact-Server.

  • Schritt 13: Der Impact-Server muss die Deliver-Email mit dem Private-Key des Impact-Server signieren und kann optional die Email mit dem Public-Key vom Endnutzer verschlüsseln. Dabei muss Der Betreff nicht verschlüsselt werden, aber muss mit “ACME: " beginnen. Der Email wird der signierte Public-Key des Endnutzer angehangen.

IMPACT-CREATE:

  • Über den CREATE-Request lässt sich ein Account für die Certification Authority anlegen.
  • Gesendet wird eine Post-Request an den API-Endpunkt /user, der json format erwartet mit 2 variablen
    • username, der Username des neuen Accounts
    • password, das Passwort des neuen Accounts
  • Format application/json
POST /user HTTP/1.1
Host: 
Content-Type: application/json

{"username":"<user>","password":"<secret>"}

IMPACT-Register

  • Im Schritt IMPACT-Register wird zusätzlich zu einem bestehendem Account, eine Email-Adresse und ein zur Email-Adresse dazugehöriger Public-Key, bzw. Zertifikat zur Signierung angegeben.
  • Es sollte möglich sein, ein optionales Widerrufungs-Zertifikat mit hochladen zu können.
  • Gesendet wird ein Post-Request an den API-Endpunkt /certificate/challenge mit den Variable
    • username, der Username eines bestehenden Account
    • password, das zum Username gehörende Passwort
    • email, die zu signierende Email
    • armored_public_key, als ASCII konvertierter zur Email-Adresse passender Öffentlicher-Schlüssel
    • revocation_cert (optional), zum Public-Key gehörendes Widerrufungs-Zertifikat
POST /certificate/challenge
Host:
Content-Type: application/json

\{ "username":"<user>", "password":"<secret>", "email":"<email>", "armored_public_key":" 
<public_pgp_key>", "revocation_cert":"<revocation_certificate>" \}

IMPACT-Challenge und Response

Eine Email-Adresse kann mithilfe eines PGP-Schlüssels von einer Certification Authority verifiziert werden. Das Challenge-Response-Verfahren beweist, dass die Person sowohl die Email-Adresse als auch den zugehörigen privaten Schlüssel kontrolliert.

Der Server sendet eine Challenge bestehend aus zwei Tokens:

  • Mail-Token, siehe challenge-email
  • HTTP-Token Also Antwort auf IMPACT-Register
{"challenge_id":"<CHALLENGE-ID>","http_token":"<HTTP-Token>"}

Der Mail-Token wird verschlüsselt an die angegebene Email-Adresse gesendet und muss vom Empfänger mit dem privaten Schlüssel entschlüsselt werden.

challenge-email

  1. Das Subject-Header-Feld hat die folgende Syntax: “ACME: ”, wobei auf das Präfix “ACME:” ein gefaltetes Leerzeichen (FWS; siehe [RFC5322]) und dann der folgt, der base64url-kodiert ist.
  2. Es muss der US-ASCII-Zeichensatz verwendet werden.
  3. Das From-Header-Feld muss die gleiche E-Mail-Adresse sein, die im “from”-Feld des Challenge-Objekts angegeben ist.
  4. Das To-Header-Feld muss die E-Mail-Adresse der Entität sein, die die PGP-Signierung angefordert hat.
  5. Die Nachricht kann ein Reply-To und/oder CC-Header-Feld enthalten.
  6. Um die Authentizität einer Challenge-Email zu beweisen, muss sie mit dem IMPACT-Server Public-Key signiert und mit dem Client-Public-Key verschlüsselt werden.
  7. Der Body der Challenge-Email sollte der Einfachheit halber vom Typ application/pgp-signature sein und auch eine von Menschen lesbare Erklärung des Zwecks der Nachricht enthalten.

Ein mit dieser Spezifikation konformer E-Mail-Client, der feststellt, dass eine bestimmte “Challenge”-E-Mail die oben beschriebene Validierung nicht besteht, muss die Challenge ignorieren und wird daher keine respone-email erzeugen. Um die Fehlersuche zu erleichtern, sollten solche fehlgeschlagenen Validierungen protokolliert werden.

Beispiel für eine Challenge-Email.

From: sirealca@hs-bremerhaven.de
Subject: ACME: 0PIAr5KXzZfw4rH6eRv45xDGoM-xMeAD5CdAQoZpTzU
To: mmuster@studenten.hs-bremerhaven.de
MIME-Version: 1.0
Date: Fri, 14 Mar 2025 12:24:05 +0000
Content-Type: multipart/encrypted;
boundary="I8ZFmTD29oVRsZ8sGNF4j8vs6Ly5uAm8fYbcT7cM";
protocol="application/pgp-encrypted"

--I8ZFmTD29oVRsZ8sGNF4j8vs6Ly5uAm8fYbcT7cM
Content-Type: application/pgp-encrypted
Content-Transfer-Encoding: 7bit

Version: 1
--I8ZFmTD29oVRsZ8sGNF4j8vs6Ly5uAm8fYbcT7cM
Content-Disposition: inline; filename="encrypted.asc"
Content-Type: application/octet-stream
Content-Transfer-Encoding: 7bit

-----BEGIN PGP MESSAGE-----

wV4DlCQfwtfPnAcSAQdAq7UWv6nlvWzsTKOeqFO032GXPEDd7NPRyPh92zeJZCUw
yGhOHw7MI/AzQkNehG6YD+thELBDQBLlSB7k3quBnGAM802UfPWV0S1j5kDe80nC
75HfACDe2qwb/csn2V1wYWs4ORYsFqWnh++GNy647MR9AnpY7kFffQ==
=02xA
-----END PGP MESSAGE-----

--I8ZFmTD29oVRsZ8sGNF4j8vs6Ly5uAm8fYbcT7cM--

response-email

  1. Das Subject-Header-Feld wird als Antwort auf die Challenge-Email gebildet (siehe Abschnitt 3.1). Seine Syntax ist die gleiche wie die der challenge-mail, außer dass ihm ein “Re:” vorangestellt werden kann, gefolgt von einem gefalteten Leerzeichen (FWS; siehe [RFC5322]).
  2. Das From-Header-Feld enthält die E-Mail-Adresse des Benutzers, der die PGP-Key-Signierung anfordert.
  3. Das To-Header-Feld der Antwort enthält den Wert aus dem Reply-To-Header-Feld der Challenge-Nachricht (falls gesetzt). Andernfalls enthält es den Wert aus dem From-Header-Feld der Challenge-Nachricht.
  4. Das Cc-Kopfzeilenfeld wird ignoriert, fallse es in der Response-Email vorhanden ist.
  5. List-* Header-Felder [RFC4021][RFC8058] muss fehlen (d.h. die Antwort kann nicht von einer Mailingliste kommen).
  6. Der Medientyp der Response-Email ist entweder text/plain oder multipart/alternative [RFC2046], mit text/plain als eine der Alternativen. (Beachten Sie, dass die Anforderung, multipart/alternative zu unterstützen, die Verwendung von Clients ermöglicht, die nicht immer reines text/plain erzeugen können, z. B. wenn sie auf text/html). Der text/plain-Body-Teil (unabhängig davon, ob er innerhalb von multipart/alternative steht oder nicht) muss einen Zeilenblock enthalten, der mit der Zeile “—–BEGIN ACME RESPONSE—–” beginnt, gefolgt von mindestens zwei Zeilen, die in base64url-encoded sind. HTTP-Token in Zeile eins (empfangen über HTTPS) und danach den Mail-Token (empfangen über E-Mail). (Beachten Sie, dass jede text/plain-Zeile mit CRLF abgeschlossen wird. Bloße LFs oder bloße CRs sind nicht erlaubt.) Wenn eine eingelesene Zeile keinem gesamten token entspricht, muss der Inhalt nach einem CRLF bis zum nächsten CRLF an die vorherige Zeile angehangen werden. Dies muss solange wiederholt werden, bis entweder ein gültiger token zusammengesetzt wurder, oder “—–END ACME RESPONSE—–” eingelesen wird. Aufgrund historischer Zeilenlängenbeschränkungen in E-Mails können Zeilenenden (CRLFs) frei in der Mitte des kodierten Digests eingefügt werden, so dass sie bei der Verarbeitung ignoriert werden müssen. Auf die letzte Zeile des verschlüsselten Digests folgt eine Zeile mit folgendem Inhalt
    “—–END ACME RESPONSE—–” Jeglicher Text vor und nach diesem Block wird ignoriert. Ein solcher Text könnte zum Beispiel erklären, was bei IMPACT-unwissenden Clients zu tun ist.
  7. Es besteht keine Notwendigkeit, eine andere Content-Transfer-Encoding-Kodierung als 7bit für den text/plain-Teil zu verwenden. Die Verwendung von quoted-printable oder base64 in einer “Antwort”-E-Mail ist nicht notwendig und sollte vermieden werden, obwohl sie erlaubt ist.
  8. Um die Authentizität einer Antwortnachricht zu beweisen, muss die Response-Email vom client signiert sein. Der Body der response email kann verschlüsselt sein. Zusätzlich kann auch der Betreff verschlüsselt sein.
Subject: Re: ACME: 0PIAr5KXzZfw4rH6eRv45xDGoM-xMeAD5CdAQoZpTzU
To: sirealca@hs-bremerhaven.de
From: "M. Muster" <mmuster@studenten.hs-bremerhaven.de>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

-----BEGIN ACME RESPONSE-----
0PIAr5KXzZfw4rH6eRv45xDGoM-xMeAD5CdAQoZpTzU
lWCYv1r8_rt8Sz9d496LUp9zLZwq80G7TYi6vG8FgqA
-----END ACME RESPONSE-----

Der Body der response Email sieht wie folgend aus.

-----BEGIN ACME RESPONSE-----
<HTTP-Token>
<EMAIL-Token>
-----END ACME RESPONSE-----

deliver-email

  1. Das Subject-Header-Feld hat die folgende Syntax: “ACME: Signed PGP-Key”, wobei auf das Präfix “ACME:” ein gefaltetes Leerzeichen (FWS; siehe [RFC5322]) und dann “Signed PGP-Key” folgt.
  2. Es muss der US-ASCII Zeichensatz verwendet werden.
  3. Das From-Header-Feld MUSS dieselbe E-Mail-Adresse sein wie der Signierschlüssel des IMPACT-Servers.
  4. Das To-Header-Feld MUSS die E-Mail-Adresse der Entität sein, die die PGP-Signierung angefordert hat.
  5. Die Nachricht darf kein Reply-To und/oder CC-Header-Feld enthalten.
  6. Im Anhang muss der vom IMPACT-Server zum TO header field gehörende signierte client-PGP-Key sein.
  7. Der Textkörper der Aufforderungsnachricht kann leer sein, sollte aber einen Text mit einer Erklärung für den Zweck der E-Mail enthalten.
  8. Der Content-Type muss multipart/signed oder multipart/encrypted (siehe [rfc1847]) sein.
  9. Die deliver-email vom IMPACT-Server muss mit dessen public-PGP-Key signiert sein. Der Betreff kann verschlüsselt sein. Der Body kann mit dem client-public-key verschlüsselt sein.
   From: sirealca@hs-bremerhaven.de
Subject: ACME: Signed PGP-Key
To: "M. Muster" <mmuster@studenten.hs-bremerhaven.de>
MIME-Version: 1.0
Date: Tue, 11 Mar 2025 12:22:40 +0000
Content-Type: multipart/signed;
 boundary="UAzd9R0Cmu8pDKiSRPnc72luFkw429catDN4vJSZ";
 protocol="application/pgp-signature"; micalg="pgp-sha256"

--UAzd9R0Cmu8pDKiSRPnc72luFkw429catDN4vJSZ
Content-Type: multipart/mixed; protected-headers="v1";
 boundary="------------6d490719b64443d88c5bb47329645b77"
Subject: ACME: Signed PGP-Key for "M. Muster"
 <mmuster@studenten.hs-bremerhaven.de>
From: sirealca@hs-bremerhaven.de
To: "M. Muster" <mmuster@studenten.hs-bremerhaven.de>

--------------6d490719b64443d88c5bb47329645b77
Content-Type: multipart/mixed;
 boundary="QQNIiSEZD8K5r4neaWFdAJ2lMZ4C9J0KMDMPmcHw"

--QQNIiSEZD8K5r4neaWFdAJ2lMZ4C9J0KMDMPmcHw
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

This is an automatically generated ACME challenge for email address ""M. Muster" <mmuster@studenten.hs-bremerhaven.de>". You can find your signed public PGP-Key attached to this email. If you haven't requested the verfication of
a PGP-Key for this email address, be very afraid.
--QQNIiSEZD8K5r4neaWFdAJ2lMZ4C9J0KMDMPmcHw
Content-Disposition: attachment;
 filename*0="OpenPGP_23DBA11B8C67D61716969B5C55C0A639DC6D5185.asc"
Content-Type: application/pgp-keys
Content-Transfer-Encoding: 7bit

-----BEGIN PGP PUBLIC KEY BLOCK-----
Comment: 23DB A11B 8C67 D617 1696  9B5C 55C0 A639 DC6D 5185
Comment: CA Root SIReAL <sirealca@hs-bremerhaven.de>

xjMEZ5JUHBYJKwYBBAHaRw8BAQdA13fwG04DNjPD/qyQMtqx3Tvkx0zmXCfOH06p
EieNK3/NK0NBIFJvb3QgU0lSZUFMIDxzaXJlYWxjYUBocy1icmVtZXJoYXZlbi5k
0YxWfzy5xWHbDQ==
=P4bS
-----END PGP PUBLIC KEY BLOCK-----

--QQNIiSEZD8K5r4neaWFdAJ2lMZ4C9J0KMDMPmcHw--
--------------6d490719b64443d88c5bb47329645b77
Content-Disposition: attachment;
 filename*0="SIGNED_KEY_\"M. Muster\" <mmuster@studenten.hs-bremerhaven.de>.asc"
Content-Type: application/pgp-keys
Content-Transfer-Encoding: 7bit

-----BEGIN PGP PUBLIC KEY BLOCK-----
Comment: 73A5 E4D0 E203 AE8D 5E1E  EF13 8BEF 82CF 9054 C6D8
Comment: M. Muster <mmuster@studenten.hs-bremerhaven.de>

xjMEZ3+4nRYJKwYBBAHaRw8BAQdALGeMZ0M/EAsHgApfzkh4h+AVpA+z9e/TDgyi
qhdgt3/NKHJlbmUgPHJzaW5uQHN0dWRlbnRlbi5ocy1icmVtZXJoYXZlbi5kZT7C
96AB
=FChr
-----END PGP PUBLIC KEY BLOCK-----

--------------6d490719b64443d88c5bb47329645b77--
--UAzd9R0Cmu8pDKiSRPnc72luFkw429catDN4vJSZ
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----

wr0EABYIAG8FgmfQKxAJEFTKWLP6RQTARxQAAAAAAB4AIHNhbHRAbm90YXRpb25z
LnNlcXVvaWEtcGdwLm9yZ1ViLt1d7aVvCBz3NXL1+qnc3yeFo/m0oekYXcnTSnf4
FiEEZpFEi371yqUQp4tjVMpYs/pFBMAAAM02AP9Cg24YKvzTQAiD5+t/4PUl9qM2
q5t7cmT37aZRj7oWkAEAqGLY08yLQjzhqkurI6pwNPQBjtp0aXcbRE9xESZLowE=
=skNm
-----END PGP SIGNATURE-----

--UAzd9R0Cmu8pDKiSRPnc72luFkw429catDN4vJSZ--

Sicherheitsannahmen und -eigenschaften

Genrelle Sicherheitsannahmen zum ACME Protokoll sind im RFC8555 zu finden. Im Folgenden wird etwas genauer beschrieben, welche Sicherheitsannahmen wir bei der Entwicklung getroffen haben und wie diese sich auf die Implementierung ausgewirkt haben.

Challenge-Response Verfahren

Beim Challenge-Response Verfahren gibt der Benutzer eine zu verifizierende E-Mail-Adresse mit einem dazugehörigem öffentlichen OpenPGP Schlüssel an. Ziel des Verfahrens ist es, zu verifizieren, dass der Benutzer der Besitzer dieser E-Mail-Adresse ist und gleichzeitig auch im Besitz des privaten Schlüssels ist, der zum öffentlichen Schlüssel passt. Für den Verifizierungsprozess haben wir angenommen, dass wenn man in der Lage ist E-Mails von einer E-Mail-Adresse zu lesen und zu versenden, dass man diese besitzt. Dies ist jedoch nicht immer der Fall, wie die folgenden Fälle es aufzeigen:

  1. In gewissen E-Mail-Systemen ist es möglich, E-Mails im Namen einer anderen Person zu versenden. Dies ist für den Absender nicht immer zu erkennen.

  2. Shared E-Mail-Accounts können von mehreren Personen kontrolliert werden. Bei der Verwendung einer solchen Adresse ist es also nicht identifizierbar, wer eine E-Mail nun verschickt hat.

  3. Ein weiterer Punkt sind kompromittierte E-Mail-Adressen. Wenn ein Angreifer es schafft Zugriff auf die E-Mail-Adresse des Opfers zu bekommen, dann kann er diese auch nutzen, um das Challenge-Response Verfahren zu durchlaufen.

Diese Beispiele zeigen, dass nur weil jemand in der Lage ist E-Mails einer Adresse zu lesen oder von dieser zu versenden, er nicht immer der Besitzer ist. Da sich diese Szenarien aus unserer Position aber nicht realistisch verhindern lassen, mussten wir diese Annahme beibehalten.

Spoofing

Das Verhindern von Spoofing liegt in der Verantwortung des E-Mail-Servers. Unser Protokoll führt keine Sicherheitsüberprüfungen (SPF, DKIM, etc.) für die eingehenden E-Mails durch und ist somit nicht in der Lage eine E-Mail, die gespoofed wurde, rauszufiltern.

DNS-Records

Ein E-Mail-System ist außerdem abhängig von DNS, was einen weiteren Angriffspunkt darstellt. Denn theoretisch könnte ein Angreifer es schaffen die DNS MX Records zu manipulieren und so zumindest temporär E-Mails abzufangen oder im Namen einer anderen Person zu versenden. Diese Art von Angriff kann durch unser System nicht realistisch verhindert werden, weswegen wir bei der Implementierung die Annahme getroffen haben, dass DNS vertrauenswürdig ist.

Softwarearchitektur

IMPACT

IMPACT (Internet Message Protection using Automated Certificate management and Transformation) ist ein modulares System zur Vereinfachung sicherer E-Mail-Kommunikation durch automatisierte Zertifikatsverwaltung. Basierend auf den RFCs 8555 (ACME) und 8823 (OpenPGP-Schlüsselsuche) ermöglicht es Nutzern die Erstellung von Schlüsselpaaren, ACME-Zertifizierungsprozesse und den Austausch öffentlicher Schlüssel.

Systemkomponenten Übersicht:

  1. Web-API

    • Verarbeitet HTTP-Anfragen von Frontends.
    • Kommuniziert mit dem ACME-Core über gRPC.
    • Implementiert Endpoints für Benutzerverwaltung, Zertifikatsprozesse und Schlüsselsuche.

  2. ACME-Core

    • Backend mit Datenbankanbindung (MariaDB).
    • Verantwortlich für Benutzerauthentifizierung, Zertifikatslebenszyklus und Schlüsselverwaltung.

  3. Mail-Worker

    • Verarbeitet E-Mails (Verschlüsselung, ACME-Protokolle).

  4. Thunderbird-Addon & Website

    • Frontend-Komponenten zur Nutzerinteraktion (Schlüsselgenerierung, ACME-Prozesssteuerung).

1. Web-Api

Die Web-API ist die zentrale Schnittstelle des IMPACT-Systems und ermöglicht die Kommunikation zwischen Frontend-Komponenten (Website/Thunderbird-Addon) und dem Backend (ACME-Core). Sie verarbeitet HTTP-Anfragen zur Benutzerverwaltung, Zertifikatserstellung und Schlüsselsuche, nutzt gRPC für die Backend-Kommunikation und gewährleistet Sicherheit durch CORS, Token-basierte Authentifizierung und verschlüsselte Datenübertragung.

Web-API Endpoints

1. Benutzerverwaltung

  • POST /user

    • Erstellt einen neuen Benutzer.
      • Request Body: { username, password }
      • Responses:
        • 201 Created bei Erfolg.
        • 400 Bad Request mit Fehlermeldung, falls Benutzer existiert (z. B.: “Hier krachts”).

  • GET /user/exists/<username>

    • Prüft, ob ein Benutzername bereits vergeben ist.
      • Response: { user_exists: bool }

  • POST /user/changePassword

    • Ändert das Passwort eines Benutzers.
      • Request Body: { username, current_password, new_password }
      • Responses:
        • 204 No Content bei Erfolg.
        • 400 Bad Request bei Fehlschlag.

2. Zertifikatsprozesse

  • POST /certificate/challenge
    • Startet eine ACME-Zertifikatsherausforderung.
      • Request Body: { username, password, email, armored_public_key,revocation_cert }
      • Response:
        • 201 Created mit { challenge_id, token_part2 } bei Erfolg.
        • 401 Unauthorized bei ungültigen Anmeldedaten.

3. Schlüsselsuche

  • GET /.well-known/openpgpkey/<domain>/hu/<local_hash>?l=<local-part>
    • Sucht öffentliche Schlüssel für eine E-Mail-Adresse (RFC 8823-konform).
      • Parameter: domain, local_hash, l (lokaler Teil der E-Mail).
      • Response: { keys: [String] } (Liste der PGP-Schlüssel).

2. Acme Core

Das Modul Acme Core ist eine zentrale Komponente zur Verwaltung von Benutzerkonten, Authentifizierung und öffentlichen Schlüsseln. Ebenso werden die ACME Prozessschnritte hier durchgeführt. Es nutzt gRPC für eine effiziente Kommunikation und MySQL als Datenbank. Das Modul besteht aus drei Kernkomponenten:

  • Der Account-Service: Verwaltet Benutzerkonten, einschließlich Erstellung, Authentifizierung und Passwortverwaltung.
  • Der KeyLookup-Service: Ermöglicht das Abrufen von signierten öffentlichen Schlüsseln, die mit bestimmten E-Mail-Adressen verknüpft sind.
  • Der Certificate-Service: Bietet Mechanismen zur Erstellung, Verschlüsselung und Validierung von Zertifikaten, einschließlich der Verwaltung von Widerrufszertifikaten.

Certificate-Service

Der Certificate-Service verwaltet die Ausstellung, Verschlüsselung und Überprüfung von signierten Schlüsseln. Zudem ermöglicht er die Speicherung und Wiederherstellung von Widerrufszertifikaten, um kompromittierte oder nicht mehr benötigte Schlüssel sicher zu widerrufen.

Hauptfunktionen

  1. Challenge-Prozess
  • challenge-Methode:
    • Generiert eine UUID als challenge_id.
    • Verschlüsselt das Widerrufszertifikat mit dem öffentlichen Schlüssel des Nutzers (PGP).
    • Speichert Challenge-Daten in der Datenbank (challenge-Tabelle).
    • Generiert zwei JWT-Token (token_part1 für HTTP, token_part2 für E-Mail).
    • Sendet eine Bestätigungs-E-Mail über den Mail-Worker.

ChallengeRequest Parameter:

message ChallengeRequest {
	string pubkey = 1;                          // Öffentlicher Schlüssel des Nutzers (ASCII-armored)
	string email = 2;                           // E-Mail-Adresse des Nutzers 
	optional string revocation_certificate = 3; // Optional: Widerrufszertifikat
	uint32 user_id = 4;                         // Benutzer-ID  
}
ChallengeResponse Parameter:
message ChallengeResponse {  
    string challenge_id = 1;           // Eindeutige ID der Herausforderung  
    string token_part1 = 2;            // JWT-Token für HTTP-Verifizierung  
    string email = 3;                  // E-Mail-Adresse des Nutzers  
}
  1. Solution-Verifikation
  • solution-Methode:
    • Überprüft die Gültigkeit beider JWT-Token (token_part1 und token_part2).
    • Validiert, ob die Tokens zur gleichen challenge_id gehören.
    • Signiert den öffentlichen Schlüssel des Nutzers mit dem privaten CA-Schlüssel (sign_key).
    • Speichert das signierte Zertifikat in der Datenbank (certificate-Tabelle).
    • Sendet das Zertifikat per E-Mail an den Nutzer.

SolutionRequest Parameter:

message SolutionRequest {  
    string token_part1 = 1;            // JWT-Token für HTTP-Verifizierung  
    string token_part2 = 2;            // JWT-Token für E-Mail-Verifizierung  
    string email = 3;                  // E-Mail-Adresse des Nutzers  
}

SolutionResponse Parameter:

message SolutionResponse {  
    string email = 1;                  // E-Mail-Adresse des Nutzers  
    string cert = 2;                   // Signiertes Zertifikat (ASCII-armored)  
}

Konfiguration

Der ACME-Core nutzt eine zentrale CONFIG-Variable mit folgenden Parametern:

  • Token-Gültigkeit: token_expiration_sec (Standard: 1 Stunde).
  • Signaturablauf: signature_expiration_days (Standard: 365 Tage).
  • CA-Schlüsselpfad: priv_sign_key_path (z. B. /etc/impact/ca_priv.key).
  • Mail-Worker-Adresse: mail_worker_address (z. B. http://mail-worker:8002).

Abhängigkeiten

  • OpenPGP: Schlüsselverwaltung und -signierung (sequoia-openpgp).
  • gRPC: Kommunikation mit der Web-API und dem Mail-Worker (tonic).
  • Datenbank: MariaDB-Anbindung über sqlx.
  • Token-Handling: JSON Web Tokens (jsonwebtoken).

Account-Service

Der Account-Service bietet eine zentrale Schnittstelle zur Verwaltung von Benutzerkonten. Alle Anfragen werden über gRPC abgewickelt, und die Benutzerdaten werden sicher in einer MySQL-Datenbank gespeichert.

Implementierte Funktionen

  1. Benutzer abrufen (get_user_by_username)

    • Ermittelt die Benutzer-ID anhand eines angegebenen Benutzernamens.

  2. Benutzer erstellen (create_user)

    • Prüft, ob der Benutzername bereits existiert.
    • Hasht das Passwort sicher mit Argon2 und speichert es in der Datenbank.

  3. Existenz eines Benutzers prüfen (user_exists)

    • Überprüft, ob ein Benutzer mit dem angegebenen Benutzernamen existiert.

  4. Benutzerauthentifizierung (auth)

    • Vergleicht das eingegebene Passwort mit dem gespeicherten Argon2-Hash.
    • Erfolgreiche Authentifizierung gibt eine Bestätigung zurück.

  5. Passwort ändern (change_password)

    • Stellt sicher, dass das alte Passwort korrekt ist.
    • Erst dann wird das neue Passwort gesetzt und erneut mit Argon2 gesichert.

Sicherheitsmechanismen

  • Argon2-Hashing für Passwörter: schützt vor Brute-Force-Angriffen.
  • gRPC mit Status-Codes: stellt eine sichere und effiziente Kommunikation sicher.
  • Transaktionen in SQL: garantieren Konsistenz bei Datenänderungen.

Sicherheitsmechanismen

JWT-Authentifizierung: Stellt sicher, dass nur autorisierte Benutzer Zertifikate abrufen oder widerrufen können. OpenPGP-Verschlüsselung: Sichert Zertifikate und Widerrufsdaten vor unbefugtem Zugriff. Datenbank-Sicherung: Speicherung von signierten Schlüsseln und Widerrufsinformationen in einer geschützten SQL-Datenbank.

KeyLookup-Service

Der KeyLookup-Service ermöglicht das Abrufen signierter öffentlicher Schlüssel, die mit einer E-Mail-Adresse verknüpft sind. Dies dient beispielsweise zur Validierung von Identitäten und zur verschlüsselten Kommunikation.

Implementierte Funktionen

  1. Öffentliche Schlüssel abrufen (get_key)

    • Sucht nach signierten öffentlichen Schlüsseln, die mit einer bestimmten E-Mail-Adresse verknüpft sind.
    • Gibt eine Liste der zugehörigen Schlüssel zurück.

  2. Datenbankabfrage (get_public_keys)

    • Führt eine SQL-Abfrage durch, um die passenden signierten öffentlichen Schlüssel aus der certificate-Tabelle abzurufen.
    • Verwendet eine JOIN-Abfrage mit der challenge-Tabelle, um sicherzustellen, dass die Schlüssel mit einer validierten E-Mail-Adresse verknüpft sind.

Sicherheitsmechanismen

  • Datenbank-Isolierung: Verhindert unbefugten Zugriff auf gespeicherte Schlüssel.
  • gRPC-Kommunikation: Stellt eine verschlüsselte Datenübertragung sicher.

3. Mail-Worker

Das Mail-Worker Modul hat die Aufgabe das Versenden und Verarbeiten von E-Mails zu übernehmen. Es kann von anderen Modulen über gRPC angesteurt werden und überwacht selbstständig das Postfach der Certification Authority. Es ist dem Nutzer überlassen, ob die E-Mails verschlüsselt oder unverschlüsselt an die CA gesendet werden.

Mail-Service

Hauptfunktionen

Beide der folgenden Funktionen werden durch das ACME-Core Modul aufgrufen. Alle E-Mails werden vor dem Versende signiert und der öffentliche Schlüssel der CA wird als Anhang mitgesendet.

  1. Send Challenge Email Wenn der Nutzer das Challene-Response-Verfahren gestartet hat, ist das Mail-Worker Modul dafür zuständig die Challenge Email an die zu verifizierende Email-Adresse zu senden. Die Challenge Email enthält den Email-Token und wird mit der Rust Library Sequioa verschlüsselt.

  2. Send Cerificate Sobald der Nutzer das Challenge-Response-Verfahren erfolgreich durchlaufen hat, wird ihm sein durch die CA signierter Key zugesendet.

Check E-Mails Methode

Diese Methode ruft über IMAP ungesehene E-Mails aus dem Postfach der CA ab, die den String “Re: ACME:” im Betreff enthalten. Abgerufene E-Mails werden wenn nötig mit der decrypt_email-Methode entschlüsselt und die darin enthaltenen Tokens werden anschliend extrahiert uns ans ACME-Core Modul gesendet.

Konfiguration

Das Mail-Worker Modul nutzt eine zentrale Config-Datei mit folgenden Parametern:

  • Pfad zum privaten Schlüssel der CA: priv_key_path (z.B. “./keys/private_key_pass.asc”)
  • Pfad zum öffentlichen Schlüssel der CA: pub_key_path (z.B. “./keys/public_key.asc”)
  • IMAP-Serveradresse: imap_server (z.B. “10.14.38.21”)
  • SMTP-Serveradresse: smtp_server (z.B. “10.14.38.21”)
  • IMAP-Port: imap_port (z.B. 993)
  • SMTP-Port: smtp_port (z.B. 587)
  • Adresse des ACME-Core Modul: acme_core_address (z.B. “http://127.0.0.1:8001”)
  • Adresse des Mail-Worker Moduls: mail_worker_address (z.B. “127.0.0.1:8002”)
  • E-Mail-Adresse von der CA: email_address (z.B. “ca@impact.test”)
  • Passwort der E-Mail Adresse von der CA: email_pass (z.B. “Ohcaephicheesoo2eezeive6oh”)
  • Name der Inbox: inbox_name (z.B. “INBOX”)
  • Interval der IMAP-Abrufe: interval (z.B. 5000)

Optionale Parameter:

  • Passwort des privaten Schlüssel der CA: priv_key_pass

Ausblick

Was wurde erreicht?

Im einjährigen Bachelorprojekt wurde ein Protokoll und System zur automatisierten Signatur von OpenPGP-Schlüsseln geplant, modelliert und entwickelt, das sich an den Standards RFC8555 (ACME) und RFC8823 (ACME-Erweiterung für S/MIME) orientiert. Das System bietet zwei verschiedene Clients, welche die User von Erstellung des Schlüsselpaares bis hin zum Erhalt des signierten Schlüssels führen.

Einer der Clients wurde als Thunderbird-Addon realisiert, mit welchem der Verifizierungsprozess, also der Beweis der Kontrolle über die E-Mail-Adresse, sowie der Beweis über die Kontrolle über den privaten Schlüssel, automatisiert möglich ist. Für User anderer E-Mail-Clients steht eine Webclient-Lösung zur Verfügung, die bis auf die Automatisierung des Verifizierungs- und Signaturprozesses dieselben Funktionen bietet. Neben den reinen funktionalen Features, welche zum erfolgreichen Durchführen des Prozesses notwendig sind, bieten die Clients auch ausführliche Dokumentation und Hilfestellungen für die User, um die Einstiegshürde für die Nutzung sicherer E-Mail-Kommunikation möglichst gering zu halten.

Serverseitig handelt es sich um ein verteiltes System mit RPC-basierter interner Kommunikation. Über HTTP und SMTP/IMAP erfolgt die Kommunikation mit den Clients und Mail-Clients. Das System ist bereit, z. B. im Rahmen der Hochschule Bremerhaven, produktiv eingesetzt zu werden, wobei es nicht auf Signaturausstellungen für E-Mail-Adressen der Hochschule limitiert ist. Die Open-Source-Veröffentlichung und Weiterentwicklung ist vorgesehen.

Was sind die Grenzen der Lösung?

Während der Planung und Entwicklung ergaben sich viele verschiedene Feature-Ideen, welche jedoch nicht alle umgesetzt bzw. vollständig implementiert wurden.

Es gibt die Möglichkeit das Revocation-Zertifikat für den zu signierenden Schlüssel in unserem System zu speichern. Die Möglichkeit diesen herunterzuladen oder das System den signierten Schlüssel widerrufen zu lassen ist derzeit nicht möglich. Neben dem Widerrufsprozess fehlen weitere Verwaltungs-Funktionalitäten über die User z. B. einsehen können, welche Verifizierungsprozesse aktuell noch offen sind, abgelaufen sind oder erfolgreich abgeschlossen wurden. Auch fehlt die Erfüllung der Anforderungen an das System durch die DSGVO und die damit verbundenen Funktionalitäten. Über die Clients ist es nicht möglich das Recht auf Auskunft oder das Recht auf Vergessenwerden in Anspruch zu nehmen.

Die automatisierte Verifizierung ist nur mit der Nutzung des Thunderbird-Clients möglich. Auch gibt das Protokoll fest vor, dass der Verifizierungsprozess über HTTP gestartet und mit SMTP beendet werden muss. Die Software-Architektur würde auch erlauben den Prozess fast vollständig über HTTP und vollständig über E-Mail-Kommunikation durchzuführen.

Vorstellbare Roadmap für die Weiterentwicklung

Für den Betrieb und die Weiterentwicklung empfehlen wir folgende Punkte priorisiert anzugehen:

1. Betrieb des Systems

Ein wichtiger Punkt ist es das System produktiv zu betreiben und die Nutzung für z. B. Angehörige der Hochschule zur Verfügung zu stellen. So kann Feedback durch die User erhalten werden und generell Erfahrungen im Betrieb, der Weiterentwicklung und Wartung von Produktivsystemen gesammelt werden. Unter den Betrieb fällt nicht nur das hosten des Systems, sondern auch die Unterstützung der User bei Problemen und Fragen.

2. Revocation-Prozess

Die Entwicklung des Revocation-Prozesses wurde bereits während des Projektzeitraumes begonnen. Damit User auf einfache Weise ihre Schlüssel widerrufen können, muss dieser Prozess vollständig implementiert werden.

3. Umsetzung eines Standards

Formalisierung des Protokolls als öffentlichen Standard (z. B. via IETF-Draft) zur Förderung der Interoperabilität und breiten Adoption.

4. Verschlüsselte Solution-E-Mail

Ein weiteres Feature, welches bereits während des Bachelorprojektes begonnen wurde, ist, dass das System auch verschlüsselte Solution-E-Mails verarbeiten kann.

5. Verwaltung

Ein weiterer Wichtiger Punkt ist es den Usern die Möglichkeit zu geben ihre Daten einzusehen, zu bearbeiten und zu löschen. Dazu gehört z. B. das Einsehen der aktiven und abgelaufenen Challenges sowie der erfolgreichen Verfahren. Auch das Einsehen, Herunterladen und Widerrufen der eigenen signierten Schlüssel gehört zu diesem Punkt. Für das Ändern des Passworts gibt es bereits einen HTTP-Endpunkt, jedoch wird dieser noch in keinem der Clients eingebunden. Neben diesen Punkten ist auch die Achtung der DSGVO und das Recht auf Auskunft und Vergessenwerden muss ermöglicht werden.

6. Testabdeckung / Monitoring

Um ein System stabil zu betreiben ist es wichtig automatisierte Tests zu haben, welche nach Anpassungen sicherstellen, dass das System noch genauso wie zuvor funktioniert. Um möglichst schnell auf Veränderungen und Ausfälle im Produktivsystem reagieren zu können und diese Vorkommnisse analysieren zu können, bedarf es Monitoring und Logging.

7. Umfragen

Ob das System erfolgreich eingesetzt wird und einen Beitrag zur sicheren E-Mail-Kommunikation leistet, entscheiden schlussendlich die User. Um Feedback der User zu erhalten, sollten gezielt Umfragen gemacht werden und das System anhand des Feedbacks verbessert werden.

8. Aufklärung / Werbung (Warum ist das Projekt wichtig?)

Damit das System genutzt wird, muss potenziellen Usern vermittelt werden, warum sie dies tun sollten. Am Tag der Informatik 2025 an der Hochschule Bremerhaven wurde das Thema E-Mail-Sicherheit und das Projekt bereits einem “informatiklastigen” Publikum vorgestellt. Um das System in der gesamten Hochschule zu etablieren, muss das Thema auch an die Angestellten der Hochschule und Studierenden anderer Studiengänge herangetragen werden.

Potentielle Bachelorarbeitsthemen

Auch im Rahmen einer Bachelorarbeit kann das System und dessen Themengebiet weiter untersucht, überarbeitet und weiterentwickelt werden. Zu möglichen Themenbereichen gehören beispielsweise:

  • Protokollüberarbeitung
  • Password recovery process
  • Usability
  • Integration weiterer Clients
  • Server Monitoring
  • Deployment
  • Softwarehardening
  • Transformation von und zu SSH und X.509 Zertifikaten
  • Integration mit anderen Identity Providern (OAuth, Unix, AD)