HOTP

HOTP (англ. HMAC-Based One-Time Password Algorithm) — алгоритм захищеної аутентифікації з використанням одноразового пароля (One Time Password, OTP). Заснований на HMAC (SHA-1). Є алгоритмом односторонньої аутентифікації, а саме: сервер виконує аутентифікацію клієнта.

В якості параметра, що відповідає за динаміку генерації паролів, використовується подія, тобто сам факт генерації: кожного разу при створенні нового пароля лічильник подій збільшує своє значення на одиницю, і саме це монотонне зростаюче значення використовується як основний параметр алгоритму. Другим параметром для розрахунку одноразових паролів є симетричний ключ, який повинен бути унікальним для кожного генератора (клієнта) і закритим від усіх, крім сервера і самого генератора (клієнта).

Історія

Алгоритм уперше формально описано командою IETF в грудні 2005. Він став першим реально успішним проектом Initiative for Open Authentication (OATH). Алгоритми генерації одноразових паролів отримали в цей час широку популярність у зв'язку з різким розвитком мобільної індустрії. Був необхідний надійний алгоритм, простий в плані реалізації.

У 2008 році HOTP подарував життя більш сильному алгоритмом Time-based One-time Password Algorithm (TOTP), який багато в чому успадковує риси батьків. У вересні 2010 на основі TOTP був розроблений потужний алгоритм аутентифікації OATH Challenge-Response Algorithm (OCRA).

Алгоритм HOTP також вніс інновації в технологію генерації одноразових паролів. Стійка по тим часам хеш-функція SHA-1 поєднувалася з нетривіальним рішенням наявності лічильника подій. Ці риси підняли HOTP на один рівень з такими перевіреними часом алгоритмами, як S/KEY.

Лічильники в HOTP і TOTP

Основною відмінністю між двома алгоритмами є генерація пароля на основі мітки часу, яку використовують в якості параметра TOTP-алгоритм. При цьому використовується не точне значення часу, а поточний інтервал, межі якого були встановлені заздалегідь (наприклад, 30 секунд)

HOTP генерує ключ на основі розподіленого секрету і не залежного від часу лічильника. Модель цього алгоритму заснована на події — наприклад, кожен раз, коли генерується черговий одноразовий пароль, лічильник буде збільшуватися. Отже, згенеровані згодом паролі повинні бути різними кожен раз.

Завдяки цьому основа для лічильника в HOTP алгоритмі, на відміну від інших алгоритмів, що використовують таймер, захищена від розсинхронізації передавальних пристроїв або занадто великої відстані між ними (такої відстані, що відповідь від отримувача приходить пізніше, ніж закінчиться час валідності пароля). Це дозволяє HOTP-паролям залишатися дійсними протягом необмеженого кількості часу, в той час як TOTP-паролі перестануть бути дійсними через конкретний проміжок часу.

У підсумку, за умови використання тієї ж самої хеш-функції, як і в HOTP, дана відмінність у роботі алгоритму робить TOTP більш безпечним і кращим рішенням для одноразових паролів

Опис алгоритму

Позначення

• ${\displaystyle }$ — Секретний ключ, унікальний для кожного клієнта і відомий тільки йому і серверу. Довжина — 160 біт (рекомендована) або 128 біт (мінімальна)
• ${\displaystyle }$ — Поточний стан 8-байтового лічильника події
• ${\displaystyle }$ — Кількість цифр в генерованому паролі
• ${\displaystyle }$ — Кількість невдалих спроб авторизації, після яких сервер заблокує з'єднання з клієнтом
• ${\displaystyle }$ — Параметр розсинхронізації. Визначає максимальну розбіжність між лічильником сервера і клієнта, при якому одноразовий пароль буде прийнятий.

Загальний опис

Алгоритм повинен повертати не менше 6 цифр для забезпечення достатньої безпеки пароля. Залежно від рівня вимог до захисту, можна використовувати значення для HOTP, що складаються з більшої кількості цифр, для отримання більш стійкого до атак пароля. Роботу алгоритму можна описати наступною формулою:$$HOTP(K,C)=Truncate(HMAC-SHA-1(K,C))$$Процес роботи алгоритму можна розбити на наступні етапи:

1. Створюється строка ${\textstyle HS}$20 байт, застосовуючи хеш-функцію $HMAC-SHA-1$, ініціалізована параметрам $K$и $C$: $HS=HMAC-SHA-1(K,C)$
2. Вибираються певним чином 4 байта з $HS$: $S_{bits}=Truncate(HS)$
   1. Чотири останніх біта останнього байта результату $S_{bits}[19]$ перетворюються в число $offset\in (0,15)$
   2. Послідовність байтів $HS[offset]..HS[offset+3]$ перетворюється в змінну $P$
   3. $Truncate(HS)$ 31 біта $P$Причина, через яку ігнорується старший біт $P$,полягає в різних варіантах реалізації цілочисельних обчислень у різних процесорів
3. Результат роботи $Truncate()$ перетворюється до послідовності з $D$ цифр: $HTOP=toNumber(Truncate(HS))\,\,mod\,10^{D}$

