Смекни!
smekni.com

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

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

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

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

- Научные исследования часто игнорируют определенные "малые" кажущиеся "тривиальными" проблемы, которые необходимо решать в приложениях и стандартах. Однако такие мелкие детали могут иметь существенные последствия для безопасности. Хорошим примером является механизм, который указывает, какая хэш-функция была использована вместе со схемой подписи, см. Калински [12].

- Органы стандартизации не всегда в курсе самых последних учебных событий.

Успешные стандарты требуют ограниченного числа полностью заданных алгоритмов, что требуется для функциональной совместимости. Однако алгоритм является полезным только при наличии достаточного доверия, получаемого после проведения тщательной оценки безопасности. Она может включать проверку статистических и очевидных уязвимостей, применяя известные атаки, оценку безопасности от новых атак и тщательную проверку всех доказательств безопасности (необходимость в этом может быть проиллюстрирована, ошибка найдена Шоапом в 7-летний OAEP доказательство безопасности [28], ошибка была исправлена для RSA-OAEP Фуджисаки и др. [10]).

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

3. Проект NESSIE

Проект NESSIE (NewEuropeanSchemesforSignature, Integrity, andEncryption) – Новые европейские Схемы для электронной подписи, целостности и шифрования – является научно-исследовательским проектом в рамках технологий информационного общества (IST) Программы Европейской Комиссии. Участники проекта: Католический университет Левена (Бельгия), координатор, Ecole Normale Sup'erieure (Франция), Royal Holloway, Лондонский университет (Великобритания), Siemens Aktiengesellschaft (Германия), Technion - Израильский технологический институт (Израиль), католический университет Лувена (Бельгия), и университет Берген (Норвегия). NESSIE является 40-месячным проектом, начавшегося 1 января 2000 года. Подробная и актуальная информация о проекте NESSIE доступна на http://cryptonessie.org/.

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

3.1 Конкурс NESSIE

В первый год проекта, был открыт конкурс на представление криптографических алгоритмов, а также был запущен процесс оценки методологии таких алгоритмов. Рамки этого конкурса были определены совместно с советом проекта промышленности (PIB); конкурс был объявлен в феврале 2000 года. Последним сроком подачи заявок было 29 сентября 2000 года. В ответ на этот конкурс NESSIE получил 40 предложений, каждое из которых было сопоставлено с предъявляемыми требованиями.

Конкурс NESSIE включает в себя запрос широкого круга алгоритмов, обеспечивающих конфиденциальность данных, аутентификацию данных, а также аутентификацию объектов. Эти алгоритмы включают блочные шифры, потоковые шифры, хеш-функции, MAC-алгоритмы, цифровые схемы подписи, шифрование открытого ключа и схемы идентификации (описание этих алгоритмов, см. [18]). Кроме того, конкурс NESSIE принимает методологии оценки для этих алгоритмов. Хотя ключевые протоколы создания также очень важны, было принято решение, что они должны быть исключены из конкурса, так как рамки конкурса и так достаточно широки.

Рамки конкурса NESSIE были гораздо шире, чем у конкурса AES запущенного NIST [20], который был ограничен лишь 128-битовыми блочными шифрами. Проект NESSIE так же сопоставим с проектом RACE (Research and Development in Advanced Communications Technologies in Europe) – RIPE (RACE Integrity Primitives Evaluation, 1988 – 1992) [26] (алгоритмы конфиденциальности были исключены из RIPE по политическим причинам), и японским проектом CRYPTREC [6] (который также включает в себя протоколы образования ключа и поколение псевдослучайных чисел). Другим отличием проекта NESSIE является то, что AES и CRYPTREC намерены производить алгоритмы для государственных стандартов. Результаты проекта NESSIE не будут приняты каким-либо правительством или Европейской комиссией. Тем не менее, планируется, что соответствующие органы по стандартизации примут эти результаты. Как, например алгоритмы цифровой подписи и хэш-функции могут быть включены в документы стандартизации EESSI, которые определяют алгоритмы, рекомендуемые для директивы европейской электронной подписи.

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

Для обеспечения требований безопасности симметричных алгоритмов, заданы два основных уровня безопасности, называемые нормальным и высоким. Минимальные требования для симметричного алгоритма достигаются либо нормальным, либо высоким уровнем безопасности, зависящим от длины ключа, внутренней памяти или выходной длины алгоритма. Для блочных шифров третьего уровня безопасности, для нормального и высокого уровня, считается ключ с размером блока 64 и 128 бит. Примером подобных требований являются такие приложения, как UMTS/3GPP, использование 64-разрядных блочных шифров в которых, планируется в ближайшие 10 – 15 лет. Для асимметричных алгоритмов общепринят изменяемый уровень безопасности, с минимум 280 3-DES шифрования.

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

Представленные в проекте NESSIEтребования, гораздо менее строгие, чем для AES, особенно в случае с требованиями для программных реализаций (только "портативный C" является обязательным).

3.2 Процедура оценки NESSIE

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

3.2.1.Оценка безопасности

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

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

Далее, открытый семинар был организован в Egham (Великобритания) 12-13 сентября 2001 года для обсуждения безопасности и производительности анализа представленных материалов. На семинаре присутствовали представители проекта NESSIE, участники конкурса, представители NESSIEPIB и члены криптографического сообщества.

После окончания семинара был опубликован полный доклад об оценке безопасности (D13 [19]). Данный документ давал общее представление о характерных атаках на различные типы алгоритмов. Кроме того, для каждого симметричного алгоритма он представлял краткое описание, требования безопасности разработчиков, описание уязвимостей и известных атак. Часть, посвященная асимметричным алгоритмам, содержала обсуждение предположений безопасности, модели безопасности, а также методологии оценки безопасности. Для каждого алгоритма, краткое описание сопровождалось обсуждением доказуемой безопасности (свойства безопасности доказаны в соответствии с условиями и предположениями), а также конкретные проблемы безопасности.