WUA wyjaśnione: jak portfel potwierdza swoją autentyczność wobec wydawcy
Wallet Unit Attestation, WUA, to dowód, który EUDI Wallet pokazuje PID Provider lub Attestation Provider podczas wydawania, aby udowodnić, że jest autentyczny. To nie jeden dokument, lecz dwa, oba podpisane przez dostawcę portfela: Wallet Instance Attestation (WIA) dotycząca aplikacji portfela oraz Key Attestation (KA) dotycząca bezpiecznego magazynu kluczy, z którymi zostanie powiązane poświadczenie.
Problem, który rozwiązuje WUA
Wydawca, który ma przekazać portfelowi PID lub poświadczenie rejestracji firmy, nie ma wbudowanego sposobu, by odróżnić certyfikowany EUDI Wallet od zmodyfikowanej aplikacji albo skryptu odtwarzającego przepływ autoryzacji. Nie widzi też, czy klucz, z którym zostanie powiązane poświadczenie, znajduje się w certyfikowanym bezpiecznym sprzęcie, czy w zwykłej pamięci, z której można go skopiować.
WUA zamyka obie te luki. Dostawca portfela ręczy za aplikację poprzez WIA, a za magazyn kluczy poprzez Key Attestation. Wydawca sprawdza oba przed wydaniem i później nadal kontroluje ich status unieważnienia, aby móc unieważnić to, co wydał, jeśli portfel lub jego magazyn kluczy okaże się później skompromitowany.
WUA jest używane wyłącznie podczas wydawania. ARF zabrania jednostce portfela przedstawiania WIA lub Key Attestation stronie Relying Party, dzięki czemu szczegóły portfela nie trafiają do żadnej prezentacji.
Uczestnicy i kto komu ufa
W procesie uczestniczy pięć ról, a tylko cztery z nich mają kiedykolwiek do czynienia z WUA. WSCD (Wallet Secure Cryptographic Device) lub keystore generuje i chroni klucze, dostawca portfela ręczy za aplikację i klucze, a wydawca polega na tym, zamiast samodzielnie oceniać portfel.
Dostawca portfela
Podpisuje WIA i Key Attestation po sprawdzeniu aplikacji i magazynu kluczy oraz prowadzi Status Lists dla obu
Jednostka portfela
Wysyła WIA i Key Attestation do wydawcy podczas wydawania i każdego z nich używa tylko do jednego wydania
WSCD lub keystore
Generuje i przechowuje klucze prywatne opisane w Key Attestation
PID Provider lub Attestation Provider
Weryfikuje WIA i Key Attestation, wiąże poświadczenie z atestowanym kluczem i nadal sprawdza, czy żadne z nich nie zostało unieważnione
Relying Party
Nigdy nie otrzymuje WUA. Zamiast tego sprawdza poświadczenie, jego powiązanie z urządzeniem i status unieważnienia
Wydawcy ufają WUA, ponieważ certyfikat podpisujący dostawcy portfela, przesyłany w nagłówku x5c, prowadzi do kotwicy zaufania na Trusted List dla dostawców portfeli. Sama Wallet Solution jest certyfikowana przez jednostkę oceniającą zgodność, a WIA zawiera informacje o tej certyfikacji.
Dwie atestacje pod jedną nazwą
TS3, specyfikacja techniczna EUDI dotycząca WUA, dzieli atestację na dwie części, ponieważ aplikacja i magazyn kluczy to różne rzeczy, sprawdzane w różnych endpointach i unieważniane z różnych powodów.
Wallet Instance Attestation (WIA)
- Poświadcza
- Integralność Wallet Instance, czyli aplikacji
- Odbiorca
- Authorization Server, w Pushed Authorization Request i Token Request
- Ważność
- Mniej niż 24 godziny
- Unieważnienie
- client_status: stan unieważnienia tej Wallet Instance
- Wymagane do
- Każdego wydania, powiązanego z urządzeniem lub nie
Key Attestation (KA)
- Poświadcza
- Że jeden lub więcej kluczy wygenerowano w określonym WSCD lub keystore i są w nim przechowywane, oraz jak odporny na ataki jest ten magazyn
- Odbiorca
- Credential Issuer, w proofs w Credential Request
- Ważność
- Ustalana przez dostawcę portfela, może być dłuższa niż w przypadku WIA
- Unieważnienie
- key_storage_status: stan unieważnienia WSCD lub keystore
- Wymagane do
- Tylko poświadczeń powiązanych z urządzeniem, w tym każdego PID
Oba są tokenami JWT podpisanymi przez dostawcę portfela algorytmem ES256, ES384 lub ES512. Key Attestation służy tylko do jednego wydania, a WIA nigdy nie jest ponownie używane wobec innego wydawcy, więc wydawcy nie mogą powiązać ze sobą żądań z tego samego portfela.
Jak jednostka portfela uzyskuje WIA i Key Attestation
TS3 pozostawia ten krok poszczególnym dostawcom portfeli, ponieważ odbywa się on wewnątrz jednego produktu portfelowego. ARF wymaga jedynie, aby dostawca portfela sprawdził integralność aplikacji przed podpisaniem WIA oraz sprawdził, że atestowane klucze prywatne rzeczywiście znajdują się we wskazanym WSCD lub keystore, zanim podpisze Key Attestation. Typowy przepływ, w którym dowodem są atestacje platformy, takie jak Google Play Integrity lub Apple DeviceCheck, wygląda następująco.
1. Jednostka portfela
Prosi WSCD lub keystore o wygenerowanie par kluczy
2. WSCD lub keystore
Zwraca klucze publiczne wraz z dowodem platformy, gdzie zostały wygenerowane
3. Dostawca portfela
Sprawdza integralność aplikacji i dowody dotyczące kluczy, a następnie podpisuje WIA i Key Attestation
4. Jednostka portfela
Utrzymuje zapas świeżych WIA i Key Attestation i do każdego wydania używa nowego
Co zawierają WIA i Key Attestation
Żadne z nich nie zawiera claimu iss: wydawca identyfikuje dostawcę portfela na podstawie certyfikatu podpisującego w nagłówku x5c. Poniższe przykłady są zdekodowane, a nagłówek i payload oddziela kropka.
Wallet Instance Attestation
{
"typ": "oauth-client-attestation+jwt",
"alg": "ES256",
"x5c": ["MIIC..."]
}.{
"sub": "https://wallet.example.eu",
"wallet_name": "ExampleWallet-mobile",
"wallet_version": "2.3.0",
"wallet_link": "https://wallet.example.eu/about",
"wallet_solution_certification_information": "https://wallet.example.eu/certification/2-3-0",
"exp": 1789329600,
"client_status": {
"status": {
"status_list": { "idx": 48213, "uri": "https://wallet.example.eu/status/wia/17" }
},
"exp": 1791936000
},
"cnf": {
"jwk": { "kty": "EC", "crv": "P-256", "x": "...", "y": "..." }
}
}| Pole | Co mówi wydawcy |
|---|---|
| typ / x5c | Że jest to client attestation, oraz łańcuch certyfikatów dostawcy portfela do sprawdzenia względem Trusted List |
| sub | Typ portfela, taki sam dla każdej instalacji, więc nie można go użyć do śledzenia użytkownika |
| wallet_name / wallet_version | Wallet Solution w postaci wpisanej na Trusted List oraz jej wersja |
| wallet_solution_certification_information | Kto certyfikował Wallet Solution; dokładna zawartość nie została jeszcze określona |
| exp | Techniczne wygaśnięcie, mniej niż 24 godziny po sprawdzeniu integralności |
| client_status | Wpis na Status List dla tej Wallet Instance oraz data, do której dostawca portfela go aktualizuje |
| cnf | Klucz, który podpisuje dowód posiadania wysyłany razem z WIA |
Key Attestation
{
"typ": "key-attestation+jwt",
"alg": "ES256",
"x5c": ["MIIC..."]
}.{
"iat": 1789257600,
"exp": 1791936000,
"certification": "https://wallet.example.eu/certification/wscd/secure-element",
"key_storage": ["iso_18045_high"],
"user_authentication": ["iso_18045_high"],
"attested_keys": [
{ "kty": "EC", "crv": "P-256", "x": "...", "y": "..." },
{ "kty": "EC", "crv": "P-256", "x": "...", "y": "..." }
],
"key_storage_status": {
"status": {
"status_list": { "idx": 3, "uri": "https://wallet.example.eu/status/ka/1" }
},
"exp": 1794614400
}
}| Pole | Co mówi wydawcy |
|---|---|
| typ / x5c | Że jest to key attestation, oraz łańcuch certyfikatów dostawcy portfela do sprawdzenia względem Trusted List |
| iat / exp | Kiedy została wydana i kiedy technicznie wygasa |
| attested_keys | Klucze publiczne, których klucze prywatne WSCD lub keystore wygenerował i przechowuje; kilka kluczy umożliwia wydawanie wsadowe |
| key_storage / user_authentication | Jak odporne na ataki są magazyn oraz uwierzytelnianie użytkownika odblokowujące klucze; WSCD ma zawsze iso_18045_high dla obu |
| certification | Certyfikacja WSCD lub keystore, na podstawie której wydawca może stwierdzić, czy jest to WSCD |
| key_storage_status | Wpis na Status List dla WSCD lub keystore oraz data, do której dostawca portfela go aktualizuje |
| nonce | c_nonce wydawcy, obecny tylko wtedy, gdy Key Attestation jest wysyłana jako attestation proof |
Dokąd trafia WUA podczas wydawania w OpenID4VCI
Obie atestacje trafiają w różne miejsca. WIA uwierzytelnia portfel jako klienta OAuth w Authorization Server. Key Attestation trafia do Credential Issuer razem z żądaniem samego poświadczenia.
Authorization Server otrzymuje WIA
- Podpis WIA prowadzi do Trusted List dla dostawców portfeli
- WIA nie wygasło, a Wallet Instance nie jest unieważniona
- Dowód posiadania jest podpisany kluczem z claimu cnf w WIA
Credential Issuer otrzymuje Key Attestation
- Podpis Key Attestation prowadzi do Trusted List dla dostawców portfeli
- Świeży c_nonce wydawcy znajduje się w jwt proof lub w samej Key Attestation
- WSCD lub keystore nie jest unieważniony, a poświadczenie zostaje powiązane z jednym z attested_keys
Pushed Authorization Request z WIA
POST /par HTTP/1.1 Host: issuer.example.eu Content-Type: application/x-www-form-urlencoded OAuth-Client-Attestation: <WIA JWT> OAuth-Client-Attestation-PoP: <PoP JWT signed with the WIA cnf key> response_type=code &client_id=https%3A%2F%2Fwallet.example.eu &scope=company_registration &code_challenge=<S256 challenge> &code_challenge_method=S256 &redirect_uri=<wallet redirect URI>
client_id odpowiada wartości sub w WIA. Token Request zawiera te same dwa nagłówki. Ponieważ Credential Issuer nigdy nie widzi WIA, Authorization Server musi przekazać mu client_status, na przykład w access tokenie.
Credential Request z Key Attestation
POST /credential HTTP/1.1
Host: issuer.example.eu
Authorization: DPoP <access_token>
DPoP: <DPoP proof JWT>
Content-Type: application/json
{
"credential_configuration_id": "company_registration",
"proofs": {
"jwt": ["<proof JWT: Key Attestation in its key_attestation header, signed with attested_keys[0]>"]
}
}Przy typie proof attestation żądanie zawiera zamiast tego "proofs": { "attestation": ["<JWT Key Attestation>"] }. Nie ma wtedy dowodu posiadania: jednostka portfela przekazuje c_nonce wydawcy dostawcy portfela, który umieszcza go w nowo podpisanej Key Attestation.
Cykl życia WUA
WUA celowo jest krótkotrwałe i jednorazowe, ale stojące za nim informacje o unieważnieniu żyją dłużej niż sam token. Pierwsze trzy etapy są rutynowe; czwarty zachodzi tylko wtedy, gdy coś pójdzie nie tak.
1. Wydanie
Dostawca portfela podpisuje WIA i Key Attestation po sprawdzeniu integralności i magazynu kluczy
2. Jednorazowe użycie
Każde służy do jednego wydania, więc jednostka portfela stale pobiera nowe
3. Łańcuchowe unieważnianie
PID Provider co najmniej co 24 godziny ponownie sprawdza status WIA i Key Attestation i unieważnia PID, jeśli którekolwiek z nich zostało unieważnione
4. Unieważnienie
Dostawca portfela unieważnia Wallet Instance, na przykład po utracie lub kradzieży, albo WSCD lub keystore z luką bezpieczeństwa
Poza ekosystemem EUDI Wallet niektórzy dostawcy portfeli wydają atestacje portfela o bardzo krótkim okresie ważności i bez żadnego odwołania do statusu, polegając na wygaśnięciu zamiast na unieważnieniu; OpenID4VCI czyni claim statusu opcjonalnym. TS3 nie dopuszcza tego w przypadku EUDI Wallets. WIA żyje już mniej niż 24 godziny, a mimo to zarówno WIA, jak i Key Attestation muszą zawierać odwołanie do statusu, które dostawca portfela utrzymuje przez co najmniej 31 dni, ponieważ PID Providers używają go do unieważniania PID długo po wydaniu.
WUA, WIA i KA: co oznacza każde z pojęć
Terminologia zmieniała się wraz z dojrzewaniem specyfikacji. TS3 nazywała WIA Wallet App Attestation do wersji 1.1, a do wersji 1.5 używała nazwy WUA dla tego, co dziś jest Key Attestation. Dlatego starsze artykuły i wersje robocze ARF używają tych pojęć inaczej.
| Pojęcie | Co obejmuje | Kto je otrzymuje |
|---|---|---|
| WUA | Zbiorcze określenie dwóch poniższych atestacji | PID Providers i Attestation Providers, wyłącznie podczas wydawania |
| WIA | Wallet Instance, czyli aplikację | Authorization Server, w Pushed Authorization Request i Token Request |
| KA | WSCD lub keystore i przechowywane w nim klucze | Credential Issuer, w proofs w Credential Request |
Powiązane pojęcia
Najczęściej zadawane pytania
Czy WUA to to samo co Wallet Instance Attestation?
Nie. Od wersji 1.5 TS3 WUA jest zbiorczym określeniem dwóch atestacji: Wallet Instance Attestation (WIA), która dotyczy aplikacji, oraz Key Attestation (KA), która dotyczy WSCD lub keystore przechowującego klucze. Starsze dokumenty używają nazwy WUA dla tego, co dziś nazywa się Key Attestation, dlatego te pojęcia są często mylone.
Czy weryfikator kiedykolwiek widzi WUA?
Nie. Wymagania ARF WUA_07 i WUA_24 pozwalają jednostce portfela przedstawić WIA lub Key Attestation wyłącznie PID Provider lub Attestation Provider podczas wydawania, nigdy Relying Party. Weryfikator sprawdza zamiast tego poświadczenie: jego podpis, powiązanie z urządzeniem i status unieważnienia. Jeśli portfel, do którego należy PID, zostanie unieważniony, PID Provider unieważnia PID w ramach swojego 24-godzinnego cyklu kontroli, a weryfikator widzi to w statusie samego PID.
Jak długo WUA jest ważne?
WIA wygasa mniej niż 24 godziny po tym, jak dostawca portfela sprawdził integralność aplikacji. Key Attestation może być ważna dłużej, według uznania dostawcy portfela. Niezależnie od tego każde z nich zawiera datę utrzymania statusu, client_status.exp lub key_storage_status.exp, do której dostawca portfela aktualizuje status unieważnienia. Jednostka portfela musi zawsze móc przedstawić takie, którego data przypada za co najmniej 31 dni, a PID musi wygasnąć przed tą datą.
Co się dzieje, gdy jednostka portfela zostanie skompromitowana przed wygaśnięciem jej WUA?
Dostawca portfela unieważnia Wallet Instance na swojej Status List dla WIA, a w przypadku luki w danym typie WSCD lub keystore unieważnia wpis na Status List dla tego magazynu. PID Provider co najmniej raz na 24 godziny sprawdza status WIA i Key Attestation stojących za każdym wydanym przez siebie PID i unieważnia PID, gdy którekolwiek z nich zostało unieważnione. Attestation Providers mogą postępować tak samo. Portfel nie zostaje wykluczony przez samo wygaśnięcie WUA, lecz przez unieważnienie wydanych mu poświadczeń.
Czy jedna Key Attestation może obejmować więcej niż jeden klucz?
Tak. attested_keys może zawierać kilka kluczy publicznych z tego samego WSCD lub keystore i na tym właśnie polega wydawanie wsadowe: wydawca wiąże każde poświadczenie z partii z innym kluczem, a jeden podpis dostawcy portfela obejmuje je wszystkie. Gdy Key Attestation jest przesyłana w jwt proof, jednostka portfela podpisuje ten proof wyłącznie pierwszym kluczem z listy.
Źródła
Ta strona ma charakter wyłącznie informacyjny i nie stanowi porady prawnej. Wiążących wskazówek należy szukać bezpośrednio w Komisji Europejskiej i OpenID Foundation.