Хабрахабр

Криптографический АРМ на базе стандартов с открытым ключом. Конфигурирование токенов PKCS#11

Еще раз просмотрев функционал утилиты cryptoarmpkcs, обратил внимание на то, что она, в основном работая с криптографическими токенами/смаркартами PKCS#11, не имеет встроенного функционала для их конфирурирования. Речь идет об инициализации токенов, установки PIN-кодов и т.п. И было решено добавить этот функционал. Первым делом для этого пришлось расширить функционал пакета TclPKCS11, библиотека которого написана на языке Си.

Новые функции пакета TclPKCS11

В пакете появились три новые функции:

::pki::pkcs11::inittoken <handle> <slotId> <SO-pin> <label for token>

::pki::pkcs11::inituserpin <handle> <slotId> <SO-pin> <USER-pin>

::pki::pkcs11::setpin <handle> <slotId> <so | user> <oldpin> <newpin>

Первая функция ::pki::pkcs11::inittoken предназначена для инициализации токена. Надо иметь ввиду, что если эта функция применяется к рабочему токену, то все имеющиеся на нем объекты будут уничтожены.

Вторая функция ::pki::pkcs11::inituserpin предназначена для первичной инициализации пользовательского PIN-кода (USER PIN).

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

Эта функция позволяет менять как пользовательский PIN-код, так и SO-PIN. Для смены PIN-кодов используется третья функция, а именно ::pki::pkcs11::setpin.

Но если вы выполните переинициализацию токена, то вновь получите дефолтный SO-PIN. При этом следует также иметь ввиду, что восстановить первоначальный SO-PIN (default), токены, как правило, не возволяют. Реализацию пакета TclPKCS11 можно посмотреть на github-е.

Теперь, имея на руках, пакет TclPKCS11 с новыми функциями, не составило труда реализовать GUI для этих функций:

Учебные токены

Но прежде чем ими воспользоваться, обратим внимание на то, что в функционал утилита добавлена еще одна кнопка «Создать Токены».

И вот именно для того, чтобы утилиту можно было легко использовать в учебных целях, прежде всего, и появилась кнопка «Создать Токены». Это связано с тем, что не у всех есть аппаратный токен PKCS#11 с поддержкой российской криптографии, а если есть, то боязно его использовать в учебных целях. Нажав на эту кнопку, вы увидите инструкцию как получить либо программный либо облачный токены:

2. Эти токены реализуют самые последние рекомендации ТК-26 для PKCS#11 v. 40.

Скачиваем необходимый дистрибутив, распаковываем при необходимости и запускаем. Рассмотрим вкратце как получить облачный токен. Если у нас нет облачного токена, то мы получим следующее сообщение:

Поскольку у нас нет еще облачного токена, то нажимаем кнопку «Регистрация в облаке»:

После заполнения полей, нажимаем кнопку «Готово»:

Поскольку мы ведем речь прежде всего об обучении, то можно сохранить пароль для доступа к облаку (но не токену) на рабочем месте:

Инициализация токена

Теперь, когда, мы зарегистрировались в облаке, мы выходим из утилиты guils11cloud_conf и возвращаемся к утилите cryptoarmpkcs для конфигуирования облачного токена. Здесь надо отметить, что библиотека облачного токена будет сохранена в папке ls11cloud, созданной в домашнем каталоге пользователя. Именно эту библиотеку и надо будет выбрать в качестве библиотеки PKCS#11 для облачного токена. После выбора библиотеки можно посмотреть и поддерживаемые криптографические механизмы:

Выбираем операцию «Инициализация токена», заполняем поля (вспоминаем, что дефолтный SO-PIN — 87654321) и нажимаем кнопку «Выполнить операцию»: Возвращаемся к инициализации облачного токена нажав кнопку «Конфигурирование токена».

Но не забудьтк сменить SO-PIN и переодическм менять пользовательский PIN-код. Все токен готов к работе. Желающие могут попробовать. По аналогичной схеме можно создать и программный токен. Теперь мы можете хранить на них свои личные сертификаты, подписывать документы, делать все то, о чем писалось в этой серии статей.

Ближайшие нововведения в ИОК/PKI

Госдума 7 ноября 2019 года приняла в первом чтении поправки в закон «Об электронной подписи». Этот поправки касаются всех организаций и ИП, поскольку изменятся правила выдачи электронных подписей.

И только используя эти сертификаты можно будет ставить
усиленную квалифицированную электронную подпись (Cades-XLT1). Если я правильно все понял, то квалифицированные сертификаты юридические лица и индивидуальные предприниматели смогут получать только в Федеральной налоговой службе, а финансовые организации — в ЦБ РФ.

Аккредитованные Минкомсвязью удостоверяющие центры (УЦ) смогут выдавать такие сертификаты только физическим лицам.

При этом требования к УЦ сильно изменятся: собственный капитал должен быть увеличен с 7 млн до 500 млн — 1 млрд, размер страховой ответственности увеличивается с 30 млн до 300-500 млн рублей, срок аккредитации сокращается с 5 лет до 3 лет.

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

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

И вот тут утилита cryptoarmpkcs будет очень и очень кстати, поскольку ее функционал позволяет ставить под документом несколько подписей, а также просматривать кто и когда подписал документ:

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть