Cum funcționează semnătura electronică avansată pe DigiOHS

Imagine olografă vs. semnătură avansată (AES)

Ce cere legea pentru o semnătură electronică avansată — și cum o facem noi

Regulamentul UE 910/2014 (eIDAS) art. 26 impune patru condiții pentru ca o semnătură să fie „avansată". Mai jos sunt cele patru, în paralel cu implementarea noastră reală — fără pretenții despre ce nu avem.

Cum funcționează la noi, pas cu pas

Tot procesul durează aproximativ 200 milisecunde și se întâmplă automat în spatele scenei, după ce salariatul confirmă semnătura prin codul OTP primit pe telefon.

1. 1

   1

   Avem propria „fabrică de certificate"

   Avem propria „fabrică de certificate" (Certificate Authority)

   Pe serverele noastre am construit o ierarhie de certificate digitale, exact cum folosesc băncile. E ca un sistem de ștampile oficiale, în mai multe niveluri, una mai puternică decât cealaltă:

   Root CA DigiOHS — „regele"

   RSA 4096 biți, valabilă 20 ani. Cheia privată e generată local prin scriptul de bootstrap și stocată CRIPTATĂ (AES-256-GCM) în baza de date, cu cheia de cifrare protejată ca fișier cu permisiuni restricționate (acces doar pentru utilizatorul aplicației). Nu o emite operativ — semnează doar Intermediate CA.

   Intermediate CA DigiOHS Signing

   RSA 2048 biți, valabilă 5 ani, semnată de Root. Cheia privată e tot criptată AES-256-GCM și folosită doar la cerere pentru emiterea certificatelor individuale ale salariaților, sub umbrela de încredere a Root.

   De ce două niveluri? Dacă serverul este vreodată compromis, doar Intermediate cade. Root rămâne neatinsă în seifuri și putem emite o nouă Intermediate fără să afectăm încrederea construită până atunci. Așa fac DigiCert, Let's Encrypt, sistemele bancare — standardul mondial.

2. 2

   2

   Salariatul primește un certificat doar al lui

   Salariatul primește un certificat propriu, valabil 48 ore

   Când Popescu Ion completează codul OTP primit pe telefon (deci confirmăm criptografic că el are acel telefon), se întâmplă automat în mai puțin de o secundă:

   1. ▸Generăm o pereche de chei RSA 2048 doar pentru el, doar pentru această semnătură.
   2. ▸Construim un certificat X.509 personalizat cu datele lui:

   CN           = Popescu Ion              (numele lui complet)
   serialNumber = 0725999000               (telefonul confirmat OTP)
   O            = SC Moneta Cons SRL       (firma)
   OU           = CUI RO12345678           (CUI-ul firmei)
   E            = ion.popescu@firma.ro     (emailul)
   C            = RO                       (țara)

   3. ▸Semnăm certificatul cu Intermediate CA → moștenește încrederea de la Root.
   4. ▸Certificatul trăiește 48 ore. Cheia privată NU se salvează nicăieri — se folosește o singură dată pentru semnare și apoi se aruncă din memoria serverului.

   Asta este diferența esențială: certificatul nu este pe numele DigiOHS, ci pe numele salariatului real. Asta îl face strict conform eIDAS art. 26(a) — „legată unic de semnatar".

3. 3

   3

   PDF-ul primește un sigiliu PAdES

   PDF-ul primește un sigiliu PAdES — formatul oficial al UE

   Fișa de instruire generată trece printr-un proces criptografic:

   1. a.Calculăm un hash SHA-256 peste tot conținutul PDF-ului. Hash-ul este o „amprentă" digitală unică — orice modificare a PDF-ului produce un hash complet diferit.
   2. b.Criptăm hash-ul cu cheia privată a salariatului → asta este „semnătura".
   3. c.Atașăm în PDF: semnătura + certificatul salariatului + Intermediate CA + Root CA — adică tot lanțul de încredere.
   4. d.Rezultatul: un singur fișier PDF auto-conținut, care poate fi verificat oriunde, oricând, fără internet.

   Format folosit: PAdES Baseline B-LTA (Long Term) — formatul oficial al UE pentru semnături PDF cu validare offline pe termen lung, conform standardului ETSI EN 319 142-1. Concret: semnăm B-B, apoi adăugăm marca temporală RFC 3161 (B-T), apoi adăugăm dicționarul DSS cu certificatele + CRL-urile încorporate (B-LT) → validare offline 5+ ani fără dependență de servere. Dacă TSA sau CRL-ul sunt indisponibile la semnare, fluxul scade automat la B-T sau B-B (best-effort, nu blocăm semnătura).
4. 4

   4

   Verificarea — setup unic, apoi automată

   Verificarea — setup unic (~30s), apoi automată în Adobe

   În Adobe Acrobat Reader (gratuit), inspectorul vede în panoul Signatures (iconul pana albastră, stânga):

   • Cine a semnat — numele complet, telefonul, firma, CUI-ul.
   • Când s-a semnat — cu marca temporală RFC 3161 (precizie de secundă, certificată de o autoritate de timestamp).
   • „Document has not been modified since it was signed" — confirmare criptografică că fișa este intactă.
   • Lanțul complet: certificat utilizator → DigiOHS Signing CA → DigiOHS Root CA.

   Setup unic — important de transparență: primul control implică adăugarea certificatului DigiOHS Root CA în lista de încredere a Adobe (~30 s, o singură dată pe calculator). După acest pas, bifa verde apare automat pe toate fișele DigiOHS, fără internet și fără configurări suplimentare. Instrucțiuni: /certificat-digiohs.
   Motivul: Root CA DigiOHS nu e (încă) listată în Adobe AATL sau EU Trusted List — aceste liste cer audit WebTrust + statut QTSP (proces de 6-12 luni + €50-100k+). Fără setup-ul de mai sus, Adobe afișează triunghiul galben „The signer is unknown — chain of trust not verified" — semnătura e validă criptografic, dar Adobe nu cunoaște emitentul.

   Certificatul salariatului trăiește 48 ore — și de ce e ok. Acesta este un certificat „de unică folosință" emis doar pentru sesiunea de semnare. Validitatea pe termen lung e ancorată în marca temporală RFC 3161 emisă de BalTstamp QTSP (timestamp calificat, listat EU): timestamp-ul dovedește că semnătura a fost aplicată în interval valid, chiar dacă certificatul expiră ulterior. Plus DSS-ul PAdES B-LTA încorporează lanțul + CRL-urile în PDF → validare offline 5+ ani.

Cele 4 criterii eIDAS art. 26 — îndeplinite

Regulamentul UE 910/2014 (eIDAS) art. 26 definește exact ce trebuie să îndeplinească o semnătură pentru a fi „avansată". Iată cum bifăm fiecare criteriu:

Ce documente sunt semnate cu AES

Fiecare PDF generat de DigiOHS trece automat prin procesul de semnare AES înainte de a fi trimis utilizatorului. Fără excepție.

Trei beneficii concrete

Cadrul juridic