Tink 的一个目标是反对错误做法。本部分尤其值得关注的是两点：
- Tink 鼓励用户以一种用户无法访问密钥材料的方式使用密钥材料。相反，应尽可能使用 Tink 支持此类系统的一种预定义方式将密钥存储在 KMS 中。
- Tink 会阻止用户访问密钥的某些部分，因为这样做通常会导致兼容性 bug。
当然，在实际操作中，有时必须同时违反这两项原则。 为此，Tink 提供了不同的机制。
密钥访问令牌
为了访问密钥材料，用户必须具备令牌（通常只是某个类的对象，而没有任何功能）。令牌通常由 InsecureSecretKeyAccess.get() 等方法提供。在 Google 中，系统通过 Bazel BUILD 可见性阻止用户使用此功能。在 Google 之外，安全审核人员可以在代码库中搜索此函数的使用情况。
这些令牌的一个实用功能是它们可以传递。例如，假设您有一个用于序列化任意 Tink 键的函数：
String serializeKey(Key key, @Nullable SecretKeyAccess secretKeyAccess);
对于包含密钥材料的密钥，此函数要求 secretKeyAccess 对象为非 null 值，并且存储了实际的 SecretKeyAccess 令牌。对于不包含任何密钥材料的密钥，系统会忽略 secretKeyAccess。
有了这样的函数，您可以编写一个对整个密钥集进行序列化的函数：String seriesizeKeyset(KeysetHandle keyset, @Nullable SecretKeyAccess secretKeyAccess);
此函数在内部针对密钥集中的每个按键调用 serializeKey，并将指定的 secretKeyAccess 传递给底层函数。如果用户随后调用 serializeKeyset 而无需序列化密钥材料，则可以使用 null 作为第二个参数。需要序列化密钥材料的用户需要使用 InsecureSecretKeyAccess.get()。
访问密钥的某些部分
一个相对常见的安全错误是“密钥重用攻击”。如果用户在两种不同的设置（例如，用于计算签名和加密）中重复使用 RSA 密钥的模数 n 以及指数 d 和 e，则会发生这种情况1。
处理加密密钥时，另一个相对常见的错误是指定密钥的一部分，然后“假定”元数据。例如，假设用户想要从 Tink 导出 RSASSA-PSS 公钥以与其他库一起使用。在 Tink 中，这些键包含以下几个部分：
- 模数
n - 公开指数
e - 在内部使用的两个哈希函数的规范
- 算法内部使用的盐的长度。
导出此类密钥时，您可能会忽略哈希函数和盐长度。这通常效果很好，因为其他库通常不需要哈希函数（例如，只需假设使用了 SHA256），并且 Tink 中使用的哈希函数恰好与其他库中所用的哈希函数相同（或者，哈希函数可能是专门选择的，以便与其他库搭配使用）。
不过，忽略哈希函数可能会是一个代价高昂的错误。为此，我们假设稍后向 Tink 密钥集添加了一个具有不同哈希函数的新密钥。然后，假设通过该方法导出密钥，并将其提供给业务合作伙伴，由业务合作伙伴将其与另一个库搭配使用。Tink 现在采用不同的内部哈希函数，并且无法验证签名。
在这种情况下，如果哈希函数与其他库的预期不符，导出密钥的函数应该会失败；否则，导出的密钥将毫无用处，因为它会创建不兼容的密文或签名。
为了防止出现此类错误，Tink 对符合以下条件的函数进行了限制：只能访问部分密钥材料，但可能会被误认为是完整密钥。例如，在 Java 中，Tink 使用 RestrictedApi 实现。
当用户使用此类注释时，他们要负责防范密钥重用攻击和不兼容性。
最佳实践：在导入密钥时尽早使用 Tink 对象
在从 Tink 导出密钥或将密钥导入 Tink 时，您最常遇到受“部分密钥访问”限制的方法。
这样可以最大限度地降低密钥混淆攻击的风险，因为 Tink 密钥对象会完全指定正确的算法，并将所有元数据与密钥材料一起存储。
请参考以下示例：
非类型化用法：
void verifyEcdsaSignature(ECPoint ecPoint, byte[] signature, byte[] message)
throws Exception {
EcdsaParameters parameters =
EcdsaParameters.builder()
.setSignatureEncoding(EcdsaParameters.SignatureEncoding.IEEE_P1363)
.setCurveType(EcdsaParameters.CurveType.NIST_P256)
.setHashType(EcdsaParameters.HashType.SHA256)
.setVariant(EcdsaParameters.Variant.NO_PREFIX)
.build();
EcdsaPublicKey key =
EcdsaPublicKey.builder()
.setParameters(parameters)
.setPublicPoint(ecPoint)
.build();
KeysetHandle handle = KeysetHandle.newBuilder()
.addEntry(KeysetHandle.importKey(key).withFixedId(1).makePrimary())
.build();
PublicKeyVerify publicKeyVerify = handle.getPrimitive(PublicKeyVerify.class);
publicKeyVerify.verify(signature, message);
}
这容易出错：在调用点，很容易忘记，绝不可以将同一 ecPoint 用于其他算法。例如，如果存在名为 encryptWithECHybridEncrypt 的类似函数，调用方可能会使用相同的曲线点来加密消息，而这很容易导致漏洞。
更好的做法是更改 verifyEcdsaSignature，使第一个参数为 EcdsaPublicKey。事实上，每当从磁盘或网络中读取密钥时，都应立即将其转换为 EcdsaPublicKey 对象：此时，您已经知道密钥的使用方式，因此最好向它提交密钥。
上述代码还可以进一步改进。最好是传入 KeysetHandle，而不是传入 EcdsaPublicKey。它可以为密钥轮替准备代码，而无需执行任何额外的操作。因此，最好使用该方法。
不过，还没有完成改进：最好传入 PublicKeyVerify 对象：这对此函数来说已经足够，因此传入 PublicKeyVerify 对象可能会增加此函数的适用位置。不过，此时该函数变得相当简单，可以内联。
建议：首次从磁盘或网络中读取密钥材料时，请尽快创建相应的 Tink 对象。
类型化用法：
KeysetHandle readEcdsaKeyFromFile(Path fileWithEcdsaKey) throws Exception {
byte[] content = Files.readAllBytes(fileWithEcdsaKey);
BigInteger x = new BigInteger(1, Arrays.copyOfRange(content, 0, 32));
BigInteger y = new BigInteger(1, Arrays.copyOfRange(content, 32, 64));
ECPoint point = new ECPoint(x, y);
EcdsaParameters parameters =
EcdsaParameters.builder()
.setSignatureEncoding(EcdsaParameters.SignatureEncoding.IEEE_P1363)
.setCurveType(EcdsaParameters.CurveType.NIST_P256)
.setHashType(EcdsaParameters.HashType.SHA256)
.setVariant(EcdsaParameters.Variant.NO_PREFIX)
.build();
EcdsaPublicKey key =
EcdsaPublicKey.builder()
.setParameters(parameters)
.setPublicPoint(ecPoint)
.build();
return KeysetHandle.newBuilder()
.addEntry(KeysetHandle.importKey(key).withFixedId(1).makePrimary())
.build();
}
使用此类代码，我们在读取该字节数组时会立即将其转换为 Tink 对象，并完全指定应使用什么算法。这种方法可最大限度地降低发生密钥混淆攻击的可能性。
最佳实践：在导出密钥时验证所有参数
例如，如果您编写一个导出 HPKE 公钥的函数：
导出公钥的不良方法：
/** Provide the key to our users which do not have Tink. */
byte[] exportTinkHpkeKey(HpkePublicKey key) {
return key.getPublicKeyBytes().toByteArray();
}
这就存在问题。收到密钥后，使用它的第三方会对密钥的参数做出一些假设：例如，它会假设用于 256 位密钥的 HPKE AEAD 算法是 AES-GCM，依此类推。
建议：请验证参数是否符合您的密钥导出预期。
导出公钥的更好方法：
/** Provide the key to our users which do not have Tink. */
byte[] exportTinkHpkeKeyForOurUsers(HpkePublicKey key) {
// Our users assume we use KEM_P256_HKDF_SHA256 for the KEM.
if (!key.getParameters().getKemId().equals(HpkeParameters.KemId.KEM_P256_HKDF_SHA256)) {
throw new IllegalArgumentException("Bad parameters");
}
// Our users assume we use HKDF SHA256 to create the key material.
if (!key.getParameters().getKdfId().equals(HpkeParameters.KdfId.HKDF_SHA256)) {
throw new IllegalArgumentException("Bad parameters");
}
// Our users assume that we use AES GCM with 256 bit keys.
if (!key.getParameters().getAeadId().equals(HpkeParameters.AeadId.AES_256_GCM)) {
throw new IllegalArgumentException("Bad parameters");
}
// Our users assume we follow the standard and do not add a Tink style prefix
if (!key.getParameters().getVariant().equals(HpkeParameters.Variant.NO_PREFIX)) {
throw new IllegalArgumentException("Bad parameters");
}
return key.getPublicKeyBytes().toByteArray();
}