Đối tượng khoá và tham số

Phần này mô tả thiết kế trong tương lai của Tink. Trạng thái hiện tại có thể phụ thuộc vào ngôn ngữ lập trình được sử dụng.

Trên thực tế, Tink cung cấp các đối tượng Key để biểu thị đối tượng khoá và Parameters để biểu thị Parameters. Ví dụ: trong Java, chúng ta có các đối tượng AesGcmKey để đại diện cho khoá AES GCM.

Trong phần này, chúng tôi sẽ giải thích cách thiết kế các đối tượng này trong Java cũng như cách chúng tương tác.

Đối tượng Parameters

Hãy cân nhắc sử dụng AES GCM, một phương thức mã hoá AEAD được sử dụng rộng rãi. Tink cung cấp cho đối tượng AesGcmParameters thông tin cần thiết để tạo một AesGcmKey mà chúng tôi sẽ giải thích ở phần sau. Hệ phân cấp tham số trong Java có dạng như sau:

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() {...}
}

Như được giải thích trong phần Khoá, thuật toán mật mã gắn thẻ, một số khoá có yêu cầu về mã nhận dạng khi chúng nằm trong bộ khoá. Mỗi Đối tượng Parameters có phương thức hasIdRequirement chỉ định liệu khoá do đối tượng Parameters này tạo sẽ có mã nhận dạng bắt buộc như vậy hoặc không.

Đối tượng AesGcmParameters tiếp theo cung cấp các phương thức getKeySizeBytes(), getIvSizeBytes() và getTagSizeBytes(). Các biến này trả về độ dài của khoá đã sử dụng, độ dài của IV đã sử dụng và độ dài của thẻ được tạo, tính bằng byte. Mặc dù Tink cung cấp một số chức năng sau để đảm bảo tính hoàn chỉnh, nhưng không phải lúc nào cũng cho phép tạo Aead cho mọi lựa chọn. Ví dụ: hiện tại chỉ hỗ trợ IV 12 byte cho AES GCM.

Đối tượng AesGcmParameters cũng cung cấp cơ chế ghi đè cho các phương thức đã xác định (và các phương thức chuẩn Java equals và hashCode và đây được coi là một phương pháp hay).

Cuối cùng, lớp này cung cấp các phương thức tĩnh để tạo đối tượng AeadParameters mới. Các trình mô phỏng này xác thực dữ liệu đầu vào, tức là kiểm tra để chắc chắn rằng kích thước là một trong các giá trị 16, 24, hoặc 32.

Đối tượng khoá

Tink cũng có một hệ phân cấp khoá. Có vẻ như còn lại với ví dụ về AES GCM của chúng tôi như sau:

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);
}

Phương thức getIdRequirementOrNull trả về mã nhận dạng mà khoá này cần có, hoặc null nếu không có yêu cầu. (Yêu cầu như vậy đối với khoá xuất phát từ việc Tink trong một số trường hợp tiền tố mật mã hoặc chữ ký có chuỗi 0x01<id>, hãy xem phần vào tính năng gắn thẻ văn bản mật mã).

Điều này sẽ luôn phù hợp với kết quả của getParameters().hasIdRequirement() và những người triển khai mới các lớp chính cần đảm bảo điều này.

Việc triển khai Key cũng cần cung cấp một phương thức equalsKey để so sánh các khoá khác nhau. Chẳng hạn một phương thức thường hữu ích: chẳng hạn như khi kiểm tra dẫn xuất khoá, một là muốn đảm bảo rằng việc áp dụng lặp lại các đạo hàm sẽ mang lại cùng một đối tượng khoá. Ngoài ra, KMS có thể muốn kiểm tra xem có bất kỳ khoá nào mà nó cung cấp cho những người dùng khác nhau là như nhau (điều này xảy ra đôi khi nếu người dùng chia sẻ khoá và tải các khoá đó lên cùng một KMS nhiều lần). Một điều đáng chú ý là chúng tôi không ghi đè phương thức Java equals, vì việc này sẽ yêu cầu chúng ta ghi đè hashCode và không có cách nào để triển khai hashCode một cách an toàn tương thích với equals mà không cần đưa ra các giả định chưa được chứng minh.

Tiếp theo, chúng ta yêu cầu một phương thức getParameters(). Điều này cho phép người dùng nhận được thông tin ban đầu về các Tham số được dùng để tạo khoá.

Cuối cùng, AesGcmKey có một phương thức getKeyBytes trả về tài liệu khoá thô. Các phương thức như vậy rất điển hình cho các lớp chính: chúng dành riêng cho từng loại, và cung cấp quyền truy cập vào tài liệu khoá cơ bản. Nhờ vậy, người dùng có thể, ví dụ: triển khai dữ liệu gốc được biểu thị bằng khoá, hoặc chuyển đổi tuần tự khoá để lưu trữ trên ổ đĩa hoặc gửi qua mạng. Bản thân khoá chịu trách nhiệm bảo vệ nội dung khoá khỏi truy cập trái phép. Ví dụ: SecretBytes yêu cầu mã truy cập để thực sự cung cấp tài liệu (xem phần Kiểm soát quyền truy cập).

Phím bất đối xứng

Đối với dữ liệu gốc bất đối xứng, Tink sử dụng hai lớp Khoá, một lớp riêng tư và một lớp cho khoá công khai. Đối với các Tham số, việc sử dụng cùng một tham số sẽ thuận tiện hơn class (vì chỉ có một lớp có thể dùng để tạo khoá).

Tink cũng có giao diện PrivateKey với tính năng hàm getPublicKey().