Komprimierung à la carte: CX7, CX8, VR8, ADC, NDC

Die Basis war ein Projekt für ein Backup-Rechenzentrum einer deutschen Großbank in Frankfurt/M. Es ging um die diversen Risiken der aus besatzungsrechtlichen Gründen juristisch eigenständigen Niederlassung nebst deren Filialen in West-Berlin. Man erinnere sich an die Berlin-Blockade von Juni 1948 bis Mai 1949, die nur durch das Engagement der westlichen Alliierten (Luftbrücke) nicht zu einem Zusammenbruch führte. Das Besatzungsstatut für Berlin galt bis zum 4+2-Vertrag (1990). Obwohl es die Rechte der Sieger (Besatzer) dokumentierte, diente es de facto dem Schutz von West-Berlin.

1985 hätte das Volumen an täglich zu übertragenden Daten mit den damals verfügbaren Mitteln die 24 Stunden, die ein Tag hat, locker überschritten. So entstand die Idee, solche Daten vor der Übertragung zu komprimieren und nach dem Empfang - jeweils entkoppelt, d.h. zeitlich unabhängig von der Übertragung - wieder zu dekomprimieren resp. solche Module entsprechend in das softwaretechnische Umfeld zu integrieren. Das alles unter Berücksichtigung der Verfügbarkeit von Ressourcen: wenig CPU-Zeit, wenig Arbeitsspeicher, zügige Abläufe im Batch-Betrieb. Damals waren diese Ressourcen äußerst knapp und sehr teuer.

Daten im Zahlungsverkehr waren damals stark strukturiert (DTA). Die Redundanz, die man findet, wenn man diese Daten nach Feldern und innerhalb der Felder nach Position eines Bytes betrachtet, ergab, dass es äußerst effizient ist, die Daten "vertikal" zu komprimieren. Man bildet eine Matrix, in die max. 255 solcher Sätze (Buchungen) eingelesen, am Satzende komprimiert und nach Satzlänge (virtuell) sortiert werden. Dann liest man diese Daten spaltenweise (an der Diagonale "gespiegelt") und dabei werden sie "horizontal" komprimiert. Dazu wurden einfachste damals bekannte Verfahren wie "run length" (Zusammenfassung gleicher Zeichen) benutzt.

Das Ergebnis war gerade in Bezug auf die Daten, die im Vordergrund standen, in Verbindung mit einem höchst effizienten Verbrauch an Ressourcen sensationell. Folgerichtig kam man zu Einsparungen von Plattenspeicher, die manchen Hersteller resp. Distributor solcher Geräte an den Rand der Verzweiflung bringen sollten. (Bei der BTX-Gebührenverwaltung konnten z.B. später über 90% dieser Speicher abgebaut und intern anderweitig verwendet werden, was Stornierungen in Millionenhöhe zur Folge hatte.) Ganz nebenbei wurde bereits im Test die "Elapsed Time" der betroffenen Prozesse stark reduziert.

So kam es zu der Idee, darauf basierend ein Utility zu entwickeln. Dazu brauchte man eine Firma. Das Utility bekam den Namen "FLAM®" und die Firma "limes datentechnik® gmbh".

Grundbegriffe zu den essentiellen Punkten rings um die FLAM®-Entwicklung finden Sie hier. Die meisten FLAM®-Versionen bieten ein aussagefähiges Protokoll.

Schon damals gab es die "leere" Datei - ohne Sätze (z.B. ohne Buchungen) darin. Und selbst die konnte man mit FLAM® "komprimieren", um beim Dekomprimieren eben wieder eine "leere" Datei zu erzeugen. Das hat den Vorteil, dass ein Partner regelmäßig seine FLAMFILE® bekommt, auch wenn es "nichts" zu übertragen gibt, so dass keine Lücke im Prozessablauf entsteht, weil zufällig etwas fehlt.

Und selbst Komprimate kann FLAM® wirtschaftlich sinnvoll verarbeiten, und zwar durch MODE=NDC (No Data Compression). FLAM® bricht sogar die Komprimierung bei MODE=ADC® (siehe unten) ab, wenn kaum ein Erfolg eintritt. In diesen Fällen werden die Daten nur segmentiert und in autarke Segmente (Puffer) kopiert.

