इस पेज का अनुवाद Cloud Translation API से किया गया है.

कुंजी को प्रमाणित करने की सुविधा के साथ, हार्डवेयर-बैक्ड कुंजी के जोड़े की पुष्टि करें

पासकोड की पुष्टि करने से आपको ज़्यादा भरोसा होता है कि आपके ऐप्लिकेशन में इस्तेमाल की जाने वाली पासकोड, डिवाइस के हार्डवेयर पर आधारित पासकोड स्टोर में सेव किए गए हैं. यहां दिए गए सेक्शन में, हार्डवेयर से सुरक्षित कुंजियों की प्रॉपर्टी की पुष्टि करने और पुष्टि करने वाले सर्टिफ़िकेट के एक्सटेंशन डेटा का विश्लेषण करने का तरीका बताया गया है.

ध्यान दें: किसी डिवाइस की हार्डवेयर पर आधारित कुंजियों की प्रॉपर्टी की पुष्टि, प्रोडक्शन-लेवल के एनवायरमेंट में करने से पहले, पक्का करें कि डिवाइस में हार्डवेयर-लेवल पर कुंजी की पुष्टि करने की सुविधा काम करती हो. ऐसा करने के लिए, देखें कि पुष्टि करने वाले सर्टिफ़िकेट की चेन में एक रूट सर्टिफ़िकेट हो, जिस पर Google की पुष्टि करने वाली रूट कुंजी से हस्ताक्षर किया गया हो. साथ ही, यह भी देखें कि कुंजी की जानकारी डेटा स्ट्रक्चर में मौजूद attestationSecurityLevel एलिमेंट, सुरक्षा के TrustedEnvironment लेवल या StrongBox लेवल पर सेट हो.

इसके अलावा, सर्टिफ़िकेट चेन में मौजूद हस्ताक्षरों की पुष्टि करना और सर्टिफ़िकेट रद्द करने की स्थिति की सूची देखकर यह पुष्टि करना ज़रूरी है कि चेन में मौजूद किसी भी पासकोड को रद्द नहीं किया गया है. जब तक सभी एट्रिब्यूट मान्य नहीं होते और रूट, Google रूट पासकोड नहीं होता, तब तक पुष्टि पर पूरी तरह भरोसा न करें. हालांकि, ध्यान दें कि जिन डिवाइसों में रद्द किए गए सर्टिफ़िकेट मौजूद हैं वे कम से कम उतने ही भरोसेमंद हैं जितने वे डिवाइस जो सिर्फ़ सॉफ़्टवेयर की पुष्टि की सुविधा के साथ काम करते हैं. पूरी तरह मान्य पुष्टि का होना, एक अच्छा संकेत है. ऐसा नहीं होने पर भी यह पता चलता है कि यह न्यूट्रल है - नेगेटिव नहीं.

हार्डवेयर-बैक्ड कुंजी का जोड़ा वापस पाएं और उसकी पुष्टि करें

पासकोड की पुष्टि के दौरान, आपको पासकोड जोड़े के उपनाम की जानकारी देनी होती है और उसका सर्टिफ़िकेट चेन पाना होता है. इस सर्टिफ़िकेट चेन का इस्तेमाल, पासकोड जोड़े की प्रॉपर्टी की पुष्टि करने के लिए किया जा सकता है.

अगर डिवाइस में हार्डवेयर-लेवल की कुंजी की पुष्टि करने की सुविधा काम करती है, तो इस चेन में मौजूद रूट सर्टिफ़िकेट पर, पुष्टि करने वाली रूट कुंजी का इस्तेमाल करके हस्ताक्षर किया जाता है. यह कुंजी, डिवाइस के हार्डवेयर पर आधारित कीस्टोर में सुरक्षित तरीके से सेट की जाती है.

ध्यान दें: हार्डवेयर-लेवल पासकोड की पुष्टि करने की सुविधा, Android 7.0 (एपीआई लेवल 24) या इसके बाद के वर्शन, और Google Play services के साथ शिप होने वाले डिवाइसों पर, रूट सर्टिफ़िकेट पर Google की पुष्टि करने वाली रूट पासकोड से हस्ताक्षर किया जाता है. पुष्टि करें कि यह रूट सर्टिफ़िकेट, रूट सर्टिफ़िकेट सेक्शन में मौजूद सर्टिफ़िकेट में से एक हो.

कुंजी को प्रमाणित करने की प्रक्रिया को लागू करने के लिए, नीचे दिया गया तरीका अपनाएं:

हार्डवेयर पर आधारित पासकोड सेव करने की सुविधा वाले पासकोड स्टोर से जुड़े X.509 सर्टिफ़िकेट की चेन का रेफ़रंस पाने के लिए, KeyStore ऑब्जेक्ट के getCertificateChain() तरीके का इस्तेमाल करें.
पुष्टि करने के लिए, सर्टिफ़िकेट किसी ऐसे अलग सर्वर पर भेजें जिस पर आपको भरोसा हो.

चेतावनी: पुष्टि करने की यह प्रोसेस, उसी डिवाइस पर न करें जिस पर KeyStore मौजूद है. अगर उस डिवाइस के Android सिस्टम को हैक किया गया है, तो इसकी वजह से पुष्टि करने वाली प्रोसेस में किसी ऐसी चीज़ पर भरोसा किया जा सकता है जो भरोसेमंद न हो.
X.509 सर्टिफ़िकेट चेन को पार्स करने और पुष्टि करने वाली ऐसी लाइब्रेरी का रेफ़रंस पाएं जो आपके टूलसेट के लिए सबसे सही हो. पुष्टि करें कि रूट सार्वजनिक सर्टिफ़िकेट भरोसेमंद है और हर सर्टिफ़िकेट, चेन में अगले सर्टिफ़िकेट पर हस्ताक्षर करता है.
हर सर्टिफ़िकेट के रद्द होने का स्टेटस देखें, ताकि यह पक्का किया जा सके कि किसी भी सर्टिफ़िकेट को रद्द नहीं किया गया है.
इसके अलावा, प्रॉविज़न करने की जानकारी वाले सर्टिफ़िकेट एक्सटेंशन की जांच करें. यह एक्सटेंशन, सिर्फ़ नई सर्टिफ़िकेट चेन में मौजूद होता है.

