Обновление хеш алгоритма цифровой подписи с sha 1 до sha 2

Обновлено: 05.05.2024

Проверка цифровой подписи драйвера является одним из важнейших средств обеспечения работоспособности операционной системы. Цифровая подпись гарантирует, что устанавливаемое программное обеспечение является легальным и имеет конкретного разработчика. Особенно важно, чтобы в системе было невозможно установить драйвер или системный сервис от неизвестного производителя, что может иметь негативные последствия как для самой ОС, так и для пользователя, который может пострадать, например, от хакерской атаки. Стоит заметить, что изредка встречаются случаи, когда подлинный драйвер может оказаться без соответствующей цифровой подписи. Подчеркну, что это бывает очень редко, гораздо чаще проблема кроется в том, что цифровая подпись имеется, но возникли проблемы в процессе ее проверки. Обычно, с этим явлением сталкиваются пользователи Windows 7, при чем, как правило, - при установке современных драйверов от производителей оборудования, которые просто не могут выпустить драйвер без цифровой подписи. И подобные случаи практически не наблюдаются по отношению к операционным системам Windows 8.x и Windows 10, что наводит на мысль об определенных недостатках именно ОС Windows 7.

Вплоть до 2017 года SHA-1 был самым популярным алгоритмом, используемым для цифровых подписей, не смотря на то, что он устарел и по мере роста производительности компьютерной техники вполне допускал возможность взлома хэша за разумное время, что и продемонстрировано здесь. Другими словами – использование алгоритма SHA-1 для цифровых подписей стало невозможным, и индустрия открытых ключей (PKI) довольно поспешно перешла на использование SHA-2. Поддержка этого алгоритма сейчас реализована практически всеми сервисами, устройствами, операционными системами и т.п. Операционные системы Windows 8x / 10 имели такую поддержку изначально, а вот Windows 7 получает ее только после установки обновления kb4474419 , выпущенного Microsoft в конце сентября 2019года. Другими словами, до установки kb4474419 , драйвер, имеющий цифровую подпись на базе SHA-2, в среде Windows 7, а также Windows Server 2008, 2008R2 являлся драйвером ”не имеющим цифровой подписи” и попытка его установки завершается кодом ошибки 52 . В качестве решения проблемы, подавляющее большинство пользователей использует не совсем оптимальный прием, основанный на отключении проверки цифровой подписи. На первый взгляд кажется, что такое решение вполне приемлемо, однако не учитывается тот факт, что алгоритм SHA-2 используется не только для обработки цифровых подписей файлов, но и во многих приложениях, где проверяется, например достоверность удаленного сервера, файла произвольного формата и т.п. Решение проблемы с установкой драйвера без проверки цифровой подписи может обернуться другими, далеко не очевидными, проблемами в работе прикладного программного обеспечения и проявиться это может спустя какое-то, возможно даже продолжительное время. Поэтому, прием, основанный на отключении проверки цифровой подписи должен рассматриваться как крайний случай, когда требуется установка реально надежного драйвера из проверенного источника, в самом деле, не имеющего цифровой подписи и вы убеждены, что в системе присутствует поддержка алгоритма SHA-2.

Как проверить наличие конкретных обновлений

Проверить наличие конкретных обновлений можно с помощью Панель управления - Программы и компоненты - Установленные обновления . А также по журналу обновлений в Центре обновления Windows или с помощью утилиты командной строки dism.exe :

dism /Online /Get-Packages

Или с выводом результатов в текстовый файл, например D:\Get-Packages.txt:

dism /Online /Get-Packages > D:\Get-Packages.txt

В текстовом файле Get-Packages.txt каждому установленному обновлению соответствует своя запись:

Удостоверение пакета : Package for KB4474419

6.1.3.2
Состояние : Установлен
Тип выпуска : Security Update
Время установки : 16.03.2021 1:45

В случае, когда обновление отсутствует, нужно установить его с использованием Центра обновления. В тех случаях, когда обновление невозможно установить, например, при использовании современных процессоров, которые якобы не поддерживаются ОС Windows 7, можно воспользоваться той же утилитой dism.exe :

Самым простым способом установки обновлений для Windows 7, в том числе и на неподдерживаемом оборудовании – воспользоваться замечательным ресурсом simplix.info. В разделе UpdatePack7R2 для обновления Windows 7 SP1 и Server 2008 R2 SP1 размещается постоянно обновляемый инструментарий для установки обновлений в рабочую систему или дистрибутив Windows 7 и Server 2008 R2, любого языка и архитектуры. Набор включает обновления для Internet Explorer 11, все критические, рекомендуемые и обновления безопасности.

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

Как проверить наличие цифровой подписи у файла.

В операционных системах семейства Windows имеются стандартное средство проверки цифровых подписей системных файлов - утилита sigverif.exe . Используется для поиска системных файлов без цифровой подписи. Запустить ее можно через диалог Выполнить (комбинацию клавиш Win+R) с правами Администратора системы.

