CH712679B1 - Verfahren zur Maskierung und eindeutigen Signierung von Datenbank-Quellcodes. - Google Patents

Abstract

Vorgeschlagen wird ein Verfahren zur Maskierung und eindeutigen Signierung von Datenbank-Quellcode, wobei ein Datenbank-Quellkode SQL-Code und PL-SQL-Code als Host-Sprache umfasst. Die SQL-Kommandos werden an entsprechenden Stellen in den Quellcode eingebunden entweder durch Prozeduraufrufe oder als Klartext-Befehle, die von einem Precompiler in Prozeduraufrufe der Host-Sprache übersetzt werden. Mittels eines Ladeprozesses liest ein Maskierungs- und Kennzeichnungsengine Klartext-Schlüsselworte aus dem Source-Code aus und erzeugt dynamisch, in Realtime ein verschlüsseltes Keyword nach den PL/SQL-Regeln. Mittels des Maskierungs- und Kennzeichnungsengine wird das Klartext-Schlüsselwort mit dem encrypted Schlüsselwort substituiert und der gesamte, maskierte PL/SQL-Source Code stückweise in eine relationale Tabelle abgespeichert, wobei die encrypted Schlüsselwort von der Oracle PL/SQL Engine korrekt interpretierbar sind.

Description

Technisches Gebiet

[0001] Die vorliegende Anmeldung betrifft elektronische Engines zum automatisierten Maskieren und eindeutig Signieren von Datenbankinhalten und Datenbank-Quellcode, insbesondere ein System und Verfahren zur Wahrung der Vertraulichkeit von Informationen in Datenbanken, im Speziellen SQL (Structured Query Language) und PL/SQL (Procedural Language/Structured Query Language) Datenbanken, sowie von Quellkode und Primärkode der entsprechenden Datenbanken.

Stand der Technik

[0002] Viele Datenbankhersteller, wie z.B. Oracle mit Hauptsitz im kalifornischen Redwood City mit ihrem Datenbankprodukt Oracle Database, liefern sog. Wrapping-Utility. Die Wrapping Utilities werden normalerweise mit jedem Release entsprechend aktualisiert, wie unten genauer erklärt wird. Der Sinn dieser Utility ist, den PL/SQL Source-Code zu maskieren, um ihn für Dritte unleserlich zu gestalten. Im Folgenden wird der Stand der Technik und die Erfindung anhand der Oracle Database erklärt, kann aber auch auf andere Datenbanken übertragen werden.

[0003] Typischerweise besteht eine Datenbank-Anwendung nie ausschliesslich aus SQL-Skripten (SQL: Structured Query Language), sondern ist in einer so genannten Host-Sprache geschrieben, wie C++, Delphi, Java etc. SQL-Kommandos werden an der entsprechenden Stelle in den Quellcode eingebunden, entweder durch Prozeduraufrufe oder als Klartext-Befehle, die von einem Precompiler in Prozeduraufrufe der Host-Sprache übersetzt werden. PL-SQL (Procedural Language/Structured Query Language) ist eine derartige Host-Sprache. Wichtig ist jeweils das Zusammenspiel der verschiedenen Engines, d.h. im vorliegenden Beispiel von SQL und PL/SQL, auf Codierungsebene. So sollten die Grenzen zwischen SQL-Engine und PL-SQL-Engine möglichst eng verwoben sein, dass insbesondere ein möglichst kleiner Unterschied zwischen den Datentypen und eingebauten Funktionen beider Umgebungen besteht. Dies gilt auch für jede andere Host-Sprache, die ebenfalls entsprechend konvertiert wird. Jede Ausführung eines SQL-Kommandos in einer PL/SQL-Prozedur führt deshalb zu einem Kontext-Switch. Charakteristisch für PL/SQL ist, dass es sehr datenbanknah ist, über keine graphische Ausgabe und nur begrenzt über Textausgabemöglichkeiten verfügt. In der Praxis führt diese häufig zu einer Aufgabenteilung. So wird eine andere Sprache als PL/SQL als Host-Sprache verwendet, aus welcher SQL-Kommandos ausgeführt und/oder PL/SQL-Konstrukte aufgerufen werden. Auf diese Weise wird die eigentliche Datenbanklogik und -technik in PL/SQL formuliert, während der Rest des Quellcodes in einer Drittsprache vorliegt. Für PL/SQL gilt, dass es normalerweise eine interpretierte Sprache ist, d.h. der Quellcode wird nicht in Maschinen-Code übersetzt, sondern in einen Zwischenlayer, dem so genannten M-Code, welcher erst zur Laufzeit vom PL-SQL-Engine interpretiert und ausgeführt wird. Dadurch wird eine Platformunabhängigkeit des Objektcodes erreicht, der allerdings einen bestimmten Performance-Nachteil zu komplett kompilierten Sprachen zeigt. PL/SQL und SQL sind weitgehend aufeinander abgestimmt. So entsprechen die Datentypen von PL/SQL weitgehend den SQL-Datentypen. Es bestehen jedoch auch Abweichungen. Remote-Aufrufe von PL-SQL-Routinen sind möglich, soweit ein Datenbanklink zur betreffenden Datenbank möglich ist. Die Ausführung geschieht auf der Remote-Datenbank. Einige der mitgelieferten PL-SQL-Packages sind unter Sicherheitsaspekten kritisch, da sie in einer Standarddatenbank von jedem Benutzer ausgeführt werden können. Der Zugriff kann jedoch auch verhindert werden, da Ausführungsrechte gezielt an einzelne Benutzer vergeben werden können. Alle PL-SQL-Objekte können über eine View dba_object abgefragt werden. Der Quelltext ist über dba_source verfügbar, und die Parameterlisten über all_arguments. Wie bei den Views gilt auch für die Erstellung von PL/SQL-Objekte und Trigger, dass die notwendigen Rechte als direkte Rechte vorhanden sein müssen, da die indirekte Erlaubnis über eine Rolle nicht genügt. Für jedes PL/SQL-Objekt können im M-Code zusätzliche Informationen zu Debugging-Zwecken abgelegt werden. Für das Debugging sind ebenfalls Ausführungsrechte auf dem Package dbms_debug notwendig.

