Amazon Web Services ブログ

IoT@Loft #8 スマートホームのセキュリティ脅威と対策

こんにちは、AWSソリューションアーキテクトの渡邊 です。2月19日の IoT@Loft 第8回目のテーマは、「スマートホームのセキュリティ脅威と対策」でした。

IoT@Loft とは ?

IoT 関連ビジネスで開発を担当するデベロッパーのためのイベントです。IoT の分野は、「総合格闘技」と呼ばれるほど、必要な技術分野が非常に多岐に渡ること、ビジネスモデルが複雑なケースが多く、全体を理解することは難しいと言われています。その結果、実証実験 (Proof of Concept : PoC) から商品への導入が進まないケースや、PoC でさえ十分に実現できていないケースも多々あります。
IoT@Loft は、そういった IoT 特有の課題と向き合い、情報共有・意見交換を行う場として、参加者の事業や製品開発を成功に近づけることができれば幸いです。この勉強会では、膨大な IoT 関連の情報の見通しを良くするために、各回ごとにテーマを定め、それに沿った形で登壇者に事例や技術のご紹介を頂きます。テーマは、インダストリー、ソリューション、テクノロジー、開発フェーズなどを軸に決めていきます。

LT セッション

LT1 – Zero Touch Provision for AWS IoT

Microchip Technology Japan様にはMicrochip Trust Platformを利用し、AWS IoT Coreにセキュアに接続する方法についてご紹介していただきました。昨今の何でもつながるIoTだからこそ、すぐにセキュリティの脅威にさらされるリスクがあることからシリコンレベルからどのように保護するかを考慮する必要があると説明して頂きました。

miraiなどに代表されるマルウェアに対してMCU(Micro Controller Unit)においても、なりすまし、FWの改ざん、盗聴の防止のため強固な認証や暗号技術が必要で、そのセキュリティレベルはプライベートキーの管理に依存します。プライベートキーの管理においてはソフトウェアから鍵を分離する、製造工程から鍵の改ざんの防止を行う、MCU内のメモリー空間には鍵を保存しないといったことを考慮する必要があります。それらを守った上で、誰がどのようにトラステッドなデバイスを作るのでしょうか。これには以下のような課題があります。誰が鍵を生成するのか、鍵を持ったデバイスをどのように作るのか、デバイスをどのようにAWS にセキュアにつなぐのかというものです。

これらを解決するためにMicrochip Technology 社で鍵を生成してセキュアエレメントに格納した状態で出荷する仕組みを提供しています。鍵の生成には高度に管理されたHSM(Hardware Secure Module)を利用しています。これによりエンドユーザーは自身で鍵の生成管理をすることなくメインのMCUからセキュアエレメントにI2Cで接続して鍵を利用できます。セキュアエレメントはハッカーの物理的なアクセスに対しアクティブシールドをつけることで対応します。情報を取得するためには、アクティブシールドを切断する必要があり、メモリーとシールドは接続されているために切断した際には情報が二度と取得できないような仕組みになっています。

AWSとの連携においては、Microchip Technology社から提供された証明書をエンドユーザーのAWSアカウントに登録することで、プライベートキーが格納されたセキュアエレメントを用いてセキュアにAWS IoT Coreに接続することが可能です。また新たな取組みとして、更に簡単（Zero Touch）かつセキュアに開発者がプロビジョニングを行うためのMicrochip Trust Platformのご紹介があり、ユースケースのサンプルコード、開発ツールを用意されているそうです。
https://www.microchip.com/design-centers/security-ics/trust-platform

株式会社ビットキー様にはスタートアップにおけるスマートロック製品開発において苦労した点に関するお話と、AWSのフルマネージドサービスを活用されたお話をして頂きました。冒頭にスマートロック屋ではなく、IDの認証/連携基盤と権利の安全なやりとりが本業の会社ですと述べられて、安全に部屋にはいる権利を第三者（運送会社）に譲渡することができれば安全に荷物を部屋の中に配達してくれたり、長期に渡り家を不在にする際にペットの世話を任せるなどの普段の生活をより便利にできると考えられているということでした。

スマートロックを利用してIDの認証と権利の安全なやりとりを現実世界に反映していますが、製品量産までとても多難だったそうです。量産における課題やセキュリティの課題があり、それらを乗り越えるために、オフラインでのセキュリティは枯れた技術の組み合わせ（信頼された技術要素の組み合わせ）を使い、オンラインではAWS IoT Coreなどのマネージド・サービスを利用している。マネージドサービスを利用することで、任せられる領域があるので実装行為に集中できると仰って頂きました。

セキュリティを考える際に100%安全は絶対にありえないということで任意のコマンドが実行される余地はないか、意図的なメモリ破壊は起こせないか、コア技術以外での安易なミスはないか、コンピューティングの進化に伴う新たなパスワード解析手法の出現がないかなど検討することは沢山あり、なにかあった時にDFU（デバイスファームウェアアップデート）ができることが大切で、それによって脆弱性が見つかった時に対応することができると説明していただきました。

AWSからは、ソリューションアーキテクトのセキュリティ脅威と対策について、デベロッパーの観点でどのように向き合い、対処していくべきかについてご説明させて頂きました。（ここからは飯田が書いていきます。）

当日の発表資料はこちらです：
https://www.slideshare.net/AmazonWebServicesJapan/20200219iotloft8securityofsmarthome
お伝えした内容について、上記のスライドに沿って書いていきたいと思います。

背景

IoTデバイスは近年爆発的な増加傾向にあり、およそ5年で倍増しており、コンシュマー向けも年率10%で増加しています。
https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/h30/html/nd111200.html

NICTERのダークネット観測網で観測されたサイバー攻撃関連通信の状況を見てもIoTデバイスを狙った攻撃が非常に増えていることがわかります。
https://www.nict.go.jp/press/2019/02/06-1.html

このような状況下で、IoTデバイスでのセキュリティ対策の重要性も増してきています。
日本では、セキュリティ対策のガイドラインとして、IoT推進コンソーシアムが出している、IoT セキュリティガイドライン があります。こちらをみると、セキュリティ対策の方針から分析、設計、構築・接続、保守運用まで網羅的にリストアップされています。この詳細については触れませんが、ぜひご覧いただき、ご自身の担当される製品において、製品の特徴を見極めた上で、必要十分な対応を考えて頂くことをおすすめします。
https://www.soumu.go.jp/main_content/000428393.pdf

対策にあたり考慮すべきこと

当然ですが、開発者としてはセキュリティ対策だけをしていればよいわけではありません。品質や納期を意識しながら、製品に付加価値をつけるためのアプリケーションの開発を行う必要があります。以下では、IoTのセキュリティ対策を行う上でポイントになりそうな点を挙げています。

１．攻撃者の目標や攻撃方法が異なる

上記のガイドラインに詳しく記載されていますが、Webでは、不正アクセスなどによるアカウント乗っ取り、個人情報取得などが多く見られるのに対して、IoTでは、なりすまし、DDoS参加などが主流です。原因としては、IoTデバイスは人が所持しないケースがあり、屋外に設置されたものなど、物理的な攻撃がしやすい状況にある場合があること、また、ユーザーに紐付かず、複数人で共同管理することもあり、この場合には、IDやパスワードがデフォルトや簡単なものにされる傾向があります。（これを狙ったのがmiraiなどボットネットの攻撃です）

２．セキュリティ対策とハードウェアの設計・製造工程

ハードウェア開発における一般的な開発の流れは上記のように、商品の企画から始まり、試作を何度も重ねた上で量産となります。このガントチャートにおいてセキュリティ対策を当て込んでいくと、手作りの試作のタイミング（電気屋が部品の選定などを行う前くらい）には、アーキテクチャと、セキュリティ設計を終えることが理想です。セキュリティ要件を考慮しないで部品を選んだ場合に、あとからセキュリティ上必要なハードウェア要件がでてくると、大きな手戻りとコストに繋がります。
また、工場（製造事業所）側にお願いしなければならない項目が出てくる場合もあります。秘密鍵や証明書を個別で書き込む作業などです。この作業のためには、その秘密鍵や証明書をどのようにセキュアに工場に渡すか、信頼できる、特定の人間だけに渡すかがポイントになります。もし、ODMを利用する場合であれば、その相手にその能力があるかどうかを確認する必要もでてきます。
より詳しい設計・製造の流れについては、こちらのBlogが参考になるかと思います。

