OCRA — различия между версиями
Andrey (обсуждение | вклад) (Новая страница: «==Основное== ORCA (OATH Challenge-Response Algorithm) это развитие алгоритма HOTP. В общих чертах – это алго…») |
(→DataInput) |
||
| (не показано 11 промежуточных версий 2 участников) | |||
| Строка 1: | Строка 1: | ||
==Основное== | ==Основное== | ||
| − | + | ||
| − | В дополнение аутентификации клиента здесь добавлены такие возможности как взаимная аутентификация, подпись транзакций | + | OCRA (OATH Challenge-Response Algorithm, стандартизован как RFC 6287) это развитие алгоритма [[HOTP]]. В общих чертах – это алгоритм генерации одноразового значения на основании случайного значения (запроса), то есть вместо счетчика событий на вход подается случайное значение, полученное с сервера. |
| + | В дополнение аутентификации клиента здесь добавлены такие возможности как взаимная аутентификация, подпись транзакций | ||
== Требования, предъявляемые к реализации== | == Требования, предъявляемые к реализации== | ||
| + | |||
# Алгоритм должен поддерживать аутентификацию на основе запрос-ответ (что собственно и является основной целью данного алгоритма) | # Алгоритм должен поддерживать аутентификацию на основе запрос-ответ (что собственно и является основной целью данного алгоритма) | ||
# Алгоритм должен поддерживать подпись данных на основе симметричного ключа | # Алгоритм должен поддерживать подпись данных на основе симметричного ключа | ||
| Строка 11: | Строка 13: | ||
# Запрос может генерироваться с проверкой целостности, с вставкой контрольного бита. Это позволит убедиться в том, что запрос введен верно | # Запрос может генерироваться с проверкой целостности, с вставкой контрольного бита. Это позволит убедиться в том, что запрос введен верно | ||
# Каждый токен (генератор) программный или аппаратный должен иметь уникальный секрет (ключ), значение которого генерируется случайным образом или рассчитывается по специальным алгоритма генерации колючей. | # Каждый токен (генератор) программный или аппаратный должен иметь уникальный секрет (ключ), значение которого генерируется случайным образом или рассчитывается по специальным алгоритма генерации колючей. | ||
| − | # Алгоритм может поддерживать дополнительные атрибуты, такие штамп времени или информация о сессии. | + | # Алгоритм может поддерживать дополнительные атрибуты, такие как штамп времени или информация о сессии. |
==Математика процесса== | ==Математика процесса== | ||
| Строка 19: | Строка 21: | ||
где, | где, | ||
| + | |||
К — общий секрет | К — общий секрет | ||
| + | |||
DataInput — структура данных, названная выше случайным значением | DataInput — структура данных, названная выше случайным значением | ||
| + | |||
CryptoFunction — функция расчета | CryptoFunction — функция расчета | ||
| Строка 29: | Строка 34: | ||
где, | где, | ||
00 – разделитель | 00 – разделитель | ||
| − | С – беззнаковый 8-байтный счетчик, | + | |
| + | С – беззнаковый 8-байтный счетчик, синхронизированный между обоими участниками (клиент и сервер). Опциональный параметр | ||
| + | |||
Q – 128-байтный запрос, если он короче, то значение дополняется нулями | Q – 128-байтный запрос, если он короче, то значение дополняется нулями | ||
| − | P – хэш-функция (поддерживается SHA-1 RFC 3174, SHA-256 и SHA-512 | + | |
| − | S – строка, длиной до 512 байт, описывающая параметры | + | P – хэш-функция (поддерживается SHA-1 RFC 3174, SHA-256 и SHA-512) от [[PIN]]-кода, который известен обеим сторонам (клиент и сервер) |
| + | |||
| + | S – строка, длиной до 512 байт, описывающая параметры сессии | ||
| + | |||
T – 8-байтное значение временных интервалов (секунд, минут, часов, дней – зависит от конкретной реализации), прошедших с 1 января 1 1970 (UT), используется для простановки штампа времени | T – 8-байтное значение временных интервалов (секунд, минут, часов, дней – зависит от конкретной реализации), прошедших с 1 января 1 1970 (UT), используется для простановки штампа времени | ||
| − | При расчете значения, состояние счетчика (С) на стороне клиента всегда увеличивается на 1, а на стороне сервера только в случае успешного прохождения аутентификации (подтверждения транзакции) | + | При расчете значения, состояние счетчика (С) на стороне клиента всегда увеличивается на 1, а на стороне сервера только в случае успешного прохождения аутентификации (подтверждения транзакции) |
=== CryptoFunction=== | === CryptoFunction=== | ||
| Строка 41: | Строка 51: | ||
Рассматривается семейство [[HOTP]]-функций, как расширение [[HOTP]]: | Рассматривается семейство [[HOTP]]-функций, как расширение [[HOTP]]: | ||
# HOTP-H-t , где варьируются H – алгоритм хэш-функции, t – длина значения, то есть обрезки | # HOTP-H-t , где варьируются H – алгоритм хэш-функции, t – длина значения, то есть обрезки | ||
| − | # HOTP-H-t, если t=0, то обрезка не выполняется и в качестве значения используется полное значение | + | # HOTP-H-t, если t=0, то обрезка не выполняется и в качестве значения используется полное значение хэш-функции. |
Рекомендуемые варианты: | Рекомендуемые варианты: | ||
# HOTP-SHA1-4 | # HOTP-SHA1-4 | ||
| Строка 48: | Строка 58: | ||
# HOTP-SHA256-6 | # HOTP-SHA256-6 | ||
# HOTP-SHA512-6 | # HOTP-SHA512-6 | ||
| + | |||
| + | ===OCRASuite=== | ||
| + | |||
| + | Это текстовая строка, представленная в виде: | ||
| + | <Algorithm>:<CryptoFunction>:<DataInput> | ||
Текущая версия на 09:29, 25 июля 2013
Содержание
Основное
OCRA (OATH Challenge-Response Algorithm, стандартизован как RFC 6287) это развитие алгоритма HOTP. В общих чертах – это алгоритм генерации одноразового значения на основании случайного значения (запроса), то есть вместо счетчика событий на вход подается случайное значение, полученное с сервера. В дополнение аутентификации клиента здесь добавлены такие возможности как взаимная аутентификация, подпись транзакций
Требования, предъявляемые к реализации
- Алгоритм должен поддерживать аутентификацию на основе запрос-ответ (что собственно и является основной целью данного алгоритма)
- Алгоритм должен поддерживать подпись данных на основе симметричного ключа
- Алгоритм должен поддерживать аутентификацию сервера, для возможности подтвердить, что клиент взаимодействует с доверенным сервером
- Длина и формат запроса должны быть настраиваемыми
- Длина и формат ответа должны быть настраиваемыми
- Запрос может генерироваться с проверкой целостности, с вставкой контрольного бита. Это позволит убедиться в том, что запрос введен верно
- Каждый токен (генератор) программный или аппаратный должен иметь уникальный секрет (ключ), значение которого генерируется случайным образом или рассчитывается по специальным алгоритма генерации колючей.
- Алгоритм может поддерживать дополнительные атрибуты, такие как штамп времени или информация о сессии.
Математика процесса
Если описывать алгоритм, то можно использовать следующее представление:
OCRA = CryptoFunction(K, DataInput)
где,
К — общий секрет
DataInput — структура данных, названная выше случайным значением
CryptoFunction — функция расчета
DataInput
DataInput = {OCRASuite | 00 | C | Q | P | S | T}
где, 00 – разделитель
С – беззнаковый 8-байтный счетчик, синхронизированный между обоими участниками (клиент и сервер). Опциональный параметр
Q – 128-байтный запрос, если он короче, то значение дополняется нулями
P – хэш-функция (поддерживается SHA-1 RFC 3174, SHA-256 и SHA-512) от PIN-кода, который известен обеим сторонам (клиент и сервер)
S – строка, длиной до 512 байт, описывающая параметры сессии
T – 8-байтное значение временных интервалов (секунд, минут, часов, дней – зависит от конкретной реализации), прошедших с 1 января 1 1970 (UT), используется для простановки штампа времени
При расчете значения, состояние счетчика (С) на стороне клиента всегда увеличивается на 1, а на стороне сервера только в случае успешного прохождения аутентификации (подтверждения транзакции)
CryptoFunction
По умолчанию, в качестве функции используется HOTP-SHA1-6, то есть алгоритм HOTP на базе SHA1 c длиной значения 6 цифр. Рассматривается семейство HOTP-функций, как расширение HOTP:
- HOTP-H-t , где варьируются H – алгоритм хэш-функции, t – длина значения, то есть обрезки
- HOTP-H-t, если t=0, то обрезка не выполняется и в качестве значения используется полное значение хэш-функции.
Рекомендуемые варианты:
- HOTP-SHA1-4
- HOTP-SHA1-6
- HOTP-SHA1-8
- HOTP-SHA256-6
- HOTP-SHA512-6
OCRASuite
Это текстовая строка, представленная в виде: <Algorithm>:<CryptoFunction>:<DataInput>
