PDFiumPas skriver ISO/TS 32003-kryptering gennem SaveAsEncrypted: sæt Revision til erR7, og hver streng og strøm beskyttes med AES-256 i GCM-tilstand, den autentificerede cipher, PDF 2.0 fik i 2023. Sæt også EnableIntegrityProtection, og dokumentet bærer også et selvstændigt PDF MAC-token, som ValidatePdfMac tjekker på læsesiden
Det er to forskellige beskyttelser, folk rutinemæssigt sammenblander. GCM autentificerer hver krypteret værdi. MAC'en autentificerer dokumentet som helhed. Du vil have begge, af forskellige grunde
Hvad tilføjer GCM, som CBC aldrig gav?
Autentificering af ciphertekst. AES-256 i CBC-tilstand, AESV3-skemaet i ISO 32000-2, holder indhold fortroligt og siger intet om, hvorvidt det ankom uændret. CBC er formbart på specifikke, veludforskede måder: en angriber, der kan vende bits i ciphertekst, producerer forudsigelige ændringer i klarteksten i den følgende blok, og intet i formatet bemærker det
GCM lukker det. Hver krypteret værdi bærer en 16-byte autentificeringstag, serialiseret fuldt ud, som ISO/TS 32003 kræver, og dekryptering fejler frem for at returnere ændret klartekst, når tagget ikke matcher. I PDF-termer er en manipuleret streng eller strøm i et AESV4-dokument en hård fejl på anvendelsestidspunktet, ikke en mærkelig værdi, der forplanter sig ind i din applikation. Encrypt-ordbogen markerer dette med /CFM /AESV4 og V 6 / R 7, sammen med en udvidelsespost, der erklærer /ExtensionLevel 32003 og /ExtensionRevision (:2023)
Tre revisioner, tre økosystemer
TPdfEncryptionRevision tilbyder erR5, erR6 og erR7, og valget er mere en kompatibilitetsbeslutning end en kryptografisk en. R5 er det oprindelige AES-256-skema, udgivet som en PDF 1.7-udvidelse, med en enkelt SHA-256-adgangskodehash, og det åbner i stort set alt fra de sidste femten år. R6 er den hærdede nøgleudledning, standardiseret i ISO 32000-2, ved brug af den iterende SHA-256/384/512-konstruktion i algoritme 2.B, og det er, hvad en nutidig PDF 2.0- eller PDF/A-4-arbejdsgang forventer. R7 er ISO/TS 32003, ved brug af den samme 2.B-udledning med AES-GCM som cipheren
Læserunderstøttelse kører i præcis den rækkefølge, og R7-understøttelse er stadig tynd uden for aktuelle mainstream-viewere. Dette er det samme afvejningsforhold, der styrer enhver PDF 2.0-funktion: den nyeste mulighed er det bedste ingeniørarbejde og den snævreste målgruppe. Beslut ud fra, hvem der skal åbne filen, og hvis det svar er "et journalsystem, ingen har opdateret siden 2019", er svaret R5, uanset hvad sikkerhedspolitikken foretrækker
uses
PDFium, FPdfEncrypt;
var
Pdf: TPdf;
Opts: TPdfEncryptOptions;
begin
Pdf := TPdf.Create(nil);
try
Pdf.FileName := 'quarterly-report.pdf';
Pdf.LoadDocument;
Opts := TPdfEncryptOptions.Default;
Opts.UserPassword := 'open-secret';
Opts.OwnerPassword := 'admin-secret';
Opts.EncryptMetadata := True;
Opts.Revision := erR7; // ISO/TS 32003 AESV4-GCM
Opts.EnableIntegrityProtection := True; // selvstændigt PDF MAC-token
if not Pdf.SaveAsEncrypted('quarterly-report.enc.pdf', Opts) then
raise Exception.Create('Encrypted save failed');
finally
Pdf.Free;
end;
end;
Hvorfor en dokument-MAC oven på en autentificeret cipher?
Fordi GCM-tags beskytter værdierne, ikke arrangementet af værdierne. Hver streng og strøm i et AESV4-dokument er individuelt autentificeret, men krydsreferencetabellen, objektnummereringen og traileren er struktur, ikke krypteret indhold. En angriber kan ikke forfalske en strøm, men intet i selve cipheren forhindrer dem i at omarrangere, hvilke objekter dokumentet peger på, eller splejse objekter fra en tidligere revision af den samme fil
Det selvstændige PDF MAC-token adresserer det lag. PDFiumPas udleder det fra filkrypteringsnøglen med et dedikeret 32-byte /KDFSalt, registreret i Encrypt-ordbogen, så besiddelse af adgangskoden er det, der lader en læser bekræfte tokenet. Resultatet er ét svar på ét spørgsmål: er dette dokument, som helhed, det dokument, der blev skrevet
var
Pdf: TPdf;
Mac: TPdfMacValidationResult;
begin
Pdf := TPdf.Create(nil);
try
Pdf.Password := 'open-secret';
Pdf.FileName := 'quarterly-report.enc.pdf';
Pdf.LoadDocument;
Mac := Pdf.ValidatePdfMac('open-secret');
case Mac.Status of
pmvsValid: ProcessDocument(Pdf);
pmvsNotPresent: ProcessWithWarning(Pdf); // intet token i denne fil
pmvsInvalid: Quarantine(Mac.MessageText); // manipuleret eller afkortet
pmvsUnsupported: RouteForManualReview(Mac.MessageText);
end;
finally
Pdf.Free;
end;
end;
De fire statusværdier kræver fire forskellige svar, og at sammenfolde dem til en boolsk mister den skelnen, der betyder noget. pmvsNotPresent betyder, at filen simpelthen ikke har noget token, hvilket beskriver næsten hver eneste krypterede PDF skrevet før 2024 og ikke er bevis for noget. pmvsInvalid betyder, at et token er til stede og ikke verificerer, hvilket er et reelt fund og bør stoppe behandlingen. pmvsUnsupported betyder, at tokenet findes i en form, denne build ikke implementerer, hvilket er et kompatibilitetshul, ikke et angreb. At behandle "ikke til stede" som "ugyldig" ville sætte hele dit tilbagekatalog i karantæne på dag ét
Hvad kryptering stadig ikke gør
Tilladelsesflag forbliver, hvad de altid har været: en anmodning til konform software, ikke en kontrol. /P-bittene fra ISO 32000-1 Tabel 22, der forbyder udskrivning eller udtrækning, respekteres af velopdragne viewere og ignoreres af alt andet, og enhver, der besidder brugeradgangskoden, besidder allerede det dekrypterede indhold. Kryptering er grænsen; tilladelser beskriver hensigt inden i den
To driftsmæssige detaljer er værd at planlægge for. For det første interagerer kryptering og senere modifikation: at tilføje en inkrementel opdatering til et krypteret dokument har sine egne regler, dækket i inkrementelle opdateringer på krypterede PDF'er, og et MAC-token er en dokumentniveau-erklæring, som en skødesløs tilføjelse vil invalidere. For det andet bruger GCM-konstruktionen en deterministisk IV-tæller, og PDFiumPas rejser en fejl frem for at genbruge en tællerværdi, hvis den plads nogensinde blev opbrugt, fordi nonce-genbrug i GCM er katastrofalt på en måde, en lydløs wraparound ville skjule
Valg mellem de tre revisioner i praksis
Skriv ned, hvem der åbner filen, og vælg derefter. Til intern distribution, hvor hver læser er en aktuel viewer under din kontrol, er R7 med integritetsbeskyttelse den stærkeste tilgængelige mulighed, og der er ingen grund til ikke at bruge den. Til dokumenter, der forlader organisationen, er R6 det forsvarlige standardvalg: det er standardiseret i ISO 32000-2 frem for i en teknisk specifikation oven på den, og understøttelsen er bred. Til arkiver og legacy-forbrugere er R5 det eneste valg, der pålideligt åbner, og du bør notere hvorfor det samme sted, du noterer resten af din opbevaringspolitik
Uanset hvad du vælger, så verificér outputtet frem for at stole på, at kaldet lykkedes. Genåbn den krypterede fil, tjek ValidatePdfMac, og bekræft, at den erklærede version er den, du forventer, ved hjælp af versionskonformitetstjekkene i præcis PDF-versionskonformitet. En bredere indtagelses-tjekliste for ubetroede dokumenter findes i audit af PDF-sikkerhedsrisici
PDFiumPas er en Delphi- og Lazarus-komponent omkring PDFium-motoren med PDF 2.0-krypteringsstakken implementeret nativt i Pascal, så AES-256, GCM og MAC-tokenet ikke kræver nogen ekstern krypto-DLL. Krypterings-API'en er dokumenteret på PDFium's produktside for Delphi-komponenten