+7(499)-938-42-58 Москва
+7(800)-333-37-98 Горячая линия

Регистрационная карточка открытого ключа кода аутентификации (ключа шифрования)

Работа с Верба-OW при взаимодействии с ЦУКС МГТУ Банка России

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

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

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

Данная статья описывает процесс получения и генерации ключей, только в Москве и работе с ЦУКС МГТУ БР.Данная статья НЕ содержит какой либо секретной информации, так как вся информация по сути весит на сайте центрального банка и FTP сервере центрального банка. Так же много всего есть на форумах. Вся информация в данной статье носит только публичный характер.

Что бы защитить обмен данными между кредитной организацией и ЦБ используется средства криптографической защиты информации Верба-OW. При обмене данными используют код аутентификации (КА) (это аналог электронной подписи) и ключ шифрования (КШ) (приватный ключ).

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

Ниже я опишу алгоритм взаимодействия с ЦУКС ЦБ:При получении и оформлении ключей взаимодействуют два подразделения — от кредитной организации это информационная безопасность – администратор СКЗИ, а от Банка России это Центр управления ключевыми системами Центрального банка Российской Федерации.Ежегодно происходит плановая смена ключей два раза.

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

Как правило это дискеты с ключами шифрования в двух экземплярах, а так же дискета со справочником открытых ключей — КА.

Ответственный администратор средств криптографической защиты информации кредитной организации, получив дискеты вырабатывает иммитовставки на справочниках КА, устанавливает все это хозяйство пользователям, согласно инструкции полученной в ЦУКС ЦБ и ведет учет СКЗИ в журналах СКЗИ.

Второй раз смена ключей происходит осенью для обмена с Банком России, при которой каждая кредитная организация генерирует свой собственный КА и КШ. Так же осенью кредитная организация генерирует КА для федеральных служб. Всего по сути осенью генерируются ключи на двух носителях, один для федеральных служб -КА, другой для Банка России — КШ и КА. При генерации обязательно делаются копии ключевых носителей, на всякий случай.Генерация ключей происходит с использованием СКЗИ Верба-OW и с использованием лицензионной дискеты и номером и серией ключа, о которых сообщает ЦУКС ЦБ. Ежегодно данная серия меняется.Как правило номера имеют примерно такое значение:2025-941044 — открытый КШ для Банка России(на первом носителе)2025-941044-01 — КА для Банка России (на первом носителе)2025-941044-02 — КА для федеральных служб (на втором носителе)Ниже снимки экрана при генерации ключей в Вербе:

Генерация КШ и КА для ЦБ

Генерация КА для ФС

Затем делается транспортная дискета в двух экземплярах, на которую помещаются открытый КШ, и два КА для ЦБ и ФС. Как правило это файлы с расширениями .lfx и .pub и названия у них соответствует номеру ключа. Данные файлы лежат в директории HD1, дискеты на которую СКЗИ Верба записывала ключ.

Так же печатаются карточки КШ и КА, это такие одно страничные листки с байтами ключа и полями для подписи и печати.На данной карточке проставляют свои подписи руководители кредитной организации, а так же проставляется печать кредитной организации.

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

Данную карточку можно запросить обычно в бухгалтерии, так же копия этой карты хранится в ЦУКС ЦБ, и её при смене руководителей следует актуализировать и направлять в ЦУКС ЦБ.

После этого доверенное лицо приходит в ЦУКС ЦБ, передает туда транспортную дискету с открытыми ключами, карточки регистрации ключей и получает от ЦУКС ЦБ, их справочники открытых ключей и один экземпляр карточки регистрации ключей с их печатью и подписью. Затем Администратор СКЗИ кредитной организации выдает ключи пользователям и ведет учет.

Карта регистрации ключей

Дельные советы для администраторов СКЗИ кредитных организаций:Что бы соблюсти все законы и требования по средствам криптографической защиты информации необходимо все ключевые носители ставить на поэкземплярный учет в том числе и дискеты. Открытые ключи следует хранить не менее пяти лет.

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

