12. Электронная почта

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

Сейчас вряд ли кто задумывается о том, как же работает электронная почта. Элек­тронная почта (Electronic mail, E-mail) — до сих пор остается одним из самых распро­страненных и дешевых средств обмена информацией во всех странах мира. Считается, что в мире имеется более 50 млн пользователей электронной почты. Сейчас предста­вить себе работу или просто общение без электронной почты иногда просто невоз­можно. Она упрощает общение, деловое партнерство или рассылку интересующей информации. И хотя уже существует много других таких Internet-сервисов, как голо­совая почта, Internet-телефония или им подобные, но тем не менее стандартная старая добрая и хорошо всем знакомая электронная почта живет. Это вполне естественно, поскольку речь здесь идет просто о передаче порции информации, в подавляющем большинстве случаев текстовой. Это дешевле, чем звонить в другую страну по теле­фону или использовать голосовую почту, когда объем передаваемой информации на несколько порядков ниже. На самом деле доказывать, что почта хороша и удобна, нет смысла, поскольку всем это понятно и так.

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

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

Для того чтобы этот обмен информацией между двумя, по крайней мере, абонен­тами состоялся, необходимо написать послание и, указав адрес, опустить в почто­вый ящик, откуда письмо неминуемо попадет на почтовый узел. Если указанный ад­рес соответствует общепринятым стандартам, то через некоторое время почтальон положит его в почтовый ящик адресата. Далее абонент вскроет послание, и — обмен информацией состоялся. Чтобы ускорить этот процесс, мы поднимаем телефонную трубку, набираем телефонный номер и, если произойдет правильное соединение, то наш абонент услышит то, что мы хотим ему передать. Если абонент не отвечает или его номер занят, придется повторить процедуру еще раз (возможно и несколько раз), сожалея о том, что на это тратится драгоценное время. Исследования показали, что, несмотря на почти мгновенный доступ к телефонной связи, около 75% телефонных вызовов заканчиваются безуспешно. Очень часто нужного абонента просто нет на месте.

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

Принцип функционирования электронной почты

Система современной электронной почты состоит из трех основных компонентов:

Q пользовательского агента (User Agent);

Q транспортного агента (Transfer Agent);

Q доставочного агента (Delivery Agent).

Программы, которые предоставляют пользователям возможность читать и состав­лять почтовые сообщения, называются пользовательскими агентами. Примеры таких программ — Internet Mail в Windows 95, Netscape, Pine, команда mail в UNIX и многие другие.

Самым первым пользовательским агентом была программа /bin/mail, разработан­ная в лаборатории AT&T. Сейчас применяются несколько программ этого класса. Кроме того, существуют пользовательские агенты с графическим интерфейсом пользовате­ля. Существует также стандарт, определяющий включение в почтовые сообщения объек­тов мультимедиа. Он называется MIME (Multipurpose Internet Mail Extensions) — многоцелевые расширения электронной почты для Internet. Данный стандарт поддер­живают многие пользовательские агенты.

Пользовательский агент формирует письмо: позволяет написать его текст, присое­динить файлы, указать тему письма и все адреса.

Затем письмо передается транспортному агенту — наиболее сложной и важной части почтовой системы. Это программы, которые принимают почту от пользователь­ского агента, интерпретируют адреса пользователей и переправляют почту на соот­ветствующие компьютеры для последующей доставки. Кроме этого, транспортный агент принимает входящую почту от других транспортных агентов. Транспортный агент отрабатывает протокол SMTP (Simple Mail Transport Protocol) — простой протокол транспортировки почты.

Дойдя до машины второго пользователя, письмо при помощи транспортного агента этой машины передается доставочному агенту (Delivery Agent), который принимает по­чту от транспортного агента, доставляет ее соответствующим пользователям и отвечает за формирование MailBox пользователя. Обычно MailBox—это файл, где последователь­но хранятся все приходящие письма. Почта может доставляться конкретному лицу, в спи­сок рассылки, в файл, в программу и т. п. Для обслуживания получателей каждого типа необходим отдельный агент mail—доставочный агент локальных пользователей. На этом работа почтовой системы заканчивается. Из MailBox почта читается почтовыми клиента­ми (например Netscape), но к работе самой системы это уже отношения не имеет.

Для пересылки любой, в том числе и обычной почты, необходимо знать адрес (нельзя писать письмо «На деревню. Дедушке.»). Это относится и к электронной почте. В системе электронной почты адресация бывает двух видов:

Q маршрутно-зависимая;

Q маршрутно-независимая.

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

UUCP-адрес состоит из списка машин (радиоэлектронного оборудования), через которые должно пройти сообщение на пути к пункту назначения. Элементы списка разделяют восклицательными знаками. Например, в электронно-почтовом UUCP-ад­ресе: mcvax!uunet!ucbvax!hao!boulder!lair!evi — пунктом назначения является машина lair, а получатель — абонент evi. Каждая машина в цепочке имеет непосредственное UUCP-соединение с машинами, которые находятся в сети до и после нее. Например, машина ucbvax должна иметь соединения с машинами пао и uunet. Цепочки UUCP-адресов бывают очень длинными, но теперь, когда широко используется Internet, на­стоящие громадины увидишь очень редко. Когда электронная почта строилась в ос­новном на базе UUCP, администраторы вынуждены были помнить список компьютеров на довольно больших участках базовой сети UUCP. В формате электронной Interne-почты адрес, приведенный выше, будет иметь вид evi@lair.

Электронно-почтовый Internet-адрес имеет следующий формат:

пользователь@машина,

где знак @ отделяет имя пользователя от обозначения машины.

Рассмотрим в качестве примера адрес электронной почты. Этот адрес (рис. 4.31) содержит идентификатор абонента и сведения о его местоположении. В нашем случае

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

То, что стоит справа от знака @, называется доменом и однозначно описывает ме­стонахождение абонента. Домен состоит из составных частей, которые разделяются точками. Самая правая часть домена — это домен верхнего уровня, который, как пра­вило, обозначает код страны адресата. Код страны утвержден международным стан­дартом ISO. В нашем случае используется код Российской Федерации — ш. Однако в качестве домена верхнего уровня может фигурировать и обозначение сети. Например, в США, где существуют сети, объединяющие высшие учебные заведения или прави­тельственные организации, в качестве доменов верхнего уровня используются сокра­щения edu — Educational institutions (например, cs.berkeley.edu), gov — Government institutions и др.

Следующая составная часть домена — поддомен является однозначно определяе­мым внутри домена верхнего уровня. Нетрудно догадаться (по аналогии с обычным письмом), что после кода страны должен следовать код города — spb в нашем случае однозначно определяет код Санкт-Петербурга. Совокупность составных частей доме­на spb.ru называется доменом второго уровня. Аббревиатуры домена второго уровня определяются в соответствии с правилами, принятыми доменом верхнего уровня.

Домен третьего уровня — stels.spb.ru. В нашем случае домен третьего уровня вклю­чает в себя название фирмы Stels. Правила образования имен внутри доменов третье­го уровня — это личное дело доменов второго уровня.

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

Q файл, содержащий список адресов;

Q файл, в который должны добавляться сообщения;

D команду, на вход которой должны передаваться сообщения.

Псевдонимы могут быть определены:

Q в файле конфигурации пользовательского агента;

Q в общесистемном файле псевдонимов /etc/aliases;

(3 в пользовательском файле пересылки -/.forward.

Сначала система электронной почты ищет псевдонимы в файле конфигурации пользовательского агента, затем в файле aliases и наконец в пользовательском файле пересылки.

Вот несколько примеров переадресации почты с помощью псевдонимов, опреде­ленных в файле aliases:

stels: savspb;

savspb: stels@mailhub;

autors: savspb,som,avit,trent.

В первой строке указано, что почту, поступающую на имя stels, следует доставлять пользователю savspb на локальный компьютер. Во второй, что всю почту, поступаю­щую на имя savspb, следует доставлять на компьютер mailhub. И, наконец, третья строка определяет, что почту, адресованную authors, следует доставлять пользовате­лям savspb, som, avit и trent. Поддерживается рекурсия, поэтому почта, посланная на имя stels, в конце концов, попадает по адресу savspb@mailhub.

Чтобы электронное письмо дошло до адресата, необходимо его оформить в соот­ветствии с международными стандартами и написать стандартизованный почтовый электронный адрес. Общепринятый формат послания определяется документом под названием «Standard for the Format of ARPA — Internet Text messages», сокращенно — Request for Comment или RFC822. Этот формат определяет, что электронное посла­ние должно состоять из текста самого письма и заголовка, который приписывается в начале сообщения. Заголовок отделяется от текста пустой строкой и содержит несколь­ко строчек необходимой информации об этом сообщении: дату отправления, адрес, обратный адрес, тему сообщения и т. д. Каждая из строк заголовка имеет вид: назва­ние: текст. Бывает несколько видов строк заголовка. Не все они обязательно должны присутствовать. Некоторые строки почтовые службы добавляют автоматически. (Received: Date:), другие задает сам автор письма (То:, Subject:).

Само письмо состоит из двух частей: заголовка и тела письма. Для системы основ­ным является заголовок, для пользователей — тело письма. Заголовок содержит све­дения об авторе письма, о получателях, времени создании. Заголовок также пополня­ется по мере прохождения письма через сеть, в него заносится информация о том, в какое время письмо проходило и через какие компьютеры. За заголовком следует пу­стая линия, отделяющая тело письма. В теле прописываются такие важные парамет­ры, как кодировка текста письма, тип присоединенных файлов и некоторые другие. В отличие от многих иных сервисов, письма передаются по сети целиком, но не в том смысле, что одним большим IP-пакетом, а в том, что все пакеты, содержащие письмо, собираются на каждом передающем компьютере. Система передачи полностью анало­гична обычному роутингу сетевых пакетов. Для нее применяются записи так называе­мого Mail eXchanger (MX), которые содержат информацию о том, куда в зависимости от адреса получателя требуется направлять письмо. Так в целом происходит работа почтовых систем.

Рассмотрим пример почтового сообщения: Received: by avg386.kiae.su; Thu, 20 Dec 90 13:51:5^MSK

Received: byjumbo.kiae.su; Thu, 20 Dec 90 12:52:17 MSK

Received: from CS.ORST.EDU by fiiug.fi with SMTP id AA15539 (5.65+/IDA-1.3.5 for avg@kiae.su); Thu, 20 Dec 90 08:19:05 +0200

Received: from jacobs.CS.ORST.EDU by CS.ORST.EDU (5.59/1.15) id AA19981; Wed, 19 Dec 90 22:19:59 PST

Received: by jacobs.CS.ORST.EDU (5.54/1.14) id AA02240; Wed, 19 Dec 90 23:19:35 MST

Date: Wed, 19 Dec 90 23:19:35 MST

From: Harry Brooks <brooksh@jacobs.cs.orst.edu>

Message-Id: <9012200619.AA02240@jacobs.CS.ORST.EDU>

To: avg@kiae.su

Subject: Re: Новое ПО

Status: RO

Привет! Вышли мне описание твоей новой программы.

Received: — это отметка о прохождении через некоторое электронное устрой­ство (своеобразный почтовый штемпель). Количество таких отметок (строчек) пока­зывает, через сколько машин прошло сообщение, чтобы достигнуть адресата. При этом каждая из машин обозначает, когда сообщение проходило через нее (ставит штемпель).

Date: — дата и время отправления письма; они указываются в стандартном фор­мате, поскольку большинство почтовых систем умеют сортировать сообщения по времени.

From: — имя отправителя и обратный адрес, который выделен угловыми скобками.

Message-Id: — внутренний уникальный, единственный в мире идентификатор со­общения, который присваивается почтовой службой отправителя каждому письму. Его можно использовать как исходящий номер для ссылок на письмо.

То: — адрес получателя.

Subject: — тема сообщения. Пометка Re: в этой строке обозначает, что сообщение является ответом (от слова reply) на другое сообщение. У исходного сообщения и у ответа строка Subject: одна и та же. Для ответа почтовая служба автоматически берет тему из исходного сообщения. Это удобно, когда идет длинный разговор на одну тему. Вы сможете потребовать, чтобы почтовая служба отсортировала сообщения по те­мам, и освежить в памяти предыдущие фразы этого разговора. В этой строке, состав­ляя сообщение, желательно указывать короткое название, но как можно более инфор­мативное. Сообщение под заголовком вроде «А помнишь, как-то раз ты мне говорила...» не всякий станет читать.

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

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

Сервисное обслуживание электронной почты

Такой сервис электронной почты, как немедленный обмен сообщениями IM (Instant Messaging), достаточно популярен в современных сетях. Однако реализация прило­жений на базе IM требует защиты трафика сообщений в случае выполнения следую­щих задач:

–        идентификация;

–        разделение файлов;

–        отказ в обслуживании.

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

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

Отказ в обслуживании DoS (Denial of Service) связан с тем, что для поддержки приложений IM администратору часто приходится открывать произвольный диапазон портов на брандмауэре, которые могут быть использованы для проведения атак DoS.

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

–        подсматривание (stalking);

–        подделка (spoofing);

–        спам (spamming).

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

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

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

Рассмотрим еще один новый сервис сети — систему унифицированного обмена сообщениями (Unified Messaging, UM). Наверное, вам приходилось сталкиваться со следующей рекламой услуг (часто бесплатных): «Факсимильные, голосовые, пейджинговые, сотовые и электронные сообщения в одном легко доступном почтовом ящике Internet¹». Предпосылка проста: использовать повсеместность Internet для доступа к нескольким разновидностям сообщений с помощью единого метода, часто на базе Web.

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

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

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

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

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

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

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

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

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

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

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

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

Недавние инциденты с вирусами 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 лишний раз хотят убедить всех в том, что защита коррес­понденции обеспечивается не их «клятвами», а объективной изоляцией критически важных ключей.