1. Was ist das Hardware Security Module (HSM)?

Das HSM ist eine spezielle Hardware-Komponente, die dem Schutz von Verschlüsselungs-Keys dient. Darüber hinaus nutzt das HSM kryptografische Keys und stellt Dienste für die Verschlüsselung, Entschlüsselung, Authentifizierung und digitale Signierung zur Verfügung. Das HSM kann allein vordefinierte Operationen durchführen. Das HSM der BRAK ist physisch von anderen Systemen getrennt und baulich besonders gesichert. Auch gegen physische Manipulationen ist es geschützt. So ist beispielsweise die Recheneinheit des HSM in eine leitfähige Folie eingehüllt. Sollte die Folie beschädigt werden, löscht sich das HSM automatisch selbst.

2. Die Anwaltschaft hat höchste Anforderungen an die Sicherheit. Was wäre noch sicherer als der Einsatz von HSM Modulen?

Die funktionalen Anforderungen und die Sicherheitsanforderungen an das beA-System können nur unter Verwendung einer Umschlüsselungs-Komponente umgesetzt werden. Ein HSM ist hierfür die einzige zur Verfügung stehende Lösung zur Umsetzung der Anforderungen an das System.

3. Was ist das Online Services Computer Interface (OSCI)?

Dieses OSCI ist eine Sammlung von Netzwerkprotokollen für die deutsche öffentliche Verwaltung. Zuständig ist die Koordinierungsstelle für IT-Standards (KoSIT), die die Entwicklung und den Betrieb von IT-Standards für den Datenaustausch in der öffentlichen Verwaltung der Bundesrepublik Deutschland koordiniert. Die Errichtung der KoSIT ist eine Folge der Ergänzung des Grundgesetzes um den Artikel 91c sowie des zugehörigen IT-Staatsvertrages. Die KoSIT unterstützt den IT-Planungsrat in dessen Aufgabe, fachunabhängige und fachübergreifende IT-Interoperabilitäts- und IT-Sicherheitsstandards zu beschließen und Bund-Länder-übergreifende E-Government-Projekte zu steuern. Das beA-System verwendet das OSCI-Transport-Protokoll für die sichere, vertrauliche und rechtsverbindliche Übertragung digitaler Daten an die Justiz. Dem OSCI-Standard entsprechend trennt das beA bei der Versendung von Nachrichten die verschlüsselten Nachrichteninhalte von den für den Nachrichtentransport erforderlichen weiteren Daten.

4. Werden private Schlüssel von Atos oder einem Dienstleister auf anderen als den Kanzleirechnern der betroffenen Rechtsanwälte gespeichert?

Die zentrale beA-Anwendung speichert den privaten Schlüssel des Postfachs als verschlüsseltes Objekt in der Datenbank. Dieser private Schlüssel des Postfaches und der zugehörige öffentliche Schlüssel werden beim Anlegen des Postfaches in einem Hardware Security Modul (HSM) erstellt. Auf Grund der Anforderung der Verwaltung von mehr als 360.000 Postfächern und den technischen Gegebenheiten zur internen Speicherung von Schlüsselmaterial in einem HSM, werden die im HSM erstellten privaten Schlüssel im HSM selbst mit einem weiteren Schlüssel verschlüsselt und in dieser Form aus dem HSM exportiert. Da kryptografische Operationen unter Verwendung des privaten Postfachschlüssels nur innerhalb des HSM möglich sind, müssen hierzu die in der Datenbank abgelegten verschlüsselten privaten Schlüssel in das HSM geladen werden.

5. Sind im HSM des beA diejenigen private Schlüssel gespeichert, die auch auf der beA-Smart Card gespeichert sind?

