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

NSMs kryptografiske anbefalinger handler om mer enn valg av algoritmer. De handler også om nøkkelbeskyttelse, evnen til å bytte kryptografi når det trengs, og hvordan man forbereder seg på det som kommer etter dagens løsninger. Vi har sett på hvordan Sigill står seg mot anbefalingene.

Kryptografi har nemlig en litt ubehagelig egenskap: Det som er sikkert i dag, trenger ikke være sikkert om ti å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å.

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, og de kan ikke eksporteres. Når plattformen skal signere, sendes kun innholdets hash til KMS. Selve signeringsoperasjonen utføres inne i AWS' FIPS 140-3-validerte maskinvaresikkerhetsmoduler, og bare den ferdige signaturen kommer tilbake. Den private nøkkelen finnes aldri noe annet sted.

Det fjerner 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.

En presisering om FIPS: Validering etter FIPS 140-3 gjelder kryptografiske moduler, ikke produktene som bruker dem. Det riktige utsagnet er derfor ikke at Sigill «er FIPS-sertifisert», men at alle Sigills private nøkler opprettes, lagres og brukes utelukkende i FIPS 140-3-validerte moduler. Det er modulen som valideres – og det er nettopp den vi lener oss på.

Hvor er dataene?

Mange virksomheter, særlig i offentlig sektor, stiller et helt betimelig spørsmål før de tar i bruk en skytjeneste: Hvor behandles dataene våre, og hvem kan se dem?

Sigill har et uvanlig godt utgangspunkt for å svare på det, av en enkel grunn: Vi trenger som regel ikke se innholdet i det hele tatt.

Et segl eller tidsstempel lages ut fra en kryptografisk hash av innholdet – enten det er et dokument, en fil, strukturerte data eller hendelser fra et AI-system. Hashen kan beregnes hos kunden, slik at innholdet aldri forlater virksomheten. Sigill mottar bare hashen, og den kan ikke brukes til å gjenskape innholdet.

Selve plattformen kjører i AWS' region i Stockholm, innenfor EU/EØS. Det gjelder også nøklene i KMS.

Og datasuverenitet handler ikke bare om hvor dataene ligger, men om å ikke være innelåst hos én leverandør. Derfor gjentar vi det gjerne: Bevisene følger åpne standarder, kan eksporteres og kan kontrolleres med uavhengige verktøy. Det gjelder også uavhengighet fra oss.

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. Mange avtaler lever så lenge – en låneavtale kan ha både 20 og 30 års løpetid. 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. Den opprinnelige kryptografien 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 lenger skulle finnes.

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å områder der vi skal videre.

Det viktigste er et samlet kryptografisk register. Mye av informasjonen finnes allerede – i kode, infrastruktur og sertifikatregistre – men NSMs poeng er at den bør samles ett sted: Hvilken kryptografi bruker vi, hvor, og når må noe byttes? Det arbeidet skal vi gjøre mer systematisk.

Rutinene rundt nøklenes livssyklus skal samme vei. Planlagte nøkkelskifter skal ikke bare være teknisk mulige; de skal være dokumenterte og øvde.

Og selv om vi har tatt de første stegene inn i post-kvantekryptografi, er ikke jobben ferdig før rutiner og migrering er like gjennomprøvd som resten. Noen eldre kompatibilitetsvalg står også på listen – de skal enten fases ut eller stå igjen som tydelig dokumenterte, bevisste unntak.

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 forlater aldri de validerte modulene. 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.