- Kort antwoord: Wat is vertrouwen nu, smeden later?
- De kernlogica van vertrouwen nu, smeden later.
- Stapsgewijs mechanisme: Hoe het smeden tot stand komt
- Waarom is dit een aansprakelijkheidsramp?
- Verschil tussen TNFL en HNDL
- Uw checklist om TNFL te beperken
- TNFL-risico en -beperking: een PKI-gecentreerd perspectief
- Hoe kan Encryption Consulting u helpen?
- Conclusie
- Veelgestelde Vragen / FAQ
In de huidige haast om het kwantumtijdperk te beveiligen, gaat de meeste aandacht uit naar de bedreiging van de vertrouwelijkheid: tegenstanders stelen vandaag de dag versleutelde gegevens om deze te decoderen zodra kwantumcomputers krachtig genoeg zijn. Die dreiging is reëel. Maar er is een tweede, wellicht nog gevaarlijkere kwantumdreiging die op de achtergrond opereert bij elke implementatie van een Public Key Infrastructure (PKI). Deze wordt Trust Now, Forge Later (TNFL) genoemd en tast niet de vertrouwelijkheid van uw gegevens aan, maar de integriteit van uw identiteit. Wanneer een cryptografisch relevante kwantumcomputer (CRQC) arriveert, kan elke RSA- of ECDSA-publieke sleutel die momenteel publiekelijk beschikbaar is, worden gebruikt om de bijbehorende privésleutel af te leiden. Dit stelt een aanvaller in staat om handtekeningen te vervalsen die teruggedateerd zijn naar elk willekeurig moment in het verleden. De aanbevolen actie: stel nu een complete cryptografische inventaris op van alle ondertekeningssleutels, geef prioriteit aan Root CA- en code-ondertekeningssleutels voor een zo snel mogelijke migratie naar door NIST goedgekeurde kwantumresistente ondertekeningsalgoritmen (FIPS 204 ML-DSA, FIPS 205 SLH-DSA) en implementeer kortere certificaatlevensduren om de bruikbare periode van elke vastgelegde sleutel te beperken. Voor de aanvullende bedreiging van de vertrouwelijkheid, zie 'Hoogst nu, decodeer later: Voorbereiding op de kwantumdreiging' . Voor de cryptografische ontdekkingsmethodologie die aan beide verdedigingsmechanismen ten grondslag ligt, zie 'Je kunt niet beveiligen wat je niet kunt zien'.
Kort antwoord: Wat is vertrouwen nu, smeden later?
Trust Now, Forge Later (TNFL) is een aanval uit het kwantumtijdperk waarbij een aanvaller vandaag de dag publiekelijk beschikbare RSA- of ECDSA-sleutels en digitale handtekeningen verzamelt , wacht tot een kwantumcomputer die het algoritme van Shor uitvoert de bijbehorende privésleutel kan afleiden, en vervolgens handtekeningen vervalst die wiskundig niet te onderscheiden zijn van die van de oorspronkelijke sleutelhouder. TNFL vereist geen actieve onderschepping in het heden, omdat publieke sleutels al zijn ingebed in elk TLS-certificaat, elk codeondertekeningscertificaat, elke firmwarevalidatieketen en elke root CA-vertrouwensopslag. De aanval ondermijnt de niet-afwijzing: zodra een aanvaller de privésleutel in handen heeft, kunnen noch u, noch enig verificatiesysteem bewijzen dat u geen vervalste handtekening hebt geproduceerd. TNFL onderscheidt zich van HNDL doordat het de integriteit en niet-afwijzing aanvalt in plaats van de vertrouwelijkheid, en het vereist vandaag de dag geen enkele inspanning om gegevens te verzamelen.
De kernlogica van vertrouwen nu, smeden later.
Momenteel gebruiken we RSA en ECC om alles te ondertekenen, van digitale handtekeningen tot software-updates. Deze handtekeningen zijn wiskundig gezien vandaag de dag onmogelijk te vervalsen. Maar een cryptografisch relevante kwantumcomputer verandert die berekening volledig. Een tegenstander kan een bestaande publieke sleutel nemen, het algoritme van Shor erop toepassen en de bijbehorende privésleutel afleiden. Zodra ze die privésleutel in handen hebben, bezitten ze niet alleen een huidige identiteit; ze bezitten elke handtekening die ooit met die sleutel is gegenereerd, en ze kunnen nieuwe handtekeningen genereren die niet te onderscheiden zijn van handtekeningen die de oorspronkelijke sleutelhouder had kunnen genereren, inclusief handtekeningen met een datum in het verleden.
Wanneer een aanvaller vandaag de dag een publieke sleutel of een ondertekend document bemachtigt, verkrijgt hij daarmee een bevroren identiteit. De reden waarom dit zo gevaarlijk is, is dat het de niet-afwijzing volledig ondermijnt: het principe dat als een handtekening geldig is, de ondertekenaar niet kan ontkennen dat hij deze heeft geplaatst. Wanneer handtekeningen met perfecte wiskundige geldigheid kunnen worden vervalst, kun je niet langer bewijzen dat je iets niet hebt ondertekend. Dat is de aansprakelijkheidsramp die centraal staat in TNFL.
Stapsgewijs mechanisme: Hoe het smeden tot stand komt
In tegenstelling tot HNDL, waarbij een aanvaller actief enorme hoeveelheden versleuteld verkeer moet onderscheppen en opslaan, vereist TNFL momenteel geen enkele inspanning. Hieronder volgt een stapsgewijze beschrijving van hoe deze aanval zich in de loop der tijd ontvouwt.
Fase 1: Het vertrouwen (vindt nu plaats)
Publieke sleutels zijn geen geheimen; ze zijn bedoeld om wereldwijd beschikbaar te zijn. Elk TLS-certificaat, elk codeondertekeningscertificaat, elke firmwarevalidatieketen en elk rootcertificaat dat in besturingssystemen is ingebed, bevat materiaal met publieke sleutels. Een aanvaller hoeft deze publieke sleutels tegenwoordig alleen maar te registreren. RSA is gebaseerd op de moeilijkheid om grote getallen te ontbinden in factoren, terwijl ECC gebaseerd is op het probleem van de discrete logaritme op elliptische krommen. In beide gevallen is de publieke sleutel wiskundig gekoppeld aan de privésleutel. Alle informatie die nodig is om de privésleutel af te leiden, is aanwezig, maar zit verborgen achter een berekening die klassieke computers een onhaalbare tijd zou kosten. Een kwantumcomputer die het algoritme van Shor uitvoert, heft die blokkade op.
Fase 2: De kwantumberekening
Zodra een cryptografisch relevante kwantumcomputer (CRQC) beschikbaar komt, voert een aanvaller het algoritme van Shor uit op een onderschepte RSA- of ECC-publieke sleutel om de bijbehorende privésleutel af te leiden. Op dat moment beschikt de aanvaller over een perfecte kopie van de digitale identiteit van de oorspronkelijke ondertekenaar zoals die bestond toen de sleutel werd aangemaakt. Ze erven de volledige bevoegdheid van de oorspronkelijke eigenaar, inclusief de mogelijkheid om nieuwe handtekeningen te produceren die geen enkel verificatiesysteem kan onderscheiden van die van de rechtmatige sleutelhouder.
Fase 3: De identiteitskaping
Met een afgeleide privésleutel in handen kan de aanvaller wiskundig perfecte handtekeningen genereren en deze terugdateren naar elk willekeurig moment waarop de sleutel geldig was. Ze creëren een kwaadaardige firmwarecomponent of een frauduleus contract, voorzien deze van een tijdstempel naar de oorspronkelijke ondertekeningsperiode en genereren een handtekening met behulp van de daadwerkelijke privésleutel. De resulterende digitale handtekening is cryptografisch niet te onderscheiden van een handtekening die op dat moment door de rechtmatige sleutelhouder is gegenereerd. Vanuit een verificatieperspectief is dit de perfecte misdaad: de handtekening komt overeen met de bekende publieke sleutel, het tijdstempel valt binnen de geldigheidsperiode van het certificaat en de certificaatketen is correct gevalideerd.
Fase 4: Het instorten van de niet-afwijzing
In onze juridische en technische systemen vertrouwen we op het principe van niet-afwijzing: als een handtekening geldig is, kan de ondertekenaar niet ontkennen dat hij deze heeft geplaatst. TNFL ondermijnt dit principe. Een consument of apparaat ontvangt een ondertekend afsluitcommando, een ondertekende software-update of een ondertekend contract. Het systeem controleert de handtekening, bevestigt dat deze afkomstig is van de vertrouwde partij en handelt ernaar. Het systeem heeft geen mechanisme om een ​​vervalste handtekening te onderscheiden van een authentieke, omdat de vervalste handtekening cryptografisch identiek is aan een authentieke.
Waarom is dit een aansprakelijkheidsramp?
Een aanvaller met een afgeleide privésleutel kan een digitale leningsovereenkomst of een enorme bankoverschrijving vervalsen, deze terugdateren naar vijf jaar geleden en ondertekenen met de originele privésleutel. De handtekening klopt. De certificaatketen is gevalideerd. De tijdstempel valt binnen de oorspronkelijke geldigheidsperiode. Hoe bewijs je in de rechtbank dat je het niet hebt ondertekend als elk technisch verificatiesysteem bevestigt dat je dat wel hebt gedaan? Wanneer handtekeningen kunnen worden vervalst, is het cryptografische bewijs van je onschuld of intentie verdwenen. De volgende drie categorieën zijn de belangrijkste doelwitten voor TNFL, gerangschikt naar operationele impactradius.
1. Codeondertekening en firmware: de bedreiging voor de toeleveringsketen
Dit is de gevaarlijkste operationele TNFL-dreiging, omdat deze alle perimeterbeveiliging omzeilt. De meeste servers, apparaten en operationele technologiesystemen zijn ontworpen om software- en firmware-updates alleen te accepteren als deze zijn ondertekend met een vertrouwde sleutel van de fabrikant. Als een aanvaller in 2035 een 2026 RSA-codeondertekeningssleutel van een fabrikant achterhaalt en een kwaadaardige firmware-update terugdateert zodat deze binnen de geldigheidsperiode van het oorspronkelijke certificaat valt, installeert elk apparaat dat die sleutel vertrouwt de malware. Voor het apparaat is de update 100% authentiek: de geverifieerde handtekening is aanwezig, de certificaatketen is geldig en de tijdstempel valt binnen het bereik. De fabrikant kan een sleutel die al kwantumcomputationeel is gecompromitteerd niet intrekken; intrekking voorkomt alleen toekomstige vertrouwensbeslissingen, niet de verificatie van handtekeningen die historisch geldig lijken. Zie CodeSign Secure voor meer informatie over hoe Encryption Consulting helpt bij het beschermen van codeondertekeningssleutels.
2. Root Certificate Authority: De dreiging van de vertrouwenshiërarchie
Het vertrouwensmodel van het internet is gebaseerd op certificeringsinstanties (CA's) . Als de privésleutel van een root-CA kwantumcomputermatig wordt afgeleid, kan een aanvaller volledig vertrouwde certificaten uitgeven voor elk domein, CRL's of OCSP- reacties vervalsen om ingetrokken certificaten geldig te laten lijken of om legitieme certificaten in te trekken, en nieuwe intermediaire CA's creëren met hun eigen uitgifteautoriteit. De gehele vertrouwenshiërarchie stort in. De vervalsing is wiskundig perfect: zelfs de CA zelf zou niet kunnen bewijzen dat zij een bepaald certificaat niet heeft uitgegeven. Elk systeem dat die root-CA vertrouwt, inclusief browsers, besturingssystemen en bedrijfsapplicaties, accepteert de vervalste infrastructuur van de aanvaller als legitiem. Voor PKI-beheer dat de migratie naar kwantumresistente vertrouwensankers ondersteunt, zie PKI-as-a-Service.
3. Financiële en juridische documenten: De dreiging van niet-afwijzing
Digitale handtekeningen op contracten, wettelijke documenten, financiële transactiegegevens en archiefstukken moeten vaak tientallen jaren verifieerbaar blijven. Juridische kaders accepteren een geldige cryptografische handtekening als bewijs van authenticiteit en intentie. Als RSA- of ECC-handtekeningen op deze documenten kunnen worden vervalst en gedateerd zodra een kwantumcomputer bestaat, stort de basis van de onweerlegbaarheid van digitale juridische documenten in elkaar. Een aanvaller die een oude privésleutel reconstrueert, kan een vervalste handtekening produceren die jaren eerder lijkt te zijn aangemaakt. Validatiesystemen die de wiskundige correctheid, de geldigheid van de certificaatketen en de intrekkingsstatus op het beweerde ondertekeningstijdstip controleren, zullen de vervalsing als legitiem bevestigen.
Verschil tussen TNFL en HNDL
Zowel Harvest Now, Decrypt Later (HNDL) als Trust Now, Forge Later (TNFL) zijn dreigingsmodellen uit het kwantumtijdperk, maar ze vallen verschillende beveiligingseigenschappen aan, gebruiken verschillende mechanismen en hebben verschillende gevolgen op de lange termijn. Inzicht in beide is essentieel voor een complete PQC-risicobeoordeling.
| Factor | HNDL | TNFL |
|---|---|---|
| Aanval | Leg vandaag nog versleutelde data vast en decodeer deze wanneer een kwantumcomputer het klassieke sleuteluitwisselingsalgoritme kan kraken. | Verzamel vandaag nog openbare sleutels en handtekeningen; vervals handtekeningen met terugwerkende kracht wanneer een kwantumcomputer de privésleutel afleidt. |
| Primaire zekerheidsobjecten getroffen | Vertrouwelijkheid | Integriteit, authenticiteit, niet-afwijzing |
| Cryptografische primitieve doelwit | Sleuteluitwisseling (RSA-sleuteltransport, ECDH, DH) | Digitale handtekeningen (RSA, ECDSA) |
| Is een hedendaagse collectie vereist? | Ja: als het verkeer nu niet wordt vastgelegd, kan het later niet meer worden gedecodeerd. | Nee: publieke sleutels zijn al permanent overal beschikbaar. |
| Wat gaat er technisch gezien kapot? | Sessievertrouwelijkheid; eerdere versleutelde sessies worden leesbaar. | Integriteit van handtekeningen en vertrouwen in identiteit; ondertekende documenten worden onvervalsbaar. |
| Effect op TLS | Versleutelde sessies uit het verleden worden leesbaar. | Certificaten en vertrouwensketens kunnen vervalst worden. |
| Effect op PKI | Vertrouwelijke communicatie blootgesteld | CA-privésleutels zijn afleidbaar; volledige PKI-hiërarchie gecompromitteerd |
| Primaire NIST-remedie | FIPS 203 ML-KEM (sleutelinkapseling) | FIPS 204 ML-DSA, FIPS 205 SLH-DSA (kwantumresistente handtekeningen) |
Uw checklist om TNFL te beperken
Het beperken van TNFL vereist een andere strategie dan traditionele gegevensbescherming. Omdat TNFL de integriteit aanvalt in plaats van de vertrouwelijkheid, is het doel niet alleen om gegevens te verbergen, maar ook om ervoor te zorgen dat uw bewijs van authenticiteit tientallen jaren onbreekbaar blijft. De volgende checklist biedt een gestructureerd pad van onmiddellijke zichtbaarheid naar kwantumbestendigheid op de lange termijn.
- Voer cryptografische ontdekking en inventarisatie uit; breng alle ondertekeningssleutels in kaart, inclusief de privésleutels van de root- en uitgevende certificeringsinstantie (CA), de privésleutels die worden gebruikt voor het ondertekenen van software, firmware en patches, schaduw- en wildcardcertificaten, codeondertekeningssleutels die worden gebruikt in CI/CD-pipelines en sleutels van de Timestamping Authority (TSA). CBOM Secure voor geautomatiseerde detectie in alle omgevingen
- Identificeer verouderde en ingebouwde apparaten die hardcoded zijn voor het gebruik van RSA- of ECC-ondertekening en geen updates op afstand kunnen ontvangen; plan tijdlijnen voor hardwarevernieuwing in deze omgevingen.
- Bewaar alle ondertekeningssleutels in een FIPS 140-3 gevalideerde configuratie. HSM's; bevestig de firmware-roadmap van uw HSM-leverancier voor ML-DSA- en SLH-DSA-ondersteuning; plan de tijdlijnen voor hervalidatie voor FIPS 140-3-certificering van PQC-algoritmen.
- Ga over van codeondertekeningscertificaten met een geldigheidsduur van 1 tot 2 jaar naar cycli van 90 dagen of korter; kortere geldigheidsduur verkleint de bruikbare periode waarin elke onderschepte publieke sleutel door TNFL-aanvallers kan worden gebruikt.
- Definieer een hybride handtekeningarchitectuur: voer tijdens de overgangsperiode parallel een klassieke handtekening (RSA of ECDSA) en een PQC-handtekening (ML-DSA of SLH-DSA) uit om achterwaartse compatibiliteit te behouden en tegelijkertijd voorwaartse beveiliging te garanderen.
- Ontwerp een nieuwe, PQC-compatibele root-CA-hiërarchie; laat klassieke en PQC-root-CA's parallel draaien tijdens de overgang; distribueer nieuwe PQC-vertrouwensankers via GPO, MDM en besturingssysteemimages voordat de klassieke root-CA's worden uitgefaseerd.
- Neem TSA-sleutels op in de PQC-migratieroadmap; PQC-compatibele tijdstempels zijn essentieel om te voorkomen dat aanvallers vervalste handtekeningen combineren met gecompromitteerde tijdstempelketens om historisch geldig auditbewijs te fabriceren.
- Migreren naar PKI-as-a-Service (PKIaaS) of een cloud-native CA die PQC-algoritmen native ondersteunt, waardoor het handmatige beheer van de certificaatlevenscyclus, dat de noodrespons vertraagt, overbodig wordt.
- Voor verouderde OT/ICS-omgevingen die niet gepatcht kunnen worden, implementeer een verificatiegateway die PQC-handtekeningen kan valideren namens apparaten die PQC-handtekeningverificatie niet native kunnen uitvoeren.
- Implementeer abstractielagen of een CLM-tool zodat de algoritmemigratie (van RSA naar ML-DSA) een configuratiewijziging vereist in plaats van een volledige herziening van de applicatie.
- Elimineer handmatig certificaatbeheer; automatiseer het volledige ondertekeningsproces, zodat noodherondertekening in geval van een beveiligingslek binnen enkele uren in plaats van maanden kan worden uitgevoerd.
- Valideer de PQC- en hybride ondersteuningsroadmap van de HSM-firmware met uw HSM-leverancier; vraag om schriftelijke bevestiging van de ondersteuningstermijnen voor ML-DSA en SLH-DSA.
- Test de doorvoer van handtekeningen met grotere PQC-algoritmen; ML-DSA produceert grotere handtekeningen dan ECDSA en de prestaties van de handtekeningverificatie moeten worden getest op alle validatie-eindpunten.
- Actualiseer de procedures voor sleutelceremonies om het genereren, opslaan en back-uppen van PQC-sleutels te omvatten; valideer de back-up- en herstelprocedures voor nieuwe sleuteltypen.
- Update de operationele documentatie van het certificeringsbeleid (CP) en de certificeringspraktijkverklaring (CPS) om de hybride en PQC-ondertekeningsarchitectuur te weerspiegelen.
TNFL-risico en -beperking: een PKI-gecentreerd perspectief
Het beperken van de TNFL-dreiging vereist een verandering in de manier waarop organisaties de houdbaarheid van vertrouwen beheren. In tegenstelling tot bedreigingen voor de vertrouwelijkheid, die kunnen worden aangepakt met encryptie van gegevens in rust, valt TNFL de autoriteit aan: als een root-sleutel of een codeondertekeningssleutel over tien jaar kwantumcomputationeel wordt gecompromitteerd, kan een aanvaller handtekeningen terugdateren naar de huidige datum, en beschikken de huidige systemen niet over een technisch mechanisme om de vervalsing van het origineel te onderscheiden. Deze tabel fungeert als een kwetsbaarheidskaart voor alle belangrijke PKI-vertrouwensdomeinen.
| PKI-vertrouwensdomein | TNFL Impact | Waarom het een hoog risico is | Praktische focus op risicobeperking |
|---|---|---|---|
| Vertrouwensankers (root-CA's en vertrouwensarchieven) | Het afleiden van de root-privésleutel stelt een aanvaller in staat om volledig vertrouwde certificaatketens uit te geven, valse identiteiten te creëren of kwaadaardige infrastructuur te ondertekenen die als legitiem wordt gevalideerd. | De basis van de organisatie is langdurig en geniet breed vertrouwen; compromissen sluiten is een vast onderdeel van het systeem voor alle betrokken partijen. | Bouw een parallelle, PQC-compatibele root-hiërarchie; distribueer vertrouwensankers vroegtijdig via GPO, MDM en OS-images; plan een root-rollover; verkort de vertrouwenshorizon voor nieuwe roots. |
| Uitgevende (tussenliggende) CA's | Door de certificeringsinstantie (CA) te compromitteren, kunnen op grote schaal vervalste certificaten worden uitgegeven, waardoor diensten, gebruikers of apparaten op grote schaal kunnen worden geïmiteerd. | Uitgevende certificeringsinstanties ondertekenen alles; een inbreuk treft veel eindpunten tegelijk. | HSM-ondersteunde CA-sleutels, kortere CA-levensduur, gefaseerde CA-vervanging, hybride uitgiftebeleid voor certificaten met een lange levensduur |
| Code ondertekening | Aanvallers reconstrueren codeondertekeningssleutels en ondertekenen malware of gemanipuleerde software-updates die er authentiek uitzien en alle validatiecontroles van de handtekening doorstaan. | TNFL maakt legitiem ogende kwaadaardige updates mogelijk met een grote operationele impact, die alle apparaten treft die op die sleutel vertrouwen. | HSM-beveiligde ondertekeningssleutels, dubbele en hybride ondertekening, afdwingen van ondertekeningsvalidatie in CI/CD, herkomstcontroles inclusief SBOM en beleidspoorten. |
| Firmware- en Secure Boot-ondertekening | Vervalsde firmware-images, ondertekend met afgeleide leverancierssleutels, worden door apparaten geaccepteerd, waardoor beveiligd opstarten wordt omzeild en persistente kwaadaardige code wordt geïnstalleerd. | Niet-upgradebare validatoren betekenen vaak dat vervalste handtekeningen gedurende de volledige levensduur van het apparaat kunnen blijven bestaan. | Firmware met dubbele ondertekening waar mogelijk; plan hardware-updates voor omgevingen met vastgelegde RSA- en ECC-code; voeg verificatiegateways met strengere validatie toe voor oudere apparaten. |
| Intrekking (OCSP en CRL) | Vervalsde OCSP-reacties of CRL's geven ten onrechte aan dat ingetrokken certificaten geldig zijn, of maken legitieme certificaten ongeldig, waardoor alle vertrouwensbeslissingen die gebaseerd zijn op de intrekkingsstatus worden ondermijnd. | Als intrekkingsdocumenten vervalst kunnen worden, kan de fundamentele vraag of een certificaat momenteel geldig is, niet betrouwbaar beantwoord worden. | Stem de intrekkingssleutels af op de nieuwe PQC-hiërarchie, handhaaf strikte OCSP-ondertekeningscontroles, monitoring en OCSP-staplingvalidatietests. |
| Tijdstempeling en langetermijnvalidatie | Door vervalste handtekeningen met een teruggedateerde datum te combineren met gecompromitteerde tijdstempelketens, lijken kwaadaardige artefacten historisch geldig en juridisch authentiek. | TNFL wordt versterkt door zwakke tijdstempelketens; de juridische en auditgevolgen zijn ernstig en worden mogelijk pas na jaren ontdekt. | PQC-compatibele tijdstempelstrategie, het opnieuw voorzien van tijdstempels voor lang bestaande records met een nieuwe, PQC-beveiligde TSA, en het ontwerpen van LTV (Long-Term Validation) zodat de archiveringsbewijsbaarheid niet instort wanneer klassieke algoritmen verouderd raken. |
| Inschrijvingsinfrastructuur | Aanvragen voor frauduleuze certificaten worden goedgekeurd of vervalst met behulp van gecompromitteerde CA-sleutels, waardoor ongeautoriseerde identiteitsverstrekking mogelijk wordt die cryptografisch geldig lijkt. | Het is een ramp als alle handtekeningen van de inschrijvingsinstantie onvervalsbaar blijken en de authenticiteit van de inschrijvingsgoedkeuringen niet meer kan worden bewezen. | Beveilig de identiteit bij inschrijvingen, automatiseer goedkeuringen met op beleid gebaseerde sjabloonbeperkingen, dwing auditsporen af ​​en implementeer CLM voor alle uitgegeven certificaten. |
| Validatie-eindpunten en -toepassingen | Applicaties accepteren vervalste certificaatketens als gevolg van een schending van het vertrouwensanker, waardoor kwaadwillende diensten niet te onderscheiden zijn van legitieme diensten. | Als validators de nieuwe PQC-profielen en OID's niet kunnen verwerken, mislukt de migratie van het klassieke vertrouwensmodel zonder dat dit gebeurt. | Crypto-agility testen op alle validatie-eindpunten, testen van de mogelijkheid om de vertrouwensopslag bij te werken, testen van de certificaatketen en het padopbouwproces voor PQC-profielen, testen van de grootte en latentie voor grotere PQC-handtekeningen. |
Hoe kan Encryption Consulting u helpen?
Als u zich afvraagt ​​waar en hoe u uw reis na het kwantumtijdperk kunt beginnen , staat Encryption Consulting voor u klaar. U kunt op ons rekenen als uw betrouwbare partner en wij begeleiden u bij elke stap met duidelijkheid, vertrouwen en praktijkervaring.
Cryptografische ontdekking en inventarisatie
Dit is de fundamentele fase waarin we inzicht creëren in uw bestaande cryptografische infrastructuur. We identificeren welke ondertekeningssleutels en certificaathiërarchieën risico lopen op kwantumdreigingen en beoordelen hoe goed uw huidige configuratie hierop voorbereid is, inclusief uw PKI, hardwarebeveiligingsmodules (HSM's) en applicaties. Het resultaat is een uitgebreide cryptografische inventaris, inclusief alle ondertekeningssleutels per algoritme, sleutelgrootte, HSM-binding en certificaatlevenscyclusstatus, die de basis vormt voor uw TNFL-mitigatieplan.
PQC-beoordeling
Zodra er inzicht is verkregen, beoordelen we het cryptografische landschap op kwantumkwetsbaarheden. Voor TNFL-specifieke risico's omvat dit het identificeren van alle RSA- en ECDSA-ondertekeningssleutels en de bijbehorende certificaten en vertrouwenshiërarchieën, het beoordelen van de HSM-firmwareondersteuning voor ML-DSA en SLH-DSA, het controleren van CI/CD-pipelines op blootstelling van codeondertekeningssleutels en het evalueren van de architectuur van de tijdstempelautoriteit. We leveren een gedetailleerd rapport met een inventaris van kwetsbare ondertekeningsmiddelen, risico-ernstclassificaties en een TNFL-specifieke prioritering voor migratie.
PQC-strategie en routekaart
Nadat de risico's zijn geïdentificeerd, ontwikkelen we een op maat gemaakte, gefaseerde migratiestrategie die is afgestemd op uw zakelijke, technische en wettelijke vereisten. Voor de mitigatie van TNFL omvat dit een hybride ontwerp voor de signatuurarchitectuur, een nieuw ontwerp voor de PQC-roothiërarchie, een strategie voor de distributie van vertrouwensankers, een plan voor het verkorten van de levensduur van certificaten en een ontwerp voor langetermijnvalidatie (LTV) van archiefgegevens. We stemmen de roadmap af op de deadlines van NIST FIPS 204 en 205 en CNSA 2.0.
Leveranciersevaluatie en proof of concept
Wij helpen u bij het identificeren en testen van de tools en platforms die uw doelstellingen voor post-quantum signing kunnen ondersteunen, waaronder HSM-leveranciers met gevalideerde PQC-firmwareondersteuning, CA-platforms die ML-DSA-uitgifte ondersteunen, tijdstempelingsservices met PQC-ondersteuning en CLM-platforms die hybride certificaatbeheer ondersteunen. We voeren PoC-tests uit in geïsoleerde omgevingen en leveren een leveranciersvergelijkingsrapport.
Proefproject, opschaling en implementatie
Voordat we de volledige implementatie uitvoeren, valideren we hybride ondertekening, de uitgifte van PQC-certificaten en de distributie van vertrouwensankers in een gecontroleerde omgeving. We testen de impact van de handtekeninggrootte op de netwerkbandbreedte en de validatieprestaties, de interoperabiliteit met oudere systemen die nog geen PQC-handtekeningen kunnen verifiëren, en de nauwkeurigheid van geautomatiseerde herondertekening in noodsituaties. Zodra de tests zijn afgerond, ondersteunen we een soepele en schaalbare uitrol.
Neem contact met ons op via [email protected] en laat ons een routekaart op maat ontwikkelen die aansluit op de specifieke behoeften van uw organisatie.
Conclusie
Hoewel de industrie zich al lange tijd richt op de HNDL-dreiging voor de vertrouwelijkheid, onthult TNFL een nog existentiëler risico: de potentiële totale ineenstorting van digitale identiteit en niet-afwijzing. Als organisaties hun cryptografische ondertekeningsmiddelen niet inventariseren en niet overstappen op kwantumresistente handtekeningen voordat een CRQC zich aandient, staan ​​ze voor een toekomst waarin de geschiedenis zelf kan worden herschreven met perfecte cryptografische geldigheid, en de digitale handtekening niet langer onder controle staat van de partij die oorspronkelijk de sleutel bezat. Het beveiligen van de toekomst betekent niet alleen het vandaag verbergen van gegevens; het betekent het versterken van de autoriteit voor morgen. De standaarden zijn afgerond: FIPS 204 ML-DSA en FIPS 205 SLH-DSA bieden de kwantumresistente handtekeningalgoritmen die nodig zijn om TNFL aan te pakken. De taak is om te ontdekken welke ondertekeningssleutels u bezit, de sleutels met het hoogste risico als eerste te migreren en uw PKI-hiërarchie en certificaatlevenscycli zo te ontwerpen dat het aanvalsoppervlak van TNFL wordt geminimaliseerd voordat het kwantumvenster zich opent. Voor de basisprincipes van cryptografische ontdekking, zie You Can't Secure What You Can't See . Voor de CBOM-inventaris die de bevindingen structureert, zie Waarom een ​​CBOM nu belangrijker is dan ooit . Voor het complete PQC-migratiekader, zie PQC-adviesdiensten.
Veelgestelde Vragen / FAQ
Wat is een Trust Now, Forge Later (TNFL)-aanval?
Trust Now, Forge Later (TNFL) is een dreigingsmodel uit het kwantumtijdperk waarbij een aanvaller vandaag de dag publieke sleutels en digitale handtekeningen verzamelt, wacht tot een kwantumcomputer die het algoritme van Shor uitvoert de bijbehorende privésleutel kan afleiden, en vervolgens vervalste handtekeningen creëert die wiskundig niet te onderscheiden zijn van die van de oorspronkelijke sleutelhouder. TNFL vereist geen actieve onderschepping in het heden, omdat publieke sleutels al wereldwijd beschikbaar zijn in TLS-certificaten, codeondertekeningscertificaten, firmwarevalidatieketens en root CA-vertrouwensarchieven.
Wat is het verschil tussen TNFL en Harvest Now, Decrypt Later (HNDL)?
HNDL valt de vertrouwelijkheid aan: een tegenstander onderschept en bewaart vandaag versleutelde gegevens en decodeert deze vervolgens zodra een kwantumcomputer het sleuteluitwisselingsalgoritme kan kraken. TNFL valt de integriteit en onweerlegbaarheid aan: een tegenstander verzamelt vandaag publieke sleutels, leidt later via kwantumcomputers privésleutels af en vervalst handtekeningen die gedateerd zijn op het heden. HNDL vereist actieve onderschepping vandaag. TNFL vereist geen inspanningen om gegevens te verzamelen, omdat de publieke sleutels al permanent en publiek beschikbaar zijn.
Welke systemen zijn het meest kwetsbaar voor TNFL-aanvallen?
De drie categorieën met het hoogste risico zijn: codeondertekening en firmwarevalidatie (apparaten accepteren updates alleen als deze zijn ondertekend met een vertrouwde sleutel; een afgeleide privésleutel maakt kwaadaardige firmware mogelijk die volledig authentiek lijkt); root-certificeringsinstanties (een gecompromitteerde privésleutel van een root-CA maakt het mogelijk om vertrouwde certificaten voor elk domein te vervalsen en de gehele vertrouwenshiërarchie te ondermijnen); en lang bewaarde financiële en juridische documenten (digitale handtekeningen die tientallen jaren verifieerbaar moeten blijven, worden vervalst, waardoor de basis van onweerlegbaarheid van digitale juridische documenten instort).
Wat is de belangrijkste eerste stap om het risico op TNFL te beperken?
De belangrijkste eerste stap is een uitgebreide cryptografische inventarisatie die alle ondertekeningssleutels specifiek in kaart brengt: de privésleutels van de root-CA en de uitgevende CA, code-ondertekeningssleutels, firmware-ondertekeningssleutels, tijdstempelautoriteitssleutels en schaduw- of wildcardcertificaten. Een CBOM (Cryptography Bill of Materials) structureert deze inventarisatie in een machineleesbare vorm en ondersteunt het doorlopende beheer.
Welke algoritmen vervangen RSA en ECDSA voor digitale handtekeningen in een TNFL-resistent systeem?
In augustus 2024 heeft NIST drie kwantumresistente handtekeningalgoritmen afgerond: FIPS 204 (ML-DSA, afgeleid van CRYSTALS-Dilithium) als de belangrijkste vervanging voor RSA- en ECDSA-handtekeningen; FIPS 205 (SLH-DSA, afgeleid van SPHINCS+) als een hash-gebaseerd alternatief; en FIPS 206 (FN-DSA, gebaseerd op FALCON), dat nog in ontwikkeling is. Voor de meest waardevolle en langst geldige ondertekeningssleutels wordt tijdens de overgangsperiode een hybride strategie aanbevolen, waarbij een klassieke handtekening wordt gecombineerd met ML-DSA of SLH-DSA.
Waarom maakt TNFL de geldigheidsduur van certificaten tot een cruciale risicobeperkingsfactor?
Kortere certificaten hebben een beperktere geldigheidsduur, waardoor een onderschepte publieke sleutel slechts gedurende een bepaalde periode bruikbaar blijft voor een TNFL-aanvaller. Een certificaat met een geldigheidsduur van 90 dagen dat al is verlopen op het moment dat een kwantumcomputer zijn privésleutel genereert, biedt de aanvaller geen enkel voordeel meer bij het ondertekenen van documenten. Certificaten met een langere geldigheidsduur, waaronder meerjarige codeondertekeningscertificaten en root-CA-certificaten met een geldigheidsduur van 20 jaar, zijn de belangrijkste doelwitten voor TNFL-mitigatie. Het verkorten van de geldigheidsduur van certificaten verkleint direct het aanvalsoppervlak per sleutel.
- Kort antwoord: Wat is vertrouwen nu, smeden later?
- De kernlogica van vertrouwen nu, smeden later.
- Stapsgewijs mechanisme: Hoe het smeden tot stand komt
- Waarom is dit een aansprakelijkheidsramp?
- Verschil tussen TNFL en HNDL
- Uw checklist om TNFL te beperken
- TNFL-risico en -beperking: een PKI-gecentreerd perspectief
- Hoe kan Encryption Consulting u helpen?
- Conclusie
- Veelgestelde Vragen / FAQ
