AES-GCM किसी संदेश की गोपनीयता की रक्षा कर सकता है और अनधिकृत बदलाव पकड़ सकता है। अपने-आप वह प्राप्तकर्ता को यह नहीं बताता कि अन्यथा वैध संदेश पहले ही प्रोसेस किया जा चुका है या नहीं।
तीन आवश्यकताओं में आसानी से भ्रम हो सकता है: एन्क्रिप्शन के लिए अद्वितीय कुंजी/nonce जोड़े, संदेश और उसके संदर्भ का प्रमाणीकरण, और प्रोटोकॉल स्तर पर रीप्ले का प्रबंधन। HKDF कुंजियाँ व्युत्पन्न करने में मदद कर सकता है, लेकिन अपने-आप तीनों आवश्यकताएँ पूरी नहीं करता।
nonce का दोबारा उपयोग और रीप्ले अलग घटनाएँ हैं
| घटना | क्या होता है | आवश्यक सुरक्षा |
|---|---|---|
| एन्क्रिप्शन के दौरान nonce का दोबारा उपयोग | अलग प्लेनटेक्स्ट उसी GCM कुंजी और nonce से एन्क्रिप्ट होते हैं | कुंजी/nonce आवंटन की विश्वसनीय रणनीति |
| छेड़छाड़ | सिफरटेक्स्ट या प्रमाणित संदर्भ बदला जाता है | प्रमाणित डिक्रिप्शन और विफलता पर अस्वीकृति |
| रीप्ले | पहले वैध रहा एन्क्रिप्टेड संदेश फिर पहुँचाया जाता है | डुप्लिकेट या पुराने संदेश पहचानने वाली स्थिति और एप्लिकेशन नियम |
| क्रम बदलना | वैध संदेश अलग क्रम में पहुँचते हैं | प्रोटोकॉल द्वारा निर्धारित क्रम और सीमित दायरे में क्रम से बाहर संदेशों का प्रबंधन |
दोबारा पहुँचाए गए सिफरटेक्स्ट का प्रमाणीकरण टैग अब भी वैध हो सकता है। कुछ बदला ही नहीं। इसलिए यह कहना गलत है कि हर डुप्लिकेट अपने-आप AES-GCM प्रमाणीकरण में विफल हो जाता है। RFC 5116 AEAD इंटरफ़ेस को रीप्ले-रोधी सेवाओं से स्पष्ट रूप से अलग करता है।
कुंजी और nonce का जोड़ा दोहराना क्यों नहीं चाहिए
GCM के nonce का गुप्त होना जरूरी नहीं, लेकिन उसे किसी दी गई कुंजी के अंतर्गत योजना की अद्वितीयता संबंधी आवश्यकताएँ पूरी करनी चाहिए। 96-बिट, यानी 12-बाइट nonce आम है; यह लंबाई चुनना सही जनरेशन की गारंटी नहीं है।
अलग प्लेनटेक्स्ट के लिए उसी कुंजी और nonce का दोबारा उपयोग करने से एन्क्रिप्शन की कीस्ट्रीम दोहरती है और प्लेनटेक्स्ट के बीच संबंध उजागर होते हैं। इससे प्रामाणिकता भी कमजोर हो सकती है और जालसाजी संभव हो सकती है। प्रभाव गंभीर है, लेकिन इसे हर पुरानी कुंजी या खाते के हर संदेश के अपने-आप उजागर होने के रूप में नहीं बताना चाहिए। प्रभावित दायरा दोबारा इस्तेमाल हुई कुंजी और प्रोटोकॉल पर निर्भर करता है।
NIST SP 800-38D GCM और उसकी आवश्यकताओं को परिभाषित करता है। कार्यान्वयन को लागू इनवोकेशन सीमाओं और nonce जनरेशन नियमों का पालन करना चाहिए, न कि “इतने संदेशों तक सुरक्षित” जैसे सरल अनुमान का।
HKDF क्या योगदान देता है
RFC 5869 में परिभाषित HKDF एक्सट्रैक्ट और एक्सपैंड चरणों से इनपुट गुप्त सामग्री से कुंजी सामग्री व्युत्पन्न करता है। प्रोटोकॉल अलग उद्देश्यों की कुंजियाँ अलग रखने के लिए संदर्भ लेबल और अलग इनपुट इस्तेमाल कर सकते हैं।
HKDF निर्धारक है। अगर क्रैश हुआ या पुरानी स्थिति में लौटाया गया क्लाइंट वही स्थिति और इनपुट दोहराता है, तो वह फिर वही आउटपुट निकाल सकता है। इसलिए डिजाइन में HKDF जोड़ने से nonce का दोबारा उपयोग असंभव नहीं हो जाता।
हर संदेश की अलग कुंजी किसी एक कुंजी के अंतर्गत सुरक्षित सामग्री की मात्रा घटा सकती है, लेकिन स्थिति को सुरक्षित रूप से आगे बढ़ाना, कुंजी पृथक्करण और मिटाना फिर भी जरूरी हैं। वास्तव में अलग कुंजियों के अंतर्गत वही nonce मान इस्तेमाल करना कुंजी/nonce जोड़ा दोहराने जैसी विफलता नहीं है; प्रोटोकॉल को स्थापित करना चाहिए कि कुंजियाँ सचमुच अलग हैं।
रीप्ले सुरक्षा प्रोटोकॉल की जिम्मेदारी है
प्राप्तकर्ता संदेश पहचानकर्ता, अनुक्रम में स्थान, सत्र युग या इस्तेमाल हो चुकी ratchet कुंजियों का रिकॉर्ड रख सकता है। संबंधित फ़ील्ड प्रमाणित होने चाहिए ताकि हमलावर पुराने संदेश को नया लेबल न दे सके।
इसके बाद एप्लिकेशन को तय करना चाहिए कि डुप्लिकेट का अर्थ क्या है। चैट का दोहरा बबल दिखना असुविधाजनक है; वही कार्य दो बार करना अधिक गंभीर हो सकता है। नेटवर्क पर दोबारा प्रयास सामान्य हैं, इसलिए क्रिप्टोग्राफिक जाँचों के साथ अक्सर आइडेम्पोटेंट प्रोसेसिंग भी जरूरी होती है।
हर वैध संदेश के बिल्कुल क्रम में पहुँचने की शर्त न रखें, जब तक प्रोटोकॉल ऐसा व्यवहार निर्धारित न करे। मोबाइल क्लाइंट नियमित रूप से दोबारा जुड़ते हैं, पुनः प्रयास करते हैं और देर से आए संदेश प्राप्त करते हैं। सुरक्षित प्रबंधन वैध देर से आए संदेश को पहले इस्तेमाल हो चुके या गलत संदर्भ वाले संदेश से अलग पहचानता है।
सुरक्षा का दावा करने से पहले क्या जाँचें
- nonce आवंटित करने के बाद, लेकिन भेजने का रिकॉर्ड लिखने से पहले रीस्टार्ट करें: क्या आवंटन दोहर सकता है?
- स्थिति का पुराना स्नैपशॉट बहाल करें: क्या कुंजियाँ, काउंटर या रीप्ले रिकॉर्ड पीछे लौट सकते हैं?
- दो वर्कर या डिवाइस से एक साथ भेजें: क्या उनके कुंजी/nonce डोमेन अलग हैं?
- वही वैध संदेश दो बार पहुँचाएँ: क्या एप्लिकेशन का कार्य एक बार होता है?
- सत्र पहचानकर्ता या हेडर बदलें: क्या संदर्भ क्रिप्टोग्राफिक रूप से बँधा है?
- वैध संदेश क्रम से बाहर पहुँचाएँ: क्या समर्थित देरी को पुरानी स्थिति स्वीकार किए बिना संभाला जाता है?
प्रमाणित डिक्रिप्शन API को सफल सत्यापन के बाद ही एप्लिकेशन को प्लेनटेक्स्ट लौटाना चाहिए। यह इंटरफ़ेस की आवश्यकता है; यह दावा नहीं कि कोई भी कार्यान्वयन कभी अंदर अस्थायी प्लेनटेक्स्ट बफ़र की गणना नहीं करता।
Livara के दावों को सही तरह पढ़ना
Livara का सुरक्षा दस्तावेज़ AES-256-GCM, प्रति-संदेश चेन और LVR1/LGS1 संदर्भ का नाम लेता है। ये मूल क्रिप्टोग्राफिक घटक अपने-आप सही क्रैश रिकवरी, nonce आवंटन या रीप्ले अस्वीकृति सिद्ध नहीं करते। ऐसे दावों के लिए संस्करण-विशिष्ट प्रोटोकॉल विवरण और परीक्षण के प्रमाण चाहिए।
मजबूत डिजाइन हर काम स्पष्ट रूप से बाँटता है: कुंजी व्युत्पत्ति इच्छित कुंजियाँ बनाती है, AEAD सामग्री और संदर्भ प्रमाणित करता है, और स्थिति रखने वाला प्रोटोकॉल लॉजिक तय करता है कि वैध संदेश अभी स्वीकार्य है या नहीं।
