はじめに
2019年5月にIoTLTにてLTをさせていただきました。
その内容のフォローを記入しながら自分なりに整理していきたいと思います。
発表内容：
スタートアップIoTデバイスのセキュリティを考える
なぜセキュリティを考えるか
クラウドベンダー各社の状況：
デバイス側とのセキュアな通信を実現するためにX509証明書を使ったデバイス認証を採用している。
■AWS IoT:
IoTデバイス認証方法として、下記の4つに対応
X.509 証明書
IAM ユーザー、グループ、ロール（基本的にIDとパスワード）
Amazon Cognito ID
（WEBサービスでよく見かけるLogin with Amazon、Facebook、Google など）
フェデレーティッドアイデンティティ（カスタム認証）
よく、Arduino のチュートリアルなどで、AWS IoTへ接続する際は、AWS IoT上で
デバイス証明書と秘密鍵を作成、ダウンロードしてデバイスに入れる例が案内されている
■Azure IoT
主に下記の認証方法に対応
X.509 証明書
SAS（共有アクセスセキュリティ）トークン
Azureでは、市販の証明書か、テストや開発の目的に独自の X.509 証明書を作成し、
登録して使用する必要がある。
AWSのように証明書は発行してくれないので、少し敷居が高い。
IoT Hubへのアクセス制御
■Google IoT Core
デバイス認証はJWT(JSON Web Token)にて行う。
RFC7519 JSON Web Token
事例が少なく、後日勉強したい内容。
Device Security
そもそもなぜ証明書なのか考察
例えば、普段利用しているオンラインショッピングで暗号化ってやっているのでは？
この場合、WEBサイトからサーバー証明書が送られてきて、ブラウザに
組み込まれたルートCA証明書で検証している。
この場合、あくまでこのサイトが正しく存在しているということを証明している。
接続しているクライアント側は認証していない。
クライアント側の認証は、ユーザーIDとパスワードなど、別の形をとっている。
これで、一般に公開したいサーバー側と、決済など機密情報の操作を行う
ユーザー側が安全につながる。
しかし必ずしも常時操作する人間がいないIoTデバイスでIDとパスワードでの
クラウド接続はセキュリティリスクが大幅に向上してしまう。
そのため、デバイス側の個体を区別して認証するため、デバイス側に証明書を
組込み、サーバー側へ提示しての双方向認証が必要とされている、という整理になるだろう。
今後の方向性≒ハードウェア支援のセキュリティ？
各社、共通しているセキュリティ設定、ガイドラインとして、X.509証明書を使用する際、以下のようなセキュリティを高めるために鍵の秘匿の重要性、秘匿のためのハードウェア支援の利用などの提案がある。
AWS IoT Core
AWS IoT Greengrassというクラウド側の計算、判断、処理をエッジ側で可能にするプラットフォームの実装でハードウェアによるセキュリティ実装の紹介
「AWS IoT Greengrass は、プライベートキーの安全な保存とオフロードのために PKCS#11 インターフェイスを介したハードウェアセキュリティモジュール (HSM) の使用をサポートしています。これにより、ソフトウェアでキーが漏洩したり複製されたりするのを防ぎます。プライベートキーは、HSM、Trusted Platform Modules (TPM)、その他の暗号化要素などのハードウェアモジュールに安全に保存できます。」
ハードウェアセキュリティ統合
Azure IoT Hub
セキュリティで保護されたハードウェアを中心に構築する:
COGS（原価コスト）が許す限り、セキュリティで保護された暗号化ストレージやトラステッド プラットフォーム モジュール (TPM) ベースのブート機能など、セキュリティ機能を構築します。 これらの機能により、デバイスのセキュリティが強化され、IoT インフラストラクチャ全体の保護に役立ちます。
IoTセキュリティに関するベストプラクティス
Google IoT Core
１、秘密鍵を秘匿してください。
２、ポート8883および443でmqtt.googleapis.comまたはmqtt.2030.ltsapis.googと通信するときは、TLS 1.2を使用してください。
３、各デバイスには、固有の公開鍵と秘密鍵のペアが必要です。複数のデバイスが単一のキーを共有し、それらのデバイスの1つが危険にさらされている場合、攻撃者はその1つのキーで設定されているすべてのデバイスを偽装する可能性があります。
４、Cloud IoT Coreに登録するときは、公開鍵を安全に保ってください。攻撃者がその公開鍵を改ざんして、その公開鍵を交換して間違った公開鍵を登録するようにプロビジョニング担当者をだますことができると、攻撃者はその後デバイスに代わって認証を受けることができます。
Device Security Recommendations
まとめ
各クラウドベンダーのIoTデバイスの認証で証明書認証が使われており、
ハードウェアで証明書のコントロールを支援する製品が出てきている。
次で、製品の比較と実際に触って理解を深めていきます。