14. Considerazioni di Sicurezza e Privacy¶

Questa sezione fornisce un'analisi informale della sicurezza della specifica IT-Wallet analizzando la conformità con i requisiti di sicurezza e privacy identificati in [OpenID4VC-SecTrust].

Nota

Poiché [OpenID4VC-SecTrust] è ancora in fase di sviluppo, le considerazioni di sicurezza e privacy descritte potrebbero cambiare in futuro.

Nota

Il focus dell'analisi è la conformità delle scelte progettuali nella specifica IT-Wallet rispetto ai protocolli OpenID4VC. Sono attualmente fuori ambito (i) l'analisi della progettazione del flusso di prossimità basato su ISO 18013-5, e (ii) l'analisi dell'implementazione. Di conseguenza 7 requisiti specificamente relativi all'implementazione non sono considerati (ad esempio, SV-00: il Verifier deve implementare il protocollo in modo sicuro e corretto).

Come in [OpenID4VC-SecTrust], tutti i requisiti sono numerati per riferimento. Insieme al rispettivo componente che deve implementare il requisito:

CF: Formato della Credenziale.
P: Protocollo.
E: Ecosistema.
I: Issuer. Nell'analisi, il Fornitore di Attestati Elettronici.
V: Verifier. Nell'analisi, la Relying Party.
W: Wallet.

Questa specifica aggiunge la categoria del requisito come prefisso:

SR: Requisiti di Sicurezza.
PR: Requisiti di Privacy.
SPR: Requisiti di Sicurezza e Privacy.

L'identificatore finale utilizza il seguente spazio dei nomi: categoria_requisito-componente-id.

Per ogni requisito definito di seguito, questa sezione utilizza la descrizione definita in [OpenID4VC-SecTrust], specificando se il requisito è soddisfatto (completamente soddisfatto: , parzialmente soddisfatto: , e non soddisfatto: ). Di seguito, i requisiti sono raggruppati in base alla loro categoria.

14.1. Requisiti di Sicurezza¶

14.1.1. SR-CF-10 e SR-E-10¶

Per qualsiasi presentazione, il formato della Credenziale e il Trust Framework devono essere progettati in modo sicuro per determinare il Fornitore di Attestati Elettronici e verificare che la Credenziale originale sia stata emessa da questo Fornitore di Attestati Elettronici (ad esempio, utilizzando una firma crittografica).

La specifica IT-Wallet supporta sia il formato di Credenziale SD-JWT VC che mdoc-CBOR. L'autenticità e l'integrità di una Credenziale vengono verificate controllando la firma del Fornitore di Attestati Elettronici.

Per SD-JWT, la verifica usa l'algoritmo specificato nel parametro dell'header alg di SD-JWT. La verifica usa anche un riferimento verificabile alla chiave pubblica per la verifica della firma. Con OpenID Federation, quel riferimento è l'header kid dell'SD-JWT. Il materiale crittografico si ottiene dalla Trust Chain relativa al Fornitore di Attestati Elettronici, indicata nel claim iss.
Per mdoc-CBOR, la firma del Fornitore di Attestati Elettronici è contenuta nel Mobile Security Object (MSO). La firma si convalida con la chiave pubblica del Fornitore di Attestati Elettronici. La chiave è presa da una catena di certificati attendibile nel parametro dell'header x5chain.

14.1.2. SR-CF-20¶

Per qualsiasi presentazione, il formato della Credenziale deve garantire che i dati legati alla Credenziale originale non possano essere alterati (ad esempio, utilizzando una firma crittografica).

La firma crittografica inclusa nel formato della Credenziale garantisce che qualsiasi manomissione della Credenziale comporterà una verifica fallita.

14.1.3. SR-CF-21¶

Per l'associazione crittografica con l'Utente, il formato di presentazione richiede al Titolare di dimostrare il possesso della chiave privata associata alla Credenziale. Questo viene tipicamente ottenuto facendo firmare al Titolare una sfida, che consiste in un valore nonce e l'identificatore univoco della Relying Party.

Sia SD-JWT che mdoc-CBOR supportano l'associazione crittografica con l'Utente definendo come un Titolare può presentare una Credenziale a una Relying Party, fornendo una prova crittografica del legittimo possesso della Credenziale.

