Off-the-Record meddelanden

Den aktuella versionen av sidan har ännu inte granskats av erfarna bidragsgivare och kan skilja sig väsentligt från versionen som granskades den 28 maj 2018; kontroller kräver 7 redigeringar .

Off-the-Record Messaging (OTR) är  ett kryptografiskt protokoll för snabbmeddelandesystem skapat 2004 av Nikita Borisov och Ian Goldberg . 

Författarna har skapat ett bibliotek som distribueras under GNU Lesser GPL-licensen , som används för att stödja OTR-klienter för snabbmeddelandesystem. Baserat på detta bibliotek skapade författarna också ett plugin för Pidgin .

EFF rekommenderar användning av OTR för avlyssning [1] .

Historik

Den första versionen av OTR-protokollet och dess implementering presenterades 2004 av Nikita Borisov och Ian Goldberg [2] [3] . 2005 publicerades en attack mot den första versionen av OTR-protokollet och ett reviderat autentiseringsprotokoll föreslogs [4] . Samma år introducerade utvecklarna av OTR den andra versionen av protokollet med korrigering av autentiseringsprotokollet, vilket också förbättrade det ytterligare [5] .

2007 publicerade Olivier Goffart modulen mod_otr  [6] för ejabberd -servern , som tillåter automatiska man-in-the-middle- attacker mot OTR-användare som inte verifierar varandras publika nyckelfingeravtryck. Utvecklarna förbättrade sedan OTR med en Socialist Millionaire- lösning som tillåter två användare att autentisera utan att byta nycklar eller deras fingeravtryck, förutsatt att de känner till den delade hemligheten [7] .  

Grundläggande egenskaper för protokollet

OTR-protokollet utvecklades för att säkerställa förhandlingarnas integritet , liknande förhandlingar utan användning av telekommunikation [8] [9] . För detta ändamål presenterades följande krav för det utvecklade protokollet:

Vissa av dessa funktioner är implementerade i system som PGP och Trillian SecureIM. OTR är annorlunda genom att den implementerar alla dessa funktioner i ett enda protokoll [10] .

Nyckelavtal

För att skicka meddelanden med OTR måste protokolldeltagare upprätta en delad hemlighet. För detta används protokollet Authenticated Key Exchange ,  baseratDiffie-Hellman-protokollet [11] .

I början av protokollet använder deltagarna Diffie-Hellman-protokollet för att fastställa den hemliga nyckel som behövs för att överföra det första meddelandet. Medlemmarna A och B väljer ett primtal och en gruppgenerator . A väljer ett slumpmässigt tal och skickar B resultatet av beräkningen . B väljer ett slumpmässigt tal och skickar A resultatet av beräkningen . Deltagarna använder sedan den delade flyktiga nyckeln , där  är den kryptografiska hashfunktionen SHA-1 [12] .

Förnya nycklar

För att säkerställa perfekt sekretess för vidarebefordran , förnyar användare ständigt nyckeln under utbytet av meddelanden [13] [14] . När det första meddelandet sänds krypterar en av parterna (till exempel part A) meddelandet med hjälp av krypteringsfunktionen med en nyckel , väljer ett slumptal och skickar B ett par värden . Nyckeln används för att kryptera nästa meddelande . I framtiden, med varje meddelande, ändrar A numret och B ändrar numret och nyckeln uppdateras.

I praktiken når meddelanden inte direkt, så efter att ha skickat ett meddelande från A till B och uppdaterat nyckeln på sidan av A kan A fortfarande ta emot ett meddelande från B krypterat med den gamla nyckeln [15] . Deltagare A kan vara säker på att B har uppdaterat nyckeln först när han får från B ett meddelande krypterat med den nya nyckeln. Därför behåller A tillräckligt många gamla nycklar för att kunna dekryptera alla meddelanden som ännu inte har kommit. För att hålla nycklarna uppdaterade tillräckligt ofta skickar den sida som inte har några meddelanden att skicka tomma meddelanden då och då [16] .

Författarna till artikeln "Secure Off-the-Record Messaging" kritiserade det nyckelförnyelseschema som används i OTR för att inte ge ytterligare säkerhet [17] . Således, i händelse av en kompromiss av den efemära nyckeln som fortfarande används , kommer den som utför man-in-the-middle- attacken att kunna modifiera alla efterföljande meddelanden och de tillfälliga nycklarna som används [18] . Dessutom kan användningen av Diffie-Hellman-protokollet kräva betydande (till exempel för batteridrivna enheter) resurser [19] . Istället föreslogs att använda samma schema som för nyckeln , eller ett mindre beräkningskrävande schema baserat på hash [20] .

Nyckelautentisering

Autentisering av alla tillfälliga nycklar utom , utförs tillsammans med meddelandeautentisering och beskrivs vidare [21] . Långtidsnycklar används för nyckelautentisering . Den första versionen av OTR använde ett osäkert autentiseringsschema, som senare ändrades [22] .

Ursprunglig version av protokollet

I den första versionen av OTR-protokollet undertecknar parterna lämpliga Diffie-Hellman-protokollmeddelanden [23] för att autentisera den initiala nyckeln . Även i dessa meddelanden överför parterna sina långsiktiga publika nycklar.

Här , och  är den digitala signaturen och och  är de offentliga nycklarna för parterna A respektive B.

Denna version av protokollet innehåller en känd sårbarhet [24] [25] . Part E, som utför en man-in-the-midten- attack , kan autentisera med part A och B samtidigt, samtidigt som den låtsas vara en av parterna (till exempel B) som den andra sidan (till exempel A) , enligt nedanstående.

Efter det kan E inte läsa meddelandena, eftersom de är krypterade med en nyckel som endast A och B känner till, men B tror att han pratar med E, fastän han faktiskt pratar med A [26] .

Säkrare protokoll som SKEME övervägdes när den första versionen av OTR-protokollet implementerades, men istället implementerades ett proprietärt protokoll enligt beskrivningen ovan [27] .

Andra versionen av protokollet

Författarna till artikeln Secure Off-the-Record Messaging föreslog att protokollet för nyckelförhandling och autentisering skulle ändras till ett av de redan kända protokollen som SIGMA , SKEME och HMQV [28] . Även i dessa meddelanden överför parterna sina långsiktiga publika nycklar.

En variant av SIGMA - protokollet , kallad SIGMA-R, fungerar enligt följande [29] :

Här är A och B identifierare och  är digitala signaturer och  är de publika nycklarna för parterna A respektive B, och  är en kryptografisk hashfunktion.

Författarna till OTR använde en modifiering av SIGMA-protokollet i den andra versionen av OTR [30] . Jämfört med det föreslagna SIGMA-protokollet har OTR-utvecklare skyddat publika nycklar från passiv attack (avlyssning). För att göra detta sänds publika nycklar över en säker kanal etablerad med hjälp av Diffie-Hellman-protokollet [31] . Modifieringen av SIGMA- protokollet som används i OTR är också komplicerad på grund av meddelandestorleksbegränsningar i vissa protokoll ( till exempel ]]32[)IRC .

Meddelandeautentisering

Till skillnad från system som PGP använder OTR inte digitala signaturer för att autentisera meddelanden, eftersom de inte tillhandahåller förnekbara autentiseringsmöjligheter [36] . Istället används HMAC [37] .

För meddelandeautentisering används nyckeln K, erhållen genom att hasha nyckeln som används för att kryptera meddelandet [38] .

När part A skickar ett meddelande M till en annan part B, skickar den det publika nyckelvärdet HMAC(M, K) [39] tillsammans med meddelandet . Part B kan, vid mottagande av meddelandet, även beräkna HMAC(M, K). Om det matchar det mottagna värdet, då vet part B att meddelandet överfördes av antingen part A eller part B, men eftersom part B vet att det inte skickade meddelandet, då kan det vara säkert att meddelandet faktiskt skickades av part A Samtidigt ger användningen av HMAC förnekelse: även genom att avslöja nyckeln K kan B inte bevisa för en tredje part att meddelandet skickades av part A. Meddelandet kan också förfalskas av part B och någon part som vet nyckeln K.

Avslöjande autentiseringsnycklar

De nycklar som används för kryptering uppdateras ständigt enligt beskrivningen ovan . Eftersom nycklarna som används för autentisering erhålls genom att hasha de nycklar som används för kryptering, uppdateras de också.

Gamla nycklar som inte längre kommer att användas kan förstöras. Men autentiseringsnycklar kan också inte bara förstöras, utan också avslöjas. Författarna till OTR har lagt till gamla nyckelavslöjande: den gamla autentiseringsnyckeln skickas tillsammans med meddelandet om det är känt att det inte längre kommer att användas [40] . Detta beslut förklaras av kraven på förnekelse av OTR-protokollet [41] [42] .

Verket Secure Off-the-Record Messaging påpekar att avslöjandet av autentiseringsnycklar onödigt komplicerar protokollet och kan vara negativt osäkert, som en icke-standard metod för kryptografi [43] . Författaren till det OTR-baserade TextSecure-protokollet, alias Moxie Marlinspike , påpekar också komplexiteten och ineffektiviteten i att exponera autentiseringsnycklar för att säkerställa förnekelse [44] .

Meddelandekryptering

För att kryptera meddelanden används AES- algoritmen i räknarläge [45] . Att använda ett strömchiffer konstruerat på detta sätt ger formbar kryptering .  Detta innebär att alla som fångar upp meddelandet kommer att selektivt kunna ändra alla bitar i meddelandet. När meddelandet väl har blivit känt kan det i synnerhet ändras till vilket annat meddelande som helst av samma längd [46] .

Kontroversiell kryptering krävs för att säkerställa att krypteringen kan förnekas [47] . Med tvivelaktig kryptering kan deltagare i OTR-protokollet hävda att något av de överförda meddelandena har ändrats av en tredje part.

Multiplayer OTR

OTR-protokollet är utformat för att endast användas av två parter. Den kan alltså inte användas i IRC -kanaler, XMPP - konferenser etc.

OTR kan inte helt enkelt utvidgas till fallet med flera högtalare på grund av de kryptografiska primitiv som används. Till exempel ger meddelandeautentiseringskoder inte meddelandekällaautentisering i fleranvändarfallet [48] .

Det finns tillägg till protokollet som tillåter flera användare att använda protokollet [49] [50] [51] .

En förlängning av OTR-protokollet som kallas GOTR (Group OTR) är baserad på idén om att skapa en "virtuell server" [52] . En av deltagarna utses till "virtuell server", byter nycklar med andra deltagare och i framtiden skickas alla meddelanden mellan konferensdeltagare via den. Nackdelen med GOTR-protokollet är att den "virtuella servern" kan ändra innehållet i meddelanden, lägga till och ta bort meddelanden, så alla deltagare i konferensen måste lita på den [53] .

Senare föreslog Ian Goldberg och andra författare mpOTR- protokollet [51] . Till skillnad från GOTR-protokollet fungerar mpOTR-protokollet utan en dedikerad central server [54] .

OTR-implementationer

libotr
Sorts Bibliotek
Författare Ian Goldberg [d] och Nikita Borisov [d]
Utvecklaren OTR utvecklingsteam
Skrivet i C
Hårdvaruplattform plattformsoberoende
senaste versionen 4.0.2 ( 9 mars 2016 )
stat Faktisk
Licens GNU Lesser General Public License version 2 [55]
Hemsida otr.cypherpunks.ca/index...

Den huvudsakliga implementeringen av OTR är libotr-biblioteket skapat av OTR-utvecklingsteamet. Baserat på det skapade samma utvecklare ett plugin för Pidgin-klienten som låter dig använda OTR med något av de protokoll som stöds av denna klient. Det finns även implementeringar av protokollet i Go , Java , JavaScript , Python , Scheme [56] .

Messenger-stöd

Inbyggt stöd

Följande klienter har inbyggt stöd för OTR-protokollet [57] .

Använda plugin

Proxy

För klienter som stöder AIM / ICQ- protokollet har OTR-utvecklingsteamet utvecklat paketet otrproxy, som är en lokal proxyserver [71] . Det tillät användning av OTR i klienter som inte hade inbyggt OTR-stöd. För närvarande stöds inte detta paket, utvecklarna rekommenderar att du använder klienter med OTR-stöd.

Anteckningar

  1. Övervakningssjälvförsvar: Instant Messaging (IM) . - "För att skydda meddelanden från avlyssning när de färdas över nätverket måste du använda kryptering. Lyckligtvis finns det ett utmärkt krypteringssystem för snabbmeddelanden som heter OTR (Off The Record).". Hämtad 22 oktober 2013. Arkiverad från originalet 13 oktober 2013.
  2. borisov2004off, 2004 .
  3. impauth, 2007 , 2.1 Original OTR Protocol, sid. 42: "Det ursprungliga OTR-protokollet presenterades av Borisov, Goldberg och Brewer 2004".
  4. di2005secure, 2005 .
  5. impauth, 2007 , 2.3 OTR version 2, sid. 43: "OTR version 2 släpptes 2005. Den största förändringen i version 2 var omarbetningen av det initiala autentiserade nyckelutbytet (AKE).".
  6. mod_otr . Hämtad 20 oktober 2013. Arkiverad från originalet 29 september 2013.
  7. impauth, 2007 , 4. Socialist Millionaires' Protocol, sid. 44.
  8. impauth, 2007 , 2.1 Original OTR Protocol, sid. 41: "Det ursprungliga OTR-protokollet presenterades av Borisov, Goldberg och Brewer 2004. Det motiverades av idén om två personer, säg Alice och Bob, som pratade ansikte mot ansikte i ett privat rum."
  9. goldberg2009multi, 2009 , 1. Motivation, sid. 359: "Även om detta kan vara genomförbart under vissa omständigheter, avviker det från det ursprungliga OTR-målet, som är att efterlikna privata konversationer."
  10. borisov2004off, 2004 , 1. Introduktion, sid. 77: "Men ingen av de mekanismer som för närvarande används för social kommunikation har alla dessa egenskaper."
  11. impauth, 2007 , 2.1 Original OTR Protocol, sid. 42: "Till att börja med använder OTR en Diffie-Hellman (DH) nyckelutbyte för att etablera en delad hemlighet mellan Alice och Bob."
  12. borisov2004off, 2004 , 4.1 Kryptering, sid. 80.
  13. borisov2004off, 2004 , 3.1 Perfect forward sekretess, sid. 78: "Vi kringgår detta problem genom att använda kortlivade krypterings-/dekrypteringsnycklar som genereras efter behov och kasseras efter användning."
  14. impauth, 2007 , 2.1 Original OTR Protocol, sid. 42: "Vid det här laget kan Alice och Bob börja skicka krypterade meddelanden till varandra. För att begränsa mängden information som äventyras om en motståndare bestämmer den delade nyckeln, nycklar Alice och Bob om så ofta som möjligt. ... Denna procedur ger OTR egenskapen perfekt framåtsekretess (PFS), vilket säkerställer att framtida nyckelkompromisser inte kan avslöja innehållet i gamla meddelanden."
  15. borisov2004off, 2004 , 4.2 Forgetting Keys, sid. 80: "Men eftersom meddelandeprotokoll vanligtvis är asynkrona, är det möjligt att det fortfarande finns ett meddelande på väg från Bob som krypterats med den tidigare nyckeln."
  16. borisov2004off, 2004 , 4.2 Forgetting Keys, sid. 81: "För att lösa detta problem bör Bob regelbundet skicka ett tomt meddelande som bekräftar mottagandet av en ny nyckel från Alice."
  17. di2005secure, 2005 , 6.3 On the Key Refreshing, sid. 89: "Således är värdet av att utföra ett DH-nyckelutbyte med varje meddelande där autentisering beror på den tidigare delade nyckeln av begränsat värde."
  18. di2005secure, 2005 , 6.3 On the Key Refreshing, sid. 88: "Vi noterar dock att om motståndaren lär sig den aktuella tillfälliga nyckeln, kan framtida meddelanden bli fullständigt äventyrade."
  19. di2005secure, 2005 , 6.3 On the Key Refreshing, sid. 89: "Detta är ännu mer med tanke på beräkningskostnaden för en DH-utbyte."
  20. di2005secure, 2005 , Därför föreslår vi att OTR kommer att åtnjuta bättre övergripande säkerhet genom att köra AKE-protokollet med jämna mellanrum. Om en finkornig uppfriskande mekanism önskas för att sekretessbelägga framåt, kan en lättare, men ändå kraftfull, mekanism användas, såsom att härleda nya nycklar (eventuellt på per-meddelande-basis, om så önskas) genom envägs-hashning föregående tangent., sid. 89.
  21. borisov2004off, 2004 , 4.3 Autentisering, sid. 81: "Vi behöver bara använda en digital signatur på det första nyckelutbytet. I ytterligare nyckelutbyten använder vi MAC:er för att autentisera en ny nyckel med hjälp av en gammal, känd och autentisk delad hemlighet."
  22. impauth, 2007 .
  23. borisov2004off, 2004 , 4.3 Autentisering, sid. 81: "Krypteringsnyckeln är i sig resultatet av en hash av den delade Diffie-Hellman hemligheten, som också måste autentiseras på något sätt. Vi åstadkommer detta genom att digitalt signera den första Diffie-Hellman-börsen."
  24. di2005secure, 2005 , 3.1 Ett autentiseringsfel, sid. 84.
  25. impauth, 2007 , 2.2 Attack on OTR version 1, sid. 42.
  26. borisov2004off, 2004 , 2.2 Attack on OTR version 1, sid. 42: "Denna attack tillåter en motståndare Eve att störa det initiala nyckelutbytet på ett sådant sätt att Alice och Bob fortfarande når samma nyckel i slutet av protokollet, men Alice tror att hon pratar med Bob medan Bob tror att han pratar till Eva."
  27. borisov2004off, 2004 , 7. Relaterat arbete, sid. 83: "Om anonymitet önskas kan man använda antingen SKEME eller Abadis privata autentisering istället för det signerade Diffie-Hellman-nyckelutbytet i vårt protokoll."
  28. di2005secure, 2005 , 4. Building A Sound AKE For OTR, sid. 85.
  29. di2005secure, 2005 , 4.1 SIGMA, sid. 85.
  30. impauth, 2007 , 2.3 OTR version 2, sid. 43: "Den största förändringen i version 2 var omarbetningen av den initiala autentiserade nyckelutbytet (AKE). Som svar på attacken som nämns ovan ändrades AKE till en SIGMA-variant, som föreslagits."
  31. impauth, 2007 , 2.3 OTR version 2, sid. 43: "Där de offentliga nycklarna tidigare skickades i klartext, är de nu krypterade med den delade hemligheten för DH."
  32. impauth, 2007 , 2.3 OTR version 2, sid. 43: "Syftet med r i stegen ovan är att tillfredsställa en teknisk begränsning: många IM-protokoll tvingar fram en maximal storlek på meddelanden."
  33. impauth, 2007 , 2.3 OTR version 2, sid. 43.
  34. OTRv2 .
  35. OTRv3 .
  36. borisov2004off, 2004 , 3.2 Digitala signaturer och icke-avvisande, sid. 79: "Av denna anledning använder vi aldrig en digital signatur för att bevisa Alices författare till något meddelande."
  37. borisov2004off, 2004 , 3.3 MACs and repudiability, sid. 79.
  38. impauth, 2007 , 2.1 Original OTR Protocol, sid. 42: "MAC-nyckeln som används är en hash av dekrypteringsnyckeln för det meddelandet."
  39. borisov2004off, 2004 , 3.3 MACs and repudiability, sid. 79: "Alice använder sin kopia av MAC-nyckeln för att beräkna en MAC av sitt meddelande och skickar denna MAC tillsammans med sitt meddelande i en säker överföring."
  40. borisov2004off, 2004 , 4.4 Avslöjande av MAC-nycklar, sid. 81.
  41. borisov2004off, 2004 , 4.4 Avslöjande av MAC-nycklar, sid. 81: "Observera vad detta har åstadkommit: Bob behöver inte längre förlita sig på den här nyckeln, eftersom han redan har kontrollerat alla meddelanden som autentiserats av den nyckeln. Men nu kan vem som helst skapa godtyckliga meddelanden som har denna MAC-nyckel, och ingen kan utesluta någon speciell person som potentiell författare till meddelandet."
  42. di2005secure, 2005 , 2.3 Kryptering och autentisering av meddelanden, sid. 84: "Anledningen till ovanstående val (dvs en formbar kryptering och avslöjande av MAC-nycklarna) är förnekelse."
  43. di2005secure, 2005 , 6.1 Förkastelse av den symmetriska krypteringen, sid. 88: "För det tredje introducerar avslöjande av MAC-nycklarna timing och synkroniseringsproblem som behövs för att förhindra ett för tidigt avslöjande. Även om detta är möjligt resulterar detta i ökad komplexitet till systemet. Även om ovanstående överväganden i viss mån kan ses som subjektiva, illustrerar vi i nästa underavsnitt faran med att lägga till icke-standardiserade säkerhetstekniker."
  44. Enkelhet , begränsningar.
  45. di2005secure, 2005 , 2.3 Kryptering och autentisering av meddelanden, sid. 83: "Meddelandet krypteras först med AES i räknarläge och sedan autentiseras den resulterande chiffertexten med HMAC (med hashfunktion SHA-1).".
  46. borisov2004off, 2004 , 3.4 Formbar kryptering och förfalskning, sid. 80: "Denna kryptering är formbar, eftersom en ändring av vilken bit som helst i chiffertexten kommer att motsvara en ändring av motsvarande bit i klartexten. I synnerhet, om Eve kan gissa klartexten i ett meddelande, kan hon sedan ändra chiffertexten för att dekryptera till något annat meddelande av samma längd, utan att känna till nyckeln."
  47. di2005secure, 2005 , Anledningen till ovanstående val (dvs en formbar kryptering och avslöjande av MAC-nycklarna) är förnekelse., sid. 84.
  48. goldberg2009multi, 2009 : "Till exempel använder OTR meddelandeautentiseringskoder (MAC) för att tillhandahålla autenticitet. Även om MAC:er för två parter kan tillhandahålla en förnekbar autentiseringsmekanism, tillhandahåller MAC:er inte ursprungsautentisering när de används av fler än två parter."
  49. bian2007off, 2007 .
  50. bian2007public, 2007 .
  51. 1 2 goldberg2009multi, 2009 .
  52. bian2007off, 2007 , 3.1. Initial design, sid. 81: "Huvudkonceptet för vår implementering är att skapa en virtuell server, som är en chattmedlem som bokstavligen fungerar som en server."
  53. goldberg2009multi, 2009 , 1. Motivation, sid. 359: "Slutligen måste servern antas vara ärlig, eftersom en oärlig server kan äventyra både konfidentialitet och integritet för alla meddelanden som skickas under en chattsession."
  54. goldberg2009multi, 2009 , 5. Slutsats, sid. 367: "Vårt föreslagna ramverk för Off-the-Record-kommunikation med flera parter är inte beroende av en central server; istället utvecklade vi en modell som efterliknar ett typiskt privat möte där varje användare autentiserar de andra deltagarna för sig själv."
  55. Off-the-Record meddelanden . Hämtad 10 november 2013. Arkiverad från originalet 17 augusti 2014.
  56. Bibliotek som stöder OTR . Hämtad 10 november 2013. Arkiverad från originalet 10 november 2013.
  57. https://otr.cypherpunks.ca/software.php Arkiverad 10 november 2013 på Wayback Machine IM-klienter som stöder Off-the-Record Messaging "out of the box"
  58. Få OTR att fungera med bitlbee . Hämtad 10 november 2013. Arkiverad från originalet 20 november 2013.
  59. OTR-plugin . Hämtad 6 september 2017. Arkiverad från originalet 13 juni 2019.
  60. Psi+ ögonblicksbilder
  61. OTR-plugin . Hämtad 23 april 2014. Arkiverad från originalet 11 januari 2016.
  62. Kort beskrivning . Hämtad 23 april 2014. Arkiverad från originalet 24 april 2014.
  63. Källkod Arkiverad 17 maj 2014.
  64. Som beskrivs på den officiella webbplatsen Arkiverad 9 april 2022 på Wayback Machine
  65. Officiell OTR-plugin för Gajim (nedlänk) . Hämtad 6 september 2017. Arkiverad från originalet 6 september 2017. 
  66. OTR-plugin på Wiki . Hämtad 6 september 2017. Arkiverad från originalet 6 september 2017.
  67. Home of irssi-otr and xchat-otr. Дата обращения: 10 ноября 2013. Архивировано 10 ноября 2013 года.
  68. OTR-plugin för Miranda IM Arkiverad 13 maj 2007.
  69. Ytterligare plugins för Vacuum-IM-projekt . Hämtad 24 oktober 2010. Arkiverad från originalet 23 maj 2011.
  70. Tkabber OTR Plugin Arkiverad 11 mars 2014.
  71. OTR localhost AIM proxy . Hämtad 10 november 2013. Arkiverad från originalet 12 april 2018.

Litteratur

Länkar