Co to jest Tink?

Tink to biblioteka kryptograficzna typu open source napisana przez kryptografów i inżynierów ds. bezpieczeństwa w Google. Proste i bezpieczne interfejsy API Tink ograniczają typowe błędy dzięki projektowaniu zorientowanemu na użytkownika, starannej implementacji, weryfikacji kodu i obszernym testom. W sekcji Cele na tej stronie znajdziesz więcej informacji o celach, jakie ma osiągnąć Tink.

Tink pomaga użytkownikom bez doświadczenia w dziedzinie kryptografii bezpiecznie implementować typowe zadania kryptograficzne. W Google Tink został wdrożony w setkach usług i systemów.

Dlaczego warto korzystać z Tink?

Najważniejsze powody, dla których warto korzystać z Tink:

  • Prosta obsługa

    Trudno jest znaleźć prawidłową kryptografię. Tink umożliwia szyfrowanie i podpisywanie danych za pomocą wbudowanych gwarancji bezpieczeństwa przy użyciu zaledwie kilku linijek kodu. Tink ułatwia też rotację kluczy lub zabezpieczania kluczy za pomocą zewnętrznych systemów zarządzania kluczami (KMS).

  • Bezpieczeństwo

    Tink dodaje zabezpieczenia do znanych bibliotek, takich jak BoringSSL i Java Cryptography Architecture, oraz pokazuje je bezpośrednio w interfejsach, dzięki czemu audytorzy i narzędzia mogą szybko znajdować luki. Tink rozdziela też potencjalnie niebezpieczne interfejsy i można je monitorować.

  • Jest zgodny

    Teksty szyfrowane Tink są zgodne z istniejącymi bibliotekami kryptograficznymi. Tink obsługuje też szyfrowanie i przechowywanie kluczy w pękach kluczy Amazon KMS, Google Cloud KMS, Android Keystore oraz iOS.

Kto używa Tink?

Z Tink korzysta wiele firm, takich jak Google, Square i Citadel, a także setki klientów Google Cloud i partnerów Google Pay. Tink obsługuje też bibliotekę Jetpack Security, która zabezpiecza wiele popularnych aplikacji na Androida, takich jak Slack, Adidas, AirBnb i Nextdoor.

Cele Tink

Jakie są główne cele Tink w porównaniu z innymi bibliotekami kryptograficznymi i jakie główne mechanizmy wykorzystuje Tink, aby je osiągnąć?

Krótko mówiąc, Tink ma dwa cele:

  1. Promowanie elastyczności kryptograficznej: użytkownicy powinni mieć możliwość łatwego zmieniania kluczy i algorytmów.
  2. Włączanie weryfikacji zabezpieczeń: Tink ma umożliwiać użytkownikom pisanie kodu, którego bezpieczeństwo można sprawdzić lokalnie. W tym celu udostępnia interfejsy dające jasne gwarancje bezpieczeństwa.

Główne mechanizmy, których używa Tink do osiągnięcia tych celów, to:

  1. Tink udostępnia elementy podstawowe i interfejsy jako ważne abstrakcje. Te abstrakcje pozwalają użytkownikom pisać kod, który nie określa dokładnego algorytmu do użycia, a zamiast tego określa oczekiwany sposób zabezpieczeń.
  2. W Tink używane jest pojęcie „zestawu kluczy”, czyli zestawu kluczy powiązanych z danym elementem podstawowym. W efekcie użytkownicy piszą kod, który działa z wieloma kluczami.
  3. W Tink klucze są określane nie tylko przez ich podstawowy materiał, ale także przez algorytm kryptograficzny i wszystkie parametry. Oznacza to, że klucz Tink zawsze wybiera unikalną funkcję kryptograficzną spośród wszystkich możliwych funkcji, więc nie pozostawia miejsca na interpretację.

W poniższych sekcjach opisano te pojęcia bardziej szczegółowo.

Zwinność kryptograficzna

Zachęcam do zapoznania się z książką Inżynieria oprogramowania w Google, która jest książką zdobytą w dziedzinie inżynierii oprogramowania pod tytułem „Lekcje programowania na przestrzeni czasu”. W tej historii autorzy dokładają wszelkich starań, aby zagłębić się w konsekwencje zachodzących zmian. Ten fakt również wpłynął w znacznym stopniu na projekt Tink. W kryptografii ważne jest, aby przygotować się na zmiany. Klucze wyciekną, a algorytmy przestaną działać. Możliwość zmiany kluczy i algorytmów jest dla wielu użytkowników bardzo ważna, dlatego warto się przygotować.

Kontrole bezpieczeństwa i usługi lokalne

Tink promuje korzystanie z interfejsów, takich jak AEAD, które pozwalają użytkownikom szyfrować dane. AEAD to wśród innych gwarancji bezpieczeństwa, które gwarantuje, że wielokrotne zaszyfrowanie tego samego ciągu znaków będzie skutkować różnymi szyframi.

Aby sprawdzić, jak można to wykorzystać, załóżmy, że inżynier chce zapisać wrażliwy identyfikator w pliku cookie użytkownika. Może to być na przykład:

class IdEncrypter {
  public static IdEncrypter createFromAead(Aead aead);

  public String encrypt(long id) throws GeneralSecurityException;
  public long decrypt(String encrypted) throws GeneralSecurityException;
};

Przesłanie żądania Aead zapewnia następujące właściwości:

  1. Kod informuje, że do wykonania swojego zadania IdEncrypter wymaga schematu szyfrowania z właściwościami zabezpieczeń udostępnianymi przez Aead. Z kolei DeterministicAead nie wystarczy – IdEncrypter wymaga, aby 2 szyfrowania o tym samym identyfikatorze były różne. Z drugiej strony przyjęcie jako parametru wystąpienia szyfratora AES GCM (jedno konkretne wystąpienie Aead) byłoby zbyt rygorystyczne – dowolny algorytm Aead wystarczy do wykonania zadania IdEncrypter i nie musi to być jeden konkretny algorytm.
  2. Kontrola bezpieczeństwa może wziąć to pod uwagę. Weryfikator zabezpieczeń nie musi przeglądać całego repozytorium kodu, aby sprawdzić, czy ktoś nie utworzył podklasy Aead, która nie jest bezpieczna do użycia z IdEncrypter. Zamiast tego Tink udostępnia właściwości zabezpieczeń, które mają wszystkie obiekty Aead, a weryfikator może sprawdzić, czy są one wystarczające.

Szczególnie drugi punkt wymaga dużego zaangażowania. Użytkownicy często proszą o dodanie algorytmów, które nie są „dobrymi” obiektami typu Aead. Poprzedni punkt wyjaśnia, dlaczego jest to niebezpieczne: jeśli dostępna jest implementacja Aead, która nie zapewnia wymaganych gwarancji bezpieczeństwa, IdEncrypter może stać się niezabezpieczony, a inżynier przeprowadzający weryfikację bezpieczeństwa będzie musiał sprawdzić dodatkowy kod, aby upewnić się, że wystąpienie obiektu jest prawidłowo utworzone.