8.4 Sikkerhetshåndtering Nøkkelhåndtering Gruppe av servere skal legge til et nytt medlem Autentisering/delegering (kapabiliteter, sertifikater)

8.4.1 Nøkkelhåndtering Alice vil sette opp en sikker forbindelse med Bob.

Alice og Bob deler en hemmelig nøkkel. Da er det underforstått at de på en eller annen måte har etablert en hemmelig fellesnøkkel. Å lage en hemmelig fellesnøkkel over en usikker kanal kan gjøres enkelt med Diffie-Hellman key exchange.

Diffie-Hellman key exchange Kan ses på som fellesnøkkel- krypteringssystem

Nøkkel distribusjon I symmetrisk krypteringssystem må den initiale hemmelige nøkkelen overføres via en sikker kanal som både er pålitelig og konfidensiell Hemmelig nøkkel distribusjon:

Hvis det ikke finnes noen nøkler for Alice og Bob for å sette opp en hemmelig forbindelse, må nøkkelen distribueres ved annen type kommunikasjon mellom de to partene. Fellesnøkkelen må distribueres på en slik måte at mottakeren er sikker på at nøkkelen har en hemmelignøkkel- part

Det er nødvendig å ha en pålitelig forbindelse når fellesnøkkelen sendes. Privatnøkkelen må sendes i en forbindelse som både er pålitelig og konfidens. Fellesnøkkel distribusjon

Sertifikater Distribusjon av fellesnøkkel kan gjøres pålitelig ved bruk av public- key certificates. Disse inneholder fellesnøkkelen sammen med en streng som identifiserer entiteten som nøkkelen hører til. Disse blir signert av en Certification authority Som signatur benyttes en privat nøkkel K-CA og en fellesnøkkel K+CA

Sertifikatbruk Anta at en klient vil fastslå at den fellesnøkkelen som er funnet i sertifikatet virkelig tilhører til entiteten den identifisere. Fellesnøkkelen benyttes til å bevise signaturen. Hvis signaturen på sertifikatet matcher (fellesnøkkel, id)- paret er det bevist.

Sertifikatets levetid Essensielt uttrykker sertifikatet at fellesnøkkelen alltid vil være gyldig, noe som ikke er ønskelig. Hvis privatnøkkelen noen gang blir avslørt, kan ingen klienter benytte seg av fellesnøkkelen. Nøkkelen må oppheves ved å offentliggjøre at nøkkelen ikke er gyldig lenger

Certificate revocation list En klient må sjekke CRL for å finne ut om sertifikatets gyldighet. Hvis en slik liste utgis en gang dagelig, kan en avslørt nøkkel benyttes siden lista ikke oppdateres før neste dag. Sertifikatets levetid begrenses. Der validiteten til en sertifikat vil utgå etter en periode. Hvis sertifikatet må i løpet av denne perioden oppheves utgis det i CRL. Levetiden til sertifikatet kan reduseres til nær null. Som resultat blir ikke sertifikat lenger brukt, isteden vil en klient alltid ha kontakt med sertifikatautoritet for å sjekke fellesnøkkelens validitet.

Sikker gruppe håndtering Troverdighet: Mange sikre systemer bruker spesielle tjenester som nøkkel distribusjonssenter KDC. Det viktigste kravet fra systemene er at tjenestene må være troverdige. Og kan sikte seg mot alle type trusler mot sikkerheten i systemet. Tilgjengelighet: Et annet krav til slike tjenester er at de alltid vil være tilgjengelige. Hvis to parter skal lage en forbindelse, må minst en av dem kontakte KDC for å få tildelt en hemmelig nøkkel. Replication- kopi er en måte å løse tilgjengelighets- problemet på, men det fører igjen til at systemet blir mer sårbart for trusler mot sikkerheten.

En prosess vil forene seg med en gruppe G. Utfordringen er å sikre at integriteten til G ikke blir avslørt. G bruker en hemmelig nøkkel CK G som deles av alle medlemmer i gruppa til å kryptere meldinger som sendes innad i gruppa. K + G og K - G brukes til kommunikasjon utenfor G.

JR – Joint request T- P’s lokal tid RP- Reply pad K P,G – generert hemmelig nøkkel