Если у вас выдается ключ каждому сотруднику, который шлет информацию, а так и должно по идее быть, то рекомендую использовать не дискеты в качестве ключевых носителей, а токены, они безопаснее и долговечнее, а так же их легче учитывать, единственное нужно будет копировать ключи с дискеты на токены, но это сделать можно с помощью  Вербы-OW.
Генерацию и работу с ключами следует делать на отдельной автономной станции, не подключенной к сети. Данная станция должна находится в защищенном помещении, иметь систему аппаратной защиты от несанкционированного доступа (НСД). В качестве защиты от НСД, могу порекомендовать СЗИ НСД Аккорд-АМДЗ – это аппаратный модуль доверенной загрузки (АМДЗ) для IBM-совместимых ПК – серверов и рабочих станций локальной сети, обеспечивающий защиту устройств и информационных ресурсов от несанкционированного доступа – http://www.accord.ru/amdz.html.

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

Бывает так, что работать специалистом в сфере информационной безопасности, это не только сидение за своим компьютером и выполнение стандартных или рутинных задач. Иногда приходится анализировать информацию, в том числе решать аналитические головоломки, так сказать продумывать действия врага на шаг вперед.В крупных компаниях работают некоторые сотрудники которые не только, нарушают политики безопасности, случайным образом, но и порой нарушают закон, сотрудничают с мошенниками и подделывают документы.Утро понедельника началось как обычно начинается рабочая неделя, делаю отчеты по вирусным атакам и заношу в общую статистику.Сутра начальник поставил важную задачу, сегодня после 20:00, нужно будет созвониться с другим сотрудником из СБ, и снять данные с компьютера вероятного злодея.Потом еще ответил на пару писем в почте. К полдню запустил сканирование сканерами уязвимостей Xspider и Nessus на несколько ресурсов, а сам пошел обедать. Надо сказать кормят у нас не дорого, и при этом неплохо.Хорошенько поев, и придя на свое место, дали мне задание отследить некоторых сотрудников кто куда ходил в интернет. Сижу и думаю, а чего за ними следить, запустил свой баш скрипт, скачал логи и разложив по папочкам отправил по почте начальнику, пускай там их руководители сами решают, куда можно, куда нельзя ходить, а тратить рабочее время и ресурсы это не по мне. Вообще бывает, так люди просят, но при этом не могут объяснить что им действительно надо.Потом разбирался с новым программным обеспечением и средствами криптографической защиты информации, установил на сервер парочку программ и дописал технический регламент по СКЗИ.К вечеру выяснилось, что данные злодея нужно будет снимать ночью, когда все уйдут,  негласно и при этом не оставив следов. Собрав с собой диски с программным обеспечением по снятию образов, и другие инструменты, стал ждать часа икс, параллельно, сходив в кафе. Где-то в полночь поступила команда от нашего наблюдающего, что все сотрудники покинули офис и мы выдвинулись к объекту. Зашли через вход, охрана нас впустила, потом тихо поднялись на этаж. И зашли в помещение, где находился комп предполагаемого злодея. После этого провели фото и видео фиксацию всех вещей, что бы зафиксировать что, где и как лежит, а то бывает так возьмешь что-то подвинешь, а потом не помнишь как лежало.

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

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

Это свело бы все подозрения предполагаемого злодея на нет. Потом отнесли все данные к себе и поехали домой.

Page 3

|

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

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

Отдельно расскажу про лояльность. Люди склонны так рассуждать в тех условиях в которых живут и эти условия формируют у них мышление. Сейчас пошла мода предлагать так называемые услуги в обучении этическому хакингу, тесты на проникновение и многие сидят и спрашивают, что такое тесты на проникновение, кто такой этический хакер и что такое этичность вообще. Помню в России один преподаватель курсов CEH: Certified Ethical Hacking сказал, что это тот человек, который не нарушает закон. По закону он прав.Но что такое закон? Закон по сути это набор норм и правил в стране, который люди обязаны соблюдать, но мир огромен и если я буду дизсамблировать коммерческую программу в России, мне ничего не сделают, а вот в США за это уже посадят в тюрьму, а в каких нибудь тропических момбасах, можно не нарушая закона, вообще несанкционированный доступ получать, если канал в интернет есть.В Китае военные хакеры занимаются взломом и кибер-шпионажем, и при этом для Китая они этичны, так как защищают интересы своего государства, они патриоты и служат своей стране и народу, но для другого государства они представляют угрозу.Поэтому полностью этичных людей не бывает, так же как и законопослушных, люди всегда враждебно настроены против какой-то социальной группы лиц. Мошенник против государства и простых граждан. Полицейский против мошенников. Простые граждане против друг друга. Все они нарушают те или иные законы или этику. К примеру простой гражданин просматривает фильм в интернете, за который должен по идее платить, а так это нарушение авторских прав и должно повлечь за собой ответственность, так как это тоже самое, что и воровство.Так же отдельно по поводу закона хочу привести еще одну догму, если человек хороший, этичный и не нарушает закон, это не значит, что он закон никогда не нарушит. Практически все свои привычные действия человек осуществляет находясь в привычной для него среде, как только среда обитания меняется и появляются новые факторы оказывающие влияние на мозг человека, человек начинает менять свои суждения, стереотипы и порой даже меняется сам по себе. Это значит, что любой человек может нарушить закон и кому-то навредить. Приведу пример: хороший, доброжелательный сотрудник работает в компании никому пароль свой не сообщает, у него захватывают в заложники семью и говорят, ты нам доступ к серверу с данными или деньгами, мы тебе семью живой. В результате человека могут запугать и он доступ возможно даст причем от страха не сообщит в правоохранительные органы. Это вполне адекватная реакция инстинкта самосохранения и выживания заложенная, еще с рождения и можно сказать приобретенная на генетическом уровне. Из данного примера вырисовывается ситуация, что завербовать и сделать инсайдером можно практически любого человека, зная его слабые психологические стороны. Если не смогут подкупить, то смогут запугать или по печени дать.

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

