Rechtsanwältin Alice fährt in den Urlaub

Nehmen wir ein System an, bei dem jeder Teilnehmer ein Schlüsselpaar hat und es keine privaten Schlüssel auf dem zentralen Serversystem gibt. Das Serversystem - wir nennen es BeA Plus - leitet nur Nachrichten weiter und betreibt einen zentralen Schlüsselservice, der die öffentlichen Schlüssel aller Teilnehmer bereitstellt.

Rechtsanwältin Alice plant also beispielsweise ihren Urlaub. Damit wichtige Nachrichten auch in dieser Zeit beantwortet werden, möchte sie, dass ihr Sekretär Bob diese ebenfalls lesen kann - doch ihren privaten Schlüssel, der sich auf einer Chipkarte befindet, kann oder darf sie nicht an Bob weitergeben. Stattdessen signiert Alice eine Mitteilung mit ihrem privaten Schlüssel in einem vordefinierten Format, in der festgelegt wird, dass in einem bestimmten Zeitraum alle Nachrichten an sie auch an Bob verschlüsselt werden können.

Diese signierte Mitteilung schickt sie an den Server von BeA Plus. Der Schlüsseldienst leitet diese Mitteilung automatisch an alle Nutzer weiter, die den öffentlichen Schlüssel von Alice abfragen.

Richterin Carol möchte eine Nachricht an Rechtsanwältin Alice schicken. Die Clientsoftware von Bea Plus auf ihrem Rechner fragt automatisch den aktuellen öffentlichen Schlüssel von Alice vom Server ab. Dieser stellt ihr nun neben dem Schlüssel auch das signierte Statement bereit. Somit weiß die Software von Carol, dass Alice zur Zeit keine Nachrichten empfängt und diese an den Sekretär Bob weitergeleitet werden sollen. Die Software kann dann automatisch den Schlüssel von Bob herunterladen und Carol anbieten, die Nachricht damit zu verschlüsseln.

Einfache Konstruktion - ohne HSM und Ende-zu-Ende-verschlüsselt

Sinnvollerweise würde die Clientsoftware Carol dann die Möglichkeit geben, zu entscheiden, ob die Nachricht an die Vertretung weitergeleitet werden soll oder möglicherweise nicht so eilig ist und bis zum Ende von Alices Urlaub warten kann. Aber eine automatische Verschlüsselung an Bob wäre ebenso möglich.

Ein weiteres Szenario, das teilweise als Grund für die HSM-Umschlüsselung genannt wurde, ist der Fall, dass ein Anwalt nicht mehr erreichbar ist, etwa weil dieser durch einen Unfall außer Gefecht, verstorben oder verschwunden ist. In so einem Fall müssten andere auf die versendeten Nachrichten Zugriff erhalten. Bereits empfangene Nachrichten könnten von der BeA-Software separat lokal gespeichert werden, für nicht empfangene Nachrichten könnte man dem Absender eine automatisierte Aufforderung zur erneuten Sendung an einen anderen Empfänger, etwa einen zuständigen Abwickler, schicken.

Das von uns skizzierte BeA Plus ist nicht besonders komplex und würde alle gewünschten Anforderungen erfüllen. Es käme ohne Vertrauen in ein Hardwaremodul aus, das sich außerhalb der Kontrolle der Nutzer befindet.

Es gäbe noch andere Möglichkeiten und auch das von uns skizzierte BeA Plus wäre vermutlich nicht die ideale Verschlüsselungslösung. Man könnte etwa überlegen, ob es zusätzlich sinnvoll wäre, Forward Secrecy für die Nachrichten zu gewährleisten, indem man für jede Nachricht einen temporären Schlüssel mittels eines Schlüsselaustauschs durchführt, ähnlich wie das Signal-Protokoll das macht. Völlig unabhängig vom Problem mit dem HSM ist es auch generell sehr fragwürdig, eine Ende-zu-Ende-Verschlüsselung in einem Webinterface umzusetzen.

Doch zunächst einmal ist es wichtig, darzustellen, dass es keinerlei Grund gibt, auf eine echte Ende-zu-Ende-Verschlüsselung zu verzichten. Die abenteuerliche Konstruktion mit dem HSM ist unnötig.