Bereits Kunde? Jetzt einloggen.
Lesezeit ca. 10 Min.

PGP-PKI: Geheimnis


Linux Magazin - epaper ⋅ Ausgabe 11/2019 vom 02.10.2019

Nicht nur aus Datenschutzgründen ergibt es Sinn ,im Unternehmen einen eigenen Keyserver zu betreiben. Er versammelt und prüft die öffentlichen Schlüssel sämtlicher Kunden und Mitarbeiter und beendet so die nervige und zeitintensive Suche nach den passenden Keys.


PGP-Keyserver im Unternehmen einsetzen

Artikelbild für den Artikel "PGP-PKI: Geheimnis" aus der Ausgabe 11/2019 von Linux Magazin. Dieses epaper sofort kaufen oder online lesen mit der Zeitschriften-Flatrate United Kiosk NEWS.

Bildquelle: Linux Magazin, Ausgabe 11/2019

© olegdudko ,123RF

Jeder weiß , dass unverschlüsselte E-Mails vom Sicherheitsniveau noch unterhalb einer Postkarte liegen. Trotzdem installiert kaum ein Unternehmen PGP. Als erste Begründung ist zu hören, das Verfahren sei zu kompliziert, als zweite, die Nutzung gestalte sich zu unhandlich. Sind beide ...

Weiterlesen
epaper-Einzelheft 5,99€
NEWS 14 Tage gratis testen
Bereits gekauft?Anmelden & Lesen
Leseprobe: Abdruck mit freundlicher Genehmigung von Linux Magazin. Alle Rechte vorbehalten.

Mehr aus dieser Ausgabe

Titelbild der Ausgabe 11/2019 von News. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
News
Titelbild der Ausgabe 11/2019 von Trends. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Trends
Titelbild der Ausgabe 11/2019 von Kernel-News: darf leben. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Kernel-News: darf leben
Titelbild der Ausgabe 11/2019 von FHEM: Zu Diensten!. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
FHEM: Zu Diensten!
Titelbild der Ausgabe 11/2019 von Alexa-Skills: aufs Wort. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Alexa-Skills: aufs Wort
Titelbild der Ausgabe 11/2019 von Z-Wave”: Welten. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Z-Wave”: Welten
Vorheriger Artikel
Datafari: Such
aus dieser Ausgabe
Nächster Artikel Recht: Ärger
aus dieser Ausgabe

Jeder weiß , dass unverschlüsselte E-Mails vom Sicherheitsniveau noch unterhalb einer Postkarte liegen. Trotzdem installiert kaum ein Unternehmen PGP. Als erste Begründung ist zu hören, das Verfahren sei zu kompliziert, als zweite, die Nutzung gestalte sich zu unhandlich. Sind beide Hemmschwellen ausgeräumt, heißt es: „Aber was ist, wenn der Mitarbeiter geht? Dann ist der Private Key futsch.” Spätestens hier kippt das Projekt PGP-Einführung. Doch das lässt sich lösen, wie der Artikel zeigt.

Der Autor
Tobias Eggendorfer nutzt PGP, seit er E-Mails versenden kann. Beim Datenschutz-IT-Security- Buzzword-Bingo gewinnt er zwar oft mit „SSLverschlüsselte E-Mail-Kommunikation”, noch lieber würde er aber „Klar, wir haben PGP” hören. Wenn er nicht gerade seine Mails verschlüsselt, ist er als IT-Berater [www.eggendorfer.info] und Professor für IT-Sicherheit tätig.

