Schutz der anwaltlichen Verschwiegenheitspflicht in der Cloud

Aus Wiki
Wechseln zu: Navigation, Suche

Inhaltsverzeichnis

Ausgangspunkt

  • DAV-Symposium zum Schutz der anwaltlichen Verschwiegenheitspflicht
  • Ziele:
    • Datenschutz (gegen unbefugten Zugriff)
    • Datensicherung (gegen Verlust)
    • Anwaltsgeheimnis
    • Rechtssicherheit
  • technische Neuerungen nutzen: Potential, Wettbewerb
  • §203 ausweiten?: Dienstleister in das Anwaltsgeheimnis einbeziehen?
  • Problem: bei grenzüberschreitenden Cloud-Dienstleistern, wie Google?
    • unsichere rechtliche Lage
    • das Recht, unter dem der Mandant erhofft, dass seine Daten geschützt sind, findet evtl. gar keine Anwendung
    • intransparente Datenverarbeitung
    • mangelnde Einflussmöglichkeiten

Überlegung

Ein Anwalt kann Dienste, die vertrauliche Daten verarbeiten, nicht in die Cloud auslagern, weil der Betreiber des Dienstes notwendigerweise die vertraulichen Daten im Klartext einsieht. Er müsste also mit jedem einzelnen Dienstanbieter eine Verschwiegenheitsvereinbarung treffen. Grunsätzlich besteht im Internet Gefahr, dass Daten während der Übertragung nicht hinreichend gegen Fremdzugriff oder Manipulation abgesichert werden. Je mehr Dienstbetreiber man also heranziehen würde, desto größer die Gefahr, dass an irgendeiner Stelle ein "Leck" entsteht, das die Sicherheit möglicherweise nachhaltig kompromittiert, da man sich darauf verlassen muss, dass ausnahmslos alle beteiligten vertrauenswürdig und hinreichend kompetent sind.

Anforderungen

Beim zweckbestimmten Arbeiten kommt zumeist nur eine überschaubare Anzahl verschiedener Programme zum Einsatz. Diese stellen entsprechend geringe Anforderungen an das eingesetzte System:

  1. Speicherplatz zum Ablegen der Daten
  2. manche einen Webserver (z.B. PHP-basierte Applikationen, wie openLawyers)
  3. manche eine Datenbank (z.B. MySQL)

Am schnellsten sind diese Funktionen über einen dedizierten, separaten "Server" bereitgestellt, der die anvertrauten Aufgaben übernimmt, im Regelfall für seine Aufgaben aber viel zu hoch skaliert ist. Die Nachteile beinhalten

  1. Stromverbrauch
  2. Wärmeproduktion
  3. Lautstärke
  4. den Schutz einer großen Apparatur gegen Diebstahl
  5. die Absicherung einer großen Apparatur gegen Ausfall

Die Nutzung von Cloud-Diensten bietet sich an, dem entgegen stehen jedoch die speziellen, oben ausgeführten Datenschutz-Anforderungen.

Wenn der Prophet nicht zum Berg kommen kann ...

Unter zuhilfenahme eines geeignet modifizierten Embedded Device, lassen sich die obigen Anforderung sicher realisieren:

  1. Speicherplatz durch Verschlüsselung von Cloud-Speicher
  2. einen Webserver kann das Gerät selbst betreiben
  3. eine Datenbank ebenso

Das Gerät übernimmt die Schnittstelle zwischen dem Anwender und seinen Cloud-Diensten. Es stellt die programmierten Dienste bereit und verarbeitet die eingegebenen, vertraulichen Daten selbst, ohne sie weiterzugeben. Zu speichernde Informationen werden mit einem geheimen Schlüssel zerhackt und in unlesbarer Form auf einem Speicher in der Cloud abgelegt.

Schlüssel

Schlüssel im flüchtigen Speicher

Um zu gewährleisten, dass mit einem physischen Diebstahl des Zerhackers ein Dritter dennoch nicht an die verschlüsselten Daten gelangen kann, könnte der geheime Schlüssel im Zerhacker in einem flüchtigen Speicher (RAM) abgelegt werden, sodass er bei Stromverlust verloren geht. So müsste er allerdings bei jedem Einschalten vom Anwender (am Einfachsten per Web-Interface) erneut in den Zerhacker hochgeladen werden.

Dieses Verfahren bietet den Vorteil, dass einheitliche Firmware-Images zum Einsatz kommen können, deren Vertrauenswürdigkeit z.B. durch Prüfsummen und Signatur sichergestellt werden kann. Der Nachteil besteht darin, dass es ja i.d.R. nicht das Embedded Device ist, das kompromittiert wird, sondern der PC, von dem aus der Anwender seinen Schlüssel hochlädt (Viren, Trojaner), die "Hauptschwachstelle" dadurch also noch nicht ausgeräumt ist.

Gefahr eines Single Point of Failure

Ein weiterer "Nachteil" der Verwendung von Schlüsseln ist, dass ohne den Schlüssel tatsächlich kein Zugriff auf die Daten besteht. Geht dieser also verloren, sind auch die Daten, obwohl physisch vorhanden, faktisch verloren, da unlesbar. Er muss also sowohl vor Diebstahl als auch vor Zerstörung (Feuer etc.) geschützt aufbewahrt werden, beispielsweise auf mehreren redundanten USB-Sticks in örtlich verschiedenen Tresoren.