После нажатия на кнопку Начать начнется проверка цифровых подписей системных файлов. Результаты проверки отображаются в окне программы:

Более детальную информацию можно получить из файла журнала программы Sigverif.txt , который можно просмотреть в режиме Дополнительно

В данном конкретном случае, утилита обнаружила один неподписанный файл драйвера C:\Windows\system32\ neo_0014.sys . Насколько это соответствует действительности, можно проверить с помощью другой системной утилиты verifier.exe , предназначенной для проверки работоспособности драйверов в Windows 7 / 8 10. При запуске без параметров, утилита отображает окно Диспетчера проверки драйверов , где необходимо выбрать проверяемые драйверы. По умолчанию, выбираются драйверы без цифровой подписи. После нажатия кнопки Далее должен отобразиться их список. Но, в данном случае, таковых не обнаружено:

При чем, если выбрать файл вручную, утилита verifier.exe определяет драйвер neo_0014.sys как имеющий цифровую подпись.

В качестве дополнительного средства контроля цифровых подписей можно воспользоваться утилитой от Microfoft Sysinternals SigCheck. Она имеет небольшой размер и не требует установки в системе. Просто разархивируйте загруженный по ссылке выше, файл в какой-либо каталог, лучше, присутствующий в путях поиска исполняемых файлов, определенных переменной окружения PATH и введите команду:

Отобразится информация о цифровой подписи файла:

C:\Windows\System32\drivers\neo_0014.sys:
Verified: Signed
Signing date: 10:34 05.02.2018
Publisher: SoftEther Corporation
Company: SoftEther Corporation
Description: SoftEther VPN
Product: SoftEther VPN
Prod version: 4, 25, 0, 9658
File version: 4, 25, 0, 9658
MachineType: 64-bit

В итоге, утилита sigchek определила, что файл драйвера neo_0014.sys имеет цифровую подпись SoftEther Corporation .

Таким образом, бывают случаи, когда подписанный цифровой подписью файл, может быть признан не имеющим подписи. Произойти это может по нескольким причинам, в том числе и внешним по отношению к текущей ОС Windows (например, временная невозможность выстроить цепочку сертификатов удостоверяющих центров по техническим причинам). Однако, как упоминалось выше, в случаях с Windows 7 нужно обратить особое внимание на работоспособность средств поддержки алгоритма SHA-2, обеспечиваемой обновлениями Microsoft. Основным из них является kb4474419, однако не исключено, что со временем к нему добавится еще какое-нибудь новое. В любом случае, ситуация с отсутствием цифровой подписи драйвера требует детальной разборки, а не бездумного отключения проверки цифровой подписи.

Как отключить проверку цифровой подписи драйвера.

На просторах Интернета можно найти описание нескольких способов отключения проверки цифровой подписи драйверов, как однократно, так и навсегда с использованием меню загрузчика и групповых политик. Однако надежным способом, обеспечивающим работоспособность драйвера без подписи является отключение проверки с помощью редактирования данных конфигурации загрузки (BCD – Boot Configuration Data) стандартной утилитой bcdedit.exe . Напомню, что порядок загрузки драйверов определяется параметром Start , который хранится в реестре для каждого существующего в системе драйвера, и может принимать значения:

0 (обозначается как boot загрузка). Загрузка драйвера выполняется в самом начале загрузки перед инициализацией ядра. Например, драйвер дискового контроллера.

1 (обозначается как System, системный) Загрузка драйвера осуществляется подсистемой ввода/вывода во время инициализации ядра. В качестве примера можно взять драйвер последовательного порта.

2 ( обозначается как Auto, запускаемый автоматически). Драйвер или служба запускаются автоматически, независимо от действий пользователя и его регистрации в системе.

3 (обозначается как Load of Demand, загружаемый вручную). Драйвер или служба запускаются по мере возникновения потребности в их функционировании. Например, как Драйвер запоминающих устройств для USB.

4 ( обозначается как Disabled, отключено). Драйвер или служба отключены. Вполне естественно, что для драйвера, имеющего параметр Start в реестре, равный 0 или 1, никакие групповые политики еще не могут быть применены, поскольку средства их применения еще не существуют в системе. Поэтому отключение проверки цифровой подписи драйвера на постоянной основе выполняются редактором данных конфигурации загрузки, командой:

bcdedit.exe -set TESTSIGNING ON - отключить проверку цифровой подписи. Естественно, команда должна выполняться от имени Администратора. Действительна не только для Windows 7, но и Windows 8 / 10.

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

В тех случаях, когда приведенная выше команда не срабатывает, рекомендуется перед ее выполнением отключить параметры контроля целостности конфигурации:

bcdedit.exe -set loadoptions DISABLE_INTEGRITY_CHECK

Хотя, из личного опыта – команда не оказывает никакого влияния на поведение загрузчика Windows.

Индустрия инфраструктуры открытых ключей (ИОК, англ. PKI — Public Key Infrastructure) рекомендует, чтобы любой объект инфраструктуры, использующий SHA-1, был переведён на более безопасный SHA-2. В этой статье описано, почему и как стоит это сделать.

В 2016 году миграция на SHA-2 была хорошей подготовкой к всеобщему дедлайну, сейчас же этот переход обязателен для обеспечения безопасности. Многие устройства и приложения, использующие электронные сертификаты, уже сейчас выводят предупреждения или ошибки или отказываются работать, если сертификат использует алгоритмы хеширования SHA-1 или старше. Зачем эти принудительные изменения? Потому что в хеше SHA-1 обнаружены серьёзные криптографические уязвимости, и дни, когда его защита ещё надёжна, уже сочтены.

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

Что такое хеш?

Службы центра сертификации (ЦС) ИОК используют криптографические хеш-функции для подтверждения идентификационных данных и запросов цифровых сертификатов. Кроме этого, хеши используются для подтверждения цифровых сертификатов (например, цифровой подписью) и списка аннулированных сертификатов (CRL, certificate revocation list), которые выдают другие доверенные стороны. Доверенные стороны не смогут полагаться на достоверность цифровых сертификатов и другого контента, подписанного ЦС, если службы ИОК используют ненадёжный криптографический хеш. Стойкость криптографического хеша создаёт доверие ко всей системе ИОК.

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

Атаки на хеши

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

Введение в семейство SHA

Алгоритм SHA-1 был разработан Агентством национальной безопасности США (АНБ) и опубликован Национальным институтом стандартов и технологий США (NIST) в качестве федерального стандарта в 1995 году. Выпущенные NIST криптографические стандарты пользуются доверием по всему миру и как правило требуются на всех компьютерах, используемых правительством или вооружёнными силами Соединённых Штатов. SHA-1 заменил предыдущие ослабевшие хеш-функции, например, MD5.

Со временем несколько непрерывных криптографических атак на SHA-1 уменьшили эффективность длины ключа. Из-за этого в 2002 году АНБ и NIST выбрали SHA-2 новым рекомендуемым стандартом хеширования. Это случилось задолго до того, как SHA-1 начали считать взломанным. В феврале 2017 года обнаружили успешную атаку на хеш с помощью коллизий, которая сделала SHA-1 бесполезным для защиты электронной подписи.

Отличное обсуждение взлома SHA-1 и пример документации можно найти здесь.

Семейство SHA-2

SHA-2 — стандарт криптографического хеширования, который программное и аппаратное обеспечение должны использовать по крайней мере ближайшие пару лет. SHA-2 очень часто называется семейством хеш-функций SHA-2, поскольку содержит много хешей разных размеров, включая 224-, 256-, 384- и 512-битные последовательности. Когда кто-то говорит, что использует SHA-2, длина его хеша неизвестна, но сейчас самый популярный — 256-битный. Хотя некоторые математические характеристики SHA-2 совпадают с SHA-1, и в нём обнаружены незначительные недостатки, в криптомире он по-прежнему считается «стойким». Без сомнения, он лучше, чем SHA-1 и чем любой критический сертификат, приложение или аппаратное устройство, использующие SHA-1. Всё, что использует SHA-1, лучше перевести на SHA-2.

Обработка устаревших хэшей SHA-1

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

План перехода ИОК с SHA-1 на SHA-2

Каждая компания с внутренним ИОК, не использующая SHA-2, должна будет создать ИОК SHA-2 или перевести существующую ИОК с SHA-1 на SHA-2. Для перехода нужно:

Обучить вовлечённых членов команды тому, что такое SHA-2 и почему требуется его использование (эта статья будет хорошим началом).
Провести инвентаризацию всех критических хешей или цифровых сертификатов, используемых в приложениях или устройствах.
Определить, какие критически важные устройства или приложения могут использовать SHA-2, какой размер ключа может быть использован и какие операционные проблемы могут возникнуть (этот этап зачастую включает обращение к поставщику и тестирование).
Определить, какие компоненты ИОК могут или должны быть перенесены в SHA-2.
Составить план перехода для преобразования компонентов SHA-1 в SHA-2, включая потребителей и компоненты ИОК, плюс резервный план на случай сбоя.
Провести PoC-тестирование.
Принять управленческий риск и решение о переходе или отказе от него.
Внедрить план перехода в производственную среду.
Провести тестирование и получить обратную связь.

Подумайте о своей миссии, чтобы определить, какие важные части вашей инфраструктуры будут или не будут работать. Начните с попытки инвентаризации каждого уникального устройства, ОС и приложения, которые должны понимать SHA-2. Затем соберите команду людей, которые протестируют, работает ли SHA-2. Можно предварительно полагаться на информацию от поставщиков, но вы не будете знать наверняка пока не проверите самостоятельно.

Обновление приложений и устройств — задача не из лёгких, и потребует больше времени, чем кажется. Даже сейчас существует множество устройств и приложений, использующих старые версии OpenSSL, которые следовало бы обновить после атаки Heartbleed, но администраторы серверов этого так и не сделали.

Если у вас есть внутренняя ИОК, вам понадобится подготовить её к переходу на SHA-2. Иногда это означает обновление ваших центров сертификации, получение новых сертификатов или установку полностью новых ИОК. Последнее рекомендуется по множеству причин, в основном потому, что новая ИОК даст вам шанс начать сначала без груза старых ошибок.

Модели перехода ИОК

Ниже перечислены сценарии для внедрения SHA-2 в компоненты ИОК (для этих примеров используется двухуровневая ИОК — автономная корневая система, онлайн центры сертификации), каждый из которых может быть либо новым компонентом, либо перенесённым:

Два ИОК дерева, один полностью SHA-1, другой полностью SHA-2.

Остальные сценарии предполагают одно дерево ИОК:

Всё дерево ИОК, от корня до конечных точек, — SHA-1.
Всё дерево ИОК, от корня до конечных точек, — SHA-2.
Корень — SHA-1, выдающие ЦС — SHA-2, сертификаты конечных точек — SHA-2.
Корень — SHA-1, выдающие ЦС — SHA-2, сертификаты конечных точек — SHA-1.
Корень — SHA-1, выдающие ЦС — SHA-2 и SHA-1, сертификаты конечных точек — SHA-2 и SHA-1.
Корень — SHA-2, выдающие ЦС — SHA-1, сертификаты конечных точек — SHA-1.
Корень — SHA-2, выдающие ЦС — SHA-2, сертификаты конечных точек — SHA-1.
Корень — SHA-2, выдающие ЦС — SHA-2 и SHA-1, сертификаты конечных точек — SHA-2 и SHA-1.

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

Примечание: собственный сертификат ЦС корневого ЦС не нужно переносить на SHA-2, даже если он всё ещё использует SHA-1. Все программы проверки устаревших SHA-1 заботятся обо всём после собственного сертификата корневого ЦС (и будут заботиться, по крайней мере, в обозримом будущем). Тем не менее, имеет смысл переместить всё, включая собственный сертификат ЦС корневого ЦС на SHA-2, чтобы можно было сказать, что вся ИОК — SHA-2, и избежать дальнейших изменений, связанных с SHA-1, в обозримом будущем.

Публичные ЦС уже перешли с SHA-1 на SHA-2 для любых сертификатов со сроком жизни, заканчивающимся после 1 января 2017, поэтому вы должны сосредоточить свои усилия на серверах и приложениях с ещё не перешедшими на SHA-2 публичными цифровыми сертификатами. После решения этой проблемы можно начать смотреть на внутренние ИОК и доверенные стороны. Переход с SHA-1 на SHA-2 технически не сложен, но это массовое логистическое изменение с множеством последствий, которое требует продолжительного тестирования.

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

SHA-3 уже здесь, но стоит ли его использовать?

Хотя в SHA-2 не обнаружено существенных криптографических слабостей, он считается алгоритмически схожим с SHA-1. Большинство экспертов думают, что его время жизни будет схожим с SHA-1. В августе 2015 NIST утвердило новый алгоритм криптографического хеширования SHA-3. Он не обладает теми же математическими свойствами, что SHA-1 и SHA-2 и должен быть более устойчив к криптографическим атакам, чем его предшественники.

К сожалению, люди, откладывающие свой переход на SHA-2 в надежде сразу перейти на SHA-3, будут очень расстроены. Общемировое принятие стандарта SHA-3 может затянуться на долгие годы, а переход на SHA-2 следует сделать уже сейчас. Если вы перейдёте на SHA-3 сейчас, то большинство, если не все, ваших криптографически-зависимых приложений или устройств, скорее всего, сообщат об ошибке (не смогут распознать цифровой сертификат).

Итак, если вы ещё не перешли на SHA-2, то переходите сейчас. И когда SHA-2 начнёт ослабевать, мы все вместе перейдём на SHA-3.

Для защиты безопасности операционной системы Windows ранее были подписаны обновления (с использованием как алгоритмов SHA-1, так и SHA-2). Подписи используются для проверки подлинности обновлений непосредственно от корпорации Майкрософт и не подделыв их во время доставки. Из-за недостатков алгоритма SHA-1 и в связи с отраслевыми стандартами мы изменили подпись обновлений Windows на более безопасный алгоритм SHA-2. Это изменение было поэтапно сделано с апреля 2019 г. по сентябрь 2019 г., чтобы обеспечить плавную миграцию (дополнительные сведения об изменениях см. в разделе "Расписание обновления продуктов").

Клиентам, которые работают с устаревшими версиями ОС (Windows 7 с SP1, Windows Server 2008 R2 с SP1 и Windows Server 2008 с SP2), на их устройствах должна быть установлена поддержка подписи кода SHA-2 для установки обновлений, выпущенных в июле 2019 г. или после этого. Все устройства без поддержки SHA-2 не смогут установить обновления Windows в июле 2019 г. или после него. Для подготовки к этому изменению мы выпустили поддержку для входов SHA-2 в марте 2019 г. и внося добавоонные улучшения. cлужбы Windows Server Update Services (WSUS) 3.0 SP2 будет получать поддержку SHA-2 для безопасной доставки подписанных обновлений SHA-2. См. раздел "Расписание обновления продуктов" для временной шкалы миграции SHA-2.

