Какой российский стандарт определяет алгоритм вычисления хеш-функции

FIPS 202 определяет новое семейство функций на основе перестановок SHA-3 на основе KECCAK в результате конкурса алгоритмов криптографического хэширования SHA-3. FIPS 202 определяет:

• Четыре алгоритма хеширования фиксированной длины: SHA3-224, SHA3-256, SHA3-384 и SHA3-512; и
• Две тесно связанные функции «расширяемого вывода» (XOF): SHAKE128 и SHAKE256.

В настоящее время только четыре алгоритма фиксированной длины SHA-3 являются одобренными хеш-алгоритмами и представляют собой альтернативу семейству хэш-функций SHA-2. XOF могут быть специализированы для хэш-функций с учетом дополнительных соображений безопасности. Руководство по использованию XOF будет предоставлено в будущем.

Производные функции SHA-3

Помимо четырех хеш-функций фиксированной длины, FIPS 202 также определяет две расширяемые функции вывода, SHAKE128 и SHAKE256. В отличие от хэш-функций фиксированной длины, эти функции SHAKE поддерживают выходные данные переменной длины и названы в соответствии с ожидаемым уровнем безопасности.

FIPS 202 также поддерживает гибкую схему разделения доменов между различными функциями, производными от KECCAK, гарантируя, что разные именованные функции будут давать несвязанные выходные данные. NIST еще больше расширяет эту гибкость, позволяя пользователям настраивать использование функций путем определения настраиваемой версии SHAKE, называемой cSHAKE.

Связанные специальные публикации

NIST SP 800-106, Рандомизированное хеширование цифровых подписей, содержит рекомендации по рандомизации входных хеш-сообщений перед созданием подписи для повышения безопасности создаваемых цифровых подписей.

NIST SP 800-107, редакция 1, Рекомендации по использованию утвержденных алгоритмов хэширования, содержит рекомендации по обеспечению безопасности для достижения требуемых или желаемых уровней безопасности при использовании криптографических приложений, использующих утвержденные хэш-функции. К ним относятся такие приложения, как цифровые подписи, коды аутентификации сообщений с хэшем (HMAC) и функции создания ключей на основе хэшей (KDF на основе хэшей).

Тестирование реализации хэш-функции

Требования к тестированию и списки проверки доступны в Программе проверки криптографических алгоритмов (CAVP).

В конце 2017 года я получил новые результаты [1] о S-блоке, используемом обоими российскими стандартами в симметричной криптографии, а именно блочным шифром (Кузнечик) и хеш-функцией (Стрибог). Это и стандарты ГОСТ, и RFC (соответственно RFC 6986 и RFC 7801). На этой странице я суммирую эти последние результаты, используя часто задаваемые вопросы.Я рекомендую заинтересованному читателю ознакомиться с настоящим исследовательским документом, который доступен онлайн (без платного доступа!) на веб-сайте ToSC.

1 Общий контекст

1.1 Что такое симметричная криптография?

Криптография — это наука, занимающаяся информационной безопасностью: как мы можем общаться таким образом, чтобы перехватчик не мог шпионить за нами? Поскольку связь осуществляется через компьютеры, методы, обеспечивающие такую ​​защиту, представляют собой алгоритмы, которые не позволяют злоумышленникам получить доступ к информации без использования ключа: если ключ не известен, невозможно прочитать/изменить данные. Когда для обработки информации перед отправкой и после получения используется один и тот же ключ, мы говорим о симметричной криптографии.

Необходимо постоянно анализировать эти алгоритмы, поскольку в конечном итоге они могут иметь недостатки. Эта угроза не является теоретической, так как в прошлом криптографические алгоритмы терпели неудачу. Возьмем недавний пример: было обнаружено, что хеш-функция SHA-1 приводит к коллизиям, что является критическим сбоем для такого алгоритма [4].

1.2 Как выбираются криптографические алгоритмы, которые мы используем?

Как правило, используются алгоритмы, стандартизированные каким-либо органом по стандартизации (например, американским NIST, ISO/IEC и т. д.). Каждый орган по стандартизации имеет собственный внутренний процесс выбора шифров.

Этот процесс может быть совершенно непрозрачным, о чем свидетельствует стандартизация DUAL_EC PRNG американским NIST. Оказалось, что этот алгоритм был навязан АНБ и, вероятно, содержит лазейку, как подробно описано в [8]. В данном случае алгоритм был стандартизирован в основном потому, что АНБ заявило, что так и должно быть. Это не уникальный случай: российские алгоритмы, обсуждаемые на этой странице, также были разработаны тайно, а затем стандартизированы без какой-либо конкуренции или других форм прозрачности. Очевидно, очень трудно доверять алгоритмам, стандартизированным таким образом: где анализ третьей стороны? Где пояснения дизайнеров?

Чтобы укрепить доверие, гораздо лучшая стратегия заключается в организации открытых конкурсов. Например, соревнования NIST по AES и хеш-функциям привели к стандартизации алгоритмов, которым сейчас доверяют. Это доверие основано на анализе, проведенном этими алгоритмами до того, как они были стандартизированы, и на качестве теоретических основ, использованных для их создания, основ, которые были тщательно объяснены их разработчиками.

Алгоритмы AES, SHA-3 и DUAL_EC были стандартизированы одним и тем же учреждением (NIST), что позволяет предположить, что оценить качество стандарта не так просто, как посмотреть на его происхождение.

1.3 Что такое Стрибог и Кузнечик?

Streebog – это криптографическая хэш-функция. Он был стандартизирован Российской Федерацией в 2012 году. Кузнечик – это блочный шифр, который был стандартизирован той же страной в 2015 году.

Оба предназначены для использования в России. На момент написания этой статьи их авторы также настаивают на стандартизации ISO/IEC.

1.4 Что такое S-Box?

Блочный шифр является одним из основных строительных блоков для создания симметричных алгоритмов. Например, AES, один из наиболее широко используемых и хорошо изученных симметричных криптографических алгоритмов, представляет собой блочный шифр. Как и Кузнечик. Также часто используется блочный шифр для создания хэш-функции с использованием блочного шифра: это случай SHA-2, очень распространенной хеш-функции, и Streebog.

Блочные шифры строятся путем итерации так называемой раундовой функции, целью которой является предоставление слабой версии свойств, которым должен соответствовать блочный шифр. При повторении этих раундов свойства их композиции усиливаются, и после достаточного количества раундов она обеспечивает эти свойства в полном объеме. Ключевым свойством является нелинейность. На практике это обычно обеспечивается небольшим компонентом, который называется S(substitution)-box. S-блок — это функция, работающая с достаточно небольшими входными данными, чтобы ее выходные данные можно было указать в таблице поиска. Затем циклическая функция содержит параллельное применение указанного S-блока ко всему состоянию.

Оба русских алгоритма используют один и тот же S-блок, π. Он указывается в таблице поиска (рис. 1).

Рисунок 1. Таблица поиска \(\pi\), как она представлена ​​в спецификации [3]. Эта функция отображает 0 в 252, 1 в 238, … и 255 в 182.

Криптографические свойства S-блока играют решающую роль в безопасности алгоритма, поскольку они являются единственным источником нелинейности. Они также находятся в центре аргументов в пользу безопасности, выдвигаемых разработчиками алгоритмов. Фактически, ожидается, что дизайнеры объяснят, как был разработан S-блок, который они использовали, и почему они выбрали структуру своего S-блока.Например, AES имеет S-блок, основанный на мультипликативной инверсии в конечном поле \(\mathrm(2^8)\). Этот выбор мотивирован тем фактом, что как линейность, так и дифференциальная однородность 1 этой перестановки являются самыми низкими из возможных.

1.5 Почему важно знать, как был создан S-блок?

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

Чтобы увидеть пример ограничений и компромиссов, которые естественным образом возникают при проектировании S-блока, вы можете просмотреть это электронное письмо, отправленное в список рассылки CFRG одним из разработчиков Белорусский стандарт, БелТ. Он объясняет, почему они решили выбрать S-блок на основе дискретного возведения в степень — выбор, в котором я лично не вижу ничего плохого.

2 Мой последний результат: структура TKlog числа π

2.1 Какова структура π?

Авторы Streebog и Kuznyechik практически не предоставили информации о своем процессе проектирования. Несколько криптографов пытались расспросить их о структуре их S-блока во время конференций. Обычный ответ был эквивалентен тому, что они были выбраны наугад из некоторого набора. Они также утверждают, что потеряли алгоритм генерации. Учитывая важность S-блока, эта потеря сама по себе должна вызывать беспокойство.

Вместе с моими соавторами Алексеем Удовенко и Алексом Бирюковым мы сначала идентифицировали две разные декомпозиции π, которые были опубликованы на двух рецензируемых площадках: на конференции EUROCRYPT'16 для первого [6] и на IACR Transactions on Symmetric Cryptology. для второго [7]. Однако ниже я буду в основном говорить о третьей декомпозиции, которая была опубликована 3 в более позднем издании IACR Transactions on Symmetric Cryptology [1]. Он основан на структуре, которую я назвал TKlog.

2.1.1 TKlog

TKlog, который я назвал в честь TK26 (Технический комитет 26, разработчики русских алгоритмов), представляет собой особое семейство перестановок, членом которого является \(\pi\). Они определяются путем составления дискретного логарифма (отображения конечных элементов поля в целые числа) со странной, но простой перестановкой, отображающей целые числа обратно в конечные элементы поля.

2.1.2 Как может быть несколько различных разложений в π?

В этом контексте декомпозиция — это просто алгоритм, который при вводе \(x\) возвращает \(\pi(x)\). Этот алгоритм априори не имеет причин быть уникальным. Например, функция \(x \mapsto 4x^2\), определенная над целыми числами, может быть записана как композиция \(x \mapsto x^2\) и \(x \mapsto 4x\) или как композиция из \(x \mapsto 2x\) и \(x \mapsto x^2\). В случае \(\pi\) это намного, намного, намного сложнее, но в основе своей ситуация та же: есть несколько способов вычисления, которые дают один и тот же результат.

2.1.3 Почему третий вариант будет "правильным"?

Хороший вопрос: если есть несколько способов вычисления этой функции, почему TKlog должен быть тем, который изначально был задуман его разработчиками?

Если бы кто-то выиграл в эту лотерею 66 раз подряд, вы бы пришли к выводу, что ему невероятно повезло или что при выборе «случайных» чисел были замешаны какие-то махинации? Последнее является естественным выводом. Используя те же рассуждения, я утверждаю, что присутствие этой структуры в \(\pi\) является преднамеренным.

2.1.4 Разве это не согласуется с их утверждениями?

Одним из заявлений разработчиков этих алгоритмов является то, что они выбрали свой S-блок случайным образом из некоторого набора S-блоков. Если бы они выбрали параметры TKlog случайным образом, не соответствовал бы ли их дизайн технически этому описанию?

На мой взгляд, нет.

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

Кроме того, авторы Streebog утверждали в неофициальных обсуждениях (см. резюме в [9]), что они хотели избежать слишком строгой алгебраической структуры, чтобы предотвратить некоторые атаки. Хотя априори в этом подходе нет ничего плохого, он полностью противоречит их конечному результату: как показано в следующем разделе, их S-блок имеет чрезвычайно сильную алгебраическую структуру.

2.2 Какими особыми свойствами он обладает?

Любая функция, работающая с \(n\) битами, может быть записана как функция над конечным полем \(\mathbb_\). Точное соответствие между конечными элементами поля и их бинарным представлением неоднозначно; она определяется конкретным полиномом. В случае \(\pi\) это поле \(\mathbb_\). Он содержит в качестве подмножества конечное поле \(\mathbb_\). Поскольку эти наборы являются полями, мы можем определить сложение (которое здесь соответствует XOR, обозначенному "\(\oplus\)") и умножение на 6 (обозначенное "\(\odot\)").

S-блок \(\pi\) (как и все журналы TKlog) отображает подмножество \(\< a \odot x, x \in \mathbb_^* \>\) из \(\mathbb_\) в подмножество вида \(\< b \oplus x, x \in \mathbb_^* \>\). Это явление показано на рис. 3. Это означает, что \(\pi\) сопоставляет простой раздел своих входных данных с простым разделом своих выходных данных.

Хуже того, все \(x \in \mathbb_\) можно записать 7 как \(a \odot b\) с \(b \in \mathbb_\), и тогда мы получим, что если \(a \neq 1\), то \(\pi(a \odot b) = f(a) \oplus g(b)\) для некоторых функций \(f\) и \(g\). Другими словами, вывод можно разделить на две половины, каждая из которых зависит только от одной половины ввода. Однако во входных данных определение этих половинок не является линейным. Как другое следствие, способ \(\pi\) действует на каждое подмножество \(\< a \odot x, x \in \mathbb_^* \>\) множества \(\mathbb_\) для \(a \neq 1\) всегда одинакова. Также обратите внимание, что \(g\) является перестановкой \(\mathbb_\), что означает, что его вывод также находится в этом подмножестве.

Рисунок 3. Основное свойство \(\pi\): он сопоставляет простой раздел своих входных данных с простым разделом своих выходных данных.

2.3 Почему это беспокоит?

Во-первых, это очень сильная алгебраическая структура, тогда как раньше утверждалось, что ее нет.

Во-вторых, Арно Баннье в своей докторской диссертации [10] установил, что для построения блочного шифра с лазейкой определенного типа необходимо построить наборы отображений S-блоков вида \(\< b \oplus x, x \in V \>\) к видам \(\< b \oplus x, x \in W \>\), где \(V\) и \(W\) - векторные подпространства \(\mathbb_\) (например, \(\mathbb_\) является векторным подпространством \(\mathbb_\)).

Это не совсем та ситуация, которую мы имеем здесь, поскольку \(\pi\) имеет такой раздел на выходе, но не на входе. Однако в случае Streebog линейный слой странным образом взаимодействует (что нам еще предстоит полностью понять) с наборами обеих форм, т.е. \(\< b \oplus x, x \in \mathbb_ \>\) и \(\< b \odot x, x \in \mathbb_ \>\).

Кстати, этот линейный слой изначально был задан как двоичная матрица \(64 \times 64\), т.е. с использованием только 0 и 1, а просто описывается матрицей \(8 \times 8\) с элементы в \(\mathbb_\). Странно, что эта структура не была раскрыта разработчиками, особенно если учесть, что это естественный выбор: такие матрицы, определенные над \(\mathbb_\), распространены в симметричной криптографии; сам AES использует один. Зачем тогда держать это в секрете?

Кстати, процесс проектирования этой матрицы также неизвестен. Обратный инжиниринг — открытая проблема!

2.4 Итак… это бэкдор?

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

Тем не менее, я не знаю ответа на поставленный выше вопрос и, говоря прямо, не думаю, что нам это нужно знать. Я думаю, что важно, может ли эта структура привести к атакам на эти алгоритмы. Как объяснялось в ответе на предыдущий вопрос, это возможно. Если это действительно уязвимость, которую можно использовать, то почему и как она оказалась в этих шифрах, это проблема их разработчиков, а не пользователей. Насколько нам известно, процесс генерации их S-блока мог быть скомпрометирован кем-то другим, что подчеркивает основную проблему, стоящую за этими алгоритмами: хотя я восстановил структуру, которая использовалась для создания этого компонента…

… мы даже не знаем наверняка, кто это разработал или с какой целью они это сделали!

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

3 обновления

22 мая 2019 г. С момента публикации [1] разработчики π настаивали на том, что наличие TKlog было простым совпадением. Их аргументы фактически неверны. Документ, подтверждающий это, [11], и я написал вульгарное объяснение на этой странице. 19 февраля 2020 г. Я встретился с предполагаемым разработчиком этого S-блока во время встречи ISO в Париже в октябре 2019 г. Он подтвердил свое заявление о случайности и настаивал на том, что, к сожалению, потерял программу, генерирующую S-блок. -коробка. Делайте из этого что хотите.

Кроме того, я обновил форму этой заметки (в основном CSS).

4 благодарности

Я благодарю Ксавьера Боннетена за корректуру первых черновиков этой страницы. Я также очень благодарен Марку Сейдену за его подробные комментарии.

5 Библиография

Сноски:

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

На самом деле указанный набор S-блоков был добавлен в SAGE Фридрихом Вимером, см. документацию соответствующего модуля.

И который был выбран комитетом конференции лучшим докладом!

В то время как cstt можно выбирать свободно, два других нельзя: s должен быть перестановкой \(\< 0, . 14 \>\), а lambda_vectors должен быть выбран таким образом, чтобы он охватывал векторное пространство измерение 4, которое вместе с подполем охватывает все поле.

Называемая «Лото», она выиграна, если правильно выбраны 5 различных чисел в \(\< 1,49 \>\) и одно в \(\< 1,10 \>\), событие с вероятностью из \(\left( \times 10 \right)^ \приблизительно 2^\).

Определение умножения в конечном поле сильно отличается от умножения на целые числа. Однако он обладает теми же свойствами: \(a \odot 1 = a\), \(a \odot 0 = 0\), \(a \odot (b \odot c) = (a \odot b) \odot c\), и можно определить мультипликативную инверсию так, что \(a \odot (a^) = 1\).

Я неявно использую разложение unique на \(a \odot b\), где \(b \in \mathbb_\) и \(a = \alpha^\) для некоторого \( я \leq 15\).

Алгоритмы безопасного хэширования (SHA) используются для вычисления сжатого представления электронных данных (сообщений). Когда сообщение любой длины менее 264 бит (для SHA-224 и SHA-256) или менее 2128 бит (для SHA-384, SHA-512, SHA-512/224 и SHA-512/256) вводится в хэш-алгоритм, результатом является вывод, называемый дайджестом сообщения. Общие названия для вывода хеш-функции включают также хеш-значение, хэш и цифровой отпечаток. Хэш-функции SHA-3 могут быть реализованы как альтернатива функциям SHA-2 или наоборот.

Хотя длина входного сообщения может варьироваться, длина дайджеста является фиксированной. Дайджесты сообщений имеют длину от 160 до 512 бит, в зависимости от алгоритма. Таблица 1, адаптированная из NIST FIPS 180-4, ниже изображает основные свойства алгоритмов хеширования.

Таблица 1. Основные свойства алгоритма хеширования

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

В соответствии со стандартом FIPS 180-4 алгоритмы хеширования называются безопасными, потому что для данного алгоритма вычислительно невозможно (1) найти сообщение, соответствующее данному дайджесту сообщения, или (2) найти два разных сообщения, которые производят один и тот же дайджест сообщения. Эти алгоритмы позволяют определять целостность сообщения: любое изменение в сообщении с очень высокой вероятностью приведет к созданию другого дайджеста сообщения. Это приведет к сбою проверки, если алгоритм безопасного хеширования используется с алгоритмом цифровой подписи или алгоритмом аутентификации сообщений с помощью хеш-ключей.

Использование функций хеширования

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

Коды аутентификации сообщений (MAC) могут использоваться для аутентификации источника и целостности. MAC представляет собой криптографическую контрольную сумму данных, которая используется для гарантии того, что данные не изменились и что MAC был рассчитан ожидаемым объектом. FIPS 198 определяет вычисление MAC с использованием утвержденной хеш-функции. Для кодов аутентификации хеш-сообщений (HMAC) разрешены ключи различных размеров, а выбор размера ключа зависит от уровня безопасности, который должен быть обеспечен для данных, и используемой хэш-функции.

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

Надежность функций хеширования

Алгоритмы наиболее существенно различаются по степени защиты хэшируемых данных. Уровень безопасности определяется в NIST SP 800-57 Pt1 Rev 4 как «объем работы (то есть количество операций), который требуется для взлома криптографического алгоритма или системы». Чтобы определить подходящие хэш-функции, которые могут использоваться в приложении, необходимо учитывать индекс минимальной надежности безопасности наряду с алгоритмом, схемой или приложением, в котором используется хеш-функция. В таблице ниже, адаптированной из NIST SP 800-57 Pt 1 Rev 4, перечислены утвержденные хеш-функции, которые можно использовать для обеспечения определенной степени безопасности для различных приложений хеш-функций.

Очень важно отметить, что SHA-1 упоминается только в устаревших целях, поскольку NIST объявил его устаревшим в мае 2011 года из-за известных коллизий. Кроме того, все основные поставщики браузеров и программного обеспечения, такие как Microsoft, Mozilla и Google, уже отказались от использования систем хеширования SHA-1.

Уязвимости хэш-функции

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

Атака с помощью хэш-функции — это попытка найти две входные строки хеш-функции, дающие одинаковый результат хэширования. Коллизия возникает, когда два разных фрагмента данных — документ, двоичный файл или сертификат веб-сайта — хэшируются в один и тот же дайджест, как показано выше. На практике коллизии никогда не должны возникать для безопасных хеш-функций. Однако, если алгоритм хеширования имеет некоторые недостатки, как SHA-1, хорошо финансируемый злоумышленник может создать коллизию. Злоумышленник может затем использовать это столкновение, чтобы обмануть системы, которые полагаются на хэши, чтобы они приняли вредоносный файл вместо его доброкачественного аналога. Например, два договора страхования с кардинально разными условиями.

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

В четверг, 23 февраля, компания Google объявила, что группа исследователей из Института CWI в Амстердаме и Google успешно продемонстрировала атаку на хеш-алгоритм SHA-1, создав два файла с одинаковыми хеш-значениями. Работа команды CWI – Google является кульминацией более чем десятилетнего исследования алгоритма SHA-1, начиная с новаторской статьи Сяоюня Вана, Ицюня Лизы Инь и Хунбо Ю в 2005 году, в которой описывались первые криптоаналитические методы, способные поиск столкновений с гораздо меньшей работой, чем грубая сила. Криптографы по всему миру продолжали совершенствовать эти методы. Методы, использованные в этой атаке, были разработаны Марком Стивенсом, одним из членов совместной команды CWI и Google. Исследовательская группа разместила дополнительную информацию на Shattered.io.

Как вышеизложенное переводится в атаку? Если «плохой» файл представляет собой вредоносное ПО или поддельный документ, например сертификат, предназначенный для гарантии подлинности веб-сайта, злоумышленник может доверить свое вредоносное ПО или поддельный веб-сайт любой системе, которая проверяет хэши SHA-1 для проверки.Другой вариант использования может быть, если вы используете белый список приложений на своем компьютере, который использует хэши для проверки того, что файлы являются теми, за кого себя выдают. Файл вредоносного ПО может иметь тот же хэш, что и законный файл или какое-либо доверенное приложение, и может быть включен в белый список, предоставляя привилегии на вашем компьютере.

Согласно команде, которая на самом деле взломала SHA-1, любое приложение, использующее SHA-1 для цифровых подписей, целостности файлов или идентификации файлов, потенциально уязвимо. К ним относятся подписи цифровых сертификатов, подписи электронной почты PGP/GPG, подписи поставщиков программного обеспечения, обновления программного обеспечения, контрольные суммы ISO, системы резервного копирования и т. д.

Сертификаты TLS/SSL не подвергаются риску, поскольку любой центр сертификации, соблюдающий правила CA/Browser Forum, больше не может выдавать сертификаты SHA-1. Кроме того, все основные поставщики технологий, такие как Microsoft, Google и Mozilla, также отказались от SHA-1 и предоставили своим пользователям дорожные карты для перехода на хэш-функции SHA-2. Наконец, чтобы гарантировать, что у практиков есть безопасные и эффективные алгоритмы хеширования для обеспечения долгосрочной безопасности, NIST выбрал новый стандарт алгоритма хеширования, SHA-3, который указан в FIPS 202 .

Джон Киндерваг из Forrester о том, почему мы должны защищать данные с помощью шифрования.

Похожие сообщения

Нравится этот блог? Мы думаем, вам это понравится.

Миллионы Android-телефонов Samsung поставляются с дефектом шифрования [отчет]

Samsung не удалось внедрить Keym

Подпишитесь на наши еженедельные обновления блога!

Присоединяйтесь к тысячам других специалистов по безопасности

Получайте лучшие блоги на почту каждую неделю

Спасибо за подписку

Посмотреть популярные теги

Вам также может понравиться

электронная книга

Управление идентификацией машин TLS для чайников

Белая книга

Исследование CIO: сбои, связанные с сертификатами, продолжают досаждать организациям

Об авторе

Приглашенный блогер: Анастасиос Арампацис

Анастасиос Арампацис — отставной офицер ВВС Греции с более чем 20-летним опытом оценки кибербезопасности и управления ИТ-проектами. Он работает инструктором по информатике в Образовательном институте AKMI, а его интересы включают изучение человеческой стороны кибербезопасности.

Твиты

Ресурсы

Lorem ipsum dolor sit amet, consectetur adipiscing elit sit amet diam.

Lorem ipsum dolor sit amet, consectetur elit.

Спасибо за подписку

ПРОДУКТЫ

РЕШЕНИЯ

РЕСУРСЫ

ЭКОСИСТЕМА

КОМПАНИЯ

Авторское право © Venafi, Inc., 2022. Все права защищены.

Зарегистрируйтесь в Venafi Cloud

Venafi Cloud управляет сертификатами и защищает их

У вас уже есть аккаунт? Войдите здесь

Лицензионное соглашение с конечным пользователем

Прокрутите вниз, чтобы принять

ОБЛАЧНАЯ СЛУЖБА VENAFI

ПОЖАЛУЙСТА, ВНИМАТЕЛЬНО ПРОЧТИТЕ ПЕРЕД ПРОДОЛЖЕНИЕМ РЕГИСТРАЦИИ И/ИЛИ АКТИВАЦИИ ОБЛАЧНОЙ СЛУЖБЫ VENAFI («СЛУЖБА»).

Это юридическое соглашение между конечным пользователем («Вы») и Venafi, Inc. («Venafi» или «наш»). ПРИНИМАЯ НАСТОЯЩЕЕ СОГЛАШЕНИЕ, НАЖИМАЯ НА ЯЩИК, УКАЗЫВАЮЩИЙ ВАШЕ ПРИНЯТИЕ, И/ИЛИ АКТИВИРУЯ И ИСПОЛЬЗУЯ ОБЛАЧНУЮ СЛУЖБУ VENAFI, ДЛЯ КОТОРОЙ ВЫ ЗАРЕГИСТРИРОВАЛИСЬ, ВЫ СОГЛАШАЕТЕСЬ С УСЛОВИЯМИ НАСТОЯЩЕГО СОГЛАШЕНИЯ. ЕСЛИ ВЫ ЗАКЛЮЧАЕТЕ НАСТОЯЩЕЕ СОГЛАШЕНИЕ ОТ ИМЕНИ КОМПАНИИ ИЛИ ДРУГОГО ЮРИДИЧЕСКОГО ЛИЦА, ВЫ ЗАЯВЛЯЕТЕ, ЧТО ИМЕЕТЕ ПОЛНОМОЧИЯ ОБЯЗАТЬ ТАКОЕ ЛИЦО И ЕГО АФФИЛИРОВАННЫЕ ЛИЦА СОБЛЮДАТЬ НАСТОЯЩИЕ УСЛОВИЯ, В ЭТОМ СЛУЧАЕ ТЕРМИНЫ «ВЫ» ИЛИ «ВАШИ» СООБЩАЙТЕСЬ О ТАКОЙ КОМПАНИИ И ЕЕ АФФИЛИРОВАННЫХ ЛИЦАХ.ЕСЛИ У ВАС НЕТ ТАКИХ ПОЛНОМОЧИЙ ИЛИ ЕСЛИ ВЫ НЕ СОГЛАСНЫ С ЭТИМИ УСЛОВИЯМИ И ПОЛОЖЕНИЯМИ, ВЫ ДОЛЖНЫ НЕ ПРИНИМАТЬ ЭТО СОГЛАШЕНИЕ И НЕ МОЖЕТЕ ПОЛЬЗОВАТЬСЯ СЛУЖБОЙ.

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

Последний раз настоящее Соглашение обновлялось 12 апреля 2017 г. Оно вступает в силу между вами и Venafi с даты принятия вами настоящего Соглашения.

Облачная служба Venafi включает в себя две отдельные службы, которыми Venafi управляет как программное обеспечение как услуга, каждая из которых лицензируется отдельно в соответствии с положениями и условиями настоящего Соглашения и считается Службой в соответствии с настоящим Соглашением: Служба оценки облачных рисков Venafi или служба Venafi Cloud for DevOps. Ваше право на использование любого из Сервисов зависит от Сервиса, для использования которого вы зарегистрировались в Venafi.

Настоящая Лицензия действует до тех пор, пока не будет прекращена, как указано в настоящем документе, или пока не истечет Срок действия Лицензии, и не будет продлена сторонами иным образом. Venafi может прекратить действие настоящего Соглашения и/или Лицензии в любое время с письменным уведомлением Вас или без такового, если Вы не соблюдаете какое-либо положение или условие настоящего Соглашения или если Venafi прекращает предоставлять Услуги конечным пользователям. Вы можете расторгнуть настоящее Соглашение в любое время, направив Venafi письменное уведомление. После любого расторжения или истечения срока действия настоящего Соглашения или Лицензии Вы соглашаетесь прекратить любое использование Сервиса, если Лицензия не будет продлена или восстановлена ​​иным образом. После расторжения Venafi также может реализовать любые права, предусмотренные законом. Положения настоящего Соглашения, защищающие права собственности Venafi, остаются в силе после расторжения.

1. Нарушение законов . Вы не должны преднамеренно предпринимать какие-либо действия или бездействовать, если разумно предсказуемый результат может привести к нарушению Venafi любого применимого закона, правила, постановления или политики и, в той степени, в которой это не противоречит, любого другого применимого закона, правила, регулирование и политика.

Настоящее Соглашение регулируется законами штата Юта, и любой арбитраж по нему должен применяться, за исключением (а) его принципов коллизионного права; (b) Конвенция Организации Объединенных Наций о договорах международной купли-продажи товаров; (c) Конвенция 1974 года об исковой давности в международной купле-продаже товаров; и (d) Протокол о внесении поправок в Конвенцию 1974 г., совершенный в Вене 11 апреля 1980 г.

1. Настоящее Соглашение является обязательным для вас, а также для ваших сотрудников, работодателей, подрядчиков и агентов, а также для любых разрешенных правопреемников и правопреемников. Если иное не заменено в письменной форме отдельно оформленным соглашением, настоящее Соглашение представляет собой полное соглашение между Вами и Venafi в отношении Лицензии, предоставленной по настоящему Соглашению, и Вы соглашаетесь с тем, что Venafi не будет нести никакой ответственности за любое заявление или представление, сделанное ею, ее агентами или кем-либо еще (невинно или по небрежности), на которых Вы полагались при заключении настоящего Соглашения, за исключением случаев, когда такое заявление или представление было сделано обманным путем. Настоящее Соглашение заменяет любые другие договоренности или соглашения, включая, помимо прочего, рекламу в отношении Сервиса. Если какое-либо положение настоящего Соглашения будет признано недействительным или не имеющим исковой силы какой-либо страной или государственным органом, обладающим юрисдикцией, это конкретное положение будет считаться измененным в той мере, в какой это необходимо, чтобы сделать его действительным и подлежащим исполнению, а остальные положения останутся в полной силе и действии. Если такое изменение окажется нецелесообразным или будет отклонено, после этого вы и Venafi имеете право расторгнуть настоящее Соглашение с немедленным уведомлением.
2. Выживание. Стороны соглашаются с тем, что права и обязанности, изложенные в вышеупомянутых Разделах 1 (Определения), 3 (Собственность), 4 (Отказ от гарантий), 5 (Ограничение ответственности), 6 (Срок действия и прекращение), 7 (Соблюдение с Законами), 8 (Применимое законодательство) и 9 (Общие положения) остаются в силе после расторжения настоящего Соглашения по любой причине, и его принудительное исполнение не зависит от каких-либо отлагательных условий.
3. Назначение . Настоящее Соглашение имеет обязательную силу и действует в интересах соответствующих правопреемников и разрешенных правопреемников сторон. Вы не имеете права переуступать настоящее Соглашение или какие-либо свои права или обязанности по настоящему Соглашению без предварительного письменного согласия Venafi, и любая такая попытка переуступки будет считаться недействительной.

По вопросам, касающимся настоящего Соглашения, обращайтесь к Venafi по адресу 175 E. 400 South, Suite 300, Salt Lake City, Utah 84111 USA.

Читайте также:

  
• Команды брачных ботов в разногласиях
  
• Где хранится резервная копия iphone на компьютере
  
• Как перевесить дверцу холодильника beko с дисплеем
  
• Как архивируются файлы в файловом менеджере Total Commander
  
• Для чего нужен ноутбук?