Crypto-agility: defensiesystemen ontwerpen om algoritmen te wisselen

De meeste defensiesystemen breken niet omdat hun cryptografie zwak was toen ze werden ingezet. Ze breken omdat de cryptografie hetzelfde bleef terwijl de wereld verder ging. Een algoritme dat bij ingebruikname deugdelijk was, raakt verouderd, dan ontmoedigd, dan verboden — en het systeem dat het hard heeft gecodeerd heeft nu een meerjarig, multi-leverancier engineeringprogramma nodig om één enkel primitief te veranderen. Crypto-agility is de discipline van het bouwen van systemen zodat het wisselen van een algoritme een configuratie- en deploymenttaak is, geen herontwerp. Nu de migratie naar post-kwantumcryptografie een vaste vereiste is geworden voor langlevende defensiegegevens, is agility geen verfijning meer — het is de voorwaarde voor het overleven van de volgende overgang zonder het systeem opnieuw te hoeven inzetten.

Wat crypto-agility werkelijk betekent

Crypto-agility is de eigenschap van een systeem waarmee het algoritmen, sleutelgroottes en protocollen kan wijzigen zonder de applicatie die ervan afhankelijk is opnieuw te ontwerpen. De test is eenvoudig: hoe lang en hoeveel regels code kost het om het ene algoritme door het andere te vervangen? In een niet-agile systeem is het antwoord "we heropenen het ontwerp," omdat de algoritmenaam, sleutellengte en parameterreeks verspreid zijn over applicatielogica, serialisatieformaten, certificaatsjablonen en protocol-handlers. In een agile systeem is het antwoord "we wijzigen een beleid," omdat al die beslissingen op het moment dat het systeem werd gebouwd zijn geëxternaliseerd naar configuratie.

Agility is niet hetzelfde als een goede cryptobibliotheek hebben. Een programma kan de best beoordeelde bibliotheek koppelen die beschikbaar is en toch volledig rigide zijn, omdat de applicatie een specifieke functie aanroept — RSA_sign, een benoemde curve, een vaste samenvatting — rechtstreeks vanuit bedrijfscode. Het feit dat de bibliotheek verwisselbaar is, helpt niet als de aanroepplaatsen dat niet zijn. Agility is een architecturele eigenschap van het hele systeem, geen kenmerk van één afhankelijkheid.

Waarom defensiesystemen het nu nodig hebben

Twee tijdlijnen botsen in defensie-aanbestedingen. De eerste is de levensduur van het platform. Een gevechtsvoertuig, een radiofamilie of een command-and-control-suite wordt verwacht twintig tot veertig jaar in gebruik te zijn. In die periode zullen cryptografische standaarden meerdere keren omgaan — de overgang van SHA-1, de afschaffing van 1024-bit RSA en de overstap naar geauthenticeerde encryptie vonden allemaal plaats binnen één platformgeneratie. Elk algoritme dat vandaag in een systeem is gebakken, zal verouderd zijn lang voordat de hardware buiten gebruik wordt gesteld.

De tweede tijdlijn is de kwantumdreiging. Een cryptografisch relevante kwantumcomputer zou RSA en elliptische-curvecryptografie rechtstreeks breken, en de "harvest now, decrypt later"-strategie betekent dat tegenstanders het versleutelde verkeer van vandaag kunnen vastleggen en opslaan totdat die machine bestaat. Defensiegegevens met tientallen jaren durende vertrouwelijkheidsvereisten lopen daarom al risico, ook al bestaat de kwantumcomputer nog niet. De standaardrespons — CNSA 2.0 en de NIST-post-kwantumsuite — stelt vaste migratiedeadlines. Een systeem zonder agility kan die deadlines niet halen zonder een heringenieursinspanning die het schema niet toelaat. Voor het dreigingsmodel en de tijdlijn hierachter, zie onze analyse van de kwantumcomputerdreiging voor defensiecommunicatie.

Begin met een cryptografische inventarisatie

U kunt niet migreren wat u niet kunt zien, en u kunt niet agile maken wat u niet heeft gelokaliseerd. Het eerste resultaat van elk crypto-agility-programma is een cryptografische inventarisatie — steeds vaker geformaliseerd als een cryptografische materialenlijst, of CBOM. Het is een volledig catalogus van elke plaats waar het systeem cryptografie gebruikt: elk algoritme en elke modus, elke sleutellengte, elk certificaat en zijn uitgever, de protocolversies die op elke interface worden onderhandeld, de bibliotheken die de primitieven implementeren en — cruciaal — de gegevens die elk exemplaar beschermt en hoe lang die gegevens vertrouwelijk moeten blijven.

