Sicher E-Mailen mit IBM i - MIDRANGE EVENTS

PRÄSENTIERT

       Sicher E-Mailen mit IBM i

EIN BEITRAG VON

Gerald Beck
Dipl.-Math. Univ.
Geschäftsführer
comSID GmbH & Co. KG

comSID GmbH & Co. KG

Sitz in Augsburg.
5 Kommanditist*innen.
8 Kolleg*innen, welche auf IBM i entwickeln.
Seit über 30 Jahren Erfahrung mit ERP-Systemen auf AS400 – IBM i.
Aufbau kundenspezifischer ERP-Systeme.
Seit einigen Jahren zunehmend Betreuung und Weiterentwicklung
   existierender ERP-Systeme.

                                       … und mit weiteren Kolleg*innen
                                          weit über 100 Jahre IBM –
                                          Erfahrung.

Gerald Beck
                      Klaus Mödinger

Sicher E-Mailen mit IBM i

Mit einem PC oder dem Domino-Server auf der IBM i ist
  dies kein Problem.
Auch auf der IBM i mit Bordmitteln geht das
  unkompliziert.

Internet ist ein globales, offenes Netz

• Jeder kann mit seinen Devices über einen Internet Service
  Provider oder Mobile Provider das Internet nutzen.
• Mit Zugang zum Internet kann jeder, jegliche Art von
  Information oder Daten anfragen oder senden.
• Die Daten werden als Klartext über das Internet transportiert,
  wenn der Sender keine Sicherheitsvorkehrungen trifft.

                                                 [Bild Zitat]

Gefährdungs-Potential

• 2000:
• Der ILOVEYOU -Virus verursachte zirka 10 Milliarden Dollar Schaden
  innerhalb von 24 Stunden (500,000 Systeme wurden infiziert).
• Mai 2017:
• Unter Nutzung von NSA-Tools, infizierte die WannaCry Ransomware
  230.000 Computer in 150 Ländern und verschlüsselte Daten.
• 2020:
• Projekt „Rubicon“, eine geheime Operation von BND und CIA: Die
  schweizer Firma Crypto AG verkaufte manipulierte Verschlüsselungs-
  Technik an mehrere Regierungen.
• Die Verschlüsselung konnte mit dieser Kenntnis durch die CIA
  geknackt werden (der BND stieg aus dem Projekt 1992 aus).

Sicherheit und Nutzung offener Netze

Zur sicheren Nutzung des Internet müssen folgende Ziele
garantiert werden:
• Unverfälschte Identität des Senders
• Unverfälschtheit der Nachricht
• Vertraulichkeit der Informationen
• Verbindlichkeit des Informationsaustausch

Asymmetrischer Verschlüsselungs-Algorithmus RSA

Weitverbreitetes Mittel, um einige der Sicherheitsziele zu erreichen.
Entwickelt 1977 von Ron Rivest, Adi Shamir und Leonard Adleman.
Er nutzt zwei unterschiedliche Schlüssel für Verschlüsselung und
   Entschlüsselung.
Den geheimen oder privaten Schlüssel – den “private key”
Den öffentlichen Schlüssel – den “public key”

                                       [Bild Zitat]

RSA – Idee der Nutzung

Der private key muss vor jedem Kommunikationspartner geheim
  gehalten werden.
Der public key wird jedem Kommunikationspartner zur Verfügung
  gestellt.
Wird eine Nachricht mit einem private key verschlüsselt, kann sie nur
  mit dem korrespondierenden public key entschlüsselt werden.
            Fdecrypt ( KPublic , Fencrypt ( KPrivate , Text) ) = Text
Wird eine Nachricht mit einem public key verschlüsselt, kann sie nur
  mit dem korrespondierenden private key entschlüsselt werden.
            Fdecrypt ( KPrivate , Fencrypt ( KPublic , Text) ) = Text
Damit haben wir die „Vertraulichkeit der Informationen“ erreicht.

RSA – kryptografisches Verfahren

Der Algorithmus basiert auf dem praktisch (in realistischer Zeit)
  unlösbaren mathematischen Problem der Faktorisierung.
  Faktorisierung: Das Produkt zweier sehr großer, zufällig selektierter
  Primzahlen kann praktisch (in realistischer Zeit) nicht faktorisiert werden
  ohne Kenntnis der Primzahlen.

