Tink to biblioteka kryptograficzna typu open source napisana przez twórców kryptografii, wśród inżynierów zabezpieczeń w Google. Bezpieczne i proste interfejsy API Tink ograniczają typowe związane z projektowaniem zorientowanym na użytkownika, dokładną implementacją i weryfikacją kodu. i szczegółowe testy. W sekcji Cele na tej stronie znajdziesz informacje więcej informacji o celach, które miał osiągnąć Tink.
Tink pomaga użytkownikom bez tła kryptograficznego bezpiecznie wdrażać typowe rozwiązania i zadania kryptograficzne. W Google firma Tink została wdrożona w setkach usług i systemami.
Dlaczego warto używać biblioteki Tink?
Najważniejsze powody, dla których warto używać biblioteki Tink, to:
Prosta obsługa
Trudno jest uzyskać poprawny obraz kryptografii. Dzięki Tink możesz: szyfrować lub podpisywać dane za pomocą z wbudowanymi zabezpieczeniami za pomocą zaledwie kilku linijek kodu. Tink także pomagają w rotacji kluczy lub zabezpieczaniu kluczy przy użyciu zewnętrznych systemów zarządzania kluczami (KMS) (KMS).
Jest bezpieczna
Tink dodaje zabezpieczenia do znanych bibliotek, takich jak BoringSSL oraz Java Cryptography Architecture i pokazuje je bezpośrednio w interfejsach, aby umożliwić audytorom i narzędziom szybkie wyszukiwanie luk. Tink oddziela też interfejsy API, które mogą być niebezpieczne, więc warto je monitorować.
Jest zgodny
Mechanizmy szyfrowania Tink są zgodne z dotychczasowymi bibliotekami kryptograficznymi. Tink obsługuje też szyfrowanie i przechowywanie kluczy w Amazon KMS, Google Cloud KMS, magazyn kluczy Androida i pęk kluczy iOS.
Kto używa Tink?
Tink jest powszechnie używany przez wiele firm, w tym Google, Square i Citadel, a także setkami klientów Google Cloud i partnerów Google Pay. Pokaż też jest wykorzystywane w bibliotece zabezpieczeń Jetpack, która zabezpiecza wiele popularnych aplikacji na Androida. takich jak Slack, Adidas, AirBnb czy Nextdoor.
Bramki Tink
Jakie są główne cele Tink w porównaniu z innymi bibliotekami kryptograficznymi? Jakich głównych mechanizmów używa Tink, aby osiągnąć te cele?
Krótko mówiąc, Tink ma dwa cele:
- Zadbaj o elastyczność kryptograficzną: użytkownicy powinni mieć możliwość zmieniania kluczy i do algorytmów.
- Włącz kontrole zabezpieczeń: Tink umożliwia użytkownikom pisanie kodu, którego bezpieczeństwo można sprawdzić lokalnie za pomocą interfejsów, które jasno określają, gwarancje bezpieczeństwa.
Główne mechanizmy, których używa Tink do osiągnięcia tych celów, to:
- Tink zawiera elementy podstawowe i interfejsy jako ważne abstrakcje. Te abstrakcje umożliwiają użytkownikom pisanie kodu, który nie określa dokładnej algorytm, ale zamiast tego określa oczekiwane pojęcie zabezpieczeń.
- Tink wykorzystuje pojęcie „zbioru kluczy”, czyli zestawu kluczy, które są wykorzystywane powiązane z konkretnym elementem podstawowym. Powoduje to, że użytkownicy piszą kod który działa z wieloma klawiszami.
- W Tink klucze są określane nie tylko przez materiał klucza, algorytm kryptograficzny i wszystkie parametry. Oznacza to, że klucz Tink zawsze wybiera unikalną funkcję kryptograficzną spośród wszystkich możliwych które mogą istnieć i nie pozostawiają miejsca na interpretację.
W sekcjach poniżej znajdziesz więcej informacji na temat tych pojęć.
Elastyczność kryptograficzna
Weź pod uwagę inżynierię oprogramowania w Google, książkę z lekcjami z dziedziny inżynierii oprogramowania, podtytuł „Wnioski z programowania na przestrzeni czasu”. Autorzy przedstawiają w nim usiłując przedstawić konsekwencje zmian, które zachodzą. Ten miał też duży wpływ na projekt Tink. W kryptografii ważne jest, przygotowując się na zmiany. Klucze wyciekną, a algorytmy – uszkodzone. Możliwość odłączenia kluczy i algorytmów ma kluczowe znaczenie dla wielu użytkowników. jest rozsądna.
Kontrole bezpieczeństwa i właściwości lokalne
Tink promuje korzystanie z takich interfejsów, jak np. AEAD, zaszyfrowanie danych. Wśród innych gwarancji bezpieczeństwa AEAD gwarantuje, że wiele szyfrowania tego samego ciągu spowoduje uzyskanie różnych tekstów szyfrowanych.
Aby zobaczyć, jak można je wykorzystać, załóżmy, że inżynier chce przechowywać poufne identyfikator w pliku cookie użytkownika. Mogą one utworzyć takie zajęcia:
class IdEncrypter {
public static IdEncrypter createFromAead(Aead aead);
public String encrypt(long id) throws GeneralSecurityException;
public long decrypt(String encrypted) throws GeneralSecurityException;
};
Zdanie Aead
skutkuje tymi właściwościami:
- Kod informuje, że do wykonania swojego zadania
IdEncrypter
wymaga schematu szyfrowania z właściwościami zabezpieczeń dostępnymi wAead
. EwentualnieDeterministicAead
to za mało –IdEncrypter
wymaga dwóch szyfrów są takie same. Z drugiej strony, biorąc jako parametr wystąpienie szyfrowanie GCM AES (jedna konkretna instancja instancjiAead
) byłoby zbyt ścisła: każdy składnik Aead wystarczy, abyIdEncrypter
wykonał swoje zadania, i nie musi stosować jeden konkretny algorytm. - Kontrola bezpieczeństwa może to wziąć pod uwagę. Kontroler bezpieczeństwa
nie trzeba przeglądać całego repozytorium kodu, aby sprawdzić,
ktoś utworzył podklasę
Aead
, która nie jest bezpieczna w użyciu dziękiIdEncrypter
. Zamiast tego Tink udostępnia właściwości zabezpieczeń, które Obiekty Aead mają i weryfikator może sprawdzić, czy są one wystarczające.
Szczególnie ostrożny jest zwłaszcza drugi punkt. Użytkownicy często proszą o dodanie
które są „niezupełnie” Aead
. W poprzednim punkcie wyjaśniamy, dlaczego
to jest niebezpieczne: jeśli jest dostępna implementacja Aead
, która
nie wykona wymaganych gwarancji bezpieczeństwa, IdEncrypter
może stać się niezabezpieczony,
a inżynier przeprowadzający kontrolę zabezpieczeń musi zbadać dodatkowy kod
aby sprawdzić, czy obiekt został poprawnie utworzony.