AEAD-Verschlüsselungskonzepte

GoogleSQL for BigQuery unterstützt die AEAD-Verschlüsselung.

In diesem Thema werden die Konzepte der AEAD-Verschlüsselung in GoogleSQL erläutert. Eine Beschreibung der verschiedenen von GoogleSQL unterstützten AEAD-Verschlüsselungsfunktionen finden Sie unter AEAD-Verschlüsselungsfunktionen.

Ziel der AEAD-Verschlüsselung

BigQuery verschlüsselt Ihre Daten bei Inaktivität und schützt sie auf diese Weise. Außerdem unterstützt BigQuery vom Kunden verwaltete Verschlüsselungsschlüssel (Customer Managed Encryption Keys, CMEKs), mit denen Sie komplette Tabellen mithilfe spezieller Verschlüsselungsschlüssel verschlüsseln können. Manchmal kann es aber auch notwendig sein, einzelne Werte in einer Tabelle zu verschlüsseln.

Beispielsweise können die Daten Ihrer gesamten Kunden gemeinsam in einer Tabelle gespeichert sein, wobei die Daten jedes einzelnen Kunden mit einem eigenen Schlüssel verschlüsselt werden sollen. Oder es sind einzelne Daten über mehrere Tabellen verteilt, die kryptografisch gelöscht werden sollen. Als "kryptografisches Löschen" oder "kryptografische Vernichtung" bezeichnet man das Löschen eines Verschlüsselungsschlüssels, um alle mit diesem Schlüssel verschlüsselten Daten unlesbar zu machen.

Mit den Funktionen der AEAD-Verschlüsselung können Sie Schlüsselsätze mit Schlüsseln zur Verschlüsselung und Entschlüsselung erstellen, mit diesen einzelne Werte in einer Tabelle codieren sowie Schlüssel in einem Schlüsselsatz rotieren.

Schlüsselsätze

Ein Schlüsselsatz ist eine Sammlung kryptografischer Schlüssel mit einem primären kryptografischen Schlüssel und eventuell vorhandenen sekundären kryptografischen Schlüsseln. Jeder Schlüssel codiert einen Algorithmus zur Verschlüsselung oder Entschlüsselung. Ein Schlüssel kann aktiviert, deaktiviert oder gelöscht sein. Nicht gelöschte Schlüssel codieren sogar Schlüssel-Byte. Der primäre kryptografische Schlüssel gibt an, wie ein eingegebener unverschlüsselter Klartext codiert wird. Dieser primäre kryptografische Schlüssel muss immer aktiviert sein. Sekundäre kryptografische Schlüssel dienen nur der Entschlüsselung und können sowohl aktiviert wie deaktiviert sein. Ein Schlüsselsatz lässt sich zur Entschlüsselung aller Daten verwenden, die damit verschlüsselt wurden.

Ein Schlüsselsatz wird in GoogleSQL als serialisierter google.crypto.tink.Keyset-Protokollzwischenspeicher in BYTES dargestellt.

Beispiel

Im Folgenden finden Sie ein Beispiel für einen AEAD-Schlüsselsatz, der als JSON-String mit drei Schlüsseln dargestellt wird.

{
  "primaryKeyId": 569259624,
  "key": [
    {
      "keyData": {
        "typeUrl": "type.googleapis.com/google.crypto.tink.AesGcmKey",
        "value": "GiDPhTp5gIhfnDb6jfKOT4SmNoriIJc7ah8uRvrCpdNihA==",
        "keyMaterialType": "SYMMETRIC"
      },
      "status": "ENABLED",
      "keyId": 569259624,
      "outputPrefixType": "TINK"
    },
    {
      "keyData": {
        "typeUrl": "type.googleapis.com/google.crypto.tink.AesGcmKey",
        "value": "GiBp6aU2cFbVfTh9dTQ1F0fqM+sGHXc56RDPryjAnzTe2A==",
        "keyMaterialType": "SYMMETRIC"
      },
      "status": "DISABLED",
      "keyId": 852264701,
      "outputPrefixType": "TINK"
    },
    {
      "status": "DESTROYED",
      "keyId": 237910588,
      "outputPrefixType": "TINK"
    }
  ]
}

