Издательский дом ООО "Гейм Лэнд"СПЕЦВЫПУСК ЖУРНАЛА ХАКЕР #58, СЕНТЯБРЬ 2005 г.

Сделай это безопасным!

Alek Silverstone

Спецвыпуск: Хакер, номер #058, стр. 058-072-6


TGS –> Клиент: Шифровать(С(клиент, сервер), С(клиент, TGS))

TGS –> Клиент: М(клиент, сервер)

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

Клиент -> Сервер: Шифровать(У(клиент)+НС, С(клиент, сервер))

Клиент -> Сервер: М(клиент, сервер)

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

Сервер -> Клиент: Шифровать(t, НС)

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

Как видишь, атакующий обложен со всех сторон :). Если он не знает секретный ключ клиента, он беспомощен. Правда, две атаки в этом случае возможны, но их нельзя назвать атаками на Kerberos. Первая основана на том, что часы на всех объектах сети должны быть синхронизированы с некоторой точность, заложенной в проверке меток времени. Если время сервера будет установлено неправильно, то возможно использование старого удостоверения. Еще опаснее атака на программу пользователя – замена ее внешней копией, которая к тому же сохраняет пароли. Но, как ты понимаешь, это характерно для всех программ.

Частые ошибки

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

1. Длительность жизни ключей. Ключи нужно постоянно обновлять. Время жизни асимметричной пары зависит от ее размера: чем больше ключ, тем дольше его будут подбирать и тем безопаснее его использование в отведенный промежуток времени. Не рекомендуется использовать симметричные ключи больше одного раза.

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

3. Использование собственных алгоритмов. Очень частая ошибка начинающих. Основное правило криптографии, сформулированное еще в XIX веке, гласит: "Знание алгоритма шифрования не должно снижать криптостойкости шифра". Сразу вспоминаются программы в open source: в них повышение защищенности идет гораздо быстрее, чем в закрытом ПО. Мир криптографии знает множество "защищенных" закрытых протоколов (ярчайший пример - WEP), взломанных из-за их непродуманности. Противоположный пример – стандарт AES: конкурс был долгосрочным и открытым, с привлечением толпы независимых экспертов. В общем, если ты не окончил факультет прикладной математики с красным дипломом, то не самодельничай. Даже если окончил, тоже не самодельничай :).

Назад на стр. 058-072-5  Содержание  Вперед на стр. 058-072-7