HOTP

Материал из Power Security Support Wiki
Перейти к: навигация, поиск

HOTP: общее описание

HOTPOATH-алгоритм генерации одноразовых паролей по событию (event-base) описан как RFC 4226. Как сказано выше в качестве параметра, отвечающего за динамику, используется событие, то есть сам факт генерации одноразового пароля: каждый раз при нажатии на кнопку генерации, счетчик событий увеличивает свое значение на единицу и именно это динамическое значение используется как основной параметр при расчете одноразового пароля.

Вторым параметром, используемым при расчете одноразовых паролей, является симметричный ключ (symmetric key), который должен быть уникальным для каждого генератора и существует требование на его минимальную длину – 128 бит. Канонически, именно это значение определяет уникальность генератора одноразовых паролей. При этом стоит отметить, что дополнительный уровень энтропии вносится за счет случайного значения начального состояния счётчика событий, который вместе с симметричным ключом «прошивается» в генератор и записывается в конфигурационный файл (по OATH-рекомендациям это должен быть формат PSKC, описанный в RFC 6030).

О чем думали создатели алгоритма

Основной задачей стандартизации алгоритма является повышение его применимости, и здесь речь идет не столько о совместимости серверов аутентификации (проверки) и генераторов одноразовых паролей разных производителей, сколько заостряется внимание на простоте использования конечным пользователем и простоте реализации (дешевизне, низкой себестоимости аутентификатора — генератора одноразовых паролей). Это выражается в минимизации пользовательского интерфейса (чем меньше пользователь принимает участие в процессе, тем лучше) и возможности реализовать алгоритм, например, в SIM-карте (при этом возможность реализации на Java-карте являлось фундаментальным требованием)

Детализированные требования можно прочитать в RFC 4226, здесь же приведем их короткие трактовки:

  1. В основе алгоритма должна быть последовательность, то есть он должен основываться на счетчике событий
  2. Должен быть экономичным с точки зрения вычислительных мощностей, энергопотребления, интерфейса взаимодействия с пользователем (минимизация количества кнопок и пр.)
  3. Не должен требовать ввода каких-либо значений
  4. Простота восприятия пользователем: значение должно быть числовым с длиной минимум 6 цифр
  5. Простота ре-синхронизации счетчика событий
  6. Должен использовать надёжный общий секрет (shared secret) длина которого должна быть не менее 128 бит, а рекомендованная длина — 160 бит


Проверка одноразового пароля и прочие радости

Проверка

Генератор (клиент, в OATH-терминологии) увеличивает значение своего счетчика на единицу каждый раз, когда инициируется генерация одноразового пароля (при нажатии на копку). Это инкрементированное значение и подаётся на вход HMAC-SHA1 симметричным ключом (секретным значением, как мы помним, уникальным для каждого генератора). Это значение передается на сервер аутентификации (сервер проверки, в OATH-терминологии) и сравнивается со значением рассчитанным сервером. Если значения совпали, то сервер увеличивает значение счетчика данного генератора на единицу. Если значения, полученные и рассчитанные сервером не совпали, сервер инициирует процесс ресинхронизации (в пределах допустимого окна рассинхронизации — параметр s). Если процесс ресинхронизации не удался, сервер инициирует запрос другого значения одноразового пароля. Ситуация повторяется до тех пор, пока не будет достигнуто максимальное число попыток аутентификации (что должно влечь блокировку учётной записи пользователя)

Рассинхронизация счетчика

OATH-HOTP — синхронный алгоритм, работающий по счетчику событий, что означает необходимость синхронности значений счетчика событий, используемого генератором (клиентом) и сервером в процессе расчета и проверки одноразового пароля. Как сказано выше инкремент счетчика генератора выполняется каждый раз, когда выполняется генерация одноразового пароля. В то же время инкремент счетчика на сервере выполняется только в случае успешной аутентификации. Исходя из этого можно выделить несколько наиболее вероятных причин ресинхронизации:

  1. Аутентификация не пройдена. Генератор инкрементировал свой счётчик, а сервер нет.
  2. Проблема связи. Генератор инкрементировал свой счётчик, а север не получил одноразовый пароль. В этом случае при невнятном сообщении об ошибке пользователь с высокой вероятностью выполнит повторную генерацию одноразового пароля.
  3. Элементарное баловство :)

Ресинхронизация счетчика