Im obigen Beispiel hat der primäre kryptografische Schlüssel die ID 569259624. Er ist der erste im JSON-String aufgeführte Schlüssel. Der Schlüsselsatz enthält zwei sekundäre kryptografische Schlüssel, einen deaktivierten mit der ID 852264701 und einen gelöschten mit der ID 237910588. Führt eine AEAD-Verschlüsselungsfunktion mit diesem Schlüsselsatz eine Verschlüsselung durch, codiert der erstellte Geheimtext die ID des primären kryptografischen Schlüssels: 569259624.

Wenn eine AEAD-Funktion diesen Schlüsselsatz zur Entschlüsselung verwendet, wird der entsprechende Schlüssel zur Entschlüsselung auf der Basis der im Geheimtext des obigen Beispiels codierten Schlüssel-ID ausgewählt. Eine Entschlüsselung mit der Schlüssel-ID 852264701 oder 237910588 führt dabei zu einem Fehler, da die Schlüssel-ID 852264701 deaktiviert und die Schlüssel-ID 237910588 gelöscht ist. Damit die Schlüssel-ID 852264701 für die Entschlüsselung verwendet werden kann, muss sie erst aktiviert werden.

Der Schlüsseltyp bestimmt den für diesen Schlüssel verwendeten Verschlüsselungsmodus.

Das mehrmalige Verschlüsseln von Klartext mit dem gleichen Schlüsselsatz gibt in der Regel unterschiedliche Geheimtextwerte aufgrund unterschiedlicher Initialisierungsvektoren (IVs) zurück. Diese werden mithilfe eines von OpenSSL bereitgestellten Pseudozufallszahlengenerators ausgewählt.

Hinweis: Wenn Sie versuchen, Schlüsselsätze im Rahmen von Abfragen in Klartext zu übergeben, wird möglicherweise der Abfragetext und damit auch der Klartextschlüsselsatz in Logs erfasst. Sie können die parametrisierten Abfragen von BigQuery verwenden, um das Logging des Klartextschlüsselsatzes zu verhindern.

Verpackte Schlüsselsätze

Wenn Sie einen Schlüsselsatz sicher verwalten oder über einen nicht vertrauenswürdigen Kanal übertragen müssen, sollten Sie einen verpackten Schlüsselsatz verwenden. Beim Verpacken eines Standard-Schlüsselsatzes wird dieser mit einem Cloud KMS-Schlüssel verschlüsselt.

Verpackte Schlüsselsätze können Daten verschlüsseln und entschlüsseln, ohne die Daten des Schlüsselsatzes offenzulegen. Es kann zwar weitere Möglichkeiten zum Einschränken des Zugriffs auf Daten auf Feldebene geben, aber verpackte Schlüsselsätze bieten im Vergleich zu Standardschlüsselsätzen mehr Sicherheit bei der Schlüsselsatzverwaltung.

Verpackte Schlüsselsätze können und sollten genauso wie Schlüsselsätze regelmäßig rotiert werden. Verpackte Schlüsselsätze werden in AEAD-Envelope-Verschlüsselungsfunktionen verwendet.

Hier einige Beispiele für Funktionen mit verpackten Schlüsselsätzen:

• KEYS.NEW_WRAPPED_KEYSET: Neuen verpackten Schlüsselsatz erstellen.
• KEYS.ROTATE_WRAPPED_KEYSET: Verpackten Schlüsselsatz rotieren.
• KEYS.REWRAP_KEYSET: Verpackten Schlüsselsatz mit neuen Daten neu verpacken.
• KEYS.KEYSET_CHAIN: Tink-Schlüsselsatz abrufen, der mit einem Cloud KMS-Schlüssel verschlüsselt ist.

