Hyper Backup HyperBackup Verschlüsselung (Client-side encryption) - Details

Status
Für weitere Antworten geschlossen.

mrsandman

Benutzer
Mitglied seit
08. Sep 2013
Beiträge
85
Punkte für Reaktionen
2
Punkte
8
Hallo Community

Da sich Synology ja relativ bedeckt hält, was die Datenverschlüsselung von Hyper Backup angeht, habe ich mich mal daran gemacht und mittels Reverse Engineering ein Script gebastelt, das verschlüsselte Daten aus einem Backup extrahieren kann und somit auch zeigt, wie die Verschlüsselung funktioniert.

Das Script findet ihr unter: https://github.com/mistersandman/hyperbackup_decrypt

Für alle die sich nicht mit dem Script beschäftigen wollen, hier die wichtigsten Details:

1. Synology verwendet ein Standard-Schema bei der Verschlüsselung: Die Daten sind mit AES verschlüsselt und die Parameter für AES sind wiederum mit RSA verschlüsselt.

2. Die Files und Filenamen werden mit AES256 im CBC Modus verschlüsselt. AES-CBC benötigt einen Schlüssel und einen Initialisierungsvektor.

3. Die verschlüsselten Filenamen und einige Metadaten sind in einer SQLite Datenbank abgespeichert. Die Filenamen müssen zuerst via Base64 dekodiert werden und werden danach mit AES256-CBC entschlüsselt. Als Schlüssel für AES dient hierzu der SHA256-Hash vom privaten RSA Schlüssel zusammen mit dem unikey Wert aus dem _Syno_TaskConfig File (ein von Hyper Backup generierter unique identifier für das Backup). Als Initialisierungsvektor für AES dient der MD5-Hash vom unikey Wert zusammen mit einem festen Saltwert (kkE7sRZRvnbVlJFofhD7WCXumXBGyzki)

4. Um in der Ordnerstruktur zu navigieren, haben alle Einträge in der Filedatenbank eine ID und eine Parent ID. Die ID besteht aus den ersten 4 bytes des MD5-Hashes vom verschlüsselten Pfad des Elternordners und dem vollen MD5-Hash vom verschlüsselten Pfad des Eintrags, wobei sich der verschlüsselte Pfad aus den verschlüsselten Ordnernamen verbunden durch / (slash) zusammensetzt. Die ID des Wurzelordners besteht aus den ersten 4 bytes des MD5-Hashes von "." und dem vollen MD5-Hash von "." (also 5058f1af5058f1af8388633f609cadb75a75dc9d).

5. Die eigentlichen Daten sind in Chunks unterteilt, welche in verschiedenen Buckets abgespeichert werden. Die Chunks sind mit AES256-CBC verschlüsselt. Der Schlüssel und der Initialisierungsvektor sind mit RSA2048 verschlüsselt in einer Datenbank gespeichert und können mit dem privaten RSA Schlüssel entschlüsselt werden. Die entschlüsselten Chunks können zusätzlich noch mit lz4 komprimiert sein.

6. Der öffentliche RSA Schlüssel ist unter Config/public.pem{.n} gespeichert. Damit werden die AES256-CBC Parameter für die Chunk-Entschlüsselung verschlüsselt. Diese Parameter können mit dem privaten RSA Schlüssel (der zum Download angeboten wird, nachdem man einen Backup Task in Hyper Backup eingerichtet hat) wieder entschlüsselt werden. Die Integrität der Parameter kann mit einem MD5-Hash des verschlüsselten AES-Schlüssels zusammen mit einem festen Saltwert (8Llx6OSaDPzbwCkjG8eYc64GZGMIlMXm) und dem verschlüsselten Initialisierungsvektor überprüft werden. Dieser MD5-Hash ist ebenfalls in der Datenbank gespeichert.

7. Der private RSA Schlüssel kann mittels dem festgelegten Passwort aus dem File Config/encKeys{.n} wiederhergestellt werden. Er liegt mit AES256-CBC verschlüsselt in dieser Datei. Der AES Schlüssel für die Entschlüsselung ist der SHA256-Hash von einem festen Saltwert zusammen mit dem Passwort (5mNgudh053SUoMrZxoKG8GUWyj6kEtGO). Der Initialisierungsvektor ist der MD5-Hash vom unikey Wert zusammen mit einem festen Saltwert (CIpfMargmxetgFtkBmG3KqEiQ6qfqZgF)

8. Um das Passwort zu verifizieren, wird zweimal ein SHA256-Hash auf einen fixen Saltwert (5mNgudh053SUoMrZxoKG8GUWyj6kEtGO) zusammen mit dem Passwort angewendet und mit einem Wert verglichen, der auch in Config/encKeys{.n} gespeichert ist.

9. Die Filestruktur (das Mapping von Filenamen zu den zugehörigen Chunks) ist relativ komplex, vermutlich um die Speichereffizienz von mehreren Backupversionen zu optimieren. Die Backupversionierung habe ich (noch) nicht durchschaut. Ich glaube, dass mein Script lediglich die jeweils neuste Version extrahiert. In der Datenbank der Filenamen findet sich ein Offsetwert. In der Datei Config/virtual_file.index/0.idx{.n} findet sich an diesem Offset Informationen zum File. Unter anderem findet man dort die ID des file chunk indexes und einen Offset für diesen Index. Im entsprechenden file chunk index unter Config/file_chunk{ID}.index/0.idx{.n} am Offset stehen dann weitere Offsets für den chunk pool index Pool/chunk_index/0.idx{.n}. Im chunk pool index an den entsprechenden Offsets stehen dann schlussendlich die bucket ID und der bucket index offset für den chunk. Der bucket index befindet sich in Pool/0/0/{ID}.index{.n}. An den bucket index offsets stehen der chunk offset im bucket file, die Grösse des Chunks und für die Dekomprimierung noch die originale Grösse der Daten. Der verschlüsselte Chunk kann dann aus Pool/0/0/{ID}.bucket{.n} extrahiert, entschlüsselt und dekomprimiert werden. Die Integrität eines Chunks kann mittels des MD5-Hash über den entschlüsselten und dekomprimierten Chunkinhalt überprüft werden. Dieser Hashwert ist ebenfalls in den bucket index Einträgen gespeichert.

Es gibt noch einige Stellen im Script in denen Daten gelesen werden, deren Bedeutung sich mir noch nicht erschlossen hat. Vielleicht hat ja jemand von euch noch Spass daran, da noch weiter zu forschen. Ebenfalls offen ist noch, wie die Versionierung funktioniert, da ich meinen Fokus nur auf die Verschlüsselung gelegt habe. Ein weiterer Spezialfall ist das Backup der DSM-Konfiguration. Dazu findet sich zwar einen Eintrag in Config/@Share/@AppConfig zum file config.dss, welcher aber einen negativen Eintrag als Offset für die virtuelle Filetable hat. Ich vermute diese Datei wird verschlüsselt im File Pool/file_pool/1.file{.n} gespeichert, aber ich habe dessen Format noch nicht entziffern können.

Gruss mrsandman
 
Zuletzt bearbeitet:
  • Like
Reaktionen: lueromat

Sedrah

Benutzer
Mitglied seit
01. Dez 2014
Beiträge
47
Punkte für Reaktionen
0
Punkte
6
Also von mir gibts da doch gleich mal einen Daumen hoch!
 

frankyst72

Benutzer
Mitglied seit
01. Jun 2015
Beiträge
1.955
Punkte für Reaktionen
3
Punkte
58
Und ich knie nieder, 25 Jahre in der IT tätig und kaum einen Satz vollständig verstanden... Respekt!

Diese Parameter können mit dem privaten RSA Schlüssel (der zum Download angeboten wird, nachdem man einen Backup Task in Hyper Backup eingerichtet hat) wieder entschlüsselt werden.
ich habe diesen Download immer übersprungen, weil ich davon ausgehe, dass ich mein Passwort nicht vergesse und eher den USB-Stick verliere/verlege. Habe ich dadurch irgendwelche Nachteile zu befürchten?
 

mrsandman

Benutzer
Mitglied seit
08. Sep 2013
Beiträge
85
Punkte für Reaktionen
2
Punkte
8
Der private RSA Schlüssel wird mit dem Passwort verschlüsselt dem Backup beigelegt (File Config/encKeys{.n}). Wenn beim Entschlüsseln das Passwort benutzt wird, dann wird damit zuerst der private RSA Schlüssel entschlüsselt und danach verläuft das Entschlüsseln genau gleich weiter, als wäre direkt der private RSA Schlüssel benutzt worden. Mein Script kann den privaten Schlüssel mit dem Passwort extrahieren.

Dein worst-case Szenario wäre also, dass die Datei Config/encKeys{.n} kaputt geht. Dann könntest du alle deine Daten nicht mehr entschlüsseln, obwohl du das Passwort kennst. Allerdings ist dieser Fall genau so wahrscheinlich, als dass die Datenbank mit den verschlüsselten AES Parametern kaputt geht und die Daten auch nicht mehr entschlüsselt werden können.

Wenn du also darauf vertraust, dass deine Backup-Daten nicht kaputt gehen, dann hast du absolut keinen Nachteil. Andernfalls hast du eine etwas grössere Wahrscheinlichkeit, dass du die Daten nicht mehr entschlüsseln kannst wenn du nur das Passwort behältst, da du dich auf die absolute Vollständigkeit von zwei Dateien (der verschlüsselte private RSA Schlüssel, und die verschlüsselten AES Parameter) verlassen musst.
 

amarthius

Super-Moderator
Teammitglied
Mitglied seit
03. Jun 2009
Beiträge
6.812
Punkte für Reaktionen
33
Punkte
174
Interessanter Beitrag. :cool: Falls du dich in dem Gebiet auskennst: Wie schätzt du die Implementierung der Verschlüsselung von Synology ein? Macht eine stärkere Verschlüsselung Sinn? Ist es umständlich implementiert was auf die Performance drückt?
 

mrsandman

Benutzer
Mitglied seit
08. Sep 2013
Beiträge
85
Punkte für Reaktionen
2
Punkte
8
Zunächst sei erwähnt, dass ich kein Profi bin in dem Gebiet. Allerdings kenne ich mich schon etwas aus, deshalb hier meine Einschätzung:

Das verwendete Verschlüsselungsverfahren zur Datenverschlüsselung ist ein Standard-Schema: Die Daten werden mit einem symmetrischen (und damit effizienten) Verfahren ver- und entschlüsselt (hier AES256-CBC) und die Parameter für das symmetrische Verfahren (hier Schlüssel und Initialisierungsvektor) werden mit einem asymmetrischen (und damit etwas aufwändigeren) Verfahren ver- und entschlüsselt (hier RSA2048). Das asymmetrische Verfahren hat auch den Vorteil, dass HyperBackup ein Backup erstellen kann, ohne dass es den Schlüssel für die Entschlüsselung kennt (den privaten RSA Key). HyperBackup braucht lediglich den öffentlichen Schlüssel und der private Schlüssel kann separat aufbewahrt werden.

Über die Stärke der Verschlüsselung lässt sich diskutieren. AES256 wird diesbezüglich als sicher bis sehr sicher eingestuft. Bei RSA hätte man auch RSA4096 nehmen können, da dies Performance-mässig überhaupt nicht ins Gewicht fällt (es müssen nur wenige Bytes damit ver- und entschlüsselt werden). Allerdings sollte auch RSA2048 für die nächsten 10 Jahre genügend sicher sein.

Etwas bedenken habe ich allerdings noch bei der Verschlüsselung des privaten RSA Schlüssels, welcher mittels des Passworts aus dem Backup extrahiert werden kann. Hier wird zur Ver- und Entschlüsselung auch wieder AES256-CBC (grundsätzlich ein sicheres Verfahren) angewendet. Allerdings ist der Initialisierungsvektor bekannt (MD5-Hash von unikey + bekannter Saltwert) und der Schlüssel ist der SHA256-Hash von Saltwert (bekannt) + Passwort, wobei der SHA256-Hash von diesem SHA256-Hash wiederum zur Verifikation ebenfalls bekannt (also im Backup gespeichert) ist. Wenn diese Verschlüsselung schwächer als RSA2048 ist, dann ist sie das schwächste Glied in der Kette. Vielleicht kann sich ja jemand der sich hier besser auskennt dazu äussern.

Bezüglich Performance: Das Hauptgewicht der Arbeit bei einem Backupvorgang liegt ganz klar auf der Verschlüsselung (und optionaler Komprimierung) der eigentlichen Daten. AES256-CBC kann sehr effizient implementiert werden. Viele Prozessoren bieten sogar eigens dafür entwickelte Instruktionen (siehe AES instruction set). Jetzt kommt es natürlich darauf an, wie Synology das implementiert und ob diese Instruktionen (falls vorhanden) auch genutzt werden. Dazu kann ich leider nichts sagen. Die ganze Versionsverwaltung und Fileablage mit den Chunks mag umständlich wirken, kann aber meiner Meinung nach effizient implementiert werden (hier auch wieder die Frage, ob Synology das auch wirklich effizient tut).

