OCRA

OCRA ( OATH Challenge-Response Algorithm , RFC 6287. ) (neurčitý) je algoritmus , který kombinuje možnosti autentizace klienta , vzájemné autentizace a podepisování transakcí pomocí jednorázových hesel . Jedná se o modifikaci algoritmu HOTP . Hlavní rozdíl mezi OCRA a HOTP spočívá v tom, že jako vstup používá náhodnou hodnotu přijatou ze serveru, nikoli počítadlo událostí.

Historie

Spolupráce OATH vyvíjí od roku 2004 jednorázové ověřovací algoritmy založené na heslech. Vzhledem k rychlému rozvoji mobilního průmyslu byly tyto algoritmy velmi populární. Koncem roku 2005 vyšel HOTP. Algoritmus HOTP používá pro generování jednorázových hesel časově nezávislý čítač. Tím se zabrání desynchronizaci, když je mezi klientem a serverem velká vzdálenost. [1] [2]

OATH představil algoritmus TOTP v roce 2008, což je modifikace HOTP. [3] TOTP pro autentizaci generuje heslo na základě času, na rozdíl od HOTP, kde bylo heslo vygenerováno na základě čítače. Toto heslo je platné pouze po určitou dobu. Díky tomu je částečně vyřešen problém desynchronizace uzlů umístěných daleko od sebe, přičemž nedochází ke ztrátě komunikace náhodným nebo záměrným resetem čítačů. [čtyři]

Na podzim roku 2010 společnost OATH upravila TOTP zavedením algoritmu OCRA. Jeho hlavní výhodou je skutečnost, že se server může autentizovat. Algoritmus je také schopen vytvořit elektronický digitální podpis a server lze také autentizovat. [jeden]

Obecné schéma

$OCRA=CryptoFunction(K,DataInput)$

Použitá označení: [5]

$CryptoFunction$ je funkce, která provádí výpočty pomocí tajného klíče K a struktury DataInput. Výchozí hodnota je HOTP s šestimístnou hodnotou založenou na SHA-1 (HOTP-SHA1-6). Doporučuje se používat následující kryptografické funkce:
- HOTP-SHA1-4
- HOTP-SHA1-6
- HOTP-SHA1-8
- HOTP-SHA256-6
- HOTP-SHA512-6

$K$ je tajný klíč známý oběma stranám.
$DataInput$ je struktura obsahující soubor různých vstupních dat. Parametry DataInput: $DataInput=(OCRASuite|00|C|Q|P|S|T)$ Označení:
- $00$ - oddělovač.
- $C$ - čítač 8 bajtů dlouhý, musí být synchronizován mezi oběma stranami.
- $Q$ - požadavek o délce 128 bajtů, v případě menší délky musí být doplněn nulami.
- $P$ je hashovací funkce PIN , kterou klient a server znají.
- $S$ — řetězec až 512 bajtů. Popisuje stav relace. Délka je uvedena v OCRASuite.
- $T$ - počet uplynulých časových intervalů od podmíněného referenčního bodu, pro které se bere datum 1. ledna 1970, délka 8 bajtů. Jednotky měření jsou specifikovány v OCRASuite.
- $OCRASuite$ — řetězec obsahující sadu parametrů pro generování odpovědi. Pro obousměrné ověřování a podepisování si klient a server musí vyměnit dva řetězce OCRASuite: jeden pro server a jeden pro klienta. Struktura : , kde: $<Algorithm>:<CryptoFunction>:<DataInput>$
  - ${\algoritmus stylu zobrazení}$ - označuje verzi OCRA. Hodnota: OCRA-v, kde v je číslo verze OCRA (1 nebo 2).
  - $CryptoFunction$ - Určuje funkci, která bude použita k výpočtu hodnoty OCRA.
  - $DataInput$ - odráží seznam platných vstupů pro tento výpočet. $([C]-QFxx-[PH|Snnn|TG])$ — Parametry DataInput pro režim „request-response“. $([C]-QFxx-[PH|TG])$ - Parametry DataInput pro jednoduchý podpis. Volitelné vstupy jsou uvedeny v hranatých závorkách. Každý výpočetní parametr je popsán jedním písmenem (kromě Q) a oddělen pomlčkami.
    - $Q$ - označuje další definici formátu F. Možné hodnoty proměnné F: A - alfanumerické, N - číselné, H - hexadecimální. Možná délka xx je od 04 do 64. Standardně je formát požadavku N08 (číselný, 8 znaků dlouhý).
    - $P$ - označuje následnou definici hashovací funkce (H) aplikované na PIN (SHA1, SHA256 nebo SHA512). Výchozí hodnota je SHA1.
    - $S$ - hovoří o upřesnění délky sezení (nnn). Výchozí hodnota je 064.
    - $T$ — označení časového kroku G. ([1-59]S — počet sekund, [1-59]M — počet minut, [0-48]H — počet hodin).

Typické režimy provozu

Jednosměrná autentizace

V tomto režimu musí server odeslat náhodný požadavek klientovi, který zase musí poskytnout platnou odpověď, aby mohl být ověřen. Obě strany se musí předem dohodnout na tajném klíči K. [4] [5]

