NXP SE050検証(証明書読み出し)(NXP SE050 cerificate extraction by using ESP32)

#はじめに#
2019/12/14に開かれた　IoTSecJPにてお時間をいただき
[セキュアエレメントとIoTデバイスセキュリティ](https://www.slideshare.net/KentaroMitsuyasu1/secure-element-for-iot-device)
と題してお話させていただきました。
その内容をベースにまとめていきたいと思います。

#メーカー出荷時設定の証明書#

下記によると　メーカーからクラウド登録用のキーペアと証明書がデバイスに登録されているとのこと。
https://www.nxp.com/docs/en/application-note/AN12436.pdf

今回使用しているデバイスがSE050(C)になるので
Table 8. Variant Cの項目を確認する。 

以下の5種類のキーペアと証明書が格納されている。
IoT Connectivity(ECC256)
Cloud Onboarding RSA(RSA2048)
Cloud Onboarding ECC(ECC256)
Attestation, proof of origin(ECC256)
Cloud Onboarding RSA(RSA4096)



この中で、下記をチェックしてみる。
Cloud Onboarding ECC 

Cloud connection key 0, ECC256, Die Individual
Key: 0xF0000100

Cloud Connectivity Certificate 0, ECC signed
Cert: 0xF0000101

鍵の管理はATECC608Aはスロット単位での管理だったが、
SE050はデバイス内ではオブジェクトIDというint32の値で管理されているようだ。

上記は、ユーザーが書き換えることができるらしい（Erasable by customer）

これらを読み出してみる。

基本的にはNXPの提供するチップと開発環境には、pyssscliというツールで
デバイスの操作ができるらしいが、ESP32に無いのと、動作の理解のために
C言語で操作してみる。
参考の[ソースコード](https://github.com/kmwebnet/NXP-SE050-Test-Get-Cert)をGithubへアップした。



```
ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:6172
load:0x40078000,len:10112
load:0x40080400,len:6492
entry 0x40080750
I (29) boot: ESP-IDF 3.30300.190916 2nd stage bootloader
I (29) boot: compile time 13:10:52
I (29) boot: Enabling RNG early entropy source...
I (34) boot: SPI Speed      : 40MHz
I (38) boot: SPI Mode       : DIO
I (42) boot: SPI Flash Size : 4MB
I (46) boot: Partition Table:
I (50) boot: ## Label            Usage          Type ST Offset   Length
I (57) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (64) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (72) boot:  2 factory          factory app      00 00 00010000 00100000
I (79) boot: End of partition table
I (84) esp_image: segment 0: paddr=0x00010020 vaddr=0x3f400020 size=0x10a14 ( 68116) map
I (116) esp_image: segment 1: paddr=0x00020a3c vaddr=0x3ffbdb60 size=0x01ef8 (  7928) load
I (119) esp_image: segment 2: paddr=0x0002293c vaddr=0x40080000 size=0x00400 (  1024) load
I (123) esp_image: segment 3: paddr=0x00022d44 vaddr=0x40080400 size=0x09468 ( 37992) load
I (146) esp_image: segment 4: paddr=0x0002c1b4 vaddr=0x00000000 size=0x03e5c ( 15964)
I (151) esp_image: segment 5: paddr=0x00030018 vaddr=0x400d0018 size=0x2f544 (193860) map
I (223) boot: Loaded app from partition at offset 0x10000
I (223) boot: Disabling RNG early entropy source...
I (224) cpu_start: Pro cpu up.
I (227) cpu_start: Application information:
I (232) cpu_start: App version:      1.0.0
I (237) cpu_start: Compile time:     Feb 10 2020 13:10:57
I (243) cpu_start: ELF file SHA256:  0000000000000000...
I (249) cpu_start: ESP-IDF:          3.30300.190916
I (255) cpu_start: Starting app cpu, entry point is 0x40081cfc
I (0) cpu_start: App cpu up.
I (265) heap_init: Initializing. RAM available for dynamic allocation:
I (272) heap_init: At 3FFAE6E0 len 0000F480 (61 KiB): DRAM
I (278) heap_init: At 3FFC1760 len 0001E8A0 (122 KiB): DRAM
I (284) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM
I (291) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (297) heap_init: At 40089868 len 00016798 (89 KiB): IRAM
I (303) cpu_start: Pro cpu start user code
I (322) cpu_start: Chip Revision: 1
W (322) cpu_start: Chip revision is higher than the one configured in menuconfig. Suggest to upgrade it.
I (326) cpu_start: Starting scheduler on PRO CPU.
I (0) cpu_start: Starting scheduler on APP CPU.
       App:INFO :PlugAndTrust_v02.12.00_20191122
       App:INFO :If you want to over-ride the selection, use ENV=EX_SSS_BOOT_SSS_PORT or pass in command line arguments.
       sss:INFO :atr (Len=35)
      00 A0 00 00    XX XX XX XX    XX XX XX XX    XX XX XX XX
      XX XX XX XX    XX XX XX XX    XX XX XX XX    XX XX XX XX
      XX XX XX
       sss:WARN :Communication channel is Plain.
       sss:WARN :!!!Not recommended for production use.!!!
cert object ID: f0000101
-----BEGIN CERTIFICATE-----
MIICIDCCAcagAwIBAgIUBABQASGuSaC8AWgEfpMKlGaAAAAwCgYIKoZIzj0EAwIw
.... 
Rg+5EqERk9BUxItxwxStkyhWZU4=
-----END CERTIFICATE-----
-----BEGIN UID-----
BABQ...............A
-----END UID-----
       App:INFO :ex_sss Finished
```

読み出し完了

#AWS　IoTへの接続について#
上記証明書を使って、AWS IoTへ接続できるチュートリアルがあるが、
[AWS IoT Core Multi-Account Registration (Beta)](https://pages.awscloud.com/iot-core-early-registration.html)というAWS IoT側の
新しい接続方法を使うものらしい。

「AWS IoT では、"Multi-Account Registration" と呼ばれる AWS IoT Core の新しい機能が発表されました。現在、ベータ版が利用可能です。この新しい機能では、デバイスを AWS IoT Core に接続するときにアカウント情報を設定しておくと、AWS アカウント間でのデバイスの移動をすばやく行うことができます。この機能の使用を選択すると、Transport Layer Security (TLS) セッションの一部としてデバイスから送信される Server Name Indication (SNI) の文字列を使って、適切な AWS IoT エンドポイントにルーティングすることができます。
この機能によって、簡素化された登録手順のオプションが提供されます。AWS IoT への登録に認証機関 (CA) は必要なく、デバイス証明書を登録できます。これにより、デバイスの登録プロセスを簡素化し、迅速化することができます。
この機能の詳細と使用の申請については、AWS IoT Core Multi-Account Registration ベータ版のページをご覧ください。」

上記によると、クラウド接続の認証へ、TLSセッションに埋め込まれたSNIを使用するという仕掛けで、自前でCAを用意する必要がなくなるとのことらしい。

AWSへベータテストの申請を行って、返信待ちとなったので、いったんここまでとする。