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

Но как помешать утечкам? Шапочка из фольги тут не поможет, хоть это, бесспорно, и красивое решение. Зато поможет тотальное шифрование данных: перехватив или украв зашифрованные файлы, соглядатай ничего в них не поймёт. Сделать это можно, защитив всю свою цифровую активность с помощью стойкой криптографии (стойкими называются шифры, на взлом которых при существующих компьютерных мощностях потребуется время, по крайней мере большее продолжительности жизни человека). Вот 6 практических рецептов, воспользовавшись которыми, вы решите эту задачу.

Зашифруйте активность веб-браузера. Глобальная сеть устроена таким образом, что ваш запрос даже к близко расположенным сайтам (типа yandex.ru) проходит на своём пути через множество компьютеров («узлов»), которые ретранслируют его туда и обратно. Посмотреть примерный их список можно, введя в командной строке команду tracert адрес_сайта. Первым в таком списке будет ваш интернет-провайдер или владелец точки доступа Wi-Fi, через которую вы подключились к интернету. Потом ещё какие-нибудь промежуточные узлы, и только в самом конце сервер, на котором хранится нужный вам сайт. И если ваше соединение не зашифровано, то есть ведётся по обычному протоколу HTTP, каждый, кто находится между вами и сайтом, сможет пересылаемые данные перехватить и проанализировать.

Поэтому сделайте простую вещь: добавьте к «http» в адресной строке символ «s», чтобы адрес сайта начинался с «https://». Таким образом вы включите шифрование трафика (так называемый слой безопасности SSL/TLS). Если сайт поддерживает HTTPS, он позволит это сделать. А чтобы не мучиться каждый раз, поставьте браузерный плагин : он будет принудительно пытаться включить шифрование на каждом посещаемом вами сайте.

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

Зашифруйте свою электронную почту. Письма, отправленные по e-mail, тоже проходят через посредников, прежде чем попасть к адресату. Зашифровав, вы помешаете соглядатаю понять их содержимое. Однако техническое решение тут более сложное: потребуется применить дополнительную программу для шифрования и дешифровки. Классическим решением, не потерявшим актуальности до сих пор, будет пакет OpenPGP или его свободный аналог GPG , либо поддерживающий те же стандарты шифрования плагин для браузера (например, Mailvelope).

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

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

Зашифруйте мгновенные сообщения. Проще всего воспользоваться мессенджерами, которые уже умеют шифровать переписку: Telegram, WhatsApp, Facebook Messenger, Signal Private Messenger, Google Allo, Gliph и т.п. В таком случае от любопытных глаз со стороны вы защищены: если случайный человек и перехватит сообщения, то увидит лишь мешанину символов. Но вот от любопытства компании, которая владеет мессенджером, это вас не оградит: у компаний, как правило, есть ключи, позволяющие читать вашу переписку - и мало того, что они любят это делать сами, они по первому требованию сдадут их правоохранительным органам.

Поэтому лучшим решением будет воспользоваться каким-либо популярным свободным (open source) мессенджером с подключенным плагином для шифрования «на лету» (такой плагин часто называют «OTR»: off the record - препятствующий записи). Хорошим выбором будет Pidgin .

Недостатки : как и в случае с электронной почтой, вы не гарантированы от атаки посредника.

Зашифруйте документы в «облаке». Если вы пользуетесь «облачными» хранилищами вроде Google Drive, Dropbox, OneDrive, iCloud, ваши файлы могут быть украдены кем-то, кто подсмотрит (или подберёт) ваш пароль, либо если обнаружится какая-то уязвимость в самом сервисе. Поэтому прежде, чем поместить что-либо в «облако», зашифруйте это. Реализовать такую схему проще и удобней всего с помощью утилиты, которая создаёт на компьютере папку - помещённые куда документы автоматически шифруются и переправляются на «облачный» диск. Такова, например, Boxcryptor . Чуть менее удобно применить для той же цели приложения типа TrueCrypt - создающие целый шифрованный том, размещаемый в «облаке».

Недостатки : отсутствуют.

Зашифруйте весь (не только браузерный) трафик с вашего компьютера. Может пригодиться, если вы вынуждены пользоваться непроверенным открытым выходом в Сеть - например, незашифрованным Wi-Fi в публичном месте. Здесь стоит воспользоваться VPN: несколько упрощая, это защищённый шифрованием канал, протягиваемый от вас до VPN-провайдера. На сервере провайдера трафик дешифруется и отправляется далее по назначению. Провайдеры VPN бывают как бесплатные (VPNbook.com, Freevpn.com, CyberGhostVPN.com), так и платные - различающиеся скоростью доступа, временем сеанса и т.п. Большой бонус такого соединения в том, что для всего мира вы кажетесь выходящим в Сеть с сервера VPN, а не со своего компьютера. Поэтому, если VPN-провайдер находится за пределами Российской Федерации, вам будут доступны сайты, заблокированные внутри РФ.

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

Недостатки : помните, что ваш трафик дешифруется на выходном узле, то есть на сервере VPN-провайдера или компьютере случайного участника TOR. Поэтому если их владельцы пожелают, они смогут анализировать ваш трафик: попробовать перехватить пароли, выделить ценные сведения из переписки и пр. Поэтому пользуясь VPN или TOR, совмещайте их с другими средствами шифрования. Кроме того, настроить TOR правильно - задача непростая. Если у вас нет опыта, лучше воспользоваться готовым решением: комплектом TOR + браузер Firefox (в таком случае будет шифроваться только браузерный трафик) или Linux-дистрибутивом Tails (работающим с компакт-диска или флэшки), где весь трафик уже настроен на маршрутизацию через TOR.

Зашифруйте флэшки и съёмные носители данных, мобильные устройства. Сюда же можно добавить и шифрование жёсткого диска на рабочем компьютере, но его вы по крайней мере не рискуете потерять - вероятность чего всегда присутствует в случае с носимыми накопителями. Чтобы зашифровать не отдельный документ, а сразу целый диск, используйте приложения BitLocker (встроено в MS Windows), FileVault (встроено в OS X), DiskCryptor , 7-Zip и им подобные. Такие программы работают «прозрачно», то есть вы не будете их замечать: файлы шифруются и дешифруются автоматически, «на лету». Однако злоумышленник, в руки которого попадёт закрытая с их помощью, например, флэшка, ничего из неё извлечь не сумеет.

Что касается смартфонов и планшеток, там для полного шифрования лучше воспользоваться встроенным функционалом операционной системы. На Android-устройствах загляните в «Настройки -> Безопасность», на iOS в «Настройки -> Пароль».

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

Таков список действий, которые стоит предпринять, если вас беспокоит возможная утечка файлов в чужие руки. Но помимо этого есть ещё несколько соображений общего характера, которые тоже следует иметь в виду:

Свободное приложение для охраны приватности обычно надёжней проприетарного. Свободное - это такое, исходные тексты которого опубликованы под свободной лицензией (GNU GPL, BSD и т.п.) и могут изменяться всеми желающими. Проприетарное - такое, эксклюзивные права на которое принадлежат какой-либо одной компании или разработчику; исходные тексты таких программ обычно не публикуются.

Шифрование предполагает использование паролей, поэтому позаботьтесь, чтобы ваш пароль был правильным: длинным, случайным, разнообразным.

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

Для задач, которые требуют анонимности/приватности, удобней держать отдельный браузер, настроенный на «параноидальный» режим (вроде уже упоминавшегося комплекта Firefox + TOR).

Javascript, часто используемый в Сети, это настоящая находка для шпиона. Поэтому, если вам есть что скрывать, Javascript в настройках браузера лучше заблокировать. Также безусловно блокируйте рекламу (поставьте любой плагин, реализующий эту функцию, например, AdBlockPlus): под видом банеров в последнее время часто рассылают вредоносный код.

Если пресловутый «закон Яровой» всё-таки вступит в силу (по плану это должно случиться 1 июля 2018 года), запасные ключи от всех шифров в России должны будут быть переданы государству, в противном случае шифр не будет сертифицирован. А за пользование несертифицированным шифрованием даже рядовые обладатели смартфонов смогут быть оштрафованными на сумму от 3 тысяч рублей с конфискацией цифрового устройства.

P.S. В статье использована фотография Christiaan Colen .

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

21.06.2011 Владимир Безмалый

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

Для начала вспомним, как осуществлялась защита документов Microsoft Word в Microsoft Office.

Прошлое и настоящее шифрования в Office

В Office, до версии 6.0 включительно, первым алгоритмом шифрования был обычный XOR. Конечно же, такой простейший алгоритм шифрования не обеспечивал никакой защиты, и любые пароли восстанавливались практически мгновенно. Вполне естественно, что соответствующие программы для взлома Microsoft Word и Microsoft Excel появились практически сразу. Более того, как отмечал один из авторов таких программ, ложное чувство безопасности гораздо хуже, чем ее отсутствие. И просил Microsoft улучшить защиту в Office.

Это и было сделано в последующих версиях Microsoft Office 97 и 2000. В данных продуктах использовались сильные криптоалгоритмы MD5 и RC4. Однако в связи с введением ограничений на экспорт сильной криптографии, действовавших в то время в США, криптоалгоритмы, применявшиеся за пределами США, не могли использовать ключи длиннее 40 разрядов. Это привело к искусственному ограничению ключей RC4 до 40 бит, а, следовательно, из 16 байт, полученных на выходе MD5, 11 просто затирались в 0, и из 5 значащих байтов и 11 нулей формировался ключ RC4. Это привело к возможности организации атаки методом перебора (методом brute force). Для расшифровки файла MS Word/Excel 97/2000 нужно перебрать максимум 240 ключей.

С учетом появления таблиц ключей (Rainbow tables) нужную атаку можно совершить за ограниченное время (от нескольких секунд до нескольких минут). Более того, появились сайты в Интернете, оказывающие подобные услуги, например www.decryptum.com (стоимость расшифровки одного файла составляет 29 долл.); программное обеспечение Guaranteed Word Decrypter (GuaWord) 1.7, Guaranteed Excel Decryptor (GuaExcel) 1.7 (производитель PSW-soft), Advanced Office Password Breaker (AOPB), Advanced Office Password Recovery (AOPR) (производитель Elcomsoft).

В Microsoft Office XP/2003 в качестве алгоритма шифрования по умолчанию был оставлен все тот же алгоритм с 40 разрядным ключом. Вместе с тем были внесены следующие изменения:

• алгоритм хеширования SHA1 (вместо MD5);
• ключ RC4 может иметь длину до 128 разрядов;
• длина пароля увеличена с 16 до 255 символов.

Другое дело, что в любом случае используемая схема шифрования и проверки паролей допускает высокую скорость перебора (до 1 000 000 паролей в секунду), как показано на экране 1.

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

• на смену алгоритму RC4 пришел алгоритм шифрования AES с длиной ключа 128 разрядов;
• вместо однократного хеширования пароль хешируется циклически 50 тыс. раз;
• возможно применение сторонних алгоритмов шифрования.

В результате принятых мер скорость перебора паролей составляет не более 200 паролей в секунду, что позволяет подобрать за разумное время пароли не длиннее 5–6 символов.

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

Экран 2. Атака перебором с учетом ресурсов видеокарты

Что касается формата защищенных файлов, то его не назовешь простым и понятным. Ведь если установлен пароль на открытие файла, то фактически файл представляет собой OLE-контейнер, состоящий из информации о шифровании, зашифрованного потока и вспомогательной информации. Однако, несмотря на то что в нем, как и в блоке шифрования в Office XP/2003, содержится имя криптопровайдера, названия алгоритмов хеширования и шифрования, а также длина ключа и данные для проверки пароля и расшифровки, в Office 2007 жестко установлены следующие параметры:

• алгоритм шифрования AES с длиной ключа 128 разрядов;
• алгоритм хеширования SHA-1.

При этом шифрование и хеширование обеспечивает криптопровайдер Microsoft Enhanced RSA and AES Cryptographic Provider. Вместе с тем следует учесть, что при атаке последовательным перебором паролей скорость перебора катастрофически падает.

Изменился и алгоритм проверки паролей защиты документа от изменений с доступом только на чтение, а также книг и листов Excel. Раньше в документе хранился хеш пароля, состоящий из 2 байт. Соответственно было возможно его реверсирование в первый подходящий пароль. Сейчас же алгоритм хеширования определен записью в файле XML и там же определено количество итераций хеша.

Параметры защиты документов

Параметры защиты документов позволяют изменить способ шифрования файлов и текста с помощью функции защиты пароля. Существует два типа параметров защиты документов:

• глобальные параметры, применимые к Office Excel 2007, Office PowerPoint 2007 и Office Word 2007. Два глобальных параметра защиты документов описаны в таблице 1;
• параметры, зависящие от приложения, применимые только к Microsoft Office OneNote 2007.

Эти параметры можно найти либо на странице параметров пользователей «Изменить» центра развертывания Office, в разделе «Система Microsoft Office 2007», «Параметры безопасности», либо в узле «Конфигурация пользователя/Административные шаблоны редактора объектов групповой политики», в разделе «Система Microsoft Office 2007/Параметры безопасности».

Настройки конфиденциальности

Настройки конфиденциальности помогают защитить частные и конфиденциальные сведения. Мы можем использовать четыре основные категории настроек конфиденциальности в Office 2007. Параметры можно настроить в центре развертывания Office или посредством групповой политики. Четыре категории настроек конфиденциальности описаны ниже.

Параметр инспектора документов показан в таблице 2.

CLSID для модуля инспектора можно найти в записях реестра, которые находятся в следующих разделах реестра:

HKEY_LOCAL_MACHINE/Software/ Microsoft/Office/12.0/Excel/ Document Inspectors HKEY_LOCAL_MACHINE/Software/ Microsoft/Office/12.0/PowerPoint/ Document Inspectors HKEY_LOCAL_MACHINE/Software/ Microsoft/Office/12.0/Word/ Document Inspectors

Параметр «Инспектор документов» можно найти на странице параметров пользователей «Изменить» центра развертывания Office: Система Microsoft Office 2007 (компьютер)/Прочее.

Или же этот параметр можно найти в редакторе объектов групповой политики: Конфигурация компьютера/Административные шаблоны/Microsoft Office 2007 (компьютер)/Прочее.

Шифрование в Office 2010. Алго­рит­мы шифрования, применяемые в Microsoft Office 2010, зависят от алгоритмов, доступ к которым можно получить через интерфейсы API в операционной системе Windows. Office 2010, помимо поддержки Cryptography API (CryptoAPI), также поддерживает интерфейс CNG (CryptoAPI: Next Generation), который впервые стал доступен в Microsoft Office 2007 с пакетом обновления 2 (SP2).

При этом стоит учесть, что, используя CNG, можно добиться более динамичного шифрования и применять модули сторонних производителей. Если Office использует CryptoAPI, алгоритмы шифрования зависят от алгоритмов, доступных в провайдере службы криптографии (CSP), который входит в операционную систему Windows.

Список провайдеров службы криптографии, установленных на компьютере, содержится в следующем разделе реестра:

HKEY_LOCAL_MACHINE/SOFTWARE/ Microsoft/Cryptography/Defaults/Provider

В Office 2010 и Office 2007 с пакетом обновления 2 (SP2) можно использовать следующие алгоритмы шифрования CNG и другие криптографические расширения CNG, установленные в системе: AES, DES, DESX, 3DES, 3DES_112 и RC2. Алгоритмы хеширования CNG и другие криптографические расширения CNG можно использовать такие: MD2, MD4, MD5, RIPEMD-128, RIPEMD-160, SHA-1, SHA256, SHA384 и SHA512.

При шифровании документов в формате Open XML (DOCX, XSLX, PPTX и т. д.) алгоритмом шифрования по умолчанию выбран алгоритм AES (алгоритм шифрования, который был выбран Агентством национальной безопасности (NSA) в качестве стандарта для правительства США, поддерживается в операционных системах Windows XP с пакетом обновления 2 (SP2), Windows Vista, Windows 7, Windows Server 2003 и Windows Server 2008) с длиной ключа 128 разрядов, алгоритм хеширования - SHA1.

Параметры криптографии и шифрования. В таблице 3 перечислены параметры, которые позволяют изменить алгоритмы шифрования при использовании версий Microsoft Office, применяющих CryptoAPI.

В Office 2010, если требуется изменить параметр «Тип шифрования» для защищенных паролем файлов Office Open XML, сначала следует включить параметр «Задать совместимость шифрования» и выбрать параметр «Использовать формат прежних версий». Параметр «Задать совместимость шифрования» доступен в Access 2010, Excel 2010, PowerPoint 2010 и Word 2010.

В таблице 4 перечислены параметры, которые позволяют изменить алгоритмы шифрования при использовании Office 2010. Эти параметры применяются к Access 2010, Excel 2010, OneNote 2010, PowerPoint 2010, Project 2010 и Word 2010.

Помимо параметров CNG, указанных в предыдущей таблице, для Excel 2010, PowerPoint 2010 и Word 2010 можно настроить параметр CNG с именем «Использовать новый ключ при смене пароля», который позволяет указать, следует ли использовать новый ключ шифрования при изменении пароля. По умолчанию при изменении пароля новый ключ не используется.

Параметр «Отключить пароль для открытия пользовательского интерфейса» можно использовать, чтобы запретить добавлять пароли в документы и тем самым отключить шифрование документов. Этот параметр управляет тем, могут ли пользователи Office 2010 добавлять пароли в документы. По умолчанию пользователи могут добавлять пароли.

Совместимость с предыдущими версиями Office. Если требуется зашифровать документы Office, рекомендуется сохранить их в формате Open XML (DOCX, XLSX, PPTX и т. д.) вместо формата Office 97–2003 (DOC, XLS, PPT и т. д.). При шифровании двоичных документов (DOC, XLS, PPT) используется алгоритм RC4, что не рекомендуется! Так как число циклов повторного хеширования по умолчанию 100 000, скорость перебора паролей по умолчанию вдвое ниже, чем при незаконном доступе к документам Office 2007.

Таким образом, можно сделать несложный вывод: с точки зрения устойчивости к атакам прямого перебора пароли документов в Microsoft Office 2010 являются на сегодня наиболее эффективными.

Владимир Безмалый ([email protected]) - специалист по обеспечению безопасности, имеет звания MVP Consumer Security, Microsoft Security Trusted Advisоr

CryptoUtility - компонент, позволяющий применять стойкое шифрование в ваших приложениях

• 12/05/2008
• Время чтения: 19 мин

В этой статье

• Майкл Стюарт
• Джей Сойер

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

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

Мы рассмотрим в этой статье некоторые проблемы разработки компонентов стойкого шифрования, используемых приложениями. Такие компоненты будут полезны в случаях, подобных описанному выше. Кроме того, при создании программы CryptoUtility мы преследовали и некоторые другие цели. Во-первых, мы хотели обеспечить максимальный уровень защиты, целесообразный для серверных Web-приложений. Во-вторых, требовалось, чтобы установка была относительно простой с точки зрения администратора и чтобы программу можно было развернуть на нескольких серверах, не изучая инструкцию по установке на 10 страницах. В-третьих, должно было поддерживаться обратимое шифрование (которые мы рассмотрим далее), причем требовалось, чтобы ключи были защищены и не подвергались опасности при хранении. Конечно, поскольку это серверное приложение, он должно быть высоко масштабируемым и способным месяцами работать без присмотра администратора и необходимости перезагрузки. Наконец, мы хотели, чтобы компонент был доступен как унаследованным COM-приложениям (например классической ASP), так и.NET-приложениям (вроде Web-сервисов и Web-приложений, работающих в ASP.NET).

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

Мы будем исследовать угрозы с помощью моделей STRIDE и DREAD, описанных Майклом Говардом в книге «Writing Secure Code, Second Edition» (Microsoft Press, 2003). STRIDE - модель деления угроз на категории. Это сокращение означает Spoofing (подделка идентификации), Tampering (взлом), Information disclosure (раскрытие информации), Denial of service (отказ в обслуживании) и Elevation of privilege (увеличение привилегий). DREAD - модель расчета общего риска, связанного с угрозой; это аббревиатура от Damage potential (возможный ущерб), Reproducibility (вероятность повторения атаки), Exploitability (насколько легко осуществить атаку), Affected users (затрагиваемые пользователи) и Discoverability (насколько легко обнаружить уязвимость). Моделирование и анализ угроз выходят за рамки статьи, но мы будем использовать терминологию моделей STRIDE и DREAD, когда речь пойдет о мерах по защите системы.

Архитектура CryptoUtility

Архитектурные решения оказывают влияние на любое приложение. Прежде всего мы должны были решить, как реализовать CryptoUtility: как внутрипроцессную DLL, как Windows-службу или как обслуживаемый компонент (Serviced Component), работающий в Enterprise Services. При разработке компонента как внутрипроцессной DLL возникло бы несколько серьезных проблем, связанных с защитой. Во-первых, CryptoUtility работала бы под учетной записью ASP.NET. Хотя мы пока не выбрали стратегию управления ключами (сделаем это позже), нам точно не хотелось бы, чтобы учетная запись ASP.NET имела доступ к ключу. Тогда существовала бы вероятность, что злоумышленник воспользуется этой уязвимостью и получит конфиденциальную информацию через Web-сайт. Шансы на это невелики, но данные, которые мы защищаем, таковы, что разрушительный потенциал взлома крайне высок. Такое вторжение может повлиять на всех пользователей, поэтому мы стараемся никогда не использовать этот подход.

Мы могли бы использовать совместно с Remoting модель защиты по правам доступа кода (Code Access Security, CAS), но из-за отсутствия поддержки COM-клиентов это не лучший выбор. Однако мы еще рассмотрим CAS в этой статье.

Обслуживаемый компонент в Enterprise Services дает те же преимущества, что и Windows-служба. Такой компонент работает под собственной идентификацией со своими удостоверениями. Кроме того, технология Enterprise Services основана на технологии COM+ Component Services, обеспечивающей COM-клиентам строгое управление доступом и простоту доступа. Поэтому мы решили сделать CryptoUtility обслуживаемым компонентом.

Криптографические решения

В девятнадцатом веке фламандский специалист в области шифрования Аугуст Керкхофф (Auguste Kerckhoff) предложил простое, но эффективное правило: безопасность шифровальной системы должна полностью зависеть от сохранения ключа в тайне. Разработчикам надо усвоить следующий урок: не разрабатывайте свои алгоритмы шифрования (и даже не занимайтесь самостоятельной реализацией общеизвестных алгоритмов, разве что в качестве упражнения). Если вы не математический гений, специализирующийся на теории криптографии, вы почти наверняка допустите ошибки, пытаясь создать собственный алгоритм. Коммерческие реализации общепризнанных алгоритмов прошли всестороннюю сертификацию. Примером могут служить Federal Information Processing Standards, выпущенные NIST (National Institute of Standards and Technology).

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

В случае асимметричного шифрования (или шифрования с открытым ключом) имеются два математически связанных, но не зависящих друг от друга ключа: открытый и закрытый. Информацию, зашифрованную с закрытым ключом, можно расшифровать только с соответствующим открытым ключом, а информацию, зашифрованную с открытым ключом, - только с соответствующим закрытым ключом.

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

Как работают симметричные алгоритмы

Симметричные алгоритмы рассматриваемого в статье типа являются блочными шифрами. Они разбивают незашифрованный текст на блоки фиксированного размера (в случае алгоритма Rijndael - на 16, 24 или 32 байта) и для каждого блока в цикле выполняют операции перестановки и замены. В.NET Framework можно выбрать один из нескольких симметричных алгоритмов: DES (Data Encryption Standard), который раньше был федеральным стандартом, 3DES (Triple-DES), RC2 или Rijndael. DES утратил свои позиции с ростом мощностей оборудования: поскольку в нем применяется лишь 56-битный ключ, он поддается атакам по методу грубой силы. Алгоритм Triple-DES, т. е. «тройной DES», по-прежнему относительно безопасен и, вероятно, хорошо подходит для шифрования, так как широко поддерживается на большинстве платформ.

Мы выбрали для CryptoUtility алгоритм Rijndael, поскольку в нем можно использовать ключи размером 256 битов - это максимальный размер среди всех алгоритмов, встроенных в.NET. Кроме того, Rijndael стал новым усовершенствованным стандартом шифрования (Advanced Encryption Standard), принятым федеральным правительством в 2001 г. в качестве замены DES. Этому предшествовало длительное и всестороннее рассмотрение нескольких алгоритмов в конкурсе, спонсировавшемся NIST.

Параметры симметричных алгоритмов

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

Режим шифрования (mode) В случае алгоритма Rijndael это или CBC (Cipher Block Chaining), или ЕCB (Electronic Code Book):

• CBC, применяемый в.NET по умолчанию, - наиболее безопасный режим шифрования. В режиме CBC алгоритм, прежде чем шифровать текст, выполняет для каждого блока открытого текста операцию XOR с предыдущим зашифрованным блоком. В этом режиме также необходим вектор инициализации (Initialization Vector, IV) - случайный блок того же размера, что и блок алгоритма. IV используется вместо блока, чтобы можно было выполнить операцию Cipher Block Chaining для первого блока незашифрованного текста, поскольку у этого блока нет предыдущего. IV гарантирует, что наличие повторений в первом блоке открытого текста при использовании одного и того же ключа не приведет к тем же повторениям в первом блоке шифрованного текста;
• ECB - менее безопасный режим, при котором каждый блок шифруется независимо от других. Повторения в открытом тексте могут привести к появлению шаблонов в шифрованном тексте, что ослабляет защиту.

Режим дополнения до длины блока (padding) Поскольку длина сообщения не всегда кратна длине блока алгоритма, вы должны добавить что-нибудь в конец сообщения, чтобы заполнить последний блок. Для управления дополнением используются следующие значения:

• PKCS7 - последний блок дополняется целыми значениями, каждое из которых представляет собой количество байтов, добавляемых в сообщение. Например, если в сообщение нужно добавить 2 байта, будет добавлено «0×02, 0×02»";
• None - ничего не добавляется. Длина сообщения обязательно должна быть кратной длине блока алгоритма;
• Zeros - последний блок дополняется нулями.

Размер ключа (key size) - длина ключа, используемого при шифровании и дешифровании. Более длинные ключи, как правило, обеспечивают лучшую защиту, поскольку меньше вероятность того, что атаки по методу грубой силы увенчаются успехом. В Rijndael используются ключи размером 128, 192 или 256 битов. Размер ключа не зависит от размера блока.

Размер блока (block size) - длина каждого блока. В Rijndael размер блока может составлять 128, 192 и 256 битов.

Заметьте: в Rijndael возможны все девять комбинаций размеров блока и ключа; однако размер IV должен совпадать с размером блока. Лучше использовать более крупные блоки, поскольку Rijndael при шифровании может выполнять на внутреннем уровне от 10 до 14 итераций, и чем больше размеры блока и ключа, тем больше число итераций. А чем больше итераций выполняет алгоритм Rijndael, тем больше устойчивость шифра к криптографическому анализу. Дополнительную информацию о Rijndael см. в посвященной этому алгоритму статье Джеймса Мак-Каффри, опубликованной в MSDN Magazine за ноябрь 2003 г.

Мы решили использовать режим Cipher Block Chaining и размеры блока и ключа по 256 битов, чтобы обеспечить максимальный уровень защиты шифрованного текста. CBC и вектор инициализации критически важны: номера многих кредитных карточек начинаются с одних и тех же цифр. Если бы шифрованный текст для таких карточек также начинался с одних и тех же данных, то злоумышленникам было бы куда проще получить доступ к зашифрованным номерам кредитных карточек и похитить данные!

Создание стойких ключей

Подобно предсказуемым паролям, предсказуемые криптографические ключи подвергают серьезному риску безопасность вашего приложения. Не генерируйте эти ключи вручную: люди - плохие генераторы случайных чисел. Генератор псевдослучайных чисел System.Random тоже не годится, поскольку его случайные последовательности детерминированы и повторяются (отсюда и название «псевдослучайные»). Для генерации стойких ключей можно воспользоваться RNGCryptoServiceProvider. Он генерирует криптографически стойкие случайные числа и годится для генерации ключей и расширений/IV. Хотя с технической точки зрения RNGCryptoServiceProvider является генератором псевдослучайных чисел, он сертифицирован NIST как криптографически стойкий. В следующем примере кода на Visual Basic .NET для получения 32 случайных байтов данных применяется RNGCryptoServiceProvider:

Dim entropy As Byte() = ... Dim pwd As PasswordDeriveBytes = _ New PasswordDeriveBytes(txtKey.Text, entropy) Dim key as Byte() = pwd.GetBytes(32)

Создание стойких расширений

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

Dim rng As RNGCryptoServiceProvider = _ New RNGCryptoServiceProvider() Dim entropy As Byte() = New Byte(15) rng.GetBytes(entropy)

При перемешивании блоков алгоритм шифрования использует IV в качестве начального блока, чтобы скрыть все закономерности в первом блоке. В режиме CBC каждый блок используется при шифровании следующего блока, а при шифровании первого блока - IV.

В алгоритме Rijndael стойкость шифра не зависит от секретности IV. Но тем фактом, что при шифровании одного и того же открытого текста с помощью одного и того же ключа и IV получается один и тот же шифрованный текст, можно воспользоваться, чтобы попытаться угадать содержимое сообщения. Так, если ваш открытый текст содержит только слова «да» и «нет», то при применении одних и тех же ключа и IV декодирование подобных сообщений было бы тривиальной задачей, поскольку шифрованный текст содержал бы повторы. Если каждый раз используется случайный IV, будет получаться разный шифрованный текст, и это собьет с толку тех, кто «играет в угадайку».

IV не обязательно должен быть закрытым; в своих примерах мы помещаем IV перед шифрованным текстом, прежде чем сохранить этот текст. При дешифровании нужен тот же IV, что и при шифровании. Не составляет труда прочитать его из начала сообщения. Поэтому некоторые рекомендуют хранить IV отдельно от шифрованного текста. Однако режим CBC обеспечивает достаточную защиту, даже если не хранить IV в тайне:

" Помещаем IV в начало шифрованного текста output = New Byte(IV_SIZE + data.Length - 1) Buffer.BlockCopy(newIV, 0, output, 0, newIV.Length) Buffer.BlockCopy(data, 0, output, IV_SIZE, data.Length) " Берем расширение (IV) из первых 16 байтов ввода Buffer.BlockCopy(cipherBlob, 0, iv, 0, IV_SIZE) " Помещаем шифрованный текст в массив cipherText Buffer.BlockCopy(cipherBlob, IV_SIZE, cipherText, 0, _ (cipherBlob.Length - IV_SIZE))

«Гигиеничная» криптография

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

Если незашифрованный текст был помещен в объект System.String, он останется в памяти в неизменном виде до тех пор, пока не будет перезаписан при сборе мусора. У элементов управления TextBox, Label и многих других свойство Text имеет тип System.String. Ситуация несколько изменится в.NET Framework 2.0, в которой введен класс SecureString, специально предназначенный для безопасного хранения строк (информацию о SecureString см. в документации Visual Studio 2005 Beta 1.) Но это не решает проблему, так как в памяти хранится открытый текст, поступающий из многих других источников, таких как TextBox и ему подобные. Если незашифрованный текст в любом виде (массив байтов, строка, массив символов и т. д.) записывался операционной системой в страничный файл, он попадает на жесткий диск. Если система дает сбой и генерирует дамп памяти в момент, когда открытый текст содержится в памяти, этот текст также записывается на диск.

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

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

Тем не менее, следует соблюдать определенные правила «гигиены» при написании кода, чтобы свести к минимуму риск таких атак. Во-первых, минимизируйте время, в течение которого ключ хранится в памяти в незашифрованном виде: зашифруйте ключ через DPAPI (Data Protection API) и храните в разделе реестра, защищенном с помощью ACL (access control list). Расшифровывайте ключ непосредственно перед использованием, а затем очищайте массив байтов методом Array.Clear, обнуляющим байты. Никогда не храните ключ в объектах String, даже закодированных с помощью алгоритма Base64; запомните, что Base64 нельзя считать шифрованием. Заметьте: такая очистка массива байтов не полностью решает проблему, поскольку сборщик мусора может переместить массив байтов в памяти до того, как он будет очищен. Чтобы этого избежать, назначьте массиву байтов определенный адрес в памяти - это не позволит сборщику мусора перемещать его. Информацию об ACL см. в статье Марка Пустилника (Mark Pustilnik) «Защита в Windows. Управление доступом к Windows-объектам на основе ACL и.NET Framework» в этом номере.

Во-вторых, минимизируйте количество мест и продолжительность периодов хранения вашего незашифрованного текста в памяти. Полностью избежать этого нельзя хотя бы потому, что код должен видеть открытый текст, чтобы зашифровать его. Но можно свести к минимуму число объектов String, содержащих незашифрованный текст, преобразовывая его в массив байтов и очищая этот массив по окончании шифрования. К сожалению, не хранить открытый текст в объектах String крайне сложно. Как упоминалось выше, у большинства элементов управления свойство Text хранится как System.String, из-за чего выполнить это требование почти невозможно.

Хранение ключа

В приложениях, используемых на практике, самой важной составляющей криптографии является хранение ключа. Брюс Шнайер (Bruce Schneier), специалист в области компьютерной безопасности и автор книги «Applied Cryptography» (John Wiley & Sons, 1996), остроумно охарактеризовал слабые места защиты, основанной исключительно на стойком шифровании. Он сравнил такую защиту с забором, состоящим лишь из одной доски, зато высотой в милю. Поскольку ключ в симметричном шифровании является секретным, встает вопрос: как его защитить? С точки зрения злоумышленника, раскрытие ключа - гораздо лучший вариант, чем применение методов грубой силы к зашифрованному тексту. Зачем лезть на забор высотой в милю, когда можно просто обойти его?

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

Мы могли бы хранить ключ в базе данных, но тогда возникла бы проблема получения ключа, если бы мы решили использовать зашифрованную строку подключения к базе данных. Мы могли бы хранить ключ в локальном файле. Это приемлемый подход, поскольку он позволяет управлять доступом к файлу на основе ACL. Мы могли бы хранить ключ в строке конструктора COM+, но тогда пришлось бы ограничиться одним ключом и потребовалось бы тщательное администрирование с управлением доверием. Рассмотрев все эти варианты, мы решили хранить ключ в реестре, используя имя приложения в качестве имени раздела. Это позволяет нам использовать ACL для управления доступом, хранить ключ для каждого приложения, использующего CryptoUtility, и без проблем задавать ключ в утилите администрирования. Можно также вести аудит разделов реестра и видеть в журнале аудита, кто читал и записывал данные этих разделов реестра.

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

Защита ключа на основе ACL

Мы можем защитить ключ двумя способами. Первый - ограничить доступ к разделу реестра с помощью ACL. Не составляет труда задать ACL вручную, но каждая ручная операция требует определенного времени, и пока она выполняется, возможно раскрытие данных, особенно при развертывании приложений на Web-фермах, которые могут состоять из десятков серверов. Поэтому мы настоятельно рекомендуем программно задавать ACL для разделов реестра, в которых хранится ключ.

Написав код, задающий ACL для разделов реестра, мы можем инкапсулировать настройку разделов прямо в установщик или в простую утилиту командной строки, автоматизирующую установку и настройку защиты. К сожалению, в.NET Framework 1.x нет встроенных средств задания ACL для разделов реестра. Но благодаря усилиям Рено Паке (Renaud Paquet) появилась крайне полезная управляемая библиотека, которая позволяет задавать ACL практически для всего. Разработанную Рено .NET-библиотеку управления ACL.

С помощью его библиотеки Win32 Security мы ограничили доступ к разделу реестра (рис. 1). Теперь, чтобы прочитать раздел, злоумышленник должен либо присвоить себе идентификацию, заданную в ACL, либо стать администратором компьютера.

Листинг 1. Защита раздела реестра

" Создаем DACL Dim regDacl As Microsoft.Win32.Security.Dacl = _ New Microsoft.Win32.Security.Dacl() regDacl.AddAce(New AceAccessAllowed(Sids.Admins, _ AccessType.SPECIFIC_RIGHTS_ALL Or _ AccessType.STANDARD_RIGHTS_ALL, _ AceFlags.CONTAINER_INHERIT_ACE)) regDacl.AddAce(New AceAccessAllowed(New Sid(_userName), _ AccessType.GENERIC_READ, AceFlags.CONTAINER_INHERIT_ACE)) " Открываем раздел реестра Dim hKey As IntPtr Dim rc As Integer = Win32.RegOpenKey(New IntPtr(_ (int)Microsoft.Win32.RegistryHive.LocalMachine), _ regKey, hKey) " Сопоставляем DACL разделу реестра If rc = Win32.SUCCESS Then Dim sd As SecurityDescriptor = _ SecurityDescriptor.GetRegistryKeySecurity(hKey, _ SECURITY_INFORMATION.DACL_SECURITY_INFORMATION Or _ SECURITY_INFORMATION.GROUP_SECURITY_INFORMATION Or _ SECURITY_INFORMATION.OWNER_SECURITY_INFORMATION) sd.SetDacl(regDacl, false) sd.SetRegistryKeySecurity (hKey, _ SECURITY_INFORMATION.DACL_SECURITY_INFORMATION) Win32.RegCloseKey(hKey) End If

Защита ключа через DPAPI

Мы ограничили доступ к ключу, задав ACL, однако ключ в виде незашифрованного текста хранится в реестре, т. е. где-то в файловой системе. Поэтому перед нами встает задача: с помощью DPAPI зашифровать сам ключ. В принципе, DPAPI обеспечивает симметричное шифрование «без ключа», используя в качестве ключа данные загруженного в текущий момент профиля пользователя или компьютера. (Полный исходный код класса-оболочки DPAPI см. в файле DpapiCryptographer.vb.)

В режиме USER DPAPI генерирует ключ по загруженному профилю пользователя. Если что-либо зашифровано в DPAPI-режиме USER, расшифровать зашифрованную информацию сможет только пользователь с данной учетной записью. В этом случае нужно, чтобы был загружен профиль учетной записи, отличной от применяемой по умолчанию компонентами COM+. Кроме того, для поддержки шифрования и дешифрования на различных компьютерах нужно, чтобы были разрешены профили роуминга и чтобы все клиенты их использовали. Это может оказаться непростой задачей для администратора.

DPAPI-режим MACHINE означает, что любой код, выполняемый на компьютере, имеет доступ к DPAPI-ключу и, следовательно, может расшифровать любые данные, зашифрованные в режиме MACHINE. Мы хотим ограничить доступ к ключу, а DPAPI позволяет нам передать уникальное расширение, чтобы внести дополнительную энтропию в генерацию ключа. Мы будем хранить это расширение в реестре вместе с зашифрованным ключом и с помощью ACL ограничим доступ к расширению, разрешив доступ тем же пользователям, что и к ключу. Это не идеальное решение; возможно, вы пожелаете хранить DPAPI-расширение где-нибудь еще. Чтобы атаковать наше решение, надо запустить код на компьютере, получить доступ к разделу реестра, защищенному ACL, и иметь возможность вызвать DPAPI, передав похищенное расширение, чтобы расшифровать ключ. Учитывая, что такая атака вряд ли осуществима, можно считать риск разумным. На рис. 2 показано, как выглядит CryptoUtility в контексте COM+, клиентского приложения и окружающих CryptoUtility подсистем - DPAPI и Registry.

Взаимная аутентификация и «затемнение» ключа

Вы увидите, что одни перегруженные методы класса Crypto поддерживают частичный ключ, а другие - нет. Мы собирались использовать в одном из наших приложений взаимную аутентификацию и написали эти перегруженные версии, чтобы можно было работать и так, и эдак.

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

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

Мы используем взаимную аутентификацию, поскольку половина ключа передается приложением; приложение не полностью анонимно, и нам в определенной степени известно, кто с ним работает. Чтобы расшифровать информацию, приложению должна быть известна его половина ключа.

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

Худший случай при использовании частичного ключа - атаку ведет сотрудник компании, уже знакомый с системой (например один из ее создателей) и имеющий сетевой доступ к компьютеру. Если при этом злоумышленник является еще и администратором компьютера, наша карта бита - он завладеет системой.

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

Еще одно возражение против частичного ключа: если злоумышленник выяснит частичный ключ, «затемненный» кодом, то оставшийся ключ будет вдвое короче, из-за чего будет в разы проще провести атаку по методу грубой силы. Но, поскольку мы используем алгоритм Rijndael с максимальной длиной ключа в 256 битов, оставшаяся 128-битная часть ключа по-прежнему будет обеспечивать очень высокую безопасность. Если в вашем случае нет смысла хранить половину ключа в клиентском приложении, хранение всего ключа в реестре будет вполне приемлемым вариантом.

