Criptare PDF AES-256 în Delphi: configurare și capcane cu HotPDF

Un flag de permisiune PDF nu este un lacăt. Este o cerere pe care fișierul o adresează oricărui program care îl deschide, iar un vizualizator este liber să o ignore. Acest singur fapt decide modul în care ar trebui să gândiți fiecare altă alegere de pe această pagină. Confidențialitatea reală vine dintr-un singur loc: criptarea AES-256, cu cheia derivată dintr-o parolă pe care cititorul nu o are. Tot restul, casetele de bifat "fără tipărire" și "fără copiere", este politică pe care software-ul conform acceptă să o respecte, iar software-ul ostil nu. Amestecați aceste două straturi și livrați ceva care pare sigur într-o demonstrație și care are scurgeri în teren

HotPDF este o componentă PDF nativă VCL pentru Delphi și C++Builder și expune modelul de protecție ISO 32000 printr-un set restrâns de proprietăți. Proprietățile sunt ușor de setat. Partea dificilă este să știți care dintre ele vă cumpără protecție criptografică și care vă cumpără doar o sugestie politicoasă, precum și să respectați ordinea corectă de atribuire, astfel încât criptarea pe care ați cerut-o să fie chiar cea pe care o primiți

Ce promit de fapt cele două parole

Criptarea PDF definește două credențiale cu roluri diferite, iar confundarea lor este cea mai comună eroare de proiectare în codul care produce ieșiri protejate. Parola de utilizator controlează accesul la decriptare. Fără ea, sau fără parola de proprietar, un cititor conform nu poate reconstitui cheia fișierului, iar conținutul rămâne ilizibil din punct de vedere criptografic. Parola de proprietar controlează în schimb setările de permisiune: un cititor care primește parola de proprietar obține acces complet, indiferent ce spun flagurile de restricție

Biții de permisiune stau pe un teren mai slab. Tipărirea, extragerea conținutului, completarea formularelor: fiecare este un flag pe care un vizualizator îl citește și alege să îl respecte (ISO 32000-2 §7.6.4). Criptarea protejează octeții. Flagurile de permisiune doar instruiesc software-ul conform și o fac după fapt. Oricine deschide documentul cu parola de utilizator deține deja conținutul decriptat în memorie, așa că "fără copiere" și "fără tipărire" înseamnă ceva pentru un vizualizator cuminte și nimic pentru unul hotărât. Construiți modelul de amenințare în jurul acestei linii. Confidențialitatea trăiește în parola de utilizator. Permisiunile modelează ceea ce oferă vizualizatoarele mainstream, și asta este tot ce fac

Ordinea configurării: totul înainte de BeginDoc

HotPDF construiește dicționarul de criptare și derivă cheia fișierului chiar în momentul în care rulează BeginDoc. Orice conțin proprietățile de protecție în acel instant este ceea ce primește documentul, iar modificarea lor ulterioară nu schimbă nimic. Proprietatea care contează cel mai mult aici este CryptKeyLength, care alege schema dintre valorile THPDFKeyType k40, k128, aes128 și aes256. Atribuiți-o după BeginDoc și nu primiți nicio excepție, niciun avertisment, doar un fișier care a păstrat pe tăcute orice avea la început. Acest tip de divergență silențioasă este cel mai rău fel: trece de fiecare test local și apare peste luni de zile ca o constatare de conformitate pe biroul unui client

var
  Pdf: THotPDF;
begin
  Pdf := THotPDF.Create(nil);
  try
    Pdf.FileName := 'statement.pdf';
    Pdf.ActivateProtection := True;
    Pdf.CryptKeyLength := aes256;        // trebuie setat înainte de BeginDoc
    Pdf.UserPassword := 'open-secret';
    Pdf.OwnerPassword := 'admin-secret';
    Pdf.UseAES256R6 := False;            // R=5: cel mai larg suport de vizualizatoare
    Pdf.BeginDoc;
    Pdf.CurrentPage.SetFont('Arial', [], 11);
    Pdf.CurrentPage.TextOut(50, 720, 0, 'Account statement, June 2026');
    Pdf.EndDoc;
  finally
    Pdf.Free;
  end;
end;

