OCRA

OCRA (OATH Challenge-Response Algorithm, RFC 6287 (неопр.).) — алгоритм, объединяющий в себе возможности аутентификации клиента, взаимной аутентификации и подписи транзакций, использующий одноразовые пароли. Является модификацией алгоритма HOTP. Основным отличием OCRA от HOTP является то, что в качестве входных данных используется случайное значение, принятое от сервера, а не счётчик событий.

ИсторияПравить

Сотрудничество OATH разрабатывало алгоритмы аутентификации на базе одноразовых паролей с 2004 года. Из-за стремительного развития мобильной индустрии эти алгоритмы пользовались большой популярностью. В конце 2005 года был опубликован HOTP. Алгоритм HOTP для создания одноразовых паролей использует счётчик, не зависящий от времени. Это позволяет избежать рассинхронизации при большом расстоянии между клиентом и сервером.^[1]^[2]

OATH в 2008 году представила алгоритм TOTP, являющийся модификацией HOTP.^[3] TOTP для аутентификации генерирует пароль, зависящий от времени, в отличие от HOTP, где пароль создавался на основе счётчика. Этот пароль действителен лишь в течение некоторого временного промежутка. Благодаря этому частично решается проблема рассинхронизации узлов, находящихся далеко друг от друга, при этом нет потери связи из-за случайного или предумышленного сброса счётчиков.^[4]

Осенью 2010 года OATH модифицировала TOTP, представив алгоритм OCRA. Основное его преимущество даёт тот факт, что есть возможность прохождения аутентификации сервером. Алгоритм также способен создавать электронную цифровую подпись, причём сервер также можно аутентифицировать.^[1]

Общая схемаПравить

$\text{[math]}$ $\text{[math]}$ $OCRA=CryptoFunction(K,DataInput)$

Использованы обозначения:^[5]

C r y p t o F u n c t i o n — функция, выполняющая вычисления, используя секретный ключ K и структуру DataInput.
По умолчанию используется HOTP с шестизначным значением на базе SHA-1 (HOTP-SHA1-6).

Рекомендуется использовать следующие криптофункции:
- HOTP-SHA1-4
- HOTP-SHA1-6
- HOTP-SHA1-8
- HOTP-SHA256-6
- HOTP-SHA512-6

$\text{[math]}$ $\text{[math]}$ $K$ — секретный ключ, известный обеим сторонам.
D a t a I n p u t — структура, содержащая набор различных входных данных.
Параметры DataInput:

$\text{[math]}$ $\text{[math]}$ $DataInput=(OCRASuite|00|C|Q|P|S|T)$

Обозначения:
- $\text{[math]}$ $\text{[math]}$ $00$ — разделитель.
- $\text{[math]}$ $\text{[math]}$ $C$ — счётчик длиной в 8 байт, должен быть синхронизирован между обеими сторонами.
- $\text{[math]}$ $\text{[math]}$ $Q$ — запрос длиной в 128 байт, в случае меньшей длины его нужно дополнить нулями.
- $\text{[math]}$ $\text{[math]}$ $P$ — это хеш-функция от PIN-кода, который знают клиент и сервер.
- $\text{[math]}$ $\text{[math]}$ $S$ — строка до 512 байт. Описывает состояние сессии. Длина указана в OCRASuite.
- $\text{[math]}$ $\text{[math]}$ $T$ — количество прошедших промежутков времени от условной точки отсчёта, за которую принята дата 1 января 1970 года, длина 8 байт. Единицы измерения указаны в OCRASuite.
- O C R A S u i t e — строка, содержащая набор параметров для формирования ответа. Для двусторонней аутентификации и подписи клиент и сервер должны обменяться двумя строками OCRASuite: одна для сервера, другая клиента.
  Структура : $\text{[math]}$ $\text{[math]}$ $<Algorithm>:<CryptoFunction>:<DataInput>$ , где:
  - $\text{[math]}$ $\text{[math]}$ $A l g o r i t h m$ — указывает версию OCRA. Значение: OCRA-v, где v — это номер версии OCRA (1 или 2).
  - $\text{[math]}$ $\text{[math]}$ $C r y p t o F u n c t i o n$ — указывает функцию, которая будет использоваться для вычисления значения OCRA.
  - D a t a I n p u t   — отражает список допустимых входов для данного вычисления.
    $\text{[math]}$ $\text{[math]}$ $([C]-QFxx-[PH|Snnn|TG])$   — параметры DataInput для режима «запрос-ответ».
    
    $\text{[math]}$ $\text{[math]}$ $([C]-QFxx-[PH|TG])$   — параметры DataInput для простой подписи.
    
    В квадратных скобках даны необязательные входы.
    
    Каждый параметр вычислений описывается одной буквой (кроме Q) и отделяется дефисами.
    - $\text{[math]}$ $\text{[math]}$ $Q$ — указывает на дальнейшее определение формата F. Возможные значения переменной F: A — буквенно-цифровой, N — числовой, H — шестнадцатеричный. Возможная длина xx — от 04 до 64. По умолчанию формат запроса имеет значение N08 (цифровой, длиной в 8 символов).
    - $\text{[math]}$ $\text{[math]}$ $P$ — указывает на последующее определение хеш-функции (H), применяемой к PIN-коду (SHA1, SHA256 или SHA512). По умолчанию SHA1.
    - $\text{[math]}$ $\text{[math]}$ $S$ — говорит об указании длины сессии (nnn). По умолчанию 064.
    - $\text{[math]}$ $\text{[math]}$ $T$ — указание шага времени G. ([1-59]S — количество секунд, [1-59]M — количество минут, [0-48]H — количество часов).

