Architettura della smart card

Questo argomento per il professionista IT descrive l'architettura di sistema che supporta le smart card nel sistema operativo Windows, tra cui l'architettura del provider di credenziali e l'architettura del sottosistema smart card.

L'autenticazione è un processo per verificare l'identità di un oggetto o di una persona. Quando si autentica un oggetto, ad esempio una smart card, l'obiettivo è verificare che l'oggetto sia originale. Quando si autentica una persona, l'obiettivo è verificare di non avere a che fare con un impostore.

In un contesto di rete, l'autenticazione è l'atto di dimostrare l'identità a un'applicazione o a una risorsa di rete. In genere, l'identità è dimostrata da un'operazione di crittografia che usa una chiave che solo l'utente conosce (ad esempio con la crittografia a chiave pubblica) o una chiave condivisa. Il lato server dello scambio di autenticazione confronta i dati firmati con una chiave di crittografia nota per convalidare il tentativo di autenticazione. L'archiviazione delle chiavi di crittografia in una posizione centrale sicura rende il processo di autenticazione scalabile e gestibile.

Per le smart card, Windows supporta un'architettura del provider che soddisfa i requisiti di autenticazione sicura ed è estensibile in modo da includere provider di credenziali personalizzati. Questo argomento include informazioni su:

• Architettura del provider di credenziali
• Architettura del sottosistema smart card

Architettura del provider di credenziali

Nella tabella seguente sono elencati i componenti inclusi nell'architettura di accesso interattivo:

L'accesso interattivo in Windows inizia quando l'utente preme CTRL+ALT+CANC. La combinazione di tasti CTRL+ALT+CANC è denominata sequenza di attenzione sicura (SAS). Per impedire ad altri programmi e processi di usarlo, Winlogon registra questa sequenza durante il processo di avvio.

Dopo aver ricevuto la firma di accesso condiviso, l'interfaccia utente genera quindi il riquadro di accesso dalle informazioni ricevute dai provider di credenziali registrati. L'immagine seguente mostra l'architettura per i provider di credenziali nel sistema operativo Windows.

In genere, un utente che accede a un computer usando un account locale o un account di dominio deve immettere un nome utente e una password. Queste credenziali vengono usate per verificare l'identità dell'utente. Per l'accesso con smart card, le credenziali di un utente sono contenute nel chip di sicurezza della smart card. Un lettore di smart card consente al computer di interagire con il chip di sicurezza nella smart card. Quando gli utenti accedono con una smart card, immettono un numero di identificazione personale (PIN) anziché un nome utente e una password.

I provider di credenziali sono oggetti COM in-process eseguiti nel sistema locale e vengono usati per raccogliere le credenziali. L'interfaccia utente di accesso fornisce il rendering interattivo dell'interfaccia utente, Winlogon offre un'infrastruttura di accesso interattiva e i provider di credenziali interagiscono con entrambi questi componenti per raccogliere ed elaborare le credenziali.

Winlogon indica all'interfaccia utente di accesso di visualizzare i riquadri del provider di credenziali dopo aver ricevuto un evento sas. L'interfaccia utente di accesso esegue una query su ogni provider di credenziali per il numero di credenziali da enumerare. I provider di credenziali hanno la possibilità di specificare uno di questi riquadri come predefinito. Dopo che tutti i provider hanno enumerato i riquadri, l'interfaccia utente di accesso li visualizza all'utente. L'utente interagisce con un riquadro per fornire le credenziali appropriate. L'interfaccia utente di accesso invia queste credenziali per l'autenticazione.

In combinazione con l'hardware di supporto, i provider di credenziali possono estendere il sistema operativo Windows per consentire agli utenti di accedere usando la biometria (ad esempio, impronta digitale, retina o riconoscimento vocale), password, PIN, certificato smart card o qualsiasi pacchetto di autenticazione personalizzato. Le aziende e i professionisti IT possono sviluppare e distribuire meccanismi di autenticazione personalizzati per tutti gli utenti di dominio e possono richiedere esplicitamente agli utenti di usare questo meccanismo di accesso personalizzato.