Сведения о фоновом режиме

Безопасный hash Algorithm 1 (SHA-1) был разработан в качестве необратимых функций hashing и широко используется при подписании кода. К сожалению, безопасность алгоритма sha-1 со временем становится менее надежной из-за недостатков алгоритма, повышения производительности процессора и появления облачных вычислений. Более надежные альтернативы, такие как безопасный hash Algorithm 2 (SHA-2), теперь являются предпочтительными, так как в них проблемы не одинаковы. Дополнительные сведения о том, как не используется SHA-1, см. в документах "Hash" (Hash) и Signature Algorithms (Алгоритмы подписи).

Расписание обновления продукта

С начала 2019 г. процесс миграции на sha-2 начался поэтапно, и поддержка будет доставляться в автономные обновления. Корпорация Майкрософт нацелена на следующее расписание, чтобы предложить поддержку SHA-2. Имейте в виду, что может измениться следующая временная шкала. Мы продолжим обновлять эту страницу по мере необходимости.

Целевая дата

Применяется к

12 марта 2019 г.

Автономные обновления для системы безопасности KB4474419 и KB4490628, выпускаются для поддержки подписи кода SHA-2.

Windows 7 с sp1
Windows Server 2008 R2 SP1

12 марта 2019 г.

Отдельное обновление KB4484071 доступно в каталоге Обновлений Windows для WSUS 3.0 с sp2, который поддерживает доставку подписанных обновлений SHA-2. Для пользователей WSUS 3.0 с sp2 это обновление должно быть установлено вручную не позднее 18 июня 2019 г.

9 апреля 2019 г.

Отдельное обновление KB4493730, в которое вводится поддержка подписи кода SHA-2 для стека обслуживания (SSU), выпущено в обновлении для системы безопасности.

Windows Server 2008 с пакетом обновления 2 (SP2)

14 мая 2019 г.

Отдельное обновление для системы безопасности KB4474419, выпущенное для поддержки подписи кода SHA-2.

Windows Server 2008 с пакетом обновления 2 (SP2)

11 июня 2019 г.

Отдельное обновление для системы безопасности KB4474419было выпущено повторно, чтобы добавить отсутствующие знаки кода MSI SHA-2.

Windows Server 2008 с пакетом обновления 2 (SP2)

18 июня 2019 г.

В Windows 10 подписи, измененные с двух подписей (SHA-1/SHA-2) на SHA-2, изменены. Действия клиента не требуются.

Windows 10 версии 1709
Windows 10 версии 1803
Windows 10 версии 1809
Windows Server 2019

18 июня 2019 г.

Обязательно: Для клиентов, использующих WSUS 3.0 с sp2, для поддержки обновлений SHA-2 к этой дате необходимо вручную установить KB4484071.

9 июля 2019 г.

Обязательно: Для обновления устаревших версий Windows потребуется установить поддержку подписи кода SHA-2. Поддержка, выпущенная в апреле и мае(KB4493730 и KB4474419),потребуется для продолжения получения обновлений для этих версий Windows.

В настоящее время все устаревшие подписи Обновлений Windows изменились с SHA1 и на SHA-2 с двойной подписью (SHA-1/SHA-2) на SHA-2.

Windows Server 2008 с пакетом обновления 2 (SP2)

16 июля 2019 г.

В Windows 10 подписи, измененные с двух подписей (SHA-1/SHA-2) на SHA-2, изменены. Действия клиента не требуются.

Windows 10 версии 1507
Windows 10 версии 1607
Windows Server 2016
Windows 10 версии 1703

13 августа 2019 г.

Обязательно: Для обновления устаревших версий Windows потребуется установить поддержку подписи кода SHA-2. Для продолжения получения обновлений для этих версий Windows потребуется поддержка, выпущенная в марте(KB4474419 и KB4490628). Если вы используете устройство или VM с загрузкой EFI, дополнительные действия по предотвращению проблемы с устройством могут не запускаться, см. в разделе "Вопросы и вопросы и вопросы".

В настоящее время все устаревшие подписи Windows изменились с SHA-1 и SHA-1/SHA-2 на SHA-2.

Windows 7 с sp1
Windows Server 2008 R2 SP1

10 сентября 2019 г.

Подписи в устаревших обновлениях Windows были изменены с двух подписей (SHA-1/SHA-2) на SHA-2. Действия клиента не требуются.

Windows Server 2012
Windows 8,1
Windows Server 2012 R2

10 сентября 2019 г.

Отдельное обновление для системы безопасности KB4474419 было повторно выпущено для добавления отсутствующих сотрудников загрузки EFI. Убедитесь, что эта версия установлена.