Der Name unseres Produkts FLAM® steht für: Frankenstein-Limes-Access-Method. Daraus entwickelte sich der Begriff "FLAM®-bieren". Und das Ergebnis davon ist die FLAMFILE®. Über Schnittstellen kann der Anwender eigene Dateiformate erzeugen resp. seine eigenen Zugriffstechniken unterstützen. Man ist multiflexibel, wenn man die FLAMFILE® auf dem gleichen oder einem anderen System "de-FLAM®-bieren" will. Was wir inzwischen unter FLAM®-bieren verstehen, geht weit über bloßes Komprimieren hinaus.

Anmerkung: Ein Vorfahre eines Gesellschafters hieß H. Frankenstein.

1999 wurde der ADC (Advanced Data Compression) entwickelt, um auch Daten mit weniger auffallenden Strukturen sehr effizient und dennoch strukturorientiert komprimieren zu können. In Verbindung damit wird ein verschleiertes Komprimat erzeugt, das den Charakter eines Unikats hat. Im Wiederholungsfall entsteht "optisch" eine völlig anders codierte, gleich große FLAMFILE®.

Ferner wurde ein Algorithmus zur Verschlüsselung der mit MODE=ADC® komprimierten Daten entwickelt und in FLAM® V3.0 integriert. Der Algorithmus macht aus den max. 64 Bytes (512 Bits) ein Vielfaches an Schlüsseldaten, und zwar entstehen durch Expansion im Passphrasing 4 KB, die dann wie über einen Index verwendet und wie üblich permanent mit den Daten, die zur Verschlüsselung benutzt wurden, modifiziert werden. In der Parameterleiste steht statt "Key" o.ä. bescheiden "Password". Eigentlich handelt es sich um einen Schlüssel zur Verschlüsselung.

Limes bezeichnet in der Mathematik den Grenzwert einer Folge bzw. die Summe einer unendlichen Reihe, einer Funktion usw. Mit diesem Hintergrund, der Endlichkeit von etwas, das unendlich erscheint, kam es zu unserem Firmennamen.

Unser Slogan lautet: ** limes®: leistung im grenzbereich des machbaren! **

Man hätte als Slogan: ** limes®: leistung am limit! ** wählen können, aber dieser Slogan beschränkt das, was wir alles noch für "möglich" und somit für "machbar" halten, weil neue Entwicklungen nicht immer vorhersehbar sind.

Der römische Limes befindet sich in der Nähe unseres Firmensitzes. Der Limes ist Weltkulturerbe der UNESCO. Mitte des 19. Jahrhunderts wurden Reste eines römischen Kastells aus dem 1. Jahrhundert ausgegraben. Man restaurierte das Kastell mit "Fördermitteln" aus Preußen und gab ihm den Namen "Saalburg". Wilhelm II. war selbst zur Eröffnung Gastgeber und auch die italienische Königin nahm daran teil.

Wir sind Mitglied im Förderverein Saalburg e.V.:

Hier der Link zum Saalburgmuseum.

An der Principia (große Halle), in der der Lions Club Friedrichsdorf/Limes mit dem Jugend-Symphonie-Orchester Hessen jeden Sommer Konzerte veranstaltet, findet man eine Tafel zu Ehren der 3 Spender, die die Kosten für 3 gewaltig hohe und breite Türen gestiftet haben, damit die Halle bei solchen Veranstaltungen geschlossen werden kann. Darunter findet man unser Firmen-Logo.

Unser Produkt FLAM® hat ein Basiskonzept, das einmalig ist und damit außergewöhnliche technische sowie wirtschaftliche Vorteile bietet, die tief und sehr effizient in die Lösung von Sicherheits-Problemen eingreifen können. Die Verschlüsselung basiert seit FLAM® V4.0 auf dem AES (Advanced Encryption Standard), dem von den USA nach 2001 ausgehenden Welt-Standard. Unser Produkt FLAM® soll damit Daten und Anwendungen auf intelligente, wirtschaftlich vorteilhafte Weise schützen.

Eine Besonderheit von FLAM® ist eine "Access-Method", die es erlaubt, mit komprimierten resp. verschlüsselten Daten so umzugehen, dass nur soviel entschlüsselt resp. dekomprimiert werden muss wie unbedingt nötig, ohne dass die Sicherheit irgendwie gefährdet ist, insbesondere kann man index-sequentiell arbeiten. Selbst in rein sequentiell aufgebauten, FLAM®-bierten Daten kann man extrem effizient suchen und selektieren, weil FLAM® mit autarken Matrizen/Segmenten arbeitet. Und das alles abwärts-, seitwärts- wie auch homogen, heterogen und hybrid kompatibel.

