経験者が教えるBluetooth通信におけるセキュリティ対策3つのセオリー
こんにちは、ムセンコネクトCMOの清水です。（プロフィール紹介はこちら）
今回はBluetooth通信、およびIoTデバイスにおけるセキュリティ対策に関するお話です。
スマートロック事業で得た「BLE通信のセキュリティ対策で考慮すべき3つのセオリー」
前職ではスマートロックの協業ビジネスを立ち上げ、その責任者としてスマートロックの開発や事業展開を経験しました。スマートロックと言えば高度なセキュリティが要求されるIoTデバイスというイメージがあると思いますが、スマートロックビジネスを展開する過程では、実際にセキュリティの問題や課題に直面し、頭を悩ませたことがありました。
そこで今回はスマートロック事業の経験を通じて得た「セキュリティ対策3つのセオリー」をご紹介したいと思います。
セキュリティ対策はビジネスを終わらせないために必要なもの
まずその前に、「セキュリティ対策」と聞くと
「大したデータを送っていないから」
「傍受されて困るデータじゃないから」
こういう理由で暗号化は必要ないと考えるエンジニアもいるかもしれません。実際そう言った声があるのも事実ですが、本当に怖いのは通信データを傍受されることだけではありません。
仮に自社製品のセキュリティ対策を全く考えず、平文で無線通信を行うとします。するとスニッファなどのツールを使えば比較的容易にBluetooth通信が傍受できてしまいますので、貴社の製品が平文で通信していることも容易にわかってしまいます。
するとどうなるか？
本当に怖いのはデータの中身を傍受されることよりも、「◯◯社の製品はセキュリティ対策を全くできていない」とか、「◯◯社はセキュリティ対策を全く行わないメーカー」とみなされてしまうことがリスクであり、そういったレッテルを貼られてしまうことにより、ビジネスを継続できなくなってしまうことが大きなリスクなのです。
実例を挙げます。
スマートロックを採用していただいた一部上場企業のA社は、セキュリティ対策の中身はもちろんのこと、「しっかりセキュリティ対策をしている事実」を重視していました。一部上場企業ともなればユーザー数は多く、SNSやネットの掲示板等ではネガティブなコメントも散見されます。
もし「A社は碌なセキュリティ対策をしていない」と書き込まれ、セキュリティ対策をしていない製品が出回っているとの風評被害が広まれば、全品回収は避けられないでしょうし、回収コスト、対策コスト、懸念されるリスクを考慮して、最悪ビジネスから撤退せざるを得ない事態にまで発展することを恐れていました。
また、その規模の会社であれば当然ビジネス上のライバルも多く、競争も熾烈です。中には競争相手を陥れるために悪意を持って使用したり、リバースエンジニアリングすることも予想されるため、「普通に使われる分には問題ない」が通用しないのです。
ここでポイントなのが、「セキュリティ対策をしている」という事実が重要であり、セキュリティ対策の中身についてはまた別の話ということです。高いセキュリティ強度であるに越したことはありませんが、中身まで説明を求められることは稀ですし、セキュリティ対策は機密事項ですので安易に公開すべきでもありません。
セキュリティの仕組みはさておき、とにかく対策をしておくことで、潜在的な大きなリスクを排除できることを知っておきましょう。
①Bluetooth通信の暗号化、接続認証はBluetoothの基本機能を用いず、上位アプリケーションで行うべき
セキュリティ対策の必要性についてお伝えしたところで、次はセキュリティ対策の考え方についてお話しします。経験から学んだセキュリティ対策のセオリーは大きく3つあります。順を追ってご紹介します。
まず一つ目。Bluetoothには基本機能として暗号化機能や接続認証機能が用意されていますが、これらは使わず、上位アプリケーションで行うべきです。ここでいう上位アプリケーションとは、自社機器のマイコンプログラムであったり、通信相手となるスマホアプリを指します。これが最も重要であり、セキュリティ対策の基本中の基本です。
Bluetoothの暗号化機能を使うべきではない一番の理由は、Bluetoothに脆弱性が見つかった時、Bluetoothの暗号化機能だけに頼り切ってしまっていると完全にノーガードの状態に晒されてしまうからです。
Bluetoothもこれまでに脆弱性が発見されたことがありました。自社デバイスは直接狙われていなくても、Bluetoothが「突破」されてしまう可能性は十分あり得ます。Windows OSや無線LANのように普及が進み、対象となるデバイスが増えれば増えるほどハッカーから狙われる可能性は高まりますので、これだけ搭載台数が増えたBluetoothも例外ではないでしょう。
万が一Bluetoothに脆弱性が見つかった場合でも自社デバイスへの影響を回避するため、上位アプリケーションで独自の暗号化をかけ、暗号化されたデータを無線で送るようにしましょう（受け取ったデータは上位アプリで復号する）。
①-2：ペアリングなどのBluetooth標準機能も極力使わない方が良い
また、Bluetoothの暗号化機能を利用したいがためにペアリング機能を使うのはやめましょう。
前述した理由に加え、ペアリングなどの「Bluetoothに備わっている標準機能」を使ってしまったことで、それに起因した不具合が発生してしまうことを避けるためです。
実例を挙げます。
今から数年前のことになりますが、あるIoTデバイスとAndroidスマホ間の接続不良が頻発してしまい、一般ユーザーからのクレームが殺到してしまったメーカーB社から原因調査を依頼されたことがありました。
弊社にて解析を行うと、Bluetoothのペアリング機能が接続不良の原因であることわかりました（注：メーカーB社が採用していた他社製BluetoothモジュールとAndroid OSとの相性の問題でした）。
ペアリング機能を使わなければ解決することがわかりましたが、そのメーカーB社は「暗号化のためにペアリング機能を用いていた」ため、セキュリティ対策（暗号化）をイチから見直す羽目になりました。
このように、Bluetoothに備わっている標準機能を流用すると、OS間の相性問題や不具合、脆弱性の影響を受けてしまう恐れがあるため、極力「自前」で対応したほうが安心です。
①-3：Bluetoothは「接続されてしまうもの」として、接続された上で通信して良いデバイスかどうか判断すべき
不特定多数の相手から接続できてはいけないデバイスの場合、「接続認証」を行う必要がありますが、これもBluetoothの標準機能は使わず上位アプリケーションで実装すべきです。
Bluetoothは基本1対1の関係で接続、通信します。片方のデバイスが相手から接続されるのを待つことになりますが（接続待ち）、待ち受けている状態は周囲のBluetoothデバイス（スマホやPCなど）であれば誰でも見つけることができますので、いつでも不特定多数からの接続要求が起こり得ると考えるのが無難です。
悪戯かもしれませんし、操作ミスかもしれませんし、悪意を持っての接続要求かもしれませんが、意図せず見知らぬデバイスから接続されてしまうことは起こり得ます。
このとき、「接続された相手が万が一意図した相手でない場合はこちらから切断する」という処理を入れておくと安心です。
例えば、接続されたら接続してきた相手に対してコマンドを投げ、意図したレスポンスが返ってこなければ「切断すべき相手」とみなして自分から切断します。接続後のやり取りは基本自社しか知らないはずですので、決められた通りに処理が進めば自社製品、そうでなければ切断すべき相手と判断できます。
結局、この「決められたやり取り」が暗号・復号処理に置き換えられるので、「上位アプリケーションで暗号化することが、接続認証対策にもなる」わけです。
②セキュリティの壁は二重三重で強化。壁の枚数は第3者に知られてはならない
セオリーの二つ目は「セキュリティ対策の壁は二重、三重で強化する。多ければ多い方が良い」且つ「壁の枚数は第3者に知られてはならない」です。
スマートロックの試作段階ではプロの脆弱性診断を受けたことがありました。セキュリティのプロともなれば、どういうセキュリティ対策をしているか、ある程度経験則でもわかってしまうようです。
ただ、「ここまでは突破できたけど、ここから先はもっと時間をかけないと無理だった」とか「たぶんこういうセキュリティをかけてると予想できるけど、対策全体までは把握できなかった」という感じで、やはりセキュリティ対策の壁が多ければ多いほど全部を突破するのは難しいようでした。
つまり、セキュリティの壁を一枚突破されてしまったとしても、二枚三枚と壁を設けて強化すれば完全突破を免れる可能性は高まります。
そしてもう一つ大事なのは、セキュリティの壁を幾重に重ねたとしても、その数を第3者に知られてはいけません。壁の枚数を知られることは、ハッカーに大きなヒントを与えるようなものです。
「セキュリティの壁を突破したけどまだ壁があった。もう一枚突破したけどさらに壁があった。」
「セキュリティの壁を何枚突破すれば良いかわからない」
こういう状況がハッキングをより難解にさせ、ハッカーの戦意を喪失させます。
以前、住宅防犯のプロに話を聞いたことがありますが、犯罪者の多くは「すぐにこじ開けられない扉（鍵）はすぐに諦める」ため、一つ一つは単純な仕組みの鍵でも、いくつも設置して「時間をかけさせる」のが効果的なのだそうです。
③最後の砦はオフラインの壁（物理的な障壁）
セオリーの三つ目はアナログな方法ですが、最後の最後に頼りになるのはオフラインの壁です（物理的な障壁）。
どういうことかと言うと、例えば
- 接続認証に必要な固有IDやシリアル番号は筐体に貼られているラベルを目視しなくては知ることができない。
- 筐体の物理スイッチで無線通信をOFFにできる。
- Bluetoothの電波出力を最小に制限しているため、物理的に極近距離まで近づかないと無線電波を傍受できない。
というように、遠隔（オンライン）からではどうにも突破できない障壁を設けます。
一番避けなくてはならない事態は、セキュリティを突破されたことによって、市場に出荷した全デバイスが悪用される対象となってしまうことです。遠隔からでも全デバイスをハッキングできてしまうとなれば、それこそ全数回収は避けられません。
ですが、オフラインの壁を作っておけば、最悪下記のような説明ができます。
- 筐体のIDを目視できるのは操作する人のみで、離れた場所にいる第3者が知ることはできません。
- 筐体の物理スイッチで無線通信をOFFにしてしまえば遠隔からハッキングすることは不可能です。
- Bluetoothの電波を傍受するためには物理的に2〜3mの距離まで近づかなければならないので、隠れたところから電波を傍受することはほぼ不可能です。
スマートロックでの体験談で言えば、ユーザーやお客様からセキュリティ対策について問われた際、こういった説明ができるか否かでお客様への納得してもらいやすさが雲泥の差ほど変わります。
セキュリティ強化と利便性のバランスを取るのが難しい
以上が実際に体験して得たセキュリティ対策の考え方です。
なお、セキュリティ対策は「どんな対策をしているかわからない」ことが重要であるため、ここでは実際の認証方法や暗号化の仕組みについては触れません。
認証方法はユーザーの操作や運用方法にも影響します。一般的にセキュリティ強化と利便性は反比例の関係にありますので、セキュリティのために面倒な操作が増えれば増えるほどユーザーから不満の声が挙がってしまうかもしれません。
また、例えば暗号の強度を高めれば高めるほど演算処理に時間がかかるため、デバイスの操作レスポンスが悪くなってしまうことがあります。これも使い勝手の悪さにつながりますので、一概にセキュリティ強度を高めれば高めるほど良いとは限りません。
このセキュリティ強化と利便性のバランスを取るのが非常に難しいのですが、バランスの取り方は対象となる製品・サービスのジャンルや価格帯によっても変わってくると思います。
本体ファームウェアアップデートできると安心な一方、新たな懸念も
「セキュリティ強化と利便性のバランス」でいうと、製品本体のファームウェアアップデート機能を設けるか否かも議論の余地があります。
セキュリティ対策はイタチごっこであり、どこまで対策しても「完璧」と言い切ることはできません。よって万が一セキュリティが破られてしまった時の保険として製品本体のファームウェアアップデート機能を設けておくとメーカーとしては少し安心です。
ただし、そのアップデートできる仕組みを組み込むことによって、それ自体がセキュリティホールになる可能性も秘めており、アップデートのために設けた外部I/F（＊）のハッキング対策も追加する必要が出てきます。
＊USBコネクタやOTA（Over The Air）用のBluetooth通信など
このように、セキュリティ対策の内容によって製品仕様も自ずと決まってくる部分があるため、製品コンセプトを企画・検討する早い段階からセキュリティ対策の方針も確認、固めておくべきだと思います。
ムセンコネクトはIoTデバイスのセキュリティ対策もお手伝いできます
前述したスマートロック開発では、セキュリティ対策を弊社ムセンコネクトCTOの三浦が担当しました。
暗号化や接続認証は通信するデバイス双方での対策となりますので、Bluetoothモジュール側だけではなく、対向となるスマホアプリ側での対策も必要です。
スマートロック開発では「スマートロックに内蔵するBLEモジュール」「iOSアプリ」「Androidアプリ」の全てを三浦が担当しましたので、ムセンコネクトでは組込み機器からスマホアプリまで含めたシステム全体のセキュリティ対策に対してアドバイスが可能です。
ムセンコネクトの無線化相談はどなたでも無料でご利用いただけますので、セキュリティ対策についてもお気軽にお問い合わせください。