Sikkerhetsbloggen

Håndtering av passord er, som håndtering av nøkler, ikke lett. Det har allikevel skjedd endel de siste årene for å forenkle vanlige (hjemme)-brukeres passordhåndtering. Det har vært stor fokus på folkeopplysning, som å fortelle at man bør unngå å ha de samme passordene på alle steder på nettet, og det har kommet passordhåndteringsprogrammer som generer sterke passord, og lagrer og synkroniserer disse mellom forskjellige enheter.

Eksempler på passordhåndteringsprogrammer er Password Safe, KeyPass og LastPass.

Ill.: www.colourbox.no

Som for passord, begynner det etterhvert også å bli mange anvendelser av nøkler og sertifikater som brukere må håndtere selv. Selv om det nok ikke foreløpig er like utbredt, vil mer avanserte brukere nok allerede ha vært borti flere systemer hvor nøkler og sertifikater har vært brukt.

Eksempler på systemer som benytter nøkler og sertifikater som vanlige (hjemme)-brukere kan komme borti:

• 2-veis autentisering på nettsider (som Skandiabanken)
• Administrasjonssertifikat i nettverksutstyr
• Filkrypteringsnøkler (som EFS, komprimerte arkiv og datafiler for Outlook)
• Fjerntilgangssertifikater (som virtuelle private nett (VPN) og Secure Shell (SSH))
• Gjenopprettingsnøkler for krypterte minnepinner
• Harddiskkrypteringsnøkler
• Kryptert e-post (som Pretty Good Privacy (PGP) og varianter, og S/MIME)

I tillegg kommer sertifikater fra eID-leverandører, men dette er nøkler og sertifikater som brukeren ikke selv forvalter.

Ill.: www.colourbox.no

De fleste anvendelsene listet her, utenom PGP, er for brukeren selv; brukeren håndterer nøkler for selv og de trenger ikke distribueres til andre. Det betyr allikevel ikke at alle nøkkelhåndteringsproblemene er løst. Fortsatt gjenstår viktige deler, slik som nøkkelgenerering og sikkerhetskopi og gjenoppretting.

Ønskede egenskaper i et nøkkel- og sertifikathåndteringsprogram for vanlige brukere kunne dermed være noe som:

• Slumptallsgenerering (med mulighet for import fra ekstern slumptallskilde)
• Nøkkelavledningsalgoritmer
• Nøkkelgenerering for symmetriske og asymmetriske nøkler
• Sertifikatgenerering (med mulighet for å bestemme hvilke felter sertifikatet skal ha) og signering sertifikatet (mulighet for minimum én-lags PKI)
• Passord- eller nøkkelbeskyttet nøkkellager
• Sikkerhetskopi og gjenoppretting av nøkler
• Synkronisering av nøklene mellom forskjellige enheter

Det finnes store avanserte systemer, som PKI-produkter, som kan gjøre flere av disse tingene, men det er ikke programmer som vanlige brukere kan forholde seg til. Det finnes også mange enkle verktøy som tar hånd om enkelte punkter i listen, men gjerne via kommandolinje, som igjen gjør det vanskelig for vanlige brukere.

Dersom noen har forslag til applikasjoner, systemer eller tjenester som vanlige brukere kan bruke for å håndtere nøkler og digitale sertifikater (X.509), hadde det vært fint om dere skriver det inn i en kommentar nedenfor.

Om noen har flere idéer til hva et slikt program burde inneholde av funksjonalitet, er det fint om disse også skrives inn i kommentarfeltet.

Med Intels nye Ivy Bridge-prosessorer kommer RdRand-instruksjonene. Disse instruksjonene skal gi store mengder gode slumptall direkte fra prosessoren. Som tidligere nevnt (her og her) er god slumptallsgenerator viktig for å lage gode nøkler.

Også AMD jobber med å implementere slik teknologi, men foreløpig er lanseringsdato ukjent.

I den gode artikkelen Behind Intel’s New Random-Number Generator i IEEE Spectrum September 2011 er teknologien bak RdRand beskrevet. I tillegg har Intel lagt ut implementeringsveiledning for RdRand her. Sistnevnte inneholder også litt mer teknisk informasjon om bruk av AES-CBC-MAC for utjevning av slumptallsstrømmen og hvordan dette benyttes som frø til AES-CTR for å møte krav i NIST Special Publication 800-90.