Parolele sunt UTF-8 și limitate la 127 de octeți, care este limita ISO 32000-2 pentru schemele AES-256. Dacă politica dumneavoastră de parole vă oferă secrete mai lungi, faceți trunchierea chiar dumneavoastră, pe partea proprie, unde controlați exact unde cade tăietura. Lăsați acest lucru la voia întâmplării, iar biblioteca și un viitor vizualizator pot să nu cadă de acord asupra punctului de tăiere, ceea ce produce un fișier care se deschide la dumneavoastră și refuză aceeași parolă în altă parte

Revizia 5 sau revizia 6: un boolean, două ecosisteme

UseAES256R6 alege între cele două protocoale de negociere AES-256, iar alegerea are consecințe mai mari decât sugerează tipul său boolean. Lăsați-l False și HotPDF scrie revizia 5, schema AES-256 care a apărut ca o extensie la PDF 1.7 și pe care o pot deschide vizualizatoare vechi de aproximativ cincisprezece ani. Setați-l True și obțineți revizia 6, derivarea de cheie întărită standardizată în ISO 32000-2 pentru PDF 2.0, care închide o vulnerabilitate cunoscută în modul în care revizia 5 verifică parola

Deci revizia 6 este, criptografic, varianta mai bună. Este de asemenea cea care strică lucrurile. Un fișier revizia 6 are nevoie de un vizualizator construit pentru PDF 1.7 Extension Level 3 sau PDF 2.0, iar o mare parte din software-ul instalat nu este niciuna dintre acestea: arhive de gestiune a înregistrărilor, motoare de randare integrate în alte produse, instrumente business pe care nimeni nu le-a atins de ani de zile. Acestea vor refuza fișierul direct, și o vor face pe mașina clientului, niciodată pe a dumneavoastră. Implicit-ul practic este, prin urmare, revizia 5. Apelați la revizia 6 doar atunci când o politică de securitate numește ISO 32000-2 după revizie și atunci când ați confirmat efectiv că fiecare consumator o poate citi. Oricum ați proceda, notați pe care ați ales-o și de ce, pentru că următoarea persoană care atinge acest cod se va întreba

Tipurile de chei mai vechi merită o propoziție, ca să știți să le evitați. THPDFKeyType mai listează încă k40, k128 și aes128, dar acestea există pentru a reproduce arhive istorice, nu pentru a proteja unele noi. RC4 pe 40 de biți cedează în fața hardware-ului obișnuit, iar schemele pe 128 de biți sunt anterioare reviziilor AES-256 pe care orice analiză de securitate actuală le va cere. Pentru un document pe care îl creați în 2026, singura întrebare reală este revizia 5 versus revizia 6; dacă vă surprindeți apelând la tipurile vechi pentru un design nou, ceva mai în amonte a mers prost

Flaguri de permisiune fără o parolă de deschidere

Adesea cerința este opusul secretului. Oricine ar trebui să poată citi documentul, dar tipărirea sau extragerea sunt menite să fie limitate. Exprimați acest lucru cu o parolă de utilizator goală și o parolă de proprietar nevidă, ceea ce PDF numește mod de parolă deschisă, și listați operațiile pe care doriți să le permiteți în ProtectOptions

Pdf.ActivateProtection := True;
Pdf.CryptKeyLength := aes256;
Pdf.UserPassword := '';                      // oricine poate deschide fișierul
Pdf.OwnerPassword := 'rotate-me-quarterly';  // protejează setul de permisiuni
Pdf.ProtectOptions := [prPrint, prPrint12bit, prExtractContent];
Pdf.BeginDoc;
// ... conținutul paginii ...
Pdf.EndDoc;

Mulțimea THPDFProtectOptions se mapează pe biții de permisiune ISO: prPrint și prPrint12bit pentru tipărire de înaltă rezoluție, prInformationCopy pentru copiere și extragere generală, prExtractContent pentru extragere destinată tehnologiilor asistive, plus prModifyStructure, prEditAnnotations, prFillAnnotations și prAssemble. Două dintre ele merită un avertisment. Lăsați prExtractContent activat în aproape fiecare profil pe care îl construiți. Este bitul de care are nevoie un cititor de ecran ca să ajungă la text, iar dezactivarea lui pe tăcute transformă o decizie legată de drepturi într-un defect de accesibilitate pe care o persoană cu dizabilități îl întâlnește, iar dumneavoastră nu îl vedeți niciodată. Cealaltă capcană este prPrint de unul singur, fără prPrint12bit: mai multe vizualizatoare răspund degradând calitatea tipăririi, iar utilizatorii dumneavoastră vor raporta asta ca pe un bug de randare, nu ca pe setarea de permisiune care este de fapt