Advanced Encryption Standard (AES)

Die AEAD-Verschlüsselungsfunktionen verwenden zur Verschlüsselung den Advanced Encryption Standard (AES). Die AES-Verschlüsselung übernimmt den Klartext als Eingabe sowie einen kryptografischen Schlüssel und gibt eine verschlüsselte Byte-Sequenz als Ausgabe zurück. Diese Byte-Sequenz kann später mit dem Schlüssel wieder entschlüsselt werden, mit dem sie verschlüsselt wurde. AES verwendet eine Blockgröße von 16 Byte, d. h., der Klartext wird als eine Sequenz von 16-Byte-Blöcken behandelt. Der erstellte Geheimtext enthält ein Tink-spezifisches Präfix, das den für die Verschlüsselung verwendeten Schlüssel angibt. Die AES-Verschlüsselung unterstützt mehrere Blockchiffriermodi.

Blockchiffriermodi

Die AEAD-Verschlüsselungsfunktionen unterstützen die Blockchiffriermodi GCM und CBC.

GCM-Modus

Der Galois/Counter Mode (GCM) ist ein von der AES-Verschlüsselung unterstützter Modus. Die Funktion nummeriert in diesem Modus die Blöcke fortlaufend und verknüpft diese Blocknummern dann mit einem Initialisierungsvektor (IV). Ein Initialisierungsvektor ist ein Zufalls- oder Pseudozufallswert, der die Basis für die Zufallsgenerierung der Klartextdaten bildet. Als Nächstes verschlüsselt die Funktion die Kombination von Blocknummer und IV mithilfe von AES. Anschließend führt die Funktion eine bitweise logische "exklusives Oder"-Operation (XOR) für dieses Verschlüsselungsergebnis sowie für den Klartext durch und generiert so den Geheimtext. Im GCM-Modus wird ein kryptografischer Schlüssel mit einer Länge von 128 oder 256 Bit verwendet.

CBC-Modus

Im CBC-Modus wird jeder Klartextblock durch eine solche bitweise XOR-Operation mit dem vorherigen Geheimtextblock "verkettet" und danach verschlüsselt. Dieser Modus nutzt einen kryptografischen Schlüssel mit einer Länge von 128, 192 oder 256 Bit. Dabei wird ein 16-Byte-Initialisierungsvektor als Anfangsblock verwendet und eine XOR-Verknüpfung dieses Blocks mit dem ersten Klartextblock ausgeführt.

Der CBC-Modus ist kein AEAD-Schema im kryptografischen Sinn, da es keine Datenintegrität bietet. Mit anderen Worten: Schädliche Änderungen an den verschlüsselten Daten werden nicht erkannt, wodurch die Vertraulichkeit von Daten beeinträchtigt wird. Aus diesem Grund empfiehlt es sich, CBC nur dann zu verwenden, wenn dies aus älteren Gründen erforderlich ist.

Zusätzliche Daten

Die AEAD-Verschlüsselungsfunktionen unterstützen die Verwendung eines additional_data-Arguments. Diese Daten werden auch als "assoziierte Daten" (AD) oder als "zusätzliche authentifizierte Daten" bezeichnet. Ein Geheimtext kann nur entschlüsselt werden, wenn dieselben zusätzlichen Daten, die zum Verschlüsseln verwendet werden, auch für die Entschlüsselung zur Verfügung gestellt werden. Daher können die zusätzlichen Daten verwendet werden, um den Geheimtext an einen Kontext zu binden.

So kann für additional_data beispielsweise die Ausgabe der Umwandlungsfunktion CAST(customer_id AS STRING) verwendet werden, wenn Daten für einen bestimmten Kunden verschlüsselt werden. Damit muss beim Entschlüsseln berücksichtigt werden, dass die Daten zuvor mit der vorgesehenen customer_id verschlüsselt wurden. Zur Entschlüsselung ist dann der gleiche additional_data-Wert erforderlich. Weitere Informationen finden Sie unter RFC 5116.