Ill.: www.colourbox.no

NSM synes det er bra at en god slumptallsgenerator implementeres i prosessoren; på denne måten kan alle brukere få tilgang til gode slumptall. I maskiner med Trusted Platform Module (TPM) har man kunnet bruke denne til det samme, men det er hovedsakling bare datamaskiner for bedriftsmarkedet som har TPM.

Når slike muligheter tilbys i maskinvaren, er det viktig at programvaren utnytter dette. For de fleste anvendelser vil NSM se det naturlig at plattformen håndterer tilgangen til slumptallsgeneratoren. Dette kan fore eksempel gjøres ved at eksisterende API for slumptallsgenerering henter slumptall fra  TPM eller CPU når dette finnes, enten direkte/alene eller som enda en kilde til plattformens slumptallsgenerator.

I enkelte systemer benyttes forskjellige deterministiske variable (som prosess-identifikater, arbeidsminne og nettverksadresse (MAC)) som ingredienser i en miks som blir tilsynelatende tilfeldig. Dersom man legger til ovennevnte slumptallskilder i denne miksen, vil alle applikasjoner og tjenester som benytter APIet for å generere slumptall få bedre slumptall uten at applikasjonen eller tjenesten må skrives om.

Tidligere har AES blitt implementert i prosessorer fra både AMD og Intel. Det som kan bli mulig nå er å benytte både slumptallsgenerering og AES-kryptering i prosessoren. Man kan altså generere en nøkkel, kryptere det man vil beskytte med nøkkelen og så kryptere nøkkelen med en offentlig nøkkel. På den måten kan man hindre at nøkkelen blir tilgjengelig for resten av systemet.

Kerckhoffs‘ kjente prinsipp sier at et «kryptosystem skal være sikkert selv om hele systemet, unntatt nøkkelen, er kjent». Det er nøkkelen som beskytter eller gir tilgang til informasjon. Dersom flere får tilgang til (kopi av) nøkkelen, vil flere få tilgang til informasjonen. Dette er helt analogt meg en husnøkkel. Jo flere som har nøkkelen, jo flere kommer inn, uansett om de er ønsket eller ei.

Selv om NSM enig i Kerckhoffs prinsipp, har NSM i god tradisjon benyttet egne, hemmelige [1] algoritmer for beskyttelse av gradert informasjon. Dermed har angriperen måtte både finne algoritme og nøkkel for å kunne dekryptere informasjonen som våre kryptosystemer har beskyttet.

NSM godkjenner allikevel bruk av kjente algoritmer (som tidligere nevnt her) for beskyttelse av gradert informasjon på gitte graderinger.

Men, tilbake til prinsippet og nøkler. NSM er veldig opptatt av kvaliteten og sikkerheten til nøkler og dette sikres gjennom nøkkelhåndteringen. Med nøkkelhåndtering menes for eksempel:

• Nøkkelgenerering
• Nøkkelbeskyttelse
• Nøkkelbruk
• Nøkkeldeponering og sikkerhetskopi
• Nøkkelsletting

NSM ser at en rekke løsninger kommer nøkkelferdig (ikke i betydningen hus) og det gjør at man med en gang begynner å lure. Og hvis man ikke begynner å lure, burde man gjøre det.

Ill.: www.colourbox.no

Når kryptoutstyr kommer med ferdige nøkler betyr det at man ikke har kontroll over nøkkelgenereringen eller om det finnes noen sikkerhetskopier. Noen ganger blir sistnevnte presentert som et gode; dersom man mister egne nøkler, kan man ta kontakt med leverandør og få tilgang til disse igjen (forhåpentligvis gjennom en autorisert prosess). Andre ganger er det en selvfølge at leverandøren ikke har tatt kopi av nøklene før utstyret ble levert.

I tillegg må man huske at leverandøren må følge lover og regler i det landet det holder til i. Så dersom leverandøren har laget en nøkkel og har en kopi, kan landets myndigheter ved lov få tilgang til nøkkelen.  Dette er også viktig å tenke på når man lagrer nøkler i skyen, og skyen glir over himmelen og landegrenser.

Når prinsippet er at alt kan være kjent, utenom nøkkelen, må man være helt sikker på at nøkkelen ikke kjent for uvedkommende. NSM ønsker derfor ikke nøkkelferdige løsninger. Det beste er om man kan benytte et av NSMs allerede godkjente nøkkelhåndteringssystemer, men om dette ikke lar seg gjøre, må leverandøren også tilby et sertifisert nøkkelhåndteringssystem og en godkjent slumptallsgenerator.

• Et godt nøkkelhåndteringssystem må håndtere alle aktuelle operasjoner for nøkkelen og gjøre det på en god måte. Det an gjøres fra det enkle, som kun å holde oversikt over hvilken nøkkel-ID som befinner seg i hvilket utstyr, til det mer avanserte, som nøkkeldeponering og -gjenoppretting.
• En god slumptallsgenerator gir grunnlaget for en god nøkkel og må sørge for at like nøkler aldri kan lages.

At NSM ønsker egen kontroll med nøkler, står ikke i strid med tidligere innlegg om bruk av Buypass’ eller Comfides’ PKI-løsninger. NSMs krav gjelder for skjermingsverdig informasjon, mens i det tidligere innlegget ble det pekt på allerede godkjente løsninger for bruk mot offentlig forvaltning.

[1] Hemmelige i vanlig forstand, ikke nødvendigvis graderingen HEMMELIG.

En avtrykksalgoritme er en algoritme som tar inn en melding av vilkårlig lengde og gir et resultat av fast lengde. Dette brukes ofte i forbindelse med digitale signaturer, hvor man i stedet for å signere et helt dokument, signerer et avtrykk av dokumentet.

Dette krever blant annet sikkerhet for at ingen andre meldinger kan gi samme avtrykk, ellers ender man opp med at to ulike dokumenter kan ha samme, gyldige signatur.

Ill.: www.colourbox.no

For et system NSM ble bedt om å se på, ble det foreslått å bruke avtrykk for å skjule deler av innholdet. Systemet bestod blant annet av en database hvor innholdet skulle record-krypteres, men for å kunne søke effektivt i denne databasen ønsket man å søke på et par sensitive felt. Forslaget var da å lage avtrykk av disse feltene og lagre avtrykkene sammen med resten av den krypterte record‘en.

Ved søk i databasen ville man lage et avtrykk av søkestrengen, finne dette i databasen og hente ut record‘en. Denne kunne så sendes til rette vedkommende, med autorisasjon til innsyn, uten at databaseadministrator eller andre uvedkommende kunne se innholdet.

Problemet med denne løsningen var at feltene de ønsket å lage avtrykk av var betydelig mindre enn selve avtrykket. Dermed ble utfallsrommet av avtrykk betydelig mindre enn det teoretiske utfallsrommet som den aktuelle avtrykksagloritmen (SHA-256) gir.

For å eksemplifisere dette; dersom databasen består av sensitive personopplysninger og man har knyttet disse til personer, ønsker man altså å kryptere all informasjon om personen, samt lage to avtrykk, Avtrykk(<fornavn>) og Avtrykk(<etternavn>). For å finne personen i databasen, lager man avtrykk av fornavn og etternavn og søker etter dette i databasen. Deretter tar man den krypterte record‘en til denne personen, sender innholdet til autorisert personell som så dekrypterer innholdet.

Ill.: www.colourbox.no

Siden antall fornavn og etternavn ikke er veldig stort (i forhold til 256 bit) blir utfallet av et slikt avtrykk lite. Dersom man ser på Jenters første fornavn 2002-2011 finner man 571 unike fornavn, og i kombinasjon med flere fornavn, samt guttenavn, ender man kanskje opp med noen tusen unike kombinasjoner av fornavn. Uten tilsvarende referanse for etternavn, kan man kanskje anta at det ikke er mer enn noen tusen etternavn heller.

Dersom databaseadministratoren ønsker å finne ut hvilke navn databasen består av, er det bare å lage en avtrykkstabell av alle kjente fornavn (enkle og doble) og en annen av alle kjente etternavn. Deretter er det bare å matche disse avtrykkene med innholdet i databasen og navnene blir kjent for den de skulle være skjult for.

