Sådan fungerer MitID-underskriften teknisk set indefra

Annonce – sponsoreret indhold.

MitID-underskriften bygger på en kompleks teknisk infrastruktur, der kombinerer avanceret kryptografi, certifikathåndtering og flertrinsgodkendelse i ét samlet system. For ingeniører, IT-ansvarlige og systemintegratorer er det ikke længere tilstrækkeligt at vide, at digital signering er sikker — forståelsen af de underliggende mekanismer er afgørende, når MitID-signering integreres i automatiserede arbejdsflows på tværs af ERP-systemer, produktionslinjer og dokumenthåndteringsplatforme. Denne artikel dissekerer den tekniske arkitektur lag for lag: fra det øjeblik brugeren godkender et dokument, til den kryptografiske forsegling er komplet og verificerbar. Målet er at give dig en operationel forståelse, der kan omsættes direkte til systemdesign og sikkerhedsvurderinger.

Autentifikationsarkitekturen bag MitID-signering

MitID opererer som en fødereret identitetsinfrastruktur, hvor flere komponenter samarbejder om at etablere en pålidelig digital identitet. Kernen i systemet er en OpenID Connect-baseret protokol, der håndterer kommunikationen mellem serviceudbydere (de systemer, der anmoder om signering) og MitID’s centrale identitetstjeneste.

Selve handlingen — når en bruger vælger at underskriv med MitID — udløser en kæde af kryptografiske verifikationstrin, der er værd at forstå for enhver, der integrerer signering i automatiserede systemer. Flowet initieres med en authorization request, der sendes til MitID-brokeren med specificerede krav til sikkerhedsniveau (Level of Assurance).

Arkitekturen er designet i tre primære lag:

• Identitetslag: Verificerer brugerens CPR-nummer mod Det Centrale Personregister og etablerer en unik identifikator
• Autentifikationslag: Håndterer den faktiske brugerverifikation gennem MitID-appen eller kodeviser
• Signeringslag: Genererer den kryptografiske signatur baseret på brugerens godkendelse

Når en signeringsanmodning modtages, opretter MitID-brokeren en session context, der indeholder hashværdien af det dokument, der skal signeres. Denne hash beregnes typisk med SHA-256 eller SHA-384 og fungerer som et fingeraftryk, der sikrer dokumentintegritet gennem hele processen.

PKI-infrastruktur og certifikathåndtering i realtid

Den tekniske rygrad i MitID-underskriften er en Public Key Infrastructure (PKI), der administreres af kvalificerede tillidstjenesteudbydere godkendt under eIDAS-forordningen. I modsætning til simple elektroniske signaturer, hvor identitetsverifikation ofte begrænser sig til e-mail-bekræftelse, involverer MitID-signaturen udstedelse af et kvalificeret certifikat i signeringsøjeblikket.

Certifikathåndteringen følger en just-in-time provisioning-model:

1. Brugeren initierer signeringen og autentificerer sig via MitID
2. MitID-brokeren anmoder om et signeringscertifikat fra den tilknyttede Certificate Authority (CA)
3. CA’en validerer brugerens identitet mod MitID’s identitetsattributter
4. Et kortlivet X.509-certifikat genereres med brugerens offentlige nøgle
5. Certifikatet anvendes til at signere dokumentet og indlejres i signaturen

Det centrale sikkerhedsprincip er, at den private nøgle genereres og opbevares i et Hardware Security Module (HSM) hos tillidstjenesteudbyderen. Brugeren autoriserer anvendelsen af nøglen gennem MitID-autentifikationen, men nøglen forlader aldrig det sikrede miljø. Dette eliminerer risikoen for nøglekompromittering på brugerens enhed.

Certifikaterne følger RFC 5280-standarden og indeholder kritiske felter som:

• Subject Distinguished Name: Brugerens fulde navn og CPR-nummer (sidstnævnte ofte hashet)
• Key Usage: Specificeret til nonRepudiation, hvilket juridisk binder underskriveren
• Certificate Policies: OID-værdier der identificerer certifikatet som kvalificeret under eIDAS
• Validity Period: Typisk 15-30 minutter for engangscertifikater

Flertrinsgodkendelsens rolle i sikkerhedsmodellen

MitID implementerer en multi-faktor autentifikation (MFA), der kombinerer mindst to uafhængige faktorer: noget brugeren ved (PIN-kode), noget brugeren har (MitID-app eller kodeviser), og i visse konfigurationer noget brugeren er (biometrisk verifikation på enheden).

