Pāriet uz galveno saturu

WUA skaidrojums: kā maks pierāda izsniedzējam, ka ir īsts

Wallet Unit Attestation (WUA) ir tas, ko EUDI Wallet izsniegšanas laikā parāda PID Provider vai Attestation Provider, lai pierādītu, ka ir īsts. Tas nav viens dokuments, bet divi, un abus paraksta Maka pakalpojumu sniedzējs: Wallet Instance Attestation (WIA) par maka lietotni un Key Attestation (KA) par to atslēgu drošo glabāšanu, kurām tiks piesaistīts apliecinājums.

Problēma, ko risina WUA

Izsniedzējam, kas gatavojas makam nodot PID vai uzņēmuma reģistrācijas apliecinājumu, nav iebūvēta veida, kā atšķirt sertificētu EUDI Wallet no modificētas lietotnes vai skripta, kas atkārto autorizācijas plūsmu. Tas arī nevar redzēt, vai atslēga, kurai tiks piesaistīts apliecinājums, atrodas sertificētā drošā aparatūrā vai parastā krātuvē, no kuras to varētu nokopēt.

WUA novērš abas nepilnības. Maka pakalpojumu sniedzējs galvo par lietotni ar WIA un par atslēgu krātuvi ar Key Attestation. Izsniedzējs pārbauda abus pirms izsniegšanas un arī pēc tam turpina pārbaudīt to atsaukšanas statusu, tāpēc var atsaukt izsniegto, ja vēlāk atklājas, ka maks vai tā atslēgu krātuve ir kompromitēta.

WUA tiek izmantots tikai izsniegšanas laikā. ARF aizliedz Maka vienībai uzrādīt WIA vai Key Attestation uzticamības pusei, tāpēc maka informācija neparādās nevienā uzrādīšanā.

Dalībnieki un kurš kam uzticas

Iesaistītas ir piecas lomas, un tikai četras no tām jebkad saskaras ar WUA. WSCD (Wallet Secure Cryptographic Device) vai atslēgu krātuve ģenerē un sargā atslēgas, Maka pakalpojumu sniedzējs galvo par lietotni un atslēgām, un izsniedzējs paļaujas uz to, nevis pats vērtē maku.

Maka pakalpojumu sniedzējs

Paraksta WIA un Key Attestation pēc lietotnes un atslēgu krātuves pārbaudes un uztur Status List abiem

Maka vienība

Izsniegšanas laikā nosūta izsniedzējam WIA un Key Attestation un katru izmanto tikai vienai izsniegšanai

WSCD vai atslēgu krātuve

Ģenerē un glabā privātās atslēgas, kuras apraksta Key Attestation

PID Provider vai Attestation Provider

Pārbauda WIA un Key Attestation, piesaista apliecinājumu atestētai atslēgai un turpina pārbaudīt, vai neviens no tiem nav atsaukts

Uzticamības puse

Nekad nesaņem WUA. Tā vietā pārbauda apliecinājumu, tā piesaisti ierīcei un atsaukšanas statusu

Izsniedzēji uzticas WUA, jo Maka pakalpojumu sniedzēja parakstīšanas sertifikāts, kas nosūtīts x5c galvenē, ved pa ķēdi līdz uzticamības enkuram Trusted List sarakstā, kas paredzēts Maka pakalpojumu sniedzējiem. Pašu Wallet Solution sertificē atbilstības novērtēšanas iestāde, un WIA satur informāciju par šo sertifikāciju.

Divas atestācijas ar vienu nosaukumu

TS3, EUDI tehniskā specifikācija par WUA, sadala atestāciju divās daļās, jo lietotne un atslēgu krātuve ir dažādas lietas, kas tiek pārbaudītas dažādos galapunktos un atsauktas dažādu iemeslu dēļ.

Wallet Instance Attestation (WIA)

Atestē
Wallet Instance, proti, lietotnes, integritāti
Tiek nosūtīts
Authorization Server, Pushed Authorization Request un Token Request ietvaros
Darbības laiks
Mazāk nekā 24 stundas
Atsaukšana
client_status: šīs Wallet Instance atsaukšanas statuss
Nepieciešams
Katrai izsniegšanai neatkarīgi no piesaistes ierīcei

Key Attestation (KA)

Atestē
To, ka viena vai vairākas atslēgas ir ģenerētas norādītajā WSCD vai atslēgu krātuvē un tiek tur glabātas, un cik labi šī krātuve pretojas uzbrukumiem
Tiek nosūtīts
Credential Issuer, Credential Request proofs daļā
Darbības laiks
To nosaka Maka pakalpojumu sniedzējs, un tas var būt ilgāks nekā WIA
Atsaukšana
key_storage_status: WSCD vai atslēgu krātuves atsaukšanas statuss
Nepieciešams
Tikai ierīcei piesaistītiem apliecinājumiem, ieskaitot katru PID

Abi ir JWT, ko Maka pakalpojumu sniedzējs paraksta ar ES256, ES384 vai ES512. Key Attestation tiek izmantots tikai vienai izsniegšanai, un WIA nekad netiek atkārtoti izmantots cita izsniedzēja priekšā, tāpēc izsniedzēji nevar sasaistīt viena un tā paša maka pieprasījumus.

Kā Maka vienība iegūst savus WIA un Key Attestation

TS3 šo soli atstāj katra Maka pakalpojumu sniedzēja ziņā, jo tas notiek viena maka produkta iekšienē. ARF tikai prasa, lai Maka pakalpojumu sniedzējs pirms WIA parakstīšanas pārbauda lietotnes integritāti un pirms Key Attestation parakstīšanas pārbauda, vai atestētās privātās atslēgas tiešām atrodas norādītajā WSCD vai atslēgu krātuvē. Tipiska plūsma, kurā kā pierādījumu izmanto platformas atestācijas, piemēram, Google Play Integrity vai Apple DeviceCheck, izskatās šādi.

1. Maka vienība

Lūdz WSCD vai atslēgu krātuvi ģenerēt atslēgu pārus

ģenerēt atslēgas

2. WSCD vai atslēgu krātuve

Atgriež publiskās atslēgas kopā ar platformas pierādījumiem par to, kur tās ģenerētas

publiskās atslēgas + pierādījumi

3. Maka pakalpojumu sniedzējs

Pārbauda lietotnes integritāti un atslēgu pierādījumus, tad paraksta WIA un Key Attestation

WIA + KA

4. Maka vienība

Uztur svaigu WIA un Key Attestation krājumu un katrai izsniegšanai izmanto jaunu

Ko satur WIA un Key Attestation

Nevienam no tiem nav iss prasības: izsniedzējs identificē Maka pakalpojumu sniedzēju pēc parakstīšanas sertifikāta x5c galvenē. Tālāk sniegtie piemēri ir dekodēti, galvene un saturs atdalīti ar punktu.

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": "..." }
  }
}
LauksKo tas pasaka izsniedzējam
typ / x5cKa šī ir klienta atestācija, un Maka pakalpojumu sniedzēja sertifikātu ķēde pārbaudei pret Trusted List
subMaka veids, vienāds katrai instalācijai, tāpēc to nevar izmantot lietotāja izsekošanai
wallet_name / wallet_versionWallet Solution, kā tas norādīts Trusted List, un tā versija
wallet_solution_certification_informationKas sertificēja Wallet Solution; precīzs saturs vēl nav definēts
expTehniskais derīguma termiņš, mazāk nekā 24 stundas pēc integritātes pārbaudes
client_statusStatus List ieraksts šai Wallet Instance un datums, līdz kuram Maka pakalpojumu sniedzējs to uztur aktuālu
cnfAtslēga, ar kuru paraksta valdījuma pierādījumu, kas nosūtīts kopā ar 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
  }
}
LauksKo tas pasaka izsniedzējam
typ / x5cKa šī ir atslēgas atestācija, un Maka pakalpojumu sniedzēja sertifikātu ķēde pārbaudei pret Trusted List
iat / expKad tas izsniegts un kad tehniski beidzas tā derīgums
attested_keysPubliskās atslēgas, kuru privātās atslēgas WSCD vai atslēgu krātuve ģenerējusi un glabā; vairākas atslēgas ļauj veikt pakešu izsniegšanu
key_storage / user_authenticationCik labi krātuve un lietotāja autentifikācija, kas atbloķē atslēgas, pretojas uzbrukumiem; WSCD abos gadījumos vienmēr ir iso_18045_high
certificationWSCD vai atslēgu krātuves sertifikācija, pēc kuras izsniedzējs var noteikt, vai tā ir WSCD
key_storage_statusStatus List ieraksts WSCD vai atslēgu krātuvei un datums, līdz kuram Maka pakalpojumu sniedzējs to uztur aktuālu
nonceIzsniedzēja c_nonce, kas ir tikai tad, ja Key Attestation tiek nosūtīts kā attestation pierādījums

