एंड्रॉइड में Keystore — यह क्या है, आर्किटेक्चर और क्रिप्टोग्राफ़ी

लेखक: IT Sectr प्रकाशित: 2026-04-04 पढ़ने का समय: 9 मिनट

Android Keystore — एक क्रिप्टोग्राफ़िक प्रदाता है जो एन्क्रिप्शन कुंजियाँ जनरेट करता है और उन्हें पृथक निष्पादन वातावरण (TEE) में संग्रहीत करता है, जो ऑपरेटिंग सिस्टम के लिए भी अगम्य है। AOSP Security Documentation (2025) के अनुसार, Google Play के टॉप-100 एप्लिकेशन में से 80% से अधिक Android-एप्लिकेशन टोकन सुरक्षा और डेटा एन्क्रिप्शन के लिए Keystore का उपयोग करते हैं। Android Keystore को समझना Android पर सुरक्षित कुंजी भंडारण के लिए अत्यंत महत्वपूर्ण है।

मुख्य बातें

  • Android Keystore — हार्डवेयर-पृथक वातावरण (TEE) में क्रिप्टोग्राफ़िक कुंजियाँ जनरेट करने और संग्रहीत करने के लिए सिस्टम प्रदाता।
  • StrongBox Keymaster — अपने स्वयं के CPU और TRNG के साथ समर्पित सुरक्षा चिप, Common Criteria EAL 4+ प्रमाणित।
  • KeyGenParameterSpec — एल्गोरिदम, कुंजी आकार, बायोमेट्रिक बाइंडिंग और समाप्ति तिथि निर्धारित करने के लिए कॉन्फ़िगरेटर।
  • TEE (Trusted Execution Environment) — प्रोसेसर का पृथक क्षेत्र जहाँ उपयोगकर्ता स्थान से पहुँच के बिना क्रिप्टोग्राफ़िक संचालन निष्पादित होते हैं।
  • Keystore से कुंजियाँ निकाली नहीं जा सकतीं — निजी कुंजी कभी भी TEE या StrongBox को नहीं छोड़ती, यहाँ तक कि एप्लिकेशन डेवलपर भी इसे नहीं पढ़ सकता।

एंड्रॉइड में 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 की आर्किटेक्चर में तीन कार्यान्वयन स्तर शामिल हैं, जो हार्डवेयर सुरक्षा की डिग्री में भिन्न हैं। स्तर डिवाइस के हार्डवेयर की क्षमताओं पर निर्भर करता है।

Hardware-backed Keystore (TEE)

TEE (Trusted Execution Environment) — एक पृथक क्षेत्र है जो उसी प्रोसेसर पर मुख्य OS के समानांतर काम करता है। 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 मिसे से अधिक नहीं होता।

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 का उपयोग केवल महत्वपूर्ण कुंजियों (मास्टर एन्क्रिप्शन कुंजियाँ, हस्ताक्षर कुंजियाँ) के लिए करें।

Software-based Keystore

Software-based 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() फ़्लैग उपलब्ध है जो टाइमआउट (सेकंड में) निर्दिष्ट करता है, जिसके दौरान कुंजी बायोमेट्रिक प्रमाणीकरण के बाद बिना पुनः अनुरोध के उपलब्ध रहती है।

कोड उदाहरण: कुंजी जनरेशन और उपयोग

Android Keystore के साथ Kotlin में व्यावहारिक उदाहरण देखें: AES कुंजी जनरेशन, डेटा एन्क्रिप्शन और हस्ताक्षर के लिए असममित जोड़ी बनाना।

Keystore में AES कुंजी जनरेशन

उदाहरण बायोमेट्रिक प्रमाणीकरण से बंधी 256-बिट AES/GCM कुंजी बनाता है। कुंजी getEncoded() के माध्यम से निर्यात के लिए अनुपलब्ध है।

kotlin
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 के साथ एन्क्रिप्टेड डेटा लौटाता है।

kotlin
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 जोड़ी जनरेशन

उदाहरण Keystore में StrongBox से बंधी RSA-2048 कुंजी जोड़ी बनाता है। निजी कुंजी हस्ताक्षर के लिए उपयोग की जाती है, सार्वजनिक कुंजी getEncoded() के माध्यम से निर्यात की जा सकती है।

kotlin
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।

अक्सर पूछे जाने वाले प्रश्न

क्या Android Keystore से निजी कुंजी प्राप्त की जा सकती है?

नहीं, Android Keystore इस तरह डिज़ाइन किया गया है कि निजी कुंजी कभी भी TEE या StrongBox को नहीं छोड़ती। Keystore में बनाई गई कुंजियों के लिए getEncoded() विधि null लौटाती है। कुंजी का उपयोग केवल Cipher, Signature या Mac API के माध्यम से किया जा सकता है — कच्चा मटेरियल उपलब्ध नहीं है।

TEE और StrongBox में क्या अंतर है?

TEE (TrustZone) — उसी प्रोसेसर पर वर्चुअल आइसोलेशन, समय विभाजन का उपयोग करता है। StrongBox — अपने स्वयं के CPU और मेमोरी वाली अलग चिप। StrongBox अधिक सुरक्षित (Common Criteria EAL 4+) है, लेकिन धीमा है और कम एल्गोरिदम का समर्थन करता है। TEE बार-बार के संचालन के लिए उपयुक्त है, StrongBox — महत्वपूर्ण कुंजियों के लिए।

कैसे जाँचें कि डिवाइस StrongBox का समर्थन करता है?

setIsStrongBoxBacked(true) फ़्लैग के साथ कुंजी जनरेशन के बाद KeyStore.getKeyCharacteristics() का उपयोग करें। SECURITY_LEVEL_STRONGBOX विशेषता हार्डवेयर समर्थन की पुष्टि करती है। यदि डिवाइस StrongBox का समर्थन नहीं करता, तो Keystore बिना त्रुटि के TEE पर स्विच हो जाता है — सुरक्षा स्तर की स्पष्ट रूप से जाँच करना आवश्यक है।

एप्लिकेशन हटाने पर कुंजियों का क्या होता है?

Keystore में कुंजियाँ डिवाइस से एप्लिकेशन हटाने पर स्वचालित रूप से हटा दी जाती हैं। Android 10+ पर कुंजियाँ बनी रह सकती हैं यदि एप्लिकेशन में मेनिफ़ेस्ट में allowBackup=true फ़्लैग है, लेकिन वे पुनः इंस्टॉलेशन के बाद अनुपलब्ध होंगी। साफ़ इंस्टॉलेशन पर कुंजियाँ पुनः जनरेट करने की अनुशंसा की जाती है।

क्या एक कुंजी का उपयोग कई उपकरणों पर किया जा सकता है?

नहीं, Android Keystore किसी विशिष्ट डिवाइस के हार्डवेयर से बंधा है। एक डिवाइस के TEE में जनरेट की गई कुंजी को दूसरे डिवाइस पर स्थानांतरित नहीं किया जा सकता। क्रॉस-प्लेटफ़ॉर्म एन्क्रिप्शन के लिए योजना का उपयोग करें: Keystore डिवाइस पर कुंजी की रक्षा करता है, और सत्र कुंजियाँ असममित एन्क्रिप्शन का उपयोग करके सुरक्षित API के माध्यम से प्रेषित की जाती हैं।

सारांश

  • Android Keystore — हार्डवेयर-पृथक वातावरण (TEE या StrongBox) में क्रिप्टोग्राफ़िक कुंजियों की सुरक्षा के लिए सिस्टम प्रदाता।
  • TEE (TrustZone) — उसी प्रोसेसर पर वर्चुअल आइसोलेशन, TrustZone वाले Android 9+ उपकरणों के लिए अनिवार्य।
  • StrongBox — Common Criteria EAL 4+ प्रमाणन के साथ समर्पित सुरक्षा चिप, setIsStrongBoxBacked(true) के माध्यम से सक्षम।
  • KeyGenParameterSpec — कुंजी पैरामीटर कॉन्फ़िगर करने के लिए केंद्रीय वर्ग: एल्गोरिदम, आकार, बायोमेट्रिक बाइंडिंग और रोटेशन।
  • कुंजियाँ निकाली नहीं जा सकतीं — निजी मटेरियल getEncoded() के माध्यम से उपलब्ध नहीं, संचालन TEE/StrongBox के अंदर निष्पादित होते हैं।
  • अनुशंसित एल्गोरिदम — एन्क्रिप्शन के लिए AES/GCM/NoPadding (256 बिट), हस्ताक्षर के लिए EC P-256, असममित परिदृश्यों के लिए RSA 2048।
  • KEK/DEK योजना — Keystore डेटा एन्क्रिप्शन कुंजियों की सुरक्षा के लिए मास्टर कुंजी संग्रहीत करता है, प्रदर्शन और सुरक्षा सुनिश्चित करता है।

हम एक मोबाइल एप्लिकेशन टर्नकी विकसित करेंगे

IT Sectr 2017 से स्टार्टअप और व्यवसायों के लिए iOS और Android एप्लिकेशन बनाता है। हम आपको सलाह देंगे और सर्वोत्तम समाधान प्रस्तावित करेंगे।

परियोजना पर चर्चा करें

यह भी पढ़ें