Может ли злоумышленник украсть данные из зашифрованной AES таблицы, не зная ключа?

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

Предполагая, что таблица зашифрована одним и тем же ключом, но с другим IV:

1. Злоумышленник обычно регистрирует новую учетную запись в приложении.
2. Приложение создает учетную запись и вставляет новую строку (2-я строка в таблице ниже)
3. Злоумышленник каким-то образом обнаружил уязвимость в приложении для запуска SQL-инъекций
4. С помощью SQL-инъекции злоумышленник заменяет шифр своей строки значением жертвы. например aes_cipher_2 -> aes_cipher_1 и iv_2 -> iv_1
5. Злоумышленник входит в свою учетную запись
6. Злоумышленник переходит на страницу профиля, затем приложение расшифровывает данные жертвы (aes_cipher_1) и показывает ему открытый текст.

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

Одним из возможных частичных смягчений является использование аутентифицированное шифрование, например AES-GCM, и в том числе Я БЫ и Имя пользователя поле в аутентифицированных данных. Чистый эффект заключается в том, что зашифрованные данные (в Адрес поле), измененное каким-либо образом, в том числе отделенное от оригинала Я БЫ или же Имя пользователя или же IV, не сможет расшифровать с криптографической достоверностью.

Аутентификация увеличит размер криптограммы (данные в Адрес поле) примерно на 12 байт (это параметр), независимо от размера Я БЫ и Имя пользователя поле. Небольшое увеличение размера можно уменьшить, сделав IV частью криптограммы, что в любом случае рекомендуется хотя бы потому, что это снижает вероятность потери связи между криптограммой и ее IV. В любом случае размещение IV в начале данных, зашифрованных блочным шифром, является стандартной практикой.

Шифрование с проверкой подлинности обеспечивает гораздо лучшую защиту, чем получение ключа AES-CTR из мастер-ключа и Идентификатор или/и Имя пользователя: если злоумышленники могут изменить данные, зашифрованные с помощью CTR, и наблюдать за поведением какой-либо ИТ-системы с расшифрованными данными, то это опасение, что они могут узнать что-то о данных. Например, если байт '<' в расшифрованных данных вызывает какое-то узнаваемое поведение, то для расшифровки требуется около 30 попыток на каждый символ; прямо как в кино. Шифрование с проверкой подлинности защищает от этого, а производные ключи — нет.

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

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