新しい IBM Developer JP サイトへようこそ!サイトのデザインが一新され、旧 developerWorks のコンテンツも統合されました。 詳細はこちら

IoT デバイスに対する脅威を識別して防ぐ

ある 1 つのジョブを実行する IoT デバイスが、そのジョブを公然と実行している場合、データ・センター内のサーバーを経由した、さまざまな形の攻撃のターゲットになります。サーバーがデータ・センター内に安全に閉じ込められているとしても、そのサーバーが実行している多くのアプリケーションには、世界中の人々がアクセスできるからです。この記事では、悪意のある物理的なアクセスによる脅威について説明した後、IoT デバイスや他のコンピューターに共通する脅威について説明します。

脅威を識別して防ぐ際は、セキュリティーは決して静的なものではないということを念頭に置くことが大切です。セキュリティーにおいては、配備するセキュリティー・メカニズムを無効化または悪用しようと狙う、私たちに対抗するインテリジェントな攻撃者が存在することを前提としなければなりません。セキュリティー分析で大きな部分を占めるのは、役立つ可能性のあるセキュリティー・メカニズムと、それらのメカニズムを攻撃者たちから保護する方法を識別することです。

物理的なアクセスによる攻撃を検出する

IoT デバイスにとって最も明らかな脅威は物理的な脅威です。ほとんどのアプリケーションでは、誰かがデバイスにアクセスしてそれを持ち去り、そのデバイスを制御できるように「改良」したバージョンを元の場所に戻すといったことが可能です。このようなリスクは、デバイスの場所と、そのデバイスへのアクセスを許可する関係者を管理できなければ回避することはできません。デバイスの電源がオフにされた時点、あるいはデバイスが収容されているものが開けられた時点でそれを識別できるようにすることはできますが、それには一般にリバース・エンジニアリングやデバイスへの「機能の追加」が必要になります。

セットアップと認証

新しいデバイスがアクティブにされて初めてサーバーにアクセスするときは、それが本当にそのデバイス自体であり、ハッカーのコンピューターではないことを確認する必要があります。セキュリティー対策の 1 つとなるのは、デバイスを発送する前に、共有シークレットを構成することです。その場合、デバイスごとに異なる共有シークレットでなければならないため、かなりの数のデバイスを製作している場合は、これよりも簡単に実施できる他のセキュリティー対策を検討してもよいでしょう。詳細については、このリンク先の記事「 IoT のデバイスとゲートウェイをセキュリティーで保護する 」を参照してください。

ハートビート

例えば、デバイスが 5 秒おきに「私はまだ存続しています」と報告するとしたら、誰にも知られずにデバイスの電源を 5 秒以上オフにするのは難しいでしょう。もちろん、デバイスが 5 秒間隔で送信するのが同じメッセージであれば、そのデバイスになりすます (スプーフィングする) のは簡単なことです。

スプーフィングするのが難しいハートビート・メッセージにするには、送信するストリングを、(毎回新しいストリングにするために) 時刻の後に時刻の 暗号学的ハッシュ関数 と共有シークレットを続けるという形にします (この処理は、デバイスを制御下に置く前に行う必要があります。デバイスの制御を開始した後は、デバイスが実行できることを何でも実行できるようになるからです)。図 1 に、このプロセスの各段階を示します。

図 1. 暗号学的ハッシュ関数を使用して一意のハードビート・メッセージを作成する

alt

このセキュリティー・メカニズムを攻撃するとしたら、どのような方法が考えられるでしょうか?ハートビートは検出用の対策、あるいはアラーム・メカニズムです。検出用の対策は、以下のいずれかの形で失敗することがあります。

  • 検出漏れ。アラームの原因となるべき問題を検出できないこと。
  • 誤検出。誤ったアラームを出すこと。誤ったアラームはそれほど危険ではないように思えますが、誤検出の数が増えると、最終的には「虚報」として無視されるという問題につながります。いつも決まって無視されるアラートは、無効であるのと同じことです。セキュリティーに関しては、攻撃の向こう側にはインテリジェントな対抗者がいることを前提としなければなりません。

ハートビートの場合、検出漏れが発生することはあまり考えられません。暗号学的ハッシュ関数を支える計算はほぼ確実であるためです。一方、誤検出は発生しがちです。攻撃者は、デバイスの電源をオフにするか、ネットワークからデバイスを切断するだけで、物理的なアクセスによる攻撃を仕掛けることができます。このような攻撃を困難にするには、USB バッテリーを使用するか、バックアップ・ネットワークまたはバックアップ・デバイスを用意するという方法があります。

バッテリー

最も簡単に想像できる攻撃は、電源の切断でしょう。電源を切断したとしても、それが攻撃であると、特に怪しまれることはありません。停電や、誰かが別のものに電源をつなげるためにデバイスの電源を切るといった場合まで、デバイスの電源は切断される可能性が常にあるからです。

最近の低価格のデバイスは、USB 電源を使っています。USB バッテリーは安価であるだけでなく、本来の停電の件数を大幅に減らします。状況によっては、USB バッテリーを使用することで、停電を疑わしいイベントと見なし、停電が発生したデバイスをセキュリティーが侵害されたものとして扱うことができます。

ネットワーク接続

ほとんどの IoT デバイスは消費者向け Wi-Fi ネットワークを使用します。Wi-Fi ネットワークは高速であり、安価であり、ほぼ常時使用することができます。けれども Wi-Fi ネットワークでは本来のサービス停止が発生するため、IoT デバイスのハートビートをトラッキングするのが難しくなります。この問題に対しては、以下の 2 つのソリューションを検討してください。

  • バックアップ・ネットワーク (セルラー・ネットワークなど) を用意して、ネットワークの接続性を確実にする。セルラー・ネットワークは、Wi-Fi ネットワークよりも速度が落ちる傾向がありますが、停電の回数は少なくなります。予算があるとしたら、このソリューションによってネットワーク接続の信頼性を確保できます。
  • 近くの安全な場所 (鍵がかかった部屋など) にセカンダリー・デバイスを用意し、バックアップ・デバイスとしてハートビートを受信させる。プライマリー・デバイスが利用できなくなった場合、セカンダリー・デバイスがアクセス・ポイントになってハードビートを引き続き受信します。接続が再開された時点で、ハートビートが正当に続行されたことをサーバーに報告できます。このソリューションのほうが、コストを大幅におさえることができます。

    ハートビートのモニタリングにセカンダリー・デバイスを使用する場合、攻撃者がネットワークを切断して両方のデバイスを乗っ取った後、セカンダリー・デバイスにハートビートの中断はなかったふりをさせるという問題があります。この問題に対するソリューションは、「自動ロボトミー」です。両方のデバイスがバッテリーで駆動していれば、その両方のデバイスを同時に無効にするのは困難になります。一方のデバイスが、もう一方のデバイスが無効にされたことを識別した場合、そのもう一方のデバイスがハートビートで使用する共有シークレットを検出することができます。その場合、デバイスが乗っ取られたとしても、そのデバイスを使って偽のメッセージを作成することは不可能です。ただし、共有シークレットを削除するということは、単にそのファイルを削除すればよいだけの話ではない場合があります (ファイルを回復するのは簡単です)。オンチップ・ストレージを使用しているとしたら、おそらくそこに共有シークレットを保管するのが最善です。(例えば Raspberry Pi 内に) オンチップ・ストレージがなければ、共有キーを削除した後に、可能な限り大量のランダム・データをファイル・システムに書き込むことが賢明な策となるでしょう。

物理的な開封明示機構の設計

