HOTP

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é 4. ledna 2017; ověření vyžaduje 31 úprav .

HOTP ( HMAC -Based One-Time Password Algorithm ) je bezpečný autentizační algoritmus využívající jednorázové heslo (One Time Password, OTP). Založeno na HMAC (SHA-1). Jedná se o jednosměrný ověřovací algoritmus, konkrétně: server ověřuje klienta .

Událost se používá jako parametr odpovědný za dynamiku generování hesla, tedy samotný fakt generování [1] : pokaždé, když je vytvořeno nové heslo, počítadlo událostí zvýší svou hodnotu o jednu, a to je toto monotónní zvýšení hodnota, která se používá jako hlavní parametr algoritmu. Druhým parametrem pro výpočet jednorázových hesel je symetrický klíč, který musí být jedinečný pro každý generátor (klienta) a soukromý od všech kromě serveru a generátoru (klienta) samotného.

Historie

Algoritmus byl poprvé formálně popsán týmem IETF v prosinci 2005. [2] [3] Byl to první skutečně úspěšný projekt iniciativy pro otevřenou autentizaci ( OATH ). [4] Algoritmy pro generování jednorázových hesel si v té době získaly velkou oblibu díky rychlému rozvoji mobilního průmyslu. Vyžaduje spolehlivý algoritmus, jednoduchý z hlediska implementace.

V roce 2008 HOTP zrodil silnější časový algoritmus jednorázového hesla (TOTP), který do značné míry zdědil vlastnosti svého rodiče. V září 2010 byl vyvinut výkonný ověřovací algoritmus OATH Challenge-Response Algorithm ( OCRA ) založený na TOTP. [čtyři]

Algoritmus HOTP také představil novinky v technologii generování jednorázových hesel. Hashovací funkce SHA-1 , která byla v té době stabilní, byla kombinována s netriviálním řešením mít čítač událostí. Tyto funkce pozvedly HOTP na stejnou úroveň jako časem prověřené algoritmy, jako je S/KEY . [čtyři]

Čítače v HOTP a TOTP

Hlavním rozdílem mezi těmito dvěma algoritmy je generování hesla na základě časového razítka, které algoritmus TOTP používá jako parametr. V tomto případě se nepoužívá přesná časová hodnota, ale aktuální interval, jehož hranice byly předem nastaveny (například 30 sekund) [5]

HOTP generuje klíč na základě sdíleného tajemství a časově nezávislého čítače. Model tohoto algoritmu je založen na událostech – například při každém vygenerování dalšího jednorázového hesla se počítadlo zvýší. Následně vygenerovaná hesla proto musí být pokaždé jiná.

Díky tomu je základ čítače v algoritmu HOTP, na rozdíl od jiných algoritmů, které používají časovač, chráněn před desynchronizací vysílacích zařízení nebo příliš velkou vzdáleností mezi nimi (taková vzdálenost, že odpověď od příjemce přijde později než vyprší doba platnosti hesla) [2] . To umožňuje, aby hesla HOTP zůstala platná po neomezenou dobu, zatímco hesla TOTP po určité době již nebudou platná.

V důsledku toho, za předpokladu, že je použita stejná hashovací funkce jako v HOTP, tento rozdíl ve fungování algoritmu dělá z TOTP bezpečnější a preferované řešení pro jednorázová hesla [6]

Popis algoritmu

Notace

$K$ - Tajný klíč, který je jedinečný pro každého klienta a zná ho pouze on a server. Délka — 160 bitů (doporučeno) nebo 128 bitů (minimálně) [1]
$C$ — Aktuální stav 8bajtového čítače událostí
$D$ — Počet číslic ve vygenerovaném hesle
$T$ - Počet neúspěšných pokusů o autorizaci, po kterých server zablokuje spojení s klientem
$s$ — Parametr desynchronizace. Definuje maximální nesoulad mezi čítačem serveru a klienta, při kterém bude akceptováno jednorázové heslo.

Obecný popis

Algoritmus musí vrátit alespoň 6 číslic, aby bylo zajištěno dostatečné zabezpečení hesla. V závislosti na úrovni požadavků na zabezpečení můžete pro HOTP použít vyšší číselné hodnoty, aby bylo heslo odolnější vůči útokům. Činnost algoritmu lze popsat následujícím vzorcem [1] :

H Ó T P ( K , C ) = T r u n C A t E ( H M A C − S H A − jeden ( K , C ) ) {\displaystyle HOTP(K,C)=Truncate(HMAC-SHA-1(K,C))}

