Начал разбираться с проверкой цифровых подписей в документах налоговой, не понравилось, не пошло.. Переключился на цифровую подпись файлов в линуксе, GnuPG.
Меня почему-то беспокоит, что подпись есть, а как она формируется я не знаю, еще не знаю откуда она взялась и кто ее контролирует. Вдруг мне система начинает задавать вопросы: доверять этому отпечатку подписи или нет?! Стал разбираться.
Открыл стандарт [RFC 4880], открыл проект gpg/GnuPG, посмотрел что пишет Вернер Кох в драфте очередной переработки на стандарт OpenPGP [RFC 4880]. Написал свой собственный парсер цифровой подписи. Хочу поделиться мыслями и впечатлениями.
Кому-то лень развивать формат OpenPGP
Мне хотелось увидеть цифровую подпись Гост, потому что Митя занимается внедрением цивровой подписи ГОСТ в библиотеку libgcrypt, на базе которой работает GnuPG.
Каково было обнаружить, что ничего нового в OpenPGP не поддерживается. В основном это упирается в стандартизацию и документацию. Библиотека libGCrypt поддерживает множество разных подписей и дайджестов, включая Китайские SM и Российские ГОСТ. НО все уперлось в то, что в GnuPG не описаны идентификаторы этих дайджестов подписей.
Пока писал программку не оставляет чувство, что это зря забытая технология. Нет, но почему забытая?! PGP ключи используются для подписи программ в множестве дистрибутивов Linux, в MSYS2. Однако, тут в чем беда, я хочу криптографию на бублике и хеши ГОСТ, а мне предлагают RSA и SHA256. Я не хочу, чтобы GnuPG умер, надо в него для долгой жизни добавить еще идентификаторов алгоритмов.
Инфраструктура OpenPGP
На чем держится все? На доверии, самоподписанные ключи разработчиков попадают в дистрибутив и распространяются с обновлением дистрибутива. Кроме того есть возможность находить сервера для проверки сертификатов через DNS записи зоны - но это скорее корпоративный стиль, вряд ли возможно поддержать такой способ в Linux. Нужен децентрализованный способ распространения и хранения ключей. Еще одна возможность - это списки доверенных серверов хранения ключей, которые можно поместить в сертификацию.
Сертификация
Я занимаюсь реверс инжинирингом. Не претендую на истину. Мое мнение - собственное, основано на том, что я вижу в коде. А вижу я свободно компануемую форму, которая называется "сертификация". В отличие от сертификатов x509, сертифицируется последовательность записией. Сертифицируется цифровой подписью. Кодирование очень простое, не сильно структурированное. Такое кодирование можно поддержать в микронтроллере с малым объемом памяти. Ничего лишнего: публичный ключ, идентификатор подписи, и подпись. Лаконично. Моя реализация, которая умеет разбирать формат и проверять сертификацию и присоедиенные подписи (detached-sign) укладывается в 800 строк кода - вся утлита такого размера. При этом, со второй попытки могу написать реализацию раза в три короче, если выкинуть вербозность. Я увидел, что формат хорошо приспоосблен для общения между децентрализованными узлами: не текстовый, не сложный, можно построить что-то типа блок-чейна. Вторая особенность имеет возможность меняться без перевыпуска ключей, т.е. если узел в сети решил, что доверяет новому серверу ключей, то для этого не надо перевыпускать сертификат. Почему, потому что ключ идентифицируется по отпечатку, отпечаток выполняется от открытого ключа, только от самого ключа, даже не от имени владельца. Уупс. А что, можно переименовать владельца ключа без перевыпуска? ДА. Я смотрю формат. Вижу, что ключ идентифируется отпечатком, по отпечатку я ищу ключ в связке или на сервере ключей. Файл подписи содержит имя владельца и разные реквизиты, которые подписаны и подпись сходится, сертификация сходится - подмена состоялась, можно сказать владелец подписал. Тоже относится и к дате ключа и сроку действия. Поля подписаны, но не ясно как им доверять. Надо читать мануал...
Сертификация множества устройств для совместной работы
Я вообще-то представляю себе множество ботов, которым надо выстраивать общение между собой. Когда думаю про ботов, думаю про криптографию, блок-чейн, цепочки доверия. PGP очень даже подходит. Устройство регистрируется со своим сертификатом самоподписанным, со своим идентификатором, рождается с несколькими ключами, и использует их для интеграции в сообществе. Нужен ключевой сервер (Who has, Who Is,.. ) и алгоритмы привязки и миграции устройства между серверами на основе доверия и подписи. [GNU Privacy Handbook] -- досуг настал, пошел изучать концептуальные вещи, как реализовать общение между ботами, как выстраивать цепочки доверия и как менять принадлежность узла ключевому серверу, как переименовать и все такое, без смены ключа.
Цифровая подпись файлов (Detached-sign)
Ниже привожу вывод моей программы по разбору сертификатов для сочетания алгоритмов RSA и SHA256, которые GPG использует по умолчанию. Формат PGP состоит из склеенных в определенной последовательности пакетов PGP. В последовательности встречаются цифровые подписи, которые сертифицируют предыдущие пакеты по правилам прописанным в стандарте [RFC4880].
Для проверки подписи файла понадобится сертификат открытого ключа. Сертификат импортируется в программу из GPG. Аналогично можно импортировать закрытый ключ и передать в другую программу или на другой компьютер. Подписываются три пакета: имя владельца, открытый ключ и субпакеты сертификации. Кстати, закрытая часть ключа не подписывается, она сама себе попдись от открытого ключа, можно проверить соответствие закрытого ключа и отокрытого математически.
## Пример. Импорт и Сертфикация закрытого ключа
$ ./mypgp -v --import=secret_key.pgp
-- PGP format --
type 5: 'Secret-Key Packet', Format v4, length=1414
Created: 2021-06-03 15:03:04
Key Alg: (1) RSA
RSA modulus n:
E2 F0 68 AF . . . E5 B2 85 C1
RSA public exp:
01 00 01
-- PGP format --
type 13: 'User ID Packet', length=52
User ID: Anatoly Georgievskii <anatoly.georgievski@gmail.com>
-- PGP format --
type 2: 'Signature Packet', Format v4, length=468
-- version 4
-- sign type(19) Positive certification of a User ID and Public-Key packet
-- pkey alg (1) RSA
-- hash alg (8) SHA256
-- hash subpacket len 62-- Хешируемые записи
-- 'Issuer fingerprint' subpacket(33), len=22
Fingerprint: -- расчитан от открытого ключа.
04 750E . . . 05C1B196BBF9564E
-- 'Signature Creation Time' subpacket(2), len=5
Creation : 2021-06-03 15:03:04
-- 'Key Flags' subpacket(27), len=2
-- 'Key Expiration Time' subpacket(9), len=5
-- 'Preferred Symmetric Algorithms' subpacket(11), len=5
Algorithms: AES256 AES192 AES128 TDES
-- 'Preferred Hash Algorithms' subpacket(21), len=6
Algorithms: SHA512 SHA384 SHA256 SHA224 SHA1
-- 'Preferred Compression Algorithms' subpacket(22), len=4
Algorithms: ZLIB BZip2 ZIP
-- 'Features' subpacket(30), len=2
-- 'Key Server Preferences' subpacket(23), len=2
digest:-- Хеш от записей: UserId|PublicKey|hash_subpackets
B5D1 9DFF . . . 1CA0 CFEE
-- data subpacket len 10
-- 'Issuer' subpacket(16), len=9
-- issuer Key Id: 05C1B196BBF9564E
-- 8 байт в конце Fingerprint образуют уникальный идентификатор ключа
-- hash octets.. B5D1 -- 2 байта Хеша вписаны в формат
-- sign len 3070 bits:
28 02 10 26 . . . 3B 20 F8 5C
-- Сертификация пройдена! Выполнена проверка подписи секретного ключа.
Cосуществование форматов OpenPGP и CMS
Есть предложение! Хочется установить соотвествие между сертифкацией OpenPGP и (detached) цифровыми подписями в формате CMS. Возможно ли использовать ключи и сертификаты x509 для генерации и проверки цифровой подписи PGP?
Это два действия.
1) Экспорт открытого ключа из x509 в PGP формате, при этом надо договориться об использовании и соответствии полей сертификата x509 и субпакетов PGP.
2) Генерация цифровой подписи detached-sign в формате PGP.
Цепочки доверия
Доверие сертификации - одноходовое. Если подпись авторитетная, то доверие есть. Система импортирует ключ, и оценивает авторитетность подписи по цепочке до самоподписанного доверенного сертификата. Доверенные сертификаты (ключи и атрибуты ключей) живут в связке (keyring). Связка ключей должна вызывать доверие.
Для примера нужна модель. Каждая сущность способная порождать файлы должна обладать возможностью сертификации. Мы говорим об операционной системе, которая порождает данные, сервисной программе, учетной записе пользователя. Данные можно порождать лично, или делегировать эту способность боту. Мы говорим о файловой системе, в которой необходимо хранить подписи и историю позволяющую выполнить проверку цепочки доверия. Допустим я беру всю файловую систему целиком без пользователя и без компьютера. Целостность нарушена, но может быть проверена и востановлена. Целостность подтверждается цепочками сертификации файлов. Все чего мы при этом лишились - это закрытого ключа. Структура файловой системы должна поддаваться анализу. Еще лучше, если анализ целостности позволяет выстраивать распределенную файловую систему. Например, представляем себе вместо установки операционной системы(вместо копирования файлов), копирование идентификаторов и сертификацию дистрибутива и серверов. Я пытаюсь запустить программу, которой нет на моем компьютере, но ее можно найти по идентификатору, по имени, с учетом сертификации в дистрибутиве. Каждый файл имеет происхождение, авторство. Каждое изменение файла или его части имеет сертификацию. . . . {дописать}
Комментариев нет:
Отправить комментарий