Attualmente, per il flusso remoto, IT-Wallet supporta solo presentazioni SD-JWT. In questo scenario, il parametro KB-JWT (Key-Bound JWT) viene utilizzato per dimostrare che il Titolare possiede la chiave privata associata alla Credenziale. Il Titolare firma il KB-JWT utilizzando un nonce e un identificatore della Relying Party, utilizzando il parametro aud, come sfida.

14.1.4. SR-E-20¶

Il Trust Framework deve garantire che l'identificazione di un Fornitore di Attestati Elettronici sia unica e non ambigua. Se ci sono più istanze dello stesso Fornitore di Attestati Elettronici che utilizzano lo stesso materiale chiave, la Relying Party deve fidarsi di tutte le istanze allo stesso modo.

Il Trust Framework IT Wallet garantisce che ogni entità (ad esempio, un Fornitore di Attestati Elettronici) sia identificata in modo univoco attraverso chiavi crittografiche e metadati. Chiavi e metadati sono distribuiti tramite un attestato verificabile, come la Entity Configuration OpenID Federation verificata all'interno di una Trust Chain.

14.1.5. SR-E-30¶

Il modo in cui la Relying Party determina l'affidabilità del Fornitore di Attestati Elettronici definito nel Trust Framework deve essere protetto dall'influenza di una parte malintenzionata che può, ad esempio, introdurre entità non affidabili in una directory.

I Fornitori di Attestati Elettronici sono registrati da un Trust Anchor o dal suo Intermediario. Per verificare l'affidabilità di un Fornitore di Attestati Elettronici, una Relying Party deve verificare che la Trust Chain relativa al Fornitore di Attestati Elettronici sia valida e ancora attiva. Questo processo di convalida garantisce che solo entità affidabili siano autorizzate a partecipare al sistema, impedendo l'introduzione di attori non affidabili.

14.1.6. SR-E-40¶

Il Trust Framework deve garantire che ci sia un modo per le Relying Party di mantenere aggiornate le loro informazioni sui Fornitori di Attestati Elettronici affidabili e che ci sia un modo per revocare la fiducia in un Fornitore di Attestati Elettronici.

Se l'Entity Statement di un Fornitore di Attestati Elettronici viene revocato o non è disponibile, significa che il Fornitore di Attestati Elettronici non è più considerato valido all'interno della federazione. Ciò garantisce che le Relying Party abbiano accesso in tempo reale allo stato delle entità affidabili e possano revocare la fiducia se necessario. Tuttavia, le Relying Party devono controllare attivamente lo stato del Fornitore di Attestati Elettronici interrogando gli endpoint della federazione (cioè, l'endpoint fetch per ottenere la Subordinate Statement).

14.1.7. SR-I-10¶

Il Fornitore di Attestati Elettronici deve autenticare e identificare l'Utente correttamente secondo le aspettative della Relying Party (che possono essere definite in una specifica, Trust Framework o per convenzione).

Il processo di emissione utilizza flussi basati su OAuth 2.0, in particolare il flusso Authorization Code, per autenticare in modo sicuro l'Utente. Inoltre, l'autenticazione dell'Utente viene eseguita utilizzando lo schema CieID con alto LoA, l'Autenticazione eID Substantial con Verifica MRTD oppure il PID/IT-Wallet ID.

14.1.8. SR-I-20¶

Il Fornitore di Attestati Elettronici deve utilizzare solo attributi corretti e aggiornati sull'Utente nella Credenziale dove sono previsti dati verificati.

Quando sono previsti dati verificati, il Fornitore di Attestati Elettronici ottiene gli attributi corretti e aggiornati dalle relative Fonti Autentiche, garantendone l'accuratezza al momento dell'emissione.

14.1.9. SR-I-30¶

Il Fornitore di Attestati Elettronici deve revocare una Credenziale una volta che il Fornitore di Attestati Elettronici viene a conoscenza di un potenziale abuso della Credenziale.

Il Fornitore di Attestati Elettronici è l'entità responsabile della revoca di una Credenziale. La specifica descrive diversi casi d'uso che possono attivare un processo di revoca. La specifica dettaglia il flusso di revoca in cui il Fornitore di Attestati Elettronici revoca le Credenziali su richiesta dell'Utente (attraverso l'Istanza del Wallet) dopo aver verificato il possesso delle Credenziali.

14.1.10. SR-I-40¶

Il Fornitore di Attestati Elettronici deve includere nella Credenziale solo dati di associazione del Titolare che sono legati all'Utente effettivo (e non, ad esempio, includere una chiave crittografica sotto il controllo di una terza parte).

Il processo di emissione lega in modo sicuro la Credenziale all'Utente come segue (vedi Fig. 11.5).

Autorizzazione (Passi 8-10): L'Istanza del Wallet invia una richiesta di autorizzazione. Il Fornitore di Attestati Elettronici autentica l'Utente utilizzando uno schema CieID o un PID/IT-Wallet ID valido. Il Fornitore di Attestati Elettronici fornisce il Token di Accesso all'Utente.
Prova di Possesso della Chiave (Passi 12-13, 16-17): L'Istanza del Wallet crea un JWT di DPoP Proof. Il JWT di DPoP Proof vincola l'Access Token all'Istanza del Wallet. L'Istanza del Wallet usa quella stessa chiave DPoP quando presenta l'Access Token al Credential Endpoint.
Emissione della Credenziale (Passi 18-21): Il Credential Issuer verifica la prova di possesso del materiale crittografico a cui la Credenziale sarà associata. Il Credential Issuer verifica la Key Attestation di quel materiale. La Key Attestation mostra che l'Istanza del Wallet controlla quel materiale.

14.1.11. SR-I-50¶

(condizionale rispetto a I-10) Il Fornitore di Attestati Elettronici deve garantire che la Credenziale sia stata memorizzata in un Wallet sicuro.

Un Wallet Attestation affidabile garantisce che l'Istanza del Wallet sia sicura e soddisfi gli standard di sicurezza richiesti prima che qualsiasi Credenziale venga emessa o memorizzata. Nei Passi 5-6 di Fig. 11.5, l'Istanza del Wallet fornisce una Wallet Attestation, che include una prova di possesso firmata con la chiave privata del Wallet. Questo attestato conferma che l'Istanza del Wallet è genuina ed è stata verificata dal Fornitore di Wallet.

Il Fornitore di Attestati Elettronici verifica questo attestato prima di consentire al Wallet di partecipare al processo di emissione, garantendo che il Wallet aderisca a specifici standard di sicurezza. Successivamente, tutte le chiavi crittografiche generate e utilizzate nel processo provengono da questa Istanza del Wallet attestata.

Nota

C'è attualmente un problema aperto su questo aspetto (https://github.com/openid/OpenID4VCI/issues/355) nella specifica OpenID4VCI.

14.1.12. SR-P-20¶

Il protocollo deve garantire che nessuna terza parte possa interferire con il processo di emissione in modo tale che il Fornitore di Attestati Elettronici emetta Credenziali per la terza parte all'Utente.

Questo requisito è affrontato mediante l'identificazione sicura del Fornitore di Attestati Elettronici. Il parametro ^iss^ nella risposta di autorizzazione assicura al Wallet che la risposta provenga dal Fornitore di Attestati Elettronici previsto. La verifica crittografica dei token ricevuti garantisce che i token siano stati emessi dal legittimo Fornitore di Attestati Elettronici. Inoltre, l'uso di PKCE evita l'iniezione del codice da un'altra sessione nella sessione dell'Utente.

14.1.13. SR-P-30¶

Il protocollo deve garantire che l'interazione tra il Wallet e la Relying Party sia protetta in modo tale che nessuna terza parte possa interferire con l'interazione modificando le informazioni trasmesse.

Il processo di presentazione avviene attraverso diversi flussi, inclusi remoto e di prossimità. Nel flusso remoto, Request Objects firmati, l'uso di nonce, la validazione della Trust Chain, la Wallet Attestation e l'associazione del Titolare proteggono lo scambio. Nessuna terza parte può interferire o modificare le informazioni trasmesse tra il Wallet e la Relying Party. Questi meccanismi sono allineati con il Requisito di Sicurezza P-30. I meccanismi proteggono l'interazione da manomissioni o attacchi di iniezione.

