Autenticazione Web tramite certificati PKI

Capisco la PKI ragionevolmente bene da un punto di vista concettuale - cioè chiavi private / chiavi pubbliche - la matematica dietro di loro, l'uso di hash e crittografia per firmare un certificato, firma digitale di transazioni o documenti ecc. Ho anche lavorato su progetti in cui openssl Le librerie C sono state utilizzate con certificati per garantire la comunicazione e l'autenticazione. Conosco anche gli strumenti della riga di comando di openssl.

Tuttavia, ho pochissima esperienza con progetti abilitati PKI basati sul web e quindi sto cercando di progettare e codificare un progetto personale per capirlo meglio.

I requisiti

Questo è il sito Web di una banca. A tutti gli utenti di Internet Banking è consentito utilizzare qualsiasi certificato emesso da alcune CA conosciute (verisign, Thawte, affidust ecc.). La Banca non è responsabile per l'acquisizione di certificati per l'utente. Questi certificati verranno utilizzati per l'autenticazione sul sito Web delle banche. Le piattaforme / SO ecc. Non sono ancora stati corretti.

Design

Mi chiedevo quale fosse il modo migliore per eseguire l'autenticazione.

1. Ho visto che Apache ha un modo per abilitare ssl a 2 vie - in questo caso, penso che navigare sul sito web richiederebbe automaticamente un certificato all'utente. Ma non sono sicuro che questo sia sufficiente perché sembra che tutto ciò che verifica sia se un certificato è firmato da un'autorità di certificazione attendibile e potrebbe anche essere se rientra in una lista bianca di argomenti dei certificati ecc. Ma questo non è abbastanza per un caso bancario perché è necessario poter associare un bankuserid a un certificato.

2. Sembra che IIS abbia un modo per archiviare un certificato per ciascun utente in Active Directory. Questo è quello che ho capito leggendo alcuni articoli MSDN. Si attiva SSL a 2 vie in IIS e quindi quando l'utente tenta di accedere al sito Web, IIS invierà una richiesta al browser con un elenco di CA approvate e il browser consentirà all'utente di scegliere un certificato appropriato dal proprio certstore e inviarlo backend. Suppongo che IIS farà 2 cose

   • Assicurarsi che l'utente disponga della chiave privata corrispondente al certificato (secondo le trattative di copertura)
   • Sulla base della mappatura dei certificati utente-utente AD, IIS segnalerà il nome utente all'applicazione.

3. Esegui esplicitamente l'autenticazione chiamando le funzioni di crittografia piuttosto che dipendono dal server web per farlo.

   • Mostra una schermata utente in cui carica un certificato e l'applicazione assicura che l'utente disponga della chiave privata corrispondente al certificato (chiedendo al front-end di firmare una stringa usando il certificato).
   • L'applicazione ha un database in cui sono memorizzati alcuni dati che consentono a ciascun utente di essere mappato sul proprio ID utente. Può essere
   • l'intero certificato corrispondente a ciascun ID utente
   • il numero di serie CA e certificato corrispondente a ciascun ID utente.

Mi chiedevo quale sia il metodo comunemente usato? Quali sono le migliori pratiche? Se dovessi scegliere il n. 3, quali sono i modi migliori per farlo?

Qualcosa che può anche funzionare facilmente con le app per smartphone sarà un ulteriore vantaggio.

Aggiornare

Permettetemi di chiarire la mia affermazione "codifica me stesso la parte di autenticazione" perché alcune delle risposte sembrano indicare che è stata fraintesa - il mio male per non essere chiaro.

Questo non significa che scrivo cose crittografiche da solo. Significa solo che in realtà chiamerò esplicitamente le routine di crittografia invece di dipendere da IIS o da qualsiasi altro server web che lo faccia implicitamente.

Anche se volevo davvero rispondere a ogni problema, penso che colpirò questo argomento per argomento:

Autorizzazione / Autenticazione

OK, prima le cose. Per il tuo esempio, hai bisogno di entrambi:

• Autenticazione : prova che l'utente è chi dice di essere. Hai scelto PKI, con la prova implicita della chiave privata come autenticazione.
• Autorizzazione : connessione dell'utente a ciò che gli è consentito fare. Questo è il punto di connessione tra il login e l'accesso agli account consentiti. La mappatura delle funzionalità di accesso da certificato a account e account è l'autorizzazione.

Per quanto riguarda l'autorizzazione, hai il problema di capire il processo tramite il quale colleghi il DN soggetto del tuo utente al suo conto bancario. Data la gravità della transazione, vuoi sicuramente avere un processo forte per questo, e non esiste un solo modo giusto qui. Dovresti consultare la banca, e probabilmente i suoi avvocati, per capire come farlo in conformità con la politica.

SSL, autenticazione client / server, prova di chiave privata

Il protocollo SSL include sempre l'autenticazione del server, con un'impostazione opzionale aggiuntiva per l'autorizzazione lato client. Hai ragione con il numero 1 in quanto Apache offre un'impostazione che aggiunge l'autenticazione client tramite PKI e puoi effettuare il provisioning con un elenco di CA affidabili. Durante l'installazione di una sessione SSL che richiede l'autenticazione client tramite PKI, otterrai una prova della chiave privata.

L'opzione n. 1 o n. 2 fornirà ciò: sia Apache che IIS possono essere configurati in questo modo. Per quanto riguarda le migliori pratiche, prenderei l'uno o l'altro oltre a proporre la tua soluzione. # 3 si avvicina pericolosamente alla regola "non scrivere la tua criptovaluta". Supponendo che sia possibile associare la transazione alla presenza di una sessione SSL autenticata, non vi è alcun motivo per eseguire il rollback della propria.

Inoltre, nell'opzione n. 1 o n. 2, esiste un modo per mettere le mani sull'intero certificato e, da lì, su qualsiasi parte del certificato. In genere l'oggetto DN e / o il numero di serie del certificato vengono utilizzati per determinare l'identità dell'utente a fini di autorizzazione.

In termini di "uso comune", tutti i principali server Web sono piuttosto comuni. IIS, Apache, Tomcat e molti altri possono essere configurati con SSL di autenticazione client. La decisione da lì si basa in gran parte sull'attuazione globale. I principali server Web hanno avuto tutti i modi per ottenere l'accesso al certificato fornito nella sessione SSL, che è ciò di cui hai bisogno per una verifica più dettagliata.

Componenti aggiuntivi per la verifica del certificato

Come minimo, dovrai:

• impostare una sessione SSL
• estrarre il certificato (la maggior parte dei web server controllerà la firma del certificato e la prova della chiave privata)
• verifica la data di validità del certificato (non indicata con alcun server web)
• eseguire il controllo dell'autorizzazione a quali account può accedere questo certificato

Date le elevate poste in gioco nel settore bancario, potresti anche voler verificare lo stato di revoca del certificato: se la chiave privata dell'utente viene persa o rubata, il loro certificato dovrebbe essere revocato.

IIS potrebbe avere i ganci per una verifica OCSP o CRL - tende ad essere un tipo di sistema più completo (mano che regge!), Ma non ricordo la parte superiore della mia testa. Inoltre, non ricordo se ti costringerà a utilizzare i prodotti Microsoft per questo. Per Apache, dovresti quasi certamente codificare o aggiungere un controllo OCSP / CRL. Credo che abbia degli hook durante la creazione della sessione SSL - di solito questo controllo viene eseguito una volta quando viene impostata la sessione SSL.

Autorizzazione

Su # 1 vs. # 2 - hai ragione che IIS ha alcune funzionalità integrate che legheranno il certificato fornito nella sessione SSL a un repository AD. È uno dei casi in cui Microsoft fa il possibile per semplificare l'acquisto e l'utilizzo di più prodotti. :) Ci sono sfumature su come IIS si lega ad AD che vanno oltre lo scopo di questa domanda e oltre il mio immediato ricordo. Ho fatto cose piuttosto pazze con IIS e AD, e il mio pensiero generale è che mentre stai facendo qualcosa di relativamente semplice come estrarre il nome utente basato sul certificato da un repository AD, probabilmente stai bene. È quando ti imbatti in problemi più complessi di archiviazione dei dati, ricerche di AD strani e in particolare di cose folli (ma legittime) con PKI, tu '

Con IIS, anche se ancora, avrai bisogno di qualcosa di aggiunto alla tua struttura AD, o altrove, legando il nome utente al conto bancario. In genere nel settore bancario, un utente ha più account. E 2 utenti possono avere un account congiunto, quindi questa è una relazione da molte a molte.

Per # 1 - sì, devi scrivere la tua ricerca. È necessario codificare: - un database o una gerarchia LDAP che collega il certificato all'utente e l'utente ai conti bancari dell'utente. La parte unica garantita di un certificato è il numero seriale + DN emittente. Spesso il DN soggetto funzionerà, ma non è garantito in tutti i sistemi PKI.

Questo è in genere il modo in cui gli sviluppatori che utilizzano PKI per l'autenticazione di fascia alta con Apache lo fanno. Avendo lavorato in molti di questi sistemi, non ho ancora incontrato un caso di facile riutilizzo delle autorizzazioni, quindi non lo vedo mai come un enorme svantaggio - dovrò avere qualcosa di specializzato in entrambi i modi, poiché i ruoli / privilegi sono mai facile.

Questo suona come un mix di # 1 e # 3 - il mio consiglio forte sarebbe - usare le capacità native di qualunque applicazione / web server che usi per generare la sessione SSL. Ciò consentirà al browser di configurare il server con la query del certificato in modo standard e ottimale. Da lì, con Apache, dovrai creare il tuo sistema di autorizzazione. IIS fornirà l'idea di Microsoft su come dovrebbe funzionare per te.

Gotcha noti

Fai un sacco di test del browser. Di anno in anno, browser per browser, trovo i gotcha con la gestione delle sessioni SSL. Concatenare correttamente la sessione SSL alla serie di richieste di pagine Web e assicurarsi che la disconnessione sia gestita correttamente sono le principali aree di preoccupazione. E ha molto a che fare sia con il server che con il software del browser. SSL è abbastanza stabile che quando funziona, di solito funziona, anche se ci possono essere problemi di IE e di chiunque altro.

In particolare, l'ultima volta che l'ho fatto, la questione della codifica forzata e del timeout della sessione è stata un grosso problema.

Smart Phone

Buona. Fortuna. è tutto ciò che posso dire. Non sono affatto uno sviluppatore di app mobili, ma la mia impressione finora è che nello smartphone medio, la gestione dei certificati PKI sia inferiore o inesistente.

Mi piacerebbe tanto essere smentito.

I certificati personali funzionano bene per il rinnovo periodico dei certificati (che ha alle spalle un processo abbastanza solido) e possono essere implementati come un'autenticazione "senza password" che piace ai clienti

ma dove fallisce è

• Il costo per certificato
• compatibilità con i browser moderni
• utenti finali che estraggono certificati e archiviano le chiavi private in modo sicuro

tieni presente che i certificati personali moderni con firma sha-2 non funzionano con Safari su iPad e molti browser moderni. Questo perché i certificati personali non sono mai decollati come le autorità dell'autorità di certificazione hanno pensato. L'emissione di 30.000 certificati (cosa facciamo) costa circa lo stesso per certificato di alcuni tipi di token hardware.

La tua strategia per consentire ai clienti di trovare i propri certificati non è realmente valida. Oggigiorno è difficile trovare fornitori di certificati personali e sono piuttosto costosi: è necessario assicurarsi che il business case funzioni altrimenti i clienti semplicemente non compreranno questo.

Okay, stanno succedendo molte cose qui. Innanzitutto, l'autenticazione client cert è inutile se non è supportata sull'endpoint. Quindi, abbiamo un ottimo post da Intrepidus che copre le basi dell'autenticazione client per le app per smartphone .

Quindi, lascia che ti suggerisca di non codificare la tua routine di autenticazione. Ci sono molte grandi librerie controllate che gestiscono questo. Ti risparmierai funzionalità e bug di sicurezza eseguendo una libreria matura per l'autenticazione. Utilizzare una libreria esaminata e matura per questo sarebbe sicuramente la migliore pratica.

La prossima best practice consiste nell'utilizzare una directory per gestire il client: mapping dei certificati. Quindi guarderai AD o LDAP. Come hai già detto, Windows e IIS lo rendono abbastanza perfetto per te. IIS.net ha una buona carrellata sulla configurazione del mapping dei certificati in IIS .

Se si rotola con Apache, questo non è così facile da usare. Sembra che mod_authz_ldap esegua il mapping dei certificati client, ma non ho lavorato personalmente con esso.

Questo ci porta alla logistica di implementare qualcosa del genere. Non stai firmando i certificati degli utenti, quindi è necessario un processo ironico per un utente che invia il proprio certificato e che la tua app lo pubblica nella directory. Vorrei vedere due fattori per questo, con una password auth e un messaggio di testo o una chiamata a un numero di fiducia. Vorrei e-mail all'utente per far loro sapere che è stato aggiunto un certificato al proprio account. Vorrei consentire a un utente di rimuovere la mappatura cert utente tramite la pagina di gestione dell'account nell'app.

Vorrei vedere cosa fanno Google e Facebook per impostare i cookie per dispositivi affidabili per evitare due fattori. Avrei avuto l'autenticazione di nuovi dispositivi con due fattori prima di consentire l'autenticazione del solo certificato.

Vorrei anche pensare a come gestire la revoca dei certificati utente. Ciò significa controllare un elenco di revoche di certificati esterni (CRL). Cosa fai se un certificato client non ha un punto di distribuzione CRL definito? Controlli il CRL ogni volta che l'utente accede o su base pianificata come parte di un lavoro, dal momento che probabilmente ci saranno solo una manciata di CRL in uso?

In realtà, ciò si riduce a: come faccio a sapere che posso fidarmi che i certificati degli utenti non sono stati compromessi e come posso fidarmi di poter mappare il certificato X all'utente Y.