Azure IoT Centralのデバイス認証を何回も何回も何回も聞かれて都度説明するのが面倒なので、徹底的に調べて記事にしました。
結論
- デバイス認証の仕組みはSAS、X.509、TPMの3種類が使える。
- SASとX.509は1デバイスずつと一度に複数デバイスを許可することができる。
- TPMは1デバイスずつ許可。一度に複数デバイスを許可はできない。
- 一度に複数デバイス許可では、認証時に自動的にAzure IoT Central上のデバイスを作成させることができる。
- 設定画面はデバイス > {device} > 接続とアクセス許可 > デバイス接続のグループの2画面ある。きちんと理解して適切な画面を使う。
Azure IoT Central上のデバイス認証設定画面
デバイス > {device} > 接続
(Devices > {device} > Connect
)とアクセス許可 > デバイス接続のグループ
(Permissions > Device connection groups
)の2箇所あります。
認証の仕組み(SAS、X.509、TPM)と許可の数(個別、グループ)で表にするとこのようになります。
個別 - individual | グループ - group | |
---|---|---|
SAS | [デバイスSAS] A3-1 |
[グループSAS] B1 (A1) |
X.509 | [デバイスX.509] A3-2 |
[グループX.509] B2 (A2) |
TPM | [デバイスTPM] A3-3 |
- |
A1はB1と同じですが、グループSASキーから計算で生成できるデバイスSASキーを手早く確認したいときに見ることがあります。(グループSASキー?デバイスSASキー?何のこと?と思うでしょうか、あまり気にせず読み進んでください。)
A2はB2と同じです。グループX.509を複数登録しているときに見るかもしれませんが、レアケースなのでA2は無視して良いです。
SAS
Azure IoT Centralのデバイス認証で使うSASは、リソースURIと有効期限をSASキーで署名したSASトークンで認証する方式のことです。(詳しくはこちら。)
漏れないようにする情報はSASキーとSASトークンです。SASトークンは、短い有効期限で運用して、漏れても被害が起きにくいようにします。

デバイスSAS
デバイスSASによる認証では、デバイスSASキーをデバイスに保持しておき、Azure IoT Centralと通信する際にデバイスSASキーからSASトークンを算出して接続、認証します。
デバイスSASキーはAzure IoT Centralから発行されるものではありません。echo `openssl rand -base64 64 | tr -d '\n'`
のように自らデバイスSASキーを生成してAzure IoT Centralに登録します。(試した記事はこちら。)
- デバイスSASキーを生成(例えば、
openssl rand
) - デバイスSASキーをA3-1. Shared access signature(SAS)画面に登録
- デバイスSASキーをデバイスに保持
- Azure IoT Central接続時にSASトークンで認証(リソースURI、有効期限、デバイスSASキーから算出)
グループSAS
グループSASによる認証では、Azure IoT Centralが発行したグループSASキーを用いて認証します。デバイスに(グループSASキーではなく)デバイスSASキーを保持しておき、デバイスSASと同様に接続、認証します。
グループSASキーはAzure IoT Centralから発行されます。
さて、デバイスSASキーはどこから手に入れるのでしょうか?
デバイスSASキーは、グループSASキーとデバイスIDから算出できます。また、(Azure IoT Centralでデバイスを作成すれば)Azure IoT CentralのA1. Shared access signature(SAS)画面でも確認できます。

コードによる算出も可能なので、独自にデバイスSASキー生成ツールを作ることもできます。ただし、デバイスにグループSASキーを保持しておき、必要な都度、デバイスSASキーを生成する仕組みにはしないでください。グループSASキーが漏れて自由にデバイスSASキーを作られてしまう可能性があるからです。
- グループSASキーをB1. Shared access signature(SAS)画面から取得
- デバイスSASキーを算出(グループSASキー、デバイスIDから算出)
- デバイスSASキーをデバイスに保持
- Azure IoT Central接続時にSASトークンで認証(リソースURI、有効期限、デバイスSASキーから算出)
X.509
Azure IoT Centralに接続するTLS(Transport Layer Security)で、クライアント証明書としてデバイス証明書を提示して認証する方式のことです。(詳しくはこちら。)
TLSとPKIについては、書籍「暗号と認証 最強の指南書」で理解が深まりました。おすすめ。
漏れないようにする情報はデバイス秘密キーです。

デバイスX.509
デバイスX.509による認証では、デバイス証明書とデバイス秘密キーをデバイスに保持しておき、Azure IoT Centralと通信する際のTLSの相互認証でクライアント証明書にデバイス証明書を提示して認証します。
デバイス証明書とデバイス秘密キーはAzure IoT Centralから発行されるものではありません。openssl ecparam
などで自ら生成します。そして、デバイス証明書はAzure IoT Centralに登録します。(試した記事はこちら。)
- デバイス証明書とデバイス秘密キーを生成(例えば、
openssl ecparam
+openssl req
) - デバイス証明書をA3-2. 証明書(X.509)画面に登録
- デバイス証明書、デバイス秘密キーをデバイスに保持
- Azure IoT Central接続時にTLSの相互認証で認証(デバイス証明書、デバイス秘密キー)
グループX.509
デバイスX.509と同様ですが、Azure IoT Centralへ登録する証明書がデバイス証明書ではなく、デバイス証明書の署名者の証明書(CA証明書)です。(試した記事はこちらとこちら。)
- CA証明書とCA秘密キーを生成(例えば、
./certGen.sh create_root_and_intermediate
) - 署名したデバイス証明書とデバイス秘密キーを生成(例えば、
./certGen.sh create_device_certificate_from_intermediate
) - CA証明書をB2. 証明書(X.509)画面に登録
- デバイス証明書、デバイス秘密キーをデバイスに保持
- Azure IoT Central接続時にTLSの相互認証で認証(デバイス証明書、デバイス秘密キー)
デバイスTPM
WIP
(まだ試していないので、、、試した後に書く。)
(詳しくはこちら。)
お願い
読んでみても「意味わからねー」という方は、お気軽にコメントください。
(みんなが悩まないように、記事を改善したいので。)
参考リンク
- IoT Central のデバイス認証の概念 / Microsoft Learn
- SASトークン構造 / Microsoft Learn
- ComputeDerivedSymmetricKeyコード / SeeedJP
- IoT での X.509 CA 証明書の使用方法を理解する / Microsoft Learn
- TPM の構成証明 / Microsoft Learn
- 暗号と認証 最強の指南書 / 日経BOOKプラス
- Azure_IoT_Central_ESP32をSeeed Studio XIAO ESP32C3で動かしてみた(個別SAS) / matsujirushi
- Azure_IoT_Central_ESP32をSeeed Studio XIAO ESP32C3で動かしてみた(グループSAS) / matsujirushi
- Azure_IoT_Central_ESP32をSeeed Studio XIAO ESP32C3で動かしてみた(個別X.509) / matsujirushi
- Azure_IoT_Central_ESP32をSeeed Studio XIAO ESP32C3で動かしてみた(グループX.509) / matsujirushi
- Azure_IoT_Central_ESP32をSeeed Studio XIAO ESP32C3で動かしてみた(グループX.509 その2) / matsujirushi