8.4.3 Tilgangsrettigheter i distribuerte systemer Ressursene er spredd over forskjellige maskiner. Hver bruker av systemet får tildelt en brukerkonto på sentralserveren. Denne serveren blir slått opp i hver gang en bruker tar bruk av en ressurs eller maskin. I distribuerte systemer brukes også Capabilities: en uforfalskbar datastruktur for en spesifikk ressurs. Den forteller om tilgangsrettigheter som kapabiliteten holder for den ressursen.

Amoeba Amoeba er det første objektbaserte distribuerte systemet. Et objekt oppholder seg i serveren mens klienten sender et ønske om tilgang til objektet. For å kalle en operasjon på et objekt, sender klienten kapabiliteten til det lokale operativsystemet som lokaliserer serveren objektet ligger på.

48 bits24 bits8 bits48 bits Server portObjectRightsCheck Server port initialisers av serveren når objektet lages. Object identifiserer selve objektet. Rights spesifiserer aksessrettighetene til innehaver av kapabiliteten. Check brukes for å gjøre kapabiliteten uforfalskbar…

Når objektet lages velger serveren et tilfeldig check field og lagrer det i selve kapabiliteten og sin egen interne tabell. Når en kapabilitet sendes tilbake til serveren i en request til å utføre en operasjon, blir check feltet bekreftet. Får å lage en begrenset kapabilitet sender klienten en kapabilitet tilbake til serveren sammen med en bit maske for de nye rettighetene. Serveren tar en XOR på checkfeltet fra tabellen og de nye rettighetene og kjører resultatene gjennom en enveis funksjon. Den nye kapabiliteten lages med samme verdier i objectfeltet, men nye bit i feltet som viser rettigheter og i checkfeltet vises utverdien av enveis funksjonen

Her er alle rettigheter slått av bortsett fra en. Når denne mer begrensede kapabilitet returneres til serveren, kan serveren se at han ikke er en eier av kapabiliteten, siden minst et bit er slått av.

Delegasjon En bruker vil skrive ut en stor fil som han bare har lese- rettigheter på. Han sender request til printeren og sier at han vil ha filen skrevet ut kl Han sender bare filens navn til printeren slik at den kan kopiere filen til utskrivings kø når det trengs. Men problemet er at printeren ikke vil ha fulle rettigheter til den navngitte filen Løsning: Brukeren delegerer sine tilgangsrettigheter for filen til printeren for en kort tid. Delegasjon vil si at en bruker gir noen av sine rettigheter bort til en annen bruker, dermed blir det enklere å distribuere arbeid mellom prosesser uten å påvirke sikkerheten.

Delegasjon er enkelt hvis en bruker kjenner alle andre brukere. Hvis Alice vil gi bort en av sine rettigheter til Bob, trenger hun bare å formulerer et sertifikat som sier at ”Alice sier at Bob har rettigheter R,” : [A,B,R] A og hvis Bob dermed vil sende disse rettighetene videre til Charlie, må Bob be Charlie om å spørre Alice. Alice kan også bare formulere et sertifikat som sier ”Alle som har dette sertifikatet har rettigheter R.” Men nå må sertifikatet beskyttes mot ulovelig bruk. Neuman’s metode beskytter sertifikatet samtidig som det ikke gir krav om at en bruker må kjenne alle andre brukere.

For å implementere delegasjon brukes proxy noe som gir datasystemer økt sikkerhet (ikke proxy som brukes som synonym til klientsides enhet). Proxy har to deler; første er et sett som består av rettigheter som delegeres, sammen med kjent del av en hemmelighet som brukes til pålitelighetskontroll : C= {R,S + proxy }. Sertifikatet bærer signaturen sig(A,C) av A. Den andre delen er den ukjente hemmelighetsdelen S - proxy.

Det finnes ulike måter å implementere S + proxy og S - proxy på. Du kan se på den første nøkkelen som en hemmelighet som er kjent av mange, men den siste er den interne delen av den hemmeligheten. Alle måtene har felles ide som går ut på å vise at DU vet en hemmelighet; både den felles delen og den interne delen.

Takk for oppmerksomheten