Sikkerhetsbloggen

I Nye retninger innen krypto for BEGRENSET stod det:

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.

NSM krever altså at man benytter asymmetrisk krypto, digitale sertifikater og PKI (offentlig nøkkelinfrastruktur) for forvaltning av nøkler for beskyttelse av BEGRENSET.

NSM anbefaler samtidig at asymmetrisk krypto, digitale sertifikater og PKI benyttes for forvaltning av kryptonøkler for andre beskyttelsesbehov.

Så til innleggets tittel; hvorfor kreve asymmetrisk krypto, digitale sertifikater og PKI?

Det korte svaret er modenhet.

Det litt lenger svaret er at asymmetrisk nøkkelforvaltning, digitale sertifikater og PKI er en moden teknologi.

Og det lange svaret følger her:

Ill.: Colourbox.no

Tradisjonelt er nøkkelforvaltningsystemer utviklet per kryptosystem. På denne måten ender man opp med like mange nøkkelforvaltningssystemer som kryptosystemer. For små organisasjoner kan dette være uproblematisk, da man ikke nødvendigvis har mer enn en eller to kryptosystemer, men for profesjonelle nøkkelforvaltere fungerer det ikke.

Forsvaret, som har tatt frem EKNAS/NOR (Elektronisk Nøkkel Administrasjons System/Norge), har samtidig krevd at nye kryptosystemer skal tilpasses slik at de kan få nøkler fra dette nøkkelforvaltningsystemet. Men, det er forbeholdt de færreste å utvikle egne kryptosystemer og dermed kunne kreve at bestemte standarder, grensesnitt eller systemer benyttes.

Siden NSM ønsker at kommersielle produkter skal benyttes for beskyttelse av BEGRENSET, må kommersielle nøkkelforvaltningssystemer støttes og benyttes. Det er allikevel ikke, verken i brukerens eller NSMs interesse, å ende opp med et utall ulike nøkkelforvaltningssystemer. Derfor krever NSM at man standardiserer og variantbegrenser dette, og tar i bruk den beste teknologien som er tatt bredest i bruk i markedet.

Hvor modent et system eller en løsning er kan måles på ulike måter, og ikke minst vil det være ulike svar avhengig av om man ser et system for seg selv eller integrert med andre. Capability Maturity Model er en aktuell modell for å kunne vurdere modenheten til programvare eller systemer. Denne modellen omtaler følgende modenhetsnivåer:

1. Initial – the starting point for use of a new or undocumented repeat process.
2. Repeatable – the process is at least documented sufficiently such that repeating the same steps may be attempted.
3. Defined – the process is defined/confirmed as a standard business process, and decomposed to levels 0, 1 and 2 (the last being Work Instructions).
4. Managed – the process is quantitatively managed in accordance with agreed-upon metrics.
5. Optimizing – process management includes deliberate process optimization/improvement.

Ill.: Colourbox.no

Kilde: Wikipedia

Chris Kostick i Ernst & Young har holdt en lessons learned-presentasjon hvor han omtaler modenhetsnivået på nøkkelforvaltning for ulike anvendelser. Selv om denne presentasjonen ikke gir alle anvendelsene god skår på modenhet, oppnår den ikke navngitte PKI-løsningen et modenhetsnivå på fire.

At nivå fire har blitt nådd for PKI er ikke rart, med tanke på det omfattende standardiseringsarbeidet som er gjennomført. Algoritmer, protokoller, sertifikater og sperrelister er veldefinerte og utprøvde. I tillegg er det en rekke sertifikatpolitikker og sertifikatpraksiser som benyttes og som er åpent tilgjengelig, og PKI-produkter er evaluert og sertifisert etter publiserte profiler.

Nivå fire i modellen er altså et fornuftig og oppnåelig mål, og grunnlag for sikker nøkkelforvaltning.

Ill.: Colourbox.no

På klientsiden har de fleste applikasjoner og tjenester implementert støtte for digitale sertifikater og PKI. Standardiseringen (formater og protokoller) som er gjort, i tillegg til at biblioteker og kryptogrensesnitt støtter asymmetriske kryptofunksjoner, gjør det relativt enkelt å støtte digitale sertifikater og PKI for nøkkelforvaltning.

At man med asymmetrisk krypto fortrinnsvis kun distribuerer offentlige nøkler er jo heller ingen ulempe…

Uten å gjennomføre en analyse av tilgjengelige løsninger for symmetrisk nøkkelforvaltning, er det klart at både standardiseringen og ikke minst markedets tilslutning til symmetriske kryptomekanismer, digitale sertifikater og PKI gjør dette til det naturlige valg for nøkkelforvaltning for beskyttelse av 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

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

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

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

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

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.

