RO127992A0 - Soluţie generică de conectare la dispozitive de criptare digitală - Google Patents

Soluţie generică de conectare la dispozitive de criptare digitală Download PDF

Info

Publication number
RO127992A0
RO127992A0 ROA201200424A RO201200424A RO127992A0 RO 127992 A0 RO127992 A0 RO 127992A0 RO A201200424 A ROA201200424 A RO A201200424A RO 201200424 A RO201200424 A RO 201200424A RO 127992 A0 RO127992 A0 RO 127992A0
Authority
RO
Romania
Prior art keywords
application
certificate
certificates
client
authority
Prior art date
Application number
ROA201200424A
Other languages
English (en)
Inventor
Iulian Vasile Popescu
Original Assignee
Isign Solftware Srl
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Isign Solftware Srl filed Critical Isign Solftware Srl
Priority to ROA201200424A priority Critical patent/RO127992A0/ro
Publication of RO127992A0 publication Critical patent/RO127992A0/ro

Links

Landscapes

  • Storage Device Security (AREA)

Abstract

Invenţia se referă la o aplicaţie capabilă să se conecteze la orice tip de dispozitiv de criptare, astfel încât să se realizeze emiterea certificatelor digitale sau marcarea temporală a documentelor. Aplicaţia conform invenţiei comunică cu un computer specializat în activităţi criptografice () (Hardware Security Module) pe care sunt stocate certificate şi chei private ale unei autorităţi de certificare, aplicaţia de certificare () (Certification Authority) solicită computerului specializat () semnarea certificatelor numai atunci când acestea sunt validate de către un operator al autorităţii, iar pentru servicii de marcare temporală, după salvarea cererii venite din partea unui client, aplicaţia () creează un pachet de marcare temporal, pe care îl va trimite la semnare computerului specializat () de care se conectează.

Description

