सीमित एम्बेडेड सिस्टम के बीच संचार सुरक्षित करना

Question

मैं वर्तमान में एक एम्बेडेड सिस्टम पर एक सीमित भौतिक संचार चैनल पर संचार को सख्त करने की कोशिश कर रहा हूं।

परिदृश्य

मुझे लगता है कि सिस्टम छोटे एम्बेडेड अनुप्रयोगों के लिए विशिष्ट है:

• शामिल एम्बेडेड सिस्टम बिना किसी ओएस के छोटे माइक्रोकंट्रोलर हैं, जिन्हें सुरक्षित भौतिक वातावरण में माना जा सकता है। कनेक्शन चैनल हमलावरों के लिए शारीरिक रूप से सुलभ है, वे वांछित संदेशों के साथ हस्तक्षेप कर सकते हैं।

• विभिन्न संचार चैनल संभव हैं: उदाहरण के लिए RS485 या RS232। एक क्रूड प्रोटोकॉल है जो एड्रेसिंग और क्रूड इंटीग्रेशन (जैसे CRC16 बिटफ्लिप्स के लिए) जैसे सामान को हैंडल करता है, जिस पर हम निर्माण कर सकते हैं। इसे धीमे टीसीपी होने के रूप में सोचें।

• प्रत्येक संचार भागीदार एक रूट प्रमाणपत्र जानता है जो सीए के रूप में कार्य कर सकता है और उसके पास स्वयं का एक अद्वितीय प्रमाणपत्र (+ कुंजी) है। प्रमाण पत्र स्व-हस्ताक्षरित, अण्डाकार वक्र प्रधानमंत्री 256v1 हैं

• इन सिस्टमों के लिए mbedTLS लाइब्रेरी उपलब्ध है (डीएच, एईएस, के साथ)।

• अधिकांश समय इंटरनेट उपलब्ध नहीं है।

• सिस्टम समय रख सकते हैं और पर्याप्त यादृच्छिक संख्या बना सकते हैं

मैं गोपनीयता, प्रामाणिकता और अखंडता तक पहुंचना चाहता हूं।

इसे कैसे हल किया जा सकता है

क्रिप्टोग्राफ़िक प्रोटोकॉल में एक नियम यह है कि उन्हें कभी भी अपने दम पर लागू न करें। दुर्भाग्य से मुझे ऐसा कुछ भी नहीं मिला जो इस उपयोग के मामले से मेल खाता हो।

मैं मौजूदा सवालों से भी रूबरू हुआ, लेकिन कुछ भी नहीं दिया जो पूरा समाधान मुझे खोज रहा था।

अंत में इस उत्तर में अंतिम विकल्प के रूप में स्वयं के प्रोटोकॉल को लागू किया जाता है।

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

सुरक्षित संचार के लिए प्रोटोकॉल

पहली बात यह है कि बेतरतीब ढंग से एक सममित कुंजी उत्पन्न करने के लिए है। पहली बात यह है कि एक हाथ मिलाना संदेश है। इसके निम्नलिखित क्षेत्र हैं:

खेत	विवरण
डीएच	डिफी-हेलमैन कुंजी विनिमय संदेश जी के
सर्टिफिकेट	भेजने वाले उपकरण का प्रमाण पत्र (-चैन)
MsgIdNonce	एक यादृच्छिक 64-बिट मान
हस्ताक्षर	प्रमाणपत्र की निजी कुंजी का उपयोग करके पूर्ण संदेश का एक हस्ताक्षर

दोनों डिवाइस ऐसा संदेश भेजते हैं (प्राप्त करते हैं)।

जब एक संदेश प्राप्त होता है, तो निम्नलिखित किया जाता है:

1. जाँच करें कि क्या अपेक्षित सीए द्वारा प्रमाण पत्र पर हस्ताक्षर किए गए हैं (चेन में होना है)
2. जांचें कि क्या msg को प्रमाणित और उसकी कुंजी के साथ ठीक से हस्ताक्षरित किया गया है

जब ये चेक भेजे गए और प्राप्त किए गए डीएच जी ^के संदेशों को एक सममित कुंजी की गणना करने के लिए उपयोग किया जाता है।

इस बिंदु से, अनुप्रयोग एईएस-सीबीसी के साथ एन्क्रिप्टेड संदेश भेज सकते हैं। जैसा कि संदेश अपेक्षाकृत अक्सर खो सकते हैं, IV संदेश में हमेशा होता है।

यह संदेश प्रारूप है:

खेत	विवरण	को गोपित
IV	एईएस के लिए प्रारंभिक रैंडम IV	नहीं न
MsgIdNonce	हैंडशेक / अंतिम MsgIdNonce + 1 या + 2	हाँ
अनुप्रयोग डेटा	डेटा / सुरक्षा के लिए आदेश	हाँ
CMAC 64 बिट में विभाजित हो गया	अखंडता की जाँच के लिए एमएसी	हाँ

एक संदेश के लिए इसे स्वीकार किया जाना चाहिए

1. MsgIdNonce (1 या 2 ऊपर अंतिम प्राप्त एक) की उम्मीद है - फिर से खेलना हमलों को रोकने, 1 संदेश खोने की अनुमति
2. मान्य CMAC है - अखंडता पर हमलों को रोकने
3. अधिकतम प्राप्त किया जाए। अंतिम संदेश के बाद टी सेकंड - देरी के हमलों को रोकना

यदि कुछ भी उम्मीद के मुताबिक नहीं है, तो हैंडशेक फिर से भेजा जाता है, फिर नए एक्सचेंज किए गए मापदंडों के साथ फिर से संदेश भेजा जाता है।

प्रशन

क्या मैं सही रास्ते पर हूं या मुझे पूरी तरह से कुछ अलग करने की कोशिश करनी चाहिए?

क्या यह मेरे सुरक्षा लक्ष्यों को प्रदान करता है या क्या मुझे यहां कोई स्पष्ट कमजोरियां याद आती हैं?

क्या यह काम कर सकता है?

मुझे आशा है कि आप इसी तरह की समस्याओं का सामना करने वाले मुझे और अन्य एम्बेडेड इंजीनियरों की मदद कर सकते हैं!

Answer 1

क्रिप्टोग्राफ़िक प्रोटोकॉल में एक नियम यह है कि उन्हें कभी भी अपने दम पर लागू न करें। दुर्भाग्य से मुझे ऐसा कुछ भी नहीं मिला जो इस उपयोग के मामले से मेल खाता हो।

क्या आपने DTLS पर विचार किया है ? वही समस्या को हल करने की कोशिश करता है (समय टिकटों को छोड़कर; कि डाटाग्राम में समय की मुहर लगाकर जोड़ा जा सकता है), और पहले से ही चीजों के बारे में सोचा है। एक और संभावना IPsec होगी; हालाँकि, DTLS आपकी समस्या के समाधान के करीब है (जब तक कि आप जिस डेटा ट्रैफ़िक को IP ट्रैफ़िक नहीं दे रहे हैं)।

उन्होंने कहा, यहां आपके द्वारा उल्लिखित प्रोटोकॉल पर कुछ विचार दिए गए हैं:

• यदि दो अनुक्रमिक संदेश छोड़ दिए जाते हैं (उदाहरण गलत तरीके से प्राप्त हुआ) तो क्या होगा? क्या दोनों पक्षों को एहसास होगा कि क्या हुआ, या क्या वे बाद के सभी संदेशों को छोड़ने के लिए आगे बढ़ेंगे (क्योंकि 'नॉनस को 2 से अधिक नियम नहीं बढ़ाना है)?

• यह मानते हुए कि वे एक रेकी का प्रयास करते हैं, यह कैसे समन्वित है? यदि एक पक्ष को लगता है कि वे अभी तक नहीं पहुंचे हैं, और दूसरा पक्ष सोचता है कि वे पुराने कुंजी के साथ एन्क्रिप्टेड संदेशों का क्या होगा? हम आम तौर पर इसे 'सिफरटेक्स्ट (DTLS में, यह' युग 'है) के साथ टैग के तहत एन्क्रिप्ट किया गया है' कुंजी को शामिल करना उपयोगी है।

• क्या आपका संचार चैनल संदेशों को पुनः व्यवस्थित कर सकता है? मुझे संदेह है कि यह आपके मामले में नहीं है, लेकिन यदि यह हो सकता है, तो आपको यह सोचना चाहिए कि इसे कैसे संभाला जाना चाहिए।

• यदि कोई व्यक्ति पिछले (मान्य) हैंडशेक संदेश को इंजेक्ट करता है तो क्या होगा? वह चीजों को कैसे भ्रमित करेगा?

• डेटा एन्क्रिप्शन पथ में, आप CBC एन्क्रिप्शन और CMAC अखंडता का उपयोग करते हैं। हालांकि यह एक व्यावहारिक समाधान है, यह विभिन्न पैडिंग हमलों के लिए प्रवण है यदि वे सही ढंग से एकीकृत नहीं हैं। वर्तमान फैशन एक AEAD मोड (जैसे GCM या Chacha20 / Poly1305) का उपयोग करने के लिए है जो दोनों करता है।

• एन्क्रिप्टेड ट्रैफ़िक यूनिडायरेक्शनल या बिडायरेक्शनल है? यदि ट्रैफ़िक दोनों तरीकों से जाता है, तो क्या आप ट्रैफ़िक के दोनों सेटों की सुरक्षा के लिए कुंजियों के एक ही सेट का उपयोग करते हैं?

• "अगर कुछ भी उम्मीद के मुताबिक नहीं है, तो हैंडशेक को फिर से भेजा जाता है, फिर नए एक्सचेंज किए गए मापदंडों के साथ फिर से संदेश भेजा जाता है।" - वह कैसे काम करता है? यदि रिसीवर ने फैसला किया है कि यह संदेश पसंद नहीं आया, तो प्रेषक इसे फिर से शुरू करने के लिए कैसे जानता है?