http://bitcoin.clarkmoody.com/

Det har vært mye snakk om kryptovaluta etter at Bitcoin (BTC) fra januar har steget fra ca. 75 NOK/BTC til rundt 1100, og med et smell ned igjen til rundt 600 NOK/BTC i dag.  Kommentatorer konkluderer ofte med at den økte interessen er en direkte årsak av finanskrisen, og spesielt den senere tids hendelser på Kypros.  Noen vektlegger kriminelle formål (f.eks. Silkeveien , en kriminell markedsplass skjult gjennom mix-nettverk).  Andre mener Bitcoin er på ville veier. Å manipulere kursen ved destabilisering av sentrale valutaforhandlere (DDoS-angrep) er et reelt problem synonymt med å blokkere børsen for å skape panikk. Skadevare som stjeler private nøkler og botnet med enorme regnekapasiteter er andre variabler man må regne på for å forstå sikkerheten i Bitcoin. At det i utgangspunktet ikke er anonymt, kommer kanskje som en overraskelse på mange.

Mange har kastet seg på Bitcoin i 2013 og flere går til innkjøp av dyre spesialdesignede FPGA-plattformer med mål om å tjene penger på “gruvedrift” . Man kan jo spørre seg om andelen ærlige deltakere som bare er spekulanter og hvorfor selgere av gruvedrift-verktøy ikke bruker disse til å tjene penger selv. Men at kursen oppfører seg som en ustabil berg-og-dalbane er det ingen tvil om.

Basics
Den prinsipielle forskjellen mellom Bitcoin og annen valuta, er at den i utgangspunktet ikke kontrolleres av myndigheter eller banker – den er desentralisert. Dine Bitcoins er beviselig knyttet til deg med hjelp av kryptografi og transaksjoner kontrolleres og godkjennes av frivillige, såkalte “gruvearbeidere”, som blir betalt med hjelp av helt nye Bitcoins og transaksjonsgebyr. Mekanismer sørger for at det er praktisk umulig å betale med samme mynten to steder (“double-spending“) og kontrollerer at det bare “trykkes” et forutsigbart antall nye Bitcoins hver dag.

Alt dette avhenger av at Bitcoin-nettverket og annen viktig infrastruktur ikke destabiliseres av uærlige aktører.

For å ta i bruk Bitcoin så må du opprette en eller flere Bitcoin-addresser (som et kontonummer). Til hver addresse er det knyttet et unikt  nøkkelpar (for signering) og selve addressen din er bare et kryptografisk avtrykk av den offentlige nøkkelen i dette paret.

Den private nøkkelen gir deg total kontroll over midlene tilknyttet denne addressen. Så det er enormt viktig at den oppbevares på en trygg måte (f.eks. i en TPM). Men mister du nøkkelen (data-krasj, tyveri, etc.) , så mister du nøkkelen som autoriserer din tilgang til midlene. I praksis laster du ned en Bitcoin-klient som ordner alt dette for deg, og er du heldig så både lager og lagrer klienten nøklene tilstrekkelig sikkert. I prinsippet er dette sikrere enn de bankløsningene du bruker for å logge på nettbanken din.

Kjernen av nettverket består hovedsakelig av to elementer;  transaksjoner og blokker.

Transaksjoner
En transaksjon er et digitalt dokument som inneholder relevant informasjon om transaksjonen du vil ha utført. Du spesifiserer til hvilken addresser, og hvor mye, det skal overføres, men du må også spesifiere fra hvor du henter betalende Bitcoins fra. Dette gjør du ved å referere til en eller flere foregående transaksjoner i nettverket, hvor din addresse  står som mottaker. Et viktig poeng er at bitcoinene bare eksisterer som tall i et lenket revidert nettverk av transaksjoner. Totalt antall Bitcoins som kommer inn i transaksjonen fordeles ut på de du skal betale til, og eventuelle vekslepenger sender du til din egen addresse. Det som er igjen regnes som transaksjonsgebyr til den eller de som skal behandle transaksjonen (vi kommer til dette). Når transaksjonen signeres av deg, så vil enhver i senere tid kunne verifisere at det virkelig er du som har utført transaksjonen og at den er gyldig. Når du er ferdig plasseres transaksjonen i et basseng med ubehandlete transaksjoner og  erkjennes først gyldig når den har blitt plassert i en offisielt godkjent blokk.

Blokker
En blokk er en offentlig bokføring (en forsegling) av en bolk med transaksjoner. Blokker lenkes til hverandre serielt i en blokk-lenke, hvor hver neste blokk refererer til den forrige og den som kommer etter seg. Det finnes altså en rot-blokk (den første som ble laget) og til enhver tid en siste blokk. Det er her “miners”, eller gruvearbeiderne, kommer inn. Blokker opprettes av en gruvearbeider; frivillige som donerer regnekraft til nettverket mot betaling. Gruvearbeideren får en bunke mer eller mindre tilfeldige ubehandlete transaksjoner fra bassenget og plasserer de i en ny blokk. Den første transaksjonen han plasserer i blokken er til han selv; for tiden 25 nyopprettede Bitcoins som takk for arbeidet.  Men så kommer arbeidet inn. Røft forklart så krever Bitcoin-nettverket at det skal tilstrekkelig mye regnekraft til for å opprette en ny godkjent blokk;  dette fordi det ikke skal opprettes flere eller færre enn omtrent 2016 blokker per andre uke (skal sørge for en viss stabilitet). Vanskelighetsgraden justeres deretter. For at det skal ta tilstrekkelig lang tid å opprette en blokk, så må gruvearbeideren beregne et 256-bit tidkrevende avtrykk (hash) på en spesiell form,  og her er det første-mann til mølla som vinner.

Gruvearbeidet
En 256-bit avtrykksfunksjon (hash-funksjon) er en funksjon som tar inn et vilkårlig stort tall og regner ut et på forhånd uforutsigbart tall mellom og (antall atomer i universet antas å være rundt ). Bitcoin utnytter følgende to egenskaper ved en 256-bit kryptografisk avtrykksfunksjon for å forhindre forfalskninger:

• Gitt et tilfeldig tall mellom og , så er det beregningsmessig umulig å finne et tall slik at .
• Man må i gjennomsnitt over tid prøve ulike verdier for for å være 100% sikker på å treffe et avtrykk som tilfredstiller ,  hvor er et tall mellom  og .

Gruvearbeideren får tildelt to verdier; avtrykket av forrige blokk i nettverket og (Merkle) avtrykket av transaksjonene i blokken han skal bokføre; og er bare to veldig store tall. Vanskelighetsgraden sier enkelt og greit at blokken ikke blir godkjent før gruvearbeideren finner en verdi slik at

.

hvor er et tall mellom og som bestemmer vanskelighetsgraden. Det mindre er, desto større blir tallet , som antyder antallet tall gruvearbeideren må teste før han finner et avtrykk som er mindre enn . Når denne bloggen publiseres må avtrykksverdien være mindre enn , slik at man må beregne avtrykksalgoritmen ca.  ganger for å treffe en verdi mindre enn .  Når gruvearbeideren finner en slik (hvilken som helst), så sender han resultatet tilbake inn i Bitcoin-nettverket for godkjenning. Viss alt er demokratisk og fint, så kan alle beregne og sjekke at avtrykksverdien er på riktig form og være enige om at blokken kan gyldiggjøres. De andre gruvearbeiderne viser enighet ved å begynne på en ny blokk, hvor de refererer til denne som siste (i praksis skjer dette ikke fullt så enkelt, og som alltid finnes djevelen i detaljene).

Angrep mot Bitcoin
For at Bitcoin-nettverket skal fungere så er det vesentlig at ingen kontrollerer betydelige prosentdeler av beregningskraften i nettverket. Det finnes mange kjente og ukjente angrepsflater, men et typisk spørsmål som dukker opp er:

Hva om noen eier en betydelig andel av ressursene i nettverket ?

Med mer enn 50% av ressursene utgjør du selvsagt en majoritet; hvilket betyr at du dikterer demokratiske avgjørelser, som f.eks. å blokkere andres transaksjoner og blokker. Du kan kort fortalt få til en del. Men du kan ikke signere transaksjoner på andres vegne (bruke andres Bitcoins). Det finnes få formelle sikkerhetsanalyser av hva som faktisk er mulig og hvilke scenarior som utspenner seg i praksis. Argumentet at “…det er alt for dyrt å kjøpe nok av ressursene i nettverket” er ikke særlig presist. Jeg tror man bør være mer nøkterne og tålmodig vente på flere og bedre sikkerhetsanalyser. Et lettere spørsmål å svare på er:

Hva om noen knekker kryptoalgoritmene ?

Kryptoalgoritmene som brukes i Bitcoin er standard. For signering av transaksjonene dine brukes ECDSA og avtrykksalgoritmen som brukes er SHA-256; ikke kontroversielt i det hele tatt (problemene oppstår typisk, og ofte,  når noen ikke klarer å bruke eller implementere dette riktig, som åpner for sidekanalsangrep).  Men praktiske ikke-sidekanalsangrep på disse algoritmene er vi et godt stykke unna ennå.

Interesserte bør ta en videre kikk på Zerocoin og Ripple.