[0004] Wie erwähnt kann der Quellcode eines PL-SQL-Objekts mittels Wrapping geschützt werden, indem man das Objekt verhüllt, d.h. wrappt. Dies bedeutet, dass der eigentliche Quellcode durch den genannten M-Code ersetzt wird. Auf diese Weise kann eine Anwendung an Dritte geliefert werden, ohne dass Einblick in den Quellcode gewährt werden muss. Auch über das obgenannte View dba_source ist der Quellcode dann nicht mehr einsehbar. Es ist nicht möglich, ein PL-SQL-Objekt in eine Datenbank einzuspielen und nachträglich ein Wrapping durchzuführen. Stattdessen findet das Wrapping der Objektdefinition innerhalb eines Skripts statt, das anschliessend eingespielt wird.

[0005] Bei Wrapping werden aus dem Originalskript create_procs.sql ein neues Skript erzeugt. Sämtliche create-Kommandos für Funktionen, Prozeduren, Packages, Package Bodies, Typen und Typ-Bodies werden in den M-Code übersetzt, während alle anderen Kommandos unverändert bleiben. Lediglich das Skript create_procs_wrapped.sql wird anschliessend eingespielt. Da eine Wiederherstellung des Quellcodes aus dem M-Code nicht möglich ist, muss für ein Update stets das Originalskript gepflegt und anschliessend für die Auslieferung erneut verhüllt werden. Folgende Punkte sind entscheidend in Zusammenhang mit Wrapping: (i) In den PL/SQL-Code eingebettete SQL-Kommandos können trotz Wrapping durch SQL-Trace der Anwendung oder durch Inspektion der View v$sql sichtbar gemacht werden; (ii) Das Exportieren und Importieren von verhüllten PL/SQL-Objekten mittels Data Pump oder konventionellem Export/Import ist möglich. Die Objekte bleiben dabei verhüllt; (iii) Der Quellcode von Triggern kann nicht verhüllt werden. Stattdessen muss eine eigene Prozedur für den Trigger-Quellcode geschrieben und das Wrapping danach durchgeführt werden. Der Trigger ruft anschliessend diese Prozedur auf; (iii) Passwörter oder sonstige Werte, die als Konstante oder als Default-Werte für Variablen im Quellcode eingebaut sind, werden durch das Wrapping nicht verschlüsselt, sondern tauchen auch im verhüllten Code im Klartext auf. In solchen Fällen sollte das Passwort verschlüsselt in einer entsprechend geschützten Datenbanktabelle oder Betriebssystemdatei gespeichert werden. Über das Package dbms_obfuscation_toolkit oder dbms_crypto stehen verschiedene Ver- und Entschüsselungsalgorithmen zur Verfügung, u.a. DES, 3DES, AES, MDS und SHA-1 etc; (iv) Die Datenbank, in welche ein verhülltes Objekt eingespielt wird, muss von derselben oder einer neueren Version sein als die Datenbank, in der das Wrapping stattfand. Normalerweise ist das Einspielen in eine ältere Datenbankversion nicht möglich.

[0006] Für das Beispiel der Oracle Database und PL-SQL-Objekte gilt, dass Oracle mit jedem Release ein entsprechendes Wrapping-Utility liefert, das erlaubt den PL/SQL Source-Code zu maskieren, um ihn für Dritte unleserlich zu gestalten. Die jeweiligen Oracle-Release PL/SQL-Engines sind dann in der Lage, den maskierten PL/SQL Source Code zu verarbeiten. Ein entscheidender Nachteil der Wrapping-Technologie ist jedoch, dass u.a. der Autor David Litchfield (siehe eu.wiley.com/WileyCDA/WileyTitle/productCd-0470080221.html) Utilities, wie die Utility unwrap.py realisiert und der Öffentlichkeit zur Verfügung gestellt hat (siehe blog.teusink.net/2010/04/unwrapping-oracle-plsql-with-unwrappy.html). Somit ist die Grundidee von Oracle, den PL/SQL Code für Dritte zu maskieren, vollständig in Frage gestellt. Hinzukommt, dass der Entschlüsselungs-Engine sehr einfach im Internet zu finden ist. Es genügt, in einer beliebigen Suchmaschine das Stichwort „unwrap it“ zu tippen, den maskierten Code in die dafür vorgesehene Form zu kopieren, um den Source-Code im Klartext zu erhalten (vgl. technology.amis.nl/2009/02/03/unwrapping-10g-wrapped-plsql/). Aus der ursprünglichen Idee von David Lichtfield sind weitere Entwicklungen entstanden, sodass sogar die IDE-Entwicklungsumgebung (Integrated Development Environment) PL-SQL-Developer selbst dazu missbraucht wird, um vollständige Sequenzen von PL/SQL-Source Code per Tastendruck wieder lesbar zu gestalten.

[0007] Dieser Tendenz hat ein anderer Entwickler Pete Finnigham (www.petefinnigan.com/weblog/archives/00001385.htm) mit einem entsprechenden Instrument entgegengewirkt, um PL/SQL Code dennoch maskieren zu können. Der technische Nachteil und die Schwierigkeit von diesem Tool liegen darin, dass der Prozess auf Datei-Ebene (Source-Code aus der Datenbank auf Dateien exportieren) und nur auf eine Datei, welche den PL/SQL Code speichert, wirkt. Zudem sind verschiedene Hilfsdateien notwendig, wie „omit-file“, um dem Obfuskation-Engine mitzuteilen, welche Schlüsselworte auf keinen Fall maskiert werden dürfen. Zusätzlich, muss der End-Benutzer ein „Reserved-Word-Flle“ von jedem Oracle-Release zum nächsten Oracle-Release nachführen, damit die Engine von Pete-Finnigham, die reservierten Oracle Schlüsselworte unangetastet lässt. Schliesslich muss der End-Benutzer zwei „encryption-keys“ ausdenken, womit der PL/SQL-Source Code verschlüsselt werden kann. Ein weiterer Nachteil liegt darin, dass mit einem einfachen Parser, welcher den Befehl „select <verkettete ASCII Zeichen> from dual;“ enthält, Sequenzen von verketteten ASCII-Zeichen als Klartext rekonstruiert werden können. Das Verfahren nach Pete Finnigham ist für kleine PL/SQL-Packages (drei bis fünf Pakete) noch überblickbar. Sobald PL/SQL Libraries zu maskieren sind, steigen Zeit und Aufwand enorm um die jeweiligen Omit-, und sonstigen, notwendigen Hilfsfiles zu erstellen und zu pflegen. Zudem steigt die Fehlerrate und Aufwand für Bug-Fix im verschlüsselten Code überproportional, beinahe exponentiell, mit der Grösse der Libraries an.

