Applet Java per l'autenticazione reciproca con smart card

Question

Applet Java per l'autenticazione reciproca con smart card

#1 da (3 voti)
#2 da (0 voti)

3

Ho bisogno di sviluppare un'applet java, per un'autenticazione reciproca tra Tomcat 6 (server) e una SmartCard "IDGo 300" (client).

Per fare questo ho pensato allo schema seguente:

Tomcat (server) invia a SmartCard (client) la richiesta del suo certificato digitale (firmato da CA).
Il client immette il PIN e seleziona un certificato disponibile sulla smart card, quindi l'applet invia il suo certificato (firmato da CA) a Tomcat. tomcat verifica il certificato digitale e se corretto restituisce il suo certificato.
L'applet verifica il certificato del server e, se il certificato è corretto, invia una conferma al server. Il server dà pieno accesso al client per utilizzare l'applicazione web.

Domande :

Questo schema è fattibile?
Mi piacerebbe gestire tutto tramite la mia applet e quando il client disconnette la smart card perde l'accesso al server.

java tls

posta xfocus 29.07.2012 - 15:58

fonte

2 risposte

Leggi altre domande sui tag java tls

Utilizzo di GPG o PGP per la crittografia / decodifica di database simmetrici in c # Credenziale minima per i parametri WMI Monitoraggio?

score 3 · Answer 1

Sì. Questo è fattibile. Esiste un modo standard per raggiungere questo obiettivo: si utilizza SSL con un certificato client. Questa funzione di SSL fa già esattamente ciò che vuoi ed è stata ben controllata, quindi ti consiglio di usarla.

In questo schema, il certificato del cliente e la chiave privata del client associato sono memorizzati sulla smartcard. La chiave privata non lascia mai la smartcard. Per dimostrare l'identità del cliente, il server invia una richiesta e la smartcard firma (e altre cose) con la chiave privata del client - questo è tutto integrato in SSL , quindi non devi implorarlo da solo, ti sto solo dando dell'intuizione su come funziona il protocollo.

Non è necessaria alcuna applet Java. Tutto ciò che serve è che il tuo browser supporti PKCS # 11. Ad esempio, Firefox supporta questo.

Se per qualche motivo si desidera utilizzare un'applet Java, si desidera nuovamente controllare PKCS # 11, le API Java Crypto e il provider di crittografia Sun PKCS # 11. Vedi anche questa domanda .

score 0 · Answer 2

IMHO prima di tutto le comunicazioni devono essere su ssl tra applet e server.

In secondo luogo il protocollo dovrebbe avere una protezione di riproduzione (nel caso in cui ssl con la negoziazione DH lo fornisca in una certa misura).

Per quanto riguarda il protocollo stesso dopo che il certificato degli utenti è stato recuperato dall'applet, dovrebbe inviare richieste di verifica crittografate e autenticate (per applet) che potrebbero includere cose come id di sessione, credenziali utente aggiuntive, ecc.). Questa richiesta deve essere crittografata con la chiave pubblica dei server e autenticata con la chiave privata delle applet (avremo la doppia verifica che il server è l'unico destinatario previsto e quell'applet è autenticata mittente ), dopo SOLO SERVER !!!! il server di verifica deve inviare la risposta all'applet nuovamente crittografata con la chiave pubblica delle applet e firmata con la chiave privata dei server , per le ragioni sopra citate). Dovrebbe essere solo informativo e il server dovrebbe gestire le decisioni di autenticazione che dovremmo fornire solo un percorso attendibile tra smart card e server.

Per quanto riguarda il punto 2, è possibile inviare informazioni tramite il nostro nuovo protocollo al server che la scheda è stata disconnessa e la sessione autenticata dell'utente dovrebbe essere invalidata.

P.S. Per quanto riguarda l'applet di autenticazione reciproca < - > server possiamo usare qualche rinegoziazione del tempo DH se siete preoccupati dell'estrazione di chiavi private.