menu di navigazione del network

Lettura CIE tramite APDU


(Giuseppe Locorotondo) #1

E’ possibile leggere il certificato della cie semplicemente usando i comandi iso7816 -4.?


(Fottavi) #2

Si, è possibile. Ti invito a fare riferimento al progetto del Middleware CIE su GitHub per avere dettagli sui comandi da utilizzare per effettuare la lettura del certificato.


(Giuseppe Locorotondo) #3

Vorrei leggere il certificato dell’utente via APDU. Quello che non trovo sono le specifiche dei comandi in formato 7816-4. Quelle che per cie2.0 erano nel documento CIE - Functional Specification v2_0


(Fottavi) #4

La specifiche del sistema operativo sono reperibili qui:
http://www.unsads.com/specs/IASECC/IAS_ECC_v1.0.1_UK.pdf

Rispetto alle specifiche CIE 2.0 sono notevolmente più complesse. La procedura di lettura richiede di stabilire un canale di comunicazione cifrato, di effettuare una mutua autenticazione con il chip e di verificare il PIN dell’utente.
Rispetto alla CIE 2.0, poiché si è passati dall’interfaccia contact a quella contactless, per evitare di esporre liberamente dati sensibili si è scelto di proteggere la lettura del certificato tramite l’inserimento del PIN.


(Giuseppe Locorotondo) #5

E’ possibile leggere il certificato dell’utente chip senza fare OCR sulla stringa ICAO? Il comando di lettura del certificato deve essere fatto in Secure Messagging, e la chiave per farlo la ricavo tramite un algoritmo che prende in input OCR delle 3 righe ICAOO. Quindi non è possibile leggere l’anagrafica dell’utente dal chip come si faceva con la vecchia CIE. L’anagrafica si legge solo e soltanto facendo OCR. E’ corretto quanto dico?
Mi potete dare i riferimenti del documento dove si parla dell’algoritmo per ricavare la chiave per fare SM leggendo OCR?
Ci sono degli script in formato iso 7816-4 di esempio che permetteno di leggere il certificato dell’utente dal chip?
E’ possibile avere il pkcs#11 della cie3.0, non i sorgenti ma solo la libreria?
grazie


(Fottavi) #6

Non è esattamente così.
La CIE 3.0 contiene due applicazioni sul chip:

  • l’applicazione ICAO, identica a quella utilizzata nel passaporto elettronico, che contiene i dati personali. Tali dati sono protetti in lettura tramite una chiave ricavata dall’MRZ (le 3 righe stampate col font OCRB sul retro) o dal CAN (i 6 numeri i basso a destra sul fronte).
  • l’applicazione IAS ECC, le cui specifiche sono quelle di cui ho inviato il link, che contiene il certificato X509 di autenticazione del titolare e la relativa chiave privata. Per leggere il certificato e usare la chiave privata è necessario verificare un PIN di 8 cifre. Nella sezione releases del progetto GitHub trovi i setup delle CSP/PKCS11 che installano le librerie. Se dovessi trovare dei bug nelle librerie ti prego di segnalarlo qui o su GitHub.

(Giuseppe Locorotondo) #7

Per la lettura del certificato di autenticazione, utilizzando l’applicativo IAS ECC, via APDU, ad un certo punto bisogna selezionare la cartella CIE. L’apdu che bisogna utilizzare è :00a4040c06a00000000039. AID della CIE è a00000000039. Nelle specifiche del file system (cie_3.0_-_specifiche_chip.pdf recuperato da web) non trovo queste informazioni e altre per l’autenticazione. Il file system quindi risulta essere non completo. Per avere tutte le informazione bisogna leggersi i sorgenti del pkcs#11 e fare un trace degli APDU. E’ possibile avere le specifiche del file system complete?


(Fottavi) #8

Buongiorno,
le specifiche del file system vanno integrate con due dati aggiuntivi, che al momento della stesura non erano ancora state definiti:

  • L’AID del DF CIE, che come ha desunto dal codice del middleware è A0 00 00 00 00 39
  • L’AID del’applet IAS ECC. Sono accettabili sia le implementazioni in cui l’Applet CIE va selezionata esplicitamente, e in questo caso l’AID da utilizzare è A0 00 00 00 30 80 00 00 00 09 81 60 01, sia le implementazioni in cui l’Applet CIE si trova a livello di Master File, quindi non è necessario selezionarla esplicitamente.

Le CIE emesse fino a oggi richiedono la selezione esplicita dell’Applet tramite il comando
00 A4 04 0C 0D A0 00 00 00 30 80 00 00 00 09 81 60 01
I prossimi lotti di produzione potrebbero rientrare nella seconda categoria. Tutte le altre informazioni richieste per effettuare l’autenticazione sono contenute nel documento di specifica del file system.


(Giuseppe Locorotondo) #9

Buongiorno, studiando il middleware, ho notato che nel modulo ias.cpp è definita una coppia di chiavi RSA fissa nel codice che viene usata nella procedura DAPP (quando si fa external authenticate). Questa chiave in futuro rimarrà fissa?
grazie


(Fottavi) #10

Buonasera,
si, la chiave rimarrà fissa.


(Giuseppe Locorotondo) #11

Buongiorno, abbiamo realizzato una libreria che permette di leggere, previa digitazione PIN, in ambiente windows l’anagrafica del titolare via NFC utilizzando i soli APDU. Stiamo facendo la stessa cosa in ambiente Linux. Tutto ciò è stato possibile leggendo i sorgenti del pkcs#11 e del csp. Abbiamo notato che per lavorare con RSA usate la libreria microsoft di cui usate BCryptImportKeyPair e BCryptEncrypt (questa sia per fare encrypt che per fare decrypt). In ambiente Linux quale libreria state utilizzando per fare la stessa cosa? Grazie


(Fottavi) #12

Buongiorno,
Complimenti innaniztutto per il vostro lavoro. Le librerie CIE per linux sono in corso di sviluppo e sono disponibili su github a questo indirizzo:


Per la parte crittografica vengono usate le librerie OpenSSL.


(Giuseppe Locorotondo) #13

Complimenti a Voi per l’ottimo lavoro, per niente semplice. Sto testando un po il pkcs#11 su Mozilla con lo scopo di fare una strong authentication. Con l’occasione mi sono accorto di un comportamento che secondo me è anamalo sul pkcs#11. Supponendo di usare il pkcs#11 per la lettura del certificato di strong authentication, se dopo aver fatto questo e richiamo la c_finalize, poi cancello la cache dalla cartella C:\ProgramData\CIEPKI e rifaccio c_initialize per arrivare poi a fare una c_openSession, ciepki.dll non richiama la finestra di inserimento login, pur essendo stata cancellata la cache, questo significa che la c_finalize non ha ripulito correttamente le sue strutture.
Cosa ne pensa?

Ho testato ciepki.dll pkcs11 via mozilla, almeno riguardo alla lettura del certificato di autenticazione e tutto funziona correttamente. Ora avrei bisogno di fare una mutua autenticazione ma non ho dei sample. Voi avete allestito un server per fare dei test di strong authentication?

Immagino che se desidero fare una strong authentication via pkcs11 i comandi siano
login come CKU_USER,
ricerca handle della chiave privata
c_sign_init con RSA_PKCS come meccanismo o equivalentemente RSA_PKCS_X509
e poi c_sign dove passo il dato che firmo. Mi sarei aspettato disponibile una decrypt, ma su questa chiave la decrypt non è disponibile. Come mai allora se richiamo C_GetMechanismInfo ho:
Mechanism Type CKM_RSA_PKCS
MinKeySize 1024
MaxKeySize 2048
Flags CKF_HW
CKF_ENCRYPT
CKF_DECRYPT
CKF_SIGN
CKF_SIGN_RECOVER
CKF_VERIFY
CKF_VERIFY_RECOVER
Mechanism Type CKM_RSA_X_509
MinKeySize 1024
MaxKeySize 2048
Flags CKF_HW
CKF_ENCRYPT
CKF_DECRYPT
CKF_SIGN
CKF_SIGN_RECOVER
CKF_VERIFY
CKF_VERIFY_RECOVER

NON DOVREI AVERE CKF_DECRYPT, NON FUNZIONA SULLA CHIAVE PRIVATA.

CONCLUDENDO nella strong authentication penso che si debba per forza fare una sign e da questa poi ottenere la chiave di sessione dal server. E’ corretto?

La ringrazio per la disponibilità
Locorotondo Giuseppe