Kryptografia II stopień

Od definicji bezpieczeństwa do konstrukcji, redukcji i publikacji naukowych.

W10d. Klucze FIDO2 i passkeys: od urządzenia do podpisu

FIDO2: Fast IDentity Online. Rodzina standardów uwierzytelniania. FIDO2 łączy standard przeglądarkowy WebAuthn z protokołem CTAP.

Logujemy się do konkretnej usługi, nie „do internetu” jako całości. Zamiast ujawniać jej wielokrotnie używane hasło, urządzenie podpisuje dane bieżącego logowania. Serwer sprawdza podpis kluczem publicznym zapisanym przy koncie. Sam podpis nie wystarcza. Trzeba jeszcze ustalić, dla jakiej witryny, jakiego konta i jakiego żądania został utworzony.

Rozdzielmy cztery czynności. Identyfikacja wskazuje konto. Uwierzytelnienie sprawdza dowód kontroli poświadczenia. Autoryzacja określa uprawnienia konta. Sesja wiąże późniejsze żądania z zakończonym logowaniem. Podpis nie potwierdza automatycznie nazwiska człowieka i nie nadaje mu praw administratora.

FIDO, FIDO2 i passkey: trzy różne poziomy opisu

FIDO rozwija się jako Fast IDentity Online. To rodzina standardów uwierzytelniania. Historyczne U2F, Universal 2nd Factor, służyło do użycia dodatkowego składnika, często po haśle. FIDO2 łączy WebAuthn z CTAP. Nie jest nazwą jednego algorytmu podpisu ani jednego modelu klucza USB.

WebAuthn: Web Authentication. Standard uwierzytelniania w aplikacjach internetowych z użyciem klucza publicznego.
CTAP: Client to Authenticator Protocol. Protokół komunikacji klienta z uwierzytelniaczem.

WebAuthn, Web Authentication, to interfejs uwierzytelniania w przeglądarce. Aplikacja wywołuje navigator.credentials.create() przy rejestracji i navigator.credentials.get() przy logowaniu.
CTAP, Client to Authenticator Protocol, określa komunikację klienta z uwierzytelniaczem. Może to być zewnętrzny klucz sprzętowy. Urządzenie wbudowane w komputer może korzystać z wewnętrznego interfejsu platformy.
Passkey to wykrywalne poświadczenie FIDO przeznaczone do logowania bez hasła. Uwierzytelniacz potrafi je odnaleźć dla danej usługi bez wcześniejszego otrzymania jego identyfikatora od serwera. Obejmuje parę kluczy i dane wiążące ją z usługą oraz kontem. Nie jest hasłem, które przeglądarka wpisuje za użytkownika. Klucz sprzętowy może obsługiwać passkeys, ale także inne poświadczenia FIDO używane jako drugi składnik.

Serwer usługi nazywamy RP, Relying Party, czyli stroną polegającą na wyniku uwierzytelnienia. Uwierzytelniacz zarządza poświadczeniem i wykonuje podpis. Klient, zwykle przeglądarka i system operacyjny, pośredniczy między nimi oraz pilnuje kontekstu witryny. Terminologia FIDO Alliance, architektura WebAuthn.

Na diagramach wystąpią dwa rodzaje lokalnej kontroli. UP, User Presence, to potwierdzenie obecności użytkownika. UV, User Verification, to jego lokalna weryfikacja przez uwierzytelniacz. Samo dotknięcie urządzenia może zapewniać UP bez UV. W naszym profilu wymagamy obu.

Klucz sprzętowy, platforma i programowy passkey

Miejsce użycia klucza i możliwość jego synchronizacji to dwie odrębne cechy. Uwierzytelniacz w laptopie nie musi synchronizować kluczy. Passkey zarządzany przez program może z kolei korzystać z ochrony sprzętowej. Nie jest prawdą, że każdy programowy passkey oznacza jawny plik z kluczem prywatnym.

Rozwiązanie	Gdzie działa podpis	Co trzeba uwzględnić w modelu bezpieczeństwa
Fizyczny klucz bezpieczeństwa FIDO2	Na osobnym urządzeniu, zwykle połączonym przez USB lub NFC	W profilu związanym z urządzeniem sekret nie jest eksportowany. Utrata urządzenia wymaga zapasowego poświadczenia lub procedury odzyskiwania
Passkey platformowy, związany z urządzeniem	W mechanizmie systemu telefonu lub komputera, często z ochroną sprzętową	Ochrona sekretu, lokalna kontrola użytkownika i bezpieczeństwo systemu. To nie musi być osobny klucz USB
Passkey synchronizowany	Na uprawnionym urządzeniu korzystającym z kopii poświadczenia	Dochodzą szyfrowanie synchronizacji, przyłączanie urządzeń, konto dostawcy i odzyskiwanie dostępu
Uwierzytelniacz czysto programowy	W oprogramowaniu, bez założonej izolacji sprzętowej	Zgodność komunikatów nie daje odporności na przejęcie pamięci procesu lub systemu

USB to Universal Serial Bus, interfejs przewodowy. NFC to Near Field Communication, komunikacja zbliżeniowa. Ani rodzaj złącza, ani samo logo FIDO2 nie dowodzą konkretnej odporności na fizyczne wydobycie sekretu. Taka własność wymaga odpowiedniego urządzenia, oceny i polityki wdrożenia.

Urządzenie nie jest pojedynczą parą kluczy. Jeden klucz sprzętowy może obsługiwać wiele poświadczeń. Nowa rejestracja tworzy nową parę związaną z określonym RP i kontem. Nie wysyłamy jednego uniwersalnego klucza publicznego do wszystkich usług. Kopie synchronizowanego poświadczenia to z kolei ten sam klucz logiczny dostępny na kilku urządzeniach.

Przy synchronizacji klucz prywatny nadal nie trafia do RP, lecz może być dostępny na kilku urządzeniach użytkownika. Przy logowaniu z pomocą telefonu telefon może sam wykonać podpis dla przeglądarki na komputerze. To nie musi oznaczać skopiowania poświadczenia na komputer. Te dwa mechanizmy trzeba odróżniać. NIST: uwierzytelniacze synchronizowane.

Oznaczenia i kontrakt całego mechanizmu

Zbudujemy model z poznanych wcześniej algorytmów podpisu. Poniższe nazwy procedur porządkują opis dydaktyczny. Nie są dodatkowym standardem ani dosłownymi nazwami wszystkich funkcji WebAuthn. Rozpatrujemy usługę otwartą jako samodzielna strona przez HTTPS, bez rozszerzeń i bez osadzenia w obcej ramce. HTTPS chroni połączenie z usługą za pomocą TLS, Transport Layer Security. FIDO2 nie zastępuje TLS i nie uzgadnia tu klucza szyfrowania całej sesji.

HTTPS: Hypertext Transfer Protocol Secure. HTTP przesyłany przez połączenie chronione protokołem TLS.

Symbol	Znaczenie i właściciel
$\rho$	RP ID, identyfikator domenowy usługi, np. `kurs.example`
$o$	Origin, pochodzenie strony: schemat, host i port, np. `https://kurs.example`
$\mathrm{uid}$	Wewnętrzny identyfikator konta, przekazywany jako uchwyt użytkownika. Nie jest sekretem ani dowodem. Nie powinien zawierać adresu e-mail lub innych danych osobowych
$\mathrm{cid}$	Identyfikator poświadczenia. Pozwala wybrać klucz, lecz sam nie jest sekretem ani dowodem
$(pk_{\mathrm{cred}},sk_{\mathrm{cred}})$	Klucz publiczny zapisany przez RP i odpowiadający mu klucz prywatny uwierzytelniacza
$c$	Świeże publiczne wyzwanie serwera, tutaj 32 losowe bajty
$st$	Stan oczekującej operacji po stronie RP: wyzwanie, rodzaj operacji, kontekst konta, termin ważności i stan wykorzystania
$D$	Baza RP wiążąca poświadczenia z kontami, kluczami i metadanymi
$S$	Prywatny magazyn poświadczeń uwierzytelniacza
$pp$	Konfiguracja usługi: RP ID, dozwolone originy, algorytmy i wymagania weryfikacji

RP ID nie jest pełnym adresem strony. Zgodna przeglądarka sprawdza jego dozwolony związek z domeną originu. Dopuszczenie domeny nadrzędnej podlega regułom WebAuthn. Nie wolno po prostu zaakceptować dowolnego RP ID podanego przez skrypt.

Symbol $pp_{\mathrm{sig}}$ oznacza parametry wybranego algorytmu podpisu. Wywołania $\mathsf{Sign}$ i $\mathsf{Verify}$ w przepływie pomijają ten ustalony parametr dla zwięzłości. Dalej rozpiszemy go jawnie dla ES256. Wymagamy poświadczenia wykrywalnego przez opcję residentKey: "required". Pozostałe, niewypisane pola żądań podlegają regułom WebAuthn.

ES256: ECDSA using P-256 and SHA-256. Identyfikator podpisu ECDSA na krzywej P-256 z haszem SHA-256.

Dwa etapy mają różne cele. Rejestracja wiąże nowy klucz z właściwym kontem. Logowanie dowodzi kontroli klucza już zarejestrowanego. Najpierw trzeba bezpiecznie ustalić, kto może dopisać poświadczenie do konta. Napastnik, który dopisze własny klucz do cudzego konta, nie musi później fałszować podpisu.

Rejestracja: utworzenie i zapis klucza

Niech $\mathrm{CD}$ oznacza dokładne bajty clientDataJSON, danych klienta kodowanych jako JSON (JavaScript Object Notation). Przy rejestracji zawierają typ webauthn.create, wyzwanie zakodowane w base64url i origin. Base64url koduje bajty znakami odpowiednimi dla adresów, ale ich nie szyfruje. Skrót $h=\operatorname{SHA256}(\mathrm{CD})$ otrzymuje uwierzytelniacz. Symbol $\mathrm{AO}$ oznacza zwracany obiekt atestacji, attestationObject.

FIDO2: rejestracja poświadczenia: algorytmy i przepływ

Dydaktyczny profil bez rozszerzeń, z atestacją none i wymaganym UV. Create obejmuje czynności klienta i uwierzytelniacza. Rozdzielamy je na rysunku. Użytkownik musi mieć prawo do dopisania klucza do wskazanego konta.

\Pi=(\mathsf{Setup},\mathsf{RegBegin},\mathsf{Create},\mathsf{RegFinish})

\mathsf{Setup}()

\longrightarrow pp

pp=(\rho,\mathcal O,\mathcal A,\mathrm{UV}_{\mathrm{req}})

O to zbiór dozwolonych originów. A to zbiór algorytmów podpisu. UV_req określa wymóg lokalnej weryfikacji użytkownika.

\mathsf{RegBegin}(pp,\mathrm{uid})

\longrightarrow (O_r,st)

c\overset{\$}{\leftarrow}\{0,1\}^{256}

O_r=(c,\rho,\mathrm{uid},\mathcal A,\mathrm{UV}_{\mathrm{req}})

Utwórz stan st związany z kontem, sesją i rejestracją. Zapisz c, termin ważności oraz znacznik niewykorzystania.

\mathsf{Create}(pp,O_r,o,S)

\longrightarrow ((\mathrm{cid},\mathrm{CD},\mathrm{AO}),S\prime)\text{ albo }\bot

h=\operatorname{SHA256}(\mathrm{CD})

(pk_{\mathrm{cred}},sk_{\mathrm{cred}})\leftarrow\mathsf{KeyGen}(pp_{\mathrm{sig}})

S\prime[\mathrm{cid}]=(\rho,\mathrm{uid},sk_{\mathrm{cred}})

Klient sprawdza dopuszczalność RP ID i przygotowuje CD typu webauthn.create. Po zgodzie i UV urządzenie tworzy unikalny cid, wybiera dozwolony algorytm, zapisuje sekret i zwraca AO z nowym kluczem publicznym. Błąd kończy procedurę.

\mathsf{RegFinish}(pp,D,st,R_r)

\longrightarrow D\prime\text{ albo }\bot

R_r=(\mathrm{cid},\mathrm{CD},\mathrm{AO})

D\prime[\mathrm{cid}]=(\mathrm{uid},pk_{\mathrm{cred}},\mathrm{meta})

Przed zapisem sprawdź świeży stan, typ create, wyzwanie, origin, RP ID, UV/UP, format AO, algorytm i klucz. meta zawiera algorytm, licznik i stan kopii. Profil dopuszcza tylko format none i brak rozszerzeń. Sprawdź przypisanie konta i brak konfliktu cid. Atomowo zapisz rekord oraz zużyj st. Przy błędzie zwróć odrzucenie.

FIDO2: rejestracja poświadczenia

RP · serwer, RegBegin: świeże wyzwanie: $c\overset{\$}{\leftarrow}\{0,1\}^{256}$ Zapisz st i uprawnione konto.
RP · serwer → Klient · przeglądarka: $O_r=(c,\rho,\mathrm{uid},\mathcal A)$ Opcje create, także wymaganie UV
Klient · przeglądarka, Create: kontekst strony: $\mathrm{CD}=\operatorname{JSON}(\mathtt{create},c,o)$ $h=\operatorname{SHA256}(\mathrm{CD})$ Sprawdź związek originu z RP ID.
Klient · przeglądarka → Uwierzytelniacz: $(\rho,\mathrm{uid},\mathcal A,h)$ Żądanie utworzenia poświadczenia
Uwierzytelniacz, Create: UP, UV i nowy klucz: $(pk_{\mathrm{cred}},sk_{\mathrm{cred}})\leftarrow\mathsf{KeyGen}(pp_{\mathrm{sig}})$ $S\prime[\mathrm{cid}]=(\rho,\mathrm{uid},sk_{\mathrm{cred}})$ Sekret nie jest wysyłany do RP.
Uwierzytelniacz → Klient · przeglądarka: $(\mathrm{cid},\mathrm{AO})$ AO zawiera nowy klucz publiczny
Klient · przeglądarka → RP · serwer: $R_r=(\mathrm{cid},\mathrm{CD},\mathrm{AO})$ Odpowiedź na autoryzowaną rejestrację
RP · serwer, RegFinish: kontrole i zapis: $D\prime[\mathrm{cid}]=(\mathrm{uid},pk_{\mathrm{cred}},\mathrm{meta})$ Zapisz tylko po wszystkich kontrolach.

Skrót create na rysunku oznacza dokładny typ webauthn.create. Opcje i metadane są skrócone do pól omawianych w tekście. W profilu none nie ma obowiązkowego podpisu atestacyjnego. Przebieg pokazuje operacje, nie wywołuje sprzętowego klucza. WebAuthn §7.1.

W prostym profilu przyjmujemy attestation: "none". Obiekt $\mathrm{AO}$ nadal zawiera dane uwierzytelniacza i nowy klucz publiczny, lecz nie daje podpisanego przez producenta potwierdzenia modelu urządzenia. W tym wariancie nie występuje podpis atestacyjny. Można wymagać innej atestacji, ale wtedy trzeba zweryfikować jej format, podpis, łańcuch zaufania i politykę akceptacji.

Serwer sprawdza też typ public-key, wybrane kodowanie i dozwolony algorytm klucza, flagi, RP ID oraz związek odpowiedzi z autoryzowaną rejestracją. Klucz musi być poprawnym kluczem wskazanego algorytmu. Nowy identyfikator nie może nadpisać poświadczenia innego konta. Zapis powinien nastąpić atomowo ze zużyciem oczekującej operacji.

Klucz publiczny w danych rejestracji jest kodowany jako COSE_Key. CBOR, Concise Binary Object Representation, jest formatem binarnego zapisu danych. COSE, CBOR Object Signing and Encryption, określa m.in. struktury kluczy i identyfikatory algorytmów. To formaty, nie dodatkowe pary kluczy. Rejestracja w WebAuthn, §7.1.

Logowanie: co dokładnie obejmuje podpis

Przy logowaniu $\mathrm{CD}$ zawiera typ webauthn.get, bieżące wyzwanie i origin. $\mathrm{AD}$ to bajty authenticatorData, przygotowane przez uwierzytelniacz. Ich podstawowy nagłówek ma następujący układ:

Pozycja bajtów od zera	Długość	Zawartość
0–31	32	$\operatorname{SHA256}(\rho)$ , obliczony z bajtów identyfikatora RP
32	1	Flagi obecności, weryfikacji użytkownika i stanu poświadczenia
33–36	4	Licznik podpisów zapisany od najbardziej znaczącego bajtu

W tym profilu odpowiedzi logowania nie ma dodatkowych pól ani rozszerzeń, więc $|\mathrm{AD}|=37$ bajtów. W rejestracji dane są dłuższe, bo dochodzi m.in. klucz publiczny. Nie można stosować stałej długości 37 do każdego komunikatu WebAuthn.

h=\operatorname{SHA256}(\mathrm{CD}),\qquad B=\mathrm{AD}\mathbin\Vert h,\qquad \sigma\leftarrow\mathsf{Sign}(sk_{\mathrm{cred}},B).

Symbol $\Vert$ oznacza połączenie ciągów bajtów. W naszym profilu $B$ ma $37+32=69$ bajtów. Wyzwanie i origin są chronione przez skrót danych klienta. RP ID jest związane z podpisem przez początek $\mathrm{AD}$ . Serwer haszuje otrzymane bajty $\mathrm{CD}$ , a nie samodzielnie odtworzony JSON o potencjalnie innej kolejności pól lub innych odstępach.

FIDO2: logowanie zarejestrowanym kluczem: algorytmy i przepływ

Kontynuacja po poprawnej rejestracji. D i S już zawierają zgodne poświadczenie. Konto jest wskazane, a cid pochodzi z listy dozwolonej przez RP. Błędne wejście lub odmowa lokalnej weryfikacji przerywa wykonanie.

\Pi=(\mathsf{AuthBegin},\mathsf{Get},\mathsf{AuthFinish})

\mathsf{AuthBegin}(pp,D,\mathrm{uid})

\longrightarrow (O_a,st)

c\overset{\$}{\leftarrow}\{0,1\}^{256}

O_a=(c,\rho,\mathrm{allowCredentials},\mathrm{UV}_{\mathrm{req}})

Wybierz poświadczenia konta i zapisz jednorazowy stan logowania z terminem ważności. c jest publiczne.

\mathsf{Get}(pp,O_a,o,S)

\longrightarrow (R_a,S\prime)\text{ albo }\bot

h=\operatorname{SHA256}(\mathrm{CD})

B=\mathrm{AD}\Vert h

\sigma\leftarrow\mathsf{Sign}(sk_{\mathrm{cred}},B)

R_a=(\mathrm{cid},\mathrm{CD},\mathrm{AD},\sigma)

Klient sprawdza RP ID i przygotowuje CD typu webauthn.get. Uwierzytelniacz wybiera dozwolone cid związane z rho, wymaga UP i UV oraz tworzy AD. Jeśli prowadzi licznik, aktualizuje swój stan. Sekret pobiera z S, nie z żądania RP.

\mathsf{AuthFinish}(pp,D,st,R_a)

\longrightarrow (\mathrm{accept},D\prime)\text{ albo }\bot

(\mathrm{uid},pk_{\mathrm{cred}},\mathrm{meta})=D[\mathrm{cid}]

B=\mathrm{AD}\Vert\operatorname{SHA256}(\mathrm{CD})

\mathsf{Verify}(pk_{\mathrm{cred}},B,\sigma)\stackrel{?}{=}1

Wykonaj wszystkie kontrole wymienione w podsekcji o decyzji RP. Przy błędzie odrzuć. Przy sukcesie atomowo zużyj st i zaktualizuj metadane D. Dopiero potem aplikacja może utworzyć sesję konta.

FIDO2: logowanie zarejestrowanym kluczem

RP · serwer, AuthBegin: zapamiętaj żądanie: $c\overset{\$}{\leftarrow}\{0,1\}^{256}$ Wybierz cid przypisane do konta.
RP · serwer → Klient · przeglądarka: $(c,\rho,\mathrm{allowCredentials})$ Opcje get, także wymaganie UV
Klient · przeglądarka, Get: podpisywany kontekst: $\mathrm{CD}=\operatorname{JSON}(\mathtt{get},c,o)$ $h=\operatorname{SHA256}(\mathrm{CD})$ To bajty utworzone przez klienta.
Klient · przeglądarka → Uwierzytelniacz: $(\rho,h,\mathrm{allowCredentials})$ Żądanie podpisu wybranym kluczem
Uwierzytelniacz, Get: UP, UV i podpis: $B=\mathrm{AD}\Vert h$ $\sigma\leftarrow\mathsf{Sign}(sk_{\mathrm{cred}},B)$ AD wiąże RP ID, flagi i licznik.
Uwierzytelniacz → Klient · przeglądarka: $(\mathrm{cid},\mathrm{AD},\sigma)$ Bez klucza prywatnego
Klient · przeglądarka → RP · serwer: $(\mathrm{cid},\mathrm{CD},\mathrm{AD},\sigma)$ Odpowiedź na bieżące logowanie
RP · serwer, AuthFinish: kontekst i podpis: $\mathsf{Verify}(pk_{\mathrm{cred}},B,\sigma)\stackrel{?}{=}1$ Użyj D i st. Sam podpis nie wystarcza.

Skrót get oznacza webauthn.get. Klient przekazuje urządzeniu h, a pełne CD dołącza w odpowiedzi dla RP. W urządzeniu przechodzi ten sam interfejs podpisu niezależnie od tego, czy sekret jest związany z jednym urządzeniem, czy objęty synchronizacją. WebAuthn §7.2.

W tym podstawowym wariancie konto jest wskazane przed logowaniem. Przy poświadczeniu wykrywalnym, discoverable credential, klient może je wybrać bez uprzedniego podania loginu. Odpowiedź zawiera wówczas uchwyt użytkownika, userHandle. Serwer nadal sprawdza jego związek z identyfikatorem poświadczenia i kontem. Nie traktuje samego uchwytu jako dowodu.

Konkretny podpis: ECDSA P-256 z SHA-256

P-256: P-256. Nazwa krzywej nad ciałem pierwszym o 256-bitowym module. To identyfikator parametrów, nie rozwinięcie akronimu.

ECDSA, Elliptic Curve Digital Signature Algorithm, to algorytm podpisu na krzywej eliptycznej. Rozpatrujemy profil ES256, czyli ECDSA z SHA-256 na P-256, o identyfikatorze COSE $-7$ . FIDO2 nie wymaga, aby wszystkie urządzenia obsługiwały wyłącznie ten algorytm. RP proponuje algorytmy, a uwierzytelniacz wybiera obsługiwany. To nie jest BLS i nie wykorzystujemy pairingu.

Tu jawnie przechodzimy do krzywej, dlatego używamy notacji addytywnej. Punkt bazowy $P$ ma rząd $q$ , będący liczbą pierwszą, a współrzędne należą do ciała o module $p$ . To dwa różne moduły. $x(R)$ oznacza współrzędną punktu, odczytaną jako liczbę. Parametry krzywej ustala standard, nie losujemy ich od nowa przy każdym logowaniu.

\Sigma_{\mathrm{ES256}}=(\mathsf{Setup},\mathsf{KeyGen},\mathsf{Sign},\mathsf{Verify}).