Windows 7 с sp1
Windows Server 2008 R2 SP1
Windows Server 2008 SP2

28 января 2020 г.

Подписи в списках доверия сертификата (CTLS) для надежной корневой программы Майкрософт изменены с двух подписей (SHA-1/SHA-2) на SHA-2. Действия клиента не требуются.

Все поддерживаемые платформы Windows

Август 2020 г.

Конечные точки службы на базе Windows Update SHA-1 больше не будут. Это влияет только на старые устройства с Windows, на которых не были обновлены соответствующие обновления для системы безопасности. Дополнительные сведения см. в KB4569557.

Windows 7
Windows 7 с sp1
Windows Server 2008
Windows Server 2008 с sp2

Windows Server 2008 R2 Windows Server 2008 R2 SP1

3 августа 2020 г.

Корпорация Майкрософт удалила из Центра загрузки Майкрософт содержимое, подписанное на Windows для безопасного hash Algorithm 1 (SHA-1). Дополнительные сведения см. в блоге WINDOWS PRO SHA-1 для Windows, который будет отменен 3 августа 2020 г.

Windows Server 2000
Windows XP
Windows Server 2003
Windows Vista
Windows Server 2008
Windows 7

Windows Server 2008 R2
Windows 8 Windows Server 2012
Windows 8,1
Windows Server 2012 R2
Windows 10
Windows 10 Server

Текущее состояние

Windows 7 с sp1 и Windows Server 2008 R2 с SP1

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

Обновление стека обслуживания (SSU) (KB4490628). При использовании Обновления Windows вам будет автоматически предложен необходимый SSU.

Обновление SHA-2(KB4474419)выпущено 10 сентября 2019 г. При использовании Обновления Windows вам автоматически будет предложено необходимое обновление SHA-2.

Важно!После установки всех необходимых обновлений необходимо перезапустить устройство перед установкой ежемесячных обновлений, обновлений только для системы безопасности, предварительной версии monthly Rollup или автономных обновлений.

Windows Server 2008 с пакетом обновления 2 (SP2)

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

Обновление стека обслуживания (SSU) (KB4493730). Если вы используете Обновление Windows, вам автоматически будет предложено необходимое обновление SSU.

Последнее обновление SHA-2(KB4474419)выпущено 10 сентября 2019 г. При использовании Обновления Windows вам автоматически будет предложено необходимое обновление SHA-2.

Вопросы и ответы

Общие сведения, планирование и предотвращение проблем

1. Чем отличаются обновления для KB3033929 и KB4039648 от автономных обновлений, которые были отправлены в марте и апреле?

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

Начиная с WSUS 4.0 в Windows Server 2012, WSUS уже поддерживает обновления SHA-2, подписанные, и для этих версий не требуется никаких действий со стороны клиента.

Только для WSUS 3.0 SP2 требуется установить KB4484071для поддержки только подписанных обновлений SHA2.

3. У меня есть система Windows Server 2008 с обновлениями 2 (SP2), которая в два сапог с Windows Server 2008 R2 (или Windows 7). Как обновиться до SHA-2?

Предположим, что вы запустите Windows Server 2008 с sp2. При двойном загрузке с Windows Server 2008 R2 SP1 или Windows 7 с SP1 диспетчер загрузки для этого типа системы будет работать в системе Windows Server 2008 R2/Windows 7. Чтобы успешно обновить обе эти системы для использования поддержки SHA-2, необходимо сначала обновить систему Windows Server 2008 R2/Windows 7, чтобы диспетчер загрузки обновился до версии, которая поддерживает SHA-2. Затем обновим систему Windows Server 2008 с sp2 с помощью SHA-2.

4. У меня есть система с двумя разделами: с Windows Server 2008 с SP2, а второй — со средой загрузки Windows 7 PE (WinPE). Как обновиться до SHA-2?

Как и в случае с двумя загрузками, необходимо обновить среду PE для Windows 7 до поддержки SHA-2. Затем необходимо обновить систему Windows Server 2008 с sp2 до поддержки SHA-2.

5. Я использую установку для чистой установки Windows 7 с Windows Server 2008 R2 с Windows Server 2008 R2 SP1. Я использую изображение, которое было настроено с помощью обновлений (например, с помощью dism.exe). Как обновиться до SHA-2?

Запустите установку Windows для завершения и загрузки в Windows до установки обновлений от 13 августа 2019 г. или более поздней версии

Откройте окно командной подсказки администратора и запустите bcdboot.exe. При этом файлы загрузки копируется из каталога Windows и настраивается среда загрузки. Дополнительные сведения см. в Command-Line параметрах bcDBoot.

Перед установкой дополнительных обновлений установите выпуск KB4474419 и KB4490628 для Windows 7 с sp1 и Windows Server 2008 R2 с sp1 от 1 августа 2019 г.

Перезапустите операционную систему. Требуется перезапуск

Установите все оставшиеся обновления.

