Обновление для добавления поддержки для Windows Server 2008 SP2 подписывания SHA-2
Обзор
Это обновление обеспечивает поддержку безопасный хэш алгоритм-2 (SHA-2) и проверки подписи функциональность кода в 64-разрядной версии Windows Server 2008 Пакет обновления 2 (SP2) который включает следующие компоненты:
Поддержка нескольких подписей на CAB-файл CAB-файла.
Поддержка нескольких подписей для файлов Windows PE.
Поддержка просмотра нескольких подписей при обновлении пользовательского интерфейса (UI).
Поддержка Проверка отметок времени RFC3161 компонент целостность кода, который проверяет подписи в ядре.
Поддержка различных прикладного программирования (API), которые включают CertIsStrongHashToSign, CryptCATAdminAcquireContext2 и CryptCATAdminCalcHashFromFileHandle2.
Безопасный хэш алгоритм (SHA) была разработана для использования в стандарте цифровой подписи (DSS) или алгоритма цифровой подписи (DSA). Он создавал бы 160-разрядных хэш-значение. Но известные слабые места SHA-1 предоставляет сам конфликт атак, которые позволяют злоумышленнику создать дополнительные сертификаты, цифровые подписи, как оригинал. Дополнительные сведения о SHA-1 хеша и алгоритмы подписисм.
Как получить это обновление
Каталог Центра обновления Майкрософт
Для получения отдельного пакета для данного обновления перейдите на веб-сайт каталога Центра обновления Майкрософт.
Сведения об обновлении
Предварительные условия
Для установки этого обновления необходимо иметь Windows Server 2008 с пакетом обновления 2, 64-разрядной установке.
Сведения о реестре
Чтобы применить это обновление, не нужно вносить изменения в реестр.
Необходимость перезагрузки
После установки обновления компьютер необходимо перезагрузить.
Сведения о замене обновлений
Это обновление не заменяет ранее выпущенное обновление.
Дополнительные сведения
Система будет продолжать поддержку операций SHA-1 без изменений, поддерживающих. SHA-2 поддержка доступна до изменения Windows обновлений переместить из подписей SHA-1 и SHA-2 подписи переход полностью. В выпуске этой поддержки SHA-2 является первым шагом в этот переход. Позднее, эта поддержка станет обязательным для упрощения ключ SHA-2 подпись обновлений для Windows Server 2008 SP2.
RFC3161 Интернета X.509 открытый ключ инфраструктуры штамп времени протокол (TSP) определяет и описывает формат запросов и ответов на время отметки центра (TSA). TSA может использоваться для доказать, что цифровая подпись была создана во время срока действия сертификата открытого ключа X.509 инфраструктуры открытого ключасм.
В криптографии открытого ключа один из ключей, называемый закрытый ключ, должны храниться в секрет. Ключ, известный как открытый ключ предназначен для совместного использования в мире. Тем не менее должен быть способ для владельца раздела о том мире, к которому принадлежит ключ. Цифровые сертификаты предоставляют способ сделать это.
Цифровой сертификат — это электронный учетных данных, используемых для подтверждения удостоверения Интернет компьютеров, организаций и частных лиц. Цифровые сертификаты содержат открытый ключ упаковки вместе с некоторую базовую информацию (владельца, чего он может быть использован, после истечения срока его действия и поэтому он включен). Дополнительные сведения содержатся в разделе Общие сведения о криптографии открытого ключа и цифровые сертификаты.
Цифровые сертификаты в основном используются для проверки удостоверения пользователя или устройства, службы проверки подлинности или шифрования файлов. Как правило не нужно думать о сертификаты, время от времени сообщения о том, что срок действия сертификата истек или недопустимое. В этих случаях один необходимо следовать инструкциям в сообщении.
Статус
Корпорация Майкрософт подтверждает, что это проблема продуктов Майкрософт, перечисленных в разделе «Относится к».
Ссылки
SHA-2 поддержка Майкрософт для Windows Server 3.0 SP2
Аннотация
Чтобы соответствовать отраслевым стандартам, Корпорация Майкрософт отходит от использования подписей SHA-1 для будущих обновлений и переходит на подписи SHA-2 (подробнее см. KB4472027). Без применения этого обновления SHA-2, начиная с июля 2019 года, WSUS 3.0 SP2 (также называемый WSUS 3.2) не сможет выполнить необходимые задачи обновления WSUS. Начиная с WSUS 4.0 в Windows Server 2012, WSUS уже поддерживает обновления с подписью SHA-2 и не требуется никаких действий со стороны клиентов. Это обновление необходимо для тех клиентов, которые все еще используют WSUS 3.0 SP2. Мы рекомендуем обновление до последней версии WSUS, версия 10.0.
Добавление поддержки SHA-2 не добавляет поддержку обновлений функций Windows 10 на WSUS 3.0 SP2.
Предварительные условия
Ежемесячная свертка Windows выпущена 12 марта 2019 года или позже, например,
KB4489880 или более высокая свертка для Windows Server 2008 SP2 установлена.
KB4489878 или более высокая свертка для Windows Server 2008 R2 SP1 установлена.
Мы рекомендуем вам совершить резервное копирование базы данных WSUS перед установкой
Синхронизация иерархии WSUS после успешной установки патча
Мы рекомендуем синхронизировать все серверы WSUS в вашей среде после применения этого обновления. Если у вас есть иерархия серверов WSUS, примените это обновление и синхронизируйте свои серверы с верхней частью иерархии.
Чтобы синхронизировать серверы таким образом, следуйте шагам ниже
Примените обновление к серверу WSUS, который синхронизируется с обновлением Microsoft.
Подождите успешного окончания синхронизации.
Повторите эти действия для каждого сервера WSUS, который синхронизируется с только что обновленным сервером.
Известные проблемы
Отмена установки данного через MSI обновления не поддерживается. Корпорация Майкрософт рекомендует проводить проверки в непроизводственной среде.
Удаленным администраторам Microsoft SQL Server следует загрузить и установить обновление, используя учетную запись с разрешениями администратора SQL Server. Установка WSUS3.0 SP2 с использованием удаленного сервера SQL всегда требует ручной установки этого обновления.
Вы можете столкнуться с сообщением об ошибке при тестировании локальной функции публикации. В журнале событий WSUS может появиться следующая запись об ошибке, “PublishPackage(): В ходе операции произошла ошибка: Не удалось подписать пакет; ошибка: 2147942527”.
Если вы обнаружите эту ошибку в журнале, то вы не установили применимые необходимые компоненты операционной системы Windows (KB4489878 или KB44898878). Пожалуйста, установите обновление необходимых компонентов, применимое к вашей версии Windows, и попробуйте снова провести тестирование.
После установки этого обновления загрузка содержимого может прерваться, если WSUS настроен на загрузку файлов экспресс-установки. Вы можете получить следующее обновление в SoftwareDistribution.log, «Информация WsusService.23 CabUtilities.CheckCertificateSignature Проверка сертификата файла не удалась для * \WsusContent\*\*.psf с 2148098064.”
Чтобы устранить эту проблему, установите перевыпущенную 9 сентября 2019 года версию (KB4484071) обновления для системы безопасности Чтобы убедиться, что у вас установлена последняя версия, перейдите на %windir%\system32\psfsip.dll и убедитесь, что это версия 7.6.7600.324.
Теперь файлы psf должны загружаться локально, когда загрузка файлов экспресс-установки настроена на сервере WSUS.
Получение обновления
Метод 1. Центр обновления Windows
Это обновление будет загружено и установлено автоматически.
Примечание. Это обновление также доступно через Windows Server Update Services (WSUS).
Способ 2. Каталог Центра обновления Майкрософт
Чтобы получить изолированный пакет для этого обновления, перейдите на веб-сайт каталога Центра обновления Майкрософт.
Ссылки
Ознакомьтесь с терминологией, используемой для описания обновлений программных продуктов Майкрософт.
Пошагово объясняем, как работает алгоритм хеширования SHA-2 (SHA-256)
Пошагово объясняем, как работает алгоритм хеширования SHA-2 (SHA-256)
Автор Мария Багулина
SHA-2 (Secure Hash Algorithm 2) — одно из самых популярных семейств алгоритмов хеширования. В этой статье мы разберём каждый шаг алгоритма SHA-256, принадлежащего к SHA-2, и покажем, как он работает на реальном примере.
Что такое хеш-функция?
Если вы хотите узнать больше о хеш-функциях, можете почитать Википедию. Но чтобы понять, о чём пойдёт речь, давайте вспомним три основные цели хеш-функции:
SHA-2 и SHA-256
SHA-2 — это семейство алгоритмов с общей идеей хеширования данных. SHA-256 устанавливает дополнительные константы, которые определяют поведение алгоритма SHA-2. Одной из таких констант является размер вывода. «256» и «512» относятся к соответствующим размерам выходных данных в битах.
Мы рассмотрим пример работы SHA-256.
SHA-256 «hello world». Шаг 1. Предварительная обработка
1. Преобразуем «hello world» в двоичный вид:
2. Добавим одну единицу:
3. Заполняем нулями до тех пор, пока данные не станут кратны 512 без последних 64 бит (в нашем случае 448 бит):
4. Добавим 64 бита в конец, где 64 бита — целое число с порядком байтов big-endian, обозначающее длину входных данных в двоичном виде. В нашем случае 88, в двоичном виде — «1011000».
Теперь у нас есть ввод, который всегда будет без остатка делиться на 512.
Шаг 2. Инициализация значений хеша (h)
Создадим 8 значений хеша. Это константы, представляющие первые 32 бита дробных частей квадратных корней первых 8 простых чисел: 2, 3, 5, 7, 11, 13, 17, 19.
Шаг 3. Инициализация округлённых констант (k)
Создадим ещё немного констант, на этот раз их 64. Каждое значение — это первые 32 бита дробных частей кубических корней первых 64 простых чисел (2–311).
Шаг 4. Основной цикл
Шаг 5. Создаём очередь сообщений (w)
1. Копируем входные данные из шага 1 в новый массив, где каждая запись является 32-битным словом:
2. Добавляем ещё 48 слов, инициализированных нулями, чтобы получить массив w[0…63] :
3. Изменяем нулевые индексы в конце массива, используя следующий алгоритм:
Давайте посмотрим, как это работает для w[16] :
Это оставляет нам 64 слова в нашей очереди сообщений ( w ):
Шаг 6. Цикл сжатия
Давайте пройдём первую итерацию. Сложение рассчитывается по модулю 2^32:
Шаг 7. Изменяем окончательные значения
Шаг 8. Получаем финальный хеш
И последний важный шаг — собираем всё вместе.
Готово! Мы выполнили каждый шаг SHA-2 (SHA-256) (без некоторых итераций).
Алгоритм SHA-2 в виде псевдокода
Если вы хотите посмотреть на все шаги, которые мы только что сделали, в виде псевдокода, то вот пример:
Хинт для программистов: если зарегистрируетесь на соревнования Huawei Cup, то бесплатно получите доступ к онлайн-школе для участников. Можно прокачаться по разным навыкам и выиграть призы в самом соревновании.
Перейти к регистрации
Как и зачем переходить с SHA-1 на SHA-2 и почему это важно
Индустрия инфраструктуры открытых ключей (ИОК, англ. PKI — Public Key Infrastructure) рекомендует, чтобы любой объект инфраструктуры, использующий SHA-1, был переведён на более безопасный SHA-2. В этой статье описано, почему и как стоит это сделать.
В 2016 году миграция на SHA-2 была хорошей подготовкой к всеобщему дедлайну, сейчас же этот переход обязателен для обеспечения безопасности. Многие устройства и приложения, использующие электронные сертификаты, уже сейчас выводят предупреждения или ошибки или отказываются работать, если сертификат использует алгоритмы хеширования SHA-1 или старше. Зачем эти принудительные изменения? Потому что в хеше SHA-1 обнаружены серьёзные криптографические уязвимости, и дни, когда его защита ещё надёжна, уже сочтены.
Вплоть до 2017 года SHA-1 был самым популярным хешем, используемым для криптографической подписи, и некоторые, в особенности старые, приложения и устройства не принимали или не понимали хеши или сертификаты, основанные на алгоритме SHA-2. Это было основной проблемой перехода на новый стандарт.
Что такое хеш?
Криптографическая хеш-функция — это математический алгоритм, преобразующий любое уникальное сообщение (текст, видео, аудио, изображение и т. д.) в уникальную комбинацию, которую чаще всего называют «хешем» или «хеш-кодом». Два разных сообщения ни в коем случае не должны преобразовываться в одинаковый хеш, а два идентичных сообщения всегда должны возвращать один и тот же хеш. Благодаря этим свойствам хеш-код может использоваться для сравнения двух различных сообщений на идентичность. Криптографические хеши являются основой для практически любой цифровой аутентификации и проверки целостности файла.
Службы центра сертификации (ЦС) ИОК используют криптографические хеш-функции для подтверждения идентификационных данных и запросов цифровых сертификатов. Кроме этого, хеши используются для подтверждения цифровых сертификатов (например, цифровой подписью) и списка аннулированных сертификатов (CRL, certificate revocation list), которые выдают другие доверенные стороны. Доверенные стороны не смогут полагаться на достоверность цифровых сертификатов и другого контента, подписанного ЦС, если службы ИОК используют ненадёжный криптографический хеш. Стойкость криптографического хеша создаёт доверие ко всей системе ИОК.
Примечание: контрольные суммы — это хеш-подобные верификаторы, но без криптографических доказательств, подтверждающих, что они обеспечивают статистически уникальные результаты для уникальных входных сообщений.
В общем, криптографические хеши считаются более безопасными, чем контрольные суммы, хотя последние часто используются для некритических проверок целостности и подлинности.
Атаки на хеши
Стойкость криптографической хеш-функции в том числе обеспечивается тем, что для любого уникального сообщения формируется уникальный хеш. В то же время необходимо, чтобы по одному только хешу нельзя было воспроизвести исходное сообщение. На попытке обойти это свойство строится атака нахождения прообраза. Кроме того, два разных сообщения ни в коем случае не должны преобразовываться в одинаковые хеши, иначе возникнет явление, которое называется коллизией. На этом явлении основывается атака «дней рождения».
Общепринятые криптографические хеш-функции изначально считаются криптографически стойкими, но со временем злоумышленники находят математические уловки, ослабляющие их защиту.
Вычислительная сложность криптостойкого хеша равна заявленной эффективной длине последовательности бит минус 1. Таким образом, когда неизвестны его недостатки, 128-битный хеш будет иметь сложность вычисления 2^127. Как только кто-то найдёт математический алгоритм, который позволит взломать хеш за время меньшее, чем эффективная длина бит минус 1, такой хеш будет считаться ослабленным. Как правило, все общепринятые хеши становятся слабее со временем. Когда эффективная длина бит сокращается, хеш становится менее защищённым и менее ценным. Когда считается, что хеш может быть взломан за разумный период времени и с не столь значительными вычислительными ресурсами (стоимостью от сотен тысяч до миллионов долларов), то хеш считается «взломанным» и не должен больше использоваться. Взломанные хеши используются вредоносными программами и злоумышленниками для создания якобы законного программного обеспечения с цифровой подписью. Хороший пример такого ПО — Flame malware program. В общем, слабые хеши могут сыграть свою роль и не должны использоваться.
Введение в семейство 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
Все крупные поставщики веб-браузеров (например, Microsoft, Google, Mozilla, Apple) и другие доверенные стороны рекомендовали всем клиентам, сервисам и продуктам, в настоящее время использующим SHA-1, перейти на SHA-2, хотя что и когда должно перейти зависит от поставщика. Например, многие поставщики заботятся только о сертификатах TLS (т. е. веб-серверах), и только компания Microsoft озабочена использованием SHA-1 в цифровом сертификате от «публичного» центра сертификации. Но можно ожидать, что все поставщики потребуют перевести на SHA-2 все приложения и устройства, даже если они не готовы к этому. Сейчас большинство браузеров покажет сообщение об ошибке, если на веб-сайте используется публичный цифровой сертификат, подписанный SHA-1, но некоторые из них позволят вам обойти всплывающее окно и перейти на такой сайт. Возможно, в скором времени, все главные поставщики браузеров запретят обход сообщений об ошибке и переходы на сайты, использующие цифровые сертификаты 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-2. Затем соберите команду людей, которые протестируют, работает ли SHA-2. Можно предварительно полагаться на информацию от поставщиков, но вы не будете знать наверняка пока не проверите самостоятельно.
Обновление приложений и устройств — задача не из лёгких, и потребует больше времени, чем кажется. Даже сейчас существует множество устройств и приложений, использующих старые версии OpenSSL, которые следовало бы обновить после атаки Heartbleed, но администраторы серверов этого так и не сделали.
Если у вас есть внутренняя ИОК, вам понадобится подготовить её к переходу на SHA-2. Иногда это означает обновление ваших центров сертификации, получение новых сертификатов или установку полностью новых ИОК. Последнее рекомендуется по множеству причин, в основном потому, что новая ИОК даст вам шанс начать сначала без груза старых ошибок.
Модели перехода ИОК
Ниже перечислены сценарии для внедрения SHA-2 в компоненты ИОК (для этих примеров используется двухуровневая ИОК — автономная корневая система, онлайн центры сертификации), каждый из которых может быть либо новым компонентом, либо перенесённым:
Остальные сценарии предполагают одно дерево ИОК:
Также возможно существование выдающего центра сертификации, который переключается между 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.
Хинт для программистов: если зарегистрируетесь на соревнования Huawei Cup, то бесплатно получите доступ к онлайн-школе для участников. Можно прокачаться по разным навыкам и выиграть призы в самом соревновании.
Перейти к регистрации
Требования к поддержке подписи кода SHA-2 2019 для Windows и WSUS
Аннотация
Для защиты безопасности операционной системы 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. Имейте в виду, что может измениться следующая временная шкала. Мы продолжим обновлять эту страницу по мере необходимости.
Автономные обновления для системы безопасности KB4474419 и KB4490628, выпускаются для поддержки подписи кода SHA-2.
Windows 7 с sp1
Windows Server 2008 R2 SP1
Отдельное обновление KB4484071 доступно в каталоге Обновлений Windows для WSUS 3.0 с sp2, который поддерживает доставку подписанных обновлений SHA-2. Для пользователей WSUS 3.0 с sp2 это обновление должно быть установлено вручную не позднее 18 июня 2019 г.
Отдельное обновление KB4493730, в которое вводится поддержка подписи кода SHA-2 для стека обслуживания (SSU), выпущено в обновлении для системы безопасности.
Windows Server 2008 с пакетом обновления 2 (SP2)
Отдельное обновление для системы безопасности KB4474419, выпущенное для поддержки подписи кода SHA-2.
Windows Server 2008 с пакетом обновления 2 (SP2)
Отдельное обновление для системы безопасности KB4474419было выпущено повторно, чтобы добавить отсутствующие знаки кода MSI SHA-2.
Windows Server 2008 с пакетом обновления 2 (SP2)
В Windows 10 подписи, измененные с двух подписей (SHA-1/SHA-2) на SHA-2, изменены. Действия клиента не требуются.
Windows 10 версии 1709
Windows 10 версии 1803
Windows 10 версии 1809
Windows Server 2019
Обязательно: Для клиентов, использующих WSUS 3.0 с sp2, для поддержки обновлений SHA-2 к этой дате необходимо вручную установить KB4484071.
Обязательно: Для обновления устаревших версий Windows потребуется установить поддержку подписи кода SHA-2. Поддержка, выпущенная в апреле и мае(KB4493730 и KB4474419),потребуется для продолжения получения обновлений для этих версий Windows.
В настоящее время все устаревшие подписи Обновлений Windows изменились с SHA1 и на SHA-2 с двойной подписью (SHA-1/SHA-2) на SHA-2.
Windows Server 2008 с пакетом обновления 2 (SP2)
В Windows 10 подписи, измененные с двух подписей (SHA-1/SHA-2) на SHA-2, изменены. Действия клиента не требуются.
Windows 10 версии 1507
Windows 10 версии 1607
Windows Server 2016
Windows 10 версии 1703
Обязательно: Для обновления устаревших версий 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
Подписи в списках доверия сертификата (CTLS) для надежной корневой программы Майкрософт изменены с двух подписей (SHA-1/SHA-2) на SHA-2. Действия клиента не требуются.
Все поддерживаемые платформы Windows
Конечные точки службы на базе 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
Корпорация Майкрософт удалила из Центра загрузки Майкрософт содержимое, подписанное на 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.
Важно!После установки всех необходимых обновлений необходимо перезапустить устройство перед установкой ежемесячных обновлений, обновлений только для системы безопасности, предварительной версии monthly Rollup или автономных обновлений.
Вопросы и ответы
Общие сведения, планирование и предотвращение проблем
Поддержка подписи кода SHA-2 была отправлена раньше, чтобы гарантировать, что большинству клиентов будет достаточно поддержки до того, как корпорация Майкрософт обновит SHA-2 для обновления этих систем. Отдельные обновления содержат некоторые дополнительные исправления, которые в настоящее время доступны для того, чтобы гарантировать, что все обновления SHA-2 входят в небольшое количество легко познаваемых обновлений. Корпорация Майкрософт рекомендует клиентам, которые сохраняют системные изображения для этих OSes, применять эти обновления к изображениям.
Начиная с WSUS 4.0 в Windows Server 2012, WSUS уже поддерживает обновления SHA-2, подписанные, и для этих версий не требуется никаких действий со стороны клиента.
Только для WSUS 3.0 SP2 требуется установить KB4484071для поддержки только подписанных обновлений SHA2.
Предположим, что вы запустите 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.
Как и в случае с двумя загрузками, необходимо обновить среду PE для Windows 7 до поддержки SHA-2. Затем необходимо обновить систему Windows Server 2008 с sp2 до поддержки SHA-2.
Запустите установку Windows для завершения и загрузки в Windows до установки обновлений от 13 августа 2019 г. или более поздней версии
Откройте окно командной подсказки администратора и запустите bcdboot.exe. При этом файлы загрузки копируется из каталога Windows и настраивается среда загрузки. Дополнительные сведения см. в Command-Line параметрах bcDBoot.
Перед установкой дополнительных обновлений установите выпуск KB4474419 и KB4490628 для Windows 7 с sp1 и Windows Server 2008 R2 с sp1 от 1 августа 2019 г.
Перезапустите операционную систему. Требуется перезапуск
Установите все оставшиеся обновления.
Установите изображение на диск и загрузите его в Windows.
В командной области запустите bcdboot.exe. При этом файлы загрузки копируется из каталога Windows и настраивается среда загрузки. Дополнительные сведения см. в Command-Line параметрах bcDBoot.
Перед установкой дополнительных обновлений установите повторное обновление KB4474419 и KB4490628 для Windows 7 с SP1 и Windows Server 2008 R2 с sp1 от 23 сентября 2019 г.
Перезапустите операционную систему. Требуется перезапуск
Установите все оставшиеся обновления.
Да, необходимо установить необходимые обновления, прежде чем продолжите:SSU (KB4490628)и SHA-2(KB4474419). Кроме того, после установки необходимых обновлений необходимо перезапустить устройство.
Windows 10 версии 1903 поддерживает SHA-2 с момента выпуска, а все обновления УЖЕ подписаны только на SHA-2. Для этой версии Windows не требуется никаких действий.
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 г.
Перезапустите операционную систему. Требуется перезапуск
Установите все оставшиеся обновления.
Проблема с восстановлением
Если вы видите сообщение об ошибке 0xc0000428 «Windows не удается проверить цифровую подпись для этого файла. В результате недавнего изменения оборудования или программного обеспечения мог быть установлен неправильно подписанный или поврежденный файл либо вредоносный программный продукт из неизвестных источников». выполните эти действия, чтобы восстановить данные.
Запустите операционную систему с помощью мультимедиа для восстановления.
Перед установкой дополнительных обновлений установите обновление KB4474419 от 23 сентября 2019 г. или более поздней с помощью системы обслуживания и управления образами развертывания(DISM)для Windows 7 с sp1 и Windows Server 2008 R2 с sp1.
В командной области запустите bcdboot.exe. При этом файлы загрузки копируется из каталога Windows и настраивается среда загрузки. Дополнительные сведения см. в Command-Line параметрах bcDBoot.
Перезапустите операционную систему.
Приостановка развертывания на других устройствах без перезапуска еще не перезапуска каких-либо устройств или ВМ-м.
Определение устройств и ВМ-устройств в состоянии ожидания перезагрузки с помощью обновлений, выпущенных 13 августа 2019 г. или более поздней версии, и открытия командной подсказки с повышенными уровнями
Найдите удостоверение пакета для обновления, которое вы хотите удалить, с помощью следующей команды, используя KB-номер для этого обновления (замените 4512506 на целевой номер KB, если он не выпущен 13 августа 2019 г.): dism /online /get-packages | findstr 4512506
Чтобы удалить обновление, заменив удостоверение пакета с помощью предыдущей команды, воспользуйтесь следующей командой: Dism.exe /online /remove-package /packagename:
Теперь вам потребуется установить необходимые обновления, перечисленные в разделе «Как получить это обновление» обновления, который вы пытаетесь установить, или необходимые обновления, перечисленные выше в разделе «Текущее состояние» этой статьи.
Примечание.Для любого устройства или VM, на которое вы сейчас получаете 0xc0000428 или который начинает работать в среде восстановления, необходимо будет предпринять действия, которые необходимо предпринять, чтобы 0xc0000428.
Если вы столкнулись с этими ошибками, вам необходимо установить необходимые обновления, перечисленные в разделе «Как получить обновление» обновления, который вы пытаетесь установить, или необходимые обновления, перечисленные выше в разделе «Текущее состояние» этой статьи.
Если вы видите сообщение об ошибке 0xc0000428 «Windows не удается проверить цифровую подпись для этого файла. В результате недавнего изменения оборудования или программного обеспечения мог быть установлен неправильно подписанный или поврежденный файл либо вредоносный программный продукт из неизвестных источников». выполните эти действия, чтобы восстановить данные.
Запустите операционную систему с помощью мультимедиа для восстановления.
Установите последнее обновление SHA-2(KB4474419),выпущенное 13 августа 2019 г., с помощью системы обслуживания изображений развертывания(DISM)для Windows 7 с SP1 и Windows Server 2008 R2 с sp1.
Перезагружается в восстановленный носитель. Требуется перезапуск
В командной области запустите bcdboot.exe. При этом файлы загрузки копируется из каталога Windows и настраивается среда загрузки. Дополнительные сведения см. в Command-Line параметрах bcDBoot.
Перезапустите операционную систему.
Если вы столкнулись с этой проблемой, вы можете устранить эту проблему, открыв окно командной подсказки и выдав следующую команду, чтобы установить обновление (замените место на фактическое расположение и имя файла обновления):
Эта проблема устранена в выпуске KB4474419 от 8 октября 2019 г. Это обновление будет автоматически устанавливаться из Windows Update и WSUS cлужбы Windows Server Update Services (WSUS). Если вам нужно установить это обновление вручную, необходимо использовать вышеуказанное обходное решение.
Примечание.Если вы ранее установили KB4474419, выпущенный 23 сентября 2019 г., то у вас уже есть последняя версия этого обновления, и вам не нужно переустановить ее.
