Verschlüsselung. Klaus Reimers ORDIX AG Köln. Verschlüsselung, encrypt, decrypt, dbms_obfuscation_toolkit, dbms_crypto, wallet, datapump, rman

Transkript

1 Verschlüsselung Klaus Reimers ORDIX AG Köln Schlüsselworte: Verschlüsselung, encrypt, decrypt, dbms_obfuscation_toolkit, dbms_crypto, wallet, datapump, rman Einleitung Die Frage nach einer Verschlüsselung von Daten und nach möglichen Verschlüsselungsmethoden begegnet mir in Projekten immer häufiger. Ich werde in meinem Vortrag die die jeweiligen Vor- und Nachteile sowie die Anwendungsmöglichkeiten folgender Methoden darstellen: PL/SQL o dbms_obfuskation_toolkit o dbms_crypto Transparente Verschlüsselung o von Spalten o von Tablespaces Kennwort-Verschlüssung bei Data Pump Verschlüsselung von Backup Sets und Archivelog-Dateien in RMAN Neben der hier dargestellten Verschlüsselung von Teilen der Datenbank gibt es auch die Verschlüsselung auf Netzwerkebene, die aber nicht Teil dieses Vortags ist. PL/SQL dbms_obfuscation_toolkit Seit der Version 8i stellt Oracle das Package DBMS_OBFUSCATION_TOOLKIT zur Verfügung, mit dem Daten innerhalb einer Oracle-Datenbank verschlüsselt werden können, um so einen unberechtigten Zugriff auf Daten zu verhindern. Das Package liefert zwei verschiedene Verschlüsselungsalgorithmen: 1. Data Encryption Standard (DES) Algorithmus 2. Triple DES (3DES) Algorithmus Der Data Encryption Standard (DES) Algorithmus ist ein symmetrischer Verschlüsselungsalgorithmus und zeichnet sich dadurch aus, dass ein betrachteter, geheimer

2 Schlüssel sowohl für die Ver- als auch für die Entschlüsselung verwendet wird. Für die Verschlüsselung mit dem DES Algorithmus wird im Allgemeinen ein 56-Bit langer Schlüssel benötigt. Neben dem DES Algorithmus stellt das Package DBMS_OBFUSCATION_TOOLKIT den Triple DES (3DES) Algorithmus zur Verfügung. Der 3DES Algorithmus basiert auf dem DES Algorithmus und bietet durch eine dreifache Verschlüsselung der Daten eine zusätzliche Sicherheit. Darüber hinaus kann der 3DES Algorithmus im Gegensatz zum DES Algorithmus in einem Zwei- bzw. Drei-Schlüsselmodus ausgeführt werden. Für den Zwei-Schlüsselmodus wird ein Schlüssel mit der Länge von 128-Bit benötigt und für den Drei-Schlüsselmodus ein Schlüssel mit der Länge von 192-Bit. Der Standardwert bei der Verschlüsselung mit dem 3DES Algorithmus ist der Zwei-Schlüsselmodus. dbms_crypto Das Package DBMS_CRYPTO verwendet für die Verschlüsselung von Daten unter anderem folgende Algorithmen: 1. Data Encryption Standard (DES) 2. Advanced Encryption Standard (AES) 3. Triple DES (3DES) Algorithmus Bei den DES und AES Verschlüsselungsalgorithmen handelt es sich um symmetrische Verschlüsselungsalgorithmen. Der AES ist der Nachfolger des DES und wurde im Oktober 2000 vom National Institute of Standards and Technology (NIST) als Standard bekanntgegeben. Er kann mit einem 128-Bit, 192-Bit und 256-Bit langen Schlüssel verwendet werden. Neben dem DES Algorithmus stellt das Package DBMS_CRYPTO den Triple DES (3DES) Algorithmus zur Verfügung. Der Standardwert bei der Verschlüsselung mit dem 3DES Algorithmus ist identisch zum Standard bei dbms_obfuscation_toolkit. Mit den Prozeduren bzw. Funktionen ENCRYPT und DECRYPT ist es möglich, Daten vom Datentypen CLOB, BLOB oder RAW zu ver- bzw. entschlüsseln. Der Datentyp VARCHAR2 wird nicht unterstützt, sondern muss vorher in den Zeichensatz AL32UTF8 umgeformt und anschließend z. B. in den Datentyp RAW konvertiert werden. Das Package DBMS_CRYPTO verfügt außerdem über so genannte Hash-Funktionen wie HASH oder MAC (Message Authentication Code). Mit Hilfe einer Hash-Funktion kann aus einer komplexen Datenstruktur, wie Zeichenkette oder Objekt, ein Hash-Wert berechnet werden. Da die Hash-Funktionen so optimiert sind, dass sie möglichst eindeutige Hash-Werte liefern, kann ein Hash-Wert auch als Schlüssel für beispielsweise Tabellen oder assoziative Arrays (Hash-Tabellen) benutzt werden.

