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]

Общая схема

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

  • — функция, выполняющая вычисления, используя секретный ключ K и структуру DataInput.
    По умолчанию используется HOTP с шестизначным значением на базе SHA-1 (HOTP-SHA1-6).
    Рекомендуется использовать следующие криптофункции:
    • HOTP-SHA1-4
    • HOTP-SHA1-6
    • HOTP-SHA1-8
    • HOTP-SHA256-6
    • HOTP-SHA512-6
  • — секретный ключ, известный обоим сторонам.
  • — структура, содержащая набор различных входных данных.
    Параметры DataInput:
    Обозначения:
    • — разделитель.
    • — счетчик длиной в 8 байт, должен быть синхронизирован между обоими сторонами.
    • — запрос длиной в 128 байт, в случае меньшей длины его нужно дополнить нулями.
    • — это хэш-функция от PIN-кода, который знают клиент и сервер.
    • — строка до 512 байт. Описывает состояние сессии. Длина указана в OCRASuite.
    • — количество прошедших промежутков времени от условной точки отсчета, за которую принята дата 1 января 1970 года, длина 8 байт. Единицы измерения указаны в OCRASuite.
    • - строка, содержащая набор параметров для формирования ответа. Для двусторонней аутентификации и подписи клиент и сервер должны обменяться двумя строками OCRASuite: одна для сервера, другая клиента.
      Структура : , где:
      • — указывает версию OCRA. Значение: OCRA-v, где v - это номер версии OCRA (1 или 2).
      • — указывает функцию, которая будет использоваться для вычисления значения OCRA.
      • — отражает список допустимых входов для данного вычисления.
        — параметры DataInput для режима “запрос-ответ”.
        — параметры DataInput для простой подписи.
        В квадратных скобках даны необязательные входы.
        Каждый параметр вычислений описывается одной буквой (кроме Q) и отделяется дефисами.
        • — указывает на дальнейшее определение формата F. Возможные значения переменной F: A — буквенно-цифровой, N — числовой, H — шестнадцатеричный. Возможная длина xx — от 04 до 64. По умолчанию формат запроса имеет значение N08 (цифровой, длиной в 8 символов).
        • — указывает на последующее определение хэш-функции (H), применяемой к PIN-коду (SHA1, SHA256 или SHA512). По умолчанию SHA1.
        • — говорит об указании длины сессии (nnn). По умолчанию 064.
        • — указание шага времени G. ([1-59]S - количество секунд, [1-59]M - количество минут, [0-48]H - количество часов).

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

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

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

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

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

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

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

Взаимная аутентификация

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. Клиент отправляет серверу запрос QC.
  2. Сервер формирует RS = OCRA(K, [C] | QC | QS | [T]). Отправляет клиенту RS и свой запрос QS на подпись.
  3. Клиент проверяет ответ сервера и вычисляет свой ответ SIGN = OCRA( K, [C] | QS | QC | [P | T]). Посылает серверу SIGN.
  4. Сервер проверяет ответ клиента и в случае успеха отправляет подтверждение аутентификации 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-12-15.
  • Joann Killeen, Madison Alexander. OATH Submits TOTP: Time-Based One Time Password Specification to IETF (англ.). Архивировано из первоисточника 24 января 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. — № 5576. — С. 672-681.
  • RFC 6287 (англ.). — 2011. — 2070-1721.
  • RFC 5802 (англ.). — 2010. — 2070-1721.
  • RFC 1994 (англ.). — 1996.

OCRA.

© 2016–2023 mk-hram.ru, Россия, Барнаул, ул. Школьная 34, +7 (3852) 17-07-29