[IoT設計製造のテンプレ・ガントチャート～Shiftall流、設計製造のポイントを添えて （Shiftail blog）](https://ja.blog.shiftall.net/archives/2291/)

３．出荷後に変えられないことが多い

クラウド開発であれば、とりあえずリリースし、あとから継続的にサービスを更新するという開発手法をとることが比較的容易だと思います。一方で、ハードウェアでは、一度リリースした後に変更することは非常に困難です。そのため、開発の早いタイミング（部品選定・工場選定前）でのセキュリティ要件整理を行い、セキュアエレメントの使用、署名検証、TLS通信実現、ファームウェア更新、証明書管理などの方法や要否について検討した上で、予定されているハードウェアリソースで満たせているかを確認する必要があります。また、ハードウェアには製品保証期間が定められているケースがほとんどで、その間は継続的なソフトウェアのアップデートが求められます。一度行った設計が長期間尾を引くことになるので、慎重に検討をする必要があります。

Embedded C, C++で実装するということ

多くのクラウド環境構築で使われる言語は、Python、Ruby、Java、Goなど比較的高級な言語であり、開発効率化するためのIDEやデバッグ環境が十分に揃っています。一方で、Embedded 環境の場合、ライブラリが十分に揃っていない、メモリが潤沢では無いなどがあります。経験が浅い方の場合、それらを考慮したスケジューリングが必要です。また、ビジネスロジックをできるだけクラウドにオフロードし、クラウド側で複雑なロジックや重い処理を行うことにより、デバイス側だけでなく、トータルの開発運用コストを下げられる可能性もあります。
また、一概には言えませんが、小ロットな開発であれば、ソフトウェア開発費が全体の開発費に占める割合が高くなる傾向があると思います。この場合は、製造原価ダウンを攻めすぎず、ハードウェアスペック上げて、Linux等を採用しソフトウェアの開発効率を上げることで総開発費は下げられるかもしれません。逆に、出荷数が増えるにつれてハードウェアの開発費、変動費（部品、製造コスト）の比率が大きくなる傾向にあると思います。

…特に、スマートホームデバイスの場合には

物理的な攻撃のリスクに関して言えば、商品を購入して分解することは容易なため、もし鍵をデバイス間で共通化した場合のリスクは非常に高いと考えます。デバイス個別の秘密鍵・証明書等を入れて頂き万が一分解されて鍵が抜き取られた場合のリスクを極小化することが求められます。また、セキュアエレメントなどを使用することで鍵自体を抜かれにくくすることも可能です。どこまでやるかは、ビジネスや会社のポリシーによっても変わって来ると思われます。求めるレベル感について、関係者と事前のすり合わせが必要になると思います。
また、スマートホームデバイスでは、大量生産・短納期が求められる傾向があると思います。大量になればなるほど、製造工程の遅延はコストに直結するため問題になります。また、同時にハードウェア視点だと、１円でも安くしたいため、安いMCU（マイコン）が選定される傾向もあります。ソフトウェア視点で、セキュリティ要件が満たせるかを検証する必要があります。もちろん、セキュリティだけでなく、ソフトウェア要件全般、開発環境構築等の観点で、そのMCUで問題無いかを検証する必要もあります。

こういったIoT開発における様々な課題や制約を乗り越えて、セキュリティ対策を実装していくには具体的にどうしたら良いかについて以下で記載します。

IoTのセキュリティ対策

出典：IoT セキュリティガイドライン（総務省・経済産業省）

この表は、IoTセキュリティガイドラインで挙げられているセキュリティ対策指針について、大項目および指針を抜粋した表です。このうちの方針、分析、設計の部分に関しては、このガイドラインやAWSの提供する次のような資料を参考にしながら、ステークホルダーと協調して実施していく作業になります。

IoT ソリューションにおける 10 のゴールデンルール
https://aws.amazon.com/jp/blogs/news/ten-security-golden-rules-for-iot-solutions/IoT

セキュリティのホワイトペーパー
https://aws.amazon.com/jp/blogs/news/aws-security-releases-iot-security-whitepaper/

設計以降のプロセスに関しては、主にソフトウェア開発者が対応していく項目になると思います。こちらについては、限られた期間に確実にセキュリティ要件の対応が必要になります。その実現のためにAWS IoTの機能・サービスが利用できる部分が多々あります。

３つのレイヤーに分けて説明していきます。

ネットワークのセキュリティ対策

特定の信頼できる機器同士のみの通信を許可することによる、*なりすましの防止*と、通信路の暗号化による*盗聴防止*が挙げられます。これらはいずれも適切にTLSを使うことで解決ができます。前者は、TLSの相互認証機能を用います。一般的なHTTPS通信で用いられているようなサーバー証明書とルート証明書を用いた認証に加えて、IoTではクライアント証明書も用いることで、サーバー、クライアント（デバイス）双方が信頼できる相手であることを保証します。また、後者は、TLSのハンドシェイクによって共通鍵を共有し、暗号化を行います。

TLSの対応は、クラウド側はAWS IoT Coreを、デバイス側はAWSが提供するSDKを使用することで容易に実現が可能です。

クラウドのセキュリティ対策

クラウド側では、万が一認証情報が漏洩した場合のリスクを最小化することが重要になります。対策としては、デバイスに許可する操作を予め最小化しておくことで攻撃範囲を限定すること、また、攻撃を行うデバイスが特定可能な場合は、そのデバイスからのアクセスを塞ぎます。

AWS IoT で、デバイスに許可する操作を最小化するためには、AWS IoT ポリシーを利用可能です。Json形式で許可／拒否するアクションを記載し、そのポリシーを証明書にアタッチします。これによりデバイスごとに細かい権限管理が可能です。
また、AWS IoT Core では、証明書の発行や管理等も合わせて行うことができます。クラウド側から不正なデバイスに紐づく証明書を無効化することにより、アクセスを遮断します。

（参考）AWS IoT Core でのデバイス証明書の発行および登録方法
https://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/device-certs-create.html

デバイスのセキュリティ対策

デバイス側の対策では、いかに物理的な攻撃に備えるかがポイントになりますが、大きく以下の2点が挙げられます。

1. 鍵情報の抜き取りを防ぐ
2. 新たな脆弱性への迅速な対応・不正なファームウェアのインストール防止

1. 鍵情報の抜き取りを防ぐ

こちらは、チップ、モジュール選定にも関連しますが、セキュアエレメントやTrustZone等を活用することで鍵の抜き取りそのものを難しくすることが求められます。以下のサイトなどを参考にしながら、ハードウェア原価とセキュリティのバランス鑑みながら対策を検討して頂くことをおすすめします。

AWS IoT Greengrass のハードウェアセキュリティ統合
https://docs.aws.amazon.com/ja_jp/greengrass/latest/developerguide/hardware-security.html

Amazon FreeRTOS のセキュアエレメント
https://aws.amazon.com/jp/about-aws/whats-new/2019/10/secure-elements-in-amazon-freertos/

上記に加えて、内部犯行や管理ミスによる鍵の漏洩リスクを低減することが求められます。オペレーション上、秘密情報に触れる担当者を限定したり、後述のログ出力を有効にすることで、誰がどのような操作を行ったかが追跡できるような事前準備が求められます。

2. 新たな脆弱性への迅速な対応・不正なファームウェアのインストール防止

何らかの脆弱性が発覚した場合、速やかな原因特定および対策が求めれると思われますが、セキュリティ対策済みのファームウェアの配布には、AWS IoT Device Management の利用により、手動作業を減らし、ファームウェア配布（OTA）に関わる実装上、運用上のコストを削減できます。例として、Amazon FreeRTOSを使用する場合の流れは以下のようになります。

デバイス側
  • あらかじめOTAエージェントを初期化しておく
  • クラウド側からOTAジョブが実行されると、エージェントはファームウェアをダウンロードし、署名を検証し、OTAを実行
クラウド側
  • 対策済みのファームウェアをS3に保存する
    • AWS CodePipeline 等を用いてCI/CDパイプラインを構築し、リリースビルドのバイナリファイルがS3上に自動保存されるように設定しておくことで、より効率化が可能です
  • AWS IoT Device Management がコード署名を行う
    • コード署名に使用する証明書の管理や署名は AWS Certificate Manager が使用されます
  • OTAジョブを実行する
    • ロールアウト設定を行うことで、少数のデバイスに配信を行い、徐々に台数を増やしていくことが可能です。また、以下のような画面でOTAの進捗状況を確認できます。

セキュリティ対策（運用・保守）

最後に、運用・保守の項目についてです。
サービスイン後に、セキュリティインシデントが発生した場合には、速やかに関係者へ情報を伝え、暫定対策および恒久対策を行うことが求められます。ここでは以下の3点に分けて説明します。

1. 攻撃を受けたら、すぐに検知し、関係者に伝える
2. 攻撃者や影響範囲を特定し、さらなる被害拡大を防ぐ
3. 根本原因を特定し修正を適用

攻撃を受けたら、すぐに検知し、関係者に伝える

ここでは、AWS IoT Device Defenderを用いることでデバイスの監査、異常動作の検出を行い、メールやスマホへのPush通知等により関係者へ伝えることが可能です。監査項目として、IoTポリシーの権限が過剰、CA証明書の有効期限切れなどがあります。監査のスケジューリングも可能です。

異常動作の検出に関しては、認証エラーやTCP接続の確立回数などのメトリクスを設定し、その閾値や期間を設定することが可能です。

監査で問題が検出されたり、異常動作が検出された場合には、Amazon Simple Notification Service の SNS トピックに対してアラートの送信が可能です。

攻撃者や影響範囲を特定し、さらなる被害拡大を防ぐ

操作や処理のログを記録しておくことで、攻撃者や攻撃を受けたデバイスを調査するのに役立ちます。
AWS IoT の設定でログ出力を有効にすることで、デバイスから送られたメッセージに対するAWS IoTの処理内容を記録することができます。このログは、Amazon CloudWatch ログとして記録されます。
API呼び出しなどAWSアカウントで発生したアクションについては、AWS CloudTrail を利用することで確認可能です。

根本原因を特定し修正を適用

修正版のファームウェアの配布には、先述の AWS IoT Device Management のジョブ機能を用いることでOTA更新が可能になります。また、原因特定の際などに、同サービスのセキュアトンネリング機能を使うことで、ファイアウォール内に設置されている出荷済みデバイスに対してリモートアクセスが可能になります。

まとめ

IoT開発におけるセキュリティ対策について、すべてを網羅とはいきませんが、開発者視点で特に重要度が高い点についてご説明させて頂きました。ぜひ先述のIoTセキュリティガイドラインや、AWSの提供している「IoTソリューションにおける10のゴールデンルール」、「IoT セキュリティのホワイトペーパー」などをご覧いただき、具体的な対策手法についての理解を深めて頂ければと思います。そして、IoTセキュリティ対策を、より簡単かつ確実に実施していくうえで、AWS IoT関連のサービスをご検討いただければと思います。

AWS Innovateについて

3 月 10 日 (火) 〜 4 月 17 日 (金)の間、オンラインのカンファレンスを開催いたします。
IoTセキュリティに関連するセッションや、IoT における動画ソリューションをご紹介するセッションもありますので、ご興味ある方はぜひお申し込みください。
https://aws.amazon.com/jp/about-aws/events/aws-innovate/

次回 IoT@Loft

現在調整中です。決まり次第、下記サイトやConnpass上でアナウンスいたします。

IoT@Loft ウェブサイト
https://aws.amazon.com/jp/start-ups/loft/tokyo/iot-loft/

IoT@Loft Connpass
https://iot-loft.connpass.com/

著書について

渡邊 翼

AWSのソリューションアーキテクトです。好きなサービスはAWS IoT Coreです。好きな食べ物はプロテインです。

 

 

飯田 起弘

AWS プロトタイピングソリューションアーキテクト
電機メーカーでソフトウェアエンジニアとしてIoT関連の新規事業の立ち上げを経験の後、AWSにてプロトタイピングソリューションアーキテクトとして、IoT関連案件のPoC, 本番導入などの支援に携わる。