Die Erfinder von E-Mail waren froh, dass sie es schafften, eine Nachricht erfolgreich zu verschicken. Die Grundpfeiler der IT-Sicherheit – Vertraulichkeit, Integrität und Authentizität – blieben dabei erst einmal Nebensache. Doch der Prototyp büxte aus den Laboren aus; der Rest ist eine Erfolgsgeschichte.
Seit den 1970er Jahren gilt aber auch: E- Mail ist unsicher. Eine Verschlüsselung wäre angezeigt, doch praktisch niemand nutzt sie. Zu umständlich, zu schwierig, zu komplex, dem Laien nicht zu vermitteln, so lauten die beliebtesten Gegenargumente. Überhaupt: „Was passiert, wenn der Empfänger das nicht hat?”
Keines der Argumente hält genauem Hinsehen stand: Komplex sind zwar die Mathematik dahinter und auch die Kunst der hybriden Verschlüsselung. Allerdings muss der normale Anwender beide nicht durchschauen, um seine E-Mails zu verschlüsseln – wer weiß schon im Detail, wie der Motor seines Autos arbeitet?
Der Empfänger hat kein PGP? Na dann bekommt er halt eine unverschlüsselte E-Mail. Wichtiger wäre, dass unternehmensweit alle Mitarbeiter auf alle bekannten öffentlichen Schlüssel zugreifen dürfen, damit nicht aus Versehen E-Mails unverschlüsselt auf die Reise gehen. Wie sich das lösen lässt, beschreibt der erste Teil dieses Artikels. Der zweite kümmert sich um ein valides Argument, das der Autor in der Praxis aber nur einmal zu hören bekam: Was passiert, wenn der Mitarbeiter geht? Hat das Unternehmen dann noch Zugriff auf seine E-Mails?

Wofür der Aufwand?

Doch warum überhaupt verschlüsseln, seit den 70ern geht es doch auch so? Laut DSGVO müssen Unternehmen mit personenbezogenen Daten sorgsam umgehen. Taucht dort Verschlüsselung nur als Empfehlung auf, gilt das Verschlüsseln in anderen Bereichen als Pflicht, etwa bei Finanz- und Passbehörden.
Manche Unternehmen und Behörden reden sich bei E-Mail dann auf SSL/ TLS zwischen den E-Mail-Servern raus, so etwa „E-Mail made in Germany”[1] . Wer diesen Unsinn Datenschützern und Admins erzählt, darf froh sein, wenn die einzige Reaktion ein Facepalm ist. Die E- Mail lagert auf allen Zwischenstationen unverschlüsselt – also kein ausreichender Sicherheitsgewinn.
DSGVO-geschulte Seitenbetreiber legen dann los mit: „Wir holen uns eine Einwilligung.” Doch auch die ist untauglich, denn sie setzt Freiwilligkeit voraus. Die dürfte kaum gegeben sein, wenn unverschlüsselte E-Mails die einzige Kontaktoption darstellen. Auf Fax und Brief muss sich der Anwender nicht verweisen lassen, das Landesamt für Datenschutzaufsicht Bayern fordert insoweit eine mediengleiche, sichere Alternative. Da bleibt eigentlich nur die Verschlüsselung.
Noch stärker betroffen, wenn auch häufig ignorant, sind Berufsgeheimnisträger wie Rechtsanwälte, Ärzte oder Steuerberater. Dennoch kommunizieren sie oft per E- Mail, gern über US-Server in der Office- 365-Cloud. Auch hier gilt: Der Mandant muss verschlüsseln dürfen, es ist seine Wahl. Die in der Branche dann mit Vorliebe vorgeschlagene Datev-Lösung, ein rudimentärer Webmailer, über den der Mandant seine E-Mails abrufen soll, ist technisch untauglich (siehe).
Nicht zuletzt gibt es in manchen Industriezweigen einen hohen Geheimhaltungsbedarf, weit über den Datenschutz hinaus. Kaum ein Betrieb, der Forschung und Entwicklung betreibt, möchte seine Wettbewerber früher als nötig über seine Pläne informieren.

PGP oder S/ MIME

Für die Kommunikation nach außen ist Verschlüsselung unabdingbar. Jetzt streiten Experten, ob PGP oder S/ MIME besser sei. Aus Sicht des Autors spricht für PGP, dass sich jeder Nutzer jederzeit einen Key generieren kann, mithin auch eine pseudonyme Kommunikation gelingt. S/ MIME verlangt nach einem Zertifikat; dabei ist Pseudonymität nicht vorgesehen, obgleich manchmal möglich. Efail[2] wurde in PGP ebenfalls behoben, für S/ MIME gilt das nicht. PGP kann unter anderem E-Mails verschlüsseln, aber auch mehr. S/ MIME ist konzeptionell für E-Mails gemacht. Daher erscheint PGP als flexibler und sinnvoller.

Keys im Griff

In jedem Fall brauchen alle Nutzer im Unternehmen Zugriff auf die Schlüssel aller Kommunikationspartner. Dazu dient ein Keyserver. Für PGP gibt es jede Menge öffentlicher Server, etwa die SKS-Keyserver oder auch Keys. openpgp.org.
Die lassen sich jedoch von Unternehmen kaum rechtskonform nutzen: Die DSGVO verlangt von Firmen, dass sie mit einem Dritten, der personenbezogene Daten im Auftrag verarbeitet, einen Auftragsverarbeitungsvertrag schließen. Stehen dessen Server außerhalb der EU und außerhalb von als sicher anerkannten Drittstaaten (zu denen die USA nicht gehören), müssen aufwändigere Verträge her.
Für öffentliche Keyserver stellt das schon ein unüberwindbares Hindernis dar. Hinzu kommt die Pflicht zur Löschung, Auskunft und Korrektur: Das SKS-Keyserver- Konzept erlaubt es wegen des Web of Trust nicht, Keys zu entfernen.

Qual der Wahl

Die Lösung: Ein interner Keyserver, der keine Daten mit externen Servern austauscht, um das Datenschutzproblem zu umgehen. Das überschaubare Angebot an Lösungen zeigt Openpgp.org[3] . Für Unternehmen eignen sich Hockeypuck[4] und Mailvelope[5] .
Das in Go geschriebene Hockeypuck kann seine Keys in einer PostgreSQL- oder MongoDB- Datenbank ablegen, doch die letzte Release stammt von 2015. Mailvelope dagegen ist recht aktuell, im August 2019 kam Version 4 heraus. Es nutzt Node.js und die No-SQL-Datenbank MongoDB.
Ersteres stellt einen kleinen Vorteil gegenüber Go dar – Javascript ist verbreiteter. Letzteres erscheint auch nicht als Hindernis: Der Keyserver sollte eh auf eigener, zu diesem Zweck installierter Hardware beziehungsweise einer VM laufen. Der Autor strebt an, ein kompaktes System mit hoher Sicherheit ab Werk zu verwenden.
Die VM sollte mit 1 GByte RAM und 4 GByte Plattenplatz auskommen, sich schnell installieren lassen und wenig Aufwand bereiten. Die Wahl fiel auf das oft übersehene OpenBSD als Basissystem. Dank Node.js lässt sich Mailvelope analog auf allen anderen Systemen installieren. Die Dokumentation ist das größte Manko von Mailvelope, unerfahrene Admis dürften mit der Anleitung verzweifeln.

Paketbote

Zunächst müssen Node.js und MongoDB auf das System. Das erledigt in der Regel der systemeigene Paketmanager, bei OpenBSD lautet der Befehl »pkg_add node mongodb«. Node.js braucht auf OpenBSD etwas Nacharbeit. Einerseits sollte der Installateur die Manpages in der »/etc/man.conf« mit eintragen, was folgende zusätzliche Zeile erledigt: manpath /usr/local/lib/node_modules/npm/man Andererseits sollte er die gewünschte Python-Version verlinken (, Zeilen 1 bis 4). Soll auch die Datenbank MongoDB beim Systemstart automatisch hochlaufen, erledigt das die Befehlsfolge aus den Zeilen 5 bis 7. Damit Mailvelope in MongoDB seine Keys auch speichern kann, legt alles Nötige an.

TLS muss sein

Experten streiten gern darüber, ob öffentliche Schlüssel der Natur nach nur verschlüsselt übertragen werden sollten. Zumindest die GPG-Tools auf dem Mac verweigern die Zusammenarbeit mit Keyservern, wenn die kein SSL anbieten. Also heißt es, entweder ein firmenweites Zertifikat zu verwenden oder sich rasch ein selbst signiertes Zertifikat zu erzeugen. Das erledigt OpenSSL (). Die Datei »Sicheres_Zertifikat .pem« sollte als sicher eingestuftes Zertifikat auf dem eigenen Rechner landen. Zugleich sollte der Admin den Hostnamen des Keyservers (etwa »keyserver.Eigene_Domain.org «) im internen DNS oder in der eigenen »/etc/hosts« eintragen.

Postbote

Abbildung 1: Mailvelope verschlüsselt seine Authentifizierungsmails auf Wunsch mit dem eigenen Public Key.


