शीर्ष स्तर के सिस्टम पर लिनक्स डिवाइस हार्डवेयर डोंगल प्रमाणीकरण

औद्योगिक IoT औद्योगिक सुविधाओं, भवनों, व्यावसायिक सुविधाओं की इंजीनियरिंग प्रणालियों की निगरानी, ​​समय-निर्धारण और स्वचालन है। विभिन्न मापदंडों, मीटर और नियंत्रकों के सेंसर इन ऑब्जेक्ट्स से डेटा एकत्र करते हैं, उदाहरण के लिए, सर्वर रूम में तापमान और आर्द्रता, अपार्टमेंट इमारतों में पानी के मीटर, कमरों में कार्बन डाइऑक्साइड का स्तर। नियंत्रक इस जानकारी को संसाधित करते हैं और "क्लाउड" पर सब कुछ भेजते हैं।

Wiren Board औद्योगिक IoT के लिए Linux नियंत्रकों का निर्माण करता है। उपकरण तेल के कुओं और बैंक शाखाओं से डेटा एकत्र करते हैं, सर्वर और सुपरमार्केट में माइक्रॉक्लाइमेट की निगरानी करते हैं। नियंत्रकों कंपनी भागीदारों के शीर्ष स्तर के सिस्टम के साथ एकीकृत करते हैं। सिस्टम उपकरणों को प्रमाणित करते हैं - वे समझते हैं कि वे अपने सेंसर के साथ बात कर रहे हैं, और किसी और के साथ नहीं, और फिर वे अधिकृत करते हैं। इस स्तर पर, एक समस्या उत्पन्न होती है - हजारों नियंत्रक, सैकड़ों ग्राहक हैं, लेकिन एक भी एकीकरण प्रणाली नहीं है। सरल पारंपरिक तरीके, जैसे कि लॉगिन / पासवर्ड जोड़े, हमलों के लिए संवेदनशील और तैनात करने में असुविधाजनक हैं।



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

वक्ता के बारे में: यूजीन बोगर ( evgeny_boger ) - सीटीओ और विरेन बोर्ड के सह-संस्थापक। एम्बेडेड सिस्टम में लगे हुए हैं, और विशेष रूप से, एम्बेडेड लिनक्स।

समस्याओं

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



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

इन समस्याओं को हल करने के लिए दो सरल उपाय हैं। पहला ग्राहक को उपयोगकर्ता नाम / पासवर्ड देना है , जैसा कि सभी करते हैं, और दूसरा कार्यस्थल में "गुप्त" को उत्पन्न और सीवे करना है । दोनों विकल्प हमें पसंद नहीं आए - मैं आपको बताऊंगा कि क्यों।

सरल उपाय

पहला समाधान क्लाइंट को उपयोगकर्ता नाम और पासवर्ड जारी करना है । हम सभी लोग हाल तक ऐसा करते हैं।

किसी सिस्टम को डेटा भेजने वाले डिवाइस को प्रमाणित करने के लिए, आप एक गुप्त कुंजी बना सकते हैं - सशर्त रूप से लॉगिन / पासवर्ड ("गुप्त")। यह नियंत्रकों और एक शीर्ष-स्तरीय प्रणाली पर आम होगा जो कई नियंत्रकों से डेटा एकत्र करता है।

उपयोगकर्ता नाम / पासवर्ड (एक सामान्य "गुप्त") का एक जोड़ा किसी तरह ग्राहक को दिया जाना चाहिए - कंपनी या व्यक्ति। किसी को एक गुप्त जोड़ी उत्पन्न करनी चाहिए, इसे ई-मेल द्वारा भेजें, ग्राहक को खाता संख्या द्वारा प्रमाणित करें। यह मानक प्रक्रिया है - कम प्रौद्योगिकी।

समस्या । यह है कि हमारे पास ऐसी कई प्रणालियाँ हैं। हमारा ग्राहक, और वह हमारे साथी के सिस्टम को डेटा भेज सकता है। यह सभी शामिल पक्षों के बीच एक जटिल बातचीत है।

कई प्रणालियों की समस्या के अलावा, अन्य हैं।

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