I provider di credenziali possono essere progettati per supportare l'accesso Single Sign-In (SSO). In questo processo, autenticano gli utenti a un punto di accesso di rete sicuro (usando RADIUS e altre tecnologie) per l'accesso al computer. I provider di credenziali sono anche progettati per supportare la raccolta di credenziali specifiche dell'applicazione e possono essere usati per l'autenticazione alle risorse di rete, l'aggiunta di computer a un dominio o il consenso dell'amministratore per il controllo dell'account utente.

In un computer possono coesistere più provider di credenziali.

I provider di credenziali devono essere registrati in un computer che esegue Windows e sono responsabili di:

• Descrizione delle informazioni sulle credenziali necessarie per l'autenticazione
• Gestione della comunicazione e della logica con le autorità di autenticazione esterne
• Creazione di pacchetti delle credenziali per l'accesso interattivo e di rete

Architettura del sottosistema smart card

I fornitori forniscono smart card e lettori di smart card e in molti casi i fornitori sono diversi per la smart card e il lettore di smart card. I driver per i lettori di smart card vengono scritti nello standard Personal Computer/Smart Card (PC/SC). Ogni smart card deve avere un provider di servizi di crittografia (CSP) che usa le interfacce CryptoAPI per abilitare le operazioni di crittografia e le API WinSCard per abilitare le comunicazioni con l'hardware della smart card.

Architettura del minidriver CSP e smart card di base

L'immagine seguente mostra la relazione tra CryptoAPI, CSP, provider di servizi di crittografia di base smart card (CSP di base) e minidriver per smart card.

Memorizzazione nella cache con CSP di base e KSP smart card

L'architettura delle smart card usa meccanismi di memorizzazione nella cache per semplificare le operazioni e migliorare l'accesso di un utente a un PIN.

• Memorizzazione nella cache dei dati: la cache dei dati consente a un singolo processo di ridurre al minimo le operazioni di I/O delle smart card
• Memorizzazione nella cache del PIN: la cache PIN consente all'utente di dover immettere di nuovo un PIN ogni volta che la smart card non è autenticata

Memorizzazione nella cache dei dati

Ogni provider di servizi di configurazione implementa separatamente la cache dei dati della smart card corrente. Il provider di servizi di configurazione di base implementa un solido meccanismo di memorizzazione nella cache che consente a un singolo processo di ridurre al minimo le operazioni di I/O delle smart card.

La cache globale esistente funziona come segue:

1. L'applicazione richiede un'operazione di crittografia. Ad esempio, un certificato utente deve essere letto dalla smart card
2. Il provider di servizi di configurazione controlla la cache per l'elemento
3. Se l'elemento non viene trovato nella cache o se l'elemento è memorizzato nella cache ma non è aggiornato, l'elemento viene letto dalla smart card
4. Dopo che qualsiasi elemento è stato letto dalla smart card, viene aggiunto alla cache. Qualsiasi copia non aggiornata esistente di tale elemento viene sostituita

Il provider di servizi di configurazione memorizza nella cache tre tipi di oggetti o dati: pin (per altre informazioni, vedere memorizzazione nella cache dei PIN), certificati e file. Se uno dei dati memorizzati nella cache cambia, l'oggetto corrispondente viene letto dalla smart card nelle operazioni successive. Ad esempio, se un file viene scritto nella smart card, la cache CSP diventa obsoleta per i file e altri processi leggono la smart card almeno una volta per aggiornare la cache CSP.

La cache dei dati globale è ospitata nel servizio Smart Card per Windows. Windows include due chiamate API smart card pubbliche, SCardWriteCache e SCardReadCache. Queste chiamate API rendono la funzionalità di memorizzazione nella cache dei dati globale disponibile per le applicazioni. Ogni smart card conforme alla specifica del minidriver della smart card ha un identificatore di scheda a 16 byte. Questo valore viene usato per identificare in modo univoco i dati memorizzati nella cache relativi a una determinata smart card. Viene usato il tipo GUID Windows standard. Queste API consentono a un'applicazione di aggiungere e leggere dati dalla cache globale.

Memorizzazione nella cache dei PIN

La cache PIN protegge l'utente dall'immissione di un PIN ogni volta che la smart card non viene autenticata. Dopo l'autenticazione, una smart card non distingue tra le applicazioni sul lato host. Qualsiasi applicazione può accedere ai dati privati nella smart card.

Per attenuare questo problema, la smart card entra in uno stato esclusivo quando un'applicazione esegue l'autenticazione alla smart card. Ciò significa tuttavia che altre applicazioni non possono comunicare con la smart card e verranno bloccate. Pertanto, tali connessioni esclusive vengono ridotte al minimo. Il problema è che un protocollo , ad esempio il protocollo Kerberos, richiede più operazioni di firma. Pertanto, il protocollo richiede l'accesso esclusivo alla smart card per un periodo prolungato o richiede più operazioni di autenticazione. È qui che viene usata la cache PIN per ridurre al minimo l'uso esclusivo della smart card senza forzare l'utente a immettere un PIN più volte.

L'esempio seguente illustra come funziona. In questo scenario sono disponibili due applicazioni: Outlook e Internet Explorer. Le applicazioni usano smart card per scopi diversi.

1. L'utente avvia Outlook e prova a inviare un messaggio di posta elettronica firmato. La chiave privata si trova nella smart card
2. Outlook richiede all'utente il PIN della smart card. L'utente immette il PIN corretto
3. I dati di posta elettronica vengono inviati alla smart card per l'operazione di firma. Il client outlook formatta la risposta e invia il messaggio di posta elettronica
4. L'utente apre Internet Explorer e prova ad accedere a un sito protetto che richiede l'autenticazione TLS (Transport Layer Security) per il client
5. Internet Explorer richiede all'utente il PIN della smart card. L'utente immette il PIN corretto
6. L'operazione di chiave privata correlata a TLS si verifica nella smart card e l'utente viene autenticato e connesso
7. L'utente torna in Outlook per inviare un altro messaggio di posta elettronica firmato. Questa volta all'utente non viene richiesto un PIN perché il PIN viene memorizzato nella cache dall'operazione precedente. Analogamente, se l'utente usa di nuovo Internet Explorer per un'altra operazione, Internet Explorer non richiederà all'utente un PIN

Il provider di servizi di configurazione di base mantiene internamente una cache per processo del PIN. Il PIN viene crittografato e archiviato in memoria. Le funzioni usate per proteggere il PIN sono RtlEncryptMemory, RtlDecryptMemory e RtlSecureZeroMemory, che svuotano i buffer che contengono il PIN.

Selezione smart card

Le sezioni seguenti di questo articolo descrivono come Windows usa l'architettura delle smart card per selezionare il software, il provider e le credenziali corretti per l'accesso con smart card:

• Livelli di specifica del contenitore
• Operazioni del contenitore
• Flag di contesto
• Creare un nuovo contenitore in un contesto invisibile all'utente
• Comportamento di selezione delle smart card
• Creare una corrispondenza con il lettore di smart card
• Creare una corrispondenza con una smart card
• Aprire un contenitore predefinito esistente (nessun lettore specificato)
• Aprire un contenitore denominato GUID esistente (nessun lettore specificato)
• Creare un nuovo contenitore (nessun lettore specificato)
• Eliminare un contenitore

Livelli di specifica del contenitore

In risposta a una chiamata a CryptAcquireContext in CryptoAPI, il provider di servizi di configurazione di base tenta di corrispondere al contenitore specificato dal chiamante a una smart card e a un lettore specifici. Il chiamante può fornire un nome di contenitore con diversi livelli di specificità, come illustrato nella tabella seguente, e ordinato da richieste più specifiche a richieste meno specifiche.

Analogamente, in risposta a una chiamata NCryptOpenKey in CNG, il KSP della smart card tenta di trovare la corrispondenza con il contenitore nello stesso modo e accetta lo stesso formato del contenitore, come illustrato nella tabella seguente.

Le informazioni sul processo chiamante e sulle smart card a cui ha eseguito l'accesso al processo vengono gestite dalla smart card CSP di base e dalla smart card della cache KSP. Quando si cerca un contenitore di smart card, il provider di servizi di configurazione di base o il provider di servizi KSP per smart card controlla prima la cache per il processo. Se l'handle memorizzato nella cache non è valido o non viene trovata alcuna corrispondenza, viene chiamata l'API SCardUIDlg per ottenere l'handle della scheda.

Operazioni del contenitore

Le tre operazioni del contenitore seguenti possono essere richieste tramite CryptAcquireContext:

1. Creare un nuovo contenitore. L'equivalente CNG di CryptAcquireContext con dwFlags impostato su CRYPT_NEWKEYSET è NCryptCreatePersistedKey.
2. Aprire un contenitore esistente. L'equivalente CNG di CryptAcquireContext per aprire il contenitore è NCryptOpenKey.
3. Eliminare un contenitore. L'equivalente CNG di CryptAcquireContext con dwFlags impostato su CRYPT_DELETEKEYSET è NCryptDeleteKey.

L'euristica usata per associare un handle di crittografia a una smart card e a un lettore specifico si basano sull'operazione del contenitore richiesta e sul livello di specifica del contenitore usato.

La tabella seguente illustra le restrizioni per l'operazione di creazione del contenitore.

Flag di contesto

La tabella seguente mostra i flag di contesto usati come restrizioni per l'operazione di creazione del contenitore.

Oltre alle operazioni sui contenitori e alle specifiche del contenitore, è necessario prendere in considerazione altre opzioni utente, ad esempio i flag CryptAcquireContext, durante la selezione delle smart card.

Creare un nuovo contenitore in un contesto invisibile all'utente

Le applicazioni possono chiamare il provider di servizi di configurazione di base con CRYPT_DEFAULT_CONTAINER_OPTIONAL, impostare il PIN in un contesto invisibile all'utente e quindi creare un nuovo contenitore in un contesto invisibile all'utente. Questa operazione si verifica come segue:

1. Chiamare CryptAcquireContext passando il nome del lettore di smart card come livello di specifica del contenitore di tipo II e specificando il CRYPT_DEFAULT_CONTAINER_OPTIONAL flag
2. Chiamare CryptSetProvParam specificando PP_KEYEXCHANGE_PIN o PP_SIGNATURE_PIN e un PIN ASCII con terminazione Null.
3. Rilasciare il contesto acquisito nel passaggio 1
4. Chiamare CryptAcquireContext con CRYPT_NEWKEYSETe specificare il livello di specifica del contenitore di tipo I
5. Chiamare CryptGenKey per creare la chiave

Comportamento di selezione delle smart card

In alcuni degli scenari seguenti, all'utente può essere richiesto di inserire una smart card. Se il contesto utente è invisibile all'utente, l'operazione ha esito negativo e non viene visualizzata alcuna interfaccia utente. In caso contrario, in risposta all'interfaccia utente, l'utente può inserire una smart card o selezionare Annulla. Se l'utente annulla l'operazione, l'operazione ha esito negativo. Il grafico di flusso mostra i passaggi di selezione eseguiti dal sistema operativo Windows.

In generale, il comportamento di selezione delle smart card viene gestito dall'API SCardUIDlgSelectCard. Il provider di servizi di configurazione di base interagisce con questa API chiamandola direttamente. Il provider di servizi di configurazione di base invia anche funzioni di callback che hanno lo scopo di filtrare e associare le smart card candidate. I chiamanti di CryptAcquireContext forniscono informazioni sulla corrispondenza delle smart card. Internamente, il provider di servizi di configurazione di base usa una combinazione di numeri di serie delle smart card, nomi di lettore e nomi di contenitori per trovare smart card specifiche.