De inventarisatie is bijna altijd verrassender dan het programma verwacht. Cryptografie verbergt zich in firmware waarvoor niemand de broncode heeft, in binaire bestanden van derden waarvan de algoritme-keuzes niet gedocumenteerd zijn, in hardwarebeveiligingsmodules met vaste mogelijkheden en in protocolstandaardinstellingen die tijdens runtime worden onderhandeld in plaats van bij het ontwerp worden gekozen. Een nuttige inventarisatie registreert ontdekkingszekerheid en eigenaarschap voor elk item, waarbij onderscheid wordt gemaakt tussen "we hebben dit in broncode gelezen," "we hebben dit op de draad waargenomen" en "de leverancier heeft ons dit verteld." Het moet een levend artefact zijn dat door de bouwpijplijn wordt gegenereerd, niet een eenmalige audit die al verouderd is de dag nadat die wordt opgeleverd.

Van inventarisatie naar risicoprioriteit

De inventarisatie is niet alleen een kaart — het is de input voor prioritering. Twee attributen bepalen de migratievolgorde: de vertrouwelijkheidslevensduur van de beschermde gegevens en de blootstelling van het kanaal. Gegevens die dertig jaar geheim moeten blijven en een externe verbinding kruisen, zijn het eerste om te migreren, omdat ze precies zijn wat "harvest now, decrypt later" target. Kortlevende gegevens op een intern, fysiek beschermd segment kunnen wachten. Zonder de inventarisatie is deze triage onmogelijk en migreert het programma óf alles tegelijk (wat onbetaalbaar is) óf de eenvoudige dingen eerst (waardoor de gegevens met het hoogste risico het langst blootgesteld blijven).

De algoritme-abstractielaag

De structurele kern van een agile systeem is een algoritme-abstractielaag — een cryptografische provider of service-interface die tussen applicatiecode en de concrete implementaties zit. Applicatiecode noemt nooit een algoritme. In plaats daarvan drukt het intentie uit: "onderteken dit bericht," "stel een sessiesleutel in met deze peer," "versleutel deze record in rust." Naast de intentie verwijst het naar een benoemd beleid — bijvoorbeeld signing.c2-link.v3 — en de abstractielaag lost dat beleid op naar een concreet algoritme, sleutellengte en parameterreeks tijdens runtime.

Het voordeel is dat een algoritmewissel een beleidswijziging wordt. Het wijzigen van signing.c2-link.v3 van een elliptische-curvehandtekening naar een post-kwantumhandtekening is een configuratiewijziging die per omgeving wordt uitgerold, zonder aanpassing van de aanroepende code en zonder hercompilatie van de applicatie die het ondertekeningsverzoek indient. Dezelfde indirectie laat een programma toe om verschillende algoritmen in verschillende theaters of voor verschillende classificatieniveaus te draaien vanuit één binair bestand, en laat het een migratie stapsgewijs uitvoeren — oud beleid in productie, nieuw beleid in test — zonder de codebase te vertakken.

Het correct ontwerpen van de interface is belangrijk. Het moet grof genoeg zijn zodat applicatieontwikkelaars er niet per ongeluk omheen kunnen gaan (geen "geef me een ruwe AES-sleutel"-ontsnappingsluik dat de keuze opnieuw hard codeert), en het moet algoritme-metadata blootstellen zodat aanroepers kunnen vastleggen welk beleid werd toegepast. De HSM, sleutelkluis en rotatiemachinery bevinden zich ook achter deze laag; voor de operationele kant hiervan, zie onze gids voor geheimenbeheer in defensie-CI/CD-pijplijnen.

Versioning van protocollen, certificaten en opgeslagen gegevens

Agility op de aanroepplaats is noodzakelijk maar niet voldoende. Cryptografische artefacten overleven het moment waarop ze worden gemaakt — een record dat vandaag wordt versleuteld, kan over vijftien jaar worden ontcijferd, een certificaat dat nu wordt uitgegeven wordt door peers geverifieerd gedurende zijn hele geldigheidsperiode en een protocolsessie wordt onderhandeld tussen twee systemen op verschillende upgradeplanningen. Elk hiervan moet voldoende metadata dragen om een algoritmewijziging te overleven.

Protocollen. Draadformaten moeten expliciete algoritme-identificatoren en versievelden bevatten zodat twee peers een gemeenschappelijk algoritme kunnen onderhandelen in plaats van er één te veronderstellen. Een protocol dat "de handtekening is ECDSA-P384" hard codeert, kan niet worden geüpgraded zonder elke geïmplementeerde peer tegelijkertijd te breken — een vlagdag die operationeel onmogelijk is in een ingezette strijdmacht. Een protocol dat onderhandelt over "ik ondersteun deze algoritmesuites, jij ondersteunt die, we zijn het eens over de sterkste gemeenschappelijke" upgradet soepel naarmate endpoints in hun eigen tempo migreren.

Certificaten. Certificaatprofielen moeten nieuwe handtekening- en sleutelinkapseling-algoritme-identificatoren accommoderen, en het validatiepad mag een onbekend-maar-beleid-goedgekeurd algoritme niet afwijzen. De publieke-sleutelinfrastructuur zelf heeft een agile root nodig: als de certificeringsinstantie slechts één algoritme kan uitgeven, wordt de PKI de bottleneck ongeacht hoe agile de endpoints zijn.