Kur WUA nonāk OpenID4VCI izsniegšanas laikā

Abas atestācijas nonāk dažādās vietās. WIA autentificē maku kā OAuth klientu Authorization Server. Key Attestation nonāk pie Credential Issuer kopā ar paša apliecinājuma pieprasījumu.

Authorization Server saņem WIA

OAuth-Client-AttestationOAuth-Client-Attestation-PoP
  • WIA paraksts ved pa ķēdi līdz Trusted List sarakstam Maka pakalpojumu sniedzējiem
  • WIA derīguma termiņš nav beidzies, un Wallet Instance nav atsaukta
  • Valdījuma pierādījums ir parakstīts ar atslēgu no WIA cnf prasības

Credential Issuer saņem Key Attestation

proofs.jwt[].key_attestationproofs.attestation
  • Key Attestation paraksts ved pa ķēdi līdz Trusted List sarakstam Maka pakalpojumu sniedzējiem
  • Izsniedzēja svaigais c_nonce ir jwt pierādījumā vai pašā Key Attestation
  • WSCD vai atslēgu krātuve nav atsaukta, un apliecinājums ir piesaistīts vienai no attested_keys

Pushed Authorization Request ar 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 atbilst WIA sub vērtībai. Token Request satur tās pašas divas galvenes. Tā kā Credential Issuer nekad neredz WIA, Authorization Server jānodod tā client_status tālāk, piemēram, piekļuves tokenā.

Credential Request ar 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]>"]
  }
}

Ar attestation pierādījuma veidu pieprasījums tā vietā satur "proofs": { "attestation": ["<Key Attestation JWT>"] }. Tad valdījuma pierādījuma nav: Maka vienība nodod izsniedzēja c_nonce Maka pakalpojumu sniedzējam, kas to ievieto tikko parakstītā Key Attestation.

WUA dzīves cikls

WUA ar nolūku ir īslaicīgs un vienreizējs, taču atsaukšanas informācija aiz tā pastāv ilgāk par pašu tokenu. Pirmie trīs posmi ir ierasti, ceturtais notiek tikai tad, ja kaut kas noiet greizi.

1. Izsniegšana

Maka pakalpojumu sniedzējs paraksta WIA un Key Attestation pēc integritātes un atslēgu krātuves pārbaudēm

2. Vienreizēja lietošana

Katrs kalpo vienai izsniegšanai, tāpēc Maka vienība pastāvīgi iegūst jaunus

3. Ķēdes atsaukšana

PID Provider vismaz ik pēc 24 stundām atkārtoti pārbauda WIA un Key Attestation statusu un atsauc PID, ja kāds no tiem ir atsaukts

4. Atsaukšana

Maka pakalpojumu sniedzējs atsauc Wallet Instance, piemēram, pēc nozaudēšanas vai zādzības, vai WSCD vai atslēgu krātuvi ar drošības ievainojamību

Ārpus EUDI Wallet ekosistēmas daži Maka pakalpojumu sniedzēji izsniedz maka atestācijas ar ļoti īsu darbības laiku un bez jebkādas statusa atsauces, paļaujoties uz derīguma termiņa beigām, nevis atsaukšanu; OpenID4VCI status prasību padara neobligātu. TS3 to EUDI Wallet gadījumā neatļauj. WIA jau tā darbojas mazāk nekā 24 stundas, tomēr gan WIA, gan Key Attestation jāsatur statusa atsauce, ko Maka pakalpojumu sniedzējs uztur vismaz 31 dienu, jo PID Providers to izmanto, lai atsauktu PID ilgi pēc izsniegšanas.

WUA, WIA un KA: ko nozīmē katrs termins

Terminoloģija mainījās, specifikācijām attīstoties. TS3 līdz versijai 1.1 sauca WIA par Wallet App Attestation, un līdz versijai 1.5 ar WUA apzīmēja to, kas tagad ir Key Attestation. Tāpēc vecākos rakstos un ARF projektos termini lietoti citādi.