Ogni chiamata a SCardUI * può comportare la lettura di informazioni aggiuntive da una smart card candidata. I callback di selezione della smart card CSP di base memorizzano nella cache queste informazioni.

Creare una corrispondenza con il lettore di smart card

Per i livelli di specifica del contenitore di tipo I e di tipo II, il processo di selezione delle smart card è meno complesso perché solo la smart card nel lettore denominato può essere considerata una corrispondenza. Il processo per la corrispondenza di una smart card con un lettore di smart card è:

1. Trovare il lettore di smart card richiesto. Se non è possibile trovarlo, il processo ha esito negativo (è necessaria una ricerca nella cache in base al nome del lettore)
2. Se nel lettore non è presente alcuna smart card, all'utente viene richiesto di inserire una smart card. (si tratta solo in modalità non invisibile all'utente; se la chiamata viene eseguita in modalità invisibile all'utente, ha esito negativo)
3. Solo per il livello di specifica del contenitore II, viene determinato il nome del contenitore predefinito nella smart card scelta
4. Per aprire un contenitore esistente o eliminare un contenitore esistente, trovare il contenitore specificato. Se non è possibile trovare il contenitore specificato in questa smart card, all'utente viene richiesto di inserire una smart card
5. Se il sistema tenta di creare un nuovo contenitore, se il contenitore specificato esiste già in questa smart card, il processo ha esito negativo

Creare una corrispondenza con una smart card

Per i livelli di specifica del contenitore III e IV, viene usato un metodo più ampio per associare una smart card appropriata a un contesto utente, perché più smart card memorizzate nella cache potrebbero soddisfare i criteri forniti.

Aprire un contenitore predefinito esistente (nessun lettore specificato)

1. Per ogni smart card a cui è stato eseguito l'accesso da CSP di base e le informazioni sull'handle e sul contenitore vengono memorizzate nella cache, il provider di servizi di configurazione di base cerca un contenitore predefinito valido. Viene tentata un'operazione sullo SCARDHANDLE memorizzato nella cache per verificarne la validità. Se l'handle smart card non è valido, il provider di servizi di configurazione di base continua a cercare una nuova smart card
2. Se non viene trovata una smart card corrispondente nella cache CSP di base, il provider di servizi di configurazione di base chiama il sottosistema smart card. SCardUIDlgSelectCard() viene usato con un filtro di callback appropriato per trovare una smart card corrispondente con un contenitore predefinito valido

Aprire un contenitore denominato GUID esistente (nessun lettore specificato)

1. Per ogni smart card già registrata con il provider di servizi di configurazione di base, cercare il contenitore richiesto. Provare un'operazione sulla SCARDHANDLE memorizzata nella cache per verificarne la validità. Se l'handle della smart card non è valido, il numero di serie della smart card viene passato all'API SCardUI * per continuare a cercare questa smart card specifica (anziché solo una corrispondenza generale per il nome del contenitore)
2. Se non viene trovata una smart card corrispondente nella cache CSP di base, viene effettuata una chiamata al sottosistema smart card. SCardUIDlgSelectCard() viene usato con un filtro di callback appropriato per trovare una smart card corrispondente con il contenitore richiesto. In alternativa, se un numero di serie della smart card è risultato dalla ricerca nel passaggio 1, il filtro di callback tenta di corrispondere al numero di serie, non al nome del contenitore

Creare un nuovo contenitore (nessun lettore specificato)

Se il PIN non è memorizzato nella cache, non è consentita alcuna CRYPT_SILENT per la creazione del contenitore perché all'utente deve essere richiesto almeno un PIN.

Per altre operazioni, il chiamante potrebbe essere in grado di acquisire un contesto di verifica rispetto al contenitore CRYPT_DEFAULT_CONTAINER_OPTIONAL predefinito e quindi effettuare una chiamata con CryptSetProvParam per memorizzare nella cache il PIN dell'utente per le operazioni successive.

