Linux, Meine Meinung

Warum die gesetzeskonforme Archivierung von elektronischen Dokumenten (mit OpenSource-Lösungen) nicht funktionieren kann

2 Comments

Die Gesetzeskonforme Archivierung von elektronischen Dokumenten (z.B. ERP-Daten, E-Mails, …) ist ein Thema, welches zwar jede noch so kleine Firma etwas angeht, aber durchaus gerne ignoriert wird. Entweder weil die verantwortlichen nichts davon wissen, oder weil sie die Preise gesehen haben.

Lange habe ich nach einer Möglichkeit gesucht, vor allem E-Mails rechtsgültig mit OpenSource-Lösungen zu archivieren.  Die gesetzlichen Vorgaben für die Archivierung von E-Mails wird in der Geschäftsbücherverordnung (GeBüV) geregelt. Artikel 3 und 9 daraus:

Art. 31 Integrität (Echtheit und Unverfälschbarkeit)

Die Geschäftsbücher müssen so geführt und aufbewahrt und die Buchungsbelege müssen so erfasst und aufbewahrt werden, dass sie nicht geändert werden können, ohne dass sich dies feststellen lässt.

Art. 9 Zulässige Informationsträger

1 Zur Aufbewahrung von Unterlagen sind zulässig:

a.
unveränderbare Informationsträger, namentlich Papier, Bildträger und unveränderbare Datenträger;
b.
veränderbare Informationsträger, wenn:

1.
technische Verfahren zur Anwendung kommen, welche die Integrität der gespeicherten Informationen gewährleisten (z.B. digitale Signaturverfahren),
2.
der Zeitpunkt der Speicherung der Informationen unverfälschbar nachweisbar ist (z. B. durch «Zeitstempel»),
3.
die zum Zeitpunkt der Speicherung bestehenden weiteren Vorschriften über den Einsatz der betreffenden technischen Verfahren eingehalten werden, und
4.
die Abläufe und Verfahren zu deren Einsatz festgelegt und dokumentiert sowie die entsprechenden Hilfsinformationen (wie Protokolle und Log files) ebenfalls aufbewahrt werden.

2 Informationsträger gelten als veränderbar, wenn die auf ihnen gespeicherten Informationen geändert oder gelöscht werden können, ohne dass die Änderung oder Löschung auf dem Datenträger nachweisbar ist (wie Magnetbänder, magnetische oder magnetooptische Disketten, Fest- oder Wechselplatten, solid state-Speicher).

Und genau in diesen zwei Artikeln liegt der Knackpunkt. Die anderen Artikel sind, sofern relevant, durchaus mit OpenSource-Lösungen zu bewältigen. Für Artikel 6 Punkt 1 liesse sich beispielsweise SOLR einsetzen.

Archivierung mit veränderbaren Datenträger

Meiner Meinung nach kann es mit veränderbaren Datenträger kein rechtssicheres Archiv geben, denn keine der beteiligten Komponenten ist manipulationssicher.

Beispiel Zeitquelle

Da der Zeitpunkt der Archivierung aufgezeichnet werden muss, benötigt man eine Zeitquelle.

Die interne, lokale Uhr hat einerseits einen sehr hohen Drift und kann andererseits durch lokale Begebenheiten (RTC-Batterie, Eingriff, …) verändert werden. Fällt als verlässliche Zeitquelle also aus.

NTP verwendet eine unverschlüsselte Netzwerkübertragung, welche jederzeit manipuliert werden kann. Beispielsweise kann man mit einem entsprechenden Router einfach den Port 113/UDP ausgehend auf einen internen Server mit NTPD umleiten.

Man könnte doch einen DCF77-Empfänger (oder einen anderen Funkzeitempfänger) verwenden? Nein. Glaubt mir, ich bin Amateurfunker. DCF77 ist hinlänglich bekannt und dokumentiert, mit einem AM-Funksender und ein bisschen Elektronik (oder einer Soundkarte, sucht mal im Internet nach dcf77gen) lässt sich hervorragend ein passender Sender erstellen. Selbiges gilt natürlich auch für GPS-Empfänger, die Frequenzen sind einfach etwas höher.

Bleibt also nur die Anschaffung einer Cäsiumuhr?!? Leider nein, eine Cäsiumuhr definiert eigentlich nur die Länge einer Sekunde, die Zeit muss manuell gestellt werden…

Als zweites hat man das Problem, dass Daten, welche auf einem veränderbaren Datenträger liegen, veränderbar sind. Auch wenn es entsprechende Dateisysteme geben würde, welche das “Versiegeln” von Dateien unterstützen würde, könnte ich jederzeit die Festplatte (oder ein anderes veränderbares Medium) aus dem System entfernen, sie in ein anderes System einbauen und die Daten mit einem Hexeditor manipulieren.

Ein Beispiel:

Ich habe ein (äusserst experimentelles) WORM-Dateisystem entwickelt. Es unterstützt POSIX-ACL’s, Dateien bis 10kb, kein Löschen, kein Überschreiben.

root@dev04:~# lsmod
[...]
exp_wormfs              6713 0
[...]
root@dev04:~# mount
[...]
/dev/c0d2p1 on /mnt/worm type wormfs (rw)
[...]
root@dev04:~#

Ich erstelle nun zwei Dateien auf diesem Dateisystem und hashe sie. Das Hash-Tool ist recht simpel, es ist eine Variante vom sha512sum welches Teile der ACL und den Timestamp als Salz verwendet.

root@dev04:~# cd /mnt/worm/
root@dev04:/mnt/worm# echo 'Diese Datei wird nicht manipuliert' >> datei1
root@dev04:/mnt/worm# echo 'Diese Datei wird manipuliert' >> datei2
root@dev04:/mnt/worm# /home/user1/sign sign datei1
  SIGNATURE  
-------------
775accdfedc5ace3e59daf0a9b35ead350acdba6b813043d1240fe1ad16332bc416236baf3bba8932110a34aaafd099047a5cc42168e34d88b337bab3afcd7b2
root@dev04:/mnt/worm# /home/user1/sign sign datei2
  SIGNATURE  
-------------
ad8a6c2f6939e789578aa4567a02923bc35ae1b61bee267aa1ed95534fe0b4c712a69e31a9549d1f97465cd4084d48f0e0425df9debf8bb7b7d6adec2cfa8ee2

Ich manipuliere nun Datei1, und teste sie:

root@dev04:/mnt/worm# touch datei1
root@dev04:/mnt/worm# /home/user1/sign check datei1
  file is insane - SIGNATURES  
-------------------------------
775accdfedc5ace3e59daf0a9b35ead350acdba6b813043d1240fe1ad16332bc416236baf3bba8932110a34aaafd099047a5cc42168e34d88b337bab3afcd7b2
08bb7b85af557dddff1b042e73dd634b619cbfb58fd0140c5e210ff61b954c6ecc3094c9a2baa34921ec7e4ecaed1b6b0bb706cb22dcc539f6bde882a04ee85c

Nun möchte ich Datei2 manupulieren ohne dass die Integrität der Datei gefährdet wird.

Dazu hänge ich das Dateisystem aus und öffne das Volume mit einem Hexeditor, suche nach meiner Datei und manipuliere sie. Ich ändere den Inhalt von “…wird manipuliert” auf “… wurd manipuliert”. (Der Einfachheit halber benutze ich einen gleich langen Satz, sonst müsste ich noch die inode manipulieren)

root@dev04:~# umount /mnt/worm
root@dev04:~# hexcurse /dev/c0d2p1
┌0008081D─────────────────────────────────────────────────┐^┌────────────────┐
│00080760 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 │▒│................│
│00080770 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 │▒│................│
│00080780 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 │▒│................│
│00080790 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 │▒│................│
│000807A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 │▒│................│
│000807B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 │▒│................│
│000807C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 │▒│................│
│000807D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 │▒│................│
│000807E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 │▒│................│
│000807F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 │▒│................│
│00080800 44 69 65 73 65 20 44 61 74 65 69 20 77 75 72 64 │◆│Diese Datei wurd│
│00080810 20 6D 61 6E 69 70 75 6C 69 65 72 74 0A 00 00 00 │▒│ manipuliert....│
│00080820 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 │▒│................│
│00080830 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 │▒│................│
│00080840 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 │▒│................│
│00080850 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 │▒│................│
│00080860 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 │▒│................│
│00080870 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 │▒│................│
│00080880 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 │▒│................│
│00080890 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 │▒│................│
│000808A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 │▒│................│
└─────────────────────────────────────────────────────────┘v└────────────────┘
  Help     Save     Open         Goto     Find       Hex Addr Asc Edit   Quit

Nun lasse ich den Hash überprüfen:

root@dev04:/mnt/worm# /home/user1/sign check datei2
  file is insane - SIGNATURES  
-------------------------------
ad8a6c2f6939e789578aa4567a02923bc35ae1b61bee267aa1ed95534fe0b4c712a69e31a9549d1f97465cd4084d48f0e0425df9debf8bb7b7d6adec2cfa8ee2
e0600cadeccd5f040a99f160ff48a4eb6a51c35d7ec905ed44e3143f34e51ce9ae0c4c6e4d6be71797e5be79c1e09dd413d2b5f769cd5e21df8088d2fd34bd05

Abermals hänge ich das Dateisystem aus, und manipuliere den Hash:

root@dev04:~# umount /mnt/worm
root@dev04:~# hexcurse /dev/c0d2p1
┌00009C35─────────────────────────────────────────────────┐^┌────────────────┐
│00009C30 00 00 00 00 00 00 65 30 36 30 30 63 61 64 65 63 │◆│......e0600cadec│
│00009C40 63 64 35 66 30 34 30 61 39 39 66 31 36 30 66 66 │▒│cd5f040a99f160ff│
│00009C50 34 38 61 34 65 62 36 61 35 31 63 33 35 64 37 65 │▒│48a4eb6a51c35d7e│
│00009C60 63 39 30 35 65 64 34 34 65 33 31 34 33 66 33 34 │▒│c905ed44e3143f34│
│00009C70 65 35 31 63 65 39 61 65 30 63 34 63 36 65 34 64 │▒│e51ce9ae0c4c6e4d│
│00009C80 36 62 65 37 31 37 39 37 65 35 62 65 37 39 63 31 │▒│6be71797e5be79c1│
│00009C90 65 30 39 64 64 34 31 33 64 32 62 35 66 37 36 39 │▒│e09dd413d2b5f769│
│00009CA0 63 64 35 65 32 31 64 66 38 30 38 38 64 32 66 64 │▒│cd5e21df8088d2fd│
│00009CB0 33 34 62 64 30 35 0A 00 00 00 00 00 00 00 00 00 │▒│34bd05..........│
│00009CC0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 │▒│................│
│00009CD0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 │▒│................│
│00009CE0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 │▒│................│
│00009CF0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 │▒│................│
│00009D00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 │▒│................│
│00009D10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 │▒│................│
│00009D20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 │▒│................│
│00009D30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 │▒│................│
│00009D40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 │▒│................│
│00009D50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 │▒│................│
│00009D60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 │▒│................│
│00009D70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 │▒│................│
└─────────────────────────────────────────────────────────┘v└────────────────┘
  Help     Save     Open         Goto     Find       Hex Addr Hex Edit   Quit

Zum Schluss hänge ich es wieder ein und teste:

root@dev04:/mnt/worm# /home/user1/sign check datei2
  file is sane - SIGNATURE
----------------------------
e0600cadeccd5f040a99f160ff48a4eb6a51c35d7ec905ed44e3143f34e51ce9ae0c4c6e4d6be71797e5be79c1e09dd413d2b5f769cd5e21df8088d2fd34bd05

Et voilà…

Natürlich ist mir dies nur gelungen, weil ich weiss, wie die Signaturen erstellt wurden, und weil ich Zugriff auf die Festplatte habe.

Einer der Vorteile von Open Source Software wird hier zum “Nachteil”: dadurch, dass jeder den Quelltext einsehen kann, kann auch jeder solche Verfahren ableiten.

Die Disk könnte man nun mit cryptsetup-luks oder truecrypt verschlüsseln, aber da dem Benutzer oder dem Computer (welcher im Besitz des Besitzers ist) der Schlüssel bekannt sein muss, ist das wiederum nicht manipulationssicher.

Und jetzt? Zurück zu closed source systemen?

Nein, keinesfalls. Die “Sicherheit”, welche ClosedSource-Systeme bieten gründet einzig und alleine darauf, dass nur eine geschlossene Benutzergruppe die Interna des Systems kennen. Dadurch ist zwar der Kreis potentieller Manipulatoren recht begrenzt, aber andererseits können genau dadurch Sicherheitsmängel lange unentdeckt bleiben.

Ein Beispiel aus der Praxis: Wir haben einen ein Archivierungssystem für E-Mails von einem bekannten Hersteller letzthin zur Vernichtung bekommen. Wie ich bin habe ich mich damit ein paar Wochen nach Feierabend beschäftigt.

Auf den ersten Blick ist die Appliance ein in sich abgeschlossenes System. Zugänglich sind lediglich vorne zwei LFF-Slots für die Festplatten und hinten zwei Netzwerkschnittstellen.

Auf den zweiten Blick fällt auf, dass hinten an der Appliance ein Blechstreifen mit 8 “Spezialschrauben” (auch bekannt als nintendo bolts) befestigt ist. Der Schraubenzieher ist relativ simpel per Ebay beschaffbar oder mit dem Dremel selber herstellbar. Unter dem Streifen kommen diverse Schnittstellen zum Vorschein: USB, VGA, SCSI, PS/2, RS232.

Also wurde ein Monitor angeschlossen und der Bootprozess beobachtet. Leider war das BIOS Kennwortgeschützt, also war es nicht möglich, die Bootreihenfolge zu ändern.

Herauszufinden, wie ich an das Mainboard des Systems komme, war nicht ganz einfach. Das Board liegt auf einer Art “Schlitten”, welcher in das Gehäuse eingeführt wird. Um daran zu gelangen musste mit einem Stück Draht mit Schlinge durch die LFF-Schächte eingeführt werden und irgendwo im Gerät links und rechts zwei Hebel gezogen werden. Man braucht ein Endoskop dazu…

Das weitere Vorgehen war simpel: BIOS-Kennwort zurücksetzen, Linux-LiveCD booten, die interne SD-Karte analysieren, Passphrase klauen, FreeBSD-LiveCD booten, Volume einhängen, root-Kennwort ändern…

Aber.. Aber…

Ich wäre eher dafür, die gesetzlichen Grundlagen zu überdenken. Jedes Dokument ist fälschbar, egal auf welchem Medium es sich befindet. Sicherheit entsteht nur durch Vertrauen. Vertrauen in Personen, nicht in Maschinen.

Wenn der Bund solche Vorgaben liefert soll er sich auch um eine zuverlässige, vertrauenswürdige, finanzierbare Lösung kümmern.

Und ganz ehrlich: Sobald das 3D-Drucken perfektioniert ist, ist nichts mehr manipulationssicher. (Gruss an den Urheber dieses Satzes, habe ihn nur leicht abgewandelt)

Ich bin übrigens offen für Ideen, wie man es richtig machen könnte. Mir ist noch keine gute Lösung eingefallen

2 thoughts on “Warum die gesetzeskonforme Archivierung von elektronischen Dokumenten (mit OpenSource-Lösungen) nicht funktionieren kann”

  1. Danke für Deinen Artikel! Ja, die Manipilationssicherheit ist ein grundlegendes Problem beim Umgang mit elektronischen Dokumenten. Mir sind drei Ansätze bekannt, damit umzugehen:

    1. Signatur inkl. Zeitstempel: Das ist eigentlich dasselbe wie das oben von Dir beschriebene Hash-Verfahren, allerdings unter Verwendung eines Zertifikats. Macht man z.B. bei Debian GNU/Linux für jedes Software-Paket mithilfe von gpg. Die Probleme hier:
    – Für die Archivierung müsste der private Schlüssel des Zertifikats auf dem Server liegen und kann dort wieder manipuliert werden. Mache ich so bei meinem Backup-Server. Die Daten werden per gpg verschlüsselt und signiert, bevor sie aufs Tape, resp. auf den Offsite-Storage geschrieben werden. Damit dieser Schlüssel nicht in fremde Hände fällt ist dieser Server mit LUKS verschlüsselt und ich muss zum Booten ein Passwort eingeben. Wird er jedoch zur Laufzeit kompromittiert, kann auch der Schlüssel geklaut werden.
    – Man muss diesem Zertifikat für immer vertrauen. Sobald das Zertifikat kompromittiert wurde, müssen alle damit signierten Daten als potenziell kompromittiert angesehen werden, da nun nachträglich neue oder veränderte Dokumente von Dritten signiert werden können.

    2. Das ewige Logfile: Dabei wird ein externes und öffentliches Logfile mit Zeitstempeln und Hashwerten geführt. Wobei diese Hashwerte sowohl das Logfile selbst als auch die zu verifizierenden Daten umfasst. Somit wird sowohl die Integrität des Logfiles wie auch der Daten zu jenem Zeitpunkt nachvollziehbar. Weitere Details zu diesem Konzept findest Du hier:
    http://altlasten.lutz.donnerhacke.de/mitarb/lutz/logfile/idee.html

    3. Vermutlich mit 2. verwandt oder eine parallele Entwicklung: Der trusted timestamp. Siehe dazu Wikipedia und den entsprechenden RFC:
    http://en.wikipedia.org/wiki/Trusted_timestamping
    http://tools.ietf.org/html/rfc3161

    HTH Simon

    Reply

    1. Hallo Simon

      Vielen Dank für Deine Anregungen! Und entschuldige bitte die späte Reaktion, wir sind in der Firma momentan ordentlich überbelastet.

      Zu 1.:
      Mein “Demo-Hash” besteht aus der sha512sum der Datei, welche mit dem Dateipfad, den Zugriffsrechten, der Inodenummer und einem Haufen anderen Dateispezifischen Informationen gesalzen wurde. Meiner Meinung nach ist es eigentlich egal, welches Verfahren angewandt werden, denn alle haben das gleiche Problem: das Hashingverfahren oder der Schlüssel muss auf dem System abgelegt werden. Diese Information kann, wie Du richtig anmerkst, entwendet werden.

      Meiner Meinung nach ist das von Die beschriebene Verfahren allerdings nicht gerichtsfest. Das Problem hier ist nicht der Angriff von aussen, sondern der Angriff von innen. Da Du im Besitz des LUKS-Kennwort bist und das Verfahren ausgearbeitet hast, kannst Du jederzeit die Daten manipulieren.

      Zu 2.:
      Eine interessante Idee, welche mir auch schon seit Tagen durch den Kopf schwirrt. Einfach die Logfiles in Echtzeit veröffentlichen. Da da diese Datei ja sowieso keine sicherheitsrelevanten Daten enthalten dürfen, spräche nichts dagegen, dass beliebige Personen diese Informationen einsene und verwahren könnten. Allerdings stelle ich es mir etwas schwierig vor, nach 10 Jahren noch einen dieser Personen aufzutreiben, allerdings frage ich mich, wir gross das Vertrauen in diese Lösung wäre. Schlussendlich könnten die Informationen ja auf dem Weg zum Betrachter verfälscht werden.

      Zu 3.:
      Ehrlich gesagt bin ich von dieser Idee auch nicht allzu begeistert, denn meiner Meinung nach verlagert sich das Problem nur, da hier das Vertrauen auch wieder nur durch eine Drittorganisation (Time Stamping Authority) geschaffen wird…

      —

      Wir haben das Problem des langen und breiten in der Firma diskutiert. Dabei ist eigentlich nur eine zeimlich vereinfachte Beschreibung des Problems entstanden:

      Das Überwachungsvideo auf DVD muss manipulationssicher gelagert werden. Damit eine Person nicht die DVD aus dem Regal nehmen, auslesen, manipulieren, neu brennen und ins Regal zurückstellen kann, muss das Regal videoüberwacht werden. Dieses Überwachungsvideo auf DVD muss manipulationssicher gelagert werden. Damit eine Person nicht die DVD aus dem Regal nehmen, auslesen, manipulieren, neu brennen und ins Regal zurückstellen kann, muss das Regal videoüberwacht werden… Idem per idem.

      Eine Idee hätte ich: Vorausgesetzt, es ist ein nur einmal beschreibbares Medium (WORM) und eine garantiert exakte Zeitquelle vorhanden, könnte man mit GnuPG eine Art Einwegschlüssel generieren: Man generiert für jede Datei ein Schlüsselpärchen, signiert die Datei und verwirft den signierenden Schlüssel sofort. Auf das WORMedium wird die Datei, die Signatur und der öffentliche Schlüssel übertragen. Mit dem Verwerfen des privaten Schlüssels wird allerdings nur sichergestellt, dass die Datei nicht nachsigniert werden kann.

      Dieses Verfahren schützt aber nicht davor, dass das ganze Medium dupliziert und dabei manipuliert werden könnte. Um dies zu verhindern müsste das ganze Medium signiert werden, die Signatur wieder sicher gelagert werden, usw…

      Also entweder mache ich mir zu viele Gedanzen zu dem Thema oder wir bräuchten hier mal ein paar Philosophen, Anwälte, Politiker und einen Priester…

      Reply

Leave a Reply to chief Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.