AWS IoTにおけるデバイスへの認証情報のプロビジョニング

© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
AWS IoTにおけるデバイスへの
認証情報のプロビジョニング
アマゾンウェブサービスジャパン株式会社

© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Amazon Confidential and Trademark.
飯塚将太
デジタルトランスフォーメーション本部
IoT Specialist Solution Architect
IoT のワークロードを持つお客様の技術支援を担当

お伝えしたいこと
• 認証情報の漏洩リスクを考慮すると、個別の認証情報を
埋め込むことがベストプラクティス
• AWS IoTでは個別の認証情報を埋め込む様々な方法を
用意
• お客様にとって最適な方法を選択可能
• 認証情報の埋め込みは検討段階から考慮する必要がある

本セッションで学べること
1. IoTデバイスにおける認証のベストプラクティス
2. AWS IoTにおける証明書発行とデバイス登録の方式
それぞれの発行や登録方式の
• 有効なケース
• 手順
• 差異
• メリット・デメリット

IoTデバイスの認証における要件
特徴/制約
• 必ずしもユーザが介在するとは限らない
• デバイスに対し、物理攻撃やネットワーク攻撃の
リスクが生じる
要件
サーバとデバイス単体で安全に認証したい

サーバとデバイス単体で安全に認証したい
個別のデバイス証明書を用いて認証する
考慮ポイント
1. 認証情報を不正に取得されないよう保存する
2. 認証情報が漏れた場合のリスクを最小化する
秘密鍵証明書

認証情報を不正に取得されないよう保存する
認証情報をセキュア領域に保存する
認証情報の保存および認証操作に、
• Trusted Platform Module
• Hardware Security Module
などのハードウェア保護モジュールを使用する

認証情報が漏れた場合のリスクを最小化する
2. デバイス毎に最小権限
のみを与える
1. デバイス証明書を個別に
無効化できるようにする

デバイス証明書を個別に無効化できるようにする
対象デバイスの認証情報を無効化
影響
対象デバイスのみがクラウドへ接続
不能に

仮に共通の秘密鍵を使用して漏洩が起きると・・?
無効化時の影響範囲も
全デバイスに及ぶ
無効化
全デバイスが不正利用
されるリスクがある

個別の秘密鍵を使用することによるリスクの最小化
対象デバイスのみが不正
利用されるリスクがある
無効化
無効化時対象デバイスのみ
がクラウドへ接続不能に

デバイス毎に最小権限のみを与える
認証情報が漏洩しても、クラウドや
他デバイスに対しての操作が制限さ
れ、リスクを最小化できる

認証・認可におけるベストプラクティス
デバイスに個別の認証情報を割り当てる
認証情報をセキュア領域に保存する
認証情報の生成、配布、無効化を行う仕組みを
導入する
デバイス毎に最小権限のみ与える

AWS IoT Coreでの認証手段
1. Amazon Cognito
• スマホ連携など、画面や入力装置があるデバイスで利用可能
• 人によるID/Passの入力ができない場合はマッチしない
2. AWS IAM
• セキュリティクレデンシャルベースでの認証
• 作成数に制限があるため、デバイスの規模に適用可能か確認
3. X.509クライアント証明書
• TLS相互認証
• 作成数に上限なし、証明書の持ち込みも可能
4. カスタム認証
• 別の認証方式をサポート

TLS相互認証

TLS相互認証
User ID
Password
証明書秘密鍵

TLS相互認証
User ID
Password
証明書秘密鍵
各ユーザを認証するためのもの
ユーザごとに異なる

TLS相互認証
User ID
Password
証明書秘密鍵
証明書秘密鍵
証明書秘密鍵
AWS IoT Core

TLS相互認証
User ID
Password
証明書秘密鍵
証明書秘密鍵
証明書秘密鍵
各デバイスを認証するためのもの
デバイスごとに異なる
AWS IoT Core

相互認証におけるクライアント認証の流れ
簡略化のためサーバ認証を省略しています
理解しやすさを優先しており、
正式な相互認証のシーケンスと一部異なる点があります
秘密鍵
証明書

1. デバイスからAWS IoT
へデバイス証明書を送信

2. デバイス証明書を署名するCAがAWS IoTも
しくは登録済みのCAであることを確認 & デバイ
ス証明書がサーバに登録済みであることを確認

