Fundacja Linux, BastionZero i Docker wspólnie zaprezentowały nowy otwarty projekt OpenPubKey, rozwijający tego samego imienia protokół kryptograficzny do weryfikacji cyfrowych podpisów dowolnych obiektów. Technologia została opracowana jako wspólny projekt firm BastionZero i Docker w celu uproszczenia weryfikacji cyfrowymi podpisami obrazów kontenerów Docker, aby zapobiec ich podstawieniu i potwierdzić budowę zgłoszoną przez twórcę. Projekt będzie rozwijany na neutralnej platformie pod patronatem organizacji Linux Foundation, co wyeliminuje zależność od poszczególnych firm komercyjnych i uprości wspólną pracę z zaangażowaniem zewnętrznych uczestników. Referencyjna implementacja OpenPubKey została napisana w języku Go i jest rozpowszechniana na licencji Apache 2.0.
Możliwości OpenPubKey nie ograniczają się tylko do obrazów kontenerów, a technologia może być stosowana do potwierdzania źródła pozyskiwania dowolnych zasobów, zapobieganiu podstawieniu zależności oraz zwiększaniu bezpieczeństwa kanałów dystrybucji zbiorów danych. Na przykład, technologia ta nadaje się do weryfikacji budów oprogramowania, poszczególnych wiadomości i commitów. Twórcy podpisu potrzebują jedynie konta w usłudze wspierającej OpenID, natomiast odbiorcy mają możliwość weryfikacji dołączonych podpisów oraz potwierdzenia ich powiązania z deklarowanym identyfikatorem OpenID.
Pod względem zastosowania OpenPubKey przypomina system Sigstore stworzony przez Google, który wcześniej został przekazany do Fundacji Linux, jednak różni się od niego znacznym uproszczeniem wdrożenia, użycia i utrzymania poprzez eliminację centralizowanych składników serwerowych, odpowiedzialnych za prowadzenie publicznego dziennika, potwierdzającego autentyczność zmian (transparency log) oraz zapewnienie działania instytucji certyfikacyjnych (Certificate Authority).
Zamiast wdrażania własnych centrów certyfikacji, OpenPubKey wykorzystuje uwierzytelnianie oparte na technologii OpenID oraz powiązanie utworzonych podpisów z istniejącymi dostawcami OpenID Connect. Innymi słowy, OpenPubkey pozwala powiązać klucze kryptograficzne z konkretnymi użytkownikami, korzystając z dostawców OpenID Connect (IdP) zamiast centrów certyfikacji. Technologia ta jest w pełni kompatybilna z istniejącymi dostawcami OpenID, takimi jak GitHub, Azure/Microsoft, Okta, OneLogin, Keycloak i Google, i nie wymaga dokonywania zmian po ich stronie (z wykorzystaniem domyślnego tokenu ID dostarczanego przez dostawcę, co umożliwia zaimplementowanie OpenPubKey wyłącznie poprzez zmiany po stronie klienta OpenID Connect).
Token wydawany przez dostawcę OpenID jest przekształcany w certyfikat, który kryptograficznie wiąże identyfikator w OpenID Connect z kluczem publicznym. Następnie użytkownik wykorzystuje wygenerowany klucz do podpisywania dowolnych danych, a te podpisy mogą być później weryfikowane pod kątem powiązania z identyfikatorem w OpenID Connect. W OpenPubKey zastosowano klucze efemeryczne, których czas życia jest ograniczony — klucze są generowane podczas logowania przy użyciu OpenID i usuwane na zakończenie sesji z dostawcą OpenID.
Przykładowy algorytm tworzenia podpisu z wykorzystaniem OpenPubKey:
- Logowanie przy użyciu dostawcy OpenID (Google, GitHub, Microsoft itp.).
- Żądanie identyfikacyjnego tokenu od dostawcy OpenID.
- Zwrócenie tokenu, podpisanego kluczem dostawcy i zawierającego pole „nonce” z losowymi danymi przesłanymi w żądaniu (przesyłany jest skrót SHA3 od klucza publicznego).
- Wykorzystanie po stronie użytkownika otrzymanego tokenu jako certyfikatu, który zawiera dane o kluczu.
- Załączenie tokenu do podpisu, analogicznie do certyfikatu.
Weryfikacja polega na sprawdzeniu, czy dołączony token został podpisany przez dostawcę OpenID oraz na zweryfikowaniu poprawności podpisu cyfrowego przy użyciu klucza publicznego, co pozwala upewnić się, że zasób został podpisany za pomocą identyfikatora z certyfikatu, a to zostało potwierdzone podpisem dostawcy OpenID. Na przykład, podmiot podpisujący może otrzymać podpisany przez dostawcę OpenID token z informacją, że został zweryfikowany jako bob@gmail.com i używa klucza publicznego 0x54A5…FF. Następnie, przy otrzymaniu wiadomości podpisanej tym samym kluczem, może użyć podpisanego przez dostawcę tokena do weryfikacji, że klucz bob@gmail.com — 0x54A5…FF i wiadomość została rzeczywiście podpisana przez bob@gmail.com.
Uproszczenie architektury zostało zrealizowane dzięki pewnym kompromisom (na przykład, zależność od zewnętrznych dostawców OpenID i brak logu zmian z hierarchicznym hashowaniem), które w niektórych sytuacjach są dopuszczalne, a w innych nie. Aby zmniejszyć zależność od dostawców OpenID, których kompromitacja lub działania personelu mogą zdyskwalifikować system (na przykład, wirusowcy mogą wydać fałszywy klucz osobie trzeciej), proponuje się użycie dodatkowego, ale opcjonalnego ogniwa MFA-Cosigner (Multi-Factor Authentication Cosigner) do wieloskładnikowego uwierzytelniania (token powinien być podpisany nie tylko przez głównego dostawcę, ale również niezależną usługę uwierzytelniającą, potwierdzającą użytkownika).
Wśród słabych stron OpenPubKey zauważono również istnienie zewnętrznych danych, które mogą być używane do śledzenia aktywności przez długi czas, niezależnie od zmian nazw (ponowne użycie identyfikującego tokena zamiast nowego certyfikatu). Bezpośrednie powiązanie z kluczami OpenID Connect podczas weryfikacji wyklucza część serwerową, ale znacznie komplikuje realizację po stronie klienta i pozostawia więcej przestrzeni do manewru przy przeprowadzaniu ataków (attack surface) na klienta, na przykład z powodu tego, że to klient jest odpowiedzialny za rotację kluczy. Brak logu zmian uniemożliwia klientowi śledzenie możliwych wycieków kluczy.
Źródło: opennet.ru