一般に、埃や湿気から守るために IoT デバイスはボックス内に収容されます。そのようなボックスが開けられたことを識別できるようにするには、ボックスの蓋の両端に電気接点を取り付けるという方法があります。蓋が開けられると、それらの接点間の接続が切断されることで、そのイベントを検出できるようにするという仕掛けです。あいにく、この仕掛けは簡単に回避することができます。ボックスに穴を開けて、電気接点間の接続を短絡させれば、ボックスを開けても検出されることはありません。図 2 に、IoT デバイスのこの物理的な開封明示機構を示します。

図 2. ボックス内に収容された IoT デバイス

alt

これよりも有効なソリューションは、いくつかの汎用 I/O (GPIO) ピンと 1 台のアナログ・デジタル・コンバーター (ADC) を使用することです。その場合、回避するのが遥かに難しい開封明示機構にすることができます。数本のケーブルを使用して、それらのケーブル上でランダムなデータを送信し、ボックスへのケーブル経路の後にデジタル・アナログ・コンバーター (DAC) を組み立てます。それには、例えば 抵抗ラダー回路 を使用できます。そして DAC の出力を ADC に接続し、ADC から得た値が、送信した値と一致することを検証します。ケーブル間で短絡が発生した場合は、それによって DAC が「認識」する値が変わるため、ADC の結果も変わってきます。図 3 を参照してください。

図 3. 回避するのが難しい物理的開封明示機構の設計

alt

センサーからの偽の入力

物理的に IOT デバイスにアクセスすることで可能になる攻撃は他にもあります。それは、攻撃者が偽の情報をセンサーに与えるという攻撃です。例えば、日中に光センサーを使用すれば、気象に関する情報を収集できます。けれども、誰かが懐中電灯の光をセンサーに向けたり、センサーを半透明のテープで覆ったりすると、センサーの情報は誤ったものになります。

この問題に対するソリューションの 1 つは、センサーから送られる値にサニティー・チェックを適用することです。光センサーが夜間に光を検出した場合や、日中に光を検出しない場合、その IoT デバイスのセキュリティーが侵害されている可能性があります。あるいは夜明け、昼間、日没に検出した光レベルが同じであれば、それも IoT デバイスのセキュリティーが侵害されている兆候です。センサー・データにいくつかのサニティー・チェックを適用するだけで、生成した偽のデータを受け入れさせるのが非常に困難になります。

デバイスが単独で使用されているのではなく、センサー・ネットワークの一部として使用されている場合は、複数の異なる箇所からの結果を比較するという方法もあります。ある場所では太陽が照っている一方、1 キロも離れていない場所が真っ暗だとしたら、何らかのセキュリティー違反を疑うことができます。

IoT ネットワークをセキュリティーで保護する

IoT デバイスはインターネットに接続された、ある種のコンピューターです。IoT デバイスはコンピューターとは異なりますが、コンピューターをセキュアにするためにできる対策はいずれも IoT デバイスに適用できます。主な例としては、サーバー・プロセスがデバイスに侵入するために悪用されないようにするために、適切なセキュリティーで保護されたサーバー・プロセスだけをインターネットに公開すること、転送するあらゆるデータを暗号化すること、管理アカウントでデフォルトの資格情報を変更するようユーザーに強制することなどが挙げられます。

IoT デバイスと汎用のコンピューターとの間には 1 つの重要な違いがあります。それは、汎用のコンピューターには非常に柔軟な使用パターンがあることです。IoT デバイスは、たとえ様々な機能に対応できるとしても、通常は極めて限られた形で 1 つか 2 つの機能を実行するために使用されます。この違いを利用してセキュリティーを強化する方法を調べるには、私が書いたこのリンク先の記事「 Securing a Raspberry Pi embedded in your IoT device 」を読んでください。

オープン・ポート

一部のネットワーク・ポートはオープン状態にしなければなりません。デバイスに Web ベースのインターフェースが備わっている場合、HTTP サーバー用のポート (できればポート 443) をオープンにしておく必要があります (可能であれば、HTTP ではなく HTTPS を使用してください)。IoT デバイスが例えば MQTT をクライアントとして使用するとしたら (通常、MQTT は IoT ソリューションに最善のネットワーク・プロトコルの 1 つとして見なされる ため、おそらくそうすることでしょう)、該当する発信接続用のポートがオープン状態になっていなければなりません。

