IoT機器の脅威分析と対策で「リプレイ攻撃」は漏れていませんか？

こんにちは。
疑似攻撃を用いて、調査対象に対し攻撃者の目的が達成できてしまうか実証する「ペネトレーションテスト」を提供している、デジタルペンテスト部の藤原です。

私が所属するデジタルペンテスト部オフェンシブペンテストグループでは、IoT機器やIoTシステムのセキュリティ対策の有効性やセキュリティ上の問題の有無を検証する「IoTデバイスペネトレーションテスト」を提供しています。このサービスは、通信ネットワーク機器や車載ユニット、IoT Gateway、医療機器など、様々なIoT機器に対して実施しています。

今回はラックのIoTデバイスペネトレーションテストの実績から、IoT機器の脅威分析とセキュリティ対策において想定されていないことが多かった「リプレイ攻撃」についてお話をします。

IoTシステムの身近な例

はじめに、自宅の玄関ドアの鍵をスマートフォンから近距離無線通信により開け閉めする、IoTシステムを例に考えてみたいと思います。IoTシステムの概要は次のとおりとします。

システム構成

• スマートフォン+アプリ
• 玄関ドアに格納された制御基板
• 制御基板からの指示でドアのカギを開け閉めする開閉機構
• Bluetooth Low Energy（以下、BLE）通信
　

動作説明

玄関ドアのカギを開ける

玄関ドアのカギを閉める

脅威とリスク

このIoTシステムの脅威の一つに「通信データを盗聴され、解析される」が挙げられると思います。

そして、悪意ある第三者が解析に成功すると、カギの開閉に必要な通信内容を不正に入手できます。その結果、「悪意ある第三者がドアのカギを開閉できる」状態となります。

対策

その対策として、一つは「通信データを暗号化する」が考えられます。

スマートフォンアプリからドアへ「開ける」というデータを暗号化して「kX9fM1・・・・・・」と送ったとします。その通信を悪意ある第三者が盗聴して通信データを取得したとしても、暗号化されているためデータを解析することは確かに困難であると思います。

「通信データを暗号化する」だけで安全ですか？

しかし、悪意ある第三者は通信の盗聴を繰り返すことで、ドアを開ける時には必ず「kX9fM1・・・・・・」が送られていると気づいたらどうでしょうか？おそらく、暗号化されているデータ「kX9fM1・・・・・・」をそのまま送信してみようと考えるはずです。

そして、取得したデータ「kX9fM1・・・・・・」をそのまま送信することでドアのカギは開いてしまいます。すなわち、暗号化されたデータを解析する必要はなく攻撃が成功してしまうのです。

これが、「リプレイ攻撃」です。Webサイト等では、通信データの盗聴によりログイン情報を取得し、そのデータをそのまま使って不正にログインするというリプレイ攻撃が良く知られていますが、IoT機器で構成されるシステムにおいてもリプレイ攻撃が可能なことがあります。

必要な追加対策

通信データを暗号化するだけではなく、追加対策として、ドアに内蔵されている制御基板は、同じデータを複数回繰り返して受信させないようにすることが必要です。

同じデータを複数回繰り返して受信させないための対策の一例として「チャレンジ・レスポンス方式」が有効です。制御基板とスマートフォンアプリとの通信手順にチャレンジ・レスポンス方式を使った具体的な例を以下に示します。

ステップ	ドアのカギを開閉する制御基板	スマートフォンアプリ
①	あらかじめスマートフォンアプリと同じ暗号鍵を保管します。	あらかじめ制御基板と同じ暗号鍵を保管します。
②	ある文字列を「チャレンジ」としてスマートフォンアプリへ送信します。 ※ チャレンジは毎回異なる値であること
③		受信した「チャレンジ」によりあらかじめ格納されている暗号鍵で「レスポンス」を作成し、「ドアを開ける」のデータに追加して送信データを作成し返信します。 ※ 送信データ＝「レスポンス＋ドアを開ける」
④	レスポンスを暗号鍵で復号して確認し以下のどちらかの操作をします。 チャレンジによるレスポンスであれば、ドアのカギを開ける チャレンジによるレスポンスでなければ、ドアのカギは開けない

ステップ①
ドアのカギを開閉する制御基板	あらかじめスマートフォンアプリと同じ暗号鍵を保管します。
スマートフォンアプリ	あらかじめ制御基板と同じ暗号鍵を保管します。
ステップ②
ドアのカギを開閉する制御基板	ある文字列を「チャレンジ」としてスマートフォンアプリへ送信します。 ※ チャレンジは毎回異なる値であること
ステップ③
スマートフォンアプリ	受信した「チャレンジ」によりあらかじめ格納されている暗号鍵で「レスポンス」を作成し、「ドアを開ける」のデータに追加して送信データを作成し返信します。 ※ 送信データ＝「レスポンス＋ドアを開ける」
ステップ④
ドアのカギを開閉する制御基板	レスポンスを暗号鍵で復号して確認し以下のどちらかの操作をします。 チャレンジによるレスポンスであれば、ドアのカギを開ける チャレンジによるレスポンスでなければ、ドアのカギは開けない

チャレンジに対し問題のないレスポンスを追加してデータを送信することでリプレイ攻撃が困難な仕様でカギの開閉が可能になります。

攻撃者が盗聴により取得した古いレスポンスが付いているデータは受け取らないので、リプレイ攻撃は困難になります。

最後に

今回はリプレイ攻撃に焦点を当てたため、BLE通信開始時に必要となるペアリング手続きのプロセスは省略しましたので、ご了承ください。

データを受信する側で、同じデータを2度受け取らない仕組みにすることで「リプレイ攻撃」は困難になります。IoT機器における「リプレイ攻撃」の他の例としては、攻撃者が脆弱性を含む古いファームウェアデータを盗聴により取得しておいて、ファームウェア更新通信を悪用して古いファームウェアを送りつけることで、攻撃者がその脆弱性を悪用するリプレイ攻撃も考えられます。

また、IoT機器とスマートフォンアプリやクラウド等の外部との通信だけでなく、IoT機器の外部端子からUSBメモリ等により入力されるファイルを読み込む場合や、内部の基板上のデバイス間でデータを受け取る場合等でもリプレイ攻撃の考慮が必要であると考えられます。ぜひ、IoT機器が外部との通信から受け取るデータに限らず、内部でのデータのやりとりでも、脅威分析やその対策で「リプレイ攻撃」を漏らさないようにしたいところです。

IoT機器のセキュリティ対策と検証に、ぜひお役立てください。また、お困りのことなどがありましたらお気軽にご相談ください。

過去の記事も以下に紹介させていただきます。

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

IoTデバイスに対するセキュリティ対策の一助になるように、インタフェースごとに確認を推奨する項目をまとめました。開発・品質管理に関わる方のセキュリティ対策検討に活用していただける内容です。ぜひご覧ください。