_НСАКЕЙ
_NSAKEY — имя переменной , обнаруженное в Windows NT 4 SP5 в 1999 году Эндрю Д. Фернандесом из Cryptonym Corporation. Переменная содержала 1024-битный открытый ключ; такие ключи используются в криптографии с открытым ключом для шифрования и аутентификации . Однако из-за названия предполагалось, что ключ позволит Агентству национальной безопасности США (АНБ) подорвать безопасность любого пользователя Windows. Microsoft опровергла эти предположения и заявила, что название ключа связано с тем, что АНБ было органом технической проверки контроля за экспортом криптографии в США .
Обзор
[ редактировать ]Microsoft требует, чтобы все наборы криптографии , взаимодействующие с Microsoft Windows, имели цифровую подпись RSA . Поскольку с Windows могут поставляться только одобренные Microsoft наборы криптографии, можно хранить экспортные копии этой операционной системы в соответствии с Правилами экспортного администрирования (EAR), которые применяются Бюро промышленности и безопасности (BIS). [1]
Уже было известно, что Microsoft использовала два ключа: основной и запасной, каждый из которых может создавать действительные подписи. Выпустив пакет обновления 5 для Windows NT 4 , Microsoft пренебрегла удалением символов отладки из ADVAPI32.DLL , библиотеки, используемой для расширенных функций Windows, таких как реестр и безопасность. Эндрю Фернандес, главный научный сотрудник Cryptonym, обнаружил первичный ключ, хранящийся в переменной. _KEY и второй ключ был помечен _НСАКЕЙ . [2] Фернандес опубликовал свое открытие, вызвав шквал спекуляций и теорий заговора , включая возможность того, что второй ключ принадлежал Агентству национальной безопасности США (АНБ) и позволял разведывательному агентству подорвать безопасность любого пользователя Windows. [3]
Во время презентации на конференции «Компьютеры, свобода и конфиденциальность 2000» (CFP2000) Дункан Кэмпбелл , старший научный сотрудник Информационного центра электронной конфиденциальности (EPIC), упомянул Противоречие _NSAKEY как пример нерешенной проблемы, связанной с безопасностью и наблюдением. [ нужна ссылка ]
Кроме того, доктор Нико ван Сомерен обнаружил в Windows 2000 третий ключ, который, как он сомневался, имел законное назначение, и заявил, что «он выглядит более подозрительно». [4]
Реакция Microsoft
[ редактировать ]Microsoft опровергла бэкдоре спекуляции о _NSAKEY и сказал: «Это предположение иронично, поскольку Microsoft последовательно выступает против различных предложений по условному депонированию ключей, предложенных правительством». По словам Microsoft, символ ключа был « _NSAKEY », поскольку АНБ было органом технической проверки контроля за экспортом криптографии в США , а ключ обеспечивал соответствие законам США об экспорте. [5] [6]
Ричард Перселл, директор Microsoft по корпоративной конфиденциальности, подошел к Кэмпбеллу после его презентации и выразил желание прояснить путаницу и сомнения по поводу _НСАКЕЙ . Сразу после конференции Скотт Калп из Центра реагирования на проблемы безопасности Microsoft связался с Кэмпбеллом и предложил ответить на его вопросы. Их переписка началась сердечно, но вскоре стала напряжённой; Кэмпбелл, очевидно, чувствовал, что Калп уклончив, а Калп, очевидно, чувствовал, что Кэмпбелл враждебно повторяет вопросы, на которые он уже ответил. 28 апреля 2000 года Калп заявил, что «мы определенно подошли к концу этой дискуссии… [которая] быстро перерастает в сферу теории заговора». [7]
Microsoft утверждала, что третий ключ был только в бета-версиях Windows 2000 и что его назначением было подписание поставщиков криптографических услуг . [6]
Дополнительная техническая информация
[ редактировать ]На странице Mozilla с общими вопросами по криптографии описано, как Microsoft подписывает CSP:
Фактически, при определенных обстоятельствах возможно получить лицензию на экспорт программного обеспечения, вызывающего криптографические функции через API. Например, реализация Microsoft спецификации Microsoft Cryptographic API (CryptoAPI) была одобрена для экспорта из США, хотя она реализует API, с помощью которого третьи стороны, в том числе третьи стороны за пределами США, могут добавлять отдельные модули («Поставщики криптографических услуг»). или CSP), реализующие криптографические функции. Такое разрешение на экспорт, по-видимому, стало возможным потому, что а) реализация CryptoAPI требует, чтобы сторонние CSP были подписаны цифровой подписью Microsoft, и отклоняет попытки вызвать CSP, не подписанные таким образом; б) посредством этого процесса подписания Microsoft может обеспечить соблюдение соответствующих правил экспортного контроля США (например, они предположительно не будут подписывать CSP, разработанный за пределами США, который реализует надежную криптографию); и c) реализация Microsoft CryptoAPI доступна только в исполняемой форме и, таким образом, предполагается, что она достаточно устойчива к вмешательству пользователя с целью отключения проверки цифровой подписи CSP. [8]
Вторую можно было убрать. _NSAKEY: при загрузке криптографического модуля crypto_verify сначала пытается использовать _KEY для проверки модуля, затем переходит к _NSAKEY если первый ключ не работает. Поскольку ни один из известных криптографических модулей в Windows не подписан _NSAKEY, он никогда не привыкнет. Замена ключа другим ключом позволяет компаниям за пределами США устанавливать свои собственные «надежные» криптосервисы в Windows без одобрения Microsoft или АНБ. [2]
Дальнейшие предположения
[ редактировать ]Microsoft заявила, что второй ключ присутствует в качестве резервного, чтобы защититься от возможности потери первичного секретного ключа. Фернандес сомневается в этом объяснении, указывая, что общепринятым способом защиты от потери секретного ключа является разделение секрета , при котором ключ разделяется на несколько разных частей, которые затем распределяются среди высшего руководства. Он заявил, что это будет гораздо надежнее, чем использование двух ключей; если второй ключ также будет утерян, Microsoft придется исправлять или обновлять каждую копию Windows в мире, а также каждый криптографический модуль, который она когда-либо подписывала. [ нужна ссылка ]
С другой стороны, если бы Microsoft не подумала о последствиях потери ключа и создала первый ключ без использования секретного разделения (и сделала это на безопасном оборудовании, которое не позволяет ослабить защиту после генерации ключа), а АНБ указало Если вы решите эту проблему в рамках процесса проверки, это может объяснить, почему Microsoft ослабила свою схему с помощью второго ключа и почему новый был назван _НСАКЕЙ . (Второй ключ может быть зарезервирован с использованием секретного разделения, поэтому потеря обоих ключей не должна быть проблемой.) Другая возможность заключается в том, что Microsoft включила второй ключ, чтобы иметь возможность подписывать криптографические модули за пределами Соединенных Штатов, при этом соблюдая требования BIS. УХО. Если криптографические модули должны быть подписаны в нескольких местах, разумным подходом будет использование нескольких ключей. Однако ни один криптографический модуль не был подписан. _NSAKEY , а Microsoft отрицает существование какого-либо другого центра сертификации. [ нужна ссылка ]
Брюс Шнайер считает, что вышеупомянутые опасения, например, то, что АНБ помещает ключ в Windows, чтобы оно могло загружать произвольные CSP с бэкдором, необоснованны. Он утверждает, что существуют более простые способы взлома Windows, которые не требуют использования дополнительного ключа, не говоря уже о ключе под названием «NSAKEY» в символах отладки, видимых всей компании: АНБ может просто запросить основной ключ. Криптовалютный API также является плохой точкой входа, поскольку он требует от жертвы запуска исполняемого файла, предоставленного АНБ. [9]
PGP-ключи
[ редактировать ]В сентябре 1999 года анонимный исследователь перепроектировал первичный ключ и _NSAKEY в PGP- совместимый формат и опубликовал их на серверах ключей . [10]
Первичный ключ (_KEY)
[ редактировать ]Type Bits/KeyID Date User ID pub 1024/346B5095 1999/09/06 Microsoft's CAPI key <[email protected]> -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.3i mQCPAzfTc8YAAAEEALJz4nepw3XHC7dJPlKws2li6XZiatYJujG+asysEvHz2mwY 2WlRggxFfHtMSJO9FJ3ieaOfbskm01RNs0kfoumvG/gmCzsPut1py9d7KAEpJXEb F8C4d+r32p0C3V+FcoVOXJDpsQz7rq+Lj+HfUEe8GIKaUxSZu/SegCE0a1CVABEB AAG0L01pY3Jvc29mdCdzIENBUEkga2V5IDxwb3N0bWFzdGVyQG1pY3Jvc29mdC5j b20+iQEVAwUQN9Nz5j57yqgoskVRAQFr/gf8DGm1hAxWBmx/0bl4m0metM+IM39J yI5mub0ie1HRLExP7lVJezBTyRryV3tDv6U3OIP+KZDthdXb0fmGU5z+wHt34Uzu xl6Q7m7oB76SKfNaWgosZxqkE5YQrXXGsn3oVZhV6yBALekWtsdVaSmG8+IJNx+n NvMTYRUz+MdrRFcEFDhFntblI8NlQenlX6CcnnfOkdR7ZKyPbVoSXW/Z6q7U9REJ TSjBT0swYbHX+3EVt8n2nwxWb2ouNmnm9H2gYfXHikhXrwtjK2aG/3J7k6EVxS+m Rp+crFOB32sTO1ib2sr7GY7CZUwOpDqRxo8KmQZyhaZqz1x6myurXyw3Tg== =ms8C -----END PGP PUBLIC KEY BLOCK-----
Вторичный ключ (_NSAKEY и _KEY2)
[ редактировать ]Type Bits/KeyID Date User ID pub 1024/51682D1F 1999/09/06 NSA's Microsoft CAPI key <[email protected]> -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.3i mQCPAzfTdH0AAAEEALqOFf7jzRYPtHz5PitNhCYVryPwZZJk2B7cNaJ9OqRQiQoi e1YdpAH/OQh3HSQ/butPnjUZdukPB/0izQmczXHoW5f1Q5rbFy0y1xy2bCbFsYij 4ReQ7QHrMb8nvGZ7OW/YKDCX2LOGnMdRGjSW6CmjK7rW0veqfoypgF1RaC0fABEB AAG0LU5TQSdzIE1pY3Jvc29mdCBDQVBJIGtleSA8cG9zdG1hc3RlckBuc2EuZ292 PokBFQMFEDfTdJE+e8qoKLJFUQEBHnsH/ihUe7oq6DhU1dJjvXWcYw6p1iW+0euR YfZjwpzPotQ8m5rC7FrJDUbgqQjoFDr++zN9kD9bjNPVUx/ZjCvSFTNu/5X1qn1r it7IHU/6Aem1h4Bs6KE5MPpjKRxRkqQjbW4f0cgXg6+LV+V9cNMylZHRef3PZCQa 5DOI5crQ0IWyjQCt9br07BL9C3X5WHNNRsRIr9WiVfPK8eyxhNYl/NiH2GzXYbNe UWjaS2KuJNVvozjxGymcnNTwJltZK4RLZxo05FW2InJbtEfMc+m823vVltm9l/f+ n2iYBAaDs6I/0v2AcVKNy19Cjncc3wQZkaiIYqfPZL19kT8vDNGi9uE= =PhHT -----END PGP PUBLIC KEY BLOCK-----
См. также
[ редактировать ]- Lotus Notes - открыто использовал ключ АНБ для соблюдения правил экспорта криптографии.
- Чип клипера
Ссылки
[ редактировать ]- ^ Чаппелл, Джефф (12 сентября 1999 г.). «Подписи CSP» . Архивировано из оригинала 4 мая 2006 года.
- ^ Перейти обратно: а б Фернандес, Эндрю (31 августа 1999 г.). «Майкрософт, АНБ и вы» . cryptonym.com . Криптоним. Архивировано из оригинала 17 июня 2000 года . Проверено 26 октября 2005 г.
- ^ «Ключ АНБ к Windows: вопрос открытый» . CNN онлайн . Кабельная новостная сеть. 5 сентября 1999 г. Архивировано из оригинала 5 октября 2015 г.
- ^ Кэмпбелл, Дункан (4 января 1999 г.). «Как доступ АНБ был встроен в Windows» . Хейзе онлайн . Хайзе Медиен.
- ^ «Microsoft заявляет, что предположения о безопасности и АНБ являются «неточными и необоснованными» » . Центр новостей . Редмонд, Вашингтон: Microsoft . 3 сентября 1999 г. Архивировано из оригинала 24 октября 2012 г.
- ^ Перейти обратно: а б «В Windows нет «Черного хода»» . Майкрософт. 7 сентября 1999 года. Архивировано из оригинала 20 мая 2000 года . Проверено 7 января 2007 г.
- ^ «Спор о Windows NSAKEY» . Университет Райса.
- ^ «Часто задаваемые вопросы по Mozilla Crypto» . Архивировано из оригинала 22 апреля 1999 года . Проверено 12 апреля 2020 г.
- ^ Шнайер, Брюс (15 сентября 1999 г.). «Ключ АНБ в Microsoft Crypto API?» . Столешница . Проверено 7 января 2007 г.
- ^ «Реверс-инжиниринг ключей» . Шифрпространство. 6 сентября 1999 года . Проверено 7 января 2007 г.