Защита самого криптографического приложения

Мы рассмотрели два уровня защиты: криптографическую защиту собственно закрытых данных по алгоритму Rijndael и защиту ключа к этим данным на основе ACL и DPAPI. Но есть и третий уровень, нуждающийся в защите, - само приложение CryptoUtility!

Хранение всего ключа в реестре, в частности, означает, что любая сборка, имеющая право обращаться к сборке Crypto, может использовать ее методы шифрования/дешифрования, не указывая дополнительные удостоверения. Поэтому предыдущие два уровня бесполезны, если анонимный вызывающий может обратиться к CryptoUtility, чтобы дешифровать ключ.

Чтобы избежать этого, мы можем воспользоваться средством модели защиты по правам доступа кода (code access security, CAS) - атрибутом StrongNameIdentityPermission (SNIP) LinkDemand. Это декларативное CAS-средство позволяет пометить метод или класс атрибутом, который содержит открытый ключ сборок, имеющих право вызывать нашу сборку. Например:

В период выполнения.NET Framework проверяет, что сборка, вызывающая нашу сборку, подписана именно тем строгим именем, которое указано в атрибуте. Если это не так, вызов терпит неудачу. Это относится и попыткам применить к сборке средства механизма отражения.

Однако у такого подхода есть слабости. Основная слабость SNIP LinkDemand в том, что достаточно привилегированный пользователь может запросто обеспечить себе успешное прохождение проверок защиты такого рода, например изменив параметры защиты.NET Framework через CASPOL (Code Access Security Policy). Кит Браун (Keith Brown) рассмотрел эти проблемы в своей колонке « » за апрель 2004 г. Кроме того, такой подход потерпит неудачу, если будет раскрыт ваш SNK-файл. Это может произойти, например, в результате атаки изнутри, которую ведет кто-то из вашей или близкой к вашей группы, имеющий доступ к файлам с ключами для строгих имен (strong names).

И последнее по порядку, но не по важности. У этого подхода есть еще одно предсказуемое, но в то же время немного неожиданное слабое место: COM. Поскольку COM не поддерживает концепцию строгих имен, COM не воспринимает атрибут StrongNameIdentityPermission LinkDemand.

Защита в COM

COM не подчиняется CAS-правилам.NET. Если мы установим CryptoUtility как COM+-приложение, оно будет доступно COM так же, как и любой другой COM-компонент, развернутый на компьютере. Это значит, что всю нашу тщательно выстроенную систему защиты можно будет взломать простейшим VBScript-кодом всего из четырех строк:

Set crypto = CreateObject("CryptoUtility.Crypto") original = "this is the secret message." cipher = crypto.Encrypt("ourApp", original) clear = crypto.Decrypt("ourApp", cipher)

Но не все потеряно. COM содержит мощные, проверенные временем средства защиты от несанкционированного доступа. Чтобы ограничить доступ для вызывающего COM-кода, следует активизировать COM+-авторизацию для пакета, как показано на рис. 2 и рис. 3.

CryptoUtility состоит из шести классов. Главный класс, Crypto, содержит только API, доступный извне через его интерфейс ICrypto. Поскольку CryptoUtility - это ServicedComponent, работающий в COM+, мы применяли при его разработке передовой опыт, в частности явно реализовали интерфейс. Класс Crypto использует несколько вспомогательных внутренних классов, выполняющих собственно шифрование. Это классы SymmetricCryptographer, DpapiCryptographer, Hasher (для хэширования и сравнения хэшей) и вспомогательный класс для считывания строк из файла ресурсов.

Класс Crypto управляет кэшированием ключей и позволяет клиентским приложениям указывать, использовать ли такое кэширование. На внутреннем уровне Crypto использует содержащийся в нем класс CachedKey для хранения кэшированных ключей. Crypto обращается к этим кэшированным ключам как к внутреннему набору. Наконец, Crypto содержит внутренние методы чтения данных из реестра и использует DpapiCryptographer для дешифрования этих ключей.

Только благодаря утечкам Эдварда Сноудена и похожим событиям у нас появляется уникальная возможность посмотреть на «внутреннюю кухню» американских спецслужб. Сами они никаких конкретных цифр выдавать не могут по определению.

«Катастрофичный» уровень достигается при комбинации подобных продуктов - к примеру, когда используется Tor, другой сервис анонимизации, чат CSpace и звонки по ZRTP. Этот уровень означает практически полную потерю информации о коммуникациях цели.

Но всё-таки в АНБ получают свою зарплату не зря. У спецслужбы есть возможность взламывать многие из методов реализации VPN. Вызывает большое опасение пункт о том, что планировалось следить за 100 тыс. VPN-соединений в час к концу 2011 года, из них полностью расшифровывать собирались 20%. На 2009 год мощности хватало всего на тысячу в час.

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

К концу 2012 года было намечено достигнуть мощность в 10 млн. взламываемых HTTPS-соединений в сутки. В этом помогает в том числе сбор данных о рукопожатиях SSL.

Из одного документа с высшим уровнем секретности следует , что на момент 2012 года АНБ пыталось найти способ взломать AES .

У АНБ есть программа, которая, как утверждается, может в некоторых случаях взламывать SSH . Этот протокол используется для удалённого управления операционной системой компьютеров, чаще всего это сервера и важные узлы сетей.

Skype, который используется 300 млн пользователей по всему миру, может быть легко прослушан . Непрерывный сбор информации начался в феврале 2011 года, ещё до покупки сервиса компанией Microsoft.

Комбинируя полученную информацию, Агентство национальной безопасности США получает доступ к множеству компьютерных систем. Заявляется, что было осуществлено проникновение в сети Royal Jordanian Airlines, авиакомпании «Трансаэро» и московского телекома «Мир Телематики». В отчётах упоминается слежка за дипломатами и чиновниками из Афганистана, Пакистана и Турции.

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

Следует отметить, что АНБ не только занимается расшифровкой, но также уже давно отправляет своих агентов на конференции Инженерного совета Интернета для сбора информации и влияния на решения. Задачей является упрощение алгоритмов защиты данных.

Для экспертов информационной безопасности полученная информация не является большим откровением - о уязвимостях в протоколах известно. Но пользователям Tor и PGP будет приятно знать о сложности, которую для АНБ представляли эти продукты в 2012 году и, возможно, всё ещё могут представлять.

В конце ноября 2006 года Microsoft выпустила финальную версию пакета приложений Microsoft Office 2007. В этой статье будет дан анализ основных изменений, касающихся защиты документов и персональных данных пользователя.

Новый формат файлов

Изменение формата сразу же бросается в глаза, например файлы Word 2007 теперь имеют расширение *.docx вместо привычного *.doc. В предыдущих версиях Office большинство файлов представляли собой OLE-контейнеры, состоящие, в свою очередь, из нескольких потоков с бинарными данными. Бинарные форматы Word и Excel в конце 90-х годов были документированы и доступны подписчикам MSDN. Однако с выходом Office 2000 компания Microsoft закрыла эти форматы, и вплоть до Office 2003 они не были доступны даже ее партнерам. Это делало невозможным написание собственных приложений, работающих с документами Office.