6. Я устанавливаю изображение Windows 7 с Windows Server 2008 R2 с Windows Server 2008 R2 с sp1 непосредственно на диск без настройки. Как сделать так, чтобы этот сценарий работал?

Установите изображение на диск и загрузите его в Windows.

В командной области запустите bcdboot.exe. При этом файлы загрузки копируется из каталога Windows и настраивается среда загрузки. Дополнительные сведения см. в Command-Line параметрах bcDBoot.

Перед установкой дополнительных обновлений установите повторное обновление KB4474419 и KB4490628 для Windows 7 с SP1 и Windows Server 2008 R2 с sp1 от 23 сентября 2019 г.

Перезапустите операционную систему. Требуется перезапуск

Установите все оставшиеся обновления.

7. Мои устройства x64 или VM используют загрузку EFI, поддерживаемую этим обновлением SHA-2 в Windows 7 с sp1 и Windows Server 2008 R2 SP1?

Да, необходимо установить необходимые обновления, прежде чем продолжите:SSU (KB4490628)и SHA-2(KB4474419). Кроме того, после установки необходимых обновлений необходимо перезапустить устройство.

8. Windows 10 версии 1903 нет в таблице выше. Поддерживает ли она обновления SHA-2? Требуются ли какие-либо действия?

Windows 10 версии 1903 поддерживает SHA-2 с момента выпуска, а все обновления УЖЕ подписаны только на SHA-2. Для этой версии Windows не требуется никаких действий.

9. Я устанавливаю обновления в веб-систему (с помощью dism.exe /online). Как сделать так, чтобы этот сценарий работал?

Windows 7 с sp1 и Windows Server 2008 R2 с SP1

Загрузка в Windows перед установкой обновлений от 13 августа 2019 г. или более поздней версии.

Перед установкой дополнительных обновлений установите выпуск KB4474419 и KB4490628для Windows 7 с SP1 и Windows Server 2008 R2 с sp1 от 23 сентября 2019 г.

Перезапустите операционную систему. Требуется перезапуск

Установите все оставшиеся обновления.

Windows Server 2008 с пакетом обновления 2 (SP2)

Загрузка в Windows перед установкой обновлений от 9 июля 2019 г. или более поздней версии.

Перед установкой дополнительных обновлений установите повторное обновление KB4474419 и KB4493730 для Windows Server 2008 с обновлениями 2 (SP2) от 23 сентября 2019 г.

Перезапустите операционную систему. Требуется перезапуск

Установите все оставшиеся обновления.

Проблема с восстановлением

Запустите операционную систему с помощью мультимедиа для восстановления.

Перед установкой дополнительных обновлений установите обновление KB4474419 от 23 сентября 2019 г. или более поздней с помощью системы обслуживания и управления образами развертывания(DISM)для Windows 7 с sp1 и Windows Server 2008 R2 с sp1.

Перезапустите операционную систему.

Приостановка развертывания на других устройствах без перезапуска еще не перезапуска каких-либо устройств или ВМ-м.

Определение устройств и ВМ-устройств в состоянии ожидания перезагрузки с помощью обновлений, выпущенных 13 августа 2019 г. или более поздней версии, и открытия командной подсказки с повышенными уровнями

Найдите удостоверение пакета для обновления, которое вы хотите удалить, с помощью следующей команды, используя KB-номер для этого обновления (замените 4512506 на целевой номер KB, если он не выпущен 13 августа 2019 г.): dism /online /get-packages | findstr 4512506

Чтобы удалить обновление, заменив удостоверение пакета<на>с помощью предыдущей команды, воспользуйтесь следующей командой: Dism.exe /online /remove-package /packagename:<удостоверение пакета>

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

Примечание.Для любого устройства или VM, на которое вы сейчас получаете 0xc0000428 или который начинает работать в среде восстановления, необходимо будет предпринять действия, которые необходимо предпринять, чтобы 0xc0000428.

3. Что делать, если я получаю ошибку с кодом 80096010 или 80092004 (CRYPT_E_NOT_FOUND), "В Обновлении Windows произошла неизвестная ошибка" при попытке установить обновление в Windows 7 с sp1, Windows Server 2008 R2 с SP1 или Windows Server 2008 с SP2?

Если вы столкнулись с этими ошибками, вам необходимо установить необходимые обновления, перечисленные в разделе "Как получить обновление" обновления, который вы пытаетесь установить, или необходимые обновления, перечисленные выше в разделе "Текущее состояние" этой статьи.

Запустите операционную систему с помощью мультимедиа для восстановления.

Установите последнее обновление SHA-2(KB4474419),выпущенное 13 августа 2019 г., с помощью системы обслуживания изображений развертывания(DISM)для Windows 7 с SP1 и Windows Server 2008 R2 с sp1.

Перезагружается в восстановленный носитель. Требуется перезапуск

Перезапустите операционную систему.