14.1.14. SR-P-40¶

Il protocollo deve garantire che l'interazione tra un attaccante e una Relying Party non possa essere inoltrata e completata con successo da un Utente.

Nel caso del flusso sullo stesso dispositivo, questo può essere prevenuto utilizzando e controllando correttamente il valore nonce, che viene creato e inviato dalla Relying Party nella richiesta di autorizzazione. La Relying Party dovrebbe mantenere una mappatura tra le sessioni dell'Utente e il nonce che è previsto nel flusso. La Relying Party dovrebbe accettare una presentazione solo se il nonce nella presentazione corrisponde al nonce che è previsto per la sessione dell'Utente. Con questa contromisura, la Relying Party deve rilevare se viene inviata una presentazione che non era legata alla sessione dell'Utente o se non esiste affatto una sessione dell'Utente, prevenendo l'attacco.

Per il flusso cross-device il requisito è parzialmente soddisfatto. Il flusso è vulnerabile agli attacchi di Cross-Device Consent Phishing. Un attaccante potrebbe iniziare il flusso di presentazione, ottenere il Request Object firmato e il codice QR, e inoltrarli alla vittima.

Alcune misure di sicurezza sono già in atto, come l'uso di nonce e state. Il nonce garantisce la freschezza della richiesta, e lo state lega il flusso a una transazione unica, riducendo così l'opportunità per un attacco di successo.

Nota

Altre misure di sicurezza sono attualmente in fase di valutazione nell'issue numero [117](https://github.com/italia/eid-wallet-it-docs/issues/117), dove viene discussa una lista di mitigazioni da [OAuthCrossDeviceSec]. Due esempi sono:

Codici QR a breve durata/limitati nel tempo: Ridurre la durata del codice QR (ad esempio, 2-3 minuti) è necessario per limitare la finestra temporale disponibile per gli attacchi.
Codici QR monouso: I codici QR monouso limitano la possibilità di attacchi quando lo stesso codice QR viene inviato a più vittime.

14.1.15. SR-P-41¶

Il protocollo deve garantire che un attaccante non possa inoltrare con successo un'interazione tra un Wallet e una Relying Party a una Relying Party sotto il controllo dell'attaccante.

Un prerequisito per un attacco di questo tipo è l'accesso dell'attaccante ad alcuni messaggi tra il Wallet e la Relying Party. Ad esempio, l'attaccante potrebbe avere accesso alla presentazione contenuta nel Token VP. La corretta implementazione di TLS garantisce la riservatezza ed evita la fuga della risposta. Oltre a TLS, l'implementazione esistente dei controlli nonce e audience nel protocollo di presentazione dovrebbe aiutare a soddisfare il requisito di sicurezza P-41. Per quanto riguarda il claim nonce, la Relying Party DEVE verificare che il valore nonce nel Token VP corrisponda al valore nonce che è creato dalla Relying Party durante la richiesta di autorizzazione. Per quanto riguarda il valore aud, la Relying Party deve verificare che l'audience della presentazione corrisponda all'identificatore della Relying Party.

14.1.16. SR-P-50¶

Il protocollo deve garantire che terze parti non possano interferire con il processo di associazione.

Nella fase di emissione, l'associazione del Titolare avviene alla richiesta di Credenziale all'endpoint protetto della Credenziale. Ciò significa che l'attaccante deve ottenere il token di accesso prima e quindi inviare la richiesta all'endpoint della Credenziale e legare le Credenziali alle chiavi sotto il suo controllo. La specifica IT-Wallet richiede l'uso di un token di accesso vincolato al mittente, il che significa che il token di accesso si lega al dispositivo utilizzando materiali crittografici.

La seconda superficie per l'attacco è correlata alla gestione delle chiavi. Con chiavi basate su software, le chiavi possono essere clonate e spostate su un dispositivo sotto il controllo dell'attaccante. Se le Credenziali sono rubate, l'attaccante può creare una prova di possesso delle chiavi. IT-Wallet è meno vulnerabile a questi attacchi perché supporta un Keystore basato su hardware. Manca ancora un profilo di certificazione che certifichi il Keystore (TEE) contro attaccanti altamente capaci. Le soluzioni TEE attuali sul mercato raggiungono al massimo AVA_VAN.3, come mostrato ad esempio in questo NSCIB-CC-0244671 o nel GP TEE Protection Profile. Il requisito è quindi soddisfatto solo in parte per le Credenziali Digitali standard. Per il PID, questa limitazione è superata richiedendo una WSCA operante in un Remote WSCD (HSM remoto lato server). Il Remote WSCD fornisce certificazione a un livello più elevato.

14.1.17. SR-V-10¶

(condizionale rispetto a I-50+V-20) La Relying Party deve garantire che la Credenziale sia memorizzata in un Wallet sicuro.

La Relying Party controlla la Wallet Attestation durante gli scambi inviati con la risposta di autorizzazione. Il controllo conferma che la Wallet Attestation soddisfa i criteri di sicurezza richiesti dalla Relying Party. La Wallet Attestation resta sotto la sola responsabilità del suo emittente, il Fornitore di Wallet affidabile.

Nota

Attualmente, non sono specificate misure di sicurezza e privacy esplicite relative a questo requisito in [OpenID4VC-SecTrust] e non è chiaramente definito cosa significhi ^memorizzato in un Wallet sicuro^. Senza questo dettaglio, questo requisito è considerato solo parzialmente soddisfatto. Infatti, la Wallet Attestation garantisce che l'Istanza del Wallet stia operando su un dispositivo sicuro e affidabile e aderisca alle rigorose politiche di sicurezza stabilite dal Fornitore di Wallet. Tuttavia, l'attestato non garantisce direttamente che ogni Credenziale all'interno del Wallet sia memorizzata in modo sicuro. L'attestato verifica la sicurezza complessiva dell'ambiente del Wallet, all'interno del quale risiedono le Credenziali. Pertanto, mentre l'attestato supporta la fiducia della Relying Party che la Credenziale provenga da una fonte sicura, è in definitiva una garanzia ampia della sicurezza del Wallet, piuttosto che una convalida specifica della memorizzazione individuale della Credenziale.

14.1.18. SR-V-20¶

(condizionale rispetto a I-10) La Relying Party deve garantire che la Credenziale sia stata emessa da un Fornitore di Attestati Elettronici che emette Credenziali solo a Wallet affidabili.

Controllando l'affidabilità del Fornitore di Attestati Elettronici, la Relying Party garantisce che la Credenziale sia stata emessa da un Fornitore di Attestati Elettronici affidabile impegnato a emettere Credenziali solo a Wallet sicuri (come per SR-I-50).

Nota

Attualmente, non sono specificate misure di sicurezza e privacy esplicite relative a questo requisito in [OpenID4VC-SecTrust], configurando questo elemento come qualcosa che richiede ulteriori sviluppi e chiarimenti.

14.1.19. SR-W-20¶

Il Wallet deve fornire informazioni affidabili e complete sui Fornitori di Attestati Elettronici all'Utente.

L'Istanza del Wallet scopre i Fornitori di Attestati Elettronici affidabili utilizzando risorse di terze parti affidabili, come l'API di Federazione. Un esempio è l'Endpoint di Elenco Subordinato del Trust Anchor e dei suoi Intermediari. L'Istanza del Wallet ispeziona i metadati del Fornitore di Attestati Elettronici e i Trust Mark per filtrare il Fornitore di PID.

Le informazioni del Fornitore di Attestati Elettronici vengono visualizzate all'Utente durante il processo di emissione e possono essere successivamente lette dall'Utente in quanto sono all'interno della Credenziale emessa. Oltre alle informazioni del Fornitore di Attestati Elettronici, il Type Metadata dell'Attestato Elettronico contiene anche informazioni sulla Fonte Autentica.

14.1.20. SR-W-30¶

Il Wallet deve fornire informazioni affidabili e complete sulle Relying Party all'Utente.

Il Wallet convalida la Trust Chain relativa alla Relying Party e le sue informazioni vengono visualizzate all'Utente prima della presentazione.

14.2. Requisiti di Privacy¶

14.2.1. PR-CF-30¶

Il Formato della Credenziale deve garantire che ci sia un meccanismo robusto per garantire che i dati che non devono essere rilasciati a una Relying Party non possano essere estratti dalla Relying Party (Divulgazione Selettiva).

Sia SD-JWT che mdoc-CBOR forniscono la capacità di Divulgazione Selettiva, permettendo ai Titolari di rivelare solo campi specifici alla Relying Party.

14.2.2. PR-CF-40¶

Il Formato della Credenziale deve supportare la protezione dalla correlazione.

Mentre la Divulgazione Selettiva è uno strumento forte per prevenire la correlazione, la completa non collegabilità non è garantita in tutti i casi. Possono sorgere problemi come la collusione della Relying Party o il tracciamento del Fornitore di Attestati Elettronici.

Suggerimento

L'emissione in batch, utilizzando diverse chiavi di associazione e salt per ogni Credenziale, può mitigare i rischi di non collegabilità Relying Party/Relying Party e di presentazione.

14.2.3. PR-E-60¶

Il Trust Framework deve garantire che il Fornitore di Attestati Elettronici non possa sapere dove l'Utente utilizza la Credenziale.

La Relying Party che esegue la Trust Evaluation sul Fornitore di Attestati Elettronici di una Credenziale non deve rilasciare alcuna informazione al Fornitore di Attestati Elettronici sull'Istanza del Wallet con cui sta interagendo. Utilizzando [OID-FED] il Fornitore di Attestati Elettronici non sa chi è l'Utente che presenta la Credenziale. Inoltre, la privacy è protetta anche durante il controllo dello stato della Credenziale. Utilizzando Status List [TOKEN-STATUS-LIST], la specifica IT-Wallet garantisce che mentre la Relying Party controlla la validità della Credenziale, il Fornitore di Attestati Elettronici non apprende dove o quando la Credenziale viene utilizzata.

14.2.4. PR-E-70¶

Il Trust Framework deve supportare la protezione dalla correlazione.

I seguenti meccanismi possono essere implementati per ridurre la correlazione:

Relying Party-Relying Party: meccanismi di valutazione per garantire che una Relying Party richieda solo le informazioni che è autorizzata a ottenere dal Wallet. Questo approccio minimizza lo scambio di dati e aiuta a prevenire la profilazione dell'Utente attraverso potenziali collusioni tra Relying Party.
Fornitore di Attestati Elettronici-Relying Party: Il Fornitore di Attestati Elettronici non richiede l'autenticazione della Relying Party durante la Trust Evaluation. In linea di principio, il Fornitore di Attestati Elettronici non sa quali Relying Party l'Utente sta accedendo e eviterà la profilazione dell'attività dell'Utente basata sull'accesso della Relying Party.

Suggerimento

I Trust Mark di OpenID Federation consentono la definizione di politiche personalizzate adatte alla soddisfazione di questo requisito.

14.2.5. PR-W-40¶

Il Wallet deve chiedere all'Utente un consenso significativo prima che una Credenziale venga utilizzata. Il Wallet deve fornire all'Utente l'opportunità di rivedere qualsiasi dato che viene rilasciato a una Relying Party.

Dopo aver stabilito la fiducia con la Relying Party, il Wallet chiede il consenso dell'Utente e fornisce all'Utente l'opportunità di rivedere e selezionare i dati da presentare alla Relying Party.

14.2.6. PR-W-60¶

Il Wallet deve garantire che il Fornitore di Attestati Elettronici non possa sapere dove l'Utente utilizza la Credenziale.

Come per SR-P-80.

14.2.7. PR-W-70¶

Il Wallet deve garantire che la Relying Party non possa sapere che lo stesso Utente sta utilizzando altre Relying Party.

Per mitigare la collegabilità Relying Party/Relying Party per le Credenziali SD-JWT, una soluzione proposta è l'emissione in batch, che prevede l'utilizzo di diverse chiavi crittografiche utilizzate nell'associazione delle chiavi e salt per ogni Credenziale emessa. Tuttavia, l'efficacia di questi metodi non è stata ancora valutata a fondo, anche in considerazione degli impatti che questi potrebbero avere sull'esperienza dell'utente, e non è ancora disponibile per IT-Wallet.