Mein Fazit: HyperBackup verwendet eine relativ starke Verschlüsselung, welche effizient umgesetzt werden kann. Eine wesentlich stärkere Verschlüsselung ist aus heutiger Sicht nicht nötig und Performance-mässig nicht sinnvoll.
 

frankyst72

Benutzer
Mitglied seit
01. Jun 2015
Beiträge
1.955
Punkte für Reaktionen
3
Punkte
58
Danke!
 

rushida

Benutzer
Mitglied seit
27. Nov 2016
Beiträge
23
Punkte für Reaktionen
1
Punkte
3
Danke Mr Sandman für diese tolle Arbeit. Kurze Frage:


glaubt Du, dass die Verschlüsselung über Hyperbackup direkt nach Amazon Cloud besser ist, als die Option über HyperBackup einee Cloud über WebDav einzubinden?

Danke
 

blinddark

Benutzer
Mitglied seit
03. Jan 2013
Beiträge
1.385
Punkte für Reaktionen
34
Punkte
68
Kurze Frage: Kann ich den privaten Schlüssel nachträglich noch laden?
 

jomochito

Benutzer
Mitglied seit
06. Dez 2014
Beiträge
1
Punkte für Reaktionen
0
Punkte
1
Super informativ, ausführlich und kompetent geschrieben!

Vielen Dank dafür!
 

vagzubi

Benutzer
Mitglied seit
22. Nov 2016
Beiträge
55
Punkte für Reaktionen
0
Punkte
6
Danke für die Ausführungen. Gleichzeitig nimmt es mich doch noch wunder, gibt es sowas wie ein Audit der Verschlüsselung die Synology verwendet? Leider finde ich nichts konkretes.
Allerdings habe ich eher beunruhigendes gefunden

:Ok so synology support got back to me.

The password is the only thing needed to decrypt the files, but Synology support (or whoever requests it from them or whoever you give it to) can also decrypt your files using the private key.
Officially this is for when you forgot your password.


https://forum.synology.com/enu/viewtopic.php?t=101361
 

frankyst72

Benutzer
Mitglied seit
01. Jun 2015
Beiträge
1.955
Punkte für Reaktionen
3
Punkte
58
das wäre natürlich ein Hammer!
 

whitbread

Benutzer
Mitglied seit
24. Jan 2012
Beiträge
1.294
Punkte für Reaktionen
54
Punkte
68
Steht doch genauso auf der HP
 

Fusion

Benutzer
Sehr erfahren
Mitglied seit
06. Apr 2013
Beiträge
14.135
Punkte für Reaktionen
898
Punkte
424
Dass jemand deine Wohnung aufschließen kann, wenn du ihm den Schlüssel aushändigst ist ja nun wahrlich nichts Neues.
Und ohne Passwort oder private Schlüsseldatei kann auch Synology die Daten nicht entschlüsseln. Sehe da keinerlei Sicherheitsproblem.
 

frankyst72

Benutzer
Mitglied seit
01. Jun 2015
Beiträge
1.955
Punkte für Reaktionen
3
Punkte
58
ja, hab ich wohl etwas hastig gelesen... wozu brauch ich den Support, wenn ich den Key hab... naja.
 

mrsandman

Benutzer
Mitglied seit
08. Sep 2013
Beiträge
85
Punkte für Reaktionen
2
Punkte
8
Bitte entschuldigt meine lange Abwesenheit, ich war die letzte Zeit ziemlich beschäftigt mit meinem Studium.

Nun, der Reihe nach:

@rushida: Ich bin mir nicht sicher, ob ich die Frage richtig verstehe, bzw. was genau meinst du mit "besser"? Bezüglich Sicherheit sind beide Methoden äquivalent, wenn Du Client-seitige Verschlüsselung benutzt. Bezüglich Komfort, Preis, etc. kann ich natürlich nichts sagen, vor allem da es auch stark vom Cloud-Anbieter abhängt, welchen Du per WebDav einbinden würdest. Amazon Cloud Drive stellt meines Wissens keine WebDav Anbindung zur Verfügung.

@blinddark: Nein, mit Synology Tools und Funktionen ist dies nicht möglich. Allerdings kannst du mit dem Passwort und meinem Script den privaten Schlüssel aus deinem Backup extrahieren. Dazu musst du lediglich mein Script laufen lassen (ohne die letzten 2 Zeilen, welche alle Daten extrahiert). Danach findest du unter extract/private.pem den privaten Schlüssel.

@vagzubi: Nein, ein Audit der Verschlüsselung gibt es nicht. Allerdings erübrigt sich ein solches meiner Meinung nach auch, da es sich um closed-source Software handelt, denn wenn du dem Audit einer closed-source Software vertraust, kannst du auch direkt der Software vertrauen. Das Audit bringt hier keinen Mehrwert, da niemand dieses verifizieren kann. Da das von Synology gewählte Verschlüsselungsverfahren ein Standardverfahren ist, ist es grundsätzlich sicher (zumindest soweit dies bis heute beurteilt werden kann). Es bleibt uns aber nichts anderes übrig, als Synology zu vertrauen, dass das Verfahren korrekt implementiert und keine Hintertür eingebaut wurde. Mein Script zeigt mittels von Synology unabhängigen open-source Crypto-Libraries zumindest, dass das Verfahren korrekt implementiert ist. Für eine Hintertür gibt es bisher keine Anzeichen.
Die von Dir zitierte Aussage des Synology-Supports sagt nur aus, dass das Passwort genügt, um mit den Synology-Tools das Backup zu entschlüsseln. Das Backup kann aber auch mit dem privaten Schlüssel entschlüsselt werden. Dies ermöglicht beispielsweise dem Support jemandem zu helfen ein Backup wiederherzustellen, ohne dass das Passwort verraten werden muss (dies kann zum Beispiel nötig sein, wenn ein Backup durch einen Bug in HyperBackup nicht regulär wiederhergestellt werden kann). Ohne das Passwort oder den privaten Schlüssel kann niemand das Backup entschlüsseln (auch nicht Synology-Support, sofern wir vertrauen, dass keine Hintertüren existieren).
 

vagzubi

Benutzer
Mitglied seit
22. Nov 2016
Beiträge
55
Punkte für Reaktionen
0
Punkte
6
Hoffe du hast die Prüfungen gut überstanden.

Ich sehe deine Punkte. Aber beim Thema Audit bin ich nicht ganz bei dir. Der Nutzen eines Audit ist ja das eine 2te Stelle die Verschlüsselung überprüft und mit seiner Reputation bürgt. Das geht auch bei Closedsurce Codes. Synology müsste einfach das in Auftrag geben und den Zugang ermöglichen. Ob man dann Auditor traut ist dann ja wieder eine Frage für sich.

Gruss und gute Erholung
 

vagzubi

Benutzer
Mitglied seit
22. Nov 2016
Beiträge
55
Punkte für Reaktionen
0
Punkte
6
Nur zur Info für alle die (wie ich) nicht ganz so den Überblick haben wie das ganze Verschlüsseln usw funktioniert. Die Datei _Syno_TaskConfig beinhaltet Die Daten wie zb welche Ordner wurden Selektioniert. Je nach Konfig kann man hier ein Teil der Datenstruktur im Klartext sehen.

Gruss
 

mrsandman

Benutzer
Mitglied seit
08. Sep 2013
Beiträge
85
Punkte für Reaktionen
2
Punkte
8
Ja, vielen Dank, die Prüfungen sind gut gelaufen! :)

Ich gebe dir recht bei deinem Einwand und präzisiere deshalb: Ein Audit unter vertretbarem Kostenaufwand erübrigt sich. Um die chain of trust aufrecht zu erhalten, müsste der Auditor für jede Version von HyperBackup alle Änderungen überprüfen und den Build-Vorgang für die Pakete replizieren, damit er Hashcodes für die von Synology verteilte Software bereitstellen kann, sodass die Kunden verifizieren können, dass der von Synology verteilte Code, wie auch der vom Auditor überprüfte Code übereinstimmen. Dies wäre ein sehr teures Prozedere.

Dein zweiter Punkt bezüglich unverschlüsselten Pfadnamen ist ganz wichtig, vielen Dank für den Hinweis! Alle Pfade der individuell für das Backup ausgewählten Ordner werden unverschlüsselt in der Datei _Syno_TaskConfig gespeichert.
 
Status
Für weitere Antworten geschlossen.
 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat