Защита документа несовместимый хэш
Продолжая раскрывать тайное знание о цифровой подписи простым языком, разберем, что же нам надо для удобной и эффективной работы с ними, а также главное различие между лагерями S/MIME + X.509 и PGP.
Перед тем, как рассматривать особенности этих двух больших лагерей, стоит рассмотреть, какая информация нужна получателю для проверки подписи (а наш зашифрованный хэш уже вполне можно называть подписью), и в каком виде ее можно ему передать.
Каждую из частей информации можно передать вместе с открытым ключом, или вместе с нашей подписью, а можно и с тем и с тем, для большего удобства. Конечно, можно не разделять информацию на передаваемую с открытым ключом и передаваемую с подписью. Но тогда каждый раз отправляя подписанную информацию мы отправляем одно и то же. Как если бы к каждому отправляемому нами бумажному письму (даже короткому, в две строки), мы бы прикладывали дополнение вида «Здравствуйте! Это я, В. Пупкин, которого вы встречали на Красной площади Москвы, где мы и познакомились, потом пошли в ресторан, потом <. >». Согласитесь, слегка неудобно.
Но вернемся к нашей информации, необходимой для проверки подписи.
Начнем с простого: информация, которая позволит нам узнать, кто же сделал эту подпись. Как мы уже договорились, ассиметричное шифрование позволяет однозначно связать наш открытый ключ и полученную подпись. Беда в том, что сам по себе открытый ключ – набор байт. При этом он, конечно, связан с закрытым, которым мы (то есть отправитель) владеем, но связь эта для получателя неочевидна. У него есть набор байт от В. Пупкина, от И. Петрова, от С. Сидорова… И от десятка других людей. И как ему их идентифицировать? Держать отдельный реестр для того, кому какой набор байт принадлежит? Это что же, получается уже второй реестр (помимо того, где должно быть записано, с помощью какой хэш-функции какой хэш сделан)! И опять, неудобно!
Значит, надо связать каждый открытый ключ с информацией о том, кому этот ключ принадлежит, и присылать это все одним пакетом. Тогда проблема реестра решается сама собой – пакет (а если более правильно, контейнер) с открытым ключом можно будет просто посмотреть и сразу понять его принадлежность.
Но эту информацию все так же надо связать с подписью, пришедшей получателю. Как это сделать? Надо соорудить еще один контейнер, на сей раз для передачи подписи, и в нем продублировать информацию о том, кто эту подпись создавал.
Продолжая нашу аналогию с красивым замком, мы пишем на ключе «Этот ключ открывает замок В. Пупкина». А на замке тоже пишем «Замок В. Пупкина». Имея такую информацию, получатель нашей коробочки не будет каждый из имеющихся у него ключей вставлять наугад в наш замок, а возьмет наш ключ и сразу его откроет.
Теперь, по переданной информации при проверке можно найти контейнер открытого ключа, взять оттуда ключ, расшифровать хэш и…
А собственно, что «и»? Мы ведь пока так и не решили проблему, как донести до получателя информацию о том, какая хэш-функция применялась для хэша, а ведь для проверки подписи эта информация необходима! Решить ее можно достаточно просто: положить эту информацию в контейнер вместе с нашим открытым ключом. Ведь именно связка «хэширование – шифрование результата хеширования» считается процедурой создания цифровой подписи, а ее результат – подписью. А значит, достаточно логичным представляется объединение в связку алгоритма шифрования хэша и хэш-функции, с помощью которой он сформирован. И доставлять эту информацию тоже надо в связке.
Теперь, ненадолго вернемся к информации о подписывающем. Какого рода эта информация должна быть? ФИО? Нет, В. Пупкиных много. ФИО + год рождения? Так и родившихся в один день В. Пупкиных тоже предостаточно! Более того, это может быть Василий, Виктор, или даже Василиса или Виктория Пупкины. Значит, информации должно быть больше. Ее должно быть столько, чтобы совпадение всех параметров, по которым мы идентифицируем человека, было максимально невероятным.
Безусловно, такой пакет информации создать возможно. Вот только, работать с ним уже трудновато. Ведь надо наши контейнеры открытых ключей надо сортировать, хранить, использовать, в конце концов. А если для каждого использования придется указывать по полсотни параметров, то уже на втором контейнере станет понятно, что что-то надо менять. Решение этой проблемы, конечно же, было найдено.
Чтобы понять, в чем же оно заключалось, обратимся к бумажному документу, который есть у всех нас: к паспорту. В нем можно найти и ФИО, и дату рождения, и пол, и много другой информации. Но, главное, в нем можно найти серию и номер. И именно серия и номер являются той уникальной информацией, которую удобно учитывать и сортировать. Кроме того, они существенно короче всей оставшейся информации вместе взятой, и при этом все так же позволяют опознать человека.
Применяя этот же подход к контейнерам открытых ключей, мы получим, что у каждого контейнера должен быть некий номер, последовательность символов, уникальная для него. Эту последовательность символов принято называть идентификатором, а сами контейнеры – сертификатами, либо просто ключами.
Вот здесь и начинаются принципиальные различия в идеологиях OpenPGP и S/MIME + X.509. Для краткого понимания их, вернемся к нашей аналогии с паспортом.
Паспорт вы можете использовать при покупках билетов, при оформлении документов, для выдачи пропуска на какую-либо территорию и даже на территории других стран! То есть, вы используете его для идентификации вашей личности в самых различных, зачастую абсолютно не связанных друг с другом, местах, с самыми различными людьми. И везде ваш паспорт принимают. Гарантом того, что вы – это вы выступает третья сторона в ваших взаимоотношениях с другими: государство. Именно оно выдало вам ваш паспорт, специально оформленный, подписанный и заверенный, и именно поэтому ваш паспорт является таким универсальным документом.
С другой стороны, в кругу друзей, или внутри компании вам достаточно представиться так: «В. Пупкин из твоей группы в институте» или же «В. Пупкин из отдела продаж». И людям, с которыми вы контактируете в этом кругу уже не нужна третья сторона, они и так помнят Пупкина из группы с которым проучились пять лет, или Пупкина из отдела продаж, с которым недавно ходили обедать, и предоставленной вами информации им вполне достаточно.
Так же можно разделить и эти два лагеря.
Сертификат X.509 – это аналог нашего паспорта. Здесь сертификаты вам выдаются суровой третьей стороной, гарантом вашей личности: Удостоверяющим Центром (УЦ). Получающий ваши подписи человек всегда может обратиться в УЦ и спросить интересующую его информацию по вот этому конкретному сертификату.
PGP же (и стандарт OpenPGP, появившийся в дальнейшем) создавался на основе так называемых сетей доверия. Такая идея подразумевает, что обмениваются подписями люди, которым третья сторона для их взаимоотношений не нужна, а нужна только защита от нехороших лиц.
Конечно, с течением времени такое разделение стало уже достаточно условным, так как на данный момент и в S/MIME+X.509 и в PGP можно использовать методы лагеря соперников. Но все же, стандарты достаточно продолжительное время развивались параллельно и развились до той степени, что взаимная совместимость между ними стала невозможной.
Более популярным стандартном, в силу своей ориентированности на участие более компетентной третьей стороны, стал стандарт S/MIME + X.509, однако и у PGP есть некоторое количество козырей за пазухой, с помощью которых он не только не погибает, но и продолжает успешно развиваться.
Более подробное рассмотрение каждого из форматов, а также рекомендации, когда, где и какой из них использовать вы сможете прочитать уже в следующих статьях.
Развитие цифровых технологий упростило многие моменты нашей жизни, в том числе, обмениваться документами и письмами в электронной форме оказалось быстрее и удобнее, чем в бумажной. Однако у электронного документооборота была проблема: нужно было как- то подтверждать подлинность электронных бумаг. На бумаге для этого использовались подписи, однако в цифровом формате их было достаточно легко подделать, поэтому для электронных документов требовался более надежный метод подтверждения. Поэтому и стал популярным аналог ручных подписей - электронная подпись, о которой будет рассказано дальше.
Сначала вкратце опишу то, как работает электронная подпись (ЭП) и в чём заключается её надёжность. Электронная подпись – подтверждение того, что какой-либо электронный документ был создан и подписан определённым физическим или юридическим лицом. При этом она должна обладать следующими свойствами:
Неотказуемость – подписавшее документ лицо не может утверждать, что это сделал кто-то другой;
Целостность – внесение исправлений в уже подписанный документ должно нарушать подпись;
Авторство – электронная подпись должна быть жёстко закреплена за определённым физическим или юридическим лицом.
Эти базовые принципы и делают ЭП эффективной и безопасной в использовании.
Немного теории
В качестве алгоритмической базы для электронной подписи обычно применяют методы шифрования с открытым ключом. Подробнее о самих алгоритмах можно почитать на википедии или на хабре. Их суть сводится к тому, что для желающего обзавестись собственной электронной подписью специальным образом выбирается пара ключей – открытый и закрытый. Первый, как следует из названия, доступен всем, а второй владельцу подписи лучше держать в секрете. Естественно, ключи выбираются так, чтобы закрытый ключ нельзя было легко угадать по открытому. После чего закрытый ключ используется для шифрования документа (иными словами, его подписания), а открытый – для расшифровки (то есть для проверки подписи). При этом алгоритмы выбора ключей гарантируют, что открытым ключом можно расшифровать только те документы, которые шифровались соответсвующим ему закрытым ключом. Таким образом, если мы знаем открытый ключ владельца ЭП и смогли расшифровать им полученный от него документ, то он был точно подписан тем самым владельцем. Так работают асимметричные схемы ЭП.
Что же может пойти не так?
И действительно, в теории взломать или подделать такую подпись можно несколькими способами. Самый лакомый способ для взломщика-криптоаналитика – это по открытому ключу угадать закрытый. Тогда злоумышленнику сразу открываются сказочные перспективы – ведь он сможет действовать от лица истинного владельца подписи и даже управлять его имуществом. Однако обычно такой взлом не возможен ввиду того, что подбор закрытого ключа по открытому – вычислительно нерешаемая задача. При генерации пары ключей широко применяются факторизация или дискретное логарифмирование, что оставляет взломщику мало надежды. Конечно можно попробовать подобрать закрытый ключ полным перебором, но при достаточно большом размере ключей такая возможность отпадает.
Ещё одно уязвимое место – это хэш-функция. Здесь возможны сразу несколько направлений атак. Если алгоритм хэширования не достаточно надёжный, то взломщик может подобрать какой-нибудь свой документ, применение хэш-функции к которому даст тот же результат, что и её применение к исходному документу. Или же злоумышленник может сгенерировать два документа, дающие одинаковый хэш, после чего при необходимости сможет подменить один документ другим. Названные ситуации считаются коллизиями хэш-функций. Однако жизнь взломщика хэш-функции всё же не так легка: мало того, что подставной документ должен представлять из себя читаемый текст, а не быть бессмысленным набором бит, так еще и придумано достаточно криптостойких алгоритмов хэширования. Для примера, надёжными на момент написания статьи являются SHA-3, BLAKE2, семейство JH или отечественный «Стрибог» (он же ГОСТ 34.11-2018).
Заключение
В статье вкратце было рассмотрено, как работает электронная подпись. Видно, что алгоритм достаточно устойчив и почти не имеет слабых мест. Однако, как и во многих случаях, самое слабое место этого метода - человеческий фактор, оставляющий большой простор для действий злоумышленников.
Итак, все чаще в кругах, работающих с документами все чаще звучат слова «электронный документ» и, связанное с ним почти неразрывно «электронная цифровая подпись», иначе — ЭЦП.
Данный цикл статей предназначен для того, чтобы раскрыть «тайное знание» о том, что это такое, когда и как это можно и нужно использовать, какие есть плюсы и минусы.
Естественно, статьи пишутся не для специалистов по криптографии, а для тех, кто эту самую криптографию будет использовать, или же только начинает ее изучение, желая стать специалистом, поэтому я старался максимально упростить понимание всего процесса, приводя аналогии и рассматривая примеры.
Зачем нам вообще что-то подписывать? Естественно, чтобы удостоверить, что мы ознакомились с содержимым, согласны (а иногда наоборот, не согласны) с ним. А электронная подпись еще и защищает наше содержимое от подмены.
Итак, начать, естественно, стоит с того, что такое электронная цифровая подпись.
В самом примитивном случае это — результат хэш-функции. Что это такое лучше меня разъяснит википедиа, в нашем же случае главное, что с высокой степенью вероятности ее результат не повторяется для разных исходных данных, а также что результат этой функции мало того, что короче исходных данных, так еще по нему исходную информацию восстановить нельзя. Результат функции называют хэшем, а применение этой функции к данным называют хешированием. Грубо, можно назвать хэш функцию архивированием, в результате чего мы получаем очень маленькую последовательность байт, но восстановить исходные данные из такого «архива» нельзя.
Итак, мы читаем файлик в память, хэшируем прочитанное. И что, уже получаем ЭЦП? Почти. Наш результат с большой натяжкой можно назвать подписью, но, все же, полноценной подписью он не является, потому что:
1. Мы не знаем, кто сделал данную подпись
2. Мы не знаем, когда была сделана подпись
3. Сама подпись не защищена от подмены никак.
4. Ну и да, хэш функций много, какая из них использовалась для создания этого конкретного хэша?
Поэтому применять к хэшу слово «подпись» еще нехорошо, будем называть его дальше просто хэш.
Вы посылаете ваш файл другому человеку, допустим, по почте, будучи уверенными, что он точно получит и прочитает именно то, что вы послали. Он же, в свою очередь, тоже должен хэшировать ваши данные и сравнить свой результат с вашим. Если они совпали — все хорошо. Это значит что данные защищены? Нет.
Ведь хэшировать может кто угодно и когда угодно, и вы никогда не докажете, что он хэшировал не то, что вы послали. То есть, если данные будут перехвачены по дороге злоумышленником, или же тот, кому вы посылаете данные — не очень хороший человек, то данные могут быть спокойно подменены и прохэшированы. А ваш получатель (ну или вы, если получатель — тот самый нехороший человек) никогда не узнает, что он получил не то, что вы отправляли, или сам подменил информацию от вас для дальнейшего использования в своих нехороших целях.
Посему, место для использование чистой хэш функции — транспорт данных в пределах программы или программ, если они умеют общаться между собой. Собственно, с помощью хэш функций вычисляются контрольные суммы. И эти механизмы защищают от случайной подмены данных, но не защищают от специальной.
Но, пойдем дальше. Нам хочется защитить наш результат хеширования от подмены, чтобы каждый встречный не мог утверждать, что это у него правильный результат. Для этого самое очевидное что (помимо мер административного характера)? Правильно, зашифровать. А ведь с помощью шифрования же можно и удостоверить личность того, кто хэшировал данные! И сделать это сравнительно просто, ведь есть ассиметричное шифрование. Да, оно медленное и тяжелое, но ведь нам всего-то и надо — зашифровать маленькую последовательность байт. Плюсы такого действия очевидны — для того, чтобы проверить нашу подпись, надо будет иметь наш открытый ключ, по которому личность зашифровавшего (а значит, и создавшего хэш) можно легко установить.
Суть этого шифрования в следующем: у вас есть закрытый ключ, который вы храните у себя. И есть открытый ключ. Открытый ключ вы можете всем показывать и раздавать, а закрытый — нет. Шифрование происходит с помощью закрытого ключа, а расшифровывание — с помощью открытого.
Приводя аналогию, у вас есть отличный замок и два ключа к нему. Один ключ замок открывает (открытый), второй — закрывает (закрытый). Вы берете коробочку, кладете в нее какую-то вещь и закрываете ее своим замком. Так, как вы хотите, чтобы закрытую вашим замком коробочку открыл ее получатель, то вы открытый, открывающий замок, ключик спокойно отдаете ему. Но вы не хотите, чтобы вашим замком кто-то закрывал коробочку заново, ведь это ваш личный замок, и все знают, что он именно ваш. Поэтому закрывающий ключик вы всегда держите при себе, чтобы кто-нибудь не положил в вашу коробочку мерзкую гадость и не говорил потом, что это вы ее положили и закрыли своим замком.
И все бы хорошо, но тут сразу же возникает проблема, а, на самом деле, даже не одна.
1. Надо как-то передать наш открытый ключ, при этом его должна понять принимающая сторона.
2. Надо как-то связать этот открытый ключ с нами, чтобы нельзя было его присвоить.
3. Мало того, что ключ надо связать с нами, надо еще и понять, какой зашифрованный хэш каким ключом расшифровывать. А если хэш не один, а их, скажем, сто? Хранить отдельный реестр — очень тяжелая задача.
Все это приводит нас к тому, что и закрытый ключ, и наш хэш надо хранить в каких-то форматах, которые нужно стандартизировать, распространить как можно шире и уже тогда использовать, чтобы у отправителя и получателя не возникало «трудностей перевода».
Как водится у людей, к чему-то единому прийти так и не смогли, и образовалось два больших лагеря — формат OpenPGP и формат S/MIME + X.509. Но об этом уже в следующей статье.
При добавлении подписи к файлу, через КриптоАРМ:
"Внимание! Для формирования ЭП был указан хеш-алгоритм, несовместимый с данным файлом подписи. Пожалуйста, выберите другой."
Ошибка связана с тем, что вы пытаетесь подписать документ подписью на разных и, в вашем случае, не поддерживаемых алгоритмов ключа подписи.
Есть два компьютера:
- КриптоАРМ 5.4 (которая работает с новым ГОСТ 2012) и сертифицированная версия КриптоПро CSP 4.0 R4
- КриптоАРМ 4.6 (которая НЕ работает с новым ГОСТ 2012) и сертифицированная версия КриптоПро CSP 4.0 R4
Возможно большое количество вариантов, рассмотрим несколько:
На первом компьютере мы подпишем документ подписью по ГОСТ 2012, передадим на второй компьютер и попробуем добавить подпись по ГОСТ 2001
И получим данную ошибку, т.к. на втором компьютере стоит КриптоАРМ не работающий с ГОСТ 2012.
! Но, если документ будет подписан алгоритмами ГОСТ 2012 и ГОСТ 2001, тогда на втором компьютере нам удастся добавить третью подпись по ГОСТ 2001, т.к. КриптоАРМ увидит поддерживаемый алгоритм.
Может быть еще вариант: например, документ подписан одной или несколькими подписями по алгоритму 2001 на втором компьютере, а мы пробуем подписать на первом по 2012. В такой конфигурации ошибки быть не может, а если ошибка появилась, то нам надо обновить КриптоАРМ и, возможно, КриптоПро CSP, и повторить операцию добавления подписи.
2. Необходимое программное обеспечение:
Минимальные требования:
Операционная система: Mac OS X 10.9.
Наличие учетной записи с правами администратора.
Ссылки на необходимое программное обеспечение:
Установка Крипто про CSP 5 версии
1. Скачайте архив Крипто про CSP 5 версии.
2. Нажимаем «Разрешить» в окне запроса загрузки.
3. Перейдите на вкладку Загрузки → двойным нажатием распакуйте скачанный архив CSP5.0macos-uni.tgz → откройте распакованную папку macos-uni.
4. В папке найдите файл с расширением *.dmg → кликните на него 2 раза.
5. В новом окне нажмите правой кнопкой мыши на файл с расширением *.mpkg → Открыть.
6. Затем в предупреждающем окне нажмите Открыть.
7. Если система выдает предупреждение на автора программы, попробуйте открыть файл с зажатой клавишей «ctrl» на клавиатуре.
8. Далее в трёх последующих окнах нажмите на кнопку Продолжить, чтобы запустить ПО для установки.
9. Далее необходимо принять условия лицензионного соглашения, для этого нажать на кнопки Принимаю, затем Продолжить и Установить.
10. Если потребуется, введите пароль учетной записи Администратора и нажмите на кнопку Установить ПО.
11. Дождитесь установки компонентов и нажмите на кнопку Закрыть. Криптопро CSP установлено!
Ввод лицензии КриптоПро
1. Откройте Terminal .
Запуск приложения macOS Терминал (Terminal).
Открыть стандартное приложение macOS Терминал (Terminal) возможно одним из способов:
В окне Терминала необходимо будет вводить команды.
. ВАЖНО при вводе команд возможно придется вводить пароль «Password» как на изображении выше, при вводе символы НЕ БУДУТ отображаться. После ввода символов пароля необходимо нажать клавишу «Enter».
2. Введите команду: sudo /opt/cprocsp/sbin/cpconfig -license -set серийный_номер_лицензии_с_дефисами.
. ВАЖНО: номер лицензии необходимо вводить с дефисами. Для подтверждения ввода необходимо ввести пароль администратора. Ввод пароля не отображается в окне терминала. После ввода пароля нажмите Enter.
Установка драйверов Рутокен
1. Со страницы загрузок на сайте Рутокен скачиваем и устанавливаем Модуль поддержки Связки Ключей (KeyChain) – скачать.
2. Далее подключаем к компьютеру usb-токен, запускаем Terminal (см. пункт «Запуск приложения macOS Терминал (Terminal)») и выполняем команду:
/opt/cprocsp/bin/csptest -card -enum
3. В ответе должно быть:
Aktiv Rutoken…
Card present…
[ErrorCode: 0x00000000]
Установка специального браузера Chromium-GOST
1. Для работы с государственными порталами потребуется браузер – Chromium-GOST.
По ссылке скачивается определенная сборка браузера (71.0.3578.98), так как в более новых версиях не гарантируется корректная работа в ЛК ФНС.
2. После скачивания файл браузера появится в папке Downloads (Загрузки), запускать его не требуется, просто перетаскиваем на панель уведомлений для удобства.
3. Переходим к настройке плагинов ниже.
Установка расширений для браузера.
Подключаем человеческий фактор, бюрократию и частные организации
В самом начале мы говорили о свойствах, которыми должна обладать качественная электронная подпись. Из них под действием уже упомянутых выше атак пока страдали только её целостность и неотказуемость. Однако в реалиях нашего мира наибольшее количество нарушений происходит из-за подмены авторства.
В России получение ЭП регулируется законом № 63-ФЗ «Об электронной подписи». Для её оформления нужно получить сертификат от удостоверяющего центра (УЦ) на выбор. В УЦ нужно предоставить необходимые документы и заплатить некоторую сумму, после чего забрать свой сертификат и заветный eToken с закрытым ключом.
Вот на получении сертификатов-то и возникает простор для всевозможных махинаций. Все УЦ являются коммерческими организациями, они обязательно аккредитованы Министерством цифрового развития и имеют лицензию от ФСБ. Однако чего не сделаешь ради прибыли - для УЦ порой желания клиентов выше установленных правил выдачи сертификата. Например, из-за этого сегодня возможно получить ЭП на другое лицо, пользуясь утечками персональных данных или некомпетентностью УЦ. Это приводит к довольно печальным последствиям – вплоть до переоформления квартиры или регистрации фиктивных организаций с целью взятия кредитов. Данные способы подделки подписей не требуют даже знания криптографии, достаточно лишь воспользоваться особенностями сертифицирования ЭП в России.
Применение хэш-функций
В связи с тем, что шифрование закрытым ключом документа большого размера – довольно сложный и долгий процесс, обычно к тексту документа сначала применяют более быстрое и простое хэш-шифрование. Полученный сравнительно короткий результат шифруют закрытым ключом, получая саму цифровую подпись. Вместе с ней открытый текст документа передаётся получателю.
Подробная схема с применением хэш-функции
Тот должен всего лишь хэшировать текст документа той же хэш-функцией, после чего расшифровать открытым ключом подпись и сравнить оба результата. Если они совпадают – то документ мог быть подписан только отправителем (вот она и неотказуемость) и не был испорчен, дополнен или подменён в процессе пересылки (а это целостность). А дляпоследнего свойства – авторства – необходимо, чтобы пара ключей подписавшего была закреплена за ним. На практике для этого используются так называемые удостоверяющие центры, которые по запросу выдают сертификат на пару ключей, а также гарантируют единственность обладания ими.
КриптоПро ЭЦП Browser plug-in
1. КриптоПро ЭЦП Browser plug-in скачиваете по данной ссылке.
2. Запустите файл установщика cprocsp-pki-2.0.14071.pkg.
3. Начнется установка КриптоПро ЭЦП Browser Plug-in. Нажмите Продолжить.
4. Ознакомьтесь с информацией о продукте и нажмите Продолжить.
5. Ознакомьтесь с Лицензионным соглашением и нажмите Продолжить.
6. Чтобы продолжить установку, потребуется принять условия Лицензионного соглашения. Для этого в появившемся окне нажмите Принять.
7. Для продолжения установки, нажмите Установить. Не рекомендуется изменять директорию установки КриптоПро ЭЦП Browser plug-in.
8. Если потребуется, разрешите Установщику установить КриптоПро ЭЦП Browser plug-in. Для этого необходимо ввести пароль.
9. Дождитесь окончания установки. После ее завершения нажмите Закрыть, чтобы выйти из программы установки.
Немного теории
В качестве алгоритмической базы для электронной подписи обычно применяют методы шифрования с открытым ключом. Подробнее о самих алгоритмах можно почитать на википедии или на хабре. Их суть сводится к тому, что для желающего обзавестись собственной электронной подписью специальным образом выбирается пара ключей – открытый и закрытый. Первый, как следует из названия, доступен всем, а второй владельцу подписи лучше держать в секрете. Естественно, ключи выбираются так, чтобы закрытый ключ нельзя было легко угадать по открытому. После чего закрытый ключ используется для шифрования документа (иными словами, его подписания), а открытый – для расшифровки (то есть для проверки подписи). При этом алгоритмы выбора ключей гарантируют, что открытым ключом можно расшифровать только те документы, которые шифровались соответсвующим ему закрытым ключом. Таким образом, если мы знаем открытый ключ владельца ЭП и смогли расшифровать им полученный от него документ, то он был точно подписан тем самым владельцем. Так работают асимметричные схемы ЭП.
Плагин для Госуслуг
1. Скачиваем корректный конфигурационный файл для расширения Госуслуг для поддержки macOS и новых ЭЦП в стандарте ГОСТ2012 по ссылке
2. Запустите файл установщика IFCPlugin.pkg с помощью контекстного меню (правая кнопка мыши), выбрав Открыть.
3. Для начала установки нажимаете Установить.
5. Если потребуется, разрешите Установщику установить плагин. Для этого необходимо ввести пароль.
6. Дождитесь окончания установки. После ее завершения нажмите Закрыть, чтобы выйти из программы установки.
7. Конфигурационный файл плагина Госуслуг ifc.cfg доступен по данной ссылке.
8. Скачиваем и оставляем его в папке Download/Загрузки.
9. Открываем стандартное приложение macOS Терминал (Terminal) (см. раздел Запуск приложения macOS Терминал (Terminal)).
10. Вводим последовательно команды:
sudo rm /Library/Internet\ Plug-Ins/IFCPlugin.plugin/Contents/ifc.cfg
sudo cp ~/Downloads/ifc.cfg /Library/Internet\ Plug-Ins/IFCPlugin.plugin/Contents
sudo cp /Library/Google/Chrome/NativeMessagingHosts/ru.rtlabs.ifcplugin.json /Library/Application\ Support/Chromium/NativeMessagingHosts
Устанавливаем сертификат с Рутокен
1. Подключаем usb-токен, переходим в Терминал (Terminal) и выполняем команду:
/opt/cprocsp/bin/csptest -card –enum
2. Устанавливаем сертификат КЭП с помощью команды в Терминал (Terminal):
/opt/cprocsp/bin/csptestf -absorb -certs
Конфигурируем CryptoPro для работы c сертификатами ГОСТ Р 34.10-2012
sudo /opt/cprocsp/sbin/cpconfig -ini ‘\cryptography\OID\1.2.643.7.1.1.1.1!3’ -add string ‘Name’ ‘GOST R 34.10-2012 256 bit’
sudo /opt/cprocsp/sbin/cpconfig -ini ‘\cryptography\OID\1.2.643.7.1.1.1.2!3’ -add string ‘Name’ ‘GOST R 34.10-2012 512 bit’
Настройка браузера Chromium-Gost
1. Запускаем браузер Chromium-Gost и в адресной строке набираем:
chrome://extensions/
2. Включаем оба установленных расширения, с помощью выключателя
3. Настраиваем расширение КриптоПро ЭЦП Browser plug-in, для этого в адресной строке Chromium-Gost набираем:
/etc/opt/cprocsp/trusted_sites.html
4. На появившейся странице в список доверенных узлов по очереди добавляем сайты:
5. Жмем кнопку Сохранить. Должна появиться запись на зелёном фоне: «Список доверенных узлов успешно сохранен».
Полезные дополнения
Устранение сбоев
1. Переподключаем usb-токен и проверяем что он виден с помощью команды в Терминал (Terminal):
sudo /opt/cprocsp/bin/csptest -card -enum
2. Очищаем кеш браузера за все время, для чего в адресной строке Chromium-Gost набираем:
chrome://settings/clearBrowserData
3. Переустанавливаем сертификат КЭП с помощью команды в Терминал (Terminal):
/opt/cprocsp/bin/csptestf -absorb –certs
4. Проверить статус лицензии КриптоПро CSP можно командой:
/opt/cprocsp/sbin/cpconfig -license –view
5. Активировать лицензию КриптоПро CSP можно командой:
sudo /opt/cprocsp/sbin/cpconfig -license -set серийный_номер_лицензии
Подпись файла командой из Терминал (Terminal)
1. В Терминал (Terminal) переходим в каталог с файлом для подписания и выполняем команду:
/opt/cprocsp/bin/cryptcp -signf -detach -cert -der -strict -thumbprint ХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХ FILE
где ХХХХ… – хэш сертификата, полученный на шаге 1, а FILE – имя файла для подписания (со всеми расширениями, но без пути).
2. Команда должна вернуть:
Signed message is created.
[ErrorCode: 0x00000000]
Будет создан файл электронной подписи с расширением *.sgn – это отсоединенная подпись в формате CMS с кодировкой DER.
Установка Apple Automator Script
Чтобы каждый раз не работать с терминалом, можно один раз установить Automator Script, с помощью которого подписывать документы можно будет из контекстного меню Finder. Для этого
1. Скачиваем архив – скачать.
2. Распаковываем архив ‘Sign with CryptoPro.zip’.
3. Запускаем Automator.
4. Находим и открываем распакованный файл ‘Sign with CryptoPro.workflow’.
5. В блоке Run Shell Script меняем текст ХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХХ на значение параметра SHA1 Hash сертификата КЭП, полученное выше.
6. Сохраняем скрипт: ⌘Command + S
7. Запускаем файл ‘Sign with CryptoPro.workflow’ и подтверждаем установку.
8. Идем в System Preferences —> Extensions —> Finder и проверяем, что Sign with CryptoPro quick action отмечено.
9. В Finder вызываем контекстное меню любого файла, и в разделе Quick Actions и/или Services выбрать пункт Sign with CryptoPro.
10. В появившемся диалоге КриптоПро ввести PIN-код пользователя от КЭП.
11. В текущем каталоге появится файл с расширением *.sgn – отсоединенная подпись в формате CMS с кодировкой DER.
Читайте также: