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

Введение

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

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

• 69% опрошенных упоминали проблемы с производительностью;
• 44% опрошенных упоминали сложности с реализацией;
• 25% опрошенных говорили о высокой цене реализации криптографических алгоритмов.

Во многих странах организации подвержены воздействию множества рычагов давления для увеличения "прозрачности" их работы. Но, с другой же стороны, на них лежит установленная законом ответственность за необеспечение сохранности конфиденциальной информации. Так было, в частности, в случае с обувными магазинами корпорации DSW в США).

Федеральная торговая комиссия США выдвинула иск против DSW, в котором было заявлено о необеспечении должного уровня защиты информации и непринятии должных мер для построения адекватных систем ограничения доступа к этим данным, а также о неудовлетворительной защите сетевых соединений между магазинными и офисными компьютерами. В случае с компанией DSW примерно 1,4 миллиона кредитных карт и около 96 тысяч чековых счетов были потенциально доступны преступникам. И прежде чем соглашения между компанией и ФТК были достигнуты, этими счетами уже успели нелегально воспользоваться.

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

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

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

Технические вопросы шифрования

Функции шифрования необходимы всем современным многопользовательским компьютерным системам, где данные, процессы и информация пользователей логически разделяются. Чтобы установить подлинность пользователя в подобной системе, логины и пароли хэшируются и сравниваются с уже имеющимися в системе хэшами (либо хэш используется для расшифровки сеансового ключа, который потом проверяется на валидность). В целях предотвращения несанкционированного просмотра личной информации внутри зашифрованных контейнеров могут храниться отдельные файлы или целые разделы. А сетевые протоколы, например, SSL\TLS и IPSec, позволяют, если это необходимо, усилить криптографическую защиту различных устройств (/dev/random, /dev/urandom и т.д.) с помощью модульных алгоритмов, работающих с ядром операционной системы.

Задача любой технологии шифрования диска состоит в защите от нежелательного доступа к личной информации и в уменьшении урона от потерь интеллектуальной собственности в результате нелегального доступа или кражи физического устройства. Операционная система Linux с версией ядра 2.6.4 представила усовершенствованную криптографическую инфраструктуру, которая просто и надёжно защищает личные данные на многих уровнях программного обеспечения. Существуют как целые стандарты хранения данных в зашифрованном виде на низком уровне, подобно Linux Unified Key Setup (LUKS), так и реализации на пользовательском уровне, например, файловые системы EncFS и CryptoFS, которые, в свою очередь, основаны на Fast Userspace File System (FUSE) под Linux. Конечно же, любая криптографическая система устойчива к взлому настолько, насколько устойчивы её пароли и ключи доступа. Всего существует три основных уровня, на которых применяются технологии шифрования:

• уровень файлов и файловой системы (пофайловое шифрование, контейнер с файлами);
• низкий блочный уровень (контейнер с файловой системой);
• уровень "железа" (специализированные криптографические устройства).

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

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

Некоторые криптографические технологии бесплатны и включены во многие дистрибутивы. Кстати, последние версии Windows оснащаются специальной файловой системой с поддержкой шифрования Encrypted File System (EFS). Fedora поддерживает ряд опций шифрования, включая LUKS (можно включить поддержку LUKS и под Windows, если использовать файловые системы FAT или FAT32 и приложение FreeOTFE). А в дополнительных пакетах Extras доступны FUSE и EncFS. CryptoFS тоже можно установить, скачав с официального сайта. .

Инфраструктура FUSE состоит из загружаемого модуля ядра и userspace-библиотеки, которая служит основой как для файловой системы CryptoFS, так и для Encrypted file system (EncFS). По своей структуре FUSE не затрагивает исходный код ядра и при этом обеспечивает высокую гибкость для реализации многих интересных дополнений, например, файловой системы с удалённым монтированием Secure Shell file system (SSHFS).

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

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

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

Userspace-оверлей, показывающий взаимодействие FUSE и EncFS.

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

LUKS работает без точного знания формата файловой системы.

LUKS разработана в соответствии с Trusted Key Setup #1 (TKS1) и совместима с Windows, если использовать какой-либо общий формат файловой системы (FAT/FAT32). Система хорошо подходит для мобильных пользователей, поддерживает выпуск и отзыв ключей Gnu Privacy Guard (GPG) и абсолютно бесплатна. LUKS способна на гораздо большее, чем любая другая описанная в этой статье реализация. Более того, LUKS поддерживает большое число решений для создания и управления устройствами с шифрованием LUKS.

Файловая система CryptoFS принимает только пароль, в то время как носитель, зашифрованный с помощью LUKS, работает с любыми ключами PGP (Pretty Good Privacy) с любым количеством паролей. EncFS также использует пароль для защиты файлов, но он открывает ключ, хранящийся в соответствующем корневом каталоге.

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

Тестовая конфигурация

Нашей тестовой платформой стал ноутбук Dell Latitude C610, немного устаревший, но всё же достаточно шустрый представитель технологий образца 2002 года. При питании от аккумулятора C610 снижает частоту процессора до 733 МГц. Поэтому во время тестирования мы не отключали ноутбук от розетки. В следующей таблице приведена конфигурация ноутбука

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

Установка

LUKS, FUSE и EncFS доступны в дистрибутиве Fedora, так что дополнительных усилий прилагать не потребуется. А вот CryptoFS придется скачивать отдельно.

Компиляция CryptoFS из исходного кода достаточно проста. Распакуйте архив, выполните конфигурационный скрипт в конечной директории, затем запустите make, как показано на иллюстрации. Файл конфигурации содержит четыре параметра: код шифрования (encryption cipher), алгоритм профиля сообщения (message digest algorithm), размер блока (block size) и счётчик (encryption salt count).

Процесс установки CryptoFS прост.

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

Настройка CryptoFS.

Затем можно запускать команду mount, после чего можно будет видеть смонтированный раздел.

Сначала убедитесь в загрузке модуля ядра FUSE (modprobe fuse). EncFS упрощает процесс создания зашифрованного контейнера, как видно на следующей иллюстрации.

Если опустить процесс установки ключей (который специфичен для каждой ситуации), то LUKS можно легко настроить, как показано ниже.

Тесты и анализ производительности

Различия в производительности между "родной" установкой и установкой в среде, зашифрованной LUKS, достаточно незначительны. Особенно с учётом заметной разницы у userspace-решений. Для поочерёдной оценки производительности зашифрованных файловых систем мы использовали Iozone. Для тестов используются записи от 4 кбайт до 16 Мбайт, размер файла меняется от 64 кбайт до 512 Мбайт, а результат указан в кбайт/с.

Заключение

По крайней мере, там, где используется LUKS, о производительности можно не задумываться. Хотя, конечно, некоторая потеря производительности вызвана "прозрачным" шифрованием данных. Систему LUKS легко и просто установить, а использовать её можно как в Linux, так и под Windows.

Корпоративным пользователям наверняка придётся столкнуться с ограничениями, связанными с политикой компании. Часто они запрещают решения на основе открытого исходного кода или запрещают некоторые реализации. Кроме того, иногда приходится учитывать ограничения по импорту/экспорту технологий шифрования, касающиеся стойкости кода, или ИТ-департамент требует телефонной поддержки со стороны поставщика решения, что позволяет забыть о LUKS, EncFS и CryptoFS. В любом случае, LUKS - прекрасное решение, если подобные проблемы вас не беспокоят. Хороший вариант для малого бизнеса или для домашних пользователей.

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

Мнение редактора

CryptoFS и EncFS - userspace-реализации. Как мы объясняли ранее, они отличаются простотой дизайна и реализации, но за это приходится платить производительностью и возможностями. Особенно это очевидно при сравнении с LUKS. Она не только работает ощутимо быстрее, но также поддерживает один или несколько PGP-ключей и может использоваться на всём разделе.

Userspace-контейнеры важны, в первую очередь, для пользователей, которые желают защитить личную информацию в многопользовательском окружении. И кому нужно защитить свои данные так, чтобы даже администратор не смог получить доступ к аппаратным или программным ресурсам. Кроме преимуществ по производительности и межплатформенной поддержке, LUKS прекрасно интегрируется с GNOME и системами управления PGP-ключами. А лёгкость повседневного использования шифрованных LUKS разделов просто впечатляет. Кстати, EncFS поддерживает Pluggable Authentication Module (PAM) под Linux в соответствующих окружениях.

В конце ноября 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 уже не хватает вычислительной мощности одного компьютера. Однако существуют приложения, способные объединять компьютеры в кластер, который будет заниматься перебором паролей. Уже тысяча компьютеров сможет обеспечить скорость перебора в полмиллиона паролей в секунду. Объединив в кластер все компьютеры корпорации, можно находить относительно сложные пароли. Но в первую очередь, конечно же, нужно попробовать атаку по словарю.

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

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 для дешифрования этих ключей.

II. Общие требования и правила оформления текстов исследовательских работ.

II. Требования к структуре образовательной программы дошкольного образования и ее объему

III. ТРЕБОВАНИЯ К РЕЗУЛЬТАТАМ ОСВОЕНИЯ СОДЕРЖАНИЯ ДИСЦИПЛИНЫ

IV. Единые требования к использованию и сохранности учебников для учеников и их законных представителей

V. Требования к подготовке и оформлению конкурсной работы

В криптографии с секретным ключом обычно рассматривают следующие криптоатаки.

Атака на основе шифртекста

Атака на основе известного открытого текста

Атака на основе выбранного открытого текста

Требования:

1. Число возможных действующих ключей должно быть непереборно велико.

Это требование вытекает непосредственно из существования тривиального переборного способа криптоанализа. Непереборность ключевых данных является наиболее легко выполнимым требованием. Действительно, если, например, ключ устанавливается на двух коммутаторах 32´32 то полное число возможных ключей оказывается равным /32!/ = 6,92 ´10 70 .

Если каждую секунду опробовать 10 6 ключей (фактически нужно не только изменять ключи, но и проверять на каждом из них осмыслен­ность дешифруемого сообщения), то перебор всех ключей составит - приблизительно 2,19´10 57 лет, а среднее время перебора будет в 2 раза меньше. Очевидно, что даже увеличив быстродействие на десять порядков, получим необозримо большое время перебора. Если ключ имеет длину 256 бит, то общее число ключей равно 2 256 = 1,16´10 77 , а полное время перебора составит, при опробовании 10 6 ключей в секунду, 3,67 * 10 63 лет. Прогресс в области повышения быстродействия ЭВМ например на 3 порядка, то есть переход к опробованию 10 9 ключей в секунду, может быть скомпенсирован добавлением 10 бит ключа.

Ясно также, что задействование для криптоанализа вместо одной ЭВМ например 10 9 комплектов, что значительно превышает число всех имеющихся на земле вычислительных машин, не повлияет на общий вывод о непереборности ключевых данных.

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

2. Статистика сообщений должна быть в значительной мере исключена из статистики криптограммы.

Поясним на простом примере как неудовлетворение этого требования может позволить просто дешифровать сообщение. Пусть используется шифр простои замены, который имеет для русского алфавита 32! = 2,63´10 35 возможных ключей. Однако, если вычислить частоты появле­ния различных букв в криптограмме и сопоставить их с таблицей вероятностей букв в русском языке, то можно по их совпадению определить каким буквам сообщения соответствуют буквы криптограммы, то есть произвести дешифрование криптограммы за короткое время без знания ключа.

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

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

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

Необходимость выполнения второго и особенно третьего требова­ния приводит к существенным изменениям в структуре шифратора.

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

4. Исключение "чтения назад".

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

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

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

1. Обеспечение специальных требований.

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

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

| | | | | 6 | |