Durch ein paralleles Splitting in Kombination mit dem Bermuda Concept® kann man sich bei Backup-Verfahren und/oder bei der (Langzeit-)Archivierung resp. Auslagerung von Daten ganz von einem aufwändigen Key Management lösen und zusätzlich auch technisch deutlich sicherer vorgehen.
Man komprimiert nur in 1 Step; in dem zweiten Step werden die Teile lediglich auf 3 Standorte verteilt, d.h. versendet (jeweils 2 x 1/3 der FLAMFILE®):
- 1+2 nach Standort A
- 1+3 nach Standort B
- 2+3 nach Standort C.
Man kann selbstverständlich die Teildateien auch auf Datenträger schreiben und getrennt auslagern.
Man verbessert den Datenschutz erheblich, weil es lokal unmöglich ist, Daten zu dekomprimieren, eben weil die Daten in diesem Dreieck nicht an einem Standort zu 100% verfügbar sind. Die Daten können sogar an einem der 3 Standorte total verloren gehen.
Das könnte man mit einer Verschlüsselung mit einem » One-Time-Pad vergleichen, wobei das durch das parallele Splitting fehlende Teilstück einem solchen Pad entspräche, zumal die FLAMFILE® den Charakter eines Unikats hat. Jeder Standort braucht ein fehlendes Drittel von einem der beiden anderen Standorte.
Im Wiederholungsfall entstünde eine anders codierte, aber gleich große FLAMFILE® mit gleich großen Teilen, die analog in einem solchen Dreieck verteilt und nur als eine in sich geschlossene Einheit wieder dekomprimiert werden können. Man kann Teile, die zwar inhaltlich gleich sind, nicht austauschen. Die parallel gesplittete FLAMFILE®, die dekomprimiert werden soll, muss in einem Prozess als eine Einheit erzeugt worden sein.
Anmerkung: Das autarke Segment-Komprimat wird mit einer CRC-Routine (32 Bits) abgesichert. Eine weitere CRC-Routine (32 Bits) wiederholt den Vorgang in Abständen von 4 Bytes und dabei bezgl. der Aufsatzpunkte versetzt (Storchen-Checksumme). Das ergibt 4 Durchläufe über jeweils 1/4 der Daten. Eine der beiden CRC-Routinen benutzt das jeweilige Zwischenergebnis (4 Bytes), um das nächste Byte mit 3 XOR (3 von 4 Bytes des Zwischenergebnisses) zu verändern. Beide Routinen werden zufallsgesteuert initialisiert. Dadurch entsteht ein verschleiertes Komprimat, das durch diese Initialisierung ein Unikat darstellt mit einer nahezu ausgeglichenen Gleichverteilung der Bytes von X'00' bis X'FF' (Entropie). Beim Splitten schreibt FLAM® reihum immer nur 4 Bytes in eine der 3 Teildateien.
Die CRC-Techniken in Verbindung mit der Verschleierung führen zu folgender quasi asymmetrischer Verteilung, weil die CRC-Technik anders vorgeht als die Verteilung auf die Teildateien 1, 2, 3:
Byte 1-4 => 1, 5-8 => 2, 9-12 => 3, 13-16 => 1, 17-20 => 2, 21-24 => 3 etc.
Im Gegensatz zur ggf. einzigen Schwachstelle eines One-Time-Pads, dass ein Angreifer zufällig (partiell) einen Teil der Daten entschlüsseln könnte, um dann in das System mit Manipulationen einzugreifen, liegen hier Daten vor, die so kompliziert verschachtelt und abgesichert sind, dass man sie nicht lesbar (!) machen kann - geschweige denn so manipulieren könnte, dass der Empfänger den Eingriff nicht erkennt.
FLAM® würde beim Dekomprimieren im betroffenen (autarken) Segment auf einen schweren Fehler laufen und abbrechen.
Man kann, um die Wirkung des parallelen Splittings zu "verfeinern", mit einem Zufallsschlüssel und AES verschlüsseln. Dieser Schlüssel muss aufgrund der Split-Technik eben gerade nicht geheim gehalten werden. Man verteilt ihn einfach auf die Header der 3 Teildateien.
Diese Vorgehensweise verschärft die Komplexität der Abhängigkeiten der Daten untereinander, so dass man sogar mit MODE=NDC (ohne Komprimierung) arbeiten könnte. Außerdem wird mit AES immer mit MACs (Message Authentication Code) gearbeitet. Das sind kryptographisch erzeugte "Checksummen". Auch diese MACs werden mit AES erzeugt. Perfekter geht es nicht. Diese äußerst wirtschaftliche, extrem sichere Lösung ist weltweit einmalig.
Die Zusatztechnik mit AES kann man auch auf 1/3 der gesplitteten FLAMFILE® und MODE=NDC beschränken, um noch mehr CPU-Zeit zu sparen, falls das bei gigantischen Mengen (Terabytes) relevant sein sollte. Dann muss man nur 1/3 der komprimierten Daten mit AES verschlüsseln.
Die System-Plattformen der Standorte dürfen unterschiedlich sein. Und auch die System-Plattform, auf der die parallel gesplittete FLAMFILE® erzeugt wird, darf von denen der Standorte abweichen. Man könnte an jedem der Standorte das Original wieder erzeugen, wenn man das fehlende Drittel hat, weil FLAM® durchgängig kompatibel ist.
Am besten man beläßt nichts auf dem System, auf dem diese 3 Teildateien erzeugt wurden. Der Zugriff der Standorte untereinander sollte blockiert werden, so dass nur ein zentrales System mit besonderer Berechtigung an die Daten der Standort herankommen kann, um die 100% Input (3/3) abzurufen, die zur Dekomprimierung gebraucht werden (ggf. auch zu der damit verbundenen Entschlüsselung über den Zufallsschlüssel aus den Headern).
Man kann Dateien/Member beliebig zu einer ganzen FLAMFILE® konkatenieren und diese als eine Einheit (!) wiederum parallel splitten, um die Teildateien auszulagern. Man muss also nicht einzelne Dateien/Member separat behandeln.
Das Bermuda Concept® (3 x 2 x 33,3% = 200%) kostet nicht mehr an Volumen, denn man archiviert ohnehin Daten an mindestens 2 Standorten (2 x 100% = 200%). Hat man z.B. um 85% komprimiert, ergibt das 2 x 15% = 30% der Originaldaten resp. 15% der klassisch archivierten 2 x 100%.
Die Entkopplung solcher Prozesse ermöglicht es, Leerlaufzeiten im Rechner (priority idle) sowie Lücken auf Leitungen zu nutzen. Trotz schneller und kostengünstiger Leitungen bleibt ein erheblicher Vorteil, das Volumen von Prozessen/Daten und die Laufzeiten zu reduzieren sowie Daten in Teilen zu versenden, weil sich Störungen einer Übertragung dann nur auf eine Teileinheit (Sendung) auswirken können. Die Wiederholung beschränkt sich auf eine Teileinheit. Durch den parallelen Start vieler FT-Prozesse entsteht eine Überlagerung, die das Maximum an Übertragungsvolumen zwischen 2 Punkten (Sender/Empfänger) fast zu 100% ausnutzt.
Man muss sich betriebswirtschaftlich gründlich überlegen, wie man mit diesem Konzept Kosten für Hochsicherheits-Archive und vergleichbare aufwändige Einrichtungen reduzieren kann, eben weil die Daten nicht an 1 Standort zu 100% verfügbar sind und weil man die Verteilung so regeln kann, dass keiner dieser 3 Standorte selbst auf Teildateien an anderen Standorten zugreifen darf (siehe oben). Damit ist auch die Sicherheit gegenüber dem/den Dienstleister/n an den Standorten gewährleistet.
Im Zentrum des Konzepts stehen die 3 Eckpunkte (Standorte) eines Dreiecks - nicht etwa das "Nichts", wie wir es aus dem Bermuda-Dreieck kennen und dessen Basis ggf. sogenannte Monsterwellen sein sollen.
Mit FLAM® kann nichts im Nichts verschwinden.
Der heutige Aufwand für Hochsicherheits-Archive ist in manchen Fällen irrational. Maschinenpistolen täuschen Sicherheit vor, die das Bermuda Concept® schon im Ansatz bietet. Nur der Zugriff nebst Berechtigungen an den betr. Standorten zur gleichen Zeit von einer Zentrale, die allein zugriffsberechtigt ist, muss organisiert werden.
Allein der Eigentümer der Daten kann auf seine Daten zugreifen und diese in einem Prozess mit FLAM® wieder herstellen.
Das Bermuda Concept®: Ein Dreieck mit sicheren Eckpunkten als Bollwerk für alles, worauf es ankommt, um multiflexibel zukunfts-/sicher zu archivieren.
Nachtrag für jene, denen der Aufwand zur Verschlüsselung trotz Komprimierung immer noch zu hoch ist, z.B. weil das Datenvolumen extrem groß ist:
Es geht hier nicht um das Bermuda Concept®, sondern nur um CPU-Zeit. Man komprimiert und splittet zunächst parallel in n Teildateien ohne jegliche Verschlüsselung. Und dann wendet man nur auf eine der n Teildateien dieser parallel gesplitteten FLAMFILE® ein Standardverfahren wie AES an. Als Parameter zur Komprimierung verwendet man MODE=NDC, weil dann der Input, diese Teildatei, nur segmentiert und in Segmenten kopiert wird, um keine CPU-Zeit zu verschenken. Diese Daten-Segmente werden verschlüsselt und über MACs abgesichert. Nun gibt es ein kritisches 1/n, um die n Teildateien dekomprimieren zu können. Das genügt.
limes®: leistung im grenzbereich des machbaren.
limes®: efficiency at the limit of possibility.
© 1985 - 2011 limes datentechnik® gmbh