Если вы столкнулись с этой проблемой, вы можете устранить эту проблему, открыв окно командной подсказки и выдав следующую команду, чтобы установить обновление (замените место <msu> на фактическое расположение и имя файла обновления):

wusa.exe <msu location> /quiet

Эта проблема устранена в выпуске KB4474419 от 8 октября 2019 г. Это обновление будет автоматически устанавливаться из Windows Update и WSUS cлужбы Windows Server Update Services (WSUS). Если вам нужно установить это обновление вручную, необходимо использовать вышеуказанное обходное решение.

Примечание.Если вы ранее установили KB4474419, выпущенный 23 сентября 2019 г., то у вас уже есть последняя версия этого обновления, и вам не нужно переустановить ее.

Ранее все обновления доставлялись с помощью SHA-1 и SHA-2. Алгоритм хеширования SHA-1 имеет ряд известных недостатков, и Microsoft планирует отказаться от SHA-1 и полностью перейти на улучшенный алгоритм SHA-2 в сентябре 2019 года.

Хотя данное изменение не представляет какой-либо проблемы для Windows 8.1, Windows 10 и соответствующих им серверных версий, этого нельзя сказать о Windows 7 и Windows Server 2008. Причина проста: обновления SHA-2 не поддерживаются в данных операционных системах.

Любое обновление, которое поставляется исключительно в SHA-2 версии и подписано только с помощью SHA-2, невозможно верифицировать на устройствах Windows 7 или Windows Server 2008. Это означает, что такие обновления не будут устанавливаться на устройствах под управлением данных версий Windows, пока не будет установлен патч для обновлений SHA-2.

Microsoft опубликовала график событий, связанных с переходом на SHA-2, на странице поддержки:

Целевая дата	Событие	Применяется для
12 марта, 2019	В качестве обновлений безопасности выпущены патчи KB4474419 и KB4490628, которые добавляют поддержку SHA-2.	Windows 7 SP1, Windows Server 2008 R2 SP1
12 марта, 2019	Для WSUS 3.0 с пакетом обновления SP2 выпущен патч KB4484071, который добавляет поддержку доставки обновлений, подписанных с помощью SHA-2. Для тех пользователей, которые используют WSUS 3.0 SP2, этот патч должен быть установлен не позднее 18 июня 2019 года.	WSUS 3.0 SP2
9 апреля, 2019	В качестве обновления безопасности выпущены патч KB4493730, в котором добавлена поддержка SHA-2 для служебного стека (SSU).	Windows Server 2008 SP2
18 июня, 2019	Цифровые подписи обновлений Windows 10 будут изменены с двойной подписи (SHA-1 / SHA-2) только на SHA-2. Никаких действий со стороны клиента не потребуется.	Windows 10 1709, Windows 10 1803, Windows 10 1809, Windows Server 2019
18 июня, 2019	Обязательно: для клиентов, использующих WSUS 3.0 SP2, патч поддержки SHA-2 KB4484071 должен быть установлен к этой дате.	WSUS 3.0 SP2
16 июля, 2019	Обязательно: Для обновления устаревших версий Windows потребуется установить патчи поддержки SHA-2. Установка патчей поддержки, выпущеных в марте и апреле, потребуется для продолжения получения обновлений для этих версий Windows.	Windows 7 SP1, Windows Server 2008 R2 SP1, Windows Server 2008 SP2
16 июля, 2019	Цифровые подписи обновлений Windows 10 изменены с двойной подписи (SHA-1 / SHA-2) только на SHA-2. Никаких действий со стороны клиента не требуется.	Windows 10 1507, Windows 10 1607, Windows 10 1703
13 августа, 2019	Содержимое обновлений для старых версий Windows подписано SHA-2 (встроенные подписанные двоичные файлы и каталоги). Никаких действий со стороны клиента не требуется.	Windows 7 SP1, Windows Server 2008 R2 SP1
10 сентября, 2019	Устаревшие цифровые подписи обновлений Windows будут изменены с двойной подписи (SHA-1 / SHA-2) только на SHA-2. Никаких действий со стороны клиента не потребуется.	Windows Server 2012, Windows 8.1, Windows Server 2012 R2

Обновления, выпущенные до 12 июня 2019 года, по-прежнему будут доступны в виде SHA-1 версий, в противном случае произошла бы полная блокировка получения каких-либо обновлений.

Устройства, на которых не установлен патч SHA-2, перестанут получать обновления, начиная с 16 июля 2019 года до тех пор, пока патч не будет установлен в системе.

В целях обеспечения безопасности, обновления операционной системы Windows в настоящее время имеют двойную подпись с использованием алгоритмов хеширования SHA-1 и SHA-2. Проверка подлинности позволяет убедиться, что обновления поставляются непосредственно от корпорации Майкрософт и не были подменены во время доставки. Из-за ряда недостатков алгоритма SHA-1 и необходимости соответствия современным отраслевым стандартам Microsoft станет подписывать обновления Windows, исключительно с помощью более безопасного алгоритма SHA-2.

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