Needham-Schroeder-protokollet

Kryptografiska notationer som används i autentiserings- och nyckelutbytesprotokoll

$A$	Identifierare av Alice ( Alice ), initiativtagaren till sessionen
$B$	Identifierare för Bob ( Bob ), den sida från vilken sessionen etableras
$T$	Identifierare för Trent ( Trent ), en pålitlig mellanpart
$K_{A},K_{B},K_{T}$	Alice, Bob och Trents publika nycklar
$K_{A}^{-1},K_{B}^{-1},K_{T}^{-1}$	Hemliga nycklar till Alice, Bob och Trent
$E_{A},\left\{...\right\}_{K_{A}}$	Kryptering av data med Alices nyckel, eller Alice och Trents gemensamma nyckel
$E_{B},\left\{...\right\}_{K_{B}}$	Kryptera data med Bobs nyckel eller Bob och Trents gemensamma nyckel
$\left\{...\right\}_{K_{B}^{-1}},\left\{...\right\}_{K_{A}^{-1}}$	Datakryptering med hemliga nycklar från Alice, Bob (digital signatur)
$jag$	Sessionssekvensnummer (för att förhindra reprisattacker)
$K$	Slumpmässig sessionsnyckel som ska användas för symmetrisk datakryptering
$E_{K},\left\{...\right\}_{K}$	Krypterar data med en tillfällig sessionsnyckel
$T_{A},T_{B}$	Tidsstämplar har lagts till i meddelanden av Alice respektive Bob
$R_{A},R_{B}$	Slumptal ( nonce ) som valdes av Alice respektive Bob

Needham-Schroeder-protokollet är ett vanligt namn för symmetriska och asymmetriska autentiserings- och nyckelutbytesprotokoll. Båda protokollen föreslogs av Michael Schroeder och Roger Needham [1] . En variant baserad på symmetrisk kryptering använder en mellanliggande betrodd part. Detta protokoll blev grunden för en hel klass av sådana protokoll. Till exempel är Kerberos ett av alternativen för det symmetriska Needham-Schroeder-protokollet. En variant baserad på asymmetrisk kryptering är designad för ömsesidig autentisering av parterna. I sin ursprungliga form är båda versionerna av protokollet sårbara [2] [3] .

Historik

Ett protokoll för symmetrisk nyckelautentisering, kanske det mest kända autentiserings- och nyckeletableringsprotokollet, formulerades av Michael Schroeder och Roger Needham 1978 [1] . Det är dock sårbart för en attack som uppfanns av Dorothy E. Denning och Giovanni Maria Sacco 1981 [ 2 ] . Trots detta blev det grunden för en hel klass av sådana protokoll. I synnerhet är Kerberos-protokollet en av varianterna av Needham-Schroeder-autentiseringsprotokollet baserat på en betrodd tredje part och dess ändringar som föreslagits av Denning och Sacco [2] . Needham-Schroeder-protokollet för autentisering av publik nyckel är också sårbart. 1995 beskrev Gavin Lowe en möjlig attack mot protokollet [3] .

Needham-Schroeder-protokoll för symmetrisk nyckelautentisering

Med ett symmetriskt nyckelkrypteringsschema antas det att den hemliga nyckeln är känd både för autentiseringsservern ( Trent) och för båda utbytesobjekten : (Alice) och (Bob). Inledningsvis har båda ämnena hemliga nycklar: och , som bara är kända för dem och för någon pålitlig part - autentiseringsservern. Under exekveringen av protokollet får Alice och Bob en ny hemlig sessionsnyckel från servern för att kryptera ömsesidiga meddelanden i denna kommunikationssession, det vill säga bara Bob kan dekryptera meddelanden från Alice till Bob, bara Alice kan dekryptera meddelanden från Bob till Alice . Dessutom ska utbytesobjekten vara säkra på att det inkommande meddelandet skickades exakt till dem som utbytet ska ske med. Bob måste vara säker på att han fick meddelandet från Alice och vice versa. Detta tillhandahålls också av protokollet. Antag att utbytet initieras av Alice. Vi antar att de har en gemensam autentiseringsserver. Överväg implementeringen av protokollet [4] : $T$ $A$ $B$ $K_{A}$ $K_{B}$

$Alice\till A,B,R_{A}\till Trent$
$Trent\till \left\{R_{A},B,K,\left\{K,A\right\}_{K_{B}}\right\}_{K_{A}}\till Alice$
$Alice\till \left\{K,A\right\}_{K_{B}}\till Bob$
$Bob\till \left\{R_{B}\right\}_{K}\till Alice$
$Alice\till \left\{R_{B}-1\right\}_{K}\till Bob$

Utbytet börjar med att Alice genererar något slumpmässigt nummer (identifierare) som används en gång. Det första meddelandet från Alice till Trent innehåller namnen på deltagarna i det kommande utbytet och ett slumptal genererat av Alice: $R_{A}$

Alice\till A,B,R_{A}\till Trent

Detta meddelande skickas i klartext, men kan krypteras med Alices nyckel : $K_{A}$

Alice\to \left\{A,B,R_{A}\right\}_{K_{A}}\to Trent

När Trent tar emot detta meddelande hämtar Trent Alices och Bobs privata nycklar från databasen: och , och beräknar en ny sessionsnyckel . Trent skickar sedan följande meddelande till Alice: $K_{A}$ $K_{B}$ $K$

Trent\till \left\{R_{A},B,K,\left\{K,A\right\}_{K_{B}}\right\}_{K_{A}}\till Alice

Alice kan avkoda och läsa meddelandet från Trent. Hon letar efter sitt ID i meddelandet, vilket bekräftar att meddelandet är ett svar på hennes första meddelande till Trent. Den kontrollerar också namnet på ämnet som den ska utbyta data med. Denna kontroll är obligatorisk, för om detta namn inte fanns där, skulle inkräktaren kunna ersätta Bobs namn med sitt eget i det första meddelandet, och Alice, som inte misstänker något, skulle interagera med inkräktaren ytterligare. En del av meddelandet kan inte läsas av Alice eftersom denna del är krypterad med Bobs nyckel. Alice skickar Bob ett fragment krypterat med hans nyckel: $R_{A}$

Alice\till \left\{K,A\right\}_{K_{B}}\till Bob

Bara Bob kan dekryptera den, eftersom den är krypterad med hans privata nyckel. Efter dekryptering äger Bob också sessionsnyckeln . Alices namn i meddelandet bekräftar att meddelandet kommer från henne. Vidare, vid utbyte av data, kommer sessionsnyckeln att användas. För att göra schemat symmetriskt och minska risken för en reprisattack genererar Bob något slumpmässigt nummer (Bobs ID) och skickar följande meddelande till Alice, krypterat med sessionsnyckeln: $K$ $R_{B}$

Bob\till \left\{R_{B}\right\}_{K}\till Alice

Alice dekrypterar det och skickar svaret som Bob förväntar sig, även krypterat med sessionsnyckeln:

Alice\till \left\{R_{B}-1\right\}_{K}\till Bob

För partner som interagerar regelbundet kan du minska antalet meddelanden till tre genom att ta bort de två första. I detta fall kommer nyckeln att användas upprepade gånger [5] .

En attack mot Needham-Schroeder-protokollet för symmetrisk nyckelautentisering

Needham-Schroeder-protokollet är sårbart för en attack mot återsändning av meddelanden som uppfanns av Dorothy E. Denning och Giovanni Maria Sacco 1981 [ 2 ] . Under attacken avlyssnar och ersätter angriparen meddelandena från paragraferna 3,4,5 i protokollet. Angriparen fångar upp meddelandet från Alice till Bob i det tredje steget av protokollet och blockerar Alice. Ersätter sedan Alices nuvarande meddelande med ett annat från den gamla sessionen mellan Alice och Bob. Baserat på antagandet att den gamla sessionsnyckeln är sårbar kan en angripare ta reda på dess värde och börja utbyta data med Bob under sken av Alice [4] .

Som ett resultat tror Bob att han har en ny sessionsnyckel med Alice, men i själva verket är nyckeln gammal och känd för angriparen.

Överväg en möjlig implementering av attacken:

Utbytet startar på samma sätt som i protokollet. Alice genererar ett slumptal och skickar det till Trent. Trent hämtar Alices och Bobs hemliga nycklar från databasen, beräknar en ny sessionsnyckel och skickar ett svar till Alice. Alice dekrypterar meddelandet, kontrollerar slumptalet och namnet på personen som hon ska utbyta data med. Skickar ett meddelande till Bob. $K$

Alice\till A,B,R_{A}\till Trent

