Реализация двухкомпонентной системы аутентификации пользователей с использованием мобильных устройств

Целью данного проекта является создание менеджера паролей, лишённого описанных недостатков, при сохранении полноценного набора возможностей и уровня безопасности. Были сформулированы следующие требования к реализации нового менеджера:

1. Модель

Основываясь на разработанной модели, изначальных требованиях к менеджеру паролей и анализе существующих решений были разработаны следующие требования к реализации менеджера паролей:

1. Пользователь, используя сочетание клавиш Shift+Alt+Ins, может запросить пароль, используя заголовок активного окна как идентификатор.

2. Пользователь, используя сочетание клавиш Shift+Alt+N, может задать пароль, используя заголовок активного окна как идентификатор.

3. Пользователь, используя сочетание клавиш Shift+Alt+O, может запросить OTP код. Заголовок окна не используется - пользователь выбирает нужный сервис на экране Android устройства.

4. При использовании расширения для браузера Google Chrome, вместо заголовка окна в качестве идентификатора должен быть использован адрес открытого сайта.

5. Пользователь, при создании пароля, имеет возможность сгенерировать пароль по указанным критериям: длина, входящие символы.

6. Пользователь имеет возможность выбрать способ беспроводной коммуникации: Bluetooth или локальная Wi-Fi сеть.

7. Пользователь имеет возможность отсканировать QR с информацией для генерации OTP. Данные будут сохранены на Android устройстве и использованы для генерации кодов по запросу.

8. Пользователь имеет возможность отсканировать QR, сгенерированный ПК, для сохранения пароля в памяти Android устройства.

9. Пользователь имеет возможность отсканировать QR, сгенерированный ПК, для получения и автоматического ввода пароля из памяти Android устройства.

10. Пользователь имеет возможность выбирать и создавать профили в рамках одного ресурса.

Нефункциональные:

1. Передача данных должна осуществляться только локально, без участия сторонних серверов.

2. Доступ к хранилищу может быть получен тем же путём, что и разблокировано Android устройство (включая доступную, значительно упрощающую доступ, биометрическую аутентификацию).

3. Перехват переданных беспроводным образом данных не должен приводить к раскрытию секретной информации.

4. Система не должна быть уязвима к Man-in-the-middle атаке.

5. Управляющая зашифрованным хранилищем подсистема не должна быть уязвима к Oracle padding атаке (Vaudenay, 2002).

3. Математические и алгоритмические основы

3.1 Схема обмена ключами

Так как данная модель, для снижения последствий заражения компьютера, не подразумевает хранение никаких секретных данных на ПК под управлением Windows, необходим способ установления зашифрованного соединения без предварительно сгенерированного общего ключа. Именно такими характеристиками обладает схема обмена ключами Диффи-Хэллмана на эллиптических кривых (Law, Menezes, Qu, Solinas, Vanstone, 1998) которая является расширением классического протокола Диффи-Хэллмана (Whitfield Diffie and Martin Hellman, 1976). Данный алгоритм позволяет безопасно сгенерировать общее секретное значение по прослушиваемому каналу. Версия на эллиптических кривых предоставляет больший уровень безопасности при меньшей вычислительной сложности. Схема обмена ключами состоит из следующих шагов:

1. Обе стороны договариваются об общей эллиптической кривой (или используют фиксированную) и точке-генераторе.

2. Каждая из сторон генерирует случайное число - секретный ключ и, с его помощью, получают точку на эллиптической кривой - открытый ключ.

3. Стороны производят обмен открытыми ключами по открытому каналу.

4. Используя собственный секретный ключ и открытый ключ другой стороны, каждая сторона вычисляет общую точку на эллиптической кривой, которая может быть использована для получения общего ключа симметричного шифрования.

Безопасность схемы обусловлена тем, что обратить операцию получения точки на эллиптической кривой из числа - вычислительно сложная задача и может быть, в данный момент, решена лишь полным перебором. Однако, любой вариант протокола Диффи-Хэллмана уязвим к атаке типа Man-in-the-middle - когда злоумышленник включает себя в канал передачи данных между обменивающимися сторонами и производит две независимых схемы обмена ключами. После этого человек посередине способен читать передаваемые сообщения, производя расшифровку и зашифровку имеющимися ключами. Таким образом, важно точно знать, с кем именно происходит обмен ключами.

