Какова надежность шифрования s/mime на iOS?

Я настроил S/MIME на своем iPhone, но, в отличие от других почтовых клиентов, у меня нет возможности выбирать алгоритмы хеширования или шифрования. Я предполагаю, что iOS принимает это решение за меня.

Может ли кто-нибудь сказать мне, какие алгоритмы используются и каковы размеры ключей? Было бы неплохо узнать, что АНБ будет нелегко проникнуть в мои уведомления на Facebook. :D

Если Facebook предоставит АНБ доступ ко всей информации на стороне сервера, шифрование уведомлений станет гораздо менее срочным, не так ли? :-/
Поскольку у вас есть два ответа, касающиеся самого создания сертификата и того, как почтовый клиент iOS использует этот ключ (и мы вряд ли получим код, который Apple использует внутри компании , возможно, вы могли бы расширить «что дальше» или что вы собираетесь использовать это информацию, чтобы изменить то, что вы сделали. В основном, каково практическое применение ответа, который вы ожидаете? (чтобы он мог помочь кому-то дать ответ, который вы могли бы принять.)
Интересно, как настройка S/MIME на вашем iPhone заставит Facebook отправлять свои уведомления в зашифрованном виде? Я что-то пропустил?
@ not2savvy Это не заставит их отправить его в зашифрованном виде. Обычно есть вложение в форме, *.p7sесли вы получаете зашифрованное сообщение, где ваш клиент не настроен должным образом для его расшифровки.

Ответы (2)

SHA-1 скорее всего это. Вот что я нашел в поддержку этого утверждения:

В справочном документе по службам синтаксиса криптографических сообщений указано, что используется версия S/MIME 3.1 , которая определена здесь, и где указано, что она поддерживает SHA-1, SHA-256, SHA-384 и SHA-512, но :

Алгоритмы SHA-256, SHA-384 и SHA-512 [FIPS180-2] в настоящее время не рекомендуются для S/MIME и включены сюда для полноты картины.

Более того, в справочном документе по сертификатам, ключам и службам доверия (хотя это версия для Mac) указано, что по умолчанию используется алгоритм SHA-1 .

В другом документе сказано:

Наиболее распространенной хэш-функцией, которую вы будете использовать, является SHA-1 , алгоритм, разработанный и опубликованный правительством США, который создает 160-битное хэш-значение из любых данных длиной до 2**64 бит. Существует также ряд более экзотических алгоритмов, таких как SHA-2, алгоритмы на основе эллиптических кривых и так далее.

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

Итак, хотя мне не удалось найти прямого подтверждения использования алгоритма SHA-1, подсказки указывают на это.

Спасибо за это исследование. Это довольно полезно. У вас есть какое-то представление об алгоритмах шифрования - это то, что меня больше интересует в TBH.
@cottsak Все, что я смог найти, это то, что написано в первом документе, на который я дал ссылку:On CMS terminology, this module performs encryption using the **enveloped-data content** type and signing using the signed-data content type. If the message is both signed and encrypted, it uses **nested ContentInfo** types.

Для конкретного сообщения вы можете использовать openssl asn1parse, чтобы заглянуть внутрь.

Я отправил себе сообщение с помощью iOS Mail, подписанное и зашифрованное для меня, и с помощью командной строки

$ openssl smime -pk7out -in message.eml | openssl asn1parse

и содержимое результатов показало, что сообщение зашифровано с помощью 3DES EDE в режиме CBC:

  913:d=5  hl=2 l=   8 prim: OBJECT            :des-ede3-cbc

Поиск алгоритма подписи — еще одна проблема. Я думаю , что это SHA-1, но расшифрованное сообщение включает в себя множество подписей сертификатов, и я не уверен, что это за сообщение.

$ openssl smime -decrypt -in smime.eml -recip me.crt -inkey me.key | \
    openssl smime -pk7out | openssl asn1parse

   30:d=5  hl=2 l=   5 prim: OBJECT            :sha1

Хотя на самом деле вопрос касается симметричного и хэш-алгоритма, используемого для шифрования данных сообщения, параметры самого сертификата (который содержит открытый ключ, используемый для шифрования симметричного ключа, который, в свою очередь, используется для работы с данными) выбирается во время генерации ключа. Я видел это в действии при создании новой пары личных ключей в StartSSL ; веб-интерфейс запрашивает размер ключа RSA и алгоритм подписи, который я хочу использовать, а также предупреждение о том, что выбор SHA-1 оставит вас с сертификатом, несовместимым с некоторыми системами.

Что бы это ни стоило, мой личный сертификат использует 2048-битный RSA и алгоритм подписи SHA-1, который, как я обнаружил, хорошо работает в нескольких различных системах, включая OS X Mail.app, iOS Mail и Outlook 2007.

Это на самом деле не помогает мой вопрос. На самом деле я ищу доказательства внутренней реализации на устройствах iOS, таких как iPhone и iPad. Спасибо
Размер ключа определяется ЦС, а алгоритм шифрования определяется почтовым клиентом. forums.comodo.com/email-certificate/…
Я понимаю. @cottsak говорит о симметричных/хеш-алгоритмах, используемых для данных, а не об алгоритмах с открытым ключом/хэшем, используемых для ключа (см . en.wikipedia.org/wiki/Hybrid_cryptosystem ). Похоже, я нанес удар в темноте, не задав этого вопроса, и попал не в ту цель. Позвольте мне внести несколько уточняющих правок, так как я думаю, что это все еще ценная информация, хотя и несущественная.
Я еще немного посмотрел и в итоге разобрал сообщение, которое я отправил. Взгляните на последние изменения.
Это очень интересно ... так вы предлагаете, чтобы iOS выбирала алгоритм шифрования хэшей и сообщений в зависимости от того, что указано в сертификате подписи?
@cottsak Честно говоря, я не уверен; Я не копался так глубоко — я только просмотрел полученное сообщение и сообщил детали, чтобы вы тоже могли посмотреть. Хотя это может оказаться интересным: tools.ietf.org/html/rfc5751#section-2.5.2
Раздел 2.7.1 упомянутого RFC5751 ( Решение, какой метод шифрования использовать ) подробно описывает, как отправитель должен принять решение, принимая во внимание известные возможности получающего клиента (если они известны). Однако именно так отправитель ДОЛЖЕН себя вести, это НЕ ОБЯЗАТЕЛЬНО.