Securitatea semnăturilor electronice DigiOHS

Toate fișele de instruire generate prin DigiOHS poartă o semnătură electronică avansată (AES) conform definiției din Regulamentul UE 910/2014 (eIDAS) art. 26. Concret, fiecare semnătură satisface simultan cele patru condiții:

• Linkată unic la semnatar — certificatul X.509 are în câmpulsubject.serialNumber (RFC 5280) un identificator personal verificabil (telefon din dosarul de personal, validat prin SMS OTP).
• Identifică semnatarul — commonNameconține numele complet, organizationName firma,organizationalUnitName conține CUI-ul.
• Sub controlul exclusiv al semnatarului — cheia privată RSA se generează ephemeral în memoria serverului doar după ce utilizatorul introduce un cod OTP cu 6 cifre primit prin SMS pe telefonul lui. Cheia nu se stochează niciodată nici pe disc, nici în baza de date.
• Detectează modificările ulterioare — semnătura PAdES Baseline B-LTA se calculează peste ByteRange (toate octeții PDF-ului mai puțin signature dictionary). Orice byte schimbat invalidează verificarea criptografică. Marca temporală RFC 3161 atașată ca id-aa-signatureTimeStampTokendovedește, în plus, momentul exact al semnării.

DigiOHS operează o autoritate de certificare internă cu trei niveluri, izolată de CA-uri publice (nu este cross-signed). Toate certificatele utilizator sunt emise de Intermediate CA, niciodată direct de Root CA.

        ┌──────────────────────────────────────┐
        │   DigiOHS Root CA                    │
        │   RSA 4096 · valabil 20 ani          │
        │   Self-signed · keyUsage=keyCertSign │
        │   Basic Constraints: CA=TRUE         │
        └──────────────────────────────────────┘
                          │ semnează
                          ▼
        ┌──────────────────────────────────────┐
        │   DigiOHS Issuing Intermediate CA    │
        │   RSA 4096 · valabil 5 ani           │
        │   keyUsage=keyCertSign + cRLSign     │
        │   pathLenConstraint=0                │
        └──────────────────────────────────────┘
                          │ semnează
                          ▼
        ┌──────────────────────────────────────┐
        │   User Certificate (per semnătură)   │
        │   RSA 2048 · valabil 48 ore          │
        │   keyUsage=digitalSignature +        │
        │     nonRepudiation                   │
        │   extKeyUsage=id-kp-documentSigning  │
        │     (OID 1.3.6.1.5.5.7.3.36)         │
        │   subject.serialNumber=<phone>       │
        └──────────────────────────────────────┘

Un PDF semnat conține întreaga chain (User cert + Intermediate + Root) într-o structură CMS SignedData conformă PKCS#7. La validare, orice viewer compatibil PAdES (Adobe Reader, Foxit, pdfsig) poate verifica chain-ul fără apel la rețea, atât timp cât are Root CA în trust store.

Roadmap criptografic: ECDSA P-256 ca alternativă la RSA-2048 (gain de performanță), RSA-PSS în loc de PKCS#1 v1.5 padding (rezistență la atacuri Bleichenbacher), Post-Quantum (CRYSTALS-Dilithium) când NIST publică standardele finale.

Niciun certificat utilizator nu este pre-emis sau cached. Fiecare semnătură generează un certificat nou, valabil 48 ore (durata standard pentru a permite reluarea fluxului în caz de erori temporare ale rețelei).

Pași la emitere (server-side):

1. Validare OTP (6 cifre) introdus de utilizator vs hash SHA-256 stocat.
2. Generare keypair RSA-2048 în memoria procesului Node (forge.pki.rsa.generateKeyPair).
3. Construire CSR cu subject DN populat din dosarul de personal (CommonName, organizationName, OID 2.5.4.5 = telefon E.164).
4. Adăugare extensii: basicConstraints CA=false, keyUsage digitalSignature + nonRepudiation, extKeyUsage id-kp-documentSigning.
5. Decriptare cheie privată Intermediate CA (AES-256-GCM cu master key) și semnare CSR.
6. Persistare în digiohs_issued_certificates: serial, certPem (publicul), publicKeyHash, validity. Niciodată cheia privată.
7. Returnare în RAM a certificatului + cheii private către funcția de semnare PAdES.
8. După aplicarea semnăturii, cheia privată iese din scope-ul funcției → garbage-collected.

Salariat (telefon)        DigiOHS (server)              MariaDB / Storage
─────────────────────     ───────────────────           ──────────────────
1. WhatsApp link  ────────▶
                           Verifică token OTP-link
                           Returnează formular semnătură

2. Trasează semnătura ────▶
                           Stochează signature image
                                               ───────▶ digiohs_stored_signatures
                                                        (imagine PNG)

3. Cere OTP       ────────▶
                           Generează 6 cifre random
                           SHA-256(OTP) → DB
                                               ───────▶ digiohs_training_events
                                                        (otpHash, otpSentAt)
                           Trimite SMS Infobip ────▶ telefon E.164

4. Introduce OTP  ────────▶
                           SHA-256(input) == DB hash?
                           ↓ DA + max 5min trecute
                           Setează otpVerifiedAt
                           Setează completedAt
                                               ───────▶ digiohs_training_events

5. Cere PDF       ────────▶
                           Verifică completedAt set
                           ↓ DA
                           buildFisaPdf() → PDF nesem.
                           applyOrganizationWatermark()
                           ─────────────────────────
                           issueUserCertificate():
                           - Generează RSA-2048 (RAM)
                           - Decriptează Intermediate
                             CA cu CA_MASTER_KEY
                           - Semnează cert utilizator
                           - Persistă DOAR certPem
                                               ───────▶ digiohs_issued_certificates
                           ─────────────────────────
                           signPdfWithPades():
                           - normalizeToLegacyXref()
                           - plainAddPlaceholder()
                           - PKCS#7 detached signature
                             cu cheia ephemeral
                           ─────────────────────────
                           Cere TSA timestamp (RFC 3161)
                           Embedează timestampToken
                           ─────────────────────────
                           Cheia privată iese din scope
                           → GC distruge octeții

                           Returnează PDF semnat ◀──── browser

                           audit log:
                           PADES_SIGNATURE_APPLIED
                                               ───────▶ digiohs_audit_events

Întregul ciclu de la prezentarea OTP-ului la PDF semnat: tipic 800-1500ms. Cheia privată trăiește efectiv ~50ms în memoria procesului Node.

Cheia utilizator (per semnătură)

Strategia: ephemeral, never-stored. Generată în memoria procesului, folosită pentru o singură operație de semnătură, distrusă la ieșirea din scope. Nu există persistență, nu există recuperabilitate. Aceasta e o postură mai puternică decât modelul KEK (Key Encryption Key) folosit de DocuSign, fiindcă nu există nimic de decriptat.

Cheia Intermediate CA

Singura cheie privată persistentă din sistem. Stocare:

• Tabela digiohs_certificate_authorities, câmp encryptedKeyPem.
• Format: v1:<iv>:<authTag>:<ciphertext_b64>
• Cifrare: AES-256-GCM. IV unic per cheie (12 octeți random). AuthTag 128 biți.
• Master key: 32 octeți (256 biți) stocată în /etc/digiohs/ca-master.key cu permisiuni 0440 root:digiohs — owner root (revocare instantă), citibil doar de procesul de aplicație care rulează sub user-ul digiohs, niciun alt user de shell nu îl poate accesa. Nu apare în .env.production, nu se loghează în deploy scripts, nu e listat de printenv pe sistem.

Atacul ipotetic care recuperează intermediate CA ar necesita simultan: (a) acces root la serverul aplicației, (b) acces la DB dump. Cu ambele, atacatorul ar putea decriptaoricine Intermediate CA și emite el însuși certificate. Pentru a închide și această zonă, oferim un upgrade opțional cu HSM hardware (FIPS 140-2 Level 3) la cerere pentru clienți enterprise — cheia nu părăsește niciodată cipul, semnarea se face prin PKCS#11 API.

Root CA

Generată o singură dată la bootstrap, ținută offline sau pe HSM (după cerință). Folosită exclusiv pentru semnarea certificatelor Intermediate (operație rară, ~o dată la 5 ani). Nu e accesibilă proceselor aplicației în funcționarea normală.

O semnătură DigiOHS poate fi verificată în mai multe moduri:

a) Adobe Acrobat Reader (gratuit)

1. Deschide PDF-ul semnat → tab Signatures (panou stânga).
2. Click pe semnătură → Validity Status.
3. La prima verificare: import Root CA în trust store (DigiOHS publică fingerprint-ul Root CA pe această pagină — vezi mai jos).
4. Adobe verifică: integritatea bytes, lanțul de certificate, timestamp-ul TSA, dacă certificatele nu au fost revocate (CRL/OCSP).

b) Linie de comandă (pdfsig / openssl)

# pdfsig (poppler-utils)
pdfsig -nocert fisa.pdf

# extragere semnătură + verificare openssl
pdfsig -dump-sig fisa.pdf
openssl pkcs7 -inform DER -in signature.bin -print_certs

c-bis) Forensic monitoring continuu

Pe lângă semnătura propriu-zisă, un cron orar verifică integritatea audit log-ului:

• Pentru fiecare TrainingEvent finalizat în ultimele 25h, verifică existența unui AuditEvent corespunzător cu acțiuneaTRAINING_OTP_VERIFIED. Dacă lipsește → posibil bypass prin SQL direct → alertă email la office@digiohs.com.
• Pentru fiecare semnătură instructor/verificator atașată recent, verifică audit corespondent (TRAINING_BATCH_*_SIGNED sau PADES_SIGNATURE_APPLIED).
• Recalculează SHA-256 hash chain pentru ultimele 5.000 evenimente audit. Orice divergență față de valoarea stocată (hashChain) detectează tampering pe tabela de audit însăși.

Toate anomaliile generează alertă email la office@digiohs.com + ping Slack. Cron-ul rulează cu lock distribuit (MariaDB GET_LOCK) → o singură execuție / oră, indiferent câte hosturi sunt active. Răspunde la întrebarea Q4 din checklist-ul de due diligence: chiar dacă un atacator cu acces SQL direct ar bypass OTP-ul, modificarea ar fi detectată în maxim 1 oră.

c) eIDAS proof bundle (pentru audit ITM)

DigiOHS oferă, prin endpoint-ul GET /api/training/eidas-proof?event=..., un PDF de probă care include: hash-ul fișei semnate, timestamp TSA, lanțul complet de certificate, log-ul de audit cu IP + user agent + timestamp OTP, plus referințele legale eIDAS art. 26 + Legea 214/2024 art. 4 alin. (5).

d) DigiOHS Root CA — fingerprint public

• Regulament UE 910/2014 (eIDAS) art. 26 — definiția AES. Toate cele patru condiții satisfăcute (vezi secțiunea 1).
• Legea 214/2024 (RO) — art. 4 alin. (5) privind utilizarea semnăturii electronice. Abrogă Legea 455/2001. AES produce efectele unei semnături olografe doar dacă este îndeplinită una dintre condițiile alternative (a–d) — vezi secțiunea 1 + secțiunea 9 pentru detalii. Sarcina probei: art. 5 alin. (3).
• Codul Muncii (RO) art. 16, art. 17 alin. (3) lit. o),HG 1425/2006 (modif. HG 259/2022) art. 81 — procedurile privind utilizarea AES pentru semnarea fișelor de instruire SSM trebuie incluse în CIM-ul fiecărui salariat și în regulamentul intern al angajatorului.
• ETSI EN 319 142-1 — formatul PAdES Baseline B-LTA implementat (PKCS#7 detached + timestamp RFC 3161 embedat în SignerInfo.unsignedAttrs + DSS dictionary cu CRL semnat de Intermediate CA și lanțul complet de certificate, plus VRI (Validation Related Info) cheată pe SHA-1 al semnăturii). Conform ISO 32000-2 §12.8.4 — semnătura poate fi validată offline 5+ ani după emitere, fără apel la rețea. Pe roadmap: B-LTA (archive timestamp pentru extinderea valabilității dincolo de validitatea certificatelor — necesar pentru retenție 10+ ani).
• RFC 5280 — X.509 v3 certificate profile. Toate certificatele noastre respectă profilul.
• RFC 3161 — Time-Stamp Protocol, model hibrid: fiecare semnătură (salariat, instructor, verificator) primește o marcă temporală calificată eIDAS de la un QTSP listat pe EU LOTL (BalTstamp, rezervă Sectigo Europe) — prezumție legală de acuratețe conform art. 41(2). Documentele descărcate/regenerate primesc o marcă temporală standard RFC 3161 (DFN-Verein, Germania) doar pentru integritate, fără a consuma marca calificată. Token-ul e embedat în SignerInfo-ul PKCS#7 (PAdES B-LTA).
• NIST SP 800-38D — modul GCM pentru AES-256.
• FIPS 180-4 / RFC 6234 — SHA-256.
• GDPR (UE 2016/679) — datele personale ale semnatarului (telefon, nume) sunt stocate exclusiv în certificat și DB-ul intern; nu sunt expuse public sau transmise către terți. Retenție: 5 ani conform legislației RO pentru documente SSM, apoi anonimizare.

Această secțiune există pentru transparență față de avocați, auditori și clienți corporate. Implementarea criptografică DigiOHS este conformă eIDAS art. 26 — dar valoarea juridică a unei AES depinde și de elemente contractuale și organizaționale care nu țin de noi. Le declarăm explicit aici.

a) Sarcina probei (Legea 214/2024 art. 5 alin. (3))

În caz de litigiu, partea care invocă semnătura (angajatorul) trebuie să demonstreze validitatea ei. La QES sarcina probei se inversează automat — la AES nu. Diferența practică: trebuie să fii pregătit să prezinți eIDAS proof bundle-ul + audit log-ul + procedurile interne care arată cum funcționează sistemul. DigiOHS livrează tehnic toate aceste artefacte; angajatorul răspunde de procedurile organizaționale.

b) Identificarea prin telefon — limite probatorii

Numărul de telefon din dosarul de personal nu este, prin sine, un identificator personal verificabil în sens juridic strict. La onboarding salariatul trebuie să confirme expres (ideal prin OTP + acceptare scrisă în CIM) că numărul este al lui și că își asumă semnături generate prin coduri SMS pe acel număr. Fără această confirmare formală, în litigiu se poate ataca legătura „semnătură ↔ identitate": „nu eu am semnat, mi-a luat telefonul colegul".

c) Root CA self-signed — limită de UX, nu de validitate

DigiOHS Root CA nu este (încă) inclus în Adobe Approved Trust List (AATL) sau în EU List of Trusted Lists (LOTL). Consecință practică: la prima deschidere în Adobe Reader, PDF-ul afișează „At least one signature has problems" sau „Signer's identity is unknown". Asta nu invalidează semnătura — chain-ul este verificabil odată ce Root CA-ul nostru este importat în trust store, iar criptografia rămâne integră. Dar pentru un inspector ITM care nu importă manual Root CA, mesajul vizual e neideal. Pentru AATL/LOTL trebuie fie să devenim TSP calificat, fie să cross-semnăm cu un TSP existent — pe roadmap.

d) Timestamp hibrid: calificat pe semnătură, standard pe document

Marca temporală este embedată în PKCS#7 ca id-aa-signatureTimeStampToken (PAdES Baseline B-LTA conform ETSI EN 319 142-1) — Adobe Reader o afișează în panoul de detalii al semnăturii ca timestamp criptografic atașat.

Fiecare semnătură (salariat, instructor, verificator) este marcată temporal de un QTSP calificat de pe lista EU LOTL — BalTstamp (Lituania), cu rezervă Sectigo Europe. Aceste mărci beneficiază de prezumția legală de exactitate a timpului conform eIDAS art. 41 alin. (2) — sarcina probei revine celui care le contestă. Acesta este reperul juridic care contează într-o eventuală dispută (ex. un salariat care contestă o fișă în instanță).

Documentele descărcate sau regenerate (fișa PDF, dovada eIDAS, recipisa de semnare) primesc în plus o marcă temporală standard RFC 3161 (DFN-Verein, Germania) — exclusiv pentru a dovedi integritatea PDF-ului la momentul generării. Aceasta nu este calificată și nu este necesar să fie: nu este o semnătură, ci doar metadată de manipulare a documentului. Astfel mărcile calificate (limitate, cu valoare juridică) sunt folosite doar acolo unde contează — pe semnături — iar descărcările și acțiunile ad-hoc nu le consumă. Pentru SLA contractual pe timestamp-ul calificat, DigiOHS poate fi comutat la un QTSP plătit (certSIGN / Trans Sped / SK ID) printr-o singură variabilă de mediu.

e) Cele 4 condiții alternative din art. 4 alin. (5)

Pentru ca AES emis prin DigiOHS să aibă aceleași efecte ca o semnătură olografă în România, este suficientă îndeplinirea uneia dintre cele patru condiții (a–d). Recomandare:

• (c) + (d) combinate sunt cea mai sigură rută. Convenție AES distinctă semnată olograf la onboarding (c) + arhitectura DigiOHS ca sistem închis cu audit (d) închid simultan două căi de atac.
• Pe rolurile critice (instructor SSM, conducător loc de muncă, verificator) există opțiunea de a integra QES via TSP calificat (CertSign, DigiSign) — care elimină dependența de art. 4 alin. (5) și inversează sarcina probei (art. 5 alin. (3) nu se mai aplică pentru QES).

f) Ce livrează DigiOHS vs. ce livrează angajatorul

• DigiOHS livrează: arhitectura tehnică AES (cheie ephemeral, PAdES B-LTA, OTP, audit log cu hash chain, eIDAS proof bundle), șabloane editabile pentru CIM, regulament intern și convenție AES, plus integrarea opțională cu un TSP calificat la cerere.
• Angajatorul livrează: act adițional la CIM-ul fiecărui salariat care folosește AES, regulament intern care prevede modalitatea AES, semnarea olografă a convenției AES la onboarding (sau cu QES), confirmarea expresă a numărului de telefon ca aparținând salariatului. Nimic din acestea nu poate fi automatizat de noi — sunt acte juridice între angajator și salariat.

Pentru întrebări de due diligence, audit criptografic, sau raportare de vulnerabilități:

Răspundem la rapoarte de vulnerabilitate în maxim 5 zile lucrătoare. Pentru contracte enterprise oferim NDA-uri standard, audit acces la cod, și asistență la integrare HSM la cerere.