Enkle grep for bedre kryptosikkerhet

Publisert: 03.06.2015

Siden Snowden-bekreftelsene om at kommunikasjon over Internett virkelig avlyttes, er øynene åpnet hos mange for behovet for kryptering. Men kryptering er ingen «magisk ingrediens» man bare kan strø over et system og sikre seg mot avlytting.

Sikre løsninger må bygges fra bunnen og dessverre er mange av standardene som sikre løsninger skal bygges etter er heller ikke sikre. Det kan være ufullstendige spesifikasjoner som gjør at implementering av sikkerhetsmekanismer vanskelig eller at man må implementere usikre mekanismer som «minste felles multiplum» for samhandling.

Nå har standardiseringsgrupper startet med å ta frem sikre standarder, men det tar ofte lang tid fra en standard er klar til produktene er i salg og ikke minst i bruk. Det vil derfor kunne ta flere år før de fleste systemer som behandler sensitiv informasjon er oppgradert med mekanismer for beskyttelse av informasjon som faktisk virker.

Heldigvis finnes det noen standardiserte og tilgjengelige mekanismer man kan ta i bruk allerede i dag for å øke kryptosikkerheten i løsningene. Hvorvidt de hjelper for en bestemt bruker eller organisasjon, vil være avhengig av hvor mye infrastruktur man forvalter og hvilken trussel man ønsker å beskytte seg mot. Det kan være forskjell på løsninger for å beskytte seg mot tilfeldige avlyttere på åpne trådløsnett og beskytte seg mot trusselaktører som utfører masseinnsamling over Internett, men det trenger ikke være det.

Reduser antall PKIer du stoler på – Det er ikke nødvendig å ha tillit til hundrevis av PKIer i operativsystem eller nettleser. Det er noen få PKIer man må stole på for å få klienten til å virke, men utover det er det få PKIer som man må ha tillit til for å aksessere de mest vanlige nettstedene på Internett. For hver PKI man har tillit til vil det være tusenvis, om ikke millioner, av sertifikater som klienten automatisk har full tillit til. Enhver kode som er signert under og ethvert nettsted som har fått sertifikat fra en slik PKI vil dermed automatisk være tiltrodd. Det er ingen grunn til å stole på hele verden.

Bruk DNSSEC – For å sikre at man kobler seg til rett tjener når man gjør navneoppslag bør man benytte sikre DNS-oppslag (DNSSEC). På denne måten unngår man at noen forfalsker adressen til nettstedet man skal besøke og kan opptre som en uautorisert man-in-the-middle.

Benytt HTTPS i stedet for HTTP – I «gamle dager» skrev man nettbanksikkerhet om HTTPS. I dag tilbyr alle seriøse nettsteder kryptert forbindelse med sertifikat (hengelås). For klienter finnes det utvidelser som sørger for alltid å prøve HTTPS i stedet for HTTP og tviholder på slike forbindelser selv om tjeneren kanskje prøver å «gå ned» til HTTP. Tjenere bør settes opp til å alltid benytte kryptert forbindelse ved å sette Strict-Transport-Security-flagget.

Key PinningBenytt Certificate Pinning – Sertifikater til kjente nettsteder og apps skal kun komme fra de PKIene de har avtale med. Google har avtale med én PKI-leverandør for sertifikater til deres programvare og nettsteder. Dersom de (som gjennom Chrome) oppdager at sertifikatet for et Google-nettsted ikke er utstedt av dere tiltrodde leverandør, vil brukeren få beskjed om at informasjonen kanskje avlyttes. Foruten nettsteder kan dette også gjøres i apps. Da må apputvikleren legge inn sertifikatet eller dets avtrykk i appen som tjeneren skal presentere når appen ringer «hjem». Dersom sertifikatet som presenteres ikke stemmer, vil appen avdekke at det er «krøll på linja».

Ta i bruk sikker fjerntilgang (kryptert VPN) – Foruten nettsteder og apps som tilbyr kryptering med certificate pinning, er det en rekke andre nettsteder og apps som ikke benytter kryptomekanismer. For å sikre disse må man benytte sikker fjerntilgang. Hvor fjerntilgangen ender kan være avhengig av hvem man representerer og hvem man vil beskytte seg mot.

For bedrifter er det naturlig å terminere sikker fjerntilgang i bedriftens hjemmenett, mens for private brukere kan man terminere forbindelsen hjemme i eget hus. Det hadde for øvrig vært spennende om norske internettleverandører ville begynne å tilby sikker fjerntilgang (kryptert VPN) for sine kunder, slik at kunder som skal surfe på Internett fra andre steder enn hjemme, kunne gjort det uten at hvem som helst kan avlytte dem. Da ville man fått samme sikkerhet mot uvedkommende når man er ute og reiser og bruker Internett som man har fra sitt eget hjem.

Benytt forward secrecy – For å sikre at kompromittering av egen eller nettsteds nøkkel ikke kompromitterer tidligere sesjoner, er det lurt å bruke algoritmer, skjema og protokoller som støtter forward secrecy. Dette ligger an til å bli standard i TLS 1.3, men frem til den er klar og implementert, er dette allerede valgfri opsjon og støttet av flere ulike chiffreringspakker (cipher suites).

Fjern eller deaktiver svake kryptomekanismer – De fleste kommunikasjonsløsningene benytter seg av forhandlingsprotokoller, som i TLS, for å bli enige om hvilken nøkkeletableringsmekanisme, kryptoalgoritmer og nøkkellengder som skal benyttes. Ved å fjerne eller deaktivere svake mekanismer, vil man sørge for at ikke disse benyttes. Dette kan gjøres både på klient og tjener, men gir raskest bedre sikkerhet for flest mulig hvis det gjøres på tjener. Om ikke tjeneren gjør dette, kan man endre dette på klienten sin og dermed sørge for at ens egen informasjon blir bedre sikret i overføring.

Generer nøkkelpar og beskytt private nøkler i maskinvare – Sterke kryptonøkler er en forutsetning for krypto og maskinvarebaserte mekanismer genererer nøkler med høyere entropi enn programvarebaserte mekanismer, i tillegg til at nøkler generert og beskyttet i slike enheter ikke kan kompromitteres selv om datamaskinen de skal benyttes i/av er kompromittert. I tillegg vil en enkel PIN-kode som beskytter nøkkel i et smartkort være lettere å huske enn et passord som beskytter en krypteringsnøkkel i en fil.

Merk at noen av disse tjenestene er avhengige av hverandre, mens andre jobber uavhengig av hverandre. Det er allikevel viktig at så mange som mulig av disse mekanismene er på plass for å oppnå best mulig kryptosikkerhet.

For NSMs detaljerte krav til krypto for beskyttelse av BEGRENSET og annen sensitiv, men ugradert informasjon, se NSM Cryptographic Requirements 3.0 tilgjengelig her.

comments powered by Disqus