Eine standardfähige Einheit: ADC & AES

Das Highlight in FLAM® V4.x ist, dass effizient, weil mit ADC (NDC) strukturiert komprimierte Daten in autarken (!) Segmenten, wie sie für FLAM® als Zugriffsmethode (Access Method) gebraucht werden, mit AES heterogen und/oder hybrid kompatibel verschlüsselt werden können:

data compression & AES encryption in autarchic units.

FLAM® unterteilt Dateien resp. Member beim Lesen in solche autarken Segmente à 64 KB (netto) – in sich getrennt nach Satzattributen (Längen) und Satzinhalten (netto) - analog zur ADC-Komprimierung. Diese Segmente bilden Member (z.B. aus Dateien bzw. Membern aus Ordnern), und diese intern aus komprimierten Segmenten synchron zum Input gebildeten Member bilden die FLAMFILE®. Das ergibt formal eine Sammeldatei, z.B. aus nur einer Datei/einem Member resp. einem Ordner aus Dateien/Membern resp. einer Liste aus Dateien ergibt sich eine (ggf. seriell/parallel gesplittete) FLAMFILE®, die man beliebig und völlig unabhängig vom Original formatieren kann. FLAM® muss zur Segmentbildung nur wissen, was ein "Satz" als logische Einheit sein soll resp. wie "satzweise" gelesen/geschrieben werden soll (in der Regel gemäß DMS erkennbar). Ein "Satz" kann z.B. in Printfiles eine Zeile mit Delimiter sein.

Auf Mainframe kennt man variabel lange Sätze mit einem binären Satzlängenfeld (SLF) davor (4 Bytes). Die 4 Bytes sind Teil der Satzlänge. Und es gibt Sätze mit fixer Länge (ohne SLF). In diesem Format steht die Länge im Katalog.

Man kann das Original auch einfach "unstrukturiert" lesen - ohne Beachtung von Formaten resp. logischen Einheiten (Sätzen). Das hat zur Konsequenz, dass beim Dekomprimieren nur so geschrieben wird, wie beim Komprimieren gelesen wurde - ohne klassische Satzformate. Auch Segmente sind dann nicht logisch gebildet worden und für eine logische Zugriffstechnik ungeeignet.

Damit sind gewisse Format-Konvertierungen per Parameter nicht mehr möglich, denn diese basieren auf der Invarianz der Daten, die die eigentliche Information ausmachen und die sich bei einer Konvertierung (Code, Format) inhaltlich (als Information) nicht ändern. Mit Modulen, die über einen Exit integriert werden, kann man völlig unabhängig von jeder Parametrisierung individuelle Konvertierungsanforderungen realisieren.

Wegen der Option, FLAM® als Zugriffsmethode zu nutzen, ist die Bildung der autarken Segmente/Member obligatorisch, aber deren Komprimierung kann durch MODE=NDC (No Data Compression) umgangen werden, wenn man nur segmentieren/verschleiern sowie verschlüsseln und/oder konvertieren/umformatieren will, z.B. zur Nutzung der homogenen, heterogenen und/oder hybriden Kompatibilität, die FLAM® gewährleistet, oder wenn der Input bereits komprimiert vorliegt resp. eine (verlustfreie) Komprimierung nicht lohnt.

Bilder, gescannte Dokumente u.dgl. werden in der Regel nur "verlustarm" komprimiert, um das Datenvolumen (Pixel) drastisch zu reduzieren, oder dürfen z.B. wegen gesetzlicher Vorschriften nicht komprimiert werden. Die "verlustarme" Komprimierung führt zu einem Qualitätsverlust oder verletzt ggf. Revisionsvorschriften. Auch eine Datei, die im Original sowohl Satzlängenfelder als auch Satzdelimiter kennt, kann mit FLAM® so verarbeitet werden, dass die "de-FLAM®-bierte" Datei genau dem Original entspricht. Ein Problem im Datenaustausch abdruckbarer Daten oder internationaler Standards (z.B. XML-Formate), das oft übersehen wird. Wer die Satzlängenfelder ignoriert, weil ihm die anderen Merkmale genügen, bekommt das Original nicht zurück und kann damit beim Vergleich zwischen Original und Dekomprimat auf Fehler stoßen.

