For at sikre, at en signeret PDF kan verificeres om mange år, efter at signeringscertifikatet er udløbet, og dets CA er skiftet (roteret), kan PDFium-komponenten producere langsigtede PAdES-signaturer på Windows: Et RFC 3161-tidsstempel for pålidelig tid, et Document Security Store (DSS) der indlejrer valideringsmaterialet, og et arkiv-DocTimeStamp over hele filen. Disse tre tilføjelser udgør PAdES-basisniveauerne B-T, B-LT og B-LTA, og PDFium-komponenten når dem alle fra et enkelt signeringskald. Dette er en Windows-kun funktion, der er beskyttet af PadesCryptoAvailable
Denne artikel er den tredje i en serie. Den første, signering af PDF-filer med PAdES B-B ved hjælp af PDFium VCL, dækker den grundlæggende signatur; den anden, undersøgelse af digitale PDF-signaturer og PAdES-niveauer, dækker læsning af en signatur og bestemmelse af, hvilket niveau den nåede. Her er fokus på arkivet: Signaturer, der skal overleve certifikatudløb og forblive verificerbare i en opbevaringsperiode målt i år, ikke uger
Hvorfor holder en gyldig PDF-signatur op med at kunne verificeres over tid?
En grundlæggende signatur besvarer kun ét spørgsmål: Blev disse bytes ændret efter signeringen. Den beviser ikke i sig selv, hvornår signeringen fandt sted, og det er dette hul, der bryder den senere. CMS-strukturen bærer en attribut for signeringstidspunkt, men signatøren skriver den værdi ud fra sit eget ur, så en valideringsfunktion har ingen grund til at stole på den. Når signeringscertifikatet senere udløber, eller CA'en tilbagekalder det, kan en valideringsfunktion ikke længere skelne mellem en signatur lavet, mens certifikatet var gyldigt, og en forfalsket efter, at det udløb. Signaturen var fin den dag, den blev lavet, og bliver uverificerbar uden egen skyld
Langsigtet arkivering løser dette i to trin
Langsigtet arkivering løser dette i to trin. For det første bekræfter en betroet tredjepart, en tidsstempelmyndighed (TSA), tidspunktet kryptografisk, så det ikke længere afhænger af signatørens ærlighed. For det andet indlejres alle certifikater, tilbagekaldelsessvar (revocation responses) og CRL'er, der er nødvendige for at opbygge og kontrollere tillidskæden, inde i selve PDF-filen, så valideringen ikke afhænger af servere, der kan være væk, når nogen kigger. PAdES, standardiseret som ETSI EN 319 142-1, opdeler disse i basisniveauer (baseline levels), og PDFium-komponenten skriver de strukturer, som hvert niveau kræver
Hvad er en LTV- eller arkivtidsstemplet PDF-signatur?
PAdES definerer fire basisniveauer, der bygger på hinanden, og PDFium-komponenten eksponerer dem via typen TPadesLevel (plB_B, plB_T, plB_LT, plB_LTA). B-B er den rene signatur. B-T tilføjer et betroet tidsstempel over signaturværdien. B-LT (langtids) tilføjer det indlejrede valideringsmateriale, hvilket er den egenskab, de fleste mener med "LTV". B-LTA (langtids med arkivtidsstempel) pakker alt ind i endnu et tidsstempel, der dækker hele filen, så det indlejrede materiale i sig selv beviseligt er intakt fra arkiveringstidspunktet
Den praktiske forståelse er en trappe. B-T beviser hvornår. B-LT beviser med hvad signaturen stadig kan kontrolleres. B-LTA beviser, at hele pakken ikke er blevet manipuleret, siden den blev forseglet, og det er det niveau, du fornyer ved at tilføje et nyt DocTimeStamp, før det foregående udløber, for at forlænge arkivet på ubestemt tid. For en kontrakt eller en compliance-post med en lang opbevaringspligt er B-LTA målet; B-LT er det pragmatiske minimum
Tilføjelse af pålidelig tid: PAdES B-T med RFC 3161
PDFium-komponenten forvandler en B-B-signatur til B-T ved at indstille to felter i TPadesSignOptions: Hæv Level til plB_T og angiv en TsaUrl. Når begge er til stede, hasher signerings-pipelinen de rå signatur-okteter med SHA-256, pakker denne digest som RFC 3161 messageImprint, sender anmodningen (POST) til TSA'en via WinHttp og indlejrer det returnerede token som den usignerede attribut signature-time-stamp (OID 1.2.840.113549.1.9.16.2.14) i SignerInfo'ens unsignedAttrs [1] i henhold til EN 319 142-1 §6.3. Tidsstemplet dækker specifikt signaturværdien, hvilket er det, der binder den pålidelige tid til netop denne signatur
CertificateThumbprint er SHA-1-hashen (i hex) for et certifikat i den aktuelle brugers "MY"-lager, hvis private nøgle du kan bruge. Feltet Nonce er RFC 3161-værdien til forhindring af genafspilning (anti-replay); lad det være nul, og komponenten udleder en unik værdi pr. anmodning ud fra en SHA-256-sammensmeltning af en tæller, uret, tick-tælleren og proces-id'et, så to anmodninger udstedt i samme millisekund ikke kolliderer. Angiv kun din egen værdi, hvis du har en kryptografisk RNG, du hellere vil stole på. Én ærlig advarsel: B-T kræver en tilgængelig TSA, så signering foretager nu et netværkskald og arver TSA'ens tilgængelighed og svartid
Indlejring af valideringsmateriale: B-LT og B-LTA i ét kald
Trinnet op til langsigtet validering er en enkelt ændring: Indstil Level til plB_LTA og behold TsaUrl. PDFium-komponenten kører derefter hele trappen i et enkelt SignPades-kald. Den signerer B-B, tidsstempler for B-T, injicerer Document Security Store (DSS) for B-LT og tilføjer arkivtidsstemplet for B-LTA, hver som sin egen trinvise opdatering (incremental update), så de tidligere bytes forbliver byte-for-byte intakte
Til B-LT-fasen opbygger PDFium-komponenten certifikatkæden med CertGetCertificateChain og skriver en /DSS-ordbog, der bærer signeringscertifikatet samt alle mellemliggende CA'er i et /Certs-array (med parallelle /OCSPs- og /CRLs-arrays) sammen med en /Extensions /ESIC-markør på Level 1, præcis som foreskrevet i EN 319 142-1 §5.4.2. Den selvsignerede rod er bevidst udeladt, da RFC 5652 §10.2.3 tillader det, og roden i forvejen er et tillidsanker, som valideringsfunktionen besidder. Resultatet er en signatur, som en læser kan verificere med intet andet end selve filen i hånden
Til B-LTA tilføjer komponenten et Document Time-stamp: En signaturordbog med /SubFilter /ETSI.RFC3161, hvis /ByteRange spænder over hele filen, hvor dens /Contents indeholder et RFC 3161-token over dette område, og den fremmer ESIC-markøren til Level 2. Dette er arkiveringstrinnet i henhold til §5.4.3 og TS 119 142-3. Da DocTimeStamp dækker både DSS'en og signaturen, beviser det, at det indlejrede valideringsmateriale var til stede og uændret på arkiveringstidspunktet, hvilket er præcis, hvad en langsigtet opbevaringspolitik skal kunne vise
Udbygning af en eksisterende signatur
Undertiden er signaturen allerede placeret på dokumentet, og du har kun brug for at tilføje eller opdatere valideringslageret, for eksempel for at bringe en tredjeparts B-B-signatur op på B-LT-niveau til dit arkiv. PDFium-komponenten eksponerer DSS-injektoren direkte via SaveAsPadesDss, som tilføjer /DSS- og /Extensions-strukturerne som en trinvis opdatering uden at røre ved de eksisterende signatur-bytes
Du leverer de DER-kodede certifikater, og eventuelt OCSP-svar og CRL'er, som en valideringsfunktion har brug for. Indstil EsicExtensionLevel til 1 for et B-LT-lager eller 2, når et DocTimeStamp følger efter. Lad IncludeVri beholde sin standardværdi False: EN 319 142-1 §5.4.2.3 behandler ordbogen /VRI pr. signatur som valgfri og fraråder den, medmindre en bestemt læser, du målretter mod, kræver det
Omkostninger og grænser, der er værd at planlægge efter
Tre reelle begrænsninger bestemmer, hvor disse niveauer passer ind. For det første er den kryptografiske backend kun til Windows: Signering og tidsstempling sker gennem platformens CNG- og WinHttp-lagre, så PadesCryptoAvailable returnerer False andre steder, og SignPades udløser fejl. Den skrivebeskyttede inspektion, der er dækket i ledsageartiklen, forbliver dog platformsafhængig; kun skrivningen af signaturer er bundet til Windows
For det andet afhænger B-T og B-LTA af en tidsstempelmyndighed (TSA), hvilket betyder en netværks-tidsrejse (round trip) på signeringstidspunktet og en ekstern tjeneste, hvis oppetid og hastighedsgrænser bliver en del af din signeringssti
For det tredje koster hvert niveau lagerplads. Hvert trin tilføjer en trinvis opdatering i stedet for at omskrive filen, DSS'en indlejrer en fuld certifikatkæde, og arkiv-DocTimeStamp reserverer plads til sit token, så en B-LTA-fil er væsentligt større end den oprindelige B-B. Det er et bevidst valg: Du bruger bytes nu for at købe verificerbarhed senere. For de fleste kontrakt- og compliance-arkiver er det det rigtige valg, men det er værd at måle på dine egne dokumenter frem for at antage det. Når du har brug for at bekræfte, at en færdig fil faktisk nåede det niveau, du havde til hensigt, kan du verificere den med teknikkerne i inspektion af digitale PDF-signaturer og PAdES-niveauer, og hvis du sikrer en dokumentpipeline bredere, dækker noterne om revision af PDF-sikkerhedsrisici de tilhørende kontroller
De funktioner til PAdES-signering, DSS og arkivtidsstempling, der er vist her, er en del af PDFium-komponenten til Delphi og C++Builder, hvis produktside indeholder den fulde signeringsreference og platformskrav