7 (Ответики к экзамену), страница 3

Электронная подпись

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

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

1. Получатель мог удостовериться в подлинности отправителя.

2. Отправитель позднее не мог отречься от документа.

3. Получатель не мог подделать документ.

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

1. Подпись с секретным ключом

Одно из решений проблемы электронной подписи – наделить полномочиями третью сторону, которую знают все, которая знает всех и которой верят все. Назовем ее «Большой Брат» (Big Brother - BB). Что произойдет, если А позже откажется от посланного сообщения? В суде В предъявит сообщение А, KBB (А, t, P), которое будет отправлено BB как непререкаемому авторитету. СД расшифрует своим ключом эту запись и все увидят А, t, P. Единственная слабость такого решения – злоумышленник может скопировать диалог между отправителем и получателем через BB и позже его повторить. Механизм временных меток позволяет уменьшить эту проблему. Кроме этого, сохранение последних RA позволяет В заметить их повторное использование.

7.1.6.2. Подпись на основе открытого ключа

Недостаток вышеописанного решения в том, что все должны доверять СД, который может читать сообщения. Кандидатами на его роль может быть правительство, банк, нотариус. Здесь есть два недостатка. Оба основаны на том, что схема работает до тех пор, пока сторона А либо умышленно не рассекретила свой ключ, либо не изменила его в одностороннем порядке. При наступлении судебного случая В предъявляет P и DA(P), так как он не знает закрытый ключ А, то он не мог подделать DA(P). При этом должно быть EA(DA(P))=P, в чем суд легко может убедиться.

Если А обращается в суд, то есть Р и EA(P), что легко сопоставить с тем, что есть у В. Однако, если А заявит, что у него украли ключи, а сам тайно передаст их, либо сменит их, не сообщив об этом В, то в последнем случае текущий EA будет не применим к тому DA(P), который предъявит В. Здесь надо сопоставлять даты передачи сообщения и смены ключей.

7.1.6.3. Сокращение сообщения

Рассмотренные методы электронной подписи критикуют за то, что они подменяют задачу установления подлинности задачей соблюдения секретности. Зачастую нужно только установление подлинности. Кроме этого, шифрование – операция медленная. Поэтому часто желательно просто поставить подпись, чтобы удостоверить подлинность сообщения. Ниже рассматривается метод, который не требует шифрования всего сообщения. Эта схема основана на идее однозначной функции перемешивания, которая по сообщению вычисляет битовую строку фиксированной длины. Эта функция называется сокращение сообщения (MD). Она обладает тремя важными свойствами:

1. Для заданного Р вычислить MD(P) просто.

2. Имея MD(P), невозможно восстановить Р.

3. Никто не сможет подобрать таких два сообщения, что MD от них будут одинаковыми.

Этот метод можно применять как с закрытым ключом, так и с открытым. В случае закрытого ключа, как в схеме на рисунке 7-22, надо пятый элемент в сообщении от ВВ к В заменить на KBB(A, t, MD(P)). «Большой брат» подписывает не все сообщение, а лишь его сокращение. В случае возникновения спора В легко докажет в суде, что он получил именно сообщение Р, так как нет другого сообщения, которое даст такое же MD(P). Сторона А также легко докажет свою правоту, так как MD вычисляет ВВ. В случае открытого ключа этот метод также работает. Его схема показана на рисунке 7-24. Здесь сторона А шифрует своим ключом не все сообщение, а лишь его сокращение. При этом сторона В защищена от злоумышленника, так как если он подменит сообщение, то сторона В, получив сообщение и вычислив его MD, сравнит полученное MD и обнаружит подмену.

Служба DNS. Организация, функционирование и основные протоколы почтовой службы в Internet. Протокол FTP.

Несмотря на то, что любая машина в Интернете имеет уникальный IP-адрес, который представляет собой число (см. главу 5), люди предпочитают работать с именами. Очень непросто разговаривать, используя машинную адресацию (как бы это звучало: “192.112.36.5 обещает вскоре…”?), еще труднее запомнить эти адреса. Поэтому компьютерам в Интернете для удобства пользователей были присвоены собственные имена. Все интернет-приложения позволяют пользоваться системными именами вместо числовых адресов. Все эти имена зафиксированы в специальной распределенной базе данных DNS, которая поддерживает иерархическую систему имен для идентификации абонентских машин или узлов в сети Интернет.

7.2.2. Поиск адреса по доменному имени

Теперь, после того как мы узнали, как соотносятся домены и создаются имена, познакомимся с тем, как использовать эту замечательную систему. Она работает автоматически. Нам не надо разыскивать адрес, соответствующий имени или подавать специальную команду для его поиска (в UNIX – команда nslookup). Все компьютеры в Интернете способны пользоваться доменной системой. Когда используют имя, например, www.lvk.cs.msu.su, надо преобразовать его в адрес. Для этого приложение начинает запрашивать помощь у DNS-серверов. Эти приложения обладают соответствующей базой данных, в число обязанностей которых входит обслуживание такого рода запросов. DNS-сервер начинает обработку имени с его правого конца и двигается по нему влево, т.е. сначала производится поиск адреса в самой верхней группе иерархии, потом постепенно поиск опускается по иерархии, тем самым сужая область поиска. Однако с целью сокращения поиска, на первом шаге опрашивается локальный узел DNS. В последнем случае местный сервер обращается к корневому серверу. Это сервер, который знает адреса серверов имен высшего уровня (самых правых в имени), в нашем случае это уровень государств (ранга домена su). У него запрашивается адрес компьютера, ответственного за зону su. Местный DNS-сервер связывается с этим сервером, расположенным на вершине иерархии, и запрашивает у него адрес сервера,   ответственного за домен msu.su. Теперь уже запрашивается сервер, отвечающий за домен msu, потом опрашивается сервер домена cs, затем – lvk, и у него запрашивается адрес рабочей машины www. Как уже было сказано, для повышения эффективности поиск начинается не с самого верха, а с наименьшего домена, в который входите и вы, и компьютер, имя которого вы запросили. Например, если ваш компьютер имеет имя cmc.cs.msu.su, то опрос начнется (если имя не выяснится сразу) не со всемирного сервера, чтобы узнать адрес сервера группы su, а сразу с группы su, что сокращает поиск и по объему, и по времени.

7.2.3. Серверы имен

Должно быть ясно, что нет и не может быть единого сервера, содержащего всю базу DNS. Чтобы сделать базу распределенной, все пространство имен доменов разбивают на непересекающиеся зоны. Границы зоны определяет администратор зоны. Каждая зона покрывает часть дерева доменов, в нее входят сервера имен этих доменов. Обычно в каждой зоне есть основной сервер зоны и несколько вспомогательных серверов имен. Часто из соображений надежности сервер зоны располагают вне зоны. Весь процесс поиска IP-адреса по имени домена, описанный в разделе 7.2.2., реализуют сервера имен. Если запрос относится к юрисдикции того сервера имен, к которому обратились, т.е. запрашиваемый домен находится в ведении данного сервера имен, тогда этот сервер генерирует ответ, содержащий записи всех ресурсов, соответствующих запросу. Этот ответ считается авторитетным, т.е. содержащаяся в нем информация считается a priori верной. Если запрос относится к удаленному домену, то сервер имен генерирует запрос к соответствующему удаленному серверу имен. Однако прежде чем обратиться к удаленному серверу имен, обращающийся сервер посмотрит записи ресурсов в своей кэш-памяти. Записи в кэш-памяти не являются авторитетными. Время актуальности содержащейся в них информации, определяет поле времени жизни (см. назначение поля времени жизни в разделе 7.2.4.).

7.2.4. Записи ресурсов

С каждым доменом связано множество ресурсов, отнесенных к этому домену. Эти записи хранятся в базе DNS. Когда происходит обращение к DNS с каким-либо именем, в ответ приходит не только IP-адрес, но и запись о ресурсах, соответствующих указанному имени. Запись ресурса состоит из пяти полей (см. рисунок 7-27). Вот эти поля: «Имя домена» (Domain name), «Время жизни» (Time to live), «Класс» (Class), «Тип» (Type), «Источник полномочий» (SOA - Start Of Authority). В поле «Имя домена» указано имя домена, к которому относится эта запись. При обращении к базе DNS с таким ключом в ответ поступают все записи, у которых в этом поле указано заданное имя. Поля «Время жизни» указывает интервал времени в секундах, в течение которого поля этой записи не меняются. Например, 86 400 - это число секунд в сутках. Если в этом поле указано такое число, то это значит, что запись меняется не чаще одного раза в сутки. В третьем поле «Класс» указано IN, если ресурс, к которому относится эта запись, является ресурсом Интернета. Здесь могут быть и другие значения, но они встречаются редко.

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

7.4.1. Архитектура и сервис

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

7.4.2. Агент пользователя

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

7.4.2.1. Отправка почты

Чтобы послать сообщение, пользователь должен предоставить адрес назначения, само сообщение и другие параметры, например, приоритетность, секретность и т.п. Для создания сообщения может быть использован любой текстовый процессор либо текстовый редактор, встроенный в агент пользователя. Все параметры должны быть заданы в формате, который понимает и с которым может работать агент пользователя. Большинство агентов пользователя ожидает адрес назначения в формате DNS: mailbox@location.

7.4.2.2. Чтение почты

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

7.4.3. Формат сообщений

Рассмотрим формат самого сообщения. Начнем с формата по RFC 822, а потом перейдем к мультимедийному расширению этого документа.

7.4.4. Передача сообщений

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

7.4.4.1. SMTP (Simple Mail Transfer Protocol) – Простой протокол передачи почты

В Internet почта передается следующим образом. Машина отправитель устанавливает ТСР-соединение с 25-м портом машины получателя. На 25 порту находится почтовый демон, который работает по протоколу SMTP. Он принимает соединение и распределяет поступающие сообщения по почтовым ящикам машины-получателя. SMTP - это простой ASCII-протокол. После установления соединения машина-отправитель работает как клиент, а машина-получатель – как сервер. Сервер шлет текстовую строку, идентифицирующую его и готовность принимать почту. Если он не готов принимать почту, то клиент разрывает соединение и повторяет всю процедуру позже. Если сервер подтвердил свою готовность, то клиент сообщает, от кого и кому предназначено очередное сообщение. Если сервер подтвердил наличие получателя, то он дает команду клиенту, и сообщение передается без контрольных сумм и подтверждений, так как ТСР-соединение обеспечивает надежный поток байтов. Если сообщений несколько, то все они передаются. Обмен по соединению происходит в обоих направлениях. У SMTP протокола, несмотря на то что он хорошо описан в RFC 821, есть несколько проблем. Первая – длина сообщения не может превосходить 64 Кбайт. Другая – time out. Если время ожидания подтверждения у отправителя и получателя не согласовано, то один будет разрывать соединение, не дождавшись, тогда как другой просто очень загружен. Третья – почтовый ураган. Пусть машина-получатель имеет лист рассылки, где указана машина-отправитель, и наоборот. Тогда отправка сообщения по листу рассылки вызовет бесконечно долгие обмены сообщениями между этими машинами. Для преодоления этих проблем в RFC 1425 был описан протокол ESMTP. Клиент вначале шлет команду EHLO, если она отвергается сервером, то это означает, что сервер работает по SMTP.

7.4.4.2. Почтовые шлюзы