Типичные режимы работыПравить

Односторонняя аутентификацияПравить

В этом режиме сервер должен отправить случайный запрос клиенту, который, в свою очередь, должен предоставить корректный ответ, чтобы пройти аутентификацию. Обе стороны должны заранее согласовать секретный ключ K.^[4] ^[5]

При этом должны использоваться следующие параметры:^[5]

C — счетчик, необязательный параметр.
Q — запрос, обязательный параметр, формируется сервером.
P — хеш-функция от PIN-кода, необязательный параметр.
S — состояние сессии, необязательный параметр.
T — шаг времени, необязательный параметр.

Алгоритм действий:^[5]

Сервер посылает запрос Q клиенту.
Клиент формирует R = OCRA(K, {[C] | Q | [P | S | T]}) и отсылает на сервер ответ R.
Сервер проверяет ответ R. Если ответ корректный, посылает клиенту OK, в противном случае — NOK.

Взаимная аутентификацияПравить

В данном режиме клиент и сервер аутентифицируют друг друга. Клиент посылает случайный запрос серверу, который формирует ответ и отправляет клиенту вместе со своим запросом. Клиент сначала проверяет ответ сервера, чтобы убедиться, что тот корректен. После этого клиент формирует свой ответ и отправляет его серверу. Сервер проверяет ответ клиента и тем самым завершает процесс взаимной аутентификации. Обе стороны должны заранее согласовать секретный ключ K.^[4] ^[5]

Параметры сервера для ответа:^[5]

C — счетчик, необязательный параметр.
QC — запрос, обязательный параметр, формируется клиентом.
QS — запрос, обязательный параметр, формируется сервером.
S — состояние сессии, необязательный параметр.
T — шаг времени, необязательный параметр.

Параметры клиента для ответа:^[5]

C — счетчик, необязательный параметр.
QS — запрос, обязательный параметр, формируется сервером.
QC — запрос, обязательный параметр, формируется клиентом.
P — хеш-функция от PIN-кода, необязательный параметр.
S — состояние сессии, необязательный параметр.
T — шаг времени, необязательный параметр.

Алгоритм действий:^[5]

Клиент отправляет серверу запрос QC.
Сервер формирует RS = OCRA(K, [C] | QC | QS | [S | T]). Отправляет клиенту RS и свой запрос QS.
Клиент проверяет ответ сервера и вычисляет свой ответ RC = OCRA(K, [C] | QS | QC | [P | S | T]). Посылает серверу RC.
Сервер проверяет ответ клиента и в случае успеха отправляет подтверждение аутентификации.

Простая подписьПравить