3.2 Генерация OTP кодов

Генерация OTP (One Time Password) кодов происходит следующим образом (Frank, Hoornaert; David, Naccache; Mihir, Bellare; Ohad, Ranen, 2005):

Используя секретную строку К и текущее время (в секундах) t, производятся следующие действия:

1. Вычисляется значение C, обозначающее номер 30-секундного интервала с начала эпохи Unix в который попадает t.

2. Вычисляется H = HMAC(C, K) - строка аутентификации сообщения на основе хэш функции, представляющая собой подпись C ключом K.

3. Используя последние 4 бита H в качестве сдвига, из H извлекается четыре последовательных байта.

4. Эти 4 байта, без самого старшего бита, интерпретируются как целое число.

5. От числа, отбрасывая старшие разряды, берётся необходимое количество цифр (как правило - 6).

3.3 Симметричная криптография

Передаваемые данные шифруются блочным шифром AES-256 в следующих режимах:

Рисунок 1

Рисунок 2

CBC (Cipher Block Chaining) - широко распространённый режим блочного шифрования, при котором каждый новый блок шифротекста выражается из предыдущего (для первого блока используется случайно сгенерированный инициализационный вектор, передаваемый открыто), позволяя избежать такой проблемы как одинаковость зашифрованных данных при одинаковости исходных данных (Рис 1, Рис 2). Серьёзность данной проблемы может быть проиллюстрирована примером ниже

Рисунок 3AES-CBC используется при шифровании сессионным ключом (полученным из схемы обмена ключами Диффи-Хэллмана).

Рисунок 4 GCM (Galois/Counter Mode) - режим блочного шифрования, обеспечивающего так называемое аутентифицированное шифрование, при котором зашифрованные данные дополнительно снабжаются зависящим от ключа и данных значением, которое может быть повторно вычислено на этапе расшифровки (Рис 4). Это позволяет проверить, что полученное сообщение не было изменено и избежать Padding oracle атаки (Vaudenay, 2002). Данный режим используется для шифрования хранилища паролей на мобильном устройстве.

4. Архитектура системы

4.1 Компоненты системы

Система состоит из следующих компонентов:

1. Android приложение, осуществляющее операции с зашифрованным хранилищем паролей. Ответственно за аутентификацию пользователя, отправку и получение паролей по беспроводному каналу, генерацию OTP кодов и сохранение информации для их генерации.

2. Windows приложение, являющееся основным способом взаимодействия с системой. Ответственно за запуск процедур сохранения и запроса паролей, генерацию паролей согласно заданным критериям, запрос OTP кодов.

3. Google Chrome расширение на Windows ПК, позволяющее менеджеру паролей использовать адрес сайта как идентификатор ресурса. Позволяет сохранять и запрашивать пароли для отдельных сайтов.

Инициализация любой из трёх процедур (запрос пароля, добавление пароля, запрос One Time Password) происходит с помощью нажатия сочетания клавиш на клавиатуре. Компонент на ПК, для упрощения использования, автоматически определяет, с каким сервисом необходимо ассоциировать операции с паролями. Уникальным идентификатором в данном случае служит заголовок окна. Например, клиент электронной почты таким образом легко отличим от компьютерной игры. Заголовок передаётся с ПК на Android устройство в зашифрованном виде после установления защищённого соединения. Основная проблема такого подхода - заголовок окна браузера практически никогда не равен адресу сайта. Более того, один сайт на различных страницах может иметь десятки различных заголовков, которые становятся заголовками окна. Так как заполнение паролей на страницах интернета - основная задача менеджера паролей, стояла необходимость разработать способ получения Android компонентом адреса сайта, не открывая дорогу несанкционированному использованию этого функционала другими приложениями на ПК. Таким образом, с точки зрения безопасности нельзя просто предоставить интерфейс для получения адреса сайта, так как это даст возможность любым приложениям на ПК шпионить за пользователем разрабатываемой системы.

Был выбран альтернативный путь без обратной коммуникации браузера с ПК компонентом - локальное приложение представляет собой WebSocket сервер. Браузерное расширение, будучи запущенным, должно установить с ним соединение и, в случае получения сообщения, отобразить на странице сайта QR код, присоединив к переданным данным адрес сайта (Рис 5). Таким образом, мобильное устройство получит идентификатор ресурса - адрес сайта, не предоставляя эти данные другим приложениям на ПК.