Verificarea durează cinci minute și își are locul în checklist-ul dumneavoastră de lansare. Deschideți un eșantion din fiecare profil în Acrobat, deschideți Document Properties și citiți fila Security, care indică algoritmul ("AES 256-bit") și listează operațiile permise, una câte una. Apoi deschideți același fișier în cel mai vechi vizualizator pe care clienții dumneavoastră îl folosesc efectiv, nu cel mai nou de pe mașina dumneavoastră. Această a doua deschidere este asigurarea ieftină împotriva unui fișier revizia 6 care trece fără probleme prin dezvoltare și moare la un client care nu a actualizat niciodată

Eliminarea protecției din fișiere existente

Decriptarea rulează același model de proprietăți în sens invers. Încărcați documentul cu o credențială validă, dezactivați protecția și salvați rezultatul fără ea

var
  Pdf: THotPDF;
  PageCount: Integer;
begin
  Pdf := THotPDF.Create(nil);
  try
    PageCount := Pdf.LoadFromFile('encrypted.pdf', 'open-secret');
    if PageCount > 0 then
    begin
      Pdf.ActivateProtection := False;   // elimină criptarea la salvare
      Pdf.SaveLoadedDocument('plain.pdf');
    end;
  finally
    Pdf.Free;
  end;
end;

Acea rută parsează întregul document în memorie, ceea ce este în regulă pentru fișiere obișnuite și risipitor pentru unele uriașe. Când intrarea ajunge la sute de megaocteți, DecryptFile este opțiunea mai ieftină: decriptează în timpul unei copieri la nivel de fișier, urmând o cale de rescriere AES-256 directă care sare peste construirea întregului arbore de obiecte ori de câte ori intrarea permite acest lucru. Face parte din Direct File API, tratat în articolul complementar despre procesarea PDF-urilor mari din Delphi

Constrângeri care interacționează cu criptarea

Merită să cunoașteți două limitări înainte de a proiecta în jurul criptării, nu după. Prima este conformitatea arhivistică. ISO 19005 interzice criptarea în PDF/A, astfel încât orice flux de lucru care criptează un document și, în același timp, pretinde conformitate PDF/A este contradictoriu prin construcție; HotPDF nu vă va permite să aveți ambele într-un singur fișier. Când aveți cu adevărat nevoie de ambele, răspunsul este două artefacte: o copie criptată pentru distribuție și o copie separată, necriptată, pentru arhivă

A doua limitare este mai dură. Criptarea PDF nu are niciun mecanism de escrow și nicio recuperare. Pierdeți parola de utilizator la un fișier R5 sau R6 și opțiunile dumneavoastră sunt forța brută sau renunțarea. Așadar tratați secretele de proprietar și de utilizator așa cum tratați orice credențială de producție. Generați-le, stocați-le într-un vault, rotiți-le după un program. Singurul lucru pe care nu trebuie să-l faceți niciodată este să le codificați dur ca și constante într-o unitate, de unde ajung direct în controlul versiunilor și rămân pentru totdeauna în copia de lucru a fiecărui dezvoltator

Un ultim reflex care merită format. Schimbarea protecției unui fișier pe care nu l-ați creat dumneavoastră folosește exact aceeași mecanică precum decriptarea, nu este o funcție separată: încărcați-l cu parola sa prin LoadFromFile, editați ProtectOptions sau parolele pe loc și scrieți-l înapoi cu SaveLoadedDocument. Dacă puteți decripta un fișier, îi puteți schimba și permisiunile, iar codul arată aproape identic cu exemplul de mai sus

Proprietățile de protecție prezentate aici fac parte din HotPDF Delphi Component standard pentru Delphi și C++Builder; pagina de produs conține referința completă de criptare, inclusiv enumerarea completă a permisiunilor