MQV

Aktuální verze stránky ještě nebyla zkontrolována zkušenými přispěvateli a může se výrazně lišit od verze recenzované 29. dubna 2016; kontroly vyžadují 9 úprav .

MQV ( Meneses-Q-Wanstone ) je autentizační protokol založený na algoritmu Diffie-Hellman . MQV poskytuje ochranu proti aktivním útokům kombinací statických a dočasných klíčů. Protokol lze upravit tak, aby fungoval v libovolné konečné komutativní grupě , a zejména ve skupinách eliptických křivek , kde je znám jako ECMQV .

MQV původně navrhli Alfred Menezes , Minghua Q a Scott Vanstone v roce 1995. V roce 1998 byl upraven. Existují jedno-, dvou- a třícestné verze algoritmu.

MQV je součástí projektu standardizace kryptosystému veřejného klíče - IEEE P1363 .

Patenty na některé odrůdy MQV vlastní Certicom [ 1] .

MQV má některé slabiny, které byly opraveny algoritmem HMQV v roce 2005 [2] ; viz [3] , [4] , [5] .

Algoritmy MQV i HMQV mají zranitelnosti, které byly opraveny protokolem FHMQV (viz [6] )

Popis

Alice má statický pár klíčů ( ), kde je její veřejný klíč a soukromý klíč. Bob má statický pár klíčů ( ), kde je jeho veřejný klíč a jeho soukromý klíč. Pojďme definovat . Nechť je bod na eliptické křivce. Potom , kde je pořadí použitého generátoru bodů . Existují tedy první bity souřadnice pro . Navíc zavádíme kofaktor definovaný jako , kde je pořadí skupiny a je třeba vzít v úvahu, že z technických důvodů musí být splněn požadavek: [1] .

Krok Úkon
jeden Alice vytvoří klíčový pár ( ) náhodným vygenerováním a výpočtem = , kde  je bod na eliptické křivce. Poté pošle dočasný veřejný klíč Bobovi.
2 Bob vytvoří pár klíčů ( ) náhodným generováním a výpočtem = . Po spárování odešle svůj dočasný veřejný klíč Alici.
3 Alice zkontroluje, že dočasný veřejný klíč patří do skupiny a také, že se nejedná o nulový prvek. Poté vypočítá prvek skupiny jako , where a . Pokud , Alice odmítne data přijatá od Boba. Jinak přijme vypočítaný výsledek jako sdílený tajný klíč.
čtyři Bob zkontroluje, že dočasný veřejný klíč patří do skupiny a také, že se nejedná o nulový prvek. Vypočítá prvek skupiny jako , where a . Pokud , Bob odmítne data přijatá od Alice. Jinak přijme vypočítaný výsledek jako sdílený tajný klíč.

Základní protokol je atraktivním řešením z několika důvodů:

  1. Poskytuje implicitní identifikaci klíče a následné zabezpečení pro každého peer.
  2. Je efektivní nejen z hlediska výpočtů, ale také z hlediska propustnosti, protože využívá pouze operace specifikované na poli a jednoduché zobrazení. Výpočty každého účastníka (v hrubém odhadu) se skládají pouze z 2,5 násobení – jedno pro generování dočasného páru klíčů, druhé pro skalární násobení pomocí nebo .

Zbytek výpočtů je násobení nebo . Za zvážení stojí i náklady na násobení kofaktorem. Tato složitost (násobení kofaktorem) však závisí na velikosti skupiny. Pro kryptosystémy založené na eliptických křivkách je tato složitost zanedbatelná, protože kofaktor je obvykle malý [2] .

Správnost

Bobovy výpočty: .

Aliceiny výpočty: .

Klávesy jsou tedy skutečně ekvivalentní klávese [3] .

Možné útoky

Nejjednodušší možností, kterou může útočník (kryptoanalytik) použít, je získat certifikát (identifikátor), který spojuje jeho jméno s veřejným klíčem, který má Alice. Pokud v tomto protokolu nahradí Alicin identifikátor svým vlastním, existuje značná šance, že Bob daný identifikátor přijme, aniž by si záměny všiml, ve skutečnosti si myslí, že mluví s Alicí. Zde je útok založený na substituci zdroje. Tento útok naznačuje potřebu požadavků na vlastnictví klíče: žadatel musí znát tajný klíč, aby získal identifikátor odpovídající veřejnému klíči. V zásadě by centrum identity mohlo zařídit kontrolu duplicitních veřejných klíčů, ale tento krok je nepraktický, protože zahrnuje účast velkého počtu center identit. Útočník tedy musí získat identifikátor pro nový veřejný klíč , takový, že existuje shoda pro tajný klíč , a takový, aby Bob při interakci s útočníkem vypočítal stejné sdílené tajemství, jaké by při interakci vypočítali Bob a Alice. Následující implementace splňuje všechny výše uvedené cíle. Označme útočníka jako Evu [3] .