Сервер должен передать клиенту какое-то значение на подпись. Этим значением может быть, например, информация, которую нужно подписать, или хеш-функция от этой информации. Обе стороны должны заранее согласовать секретный ключ K.^[5]

Используются следующие параметры:^[5]

C — счетчик, необязательный параметр.
QS — запрос на подпись, обязательный параметр, формируется сервером.
P — хеш-функция от PIN-кода, необязательный параметр.
T — шаг времени, необязательный параметр.

Алгоритм действий:^[5]

Сервер посылает запрос Q на подпись клиенту.
Клиент формирует SIGN = OCRA(K, [C] | QS | [P | T]) и отсылает на сервер ответ SIGN.
Сервер проверяет ответ R. Если ответ корректный, посылает клиенту OK.

Подпись с аутентификацией сервераПравить

В этом случае клиент сначала проверяет подлинность сервера, а уже потом вычисляет и отправляет электронную подпись. Клиент сначала отправляет случайное значение в качестве запроса на сервер, после чего сервер посылает клиенту свой ответ на его запрос и информацию на подпись. Обе стороны должны заранее согласовать секретный ключ K.^[5]

Параметры сервера для ответа:^[5]

C — счетчик, необязательный параметр.
QC — запрос, обязательный параметр, формируется клиентом.
QS — запрос на подпись, обязательный параметр, формируется сервером.
T — шаг времени, необязательный параметр.

Параметры клиента для ответа:^[5]

C — счетчик, необязательный параметр.
QC — запрос, обязательный параметр, формируется клиентом.
QS — запрос на подпись, обязательный параметр, формируется сервером.
P — хеш-функция от PIN-кода, необязательный параметр.
T — шаг времени, необязательный параметр.

Алгоритм действий:^[5]

Клиент отправляет серверу запрос QC.
Сервер формирует RS = OCRA(K, [C] | QC | QS | [T]). Отправляет клиенту RS и свой запрос QS на подпись.
Клиент проверяет ответ сервера и вычисляет свой ответ SIGN = OCRA(K, [C] | QS | QC | [P | T]). Посылает серверу SIGN.
Сервер проверяет ответ клиента и в случае успеха отправляет подтверждение аутентификации OK.

Требования к реализацииПравить

Алгоритм должен поддерживать аутентификацию по методу «запрос-ответ».
Алгоритм должен поддерживать алгоритм подписи на основе симметричного ключа.
Алгоритм должен поддерживать аутентификацию сервера.
Рекомендуется использовать в качестве криптофункции HOTP.
Рекомендуется длину и формат входного запроса реализовать конфигурируемыми.
Рекомендуется длину и формат выходного ответа реализовать конфигурируемыми.
Запрос может быть реализован с возможностью проверки целостности, например, можно использовать биты чётности для простых проверок на ошибки.
Ключ должен быть уникальным для каждого генератора, и ключ должен быть случайным числом.
Алгоритм может включать в себя дополнительные атрибуты данных, такие как информация о времени или номере сеанса, которые будут включены в расчёт. Эти данные входы могут использоваться по отдельности или все вместе. ^[5]

Надёжность алгоритмаПравить

Системы аутентификации, построенные на базе одноразовых паролей, являются достаточно надёжными. При этом OCRA обладает рядом преимуществ по сравнению со своими предшественниками, алгоритмами TOTP и HOTP.^[4]

Один из серьёзных методов атаки — подмена сервера аутентификации, что может оказаться эффективным при атаках на TOTP и HOTP. При этом злоумышленник получает данные от пользователя и может использовать их для связи с сервером. Однако в случае алгоритма OCRA, работающего по методу «запрос-ответ», злоумышленник должен выступать в качестве посредника между пользователем и сервером. Злоумышленнику придётся подменять ещё и адрес клиента, чтобы получать данные с сервера и использовать их для связи с клиентом.^[4]

Также алгоритм OCRA может быть реализован устойчивым к атаке, основанной на рассинхронизации таймеров или счётчиков, которой подвержены HOTP и TOTP, так как эти параметры в OCRA можно комбинировать. При введении счётчика отправка повторного сообщения злоумышленником, работающим по методу «человек посередине» (Man-in-the-middle), будет неудачной, так как счётчик на стороне сервера (или клиента, смотря кого пытается сымитировать злоумышленник) изменится и сообщение будет проверяться уже не тем значением, с помощью которого оно создавалось. Можно менять и промежуток времени, в течение которого пароль действителен, в зависимости от расстояния между клиентом и сервером, избегая рассинхронизации.^[4]

