Usługa Google Cloud Key Vault

Opisujemy usługę w chmurze, która korzysta z bezpiecznego sprzętu do przechowywania kluczy kryptograficznych, a dostęp do nich jest zabezpieczony niską entropią (np. kodem PIN ekranu blokady). Bezpieczny sprzęt został zaprojektowany tak, aby zapobiegać atakom brute-force, ponieważ po zbyt wielu nieudanych próbach dostarczenia zapisanych kluczy kryptograficznych zapisane klucze kryptograficzne są nieodwracalne.

Autor: Shabsi Walfish
Data wersji: 2018-03-06

Uwaga: ten dokument jest nadal w trakcie opracowywania, a szczegóły implementacji nie są jeszcze gotowe. Gdy system się ustabilizuje i zdobędzie więcej dokumentacji, zaktualizujemy ten dokument, dodając bardziej szczegółowe informacje (w szczególności w połączeniu z odpowiednimi wersjami open source).

Przegląd

Tradycyjnie szyfrowanie (używane do zapewnienia prywatności danych) wymaga stosowania obiektów tajnych z dużą entropią z punktu widzenia atakującego. Wymagana jest wysoka entropia, ponieważ schemat szyfrowania musi powstrzymać ataki brute force, które obejmują przestrzeń wszystkich prawdopodobnych sekretów, dopóki nie zostanie znaleziony właściwy. Biorąc pod uwagę dzisiejszą dostępność mocy obliczeniowej, rozsądne minimalne wymaganie dotyczące entropii dla obiektów tajnych kryptograficznych może wynosić od 70 do 80 bitów. Ludzie mają trudności z zapamiętaniem i niezawodnym hasłem oraz innymi tajemnicami z taką ilością entropii¹, zwłaszcza jeśli są one rzadko używane (ale częste korzystanie z hasła o wysokiej entropii jest trudne i uciążliwe). Pozostaje pewien problem: jak możemy chronić prywatne dane przy użyciu technologii szyfrowania, jeśli chcemy, aby sekret ten pozostawał „czynnikiem wiedzy”, o którym użytkownik z dużym prawdopodobieństwem zapadnie w pamięć? Problem ten jest tak trudny do rozwiązania z różnych powodów, że usługi Cloud Storage zazwyczaj szyfrują dane tylko za pomocą obiektów tajnych zarządzanych przez samego dostawcę Cloud Storage, zamiast polegać na zapamiętywaniu własnego obiektu tajnego przez użytkownika.

Jednym ze sposobów na zniwelowanie wymagań dotyczących obiektów tajnych kryptograficznych i ludzkich obiektów tajnych zapadających w pamięć jest użycie usługi Cloud Key Vault (CKV) do przechowywania „klucza odzyskiwania” o wysokiej entropii chronionego przez pamiętny obiekt tajny o niskiej entropii. Usługa CKV udostępni klucz odzyskiwania tylko tym podmiotom, które udowodnią znajomość poprawnego, zapadającego w pamięć obiektu tajnego. Ataki brute-force na ludzki obiekt tajny, który można łatwo zapamiętać, mogą zostać udane przez usługę CKV, która wymusi bezwzględną liczbę nieudanych prób potwierdzenia znajomości obiektu tajnego. Sam klucz odzyskiwania jest standardowym kluczem kryptograficznym symetrycznym, odpowiednim do zastosowania (uwierzytelniony) schemat szyfrowania, który może łatwo szyfrować duże ilości danych (np. kopię zapasową dysku), które można bezpiecznie przechowywać w dowolnym miejscu. Takie zaszyfrowane dane są bezużyteczne dla osób, które nie mogą uzyskać klucza odzyskiwania.

W tym dokumencie opisujemy nasze podejście do tworzenia usługi Cloud Key Vault z użyciem zaufanych modułów sprzętowych (THM). Pierwsza implementacja usługi CKV została zaprojektowana tak, aby chronić klucze odzyskiwania za pomocą współczynnika wiedzy ekranu blokady (LSKF) – tajnego kodu PIN, hasła lub wzoru, które pozwalają odblokowywać smartfony. Ludzie są w stanie niezawodnie zapamiętać swoją wartość LSKF. Jednocześnie takie obiekty tajne LSKF zwykle mają wystarczająco dużo entropii, aby oprzeć atakującego, który ma bardzo ograniczoną liczbę prób, więc dobrze nadają się do usługi CKV.

Pierwszą aplikacją naszej usługi Cloud Key Vault będzie włączenie kopii zapasowych Androida zaszyfrowanych po stronie klienta. Wcześniej pliki zaszyfrowane lokalnie na urządzeniu z Androidem korzystały z klucza chronionego za pomocą LSKF użytkownika, ale kopie zapasowe tych plików przechowywane (i zaszyfrowane) w chmurze nie były chronione przez LSKF. Cloud Key Vault po raz pierwszy włącza też ochronę ekranu blokady dla kopii zapasowych Androida przechowywanych w chmurze. Oznacza to, że serwery Google nie mają możliwości dostępu do zaszyfrowanych kopii zapasowych ani ich przywrócenia. Tylko urządzenie z szyfrowaniem LSKF użytkownika może je odszyfrować.

Podstawowe pojęcia

Początkowo jedyną obsługiwaną platformą kliencką dla usługi Cloud Key Vault jest system operacyjny Android 9 Pie. W tym dokumencie mamy na myśli urządzenie z systemem operacyjnym Android 9 Pie i Usługami Google Play. Nasza implementacja po stronie serwera działa na specjalnie wyznaczonych serwerach Google, które mają zainstalowany dodatkowy układ Titan². Zaprojektowany przez Google układ Titan służy jako komponent sprzętowy naszego zaufanego modułu sprzętowego. Udostępniamy go w postaci niestandardowego programu rozruchowego oraz oprogramowania układowego, które implementuje nasze protokoły oraz mechanizmy egzekwowania bezpieczeństwa (jak opisano w tym dokumencie). Korzystamy z technik atestacji sprzętowej, by mieć pewność, że nasz protokół naprawdę działa na sprzęcie Titan.

Usługa CKV musi być skalowana, aby obsłużyć ruch z miliardów³ urządzeń z Androidem, nie tracąc znaczącej ilości danych użytkownika z powodu awarii sprzętu (np. wypalonych układów scalonych) ani dłuższych przerw w działaniu usługi spowodowanych konserwacją centrum danych. Z tego powodu serwery z układami Titan są podzielone na kohorty, w których każda kohorta składa się z kilku niezależnych THM, z których każdy zawiera kopię tego samego materiału klucza. Dana kohorta zostanie rozdzielona między fizycznie odmienne centra danych w różnych strefach konserwacji, aby system mógł osiągnąć cele w zakresie dostępności i niezawodności. Dla skalowalności klienci zostaną podzieleni na różne kohorty, co pozwoli nam dostosować wydajność usługi przez dodanie kolejnych serwerów w celu zwiększenia liczby dostępnych kohort.

Możemy teraz wymienić główne komponenty architektury usługi Cloud Key Vault.

Komponenty architektoniczne / słowniczek

Czynnik wiedzy na ekranie blokady: tajny klucz, który można zapamiętać, na przykład krótki kod PIN, wzór przesunięcia palcem po siatce 3 x 3 kropki lub hasło. Ten obiekt tajny służy do ochrony możliwości lokalnego odblokowywania urządzenia i jest uważany za główny (lub „silny”) czynnik uwierzytelniania w przypadku lokalnej blokady ekranu urządzenia użytkownika.

Klient: urządzenie użytkownika z systemem operacyjnym Android 9 Pie i Usługami Google Play lub podobnym oprogramowaniem.

Android Framework: używamy tego ogólnego terminu (lub platformy) w odniesieniu do interfejsów API Androida 9 Pie lub nowszego. Nie odnosi się on do wcześniejszych wersji.

Usługi Google Play: zbiór usług i aplikacji działających na urządzeniu użytkownika, które umożliwiają współpracę z systemem kont Google i niestandardowymi interfejsami API serwera.

Agent przywracania: aplikacja systemowa działająca w ramach Usług Google Play w przestrzeni użytkownika na urządzeniu z Androidem 9 Pie (lub podobnym). Agent przywracania jest odpowiedzialny za uruchamianie różnych protokołów po stronie klienta oraz za współpracę z systemem operacyjnym Android w razie potrzeby w celu utworzenia komunikatów protokołu obejmujących LSKF.

Żądanie odzyskiwania: jeśli użytkownik chce odzyskać klucz odzyskiwania, musi utworzyć zgłoszenie odzyskiwania obejmujące zaszyfrowaną kopię pliku LSKF, którą użytkownik deklaruje, że ma ją znać. Zwykle użytkownik będzie musiał podać numer LSKF ze starego urządzenia na nowym urządzeniu, które próbuje uzyskać dostęp do klucza odzyskiwania starego.

Klucz odzyskiwania: tajny klucz kryptograficzny, który jest chroniony przez usługę Cloud Key Vault i służy do szyfrowania (i uwierzytelniania) danych na urządzeniu klienckim. Po umieszczeniu klucza odzyskiwania w Vault (patrz poniżej) jego kopię lokalną można usunąć, gdy tylko klient przestanie używać jej do szyfrowania danych.

Usługa Cloud Key Vault (CKV): usługa internetowa, która umożliwia urządzeniom klienckim przechowywanie kluczy kryptograficznych chronionych za pomocą LSKF możliwej do zapamiętania przez człowieka.

Kohorta: zbiór serwerów/THM, które mogą służyć jako nadmiarowe repliki siebie nawzajem.

Klucz publiczny kohorty: klucz publiczny z pary kluczy wygenerowany przez konkretną kohortę THM. Odpowiedni klucz prywatny jest dostępny tylko w plikach THM, które znajdowały się w kohortie w momencie generowania klucza.

Trusted Hardware Module (THM): specjalny moduł zabezpieczeń (mikrokontroler) zaprojektowany tak, aby stworzyć minimalistyczne i wiarygodne środowisko obliczeniowe. Element bezpieczny musi być co najmniej w stanie generować lub przechowywać klucze tajne oraz utrzymywać pewien nieulotny stan ewolucji (aby zapobiegać atakom polegającym na zresetowaniu ich do wcześniejszego stanu).

Vault: określony wpis w bazie danych usługi CKV zawierający klucz odzyskiwania chroniony przez LSKF pojedynczego urządzenia. Użytkownik może mieć wiele zapisanych magazynów. Każde z nich odpowiada innemu urządzeniu lub LSKF. Tylko THM na serwerze Vault może analizować lub wyodrębniać zawartość Vault.

Serwer Vault: komputer ogólnego przeznaczenia działający w centrum danych Google, który został specjalnie zmodyfikowany, aby dodać moduł THM (Trusted Hardware Module).

Projektowanie protokołu

Protokół CKV składa się z kilku etapów:

Inicjacja

Aby zainicjować system, Google dostarczy klucz publiczny dla „roota zaufania”, którego platforma będzie używać do weryfikowania atestów sprzętowych Google. Klucz podpisywania dla tego źródła zaufania jest przechowywany offline i ostrożnie zabezpieczony w taki sposób, aby logowanie się za jego pomocą wymagało uczestnictwa wielu pracowników. Klucz publiczny tego źródła zaufania jest umieszczony w systemie operacyjnym Android i można go zmienić tylko w ramach jego aktualizacji.

Google co jakiś czas publikuje też listę kluczy publicznych dla każdej kohorty THM wraz z atestem na liście. Atest na liście korzysta z podpisu, który łączy się z głównym źródłem zaufania. Każda aktualizacja opublikowanej listy zawiera też numer sekwencyjny, dzięki czemu można zapobiec przywróceniu zmian. Agent przywracania pobierze najnowszą opublikowaną listę kluczy publicznych kohorty i dostarczy ją do platformy. Platforma weryfikuje atest i losowo wybiera z listy klucz publiczny kohorty do użycia na etapie tworzenia Vault.

Tworzenie Vault

Gdy ułatwisz inicjowanie platformy przez pobranie listy kluczy publicznych kohorty, agent przywracania zażąda od platformy utworzenia nowego Vault. Za każdym razem, gdy użytkownik wpisze LSKF, platforma wygeneruje nowy klucz odzyskiwania i zaszyfruje go najpierw za pomocą klucza pochodzącego z skrótu LSKF, a następnie klucza publicznego kohorty wybranego przez platformę podczas inicjowania. Powstały w ten sposób zaszyfrowany obiekt blob to Vault, który jest przekazywany z powrotem przez platformę do agenta przywracania, a następnie przesyła go do usługi CKV Google.

Otwieranie Vault

Gdy agent przywracania na nowym urządzeniu będzie potrzebować dostępu do klucza odzyskiwania zapisanego w konkretnej Vault, najpierw poprosi użytkownika o wpisanie numeru LSKF pierwotnego urządzenia, na którym utworzono Vault. Agent przywracania poprosi platformę o utworzenie żądania odzyskiwania za pomocą tego LSKF. Platforma wygeneruje nowy klucz strony wnoszącej roszczenie oraz zaszyfruje ten klucz strony wnoszącej roszczenie oraz hasz LSKF za pomocą tego samego klucza publicznego kohorty, za pomocą którego Vault był pierwotnie szyfrowany. Powstały w ten sposób zaszyfrowany obiekt blob jest nazywany oświadczeniem o przywróceniu. Platforma przekazuje go do agenta przywracania, który następnie przedstawia go usłudze CKV.

CKV kieruje żądanie odzyskiwania (i odpowiadające mu Vault) do serwerów Vault, które należą do prawidłowej kohorty. THM w serwerach Vault odszyfrowuje żądanie odzyskiwania i podejmuje próbę wyodrębnienia klucza odzyskiwania z oryginalnego Vault przy użyciu zadeklarowanego skrótu LSKF (w celu uzyskania wewnętrznego klucza szyfrowania). Jeśli oryginalny hasz LSKF i deklarowany hasz LSKF są zgodne, THM wyodrębni klucz odzyskiwania z Vault i ponownie zaszyfruje go za pomocą klucza strony wnoszącej roszczenie, który był w roszczeniu odzyskiwania. W przeciwnym razie THM zwróci licznik nieudanych prób. Gdy licznik nieudanych prób osiągnie swój limit, THM odmówi przetworzenia wszelkich kolejnych żądań odzyskiwania dla tego Vault.

Jeśli wszystko pójdzie dobrze, ponownie zaszyfrowany klucz odzyskiwania (który jest teraz zaszyfrowany jako klucz strony wnoszącej roszczenie) jest wysyłany z serwera Vault aż do platformy Framework. Platforma używa swojej kopii klucza strony wnoszącej roszczenie do odszyfrowywania klucza odzyskiwania i protokół jest gotowy.

Środki bezpieczeństwa

System Cloud Key Vault ma zapewnić „dogłębną ochronę” przez uwzględnienie zabezpieczeń na wielu poziomach naszego stosu. Aby przybliżyć działanie tych zabezpieczeń, zaczniemy od opisania klienta i przejścia na stos do usługi Cloud Key Vault.

Bezpieczeństwo klienta

W zależności od producenta OEM i urządzenia współczynnik wiedzy na ekranie blokady (LSKF) jest zwykle przechowywany i chroniony na urządzeniu za pomocą różnych metod, które różnią się w zależności od producenta OEM. Na przykład urządzenia Google Pixel 2 korzystają z odpornego na manipulacje modułu zabezpieczeń sprzętowych do przechowywania LSKF w spoczynku i egzekwowania sprzętowych limitów liczby żądań w ramach walidacji LSKF. Nowe interfejsy API platformy Framework, które wprowadzamy, aby umożliwić korzystanie z Cloud Key Vault, zostały zaprojektowane tak, aby w jak największym stopniu zachowywać istniejące gwarancje bezpieczeństwa, nawet gdy urządzenie używa takiego sprzętowego modułu zabezpieczeń do ochrony miejsca na dane LSKF.

W tej sekcji skupimy się w szczególności na istotnych problemach z zabezpieczeniami i zabezpieczeniach, które mają wpływ na nową funkcję Cloud Key Vault, zamiast udostępniać pełny obraz wszystkich mechanizmów bezpieczeństwa powiązanych z LSKF.

Zabezpieczanie interfejsów API platformy

Nowe interfejsy Framework API, które zostały dodane do obsługi usługi CKV, są oznaczone jako @SystemApi i wymagają specjalnych uprawnień, dzięki którym są one dostępne tylko dla zatwierdzonych przez OEM aplikacji systemowych, takich jak Usługi Google Play. Dzięki temu w dużym stopniu eliminuje możliwość bezpośredniego ataku, które mogą być narażone na dostęp do aplikacji zainstalowanych przez użytkownika na urządzeniu.

Interfejsy API platformy Framework zapewniają też, że Vault są tworzone tylko dla kluczy publicznych kohorty, które zostały poświadczone przez źródło zaufania. Źródło zaufania jest umocnione w strukturze przez producenta OEM w momencie dostawy i nie można go zmienić bez aktualizacji systemu operacyjnego. Dzięki temu masz pewność, że LSKF jest używane tylko do tworzenia Vault, które odpowiednio egzekwują sprzętowe zabezpieczenia brute-force. Wykorzystując systemy THM w usłudze Cloud Key Vault do ochrony LSKF, możemy uzyskać poziom bezpieczeństwa porównywalny z używaniem bezpiecznego sprzętu na poszczególnych urządzeniach (podobnie jak w przypadku urządzeń Google Pixel 2).

Nie zakładamy, że plik LSKF będzie przechowywany w dowolnym miejscu na urządzeniu poza bezpiecznym sprzętem, dlatego nową usługę Vault można utworzyć dopiero od razu po odblokowaniu urządzenia. W momencie, gdy użytkownik wpisuje LSKF, aby odblokować urządzenie, LSKF jest na krótko dostępny dla platformy w pamięci RAM. W tej chwili korzysta z niego nowy interfejs API służący do tworzenia Vault. Nie można utworzyć nowego magazynu chronionego przez LSKF, gdy urządzenie jest zablokowane, ponieważ LSKF jest niedostępny.

Zabezpieczanie agenta przywracania

Podstawową ochroną zapewnianą w agencji przywracania jest ten protokół, który uniemożliwia mu w ogóle odczytanie LSKF bieżącego urządzenia ani kluczy odzyskiwania. Po stronie klienta te elementy powinny być widoczne tylko dla platformy, co znacznie utrudnia wykorzystanie potencjalnych błędów i luk w zabezpieczeniach w agencie przywracania. Agent przywracania jest używany głównie do zarządzania zdarzeniami cyklu życia oraz przesyłaniem danych między chmurą a platformą. Jedynym wyjątkiem jest odzyskiwanie tuż przed protokołem otwierania Vault, kiedy użytkownik musi wpisać nazwę LSKF starego urządzenia. Interfejs użytkownika, który zbiera informacje o zgłoszonej LSKF dla starego urządzenia, jest zaimplementowany w agencie przywracania⁴. Jednak implementacja agenta przywracania „zapomina” zgłoszony LSKF, gdy tylko platforma przejmie tworzenie żądania odzyskiwania.

Funkcje zabezpieczeń protokołu

Pełna analiza protokołu wykracza poza zakres tego dokumentu, ale chcemy zwrócić uwagę na kilka zabezpieczeń wbudowanych w ten protokół. W szczególności protokół używa tylko skrótu LSKF. Oznacza to, że jeśli LSKF ma wysoką entropię (np.jeśli jest to dobre hasło o wysokiej entropii), przechowywanie Vault jest lepsze niż przechowywanie skrótu hasła. W tym przypadku hasz hasła może zapewnić środek bezpieczeństwa niezależnie od bezpieczeństwa THM. Z tego powodu w ramach protokołu obsługujemy haszowanie LSKF z zaburzaniem pamięci. Łączymy też kryptograficznie identyfikator urządzenia, na którym utworzono żądanie odzyskania dostępu do Vault, oraz przypisujemy żądanie odzyskiwania do jednorazowej karty, która jest używana jako test zabezpieczający logowanie w protokole otwierania Vault, aby upewnić się, że prośba o odzyskanie konta jest aktualna.

Klucz odzyskiwania jest generowany automatycznie przy każdym tworzeniu Vault, dlatego przeprowadzamy rotację kluczy, zastępując istniejący wpis Vault nowo utworzonym Vault. Adres licznika nieudanych prób używanego przez Vault jest wybierany podczas tworzenia Vault, a platforma zapewnia, że adres licznika używanego w kolejnych Vault nie zmienia się, chyba że zmieni się LSKF lub pojawi się nowa poświadczona lista kluczy publicznych kohorty. Dzięki temu można przeprowadzić rotację klucza odzyskiwania bez szkody dla ochrony LSKF.

Zabezpieczenia serwera dla usługi Cloud Key Vault

Implementacja serwera polega na połączeniu oprogramowania działającego na zwykłym sprzęcie serwerowym oraz oprogramowania układowego działającego na specjalistycznym sprzęcie (układzie Titan). Omówimy zabezpieczenia dostępne na każdej warstwie.

Zabezpieczenia sprzętu

Podstawowym zabezpieczeniem wdrożonym po stronie serwera usługi CKV są THM (Trusted Hardware Modules), które są tworzone z użyciem własnych, specjalnie zaprojektowanych układów Titan od Google. Układy zawierają oprogramowanie układowe, które udostępnia interfejsy API niezbędne do implementacji protokołów CKV. Mogą oni w szczególności wygenerować parę kluczy i bezpiecznie ją udostępnić innym członkom kohorty. Dzięki temu logika oprogramowania układowego chroni klucz prywatny przed wyciekiem danych poza układy Titan w kohorcie. Mogą też wykonywać operacje otwierania Vault i utrzymywać licznik nieudanych prób w poszczególnych Vault (w przypadku gdy licznik jest oparty na stanie zapisanym w układzie scalonym Titan). Bardziej szczegółowy opis protokołu uruchamianego przez układ układowy CKV Titan zostanie udostępniony w kolejnej wersji tego dokumentu.

Biorąc pod uwagę, że bezpieczeństwo serwera wywodzi się z logiki oprogramowania układowego układów Titan, musimy upewnić się, że logika nie zmienia się w sposób, który umożliwia chipom wyciek tajnych obiektów lub ignorowanie limitów licznika. W tym celu zmieniamy też program rozruchowy Titan, aby przed zastosowaniem aktualizacji zostały całkowicie wyczyszczone dane przechowywane przez układ (takie jak klucz prywatny kohorty). Wadą tej ochrony jest to, że nie możemy naprawić błędów w oprogramowaniu układowym bez utraty danych. Aktualizacja oprogramowania jest funkcjonalnie zgodna z zniszczeniem istniejącego sprzętu i wymianą go na nowe układy scalone. Jeśli wymagana jest krytyczna poprawka oprogramowania, Google musi wygenerować i opublikować zupełnie nową listę akredytowanych kluczy publicznych kohorty oraz stopniowo przenieść wszystkich użytkowników na nową listę. Aby ograniczyć to ryzyko, staramy się ograniczać bazę kodu oprogramowania układowego do minimum i dokładnie sprawdzać ją pod kątem potencjalnych problemów z zabezpieczeniami.

Ochrona oprogramowania

Oprócz sztywnych limitów błędów na Vault nałożonych przez THM usługa CKV wdraża również programowe ograniczanie liczby żądań. Ograniczenie szybkości ma na celu powstrzymanie hakerów przed uzyskaniem dostępu do konta użytkownika i szybkim wyczerpaniem limitu nieudanych prób odzyskiwania, co w efekcie blokuje dostęp prawdziwego użytkownika do kluczy odzyskiwania. Podobnie jak w przypadku opóźnień nałożonych przez urządzenie użytkownika po zbyt wielu nieudanych próbach odblokowania ekranu usługa CKV będzie wymuszać coraz większe opóźnienie po każdym nieudanym żądaniu otwarcia Vault.

Wdrażamy również standardowe środki bezpieczeństwa dla usług w chmurze hostujących dane użytkowników, w tym ścisłą kontrolę dostępu, monitorowanie i kontrolę.

Szczegółowa specyfikacja protokołu

Szczegółowa specyfikacja protokołu jest nadal w przygotowaniu, a ten dokument zostanie zaktualizowany o jej szczegóły wraz z opublikowaniem kodu klienta w projekcie Android Open Source pod koniec tego roku.

Uwagi