Algorytm	Wejście, wynik i wykonywane operacje
$\mathsf{Setup}(1^\lambda)\to pp_{\mathrm{sig}}$	Wybierz standardowy profil P-256, $P$ , $q$ , SHA-256 i kodowania. Profil ma ustaloną siłę, około 128 bitów, a nie dowolne $\lambda$
$\mathsf{KeyGen}(pp_{\mathrm{sig}})\to(A,a)$	Wylosuj $a\overset{\$}{\leftarrow}\mathbb Z_q^*$ . Oblicz $A=a\cdot P$ . Tutaj $sk_{\mathrm{cred}}=a$ i $pk_{\mathrm{cred}}=A$
$\mathsf{Sign}(pp_{\mathrm{sig}},a,B)\to(r,s)$	Oblicz $z=\operatorname{OS2IP}(\operatorname{SHA256}(B))$ . Wylosuj $u\overset{\$}{\leftarrow}\mathbb Z_q^*$ , oblicz $R=u\cdot P$ , $r=x(R)\bmod q$ i $s=u^{-1}\cdot(z+r\cdot a)\bmod q$ . Gdy $r=0$ lub $s=0$ , ponów losowanie
$\mathsf{Verify}(pp_{\mathrm{sig}},A,B,(r,s))\to b$	Sprawdź poprawność klucza oraz $1\le r<q$ i $1\le s<q$ . Niespełnienie choć jednego warunku oznacza odrzucenie. Odtwórz $z$ , oblicz $w=s^{-1}\bmod q$ i $X=(z\cdot w)\cdot P+(r\cdot w)\cdot A$ . Odrzuć punkt w nieskończoności. Zwróć $b=1$ dokładnie wtedy, gdy $x(X)\bmod q=r$ . Odrzucenie oznacza $b=0$

OS2IP, Octet String to Integer Primitive, odczytuje ciąg bajtów jako nieujemną liczbę. SHA-256 oznacza Secure Hash Algorithm z 256-bitowym wynikiem. W ES256 występują dwa różne haszowania: najpierw danych klienta, a potem całego $B$ wewnątrz ECDSA. To nie hash-to-point. Biblioteka podpisująca z ustawieniem SHA-256 otrzymuje $B$ , a nie jego skrót przygotowany ponownie przez aplikację.

Poprawność wynika bezpośrednio z algebry. Weryfikator nie zna $a$ ani $u$ , lecz dla uczciwego podpisu uzyskuje

X=(z\cdot s^{-1})\cdot P+(r\cdot s^{-1})\cdot(a\cdot P) =\bigl((z+r\cdot a)\cdot s^{-1}\bmod q\bigr)\cdot P =u\cdot P=R.

To pokazuje, dlaczego uczciwy wynik jest akceptowany. Nie jest jeszcze dowodem niepodrabialności całego WebAuthn. Sekretny nonce $u$ w ECDSA nie jest publicznym wyzwaniem $c$ serwera. Wyciek lub błędne ponowne użycie $u$ może ujawnić klucz podpisu, mimo poprawnego losowania $c$ . Istnieją także standaryzowane warianty deterministycznego wyprowadzania nonce. Nie należy implementować własnego generatora na podstawie tego poglądowego opisu. FIPS 186-5, algorytmy COSE, RFC 9053 §2.1.

Lokalna zgoda: kod, dotknięcie i biometria

PIN, Personal Identification Number, jest kodem lokalnej kontroli dostępu. Biometria może pełnić podobną rolę. Nie zastępują klucza prywatnego i nie są przesyłane do RP jako hasło. UP, User Presence, oznacza potwierdzenie obecności, np. dotknięcie urządzenia. UV, User Verification, oznacza wykonaną przez uwierzytelniacz weryfikację użytkownika. Samo dotknięcie nie musi spełniać UV. Przy wymaganym UV serwer musi sprawdzić odpowiednią flagę, a nie tylko zażądać jej w interfejsie.

W kluczu zewnętrznym PIN może być wpisany na komputerze, ale CTAP nie przesyła go do klucza otwartym tekstem. Przykładowy PIN/UV Auth Protocol Two używa ECDH, czyli Elliptic Curve Diffie–Hellman, do wyprowadzenia wspólnego materiału. HKDF-SHA-256 wyprowadza osobne klucze szyfrowania i uwierzytelniania. HKDF to HMAC-based Extract-and-Expand Key Derivation Function, funkcja wyprowadzania kluczy oparta na HMAC. HMAC to Hash-based Message Authentication Code, kod uwierzytelniania oparty na funkcji skrótu.

W tym profilu używa się AES-256-CBC do szyfrowania odpowiednich pól protokołu i HMAC-SHA-256 do kontroli autentyczności. AES to Advanced Encryption Standard, a CBC to Cipher Block Chaining. Po poprawnej lokalnej weryfikacji klient uzyskuje ograniczony uprawnieniami token PIN/UV, którym uwierzytelnia dozwolone polecenia. To osobny mechanizm od podpisu poświadczenia wysyłanego do RP. Nie wykorzystuje tego samego klucza prywatnego do podpisu i do ECDH. Szczegóły kodowania i zakresy tokenów określa CTAP 2.2, §6.5.

Dlaczego poprawny podpis nie wystarcza

Weryfikacja matematyczna jest tylko jednym warunkiem. W modelu AuthFinish oznacza koniunkcję następujących kontroli:

Poświadczenie i konto. Znajdź wcześniej zapisany klucz dla $\mathrm{cid}$ . Sprawdź dozwolone konto i ewentualny userHandle. Nie przyjmuj klucza publicznego dołączonego dowolnie przez logującego się.
Typ i świeżość. Wymagaj webauthn.get, zgodnego wyzwania, właściwej sesji oczekującej i nieprzekroczonego terminu. Zaakceptowany stan zużyj tylko raz.
Pochodzenie i usługa. Sprawdź origin z listą dopuszczoną przez RP oraz skrót RP ID. Nasz profil nie dopuszcza kontekstu obcej ramki.
Lokalna kontrola. Sprawdź UP i wymaganą przez politykę UV. Obsłuż flagi i kodowania zgodnie z profilem.
Podpis. Odtwórz $B$ z otrzymanych bajtów i sprawdź $\mathsf{Verify}(pk_{\mathrm{cred}},B,\sigma)=1$ .
Stan poświadczenia. Uwzględnij licznik i politykę kopii. BE, Backup Eligibility, oznacza możliwość wykonania kopii, a BS, Backup State, stan wykonania kopii. BS nie może być ustawione bez BE. Nie są to dowody konkretnego modelu sprzętu.

