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

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

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

Решение задач управления информационным наполнением считается успешным при соблюдении:

– конфиденциальности;

– целостности.

Обеспечить конфиденциальность обмена электронной почтой просто только тео­ретически; при практической реализации — это весьма трудная задача, в том числе и с точки зрения управления.

Недавние инциденты с вирусами Melissa и Love Bug продемонстрировали реаль­ную угрозу: сегодня в глобальной сети Internet один вирус может поразить миллионы хостов практически по всему миру.

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

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

– обеспечить оперативное информирование пользователей при обнаружении ата­ки;

– использовать адаптивную фильтрацию подозрительной почты;

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

– внедрить адекватные процедуры резервного копирования и восстановления дан­ных.

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

С помощью адаптивной фильтрации подозрительной почты во время последних инцидентов в большинстве компаний смогли отфильтровывать как входящие, так и исходящие сообщения со словами «I Love You» в теме сообщения (фирменный знак этих вирусов). Кроме того, сообщения рекомендуется ограничивать по размеру, по крайней мере, на первое время после обнаружения опасности. Это поможет воспре­пятствовать распространению сомнительных вложений, таких, как исполняемые фай­лы. Порог в 5 кбайт является достаточным.

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

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

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

Все методы извлечения информации должны быть защищенными. Выполните ана­лиз защиты всех методов сбора сообщений и периодически проверяйте каждую среду доступа (включая беспроводную и телефонную связь). К примеру, еще в 1997 году шифровальщик Брюс Шнайер (из Counterpane Lab) обнаружил «дыру» в технологии шифрования, используемой в цифровых сотовых телефонах.

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

Самый очевидный выход из создавшегося положения — шифрование. Почему же этот способ не получил распространения, и все письма в Internet не кодируются авто­матически? В первую очередь, из-за наличия разных стандартов. Два наиболее попу­лярных способа шифрования — S/MIME (Secure Multipurpose Internet Mail Extension) и POP (Pretty Good Privacy) — несовместимы друг с другом.

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

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

Вероятность расшифровки и подмены подобного письма очень мала. Правда, появ­ляется необходимость регулярно проверять актуальность чужих ключей — не были ли они изменены или скомпрометированы (например, украдены). Для этого служат компании, подтверждающие актуальность ключа. К тому же вы вправе потребовать от подобной компании цифровой ключ, подтверждаемый другой компанией, и т. д. По­добная иерархия компаний, подтверждающих ключи друг друга, с самой авторитетной компанией наверху реализована в протоколе S/MIME. PGP использует для этих же целей Сеть доверия (Web of Trust), состоящую из общих друзей и знакомых.

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

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

Для достижения этой цели предлагаются, по крайней мере, три конкурирующих подхода, каждый на базе соответствующих протоколов. Первый подход опирается на Secure/MIME (S/MIME) компании RSA Security. Это расширение протокола кодиро­вания MIME. S/MIME стал форматом де-факто для двоичных мультимедийных вложе­ний в электронные сообщения. Хотя первый протокол S/MIME был разработан RSA, текущая версия S/MIME базируется на спецификации IETF (RFC 2632,2633 и 2634) и, таким образом, представляет собой открытый стандарт.

Благодаря включению сообщений в формате стандарта на криптографию с откры­тыми ключами PKCS7 (Public Key Cryptography Standart #7) в тело MIMI протокол S/MIME позволяет получателю идентифицировать личность отправителя с помощью шифрования с открытыми ключами. При таком подходе подпись сообщения просто сравнивается с открытым ключом отправителя.

S/MIME — наиболее широко распространенный способ сквозной защиты информа­ционного наполнения. Он пользуется поддержкой основных поставщиков протоколов для обмена сообщениями, включая Microsoft, Lotus, Netscape (Communications и Novell).

Второй подход к обеспечению конфиденциальности электронной почты (Pretty Good Privacy, PGP) был предложен Филиппом Циммерманом в виде бесплатного инстру­ментария для UNIX, однако впоследствии его коммерческой реализацией занялась Network Associates, и теперь PGP доступен и для платформ Windows и Macintosh.

Хотя PGP мог применяться к составным вложениям сам по себе, имеющиеся пред­ложения ориентируются на MIME как на структуру информационного наполнения и поэтому называются PGP/MIME. Кроме того, IETF в настоящее время работает над открытой версией PGP, называемой OpenPGP.

Как и S/MIME, спецификация PGP предполагает шифрование сообщений с исполь­зованием симметричного ключа (один и тот же ключ применяют как для шифрования, так и для дешифровки данных), после чего он присоединяется к сообщению и шифру­ется с помощью технологии с открытыми ключами. Это исключает необходимость шифрования текста сообщения посредством открытого ключа — весьма медленного процесса.

Однако в отличие от S/MIME, технология PGP не предусматривает иерархичес­кого распространения (и подписи) открытых ключей. Вместо этого PGP опирается на концепцию «паутины доверия», в соответствии с которой пользователь получает открытые ключи надежными средствами (например, лично) и затем самостоятельно решает относительно принятия других ключей, подписанных теми же доверенными уполномоченными. Такой механизм прост для реализации на корпоративном уров­не, но ему недостает масштабируемости иерархических PKI (Public-key Infrastructure).

Третий подход составляет совокупность РЕМ (Privacy Enhanced Mail) и MOSS (MIME Object Security Services). Задуманный еще в 1993 году, протокол РЕМ стал первой попыткой защитить обмен электронной почтой; он был опубликован IETF в качестве проекта стандарта в RFC 1421,1422,1423 и 1424. Однако его существенным недостатком была неспособность обрабатывать восьмибитовые текстовые сообщения (что необходимо для мультимедийных вложений), поэтому спецификация MOSS и была предложена в качестве замены РЕМ.

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

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

Фантастически быстрый успех многих компаний, предлагающих новые техноло­гии для Internet, связан, как правило, с изобретением нового Web-сервиса, полезность которого для широкой аудитории настолько очевидна, что число его пользователей достигает десятков миллионов человек. Так было, в частности, с бесплатной регистра­цией почтовых адресов в Hotmail. Для работы с подобными системами не требуется никакого клиентского программного обеспечения, кроме браузера, абоненты не при­вязаны жестко к своему провайдеру и могут пользоваться электронной почтой в лю­бом месте, оборудованном Web-терминалом. Несмотря на очевидные достоинства, одна важная проблема не решена и здесь. Речь идет о защищенности передаваемой коррес­понденции от посторонних глаз.

Сложность задачи заключается не в алгоритмах шифрования, которые известны и достаточно хорошо проработаны, а в организации удобной работы с ключами, в пре­одолении строгих юридических рогаток и, самое главное, в завоевании доверия клиен­та. Хорошо известно, что в США установлены очень жесткие ограничения на экспорт стойких средств шифрования, за смягчение которых борются не только защитники прав и свобод человека, но и ведущие производители прикладных информационных систем, потому что их продукция теряет свою конкурентоспособность на мировом рынке. ФБР и ЦРУ лоббируют принятие законов, регламентирующих предоставление государственным органам по решению суда секретных ключей, выданных клиентам уполномоченными на это организациями. И хотя приводимые аргументы (борьба с терроризмом и контроль над государствами, не признающими решений мирового со­общества) выглядят убедительно, не только преступники, но и законопослушные субъекты хотели бы иметь дополнительные гарантии сохранения конфиденциальнос­ти своей корреспонденции.

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

В ZipLip.com пошли по простому пути: переданное с помощью SSL сообщение не дешифруется и хранится на почтовом сервере до тех пор, пока за ним не обратится получатель. Соответствующий ключ генерируется на основе фразы-пароля, которая должна быть заранее известна и отправителю, и получателю. Поскольку шифрование происходит на сервере, находящемся на территории США, экспортные ограничения не нарушаются, и длина ключа может быть любой. С другой стороны, из-за того что ключ хранится вместе с зашифрованным сообщением, получить доступ к нему могут не только представители ФБР, но и сотрудники ZipLip. Таким образом, в этом случае все сводится к проблеме доверия.

В основе решения HushMail лежит более изощренный подход. Поскольку оно ба­зируется на технологии Java (JVM 1.5.5 и более поздние редакции), в качестве почто­вых клиентов можно использовать лишь достаточно свежие версии Web-браузеров: Netscape Navigator (начиная с версии 4.04) и Internet Explorer (начиная с версии 4.5). Благодаря применению средств шифрования с открытым ключом корреспонденты не обязаны знать и помнить чужие пароли. На разных этапах используются симметрич­ные и несимметричные алгоритмы шифрования. Напомним, что при симметричном шифровании один и тот же ключ служит как для кодирования, так и для декодирова­ния, а при несимметричном — кодирование осуществляется открытым ключом, а де­кодирование — секретным,

Специалисты Hush Communications приложили немало усилий, чтобы, с одной сто­роны, максимально упростить процедуру генерации ключей, а с другой — сделать их недоступными для посторонних лиц (в том числе и государственных органов) без раз­решения владельца. При этом многие правовые коллизии были решены столь тонко, что представитель ФБР был вынужден признать легитимность системы HushMail, по­сетовав на то, что она выводит передаваемую корреспонденцию из под юридического контроля.

При регистрации пользователя в HushMail пара ключей (открытый и секретный) генерируется непосредственно на его клиентской машине. Для этого туда загружает­ся специальный Java‑апплет, который предлагает пользователю случайным образом поманипулировать мышью, а затем на основе зафиксированной и рандомизированной последовательности координат формирует пару ключей (длиной 1024 бит). Сообще­ние шифруется специальным апплетом, пересылаемым с сервера HushMail на браузер клиента. Понимая, что строгие судьи могут квалифицировать загрузку апплета как некую форму незаконного экспорта криптографического программного обеспечения, Hush Communications разместила свой сервер за пределами США (по разным сведе­ниям, в Канаде или на расположенном в Карибском бассейне острове Ангвилла). Кро­ме того, сами апплеты были разработаны гражданами Ангвиллы — своеобразной про­граммистской оффшорной зоны с весьма мягким законодательством в отношении средств шифрования.

Открытый ключ пересылается на сервер HushMail, откуда он автоматически выда­ется другому клиенту системы HushMail, написавшему секретное письмо данному пользователю. Таким образом, в конфиденциальной переписке могут принимать учас­тие лишь зарегистрированные пользователи HushMail.

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

Указанная проблема решается следующим образом. Еще на этапе регистрации апплет предлагает пользователю задать достаточно длинную фразу-пароль, которую тот должен хорошо запомнить. На основе пароля генерируется симметричный 128-раз­рядный ключ, с помощью которого секретный ключ шифруется и отправляется на хра­нение на сервер HushMail. Теперь, независимо от местонахождения, вы можете под­ключиться к HushMail и загрузить с сервера свой дополнительно зашифрованный секретный пароль.

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

Итак, все потенциально опасные для пользователя операции — генерация ключей, шифрование и декодирование сообщений — осуществляются на его клиентской ма­шине вдали от сервера HushMail. Сообщения и секретные ключи хранятся на нем в зашифрованном виде и не могут быть вскрыты без фразы-пароля. Тем самым специа­листы Hush Communications лишний раз хотят убедить всех в том, что защита коррес­понденции обеспечивается не их «клятвами», а объективной изоляцией критически важных ключей.

Дата добавления: 2014-01-07