3 Das besondere an einer MAC-Funktion ist, dass zur Errechnung eines Hash-Wertes ein Schlüssel notwendig ist. Mit diesem Schlüssel soll eine zusätzliche Sicherheit gewährleistet werden, um die Bestimmung eines Klartextes aus einem Hash-Wert zu verhindern. Die folgende Aufstellung zeigt die Unterschiede zwischen den beiden Packages. Package Feature DBMS_CRYPTO DBMS_OBFUSCATION_TOOLKIT Verschlüsselungsalgorithmen DES, 3DES, AES, DES, 3DES RC4, 3DES_2KEY Padding Formen PKCS5, zeroes Nicht unterstützt Block cipher chaining modes CBC, CFB, ECB, CBC OFB Hash Algorithmen SHA-1 MD5 Hash Algorithmen mit Schlüssel HMAC_MD5, Nicht unterstützt (MAC) HMAC_SH1 Schlüsselgeneratoren RAW, NUMBER, RAW, VARCHAR2 BINARY_INTEGER Datenbank Datentypen RAW, CLOB, BLOB RAW, VARCHAR2 Schlüsselmanagement Eine zentrale Rolle bei der Verschlüsselung über PL/SQL-Prozeduren spielen die Erzeugung und die Verwaltung des Schlüssels. Besteht ein Schlüssel aus einfachen, zusammengesetzten Wörtern, so kann dieser leicht erraten werden. Für die Erzeugung von sicheren und zufälligen Schlüsseln stellt Oracle im Package DBMS_CRYPTO spezielle RANDOM-Funktionen, wie RANDOMBYTES, RANDOMINTEGER oder RANDOMNUMBER, zur Verfügung. Neben der Erzeugung des Schlüssels durch eine der genannten RANDOM-Funktionen kann die Eingabe des Schlüssels durch den Anwender auch manuell erfolgen. Hierbei ist zu beachten, dass der Schlüssel möglicherweise vergessen bzw. verloren wird. In diesem Fall können die verschlüsselten Daten nicht mehr entschlüsselt werden. Nachdem ein Schlüssel erzeugt wurde, stellt sich die Frage, wo dieser abgelegt werden kann. Grundsätzlich bestehen folgende Speichermöglichkeiten: in der Datenbank in einer Datei im Betriebssystem in der Datenbankanwendung Liegt der Schlüssel in der Datenbank, so hat der Datenbankadministrator jederzeit ungehinderten Zugriff auf den Schlüssel. Beim Ablegen des Schlüssels in einer Datei im Betriebssystem kann es bei häufigen Zugriffen auf den Schlüssel zu Performance-Einbußen kommen. Wird der Schlüssel in einer Datenbankanwendung abgelegt, kann sichergestellt

4 werden, dass selbst ein Datenbankadministrator die verschlüsselten Daten nicht entschlüsseln kann. Voraussetzung dafür ist allerdings, dass sich die Anwendung auf einem anderen Rechner als die Datenbank befindet. Transparente Verschlüsselung Transparente Verschlüsselung von Spalten Mit der transparenten Datenverschlüsselung ist es möglich, Daten in einer Datenbank ohne zusätzlichen Programmieraufwand zu verschlüsseln. Dabei findet beim Hinzufügen von Einträgen in eine Tabelle automatisch eine Verschlüsselung der Daten statt. Zudem werden die Daten beim Abfragen aus einer Tabelle automatisch entschlüsselt. Verschlüsselte Tabellenspalten lassen sich über die Datenbank-View DBA_ENCRYPTED_COLUMNS ermitteln. Wird eine Spalte mit dem Parameter ENCRYPT als verschlüsselt gekennzeichnet, so wird implizit ein Schlüssel für die Tabelle zum Verschlüsseln erzeugt und im Data Dictionary abgelegt. Aus Sicherheitsgründen wird dieser Schlüssel mit einem Master-Schlüssel verschlüsselt. Der Master-Schlüssel wird wiederum in einem Wallet abgelegt, der sich standardmäßig auf dem Datenbank-Server unter dem folgenden Verzeichnis befindet: $ORACLE_BASE/admin/$ORACLE_SID/wallet Die Ablage der Wallets kann in der Datei sqlnet.ora im Verzeichnis $ORACLE_HOME/network/admin auf dem Datenbankserver geändert werden. Ein Wallet dient zur Ablage von Zertifikaten zur SSL-verschlüsselten Verbindung oder auch zur Speicherung von Master-Schlüsseln. Es zeichnet sich dadurch aus, dass es durch ein Passwort geschützt ist und über den Oracle Wallet Manager (OWM) verwaltet werden kann. Beim Einfügen von Daten in eine Tabelle mit einer verschlüsselten Spalte wird zuerst der Master-Schlüssel aus dem Wallet ermittelt. Danach wird mit Hilfe des Master-Schlüssels der Tabellenschlüssel aus dem Data Dictionary entschlüsselt. Anschließend werden mit dem entschlüsselten Tabellenschlüssel die in die Tabelle eingefügten Daten verschlüsselt und in der Datenbank abgelegt. Indizierung von verschlüsselten Spalten Verfügt eine verschlüsselte Spalte über einen Index, so ist zu beachten, dass z. B. bei Vergleichen mit dem Operator LIKE immer ein Full Table Scan durchgeführt wird. Der Grund liegt hier in der Verschlüsselung. Die Struktur eines B*-Baumes ist so aufgebaut, dass ähnliche Werte in der Indexstruktur nebeneinander liegen. Durch die Verschlüsselung werden ähnliche Werte über den Index verstreut, da diese verschlüsselt und nicht mehr ähnlich gespeichert werden.

