Как настроить алгоритм шифрования

Алгоритм шифрования необходимый для выполнения этой операции не установлен на этом компьютере

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

Что такое ЭЦП?

Электронная цифровая подпись подтверждает авторство документа. Это позволяет убедиться, что вся содержащаяся в нем информация актуальна и правдива. Если файл был изменен сторонними лицами, то ЭП в нем не будет.

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

В июле 2021 года изменились требования к электронным подписям. ИП и юрлица могут получать квалифицированную ЭП бесплатно в ФНС. Обычным гражданам приходится обращаться в коммерческий аккредитованный центр.

После покупки ЭЦП желательно обезопасить свои данные. Для этого нужно сделать следующее:

1. Настроить компьютер для работы с электронными подписями.
2. Запустить КриптоПРО CSP.
3. Открыть вкладку «Сервис».
4. Кликнуть на кнопку «Изменить пароль».
5. Нажать на клавишу «Обзор» и выбрать нужный сертификат».
6. Поставить на него пароль.

После входа на любой ресурс, требующий ЭЦП, будет возникать окно с требованием ввести выбранный вами пин-код. Это обезопасит вас от мошенников.

Почему возникает ошибка «Алгоритм шифрования не установлен на компьютере»

Начиная с 2010 версии Ворда, для подписи электронных документов необходимо устанавливать дополнение Крипто Про Office Signature. Для успешной инсталляции этого плагина понадобится купить отдельную лицензию. Без новых расходов не обойтись, даже если у вас уже оплачена программа КриптоПро.

Если вы видите сообщение «Алгоритм шифрования, который необходим для выполнения операции, не установлен на этом компьютере», сразу проверьте работу плагина Crypto Pro Office Signature 2.0. Без него вы не сможете поставить действующую электронную подпись.

Проблемы могут заключаться в следующем:

• Плагин Signature 2.0 не установлен.
• Срок действия лицензии на данную утилиту уже истек.
• Требуется обновление ПО.
• Поддержка Microsoft Office прекращена.

Первый месяц программа может работать в бесплатном тестовом режиме. Далее за ее использование необходимо будет заплатить.

Полезные ссылки

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

Разобраться в ситуации вам помогут следующие ссылки:

• Официальный мануал в формате PDF лежит на площадке cryptopro.ru.
• Информацию от компании Майкрософт можно найти на сайте microsoft.com.

Если вы не можете разобраться с проблемой самостоятельно, обратитесь в техподдержку. Для этого перейдите на сайт support.cryptopro.ru. Чтобы получить помощь от сотрудников сервиса, авторизуйтесь в системе. Затем кликните на кнопку «Создать новое обращение».

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

Как работать с плагином

Если алгоритм шифрования для выполнения нужной операции не установлен на компьютере, его надо инсталлировать. Если же требуемое ПО уже у вас есть, то ситуация становится сложнее. Возможно, неполадки связаны с тем, что Крипто Про больше не поддерживает Microsoft Office.

Как подписать документ в этом случае:

1. Найдите его на своем компьютере. Это удобнее делать с помощью файлового менеджера. Затем щелкните правой кнопкой мыши по названию документа.
2. Появится контекстное меню. Выберите в нем опцию VipNet CryptoFile.
3. В списке доступных команд вы увидите такие варианты как «Подписать» и «Зашифровать». Кликните на нужное вам действие.

У пользователей Microsoft Office часто возникают проблемы с подписью для электронных документов. Чтобы не тратить лишнее время на бесплодные попытки исправить подобные неполадки, мы рекомендуем в любой непонятной ситуации сразу обращаться в службу технической поддержки Крипто Про.

Ссылка на скачивание плагина с поддержкой Майкрософт Офис выложена на ресурсе https://cryptopro.ru/products/office/signature/downloads. Кликните по надписи КриптоПро Office Signature 2.0. В ответ на это на соседней вкладке откроется окошко с предложением скачать файл. Нажмите на кнопку «ОК» и дожидайтесь завершения загрузки.

По окончанию скачивания запустите файл и начните его установку. Удалять предыдущие версии программы не нужно. Данное ПО является ознакомительным, поэтому не может полноценно заменить плагин КриптоПро Signature 2.0.

У пользователей Microsoft Office часто возникают проблемы с подписью для электронных документов. Чтобы не тратить лишнее время на бесплодные попытки исправить подобные неполадки. Мы рекомендуем в любой непонятной ситуации сразу обращаться в службу технической поддержки Крипто Про.

Источник

Шифрование TLS-трафика по алгоритмам ГОСТ-2012 c Stunnel

В этой статье я хочу показать, как настроить Stunnel на использование российских криптографических алгоритмов в протоколе TLS. В качестве бонуса покажу, как шифровать TLS-канал, используя алгоритмы ГОСТ, реализованные в криптоядре Рутокен ЭЦП 2.0.

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

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

Стоит заметить, что на сервере не обязательно должен стоять именно Stunnel, для работы с криптографическими алгоритмами. Здорово, что есть готовые демонстрационные стенды, которые поддерживают российскую криптографию, список которых есть в презентации с РусКрипто’2019.

Нам нужны стабильно работающие серверы, осуществляющие двухстороннюю аутентификацию.
Мы выбрали серверы КриптоПро как наиболее надёжные с полной реализацией стандарта ГОСТ TLS. Спасибо им за это 🙂

Звучит достаточно просто, давайте попробуем организовать этот процесс.

Подготовительный шаг

1. OpenSSL
2. Stunnel
3. rtengine
4. Доступ к тестовым серверам КриптоПро, для проверки соединения по TLS

OpenSSL для Windows можно взять отсюда, а для пользователей линукса — из репозиториев или собрать самому, скачав свежую версию отсюда. Также его можно взять из Rutoken SDK, из директории openssl\openssl-tool-1.1, этот архив нам будет полезен и дальше, т.к. в нём находится интересующий нас rtengine. Stunnel можно найти здесь. Для работы необходима версия >= 5.56.

Скачать rtengine можно из Rutoken SDK, он лежит в директории openssl\rtengine\bin. Закинуть его нужно туда, где хранятся все движки openssl. Узнать путь до них можно с помощью

