Прошло без малого пять лет как я впервые столкнулся с интегрированной средой разработки программ на tcl/tk TKproE-2.20. В апреле 2021 года вышла новая версия этого продукта — TKproE-2.30 и я полностью погрузился в её мир. Он меня заворожил. Название TKproE является аббревиатурой от TCL/TK Programming Environment. TKproE — это интегрированная среда разработки программ для языка сценариев TCL/TK. Сам TKproE полностью написан на языке TCL/TK. В преамбуле к TKproE подчёркнуто, что он поддерживает быструю разработку сложных графических пользовательских интерфейсов.

Что же принципиально нового появилось в новой версии по сравнению с версией 2.20 помимо нового логотипа?

После опубликования статьи, посвящённой требованиям Приказа №795 ФСБ России в редакции от 29 января 2021 года, меня не покидало чувство её незавершённости. Это чувство было связано с тем, что в статье ни слова не было сказано про утилиту CAFL63, которая позволяет разворачивать удостоверяющие центры. И естественным является то, что её тоже необходимо привести в соответствие с новыми требованиями.

7 сентября 2021 года мне пришло электронное письмо:

fsb795
Добрый день.
не планируете библиотеку подправить под свежие изменения в приказе 795 ?

Было понятно, что речь идет о пакете fsb795, написанном на Python для разбора квалифицированных сертификатов. Требования к составу и форме квалифицированного сертификата установлены Приказом ФСБ России от 27.12.2011 №795. Но 29 января 2021 года в этот приказ были внесены изменения. Именно об этих изменениях мне и напомнил автор письма. Письмо я получил 7 сентября, а изменения вступили в силу 1-го сентября 2021 года. В этот период времени я был увлечён написанием статьи, связанной с пятидесятилетием окончания Казанского суворовского военного училища и выбора мною стези программиста:

Если первая часть моего повествования заканчивалась поступлением в Военную орденов Ленина, Октябрьской Революции и Суворова академию им. Ф. Э. Дзержинского (сокращённое название ВА им. Ф.Э. Дзержинского, ВАД или просто Дзержинка), то вторая часть закончилась отправлением поезда «Москва-Рига», в котором ехал я. Логотип третьей части возвращает меня в годы моего становления как программиста.

I. 649-й отдельный пункт разведки радиоизлучений космического пространства

Итак, промозглой осенью 1976 года я прибыл в Ригу. В Риге пересел на поезд до города Вентспилс. Прибыв в Вентспилс, я зашёл к коменданту станции, где мне показали машину, которая поедет в часть. Оказалось, что каждый день здесь дежурила машина из гарнизона Вентспилс-8. Старшим машины был прапорщик, который довёз меня до части и помог устроиться в гостинице. Была уже ночь. Всю дорогу справа и слева от нас был хвойный лес. Для себя я сразу определился с названием – прибалтийская тайга. Я понял, что меня не обманули, когда говорили, что я буду служить в глухом лесном месте:

Первая часть моего повествования заканчивалась поступлением в Военную орденов Ленина, Октябрьской Революции и Суворова академию им. Ф. Э. Дзержинского (сокращённое название ВА им. Ф. Э. Дзержинского, ВАД или просто Дзержинка). Логотип второй части напоминает мне мои первые шаги на пути программиста. Это, прежде всего, годы учёбы в Дзержинке, куда я поступил на второй факультет, на котором готовили специалистов по автоматизированным системам управления ракетными комплексами. На факультете для курсантов было две профилирующие кафедры. Кафедра №23 готовила военных инженеров по эксплуатации вычислительной техники, а кафедра №25 готовила военных инженеров-программистов. Именно с сентября 1971 года в академии начали готовить военных инженеров-программистов из курсантов. Наш курс состоял из пяти отделений, в трёх из которых готовились военные инженеры по эксплуатации вычислительной техники, а в двух отделениях готовились будущие военные инженеры-программисты. Я проходил обучение в отделениях программистов. Почему во множественном числе? Просто обучение я начинал в отделении А, а затем меня перевели в отделение В. Поэтому оба отделения для меня стали родными. Именно эмблема кафедры №25 и находится в центре логотипа статьи. С одной стороны, с эмблемой всё понятно, а с другой стороны, сегодня она требует некоторого пояснения. Символы «к. 25» — ясно, что это кафедра №25. Символы «МО» являются аббревиатурой от словосочетания «Математическое Обеспечение». В те далёкие времена было принято говорить не программное обеспечение ЭВМ, а именно математическое обеспечение ЭВМ. Ну и последнее, символы «МО» располагаются поверх одного из основных носителей (наряду с перфокартами) программ и вообще данных – перфоленты. Сегодня трудно представить, что и программы и исходные данные для них готовились не в файлах на каком-нибудь носителе (диски, флешки и т.д.), а готовились на бумажном носителе, будь то перфолента или перфокарта