Сравнение с аналогамиПравить

Основными конкурентами OCRA среди алгоритмов, работающих по методу «запрос-ответ» являются SCRAM и CHAP. По сравнению с ними, OCRA имеет как преимущества, так и недостатки. Все три алгоритма поддерживают взаимную аутентификацию, но изначально в CHAP эта возможность не задумывалась как важная часть алгоритма. Также в CHAP каждая передача данных осуществляется в виде пакета с указанием предназначения данного пакета, его длины и т. д. Это увеличивает объём пересылаемых данных и может ухудшить работу алгоритма при медленном соединении. Но такая форма сообщений позволяет проводить некоторые дополнительные операции, например, изменение секретного слова, хранящегося и у сервера и у клиента. В OCRA такая возможность отсутствует, алгоритм не поддерживает возможность изменять секрет. В SCRAM у сервера и клиента имеются массивы ключей, защищённые солью. Это позволяет менять ключ при каждом новом сеансе аутентификации. Также в SCRAM есть возможность обнаружения атаки методом «человек посередине». При успешном обнаружении такой атаки связь между клиентом и сервером останавливается. OCRA и SCRAM, в отличие от CHAP, в качестве аргумента криптофункции используют случайное значение, полученное с сервера. OCRA обладает возможностью создания электронной подписи, в то время как в SCRAM с помощью подписи проводится аутентификация. Сервер (клиент) посылает клиенту (серверу) параметры для криптофункции и зашифрованный текст. После этого клиент (сервер) расшифровывает текст, подписывает его и отправляет серверу (клиенту). При подтверждении подлинности подписи аутентификация считается пройденной. OCRA, в отличие от своих конкурентов, обладает возможностью использования счётчиков и таймеров в качестве дополнительной защиты от взлома. ^[6] ^[7]

ПримечанияПравить

ИсточникиПравить

Nathan Willis. OATH: yesterday, today, and tomorrow (англ.) // isode.com. — 2010. — 15 December.
Joann Killeen, Madison Alexander. OATH Submits TOTP: Time-Based One Time Password Specification to IETF (англ.) (недоступная ссылка — история). Архивировано 23 января 2013 года.
Давлетханов Марат. Концепция одноразовых паролей в построении системы аутентификации (рус.) // Byte/Россия : журнал. — 2006-07, 2006-08. — № 7—8 (95).
Binod Vaidya, Jong Hyuk Park, and Joel J.P.C. Rodrigues. HOTP-Based User Authentication Scheme in Home Networks (англ.) // Lecture Notes in Computer Science^[en]. — 2009. — No. 5576. — P. 672—681. Архивировано 4 марта 2016 года.
RFC 6287 (англ.). — 2011. — ISSN 2070-1721.
RFC 5802 (англ.). — 2010. — ISSN 2070-1721.
RFC 1994 (англ.). — 1996.

[_fcc1f93cb702ecdc-1] ¹ ² Nathan Willis, 2010.

[_f934a1e352baff28-2] HOTP-Based User Authentication Scheme in Home Networks, 2009.

[_7a28f4a3ce8b1744-3] OATH Submits TOTP: Time-Based One Time Password Specification to IETF.

[_f18ce9bed15a98b4-4] ¹ ² ³ ⁴ ⁵ ⁶ Концепция одноразовых паролей в построении системы аутентификации, 2006-07, 2006-08.

[_0a03619a0d56cf2f-5] ¹ ² ³ ⁴ ⁵ ⁶ ⁷ ⁸ ⁹ ¹⁰ ¹¹ ¹² ¹³ ¹⁴ ¹⁵ ¹⁶ RFC 6287, 2011.

[_ed7e99062c7a2414-6] RFC 5802, 2010.

[_7b63cc81021f4672-7] RFC 1994, 1996.

[1]

[2]

[3]

[4]

[5]

[6]

[7]