Der im HSM hinterlegte Schlüssel erfüllt verschiedene Funktionen: Der Schlüssel wird für die Authentifizierung, die Verschlüsselung und für die Anmeldung verwendet. Bei dem privaten Schlüssel auf der beA-Karte (privater Benutzerschlüssel) und dem im HSM hinterlegten Schlüssel (privater Postfachschlüssel) handelt es sich um zwei verschiedene Schlüssel. Die privaten Schlüssel der Postfächer und die zugehörigen öffentlichen Schlüssel werden beim Anlegen des Postfaches im HSM erstellt. Der private Benutzerschlüssel wird von der BNotK bei Generierung der beA-Karte erstellt. Der private Postfachschlüssel im HSM wird im Rahmen der Postfachgenerierung erzeugt und verlässt dieses nie unverschlüsselt. Es wird sichergestellt, dass ein Sicherheitstoken wie die beA-Karte einem System-Benutzer eindeutig zugeordnet wird. Nach § 26 Abs. 1 RAVPV dürfen die Inhaber eines für sie erzeugten Zertifikats dieses keiner weiteren Person überlassen und haben die dem Zertifikat zugehörigen Zertifikats-PIN geheim zu halten. Nach § 26 Abs. 2 RAVPV hat der Postfachinhaber unverzüglich alle erforderlichen Maßnahmen zu ergreifen, um einen unbefugten Zugriff auf sein Postfach zu verhindern. Den Fall, dass mehrere Personen über dasselbe Schlüsselmaterial verfügen, sieht das beA-System nicht vor.

6. Wie wird sichergestellt, dass niemand Zugriff auf den im HSM hinterlegten Schlüssel hat?

Die Implementierung des HSM enthält keinerlei Funktionalität, die diesen (oder andere) Schlüssel im Klartext exportieren kann. Somit hat kein Nutzer im Betrieb des HSM Zugriff auf diesen Schlüssel. Ebenso wenig haben Systemadministratoren des technischen Dienstleisters oder Verantwortliche der BRAK oder der regionalen Rechtsanwaltskammern Zugriff auf das Schlüsselmaterial. Des Weiteren stellen die Schutzmechanismen der Hardware des HSM sicher, dass kein Anwender im Falle eines Angriffs auf das HSM (etwa das gewaltsame Öffnen und Versuch des Auslesens des Speichers) Zugriff auf das Klartext-Schlüsselmaterial erhalten kann.

7. Wie ist das HSM gegen (unberechtigte) Zugriffe von außen gesichert? Wer hat physischen Zugriff auf das HSM? Wie sieht der Wartungsprozess der HSM-Maschinen aus?

Die Rechenzentren haben an beiden Standorten ein mehrschichtiges Sicherheitskonzept in Bezug auf den physischen Zugang: Geländeumzäunung und Videoüberwachung, Gebäudeüberwachung mit Videokamera an den Haupteingängen, extra gesicherter Kernbereich mit Vereinzelungsanlage und speziellen Ausweisen, Käfige für verschiedene Kunden. Für die BRAK sind sämtliche beA-Komponenten in dezidierten, abgeschlossenen Käfigen und zusätzlich durch abgeschlossene Racks (mit RFID-Schlüsseln) gesichert untergebracht. Der Empfang und das Einbringen von Komponenten in das Rechenzentrum oder in die Käfige erfolgt nur über Netz und DC Services (NDCS), DC-Operations-Personal oder begleitete Mitarbeiter des Herstellers. Der Zugang wird nur gestattet, wenn ein entsprechender Antrag/Change avisiert und genehmigt wurde. Für kurzfristige notwendige Wartungsarbeiten (z.B. Plattentausch) sind Techniker durchgehend vor Ort. Im normalen Betrieb und für Monitoring-Zwecke ist kein physischer Zugang notwendig. Der Versuch, ein HSM-Modul physisch zu öffnen, führt zur kompletten Löschung der im Modul gespeicherten Daten. Eine Wartung eines HSM-Moduls kann nicht vor Ort, sondern nur in den gesicherten Herstellerräumen von Atos Worldwide erfolgen. Hier haben die spezialisierten Techniker ebenfalls keinen Zugriff auf die verschlüsselten Schlüssel der Anwaltschaft. Es gibt keinen Generalschlüssel. Die Inhalte eines ausgebauten HSM werden vollständig gelöscht. Um bei einer Wartung eine Betriebsunterbrechung zu vermeiden werden dabei erst neue Geräte vor Ort gebracht, in das System eingebunden und synchronisiert, danach die alten Geräte herausgenommen und an Atos Worldwide zurückgeschickt.

8. Welches technische Verfahren wird angewandt, um die Schlüssel zu übertragen?

Als asymmetrisches Verfahren zum Schlüsseltransport ist gemäß OSCI-Transport 1.2 die Verschlüsselung mit einem RSA-Algorithmus vorgesehen. Die Größe der Schlüssel beträgt 2048 Bit. Für die symmetrische Verschlüsselung der Nachricht wird der Verschlüsselungsalgorithmus AES 256 verwendet. Dies entspricht ebenfalls der OSCI 1.2-Spezifikation.

9. Trifft es zu, dass der Weg über den lokalen Server im SecurityClient insbesondere gewählt wurde, um den Zugriff auf das Kartenlesegerät zu ermöglichen? Wurde die Möglichkeit moderner Browser in Erwägung gezogen, selbst und direkt auf USB-Geräte zuzugreifen?

Die Ansteuerung von Kartenlesegeräten ist eine der Funktionen, die zu der Entscheidung geführt haben, die Client Security einzubinden. Moderne Browser erlauben es auch heute noch nicht, die Verschlüsselung vorzunehmen.

Ursprünglich war für das beA eine Plugin Schnittstelle (NSAPI) vorgesehen. Die Kryptografie-Funktionalitäten und die Kartenansteuerung sollten in Form eines Java-Applets bereitgestellt werden. Java-Applets können im Kontext einer Webseite ausgeführt werden und erlauben eine Javascript-basierende Kommunikation zwischen der Webseite und dem Applet. Voraussetzung für die Nutzung von Applets ist es, dass der Browser eine Schnittstelle für Plug-Ins, in diesem Fall für ein Java-Plug-In, bereitstellt. Dies war zum Zeitpunkt des Angebots Standard und ist aktuell auch noch bei allen Browsern am Markt der Fall. Allerdings wurde der Support der Plug-In-Schnittstelle (NPAPI) von den Schnittstellenunterstützern (u.a. Google) abgekündigt. Als Lösung wählte daraufhin die BRAK die Realisierung der Web-Anwendung in der zur Verfügung gestellten Form, um zukunftsfest zu sein.

10. Ist es richtig, dass die .msi nicht codedesigned ist und die macOS-Installationsdatei nicht von einem zertifizierten Entwickler stammt? Wie wird sichergestellt, dass keine „gehackten“ Versionen der Software kursieren?

Die macOS-Installationsdatei stammt nicht von einem zertifizierten Entwickler – sie ist nicht codesigned, d.h. es handelt sich um eine nicht signierte Installationsdatei. Nutzer sollten durch den Download auf der Startseite von beA die Client Security-Installationsdatei laden. Eine Weitergabe der Installationsdatei an Dritte ist nicht vorgesehen. Die zu ladenden Installationsdateien sind mit einem Hashwert versehen und können entsprechend auf ihre Integrität überprüft werden.

11. Ist es richtig, dass die beA-Webanwendung anfällig ist für Cross-Site-Scripting?

Es wurden und es werden fortlaufend Filter in der beA-Anwendung eingesetzt, um neuen Bedrohungssituationen zu begegnen. Zu betonen ist, dass Angriffe durch Cross-Site-Scripting nicht speziell Web-Anwendungen immanent sind, sondern grundsätzlich ein Angriffsszenario für jede Software-Anwendung darstellen. Das beA-System sieht vor, dass nur maximal zehn zusätzliche Zeichen eingegeben werden können. Damit sind Angriffsmöglichkeiten durch Cross-Site-Scripting extrem eingeschränkt.

12. Sind SSL-Stripping-Angriffe möglich?

Auf dem Citrix NetScaler ist HTTP Strict Transport Security (HSTS) aktiviert. Der Citrix NetScaler ADC ist ein Application Delivery Controller. Bei aktuellen Browsern sollten SSL-Stripping-Angriffe nicht mehr möglich sein. Die Client-Security verwendet zur Kommunikation ausschließlich SSL. Ein SSL-Stripping-Angriff ist damit nicht möglich.

13. Wurde den Herstellern von Kanzleisofware (KSW) die API zur Verfügung gestellt?

Ja, die BRAK hat die gesamte Dokumentation zur KSW-Schnittstelle den interessierten Herstellern im Vorfeld bereitgestellt. Darüber hinaus wurden diverse Informationsveranstaltungen von der BRAK durchgeführt, in denen Fragen von Herstellern zur Dokumentation geklärt worden sind. Zudem beantwortete die BRAK Fragen zur Implementierung der Schnittstelle durch einen erfahren Softwareentwickler. Die Dokumentation wird im Rahmen der Weiterentwicklung entsprechend gepflegt und den KSW-Herstellern zur Verfügung gestellt. Die KSW-Schnittstelle ist ein integraler Bestandteil des beA-Systems.