Покупка нужных ингредиентов: небольшой список продуктов для безопасного канала
За относительно короткий период времени я заметил тенденцию в проектировании инфраструктур, которые включают механизмы для выполнения некоторых криптографических целей. Неудачи предостаточно, и понятно почему. Иногда система разрабатывается кем-то, кто так же квалифицирован для выполнения этой работы, как слепой шимпанзе, чтобы выполнить операцию по шунтированию вчетверо во время езды на одноколесном велосипеде в час пик по шоссе I-85. Вы не можете ожидать плодотворного результата, мягко говоря. Если вы не можете поставить правильный диагноз, вы не сможете решить существующую проблему, из-за которой большинству этих некачественных систем не хватает фундаментальных компонентов, потому что соответствующие цели проектирования никогда не ставились. Это приводит к ужасным дизайнерским решениям, которые обычно являются результатом чистой некомпетентности.
То, что я изложу ниже, ни в коем случае не является исчерпывающим списком всего, что вам когда-либо понадобится, учитывая, что требования меняются вместе с каждым сценарием, но это охватывает целую чайную ложку некоторых важных компонентов, которые требуют, чтобы они были результат правильных решений. Я смешаю практические компоненты с небольшой теорией и засыплю вас некоторыми необходимыми ресурсами. Если вы когда-либо хотели получить простой, самоуверенный ответ о том, как начать проектирование безопасного канала, это укажет вам правильное направление. Чтобы все было просто, последовательно и в основном ориентировано на стандарты, следующий совет сосредоточен на блочном шифре — AES.
Длины ключей и уровни безопасности
Я начну с чего-то, в чем я не могу винить всех подряд, поскольку есть среды, которые настолько сильно ограничены, что замечается каждая маленькая «мелочь»; то есть симметричная длина ключа. Если вы обратитесь к криптографическому сообществу за советом относительно консервативной длины ключа, ответ, который вы получите, скорее всего, будет двояким. Во-первых, вы услышите «128-бит» как хорошее значение, но мы не говорим о самой длине ключа. Например, можно сказать что-то вроде: «Используйте 256-битный ключ и заявите о 128-битной стойкости проекта». Посмотрите на «силу конструкции» как на ожидаемый уровень безопасности. Некоторые криптографы разрабатывают блочные шифры на основе этой консервативной философии, а другие нет. Я считаю, что это хороший совет, поэтому рекомендую следовать ему, если сможете. Как я уже говорил в начале этого абзаца, реализация этого на практике может быть нежизнеспособным решением из-за жестких ограничений, поэтому постарайтесь максимально приблизиться к 128-битной безопасности ваших 128-битных ключей. Общая поговорка, которую Конфуций не сказал, но, вероятно, мог бы осуществить: « Лучший разработчик, который хочет иметь n битов безопасности, будет использовать 2 n битов ключевого материала». Не волнуйся; вы не уступаете, если ограничения говорят, что вы не можете, но делаете все возможное.
Фламандский. Рыба. Змея. Выбор сделать.
Снова и снова я слышу, как непрофессионалы с уверенностью говорят: «Я предпочитаю Twofish» или «Мне больше нравится Serpent». Мой заготовленный вопросительный ответ обычно звучит так: «Не могли бы вы пояснить, почему?» Я получаю всевозможные ответы, от «Э-э, я просто хочу» до «AES небезопасен. Вот почему АНБ разрешило ему стать стандартом». (Я уже добавил два цента и пять центов на то, почему последний ответ является необоснованным и спекулятивным, и почему я считаю, что стандартизация Rijndael, наряду со всей конкуренцией AES, была успешной с точки зрения построения криптографического характер Rijndael, а также направляет нас в правильном направлении для выбора новых примитивов, которые будут служить эталонами.) Я долгое время был сторонником многочисленных принципов дизайна, демонстрируемых Twofish, и Serpent, без сомнения, был фигуративным танком связка; я с большим уважением отношусь к тому, что они включены в мою группу рекомендуемых блочных шифров, когда вы не можете использовать AES или когда нишевые среды требуют чего-то другого. Но когда есть возможность — пользуйтесь. Он упрощен, элегантен и включает в себя больше криптоанализа, чем любой из других финалистов, включая Twofish и Serpent. Мало того, он выдерживает криптоанализ. Никто не может винить вас за его использование. Это надежный способ сохранить конфиденциальность сообщений.
Манипулировать часто хуже, чем разглашать
Уже ожидая ответа, когда моя реплика свернута и готова нанести удар, один из первых вопросов, который я задаю разработчику, звучит так: «Каковы ваши цели безопасности для канала между Алисой и Бобом?» К счастью, есть капелька надежды благодаря тем, кто сделал свою домашнюю работу. Однако слишком часто я слышу: «Все, о чем мы заботимся, это то, чтобы никто не мог прочитать трафик между Алисой и Бобом». Как насчет: «Нет, это не все, что тебя волнует». По крайней мере, это не все, о чем вы должны заботиться. Эта проблема наступает на пятки единственной вещи, по которой люди, вероятно, меня запомнят, поскольку мои криптографические усилия идут — необходимость аутентификации сообщений. Бог свидетель, я злоупотребляю ею, но это одна из добродетелей, о которой я не теряю сна, проповедуя. Некоторые люди ошибочно считают зашифрованный текст открытым текстом, на который наносится OFF! репеллент, так что любые любопытные, злонамеренные комары (мальскиты, если хотите) будут быстро удержаны от любой потенциальной попытки зацепиться.
К сожалению, SC Johnson & Son не занимается криптографией, и даже при использовании хорошего режима работы блочного шифра, такого как CTR или CBC, зашифрованный текст остается податливым. Из этого следует, что возможность выполнять контролируемые изменения в зашифрованном тексте, когда зашифрованный текст расшифровывается во что-то значимое, во многих случаях является даже более серьезным, чем просто возможность прочитать соответствующий открытый текст зашифрованного текста. Чтобы исправить это, хорошим решением является CMAC, MAC на основе блочного шифра, который сохраняет целостность и довольно хорошо работает с AES. Чтобы быть одним из наиболее важных аспектов безопасного канала, это остается незамеченным гораздо чаще, чем это удобно принять. Поместите его в начало списка.
В поисках хорошего рецепта
Многие разработчики способны понять математическую теорию криптографии или, по крайней мере, понять причины моих предложений выше. Если бы их резюмировать, добавив немного специй, это могло бы звучать примерно так:
- Используйте AES в режиме CTR для сохранения конфиденциальности сообщений.
- Используйте CMAC-AES для сохранения целостности сообщений.
- Сначала зашифруйте, а затем аутентифицируйте.
- Используйте 256-битные ключи для обоих.
Вводная литература по криптографии не погружает вас в более сложные понятия криптографической безопасности, но если бы вы спросили меня, какие свойства ожидать от схемы шифрования и аутентификации, я бы сказал, что соответствие IND-CCA2 и INT-CTXT это очень хорошее начало. Если мы вычислим MAC-адрес SUF-CMA, например CMAC-AES, на зашифрованном тексте схемы шифрования с защитой IND-CPA, например AES в режиме CTR, мы сможем достичь вышеупомянутых свойств IND-CCA2 и INT-CTXT. Очевидно, это композиция Encrypt-then-Authenticate; хотя я согласен с философией Authenticate-then-Encrypt (AtE), Encrypt-then-Authenticate (EtA) проще всего сделать правильно — проще говоря. Простота превыше всего, поэтому дать эту рекомендацию несложно. Подожди, подожди, подожди. «Все эти аббревиатуры разбрызгиваются, но я понятия не имею, что они означают». Не переживай приятель. Ну вот.
- IND-CPA = неразличимость при атаке с выбранным открытым текстом
- IND-CCA2 = неразличимость при атаке адаптивного выбранного зашифрованного текста
- INT-CTXT = Целостность зашифрованных текстов
- SUF-CMA = Сильная невозможность подделки при атаке с выбранным сообщением
Теперь, когда я бросил вам кучу терминов, это невозможно вывести без теории. Я укажу вам на превосходный справочный материал, если вы захотите связать «почему» с «что», которые я только что вам предоставил. Вам может быть приятно узнать, что это общее мнение среди криптографов, и оно было тщательно изучено. Что касается содержания, то вы скоро получите достаточное количество ссылок. В 2000 году Михир Белларе и Чанатип Нампремпре опубликовали статью под названием «Аутентифицированное шифрование: отношения между понятиями и анализ парадигмы родовой композиции», которую я считаю основополагающим вкладом в анализ того, как родовая композиция коррелирует с понятиями неразличимости., негибкость и целостность. Годом позже Хьюго Кравчик представил веские доводы в пользу композиции «Зашифровать, затем аутентифицировать» в своей обязательной к прочтению статье «Порядок шифрования и аутентификации для защиты связи (или: насколько безопасен SSL?)». После того, как вы переварите этот шведский стол из яиц, бекона, ливерной муки и теории, вы будете довольны тем, что сделаете ставку на аббревиатуры, вырисовывающиеся выше.
Говоря об аббревиатурах, давайте рассмотрим другой механизм обеспечения конфиденциальности и целостности, который направлен в несколько ином направлении: EAX. Михир Белларе, Филлип Рогауэй и Дэвид Вагнер предлагают нам этот аутентифицированный режим работы, который продвигает основные принципы, такие как — и это всегда успокаивающие слова для консервативного криптографа — «эффективность, простота, элегантность, простота правильного использования и доказуемая безопасность». гарантии». Ммм ммм ммм. Это мило. EAX — это схема AEAD или аутентифицированное шифрование со связанными данными ; это также двухпроходная схема, поскольку она делает один проход для шифрования и другой для аутентификации. По сути, EAX является производным от общей конструкции композиции, получившей название EAX2, в которой два ее ключа объединены в один. EAX2 запускает режим CTR для шифрования, затем OMAC1 для аутентификации. (Обратите внимание, что упомянутая ранее конструкция CMAC эквивалентна OMAC1.)
Если, как говорят дизайнеры, вы предпочитаете общий подход к композиции, то EAX2 — хороший выбор; как таковой, EAX имеет смысл. И не забывайте о его обледенении – он свободен от патентов, а также намерения быть запатентованным. Если вам интересно, как это вписывается в мой список рекомендаций, EAX занимает место общей композиции, которая сначала шифруется с помощью AES в режиме CTR, а затем аутентифицируется с помощью CMAC-AES. Посмотрите на это как на гибридный режим, который обрабатывает как шифрование, так и аутентификацию с использованием блочного шифра, такого как AES. Две фигурные птицы. Один растворяющий камень. Голуби и галька в стороне, и шифрование, и аутентификация требуют внимания, и правильно, независимо от того, по какому пути вы идете по своим ограничениям. Используйте это как компас. Это только начало длинного конца, но если вы можете сказать, что справились с этим, то вы хорошо проводите время.