Шифрование / подпись электронной почты на лету - PullRequest
0 голосов
/ 08 октября 2009

Справочная информация: Я унаследовал встроенную систему на основе Linux, которая содержит SMTP-прокси и некоторые дурацкие ограничения, с которыми мне просто нужно жить. Он находится между SMTP-клиентом и сервером. Когда SMTP-клиент подключается, прокси-сервер открывает соединение с сервером и передает данные клиента на сервер после некоторой оперативной обработки.

Задача: Мне нужно подписать и / или зашифровать электронную почту на пути к серверу, используя стандартные методы PKI и форматы S / MIME (см., Например, RFC2311 ) , У меня есть доступ ко всем необходимым открытым ключам из соответствующих сертификатов.

Дурацкие ограничения (пожалуйста, просто примите их, так как они находятся вне моего контроля) :

  1. Я не могу сохранить электронную почту; должен обрабатываться на лету.
  2. Я могу выполнить шифрование локально, используя открытые ключи, но я не могу получить доступ к закрытым ключам напрямую, что означает, что цифровая подпись должна быть сделана "подписывающим устройством" через соединение 9600 бит / с.
  3. Типичные сообщения электронной почты имеют размер десятков или сотен МБ . (Сервер электронной почты и получатели могут обрабатывать эти размеры; единственная проблема - недопустимая задержка при подписании.)
  4. Любой новый код должен быть на C, но допустимо, например, передавать данные в отдельную утилиту для шифрования / подписи, если данные никогда не сохраняются ( например, нет временных файлов).
  5. Доставка в течение 14-21 дней.

Вопросы:

  1. Я надеялся найти утилиту с открытым исходным кодом или библиотеку, которая генерировала бы соответствующие заголовки MIME и зашифровывала / подписывала большой объем данных, но я не нашла этого в Sourceforge, коде Google, и т. Д. Вы использовали тот, который могли бы порекомендовать?
  2. Я отчаянно надеялся найти RFC, который говорит, что допустимо хешировать 100 МБ данных и затем подписывать хеш, поскольку это уменьшит узкое место 9600 бит / с. Но опять не повезло. Существует ли стандартный ярлык (RFC?), Который был бы совместим с типичными почтовыми клиентами?

Спасибо за ваши мысли.

1 Ответ

5 голосов
/ 08 октября 2009

Вопрос 1:

OpenSSL - это утилита и , которая может создавать и проверять сообщения S / MIME, включая заголовки MIME. См. справочную страницу smime (1) для использования версии утилиты - все это построено с использованием версии библиотеки, так что она может сделать это тоже.

Вопрос 2:

Это не только приемлемо, но и способ, которым подписи S ​​/ MIME всегда сделаны. Предположительно вы будете создавать подписанное сообщение, используя формат multipart / подписанный (см. Раздел 3.4.3 RFC2311 ). Этот составной MIME-тип содержит отдельную подпись как объект с MIME-типом application / pkcs7-signature. Раздел 3.4.3.1 говорит нам, что он содержит объект подписанного данных PKCS # 7. PKCS # 7 описан в RFC2315 , а объект signatureData описан в разделе 9. Этот раздел говорит нам, что мы создаем дайджест сообщения для подписываемого сообщения (S / MIME говорит, что реализации должны понимать по крайней мере, дайджесты сообщений MD5 и SHA1, поэтому вы должны использовать SHA1 в качестве интероперабельного варианта с максимальной безопасностью) и шифровать его с помощью личного ключа подписавшего.

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

Затем вы взяли бы составной / подписанный MIME-объект и зашифровали его в соответствии со спецификациями S / MIME, а затем снова подписали весь восковой шарик (режим Sign-Encrypt-Sign), чтобы в итоге вы получили:

  • multipart / подписанный объект, где первая часть:
  • объект application / pkcs7-mime, который при расшифровке следующим PKCS # 7 содержит:
  • еще один мультипликационный / подписанный объект, где первая часть:
  • объект MIME, представляющий исходное письмо (или просто тело; все, что вам нужно ...)

Добавление:

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...