Linux Fundacja, BastionZero i Docker zaprezentowały nowy projekt open source o nazwie OpenPubKey, który rozwija protokół kryptograficzny o tej samej nazwie do cyfrowego podpisywania dowolnych obiektów. Technologia ta została opracowana jako wspólny projekt BastionZero i Dockera, aby uprościć cyfrowe podpisywanie obrazów kontenerów Dockera, zapobiec manipulacjom i zweryfikować, czy zostały one stworzone przez ich twórcę. Projekt będzie rozwijany na neutralnej platformie pod auspicjami organizacji. Linux Foundation, która eliminuje zależność od indywidualnych firm komercyjnych i upraszcza współpracę z zewnętrznymi współautorami. Implementacja referencyjna OpenPubKey jest napisana w języku Go i rozpowszechniana na licencji Apache 2.0.
Możliwości OpenPubKey nie ograniczają się do obrazów kontenerów, a technologię można wykorzystać do potwierdzenia źródła dowolnego zasobu, zapobiegania podstawieniu zależności i poprawy bezpieczeństwa kanałów dystrybucji zbiorów danych. Na przykład technologia ma zastosowanie do weryfikowania zestawów programów, poszczególnych komunikatów i zatwierdzeń. Twórcy podpisów muszą jedynie posiadać konto w serwisie obsługującym OpenID, a konsumenci otrzymują możliwość weryfikacji dołączonych podpisów i potwierdzenia swojego połączenia z zadeklarowanym identyfikatorem OpenID.
W swoim przeznaczeniu OpenPubKey jest podobny do tego stworzonego przez Google i wcześniej przeniesionego do Linux Platforma Foundation jest podobna do systemu Sigstore, ale różni się od niego tym, że znacznie upraszcza wdrażanie, użytkowanie i konserwację, eliminując scentralizowane komponenty serwerowe odpowiedzialne za prowadzenie publicznego dziennika potwierdzającego autentyczność zmian (dziennik przejrzystości) i zapewniającego działanie urzędów certyfikacji (Certificate Authority).
Zamiast wdrażać własne urzędy certyfikacji, OpenPubKey korzysta z technologii uwierzytelniania OpenID i łączy utworzone podpisy z istniejącymi dostawcami OpenID Connect. Innymi słowy, OpenPubkey umożliwia powiązanie kluczy kryptograficznych z określonymi użytkownikami przy użyciu dostawców OpenID Connect (IdP) zamiast urzędów certyfikacji. Technologia jest w pełni kompatybilna z istniejącymi dostawcami OpenID, takimi jak GitHub, Azure/Microsoft, Okta, OneLogin, Keycloak i Google i nie wymaga zmian po ich stronie (wykorzystywany jest standardowy ID Token dostarczony przez dostawcę, co pozwala na wdrożyć OpenPubKey tylko poprzez zmiany po stronie klienta OpenID Connect).
Token wydany przez dostawcę OpenID jest przekształcany w certyfikat, który kryptograficznie wiąże identyfikator w OpenID Connect z kluczem publicznym. Następnie użytkownik używa wygenerowanego klucza do podpisania dowolnych danych, które następnie można zweryfikować z identyfikatorem w OpenID Connect. OpenPubKey wykorzystuje klucze efemeryczne, które mają ograniczony czas życia - klucze są generowane podczas logowania OpenID i usuwane po zakończeniu sesji z dostawcą OpenID.
Przykładowy algorytm tworzenia podpisu przy użyciu OpenPubKey:
- Zaloguj się przy użyciu dostawcy OpenID (Google, GitHub, Microsoft itp.).
- Poproś o token identyfikacyjny od dostawcy OpenID.
- Zwrócenie tokena podpisanego kluczem dostawcy i zawierającego pole „nonce” z dowolnymi danymi przesyłanymi w trakcie żądania (przesyłany jest hash SHA3 klucza publicznego).
- Użyj po stronie użytkownika otrzymanego tokena jako certyfikatu zawierającego kluczowe dane.
- Dołączenie tokena do podpisu, podobnie jak w przypadku certyfikatu.
Weryfikacja sprowadza się do sprawdzenia, czy dołączony token jest podpisany przez dostawcę OpenID i sprawdzenia poprawności podpisu cyfrowego zasobu za pomocą klucza publicznego, co pozwala upewnić się, że zasób jest podpisany za pomocą identyfikatora z certyfikatu i jest to potwierdzone podpisem dostawcy OpenID. Na przykład twórca podpisu może otrzymać token podpisany przez dostawcę Google OpenID z informacją, że jest zweryfikowany jako bob@gmail.com i używa klucza publicznego 0x54A5…FF. Następnie, po otrzymaniu wiadomości podpisanej tym samym kluczem, odbiorca może użyć tokena podpisanego przez dostawcę, aby zweryfikować, że klucz bob@gmail.com to 0x54A5…FF i wiadomość została rzeczywiście podpisana przez bob@gmail.com.
Uproszczenie architektury osiąga się poprzez pewne kompromisy (na przykład zależność od zewnętrznych dostawców OpenID i brak dziennika zmian z hierarchicznym hashowaniem), które są akceptowalne w niektórych sytuacjach, ale nie w innych. Aby zmniejszyć zależność od dostawców OpenID, których kompromis lub działania mogą zdyskredytować system (np. zhakowani dostawcy mogą wydać fikcyjny klucz osobie trzeciej), proponuje się zastosować dodatkowy, ale nie obowiązkowy, MFA-Cosigner (Multi-Factor Authentication Cosigner) link do uwierzytelniania wieloskładnikowego (token musi być podpisany nie tylko przez głównego dostawcę, ale także przez niezależną usługę uwierzytelniania, która potwierdza użytkownika).
Jedną ze słabości OpenPubKey jest także obecność obcych informacji, które można wykorzystać do śledzenia aktywności przez długi czas i niezależnie od zmiany nazwy (ponowne użycie tokena identyfikacyjnego zamiast nowego certyfikatu). Bezpośrednie powiązanie z kluczami OpenID Connect podczas weryfikacji eliminuje część serwerową, ale znacznie komplikuje implementację po stronie klienta i pozostawia większe pole manewru podczas przeprowadzania ataków (powierzchnia ataku) na klienta, na przykład ze względu na fakt, że zadanie rotacja kluczy przypada klientowi. Brak dziennika zmian nie pozwala klientowi na śledzenie ewentualnych wycieków kluczy.
Źródło: opennet.ru