Spadek lub brak wzrostu niezerowego licznika może być sygnałem problemu, nie dowodem sklonowania urządzenia. Część poświadczeń ma licznik równy zero. Synchronizacja i współbieżne logowania wymagają właściwej polityki. Licznik nie zastępuje świeżego wyzwania. WebAuthn, §7.2.

Podpis odpowiedzi i niezależne kontrole RP

Model warstwy podpisu WebAuthn z ECDSA P-256 w WebCrypto. Nie wywołuje urządzenia FIDO ani navigator.credentials. Błędne konteksty są wstrzykiwane do lokalnego testu.

Oczekiwane wyzwanieoczekuje

Klucz publiczny P-256 · 65 bajtówoczekuje

Otrzymane clientDataJSONoczekuje

SHA-256 otrzymanych danych klientaoczekuje

authenticatorData · 37 bajtówoczekuje

B podpisane przez urządzenie · 69 bajtówoczekuje

B odtworzone przez RP · 69 bajtówoczekuje

Podpis ECDSA · r ∥ soczekuje

Klucz publiczny pokazano jako nieskompresowany punkt (04 ∥ x ∥ y), nie jako COSE_Key. Podpis WebCrypto ma 64 bajty (r ∥ s). WebAuthn ES256 przesyła go w kodowaniu ASN.1 DER. W wariancie zmiany danych po podpisaniu RP odtwarza inne B. To model podpisanych danych i kontroli kontekstu, nie pełny parser WebAuthn.

Gotowe do rozpoczęcia.

Pełne wartości przebiegu

Jeszcze nie wykonano obliczeń.

ASN.1: Abstract Syntax Notation One. Notacja opisu abstrakcyjnych struktur danych.
DER: Distinguished Encoding Rules. Jednoznaczne reguły kodowania danych ASN.1.

W przykładzie klucz publiczny, skrót danych klienta i podpisane bajty są wyliczane rzeczywiście w WebCrypto. Klucz prywatny pozostaje w lokalnym obiekcie kryptograficznym i nie jest wyświetlany. Nie jest to jednak fizyczny klucz FIDO ani atestowana izolacja sprzętowa. Każdy nowy przebieg przygotowuje testowy klucz jako odpowiednik już przeprowadzonej rejestracji. Testy z innym originem lub RP ID celowo wstrzykują błędny kontekst do modelu odbiorcy. Nie demonstrują obejścia ograniczeń prawdziwej przeglądarki.

Kodowanie podpisu też ma znaczenie. WebCrypto zwraca dla P-256 64 bajty $r\Vert s$ . WebAuthn ES256 używa ASN.1 DER, Abstract Syntax Notation One, Distinguished Encoding Rules, czyli sekwencji dwóch liczb z informacjami o typie i długości. Ten sam podpis matematyczny ma inne bajty w tych dwóch formatach. Nie wystarczy przesłać jednego formatu do parsera drugiego.

Co ten mechanizm gwarantuje, a czego nie

Odporność na phishing jest własnością złożenia. Fałszywa witryna nie może przez zgodną przeglądarkę zażądać użycia dowolnego cudzego RP ID. Rzeczywisty serwer sprawdza origin, RP ID i wyzwanie objęte podpisem. Sam ECDSA nie rozumie nazw domen. Niepodrabialność podpisu, kontrola pochodzenia i stan jednorazowego żądania odpowiadają na różne zagrożenia.

Przechwycona stara odpowiedź nie powinna otwierać nowej sesji. Nowe wyzwanie i jednorazowy stan RP blokują jej ponowne użycie.
Wykradzenie bazy kluczy publicznych nie daje kluczy prywatnych. Możliwość zmiany tej bazy jest jednak innym, bardzo poważnym zagrożeniem.
Przejęcie przeglądarki, magazynu poświadczeń, procesu synchronizacji lub aktywnej sesji wykracza poza samo fałszowanie podpisu. Ochrona sprzętowa ogranicza określone ataki na sekret, ale nie naprawia automatycznie całego komputera.
Atestacja może pomóc RP ocenić pochodzenie uwierzytelniacza. Nie jest podpisem dokumentu przez użytkownika, nie potwierdza jego nazwiska i nie gwarantuje braku wszystkich podatności.

W porównaniu z interaktywnym Schnorrem wyzwanie pochodzi od serwera, ale odpowiedź jest tutaj podpisem ustrukturyzowanej wiadomości, nie samą odpowiedzią skalarnego protokołu identyfikacji. W porównaniu z AKE nie wyprowadzamy wspólnego klucza do szyfrowania ruchu aplikacji. Tym zajmuje się warstwa kanału. Ten podział pozwala wskazać, co dokładnie musimy udowodnić i które dodatkowe założenia pozostają po stronie systemu.

Sprawdź rozumienie: co zmienia się po przeniesieniu poświadczenia do drugiego urządzenia, a co pozostaje takie samo w równaniu weryfikacji? Dlaczego dotknięcie klucza nie zawsze oznacza UV? Dlaczego weryfikacja podpisu starej odpowiedzi może być poprawna, a logowanie odrzucone? Rozwinięcie rachunków: C18. Odtworzenie podpisanych bajtów i kodowania DER w Pythonie: L13.

W10e. SSO i federacja: komu ufa aplikacja

SSO: Single Sign-On. Jednokrotne logowanie wykorzystywane przez wiele usług.

Passkey odpowiada na pytanie „jak dowieść kontroli poświadczenia?”. Federacja odpowiada na inne: „jak aplikacja może skorzystać z uwierzytelnienia wykonanego przez zaufanego dostawcę?”. Te mechanizmy mogą działać razem. Dostawca tożsamości może uwierzytelnić użytkownika przez FIDO2, a następnie wystawić komunikat dla aplikacji.