Opgeslagen gegevens. Elke versleutelde record of ondertekend object moet vastleggen welk algoritme en welke sleutel het heeft beschermd. Zonder die tag kan een toekomstig systeem erfgoedgegevens niet ontcijferen of verifiëren nadat het actieve algoritme verandert — de gegevens worden onleesbaar niet omdat de sleutel verloren ging, maar omdat het systeem vergat welk schema het gebruikte. Deze metadata is wat een migratie omkeerbaar maakt en wat oud en nieuw geheimschrift tijdens de overgang naast elkaar laat bestaan.

Een gefaseerd migratieplan

Met de inventarisatie, de abstractielaag en versiebeheerde artefacten op hun plaats, wordt de migratie zelf een gecontroleerde, omkeerbare reeks in plaats van een vlagdag. Een werkbaar plan verloopt in vijf fasen.

Fase 1 – inventarisatie. Bouw en automatiseer de CBOM, en prioriteer vermeldingen op vertrouwelijkheidslevensduur en blootstelling. Deze fase produceert de migratieachterstand en legt de afhankelijkheden bloot die anders veldstoringen zouden veroorzaken.

Fase 2 – abstractie. Introduceer de algoritme-abstractielaag en routeer elke bestaande cryptografische aanroep erdoorheen. Geen applicatielogica mag een algoritme rechtstreeks aanroepen. Aan het einde van deze fase is het systeem niet veiliger dan voorheen, maar het is nu wijzigbaar — de voorwaarde voor alles wat volgt.

Fase 3 – hybride modi. Configureer de laag om een klassiek en een post-kwantumalgoritme samen te draaien — bijvoorbeeld een hybride sleuteluitwisseling die een elliptische-curveuitwisseling combineert met een rooster-gebaseerd sleutelinkapselmechanisme. De gecombineerde constructie blijft veilig als een van beide componenten later wordt gecompromitteerd, wat inspeelt op zowel een kwantumbreuk van het klassieke algoritme als een onvoorziene zwakte in het nieuwere post-kwantumalgoritme. Rol hybride modi uit per omgeving achter beleid, waarbij interoperabiliteit met geallieerde en STANAG-gereglementeerde systemen wordt gevalideerd voordat een standaardinstelling wordt gewijzigd.

Fase 4 – geprioriteerde migratie. Gebruik de risicorangschikking van de inventarisatie om eerst gegevens met langdurige vertrouwelijkheid en extern blootgesteld te migreren, dan verder naar kortlevende interne gegevens. Meet dekking aan de CBOM bij elke stap zodat het programma exact kan rapporteren welk deel van hoogrisico-gegevens wordt beschermd door post-kwantumcryptografie. De gedetailleerde nalevingsvolgorde voor deze fase is uiteengezet in de CNSA 2.0-migratieroadmap.

Fase 5 – buiten gebruik stellen. Verwijder een klassiek-only algoritme pas wanneer elke afhankelijke peer en elk opgeslagen-gegevenspad zijn herversleuteld of herveranderend onder het nieuwe beleid — wat de inventarisatie en opgeslagen-gegevenstags u laten verifiëren in plaats van veronderstellen. Buiten gebruik stellen is de laatste stap juist omdat het de enige onomkeerbare is; alles ervoor kan worden teruggedraaid als interoperabiliteit of prestaties achteruitgaan.

Veelvoorkomende faalpatronen

Drie fouten komen steeds terug in programma's. De eerste is agility behandelen als een bibliotheekvervaging — een post-kwantum-geschikte bibliotheek koppelen terwijl directe algoritme-aanroepen in applicatiecode achterblijven, wat een systeem oplevert dat niet agiler is dan voorheen. De tweede is migreren voor inventariseren, wat gegarandeerd gemiste afhankelijkheden oplevert die als veldstoringen opduiken wanneer een niet-gecatalogiseerde peer of firmwarecomponent het nieuwe algoritme niet kan onderhandelen. De derde is het oude algoritme te vroeg verwijderen, voordat elke opgeslagen record en elke peer heeft gemigreerd, waardoor erfgoedgegevens onverifieerbaar of onleesbaar worden. Elk hiervan wordt vermeden door dezelfde discipline: eerst inventariseren, abstraheren voor migreren en als laatste buiten gebruik stellen.

Wat dit betekent voor aanbestedingen

Crypto-agility is het goedkoopst wanneer het een vereiste is bij contracttoekenning en het duurst wanneer het achteraf wordt aangebracht in een ingezet systeem. Programma's die nieuwe defensiesoftware specificeren, moeten een algoritme-abstractielaag, een bijgehouden cryptografische materialenlijst en versiebeheerde cryptografische artefacten als acceptatiecriteria vereisen — niet als toekomstige verbetering. De systemen die vandaag worden ontworpen, zullen de post-kwantumovergang doormaken en minstens één overgang daarna. Ze zo bouwen dat ze algoritmen goedkoop kunnen wisselen, is het verschil tussen een configuratiewijziging en een herinzetprogramma.