Trent\till \left\{R_{A},B,K,\left\{K,A\right\}_{K_{B}}\right\}_{K_{A}}\till Alice

Alice\till \left\{K,A\right\}_{K_{B}}\till Bob

Därefter ingriper en angripare i protokollet. Först avlyssnar han Alices meddelande till Bob och blockerar sedan helt Alices kommunikationskanal. Baserat på antagandet att den gamla sessionsnyckeln är sårbar kan en angripare ta reda på dess värde. Utöver värdet på den gamla nyckeln har angriparen det gamla sessionsmaterialet mellan Alice och Bob: , där (föregående nyckel) är den gamla nyckeln. Han poserar som Alice och skickar ett meddelande till Bob med den gamla nyckeln: $Alice\to \left\{K_{P},A\right\}_{K_{B}}\to Bob$ $K_{P}$

Alice(Attacker)\till \vänster\{K_{P},A\höger\}_{K_{B}}\till Bob

Bob dekrypterar meddelandet och ser till att det är från Alice, ovetande om att han har blivit attackerad och redan kommunicerar med inkräktaren. Han skickar "Alice" sitt slumpmässiga nummer:

Bob\to \left\{R_{B}\right\}_{K_{P}}\to Alice(Attacker)

Angriparen, som vet värdet på den gamla nyckeln, dekrypterar Bobs meddelande. Som väntat minskar han Bobs slumptal med ett, krypterar resultatet med samma gamla sessionsnyckel och skickar ett meddelande till Bob:

Alice(Attacker)\till \vänster\{R_{B}-1\höger\}_{K_{P}}\till Bob

Som ett resultat är Bob säker på att han etablerade en kommunikationssession med Alice, eftersom alla nödvändiga protokollsteg utfördes korrekt och alla meddelanden visade sig vara korrekta.

Denna attack ger upphov till en allvarligare fara - avsaknaden av en verklig koppling mellan partnerna. Angriparen behöver inte vänta på att Alice ska starta protokollet. Eftersom han känner till den gamla sessionsnyckeln kan han starta attacken själv genom att starta protokollet från steg 3. Bob kommer att tro att han tog kontakt med Alice, medan Alice inte tog kontakt alls [6] . $K_{P}$

Sårbarhetskorrigering

Denning och Sacco föreslog att man skulle använda tidsstämplar i meddelanden för att förhindra attacker som den som diskuterades ovan [2] . Låt oss beteckna en sådan etikett med en bokstav . Överväg alternativet att åtgärda sårbarheten: $t$

$Alice\till A,B,R_{A}\till Trent$
$Trent\to \left\{R_{A},A,B,\left\{K\right\}_{K_{A}}\right\}_{K_{A}}$ , $\left\{t,A,B,\left\{K\right\}_{K_{B}}\right\}_{K_{B}}\till Alice$
$Alice\to \left\{t,A,B,\left\{K\right\}_{K_{B}}\right\}_{K_{B}}\to Bob$
$Bob\till \left\{R_{B}\right\}_{K}\till Alice$
$Alice\till \left\{R_{B}-1\right\}_{K}\till Bob$

Efter att ha tagit emot protokollmeddelanden från Trent kan Alice och Bob upptäcka att deras meddelanden har blivit obesvarade genom att kontrollera ojämlikheten:

t_{curr}-t<\Delta t_{1}+\Delta t_{2}

där (aktuell tid) är mottagarens aktuella lokala tid; är ett intervall som representerar den tillåtna skillnaden mellan Trent-tid och lokal tid; är den förväntade tidsfördröjningen. Härifrån är de övertygade om "friskheten" i meddelanden och i synnerhet sessionsnyckeln. Eftersom tidsstämpeln är krypterad med Alices och Bobs hemliga nycklar, är Trents imitation omöjlig i ett idealiskt krypteringsschema [7] . $t_{{curr}}$ $\Delta t_{{1}}$ $\Delta t_{{2}}$

Även i denna reviderade protokollspecifikation framhålls behovet av att skydda dataintegriteten uttryckligen. Om meddelandena som utbyttes mellan protokolldeltagare inte förvrängdes under överföringen, kan båda parter efter verifieringsproceduren vara säkra på att sessionsnyckeln är konsistent både med användarna och med "freshness"-identifieraren. Detta bör övertyga dem om att varandra är autentiska och att den gamla sessionsnyckeln inte används [8] .