V tomto případě by měly být použity následující parametry: [5]

C - čítač, volitelný parametr.
Q — požadavek, požadovaný parametr, generovaný serverem.
P je hashovací funkce PIN kódu, volitelný parametr.
S — stav relace, volitelný parametr.
T - časový krok, volitelný parametr.

Algoritmus akce: [5]

Server odešle klientovi Q požadavek.
Klient vytvoří R = OCRA(K, {[C] | Q | [P | S | T]}) a odešle odpověď R na server.
Server zkontroluje odpověď R. Pokud je odpověď správná, odešle klientovi OK, v opačném případě NOK.

Vzájemná autentizace

V tomto režimu se klient a server vzájemně ověřují. Klient odešle náhodný požadavek na server, který vygeneruje odpověď a odešle ji klientovi spolu se svým požadavkem. Klient nejprve zkontroluje odpověď serveru, aby se ujistil, že je správná. Poté klient vytvoří svou odpověď a odešle ji na server. Server zkontroluje odpověď klienta a tím dokončí proces vzájemné autentizace. Obě strany se musí předem dohodnout na tajném klíči K. [4] [5]

Parametry serveru pro odpověď: [5]

C - čítač, volitelný parametr.
QC - požadavek, povinný parametr, generovaný klientem.
QS - požadavek, povinný parametr, generovaný serverem.
S — stav relace, volitelný parametr.
T - časový krok, volitelný parametr.

Klientské možnosti odpovědi: [5]

C - čítač, volitelný parametr.
QS - požadavek, povinný parametr, generovaný serverem.
QC - požadavek, povinný parametr, generovaný klientem.
P je hashovací funkce PIN kódu, volitelný parametr.
S — stav relace, volitelný parametr.
T - časový krok, volitelný parametr.

Algoritmus akce: [5]

Klient odešle na server požadavek kontroly kvality.
Server vygeneruje RS = OCRA(K, [C] | QC | QS | [S | T]). Odešle RS a jeho QS požadavek klientovi.
Klient zkontroluje odpověď serveru a vypočítá svou vlastní odpověď RC = OCRA(K, [C] | QS | QC | [P | S | T]). Odesílá na RC server.
Server zkontroluje odpověď klienta a pokud je úspěšná, odešle potvrzení o ověření.

Jednoduchý podpis

Server musí klientovi poslat nějakou hodnotu k podpisu. Touto hodnotou může být například informace, která má být podepsána, nebo hashovací funkce z této informace. Obě strany se musí předem dohodnout na tajném klíči K. [5]

Používají se následující parametry: [5]

C - čítač, volitelný parametr.
QS - požadavek na podpis, povinný parametr, generovaný serverem.
P je hashovací funkce PIN kódu, volitelný parametr.
T - časový krok, volitelný parametr.

Algoritmus akce: [5]

Server odešle klientovi požadavek Q na podpis.
Klient vygeneruje SIGN = OCRA(K, [C] | QS | [P | T]) a odešle na server odpověď SIGN.
Server zkontroluje odpověď R. Pokud je odpověď správná, odešle klientovi OK.

Ověřovací podpis serveru

V tomto případě klient nejprve zkontroluje pravost serveru a teprve poté vypočítá a odešle elektronický podpis. Klient nejprve odešle serveru náhodnou hodnotu jako požadavek, načež server klientovi odešle odpověď na jeho požadavek a informaci k podpisu. Obě strany se musí předem dohodnout na tajném klíči K. [5]

Parametry serveru pro odpověď: [5]

C - čítač, volitelný parametr.
QC - požadavek, povinný parametr, generovaný klientem.
QS - požadavek na podpis, povinný parametr, generovaný serverem.
T - časový krok, volitelný parametr.

Klientské možnosti odpovědi: [5]

C - čítač, volitelný parametr.
QC - požadavek, povinný parametr, generovaný klientem.
QS - požadavek na podpis, povinný parametr, generovaný serverem.
P je hashovací funkce PIN kódu, volitelný parametr.
T - časový krok, volitelný parametr.

Algoritmus akce: [5]

Klient odešle na server požadavek kontroly kvality.
Server vygeneruje RS = OCRA(K, [C] | QC | QS | [T]). Odešle RS a jeho požadavek QS klientovi k podpisu.
Klient zkontroluje odpověď serveru a vypočítá svou vlastní odpověď SIGN = OCRA(K, [C] | QS | QC | [P | T]). Odešle SIGN na server.
Server zkontroluje odpověď klienta a pokud je úspěšná, odešle potvrzení OK.

Požadavky na implementaci

