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

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

Введение

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

В декабре 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 в соответствующих окружениях.

Применимо к: Office 2013, Office 365 ProPlus

Последнее изменение раздела: 2016-12-16

Сводка . В этой статье рассказывается о параметрах, с помощью которых можно шифровать данные в Office 2013, и совместимости с предыдущими версиями Office.

Аудитория: ИТ-специалисты

Office 2013 включает параметры, позволяющие управлять способом шифрования данных при использовании Access 2013, Excel 2013, OneNote 2013, PowerPoint 2013, Project 2013 и Word 2013.

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

Планируя применение параметров шифрования, учитывайте следующее.

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

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

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

Если пользователям разрешено защищать документы с помощью паролей, то в случае потери пароля с помощью средства DocRecrypt вы сможете сбросить или удалить пароль. Дополнительные сведения см. в статье Удаление и сброс паролей файлов в Office 2013 (Удаление или сброс паролей в Office 2013).

В этой статье

Параметры криптографии и шифрования

Криптография и шифрование в Office 2010

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

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

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

HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Cryptography/Defaults/Provider

Указанные ниже алгоритмы шифрования CNG, а также другие установленные в системе расширения шифрования CNG можно использовать с Система Office 2007 с пакетом обновления 2, Office 2010 и Office 2013:

AES, DES, DESX, 3DES, 3DES_112 и RC2.

Указанные ниже алгоритмы хэширования CNG, а также другие расширения шифрования CNG, установленные в системе, можно использовать с Система Office 2007 с пакетом обновления 2, Office 2010 и Office 2013:

MD2, MD4, MD5, RIPEMD-128, RIPEMD-160, SHA-1, SHA256, SHA384 и SHA512.

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

Параметры криптографии и шифрования

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

Параметры алгоритмов шифрования для использования с CryptoAPI

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

В следующей таблице приведены параметры, с помощью которых можно изменить алгоритмы шифрования при использовании Office 2013. Эти параметры применяются к Access 2013, Excel 2013, OneNote 2013, PowerPoint 2013, Project 2013 и Word 2013.

Параметры, изменяющие алгоритм шифрования

В следующей таблице указаны дополнительные параметры CNG, которые можно настроить для Excel 2013, PowerPoint 2013 и Word 2013.

Параметр CHG для Excel 2013, PowerPoint 2013 и Word 2013

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

Параметр, который запрещает пользователям защищать документы с помощью паролей

Совместимость с предыдущими версиями Office

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

В Office 2013, Office 2010 и Система Office 2007 можно сохранять документы в формате Open XML. Кроме того, при наличии Office XP или Office 2003 можно использовать пакет обеспечения совместимости, чтобы сохранять документы в формате Open XML.

Документы, сохраненные в формате Open XML и зашифрованные с помощью Office 2013, доступны для чтения только в Office 2013, Office 2007 с пакетом обновления 2 и Office 2003 с пакетом обеспечения совместимости Office 2007 с пакетом обновления 2. Чтобы гарантировать совместимость со всеми предыдущими версиями Office, можно создать раздел реестра (если он еще не создан) CompatMode в разделе HKCU\Software\Microsoft\Office\14.0\\Security\Crypto\ и отключить его, установив значение 0 . Значения, которые можно вводить для <приложения>, представляют определенное приложение Office, для которого можно настроить этот раздел реестра. Например, можно ввести Access, Excel, PowerPoint или Word. Необходимо помнить, что когда для CompatMode устанавливается значение 0 , Office 2013 использует формат шифрования, совместимый с Office 2007, вместо усиленной безопасности, которая по умолчанию действует при использовании Office 2013 для шифрования файлов в формате Open XML. Если нужно настроить этот параметр для целей совместимости, рекомендуется также использовать модуль шифрования стороннего поставщика, обеспечивающий усиленную безопасность, например шифрование AES.

Если для шифрования файлов Open XML организация использует пакет обеспечения совместимости Microsoft Office для форматов файлов Word, Excel и PowerPoint, ознакомьтесь со следующей информацией.

По умолчанию в пакете совместимости используются следующие параметры шифрования файлов в формате Open XML.

• Microsoft Enhanced RSA and AES Cryptographic Provider (прототип), AES 128, 128 (в операционной системе Windows XP Professional).

  Microsoft Enhanced RSA and AES Cryptographic Provider, AES 128, 128 (в операционных системах Windows Server 2003 и Windows Vista).

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

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

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