Что общего у ЭЦП и https?

и как это работает

Опубликовано: 28.09.2023

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

Все мы хорошо знаем, что http протокол предусматривает передачу данных в открытом виде. Это означает, что в процессе передачи траффика от одного компьютера к другому злоумышленник, имеющий доступ к транзитному устройству, может никак не напрягаясь этот траффик просмотреть, сохранить, и тому подобное. Этот метод познания называется сниффинг, а его условия - mitm. Транзитных устройств по пути следования http пакетов может быть, например, одно - роутер, как в случае простейшей корпоративной или домашней сети, а может быть немало, как в случае использования "обычного" интернета. Отметим, что доступ к таким транзитным устройствам могут иметь не только обычные злоумышленники, но и правоохранительные органы. Кроме того, все мы хорошо помним, что по закону от 6 июля 2016 года №374-ФЗ операторы, в общем случае, надёжно хранят весь траффик в течение 6 (шести) месяцев, а метаинформацию 3 (три) года.

В какой-то момент, когда у нас отрастают усы, и мы не на шутку становимся с ними сами, нам приходит в голову (и не всегда как фактор постановки диагноза "параноидная шизофрения"), что неплохо бы сберечь ценные данные от просмотра чужаками. Но как это сделать простому гуманитарию в большом и запутанном мире информационных технологий? Если вы хотите знать, велком под кат.

Для решения означенной проблемы используется протокол https. S значит secure. Secure достигается путём зашифровки траффика передающим устройством и расшифровки принимающим. Процесс этот двунаправленный, и, значит, эти операции выполняют оба устройства. Рассмотрим простую клиент-серверную модель получения данных веб-сайта по протоколу https для их отображения браузером пользователя.

Вначале 2 определения:
1. Веб-сервер - программа, установленная на физический сервер, которая отвечает за предоставление контента сайта программам, которые ей направят соответствующий запрос, например, браузерам пользователей.
2. Веб-сайт - в простом случае это папка с текстами, картинками и разметкой, которая доступна веб-серверу; веб-сервер считывает содержимое этой папки и передаёт обратившимся к нему программам.

Вот мы открыли веб-сайт.

Если мы работаем по протоку https, то в самом упрощённом виде этот сайт попал к нам в экран следующим образом:
- наш браузер направил веб-серверу запрос на предоставление того сайта, который указан в адресной строке браузера;
- веб-сервер считал папку с данными сайта, зашифровал эти данные и передал через сеть нашему браузеру;
- наш браузер эти данные расшифровал и отобразил на экране.

Чтобы понять как при этом осуществлялось шифрование, необходимо ввести несколько понятий (в наглядно-образном формате):
1. Шифрование - процесс преобразования исходных данных посредством какого-нибудь алгоритма в лишённый самостоятельного смысла набор знаков таким образом, чтобы при обратном преобразовании посредством этого алгоритма получить исходные данные;
2. Ключ шифрования - уникальный элемент алгоритма шифрования, его переменная часть; неотъемлемая часть условия преобразования данных; существует в виде информации, например, в форме файла;
3. Симметричное шифрование - алгоритм шифрования предусматривает зашифрование и расшифрование исходных данных одним и тем же ключом шифрования.
4. Асимметричное шифрование - алгоритм шифрования предусматривает зашифрование исходных данных одним ключом, а расшифрование другим ключом, парным первому, то же можно произвести и наоборот - зашифровать вторым ключом, а расшифровать первым; нельзя расшифровать тем же ключом, которым данные зашифрованы;
5. Приватный ключ шифрования - один из парных ключей, используемых в ассиметричном шифровании, который хранится его владельцем в тайне для достижения таким организационным путём цели шифрования.
6. Публичный ключ шифрования - другой ключ из двух парных ключей, используемых в ассиметричном шифровании, который должен быть доступен второй стороне процедуры обмена данными с использованием шифрования; он может быть доступен публично любому лицу - нет нужды хранить его в секрете.

Вот, что происходит на практике более детально, но всё же в упрощённом виде:
1. для веб-сервера для каждого сайта, который он предоставляет обратившимся программам по протоколу https, в физических недрах обеспечивающей его работу инфраструктуры доступны два указанных выше ключи - один тайный, второй публичный, который он предоставляет всем, кто обратится;
2. браузер пользователя направляет веб-серверу запрос на предоставление данных интересующего пользователя сайта;
3. веб-сервер предоставляет браузеру публичный ключ для интересующего сайта;
4. браузер пользователя получает этот публичный ключ, генерит ключ шифрования для симметричного алгоритма, шифрует этот ключ для симметричного алгоритма ключом для асимметричного алгоритма, который ему предоставил веб-сервер, отправляет сообщение с этим зашифрованным ключом для симметричного алгоритма на веб-сервер;
5. веб-сервер получает это сообщение с зашифрованным ключом для симметричного алгоритма; расшифровывает его с использованием приватного ключа, парного тому, который он ранее направил браузеру и с использованием которого браузер зашифровал сообщение; таким образом извлекает ключ симметричного шифрования; сохранение приватного ключа в тайне - организационное условие достижения целей шифрования.
6. теперь у браузера и веб-сервера есть один ключ для симметричного шифрования, который известен только им двоим (в условной норме, если посередине нет ssl-прокси, что актуально в корпоративных сетях, но это сейчас неважно);
7. веб-сервер и браузер приступают к процедуре обмена данными, зашифрованными посредством симметричного алгоритма, через цепочку недоверенного транзитного оборудования.

