Инструменты разработчика · SHA хеш-калькулятор
Совпадающая контрольная сумма не является подписью: целостность против подлинности
· Почему это важно
ша-256 криптография безопасность
Опубликованный SHA-256 позволяет пользователям обнаружить поврежденную загрузку, но если злоумышленник контролирует страницу, он также контролирует контрольную сумму. Этот пост отделяет целостность от подлинности и объясняет, что добавляют подписи.
Контрольная сумма на той же странице, что и загрузка — почему она защищает от повреждения, но не от взлома хоста
Выпуск программного обеспечения публикуется с контрольной суммой SHA-256 на той же странице, что и загрузка. Пользователи могут получить архив, хешировать его и сравнить результат с опубликованным значением. Если они совпадают, загрузка не повреждена. Это проверка целостности, и это реальная и полезная проверка. Однако если злоумышленник скомпрометирует веб-сервер, на котором размещен выпуск, он сможет заменить двоичный файл, пересчитать его SHA-256 и обновить контрольную сумму на странице. Пользователь проверяет контрольную сумму, и вредоносное ПО злоумышленника исходит от издателя. Система работала именно так, как задумано, но не смогла ответить на вопрос, который, по мнению пользователя, он задавал.
Это не является сбоем самой контрольной суммы. Это правильное замечание о том, что делает и чего не делает контрольная сумма. Контрольная сумма доказывает, что две копии данных идентичны. Это не доказывает, кто создал данные. В этом заключается различие между целостностью и подлинностью, и их объединение является одной из наиболее распространенных ошибок безопасности при проверке выпуска. Многие системы ломаются не потому, что их контрольные суммы неверны, а потому, что пользователи доверяют им отвечать на вопросы, на которые они не могут ответить.
Что доказывает хеш — что два входных данных — это одни и те же байты, и ничего о том, кто их создал.
Целостность — это свойство самих данных. Если у вас есть файл и его SHA-256, и файл не был изменен, хэш совпадает. Хэш доказывает, что каждый байт не изменился с момента его вычисления. Если файл был поврежден из-за ошибки передачи, сбоя диска или перевернутого бита сетевого кабеля, хэш не будет совпадать. Именно с этим хорошо справляются контрольные суммы. Они превосходно выявляют несчастные случаи и случайные повреждения. Они терпят неудачу против противника, который также может вычислять хэши.
Подлинность — это свойство утверждения о том, кто создал данные. Вопрос «получил ли этот файл издатель, которому я доверяю?» принципиально отличается от вопроса «был ли этот файл изменен?» Хэш сам по себе не может ответить на вопрос аутентичности, поскольку любой может вычислить хеш. Злоумышленник, изменяющий файл, может вычислить новый хэш и опубликовать его так же легко, как это сделал бы законный издатель. Хеширование симметрично; и защитник, и нападающий обладают одинаковыми вычислительными способностями.
Требование доверенного канала: почему контрольная сумма заслуживает доверия только в том месте, где вы ее получили
Требование доверенного канала является ключевым моментом. Контрольная сумма заслуживает доверия настолько, насколько надежен канал, по которому она пришла. Если вы загрузите двоичный файл программного обеспечения с официального сайта издателя CDN и загрузите контрольную сумму с того же сервера, они пройдут один и тот же путь. Компрометация сервера означает, что злоумышленник контролирует оба. Контрольная сумма обеспечивает защиту от повреждения во время доставки (поврежденный файл не будет соответствовать), но не от злоумышленника, контролирующего источник. Контрольная сумма и файл имеют одну точку отказа.
Если контрольная сумма была опубликована отдельно, на другом сервере, с другим контролем доступа, то это обеспечивает большую защиту. Злоумышленнику, который скомпрометирует основной сайт, придется скомпрометировать оба места, чтобы подделать совпадающую пару. Это лучше, но все равно полагается на то, что две независимые контрольные точки остаются в безопасности. Злоумышленнику теперь придется взломать две системы вместо одной, что увеличивает стоимость атаки. Но это еще не доказательство подлинности; это просто более дорогая атака.
Подписи связывают хеш с личностью — как подписание дайджеста закрытым ключом повышает подлинность
Цифровая подпись решает эту проблему, привязывая данные к личности с помощью криптографии. Издатель генерирует пару ключей: закрытый ключ, который он хранит в секрете, и открытый ключ, который он публикует. Они подписывают файл, вычисляя дайджест, а затем шифруя этот дайджест своим закрытым ключом. Результатом является подпись. Пользователь проверяет подпись, расшифровывая ее с помощью открытого ключа издателя и проверяя, соответствует ли результат вычисленному дайджесту полученного файла. Криптография создает асимметрию, которую не может достичь контрольная сумма.
Если это сработает, будут доказаны две вещи: данные соответствуют дайджесту, подписанному издателем, а закрытый ключ, использованный для подписи, соответствует опубликованному открытому ключу. Это доказывает, что его создал издатель, а не только злоумышленник. Открытый ключ должен пройти по защищенному каналу — обычно это сертификат доверенного центра сертификации, — но как только у вас появится открытый ключ, вы сможете проверять подписи от этого издателя в течение неопределенного времени. Теперь атака требует кражи закрытого ключа, что гораздо сложнее, чем взломать веб-сервер.
Рабочий пример — три сценария угроз (поврежденное зеркало, скомпрометированная страница, вредоносный инсайдер) и какая контрольная сумма и подпись каждого из них ловятся.
Три сценария угроз иллюстрируют разницу. Сценарий первый: зеркало загрузки повреждено случайной ошибкой. Контрольная сумма улавливает это; подпись улавливает это. Оба работают одинаково хорошо, поскольку ни одному из них не нужно побеждать злоумышленника. Сценарий второй: зеркало взломано злоумышленником, который подменяет файл и контрольную сумму. Контрольная сумма не защищает; подпись по-прежнему работает, поскольку у злоумышленника нет закрытого ключа, и он не может подделать действительную подпись. Злоумышленник может опубликовать что угодно, но подпись доказывает, что оно не принадлежит издателю.
Сценарий третий: CDN скомпрометирован, но подпись была опубликована через другой канал. Контрольной сумме CDN нельзя доверять, но проверка подписи по-прежнему работает, поскольку проверка целостности криптографически привязана к ключу издателя, а не к каналу. Теперь злоумышленнику необходимо подделать подпись, для которой требуется закрытый ключ. Подпись — единственная проверка, которая выдерживает компрометацию сервера. Вот почему для обеспечения подлинности необходимы подписи; они являются единственным инструментом, который подтверждает личность, несмотря на компрометацию канала.
Роль TLS и ее ограничения — транспортная безопасность защищает загрузку в процессе, а не на сервере издателя.
Транспортная безопасность защищает соединение с хостом, указанным в сертификате. Это может помешать наблюдателю на пути подменять байты загрузки, но не может сделать скомпрометированный источник издателя честным. Если этот источник обслуживает измененный архив и свежевычисленную контрольную сумму по действительному TLS, оба они доставляются неповрежденными и по-прежнему описывают контент, контролируемый злоумышленником.
Вот почему транспортировка, целостность и подлинность — это отдельные уровни. TLS защищает канал, дайджест сравнивает байты, а подпись связывает результат проверки с контролем закрытого ключа. Ни один уровень не должен рассматриваться как подтверждающий свойство, предоставленное другим, даже если рабочий процесс выпуска разумно сочетает в себе все три.
Чего это не касается — распределение ключей и корни доверия, которые являются самой сложной частью подписей.
Распределение ключей — это жесткая граница, которую не пересекает этот дайджест-калькулятор. Средство проверки подписи по-прежнему нуждается в подлинном открытом ключе или цепочке сертификатов, а также в политике ротации, отзыва и приемлемых алгоритмах. Математически достоверная подпись под ненадежным ключом доказывает только то, что владелец этого ненадежного ключа подписал байты.
Соответственно, отработанные сценарии прекращаются там, где доверенный ключ уже доступен. Они не предписывают закрепление сертификатов, инфраструктуру открытых ключей или церемонии выпуска ключей. Эти варианты развертывания нуждаются в собственном проверенном дизайне; ToolAcre предоставляет простой дайджест, который может быть подписан, а не корень доверия, используемый для проверки личности.
Вывод: контрольные суммы для целостности, подписи для аутентичности — ToolAcre SHA хэш-калькулятор вычисляет дайджесты; проверка того, кто их опубликовал, — это отдельный шаг
Хэш-калькулятор ToolAcre SHA вычисляет сторону целостности этой проверки. Используйте его для хеширования загруженного файла и проверки его на опубликованное значение. Если они совпадают, загрузка не повреждена. Но если они совпадают, потому что злоумышленник переписал оба, одна только проверка целостности не поможет. Инструмент честно говорит об этом ограничении и не претендует на проверку подлинности. Только для целостности контрольные суммы выполняются быстро и качественно. Для подлинности нужны подписи. TLS обеспечивает транспортную безопасность самой загрузки. Соединение с сервером зашифровано и проверено, поэтому злоумышленник в сети не сможет изменить файл при передаче. Однако TLS не поможет, если скомпрометирован сам сервер. Скомпрометированный сервер может передать любой файл через любое безопасное соединение TLS. Вот почему проверка на уровне приложения — контрольные суммы и подписи — имеет значение отдельно от транспортной безопасности.
Распространенной практикой в выпусках программного обеспечения является публикация как контрольных сумм, так и подписей. Контрольные суммы удобны; пользователи могут быстро проверить их с помощью однострочной команды оболочки. Подписи обеспечивают подлинность пользователей, у которых есть открытый ключ издателя. Пользователь может сначала проверить контрольную сумму для быстрого прохождения проверки целостности, а затем проверить подлинность подписи по ключу, хранящемуся в его связке ключей GPG. Эти две проверки служат разным целям и могут быть наслоены для обеспечения глубокоэшелонированной защиты. Сложная часть подписей — это распределение ключей и доверие. Вам нужен открытый ключ издателя, и вы должны верить, что он действительно принадлежит ему. Именно для решения этой проблемы существуют центры сертификации: они подписывают сертификаты издателя, а сертификаты корневого центра сертификации предварительно загружены в браузеры и операционные системы. Для небольшого проекта вы можете опубликовать ключ GPG на отдельном защищенном веб-сайте или на сервере открытых ключей. Проверка контрольной суммы не требует больших затрат; подписи требуют управления корнями доверия. Дополнительная сложность — это цена подлинности.