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

 (bmi.usercontent.opencode.de)
1 पॉइंट द्वारा GN⁺ 27 일 전 | 1 टिप्पणियां | 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 व्यवस्था पर निर्भरता मौजूद है, और सार्वजनिक नहीं की गई आंतरिक मूल्यांकन पद्धतियाँ संभावित अनिश्चितता का कारक बनी रहती हैं

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

1 टिप्पणियां

 
GN⁺ 27 일 전
Hacker News की राय

  • eIDAS 2.0 स्पेसिफिकेशन किसी खास हार्डवेयर की मांग नहीं करता
    यह सिर्फ verifiable credentials और क्रिप्टोग्राफिक रूप से signed प्रमाणपत्रों को स्टोर करने की एक संरचना है
    ऐसा लगता है कि जर्मन implementation टीम उस प्रावधान से बचने की आलसी कोशिश कर रही है जिसमें कहा गया है कि “यूज़र Wallet Unit की प्रामाणिकता सत्यापित कर सके, इसके लिए एक मेकैनिज़्म लागू होना चाहिए”
    संबंधित दस्तावेज़ EUDI Architecture and Reference Framework में देखा जा सकता है

    • reference implementation को देखें तो maintainers Google dependency हटाना नहीं चाहते
      वजह स्पष्ट नहीं है, लेकिन जो चीज़ बिना वजह बनी रहती है, उसकी कोई वजह तो होती ही है
      GitHub repository देखें
    • सेक्शन 5.4 के Attestation Rulebooks और Attestation Schemes भाग में संबंधित नियम दिए गए हैं

  • एक जर्मन implementer के रूप में, eIDAS implementing regulation के अनुसार attestation mechanism का उपयोग करना ज़रूरी है
    यह operating system के समर्थन के बिना काम नहीं करता
    हमें पता है कि अभी Google/Android तक सीमित होना आदर्श नहीं है, और GrapheneOS जैसे दूसरे OS के समर्थन की भी योजना है
    फिलहाल यह सिर्फ priority का सवाल है, ऐसा नहीं कि समस्या का पता नहीं है

    • दो अमेरिकी कंपनियों के उत्पादों पर निर्भर होना “अच्छा नहीं” भर नहीं, बल्कि गंभीर समस्या है
      account lock होने के कई मामले हैं, और ऐसी निर्भरता रखना ही नहीं चाहिए
    • accessibility और eIDAS की भावना के उल्लंघन के लिहाज़ से इसमें गैरकानूनी तत्व भी हैं
      अंततः सभी नागरिक Google·Apple की terms के अधीन हो जाते हैं, और account suspend होने पर eID service तक पहुंच असंभव हो जाती है
      तकनीकी रूप से विकल्प मौजूद हैं, इसलिए ऐसा समाधान ढूँढना आपकी ज़िम्मेदारी है
    • एक जर्मन नागरिक के रूप में मैं पूछना चाहता हूँ: जब पता है कि यह सभी नागरिकों के लिए काम नहीं करेगा, तो इसे आगे क्यों बढ़ाया जा रहा है?
      मैं Google Play के बिना AOSP-आधारित Android से Ubuntu Touch पर गया हूँ, और आगे चलकर postmarketOS पर जाने की योजना है
    • Google account की access खोना बहुत आसान है। recovery भी असंभव हो सकती है
      ऐसे हालात और geopolitical risk को देखते हुए, किसी खास कंपनी पर निर्भरता को सही नहीं ठहराया जा सकता
      डेवलपर अनुभव का एक सबक यह भी है कि “अस्थायी जुगाड़ ही सबसे स्थायी समाधान बन जाता है”
    • eIDAS 1 के Mobile-ID (SIM-आधारित) या Smart-ID (server-side key management) से जो समस्या पहले ही हल हो चुकी थी,
      उसे फिर Wallet model में बदलने की क्या ज़रूरत है, यह समझ नहीं आता। दो अमेरिकी कंपनियों के backend पर निर्भर होने की कोई जरूरत नहीं है

  • attestation को ही खत्म कर देना चाहिए
    ऐप को यह नहीं जानना चाहिए कि वह किस डिवाइस पर चल रही है
    यूज़र अपने डिवाइस की सुरक्षा खुद कर सकता है, और डेवलपर के लिए सिर्फ सिफारिशें देना काफी होना चाहिए
    इसे GrapheneOS, rooted डिवाइस, emulator, Linux compatibility layer—हर तरह के environment में चलना चाहिए

    • सही बात, यह मेरा डिवाइस है, इसलिए मुझे इसे अपनी इच्छा से इस्तेमाल करने का अधिकार होना चाहिए
      ऐप का अमेरिकी big tech के “certification” को अपने-आप जांचना अनावश्यक है
    • device trust की अवधारणा ही भ्रम है
      rooted console और phones के इतिहास को देखें तो कोई भी सुरक्षा पूरी तरह परफेक्ट नहीं होती
      बेहतर यह होगा कि अगर यूज़र चाहे तो अपनी identity को डिवाइस से बाँधने का विकल्प optional feature के रूप में दिया जाए
    • बेशक rooting या modification आपकी स्वतंत्रता है, लेकिन उसके परिणाम भी आपको ही भुगतने होंगे
      अगर ऐप अपनी integrity verify नहीं कर सकती, तो कुछ features security reasons से संभव ही नहीं होंगे
      जैसे physical ID पर आकार या रूप जैसी सीमाएँ होती हैं, वैसे ही कुछ सीमाएँ यहाँ भी ज़रूरी हैं
    • आधुनिक computing का मूल पाप यह है कि ‘security elements’ यूज़र के लिए नहीं, बल्कि manufacturers के लिए डिज़ाइन किए गए
      NGSCB के दौर में ऐसे तत्वों को कानूनी रूप से प्रतिबंधित न करना ही समस्या की शुरुआत थी

  • अगर Google/Apple account खो जाए तो?
    अगर आप International Criminal Court के जज की तरह sanctions के दायरे में आ जाएँ, तो eIDAS access असंभव हो जाएगी
    यूरोपीय समाज का अब भी अमेरिकी कंपनियों पर निर्भर रहना एक विरोधाभासी वास्तविकता है

    • आप मशहूर व्यक्ति न भी हों, फिर भी automated account suspension की वजह से सामाजिक बहिष्कार जैसी स्थिति में जा सकते हैं
      दो विदेशी कंपनियों के हाथ में निगरानी और नियंत्रण की शक्ति होना खतरनाक है
    • “अगर यूरोप की राजधानी वॉशिंगटन में हो,” तो शायद ऐसी चीज़ें स्वाभाविक ही लगें
    • तब शायद Waymo भी इस्तेमाल नहीं कर पाएँगे

  • ऐसी नीतियों के खिलाफ जनता का विरोध इतना कम होना चौंकाने वाला है
    एक अभिभावक के रूप में मैं समझता हूँ कि बच्चों के internet उपयोग को नियंत्रित करने की जरूरत हो सकती है,
    लेकिन अंततः राज्य माता-पिता की भूमिका ले रहा है और हम स्वतंत्रता और गोपनीयता खो रहे हैं

    • ज़्यादातर लोग बस अमूर्त रूप में ही समझते हैं कि इसका उनकी ज़िंदगी पर क्या असर पड़ेगा
      जब तक खतरा “सरकार मेरे WhatsApp messages पढ़ रही है” जितना ठोस न हो, वे प्रतिक्रिया नहीं देते
    • जर्मनी में ध्यान speed limit बहस जैसे ऊर्जा-खपत वाले लेकिन निरर्थक मुद्दों पर बँट जाता है
      राजनीतिक वर्ग इस भ्रम का इस्तेमाल करके असली मुद्दों को ढक देता है
    • दूसरी ओर, कई माता-पिता online access restrictions के समर्थन में हैं
      वे चाहते हैं कि बच्चों को बड़ी कंपनियों की attention extraction से बचाया जाए
      जैसे वास्तविक दुनिया में age restrictions हैं, वैसे online दुनिया को अपवाद नहीं माना जा सकता
    • लोग अपने-अपने filter bubble में फँसे हुए हैं और ऐसे मुद्दों के बारे में सुनते तक नहीं
      लोकतंत्र के भविष्य को देखते हुए यह बहुत चिंताजनक है
    • EU व्यवहार में एक lobbying platform की तरह काम करता है
      नागरिक lobbying संभव तो है, लेकिन उसमें खर्च और समन्वय की जरूरत होती है, इसलिए बड़ी कंपनियाँ हावी रहती हैं
      हाल में EU digital infrastructure में hacker group की घुसपैठ की घटना भी हुई थी
      संबंधित लेख

  • खास hardware·software आवश्यकताएँ अतार्किक हैं
    सभी नागरिकों को अपनी पसंद का कंप्यूटर इस्तेमाल करने की आज़ादी होनी चाहिए
    authentication के लिए password या key pair ही काफी हैं, और चाहें तो TOTP या security key जोड़ी जा सकती है
    लगता है जैसे लोग भूल गए हैं कि smartphone के अलावा भी कंप्यूटर होते हैं

    • EU कहता है कि वह VISA·MasterCard से स्वतंत्र payment system बनाएगा, लेकिन अंततः app store dependency बनी रहती है
      Apple·Google account के बिना digital euro payments भी संभव नहीं होंगी
      यह देखकर हैरानी होती है कि राजनेता और बैंक दो-तीन कदम आगे की सोच भी नहीं पा रहे
    • EU की नीति “यूज़र अपने जोखिम का आकलन खुद करे” वाली नहीं है,
      बल्कि यह मानती है कि service provider को यूज़र की रक्षा करनी चाहिए
      परिणामस्वरूप supported platforms पर प्रतिबंध लगभग अपरिहार्य हो जाता है
    • “हर कंप्यूटर पर चलना चाहिए” कहना भी अव्यावहारिक है
      इसका मतलब यह नहीं कि कानूनन इसे Apple II पर भी चलना ही चाहिए

  • sanctions के दायरे में आने वाले लोग या कुछ विशेष समूह Play Store तक पहुँच नहीं बना पाते,
    इसलिए eIDAS ऐप install करना ही असंभव हो सकता है

    • अगर account की जरूरत है, तो हाँ
      हाल के राजनीतिक विरोधियों के account deletion मामलों को देखें, तो कुछ authorities को यह शायद उल्टा पसंद भी आए
    • लेकिन private key की सुरक्षा सबसे अहम है
      smart card जैसे security device की जरूरत होती है, इसलिए पूरी तरह खुला environment जोखिमभरा है
      “मैं alternative Android इस्तेमाल करना चाहता हूँ” यह समझ में आता है, लेकिन यह भी समझना होगा कि वह non-secure environment है

  • EU इस तरह की व्यवस्था पर कितना बजट बर्बाद करेगा, यह सोचकर हैरानी होती है
    समझ नहीं आता कि आखिर किसे इसकी जरूरत है

  • Self Sovereign Identity(SSI) ही असली समाधान है
    किसी व्यक्ति की पहचान किसी संस्था या कंपनी के अधीन नहीं होनी चाहिए
    पहचान बस ‘मैं स्वयं’ होनी चाहिए
    Google ID या Apple ID नहीं, बल्कि self-sovereign identity की जरूरत है

    • लेकिन “मैं बस मैं हूँ” कहना वास्तविक पहचान सत्यापन नहीं है
      आप बार में ID card की जगह ऐसा नहीं कह सकते
      सामाजिक अनुबंध के भीतर कार्यात्मक पहचान सत्यापन आवश्यक है
    • EU ने 2019 में ही ESSIF(European Self-Sovereign Identity Framework) बना लिया था
      infrastructure सात साल पहले से मौजूद है, इसलिए सिर्फ यह कह देना कि सरकार अक्षम है, पर्याप्त नहीं

  • लगता है कि “डिजिटल Reichstag fire” होने का समय आ गया है
    मैं पूछना चाहता हूँ कि जर्मनी आखिर कब इतिहास दोहराने की अपनी आदत छोड़ेगा