Источник: https://tsnm.livejournal.com/3244.html

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

Регистрационная карточка открытого ключа кода аутентификации (ключа шифрования)

(с изменениями на 17 августа 2004 года)____________________________________________________________________Фактически утратило силу с 1 января 2014 года в связи с истечением срока действия,

предусмотренного пунктом 7.2 положения Банка России от 29 августа 2008 года №321-П.

____________________________________________________________________

____________________________________________________________________
Документ с изменениями, внесенными:
указанием Банка России от 17 августа 2004 года N 1490-У (Вестник Банка России, N 54, 10.09.2004).
____________________________________________________________________

____________________________________________________________________
Принятые до дня вступления в силу Федерального закона от 12 апреля 2007 года N 51-ФЗ акты Центрального банка Российской Федерации, устанавливающие рекомендации по разработке правил внутреннего контроля, порядок определения квалификационных требований к специальным должностным лицам, ответственным за соблюдение правил внутреннего контроля и программ его осуществления, а также требований к подготовке и обучению кадров, идентификации клиентов, выгодоприобретателей, порядок представления информации в федеральный орган исполнительной власти, принимающий меры по противодействию легализации (отмыванию) доходов, полученных преступным путем, и финансированию терроризма в соответствии с Федеральным законом от 7 августа 2001 года N 115-ФЗ “О противодействии легализации (отмыванию) доходов, полученных преступным путем, и финансированию терроризма”, в соответствии со статьей 2 Федерального закона от 12 апреля 2007 года N 51-ФЗ согласованы с уполномоченным органом (Федеральная служба по финансовому мониторингу) и применяются с 1 января 2009 в действующих редакциях – см. информационное сообщение Банка России от 26 декабря 2008 года “О согласовании актов Банка России указанных в статье 2 Федерального закона от 12 апреля 2007 года N 51-ФЗ с уполномоченным органом (Федеральная служба по финансовому мониторингу)”.
– Примечание изготовителя базы данных.________________________________________________________________________________________________________________________________________

С 1 января 2009 года (со дня вступления в силу положения Банка России от 29 августа 2008 года N 321-П) настоящее положениедействует в течение 5 лет для случаев формирования исправленного ОЭС по ОЭС, направленному до 1 января 2009 года и не принятому уполномоченным органом, либо ОЭС, формируемого на замену, удаление, по ОЭС, направленному до 1 января 2009 года и принятому уполномоченным органом, – см. пункт 7.2 положения Банка России от 29 августа 2008 года N 321-П.

– Примечание изготовителя базы данных.____________________________________________________________________

Центральный банк Российской Федерации на основании статьи 7 Федерального закона “О противодействии легализации (отмыванию) доходов, полученных преступным путем, и финансированию терроризма” (с изменениями и дополнениями) (Собрание законодательства Российской Федерации, 2001, N 33 (часть I), ст.3418; 2002, N 44, ст.4296) (далее – Федеральный закон) и статьи 7 Федерального закона “О Центральном банке Российской Федерации (Банке России)” (Собрание законодательства Российской Федерации, 2002, N 28, ст.2790) устанавливает следующий порядок представления кредитными организациями в уполномоченный орган сведений об операциях с денежными средствами или иным имуществом, подлежащих обязательному контролю, а также иных операциях с денежными средствами или иным имуществом, связанных с легализацией (отмыванием) доходов, полученных преступным путем, и финансированием терроризма.

1. Общие положения

1.1. Для целей настоящего Положения применяются следующие основные понятия:

Отчет в виде электронного сообщения (ОЭС) – сообщение, формируемое кредитной организацией (филиалом кредитной организации), содержащее сведения об операциях, предусмотренные Федеральным законом, представленное в электронной форме и снабженное зарегистрированным(и) кодом (кодами) аутентификации.

Извещение в виде электронного сообщения (ИЭС) – сообщение о принятии (непринятии) территориальным учреждением Банка России ОЭС кредитной организации (филиала кредитной организации) для доставки в уполномоченный орган или сообщение о принятии (непринятии) уполномоченным органом ОЭС или отдельных сведений об операциях от кредитной организации (филиала кредитной организации), представленное в электронной форме.

Аутентификация – процесс установления подлинности и целостности сообщения.

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

Код аутентификации сообщения (КА) – данные, включаемые отправителем в состав сообщения и используемые получателем для установления подлинности и целостности сообщения и идентификации его отправителя.

Ключ КА – индивидуальные данные, используемые при создании и проверке КА сообщения и состоящие из:

– секретной части ключа КА (далее – секретный ключ КА) – данных, предназначенных для создания отправителем КА сообщения;

– публичной части ключа КА (далее – открытый ключ КА) – данных, предназначенных для аутентификации сообщения получателем.

Владелец ключа КА – кредитная организация (филиал кредитной организации), учреждение Банка России (структурные подразделения Банка России, территориальные учреждения Банка России), ключ КА которых зарегистрирован в соответствии с Приложением 1 к настоящему Положению.

2. Порядок формирования и направления кредитной организацией сведений в уполномоченный орган

2.1. Представление кредитной организацией, филиалом кредитной организации (далее – кредитная организация) в уполномоченный орган сведений, предусмотренных Федеральным законом, осуществляется в виде ОЭС через территориальные учреждения Банка России (далее – территориальное учреждение).

2.2. Передача в уполномоченный орган ОЭС через территориальное учреждение филиалом кредитной организации допускается только для филиалов, имеющих банковский идентификационный код (БИК) участника расчетов на территории Российской Федерации.

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

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

2.3. Передача-прием ОЭС кредитной организацией и территориальным учреждением осуществляются с применением средств криптографической защиты информации, принятых к использованию в Банке России.

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

2.5. Описание структуры ОЭС представлено в Приложениях 4 и 5 к настоящему Положению.

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

2.7. Ответственность за содержание данных, включаемых в ОЭС, несет владелец ключа КА, которым снабжено сообщение.

2.8.

Кредитная организация доставляет ОЭС, содержащий сведения об операциях с денежными средствами или иным имуществом, подлежащих обязательному контролю, а также иных операциях с денежными средствами или иным имуществом, связанных с легализацией (отмыванием) доходов, полученных преступным путем, и финансированием терроризма, и подготовленный в соответствии с пунктами 2.4, 2.5 и 2.6 настоящего Положения, в территориальное учреждение по каналам связи или на магнитном носителе.

Территориальное учреждение обеспечивает прием ОЭС кредитных организаций, доставленных в территориальное учреждение по каналам связи или на магнитном носителе, а также их контроль в соответствии с главой 3 настоящего Положения.

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

2.9.

В случае приостановления кредитной организацией операции с денежными средствами или иным имуществом, а также при совершении операции по зачислению денежных средств, поступивших на счет физического или юридического лица, хотя бы одной из сторон которой является организация или физическое лицо, в отношении которых имеются полученные в установленном в соответствии с пунктом 2 статьи 6 Федерального закона порядке сведения об их участии в террористической деятельности, либо юридическое лицо, прямо или косвенно находящееся в собственности или под контролем таких организации или лица, либо физическое или юридическое лицо, действующее от имени или по указанию таких организации или лица (далее – операция, связанная с финансированием терроризма), кредитная организация в день приостановления или совершения такой операции формирует отдельный ОЭС, содержащий сведения о данной операции, и немедленно направляет его в уполномоченный орган через территориальное учреждение с признаком в имени файла, определяющим представление сведений об операциях, связанных с финансированием терроризма, в соответствии с Приложением 5 настоящего Положения.
Территориальное учреждение по получении ОЭС, содержащего сведения об операции (операциях), связанной(ых) с финансированием терроризма, немедленно передает его в Главный центр информатизации Банка России (далее – ГЦИ).

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

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

ОЭС, содержащие сведения об операциях с денежными средствами или иным имуществом, подлежащих обязательному контролю, а также иных операциях с денежными средствами или иным имуществом, связанных с легализацией (отмыванием) доходов, полученных преступным путем, и финансированием терроризма, за исключением операций, сведения о которых представляются в уполномоченный орган в порядке, определенном в пункте 2.9 настоящего Положения, и принятые территориальным учреждением от кредитных организаций, передаются территориальным учреждением в ГЦИ в день их принятия до 18.00 по местному времени.

2.11.

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

Источник: http://docs.cntd.ru/document/901837675

Хранилище ключей и сертификатов

Регистрационная карточка открытого ключа кода аутентификации (ключа шифрования)

Защита данных в приложениях имеет важное значение, защита конфиденциальной информации — первостепенное. Одним из самых распространённых способов защиты информации во все времена является шифрование данных.

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

Для этих целей используется keystore — хранилищесертификатов и ключей.

keystore — это специализированное хранилище секретных данных, которое используется Java-приложениями для шифрования, аутентификации и установки HTTPS соединений. Так, для аутентификации клиента и сервера, устанавливающих SSL (Secure Sockets Layer — уровень защищённых cокетов) соединение, требуются приватные ключи и сертификаты.

Если используется односторонняя аутентификация, то keystore используется только на серверной стороне. При двусторонней аутентификации клиент и сервер обмениваются сертификатами; соответственно и у сервера, и у клиента должны быть keystore с парой ключей private/public + сертификат.

Иными словами keystore используется для хранения ключей и сертификатов, применяемых для идентификации владельца ключа (клиента или сервера).

Java поддерживает несколько форматов хранилищ keystore :

• jks— стандартный тип хранилища в виде файла с расширением jks (“java key storage”); устанавливается по умолчанию и, поэтому, применяется наиболее часто.
• jceks— альтернативная реализация хранилища, которая использует более сильное шифрование на основе triple DES; можно обновить имеющееся jks-хранилище до jceks соответствующей командой утилиты keytool.
• pkcs12— тип хранилища, предназначенный прежде всего для хранения или переноса закрытых ключей пользователя, сертификатов и пр.

Каждая запись в keystore имеет уникальный псевдоним (alias). Рекомендуется в keystore не использовать alias'ы, отличающиеся только регистром. В стандартной реализации каждый ключ в хранилище защищается паролем; кроме того, всё хранилище целиком может быть защищено отдельным паролем.

Стандартное хранилище доверенных CA-сертификатов (Certificate Authority) для Java приложений располагается в директории jre/lib/security/cacerts (пароль – changeit).

Информацию в хранилище можно разделить на две категории: ключевые записи (пары ключей private/public) и доверенные сертификаты.

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

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

Чтобы отделить ключевые записи от сертификатов целесообразно использовать различные хранилища : один для собственных ключей, а другой — для доверенных сертификатов, включая сертификаты Центров сертификации (CA).

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

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

В конце статьи представленJava пример просмотра содерживого хранилища ключей и сертификатов CertificateReader.

Утилита keytool

Для управления парами ключей (private/public), сертификатами и хранилищем keystore Java включает утилиту keytool, располагаемую в директории bin.

Для запуска keytool можно использовать командную строку.Опции утилиты позволяют выполнять различные операции и получать определенные сведения.

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

C:\Program Files\Java\jre1.8.0_121\bin>keytoolKey and Certificate Management Tool Commands: -certreq Generates a certificate request-changealias Changes an entry's alias-delete Deletes an entry-exportcert Exports certificate-genkeypair Generates a key pair-genseckey Generates a secret key-gencert Generates certificate from a certificate request-importcert Imports a certificate or a certificate chain-importpass Imports a password-importkeystore Imports one or all entries from another keystore-keypasswd Changes the key password of an entry-list Lists entries in a keystore-printcert Prints the content of a certificate-printcertreq Prints the content of a certificate request-printcrl Prints the content of a CRL file-storepasswd Changes the store password of a keystore Use “keytool -command_name -help” for usage of command_name 

Чтобы получить дополнительную справку о команде необходимо указать ее наименование и волшебное слово help. Не забывайте о дефисе '-' перед опциями :

C:\Program Files\Java\jre1.8.0_121\bin>keytool -certreq -helpkeytool -certreq [OPTION]… Generates a certificate request Options: -alias alias name of the entry to process-sigalg signature algorithm name-file output file name-keypass key password-keystore keystore name-dname distinguished name-storepass keystore password-storetype keystore type. . .-providerarg provider argument-providerpath provider classpath-v verbose output-protected password through protected mechanism Use “keytool -help” for all available commands 

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

Для создания самоподписанного сертификата также необходимо использовать команду -genkey с указанием срока действия сертификата в опции -validity.

Следующая команда создаст пару 2048-битных RSA-ключей, действительных на протяжении 365 дней, с указанным псевдонимом (parent) в заданном файле/хранилище ключей (keystore.jks).

Закрытый ключ в хранилище «закрывается» паролем, открытый ключ «оборачивается» в самоподписанный сертификат.

keytool -genkey -alias parent -keyalg RSA -validity 365 \ -keystore keystore.jks  Если заданного хранилища ключей (keystore.jks) не существует, то keytool создаст его.

При выполнении командыkeytool будет запрашивать некоторые необходимые данные : пароль хранилища, Distinguished Name и пароль закрытого ключа. Многие параметры используются со значениями по умолчанию.

Так, например, алиас – mykey, хранилище – .keystore в домашней директории пользователя (HOMEPATH), алгоритм шифрвания – SHA1withDSA и пр.

Distinquished Name

Сертификат создается в формате X.509. В этом формате в качестве идентификатора владельца используется Distinquished Name или просто DN в формате X.500. Этот же формат идентификации объектов используется в LDAP-протоколе или в SNMP. Distinquished Name задается в виде разделенных через запятую атрибутов :

  • CN — common name (имя владельца);
  • OU — organizational unit or department/division (департамент/отдел);
  • O — organization name (наименование организации);
  • L — locality or city (город/местоположение);
  • ST — state or province;
  • C — country, two chars (страна).

Часть из атрибутов могут быть пропущены; в этом случае им будет присвоено значение Unknown.

Одним из важных атрибутов сертификата являются альтернативные имена SAN (SubjectAlternativeName). Подробности и пример внесения SAN в самоподписанный сертификат представлены на странице настройки конфигурации сервера Tomcat.

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

C:\Program Files\Java\jdk1.8.0_121\bin> \ keytool -v -genkey -dname “CN=java-online.ru, \ OU=Developers, O=IT Systems Inc., L=Moscow, C=RF” \ -alias parent -storetype jks -keystore keystore.jks \ -validity 365 -keyalg RSA -keysize 2048 \ -storepass mystorepass -keypass mykeypass Generating 2 048 bit RSA key pair and self-signed certificate (SHA256withRSA) with a validity of 365 days for: CN=java-online.ru, OU=Developers, O=IT Systems Inc., L=Moscow, C=RF[Storing keystore.jks] 

Новое хранилище было размещено в той же директории, где и располагается keytool.

Создание пары ключей

Для создания пары ключей необходимо использовать команду “-genkeypair”. Следующая команда создаст пару ключей “keypair” в хранилище keystore.jks, где размещен созданный ранее сертификат.

C:\Program Files\Java\jdk1.8.0_121\bin> \ keytool -alias keypair -genkeypair -keystore keystore.jks \ -dname “CN=java-online.ru” Enter keystore password:Enter key password for (RETURN if same as keystore password): 

Сертификат и закрытый ключ сохранены в виде новой keystore записи, идентифицированной псевдонимом “keypair”. Открытый ключ обертывается в формат X.509 — это самоподписанный сертификат, который сохранен как одноэлементная цепочка сертификата.

Опции команды genkeypair

  • {-v}
  • [-storepass storepass]
  • {-alias alias}
  • {-storetype storetype}
  • {-keystore keystore}
  • [-keypass keypass] — является паролем, используемым для защиты закрытого ключа
  • [-dname dname] — определяет отличительное имя в формате X.

    500, связанное с псевдонимом и используемое в качестве issuer и subject поля в самоподписанном сертификате

  • {-startdate value}
  • {-keyalg keyalg} — определяет алгоритм, который будет использоваться, чтобы генерировать пару ключей
  • {-keysize keysize} — определяет размер каждого ключа, который будет сгенерирован
  • {-sigalg sigalg} — определяет алгоритм, который должен использоваться, чтобы подписать самоподписанный сертификат; алгоритм должен быть совместимым с keyalg
  • {-ext ext}*
  • {-validity valDays}
  • {-providerClass provider_class_name {-providerArg provider_arg}}
  • {-protected}
  • {-Jjavaoption}

Создадим еще две пары ключей с псевдонимами “keypair1” и “keypair2”, чтобы при просмотре содержимого хранилища (ниже) был небольшой список пар ключей :

keytool -alias keypair1 -genkeypair -keystore keystore.jks \ -dname “CN=java-online.ru” keytool -alias keypair2 -genkeypair -keystore keystore.jks \ -dname “CN=java-online.ru” 

Экспорт сертификата

Сертификат можно экспортировать из хранилища и предоставить его пользователям Вашей «подписанной» программы. Тогда пользователи могут занести Ваш сертификат в свое хранилище доверенных сертификатов. Для экспорта сертификата используется команда “exportcert”. Следующий пример извлекает из хранилища сертификат в файл “parent.cer” :

C:\Program Files\Java\jdk1.8.0_121\bin> \ keytool -exportcert -keystore keystore.jks \ -alias parent -file parent.cer Enter keystore password:Certificate stored in file  

Импорт сертификата

Чтобы импортировать сертификат в хранилище, нужно его сначала получить каким-либо образом.Не будем мудрить и извлечем сертификат с псевдонимом veriSignclass1g3ca из хранилища доверенных сертификатов jre\lib\security\cacerts (пароль хранилища changeit). То есть выполним командуэкспорта сертификата с указанием соответствующего хранилища :

Экспорт сертификата из хранилища cacerts

C:\Program Files\Java\jdk1.8.0_121\bin> keytool -exportcert -alias veriSignclass1g3ca -keystore \ “C:\Program Files\Java\jdk1.7.0_67\jre\lib\security\cacerts” \ -file veriSignclass1g3ca.cer Enter keystore password:Certificate stored in file  

Импорт сертификата в хранилище

Чтобы импортировать сертификат в хранилище keystore.jks необходимо использовать команду”importcert”. Если в качестве опции указать “-trustcacerts”, то сертификат импортируется в хранилищедоверенных сертификатов, т.е. в jre\lib\security\cacerts. При выполнении команды импорта утилитаkeytool попросит ввести пароль хранилища :

C:\Program Files\Java\jdk1.8.0_121\bin> \ keytool -importcert -keystore keystore.jks \ -file veriSignclass1g3ca.cer Enter keystore password: \ Owner: \ CN=VeriSign Class 1 Public Primary Certification Authority – G3, \ OU=”(c) 1999 VeriSign, Inc. – For authorized use only”, \ OU=VeriSign Trust Network, \ O=”VeriSign, Inc.”, \ C=USIssuer: \ CN=VeriSign Class 1 Public Primary Certification Authority – G3, \ OU=”(c) 1999 VeriSign, Inc. – For authorized use only”, \ OU=VeriSign Trust Network, \ O=”VeriSign, Inc.”, \ C=US \ Serial number: 8b5b75568454850b00cfaf3848ceb1a4 \Valid from: \ Fri Oct 01 04:00:00 MSD 1999 until: Thu Jul 17 02:59:59 MSK 2036 \Certificate fingerprints: \ MD5: B1:47:BC:18:57:D1:18:A0:78:2D:EC:71:E8:2A:95:73 \ SHA1: 20:42:85:DC:F7:EB:76:41:95:57:8E:13:6B:D4:B7:D1:E9:8E:46:A5 \ SHA256: CB:B5:AF:18:5E:94:2A:24:02:F9:EA:CB:C0:ED:5B:B8:76:EE:A3: \ C1:22:36:23:D0:04:47:E4:F3:BA:55:4B:65 Signature algorithm name: SHA1withRSA Version: 1 \Trust this certificate? [no]: yCertificate was added to keystore 

Просмотр хранилища

Для чтения содержимого хранилища необходимо использовать команду “-list”. В качестве опции “-keystore” можноуказать путь к хранилищу. По умолчанию команда “-list” отображает цифровой отпечаток SHA1 сертификата. Следующийкод позволяет просмотреть содержимое созданного хранилища, включающего сертификат и три пары ключей :

Источник: http://java-online.ru/keystore-keytool.xhtml

Поделиться:
Нет комментариев

    Добавить комментарий

    Ваш e-mail не будет опубликован. Все поля обязательны для заполнения.