4.2 Технологии

Windows-компонент:

· C# - .Net Framework 4.5

· Nuget пакет Newtonsoft.Json © James Newton-King (MIT) - серализация и десериализация JSON

· Nuget пакет QRCoder © Raffael Herrmann (MIT) - формирование QR изображений

· Nuget пакет websocket-sharp.clone © Jacob Reimers (MIT) - WebSocket сервер

· Nuget пакет 32feet.NET © Alan McFarlane, Peter Foot (MIT) - для работы с Bluetooth

Android-компонент:

· Kotlin

· Google play services vision © Google (Android Software Development Kit License) - распознавание QR кодов

· GSON © Google (Apache 2.0) - сериализация и десериализация JSON

· Android-floating-action-button © Jerzy Chalupski (Apache 2.0) - UI элемент на странице профилей

4.3 Обмен данными

Рисунок 5

Применительно к выбранной двухкомпонентной модели, схема обмена ключами и обмен данными реализованы следующим образом:

1. ПК генерирует ключевую пару: публичный и секретный ключи для протокола Диффи-Хеллмана на эллиптических кривых

2. ПК отображает на экране QR код, выступающий способом передачи данных на первом этапе, в котором закодирован публичный ключ. Дополнительно, данный QR содержит в себе обратный адрес - локальный IP адрес в случае коммуникации через Wi-Fi или MAC адрес и GUID сервера в случае коммуникации через Bluetooth.

3. Android устройство получает публичный ключ, считывая QR. Атака Man-in-the-middle становится невозможна после этого шага - публичный ключ ПК получен из достоверного источника - экрана ПК

4. Android устройство генерирует ключевую пару и вычисляет общий секрет. Затем, используя выбранный беспроводной канал, отправляет на ПК собственный публичный ключ

5. Происходит обмен данными (Рис 5), которые зашифрованы вычисленным на обоих концах ключом (с использованием алгоритма AES-256), полученным из общего секретного значения из протокола Диффи -- Хеллмана

Рисунок 6

Пример отображения QR на ПК - режим сохранения нового пароля в память Android устройства (Рис 6).

4.4 Основные режимы работы

Для всех режимов, кроме сохранения данных для генерации OTP, логика начинается с установления безопасного канала между устройствами:

1. Нажатие сочетания клавиш на ПК

2. Генерация пары ключей на эллиптической кривой на стороне Windows ПК

3. Отображение QR кода с публичным ключом, названием режима и данными для обратной связи (Wi-Fi/Bluetooth)

4. Считывание QR кода Android устройством

5. Генерация пары ключей на эллиптической кривой на стороне Android

6. Вычисление общего секрета на стороне Android устройства, генерация ключа для AES-256

7. Отправка публичного ключа Android устройства по указанному обратному адресу

8. Вычисление общего секрета на стороне Windows ПК, генерация ключа для AES-256

В результате обе стороны безопасно (в том числе защищённо от man-in-the-middle) вычисляют единый ключ симметричного шифрования и готовы к двустороннему обмену данными.

Таблица 2

4.5 Хранение криптографических ключей

Самое важное - защита сохраняемых на мобильном устройстве данных, обеспечивается с помощью Android Keystore - системы, которая специально разработана таким образом, чтобы упростить безопасное хранение криптографических ключей на устройстве и сделать процесс их извлечения гораздо более сложным:

· Ключи никогда не попадают в процесс исполняемого приложения. Любые данные, которые должны быть зашифрованы, расшифрованы, подписаны или проверены передаются в защищённый системный процесс. В случае компрометации приложения, атакующий, с подтверждения пользователя, может воспользоваться криптографическими ключами, но не может извлечь их из устройства.

· Если поддерживается, все криптографические операции будут происходить на выделенном чипе внутри Android устройства. Даже в случае полного взятие под контроль операционной системы, атакующие не смогут выгрузить сохранённые ключи.

Обращение к Android Keystore происходит при каждой операции с паролями - получении или сохранении. Следовательно, пользовательское подтверждение с помощью биометрии или пароля необходимо после каждого сканирования QR кода от ПК компонента.

4.6 Профили

Мобильное приложение поддерживает несколько профилей для каждого ресурса. В случае добавления нового пароля или запроса пароля, если профилей больше одного, пользователю будет показан список профилей, где можно выбрать существующий или создать новый.