Mailvelope bietet an, hochgeladene Keys zu verifizieren. Dazu erhalten alle für einen Key eingetragenen E-Mail-Adressen automatisch eine Nachricht mit einem Link. Um diese E-Mails zu verschicken, braucht Mailvelope einen lokalen E-Mail- Server. Kompakt, schlank und schnell aufgesetzt ist OpenSMTPD[6] . Wahrscheinlich existiert ein Unternehmens- Mailserver, dorthin sollen die E-Mails zur weiteren Zustellung gehen. Das erledigt die Konfigurationsdatei »/etc/mail/ smtpd.conf« aus.
Wer sich, wie der Autor, gern genau dann vertippt, wenn das unmöglich scheint, prüft einfach über »smtpd ‑n«, ob die Konfiguration tatsächlich fehlerfrei ist. Bei positivem Ergebnis startet der Admin über »rcctl restart smtpd« im nächsten Schritt den SMTP-Dienst neu.

Verknotet

Jetzt kommt endlich Mailvelope selbst an die Reihe: Zunächst lädt der Administrator sich die aktuelle Entwicklerversion des Keyservers auf die Festplatte (, Zeile 1), entpackt sie dort in ein Verzeichnis (Zeile 3) und richtet sie dann ein (Zeile 4). Der Node.js-Paketmanager Npm installiert dabei die nötigen Bibliotheken mit.
Die spärliche Doku schlägt vor, mit »npm test« die Installation zu prüfen. Wer das tut, wird mit Fehlermeldungen überhäuft. Besser ist es, zunächst die »config/default. js« anzupassen. Das Ergebnis zeigt, erläutert die nicht selbsterklärenden Optionen.

Kein HTTPS?

Mailvelope schlägt vor, einen HTTPSoder HTTP-Proxy vor den eingebauten Webserver zu stellen. Das erscheint nicht nur unlogisch, sondern gerade im unter- nehmensinternen Einsatz eher überflüssig. Wenn die GPG-Tools zum Beispiel nur über SSL mit dem Server kommunizieren möchten, sollte die Verschlüsselung nicht am Proxy enden.
Mailvelope beherrscht standardmäßig nur HTTP. Dabei lässt sich ein HTTPSServer dank des KOA-Frameworks mit zwei minimalen Änderungen in der Datei »/src/index.js« erzeugen; die neue Version zeigt. Die »config/default. js« aus berücksichtigt die passenden Erweiterungen schon.
Jetzt läuft der Test mit »npm test« erfolgreich durch, »npm start« lässt dann den Keyserver durchstarten. Unter »https://keyserver.Eigene_Domain.org« sollte jetzt das Webfrontend erscheinen.
Das sieht so aus, wie jenes unter. Das ist unerfreulich, aber leicht zu ändern: Alles, was die Oberfläche ausmacht, steht als HTML in »/src/view/«. So lässt sich der lästige, weil nicht automatisch aktualisierte Ver- weis auf »hkps://keys.mailvelope.com« aus der unteren rechten Ecke ersetzen.

Einrichten

GPG unter Unix hält seine benutzereigenen Konfigurationsdateien üblicherweise in »~/.gnupg/« vor. Dort findet sich auch die Datei »dirmngr.conf«, die der Admin um den neuen internen Server ergänzt (). Um Nutzer anzulegen, bietet es sich an, diese Datei als Template in »/etc/skel/« vorzuhalten.
Als Ergebnis der Schritte sollte der Admin über die Kommandozeile jetzt einen vorher hochgeladenen Key finden können (, erste Zeile). In die jeweiligen GPG-Schlüsselverwaltungen wie GPG Keychain oder Kleopatra trägt er die Server bei Bedarf auch ein.
Lädt der Anwender dann über den Befehl aus der zweiten Zeile (oder ganz bequem per Webfrontend) einen weiteren Schlüssel auf den Server, erzeugt Mailvelope eine automatische Kontrollmail (). Erst wenn der Besitzer des Schlüssels den Link anklickt, gilt der öffentliche Schlüssel als bestätigt.
Steht der Wert »pgp« in der Datei »config/ default.js« auf »true« (), verschlüsselt Mailvelope die E-Mail gleich mit dem öffentlichen Key des Empfängers. So prüft die Software nicht nur, ob der E-Mail-Empfänger existiert, sondern auch, ob er den passenden privaten Schlüssel besitzt.
Verwendet ein Unternehmen hingegen einen Keyserver ohne Zugriffsmöglichkeit von außen, lässt sich keine auf E-Mails basierte Prüfung für Kundenschlüssel umsetzen. Hier ergibt es Sinn, Abteidie Prüfung komplett zu unterlassen. Da Mailvelope aber nur geprüfte öffentliche Schlüssel ausliefert, wäre der Keyserver so unbrauchbar.
zeigt einen Vorschlag für die Lösung: Es ersetzt die Zeile 103 der »service/ public‑key. js«. Die neue Konfigurationsdirektive »autoverify« aktiviert das dort vorgeschlagene Feature. Über ein wenig Javascript- Code und mit Hilfe regulärer Ausdrücke ließen sich dann auch einige Domainnamen in der Datei ergänzen und nur dafür E-Mails zur Verifizierung durchlassen.

Abbildung 2: Einen neuen Key für die Vertriebsabteilung erzeugen


Abbildung 3: Barbara Beispiel als weitere ID dem Key hinzufügen.


Abbildung 4: Ist die Vertriebsabteilung komplett ,sind deren Mitglieder über verschlüsselte E-Mails an »vertrieb@example.com« erreichbar


SMTP über TLS?

Wer in der »smtpd. conf« in die fehlenden PKI-Direktiven entdeckt und entsetzt in der »config/ default.js« den Eintrag »starttls« vermisst: Weil Mailvelope alle ausgehenden E-Mails über den lokalen Mailserver per PGP-verschlüsselt, eine Authentifizierung fehlt und die Kommunikation nur lokal verläuft (über »localhost« oder »127.0.0.1«), ist SSL überflüssig.
Zwar ließe sich das selbst signierte Zertifikat anlegen und schnell in die »smptd. conf« einbinden, doch wäre zum Akzeptieren solcher Zertifikate eine Code-Änderung an Mailvelope nötig: Die Software mault bei selbst signierten Zertifikaten.

Reisende nicht aufhalten

Mit dem Keyserver kann es nun losgehen: Kommunikation intern und extern ist perfekt verschlüsselt. Doch was passiert, wenn ein Mitarbeiter das Unternehmen verlässt, krank wird oder gar Urlaub macht? Wie realisiert man im Rahmen einer – hoffentlich DSGVO- und Fernmeldegeheimnis- tauglichen – Vertreterregelung den Zugriff auf die E-Mails?
Einen Gruppen-Key sieht PGP zwar nicht vor. Unter den folgenden drei Prämissen findet sich aber auch für dieses Problem ein Ausweg:
■ Der PGP-Einsatz zielt vorrangig auf eine sichere Ende-zu-Ende-Verschlüsselung für die externe Kommunikation ab und nur eingeschränkt auf eine Authentifizierung des Absenders. Es genügt, dass sich das Unternehmen authentifiziert.
■ Es gibt einen definierten Prozess, um Schlüssel beim Ausscheiden von Mitarbeitern zurückzurufen.
■ Innerhalb einer Abteilung sind gegenseitige Vertretungen vorgesehen.
Treffen alle drei Punkte zu, wäre es denkbar, eine E-Mail-Adresse für die Abteilung zu generieren (), zum Beispiel »vertrieb@example.org «, deren Schlüssel die E-Mail-Adressen der Mitarbeiter der Abteilung () als weitere IDs auflistet (). Einzelne Mitarbeiter erhalten dann keine verschlüsselten E-Mails mehr.
Die Nachteile der Lösung: Den Private Key teilen sich alle Mitarbeiter der Vertriebsabteilung. Daher setzt die Gültigkeitsdauer für den Schlüssel recht kurz an. Zudem eignet sich der Key damit nur noch eingeschränkt zum Signieren: Die Signatur bestätigt nicht mehr den Versand durch eine Person, sondern allenfalls durch ein Mitglied der Abtei lung. Zudem dürfen so alle Mitarbeiter der Abteilung Nachrichten entschlüsseln. Doch das ist erwünschtes Verhalten.

Fazit

