PKCS # 7 SignedData и алгоритмы множественного дайджеста

Question

Я изучаю возможность обновления приложения с SHA1 в качестве алгоритма дайджеста SignedData PKCS # 7 по умолчанию до более сильных дайджестов, таких как SHA256, способами, обеспечивающими обратную совместимость для верификаторов сигнатур, которые не поддерживают алгоритмы дайджеста, кроме SHA1. Я хочу проверить мое понимание формата PKCS # 7 и доступных опций.

То, что я хочу сделать, это переварить содержимое сообщений как с SHA1, так и с SHA256 (или, в более общем смысле, с набором алгоритмов дайджеста), чтобы старые приложения могли продолжать проверку с помощью SHA1, а обновленные приложения могли начать проверку с помощью SHA256. (в общем, самый сильный дайджест), игнорируя более слабый алгоритм (ы). [Если есть лучший подход, пожалуйста, дайте мне знать.]

Похоже, что в рамках стандарта PKCS # 7 единственным способом предоставления нескольких дайджестов является предоставление нескольких SignerInfos, по одному для каждого алгоритма дайджеста. К сожалению, это может привести к чистому снижению безопасности, поскольку злоумышленник может лишить всех, кроме SignerInfo, самым слабым алгоритмом дайджеста, который сам по себе все еще будет формировать действительную подпись. Это понимание правильно?

Если это так, моя идея заключалась в том, чтобы использовать пользовательские атрибуты в поле authenticatedAttributes в SignerInfo, чтобы предоставить дополнительные дайджесты сообщений для дополнительных алгоритмов дайджеста (оставив SHA1 в качестве алгоритма «по умолчанию» для обратной совместимости). Поскольку это поле аутентифицируется как один блок, это предотвратит вышеуказанную атаку. Похоже ли это на жизнеспособный подход? Есть ли способ сделать это или нечто подобное, не выходя за рамки стандарта PKCS?

Answer 1

Да, вы правы, в текущем CMS RFC говорится об атрибуте дайджеста сообщения, который

Подписанные атрибуты в подписавшей информации ДОЛЖЕН включать только один экземпляр атрибута дайджеста сообщения. Аналогично, атрибуты AuthAttributes в AuthenticatedData ДОЛЖНЫ включать только один экземпляр атрибута дайджеста сообщения.

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

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

Вашу схему с пользовательскими атрибутами немного сложнее сломать, но все еще существует хэш SHA-1, который можно атаковать. Это уже не так просто, как просто удалить атрибут - как это покрыто подписью. Но:

Существует также алгоритм дайджеста, который используется для дайджеста подписанных атрибутов, который служит основой для окончательного значения подписи. Что вы собираетесь использовать там? SHA-256 или SHA-1? Если это SHA-1, то вы будете в той же ситуации, что и раньше:

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

В вашей ситуации я бы рекомендовал продолжать использовать SHA-1, но применять к вашей подписи метку времени, соответствующую RFC 3161 , как неподписанный атрибут. Эти метки времени на самом деле являются собственными подписями. Хорошо, что вы можете использовать SHA-256 для импринтинга сообщения, и часто сервер меток времени применяет свою подпись, используя тот же алгоритм дайджеста, который вы указали. Затем отклоните любую подпись, которая либо не содержит такой отметки времени, либо содержит только отметки времени с алгоритмами вывода / дайджеста подписи, более слабыми, чем SHA-256.

В чем преимущество этого решения? Ваши унаследованные приложения должны проверять наличие неподписанного атрибута метки времени и наличие для него сильного дайджеста, но в противном случае игнорируйте их и продолжайте проверять подписи так же, как и раньше. С другой стороны, новые приложения будут проверять подпись, но также дополнительно проверять метку времени. Поскольку подпись отметки времени «покрывает» значение подписи, у злоумышленника больше нет возможности подделать подпись. Хотя подпись использует SHA-1 для значений дайджеста, злоумышленник должен иметь возможность разбить более сильный дайджест отметки времени.

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

Последнее преимущество временных меток заключается в том, что вы можете обновлять их с течением времени, если некоторые алгоритмы становятся слабыми.Например, вы можете применять новую временную метку каждые 5-10 лет с использованием современных алгоритмов и иметь новые временные метки, охватывающие все более старые подписи (включая более старые временные метки).Таким образом, слабые алгоритмы затем покрываются более новой, более сильной сигнатурой времени.Взгляните на CAdES (существует также RFC , но он уже устарел), который основан на CMS и пытается применить эти стратегии для обеспечения долгосрочной перспективы.архивация подписей CMS.