Schon mit dem logischen Basiskonzept für den heterogen kompatiblen Datenaustausch zwischen beliebigen System-Plattformen in Verbindung mit jeder Übertragungstechnik, insbesondere mit jedem File-Transfer-Produkt, wurden Anforderungen erfüllt, an die zum Teil die betroffenen Projekte selbst noch nicht gedacht hatten. So entstand der Wunsch nach einer einheitlichen Lösung, die nur bzgl. FLAM® ein Standard ist. Sonst bleibt jeder Teilnehmer von anderen Teilnehmern (Partnern) und deren Entscheidungen am eigenen Standort weitgehend unabhängig.

Das ermöglichte, insbesondere im Umfeld von Finanzinstituten/-dienstleistern, rascher und sehr effizient in den Datenaustausch mit beliebigen Partnern einzusteigen. Dazu kamen später die Anbieter aus dem Bereich Telekommunikation, die ein aufwendiges Clearing für Messdaten und Gebührenabrechnungen betreiben und die große Teile dieser Daten - trotz Flat Rate - über längere Zeit im Zugriff halten müssen (z.B. wg. der Anti-Terror-Fahndung).

Letzteres gilt erst recht für Daten aus dem Bank- und Börsenwesen (10 Jahre). Dabei stellt sich die Frage, was man nach wieviel Jahren noch lesen kann, weil sich - unabhängig von der Physik der Datenträger - die Geräte-/Aufzeichnungstechniken rasant entwickeln. - In den USA ist die Dauer der Aufbewahrung z.B. 30 Jahre (diese Frist gilt auch für Exporteure aus Europa)! Da muss man gründlich überlegen, wie und womit man sicher archiviert, damit alles als Beweismittel verfügbar bleibt und Unbefugte keinen Zugang haben.

Teilt man eine FLAMFILE® in 3 Drittel (es wird in Einheiten von 1 Wort = 4 Bytes wraparound geschrieben), dann kann man jeweils 2 Drittel an 1 von 3 Standorten auslagern. Damit kann man an keinem Standort die Daten lesbar machen und hat bei Ausfall der Daten an 1 Standort volles Backup durch die Kopien an den anderen beiden Standorten. Man muss sich keinen Key merken. Der Key ist das gesamte fehlende Drittel. Man braucht kein Key Management System!

Man kann das auch ein Bermuda Concept® nennen, nur dass hier "nichts im Nichts" verschwindet, selbst wenn partiell, d.h. an 1 Standort ein Total-Verlust eintritt.

Mit FLAM® sind alle denkbaren Offline-Varianten - mit/ohne Telekommunikation - machbar, z.B. das Brennen solcher Daten auf CD/DVD resp. Speichern auf externen Datenträgern zwecks Versand (ggf. Backup) oder Lagerung. Komprimiert und verschlüsselt kann man sogar sehr große Datenmengen auf USB-Stick in der Hand-/Hosentasche mitnehmen. Selbst Mobiltelefone bieten immer mehr Komfort, für den eine Kombination aus Komprimierung und Verschlüsselung sinnvoll ist.

Beispiel: Man nimmt einen USB-Stick mit einem Speichervermögen von 8 GB. Nun nimmt man eine Datei von 80 GB und komprimiert sie um 90%, wie das mit FLAM® bei den neuen Daten aus dem europäischen Zahlungsverkehr (SEPA) Standard ist (meist liegt der K-Effekt >95%). Dann bleiben als Komprimat gerade soviel Daten, wie der USB-Stick aufnehmen kann. Und den kann man in der Hosentasche mitnehmen. Das gilt auch für den Fall, dass jemand unerlaubt Daten auf einem so unscheinbaren Datenträger transportiert, wenn er auf die Originale Zugriff hat und nicht genug für die Sicherheit getan wird.