Aus Sicht des Autors stellt das geschilderte Szenario einen tragbaren Kompromiss zwischen ungeschützter Kommunikation und unternehmensinternen Risiken dar. Für vertrauliche Kommunikation im Unternehmen, etwa mit dem Betriebsrat oder ‑arzt, lassen sich zusätzlich individuelle Schlüssel konfigurieren.
Dank des internen Keyservers greifen alle Mitarbeiter auf die Public Keys von Kunden und Kollegen zu. Da Mailvelope die Keys per Default nicht verteilt und deren Löschen ermöglicht, darf die Lösung – anders als bei öffentlichen Keyservern – als datenschutzfreundlich gelten. Der Implementationsaufwand erscheint, lässt man die schlechte Dokumentation von Mailvelope beiseite, ebenfalls tragbar. Am Ende stünde ein wichtiger Fortschritt bei E-Mails: Eine echte Endezu- Ende-Verschlüsselung zwischen den Kommunikationspartnern.(kki/jlu)

Infos
[1] E-Mail made in Germany: [https://www.e‑mail‑made‑in‑germany.de/Verschluesselung.html]
[2] Efail: [https://efail.de]
[3] Interne Keyserver: [https://www.openpgp.org/software/server/]
[4] Hockeypuck: [https://hockeypuck.github.io]
[5] Mailvelope: [https://keys.mailvelope.com]
[6] OpenSMTPD-Konfiguration, Tobias Eggendorfer, „Frisch verbrieft”: LM 09/ 2015, S. 72, [https://www.linux‑magazin.de/ausgaben/2015/09/open‑smtpd/]
[7] „Bullshit made in Germany”: [https://www.youtube.com/watch?v=J‑n6CfOCnPg]

Datev – das Grauen kehrt zurück

Datev bietet unter anderem IT-Dienstleistungen für Steuerberater und Rechtsanwälte an. Da sollte echte E-Mail-Verschlüsselung nicht erst seit der DSGVO Standard sein, sondern wegen der Schweigepflichten und ‑rechte schon immer.
Doch deren von SEPP-Mail eingekaufte Lösung ist geradezu peinlich: Sendet ein Anwalt eine als zu verschlüsseln markierte E-Mail, landet sie auf einem Datev-Server. Der schickt dem Empfänger eine E-Mail mit einem HTML-Attachment, die darum bittet, den Anhang im Browser zu öffnen. Schon da biegen sich die Zehennägel von IT-Sicherheitserfahrenen senkrecht nach oben: Seit über einem Jahrzehnt lautet der ständige Rat an Nutzer, keinesfalls Links in E-Mails anzuklicken und die Finger von Attachments zu lassen. Die Datev-E-Mails wirken anachronistisch und haben durch ihren standardisierten Aufbau ein hohes Phishing-Potenzial.
Spielt der Empfänger notgedrungen das grausige Spiel mit, landet er auf einer Webseite und soll für einen Account, bei dem der Username die eigene E-Mail-Adresse ist, ein Passwort vergeben. Mit diesem Passwort lässt sich dann die E-Mail lesen, beantworten und als ».eml«-Datei herunterladen. Kenner würden von einem verkrüppelten Webmailer sprechen.
In den eigenen Account-Einstellungen gibt es noch die Möglichkeit, seinen öffentlichen PGPKey zu hinterlegen. Dann würde die E-Mail nicht mehr bei Datev gespeichert, sondern auf deren Server mit dem Key verschlüsselt und per E-Mail weitergeleitet – ein grandioses Konzept, das schon Linus Neumann zu seinem C3C-Beitrag „Bullshit made in Germany”[7] hinriss – der Titel ließe sich leicht übertragen.
Noch unsinniger ist das Beantworten verschlüsselter E-Mails geregelt: Einen PGP-Key dazu gibt es nicht, der Verfasser muss sich im Webinterface einloggen. Das funktioniert aber, mangels HTML-Attachments bei den per PGP weitergesendeten E-Mails, nur über den Link aus der allerersten E-Mail. Damit sind alle E-Mails zwangsläufig Antworten auf diese. Nutzerunfreundlicher geht es kaum, neben dem Unsinn, dass die E-Mail nun auf dem Webserver von Datev liegt und sich von dort auf undefinierten Wegen in die Kanzlei bewegt.