Forside › Analyse og fortolkning · Gennemgået oktober 2026 · Af John Nielsen
En digital signatur i en PDF beviser, at et bestemt byteområde af filen ikke er ændret, siden det blev signeret med en bestemt nøgle. Om signaturen er gyldig, afhænger af tre ting: om de signerede bytes stadig passer med signaturen, om certifikatet kan føres tilbage til en betroet udsteder og var gyldigt på signeringstidspunktet, og om det, der er tilføjet efter signeringen, er tilladt. Det grønne flueben i en PDF-læser er en sammenfatning af disse kontroller, ikke et bevis i sig selv.
Den juridiske side af elektroniske signaturer og aftaler er beskrevet på Digitale signaturer og elektroniske aftaler som bevis. Her handler det om, hvad der teknisk ligger i filen, og hvordan det efterprøves. Signaturløsningens egen log over forløbet er beskrevet i Audit trail i e-signaturløsninger.
Hvad der ligger i filen
En signatur i en PDF er et formularfelt, der peger på en signaturordbog. De vigtigste elementer er:
ByteRange· De byteintervaller i filen, som signaturen dækker. Normalt hele filen på signeringstidspunktet undtagen selve signaturværdienContents· Selve signaturen som en CMS-struktur med signerens certifikat og ofte hele kædenSubFilter· Signaturformatet, fx en PKCS#7-baseret eller en CAdES-baseret variantM· Signeringstidspunktet, som signerens eget system har angivetReferenceogDocMDP· Ved certificeringssignaturer: hvilke ændringer der er tilladt bagefter
Når en læser kontrollerer signaturen, beregner den hashværdien af de bytes, ByteRange angiver, og sammenligner med den hashværdi, der er signeret i Contents. Passer de, er de dækkede bytes uændrede.
Ændringer efter signering
PDF-formatet tillader inkrementelle opdateringer, hvor nye objekter tilføjes i slutningen af filen. Det er nødvendigt, for ellers kunne et dokument ikke signeres af flere personer. Men det betyder også, at filen kan indeholde mere end det, der blev signeret. De generelle tegn på inkrementelle opdateringer er beskrevet i Dokumentforfalskning i Office og PDF.
For en signeret fil skal man derfor kontrollere:
- Dækker
ByteRangehele den version, der blev signeret? Ender det dækkede område ved en EOF-markering, og er der bytes efter den? - Hvad er tilføjet bagefter? Yderligere signaturer, formularudfyldning og kommentarer kan være tilladt. Ændret sideindhold, nye sider eller ændrede skrifttyper er noget andet.
- Hvad tillod den første signatur? En certificeringssignatur med
DocMDPangiver et niveau: ingen ændringer, kun formularudfyldning og signering, eller også kommentarer.
Den signerede version kan genskabes ved at læse filen frem til slutningen af ByteRange og gemme den som en selvstændig fil. Den version er det, signaturen faktisk dækker, og den kan sammenlignes visuelt og strukturelt med den samlede fil.
Forskning fra Ruhr-Universität Bochum har vist, at flere udbredte PDF-læsere har haft svagheder i, hvordan de vurderer tilføjelser efter signering. Producenterne har rettet mange af dem, men resultatet afhænger stadig af program og version. Validér derfor med mere end ét værktøj, og læs strukturen direkte, når resultatet er afgørende.
Certifikatkæden
En gyldig hashsammenligning siger kun, at bytes passer med en nøgle. Hvem nøglen tilhører, afgøres af certifikatet:
- Kæden fra signerens certifikat over mellemliggende udstedere til et rodcertifikat skal kunne bygges og valideres.
- Tillidsankeret er det, der afgør, om roden er betroet. Det kan være EU’s tillidslister, en PDF-læsers egen liste eller styresystemets certifikatlager. Forskellige ankre kan give forskellige resultater for samme fil.
- Gyldighed på tidspunktet. Certifikatet skal have været gyldigt og ikke tilbagekaldt, da signaturen blev lavet. Det kontrolleres med tilbagekaldelseslister (CRL) eller OCSP-svar.
- Formål. Certifikatet skal være udstedt til signering, og feltet for nøgleanvendelse skal passe.
Mange danske signeringstjenester signerer eller forsegler dokumentet med tjenestens eget certifikat og vedlægger et revisionsspor over, hvem der har godkendt hvad. Så er det tjenestens forsegling, der kan valideres kryptografisk, mens den enkelte persons identifikation fremgår af revisionssporet. Det skal holdes adskilt i en vurdering.
Tidsstempling
Feltet M er det tidspunkt, signerens computer oplyste. Det kan være forkert, og det er ikke beskyttet af nogen uafhængig part. Et kryptografisk tidsstempel fra en tidsstemplingstjeneste (efter RFC 3161) er derimod et selvstændigt signeret bevis for, at signaturværdien fandtes på et bestemt tidspunkt.
- Signaturtidsstempel ligger inde i signaturen og dækker signaturværdien.
- Dokumenttidsstempel er en særlig signatur over hele dokumentet, typisk brugt til langtidsbevaring.
Ved validering kontrolleres også tidsstemplingstjenestens certifikat og kæde. Den juridiske betydning af et kvalificeret tidsstempel er beskrevet i Kvalificeret tidsstempel.
Langtidsvalidering (LTV)
Certifikater udløber, og tilbagekaldelsesservere lukker. En signatur, der var gyldig i 2020, kan derfor vise sig som “ukendt” i dag, hvis valideringsdataene ikke længere kan hentes. Langtidsvalidering løser det ved at gemme certifikater, tilbagekaldelsesdata og tidsstempler i filen, typisk i en Document Security Store, og eventuelt forsegle det med et dokumenttidsstempel.
Basisprofilerne i ETSI EN 319 142-1 hedder B-B (grundlæggende signatur), B-T (med tidsstempel), B-LT (med indlejrede valideringsdata) og B-LTA (med dokumenttidsstempel til langtidsarkivering). Niveauerne er tekniske og siger ikke i sig selv, om signaturen juridisk er simpel, avanceret eller kvalificeret. Den juridiske side er beskrevet i Digitale signaturer og elektroniske aftaler som bevis.
Indlejrede valideringsdata er i sig selv et spor. OCSP-svar og tilbagekaldelseslister har deres egne udstedelsestidspunkter, og et dokumenttidsstempel lagt oven på signaturen viser, hvornår valideringsdataene senest blev forseglet. Sammenholdt med signaturtidsstemplet kan det give en ret præcis tidsramme for, hvornår filen fik sin nuværende form.
For en undersøgelse betyder det, at valideringsresultatet afhænger af valideringstidspunktet og af, om valideringsdata findes i filen. Rapportér begge dele.
Sikring
- Sikr den originale fil, som den blev modtaget eller hentet fra signeringstjenesten, med hashværdi straks. En PDF, der er åbnet og gemt i en læser, kan have fået en ny inkrementel opdatering.
- Hent revisionssporet eller kvitteringen fra signeringstjenesten særskilt, og sikr eventuelle mails med notifikationer, som er sendt i forbindelse med signeringen.
- Notér valideringsværktøj, version, tillidsliste og tidspunkt for hver validering. Et resultat uden disse oplysninger kan ikke gentages.
Se Hashalgoritmer om algoritmevalg og Mail-headere om de tilhørende mails.
Typiske fejlkilder
- “Gyldig” læst som “ægte indhold”. En gyldig signatur dækker det signerede byteområde. Indhold tilføjet bagefter skal vurderes for sig.
- “Ukendt” læst som “falsk”. Manglende tillid til roden eller manglende tilbagekaldelsesdata gør ikke signaturen ugyldig. Det betyder, at den ikke kunne valideres fuldt i det miljø.
- Feltet M som sandhed. Uden tidsstempel er signeringstidspunktet kun signerens eget ur.
- Indscanning eller udskrift. En udskrevet og indscannet kopi har ingen digital signatur, uanset hvordan signaturfeltet ser ud på papiret.
- Billede af en underskrift. Et indsat billede af en håndskrevet underskrift er ikke en digital signatur.
- Valideringstidspunktet glemt. Samme fil kan give forskellige resultater i dag og om et år, fordi tillidslister og tilbagekaldelsesdata ændrer sig. Et resultat skal altid dateres.
Hvad valideringen kan og ikke kan bevise
En gyldig signatur med gyldig kæde og tidsstempel viser med høj sikkerhed, at det signerede indhold fandtes på tidspunktet og er signeret med den pågældende nøgle. Den viser ikke, hvem der havde nøglen i hånden, om personen forstod indholdet, eller at der ikke findes andre versioner af aftalen. Det kræver revisionsspor, logs fra signeringstjenesten og andre kilder.
I rapporten
Beskriv for hver signatur: signaturfelt, ByteRange, signaturformat, certifikatkæde med serienumre, tilbagekaldelsesstatus, tidsstempel og tidsstemplingstjeneste, tilladte ændringer og de faktiske tilføjelser efter signering. Angiv valideringsværktøj, version og tillidsliste. Se Rapportskrivning.
Kilder og versioner
- ETSI EN 319 142-1: PAdES, basisprofiler
- PDF Insecurity: forskning i signaturvalidering
- RFC 3161: Time-Stamp Protocol
Senest gennemgået: oktober 2026.
Næste skridt
- Hvornår er billedet taget? EXIF, XMP og IPTC forklaret
- Metadata, der forsvinder ved upload og deling
- Falske chatbilleder: verifikation mod kildeenheden og appens database
Del af: Analyse og fortolkning
Læs også: Videometadata: MP4/MOV-strukturer og optagetid · Excel i undersøgelser: skjulte ark, formler, eksterne links og ændringer
→ Teknisk undersøgelse af dokumenter og metadata · For sagkyndige · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT