Подводные камни криптографического кода

Question

Я изменяю существующий код безопасности. Спецификации довольно ясны, есть пример кода, но я не специалист по криптографии. Фактически, в примере кода есть заявление об отказе от ответственности, в сущности, «не используйте этот код дословно».

Во время аудита кода, который я хочу изменить (который, якобы, завершен), я наткнулся на этот маленький драгоценный камень, который используется при создании задачи:

static uint16 randomSeed;

...

uint16 GetRandomValue(void)
{
  return randomSeed++;/* This is not a good example of very random generation :o) */
}

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

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

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

• Каковы наиболее распространенные проблемы безопасности, специфичные для криптографии, которые мне нужно понять?
• Какие хорошие ресурсы дадут мне подходящие знания о том, что я должен знать помимо обычных ошибок?

-Adam

Answer 1

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

Answer 2

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

Некоторые вещи, на которые стоит обратить внимание:

• Бедные источники случайности
• Попытка разработать собственный алгоритм или протокол - никогда не делайте этого.
• Не получает код проверки. Желательно опубликовать в Интернете.
• Не пользуется хорошо зарекомендовавшей себя библиотекой и пытается написать ее самостоятельно.
• Крипто как панацея - шифрование данных волшебным образом не делает его безопасным
• Управление ключами. В наши дни часто проще украсть ключ с помощью атаки по побочному каналу, чем атаковать криптографию.

Answer 3

Ваш вопрос показывает один из наиболее распространенных: плохие источники случайности. Не имеет значения, используете ли вы 256-битный ключ, если они не достаточно случайны.

Номер 2, вероятно, предполагает, что вы можете разработать систему лучше, чем эксперты. Это та область, где качественное внедрение стандарта почти наверняка будет лучше инноваций. Помните, что до того, как SSL стал действительно безопасным, потребовалось 3 основных версии. Мы думаем.

Answer 4

ИМХО, вам нужно знать о четырех уровнях атак:

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

2. не выполняет произвольный код (здесь переполнены буферы, эксплойты xss, инъекции sql). Минимальное, что нужно сделать, чтобы узнать об этом, - это прочитать «Написание безопасного кода» от кого-то из MS и посмотреть технический доклад Google «Как взломать веб-программное обеспечение». Это также должно немного рассказать вам о глубокой защите.

3. логические атаки. Если ваш код манипулирует обычным текстом, сертификатами, сигнатурами, зашифрованными текстами, открытыми ключами или любыми другими криптографическими объектами, вы должны знать, что неправильное обращение с ними может привести к плохим вещам. Минимальные вещи, о которых вам следует знать, включают атаки по словарю в автономном режиме и онлайн, повторные атаки, атаки «человек посередине». Отправной точкой для изучения этого и, как правило, очень хорошего ориентира для вас является http://www.soe.ucsc.edu/~abadi/Papers/gep-ieee.ps

4. криптографические атаки. Криптографические уязвимости включают в себя:

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

Хорошей ссылкой в ​​целом должна быть прикладная криптография.

Кроме того, меня очень беспокоит, что то, что происходит на мобильном устройстве, которое, вероятно, заблокировано и трудно обновляется, написано кем-то, кто спрашивает о безопасности в stackoverflow. Я полагаю, что ваш случай - один из немногих случаев, когда вам нужен внешний (хороший) консультант, который поможет вам правильно определить детали. Даже если вы нанимаете консультанта по безопасности, что я рекомендую вам сделать, прочтите также приведенные выше (минималистичные) ссылки.

Answer 5

Каковы наиболее распространенные проблемы безопасности, специфичные для криптографии, которые мне нужно понять?

Легко - вы (1) недостаточно умны, чтобы придумать собственный алгоритм.

(1) И под тобой я имею в виду тебя, меня и всех остальных, читающих этот сайт ... за исключением, возможно, Алан Кей и Джон Скит .

Answer 6

Я тоже не крипто-парень, но S-блоки могут быть неприятными, когда портятся (и они действительно имеют значение). Вам также нужен реальный источник энтропии, а не просто PRNG (независимо от того, насколько случайным он выглядит). PRNGs бесполезны. Затем вы должны убедиться, что источник энтропии не является детерминированным и не может быть подделан.

Мой скромный совет: придерживайтесь известных криптоалгоритмов, если вы не эксперт и не понимаете риски. Вы могли бы лучше использовать некоторый протестированный, общедоступный код с открытым исходным кодом / общественное достояние.