Тел./факс:
+7 (495) 780 4820
+7 (495) 660 2330
сайт: http://www.cryptopro.ru
e-mail: info@cryptopro.ru
|
|
|
|
|
127018, Москва, ул.Сущевский Вал д.16 стр.5 Тел./факс: +7 (495) 780 4820 +7 (495) 660 2330 сайт: http://www.cryptopro.ru e-mail: info@cryptopro.ru |
|
|
|
|
|
|
|
Описание основной функциональности криптопровайдера КриптоПро JCP Связь с разработчиком. |
Настоящее руководство содержит общее описание средства криптографической защиты информации (СКЗИ) КриптоПро JCP 1.0, его состав, ключевую систему, рекомендации по размещению технических средств, использующих СКЗИ, рекомендации по проверке целостности установленного ПО СКЗИ, по использованию СКЗИ в различных автоматизированных системах и средствах вычислительной техники.
Инструкции администраторам безопасности и пользователям различных автоматизированных систем, использующих СКЗИ КриптоПро JCP 1.0, должны разрабатываться с учетом требований настоящего Руководства.
Криптопровайдер КриптоПро JCP является средством криптографической защиты информации (СКЗИ КриптоПро JCP 1.0), реализующим российские криптографические алгоритмы и функционирующим под управлением виртуальной машины Java 2 Runtime Environment версии 1.4.2 и выше.
Криптопровайдер КриптоПро JCP должен использоваться с сертифицированными SUN Java-машинами, соответствующим требованиям безопасности SUN. Защищенность криптографических объектов, создаваемых и обрабатываемых криптопровайдером, зависит от степени защищенности и корректности Java-машины, и может быть снижена при использовании виртуальных машин, не имеющих сертификата SUN. Список сертифицированных Java-машин находится на сайте SUN по адресу: http://java.sun.com/j2se/licensees/index.html
Основные направления деятельности администратора безопасности:
Примечание.
Документированная информация с ограниченным доступом по условиям ее правового режима подразделяется на информацию, отнесенную к государственной тайне, и конфиденциальную [РФ.Защита].
ЭД представляет собой задокументированную совокупность данных, зафиксированных на материальном носителе (магнитном или бумажном) с реквизитами, позволяющими идентифицировать эту информацию и авторов документа. Идентификация ЭД обеспечивается средствами защита на основе алгоритмов шифрования, электронной цифровой подписи и защиты от несанкционированного доступа.
ЭД создается участником системы на основе бумажного документа либо на основании другого электронного документа и полностью повторяет его по содержанию. ЭД обрабатываются и хранятся в ЭВМ и могут передаваться по электронным каналам связи.
Шифрование информации - взаимно-однозначное математическое (криптографическое) преобразование, зависящее от ключа (секретный параметр преобразования), которое ставит в соответствие блоку открытой информации, представленной в некоторой цифровой кодировке, блок шифрованной информации, также представленной в цифровой кодировке. Термин шифрование объединяет в себе два процесса: зашифрование и расшифрование информации.
Если зашифрование и расшифрование осуществляются с использованием одного и того же ключа, то такой алгоритм криптографического преобразования называется симметричным, в противном случае - асимметричным.
Прочитать зашифрованное сообщение (информацию) может только пользователь, имеющий тот же закрытый ключ шифрования.
Проверка электронной цифровой подписи под блоком открытой информации производится с помощью криптографического преобразования и открытого ключа, соответствующего закрытому, участвовавшего в процессе установки ЭЦП.
Электронная цифровая подпись обеспечивает целостность сообщений (документов), передаваемых по незащищенным телекоммуникационным каналам общего пользования в системах обработки информации различного назначения, с гарантированной идентификацией ее автора (лица, подписавшего документ). Электронная цифровая подпись позволяет заменить при безбумажном документообороте традиционные печать и подпись. При построении цифровой подписи вместо обычной связи между печатью или рукописной подписью и листом бумаги выступает сложная математическая зависимость между электронным документом, закрытым и открытым ключами.
Практическая невозможность подделки электронной цифровой подписи опирается на очень большой объем определенных математических вычислений.
Проставление подписи под документом не меняет самого документа, она только дает возможность проверить подлинность и авторство полученной информации.
СКЗИ КриптоПро JCP 1.0 является криптопровайдером Java и предназначено для защиты конфиденциальной информации.
СКЗИ КриптоПро JCP 1.0 совместимо КриптоПро CSP по выполняемым криптографическим функциям и ключам (см. Совместимость с продуктами КриптоПро).
Средствами СКЗИ КриптоПро JCP не допускается защищать информацию, составляющую государственную тайну.
СКЗИ КриптоПро JCP при условии выполнения настоящих Правил обеспечивает криптографическую защиту конфиденциальной информации от внешнего нарушителя, самостоятельно осуществляющего создание методов и средств реализации атак, а также самостоятельно реализующего атаки.
СКЗИ КриптоПро JCP 1.0 функционирует под управлением следующих Java-машин:
Алгоритм зашифрования/расшифрования данных и вычисление имитовставки реализован в соответствии с требованиями ГОСТ 28147 89 "Системы обработки информации. Защита криптографическая".
Алгоритмы проверки ЭЦП реализованы в соответствии с ГОСТ Р 34.10 94 "Информационная технология. Криптографическая защита информации. Процедуры выработки и проверки электронной цифровой подписи на базе асимметричного криптографического алгоритма" и ГОСТ Р 34.10 2001 "Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи".
Алгоритмы формирования ЭЦП реализованы в соответствии с ГОСТ Р 34.10 2001 "Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи".
Алгоритм выработки значения хэш-функции реализован в соответствии с требованиями ГОСТ Р 34.11 94 "Информационная технология. Криптографическая защита информации. Функция хеширования".
Ключевая система СКЗИ КриптоПро JCP обеспечивает возможность парно-выборочной связи абонентов сети с использованием для каждой пары абонентов уникальных ключей, создаваемых на основе принципа открытого распределения ключей.
Формирование закрытых ключей может производиться на следующие ключевые носители:
Примечания.
Размеры ключей электронной цифровой подписи:
Размеры ключей, используемых при шифровании:
Возможна ситуация, когда установленная JRE имеет экспортные ограничения.
США запрещает экспорт "сильной" криптографии и JCP с длиной ключа
256 бит попадает под это ограничение.
Ограничения устанавливаются файлами local_policy.jar
и US_export_policy.jar
в каталоге <JRE>/jre/lib/security.
Для снятия экспортных ограничений
необходимо скачать файл jce_policy-6.zip с политиками со страницы
http://java.sun.com/javase/downloads/index.jsp
, выбирая "Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files 6".
Для отладки же можно просто скопировать US_export_policy.jar в local_policy.jar
(оба файла должны присутствовать).
КриптоПро JCP 1.0 позволяет:
GostCertificateRequest запроса для удостоверяющего центра Microsoft CA с установленным на нем СКЗИ
КриптоПро CSP 2.0 и выше, а также для удостоверяющего центра КриптоПро УЦ 1.3 и выше;keytool запроса для удостоверяющего центра Microsoft CA с установленным на нем СКЗИ
КриптоПро CSP 2.0 и выше, а также для удостоверяющего центра КриптоПро УЦ 1.4.КриптоПро JCP 1.0 совместим с КриптоПро CSP 3.6 по выполняемым криптографическим функциям, форматам данных и ключам со следующими ограничениями:
Он совместим с КриптоПро CSP 3.0 по выполняемым криптографическим функциям, форматам данных и ключам со следующими, дополнительными к 3.6 ограничениями:
Он совместим с КриптоПро CSP 2.0 только по выполняемым криптографическим функциям и форматам данных со следующими, дополнительными к 3.0 ограничениями:
Он совместим с КриптоПро УЦ 1.3/1.4 по форматам данных со следующими ограничениями:
В CSP 3.0 на Unix-системах ключи хранились в каталоге
/var/CPROcsp/keys/${user.name}.
В CSP 3.6 ключи хранятся /var/opt/cprocsp/keys/${user.name}.
Пути к блокировкам соответсвенно поменялись с /var/CPROcsp/tmp на /var/opt/cprocsp/tmp.
Если Вы используете на одном компьютере и JCP и CSP необходимо настроить пути к ключам в соответствии в версией CSP. Это можно сделать средствами контрольной панели, из командной строки или программно.
КриптоПро JCP 1.0 совместим с КриптоПро PDF при условии использования PDF с расширенными правами. Такой PDF можно сделать, например, в Adobe LiveCycle и Adobe Acrobat Pro. Для создания подписи в файле формата PDF с расширенными правами с помощью КриптоПро JCP можно, например, использовать свободную библиотеку iText. Такая подпись будет видна в PDF-файле при просмотре через Adobe Reader, а если установлены КриптоПро CSP и КриптоПро PDF, то она сможет провериться.
Основной архитектурной особенностью ПО СКЗИ КриптоПро JCP является то, что ПКЗИ не имеет непосредственного доступа к ключевой и криптографически значимой информации. Все операции с закрытыми ключами, незавершенными значениями хэш-функций и т. п. осуществляется недоступные пользователю объектов; операции экспорта отсутствуют.
В состав программного обеспечения для всех платформ входят СКЗИ КриптоПро JCP и ПКЗИ.
Общая структура СКЗИ КриптоПро JCP 1.0 представлена на рис.
В состав СКЗИ КриптоПро JCP входят:
В состав ПКЗИ входят следующие компоненты:
СКЗИ КриптоПро JCP является системой с открытым распределением ключей. Открытые ключи подписи обычно представляются в виде сертификатов открытых ключей.
В СКЗИ КриптоПро JCP закрытый ключ подписи может быть использован только для формирования ЭЦП. Закрытый ключ шифрования может быть использован как для формирования ключа связи с другим пользователем, так и для формирования ЭЦП.
При работе с СКЗИ каждый пользователь, обладающий правом подписи и/или шифрования, вырабатывает на своем рабочем месте или получает у администратора безопасности (в зависимости от принятой политики безопасности) личные закрытый и открытый ключи. На основе каждого открытого ключа третьей стороной (Центром Сертификации) формируется сертификат открытого ключа.
Должны быть приняты меры, обеспечивающие сохранение в тайне закрытых ключей электронной подписи и шифрования и соответствующий порядок работы с ключевой документацией и сертификатами открытых ключей.
В СКЗИ КриптоПро JCP ключ зашифрования сообщения совпадает с ключом расшифрования (общий закрытый ключ связи). При зашифровании сообщения пользователя A для пользователя Б общий закрытый ключ связи вырабатывается на основе закрытого ключа шифрования пользователя А и открытого ключа шифрования пользователя Б. Соответственно, для расшифрования этого сообщения пользователем Б формируется общий закрытый ключ связи на основе своего собственного закрытого ключа шифрования и открытого ключа шифрования пользователя А.
Таким образом, для обеспечения связи с другими абонентами каждому абоненту необходимо иметь:
Закрытый ключ подписи используется для выработки электронной цифровой подписи. При проверке подписи проверяющий должен располагать открытым ключом (сертификатом) пользователя, поставившего подпись. Проверяющий должен быть полностью уверен в подлинности открытого ключа, а именно в том, что имеющийся у него открытый ключ соответствует открытому ключу конкретного пользователя. Для этой цели используется сертификат открытого ключа, подписанный третьей доверенной стороной. Каждому пользователю, обладающему правом подписи, необходимо иметь:
При формировании закрытые ключи СКЗИ КриптоПро JCP записываются на ключевой носитель (ключевой контейнер).
Ключевой контейнер может содержать:
КриптоПро JCP может создавать ключевой контейнер состоящий только из ключа подписи или только из ключа шифрования. При создании ключа, если существует контейнер с тем же именем (alias), то он будет уничтожен и на его место будет создан новый контейнер.
Если ключевой контейнер был создан, не с помощью КриптоПро JCP (например, при помощи КриптоПро CSP), то в качестве ключа для выработки ЭЦП будет использоваться
Дополнительно ключевой контейнер содержит служебную информацию, необходимую для обеспечения криптографической защиты ключей, их целостности и т. п.
Каждый ключевой контейнер (независимо от типа носителя), является самодостаточным и содержит всю необходимую информацию для работы как с самим контейнером, так и с закрытыми (и соответствующими им открытыми) ключами.
Ключевой контейнер содержит следующую информацию: главный ключ, маски главного ключа, контрольную информацию главного ключа, вторичный ключ (опциональный), резервную копию ключевого контейнера.
Каждый закрытый ключ хранится в формате, дополнительно содержащем все константы, необходимые для формирования открытого ключа.
Структура ключевого контейнера обеспечивает чтение ключей и соответствующих масок отдельными операциями в раздельные области памяти, для чего он разбит на шесть зон (реализация зон зависит от типа ключевого носителя).
Ключевой контейнер содержит также дополнительную информацию, необходимую для обеспечения восстановления контейнера, при возникновении различных программно-аппаратных сбоев (дополнительная информация включается в тех случаях, когда размер ключевого контейнера не ограничен размерами памяти физического носителя).
Личные ключевые носители пользователей рекомендуется хранить в сейфе. Пользователь несет персональную ответственность за хранение личных ключевых носителей.
При наличии в организации, эксплуатирующей СКЗИ, администратора безопасности, и централизованном хранении ключевых носителей, администратор безопасности организации несет персональную ответственность за хранение личных ключевых носителей пользователей. Личные ключевые носители администратора безопасности должны храниться в его личном сейфе.
Требования по хранению личных ключевых носителей распространяются на ПЭВМ (в том числе и после удаления ключей с диска).
Настоятельно рекомендуется использовать парольную защиту при хранении ключей на ЖМД.
При необходимости передачи ключевого носителя постороннему, информацию с него необходимо гарантированно удалить.
При использовании ключей обязательным является выполнение условий:
Ключи на ключевых носителях (включая смарт-карты), срок действия которых истек, уничтожаются путем удаления ключевых контейнеров средствами ПО СКЗИ или с помощью Контрольной Панели, после чего ключевые носители могут использоваться для записи на них новой ключевой информации.
Об уничтожении ключей делается соответствующая запись в "Журнале пользователя сети" (см. Ведение журналов).
Управление ключами может осуществляться при помощи программы keytool входящей в состав Java 2 Runtime или при помощи прикладного программного обеспечения (см. Использование утилиты keytool).
Для обеспечения защиты электронных документов и создания защищенной автоматизированной системы в первую очередь используют криптографические методы защиты, которые позволяют обеспечить защиту целостности, авторства и конфиденциальности электронной информации и реализовать их в виде программных или аппаратных средств, встраиваемых в автоматизированную систему.
Использование криптографических средств требует, как правило, применения также организационно-технических мер защиты.
Следует отметить, что вновь разрабатываемые ПКЗИ и прикладное ПО, использующие сертифицированные СКЗИ должны удовлетворять требованиям к СКЗИ в части корректности использования СКЗИ и в части проверки влияния на СКЗИ со стороны ПО. Поэтому, в соответствии с российскими законами, встраивание СКЗИ могут производить организации, имеющие лицензию на право проведения таких работ, а работы по встраиванию должны проводиться в соответствии с Положением ПКЗ 2005 [ПКЗ-2005].
При создании защищенной автоматизированной системы необходимо определить модель угроз и политику ее безопасности. В зависимости от политики безопасности определяется необходимый набор криптографических функций и организационно-технических мер, реализуемых в создаваемой системе.
СКЗИ КриптоПро JCP в первую очередь предназначено для встраивания в прикладное программное обеспечение. Функции СКЗИ КриптоПро JCP, могут быть использованы:
Ниже приведен основной перечень требований, реализуемых при помощи криптографических методов.
При передаче данных в сети обеспечивается использованием функций шифрования. Для обеспечения защиты от НСД к информации при хранении (на дисках, в базе данных) допускается использование шифрования на производном (например, от пароля) ключе.
При сетевом взаимодействии (установлении сеанса связи) обеспечивается функциями ЭЦП при использовании их в процессе аутентификации (например, в соответствии с рекомендациями Х.509 [X.509]). Одновременно при аутентификации должна использоваться защита от переповторов. Для этих целей может использоваться функция имитозащиты с вычислением имитовставки на сессионном ключе (симметричный ключ шифрования).
При электронном документообороте обеспечивается использованием функций ЭЦП электронного документа. Дополнительно должна быть предусмотрена защита от навязывания, переповтора электронного документа и целостность справочников открытых ключей ЭЦП.
Обеспечивается использованием функций ЭЦП электронного документа. При использовании функций шифрования (без использования ЭЦП) обеспечивается имитозащитой.
Для обеспечения целостности хранимых данных может быть использована функция хеширования или имитозащиты, но при этом не обеспечивается авторство информации.
Обеспечивается использованием функций ЭЦП (подпись документа отправителем) и хранением документа с ЭЦП в течение установленного срока приемной стороной.
Обеспечивается использованием функций ЭЦП и квитированием приема документа (подпись квитанции получателем), хранением документа и квитанции с ЭЦП в течение установленного срока отправляющей стороной.
Обеспечивается использованием криптографических функций ЭЦП, шифрования или имитозащиты с добавлением уникального идентификатора сетевой сессии (электронного документа) с последующей их проверкой приемной стороной или разработкой специализированного протокола аутентификации (обмена электронными документами).
Защита от нарушителя с целью навязывания им приемной стороне собственной информации, переданной якобы от лица санкционированного пользователя (нарушение авторства информации). Обеспечивается использованием функций ЭЦП с проверкой атрибутов электронного документа и открытого ключа отправителя. В случае навязывания информации про компрометации ключа обеспечивается организационно-техническими мероприятиями. Например, созданием системы централизованного управления ключевой информацией (оповещением абонентов) или специализированных протоколов электронного документооборота.
Обеспечивается совместным использованием криптографических средств и организационных мероприятий (см. Требования по защите от НСД).
При встраивании СКЗИ КриптоПро JCP в прикладное программное обеспечение или использовании его в составе стандартного прикладного ПО должны выполняться следующие требования:
Sun Java System Identity Manager обеспечивает применение различных алгоритмов ЭЦП для управлениями правами доступа к информационным ресурсам.
Специалистами компаний Sun Microsystems и КРИТПО-ПРО были совместно выполнены интеграция и тестирование совместной работы Sun Java System Identity Manager со средством криптографической защиты КриптоПро JCP.
Произведенная интеграция позволяет использовать реализованные в КриптоПро JCP российские криптографические алгоритмы ГОСТ Р 34.10-2001 и ГОСТ Р 34.11-94 для заверения российской электронной цифровой подписью заявок на получение доступа к ресурсам, используя стандартные интерфейсы в рамках автоматизированного бизнес-процесса системы Sun Java System Identity Manager. Применение российского средства ЭЦП и сертификатов ключей ЭЦП гарантирует, что заявка исходит именно от того лица, которое уполномочено на такие действия (руководители, сотрудники службы безопасности и т.д.). Формирование заявок и ЭЦП производится непосредственно с помощью разработанных web-форм для согласующих лиц. Информация об одобрении заявки, вместе с ЭЦП, хранится в репозитории Identity Manager и может быть предоставлена в виде отчета, необходимого для проведения аудитов по информационной безопасности.
Для интеграции Sun IdM и КриптоПро JCP:
При установке и настройке IdM по документации http://docs.sun.com/source/819-6124/Ch8_java8.html. пункт 3.11 ("Log in to Identity Manager on the port you specified when you installed your applications server.") в процессе установки преждевременный. Сразу входить не надо, сначала надо настроить права по пункту 5.
security.nonrepudiation.signedApprovals=true
Войдите на отладочную страницу Identity Manager http://PathToIDM/debug. Загрузится страница с системными настройками. У пункта "List Objects" надо выбрать из выпадающего меню "Configuration" и нажать "List Objects", появится страница "List Objects of type: Configuration". У пункта "System Configuration" надо выбрать "Edit", появится файл содержащий системную конфигурацию. Его надо отредактировать, установив signedApprovals=true.
<Attribute name='nonrepudiation'>
<Object>
<Attribute name='signedApprovals'>
<Boolean>true</Boolean>
</Attribute>
</Object>
</Attribute>
В документации сказано: "From the Administrator interface, select Configure, and then select Certificates". В седьмой версии пункт меню Sertificates реально находится в меню Security.
Именно ts1.jar проставляет подпись на клиенте. Подпись не на ГОСТ-овских алгоритмах, нужна для того, чтобы разрешить выполнение кода на клиентской машине.
В файле samples_src.jar в каталоге SunIdM находятся
две модифицированные формы IdM: "Approval Form.xml" и "Work Item Configuration.xml".
В них добавлены параметры supportedKeyStoreTypes и keytypeSignatureMapping для полей типа TransactionSigner.
<Property name='keytypeSignatureMapping' value='DSA=SHA1withDSA,RSA=SHA1withRSA,RSA=MD5withRSA,RSA=MD2withRSA,GOST3410=GOST3411withGOST3410EL'/>
<Property name='supportedKeyStoreTypes' value='JKS,PKCS12,HDImageStore'/>
Надо установить в поле supportedKeyStoreTypes типы хранилищ ключей, которые будут использованы на клиентской машине для подписи.
HDImageStore добавлен для примера, установите типы хранилищ, которые будут реально использоваться.
Эти формы необходимо по очереди импортировать в конфигурацию через web-интерфейс, Configure -> Import Exchange File.
Перезагрузите IdM.
Подготовьте хранилища и ключи, которые будут использоваться для подписи. Указания "Obtain a certificate and private key, and then export them to a PKCS#12 keystore." необходимо игнорировать. JCP и PKCS#12 несовместимы.
Управление ключами СКЗИ базируется на архитектуре PKI рекомендаций X 509 в части управления сертификатами открытых ключей и должна обеспечиваться Удостоверяющим центром (УЦ). В качестве УЦ может выступать Удостоверяющий центр КриптоПро УЦ [ЖТЯИ.00009-01 30 01. Удостоверяющий центр "КриптоПро УЦ". Формуляр.], но допускается использование Центра Сертификации корпорации Microsoft (Microsoft Certification Authority), или другие реализации, обеспечивающие выполнение целевых функций.
Рекомендации по управлению ключами приведены для КриптоПро УЦ, основанной на использовании сертификатов открытых ключей и исходя из наличия определенной организационной структуры управления ключами, элементами которой являются:
Примечание.
СКЗИ КриптоПро JCP может использоваться в качестве криптоядра в составе различных прикладных систем, организационные схемы управления ключевой системой которых могут отличаться от рассматриваемой.
Сертификат открытого ключа подписи или шифрования представляет собой структурированную двоичную запись в формате ASN.1, содержащую:
Формат сертификата определен в рекомендациях ITU-T 1997 года X.509 и [X.509] рекомендациях IETF 1999 года RFC 2459. В настоящее время основным принятым форматом является формат версии 3, позволяющий определить расширения (extensions), с помощью которых реализуется определенная политика безопасности в системе.
Ниже приведены рекомендации по управлению ключевой системой на всех этапах ее жизненного цикла, начиная с формирования ключей Центра Сертификации. Рекомендации приведены с учетом наличия Центра Регистрации, являющегося функциональной единицей системы. В случае его отсутствия функции Центра Регистрации выполняет Центр Сертификации, функции администратора ЦР выполняет администратор ЦС.
Удостоверяющий центр является структурным подразделением, обеспечивающим выполнение следующих функций:
В состав программно-аппаратных средств УЦ входят:
Формирование ключей Центра Сертификации производится администратором ЦС следующим образом:
Примечание.
При формировании СОС ЦС и наличии сетевых средств распространения СОС в системе, рекомендуется установить в СОС дополнение Точка распространения СОС (issuingDistributionPoint) с заданием в нем метода доступа, который может быть использован пользователями для регулярного обновления СОС (см. [PKIX], [X.509]).
При формировании закрытого ключа ЭЦП и сертификата ЦС рекомендуется использовать следующие значения. Сроки действия:
Закрытый ключ ЦС и его резервная копия хранятся у начальника УЦ. При необходимости его использования или в начале рабочего дня (смены, при сменной работе), закрытый ключ ЦС выдается администратору ЦС, о чем делается пометка в "Журнале пользователя сети". Рекомендуется не загружать программное обеспечение ЦС без необходимости, а при загруженном ПО, не оставлять закрытый ключ ЦС без контроля администратора ЦС.
Рекомендации, описанные в данном разделе, относятся только к системам, использующим Центр Регистрации.
Администратор ЦС производит регистрацию ЦР в Центре Сертификации, о чем делается запись в "Журнале регистрации администраторов безопасности и пользователей".
При формировании закрытого ключа и сертификата ЦР следует использовать следующие значения.
Сроки действия:
После завершения этих действий Центр Сертификации и Центр Регистрации готовы к регистрации пользователей системы и выпуску сертификатов.
Общая схема, используемая для включения пользователя в систему, состоит из следующих этапов:
Руководство организации-пользователя для регистрации пользователя в сети должно представить в УЦ на имя его начальника с сопроводительным письмом следующие документы (конкретный состав документов определяется Регламентом (Договором) системы:
Формирование ключей пользователя происходит в следующей последовательности.
Примечание.
При регистрации каждого пользователя системы администратор ЦС (ЦР) передает пользователю копию бланка сертификата ЦС, сертификат и СОС ЦС (ЦР).
Карточка оповещения о компрометации
| Пароль УЦ | Основной пароль | Резервный пароль |
| Телефоны администратора ЦР (УЦ) | ||
| Пароль пользователя | Основной пароль | Резервный пароль |
Примечание.
Карточка оповещения используется участниками системы для сообщений о компрометации ключа по телефонным каналам общего пользования. Карточка оповещения должна храниться у пользователя наравне с ключами.
При формировании закрытого ключа и сертификата пользователя следует использовать следующие значения.
Сроки действия:
При наличии в организации администратора безопасности, все описанные ниже действия могут производиться либо администратором безопасности, либо пользователем в присутствии администратора безопасности.
Личный сертификат может быть получен следующими способами:
В любом из перечисленных случаев сертификат не передается пользователю до тех пор, пока Центр Регистрации не получит заверенный бланк запроса на сертификат.
При передаче личного сертификата пользователю ему так же передается заверенный администратором бланк запроса и сертификата пользователя. Вторые копии этих бланков хранятся в ЦС (ЦР).
Повторная регистрация пользователя в Центре Регистрации производится в случае изменения зарегистрированных атрибутов пользователя по инициативе пользователя либо администрации системы.
Заблаговременно (до окончания срока действия закрытого ключа ЦС) администратор ЦС производит формирование нового закрытого ключа и сертификата ЦС (см. Формирование ключей Центра Сертификации).
Сформированный новый сертификат ЦС записывается на магнитный носитель (дискету) и передается в ЦР вместе с бланком сертификата.
При окончании действия закрытого ключа, ключевые носители с закрытым ключом, а также копии закрытого ключа ЦС уничтожаются по Акту комиссией.
Все пользователи системы во время, оставшееся до окончания срока действия закрытого ключа ЦС, обязаны получить новый сертификат ЦС и добавить его в справочники сертификатов, без удаления действующего сертификата ЦС.
Заблаговременно (до окончания срока действия закрытого ключа ЦС) администратор ЦР производит формирование нового закрытого ключа и сертификата ЦР.
Смена ключей Центра Регистрации производится аналогично смене ключей пользователя (см. Смена ключей пользователя).
Все пользователи системы во время, оставшееся до окончания срока действия закрытого ключа ЦР, обязаны получить новый сертификат ЦР.
Пользователь, имеющий действующий сертификат и соответствующий ему закрытый ключ ЭЦП, в любой момент времени (но не позднее недели) до окончания срока действия действующего закрытого ключа, может произвести формирование нового закрытого ключа.
Формирование нового закрытого ключа, запроса на сертификат, передача запроса в ЦР и получение сертификата производится согласно последовательности, описанной в разделе Формирование ключей.
Ключевые носители с закрытым ключом ЭЦП, срок действия которого истек, уничтожаются путем переформатирования (очистки), о чем делается запись в "Журнале пользователя сети".
Определение термина Компрометация, виды компрометации и основные события, приводящие к компрометации, приведены в разделе Основные термины и положения.
По факту компрометации ключей должно быть проведено служебное расследование.
Выведенные из действия скомпрометированные ключевые носители после проведения служебного расследования уничтожаются, о чем делается запись в "Журнале пользователя сети".
В случае компрометации ключа Центра Сертификации вся система должна быть остановлена.
При наличии резервных ключей, система должна полностью перейти на комплект резервных ключей.
Если резервные ключи не были предусмотрены, для восстановления системы необходимо:
Компрометация ключа ЦР не приводит к останову системы. В случае компрометации становится невозможным сетевое взаимодействие между пользователем системы и ЦР в части управления ключевой системой.
В случае компрометации ключа Центра Регистрации должны быть выполнены следующие мероприятия:
Если резервные ключи не были предусмотрены, для восстановления системы необходимо:
При компрометации ключа у пользователя он должен немедленно прекратить связь по сети с другими пользователями.
Пользователь (или администратор безопасности организации) должен немедленно известить ЦР (УЦ) о компрометации ключей пользователя.
Информация о компрометации может передаваться в УЦ по телефону с сообщением заранее условленного пароля, зарегистрированного в "Карточке оповещения о компрометации"
После компрометации ключей пользователь формирует новый закрытый ключ и запрос на сертификат. Так как пользователь не может использовать скомпрометированный ключ для формирования ЭЦП и передачи запроса в защищенном виде по сети, запрос на сертификат вместе с бланками доставляется лично пользователем (администратором безопасности) в Центр Регистрации.
При получении сообщения о компрометации ключа одного из пользователей сети, администратор ЦР оповещает ЦС о необходимости добавления сертификата, соответствующего скомпрометированному закрытому ключу в список отозванных сертификатов. ЦС, при формировании очередного СОС, включает в него отзываемый сертификат.
Дата, с которой сертификат считается недействительным в системе, устанавливается равной дате изготовления СОС, в который был включен отзываемый сертификат.
При наличии сетевых средств распространения СОС, администратор ЦР производит публикацию СОС.
Для рассылки вновь изданного СОС всем пользователям, зарегистрированным в списке рассылки (см. Регистрация пользователя), может быть использована электронная почта.
Сертификат открытого ключа пользователя не удаляется из базы ЦС (ЦР) и хранится в течение установленного срока хранения для проведения (в случае необходимости) разбора конфликтных ситуаций, связанных с применением ЭЦП.
Исключение пользователя из сети может быть осуществлено на основании письменного заявления пользователя в адрес начальника УЦ, заверенного руководством организации. Исключение пользователя из сети производится аналогично действиям при компрометации ключа пользователя. Получив такое заявление, администратор ЦР производит действия описанные в разделе "Действия УЦ при компрометации ключей пользователя".
Периодичность издания СОС Центром Сертификации определяется администрацией системы.
Центр Сертификации может ежедневно издавать СОС и публиковать его в сетевом справочнике (при его наличии).
Для распространения вновь изданного СОС, может быть использована система электронной почты и список рассылки пользователей системы, который формируется при регистрации пользователя (см. Регистрация пользователя).
Пользователи должны регулярно обновлять СОС, хранящийся в локальном справочнике сертификатов с использованием доступных средств.
Администратор УЦ ведет следующие журналы:
Администраторы безопасности организации ведут журнал "Журнал пользователя сети".
В "Журнале регистрации администраторов безопасности и пользователей" фиксируются факты регистрации администраторов ЦС (ЦР), администраторов безопасности организации, пользователей системы.
В " Журнал пользователя сети" записываются факты изготовления и плановой смены ключей, факты компрометации ключевых документов, нештатные ситуации, происходящие в сети, проведение регламентных работ, данные о полученных у администратора безопасности организации ключевых носителях, нештатных ситуациях, произошедших на АРМ с установленным ПО СКЗИ.
В "Журнале пользователя сети" может отражаться следующая информация:
Примечание.
Ориентировочные графы журналов приведены в приложениях (см. Приложение 2 и Приложение 3).
Применение электронной цифровой подписи в автоматизированной системе может приводить к конфликтным ситуациям, заключающимся в оспаривании сторонами (участниками системы) авторства и/или содержимого документа, подписанного электронной цифровой подписью.
Разбор подобных конфликтных ситуаций требует применения специального программного обеспечения для выполнения проверок и документирования данных, используемых при выполнении процедуры проверки соответствия ЭЦП содержимому электронного документа.
Разбор конфликтной ситуации заключается в доказательстве авторства подписи конкретного электронного документа конкретным исполнителем.
Данный разбор основывается на математических свойствах алгоритма ЭЦП, реализованного в соответствии со стандартами Российской Федерации ГОСТ Р 34.10-94, ГОСТ Р 34.10-2001 и ГОСТ Р 34.11-94, гарантирующем невозможность подделки значения ЭЦП любым лицом, не обладающим закрытым ключом подписи.
При проверке значения ЭЦП используется открытый ключ, значение которого вычисляется по значению закрытого ключа ЭЦП при их формировании.
В системе должны быть предусмотрены средства ведения архивов электронных документов с ЭЦП и сертификатов открытых ключей.
Разбор конфликтной ситуации выполняется комиссией, состоящей из представителей сторон, службы безопасности и экспертов. Состав комиссии, порядок ее формирования, регламент работы, рассмотрение результатов определяется в приложении к Регламенту системы (Договору), заключаемому между участниками автоматизированной системы.
Оспаривание результатов работы комиссии и возмещение пострадавшей стороне принесенного ущерба выполняется в установленном действующим законодательством Российской Федерации порядке.
Разбор конфликтной ситуации выполняется по инициативе любого участника автоматизированной системы и состоит из:
Разбор конфликтной ситуации проводится с использованием программного обеспечения СКЗИ КриптоПро JCP для электронного документа, авторство или содержание которого оспаривается.
Проверка подписанного электронного документа включает в себя выполнение следующих действий:
При проверке ЭЦП документа, верификации цепочки сертификатов, отсутствии сертификата в СОС, авторство подписи под документом считается установленным.
Примечание. Несовпадение даты формирования документа и сроков действия сертификата и/или сроков действия закрытого ключа не влияют на определение авторства документа. На их основе можно сделать предположение о несоблюдении пользователем Регламента (Договора) в части сроков действия ключей, сертификатов или некорректного использования сертификата в прикладном ПО.
При не обнаружении в архиве сертификата открытого ключа пользователя, выполнившего ЭЦП, доказать авторство документа невозможно. В связи с этим, архив с сертификатами открытых ключей необходимо подвергать регулярному резервному копированию и хранить в течение всего установленного срока хранения.
Ниже приведен основной перечень нештатных ситуаций и соответствующие действия персонала при их возникновении.
| Нештатная ситуация | Действия персонала |
|---|---|
| Эвакуация, угроза нападения, взрыва и т.п., стихийные бедствия, аварии общего характера в Центре управления ключевой системой. | Остановить все ЭВМ.
Персонал, имеющий доступ к ключам, обязан сдать все имеющиеся у него в наличии ключевые носители администратору безопасности. Администратор безопасности упаковывает все ключевые носители, регистрационные карточки сертификатов открытых ключей пользователей в опечатываемый контейнер, который выносит в безопасное помещение или здание. Опечатанный контейнер должен находиться под охраной до окончания действия нештатной ситуации и восстановления нормальной работы аппаратных и программных средств СКЗИ. Администратор безопасности оповещает по телефонным каналам общего пользования всех пользователей о приостановке работы системы. В случае наступления события, повлекшего за собой долговременный выход из строя аппаратных средств СКЗИ, администратор безопасности уничтожает всю ключевую информацию с носителей, находящихся в контейнере. |
| Компрометация одного из личных ключевых носителей. | Порядок действий при компрометации ключей описан в разделе Компрометация ключей пользователя. |
| Выход из строя первого личного ключевого носителя. Аналогично для смарт-карт. |
Необходимо сообщить по телефону в УЦ о факте выхода из строя личного ключевого носителя и обеспечить его доставку в УЦ для выяснения причин выхода из строя. Для работы используется второй личный ключевой носитель. |
| Выход из строя второго личного ключевого носителя (при условии, что первый тоже вышел из строя). | Пользователь, у которого вышли из строя оба личных ключевых носителя, является в УЦ для повторной регистрации (без изменения данных регистрации). |
| Отказы и сбои в работе аппаратной части АРМ со встроенной СКЗИ. | При отказах и сбоях в работе аппаратной части АРМ со встроенной СКЗИ необходимо остановить работу, по возможности локализовать неисправность и в дальнейшем произвести ремонт в установленном порядке и, при необходимости, переустановку СКЗИ. |
| Отказы и сбои в работе средств защиты от НСД. | При отказах и сбоях в работе средств защиты от НСД, администратор безопасности, должен восстановить работоспособность средств НСД. При необходимости переустановить программно-аппаратные средства НСД. |
| Утеря личного ключевого носителя. | Утеря личного ключевого носителя приводит к компрометации ключей.
Порядок действий при компрометации ключей описан в разделе Компрометация ключей пользователя |
| Отказы и сбои в работе программных средств вследствие не выявленных ранее ошибок в программном обеспечении. | При отказах и сбоях в работе программных средств, в следствии не выявленных ранее ошибок в программном обеспечении, необходимо остановить работу, локализовать по возможности причину отказов и сбоев и вызвать разработчика данного ПО или его представителя для устранения причин, вызывающих отказы и сбои. |
| Отказы в работе программных средств вследствие случайного или умышленного их повреждения. | При отказах в работе программных средств, в следствии случайного или умышленного их повреждения, лицо, ответственное за безопасность функционирования программных и аппаратных средств, обязано произвести служебное расследование по данному факту с целью установления причины отказа и восстановления правильной работы программных средств в установленном порядке. |
| Отказы в работе программных средств вследствие ошибок оператора. | При отказах в работе программных средств, в следствии ошибок оператора, оператор сообщает о данном факте лицу, ответственному за безопасность функционирования программных и аппаратных средств. Ответственный за безопасность функционирования программных и аппаратных средств дает соответствующие указания обслуживающему персоналу по восстановлению правильной работы программных средств в установленном порядке. |
Все нештатные ситуации должны отражаться в "Журнале пользователя сети" (см. Ведение журналов).
К эксплуатации программного обеспечения, имеющего в своем составе СКЗИ, допускаются лица, прошедшие соответствующую подготовку и изучившие эксплуатационную документацию на соответствующие программные средства.
При установке программного обеспечения СКЗИ, необходимо:
Основной способ установки КриптоПро JCP состоит в запуске командного файла, входящего в состав дистрибутива КриптоПро JCP, имя командного файла зависит от операционной системы, на которую производится установка.
Перед установкой КриптоПро JCP необходимо предварительно удалить предыдущую версию продукта.
Для установки JCP Вы должны иметь права администратора на данной рабочей станции.
При запуске классов JCP будет выводить сообщения в кодировке принятой в Вашей java по умолчанию. Если у Вас кодировка, установленная java при запуске, отличается от кодировки окна, Вы увидите так называемые "кракозябры". Изменить кодировку при запуске java можно указав значением переменной file.encoding нужную кодировку, например
java -Dfile.encoding=Cp866 -versionИз кода программы сменить кодировку можно методом System.setProperty("file.encoding", "UTF-8");
Если Вы хотите, чтоб JCP выводил сообщения в другой кодировке, измените значение переменной. Такое возможно, например, если Вы собираетесь перенаправить вывод в файл install.bat \java >log.txt 2>&1 и анализировать его потом используя другую кодировку.
В Unix-системах java-машины используют для определения кодировки значение переменной LANG. Следите за тем, чтобы значение этой переменной совпадало с кодировкой Вашего окна.
Установка КриптоПро JCP должна проводится администратором из командной строки, находясь в папке с инсталлятором:
install.bat <путь_к_JRE> [<серийный_номер> <имя_компании>],
например,
install.bat "C:\Program Files\Java\jdk1.5.0\jre" XXXXX-XXXXX-XXXXX-XXXXX-XXXXX "Your Company"
При этом будет использоваться исполняемый файл <JRE>\bin\java.exe, а также будет произведено полное удаление файлов КриптоПро JCP, что может быть необходимо при разрешении ошибочных ситуаций. В любом случае, перед установкой автоматически осуществляется попытка деинсталляции КриптоПро JCP на случай, если оно было ранее установлено. Если имя компании содержит пробелы, то оно должно быть заключено в кавычки. Если имя компании указывается на русском языке, то кодировка должна совпадать с указанной в <JRE>\lib\font.properties
По окончании процесса установки необходимо убедиться в корректности установки и ввести лицензию (см. Проверка и ввод лицензии), если она не была указана сразу, для этого запустите файл:
ControlPane.bat <путь_к_JRE>
Если установка завершилась успешно, то будет запущена контрольная панель КриптоПро JCP. При необходимости введите лицензию, как это описано в "Контрольная панель".
Удаление КриптоПро JCP проводится администратором из командной строки:
uninstall.bat <путь_к_JRE>
При этом будет использоваться исполняемый файл <JRE>\bin\java.exe, а также будет произведено полное удаление файлов КриптоПро JCP.
В связи с возможностью одновременного сосуществования нескольких JRE на одной машине необходимо следить за тем, чтобы установка, удаление и использование КриптоПро JCP проводилось одним и тем же JRE, то есть программные модули запускались одним и тем же файлом <JRE>\bin\java.exe.
Установка КриптоПро JCP должна осуществляться администратором. На Windows Vista, Windows 2008 и Windows 7 запуск командного файла следует выполнять как "Run as administrator".
Установка КриптоПро JCP на Unix осуществляется аналогично установке КриптоПро JCP на Windows, с разницей лишь в исполняемых файлах для установки КриптоПро JCP, удаления КриптоПро JCP и запуска контрольной панели КриптоПро JCP:
для установки КриптоПро JCP:
./install.sh <путь_к_JRE> [<серийный_номер> <имя_компании>],
например,
install.sh /usr/java/jdk1.5.0_04/jre XXXXX-XXXXX-XXXXX-XXXXX-XXXXX "Your Company"
для удаления КриптоПро JCP:
uninstall.sh <путь_к_JRE>
для запуска контрольной панели:
ControlPane.sh <путь_к_JRE>
При этом будет использоваться исполняемый файл <JRE>/bin/java.
Установка КриптоПро JCP должна осуществляться администратором. Права, необходимые для установки JCP, можно получить:
При установке КриптоПро JCP на операционные системы отличные от Windows и Unix необходимо воспользоваться установкой через вызов программы java. Этот способ установки также может использоваться при частичной установке КриптоПро JCP, а также при установке из других программ.
Перед запуском установки необходимо убедиться в том, что:
Для запуска программы установки необходимо вызвать java с именем jar файла, например:
java -classpath JCPinst.jar ru.CryptoPro.Install.VariantTwoдля установки Варианта 2 (JCP с функциями шифрования)
java -classpath JCPinst.jar ru.CryptoPro.Install.VariantOneдля установки Варианта 1 (JCP без функций шифрования)
Программа установки поддерживает следующие команды:
При выполнении команды могут быть указаны дополнительные опции:
Для полной установки КриптоПро JCP в одном из стандартных исполнений необходимо запустить
java -classpath JCPinst.jar ru.CryptoPro.Install.VariantTwo -installдля установки Исполнения 2
java -classpath JCPinst.jar ru.CryptoPro.Install.VariantOne -installдля установки Исполнения 1.
Для выборочной первоначальной установки нескольких пакетов необходимо задать список устанавливаемых пакетов для опции install, например:
java -classpath JCPinst.jar ru.CryptoPro.Install.VariantOne -install Installer,JCPСписок возможных пакетов:
При установке пакета JCP могут быть указаны дополнительные опции:
Для удаления JCP необходимо запустить класс вариант установки с опцией -uninstall, например следующим образом:
java ru.CryptoPro.Install.VariantTwo -uninstall -skipfiles delfiles.lstПосле завершения процесса удаления JCP, необходимо удалить все файлы имена которых находятся в списке delfiles.lst.
Для частичного удаления JCP (удаления нескольких пакетов) опции -uninstall можно задавать имена удаляемых пакетов аналогично опции -install. Так же при удалении можно задавать и другие опции, описанные выше.
Для получения списка установленных пакетов можно воспользоваться командной строкой:
java ru.CryptoPro.Install.VariantTwo -installed
Установка дополнительных пакетов осуществляется другим способом. Для установки дополнительных пакетов, а так же пакетов входящих в состав JCP, но не установленных при начальной установке, необходимо использовать установщик входящий в состав дополнительного пакета или воспользоваться установкой пакета по умолчанию.
Установка дополнительного пакета с настройками по умолчанию, осуществляется вызовом java:
java -jar <имя jar>Если пакет состоит из нескольких jar файлов, то все файлы пакета должны находится в одной директории. Удаление пакета можно проводить любым из способов описанных выше.
Установка дополнительного пакета с заданием опций, производится вызовом программы установки из этого пакета. Например:
java -classpath JCPxml.jar ru.CryptoPro.JCPxml.XMLInstall -install
Список опций класса установки совпадает со списком опций при установке из программы установки JCP. Ниже приведен полный список классов установки для всех пакетов входящих в КриптоПро JCP и КриптоПро JTLS.
Криптопровайдер КриптоПро JCP имеет два типа лицензий: клиентские и серверные. Тип лицензии зависит от платформы, операционной системы и дальнейшего применения провайдера.
Клиентские ОС:
Серверные ОС:
Клиентская лицензия предусматривает количество ядер не более четырех. Если количество ядер более четырех или в дальнейшем предполагается использовать JTLS сервер, то необходима серверная лицензия JCP (даже если по вышеуказанному списку подходит клиентская).
Для работы с лицензией можно использовать контрольную панель или командную строку (класс ru.CryptoPro.JCP.tools.License).
Минимальные требования к лицензии для данной системы указаны на контрольной панели (закладка "Общие"), также их можно узнать из командной строки:
ru.CryptoPro.JCP.tools.License -required
Ввод лицензии осуществляется через контрольную панель или вызовом класса ru.CryptoPro.JCP.tools.License с параметрами:
ru.CryptoPro.JCP.tools.License -serial "serial_number" -company "company_name" -storeили
ru.CryptoPro.JCP.tools.License -serial "serial_number" -combase "company_name_in_base64" -store
Также можно проверить заданную лицензию без ее установки:
ru.CryptoPro.JCP.tools.License -serial "serial_number" -company "company_name"или
ru.CryptoPro.JCP.tools.License -serial "serial_number" -combase "company_name_in_base64"
При использовании параметра "-combase" имя компании вводится в base64 кодировке.
Вызов класса ru.CryptoPro.JCP.tools.License без параметров проверит установленную лицензию.
Дату первой установки можно узнать с помощью команды:
ru.CryptoPro.JCP.tools.License -first
Для вывода справки:
ru.CryptoPro.JCP.tools.License ?
Для того чтобы использовать eToken как носитель ключевой информации для СКЗИ КриптоПро JCP (тип хранилища "OCFStore" см. Руководство программиста) в исполнительной среде Java Runtime Environment, необходимо выполнить следующие подготовительные действия:
Для установки программного обеспечения вы должны иметь права администратора на данной рабочей станции.
${java.home}/lib/security/java.policy
КриптоПро JCP устанавливается в каталог ${java.home}\lib\ext.
Обычно этот каталог имеет права доступа разрешающие
всем jar файлам, содержащимся в этом каталоге, получить все права доступа
grant codeBase "file:${java.home}/lib/ext/*" {
permission java.security.AllPermission;
};
Если этот каталог имеет права доступа отличные от приведенных выше необходимо настроить права доступа для JCP.jar. Примерный вид этого файла приведен ниже.
grant codeBase "file:${java.home}/lib/ext/jcp.jar" {
permission java.lang.RuntimePermission "preferences", "read";
permission java.util.PropertyPermission "os.name", "read";
java.util.PropertyPermission "<usedProperty>", "read";
permission java.io.FilePermission "<pathToLocalMutex>/*" "read, write";
};
где Администратору безопасности должны быть предоставлены следующие права доступа:
grant {
permission java.lang.RuntimePermission "preferences", "read";
}
Кроме того, администратор безопасности должен иметь:
HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Prefs\ru\/Crypto/Pro\/J/C/P
Установленные на JAVA машину приложения не должны осуществлять доступ к ключам. Для этого все приложения установленные на Java машину должны быть или получены от производителей доверенным способом или иметь права доступа запрещающие доступ к ключам.
Обычно каталог ${java.home}\lib\ext разрешает всем
приложениям для всех пользователям все права доступа. Необходимо или
ограничить эти права доступа, запретив доступ в каталоги содержащие ключи
(а так же к смарт-карте и дискете) или устанавливать в этот каталог
только приложения производителей полученные доверенным способом.
Пользователь JCP должен обладать следующими правами доступа:
HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Prefs\ru\/Crypto/Pro\/J/C/P;Примечание: для Unix платформ папки keys и tmp, заданные по умолчанию
(/var/CPROcsp/keys и /var/CPROcsp/tmp), могут быть созданы только из под root.
Для их автоматического создания с правильными правами доступа достаточно создать контейнер из под root.
В данном разделе приводится описание контрольной панели КриптоПро JCP, которая является инструментом, позволяющим устанавливать и изменять наиболее важные настройки криптопровайдера КриптоПро JCP, такие как:
Для запуска контрольной панели в Windows можно использовать
ControlPane.bat <путь_к_JRE>
Для запуска контрольной панели в Unix используйте
ControlPane.sh <путь_к_JRE>
Запуск контрольной панели в других операционных системах осуществляется запуском класса ru.CryptoPro.JCP.ControlPane.MainControlPane принятым в Вашей системе способом.
Контрольная панель КриптоПро JCP предназначена для работы с настройками криптопровайдера КриптоПро JCP при помощи следующих обеспечиваемых ею операций:
Панель состоит из шести закладок ("Общие", "Алгоритмы", "Оборудование", "Дополнительно" и "Окружение", "Хранилища ключей и сертификатов"), каждая из которых обеспечивает выполнение одной из перечисленных операций. При установке дополнительных компонентов криптопровайдера КриптоПро JCP количество закладок контрольной панели может быть увеличено.
Изменение всех настроек криптопровайдера разрешено только для пользователя, обладающего всеми правами (т.е. для администратора).Все поля контрольной панели для администратора доступны для редактирования. Для остальных пользователей часть полей панели, в зависимости от установленных для пользователей прав, будет доступна только для чтения.
Также следует обратить внимание на то, что внешний вид контрольной панели может отличаться от изображений, приведенных в данной документации. Внешний вид панели зависит от настроек, операционной системы, установленной Java машины и т.д.
Панель "Лицензия" предназначена для просмотра информации о текущей лицензии на использование криптопровайдера КриптоПро JCP, а также для установки новой лицензии, если это необходимо.
При установке криптопровайдера КриптоПро JCP без ввода лицензии пользователю предоставляется лицензия с ограниченным сроком действия. Для использования КриптоПро JCP после окончания этого срока пользователь должен ввести серийный номер с бланка Лицензии, полученной у организации-разработчика или организации, имеющей права распространения продукта (дилера).
Внешний вид панели "Лицензия" (временная лицензия)
Панель включает в себя следующую информацию:
Также указывается информация об операционной системе пользователя.
Помимо этого, в панель включена кнопка "Ввод лицензии", позволяющая по истечению срока действия предыдущей лицензии устанавливать серийный номер новой лицензии, а также информацию о ее владельце.
Ввод серийного номера лицензии
После ввода серийного номера новой лицензии, а также информации о владельце устанавливаемой лицензии, на панели "Лицензия" будет отображена введенная информация.
ВАЖНО: лицензия будет сохранена только после нажатия кнопок "OK" или "Применить"
Панель "Алгоритмы" предназначена для просмотра используемых параметров реализованных криптографических алгоритмов. Помимо этого допускается изменение текущих параметров на любые другие, допустимые соответствующими алгоритмами.
Внешний вид панели "Алгоритмы"
По умолчанию в панели "Алгоритмы" определен следующий набор параметров:
Панель позволяет устанавливать следующие параметры:
Закладка "Оборудование" предназначена для определения путей к хранилищам закрытых ключей (дисководу и жесткому диску).
Внешний вид закладки "Оборудование"
Закладка состоит из двух полей:
По умолчанию в панели установлены следующие пути к носителям:
Предполагается, что системные настройки ${...} установлены также в значения по умолчанию, т.е. значение ${user.name} - есть имя текущего пользователя, а ${user.home} установлено в директорию "Documents and Settings\${user.name}". Следует обратить внимание на то, что при изменении текущих настроек криптопровайдера, новые пути к носителям могут содержать любые допустимые системные настройки вида "${...}". Следует учитывать, что значение переменной может быть изменено при запуске Java-машины.
Закладка "Дополнительно" предназначена для выбора параметров безопасности при работе с криптопровайдером КриптоПро JCP.
Внешний вид закладки "Дополнительно"
Закладка состоит из следующих компонентов:
По умолчанию для каждого из полей определены следующие значения:
Панель "Контроль целостности" предназначена для контроля целостности файлов ОС средствами КриптоПро JCP. Панель оперирует "хранилищами" контрольных сумм, с ее помощью можно:
Кроме того, можно выбирать хранилище, по которому будет осуществляться контроль.
Внешний вид панели "Контроль целостности"
Панель состоит из окна, в котором отображаются контролируемые файлы, панели "Хранилище хешей", и кнопок "Проверить", "Пересчитать", "Добавить", "Удалить".
Панель "Хранилище хешей" состоит, в свою очередь, из переключателя между системным и файловым хранилищами.
Хеши файлов могут храниться в системных настройках (системное хранилище), или в файле (файловое хранилище). В случае хранения их в системных настройках не нужен никакой дополнительный выбор, система автоматически определяет их месторасположение. В случае хранения хешей в файле, следует определить хранилище, указав имя файла, в котором будет организовано хранилище. Файл хранилища должен иметь расширение "cpv". Его можно задать, переключившись в режим файла в панели "Хранилище хешей", и введя его имя в строке ввода, или выбрав его в раскрывающемся файловом меню. Если расширение выбранного или вновь создаваемого файла не "cpv", то оно будет заменено на "cpv". Если файл изначально не является файлом хранилища, то он будет открыт как пустое хранилище (как хранилище, у которого не сошлась контрольная сумма), но при нажатии кнопки "Применить", если были какие-то изменения, будет перезаписан, и все прежние данные в нем будут утеряны. Вновь создаваемый файл открывается как пустое хранилище.
Любое хранилище - список файлов с их контрольными суммами, в свою очередь контролируемый. Это означает, что любое хранилище может формально находиться в одном из трех состояний: "не существовать", "существовать, но быть испорченным", и "существовать и быть исправным". Открытие хранилища происходит при старте панели или при смене хранилища внутри контрольной панели. Если хранилище, которое в настоящий момент выбрано, не существует, то в него можно только добавлять файлы (соответственно, сначала доступна только кнопка "Добавить"). После того, как в несуществующее хранилище добавлен хотя бы один файл, также становятся доступными кнопки "Пересчитать", "Проверить", "Удалить". Все они выполняют лишь виртуальные операции, и результат действий не сохраняется. Однако если после любых изменений сохранить хранилище, то будет выполнена стандартная проверка на возможность сохранения, и, в случае успеха, хранилище будет сохранено, а в противном случае будет выдано сообщение об ошибке. Если хранилище существует и повреждено, то будет выдано сообщение об ошибке, и хранилище будет открыто как несуществующее. Если хранилище исправно, то при его открытии произойдет считывание списка файлов.
Все операции с файлами в хранилище буферизуются. Это значит, что пока не нажата кнопка "Применить", хранилище изменено не будет. При нажатии кнопки "Применить" фиксируется текущее состояние текущего открытого хранилища. Состояние любых других хранилищ, в том числе и открытых раньше, не сохраняется.
Файл в открытом хранилище может быть в одном из четырех состояний:
 |
- не проверялся |
 |
- проверен, хеш сходится |
 |
- проверялся, хеш не сходится |
 |
- поврежден или удален |
Файлы сохраняются в хранилище только в том случае, если все они находятся в состоянии "Проверен, хеш сходится".
При открытии исправного хранилища из него читаются все содержащиеся в нем файлы. Все они автоматически переходят в состояние "Не проверялся". После открытия хранилища с файлами разумно выполнить проверку целостности для всего списка файлов.
При нажатии кнопки "Добавить" в раскрывшемся диалоге выбрать нужные файлы, и они будут добавлены в текущее хранилище. Изначально окно открывается в домашнем каталоге пользователя, но после успешного сохранения настроек в Контрольной Панели сохраняется последний каталог, из которого брались файлы, и в следующий раз диалог откроется в этом каталоге. Файлы могут быть добавлены по одному и списком.
Выделить файлы, лежащие в хранилище и отображенные в окне. Нажать кнопку "Пересчитать". Хеши для всех выделенных файлов будут пересчитаны. Если не выделен ни один файл, хеши будут пересчитаны для всех файлов в хранилище. После вывода сообщения об успешном пересчете хешей все файлы, для которых хеши были подсчитаны заново, изменят свое состояние на " Проверен, хеш сходится ".
Выделить файлы, лежащие в хранилище и отображенные в окне. Нажать кнопку "Проверить". Будут проверены все выделенные файлы, а если не был выделен ни один, будут проверены все файлы, находящиеся в хранилище.
Выделить файлы, лежащие в хранилище и отображенные в окне. Нажать кнопку "Удалить". Выделенные файлы будут удалены из хранилища.
Сохранение состояние панели (сохранение хранилища, и сохранения текущего хранилища, при наличии изменений) происходит при нажатии кнопки "Применить" или кнопки "ОК". В любом другом случае сохранения состояния панели не происходит. Исключение составляют текущие каталоги для диалогов добавления файлов в хранилище и выбора хранилища, которые сохраняются после каждого закрытия соответствующего диалога.
Установки панели, такие как текущие каталоги для добавляемых в хранилище файлов и для файловых хранилищ, сохраняются в настройках пользователя. Выбранное в настоящий момент на данном компьютере хранилище описано в системных настройках. Прочитать выбранное хранилище может пользователь, которому системные настройки доступны для чтения. Изменить выбор хранилища может пользователь, которому системные настройки доступны для записи. Если пользователь не может задать хранилище, соответствующий переключатель погашен.
У любого хранилища также есть права на чтение и запись для каждого пользователя. Они совпадают с правами пользователя для файла хранилища, или для системных настроек, если в качестве хранилища выбраны они. Создав хранилище из-под одного пользователя, следует также установить возможность чтения этого хранилища для всех других пользователей, кто может работать с контрольной панелью.
В случае, если пользователь не может ни писать в текущее (существующее) хранилище, ни читать из него, погашены кнопки "Добавить", "Удалить", "Проверить", "Пересчитать" (то же, если текущим оказалось несуществующее хранилище). Если пользователь имеет права на чтение хранилища, погашены все кнопки, кроме "Проверить". Если пользователь имеет права на запись в хранилище, все четыре кнопки доступны.
Изначально установлено хранилище в системных настройках, список файлов в нем пуст. При открытии файлового диалога для выбора нового хранилища или для добавления файлов, они откроются в домашнем каталоге пользователя.
При открытии ранее уже использованной панели, будет выведено последнее установленное хранилище, и в окне файлов будут отображены все содержащиеся в хранилище файлы со знаком "Не проверялся".
Панель "Хранилища ключей и сертификатов" предназначена для просмотра хранилищ ключей, установленных в системе, просмотра и управления контейнерами в хранилищах.
С помощью панели можно:
Внешний вид панели "Хранилища ключей и сертификатов"
Панель состоит из окна просмотра дерева хранилищ контейнеров, окна просмотра дерева хранилищ сертификатов, кнопок управления хранилищами и кнопок управления объектами в хранилищах.
При открытии панели дерево хранилищ и контейнеров находится в свернутом состоянии, показаны только хранилища, установленные в системе. Двойной щелчок мыши или нажатие "Ввод" на любом их хранилищ проинициализирует попытку открытия данного хранилища. В этом случае:
Если во время открытия хранилища произошла ошибка, сообщение о ней будет выдано на экран.
При установке курсора на любой элемент дерева, автоматически переключающиеся закладки справа,
покажет закладку с соответствующими кнопками для выполнения операций над данным объектом.
В хранилище в общем случае хранятся алиасы - контейнеры (в хранилищах контейнеров) либо сертификаты (в хранилищах сертификатов). Содержимое любого контейнера можно просмотреть, с помощью двойного клика мыши и нажатия "Ввод" на нем. При этом раскроется окно ввода пароля для контейнера. Если введен правильный пароль, контейнер будет раскрыт и его содержимое (набор сертификатов и ключ) будет отображено как листья в дереве. Если же пароль неправильный, или произошла какая-то ошибка чтения контейнера, будет выведен единственный лист: "Контейнер не открывался".
Будь то контейнер или хранилище, в случае, если для него выведен лист "... не открывался", после схлопывания дерева в его ветке и повторного двойного клика на листе будет произведена очередная попытка открытия.
Успешно открытое хранилище или контейнер не надо открывать заново в случае схлопывания ветки дерева. Также и после успешно завершенных операций, требующих открытия хранилища или контейнера (изменение пароля, копирование), заново их открывать не нужно.
При установке указателя на одно из хранилищ контейнеров доступно действие "Создать" контейнер.
Данная реализация позволяет получить закрытый ключ подписи или обмена с самоподписанным сертификатом (для аутентификации сервера или клиента (выбор справа)). Также указываются имя нового контейнера и имя субъекта сертификата. При совпадении имени создаваемого контейнера с именем уже существующего в хранилище контейнера будет выведено сообщение о перезаписи или отмене. Ключ можно сохранить без пароля или с паролем. Для сохранения ключа с паролем необходимо выбрать флаг "Пароль" и в соответствующее поле ввести пароль. При нажатии кнопки "Создать" будет сгенерирован ключ и сертификат, и контейнер с указанным именем и паролем будет записан в текущее хранилище.
Если создается ключ обмена, то перед созданием контейнера убедитесь, что провайдер Crypto установлен, т.к. для данного случая генерирование ключа происходит по алгоритму Диффи-Хелмана (ключ подходит как для обмена, так и для подписи). Если провайдер Crypto не установлен, появится сообщение об ошибке "Провайдер Crypto не найден".
После данных операций появится окно диалога сохранения запроса на сертификат.
Сохраненный запрос можно использовать для получения сертификата на УЦ.
Полученный на УЦ и сохраненный в файл сертификат можно уложить в соответствующий контейнер
установив на нем указатель и нажав кнопку "Добавить", в появившейся закладке операций для объекта контейнер).
При выполнении данного действия осуществляется перезапись сертификата в контейнере.
В контейнер можно также добавлять цепочку сертификатов (из файла *.p7b).
Также становятся доступны следующие операции с контейнером:
При установке указателя на ключ в контейнере, будет выведена информация о ключе.
При установке указателя на сертификат в контейнере будут доступны операции просмотра и копирования.
Кнопка "Построить" позволяет осуществить поиск цепочки для данного сертификата (в выбранном хранилище сертификатов).
Чтобы открыть или создать новое хранилище сертификатов следует установить указатель на корневой элемент дерева хранилищ сертификатов.
После нажатия кнопки "Найти / Создать" появится окно диалога открытия (создания) хранилища.
После открытия(создания) хранилища сертификатов в дереве появится соответствующий лист.
При установлении указателя на хранилище сертификатов становятся доступны следующие операции:
При установке указателя на сертификат в хранилище сертификатов доступны операции просмотра, копирования и удаления сертификата из данного хранилища. Кнопка "Построить" позволяет осуществить поиск цепочки для данного сертификата (в выбранном хранилище сертификатов).
Сертификаты могут хранится в контейнерах и в файловой части хранилища - хранилище сертификатов. В любом случае к ним может быть применена операция "просмотреть сертификат" (кнопка "Просмотр"). Для сертификата будет выведено окно просмотра с тремя закладками: "Общая информация", "Подробно" и "Путь". Первая закладка содержит общую информацию о сертификате: действителен ли он, срок его действия, имя издателя и владельца.
Вторая закладка содержит информацию о большинстве полей сертификата, представленных в виде списка, каждая строка которого - пара "Имя поля":"Значение поля".
С помощью кнопки "Просмотр" можно также просматривать цепочки и наборы сертификатов, хранящиеся вместе с ключами в контейнерах. Перед просмотром производится попытка построить цепочку из набора сертификатов контейнера, и, если это удалось, набор сертификатов выводится в третьей вкладке окна просмотра в виде дерева. В противном случае в третьей вкладке выводится набор сертификатов в виде списка. В любом случае в первых двух вкладках отображается информация для конечного сертификата (сертификата ключа). На третьей же вкладке есть возможно просмотреть полную информацию о любом из сертификатов в наборе, кроме конечного, выбрав его в окне и нажав кнопку "Просмотр".
Цепочку можно сохранить в файл формата CMS (*.p7b). Закрывается окно просмотра сертификатов по кнопке "Ок", или при нажатии "Esc", или при нажатии на кнопку закрытия в углу окна.
Операция копирования применима к контейнерам и сертификатам. Контейнеры, содержащие экспортируемый ключ, можно копировать из одного хранилища в другое, а также копировать в то же хранилище (переименование). Сертификаты можно копировать только в файловое хранилище (хранилище сертификатов), но безразлично - из контейнера или из хранилища сертификатов. При нажатии кнопки "копировать", когда выбран контейнер, сначала производится его открытие, потом выводится окно "Выбор хранилища", после выбора хранилища назначения задаются новое имя контейнера в хранилище и его пароль. Затем производится копирование.
Для сертификата копирование осуществляется в том же порядке, что и для контейнера, однако не запрашиваются старый и новый пароль.
Операция удаления объекта применима к любому алиасу - сертификату или контейнеру в хранилище. Выполняется по кнопке "Удалить".
Операция изменения пароля применима к файловой части хранилища - хранилищу сертификатов, и к контейнерам. При смене пароля происходит перезапись объекта с тем же именем, но с другим паролем, соответственно, чтобы изменить пароль на контейнере, необходимо, чтобы он содержал экспортируемый ключ.
Операция смены пароля состоит из открытия объекта (для этого потребуется старый пароль) и ввода нового пароля с подтверждением.
Протоколирование КриптоПро JCP осуществляется стандартными средствами Java машины. Формат протокола, поля вывода, уровни протоколирования настраивается в фале <jre>/lib/logging.properties. Имя класса протокола для JCP: ru.CryptoPro.JCP.tools.JCPLogger.
Уровни протоколирования JCP совпадают с уровнями протоколирования Java, ниже они приведены в порядке по возрастанию информативности сообщений, уровень выше включает все сообщения приведенные по тексту ниже. Уровень ALL включает все сообщения, уровень OFF выключает все сообщения.
При настройках Java машины по умолчанию, включен уровень INFO.
При включении уровня отличного от заданного по умолчанию (INFO) следует помнить, что уровни выше CONFIG могут значительно замедлить скорость провайдера, а уровни ниже INFO привести к несвоевременному обнаружению причин отказа JCP. При обычной работе JCP рекомендуется оставлять настройку уровня выводимых сообщений по умолчанию (INFO).
Контроль целостности JAR-файла провайдера осуществляется при загрузке
провайдера посредством проверки подписей трех файлов jcp.jar, JCP_ASN.jar и
asn1rt.jar.
Создание и проверка подписей JAR-файлов реализованы в классе JarChecker.
Для создания подписи некоторого JAR-файла следует вызвать функцию
main класса JarChecker со следующими параметрами:
-sign [-alias keyAlias] [-storetype storeType] [-keypass keyPassword]
[-in jar_file] [-out signed_jar_file] [-delsign]
Описание передаваемых параметров:
| параметр | значение | обязательный/необязательный |
|---|---|---|
| -sign | команда создания новой подписи | обязательный параметр |
| -alias | имя закрытого ключа, на котором осуществляется подпись | обязательный параметр |
| -storetype | имя ключевого носителя, на котором лежит ключ | по умолчанию - HDImageStore, обязательный если ключ лежит не на жестком диске |
| -keypass | пароль на ключ подписи | обязательный, если пароль на ключ установлен |
| -in | полный путь к подписываемому JAR-файлу | обязательный параметр |
| -out | полный путь к файлу, в который будет записан подписанный JAR-файл | обязательный параметр |
| -delsign | флаг, определяющий удаление неверных подписей | если указан, то неверные подписи будут удалены |
Описание процесса создания подписи:
В процессе формирования подписи JAR-файла осуществляется
копирование всех классов, входящих в исходный JAR-файл, в новый JAR-файл, определенный путем
-out. После чего в директории META-INF нового JAR-файла
создаются два файла: Digest.CP и Sign.CP (если подпись производится не в первый раз, т.е. если такие
файлы уже существуют в исходном JAR-файле, то файл Digest.CP не изменяется, а к содержимому Sign.CP
добавляется информация о новой подписи).
Первый файл представляется собой набор пар: имя класса, входящего в JAR-файл, но не входящего в директорию META-INF, и значение хеша на содержимое этого класса. Второй файл содержит в себе следующую информацию:
Новая подпись (как и все предыдущие) производится на содержимое файла Digest.CP.
Для проверки подписи некоторого JAR-файла следует вызвать функцию
main класса JarChecker со следующими параметрами:
-verify [-in signed_jar_file] [-cert cert_file]
Описание передаваемых параметров:
| параметр | значение | обязательный/необязательный |
|---|---|---|
| -verify | команда проверки подписи | обязательный параметр |
| -in | полный путь к подписанному JAR-файлу | обязательный параметр |
| -cert | полный путь к сертификату, на котором осуществляется проверка подписи | если указан, то осуществляет проверка подписи, соответствующей заданному сертификату. В противном случае осуществляется проверка всех имеющихся подписей JAR-файла |
Описание процесса проверки подписи:
-cert),
то производится поиск соответствующего сертификата в файле Sign.CP и, если такой сертификат
найден, осуществляется проверка соответствующей подписи;При загрузке провайдера CryptoPro JCP осуществляется проверка
подписей трех файлов jcp.jar, JCP_ASN.jar и
asn1rt.jar на заданном сертификате (сертификат прошит в самом JarChecker, а также
находится в: Personal.JCP_path + Build\key\jcpsignjar.cer).
Для последующего контроля целостности, при сборке провайдера необходимо осуществить
подпись всех этих JAR-файлов на ключе с именем "JCPSignJar"
(полный путь к контейнеру: Personal.JCP_path + Build\key\JCPSignJ.000).
Контроль целостности осуществляется при помощи функции check() класса JarChecker, которая запускается в классе Starter загружаемого провайдера, собранного с отключенным флагом DEBUG. Для корректной работы данной функции сертификат прошит в самом классе JarChecker, и указание пути к файлу с сертификатом при осуществлении контроля целостности не требуется.
Командная строка CPVerify введена для более удобного контроля целостности а также возможности администрирования систем, в которых отсутствует графическое расширение или пакеты Java AWT и Swing.
С помощью командной строки можно создавать хранилища хэшей, добавлять в них файлы, удалять файлы из хранилища, пересчитывать и проверять хеши файлов в хранилище, а также работать с основным системным хранилищем.
Командной строке Prompt всегда передается следующий набор параметров:
doing repository [params]
Параметр doing определяет действие, требуемое от командной строки. Он обязательно должен стоять первым. Значения параметра приведены в таблице:
| параметр | действие |
|---|---|
| -verify | Проверить файлы в хранилище. Команда проверяет хеши одного или нескольких файлов из указанного хранилища. |
| -make | Пересчитать хеши файлов в хранилище. По команде пересчитывается хеш одного или нескольких файлов в хранилище. |
| -add | Добавить файлы в хранилище. Команда добавляет один или несколько файлов в хранилище, и пересчитывает для них хеш. |
| -delete | Удалить файлы из хранилища. Команда удаляет один или несколько файлов из хранилища. |
| -create | Создать хранилище. Команда создает новое хранилище. Если хранилище уже существует, то оно будет перезаписано. |
| -check | Проверить статус хранилища. Команда проверяет статус хранилища: не повреждено или не удалено ли оно. |
| -setdefault | Сделать хранилище основным системным. Основное системное хранилище - то, в котором хранятся хеши наиболее важных системных файлов, и которое периодически проверяют внутренние службы криптопровайдера. |
| -getdefault | Узнать, какое хранилище является основным системным. |
| Вывести состояние всех файлов в хранилище. Команда выводит состояние всех файлов в хранилище: не повреждены ли они, не удалены ли. | |
| -help | Вывести справку. Общая справка по всем командам. |
Параметр repository является необходимым во всех командах, кроме -help и -getdefault. Он задает хранилище, с которым будет проводиться операция. Он может быть определен одним из трех следующих способов:
| параметр | хранилище |
|---|---|
| -repfile filename | Хранилище - файл, с именем filename |
| -reppref | Хранилище расположено в каталоге системных настроек (реестр для Windows). |
| -repdefault | Основное системное хранилище |
Параметр repository может быть любым по счету, но не первым. Если он равен -repfile, следующее слово в командной строке считается именем файла.
Параметры [params] зависят от команды. Для всех команд действует параметр -help - подробная справка по команде. Команды -help, -print, -getdefault, -setdefault, -check, -create не предполагают дополнительных параметров. В командах -verify, -make, -add, -delete надо определять список файлов, над которыми производится действие, специальными параметрами, указанными ниже в таблице:
| Команда | Параметр, определяющий файлы | Действие |
|---|---|---|
| -verify | -all | Проверить все файлы, лежащие в хранилище. |
| -file filename1 [-file filename2 [...]] | Проверить файлы filename1, filename2,..., если они есть в данном хранилище. | |
| -make | -all | Пересчитать хеши всех файлов, лежащих в хранилище |
| -file filename1 [-file filename2 [...]] | Пересчитать хеши файлов filename1, filename2,..., лежащих в хранилище | |
| -add | -file filename1 [-file filename2 [...]] | Добавить в хранилище файлы filename1, filename2,... |
| -delete | -all | Удалить все файлы из хранилища |
| -file filename1 [-file filename2 [...]] | Удалить файлы filename1, filename2,... из хранилища. |
Любая команда из тех, которые изменяют хранилище, перед сохранением хранилища вызывает проверку всех файлов, в нем содержащихся. Поэтому если какие-то файлы в хранилище повреждены, его состояние можно перезаписать только удалив их всех из него одной командой -delete, или пересчитав для всех хеш.
Приложение завершается с ошибкой (выход по исключению), если возникла непредвиденная ситуация (отказано в доступе к файлу, ошибка ввода-вывода и т.д.), или если возникла ошибка при работе с хранилищем, когда оно считается существующим. Так, если проверяется статус поврежденного хранилища, приложение завершится нормально, выдав диагностическое сообщение, однако если проводится проверка файлов в поврежденном хранилище, приложение завершится с ошибкой. Приложение завершается нормально, если проверяемый файл из хранилища поврежден, выдавая соответствующую диагностику.
Перед началом работы с провайдером необходимо создать основное хранилище в системных настройках, права на изменения которого даны только администратору. В него следует добавить исполняемые файлы Java, файлы содержащие пакеты java.lang, java.security, java.io, javax, системные библиотеки, конфигурационные файлы Java-машины, модули JCP, которые находятся в каталоге [путь к JRE]/lib/ext.
Этот список следует проверять средствами командной строки в отдельном процессе до загрузки рабочей Java-машины не реже одного раза в сутки.
В случае, если CPVerify зафиксирует изменение хотя бы одного элемента Java-машины, использование криптопровайдера следует прекратить до выяснения и устранения причин возникновения ошибки.
Защита информации от НСД в автоматизированной системе обеспечивается комплексом программно-технических средств и поддерживающих их организационных мер. В их числе:
Защита информации от НСД должна обеспечиваться на всех технологических этапах обработки информации и во всех режимах функционирования, в том числе, при проведении ремонтных и регламентных работ.
Защита информации от НСД должна предусматривать контроль эффективности средств защиты от НСД. Этот контроль может быть либо периодическим, либо инициироваться по мере необходимости пользователем или контролирующими органами.
В организации, эксплуатирующей ПО СКЗИ КриптоПро JCP, должна быть выпущена инструкция по защите от НСД к системе, разработанная на базе настоящего документа, руководящих документов Государственной технической комиссии, действующих нормативных документов самой эксплуатирующей организации.
В организации - пользователе системы должно быть выделено специальное должностное лицо - администратор безопасности, функции которого должны заключаться в выполнении процедур установки ПО, настройки системного окружения, установки, настройки, обслуживания и обеспечения функционирования средств защиты.
Администратор безопасности должен иметь возможность доступа ко всей информации, обрабатываемой на рабочем месте.
Каждый исполнитель работ как пользователь сети конфиденциальной связи должен быть зарегистрирован у администратора службы безопасности.
При осуществлении доступа в глобальные сети передачи данных непосредственно с рабочих мест, оснащенных СКЗИ КриптоПро JCP, должны быть приняты меры, исключающие возможность воздействия нарушителя на СКЗИ по каналам связи, выходящим за пределы контролируемой зоны.
При использовании СКЗИ КриптоПро JCP следует принять следующие организационные меры:
В любом случае запрещается использовать эти средства для просмотра и редактирования кода и памяти приложений, использующих СКЗИ КриптоПро JCP. Необходимо исключить попадание в систему программ, позволяющих, пользуясь ошибками ОС, получать привилегии администратора.
При использовании JCP на платформе Windows Java-машина системные и пользовательские настройки хранит в реестре в разделах HKEY_CURRENT_USER\Software\JavaSoft\Prefs и HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Prefs соответсвенно.
На платформах Solaris и Linux Java-машина системные и пользовательские настройки хранит в файловой системе. Системные настройки находятся в каталоге .systemPrefs, положение которого определяется переменной java.util.prefs.systemRoot (по умолчанию /etc/.java). Если он недоступен то .systemPrefs находится в каталоге определенном переменной java.home
Пользовательские настройки находятся в каталоге .java/.userPrefs, положение которого определяется переменной java.util.prefs.userRoot Если переменная не задана то каталог .java/.userPrefs находится в каталоге определенном переменной user.home
В данном разделе представлены основные рекомендации по организационно-техническим мерам защиты для обеспечения безопасности функционирования рабочих мест со встроенной СКЗИ.
Не допускается:
УТВЕРЖДАЮ
_______________________________
(должность)
_______________________________
(наименование учреждения)
______________________________
(подпись) (Ф.И.О.)
АКТ
готовности к работе _______________________________ /наименование учреждения/ с _____________________________ /наименование изделий/ "_____" _______________ 20___г.
Комиссия в составе председателя ______________________ /должность/ ______________________________ /Ф.И.О/ и членов назначенная _______ составила настоящий акт о том, что помещение эксплуатирующего органа ___________________ /название/, ___________________________ /размещение/, хранилища ключевых носителей, охрана помещений и подготовленность сотрудников к обслуживанию _______________________________________________________/оборудование/ соответствуют: ______________________________________________________ /ГОСТ, инструкция, руководящие документы, правила пользования и т.п./
Комиссия отмечает, что инсталляция ПО вышеупомянутых изделий проведены в соответствии с _________________________________________________________ ___________________ инструкции
Вывод: комиссия считает, объект________________________/название объекта/
отвечает требованиям
__________________________________________________________ ___________________
/название инструкции по обеспечению безопасности связи/
по уровню _________________
и может быть введен в действие.
| Председатель: | Члены комиссии |
| ____________________________ | __________________________________________ |
| (подпись) | (Ф.И.О) |
| ____________________________ | __________________________________________ |
| (подпись) | (Ф.И.О) |
| ____________________________ | __________________________________________ |
| (подпись) | (Ф.И.О) |
| ____________________________ | __________________________________________ |
| (подпись) | (Ф.И.О) |
| М.П. |
| п/п | Организация | Ф.И.О.администратора безопасности пользователя системы | Данные регистрации | Дата регистрации | Дата выбытия | Примечание(пользователь, администратор) |
| 1 | Сидоров А. А | нет | 21.04.2000 | Администратор безопасности | ||
| 2 | Иванов И. И. | Почтовый адрес:a.sidorov@acme.ru Должность: | 01.05.2000 | Оператор расчетной системы |
| п/п | Дата | Время | Ф.И.О.пользователя системы | Событие | Дополнительные данные | Примечание |
| 1 | 02.05.2000 | 09:00 | Иванов И.И. | Поломка ключа |