Technische Aufgabe

[0008] Es ist Aufgabe der Erfindung, eine technische Lösung bereit zu stellen, die die oben diskutierten Nachteile nicht aufweist. Insbesondere soll die Lösung es erlauben, PL/SQL Code trotz den vorhandenen un-wrapp-Möglichkeiten maskieren zu können. Zudem soll der technische Aufwand und die benötigte Zeit (notwendige Anzahl Omit-, und Hilfsfiles; notwendige Passwörter; notwendiges Release-bedingtes Nachführen der Dateien etc.) für den Wrapp-Engine um den PL/SQL-Source-Code bewusst zu maskieren entsprechend klein sein oder gänzlich wegfallen, ohne dass es Dritten einfach erlaubt wird, den Code zu unwrappen.

Zusammenfassung der Erfindung

[0009] Gemäss der vorliegenden Erfindung werden die obgenannten Aufgaben insbesondere durch die Anspruchsmerkmale der unabhängigen Ansprüche erreicht. Weitere vorteilhafte Ausführungsformen können durch die abhängigen Ansprüche und die Beschreibung erhalten werden.

[0010] Gemäss der vorliegenden Erfindung werden die obgenannten Aufgaben für einen elektronischen Maskierungs- und Kennzeichnungsengine zur Maskierung und eindeutiger Signierung von Datenbankinhalten und Datenbank-Quellcode insbesondere dadurch gelöst, dass ein Datenbank-Quellcode SQL-Code und PL-SQL-Code als Host-Sprache umfasst, wobei SQL-Kommandos an entsprechenden Stellen in den Quellcode eingebunden werden. Entweder durch Prozeduraufrufe oder als Klartext-Befehle, die von einem Precompiler in Prozeduraufrufe der Host-Sprache übersetzt werden, dass der Maskierungs- und Kennzeichnungsengine mittels eines Ladeprozesses Klartext-Schlüsselworte aus dem Source-Code ausliest und dynamisch, in Real-time ein verschlüsseltes Keyword nach den PL/SQL-Regeln erzeugt, und dass mittels des Maskierungs- und Kennzeichnungsengine das Klartext-Schlüsselwort mit dem encrypted Schlüsselwort substituiert wird und der gesamte, maskierte PL/SQL-Source Code stückweise in eine relationale Tabelle abgespeichert wird, wobei die encrypted Schlüsselwort von der Oracle PL/SQL Engine korrekt interpretierbar sind. Die Erfindung hat unter anderem den Vorteil, dass der Maskierungs- und Kennzeichnungsengine sich besonders eignet, die Stärken von Java, PL/SQL und der Oracle relationalen Datenbank zu vereinen, und gleichzeitig die jeweiligen Schwächen der einzelnen Technologien zu kompensieren. Mittels des Maskierungs- und Kennzeichnungsengine können z.B. automatisiert im Code Zeichenfolgen einfügt werden, wobei der Code mit eingefügten Zeichenfolgen von der Oracle PL/SQL Engine korrekt interpretiert wird. Der Zugriff auf das jeweilige Benutzer-Schema, welcher die gesamte elektronische Maskierungs- und Kennzeichnungsengine speichert, kann z.B. nur mittels vordefinierter, scharfer Rollen erfolgen, welche bestimmten, ausgewiesenen End-Anwender der Engine zugeordnet sind. Der Zugriff auf das jeweilige Benutzer-Schema, welcher die gesamte elektronische Maskierungs- und Kennzeichnungsengine speichert, kann z.B. mittels der vordefinierten, scharfen Rollen nach den Sicherheits-Regeln eines jeweiligen Datenbank-Providers erfolgen. Die Zugriffs-Sicherheit auf den elektronischen Maskierungs- und Kennzeichnungsengine kann z.B. erhöht werden, indem ein Mechanismus „transparent encrypted“ im jeweiligen Speichermedium abgelegt und mit dem maskierten, erstellten PL/SQL Source Code im ordentlichen Backup-Restore-Recovery Prozess eingebunden wird. Nach der Maskierung des Source-Codes mittels des Maskierungs- und Kennzeichnungsengine kann z.B. entweder ein einzelnes PL-SQL Paket, welches geeignet ist einzelne Patches innerhalb einer Library zu erstellen, oder eine gesamte Library als einziger Stream in eine versandbereit gezippte Datei exportieren. Für Benutzer des PL/SQL Codes mittels eines Historisierungs- und Versionierungsmechanismus kann z.B. jederzeit das Paar (Klartext-Schlüsselwort; encrypted-Schlüsselwort) rekonstruierbar sein, wobei für die Benutzer feststellbar ist, wann, für welchen End-Benutzer oder Kunden, in welchem PL/SQL-Paket jeweils die Substitution Klartext-Schlüsselwort“ mit „encrypred Schlüsselwort“ stattgefunden hat. In derselben Tabelle, in welcher jedes Paar (Klartext-Schlüsselwort; encrypted Schlüsselwort) gespeichert ist, kann z.B. jedes Paar mit einem Zeitstempel versehen sein. Der gesamte Maskierungs- und Kennzeichnungsengine kann z.B. in Java und/oder einer anderen, objektorientierten Programmiersprache realisiert sein, wobei der Engine als Byte-Code und als vollkommen intransparenter und irreversibler Code für Benutzer im PL/SQL-Code vollständig eingebettet und vom PL-SQL-Engine ausführbar ist. Die Tabelle, welche die zu maskierenden Schlüsselworte enthält, kann z.B. in analoger Weise mit Klartext-Passwörter befüllbar sein, wobei danach die verschlüsselten und dynamisch erstellten Passwörter von Machine-to-Machine sendbar sind, um auf lokale oder delokalisierten Maschinen und/oder Applikationen Passwörter automatisch und/oder nach einem Zeitplan und/oder nach dem Zufallsprinzip, zu ändern. Der Maskierungs- und Kennzeichnungsengine kann z.B. ein aus einem einzigen Zeichen bestehenden Klartext-Schlüsselwort und/oder Passwort ein verschlüsseltes Schlüsselwort oder Passwort von 29 Zeichen nach den PL-SQL Engine Regeln von der Oracle Database erzeugen, wobei die maximale Zeichenlänge von 29 Zeichen von der Oracle Database festgelegt und nicht überschreitbar ist, und wobei bei zusätzlichem Zufügen ein Zeichen zur verschlüsselten Zeichenkette der Oracle-PL/SQL Engine jede weitere Ausführung blockiert. Der Verschlüsselungs-Engine kann z.B. separat vom Maskierungs- und Kennzeichnungsengine realisiert sein und mit dem gleichen Mechanismus in ein PL/SQL-Code eingebettet und bedienbar sein. Schliesslich ist anzufügen, dass die vorliegende Erfindung durch ihre technische Struktur eine gebietsübergreifend Anwendung sowohl in der loT-Welt (Internet of Things), Robot-Robot oder Maschine-zu-Maschine-Kommunikation hat, insbesondere beim Vorbeugen von Daten-, und Software-Diebstahl, Verbesserung von Refresh-Mechanismen bei offenen Protokollen wie dem OAuth-Protokoll (z.B. OAuth2.0-Protokoll), im Zusammenhang mit Block-Chain z.B. bei der Verwendung von biometrischen persönlichen Schlüsseln oder bei Autorisierungs-/Authentizierungs-Login-Mechanismen. Diese universelle Anwendbarkeit lässt sich mit keinem bekannten System oder Verfahren des Standes der Technik so realisieren. Da offene Protokolle wie das OAuth insbesondere eine standardisierte, technologie-übergreifende, sichere API (Application Programming Interface)-Autorisierung für Desktop-, Web- und Mobile-Anwendungen erlaubt, ergibt die Kombination der vorliegenden Erfindung mit derartige offenen Protokollen eine entsprechend breite Anwendbarkeit und Einsetzbarkeit.