दूसरा समाधान उत्पादन में एक "गुप्त" उत्पन्न और सीवे करना है । यह पिछले समाधान पर एक सुधार है।

योजना यह है: हम, नियंत्रक के निर्माता के रूप में, सभी के लिए उपयोगकर्ता नाम और पासवर्ड पूर्व-उत्पन्न करते हैं, उन्हें हमारे सिस्टम में सीवे और उन्हें उपकरणों में दर्ज करें। उपकरण से लॉगिन और पासवर्ड न तो पढ़ा जा सकता है और न ही बदला जा सकता है। यह पिछले विकल्प से बेहतर है, क्योंकि इसमें लोगों के बीच बातचीत की आवश्यकता नहीं है।

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

दोनों ही समाधान हमें शोभा नहीं देते। इसलिए, हमने एक अलग रास्ता लेने का फैसला किया। लेकिन इससे पहले उन्होंने सामान्य लक्ष्यों और उद्देश्यों को रेखांकित करने का फैसला किया।

कार्य और लक्ष्य

पहले सामान्य कार्य।

प्रमाणीकरण। यह समझने का एक तरीका है कि कौन शीर्ष स्तर की प्रणाली से बात कर रहा है, जो वास्तव में प्रेषण प्रणाली से जुड़ता है।

प्रमाणीकरण पहुँच अधिकार प्रदान या परिसीमित नहीं कर रहा है, लेकिन यह समझने का एक तरीका है कि हमसे कौन बात कर रहा है।

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

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

• नि: शुल्क निर्माता सेवा । डिवाइस सीरियल नंबर द्वारा पहुंच प्रदान करें।
  
• हमारे भागीदारों की सेवा के लिए अनुक्रमांक की श्वेत सूची - ग्राहक के खाते में खरीदारी और पहुंच लिंक करें।
  
• लाइसेंस। प्रमाणपत्र में निर्दिष्ट विकल्पों के आधार पर अनुमति दें या अस्वीकार करें।
  

जब हम समस्याओं को हल करते हैं तो लक्ष्य वे होते हैं जिन्हें हम प्राप्त करना चाहते हैं।

ग्राहक को जारी करना और वितरण करना । लोगों की भागीदारी के बिना - उत्पादन में रोबोट द्वारा जानकारी को सीवन किया जाता है।

नुकसान की वसूली । हम चाहते हैं कि गुप्त विवरणों का नुकसान न हो।

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

सर्वर पर भंडारण । यह सलाह दी जाती है कि वहां कुछ भी स्टोर न करें।

सेवाओं और इंट्रानेट के बीच सिंक्रनाइज़ेशन । यह भी सलाह दी जाती है कि कुछ भी सिंक्रनाइज़ न करें - क्योंकि हम कुछ भी स्टोर नहीं करेंगे।

विवरण की नकल के खिलाफ संरक्षण । हम कुछ गुप्त चाहते हैं, जिसके लिए पैसा लिया जाता है, मुफ्त में कॉपी और प्राप्त करना असंभव था।

डिजिटल हस्ताक्षर बचाव के लिए पहुंचे

इलेक्ट्रॉनिक डिजिटल हस्ताक्षर (ईडीएस) एक ऐसी तकनीक है जिसके चारों ओर सब कुछ हमारे लिए काम करता है।

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

एक इलेक्ट्रॉनिक हस्ताक्षर एक ऐसी चीज है जिसे एक संदेश द्वारा गिना जा सकता है यदि आप गुप्त निजी कुंजी (निजी कुंजी) जानते हैं। यदि आप सार्वजनिक कुंजी (सार्वजनिक कुंजी) जानते हैं, तो यह सत्यापित करना आसान है कि संदेश के लिए इलेक्ट्रॉनिक हस्ताक्षर सही है। नाम स्पष्ट है - जनता सभी को सूचित करने के लिए प्रथागत है, और रहस्य केवल उसी के लिए है जो हस्ताक्षर करता है।

सभी हस्ताक्षर और कुंजी बस संख्या हैं।

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

हम हस्ताक्षर ECDSA-256 + SHA-256 का उपयोग करते हैं:

• e = HASH(m) - क्रिप्टोग्राफिक हैश फ़ंक्शन अपरिवर्तनीय रूप से संदेश को नंबर ई में परिवर्तित करता है;
  
• private key (dA) - यादृच्छिक संख्या;
  
• public key (QA) - एक निजी कुंजी से उत्पन्न, लेकिन इसके विपरीत नहीं;
  
• signature (r,s) = sign(private key, e) - हस्ताक्षर;
  
• verify(public key, signature, e) - हस्ताक्षर का सत्यापन।
  

ईडीएस प्रमाणीकरण। पहला प्रयास

इस मुश्किल तंत्र का उपयोग करके हमारे कार्य के लिए क्या किया जा सकता है, जो एक दिशा में काम करता है और दूसरी मुश्किल में?

ग्राहक को जारी करना और वितरण करना । हम उत्पादन में प्रत्येक डिवाइस के लिए एक यादृच्छिक निजी कुंजी उत्पन्न करते हैं। हम किसी को नहीं बताते हैं, क्योंकि हम उसे जानते भी नहीं हैं, और हम डिवाइस को लिखते हैं।

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

मानक स्वास्थ्य जांच एल्गोरिथ्म:

• सेवा नियंत्रक को एक यादृच्छिक संदेश भेजती है;
  
• नियंत्रक: sign(private key, m) ;
  
• नियंत्रक सेवा के लिए एक हस्ताक्षर भेजता है;
  
• सेवा: verify(public key, signature, m) ।
  

केवल एक चीज जो हमने इस तरह से तय की है कि अब हम खुले या कैश्ड रूप में अपनी सेवाओं पर आम "रहस्यों" को संग्रहीत नहीं करते हैं । यह वह नहीं है जो हम चाहते हैं।

ईडीएस प्रमाणीकरण। दूसरा प्रयास

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

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

अब डिवाइस सार्वजनिक कुंजी को भी सेवा में भेज देगी। यह कैसे जांचें कि किसी ने उसे बाधित नहीं किया, उसे नकली नहीं बनाया, और यह सब कुछ काम करता है?

सार्वजनिक कुंजी की जाँच करना । हम खुद को एक और सार्वजनिक कुंजी बनाते हैं। वह एक निर्माता के रूप में हमारी कुंजी होगी। यह मूल कुंजी "रूट निजी कुंजी + सार्वजनिक कुंजी" है। उत्पादन में इस मूल गुप्त कुंजी के साथ, हम डिवाइस को सार्वजनिक कुंजी पर हस्ताक्षर करेंगे और हम इस हस्ताक्षर को डिवाइस पर संग्रहीत करेंगे। डिवाइस को अपनी सार्वजनिक कुंजी और सेवा के लिए अपनी सार्वजनिक कुंजी के हस्ताक्षर भेजने होंगे। अब सेवा डिवाइस की सार्वजनिक कुंजी की जांच कर सकती है। यदि यह रूट निजी कुंजी के साथ हस्ताक्षरित है, तो हमने यह कुंजी जारी की है।

केवल निर्माता - हम डिवाइस पर एक हस्ताक्षर बना और स्टोर कर सकते हैं, लेकिन सब कुछ जांचें।

हम "संपर्क" अनुभाग में साइट पर सार्वजनिक कुंजी प्रकाशित करते हैं। कोई भी इसे ले सकता है और डिवाइस की सार्वजनिक कुंजी की जांच कर सकता है जिसने डिवाइस को सेवा में भेजा है। फिर आप यह सत्यापित कर सकते हैं कि डिवाइस की अपनी निजी कुंजी है।

सामान्य एल्गोरिदम इस तरह दिखता है।

• (once) random root private key ;
  
• factory: random device private key ;
  
• factory: sign(root private key, device public key) = signature_1 ;
  
• device->service: device public key + signature_1 ;
  
• service: verify(root public key, signature_1, device public key)?
  

दूसरा प्रयास परिणाम

हमने क्लाइंट को डिलीवरी के साथ समस्या को हल किया - उत्पादन साइट पर जानकारी को सीवन किया गया है और कुछ भी बहाल करने की आवश्यकता नहीं है ।

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

सर्वर पर हम केवल निर्माता कुंजी (रूट सार्वजनिक कुंजी) संग्रहीत करते हैं।

हमारे पास सेवाओं और इंट्रानेट के बीच सिंक्रनाइज़ेशन नहीं है, जिसके बारे में हम पहले ही बात कर चुके हैं। इसके अलावा, हमारे पास विवरणों की नकल करने से कोई सुरक्षा नहीं है।

केवल एक चीज जिसे हम भूल गए हैं वह प्रमाणीकरण है । डिवाइस ने एक निजी कुंजी भेजी, और हमने जाँच की कि हमने यह किया है और इसे जारी किया है, और जाँच की कि डिवाइस का मालिक है। लेकिन हम नहीं जानते कि यह किस प्रकार का उपकरण है, और हम उनमें से हजारों का उत्पादन करते हैं।

इसलिए, हमने "प्रमाणपत्र" नामक एक ट्रिक लागू की।

प्रमाणीकरण और प्रमाण पत्र

इस कदम पर, सभी गणितीय जादू में हस्ताक्षर और उनके चेक के साथ, हम अतिरिक्त जानकारी जोड़ते हैं - एक प्रमाण पत्र । ऐसा करने के लिए, हम कारखाने में न केवल सार्वजनिक कुंजी (डिवाइस सार्वजनिक कुंजी) पर हस्ताक्षर करते हैं, बल्कि अतिरिक्त जानकारी के साथ कुंजी।

हमारे मामले में अतिरिक्त जानकारी।

• निर्माण और निर्माता की तारीख।
  
• मॉडल और हार्डवेयर कॉन्फ़िगरेशन।
  
• सीरियल नंबर जिसके द्वारा डिवाइस को प्रमाणित किया जा सकता है।
  
• विकल्प: हार्डवेयर और सॉफ्टवेयर। विभिन्न कॉन्फ़िगरेशन भौतिक रूप से एक-दूसरे से भिन्न नहीं हो सकते हैं, लेकिन प्रमाण पत्र में ग्राहक के लिए भुगतान के बारे में जानकारी होगी।
  
• ग्राहक का नाम और खाता संख्या।
  

हम अपने निर्माता कुंजी - रूट सार्वजनिक कुंजी के साथ सार्वजनिक कुंजी के साथ इस सभी जानकारी पर हस्ताक्षर करेंगे। उसके बाद, जानकारी सेवाओं पर जाएगी और वे यह सुनिश्चित कर पाएंगे कि यह सही है। चूंकि ये हमारी और हमारे भागीदारों की सेवाएं हैं, इसलिए वे हम पर भरोसा करते हैं।

लक्ष्य की स्थिति

फैक्ट्री में सूचनाओं को सिल दिया जाता है, और सेवाओं की डिलीवरी की आवश्यकता नहीं होती है। सर्वर पर हम केवल निर्माता की कुंजी संग्रहीत करते हैं।

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

प्रमाण पत्र को कारखाने में संग्रहीत किया जा सकता है और ग्राहक को भेजा जा सकता है अगर वह इसे खो देता है। ग्राहक शायद ही कभी स्मृति के सेवा क्षेत्र को मिटाते हैं। आमतौर पर हम डिवाइस रिकवरी प्रक्रिया के दौरान ऐसा करते हैं: डिवाइस क्लाइंट से आया है, यह पूरी तरह से आरंभीकरण से गुजरता है, सब कुछ मिट जाता है, इसे फिर से डाउनलोड किया जाता है, और प्रमाण पत्र को फैक्ट्री डेटाबेस से कॉपी किया जाता है।

हमारे पास सेवाओं के बीच हानि वसूली , प्रतिलिपि संरक्षण और सिंक्रनाइज़ेशन नहीं है ।

प्रमाणीकरण स्तर पर, हम प्रमाण पत्र प्राप्त करते हैं और सत्यापित करते हैं। हम समझते हैं कि यह किस प्रकार का उपकरण है - हम निर्माता, मॉडल और सीरियल नंबर को जानते हैं, वह क्या कर सकता है और क्या नहीं।

प्राधिकरण

प्रमाणपत्र आपको प्राधिकरण के लिए जानकारी संग्रहीत करने की अनुमति देता है।

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

अनुक्रमांक की सफेद सूची । हमारे सहयोगियों की सेवा के लिए, आप सीरियल नंबर की एक सफेद सूची के साथ एक तालिका बना सकते हैं: "क्लाइंट वसीली ने हमसे दो कंट्रोलर खरीदे हैं जो ऐसे सीरियल नंबर के साथ हैं जो उसके खाते से जुड़े हैं"

लाइसेंस। आप पहले से कुछ बेच सकते हैं, और फिर प्रमाणपत्र में निर्दिष्ट विकल्पों के आधार पर अनुमति या इनकार कर सकते हैं - सिस्टम एक्स के लिए एक लाइसेंस के साथ एक नियंत्रक।

सेवाओं, निर्माता या सिस्टम के निर्माता के बीच कोई सामान्य आधार नहीं है। सब कुछ विशेष रूप से नियंत्रक द्वारा जानकारी पर काम करता है जो हमारे द्वारा हस्ताक्षरित होता है, एक निर्माता के रूप में, जब यह सिस्टम में प्रमाणित होता है।

इंटरमीडिएट का प्रमाण पत्र

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

हम उपकरणों के एक बैच के लिए मध्यवर्ती कुंजियों का परिचय देते हैं जो खोने के लिए इतने डरावने नहीं हैं।

हमने वही किया, केवल श्रृंखला लंबी है।



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

सुरक्षित कीस्टोर

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

आदर्श मामले में, डिवाइस की निजी कुंजी को कॉपी करने से बचाने के लिए अच्छा होगा - इसे एक ब्लैक बॉक्स में रखें।

ब्लैक बॉक्स 4 ऑपरेशन करता है:

• अंदर ही अनुरोध पर एक कुंजी उत्पन्न करता है, लेकिन नहीं देता है;
  
• सार्वजनिक कुंजी देता है;
  
• एक संदेश पर हस्ताक्षर करता है
  
• हस्ताक्षर की पुष्टि करता है।
  

हस्ताक्षर को सत्यापित करने के लिए, आपको केवल एक सार्वजनिक कुंजी की आवश्यकता है, इसलिए तीन ऑपरेशन पर्याप्त हैं।

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

पहला ब्लैक बॉक्स विकल्प जिसकी हमने समीक्षा की वह NXP i.mx 6, 7, 8 प्रोसेसर में CAAM मॉड्यूल है जिसका हम उपयोग करते हैं। समस्या यह है कि यह प्रोसेसर के बूट रोम में प्रोग्रामेटिक रूप से कार्यान्वित किया जाता है।

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

इसलिए, हमने एक अलग चिप ली। मैं ईमानदारी से मानता हूं, मैंने इस तथ्य पर भरोसा किया कि अगर हम इसे रूस में नहीं ला सकते हैं, तो हम कुछ लेकर आएंगे - चिप छोटा है, इसकी कीमत $ 1 है। लेकिन सब कुछ अच्छी तरह से निकला - उन्हें माइक्रोचिप एटीईसीसी चिप मिला, जिसमें पहले से ही सभी कागजात हैं।

माइक्रोचिप ATECC608A

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

चिप वह कर सकती है जो हमें ऐसी चिप से चाहिए: हस्ताक्षर, स्टोर कुंजी, और बहुत कुछ पढ़ें।



विशेषताएं:

• 16 प्रमुख स्लॉट;
  
• ECSDSA हस्ताक्षर, हैश, एमएसीएस और एईएस एन्क्रिप्ट कर सकते हैं, डीएच पढ़ सकते हैं;
  
• एक यादृच्छिक संख्या जनरेटर और क्रिप्टोग्राफिक काउंटर है;
  
• बाड़ों: SOIC-8, DFN6;
  
• प्रोटोकॉल: I2C, एकल तार;
  
• ~0.7$@1000pcs।
  

कैसे एक microcircuit के साथ काम करने के लिए

इसके लिए सभ्य दस्तावेज है , लेकिन एनडीए के तहत। यदि आप तुरंत गामा को लिखते हैं। चिपकने वाला। तो वे आपको 2 सप्ताह में दे देंगे। यदि किसी अन्य कंपनी में - 3 महीने के बाद। हमने दो कंपनियों को लिखा था, और जब हमने सब कुछ किया था, तो एक और माइक्रोचिप डीलर ने हमें जवाब दिया।

वहाँ कुछ appnotes हैं और वे औसत से भी बदतर हैं। GitHub पर सॉफ्टवेयर है - HAL के साथ एक पुस्तकालय। यह हास्यास्पद है - प्रलेखन एनडीए के तहत है, और उस पर लिखा गया सॉफ्टवेयर गीथहब पर है। सॉफ्टवेयर लिनक्स का समर्थन नहीं करता है, लेकिन रास्पबेरी पाई और एटलम एमके का समर्थन करता है - यह थोड़ा अलग है। डेवलपर्स का मानना ​​है कि सभी उपकरणों पर केवल एक I2C बस है, उदाहरण के लिए, पैरों को रास्पबेरी पाई के रूप में कहा जाता है।

ओपनएसएसएल के साथ एकीकरण है - यह अच्छी तरह से काम नहीं करता है, लेकिन यह करता है। लिनक्स के तहत कोई उदाहरण नहीं हैं और निजीकरण के साथ कोई काम नहीं है।

चिप अनुकूलन

चिप के साथ निजीकरण सबसे बड़ा सिरदर्द है।

समस्या यह है कि चिप बहुत सारी चीजें कर सकती है। इसमें 16 स्लॉट हैं जिसमें 16 कुंजी संग्रहीत हैं: उपयोगकर्ता डेटा, या सार्वजनिक कुंजी, या अन्य स्लॉट के लिए अस्थायी भंडारण - कई विकल्प हैं।

आपको किसी तरह से स्लॉट तक पहुंच को प्रतिबंधित करने की आवश्यकता है, और कई कॉन्फ़िगरेशन विकल्प भी हैं: पासवर्ड द्वारा प्रतिबंधित, दूसरे स्लॉट में प्रमाणीकरण द्वारा, कारखानों तक पहुंच के समय तक।


तालिका में, कुंजी का प्रकार, पढ़ने और लिखने का उपयोग, स्लॉट्स के बीच का संबंध - स्लोटकोनफिग, कीकोनफिग।

हमारे द्वारा उपयोग की जाने वाली प्रत्येक कुंजी के बिट मास्क (16 बिट्स) में, हर जगह अलग-अलग संख्याएं होती हैं।

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

उदाहरणों में या सॉफ्टवेयर में कोई प्रलेखन नहीं है। व्यक्तिगत बिट्स के लिए प्रलेखन है, लेकिन वहां सब कुछ जटिल है। माइक्रोचिप से सभी उदाहरणों में यह लिखा है: "इस तरह के एक ब्लॉक को डाउनलोड करें, और यह किसी तरह आपके लिए काम करेगा, जैसे कि अमेज़ॅन को डेटा भेजने के उदाहरण में।"

इसमें बहुत समय लगा, लेकिन इस प्रक्रिया में उन्होंने एक शांत उपयोगिता बनाई।

एतेक-उपयोग उपयोगिता

यह एक कंसोल उपयोगिता है जो चिप के अधिकांश कार्यों को कर सकता है और आपको थोड़ा आसान काम करने की अनुमति देता है। यह एक MIT लाइसेंस के तहत GitHub पर उपलब्ध है।

उपयोगिता CryptoAuthLib का उपयोग करती है। वह जानती है कि कॉन्फिग ज़ोन के साथ अधिक दोस्ताना काम कैसे करना है, वह जानती है कि SHA, MAC, ECDSA, DH के साथ कैसे काम करना है। इंटरफ़ेस बैच के अनुकूल है, क्योंकि हमने स्क्रिप्ट्स में उपयोग के लिए उपयोगिता पहले स्थान पर बनाई थी। तथ्य यह है कि एक व्यक्ति यह कारण हो सकता है एक पक्ष विशेषता है। उपयोगिता एक सूची बना सकती है - आदेशों की एक योजना: "पहले इस क्षेत्र को निजीकृत करें, फिर इस तरह की कुंजी लिखें।"

उपयोगिता को कॉल करने का एक उदाहरण काफी मानव-पठनीय है।

 atecc - b 10 - c 'serial' - c 'read-config /tmp/config.dump' 

उपयोगिता लिनक्स के तहत बनाया गया है, AMD64 के तहत - यह डेबियन पैकेज में है।

अन्य वैयक्तिकरण उपकरण

बिट्स को पढ़ने के लिए हमारे पास एक एक्सेल प्लेट है। यदि आप हमें माइक्रोचिप के साथ एनडीए स्कैन दिखाते हैं, तो हम इसे आपको दे देंगे।



हमने परीक्षणों के साथ सब कुछ कवर किया है, क्योंकि कई विकल्प हैं जब आप एक बिट को भूल सकते हैं और कुछ सेवा कमांड आपकी निजी कुंजी पढ़ेंगे। टेस्ट असली डिवाइस का परीक्षण करते हैं। वे माइक्रोक्रिकिट की ओर मुड़ते हैं और डिवाइस पर सही कॉन्फ़िगरेशन की जांच करते हैं: क्या इस स्लॉट को पढ़ा जा सकता है, क्या इस तरह के हस्ताक्षर किए जा सकते हैं?

बिट्स के समानांतर में, हमने गारंटी की एक सूची बनाई कि इस उपकरण को संतुष्ट करना चाहिए, और यह जांचना चाहिए कि सब कुछ कैसे काम करता है। हम चमगादड़ ढांचे का उपयोग करते हैं - एक बहुत ही दिलचस्प बात। ऐसा दिखता है।


एक उदाहरण के लिए परीक्षणों की सूची। ऊपरी वाले पास हैं, लेकिन निचले वाले नहीं हैं।

उपकरणों में सेटिंग्स

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

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

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

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

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

अब तक, दुर्भाग्य से, किसी ने भी उपयोग नहीं किया है, लेकिन हमें उम्मीद है।

इन्फ्रास्ट्रक्चर: इंटरमीडिएट की

मैंने पहले ही कहा था कि कुछ बिंदु पर हमने मध्यवर्ती प्रमाणपत्र लागू किए ताकि रूट प्रमाणपत्र के साथ चमक न जाए जो खोना नहीं चाहिए। वह कभी किसी कारखाने में दिखाई नहीं देता।



शारीरिक रूप से मध्यवर्ती प्रमाण पत्र एक ATECC508A चिप है। यह 608 से थोड़ा अलग है, लेकिन 508 ​​में कार्यक्षमता है जो चाबियों के लिए काम में आती है, लेकिन 608 में यह अब नहीं है।

चिप USB-I2C एडाप्टर के माध्यम से जुड़ा हुआ है। यह छोटे-यूएसबी-आई 2 सी फर्मवेयर के साथ यूएसबीआईएसपी है - एक प्रोग्रामर जिसे यूएसबी-आई 2 सी पुल में फ्लैश किया जा सकता है। इंटरमीडिएट प्रमाणपत्र उनकी निजी कुंजी के साथ डिवाइस प्रमाण पत्र पर हस्ताक्षर करते हैं।

Microcircuit की दो विशेषताएं हमारे लिए उपयोगी साबित हुईं।

हार्डवेयर पासवर्ड सुरक्षा स्लॉट । चिप को केवल दो शर्तें पूरी होने पर हस्ताक्षर को पढ़ने के लिए प्रोग्राम किया जा सकता है:

• जब डिवाइस कंप्यूटर में फंस जाता है;
  
• पासवर्ड दर्ज किया गया।
  

हम उत्पादनकर्ता को कई नियंत्रकों के लिए एक मध्यवर्ती कुंजी और पासवर्ड उत्पादन के लिए देते हैं। तदनुसार, आपको पहुँच प्राप्त करने के लिए कुंजी और पासवर्ड दोनों को चुराने की आवश्यकता है। हमें यह मौका मुफ्त में मिला है, लेकिन यह प्रणाली की सुरक्षा में सुधार करता है।

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

क्लाइंट पर OpenSSL

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

हमने माइक्रोचिप से कोड लिया, इसे थोड़ा जोड़ा, ताजा ओपनएसएसएल का समर्थन किया
1.1। नतीजतन, वह जानता है कि हार्डवेयर कुंजी के साथ कैसे काम किया जाए - हार्डवेयर निजी कुंजी के लिए पासवर्ड का समर्थन करता है।

यह कुछ इस तरह दिखता है।

 openssl req -new -engine ateccx08 -keyform engine -key ATECCx08:00:04:C0:00 -subj "/CN=wirenboard-AP6V5MDG" -out device AP6V5MDG.csr 

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

सर्वर पर एसएसएल

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

स्टैंडर्ड टीएलएस का कहना है कि दोनों पक्षों को एक दूसरे को प्रमाणित करना होगा। — — . — handshake.

: . , . letsencrypt SSL, , .

, — MQTT.

MQTT: mosquitto

IBM. .

Mosquitto — , , Linux. , OpenSSL engine ( ) «keyfile», . , 20 .

bundle.



.

 mosquitto_sub -h mqtt.wirenboard.com -p 8884 -cert /etc/ssl/device/device_bundle.crt.pem --key 'engine:ateccx08:ATECCx08:00:04:C0:00' --capath /etc/ssl/certs/ -t /# -v 

. — -cert . bundle- — . --key . .

, --capath , . SSL-, letsencrypt.

.

 root@wirenboard-AXXVJI62:~# cat /etc/mosquitto/conf.d/bridge-hw.conf connection wb_devices_cloud.wirenboard-AXXVJI62 address contactless.ru:8884 bridge_capath /etc/ssl/certs/ bridge_certfile /etc/ssl/device/device_bundle.crt.pem bridge_keyfile engine:ateccx08:ATECCx08:00:04:C0:00 notifications true notification_topic /client/wirenboard-AXXVJI62/bridge_status topic/# both 1 ""/dient/wirenboard-AXXVJI62 

Mosquito- .

Mosquitto — .

 per _listener_settings true listener 8884 0.0.0.0 cafile/etc/mosquitto/certs/WirenBoard_Root_CA.crt certfile /etc/letsencrypt/live/contactless.ru/fullchain.pem keyfile/etc/letsencrypt/live/contactless.ru/privkey.pem require.certificate true use_identity_as_username true password_file /etc/mosquitto/passwd.conf allow_anonymous false acl_file /etc/mosquitto/ad.conf :~$ cat /etc/mosquitto/acl.conf pattern write /client/%u/# pattern read /client/%u/# 

— .

• Root CA letsencrypt- — . .
  
• Mosquitto. username MQTT.
  
• , , , (CN) wirenboard-AXXVJI62, , .
  
• per_listener_settings: , / (>1.5.5).
  

MQTT- Wiren Board IoT Cloud Platform.

OpenVPN

OpenVPN , , . , .

OpenVPN , . , : bundle, , engine.

 openvpn --capath /etc/ssl/certs/ --cert /etc/ssl/device/device_bundle.crt.pem --key engine:ateccx08:ATECCx08:00:04:C0:00 

letsencrypt.

 ca /etc/openvpn/WirenBoard_Root_CA.crt cert /etc/letsencrypt/live/vpn1.wirenboard.com/fullchain.pem key /etc/letsencrypt/live/vpn1.wirenboard.com/privkey.pem 

— . - .

nginx

. Nginx , , , SSL. nginx web-, reverse-proxy. — nginx.

nginx , HTTP-, . , : Common Name, , . , 400.

 ssl_client_certificate WirenBoard_Root_CA.crt; ssl_verify_client on; 

nginx . — , HTTP. Linux- nginx , SSL, , OpenSSL.

wget , bash , HTTP- TLS . 10 .

 server { listen 8080; location / { proxy_pass https://example.com; proxy_ssl_name example.com; proxy_ssl_server_name on; proxy_ssl_certificate/etc/ssl/device/device_bundle.crt.pem; proxy_ssl_certificate_key engine:ateccx08;ATECCx08:00:04:C0:00; } } 

Wiren Board 6 , . , .

web- cloud.wirenboard.com OpenVPN . Grafana InfluxDB, MQTT. saymon.info — (MQTT) .

, - , , Grafana, MQTT-, , , . — .

, , : — OpenSSL , — . !

InoThings Conf 2019 . YouTube- 2019 . Telegram. , , IoT.