Krok Úkon
jeden Eva zachytí dočasný veřejný klíč Alice na cestě k Bobovi.
2 Eva vybere celé číslo , které patří do mezery, a vypočítá dočasný veřejný klíč jako (všimněte si, že Eva nezná odpovídající tajný klíč ). Pokud , Eva zopakuje tento krok s dalším celým číslem .
3 Eva vypočítá statický pár jako ,

.

čtyři Eva obdrží identifikátor pro svůj statický veřejný klíč . Zná tedy odpovídající tajný klíč . Splňuje tedy požadavky na vlastnictví klíče.
5 Eva zahájí protokol s Bobem zasláním svého dočasného veřejného klíče .
6 Eva obdrží Bobův dočasný veřejný klíč a dá ho Alici.

V důsledku tohoto útoku Alice zkontroluje Bobovo ID a vypočítá sdílené tajemství , zatímco Bob obdrží a ověří Evino ID a vypočítá sdílené tajemství , jak je definováno dříve a .

Bobův klíč bude stejný, jako kdyby Bob interagoval s Alicí.

.

Eva musí získat identifikátor pro svůj statický veřejný klíč v době, kdy Alice spouští protokol. Alice si tedy může všimnout zpoždění mezi okamžikem odeslání jejího dočasného veřejného klíče a okamžikem, kdy obdrží Bobovo ID.

Protiopatření útoku

V první řadě je prvním krokem zařazení do protokolu operace, která bude vyhrazena pro kontrolu existence klíče. Tento tip platí pro všechny ověřovací protokoly. Aby tedy Eva prošla Bobovým ověřením, bude muset projít další kontrolou. Dalším protiopatřením, které lze do protokolu zavést, je, aby si strany před výměnou dočasných klíčů vyměnily jednosměrné hash svých dočasných veřejných klíčů. Mechanismus výměny je v tomto případě opravdu důležitý. Každá strana si musí být jistá, že druhý člen skutečně obdržel „balíček“, než mu pošle dočasný veřejný klíč. Potvrzení této skutečnosti lze získat příslušnou sekvencí. Například Alice pošle své potvrzení, Bob je obdrží a pošle své potvrzení. Alice obdrží Bobovo potvrzení a pošle svůj klíč. Když Bob obdrží klíč Alice, pošle svůj vlastní klíč. Bez takové sekvence, například pokud Bob a Alice posílají oba současně, bude tento protokol zranitelný vůči některým typům útoků [4] .

Pojďme se podívat na další protiopatření.

  1. Detektor zpoždění je alternativou, která nepoužívá kryptografii. Implementace tzv. delay checkeru. Strana (Bob nebo Alice) ukončí protokol, pokud doba odezvy druhé strany překročí povolenou hodnotu uvedenou v implementaci protokolu. Když tedy Eva požaduje identifikátor, může tento krok vyžadovat další čas (existují však způsoby, jak tuto složitost obejít). Navíc bude dodatečný čas srovnatelný s časem jiných operací zahrnutých v protokolu. Toto protiopatření však nepomůže v případě vícekrokového útoku.
  2. "Identifikátor záznamu". Příjemce si může vyžádat doklad o stáří identifikátoru. Nově získaný průkaz totožnosti může být považován za důkaz útoku. Poté bude komunikační kanál s útočníkem uzavřen.
  3. Identifikace účastníků prostřednictvím zpráv. Hlavním principem návrhu protokolů je, že zprávy by měly nést dostatek informací, aby se zabránilo chybné interpretaci. V souladu s tím musí zprávy chráněné sdíleným tajemstvím identifikovat účastníky přenosu. Taková identifikace by zabránila možnosti nesprávné interpretace.

Všechna výše uvedená vylepšení zavádějí minimální úpravy struktury protokolu. Stojí za zmínku, že neexistuje žádný formální důkaz o úplné bezpečnosti protokolu, který je upraven pomocí výše uvedených doporučení.

Viz také

Poznámky

  1. Kaliski, 2001 , str. 277.
  2. Kaliski, 2001 , str. 278.
  3. 1 2 Kaliski, 2001 , str. 280.
  4. Kaliski, 2001 , str. 281.

Literatura

Odkazy