Identifikatorer for Alice ( Alice ), initiativtageren til sessionen | |
Identifikator for Bob ( Bob ), den side, hvorfra sessionen er etableret | |
Identifikator for Trent ( Trent ), en betroet mellempart | |
Alice, Bob og Trents offentlige nøgler | |
Alice, Bob og Trents hemmelige nøgler | |
Kryptering af data med Alices nøgle, eller Alice og Trents fælles nøgle | |
Kryptering af data med Bobs nøgle eller Bob og Trents fælles nøgle | |
Datakryptering med hemmelige nøgler af Alice, Bob (digital signatur) | |
Sessionssekvensnummer (for at forhindre gentagelsesangreb) | |
Tilfældig sessionsnøgle, der skal bruges til symmetrisk datakryptering | |
Kryptering af data med en midlertidig sessionsnøgle | |
Tidsstempler føjet til beskeder af henholdsvis Alice og Bob | |
Tilfældige tal ( nonce ), der blev valgt af henholdsvis Alice og Bob |
Yahalom er en symmetrisk nøgledistributionsprotokol med en pålidelig server. Yahalom-protokollen kan ses som en forbedret version af Wide-Mouth Frog- protokollen . Denne protokol "skifter" genereringen af en ny sessionsnøgle til det betroede center og bruger også tilfældige tal til at beskytte mod gentagelsesangreb [1] .
Med symmetrisk kryptering antages det, at den hemmelige nøgle, som tilhører klienten, kun er kendt af ham og en tredje betroet part - autentificeringsserveren. Under protokolsessionen modtager klienterne Alice og Bob en ny hemmelig sessionsnøgle fra Trent-godkendelsesserveren for at kryptere gensidige beskeder i den aktuelle kommunikationssession. Protokolimplementering [2] :
Først starter Alice en session ved at sende Bob hendes ID og et tilfældigt nummer :
Efter at have modtaget en besked fra Alice, kombinerer Bob Alices ID, Alices tilfældige nummer og sit eget tilfældige nummer og krypterer den oprettede besked med nøglen, der deles med Trent. Efter at have tilføjet sit ID til denne besked, sender Bob den modtagne besked til Trent:
Trent afkoder Bobs besked og opretter to beskeder. Den første besked inkluderer Bobs ID , Trents genererede sessionsnøgle , Alices tilfældige tal og Bobs tilfældige tal . Denne besked er krypteret med nøglen, der deles med Alice. Den første besked ser sådan ud:
Den anden besked er krypteret med den delte nøgle mellem Trent og Bob og inkluderer Alices ID og Trents genererede sessionsnøgle . Den anden besked ser sådan ud:
Trent videresender begge beskeder, han oprettede, til Alice:
Alice modtager to beskeder fra Trent og dekrypterer den første. Efter at have dekrypteret beskeden udtrækker Alice sessionsnøglen og sikrer sig, at det tilfældige tal givet af Trent stemmer overens med det tilfældige tal givet til Bob i det første trin. Alice sender derefter to beskeder til Bob. Den første besked er beskeden modtaget fra Trent, krypteret med den delte nøgle mellem Trent og Bob. Denne besked består af Alices identifikator og sessionsnøgle :
Den anden besked er krypteret med en sessionsnøgle genereret af Trent, Bobs tilfældige nummer :
Alice sender begge beskeder til Bob:
Bob dekrypterer den første besked og udtrækker sessionsnøglen . Ved at bruge den hentede sessionsnøgle dekrypterer Bob den anden besked og modtager et tilfældigt tal . Bob kontrollerer nummeret modtaget fra Alice med det tilfældige nummer sendt i andet trin. Efter de beskrevne handlinger kan parterne bruge den nye sessionsnøgle [2] }.
Yahalom-protokollen giver udover at generere en sessionsnøgle godkendelse af parterne:
Som et resultat af Yahalom-protokollen er Alice og Bob overbeviste om, at de kommunikerer med hinanden og ikke med en ukendt tredjepart. I modsætning til Wide-Mouth Frog- protokollen har parterne mulighed for at sikre sig, at den mellemliggende server genererer en delt hemmelig nøgle for dem to og ikke for en tredjepart (selvom denne protokol ikke beskytter mod fuldstændig kompromittering af den betroede parti) [2] .
Yahalom-protokollen har en række sårbarheder, der kan udnyttes af angribere.
Trent genererer en ny sessionsnøgle
Alice bruger den gamle sessionsnøgle og sender en besked
I en artikel fra 1989 foreslog Michael Burrows, Martin Abadi og Roger Needham deres egen version af Yahalom-protokollen:
I denne version af protokollen er der ingen grund til at bruge en ikke-certificeret nøgle, da aktualiteten af den sidste meddelelse er garanteret af et tilfældigt tal . Der er ingen grund til at kryptere Bobs tilfældige nummer i anden fase og i den første besked i tredje fase . Resultatet er det samme resultat, men med mindre kryptering [4] .
Autentificering og nøgleudvekslingsprotokoller | |
---|---|
Med symmetriske algoritmer | |
Med symmetriske og asymmetriske algoritmer | |
Protokoller og tjenester, der bruges på internettet |