Логотип статьи определяет три, как временные, так и географические, точки на моём жизненном пути, через которые лежал мой путь в страну под названием «Программирование». В городе Чебоксары, на родине легендарного комдива Гражданской войны В.И.Чапаева, прошло моё детство (1954-1968 г.г.), там я закончил 8 классов средней школы №6. В 1968 году я переместился в следующую географическую точку, в г. Казань, в Казанское суворовское военное училище (КзСВУ). После окончания КзСВУ в 1971 году мой путь лежал в столицу нашей Родины в Москву, в Военную орденов Ленина, Октябрьской Революции и Суворова Академию им. Ф.Э.Дзержинского (сокращённое название ВА им. Ф.Э.Дзержинского или ВАД), которой в 2020 году исполнилось 200 лет со дня ее основания. И 22 июня в трагический для нашей страны день в 1941 году и знаковый для меня в 1976 году я окончил ВА им. Ф.Э.Дзержинского и получил диплом по специальности «Программирование» с присвоением квалификации военного инженера программиста:

I. Предисловие

Всё началось с того, что 26 января 2021 года в одноклассниках мне пришло сообщение от Валерия Иванова:

Владимир, в ВА им. Дзержинского вы когда учились и в какой группе?

Я написал Валерию:

1971-1976 г.г. 25 кафедра, НК-25 — Захаров В.Н., начальник курса — п-к Григорьев, курсовой — Кузнецов Ю.М. 1979-1982 г.г. адъюнктура 25 кафедры

И от него пришёл ответ:

Володя, я Иванов Валерий Петрович, сверхсрочник, 23 группа....

Да, я помнил его. Он был единственным сверхсрочником на нашем курсе в Военной Академии им. Ф.Э. Дзержинского (сокращённо ВАД).
В те годы Академия им. Ф.Э. Дзержинского располагалась в столице нашей Родины Городе-Герое Москве на набережной Москвы- реки в Китай-городе:

