1С-ЭДО Настройка клиент-серверного подписания электронных документов

1С-ЭДО Настройка клиент-серверного подписания электронных документов Сертификаты

Что нужно знать перед настройкой

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

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

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

У браузеров Internet Explorer, Google Chrome, Яндекс.Браузер и Mozilla Firefox интерфейс имеет отличия, поэтому их настройка для работы с электронной подписью различается.

Рассмотрим настройку этих браузеров на основе криптопровайдера КриптоПро CSP.

1с-эдо

Ошибка при получении свойства сертификата.png

Ошибка при получении свойства сертификата (0x00000000) – это проявление ошибки отсутствия связи сертификата в Личном списке сертификатов пользователя ОС с контейнером закрытого ключа.

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

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

  • Если база клиент-серверная и проверяется подпись на сервере, то наличие связи надо проверять для пользователя ОС, под которым запущен сервер 1С без повышения прав (если используется web-сервер, то все равно проверки выполнять для пользователя ОС, под которым запущен сервер 1С). В этом случае ошибка в проверке подписи на клиенте проблемой не является.

  • Если база клиент-серверная и проверяется подпись на клиенте, то наличие связи надо проверять для пользователя ОС, под которым запускается сеанс 1С на машине-клиенте без повышения прав. В этом случае ошибка в проверке подписи на сервере проблемой не является.

Необходимо выяснить в каком из вышеперечисленных режимов происходит запуск 1С при возникновении ошибки, а также в какой проверке возникает ошибка (проверка на сервере или на клиенте). Все дальнейшие рекомендации выполнять на нужной машине и в сеансе нужного пользователя ОС без повышения прав (т.е. без “запуск от имени администратора”).

1. Проверить, что сертификат установлен в Личный список сертификатов пользователя ОС, а также наличие связи с закрытым ключом:

1.1. Под пользователем ОС (см. выше, как определить) запустить консоль сертификатов – certmgr.msc

Ошибка при получении свойства сертификата 2.png

1.2. В консоли развернуть папку «Личное» и перейти в «Сертификаты».

Ошибка при получении свойства сертификата 3.jpg

1.3. Открыть проблемный сертификат.

Ошибка при получении свойства сертификата 4.jpg

 В сведениях о сертификате не должно быть красного креста или восклицательного знака.

Ошибка при получении свойства сертификата 5.jpg

  • Восклицательный знак обозначает, что цепочка до корневого сертификата не построена.
  • Красный крест обозначает, что сертификат истек или не выстроена цепочка сертификатов до корневого.

С подробной инструкцией как построить цепочку сертификатов, можно ознакомиться по

ссылке

.

В нижней части должен отображаться значок ключа с надписью: «Есть закрытый ключ для этого сертификата», если данный значок отсутствует, то это означает, что закрытого ключа нет (как это исправить – см. п. 2).

2. Проверка связи и перепривязка средствами криптопровайдера:

2.1. В сеансе пользователя ОС (без повышения прав) переустановить сертификат в Личное хранилище сертификатов с привязкой к закрытому ключу(Инструкция по переустановке http://my-sertif.ru/handbook/28/4008/).

2.2. Если сертификат установлен в Личном хранилище сертификатов администратора ОС (т.е. в реестре администратора), тогда нужно его (вместе с закрытым ключом) экспортировать в файл средствами Windows (в файл pfx). А затем импортировать в сеансе пользователя ОС, из под которого выполняется запуск 1С без повышения прав. Для этого необходимо в сертификате перейти на вкладку «Состав» и нажать «Копировать в файл…»

Ошибка при получении свойства сертификата 6.png

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

Ошибка при получении свойства сертификата 7.jpg

На следующем шаге автоматически определится предпочтительный формат экспортируемого файла (.PFX). Необходимо нажать «Далее».

Ошибка при получении свойства сертификата 8.jpg

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

Ошибка при получении свойства сертификата 9.jpg

На следующем шаге мастера экспорта сертификатов требуется указать имя файла и доступную директорию компьютера.

Ошибка при получении свойства сертификата 10.jpg

И завершить экспорт. 

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

Ошибка при получении свойства сертификата 11.jpg

В поле «Расположение хранилища» выбрать «Текущий пользователь» и нажать «Далее».

Ошибка при получении свойства сертификата 12.jpg

Импортируемый файл определится автоматически.

Ошибка при получении свойства сертификата 13.jpg

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

Ошибка при получении свойства сертификата 14.jpg

После чего завершить импорт сертификата, выбрав «Автоматически выбрать хранилище на основе типа сертификата».

Ошибка при получении свойства сертификата 15.jpg

И выполнить рекомендации из статьи  http://my-sertif.ru/handbook/28/4008/

Если криптосредство (КриптоПро, VipNet) не запускается без повышения прав в сеансе пользователя ОС, из-под которого выполняется запуск приложений 1С (запуск сервера 1С или web-сервера для файловой ИБ), рекомендуется выполнить переустановку криптосредства, чтобы оно было доступно в сеансе пользователя ОС, из-под которого выполняется запуск приложений 1С (и/или сервера/web-сервера).

Также вам может быть интересно:

Настройка клиент-серверного подписания электронных документов

Сертификат не найден на компьютере

Настройка криптопровайдера ViPNet CSP для работы с 1С-ЭДО

Google chrome

  1. В окне браузера нажмите кнопку «Настройки» (три точки в правом верхнем углу) → «Дополнительные инструменты» → «Расширения» .
  2. Проверьте наличие «CryptoPro Extension for CAdES Browser Plug-in» и активируйте его.
  3. Если «CryptoPro Extension for CAdES Browser Plug-in» отсутствует в расширениях, перейдите в интернет-магазин Chrome и установите его, затем повторите шаг 2.

В правом верхнем углу в списке активированных расширений должен появиться значок CryptoPro Extension for CAdES Browser Plug-in, что свидетельствует о правильной установке.

Государственные и коммерческие предприятия

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

На просторах России сертифицированные криптопровайдеры предоставляют не так уж и много компаний: ООО «КРИПТО-ПРО», ООО «Лисси», ОАО «ИнфоТеКС», ЗАО «Сигнал-КОМ» и некоторые другие. Программа CyberSafe поддерживает работу с сертифицированным криптопровайдером от ООО «КРИПТО-ПРО», что обеспечивает возможность формирования и проверки электронной подписи в соответствии с отечественными стандартами ГОСТ Р 34.11-94 / ГОСТ Р 34.11-2021 и ГОСТ Р 34.10-2001 / ГОСТ Р 34.10-2021.

Криптография, электронная подпись и pki

Криптография и инфраструктура открытых ключей PKI

В данной статье мы рассмотрим, что такое Инфраструктура открытых ключей (PKI), как она устроена на логическом уровне, для чего используется, а также попытаемся выявить её плюсы и минусы. Никакой математики – только логика работы. При подготовке материала использовались лекции Антона Карпова о PKI, которые можно найти на YouTube.

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

Для начала разберемся для каких целей в наши дни применяется криптография:

  • Конфиденциальность – невозможность прочтения информации посторонним;
  • Целостность данных – невозможность незаметного изменения информации;
  • Аутентификация – проверка подлинности авторства или иных свойств объекта;
  • Апеллируемость – невозможность отказа от авторства.
Про сертификаты:  Какие нужны документы для новорожденного ребенка: перечень необходимых документов

Интересно, что конфиденциальность сообщений интересовала людей еще в Древнем мире. Наверное, образно можно говорить о том, что шифрование появилось с того момента, когда люди научились писать. Некоторые из ранних упоминаний о шифровании сообщений датируются пятым веком до н.э. Если читателя интересует история шифрования, рекомендуем к прочтению книгу Саймона Сингха “Книга шифров. Тайная история шифров и их расшифровки”. В данном труде автору удается изложить историю шифрования, начиная с древних времен и первого исторического произведения Геродота о греко-персидских войнах, до наших дней и появления квантовой криптографии – в достаточно увлекательной и захватывающей манере. В общем – категорически рекомендуем!

Ну а мы рассмотрим два принципиальных вида алгоритмов шифрования: симметричные алгоритмы шифрования и асимметричные алгоритмы шифрования.

В симметричных алгоритмах шифрования используется один и тот же ключ как для шифрования, так и для дешифрования сообщения. Таким образом, если в обмене сообщениями участвуют два субъекта, у обоих будет одинаковый ключ шифрования/дешифрования. Преимуществом данных алгоритмов шифрования является скорость работы и простота реализации. Основной же проблемой этого вида шифрования является общий ключ шифрования/дешифрования. Безопасная передача этого ключа является очень большой проблемой, ведь злоумышленник, перехватив ключ, сможет читать все сообщения. Поэтому в 70-х годах 20-го столетия появилась криптография с открытым ключом. Определяющими факторами для появления ассиметричного вида шифрования явились:

На алгоритмах RSA и Диффи-Хеллмана мы останавливаться не будем, а перейдем к сути криптографии с открытым ключом:

В ассиметричных алгоритмах шифрования для шифрования и дешифрования используются разные ключи, математически связанные между собой. Такие ключи называются ключевой парой. Один из них – закрытый (private key), другой является открытым (public key). Сообщение, которое было зашифровано на открытом ключе, может быть дешифровано только с помощью соответствующего закрытого ключа, и наоборот. Логика следующая:

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

Стоит заметить, что в современных реализациях VPN (в качестве примера можно привести технологию ViPNet), используется комбинация симметричных и асимметричных алгоритмов шифрования. Например, сначала используются асимметричные алгоритмы для получения сессионного симметричного ключа шифрования (алгоритм Диффи-Хеллмана), а уже потом данные шифруются с помощью быстрого симметричного алгоритма с использованием ключа, который был выработан на первом шаге.

В нашем примере всего два субъекта и понятно, что в реальности, субъектов, обменивающихся информацией, будет гораздо больше. При этом открытый ключ не представляет из себя секрета, поэтому мы смело передаем его по открытым каналам. Таким образом, принципиальная проблема симметричных алгоритмов шифрования решена! Больше нет необходимости передавать секрет по открытым каналам связи. Но возникает другая – подтверждение подлинности открытого ключа. К примеру, субъект направляет нам свой открытый ключ и просит зашифровать на нем и отправить ему конфиденциальную информацию. При этом, мы не можем знать, действительно ли субъект является тем, за кого себя выдает, т.е. принадлежит ли открытый ключ нужному адресату. Возможно, что злоумышленник подменил открытый ключ и направил нам. Получив от нас сообщение, он сможет спокойно его расшифровать. Для решения этой проблемы и была придумана Инфраструктура открытых ключей (Public Key Infrastructure).

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

В 1994 году Главным управлением безопасности связи ФАПСИ был разработан первый российский стандарт ЭЦП — ГОСТ Р 34.10-94 “Информационная технология. Криптографическая защита информации. Процедуры выработки и проверки электронной цифровой подписи на базе асимметричного криптографического алгоритма”.

В 2002 году для обеспечения большей криптостойкости алгоритма взамен ГОСТ Р 34.10-94 был введён одноимённый стандарт ГОСТ Р 34.10-2001, основанный на вычислениях в группе точек эллиптической кривой. В соответствии с этим стандартом, термины “электронная цифровая подпись” и “цифровая подпись” являются синонимами.

1 января 2021 года ГОСТ Р 34.10-2001 заменён на ГОСТ Р 34.10-2021 “Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи.” Применение нового ГОСТ Р 34.10-2021 обязательно с января 2021 года – об этом мы уже писали. Если вы используете электронную подпись, нужно убедиться, что ваши средства ЭП поддерживают данный стандарт.

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

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

Парадигма PKI предполагает существование Корневого удостоверяющего центра (Certificate Authority), которому все участники взаимодействия безоговорочно доверяют. Создается иерархическая система доверия, т.е. Корневой УЦ может делегировать полномочия по подтверждению подлинности ключей пользователей другим УЦ. Система доверия выглядит как древовидная цепочка сертификатов УЦ, вплоть до конечного пользователя. Для подтверждения подлинности ключей пользователя, УЦ и выдает пользователям цифровые сертификаты.

Цифровой сертификат – это открытый ключ субъекта, подписанный закрытым ключом УЦ, содержащий в своем составе информацию о субъекте. Сертификаты создаются в соответствии со стандартом X.509, и могут использоваться для подписи, шифрования и аутентификации. Стандарт X.509 мы рассмотрим чуть дальше.

Таким образом, в состав компонентов PKI структуры входят:

  • Корневой УЦ (Root CA)
  • Подчиненные УЦ (Subordinate CA (IntermediateCA))
  • Набор политик и регламентов
  • Каталог выданных сертификатов
  • Каталог отозванных сертификатов

Теперь процесс формирования ключей и обмена сообщениями, описанный ранее, в PKI выглядит следующим образом:

  • Субъект формирует закрытый ключ
  • Субъект формирует запрос на сертификат (CSR – Certificate Signing Request)
  • Субъект отправляет запрос в УЦ
  • УЦ удостоверяет личность владельца запроса и подписывает запрос своим закрытым ключом, выпуская сертификат
  • Вторая сторона получает сертификат субъекта
  • Вторая сторона проверяет действительность сертификата субъекта, используя цепочку вплоть до корневого сертификата УЦ, и шифрует сообщения на нем

Многие УЦ генерируют и выдают субъекту ключевую пару, т.е. открытый и закрытый ключ. Таким образом пользователь сам ничего не создает. При такой схеме возможна компрометация закрытого ключа при выдаче оператором УЦ. С другой стороны, ведь УЦ мы безоговорочно доверяем?

Еще раз остановимся на основном, фундаментальном для PKI требовании – должна быть сущность, которой все доверяют. Этой сущностью является Корневой УЦ. Если в ОС Windows открыть список доверенных корневых сертификатов (certmgr.msc -> Доверенные корневые центры сертификации), можно увидеть более 70 сертификатов УЦ, которым система доверяет по умолчанию.

Список доверенных корневых сертификатов

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

Про сертификаты:  континент ап сертификат —

Например, у Microsoft существует документ “Программа доверенных корневых сертификатов Майкрософт. Требования аудита для центров сертификации”, где описаны общие требования для УЦ.

Кроме того существует программа сертификации WebTrust – это мировой стандарт, определяющий набор правил и критериев для УЦ. Критерии стандарта WebTrust были определены The American Institute of Certified Public Accountants (AICPA) и Canadian Institute of Chartered Accountants (CICA) в 1995 году. Любой крупный УЦ регулярно должен проходить аудит WebTrust.

Сертификаты PKI, выдаваемые согласно стандарту WebTrust, имеют статус проверенных и надёжных на мировом уровне, а также попадают в список доверенных в операционных системах (Windows, MAC OS X и др.) и веб-браузерах.

В Российской Федерации, согласно Федеральному закону от 06.04.2021 N 63-ФЗ “Об электронной подписи”, аналогично с проведением международного аудита по требованиям безопасности, УЦ могут пройти процедуру аккредитации. Требования для аккредитованных УЦ устанавливает Федеральный закон и подзаконные правовые акты Минкомсвязи. Прохождение процедуры аккредитации дает право УЦ выпускать квалифицированные сертификаты электронной подписи. Такие сертификаты имеют юридическую значимость на территории РФ.

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

Структура сертификата:

  • Сертификат
    • Версия
    • Серийный номер
    • Идентификатор алгоритма подписи
    • Имя издателя
    • Период действия:
    • Имя субъекта
    • Информация об открытом ключе субъекта:
      • Алгоритм открытого ключа
      • Открытый ключ субъекта
    • Уникальный идентификатор издателя (обязательно только для v2 и v3)
    • Уникальный идентификатор субъекта (обязательно только для v2 и v3)
    • Дополнения (для v2 и v3)
      • …возможные дополнительные детали
  • Алгоритм подписи сертификата (обязательно только для v3)
  • Подпись сертификата (обязательно для всех версий)

Основные форматы файла сертификата:

Согласно RFC 2459:

  • .CER — сертификат, или набор сертификатов, закодированных по стандарту CER.
  • .DER — сертификат, закодированный по стандарту DER.
  • .PEM — PEM-сертификат, закодированный по стандарту DER и использующий Base64 и помещенный между “—– BEGIN CERTIFICATE —–” и “—– END CERTIFICATE —–“.
  • .P7B, .P7C — PKCS #7 содержит несколько сертификатов или CRL.

Механизмы проверки действительности сертификата:

Любой сертификат в структуре PKI может быть скомпрометирован, поэтому стандарт X.509 предполагает механизмы их проверки. Проверка происходит с использованием “чёрных списков”. Проверка происходит по серийному номеру сертификата. Существуют два основных формата:

  • CRL (Certificate Revocation List) – Список отозванных сертификатов. Публикуется УЦ на регулярной основе в публичных источниках. Имеет время жизни, которое зависит от политик и регламента УЦ. В своем составе CRL содержит серийный номер сертификата, дату и причину отзыва. CRL может содержать один из статусов: отозван (revoked) или приостановлен (hold), хотя приостановление сертификатов на практике практически не используется. Важно понимать, что CRL является оффлайн инструментом и не позволяет проверять статус сертификата в реальном времени.
  • OCSP (Online Certificate Status Protocol) – сетевой протокол, который позволяет проверить статус сертификата в реальном времени. Адрес OCSP-сервера указывается в специальном поле сертификата – CDP (CRL Distribution Point). Важно обеспечить постоянную доступность OCSP-сервера.

C 31 декабря 2021 года начинает действовать редакция Федерального закона N 63-ФЗ “Об электронной подписи”, согласно которой аккредитованный УЦ будет обязан иметь в своем составе OSCP-сервер.

Проблемы стандарта X.509:

  • Нет возможности ограничить подчиненные УЦ в выдаче сертификатов, т.е. если Корневой УЦ выдал сертификат подчиненному УЦ, тот может выпускать какие угодно сертификаты и у корневого УЦ нет механизмов, позволяющих это хоть как-то контролировать. Сама технология этого не предусматривает. Отсюда вытекает следующий момент: вопрос доверия огромному на сегодняшний день количеству корневых УЦ. Разве можно гарантировать, что все они прошли аудит и соблюдают правила выдачи сертификатов и аутентификации клиента перед выдачей? Если вдобавок посмотреть на политическую ситуацию в мире, то становится понятно, что использование поддельных сертификатов может быть крайне эффективным оружием в информационной войне между государствами. В этом смысле, видя решительные попытки перехода на отечественное программное обеспечение, остается только гадать, почему сертификаты для сайтов коммерческих банков, государственных органов, выданы зарубежными УЦ, ведь в процессе обеспечения информационной безопасности, одним из самых важных принципов является комплексность.
  • Остается открытым вопрос: что делать, если недоступны CRL и OCSP? На текущий момент решение одно – УЦ нужно обеспечивать доступность этих компонентов.
  • Что делать в случае компрометации Корневого УЦ? Ответ один: нужно отзывать корневой сертификат. При этом станут недействительны все сертификаты, выданные этим УЦ. Если взять в качестве примера Головной УЦ Минкомсвязи, который является корневым для всех сертификатов, аккредитованных УЦ в России, компрометация Головного УЦ приведет к катастрофическим последствиям в любых отношениях, использующих юридически значимую электронную подпись на территории России. На сегодняшний день насчитывается более пятидесяти сфер использования квалифицированных ЭП в нашей стране – это внешний и внутренний ЭДО, электронные торги, взаимодействие с государственными информационными системами и др.

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

В качестве постскриптума, хочется кратко поговорить о существующих альтернативах и расширениях PKI:

Сеть доверия PGP (Pretty Good Privacy). Подробнее про PGP можно почитать в Интернете. Остановиться хочется именно на идее проверки принадлежности ключа конкретному пользователю. Как и в PKI, при использовании PGP, субъекты должны каким-нибудь способом проверить, что открытый ключ в сертификате действительно принадлежит отправителю. Если в PKI эту задачу решает существование доверенного УЦ, то в PGP используется схема проверки Web of Trust (Сеть доверия). Web of Trust основан на подписи ключей. Вы можете обозначить свое доверие ключу субъекта, которого знаете, подписав его своим ключом. Этот подписанный ключ вы можете отправить на key-server PGP (key-server выступает в роли публичного хранилища открытых ключей пользователя). Затем третье лицо, зная вас и вам доверяя, может обозначить свое доверие и тому лицу, чей ключ вы подписали. Таким образом, собирается сеть доверия. Существуют специальные мероприятия, которые называются PGP Key-signing party, где люди, показывая друг другу свои документы, удостоверяющие личность и открытый ключ (это не шутка), а затем, подписывая проверенные таким образом ключи друг друга, расширяют сеть доверия. Широкого распространения эта технология не получила и используется в довольно узких сферах (команды разработчиков, единомышленников). При этом key-server не играет ключевой роли, ключи могут быть опубликованы где угодно. Но сама идея с подписанными ключами и децентрализованной сетью доверия кажется очень интересной.

Расширение PKI – OCSP stapling. В целях снятия больших нагрузок в инфраструктуре PKI на сервер OCSP придуман механизм OCSP stapling. Он предполагает, что сайт, которому выдан сертификат, в определенные промежутки времени делает запрос в УЦ о статусе своего сертификата. УЦ отвечает метками действительности с проставлением штампа времени. При этом клиент, который заходит на сайт, видит метку УЦ на сертификате сайта, доверяет ему и не обращается к OCSP-серверу.

Расширение PKI – Certificate pinning. В общем случае клиент, который заходит на сервер, получает сертификат сервера, подписанный УЦ. Этот сертификат может быть подменен на сертификат от другого доверенного УЦ, который вдруг был взломан. Данное расширение предполагает, что на клиенте, как правило, в браузерах и мобильных приложениях, прописано соответствие серверов и сертификатов, т.е. прописан список разрешенных для домена сертификатов или УЦ, который хранится в исходных текстах браузера. Этот метод позволяет избежать подмены сертификата за счет сравнения с эталонными в защищенном хранилище браузера. Но этот метод не защищает нас от взлома УЦ, которые есть в списке соответствия данному домену.

Про сертификаты:  Сертификация меха и меховых изделий | ОС "Сертификация"

Convergence. Так же как и в предыдущем пункте, данный метод призван защитить нас от атаки Man in the middle (MITM) или человек посередине, когда злоумышленник прослушивает канал и перенаправляет нас на свой сервер, передающий сертификат, подписанный УЦ, который находится в доверенных списках клиента. При этом мы предполагаем, что УЦ взломан. Распределенная система доверия предполагает, что в сети находятся специальные узлы, которые называются “нотариусами” (их может быть большое количество, расположены они могут быть в разных странах). Сертификаты нотариусов предварительно “зашиты” на клиенте. В момент получения сертификата с сервера, клиент, перед тем как доверять этому сертификату, обращается к “нотариусам” и просит их проверить со своей стороны, какой сертификат отдает целевой сервер при обращении к нему. Каждый нотариус идет на сервер и сравнивает сертификат сервера, который он получает с сертификатом в запросе клиента. При совпадении информации клиент доверяет сертификату сервера. Конечно, данный метод не защищает нас от взлома самого сервера.

Расширение для TLS протокола – TACK. В процессе установления соединения с сервером, клиент заявляет о поддержке расширения TACK и запрашивает TACK-ключ (эту ключевую пару генерирует администратор сервера, у данного ключа настраиваемое время жизни и порядок смены). В ответ сервер передает открытую часть TACK-ключа, сгенерированную администратором сервера. Передача происходит в рамках TLS handshake. Далее сервер передает клиенту сертификат, выданный УЦ, который подписан закрытым TACK-ключом, а клиент проверяет подпись с помощью открытой части TACK-ключа, переданной ранее. Таким образом, ответственность смещается на сторону сервера. Применение этой технологии не защищает от MITM при первоначальном подключении.

Google Key Pinning. Очень сильно похож на TACK. Отличия следующие: TACK – расширение для TLS, GKP – расширение HTTP. Ключи передаются не в рамках TLS handshake, а в заголовках сервера. У ключей GKP нет времени жизни. В целом технологии очень похожи. Стандарт предполагает генерацию резервных ключей совместно с основным ключом. В случае компрометации ключа используются резервные ключи. При этом также остается проблема MITM при первоначальном подключении.

Certificate Transparency. Технология разработана специалистами Google и призвана решить проблему поддельных сертификатов для доменов и их позднего обнаружения. Идея заключается в том, чтобы сделать невозможным создание сертификата для какого-либо домена незаметно для владельца этого домена. Технология предполагает существование трех объектов:

  • Public Logs of Certificates – Постоянно расширяемый, открытый для общего доступа журнал, в который заносятся все выданные сертификаты. Предполагается, что такие журналы будут вести УЦ, записывая в них выданные сертификаты.
  • Public Log Monitoring – Мониторы являются публично запускаемыми серверами, которые периодически связывают все серверы, где ведутся журналы сертификатов и следят за подозрительными сертификатами. Например, мониторы могут определить, был ли выпущен незаконный или несанкционированный сертификат для домена, а также они могут наблюдать за сертификатами, которые имеют необычные расширения, странные разрешения или, например, содержат слабые ключи. Предполагается, что Мониторы развернуты владельцами критических, с точки зрения безопасности передаваемых данных, сайтов, что позволяет отслеживать выдачу сертификатов для своих доменов или просто “неравнодушными” к проблемам безопасного интернета людей.
  • Public Certificate Auditing – Аудиторы – это клиентские программные компоненты, которые выполняют две функции. Во-первых, они могут проверить, что журналы ведут себя корректно и согласовано. Во-вторых, они могут проверить, что конкретный сертификат появляется в журнале. Это особенно важная функция аудита, поскольку для платформы Transparency требуется, чтобы все сертификаты SSL регистрировались в журнале. Если сертификат не был зарегистрирован в журнале, это знак того, что сертификат является подозрительным, и клиенты TLS могут отказаться от подключения к сайтам с такими сертификатами.

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

Также как и любое правило, которое всегда содержит исключения, любая, даже по-настоящему отличная идея, всегда будет содержать в себе недостатки. PKI решает огромную массу задач и, несмотря на имеющиеся в технологии изъяны, является одним из самых значимых применений криптографии в сфере информационных технологий на сегодняшний день. К тому же, давайте говорить прямо, это очень неплохой бизнес для сотен УЦ. Поэтому можно с уверенностью говорить, что PKI будет только расширять свое присутствие в самых различных сферах применения.

Можно ли использовать программу cybersafe?

Одно дело — шифрование личных файлов, но государственный и банковский сектор — совсем другое. Какие нормы позволяют считать CyberSafe программой, использующей сертифицированное ФСБ России СКЗИ и не требующей соответствующей сертификации? Ответ на этот вопрос можно получить в паспорте (формуляре) на программный продукт КриптоПро CSP и в методических рекомендациях по обеспечению с помощью криптосредств безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств автоматизации. Последние утверждены ФСБ России 21 февраля 2008 года № 149/54-144.

В паспорте на КриптоПро CSP читаем п. 1 из раздела 2:

Допускается использование СКЗИ для криптографической защиты персональных данных

Далее открываем методические рекомендации и читаем пункт 1 из раздела 5:

5.1. Встраивание криптосредств класса КС1 и КС2 осуществляется без контроля со стороны ФСБ России (если этот контроль не предусмотрен техническим заданием на разработку (модернизацию) информационной системы).

Настройка браузеров

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

Принцип работы[]

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

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

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

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

Российские стандарты[]

В России действуют свои криптографические стандарты. Использование их совместно с сертификатами описано в RFC4491: Using GOST with PKIX.

ar:شهادات رقميةca:Certificat digitalcs:

Digitální certifikátde:Digitales Zertifikatel:

Ψηφιακό πιστοποιητικόen:Public key certificatees:Certificado digitalfa:گواهی دیجیتالfr:Certificat électroniqueit:

Certificato digitaleja:公開鍵証明書nl:Certificaat (PKI)pl:

Certyfikatpt:Certificado digitaluk:

Цифровий сертифікатvi:Chứng thực khóa công khaizh:電子證書

Структура сертификата[]

Перечень обязательных и необязательных полей, которые могут присутствовать в сертификате, определяется стандартом на его формат (например, X.509). Как правило, сертификат включает в себя следующие поля:

Яндекс.браузер

  1. В браузере откройте меню (три полоски в правом верхнем углу) → «Дополнения».
  2. Проверьте наличие «КриптоПро ЭЦП» и активируйте его.

Выводы

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

Оцените статью
Мой сертификат
Добавить комментарий