Entschlüsselung

Die Ausgabe von AEAD.ENCRYPT ist BYTES-Geheimtext. Mit den Funktionen AEAD.DECRYPT_STRING oder AEAD.DECRYPT_BYTES kann dieser Geheimtext entschlüsselt werden. Für diese Funktionen muss ein Schlüsselsatz verwendet werden, der den für die Verschlüsselung eingesetzten Schlüssel enthält. Der Schlüssel muss den Status 'ENABLED' haben. Außerdem müssen die gleichen additional_data-Daten wie bei der Verschlüsselung verwendet werden.

Bei Verwendung des Schlüsselsatzes zur Entschlüsselung wird der entsprechende Schlüssel basierend auf der im Geheimtext codierten Schlüssel-ID ausgewählt.

Die Ausgabe von AEAD.DECRYPT_STRING ist ein Klartext-STRING, während für AEAD.DECRYPT_BYTES Klartext-BYTES ausgegeben werden. Mit AEAD.DECRYPT_STRING kann Geheimtext entschlüsselt werden, der einen STRING-Wert codiert. Mit AEAD.DECRYPT_BYTES lässt sich Geheimtext entschlüsseln, der einen BYTES-Wert codiert. Wenn eine dieser Funktionen zum Entschlüsseln eines Geheimtextes verwendet wird, der nicht den Datentyp der Funktion codiert – z. B. AEAD.DECRYPT_STRING zum Entschlüsseln von Geheimtext, der einen BYTES-Wert codiert –, führt das zu einem unerwarteten Verhalten und eventuell zu einem Fehler.

Schlüsselrotation

Primäres Ziel des Rotierens von Verschlüsselungsschlüsseln ist die Reduzierung der mit einem bestimmten Schlüssel verschlüsselten Datenmenge. Dadurch hat ein potenzieller Angreifer bei missbräuchlicher Nutzung des Schlüssels auf weniger Daten Zugriff.

Für das Rotieren von Schlüsselsätzen muss Folgendes ausgeführt werden:

1. Erstellen eines neuen primären kryptografischen Schlüssels in jedem Schlüsselsatz
2. Entschlüsseln und erneutes Verschlüsseln aller verschlüsselten Daten

Der erste Schritt wird mit der Funktion KEYS.ROTATE_KEYSET oder KEYS.ROTATE_WRAPPED_KEYSET ausgeführt. Dabei wird einem Schlüsselsatz ein neuer primärer kryptografischer Schlüssel hinzugefügt. Der alte primäre kryptografische Schlüssel wird in einen sekundären kryptografischen Schlüssel umgewandelt.

Cloud KMS-Schüssel

GoogleSQL unterstützt AEAD-Verschlüsselungsfunktionen mit Cloud KMS-Schlüsseln, um Ihre Daten zusätzlich zu sichern. Diese zusätzliche Schutzebene verschlüsselt den Datenverschlüsselungsschlüssel (Data Encryption Key, DEK) mit einem Schlüsselverschlüsselungsschlüssel (Key Encryption Key, KEK). Der KEK ist ein symmetrischer Verschlüsselungs-Schlüsselsatz, der sicher im Cloud Key Management Service gespeichert und mit Cloud KMS-Berechtigungen und -Rollen verwaltet wird.

Verwenden Sie beim Ausführen der Abfrage die Funktion KEYS.KEYSET_CHAIN, um den KMS-Ressourcenpfad des KEK und den Geheimtext aus dem verpackten DEK bereitzustellen. BigQuery ruft Cloud KMS auf, um den DEK zu entpacken, und verwendet diesen Schlüssel dann zum Entschlüsseln der Daten in Ihrer Abfrage. Die entpackte Version des DEK wird nur für die Dauer der Abfrage im Arbeitsspeicher gespeichert und dann gelöscht.

Weitere Informationen finden Sie unter SQL-Verschlüsselung auf Spaltenebene mit Cloud KMS-Schlüsseln.