8.4 Проверка ключей

Как Боб узнает, получив ключ, что ключ передан Алисой, а не кем-то другим, кто выдает себя за Алису? Все просто, если Алиса передает ему ключ при личной встрече. Если Алиса посылает свой ключ через доверенного курьера, то курьеру должен доверять и Боб. Если ключ зашифрован ключом шифрования ключей, то Боб должен доверять тому, что этот ключ шифрования ключей есть только у Алисы. Если для подписи ключа Алиса использует протокол электронной подписи, Боб при проверке подписи должен доверять базе данных открытых ключей,. (Ему также придется считать, что Алиса сохранила свой ключ в безопасности.) Если Центр распределения ключей (Key Distribution Center, KDC) подписывает открытый ключ Алисы, Боб должен считать, что его копия открытого ключа KDC не была подменена.

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

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

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

Боб мог бы также проверять ключ Алисы по телефону, получив возможность услышать ее голос. Распознавание голоса действительно является хорошей схемой идентификации личности. Если речь идет об открытом ключе, он может безопасно его повторить его даже при угрозе подслушивания. Если это секретный ключ, он может использовать для проверки ключа одностороннюю хэш-функцию. Оба TSD PGP (см. раздел 24.12.) и AT$T (см. Раздел 24.18) используют этот способ проверки ключей.

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

Обнаружение ошибок при передаче ключей

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

Одним из наиболее широко используемых методов является шифрование ключом некоторой постоянной величины и передача первых 2-4 байт этого шифротекста вместе с ключом. У получателя делается то же самое. Если шифрованные константы совпадают, то ключ был передан без ошибки. Вероятность ошибки находится в диапазоне от 1/2¹⁶ до 1/2³².

Обнаружение ошибок при дешифрировании

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

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

Вот для этого способ получше [821]:

1. Сгенерите вектор идентификации (отличный от используемого в сообщении).

2. Используйте этот вектор идентификации для генерации большого блока битов: скажем, 512.

3. Хэшируйте результат.

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

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

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