Digital signing source code software for µFR Series NFC RFID contactless readers
La firma digitale è il futuro del business online, sia che si parli di semplice firma di documenti, codice ed e-mail o di un'implementazione crittografica più avanzata come vediamo oggi nelle criptovalute e nelle blockchain.
Digital Logic Ltd. è una delle prime aziende al mondo a implementare soluzioni di firma digitale con carte RFID contactless.
Ci aspettiamo che i vecchi sistemi che utilizzano ancora le schede contatto diventeranno presto un ricordo del passato.
Il software μFR Signer supporta algoritmi crittografici RSA ed ECDSA per la firma digitale dei file.
Il software è destinato ad essere utilizzato con la nostra serie μFR di dispositivi NFC: Nano, Classic, Classic CS e Advance.
μFR Signer funziona con tutte le schede che supportano RSA ed ECDSA. Nel nostro video dimostrativo, abbiamo usato la scheda JCOP J3D081.
Le carte DL Signer forniscono la firma digitale di dati e documenti nelle schede stesse utilizzando algoritmi crittografici asimmetrici RSA o ECDSA. L'infrastruttura PKI è supportata e nelle schede DL Signer è possibile memorizzare certificati X.509 correlati a coppie di chiavi crittografiche generate nelle schede stesse. È supportato per archiviare tutti i certificati X.509 che costituiscono la catena di attendibilità dal certificato radice al certificato dell'entità finale.
La chiave pubblica generata nelle schede DL Signer viene inserita nel corpo della richiesta durante la creazione del requisito di firma del certificato (di seguito CSR). La richiesta viene firmata nella scheda stessa con un'apposita chiave privata che non lascia mai la carta stessa e in nessun modo può essere letta dopo aver generato coppie di chiavi. Inoltre, la CSR viene inviata all'ente di certificazione per creare e firmare il certificato X.509 basato su di esso. Questo certificato dell'entità finale viene inserito nella scheda DL Signer con altri certificati della catena di attendibilità ed è pronto per firmare digitalmente dati e documenti. L'utente può inviare CSR a qualsiasi ente di certificazione di cui desidera utilizzare i servizi. Digital Logic ha fornito un meccanismo per l'emissione di certificati di entità finale per testare il sistema. Una delle caratteristiche di base del certificato dell'entità finale è che la chiave privata, associata alla chiave pubblica contenuta in tali certificati, non deve essere utilizzata per firmare altri certificati.
Gli strumenti software di Windows che avviano la generazione di coppie di chiavi crittografiche, generano CSR, gestiscono i codici PIN e PUK delle schede DL Signer, manipolano il contenuto dei certificati X.509 e firmano i dati e i file, vengono distribuiti come "ufr-signer".
"Signature-verifier" è un'applicazione Windows che convalida le firme digitali RSA ed ECDSA.
La firma digitale e la convalida delle firme possono essere eseguite anche dall'applicazione Adobe Acrobat Reader DC utilizzando il modulo ufr-pkcs11 che abbiamo sviluppato per questo scopo. Il nostro modulo PKCS#11 può essere utilizzato anche con il popolare client di posta elettronica e browser web di Mozilla, nonché con altri strumenti software compatibili con la specifica PKCS#11.
Abbiamo anche fornito servizi web per il controllo online dei certificati X.509 e dei file pdf firmati.
Firmatario uFR
"uFR Signer" è uno strumento software che avvia la generazione di coppie di chiavi crittografiche, genera richieste CSR, serve a gestire i codici PIN e PUK delle schede DL Signer, manipola il contenuto dei certificati X.509 e firma i dati e i file.
L'applicazione è suddivisa in diverse unità logiche utilizzando un componente visivo di controllo a schede. Le schede sono etichettate con i nomi di queste unità:
"Chiavi RSA" e "Chiavi EC" vengono utilizzate per creare e manipolare coppie di chiavi RSA o ECC.
RSA (Rivest, Shamir, & Adleman) ed ECC (Elliptic Curve Cryptography) rappresentano algoritmi crittografici asimmetrici contemporanei. Le schede DL Signer supportano la memorizzazione di 3 chiavi RSA e 3 chiavi ECC separatamente. Ciascuna delle chiavi crittografiche può essere di diverse lunghezze e caratteristiche ed è indicata da un algoritmo crittografico e da un indice chiave.
La scheda "Codici PIN" si riferisce alla gestione e alla registrazione del codice PIN dell'utente sulla scheda DL Signer situata nel campo del lettore uFR. Il PIN è l'abbreviazione di "Numero di identificazione personale". Oltre ai codici PIN, in questa scheda puoi anche sbloccare le carte eventualmente bloccate utilizzando i codici PUK. PUK è l'acronimo di "PIN Unlock Key".
La scheda "Oggetti scheda" viene utilizzata per gestire i certificati CA e i certificati dell'entità finale associati alle rispettive chiavi crittografiche tramite i relativi indici. I certificati devono essere conformi alla versione X.509 3. Le credenziali dell'entità finale devono contenere una chiave pubblica originariamente generata nella scheda DL Signer in coppia con la chiave privata associata. Lo scopo principale del certificato è l'utilizzo con la preparazione per la firma tramite il modulo PKCS#11. La presenza dei certificati X.509 non è obbligatoria per l'utilizzo della DL Signer Card con le applicazioni proprietarie.
Nella scheda "Firma" ci sono opzioni per la creazione di firme digitali. È possibile firmare una matrice di byte, un input di testo o un file. Queste firme possono essere verificate utilizzando l'applicazione "signature-verifier".
Per risolvere i problemi di prestazioni in modo efficiente, le schede DL Signer sono progettate per firmare blocchi di dati nel modo più conciso possibile. Pertanto, è una pratica firmare digitalmente i dati con un algoritmo RSA come definito dallo schema PKCS#1 v1.5. Per l'algoritmo ECDSA, la procedura di generazione della firma digitale, il riempimento e i meccanismi di allineamento sono definiti nella RFC 6979.
L'ultima versione dell'applicazione uFRSigner è la 1.5.3.0 ed è necessario utilizzare la libreria uFCoder versione 5.0.1 o successiva e il firmware uFR versione 5.0.7 o successiva.
Codici PIN
Il codice PIN è l'abbreviazione di "Numero di identificazione personale". La DL Signer Card contiene 2 diversi codici PIN. Questi sono IL PIN SO (Security Officer) e il codice PIN dell'utente. Il cosiddetto "Security Officer" è un utente che dispone di privilegi amministrativi per l'accesso agli oggetti di sicurezza sulla DL Signer Card. QUINDI il codice PIN dovrebbe essere diverso dal codice PIN dell'utente.
"Security Officer" è necessario essere loggati per accedere alla carta nei casi in cui sia necessario modificare i codici PIN e PUK e modificare il contenuto della memoria per le chiavi e i certificati. L'accesso con un codice PIN utente è necessario per ottenere la firma digitale di una stringa di dati con hash.
I codici PIN sulle DL Signer Card possono avere un minimo di 4 caratteri e un massimo di 8 caratteri. Qui, sotto il carattere, c'è qualsiasi carattere alfanumerico (con distinzione tra maiuscole e minuscole) o stampabile. I caratteri stampabili si riferiscono principalmente ai segni di punteggiatura sulle tastiere standard. Quando si modificano i codici PIN, non è consigliabile l'uso di caratteri specifici che possono essere trovati solo su singole tastiere localizzate, ma solo caratteri che sono in standard ASCII e che esistono su tastiere standard inglese americano.
In tutte le DL Signer Card, i codici PIN e PIN utente predefiniti vengono impostati inizialmente, costituiti da otto caratteri numerici consecutivi '0' (zero) o "000000000".
Il numero massimo di codici PIN consecutivi errati immessi è 5. Se viene superato il numero di tentativi successivi errati di immissione del codice PIN, tale codice PIN viene bloccato. Mentre il codice PIN non è bloccato, l'immissione del codice PIN corretto reimposta il contatore dei codici PIN immessi in modo errato.
L'unico modo per sbloccare il PIN è inserire il codice PUK corretto. PUK è l'abbreviazione di "PIN Unlock Key". Il codice SO PUK serve esclusivamente a sbloccare il codice PIN SO e l'utente PUK a sbloccare il codice PIN dell'utente. Nel caso di 10 codici PUK consecutivi inseriti in modo errato, il codice PUK diventa inutilizzabile e la funzionalità della carta su cui si riferisce il codice PIN bloccato rimane bloccata per sempre.
Chiavi RSA
Nella scheda "Chiavi RSA" sono disponibili opzioni per la creazione e la gestione delle chiavi RSA. Prima di utilizzare le chiavi RSA, la scheda di firma DL deve trovarsi nel campo del lettore uFR connesso al computer che esegue l'applicazione ufr-signer. Inoltre, SO (Security Officer) deve essere connesso.
Tasti EC
Nella scheda "Ec Keys" ci sono opzioni per la creazione e la gestione della chiave EC. Prima di utilizzare le chiavi EC, la DL Signer Card deve trovarsi nel campo del lettore uFR collegato al computer che esegue l'applicazione ufr-signer. Inoltre, SO (Security Officer) deve essere connesso.
Le DL Signer Card supportano le seguenti curve ECC standard:
Generazione di una richiesta di firma del certificato (CSR)
È definito dallo standard PKCS#10 e rappresenta un record standardizzato che, tra le altre cose, contiene informazioni di base sull'utente del certificato nel nome distinto. Sulla base del nome caratteristico, il cosiddetto Soggetto (campo soggetto) viene formato nel certificato X.509 finale. Inoltre, i record CSR possono anche contenere estensioni specificate dallo standard X.509 che l'autorità di certificazione (CA) può prendere in considerazione o scartare, a seconda della sua politica di certificazione. La parte fondamentale della CSR è sicuramente una chiave pubblica e i suoi parametri. Tutti questi dati, confezionati nella forma definita dallo standard PKCS#10, vengono infine passati attraverso l'apposito algoritmo di cryptographic digest e il risultato viene firmato nella scheda con l'apposita chiave privata. La firma digitale così acquisita diventa parte integrante della CSR.
La CSR viene inviata all'emittente desiderata del certificato, che rappresenta la cosiddetta Autorità di certificazione (CA). L'autorità emittente del certificato genererà il certificato dell'entità finale X.509, firmato dalla rispettiva chiave privata, ora associata alla chiave pubblica contenuta nel certificato CA intermedio o radice appropriato. In questo modo, il certificato dell'entità finale diventa parte della catena di attendibilità garantita dall'Autorità di certificazione (CA).
La finestra di dialogo "Certificate Signing Request (CSR)" è un gruppo separato per l'input di "Distinguished Name (DN)", "Extensions" e nella parte in alto a destra dei gruppi di caselle combinate, per il controllo dell'algoritmo hash e la definizione della chiave crittografica. In basso a destra c'è un gruppo di pulsanti per la scelta delle attività relative alla generazione di CSR.
Un nome distinto, denominato DN, è costituito da un gruppo RDN (Relative Distinguished Name) che rappresenta il gruppo di attributi. Quando si definisce un DN, l'ordine del campo RDN è molto importante. È importante notare che è possibile ripetere un singolo campo RDN più volte all'interno del DN. Va ricordato che l'Autorità di Certificazione (CA) non è obbligata a rilasciare un certificato con lo stesso DN come definito nella CSR, ma il DN può formarsi in base alle proprie regole e ai dati ottenuti durante la verifica precedentemente implementata dell'identità dell'utente.
La formazione del DN viene eseguita selezionando l'RDN appropriato dalla casella combinata e digitando il valore desiderato nella casella di testo. Premendo il pulsante "Put", l'RDN dichiarato verrà inserito nell'elenco (List Box) che definisce DN. Se uno dei campi RDN è stato selezionato nell'elenco, il nuovo RDN verrà inserito tra il campo selezionato e quello precedente. Se non è selezionato nulla nell'elenco DN, alla fine dell'elenco viene inserito un nuovo campo RDN. Per annullare la selezione nell'elenco, premere il pulsante "Deseleziona". RDN errato può essere rimosso dall'elenco premendo "Rimuovi". L'ordine del campo RDN può essere modificato utilizzando i pulsanti "Sposta su" e "Sposta giù" che influiscono sulla ridondanza dell'RDN selezionato nell'elenco.
Le estensioni sono una parte facoltativa della CSR e l'Autorità di certificazione (CA) può prenderle in considerazione o rifiutarle, a seconda dei criteri di certificazione. È possibile assegnare più attributi ed è consigliabile definire un indirizzo di posta elettronica all'interno dell'oggetto alternativo del soggetto (nome alternativo del soggetto, subjectAltName abbreviato) perché questo è l'emittente di certificati più comune nel solito posto per questo scopo. Per le estensioni, l'ordine dei singoli attributi non è importante. Si prevede che lo scopo desiderato delle chiavi, lo scopo esteso delle chiavi e le dichiarazioni relative ai certificati qualificati possano ancora essere definiti. Ancora una volta, va sottolineato che gli emittenti del certificato possono ignorare le estensioni e solo alcuni di loro possono emettere i cosiddetti certificati elettronici qualificati. In ogni caso, all'interno delle estensioni, l'utente può indicare gli elementi desiderati del futuro certificato, ma, ancora una volta, l'eliminazione finale del certificato X.509 dipende esclusivamente dal loro emittente e che tutti i dettagli devono essere pienamente familiarizzati con le loro politiche prima della conclusione del contratto di emissione.
La scelta dell'algoritmo hash viene effettuata dalla casella combinata contrassegnata con l'"algoritmo signer digest". La scelta predefinita è SHA-256, che si riferisce all'algoritmo SHA2 che ha 256 bit all'output o 32 byte e questo è consigliato da utilizzare per CSR. SHA1 non è più raccomandato e SHA2 con un numero maggiore di byte all'output (384 e 512) e l'algoritmo SHA3 è pianificato per un uso più frequente in futuro.
Le chiavi e i loro parametri ("signer cipher algorithm" e "signer key index (card)") non possono essere modificati qui e ci sono già definiti nella scheda da cui hai aperto questa finestra di dialogo ("RSA Keys" o "EC Keys") e il loro scopo qui è solo informativo. Se le "Chiavi RSA" o "Chiavi EC" da cui è stata aperta la finestra di dialogo CSR, non c'era alcuna chiave pubblica corrispondente, precedentemente letta dalla scheda, sull'etichetta che indica la dimensione della chiave RSA, La curva ECDSA sarà indicata come "Chiave pubblica non impostata". Quando una chiave pubblica non è impostata, non è possibile eseguire "Sign and Save CSR", ma è possibile caricare DN ed estensioni da una CSR esistente o dalla cosiddetta TBS CSR.
TBS CSR è la nostra richiesta interna in formato di record, la cosiddetta richiesta "To Be Signed" che può fungere da modello per la creazione di richieste CSR con più funzionalità comuni. TBS CSR non contiene chiavi crittografiche ma memorizza solo DN ed estensioni.
Premendo il pulsante "Cancella voci" vengono rimossi tutti gli elementi nel DN e nell'estensione in modo che la finestra di dialogo sia preparata per la nuova voce.
Premendo il tasto "Firma e salva CSR", si firma la CSR nella scheda e la si memorizza nel file selezionato. Se la scheda non è nel campo del lettore uFR collegato o ha inserito il codice PIN utente errato, verrà visualizzato un messaggio di errore con la descrizione appropriata.
L'ultima cosa da fare dopo aver generato la CSR è inviarla all'emittente del certificato per ricevere il certificato X.509. È possibile scegliere uno qualsiasi degli emittenti di certificati commerciali o non commerciali o premendo il pulsante "Ottieni certificato online" è possibile inviare la CSR al nostro servizio web per ottenere un certificato dimostrativo e di prova rilasciato da "Digital Logic Ltd." Certificati di prova. La dimostrazione, un certificato di prova è destinato esclusivamente all'utilizzo di test e il suo periodo di validità è di 3 mesi. I certificati CA radice e intermedi di accompagnamento possono essere scaricati da http://ca.d-logic.com.
Se si fa clic sul pulsante "Ottieni certificato online" verrà richiesto un file CSR salvato in precedenza con estensione ".pem" che verrà inviato al server HTTP. In connessione con un server sul https://certificates.d-logic.com ha esito positivo e viene emesso il certificato X.509, verrà richiesto il nome del file per salvare il certificato. In caso contrario, verrà visualizzato un messaggio di errore appropriato.
X.509 Oggetti
Questa scheda ha lo scopo di gestire gli oggetti X.509, relativi ai certificati sulle carte firmatrici DL. Per leggere gli oggetti X.509 da una scheda, non è necessario accedere con nessuno dei codici PIN. Per modificare il contenuto della memoria per gli oggetti X.509 sulla scheda, è necessario aver effettuato l'accesso con il codice PIN SO nella pagina "Codici PIN".
Nella scheda "Oggetti X.509", l'applicazione tenta immediatamente di leggere la scheda presente nel campo del lettore uFR. Se nel campo non è presente alcuna scheda di firma DL, verrà visualizzato un messaggio di errore, come mostrato nell'immagine seguente:
Se l'archivio oggetti X.509 viene letto correttamente dalla scheda, gli elenchi di visualizzazione dei certificati verranno popolati con tale contenuto. È possibile aggiornare questi elenchi in qualsiasi momento posizionando la scheda desiderata nel campo del lettore e premendo il pulsante "Aggiorna oggetti dalla scheda".
La selezione del file del certificato X.509 viene effettuata premendo il tasto "apri file certificato". È anche possibile leggere certificati da file in formato PEM (codificato Base64), che di solito hanno l'estensione ".pem" o dai file binari scritti in standard ASN.1 (codificato DER), che possono avere estensioni ".crt", ".cer ", o ".der ". Se è selezionato un file valido, verrà visualizzata una finestra di dialogo di sistema che mostra il contenuto del certificato X.509 selezionato. Dopo aver controllato gli elementi del certificato, è sufficiente confermarlo premendo il pulsante "OK".
Per memorizzare il certificato selezionato in una scheda, è necessario immettere l'ID oggetto desiderato (stringa di caratteri alfanumerici arbitrari) che deve essere univoco per quanto riguarda altri certificati memorizzati sulla scheda. L'ID oggetto viene immesso nella casella di testo denominata "ID oggetti:". La proposta è che i certificati contenenti chiavi pubbliche RSA dovrebbero essere contrassegnati con un ID di es. "0001" a "0003" e quelli contenenti chiavi pubbliche ECDSA saranno contrassegnati con un ID di es. Da "1001" a "1003". I certificati CA devono anche avere un tag ID univoco sulla carta, quindi è consigliabile etichettarli con ad esempio da "5001" a "5012". È comunque necessario selezionare un tipo di chiave. Per i tipi RSA ed ECDSA, l'indice della chiave privata nella scheda è associato a tale certificato e tali indici devono essere coerenti. Per l'autorità di certificazione CA, l'ordine dell'indice non è rilevante, ma a causa della trasparenza per raccomandazione, dovrebbero essere inseriti in ordine, uno dopo l'altro in coppie, ad esempio, da radice a intermedio. Le applicazioni che supportano il modulo PKCS#11 e utilizzano certificati X.509, funzionano leggendo tutti gli oggetti pubblici dalla scheda e quindi controllando la catena di attendibilità in base al contenuto dei certificati stessi. Alla fine, è necessario premere il pulsante con un nome descrittivo "Inserisci il certificato da un file nella scheda con un ID designato, un tipo di oggetto e un indice".
Abbiamo menzionato le coppie radice e intermedia di certificati CA e potrebbe essere necessario chiarirlo ulteriormente. Qui abbiamo ipotizzato che il certificato dell'entità finale nella catena di attendibilità sia stabilito tramite il certificato CA intermedio a quello radice. Questo è il solito modo di formare una catena di fiducia da parte degli emittenti ufficiali del certificato. Tuttavia, questa non è una regola rigorosa e altre configurazioni sono possibili per modificare i certificati CA che formano una catena di attendibilità. È importante sottolineare che ci sono sempre due certificati finali, all'inizio della catena, il cosiddetto certificato CA root (root) e alla fine del certificato end-entity della catena (certificato foglia)
firma
Nella scheda "Firma" ci sono i comandi per ottenere firme digitali dalla carta. È possibile firmare un insieme di dati dalla riga di input etichettata "M:" (messaggio) o un file il cui percorso può essere impostato facendo clic sul pulsante di opzione "Imposta file da firmare". I dati possono essere inseriti in formato esadecimale (HEX), codificato Base64 o layout di codice ASCII.
Il formato esadecimale (HEX) include coppie di cifre esadecimali che possono essere separate da spazi. Il formato Base64 viene spesso utilizzato nella crittografia e nei record PEM dei certificati X.509. Qui non tratteremo il formato Base64 in dettaglio. Il layout del codice ASCII è uno standard comunemente usato per la registrazione di set di dati testuali che includono tutti i caratteri alfanumerici e tutta la punteggiatura standard. In linea di principio, tutto ciò che può essere inserito attraverso la tastiera standard inglese degli Stati Uniti è coperto dal layout del codice ASCII. Se per caso vengono inseriti caratteri che non fanno parte del layout del codice ASCII e questa opzione è selezionata, questi caratteri verranno sostituiti internamente dal carattere '?'. I caratteri che non fanno parte del layout del codice ASCII possono essere inseriti tramite alcune tastiere localizzate o selezionando l'opzione "incolla" dal menu di scelta rapida della casella di testo "M:".
Quando alcuni dati vengono inseriti nella linea di input, la conversione in un altro tipo di record viene eseguita semplicemente selezionando il formato di record desiderato (opzioni HEX / Base64 / ASCII) tranne quando si verifica un errore di input.
Facendo clic sul pulsante di opzione "Imposta file da firmare" si apre una finestra di dialogo di selezione dei file standard per il sistema operativo Windows. Quando il file è selezionato, il suo percorso viene impostato sulla casella di testo "M:".
Premendo il pulsante "Salva messaggio in file binario", viene abilitato a memorizzare una matrice di byte immessi nella casella di testo "M:" nel file binario.
Selezionando il pulsante "Ottieni firma", i dati da firmare passano attraverso l'algoritmo hash selezionato (Message digest algorithm) il cui risultato viene inviato alla scheda. La scheda genera quindi una firma basata sull'algoritmo crittografico selezionato dalla casella combinata "Algoritmo di cifratura" (RSA o ECDSA) e l'indice della chiave nella scheda (casella combinata "Indice chiave nella scheda"). Per firmare la carta, è necessario essere loggati con il codice PIN dell'utente in anticipo.
Dopo aver firmato correttamente, il valore della firma digitale viene visualizzato nella casella di testo "Firma" in formato HEX o Base64, a seconda dell'opzione selezionata. Modificando la selezione HEX / Base64, è possibile convertire la visualizzazione della firma. La firma può essere salvata nel file binario premendo il pulsante "Salva firma in file binario".
È stato inoltre implementato il calcolo facoltativo del valore hash della firma digitale. La scelta degli algoritmi hash per questo scopo include anche l'obsoleto algoritmo MD5 per ragioni storiche, poiché alcuni vecchi sistemi crittografici dipendono ancora da questo meccanismo. Il valore hash di una firma digitale può essere memorizzato in un file binario premendo il pulsante "Salva hash su file".
We use cookies on our website to give you the most relevant experience by remembering your preferences and repeat visits. By clicking “Accept”, you consent to the use of ALL the cookies.
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