5 Salt-Prinzip unterschiedliche Verschlüsselung gleicher Werte Kommt ein Wert in einer Tabelle mehrfach vor, so wird dieser innerhalb einer Tabelle gleich verschlüsselt. Aufgrund dieser Tatsache, können anhand der verschlüsselten Werte Schlussfolgerungen bzgl. der Gemeinsamkeiten von Werten der Datensätze gezogen werden. Um das zu vermeiden, führte Oracle das Salt-Prinzip ein. Gleiche Werte in einer Tabelle werden dabei unterschiedlich verschlüsselt, so dass keine Schlussfolgerungen bzgl. der Gemeinsamkeiten gezogen werden können. Verschlüsselte Spalten werden standardmäßig mit dem Salt-Prinzip verschlüsselt. Für Spalten, die mit dem Salt-Prinzip verschlüsselt sind, kann kein Index angelegt werden. Aus diesem Grund kann das Salt-Prinzip nicht für Spalten eines Primärschlüssels oder Unique-Schlüssels verwendet werden, da bei diesen Constraints implizit ein Index erzeugt wird. Auf Spalten eines Fremdschlüssels ist das Salt-Prinzip ebenfalls nicht erlaubt. Transparente Verschlüsselung von Tablespaces Tablespaces können seit Oracle 11g verschlüsselt werden. Das geschieht direkt beim Anlegen des Tablespaces und kann im Nachhinein nicht mehr modifiziert werden. Mögliche Verschlüsselungsalgorithmen sind: 3DES168 AES128 (Default) AES192 AES256 Die Daten aus diesen Tablespaces sind während der gesamten Verarbeitungsschritte verschlüsselt, also auch beim Zwischenlagern im Temporary Tablespace. Folgende Einschränkungen sind zu beachten: Temporary Tablespaces sind nicht verschlüsselbar UNDO Tablespaces sind nicht verschlüsselbar BFILES und EXTERNAL TABLES sind nicht verschlüsselbar Verschlüsselte Tablespaces sind nicht über TSPITR auf andere Plattformen migrierbar Kennwort-Verschlüsselung bei Data Pump Beim Extrahieren von Daten mit dem Werkzeug Data Pump, werden verschlüsselte Daten standardmäßig im Klartext (also unverschlüsselt) in einer Datei abgelegt. Lediglich eine Warnung weist darauf hin, dass eventuell verschlüsselte Daten aus einer Tabelle in eine Datei unverschlüsselt gespeichert wurden. Um die mit Data Pump erzeugten Dateien zu schützen, kann mit der Option ENCRYPTION_PASSWORD ein Kennwort für die erzeugten Dateien festgelegt werden.

6 Sollen die mit Data Pump extrahierten Dateien in eine Datenbank wieder importiert werden, wird das beim Exportieren festgelegte Kennwort benötigt. Das Export Utility (EXP) unterstützt verschlüsselte Tabellen mit der transparenten Datenverschlüsselung nicht und kann diese auch nicht exportieren. Stattdessen können Tabellen mit 11g Data Pump verschlüsselt im Dateisystem abgelegt werden. Hierfür gibt es neue Kommandozeilen-Parameter. Verschlüsselung von BackupSets und Archivelog-Dateien in RMAN BackupSets können ab Oracle 10g verschlüsselt werden. Somit sind diese dann selbst mit Kenntnis der Blockstrukturen nicht mehr direkt lesbar. Die Verwendung dieser Backups für das Restore ist nur mit Kenntnis des Passwortes oder bei Verwendung der Advanced Security Option mit Verfügbarkeit des entsprechenden Wallets möglich. Die Einstellung verschlüsselter Backups kann mit folgendem Befehl erfolgen: CONFIGURE ENCRYPTION FOR DATABASE ON; Diese globale Einstellung gilt nicht für die Sicherung von Archivelog-Dateien. Um diese ebenso zu verschlüsseln, muss vor der Sicherung dieser Befehl verwendet werden: SET ENCRYPTION ON Der zu verwendende Verschlüsselungsalgorithmus kann mit folgendem Befehl eingestellt werden: CONFIGURE ENCRYPTION ALGORITM TO...' RMAN-Sicherungen können mit AES128, AES192, und AES256 verschlüsselt werden. Voraussetzung für die Nutzung der Backup-Verschlüsselung ist eine Einstellung des Parameters COMPATIBLE auf mindestens Kontaktadresse: Klaus Reimers ORDIX AG Wikinger Str Köln Telefon: +49 (0) Fax: +49 (0)

7 Internet: