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

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

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

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

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

1 ответов


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

SignedAttributes в signerInfo Должен включать только один экземпляр атрибута Message-digest. Аналогично, AuthAttributes в AuthenticatedData должны включать только один экземпляр атрибута Message-digest.

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

и да, любая система безопасности так же сильна, как и ее самое слабое звено, поэтому теоретически вы ничего не получите, добавив 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.

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

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

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