YubiKey 5 Series पर EUCLEAK side-channel हमला

 (ninjalab.io)
1 पॉइंट द्वारा GN⁺ 2024-09-04 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • secure element मज़बूत authentication के trust base के रूप में इस्तेमाल होते हैं, और EUCLEAK एक side-channel हमला है जो Infineon की ECDSA implementation से secret key निकालता है; इसका प्रदर्शन YubiKey 5Ci पर किया गया
  • मुख्य कमजोरी Infineon cryptographic library की non-constant-time modular inversion operation में है, और यह 14 वर्षों में लगभग 80 बार highest-level Common Criteria certification evaluations पास कर चुकी है
  • हमलावर को secure element तक physical access चाहिए, साथ ही कुछ local electromagnetic measurements, महंगे उपकरण, custom software और technical skill की ज़रूरत होती है, लेकिन measurement खुद कुछ ही मिनटों में हो सकता है
  • प्रभाव का दायरा firmware 5.7 से पहले की YubiKey 5 Series और Infineon cryptographic library चलाने वाले secure microcontrollers तक है, जिनमें TPM भी शामिल हैं
  • FIDO में ECDSA secret key निकालकर device cloning संभव है, लेकिन phishing defense के उद्देश्य से प्रभावित उत्पाद का उपयोग करना, उपयोग न करने से अब भी अधिक सुरक्षित है

EUCLEAK हमला किसे निशाना बनाता है

  • secure element छोटे microcontroller होते हैं जो secret values generate और store करते हैं तथा cryptographic operations चलाते हैं; इन्हें अक्सर Common Criteria के highest-level security evaluations मिलते हैं
  • FIDO hardware token web services में login के लिए इस्तेमाल होने वाला एक मज़बूत authentication माध्यम है, और FIDO protocol अपने मुख्य cryptographic primitive के रूप में ECDSA का उपयोग करता है
  • YubiKey 5 Series व्यापक रूप से इस्तेमाल होने वाला FIDO hardware token है, और secure element के रूप में Infineon SLE78 का उपयोग करता है
  • NinjaLab ने Feitian A22, जो Infineon SLE78-आधारित JavaCard open platform है, पर Infineon ECDSA implementation का विश्लेषण किया और side-channel कमजोरी का उपयोग करने वाला वास्तविक हमला डिज़ाइन किया
    • हमले का प्रदर्शन YubiKey 5Ci पर किया गया
    • यह कमजोरी अधिक नए उत्पादों Infineon Optiga Trust M और Infineon Optiga TPM secure microcontrollers तक भी फैली हुई है
  • इस कमजोरी का कारण Infineon Technologies cryptographic library का non-constant-time modular inversion है, जो 14 वर्षों और लगभग 80 highest-level Common Criteria certification evaluations के दौरान पकड़ में नहीं आया
  • विस्तृत तकनीकी दस्तावेज़ Download the Writeup में उपलब्ध है

प्रभावित उत्पाद और हमले की शर्तें

  • हमलावर को secure element तक physical access चाहिए, और कुछ local electromagnetic side-channel measurements के जरिए ECDSA secret key निकाली जा सकती है
    • FIDO protocol में इससे FIDO device cloning संभव हो जाता है
    • हमले के लिए महंगे उपकरण, custom software और technical skill की आवश्यकता होती है
  • प्रभावित उत्पाद इस प्रकार हैं
    • Infineon cryptographic library एम्बेड करने वाले सभी मौजूदा-version Infineon secure microcontrollers
    • मौजूदा-version Infineon TPM
    • firmware 5.7 से पहले की सभी YubiKey 5 Series
  • ये secure microcontrollers electronic passports, cryptocurrency hardware wallets, smart cars, smart homes जैसे ECDSA पर निर्भर कई security systems में उपयोग होते हैं, लेकिन EUCLEAK इन उत्पादों पर वास्तव में लागू होता है या नहीं, यह अभी पुष्टि नहीं हुई है
  • Feitian A22 JavaCard इस शोध में इस्तेमाल किया गया पुराना उत्पाद है और अब बिक्री में नहीं है
    • Feitian webstore पर वर्तमान में बिकने वाले Infineon secure microcontroller-आधारित उत्पाद Feitian की अपनी cryptographic library का उपयोग करते हैं, और NinjaLab की जानकारी के अनुसार वे इस शोध से प्रभावित नहीं हैं

mitigation और आधिकारिक जानकारी

  • YubiKey firmware 5.7 ने 6 मई 2024 के update में Infineon cryptographic library की जगह Yubico की नई cryptographic library अपना ली
    • NinjaLab की जानकारी के अनुसार यह नई library EUCLEAK से प्रभावित नहीं है
  • Infineon के पास cryptographic library patch पहले से है, लेकिन NinjaLab की जानकारी के अनुसार उसने अभी तक Common Criteria certification evaluation पास नहीं किया है
  • CVE request अस्वीकार कर दी गई, और MITRE ने इसके बजाय CVE-2024-45678 का उपयोग किया
    • description update request लंबित है
  • आधिकारिक स्थिति इन दस्तावेज़ों में देखी जा सकती है

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

1 टिप्पणियां

 
GN⁺ 2024-09-04
Hacker News की राय

  • Ars Technica लेख के अनुसार, हमलावर को username और password के साथ-साथ key तक physical access भी चाहिए, और device को खोलने के बाद वापस देने के लिए उसे फिर से assemble भी करना होगा, इसलिए यह कोई मामूली attack बिल्कुल नहीं है
    Plastic joint पर थोड़ा nail polish लगा देने से छेड़छाड़ का पता बताने वाले canary की तरह इस्तेमाल किया जा सकता है
    हालांकि इससे FIDO token की कमजोरी भी सामने आती है। आपने उसे कहाँ-कहाँ register किया है इसकी list खुद manage करनी पड़ती है, और token खो जाए या चोरी हो जाए तो हर registered जगह जाकर खुद revoke करना पड़ता है

    • यह सिर्फ YubiKey की समस्या नहीं है
      NinjaLab के मुताबिक Infineon cryptographic library चलाने वाले सभी Infineon secure microcontroller, जहाँ तक जानकारी है मौजूदा सभी versions में, इस attack के प्रति vulnerable हैं
      इसमें अमेरिका, चीन, भारत, ब्राज़ील और कई यूरोपीय व एशियाई देशों के e-passport chips, Samsung और OnePlus phones के secure areas, Ledger और Trezor जैसे cryptocurrency hardware wallets, SIM cards, Lenovo/Dell/HP laptops के TPM, और credit/debit cards के EMV chips शामिल हैं
    • मैं KeePassXC को password manager के रूप में इस्तेमाल करता हूँ और जिन accounts में hardware key इस्तेमाल होती है, उन पर tag लगा देता हूँ
      इसलिए key खो जाए, चोरी हो जाए या खराब हो जाए, तो हटाने वाली sites की list जल्दी निकाली जा सकती है
      मैं हमेशा 2 keys register करता हूँ और उन्हें physically अलग-अलग रखता हूँ, ताकि एक खो भी जाए तो login संभव रहे
    • मैं मानता हूँ कि यह attack मामूली नहीं है, लेकिन YubiKey कभी-कभी बहुत high-risk environments में इस्तेमाल होती है
      इसमें cryptocurrency assets तक access के अलावा defence contractors जैसी और गंभीर स्थितियाँ भी शामिल हैं
      ऐसे मामलों में हमलावर के पास resources भी बहुत होते हैं और motivation भी strong होती है, और YubiKey का इस्तेमाल ठीक ऐसे ही attacks को रोकने के लिए किया जाता है
      इसलिए key अभी भी phishing-resistant authentication देती है, लेकिन कुछ security expectations टूट गई हैं, ऐसा मानना होगा
    • पर्याप्त resources वाला attacker उसी ECDSA key के साथ backdoored replacement key भी बना सकता है
    • किसी individual के लिए जवाब यह हो सकता है कि इस device को सिर्फ critical services तक सीमित रखा जाए और बाकी के लिए अच्छी password hygiene पर निर्भर रहा जाए

  • सबसे परेशान करने वाली बात यह है कि YubiKey को बस यूँ ही replace नहीं किया जा सकता
    चाहे passkey इस्तेमाल करें या non-discoverable key, इस key को retire करने से पहले हर account में अलग-अलग जाकर उसे किसी नए, non-vulnerable key से बदलना होगा
    non-discoverable होना भी समस्या है, क्योंकि याद नहीं रहता कि पहले कहाँ-कहाँ YubiKey इस्तेमाल की थी
    Ars के लेख [0] में PIN की बात भी है, लेकिन यह YubiKey-specific feature नहीं बल्कि FIDO feature है
    [0]: https://arstechnica.com/security/2024/09/yubikeys-are-vulner...
    [1]: https://new.reddit.com/r/yubikey/comments/12bv4sv/fido_pin_s...

    • एक और पहलू से, non-discoverable FIDO keys के मुख्य use case यानी two-factor authentication की वजह से मुझे account से lock out हो जाने की ज्यादा चिंता रहती है
      पहले जब अमेरिकी customs ने YubiKey सहित electronic devices रोक लिए थे, तब मैंने सच में यह झेला था
      बाद में जिन accounts ने email को 2FA या अंतिम authentication method के रूप में स्वीकार किया, उनमें से कई recover हो गए, लेकिन AWS सहित कुछ accounts में ऐसा नहीं हुआ
      कई websites backup authentication methods और access खोने के परिणामों को साफ-साफ समझाए बिना 2FA enrollment recommend करती हैं
    • मैं password manager में track करता हूँ
      जिन accounts में YubiKey registered है, उन पर "YubiKey (FIDO)" tag लगा देता हूँ
    • GitHub जैसी sites जो resident WebAuthn tokens इस्तेमाल करती हैं, वे key में ज्ञात sites की list दिखा सकती हैं
      हालांकि इस पूरे flow का user experience अभी उम्मीद के स्तर का नहीं है
    • मुझे हमेशा यह बात नापसंद रही कि personal YubiKey को clone या backup नहीं किया जा सकता, इसलिए मैंने इसे हर जगह इस्तेमाल करने से बचा है
    • मैंने अभी तक ऐसी site नहीं देखी जो FIDO device register करते समय किसी दूसरे प्रकार का 2FA setup अनिवार्य न करती हो
      मेरे मामले में, साथ में app में रखा हुआ TOTP भी है

  • अगर “firmware 5.7 से नीचे की सभी YubiKey 5 Series प्रभावित हैं”, तो मैंने सोचा था कि physical hardware token का firmware update करना ही काफी होगा
    लेकिन लिखा है कि YubiKey firmware upgrade नहीं किया जा सकता
    https://support.yubico.com/hc/en-us/articles/360013708760-Yu...
    तो फिर Yubico free replacement दे रहा होगा, है ना? मेरे पास ऐसी कुछ YubiKeys हैं…

    • YubiKey का मकसद phishing को रोकना है, और इस attack के लिए physical access चाहिए
      यानी अगर आप इतने valuable हैं कि real world में सीधे target बन सकते हैं, तो शायद शुरुआत से ही YubiKey इस्तेमाल नहीं करनी चाहिए
      कोई आपकी spare key बदल सकता है, और बहुत देर होने तक आपको पता भी नहीं चलेगा
    • मैं 5.4.3 5C Nano इस्तेमाल कर रहा हूँ, free replacement नहीं है, सिर्फ mitigations हैं
      https://support.yubico.com/hc/en-us/articles/15705749884444-...
    • पिछली बार जब Infineon chip में crypto तोड़ने वाला bug था, तब Estonia के नागरिकों को नए ID cards free में मिले थे
      इसके उलट, release के दो महीने से भी कम समय बाद मेरी YubiKey 4 ने hardware attestation PIV smartcard के रूप में काम करना बंद कर दिया

  • “constant time नहीं होने वाली modular inverse calculation की वजह से” कहना कोई सूक्ष्म side channel नहीं है, जैसे बारीक रेडियो emission वगैरह
    secret data के हिसाब से time बदलता है या नहीं, side-channel audit में यह लगभग सबसे पहले चेक की जाने वाली चीज़ है
    बस यह verify करना होता है कि सभी operations data से स्वतंत्र होकर हमेशा समान number of clock cycles लेते हैं, और errors भी data से स्वतंत्र होकर fixed clock cycles के बाद ही आने चाहिए
    समझ नहीं आता auditors ने यह कैसे miss कर दिया

    • सटीक कहें तो यह वैसा radio side channel ही लगता है
      अगर मैंने paper को सही समझा है, तो non-constant time चीज़ algorithm execution खुद नहीं है, बल्कि बाहर से observe किए जा सकने वाले RF side channel का duty cycle है
      अगर execution time सचमुच non-constant होता, तो worst case में शायद सिर्फ USB से भी attack संभव होता, लेकिन Infineon implementation pure timing attack के लिए vulnerable नहीं लगती
      nonce blinding भी implement है, पर समस्या यह है कि elliptic curve size से कहीं छोटा multiplication mask इस्तेमाल किया गया, जिससे brute force संभव हो गया
    • ECDSA code review में सबसे पहले चेक की जाने वाली चीज़ों में से एक है, इसलिए Infineon के लिए यह शर्मनाक गलती है
    • सहमत। मैंने सच में कोई advanced attack expected किया था, लेकिन यह fancy probe लगाए हुए standard timing attack जैसा है
      फिर भी probe खुद शानदार है

  • अगर कोई physically YubiKey तक पहुंचने की कोशिश करने की हद तक जा रहा है, तो वह उसे समान रूप से घिसी-पिटी और वैसी ही दिखने वाली key से swap कर सकता है
    तब victim या तो मानेगा कि उसकी YubiKey खराब हो गई है, या attacker को YubiKey इस्तेमाल करने के लिए काफी समय मिल जाएगा
    उदाहरण के लिए, मेरे पास दो YubiKey हैं; अगर कोई मेरे घर में चुपके से घुसकर spare key बदल दे, तो मुझे तब तक पता नहीं चलेगा जब तक मैं spare key इस्तेमाल न करूं
    आखिरकार यह attack तभी मायने रखता है जब target को सीधे निशाना बनाने लायक value हो, और ऐसे target शायद YubiKey से कुछ ज्यादा सुरक्षित चीज़ इस्तेमाल करते होंगे

    • ykman list से YubiKey की identifying information देखी जा सकती है, इसलिए key सच में खराब है या बदली गई है, यह जांचने की प्रक्रिया आसानी से रखी जा सकती है
      security requirements ज्यादा हों तो इसे periodically verify कर सकते हैं या spare key की physical location को अलग से protect कर सकते हैं
      यह भी जानना चाहूंगा कि hardware authenticators में YubiKey से ज्यादा सुरक्षित क्या है
    • अगर access है, तो key को damage करके working spare key से swap करना वाकई आसान है
    • असल में YubiKey के chain की सबसे कमजोर कड़ी बनने की संभावना बहुत कम है
      attacker device को निशाना बना सकता है, communications intercept कर सकता है, data host करने वाली service पर warrant execute करा सकता है या stealthily infiltrate कर सकता है

  • EUCLEAK explanation PDF: https://ninjalab.io/wp-content/uploads/2024/09/20240903_eucl...
    Yubico blog post: https://www.yubico.com/support/security-advisories/ysa-2024-...

  • NinjaLab की research शानदार है
    Yubico advisory में खास तौर पर दिलचस्प बात यह है कि इस local cloning से WebAuthn protocol की attestation [1] भी निष्प्रभावी हो जाती है
    क्या protocol को इस local cloning attack के खिलाफ बेहतर withstand करने के लिए design किया जा सकता था?
    “attacker recovered attestation key का इस्तेमाल करके fake YubiKey बना सकता है। इस case में make credential के दौरान valid FIDO attestation statement generate होगा, जिससे affected YubiKey versions के लिए organization के authenticator model preference control को bypass किया जा सकता है।”

    1. https://www.w3.org/TR/webauthn-2/#attestation
    • अगर attacker request signing में इस्तेमाल होने वाले secret value को clone कर रहा है, तो वह secret value होने के बाद clone और original device में फर्क करने का कोई तरीका नहीं दिखता
      secure element का पूरा security model key extraction रोकने पर टिका है; अगर वही संभव हो जाए, तो key को computer file में store करने से बेहतर कुछ नहीं बचता
      हां, key पाने के लिए device को physically खोलना पड़ता है, इसलिए जब तक कोई वास्तव में key नहीं ले जाता, यह computer में store करने से ज्यादा सुरक्षित है
    • अफसोस, practical तौर पर यह मुश्किल है। attestation लगभग हमेशा इस structure पर निर्भर करता है कि कोई secure hardware issuer द्वारा certified secret को सुरक्षित रखता है, relying party के सामने खुद को authenticate करता है, और derived/stored secrets से trust आगे बढ़ाता है
      अगर वह attestation secret किसी भी तरीके से extract किया जा सकता है, तो attacker को fake authenticator बनाने से रोकना संभव नहीं, जो असली जैसा behave किए बिना भी fraudulent attestation बना सके
      theoretically indirect attestation या per-authenticator unique attestation keys से single attestation secret leak के impact को कम किया जा सकता है
      YubiKey की तरह लाखों authenticators द्वारा shared attestation key की बजाय ऐसा तरीका अपनाया जा सकता है, लेकिन फिर भी यह शायद probabilistic mitigation तक ही सीमित रहेगा

  • Yubico website पर लिखा है कि 5.7 और उससे ऊपर affected नहीं हैं
    Yubico के दूसरे post [1] को देखें तो 5.7 release की features में से एक RSA और ECC के underlying cryptographic operations करने वाली Yubico की अपनी cryptographic library में migration बताया गया है
    उम्मीद है इसे बहुत लोगों ने देखा होगा। आज के दौर में जब public और private implementations बहुत हैं, समझ नहीं आता कोई अपनी cryptographic library क्यों इस्तेमाल करना चाहेगा
    [1] https://www.yubico.com/blog/now-available-for-purchase-yubik...

    • क्योंकि vendor की वजह से security issue आने का यह दूसरा मौका है, और पिछली बार issue ज्यादा गंभीर था
      अगर पूरी company encryption पर आधारित है, तो पर्याप्त applied cryptographers hire करके अपनी किस्मत अपने हाथ में लेना वास्तव में समझदारी है
    • embedded platforms पर existing libraries port नहीं हुई हो सकतीं, या platform इतना अलग हो सकता है कि porting practical न हो
      दूसरे कारण भी हो सकते हैं, और closed source में economic considerations भी बड़े होते हैं
      खासकर जब पिछले closed, शायद source-available vendor implementation से in-house implementation में move किया जा रहा हो, तब तो और भी
    • 5.7 कब release हुआ था?

  • Infineon ने फिर कर दिखाया। 7 साल पहले भी ऐसा हुआ था: https://en.wikipedia.org/wiki/ROCA_vulnerability

  • “Infineon के पास पहले से ही cryptography library का patch है, लेकिन जहाँ तक जानकारी है, उसने अभी तक Common Criteria certification evaluation पास नहीं किया है” ऐसा कहा गया है, लेकिन सच कहें तो यह बिल्कुल महत्वपूर्ण नहीं है

    • हमले से अलग देखें तो यह एक दिलचस्प experiment है और इसे सार्वजनिक करना मूल्यवान है, लेकिन व्यवहार में, नाममात्र रूप से vulnerable devices पर भी वास्तविक दुनिया में इसका असर बहुत बड़ा नहीं लगता