Приклад обчислення 6-значного значення HOTP

Даний приклад демонструє роботу алгоритму, генеруючого шестизначний цифровий пароль з коду аутентифікації розміром в 160 біт. Нехай на певному кроці було обчислено значення рядка ${\displaystyle }$ з ${\displaystyle }$

int offset = hmac_result[19] & 0xf;
int bin_code = (hmac_result[offset] & 0x7f) << 24
           | (hmac_result[offset+1] & 0xff) << 16
           | (hmac_result[offset+2] & 0xff) <<  8
           | (hmac_result[offset+3] & 0xff);

Тоді результат буде виглядати наступним чином:

Індекс байта	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19
Значення	1f	86	98	69	0e	02	ca	16	61	85	50	ef	7f	19	da	8e	94	5b	55	5a

1. Останній байт має значення 0x5a
2. Значення зсуву, отримане з молодших 4 біт — 0xa, це дає нам число 10
3. Значення 4 послідовних байтів, починаючи з 10-ій позиції — 0x50ef7f19, яке перетворюється в двійковий код DBC1 (dynamic binary code)
4. MSB, отримане з DBC1, одно 0x50. Тому DBC2= DBC1 = 0x50ef7f19
5. Далі, двійкові значення розглядаються як позитивне число, записане в порядку від старшого до меншого, у якого перший байт маскується значенням 0x7f.
6. Для того, щоб отримати шестизначне число для HOTP, необхідно взяти число, отримане на попередньому кроці по модулю 10⁶ — ${\displaystyle }$

Перевірка одноразового пароля

Перевірка значень лічильників

При створенні нового одноразового пароля генератором (клієнтом) значення лічильника клієнта збільшується на одиницю. Надалі значення лічильника ${\displaystyle }$ подається на вхід хеш-функції ${\displaystyle }$ разом з ключем ${\displaystyle }$. Після цього ${\displaystyle }$ буде відправлено сервера аутентифікації, де воно буде порівняно зі значенням, обчисленим сервером. Якщо значення збігаються з урахуванням розбіжності не більше параметра розсинхронізації ${\displaystyle }$, то сервер збільшує на одиницю значення свого лічильника. Якщо дані не співпали, то сервер починає ресинхронизацию і повторює її в разі невдачі, поки не буде досягнута межа невдалих спроб аутентифікації ${\displaystyle }$. Після цього сервер блокує обліковий запис користувача.

Розсинхронізація між клієнтом і сервером

Як було згадано раніше, клієнт оновлює значення лічильника подій при кожній генерації одноразового пароля. У свою чергу, значення лічильника на сервері збільшується тільки після успішної автентифікації. Виходячи з цих тверджень можна описати причини, чому впровадження процесу ресинхронізації необхідно:

1. Аутентифікація не пройдена. Клієнт оновив значення лічильника після створення пароля, а значення на сервері не змінилося
2. Проблема зв'язку. Клієнт інкрементував значення лічильника після відправки пароля, але пароль не досяг сервера

Це призводить до необхідності використання параметра розсинхронізації ${\displaystyle }$, який буде відповідати за розміри вікна, в межах якого значення лічильника клієнта і сервера будуть вважатися синхронізованими.

Ресинхронізація лічильника

Ресинхронізація проводиться виключно сервером. Вона полягає в розрахунку нового значення для свого лічильника подій, щоб його значення співпадало з отриманими від клієнта в межах різниці між значеннями не більше ${\displaystyle }$. Якщо ця умова виконується, то сервер оновлює значення власного лічильника.

В іншому випадку сервер розраховує заново стан лічильника. В ході цього процесу сервер може запросити кілька разів додаткові значення одноразових паролів. Це зроблено для підвищення рівня безпеки, так як порівняння паролів у цьому випадку виконуються для двох або трьох пар. Якщо кількість спроб буде вичерпано, то сервер блокує обліковий запис користувача. Параметр ${\displaystyle }$ також визначає вікно, в межах якого сервер збільшує лічильник в процесі ресинхронізації. Це обмеження параметром служить для:

1. Обмеження шансу підбору вірного значення пароля
2. Запобігти зацикленню розрахунку значення в рамках однієї перевірки

Безпека

Надійність алгоритму

Системи захисту, побудовані з використанням HOTP, володіють високим ступенем надійності. Вони, в більшості своїй, стійкі до широко поширеним криптографічних атак, наприклад:

• Атака виду «людина посередині» (Man-in-the-middle). Зловмисник не може підробити пересланого запрошення повідомлення, так як пароль змінюється досить часто. Безліч методів криптографічного аналізу стають при цьому малопридатними. У деяких реалізаціях лічильник, який використовується для створення пароля, змінює значення після кожної пересилання. Якщо повідомлення зашифровані з використанням досить сильного шифру, то HOTP робить підбір пароля майже неможливим.

