СПОСОБ СОХРАНЕНИЯ ИНФОРМАЦИИ ДЛЯ ПОДТВЕРЖДЕНИЯ ОТПРАВКИ СООБЩЕНИЯ ЭЛЕКТРОННОЙ ПОЧТЫ Российский патент 2019 года по МПК H04L12/859 G06F21/64 H04L12/58 

Область техники, к которой относится изобретение

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

Уровень техники

Наиболее широко в мире для отправки сообщений электронной почты между серверами электронной почты (e-mail) используется протокол Simple Mail Transfer Protocol или SMTP (RFC 5321). Иногда пользователю электронной почты необходимо доказать (например, для юридически значимых действий), что определенная информация была им отправлена адресату в определенное время. В принципе, такую информацию можно получить от провайдера услуг электронной почты. Но зачастую провайдер не хранит такую информацию, а кроме того, такие процедуры требуют привлечения персонала провайдера и потому дороги.

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

Сущность изобретения

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

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

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

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

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

При этом база данных может быть блокчейном, или база данных может быть реляционной или объектной.

И наконец, хэш-код и второй хэш-код сообщения с соответствующими им ЭЦП могут находится в публичном доступ для чтения.

Краткое описание чертежей

На фиг. 1 изображена общая схема системы, реализующей способ по настоящему изобретению.

Подробное описание изобретения

Способ по настоящему изобретению может быть реализован в нескольких вариантах, которые, тем не менее, осуществляются сходным образом. На фиг. 1 представлена типичная схема системы, реализующей способ сохранения информации для подтверждения отправки сообщения электронной почты. Почтовый сервер 1 получает сообщение электронной почты от источника электронного сообщения 2. При этом способ формирования и передачи электронного сообщения от источника 2 к серверу 1 может быть различный. Например, через почтовый клиент типа Thunderbird по протоколу SMTP. Или пользователь системы через браузер формирует электронное сообщение на Web-сервере, а Web-сервер передает электронное сообщение на почтовый сервер 1 в общем случае в любом формате, понятном почтовому серверу 1. Либо источник 2 может быть корпоративным почтовым сервером, например, Microsoft Exchange.

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

Почтовый сервер отправляет сообщение электронной почты другому почтовому серверу 3 (почтовому серверу получателю) по протоколу SMTP через почтовый релей 5. После отправки сообщения серверу получателя 3 почтовый сервер 1 записывает в один из блоков системы блокчейн (который является вариантом распределенной базы данных) 4 упомянутый хэш-код. В блоке, который является частным случаем записи (record) в базе данных, может быть и только один хэш-код, или несколько хэшкодов для разных сообщений. В силу свойств технологии блокчейн изменить информации в блоке будет очень трудно, потому что блоки подписывают электронной цифровой подписью (ЭЦП). Кроме того, если для создания электронной подписи используется электронная подпись из ранее созданного электронного блока, то образуется связанная цепочка блоков, в которой сложно изменить содержание одного, не изменяя содержание других. Если независимых узлов в системе блокчейн 4 будет достаточное количество, то изменение практически невозможно.

В принципе, если при расчете хэш-кода будет использовано время отправки сообщения (time stamp line), то в блок системы 4 достаточно включать только хэш-код. Но для удобства сопоставления хэш-кода и соответствующего сообщения в системе 4 можно в блок включать и время отправки (например, кол-во секунд/миллисекунд от 01.01.1970). Очевидно, что хэш-коды при большом количестве сообщений будут повторятся. Но вероятность появление в системе блокчейн 4 двух одинаковых хэш-кодов в близкие моменты времени практически нулевая.

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

Если пользователю e-mail потребуется подтверждение отправки сообщения, то, зная алгоритм хэш-функции, он может самостоятельно получить хэш своего отправленного когда-то сообщения, написав собственную программу, или получить хэш-код, воспользовавшись соответствующим web-сервисом, представленным, например, инфраструктурой поддержки системы 4 и провайдером почтового сервера 1. Если сообщение во время отправки было зашифровано с помощью открытого ключа, то перед получением хэш-кода к содержимому сообщения применяется шифрование.

Информация система блокчейн 4 находится в публичном доступе для чтения (во всяком случае хэш-коды и ЭЦП). Наличие в системе 4 соответствующего хэш-кода, связанного со временем отправки сообщения (или явно в блоке с помощью пары хэш-код/время, или заданного пользователем на основании времени отправки сообщения, сохраненным в почтовом клиенте пользователя - time stamp line) подтверждает отправку электронного сообщения от конкретного отправителя, конкретному получателю в определенное время. Таким образом пользователь может предъявить наличие в системе блокчейн 4 хэш-кода, совпадающего с хэш-кодом конкретного письма, например, судебным экспертам.

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

Система блокчейн может быть построена на базе кода Ethereum или Bitcoin. А сервер 1 может быть реализован на базе открытого почтового сервера, например, Zimbra или iRedMail, к которому добавлены формирователь хэш-кода, например, на базе CityHash или алгоритмов на базе ГОСТ Р 34.11-2012, и интерфейс для работы с блокчейн платформой.

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

В другом варианте вместо блокчейн можно использовать базу данных, например, PostgreSQL или BigChainDB (на базе MongoDB). В этом случае почтовые сервера 1 или 3 или релей 5 записывают хэш-код в поле записи базы данных, которая создается до или после создания хэш-кода. В другом подварианте сервер 3 или релей 5 могут не создавать новую запись, а найти в базе данных запись с таким же хэш-кодом и близким временем отправления, созданную сервером 1. Кроме поля хэшкода запись (новая и старая) содержит поле ЭЦП (или два поля ЭЦП), идентификатор(-ы) одной или нескольких записей базы данных, созданных ранее, или же просто можно использовать ЭЦП предыдущей записи. Запись также может содержать поле времени передачи сообщения. Удобно также иметь поля для идентификаторов владельца цифровой подписи.

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

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

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

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

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

- принимают электронное сообщение;

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

- упомянутый хэш-код сохраняют в записи базы данных;

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

- передают упомянутое электронное сообщение на почтовый релей;

- с упомянутого почтового релея передают упомянутое электронное сообщение с помощью протокола SMTP;

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

- упомянутый второй хэш-код сохраняют в записи базы данных или проверяют наличие упомянутого второго хэш-кода в упомянутой базе данных;

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

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

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

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

5. Способ по п. 1, отличающийся тем, что упомянутая база данных является блокчейном.

6. Способ по п. 1, отличающийся тем, что упомянутая база данных является реляционной или объектной.

7. Способ по п. 1, отличающийся тем, что упомянутый хэш-код и упомянутая соответствующая ему электронная цифровая подпись находятся в публичном доступе для чтения.

8. Способ по п. 1, отличающийся тем, что упомянутый второй хэш-код и упомянутая соответствующая ему электронная цифровая подпись находятся в публичном доступе для чтения.