поиск по сайту

Если у вас возникли вопросы, или вам что-то не нравится, вы можете пожаловаться

Организация распределения ключей с помощью Privacy

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

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

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

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

Это ПАК Privacy, на базе ПСКЗИ ШИПКА.

Пропустить описание системы, перейти сразу к схеме работы

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

Инфраструктура открытых ключей в Privacy организована по принципу «сети доверия» - стандарта OpenPGP, известного в наибольшей степени по программе PGP. При этом Privacy работает не только с импортной, но и с российской криптографией, являясь интерфейсной программной надстройкой над сертифицированным по классу КС3 российским криптосредством.

«Сеть доверия» (Web of trust) - это система, в которой в качестве метода подтверждения принадлежности открытого ключа тому или иному пользователю применяется подписывание ключей, подлинность которых установлена, непосредственно пользователями. В этом случае решение о доверии тому или иному ключу пользователь принимает самостоятельно, под свою ответственность, на основании доверия тем доводам, которые он сам считает достаточными (сличение отпечатка, наличие подписи лица, которому он доверяет на ключе, которому он доверяет, и т. д.).

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

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

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

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

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

Схема работы при этом может быть такой

1. Уполномоченное подразделение, назовем его «отдел К», наделяет троих сотрудников правом удостоверять подлинность открытых ключей участников информационного обмена. Каждый из них генерирует с помощью Privacy пару ключей, и в специальном журнале фиксируются записи, содержащие ФИО и должность сотрудников, серийные номера их ШИПОК, имя, ID и прочие свойства пар, выработанных для данной задачи, включая их Fingerprint'ы и сроки действия. Можно сохранять снимок экрана со свойствами ключа в файл. Имя файла со снимком может иметь имя, совпадающее с порядковым номером учетной записи.

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

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

Свойства ключа (пары), которые отображаются в Privacy, перечислены в разделе 5.1.2.2. «Руководства пользователя», которое можно прочитать в разделе Документация.

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

Обратившийся должен

1) прийти в «отдел К»,

2) получить там ШИПКУ (или прийти со своей ШИПКОЙ, если у него уже есть),

3) получить ПО Privacy,

4) импортировать в свою ШИПКУ открытый ключ одного из уполномоченных сотрудников. Процедура производится в присутствии уполномоченного сотрудника и владельца устройства ШИПКА.

5) проверить его отпечаток,

6) подтвердить доверие этому ключу,

7) сгенерировать пару с параметрами, согласованными с «отделом К»,

8) экспортировать ее открытый ключ и передать его сотруднику «отдела К».

Сотрудник «отдела К»

1) импортирует открытый ключ обратившегося в свою ШИПКУ

2) проверяет его отпечаток

3) подтверждает доверие этому ключу, подписывая его своей подписью

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

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

4. Обратившийся, в свою очередь, может импортировать свой ключ снова к себе в устройство, и он импортируется уже с подписью «отдела К» (которую он может проверить с помощью имеющегося в его ШИПКЕ открытого ключа), чтобы раздавать его своим будущим абонентам. Это целесообразно в том случае, если «отдел К» не планирует регистрировать в журнале всех, кому передан открытый ключ каждого обратившегося. Скорее всего это излишне, но при необходимости можно организовать распределение ключей и так.

Главных плюсов в этой схеме, на наш взгляд, два:

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

2. пользователи, вступающие в защищенную коммуникацию имеют четкие и однозначные основания для принятия решения о доверии ключу, поскольку их распределение контролируется уполномоченным отделом, ведь несмотря на то, что взаимодействие происходит с абонентами, находящимися вне контролируемой зоны, наличие подписи «отдела К» является достаточным признаком для признания ключа нескомпрометированным, ведь извлечь из ШИПКИ закрытый ключ, чтобы как-то его скомпрометировать, невозможно, а в случае компрометации целиком ШИПКИ (то есть, в общем случае - это отказ пользователю в праве участвовать в защищенной переписке дальше), «отдел К» просто отзовет подпись.

Все механизмы, применяемые в решении - стандартные (гостированные алгоритмы, стандарт PKCS#11), не требуют внесения изменений в проприетарное ПО (патчей) или вскрытия корпусов компьютеров, что может быть связано с серьезными организационными трудностями, или разворачивания УЦ.  

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

В случае необходимости такие проверки можно сделать регламентными.

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

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

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

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

В последнем случае может быть целесообразной разработка автоматизированной системы управления ключами, поскольку «ручное» в этом случае может оказаться трудоемким. Мы готовы это сделать для Заказчика по согласованному заранее ТЗ.