Электро́нная цифрова́я по́дпись (ЭЦП)- реквизит электронногодокумента, предназначенный для защиты данного электронного документа от подделки, полученный врезультате криптографического преобразования информации с использованием закрытого ключаэлектронной цифровой подписи и позволяющий идентифицировать владельца сертификата ключа подписи,а также установить отсутствие искажения информации в электронном документе, а также обеспечивает неотказуемость подписавшегося.
Схема электронной подписи обычно включает в себя:
- алгоритм генерации ключевых пар пользователя;
- функцию вычисления подписи;
- функцию проверки подписи.
Функция вычисления подписи на основе документа и секретного ключа пользователя вычисляет собственноподпись. В зависимости от алгоритма функция вычисления подписи может быть детерминированной иливероятностной. Детерминированные функции всегда вычисляют одинаковую подпись по одинаковымвходным данным. Вероятностные функции вносят в подпись элемент случайности, что усиливаеткриптостойкость алгоритмов ЭЦП. Однако, для вероятностных схем необходим надёжный источникслучайности (либо аппаратный генератор шума, либо криптографически надёжный генераторпсевдослучайных бит), что усложняет реализацию.
В настоящее время детерминированные схемы практически не используются. Даже в изначальнодетерминированные алгоритмы сейчас внесены модификации, превращающие их в вероятностные (так, валгоритм подписи PKCS#1 добавила предварительное преобразование данных (OAEP), включающее в себя,среди прочего, зашумление).
Функция проверки подписи проверяет, соответствует ли данная подпись данному документу и открытомуключу пользователя. Открытый ключ пользователя доступен всем, так что любой может проверить подписьпод данным документом.
Поскольку подписываемые документы — переменной (и достаточно большой) длины, в схемах ЭЦП зачастуюподпись ставится не на сам документ, а на его хэш. Для вычисления хэша используются криптографическиехэш-функции, что гарантирует выявление изменений документа при проверке подписи. Хэш-функции неявляются частью алгоритма ЭЦП, поэтому в схеме может быть использована любая надёжная хэш-функция.
Алгоритмы ЭЦП делятся на два больших класса: обычные цифровые подписи и цифровые подписи свосстановлением документа. Обычные цифровые подписи необходимо пристыковывать к подписываемомудокументу. К этому классу относятся, например, алгоритмы, основанные на эллиптических кривых (ГОСТ Р34.10-2001, ДСТУ 4145-2002). Цифровые подписи с восстановлением документа содержат в себеподписываемый документ: в процессе проверки подписи автоматически вычисляется и тело документа. Кэтому классу относится один из самых популярных алгоритмов — код аутентичности сообщения, несмотряна схожесть решаемых задач (обеспечение целостности документа и неотказуемости авторства). АлгоритмыЭЦП относятся к классу асимметричных алгоритмов, в то время как коды аутентичности вычисляются посимметричным схемам.
Защищённость
Цифровая подпись обеспечивает:
- Удостоверение источника документа. В зависимости от деталей определения
документа могут бытьподписаны такие поля, как «автор», «внесённые изменения», «метка времени» и т. д.
- Защиту от изменений документа. При любом случайном или преднамеренном
изменении документа (илиподписи) изменится хэш, следовательно, подпись станет
недействительной.
- Невозможность отказа от авторства. Так как создать корректную подпись можно, лишь зная закрытый ключ, аон известен только владельцу, то владелец не может отказаться
от своей подписи под документом.
- Предприятиям и коммерческим организациям сдачу финансовой отчетности в
государственные учреждения в электронном виде;
- Организацию юридически значимого электронного документооборота.
Возможные атаки на ЭЦП таковы…
Подделка подписи
Получение фальшивой подписи, не имея секретного ключа — задача практически нерешаемая даже дляочень слабых шифров и хэшей.
Подделка документа (коллизия первого рода)
Злоумышленник может попытаться подобрать документ к данной подписи, чтобы подпись к нему подходила.Однако в подавляющем большинстве случаев такой документ может быть только один. Причина вследующем:
· Документ представляет из себя осмысленный текст.
· Текст документа оформлен по установленной форме.
· Документы редко оформляют в виде Plain Text — файла, чаще всего в формате DOC или HTML.
Если у фальшивого набора байт и произойдет коллизия с хешем исходного документа, то
Должны выполниться 3 следующих условия:
· Случайный набор байт должен подойти под сложно структурированный формат файла.
· То, что текстовый редактор прочитает в случайном наборе байт, должно образовывать текст, оформленныйпо установленной форме.
· Текст должен быть осмысленным, грамотным и соответствующий теме документа.
Впрочем, во многих структурированных наборах данных можно вставить произвольные данные в некоторыеслужебные поля, не изменив вид документа для пользователя. Именно этим пользуются злоумышленники,подделывая документы.
Вероятность подобного происшествия также ничтожно мала. Можно считать, что на практике такого случитьсяне может даже с ненадёжными хеш-функциями, так как документы обычно большого объёма — килобайты.
Получение двух документов с одинаковой подписью (коллизия второго рода)
Куда более вероятна атака второго рода. В этом случае злоумышленник фабрикует два документа содинаковой подписью, и в нужный момент подменяет один другим. При использовании надёжной хэш-функции такая атака должна быть также вычислительно сложной. Однако эти угрозы могут реализоваться из-за слабостей конкретных алгоритмов хэширования, подписи, или ошибок в их реализациях. В частности,таким образом можно провести атаку на SSL-сертификаты и алгоритм хеширования
Социальные атаки
Социальные атаки направлены на «слабое звено» криптосистемы — человека.
· Злоумышленник, укравший закрытый ключ, может подписать любой документ от имени владельца ключа.
· Злоумышленник может обманом заставить владельца подписать какой-либо документ, например используяпротокол слепой подписи.
· Злоумышленник может подменить открытый ключ владельца (см. управление ключами) на свой собственный,выдавая себя за него.
Алгоритмы ЭЦП
· Американские стандарты электронной цифровой подписи: ECDSA
· Российские стандарты электронной цифровой подписи: ГОСТ Р 34.10-94 (в настоящее время не действует),ГОСТ Р 34.10-2001
· Украинский стандарт электронной цифровой подписи: ДСТУ 4145-2002
· Стандарт RSA
· схема Шнорра
· ElGamal
· Вероятностная схема подписи Рабина
Управление ключами
Важной проблемой всей криптографии с открытым ключом, в том числе и систем ЭЦП, является управлениеоткрытыми ключами. Необходимо обеспечить доступ любого пользователя к подлинному открытому ключулюбого другого пользователя, защитить эти ключи от подмены злоумышленником, а также организоватьотзыв ключа в случае его компрометации.
Задача защиты ключей от подмены решается с помощью сертификатов. Сертификат позволяет удостоверитьзаключённые в нём данные о владельце и его открытый ключ подписью какого-либо доверенного лица. Вцентрализованных системах сертификатов (например PKI) используются центры сертификации,поддерживаемые доверенными организациями. В децентрализованных системах (например
Управлением ключами занимаются центры распространения сертификатов. Обратившись к такому центрупользователь может получить сертификат какого-либо пользователя, а также проверить, не отозван ли ещётот или иной открытый ключ.
Юридические аспекты
В России юридически значимый сертификат электронной подписи выдаёт удостоверяющий центр. Правовыеусловия использования электронной цифровой подписи в электронных документах регламентирует ФЗ «ОБ ЭЛЕКТРОННОЙ ЦИФРОВОЙ ПОДПИСИ»
- Электронная почта
Электро́нная по́чта (англ. email , e - mail, от англ. electronic mail) — технология и предоставляемые ею услуги по пересылке и получению электронных сообщений (называемых «письма» или «электронные письма») по распределённой (в том числе глобальной) компьютерной сети.
Электронная почта по составу элементов и принципу работы практически повторяет систему обычной (бумажной) почты, заимствуя как термины (почта, письмо, конверт, вложение, ящик, доставка и другие), так и характерные особенности — простоту использования, задержки передачи сообщений, достаточную надёжность и в то же время отсутствие гарантии доставки.
Достоинствами электронной почты являются: легко воспринимаемые и запоминаемые человеком адреса вида имя_пользователя@имя_домена (например, somebody@example.com); возможность передачи как простого текста, так и форматированного, а также произвольных файлов; независимость серверов (в общем случае они обращаются друг к другу непосредственно); достаточно высокая надёжность доставки сообщения; простота использования человеком и программами.
Недостатки электронной почты: наличие такого явления, как спам (массовые рекламные и вирусные рассылки); возможные задержки доставки сообщения (до нескольких суток); ограничения на размер одного сообщения и на общий размер сообщений в почтовом ящике (персональные для пользователей).
В настоящее время любой начинающий пользователь может завести свой бесплатный электронный почтовый ящик, достаточно зарегистрироваться на одном из интернет-порталов.
В терминологии электронной почты выделяются следующие компоненты:
· MTA (англ. Mail Transfer Agent — агент пересылки почты) — отвечает за отправку почты; чаще всего это почтовый сервер, но, в принципе, возможна реализация с отправкой почты через smart host.
· MDA (англ. Mail Delivery Agent — агент доставки почты) — отвечает за доставку почты конечному пользователю.
· MUA (англ. Mail user agent — почтовый агент пользователя; в русской нотации закрепился термин почтовый клиент) — программа, обеспечивающая пользовательский интерфейс, отображающая полученные письма и предоставляющая возможность отвечать, создавать, перенаправлять письма.
· MRA англ. Mail retrieve agent — почтовый сервер, забирающий почту с другого сервера по протоколам, предназначенным для MDA.[5]
В случае использования веб-интерфейса MDA и MUA могут совпадать. В случае использования выделенных серверов для хранения почты пользователей всё взаимодействие пользователя с сервером может происходить по протоколам, не укладывающимся в эту схему.
Почтовые сервера обычно выполняют роль MTA и MDA. Некоторые почтовые сервера (программы) выполняют роль как MTA, так и MDA, некоторые подразумевают разделение на два независимых сервера: сервер-MTA и сервер-MDA (при этом, если для доступа к ящику используются различные протоколы — например, POP3 и IMAP, — то MDA в свою очередь может быть реализован либо как единое приложение, либо как набор приложений, каждое из которых отвечает за отдельный протокол).
Общепринятым в мире протоколом обмена электронной почтой является SMTP (англ. Simple mail transfer protocol — простой протокол передачи почты). В общепринятой реализации он использует DNS для определения правил пересылки почты (хотя в частных системах, вроде Microsoft Exchange, SMTP может действовать исходя из информации из других источников).
В различных доменах настроены свои, независимые друг от друга, почтовые системы. У каждого почтового домена может быть несколько пользователей. (Однако, фактически, может быть так, что одна организация или персона владеет многими доменами, которые обслуживаются (физически) одной почтовой системой). Почта передаётся между узлами с использованием программ пересылки почты (англ. Mail transfer agent, MTA; такими, как, например, sendmail, exim4, postfix, Microsoft Exchange Server, Lotus Domino и т. д.). Поведение систем при связи друг с другом строго стандартизировано, для этого используется протокол SMTP (и соблюдение этого стандарта, наравне с всеобщей поддержкой DNS всеми участниками, является основой для возможности связи «всех со всеми» без предварительных договорённостей). Взаимодействие почтовой системы и пользователей, в общем случае, никак не регламентируется и может быть произвольным, хотя существуют как открытые, так и закрытые (завязанные на ПО конкретных производителей) протоколы взаимодействия между пользователями и почтовой системой. Программа, работающая в почтовой системе и обслуживающая пользователей, называется MDA (англ. mail delivery agent, агент доставки почты). В некоторых почтовых системах MDA и MTA могут быть объединены в одну программу, в других системах могут быть разнесены в виде разных программ или вообще выполняться на различных серверах. Программа, с помощью которой пользователь осуществляет доступ, называется MUA (англ. mail user agent). В случае использования веб-интерфейса для работы с почтой, ее роль выполняет приложение веб-интерфейса, запускаемое на сервере.
Внутри заданной почтовой системы (обычно находящейся в рамках одной организации) может быть множество почтовых серверов, выполняющих как пересылку почты внутри организации, так и другие, связанные с электронной почтой задачи: фильтрацию спама, проверку вложений антивирусом, обеспечение автоответа, архивация входящей/исходящей почты, обеспечение доступа пользователям различными методами (от POP3 до ActiveSync). Взаимодействие между серверами в рамках одной почтовой системы может быть как подчинено общим правилам (использование DNS и правил маршрутизации почты с помощью протокола SMTP), так и следовать собственным правилам компании (используемого программного обеспечения).
Маршрутизация почты[
Почтовый сервер, получив почту (из локального источника или от другого сервера) проверяет, существуют ли специфичные правила для обработки почты (правила могут основываться на имени пользователя, на домене в адресе, содержимом письма и т. д.), если специфичных правил не обнаружено, то проверяется, является ли почтовый домен локальным для сервера (то есть является ли сервер конечным получателем письма). Если является, то письмо принимается в обработку. Если же домен письма не является локальным, то применяется процедура маршрутизации почты (являющаяся основой для передачи писем между различными серверами в Интернете).
При маршрутизации используется только доменная часть адреса получателя (то есть часть, находящаяся после символа @). Для домена получателя ищутся все MX-записи. Они сортируются в порядке убывания приоритета. Если адрес почтового сервера совпадает с одним из узлов, указанных в MX-записях, то все записи с приоритетом меньшим приоритета узла в MX-записи (а также MX-запись самого узла) отбрасываются, а доставка осуществляется на первый отвечающий узел (узлы пробуются в порядке убывания приоритета). Это сделано на случай, если почтовый сервер отправителя является релеем почтового сервера получателя. Если MX-запись для домена не найдена, то делается попытка доставить почту по A-записи, соответствующей домену. Если же записи о домене нет, то формируется сообщение о невозможности доставки (Bounce message). Это сообщение формируется с MAIL FROM:<> (RFC 5321), в поле «To» указывается отправитель исходного письма, в поле в поле «From» — E-Mail вида MAILER-DAEMON@имя сервера. Под именем сервера понимается имя хоста в Интернет, который сгенерировал уведомление. MAIL FROM:<> позволяет защитить почтовые сервера от бесконечного хождения сообщений об ошибке между серверами — если сервер обнаруживает, что не может доставить письмо с пустым обратным адресом, то он уничтожает его. Сообщение о невозможности доставки, так же, может формироваться через некоторое время. Это происходит в случае, если обнаруженная проблема определяется, как временная, но истекает время нахождения сообщения в очереди (RFC 5321, раздел 4.5.4.1. Sending Strategy).
Если сеть имеет различные DNS-серверы (например, внешние — в Интернете, и локальные — в собственных пределах), то возможна ситуация, когда «внутренние» DNS-серверы в качестве наиболее приоритетного получателя указывают на недоступный в Интернете сервер, куда и перенаправляется почта с релея, указанного как узел-получатель для Интернета. Подобное разделение позволяет осуществлять маршрутизацию почты по общим правилам между серверами, не имеющими выхода в Интернет.
Протоколы получения почты
После попадания почты на конечный сервер, он осуществляет временное или постоянное хранение принятой почты. Существует две различные модели работы с почтой: концепция почтового хранилища (ящика) и почтового терминала.
Структура письма
При передаче по протоколу SMTP Электронное письмо состоит из следующих частей:
· Данные SMTP-конверта, полученные сервером. Часть этих данных может отсутствовать в самом сообщении. Так, например, в RCPT TO (envelope to) содержится список получателей письма, при этом в самом письме получатель может быть не указан. Эта информация передаётся за пределы сервера только в рамках протокола SMTP, и смена протокола при доставке почты (например, на узле-получателе в ходе внутренней маршрутизации) может приводить к потере этой информации. В большинстве случаев эта информация недоступна конечному получателю, который использует не-SMTP протоколы (POP3, IMAP) для доступа к почтовому ящику. Для возможности контролировать работоспособность системы эта информация обычно сохраняется в журналах почтовых серверов.
· Самого сообщения (в терминологии протокола SMTP — 'DATA'), которое, в свою очередь, состоит из следующих частей, разделённых пустой строкой:
· Заголовков (англ. headers) письма. В заголовке указывается служебная информация и пометки почтовых серверов, через которые прошло письмо, пометки о приоритете, указание на адрес и имя отправителя и получателя письма, тема письма и другая информация.
· Тела письма. В теле письма находится, собственно, сообщение письма.
Данные SMTP-конверта
Данные SMTP-конверта содержат в себе следующую информацию:
· Параметр HELO/EHLO — содержит имя отправляющего узла (не имя отправителя, а имя сервера или компьютера пользователя, который обратился к серверу).
· Параметр MAIL FROM — содержит адрес отправителя. Адрес может быть произвольным (в том числе с несуществующих доменов), однако, это значение используется для формирования уведомлений об ошибках доставки сообщений (а, отнюдь, не значение из поля From заголовка сообщения). В силу этого, неправильное значение не позволит Вам узнать судьбу Вашего отправления. Этот адрес, так же, может проверяться при первичной проверке на спам[7]. При отправке сообщения, обычный почтовый клиент формирует MAIL FROM из содержимого поля From.
· Параметр RCPT TO — наиболее важное поле для доставки почты, содержит электронный адрес одного или нескольких получателей. В SMTP-конверте может быть несколько таких полей. При отправке сообщения, обычный почтовый клиент формирует список для RCPT TO из содержимого полей сообщения To, Cc и Bcc.
Заголовки письма
Заголовки письма описываются стандартами RFC:
· RFC 2076 — Common Internet Message Headers (общепринятые стандарты заголовков сообщений), включает в себя информацию из других RFC: RFC 822, RFC 1036, RFC 1123, RFC 1327, RFC 1496, RFC 1521, RFC 1766, RFC 1806, RFC 1864, RFC 1911).
· RFC 4021 — Registration of Mail and MIME Header Fields (регистрация почты и поля заголовков MIME).
Заголовки отделяются от тела письма пустой строкой. Заголовки используются для журналирования прохождения письма и служебных пометок (иногда их называют кладжами). В Microsoft Outlook эти заголовки называются «Заголовки Интернет». В заголовках обычно указываются: почтовые серверы, через которые прошло письмо (каждый почтовый сервер добавляет информацию о том, от кого он получил это письмо), информацию о том, похоже ли это письмо на спам, информацию о проверке антивирусами, уровень срочности письма (может меняться почтовыми серверами). Также в заголовке обычно пишется программа, с помощью которой было создано письмо. Поскольку заголовки являются служебной информацией, то чаще всего почтовые клиенты скрывают их от пользователя при обычном чтении писем, но также предоставляют возможность увидеть эти заголовки, если возникает потребность в более детальном анализе письма. В случае, если письмо из формата SMTP конвертируется в другой формат (например, в Microsoft Exchange 2007 письма конвертируются в MAPI), то заголовки сохраняются отдельно, для возможности диагностики.
Заголовки обычно добавляются снизу вверх (то есть каждый раз, когда к сообщению нужно добавить заголовок, он дописывается первой строкой, перед всеми предыдущими).
Помимо служебной информации, заголовки письма также хранят и показываемую пользователю информацию, это обычно отправитель письма, получатель, тема и дата отправки.
Заголовки сообщения могут содержать только 7-битные символы[8]. При необходимости использовать национальные символы в каких-то полях, требуется использование кодировок. Как правило, этоBase64 или Quoted-Printable.
Дата: 2019-07-24, просмотров: 322.
