Анонимность и неотказуемость – оксюморон или необходимость? К вопросу о защищенном и аутентифицированном обмене данными по электронной почте.

К вопросу о защищенном и аутентифицированном обмене данными по электронной почте

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

Оперативность

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

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

Аутентичность и целостность и... анонимность

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

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

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

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

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

Существующие решения по защите электронной почты

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

Стандартные протоколы (SMTP, POP3, IMAP4), которые применяются для работы с электронной почтой, не содержат механизмов защиты пересылаемых электронных сообщений, поэтому при передаче сообщение может быть легко перехвачено и изменено. Именно по этой причине электронная почта считается ненадежным каналом передачи чувствительных данных.

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

Например, клиенты Microsoft Outlook и Microsoft Outlook Express имеют встроенные возможности отправлять защищенные сообщения с помощью функций Crypto API 2.0 и сертификатов открытых ключей формата X.509.

Этот способ имеет два основных недостатка:

1. сертификаты открытых ключей - платные, и получить их гражданин может только лично по предъявлении целого ряда документов, то есть вменить в обязанность, например, внешним экспертам приобрести сертификаты для обмена данными с организацией не всегда удобно; вместе с тем организация может решить этот вопрос путем развертывания собственного УЦ;
2. клиенты Microsoft Outlook и Microsoft Outlook Express не работают с российскими криптографическими алгоритмами - для того чтобы организовать обмен на сертификатах ГОСТ, необходимо «патчить» операционную систему.

Существуют возможности подключения к почтовым клиентам дополнительных модулей защиты от сторонних производителей. Так в настройках почтового клиента The Bat! можно указать версию PGP и использовать средства защиты данного программного продукта.

Однако и у этого способа есть недостатки:

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

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

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

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

А если речь идет не об исследовательских грантах на 150-200 тыс. рублей, а о более существенных суммах, то весьма вероятна и атака завладения ключами из оперативной памяти в момент выполнения преобразований, которая, как известно, осуществима и в случае «защищенного» хранения ключей на различных «токенах».

Это именно те причины, по которым обмен по электронной почте не принято считать доверенным каналом обмена информацией.

Система обмена сообщениями может считаться защищенной, если она соответствует следующим требованиям:

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

• при создании (отправка ложного сообщения от чужого лица)
• при передаче (перехват сообщения с целью его чтения, искажения или удаления)
• при получении (получение сообщения тем, кому оно не предназначено).

Система обмена сообщениями может считаться оперативной, если она соответствует следующим требованиям:

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

Систему, удовлетворяющую первым двум требованиям можно построить с использованием хорошего СКЗИ (как минимум, включающего в себя аппаратный ключевой контейнер с неизвлекаемыми ключами подписи) и системы цифровых сертификатов X.509 (как уже было упомянуто выше - на основе корпоративного УЦ). Однако применение цифровых сертификатов, по крайней мере, если оно построено добросовестно и ответственно, исключает анонимность.

Возможно, анонимность и аутентичность (неотказуемость) - это вообще взаимоисключающие вещи?

Предлагаемое решение

Обе эти задачи - безопасные вычисления и простота настройки - решаются применением программно-аппаратного комплекса (ПАК) Privacy, в состав которого входит ПСКЗИ ШИПКА (аппаратное средство криптографической защиты информации) и ПО Privacy.

PRIVACY - это программно-аппаратный комплекс, аппаратной частью которого является ПСКЗИ ШИПКА, а программной - набор модулей для

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

Программная часть комплекса является интерфейсом для использования функций ШИПКИ, то есть все криптографические преобразования и работа с ключами производятся исключительно процессором ШИПКИ, а не в ОС компьютера, на котором установлен PRIVACY.

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

ПАК Privacy имеет следующие принципиальные преимущества перед другими средствами обеспечения защищенного обмена данными по электронной почте:

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

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

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

В предлагаемой системе оперативного обмена информацией с применением ПАК Privacy с ПСКЗИ ШИПКА реализован подход организации пространства открытых ключей с помощью сети доверия или системы поручителей. Инфраструктура открытых ключей в Privacy организована по принципу «сети доверия», известному в наибольшей степени по программе PGP. «Сеть доверия» (Web of trust) - это система, в которой в качестве метода подтверждения принадлежности открытого ключа тому или иному пользователю применяется подписывание ключей, подлинность которых установлена, непосредственно пользователями. Если я доверяю ключу и собираюсь им пользоваться - я подтверждаю доверие ему, а если я хочу сообщить о своем доверии этому ключу другим участникам обмена, я его еще и подписываю своей ЭЦП.

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

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

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

В случае с организацией работы с экспертами схема может быть такой.

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

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

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

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

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

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

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

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

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

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

5) проверить отпечатки ключей,

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

7) сгенерировать пару с параметрами, согласованными с «отделом К», не содержащими ФИО эксперта, а содержащими его Nick, псевдоним любого иного рода, или, допустим, порядковый номер по списку экспертов,

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

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

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

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

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

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

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

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

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

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

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

Автор: Конявская С. В.

Дата публикации: 01.01.2012

Библиографическая ссылка: Конявская С. В. Анонимность и неотказуемость – оксюморон или необходимость? К вопросу о защищенном и аутентифицированном обмене данными по электронной почте // Комплексная защита информации. Безопасность информационных технологий. Материалы XVII Международной конференции 15–18 мая 2012 года, Суздаль (Россия). М., 2012. С. 129–133.

---