Зошто безбедното провизирање е дел од производството
Поврзан уред што се испорачува без идентитет мора да биде провизиран на терен. Провизирањето на терен значи рачен чекор (или ранливо автоматско вклучување) при инсталацијата. И двете носат оперативни проблеми и безбедносна изложеност.
Провизирањето од страна на производството му дава на уредот единствен криптографски идентитет уште пред испораката. Уредот се подига, се автентицира и се регистрира без рачна интервенција.
Secure elements
Microchip ATECC608 и NXP EdgeLock се вообичаени secure elements за IoT. Двата поддржуваат:
- Генерирање ECC приватен клуч во самиот чип (клучот никогаш не излегува)
- Потпишување и проверка на сертификати
- Заштита од replay-напади заснована на бројач
- Однесување што открива неовластен пристап
Производствената линија генерира клуч во secure element-от, потпишува сертификат со root CA, го запишува сертификатот во уредот и го логира јавниот клуч со серискиот број.
Регистрација на X.509 сертификат
X.509 е стандардниот формат за сертификати. Регистрацијата од страна на производството обично го следи овој шаблон:
- Secure element-от генерира ECC пар клучеви (приватниот клуч е заклучен во чипот)
- Производствениот систем го чита јавниот клуч
- Производствениот систем го потпишува сертификатот користејќи root CA поддржана од HSM
- Сертификатот се запишува назад во уредот
- Јавниот клуч и fingerprint-от на сертификатот се логираат со серискиот број
Приватниот клуч на root CA никогаш не доаѓа во допир со производствената линија. Тој е во HSM во контролирана средина.
AWS IoT и Azure DPS
AWS IoT поддржува Just-in-Time Provisioning (JITP) и Multi-Account Registration. Azure Device Provisioning Service (DPS) поддржува X.509 атестација, атестација преку Trusted Platform Module (TPM) и атестација со симетричен клуч.
И двата ѝ овозможуваат на производствената линија однапред да ги регистрира уредите за тие автоматски да се вклучат при првото поврзување со cloud-от. Работниот тек од страна на производството:
- Уредот е провизиран со X.509 сертификат
- Fingerprint-от на сертификатот на уредот е регистриран во cloud DPS
- Уредот се подига на терен, го презентира сертификатот и се регистрира автоматски
- Cloud-от го доделува уредот на соодветната група и презема конфигурација
Сопствената PKI го следи истиот шаблон, со внатрешна инфраструктура наместо AWS или Azure.
Работен тек од страна на производството што функционира
- Root CA поддржана од HSM во контролирана средина, со пристап преку signing API
- Генерирање на клуч по единица во secure element на линијата
- Потпишување на сертификат преку API повик (без изложен криптографски материјал)
- Однапред регистрирање во cloud DPS како дел од чекорот за провизирање
- Запис за регистрација по единица во производствената база
- По избор, управување со список за отповикување за уреди на крај од работниот век или изгубени уреди
Чести грешки
- Приватниот клуч на root CA се чува на производствената линија (не во HSM)
- Истиот клуч е запишан во повеќе уреди („тест-режим што се испорачал“)
- Fingerprint-от на сертификатот е логиран, но не е однапред регистриран во cloud DPS
- Работниот тек за провизирање е направен рачно на неколку единици, никогаш не е скалиран
Извори
- Документација за AWS IoT Just-in-Time Provisioning
- Документација за Microsoft Azure Device Provisioning Service
- Документација за Microchip ATECC608 secure element
- Документација за NXP EdgeLock secure element