Защо сигурното provisioning принадлежи на производството
Свързано устройство, което излиза от завода без идентичност, трябва да се provision-ва на терен. Provisioning на терен означава ръчна стъпка (или уязвимо автоматично enrollment) при монтажа. И двете носят оперативни проблеми и риск за сигурността.
Provisioning от страна на производството дава на устройството уникална криптографска идентичност, преди да напусне линията. Устройството бутва, удостоверява се и се enroll-ва без ръчна намеса.
Secure elements
Microchip ATECC608 и NXP EdgeLock са често използвани secure elements за IoT. И двата поддържат:
- генериране на ECC частен ключ вътре в чипа (ключът никога не излиза)
- подпис и верификация на сертификати
- защита от replay чрез брояч
- tamper-evident поведение
Производствената линия генерира ключ вътре в secure element-а, подписва сертификат срещу root CA, записва сертификата в устройството и логва публичния ключ срещу серийния номер.
Enrollment на X.509 сертификати
X.509 е стандартният формат за сертификати. Enrollment от страна на производството обикновено следва тази схема:
- Secure element-ът генерира ECC ключова двойка (частният ключ остава заключен в чипа)
- Производствената система прочита публичния ключ
- Производствената система подписва сертификат чрез root CA, защитен от HSM
- Сертификатът се записва обратно в устройството
- Публичният ключ и certificate 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 attestation, attestation чрез Trusted Platform Module (TPM) и attestation със симетричен ключ.
И двете услуги позволяват на производствената линия да регистрира устройствата предварително, така че те да се enroll-ват автоматично при първото свързване с облака. Работен процес от страна на производството:
- Устройството се provision-ва с X.509 сертификат
- Certificate fingerprint на устройството се регистрира в облачния DPS
- Устройството бутва на терен, представя сертификата си и се enroll-ва автоматично
- Облакът го разпределя в правилната група и сваля конфигурацията
Custom PKI следва същата схема, само че с вътрешна инфраструктура вместо AWS или Azure.
Работен процес от страна на производството, който работи
- root CA, защитен от HSM в контролирана среда, достъпен през signing API
- генериране на ключ за всяко изделие вътре в secure element-а на линията
- подпис на сертификат през API call (без излагане на ключов материал)
- предварителна регистрация в облачния DPS като част от стъпката за provisioning
- запис за enrollment-а на всяко изделие в производствената база
- по желание, управление на revocation list за изведени от експлоатация или изгубени устройства
Чести грешки
- частният ключ на root CA се пази на производствената линия (не в HSM)
- един и същ ключ се прошива в няколко устройства („тестов режим, който е заминал в производството“)
- certificate fingerprint се логва, но не се регистрира предварително в облачния DPS
- provisioning се прави на ръка за няколко изделия и никога не се мащабира
Източници
- документация на AWS IoT Just-in-Time Provisioning
- документация на Microsoft Azure Device Provisioning Service
- документация на Microchip ATECC608 secure element
- документация на NXP EdgeLock secure element