Spec-Zone .ru
спецификации, руководства, описания, API
|
|
Spec-Zone .ru
спецификации, руководства, описания, API
|
Этот урок объясняет, почему цифровые подписи, сертификаты, и keystores необходимы. Урок также сравнивает использование инструментов против API Безопасности JDK относительно генерирования подписей. Такое использование инструмента демонстрируется в следующих двух уроках, Подписывая Код и Предоставление Этого Полномочия и Обмен Файлами. Использование API демонстрируется в Генерировании и Проверке урока Подписей.
Этот урок содержит следующие разделы
Если Вы электронно отправляете кому-то важный документ (или документы), или апплет или приложение, чтобы работать, получатель нуждается в способе проверить, что документ или код прибыли от Вас и не были изменены в пути (например злонамеренным пользователем, прерывающим это). Цифровые подписи, сертификаты, и keystores, который вся справка гарантирует безопасности файлов, которые Вы отправляете.
Основная идея в использовании цифровых подписей следующие.
keytool или методы API безопасности. Таким образом, Вы генерируете цифровую подпись для документа или кода, используя jarsigner инструмент или методы API Безопасности.Получатель должен гарантировать, что Ваш сам открытый ключ подлинен прежде, чем он или она сможет использовать его, чтобы проверить, что Ваша подпись подлинна. Поэтому, Вы будете обычно предоставлять сертификат, который содержит Ваш открытый ключ вместе с ключом Центра сертификации, кто может ручаться за подлинность Вашего ключа. См. следующий раздел для деталей.
Для получения дополнительной информации о терминологии и понятии подписания и проверки, и дальнейшего объяснения преимуществ, см. раздел Файлов JAR Подписания "Программы Упаковки в уроке" Файлов JAR.
Сертификат содержит:
Один способ для получателя проверить, допустим ли сертификат, проверяя его цифровую подпись, используя открытый ключ (подписывающего лица) его выпускающего. Тот ключ может самостоятельно быть сохранен в пределах другого сертификата, подпись которого может также быть проверена при использовании открытого ключа выпускающего того следующего сертификата, и что ключ может также быть сохранен в еще одном сертификате и так далее. Можно прекратить проверять, когда Вы достигаете открытого ключа, что Вы уже доверяете и используете его, чтобы проверить подпись на соответствующем сертификате.
Если получатель не может установить доверительную цепочку, то он или она может вычислить цифровой отпечаток (ки) сертификата, используя keytool -import или -printcert команда. Цифровой отпечаток является относительно коротким числом, которое уникально и достоверно идентифицирует сертификат. (Технически, цифровой отпечаток является значением хэш-функции информации о сертификате, используя функцию обзора сообщения.) Получатель может тогда позвонить владельцу сертификата и сравнить значения цифрового отпечатка полученного сертификата с сертификатом, который был отправлен. Если цифровые отпечатки являются тем же самым, сертификаты являются тем же самым.
Таким образом можно гарантировать, что сертификат не был изменен в пути. Одна другая потенциальная неопределенность, когда работа с сертификатами является идентификационными данными отправителя. Иногда сертификат самоподписывается, то есть, подписал использование закрытого ключа, соответствующего открытому ключу в сертификате; выпускающий является тем же самым как предметом. Разумно самоподписать сертификат, если получатель уже доверяет отправителю.
Иначе отправитель должен получить сертификат из доверенной третьей стороны, называемой центром сертификации (CA). Чтобы сделать так, Вы отправляете самоподписанный запрос подписания сертификата (CSR) CA. CA проверяет подпись на CSR и Ваших идентификационных данных, возможно проверяя Ваши водительские права или другую информацию. CA тогда ручается за то, что вы были владельцем открытого ключа, выпуская сертификат и подписывая это с его собственным (CA) закрытый ключ. Любой, кто доверяет открытому ключу CA издания, может теперь проверить подпись на сертификате. Во многих случаях у CA самого издания может быть сертификат от CA выше в иерархии CA, приводя к цепочкам сертификата.
Сертификаты об объектах, которым Вы доверяете, обычно импортируются в Ваш keystore как "сертификаты, которым доверяют." Открытый ключ в каждом таком сертификате может тогда использоваться, чтобы проверить, что подписи генерировали использование соответствующего закрытого ключа. Такие проверки могут быть выполнены:
jarsigner инструмент (если документ/код и подпись появляются в файле JAR),Если Вы отправляете подписанный код или документы другим, Вы должны предоставить их сертификат, содержащий открытый ключ, соответствующий закрытому ключу, используемому, чтобы подписать код/документ. keytool -export команда или методы API могут экспортировать Ваш сертификат от Вашего keystore до файла, который может тогда быть отправлен любому нуждающемуся в этом. Человек, который получает сертификат, может импортировать его в keystore как доверяемый сертификат, использование, например, методы API или keytool -import команда.
Если Вы используете jarsigner инструмент, чтобы генерировать подпись для файла JAR, инструмент получает Ваш сертификат и его цепочку сертификата поддержки от Вашего keystore. Инструмент тогда хранит их, наряду с подписью, в файле JAR.
Закрытые ключи и их связанные сертификаты с открытым ключом сохранены в защищённых паролем базах данных, названных keystores. keystore может содержать два типа записей: доверяемые записи сертификата, обсужденные выше, и записи ключа/сертификата, каждый содержащий закрытый ключ и соответствующий сертификат с открытым ключом. Каждая запись в keystore идентифицируется псевдонимом.
У keystore владельца могут быть многократные ключи в keystore, к которому получают доступ через различные псевдонимы. Псевдоним обычно называют в честь определенной роли, в которой keystore владелец использует связанный ключ. Псевдоним может также идентифицировать цель ключа. Например, псевдоним signPersonalEmail мог бы использоваться, чтобы идентифицировать keystore запись, закрытый ключ которой используется для того, чтобы подписать персональную электронную почту, и псевдоним signJarFiles мог бы использоваться, чтобы идентифицировать запись, закрытый ключ которой используется для того, чтобы подписать файлы JAR.
keytool инструмент может привыкнуть к
Методы API могут также привыкнуть к доступу и изменить keystore.
Отметьте следующий относительно использования инструментов и API, связанного с цифровыми подписями.
jar инструмент. Файл JAR является хорошим способом инкапсулировать многократные файлы в одном пятне. Когда файл "подписывается", получающиеся байты цифровой подписи должны быть сохранены где-нибудь. Когда файл JAR подписывается, подпись может войти в файл JAR непосредственно. Это - то, что происходит, когда Вы используете jarsigner инструмент, чтобы подписать файл JAR.jarsigner инструмент, чтобы проверить подлинность подписи файла JAR, человек/организация, который получил файл JAR сначала, должен импортировать в их keystore сертификат, аутентифицирующий открытый ключ, соответствующий закрытому ключу, используемому, чтобы подписать код.Генерирование и Проверка Подписей показывают Вам, как использовать API Безопасности JDK, чтобы подписать документы. Урок показывает то, к чему сделала бы одна программа, выполняемая человеком, у которого есть оригинал документа,
Затем это показывает пример другой программы, выполняемой получателем данных, подписи, и открытого ключа. Это показывает как программа
Этот урок также показывает Вам альтернативные способы импортировать и предоставить ключи, включая сертификаты.
Код Подписания и Предоставление Его шоу урока Полномочий, как использовать Средства обеспечения безопасности Java, чтобы поместить Ваш код в файл JAR, подпишите его, и экспортируйте Ваш открытый ключ. Затем это показывает, как Ваш получатель может использовать эти те же самые инструменты Java, чтобы импортировать Ваш сертификат с открытым ключом и затем добавить запись в файл политики, который предоставит Вашему коду разрешение, это должно получить доступ к системным ресурсам, которыми управляет Ваш получатель.
Урок Файлов Обмена Вы, как использовать средства обеспечения безопасности Java, чтобы подписать документ и затем экспортировать сертификат с открытым ключом для использования с открытым ключом keytool. соответствие закрытому ключу, используемому, чтобы подписать то использование документа keytool. Затем это показывает, как Ваш получатель может проверить Вашу подпись, устанавливая Ваш сертификат с открытым ключом и затем используя jarsigner инструмент, чтобы проверить Вашу подпись.
Эти два урока имеют много общего. В обоих случаях первые два шага для кода или отправителя документа к:
jar инструмент.keytool -genkey команда.Следующие два шага являются дополнительными:
keytool -certreq команда; тогда отправьте получающийся запрос подписания сертификата центру сертификации (CA), такой как VeriSign.keytool -import команда, чтобы импортировать ответ CA.Следующие два шага требуются:
jarsigner инструмент и закрытый ключ, сгенерированный ранее.keytool -export команда. Затем предоставьте подписанный файл JAR и сертификат получателю.В обоих случаях получатель подписанного файла JAR и сертификата должен импортировать сертификат как доверяемый сертификат, используя keytool -import команда. keytool попытается создать доверительную цепочку из сертификата, который будет импортирован в уже доверяемый сертификат в keystore. Если это перестало работать, keytool выведет на экран цифровой отпечаток сертификата и запросит Вас проверять это.
Если бы то, что было отправлено, было кодом, то получатель также должен изменить файл политики, чтобы разрешить необходимым доступам ресурса кодировать подписанный закрытым ключом, соответствующим открытому ключу в импортированном сертификате. Средство осуществления политики может использоваться, чтобы сделать это.
Если бы то, что было отправлено, было одним или более документами, то получатель должен проверить подлинность подписи файла JAR, используя jarsigner инструмент.
Этот урок обсуждает два дополнительных шага. Другие шаги покрываются следующими двумя уроками, Подписывая Код и Предоставление Этого Полномочия и Обмен Файлами.
Когда keytool используется, чтобы генерировать пары "открытый/закрытый ключ", это создает keystore запись, содержащую закрытый ключ и самоподписанный сертификат для открытого ключа. (Таким образом, сертификат подписывается, используя соответствующий закрытый ключ.) Это может соответствовать, если люди, получающие Ваши подписанные файлы уже, знают и доверяют Вашим идентификационным данным.
Однако, сертификату, более вероятно, будут доверять другие, если он будет подписан центром сертификации (CA). Чтобы подписать сертификат CA, Вы сначала генерируете запрос подписания сертификата (CSR) через команду, такую как следующее:
keytool -certreq -alias alias -file csrFile
Здесь псевдоним используется, чтобы получить доступ к keystore записи, содержащей закрытый ключ и сертификат с открытым ключом, и csrFile определяет имя, которое будет использоваться для CSR, создаваемого этой командой.
Вы тогда представляете этот файл CA, такому как VeriSign, Inc. CA аутентифицирует Вас, проситель ("предмет"), и затем подписывает и возвращает сертификат, аутентифицирующий Ваш открытый ключ. Подписывая сертификат, CA ручается, что Вы - владелец открытого ключа.
В некоторых случаях CA возвратит цепочку сертификатов, каждый аутентифицирующий открытый ключ подписывающего лица предыдущего сертификата в цепочке.
Если бы Вы представили запрос подписания сертификата (CSR) центру сертификации (CA), то Вы должны заменить исходный самоподписанный сертификат в своем keystore с цепочкой сертификата, импортируя сертификат (или цепочка сертификатов) возвратился к Вам CA.
Но сначала Вы нуждаетесь в "доверяемом сертификате" запись в Вашем keystore (или в cacerts файл keystore, описанный ниже), который аутентифицирует открытый ключ CA. С такой записью может быть проверена подпись CA. Таким образом, подпись CA на сертификате, или на заключительном сертификате в цепочке, которую CA отправляет Вам в ответ на Ваш CSR, может быть проверена.
Прежде, чем Вы импортируете ответ сертификата из CA, Вы нуждаетесь в одном или более "доверяемых сертификатах" в Вашем keystore или в cacerts файл.
cacerts файл представляет keystore в масштабе всей системы с сертификатами CA. Этот файл находится в каталоге свойств безопасности JRE, java.home/lib/security, где java.home является каталогом установки JRE.
ВАЖНЫЙ: Проверьте Ваш cacerts Файл
Так как Вы доверяете АВАРИИ cacerts файл как объекты для подписания и издания сертификатов другим объектам, следует управлять cacerts зарегистрируйте тщательно. cacerts файл должен содержать только сертификаты об АВАРИИ, которой Вы доверяете. Это - Ваша обязанность проверить доверяемые корневые сертификаты CA, связанные в cacerts файл и принимает Ваши собственные доверительные решения. Удалить недоверяемый сертификат CA из cacerts файл, используйте удалить опцию keytool команда. Можно найти cacerts файл в каталоге установки JRE. Свяжитесь со своим системным администратором, если у Вас нет разрешения, чтобы отредактировать этот файл.
cacerts файл содержит много доверяемых сертификатов CA. Если Вы отправили свой CSR одному из этих доверяемых поставщиков (таких как VeriSign), Вы не должны будете импортировать корневой сертификат поставщика как доверяемый сертификат в Вашем keystore; можно продолжить к следующему разделу видеть, как импортировать ответ сертификата из CA.
Сертификат от CA обычно или самоподписывается или подписывается другим CA, когда Вы также нуждаетесь в сертификате, аутентифицирующем что открытый ключ CA. Предположите, что компания ABC, Inc., CA и что Вы получаете названный файл ABCCA.cer, согласно заявлению самоподписанный сертификат от ABC, аутентифицируя, что открытый ключ CA.
Очень делайте все возможное гарантировать, что сертификат допустим до импорта этого как "доверяемый" сертификат! Просмотрите это сначала (использующий keytool -printcert команда или keytool -import команда без -noprompt опция), и удостоверяются что выведенное на экран соответствие цифрового отпечатка (ков) сертификата ожидаемые. Можно вызвать человека, который отправил сертификат, и сравните цифровой отпечаток (ки), что Вы видите с теми, что они показывают или что безопасный репозитарий с открытым ключом показывает. Только если цифровые отпечатки равны, это, гарантировал, что сертификат не был заменен в пути с чьим-либо (например, атакующий) сертификат. Если бы такая атака имела место, и Вы не проверяли сертификат прежде, чем Вы импортировали это, то Вы закончили бы тем, что доверяли чему-либо, что атакующий подписал.
Если Вы полагаете, что сертификат допустим, можно добавить это к своему keystore через команду, такую как следующее:
keytool -import -alias alias -file ABCCA.cer -keystore storefile
Эта команда создает "доверяемый сертификат" запись в keystore, имя которого - определенное в storefile. Запись содержит данные от файла ABCCA.cer, и это присваивается указанный псевдоним.
Как только Вы импортировали необходимый доверяемый сертификат (ы), как описано в предыдущем разделе, или они уже находятся в Вашем keystore или в cacerts файл, можно импортировать ответ сертификата и таким образом заменить Ваш самоподписанный сертификат цепочкой сертификата. Эта цепочка будет любой той, возвращенной CA в ответ на Ваш запрос (если ответ CA будет цепочкой), или один созданный (если ответ CA является единственным сертификатом) при использовании ответа сертификата, и доверял сертификатам, которые уже доступны в keystore или в cacerts файл keystore.
Как пример, предположите, что Вы отправили свой запрос подписания сертификата VeriSign. Можно тогда импортировать ответ через следующий, который предполагает, что возвращенный сертификат находится в файле, определенном certReplyFile:
keytool -import -trustcacerts
-keystore storefile
-alias alias
-file certReplyFile
Введите эту команду на одной строке.
Ответ сертификата проверяется при использовании доверяемых сертификатов от keystore и дополнительно при использовании сертификатов, сконфигурированных в cacerts файл keystore (если -trustcacerts опция определяется). Каждый сертификат в цепочке проверяется, используя сертификат на следующем уровне выше в цепочке. Вы должны доверять только высокоуровневому "корневому" сертификату CA цепочке. Если Вы уже не доверяете высокоуровневому сертификату, keytool выведет на экран цифровой отпечаток того сертификата и спросит Вас, хотите ли Вы доверять этому.
Новая цепочка сертификата указанного (псевдонимом) запись заменяет старый сертификат (или цепочка) связанный с этой записью. Старая цепочка может быть заменена, только если предоставляется допустимый keypass, пароль, используемый, чтобы защитить закрытый ключ записи. Если никакой пароль не обеспечивается и если пароль с закрытым ключом отличается от keystore пароля, пользователь запрашивается это.
Для более подробной информации о генерировании CSRs и импорте ответов сертификата, см. keytool документация:
|
