- Key Takeaways
- Waarom digitale handtekeningen na verloop van tijd niet meer werken
- Wat PAdES en langetermijnvalidatie inhouden
- PAdES LTV in kaart brengen voor Enterprise Code Signing
- Waarom het nu belangrijk is: eIDAS 2.0 en digitale portemonnees van de EU
- De LTV-waarde goed bepalen: een praktische checklist
- Hoe encryptieconsultancy kan helpen
- Conclusie
- Veelgestelde Vragen / FAQ
Stel je een contract voor dat drie jaar geleden elektronisch is ondertekend. Het bestand kan nog steeds worden geopend en de handtekening ziet er nog steeds goed uit. Maar hier is een terechte vraag: zou je vandaag de dag nog kunnen bewijzen dat de handtekening geldig was op het moment van ondertekening? En zou je dat over tien jaar nog steeds kunnen bewijzen? Voor de meeste digitale handtekeningen is het eerlijke antwoord nee. Dat is precies het probleem dat PAdES (PDF Advanced Electronic Signatures) en Long-Term Validation (LTV) proberen op te lossen.
PAdES, gedefinieerd door de ETSI-norm EN 319 142, is de Europese standaard voor het toevoegen van digitale handtekeningen aan PDF-bestanden. LTV is het onderdeel van PAdES dat alles wat nodig is om een ​​handtekening te vertrouwen, zoals de certificaten, de intrekkingscontroles en een betrouwbare tijdstempel, direct in de PDF opslaat. Omdat al dit bewijs in het bestand is opgenomen, kan de handtekening jaren later nog steeds worden gecontroleerd, zelfs als de diensten die de handtekening oorspronkelijk hebben uitgegeven niet meer bestaan. Om te begrijpen waarom LTV nodig is, is het nuttig om eerst te bekijken waarom een ​​gewone digitale handtekening niet voor altijd betrouwbaar blijft.
PAdES is een standaard voor het ondertekenen van documenten, niet voor het ondertekenen van code; het beveiligt geen uitvoerbaar bestand, installatieprogramma of firmware-image. Maar codeondertekening in een bedrijfsomgeving kampt met precies hetzelfde probleem van langetermijnvalidatie waarvoor PAdES is ontwikkeld, en om dezelfde reden: een ondertekend document moet vaak jarenlang verifieerbaar blijven nadat het certificaat waarmee het is ondertekend, is verlopen. De rest van dit artikel gebruikt het LTV-model van PAdES als concrete illustratie van dat probleem en de oplossing ervan, en vertaalt dit vervolgens direct naar wat een codeondertekeningsprogramma moet doen.
Langetermijnvalidatie voor het ondertekenen van bedrijfssoftware, gedefinieerd als: het bewaren van de certificaatketen, de intrekkingsstatus en een betrouwbaar tijdstempel voor een ondertekend artefact op het moment van ondertekening. Hetzelfde principe dat PAdES LTV toepast op PDF's, zorgt ervoor dat firmware, installatieprogramma's en bedrijfssoftware met een levensduur van meerdere jaren verifieerbaar blijven, lang nadat de geldigheidsperiode van hun ondertekeningscertificaat is verlopen.
Key Takeaways
- PAdES en codeondertekening zijn verschillende standaarden voor verschillende soorten artefacten, maar ze hebben dezelfde faalmodus: een handtekening die afhankelijk is van externe intrekkings- en tijdstempelservices wordt onverifieerbaar zodra die services, of het certificaat zelf, niet meer beschikbaar zijn.
- Het equivalent van het B-LT-niveau van PAdES voor codeondertekening is een RFC 3161-vertrouwde tijdstempel die wordt toegepast op het moment van ondertekening; zonder deze vervalt het vertrouwen in een ondertekend artefact samen met het certificaat, doorgaans binnen 460 dagen volgens de huidige CA/Browser Forum-regels.
- Een QSCD (Qualified Signature Creation Device) in de PAdES/eIDAS-wereld voldoet functioneel aan dezelfde vereisten als een HSM bij codeondertekening: de privésleutel moet worden gegenereerd in gecertificeerde hardware en mag deze nooit verlaten.
- Voor een gedetailleerde beschrijving van de tijdstempel- en HSM-vereisten die specifiek zijn voor codeondertekening, zie Best practices voor codeondertekening in de SDLC en We hebben alle formaten geteld die CodeSign Secure kan ondertekenen..
Waarom digitale handtekeningen na verloop van tijd niet meer werken
Een digitale handtekening is gebaseerd op een publieke sleutelinfrastructuur (PKI) . De ondertekenaar beschikt over een privésleutel die gekoppeld is aan een digitaal certificaat , uitgegeven door een vertrouwde certificeringsinstantie . Door te ondertekenen wordt een unieke vingerafdruk van het document gecreëerd en met die sleutel vergrendeld, zodat iedereen met de bijbehorende publieke sleutel kan bevestigen dat het document ongewijzigd is gebleven. Dit werkt goed op de korte termijn, maar geen van de onderdelen is eeuwigdurend: certificaten verlopen na één tot drie jaar, certificeringsinstanties worden opgeheven, de online diensten die bevestigen dat een certificaat nog steeds betrouwbaar is, verdwijnen en na verloop van tijd wordt de onderliggende wiskunde gemakkelijker te kraken.
Wanneer dat gebeurt, loopt iedereen die jaren later de handtekening controleert tegen een probleem aan: ze kunnen niet bevestigen dat het certificaat geldig was toen het werd gebruikt, kunnen niet controleren of het later is ingetrokken en vertrouwen het algoritme mogelijk niet meer. Het document bestaat nog steeds, maar het bewijsmateriaal is verdwenen, wat een reëel en kostbaar risico vormt bij een geschil of een audit.
LTV maakt deze afhankelijkheid van externe diensten overbodig: het slaat al het bewijsmateriaal op in het document zelf op het moment van ondertekening en legt het exacte tijdstip van ondertekening vast, zodat de handtekening altijd als geldig wordt beschouwd vanaf die datum. Daarom blijft een LTV-handtekening geldig lang nadat het certificaat van de ondertekenaar is verlopen. Om te begrijpen hoe dit bewijsmateriaal wordt opgebouwd, is het nuttig om te kijken naar de structuur van PAdES.
Wat PAdES en langetermijnvalidatie inhouden
PAdES is een van de weinige in Europa erkende digitale handtekeningformaten en is de juiste keuze voor PDF-bestanden. Het werkt met verschillende niveaus, waarbij elk niveau meer bescherming biedt dan het vorige. U hoeft de technische termen niet te onthouden, maar het is wel de moeite waard om het principe achter elke stap te begrijpen.
PAdES definieert vier niveaus, die elk voortbouwen op het voorgaande. De onderstaande tabel laat zien wat elk niveau toevoegt en hoe lang de resulterende handtekening betrouwbaar is.
| PAdES-niveau | Wat het toevoegt | Hoe lang is het te vertrouwen? |
|---|---|---|
| BB (Basislijn) | De handtekening plus het certificaat van de ondertekenaar. | Alleen zolang het certificaat nog geldig is. |
| BT (Tijdstempel) | Een gekwalificeerde tijdstempel van een erkende vertrouwensdienstverlener (Qualified Trust Service Provider, QTSP) waaruit blijkt wanneer het document is ondertekend. | Het ondertekeningstijdstip wordt vastgesteld, maar de verificatie is nog steeds afhankelijk van het verkrijgen van certificaat- en intrekkingsinformatie uit externe bronnen. |
| B-LT (Langetermijn) | De volledige certificaatketen en intrekkingsgegevens zijn opgeslagen in het PDF-bestand. | Dit is direct te verifiëren aan de hand van het bestand zelf, zonder dat een externe dienst nodig is. |
| B-LTA (Langetermijn + Archivering) | Een cryptografische tijdstempeltoken die alle opgeslagen bewijzen verzegelt; verlengbaar voordat deze verloopt. | Tientallen jaren, mits de cryptografische tijdstempel volgens schema wordt vernieuwd. |
Als vuistregel geldt dat elk document dat langer dan een paar jaar geldig moet blijven, minimaal de langetermijnvalidatie moet hebben, en elk document dat tientallen jaren geldig moet blijven, de hoogste validatie moet hebben in combinatie met een verlengingsplan. Dit alles wordt steeds belangrijker vanwege nieuwe Europese regelgeving, waar we het nu over zullen hebben.
PAdES LTV in kaart brengen voor Enterprise Code Signing
De concepten zijn direct overdraagbaar, ook al verschillen de standaarden en bestandsformaten:
| PAdES / eIDAS Concept | Equivalent van codeondertekening |
|---|---|
| BT: gekwalificeerd tijdstempel bij ondertekening | RFC 3161 vertrouwde tijdstempel toegepast tijdens ondertekening. |
| B-LT: certificaatketen en intrekkingsgegevens opgeslagen in het bestand | Certificaatketen verpakt met de handtekening; intrekking gecontroleerd via CRL/OCSP tijdens verificatie. |
| B-LTA: archiveringstijdstempel, volgens schema vernieuwd | Er bestaat nog geen direct equivalent in de meeste tools voor codeondertekening, wat een groot gemis is voor firmware met een levensduur van meer dan 10 jaar. |
| QSCD (Qualified Signature Creation Device) | HSM voldoet aan FIPS 140-2 niveau 2+ (vereist voor alle publiekelijk vertrouwde codeondertekeningscertificaten sinds juni 2023) |
| Crypto-flexibiliteit voor post-kwantummigratie | Dezelfde vereiste: ondersteuning voor ML-DSA (FIPS 204), SLH-DSA (FIPS 205) of LMS/XMSS zonder een volledige heropbouw van de pipeline. |
Het is belangrijk om dit probleem expliciet te benoemen: de B-LTA-archiveringsfunctie van PAdES, die het zegel op een document vernieuwt voordat het eigen tijdstempel verloopt, heeft geen breed geaccepteerd equivalent in de huidige tools voor codeondertekening. Voor firmware en bedrijfssoftware met een levensduur van tientallen jaren is dit een reëel risico: een RFC 3161-tijdstempel zorgt ervoor dat een handtekening geldig blijft na het verlopen van het certificaat, maar de meeste workflows voor codeondertekening vernieuwen dat tijdstempel niet voordat de certificaatketen van de tijdstempelautoriteit uiteindelijk ook verloopt. Beschouw dit als een open operationele vraag waarvoor planning nodig is, niet als een opgelost probleem.
Waarom het nu belangrijk is: eIDAS 2.0 en digitale portemonnees van de EU
De Europese eIDAS-verordening stelt de regels vast voor elektronische handtekeningen; de bijgewerkte eIDAS 2.0 is sinds 2024 van kracht en introduceert de digitale identiteitswallet van de EU, die elke EU-lidstaat uiterlijk eind 2026 beschikbaar moet stellen op grond van Verordening (EU) 2024/1183. Dit is een ontwikkeling op het gebied van document- en identiteitsondertekening, niet op het gebied van codeondertekening, maar het is om één reden de moeite waard om te kennen: het leidt tot een sterke toename van het aantal langdurig ondertekende documenten die tientallen jaren verifieerbaar moeten blijven. Dezezelfde druk zorgt er ook voor dat codeondertekening steeds meer een vergelijkbare discipline van langetermijnvalidatie vereist.
De meest direct relevante druk voor codeondertekening komt voort uit de transitie naar het post-kwantumtijdperk. Kwantumveilige ondertekeningsalgoritmen zijn al gestandaardiseerd, waaronder ML-DSA (FIPS 204) en SLH-DSA (FIPS 205), die in augustus 2024 door NIST zijn afgerond. Code die tot ver na 2030 verifieerbaar moet blijven, moet daarom nu al worden ontwikkeld met het oog op cryptografische flexibiliteit.
Voor het ondertekenen van software en firmware stelt de NSA's CNSA 2.0- suite een strengere deadline: leveranciers moeten post-kwantumalgoritmen ondersteunen en prefereren tegen 2025 en deze exclusief gebruiken tegen 2030. De suite keurt ML-DSA en de hash-gebaseerde LMS /XMSS (NIST SP 800-208) goed voor ondertekening, maar niet SLH-DSA. Dit alles weten is één ding; het in de praktijk goed doen is iets anders. De onderstaande checklist vat de belangrijkste gewoonten samen die een handtekening daadwerkelijk geldig houden.
De LTV-waarde goed bepalen: een praktische checklist
De meeste gebroken digitale handtekeningen falen om gewone, vermijdbare redenen, niet door exotische cryptografie. Dit zijn de gewoonten die ervoor zorgen dat een digitale handtekening op de lange termijn verifieerbaar blijft:
- Teken minimaal op het lange termijnniveau (B-LT) en gebruik B-LTA voor alles wat tientallen jaren moet meegaan.
- Gebruik een gekwalificeerde tijdstempelservice (QTSP)En voeg de tijdstempel toe op het moment van ondertekening, nooit achteraf.
- Bewaar de intrekkingsgegevens (OCSP of CRL) in de PDF; controleer het niet slechts één keer en gooi het vervolgens weg.
- Bewaar ondertekeningssleutels in een Qualified Signature Creation Device (QSCD), doorgaans een gecertificeerd apparaat. hardwarebeveiligingsmodule (HSM), zoals vereist voor gekwalificeerde handtekeningen.
- Vernieuw de archiveringstijdstempels voordat ze verlopen, want een gemiste vernieuwing kan later niet meer worden hersteld.
- Maak een ondertekend PDF-bestand nooit plat of sla het nooit opnieuw op in een programma dat geen rekening houdt met handtekeningen, omdat dit het bestand ongemerkt kan beschadigen.
- Ontwikkeld voor crypto-flexibiliteit, zodat de huidige algoritmes kunnen worden geüpgraded naar kwantumveilige algoritmes zonder helemaal opnieuw te hoeven beginnen.
Op zichzelf is dit allemaal niet moeilijk. De uitdaging zit hem in het consequent uitvoeren ervan, in elk ondertekeningsproces en jarenlang. Dat is waar externe expertise zijn waarde bewijst.
Hoe encryptieconsultancy kan helpen
Dit is precies waarvoor CodeSign Secure van Encryption Consulting is ontworpen. Het ondertekent documenten en code met privésleutels die worden gegenereerd en opgeslagen in een FIPS 140-2 Level 3 HSM en deze nooit verlaten. Bovendien worden er op het moment van ondertekening beveiligde tijdstempels volgens RFC 3161 toegevoegd, dezelfde basis waarop validatie op de lange termijn is gebaseerd. Voordat een handtekening wordt geplaatst, valideert het platform de integriteit van wat er wordt ondertekend. Elke ondertekeningsactie wordt beheerd door op rollen gebaseerde toegangscontrole, M-van-N-quorumgoedkeuringen en een volledig ondertekend auditspoor. Zo kunt u niet alleen bewijzen dat een bestand is ondertekend, maar ook precies wanneer, door wie en onder welk beleid.
CodeSign Secure is ook ontworpen voor de lange termijn waar deze blog over gaat. Het biedt native ondersteuning voor post-quantumtechnologie , inclusief de ML-DSA- en LMS-handtekeningalgoritmen (Leighton-Micali Signature, NIST SP 800-208), en biedt hybride ondertekening die een klassiek algoritme combineert met een quantumveilig algoritme. Hierdoor blijven handtekeningen die vandaag worden aangemaakt betrouwbaar, ook als de standaarden veranderen. Het draait on-premises, in de cloud of als een hybride implementatie en integreert met toonaangevende HSM's en uw bestaande CI/CD-pipelines. Of u zich nu voorbereidt op de uitrol van de EU Digital Identity Wallet of een archief van ondertekende documenten voor de lange termijn wilt beveiligen, CodeSign Secure biedt u één verifieerbare plek om met vertrouwen te ondertekenen.
Conclusie
Een handtekening die je later niet kunt bewijzen, is in feite geen handtekening waarop je kunt vertrouwen. PAdES en LTV dichten die kloof door al het bewijsmateriaal, de certificaten, de intrekkingscontroles, de tijdstempels en het archiveringszegel in de ondertekende PDF op te slaan. Daardoor wordt een kwetsbaar bestand iets dat tientallen jaren geldig blijft.
Nu eIDAS 2.0 en de digitale identiteitsportefeuilles van de EU het mogelijk maken voor miljoenen mensen om gekwalificeerd te ondertekenen, zal het aantal langdurig ondertekende documenten snel toenemen. Organisaties die geen LTV (Long-Term Value) in hun ondertekeningsproces hebben ingebouwd, lopen een steeds groter juridisch risico naarmate de handtekeningen in hun oudere documenten niet meer als betrouwbaar worden beschouwd.
De weg vooruit is duidelijk, en de bovenstaande checklist vat die samen: onderteken op de lange termijn, bewijs het tijdstip van ondertekening, bewaar het bewijs in het bestand en wees bereid om tijdstempels te vernieuwen en cryptografie te upgraden wanneer standaarden veranderen. Doe dat, en uw handtekeningen blijven geldig lang nadat ze zijn aangemaakt.
Wilt u uw eigen ondertekeningsconfiguratie toetsen aan deze punten, of bent u van plan de digitale identiteitswallet van de EU te gebruiken? Neem dan contact met ons op voor technisch advies.
Veelgestelde Vragen / FAQ
Wordt PAdES gebruikt voor het ondertekenen van code?
Nee. PAdES (ETSI EN 319 142) is een standaard voor het ondertekenen van PDF-documenten, niet voor uitvoerbare bestanden, installatieprogramma's of firmware. Het is alleen relevant voor codeondertekening als model, aangezien beide met hetzelfde probleem te maken hebben: het behouden van een verifieerbare handtekening nadat het certificaat is verlopen.
Wat is het equivalent van het B-LT-niveau van PAdES op het gebied van codeondertekening?
Een RFC 3161-vertrouwenstijdstempel wordt toegepast tijdens het ondertekenen, in combinatie met de certificaatketen die bij de handtekening is inbegrepen. Zonder het tijdstempel vervalt het vertrouwen in een ondertekend document samen met het certificaat.
Heeft codeondertekening een equivalent van PAdES's archiveringshernieuwde tijdstempeling (B-LTA)?
Tegenwoordig wordt het nog niet veel gebruikt. Dit is een reële lacune voor firmware en bedrijfssoftware met een levensduur van tientallen jaren, aangezien de meeste codeondertekeningsworkflows geen tijdstempel opnieuw verzegelen voordat de certificaatketen uiteindelijk verloopt. Houd hier rekening mee in plaats van aan te nemen dat het probleem is opgelost.
Is een QSCD hetzelfde als een HSM?
Functioneel gezien wel, voor dit doel. Een QSCD is de eIDAS-specifieke certificering voor het apparaat dat een gekwalificeerde ondertekeningssleutel bevat; een HSM die voldoet aan FIPS 140-2 Level 2+ vervult dezelfde rol bij het ondertekenen van code en is sinds juni 2023 vereist voor alle publiekelijk vertrouwde certificaten voor het ondertekenen van code.
- Key Takeaways
- Waarom digitale handtekeningen na verloop van tijd niet meer werken
- Wat PAdES en langetermijnvalidatie inhouden
- PAdES LTV in kaart brengen voor Enterprise Code Signing
- Waarom het nu belangrijk is: eIDAS 2.0 en digitale portemonnees van de EU
- De LTV-waarde goed bepalen: een praktische checklist
- Hoe encryptieconsultancy kan helpen
- Conclusie
- Veelgestelde Vragen / FAQ
