IoT الصناعية هي مراقبة وجدولة وأتمتة النظم الهندسية للمنشآت الصناعية والمباني والمنشآت التجارية. تقوم مستشعرات المقاييس المختلفة ، والمقاييس وأجهزة التحكم بجمع البيانات من هذه الكائنات ، على سبيل المثال ، درجة الحرارة والرطوبة في غرفة الخادم ، وقراءات عدادات المياه في المباني السكنية ، ومستوى ثاني أكسيد الكربون في الغرف. يقوم المعالجون بمعالجة هذه المعلومات وإرسال كل شيء إلى "السحابة".
تقوم Wiren Board بتصنيع أجهزة التحكم Linux لنظام IoT الصناعي. تقوم الأجهزة بجمع البيانات من آبار النفط وفروع البنوك ، ومراقبة المناخ المحلي في الخادم والسوبر ماركت. تتكامل وحدات التحكم مع أنظمة المستوى الأعلى لشركاء الشركة. تقوم الأنظمة بمصادقة الأجهزة - فهم يفهمون أنهم يتحدثون مع المستشعر الخاص بهم ، وليس مع شخص آخر ، ثم يأذن لهم بذلك. في هذه المرحلة ، تنشأ مشكلة - هناك الآلاف من وحدات التحكم ، ومئات العملاء ، ولكن لا يوجد نظام تكامل واحد. الأساليب التقليدية البسيطة ، مثل أزواج تسجيل الدخول / كلمة المرور ، عرضة للهجمات وغير مريحة للنشر.

لذلك ، طورت الشركة المصادقة في أنظمة المستوى الأعلى باستخدام مفاتيح الأجهزة - بناءً على تشفير قياسي غير متماثل باستخدام عنصر محمي للأجهزة لتخزين المفاتيح. الآن ليست هناك حاجة لنظام تكامل موحد - المصادقة والترخيص محميان ويعملان خارج الصندوق.
سيخبرك Evgeny Boger بكيفية القيام بذلك: كيف اختاروا "شريحة التشفير" ، وكيف قاموا بتثبيتها على الأجهزة ولينوكس ، وكيف أصبحت المكتبات والبرامج المشتركة صداقة معها. التركيز بشكل خاص على النشر: إدخال تهيئة الجهاز في الإنتاج ، وتقديم الدعم لمختلف برامج المستوى الأعلى ، بما في ذلك في شخص آخر ومغلق.
نبذة عن المتحدث: يوجين بوجر (
evgeny_boger ) - CTO والمؤسس المشارك لـ Wiren Board. تشارك في أنظمة مدمجة ، وخاصة نظام Linux المضمن.
المشاكل
بادئ ذي بدء ، ما الذي نفعله ومن أين جاءت هذه المشكلة. نحن في Wiren Board نقوم بتصميم وتصنيع المعدات في روسيا. كان يطلق عليه M2M ، ولكن الآن - تقنيات عمليات الصناعية. هذا هو أتمتة بناء النظم الهندسية ، والرصد والجدولة. باختصار ، يبدو كل العمل كما يلي: أجهزة استشعار للمعلمات المختلفة ، والمحركات ، والعدادات ، وأجهزة التحكم (الحوسبة الحافة أو بوابة إنترنت الأشياء) تجمع بيانات مختلفة من الكائنات ، ومعالجتها ، وتنفيذ المنطق المحلي ، ثم تجميعها في نظام واحد للإرسال أو المراقبة أو التحكم .

ليس لدينا نظام بيئي كامل ، على عكس بعض المنافسين. نقوم بتصنيع المعدات التي تتكامل مع العديد من أنظمة المستوى الأعلى لشركائنا. هناك العديد من الشركات الشريكة وتتقاسم المسؤولية. بدون وسائل تقنية جيدة ، لن ينجح التكامل - لا يمكن التفاوض عليه.
هناك حلان بسيطان لحل هذه المشكلات. الأول هو
إعطاء اسم المستخدم / كلمة المرور للعميل ، كما يفعل الجميع ، والثاني هو
إنشاء وخياطة "السر" في مكان العمل . كلا الخيارين لم يناسبنا - سأخبرك لماذا.
حلول بسيطة
الحل الأول هو إصدار اسم مستخدم وكلمة مرور للعميل . كلنا نفعل ذلك حتى وقت قريب.
لمصادقة جهاز يرسل بيانات إلى بعض النظام ، يمكنك إنشاء مفتاح سري - تسجيل الدخول / كلمة المرور المشروط ("سري"). سيكون من الشائع على وحدات التحكم وعلى نظام المستوى الأعلى الذي يجمع البيانات من عدة وحدات تحكم.
يجب إعطاء اسم مستخدم / كلمة مرور (كلمة سر مشتركة) للعميل - الشركة أو الشخص. يجب على شخص ما إنشاء زوج سري ، وإرساله عبر البريد الإلكتروني ، ومصادقة العميل برقم الحساب. هذا هو الإجراء القياسي - التكنولوجيا المنخفضة.
مشكلة هو أن لدينا العديد من هذه النظم. عميلنا ، ويمكنه إرسال البيانات إلى نظام شريكنا. هذا تفاعل معقد بين جميع الأطراف المعنية.
بالإضافة إلى مشكلة العديد من الأنظمة ، هناك أنظمة أخرى.
- سوء التسليم والتسليم للعميل .
- يتم تخزين تسجيلات الدخول وكلمات المرور على الخادم . إذا قمنا أيضًا بتخزين التجزئة ، فإن هذا سيحمينا قليلاً من التسريبات. ولكن على الرغم من ذلك ، ينشأ شعور غير سارة عند تخزين المفاتيح السرية لجميع وحدات تحكم العميل على الخادم. يمكن لبعضهم التعامل مع المهام الحاسمة: الإضاءة في الهواء الطلق ، ومراقبة منصات النفط.
- التزامن بين الخدمات .
- استرداد الخسارة . ليس من الواضح ما يجب القيام به في حالة الخسارة ، عندما يمحو العميل ذاكرة وحدة التحكم - في أي ذاكرة يجب أن أكتب؟ يجب عليك تكرارها مرة أخرى.
- حماية ضد نسخ التفاصيل . هناك أنظمة مراقبة مدفوعة توفر للعميل رسوم خدمة ورسوم. لا أريد أن يتمكن العميل النهائي من تجاوز النظام بطريقة ما من خلالنا - الدفع مرة واحدة ، ولكن استخدام اثنين.
الحل الثاني هو توليد وخياطة "سر" في الإنتاج . هذا تحسين على الحل السابق.
المخطط هو: نحن كشركة مصنعة لوحدات التحكم ، نقوم بتوليد أسماء المستخدمين وكلمات المرور للجميع مسبقًا ، ونخيطها في نظامنا وندخلها في معدات. لا يمكن قراءة معلومات تسجيل الدخول وكلمات المرور من الجهاز أو تغييرها. هذا أفضل من الخيار السابق ، لأنه لا يتطلب التفاعل بين الناس.
المشاكل . تبقى جميع المشكلات باستثناء الأولى ، ولكن المشكلة الرئيسية هي
المزامنة بين الخدمات والإنترانت . هناك الكثير من الخدمات وليس من الواضح كيفية مزامنتها - ولهذا السبب ، لم نتمكن من تنفيذ الحل الثاني. لدينا عملاء يستخدمون المعدات في شبكاتهم المغلقة. أصدرنا وحدة تحكم جديدة ، وباعناها إلى عميل ، ونظامه مغلق. تم إعداده ، ويعمل مرة واحدة ، ومن الصعب نقل "الأسرار" بشكل أكبر. تقرير على دفعات؟ كل شيء معقد في المنظمات ، رغم أنه بسيط من الناحية الفنية.
كل الحلول لم تناسبنا. لذلك ، قررنا اتخاذ مسار مختلف. ولكن قبل ذلك قرروا تحديد الأهداف والغايات المشتركة.
المهام والأهداف
المهام المشتركة الأولى.
المصادقة. هذه طريقة لفهم من يتحدث إلى نظام المستوى الأعلى ، من يتصل بالضبط بنظام الإرسال.
المصادقة لا تمنح أو تحدد حقوق الوصول ، ولكنها طريقة لفهم من يتحدث إلينا.
مهمة إرسال البيانات . وحدات التحكم لدينا هي أجهزة كمبيوتر Linux مصممة لمهمة خاصة. نحن بحاجة إليهم لإرسال البيانات إلى أنظمة المستوى الأعلى ، والاتصال عبر VPN. في الوقت نفسه ، نريد أن يعمل الإرسال "خارج الصندوق" - دون إعدادات وتفاعل عملائنا ومستخدمي النظام معنا ومع العملاء.
مهام أخرى . هذا هو اتصال موثوق به ، تشفير قناة البيانات ، ولكن هناك مشكلة منفصلة تتمثل في
التخويل . ترتبط مهمة التفويض بالخدمات الخارجية وتنقسم إلى ثلاثة أجزاء.
- خدمة الصانع مجانا . توفير الوصول عن طريق الرقم التسلسلي للجهاز.
- قوائم بيضاء بالأرقام التسلسلية لخدمة شركائنا - ربط عمليات الشراء والوصول إلى حساب العميل.
- الترخيص. السماح بالوصول أو رفضه استنادًا إلى الخيارات المحددة في الشهادة.
الأهداف هي ما نريد تحقيقه عندما نحل المشاكل.
إصدار وتسليم للعميل . بدون مشاركة الأشخاص - يتم تجميع المعلومات بواسطة الروبوتات في الإنتاج.
استرداد الخسارة . نريد ألا تكون هناك أي تفاصيل سرية على الإطلاق.
التسليم من الإنتاج إلى الخدمات . نريد الاستغناء عنه ، بحيث لا تحتاج إلى تقديم أي شيء للخدمات. عند تشغيل معدات جديدة ، لا نريد تحديث قواعد بيانات جميع الخدمات التي يجب أن تصادق هذه الأجهزة.
التخزين على الخادم . من المستحسن عدم تخزين أي شيء هناك على الإطلاق.
التزامن بين الخدمات والإنترانت . يُنصح أيضًا بعدم مزامنة أي شيء - لأننا لن نخزن أي شيء.
حماية ضد نسخ التفاصيل . نريد شيئًا سريًا ، حيث يتم الحصول على المال ، كان من المستحيل نسخه واستلامه مجانًا.
التوقيع الرقمي يندفع إلى الإنقاذ
التوقيع الرقمي الإلكتروني (EDS) هو تقنية يعمل حولها كل شيء بالنسبة لنا.
يشبه التوقيع العادي ، رقمي فقط. من السهل التحقق من صحة EDS ، ولكن يصعب تزويرها. الحقائق المألوفة للتشفير ، والتي عمرها عقود.
التوقيع الإلكتروني هو شيء يمكن حسابه برسالة إذا كنت تعرف المفتاح السري السري (المفتاح الخاص). إذا كنت تعرف المفتاح العمومي (المفتاح العمومي) ، فمن السهل التحقق من صحة التوقيع الإلكتروني للرسالة. الاسم واضح - الجمهور معتاد على إبلاغ الجميع ، والسر هو فقط للشخص الذي يوقع.
جميع التوقيعات والمفاتيح هي مجرد أرقام.
في حالتنا ، هذه 32 بايت من البيانات ، والتي تعمل على "السحر" الرياضي. يضمن Math أن التوقيع سهل التحقق ، ولكن يصعب تزويره.
نستخدم التوقيع ECDSA-256 + SHA-256:
e = HASH(m)
- تعمل دالة تجزئة التشفير على تحويل الرسالة m إلى الرقم e بشكل لا رجعة فيه ؛
private key (dA)
- رقم عشوائي ؛
public key (QA)
- يتم إنشاؤه من مفتاح خاص ، ولكن ليس العكس ؛
signature (r,s) = sign(private key, e)
- التوقيع ؛
verify(public key, signature, e)
- التحقق من التوقيع.
مصادقة EDS. المحاولة الأولى
ما الذي يمكن القيام به لمهمتنا باستخدام هذه الآلية الصعبة ، والتي تعمل في اتجاه واحد ببساطة والأخرى صعبة؟
إصدار وتسليم للعميل . نقوم بإنشاء مفتاح خاص عشوائي لكل جهاز في الإنتاج. نحن لا نخبر أحداً ، لأننا لا نعرفه حتى نكتب إلى الجهاز.
التسليم من الإنتاج إلى الخدمات . بعد ذلك ، نستخدم فقط المفتاح العمومي لهذا الجهاز للمصادقة على الخدمات. على الخدمات ، نقوم فقط بتخزين قائمة المفاتيح العامة بدلاً من كلمات المرور.
خوارزمية فحص الصحة القياسية:
- ترسل الخدمة رسالة عشوائية
m
إلى وحدة التحكم ؛
- تحكم:
sign(private key, m)
؛
- ترسل وحدة التحكم توقيعًا إلى الخدمة ؛
- الخدمة:
verify(public key, signature, m)
.
الشيء الوحيد الذي قررناه بهذه الطريقة هو أننا
لم نعد نخزن "الأسرار" الشائعة على خدماتنا في شكل مفتوح أو مؤقت. هذا ليس ما نريد.
مصادقة EDS. المحاولة الثانية
لا نريد تخزين شيء على الخدمات. لتحقيق ذلك ، يمكننا إجبار أجهزتنا على إرسال مفاتيحهم العامة إلى الخدمة.
في المرحلة الأخيرة ، حلنا مشكلتين. الأول -
فحصنا أنهم قدموا مفتاح الخدمة . لدينا مفتاح عمومي ، مما يعني أننا صنعنا أيضًا مفتاحًا خاصًا. الثاني - تأكدنا من أن
الجهاز يملك مفتاحًا خاصًا ، والذي يقع في مكان ما على محرك أقراص فلاش USB. إذا كان بإمكان الجهاز توقيع شيء ما ، فسيحتوي على مفتاح خاص.
الآن سيرسل الجهاز أيضًا المفتاح العمومي إلى الخدمة. كيف تتحقق من أن أحدًا لم يعترض عليه ، ولم يزعجه ، وأن كل شيء يعمل؟
التحقق من المفتاح العمومي . نخلق أنفسنا مفتاح عام آخر. سيكون مفتاحنا كشركة مصنعة. هذا هو مفتاح الجذر "مفتاح الجذر الخاص + المفتاح العام". باستخدام هذا المفتاح السري الجذر في الإنتاج ، سنقوم بتوقيع المفتاح العام للجهاز وسنقوم بتخزين هذا التوقيع على الجهاز. يجب أن يرسل الجهاز مفتاحه العام وتوقيع المفتاح العام إلى الخدمة. الآن يمكن للخدمة التحقق من المفتاح العمومي للجهاز. إذا تم توقيعه باستخدام مفتاح الجذر الخاص ، فقد أصدرنا هذا المفتاح.
الشركة المصنعة فقط - يمكننا إنشاء وتخزين توقيع على الجهاز ، ولكن تحقق من كل شيء.
ننشر المفتاح العمومي على الموقع في قسم "جهات الاتصال". يمكن لأي شخص أخذها والتحقق من المفتاح العام للجهاز الذي أرسل الجهاز إلى الخدمة. ثم يمكنك التحقق من أن الجهاز نفسه لديه مفتاحه الخاص.
الخوارزمية العامة تبدو هكذا.
(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 بايت. من خلال مساعدتهم وسحرهم الرياضي ، يمكنك الاستمرار في إجراء اتصال بالمصافحة والتحقق من أن الجهاز يحتوي على المفتاح الخاص المقابل.
على الخادم ، نقوم فقط بتخزين مفتاح الشركة المصنعة (المفتاح العمومي الجذر).
ليس لدينا
التزامن بين الخدمات والإنترانت ، والتي تحدثنا عنها بالفعل. أيضا ، ليس لدينا أي
حماية ضد نسخ التفاصيل .
الشيء الوحيد الذي نسيناه هو
المصادقة . أرسل الجهاز مفتاحًا خاصًا ، وتأكدنا من أننا قمنا به وأصدرناه ، وتأكدنا من امتلاك الجهاز له. لكننا لا نعرف نوع الجهاز هذا ، ونحن ننتج الآلاف منهم.
لذلك ، طبقنا خدعة تسمى "الشهادة".
المصادقة والشهادات
في هذه الخطوة ، في كل السحر الرياضي مع التواقيع والشيكات الخاصة بهم ، نضيف
معلومات إضافية - شهادة . للقيام بذلك ، نقوم بتسجيل الدخول إلى المصنع ليس فقط المفتاح العمومي (المفتاح العمومي للجهاز) ، ولكن المفتاح مع معلومات إضافية.
معلومات إضافية في حالتنا.
- تاريخ الصنع والشركة المصنعة.
- تكوين النموذج والأجهزة.
- الرقم التسلسلي الذي يمكن من خلاله مصادقة الجهاز.
- خيارات: الأجهزة والبرامج. قد لا تختلف التكوينات المختلفة فعليًا عن بعضها البعض ، لكن الشهادة ستحتوي على معلومات حول ما دفعه العميل.
- اسم العميل ورقم الحساب.
سنقوم بتوقيع كل هذه المعلومات مع المفتاح العمومي مع مفتاح المنتج العمومي - الجذر العام. بعد ذلك ، ستذهب المعلومات إلى الخدمات وسيكون بمقدورها التأكد من صحتها. نظرًا لأن هذه هي خدماتنا وشركائنا ، فإنهم يثقون بنا.
حالة الهدف
يتم أيضًا حياكة المعلومات في المصنع ، ولا يلزم
تقديم الخدمات.
على الخادم نقوم بتخزين مفتاح الشركة المصنعة فقط.
استرداد الخسارة . نقوم بخياطة جميع المعلومات من الشهادات في ذاكرة فلاش الجهاز. من الناحية النظرية ، يمكن حذفها عن طريق الخطأ أو عن قصد ، ولكن لا يوجد شيء سري في هذه المعلومات في الشهادة. حتى التوقيع نفسه ليس سريًا - فهناك مفتاح عام والتوقيع بمفتاحنا. السر الوحيد في الشهادة هو حجم مبيعات الأجهزة بخيارات مختلفة.
يمكن تخزين الشهادة في المصنع وإرسالها إلى العميل إذا فقدها. نادراً ما يمحو العملاء منطقة خدمة الذاكرة على وجه التحديد. عادةً ما نقوم بذلك أثناء إجراء استرداد الجهاز: وصل الجهاز من العميل ، وتمريره بالكامل من خلال التهيئة ، وتمحى كل شيء ، وتم تنزيله مرة أخرى ، ويتم نسخ الشهادة من قاعدة بيانات المصنع.
ليس لدينا فقدان
الاسترداد وحماية النسخ
والمزامنة بين الخدمات .
في مرحلة المصادقة ، نتلقى الشهادة ونتحقق منها. نحن نتفهم نوع الجهاز - نحن نعرف الشركة المصنعة والطراز والرقم التسلسلي وما يستطيع وما لا يستطيع.
ترخيص
تسمح لك الشهادة بتخزين المعلومات للترخيص.
خدمة الصانع مجانا . معرفة الرقم التسلسلي للجهاز ، يمكنك منح حق الوصول إلى الجميع. في خدماتنا نعطي الوصول إلى جميع عملائنا قاعدة.
قوائم بيضاء من الأرقام التسلسلية . لخدمة شركائنا ، يمكنك إنشاء جدول مع قائمة بيضاء من الأرقام التسلسلية: "اشترى العميل Vasily منا اثنين من وحدات التحكم مع هذه الأرقام التسلسلية المرتبطة بحسابه"
الترخيص. يمكنك بيع شيء مقدمًا ، ثم السماح أو رفض الوصول
بناءً على الخيارات المحددة في الشهادة - وحدة تحكم مع ترخيص للنظام X.
لا توجد قاعدة مشتركة بين الخدمات أو الشركة المصنعة أو الشركة المصنعة للأنظمة. كل شيء يعمل بشكل حصري على المعلومات من وحدة التحكم التي وقعناها ، كشركة مصنعة ، عندما يتم المصادقة في النظام.
الشهادة المتوسطة
مشكلة فنية أخرى قمنا بحلها على الطريق. في المخطط الذي تحدثت عنه للتو ، هناك شهادة جذر من الشركة المصنعة - المفتاح الخاص الجذر. هناك حاجة مادية في كل مرة تقوم فيها بإنشاء الجهاز. ولكن إذا كان هناك العديد من الأجهزة ، فإن هذا المفتاح يحتاج إلى وصول مستمر لدائرة محدودة من الأشخاص. هذا أمر سيء ، لأنه في حالة فقده ، سيتعين عليك تحديث المفاتيح العامة على جميع الخدمات ، ويجب ألا يصل إلى المهاجمين. هذه مشاكل تنظيمية كبيرة. ولكن هناك حل.
نحن نقدم مفاتيح وسيطة لمجموعة من الأجهزة التي ليست مخيفة جدا ليخسرها.
فعلنا الشيء نفسه ، فقط السلسلة أطول.

مع شهادة الشركة الصانعة ، نوقع المفتاح الوسيط. جسديا ، هذا هو "محرك أقراص فلاش" ، والذي يعطى إلى رئيس الوزراء في المصنع لمدة يوم واحد. يحد الجهاز عدد الأجهزة التي يمكن أن يوقعها المفتاح. في منتصف المخطط ، أضفنا شهادة متوسطة ، وإلا لم يتغير شيء.
قفل المفاتيح آمن
في كل هذا ، ليس لدينا
حماية كافية
للمفتاح الخاص بالجهاز - لا يزال هذا الملف موجودًا على محرك أقراص فلاش USB. يمكن للمهاجم نسخها ، ولكن على الأرجح سيخسرها أو يفتح الوصول عن طريق الخطأ.
في الحالة المثالية ، سيكون من الجيد حماية المفتاح الخاص للجهاز من النسخ - وضعه في صندوق أسود.
الصندوق الأسود ينفذ 4 عمليات:
- داخل نفسه يولد مفتاحًا عند الطلب ، لكنه لا يعطي ؛
- يعطي المفتاح العمومي ؛
- يوقع رسالة
- يتحقق من التوقيع.
للتحقق من التوقيع ، تحتاج فقط إلى مفتاح عمومي ، لذلك ثلاث عمليات كافية.حسب فهمي ، يجب أن يكون هذا حلاً للأجهزة ، ويفضل أن يكون منفصلاً عن المعالج. هناك العديد من الخيارات ، أفضلها هو
معالج تشفير خاص داخل شركة نفط الجنوب أو كورقة منفصلة.
خيار الصندوق الأسود الأول الذي قمنا بمراجعته هو
وحدة CAAM في معالجات NXP i.mx 6 و 7 و 8 التي نستخدمها. المشكلة هي أنه يتم تنفيذه برمجيًا في ROM Boot الخاص بالمعالج.
قد تحتوي على أخطاء يمكن العثور عليها وحتى يتم استغلالها من خلال وظائف المعالج الأخرى. قبل عامين ، تم العثور على ثقب في هذه الوحدة النمطية التي مكنت من تجاوز التحقق من التوقيع عند تنزيل البرامج الثابتة. هذه ليست الوظيفة التي نحتاجها ، ولكن تبقى الرواسب. مشكلة أخرى هي أنه من الصعب استيراد المعالجات بهذه الوحدة إلى روسيا ؛ فهي تتطلب ملء الأوراق.
لذلك ، أخذنا شريحة منفصلة. أعترف بأمانة ، لقد اعتمدت على حقيقة أنه إذا لم نتمكن من إحضاره إلى روسيا ، فسنتوصل إلى شيء - الشريحة صغيرة ، وتكلف 1 دولار. ولكن تحول كل شيء بشكل جيد - فقد وجدوا
رقاقة MicroECip ATECC ، التي تحتوي بالفعل على جميع الأوراق.
رقاقة ATECC608A
هذه شريحة صغيرة منفصلة تكلف فلسا واحدا. يتم توصيل الشريحة عبر I2C - "أرجل" للمعالج ، يمكنك مشاركتها مع الأجهزة الطرفية الأخرى. رقاقة لديه pinout القياسية. استخدمنا الشريحة في الإصدارات الأولى من الجهاز وقمنا ببساطة بتثبيتها أعلى شريحة أخرى بنفس البروتوكول و pinout ، لأنها قياسية.
يمكن للرقاقة أن تفعل ما نحتاجه من هذه الشريحة: قراءة التواقيع ، مفاتيح المتجر ، وأكثر من ذلك بكثير.

الميزات:
- 16 فتحات رئيسية ؛
- يمكن قراءة توقيعات ECSDSA ، التجزئة ، MACs ، وتشفير AES ، يمكن DH ؛
- لديه مولد رقم عشوائي وعدادات التشفير.
- مرفقات: SOIC-8، DFN6؛
- البروتوكولات: I2C ، سلك واحد.
- ~0.7$@1000pcs.
كيفية العمل مع microcircuit
هناك
وثائق لائقة
لذلك ، ولكن تحت التجمع الوطني الديمقراطي. إذا كتبت على الفور إلى gamma.spb.ru ، فسيقومون بتقديمها لك في غضون أسبوعين. إذا كان في شركة أخرى - بعد 3 أشهر. لقد كتبنا إلى شركتين ، وعندما فعلنا كل شيء ، أجابنا تاجر رقاقة آخر.
هناك عدد قليل من الحواشي وهم أسوأ من المتوسط. هناك
برنامج على جيثب - مكتبة مع HAL. إنه أمر مضحك - الوثائق تحت NDA ، والبرامج الموجودة عليها على GitHub. لا يدعم البرنامج نظام Linux ، لكنه يدعم Raspberry Pi و Atmel MK - هذا يختلف قليلاً. يعتقد المطورون أنه يوجد على جميع المعدات ناقل I2C واحد فقط ، على سبيل المثال ، يتم استدعاء الأرجل كما في Raspberry Pi.
هناك
تكامل مع
OpenSSL - لا يعمل بشكل جيد ، لكنه يعمل.
لا توجد أمثلة في نظام Linux ولا يوجد عمل خاص
بالتخصيص .
رقاقة التخصيص
التخصيص هو أكبر صداع مع الشريحة.
المشكلة هي أن الشريحة يمكنها أن تفعل الكثير من الأشياء. يحتوي على 16 فتحة حيث يتم تخزين 16 مفتاحًا: بيانات المستخدم ، أو المفاتيح العامة ، أو التخزين المؤقت للفتحات الأخرى - هناك العديد من الخيارات.
تحتاج إلى تقييد الوصول إلى الفتحات بطريقة أو بأخرى ، وهناك أيضًا العديد من خيارات التكوين: التقييد بكلمة مرور ، المصادقة في فتحة أخرى ، بحلول وقت الوصول إلى المصانع.
في الجدول ، نوع المفتاح ، حق الوصول للقراءة والكتابة ، العلاقة بين الفتحات - SlotConfig ، KeyConfig.في قناع البت (16 بت) لكل مفتاح نستخدمه ، هناك أرقام مختلفة في كل مكان.
أتعس شيء هو أن منطقة التكوين هي لمرة واحدة ، والتي تحدد وظائف فتحات. لقد افسدت 50 رقاقة قبل القيام بكل شيء بشكل صحيح. الشريحة تعمل فقط
بعد قفل التكوين . بشكل منفصل ، هناك
قفل للفتحات الفرديةلا توجد وثائق في الأمثلة أو في البرنامج. هناك وثائق للبت الفردية ، ولكن كل شيء معقد هناك. في جميع الأمثلة من Microchip ، تمت كتابته: "قم بتنزيل مثل هذه الكتلة ، وسيعمل بك بطريقة أو بأخرى ، كما في مثال إرسال البيانات إلى Amazon"
استغرق الأمر الكثير من الوقت ، ولكن في هذه العملية قاموا بعمل أداة رائعة.
Atecc- فائدة فائدة
هذه أداة مساعدة لوحدة التحكم يمكنها أداء معظم وظائف الشريحة وتتيح لك العمل بسهولة أكبر. وهي متوفرة
على GitHub بموجب ترخيص MIT.
تستخدم الأداة المساعدة CryptoAuthLib. إنها تعرف كيفية العمل بشكل أكثر ودية مع منطقة التكوين ، وهي تعرف كيفية العمل مع SHA ، MAC ، ECDSA ، DH. الواجهة سهلة الاستخدام ، لأننا أنشأنا الأداة للاستخدام في البرامج النصية في المقام الأول. حقيقة أن الشخص يمكن أن يسبب ذلك هو ميزة جانبية. يمكن للأداة المساعدة إنشاء قائمة - خطة للأوامر: "أولاً ، خصص هذه المنطقة ، ثم اكتب مثل هذا المفتاح."
مثال على استدعاء الأداة المساعدة قابل للقراءة تمامًا.
atecc - b 10 - c 'serial' - c 'read-config /tmp/config.dump'
تم إنشاء الأداة المساعدة تحت Linux ، تحت AMD64 - إنها موجودة في حزمة دبيان.

أدوات التخصيص الأخرى
لدينا لوحة اكسل لقراءة البتات. إذا عرضت علينا فحص NDA باستخدام رقاقة ، فسنقدم لك ذلك.

لقد غطينا كل شيء من خلال الاختبارات ، نظرًا لوجود العديد من الخيارات التي يمكنك نسيانها بت واحد وسوف تقرأ بعض أوامر الخدمة مفتاحك الخاص. اختبارات اختبار الجهاز الحقيقي. إنهم يلجأون إلى الدائرة الصغيرة ويتحققون من التكوين الصحيح على الجهاز: هل يمكن قراءة هذه الفتحة ، هل يمكن عمل هذا التوقيع؟
بالتوازي مع البتات ، أنشأنا قائمة من الضمانات التي يجب أن يفي بها هذا الجهاز ، وتحققنا من كيفية عمل كل شيء. نحن نستخدم
إطار الخفافيش - شيء مثير للاهتمام للغاية. يبدو مثل هذا.
قائمة الاختبارات على سبيل المثال. يتم تمرير العلوي ، ولكن السفلي منها لا.الإعدادات في الأجهزة
لأنفسنا ، نستخدم شريحتين فقط للمهمة التي أتحدث عنها. في كل من نقوم بتخزين المفتاح الخاص للجهاز. الفرق هو أن الأول يرتبط
بشهادة دائمة ، صدرت في عام 1970 لمدة 200 عام.
ويرجع ذلك إلى حقيقة أنه في وقت إنترنت الأشياء لا تتم مزامنتها دائمًا. تتضمن البنية التحتية للشهادة التحقق من صلاحية الشهادة. إذا تعطلت المزامنة على الأجهزة ، فقد تفشل بعض الخدمات الحيوية ، على سبيل المثال ، VPN.
لذلك ،
فتحة واحدة هو لانهائي - دائم . يتم إنشاؤه مرة واحدة ولا يتغير طوال عمر الجهاز. بالنسبة لهذا المفتاح ، يتم إنشاء شهادة لمدة 200 عام - للشبكات المغلقة.
يتم تحديث فتحة أخرى. الحد الأقصى لعمر الشهادة هو سنة واحدة. يتم ذلك فقط في حالة تعرض شيء ما للخطر. يتم إنشاء مفتاح جهاز خاص قابل للتحديث مع انتهاء صلاحية فترة صلاحية شهادة الجهاز. يستخدم للمصادقة في الشبكات المفتوحة ، يتم تحديثه مرة واحدة في الشهر أو أقل ، بالإضافة إلى شهادة.
للمستخدمين ، أنشأنا مجموعات متعددة ، بما في ذلك عدة فتحات لمفاتيح ECDSA الخاصة. يمكن للمستخدمين إنشاء مفتاحهم في فتحة منفصلة إذا لم يثقوا في مفتاحنا الخاص. لهذا تحتاج إلى الثقة فقط رقاقة. يمكن للمستخدمين قراءة التوقيعات والقيام بالتشفير - لقد قدمنا كل ما تستطيع الشريحة القيام به.
لسوء الحظ ، لم يستخدم أحد ، لكننا نأمل ذلك.
البنية التحتية: المفاتيح المتوسطة
لقد قلت بالفعل أننا في مرحلة ما طبقنا شهادات وسيطة حتى لا نتألق بشهادة الجذر التي يجب ألا تضيع. لم يظهر أبدًا في المصنع.

الشهادات الوسيطة فعليًا هي شريحة ATECC508A. إنه يختلف قليلاً عن 608 ، ولكن في 508 ، هناك وظيفة أصبحت مفيدة للمفاتيح ، ولكن في 608 لم تعد هناك.
يتم توصيل الشريحة عبر محول USB-I2C. هذا هو USBISP مع البرامج الثابتة الصغيرة USB-i2c - مبرمج يمكن وميض في جسر USB-I2C. تقوم الشهادات الوسيطة بتوقيع شهادات الجهاز باستخدام المفتاح الخاص بها.
تحولت ميزات اثنين من microcircuit لتكون مفيدة لنا.
فتحة حماية كلمة مرور الأجهزة . يمكن برمجة الشريحة لقراءة التوقيع فقط في حالة استيفاء شرطين:
- عندما يكون الجهاز عالقًا في جهاز الكمبيوتر ؛
- كلمة المرور دخلت.
نعطي فورمان للإنتاج مفتاحًا متوسطًا وكلمة مرور لعدد من وحدات التحكم. وفقًا لذلك ، تحتاج إلى سرقة المفتاح وكلمة المرور من أجل الوصول. لقد حصلنا على هذه الفرصة مجانًا ، ولكنها تعمل على تحسين أمان النظام.
الحد من الأجهزة على عدد الاستخدامات . العداد التشفير داخل يمكن أن تزيد فقط. عندما يصل إلى حد محدد مسبقًا مرة واحدة ، فإن الدائرة الدقيقة لا توقع أي شيء آخر.

OpenSSL على العميل
دعنا نفكر كيف يعمل كل شيء على العميل. لدينا OpenSSL على وحدة التحكم. لم نخترع أي شيء - وهذا هو TLS العادي ، PKI العادي. نحتاج بالإضافة إلى ذلك مكتبة العميل. في الغالبية العظمى من برامج Linux ، يتم استخدامه للاتصال الآمن.
أخذنا الشفرة من رقاقة ، وأضفناها قليلاً ، ودعمت OpenSSL الطازجة
1.1. نتيجة لذلك ، فهو يعرف كيفية التعامل مع مفتاح الجهاز - الأجهزة تدعم كلمات المرور للمفاتيح الخاصة.
يبدو شيء من هذا القبيل.
openssl req -new -engine ateccx08 -keyform engine -key ATECCx08:00:04:C0:00 -subj "/CN=wirenboard-AP6V5MDG" -out device AP6V5MDG.csr
هذه دعوة إلى OpenSSL العادية وتعليمات لاستخدام وحدة المحرك المناسبة. يتم تعيين المفتاح هنا: العنوان والنموذج وآخر وحدتي بايت هو رقم الفتحة المستخدمة. يتم نقل كل شيء كما لو كان ملفًا رئيسيًا ، لكنه ليس ملفًا - فأنت بحاجة إلى الدخول إلى الجهاز.
SSL على الخادم
أي SSL يعمل على الخادم ، بما في ذلك OpenSSL. هناك حاجة إلى أي تعديلات والبنيات المخصصة على جانب الخادم. كل ما هو مطلوب على الخادم هو
التمكن من التحقق من سلسلة حزمة الشهادة (سيرت الجهاز + شهادة وسيطة) ،
وتخزين المفتاح العام لدينا ، الذي نشرناه على الموقع - Wiren Board ROOT CA.
يقول TLS القياسي أنه يجب على الطرفين مصادقة بعضهما البعض. — — . — 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
, . , : 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 , , , 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.