Microsoft настоятелно призовава организацията да подготвят своите сертификатни системи за постквантова автентификация, като предупреждава, че инфраструктурата с публичен ключ (PKI), хардуерните модули за сигурност (HSM) и устройствата за сигурност се нуждаят от тестване преди внедряване.
Указанията на компанията от 8 октомври гласят, че преходът ще засегне приложенията, устройствата, сертификатните вериги и процесите, които поддържат функционирането на дигиталното доверие. Посланието надхвърля рамките на защитата на шифрования трафик.
Въпреки че много планове за квантова сигурност са фокусирани върху това атакуващите да събират данни сега, за да ги дешифрират по-късно, автентификацията зависи от издаването, съхранението, проверката, подновяването и управлението на сертификати и частни ключове от различни доставчици. Промяната на базовите алгоритми може да разкрие пропуски в цялата тази верига.
От Microsoft Security Research отбелязват, че организациите често знаят къде TLS защитава комуникациите, но нямат пълна представа за зависимостта от сертификати. Техният доклад засяга готовността на инфраструктурата, а не новооткрита кампания със зловреден код.
Постквантова автентификация
Основното предизвикателство не е просто намирането на устойчив на квантови атаки алгоритъм. Бизнесът трябва да установи дали съществуващите му системи могат да използват надеждно нови сертификати.
По-старите PKI внедрявания, вградените устройства, операционните технологии (OT), потребителските приложения и услугите на трети страни могат да съдържат фиксирани предположения, които стават видими едва по време на тестване.
По-големите постквантови сертификати и сертификатни вериги могат да засегнат настройката на връзката, съхранението, предаването и ограниченията за проверка на мрежовия трафик.
Свързаната работа по постквантовия удостоверителен орган на Cloudflare показва защо размерът на сертификата и скоростта на връзката са от значение, докато доставчиците проучват различни дизайни за квантово-безопасна автентификация.
Тези усилия не отменят необходимостта от индивидуално тестване на корпоративните системи. Ето защо доставчиците на HSM и устройства за сигурност трябва да участват в дискусията за миграция от самото начало.
Екипите трябва да проверят дали хардуерно поддържаните системи отговарят на бъдещите изисквания за сертификати и дали инструментите за мониторинг, инспекция и управление на сертификати могат да обработват получения трафик. Поддръжката в едно приложение не означава готовност в цялата среда.
PQC TLS пилотната програма на Microsoft
Microsoft стартира своята пилотна програма за постквантова криптография Post-Quantum Cryptography TLS Pilot Program на 27 август 2026 г. Тя позволява на одобрени удостоверителни органи в добро състояние с Microsoft Trusted Root Program да тестват коренни сертификати (root certificates) и издаване чрез ML-DSA-87 – устойчив на квантови атаки алгоритъм за цифров подпис.
Фокусът е върху съвместимостта, производителността и ежедневните операции. Версията от август добави седем пилотни коренни сертификата, управлявани от ComSign, DigiCert, HARICA, IdenTrust Services, Sectigo, Shanghai Electronic Certification Authority и SSL.com.
Приемът продължава до края на 2026 г. Публикуваните от Microsoft указания за готовност за автентификация пренасочват отговарящите на изискванията доставчици към портала Trusted Root Program за изисквания и кандидатстване.
Тези сертификати не са публично доверени. Microsoft ограничава тяхната употреба до затворени среди, потребителски приложения и корпоративни тестови среди, като изрично изключва производствено доверие и публични уебсайтове.
На друго място, пътната карта за сертификати на Let’s Encrypt изследва Merkle Tree Certificates за автентификация в публичния уеб, подчертавайки, че отделни усилия се адресират към различни части от прехода.
На поддържани и правилно конфигурирани системи с Windows 11, пилотното тестване започва с актуализациите от 28 юли 2026 г. Microsoft посочва KB5101681, OS Build 28000.2608 за 26H1, и KB5101684, OS Builds 26200.8973 и 26100.8973 за 25H2.
ML-DSA сертификатите могат да работят и със Secure Channel (Schannel) при поддържани сценарии. Администраторите трябва да потвърдят изискванията на платформата преди тестване.
Готовността на софтуера и хардуера трябва да се проверява отделно. По-ранни публикации относно квантово-безопасните цифрови подписи на Google описват софтуерна поддръжка за Cloud KMS, като хардуерната поддръжка се планира отделно.
Microsoft по подобен начин призовава организациите да запитат своите доставчици на сертификати, HSM, софтуер и платформи относно техните пътни карти и възможности за тестване, вместо да предполагат универсална поддръжка.
Екипите по сигурност трябва да инвентаризират системите, зависещи от сертификати, да картират отношенията на публично и частно доверие и да идентифицират оборудване с дълги цикли на обновяване.
Тестовете извън производствената среда трябва да покриват съвместимостта, производителността и оперативните работни процеси. Разработки като подобренията в производителността на постквантовата криптография в OpenSSL предоставят полезен контекст за тестване, но предварителният софтуер и пилотните сертификати на Microsoft не трябва да се третират като готови за производство заместители.
Тази работа трябва да обхване пълния жизнен цикъл на сертификата, а не само успешното осъществяване на връзка. Издаването, разпространението, валидирането, подновяването и управлението зависят от свързани системи.
Тестването на тези стъпки заедно помага на екипите да открият пропуски в процесите, които самостоятелен тест на алгоритъм би могъл да пропусне, преди те да засегнат реални бизнес услуги.
Microsoft препоръчва многогодишна програма с определени отговорници, ясни зависимости и приоритети за модернизация, базирани на резултатите от тестовете.
Организациите могат да попитат своя доставчик на сертификати дали участва в пилотната програма и дали предлага подходящо тестване. Практическата цел е да се открият съответните неизправности, преди постквантовата автентификация да се превърне в масово изискване за внедряване.
Индикатори за компрометиране (IoCs):-
| Категория индикатор | Находка от източника |
|---|---|
| SHA-256, SHA-1, MD5 хешове | Не са докладвани |
| Зловредни домейни | Не са докладвани |
| Зловредни IP адреси | Не са докладвани |
| URL адреси на атаки | Не са докладвани |
Забележка: IP адресите и домейните са нарочно дезактивирани (напр. [.]), за да се предотврати случайното им разрешаване или появата на хипервръзки. Възстановете оригиналния им вид само в рамките на контролирани платформи за анализ на заплахи (threat intelligence) като MISP, VirusTotal или вашата SIEM система.