Algoritmus musí podporovat ověřování typu výzva-odpověď.
Algoritmus musí podporovat algoritmus podpisu symetrického klíče.
Algoritmus musí podporovat ověřování serveru.
Jako šifrovací funkci se doporučuje používat HOTP.
Doporučuje se, aby délka a formát vstupního požadavku byly konfigurovatelné.
Doporučuje se, aby délka a formát výstupní odpovědi byly konfigurovatelné.
Požadavek lze implementovat s kontrolou integrity, například paritní bity lze použít pro jednoduché kontroly chyb.
Klíč musí být jedinečný pro každý generátor a klíč musí být náhodné číslo.
Algoritmus může zahrnovat další datové atributy, jako jsou časové informace nebo číslo relace, které mají být zahrnuty do výpočtu. Tyto vstupy lze použít jednotlivě nebo všechny dohromady. [5]

Spolehlivost algoritmu

Autentizační systémy založené na jednorázových heslech jsou poměrně spolehlivé. OCRA má zároveň řadu výhod oproti svým předchůdcům, algoritmům TOTP a HOTP. [čtyři]

Jednou ze závažných metod útoku je spoofing autentizačního serveru, který může být účinný při útocích na TOTP a HOTP. V tomto případě útočník obdrží data od uživatele a může je použít ke komunikaci se serverem. V případě algoritmu OCRA, který pracuje podle metody „request-response“, však musí útočník fungovat jako prostředník mezi uživatelem a serverem. Útočník bude také muset nahradit adresu klienta, aby mohl přijímat data ze serveru a používat je ke komunikaci s klientem. [čtyři]

Algoritmus OCRA lze také implementovat tak, aby byl odolný vůči útoku na základě desynchronizace časovače nebo čítače, které podléhají HOTP a TOTP, protože tyto parametry lze v OCRA kombinovat. Když je zaveden čítač, odeslání opakované zprávy útočníkem pomocí metody Man-in-the-middle selže , protože čítač na straně serveru (nebo klienta, v závislosti na tom, koho se útočník snaží napodobit) se změní a zpráva bude zkontrolována již nikoli hodnota, se kterou byla vytvořena. Je také možné změnit dobu, po kterou je heslo platné, v závislosti na vzdálenosti mezi klientem a serverem, čímž se zabrání desynchronizaci. [čtyři]

Srovnání s vrstevníky

Hlavními konkurenty OCRA mezi algoritmy pracujícími na metodě „request-response“ jsou SCRAM a CHAP . Oproti nim má OCRA výhody i nevýhody. Všechny tři algoritmy podporují vzájemnou autentizaci, ale CHAP nebyl původně navržen jako důležitá součást algoritmu. Také v CHAP je každý přenos dat prováděn jako paket, který označuje účel tohoto paketu, jeho délku atd. To zvyšuje množství přenášených dat a může degradovat algoritmus na pomalém připojení. Tato forma zpráv však umožňuje provádět některé další operace, například změnit tajné slovo uložené serverem i klientem. OCRA tuto funkci nemá, algoritmus nepodporuje možnost změny tajemství. Ve SCRAM mají server a klient klíčová pole chráněná saltem . To vám umožní změnit klíč při každé nové autentizační relaci. SCRAM má také schopnost detekovat útok pomocí metody „man in the middle“. Po úspěšné detekci takového útoku je komunikace mezi klientem a serverem zastavena. OCRA a SCRAM, na rozdíl od CHAP, používají náhodnou hodnotu přijatou ze serveru jako argument kryptografické funkce. OCRA má schopnost vytvořit elektronický podpis, zatímco SCRAM používá podpis k ověření. Server (klient) odešle klientovi (serveru) parametry pro šifrovací funkci a šifrovaný text. Poté klient (server) text dešifruje, podepíše a odešle serveru (klientovi). Když je podpis ověřen, je autentizace považována za prošlou. OCRA má na rozdíl od svých konkurentů možnost používat čítače a časovače jako další ochranu proti hackování. [6] [7]

Poznámky

↑ 12 Nathan Willis, 2010 .
↑ Schéma autentizace uživatele v domácích sítích založené na HOTP, 2009 .
↑ OATH předkládá TOTP: Time-Based One Time Password Specification IETF .
↑ 1 2 3 4 5 6 Koncept jednorázových hesel při budování autentizačního systému, 2006-07, 2006-08 .
↑ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 RFC 6287, 2011 .
↑ RFC 5802, 2010 .
↑ RFC 1994, 1996 .

Zdroje

Nathan Willis. OATH: včera, dnes a zítra (anglicky) // isode.com . - 2010. - 15. prosince.
Joanne Killeen, Madison Alexander. OATH předkládá TOTP: Time-Based One Time Password Specification IETF ( mrtvý odkaz) . Archivováno z originálu 23. ledna 2013.
Davletchanov Marat. Koncept jednorázových hesel při budování autentizačního systému // Byte/Russia : journal. — 2006-07, 2006-08. - č. 7-8 (95) . (Ruština)
Binod Vaidya, Jong Hyuk Park a Joel JPC Rodrigues. Schéma autentizace uživatele v domácích sítích založené na HOTP // Poznámky k přednáškám z informatiky [ . - 2009. - Ne. 5576 . - S. 672-681 . Archivováno z originálu 4. března 2016.
RFC 6287 . - 2011. - ISSN 2070-1721 .
RFC 5802 . - 2010. - ISSN 2070-1721 .
RFC 1994 . — 1996.