У нелюбви к Microsoft есть масса источников - надуманных и не очень. И далеко не последнее место среди них занимает страх перед призраком Большого Брата, то и дело выглядывающим из-за плеча CEO компании, скромно стоящего на обочине дороги в будущее.

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

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

В последний раз таким поводом стали исследования Andrew Fernandes'а из канадской компании Cryptonym, касающиеся "секретного ключа" в Windows.

Чтобы было понятно, о чем именно идет речь, соверим небольшой экскурс в архитектуру Microsoft CryptoAPI.

Основное назначение этой подсистемы, как понятно из названия - предоставить Win32-приложениям средства для работы с криптографическими средствами: шифрованием и цифровой подписью сообщений, выдачей и проверкой сертификатов, ключей и т.п. Причем базовые криптографические функции реализованы в виде отдельных модулей, получивших название Cryptographic Service Providers (CSP). Помимо стандартных CSP, поставляемых Microsoft, аналогичный модуль может подготовить и сторонний разработчик, после чего он должен быть сертифицирован Microsoft и подписан цифровой подписью. В начале работы с CryptoAPI программист вызывает функцию CryptAcquireContext, сообщая ей, с каким CSP он планирует работать, и после его загрузки его функции доступны программисту. Во время работы CryptoAPI периодически проверяет цифровую подпись CSP, чтобы исключить возможность его подмены. Вот вокруг этой цифровой подписи все и закрутилось.

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

Таким образом, для проверки цифровой подписи необходимо знать открытый ключ. И такой ключ включает в себя и CryptoAPI. А если быть совсем точным, то не один, а два ключа. По утверждению Microsoft, второй ключ является резервным - на тот случай, если в Рэдмонде случится некая локальная катастрофа и первичный ключ будет утерян. На самом деле, это довольно идиотское решение - проверять подлинность подписи по любому из двух существующих ключей, поскольку это открывает широкие возможности для подделки одного из них, - по словам Брюса Шнейера, "It's stupid cryptography, but the sort of thing you'd expect out of Microsoft". Но шум поднялся совсем из-за этого.

События развивались следующим образом: в вышедшем Service Pack 5 для NT4 из модулей CryptoAPI не была удалена символьная информация (в общем-то то еще разгильдяйство), в результате чего глазам исследователей открылись имена переменных, хранящих эти ключи. И если первичный ключ имел вполне безобидное имя _KEY, то второй - о ужас - назывался _NSAKEY, что уж больно нехорошо стыковалось с аббревиатурой NSA (National Security Agency). В результате немедленно был сделан вывод о том, что наш маленький Большой Брат подружился с большим Большим Братом, заведя для него специальный второй ключик, о чем и было доложено всему свету, обрастая по пути дополнительными подробностями типа возможного проникновения федеральных агентов в любой компьютер, удаленного запуска программ-"закладок" и т.п.

Следует отметить, что эти громкие выводы были сделаны лишь на основе имени переменной, специально подчеркивалось, что исследователи не занимались reverse engineering (ну что ж поделать, страх перед дизассемблированием у них, видимо, уже в крови). Причем самое забавное, что файлы с символьной информацией совершенно открыто лежат на оригинальных компактах с NT (указанные переменные присутствуют в файле \SUPPORT\DEBUG\I386\SYMBOLS\DLL\ADVAPI32.DBG) и доступны всем желающим без подобных игр в сыщиков/воров.

Что касается версии о специальном ключе для NSA - она выглядит совсем неубедительной. В конце концов, гораздо проще было просто поделиться с ними своим первым ключом, чем так подставляться на ровном месте. Гораздо более неприятным является тот факт, что значение _NSAKEY может быть заменено на любое другое, что дает возможность любому разработчику CSP подписать его своим ключом и использовать, минуя контроль Microsoft. Правда, единственное назначение этих ключей - лишь проверка подлинности CSP, а чтобы воспользоваться результатами подделки CSP, его еще надо установить в систему, что в общем случае далеко не так просто.

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

Дополнительные ссылки:

• Тимофей Лирин. Билл Гейтс - Чингисхан сегодня
• Дмитрий Симаненков, Страшные сказки о безопасности Windows и Интернет
• Первоначальное сообщение от Cryptonim
• Duncan Campbell. How NSA access was built into Windows
• Официальная реакция Microsoft
• Комментарий Брюса Шнейера, Counterpane Internet Security, Inc