Android میں Keystore — یہ کیا ہے، آرکیٹیکچر اور کرپٹوگرافی

Android میں Keystore کیا ہے؟

Android Keystore — Android پلیٹ فارم کا ایک سسٹم کمپوننٹ ہے جو محفوظ ماحول میں کرپٹوگرافک کلیچیں تیار کرنے، ذخیرہ کرنے اور استعمال کرنے کے لیے API فراہم کرتا ہے۔ سافٹویئر کرپٹوگرافک لائبریریڒ (Bouncy Castle, Conscrypt) کے برعکس، Keystore گارنٹی دیتا ہے کہ پرائیویٹ کلیچیں کبھی علاحدہ تعمیل علاقہ نہیں چھوڑتیں۔

Keystore Android 4.3 (API 18) میں RSA تعاون کے ساتھ ایک سافٹویئر پراوائیڈر کے طور پر ظاہر ہوا۔ Android 6.0 (API 23) سے شروع ہوکر، Keystore نے Keymaster Hardware Abstraction Layer (HAL) کے ذریعہ ہارڈویئر تعاون حاصل کیا، جو مطابق آلات پر کرپٹوگرافک کاروائیاں Trusted Execution Environment (TEE) کو سونپتی کرتا ہے۔ Android Compatibility Definition Document (2025) کے مطابق، Android 9+ والے تمام آلات کے لیے TEE یا StrongBox کے ذریعہ ہارڈویئر Keystore کی تعاون لازمی ہے۔

Keystore میں کلیچیں علامت (alias) سے پہچانی جاتی ہیں — ایک سٹرنگ جو کلیچ تیار یا لوڈ کرتے وقت دی جاتی ہے۔ Keystore کلیچ کا خام مواد حاصل کرنے کی اجازت نہیں دیتا: Keystore میں تیار کردہ کلیچوں کے لیے getEncoded() طریقے null واپس کرتے ہیں۔ یہ سافٹویئر کلیچوں سے بنیادی فرق ہے — حملہ آور آلہ پر مکمل کنٹرول کے باوجود بھی پرائیویٹ کلیچ نہیں نکال سکتا۔

Keystore Android کے دیگر حفاظتی میکانزم کے ساتھ مضمون ہے: بائیومیٹرک تصدیق (BiometricPrompt)، فائل سطح پر اینکرپشن (File-Based Encryption) اور SafetyNet/Play Integrity تصدیقی فنکشنز۔ کلیچیں مخصوص شرائط پر خودکار حذف کے لیے ترتیب دی جا سکتی ہیں: پاسورڈ ہٹانے پر، نئی انگلیت شامل کرنے پر یا میاد ختم ہونے پر۔

Android Keystore کا آرکیٹیکچر

Android Keystore کے آرکیٹیکچر میں تین نفاذی سطح شامل ہیں جو ہارڈویئر تحفظ کی ڈگری میں مختلف ہیں۔ سطح آلہ کی ہارڈویئر صلاحیتوں پر منحصر ہے۔

ہارڈویئر-تعاون یافتہ Keystore (TEE)

TEE (Trusted Execution Environment) — ایک علاحدہ علاقہ جو ایک ہی پروسیسر پر اوپریٹنگ سسٹم کے متوازی کام کرتا ہے۔ TEE ARM TrustZone ٹیکنالوجی استعمال کرتا ہے، جو پروسیسر کے فزیکل کور کو دو ورتضائی میں تقسیم کرتا ہے: Normal World (Android) اور Secure World (TEE)۔ Secure World میں کوڈ کی اس میموری اور پیریفیرل تک رسائی ہوتی ہے جو Normal World سے ناقابل رسائی ہے۔

جب ایپلیکیشن Keystore کے ذریعہ کرپٹوگرافک کاروائی کا مطالبہ کرتا ہے، درخواست Keymaster HAL کے ذریعہ TEE کو بھیجی جاتی ہے، جہاں کارروائی ہارڈویئر کے ذریعہ انجام پاتی ہے۔ نتیجہ ایپلیکیشن کو واپس کیا جاتا ہے، لیکن پرائیویٹ کلیچ TEE کی محفوظ میموری میں رہتی ہے۔ TEE GlobalPlatform TEE Protection Profile کے مطابق سرٹیفائیڈ ہے اور TrustZone کی حمایت کے ساتھ پروسیسر والے Android 9+ آلات کے لیے لازمی شرط ہے۔

TEE AES/GCM (128, 256 بٹ)، RSA (2048, 4096 بٹ)، EC (P-256, P-384, P-521) اور HMAC-SHA256 الگورتہم کی حمایت کرتا ہے۔ TEE کی کارکردگی سافٹویئر کرپٹوگرافی (سے 20–40%کم) سے کم ہے، لیکن معمولی کاروائیوں (JWT دستخت، سیشن کلیچ کا شفرے کہنے) کے لیے تاخیر 10–50 ms سے زیادہ نہیں ہوتا۔

StrongBox Keymaster

StrongBox — ایک مخصوصی سیکیورٹی چیپ ہے، جو مرکزی پروسیسر سے طبیعی طور پر علاحدہ ہے۔ TEE کے برعکس جو Android کے ساتھ پروسیسر کا وقت شیئر کرتا ہے، StrongBox کا اپنا CPU، RAM، True Random Number Generator (TRNG) اور محفوظ ذخیرہ (One-Time Programmable memory) ہوتا ہے۔ StrongBox Common Criteria EAL 4+ اور Secure IC Protection Profile پر سرٹیفائیڈ ہے۔

StrongBox Android 9+ والے آلات پر موجود ہوتا ہے جب مناسب چیپ موجود ہو (مثالاً، Google Pixel پر Titan M، Samsung Galaxy پر Knox)۔ ڈیولپر KeyGenParameterSpec میں setIsStrongBoxBacked(true) فلیگ کے ذریعہ StrongBox کو فعال کرتا ہے۔ ہارڈویئر حمایت کی غیرموجودگی میں، فلیگ کو نظرانداز کیا جاتا ہے اور Keystore TEE پر چلا جاتا ہے۔

StrongBox کی حدود: محدود الگورتہم سیٹ (AES-256, EC P-256, HMAC-SHA256) کی حمایت کرتا ہے، کاروائی کی قطار — ایک وقت میں از ایک زیادہ نہیں، کاروائیوں کی تعداد — چیپ کے وسائل سے محدود۔ StrongBox اعلی بوار کے مناظر کے لیے نہیں ہے — بار بار کی کاروائیوں کے لیے TEE استعمال کریں اور StrongBox کو صرف اہم کلیچوں (ماسٹر اینکرپشن کلیچیں، دستخت کلیچیں) کے لیے استعمال کریں۔

سافٹویئر بیسڈ Keystore

سافٹویئر بیسڈ Keystore — سافٹویئر نفاذ جو TEE یا StrongBox ہارڈویئر حمایت کے بغیر آلات پر استعمال ہوتا ہے۔ کلیچیں فائل سسٹم میں اینکرپٹیڈ شکل میں محفوظ ہوتی ہیں، لیکن پرائیویٹ کلیچ عارضی طور پر RAM میں شفرے کی جا سکتی ہے۔ سافٹویئر Keystore کم محفوظ ہے — روٹ رسائی والا حملہ آور میموری میں کلیچ کو روک سکتا ہے۔

Android 12 (API 31) سے شروع ہوکر، Google تمام نئے آلات کے لیے ہارڈویئر Keystore حمایت لازمی کرتا ہے۔ Android 9–11 والے آلات میں سستے موڈل پر سافٹویئر Keystore ہو سکتا ہے۔ ڈیولپر KeyStore.getKeyCharacteristics() کے ذریعہ تحفظ کی سطح کی جانچ کر سکتا ہے — SECURITY_LEVEL_TRUSTED_ENVIRONMENT یا SECURITY_LEVEL_STRONGBOX وضاحت ہارڈویئر تحفظ کی تصدیق کرتی ہے۔

تعاون یافتہ الگورتہم اور فنکشنز

Android Keystore کلیچ کی قسم کے بائیس زمرہ میں تقسیم شدہ کرپٹوگرافک الگورتہم کے وسیع سیٹ کی حمایت کرتا ہے۔ الگورتہم کا انتخاب کارکردگی، مطابقت اور حفاظتی سطح کو متاثر کرتا ہے۔

AES (Advanced Encryption Standard) — آلہ پر ڈیٹا تحفظ کے لیے متناظر اینکرپشن۔ متجوزہ موڈ: AES/GCM/NoPadding (256 بٹ)۔ GCM تصدیق شدہ اینکرپشن (AEAD) فراہم کرتا ہے — اینکرپٹیڈ ڈیٹا کی سلامتی کی جانچ کرتا ہے۔ GCM کے لیے IV (Initialization Vector) کا حجم: 12 بائٹ۔ AES/ECB کا استعمال نہ کریں — یہ مناسب تحفظ فراہم نہیں کرتا۔

RSA (Rivest–Shamir–Adleman) — سیشن کلیچ تحفظ اور ڈیجٹل دستخت کے لیے غیر متناظر اینکرپشن۔ متجوزہ حجم: 2048 یا 4096 بٹ۔ موڈ: RSA/ECB/PKCS1Padding (اینکرپشن) اور RSA/ECB/PKCS1Sign (دستخت)۔ RSA 1024 کو فرسودہ سمجھا جاتا ہے اور نئے ایپلیکیشن کے لیے سفارش نہیں کی جاتی (NIST SP 800-131A Rev. 2)۔

EC (Elliptic Curve) — دستخت اور کلیچ تبادلے کے لیے بیضوی منحنیات پر غیر متناظر کرپٹوگرافی۔ معاون منحنیات: secp256r1 (P-256, لازمی), secp384r1 (P-384) اور secp521r1 (P-521)۔ EC کف چھوٹے کلیچ حجم پر RSA کے برابر حفاظت فراہم کرتا ہے۔ P-256 زیادہ تر مناظر کے لیے متجوزہ ہے: یہ تمام آلات پر تعاون یافتہ ہے اور 128 بٹ حفاظتی سطح فراہم کرتا ہے۔

HMAC (Hash-based Message Authentication Code) — پیغامات کی متناظر تصدیق۔ معاون ہیش فنکشنز: SHA-256, SHA-384, SHA-512۔ HMAC ڈیٹا کی سلامتی اور مستندیت کی تصدیق کے لیے استعمال ہوتا ہے، مثالاً، webhook درخواستوں کی تصدیق یا ترتیب کی سلامتی کی جانچ کے لیے۔

تمام الگورتہم KeyGenParameterSpec.Builder.setUserAuthenticationRequired(true) کے ذریعہ بائیومیٹرک تصدیق سے منسلک ہو سکتے ہیں۔ Android 11+ پر setUserAuthenticationParameters() فلیگ دستیاب ہے جو ایک طرف (Seconds میں) متعین کرتا ہے جس دوران کلیچ بائیومیٹرک تصدیق کے بعد بغیر دوبارہ درخواست کے دستیاب ہوتی ہے۔

کوڈ کی مالیکیں: کلیچ تیاری اور استعمال

Kotlin میں Android Keystore کے ساتھ عملی مثالیں دیکھیں: AES کلیچ تیاری، ڈیٹا اینکرپشن اور دستخت کے لیے غیر متناظر جوڑی بنانا۔

Keystore میں AES کلیچ تیاری

مثال بائیومیٹرک تصدیق سے منسلک 256 بٹ AES/GCM کلیچ تیار کرتا ہے۔ کلیچ getEncoded() کے ذریعہ برآمد کے لیے دستیاب نہیں ہے۔

import android.security.keystore.KeyGenParameterSpec
import android.security.keystore.KeyProperties
import java.security.KeyStore

private val keyStore = KeyStore.getInstance("AndroidKeyStore").apply { load(null) }

fun generateAesKey(alias: String) {
    val spec = KeyGenParameterSpec.Builder(
        alias,
        KeyProperties.PURPOSE_ENCRYPT or
        KeyProperties.PURPOSE_DECRYPT
    )
    .setKeySize(256)
    .setBlockModes(KeyProperties.KEY_BLOCK_MODE_GCM)
    .setEncryptionPaddings(KeyProperties.ENCRYPTION_PADDING_NONE)
    .setUserAuthenticationRequired(true)
    .setInvalidatedByBiometricEnrollment(true)
    .build()

    val generator = KeyGenerator.getInstance(
        KeyProperties.KEY_ALGORITHM_AES,
        "AndroidKeyStore"
    )
    generator.init(spec)
    generator.generateKey()
}

AES/GCM ڈیٹا اینکرپشن

مثال Android Keystore سے کلیچ استعمال کرکے ڈیٹا اینکرپٹ کرتا ہے۔ Cipher علامت سے کلیچ حاصل کرتا ہے، AES/GCM اینکرپشن شروع کرتا ہے اور IV کے ساتھ اینکرپٹیڈ ڈیٹا واپس کرتا ہے۔

fun encryptData(alias: String, plaintext: ByteArray): ByteArray {
    val cipher = Cipher.getInstance("AES/GCM/NoPadding")
    val secretKey = keyStore.getKey(alias, null) as SecretKey
    cipher.init(Cipher.ENCRYPT_MODE, secretKey)

    val iv = cipher.getIV()
    val encrypted = cipher.doFinal(plaintext)

    // IV + اینکرپٹیڈ ڈیٹا
    return iv + encrypted
}

fun decryptData(alias: String, ciphertextWithIv: ByteArray): ByteArray {
    val iv = ciphertextWithIv.copyOfRange(0, 12)
    val encrypted = ciphertextWithIv.copyOfRange(12, ciphertextWithIv.size)

    val cipher = Cipher.getInstance("AES/GCM/NoPadding")
    val secretKey = keyStore.getKey(alias, null) as SecretKey
    val spec = GCMParameterSpec(128, iv)
    cipher.init(Cipher.DECRYPT_MODE, secretKey, spec)

    return cipher.doFinal(encrypted)
}

دستخت کے لیے RSA جوڑی تیاری

مثال StrongBox سے منسلک RSA-2048 کلیچ جوڑی Keystore میں تیار کرتا ہے۔ پرائیویٹ کلیچ دستخت کے لیے استعمال ہوتی ہے، عوام کلیچ getEncoded() کے ذریعہ برآمد کی جا سکتی ہے۔

fun generateRsaKeyPair(alias: String) {
    val spec = KeyGenParameterSpec.Builder(
        alias,
        KeyProperties.PURPOSE_SIGN or
        KeyProperties.PURPOSE_VERIFY
    )
    .setKeySize(2048)
    .setSignaturePaddings(
        KeyProperties.SIGNATURE_PADDING_RSA_PKCS1
    )
    .setDigests(KeyProperties.DIGEST_SHA256)
    .setIsStrongBoxBacked(true)
    .build()

    val pair = KeyPairGenerator.getInstance(
        KeyProperties.KEY_ALGORITHM_RSA,
        "AndroidKeyStore"
    ).apply { init(spec) }
     .generateKeyPair()

    // عوام کلیچ برآمد کی جا سکتی ہے
    val publicKey = pair.public // X509EncodedKeySpec
}

Android Keystore کے ساتھ بہترین طریقے

Android Keystore کا مؤثر استعمال ان قوانین پر عمل کرنے کا تقاضا کرتا ہے جو کارکردگی برقرار رکھتے ہوئے زیادہ سے زیادہ تحفظ یقینی بناتے ہیں۔

KeyGenParameterSpec کو از ضروری پارامیٹرز کے ساتھ استعمال کریں: صرف وہی purpose، block modes اور paddings متعین کریں جو فعلی طور پر استعمال ہوتے ہیں۔ ضرورت سے زائد پارامیٹرز (مثالاً، صرف دستخت کے لیے استعمال ہونے والی کلیچ کے لیے PURPOSE_ENCRYPT) غیر ضروری حملۙ ویکٹر تیار کرتے ہیں۔ Android دستخت کے لیے ڈائجسٹ کو واضح طور پر متعین کرنے کی سفارش کرتا ہے — SHA256 کم سے کم قابل قبول سطح ہے (SHA1 فرسودہ ہے)۔

اہم کاروائیوں کے لیے کلیچوں کو بائیومیٹرکس سے منسلک کریں: setUserAuthenticationRequired(true) گارنٹی دیتا ہے کہ کلیچ صرف بائیومیٹرک تصدیق کے بعد ہی استعمال کی جا سکتی ہے۔ Android 11+ پر ایک سیشن کے اندر ہر کارروائی کے لیے بائیومیٹرکس کا مطالبہ نہ کرنے کے لیے طرف (متجوزہ 30–60 سیکنڈ) کے ساتھ setUserAuthenticationParameters() استعمال کریں۔ setInvalidatedByBiometricEnrollment(true) نئی انگلیت یا چہرہ شامل کرنے پر خودکار طور پر کلیچ کو ناکارب کر دیتا ہے — پرانے بائیومیٹرک ڈیٹا کے ذریعہ رسائی کو روکتا ہے۔

آغاز کے مرحلہ پر حفاظتی سطح کی جانچ کریں: SECURITY_LEVEL متعین کرنے کے لیے KeyStore.getKeyCharacteristics() استعمال کریں۔ اگر آلہ صرف سافٹویئر Keystore (SECURITY_LEVEL_SOFTWARE) کی حمایت کرتا ہے، فیصلہ کریں: یا تو فنکشنالٹی کو مسترد کریں یا اضافی اینکرپشن (مثالاً، صارف کے پاسورڈ کے ذریعہ کلیچ لپٹنا) استعمال کریں۔ اگر StrongBox گارنٹیڈ نہیں ہے تو اس پر بھروسہ نہ کریں — ہمیشہ setIsStrongBoxBacked(true) فلیگ متعین کریں اور getKeyCharacteristics کے ذریعہ نتیجہ چیک کریں۔

مقررہ کے مطابق کلیچیں اپ ڈیٹ کریں: کرپٹوگرافک کلیچوں کی ایک متجوزہ زندگی ہوتی ہے۔ NIST SP 800-57 AES کلیچوں کو ہر 1–2 سال، RSA/EC جوڑیوں کو ہر 2–3 سال میں بدلنے کی سفارش کرتا ہے۔ کلیچ گردش کا میکانزم نفذ کریں: ایپ لانچ پر کلیچ تخلیق کی تاریخ (KeyGenParameterSpec.Builder.setKeyValidityStart/End) چیک کریں اور میاد ختم ہونے پر نئی کلیچ تیار کریں۔ پرانے کلیچ سے اینکرپٹیڈ پرانا ڈیٹا شفرے شدہ اور نئی کلیچ سے دوبارہ اینکرپٹ ہونا چاہیے۔

بڑے ڈیٹا کے لیے Keystore کا استعمال نہ کریں: Keystore کلیچ ذخیرہ کرنے (چند سو بائٹ) کے لیے ہے، بڑی فائلوں کو اینکرپٹ کرنے کے لیے نہیں۔ ڈیٹا اینکرپشن کے لیے سکیم استعمال کریں: ایک بہتروی AES کلیچ (DEK — Data Encryption Key) تیار کریں، ڈیٹا کو اس کلیچ سے اینکرپٹ کریں، اور DEK کو Keystore کلیچ (KEK — Key Encryption Key) سے اینکرپٹ کریں۔ Android EncryptedSharedPreferences بلکل اسی سکیم کا استعمال کرتا ہے: ماسٹر کلیچ Keystore میں، ڈیٹا — AES-256 GCM۔