Kurze Beschreibung der Zeichnungen

[0011] Die vorliegende Erfindung wird detaillierter erklärt durch die folgenden Beispiele mit Referenzierung zu den Zeichnungen, wobei: Fig. 1 zeigt schematisch einen elektronischen Maskierungs- und Kennzeichnungsengine zur Maskierung und eindeutiger Signierung von Datenbankinhalten und Datenbank-Quellcode, sowie ein Komponenten-Überblick für den Betrieb des Maskierungs- und Kennzeichnungsengine und für das Erstellen des versandbereit maskierten PL-SQL Source-Code. Schritt 1 und 2 zeigen den Maskierungs- und Kennzeichnungsengine, der in einem vordefinierten Benutzer-Schema mit der loadjava-Utility (2) von der Oracle Database geladen wird. Schritt 3 zeigt, wie innerhalb eines vordefinierten Oracle Benutzer-Kontos aile Operationen für die Maskierung des Klartext-PL-SQL Source Codes stattfinden. Schritt 4 zeigt, wie die parametrisierten Methoden es erlauben, einzelne PL/SQL Pakete oder eine gesamte Library in der referenzierten Reihenfolge der PL/SQL Pakete, zu erstellen. Schritt 5 zeigt schliesslich, wie der maskierte PL/SQL-Code versandbereit gezippt ist. Fig. 1 illustriert damit den grundsätzlichen Aufbau und die Funktionsweise des elektronischen Maskierungs- und Kennzeichnungsengine von der Lieferung, als gezipptes WAR-File, bis zur Extraktion entweder eines beliebigen Files respektive Patches oder einer gesamten Library (5) aus der Oracle-Datenbank. Die Files sind in einem Archiv gespeichert und gezippt für einen bestimmten End-Benutzer, mittels der gängigen Transferkanäle (Mailanhang, SFTP (Secure-File-Transfer-Protocol), download aus einem Repository) versandbereit. Fig. 2 illustriert schematisch den Transfer eines Maskierungs- und Kennzeichnungsengine als gezipptes jar-File. Fig. 2 zeigt damit, wie ein End-Benutzer den elektronischen Maskierungs- und Kennzeichnungsengine erhält. Das entzippte Archiv enthäit sämtliche weitere Programme für die Installation und Betrieb des elektronischen Maskierungs- und Kennzeichnungsengine und die Installation-Guide wie in Fig. 3 (Entzippen des Files „deliver_release_1_1_20160202“) ersichtlich. Fig. 3 zeigt beispielshaft das Entzippen des Files „deliver_release_1_1_20160202“. Fig. 4 zeigt beispielshaft einen elektronischen Maskierungs- und Kennzeichnungsengine, der als Java-Byte-Code mittels der loadjava-Utility von Oracle in das Benutzer-Schema eingebettet wird. D.h. der Maskierungs- und Kennzeichnungsengine wird ausserhalb einer Oracle-Datenbank mit den gängigen Java-Entwicklungstools entwickelt. Der Klartext-Java-Source-Code wird niemals in irgendeine Oracle-Datenbank geladen (vgl. Fig. 4). Gängige Java-Tools genügen, um aus den einzelnen, referenzierten Java-Klassen ein jar-File zu erstellen. Das jar-File ist in einem Directory gespeichert, um mit der loadjava-Utility von Oracle in die Datenbank zu laden. Fig. 5 zeigt beispielshaft eine Bestätigung des erfolgreichen Ladeprozesses der java-byte-classes aus dem jar-File in die Datenbank. Fig. 5 illustriert, dass nur der Eigentümer oder ein Administrator die Engine in ein bestimmtes Oracle-Benutzer-Schema installieren darf. Dafür sind notwendig: „Benutzer-Name/Passwort“, „Server-Name“, „Port“ und „Datenbank-instanz-Name“, ausserdem muss der Zugriff auf den lokalen Ordner erlaubt sein, worin die OPCHSE-Engine als „obfKit1_1.jar“ File gespeichert ist. Nachdem der Ladeprozess gestartet ist, bestätigt die Loadjava-Engine, dass sämtliche Java-Byte-Klassen fehlerfrei im ausgewählten Datenbank-Benutzer-Konto (=Schema) geladen sind. Fig. 6 zeigt beispielshaft einen elektronischen Maskierungs- und Kennzeichnungsengine, der vollständig als Java-Byte-Code in der Oracle-Datenbank eingebettet ist. D.h. Fig. 6 zeigt, dass mit Hilfe von gängigen SQL-Tools (z.B. SQL-Developer) die Datenbank alle Klassen der Obfuskation-Engine enthält. Dabei wird nur der Java-Byte-Code in die Datenbank geladen. Fig. 7 zeigt beispielshaft die Tabelle „OBP_PACKAGELIST_T“, die die zu obfuskierenden Pakete enthält. Die Reihenfolge der Paket-Namen lässt sich erzwingen. Dadurch ist die logische Referenz der PL-SQL Pakete erhalten und als gesamte Library fehlerfrei kompilierbar. End-Benutzer fügen die Liste der PL/SQL-Pakete, welche es zu obfuskieren gilt in die Tabelle „OBF_PACKALIST_T“. Fig. 8 zeigt beispielshaft die Tabelle OBF_JKEYWRD20BF_T, die in der Spalte „KEYWORD“ die zu verschlüsselnden Keywords enthält. Die Engine ermittelt „on-the-fly“ die obfuskierten Schlüsselworte und speichert sie in der Spalte „OBFKEYWORD“ ab. Fig. 8 zeigt damit die zweite wichtige Tabelle, welche durch End-Benutzer zu pflegen ist. Der Maskierungs- und Kennzeichnungsengine erzeugt für jedes Klartext-„KEYWORD“ immer ein verschlüsseltes Schlüsselwort von 29 Zeichen und speichert es in der Spalte „OBFKEYWORD“ ab. Im Fall von „Cross-Site-Scripting“-Angriffe (XSS) lässt sich ein Angriff mittels SQL-Injektion auf die Datenbank-Objekte verhindern. Einerseits, weil die encrypted Objekt-Namen in keiner Liste aufgeführt sind. Somit erweisen sich „Brute-Force“ und/oder „rainbow password cracker“ Methoden als nutzlos, um die encrypted Schlüsselworte als Klartext zu erhalten. Anderseits, falls ein Objekt-Name auch nur um ein Zeichen erweitert wird oder die encrypted Schüsselworte manipuliert werden, meldet die PL/SQL-Engine sofort einen Fehler, weil die Oracle-Engine im ersten Fall keine Objektnamen länger als 30 Zeichen zulässt und/oder, wie im zweiten Fall, weil das manipulierte encrypted Schlüsselwort im Kontext des PL/SQL Source Code unerkannt bleibt und die Oracle-PL/SQL-Engine das Objekt als „invalid“ abstempelt, jegliche Ausführung per sofort blockiert. Schliesslich, ist die totale Obfuskation aller Objekt-Namen möglich, um auch „Schnüffler“ innerhalb des gleichen Unternehmens entgegen zu wirken, in dem sowohl in der Paket-Definition als auch im Paket-Körper sämtliche Objekt-Namen verschlüsselt werden. Im Suchbaum, wie z.B. SQL-Developer oder mittels der gängigen Administratoren-Tools erscheinen Folgen von sinnlosen Zeichensequenzen. Nur Benutzer und/oder diejenigen, welche den PL/SQL Source-Code pflegen und entwickeln haben, können mit Hilfe der Tabelle (vgl. Figur 8) und mit dem gleichen Mechanismus den Klartext PL/SQL Source Code wieder erstellen. Darum eignet sich die Verschlüsselungs-Engine, welche separate von der Obfuskation-Engine zu haben ist, auch oder besonders für planmässige oder nach dem Zufallsprinzip gesteuerte Änderung der Passwörter in verteilte Oracle-Datenbanken.

