Das ältere DBMS_OBFUSCATION_TOOLKIT unterstützt lediglich zwei inzwischen als weniger sicher eingestufte und ausserdem wenig performante Verschlüsselungsalgorithmen (DES und 3DES). Deshalb ist von der Verwendung dieses Package abzuraten. Stattdessen sollte DBMS_CRYPTO verwendet werden.

DBMS_CRYPTO ist Teil des Schema SYS. Voraussetzung für seine Verwendung ist die Ausführungsberechtigung, die natürlich über ein GRANT EXECUTE erteilt wird.

In konkreten Projekten betrifft die wichtigste Entscheidung für das Arbeiten mit DBMS_CRYPTO den Umgang mit dem Schlüssel oder den Schlüsseln für die Verschlüsselung. Drei Vorgehensweisen sind möglich.

1. Der oder die Schlüssel werden in der Datenbank gespeichert. Denkbar wäre, den oder die Schlüssel in einer separaten Spalte der Tabelle abzulegen, die auch die zu verschlüsselnden Daten enthält. Die Speicherung kann alternativ in einer eigenen Tabelle erfolgen. So ist es möglich, Schlüssel zu verwenden, die für unterschiedliche Zeiträume gelten oder die für jeden Datensatz unterschiedlich sind. Für beide Fälle muß natürlich die passende Form der Verknüpfung gewählt werden - also z.B. eine Verknüpfung über ein in dem Datensatz enthaltenes Datumsfeld oder eine Primär-Fremdschlüsselverknüpfung mit der Datentabelle.

Problematisch bei diesen Vorgehensweisen ist, dass privilegierten Benutzern, also z.B. Datenbankadministratoren, der Zugriff auf diese Schlüssel und damit auf die verschlüsselten Daten nicht zu entziehen ist.

2. Der oder die Schlüssel werden in einer Betriebssystemdatei abgelegt, die im Rahmen der Ver- bzw. Entschlüsselung gelesen wird. Auch hier liegt die Problematik in der Absicherung der Schlüssel gegen unbefugte Zugriffe, denn privilegierte Betriebssystemnutzer könnten die Datei jederzeit lesen.

3. Schließlich können die Schlüssel durch die Benutzer selbst verwaltet werden. Hier besteht allerdings die Gefahr, dass Schlüssel entweder vergessen werden - mit der Folge, dass der Zugriff auf die verschlüsselten Daten endgültig verloren geht - oder dass die Schlüssel und damit die verschlüsselten Daten durch ungeeignete Ablagen (Post-Its am Arbeitsplatz!) kompromittiert werden. Aber auch die Eingabe (Keylogger, Beobachtung der Eingabe!) und Übertragung der Schlüssel im Netzwerk (verschlüsselt?) könnten zum Sicherheitsproblem werden.

Für das Beispiel in diesem Beitrag wird auf die erste der genannten Möglichkeiten zurückgegriffen: Speicherung der Schlüssel in einer eigenen Tabelle. Die Schlüssel sollen nur für einen bestimmten Zeitraum Gültigkeit haben. Die Tabelle für die Schlüssel wird mit folgendem Befehl angelegt

CREATE TABLE schluesseltabelle
(schluessel RAW(300) NOT NULL,
 startdatum DATE NOT NULL,
 enddatum DATE
)

INSERT INTO schluesseltabelle (schluessel, startdatum) VALUES
   (SYS.DBMS_CRYPTO.RANDOMBYTES(32),
    to_date('AUG-01-2008', 'MON-DD-YYYY')
   )

CREATE OR REPLACE FUNCTION crypt (eingabe IN VARCHAR2)
RETURN RAW
IS
  v_rohdaten   	      RAW(200); 	-- Variable für verschlüsselten Wert
  v_schluessel	      RAW(32);		-- Variable für 256-bit Schlüssellänge
  v_verschluesselung  PLS_INTEGER :=   -- Kennung für Verschlüsselungsalgorithmus
     DBMS_CRYPTO.ENCRYPT_AES256 +  
     DBMS_CRYPTO.CHAIN_CBC +
     DBMS_CRYPTO.PAD_ZERO;
BEGIN
  SELECT schluessel INTO v_schluessel
  FROM schluesseltabelle
  WHERE sysdate BETWEEN startdatum AND nvl(enddatum, sysdate);
  v_rohdaten   := DBMS_CRYPTO.ENCRYPT(
       src => UTL_I18N.STRING_TO_RAW (eingabe, 'AL32UTF8'),
		       typ => v_verschluesselung,
		       key => v_schluessel);
RETURN v_rohdaten;
END;

INSERT INTO tabelle (...) VALUES (..., crypt('eintest'), ...)

CREATE OR REPLACE FUNCTION dcrypt (eingabe IN RAW)
RETURN VARCHAR2
IS
  v_daten   	      RAW(200);
  v_schluessel	      RAW(32);
  v_verschluesselung  PLS_INTEGER := 
     DBMS_CRYPTO.ENCRYPT_AES256 +
     DBMS_CRYPTO.CHAIN_CBC +
     DBMS_CRYPTO.PAD_ZERO;
BEGIN
  SELECT schluessel INTO v_schluessel
  FROM schluesseltabelle
  WHERE sysdate BETWEEN startdatum AND nvl(enddatum, sysdate);
  v_daten   := DBMS_CRYPTO.DECRYPT(
		 src => eingabe,
		 typ => v_verschluesselung,
		 key => v_schluessel);
RETURN UTL_I18N.RAW_TO_CHAR(v_daten, 'AL32UTF8');
END;

SELECT dcrypt(spaltenname)
FROM tabelle
WHERE ...

wrap iname=dateiname.sql

Zurück zur Community-Seite