Основные схемы неправильного использования криптографии

Режим электронной кодовой книги (ECB) шифрует каждый блок независимо, используя один и тот же ключ. Одинаковые блоки открытого текста дают одинаковые блоки шифротекста. Классическая демонстрация — «пингвин ECB»: шифрование растрового изображения в режиме ECB сохраняет структуру изображения на уровне блоков, поэтому очертания пингвина остаются отчетливо видимыми в шифротексте. Режим ECB не обеспечивает семантическую безопасность и никогда не должен использоваться для практического шифрования.

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

Коллизии MD5 можно строить с 2004 года; создание двух файлов с одинаковым хешем MD5 не представляет вычислительной сложности. Практическая атака Google SHAttered в 2017 году продемонстрировала коллизии SHA-1, создав два файла PDF с одинаковым хешем SHA-1. Ни MD5, ни SHA-1 не следует использовать в целях безопасности: для цифровых подписей, контроля целостности содержимого, хранения паролей или HMAC. Для современных систем используйте SHA-256, SHA-3 или BLAKE2.

Использование time() или других предсказуемых значений для инициализации генератора псевдослучайных чисел представляет критическую уязвимость, если выходные данные PRNG применяются в целях безопасности. Злоумышленник, который приблизительно знает, когда был создан ключ, может перебрать пространство начальных значений (все возможные отметки времени в небольшом диапазоне) и восстановить ключ. Классический пример: ранние версии Netscape инициализировали генерацию ключей SSL с помощью времени и идентификатора процесса — оба значения злоумышленник на той же машине мог наблюдать.

rand() в C, java.util.Random и модуль random в Python используют детерминированные линейные конгруэнтные генераторы или вихрь Мерсенна, предназначенные для статистического качества при моделировании, а не для безопасности. Злоумышленник, наблюдающий достаточное количество выходных данных таких генераторов, может восстановить их внутреннее состояние и предсказать все будущие выходные данные. В целях безопасности используйте генераторы CSPRNG, предоставляемые OS: secrets.token_bytes() в Python, crypto.randomBytes() в Node.js или /dev/urandom в Linux.

Шифрование без аутентификации обеспечивает только конфиденциальность, но не целостность. Злоумышленник, который не может прочитать открытый текст, все же может изменить шифротекст, потенциально вызвав предсказуемые изменения открытого текста (особенно в режиме CTR или CBC). Такая податливость позволяет проводить атаки: перехватив зашифрованную банковскую операцию, злоумышленник может изменить отдельные биты и тем самым поменять сумму перевода или счет получателя, не зная открытого текста. Всегда используйте аутентифицированное шифрование (AEAD).

Жёсткое задание ключей шифрования или векторов инициализации в исходном коде представляет критическую уязвимость. Исходный код часто сохраняется в репозиториях систем управления версиями, иногда публичных. Даже в закрытых репозиториях любой, у кого есть доступ к коду, получает доступ к ключу. Жёстко заданные ключи означают, что все экземпляры используют один и тот же ключ, а смена ключа требует повторного развертывания. Ключи необходимо хранить в переменных окружения, системах управления секретами (HashiCorp Vault, AWS Secrets Manager) или аппаратных модулях безопасности.

Использование одного и того же вектора инициализации для нескольких операций шифрования с одним ключом создает серьезные уязвимости. В режиме CTR повторное использование IV создает один и тот же поток ключей, позволяя восстановить открытый текст с помощью XOR. В режиме CBC повторное использование IV позволяет злоумышленнику определить, когда два сообщения начинаются с одинаковых блоков открытого текста. В режиме GCM повторное использование одноразового номера (IV) имеет катастрофические последствия (см. урок о повторном использовании одноразовых номеров). Для каждой операции шифрования создавайте новый случайный IV; добавляйте его в начало шифротекста для хранения вместе с контекстом расшифрования.

Хранение паролей в виде хешей, вычисленных с помощью MD5, SHA-256 или любой другой быстрой криптографической хеш-функции, недостаточно безопасно. Современные графические процессоры могут вычислять миллиарды хешей SHA-256 в секунду, поэтому автономный перебор украденных баз данных хешей становится чрезвычайно быстрым. Для хеширования паролей нужны специально созданные медленные функции, требующие много памяти: bcrypt, scrypt или Argon2id. Они разработаны так, чтобы сделать перебор дорогостоящим даже на специализированном оборудовании и сохранить автономные атаки практически невыполнимыми.

Отключение проверки сертификатов SSL/TLS (задание ssl.CERT_NONE в Python, передача -k утилите curl, установка trustAllCerts=true в Android) устраняет защиту от атак посредника. Злоумышленник может предъявить любой сертификат и перехватить все сообщения. Такая практика появляется при разработке для обхода ошибок самоподписанных сертификатов, но часто сохраняется и в рабочей среде. Всегда выполняйте надлежащую проверку сертификатов и правильно устраняйте исходные проблемы с сертификатами.

Криптографические функции сообщают о сбоях через возвращаемые значения или исключения. Их игнорирование позволяет продолжить выполнение с некорректным состоянием: расшифрованием, давшим бессмысленные данные, неудачной проверкой или завершившейся ошибкой генерацией ключа. В API на основе C, таких как OpenSSL, игнорирование возвращаемых значений особенно опасно, поскольку программа может продолжить работу с неинициализированной памятью. Всегда проверяйте каждое возвращаемое значение криптографических функций и безопасно обрабатывайте сбои.

Почему режим ECB (электронной кодовой книги) считается небезопасным для шифрования данных?

Основные ошибки, которых следует избегать: никогда не используйте режим ECB (он раскрывает шаблоны блоков), не реализуйте криптографические примитивы самостоятельно, не используйте MD5 и SHA-1 в целях безопасности, инициализируйте PRNG с помощью CSPRNG, а не time(), используйте CSPRNG для всей чувствительной к безопасности случайности, всегда аутентифицируйте зашифрованные данные (AEAD), никогда не задавайте ключи или IV жестко, создавайте новый IV для каждой операции шифрования, используйте Argon2id для паролей вместо быстрых хеш-функций, всегда проверяйте сертификаты TLS и проверяйте каждое возвращаемое значение криптографических функций.