TerminsKo tas aptverKas to saņem
WUAVispārīgs termins abām tālāk minētajām atestācijāmPID Providers un Attestation Providers, tikai izsniegšanas laikā
WIAWallet Instance, proti, lietotniAuthorization Server, Pushed Authorization Request un Token Request ietvaros
KAWSCD vai atslēgu krātuvi un tajā glabātās atslēgasCredential Issuer, Credential Request proofs daļā

Saistītie termini

Biežāk uzdotie jautājumi

Vai WUA ir tas pats, kas Wallet Instance Attestation?

Nē. Kopš TS3 versijas 1.5 WUA ir vispārīgs termins divām atestācijām: Wallet Instance Attestation (WIA), kas aptver lietotni, un Key Attestation (KA), kas aptver WSCD vai atslēgu krātuvi, kurā glabājas atslēgas. Vecākos dokumentos WUA apzīmē to, ko tagad sauc par Key Attestation, tāpēc šos terminus bieži sajauc.

Vai verifikators kādreiz redz WUA?

Nē. ARF prasības WUA_07 un WUA_24 ļauj Maka vienībai uzrādīt WIA vai Key Attestation tikai PID Provider vai Attestation Provider izsniegšanas laikā, nekad uzticamības pusei. Verifikators tā vietā pārbauda apliecinājumu: tā parakstu, piesaisti ierīcei un atsaukšanas statusu. Ja maks, kas ir aiz PID, tiek atsaukts, PID Provider atsauc PID sava 24 stundu pārbaudes cikla laikā, un verifikators to redz paša PID statusā.

Cik ilgi WUA ir derīgs?

WIA derīguma termiņš beidzas mazāk nekā 24 stundas pēc tam, kad Maka pakalpojumu sniedzējs pārbaudījis lietotnes integritāti. Key Attestation var būt derīgs ilgāk, pēc Maka pakalpojumu sniedzēja ieskatiem. Turklāt katram ir statusa uzturēšanas datums, client_status.exp vai key_storage_status.exp, līdz kuram Maka pakalpojumu sniedzējs uztur atsaukšanas statusu aktuālu. Maka vienībai vienmēr jāspēj uzrādīt tāda atestācija, kuras datums ir vismaz 31 dienu uz priekšu, un PID derīguma termiņam jābeidzas pirms šī datuma.

Kas notiek, ja maka vienība tiek kompromitēta pirms WUA derīguma termiņa beigām?

Maka pakalpojumu sniedzējs atsauc Wallet Instance savā WIA Status List sarakstā vai, ja ievainojamība skar kādu WSCD vai atslēgu krātuves veidu, šīs krātuves ierakstu Status List sarakstā. PID Provider vismaz reizi 24 stundās pārbauda WIA un Key Attestation statusu katram izsniegtajam PID un atsauc PID, ja kāds no tiem ir atsaukts. Attestation Providers var rīkoties tāpat. Maku no ekosistēmas izslēdz nevis paša WUA derīguma termiņa beigas, bet tam izsniegto apliecinājumu atsaukšana.

Vai viens Key Attestation var aptvert vairāk nekā vienu atslēgu?

Jā. attested_keys var uzskaitīt vairākas publiskās atslēgas no vienas un tās pašas WSCD vai atslēgu krātuves, un tieši tā darbojas pakešu izsniegšana: izsniedzējs katru paketes apliecinājumu piesaista citai atslēgai, un viens Maka pakalpojumu sniedzēja paraksts aptver tās visas. Ja Key Attestation tiek nosūtīts jwt pierādījumā, Maka vienība šo pierādījumu paraksta tikai ar pirmo atslēgu sarakstā.

Avoti

  1. TS3: Wallet Unit Attestations used in issuance of PID and Attestations
  2. EUDI Wallet Architecture and Reference Framework
  3. OpenID for Verifiable Credential Issuance 1.0
  4. OpenID4VC High Assurance Interoperability Profile 1.0
  5. OAuth 2.0 Attestation-Based Client Authentication
  6. Token Status List

Šī lapa ir informatīva un nav uzskatāma par juridisku konsultāciju. Autoritatīvu norādījumu saņemšanai vērsieties tieši pie Eiropas Komisijas un OpenID Foundation.

Sazinieties ar mums par EUDI Wallet integrāciju