Инфраструктура открытых ключей (PKI/ИОК) включает в себя множество различных объектов и механизмов работы с ними, а также протоколы взаимодействия объектов друг с другом (например, протоколы TLS, OCSP). В число объектов ИОК входят запросы на сертификаты (PKCS#10) и сами сертификаты x509, ключевые пары (приватные и публичные ключи), подписанные и зашифрованные документы (PKCS#7, CMS), защищенные контейнеры для хранения приватных ключей (PKCS#8) и личных сертификатов с ключами (PKCS#12) и т.д. В число механизмов входят не только криптографические функции, которые позволяют шифровать и подписывать документы по различным алгоритмам, но и функции, формирующие конечные объекты ИОК в соответствии со стандартами (сертификаты, запросы, подписанные/зашифрованные документы, пакеты протоколов и т.д. и т.п.). Да и как не вспомнить центральный объект ИОК/PKI — УЦ.

Сегодня уже трудно представить деловую жизнь страны без ИОК, без сертификатов x509 (без квалифицированных сертификатов), без сервисов ГОСУСЛУГИ и ФНС, где документы принимаются в электронном виде с электронной подписью. И все больше документов возвращаются к гражданину тоже в электронном виде с электронной подписью. Судопроизводство уже также невозможно представить без электронной подписи.

Подошло время рассказать как была добавлена поддержка российской криптографии в проект PyKCS11. Всё началось с того, что мне на глаза попалась переписка разработчика проекта PyKCS11 с потенциальными потребителями по поводу возможной поддержки алгоритмов ГОСТ Р 34.10-2012 в нём. В этой переписке автор PkCS11 сказал, что не собирается включать поддержку российских криптоалгоритмов до тех пор, пока они не будут стандартизованы.
Ту же самую мысль он выразил и мне, когда я предложил ему это сделать. И не просто сделать, а выслал соответствующий программный код:

В предыдущей статье был представлен модуль pyp11, написанный на языке Си и обеспечивающий поддержку токенов PKCS#11 с российской криптографией. В этой статье будет рассмотрен класс Token, который позволит упростить использование функционала модуля pyp11 в скриптах, написанных на Python-е. Отметим, что в качестве прототипа этого класса был взят класс token, написанный на TclOO и который используется в утилите cryptoarmpkcs:

Поддержка криптографических токенов PKCS#11 с российской криптографией в скриптовых языках (Python, Tcl) давно находится в моём поле зрения. Это, прежде всего, пакет TclPKCS11 и реализованная на его базе кроссплатформенная утилита cryptoarmpkcs. Утилита cryptoarmpkcs написана на tcl/tk и функционирует на различных платформах, включая Android. Пакет TclPKCS11 версии 1.0.0 заточен на работу именно с токенами, поддерживающими ГОСТ Р 34.11-2012 и ГОСТ Р 34.10-2012. Он позволяет генерировать ключевые пары по ГОСТ Р 34.10-2012 с длиной закрытого ключа 256 и 512 бит, формировать и проверять электронную подпись. Все это можно наглядно видеть в утилите cryptoarmpkcs, в которой в качестве криптодвижка используется именно этот пакет:

Часто приходится слышать, что скриптовому языку Tcl не хватает поддержки объектно-ориентированного стиля программирования. Сам я до последнего времени мало прибегал к объектно-ориентированному программированию (ООП), тем более в среде Tcl. Но за Tcl стало обидно. Я решил разобраться. И оказалось, что практически с момента появления Tcl, появилась и возможность объектно-ориентированного программирования в его среде. Всё «неудобство» заключалось в необходимости подключить пакет с поддержкой ООП. А таких пакетом было и есть несколько, как говорится на любой вкус. Это и Incr Tcl, Snit и XoTcl.

Программисты, привыкшие к языку C++, чувствуют себя как дома, программируя в среде Incr Tcl. Это было одним из первых широко используемых расширений для OOП на основе Tcl.

Пакет Snit в основном используется при построении Tk-виджетов, а XoTcl и его преемник nx предназначались для исследования динамического объектно-ориентированного программирования.

Обобщение опыта, полученного при использовании этих систем, позволило внедрить ООП в ядро Tcl начиная с версии 8.6. Так появился TclOO — Tcl Object Oriented.

Сразу отметим, что Tcl не просто поддерживает объектно-ориентированное программирование, а в полном смысле динамическое объектно-ориентированное программирование.

Второго ноября 2020 года я прочитал на хабре публикацию SLY_G «Восхождение интернета, ч.2: появление частных и публичных компаний». Меня поразил абзац:

Летом 1986 года сенатор Эл Гор (Альберт Арнольд Гор—младший) из Теннеси ввёл поправку к закону Конгресса, позволяющую выделить бюджет для Национального научного фонда США (NSF). Он призвал федеральное правительство изучить возможности «коммуникационных сетей для связи суперкомпьютеров в университетах и федеральных исследовательских центрах». …
Одна из многообещающих технологий – разработка оптоволоконных систем для передачи голоса и данных.

Поразился я тем, что именно в это же время участвовал в подготовке материалов для Постановления ЦК КПСС и СМ СССР. Это постановление готовилось во исполнение Решения ГК СМ СССР по ВПВ от 18.03.85 года №79:



Этим Решением предусматривалась организация работ по противодействию стратегической оборонной инициативе (СОИ) США. СОИ США – это так называемые «звездные войны». Надо сказать, что военно-политическая обстановка в середине 80-х прошлого столетия лично мне напоминает сегодняшний день. Тоже противостояние с США, те же санкции, та же сложная экономическая ситуация в стране. И вот в этих тяжелых экономических условиях надо было найти решение, которое могло сохранить паритет с США.

О какой медали идет речь в заголовке? Речь идет об инфраструктуре открытых ключей (Public Key Infrastructure — PKI/ИОК) на базе стандартов криптографии с открытым ключом (Public Key Cryptography Standards — PKCS). Инфраструктура открытых ключей включает в себя множество различных объектов и механизмов работы с ними, а также протоколы взаимодействия объектов друг с другом (например, протоколы TLS, OCSP). В число объектов ИОК/PKI входят сертификаты x509 и ключевые пары (приватные и публичные ключи), подписанные и зашифрованные документы (pkcs#7, CMS), защищенные контейнеры для хранения приватных ключей (pkcs#8) и личных сертификатов с ключами (pkcs#12) и т.д. В число механизмов входят не только криптографические функции, которые позволяют шифровать и подписывать документы по различным алгоритмам, но и функции, формирующие конечные объекты ИОК в соответствии со стандартами (сертификаты, запросы, подписанные/зашифрованные документы, пакеты протоколов и т.д. и т.п.). Да, и как не вспомнить центральный объект ИОК/PKI — Удостоверяющий Центр (УЦ).

Как все начиналось

В самом начале периода самоизоляции мне на почту пришло письмо:



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

Чем дольше я пишу различные программы на tcl/tk, тем больше восхищаюсь его возможностями и продуманностью. Но была одна вещь, которая не давала мне покою до последнего времени. При разработке GUI часто приходится пользоваться файловым проводником (tk_getSaveFile, tk_getOpenFile или tk_chooseDirectory). И если на платформах Windows или OS X, загружается нативный файловый проводник этих платформ, то на платформах Linux загружается проводник от tcl/tk (ну нет в Linux нативного проводника):

С точки зрения PKCS#11 интерфейса, использование облачного токена не отличается от использования аппаратного токена. Для использования токена на компьютере (а у нас пойдет речь о платформе Android) необходимо иметь библиотеку для работы с токеном и собственно подключенный токен. Для облачного токена нужно тоже самое — библиотеку и подключение к облаку. В качестве такого подключения выступает некий конфигурационный файл, в которой прописывается адрес облака, в котором хранятся токены пользователей.

Проверка статуса криптографического токена

Итак, скачиваем обновленную версию утилиты cryptoarmpkcs-A. Устанавливаем и запускаем приложение и переходим в основное меню. Для дальнейшей работы необходимо выбрать токен, криптографические механизмы которого будут задействованы (напомним, что при работе с PKCS12 токен не нужен):



Скриншот наглядно показывает, что происходит при нажатии на ту или иную кнопку. Если нажать на кнопку «другой токен», то будет предложено выбрать библиотеку PKCS#11 для вашего токена. В двух других случаях выдается информация о статусе выбранного токена. Как подключается программный токен говорилось в предыдущей статье. Сегодня нас интересует облачный токен.

Регистрация облачного токена

Переходим на вкладу «Подключение Токенов PKCS#11», находим пункт «Создание облачного токена» и скачиваем приложение LS11CloudToken-A

Подошло время задействовать криптографические механизмы PKCS#11 и на платформе Android. Кто-то может сказать, что нет аппаратных токенов для Android. Но, если это и так, то это только временное явление. Но уже сегодня можно поставить программный токен или использовать облачный токен. Поскольку утилита cryptoarmpkcs-A разрабатывается для платформы Android с использованием Androwish на скриптовом языке Tcl/Tk, то для подключения токенов используется пакет TclPKCS11 версии 1.0.1.

При этом никакой переработки пакета не потребовалось. Все что было сделано, это был добавлены в проект скрипт для сборки библиотеки пакета, написанной на языке Си, под Android и сам дистрибутив библиотеки. В этот же проект было решено добавить и библиотеки программного ls11sw2016 и облачного ls11cloud токенов для различных платформ.

Пришло время продемонстрировать как криптографический АРМ на базе стандартов с открытым ключом cryptoarmpkcs работает на одной из мобильных платформ, а именно Android.

Концепция, которая закладывалась при разработке утилиты cryptoarmpkcs, состоит в том, что пользователь должен испытывать минимум неудобств при создании и проверке электронной подписи. Именно поэтому мы предлагаем в качестве ключевого носителя для личного сертификата использовать криптографические токены PKCS#11 и/или защищенные контейнеры PKCS#12. Надо сказать, что использование PKCS#12 во многих случаях оказывается чуть ли не единственно возможным, например, когда у тех же токенов 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>