Время совершения операции с профилями ограничено по времени - при текущих настройках, Android Keystore, после разблокировки, становится доступен для совершения операций только на тридцать секунд. Оставшееся время отображается в виде убывающей полосы вверху экрана.

Рисунок 7

5. Документация и описание экранов

Настройки

Чтобы получить доступ к настройкам, нужно нажать правой кнопкой мыши по значку на панели задач:

Рисунок 8

Рисунок 9

Запрос пароля

Для запроса пароля необходимо выполнить следующие действия:

1. Взять нужное текстовое в фокус и нажать сочетание клавиш Shift+Alt+Ins.

Рисунок 50

Отсканировать появившийся QR код (Рис 10).

2. Авторизоваться с помощью пароля или биометрии.

Рисунок 61

Выбрать профиль, если было создано более одного (Рис 11). На эту операцию отводится 30 секунд.

Сохранение пароля

Для сохранения пароля необходимо выполнить следующие действия:

1. Взять нужное окно в фокус и нажать сочетание клавиш Shift+Alt+N.

Рисунок 7

Отсканировать появившийся QR код (Рис 12).

Рисунок 8

Ввести или сгенерировать пароль (Рис 13).

2. Авторизоваться с помощью пароля или биометрии.

Рисунок 9

Выбрать или создать новый профиль для сохранения пароля (Рис 14). На эту операцию отводится 30 секунд.

Запрос OTP

Для запроса OTP необходимо выполнить следующие действия:

1. Взять нужное текстовое в фокус и нажать сочетание клавиш Shift+Alt+O.

Рисунок 10

Отсканировать появившийся QR код (Рис 15).

2. Авторизоваться с помощью пароля или биометрии.

Рисунок 11

Выбрать подходящий аккаунт среди доступных (Рис 16). На эту операцию отводится 30 секунд.

Сохранение данных для генерации OTP

Для сохранения данных для генерации OTP необходимо выполнить следующие действия:

1. Отсканировать с помощью приложения OTP QR код.

2. Авторизоваться с помощью пароля или биометрии.

Обучение

Обучение пользователя - важный функционал любого инструмента, особенно если он, по взаимодействию с пользователем, сильно отличается от уже знакомых существующих аналогов.

Для решения этой задачи, в мобильном компоненте, как основной части разрабатываемого приложения, был реализован тур по функционалу. Тур автоматически показывается при первом запуске приложения и может быть вызван позже с главного экрана приложения (Рис 17).

Рисунок 12

6. Системные требования

Основным методом тестирования, ввиду сложности автоматизации, является ручное прохождение пользовательских путей (Рис 18, Рис 19).

Рисунок 138

Рисунок 19

Заключение

В результате реализации данного проекта была получена безопасная и дружественная к пользователю альтернатива классическим менеджерам паролей, берущая на себя функционал внешних криптографических устройств. Разработанная двухкомпонентная система аутентификации использует аппаратную поддержку шифрования на Android устройствах, упрощает доступ с помощью встроенной в мобильные устройства биометрии, предоставляет пользователю полный контроль над своими данными без потери их мобильности и, по сравнению с классическими менеджерами паролей, значительно снижает последствия заражения ПК.

Использованная литература

1. Law Laurie, Menezes Alfred, Qu Minghua, Solinas Jerry and Vanstone Scott (1998) An Efficient Protocol for Authenticated Key Agreement

2. McGrew David A., Viega John (2005) The Galois/Counter Mode of Operation (GCM)

3. Microsoft (2016) Security Intelligence Report

4. Nokia (2017) Threat Intelligence Report

5. Serge Vaudenay (2002) Security Flaws Induced by CBC Padding Applications to SSL, IPSEC, WTLS…

6. Statcounter (2019) Mobile Operating System Market Share Worldwide

7. Whitfield Diffie and Martin Hellman (1976) New Directions in Cryptography

8. Frank, Hoornaert; David, Naccache; Mihir, Bellare; Ohad, Ranen (2005) HOTP: An HMAC-Based One-Time Password Algorithm

Приложение

Исходный код Windows компонента: https://github.com/Acuion/Lockall-Windows

Исходный код Android компонента: https://github.com/Acuion/Lockall-Android

Размещено на Allbest.ru