Nye retninger innen krypto for BEGRENSET

Bakgrunn

De siste årene og ikke minst det siste året har det skjedd endel ting som medfører at kravene til kryptomekanismer for beskyttelse av BEGRENSET informasjon må revideres. Noe av dette er ferdigstilt og har blitt offentliggjort, men ikke alle kravdokumentene er oppdatert ennå. For å gjøre endringene og noen av vurderingene bak kjent, benyttes derfor Sikkerhetsbloggen.

Ill.: Colourbox.no

Ill.: Colourbox.no

Det har lenge vært ønskelig å benytte kommersielle mekanismer for beskyttelse av BEGRENSET informasjon. Både systemeiere og NSM  har sett at kommersielle løsninger inneholder flere og bedre kryptomekanismer, noe som var grunnlaget for at NSM publiserte «Standard Cryptographic Requirements» (senere endret til «NSM Cryptographic Requirements» i 2004).

Selv om NSM allerede for ni år siden åpnet for kommersielle, tredjepartsevaluerte produkter, har det vist seg at det ikke er mange produkter som er gode nok for å beskytte BEGRENSET.

For en tid tilbake begynte amerikanske sikkerhetsmyndigheter (National Security Agency (NSA)) å se på muligheten for å benytte kommersielle kryptomekanismer for beskyttelse av alle graderinger gjennom programmet Commercial Solutions for Classified (CSfC).

Allerede her vil noen reagere, da de ser at amerikanerne åpner for alle graderinger, mens Norge kun åpner for BEGRENSET. Det er dog en rekke flere forutsetninger som må oppfylles for at førstnevnte skal kunne bli godkjent.

CSfC baserer seg på å benytte to uavhengige kommersielt tilgjengelige løsninger som benyttet sammen gir nødvendig tillit til at sikkerheten er ivaretatt. Det enkleste eksemplet på slik bruk, er kryptert VPN hvor man etablerer kryptert tunnel gjennom en annen kryptert tunnel. Se illustrasjon under fra Commercial Solutions for Classified (CSfC) Multi-Site Virtual Private Network Capability Package:

Figure 1. Two IPsecTunnels Protect Data across a Black Network

Figure 1. Two IPsecTunnels Protect Data across a Black Network

Som nevnt over er det flere forutsetninger for få en løsning godkjent etter CSfC-programmet enn for beskyttelse av BEGRENSET. Mens NSM vil tillate de fleste kombinasjoner evaluerte og sertifiserte produkter, har NSA strengere krav til CSfC. I hovedsak går dette ut på uavhengighet. NSA krever produktene som benyttes sammen er så uavhengige hverandre som mulig, og med uavhengighet menes blant annet ulike protokoller, ulike kodebaser, ulike operativsystem, ulike kjøretidsmiljø og ulike nøkkelkilder. Dette er nærmere beskrevet i Fred Roeper og Neal Zirings presentasjon ved RSA Conference 2012.

I tillegg ble Forskrift om informasjonssikkerhet revidert i fjor sommer hvor spesielt krav til informasjonssystemsikkerhet ble forbedret. Disse kravene ligger til grunn for godkjenning av integrerte kryptosystemer.

Ill.: Colourbox.no

Ill.: Colourbox.no

Oppdaterte krav

Så til de faktiske kravene som er oppdaterte og gjeldene.

I hovedsak er kryptoløsninger for BEGRENSET sterkt integrert mot operativsystem/plattform og kommersielt utviklet. NSM ønsker ikke lenger å evaluere og sertifisere denne type kryptoløsninger, da dette forutsetter dyp kjennskap til systemet det skal integreres i og er svært ressurskrevende å gjennomføre. For slike løsninger vil NSM basere sin godkjenning på allerede gjennomførte tredjepartsevalueringer og -sertifiseringer.

Om løsningen alene ikke tilfredsstiller NSMs krav til tillit (evaluerings- og sertifiseringsnivå), kan man benytte to løsninger, som beskrevet over, og få den komplette løsningen godkjent. Dette forutsetter at løsningene er evaluerte og sertifiserte, men de kan altså være sertifiserte til et lavere tillitsnivå.

Evaluering og sertifisering skal som før følge Common Criteria, FIPS 140-2 eller andre relevante nasjonale godkjenningsordninger. NSM vil anerkjenne tilliten disse evalueringene har etablert og godkjenne løsningene for BEGRENSET.

I noen tilfeller vil det allikevel være behov for at NSM involverer seg i en tradisjonell evaluering av kryptosystemer. Dette vil være løsninger som ikke er avhengig av plattform, operativsystem eller annet. Også for disse systemene forutsettes det at de er tredjepartsevaluert/-sertifisert, eller under evaluering, før NSM begynner evaluering.

