значения. ofstream file("c:\\keys\\key.bin", ios_base:binary); file.write(reinterpret_castconst char *(pbKey), dwLen); file.close(); } catch(e), cerr "Ошибка " ehex " " e endl; Выполняем очистку. if (hExchangeKey) CryptDestroyKey(hExchangeKey); if (hKey) CryptDestroyKey(hKey); if (hProv) CryptReleaseContext(hProv, 0); if (pbKey) delete pbKey; } Этот код вы найдете в папке Secureco\Chapter. Имейте в виду, что функция GetExchangeKey всего лишь пример, в реальном приложении она должна получать сеансовый ключ из его хранилища или от пользователя. Теперь вы можете получать из хранилища ключ в зашифрованной форме и шифровать и расшифровывать им данные, даже не зная, как он выглядит! Приложение генерирует два DES-ключа. DES это алгоритм шифрования, в котором данные последовательно шифруются тремя различными ключами. Его труднее взломать, чем простой DES. Проблемы обмена ключами Обмен ключами это одна из самых сложных и неблагодарных подзадач общей задачи управления ключами. Как-никак, если хакеру удастся скомпрометировать процесс обмена ключами, он получит доступ к ключам шифрования данных и в итоге сможет нокаутировать приложение. Основная угроза, которую таит в себе небезопасный или ненадежный механизм обмена ключами, раскрытие и порча информации. И то, и другое дает возможность атаковать подменой сетевых 240 Часть II Методы безопасного кодирования объектов (spoofing), если ключ применяется для аутентификации или подписи данных. Помните: подпись служит для подтверждения подлинности и целостности документа, и если ключ подписи скомпрометирован, то за целостность документа поручиться нельзя. Существует несколько правил, которыми следует руководствоваться при организации обмена ключами. Некоторые ключи никогда не должны участвовать в обмене! Например, закрытые ключи подписи (на то они и закрытые! ). Так что каждый раз спрашивайте себя: Действительно ли необходимо делать этот ключ общим? Вы сами удивитесь, как часто обмен окажется совершенно ненужным и вас устроит какой-нибудь другой безопасный протокол, где обмен не требуется. Как я уже говорил, никогда не прописывайте ключ в коде. Раз и навсегда решить проблему обмена ключами можно, вообще не прибегая к помощи ключей. Однако, если вы все-таки решите задействовать ключ, а хакер его взломает (а при малейшей возможности он это сделает, не сомневайтесь), готовьтесь к большой ложке дегтя (об этом в главе 9). Не исключайте возможности приделать ноги сменным носителям для обмена ключами (то есть позаботьтесь, чтобы обмен ключами выполнялся с помощью дискет, дисков, лент и других сменных носителей)*. Весьма трудно пере хватить ключ, когда для его доставки используются люди, а не линии связи. Правда это менее удобно, но в свете проблем с безопасностью вполне терпимо, а усилия окупаются сторицей. Подобный режим поддерживает утилита администрирования IPSec в Windows 2000 и более поздних ОС. На рис. 8-4 показано диалоговое окно сохранения сертификата, который затем пользователь доставляет на своих двоих. Рис. 84. В диалоговом окне выбора способа аутентификации предоставляется возможность использовать сертификат вместо сетевого механизма обмена ключами * В английском языке подобная сеть, в которой перенос данных осуществляется не по линиям связи, а путем переноса сменных носителей с данными, называется sneakernet, от sneaker кроссовка и net сеть. Прим. перев. ГЛАВА 8 Подводные камни криптографии 241. Подумайте, может, стоит установить протокол, который возьмет обмен ключами на себя. Это применимо лишь для краткосрочных и временных данных, например тех, что передаются по сети. Так, в протоколах SSLTLS и IPSec перед передачей данных выполняется обмен ключами. Подобный метод не годится, если данные хранятся в реестре или базе данных. И все-таки: для обмена ключами выбирайте проверенные механизмы, которым можно доверять стопроцентно, например согласование ключей Диффи Хеллмана (Diffie Hellman) или обмен ключами по алгоритму RSA. Ни в коем случае не изобретайте собственный протокол.