Fallet med olika autentiseringsservrar

I det verkliga livet kan Alice och Bob vara tillräckligt långt ifrån varandra för att det inte finns någon gemensam autentiseringsserver [5] . Av denna anledning, i allmänhet, kan Alice ha sin egen autentiseringsserver: , och Bob sin egen: . Eftersom i det här fallet ställs Alice också inför uppgiften att konstruera ett budskap av form för Bob . Båda servrarna kommer att vara inblandade i dess bildande, eftersom den bara kan kryptera med Alices nyckel och bara kan använda Bobs nyckel: . Samtidigt ska säkerheten för utbyte mellan servrar säkerställas. Tänk på ett exempel för fallet med två olika servrar som har en anslutning till varandra: $T_{A}$ $T_{B}$ $\left\{K,A\right\}_{K_{B}}$ $T_{A}$ $K_{A}$ $T_{B}$ $K_{B}$

$Alice\till A,B,R_{A}\till Trent_{A}$
$Trent_{A}\till A,B,R_{A},K\till Trent_{B}$
$Trent_{B}\to A,R_{A},\left\{K,A\right\}_{K_{B}}\to Trent_{A}$
$Trent_{A}\to \left\{R_{A},B,K,\left\{K,A\right\}_{K_{B}}\right\}_{K_{A}}\to Alice$
$Alice\till \left\{K,A\right\}_{K_{B}}\till Bob$
$Bob\till \left\{R_{B}\right\}_{K}\till Alice$
$Alice\till \left\{R_{B}-1\right\}_{K}\till Bob$

Steg 1, 4-7 motsvarar steg 1-5 i det vanliga autentiseringsserverfallet ovan. I det andra steget kontaktar Alices server, som inte hittar Bob i listan över sina klienter, Bobs server. Han känner till Bobs nyckel och kan utföra den nödvändiga krypteringen. Efter det skickas den krypterade informationen tillbaka till Alices autentiseringsserver, som skickar den till Alice [5] .

Entity Authentication Protocol

"Response-revoke"-mekanismen [9] i protokollet tillhandahåller den så kallade entitetsautentiseringen [ISO 1] . Autentisering av en enhet utförs med hjälp av verifiering av verifierande användare av någon kryptografisk operation. Det visar att det finns en provanvändare, vilket anses bekräftat om provanvändaren har utfört någon kryptografisk operation efter den händelse som en annan användare anser vara den sista.

I det andra steget av Needham-Schroeder-protokollet dekrypterar Alice det engångsslumptal som hon själv genererade i det första steget. Detta bekräftar det faktum att Trent utförde krypteringen efter att ha tagit emot meddelandet från Alice. Som ett resultat vet Alice att Trent existerade efter denna händelse, det vill säga Trent klarade existensautentiseringen i förhållande till Alice. Samtidigt kan Bob, som deltar i samma protokoll, inte vara säker på existensen av Trent [7] .

Needham-Schroeder-protokoll för autentisering av publik nyckel

Public key kryptosystem

Låt oss presentera notationen:

$K_{A}$ - Alices publika nyckel ;
$K_{{A}}^{{-1}}$ Alices privata nyckel .

Dessutom är det bara Alice som känner till den hemliga nyckeln, och den publika nyckeln är känd för andra.

$M$ — klartext ;
$\left\{M\right\}_{K_{A}}$ - texten är krypterad med Alices publika nyckel och kan endast dekrypteras av Alice med hjälp av hennes privata nyckel;
$\left\{M\right\}_{{K_{{A}}^{{-1}}}}$ — texten är krypterad med Alices privata nyckel och kan dekrypteras med Alices publika nyckel.

Det betyder att texten med perfekt kryptering garanterat skapas av Alice, eftersom det bara är hon som äger denna hemliga nyckel. Det är därför chiffertexten kallas för en digital meddelandesignatur . Dess dekryptering med den offentliga nyckeln kallas Alices signaturverifiering [ 10] . $\left\{M\right\}_{{K_{{A}}^{{-1}}}}$ $\left\{M\right\}_{{K_{{A}}^{{-1}}}}$ $M$

Needham-Schroeder-protokoll för autentisering av publik nyckel

En asymmetrisk variant (tvånyckelschema) av Needham-Schroeder-protokollet. Trent äger de publika nycklarna till alla klienter han betjänar. Alice har en offentlig nyckel och en privat nyckel , Bob har både , Trent har och . Låt Alice starta en ny session med Bob [11] : $K_{A}$ $K_{{A}}^{{-1}}$ $K_{B}$ $K_{{B}}^{{-1}}$ $K_{T}$ $K_{{T}}^{{-1}}$

$Alice\till A,B\till Trent$
$Trent\till {\left\{K_{B},B\right\}}_{K_{T}^{-1}}\till Alice$
$Alice\till T,\vänster\{R_{A},A\höger\}_{K_{B}}\till Bob$
$Bob\till B,A\till Trent$
$Trent\till \left\{K_{A},A\right\}_{K_{T}^{-1}}\till Bob$
$Bob\to \left\{R_{A},R_{B}\right\}_{K_{A}}\till Alice$
$Alice\to \left\{R_{B}\right\}_{K_{B}}\to Bob$

Alice, initiativtagaren till protokollet, ber Trent om Bobs publika nyckel i det första meddelandet:

Alice\till A,B\till Trent

På vilket Trent, i det andra steget av protokollet, svarar med ett meddelande med Bobs publika nyckel och hans namn. Meddelandet är krypterat med Trents privata nyckel , det vill säga det är hans digitala signatur . Denna signatur borde övertyga Alice om att hon fick meddelandet från Trent. Det antas att Alice känner till Trents publika nyckel och kan dekryptera meddelandet, det vill säga verifiera signaturen.

Trent\till {\left\{K_{B},B\right\}}_{K_{T}^{-1}}\till Alice

Därefter genererar Alice ett slumpmässigt nummer och skickar det till Bob tillsammans med hennes namn, efter att ha krypterat det tidigare med Bobs publika nyckel. $R_{A}$

Alice\till T,\vänster\{R_{A},A\höger\}_{K_{B}}\till Bob

Endast Bob kan dekryptera detta meddelande, eftersom det kräver hans privata nyckel . Från meddelandet får han veta att Alice vill börja utbyta data med honom. Därför behöver Bob Alices publika nyckel och utför samma operationer som Alice gjorde: $K_{{B}}^{{-1}}$

Bob\till B,A\till Trent

Trent\till \left\{K_{A},A\right\}_{K_{T}^{-1}}\till Bob

Som ett resultat känner utbytesdeltagarna till varandras publika nycklar. Därefter utförs ömsesidig autentisering med genererade slumptal :

Bob\to \left\{R_{A},R_{B}\right\}_{K_{A}}\till Alice

Alice\to \left\{R_{B}\right\}_{K_{B}}\to Bob

Needham och Schroeder föreslog att man skulle använda siffror för att initiera den delade hemliga nyckeln [1] , som ger en hemlig koppling mellan Alice och Bob. Denning och Sacco påpekade senare att detta protokoll inte garanterar att publika nycklar är nya och inte dubbletter av gamla. Detta problem kan lösas på olika sätt, i synnerhet genom att använda tidsstämplar [2] i meddelanden med nycklar. Needham och Schroeder övervägde också användningen av tidsstämplar, men förkastade denna idé på grund av bristen på en kvalitativ tidsstandard [12] . $R_{A}$ $R_{B}$

En attack mot Needham-Schroeder-protokollet för autentisering av publik nyckel

En attack mot protokollet föreslogs av Gavin Lowe [3 ] . Han delade upp protokollet i två delar som inte var logiskt relaterade. Först: 1, 2, 4, 5 steg i protokollet - erhållande av en publik nyckel. Andra: 3, 6, 7 steg - Alice och Bob-autentisering. Vi kommer att anta att den första delen har ägt rum och överväga den andra:

Alice\till T,\vänster\{R_{A},A\höger\}_{K_{B}}\till Bob

Bob\to \left\{R_{A},R_{B}\right\}_{K_{A}}\till Alice

Alice\to \left\{R_{B}\right\}_{K_{B}}\to Bob

Låt Attacker vara en person som är en legitim användare av systemet . Han kan genomföra standardkommunikationssessioner med andra användare av systemet. För attacken används den samtidiga lanseringen av två protokoll: i det första genomför Alice en korrekt session med angriparen, i det andra utger sig angriparen för att vara Alice när han kommunicerar med Bob [13] .

1.3.

Alice\to T,\left\{R_{A},A\right\}_{K_{At}}\to Attacker

2.3.

Angripare (Alice)\till T,\vänster\{R_{A},A\höger\}_{K_{B}}\till Bob

2.6.

Bob\to \left\{R_{A},R_{B}\right\}_{K_{A}}\to Attacker(Alice)

1.6.

Angripare\till \vänster\{R_{A},R_{B}\höger\}_{K_{A}}\till Alice

1.7.

Alice\till \left\{R_{B}\right\}_{K_{At}}\to Attacker

2.7.

Angripare (Alice)\till \vänster\{R_{B}\höger\}_{K_{B}}\till Bob

I steg 1.3 skickar Alice ett slumpmässigt nummer till angriparen, som angriparen omedelbart skickar till Bob vid steg 2.3 i ett annat protokoll. Bob får detta meddelande och genererar i steg 2.6 sitt eget slumptal och svarar på vad han tror är Alice. Angriparen kan inte dekryptera detta meddelande, så han skickar det till Alice i steg 1.6. Alice tar emot ett misstänkt meddelande, dekrypterar det och returnerar Bobs slumpmässiga nummer till angriparen i steg 1.7 genom att kryptera meddelandet med angriparens publika nyckel. Nu känner angriparen till Bobs slumptal och kan svara honom i steg 2.7. Bob är säker på att han upprättade en kommunikationssession med Alice, eftersom han krypterade meddelandet med ett slumpmässigt nummer med hennes nyckel och fick rätt svar. $R_{A}$

Nyckelpunkten med attacken är att angriparen kan tvinga Alice att dekryptera Bobs slumpmässiga nummer åt honom. Alice i denna attack agerar som ett orakel - en systemanvändare som utför någon kryptografisk operation i angriparens intresse [14] .

Ett exempel på konsekvenser

Betrakta ett exempel på konsekvenserna av denna attack. Låt Bob vara en bank. Då kan angriparen, som utger sig för att vara Alice, använda hennes konto och överföra pengar från det till sitt eget. Banken kommer att vara säker på att operationen utfördes av Alice [14] .

Enkel protokollfix

För att förhindra attacken som beskrivs ovan, lägg till namnet på den som svarade i meddelandet i det sjätte steget:

2.6.

Bob\to \left\{B,R_{A},R_{B}\right\}_{K_{A}}\to Attacker(Alice)

I det här fallet kommer angriparen inte att kunna vidarebefordra meddelandet till Alice, eftersom Alice kommer att förvänta sig följande meddelande från honom:

1.6.

Angripare\till \vänster\{At,R_{A},R_{B}\höger\}_{K_{A}}\till Alice

som angriparen inte kan få vare sig genom att vidarebefordra Bobs meddelanden eller på egen hand [14] .

Sårbarhetskorrigering

Första alternativet 3.

Alice\to \left\{\left\{R_{A},A\right\}_{K_{A}^{-1}}\right\}_{K_{B}}\till Bob

Bob\to \left\{R_{A},\left\{R_{B}\right\}_{K_{B}^{-1}}\right\}_{K_{A}}\till Alice

Alice\to \left\{\left\{R_{B}\right\}_{K_{A}^{-1}}\right\}_{K_{B}}\to Bob

I den reviderade specifikationen är detta ett meddelande som måste verifieras med Alices publika nyckel, det vill säga att det är Alices signatur . I denna specifikation signeras först slumpmässiga nummer och krypteras sedan med en annan användares publika nyckel. Eftersom Bob signerar sitt nummer i steg 6, blir Lows attack omöjlig. Om angriparen vidarebefordrar meddelandet till Alice kommer hon att märka ett verifieringsfel [15] . $\left\{R_{A},A\right\}_{K_{A}^{-1}}$

Andra alternativet

Med metoden "kryptera och signera" kan du förfina den enligt följande:

Alice\to \left\{\left\{R_{A}\right\}_{K_{B)),A\right\}_{K_{A}^{-1}}\till Bob

Bob\to \left\{\left\{R_{A},R_{B}\right\}_{K_{A}}\right\}_{K_{B}^{-1}}\till Alice

Alice\to \left\{\left\{R_{B}\right\}_{K_{B}}\right\}_{K_{A}^{-1}}\till Bob

Nu kan angriparen inte ens starta kommunikationsprotokollet med Bob på uppdrag av en annan person [15] .

Praktisk användning

Kerberos- protokollet är utformat för att lösa problemet med nätverksanvändarautentisering . Dess huvudidé är att använda en betrodd tredje part som ger användaren åtkomst till servern med en gemensam sessionsnyckel som delas mellan användaren och servern. Detta protokoll är baserat på en variant av Needham-Schroeder-protokollet som använder en tidsstämpel [16] [1] .

Anteckningar

↑ 1 2 3 4 Needham, Schroeder, 1978 .
↑ 1 2 3 4 5 6 Denning, Sacco, 1981 .
↑ 1 2 3 Lowe, 1995 .
↑ 1 2 Mao, 2005 , sid. 76.
↑ 1 2 3 Semenov Yu.A. .
↑ Mao, 2005 , sid. 77.
↑ 1 2 Mao, 2005 , sid. 79.
↑ Mao, 2005 , sid. 641.
↑ Mao, 2005 , sid. 75.
↑ Mao, 2005 , sid. 80.
↑ Mao, 2005 , sid. 81.
↑ Needham, Schroeder, 1987 .
↑ Mao, 2005 , sid. 83.
↑ 1 2 3 Mao, 2005 , sid. 84.
↑ 1 2 Mao, 2005 , sid. 643.
↑ Mao, 2005 , sid. 462.

Standarder

↑ ISO 9798-2: Informationsteknologi - Säkerhetstekniker - Entitetsautentiseringsmekanismer - Del 2: Entitetsautentisering med symmetriska tekniker.

Litteratur

Roger M. Needham, Michael D. Schroeder. Använda kryptering för autentisering i stora nätverk av datorer // Commun . ACM. - New York, NY, USA: ACM, 1978. - Vol. 21 , iss. 12 . - P. 993-999 . — ISSN 0001-0782 . doi : 10.1145/ 359657.359659 .
Dorothy E. Denning, Giovanni Maria Sacco. Tidsstämplar i nyckeldistributionsprotokoll // Commun . ACM. - New York, NY, USA: ACM, 1981. - Vol. 24 , iss. augusti 1981 , nr. 8 . - s. 533-536 . — ISSN 0001-0782 . - doi : 10.1145/358722.358740 .
Roger M. Needham, Michael D. Schroeder. Autentisering återbesökt // SIGOPS Oper. Syst. Rev.. - New York, NY, USA: ACM, 1987. - Vol. 21 , iss. 1 . - S. 7-7 . — ISSN 0163-5980 . doi : 10.1145/ 24592.24593 .
Gavin Lowe. En attack mot Needham-Schroeder-protokollet för autentisering med offentlig nyckel // Information Processing Letters. - 1995. - Vol. 56 , nr. 3 . - S. 131-133 . — ISSN 0020-0190 . - doi : 10.1016/0020-0190(95)00144-2 .
Schneier B. Tillämpad kryptografi. Protokoll, algoritmer, källkod i C-språk = Applied Cryptography. Protocols, Algoritms and Source Code in C. - M. : Triumph, 2002. - 816 sid. - 3000 exemplar. - ISBN 5-89392-055-4 .
Wenbo Mao. Modern Cryptography: Theory and Practice = Modern Cryptography: Theory and Practice. - Williams Publishing House, 2005. - ISBN 5-8459-0847-7 .
Semenov Yu.A. Needham-Schroeder Authentication Protocol i fall av symmetriska och asymmetriska krypteringssystem . Hämtad: 8 december 2012. (ryska)

Länkar

Needham-Schroeder offentlig nyckel . Hämtad 2 augusti 2010. Arkiverad från originalet 6 december 2012.
Symmetrisk nyckelprotokoll . Hämtad 17 november 2012. Arkiverad från originalet 6 december 2012.
Protokollet med offentlig nyckel ändrat av Lowe . Hämtad 17 november 2012. Arkiverad från originalet 6 december 2012.

Autentisering och nyckelutbytesprotokoll
Med symmetriska algoritmer	Groda med bred mun Yahalom Needham-Schroeder-protokollet Otway-Risa-protokollet Kerberos Newman-Stubblebine-protokollet
Med symmetriska och asymmetriska algoritmer	DASS Denning-Sacco-protokollet Wu Lam-protokollet SPKM
Protokoll och tjänster som används på Internet	OAuth Öppna ID Windows Live ID