IoT機器はどこを狙われるのか？攻撃者視点で整理するセキュリティ対策

こんにちは。
IoTに対するペネトレーションテストのPMを担当している、デジタルペンテスト部オフェンシブペンテストグループの藤原です。

私たちのグループでは、IoT機器やIoTシステムに想定される脅威の可能性に対して、現行のセキュリティ対策が本当に機能しているのかを実証的に検証する「IoTデバイスペネトレーションテスト」を提供しています。設計思想やチェックリストの確認だけでなく、実際の攻撃者視点で侵入経路や権限昇格、データ窃取の可能性を洗い出します。対象は、通信ネットワーク機器や車載ユニット、IoT Gateway、医療機器など多岐にわたります。社会インフラや人命に直結する領域だからこそ、問題が起きてから対応するのでは遅いのがIoTの世界です。

今回は、IoT機器において想定される脅威を起点に、「守るべきものを守れていますか」という問いを掘り下げます。機能や利便性の裏で見落とされがちな資産や、攻撃者にとって魅力的なポイントはどこにあるのか、机上の想定ではなく現実のリスクとして捉え直していきます。

IoT機器で、攻撃者から守るべきもの

まず、IoT機器において「何を守るべきなのか」を整理します。ここでは、IoTデバイスペネトレーションテストの実施時の、代表的なポイントをご紹介します。

攻撃者の視点で見ると、IoT機器に対する攻撃は大きく2つに分けられます。機器内部に直接アクセスする攻撃と、ネットワークを介して通信を狙う攻撃です。そこで本稿では、「IoT機器の内部」と「外部との通信」の2つの観点から、守るべきポイントを整理します。IoT機器の内部と外部との通信においては、例として以下のものがあります。

IoT機器内部

IoT機器内部において、守るべきものはメイン基板上に存在します。

• ①ファームウェア
• ②保存データ
• ③暗号鍵
• ④署名情報

通信

• ①認証機能
• ②通信データ

なぜ、守らなければならないか

先ほどご紹介したものを、なぜ守らなければならないのか確認していきましょう。

IoT機器内部

ファームウェア

ファームウェアはIoT機器の動作を司るプログラムです。これが攻撃者に改ざんされてしまうと、セキュリティ対策の回避や悪意を持った動作の追加等を行われてしまう可能性があります。また、窃取されてしまうと、設計や実装仕様、さらに、搭載されているノウハウ等が解明されてしまう可能性もあります。

保存データ

保存されるデータが機微情報である場合、攻撃者に窃取されては問題になります。また、クラウドとの連携を行うデバイスでは、その連携に必要な認証情報（APIキーなど）も機微情報と言えます。解析によってクラウドとの連携情報が漏えいし、悪用されてしまうと、攻撃者による侵害範囲がより広範囲に及び、大きな被害につながることもありえます。

暗号鍵

暗号鍵は、機微情報を保護するために暗号化する際や認証等に使用します。攻撃者に窃取されてしまうと、暗号化したデータを復号されてしまう、認証を突破されてしまう等の可能性があります。

署名情報

署名情報は、受信したファイルやデータを検証する際に改ざんされていないこと、正しいものであることの確認に使用します。攻撃者に窃取されてしまうと、攻撃者が改ざんしたファイルやデータであっても、窃取した情報を用いて署名を作成し、これを送信すれば正当なものとして問題ないと判定され、受信されてしまう可能性があります。

通信

認証機能

認証機能は、IoT機器がデータの読み出しや書き込みを行う際に、通信先が正しい相手かどうかを確認するための仕組みです。このハードルが低いと、攻撃者が認証を突破して機器内の情報を不正に読み出したり、設定やデータを書き換えたりする可能性があります。

通信データ

IoT機器と、通信先とでやりとりする通信データに機微情報が含まれる場合、これを攻撃者に盗聴、窃取、改ざんされると問題になります。

攻撃者が攻撃を試みる方法

では、攻撃者はどのように攻撃を試みるのか考えてみます。

IoT機器内部

ファームウェア

ファームウェアはIoT機器の内部のメイン基板上のデバイスに格納されていることが多いです。そのため、攻撃者はIoT機器の内部からメイン基板を取り出し、ファームウェアが格納されていると想定されるデバイスを探し、次の手法を実施することが考えられます。