Но не всё так просто. Откуда в нашей упрощённой модели браузер знает, что имеет дело с веб-сервером, который работает на истинного владельца сайта? Для целей шифрования безразлично с использованием какой пары ключей осуществляется шифрование. Какой ключ веб-сервер пришлёт, с тем браузер и будет работать. Технически генерация пары ключей не составляет никакого труда. Например, с использованием консольной утилиты openssl. Кто угодно может сгенерить ключи. Таким образом, существует риск, что публичный ключ браузеру предоставил не настоящий веб-сервер, а веб-сервер злоумышленника, расположенный где-то в цепочке транзитного оборудования или за её пределами, на который злоумышленник просто завернул траффик от нашего браузера и теперь говорит, что это у него тут настоящий веб-сайт.

Для решения этой проблемы используют удостоверяющие центры.

Каким же образом?

Примерно таким же организационным, как обеспечивают цели асимметричного шифрования. Для этого международной некоммерческой тусовкой инженеров (ietf.org) разработан стандарт rfc2459 (https://www.ietf.org/rfc/rfc2459.txt), которым установлено понятие сертификата. По сути, это публичный ключ плюс дополнительная структурированная информация. Пункт 4.1 указанного rfc содержит описание полей такого информационного объекта:

Certificate  ::=  SEQUENCE  {
        tbsCertificate       TBSCertificate,
        signatureAlgorithm   AlgorithmIdentifier,
        signatureValue       BIT STRING  }

Значение tbsCertificate также должно иметь свою структуру:

TBSCertificate  ::=  SEQUENCE  {
        version         [0]  EXPLICIT Version DEFAULT v1,
        serialNumber         CertificateSerialNumber,
        signature            AlgorithmIdentifier,
        issuer               Name,
        validity             Validity,
        subject              Name,
        subjectPublicKeyInfo SubjectPublicKeyInfo,
        issuerUniqueID  [1]  IMPLICIT UniqueIdentifier OPTIONAL,
                             -- If present, version shall be v2 or v3
        subjectUniqueID [2]  IMPLICIT UniqueIdentifier OPTIONAL,
                             -- If present, version shall be v2 or v3
        extensions      [3]  EXPLICIT Extensions OPTIONAL
                             -- If present, version shall be v3
        }

Для понимания сути явления достаточно знать назначение следующих полей: SubjectPublicKeyInfo, subject, issuer, signatureValue.

SubjectPublicKeyInfo - это публичный ключ;

subject - именование владельца публичного ключа; может содержать имя сайта, для которого будет использоваться;

issuer - именование удостоверяющего центра;

signatureValue - доказательство удостоверяющего центра, указанного в поле issuer, того, что публичный ключ в поле SubjectPublicKeyInfo принадлежит лицу, указанному в поле subject.

Почему кто-либо должен верить доказательству в поле signatureValue и чем это доказательство является по сути?

По своей сути это доказательство является следующим (в идеализированном представлении):
1. subject генерит у себя на ноутбуке два асимметричных ключа для каких угодно своих целей;
2. приносит issuer`у один из этих ключей, публичный, и говорит: "сделай мне из этого ключа сертификат".
3. issuer сверяет фотографию в паспорте subject`а с его лицом (в России это уже может регулироваться русскими законами, однако, смотря для каких целей, во-первых, во-вторых, законодательно это далеко не всегда обязательно для практики), берёт у него его публичный ключ, заполняет все, какие надо, поля сертификата, помещает в поле SubjectPublicKeyInfo этот публичный ключ;
4. далее issuer берёт уже свой приватный ключ, берёт заполненный раздел TBSCertificate, зашифровывает своим приватным ключом заполненный раздел TBSCertificate, помещает эту зашифрованную информацию в поле signatureValue, раздел TBSCertificate в сертификате, при этом, по-прежнему остаётся доступным в открытом виде.
5. отдаёт сертификат subject`у.
6. теперь subject для выполнения процедур шифрования всем предоставляет не свой публичный ключ, а этот сертификат, содержащий его публичный ключ.

Что же делают все, чтобы удостовериться, что полученный сертификат не сделал себе сам указанный в нём subject, ранее просто создав ключи указанного в сертификате issuer`а (в пару кликов), с помощью приватного из которых сформировал поле signatureValue?

Как мы помним, расшифровать данные, зашифрованные конкретным частным ключом, можно только с помощью парного ему конкретного публичного ключа.

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

Итак, мы ввели в строке браузера доменное имя интересующего нас сайта, браузер выяснил у регистратора этого доменного имени ip-адрес веб-сервера, который отдаёт контент этого сайта, направил запрос этому веб-серверу на установление зашифрованного соединения по протоколу https, веб-сервер предоставил нашему браузеру сертификат, с использованием которого предлагает выполнить зашифрованный обмен информацией. Теперь, мы, в лице нашего браузера, хотим убедиться, что этот сертификат, включая содержащийся в нём публичный ключ, настоящий. Для этого мы должны расшифровать значение поля signatureValue и посмотреть, что же там написано.

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

При выпуске сертификатов ключей для веб-сайтов, минимальный объём проверки удостоверяющими центрами заключается в подтверждении того, что запрос на сертификат для доменного имени, которое будет указано в сертификате, поступил с ip-адреса, который по данным регистратора доменных имён (не будем тут про dns) однозначно соответствует данному доменному имени; это примерно как регистрация по смс - как телефон с номером, так и сервер с айпишником. Эта схема работает, поскольку по умолчанию доступ к указателю соответствия конкретного доменного имени конкретному ай-пи имеет только владелец этого доменного имени. Может быть, в этой схеме возможны какие-либо атаки, направленные на получение настоящего сертификата злоумышленником, но мы здесь не будем в них ковыряться, т.к. к сути явления это не относится.

В максимальном объёме проверка удостоверяющим центром может включать очную явку собственников в удостоверяющий центр, предоставление ими паспортов, других документов и т.д.

Если удостоверяющий центр проверил того, кому выдал сертификат; если у нас есть публичный ключ этого удостоверяющего центра; если мы с использованием этого публичного ключа смогли расшифровать содержимое сертификата и после расшифровки имя сайта, указанное в сертификате, совпадает с тем, по которому мы обратились, значит мы можем быть уверены, что на том ip-адресе, с которого мы получаем контент, находится экземпляр сертификата, выпущенного данным удостоверяющим центром для данного доменного имени.

Таким образом, мы можем быть уверены, что наш браузер устанавливает зашифрованное соединение с использованием сертификата, выданного тому лицу, которое имеет доступ к регистрационным записям запрошенного доменного имени.

Где же мы возьмём публичный ключ удостоверяющего центра, чтобы проверять все выданные им сертификаты? Очень просто: сертификаты удостоверяющих центров предустановлены в нашем веб-броузере и в операционной системе. Также их туда можно устанавливать руками (всем известная суета с установкой сертификатов Минцифры как раз об этом). Что будет, если себе в систему установить какой-нибудь злоумышленный сертификат поддельного удостоверяющего центра? Наша система начнёт доверять всем сертификатам, которые выпущены с использованием приватного ключа, парного этому сертификату.

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

Хэш - результат преобразования данных посредством функции; имеет один размер, независимо от размер входных данных; при повторном применении той же хэш-функции к тем же данным, результат будет идентичным; обратным преобразованием хэша первоначальные данные не получить; каждый хэш достаточно уникален для практических целей.

Итак, что же такое ЭЦП. Это та же самая пара ключей для асимметричного алгоритма шифрования, которую мы рассмотрели ранее. Только в поле subject сертификата уже указан конкретный гражданин, сотрудник юрлица или должностное лицо госоргана. А привантый ключ, таким образом, инвариантно сопоставлен с указанным в сертификате лицом посредством удостоверительной записи удостоверяющего центра, содержащейся в рассмотренном ранее поле signatureValue сертификата.

Как происходит подписание посредством ЭЦП.

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

Чтобы так сделать было нельзя, мы зашифровываем хэш этого файла своим частным ключом. Этот криптохэш может существовать в виде отдельного файла, который передаётся получателю вместе с исходным документом. Также в комплекте должен идти наш сертификат с нашим публичным ключом, но иногда он может содержаться и в файле с криптохэшем. Иногда и криптохэш и сертификат могут быть добавлены к документу без нарушения целостности исходного документа. Криптохэш вместе с сертификатом публичного ключа и есть электронная цифровая подпись документа. Т.о. криптохэш тождественен собственноручной подписи владельца частного ключа, с использованием которого этот криптохэш изготовлен. Изготовил криптохэш документа = подписал его.

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

Всё.

Как-нибудь рассмотрим p2p шифрование переписки. И штампы времени в ЭЦП (нешутошной важности вещь).

_{Условия использования статьи: перепечатка (отображение во фрейме и т.п.) не разрешена, цитирование разрешено по российскому праву на общих основаниях с указанием действующей индексируемой (dofollow) ссылки на статью на сайте vk-pravo.ru}