Från Rilpedia

Du har inte behörighet att redigera denna sida, av följande anledning:

Du kan se och kopiera denna sidas källtext:

<noinclude>{{rpsv.from.wpsv}}</noinclude>'''Autentisering''' har två betydelser: *kontroll av uppgiven [[identitet]], till exempel vid inloggning, vid [[kommunikation]] mellan två system eller vid utväxling av [[meddelande]]n mellan användare *meddelandeverifiering, d.v.s. [[kontroll]] av att ett meddelande inte ändrats sedan det lämnat avsändaren Autentisering innebär att kunna visa sin identitet för någon annan. Som människor har vi inget problem med det i vardagen då vi kan autentisera oss på många olika sätt. Vi känner t.ex. igen varandras röster på telefon, eller varandras ansikten när vi träffas. Det finns även olika kontor som kollar oss genom bilden på vårt pass/id. När man kommunicerar över ett nätverk kan man inte förlita sig på t.ex. visuellt beteende eller en ljudinspelning. Det är vanligt att nätverkselement såsom routrar, servrar och klientprocesser måste autentisera varandra. Autentisering måste i sådana fall uteslutande ske med hjälp av protokoll. Protokollet måste köras innan några andra protokoll körs mellan parterna. Dessa protokoll kallas för ap (autentiseringsprotokoll). <ref>Kurose James F. and Ross Keith W. (2005), Computer Networking A top-down approach featuring the internet,ISBN 0-321-26976-4.</ref> ==Protokoll== ===ap1.0=== Det här är kanske allra simplaste protokollet. En sändare A säger till en mottagare B att jag är A. Det finns inget sätt som B kan veta att A verkligen är A. Det innebär att vem som helst egentligen kan uppge sig för att vara avsändare A. ===ap2.0=== Om sändare A har en välkänd ip-adress som A alltid kommunicerar ifrån kan mottagare B autentisera A genom att ta reda på sändarens adress i IP-datagrammet och kontrollera att det är A:s välkända adress. Det är säkrare än ap 1.0 men fortfarande inte helt säkert. Om någon har tillgång till källkoden för ett operativsystem såsom linux och kan bygga sin egen kärna för att skapa ett IP-datagram, så kan man sätta dit vilken ip-adress man vill, t.ex A:s adress. Det här är en välkänd säkerhetsattack och kan undvikas om upphovsroutern från personen som försöker förfalska ip-adressen är konfigurerad, så att den bara skickar vidare datagram innehållande ip-adressen för personer som är direkt uppkopplade mot den routern. ===ap3.0=== Våra klassiska sätt att autentisera oss är genom lösenord. Vi har t.ex. lösenord för att logga in på operativsystemet eller för automatiska telefonsvarare. Lösenordet delas mellan autentiseraren och personen som blir autentiserad. I det här protokollet så sänder A ett lösenord till mottagare B. Lösenord är ju vanligt använt och man kan tro att det här protokollet är relativt säkert. Det är fel, då en utomstående person kan tjuvlyssna på A:s och B:s kommunikation och lära sig A:s lösenord. Om man t.ex. kör telnet mot en annan maskin och loggar in okryptat på telnet-servern, så kan någon sniffa upp paketen som skickas och ta reda på lösenordet. Det här är ett ganska vanligt tillvägagångssätt för att ta reda på lösenord. ===ap3.1=== Det här är en utökning av ap 3.0 då man krypterar lösenordet. På så sätt kan man förhindra att någon kan sniffa upp data för en kommunikation mellan två parter för att ta reda på lösenordet. Ifall man antar att avsändare A och mottagare B delar en hemlig symmetrisk nyckel. Då kan sändare A kryptera sitt lösenord och skicka ett identifieringsmeddelande innehållande lösenordet till mottagare B. Mottagare B avkodar meddelandet och ser vilket lösenord avsändare A använder. Användningen av kryptografi löser dock inte hela autentiseringsproblemet. B kan bli mål för en uppspelningsattack. För en inkräktare behöver bara tjuvlyssna på A:s kommunikation och spara det krypterade lösenordet. Sedan kan inkräktaren spela upp det krypterade lösenordet för B som då tror att inkräktaren är sändaren A. ===ap4.0=== Problemet med det föregående protokollet ap 3.0 är att samma lösenord använts om och om igen. En lösning vore att använda ett nytt lösenord varje gång. Sändaren A och mottagaren B kan tillsammans göra upp om en sekvens av lösenord eller genom att använda sig av en algoritm för att generera lösenord, för att sedan använda varje lösenord endast en gång. Det finns mera generella tillvägagångssätt för att motverka uppspelningsattacker. Ett problem för de tidigare protokollen är att mottagaren B inte kan urskilja mellan originalautentiseringen från A:s och en senare uppspelning av A:s originalautentisering. Man kan också uttrycka det som att B inte vet ifall A verkligen finns på andra sidan och sänder ett meddelande eller ifall det är inspelning av en tidigare autentisering från sändare A. En lösning på problemet är att använda sig av ett tillfälligt nummer som bara kommer att användas inom protokollets livslängd. # A sänder ett identifieringsmeddelande till mottagare B. # B väljer ett tillfälligt nr R och skickar tillbaka det till A. # A krypterar numret genom att använda A och B:s gemensamma symmetriska hemliga nyckel. Det är samma princip som för ap 3.1 där båda sidor vet om den hemliga nyckeln och använder den för att kryptera ett värde som gör att mottagaren B vet att meddelandet kommer från sändare A. Det tillfälliga numret R används för att veta att sändare A lever (sänder meddelanden på riktigt och inte som inspelningar). # Mottagare B avkodar meddelandet och kontrollerar så att det tillfälliga numret R är samma som B sände till A och kan nu autentisera sändare A. ===ap5.0=== Det här protokollet försöker använda sig av ett tillfälligt nummer R och en publik nyckel istället för en symmetrisk nyckel för att lösa autentiseringsproblemet. # Sändare A skickar ett identifieringsmeddelande till mottagare B. # Mottagare B skickar ett tillfälligt nr R till A. R används för att kontrollera att A lever. # A använder en privat nyckel för att kryptera R och skickar värdet till B. Det är bara A som känner till den privata nyckeln och meddelandet måste alltså komma från A. # B frågar efter A:s publika nyckel för att kunna läsa det mottagna meddelandet från A. B får det av A och kan avkoda meddelandet och se att R är samma som skickades till A från början. Det här är inte en ultimat teknik då vem som helst kan låtsas vara sändare A. Det kan upptäckas genom att konversationen mellan A och B ändras och någon av parterna kan fatta misstankar. Det kan även va en inkräktare som lyssnar av meddelanden mellan A och B utan att ändra dem, genom att låtsas vara både A och B. Dvs. A tror att inkräktaren är B, som i själva verket kan läsa A:s meddelanden och sedan skicka vidare till B. B tror att inkräktaren är A, som kan läsa meddelanden och sedan skicka vidare till A. ==Källor== <references/> [[Kategori:Datasäkerhet]] [[az:Autentikasiya]] [[cs:Autentizace]] [[da:Autenticitet]] [[de:Authentifizierung]] [[el:Πιστοποίηση]] [[en:Authentication]] [[es:Autenticación]] [[eu:Kautotu]] [[fi:Todennus]] [[fr:Authentification]] [[gl:Autenticación]] [[he:אימות זהות]] [[hy:Վավերացում (ինֆորմատիկայի ոլորտ)]] [[it:Autenticazione]] [[ja:認証]] [[kaa:Awtentifikatsiya]] [[ko:인증]] [[lv:Autentifikācija]] [[nl:Authenticatie]] [[no:Autentisering]] [[pl:Uwierzytelnianie]] [[pt:Autenticação]] [[ro:Autentificare]] [[ru:Аутентификация]] [[simple:Authentication]] [[sl:Avtentikacija]] [[uk:Автентифікація]] [[vi:Xác thực]] [[zh:認證]]

Tillbaka till Autentisering.