For både førstnevnte godkjenning og sistnevnte evaluering, kreves NSMs godkjenning av profil e.l. som er benyttet for evalueringen. Det er et håp om at det utarbeides en kryptoprofil innen Common Criteria som kan benyttes. Dersom dette etableres og NSM godkjenner profilen, trenger man ikke lenger følge FIPS 140-2.

Nøkkelforvaltning

Ill.: Colourbox.no

Ill.: Colourbox.no

Selv om NSM på denne måten forenkler kravene til og godkjenningen av kryptosystemer for beskyttelse av BEGRENSET, krever NSM at nøkkelforvaltningen skjer på en god måte. Nøkler for BEGRENSET skal komme fra en PKI som er underlagt NSMs policy og rot-sertifikattjener. Dette utelukker ikke at symmetriske nøkler kan benyttes, men de må være beskyttet av digitale sertifikater og PKI under NSMs kontroll.

Langtidsnøkler må være generert i maskinvarebasert kryptomodul og må regnskapsføres slik at man har komplett oversikt over hvilke nøkler som er utstedt, til hvem, i hvilket utstyr, utstedelsesansvarlig, levetid, med mer. Merk at krav til levetid før nøkler ikke er spesifisert, men vil være avhengig av krypto- og informasjonssystemet de benyttes i. Med levetid menes både tidsperiode en nøkkel er gyldig og for hvor stor datamengde en nøkkel kan beskytte.

Det at nøklene må komme fra en sertifikattjener underlagt NSM betyr ikke at NSM selv må operere utstedende sertifikattjener. NSM tillater og ønsker at brukerne selv skal håndtere egne nøkler. NSM tillater også at brukerne kan kjøpe nøkkelforvaltningstjenester fra kommersielle kryptotjenesteleverandører som er underlagt NSMs PKI.

For alle nøkler som genereres må kvaliteten vurderes før nøkkelen sertifiseres (sertifikat utstedes), og alle sertifikater må, sammen med sertifikatstatusinformasjon, publiseres i systemet de skal benyttes.

NSM ønsker ikke sentralisert nøkkeldeponering. Dette kan gjøres lokalt for gjenoppretting av data ved tap og sletting av konfidensialitetsnøkler, men forutsetter to-person-kontroll.

Algoritmer

Algoritmer som anbefales er i hovedsak begrenset til Suite B. Suite B inneholder følgende:

Funksjonalitet                  Algoritme       Nøkkellengde
 Symmetrisk kryptering           AES             128, 256
 Digitale signatur               EC-DSA          256, 384
 Nøkkeletablering                EC-DH           256, 384
 Avtrykk                         SHA-2           256, 384

I tillegg kan følgende algoritmer benyttes:

Funksjonalitet                  Algoritme       Nøkkellengde
 Digital signatur                RSA             2048, 3072, 4096
 Nøkkeletablering                DH              2048, 3072, 4096
 Avtrykk                         SHA-2           224, 512
 Symmetrisk nøkkelbeskyttelse    KW, KWP         128, 256

Dette utelukker ikke at nye proprietære NSM-godkjente algoritmer kan benyttes i spesielle tilfeller. Merk at dette vil kunne hindre interoperabilitet.

Standarder og protokoller

Selv om NSM kun har spesifisert bestemte algoritmer og nøkkellengder som kan benyttes, er det ønskelig at åpne standarder og protokoller benyttes for høyere lags håndtering eller bruk av krypto. Eksempler på dette kan være Transport Layer Security eller IPsec i stedet for å benytte proprietære protokoller.

Ill.: Colourbox.no

Ill.: Colourbox.no

Spesielt for sikker fjerntilgang (kryptert VPN) har NSM slått fast at slike løsninger skal implementeres i en separat/uavhengig prosesseringsenhet (computing base). I forhold til figuren over (Figure 1), betyr dette at man kan benytte evaluerte og sertifiserte komponenter i tunnel-i-tunnel-modus, hvor innerste tunnel kan være programvarebasert løsning på klientmaskin og ytterste tunnel håndteres av en «vpn-ruter».

NSM utarbeider for tiden kravsett til sikker fjerntilgang. Sistnevnte krav vil bestå i dette nye kravsettet, men vil også inneholde ytterligere krav til  plattform, integrasjon, nettverk og krypto.

About Lars Olaussen

Lars Olaussen er sjefingeniør i Nasjonal sikkerhetsmyndighet, avdeling for teknologi, seksjon for kryptoutvikling. Hans ansvarsområde er råd- og veiledning og krav- og tiltaksutvikling innen elektronisk identifikasjon, kryptoløsninger og nøkkelforvaltning for beskyttelse av lavgradert og annen sensitiv, men ugradert informasjon.
This entry was posted in Informasjonssikkerhet, Internettsikkerhet, Kryptografi, Teknisk. Bookmark the permalink.