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

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

В этой статье

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Защита в COM

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

openxmlformats.org/officeDocument/2006/math”

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

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

wordprocessingDrawing” xmlns:w10=”urn:schemas-

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

schemas.openxmlformats.org/wordprocessingml/2006/

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

office/word/2006/wordml”>

w:rsidRDefault=”00FC4BE5">

Test Word file…

w:rsidSect=”00021ED4">

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

w:gutter=”0" />

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

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

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

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

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

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

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

w:cryptAlgorithmClass=”hash” w:cryptAlgorithmType=

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

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

”gmd47MvIcN4OwJ5dPxZL6Q==” />

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Применимо к: 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

Параметр	Описание
	С помощью этого параметра можно выбрать тип шифрования для файлов Open XML из доступных поставщиков служб шифрования (CSP). Этот параметр необходим при использовании надстройки с настраиваемым шифрованием модели COM. Этот параметр также необходим, если используется Система Office 2007 с пакетом обновления 1 или старая версия пакета обеспечения совместимости Microsoft Office для форматов файлов Word, Excel и PowerPoint и нужно изменить алгоритм шифрования на отличный от установленного по умолчанию.
Тип шифрования для защищенных паролем файлов Office 97–2003	С помощью этого параметра можно выбрать тип шифрования для файлов Office 97–2003 (двоичные) из доступных поставщиков службы шифрования (CSP). С этим параметром поддерживается всего один алгоритм шифрования - RC4, который не рекомендуется использовать.

Если в 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	Позволяет настроить используемый алгоритм шифрования CNG. Значение по умолчанию: AES.
Настройка режима цепочки шифрования CNG	Позволяет настроить используемый режим цепочки шифрования. Значение по умолчанию: Cipher Block Chaining (CBC) .
Задать длину ключа шифрования CNG	Позволяет указать количество битов, которые будут использоваться при создании ключа шифрования. Значение по умолчанию: 128 бит.
Задать совместимость шифрования	Позволяет указать формат совместимости. Значение по умолчанию: Использовать формат следующего поколения .
Задать параметры для контекста CNG	Позволяет указать параметры шифрования, которые следует использовать для контекста CNG. Чтобы использовать этот параметр, сначала необходимо создать контекст CNG с помощью CryptoAPI: Next Generation (CNG). Дополнительные сведения см. в статье Функции конфигурации шифрования CNG .
Задать алгоритм хэширования CNG	Позволяет указать используемый алгоритм хэширования. Значение по умолчанию: SHA1.
Задать число смен хэша пароля CNG	Позволяет указать количество смен хэша в средстве проверки пароля. Значение по умолчанию: 100000.
Задать алгоритм генерации случайных чисел CNG	Позволяет настроить генератор случайных чисел CNG, который будет использоваться. Значение по умолчанию: RNG (Random Number Generator).
Задать длину соли CNG	Позволяет указать количество байтов соли, которое нужно использовать. Соль является дополнительными входными данными на ряду с паролем и хэшем. Значение по умолчанию: 16.

В следующей таблице указаны дополнительные параметры 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.