Ресинхронизация выполняется расчетом следующего HOTP-значения и сравнением с полученным от клиента (генератора). Это повторяется в переделах заданного окна ресинхронизации s. Дополнительно в процессе ресинхронизации сервер может запросить дополнительные значения одноразовых паролей (2 или 3). Это сделано для повышения безопасности, так как сравнения в этом случае выполняется для двух или трех пар, и все они должны пройти успешно. Параметр s — определяет окно, в пределах которого сервер увеличивать счетчик в процессе ресинхронизации.

Это ограничение вводится по двум причинам:

  1. ограничить вероятность подбора одноразового значения (см ниже расчет вероятности)
  2. предотвратить бесконечный расчет в рамках одной проверки и как следствие отказ в обслуживании


Математическая подоплека

Общее

В основе генерации одноразовых паролей лежит HMAC-функция, на вход которой подается два значения: симметричный ключ и текущее состояние счетчика. Отсюда, кстати, и название алгоритма HOTP — HMAC-Based One-Time Password. В качестве основы HMAC взят алгоритм SHA-1 (RFC 3174), то есть речь идет о HMAC-SHA-1 (RFC 2104) с длиной результата 160 бит.

Так как конечный пользователь будет испытывать катастрофические затруднения при наборе одноразового пароля длиной 160 бит, алгоритм предусматривает обрезку оригинального результата (160 бит) до приемлемой длины: одноразовый пароль имеет формат цифрового значения с длиной не менее 6 символов (цифр). Таким образом, функция генерации одноразового пароля по событию записывается следующим образом:


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


где:

К — симметричный ключ

С — текущее состояние счетчика

T — количество неверных аутентификаций, после которых сервер заблокирует учетную запись пользователя

s — параметр рассинхронизации, определяет максимальное расхождение между счетчиком сервера и генератора (клиента в OATH-терминологии), при котором одноразовый пароль будет принят.

Digit — количество цифр в значении одноразового пароля

Truncate — функция обрезки, позволяющая преобразовать 160-битное значение функции HMAC-SHA-1, в упомянутый выше юзер-френдли числовой формат (с длиной 6 или более символов)


Как работает Truncate (обрезка)

Результат HMAC-SHA-1 (RFC 2104)— 160 бит или строка, состоящая из 20 байт, на основе чего генерируется строка в 4 байта. Это происходит следующим образом:

20-байтная строка представляется как 20 блоков по 8 бит, 4 младших бита последней 20-ой 8-битной последовательности определяют смещение (понятно, что это значение находится в диапазоне от 0 до 15). Далее выполняется конкатенация (склеивание) 4 последовательностей, первая из которых является строковым предобразованием вычисленного смещения, а вторая — преобразованием от смещения увеличенного на единицу и т.д. последние 31 бита этой склейки и будут теми 4 байтами.

Далее 4 байта представляются как десятичное число, которое делится по модулю на 10^Digit. Результат и есть одноразовый пароль


Аспекты безопасности

Надежность алгоритма

Анализ используемой математической базы, в частности используемые алгоритмы HMAC-SHA-1 и дальнейшие преобразования 160-битного результата до 6-8 цифрового значения, показал что наиболее вероятной атакой на HOTP будет атака методом прямого перебора (brute-force attack). Легко понять, что вероятность прохождения аутентификации будет считаться по формуле:

Sec = sT/10^Digit

где:

Sec — рассчитываемая вероятность

s — окно допустимой расссинхронизации счетчиков на сервере и клиенте (генераторе)

T — количество попыток пройти аутентификации, при достижении которого учетная запись пользователя блокируется

Digit — количество цифр в одноразовом пароле.

Например, при 5 разрешенных попытках, окне допустимом окне рассинхронизации равном 30 и 6-цифровом одноразовом пароле, вероятность подобрать пароль составит и пройти аутентификацию составит: 0.015%

Требования

  1. Необходимо поддерживать двухфакторную аутентификацию. В данном случае подразумевается, что первым фактором является генератор одноразовых паролей (программный или аппаратный), вторым - некоторый дополнительный секрет, который добавляется к одноразовому паролю.
  2. Сервер должен быть защищен от атак методом прямого перебора (brute-force attack), то есть учетная запись пользователя (в общем случае) должна блокироваться после определенного числа неуспешных попыток аутентификации
  3. Необходимо использовать защищенный канал