Comments 48
Так все-таки, как же вы собираетесь «кроссплатформенно» сделать подпись/шифрование файла алгоритмом, расположенным в ключе?
Я что-то нигде этого не увидел.
Я что-то нигде этого не увидел.
Для реализации полной кроссплатформенности необходимо, чтобы web-сервер запускался и работал ВНУТРИ токена и следовательно сам токен притворялся в системе сетевым интерфейсом. Токен, на котором я делал данную демонстрацию, пока такой возможности не имеет. Я просто показал сам принцип.
чтобы web-сервер запускался и работал ВНУТРИ токена и следовательно сам токен притворялся в системе сетевым интерфейсом
И как вы предлагаете это сделать?
Самое первое что приходит в голову — реализовать для начала на токене сетевой стек и написать внутри токена сервис обработки команд. Естественно, для этого необходимо иметь доступ «внутренностям» самого токена.
Почему бы всё-таки не сделать некую программную прослойку прикладного уровня с зачатками HTTP(S) сервера, взаимодействующую уже с драйвером токена? Конечно, это потребует отдельной версии под каждую платформу, но востребованных платформ не так уж и много.
Запихивать в токен даже минималистичный веб-сервер — явно излишне.
Запихивать в токен даже минималистичный веб-сервер — явно излишне.
Ну хорошо. Ведь ничего не мешает положить на токен (токен еще и носитель) конфигурационный файл, в котором определить все настройки. Из внутренностей токена имеется возможность прочитать свою же память.
А почему не уверены, что обращение на локальный ip не проходит?
А почему не уверены, что обращение на локальный ip не проходит?
Ведь ничего не мешает положить на токен (токен еще и носитель) конфигурационный файл, в котором определить все настройки.
И кто этот файл будет конфигурировать? А как о том, как сконфигурировано, узнает сервер, которому нужна криптофункциональность?
Тут есть конечно вопрос, но он скорее организационный, чем технический. Ведь, к примеру, для того чтобы использовать средства ЭЦП, предоставляемые токеном, как минимум необходимо сгенерировать пару ключей (это можно сделать и сторонним приложением например) и параллельно записать настройки. Также внешнее web-приложение может «говорить», какую конфигурацию токена можно использовать для своих целей. Вариантов множество.
Да, но ключи-то генерят при помощи этого же токена!
Да, но ключи-то генерят при помощи этого же токена!
Кто вам это сказал?
Дело в том, что я использовал токен, который внутри себя содержит всю соответствующую математику, начиная от генерации ключей и их хранения, заканчивая выработкой ЭЦП и шифрования. Алгоритмы зашиты в само устройство. Это т.н. криптомашина. Плюс токен реализует режим съемного носителя.
PKCS#11 например об этом говорит.
И это действительно так. Потому что закрытый ключ не должен покидать токена, особенно, если речь про ГОСТ. Наружу можно вытащить только запрос на сертификат. А потом заверенный сертификат записать в контейнер.
И это действительно так. Потому что закрытый ключ не должен покидать токена, особенно, если речь про ГОСТ. Наружу можно вытащить только запрос на сертификат. А потом заверенный сертификат записать в контейнер.
Наружу можно вытащить еще и открытые ключи, кстати.
Даже если это так, то все равно те, кто генерят эти ключи, понятия не имеют, для чего и как они будут использоваться. Это данность, я с такими ключами имел дело.
Чёйт не имеют? Мне когда в Ростелекоме выдавали для Госуслуг — так очень даже имели представление. Они, правда, не представляли, что я докопаюсь как подписывать произвольные документы, а не только ЕПГУшные транзакции, ну так это уже другая история.
Автор, а почему не рассматривается механизм работы через плагин? Рутокен Веб и еТокен ГОСТ, например, сейчас именно так интегрируются.
Это тоже вариант. Но, хотелось продемонстрировать идею работы без плагина.
Кстати, я использовал в примере аналог этих устройств. К сожалению, пока не могу здесть написать его название, т.к. устройство проходит соответствующую экспертизу.
Либо плагин, либо библиотека, которые надо иметь под все платформы. Плюс драйвера (которые не на всех платформах ставятся автоматом).
С TCP/IP интерфейсом было бы гораздо удобнее и совместимее.
С TCP/IP интерфейсом было бы гораздо удобнее и совместимее.
например, OpenSSL есть под все платформы и имеет соответствующее API для работы с токенами. Не хватает только API для работы из веб-приложения (т.е. плагина или встроенного функционала браузера).
это конечно замечательно, но как быть с национальными стандартами?
Есть такой плагин. Называется Рутокен WEB PKI Edition. Обеспечивает интеграцию Рутокен WEB/Рутокен ЭЦП + OpenSSL с браузерами. Все по ГОСТам, кросслатформенно и мультибраузерно.
Примерно такой-же интерфейс я реализовал для работы с криптографией GnuPG со страницы в браузере. В случае необходимости идет обращение на локальный порт, который слушает «программный агент» и далее выполняются все нужные действия достаточно удобным для пользователя способом. В принципе, методику можно использовать и для токенов.
Вот тут исходники (Lazarus): hg.cdemocracy.ru/cdem_agent/
Вот тут исходники (Lazarus): hg.cdemocracy.ru/cdem_agent/
Если я правильно поняла, то такой же принцип используется в USB-токенах, которые выдает Сбербанк для подключения к СБОЛ (Сбербанк бинзнес онлайн). Нам как раз выдали такой. Он запускает свой веб-сервер и далее через него уже необходимо выходить на сайт СБОЛ для дальнейшей работы с расчетным счетом. Никакого дополнительного ПО устанавливать при этом не пришлось. Довольно удобно.
А какая математика на этих токенах реализована?
www.sbrf.ru/amur/ru/legal/new_means/ — это оно?
Там пишут, что нужен драйвер USB Smart Card reader. Стало быть обычный токен.
Там пишут, что нужен драйвер USB Smart Card reader. Стало быть обычный токен.
Самый стрёмный вариант такой конструкции — авторизация и хранение сессии пользователя. Будет не очень ок, если залетный троян сможет штамповать запросы like a sir
а еще можно не городить велосипед и использовать PKCS #11 :)
Sign up to leave a comment.
Использование криптографических функций, реализованных на аппаратном токене в web-приложениях