क्या एक तरफ़ा एसएसएल एक IoT डिवाइस को सुरक्षित कर सकता है?


9

मैं अपने स्थानीय नेटवर्क से जुड़ी एक IoT डिवाइस पर विचार कर रहा हूं (डिफ़ॉल्ट सेटिंग्स, कोई वीपीएन, कोई NAT, कोई DMZ) इंटरनेट एक्सेस के साथ या उसके बिना। मेरा डिवाइस प्रमाणीकरण और प्राधिकरण के साथ आरपीसी तंत्र की पेशकश करने वाले HTTP सर्वर के रूप में चलेगा। यह खुद को mDNS के साथ विज्ञापित करता है और मैं इसे अपने मोबाइल ऐप या मेरे रास्पबेरीपी का उपयोग करके बात करता हूं।

ऐसा लगता है कि IoT के विकास में मानदंड परस्पर (दो-तरफा) SSL है। इसका मतलब यह है कि एक तरफा एसएसएल मेरे ट्रैफ़िक को सुरक्षित नहीं कर सकता है? क्यों?

टिप्पणियाँ:

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

जवाबों:


8

एसएसएल / टीएलएस अच्छी तरह से काम करता है जब "सर्वर" ज्ञात स्थान (एक निश्चित होस्टनाम) पर होता है जो कि प्रस्तुत प्रमाण पत्र के सीएन से मेल खा सकता है।

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

जब पारस्परिक टीएलएस का उपयोग किया जाता है तो यह तब होता है जब डिवाइस किसी केंद्रीय सेवा से जुड़ रहा होता है, ग्राहक के पास यह प्रमाणित करने के लिए स्वयं प्रमाणित / निजी कुंजी होती है कि वह उस केंद्रीय सर्वर के साथ मालिक की ओर से कार्य करने में सक्षम हो।

अपने प्रश्न के स्पष्टीकरण के एक बिंदु के रूप में आपको सभी क्लाइंट को सर्वर सर्टिफिकेट / कुंजी वितरित करने की आवश्यकता नहीं है, बस जिस सीए ने प्रमाण पत्र जारी किया है उसका प्रमाण पत्र प्रमाणित करने के लिए आवश्यक है।

संपादित करें:

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


यदि होस्ट एक निश्चित डीएनएस नाम या आईपी पते पर नहीं है, तो सामान्य प्रमाणपत्र सत्यापन विफल हो जाता है, क्योंकि यह प्रमाणित करता है कि उस पते पर डिवाइस यह कहता है कि यह कौन है (सामान्य "एकल पक्षीय" एसएसएल)। पारस्परिक रूप से प्रमाणित एसएसएल के लिए आपको दोनों पक्षों के लिए एक ही कुंजी / प्रमाण पत्र का उपयोग नहीं करना चाहिए। सर्वर और क्लाइंट तक पहुँचने के लिए अपना स्वयं का प्रमाण पत्र / कुंजी एक पारस्परिकता से भरोसा किया हुआ CA द्वारा हस्ताक्षरित होना चाहिए
hardillb

उत्तर के लिए धन्यवाद और लंबी चुप्पी के लिए क्षमा करें @hardillb। "इसका मतलब है कि उन्हें प्रमाण पत्र के साथ जारी नहीं किया जा सकता है (अच्छी तरह से वे कर सकते हैं लेकिन अधिकांश ब्राउज़र उन्हें अस्वीकार कर देंगे)।" अपने IoT डिवाइस के साथ संचार को ध्यान में रखते हुए, मैं यह नहीं देखता कि कब मैं ऐसा करने के लिए एक ब्राउज़र का उपयोग करूंगा ... "आपको सभी क्लाइंट को सर्वर सर्टिफिकेट / कुंजी वितरित करने की आवश्यकता नहीं है, बस सीए का प्रमाण पत्र" यह है एक तरफ़ा टीएलएस के लिए, सही? क्योंकि आपसी के लिए मेरा मानना ​​है कि आपको सर्टिफिकेट और चाबी देने की जरूरत है, जो चीजों को और अधिक कठिन बना देता है। Tradfri के बारे में, पूर्व-साझा की गई कुंजी एन्क्रिप्शन के लिए है, एन्क्रिप्शन के लिए नहीं।
वैलेंटाइन

कोई भी ट्रेड्रफी पूर्व-साझा की गई कुंजी को एन्क्रिप्शन के लिए एक डिवाइस-कुंजी को हैंडशेक करने और बनाने के लिए नहीं है
hardillb

1

आम तौर पर, टीएलएस x.509 से अधिक के लिए अच्छा है, लेकिन कई कार्यान्वयन इसे केवल x.509 तक सीमित करते हैं।

x.509 एक सुरक्षित अप्रत्यक्ष ट्रस्ट के लिए एक तकनीक है। "ए" ट्रस्ट्स "बी", अगर "बी" के पास एक प्रमाण पत्र है, जिस पर "सी" और "सी" द्वारा हस्ताक्षरित है, "ए" द्वारा भरोसा किया जाता है। वह वास्तविक जीवन में भी काम करता है; आप किसी ऐसे व्यक्ति पर भरोसा करते हैं जिसे आप नहीं जानते हैं, यदि कोई पत्र उस व्यक्ति द्वारा हस्ताक्षरित प्रस्तुत किया जाता है जिस पर आप भरोसा करते हैं। हो सकता है कि आपको नुकसान दिखाई दे: यदि पत्र कहता है, तो कृपया एक कप कॉफी दें जो आप अपनी कार को नहीं देंगे। इसलिए प्रमाणपत्र में अतिरिक्त जानकारी भी ट्रस्ट को गुंजाइश देने के लिए प्रासंगिक है। इसीलिए एक सर्वर में आमतौर पर डीएनएस नाम या आईपी-एड्रेस होता है। आम तौर पर आप अलग-अलग जानकारी शामिल कर सकते हैं (उदाहरण के लिए "लिविंग रूम लैंप"), लेकिन कई कार्यान्वयन भी DNS / आईपी सामान का उपयोग / जांच करने के लिए कम से कम पूर्वनिर्मित हैं। और यह सब केवल तभी काम कर रहा है जब किसी को विश्वसनीय की परवाह है "

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.