ただし、ネットワークを介したすべての接続は、潜在的なセキュリティー・リスクになります。CVE Details Web サイトに 脆弱性のリスト が掲載されていますが、このリストに含まれているのは公開済みの脆弱性だけです。この他に、公開されていない脆弱性も存在します。それらの未知の脆弱性が、IoT デバイス内で使用するプログラムに影響を及ぼす可能性があります。IoT デバイスにジョブを行わせるためには、ある程度のネットワーク・アクセスを許可しなければなりませんが、必要以上のアクセスを許可すると不要なリスクをもたらすことになるため、そのようなアクセスは拒否してください。このプロセスは、「 最小権限 」と呼ばれる、セキュリティーの基本原則です。

汎用のオペレーティング・システムを使用する場合は、ファイアウォールを使用することが、ネットワーク・アクセスをブロックするのに最も簡単な方法となります。IoT デバイスが Linux を使用するとしたら、ファイアウォールのアップタイムとセキュリティーを確保するために、iptables アプリを使用できます。

特化されたオペレーティング・システム (NodeMCU など) を使用するデバイスの場合、必要以上の数のネットワーク・ポートをオープン状態に維持させる可能性はかなり低くなります。それでも、 nmap を使用してオープン状態または使用中のポートを確認することが賢明です。

暗号化

ネットワーク・セキュリティーの観点からは、IoT デバイスから中央サーバーに情報が送信されるのか、あるいはサーバーから IoT デバイスに情報を返すのかに関わらず、インターネット内を転送される情報に対しては以下の 2 つの攻撃が仕掛けられる可能性があります。

  • 窃盗。 IoT の情報に、関係者以外が価値を見いだすこともあります。例えば、テキサスの真夏にエアコンが 1 週間オフにされていることがわかれば、それは泥棒にとって、そこに住む家族が休暇で家を空けていて、その住居に侵入して物を盗み出せることを知らせる情報になります。
  • マスカレード、改ざん、または削除。 リモートから制御できるアラーム・システムが住居に備わっている場合、泥棒にとって、その住居に侵入する前にアラーム・システムを無効にするコマンドを送信できればなによりです。

このような攻撃を防ぐには、暗号化と証明書を使用できます。詳細については、このリンク先の記事「 ネットワーク上の IoT データをセキュリティーで保護する 」を参照してください。業界標準のソリューションである TLS を使用しているときに発生する可能性のある 1 つの問題は、中間者攻撃です。TLS では、サーバーを識別する証明書をソリューションとして使用しますが、これらの証明書にエンコードされている ID を実際に確認しなれば、セキュリティー対策にはなりません。

デフォルトの資格情報

IoT デバイスは、一般にネットワークを介してリモートから管理されます。通常、工場出荷時のデバイスはデフォルトの資格情報 (ユーザー名とパスワード) を使用していて、ユーザーがデフォルトの資格情報を変更することになっています。それを行わないと、攻撃者がデフォルトの資格情報を悪用してデバイスを制御できてしまいます。このような攻撃は IoT デバイスに対してすでに発生しています (Mirari、BrikerBot、Amnesia といったマルウェア・プログラム が、デフォルトの資格情報を使用して IoT デバイスに侵入したという事件)。この問題を回避するには、ユーザーが初めてログインしたときに、デフォルトのパスワードを変更しなければ何の操作もできないようにするという方法があります。

まとめ

この記事で説明した、IoT デバイスに対するセキュリティーの脅威の概要を参考に、皆さんのデバイスに対する具体的な脅威と、それらの脅威を緩和する方法を考えてください。完璧なソリューションを実現するのは不可能ですが、IoT デバイスを他のターゲットよりも攻撃しにくいものにすることは可能です。