Behov for innspill: Ny krypteringsløsning i FtPB
Innspill sendes service desken innen 9. juni 2025.
Bakgrunn
Retningslinjene fra Datatilsynet og NSM understreker viktigheten av å bruke kryptering ved overføring av fødselsnummer mellom systemer. Og det settes krav til nøkkelrotasjon og forvaltning for å sikre at krypteringsløsningen følger med utviklingen i teknologi og trusselbilde.
Det er ikke alltid vi krypterer fødselsnummer per nå.
Vi krypterer ikke fødselsnummer når den som fyller ut søknaden oppgir sitt eget – for eksempel som ansvarlig søker eller tiltakshaver.
Kryptering brukes derimot når fødselsnummer hentes fra andre personer. Dette gjelder i to tjenester:
Tiltakshavers samtykke
Nabovarsel
I begge tilfeller er fødselsnummer nødvendig, men den som fyller ut søknaden har ikke tilgang til fødselsnumrene til naboer eller tiltakshaver. Derfor hentes disse separat og krypteres i søknaden, slik at innsenderen ikke får innsyn i dem.
Kryptering i nabovarsel
Under implementeringen av Nabovarsel i Altinn 2 innførte Fellestjenester Plan og Bygg (FtPB) en løsning for kryptering/dekryptering av naboers fødselsnummer basert på asymmetrisk kryptering, med public/private key pair-løsning.
Bakgrunnen for dette sikkerhetstiltaket er personopplysningsloven. Når det skal varsles naboer i forbindelse med et tiltak, har disse naboene ikke selv avgitt sine personopplysninger til den behandlingsansvarlige. De er heller ikke informert om at opplysningene deres er innhentet og behandles. Det stilles derfor strenge krav til håndtering av personopplysninger, særlig fødselsnummer.
Håndtering i søknadssystemene
Nåværende løsningen er at nabovarsel-applikasjonen i søknadssystemene henter inn nødvendige naboopplysninger fra matrikkelen. Fødselsnumrene krypteres deretter med en offentlig nøkkel fra Direktoratet for Byggkvalitet (DiBK). På denne måten sikres fødselsnumrene både når de lagres i søknadssystemene ("at rest") og under overføring.
Søknadssystemene har ikke tilgang til å dekryptere fødselsnumrene, ettersom den nødvendige private nøkkelen ikke er tilgjengelig for dem.
Håndtering i sak-/arkivsystemene
Siden det ikke finnes en dekrypteringstjeneste for sak-/arkivsystemene som benyttes av kommuner og sektormyndigheter, har det vært nødvendig å sende med dette i en separat fil. Denne filen inneholder både krypterte og ukrypterte fødselsnumre. Filen er unntatt offentlig innsyn og skal ikke registreres i postjournalen eller tilgjengeliggjøres for saksbehandler.
Fødselsnummer i filen utledes av den krypterte versjonen overført fra søknadsløsningen med DiBK sin private nøkkel.
Kryptering for fødselsnumre i andre tjenester
Senere, da Tiltakshavers samtykke til byggeplaner ble introdusert, ble en ny mekanisme for kryptering av fødselsnummer utviklet spesifikt for fødselsnummeret til tiltakshaver. Krypteringen baserer seg på samme public/private nøkkeloppsett og konsept som brukes for Nabovarsel.
Per nå er det ikke utført dekryptering av fødselsnummeret for tiltakshaver i XML-filen som videresendes til kommunen.
Plan videre i Altinn 3
Når vi nå går over til Altinn 3 og lager en versjon 5 av nabovarseltjenesten, planlegger Fellestjenester Plan og Bygg å forenkle og forbedre krypteringsløsningen med følgende mål:
Sentralisere krypterings-/dekrypteringsmekanismen: Alle tjenester i FtPB skal benytte en felles tilnærming for håndtering av fødselsnummer for å forenkle administrasjon og sikre konsistent implementering. DiBK og FtPB vil eie, drifte og forvalte en enklere krypteringsløsning.
Sikre samsvar med Datatilsynets- og NSMs-retningslinjer for kryptering: Den valgte krypteringsmekanismen skal være i tråd med beste praksis definert av Datatilsynet og NSM. Det stilles krav til:
algoritme og nøkkelstyrke
forvaltningspraksis som tillater bytte av nøkkel og algoritme
rutinemessig oppfølging av risiko knyttet til eksisterende krypteringsløsning.
Forenkle for søknadsløsningene. Konsesjonshavere skal slippe å oppbevare en public key og ha rutiner for administrasjon ved nøkkelbytte. Søknadsløsningene slipper å ha funksjonalitet for kryptering - men de må gjøre det via API-kall til DiBK sin tjeneste.
Forenkle for kommuner og sektormyndigheter. Saksbehandlingssystemene myndighetene bruker, kan tilrettelegge for dekryptering av fødselsnummer når det trengs i saksbehandlingen. Myndighetene trenger ikke bekymre seg for at lister med dekrypterte fødselsnummer ved en feil blir publisert i postjournaler, tilgjgengelig for saksbehandler eller distribuert i sakspapirer til utvalg. Løsningen kan brukes i alle tilfeller der fødselsnummer ønskes særlig beskyttet.
Styrke sikkerheten ved distribusjon av fødselsnummer. Med løsningen som foreslås kan filen med krypterte/dekrypterte fødselsnummer avvikles. Fødselsnummer kan, av de som har blitt gitt tilgang til tjenesten, dekrypteres ved behov (“On demand”, “Just-In-Time”).
Forslag til ny løsning
Vi ønsker å etablere et nytt API for kryptering og dekryptering av fødselsnummer, som kan benyttes av eksterne systemer.
Implementering og forvaltning av ny løsning
FtPB skal ha ansvar for å utvikle og drifte en API-basert krypterings- og dekrypteringstjeneste, som skal benyttes av konsesjonshaverne. API-et skal sikres gjennom autentisering via Maskinporten, og alle kall skal loggføres.
Krypteringsløsningen vil inneholde bakover-kompatibilitet, slik at et fødselsnummer kryptert av tjenesten alltid vil kunne dekrypteres.
Løsningen vil kunne kryptere fødselsnummer i bulk, antakelig i en asynkron prosess, eller ett og ett i en synkron prosess. Er det behov for dekryptering i bulk kan det tilrettelegges for, ellers vil det kun tilbys dekryptering av ett og ett fødselsnummer.
Siden dette er forandring til en eksisterende løsning ber vi om innspill fra konsesjonshaverne om deres behov slik at vi får laget en god løsning med en overkommelig overgangsfase.
Bruken av dagens løsning med distribuert public key vil bli avviklet og det vil ikke bli tatt i mot fødselsnummer kryptert med denne nøkkelen.
Innspill sendes service desken og fristen er 9. juni 2025.