Хранилище ключей эцп что выбрать

Как и где можно хранить электронную подпись

Защищенные носители для квалифицированной электронной подписи

Токен (eToken, Рутокен и др.)

Надежный и удобный носитель в виде USB-брелока. Подходит для большинства применений, кроме ЕГАИС. С его помощью можно отправить отчет в налоговую или Росстат, подписать договор и участвовать в электронных торгах. Чтобы подписывать документы с помощью токена, на компьютер нужно установить средство криптографической защиты информации (СКЗИ).

Токен со встроенным СКЗИ (Рутокен ЭЦП, Рутокен ЭЦП 2.0, JaCarta PKI/ГОСТ/SE)

Носитель, который похож на обычный токен, но обладает встроенным СКЗИ. Используя электронную подпись на таком носителе, вы сможете подписывать документы на любом компьютере без покупки дополнительного ПО. Рутокен ЭЦП подходит для дистанционного банковского обслуживания, работы на госпорталах, сдачи отчетности и документооборота. Он не предназначен для работы с торговыми площадками и ЕГАИС. Рутокен ЭЦП 2.0, как и JaCarta PKI/ГОСТ/SE, используются только для работы с ЕГАИС.

Дополнительная защита электронной подписи

Доступ к подписи по пин-коду

На каждом съемном носителе электронной подписи установлен пин-код — комбинация символов, после ввода которой вы получаете доступ к подписи. Вводится пин-код каждый раз при подписании документа или любом другом обращении к ЭП. По умолчанию код стандартный, но вы можете убрать его совсем или поменять на свой. Мы подготовили инструкцию по смене для Рутокен, eToken, JaCarta. Если нужно, обратитесь в УЦ, и наш специалист поможет сменить пин-код.

Защита подписи от копирования

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

Незащищенные носители для квалифицированной электронной подписи

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

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

О чем нужно помнить при хранении квалифицированной ЭЦП

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

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

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

При смене реквизитов меняйте и ЭП
Компания изменила свое название, владелец ЭП уволился или поменял должность? Меняйте подпись. Не затягивайте с этим, чтобы не столкнуться с пачкой платежек, подписанных неизвестно кем, и не нарушать п. 1 ст. 2 Федерального закона №63-ФЗ «Об электронной подписи», требующий обеспечить точную идентификацию владельца ЭП. Для замены электронной подписи обратитесь к менеджеру, который ее выдавал. Или свяжитесь с удостоверяющим центром «Тензор» удобным для вас способом.

Вовремя продлевайте ЭП
Если не продлить электронную подпись, она станет недействительной. И вы не сможете подписать ни один электронный документ, пока не получите новую ЭП в удостоверяющем центре. О том, как продлить электронную подпись, читайте в нашей статье.

Защитите рабочее место
Антивирусное ПО защищает вас от любых неприятных сюрпризов. Вирусы способны имитировать поведение владельца подписи, чтобы подписать несколько нужных злоумышленнику документов. И доказать, что подпись ставили не вы, будет тяжело.

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

Источник

Электронная подпись для чайников: с чем ее есть и как не подавиться. Часть 2

Продолжая раскрывать тайное знание о цифровой подписи простым языком, разберем, что же нам надо для удобной и эффективной работы с ними, а также главное различие между лагерями S/MIME + X.509 и PGP.

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

Каждую из частей информации можно передать вместе с открытым ключом, или вместе с нашей подписью, а можно и с тем и с тем, для большего удобства. Конечно, можно не разделять информацию на передаваемую с открытым ключом и передаваемую с подписью. Но тогда каждый раз отправляя подписанную информацию мы отправляем одно и то же. Как если бы к каждому отправляемому нами бумажному письму (даже короткому, в две строки), мы бы прикладывали дополнение вида «Здравствуйте! Это я, В. Пупкин, которого вы встречали на Красной площади Москвы, где мы и познакомились, потом пошли в ресторан, потом ». Согласитесь, слегка неудобно.

Но вернемся к нашей информации, необходимой для проверки подписи.
Начнем с простого: информация, которая позволит нам узнать, кто же сделал эту подпись. Как мы уже договорились, ассиметричное шифрование позволяет однозначно связать наш открытый ключ и полученную подпись. Беда в том, что сам по себе открытый ключ – набор байт. При этом он, конечно, связан с закрытым, которым мы (то есть отправитель) владеем, но связь эта для получателя неочевидна. У него есть набор байт от В. Пупкина, от И. Петрова, от С. Сидорова… И от десятка других людей. И как ему их идентифицировать? Держать отдельный реестр для того, кому какой набор байт принадлежит? Это что же, получается уже второй реестр (помимо того, где должно быть записано, с помощью какой хэш-функции какой хэш сделан)! И опять, неудобно!

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

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

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

А собственно, что «и»? Мы ведь пока так и не решили проблему, как донести до получателя информацию о том, какая хэш-функция применялась для хэша, а ведь для проверки подписи эта информация необходима! Решить ее можно достаточно просто: положить эту информацию в контейнер вместе с нашим открытым ключом. Ведь именно связка «хэширование – шифрование результата хеширования» считается процедурой создания цифровой подписи, а ее результат – подписью. А значит, достаточно логичным представляется объединение в связку алгоритма шифрования хэша и хэш-функции, с помощью которой он сформирован. И доставлять эту информацию тоже надо в связке.

Теперь, ненадолго вернемся к информации о подписывающем. Какого рода эта информация должна быть? ФИО? Нет, В. Пупкиных много. ФИО + год рождения? Так и родившихся в один день В. Пупкиных тоже предостаточно! Более того, это может быть Василий, Виктор, или даже Василиса или Виктория Пупкины. Значит, информации должно быть больше. Ее должно быть столько, чтобы совпадение всех параметров, по которым мы идентифицируем человека, было максимально невероятным.

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

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

Применяя этот же подход к контейнерам открытых ключей, мы получим, что у каждого контейнера должен быть некий номер, последовательность символов, уникальная для него. Эту последовательность символов принято называть идентификатором, а сами контейнеры – сертификатами, либо просто ключами.
Вот здесь и начинаются принципиальные различия в идеологиях OpenPGP и S/MIME + X.509. Для краткого понимания их, вернемся к нашей аналогии с паспортом.

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

Так же можно разделить и эти два лагеря.

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

PGP же (и стандарт OpenPGP, появившийся в дальнейшем) создавался на основе так называемых сетей доверия. Такая идея подразумевает, что обмениваются подписями люди, которым третья сторона для их взаимоотношений не нужна, а нужна только защита от нехороших лиц.

Конечно, с течением времени такое разделение стало уже достаточно условным, так как на данный момент и в S/MIME+X.509 и в PGP можно использовать методы лагеря соперников. Но все же, стандарты достаточно продолжительное время развивались параллельно и развились до той степени, что взаимная совместимость между ними стала невозможной.

Более популярным стандартном, в силу своей ориентированности на участие более компетентной третьей стороны, стал стандарт S/MIME + X.509, однако и у PGP есть некоторое количество козырей за пазухой, с помощью которых он не только не погибает, но и продолжает успешно развиваться.
Более подробное рассмотрение каждого из форматов, а также рекомендации, когда, где и какой из них использовать вы сможете прочитать уже в следующих статьях.

Источник

Криптографические решения. От облачной подписи к доверенной среде

Данная статья является продолжением статьи «Криптографические решения. От криптопровайдеров до браузерных плагинов» и охватывает криптографические решения:

Облачная подпись

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

Отдельные браузеры с российской криптографией

Браузеры, созданные на базе open source проектов Mozilla FireFox и Chromium, используют в качестве криптоядра NSS или OpenSSL. OpenSSL поддерживает российские криптоалгоритмы. Для NSS также существуют разработки, которые обеспечивают поддержку российских криптоалгоритмов. Некоторое время назад на рынке появились полнофункциональные браузеры с поддержкой российской криптографии.

Подобное решение обладает большим, на данный момент невостребованным, потенциалом, так как позволяет создавать защищенные стандартные WEB-клиенты для систем с высокими требованиями к безопасности. Еще одним плюсом подобного браузера является его «портабельность». С учетом существования USB-токенов с защищенной FLASH-памятью созданы безопасные решения, в котором наиболее критические операции с закрытом ключом осуществляются на «борту» USB-токена, а сам браузер хранится в его защищенной от модификации FLASH-памяти. Подобное решение кроме высокого уровня безопасности является очень удобным в применении.

На базе NSS

На картинке представлена архитектура решения, реализованная в проекте по расширению NSS aToken.

Отдельные почтовые клиенты с российской криптографией

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

Российская криптография в фреймворках, платформах, интерпретаторах

Microsoft.NET

Расширения классов

В платформе существует набор криптографических классов, в которых предусмотрены механизмы расширения сторонними алгоритмами. Наиболее известным на рынке решением по расширению платформы Microsoft.NET российскими криптоалгоритмами является продукт КриптоПро. NET, представляющий собой надстройку над КриптоПро CSP.
Установка КриптоПро.NET позволяет использовать российские криптоалгоритмы, например,
в WEB-сервисах на базе ASP.NET, SOAP-сервисах, в клиентских браузерных приложениях MS.Silverlight.

Отдельные библиотеки

BouncyCastle — это open source библиотека, в которой реализована своя система криптографических классов для платформы Microsoft.NET. В библиотеке поддерживаются как базовые криптографические алгоритмы ГОСТ 28147-89, ГОСТ Р 34.10-2001, ГОСТ Р 34.11-94, так и криптографические форматы PKCS#7/CMS, PKCS#10, X.509 с учетом специфики, описанной в RFC российских производителей СКЗИ. Кроме того, по утверждениям разработчиков библиотека поддерживает формат CADES с российскими криптоалгоритмами.

Архитектура криптографической системы платформы Java (Java Cryptography Architecture) позволяет расширять набор поддерживаемых в платформе криптоалгоритмов. С учетом большой распространенности Java многие из российских разработчиков криптосредств предлагают сертифицированные JCP-провайдеры.

Java-апплеты

Одним из вариантов использования СКЗИ в браузере является их интеграция в Java-апплеты.
В ряде случаев СКЗИ и криптографические библиотеки не требуют установки и представляют собой нативную библиотеку. В этом случае возможна ее интеграция непосредственно «внутрь» апплета и вызов функций СКЗИ через механизм JNI. При этой схеме библиотека будет инсталлирована в профайл пользователя при первой загрузке Java-апплета в браузере и ее отдельной инсталляции не потребуется.
Другим вариантом является написание Java-апплета, который вызывает предустановленное в системе СКЗИ (CSP, JCP и др.)
Более подробно пример подобной реализации, основанный на использовании Рутокен ЭЦП и OpenSSL, описан в статье habrahabr.ru/company/aktiv-company/blog/134890.

PHP является одним из наиболее распространенных языков WEB-разработки. Криптографическая подсистема PHP построена на базе OpenSSL, в котором есть поддержка российских криптоалгоритмов. Но при этом в самом PHP поддержки российских криптоалгоритмов нет. Некоторые российские производители СКЗИ приступали к формированию патча к PHP, который позволял бы использовать российскую криптографию, но до конца эти работы доведены не были.
Бинарная совместимость таких СКЗИ, как МагПро КриптоПакет, с OpenSSL позволила бы придать данному решению легитимность.
В настоящее время многие разработчики инфосистем на базе PHP используют непосредственный вызов командно-строчной утилиты OpenSSL для проведения криптоопераций с использованием российских алгоритмов.

Экзотическое решение реализовано в рамках проекта Рутокен WEB. В серверной компоненте решения проверка подписи ГОСТ Р 34.10-2001 реализована непосредственно на PHP с использованием математических примитивов из нативной библиотеки.

ams/Crypt-GOST-1.00/GOST.pm.
При этом в реальных проектах на Perl разработчики обычно используют вызовы командно-строчной утилиты из OpenSSL или какого-нибудь Linux-совместимого СКЗИ.

Ruby использует в качестве криптоядра openssl, что позволило автору данной статьи habrahabr.ru/post/231261 пропатчить его для поддержки российской криптографии.

JavaScript

Некоторое время назад на Хабре появилась статья, автор которой реализовал многие криптографические форматы непосредственно на JavaScript
При этом криптоалгоритмы используются из унифицированного ядра WebCrypto, которое уже сейчас поддерживается большинством современных браузеров.
habrahabr.ru/post/221857

Настольные криптографические приложения

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

Средства формирования доверенной среды

На последнем способе формирования ДС хотелось бы остановиться подробнее.

Компанией «Код безопасности» предложен интересный продукт Jinn, который позволяет эмулировать доверенную среду как на многоядерном, так и на одноядерном компьютере. Основной идеей данного решения является то, что доверенная среда выполняется на логических ядрах, на которых не выполняется сама клиентская ОС. В случае одноядерного компьютера now-how решения позволяет реализовать эмуляцию отдельного физического вычислительного устройства, которое не видно ОС (или, вернее, доступ к нему из ОС сильно затруднен).

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

Для доступа к доверенной среде из клиентской ОС используется специальная библиотека (COM-объект). При подписи платежки через данную библиотеку Jinn перехватывает управление графическим адаптером и визуализирует на нем платежку. Если представленная информация верна, то после подтверждения пользователя Jinn подписывает платежку и возвращает управление клиентской ОС.

Источник