SSO, czyli single sign-on, to możliwość korzystania z wielu usług bez ponownego wykonywania pełnego logowania za każdym razem. Nie oznacza jednego uniwersalnego tokenu dla wszystkich usług. Dostawca ma swoją sesję, a każda aplikacja tworzy własną po sprawdzeniu odpowiedzi skierowanej właśnie do niej.

Przykład: student otwiera portal kursu, a potem bibliotekę. Obie aplikacje ufają temu samemu uczelnianemu dostawcy tożsamości. Dostawca może skorzystać z istniejącej sesji, ale wystawia odpowiedzi dla różnych odbiorców. Biblioteka nie powinna akceptować tokenu wydanego portalowi kursu. SSO ułatwia pracę użytkownika, nie znosi granic między aplikacjami.

OpenID Connect: kod, PKCE, token i sesja

PKCE: Proof Key for Code Exchange. Powiązanie wymiany kodu autoryzacyjnego z sekretem klienta.

OAuth 2.0 dotyczy delegowania dostępu do zasobów. OpenID Connect, OIDC, dodaje warstwę uwierzytelniania, w tym ID Token. Access token służy do wywołań API i nie zastępuje ID Tokenu. Opiszemy przepływ kodu autoryzacyjnego z PKCE dla aplikacji z backendem.

OAuth: OAuth. Nazwa mechanizmu delegowania uprawnień. Nie oznacza Open Authentication i sama nie definiuje logowania użytkownika.

Aplikacja tworzy stan transakcji związany z przeglądarką. Losuje state, nonce i sekret PKCE code_verifier.
Przekierowuje przeglądarkę do zaufanego dostawcy, podając m.in. client_id, dokładny redirect_uri, scope=openid, state, nonce i wyzwanie PKCE.
Dostawca uwierzytelnia użytkownika lub wykorzystuje istniejącą sesję zgodnie z żądaniem. Przez przeglądarkę odsyła krótko ważny kod i state do zarejestrowanego adresu.
Backend kontroluje odpowiedź i wymienia kod na tokeny przez TLS. Przekazuje weryfikator PKCE. Klient poufny dodatkowo uwierzytelnia się metodą zarejestrowaną u dostawcy.
Aplikacja weryfikuje ID Token i kontekst. Dopiero wtedy ustanawia własną sesję użytkownika.

PKCE (Proof Key for Code Exchange) wiąże dwa etapy. Dla losowego ciągu $v$ o wymaganej entropii i dozwolonym formacie:

\mathrm{code\_challenge}= \operatorname{base64url}\bigl(\operatorname{SHA256}(\operatorname{ASCII}(v))\bigr).

Kod zostaje związany z tym wyzwaniem, klientem i adresem powrotu. Podczas wymiany serwer przelicza je z otrzymanego $v$ . Sam przechwycony kod nie wystarcza bez tego sekretu. PKCE nie jest podpisem użytkownika i nie usuwa pozostałych kontroli. Konstrukcję definiuje RFC 7636. Aktualne wymagania bezpieczeństwa przepływów OAuth opisuje RFC 9700.

OIDC · droga kodu i sprawdzenie tokenu

Lokalny model przepływu z backendem. SHA-256 dla PKCE i rzeczywisty JWS ES256. Bez połączenia z dostawcą tożsamości. Adresy example są nazwami demonstracyjnymi.

Sekret PKCE · code_verifieroczekuje

Publiczne code_challengeoczekuje

Deklaracje ID Tokenuoczekuje

Podpisany token JWSoczekuje

Gotowe do rozpoczęcia.

Pełne wartości przebiegu

Jeszcze nie wykonano obliczeń.

JWS: JSON Web Signature. Format ochrony treści podpisem cyfrowym lub kodem uwierzytelnienia.

Jaki dokument podpisuje dostawca

W popularnym formacie JWS Compact token ma trzy części: zakodowany nagłówek $h$ , zakodowany zestaw deklaracji $p$ i zakodowany podpis. Podpis obejmuje dokładne bajty

B=\operatorname{ASCII}(h\mathbin\Vert\mathtt{.}\mathbin\Vert p), \qquad \sigma=\operatorname{Sign}_{sk_{\mathrm{IdP}}}(B).

Kodowanie base64url nie szyfruje danych. Algorytm wynika z uzgodnionego profilu i listy dozwolonej przez odbiorcę, a nie z bezwarunkowego zaufania do pola alg przysłanego przez napastnika. Można tu spotkać podpisy RSA lub krzywych eliptycznych. Przykładowo RS256 oznacza RSASSA-PKCS1-v1_5 z SHA-256, a PS256 oznacza RSA-PSS z SHA-256 i solą 32-bajtową. ES256 oznacza ECDSA na P-256 z SHA-256. Te identyfikatory nie są zamienne. Formaty podpisów i parametry określają JWS, RFC 7515 oraz JWA, RFC 7518.

RS256: RSASSA-PKCS1-v1_5 using SHA-256. Identyfikator podpisu RSA z kodowaniem PKCS #1 v1.5 i haszem SHA-256.
RSASSA-PKCS1-v1_5: RSA Signature Scheme with Appendix, PKCS #1 version 1.5. Podpis RSA ze starszym kodowaniem ze standardu PKCS #1.
PS256: RSASSA-PSS using SHA-256 and MGF1 with SHA-256. Identyfikator podpisu RSA-PSS z haszem SHA-256.
JWA: JSON Web Algorithms. Specyfikacja algorytmów i ich identyfikatorów dla formatów tokenów.

W naszym profilu aplikacja zawsze sprawdza podpis kluczem uzyskanym z zaufanej konfiguracji wystawcy, np. jego JWKS. Klucz znaleziony pod dowolnym adresem wskazanym w niezweryfikowanym tokenie nie tworzy zaufania. Rotację kluczy trzeba obsłużyć, zachowując to przypisanie do wystawcy.

JWKS: JSON Web Key Set. Zestaw kluczy zapisanych w formacie JSON Web Key.

Kontrola	Co chroni
`iss` zgodny z oczekiwanym wystawcą	Nie przyjmujemy tokenu innego dostawcy
`aud` obejmuje nasze `client_id`, a `azp` jest sprawdzone, gdy wymagane	Token dla innej aplikacji nie otwiera naszej
`exp`, `iat` i wymagany kontekst czasu	Odrzucamy tokeny przeterminowane i niespójne z polityką
`nonce` zgodny z rozpoczętą transakcją	Podpisany token z innego logowania nie jest odpowiedzią na to żądanie
Kod jednorazowy, właściwy redirect URI i PKCE	Chronimy powiązanie etapów wymiany
`state` związany z lokalną sesją przeglądarki	Kontrolujemy powrót do rozpoczętego przepływu

URI: Uniform Resource Identifier. Jednolity identyfikator zasobu.

Tożsamość konta identyfikujemy parą $(\mathrm{iss},\mathrm{sub})$ . Sam zgodny napis adresu e-mail nie jest uniwersalnym dowodem, że dwa konta należy połączyć. Dokładne wymagania dla tokenów i przepływu zawiera OpenID Connect Core, §3.1. state, nonce i PKCE mają różne miejsca w protokole. W wybranych profilach część ich zabezpieczeń się pokrywa, ale nie wolno usuwać ich bez analizy konkretnego modelu.

SAML, TOTP i certyfikaty: ta sama potrzeba, inne narzędzia

SAML: Security Assertion Markup Language. Język opisu stwierdzeń dotyczących bezpieczeństwa, m.in. uwierzytelnienia.
TOTP: Time-based One-Time Password. Hasło jednorazowe zależne od czasu.

SAML 2.0 jest ważną rodziną federacji w środowiskach instytucjonalnych. Dostawca wystawia asercję XML. Podpis asercji lub odpowiedzi zapewnia integralność zgodnie z profilem. Odbiorca sprawdza zaufanego wystawcę, odbiorcę, czas i związek z żądaniem, np. InResponseTo. Musi przetwarzać dokładnie ten element, którego podpis zweryfikował. Weryfikacja jednego fragmentu XML i użycie innego nie daje ochrony. Schemat SSO pozostaje podobny do OIDC, ale formaty, wiązania transportowe i zasady podpisu nie są wymienne. OASIS SAML, przegląd techniczny §5.1.

XML: Extensible Markup Language. Rozszerzalny język znaczników.
OASIS: Organization for the Advancement of Structured Information Standards. Organizacja rozwijająca standardy wymiany danych.

TOTP generuje krótki kod ze wspólnego sekretu $K$ i numeru przedziału czasu $T$ . Dla początku epoki $t_0$ , kroku $\Delta$ i liczby cyfr $d$ :

T=\left\lfloor\frac{t-t_0}{\Delta}\right\rfloor,\qquad \mathrm{OTP}=\operatorname{Trunc}(\operatorname{HMAC}_K(\operatorname{enc}_{64}(T)))\bmod10^d.

$\operatorname{Trunc}$ oznacza zdefiniowane w HOTP dynamiczne wycięcie 31-bitowej wartości. Serwer dopuszcza określone okno czasu, ogranicza próby i nie przyjmuje ponownie już wykorzystanego kodu. Kod nie jest związany z origin witryny. Fałszywa strona może przekazać go prawdziwej usłudze w czasie ważności, dlatego drugi składnik nie musi być odporny na phishing. To konstrukcja HMAC, nie podpis cyfrowy. RFC 6238.

HOTP: HMAC-based One-Time Password. Hasło jednorazowe oparte na HMAC i liczniku.

Certyfikat klienta w TLS wiąże z kolei podpis z transkryptem konkretnego połączenia. Łańcuch certyfikatów i polityka usługi określają, komu przypisać klucz. Jest to inne związanie kontekstu niż RP ID w WebAuthn i inne niż podpisany ID Token.

Mechanizm	Kto dowodzi lub poświadcza	Co stanowi kontekst
FIDO2 / passkey	Uwierzytelniacz używający klucza poświadczenia	Wyzwanie, origin i RP ID
OIDC / SAML	Zaufany dostawca tożsamości	Wystawca, odbiorca, transakcja i czas
TOTP	Posiadacz wspólnego sekretu	Przedział czasu, bez związania z domeną
Klient TLS z certyfikatem	Posiadacz klucza prywatnego certyfikatu	Transkrypt połączenia TLS

Od równania weryfikacji do bezpieczeństwa logowania

Przeciwnik nie zawsze musi sfałszować podpis. Może powtórzyć stary token, przekazać prawdziwy token złej aplikacji albo przejąć sesję już po logowaniu. Sensowny cel mówi: aplikacja nie akceptuje świeżej transakcji jako konta ofiary bez odpowiedniego zdarzenia uwierzytelnienia u właściwej strony, przy zadeklarowanych założeniach o TLS, klientach, rejestracji i kluczach.

Dla pojedynczego, niezależnego, równomiernego wyzwania $b$ -bitowego prawdopodobieństwo trafienia go jedną wcześniej przygotowaną odpowiedzią wynosi $2^{-b}$ . To tylko jeden składnik analizy. Dowód całego protokołu musi jeszcze wykluczyć zamianę odbiorcy, pomieszanie sesji, przejęcie klucza i niedozwolone ponowne użycie. EUF-CMA podpisu nie jest samodzielnym dowodem bezpieczeństwa SSO.

Po logowaniu aplikacja chroni identyfikator sesji, np. ciasteczkiem Secure, HttpOnly i odpowiednią polityką SameSite. Musi obsłużyć CSRF, wygaśnięcie, odnowienie i wylogowanie. Odzyskiwanie konta nie może niejawnie obniżać całej ochrony do słabego kanału. To kontynuacja tej samej zasady z AKE: matematyka działa w określonym kontekście protokołu i urządzenia.

CSRF: Cross-Site Request Forgery. Fałszowanie żądań między witrynami.

Powiązania: C18, L13.