Datenverschlüsselung nach Standards

FLAM® kann ab Version V3.0 Daten verschlüsseln; ab Version V4.0 mit dem Welt-Standard AES (Advanced Data Encryption) und (auf IBM Mainframe) seit Version V4.3 - hybrid kompatibel - mit dem AES Prozessor CPACF.

CPACF bedeutet: Central Processor Assist for Cryptographic Function.

FLAM® bildet ab Version V3.0 mit MODE=ADC® (Advanced Data Compression) autarke Segmente von max. 64 KB (netto) und komprimiert diese mit einem komplexen Algorithmus, der darauf ausgerichtet ist, besonders performant und mit wenig Arbeitsspeicher effizient zu arbeiten.

Der Anwender kann alternativ MODE=NDC (No Data Compression) benutzen, wenn er gute Gründe hat, den Input nur zu segmentieren und diese autarken Daten-Segmente nicht zu komprimieren. Die Netto-Daten werden dann nur in den Segment-Puffer kopiert.

Gute Gründe sind:

*) Die Segmentierung der bereits komprimierten und/oder verschlüsselten Daten führt zu einer neuen Segmentierung, die nicht mehr synchron zu der der Ausgangsdaten ist. Außerdem würden alle Informationen, die FLAM® in Headern der FLAMFILE® unterbringt (File, Member, Segmente) und die man zur Erstellung der ursprünglichen Datei (Original) benötigt inkl. der Checksummen für die Komprimate etc., verschlüsselt werden. Selbst das kann gewollt sein. Es gäbe keine Information mehr, die einen Bezug zu den Originaldaten zuläßt.

FLAM® kann seit Version V3.0 verschlüsseln, aber nur, wenn man zur Komprimierung als Parameter MODE=ADC® oder MODE=NDC benutzt. Trotz Verschlüsselung kann man ein solches Segment direkt adressieren, entschlüsseln und dekomprimieren. Das war eine der Zielsetzungen.

In FLAM® V3.0 wird der Parameter dazu PASSWORD genannt, weil das Verfahren kein internationales Standardverfahren ist, sondern von uns selbst entwickelt wurde. Es geht also hier nicht um den klassischen Zugriffsschutz mittels Password, sondern um eine Verschlüsselung.

Es wird mit SKI, d.h. einem symmetrischen Schlüssel (dieses Password), der variabel bis zu 64 Bytes (512 Bits) lang sein darf, gearbeitet. Der Anwender, der die FLAMFILE® entschlüsseln will, muss genau diesen Schlüssel (per Password-Parameter) in der richtigen Länge übergeben.

Anmerkung: Ab FLAM® V4.1 ist mit FKME (FLAM® Key Management Exit) auch für dieses Verschlüsselungsverfahren eine Kopplung zu jedem Key Management (SKI/PKI) sowie zu externen Verschlüsselungsverfahren möglich (Aktuell).

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. Es ist durchaus interessant, nicht unbedingt das Maximum zu wählen, denn die Länge ist ein Teil des geheimen Schlüssels.

Ein abdruckbarer Schlüssel wird so, wie er beim Verschlüsseln vorgegeben wurde, eingegeben. Die evtl. erforderliche Byte-Konvertierung übernimmt FLAM® (intern). Ein abdruckbarer Schlüssel hat natürlich nicht mehr annähernd 2**512 Varianten als Basis. Vielleicht sind es noch 2**384 Varianten. Dennoch eine Zahl, die alles gigantisch übersteigt, was selbst in der Astrophysik als "astronomisch" gilt.

Ein Schlüssel, der mit "E" beginnt, soll in EBCDIC interpretiert werden, bei "A" in ASCII. Die hexadezimale Darstellung beginnt mit "X". Sie entspricht quasi einer binären Vorgabe, weil jede (Halb-)Byte-Folge zulässig ist. Die Anzahl der Halb-Bytes muss gerade sein (max. 2 x 64 = 128). E, A oder X steht vor dem Schlüssel, ist aber selbst nicht Teil der max. 64 Bytes des Schlüssels. Man kann auch X angeben, wenn der Schlüssel an sich abdruckbar ist. Dann ist dieser Schlüssel nicht konvertierbar.

