AES (Advanced Encryption Standard) — یک الگوریتم رمزنگاری بلوکی متقارن است که در سال 2001 توسط مؤسسه ملی استانداردها و فناوری ایالات متحده (NIST) به عنوان استاندارد رسمی پذیرفته شد. AES جایگزین DES قدیمی شد و از آن زمان به پرکاربردترین الگوریتم رمزنگاری در جهان تبدیل شده است که از سیستمهای بانکی تا برنامههای موبایل استفاده میشود. بر اساس دادههای NIST (2023)، AES مقاومتی معادل 2^256 عملیات برای کلید 256 بیتی فراهم میکند که آن را در برابر حملات brute force مدرن غیرقابل نفوذ میسازد. 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 بیتی آن در سال 1998 در 22 ساعت توسط دستگاه تخصصی 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 که مقاومت رمزنگاری آن را تضمین میکند، اثر بهمنی (avalanche effect) است. تغییر یک بیت در متن ساده یا کلید منجر به تغییر حدود 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 بیت) را رمزنگاری میکند. برای رمزنگاری دادههای با طول دلخواه از حالتهای کار (modes of operation) استفاده میشود. انتخاب حالت بهطور بحرانی بر امنیت تأثیر میگذارد: حالت نادرست میتواند مقاومت 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 استاندارد de facto برای برنامههای موبایل است.
از نظر تئوری 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 از سال 2017 برنامههای iOS و Android را برای استارتاپها و کسبوکارها ایجاد میکند. ما به شما مشاوره میدهیم و بهترین راهحل را پیشنهاد خواهیم کرد.
همچنین بخوانید