Kryptering

Informasjonen «låses ned» med en nøkkel og kan ikke leses før man har låst den opp igjen med riktig nøkkel. Nøkkelen som brukes til å låse opp trenger ikke å være den samme som ble brukt til å låse ned informasjonen.

Symmetrisk kryptering

Symmetrisk kryptering innebærer at det benyttes samme nøkkel til å låse ned og låse opp informasjon. Denne nøkkelen må utveksles mellom avsender og mottaker på en sikker måte.

Asymmetrisk kryptering

Asymmetrisk kryptering kalles også offentlig nøkkelkryptering (public key). Man benytter et nøkkelpar: én privat og én offentlig nøkkel, som er matematisk relatert til hverandre. Den offentlige nøkkelen kan gjøres tilgjengelig for hvem som helst, og den private er kun kjent av nøkkelens eier. Selv om det er en matematisk sammenheng mellom de to nøklene, så kan ikke den ene utledes av den andre. Den offentlige nøkkelen kan fritt distribueres. Validiteten (gyldighet og ekthet) på den offentlige nøkkelen må imidlertid kontrolleres og administreres.

Kravet til nøkkellengde er forskjellig ved bruk av disse metodene.

Hvilke krav stiller vi til kryptering?

Datatilsynet er ikke riktig myndighet for kryptering og kan ikke veilede i hvordan man krypterer. Vi viser til Nasjonal sikkerhetsmyndighet (NSM) og deres krav til kryptografi, samt anbefalingene de gir i Sikkerhetsbloggen.

Hva gir god nok sikring av konfidensialitet?

Dette er et spørsmål som vi ofte får. Det viktigste er at man benytter seg av utbredte og anerkjente algoritmer og metoder, sammen med en nøkkellengde som er tilstrekkelig.

At noe er godt nok sikret med kryptering avhenger av tre elementer:

1. Funksjoner – kryptografiske mekanismer. Som symmetrisk konfidensialitetsbeskyttelse anbefales AES med 128 eller 256 bits nøkkel. Som avtrykksalgoritme anbefales SHA-2 med minst 256 bits styrke. For RSA-algoritmen anbefales 3072 bits nøkkel.
2. Tillit til kryptomodul. Kryptografiske moduler som genererer, beskytter og bruker private nøkler eller sesjonsnøkler skal evalueres mot Common Criteria, FIPS 140-2 eller tilsvarende.
3. Nøkkelforvaltning. Nøkler kan lages i software (for eget bruk) for datakommunikasjon (data in transit). Nøkler må lages og brukes i hardware for langtidslagring (data at rest). Levetid på nøkler er avhengig av beskyttelsen av disse. Langtidsnøkler skal være asymmetriske og digitale sertifikater, og PKI skal benyttes for nøkkelforvaltning. Nøkler skal slettes på forsvarlig måte etter bruk.

Dersom et av disse elementene mangler eller er svakt, er ikke sikringen god nok.

Hvem avgjør om sikringen er god nok?

Virksomheten (behandlingsansvarlig) må selv foreta en risikovurdering av innholdet den trenger å beskytte. En lønnsslipp er et eksempel på et dokument som kan inneholde sensitive personopplysninger og som derfor krever konfidensialitet.

Hva som benyttes som passord for kryptering og hvordan man håndterer disse må risikovurderes. Passord for dekryptering av lønnsslipp bør for eksempel ikke være fødselsnummer eller andre kjennetegn for mottaker.

Datatilsynet kan gi pålegg om sikring av personopplysninger og fastlegge kriterier for akseptabel risiko forbundet med behandlingen av personopplysninger.

Hva skal man kryptere?

Vi mener det er nødvendig med konfidensialitet når informasjonen som overføres er:

1. Særlige kategorier av personopplysninger (sensitive personopplysninger)
2. fødselsnummer
3. personopplysninger om mange
4. personopplysninger som behandlingsansvarlig har klassifisert som beskyttelsesverdig

Når og hvordan skal man kryptere?

Ved bruk av datakommunikasjon (data in transit)

Personopplysninger som skal overføres mellom to eller flere lokasjoner ved bruk av datakommunikasjon. Dette kan være:

1. mellom virksomhetens (behandlingsansvarliges) egne lokasjoner,
2. mellom virksomheten og leverandør (databehandler eller sikkerhetspart),
3. mellom leverandører og underleverandører, eller
4. mellom leverandørers datasentre.

Overføring av e-post og nettsider

Det er mest vanlig med HTTPS. Man bør bruke høyeste versjon av TLS (Transport Layer Security), og unngå SSL 3.0 (og lavere) som har kjente svakheter. TLS 1.0 er en forbedring av SSL 3.0, TLS 1.2 har også sine problemer, men det kommer an på algoritme og klient. TLS 1.3 er i draft og kommer snart.

Kryptering av enkeltfiler

Dersom man ved overføring av enkeltfiler ikke har mulighet til å kryptere e-posten, eller kan være sikker på at e-postoverføringen er kryptert, kan det være et alternativ å bruke krypteringsmekanismer som er innebygd i programvare. Eksempler på dette er 7zip, PDF eller MS Office av nyere sort. Disse støtter AES 256.

Krypteringsnøkkelen må sikres og sendes separat til mottaker. Et alternativ er å sende nøkkelen som SMS eller muntlig over telefon. Men dette må risikovurderes og vi anbefaler kun å gjøre dette i enkelttilfeller når man ikke har mulighet til å kryptere selve kommunikasjonen. Utfordringer er at man kan mangle kontroll på endepunkter og at man ikke kan sikre seg mot avlytting.

Harddiskkryptering

Harddiskkryptering sikrer i hovedsak konfidensialitetsbeskyttelse av data når datamaskinen er avslått. Dermed er data sikret dersom datamaskinen mistes eller stjeles. Harddiskkryptering har blitt standardfunksjon i moderne operativsystemer. Eksempler på dette er FileVault for MacOS, BitLocker for Windows og maskinvarebasert harddiskkrypto fra Intel.