प्रमाणीकरण टोकन एन्क्रिप्टेड है लेकिन हस्ताक्षरित नहीं - कमजोरी?

Question

सालों से मैं इस परिदृश्य में एक से अधिक बार आया हूं। आपके पास उपयोगकर्ता से संबंधित डेटा का एक गुच्छा है जिसे आप एक एप्लिकेशन से दूसरे एप्लिकेशन में भेजना चाहते हैं। दूसरे एप्लिकेशन से "टोकन" पर भरोसा करने की उम्मीद है और इसके भीतर डेटा का उपयोग करें। एक चोरी/पुन: उपयोग हमले को रोकने के लिए टोकन में एक टाइमस्टैम्प शामिल किया गया है। किसी भी कारण से (चलिए इसके बारे में चिंता न करें) एसएएमएल जैसे उद्योग मानक के बजाय एक कस्टम समाधान चुना गया है।

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

लेकिन जो कुछ मैं देखता हूं वह यह है कि डेवलपर सममित एन्क्रिप्शन का उपयोग करेंगे, उदाहरण के लिए एईएस। वे मानते हैं कि डेटा "गुप्त" बनाने के अलावा, एन्क्रिप्शन भी 1) संदेश अखंडता प्रदान करता है और 2) ट्रस्ट (स्रोत का प्रमाणीकरण)।

क्या मुझे संदेह है कि यहां एक निहित कमजोरी है? फेस वैल्यू पर यह काम करता प्रतीत होता है, अगर सममित कुंजी ठीक से प्रबंधित की जाती है। उस कुंजी की कमी, मैं निश्चित रूप से नहीं जानता कि एन्क्रिप्टेड टोकन को कैसे संशोधित करें, या कई टोकन को अवरुद्ध करने के बाद किसी प्रकार का क्रिप्टोग्राफिक हमला शुरू करें। लेकिन क्या एक अधिक परिष्कृत हमलावर यहां कुछ शोषण करने में सक्षम होगा?

Answer 1

इसका हिस्सा एन्क्रिप्शन मोड पर निर्भर करता है। यदि आप ईसीबी (आप पर शर्मिंदा हैं!) मैं संदेश को बदलने, चारों ओर ब्लॉक स्वैप कर सकता था। Stackoverflow got hit by this very bug।

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

यदि आप यह सुनिश्चित करें कि एक हमलावर जो अपने मैक के लिए उपयोग नहीं है कर सकते हैं कुंजी कभी कोड की एक ब्लॉक करने के लिए बुराई इनपुट फ़ीड नहीं कर सकते हैं, हालांकि, आप नाटकीय रूप से मौका है कि वह किसी भी कीड़े

Answer 2

एक सममित एन्क्रिप्शन दृष्टिकोण कुंजी के रूप में सुरक्षित है। यदि दोनों प्रणालियों को कुंजी दी जा सकती है और कुंजी को सुरक्षित रूप से पकड़ लिया जा सकता है, तो यह ठीक है। सार्वजनिक कुंजी क्रिप्टोग्राफी निश्चित रूप से एक अधिक प्राकृतिक फिट है।

Answer 3

हाँ फायदा उठाने में सक्षम हो जाएगा को कम । अकेले एन्क्रिप्शन प्रमाणीकरण प्रदान नहीं करता है। यदि आप प्रमाणीकरण चाहते हैं तो आपको एक संदेश प्रमाणीकरण कोड जैसे एचएमएसी या डिजिटल हस्ताक्षर (अपनी आवश्यकताओं के आधार पर) का उपयोग करना चाहिए।

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

संदेश के अन्य ब्लॉकों भी हेरफेर किया जा सकता है, हालांकि यह एक छोटे से जटिल काम है। ध्यान दें, कि यह केवल सीबीसी की कमजोरी नहीं है। ओएफबी जैसे अन्य तरीके, सीएफबी की समान कमजोरियां हैं। तो उम्मीद एन्क्रिप्शन अकेले में प्रावधान है कि प्रमाणीकरण सिर्फ एक बहुत ही खतरनाक धारणा