Защита криптографических ключей

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

Хотя для достижения этой цели можно применить несколько технологий, все они имеют свои недостатки. Рассмотрим доступные варианты и ситуации, для которых они наиболее приемлемы.

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

Эти характеристики, как правило, включают кодовую фразу, по которой создается ключ, и, возможно, другие значения, например инициализирующий вектор (initialization vector). Что бы вы ни выбрали — кодирование байтов ключа или реализацию логики генерации ключа, вы в конечном счете скрываете ключ в исходном коде приложения.Такой вариант дает вам больший контроль и гибкость, но и подвергает ваши данные большему риску в случае обратного проектирования вашего приложения. В качестве альтернативы можно хранить ключ в постоянном хранилище вроде файла или реестра и защищать это хранилище с помощью ACL. Но такой подход чреват ошибками при сопровождении, поэтому я не рекомендую его.

Более безопасный, но менее гибкий способ генерировать ключи — позволить операционной системе делать это за вас. Для этого используются та кие средства операционной системы, как Local Security Authority (LSA) или DPAPI.

Берегитесь LSA

Во времена расцвета Windows NT 4.0 функции LSA Policy LsaStore PrivateData и LsaRetrieve Private Data предоставляли достаточно надежный способ защиты секретов приложения. Хотя функции LSA Policy доступны в Windows 2000 и выше (и по-прежнему используются для защиты таких данных, как пароли для служб Windows), Microsoft не рекомендует применять их, поэтому я упомянул эти функции лишь для полноты картины,

чтобы объяснить, почему их следует избегать. Проблема с функциями LSA Policy в том, что они не только управляют ключами и шифруют их, но и работают с хранилищами данных, используя защищенную область реестра Windows. Может показаться, что это хорошо, но это не так, потому что объем доступного места для функций LSA Policy ограничен 4096 слотами, половина из которых уже занята системой. Если приложения будут использовать LSA Policy для хранения секретных данных, им просто не хватит места. Далее, поскольку лишь в высшей степени привилегированные пользователи могут вызывать функции LSA Policy, они не сработают для приложений, выполняемых под непривилегированными учетными записями, такими как ASP.NET. Хуже того, существуют инструменты вроде LSADUMP2 (http://razor.bindview.com/tools/desc/Isadump2_readme.html), способные раскрыть секреты LSA. Вывод: не применяйте функции LSA Policy для защиты данных.

Использование DPAPI

Как альтернативу функциям LSA Policy компания Microsoft рекомендует применять подмножество Crypto API, которое называется DPAPI. DPAPI включает две функции, пригодные для защиты данных: CryptProtectData и CryptUnprotectData. Эти функции реализованы в crypt32.dll и могут вызываться из приложений.NET Framework через P/Invoke. DPAPI является частью операционной системы и доступен в Windows 2000 и выше.

DPAPI — в отличие от функций LSA — не работает с хранилищами данных, но способен создавать индивидуальные для машины или пользователя ключи для шифрования и расшифровки данных. Чтобы различать два типа ключей, в документации DPAPI их называют хранилищем машины (machine store) и хранилищем пользователя (user store).

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

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

Хотя существует' способ обойти эти ограничения через обслуживаемые компоненты (serviced components), расплатой за него станет рост сложности и снижение производительности приложения. Этот способ также требует, чтобы обслуживаемый компонент выполнялся под привилегированной учетной записью, что нарушает принцип наименьшей привилегии. Если вы решите использовать DPAPI с ключами для пользователей, учтите, что только пользователь, зашифровавший данные, сможет расшифровать результат. Очевидно, это неприемлемо для приложений, выполняемых под разными учетными записями, или для программ, чьи параметры могут определяться разными пользователями. Другая проблема ключей, специфичных для пользователей, в том, что они позволяют всем приложениям, выполняемым в одном профиле пользователя, получать доступ к данным /[руг друга, что может стать брешью в защите. Как и в случае с DPAPI, использующим хранилища машины, эту проблему можно решить, требуя от вызвавшего кода предоставить вторичную энтропию, но, как и в предыдущем примере, возникнет проблема с хранением этой энтропии. К сожалению, DPAPI не позволяет одновременно использовать ключи, специфичныедля машины и специфичные для пользователя (в одном вызове CryptProtectData).

DPAPI рекомендуется для приложений, которые выполняются под одной учетной записью с загружаемым профилем пользователя, и чьи параметры определяются одним пользователем. (Более подробную информацию см. во врезке ≪Загружаемый профиль пользователя≫.) Типичный пример — служба Windows, выполняемая под учетной записью локального или доменного пользователя. Если ваше приложение удовлетворяет этим требованиям, ему следует задействовать DPAPI с ключами, специфичными для пользователей. В других приложениях можно использовать DPAPI с ключами, специфичными для машины и защищенными вторичной энтропией (см. http://msdn.microsoft.com/library/en-us/dnnetsec/html/SecNetHTOS.asp и http://www.obviex.com/samples/dpapi.aspx). Вы можете определить эту энтропию в исходном коде приложения и затемнить двоичный файл приложения, чтобы обнаружить энтропию было непросто. Но если вы изберете такой способ, учтите, что даже затемненный код может.быть подвергнут обратному проектированию. Чтобы узнать, что может и чего не может предложить вам затемнение, прочтите статью Брента Ректора (Brent Rector) ≪The Premier Obfuscator for Microsoft.NET Applications!≫ по ссылке http://www.wintellect.com/resources/newsletters/2002/aug2002.aspx и статью Габриэла Торока (Gabriel Torok) и Билла Лича(Bill Leach) в этом номере.

Загружаемый профиль пользователя

Хотя в документации Microsoft одним из требований к приложению, в котором применяется DPAPI с хранилищем пользователя, указан загружаемый профиль пользователя, там не объясняется, что это такое. Если вы озадачены этим термином, считайте, что это профиль интерактивного пользователя, который создается, когда пользователь впервые регистрируется в системе. Все приложения, интерактивно запущенные пользователем, выполняются с загруженным профилем интерактивного пользователя. Неинтерактивные приложения, такие как службы Windows, настроенные на выполнение под LocalSystem, не могут загружать профиль пользователя и, таким образом, не в состоянии задействовать DPAPI с хранилищем пользователя. То же можно сказать и о системных процессах, таких как процессы ASP.NET, которые выполняются под встроенными учетными записями. Чтобы позволить службам Windows обращаться к DPAPI с хранилищем пользователя, их следует настроить на выполнение под учетными записями локальных или доменных пользователей с уже созданным профилем. На практике это означает, что до того, как приложение сможет выполнять вызовы DPAPI от имени пользователя, тот должен хотя бы один раз интерактивно войти в систему.

Если ваше приложение не может напрямую использовать DPAPI с ключами, специфичными для пользователей, а вы не хотите примириться с угрозой обратного проектирования, подумайте о реализации DPAPI с обслуживаемым компонентом, но учтите, что это негативно отразится на производительности вашего приложения [см. ≪Use DPAPI (User Store) from

Если вы определяете ключ в приложении, то, кроме затемнения сборки, старайтесь не хранить реальные байты ключа в исходном коде. Вместо этого реализуйте логику генерации ключа на основе постоянных характеристик, таких как алгоритм шифрования, размер ключа, кодовая фраза, инициализирующий вектор, и ≪расширение≫ (см. пример по ссылке http://www.obviex.com/samples/encryption.asp). Это внесет дополнительный уровень неопределенности, и ключ не удастся получить простым дампом символов из двоичного файла сборки. Так как логика генерации ключа и его характеристики постоянны, неизменность результирующего ключа гарантирована. Также хорошей идеей будет отказ от использования статических строк в качестве характеристик для генерирования ключа и их создание ≪на лету≫. Еще можно предложить рассматривать сборку так же, как хранилище данных, т. е. применять соответствующие ACL. И прибегайте к этому варианту лишь в качестве крайней меры, когда никакая другая технология защиты данных неприменима и единственной альтернативой остается хранение секретных данных в незашифрованном виде.

Изолированное хранилище

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

Заключение

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