3. デバイス証明書から抽出され
る公開鍵で今回の通信に利用す
る共通鍵を暗号化して送付

4. 暗号化された共通鍵を
デバイスの秘密鍵で復号

5. 復号した共通鍵で暗
号化して通信を開始

秘密鍵
証明書

どうやってデバイス
個別に組み込むか? どのCAを利用
するか?
どうやって
AWS IoTに
登録するか?
秘密鍵
証明書

デバイスへの証明書埋め込み方法
量産直前になってお客様からよく聞かれる話ですが、
• 量産前に検証しなければならない
• 後から変更しにくい
ため、検討段階から考慮しないと困ることが多い

AWS IoTにおける証明書発行とデバイス登録の方式
1. AWS IoTによる秘密鍵・証明書発行＆事前登録
(デバイスキッティング時登録)
2. AWS IoTによる証明書発行＆事前登録
3. Fleet Provisioning登録
4. 独自CAによる証明書発行＆AWS IoTへの事前登録
5. 独自CAによる証明書発行＆JITRによる登録
6. 独自CAによる証明書発行＆JITPによる登録
7. CA登録無しの証明書登録（マルチアカウント登録）
AWS IoTではこのように様々な選択肢を用意

どの方式が最適かは、これらの条件に左右される
• 会社のセキュリティーポリシー
• 生産設備や出荷プロセスで対応可能か
• デバイス数
• 認証局を運用できるか
• 複数の環境で同一の証明書を利用したいか
• Stage, Prodなど、出荷までのフェーズで変わる場合

どの登録方式を使うのが良いのか？
どの証明書を用いるか
秘密鍵がイン
ターネットを
通るのはNG
製造時に個別
証明書を埋め
込むのが困難
セキュアチッ
プでベンダ
CAを利用
複数アカウント
で同じ証明書を
利用したい
Amazonが管理する
CAで証明書を発行
• CAの運用は不要
• 証明書の有効期限は
固定
AWS IoTによる秘密鍵・
証明書発行＆事前登録
No No No No
AWS IoTによる証明書発
行＆事前登録
Yes(*1) No No No
Fleet Provisioning登録 Yes(*1) Yes No No
Amazon以外のCAで
発行した証明書を利用
• 証明書の有効期限を
管理可能
• CAの運用が必要
独自CAによる証明書発行
＆AWS IoTへの事前登録
Yes No Yes Yes(*2)
JITRによる登録 Yes Yes No Yes(*2)
JITPによる登録 Yes Yes No Yes(*2)
CA登録無しの証明書登録
（マルチアカウント登録）
Yes Yes(*3) Yes Yes
要件
どうやってAWS
IoTに登録するか
(*1) CSRを用いた場合
(*2) 同一リージョンでは不可
(*3) クレデンシャルが必要

Amazonが管理するCAで
証明書を発行する場合
CAの運用は不要
証明書の有効期限は固定

簡単に証明書と秘密鍵を発行可能な
AWS IoTによる
秘密鍵・証明書発行＆事前登録
• 制約が少ない
場合に有効

1. AWS IoTに秘密鍵と証明書の発行を依頼
(access keyとsecret keyが必要)

2. 証明書・秘密鍵を発行
してデバイスに返す
秘密鍵
証明書

秘密鍵
証明書
3. 証明書をデバイスのス
トレージに、秘密鍵をセ
キュアストレージに保存

AWS IoTによる秘密鍵・証明書発行＆事前登録
1. AWS IoTに秘密鍵と証明書の発行を依頼
(access keyとsecret keyが必要)
秘密鍵
証明書
2. 証明書・秘密鍵を発行
してデバイスに返す

メリット
• 証明書と同時にデバイス登録しておくと、デバイスが起動したらす
ぐ使える
• 最も簡単な発行及び登録方法であるため検証や開発時はこれで良い
デメリット
• 証明書・秘密鍵の発行、デバイスへの焼き込み、AWS IoTへデバ
イスを登録する仕組みを生産設備に組み込む必要がある
• 生産時に工場がAWS IoTに接続する必要がある
• 製造時に登録されるため、使われるかわからないデバイス情報も登
録される
• 秘密鍵がネットワークを通る

秘密鍵がネットワークを通らない
AWS IoTによる
証明書発行＆事前登録
• 簡単に証明書を発行可能
• 秘密鍵をネットワークに通したくない場合に有効

秘密鍵
1. デバイスの
秘密鍵を作成

2. CSRを生成してAWS
IoTに署名をリクエスト
秘密鍵
証明書署名要求
CSR
CSR

3. デバイス証明書を発
行してデバイスに返す
秘密鍵
証明書
CSR

秘密鍵
証明書
CSR

AWS IoTによる証明書発行＆事前登録
1. デバイスの
秘密鍵を作成
3. デバイス証明書を発
行してデバイスに返す
秘密鍵
証明書
CSR
CSR
2. CSRを生成してAWS
IoTに署名をリクエスト

メリット
• 事前に証明書とデバイスの登録しておくと、デバイスが起動したら
すぐ使える
• 秘密鍵がデバイスから外に出ない
デメリット
• 証明書・秘密鍵の発行、デバイスへの焼き込み、AWS IoTへデバ
イスを登録する仕組みを生産設備に組み込む必要がある
録される

デバイスの登録及びその証明書の発行をデバイスの初回接続時に行う
Fleet Provisioning登録
• 大量のデバイスを初回接続時にAWS IoTに登録させ、AWS IoTに
認証情報を発行させたい場合に有効
https://docs.aws.amazon.com/iot/latest/developerguide/provision-wo-cert.html

Fleet Provisioningでのプロビジョニング方式
1. 認証ユーザー
• スマホ連携などができる場合には有効な手段
• スマホ連携などによってユーザーを認証してプロビジョニングする
https://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/provision-wo-cert.html#trusted-user
2. クレーム証明書
• スマホ連携できなくても認証情報を配布する手段
• 事前に埋め込んだ共通証明書を用いてプロビジョニングする
https://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/provision-wo-cert.html#claim-based

1. プロビジョニング
テンプレートを登録
認証ユーザーを用いたプロビジョニング
（事前設定）

2. クレーム証明書・秘密鍵を発行
を許可するためのIAM Roleを作成
（事前設定）

1. Cognitoで認証してクレーム権限を
持つRoleのクレデンシャルを受け取る
（各デバイスのセットアップ時）

2. クレーム証明書・
秘密鍵をリクエスト

3. 有効期限5分の一時的なクレーム証明書・
秘密鍵をIoT Coreが作成し、有効化して返却

4. クレーム証明書・秘
密鍵をデバイスに仮置

1. Cognitoで認証してクレーム権限を
持つRoleのクレデンシャルを受け取る
2. クレーム証明書・
秘密鍵をリクエスト
4. クレーム証明書・秘
密鍵をデバイスに仮置
3. 有効期限5分の一時的なクレーム証明書・
秘密鍵をIoT Coreが作成し、有効化して返却

5. クレーム証明書を用いて
個別証明書をリクエスト
デバイス側で事前に秘密鍵
を持っている場合にはCSR
を投げることも可能

6. 個別の証明書、秘密
鍵、トークンが発行

7. デバイスに個別の証明書・秘密鍵を保存
プロビジョニング後はこの情報を用いて接続

8. クレーム証明書・秘密鍵とトークンを
使って、プロビジョニングをリクエスト

8.5. (option) Lambdaでリ
クエストされたデバイス情報
が正しいかを検証

9. Thing、Policyがテンプ
レートに合わせて作成され、
証明書と紐づく

9. Thing、Policyがテンプ
レートに合わせて作成され、
証明書と紐づく
7. デバイスに個別の証明書・秘密鍵を保存
プロビジョニング後はこの情報を用いて接続
6. 個別の証明書、秘密
鍵、トークンが発行
8.5. (option) Lambdaでリ
クエストされたデバイス情報
が正しいかを検証
5. クレーム証明書を用いて
個別証明書をリクエスト
8. クレーム証明書・秘密鍵とトークンを
使って、プロビジョニングをリクエスト
デバイス側で事前に秘密鍵
を持っている場合にはCSR
を投げることも可能

クレーム証明書を用いたプロビジョニング
（事前設定）

（事前設定）
2. クレーム証明書・秘密鍵
をIoT Coreで発行
プロビジョニング用の権限
だけをポリシーに付与

をすべてのデバイスに格納
（事前設定）