Titlul invenției:
Soluție generică de conectare la dispozitive de criptare digitală
Domeniul tehnic la care se referă invenția: tehnologia informației
1. Scopul documentului
Acest document descrie din punct de vedere funcțional și tehnic modul de conectare la un dispozitiv criptografic, cu utilizarea sa cea mai uzuală și anume semnătura electronică și marcarea temporală.
2. Prezentarea procesului (vezi figura 2.1 de la „DESENE”)
Obținerea unui certificat digital calificat se face în mai multe etape, fiecare etapă având un rol bine determinat și desfașurându-se sub responsabilitatea solicitantului, al AI (Autorității de înregistrare), sau al AC (Autorității de certificare). Fiecare etapă din cele prezentate mai sus, se desfășoară la rândul său pe mai mulți pași.
2.1 înregistrare solicitant înregistrare solicitant este punctul de intrare în sistem și are rolul de a înregistra o cerere de emitere de certificat calificat. în această etapă se primesc două categorii de informații: informații online legate de solicitant și de certificatul dorit și documentele necesare emiterii certificatului calificat.
Un utilizator trebuie să prezinte AI, următoarele documente:
Page 2 of 20 x- 2 0 1 2 - 0 0 4 2 4 - t 3 -06- 2012
a) act de identitate (carte de identitate, buletin, pașaport,
CUI pentru societăți comerciale)
b) declarație pe proprie răspundere prin care solicitantul își expirmă acordul cu condițiile generale ale ISIGN SOFTWARE privind furnizarea serviciilor de certificare. Formularul acestei declarații se poate descărca de pe site-ul ISIGN SOFTWARE:
c) în cazul certificatelor emise pentru instituții, este necesară și o împuternicire sau dovadă că solicitantul are dreptul de a semna în numele instituției.
Autoritatea de înregistrare are obligația de a face copii după documentele originale primite de la solicitant și le va păstra pe baza metodologiei de arhivare a informațiilor personale. Aceste metodologii sunt definite în cadrul procedurilor interne de protecție a informațiilor cu caracter personal.
în cadrul formularului web sunt cerute, în mai mulți pași, informații legate de solicitant, instituția pe care o reprezintă și despre certificat.
Pas 1: se introduce CNP-ul clientului, sau pentru persoanele care nu sunt cetățeni români, se introduce codul unic de identificare similar. în funcție de acest cod, sistemul va verifica dacă clientul mai este deja în baza de date, sau este un client nou. în funcție de acestă verificare, se va trece la pasul următor.
Pas 2: dacă clientul este un utilizator nou al serviciilor de certificare, atunci în acest pas va trebui să completeze toate datele personale ( nume, prenume, adresă, serie și număr act de identitate, alte c v- 2 0 1 2 - 0 0 4 2 4 - 1 3 -06- 2012
Page 3 of 20 informații de contact etc ). în cazul în care clientul este deja în baza de date, atunci acestuia i se va cere, doar să actualizeze aceste câmpuri, dacă este cazul.
Pas 3: se introduc informațiile legate de certificatul ce se dorește a fi emis: adresa de email, instituția, funcția și opțional localitatea și adresa clientului. Tot în acest pas, prin intermediul unui applet Java semnat, se accesează DCSC-ul (Dispozitiv securizat de creare a semnăturii electronice), care bineînțeles trebuie să fie conectat la calculator. DSCSul va genera o pereche de chei care vor fi legate de certificatul ce va fi emis. Cheia publică este împachetată într-un obiect PKCS#10 și este trimisă odată cu celelalte informații, către server-ul autorității de certificare, unde sunt stocate în baza de date.
Un client nu poate să aibă mai mult de un certificat valid pe aceeași adresă de email. După ce aceste informații sunt completate utilizatorul va fi înștințat că o să primească un email cu răspunsul pozitiv sau negativ al validării datelor.
2.2 Validare date
Un responsabil cu validarea solicitărilor de certificare, din partea ISIGN SOFTWARE, va trebui să verifice dacă informațiile venite prin formularul web, coincid cu realitatea (documentele primite de către AI). Drepturile de validare a cererilor de certificate sunt date de către responsabilul cu gestiunea autorității de certificare, care poate să creeze conturi noi, să dezactiveze pe cele deja existente, sau să modifice drepturile de acces ale acestora.
t<2 0 1 2 - 0 0 4 2 4 - t 3 -06- 2012
Page 4 of 20
Există mai multe tipuri de drepturi pe care un operator le poate avea în sistem: de înregistrare, de revocare, de validare și de administrare operatori.
Dreptul de administrare a operatorilor îl are doar responsabilul cu gestiunea autorității de certificare.
Ca rezultat al etapei de validare, operatorul responsabil, va trebui să accepte sau să refuze cererea de certificare din partea solicitantului. în cazul unui răspuns negativ, operatorul va trebui să precizeze și cauza refuzului.
în ambele cazuri, solicitantul va primi pe email răspunsul cererii de A certificare. In cazul unui răspuns pozitiv în email va fi trecută și o adresă URL, de unde se poate descărca certificatul calificat pe un dispozitiv DSCS (Dispozitiv securizat de creare a semnăturii electronice).
2.3 Descărcare certificat
Dacă cererea de certificare a fost validată, atunci solicitantul va primi un mail de confirmare, unde va găsi și adresa web de unde va putea să descarce acest certificat Descărcarea și revocarea unui certificat se fac numai pe baza unei parole asociate la certificat. Această parolă a fost introdusă, odată cu informațiile legate de certificat, în etapa de înregistrare.
Descărcarea certificatului se poate face numai pe DCSC-ul care a fost folosit și în etapa de înregistrare, deoarece, certificatul conține cheia publică a solicitantului, cheie verificată și la descărcarea certificatului pe dispozitiv.
¢-2012-00424--
Page 5 of 20
Conform standardului PKCS#11, dispozitivul securizat este împărțit în „entry-uri”, unde se țin cheia publică, cheia privată și certificatul.
Acest lucru permite, unui utilizator, stocarea mai multor certificate pe un asemenea dispozitiv.
Pentru a permite lucrul cu mai multe certificate pe același dispozitiv, aplicația autorității de certificare, va salva, în etapa de înregistrare, numele intrării nou create, odată cu perechea de chei.
Numele noii intrări a DSCS-ului este un număr unic, calculat în funcție de momentul de timp în care se face înregistrarea. Acest nume este transmis, odată cu toate informațiile solicitantului, către AC, și va fi folosit de către aplicația de certificare, în etapa de descărcare a certificatului, pentru a știi exact unde să fie scris certificatul (în care din intrările DSCS-ului).
Descărcarea certifcatului de pe serverul autorității de certificare și scrierea lui pe DSCS se face cu ajutorul unui applet Java semnat, care are acces la resursele locale și care poate să comunice cu dispozitivul de securitate. Acesta este același applet folosit la etapa de înregistrare, dar care are două funcții diferite în funcție de parametri de intrare dați.
3. Preambul în proiectarea sistemului de emitere a certificatelor calificate s-a ținut cont de doi factori foarte importanți: securitatea sistemului, dar și ușurința și fiabilitatea în exploatare. Sunt de remarcat câteva din metodele, care combină cei doi factori menționați mai sus: parola de acces pe certificat, sistemul de comunicare prin email și metodele de
Page 6 of 20
C\-2 0 1 2 - 0 0 4 2 4 - - V?7 f 3 -06- 2012 protecție implementate la descărcarea certificatului pe un dispozitiv securizat.
Datorită utilizării unui applet Java pentru comunicarea cu DSCSul, va trebui ca pe mașina, pe care se execută etapele de înregistrare și de descărcare a certificatului, să fie instalată o mașină virtuală Java, cel puțin versiunea JRE 1.5. Acest lucru poate părea o limitare, dar pe de altă parte permite rularea și sub browsere de intemet din altă familie decât Intemet Explorer, ca în cazul tehnologiei ActiveX.
Orice browser de intemet ar fi folosit, trebuie să fie configurat pentru a permite rularea appleturilor Java semnate digital.
4. Descrierea sistemului informatic
4.1. Introducere
Acest document descrie un sistem de certificare generic folosit de către o autoritate de certificare.
4.2. Infrastructura (vezi figura 4.1 de la „DESENE”)
4.2.1 Router
Routerul este un model LinkSys RV042, care permite două linii de intemet de intrare, una principală și ceea de-a doua de rezervă. Dacă intemetul cade pe linia principală, atunci router-ul comută automat pe ceea de-a doua linie.
Page 7 of 20 ? 1 ? - n ? 4 2 A 1 3 -iii- 2012
4.2.2 Firewall
Firewall-ul este o mașină care rulează sistemul de operare Linux, distribuția CentOS v6.2 și care este configurată să protejeze rețeaua autorității de certificare de accesul neautorizat din afară.
4.2.3 Intrusion Detection System (IDS)
Pentru a monitoriza eventualele încercări de penetrare a sistemului este instalat și un sistem de detecție a intruziunii, Intrusion Detection System (IDS).
Acesta este tot o mașină Linux, distribuția CentOS v6.2, pe care sunt instalare aplicațiile Snort și Acid. Logurile sunt vărsate și raportate dintr-o bază de date MySQL.
Toate logurile generate de IDS vor putea fi consultate de administratorul sistemului din interfață web.
4.2.4 ISSWeb
ISSWeb este un cluster format din două servere, care au rolul de a fi ține aplicația web de generare a certificatelor digitale. Aici este găzduit subdomeniul care conține toate paginile ce țin de Registrul autorității de certificare.
Cele 2 servere ISSWeb 1 și ISSWeb2 își fac automat mirroring folosind funcții din cadrul sistemului de operare Windows 2008 Server R2 Enterprise Edition.
Pe aceste servere rulează Apache Tomcat Application Server v5.5.20, care servește pagini web pe portul 443 (HTTPS). Acest server va servi atât paginile statice cât și cele cu conținut activ (Java Server Faces).
0 1 2 - 0 0 4 2 4 - ί 3 -06- 2012
Page 8 of20
4.2.5 ISSDB1
Pentru stocarea informațiilor legate de clienți și de certificate se folosește un o bază de date SQL, gestionată de un server SQL Server
2008 Standard Edition, instalat pe ISSDB1.
4.2.6 ISSDB2
Serverul ISSDB1 are și el un backup, pentru a respecta un nivel de redundanță ridicat. Baza de date SignTechCA de pe serverul ISSDB1 este replicată pe ISSDB2 în mod conținu. în cazul în care serverul ISSDB 1 are probleme, ISSDB2, nu numai că va putea să readucă datele din baza de date, dar poate să îi ia locul în mod activ, printr-o simplă comutare a dateleor de conectare la baza de date folosite de ISSWeb.
4.2.7 Hardware Security Module (HSM)
Hardaware Security Module (HSM), este un computer specializat în activități criptografice. Rolul HSM-ului este de a stoca cheile autorităților de certificare din cadrul ISS și de a semna toate certificatele care sunt emise clienților.
HSM-ul este produs de firma Algorithmic Research din Israel, iar modelul său este PrivateServer v4.
Comunicarea cu acest dispozitiv se face folosind stanradrul PKCS#11. Pentru aceasta serverul ISSCAServer comunica direct pe un cablu UTP dedicat, izolând astfel HSM-ul de restul rețelei, (vezi figura
4.2 Hardware Security Module de la „DESENE”) în tabelul de mai jos se găsesc specificațiile tehnice ale HSM-ul de la Algorithmic Research utilizat pentru testarea aplicației:
<-2 0 1 2 - 0 0 4 2 4 - 1 3 -06- 2012
Page 9 of 20
Caracteristică Valoare
Algoritm asimetric de criptare RSA (320-4096 bits)
Algoritm simetric de criptare DES, Triple-DES, AES
Standarde de securitate FIPS 140-1 Level 3 FIPS 140-2 level 3* FCC Subpart B Class B EN 55022 Class B for AC
Stocare sigură a cheilor Da
Conectivitate TCP/IP Ethemet LU6.2 Token Ring LU6.2 SDLC
API criptografic PKCS#11 MS CAPI JCA
Dimensiuni fizice W 48.3cm; D 44.7cm; H 17.8cm 6U Rack mountable Greutate: 15 KG
Moduri de autentificare Smart Cârd (Windows only) USB Token (Windows only) Software Key (Windows, Linux, HP, AIX and Solaris)
Performantă J 450 RSA Signatures pe secundă (1024 bit) 5500 Symmetric Transactions pe secundă
Funcții HASH SHA-1, SHA-256, SHA-512 ISO-Hashing ARDFP
0 1 2 - o o 4 2 Ă - 1 3 -06- 2012
Page 10 of 20
Management de la distanță Da
Sisteme de operare clienți MS Windows 2000, XP, 2003 Server Sun/ Solaris HP-UX, AIX, Linux OS/2 STRATUS/VOS Tandem MVSOS390
4.2.8 Domanin Controller
Pentru a asigura funcționarea serverelor ISSWeb în cluster și pentru o mai ușoară administrare s-a implementat un domeniu pentru autoritatea de certificare. Domeniul este isign.ro. Calculatorul de Domain Controller are numai această funcție.
5. Problema de rezolvat
Pentru a asigura funcționarea sistemului este necesară comunicarea cu dispozitivul Hardware Signing Module, producătorul acestuia nu oferă o soluție concretă, ci doar aplicații în baza cărora să se dezvolte software ajutător de către utilizatori, în funcție de platforma utilizată și tipul de utilizare indicat (HSM având mai multe utilizări potențiale, de exemplu, gestionarea PIN cârdurilor bancare).
în acest sens, este nevoie de o aplicație capabilă să se conecteze la orice tip de dispozitiv de criptare, pentru a nu mai fi dependent de platformă sau producător.
Pentru emiterea certificatelor digitale, aplicația va trebui sa comunice cu un HSM pe care sunt stocate certificatele si cheiele private ale autoritatii de certificare si subautoritatile sale. Aplicația de certificare, (X“ 2 0 1 2 - 0 0 4 2 4 - î 3 -06- 2012
Page 11 of 20 numita si CA (Certification Authority) va trebui sa ceara HSM-ului semnarea certificatelor numai atunci când acestea sunt validate de către un operator al autoritatii.
Pentru servicii de marcare temporală, după salvarea cererii venite din partea clientului, aplicația va crea un pachet de marcare temporal, pe care il va trimite la semnare HSM-umului de care se conectează.
Comunicația cu HSM-ul se realizează pe baza standardului PKCSflll.
6. Soluția
Soluția aleasă este una independentă de sistemul de operare, bazată pe Java care include pachete ce trebuiesc instalate neapărat pe sistemul local (necesită să existeța funcțională a unei mașini virtuale Java), acolo unde are loc accesul securizat la certificatele digitale.
Codul aplicației de conectare poate fi folosit de sine stătător, cu propria interfața grafică, sau integrat în alte aplicații, prin care se prelucrează datele care necesită fie semnarea digitală prin intermediul unui certificat digital, fie marcarea temporală pentru dovedirea datei certe de elaborare a documentelor. Totul este scris în Java, având avantajele rulării pe orice sistem de operare, existenței unor unelte performante pentru prelucrare XML-PDF și al securității lucrului cu certificate digitale.
Interfețele specifice criptografiei sunt bazate pe furnizori, permițând multiple implementări interoperabile. Unii furnizori pot efectua operații criptografice in software; alții pot realiza operații pe un token hardware (de exemplu pe dispozitive smartcard).
c\ -2 0 1 2 - 0 0 4 7 4 - 1 3 -06- 2012
Page 12 of 20
Platforma Java include furnizori predefmitipentru cei mai utilizați algoritmi criptografici, incluzând algoritmii RSA si DSA de semnătură, algoritmii de criptare DES, AES si ARCFOUR, si algoritmii de hash MD5 si SHA-1. Acești furnizori implementează algoritmii criptografici in cod Java. Infrastructura de chei publice (PKI) este un termen folosit pentru un framework care permite un schimb de informații securizat bazat pe arhitectura de chei publice (se folosesc algoritmi de chei asimetrice in locul sau laolalta cu algoritmii de chei simetrice). Permite persoanelor/organizatiilor sa utilizeze cetificatele digitale si oferă mijloace de verificare a autenticitatii certificatelor. Platforma Java incude suport pentru certificate digitale X.509 si pentru CRL-uri.
Clasele asociate cu PKI-urisunt localizate in pachetele java.security si j ava. security.cert.
Platforma Java permite o stocare persistentă a cheilor si a certificatelor via depozitelor de certificate si chei. Mai exact, clasa java.security.KeyStore reprezintă un depozit de chei, permițând stocarea cheilor criptografice si/sau a certificatelor digitale de tip trusted (pentru a fi utilizate ulterior in validarea cu ajutorul certificatelor), cat si clasa java.security.CertStore care reprezintă un depozit de certificate. Un CertStore poate stoca si certificate.
Furnizorul SunPKCSll include o implementare KeyStore PKCS11. Acest lucru inseamna ca certificatele si cheile păstrate intr-un hardware securizat (spre exemplu intr-un smartcard) pot fi accesate si utilizate de aplicațiile Java via API-ului KeyStore. Ca o observație cheile din smartcard-uri nu le este permis sa parasesca dispozitivul. In aceste cazuri obiectul java.security.Key retumat de API-ul KeyStore ar putea fi o simpla referința la cheie (acest lucru însemnând ca nu conține explicit
Page 13 of 20 ^-2012-00424-1 3 -06- 2012 cheia). Acest obiect de tip Key ar pute fi folosit numai pentru a realiza operații criptografice numai asupra dispozitivului unde este pastrata cheia.
Platforma Java include de asemenea un depozit de certificate de tip LDAP (pentru a accesa certificatele stocate intr-un director LDAP) cat si un depozit de certificate in-memory de tip Collection (pentru certificatele dintr-un obiect java.util.Collection).
Aplicația integrată posedă următoarele caracteristici:
a) Pentru partea de emitere certificate digfitale:
Aplicația de emitere a certificatelor calificate trebuie sa respecte normele legii semnăturii electronice 455/2001, normele de aplicare ale acesteia, precum si standardele referite de aceste documente:
CI: aplicația este pe o platforma web.
C2: aplicația permite înscrierea clientilor pentru obținerea de certificate calificate.
C3: păstrează un numenclator de client, identificarea unica facandu-se după codul numeric personal sau similarul sau pentru cetateni străini.
C4: aplicația permite cautarea si afișarea informațiilor legate de certificatele emise si starea acestora.
C5: aplicația lucrează cu o baza de date tip SQL in care va stoca certificatele calificate emise si toate detaliile necesare (attribute, stare, data emiterii, data expirării, data revocării etc).
%
Page 14 of 20 ^-- 2012-00424-1 3 -06- 2012
C6: aplicația permite validarea de către un operator al autoritatii, datele înscrise pentru obținerea unui certificate, avand in fata documentele furnizate de către client.
C7: un operator al autoritatii de certificare poate refuza o cerere venita din partea unui client, doar pe baza unui motiv pe care il va menționa in aplicație.
C8: Validarea datelor clientului de către un operator va duce automat la generarea certificatului calificat si semnarea acestuia de către autoritate folosind un dispozitiv HSM (Hardware Security Module).
C9: Fiecare certificate are o serie unica formata din un cod unic al autoritatii si un număr de ordine al certificatului generat in registrul certificatelor.
C10: De asemenea certificatul calificat respecta atributele cerute de către legea semnăturii electronice si normele de aplicare ale acesteia prin standardele referite.
Cil: Se vor trece sub forma de atribute informații ca numele posesorului, orașul, organizația si funcția sa, acolo unde este cazul.
C12: Aplicația comunică cu un HSM pe care sunt stocate certificatele si cheiele private ale autoritatii de certificare si subautoritatile sale. Aplicația de certificare, numita si CA (Certification Authority), cere HSM-ului semnarea certificatelor numai atunci când acestea sunt validate de către un operator al autoritatii.
o \-2 0 1 2 - 0 0 4 2 4 - î 3 -06- 2012
Page 15 of 20
C13: Orice client are posibilitatea, pe baza unui cont si a unei parole, sa revoce certificatul, in cazul in care acesta a fost compromise.
C14: Revocarea este disponibila la orice ora, si de pe orice platform hardware si software.
CI5: De asemenea revocarea este posibila si de către un operator al autoritatii, pe baza unei cereri venite din partea clientului.
CI6: Sistemul permite managementul operatorilor si al nivelului de acces al acestora in cadrul sau. Trebuie sa se faca diferența clara intre operatorii care pot valida certificate, anula certificate sau cei care administrează conturile sistemului.
CI7: aplicația va treui sa genereze periodic pentru autoritatea de certificare si pentru orice subautoritate a acesteia, la un interval setabil de timp pentru fieecare in pate (ex: 12 ore), o lista a certificatelor revocate - CRL (Certification Revocation List), utilizând standardele cerute de lege. Fișierele CRL vor fi semnate de HSM cu certificatele autoritatii părinte pentru fiecare CRL in parte. După semnare fișierele CRL vor fi stocate in baza de date, dar si pe server-ul web astfel incat fișierul sa poata fi consultat de clientii umane din pagina web, dar si automat de către aplicațiile software.
CI8: La introducerea datelor de către client, sau de către un operator al autoritatii, cu scopul obținerii unui certificate, adresa de email a clientului este validată prin trimiterea unui email cu un anumit link web, pe care clientul va trebui sa il acceseze. Prin acesarea acestui link aplicația va primi confirmarea ca adresa de oV- 2 0 1 2 - 0 0 4 2 4 - ~
3 -06- 2012
Page 16 of 20 email exista si este active. Daca trece un anumit timp, setabil de către administratorul sisitemului, cererea de validare a emailul va trebui sa expire, pentru a nu fi utilizata in alte scopuri.
Ci9: După finalizarea procesului de înscriere a unui client, acesta va primi alt email prin care este informat ca cererea lui de emitere a unui certificate a fost înregistrata cu succes si ca aceasta va fi verificata de către un operator al autoritatii.
C20: Daca cererea de emitere a unui certificate calificat este respinsa de către operator, atunci clientul primește un email de informare prin care sa se precizeze si motivul pentru care cererea sa a fost respinsa. Motivul transmis prin email este textul pe care operatorul il introduce in sistem la respingerea unei cereri de certificare.
C21: După validarea unui certificat, de către operatorul autoritatii, clientul va primi un email de informare ca cererea sa a fost aprobata si va avea si o adresa URL de unde va putea sa descarce certificatul generat de către autoritate. Descărcarea unui certificate se face pe un dispozitiv de securitate de tip token sau smart-card. Comunicarea cu dispozitivele de securitate se face folosind standardul PKCS#11. La descărcarea certificatului se cere clientului sa introducă o parola, pe care a specificat-o in procesul de înscriere. De asemenea aplicația va face si o verificare ca dispozitivul securizat pe care este descărcat certificatul calificat sa fie același cu cel folosit la generarea perechii de chei din procesul de înscriere.
Q- 2 0 1 2 - 0 0 4 2 4 - 1 3 -06- 2012
Page 17 of 20
C22: La revocarea unui certificat se trimite automat un email pe adresa de email a clientului, prin care este informat de aceasta acțiune.
C23: Toate aceste emailuri, pe care aplicația le transmite clientilor, sunt modificabile de către un administrator, prin editarea unor template-uri ale acestora.
C24: La revocarea unui certificate se va genera imediat si lista de certificate revocate CRL, care va include noul certificate revocat.
C25: Certificatele care au expirat, conform perioadei de valabilitate, nu vor mai fi trecute in listele CRL.
C26: Paginile in care este nevoie de acces la dispozitivul securizat al clientului conțin un obiect ActiveX sau Java Applet semnate digital, pentru a avea acces la resursele locale ale calculatorului clientului.
C27: Aplicația este complet funcționala si optimizata cel puțin pentru platform Internet Explorer 6 sau versiuni mai noi.
C28: Toate acțiunile operatorilor in aplicație vor trebui sa fie auditate si se vor păstră in baza de date, permițând astfel analiza acestora in cazul unor anumite contestații. Acțiunile logate vor include: înscrierea unui client, validarea sau respingerea unei cereri de certificare, revocarea unui certificate, generarea fișierelor CRL. Pentru fiecare acțiune sistemul va trebui sa stocheze in baza de date un cod al acțiunii, un identificator al operatorului responsabil, data si ora exacta a acțiunii, si o lista de parametrii ai acțiunii respective, acolo unde este cazul.
iX-2 0 1 2 - 0 0 4 2 4 - î 3 -06- 2012
Page 18 of 20
C29: De asemenea, aplicația va trebui sa scrie in fișiere de tip log, toate erorile sau orice alte informartii care ar putea sa intereseze pe administratorii sistemului. In fișierele de tip log este obligatorie precizarea orei exacte.
C30: Accesul la zonele critice ale aplicației, cum ar fi modulul de administrare sau cel de validare cereri de certificare, va trebui sa fie limitat pe baza de IP al clientului care incearca sa se conecteze. Numai daca IP-ul acestuia este unul de încredere se va trece la pasul in care este ceruta parola de acces.
b) Pentru partea de marcare digitală:
Aplicația de emitere a certificatelor calificate trebuie sa respecte normele legii mărcii temporal 451/2004, normele de aplicare ale acesteia, precum si standardele referite de aceste documente:
CI: aplicația este pe o platforma web.
C2: aplicația lucrează cu o baza de date tip SQL in care va stoca mărcile temporale emise si toate detaliile necesare (atribute, stare, data emiterii etc).
C3: Aplicația gestionează o lista de clienti. Fiecare client va avea un cont de acces (usemame si parola), dar si o descriere a unui abonament de servicii. Prin abonament se înțelege un număr de marcari temporal incluse, costul unei marcari peste cele incluse in abonament etc.
C4: Aplicația va aștepta sa primească cereri din partea aplicațiilor clientilor, cereri de marcare temporala in formatul impus de standardele referite de cadrul legislative.
> 2 0 1 2 - 0 0 4 2 4 - t 3 -06- 2012
Page 19 of 20
C5: Daca clientul care cere semnarea nu cont sau nu este unul valid, atunci aplicația va opri procesul de emitere al mărcii temporal.
C6: După recepționarea cererii de marcare, aplicația va stoca informațiile venite de la client (data si ora, nume client, codul HASH al informațiilor care trebuiesc marcate temporal, IP-ul mașinii prin care clientul s-a conectat).
C7: După salvarea cererii venite din partea clientului, aplicația crează un pachet de marcara temporal, pe care il va trimite la semnare HSM-umului de care se conectează. Comunicația cu HSM-ul se realizează pe baza standardului PKCS#11.
C8: HSM-ul semnează setul de date folosind certificatul si cheia private create special pentru marca temporal. Aplicația va trimite înapoi clientului un răspuns cu o marca temporala in formatul cerut de standardele tehnice impuse de lege.
C9: Fiecare marca temporal va avea o serie unica de identificare formata din codul autoritatii de marcare temporala si un număr de ordine in registrul mărcilor emise.
C10: Răspunsul către un client poate sa fie sub forma unor coduri de eroare, acolo unde este cazul.
Cil: După trimiterea răspunsului către client, aplicația va salva in baza de date acest răspuns cu toti parametri necesari.
C12: Aplicația generează, la cerearea unui operator al autoritatii, registrul mărcilor temporal emise.
^-2 0 1 2 - 0 0 4 2 4 -1 3 -06- 2012
Page 20 of 20
C13: De asemenea, marca temporala respectă atributele cerute de către legea mărcii temporale si normele de aplicare ale acesteia prin standardele referite.
C14: Sistemul permite managementul operatorilor si al nivelului de acces al acestora in cadrul sau
CI 5: Interfața cu utilizatorii funcționează cel puțin pe navigatoarele Mozila Firefox 6 si Internei Explorer 6.
CI6: Fiecare client va putea accesa o pagina web din cadrul aplicației, iar pe baza unui usemame si a unei parole, va putea sa intre in contul sau, unde sunt prezentate informații legate de număr mărcilor temporal emise pentru contul current, si toate detaliile acestora.
C17; Separat, trebuie luata in calcul dezvoltarea unui sistem integrat cu aplicația de plata online a abonamentelor de către clienți.
CI8: Aplicația scrie in fișiere de tip log, toate erorile sau orice alte informartii care ar putea sa intereseze pe administratorii sistemului. In fișierele de tip log este obligatorie precizarea orei exacte.

Claims (1)

13.3 REVENDICĂRI
Prin prezenta dorim protejarea proprietății intelectuale pentru:
Soluție generică de conectare la dispozitive de criptare digitală o aplicație capabilă să se conecteze la orice tip de dispozitiv de criptare, pentru a nu mai fi dependent de platformă sau producător astfel încât să se realizeze emiterea certificatelor digitale sau marcarea temporală a documentelor, conform descrierii acesteia depusă la actula cerere cu titlul „DESCRIERE”.
ROA201200424A 2012-06-13 2012-06-13 Soluţie generică de conectare la dispozitive de criptare digitală RO127992A0 (ro)

Priority Applications (1)

Application Number Priority Date Filing Date Title
ROA201200424A RO127992A0 (ro) 2012-06-13 2012-06-13 Soluţie generică de conectare la dispozitive de criptare digitală

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
ROA201200424A RO127992A0 (ro) 2012-06-13 2012-06-13 Soluţie generică de conectare la dispozitive de criptare digitală

Publications (1)

Publication Number Publication Date
RO127992A0 true RO127992A0 (ro) 2012-11-29

Family

ID=47220959

Family Applications (1)

Application Number Title Priority Date Filing Date
ROA201200424A RO127992A0 (ro) 2012-06-13 2012-06-13 Soluţie generică de conectare la dispozitive de criptare digitală

Country Status (1)

Country Link
RO (1) RO127992A0 (ro)

Similar Documents

Publication Publication Date Title
CN112333198B (zh) 安全跨域登录方法、系统及服务器
CN111741036B (zh) 一种可信数据传输方法、装置及设备
KR101591255B1 (ko) 클라이언트로부터 생성되는 정보에 대한 차동 클라이언트측 암호화
US9736146B2 (en) Embedded extrinsic source for digital certificate validation
US11082420B2 (en) Certificate issuing system based on block chain
US10182044B1 (en) Personalizing global session identifiers
CN115811412B (zh) 一种通信方法、装置、sim卡、电子设备和终端设备
EP3477891A1 (en) Methods for recording and sharing a digital identity of a user using distributed ledgers
CN113012008A (zh) 一种基于可信硬件的身份管理方法、装置及设备
CN109241181A (zh) 数据库操作方法和装置
CN103532704B (zh) 一种针对owa的电子邮件ibe加密系统
CN113129017B (zh) 一种信息共享方法、装置及设备
Lax et al. Enabling secure health information sharing among healthcare organizations by public blockchain
Danquah et al. Public key infrastructure: an enhanced validation framework
CN108022194A (zh) 执法记录仪及其数据安全处理方法、服务器及系统
CN102355459A (zh) 基于TPM的可信Web网页的实现方法
CN101739622A (zh) 一种可信支付计算机系统
CN114944937A (zh) 分布式数字身份验证方法、系统、电子设备及存储介质
CN111769956A (zh) 业务处理方法、装置、设备及介质
CN103078743B (zh) 一种电子邮件ibe加密实现方法
US20240236049A1 (en) System and method for providing access to secured content
JP2015064767A (ja) 文書保存管理システム及び文書保存管理方法
CN114513373B (zh) 可信数据交换方法、装置、系统、电子设备和存储介质
US20140259131A1 (en) Method for creating a security certificate
RO127992A0 (ro) Soluţie generică de conectare la dispozitive de criptare digitală