HOTP(K,C)=Truncate(HMAC-SHA-1(K,C))

Proces algoritmu lze rozdělit do následujících fází:

Řetězec 20 bajtů se vytvoří pomocí hashovací funkce inicializované s parametry a : ${\textstyle HS}$ $HMAC-SHA-1$ $K$ $C$ $HS=HMAC-SHA-1(K,C)$
4 bajty jsou vybrány určitým způsobem z : $HS$ $S_{bits}=Truncate(HS)$
1. Poslední čtyři bity posledního bajtu výsledku jsou převedeny na číslo $S_{bits}[19]$ $offset\in (0,15)$
2. Posloupnost bajtů je převedena na proměnnou $HS[offset]..HS[offset+3]$ $P$
3. $Truncate(HS)$ vrací posledních 31 bitů Důvod, proč je nejvýznamnější bit ignorován, je způsoben různými implementacemi celočíselných výpočtů v různých procesorech [1] $P$ $P$
Výsledek práce se převede na posloupnost čísel: $Truncate()$ $D$ ${\displaystyle HOTP=toNumber(Truncate(HS))\,\,mod\,10^{D))$

Příklad výpočtu 6místné hodnoty HOTP

Tento příklad [1] demonstruje činnost algoritmu, který generuje šestimístné číselné heslo ze 160bitového ověřovacího kódu. Nechte v určitém kroku hodnotu řetězce od $hmac\_result[0]..hmac\_result[19]$ $HMAC-SHA-1$

int offset = hmac_result[19] & 0xf; int bin_code = (hmac_result[offset] & 0x7f) << 24 | (hmac_result[offset+1] & 0xff) << 16 | (hmac_result[offset+2] & 0xff) << 8 | (hmac_result[offset+3] & 0xff);

Výsledek pak bude vypadat takto:

Bajtový index	0	jeden	2	3	čtyři	5	6	7	osm	9	deset	jedenáct	12	13	čtrnáct	patnáct	16	17	osmnáct	19
Význam	lf	86	98	69	0e	02	ca	16	61	85	padesáti	ef	7f	19	da	8e	94	5b	55	5a

Poslední bajt je 0x5a
Hodnota posunu získaná z nižších 4 bitů je 0xa, což nám dává číslo 10
Hodnota 4 po sobě jdoucích bytů počínaje 10. pozicí je 0x50ef7f19, která je převedena na binární kód DBC1 [7] (dynamický binární kód)
MSB přijaté z DBC1 je 0x50. Proto DBC2 [8] = DBC1 = 0x50ef7f19
S binárními hodnotami se dále zachází jako s kladným číslem, zapsaným v pořadí od nejvyšší po nejnižší, přičemž první bajt je maskován hodnotou 0x7f.
Abyste získali šestimístné číslo pro HOTP, musíte vzít číslo získané v předchozím kroku modulo 10 6 - $HOTP=DBC2{\pmod {10^{6))}=872921$

Kontrola jednorázového hesla

Kontrola hodnot počítadla

Když generátor (klient) vytvoří nové jednorázové heslo, hodnota počítadla klienta se zvýší o jedničku. V budoucnu je hodnota čítače přiváděna na vstup hashovací funkce spolu s klíčem . Poté bude odeslána na autentizační server, kde bude porovnána s hodnotou vypočítanou serverem. Pokud se hodnoty shodují, s přihlédnutím k rozdílu ne více než parametru desynchronizace , pak server zvýší hodnotu svého čítače o jednu. Pokud se data neshodují, server zahájí resynchronizaci a v případě selhání ji opakuje, dokud není dosaženo limitu neúspěšných pokusů o autentizaci . Poté server zablokuje uživatelský účet [1] . $C$ $HMAC-SHA-1$ $K$ $C$ $s$ $T$

Nesynchronizováno mezi klientem a serverem

Jak již bylo zmíněno, klient aktualizuje hodnotu čítače událostí při každém vygenerování jednorázového hesla. Hodnota čítače na serveru se zase zvýší až po úspěšné autentizaci. Na základě těchto tvrzení je možné popsat důvody, proč je implementace procesu resynchronizace nezbytná:

Ověření se nezdařilo. Klient po vytvoření hesla aktualizoval hodnotu čítače, ale hodnota na serveru se nezměnila
Komunikační problém. Klient po odeslání hesla zvýšil hodnotu čítače, ale heslo se na server nedostalo

To vede k nutnosti použít parametr out of sync , který bude zodpovědný za velikost okna, ve kterém budou hodnoty čítače klienta a serveru považovány za synchronizované. $s$

