1. Тема дня

Жизненный цикл identity:

text 
device produced
→ unique device_id
→ key pair
→ CSR
→ client certificate
→ mTLS
→ certificate rotation
→ revocation
→ decommission

Главная мысль: у каждого устройства должна быть собственная криптографическая идентичность. Производственная станция не должна записывать один общий пароль или private key на весь парк.

2. Зачем это нужно

Схема username=device/password=common опасна:

text 
утечка одного устройства -> компрометация всех.

Правильно:

text 
TC-0001842 -> unique private key -> unique client certificate -> mTLS

При компрометации отзывается один сертификат. Идентичность устройства должна связывать:

c 
device_id;
ESP32 MAC;
EC25 IMEI;
hardware revision;
client certificate fingerprint;
firmware release;
HIL result.

3. Теория

Серийный номер - не криптографическая identity

device_id, MAC, IMEI, STM32 UID - это инвентаризационные признаки. Private key доказывает владение identity.

Key pair

text 
private key: секрет, не покидает устройство;
public key: в сертификате, сервер проверяет подпись.

Для embedded часто удобно ECC P-256.

CSR

Device генерирует key pair, создает CSR и отправляет CA public key + proof. CA выпускает сертификат и не получает private key.

Модели provisioning

Плохо:

text 
один общий key/cert на весь парк.

Лучше:

text 
station генерирует unique key и записывает в устройство.

Еще лучше:

text 
key pair генерируется на устройстве или secure element;
station получает только CSR.

A/B credential slots

Ротация не должна перезаписывать active credentials:

text 
identity_a ACTIVE
identity_b PENDING

Новая identity активируется только после proof-of-possession/TLS probe.

Где хранить private key ESP32

Варианты:

text 
embedded in firmware: только лабораторно;
NVS Encryption + Flash Encryption: лучше;
secure element ATECC608A: сильнее;
новые ESP32 SoC с hardware-backed crypto: зависит от target.

Для классического ESP32-WROOM-32U внешний secure element - хороший вариант, если private key не должен быть извлекаемым software.

STM32

На STM32 private key можно хранить во внутренней защищенной Flash/TrustZone/Secure Storage или в STSAFE. STSAFE-A110 умеет on-chip key generation и ECDSA operations без выдачи private key MCU.

4. Типичные ошибки

  • Один сертификат на все устройства.
  • MAC/IMEI считается доказательством identity.
  • Private key генерируется в общем CI job.
  • Private key хранится в Git.
  • Backend получает private key вместо CSR.
  • Active сертификат перезаписывается без A/B.
  • Старый cert удаляется до проверки нового.
  • Server verification отключается, потому что есть client cert.
  • Key хранится в plaintext NVS.
  • PEM key попадает в debug log.
  • Certificate expiry не мониторится.
  • Bootstrap token один на всю партию.
  • Нет recovery path при потере credentials.

5. Практическое задание на 30-60 минут

Создай DEVICE_IDENTITY_POLICY.md:

markdown 
# Device identity policy
1. Every production device has a unique key pair.
2. A private key is never shared by multiple devices.
3. The backend receives CSR, never a device private key.
4. MAC, UID and IMEI are inventory attributes, not credentials.
5. Server certificate verification is always enabled.
6. Operational credentials are stored in A/B slots.
7. New credentials are tested before activation.
8. Old credentials are retained during a grace period.
9. Every credential has a generation and fingerprint.
10. Production private keys are never stored in Git or CI artifacts.
11. Lost credentials do not fall back to a common password.
12. Provisioning produces an auditable device record.

Создай development CA и device certificate через OpenSSL:

sh 
# Editorial addition: development CA only; not a production provisioning workflow.
cat > device.ext <<'EOF'
basicConstraints=critical,CA:FALSE
keyUsage=critical,digitalSignature
extendedKeyUsage=clientAuth
subjectAltName=URI:urn:traffic-controller:device:TC-DEV-0001
EOF
openssl x509 -req -in TC-DEV-0001.csr -CA dev-ca.crt -CAkey dev-ca.key \
  -CAcreateserial -out TC-DEV-0001.crt -days 365 -sha256 -extfile device.ext
openssl verify -purpose sslclient -CAfile dev-ca.crt TC-DEV-0001.crt

OpenSSL x509: подпись CSR и расширения сертификата

text 
openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out dev-ca.key
openssl req -x509 -new -key dev-ca.key -sha256 -days 3650 \
  -subj "/CN=Embedded Development CA" -out dev-ca.crt
openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out TC-DEV-0001.key
openssl req -new -key TC-DEV-0001.key -subj "/CN=TC-DEV-0001" -out TC-DEV-0001.csr

Добавь SAN:

text 
subjectAltName=URI:urn:traffic-controller:device:TC-DEV-0001
keyUsage=critical,digitalSignature
extendedKeyUsage=clientAuth

Проверь:

text 
openssl verify -CAfile dev-ca.crt TC-DEV-0001.crt

Добавь CLI identity info, который показывает fingerprint, issuer, SAN, generation, backend, но не private key.

6. Что почитать или попробовать дальше

  • ESP-TLS client certificate, NVS Encryption, ATECC608A integration.
  • STSAFE-A110 / X-CUBE-STSE01.
  • Device provisioning audit records и CSR enrollment.
Что CA должен получить при enrollment устройства согласно уроку?

Критерии: Явно сохраните границу private key.

Задание

Опишите безопасную A/B rotation credentials при identity_a ACTIVE и identity_b PENDING. Укажите момент активации новой identity и то, что нельзя удалять преждевременно.

Критерии самопроверки: Разделите запись, проверку и активацию; сохраняйте разные generations/fingerprints и не раскрывайте private key в диагностике.

Показать ответ автора

Записать новые credentials в неактивный/PENDING slot, проверить proof-of-possession и TLS probe, затем активировать новую identity. Не перезаписывать текущие active credentials и не удалять старый сертификат до проверки новой identity; сохранить предусмотренный grace/recovery path.