14.3. Requisiti di Sicurezza e Privacy¶

14.3.1. SPR-E-50¶

Il Trust Framework deve garantire che i cicli di vita delle chiavi, dei certificati e delle Credenziali siano progettati in modo tale da minimizzare l'impatto di una compromissione.

Il ciclo di vita della Credenziale include un meccanismo di revoca della Credenziale basato su Status List [TOKEN-STATUS-LIST] che garantisce che le Credenziali siano correttamente revocate quando compromesse o obsolete.

La revoca di un'Entità di Federazione (Fornitore di Attestati Elettronici, Relying Party o Fornitore di Wallet) è possibile non emettendo la corrispondente Subordinate Statement su quell'Entità. Una breve scadenza della Trust Chain impedisce l'uso improprio durante la compromissione.

Suggerimento

Inoltre, [OID-FED] supporta un endpoint delle chiavi storiche per recuperare l'elenco delle chiavi scadute e revocate, con la motivazione della revoca.

14.3.2. SPR-P-10¶

Il protocollo deve garantire che nessuna terza parte possa leggere la Credenziale emessa dal Fornitore di Attestati Elettronici.

Per mitigare questa minaccia, la specifica IT-Wallet richiede i seguenti meccanismi di sicurezza nel processo di emissione:

TLS: Utilizzato in tutte le comunicazioni tra il Wallet e il Fornitore di Attestati Elettronici. I dati in transito sono crittografati e protetti dall'intercettazione da parte di attaccanti.
Wallet Attestation: Garantisce che il Wallet operi su un dispositivo sicuro e affidabile e rispetti gli standard di sicurezza richiesti dal Fornitore di Attestati Elettronici. L'attestato dà ulteriore garanzia che il Fornitore di Attestati Elettronici stia interagendo con un'Istanza del Wallet legittima.
DPoP: Garantisce che il Titolare del token di accesso possieda la chiave privata associata ad esso, impedendo agli attaccanti di riutilizzare token intercettati.
Associazione del Titolare: Lega la Credenziale a un Titolare specifico, garantendo che solo il legittimo Titolare possa utilizzare una Credenziale per autenticarsi con il Fornitore di Attestati Elettronici.
validazione redirect_uri: Questa validazione garantisce che la risposta di autorizzazione sia inviata all'endpoint corretto e autorizzato, impedendo così l'intercettazione non autorizzata da parte di attori malintenzionati. Garantire l'integrità del redirect_uri è fondamentale per evitare qualsiasi manipolazione o reindirizzamento dell'URI.
PKCE: Evita l'iniezione di un code di autorizzazione legittimo in un'altra sessione.

14.3.3. SPR-P-60¶

Il protocollo deve garantire che durante un'interazione con una Relying Party, un attaccante non possa leggere PII.

L'IT Wallet è conforme ai requisiti di P-60 garantendo che tutte le connessioni di rete siano protette da TLS.

Inoltre, poiché la Risposta di Autorizzazione contiene PII è importante che non venga inviata a un endpoint controllato dall'attaccante. Nella specifica IT Wallet il response_uri è l'endpoint dove il Wallet invia la Risposta di Autorizzazione. Il response_uri è incluso nel Request Object firmato. Il Wallet verifica quell'oggetto con la chiave pubblica della Relying Party e la Trust Chain. Questo garantisce che la Risposta di Autorizzazione venga inviata all'endpoint corretto. Inoltre, la Risposta di Autorizzazione è crittografata con la chiave pubblica della Relying Party, garantendo che solo il destinatario previsto possa decrittografare e leggere le informazioni sensibili, proteggendo ulteriormente la trasmissione.

Un altro endpoint da validare è il redirect_uri, che viene utilizzato per reindirizzare l'Utente alla Relying Party dopo che la presentazione della Credenziale è completata. Nella specifica IT-Wallet, il redirect_uri è registrato e validato in anticipo durante l'onboarding della Relying Party utilizzando OpenID Federation. Durante la fase di presentazione, il Wallet valida questo valore verificando la fiducia nella Relying Party secondo Meccanismo di Valutazione della Fiducia.