• Атака повторного відтворення. Тут успіх залежить від конфігурації самої системи. У випадку, наприклад, коли використовується сервер аутентифікації для надання прав на вхід користувача, у атакуючого виникає ряд проблем. Сервер після кожного прийому повідомлення збільшує значення лічильника на одиницю. Тому елементарна відправка дубліката повідомлення не пройде перевірку — повідомлення створювалося за допомогою одного значення, а перевірка проводиться іншим.

• Якщо ключ складається з ${\displaystyle }$ довільних цифр, то ймовірність успіху атаки методом прямого перебору при наявності ${\displaystyle }$ спроб аутентифікації до моменту блокування розраховується за формулою ${\displaystyle }$. Наприклад, при 5 дозволених спробах введення шестизначного пароля і розмірі допустимого вікна ${\displaystyle }$ шанс успіху при атаці становить 0,015 %.

Часто зловмиснику вдається вкрасти з сервера аутентифікації хешований пароль, по якому відбувається перевірка достовірності. Однак алгоритм для створення пароля використовує також лічильник подій. Оскільки початкове значення лічильника вибирається сервером, воно зазвичай випадкове, що ускладнює злом каналу зв'язку навіть при наявності у атакуючого розподіленого секрету.

Способи посилення захисту

Дані зміни не є обов'язковими або рекомендованими авторами алгоритму розширеннями. Однак для підвищення рівня безпеки власної реалізації можна застосувати такі варіанти:

• Збільшення довжини значення HOTP.

Витяг кожного нового символу з результату ${\displaystyle }$ різко зменшує шанси успішної атаки. Завдяки цьому можна зробити процес роботи з паролями зручніше. Наприклад, збільшити кількість спроб введення або розширити діапазон, в якому порівнюються значення лічильників сервера і клієнта.

• Алфавітно-цифрові значення.

Сенс цієї ідеї полягає в тому, щоб використовувати не тільки цифри для пароля, але ще і символи A-Z. Вірніше, мова йде про набір з 32 символів з алфавітно-цифрового множини. Відразу ж стає видно, як виріс рівень безпеки паролів, тому що тепер ймовірність успіху повного перебору складає ${\displaystyle }$ для паролів, які складаються з 6 символів.

• Ресинхронізація на базі лічильника.

Якщо умови дозволяють клієнту відправляти не тільки значення HOTP, але і інші дані, то можна зробити процес ресинхронізації набагато зручніше і безпечніше, якщо разом зі значенням HOTP клієнт буде відправляти серверу стан лічильника подій. В цьому випадку значення клієнтського HOTP буде виступати в ролі імітовставки для стану лічильника.

Перевіряючи таким чином значення лічильника на достовірність і відповідність, можна відмовитися від використання параметра розсинхронізації, що дозволить також підвищити рівень захисту алгоритму, тому що в оновленій системі ймовірність успіху атаки прямим перебором буде становити всього ${\displaystyle }$.

Застосування

Об'єднання OATH, стандартизовало HOTP, без жодних вказівок з приводу реалізації алгоритму. Навпаки, свобода розробників дозволяє знаходити все нові рішення, прагнучи задовольнити потреби замовника та внести інноваційний внесок у технологію OTP.

Поширену реалізацію HOTP на Java можна знайти в пакеті org.jboss.security.otp, який входить у стандартні бібліотеки вільно розповсюджуваного веб-сервера Apache Jboss.

Ще одна реалізація на мові Java представлена безпосередньо об'єднанням OATH в пакеті org.openauthentication.otp.

Можна також згадати реалізацію — проект OATH Toolkit, бібліотека liboath якого дозволяє створювати паролі в режимі HOTP і TOTP.

Велика кількість низькоінтеллектуальних пристроїв спеціально створено для генерації паролів або передачі даних за допомогою HOTP і TOTP (Feitian, SecuTech, SmartDisplayer, Vasco, Yubico, Protectimus). Алгоритм також використовується в домашніх мережах для управління периферією за допомогою пульта дистанційного керування або мобільного телефону.

Вимоги до реалізації алгоритму

1. Необхідно підтримувати двофакторну аутентифікацію. У даному випадку мається на увазі, що першим чинником є генератор одноразових паролів, а другим — якийсь додатковий секрет, який додається до одноразового паролю
2. Сервер повинен бути захищений від атак методом прямого перебору, тобто обліковий запис користувача повинна блокуватися після певного числа невдалих спроб аутентифікації
3. Необхідно використовувати захищений канал

Додатково

HOTP заснований на SHA-1, яка більше не вважається досить стійкою до колізій. Проте, алгоритм HOTP використовує тільки факт випадковості числа, вирахуваного на її основі, тому наявність колізій безпосередньо не впливає на його роботу.

Одностороння аутентифікація передбачає, що клієнт за потреби намагається встановити зв'язок. Після чого сервер відправляє запит назад клієнтові і перевіряє його відповідь на справжність. Модифікація алгоритму OCRA дозволяє також і користувачеві провести аутентифікацію сервера.

Дивись також

• Time-based One-time Password Algorithm

Посилання

• RFC 4226(англ.)
• HOTP-Based User Authentication Scheme in Home Networks(англ.)