[0012] Die Tabelle (Figur 8) ist in vielen Hinsichten wie Historisierung, Versionierung der encrypted Schlüsselwörter respektive Passwörter und License-Key-Management kundenspezitisch erweiterbar.

[0013] Durch Austauschen des Inhalts aus der Spalte „OBFKEYWORD“ mit dem Inhalt aus der Spalte „KEYWORD“ können Entwickler und Inhaber des PL-SQL-Code mit derselben Engine den Klartext-Source-Code gewinnen. Auch nach der vollständigen Obfuskation aller Objektnamen (Paket-, Prozedur-, Funktion-, Tabellennamen) durch den Eintrag der Klartext-Namen in die Spalte „KEYWORD“ ist es mit dem erwähnten Austauschverfahren der beiden Spalten möglich den Klartext-Source-Code aus dem verschlüsselten Source-Code zu gewinnen. Noch mehr, z.B. um die Immaterialgüterrechte oder andere Rechte eines PL-SQL Source Code zu wahren und beweisen zu können, lassen sich wahlweise beliebige „elektronische Unterschriften“ im obfuskierten Source-Code streuen oder planmässig platzieren. Fig. 9 zeigt beispielshaft das Einbetten der Java-Programme in PL-SQL-Code und Steuerung vom PL-SQL Code aus. Fig. 10 zeigt beispielshaft einen kompakten Klartext PL-SQL Source Code. Fig. 11 zeigt beispielshaft einen kompakten maskierten PL-SQL Source Code. Encrypted Schlüsselworte ersetzen dabei die Klartext-Schlüsselworte. Der kompakte Klartext-PL-SQL Source Code (vgl. Fig. 10) bildet die Grundlage für die Maskierung des PL-SQL Source Codes, wie in Fig. 11 gezeigt.

Detaillierte Beschreibung einer bevorzugten Ausführungsvariante

[0014] Figur 1 illustriert schematisch eine Architektur für eine mögliche Realisierung einer Ausführungsvariante des Oracle-based PL/SQL Code Hiding and Signing Engine. Der Engine kann beispielsweise basierend auf einer Library von 25 PL/SQL-Source Code Pakete erfolgreich auf verschiedenen Oracle-Instanzen und Plattformen realisiert werden. Der kompilierte PL/SQL Source Code einer gesamten Library bleibt immer innerhalb der Oracle-Datenbank erhalten. Die gesamte Funktionalität der OPCHSE Engine stützt sich auf Kompaktieren und Sequentialisierung (Figuren 9 und 10) des Source-Codes, Maskierung von ausgewählten Schlüsselworten (Figuren 8) innerhalb des PL/SQL-Source Codes (Figuren 11). Die eineindeutigen PL/SQL-Paket-Namen sind als Primärschlüssel in einer relationalen Tabelle innerhalb der Oracle-Datenbank (Figur 7) gespeichert. Die Reihenfolge der gespeicherten PL/SQL-Paketnamen (Figur 7) gilt als Referenzmechanismus und Reihenfolge, um die maskierten PL/SQL-Pakete einer Library in eine Oracle RDBMS-Instanz (Relational Database Management System) zu kompilieren. Damit ist Maskierung und Kompilierung einer gesamten Library per Tastendruck innert weniger Minuten, wenn nicht sogar Sekunden, verglichen mit der Engine von Pete Finnigham, möglich. Anzumerken ist, dass relationale Datenbanken auf einem tabellenbasierten relationalen Datenbankmodell beruhen. Das zugehörige Datenbankmanagementsystem wird als relationales Datenbankmanagementsystem oder RDBMS (Relational Database Management System) bezeichnet. Zum Abfragen und Manipulieren der Daten wird überwiegend die Datenbanksprache SQL (Structured Query Language) eingesetzt. Grundlage des Konzeptes relationaler Datenbanken ist die Relation, d.h. Datenbankrelation, die eine mathematische Beschreibung einer Tabelle darstellt. Operationen auf diesen Relationen werden durch die relationale Algebra bestimmt. Die relationale Algebra ist somit die theoretische Grundlage von SQL. Die relationale Datenbank beruht folglich auf einer Sammlung von Tabellen (den Relationen), in welchen Datensätze abgespeichert sind. Jede Zeile (Tupel) in einer Tabelle ist ein Datensatz (record). Jedes Tupel besteht aus einer Reihe von Attributwerten (d.h. Eigenschaften), den Spalten der Tabelle. Das Relationenschema legt dabei die Anzahl und den Typ der Attribute für eine Relation fest.

[0015] Die im PL/SQL-Code zu maskierenden Schlüsselworte sind eineindeutig in einer relationalen Tabelle aufgeführt und genau einem spezifischen PL/SQL-Paket zugeordnet. Ein entsprechender Engine liest die Klartext-Schlüsselworte aus dem Source-Code, erzeugt dynamisch, d.h. „on-the-fly“, ein verschlüsseltes Keyword nach den PL/SQL-Regeln, substituiert das klartext-Schlüsselwort mit dem encrypted Schlüsselwort und speichert den gesamten, maskierten PL/SQL-Source Code stückweise in eine relationale Tabelle ab (vgl. Figur 11). Die verschlüsselten Schlüsselworte sind für Dritte, insbesondere Hackers, irreversibel, weil kein einziges davon in irgendeiner „Liste“ enthalten oder einsehbar ist.

[0016] Die Tabellen mit dem ursprünglichen, kompaktierten Source-Code, Reihenfolge der zu verschlüssenden PL/SQL-Pakete, encrypted Schlüsselworte und maskierten Code können dabei nur einem geschützten Kreis selektiv zugänglich gemacht werden und z.B. nur denjenigen Autoren und/oder Entwickler zugänglich sein, welche mit der Obfuskierungsaufgabe beauftragt sind und/oder zugestimmt haben, die IPR (Intelligence Property Rights) des PL/SQL-Code zu wahren. Der geschützte Kreis von Personen kann allenfalls sogar verpflichtet sein, nachweisen zu müssen, falls ein allfälliger End-Benutzer möglicherweise einen unlizenzierten PL/SQL Source Code verwendet. Der elektronische Maskierungs- und Kennzeichnungsengine ermöglicht den maskierten PL/SQL Code „elektronisch zu unterschreiben“. Dies, indem im Code bewusst automatisierte Zeichenfolgen mittels des Engins einfügt werden, welche von der Oracle PL/SQL Engine korrekt interpretiert werden. In Wahrheit, die anscheinend „unsinnigen Zeichenfolgen“ verstecken und eindeutig nachweisbar den Signing-Token als Copyright-Beweis. Diese Technik der Code Signierung mittels „unsinnigen Zeichenfolgen“ lässt sich insbesondere anwenden, um gewollt und bewusst die Ausführung vom PL/SQL Source-Code zu verhindern. Damit lässt sich bereits bei der Auslieferung des Source-Code ein Schutzmechanismus anwenden, um entweder Transaktionen, Aktionen oder Operationen auf Daten in der Datenbank zu verunmöglichen und/oder um das Mehraugenprinzip zu verwirklichen, z.B. wenn es darum geht, bewilligungspflichtige Transaktionen und/oder Aktionen und/oder sensitive Informationen in einer Datenbank auszuwählen und auszuhändigen, welche vorgängig jedoch von verschiedensten Mitverantwortlichen bestätigt werden müssen, in dem verdeckt eine Prozedur/Funktion/Programm aufgerufen wird, dessen Namen ebenso encrypted ist und als Folge von „unsinnigen“ Zeichen innerhalb des PL/SQL-Source-Codes erscheint und eingebettet ist. Das verborgene Programm, welches als Java-Byte-Code im PL/SQL-Code eingebettet ist, blockiert per sofort vor der Ausführung (i) von bewilligungspflichtigen Transaktionen und/oder Aktionen auf sensitive Informationen, (ii) benachrichtigt (z.B. unmittelbar) die Mitverantwortlichen, z.B. Line Manager, Entscheidungsträger und/oder Member of Board, C-Level, z.B. über gängige Kommunikationskanäle, wie iPhone, Mail, Telefon, über die Absicht eine unerlaubte Transaktion und/oder Aktion auszuführen, welche durch Dritte ausgelöst wurde. Sämtliche Prozessschritte, welche der Auslöser der bewilligungspflichtigen Transaktion und/oder Aktion durchgeführt hat, werden unwiderruflich registriert, eingefroren und verschlüsselt. Eine Kopie der gesamten registrierten Prozessschritte, welche zur unerlaubten Transaktion und/oder Aktion geführt haben, ähnlich einer Black-Box in der Aviatik, werden ausserhalb des Systems verschlüsselt gesichert. Die Aufzeichnungen können insbesondere als Beweise für forensische Zwecke verwendet werden. Mit diesem Mechanismus ist z.B. selbst Hackers verunmöglicht, selbst nach gelungenem Eindringen im System, Daten zu stehlen oder zu manipulieren.

[0017] Der Zugriff auf das jeweilige Benutzer-Schema (vgl. Figur 1, Prozessschritt 3), welcher die gesamte elektronische Maskierungs- und Kennzeichnungsengine speichert, erfolgt nur mittels vordefinierter, scharfer Rollen, welche bestimmten, ausgewiesenen End-Anwendern der Engine zugeteilt werden, und zwar, nach den Sicherheits-Regeln des Datenbank-Providers, d.h. z.B. von Oracle. Die Zugriffs-Sicherheit auf den elektronische Maskierungs- und Kennzeichnungsengine kann sogar merklich erhöht werden, indem der gesamte Mechanismus „transparent encrypted“ im jeweiligen Speichermedium abgelegt und mit dem maskierten, erstellten PL/SQL Source Code im ordentlichen Backup-Restore-Recovery Prozess eingebunden wird.

[0018] Nach der Maskierung des Source-Codes lässt der Maskierungs- und Kennzeichnungsengine es zu, entweder ein einzelnes PL-SQL Paket (geeignet, um einzelne Patches innerhalb einer Library zu erstellen) oder eine gesamte Library als einziger Stream in eine versandbereit gezippte Datei, zu exportieren (vgl. Figur 1, Prozessschritte 4 und 5).

[0019] Entwickler und/oder Autor(en) des PL/SQL Codes alleine können mittels des Historisierungs-, und Versionierungsmechanismus jederzeit das Paar (Klartext-Schlüsselwort; encrypted-Schlüsselwort) rekonstruieren und feststellen, wann, für welchen End-Benutzer oder Kunden, in welchem PL/SQL-Paket jeweils die Substitution „klartext-Schlüsselwort“ mit „encrypted Schlüsselwort“ stattgefunden hat (vgl. Figur 8). Das heisst, dass für definierte Benutzer, insbesondere Code Verantwortlichen und/oder Entwickler, also dem, eingeschränkten Kreis von Verantwortlichen, welcher der Schweigepflicht verpflichtet ist, feststellbar ist, wann, für welchen End-Benutzer oder Kunden, in welchem PL/SQL-Paket jeweils die Substitution Klartext-Schlüsselwort“ mit „encrypfed Schlüsselwort“ stattgefunden hat. Ebenso ist in derselben Tabelle (Figur 8), in welcher jedes Paar (Klartext-Schlüsselwort; encrypted Schlüsselwort) gespeichert ist, jedes Paar mit einem Zeitstempel versehen. Der gesamte Mechanismus kann z.B. in Java, einer objektorientierten Programmiersprache entwickelt sein (Figur 2,3,4). Die Engine ist jedoch als Byte-Code (vollkommen intransparenter und irreversibler Code für Benutzer) im PL/SQL-Code vollständig eingebettet und vom PL-SQL-Engine ausführbar (vgl. Figur 5,6,9). End-Benutzer können z.B. den Engine mittels den gängigen und bekannten Tools bedienen. Dabei kann insbesondere der gesamte Prozess von der Installation, Fehlerbehebung bis zum Erstellen von versandbereit gezippten Patches oder Libraries mittels GUI (graphische Oberfläche) gestalten sein.

[0020] Die Tabelle, welche die zu maskierenden Schlüsselworte enthält (Figur 8), lässt sich in analoger Weise mit Klartext-Passwörtern befüllen. Danach können die verschlüsselten „on-the-fly“, d.h. dynamisch erstellten Passwörter von Machine-to-Machine gesendet werden, um auf lokale oder delokalisierten (fernen) Maschinen und/oder Applikationen Passwörter automatisch und/oder nach einem Zeitplan und/oder nach dem Zufallsprinzip, zu ändern.

[0021] Security-Administratoren haben aufgrund des automatisch nachgeführten Life-Cycle-Mechanismus für ein jedes Klartext-Passwort, Applikationsname, delokalisierte und/oder lokale Maschine, immer den dynamisch geführten Überblick, wann welches Passwort wo geändert worden ist.

