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

StackOverflow https://stackoverflow.com/questions/497156

  •  20-08-2019
  •  | 
  •  

Вопрос

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

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

static uint16 randomSeed;

...

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

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

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

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

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

-Адам

Это было полезно?

Решение

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

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

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

Другие советы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top