Soatok की अनौपचारिक Threat Model गाइड

 (soatok.blog)
2 पॉइंट द्वारा GN⁺ 1 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Threat model सिर्फ़ संरक्षित किए जाने वाले लक्ष्य और attacker की सूची तक सीमित नहीं होता; जब यह assets के बीच संबंध, assumptions, और जानबूझकर बाहर रखे गए threats को भी दिखाता है, तभी यह design decision में काम आता है
  • एक अच्छा model assets को सूची नहीं बल्कि graph की तरह देखता है, और components के input, output, और dependencies को क्रमशः संकीर्ण करते हुए risk और premises की जाँच करता है
  • अगर assumptions टूट जाएँ, तो स्वीकार किए गए risk की फिर से समीक्षा करनी चाहिए; Invisible Salamanders attack तब समस्या बनता है जब E2EE abuse reporting feature और AEAD की “प्रति संदेश एक ही valid key” वाली assumption टकराती है
  • publickey.directory का उदाहरण assumptions, assets, actors, और risk states को अलग-अलग देखता है, लेकिन यह परिपूर्ण नहीं है; Matrix v1.18 threat model attack type की सूची के अधिक करीब है और उसमें encryption तथा key management गायब हैं
  • threat modeling, passkey authentication, distributed E2EE design, और PQC बहस जैसे मामलों में तकनीकी विकल्पों की सीमाओं और वास्तविक risks को अलग करके बेहतर design decision लेने में मदद करता है

Threat model को किन सवालों का जवाब देना चाहिए

  • Threat model एक औपचारिक cyber security process हो सकता है, लेकिन नए product या service के design·architecture चरण में इसे अनौपचारिक रूप से भी किया जा सकता है
  • कम-से-कम इसे इन सवालों का जवाब देना चाहिए
    • क्या संरक्षित किया जा रहा है
    • कौन या क्या उस संरक्षित लक्ष्य को नुकसान पहुँचाना चाहता है
    • attacker किस तरीके से हमला कर सकता है
    • उस हमले को रोकने के लिए क्या किया जाएगा
  • सिर्फ़ इन चार बातों से भी इसे threat model कहा जा सकता है, लेकिन व्यवहार में महत्वपूर्ण विवरण छूट जाना आसान है
  • इसके अलावा ज़रूरी सवाल ये हैं
    • संरक्षित assets आपस में कैसे जुड़े हैं
    • कौन-सी assumptions की जा रही हैं
    • किन threats को जानबूझकर नहीं संभाला जा रहा है
  • हर भविष्य के attack को कवर करना संभव नहीं है, इसलिए बाहर रखे गए threats को स्पष्ट रूप से लिखना चाहिए
  • अगर assumptions ग़लत निकलें, तो model अधूरा हो जाता है, और पहले से स्वीकार की गई risk सूची की भी फिर से समीक्षा करनी चाहिए
  • Threat model किसी एक समय का snapshot नहीं बल्कि ज़रूरत पड़ने पर अपडेट होने वाला living document होना चाहिए

जब assumptions टूटती हैं तो क्या समस्या होती है

  • Invisible Salamanders attack कुछ E2EE messaging designs में abuse reporting feature जोड़ने पर उस feature को तोड़ सकता है
  • यह attack AES-GCM, ChaCha20-Poly1305 जैसे AEAD schemes की assumptions से जुड़ा है
    • इन schemes में यह assumption होती है कि किसी दिए गए message के लिए एक ही valid key होती है
    • अगर एक message के लिए कई valid keys हों, या confused deputies बन जाएँ, तो algorithm की security guarantees के बाहर चला जाता है
  • assumptions को स्पष्ट रूप से लिखना अपनी unknown unknowns की पहचान करने में मदद करता है
  • परिपूर्ण होना ज़रूरी नहीं, लेकिन किन premises पर भरोसा किया जा रहा है यह साफ़ होना चाहिए

Threat modeling शुरू करने की प्रक्रिया

  • पेशेवर रूप से threat modeling करना हो तो Threat Modeling Manifesto पढ़ने की सिफ़ारिश की जाती है
  • व्यवहार में शुरुआत 7 बिंदुओं को जल्दी से कॉपी करके भरने योग्य format में लिखने से की जाती है
  • उसके बाद जिस system का analysis करना है उसके components को कागज़ या digital tool पर बनाइए
    • अगर कोई widget किसी दूसरे widget से सीधे communicate करता है, depend करता है, या interact करता है, तो उस संबंध को चिह्नित कीजिए
    • संबंध दिखाने का तरीका वही हो जो काम करने वाले व्यक्ति के लिए सबसे उपयोगी हो
  • पूरे graph को एक box में घेरने के बाद, धीरे-धीरे box को छोटा करते हुए हर component पर ध्यान केंद्रित कीजिए
    • हर iteration में component के input और output लिखिए
    • जहाँ तक संभव हो 7 सवालों के जवाब दीजिए
  • abstraction level जितनी गहराई की अनुमति दे, उतना नीचे जाएँ, फिर जिन layers तक और नीचे नहीं गए उनके बारे में कौन-सी assumptions हैं इस पर brainstorming कीजिए
  • हो सकता है database, load balancer की तरह X25519 की security पर निर्भर न हो
  • database में RSS feed पहुँचने जैसे अनुचित संबंधों को दर्ज करना, और संभव हो तो उन्हें तोड़ना, लक्ष्य होना चाहिए

publickey.directory उदाहरण

  • Fediverse में key transparency देने का काम publickey.directory पर ट्रैक किया जा रहा है
  • यह काम public-key-directory-specification specification से शुरू हुआ, और specification में threat model शामिल है
  • यह threat model इन sections से बना है
    • assumptions
    • assets
    • attackers और संरक्षित किए जाने वाले लोगों को शामिल करने वाले actors तथा role names
    • risks और risk states
  • risk states चार प्रकार के हैं
    • Prevented by design: attack design के कारण काम ही नहीं करता
    • Mitigated: यदि assumptions ग़लत न हों, तो attack सफल नहीं होना चाहिए
    • Addressable: mitigation का तरीका है, लेकिन effort या सावधानी चाहिए और operator को इसकी जानकारी होनी चाहिए
    • Open: ऐसा risk जिसे mitigate नहीं किया जा सकता या नहीं किया जाएगा, और उस स्थिति में attack सफल होता है
  • यह threat model भी परिपूर्ण नहीं है
    • assets और actors के संबंधों को पूरी तरह से human-readable graph में नहीं जोड़ा गया है
    • risk section में कुछ blind spots छूटे हो सकते हैं
    • system security के लिए महत्वपूर्ण कुछ assumptions छूट गई हो सकती हैं

Matrix और Signal की तुलना

  • Matrix v1.18 का Security Threat Model denial of service, spoofing, spam, spying जैसे attack types को सूचीबद्ध करता है
  • उस document में ये समस्याएँ हैं
    • यह threat model से अधिक attack type सूची के करीब है
    • assumptions की सूची नहीं है
    • assets की सूची और assets के बीच संबंध नहीं हैं
    • attacks की सूची अधूरी है
    • Matrix को E2EE messenger के रूप में प्रचारित किया जाता है, लेकिन threat model encryption या key management को नहीं कवर करता
  • Matrix threat model v1.1 के बाद से ज़्यादा नहीं बदला है, जबकि उस बीच vulnerabilities का खुलासा हुआ और Lotte के दो अतिरिक्त cryptographic attacks भी आए
  • फिर भी Matrix के पास threat model है
  • Signal technical specification देता है, लेकिन उसका threat model उपयोगकर्ता को ख़ुद समझना पड़ता है
  • ख़राब threat model भी बिल्कुल threat model न होने से बेहतर है

Threat model design को कैसे बेहतर बनाता है

  • security practice में अक्सर कहा जाता है कि defender को हर बार सही होना पड़ता है, जबकि attacker को सिर्फ़ एक बार सफल होना होता है
  • अगर defender पर्याप्त तैयारी करे, तो वह attacker की movement का terrain तय कर सकता है
  • वास्तविक defense-in-depth में threat model को पर्याप्त रूप से समझना शामिल है ताकि attacker को अनुमानित dead end में धकेला जा सके

  • Credential stuffing की रोकथाम

    • Credential stuffing वास्तविक दुनिया में अत्यधिक प्रभावी एक सरल हमला है
    • इसका कारण लोगों का passwords दोबारा इस्तेमाल करना है
    • कई unique और सुरक्षित passwords याद रखना उपयोगकर्ताओं के लिए कठिन है, इसलिए password manager कुछ समय तक उचित mitigation था
    • अब passkey को बेहतर विकल्प माना जाता है
    • passkey authentication के लिए asymmetric cryptography का उपयोग करवाने का अधिक user-friendly तरीका है
    • सर्वोत्तम स्थिति में SoloKeys या YubiKeys जैसे hardware security tokens उपयोग किए जाते हैं
    • औसत स्थिति में operating system या password manager यह सुविधा देता है
    • credential stuffing और समान सरल attacks से बचने के लिए ये design ज़रूरी हैं
      • application को passkey अनिवार्य करने के लिए design किया जाए
      • उपयोगकर्ता को कई passkeys register करने दी जाएँ, या कम-से-कम एक backup passkey अनिवार्य हो
      • जिन उपयोगकर्ताओं ने सभी credentials खो दिए हों, उनके लिए administrator के पास नया passkey जोड़ने का break glass रास्ता हो
      • यह administrative action ऐसे logs में दर्ज हो जिन्हें administrator censor न कर सके
      • जहाँ संभव हो authentication password का समर्थन बिल्कुल न किया जाए
      • encryption key derivation के लिए password अलग संदर्भ में ठीक हो सकता है
    • passkey registration के समय credentials domain name से cryptographically bind हो जाते हैं, इसलिए phishing संभव नहीं होती
    • भले passkey onboarding की लागत हो, यह credential stuffing और phishing से जुड़ा support burden उससे अधिक घटा सकता है
    • जब यह अवास्तविक अपेक्षा हटा दी जाती है कि इंसान high-entropy secrets याद रखें और reuse न करें, तब कई attack classes समाप्त होती हैं और usability भी बेहतर होती है
    • Avi Douglen का यह कथन उद्धृत है: “usability की क़ीमत पर security, security की ही क़ीमत पर होती है”

Distributed E2EE और threat model

  • direct messaging के लिए E2EE पर दो प्रस्तावों पर चर्चा हो रही है
    • Fediverse software, जैसे Mastodon के private DM, को लक्ष्य करने वाला ActivityPub E2EE specification
    • ATProto, जैसे BlueSky, के लिए वही लक्ष्य रखने वाले Germ Network जैसे projects
  • दोनों projects ने किसी बिंदु पर MLS को E2EE conversation key management protocol के रूप में उपयोग करने पर विचार किया
  • decentralized systems में MLS की दो महत्वपूर्ण सीमाएँ हैं
    • MLS, Authentication Service नाम की एक abstract concept को specify करता है
    • MLS के epoch को सहारा देने वाले ratcheting tree की security में message ordering महत्वपूर्ण है
  • यदि ActivityPub पहली सीमा के लिए key transparency अपनाता है, तो उसे यह specify करना होगा कि कई servers पर कई KeyUpdate messages के टकराने पर क्या किया जाए
  • ATProto और BlueSky की स्थिति अधिक कठिन है
    • ATProto में Fediverse जैसी instances नहीं हैं
    • security analysis में इसे लगभग P2P की तरह देखना पड़ता है
    • distributed system में message ordering सुनिश्चित करने के लिए Raft consensus algorithm जैसे जटिल protocols की ज़रूरत पड़ सकती है
    • या फिर MLS को छोड़कर pairwise E2EE अपनाना होगा और group abstraction का त्याग करना होगा
  • अगर users के बीच message confidentiality security goal है और hosting को decentralize करना है, तो ATProto का blockchain-जैसा design आज उपलब्ध standardized efficient group key agreement protocols के उपयोग में बाधा बनता है
  • threat modeling शुरुआती diagram stage में ही ऐसी design constraints सामने ला सकता है

PQC बहस में threat modeling की भूमिका

  • hybrid post-quantum constructions के संदर्भ में IETF TLS working group mailing list पर non-hybrid ML-KEM code points के लिए RFC पर चर्चा चल रही है
  • चर्चा की premises इस प्रकार हैं
    • ML-KEM, NSA का design नहीं है
    • मुख्य submitter Peter Schwabe हैं, जिन्होंने Daniel J. Bernstein और NaCl crypto library के साथ काम किया है, और वे Germany में रहते हैं
    • अन्य submitters भी Europe के विभिन्न क्षेत्रों में हैं
    • Sophie Schmieg के लेख की तरह, information theory ML-KEM में backdoor की संभावना को खारिज करती है
    • ML-KEM को NIST की सार्वजनिक और 10-वर्षीय international standardization effort के तहत चुना गया
    • NIST, FIPS, और NSA confidential systems में non-hybrid ML-KEM और ML-DSA की माँग करते हैं
  • संबंधित IETF draft non-hybrid ML-KEM को specify करता है और उसे Recommend=N के रूप में चिह्नित करता है
  • hybrid KEM RFC को Recommend=Y के रूप में चिह्नित किए जाने की उम्मीद है, और hybrid KEM को non-hybrid KEM से अधिक पसंद किया जाता है
  • जो systems हमेशा hybrid KEM उपयोग करने के लिए configure हैं, उनकी security ML-KEM RFC आने से कम नहीं होगी
  • Google Chrome पहले से non-hybrid ML-KEM को support करता है, और IETF RFC न होने पर भी यह तथ्य नहीं बदलेगा
  • इस RFC का व्यावहारिक प्रभाव यह है कि CNSA 2.0, FIPS 140-3, या समान नियमों का पालन करने वाली और Internet Draft के बजाय स्थिर IETF RFC number चाहने वाली संस्थाओं की procedural constraint दूर हो जाएगी
  • यह समस्या विशेष रूप से उन business segments में आम हो सकती है जो government customers को बेचते हैं

  • Hybrid PQ+ECDH और Pure PQ का अंतर

    • KEM में सामने आने वाला risk “Q-Day के बाद crypto तोड़ना” नहीं बल्कि Harvest Now, Decrypt Later है
    • Q-Day उस समय के लिए shorthand है जब attacker के पास crypto-संबंधित quantum computer आ जाएगा
    • risk को बाँटें तो स्थिति यह बनती है
      • Pure ECDH, यानी PQ के बिना, Q-Day पर retroactively टूट जाता है
      • Pure PQ, इस assumption पर कि PQ algorithm पहले नहीं टूटता, Q-Day पर नहीं टूटता
      • Hybrid PQ+ECDH, Q-Day से पहले algorithm collapse के विरुद्ध hedge है, लेकिन Q-Day के बाद Pure PQ की तुलना में उपयोगी नहीं है
    • ECDH + ML-KEM की वकालत करना लंबी अवधि में ML-KEM को सुरक्षित algorithm मानने के बराबर है
    • hybrid को पसंद करने के दो कारण बताए गए हैं
      • यह पूरी तरह अनजान algorithm की तुलना में स्वीकार करना आसान है, इसलिए PQ adoption तेज़ कर सकता है
      • यह ML-KEM या पूरे lattice-based cryptography परिवार के algorithm collapse के विरुद्ध hedge दे सकता है
    • अगर crypto-सक्षम quantum computer के विरुद्ध भी hedge चाहिए, तो PQ+PQ hybrid की ज़रूरत होगी
    • अगर algorithm diversity महत्वपूर्ण है, तो ML-KEM + HQC + ECDH का 3-way hybrid अधिक ईमानदार दावा होगा
    • ML-KEM एक lattice-based KEM है और इसे quantum attacks के विरुद्ध टिकाऊ माना जाता है
    • HQC एक code-based KEM है और इसे quantum attacks के विरुद्ध टिकाऊ माना जाता है
    • ECDH वर्तमान में इस्तेमाल होने वाली पद्धति है, लेकिन quantum attacks के प्रति संवेदनशील है
    • threat modeling ऐसी बहसों में वैचारिक विरोध और तकनीकी risk को अलग करके निर्णय लेने में मदद कर सकता है

निष्कर्ष

  • इंटरनेट पर threat model और संबंधित methodologies को औपचारिक रूप से समझाने वाली कई guides उपलब्ध हैं
  • यहाँ उद्देश्य एक smoke test तैयार करना है जिससे threat model document की quality और effectiveness को जल्दी परखा जा सके
  • अच्छा threat model सिर्फ़ संरक्षित लक्ष्य, attacker, attack method, और defenses तक सीमित नहीं रहता, बल्कि assets के संबंध, assumptions, और accepted risks को भी उजागर करना चाहिए

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

1 टिप्पणियां

 
GN⁺ 1 시간 전
Lobste.rs की राय
  • इस बार मैं शायद उनकी तारीफ़ करने वाला था कि उन्होंने दुर्लभ रूप से घमंडी और अप्रिय रवैये के बिना ब्लॉग पोस्ट लिखी, लेकिन आखिरकार पोस्ट के उस हिस्से तक पहुँच गया जो उस ब्लॉग में आम Matrix आलोचना पोस्ट जैसा था
    “असभ्यता” अगर टिप्पणी रिपोर्ट करने का वैध कारण है, तो tech internet को बेहतर बनाने के लिए क्या हमें इस लेखक के ब्लॉग पर बार-बार दिखने वाले आक्रामक tone को अब और बढ़ावा नहीं देना चाहिए और उसे recommend करना भी बंद नहीं कर देना चाहिए? उस domain को पूरी तरह ban करने पर भी विचार किया जा सकता है
    • जिस हिस्से की आलोचना की गई थी, उसे पूरा quote किया गया था, और उसके खिलाफ ठोस rebuttal भी दिया गया था — यह काफ़ी तर्कसंगत आलोचना थी। मुझे लगा कि यह ज़्यादातर आलोचनाओं से कहीं बेहतर उदाहरण था
    • यह तिरस्कार संस्कृति है: https://blog.aurynn.com/2015/12/16-contempt-culture
    • मुझे समझ नहीं आता कि किसी को “घमंडी और अप्रिय बेवकूफ़” कहना और साथ ही यह कहना कि उसे असभ्य होने की वजह से ban कर देना चाहिए, ये दोनों बातें एक साथ कैसे चल सकती हैं। आप जो बदलाव देखना चाहते हैं, उसे खुद दिखाना चाहिए
    • मुझे tone ठीक लगा
      और “everything is graphs” वाला protocol वास्तव में research project की तरह treat किया जाना चाहिए। नतीजा असल में यह था: “अरे, graph algorithms पर सही ढंग से reasoning करना सच में बहुत मुश्किल है”