For signeringspecifikke flows tilføjes et ekstra lag: explicit consent. Brugeren præsenteres for en opsummering af, hvad der signeres, og skal aktivt bekræfte handlingen. Dette adskiller en MitID-signatur fra en simpel login-handling og etablerer den juridiske viljestilkendegivelse.

Den tekniske implementering af flertrinsgodkendelsen bygger på FIDO2/WebAuthn-protokollen for kommunikation mellem MitID-appen og backend-systemerne. Hver autentifikationshandling genererer en unik assertion, der indeholder:

• En kryptografisk signatur af challenge-værdien fra serveren
• Authenticator data med informationer om den anvendte enhed
• Client data med kontekst om signeringsanmodningen

For automatiserede workflows er det væsentligt at forstå, at MitID’s sikkerhedsmodel ikke tillader fuldautomatisk signering uden brugerinteraktion. Dette er en designmæssig beslutning, der sikrer non-repudiation — brugeren kan ikke efterfølgende benægte at have signeret. Systemintegratorer må derfor designe workflows, der inkluderer et brugerinteraktionstrin, typisk via push-notifikation til MitID-appen.

Protokolniveau: OAuth 2.0 og SAML i signeringsflowet

MitID eksponerer sine tjenester gennem standardiserede protokoller, der muliggør integration med eksisterende enterprise-systemer. De to primære integrationsmodeller er OAuth 2.0/OpenID Connect for moderne API-baserede integrationer og SAML 2.0 for legacy-systemer.

I OAuth 2.0-flowet for signering anvendes en udvidet authorization code grant med specifikke scope-parametre:

• openid: Basis-scope for identitetstoken
• mitid: Adgang til MitID-specifikke attributter
• sign: Indikerer at flowet involverer dokumentsignering

Signeringsanmodningen inkluderer desuden en signText-parameter, der indeholder den tekst eller hash, brugeren skal godkende. For dokumentsignering transmitteres typisk en SHA-256 hash af dokumentet sammen med en læsbar beskrivelse.

Responsflowet returnerer et ID token og et access token. ID tokenet indeholder brugerens verificerede identitetsattributter, mens access tokenet kan anvendes til at hente den genererede signatur fra signeringstjenesten. Signaturen leveres i PAdES-format (PDF Advanced Electronic Signatures) for PDF-dokumenter eller XAdES-format (XML Advanced Electronic Signatures) for strukturerede data.

Tekniske krav til serviceudbydere

For at integrere MitID-signering skal serviceudbydere opfylde specifikke tekniske krav:

1. Registrering hos MitID-brokeren: Tildeling af client_id og client_secret
2. Implementering af redirect endpoints: Sikre HTTPS-endpoints til callback-håndtering
3. Token-validering: Verifikation af JWT-signaturer mod MitID’s offentlige nøgler
4. Sikker opbevaring: Krypteret lagring af modtagne tokens og signaturer

Dokumentintegritet og tidsstemplingsmekanismer

En MitID-signatur er kun værdifuld, hvis den kan verificeres på et vilkårligt fremtidigt tidspunkt. Derfor inkluderer signeringsinfrastrukturen kvalificerede tidsstempler fra en betroet Time Stamping Authority (TSA).

Tidsstemplet beviser, at signaturen eksisterede på et specifikt tidspunkt, hvilket er kritisk for juridisk gyldighed. Teknisk set er tidsstemplet en signatur fra TSA’en over signaturen og et præcist timestamp, typisk med millisekund-opløsning synkroniseret via NTP mod autoritative tidskilder.

For langtidsvalidering anvender systemet PAdES-LTV (Long Term Validation) formatet, der indlejrer alle nødvendige verifikationsdata i selve dokumentet:

• Signeringscertifikatet og hele certifikatkæden op til root CA
• Certificate Revocation Lists (CRL) eller OCSP-responser der beviser, at certifikaterne var gyldige på signeringstidspunktet
• Tidsstempler der forsegler signaturen og verifikationsdata

Dette sikrer, at et dokument kan verificeres selv årtier efter signering, uafhængigt af om de oprindelige CA’er stadig eksisterer.

Praktiske implikationer for automatiserede dokumentflows

For organisationer der bygger automatiserede arbejdsflows med MitID-signering, er der flere arkitektoniske overvejelser. Det asynkrone flow, hvor brugeren modtager en notifikation og signerer på et senere tidspunkt, kræver robust state management i det kaldende system.

Typiske integrationsmønstre inkluderer:

• Webhook-baseret notifikation: Signeringstjenesten kalder et endpoint, når signaturen er komplet
• Polling-model: Det kaldende system checker periodisk signeringsstatus
• Event-drevet arkitektur: Signeringshændelser publiceres til en message broker

For produktionsvirksomheder der håndterer store dokumentvolumener, er det relevant at overveje batch-signering, hvor flere dokumenter kan signeres i én brugerhandling. Dette reducerer friktionen markant i workflows med mange dokumenter, eksempelvis ved kvartalsafslutninger eller kontraktfornyelser.

Når virksomheder vurderer automatiseringsløsninger generelt, er det værd at bemærke, at principperne bag sikker signering — autentifikation, autorisation og auditability — gælder bredt. Som beskrevet i artiklen om valg af industrielle maskiner, handler effektiv systemintegration om at forstå de underliggende mekanismer, ikke blot overfladen.

Sikkerhedsvurdering af eksisterende integrationer

IT-ansvarlige bør regelmæssigt evaluere deres MitID-signeringsintegrationer mod følgende kriterier:

• Token-håndtering: Opbevares access tokens korrekt krypteret med begrænset levetid?
• Certificate pinning: Validerer systemet MitID-brokerens certifikat korrekt?
• Audit logging: Logges alle signeringsanmodninger med tilstrækkelig detaljeringsgrad?
• Fejlhåndtering: Håndteres timeout og fejlscenarier uden at kompromittere sikkerhed?
• Nøglerotation: Følger systemet automatisk med, når MitID roterer sine signeringsnøgler?

En robust integration bør desuden implementere rate limiting for at forhindre misbrug og anomalidetektion for at identificere usædvanlige signeringsmønstre, der kunne indikere kompromittering.

Ofte stillede spørgsmål

Hvordan verificerer jeg en MitID-signatur programmatisk?

Verifikation af en MitID-signatur involverer flere trin: Først ekstraheres signaturen og certifikatet fra dokumentet (typisk i PAdES- eller XAdES-format). Derefter valideres certifikatkæden op til en betroet root CA, og det kontrolleres at certifikatet ikke var revokeret på signeringstidspunktet via OCSP eller CRL. Endelig verificeres selve signaturen kryptografisk ved at dekryptere den med certifikatets offentlige nøgle og sammenligne med dokumentets hash. Biblioteker som iText (Java), PyPDF (Python) eller iTextSharp (.NET) tilbyder højniveau-API’er til denne proces.

Kan MitID-signering integreres i on-premise systemer uden cloud-afhængighed?

MitID er en cloud-baseret tjeneste, og selve autentifikationen og certifikatudstedelsen kræver kommunikation med MitID’s backend-infrastruktur. On-premise systemer kan dog integrere via en lokal broker eller gateway, der håndterer kommunikationen med MitID. Det signerede dokument kan derefter opbevares lokalt. Organisationer med strenge data residency-krav bør vælge en signeringstjenesteudbyder, der tilbyder dedikerede instanser inden for ønskede jurisdiktioner.

Hvad sker der teknisk, hvis brugerens MitID-app er offline under signeringen?

Hvis MitID-appen er offline, kan signeringen ikke gennemføres i realtid. Signeringsanmodningen forbliver aktiv i MitID-systemet i en konfigurerbar periode (typisk 5-15 minutter). Når brugeren får netværksforbindelse igen, modtager appen en push-notifikation. For systemer der kræver øjeblikkelig signering, kan fallback til MitID-kodeviser (hardware-token) tilbydes, da denne ikke kræver netværksforbindelse på brugerens side — kun systemet der initierer signeringen skal være online.

Hvordan sikres det at signeringstjenesten ikke kan forfalske signaturer på brugerens vegne?

Arkitekturen anvender flere sikkerhedsmekanismer: Den private signeringsnøgle opbevares i et HSM (Hardware Security Module) med FIPS 140-2 Level 3 certificering, hvor nøglen aldrig kan ekstraheres. Anvendelse af nøglen kræver en aktiv autentifikation fra brugeren via MitID-appen, hvilket genererer en kryptografisk attestation. Alle operationer logges i et manipulationssikret audit-log. Tillidstjenesteudbyderne underlægges desuden regelmæssige revisioner af nationale tilsynsmyndigheder under eIDAS-forordningen, hvilket sikrer operationel integritet.