Первая часть моего повествования заканчивалась поступлением в Военную орденов Ленина, Октябрьской Революции и Суворова академию им. Ф. Э. Дзержинского (сокращённое название ВА им. Ф. Э. Дзержинского, ВАД или просто Дзержинка). Логотип второй части напоминает мне мои первые шаги на пути программиста. Это, прежде всего, годы учёбы в Дзержинке, куда я поступил на второй факультет, на котором готовили специалистов по автоматизированным системам управления ракетными комплексами. На факультете для курсантов было две профилирующие кафедры. Кафедра №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>

САИПР — генетический код части"
Л.И.Волков, начальник 4 ЦНИИ МО

В названии статьи объединены заголовки двух публикаций, появившихся в далеком 1994 году в газетах «Московский воин» и «Красная Звезда». Основой публикаций стало интервью, которое взял у меня военный корреспондент подполковник Александр Бежко.
И вот эти две публикации попались мне на глаза:

Основной работой при создании утилиты cryptoarmpkcs было не разработка кода или графического интерфейса, а работа с ASN1-структурами. Именно в этих структурах хранятся сертификаты x509v3, электронные подписи документов (PKCS#7, CMS), запросы на сертификаты (PKCS#10, CSR), открытые и закрытые ключи, защищенные контейнеры PKCS#12/PFX, списки отозванных сертификатов CRL и штампы времени для электронной подписи, запросы и ответы OCSP и так далее и тому подобное. Постоянно приходилось просматривать уже имеющиеся структуры для понимания того как это делали другие, просматривать только что собранные самим AN1-структуры. Процесс понятен. Но поскольку я работаю на Linux (сейчас это Mageia, и код для Windows тоже готовлю на Linux), то под рукой из доступных средств разбора ASN1-структур были утилиты openssl и derdump из пакета NSS. Лично мои предпочтения были на стороне derdump. Именно она и стала прототипом рассматриваемой здесь утилиты derdump.tcl/tclderdump для просмотра ASN1-структур. И если вы сравните вывод утилиты derdump из пакета NSS и утилиты derdump.tcl, то вы практически не увидите различий:

Вот мы и добрались до создания самоподписанных сертификатов.
Где применяются самоподписанные сертификаты? Конечно, с самоподписанным сертификатом вы не сможете зарегистрироваться на сайте Госуслуг или подать подписанную декларацию в ФНС. Но для внутрикорпоративного документооборота их вполне можно использовать. Можно также использовать их для защиты личной почтовой переписки, в VPN-сетях и т.п. Но наиболее часто используют самоподписанные SSL-сертификаты для обеспечения защищенного доступа по https-протоколу к Web-приложениям. Самым популярным средством для создания самоподписанных сертификатов остается OpenSSL. Процедура получения SSL-сертификатов с помощью того же OpenSSL хороша описана здесь. Но там вы не найдете упоминая о ГОСТ-овых сертификатах, о токенах PKCS#11 и т.п. Здесь мы рассмотрим простой графический интерфейс, который позволяет получать сертификаты на базе ГОСТ Р 34.10-2012 и без всякого использования OpenSSL.

Предисловие

Я несколько раз в своих комментариях ссылался на книгу Эндрю Таненбаума «Operating Systems Design and Implementation» на ее первое издание и на то, как в ней представлен язык Си. И эти комментарии всегда вызывали интерес. Я решил, что пришло время опубликовать перевод этого введения в язык Си. Оно по-прежнему актуально. Хотя наверняка найдутся и те, кто не слышал о языке программировании PL/1, а может даже и об операционной системе Minix.

Это описание интересно также и с исторической точки зрения и для понимания того, как далеко ушел язык Си с момента своего рождения и IT-отрасль в целом.