L'endpoint di risposta della Relying Party verifica che il redirect_uri provenga da un Wallet legittimo e non da un attaccante. Al ricevimento di una risposta di autorizzazione valida, l'endpoint crea un valore crittografico fresco collegato a quella risposta. L'endpoint allega il valore al redirect_uri inviato al Wallet. Quando la Relying Party riceve il reindirizzamento, può estrarre il codice di risposta e verificare con il suo endpoint di risposta se il codice di risposta era associato a questa Risposta di Autorizzazione. (Vedi URI di Reindirizzamento).

14.3.4. SPR-P-70¶

Il protocollo deve garantire che durante un'interazione con un Fornitore di Attestati Elettronici, un attaccante non possa leggere PII.

Nel processo di emissione, poiché la Credenziale all'interno di una Risposta di Credenziale contiene PII, è necessario che la Credenziale non venga inviata o intercettata da un attaccante. Per mitigare queste minacce, la specifica IT-Wallet richiede i seguenti meccanismi di sicurezza:

TLS: Utilizzato in tutte le comunicazioni tra il Wallet e il Fornitore di Attestati Elettronici. I dati in transito sono crittografati e protetti dall'intercettazione da parte di attaccanti.
Attestato dell'Istanza del Wallet: Garantisce che il Wallet operi su un dispositivo sicuro e affidabile e rispetti gli standard di sicurezza richiesti dal Fornitore di Attestati Elettronici. L'attestato dà ulteriore garanzia che il Fornitore di Attestati Elettronici stia interagendo con un'Istanza del Wallet legittima.
DPoP: Garantisce che il Titolare del token di accesso possieda la chiave privata associata ad esso, impedendo agli attaccanti di riutilizzare token intercettati.
Associazione del Titolare: Lega la Credenziale a un Titolare specifico, garantendo che solo il legittimo Titolare possa utilizzare una Credenziale per autenticarsi con il Fornitore di Attestati Elettronici.
validazione redirect_uri: Questa validazione garantisce che la risposta di autorizzazione sia inviata all'endpoint corretto e autorizzato, impedendo così l'intercettazione non autorizzata da parte di attori malintenzionati. Garantire l'integrità del redirect_uri è fondamentale per evitare qualsiasi manipolazione o reindirizzamento dell'URI.
PKCE: Evita l'iniezione di un code di autorizzazione legittimo in un'altra sessione.

Suggerimento

Un ulteriore miglioramento della sicurezza che potrebbe essere applicato per aggiungere un ulteriore livello di protezione per le informazioni sensibili dell'Utente è la crittografia delle risposte di Credenziale. Lo standard OpenID4VCI fornisce l'opzione per il Wallet di richiedere Credenziali crittografate contenenti PII includendo un oggetto credential_response_encryption nella sua richiesta.

Nota

Attualmente, non sono specificate misure di sicurezza e privacy esplicite relative a questo requisito in [OpenID4VC-SecTrust], rimane un lavoro in corso.

14.3.5. SPR-P-80¶

Il protocollo deve garantire che il Fornitore di Attestati Elettronici non possa sapere dove l'Utente utilizza la Credenziale.

Il protocollo di scambio non richiede alcuna interazione tra Relying Party e Fornitori di Attestati Elettronici. Inoltre, Status List che preserva la privacy, garantisce che mentre la Relying Party controlla la validità della Credenziale, il Fornitore di Attestati Elettronici non apprende dove o quando la Credenziale viene utilizzata.

14.3.6. SPR-W-50¶

Il Wallet deve garantire che le Credenziali e le chiavi private siano protette da accessi non autorizzati.

Per prevenire l'accesso non autorizzato, il Wallet viene sbloccato sul dispositivo dell'Utente con un numero di identificazione personale (PIN) o con l'autenticazione biometrica. L'autenticazione biometrica comprende l'impronta digitale o il riconoscimento facciale, in base alle preferenze dell'Utente e alle capacità del dispositivo. Le chiavi crittografiche sono memorizzate nel Keystore, oppure nel WSCA/Remote WSCD per il PID. Solo l'Utente può accedere a quelle chiavi. Tale conservazione impedisce l'uso non autorizzato o la manomissione.