Access Control

One goal of Tink is to discourage bad practices. Of particular interest in this section are two points:

  1. Tink encourages usage in such a way that users cannot access secret key material. Instead, secret keys should be stored in a KMS whenever possible using one of the pre-defined ways in which Tink supports such systems.
  2. Tink discourages users from inspecting individual keys in a keyset. Writing code which depends on individual keys often breaks key rotation, and hence goes against a goal of Tink.

In practice, of course both of these principle have to be violated sometimes. For this, Tink provides different mechanisms.

Secret Key Access Tokens

In order to access secret key material, users have to have a token (i.e., an object of a given class without any contents) which is typically provided by a function such as AccessToken insecureSecretKeyAccess(). Within Google, users are prevented from using this function using Bazel BUILD visibility. Outside of Google, we expect that security reviewers will search their code base for usages of this function.

Tink also provides a token for users which only need access to public key material. This function is typically not visibility restricted, and may e.g. be called AccessToken publicKeyAccess().

One useful feature of these tokens is that they can be passed on. For example, suppose we have a function which serializes a key, such as:

String serializeKey(Key key, AccessToken token);

One can then write a function which serializes a complete keyset:

String serializeKeyset(Keyset keyset, AccessToken token);

This function will simply call serializeKey internally and use the passed in token. Users who then call serializeKeyset without the need to serialize secret key material can use publicKeyAccess() as the second argument. Users which have the need to serialize secret key material should use insecureSecretKeyAccess().

Single Key User

Some users may require access to single keys in a keyset. Tink also attempts to limit this because it will often prevent key rotation. The mechanism is more language dependent than for secret key access, because it is usually not necessary to "pass on" tokens for this purpose.

For example, in Java Tink uses RestrictedApi for this.