Lösenordsautentiserat nyckelutbyte genom att jonglera
Password Authenticated Key Exchange by Juggling (eller J-PAKE) är ett lösenordsautentiserat nyckelavtalsprotokoll, föreslagit av Feng Hao och Peter Ryan. Detta protokoll tillåter två parter att upprätta privat och autentiserad kommunikation enbart baserat på deras delade (låg-entropi) lösenord utan att kräva en Public Key Infrastructure . Det ger ömsesidig autentisering till nyckelutbytet, en funktion som saknas i Diffie–Hellmans nyckelutbytesprotokoll .
Beskrivning
Två parter, Alice och Bob, kommer överens om en grupp med generator av prime ordning där det diskreta loggproblemet är svårt. Typiskt används en Schnorr-grupp . I allmänhet kan J-PAKE använda vilken prime order-grupp som helst som är lämplig för kryptografi med publik nyckel, inklusive elliptisk kurvkryptering . Låt vara deras delade (låg-entropi) hemlighet, som kan vara ett lösenord eller en hash av ett lösenord ( ). Protokollet körs i två omgångar.
- Omgång 1
- Alice väljer , och skickar ut , tillsammans med nollkunskapsbevisen (med till exempel Schnorr icke-interaktiva nollkunskapsbevis som specificerats i RFC 8235) för bevis för exponenterna och . På liknande sätt väljer Bob x och skickar ut , tillsammans med Zero-knowledge-bevisen för beviset för exponenterna och . Ovanstående kommunikation kan genomföras i en omgång eftersom ingen av parterna är beroende av den andra. När det är klart verifierar Alice och Bob de mottagna nollkunskapsbevisen och kontrollerar även .
- Omgång 2
- Alice skickar ut och ett Zero-knowledge bevis för beviset för exponenten . (Obs! Alice härleder faktiskt en ny publik nyckel med som generator). På liknande sätt skickar Bob ut och ett Zero-knowledge bevis för beviset för exponenten .
Efter omgång 2 beräknar Alice . På liknande sätt beräknar Bob . Med samma nyckelmaterial kan Alice och Bob härleda en sessionsnyckel med hjälp av en kryptografisk hashfunktion : .
J-PAKE-protokollet i två omgångar är helt symmetriskt. Detta hjälper till att avsevärt förenkla säkerhetsanalysen. Till exempel måste beviset på att en part inte läcker någon lösenordsinformation i datautbytet gälla för den andra parten baserat på symmetrin. Detta minskar antalet nödvändiga säkerhetsbevis med hälften.
I praktiken är det mer sannolikt att implementera J-PAKE i tre flöden eftersom en part normalt ska ta initiativet. Detta kan göras trivialt utan förlust av säkerhet. Anta att Alice initierar kommunikationen genom att skicka till Bob: och Noll-kunskapsbevis. Sedan svarar Bob med: och noll-kunskapsbevis. Till sist skickar Alice till Bob: och ett Zero-knowledge bevis. Båda parter kan nu härleda samma sessionsnyckel.
Beroende på applikationskravet kan Alice och Bob utföra ett valfritt steg för nyckelbekräftelse. Det finns flera sätt att göra det. En enkel metod som beskrivs i SPEKE fungerar följande: Alice skickar till Bob och sedan svarar Bob med . Alternativt kan Alice och Bob realisera explicit nyckelbekräftelse genom att använda den nykonstruerade sessionsnyckeln för att kryptera ett känt värde (eller en slumpmässig utmaning). EKE , Kerberos och Needham-Schroeder försöker alla ge uttrycklig nyckelbekräftelse med exakt denna metod.
Säkerhetsegenskaper
Med tanke på att det underliggande Schnorr icke-interaktiva nollkunskapsbeviset är säkert, har J-PAKE-protokollet visat sig uppfylla följande egenskaper:
- Off-line ordbok attackmotstånd - Den läcker inte någon lösenordsverifieringsinformation till en passiv/aktiv angripare.
- Sekretess för vidarebefordran - Den producerar sessionsnycklar som förblir säkra även när lösenordet senare avslöjas.
- Säkerhet med känd nyckel - Den förhindrar att en avslöjad sessionsnyckel påverkar säkerheten för andra sessioner.
- Online ordbok attackmotstånd - Det begränsar en aktiv angripare att testa endast ett lösenord per protokollexekvering.
Under 2015 genomförde Abdalla, Benhamouda och MacKenzie en oberoende formell analys av J-PAKE för att bevisa dess säkerhet i en slumpmässig orakelmodell med antagande av algebraiska motståndare.
Protokolldesignen
J-PAKE-protokollet är designat genom att kombinera slumpmässiga publika nycklar på ett sådant strukturerat sätt för att uppnå en försvinnande effekt om båda parter tillhandahåller exakt samma lösenord. Detta är på något sätt likt Anonymous veto-nätverksprotokolldesign . Kärnan i idén kan dock spåras tillbaka till David Chaums ursprungliga Dining Cryptographers nätverksprotokoll, där binära bitar kombineras på ett strukturerat sätt för att uppnå en försvinnande effekt.
Genomförandet
J-PAKE har implementerats i OpenSSL och OpenSSH som ett experimentellt autentiseringsprotokoll. Den togs bort från OpenSSH-källkoden i slutet av januari 2014. Den har även implementerats i Smoke Crypto Chat Messenger, i NSS och användes av Firefox Sync version 1.1 men avvecklades i 1.5 som använder en annan nyckelutbyte och lagringsmetod. Mozillas J-PAKE-server stängdes av tillsammans med Sync 1.1-lagringsservrarna den 30 september 2015. Pale Moon fortsätter att använda J-PAKE som en del av sin Sync-tjänst. Sedan februari 2013 har J-PAKE lagts till i det lätta API:et i Bouncycastle (1.48 och framåt). J-PAKE används också i tråden (nätverksprotokoll)
Standardisering
J-PAKE har inkluderats i ISO/IEC 11770-4 (2017) som en internationell standard. Den publiceras också i RFC 8236.
externa länkar
- J-PAKE utkast
- En prototypdemo av J-PAKE i C
- En prototypdemo av J-PAKE i Java
- Ett exempel på implementering av J-PAKE med elliptisk kurva
- J-PAKE: Från restaurangkryptering till jonglörer