Sigill og NSMs kryptografiske anbefalinger: Hvor står vi?

Kryptografi har en litt ubehagelig egenskap: Det som er sikkert i dag, trenger ikke være sikkert om noen år.

Algoritmer blir gamle. Sertifikater utløper. Nøkler må byttes. Nye angrep dukker opp. Og en dag får vi datamaskiner som kan gjøre deler av dagens kryptografi langt mindre betryggende enn den er nå.

Dette er noe av grunnen til at NSMs kryptografiske anbefalinger er interessante for oss i Sigill. Veilederen handler nemlig ikke bare om hvilke algoritmer man bør bruke. Den spør også om man vet hvor kryptografien brukes, om nøklene er godt beskyttet, om gamle løsninger kan skiftes ut – og om man har begynt å forberede seg på tiden etter dagens kryptografi.

Det passer godt med problemet Sigill prøver å løse.

Når en AI-agent utfører en handling, et system registrerer en hendelse eller en virksomhet trenger å kunne dokumentere hva som skjedde på et bestemt tidspunkt, skal det kunne etterprøves senere. Ikke bare neste uke, men potensielt mange år frem i tid.

Så: Hvordan står Sigill seg mot anbefalingene fra NSM?

Ganske godt, mener vi. Men det er også noen ting vi fortsatt må gjøre bedre.

Vi prøver ikke å finne opp kryptografien på nytt

Et av de enkleste rådene fra NSM er også et av de viktigste: Bruk etablerte kryptografiske løsninger. Ikke lag dine egne.

Det høres selvfølgelig ut, men teknologihistorien er full av systemer som har laget sin egen «smarte» variant og senere oppdaget hvorfor det var en dårlig idé.

Sigill bygger derfor på åpne og etablerte standarder. Vi bruker blant annet RFC 3161 for tidsstempling, PAdES, CAdES og JAdES for signaturer og segl, og RFC 4998 for bevis som skal kunne leve lenge. Vi bruker også ETSI-standarder for validering.

Men det viktigste er egentlig ikke forkortelsene. Poenget er at bevisene ikke skal være avhengige av at vi forklarer hvordan de virker.

De skal kunne kontrolleres med programvare vi ikke kontrollerer, som EU DSS, Bouncy Castle og OpenSSL. Hvis Sigill lager et bevis som bare Sigill kan forstå, har vi egentlig bare flyttet problemet.

Det samme prinsippet gjelder signaturalgoritmene våre. Vi har flyttet dokumentsegl og signerte valideringsrapporter over til RSA-PSS, som er den moderne RSA-varianten NSM anbefaler fremfor eldre PKCS #1 v1.5 i nye løsninger. Våre egne seglnøkler bruker 4096-bits RSA.

Gamle bevis blir selvfølgelig ikke skrevet om. Et bevis skal fortelle hva som faktisk skjedde da det ble laget, ikke pyntes på i ettertid fordi teknologien har gått videre.

Nøklene skal være vanskelige å få tak i

En kryptografisk signatur er bare så trygg som nøkkelen bak den.

Derfor opprettes og brukes Sigills private plattformnøkler i AWS KMS. Den private nøkkelen blir ikke hentet ut og lagt inn i Sigill-applikasjonen. Signeringen skjer gjennom den forvaltede kryptografiske tjenesten.

Det reduserer blant annet risikoen for at en nøkkel havner i en konfigurasjonsfil, en sikkerhetskopi eller et annet sted den aldri skulle vært.

Når et kundesertifikat aktiveres, kontrollerer vi også at den offentlige nøkkelen i sertifikatet faktisk hører sammen med nøkkelen den skal brukes med.

Dette gjør ikke Sigill til et «FIPS-sertifisert produkt», og det påstår vi heller ikke. Men det betyr at de private plattformnøklene håndteres i en tjeneste bygget på validerte sikkerhetsmoduler, i stedet for inne i selve applikasjonen.

Et bevis må kunne overleve teknologien som laget det

Her kommer vi til noe av det viktigste for Sigill.

Tenk deg at du finner et viktig digitalt bevis fra 2026 i et arkiv i 2041. Programvaren som laget det finnes kanskje ikke lenger. Selskapet kan ha byttet systemer flere ganger. Sertifikatet er for lengst utløpt, og algoritmen som ble brukt er ikke lenger anbefalt.

Kan du fortsatt kontrollere beviset?

Det er dette NSM kaller kryptografisk smidighet: Man må kunne gå videre når kryptografien endrer seg.

For Sigill betyr det blant annet at vi ikke bare lagrer en databaseverdi som sier «dette ble signert med algoritme X». Vi leser informasjonen fra selve de kryptografiske objektene. Vi holder også oversikt over når algoritmer og sertifikater nærmer seg et punkt der beviset bør styrkes.

Et langtidsbevis kan da få et nytt tidsstempel før den gamle kryptografien blir for svak. Det opprinnelige materialet røres ikke. I stedet legger vi et nytt lag utenpå som bekrefter at beviset fortsatt eksisterte i samme form på et senere tidspunkt.

Det er litt som å legge et nytt, sterkere segl rundt en gammel, ubrutt konvolutt.