Kryptografische Hash-Funktionen

Hash-Funktionen (z.B. SHA-256) transformieren jeden Input in eine
  Ergebnis (Hash) fixer Länge (z.B. 256 bit).

Eine Hash-Funktion h ist                                    [Bild Zitat]

• kollisionsfrei, wenn es praktisch unmöglich ist, zwei verschiedene
   Nachrichten M und M’ zu finden, für welche h(M) = h(M’) gilt.
• eine Ein-Weg-Funktion, wenn es praktisch unmöglich ist zu einem
   Hash z eine Nachricht M zu finden, für welche gilt M = h(z).
Kryptografische Hash-Funktionen sind kollisionsfrei.

Trust Problem in asymmetrischen Kryptosystemen

Angriffs-Scenario:
Mallory versucht Alice seinen Public Key als den von Bob auszugeben,
  um ihre Nachrichten an Bob zu lesen.
• Mallory gibt seinen Public Key als den von Bob aus.
• Dann kann Mallory die vertraulichen Nachrichten von Alice an Bob
  lesen. Bob kann diese Nachrichten nicht lesen.
• Mallory kann im Namen von Bob Dokumente signieren.

                                                       [Bild Zitat]

Public Key Infrastructure - PKI

Weitverbreitete Lösung des Trust-Problems:
Die Kommunikationspartner vertrauen einem Trust Center, welches
  die Verknüpfung eines Public Key zu einer Person garantiert.
Das Trust Center gibt hierfür Zertifikate oder genauer Key-Zertifikate
  aus, welche folgende Informationen enthalten:
• Eigentümer des Zertifikats (Person, Firma, Webserver, …).
• Public Key des Eigentümers.
• Die digitale Signatur des Trust Centers, welche das Zertifikat
  ausgestellt hat.

Digitale Signatur

                                                   [Bild Zitat]

Damit erreichen wir die noch ausstehenden Ziele:
• Unverfälschtheit der Nachricht
• Unverfälschte Identität des Senders
• Verbindlichkeit des Informationsaustausch

Theorie zu Ende /
Beginn der Praxis

Howto auf IBM i - 1

Wir wollen z.B. Aufträge von unserer IBM i aus versenden.
Die IBM i läuft unter V7R2 und Primärsprache 2929 Deutsch.
Voraussetzungen sind:
i5/OS PASE (5770-SS1 option 33)
Digital Certificate Manager (5770-SS1 option 34) und
OpenSSL (5733-SC1 option 1).
Damit die Absenderadressen von unserem E-Mail-Provider akzeptiert
   werden, richten wir eine Subdomäne order.comsid.de ein.
(Andere Netzwerkumgebungen und Firmenphilosophien erfordern
   eventuell ein modifiziertes Vorgehen. So funktioniert es jedenfalls
   bei uns (comSID)).

Howto auf IBM i - 2

Dem SMTP-Server wird der Verzeichnistyp und die Nutzung der
  Absende-Domäne order.comsid.de mitgeteilt.
Wenn bis jetzt produktiv z.B. mit DIRTYPE(*SDD) gearbeitet wurde,
  sollte man das nicht so locker umstellen. Planung ist nötig.
CHGSMTPA DIRTYPE(*SMTP) ALIASDMN('ORDER.COMSID.DE’)
Der SMTP-Server muss neu gestartet warden:
ENDTCPSVR SERVER(*SMTP)
STRTCPSVR SERVER(*SMTP)
Benutzer der IBM i, welche E-Mails versenden sollen, werden dem
  SMTP-Server bekanntgegeben:
ADDUSRSMTP USRPRF(NTIRLIS) DOMAIN(*DFT ORDER.COMSID.DE)

Howto auf IBM i - 3

Jeder dieser Benutzer erhält für den Digital Certificate Manager (DCM)
  ein Directory:
chgcurdir '/QIBM/UserData/ICSS/Cert/Download/Client'
MKDIR DIR(ntirlis)
Mit dem DCM erhalten diese Benutzer einen Zertifikatsspeicher:
http://:2001/QIBM/ICSS/Cert/Admin/qycucm1.ndm/main0
Neuen Zertifikatsspeicher erstellen, Speicher für andere
  Systemzertifikate, Nein – Kein Zertifikat im Zertifikatsspeicher
  erstellen, Pfad und Dateiname für Zertifikatsspeicher:
  /QIBM/UserData/ICSS/Cert/Download/Client/ntirlis/ntirlis.kdb
Kennwort für Zertifikatsspeicher:

Howto auf IBM i - 4

Von unserer Zertifizierungsinstanz bekommen wir eine .p12-Datei,
  welche Passwort-geschützt ist, den Private Key und ein Zertifikat
  enthält.
Wir nutzen hier als Zertifizierungsinstanz die DGN Deutsches
  Gesundheitsnetz GmbH.
Die .p12-Datei legen wir im Ordner
  /QIBM/UserData/ICSS/Cert/Download/Client/ntirlis mit dem Namen
  ntirlis@order.comsid.de.p12 ab.
Damit der Benutzer NTIRLIS mit dem Speicher arbeiten kann:
CHGOWN OBJ('/QIBM/UserData/ICSS/Cert/Download/Client/ntirlis')
  NEWOWN(NTIRLIS) SUBTREE(*ALL)

Howto auf IBM i - 5

Bevor wir auf V7R2, Primärsprache Deutsch erfolgreich E-Mails
  versenden wollen, ändern wir noch unseren interaktiven Job ab:
CHGJOB CCSID(37)
Diese Absonderlichkeit ist auf den Folgereleases schon gefixt.
Damit können wir signierte E-Mails versenden:
SNDSMTPEMM RCP(('c.sielecki§comsid.de')) SUBJECT('Unser Auftrag
  A202104001') NOTE('Unser Auftrag A202104001 ...') SMIME(*SIGN)
  PASSWORD()
Man beachte das §-Zeichen statt dem @-Zeichen wegen CCSID 37.

Howto auf IBM i - 6

Eventuell wird die Unterschrift von ihrem E-Mail-Client noch nicht
  akzeptiert, da das Ausstellerzertifikat nicht bekannt ist.
Bei der DGN Deutsches Gesundheitsnetz GmbH ist das z.B. der Fall.
Wir haben die E-Mail erwartet und vertrauen ihrem Zertifikat.
Wir arbeiten mit Mozilla Thunderbird.
Wenn wir die signierte Nachricht öffnen, erhalten wir einen Button
  S/MIME, welcher uns nach Anklicken mitteilt, dass die digitale
  Unterschrift nicht gültig ist.
Durch Ansehen des Unterschriftszertifikats erhalten wir den
  Allgemeinen Namen des Ausstellerzertifikats:
dgnservice CA 2 Type E:PN

Howto auf IBM i - 7

Googeln nach dem Ausstellerzertifikat führt unkompliziert zu einer
  Downloadmöglichkeit auf der Website von DGN Deutsches
  Gesundheitsnetz GmbH.
Die Datei dgnservice_CA_2_Type_EPN.cer, welche das
  Ausstellerzertifikat repräsentiert, importieren wir in Thunderbird
  z.B. beim E-Mail-Account c.sielecki@comsid.de über Einstellungen,
  Ende-zu-Ende-Verschlüsselung, S/MIME-Zertifikate verwalten und
  Zertifizierungsstellen.
Dabei geben wir noch an, dass der CA vertraut wird, um E-Mail-Nutzer
  zu identifizieren.
Nun vertraut der E-Mail-Client der digitalen Unterschrift.

Howto auf IBM i - 8

Zum Verschlüsseln von E-Mails benötigen wir den Public Key des
   Empfängers c.sielecki@comsid.de und seine Zertifikatskette.
Um eine signierte E-Mail zu versenden, benötigen wir den Private Key
   im E-Mail-Account von c.sielecki@comsid.de.
In Thunderbird importieren wir die Datei c.sielecki@comsid.de.p12 in
   die Zertifikatverwaltung z.B. im Account c.sielecki@comsid.de über
   Einstellungen, Ende-zu-Ende-Verschlüsselung, S/MIME-Zertifikate
   verwalten und Ihre Zertifikate.
Über den Account c.sielecki@comsid.de wird das Zertifikat in
   c.sielecki@comsid.de.p12 dann mittels seiner Option Einstellungen,
   Ende-zu-Ende-Verschlüsselung, S/MIME, Auswählen für Persönliches
   Zertifikat für digitale Unterschrift und Verschlüsselung zugewiesen.

Howto auf IBM i - 9

Nun kann der Account c.sielecki@comsid.de z.B. an
  n.ntirlis@comsid.de eine signierte Nachricht versenden.
Das erreicht man mit Thunderbird über Datei, Neu, Nachricht,
  Sicherheit, Nachricht unterschreiben und Versenden der nun
  signierten Nachricht.
Die empfangene Nachricht hat wieder einen Button S/MIME, über
  welchen wir das Unterschriftszertifikat ansehen und den Public Key
  z.B. als Datei c.sielecki@comsid.de.pem abspeichern können.
Das Unterschriftszertifikat enthält auch den allgemeinen Namen des
  Ausstellers dgnservice CA 2 Type E:PN. Die Datei
  dgnservice_CA_2_Type_EPN.cer dazu, kennen wir ja schon.

Howto auf IBM i - 10

Durch interne Prozesse hat Thunderbird das Root-Zertifikat dgnservice
  Root 7:PN hierzu schon automatisch importiert.
Wir exportieren es über die inzwischen bekannte Zertifikatverwaltung
  von Thunderbird und Zertifizierungsstellen als Datei
  dgnserviceRoot7-PN.crt.
Dem Zertifikatsspeicher ntirlis.kdb müssen nun die
  Ausstellerzertifikate bekannt gemacht werden.
Mit dem DCM Zertifikatsspeicher wählen, Speicher für andere
  Systemzertifikate, Pfad und Dateiname für Zertifikatsspeicher:
  /QIBM/UserData/ICSS/Cert/Download/Client/ntirlis, Kennwort für
  Zertifikatsspeicher: .

Howto auf IBM i - 11

Nun werden die Ausstellerzertifikate importiert, beginnend mit dem
  Root-Zertifikat.
Zertifikat importieren, Zertifizierungsinstanz, Importdatei: //dgnserviceRoot7-PN.crt, Zertifikatsbezeichnung
  der Zertifizierungsinstanz: dgnserviceRoot7-PN.crt.
Und nochmal den gleichen Prozess für die Datei
  dgnservice_CA_2_Type_EPN.cer.
Der Zertifikatsspeicher ntirlis.kdb muss nun das Kennwort der Datei
  ntirlis@order.comsid.de.p12 bekommen.
Zertifikatsspeicher verwalten, Kennwort ändern, Neues Kennwort,
  Kennwort der Datei ntirlis@order.comsid.de.p12.

Howto auf IBM i - 12

Damit der Benutzer NTIRLIS alle Objekte in
  /QIBM/UserData/ICSS/Cert/Download/Client/ntirlis bearbeiten
  kann, vergeben wir passende Rechte:
CHGOWN OBJ('/QIBM/UserData/ICSS/Cert/Download/Client/ntirlis')
  NEWOWN(NTIRLIS) SUBTREE(*ALL)
Da bei fehlerhaften Rahmenbedingungen bei der Ausführung von
  SNDSMTPEMM (z.B. ein Public Key fehlt) Dateien im zugeordneten
  Benutzer-Ordner (z.B. ntirlis) gelöscht werden, verhindern wir dies:
CHGAUT OBJ('/QIBM/UserData/ICSS/Cert/Download/Client/ntirlis/*')
  USER(NTIRLIS) OBJAUT(*OBJMGT *OBJALTER *OBJREF)

Howto auf IBM i - 13

Nun können wir auch schon verschlüsselte E-Mails versenden.
SNDSMTPEMM RCP(('c.sielecki§comsid.de')) SUBJECT('Unser Auftrag
  A202104001') NOTE('Unser Auftrag A202104001 ...') SMIME(*BOTH)
  PASSWORD()
Das ist nicht einmal ironisch gemeint, da nach den Vorarbeiten ja
  nichts mehr zu tun ist.

VIEL ERFOLG!

ENDE
comSID Webseite:
https://www.comsid.de/
modernisierung.comsid.de:
https://modernisierung.comsid.de/
comSID – Kontakt - Herr Beck:
Tel.: 0821 450437 301
E-Mail: g.beck@comsid.de
Grafiken zitiert aus dem Kurs:
Confidential Communication in the Internet
(https://open.hpi.de/courses/confidentialcommunication2021)
von Prof. Dr. Christoph Meinel