• SoC（System on a Chip）であれば、デバッグポートからのアクセス
• フラッシュメモリであれば、基板から取り外し、データの抽出

保存データ、暗号鍵、署名情報

保存データ、暗号鍵、署名情報もIoT機器の内部のメイン基板上のデバイスに格納されていることが多くあります。これらもファームウェアと同様の攻撃手法が考えられます。

通信

認証機能

攻撃者が想定するデータを大量に作成して送信し、IoT機器の応答を確認しながら突破を試みることが挙げられます。

通信データ

通信パケットをキャプチャし、通信データの解析を試みる可能性があります。

どのように守るか

IoTデバイスペネトレーションテストの報告書では、発見されたリスクに対して具体的な推奨対策を提示しています。ここでは、IoT機器をどのように守ればよいのか、実践的な対策の考え方をご紹介します。

IoT機器内部

ファームウェア、保存データ

SoCのデバッグポートへの攻撃者のアクセスから守る方法としては、デバッグポートを無効にする、デバッグポートへの不正アクセスからパスワード等で保護するSoCの機能を有効にするなどが考えられます。

フラッシュメモリからのデータの抽出・解析から守る方法は、データを抽出されても解析が困難なように暗号化しておくことなどが考えられます。また、この暗号化に用いる鍵の管理も重要なポイントです。鍵の生成・配布・更新・廃棄までを含めたライフサイクル管理を設計しておかなければ、暗号化の効果は十分に発揮されません。特に、開発用の暗号鍵と、製品用の暗号鍵を共通にしてしまうようなことがないように注意する必要があります。

さらに、ファームウェアの改ざんを防ぐためには、起動時にプログラムの正当性を検証するセキュアブート機能の実装も有効です。

暗号鍵、署名情報

暗号鍵は、SoCのデバッグポートからアクセス可能な領域や、フラッシュメモリに格納することは適切ではありません。こうした領域に保存されていると、物理的な解析やデバッグ機能を悪用され、鍵そのものが取り出されてしまうおそれがあります。そのため、暗号鍵はSoCが備えるセキュリティエリアや、HSM（ハードウェアセキュリティモジュール）などの専用領域に格納し、外部から直接参照できない形で保護することが重要です。

SoCのセキュリティエリアやHSMの容量が限定される場合には、特にトラストチェーン（信頼の鎖）の考え方や実装が重要になります。

通信

認証機能

例として、チャレンジ・レスポンス認証で考えると、攻撃者がレスポンスの値を容易に推測できないことが前提となります。予測可能な値や単純なアルゴリズムでは、総当たりや解析によって認証を突破されるおそれがあるためです。

さらに、認証に失敗した回数に応じて認証試行を制限するロックアウト処理（例：3回連続で失敗した場合、一定時間はチャレンジを受け付けないなど）を実装することで、総当たり攻撃の成立をより一層難しくできます。認証方式そのものの強度に加え、こうした運用面の防御を組み合わせることが、IoT機器の認証機能を実効的に守るポイントといえます。

IoT機器と通信先とでやりとりする通信データ

通信データを暗号化することが必要と考えます。

さいごに

ラックでは、IoT機器のセキュリティを開発の初期から検証まで一貫して支援しています。

開発工程の初期段階では、「何を守るべきか」「それをどのように守るべきか」を整理し、設計段階から対策を組み込むための「IoTセキュア開発コンサルティング」を提供しています。後から対策を追加するのではなく、製品の設計そのものにセキュリティを組み込むことを目的としています。

さらに、開発工程の終了段階では、「守るべきもの」が実際に守られているかを攻撃者の視点で検証する「IoTデバイスペネトレーションテスト」を実施します。設計どおりの防御が機能するのか、想定外の弱点が残っていないかを実践的に確認します。

IoT機器のセキュリティ対策と検証の両面からご支援できます。ご関心がありましたら、お気軽にご相談ください。

IoTデバイスのセキュリティ対策に役立つホワイトペーパーのご紹介！

IoT製品のセキュリティ対策について解説するホワイトペーパーです。デバイス開発、品質管理、セキュリティ設計・実装など、IoTデバイス・ネットワークにつながる機器の開発に関係する幅広い皆様におすすめの内容です。ぜひご覧ください。

下記ダウンロードサイトからお申し込みください。