Og dette skal ikke låse kunden til Sigill. Beviskjeder kan eksporteres i standardiserte formater og kontrolleres med andre verktøy. Målet er at et godt Sigill-bevis fortsatt skal være nyttig selv om Sigill en dag ikke skulle være det.

Så kommer kvantedatamaskinene

Ikke i morgen, nødvendigvis. Men problemet må løses før de er gode nok til å bli et problem.

Mye av kryptografien verden bruker i dag vil være utsatt dersom store nok kvantedatamaskiner blir tilgjengelige. Derfor anbefaler NSM at virksomheter begynner overgangen til post-kvantekryptografi før det haster.

Sigill støtter allerede ML-DSA-87 som et valgfritt tillegg til den klassiske RSA-signaturen i CAdES- og JAdES-bevis.

Vi erstatter altså ikke dagens kryptografi over natten. Vi kan bruke den klassiske og den post-kvantesikre signaturen sammen. Skal et slikt hybridbevis godkjennes fullt ut, må begge signaturene stemme.

Det er med vilje at vi ikke har presset den samme løsningen inn i PDF-signaturer ennå. Standardene og verktøystøtten rundt post-kvantekryptografi i PDF-verdenen er ikke modne nok. I stedet kan en PDF få et separat hybridbevis.

Vi synes det er bedre å være tydelige på hvor teknologien faktisk står enn å krysse av en «post-quantum»-boks og late som hele økosystemet er ferdig.

Det samme gjelder kvalifiserte tillitstjenester. De er fortsatt i hovedsak bygget på klassisk kryptografi. En ML-DSA-signatur blir derfor ikke en kvalifisert signatur bare fordi den ligger sammen med andre kvalifiserte elementer.

Kryptografi kan bevise mye – men ikke sannheten

Dette er et viktig forbehold når man snakker om Sigill, særlig i forbindelse med AI-agenter.

La oss si at en agent registrerer: «Jeg godkjente betalingen fordi beløpet var under 10 000 kroner.»

Sigill kan bidra til å bevise at denne opplysningen ble registrert på et bestemt tidspunkt, og at den ikke senere er blitt endret.

Men Sigill kan ikke bevise at agentens forklaring var sann.

Hvis et system gir oss mangelfulle data, gjør ikke en kryptografisk signatur dataene komplette. Hvis en viktig hendelse aldri blir logget, kan vi ikke trylle den frem senere.

Sigill gjør det som faktisk registreres vanskeligere å endre i ettertid og lettere å etterprøve. Det erstatter ikke god logging, tilgangskontroll, overvåking eller styring av AI-systemer.

For oss er det en viktig grense å være tydelig på.

Her har vi fortsatt arbeid igjen

NSMs anbefalinger peker også på noen områder der Sigill kan bli bedre.

Det viktigste er et samlet kryptografisk register. Vi har allerede mye av informasjonen fordelt mellom kildekode, infrastruktur, sertifikatregistre, konfigurasjon og logger. Men NSMs poeng er nettopp at dette bør samles: Hvilken kryptografi bruker vi? Hvor? Hvilke versjoner? Hvem har ansvar? Når må noe byttes?

Det arbeidet skal vi gjøre mer systematisk.

Det samme gjelder levetiden til nøklene våre. Asymmetriske nøkler i AWS KMS byttes ikke automatisk. En ny nøkkel må opprettes, få riktig sertifikat, settes i drift og den gamle må fases ut på en kontrollert måte. Dette må ikke bare være teknisk mulig; prosedyren må være dokumentert og øvd.

Vi har også noen mindre, men konkrete oppgaver. Deler av sertifikatflyten bruker fortsatt eldre PKCS #1 v1.5 av kompatibilitetshensyn. Det må enten bort eller være et tydelig dokumentert unntak. Vi bør kontrollere hele RSA-profilen når nøkler opprettes, i stedet for å anta at skyleverandørens standardinnstillinger alltid er slik vi forventer. Og selv om vi har tatt de første stegene mot post-kvantekryptografi, er ikke jobben ferdig før også nøkkelhåndtering, rutiner og migrering er gjennomprøvd.

Den offentlige tjenesten støtter dessuten både TLS 1.2 og TLS 1.3. Det kan fortsatt være nødvendig av kompatibilitetshensyn, men slike valg bør vurderes på nytt med jevne mellomrom – ikke bli stående fordi ingen husker hvorfor de ble gjort.

Så hvor står vi?

Det mest interessante med NSMs anbefalinger er egentlig ikke om Sigill kan krysse av flest mulig bokser i dag.

Det interessante er om vi har bygget en plattform som tåler at kryptografien endrer seg.

Det mener vi at vi har et godt utgangspunkt for.

Vi bruker åpne standarder. Bevisene skal kunne kontrolleres uten å stole på Sigill. Private nøkler holdes utenfor applikasjonen. Vi har gått over til moderne RSA-signaturer, bygger inn muligheten for å fornye langtidsbevis og har begynt å bruke post-kvantekryptografi sammen med dagens løsninger.

Samtidig er ikke jobben ferdig. Vi trenger blant annet et bedre samlet kryptografisk register, enda tydeligere rutiner for nøkkelskifte og mer operativ erfaring med post-kvantemigrering.

Og det er kanskje den viktigste konklusjonen fra NSMs veileder: God kryptografi er ikke noe man velger én gang.

Den må vedlikeholdes.