Доска почёта ЭЦП — ofd1.kz

Портал ОФД Транстелеком — решение вопроса фискализации в режиме онлайн для контрольно-кассовых машин. При анализе обнаружено два замечания: одно замечание жёлтого уровня [😐], а другое — красного [🤬] (об уровнях).

😐 Ограниченная поддержка носителей ключей ЭЦП

На портале ОФД Транстелеком поддерживаются только ключи ЭЦП, хранящиеся в виде обычных файлов на компьютере. Защищённые носители ключей ЭЦП не поддерживаются.

Ключи ЭЦП можно хранить в разных местах. Например:
- Файлы на компьютере
- Удостоверение личности гражданина РК
- KAZTOKEN
- JaCarta
- Хранилище ключей Java
- AKEY
- eToken5110
- eToken

Из всех вышеперечисленных, наименее защищённым является хранение ключей ЭЦП в файлах на компьютере. О соответствующем риске говорится в личном кабинете Национального удостоверяющего центра Республики Казахстан при выпуске ЭЦП.

Напомню, закрытый ключ, должен храниться в строжайшем секрете. В идеале, никогда, ни при каких обстоятельствах не покидать устройство, где он был создан и хранится. Об этом подробнее можно прочитать в одной из моих статей из цикла «Цифровая гигиена»: ЭЦП, SMS и много других непонятных слов. Я, например, выпускаю свои ключи ЭЦП (как личные, так и служебные) в своём устройстве KAZTOKEN и, соответственно, храню их там же.

Комментарий разработчика:

Если интернет-ресурс использует актуальный API NCALayer, то разработчики могут довольно легко решить данную проблему. Для этого перед вызовом метода подписания данных, необходимо предварительно вызвать getActiveTokens и, в том случае, если он вернул непустой массив, попробовать использовать элемент этого массива при подписании.

Пример подобной обработки приведен в описании JS библиотеки для работы с NCALayer: https://github.com/sigex-kz/ncalayer-js-client

Интерактивная документация по API NCALayer.

🤬 Некорректная реализация аутентификации

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

Несмотря на то, что в процессе аутентификации на ofd1.kz отображается окно NCALayer, предлагающее выбрать файл хранилища ключей, сертификат и ввести пароль, фактической аутентификации по цифровому сертификату интернет-ресурс не выполняет, а вместо этого, получив данные о сертификате, он ограничивается проверкой срока действия сертификата. Таким образом аутентификацию можно выполнить не только с помощью отозванного сертификата Национального удостоверяющего центра Республики Казахстан (НУЦ РК), но и с помощью любого самостоятельно сформированного сертификата не имеющего отношения к НУЦ РК.

Комментарий разработчика:

Ситуацию усугубляет тот факт, что NCALayer в заголовке окна отображает строку «Подписание выбранным ключем», несмотря на то, что был вызван метод kz.gov.pki.knca.commonUtils.getKeyInfo (метод получения информации о сертификате), а не один из методов подписания данных, таких как kz.gov.pki.knca.commonUtils.createCAdESFromBase64, kz.gov.pki.knca.commonUtils.createCMSSignatureFromBase64 или kz.gov.pki.knca.commonUtils.signXml.

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

Потенциально, злоумышленник может войти в систему от имени любого пользователя.

PS: желающие более глубоко погрузиться в вопрос аутентификации по цифровым сертификатам могут почитать соответствующую статью.

Vladimir Turekhanov ・ February 04, 2021

 

вернуться