एंड-टू-एंड एन्क्रिप्शन (E2E) वाले दूतों में, उपयोगकर्ता अपनी कुंजियों के लिए जिम्मेदार होता है। जब वह उन्हें खो देता है, तो उसे अपना खाता रीसेट करने के लिए मजबूर किया जाता है।

खाता रीसेट करना खतरनाक है। आप सार्वजनिक कुंजी मिटा देते हैं और सभी वार्तालापों में एक क्रिप्टोग्राफ़िक अजनबी बन जाते हैं। आपको अपनी पहचान को पुनर्स्थापित करने की आवश्यकता है, और लगभग सभी मामलों में इसका मतलब है एक व्यक्तिगत बैठक और प्रत्येक संपर्कों के साथ "सुरक्षा संख्या" की तुलना। आप वास्तव में कितनी बार इस तरह के परीक्षण से गुजरते हैं, जो MiTM से एकमात्र सुरक्षा है?

यहां तक ​​कि अगर आप सुरक्षा संख्या के बारे में गंभीर हैं, तो आप एक सम्मेलन में वर्ष में केवल एक बार कई चैट पार्टनर देखते हैं, इसलिए आप फंस गए हैं।

लेकिन यह अक्सर होता है, है ना?

रीसेट कितनी बार होता है? उत्तर: अधिकांश E2E चैट अनुप्रयोगों में हर समय।

इन त्वरित संदेशवाहकों में, आप क्रिप्टोग्राफी छोड़ देते हैं और बस सर्वर पर भरोसा करना शुरू करते हैं: (1) जब भी आप एक नए फोन पर स्विच करते हैं; (2) जब भी कोई वार्ताकार किसी नए टेलीफोन पर स्विच करता है; (3) जब फोन की फ़ैक्टरी सेटिंग्स पर रीसेट किया जाता है; (4) जब कोई भी वार्ताकार फैक्ट्री सेटिंग्स पर रीसेट करता है; (५) जब भी आप एप्लिकेशन को अनइंस्टॉल और रीइंस्टॉल करते हैं, या (६) जब आप जिस किसी व्यक्ति से बात कर रहे होते हैं, उसे अनइंस्टॉल करते हैं और उसे पुनः स्थापित करते हैं। यदि आपके पास दर्जनों संपर्क हैं, तो हर कुछ दिनों में एक रीसेट होगा।

रीसेट इतनी नियमित रूप से होता है कि ये अनुप्रयोग दिखावा करते हैं कि यह कोई समस्या नहीं है:


ऐसा लगता है कि हमारे पास एक सुरक्षा अपग्रेड है! (लेकिन वास्तव में नहीं)

क्या यह सच में TOFU है?

क्रिप्टोग्राफी में, TOFU शब्द ("पहले उपयोग पर भरोसा") एक मौका का खेल बताता है जब दो पार्टियां पहली बार बोलती हैं। व्यक्तिगत रूप से मिलने के बजाय, मध्यस्थ प्रत्येक पक्ष के लिए जिम्मेदार होता है ... और फिर, पार्टियां स्वयं उपस्थित होने के बाद, प्रत्येक पक्ष यह सुनिश्चित करने के लिए कुंजियों की निगरानी करता है कि कुछ भी नहीं बदला है। यदि कुंजी बदल गई है, तो प्रत्येक पक्ष एक अलार्म देता है।

यदि ऐसी स्थिति में दूरस्थ होस्ट की कुंजी एसएसएच में बदल जाती है, तो यह "सिर्फ काम" नहीं होगा, बल्कि पूरी तरह से जुझारू हो जाएगा:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
00:11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee:ff
Please contact your system administrator.
Add correct host key in /Users/rmueller/.ssh/known_hosts to get rid of this message.
Offending RSA key in /Users/rmueller/.ssh/known_hosts:12
RSA host key for 8.8.8.8 has changed and you have requested strict checking.
Host key verification failed.

यहाँ सही व्यवहार है। और याद रखें: यह TOFU नहीं है यदि यह आपको एक छोटी चेतावनी के साथ आगे काम करने की अनुमति देता है। आपको क्रॉसबोन्स के साथ एक विशाल खोपड़ी देखना चाहिए ।

बेशक, ये तत्काल संदेशवाहक दावा करेंगे कि सब कुछ ठीक है, क्योंकि उपयोगकर्ता को चेतावनी दी गई है। वह चाहे तो सुरक्षा नंबरों की जांच कर सकता है । इसीलिए हम सहमत नहीं हैं:

1. सत्यापन नहीं किया जाता है क्योंकि यह बहुत बार होता है।
   
2. चूस चूस कर।
   
3. यहां तक ​​कि सुरक्षा की चिंता करने वाले हमारे दोस्तों के एक सरसरी सर्वेक्षण से पता चला कि कोई भी इस परीक्षण के बारे में चिंतित नहीं है।
   
4. तो यह सिर्फ सर्वर पर भरोसा है और एसएमएस पर भरोसा (अच्छी तरह से, अच्छी तरह से!) फिर से, फिर से ।
   
5. अंत में, इन अनुप्रयोगों को इस तरह से काम नहीं करना चाहिए। खासकर उपकरणों को बदलते समय। एक सामान्य सामान्य मामले को सुचारू रूप से और सुरक्षित रूप से संभाला जा सकता है, और स्थिति जितनी दुर्लभ हो, उतनी ही खराब दिखनी चाहिए। एक मिनट में, कीबेस समाधान दिखाएं।

इसे TOFU कहना बंद करो

बहुत प्रभावी हमला है। मान लीजिए कि ईव ऐलिस और बॉब की मौजूदा बातचीत में टूटना चाहता है और उनके बीच खड़ा है। एलिस और बॉब कई वर्षों से संपर्क में हैं, लंबे समय से टीओएफयू पास है।

ईव सिर्फ ऐलिस को लगता है कि बॉब ने एक नया फोन खरीदा है:

बॉब (हव्वा): अरे, अरे!

ऐलिस: यो, बॉब! ऐसा लगता है कि आपके पास नए सुरक्षा नंबर हैं।

बॉब (ईव): हां, मैंने iPhone XS, एक अच्छा फोन खरीदा है, इससे बहुत खुश हूं। चलो आरडब्ल्यूसी 2020 पर सुरक्षा नंबर का आदान-प्रदान करते हैं। अरे, क्या आपके पास अपना वर्तमान कैरोलिन पता है? मैं सैन फ्रांसिस्को में रहते हुए उसे आश्चर्यचकित करना चाहता हूं।

ऐलिस: मैं तुलना नहीं कर सकता, एंड्रॉइड 4 जीवन! हां, कोज़ी स्ट्रीट 555।

इसलिए, अधिकांश एन्क्रिप्ट किए गए दूत TOFU अनुपालन अर्जित करने की संभावना नहीं है। यह TADA की तरह अधिक है - उपकरणों को जोड़ने के बाद विश्वास। यह एक वास्तविक, काल्पनिक समस्या नहीं है, क्योंकि यह पहले से मौजूद बातचीत में दुर्भावनापूर्ण कार्यान्वयन का अवसर पैदा करता है। वास्तविक टीओएफयू में, जब तक कोई आपकी बातचीत में दिलचस्पी लेता है, तब तक वे इसमें घुसपैठ नहीं कर पाएंगे। टाडा के साथ, यह संभव है।

समूह चैट में, स्थिति और भी खराब है। चैट में जितने अधिक लोग होंगे, उतनी बार खाते को पुनः इंस्टॉल किया जाएगा। केवल 20 लोगों की कंपनी में, हमारे अनुमान के अनुसार, यह लगभग हर दो सप्ताह में होगा। और कंपनी के प्रत्येक व्यक्ति को इस व्यक्ति से मिलना चाहिए। निजी तौर पर। अन्यथा, संपूर्ण चैट एक तिल या हैकर द्वारा समझौता किया जाता है।

निर्णय

क्या एक अच्छा समाधान है जो निजी कुंजी सर्वरों पर भरोसा नहीं करता है? हमें लगता है कि कई उपकरणों के लिए वास्तविक समर्थन है। इसका मतलब है कि आप उपकरणों की एक श्रृंखला का प्रबंधन करते हैं जो आपकी पहचान का प्रतिनिधित्व करते हैं। जब आप एक नया डिवाइस (फोन, लैपटॉप, डेस्कटॉप कंप्यूटर, आईपैड, आदि) प्राप्त करते हैं, तो यह अपनी कुंजी जोड़ी बनाता है, और आपके पिछले डिवाइस ने इसे बनाया है। यदि आप उपकरण खो देते हैं, तो इसे शेष लोगों में से एक से हटा दें। तकनीकी रूप से, इस तरह की विलोपन एक याद है, और इस मामले में कुछ प्रकार की कुंजी उलट भी होती है जो स्वचालित रूप से होती है।

नतीजतन, आपको सर्वर पर भरोसा करने या व्यक्तिगत रूप से मिलने की आवश्यकता नहीं होती है जब वार्ताकार या सहकर्मी एक नया उपकरण प्राप्त करता है । इसी तरह, डिवाइस को हटाने पर आपको सर्वर पर भरोसा करने या व्यक्ति से मिलने की आवश्यकता नहीं है, अगर यह अंतिम नहीं था। आपको केवल चेतावनी देखने की आवश्यकता होती है जब कोई व्यक्ति वास्तव में अपनी सभी सेटिंग्स तक पहुँच खो देता है। और इस मामले में, आपको एक गंभीर चेतावनी दिखाई देगी, जैसा कि यह होना चाहिए:


विशेष रूप से अधिकतम बदसूरत

परिणामस्वरूप, बहुत कम खाते रीसेट किए जाते हैं और फिर से इंस्टॉल किए जाते हैं। ऐतिहासिक रूप से, कीबेस पर, डिवाइस ऐड-ऑन और समीक्षाओं की कुल संख्या खाता निर्वहन की संख्या का दस गुना है (आपको इसके लिए हमारा शब्द लेने की आवश्यकता नहीं है, यह सार्वजनिक रूप से हमारे मर्कल ट्री में उपलब्ध है)। अन्य दूतों के विपरीत, हम वास्तव में भयानक चेतावनी दिखा सकते हैं जब आप किसी ऐसे व्यक्ति से बात कर रहे हैं जिसने हाल ही में चाबियों को फिर से स्थापित किया है।

डिवाइस प्रबंधन एक जटिल इंजीनियरिंग ऑपरेशन है जिसे हमने कई बार परिष्कृत किया है। मौजूदा डिवाइस नए डिवाइस की सार्वजनिक कुंजी पर हस्ताक्षर करता है और नए डिवाइस की सार्वजनिक कुंजी के लिए सभी महत्वपूर्ण गुप्त डेटा को एन्क्रिप्ट करता है। यह ऑपरेशन जल्दी (एक सेकंड के भीतर) किया जाना चाहिए, क्योंकि हम उपयोगकर्ता के ध्यान की सीमा के बारे में बात कर रहे हैं। नतीजतन, कीबेस एक महत्वपूर्ण पदानुक्रम का उपयोग करता है, ताकि जब एक पुराने डिवाइस से गुप्त बाइट्स के 32 बाइट्स को स्थानांतरित किया जाए, तो नया डिवाइस सभी लंबे समय तक रहने वाले क्रिप्टोग्राफिक डेटा (अधिक विवरण के लिए नीचे FAQ देखें) देख सकता है। यह थोड़ा आश्चर्यजनक लग सकता है, लेकिन यह बिल्कुल क्रिप्टोग्राफी का बिंदु है । यह आपके रहस्यों के प्रबंधन की समस्याओं को हल नहीं करता है, यह सिर्फ सिस्टम को और अधिक स्केलेबल बनाता है।

सुरक्षा की पूरी तस्वीर

अब हम कीबेस एप्लीकेशन के लिए चार बुनियादी सुरक्षा गुण तैयार कर सकते हैं:

1. लंबे समय तक चलने वाली गुप्त कुंजियाँ उन उपकरणों को कभी नहीं छोड़ती हैं जिन पर वे बनाए जाते हैं
   
2. पूर्ण मल्टी-डिवाइस समर्थन खाता ड्रॉप्स को कम करता है
   
3. कुंजी निरसन दुर्भावनापूर्ण रूप से देरी या वापस लुढ़का नहीं जा सकता
   
4. पंचांग समय संदेशों का उपयोग करके प्रत्यक्ष गोपनीयता

पहले दो समझ में आते हैं। एक तीसरे डिजाइन में महत्वपूर्ण हो जाता है जहां डिवाइस को याद किया जाता है और सामान्य माना जाता है। सिस्टम में यह जांच होनी चाहिए कि दुर्भावनापूर्ण सर्वर डिवाइस समीक्षा में देरी नहीं कर सकते हैं, जो हमने पहले लिखा था ।

चौथी सुरक्षा सुविधा के बारे में अधिक जानकारी के लिए अल्पकालिक संदेश पर हमारा लेख देखें।

बहुत सारी नई क्रिप्टोग्राफी, क्या सब कुछ सही तरीके से लागू किया गया है?

कीबेस ने पहले कभी भी बुनियादी सुरक्षा कार्यों को लागू नहीं किया है और कभी भी इसे वैज्ञानिक लेखों में वर्णित नहीं किया है। हमें स्वयं कुछ क्रिप्टोग्राफिक प्रोटोकॉल का आविष्कार करना था। सौभाग्य से, किसी भी स्थिति के लिए बहुत सारे ऑफ-द-शेल्फ, मानकीकृत और व्यापक रूप से उपयोग किए जाने वाले क्रिप्टोग्राफ़िक एल्गोरिदम हैं । हमारा सभी क्लाइंट कोड खुला है । सैद्धांतिक रूप से, कोई भी डिज़ाइन या कार्यान्वयन त्रुटियां पा सकता है। लेकिन हम आंतरिक संरचना का प्रदर्शन करना चाहते थे और पूर्ण विश्लेषण के लिए सर्वश्रेष्ठ सुरक्षा ऑडिट फर्म को काम पर रखा था।

आज हम एनसीसी समूह की रिपोर्ट पेश करते हैं और परिणामों से बेहद प्रोत्साहित होते हैं। कीबेस ने ऑडिटिंग पर $ 100,000 से अधिक खर्च किया, और एनसीसी समूह ने शीर्ष-स्तरीय सुरक्षा और क्रिप्टोग्राफी विशेषज्ञों को काम पर रखा। उन्होंने हमारे कार्यान्वयन में दो महत्वपूर्ण त्रुटियां पाईं, और हमने जल्दी से उन्हें ठीक कर दिया। ये बग तभी सामने आ सकते हैं जब हमारे सर्वर दुर्भावनापूर्ण तरीके से काम करते हैं। हम आश्वस्त कर सकते हैं कि वे ऐसा कार्य नहीं करेंगे, लेकिन आपके पास हमारे विश्वास करने का कोई कारण नहीं है। यही बात है!

हमें विश्वास है कि एनसीसी टीम ने एक उत्कृष्ट कार्य किया है। उस समय के लिए सम्मान जब उन्होंने हमारी वास्तुकला और कार्यान्वयन को पूरी तरह से समझने के लिए खर्च किया। उन्होंने सूक्ष्म त्रुटियां पाईं जो हमारे डेवलपर्स का ध्यान आकर्षित करती हैं, हालांकि हमने हाल ही में कोड बेस के इस हिस्से को बार-बार देखा है। हम अनुशंसा करते हैं कि आप यहां रिपोर्ट देखें, या हमारे FAQ पर जाएं।

पूछे जाने वाले प्रश्न

आप एक XYZ उत्पाद पर हमला करने की हिम्मत कैसे करते हैं?

हमने पहले ही लेख से विशिष्ट उत्पादों के संदर्भ हटा दिए हैं।

और क्या?

हमें गर्व है कि कीबेस को फोन नंबरों की आवश्यकता नहीं है और अगर आप किसी को जानते हैं तो क्रिप्टोग्राफिक रूप से ट्विटर, हैकरन्यूज, रेडिट और जीथब आइडेंटिफायर्स की जांच कर सकते हैं।

और ... बहुत जल्द ... मस्तोडोन के लिए समर्थन होगा।

फोन पुनर्निर्देशित हमलों के बारे में क्या?

कई अनुप्रयोगों को पुनः निर्देशित हमलों के लिए अतिसंवेदनशील होते हैं। ईव एक शॉपिंग सेंटर में एक कियोस्क में चलता है और बॉब, मोबाइल ऑपरेटर को आश्वस्त करता है कि वह बॉब के फोन नंबर को अपने डिवाइस पर फॉरवर्ड करे। या वह फोन से प्रतिनिधि को मना लेती है। अब, ईव मैसेंजर सर्वर पर यह प्रमाणित कर सकता है कि वह बॉब है। परिणाम एलिस, बॉब और ईव के हमारे उदाहरण जैसा दिखता है, लेकिन ईव को किसी भी सर्वर को भेदने की आवश्यकता नहीं है। कुछ अनुप्रयोग इस हमले से बचाने के लिए "पंजीकरण अवरुद्ध" की पेशकश करते हैं, लेकिन डिफ़ॉल्ट रूप से वे कष्टप्रद होते हैं।

मैंने सुना है कि कीबेस सर्वर पर कुछ निजी कुंजी भेजता है?

शुरुआती दिनों (2014 और 2015 की शुरुआत) में, कीबेस ने PGP वेब एप्लिकेशन के रूप में काम किया, और उपयोगकर्ता अपने सर्वर पर अपनी निजी PGP कुंजियों को संग्रहीत करने के लिए फ़ंक्शन का चयन कर सकता था, पासफ़्रेज़ के साथ एन्क्रिप्ट किया गया था (जिसे कीबेस को पता नहीं था)।

सितंबर 2015 में, हमने नया कीबेस मॉडल पेश किया। Keybase चैट या फ़ाइल सिस्टम में PGP कुंजियों का उपयोग कभी नहीं किया जाता है (और कभी उपयोग नहीं किया जाता है)।

नए फ़ोन पर पुरानी चैट तुरंत कैसे दिखाई देती हैं?

कुछ अन्य अनुप्रयोगों में, नए डिवाइस पुराने संदेश नहीं देखते हैं, क्योंकि सर्वर के माध्यम से पुराने संदेशों को सिंक्रनाइज़ करना प्रत्यक्ष गोपनीयता के विपरीत है। कीबेस ऐप आपको कुछ संदेश - या संपूर्ण वार्तालाप - "पंचांग" के रूप में निर्दिष्ट करने की अनुमति देता है। उन्हें एक निश्चित समय के बाद नष्ट कर दिया जाता है और दो बार एन्क्रिप्ट किया जाता है: एक बार लंबे समय तक चैट एन्क्रिप्शन कुंजियों का उपयोग करने के बाद, और दूसरे में अक्सर बदल रही अल्पकालिक कुंजियों का उपयोग करके। इस प्रकार, पंचांग संदेश प्रत्यक्ष गोपनीयता प्रदान करते हैं और फोन के बीच सिंक्रनाइज़ नहीं किए जा सकते हैं।

गैर-अल्पकालिक संदेश तब तक बने रहते हैं जब तक उपयोगकर्ता स्पष्ट रूप से उन्हें हटा नहीं देता और E2E को नए स्लैक-शैली उपकरणों के साथ सिंक्रनाइज़ करता है, केवल एन्क्रिप्शन के माध्यम से! इसलिए, जब आप किसी टीम में किसी को जोड़ते हैं या अपने लिए एक नया उपकरण जोड़ते हैं, तो संदेश अनब्लॉक हो जाते हैं।

अगले पैराग्राफ में सिंक्रनाइज़ेशन पर अधिक।

PUKs के बारे में बताएं!

दो साल पहले, हमने उपयोगकर्ताओं (PUK) के लिए कुंजियाँ पेश कीं । PUK के सार्वजनिक आधे हिस्से को उपयोगकर्ताओं के सार्वजनिक सिगचिन में विज्ञापित किया गया है। प्रत्येक डिवाइस की सार्वजनिक कुंजी के लिए गुप्त आधा एन्क्रिप्ट किया गया है। जब ऐलिस एक नया उपकरण तैयार कर रही है, तो उसका पुराना उपकरण उसके PUK के गुप्त आधे हिस्से और नए उपकरण की सार्वजनिक कुंजी को जानता है। यह नए डिवाइस की सार्वजनिक कुंजी के लिए PUK के गुप्त आधे हिस्से को एन्क्रिप्ट करता है, और नया डिवाइस सर्वर के माध्यम से इस सिफरटेक्स्ट को डाउनलोड करता है। नया डिवाइस PUK को डिक्रिप्ट करता है और सभी लंबे समय तक चैट किए गए संदेशों को तुरंत एक्सेस कर सकता है।

जब भी ऐलिस किसी डिवाइस को याद करती है, तो वह अपना PUK बदल देती है, ताकि उसके सभी डिवाइस, सबसे हाल ही में वापस बुलाए गए, एक नया UUK प्राप्त करें।

यह तुल्यकालन योजना प्रारंभिक कीबेस पीजीपी प्रणाली से मूलभूत रूप से अलग है। यहां, शामिल सभी कुंजियों में 32 बाइट्स होती हैं, जो कि सही है। सच है, अगर कर्व 2525 या गो से PRNG टूट गया है, तो सब कुछ टूट जाता है। लेकिन PUK सिंक्रोनाइज़ेशन कोई अन्य महत्वपूर्ण क्रिप्टोग्राफ़िक धारणा नहीं बनाता है।

बड़े समूह चैट के बारे में क्या?

टीएल; ड्र ग्रुप्स की सदस्यों को बदलने, जोड़ने और हटाने के लिए अपनी स्वयं की ऑडिट की गई हस्ताक्षर श्रृंखलाएं हैं।

सुरक्षा शोधकर्ताओं ने समूह चैट पर प्रेत उपयोगकर्ता हमलों के बारे में लिखा । यदि उपयोगकर्ता के ग्राहक समूह सदस्यता की क्रिप्टोग्राफिक रूप से सत्यापित करने में सक्षम नहीं हैं, तो दुर्भावनापूर्ण सर्वर समूह चैट में स्पाइवेयर और मोल्स को एम्बेड कर सकते हैं। कीबेस के पास समूहों के एक विशेष कार्य के रूप में एक बहुत ही विश्वसनीय प्रणाली है, जिसके बारे में हम भविष्य में लिखेंगे।

क्या आप NCC-KB2018-001 के बारे में बात कर सकते हैं?

हम मानते हैं कि यह बग एनसीसी ऑडिट का सबसे महत्वपूर्ण खोज है। कीबेस सक्रिय रूप से परिशिष्ट से सर्वर अस्पष्टता के खिलाफ की रक्षा के लिए अपरिवर्तनीय डेटा संरचनाओं का उपयोग करता है। बग के मामले में, एक ईमानदार सर्वर बाहर निकलना शुरू हो सकता है: "मैंने आपको पहले कहा था, लेकिन एक बग हुआ, मेरा मतलब बी था"। लेकिन हमारे ग्राहकों की एक सामान्य नीति है कि सर्वर को इस तरह के लचीलेपन की अनुमति न दें: बग के मामले में उनके पास हार्ड-कोडित अपवाद हैं।

हाल ही में, हमने सिगचैन वी 2 भी पेश किया: यह प्रणाली स्केलेबिलिटी की समस्याओं को हल करती है जिसे हमने पहले संस्करण में सही ढंग से भविष्यवाणी नहीं की थी। अब ग्राहक क्रिप्टोग्राफिक डेटा के साथ अधिक किफायती हैं जो वे सर्वर से खींचते हैं, प्रत्येक मध्यवर्ती लिंक के हस्ताक्षर के बजाय हस्ताक्षर श्रृंखला की पूंछ से केवल एक हस्ताक्षर प्राप्त करते हैं। इस प्रकार, ग्राहकों ने एक विशिष्ट हस्ताक्षर हैश की खोज में चक्र में जाने का अवसर खो दिया है, लेकिन हमने पहले हार्ड-कोडित अपवादों की इस सूची में खराब चेनलिंक्स की खोज करने के लिए इन हैश का उपयोग किया था। हम सिगचैन V2 की रिहाई के लिए तैयारी कर रहे थे, अमूर्त की कई परतों के नीचे दफन इस विस्तार के बारे में भूल गए, इसलिए सिस्टम ने बस सर्वर प्रतिक्रिया से क्षेत्र पर भरोसा किया।

एक बार जब एनसीसी ने इस त्रुटि का पता लगाया, तो यह फिक्सिंग काफी सरल थी: एक चेनलिंक हैश के बजाय हार्ड-कोडित अपवादों की तलाश करना। क्लाइंट हमेशा इन हैश की सीधे गणना कर सकता है।

हम इस त्रुटि को सिगचैन वी 1 और सिगचिन वी 2 को एक साथ समर्थन करने के लिए आवश्यक अतिरिक्त जटिलता का भी श्रेय दे सकते हैं। आधुनिक ग्राहक सिगचैन V2 लिंक लिखते हैं, लेकिन सभी ग्राहकों को असीमित समय के लिए विरासत v1 लिंक का समर्थन करना चाहिए। याद रखें कि ग्राहक प्रत्येक डिवाइस के लिए अपनी निजी कुंजी के साथ लिंक पर हस्ताक्षर करते हैं। हम सभी ग्राहकों को उचित समय में ऐतिहासिक डेटा अधिलेखित नहीं कर सकते, क्योंकि ये ग्राहक बस ऑफ़लाइन हो सकते हैं।

क्या आप NCC-KB2018-004 के बारे में बात कर सकते हैं?

001 (ऊपर देखें) के रूप में, हमें पुराने समाधानों और अनुकूलन के लिए एक साथ समर्थन के एक निश्चित संयोजन के द्वारा नीचे दिया गया था, जो महत्वपूर्ण लग रहा था क्योंकि हमने सिस्टम के साथ काम करने का अधिक अनुभव प्राप्त किया।

सिगचैन वी 2 में, हम उपयोगकर्ताओं को खोजने के लिए आवश्यक बैंडविड्थ को कम करने के लिए बाइट्स में चेन के आकार को कम करते हैं। यह बचत मोबाइल फोन पर विशेष रूप से महत्वपूर्ण है। इस प्रकार, हम मैसेजपैक के साथ चेनलिंक को एनकोड करते हैं, न कि JSON को , जो अच्छी बचत देता है। बदले में, ग्राहक इन श्रृंखलाओं पर हस्ताक्षर करते हैं और हस्ताक्षर करते हैं। एनसीसी के शोधकर्ताओं ने "हस्ताक्षर" बनाने के लिए ट्रिकी तरीके खोजे हैं जो एक ही समय में JSON और MessagePack की तरह दिखते हैं, जिससे संघर्ष होता है। जब हमने JSON पार्सर्स को मानक गो पार्सर से अधिक कुशल एक में बदल दिया, तो हमने अनपेक्षित रूप से अनुकूलन के दौरान डिकोडिंग की इस अस्पष्टता को पेश किया। इस तेज पार्सर ने वास्तविक JSON को खोजने से पहले चुपचाप कचरे का एक गुच्छा छोड़ दिया, जिसमें इस पॉलीग्लॉट अटैक फीचर को शामिल किया गया था। त्रुटि अतिरिक्त इनपुट सत्यापन द्वारा तय की गई है।

सिगचैन वी 2 में, हमने एडम लैंगली के सुझाव को भी स्वीकार कर लिया है कि हस्ताक्षरकर्ता अपने पैकेज को संदर्भ लाइन उपसर्ग और बाइट \0 से हस्ताक्षरित करते हैं ताकि सत्यापनकर्ता हस्ताक्षरकर्ता के इरादों से भ्रमित न हों। इस संदर्भ-उपसर्ग विचार के सत्यापन पक्ष में, ऐसी त्रुटियां थीं जो अन्य बहुभुज हमलों को जन्म दे सकती थीं। हमने जल्दी से एक श्वेतसूची के साथ इस दोष को ठीक किया।

दोनों बग को ठीक करने के बाद, सर्वर पॉलीग्लॉट अटैक के दुर्भावनापूर्ण भार को अस्वीकार कर देता है, इसलिए इन कमजोरियों का शोषण केवल एक समझौता किए गए सर्वर की मदद से संभव है।

दस्तावेज कहां है?

https://keybase.io/docs

आने वाले महीनों में, हम प्रलेखन पर काम करने के लिए अधिक समय समर्पित करेंगे।

आप एनसीसी के इस कथन के बारे में अधिक बता सकते हैं: "हालांकि, एक हमलावर सिगचिन को अपडेट करने से इनकार करने या किसी उपयोगकर्ता के सिगचिन को पिछली स्थिति में वापस करने के लिए श्रृंखला में बाद के लिंक को छोटा करके सक्षम करता है"

Keybase अपरिवर्तनीय परिशिष्ट-केवल सार्वजनिक डेटा संरचनाओं का व्यापक उपयोग करता है जो उपयोगकर्ता पहचानकर्ताओं के एक सच्चे प्रतिनिधित्व को पकड़ने के लिए सर्वर के बुनियादी ढांचे को मजबूर करता है। हम उपकरणों को वापस बुलाने और समूह के सदस्यों को इस तरह से हटाने की गारंटी दे सकते हैं कि एक समझौता किया हुआ सर्वर वापस नहीं आ सकता है। यदि सर्वर असंगत दृश्य दिखाने का निर्णय लेता है, तो यह विचलन अपरिवर्तनीय सार्वजनिक रिकॉर्ड का हिस्सा बन जाता है। कीबेस के ग्राहक या तीसरे पक्ष के ऑडिटर हमले के बाद किसी भी समय एक बेमेल का पता लगा सकते हैं। हम मानते हैं कि ये गारंटी प्रतिस्पर्धी उत्पादों की गारंटी से कहीं अधिक हैं और लगभग इष्टतम हैं, जो मोबाइल फोन और ग्राहकों की व्यावहारिक कंप्यूटिंग शक्ति की व्यावहारिक सीमाओं को ध्यान में रखते हैं।

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

कीबेस हैंडल अकाउंट रीसेट कैसे करता है?

जब कीबेस उपयोगकर्ता वास्तव में अपने सभी उपकरणों को खो देते हैं (जैसा कि नए को जोड़ने या कुछ खोने का विरोध किया जाता है), उन्हें रीसेट करने की आवश्यकता होती है। खाता रीसेट करने के बाद, उपयोगकर्ता मूल रूप से नया है, लेकिन उसके पास एक ही उपयोगकर्ता नाम है। वह "रीसेट निर्देश" पर हस्ताक्षर नहीं कर सकता क्योंकि उसने अपनी सभी चाबियाँ खो दी हैं। इसलिए इसके बजाय, कीबेस सर्वर मैर्कल ट्री के लिए नॉन-इरेज़ेबल स्टेटमेंट देता है, जिसका अर्थ है रीसेट। ग्राहक इन निर्देशों को वापस करने की असंभवता पर बल देते हैं। भविष्य के लेख में, विशिष्ट तंत्रों का विस्तार से वर्णन किया जाएगा।

इस उपयोगकर्ता को नई कुंजियों के साथ पहचान सत्यापन (ट्विटर, जीथब, जो भी हो) को फिर से जोड़ना होगा।

क्या कोई सर्वर बस किसी की मर्कल ट्री लीव को स्वैप कर सकता है जो चाबियों के एक पूरी तरह से अलग सेट का विज्ञापन कर सकता है?

एनसीसी लेखक एक शत्रुतापूर्ण कीबेस सर्वर पर विचार कर रहे हैं जो पूरी तरह से नए नकली सेट के साथ बॉब के असली कुंजी सेट की जगह, मर्कल ट्री लीफ को पूरी तरह से बदल देता है। एक हमलावर सर्वर में दो विकल्प होते हैं। सबसे पहले, वह बॉब को एक कांटे में रखकर दुनिया की स्थिति को कांटा सकता है, और जिन्हें वह दूसरे में मूर्ख बनाना चाहता है। दूसरे, वह नकली कुंजी के साथ बॉब कुंजी और अन्य संस्करणों के सही सेट के साथ मर्कल ट्री के एक संस्करण को प्रकाशित करके "धोखा" दे सकता है। उपयोगकर्ता जो बॉब के साथ नियमित रूप से बातचीत करते हैं, वे इस हमले का पता लगा लेंगे, क्योंकि वे सत्यापित करेंगे कि बॉब के इतिहास के पहले डाउनलोड किए गए संस्करण नए संस्करणों के मान्य उपसर्ग हैं जो वे सर्वर से डाउनलोड करते हैं। तृतीय-पक्ष सत्यापनकर्ता जो सभी कीबेस अपडेट स्कैन करते हैं, इस हमले को भी नोटिस करेंगे। यदि आप एक तृतीय-पक्ष कीबेस सत्यापनकर्ता लिखते हैं जो हमें पसंद है, तो हम एक महत्वपूर्ण इनाम की पेशकश कर सकते हैं। Keybase पर max संदर्भ लें। अन्यथा, हम जल्द ही एक स्वायत्त सत्यापनकर्ता के निर्माण की योजना बनाने की उम्मीद करते हैं।

क्या आप विश्वास कर सकते हैं कि मैंने आखिर क्या पढ़ा?

पढ़ें या बस नीचे स्क्रॉल करें?