Der Algorithmus aus V3.0 macht aus den max. 64 Bytes (512 Bits) ein Vielfaches an Schlüsseldaten, und zwar entstehen durch Expansion in einem komplexeren Passphrasing 4 KB, die dann wie über ein Index-Verfahren verwendet und permanent mit Daten, die zur Verschlüsselung benutzt wurden, ebenfalls indiziert modifiziert werden. Dadurch ändern sich die 4 KB permanent, aber eben immer nur partiell.

Zu Beginn der Verschlüsselung eines Segment-Komprimats wird zusätzlich eine Initialisierung vorgenommen, so dass jedes Segment-Komprimat mit einem Derivat dieser 4 KB verschlüsselt wird.

Es gibt keine Möglichkeit, eine "Brute Force Attack" zu beschleunigen. Man muss bis zum Ende der Dekomprimierung eines Segments kommen, um dann erkennen zu können, ob korrekt entschlüsselt und dekomprimiert wurde. Das ist ein sehr langer Prozess, um nur einen einzigen Schlüssel auszutesten. Dann muss man den ganzen Prozess neu starten (initialisieren etc.).

Diese Lösung ist ggf. auch weiterhin ausreichend, z.B. beim parallelen Splitting (Bermuda Concept®), weil weniger CPU-Zeit als mit AES verbraucht wird, falls ein Anwender überhaupt dieses Splitting mit einer Verschlüsselung kombinieren will.

Unabhängig davon werden die ADC-Komprimate verschleiert, so dass jedes Komprimat ein Unikat darstellt, das im Wiederholungsfall anders "aussieht". Das gilt insbesondere auch, wenn mit MODE=NDC (No Data Compression) die ADC-Komprimierung umgangen und der Input nur segmentiert, dabei kopiert und dann mit dem Password-Key verschlüsselt wird.

Arbeitet FLAM® mit einem Zufallsschlüssel, ist auch das verschlüsselte Segment-Komprimat ein Unikat, weil bei jedem Aufruf von FLAM® ein neuer Zufallsschlüssel generiert oder angefordert wird.

Anmerkung: Der Zufallsschlüssel wird mit dem vereinbarten Key (SKI/PKI) verschlüsselt, im FLAMFILE®-Header abgelegt und dieser Header wird signiert. Zur Verschlüsselung des Zufallsschlüssels sowie zur Signierung können Verfahren verwendet werden, die außerhalb FLAM® liegen und für die man Exits wie FKME benutzt. Das können Hardware-Einheiten, Emulationen solcher Einheiten oder Software-Module sein. Jeder Standard und jede Individualisierung sowie jede Kombination daraus ist lösbar. Eine Anwendergruppe kann sich ihre - nach außen - nicht kompatible Kombination zusammenstellen. Um dann eine FLAMFILE® zu entschlüsseln, genügt es nicht, einen Schlüssel oder Teile der Kombination zu kennen. Man muss in die Lösung dieser Anwendergruppe voll integriert worden sein.

FLAM® ist die perfekte Basis für solche kreativen, innovativen Lösungen.

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. Auch hierfür dürfen nur die Parameter MODE=ADC® oder MODE=NDC benutzt werden.

Die Regeln für Schlüssel stimmen mit denen zu Version V3.x überein (siehe oben).

Das 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 umgehen. Es ist nicht möglich, Schlüssel "seitwärts" einzuschleusen, um z.B. mit schmaleren Schlüsseln zu "experimentieren". 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-Komprimat muss eine Mindestmenge haben; ist das Segment-Komprimat kleiner, wird aufgefüllt und erst dann verschlüsselt.

An den entscheidenden Stellen wird in Einheiten von 16 Bytes mit einer Schlüssellänge von 128 Bits (16 Bytes) gearbeitet (AES-128). Man darf folglich nur das als Kriterium für die Beurteilung benutzen - nicht die Schlüsselbreite von außen. Dennoch kann derjenge, der experimentell einen Schlüssel herausfinden möchte, sich eben nicht auf 16 Bytes beschränken. Und 2**128 ist ja schon "viel" - genauer: eine Zahl von mehr als astronomischer Größe.

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.).

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 sehr vielmehr 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.

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.

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 und Zufallsschlüssel 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).

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.

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

© 1985 - 2011 limes datentechnik® gmbh

Seitenanfang

Alle Rechte vorbehalten

Seite drucken