Однако с выходом Office 2007 ситуация радикально изменилась. Новый формат файлов Office Open XML является полностью открытым и документированным. Документация по формату доступна и может быть скачана всеми желающими с web-сайта Microsoft. Здесь Microsoft пошла по пути известного проекта OpenOffice, формат файлов которого тоже открытый и использует XML для хранения данных. Поскольку формат XML, в отличие от бинарного, содержит много избыточной информации, все XML-файлы упакованы методом deflate архиватора ZIP.

Вот так, например, выглядит файл document.xml, представляющий собой «тело» документа Word:

org/markup-compatibility/2006" xmlns:o=”urn:

schemas-microsoft-com:office:office” xmlns:r=

”http://schemas.openxmlformats.org/officeDocument/

2006/relationships” xmlns:m=”http://schemas.

openxmlformats.org/officeDocument/2006/math”

xmlns:v=”urn:schemas-microsoft-com:vml” xmlns:wp=

”http://schemas.openxmlformats.org/drawingml/2006/

wordprocessingDrawing” xmlns:w10=”urn:schemas-

microsoft-com:office:word” xmlns:w=”http://

schemas.openxmlformats.org/wordprocessingml/2006/

main” xmlns:wne=”http://schemas.microsoft.com/

office/word/2006/wordml”>

w:rsidRDefault=”00FC4BE5">

Test Word file…

w:rsidSect=”00021ED4">

w:left=”1701" w:header=”708" w:footer=”708"

w:gutter=”0" />

Ссылки на XML-схемы, к сожалению, пока не работают. Будем надеяться, что в скором времени Microsoft исправит это недоразумение. Как видно из этого примера, формат файла вполне читаемый и понятный: здесь видны, как минимум, язык текста, сам текст и параметры страницы, а назначение остальных тэгов можно посмотреть в документации.

В Office 2007 очень грамотно решена проблема совместимости с предыдущими версиями Office. Если попытаться открыть файл нового формата, например, в Office 2003, то появится предложение скачать с сайта Microsoft конвертор, после установки которого Office 2003 без проблем будет работать с новыми файлами. При этом сохранение в новом формате тоже поддерживается.

Защита файлов Office 2007: Word, Excel и PowerPoint

Если формат обычных файлов Office является очень простым и понятным, то формат защищенных файлов таковым назвать нельзя. Если установлен пароль на открытие файла, то файл представляет собой OLE-контейнер, состоящий из информации о шифровании, зашифрованного потока и вспомогательной информации. Блок информации о шифровании точно такой же, как и в Office XP/2003. Там содержится имя криптопровайдера, алгоритмы хеширования и шифрования, а также длина ключа и данные для проверки пароля и расшифровки документа. Однако если в предыдущих версиях Office можно было менять криптопровайдера и длину ключа, то в Office 2007 жестко установлены следующие параметры: алгоритм шифрования AES c длиной ключа 128 бит и хеширование SHA-1. Шифрование и хеширование обеспечивает криптопровайдер Microsoft Enhanced RSA and AES Cryptographic Provider.

Однако по сравнению с Office 2003 изменился алгоритм преобразования пароля в ключ. Раньше пароль просто хешировался вместе со случайным набором байтов, уникальных для каждого документа (salt). Эта операция требовала всего два преобразования SHA-1 и выполнялась очень быстро. Сейчас же для преобразования пароля в ключ нужно выполнить последовательно 50 тыс. SHA-1-преобразований. При открытии документа это незаметно - операция выполняется за доли секунды. Однако когда мы начинаем последовательно перебирать пароли, то скорость перебора катастрофически падает. По предварительным оценкам, она может составлять не более 500 паролей в секунду даже на современных процессорах Intel Core 2 Duo. Поэтому если использовать вычислительную мощность только одного компьютера, реально возможно найти пароль длиной лишь до 4-5 символов.

Существенно изменился алгоритм проверки паролей read only, защиты документа, а также книг и листов Excel. Раньше в документе хранился хеш пароля, состоящий из 2 байт. Соответственно было возможно его реверсирование в первый подходящий пароль. Сейчас же алгоритм хеширования определен записью в XML-файле и там же определено количество итераций хеша.

Пример хранения информации о read only-пароле Word 2007:

w:cryptAlgorithmClass=”hash” w:cryptAlgorithmType=

”typeAny” w:cryptAlgorithmSid=”4" w:cryptSpinCount=

”50000" w:hash=”L419ICUXKWKS4zJGA1QoY80b6ds=” w:salt=

”gmd47MvIcN4OwJ5dPxZL6Q==” />

Здесь мы видим, что используются те же 50 тыс. итераций хеша SHA-1, соответственно этот пароль найти мгновенно уже не представляется невозможным. Однако открытость формата значительно упрощает задачу, если нужно изменить или удалить этот пароль. Мы можем либо пересчитать хеш от нового пароля, либо вообще удалить этот тэг из XML-файла. Аналогичным образом хранятся пароли защиты документа, а также книг и листов Excel.

Другие приложения Microsoft Office

Существенно изменилась система защиты в Microsoft Access. Если раньше пароль на открытие файла хранился в заголовке почти открытым текстом, то в Access 2007 используется шифрование файла, реализованное по тому же принципу, что и в Word/Excel. Теперь этот пароль невозможно восстановить мгновенно, а на его восстановление путем прямого перебора уйдет значительное количество времени. В Access 2007 убрана защита на уровне пользователей и групп пользователей.

Защита PST-файлов Microsoft Outlook не претерпела никаких изменений. По-прежнему в файле хранится лишь 32-битный хеш (CRC-32) от пароля, который может быть легко реверсирован.

Стратегии защиты и восстановления паролей Office 2007

В первую очередь хочу отметить, что в целом защита документов Office в новой версии пакета значительно усилена. Всего лишь 10 лет (с момента выхода Office 97) понадобилось Microsoft для разработки хорошей защиты. Пароль на открытие файла является очень стойким, и его перебор может занять очень много времени. Но это не отменяет необходимости выбирать стойкие пароли для документов. К сожалению, человеческий фактор всегда был и будет самым слабым местом в любой защите. И даже стойкая защита Office 2007 не поможет, если пользователь выбрал пароль John, love или sex - он будет мгновенно восстановлен по словарю.

Абсолютно очевидно, что для восстановления стойких паролей к документам Office 2007 уже не хватает вычислительной мощности одного компьютера. Однако существуют приложения, способные объединять компьютеры в кластер, который будет заниматься перебором паролей. Уже тысяча компьютеров сможет обеспечить скорость перебора в полмиллиона паролей в секунду. Объединив в кластер все компьютеры корпорации, можно находить относительно сложные пароли. Но в первую очередь, конечно же, нужно попробовать атаку по словарю.

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