Lesere av Sikkerhetsbloggen har sikkert allerede forstått at NSM er positive til Public Key Infrastructure og digitale sertifikater. En av oppgavene NSM har er håndtering av nøkler for graderte systemer. I hovedsak skjer dette ved bruk av EKNAS/NOR (Elektronisk Krypto Nøkkeladministrasjonssystem for Norge) som forvaltes av National Distributing Authority Norway (NDA) i NSM. Dette er et spesialutviklet system for generering og distribusjon av nøkler, samt regnskapsførsel av nøkler og kryptoutstyr. Mer om dette vil komme i et senere innlegg.

I tillegg håndterer NSM asymmetriske nøkler, men dette er bare for lavgraderte (BEGRENSET) anvendelser.

NSM har ingen myndighet eller krav til krypto utenom sikkerhetsloven, men tilbyr allikevel råd og veiledning i forbindelse med bruk og implementering av krypto. Dette tilbys stort sett andre offentlige etater, men NSM kan også hjelpe andre halvoffentlige eller private organisasjoner med dette. Rådene NSM gir i disse tilfellene er basert på de anbefalte kravene til Moderate nivå, gitt i kapittel 8 av NSM Cryptographic Requirements.

Ill.: www.colourbox.no

Ett av rådene NSM har gitt har vært i forbindelse med etablering av eID i Norge. NSM har anbefalt at en offentlig PKI-løsning (med lokale sertifikater og private nøkler i hardware) til landets borgere bør opprettes for å tilby brukerne en god og sikker måte å autentisere seg overfor staten og hverandre. Selv om det ikke har blitt etablert som en offentlig løsning, tilbyr Buypass og Commfides sertifikater på hardware token for integritetsbeskyttelse, autentisering og signering.

I tillegg har NSM anbefalt at en slik løsning også må tilby konfidensialitetstjenester. Dette for å sørge for god toveis konfidensialitetsbeskyttelse mellom borgerne og staten, og mellom borgerne. Også dette tilbys fra ovennevnte leverandører.

Selv om NSM ikke har ansvar for personvern eller annen beskyttelse av personlige opplysninger, mener NSM at god integritetsbeskyttelse, sterk autentisering og konfidensialitetsbeskyttelse er nødvendig for å oppnå god grunnsikkerhet for samfunnets bruk av Internett.

Disse løsningene åpner altså for full ende-til-ende-sikkerhet mellom borgere og staten, mellom borgere og mellom borgere og bedrifter, men de benyttes i liten grad.

Posten har for en liten stund tilbake lansert Digipost. Dette er en elektronisk postkasse hvor man får tilsendt brev fra deres samarbeidspartnere og kan få tilgang til disse fra hvor enn man er i verden, uten å måtte gå hjem til sin egen fysiske postkasse. Det som er spesielt i denne sammenheng er at man trenger enten BankID eller Buypass for å registrere seg der.

Altså, for å registrere seg for å få tilgang til en side for å lese brev, trenger man et Buypass-sertifikat som gir mulighet for at avsenderen kunne kryptert brevet og sendt det direkte til mottaker, uten at Posten trenger å ha brevet i klartekst på sine servere.

Også på Altinn kan man benytte Buypass-sertifikatet for å logge inn, og her kan man også benytte Commfides-sertifikat. Det kunne dermed blitt åpnet for at alle som har logget inn med slike sertifikat kan få tilsendt dokumenter kryptert i sertifikatets levetid. På den måten kunne Altinn kryptert alle dokumentene som skulle ut med brukernes sertifikater og deretter sendt dokumentene til e-postadressene som er registrert i sertifikatet.

Ill.: www.colourbox.no

Den vanlige motforestillingen mot PKI er at det er dyrt å utstede og håndtere sertifikater og token til sluttbrukere, og at det er vanskelig for sluttbrukerne å installere og ta i bruk løsningene. Allikevel viser det seg at det er to løsninger som er utbredt i Norge og som brukere, enten gjennom jobben eller på eget initiativ, har skaffet seg og benytter.

Nøkkelhåndteringen, som normalt sees på som det vanskeligste ved bruk av krypto, er altså håndtert av tredjepart. Det er derfor synd at ikke flere gode ende-til-ende-sikkerhetsløsninger tilbys når det finnes nøkkelhåndtering for å understøtte dem.