[0022] Der Maskierungs- und Kennzeichnungsengine bietet eine valide Gegenmassnahme an, um dem Cybercrime, der mit immer aktiveren und mit sehr ausgeklügelten Methoden in Systeme und Datenbanken eindringt, das Handwerk zu erschweren, wenn nicht gar zu verhindern. Einerseits, weil die durch Hackers möglicherweise erfassten (mittels: „Brüte Force“, „Mon-in-the-Middle“, „key-loggers“, „sniffing“, Methoden, um Beispiele zu nennen) verschlüsselten PL/SQL Source-Code Schlüsselworte und/oder Passwörter, für einen Hacker vollkommen wertlos sind. Es gibt keine Liste, womit die encrypted Schlüsselworte verglichen werden können, um daraus den Klartext zu gewinnen. Der Maskierungs- und Kennzeichnungsengine erzeugt dynamisch („on-fhe-fly“) nach dem Zufallsprinzip ein encrypted Schlüsselwort. Auch die schnellere Variante des „Brute-Force“ Vorganges „rainbow password cracker“ (vgl. www.google.ch/?gfe_rd=cr&ei=Cb5EV7cluaX8QeCkYKQDw&gws_rd=ssl#q=rainbow+p assword+cracker)ist in diesem Fall für Hackers völlig nutzlos.

[0023] Der Maskierungs- und Kennzeichnungsengine erzeugt selbst aus einem einzigen Zeichen bestehenden Klartext-Schlüsselwortes und/oder Passwortes ein verschlüsseltes Schlüsselwort oder Passwort von 29 Zeichen nach den PL-SQL Engine Regeln von Oracle. Die maximale Zeichenlänge von 29 Zeichen ist von Oracle festgelegt und darf auf keinen Fall überschritten werden, denn sobald der verschlüsselten Zeichenkette ein einziges Zeichen dazu gefügt wird, blockiert die Oracle-PL/SQL Engine jede weitere Ausführung. Falls Hackers selbst ein einziges verschlüsseltes Schlüsselwort ersetzen, wird dieses im Kontext des PL/SQL Codes von der Oracle Engine nicht erkannt. Jeder Versuch, ein Programm auszuführen, ist sofort mit einem „ORA-Error“ quittiert. Mit diesen, mit jeder Oracle-Instanz inhärent gegebenem Mechanismus, schlägt jeder manipulierte, maskierte PL/SQL Source Code sofort Alarm.

[0024] Die Verschlüsselungs-Engine eignet sich besonders für planmässige oder nach dem Zufallsprinzip gesteuerte Änderungen von Passwörter in verteilten Oracle-Datenbanken, besser bekannt als Oracle-Cloud. Die Tabelle (Figur 8) mit dem Paar (Klartext-Schlüsselworte; encrypted Schlüsselwort) ist in Hinsicht Historisierung, Versionierung der encrypted Schlüsselwörter respektive Passwörter und License-Key-Management (Figur 4) kundenspezifisch erweiterbar.

[0025] Der Verschlüsselungs-Engine kann auch separate vom Maskierungs- und Kennzeichnungsengine realisiert sein (vgl. Figur 2) und kann mit dem gleichen Mechanismus (vgl. Figur 5) in ein PL/SQL-Code eingebettet und bedient werden (vgl. Figur 9).

Claims (11)

1. Verfahren zur Maskierung und eindeutiger Signierung von Datenbank-Quellcodes mittels eines elektronischer Maskierungs- und Kennzeichnungsengine eines Systems mit mindestens einer Datenbank, wobei ein Datenbank-Quellcode SQL-Code und PL-SQL-Code als Host-Sprache umfasst, und wobei SQL-Kommandos an entsprechenden Stellen in den Datenbank-Quellcode eingebunden werden durch Prozeduraufrufe und/oder als Klartext-Befehle, die von einem Pre-compiler in Prozeduraufrufe der Host-Sprache übersetzt werden, dadurch gekennzeichnet, dass mittels eines Ladeprozesses der Maskierungs- und Kennzeichnungsengine Klartext-Schlüsselworte aus dem Datenbank-Quellcode ausgelesen werden und dynamisch, in Echtzeit ein engrypted Schlüsselwort nach den PL/SQL-Regeln erzeugt wird, dass mittels des Maskierungs- und Kennzeichnungsengine das Klartext-Schlüsselwort mit dem encrypted Schlüsselwort substituiert wird und der maskierte Datenbank-Quellcode stückweise in eine relationale Tabelle abgespeichert wird, wobei das encrypted Schlüsselwort vom Maskierungs- und Kennzeichnungsengine interpretiert wird, und dass zur Maskierung und eindeutiger Signierung von Datenbank-Quellcodes automatisiert im Datenbank-Quellcode Zeichenfolgen mittels des Maskierungs- und Kennzeichnungsengine einfügt werden, wobei der Datenbank-Quellcode mit eingefügten Zeichenfolgen von dem Maskierungs- und Kennzeichnungsengine interpretierbar ist.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass der Zugriff auf das jeweilige Benutzer-Schema, welcher die gesamte elektronische Maskierungs- und Kennzeichnungsengine speichert, nur mittels vordefinierter, scharfer Rollen erfolgt, welche bestimmten, ausgewiesenen End-Anwendern der Maskierungs- und Kennzeichnungsengine zugeordnet sind.

3. Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass der Zugriff auf das jeweilige Benutzer-Schema, welcher die gesamte elektronische Maskierungs- und Kennzeichnungsengine speichert, mittels der vordefinierter, scharfer Rollen nach den Sicherheits-Regeln eines jeweiligen Datenbank-Providers erfolgt.

4. Verfahren nach einem der Ansprüche 2 oder 3, dadurch gekennzeichnet, dass die Zugriffs-Sicherheit auf den elektronischen Maskierungs- und Kennzeichnungsengine erhöht wird, indem ein, transparent encrypted Mechanismus im jeweiligen Speichermedium abgelegt und mit dem maskierten, erstellten Dantebank-Quellcode im ordentlichen Backup-Restore-Recovery Prozess eingebunden wird.

5. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass nach der Maskierung des Datenbank-Quellcode mittels des Maskierungs- und Kennzeichnungsengine entweder ein einzelnes PL-SQL Paket, welches geeignet ist, einzelne Patches innerhalb einer Library zu erstellen, oder eine gesamte Library als einziger Stream in eine versandbereit gezippte Datei exportiert wird.

6. Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass für Benutzer des Datenbank-Quellcode mittels einem Historisierungs-, und Versionierungsmechanismus jederzeit das Paar {Klartext-Schlüsselwort; encrypted-Schlüsselwort} rekonstruierbar ist, wobei für definierte Benutzer, insbesondere Code Verantwortlichen und/oder Entwickler als Geheimhalteverpflichtete, feststellbar ist, wann, für welchen End-Benutzer oder Kunden, in welchem PL/SQL-Paket jeweils die Substitution Klartext-Schlüsselwort mit encrypted Schlüsselwort stattgefunden hat.

7. Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass in derselben Tabelle, in welcher jedes Paar {Klartext-Schlüsselwort; encrypted Schlüsselwort} gespeichert ist, jedes Paar mit einem Zeitstempel versehen ist.

8. Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass der gesamte Maskierungs- und Kennzeichnungsengine in Java und/oder einer objektorientierten Programmiersprache realisiert ist, wobei der Engine als Byte-Code und als vollkommen intransparenter und irreversibler Code für Benutzer im Datenbank-Quellcode vollständig eingebettet und vom Maskierungs- und Kennzeichnungsengine ausführbar ist.

9. Verfahren nach einem der Ansprüche 1 bis 8, dadurch gekennzeichnet, dass die Tabelle, welche die zu maskierenden Schlüsselworte enthält, in analoger Weise mit Klartext-Passwörter befüllbar ist, wobei danach die verschlüsselten und dynamisch erstellten Passwörter von Machine-to-Machine sendbar sind, um auf lokale oder delokalisierten Maschinen und/oder Applikationen Passwörter automatisch und/oder nach einem Zeitplan und/oder nach dem Zufallsprinzip, zu ändern.

10. Verfahren nach einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, dass der Maskierungs- und Kennzeichnungsengine aus einem einzigen Zeichen bestehenden Klartext-Schlüsselwortes und/oder Passwortes ein verschlüsseltes Schlüsselwort oder Passwort von 29 Zeichen nach den Maskierungs- und Kennzeichnungsengine Regeln von der Datenbank erzeugt, wobei die maximale Zeichenlänge von 29 Zeichen von der Datenbank festgelegt und nicht überschreitbar ist, und wobei bei zusätzlichem Zufügen eines Zeichens zur verschlüsselten Zeichenkette der Maskierungs- und Kennzeichnungsengine jede weitere Ausführung blockiert.

11. Verfahren nach einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, dass die Verschlüsselung mittels einem vom Maskierungs- und Kennzeichnungsengine separaten Verschlüsselungs-Engine realisiert ist, der mit dem gleichen Mechanismus in den Datenbank-Quellcode eingebettet und bedienbar ist.