Schlüssel- und Parameterobjekte

In der Praxis stellt Tink Key-Objekte zur Darstellung von Schlüsseln und Parameters-Objekte zur Darstellung von Parameters bereit. In Java haben wir beispielsweise AesGcmKey-Objekte, um AES GCM-Schlüssel darzustellen.

In diesem Abschnitt wird erläutert, wie diese Objekte in Java entworfen werden und wie sie interagieren.

Parameters-Objekte

Sehen wir uns AES GCM an, ein weit verbreitetes AEAD-Verschlüsselungsschema. Tink stellt ein AesGcmParameters-Objekt mit den erforderlichen Informationen bereit, um ein AesGcmKey zu erstellen. Dies wird später erläutert. Die Parameterhierarchie in Java sieht so aus:

public abstract class Parameters {
  public abstract boolean hasIdRequirement();
}

public abstract class AeadParameters extends Parameters {}

public final class AesGcmParameters extends AeadParameters {
  /**
   * The Variant specified how ciphertexts are [tagged](/tink/design/keysets#tagging_ciphertexts).
   */
  public static final class Variant {...}
  /** A helper object to create new AesGcmParameters. */
  public static final class Builder {...}

  public int getKeySizeBytes() {...}
  public int getIvSizeBytes() {...}
  public int getTagSizeBytes() {...}

  public Variant getVariant() {...}

  public OutputPrefixType getOutputPrefixType() {...}
  public boolean equals(Object object) {...}
  public int hashCode() {...}
}

Wie im Abschnitt Schlüsselsätze, Verschlüsselungstexte taggen erläutert, gilt für einige Schlüssel eine Anforderung hinsichtlich ihrer ID, wenn sie sich in einem Schlüsselsatz befinden. Jedes Parameters-Objekt hat eine hasIdRequirement-Methode, die angibt, ob der von diesem Parameters-Objekt erstellte Schlüssel eine solche erforderliche ID hat oder nicht.

Das AesGcmParameters-Objekt stellt als Nächstes die Methoden getKeySizeBytes(), getIvSizeBytes() und getTagSizeBytes() bereit. Diese geben die Länge des verwendeten Schlüssels, die Länge der verwendeten IV und die Länge des erzeugten Tags in Byte zurück. Tink bietet zwar einige dieser Funktionen der Vollständigkeit halber, ermöglicht jedoch nicht immer das Erstellen von Aeads für jede Auswahl. Zum Beispiel werden derzeit nur 12-Byte-IVs für AES GCM unterstützt.

Das Objekt AesGcmParameters bietet auch Überschreibungen für die zuvor definierten Methoden (sowie die Java-Standardmethoden equals und hashCode, die als bewährte Methoden angesehen werden).

Außerdem stehen statische Methoden zum Erstellen neuer AeadParameters-Objekte zur Verfügung. Diese validieren die Eingaben, d.h. sie prüfen, ob die Größe 16, 24 oder 32 ist.

Schlüsselobjekte

Tink hat auch eine Schlüsselhierarchie. Bei unserem AES GCM-Beispiel sieht es so aus:

public abstract class Key {
  public abstract Parameters getParameters();
  public abstract @Nullable Integer getIdRequirementOrNull();
  public abstract boolean equalsKey(Key other);
}

public abstract class AeadKey extends Key {
  public abstract AeadParameters getParameters();
  public abstract Bytes getOutputPrefix();
}

public final class AesGcmKey implements AeadKey {
  public SecretBytes getKeyBytes();
  public abstract Bytes getOutputPrefix();
  public AesGcmParameters getParameters();
  public @Nullable Integer getIdRequirementOrNull();
  public boolean equalsKey(Key object);
}

Die Methode getIdRequirementOrNull gibt die ID zurück, die dieser Schlüssel benötigt, oder null, wenn es nicht erforderlich ist. Eine solche Anforderung an den Schlüssel ergibt sich aus der Tatsache, dass Tink in einigen Fällen Geheimtexten oder Signaturen den String 0x01<id> vorangestellt hat. Weitere Informationen finden Sie im Abschnitt zum Taggen von Geheimtexten.

Dies entspricht immer dem Ergebnis von getParameters().hasIdRequirement() und Implementierer neuer Schlüsselklassen müssen dies gewährleisten.

Implementierungen von Key müssen außerdem eine equalsKey-Methode bereitstellen, um verschiedene Schlüssel zu vergleichen. Eine solche Methode ist häufig nützlich: Wenn Sie beispielsweise die Schlüsselableitung testen, möchten Sie sicherstellen, dass eine wiederholte Anwendung der Ableitung dasselbe Schlüsselobjekt liefert. Außerdem kann ein KMS überprüfen, ob einer der Schlüssel, die er verschiedenen Nutzern zur Verfügung stellt, identisch sind. Dies kann vorkommen, wenn Nutzer Schlüssel freigeben und sie mehrmals in denselben KMS hochladen. Beachten Sie, dass die Java-Methode equals nicht überschrieben wird, da dies die Überschreibung von hashCode erfordern würde und es keine Möglichkeit gibt, hashCode auf sichere Weise zu implementieren, die mit equals kompatibel ist, ohne unbewiesene Annahmen anzustellen.

Als Nächstes ist die Methode getParameters() erforderlich. Auf diese Weise erhalten Nutzer die ursprünglichen Informationen zu den Parametern, mit denen der Schlüssel erstellt wurde.

Schließlich verfügt AesGcmKey über die Methode getKeyBytes, die das Rohschlüsselmaterial zurückgibt. Solche Methoden sind sehr typisch für Schlüsselklassen: Sie sind typspezifisch und bieten Zugriff auf das zugrunde liegende Schlüsselmaterial. Damit können Nutzer im Prinzip z.B. die durch den Schlüssel dargestellte Primitive implementieren oder den Schlüssel serialisieren, um ihn auf der Festplatte zu speichern oder über das Netzwerk zu senden. Der Schlüssel selbst ist für den Schutz des Schlüsselmaterials vor unbefugtem Zugriff verantwortlich. Beispielsweise benötigt SecretBytes ein Zugriffstoken, um das Material tatsächlich bereitzustellen (siehe Zugriffssteuerung).

Asymmetrische Schlüssel

Für asymmetrische Primitive verwendet Tink zwei Schlüsselklassen, eine für private und eine für öffentliche Schlüssel. Für die Parameter ist es praktischer, dieselbe Klasse zu verwenden (da es nur eine Klasse gibt, die zum Generieren der Schlüssel verwendet werden kann).

Tink hat auch die Schnittstelle PrivateKey mit der zusätzlichen Funktion getPublicKey().