AES: คืออะไร อัลกอริธึมการเข้ารหัสแบบสมมาตร และนำไปใช้ที่ไหน
AES (Advanced Encryption Standard) เป็นอัลกอริธึมการเข้ารหัสแบบบล็อกสมมาตรที่ถูกนำมาใช้ในปี 2001 โดยสถาบันมาตรฐานและเทคโนโลยีแห่งชาติของสหรัฐอเมริกา (NIST) เป็นมาตรฐานอย่างเป็นทางการ AES เข้ามาแทนที่ DES ที่ล้าสมัยและตั้งแต่นั้นมาก็กลายเป็นอัลกอริธึมการเข้ารหัสที่แพร่หลายที่สุดในโลก ใช้ตั้งแต่ระบบธนาคารไปจนถึงแอปพลิเคชันมือถือ ตามข้อมูลของ NIST (2023) AES ให้ความปลอดภัยเทียบเท่ากับ 2^256 การดำเนินการสำหรับคีย์ 256 บิต ทำให้ไม่สามารถถูกโจมตีแบบ brute-force สมัยใหม่ได้ NIST FIPS 197, 2023
ประเด็นสำคัญ
- AES คือการเข้ารหัสแบบบล็อกสมมาตรที่มีขนาดบล็อกคงที่ 128 บิต และคีย์ 128, 192 หรือ 256 บิต
- โหมด GCM เป็นโหมดการทำงาน AES ที่แนะนำสำหรับแอปพลิเคชันมือถือ ซึ่งให้การเข้ารหัสที่รับรองความถูกต้อง
- AES-256 เป็นเวอร์ชันที่มีระดับความปลอดภัยสูงสุด แนะนำสำหรับการปกป้องข้อมูลที่มีความละเอียดอ่อนสูง
- การเร่งด้วยฮาร์ดแวร์ — คำสั่ง AES-NI ของโปรเซสเซอร์ช่วยให้การเข้ารหัสทำงานด้วยความเร็วสูงถึง 10 GB/s บนอุปกรณ์สมัยใหม่
- Android และ iOS มี API ในตัวสำหรับ AES: Android Keystore และ iOS CryptoKit พร้อมรองรับการเร่งด้วยฮาร์ดแวร์
AES คืออะไร?
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 (XOR ด้วยคีย์รอบ)
ประวัติของมาตรฐาน AES
การพัฒนาของ AES เริ่มต้นในปี 1997 เมื่อ NIST ประกาศการแข่งขันเพื่อแทนที่ DES ซึ่งคีย์ 56 บิตถูกถอดรหัสใน 22 ชั่วโมงในปี 1998 บนอุปกรณ์เฉพาะทาง Deep Crack อัลกอริธึมสิบห้าชนิดจากหลายประเทศเข้าร่วม รวมถึง 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 ทำงานอย่างไร
AES ประมวลผลข้อมูลเป็นบล็อกขนาด 128 บิต (16 ไบต์) จัดเป็นเมทริกซ์ 4x4 ไบต์ที่เรียกว่า state แต่ละรอบการเข้ารหัสจะดำเนินการแปลงแบบกำหนดเป็นลำดับ ซึ่งรวมกันสร้างเอฟเฟกต์หิมะถล่ม: การเปลี่ยนหนึ่งบิตของข้อมูลนำเข้าจะเปลี่ยนประมาณ 50% ของบิตข้อมูลส่งออก เอฟเฟกต์นี้ทำให้ AES ทนทานต่อการวิเคราะห์รหัสแบบเชิงอนุพันธ์และเชิงเส้น — วิธีการหลักในการถอดรหัสแบบบล็อก
กระบวนการเริ่มต้นด้วย AddRoundKey — การทำ XOR ของคีย์เริ่มต้นกับ state จากนั้นดำเนินการรอบ: SubBytes แทนที่แต่ละไบต์ของ state ด้วยค่าจาก S-box (ตารางการแทนที่) ShiftRows เลื่อนแถวที่สองแบบวน 1 ตำแหน่ง แถวที่สาม 2 ตำแหน่ง แถวที่สี่ 3 ตำแหน่ง — เพื่อให้แน่ใจว่ามีการผสมระหว่างคอลัมน์ MixColumns คูณแต่ละคอลัมน์ของ state ด้วยเมทริกซ์คงที่ในฟิลด์ Galois GF(2^8) สร้างการพึ่งพาของแต่ละไบต์ส่งออกบนไบต์นำเข้าทั้งสี่ของคอลัมน์ AddRoundKey ทำ XOR ด้วยคีย์รอบถัดไป ซึ่งได้มาจากคีย์ดั้งเดิมผ่าน Key Expansion รอบสุดท้ายไม่มีการดำเนินการ MixColumns การถอดรหัสใช้การดำเนินการผกผัน InvSubBytes, InvShiftRows, InvMixColumns และ AddRoundKey ในลำดับย้อนกลับ สำหรับนักพัฒนาแอปพลิเคชันมือถือ ไม่จำเป็นต้องเข้าใจโครงสร้างภายในของ AES — เพียงพอที่จะรู้วิธีการเรียก API ในตัวของแพลตฟอร์มอย่างถูกต้องด้วยพารามิเตอร์ที่เหมาะสม
เอฟเฟกต์หิมะถล่มและความแข็งแกร่งทางการเข้ารหัสของ AES
คุณลักษณะสำคัญของ AES ที่รับประกันความแข็งแกร่งทางการเข้ารหัสคือเอฟเฟกต์หิมะถล่ม การเปลี่ยนหนึ่งบิตในข้อความธรรมดาหรือคีย์ส่งผลให้ประมาณ 50% ของบิตข้อความเข้ารหัสเปลี่ยนไป ทำให้ AES ทนทานอย่างยิ่งต่อการวิเคราะห์รหัสแบบเชิงอนุพันธ์และเชิงเส้น การรวมกันของ SubBytes (ความไม่เป็นเชิงเส้นผ่าน S-box) และ MixColumns (การกระจายผ่านการคูณในฟิลด์ Galois) สร้างความซับซ้อนทางคณิตศาสตร์ที่แม้จะรู้ส่วนหนึ่งของข้อความเข้ารหัสก็ไม่สามารถกู้คืนคีย์ได้เร็วกว่า brute force ตามการวิเคราะห์ของ NIST (2018) การโจมตีที่รู้จักดีที่สุดต่อ AES-128 — การโจมตีแบบ biclique — ลดความยาวคีย์ที่มีประสิทธิภาพเพียง 2 บิต (เหลือ 126.2 บิต) โดยไม่ให้ข้อได้เปรียบในทางปฏิบัติแก่ผู้โจมตี สำหรับ AES-256 ไม่มีการโจมตีที่ใช้งานได้จริงเกินกว่า brute force
ขนาดคีย์ AES และระดับความปลอดภัย
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 ครั้งผ่านอัลกอริธึมของ Grover ในขณะที่ AES-256 จะต้องใช้ 2^149 ครั้ง ทำให้ AES-256 ทนทานต่อการโจมตีแบบควอนตัมในอีก 20–30 ปีข้างหน้า แม้แต่ AES-128 ก็ให้การปกป้องเพียงพอสำหรับสถานการณ์เชิงพาณิชย์ส่วนใหญ่: การถอดรหัสคีย์ 128 บิตด้วย brute force จะต้องใช้พลังงานมากกว่าที่มีอยู่ในจักรวาลตามการประมาณของ Bruce Schneier อย่างไรก็ตาม มาตรฐานความปลอดภัย (GDPR, HIPAA, PCI DSS) มักกำหนดให้ใช้ AES-256 อย่างชัดเจน ดังนั้นโปรเจกต์ในระบบผลิตควรใช้ความยาวคีย์สูงสุด
โหมดการทำงานของ AES
AES ในฐานะการเข้ารหัสแบบบล็อกจะเข้ารหัสบล็อกขนาดคงที่ (128 บิต) สำหรับการเข้ารหัสข้อมูลที่มีความยาวตามต้องการ จะใช้โหมดการทำงาน การเลือกโหมดส่งผลกระทบอย่างมากต่อความปลอดภัย: โหมดที่ผิดสามารถลบล้างความแข็งแกร่งของ AES ได้
- ECB (Electronic Codebook) — โหมดที่ง่ายที่สุดและไม่ปลอดภัยที่สุด แต่ละบล็อกถูกเข้ารหัสอิสระด้วยคีย์เดียวกัน บล็อกข้อความธรรมดาที่เหมือนกันให้บล็อกข้อความเข้ารหัสที่เหมือนกัน ทำให้สามารถกู้คืนโครงสร้างข้อมูลได้ ถูกห้ามในมาตรฐานความปลอดภัยสมัยใหม่ทั้งหมด ห้ามใช้ ECB ในแอปพลิเคชันมือถือโดยเด็ดขาด
- CBC (Cipher Block Chaining) — แต่ละบล็อกข้อความเข้ารหัสก่อนหน้าถูกใช้เป็นเวกเตอร์เริ่มต้น (IV) สำหรับบล็อกถัดไป ต้องใช้ IV แบบสุ่มสำหรับแต่ละข้อความ เสี่ยงต่อการโจมตีแบบ padding oracle เมื่อใช้งานไม่ถูกต้อง เหมาะสำหรับการเข้ารหัสไฟล์แต่ต้องใช้ MAC (HMAC) เพื่อความสมบูรณ์ของข้อมูล
- GCM (Galois/Counter Mode) — โหมดที่แนะนำสำหรับแอปพลิเคชันมือถือ ให้การเข้ารหัสที่รับรองความถูกต้อง (AEAD): การเข้ารหัส + การตรวจสอบความสมบูรณ์ในการดำเนินการเดียว ใช้ตัวนับสำหรับสร้างกระแสคีย์และการคูณในฟิลด์ Galois สำหรับการรับรองความถูกต้อง GCM ต้องใช้ nonce ที่ไม่ซ้ำกัน (12 ไบต์) สำหรับแต่ละข้อความ แนะนำโดย NIST ใช้ใน TLS 1.2/1.3 และ Android Keystore
- CCM (Counter with CBC-MAC) — โหมด AEAD ทางเลือกที่ใช้ CTR + CBC-MAC ช้ากว่า GCM และไม่รองรับการประมวลผลแบบขนาน ใช้ในโปรโตคอล ZigBee และ 802.11 (Wi-Fi) สำหรับแอปพลิเคชันมือถือ GCM เหมาะกว่า
สำหรับโปรเจกต์มือถือให้ใช้ AES-256-GCM กับ nonce ขนาด 12 ไบต์ GCM แก้ปัญหาสองอย่างพร้อมกัน: การเข้ารหัสข้อมูลและการรับรองความถูกต้อง ป้องกันการโจมตีแบบ padding oracle และ chosen ciphertext Android Keystore และ iOS CryptoKit รองรับ AES-GCM ในตัวโดยไม่ต้องใช้พื้นฐานการเข้ารหัสเพิ่มเติม เมื่อทำงานกับ GCM สิ่งสำคัญคือต้องไม่ใช้ nonce ซ้ำกับคีย์เดียวกัน — สิ่งนี้ทำลายความปลอดภัยของการเข้ารหัสอย่างสมบูรณ์ สร้าง nonce แบบสุ่มใหม่สำหรับการเข้ารหัสแต่ละครั้งและเก็บไว้พร้อมกับข้อความเข้ารหัส
การนำ AES ไปใช้ในแอปพลิเคชันมือถือ
มาดูตัวอย่างการใช้งาน AES-256-GCM อย่างปลอดภัยบน Android โดยใช้ Jetpack Security โค้ดด้านล่างแสดงวงจรที่สมบูรณ์: การสร้างคีย์ AES-256 ผ่าน MasterKey, การเข้ารหัสและถอดรหัสสตริงด้วยข้อมูลที่รับรองความถูกต้องเพิ่มเติม (AAD)
kotlin
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+ ครั้ง
AES บน iOS ผ่าน CryptoKit
บน 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 เลือกพารามิเตอร์ที่เหมาะสมที่สุดโดยอัตโนมัติ ป้องกันการโจมตีทางช่องทางข้าง และใช้การเร่งฮาร์ดแวร์ AES-NI บนโปรเซสเซอร์ Apple Silicon บนอุปกรณ์ที่มี Secure Enclave คีย์จะไม่ออกจากโมดูลฮาร์ดแวร์เลย ป้องกันการขโมยแม้ว่าแอปพลิเคชันจะถูกบุกรุกอย่างสมบูรณ์ สำหรับการทำให้คีย์เป็นอนุกรม ให้ใช้เมธอด withUnsafeBytes ตามด้วยการเก็บใน Keychain ผ่าน SecItemAdd ด้วยแอตทริบิวต์ kSecAttrAccessible = kSecAttrAccessibleWhenUnlockedThisDeviceOnly
คำถามที่พบบ่อย
AES คืออะไรในคำง่าย ๆ?
AES คืออัลกอริธึมที่แปลงข้อมูลที่อ่านได้เป็นชุดไบต์ที่อ่านไม่ได้โดยใช้คีย์ลับ ต้องใช้คีย์เดียวกันเพื่อนำข้อมูลกลับสู่รูปแบบเดิม AES เชื่อถือได้มากจนใช้ในการเข้ารหัสเอกสารลับของรัฐบาลสหรัฐอเมริกา
AES-128 แตกต่างจาก AES-256 อย่างไร?
AES-128 ใช้คีย์ขนาด 128 บิตและดำเนินการ 10 รอบการเข้ารหัส AES-256 ใช้คีย์ 256 บิตและ 14 รอบ ทำให้ถอดรหัสได้ยากขึ้น 2^128 เท่า สำหรับแอปพลิเคชันมือถือ แนะนำ AES-256 เนื่องจากความแตกต่างด้านประสิทธิภาพน้อยมาก
โหมด AES ไหนปลอดภัยที่สุด?
AES-256-GCM เป็นโหมดที่ปลอดภัยที่สุดและแนะนำ GCM ให้การเข้ารหัสที่รับรองความถูกต้อง (การเข้ารหัส + การตรวจสอบความสมบูรณ์) ห้ามใช้โหมด ECB, CBC ต้องใช้ MAC แยกต่างหาก GCM เป็นมาตรฐานโดยพฤตินัยสำหรับแอปพลิเคชันมือถือ
AES สามารถถูกถอดรหัสได้หรือไม่?
ในทางทฤษฎี AES สามารถถูกถอดรหัสด้วย brute force แต่สำหรับ AES-256 ต้องใช้ความพยายาม 2^256 ครั้ง — มากกว่าจำนวนอะตอมในจักรวาลที่สังเกตได้ ไม่มีการโจมตีในทางปฏิบัติต่อ AES-256 การโจมตีทางช่องทางข้าง (Spectre, Meltdown) ไม่ได้ถอดรหัส AES แต่ขโมยคีย์จากหน่วยความจำ ดังนั้นการจัดเก็บคีย์ในฮาร์ดแวร์จึงสำคัญมาก
จะใช้ AES ในแอปมือถือบน Android ได้อย่างไร?
ใช้ไลบรารี AndroidX Security: MasterKey.Builder กับ KeyScheme.AES256_GCM สร้างคีย์ที่ป้องกันใน Android Keystore และ EncryptedSharedPreferences เข้ารหัสข้อมูลทั้งหมดโดยอัตโนมัติผ่าน AES-256-GCM ไม่ต้องใช้การเข้ารหัสด้วยตนเอง — API ปลอดภัยโดยค่าเริ่มต้น ไม่มีความเสี่ยงจากข้อผิดพลาดของนักพัฒนา
สรุป
- AES เป็นอัลกอริธึมการเข้ารหัสแบบสมมาตรที่แพร่หลายและผ่านการพิสูจน์มากที่สุด ซึ่งถูกทำให้เป็นมาตรฐานโดย NIST ในปี 2001
- AES-256 ให้ความปลอดภัยสูงสุดพร้อมส่วนต่างสำหรับการโจมตีแบบควอนตัมในอีก 20–30 ปีข้างหน้า
- โหมด GCM เป็นโหมดเดียวที่แนะนำสำหรับแอปพลิเคชันมือถือ: การเข้ารหัส + การรับรองความถูกต้องในการดำเนินการเดียว
- Android Keystore และ iOS Secure Enclave — พื้นที่จัดเก็บฮาร์ดแวร์ที่แยกคีย์ AES ออกจากแอปพลิเคชัน
- Jetpack Security (Android) และ CryptoKit (iOS) ให้การใช้งาน AES-256-GCM ที่ปลอดภัยโดยไม่ต้องเข้ารหัสด้วยตนเอง
- Nonce (IV) สำหรับ GCM ต้องไม่ซ้ำกันสำหรับการเข้ารหัสแต่ละครั้ง — การใช้ซ้ำจะทำลายความปลอดภัยอย่างสมบูรณ์
- คำแนะนำ: ใช้ AES-256-GCM ผ่าน EncryptedSharedPreferences บน Android และ CryptoKit บน iOS สำหรับข้อมูลที่ละเอียดอ่อนทั้งหมด
เราจะพัฒนาแอปพลิเคชันบนมือถือแบบครบวงจร
IT Sectr สร้างแอปพลิเคชัน iOS และ Android สำหรับสตาร์ทอัพและธุรกิจตั้งแต่ปี 2017 เราจะให้คำแนะนำและเสนอวิธีแก้ปัญหาที่ดีที่สุดแก่คุณ
อ่านเพิ่มเติม