जर्मनी का eIDAS इलेक्ट्रॉनिक पहचान वॉलेट, Apple·Google अकाउंट-आधारित डिवाइस सुरक्षा सत्यापन संरचना

 (bmi.usercontent.opencode.de)
1 पॉइंट द्वारा GN⁺ 26 일 전 | अभी कोई टिप्पणी नहीं है. | WhatsApp पर शेयर करें
  • जर्मनी का National EUDI Wallet मोबाइल डिवाइस की सुरक्षा भेद्यता प्रबंधन (MDVM) व्यवस्था के जरिए इलेक्ट्रॉनिक पहचान प्रमाणीकरण की अखंडता बनाए रखता है
  • MDVM ऑपरेटिंग सिस्टम और हार्डवेयर key store (HKS) की भेद्यताओं का पता लगाता है, और जोखिम अधिक होने पर प्रमाणीकरण key के उपयोग को ब्लॉक कर देता है
  • Android में Google Play Integrity API और KeyAttestation, तथा iOS में Apple DeviceCheck·AppAttest का उपयोग कर डिवाइस अखंडता सत्यापित की जाती है
  • इस संरचना के कारण इलेक्ट्रॉनिक पहचान फीचर का उपयोग करते समय Apple या Google अकाउंट-आधारित सत्यापन प्रक्रिया अनिवार्य रूप से चलती है
  • पूरे सिस्टम को हमलावरों द्वारा key की नकल·दुरुपयोग रोकने और उच्च आश्वासन स्तर वाले eID प्रमाणीकरण को बनाए रखने के उद्देश्य से डिज़ाइन किया गया है

मोबाइल डिवाइस भेद्यता प्रबंधन की अवधारणा (Mobile Device Vulnerability Management, MDVM)

  • MDVM जर्मनी के National EUDI Wallet आर्किटेक्चर के भीतर एक ऐसी व्यवस्था है जो उपयोगकर्ता डिवाइस की सुरक्षा भेद्यताओं की लगातार निगरानी करती है और प्रमाणीकरण साधनों की अखंडता बनाए रखती है
  • HKS(हार्डवेयर key store) और ऑपरेटिंग सिस्टम(OS) की ज्ञात भेद्यताओं का पता लगाकर, उच्च हमले-जोखिम की स्थिति में RWSCA/RWSCD key के उपयोग को ब्लॉक किया जाता है
  • इसके माध्यम से इलेक्ट्रॉनिक पहचान सत्यापन(eID) प्रक्रिया में उच्च आश्वासन स्तर बनाए रखा जाता है, और हमलावरों द्वारा key की नकल·दुरुपयोग को रोका जाता है
  • MDVM चार कार्यों से बना है: डिवाइस और ऐप की सुरक्षा स्थिति सत्यापन, डिवाइस class की पहचान, भेद्यता सत्यापन, और उपयोग-निर्णय

प्रेरणा

  • Wallet Unit public/private key pair के जरिए कई पहचान साधनों(PID आदि) से जुड़ा प्रमाणीकरण साधन प्रदान करता है
  • PID जारी करते समय WB(Wallet Backend), PP(Provider Party) के लिए यह OpenID4VCI Key Attestation के माध्यम से सत्यापित करता है कि संबंधित key एक निश्चित स्तर के attack resistance वाले प्रमाणीकरण साधन द्वारा नियंत्रित है
  • ISO/IEC 18045 और EU विनियमन 2015/1502 के अनुसार, उच्च आश्वासन स्तर वाली इलेक्ट्रॉनिक पहचान सत्यापन के लिए मजबूत प्रमाणीकरण साधन आवश्यक हैं
  • प्रमाणीकरण साधन दो प्रकार की assurance प्रदान करता है
    1. key store की नकल और छेड़छाड़ से सुरक्षा
    2. उपयोगकर्ता प्रमाणीकरण तंत्र पर हमलों से सुरक्षा
  • पहली assurance को HSM-आधारित RWSCD से लागू किया जा सकता है, और यह उपयोगकर्ता डिवाइस से स्वतंत्र रूप से हासिल की जा सकती है
  • दूसरी assurance उपयोगकर्ता डिवाइस की सुरक्षा पर निर्भर करती है, और इसमें possession factor(HKS-आधारित) तथा knowledge factor(पासवर्ड आदि) शामिल हैं
  • मोबाइल डिवाइस के HKS या OS का पूर्व-भेद्यता विश्लेषण·प्रमाणीकरण व्यावहारिक रूप से संभव नहीं है, और पहले भी अनेक भेद्यताएँ रिपोर्ट की जा चुकी हैं
  • इसलिए संचालन के दौरान भेद्यता निगरानी व्यवस्था(MDVM) के जरिए हमले की संभावना घटाई जाती है, और अपर्याप्त सुरक्षा वाले डिवाइस पर RWSCA/RWSCD key के उपयोग को ब्लॉक किया जाता है

MDVM के प्रमुख कार्य

कार्य विवरण
डिवाइस/ऐप सुरक्षा स्थिति सत्यापन डिवाइस और Wallet ऐप की अखंडता और प्रामाणिकता सत्यापित करता है, तथा प्लेटफ़ॉर्म सुरक्षा सुविधाओं और RASP(Runtime Application Self-Protection) का उपयोग करता है
डिवाइस class की पहचान डिवाइस मॉडल, OS version और patch level, HKS जानकारी को सत्यापित तरीके से पहचानता है
डिवाइस class-वार भेद्यता सत्यापन OS और HKS की नवीनतम भेद्यता जानकारी की जांच करता है
डिवाइस/ऐप उपयोग निर्णय सुरक्षा स्थिति और भेद्यता जानकारी के आधार पर, अपर्याप्त सुरक्षा वाले डिवाइस में OpenID4VCI Key Attestation सत्यापन तथा RWSCD key उपयोग को ब्लॉक करता है

एकत्रित signals

  • एकत्रित signals का उपयोग threat response, डिवाइस class पहचान, और plausibility check में किया जाता है

  • मुख्य signal स्रोत: KeyAttestation, PlayIntegrity, DeviceCheck, RASP, LPADB, DCVDB

  • अवलोकन

    signal स्रोत संबोधित खतरे synergy टिप्पणी
    KeyAttestation rooting, bootloader unlock, custom ROM, ऐप छेड़छाड़, cloning, emulation, replay attack आदि LPADB, RASP DCVDB input के रूप में उपयोग
    PlayIntegrity ऐप छेड़छाड़, replay, rooting, custom ROM, Google backend-आधारित MDVM निर्णय, credential theft tools, overlay attack आदि KeyAttestation, RASP bootloader स्थिति जांच आवश्यक
    iOS DeviceCheck replay, certificate tampering, proxy attack, ऐप छेड़छाड़ RASP डिवाइस अखंडता assurance सीमित
    LPADB सार्वजनिक KeyAttestation keys का उपयोग कर rooting छिपाना KeyAttestation -
    DCVDB ज्ञात भेद्यताओं के आधार पर असुरक्षित डिवाइस की पहचान KeyAttestation, RASP डिवाइस class पहचान की सटीकता महत्वपूर्ण
    RASP ऐप hooking, debugging, rooting, emulation detection - रनटाइम के दौरान लगातार अखंडता निगरानी

Android KeyAttestation signal

  • HKS-आधारित हार्डवेयर सत्यापन जानकारी के जरिए डिवाइस मॉडल, OS version, patch level, bootloader स्थिति आदि की पहचान की जाती है
  • प्रमुख signal आइटम
    • SecurityLevel: HKS प्रकार की पहचान (TrustedEnvironment, StrongBox)
    • attestationIdModel/Product/Device: डिवाइस मॉडल पहचान
    • osVersion / osPatchLevel: OS version और security patch level
    • RootOfTrust: bootloader और Verified Boot स्थिति
    • AttestationApplicationId: ऐप package name, version, signing certificate hash
  • Google की Key-Attestation certificate revocation list का अपडेट धीमा है, इसलिए सार्वजनिक रूप से लीक हुई keys अब भी उपयोग योग्य हो सकती हैं
  • कुछ डिवाइसों में कुछ पहचान fields गायब हो सकती हैं, इसलिए तीनों fields का मूल्यांकन करना चाहिए

Android PlayIntegrity Verdict signal

  • Google Play Integrity API के जरिए ऐप और डिवाइस अखंडता सत्यापित की जाती है
  • प्रमुख signal आइटम
    • appRecognitionVerdict: क्या ऐप मूल है
    • deviceRecognitionVerdict: डिवाइस trust level (उदाहरण: MEETS_STRONG_INTEGRITY)
    • appLicensingVerdict: क्या PlayStore से इंस्टॉल किया गया है
    • playProtectVerdict: Play Protect risk assessment
  • MEETS_STRONG_INTEGRITY के लिए पिछले 12 महीनों के भीतर security patch लागू होना आवश्यक है
  • signal trust सुनिश्चित करने के लिए signature verification और decryption आवश्यक हैं
  • Google backend की आंतरिक मूल्यांकन पद्धति सार्वजनिक नहीं है

Android RASP

  • ठोस solution अभी तय नहीं हुआ है, और यह requirements definition चरण में है
  • detection functions
    • App Hooking/Debugging: dynamic manipulation detection (Frida, Xposed आदि)
    • App Repackaging/Tampering: ऐप छेड़छाड़ और re-signing detection
    • UD Rooting/Emulation: rooting, virtualization, automation environment detection
  • RASP रनटाइम के दौरान अखंडता निगरानी प्रदान करता है, और Google की revocation list से अलग blocklist बनाए रखकर leaked key-आधारित हमलों को रोकता है

iOS DCDeviceCheck.AppAttest Attestation

  • Secure Enclave और Apple servers के माध्यम से ऐप प्रमाणीकरण संरचना
  • प्रमुख signals
    • attestationObject: यह प्रमाण कि App Attest key Secure Enclave में बनाई गई है
    • credentialId: App Attest key पहचानकर्ता
    • RP ID: ऐप का App ID prefix + Bundle ID
  • Apple का risk indicator(receipt metric) proxy attacks की पहचान में उपयोगी हो सकता है, लेकिन स्पष्ट मानदंडों की कमी है और Apple servers से संचार के कारण privacy exposure risk मौजूद है
  • iOS में डिवाइस मॉडल, OS version/patch level की hardware-आधारित जानकारी उपलब्ध नहीं, इन्हें केवल OS query से ही जांचा जा सकता है

iOS DCDeviceCheck.AppAttest Assertions

  • App Attest key से उत्पन्न signature-आधारित सत्यापन संरचना
  • प्रमुख signals
    • assertionObject: challenge पर आधारित signature शामिल करता है
    • keyId: App Attest key पहचानकर्ता
    • counter: signature count, जिसे monotonically increase होना चाहिए
  • counter value में तेज़ वृद्धि proxy attack की संभावना का संकेत हो सकती है, जबकि कमी replay attack की संभावना दिखाती है

iOS RASP

  • Android जैसी detection functions की आवश्यकता
    • App Hooking/Debugging, App Repackaging, App Tampering, UD Rooting, UD Emulation
  • Apple का App Sandbox, Code Signing, System Integrity Protection केवल install समय सुरक्षा देता है; rooting·hooking·runtime manipulation detection उपलब्ध नहीं कराता
  • RASP रनटाइम के दौरान अखंडता निगरानी के जरिए इसकी भरपाई करता है
  • Apple दस्तावेज़ के अनुसार, App Attest स्पष्ट करता है कि “सामान्य डिवाइस पर चल रहा छेड़छाड़ किया गया ऐप वैध assertion उत्पन्न नहीं कर सकता”

निष्कर्ष

  • MDVM डिवाइस सुरक्षा स्थिति का real-time मूल्यांकन करता है और उच्च हमले-संभावना वाले वातावरण में प्रमाणीकरण key के उपयोग को ब्लॉक करके इलेक्ट्रॉनिक पहचान प्रमाणीकरण प्रणाली की विश्वसनीयता बनाए रखता है
  • Android और iOS दोनों में प्लेटफ़ॉर्म सुरक्षा सुविधाओं और RASP-आधारित dynamic protection को मिलाकर डिवाइस अखंडता सत्यापन ढांचा बनाया गया है
  • Google और Apple की backend verification व्यवस्था पर निर्भरता मौजूद है, और सार्वजनिक नहीं की गई आंतरिक मूल्यांकन पद्धतियाँ संभावित अनिश्चितता का कारक बनी रहती हैं

संबंधित पढ़ाई

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.