Resynchronizace čítače

Resynchronizaci provádí výhradně server. Spočívá ve výpočtu nové hodnoty pro jeho počítadlo událostí tak, aby jeho hodnota odpovídala hodnotě přijaté od klienta v rámci rozdílu mezi hodnotami nejvýše . Pokud je tato podmínka splněna, pak server aktualizuje hodnotu vlastního čítače [1] . $s$

V opačném případě server přepočítá stav počítadla. Během tohoto procesu může server několikrát požádat o další hodnoty OTP. To se provádí za účelem zvýšení úrovně zabezpečení, protože porovnání hesel se v tomto případě provádí pro dva nebo tři páry. Pokud je dosaženo limitu opakování, server uzamkne uživatelský účet. Parametr také definuje okno, ve kterém server zvýší čítač během procesu resynchronizace. Tento limitní parametr slouží k: $s$

Omezení možnosti uhodnutí správného hesla
Zabraňte zacyklení výpočtu hodnoty v rámci jedné kontroly

Zabezpečení

Spolehlivost algoritmu

Bezpečnostní systémy postavené pomocí HOTP mají vysoký stupeň spolehlivosti. Jsou z větší části odolné vůči rozšířeným kryptografickým útokům, například:

Útok typu " muž uprostřed " ( Man-in-the-middle ). Útočník nemůže zfalšovat předávanou zprávu, protože heslo se poměrně často mění. Mnoho metod kryptografické analýzy je v tomto případě málo použitelných. V některých implementacích se počítadlo používané ke generování změn hesla po každém přenosu. Pokud jsou zprávy zašifrovány pomocí dostatečně silné šifry, pak HOTP téměř znemožňuje uhodnutí hesla. [3]

Přehrát útok . Zde úspěch závisí na konfiguraci samotného systému. V případě, kdy je například k udělení přihlašovacích práv uživateli použit ověřovací server, má útočník řadu problémů. Server po každém příjmu zprávy zvýší počítadlo o jednu. Kontrolou tedy neprojde elementární odeslání duplicitní zprávy - zpráva byla vytvořena pomocí jedné hodnoty a kontrola je provedena jinou. [3]

Pokud se klíč skládá z libovolných číslic, pak se pravděpodobnost úspěchu útoku hrubou silou za přítomnosti pokusů o ověření před zablokováním vypočítá podle vzorce . Například při 5 povolených pokusech o zadání šestimístného hesla a platné velikosti okna je šance na úspěch při útoku 0,015 %. $D$ $T$ ${\displaystyle p=sT/10^{D))$ $s=30$

Útočníkovi se často podaří ukrást hashované heslo uživatele z ověřovacího serveru, který se používá k ověřování. Algoritmus vytváření hesla však také používá čítač událostí. Protože počáteční hodnotu čítače volí server, je obvykle náhodná, což ztěžuje hacknutí komunikačního kanálu, i když má útočník sdílené tajemství. [3]

Způsoby zvýšení ochrany

Tyto změny nejsou povinné nebo rozšíření doporučená autory algoritmu. Chcete-li však zvýšit úroveň zabezpečení vlastní implementace, můžete použít následující možnosti [1] :

Zvětšení délky hodnoty HOTP .

Extrahování každé nové postavy z výsledku drasticky snižuje šance na úspěšný útok. Díky tomu si můžete proces práce s hesly zpříjemnit. Například zvyšte počet pokusů o vstup nebo rozšiřte rozsah, ve kterém se porovnávají hodnoty počítadel serveru a klienta. $HMAC-SHA-1$

Alfanumerické hodnoty .

Smyslem této myšlenky je použít pro heslo nejen čísla, ale také znaky AZ. Spíše se bavíme o sadě 32 znaků z alfanumerické sady. Okamžitě vidíte, jak vzrostla úroveň zabezpečení hesel, protože nyní je pravděpodobnost úspěchu hledání hrubou silou u hesel skládajících se ze 6 znaků. $sT/32^{6}$

Resynchronizace založená na čítači .

Pokud podmínky umožňují klientovi zasílat nejen hodnotu HOTP, ale i další data, pak můžete proces resynchronizace učinit mnohem pohodlnějším a bezpečnějším, pokud klient spolu s hodnotou HOTP odešle stav počítadla událostí do server. V tomto případě bude hodnota klientského HOTP fungovat jako falešná vložka pro stav čítače.