をすべてのデバイスに格納
（事前設定）
をIoT Coreで発行
プロビジョニング用の権限
だけをポリシーに付与

（各デバイスの初回接続時）
を使って証明書・秘密鍵の
発行をリクエスト
0. デバイス側で事前に秘密
鍵を持っている場合には
CSRを投げることも可能

2. 個別の証明書・秘
密鍵、トークンが発行

3. デバイスに個別の証
明書・秘密鍵を保存
プロビジョニング後は
この情報を用いて接続

とトークンを使って、プロ
ビジョニングをリクエスト

4.5. (option) AWS Lambda
でリクエストされたデバイス
情報が正しいかを検証

5. Thing、Policyがテ
ンプレートに合わせて
作成、証明書が有効に

6. クレーム証明書を用い
た接続を切断し、個別証
明書を用いた接続を開始

5. Thing、Policyがテ
ンプレートに合わせて
作成、証明書が有効に
3. デバイスに個別の証
明書・秘密鍵を保存
プロビジョニング後は
この情報を用いて接続
とトークンを使って、プロ
ビジョニングをリクエスト
を使って証明書・秘密鍵の
発行をリクエスト
0. デバイス側で事前に秘密
鍵を持っている場合には
CSRを投げることも可能
6. クレーム証明書を用い
た接続を切断し、個別証
明書を用いた接続を開始
2. 個別の証明書・秘
密鍵、トークンが発行
4.5. (option) AWS Lambda
でリクエストされたデバイス
情報が正しいかを検証

メリット
• デバイスに個別の証明書と秘密鍵を事前に組み込む必要がないので、
デバイスの生産が楽
• 生産時に工場がAWS IoTに接続しなくて良い
• 個別の証明書発行やデバイス登録する構成を組まなくて良い
• 人による認証を行う場合は、初めに証明書自体事前が入っていなく
て良い
デメリット
• クレーム用の共通証明書が流出した場合を考慮しておく必要がある
• デバイス側でプロビジョニングのリクエストや受け取りを行う実装
が必要

Amazon以外のCAで発行した
証明書を利用する場合
自社でCAを管理したい場合
証明書の有効期限を管理可能
複数のアカウントやリージョンで同一証明書を用いたい場合
CAの運用が必要

Amazon以外のCAで発行した証明書を利用する
独自CAによる証明書発行＆
AWS IoTへの事前登録
• 証明書の有効期限を設定したい場合に有効
https://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/manual-cert-registration.html#manual-cert-registration-cli

独自CAによる証明書発行＆AWS IoTへの事前登録
0. 独自CAの証明書
を AWS IoTに登録

1. デバイスの
秘密鍵を作成
秘密鍵

2. CSRを生成して独自CA
に署名をリクエスト
秘密鍵
CSR
CSR

3. CSRを独自CAの秘密鍵
で署名してデバイス証明書
を発行してデバイスに返す
秘密鍵
証明書
CSR
CSR

秘密鍵
証明書
CSR

5. 証明書をAWS IoTに事前登録
秘密鍵
証明書
CSR

秘密鍵
証明書
CSR

秘密鍵
証明書
CSR
CSR
1. デバイスの
秘密鍵を作成

メリット
• 証明書と同時にデバイス登録しておくと、デバイスが起動したらす
ぐ使える
デメリット
• 証明書・秘密鍵の発行、デバイスへの焼き込み、AWS IoTへ証明
書やデバイスを登録する仕組みを生産設備に組み込む必要がある
録される

デバイス及びその証明書の登録をデバイスの初回接続時に行う
JITRによる登録
Just in Time Registration
• Amazon以外のCAで発行した個別証明書を製造時に埋め込みたくない
• クラウド側の登録するロジックは自身で実装したい
場合に有効
https://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/auto-register-device-cert.html

独自CAによる証明書発行＆JITRによる登録
（製造時）
秘密鍵
証明書
CSR
CSR
1. デバイスの
秘密鍵を作成
5. 証明書をAWS IoTに事前登録不要

証明書を送信(初回接続)

2. デバイス証明書を署名するCAが登録済
みのCAであることを確認したが、デバイス
証明書がサーバに登録されていない

3. エラーが返る

4. リクエストしてきた
デバイスやその証明書、
ポリシーを登録

へ証明書を送信 (再接続)

6. デバイス証明書を署名するCAが AWS IoT も

7. 通常の相互
認証を行う

JITR詳細
AWS IoT Core
未認可な証明証のアクセスは暗黙的に
$aws/events/certificates/registered/<CERT-ID>
のtopicにイベント通知される
証明書の有効化やポリシーのアタッチが
完了するまではエラーとなることに注意
証明書の有効化とポリシーのアタッチ
{
"certificateId": "",
"caCertificateId": "",
"timestamp": "",
"certificateStatus":
"PENDING_ACTIVATION",
"awsAccountId": "",
"certificateRegistrationTimestamp": ""
}
CERT-ID単位でのtopicになるので、種別などでポリ
シーを分けたい場合はCAを複数使うことで対応可能

メリット
• AWS Lambdaで登録するため、その他必要な処理も実装可能
デメリット
• 証明書・秘密鍵の発行、デバイスへの焼き込みの仕組みを生産設備
に組み込む必要がある
• デバイスの登録で使う情報は、AWS Lambdaで証明書をパースす
る必要がある

デバイス及びその証明書の登録をAWS IoTが行う
JITPによる登録
Just in Time Provisioning
• Amazon以外のCAで発行した個別証明書を製造時に埋め込みたくない
• AWS IoTに登録する仕組みを自身で構築したくない
場合に有効
https://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/jit-provisioning.html

独自CAによる証明書発行＆JITPによる登録
（事前設定）
{
"templateBody" : ”json format",
"roleArn" : ”xxx"
}
プロビジョニングテ
ンプレートを登録

（製造時）
秘密鍵
証明書
CSR
CSR
1. デバイスの
秘密鍵を作成
5. 証明書をAWS IoTに事前登録不要

4. プロビジョニングテンプレートに
従って証明書の登録、ポリシーの作
成、デバイスの登録が行われる

7. 通常の相互
認証を行う

メリット
• プロビジョニングテンプレートに沿って自動で登録可能
デメリット
• 証明書・秘密鍵の発行、デバイスへの焼き込みの仕組みを生産設備
に組み込む必要がある
• プロビジョニングテンプレートは証明書からデバイス情報を生成す
るため、証明書内容を考慮する

同一証明書を複数アカウントの同一リージョンに登録可能な
（マルチアカウント登録）
• 同一証明書を複数の環境で利用したい
• チップベンダのセキュアチップを利用したい
場合に有効
https://docs.aws.amazon.com/iot/latest/developerguide/manual-cert-
registration.html#manual-cert-registration-noca-cli

秘密鍵
証明書
CSR
CSR
1. デバイスの
秘密鍵を作成

メリット
• CA証明書をAWS IoTに登録不要なので、同一証明書を複数アカウ
ントの同一リージョンに登録可能
デメリット
• 証明書・秘密鍵の発行、デバイスへの焼き込み、AWS IoTへ証明
書やデバイスを登録する仕組みを生産設備に組み込む必要がある

CA登録無しの証明書登録（セキュアチップ利用）
0. 証明書と秘密鍵は既に
セキュアストチップ内に
1. チップベンダーから証明
書のリストを取得
秘密鍵
証明書
CSR

メリット
• 秘密鍵がデバイスから外に出ない & セキュアなストレージに保存
• CA証明書をAWS IoTに登録不要なので、同一証明書を複数アカウ
ントの同一リージョンに登録可能
• CAの運用が不要
デメリット
• セキュアチップのハードコストが発生

まとめ
• 認証情報の漏洩リスクを考慮すると、個別の認証情報を
埋め込むことがベストプラクティス
• AWS IoTでは個別の認証情報を埋め込む様々な方法を
用意
• お客様にとって最適な方法を選択可能
• 認証情報の埋め込みは検討段階から考慮する必要がある
• 証明書の更新方法についても同時に考慮

AWS IoTにおけるデバイスへの認証情報のプロビジョニング

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to AWS IoTにおけるデバイスへの認証情報のプロビジョニング

Similar to AWS IoTにおけるデバイスへの認証情報のプロビジョニング (20)

More from Amazon Web Services Japan

More from Amazon Web Services Japan (20)

Recently uploaded

Recently uploaded (11)

AWS IoTにおけるデバイスへの認証情報のプロビジョニング