Фейзуллаев Р.Э.
СРАВНИТЕЛЬНЫЙ АНАЛИЗ РЕЖИМОВ ШИФРОВАНИЯ AES В МОБИЛЬНОМ МЕССЕНДЖЕРЕ: ПЕРЕХОД ОТ ECB К CBC И GCM *
Аннотация:
в статье рассматривается проблема выбора режима шифрования для обеспечения безопасности данных в мобильных мессенджерах. На примере разработанного приложения на Android проведен сравнительный анализ трех реализаций алгоритма AES: ECB, CBC и GCM. Показано, что использование режима ECB, несмотря на простоту реализации, приводит к уязвимостям, связанным с отсутствием рандомизации и устойчивости к шаблонным атакам. В качестве альтернативы предложены подходы на основе CBC и GCM, интегрированные с Android KeyStore для безопасного хранения ключей. Реализации тестировались на реальных сценариях обмена сообщениями с измерением времени шифрования и дешифрования. Выполнены замеры времени шифрования и дешифрования на наборах сообщений различной длины с использованием System.nanoTime(). Особое внимание уделено практическим аспектам: генерации векторов инициализации, работе с аппаратным хранилищем ключей, а также предотвращению утечек через логирование. На основе проведенного анализа сформулированы рекомендации для разработчиков, включая отказ от ECB, использование GCM для передачи файлов и CBC для текстовых сообщений. По результатам экспериментов сделан вывод о целесообразности применения AES-GCM в мобильных мессенджерах и обозначены рекомендации по безопасности и производительности. Результаты работы могут быть применены для улучшения безопасности мобильных приложений с end-to-end шифрованием.
Ключевые слова:
шифрование, дешифрование, Андроид Keystore, безопасность, мобильное приложение, вектор инициализации
Введение.В эпоху глобальных коммуникационных сетей и ростом числа пользователей мессенджеров, чаты стали неотъемлемой частью повседневной коммуникации, обрабатывая огромные объемы конфиденциальных данных — от личных переписок до финансовой информации. Рост числа кибератак, включая перехват сообщений и анализ трафика, обуславливает критическую важность внедрения надежных механизмов шифрования. Современные стандарты, такие как AES, обеспечивают базовую защиту, однако их эффективность напрямую зависит от выбранного режима работы. В этой связи актуальной задачей становится не только применение криптографических алгоритмов, но и корректный выбор режима их реализации, исключающего утечки данных через побочные каналы.В рамках разработки мессенджера для Android была реализована первая версия шифрования на основе режима ECB, который, несмотря на простоту интеграции, обладает фундаментальными недостатками, которые позднее будут разобраны в статье.Целью данной работы является сравнительный анализ трех режимов AES — ECB, CBC и GCM — в контексте мобильного приложения, а также реализация перехода от ECB к другим режимам шифрования. Исследование фокусируется на двух аспектах:Безопасность: устранение уязвимостей ECB за счет внедрения векторов инициализации в CBC и аутентифицированного шифрования в GCM.Производительность: измерение накладных расходов при переходе к более сложным режимам, включая генерацию IV/nonce, работу с Android KeyStore и обработку данных в реальном времени.Метод исследования. В основе исследования лежит сравнительный анализ трёх режимов AES-шифрования (ECB, CBC/PKCS7Padding, GCM/NoPadding) в рамках одного и того же Android-мессенджера. Основные этапы методики:Подготовка выборки сообщений.Короткие, средние и длинные строки текста,Повторяемость фрагментов для проверки шаблонных атак.Измерение производительности.Использование System.nanoTime() для фиксации времени шифрования и дешифрования,Вычисление среднего и максимального времени, а также стандартного отклонения.Сравнительная оценкаСводная таблица и график зависимости времени от длины сообщения,Сопоставление уровней безопасности: рандомизация, аутентификация, устойчивость к атакамИспользуемые технологии разработки.Разработка прототипа Android-мессенджера велась в среде Android Studio с применением следующих инструментов и библиотек:– Язык программирования Java — реализация логики приложения и интеграция криптографических функций,– Android Keystore API — генерация и безопасное хранение симметричных ключей AES,– Firebase Realtime Database — хранение и синхронизация зашифрованных сообщений между пользователями,– Firebase Authentication — управление учётными записями и идентификация пользователей,– Cipher (javax.crypto) — реализация трёх режимов AES:AES (ECB/PKCS5Padding) для прототипа,AES/CBC/PKCS7Padding с IV,AES/GCM/NoPadding,Реализация шифрования.Режим AES/ECB.Первоначальная реализация мессенджера использовала режим Electronic Codebook алгоритма AES. Данный выбор был обусловлен простотой интеграции — отсутствием необходимости генерации векторов инициализации и минимальными изменениями в архитектуре приложения. Однако, как показали дальнейшие тесты, ECB обладает фундаментальными недостатками, делающими его непригодным для защиты конфиденциальных данных.[1] ECB не является семантически безопасным — наблюдение за зашифрованным текстом в режиме ECB может раскрыть информацию об открытом тексте.[2]Ключевые фрагменты реализации ECBФиксированный ключ в коде:Ключ шифрования жестко задан в виде массива байтов, что нарушает принцип "секретности ключа" [3]. При декомпиляции приложения злоумышленник может извлечь ключ, скомпрометировав все сообщения.Листинг 1. Фрагмент кода с ключом и инициализацией.Отсутствие рандомизации:ECB не использует IV, поэтому одинаковые блоки открытого текста всегда дают идентичные блоки шифра. Это демонстрирует метод AESEncryptionMethod.Листинг 2. Фрагмент кода метода AESEncryptionMethod.Дешифрование без проверки целостности:Метод AESDecryptionMethod не включает механизмов аутентификации, а ECB не предусматривает подобное по умолчанию, что позволяет злоумышленнику модифицировать шифр без обнаружения:Листинг 3. Фрагмент кода метода AESDecryptionMethod.Демонстрация уязвимостей ECB.Статичность ключа:Жёстко встроенный в APK массив байт легко извлечь при анализе приложения.Повторяющиеся блоки в шифре:При шифровании сообщений с повторяющимися фразами из‑за отсутствия IV и рандомизации, ECB генерирует идентичные блоки. Это упрощает частотный анализ и деанонимизацию пользователей. На рис. 1 видно, что зашифрованный текст сохраняет паттерны исходного (см. рис. 1).Рисунок 1. Результат шифрования с ECB режимом и статичным ключом.В результате был сделан переход на Android Keystore API для безопасного хранения ключей. Однако это не исключает того, что режим ECB, несмотря на простоту, непригоден для мессенджеров так как ECB уязвим для атак кодовой книги и не подходит для длинных сообщений [4], а отсутствие рандомизации раскрывает структуру данных.Режим AES/CBC.Первой улучшенной версией криптоподсистемы стал режим Cipher Block Chaining с PKCS7-паддингом, который устраняет детерминированность ECB за счёт введения случайного вектора инициализации и позволяет хранить ключи в Android Keystore.Модернизация архитектуры с использованием Android KeyStoreДля устранения недостатков ECB в мессенджере была реализована поддержка режима CBC (Cipher Block Chaining) с интеграцией Android KeyStore — защищенного хранилища ключей, обеспечивающего аппаратную изоляцию криптографического материала [5]. Это позволило решить две ключевые проблемы:Динамическая генерация ключей вместо хардкода в коде.Рандомизация шифрования за счет использования векторов инициализации (IV).Метод initKeyStore() генерирует и сохраняет ключ в защищенном хранилище.Листинг 4. Фрагмент кода Инициализация Android Keystore и генерация ключа.– Использование Android Keystore гарантирует, что материал ключа остаётся неплохо экспортируемым и надёжно хранится в аппаратном модуле или безопасном контейнере ОС.– Установка setRandomizedEncryptionRequired(true) обеспечивает автоматическую генерацию IV при каждом шифровании.Шифрование с использованием IVМетод AESEncryptionMethod() генерирует уникальный IV для каждого сообщения, устраняя шаблонность ECB:Листинг 5. Фрагмент кода метода AESEncryptionMethod для CBC.Особенности:IV передается вместе с шифром (первые 16 байт).Режим PKCS7Padding гарантирует корректную обработку блоков.Дешифрование с проверкой IV.Метод AESDecryptionMethod() извлекает IV и обеспечивает детерминированное восстановление данных:Листинг 6. Фрагмент кода метода AESDecryptionMethod для CBC.Преимущества и ограничения CBC.– Рандомизация шифротекста: разные IV приводят к различным криптотекстам даже для одинаковых сообщений, что предотвращает шаблонные атаки.– Отсутствие аутентификации: CBC не включает механизм проверки целостности, что позволяет прицельно модифицировать отдельные блоки и нарушить корректность дешифрования без выброса исключения.– Для полноценной защиты от «бит-флипа» и атак целостности рекомендуется комбинировать CBC с HMAC или перейти на режим AEAD (GCM).После анализа, был проведен запуск и проверка работоспособности приложения. После чего было подтверждено, что текст зашифрован по-разному (см. рис. 2).Рисунок 2. Результат шифрования с CBC режимом и проверка присланных сообщений.Также было необходимо убедиться, что у другого пользователя текст дешифруется корректно. (см. рис. 3).Рисунок 3. Проверка присланных сообщений.Режим AES/GCM/NoPadding.Внедрение аутентифицированного шифрования.Для достижения максимального уровня безопасности в мессенджере был внедрен режим GCM, сочетающий шифрование с аутентификацией данных. GCM обеспечивает:Конфиденциальность: Шифрование с использованием счетчика (Counter Mode).Целостность: Генерация 128-битного тега аутентификации для обнаружения изменений данных [7]. При несовпадении тега возникает AEADBadTagException, что прерывает дешифрование.Защиту от повторного использования nonce: Уникальные 12-байтовые значения nonce для каждого сообщения [8].Ключевые фрагменты реализации GCM.Инициализация KeyStore с поддержкой GCM.Для этого необходимо было изменить в строке трансформации "AES/CBC/PKCS7Padding" на "AES/GCM/NoPadding". В модуле initKeyStore()перед самим запуском был удален предыдущий ключ с помощью строки: if (keyStore.containsAlias(KEY_ALIAS)) {keyStore.deleteEntry(KEY_ALIAS),}. Так же SetBlockMode был установлен на GCM соответственно, а setEncryptionPaddings был установлен на “NONE”.Шифрование с генерацией nonce и тега.Метод AESEncryptionMethod() объединяет nonce, шифротекст и тег аутентификации:Листинг 7. Фрагмент кода метода AESEncryptionMethod для GCM.Дешифрование с проверкой тегаМетод AESDecryptionMethod() проверяет целостность данных через тег:Фрагмент кода метода AESDecryptionMethod для GCM.Проверка целостности происходит внутри doFinal(): при любом искажении тега или ciphertext будет выброшено AEADBadTagException.Преимущества GCM перед CBCАутентификация данных: Тег защищает от подмены шифра.Эффективность: Режим счетчика позволяет параллельное шифрование.Рисунок 4. Результат шифрования с GCM режимом и проверка присланных сообщений.Анализ производительности.Для дополнительного анализа, были сделаны замеры времени шифрования и дешифрования. Для этого были подготовлены 1, 10, 20 и 40 слов и символов для тестирования скорости. После чего каждый замер был проведен по 20 раз, и выведено среднее арифметическое потраченного времени. Это было сделано для того, чтобы минимизировать искажение нагрузки CPU на результат.В результате экспериментов были получены следующие средние времена шифрования и дешифрования для трёх режимов AES при разном объёме текста — см. Таблицу 1.Таблица 1. Время шифрования и дешифрования (в наносекундах).Выводы по результатам.ECB демонстрирует наименьшие времена шифрования и дешифрования: до 0,2 мс для Encrypt и менее 0,1 мс для Decrypt при малых объёмах. Однако при росте длины текста его абсолютная производительность остаётся лучшей лишь по скорости, но он полностью лишён защитных свойств.CBC даёт значительную нагрузку на CPU: время шифрования достигает 25 мс при 40 словах, а дешифрования — более 60 мс. Это связано с дополнительными операциями обработки и созданием/извлечением IV для каждого блока.GCM показывает средние результаты: порядка 4–10 мс на шифрование и 14–30 мс на дешифрование, что почти в 2–6 раз быстрее CBC, при этом сохраняя AEAD-свойства.Таким образом, AES/GCM сочетает приемлемую производительность и необходимые для продакшен-решений криптографические гарантии, тогда как ECB крайне небезопасен, а CBC требует дополнительной защиты целостности и серьёзно нагружает систему.Заключение.В работе проведён подробный сравнительный анализ трёх режимов AES-шифрования в Android-мессенджере:AES/ECB оказался быстрым, но полностью неприемлемым для реальных приложений из-за отсутствия рандомизации и аутентификации.AES/CBC/PKCS7Padding устраняет проблему повторяющихся блоков, однако без дополнительного HMAC не гарантирует целостность и демонстрирует высокие временные затраты.AES/GCM/NoPadding обеспечивает и конфиденциальность, и встроенную проверку целостности, показывая при этом более высокую производительность по сравнению с CBC.По результатам экспериментов рекомендуется использовать AES/GCM в сочетании с Android Keystore для безопасного хранения ключей и автоматической генерации nonce. Это позволит обеспечить баланс между скоростью криптографических операций и надёжной защитой данных пользователей мобильного мессенджера.
Номер журнала Вестник науки №5 (86) том 2
Ссылка для цитирования:
Фейзуллаев Р.Э. СРАВНИТЕЛЬНЫЙ АНАЛИЗ РЕЖИМОВ ШИФРОВАНИЯ AES В МОБИЛЬНОМ МЕССЕНДЖЕРЕ: ПЕРЕХОД ОТ ECB К CBC И GCM // Вестник науки №5 (86) том 2. С. 934 - 952. 2025 г. ISSN 2712-8849 // Электронный ресурс: https://www.вестник-науки.рф/article/22944 (дата обращения: 20.07.2025 г.)
Вестник науки © 2025. 16+