Schließlich kann man die verschlüsselte FLAMFILE® hexadezimal wie einen Dump virtuell drucken und diesen Output auf Microfiches abbilden. Das spart extrem viel an Material und ist besonders sicher. Man braucht nur ein Lesegerät mit FLAM®, z.B. einen PC, um die Daten wieder so lesbar zu machen, wie sie ursprünglich ausgedruckt werden sollten. Das kann man so optimieren, dass nur ein Minimum selektiert, d.h. entschlüsselt und dekomprimiert werden muss. Für diese Techniken sind selbst 100 Jahre ein "kurzer" Zeitraum, wenn man sich die Fotos von Besuchen Wilhelm II. auf der Saalburg anschaut. - Bei CD/DVD weiß man noch nicht, wie es in 100 Jahren aussieht. Selbst 30 Jahre (USA) sind ein riskantes Zeit-Intervall. Alles was auf die Lochkarte folgte, ist längst wieder "tot" - nur der Microfiche nicht.

Unabhängig davon, ob man die Daten auf Datenträgern, die alt sind oder nicht mehr unterstützt werden, noch lesen könnte: Es fehlen ganz einfach die technischen Voraussetzungen dafür. Die betreffenden Lesegeräte werden nicht mehr hergestellt resp. gewartet. Schon deshalb kann man diese Daten(träger) nicht mehr lesen.

Mit der Offline-Variante erfüllt FLAM® die Anforderungen an PCI DSS, z.B. bei der Abwicklung von Aufträgen zur Herstellung von Cards (Mastercard, Visa Card, ...). So könnte man auch die Auftragsabwicklung für die Gesundheitskarte durchführen. Man soll nicht "am Netz" ver- resp. entschlüsseln, sondern dort, wo die Daten ohnehin an die Applikationen angebunden sind, die "klare" Daten verlangen müssen und die Daten sollten in bestimmten Anwendungen nur virtuell im Arbeitsspeicher klar lesbar sein.

Heute gibt es das Problem des Einsatzes verschiedenster Krypto-Verfahren in Verbindung mit Key Management Systemen, die immer nur in einem begrenzten Umfeld (kompatibel) benutzbar sind sowie die hybrid kompatible Anbindung an Hard-, Firm- und Software zur Ver- resp. Entschlüsselung in den dafür vorgesehenen User-Netzen, die übergreifend meist inkompatibel sind.

FLAM® kann alle diese Probleme harmonisieren resp. homogenisieren, und zwar auf der Basis einer intern in sich abgeschlossenen AES Verschlüsselung sowie der Bildung von MACs und Signaturen ebenfalls auf Basis der AES Algorithmik. Das alles kann, um CPU-Zeit zu sparen, mit CPACF, einem speziell entwickelten AES-Prozessor, kombiniert werden und dabei im Einzelfall hybrid kompatibel ablaufen. Dabei lässt sich FLAM® mittels FKME mit jedem Key Management System koppeln resp. kann ein eigenes, von uns zusammen mit IBM-Beratern entwickeltes Key Management System mittels FKMS integriert werden. Selbst Verschlüsselungsverfahren der Partner müssen nicht kompatibel sein. Der End-User braucht nur einen einzigen zentralen Ansprechpartner - eine Art "Knoten" - und nur mit ihm muss er die offline komprimierten/verschlüsselten Daten austauschen. Dieser Partner sorgt wie in einem Mobilfunk-Netz für die Kopplung mit dem gewünschten Empfänger (vgl. Beispiel eNotar®). Die Flexibilität ist wesentlich größer, eben weil nicht online gearbeitet werden muss.

Mit FLAM® können End-User (auch offline) inter-/national im Datenaustausch sicher übergreifend miteinander kommunizieren, die sonst keinerlei Gemeinsamkeit haben - außer FLAM® selbst. Und dabei kann jeder FLAM®-Anwender ganz unabhängig davon - sozusagen en passant - für sich selbst deutliche betriebswirtschaftliche Vorteile aus dem Einsatz von FLAM® ziehen sowie kreativ und innovativ an die Lösung von Problemen herangehen, über die noch zu wenig nachgedacht worden ist.

Für die FLAM®-Community gilt:

Wir verstehen uns, weil FLAM® ein harmonisches, homogenes Umfeld schafft, das

Dass FLAM® effizient Daten komprimiert, spielt oft nur noch eine untergeordnete Rolle.

Wir FLAM®-bieren Daten und das geht weit darüber hinaus.

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

© 1985 - 2011 limes datentechnik® gmbh

Seitenanfang

Alle Rechte vorbehalten

Seite drucken