Но просто переместить движок в нужную папку — мало, нужно ещё сконфигурировать сам openssl для работы с ним. Узнаём где лежит файл с конфигурацией openssl.cnf с помощью той же команды, что указана выше (под виндой stunnel идёт с собственной версией openssl, поэтому файл с конфигурацией лежит в path\to\stunnel\config\openssl.cnf

Давайте проверим, что rtengine подключился, для этого подключим токен и выведем список всех алгоритмов шифрования:

Напомню, что в Windows нужно проверять на openssl, который лежит рядом с stunnel
Если среди них будут присутствовать наши ГОСТы, значит всё настроено верно.

Настало время самого интересного: проверка установки соединения по ГОСТу с тестовыми серверами КриптоПро. Список данных серверов описан здесь (https://www.cryptopro.ru/products/csp/tc26tls). Каждый из этих серверов работает со своими алгоритмами для аутентификации и шифрования. Более того на портах 443, 1443, 2443,… запущены сервисы, которые воспринимают только определённые парамсеты. Так, например, по адресу http://tlsgost-256auth.cryptopro.ru происходит шифрование с аутентификацией с использованием алгоритмов GOST2012-GOST8912-GOST8912 и 256-битным ключом. Так же на порту 443 используется XchA-ParamSet, на порту 1443 — XchB-ParamSet, на порту 2443 — A-ParamSet и т.д.

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

Простой способ (работает под Windows и Linux)

Через командную строку

Для того, чтобы получить корневой сертификат, зайдём на сайт тестового УЦ ООО «КРИПТО-ПРО». И нажмём на кнопку для получения сертификата. Отобразится новая вкладка, в которой нужно будет выбрать метод шифрования Base64 и нажать на кнопку «Загрузка сертификата ЦС». Полученный файл certnew.cer сохраняем.

Теперь генерируем ключи.

Стоит заметить, что сгенерированные на токене ключи не могут быть скопированы с токена. В этом состоит одно из основных преимуществ их использования.

Создадим запрос на сертификат:

Опять открываем сайт тестового УЦ, но на этот раз нажимаем на кнопку «Отправить готовый запрос PKCS#10 или PKCS#7 в кодировке Base64». Вставляем в поле содержимое нашего запроса, нажимаем на кнопку Выдать и загружаем сертификат user.crt в формате Base64. Полученный файл сохраняем

Остался последний вопрос: Для чего всё это. Зачем мы получали все эти сертификаты, ключи и запросы?

Дело в том, что они нужны протоколу TLS для двусторонней аутентификации. Работает это очень просто.

У нас есть сертификат сервера, и мы считаем его доверенным.

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

Мы отправили этот запрос и сервер подписал её своей ЭЦП. Теперь мы можем каждый раз предъявлять этот сертификат, подписанный корневым УЦ, тем самым подтверждая, что мы — это мы.

Конфигурирование Stunnel

Осталось только правильно настроить наш туннель. Для этого создадим файл stunnel.conf с настройками Stunnel по умолчанию и напишем туда следующее:

Теперь, если всё сделано правильно, можно запустить Stunnel с нашей конфигурацией и подключиться к серверу:

Откроем браузер и зайдём по адресу localhost:8080. Если всё верно, то отобразится следующее:

Если же нет, то смотрим логи и используем отладчик, чтобы понять в чём же всё-таки проблема.

Если у вас остались какие-то вопросы, то милости просим в комментарии 🙂

Источник

Шифруемся по ГОСТу: памятка по настройке динамической маршрутизации трафика

Пара слов о проекте

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

Обычно в подобных проектах всё статично: на криптошлюзах (КШ) задаются статические маршруты в локальную сеть площадки, прописываются списки IP-адресов (ACL) для шифрования. Однако в данном случае у площадок нет централизованного управления, и внутри их локальных сетей может происходить всё, что угодно: сети могут добавляться, удаляться и всячески модифицироваться. Для того чтобы избежать перенастройки маршрутизации и ACL на КШ при изменении адресации локальных сетей на площадках, было принято решение использовать GRE-туннелирование и динамическую маршрутизацию OSPF, в которую включены все КШ и большинство маршрутизаторов уровня ядра сети на площадках (на некоторых площадках администраторы инфраструктуры предпочли использовать SNAT в сторону КШ на маршрутизаторах ядра).

GRE-туннелирование позволило решить две задачи:
1. Использовать в ACL для шифрования IP-адрес внешнего интерфейса КШ, в котором инкапсулируется весь трафик, направляющийся на другие площадки.
2. Организовать p-t-p туннели между КШ, которые позволяют настроить динамическую маршрутизацию (в нашем случае между площадками организован провайдерский MPLS L3VPN).

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

А теперь собственно памятка – как и что мы настраивали

Субъекту КИИ на заметку: настраиваем криптошлюз

Базовая настройка сети

Прежде всего запускаем новый КШ и попадаем в консоль администрирования. Начать стоит с изменения пароля встроенного администратора — команда change user password administrator. Затем необходимо с провести процедуру инициализации (команда initialize) в процессе которой вводятся данные лицензии и инициализируется датчик случайных чисел (ДСЧ).

Обратите внимание! При инициализации КШ S-Terra устанавливается политика безопасности, при которой интерфейсы шлюза безопасности не пропускают пакеты. Необходимо либо создать собственную политику, либо с помощью команды run csconf_mgr activate выполнить активацию предустановленной разрешающей политики.
Далее необходимо настроить адресацию внешних и внутренних интерфейсов, а также маршрут по умолчанию. Работу с сетевой конфигурацией КШ и настройку шифрования предпочтительно выполнять через Cisco-like консоль. Данная консоль предназначена для ввода команд, аналогичных командам Cisco IOS. Конфигурация, сформированная с помощью Cisco-like консоли, в свою очередь конвертируется в соответствующие конфигурационные файлы, с которыми работают демоны ОС. Перейти в Cisco-like консоль из консоли администрирования можно командой configure.

Меняем пароли на встроенного пользователя cscons и enable:

>enable
Password: csp(предустановленный)
#configure terminal
#username cscons privilege 15 secret 0 #enable secret 0 Настраиваем базовую сетевую конфигурацию:

#interface GigabitEthernet0/0
#ip address 10.111.21.3 255.255.255.0
#no shutdown
#interface GigabitEthernet0/1
#ip address 192.168.2.5 255.255.255.252
#no shutdown
#ip route 0.0.0.0 0.0.0.0 10.111.21.254

Выходим из Cisco-like консоли, и переходим в debian shell командой system. Устанавливаем собственный пароль для пользователя root командой passwd.
На каждом КШ настраивается отдельный туннель для каждой площадки. Настройка туннельного интерфейса производится в файле /etc/network/interfaces. За создание самого интерфейса отвечает утилита IP tunnel, входящая в предустановленный набор iproute2. Команда создания интерфейса прописывается в опцию pre-up.

Пример конфигурации типового туннельного интерфейса:
auto site1
iface site1 inet static
address 192.168.1.4
netmask 255.255.255.254
pre-up ip tunnel add site1 mode gre local 10.111.21.3 remote 10.111.22.3 key hfLYEg^vCh6p

Обратите внимание! Надо заметить, что настройки туннельных интерфейсов необходимо располагать вне секции

В противном случае данные настройки будут затерты при изменении сетевых настроек физических интерфейсов через Cisco-like консоль.

Динамическая маршрутизация

В S-Terra динамическая маршрутизация реализуется при помощи пакета программ Quagga. Для настройки OSPF нам потребуются включение и настройка демонов zebra и ospfd. Демон zebra отвечает за взаимодействие между демонами маршрутизации и ОС. Демон ospfd, как понятно из названия, отвечает за реализацию протокола OSPF.
Настройка OSPF производится либо через консоль демона, либо напрямую через конфигурационный файл /etc/quagga/ospfd.conf. В файл добавляются все физические и туннельные интерфейсы участвующие в динамической маршрутизации, а также объявляются сети, которые будут анонсироваться и принимать анонсы.

Пример конфигурации, которую требуется добавить в ospfd.conf:
interface eth0
!
interface eth1
!
interface site1
!
interface site2
router ospf
ospf router-id 192.168.2.21
network 192.168.1.4/31 area 0.0.0.0
network 192.168.1.16/31 area 0.0.0.0
network 192.168.2.4/30 area 0.0.0.0

В данном случае адреса 192.168.1.х/31 отведены под туннельные ptp-сети между площадками, адреса 192.168.2.х/30 — под транзитные сети между КШ и маршрутизаторами ядра.

Обратите внимание! Для уменьшения таблицы маршрутизации в крупных инсталляциях можно отфильтровать анонсирование самих транзитных сетей с помощью конструкций no redistribute connected или redistribute connected route-map.

После настройки демонов необходимо изменить статус запуска демонов в /etc/quagga/daemons. В опциях zebra и ospfd no исправить на yes. Запустить демон quagga и установить его автозапуск при запуске КШ командой update-rc.d quagga enable.

Если настройка GRE-туннелей и OSPF выполнена верно, то на КШ и маршрутизаторах ядра должны появится маршруты в сети остальных площадок и, таким образом, возникает сетевая связность между локальными сетями.

Шифруем передаваемый трафик

Как уже было написано, обычно при шифровании между площадками мы указываем диапазоны IP-адресов (ACL), между которыми шифруется трафик: если адреса источника и получателя попадают в эти диапазоны, то трафик между ними шифруется. Однако в данном проекте структура динамическая и адреса могут меняться. Так как мы уже настроили GRE-туннелирование, в качестве адресов источника и получателя для шифрования трафика можем указать внешние адреса КШ — ведь для шифрования приходит трафик, уже инкапсулированный протоколом GRE. Иными словами, шифруется всё, что попадает в КШ из локальной сети одной площадки в сторону сетей, которые были анонсированы другими площадками. А уже внутри каждой из площадок может выполняться любая переадресация. Таким образом, при каком-либо изменении локальных сетей администратору достаточно модифицировать анонсы, идущие из его сети в сторону КШ, и она станет доступной для других площадок.

Шифрование в КШ S-Terra выполняется посредством протокола IPSec. Мы используем алгоритм «Кузнечик» в соответствии с ГОСТ Р 34.12-2015, а для совместимости со старыми версиями можно применить ГОСТ 28147-89. Аутентификация технически может выполняться как на предопределенных ключах (PSK), так и на сертификатах. Тем не менее в промышленной эксплуатации необходимо использовать сертификаты, выпущенные по ГОСТ Р 34.10-2012.

Работа с сертификатами, контейнерами и CRL выполняется с помощью утилиты cert_mgr. Первым делом с помощью команды cert_mgr create необходимо сформировать контейнер закрытого ключа и запрос на сертификат, который будет направлен в Центр управления сертификатами. После получения сертификата его вместе с корневым сертификатом УЦ и CRL (если используется) необходимо импортировать командой cert_mgr import. Убедиться в том, что все сертификаты и CRL установились можно командой cert_mgr show.

После успешной установки сертификатов переходим в Cisco-like консоль для настройки IPSec.
Создаем IKE-политику, в которой указываются желаемые алгоритмы и параметры создаваемого защищенного канала, которые будут предложены партнеру для согласования.

#crypto isakmp policy 1000
#encr gost341215k
#hash gost341112-512-tc26
#authentication sign
#group vko2
#lifetime 3600

Данная политика применяется при построении первой фазы IPSec. Результатом успешного прохождения первой фазы служит установление SA (Security Association).
Далее нам потребуется определить список IP-адресов источника и получателя (ACL) для шифрования, сформировать набор преобразований (transform set), создать криптографическую карту (crypto map) и привязать ее к внешнему интерфейсу КШ.

Задаем ACL:
#ip access-list extended site1
#permit gre host 10.111.21.3 host 10.111.22.3

Набор преобразований (так же, как и для первой фазы, используем алгоритм шифрования «Кузнечик» с использованием режима выработки имитовставки):

#crypto ipsec transform-set GOST esp-gost341215k-mac

Создаем криптокарту, указываем ACL, transform set и адрес пира:

#crypto map MAIN 100 ipsec-isakmp
#match address site1
#set transform-set GOST
#set peer 10.111.22.3

Привязываем криптокарту к внешнему интерфейсу КШ:

#interface GigabitEthernet0/0
#ip address 10.111.21.3 255.255.255.0
#crypto map MAIN

Для шифрования каналов с другими площадками необходимо повторить процедуру создания ACL и криптокарты, изменив название ACL, IP-адреса и номер криптокарты.

Обратите внимание! В том случае, если не используется проверка сертификатов по CRL, это необходимо явно указать:

#crypto pki trustpoint s-terra_technological_trustpoint
#revocation-check none

На этом настройку можно считать завершенной. В выводе команд Cisco-like консоли show crypto isakmp sa и show crypto ipsec sa должны отражаться построенные первые и вторые фазы IPSec. Эту же информацию можно получить с помощью команды sa_mgr show, выполненной из debian shеll. В выводе команды cert_mgr show должны появиться сертификаты удаленных площадок. Статус таких сертификатов будет remote. В том случае если туннели не строятся, необходимо заглянуть в лог VPN-сервиса, который хранится в файле /var/log/cspvpngate.log. Полный список лог-файлов с описанием их содержания присутствует в документации.

Мониторим «здоровье» системы

В КШ S-Terra для мониторинга используется стандартный демон snmpd. Помимо типичных для Linux параметров, S-Terra «из коробки» поддерживает выдачу данных об IPSec-туннелях согласно CISCO-IPSEC-FLOW-MONITOR-MIB, чем мы и пользуемся, отслеживая состояние IPSec-туннелей. Также поддерживается функционал кастомных OID’ов выдающих в качестве значений результаты выполнения скрипта. Эта возможность позволяет нам отслеживать сроки истечения сертификатов. Написанный скрипт парсит вывод команды cert_mgr show и в результате выдает количество дней до истечения локального и корневого сертификатов. Данный прием незаменим при администрировании большого количества КШ.

В чем цимус такого шифрования

Вся описанная выше функциональность поддерживается «из коробки» КШ S-Terra. То есть не пришлось устанавливать никаких дополнительных модулей, которые могли бы повлиять на сертификацию криптошлюзов и аттестацию всей информационной системы. Каналы между площадками могут быть любые, хоть через интернет.

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

Безусловно, шифрование за счет накладных расходов (overhead) влияет на скорость передачи данных, но незначительно — пропускная способность канала может снизиться максимум на 5—10 %. При этом технология протестирована и показала хорошие результаты даже на спутниковых каналах, которые довольно нестабильны и обладают низкой пропускной способностью.

Игорь Виноходов, инженер 2-ой линии администрирования «Ростелеком-Солар»

Источник