Man beachte in diesem Zusammenhang auch die begrenzte Speicherungsfähigkeit mancher Datenträger. Digitale Speichermedien sind nicht unendlich lagerungsfähig: Sonneneinstrahlung, physischer Verschleiß, Nutzungszyklen und Verfall ohne Fremdeinwirkung können mit der Zeit zu Datenverlust führen, was im Falle der Schlüssel fatal wäre.

Email Public Keys

Besitzt ein Anwender bereits einen Email-Schlüssel (Public Key), so bietet es sich an, diesen auch zur Datenverschlüsselung zu verwenden. Grundsätzlich bietet es sich an, Schlüssel zu erstellen, die für beide Zwecke genutzt werden können. Dies würde in der Folge z.B. auch eine automatische Signierung von ausgehenden Emails ermöglichen.

Smartcards

Noch sicherer als digitale Schlüssel wäre die Verwendung einer Smartcard (Typus "Prozessor-Karte"), die selbst die Ver- und Entschlüsselung übernimmt. Die Smartcard enthält den Schlüssel, gibt ihn aber niemals heraus, sodass der private Schlüssel ultimativ sicher abgeschirmt ist. Eine Smartcard ver-/entschlüsselt zwar viel langsamer, aber so wäre der Schlüssel noch nicht mal dem Zerhacker selbst bekannt, könnte dort oder am PC des Anwenders also auch nicht ausgelesen werden. Smartcards können nur physisch, nicht aber über das Netzwerk gehackt werden.

Auch in Kombination mit anderen Schlüsseln wären Smartcards denkbar.

Mögliche Lösung des Single Point of Failure

Smartcards wären in Hinblick auf die Datenabschirmung optimal. Sie können nicht ohne sichtbare Spuren an der Karte gehackt werden (*). Da sie jedoch nicht ohne Weiteres dupliziert werden können, ist die Gefahr des Single Point of Failure noch größer (Verlust ist fatal). Lösen könnte man dieses Problem nur, indem an zentraler Stelle eine Kopie des privaten Schlüssels vorgehalten wird. Dann jedoch wäre die Abschirmung der Daten nicht mehr sichergestellt. Sie könnte jedoch wieder sichergestellt werden, wenn die vorgehaltene Kopie von vertrauenswürdiger Stelle verschlüsselt wäre, z.B. einem anderen Anwalt. Dieser Anwalt muss dazu nicht notwendigerweise in den Besitz der Schlüsselkopie gelangen.

Ein mögliches Szenario wäre: Der Anwender verliert seine Smartcard z.B. durch einen Wohnungsbrand und kann so nicht mehr an seine Daten gelangen. Er fordert nun von der zentralen Stelle die verschlüsselte Schlüsselkopie an, und übergibt sie seinem Anwalt zur Entschlüsselung. Weder die zentrale Stelle noch der Anwalt sind bis dahin in der Lage, unabhängig voneinander an die Daten zu gelangen, da der Schlüssel nicht im Klartext vorliegt. Es können beliebig viele "Anwälte" (oder andere, vertrauenswürdige Parteien) zur Entschlüsselung der Schlüsselkopie erforderlich gemacht werden, da die Schlüsselkopie ja vor der Hinterlegung beliebig oft verschlüsselt werden kann. Es ist auch möglich, verschiedene Teile der privaten Schlüsselkopie für verschiedene Personen zur verschlüsseln (mit deren Public Key), sodass niemand im Bedarfsfall durch Entschlüsselung der vorgelegten Schlüsselkopie in den Besitz des vollständigen privaten Schlüssels gelangt (**).

Nach der Wiederherstellung der Schlüsselkopie ist der geheime Schlüssel natürlich nicht mehr ultimativ sicher, sollte/muss also erneuert werden, dennoch wurde durch das Verfahren gewährleistet, dass die Daten die ganze Zeit über nur verschlüsselt vorgelegen haben und auch durch den Wohnungsbrand nicht verloren gegangen sind.

zu (*): Es könnte lediglich nach einem unbemerkten Diebstahl eine optisch gleichaussehende Kopie angefertigt und zurückplatziert werden, jedoch ist dies ein sehr aufwendiger Vorgang, der einige Zeit braucht, sodass es wahrscheinlich ist, dass der Anwender den Verlust der Smartcard zwischenzeitlich bemerkt. In jedem Fall ist dies bedeutend aufwendiger, als an unverschlüsselte Daten oder durch Hacken des PCs (oder Trojaner) an einen digital vorliegenden Schlüssel zu gelangen.

zu (**): Die einzige Schwachstelle bestünde dann darin, dass bei gleichzeitiger Kompromittierung aller Vertrauenspersonen und der zentralen Stelle, auch der eigene Schlüssel indirekt kompromittiert wäre. Dieses Szenario ist aber unwahrscheinlich und es würde sich bei einem derartig weitreichenden Kompromittierungsfall ohnehin die Frage stellen, ob der eigene Schlüssel nicht besser erneutert werden sollte, auch ohne dass er sich als kompromittiert herausgestellt hat.

Meine Werkzeuge
Namensräume
Varianten
Aktionen
Navigation
Werkzeuge