Коммит d1b88ec7 создал по автору lagutinakv's avatar lagutinakv
Просмотр файлов

Add the section about encryption and tokens

владелец 3a9c025b
......@@ -831,6 +831,21 @@ Copyright © 2016–2025 ООО «Открытая мобильн
* [Тесты](./sensors_filter/tests.md)
* NFC
* Шифрование и токены
* [QCA](./qca)
* Лекция:
[cлайды](./qca/lecture.fodp),
[конспект](./qca/lecture.md)
* [Тесты](./qca/tests.md)
* [Работа с токенами](./tokens)
* Лекция:
[cлайды](./tokens/lecture.fodp),
[конспект](./tokens/lecture.md)
* [Тесты](./tokens/tests.md)
* [KeyStore](./keystore)
* Лекция:
[cлайды](./keystore/lecture.fodp),
[конспект](./keystore/lecture.md)
* [Тесты](./keystore/tests.md)
* Дополнительные API ОС Аврора
* Локализация приложений
* [Интернационализация в Qt](./internationalization)
......
Это отличие свёрнуто
# KeyStore
Copyright © 2025 ООО «Открытая мобильная платформа».
Этот документ предоставляется в соответствии
с [Публичной лицензией Creative Commons с указанием авторства версии 4.0 Международная](../../LICENSE.CC-BY-4.0.ru.md).
## Aurora KeyStore
Aurora KeyStore предназначено для обеспечения следующих возможностей:
* хранение в зашифрованном виде данных пользователя: открытый/закрытый ключ ЭП, ключи симметричного шифрования, сертификат открытого ключа ЭП;
* доступ к данным на основе пароля (пин-кода);
* механизмы подписи и проверки подписи;
* механизм генерации асимметричных (открытый/закрытый ключ ЭП) и симметричных ключей;
* механизмы шифрования и расшифрования данных;
* механизмы формирования хэш-кода.
## Реализация KeyStore
Aurora KeyStore реализует криптографический токен, имеющей две возможные реализации:
* TEE Keystore — программно-аппаратное средство, использующее аппаратную поддержку ARM TrustZone (для устройств, поддерживающих TEE);
* SoftHSM Keystore – программное средство.
Ключевое отличие реализации TEE Keystore от SoftHSM заключается в том, что данные TEE хранятся в отдельной защищенной области памяти.
Aurora Keystore используется совместно с КриптоAPI (работает под управлением ОС Аврора), реализующим интерфейсные функции взаимодействия прикладного ПО с Keystore и СКЗИ.
КриптоAPI построено на основе библиотеки QCA.
Приложения (де)шифруют свои данные без прямого использования ключей (например, SoftPOS и браузер).
На устройствах, поддерживающих TEE, доступна только реализация TEE Keystore. Реализация SoftHSM Keystore используется на устройствах без поддержки TEE и в эмуляторе.
## UserApp Keystore
Хранилище типа UserApp Keystore (USERAPP токен) обеспечивает хранение данных конкретного пользователя, обрабатываемых одним определённым приложением.
UserApp Keystore ограничивает несанкционированный доступ к защищаемым данным как со стороны других пользователей мобильного устройства, так и со стороны прикладных приложений, не являющихся владельцем хранилища.
Примером приложения, требующего использования UserApp Keystore, может быть SoftPOS-терминал.
## Основные моменты при работе с KeyStore
В приложении должен быть реализован обработчик запросов.
Обработчик запросов должен работать в отдельном потоке.
Библиотека QCA должна быть инициализирована (QCA::Initializer) до выполнения любых операций.
Провайдер PKCS#11 должен быть инициализирован (QCA::KeyStoreManager).
Токен приложения должен быть однократно проинициализирован (создан).
В операциях с ключами из KeyStore необходимо явно задавать используемый провайдер Aurora KeyStore — qca—aurora—pkcs11.
## qca-aurora-pkcs11
Взаимодействие приложений с Aurora KeyStore (USERAPP токеном) осуществляется с использованием стандартного КриптоAPI ОС Аврора (QCA).
Для доступа к Aurora KeyStore используется специальный криптопровайдер (плагин) QCA — qca-aurora-pkcs11.
Для того, чтобы использовались функции и объекты именно Aurora KeyStore, при любых операциях, позволяющих выбирать криптопровайдера, должен быть явно выбран плагин qca-aurora-pkcs11.
Это делается указанием строки "qca-aurora-pkcs11" в параметре provider при вызове конструктора требуемого объекта.
Токен Aurora KeyStore предназначен для долговременного защищенного хранения ключевых данных.
Непосредственно содержимое секретных ключей никогда не извлекается из токена.
Все криптооперации, требующие использования ключей, выполняются внутри токена.
Прежде чем приложение сможет работать с USERAPP токеном, токен должен быть инициализирован.
Инициализация токена может быть выполнена, например, при первом запуске приложения.
Для инициализации используется вызов initKeyStore() (QCA::KeyStoreManager).
# Тесты по теме «KeyStore»
Copyright © 2025 ООО «Открытая мобильная платформа».
Этот документ предоставляется в соответствии
с [Публичной лицензией Creative Commons с указанием авторства версии 4.0 Международная](../../LICENSE.CC-BY-4.0.ru.md).
## Multiple choice
Какие возможности предоставляет Aurora KeyStore?
---
* **Хранение открытых и закрытых ключей электронной подписи**
* Доступ к данным только на основе биометрии
* **Генерация и проверка цифровых подписей**
* Поддержка исключительно программного механизма защиты
## Single choice
В каком режиме работают криптографические операции с Aurora KeyStore?
---
* Открытые ключи постоянно находятся вне хранилища
* Непосредственное извлечение секретных ключей из хранилища разрешено
* **Криптографические операции выполняются внутри самого токена KeyStore**
## Single choice
При выполнении каких действий должна быть явно указана библиотека-поставщик "qca-aurora-pkcs11"?
---
* Во всех случаях, когда используются криптографические функции QCA
* Только при создании объектов шифрования и дешифровки
* **Только при доступе к средствам шифрования Aurora KeyStore**
* Всегда, независимо от выполняемых операций
Это отличие свёрнуто
# QCA
Copyright © 2025 ООО «Открытая мобильная платформа».
Этот документ предоставляется в соответствии
с [Публичной лицензией Creative Commons с указанием авторства версии 4.0 Международная](../../LICENSE.CC-BY-4.0.ru.md).
## Криптографическая архитектура Qt
QCA стремится предоставить простой и кроссплатформенный криптографический API, использующий типы данных и соглашения Qt.
QCA отделяет API от реализации, используя плагины, называемые криптопровайдерами.
Преимущество этой модели состоит в том, чтобы позволить приложениям избегать сопряжения или явной зависимости от какой-либо конкретной криптографической библиотеки.
Базовая функциональность плагинов предоставляется "из коробки".
Разработчики могут создавать собственные плагины (например, для SSL, SASL, TLS) или интегрировать сторонние.
Сторонние плагины должны проходить валидацию и поставляться в составе приложения.
## Функциональность QCA
QCA предоставляет простой API для следующей функциональности:
* Безопасные массивы байтов (QCA::SecureArray).
* Целые числа произвольной точности (QCA::BigInteger).
* Генерация случайных чисел (QCA::Random).
* Сертификаты X509 (QCA::Certificate и QCA::CertificateCollection).
* Списки отозванных сертификатов X509 (QCA::CRL).
* Встроенная поддержка корневого хранилища сертификатов операционной системы (QCA::systemStore).
* Подсистема управления смарт-картами (QCA::KeyStore).
* Простая, но гибкая система ведения журнала (QCA::Logger).
* RSA (QCA::RSAPrivateKey и QCA::RSAPublicKey).
* ECDH и ECDSA (QCA::ECPrivateKey и QCA::ECPublicKey).
* Хеширование (QCA::Hash).
* Шифрование (QCA::Cipher).
* Код аутентификации сообщения (QCA::MessageAuthenticationCode).
* Кодирование и декодирование шестнадцатеричных (QCA::Hex) и Base64 (QCA::Base64) строк.
Функциональность предоставляется через плагины.
Этот подход полезен для того, чтобы избежать зависимости от конкретной криптографической библиотеки и упростить обновление, поскольку нет необходимости перекомпилировать приложение при добавлении или обновлении криптографического плагина.
Кроме того, благодаря включению криптографических функций в плагины приложение избавляется от юридических проблем, таких как регулирование экспорта.
## Использование QCA
Приложение просто включает <QtCrypto> и ссылки на libqca, которая предоставляет «оболочку API» и загрузчик плагинов.
Криптографическая функциональность определяется во время выполнения, а подключаемые модули загружаются из подкаталога «crypto» путей к библиотеке Qt.
Использование QCA во многом похоже на использование Qt, и при опыте работы с Qt работа с QCA должна казаться «естественной».
Однако для создания надёжных приложений необходимо знать несколько особенностей:
* QCA необходимо инициализировать перед использованием любого класса, который требует поддержки плагинов или использует безопасную память.
Это большая часть QCA, поэтому следует обязательно предполагать, что нужно выполнить инициализацию.
Самый простой способ сделать это — создать экземпляр объекта QCA::Initializer и убедиться, что он не удалён (или не может выйти за пределы области видимости), пока не закончится использование QCA.
* Большинство функциональности/алгоритмов предоставляется плагинами/криптопровайдерами.
Необходимо убедиться, что требуемая функция действительно доступна (QCA::isSupported()), прежде чем пытаться её создать.
Если приложение попытается создать класс, а поддержка подходящего криптопровайдера недоступна, оно вернётся к нулевому объекту, а когда попытается использовать один из методов — получит ошибку сегментации.
Кроме того, для функциональности, которая использует имена алгоритмов (например, QCA::Hash, который принимает на вход имя алгоритма хеширования, например «md5» или «sha256»), имя ищется во время выполнения, поэтому при опечатке (например, «md56») всё будет компилироваться правильно, но во время выполнения произойдёт ошибка сегментации.
## Список криптопровайдеров
Объект Initializer настраивает элементы, а также выполняет очистку, когда они больше не требуются.
Загрузка всех доступных криптопровайдеров.
Обычно она не нужна (потому что тестирование проходит с помощью isSupported()), но это особый случай.
Эта инструкция даёт список всех плагинов-криптопровайдеров.
У каждого криптопровайдера есть имя, которое можно отобразить, а также список возможностей.
Список строк превращается обратно в одну строку, и она также отображается.
Следует обратить внимание, что криптопровайдер по умолчанию не включается в результат QCA::providers().
Однако всё ещё можно узнать про функциональность, поддерживаемую криптопровайдером по умолчанию.
## Работа с сертификатами
Работа будет происходить с несколькими сертификатами, а QList — отличный шаблонный класс для решения данной задачи.
Используются системные сертификаты.
Эта инструкция превращает CertificateCollection в QList объектов сертификата.
Серийный номер сертификата — QCA::BigInteger, но можно просто преобразовать его в строку, а затем вывести.
Информация о субъекте показывает свойства того, к кому применяется сертификат.
Информация об издателе показывает свойства того, кем был подписан сертификат.
Далее выполняется проверка, можно ли использовать сертификат в качестве центра сертификации.
Далее выполняется проверка, является ли сертификат самоподписанным.
Сертификат действителен только в определённые даты.
Можно получить даты (как QDateTime) с помощью пары вызовов.
Можно получить сертификат в кодировке PEM простым вызовом метода toPEM().
## Хэширование
Hash — это класс для различных алгоритмов хеширования в QCA.
SHA256, SHA1 или RIPEMD160 рекомендуются для новых приложений, хотя MD2, MD4 или MD5 могут быть применимы (по причинам совместимости) для некоторых приложений.
В примере в качестве исходных данных используется первый аргумент программы, если он предоставлен, или используется «привет», если нет аргументов.
Всегда нужно проверять, поддерживается ли алгоритм, прежде чем его использовать.
Эта инструкция демонстрирует подход к хэшированию «всё в одном».
## Шифрование
Cipher — это класс для различных алгоритмов, выполняющих низкоуровневое шифрование и дешифрование в рамках QCA.
В примере в качестве исходных данных используется первый аргумент, если он предоставлен, или используется «привет», если нет аргументов.
Создаётся случайный ключ — в реальном приложении он, вероятно, будет получен из другого источника.
Создаётся случайный вектор инициализации — это значение нужно, чтобы расшифровать полученный зашифрованный текст, но его не нужно держать в секрете (в отличие от ключа).
Создаётся 128-битный объект шифрования AES в режиме сцепления блоков шифротекста (CBC).
Используется заполнение по умолчанию, что эквивалентно PKCS7 для CBC.
Этот объект будет зашифрован.
Используется зашифрованный объект, чтобы зашифровать аргумент, который был передан, после чего возвращается результат.
Следует обратить внимание, что если данных меньше 16 байт (1 блок), то ничего не будет возвращено.
Данные буферизуются, можно вызвать update() столько раз, сколько потребуется.
Следует обратить внимание, что всегда нужно вызывать final() даже без дополнения, чтобы провести очистку.
QCA::SecureArray f = cipher.final();
Повторно используется дешифрование зашифрованного текста.
Нужно использовать тот же ключ и вектор инициализации, что и при шифровании.
Создаётся единый массив зашифрованного текста.
Также можно вызвать update() с каждым блоком по мере его получения, если это полезнее.
Текст расшифровывается.
Снова нужно вызвать final(), чтобы получить последний блок (с удалённым дополнением).
Вместо update() и final() можно сделать всё за один шаг, используя process().
## Код аутентификации сообщения
MessageAuthenticationCode— это класс для доступа к различным алгоритмам аутентификации сообщений в QCA.
Для новых приложений рекомендуется HMAC с использованием SHA1 ("hmac(sha1)") или HMAC с использованием SHA256 ("hmac(sha256)").
Первый аргумент используется как данные для аутентификации, если аргумент предоставлен.
В противном случае используется строка «hello».
Второй аргумент используется как ключ для аутентификации, если предоставлены два аргумента.
«Секрет» используется в качестве ключа, если число аргументов менее двух.
Создаётся требуемый объект с использованием HMAC с SHA-1 и пустым ключом.
Создаётся ключ, устанавливается объект HMAC для использования ключа.
Он разбивается на две части, чтобы показать инкрементное обновление: три символа — "hel", остаток — "lo".
После вызова final обновления невозможны.
Результат конвертируется в шестнадцатеричный для печати.
## Кодирование и декодирование строк
Используется первый аргумент в качестве данных для кодирования, если аргумент предоставлен.
В противном случае используется строка «hello».
Создаётся объект, который по умолчанию использует алгоритм кодировки QCA::Base64 encoder(QCA::Encode).
В примере демонстрируется фактическое преобразование (кодирование).
Можно предпочесть использовать encoder.encode(); и пусть он вернёт QCA::SecureArray, в зависимости от потребностей.
Создаётся объект для декодирования base64.
Также можно повторно использовать существующий объект, вызвав для него clear(); и setup(QCA::Decode).
QString конвертируется в QString.
# Тесты по теме «QCA»
Copyright&nbsp;©&nbsp;2025 ООО&nbsp;«Открытая мобильная платформа».
Этот документ предоставляется в&nbsp;соответствии
с&nbsp;[Публичной лицензией Creative Commons с&nbsp;указанием авторства версии&nbsp;4.0 Международная](../../LICENSE.CC-BY-4.0.ru.md).
## Single choice
Какое основное преимущество разделения API и реализации в QCA?
---
* **Упрощение обновления и независимость от конкретных библиотек**
* Ускорение процесса разработки приложений
* Повышение производительности криптографических операций
* Автоматическое создание новых типов данных
## Single choice
Что используется для инициализации QCA перед началом работы с любыми функциями, зависящими от плагинов?
---
* Метод QCA::init()
* **Создание экземпляра объекта QCA::Initializer**
* Установка переменной окружения QT_CRYPTO_PLUGIN_PATH
* Настройка конфигурации проекта
## Single choice
Почему важно проверять доступность нужной криптографической функции перед её использованием?
---
* **Из-за возможных ошибок сегментации**
* Чтобы оптимизировать производительность приложения
* Потому что некоторые функции требуют ручного конфигурирования
* Это обязательное требование лицензии Qt
## Single choice
Какое утверждение верно относительно интеграции сторонних криптографических модулей в QCA?
---
* Сторонние плагины интегрируются автоматически при установке Qt
* **Все сторонние плагины проходят обязательную валидацию перед распространением**
* Применение стороннего плагина возможно только после полной замены стандартных
* Нет необходимости проводить дополнительную настройку сторонних плагинов
Это отличие свёрнуто
# Работа с токенами
Copyright&nbsp;©&nbsp;2025 ООО&nbsp;«Открытая мобильная платформа».
Этот документ предоставляется в&nbsp;соответствии
с&nbsp;[Публичной лицензией Creative Commons с&nbsp;указанием авторства версии&nbsp;4.0 Международная](../../LICENSE.CC-BY-4.0.ru.md).
## Токены и токенизация
В информационной безопасности токенизация — это процесс замены конфиденциальных данных на неконфиденциальный токен.
Токен — это идентификатор, который сопоставляется с конфиденциальными данными через систему токенизации.
Детокенизация — это обратный процесс обмена токена на связанные с ним данные.
Безопасность отдельного токена в основном зависит от невозможности определить исходное значение, зная только его замещающее значение.
Токен не имеет самостоятельного значения для внешнего или внутреннего использования.
Методы сопоставления исходных данных с токеном делают невозможным обратное преобразование токенов в исходные данные вне системы токенизации.
Система токенизации предоставляет приложениям API для запроса токенов и расшифровки конфиденциальных данных.
Такая система уменьшает риск компрометации, случайного воздействия и несанкционированного доступа к конфиденциальным данным.
Приложения могут работать с токенами, а не с реальными данными.
Токены обычно делятся на одноразовые и многоразовые.
Одноразовый токен обычно используется для представления конкретной транзакции.
Многоразовый токен может использоваться для отслеживания одних и тех же данных в нескольких транзакциях.
## Токены в QCA
TokenAsker — обработчик токенов пользователя.
Этот класс используется для запроса пользователя вставить токен.
ask()
Ставит в очередь запрос токена, связанный с хранилищем ключей.
waitForResponse()
Блокируется до завершения запроса токена.
responseReady()
Сигнал испускается, когда процесс запроса завершён.
Нужно проверить, принял ли пользователь ответ с помощью accepted(), прежде чем полагаться на наличие токена.
accepted()
Проверка, был ли принят запрос токена.
Возвращает true, если запрос токена был принят.
## Пример запроса токена
В приведённом на слайде коде показано, как работать на стороне клиента с запросом токена от QCA и любых связанных криптопровайдеров.
Полный пример кода доступен по ссылке внизу.
# Тесты по теме «Работа с токенами»
Copyright&nbsp;©&nbsp;2025 ООО&nbsp;«Открытая мобильная платформа».
Этот документ предоставляется в&nbsp;соответствии
с&nbsp;[Публичной лицензией Creative Commons с&nbsp;указанием авторства версии&nbsp;4.0 Международная](../../LICENSE.CC-BY-4.0.ru.md).
## Single choice
Что такое токенизация?
---
* Процесс шифрования данных
* **Процесс замены конфиденциальных данных на неконфиденциальный токен**
* Процесс хранения паролей пользователей
* Метод защиты сетевых соединений
## Text
Как называется обратный процесс преобразования токена в оригинальные данные?
---
* Детокенизация
## Single choice
Какие существуют типы токенов согласно тексту?
---
* **Одноразовые и многоразовые**
* Временные и постоянные
* Одноразовые и двухразовые
* Стандартизированные и уникальные
## Single choice
Для чего предназначен метод ask() класса TokenAsker?
---
* Проверяет принятие запроса токена
* Блокирует выполнение программы до завершения запроса токена
* **Запрашивает ввод токена от пользователя**
* Возвращает факт принятия запроса токена
## Single choice
Что означает сигнал responseReady() в классе TokenAsker?
---
* Пользователь успешно ввёл токен
* Система готова принять новый запрос
* Произошла ошибка в процессе ввода токена
* **Завершился процесс запроса токена**
Поддерживает Markdown
0% или .
You are about to add 0 people to the discussion. Proceed with caution.
Сначала завершите редактирование этого сообщения!
Пожалуйста, зарегистрируйтесь или чтобы прокомментировать