* 11 *

Internett sikkerhet

Ukens faktum

I 2000 ble RSA Securities' web side "tægget" av crackere -- noe som kunne vært svært pinlig for sikkerhetsfirmaet. Crackerne kom ikke inn på RSAs system derimot. De fikk lure DNS systemet ved å angripe en DNS server over RSAs egen i hierarkiet. Dette viser hvor kritisk det er med avhengigheter i sikkerhetssystemer. Sikkerhet er ikke bare for de som har hemmeligheter, men et problem for samfunnet i sin helhelt.
Se Stallings kapitler 6 & 7

Diffie-Hellman key exchange

En av de sikreste måter å sende informasjon på er å bruke en engangs nøkkel, eller sesjonsnøkkel, dvs en random krypterings nøkkel som er unik til hver samtale. For å bruke en sesjonsnøkkel må begge parter i en samtale bli enige om en slik nøkkel. Nøkkelen kan ikke offentligjøres, ellers blir poenget borte. Nøkkeldistribusjonsproblemet var en vanskelig sak før Diffie-Hellman algoritmen.

Ved å bruke de samme primtall metodene som er brukt i RSA, klarer Diffie-Hellman algoritmen å konstruere den samme nøkkelen to forskjellige steder, uten å sende nøkkelen via nettet. Denne algoritmen er sentral i mange sikkerhetssystemer idag.

Sikker E-mail og S/MIME

Flere mail transfer agents (MTA) slik som sendmail v8.11 har nå støtte for applikasjonsnivå, point to point, kryptering for å unngå avlytting av Email. Dette kalles START TLS og AUTH SMTP og fører til at hele SMTP samtalen krypteres.

Problemet med SMTP E-mail protocolen, slik den er implementert i mange systemer, er at den ikke kan håndtere binære (ikke ASCII) data. Dette skaper problemer for kryptering, eller overførsel av multimedia filer (bilder,lyd osv), som trenger binæer fil-formater. Dette er grunnen til at slike filer må pakkes inn i MIME (multi-purpose internet mail extension) attachments, med Unix-aktig uuencode/uudecode ASCIIfisering. Sikkerhetssystemer for Email må derfor konvertere data til ASCII formater og tilbake.

Email kan krypteres manuelt ved hjelp av PGP. En versjon av MIME med kryptering og signaturer heter er også utviklet og heter S/MIME. Denne er en mer transparent grensesnitt mot krypteringsfunksjonaliteten.

SSL/TLS

The secure socket layer (SSL) ble laget opprinnelig av Netscape Communications for å sikre web transaksjoner. (HTTPS er SSL kryptert HTTP). Versjon 3 av SSL protokollen ble utvidet ved hjelp av forslag andre aktører i industrien og ble publisert som en Internet Draft Document standard. Transport layer security (TLS) er en mindre modifikasjon av SSLv3, og det er meningen at denne skal bli en internet standard.

SSL and TLS bruker offentlig/privat nøkkel metoder for å etablere sikre kommunikasjonskanaler. De gjøre dette ved å først utforske sikkerhets muligheter på begge sider av en forbindelse, slik at den beste felles mulighet brukes, og så etablere en sesjonsnøkkel for kryptering. Etter dette, brukes en billigere eller raskere form for kryptering (3DES,IDEA,RC4 etc) for å overføre dataene.

SSL ble utviklet som en transparent erstatning for vanlig socket kommunikasjon mellom maskiner. For å ta i bruk SSL er det ikke stort mer å gjøre enn å bytte noen systemkall med SSL biblioteksfunksjoner.

SET - secure electronic transactions

The Secure Electronic Transaction system (SET) ble utviklet under oppdrag fra VISA og MASTERCARD kredittkort selskapene i 1996. Flere atkører var med i utviklingen, inkludert Microsoft, Netscape, IBM, RSA, Terisa og Verisgn. Mens SSL/TLS var et generelt system for å overføre datastrømmer, var SET basert på en spesifikk transaksjonsmodell, rettet mot betaling med kredittkort. Systemet var laget for å ivareta fortrologheten til de tre partene i en betalingstransaksjon: (kunde,butikk,bank).

SET bruker en tredjeparts sertifiseringsorganisasjon (a la Verisign) for å lagre en database over kundenes offentlige nøkler, som øker tillitten til nøklenes integritet under transaksjonen.

Den interessante egenskapen til SET modellen er at den bruker en dobbel signatur for å øker fotroligheten til kunde og butikk. Butikken trenger ikke å vite om kunden kredittkort detaljer, og banken trenger ikke å vite hvilke varer som ble kjøpt av kunden. Separate signaturer lages for disse to delene av en handelstransaksjon. Disse må imidlertid kobles, slik at betalingen og utførelsen av transaksjonen henger sammen. Men måten de er koblet sammen på forsikrer at bare den informasjonen partene trenger å vite er mulig å lese for dem.

VPNs and S/WAN

Da TCP/IP protokollen ble oppfunnet var det svært uvanlig å ha tilgang til root/Administrator privilegier, eller ha personlig nettverk forbindelse. Sikkerheten som lå i TCP/IP var basert på at nettverkstraffikken aldri ville være tilgjengelig for vanlige brukere. Dette er ikke lenger tilfellet: i dag har så å si alle tilgang til nettverkstraffikken og root/Administrator privilegier.

Ett av problemene med TCP/IP sikkerhet er at passord og annen privatinformasjon sendes ofte i klartekst (ukryptert) slik at avlyttere kan `sniffe' nettet og plukke opp fortrolige data.

Et sikkert virtual private network (VPN) er en kryptert forbindelse mellom maskiner, som fungerer som en tunnel eller `armert rør' mellom en bruker og en tjenermaskin. Det finnes mange tekniske løsninger til denne problemstillingen; de fleste er basert på RSA type autentisering og kryptering, f.eks SSH.

IPSec

Mange problemer innen nettverkskommunikasjon ville være lett løst dersom det fantes transportnivå kryptering av internett traffikk. IPSec er et sikkerhetssystem som var utviklet til bruk i IPv6, men mekanismene kan også brukes i IPv4 (RFC1636). IPSec gir kryptering på IP nivået. Dette betyr at typiske TCP/UDP angrep (spoofing, sequence guessing osv) aldri ville kunne skje, da angripere aldri ville se innholdet i pakkene som sendes.

DNSSec

Selv om man løser fortrolighetsproblemet for kommunikasjon mellom to parter, har man igjen muligheten for å bli lurt til å snakke med feil person eller maskin. I DNS cache angrep, lurer crackere falsk informasjon inn i DNS databasen, slik at oppslag fører til oppkobling mot den gale maskinen. Problemet er at DNS er en trusted database, men den tilliten er basert på svært lite bevis. Sikker DNS (DNSSEC) forsøker å løse dette problemet ved å bruke message digests og signaturer til å stemple DNS pakker med autentiserings- of integritetsbevis.

Secure DNS løser problemet med autentisering av DNS record (RFC 2535). Sikker DNS dreier seg ikke om fortrolighet: informasjonen i DNS er offentlig informasjon. Den fokuserer kun på integritet. Designprinsippet er at alle brukere som slår opp den samme informasjon vil få samme svar. Strategien er å umuliggjøre forfalskning.

DNS er vel den største distribuerte databasen som finnes. Problematikken rundt implementasjonen av denne tjenesten, med distrubusjon av oppdateringer m.m. er ikke triviell, og dette systemet testes fremdeles.

Back