किसी को एन्क्रिप्टेड समूह से हटाने पर उसे भविष्य के सुरक्षित संदेशों के लिए जरूरी गुप्त जानकारी मिलना बंद होना चाहिए। यदि बाकी प्रेषक वही कुंजी सामग्री इस्तेमाल करते रहें जिसे पूर्व सदस्य पहले से जानता है, तो केवल सदस्य सूची बदलने से यह लक्ष्य पूरा नहीं होता।
अविश्वसनीय नेटवर्क पर यह परिवर्तन हर जगह तत्काल भी नहीं होता। सुरक्षित समूह डिज़ाइन को तय करना चाहिए कि संदेश किस सदस्यता अवस्था का है और हटाने की प्रक्रिया पूरी करने से पहले प्रेषक क्या करता है।
पुराने और भविष्य के संदेश अलग समस्याएं हैं
पूर्व सदस्य अपने अधिकृत रहने के दौरान मिले संदेश, फ़ाइलें और कुंजियां रख सकता है। हटाने से वह व्यक्ति इतिहास भूल नहीं सकता और उसके स्क्रीनशॉट मिट नहीं जाते।
संभव लक्ष्य उसे हटाना प्रभावी होने के बाद की नई क्रिप्टोग्राफिक अवस्था से बाहर रखना है। इसी तरह, किसी को जोड़ने पर अलग सवाल उठता है: क्या उसे पुराने इतिहास तक पहुंच मिलती है? उत्पाद और प्रोटोकॉल फॉरवर्ड सीक्रेसी जैसे शब्द अलग संदर्भों में इस्तेमाल करते हैं, इसलिए अस्पष्ट लेबल की तुलना में इच्छित पहुंच नियम का सीधा वर्णन अक्सर अधिक स्पष्ट होता है।
प्रेषक-कुंजी वाले समूहों को नई अवस्था क्यों चाहिए
प्रेषक-कुंजी डिज़ाइन में हर भागीदार अनुमत प्राप्तकर्ताओं के साथ साझा चेन से सामान्य समूह संदेश एन्क्रिप्ट कर सकता है। इससे हर बार भेजते समय हर प्राप्तकर्ता के लिए पूरे कंटेंट को अलग से एन्क्रिप्ट करने की जरूरत टल सकती है।
हटाने के बाद भी पूर्व सदस्य के पास पुरानी चेन हो सकती है। इसलिए बाकी प्रेषकों को नई प्रतिस्थापन अवस्था चाहिए जो बाहर किए गए सदस्य को न दी जाए, और क्लाइंट को उसे इस्तेमाल करने के लिए सहमत सदस्यता संदर्भ चाहिए। बदलाव में सभी संबंधित प्रेषक और उपकरण शामिल होने चाहिए; सर्वर का एक फ़्लैग बदलना पर्याप्त नहीं है।
सटीक प्रोटोकॉल महत्वपूर्ण है। RFC 9420 में निर्दिष्ट MLS हटाने को कमिट किए गए एपक परिवर्तन के जरिए संभालता है, जो बचे सदस्यों को नई एंट्रॉपी देता है। यह परिभाषित अवस्था परिवर्तन का उदाहरण है, न कि दावा कि Livara MLS लागू करता है।
Livara LGS1 के बारे में क्या दस्तावेज़ित करता है
Livara का सुरक्षा पृष्ठ हर प्रेषक के लिए एक हस्ताक्षरित प्रेषक चेन बताता है, जिसमें प्रेषक कुंजियां जोड़ीवार LVR1 सत्रों के जरिए बांटी जाती हैं। उसमें कहा गया है कि सदस्यता बदलने पर नई प्रेषक कुंजियां बनाई और वितरित की जाती हैं।
यह प्रकाशित कुंजी नवीकरण डिज़ाइन के बारे में दावे का समर्थन करता है। इससे मापा हुआ “तत्काल निरस्तीकरण” समय स्थापित नहीं होता और न यह सिद्ध होता है कि हर रेस कंडीशन, ऑफ़लाइन उपकरण की परिस्थिति और पुनः प्रयास सही संभाला जाता है। इनके लिए कार्यान्वयन का विश्लेषण और परीक्षण आवश्यक है।
सर्वर-पक्ष सदस्यता नियंत्रण और क्रिप्टोग्राफिक बहिष्करण के काम भी अलग हैं। सेवा डिलीवरी या पहुंच रोक सकती है, जबकि एन्क्रिप्शन को सुनिश्चित करना चाहिए कि बाहर किए गए पक्ष के पास बाद के साइफ़रटेक्स्ट की प्रति हो, तब भी वह नई गुप्त जानकारी के बिना उसे खोल न सके।
हटाने की उपयोगी परीक्षण योजना
अधिकृत परीक्षण समूह में गैर-संवेदनशील संदेशों से इन स्थितियों की जांच करें:
| स्थिति | वह सवाल जिसका उत्तर मिलना चाहिए |
|---|---|
| सभी ऑनलाइन हों और सदस्य हटाया जाए | नई सदस्यता अवस्था के अंतर्गत पहला संदेश कौन-सा है? |
| बचा हुआ कोई प्रेषक ऑफ़लाइन हो | क्या उसे फिर भेजने से पहले सदस्यता और कुंजियां अपडेट करनी होंगी? |
| हटाया गया सदस्य बाद में फिर जुड़े | क्या उसे नई प्रेषक-कुंजी वितरण मिल सकते हैं या केवल पुरानी अधिकृत सामग्री? |
| कई सदस्य एक साथ बदलें | क्या सभी बचे उपकरण एक ही अवस्था पर पहुंचते हैं? |
| पुराना संदेश दोबारा भेजने की कोशिश हो | क्या उसे नया कंटेंट बताने की बजाय उसका मूल एपक सुरक्षित रखा जाता है? |
केवल UI का परीक्षण दिखने वाले व्यवहार की पुष्टि कर सकता है, लेकिन अकेले उससे क्रिप्टोग्राफिक बहिष्करण सिद्ध नहीं होता। कठोर मूल्यांकन में देखना होगा कि बाहर किया गया परीक्षण उपकरण कौन-सी कुंजियां और साइफ़रटेक्स्ट प्राप्त कर सकता है।
प्रशासकों को क्या याद रखना चाहिए
अनावश्यक भागीदार हटाएं, बचे सदस्यों की समीक्षा करें और ऐप के बदलाव संसाधित करने तक नई संवेदनशील सामग्री भेजने से बचें। यदि वर्तमान भागीदार जानबूझकर सामग्री आगे भेजता है, तो समूह की कुंजियां बदलना उस खुलासे को रोक नहीं सकता।
अत्यधिक संवेदनशील उपयोग के लिए प्रदाता से हटाने का सटीक अर्थ, उपकरण निरस्तीकरण का व्यवहार और परीक्षण प्रमाण पूछें। महत्वपूर्ण वादा भविष्य के संदेशों के लिए स्पष्ट सीमा है, न कि निराधार दावा कि हटाने का बटन हर पुरानी प्रति नष्ट कर देता है।
