AES (Advanced Encryption Standard) — це симетричний блоковий алгоритм шифрування, прийнятий у 2001 році Національним інститутом стандартів і технологій США (NIST) як офіційний стандарт. AES прийшов на зміну застарілому DES і з тих пір став найпоширенішим алгоритмом шифрування у світі, що використовується від банківських систем до мобільних додатків. За даними NIST (2023), AES забезпечує стійкість, еквівалентну 2^256 операціям для ключа довжиною 256 біт, що робить його невразливим для сучасних атак повним перебором. NIST FIPS 197, 2023
Головне
AES (Advanced Encryption Standard) — це симетричний блоковий шифр, розроблений бельгійськими криптографами Joan Daemen та Vincent Rijmen під назвою Rijndael. У 2001 році NIST обрав Rijndael переможцем конкурсу на новий стандарт шифрування США після п'яти років відкритого тестування та аналізу. AES працює з блоками даних фіксованого розміру (128 біт) і підтримує три довжини ключа: 128, 192 та 256 біт. Кількість раундів перетворення залежить від довжини ключа: 10 раундів для 128-бітного, 12 для 192-бітного та 14 для 256-бітного ключа. Кожен раунд включає чотири операції: SubBytes (нелінійна заміна байтів через S-box), ShiftRows (циклічний зсув рядків), MixColumns (перемішування стовпців) та AddRoundKey (накладання раундового ключа).
Розробка AES розпочалася в 1997 році, коли NIST оголосив конкурс на заміну DES, чий 56-бітний ключ був зламаний за 22 години в 1998 році на спеціалізованому пристрої Deep Crack. У конкурсі брали участь 15 алгоритмів з різних країн, включаючи Serpent (Великобританія), Twofish (США) та RC6 (США). До фіналу 1999 року залишилося 5 кандидатів. Rijndael переміг завдяки комбінації високої швидкості на всіх платформах (від 8-бітних мікроконтролерів до 64-бітних серверів), стійкості до криптоаналізу та компактної реалізації в апаратному забезпеченні. З 2006 року AES використовується для шифрування даних з грифом SECRET та TOP SECRET в урядових системах США. Сьогодні AES вбудовано у всі основні протоколи: TLS 1.2/1.3, IPsec, SSH, Wi-Fi WPA2/WPA3 та Bluetooth BR/EDR.
AES обробляє дані блоками по 128 біт (16 байт), організованими у вигляді матриці 4x4 байта, яка називається state. Кожен раунд шифрування виконує послідовність детермінованих перетворень, які в сукупності створюють ефект «лавини»: зміна одного біта вхідних даних змінює близько 50% бітів вихідних даних. Такий ефект робить AES стійким до диференціального та лінійного криптоаналізу — основних методів зламу блокових шифрів.
Процес починається з AddRoundKey — накладання початкового ключа на state через операцію XOR. Потім виконуються раунди: SubBytes замінює кожен байт state на значення з S-box (таблиці заміни). ShiftRows циклічно зсуває другий рядок на 1 позицію, третій на 2, четвертий на 3 — це забезпечує перемішування між колонками. MixColumns множить кожен стовпець state на фіксовану матрицю в полі Галуа GF(2^8), створюючи залежність кожного вихідного байта від усіх чотирьох вхідних байтів стовпця. AddRoundKey накладає черговий раундовий ключ, отриманий з вихідного ключа через процедуру Key Expansion. Останній раунд відрізняється відсутністю операції MixColumns. Розшифрування використовує зворотні операції InvSubBytes, InvShiftRows, InvMixColumns та AddRoundKey у зворотному порядку. Для мобільних розробників розуміння внутрішньої структури AES не потрібне — достатньо знати, як правильно викликати вбудовані API платформи з коректними параметрами.
Ключова характеристика AES, що забезпечує його криптостійкість — лавинний ефект. Зміна одного біта у відкритому тексті або ключі призводить до зміни приблизно 50% бітів шифротексту, що робить AES надзвичайно стійким до диференціального та лінійного криптоаналізу. Комбінація операцій SubBytes (нелінійність через S-box) та MixColumns (дифузія через множення в полі Галуа) створює математичну складність, при якій навіть знання частини шифротексту не дозволяє відновити ключ швидше повного перебору. За даними аналізу NIST (2018), найкраща відома атака на AES-128 — biclique attack — скорочує ефективну довжину ключа всього на 2 біти (до 126.2 біт), що не дає практичної переваги атакуючому. Для AES-256 не існує жодної практично реалізованої атаки, що перевершує повний перебір.
AES підтримує три розміри ключа, кожен з яких відповідає певному рівню криптостійкості. Вибір розміру ключа впливає на безпеку, продуктивність та вимоги до ресурсів пристрою.
| Розмір ключа | Кількість раундів | Рівень безпеки | Застосування |
|---|---|---|---|
| AES-128 | 10 | 128 біт | Комерційні додатки, TLS |
| AES-192 | 12 | 192 біти | Державні системи (SECRET) |
| AES-256 | 14 | 256 біт | TOP SECRET, фінансовий сектор |
Практичне правило: для мобільних додатків використовуйте AES-256 за замовчуванням. Різниця в продуктивності між AES-128 та AES-256 на сучасних пристроях з підтримкою AES-NI становить не більше 10–15%, але рівень безпеки подвоюється. Згідно з квантовим аналізом (Grassl et al., 2016), для зламу AES-128 знадобиться 2^77 квантових операцій через алгоритм Гровера, а для AES-256 — 2^149, що робить AES-256 стійким до квантових атак на найближчі 20–30 років. Навіть AES-128 забезпечує достатній захист для переважної більшості комерційних сценаріїв: для повного перебору 128-бітного ключа знадобиться більше енергії, ніж існує у Всесвіті за оцінкою Брюса Шнайєра. Однак стандарти безпеки (GDPR, HIPAA, PCI DSS) часто явно вимагають AES-256, тому в продакшен-проектах рекомендується використовувати максимальну довжину ключа.
AES як блоковий шифр шифрує блоки фіксованого розміру (128 біт). Для шифрування даних довільної довжини використовуються режими роботи. Вибір режиму критично впливає на безпеку: неправильний режим може звести нанівець стійкість AES.
Для мобільних проектів використовуйте AES-256-GCM з nonce довжиною 12 байт. GCM вирішує дві проблеми одночасно: шифрування даних та перевірка справжності, що запобігає атакам типу padding oracle та chosen ciphertext. Android Keystore та iOS CryptoKit підтримують AES-GCM з коробки без необхідності реалізації додаткових криптографічних примітивів. При роботі з GCM важливо ніколи не повторювати nonce з одним і тим же ключем — це повністю руйнує безпеку шифрування. Генеруйте новий випадковий nonce для кожного шифрування та зберігайте його разом з шифротекстом.
Розглянемо приклад безпечної реалізації AES-256-GCM на Android з використанням Jetpack Security. Код нижче демонструє повний цикл: створення ключа AES-256 через MasterKey, шифрування та розшифрування рядка з додатковими автентифікованими даними (AAD).
import androidx.security.crypto.MasterKey
import androidx.security.crypto.EncryptedSharedPreferences
val masterKey = MasterKey.Builder(context)
.setKeyScheme(MasterKey.KeyScheme.AES256_GCM)
.build()
val securePrefs = EncryptedSharedPreferences.create(
context,
"secure_prefs",
masterKey,
EncryptedSharedPreferences.PrefKeyEncryptionScheme.AES256_SIV,
EncryptedSharedPreferences.PrefValueEncryptionScheme.AES256_GCM
)
fun storeSecureData(key: String, value: String) {
securePrefs.edit().putString(key, value).apply()
}
fun readSecureData(key: String): String? {
return securePrefs.getString(key, null)
}
Ключова особливість цього рішення — AES-256-GCM використовується на двох рівнях: для шифрування ключів-значень (PrefValueEncryptionScheme) та для захисту самих назв ключів (PrefKeyEncryptionScheme використовує AES-256-SIV, стійкий до повторення nonce). MasterKey генерується з використанням алгоритму AES-256-GCM та зберігається в Android Keystore, захищеному апаратно на пристроях з Trusted Execution Environment. На пристроях без апаратної підтримки (TEE) ключ шифрується через Bouncy Castle, що все одно безпечніше зберігання в SharedPreferences.
Для прямого шифрування великих обсягів даних (наприклад, зображень або файлів) використовуйте AES-256-GCM через EncryptedFile з AndroidX Security. Для експорту ключів (наприклад, для бекапу) використовуйте додаткове шифрування з використанням пароля користувача через PBKDF2 з 100000+ ітерацій.
На iOS робота з AES організована через фреймворк CryptoKit (Swift 5.0+). Ключ AES-256 створюється через SymmetricKey(size: .bits256) та зберігається в Secure Enclave — апаратному криптопроцесорі, ізольованому від основного CPU та операційної системи. CryptoKit надає дві реалізації AES: AES.GCM (рекомендований) та AES.CBC (для зворотної сумісності з застарілими форматами). Шифрування виконується через метод seal(), який приймає дані, ключ та nonce (12 байт), а повертає AES.GCM.SealedBox — структуру, що містить шифротекст та тег автентифікації. Розшифрування — через open(). Apple наполегливо не рекомендує використовувати CommonCrypto безпосередньо: CryptoKit автоматично вибирає оптимальні параметри, захищає від side-channel атак та використовує апаратне прискорення AES-NI на процесорах Apple Silicon. На пристроях з Secure Enclave ключі ніколи не покидають апаратний модуль, що виключає їх крадіжку навіть при повній компрометації додатку. Для серіалізації ключа використовується метод withUnsafeBytes з подальшим збереженням в Keychain через SecItemAdd з атрибутом kSecAttrAccessible = kSecAttrAccessibleWhenUnlockedThisDeviceOnly.
Часті запитання
AES — це алгоритм, який перетворює читабельні дані в нечитабельний набір байтів за допомогою секретного ключа. Той самий ключ потрібен, щоб повернути дані у вихідний вигляд. AES настільки надійний, що використовується для шифрування секретних документів уряду США.
AES-128 використовує ключ довжиною 128 біт і виконує 10 раундів шифрування. AES-256 використовує 256-бітний ключ і 14 раундів, що робить його в 2^128 разів складнішим для зламу. Для мобільних додатків рекомендується AES-256 через мінімальну різницю в продуктивності.
AES-256-GCM — найбільш безпечний і рекомендований режим. GCM забезпечує автентифіковане шифрування (шифрування + перевірка цілісності). Режим ECB використовувати заборонено, CBC потребує окремого MAC. GCM — стандарт де-факто для мобільних додатків.
Теоретично AES може бути зламаний повним перебором, але для AES-256 знадобиться 2^256 спроб — більше, ніж атомів у спостережуваному Всесвіті. Практичних атак на AES-256 не існує. Атаки на side-channel (Spectre, Meltdown) не зламують AES, а крадуть ключі з пам'яті, тому апаратне зберігання ключів критично важливе.
Використовуйте бібліотеку AndroidX Security: MasterKey.Builder з KeyScheme.AES256_GCM створює захищений ключ в Android Keystore, а EncryptedSharedPreferences автоматично шифрує всі дані через AES-256-GCM. Жодної ручної криптографії — API безпечний за замовчуванням, без ризику помилок розробника.
Підсумки
Ми розробимо мобільний застосунок під ключ
IT Sectr створює застосунки для iOS та Android для стартапів і бізнесу з 2017 року. Ми проконсультуємо вас і запропонуємо найкраще рішення.
Читайте також