Vom National Institute of STandards der USA (NIST) wurde der Advanced Encryption Standard (AES) zur Verschlüsselung von Daten festgelegt. Dieser Algorithmus wurde von belgischen Mathematikern entwickelt. Die Nutzung ist ab FLAM® V4.0 möglich, wenn man mit MODE=ADC® oder MODE=NDC arbeitet.

Als Schlüssel können heterogen kompatibel sogar abdruckbar variabel bis zu 64 Zeichen in ASCII/EBCDIC oder Bytes in Binär-Code (hexadezimales Format) angegeben werden; oder der Schlüssel steht in einer Datei, die zugeordnet wird. Intern wird in Einheiten von 16 Bytes mit einer Schlüssellänge von 128 Bits (16 Bytes) gearbeitet (AES-128).

Zur Absicherung der segmentierten Daten (Segment/Member/File) werden hierarchisch verknüpfte irreversible Kontrollfelder (MACs) eingefügt, die ebenfalls mit AES gebildet werden (Vertraulichkeit der Nettodaten, Identität, Authentizität, Reihenfolge der Segmente/Member, Vollständigkeit, Manipulationsschutz, Revisionssicherheit u.a.).

Ein komplexes Passphrasing erzeugt verschachtelt eine Fülle von sämtlich irreversiblen Ableitungen auf File-, Member- und Segment-Level. Damit macht FLAM® eine "Brute Force Attack" schon im Ansatz äußerst zeitaufwendig. Hat der FLAM®-Anwender 64 Bytes (512 Bits) als Schlüssel benutzt, kann der Angreifer das nicht gezielt über einen anderen Punkt umgehen. Es ist nicht möglich, Schlüssel "seitwärts" einzuschleusen, um z.B. mit schmaleren Schlüsseln zu "experimentieren" (statt 2**512). Hinzu kommt, dass die Schlüssellänge selbst variabel ist. Folglich ist der Längencode (6 Bits) Teil des Schlüssels. Das ergibt sogar 2**518 Varianten.

Bei der Entschlüsselung geht man bei jedem Segment genau so vor wie bei der Verschlüsselung. Man kann selbstverständlich in keinem Teil eines Segments aufsetzen - nur am Segmentanfang. Ein Segment (dessen Komprimat) muss eine Mindestmenge haben; ist das Komprimat kleiner, wird aufgefüllt und erst dann verschlüsselt.

Durch den segmentweisen Aufbau der FLAMFILE® ist ein direkter Zugriff auf ein verschlüsseltes/komprimiertes Segment/Member möglich. Darauf aufbauend kann man effiziente Such-/Lese-Strategien (Selektionen) entwickeln, die obendrein mehr Sicherheit und Datenschutz gewährleisten.

Verschlüsselung, Komprimierung, Konvertierung, Formatierung etc. werden durch Parameter aktiviert. Es gibt Interfaces/Exits/Schnittstellen, die individuelle Erweiterungen des Funktionsumfangs ermöglichen, z.B. zur Lösung komplizierter Kompatibilitätsprobleme. Man kann FLAM® auch als Unterprogramm in Anwendungen integrieren. Auf MVS gibt es FLAM® als integriertes Subsystem und auf UNIX/LINUX kann man es im Pipelining einsetzen.

Durch solche Erweiterungen kann FLAM® hybrid kompatibel arbeiten. Das bedeutet z.B., dass auf einer Seite eine Kopplung zu einer Hardwareeinrichtung (z.B. HSM mit Triple DES) bestehen darf, die auf der anderen Seite durch eine Software-Emulation ersetzt wird. Trotzdem wird das Komprimat mit AES verschlüsselt/abgesichert, und zwar mit einem vom HSM generierten Zufallsschlüssel (4 x 128 Bits).

Der Zufallsschlüssel wird mit dem im HSM zugewiesenen geheimen Schlüssel mittels Triple DES verschlüsselt und im Header der FLAMFILE® abgelegt. Dieser Header wird signiert. Damit kann der Empfänger den Zufallsschlüssel gemäß dem vereinbarten Verfahren (hier: Triple DES) auf Basis einer Emulation mit dem geheimen Schlüssel entschlüsseln und zur untergeordneten AES-Entschlüsselung übergeben.

HSM bedeutet: Hardware-Sicherheits-Modul.

FLAM® unterstützt ferner hybrid kompatibel den AES-Prozessor der IBM (CPACF) auf Mainframe. FLAM® V4.3 für z/OS erkennt automatisch, ob dieser Prozessor verfügbar ist und aktiviert wurde, um durch dessen Nutzung als Alternative ganz wesentlich CPU-Zeit zu sparen. Das ändert nichts daran, dass die Kombination mit FLAM® aus ADC-Komprimierung (Advanced Data Compression) und AES-Verschlüsselung (Advanced Encryption Standard) zu einer erheblichen Optimierung der Abläufe und des Verbrauchs an CPU-Zeit führt.

CPACF bedeutet: Central Processor Assist for Cryptographic Function.

Ohne Komprimierung nur auf CPACF u.a. Hardware zu setzen, ist unwirtschaftlich. FLAM® komprimiert effizient die autarken Segmente und setzt dann erst mit dem Segment-Komprimat auf CPACF (falls verfügbar) auf resp. benutzt FLAM® die eigenen weit möglichst optimierten AES-Module. Das verschlüsselte Segment-Komprimat ist eine in sich geschlossene, autarke, adressierbare Einheit.

Wer mit FLAM® & AES verschlüsselt, ist von der Konstellation eines Partners völlig unabhängig, wenn dieser ebenfalls FLAM® einsetzt: Homogene, heterogene resp. hybride Kompatibilität.

Man kann also sogar HSM und CPACF in einem Prozess zusammen nutzen: HSM (als Black Box) in Verbindung mit einem beliebigen Verschlüsselungsverfahren (wie z.B. Triple DES) und CPACF für die hybrid kompatible AES-Verschlüsselung der komprimierten Nettodaten eines Segments und die MAC-Bildung. Eine Kopplung mit anderen Hard-/Firmware-Modulen wie auch Emulationen ist ebenfalls unproblematisch.

FLAM® kann nahezu jedes (heterogene) Kompatibilitätsproblem lösen – selbst bei Wechsel des/der Verschlüsselungsverfahren und/oder des Key Managements (SKI/PKI <=> SKI/PKI) – wie das Beispiel mit dem HSM zeigt (oben), an dem hybride Komponenten, unterschiedliche Verschlüsselungsverfahren (z.B. Triple DES, AES) und Zufallsschlüssel in Kombination mit PKI-/SKI-Schlüsseln beteiligt sind.

Wer FLAM® über den Key Management Exit (FKME) mit dem ICSF (Integrated Cryptographic Service Facility) der IBM flexibel koppeln will, benutzt dazu die Spezifikation unter Downloads und/oder bestellt das FL-ICSF (eine realisierte Lösung dieser Spezifikation).

Hat man einen Anwenderkreis, der noch Triple DES als Standard verwendet und wird in einem anderen bereits AES als Standard benutzt, dann kann man mit FLAM® die beiden Anwenderkreise kompatibel miteinander verknüpfen.

Mit all diesen Möglichkeiten kann ein FLAM®-Anwender die Vorgaben des PCI DSS (Payment Card Industry Data Security Standard) u.a. Standards erfüllen, weil man mit FLAM® offline arbeiten kann. Die Ent-/Verschlüsselung kann dort erfolgen, wo die Daten ohnehin klar für Anwendungen bereit stehen müssen. Das kann wieder eine ganz andere System-Plattform sein als die des Servers.

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®):

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.

FLAMFILE®s, die trotz Komprimierung sehr groß sind, kann man beim Komprimieren auch sequentiell splitten und z.B. in Teilen versenden.

FLAM®-bieren heißt: Diese Möglichkeiten heute und zukünftig zu nutzen.

limes®: leistung im grenzbereich des machbaren.
limes®: efficiency at the limit of possibility.

© 1985 - 2011 limes datentechnik® gmbh

Seitenanfang

Alle Rechte vorbehalten

Seite drucken