Kontrolou hodnot počítadla na pravost a shodu tímto způsobem můžete odmítnout použití parametru desynchronizace, což také zvýší úroveň ochrany algoritmu, protože v aktualizovaném systému je pravděpodobnost úspěchu hrubé síly útok bude pouze . $T/10^{6}$

Aplikace

Sloučení OATH se standardizovaným HOTP neposkytlo žádné vodítko k implementaci algoritmu. Naopak svoboda vývojářů umožňuje nacházet nová řešení, snažící se vyhovět potřebám zákazníka a inovativním způsobem přispět k technologii OTP. [2] [3] [9]

Běžnou implementaci HOTP v Javě lze nalézt v balíčku org.jboss.security.otp, který je součástí standardních knihoven freewarového webového serveru Apache Jboss.

Další implementaci v jazyce Java zajišťuje přímo unie OATH v balíčku org.openauthentication.otp.

Zmínit lze i implementaci – projekt OATH Toolkit, jehož knihovna liboath umožňuje vytvářet hesla v režimu HOTP a TOTP. [deset]

Velké množství zařízení s nízkou inteligencí je speciálně navrženo pro generování hesel nebo přenos dat pomocí HOTP a TOTP (Feitian, SecuTech, SmartDisplayer, Vasco, Yubico, Protectimus [11] ). Algoritmus se také používá v domácích sítích pro ovládání periferií pomocí dálkového ovladače nebo mobilního telefonu. [3]

Požadavky na implementaci algoritmu

Musí být podporována dvoufaktorová autentizace. V tomto případě se předpokládá, že prvním faktorem je generátor jednorázových hesel a druhým je nějaké další tajemství, které je přidáno k jednorázovému heslu [3]
Server musí být chráněn před útoky hrubou silou, to znamená, že uživatelský účet musí být zablokován po určitém počtu neúspěšných pokusů o autentizaci [1]
Musíte použít zabezpečený kanál

Navíc

HOTP je založen na SHA-1 , který již není považován za dostatečně odolný proti kolizím. Algoritmus HOTP však využívá pouze toho, že na jeho základě vypočítané číslo je náhodné, takže přítomnost kolizí přímo neovlivňuje jeho činnost. [2] [9]

Jednosměrná autentizace znamená, že se klient na požádání pokusí navázat spojení. Server poté odešle požadavek zpět klientovi a ověří jeho odpověď na pravost. Modifikace algoritmu OCRA také umožňuje uživateli ověřit server. [čtyři]

Viz také

Časově založený jednorázový algoritmus hesla

Poznámky

↑ 1 2 3 4 5 6 7 8 9 Hoornaert, Frank, Naccache, David, Bellare, Mihir, Ranen, Ohad. HOTP : Algoritmus jednorázového hesla založený na HMAC . tools.ietf.org. Získáno 26. března 2017. Archivováno z originálu dne 6. dubna 2019.
↑ 1 2 3 4 "Algorithm agility and OATH" od Burta Kaliského, RSA Laboratories. 19. května 2005.
↑ 1 2 3 4 5 6 7 „Schéma ověřování uživatele v domácích sítích založené na HOTP“ od Binoda Vaidyi, Jong Hyuka Parka a Joela JPC Rodriguese. 2009
↑ 1 2 3 4 „Přísaha: včera, dnes a zítra“ od Nathana Willise, 15. prosince 2010.
↑ Nathan Schmidt. Nathan Schmidt – Rozdělení: Jednorázová hesla založená na HMAC (anglicky) (stahování) . nathschmidt.net. Získáno 27. března 2017. Archivováno z originálu 3. dubna 2016.
↑ Jednorázová hesla – HOTP a TOTP , blog Aldaris ( 28. února 2014). Archivováno z originálu 11. června 2018. Staženo 22. března 2017.
↑ M. Bellare, R. Canetti a H. Krawczyk. Keyed Hash Functions and Message Authentication // Proceedings of Crypto'96, LNCS Vol. 1109, str. 1-15..
↑ Krawczyk, H., Bellare, M. a R. Canetti. HMAC: Keyed-Hashing pro ověřování zpráv // RFC 2104 . - 1997. - únor.
↑ 1 2 „Attacks on SHA-1“ od Initiative for Open AuTHentication, 2. března 2005.
↑ „Představujeme sadu nástrojů OATH“ od Simona Josefssona, 2011.
↑ Protectimus . Získáno 21. 8. 2015. Archivováno z originálu 20. 4. 2018. (neurčitý)

Odkazy

RFC 4226
Schéma autentizace uživatele v domácích sítích založené na HOTP