1. Per ogni smart card già nota dal provider di servizi di configurazione, aggiornare il file SCARDHANDLE archiviato ed eseguire i controlli seguenti:
   1. Se la smart card è stata rimossa, continuare la ricerca
   2. Se la smart card è presente, ma ha già il contenitore denominato, continuare la ricerca
   3. Se la smart card è disponibile, ma una chiamata a CardQueryFreeSpace indica che la smart card non dispone di spazio di archiviazione sufficiente per un contenitore di chiavi aggiuntivo, continuare la ricerca
   4. In caso contrario, usare la prima smart card disponibile che soddisfa i criteri precedenti per la creazione del contenitore
2. Se nella cache CSP non viene trovata una smart card corrispondente, effettuare una chiamata al sottosistema smart card. Il callback usato per filtrare le smart card enumerate verifica che una smart card candidata non abbia già il contenitore denominato e che CardQueryFreeSpace indichi che la smart card ha spazio sufficiente per un contenitore aggiuntivo. Se non viene trovata una smart card appropriata, all'utente viene richiesto di inserire una smart card

Eliminare un contenitore

1. Se il nome del contenitore specificato è NULL, il contenitore predefinito viene eliminato. L'eliminazione del contenitore predefinito determina l'selezione arbitraria di un nuovo contenitore predefinito. Per questo motivo, questa operazione non è consigliata
2. Per ogni smart card già nota dal provider di servizi di configurazione, aggiornare il file SCARDHANDLE archiviato ed eseguire i controlli seguenti:
   1. Se la smart card non ha il contenitore denominato, continuare la ricerca
   2. Se la smart card ha il contenitore denominato, ma l'handle della smart card non è più valido, archiviare il numero di serie della smart card corrispondente e passarlo a SCardUI
3. Se nella cache CSP non viene trovata una smart card corrispondente, effettuare una chiamata al sottosistema smart card. Il callback usato per filtrare le smart card enumerate deve verificare che una smart card candidata abbia il contenitore denominato. Se è stato specificato un numero di serie come risultato della ricerca nella cache precedente, il callback deve filtrare le smart card enumerate in base al numero di serie anziché alle corrispondenze del contenitore. Se il contesto non è invisibile all'utente e non viene trovata alcuna smart card appropriata, visualizza l'interfaccia utente che richiede all'utente di inserire una smart card

Architettura basata su CSP e KSP di base in Windows

Il diagramma seguente illustra l'architettura di crittografia usata dal sistema operativo Windows.

Proprietà CSP e KSP di smart card di base in Windows

Implicazioni per i CSP in Windows

I provider di servizi di crittografia(CSP), inclusi i CSP delle smart card personalizzati, continuano a essere supportati, ma questo approccio non è consigliato. L'uso del CSP di base e del KSP smart card esistente con il modello di minidriver smart card per le smart card offre vantaggi significativi in termini di prestazioni, PIN e memorizzazione nella cache dei dati. Un minidriver può essere configurato per funzionare nei livelli CryptoAPI e CNG. Ciò offre vantaggi dal supporto crittografico avanzato, tra cui la crittografia a curva ellittica e AES.

Se una smart card è registrata da un CSP e da un minidriver smart card, quella installata più di recente verrà usata per comunicare con la smart card.

Scrivere un minidriver, CSP o KSP per smart card

I CSP e i KSP devono essere scritti solo se funzionalità specifiche non sono disponibili nell'architettura di minidriver della smart card corrente. Ad esempio, l'architettura del minidriver della smart card supporta i moduli di sicurezza hardware, pertanto è possibile scrivere un minidriver per un modulo di sicurezza hardware e un CSP o un KSP potrebbe non essere necessario a meno che non sia necessario per supportare algoritmi non implementati nel provider di servizi di configurazione CSP di base o nella smart card KSP.

Per altre informazioni su come scrivere minidriver, CSP o KSP per smart card, vedere Smart Card Minidriver.For more information about how to write a smart card minidriver, CSP, or KSP, see Smart Card Minidrivers.