अपने टूलसेट के लिए सबसे सही CBOR पार्स करने वाली लाइब्रेरी का रेफ़रंस पाएं. रूट के सबसे नज़दीक का वह सर्टिफ़िकेट ढूंढें जिसमें प्रोसवाइज़िंग की जानकारी वाला सर्टिफ़िकेट एक्सटेंशन शामिल हो. उस सर्टिफ़िकेट से, प्रोवाइज़न करने की जानकारी वाले सर्टिफ़िकेट एक्सटेंशन का डेटा निकालने के लिए, पार्सर का इस्तेमाल करें.

ज़्यादा जानकारी के लिए, प्रावधान की जानकारी देने वाले एक्सटेंशन के डेटा स्कीमा का सेक्शन देखें.
अपने टूलसेट के लिए सबसे सही ASN.1 पार्स करने वाली लाइब्रेरी का रेफ़रंस पाएं. रूट के सबसे नज़दीक का वह सर्टिफ़िकेट ढूंढें जिसमें कुंजी की पुष्टि करने वाला सर्टिफ़िकेट एक्सटेंशन हो. अगर डिवाइस को चालू करने की जानकारी वाले सर्टिफ़िकेट का एक्सटेंशन मौजूद था, तो पुष्टि करने वाले सर्टिफ़िकेट का एक्सटेंशन, अगले सर्टिफ़िकेट में होना चाहिए. उस सर्टिफ़िकेट से, पुष्टि करने वाले सर्टिफ़िकेट के एक्सटेंशन का मुख्य डेटा निकालने के लिए, पार्स करने वाले टूल का इस्तेमाल करें.

चेतावनी: यह न मानें कि कुंजी की पुष्टि करने वाला सर्टिफ़िकेट एक्सटेंशन, चेन के लीफ़ सर्टिफ़िकेट में मौजूद है. चेन में, एक्सटेंशन के सिर्फ़ पहले वर्शन पर भरोसा किया जा सकता है. एक्सटेंशन के किसी और उदाहरण को सुरक्षित हार्डवेयर ने जारी नहीं किया है. ऐसा हो सकता है कि अटैकर ने अविश्वसनीय कुंजियों के लिए फ़र्ज़ी पुष्टि करने की कोशिश करते समय, चेन को बढ़ाकर ऐसा किया हो.

कुंजी के पुष्टि करने वाले सर्टिफ़िकेट का सैंपल, Bouncy Castle के ASN.1 पार्सर का इस्तेमाल करके, पुष्टि करने वाले सर्टिफ़िकेट के एक्सटेंशन डेटा को निकालता है. अपना पार्सर बनाने के लिए, इस सैंपल को पहचान फ़ाइल के तौर पर इस्तेमाल किया जा सकता है.

ज़्यादा जानकारी के लिए, मुख्य पुष्टि करने के एक्सटेंशन के डेटा स्कीमा का सेक्शन देखें.
पिछले चरणों में हासिल किए गए एक्सटेंशन डेटा की जांच करें, ताकि यह पता चल सके कि वह एक जैसा है या नहीं. साथ ही, उस डेटा की तुलना उन वैल्यू के सेट से करें जो आपको लगता है कि हार्डवेयर की मदद से सुरक्षित की गई कुंजी में होनी चाहिए.

रूट सर्टिफ़िकेट

पुष्टि की भरोसेमंदता, चेन के रूट सर्टिफ़िकेट पर निर्भर करती है. Android डिवाइसों को Google Play के साथ-साथ, Google के अन्य ऐप्लिकेशन इस्तेमाल करने के लिए, ज़रूरी टेस्टिंग से गुज़रना होता है. ऐसे डिवाइसों को Android 7.0 (एपीआई लेवल 24) या उसके बाद के वर्शन पर लॉन्च किया जाना चाहिए. साथ ही, इन डिवाइसों को Google के हार्डवेयर की पुष्टि करने वाले रूट सर्टिफ़िकेट से साइन की गई पुष्टि करने वाली कुंजियों का इस्तेमाल करना चाहिए. ध्यान दें कि Android 8.0 (एपीआई लेवल 26) तक, पुष्टि करना ज़रूरी नहीं था. रूट सार्वजनिक कुंजी इस तरह से होती है:

पहले जारी किए गए रूट सर्टिफ़िकेट

अगर आपको मिली पुष्टि की चेन में मौजूद रूट सर्टिफ़िकेट में यह सार्वजनिक कुंजी है और चेन में मौजूद किसी भी सर्टिफ़िकेट को रद्द नहीं किया गया है, तो आपको यह पता चलता है कि:

आपकी कुंजी उस हार्डवेयर में हो जिसे Google सुरक्षित मानता हो; और
इसमें, पुष्टि करने वाले सर्टिफ़िकेट में बताई गई प्रॉपर्टी होती हैं.

अगर पुष्टि करने वाली चेन में कोई दूसरी रूट सार्वजनिक कुंजी है, तो Google, हार्डवेयर की सुरक्षा के बारे में कोई दावा नहीं करता. इसका मतलब यह नहीं है कि आपकी कुंजी का इस्तेमाल गलत तरीके से किया जा रहा है. इसका मतलब सिर्फ़ यह है कि पुष्टि करने की प्रक्रिया से यह साबित नहीं होता कि कुंजी सुरक्षित हार्डवेयर में है. सुरक्षा से जुड़े अपने अनुमानों में बदलाव करें.

अगर रूट सर्टिफ़िकेट में इस पेज पर सार्वजनिक कुंजी मौजूद नहीं है, तो इसकी दो वजहें हो सकती हैं:

ऐसा हो सकता है कि डिवाइस को Android 7.0 से पहले के वर्शन के साथ लॉन्च किया गया हो और वह हार्डवेयर की पुष्टि करने की सुविधा के साथ काम न करता हो. इस मामले में, Android में पुष्टि करने के लिए एक सॉफ़्टवेयर लागू किया गया है. इससे, पुष्टि करने वाला वही सर्टिफ़िकेट मिलता है. हालांकि, इसे Android के सोर्स कोड में हार्डकोड की गई पासकोड से साइन किया जाता है. साइनिंग पासकोड को सार्वजनिक तौर पर शेयर किया जाता है. इसलिए, हो सकता है कि हमलावर ने सुरक्षित हार्डवेयर उपलब्ध कराने का दावा करके, पुष्टि करने वाला सर्टिफ़िकेट बनाया हो.
इसकी एक और वजह यह हो सकती है कि डिवाइस, Google Play डिवाइस न हो. ऐसे में, डिवाइस बनाने वाली कंपनी अपने हिसाब से रूट बना सकती है और पुष्टि के बारे में अपनी पसंद के मुताबिक दावे कर सकती है. डिवाइस बनाने वाली कंपनी के दस्तावेज़ देखें. ध्यान दें कि इस लेख के समय तक Google को इस बात की जानकारी नहीं है कि डिवाइस बनाने वाली किस कंपनी ने ऐसा किया है.

सर्टिफ़िकेट निरस्त होने की स्थिति की सूची

पुष्टि करने वाली कुंजियों को कई वजहों से रद्द किया जा सकता है. इनमें, गलत तरीके से इस्तेमाल करना या किसी हमलावर के पास उनका ऐक्सेस होने का संदेह होना शामिल है. इसलिए, यह ज़रूरी है कि पुष्टि की चेन में मौजूद हर सर्टिफ़िकेट की स्थिति की जांच, सर्टिफ़िकेट रद्द करने की आधिकारिक स्थिति सूची (सीआरएल) के हिसाब से की जाए. इस सूची को Google मैनेज करता है और इसे यहां पब्लिश किया जाता है: https://android.googleapis.com/attestation/status. एचटीटीपी रिस्पॉन्स में मौजूद Cache-Control हेडर से यह तय होता है कि अपडेट की जांच कितनी बार करनी है, ताकि पुष्टि किए जा रहे हर सर्टिफ़िकेट के लिए नेटवर्क अनुरोध की ज़रूरत न पड़े. यह यूआरएल, एक JSON फ़ाइल दिखाता है. इसमें उन सभी सर्टिफ़िकेट का रद्द करने का स्टेटस होता है जिनका सामान्य मान्य स्टेटस नहीं है. JSON फ़ाइल का फ़ॉर्मैट, JSON स्कीमा (ड्राफ़्ट 07) की इस परिभाषा के मुताबिक होना चाहिए:

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
    "entries": {
      "description" : "Each entry represents the status of an attestation key. The dictionary-key is the certificate serial number in lowercase hex.",
      "type": "object",
      "propertyNames": {
        "pattern": "^[a-f1-9][a-f0-9]*$"
      },
      "additionalProperties": {
        "type": "object",
        "properties": {
          "status": {
            "description": "[REQUIRED] Current status of the key.",
            "type": "string",
            "enum": ["REVOKED", "SUSPENDED"]
          },
          "expires": {
            "description": "[OPTIONAL] UTC date when certificate expires in ISO8601 format (YYYY-MM-DD). Can be used to clear expired certificates from the status list.",
            "type": "string",
            "format": "date"
          },
          "reason": {
            "description": "[OPTIONAL] Reason for the current status.",
            "type": "string",
            "enum": ["UNSPECIFIED", "KEY_COMPROMISE", "CA_COMPROMISE", "SUPERSEDED", "SOFTWARE_FLAW"]
          },
          "comment": {
            "description": "[OPTIONAL] Free form comment about the key status.",
            "type": "string",
            "maxLength": 140
          }
        },
        "required": ["status"],
        "additionalProperties": false
      }
    }
  },
  "required": ["entries"],
  "additionalProperties": false
}

सीआरएल का उदाहरण:

{
  "entries": {
    "2c8cdddfd5e03bfc": {
      "status": "REVOKED",
      "expires": "2020-11-13",
      "reason": "KEY_COMPROMISE",
      "comment": "Key stored on unsecure system"
    },
    "c8966fcb2fbb0d7a": {
      "status": "SUSPENDED",
      "reason": "SOFTWARE_FLAW",
      "comment": "Bug in keystore causes this key malfunction b/555555"
    }
  }
}

कुंजी की पुष्टि करने वाले एक्सटेंशन का डेटा स्कीमा

कुंजी की पुष्टि करने वाले एक्सटेंशन का ओआईडी 1.3.6.1.4.1.11129.2.1.17 है. एक्सटेंशन, जानकारी को ASN.1 स्कीमा के मुताबिक सेव करता है.

यहां दी गई सूची में, स्कीमा में मौजूद हर एलिमेंट के बारे में जानकारी दी गई है:

मुख्य जानकारी

वैल्यू का यह क्रम, पासकोड की पुष्टि करने के लिए इस्तेमाल किए जा रहे पासकोड पेयर के बारे में सामान्य जानकारी देता है. साथ ही, ज़्यादा जानकारी को आसानी से ऐक्सेस करने की सुविधा भी देता है.

attestationVersion

कुंजी को प्रमाणित करने की सुविधा का वर्शन.

वैल्यू	वर्शन
1	Keymaster का वर्शन 2.0
2	Keymaster का वर्शन 3.0
3	कीमास्टर वर्शन 4.0
4	कीमास्टर वर्शन 4.1
100	KeyMint का वर्शन 1.0
200	KeyMint का वर्शन 2.0
300	KeyMint का वर्शन 3.0

attestationSecurityLevel

पुष्टि का सुरक्षा लेवल.

चेतावनी: Android सिस्टम में सेव की गई कुंजियों की पुष्टि की जा सकती है. इसका मतलब है कि अगर attestationSecurityLevel की वैल्यू 'सॉफ़्टवेयर' पर सेट है, तो Android सिस्टम में सेव की गई कुंजियों की पुष्टि की जा सकती है. हालांकि, अगर Android सिस्टम हैक हो जाता है, तो इन पुष्टिओं पर भरोसा नहीं किया जा सकता.

keymasterVersion / keyMintVersion

Keymaster या KeyMint हार्डवेयर ऐब्स्ट्रैक्शन लेयर (एचएएल) का वर्शन.

वैल्यू	वर्शन
0	Keymaster का वर्शन 0.2 या 0.3
1	कीमास्टर वर्शन 1.0
2	Keymaster का वर्शन 2.0
3	Keymaster का वर्शन 3.0
4	Keymaster का वर्शन 4.0
41	कीमास्टर वर्शन 4.1
100	KeyMint का वर्शन 1.0
200	KeyMint का वर्शन 2.0
300	KeyMint का वर्शन 3.0

keymasterSecurityLevel / keyMintSecurityLevel

Keymaster/KeyMint को लागू करने का सुरक्षा स्तर.

attestationChallenge

इसमें वह चैलेंज शामिल होता है जो पासकोड बनाने के समय दिया गया था. देखें कि यह वैल्यू, अनुमति वाले टैग में सेव की गई वैल्यू से मैच करती है या नहीं. ऐसा न करने पर, आपकी सेवा पर, पुष्टि करने वाले पुराने सर्टिफ़िकेट फिर से इस्तेमाल किए जा सकते हैं.

uniqueId

यह वैल्यू, डिवाइस की पहचान करती है—हालांकि, सिर्फ़ कुछ समय के लिए. इसे कंप्यूट किया गया है और इसका इस्तेमाल सिर्फ़ सिस्टम ऐप्लिकेशन में किया जाता है. अन्य सभी ऐप्लिकेशन में, uniqueId खाली होता है.

softwareEnforced

ज़रूरी नहीं. Keymaster / KeyMint की अनुमति वाली सूची, जिसे डिवाइस के ट्रस्टेड एक्ज़ीक्यूशन एनवायरमेंट (टीईई) के बजाय, Android सिस्टम लागू करता है. अनुमति वाली इस सूची में मौजूद जानकारी, उस कोड से इकट्ठा या जनरेट की जाती है जो प्लैटफ़ॉर्म का हिस्सा है और जिसे डिवाइस के सिस्टम पार्टिशन में सेव किया जाता है. अनुमति वाली इस सूची के कॉन्टेंट पर तब तक भरोसा किया जा सकता है, जब तक डिवाइस पर ऐसा ऑपरेटिंग सिस्टम काम कर रहा हो जो Android Platform Security Model के मुताबिक हो. सर्टिफ़ाइड सभी Android डिवाइस, इस सुरक्षा मॉडल का पालन करते हैं. इसलिए, अगर डिवाइस लॉक है और पुष्टि किए गए बूट की स्थिति Verified है, तो यहां दी गई वैल्यू भरोसेमंद होनी चाहिए. बदलाव किए गए डिवाइस पर, बूटलोडर अनलॉक होने पर उपयोगकर्ता ऐसा ऑपरेटिंग सिस्टम इंस्टॉल कर सकता है जो Android प्लैटफ़ॉर्म के सुरक्षा मॉडल के मुताबिक न हो. इसलिए, हो सकता है कि उपयोगकर्ता इस फ़ील्ड में अपनी पसंद के मुताबिक वैल्यू चुन ले.

hardwareEnforced

ज़रूरी नहीं. Keymaster / KeyMint की अनुमति वाली सूची, जिसे डिवाइस के ट्रस्टेड एक्ज़ीक्यूशन एनवायरमेंट (टीईई) से लागू किया जाता है. अनुमति की इस सूची में मौजूद जानकारी को कोड से इकट्ठा या जनरेट किया जाता है. यह कोड, सुरक्षित हार्डवेयर का हिस्सा होता है और इसे प्लैटफ़ॉर्म कंट्रोल नहीं करता. उदाहरण के लिए, अनुमति वाली इस सूची में दी गई जानकारी, डिवाइस के बूटलोडर या डिवाइस पर चल रहे TEE से मिलती है. अनुमति वाली इस सूची में जिन फ़ील्ड को सीधे KeyMint से सेट नहीं किया गया है उन्हें सुरक्षित हार्डवेयर के अन्य हिस्सों (उदाहरण के लिए, बूटलोडर) से ऐसे सुरक्षित कम्यूनिकेशन चैनलों के ज़रिए उपलब्ध कराया जाता है जिन्हें प्लैटफ़ॉर्म पर भरोसा नहीं है. सुरक्षित हार्डवेयर और Android सिस्टम के बीच का अंतर यह है कि उपयोगकर्ता, सुरक्षित हार्डवेयर (फ़र्मवेयर) में चल रहे कोड में बदलाव नहीं कर सकता. इसलिए, उपयोगकर्ता अनुमति की इस सूची में मौजूद वैल्यू को बदल नहीं सकता.

SecurityLevel

इस डेटा स्ट्रक्चर से पता चलता है कि डिवाइस में किसी जगह पर मौजूद, कुंजी जोड़ी जैसी सॉफ़्टवेयर सुविधा को कितनी सुरक्षा दी गई है.

डेटा स्ट्रक्चर एक एनोटेशन है, इसलिए यह इनमें से कोई एक वैल्यू लेता है:

कीस्टोर: सुविधा को बनाने और मैनेज करने का लॉजिक, Android सिस्टम में लागू किया जाता है. पासकोड बनाने और सेव करने के लिए, यह जगह TEE की तुलना में कम सुरक्षित है. हालांकि, यह आपके ऐप्लिकेशन के प्रोसेस स्पेस से ज़्यादा सुरक्षित है.
TrustedEnvironment: इस सुविधा को बनाने और मैनेज करने का लॉजिक, टीईई जैसे सुरक्षित हार्डवेयर में लागू किया जाता है. कुंजी के जोड़े बनाने और सेव करने के लिए, जगह की यह जानकारी ज़्यादा सुरक्षित होती है, क्योंकि सुरक्षित हार्डवेयर में कहीं से भी छेड़छाड़ किए जाने का कोई खतरा नहीं होता.
StrongBox: इस सुविधा को बनाने और मैनेज करने का लॉजिक, खास हार्डवेयर सिक्योरिटी मॉड्यूल में लागू किया जाता है. कुंजी के जोड़े बनाने और उन्हें सेव करने के लिए, यह जगह ज़्यादा सुरक्षित है. ऐसा इसलिए है, क्योंकि यह मॉड्यूल के लिए, रिमोट से किए जाने वाले हमले और हार्डवेयर हमले से ज़्यादा सुरक्षित है.
सॉफ़्टवेयर: इस सुविधा को बनाने और मैनेज करने का लॉजिक, KeyMint या Keymaster के ऐसे वर्शन में लागू किया गया है जो सुरक्षित प्लैटफ़ॉर्म पर नहीं चलता. पासकोड जोड़े बनाने और उन्हें सेव करने के लिए, यह जगह TEE की तुलना में कम सुरक्षित है. हालांकि, यह आपके ऐप्लिकेशन के प्रोसेस स्पेस से ज़्यादा सुरक्षित है.

AuthorizationList

इस डेटा स्ट्रक्चर में, की-पेयर की प्रॉपर्टी होती हैं, जैसा कि Keymaster या KeyMint हार्डवेयर एब्स्ट्रैक्शन लेयर (एचएएल) में बताया गया है. इन वैल्यू की तुलना, डिवाइस की मौजूदा स्थिति या उम्मीद की जाने वाली वैल्यू के सेट से की जाती है. इससे यह पुष्टि की जाती है कि आपके ऐप्लिकेशन में इस्तेमाल करने के लिए, कुंजी का जोड़ा अब भी मान्य है या नहीं.

हर फ़ील्ड का नाम, इसी नाम वाले Keymaster / KeyMint अनुमति टैग से मेल खाता है. उदाहरण के लिए, अनुमति सूची में मौजूद keySize फ़ील्ड, Tag::KEY_SIZE अनुमति टैग से जुड़ा होता है.

AIDL इंटरफ़ेस स्पेसिफ़िकेशन में, अनुमति टैग के बारे में पूरी जानकारी होती है. इससे हर टैग के आईडी की वैल्यू और उसके टाइप के बारे में पता चलता है. साथ ही, यह भी पता चलता है कि हर टैग को hardwareEnforced की अनुमति देने वाली सूची (यह बताता है कि टैग को सुरक्षित एनवायरमेंट में लागू किया गया है) या softwareEnforced की अनुमति देने वाली सूची में मौजूद होने की उम्मीद है या नहीं. इससे यह पता चलता है कि टैग को Android ने लागू किया है, आम तौर पर कीस्टोर.

नीचे दी गई सूची में मौजूद हर फ़ील्ड को भरना ज़रूरी नहीं है:

purpose

यह Tag::PURPOSE अनुमति टैग से मेल खाता है. यह टैग आईडी की वैल्यू 1 का इस्तेमाल करता है.

algorithm

Tag::ALGORITHM ऑथराइज़ेशन टैग से मेल खाता है. इस टैग में, टैग आईडी की वैल्यू दो होती है.

पुष्टि करने वाले AuthorizationList ऑब्जेक्ट में, एल्गोरिदम की वैल्यू हमेशा RSA या EC होती है.

keySize

यह अनुमति देने वाले Tag::KEY_SIZE टैग से जुड़ा है. यह टैग, 3 वाली टैग आईडी वैल्यू का इस्तेमाल करता है.

digest

यह Tag::DIGEST अनुमति टैग से जुड़ा है. यह टैग, 5 की टैग आईडी वैल्यू का इस्तेमाल करता है.

padding

यह अनुमति देने वाले Tag::PADDING टैग से जुड़ा है. यह टैग, 6 की टैग आईडी वैल्यू का इस्तेमाल करता है.

ecCurve

यह Tag::EC_CURVE अनुमति टैग से जुड़ा है, जो 10 की टैग आईडी वैल्यू का इस्तेमाल करता है.

पैरामीटर का सेट, जिसका इस्तेमाल एलिप्टिक कर्व (ईसी) कुंजी का जोड़ा जनरेट करने के लिए किया जाता है. यह Android सिस्टम के पासकोड में, हस्ताक्षर करने और पुष्टि करने के लिए ईसीएसडीए का इस्तेमाल करता है.

rsaPublicExponent

यह Tag::RSA_PUBLIC_EXPONENT अनुमति टैग से जुड़ा है. यह टैग, 200 की टैग आईडी वैल्यू का इस्तेमाल करता है.

mgfDigest

यह एट्रिब्यूट सिर्फ़ ऐसे एटेस्टेशन वर्शन में मौजूद होता है जो 100 या उससे ज़्यादा हो.

यह Tag::RSA_OAEP_MGF_DIGEST KeyMint अनुमति टैग से जुड़ा है, जो टैग आईडी की वैल्यू 203 का इस्तेमाल करता है.

rollbackResistance

सिर्फ़ कुंजी को प्रमाणित करने वाले वर्शन >= 3 में प्रज़ेंट करें.

Tag::ROLLBACK_RESISTANT ऑथराइज़ेशन टैग से मेल खाता है, जिसमें 303 की टैग आईडी वैल्यू का इस्तेमाल किया जाता है.

earlyBootOnly

यह सिर्फ़ ऐसेट की पुष्टि करने वाले वर्शन 4 और उसके बाद के वर्शन में मौजूद है.

यह Tag::EARLY_BOOT_ONLY अनुमति टैग से जुड़ा है, जो 305 की टैग आईडी वैल्यू का इस्तेमाल करता है.

activeDateTime

यह Tag::ACTIVE_DATETIME अनुमति देने वाले टैग के मुताबिक है, जिसमें 400 की टैग आईडी वैल्यू का इस्तेमाल किया जाता है.

originationExpireDateTime

Tag::ORIGINATION_EXPIRE_DATETIME Keymaster अनुमति टैग से मेल खाता है. यह टैग आईडी की वैल्यू 401 का इस्तेमाल करता है.

usageExpireDateTime

यह अनुमति वाले टैग के लिए है, जो Tag::USAGE_EXPIRE_DATETIME के बराबर है. यह टैग, 402 की टैग आईडी वैल्यू का इस्तेमाल करता है.

usageCountLimit

Tag::USAGE_COUNT_LIMIT अनुमति टैग से मेल खाता है, जो टैग आईडी की वैल्यू 405 का इस्तेमाल करता है.

noAuthRequired

यह अनुमति वाले Tag::NO_AUTH_REQUIRED टैग से जुड़ा है, जो टैग आईडी की वैल्यू 503 का इस्तेमाल करता है.

userAuthType

यह Tag::USER_AUTH_TYPE अनुमति देने वाले टैग के मुताबिक है, जिसमें 504 की टैग आईडी वैल्यू का इस्तेमाल किया जाता है.

authTimeout

अनुमति देने वाले टैग के लिए है, जो Tag::AUTH_TIMEOUT टैग आईडी की वैल्यू 505 का इस्तेमाल करता है.

allowWhileOnBody

यह Tag::ALLOW_WHILE_ON_BODY अनुमति टैग से जुड़ा है, जो टैग आईडी की वैल्यू 506 का इस्तेमाल करता है.

अगर उपयोगकर्ता ने अब भी अपने शरीर पर डिवाइस पहना हुआ है, तो पुष्टि करने का समय खत्म होने के बाद कुंजी का इस्तेमाल करने की अनुमति देता है. ध्यान दें कि सुरक्षित तौर पर पहने जाने वाला सेंसर यह तय करता है कि डिवाइस, उपयोगकर्ता के शरीर पर पहना जा रहा है या नहीं.

trustedUserPresenceRequired

सिर्फ़ कुंजी को प्रमाणित करने वाले वर्शन >= 3 में प्रज़ेंट करें.

Tag::TRUSTED_USER_PRESENCE_REQUIRED ऑथराइज़ेशन टैग से मेल खाता है, जिसमें 507 की टैग आईडी वैल्यू का इस्तेमाल किया जाता है.

इससे पता चलता है कि इस पासकोड का इस्तेमाल सिर्फ़ तब किया जा सकता है, जब उपयोगकर्ता ने अपनी मौजूदगी का सबूत दिया हो. इसके कुछ उदाहरण यहां दिए गए हैं:

StrongBox पासकोड के लिए, हार्डवेयर बटन, जो StrongBox डिवाइस पर पिन से कनेक्ट होता है.
टीईई पासकोड के लिए, फ़िंगरप्रिंट की मदद से पुष्टि करने की सुविधा से, डिवाइस के इस्तेमाल में होने की पुष्टि होती है. ऐसा तब तक होता है, जब तक टीईई के पास स्कैनर का पूरा कंट्रोल होता है और वह फ़िंगरप्रिंट मैच करने की प्रोसेस करता है.

trustedConfirmationRequired

यह सिर्फ़ ऐसेट की पुष्टि करने वाले वर्शन 3 और उसके बाद के वर्शन में मौजूद है.

यह Tag::TRUSTED_CONFIRMATION_REQUIRED authorization टैग से जुड़ा है, जो टैग आईडी की वैल्यू 508 का इस्तेमाल करता है.

इससे पता चलता है कि पासकोड का इस्तेमाल सिर्फ़ तब किया जा सकता है, जब उपयोगकर्ता अनुमति वाले टोकन का इस्तेमाल करके, उस डेटा की पुष्टि करता है जिस पर हस्ताक्षर करना है. उपयोगकर्ता की पुष्टि करने के तरीके के बारे में ज़्यादा जानने के लिए, Android पर सुरक्षित पुष्टि देखें.

ध्यान दें: यह टैग सिर्फ़ उन बटन पर लागू होता है जो SIGN के मकसद के लिए इस्तेमाल किए जाते हैं.

unlockedDeviceRequired

यह सिर्फ़ ऐसेट की पुष्टि करने वाले वर्शन 3 और उसके बाद के वर्शन में मौजूद है.

यह Tag::UNLOCKED_DEVICE_REQUIRED अनुमति टैग से जुड़ा है, जो टैग आईडी की वैल्यू 509 का इस्तेमाल करता है.

allApplications

Tag::ALL_APPLICATIONS ऑथराइज़ेशन टैग से मेल खाता है. इस टैग में, 600 की टैग आईडी वैल्यू का इस्तेमाल किया जाता है.

इससे पता चलता है कि किसी डिवाइस पर मौजूद सभी ऐप्लिकेशन, पासकोड जोड़े को ऐक्सेस कर सकते हैं या नहीं.

applicationId

यह Tag::APPLICATION_ID अनुमति देने वाले टैग के मुताबिक है, जिसमें 601 की टैग आईडी वैल्यू का इस्तेमाल किया जाता है.

creationDateTime

यह Tag::CREATION_DATETIME अनुमति टैग से जुड़ा है. यह टैग, 701 की टैग आईडी वैल्यू का इस्तेमाल करता है.

origin

Tag::ORIGIN ऑथराइज़ेशन टैग से मेल खाता है, जिसमें 702 टैग आईडी की वैल्यू का इस्तेमाल किया जाता है.

rollbackResistant

यह सिर्फ़ एटेस्टेशन पासकोड के वर्शन 1 और 2 में मौजूद है.

यह Tag::ROLLBACK_RESISTANT अनुमति टैग से जुड़ा है, जो 703 की टैग आईडी वैल्यू का इस्तेमाल करता है.

rootOfTrust

Tag::ROOT_OF_TRUST ऑथराइज़ेशन टैग के मुताबिक है, जिसमें 704 की टैग आईडी वैल्यू का इस्तेमाल किया जाता है.

ज़्यादा जानकारी के लिए, RootOfTrust डेटा स्ट्रक्चर के बारे में बताने वाला सेक्शन देखें.

osVersion

यह अनुमति देने वाले Tag::OS_VERSION टैग से जुड़ा है. यह टैग, 705 की टैग आईडी वैल्यू का इस्तेमाल करता है.

Keymaster से जुड़े Android ऑपरेटिंग सिस्टम का वर्शन, जो छह अंकों के पूर्णांक के तौर पर दिया गया है. उदाहरण के लिए, वर्शन 8.1.0 को 080100 के तौर पर दिखाया जाता है.

अनुमति सूची में यह मान सिर्फ़ कीमास्टर वर्शन 1.0 या उसके बाद वाले वर्शन को ही शामिल किया जाता है.

osPatchLevel

Tag::PATCHLEVEL ऑथराइज़ेशन टैग से मेल खाता है. इस टैग में, 706 की टैग आईडी वैल्यू का इस्तेमाल किया जाता है.

KeyMaster में इस्तेमाल किए जा रहे सुरक्षा पैच से जुड़ा महीना और साल. इसे छह अंकों वाले पूर्णांक के तौर पर दिखाया जाता है. उदाहरण के लिए, अगस्त 2018 के पैच को 201808 के तौर पर दिखाया जाता है.

सिर्फ़ Keymaster वर्शन 1.0 या इसके बाद के वर्शन में, अनुमति की सूची में यह वैल्यू शामिल होती है.

attestationApplicationId

यह सिर्फ़ ऐसेट की पुष्टि करने वाले वर्शन 2 और उसके बाद के वर्शन में मौजूद है.

यह Tag::ATTESTATION_APPLICATION_ID Keymaster अनुमति टैग से जुड़ा है. इस टैग में, टैग आईडी की वैल्यू 709 का इस्तेमाल किया जाता है.

ज़्यादा जानकारी के लिए, AttestationApplicationId के डेटा स्ट्रक्चर के बारे में बताने वाला सेक्शन देखें.

attestationIdBrand

सिर्फ़ कुंजी को प्रमाणित करने वाले वर्शन >= 2 में प्रज़ेंट करें.

यह Tag::ATTESTATION_ID_BRAND Keymaster टैग से जुड़ा है, जो 710 की टैग आईडी वैल्यू का इस्तेमाल करता है.

attestationIdDevice

यह सिर्फ़ ऐसेट की पुष्टि करने वाले वर्शन 2 और उसके बाद के वर्शन में मौजूद है.

यह Tag::ATTESTATION_ID_DEVICE Keymaster टैग से जुड़ा है, जो 711 की टैग आईडी वैल्यू का इस्तेमाल करता है.

attestationIdProduct

यह सिर्फ़ ऐसेट की पुष्टि करने वाले वर्शन 2 और उसके बाद के वर्शन में मौजूद है.

Tag::ATTESTATION_ID_PRODUCT के-मास्टर टैग से मेल खाता है. इस टैग में, टैग आईडी की वैल्यू 712 होती है.

attestationIdSerial

यह सिर्फ़ ऐसेट की पुष्टि करने वाले वर्शन 2 और उसके बाद के वर्शन में मौजूद है.

यह Tag::ATTESTATION_ID_SERIAL Keymaster टैग से जुड़ा है, जो 713 की टैग आईडी वैल्यू का इस्तेमाल करता है.

attestationIdImei

यह सिर्फ़ ऐसेट की पुष्टि करने वाले वर्शन 2 और उसके बाद के वर्शन में मौजूद है.

Tag::ATTESTATION_ID_IMEI ऑथराइज़ेशन टैग से मेल खाता है. इस टैग में, टैग आईडी की वैल्यू 714 है.

attestationIdMeid

यह सिर्फ़ ऐसेट की पुष्टि करने वाले वर्शन 2 और उसके बाद के वर्शन में मौजूद है.

यह Tag::ATTESTATION_ID_MEID अनुमति टैग से जुड़ा है, जो 715 की टैग आईडी वैल्यू का इस्तेमाल करता है.

attestationIdManufacturer

यह सिर्फ़ ऐसेट की पुष्टि करने वाले वर्शन 2 और उसके बाद के वर्शन में मौजूद है.

यह Tag::ATTESTATION_ID_MANUFACTURER अनुमति वाले टैग से जुड़ा है, जो 716 की टैग आईडी वैल्यू का इस्तेमाल करता है.

attestationIdModel

यह सिर्फ़ ऐसेट की पुष्टि करने वाले वर्शन 2 और उसके बाद के वर्शन में मौजूद है.

Tag::ATTESTATION_ID_MODEL ऑथराइज़ेशन टैग से मेल खाता है, जिसमें टैग आईडी की वैल्यू 717 है.

vendorPatchLevel

यह सिर्फ़ ऐसेट की पुष्टि करने वाले वर्शन 3 और उसके बाद के वर्शन में मौजूद है.

यह Tag::VENDOR_PATCHLEVEL अनुमति टैग से जुड़ा है, जो टैग आईडी की वैल्यू 718 का इस्तेमाल करता है.

इससे वेंडर इमेज के सुरक्षा पैच लेवल की जानकारी मिलती है. इस कुंजी का इस्तेमाल करने के लिए, यह लेवल डिवाइस पर इंस्टॉल होना चाहिए. वैल्यू, YYYYMMDD फ़ॉर्मैट में दिखती है. इससे वेंडर के सुरक्षा पैच की तारीख का पता चलता है. उदाहरण के लिए, अगर किसी Android डिवाइस पर 1 अगस्त, 2018 को वेंडर का सुरक्षा पैच इंस्टॉल होने के बाद कुंजी जनरेट की गई थी, तो यह वैल्यू 20180801 होगी.

bootPatchLevel

यह सिर्फ़ ऐसेट की पुष्टि करने वाले वर्शन 3 और उसके बाद के वर्शन में मौजूद है.

यह Tag::BOOT_PATCHLEVEL अनुमति टैग से जुड़ा है, जो टैग आईडी की वैल्यू 719 का इस्तेमाल करता है.

इस कुंजी का इस्तेमाल करने के लिए, डिवाइस पर कर्नल इमेज का वह सुरक्षा पैच लेवल होना चाहिए जिसकी जानकारी इस एट्रिब्यूट में दी गई है. वैल्यू YYYYMMDD फ़ॉर्मैट में दिखती है. इससे सिस्टम के सुरक्षा पैच की तारीख का पता चलता है. उदाहरण के लिए, अगर कोई कुंजी ऐसे Android डिवाइस पर जनरेट की गई थी जिसमें सिस्टम का 5 अगस्त, 2018 का सुरक्षा पैच इंस्टॉल है, तो यह वैल्यू 20180805 होगी.

deviceUniqueAttestation

यह एट्रिब्यूट सिर्फ़ ऐसेट की पुष्टि करने वाले वर्शन 4 और उसके बाद के वर्शन में मौजूद होता है.

Tag::DEVICE_UNIQUE_ATTESTATION ऑथराइज़ेशन टैग से मेल खाता है, जिसमें 720 की टैग आईडी वैल्यू का इस्तेमाल किया जाता है.

attestationIdSecondImei

यह सिर्फ़ 300 या उससे ज़्यादा वर्शन के एटेस्टेशन में मौजूद है.

यह Tag::ATTESTATION_ID_SECOND_IMEI अनुमति टैग से जुड़ा है, जो 723 की टैग आईडी वैल्यू का इस्तेमाल करता है.

RootOfTrust

वैल्यू के इस कलेक्शन से, डिवाइस की स्थिति के बारे में अहम जानकारी मिलती है.

यहां दी गई सूची में मौजूद हर फ़ील्ड को भरना ज़रूरी है:

verifiedBootKey

सिस्टम इमेज की पुष्टि करने वाली कुंजी का सुरक्षित हैश. हमारा सुझाव है कि इस हैश के लिए, SHA-256 एल्गोरिदम का इस्तेमाल करें.

deviceLocked

अगर डिवाइस का बूटलोडर लॉक है, तो यह विकल्प 'सही है' पर सेट होता है. इससे, पुष्टि किए गए बूट की जांच की सुविधा चालू होती है और डिवाइस पर बिना हस्ताक्षर वाली डिवाइस इमेज को फ़्लैश होने से रोका जाता है. इस सुविधा के बारे में ज़्यादा जानकारी के लिए, बूट की पुष्टि करने से जुड़ा दस्तावेज़ देखें.

verifiedBootState

वेरिफ़ाइड बूट की सुविधा के हिसाब से, डिवाइस के बूट की स्थिति.

verifiedBootHash

यह सिर्फ़ ऐसेट की पुष्टि करने वाले वर्शन 3 और उसके बाद के वर्शन में मौजूद है.

पुष्टि किए गए बूट की मदद से सुरक्षित किए गए सभी डेटा का डाइजेस्ट. पुष्टि किए गए बूट के Android Verified Boot लागू करने वाले डिवाइसों के लिए, इस वैल्यू में VBMeta स्ट्रक्चर या पुष्टि किए गए बूट के मेटाडेटा स्ट्रक्चर का डाइजेस्ट होता है.

इस वैल्यू का हिसाब लगाने के तरीके के बारे में ज़्यादा जानने के लिए, VBMeta डाइजेस्ट देखें.

VerifiedBootState

इस डेटा स्ट्रक्चर से, डिवाइस की मौजूदा बूट स्टेटस की जानकारी मिलती है. इससे यह पता चलता है कि डिवाइस के बूट होने के बाद, उपयोगकर्ता और ऐप्लिकेशन को कितनी सुरक्षा दी गई है. इस सुविधा के बारे में ज़्यादा जानने के लिए, बूट की पुष्टि करने से जुड़े दस्तावेज़ में, बूट की स्थिति सेक्शन देखें.

यह डेटा स्ट्रक्चर, एनोटेशन है. इसलिए, इसमें इनमें से कोई एक वैल्यू ही हो सकती है:

पुष्टि हो चुकी है

इससे पता चलता है कि सभी लोग भरोसेमंद हैं या नहीं. इनमें बूटलोडर, बूट वाला हिस्सा, और पुष्टि किए गए सभी हिस्से शामिल हैं.

जब डिवाइस इस बूट स्टेटस में होता है, तो verifiedBootKey डिवाइस में एम्बेड किए गए सर्टिफ़िकेट का हैश होता है. डिवाइस बनाने वाली कंपनी, फ़ैक्ट्री में डिवाइस के आरओम में यह हैश जोड़ती है.

SelfSigned

इससे पता चलता है कि डिवाइस में जोड़े गए सर्टिफ़िकेट ने डिवाइस के बूट पार्टीशन की पुष्टि की है और हस्ताक्षर मान्य है.

जब डिवाइस इस बूट स्थिति में होता है, तो verifiedBootKey उपयोगकर्ता के इंस्टॉल किए गए प्रमाणपत्र का हैश होता है. यह बूट विभाजन को दर्शाता है जिसे उपयोगकर्ता डिवाइस में निर्माता के दिए गए बूट विभाजन की जगह पर जोड़ता है.

पुष्टि नहीं हुई है

इससे पता चलता है कि उपयोगकर्ता डिवाइस में अपने हिसाब से बदलाव कर सकता है. इसलिए, डिवाइस की सुरक्षा की पुष्टि करने की ज़िम्मेदारी उपयोगकर्ता की है.

काम नहीं हुआ

इससे पता चलता है कि डिवाइस की पुष्टि नहीं हो सकी. पुष्टि करने वाले सर्टिफ़िकेट में, VerifiedBootState के लिए कभी भी इस वैल्यू का इस्तेमाल नहीं किया जाना चाहिए.

AttestationApplicationId

इस डेटा स्ट्रक्चर से पता चलता है कि Android प्लैटफ़ॉर्म के हिसाब से, किन ऐप्लिकेशन को पुष्टि के तहत गुप्त कुंजी के कॉन्टेंट का इस्तेमाल करने की अनुमति है. आईडी में एक से ज़्यादा पैकेज शामिल हो सकते हैं. हालांकि, ऐसा सिर्फ़ तब होगा, जब एक से ज़्यादा पैकेज एक ही यूआईडी शेयर करते हों. ऑक्टेट स्ट्रिंग को नीचे दिए गए ASN.1 के हिसाब से फ़ॉर्मैट किया जाता है स्कीमा:

AttestationApplicationId ::= SEQUENCE {
    package_infos  SET OF AttestationPackageInfo,
    signature_digests  SET OF OCTET_STRING,
}

AttestationPackageInfo ::= SEQUENCE {
    package_name  OCTET_STRING,
    version  INTEGER,
}

पैकेज की जानकारी

AttestationPackageInfo ऑब्जेक्ट का एक सेट, जिसमें हर ऑब्जेक्ट में पैकेज का नाम और वर्शन नंबर होता है.

signature_digests

ऐप्लिकेशन के साइनिंग सर्टिफ़िकेट के SHA-256 डाइजेस्ट का सेट. किसी ऐप्लिकेशन में, साइनिंग पासकोड के कई सर्टिफ़िकेट चेन हो सकती हैं. हर एक के लिए, "लीफ़" सर्टिफ़िकेट को इकट्ठा किया जाता है और signature_digests फ़ील्ड में डाला जाता है. फ़ील्ड का नाम गुमराह करने वाला है, क्योंकि डाइजेस्ट किया गया डेटा, ऐप्लिकेशन के साइनिंग सर्टिफ़िकेट होता है, न कि ऐप्लिकेशन के हस्ताक्षर. ऐसा इसलिए है, क्योंकि इसका नाम getPackageInfo() को कॉल करने पर मिलने वाली Signature क्लास के लिए रखा गया है. यहां दिया गया कोड स्निपेट, उदाहरण के तौर पर सेट किया गया है:

{SHA256(PackageInfo.signature[0]), SHA256(PackageInfo.signature[1]), ...}

प्रोवाइज़न करने की जानकारी वाले एक्सटेंशन का डेटा स्कीमा

प्रावधान की जानकारी वाले एक्सटेंशन का OID 1.3.6.1.4.1.11129.2.1.30 है. यह एक्सटेंशन, डिवाइस के बारे में वह जानकारी देता है जो डिवाइस को सेट अप करने वाले सर्वर के पास होती है. यह एक्सटेंशन, सीडीएल स्कीमा का पालन करता है.

  {
        1 : int,   ; certificates issued
  }

मैप का वर्शन नहीं बदला गया है और नए वैकल्पिक फ़ील्ड जोड़े जा सकते हैं.

certs_issued: पिछले 30 दिनों में डिवाइस को जारी किए गए सर्टिफ़िकेट की अनुमानित संख्या. अगर वैल्यू, औसत से काफ़ी ज़्यादा है, तो इस वैल्यू का इस्तेमाल संभावित गलत इस्तेमाल के सिग्नल के तौर पर किया जा सकता है.