Digital signing source code software for µFR Series NFC RFID contactless readers
Semnarea digitală este viitorul afacerilor online, fie că vorbim despre semnarea simplă a documentelor, a codului și a e-mailurilor sau despre o implementare criptografică mai avansată, așa cum vedem în prezent în criptomonede și blockchain-uri.
Digital Logic Ltd. este una dintre primele companii din lume care implementează soluții de semnare digitală cu carduri RFID contactless.
Ne așteptăm ca sistemele vechi care încă mai folosesc cărți de vizită să devină în curând un lucru al trecutului.
Software-ul μFR Signer acceptă atât algoritmi criptografici RSA, cât și ECDSA pentru semnarea digitală a fișierelor.
Software-ul este destinat să fie utilizat cu seria noastră μFR de dispozitive NFC: Nano, Classic, Classic CS și Advance.
μFR Signer funcționează cu toate cardurile care acceptă RSA și ECDSA. În videoclipul nostru demonstrativ, am folosit placa JCOP J3D081.
Cardurile DL Signer asigură semnarea digitală a datelor și documentelor din cardurile propriu-zise folosind algoritmi criptografici asimetrici RSA sau ECDSA. Infrastructura PKI este acceptată și în cardurile DL Signer, este posibil să stocați certificate X.509 care sunt legate de perechi de chei criptografice generate în cardurile în sine. Este acceptat pentru a stoca toate certificatele X.509 care alcătuiesc lanțul de încredere de la certificatul rădăcină la certificatul de entitate finală.
Cheia publică generată în cardurile DL Signer este plasată în corpul solicitării în timp ce se creează cerința de semnare a certificatului (denumită în continuare CSR). Solicitarea este semnată pe cardul propriu-zis cu o cheie privată corespunzătoare care nu părăsește niciodată cardul în sine și în niciun caz nu poate fi citită după generarea perechilor de chei. Mai mult, CSR-ul este trimis organismului de certificare pentru a crea și semna certificatul X.509 pe baza acestuia. Acest certificat de entitate finală este plasat în cardul DL Signer cu alte certificate din lanțul de încredere și este gata să semneze digital date și documente. Utilizatorul poate trimite CSR la orice organism de certificare ale cărui servicii dorește să le utilizeze. Digital Logic a furnizat un mecanism de emitere a certificatelor de entitate finală pentru a testa sistemul. Una dintre caracteristicile de bază ale certificatului de entitate finală este că cheia privată, care este asociată cu cheia publică pe care o conțin astfel de certificate, nu trebuie utilizată pentru a semna alte certificate.
Instrumentele software Windows care inițiază generarea de perechi de chei criptografice, generează RSC, gestionează codurile PIN și PUK ale cardurilor DL Signer, manipulează conținutul certificatelor X.509 și semnează datele și fișierele, sunt distribuite ca "ufr-signer".
"Verificator de semnături" este o aplicație Windows care validează semnăturile digitale RSA și ECDSA.
Semnarea digitală și validarea semnăturilor se pot face și din aplicația Adobe Acrobat Reader DC folosind modulul ufr-pkcs11 pe care l-am dezvoltat în acest scop. Modulul nostru PKCS #11 poate fi, de asemenea, utilizat cu popularul client de e-mail mozilla și browser-ul web, precum și cu alte instrumente software care sunt compatibile cu specificațiile PKCS #11.
De asemenea, am oferit servicii web pentru verificarea online a certificatelor X.509 și a fișierelor pdf semnate.
Semnatar uFR
"uFR Signer" este un instrument software care inițiază generarea perechilor de chei criptografice, generează solicitări CSR, servește la gestionarea codurilor PIN și PUK ale cardurilor DL Signer, manipulează conținutul certificatelor X.509 și semnează datele și fișierele.
Aplicația este împărțită în mai multe unități logice folosind o componentă vizuală de control al filelor. Filele sunt etichetate după numele acestor unități:
"Cheile RSA" și "Cheile CE" sunt utilizate pentru a crea și manipula perechi de chei RSA sau ECC.
RSA (Rivest, Shamir, & Adleman) și ECC (Elliptic Cryptography) reprezintă algoritmi criptografici asimetrici contemporani. Cardurile DL Signer acceptă stocarea separată a 3 chei RSA și 3 ECC. Fiecare dintre cheile criptografice poate avea lungimi și caracteristici diferite și este indicată de un algoritm criptografic și de un indice cheie.
Fila "Coduri PIN" se referă la gestionarea și înregistrarea în jurnal a codului PIN de utilizator pe cardul DL Signer situat în câmpul cititor uFR. CODUL PIN este o abreviere a "Numărului personal de identificare". În plus față de codurile PIN, în această filă, puteți debloca, de asemenea, cardurile blocate în cele din urmă folosind coduri PUK. PUK înseamnă "PIN Unlock Key".
Fila "Obiecte card" este utilizată pentru a gestiona certificatele CA și certificatele de entitate finală care sunt asociate cu cheile criptografice respective prin indexurile lor. Certificatele trebuie să fie sub X.509 versiunea 3. Acreditările de entitate finală trebuie să conțină o cheie publică generată inițial în cardul DL Signer în perechi cu cheia privată asociată. Scopul principal al certificatului este de a fi utilizat cu pregătirea pentru semnare prin modulul PKCS#11. Prezența certificatelor X.509 nu este obligatorie pentru utilizarea cardului DL Signer cu aplicațiile proprietare.
În fila "Semnătură" există opțiuni pentru crearea semnăturilor digitale. Este posibil să semnați o matrice de octeți, o intrare de text sau un fișier. Aceste semnături pot fi verificate folosind aplicația "verificator de semnătură".
Pentru a rezolva problemele de performanță în mod eficient, dl signer carduri sunt concepute pentru a semna blocuri de date cât mai concis posibil. Prin urmare, este o practică să semnați digital datele cu un algoritm RSA, așa cum este definit de schema PKCS #1 v1.5. Pentru algoritmul ECDSA, procedura de generare a semnăturilor digitale, mecanismele de umplutură și aliniere sunt definite în RFC 6979.
Cea mai recentă versiune a aplicației uFRSigner este 1.5.3.0 și este necesar să se utilizeze biblioteca uFCoder versiunea 5.0.1 sau mai recentă și versiunea de firmware uFR 5.0.7 sau mai mare.
Coduri PIN
Codul PIN este o abreviere a "Numărului personal de identificare". Cardul dl signer conține 2 coduri PIN diferite. Acestea sunt SO (Security Officer) PIN și codul PIN de utilizator. Așa-numitul "Ofițer de securitate" este un utilizator care are privilegii administrative pentru accesarea obiectelor de securitate de pe cardul dl signer. Deci, codul PIN ar trebui să fie diferit de codul PIN al utilizatorului.
"Agentul de securitate" trebuie să fie conectat pentru a accesa cardul în cazurile în care este necesar să se modifice codurile PIN și PUK și să se modifice conținutul spațiului de stocare pentru chei și certificate. Conectarea cu un cod PIN de utilizator este necesară pentru a obține semnătura digitală a unui șir de date hashed.
Codurile PIN de pe cardurile dl signer pot avea un minim de 4 caractere și un maxim de 8 caractere. Aici, sub caracter, există orice alfanumerical (sensibil la litere mari) sau orice caracter imprimabil. Caracterele imprimabile se referă în principal la semnele de punctuație de pe tastaturile standard. La modificarea codurilor PIN, nu se recomandă utilizarea caracterelor specifice care pot fi găsite numai pe tastaturile localizate individuale, ci numai a caracterelor care sunt în standardul ASCII și care există pe tastaturile standard în limba engleză din SUA.
În toate cardurile dl signer, pin-ul implicit și codurile PIN de utilizator sunt setate inițial, constând din opt caractere numerice consecutive "0" (zero) sau "00000000".
Numărul maxim de cod PIN consecutiv incorect introdus este 5. Dacă numărul de încercări succesive incorecte de a introduce codul PIN este depășit, acel cod PIN este blocat. Deși codul PIN nu este blocat, introducerea codului PIN corect resetează contorul codurilor PIN introduse incorect.
Singura modalitate de a debloca codul PIN este să introduceți codul PUK corect. PUK este abrevierea "PIN Unlock Key". Deci, codul PUK servește exclusiv pentru a debloca codul PIN SO și PUK utilizator pentru a debloca codul PIN al utilizatorului. În cazul a 10 coduri PUK introduse incorect consecutive, codul PUK devine inutilizabil, iar funcționalitatea cardului pe care se referă codul PIN blocat rămâne blocată pentru totdeauna.
Cheile RSA
În fila "Chei RSA" există opțiuni pentru crearea și gestionarea cheilor RSA. Înainte de a lucra cu cheile RSA, dl Signer Card trebuie să fie în câmpul cititor uFR care este conectat la computerul care execută aplicația ufr-signer. De asemenea, SO (ofițer de securitate) trebuie să fie conectat.
Cheile CE
În fila "Chei CE" există opțiuni pentru crearea și gestionarea cheii CE. Înainte de a lucra cu tastele CE, dl Signer Card trebuie să fie în câmpul cititor uFR care este conectat la computerul care execută aplicația ufr-signer. De asemenea, SO (ofițer de securitate) trebuie să fie conectat.
Generarea cererii de semnare a certificatelor (CSR)
Acesta este definit de standardul PKCS#10 și reprezintă o înregistrare standardizată care, printre altele, conține informații de bază despre utilizatorul certificatului în numele distinctiv. Pe baza numelui caracteristic, așa-numitul Subiect (câmp subiect) se formează în certificatul final X.509. În plus, înregistrările CSR pot conține, de asemenea, extensii specificate de standardul X.509 pe care autoritatea de certificare (CA) le poate lua în considerare sau le poate elimina, în funcție de politica sa de certificare. Partea de bază a RSI este cu siguranță o cheie publică și parametrii săi. Toate aceste date, ambalate în forma definită de standardul PKCS#10, sunt în cele din urmă trecute prin algoritmul de digerare criptografică corespunzător, iar rezultatul este semnat în card cu cheia privată corespunzătoare. Semnătura digitală astfel achiziționată devine parte integrantă a RSI.
CSR-ul este trimis emitentului dorit al certificatului, care reprezintă așa-numita autoritate de certificare (CA). Emitentul certificatului va genera certificatul de entitate finală X.509, care este semnat de cheia privată respectivă, acum asociată cu cheia publică conținută în certificatul CA intermediar sau rădăcină corespunzător. În acest fel, certificatul de entitate finală devine parte a lanțului de încredere garantat de autoritatea de certificare (CA).
"Cerere de semnare certificat (CSR)" un dialog este un grup separat pentru introducerea "Nume distinctiv (DN)", "Extensii" și în partea dreaptă sus a grupurilor de casete combo, pentru controlul algoritmului hash și definirea cheii criptografice. Mai jos dreapta este un grup de butoane pentru alegerea activităților legate de generarea DE CSR.
Un nume distinctiv, denumit DN, constă dintr-un grup de nume distinctiv relativ (RDN) reprezentând grupul de atribute. La definirea unui DN, ordinea câmpului RDN este foarte importantă. Este important să rețineți că este posibil să repetați un singur câmp RDN de mai multe ori în DN. Trebuie amintit faptul că autoritatea de certificare (CA) nu este obligată să elibereze un certificat cu același DN definit în RSI, dar DN se poate forma pe baza propriilor reguli și date obținute în timpul verificării identității utilizatorului implementate anterior.
Formarea DN-ului se face selectând RDN-ul corespunzător din caseta combo și tastând valoarea dorită în caseta text. Prin apăsarea butonului "Put", RDN-ul declarat va fi plasat pe lista (Caseta listă) care definește DN. Dacă unul dintre câmpurile RDN a fost selectat în listă, noul RDN va fi introdus între câmpul selectat și câmpul anterior. Dacă nu este selectat nimic în lista DN, se inserează un nou câmp RDN la sfârșitul listei. Pentru a anula selecția din listă, apăsați butonul "Deselectare". RDN incorecte pot fi eliminate din listă apăsând "Elimina". Ordinea câmpului RDN poate fi modificată utilizând butoanele "Mutare în sus" și "Mutare în jos" care afectează redundanța RDN-ului selectat din listă.
Extensiile sunt o parte opțională a RSI, iar Autoritatea de Certificare (CA) le poate lua în considerare sau respinge, în funcție de politica lor de certificare. Este posibil să se atribuie mai multe atribute și este de dorit să se definească o adresă de e-mail în cadrul subiectului alternativ al subiectului (nume alternativ subiect, abreviat subjectAltName), deoarece acesta este cel mai comun emitent de certificat în locul obișnuit în acest scop. Pentru extensii, ordinea atributelor individuale nu este importantă. Se preconizează că scopul dorit al cheilor, scopul extins al cheilor și declarațiile referitoare la certificatele calificate pot fi încă definite. Încă o dată, trebuie subliniat faptul că emitenții certificatului pot ignora extensiile și numai unii dintre ei pot emite așa-numitele certificate electronice calificate. În orice caz, în cadrul extensiilor, utilizatorul poate indica elementele dorite ale viitorului certificat, dar, încă o dată, eliminarea finală a certificatului X.509 depinde exclusiv de emitentul său și că toate detaliile trebuie să fie pe deplin familiarizate cu politicile lor înainte de încheierea contractului de emitere.
Alegerea algoritmului hash se face din caseta combo marcată cu "algoritmul de digerare a semnatarului". Alegerea implicită este SHA-256, care se referă la algoritmul SHA2 care are 256 de biți la ieșire sau 32 de octeți și acest lucru este recomandat să se utilizeze pentru CSR. SHA1 nu mai este recomandat, iar SHA2 cu un număr mai mare de octeți la ieșire (384 și 512), iar algoritmul SHA3 este planificat pentru o utilizare mai frecventă în viitor.
Cheile și parametrii lor ("algoritmul de cifru al semnatarului" și "indexul cheii semnatarului (card)") nu pot fi modificate aici și există deja definite pe fila din care ați deschis acest dialog ("Chei RSA" sau "Chei CE"), iar scopul lor aici este doar informativ. Dacă "Cheile RSA" sau "Cheile CE" din care ați deschis dialogul CSR, nu a existat nicio cheie publică corespunzătoare, citită anterior de pe card, pe eticheta care indică dimensiunea cheii RSA, Curba ECDSA va fi indicată ca "Cheia publică nu este setată". Atunci când o cheie publică nu este setată, nu este posibil să executați "Semnați și salvați CSR", dar este posibil să încărcați DN și extensii dintr-un CSR existent sau așa-numitul TBS CSR.
TBS CSR este formatul nostru intern de înregistrare așa-numita solicitare "Pentru a fi semnat", care poate servi ca șablon pentru crearea solicitărilor CSR cu mai multe caracteristici comune. TBS CSR nu conține chei criptografice, ci stochează doar DN și extensii.
Apăsarea butonului "Ștergeți intrările" elimină toate elementele din DN și extensia, astfel încât dialogul să fie pregătit pentru noua intrare.
Apăsând tasta "Semnați și salvați CSR", semnarea CSR-ului în card și stocarea acestuia în fișierul selectat se face. Dacă cardul nu se află în câmpul cititorului uFR conectat sau a introdus codul PIN de utilizator greșit, veți primi un mesaj de eroare cu descrierea corespunzătoare.
Ultimul lucru pe care trebuie să-l faceți după generarea CSR-ului este să îl trimiteți emitentului certificatului pentru a primi certificatul X.509. Puteți alege oricare dintre emitenții de certificate comerciale sau necomerciale sau apăsând butonul "Obțineți certificatul online" puteți trimite CSR-ul la serviciul nostru web pentru a obține o demonstrație, certificat de testare emis de "Digital Logic Ltd." Certificate de testare. Demonstrația, un certificat de testare este destinat exclusiv utilizării testului, iar perioada de valabilitate a acestuia este de 3 luni. Certificatele rădăcină și CA intermediare de însoțire pe care le puteți descărca de pe http://ca.d-logic.com.
Dacă faceți clic pe butonul "Obțineți certificatul online", vi se va solicita un fișier CSR salvat anterior cu o extensie ".pem" care va fi trimisă la serverul HTTP. În legătură cu un server de pe https://certificates.d-logic.com are succes și se eliberează certificatul X.509, vi se va solicita ca numele fișierului să salveze certificatul. În caz contrar, veți primi un mesaj de eroare corespunzător.
X.509 Obiecte
Această filă este destinată pentru a gestiona obiectele X.509, legate de certificatele de pe dl signer carduri. Pentru a citi obiectele X.509 de pe un card, nu este necesar să fiți conectat cu oricare dintre codurile PIN. Pentru a modifica conținutul spațiului de stocare pentru obiectele X.509 de pe card, trebuie să fiți conectat cu codul SO PIN pe pagina "Coduri PIN".
În fila "X.509 Obiecte", aplicația încearcă imediat să citească cardul care este prezent în câmpul cititorului uFR. Dacă nu există nici un dl Signer Card este în câmp, un mesaj de eroare va apărea, așa cum se arată în imaginea de mai jos:
Dacă stocarea obiectelor X.509 este citită cu succes de pe card, listele de afișare a certificatelor vor fi populate cu acel conținut. Puteți reîmprospăta aceste liste în orice moment, plasând cardul dorit în câmpul cititorului și apăsând butonul "Reîmprospătați obiectele de pe card".
Selectarea fișierului certificat X.509 se face apăsând tasta "deschideți fișierul certificat". De asemenea, este posibil să citiți certificate din fișiere în format PEM (codate Base64), care de obicei au extensia ".pem" sau din fișierele binare scrise în standardul ASN.1 (codate DER), care pot avea extensii ".crt", ".cer ", sau ".der ". Dacă este selectat un fișier valid, se va afișa un dialog de sistem care afișează conținutul certificatului X.509 selectat. După verificarea elementelor certificatului, este suficient să confirmați acest lucru apăsând butonul "OK".
Pentru a stoca certificatul selectat într-un card, trebuie să introduceți ID-ul obiectului dorit (șir de caractere alfanumerice arbitrare) care trebuie să fie unic în ceea ce privește alte certificate care sunt stocate pe card. ID-ul obiectului este introdus în caseta text etichetată "Id obiecte:". Propunerea este ca certificatele care conțin chei publice RSA să fie marcate cu un act de identitate de exemplu. "0001" la "0003", iar cele care conțin chei publice ECDSA vor fi marcate cu un act de identitate de exemplu. "1001" la "1003". Certificatele CA trebuie să aibă, de asemenea, o etichetă de identificare unică pe card, deci este o sugestie să le etichetați cu, de exemplu, "5001" la "5012". Este încă necesar să selectați un tip de cheie. Pentru tipul RSA și ECDSA, indicele cheii private din card este legat de certificatul respectiv, iar acești indici trebuie să fie consecvenți. Pentru autoritatea de certificare CA, ordinea indicelui nu este relevantă, dar datorită transparenței prin recomandare, acestea ar trebui introduse în ordine, una după alta în perechi, de exemplu, de la rădăcină la intermediar. Aplicațiile care acceptă modulul PKCS#11 și utilizează certificate X.509, funcționează citind toate obiectele publice de pe card și apoi verificând lanțul de încredere pe baza conținutului certificatelor în sine. În cele din urmă, trebuie să apăsați butonul cu un nume descriptiv "Puneți certificatul dintr-un fișier în card cu un id desemnat, un tip de obiect și un index".
Am menționat perechile rădăcină și intermediare de certificate CA și poate fi necesar să se clarifice în continuare acest lucru. Aici am presupus că certificatul de entitate finală în lanțul de încredere este stabilit prin intermediar la certificatul CA rădăcină. Acesta este modul obișnuit de a forma un lanț de încredere de către emitenții oficiali ai certificatului. Cu toate acestea, aceasta nu este o regulă strictă și alte configurații sunt posibile pentru a modifica certificatele CA care formează un lanț de încredere. Este important să subliniem că există întotdeauna două certificate finale, la începutul lanțului, așa-numitul certificat CA rădăcină (rădăcină) și la sfârșitul certificatului de entitate finală a lanțului (certificat de frunze)
Semnătura
În fila "Semnătură" există comenzi pentru obținerea semnăturilor digitale de pe card. Un set de date din linia de intrare etichetată "M:" (mesaj) sau un fișier a cărui cale poate fi setată făcând clic pe butonul radio "Setați fișierul să semneze" poate fi semnat. Datele pot fi introduse în format hexazecimal (HEX), codat Base64 sau aspect de cod ASCII.
Formatul hexazecimal (HEX) include perechi de cifre hexazecimale care pot fi separate prin spații. Formatul Base64 este adesea folosit în criptografia și înregistrările PEM ale certificatelor X.509. Aici nu ne vom ocupa de formatul Base64 în detaliu. Aspectul de cod ASCII este un standard utilizat în mod obișnuit pentru înregistrarea seturilor de date textuale care includ toate caracterele alfanumerice, precum și toate semnele de punctuație standard. În principiu, tot ceea ce poate fi introdus prin tastatura standard în limba engleză din SUA este acoperit de aspectul de cod ASCII. Dacă, din întâmplare, sunt introduse caractere care nu fac parte din aspectul codului ASCII și această opțiune este selectată, aceste caractere vor fi înlocuite intern cu caracterul '?'. Caracterele care nu fac parte din aspectul codului ASCII pot fi introduse prin intermediul unor tastaturi localizate sau selectând opțiunea "lipire" din meniul contextual al casetei text "M:".
Când unele date sunt introduse în linia de intrare, conversia la un alt tip de înregistrare se face prin simpla selectare a formatului de înregistrare dorit (opțiuni HEX / Base64 / ASCII), cu excepția cazului în care există o eroare de intrare.
Făcând clic pe butonul radio "Setați fișierul să semneze" se deschide un dialog de selecție a fișierelor care este standard pentru sistemul de operare Windows. Când fișierul este selectat, calea sa este setată la caseta text "M:".
Apăsând butonul "Salvați mesajul în fișierul binar", este activat să stocați o serie de octeți introduși în caseta text "M:" în fișierul binar.
Selectând "Obțineți semnătura", pentru a fi semnate, datele trec prin algoritmul hash selectat (algoritmul Message digest) al cărui rezultat este trimis pe card. Cardul generează apoi o semnătură bazată pe algoritmul criptografic selectat din caseta combo "Algoritm de cifru" (RSA sau ECDSA) și indexul cheie din card ("Index cheie în card"). Pentru a semna cardul, este necesar să fiți conectat în prealabil cu codul PIN de utilizator.
După semnarea cu succes, valoarea semnăturii digitale este afișată în caseta text "Semnătură" în format HEX sau Base64, în funcție de opțiunea selectată. Prin schimbarea selecției HEX / Base64, este posibil să convertiți afișarea semnăturii. Semnătura poate fi salvată în fișierul binar apăsând butonul "Salvați semnătura în fișierul binar".
Opțional, a fost implementată și calcularea valorii hash a semnăturii digitale. Alegerea algoritmilor hash în acest scop include, de asemenea, algoritmul MD5 învechit din motive istorice, deoarece unele sisteme criptografice vechi încă depind de acest mecanism. Valoarea hash a unei semnături digitale poate fi stocată într-un fișier binar apăsând butonul "Salvați hash-ul în fișier".
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.
