IoT/M2Mのセキュリティ

～こんなはずじゃ！orz になる前に知っておきたい IoT/M2M

の落とし穴～

IT&組込み技術ライター トライアングルエレクトロニクス 代表

久保幸夫

2016/2/11 オープンハードカンファレンス 2016 Tokyo/Winter

サマリ • IoT/M2Mシステムは、プロトタイプから、実用フェーズへ。でも、その前に大事なことが“セキュリティ”。

• セキュリティと言うと、情報漏洩とかサイバー攻撃とかを思い浮かべますが、“きちんとあたりまえに動く”すなわち“可用性”についても、考慮が必要です。

• 研究室では、上手く動いても、フィールドでの実証試験や数を増やしたときに動作しない… 特に、センサーノード（デバイス）とインターネットを接続する”要”となる、無線や通信のトラブルは、 システムにとって致命傷となる可能性があります。

• このカンファレンスでは、 IoT/M2Mシステムのセキュリティの概要と、 “動かないコンピュータ”にならないためにも、知っておきたい “無線や通信プロトコル”のことについて、お話をさせていただきます。

講師紹介 • 講師紹介 IT&組込み技術ライター トライアングルエレクトロニクス 代表 久保幸夫

• 関西の大手電鉄系エンジニアリング会社勤務後、2001年にIT関連セミ

ナー講師として独立。現在は、日経BP社、電波新聞社、CQ出版社、オーム社など技術系の出版社で執筆や講演活動を行う。ITや組込み、エレクトロニクス関連まで、幅広くてがける“何でも屋”。最近は、IoT/M2Mがらみの執筆仕事や講演・講座が急増中。

• 大阪・日本橋 ROBOBAの住人 – 日本橋でんでんタウン・ロボット連絡会 監事

• 雑誌連載

– 日経ネットワーク誌 ネットワーク実験室シリーズ 2003年4月～ – 電波新聞社 電子工作マガジン 工作記事 2008年～ – オーム社 電気と工事 ネットワークQ&A 20016年4月～

• CQ出版 インタフェース誌 2007年7月～2008年7月 その他

• 日経ネットワーク 2016年1月号

• 連載100回記念スペシャル

• 無線LANの天敵

を再確認せよ！

こんな雑誌 記事を ぼちぼち 書いています

もちろん 電子工作も

電子工作マガジン 工作記事連載中

オーディオ工作

初心者向け パッチン電子工作

アナログ電子工作

IEEE802.15.4 無線ラジコン

IoT/M2Mのセキュリティ

• １ セキュリティとは？ • ２ IoT/M2Mのセキュリティ • ３ 機密性の面からIoT/M2Mを考える • ４ 完全性の面からIoT/M2Mを考える • ５ 可用性の面からIoT/M2Mを考える • ６ まとめ

１ セキュリティとは？ • JIS Q 27002 (ISO/IEC 27002)の定義

–機密性 (confidentiality) • 情報へのアクセスを認められた者だけが、その情 報にアクセスできる状態を確保すること

–完全性 (integrity) • 情報が破壊、改ざん又は消去されていない状態を確保す ること

–可用性 (availability) • 情報へのアクセスを認められた者が、必要時に中断す ることなく、情報及び関連資産にアクセスできる状態を確保すること

– 以上3点（CIA）を維持すること。

１ セキュリティとは？ • JIS Q 27002 (ISO/IEC 27002)の定義

–機密性 (confidentiality) • 情報へのアクセスを認められた者だけが、その情 報にアクセスできる状態を確保すること

–完全性 (integrity) • 情報が破壊、改ざん又は消去されていない状態を確保す ること

–可用性 (availability) • 情報へのアクセスを認められた者が、必要時に中断す ることなく、情報及び関連資産にアクセスできる状態を確保すること

– 以上3点（CIA）を維持すること。

はあ？

１ セキュリティとは？ • C:機密性 (コンフィデンシャリィ)

–（見たらイケない人は）情報を見れない • 暗号化により、イケない人が見ても意味不明

• I：完全性 (インテグリティ） –情報が正しく、書き換えられていないこと

• デジタル署名などにより、改ざんを検知

• A:可用性 (アベイラビリティ) –情報にアクセスできること

• （見ても良い人は）必要な時に、情報にアクセスできる • 要は、いつも使えること

• 以上3点（CIA）を維持すること。

試験に出ます！！

情報セキュリティマネジメント試験 平成28年度春期試験（4月17日[日]実施） の受験申込み、現在受付中！ http://www.jitec.ipa.go.jp

ちなみに・・・今は… サイバーセキュリティ月間 2月1日～3月18日 IPA (独立行政法人 情報処理推進機構) NISC（内閣サイバー セキュリティセンター） JNSA（NPO 日本ネットワークセキュリティ協会）

２ IoT/M2Mのセキュリティ • IoT/M2M時代

なんでもかんでも、ネットにつながる時代

• やっぱ、 セキュリティ 大事だよね！

• じゃ、IoT/M2Mのセキュリティについて、３つの観点から、見直してみよう C 機密性 (コンフィデンシャリィ) I 完全性 (インテグリティ） A 可用性 (アベイラビリティ)

２ IoT/M2Mのセキュリティ • IoT/M2Mシステムの要素

– データ • 蓄積・分析・判断 ビッグデータ、機械学習…

– コネクタビリティ • 無線（PAN、モバイル） 、有線

– ノード（デバイス） – センシング – コントロール

– 実世界（リアル） • 計測対象・制御対象

– これらが（これらの中に）情報資産があり 脅威から守るべき対象となる。

情報資産

情報資産 情報資産

情報資産 情報資産

情報資産

情報資産 情報資産

情報資産 情報資産

めっちゃ 広い！ 全てカバーできる 人材っているの？

２ IoT/M2Mのセキュリティ • IoT/M2Mシステムの要素

– データ • 蓄積・分析・判断 ビッグデータ、機械学習…

– コネクタビリティ • 無線（PAN、モバイル） 、有線

– ノード（デバイス） – センシング – コントロール

– 実世界（リアル） • 計測対象・制御対象

– これらが（これらの中に）情報資産があり 脅威から守るべき対象となる。

２ IoT/M2Mのセキュリティ • IoT/M2Mシステムの要素

– データ • 蓄積・分析・判断 ビッグデータ、機械学習…

– コネクタビリティ • 無線（PAN、モバイル）、有線

– ノード（デバイス） – センシング – コントロール

– 実世界（リアル） –物理セキュリティ

• IoT/M2Mのセキュリティ

IoT/M2Mのセキュリティ ＝サイバーセキュリティ＋リアル世界のセキュリティ

ここの、セキュリティは、 結構注目されているような・・・

レイヤが低めの セキュリティが、

遅れているような・・・

３ 機密性の面からIoT/M2Mを考える • みちゃイヤ！見ないで！ と言う人いれば、 それを、見たい！ と言う人もいる。

• 見られたくないデータが、外部に漏れたら – 機密情報

• 企業機密 – 営業ノウハウ、顧客情報・・・

– 個人情報 • 基本的個人情報 • プライバシー

– 恥ずかしい

confidential

３ 機密性の面からIoT/M2Mを考える • こんな IoT/M2M嫌だ！

• 例

– IoT対応Bluetoothヘルスメータのデータが外部に漏洩したら・・・

• 知らないBluetoothデバイスにペアリングしたら・・・ 隣の家のヘルスメータだった・・・

• こんなの嫌だ！

• IoT/M2Mのシステムを作り、サービスを提供するほうも、個人情報への配慮が必要

３ 機密性の面からIoT/M2Mを考える • 個人情報が漏洩したときの代償

– 某、通信教育 会社 • 秘匿性 低

– 基本的情報 » 氏名、住所、性別、年齢・・・

– 500円の商品券/一人 – 下着メーカやエステ

• 秘匿性 高い – 知られると超！恥ずかしい

» スリーサイズ » エステの施術コース

– 数万円/一人 –

– 参考 • 弁護士法人みずほ中央法律事務所

– http://www.mc-law.jp/kigyohomu/9055/

３ 機密性の面からIoT/M2Mを考える • IoT/M2M時代

– 家の中、社会の隅々までセンサーノードが – ねっとにつながる機器が増える – ウェアラブル機器

• バイタル情報・・・

– 今まで、見えなかったことも、可視化できる

– 恥ずかしいデータも、増える • 匿名であれば問題無し • これが、個人を特定できるデータと、紐づけられたら・・・

– しっかりと、対策を考える必要がある

４ 完全性の面からIoT/M2Mを考える • 完全性 (インテグリティ）

–情報が正しく、書き換えられていないこと • デジタル署名などにより、改ざんを検知

• と、書くと –悪意の第三者（攻撃者）によって、 データが,“改ざん”される

• 書き換えられるのは嫌だ！ • 正しいデータがあってはずの、BigData

– じゃ、デジタル署名やMAC（メッセージ認証符号） を使って・・・メッセージの認証を・・・

• それも大事であるが、その前に・・・ 今日は、オープンハード カンファレンスなので、 ハードの話も

４ 完全性の面からIoT/M2Mを考える そもそも、そのデータ、正確ですか？

例 Arduinoなどのマイコンに、 アナログ出力の温度センサーをつなぐ

LM35 ANALOG IN

良くある回路！ でも、正確に動きますか

温度 センサー

+5V

GND

Arduinoなどのマイコン

OUT

４ 完全性の面からIoT/M2Mを考える • IoT/M2M あるある

こんな形の 温度センサー

４ 完全性の面からIoT/M2Mを考える • そもそも、そのデータ、正確ですか？

• 動くこともあるが、 思ったように動かないことも （精度が出ない、ずれが大きい…）

• 原因 – そもそも校正されていない – AD変換器のインピーダンスミスマッチング – ブレッドボートからの長い線にノイズがのる – USB給電 PCの電源ラインからノイズ – VCC が ＋５Vよりも低い – などなど

４ 完全性の面からIoT/M2Mを考える • そもそも、そのデータ、取引に使えますか？

• 計量法

– 計量法第10条第1項は、法定計量単位により取引又は証明における計量をする者に、正確に計量をするよう努めることを義務づけています。この規定は、2．で後述する特定商品以外の商品を取引する場合にも適用されます。 ・・・

– 詳しくは 経済産業省 – 計量法における商品量目制度の概要

» http://www.meti.go.jp/policy/economy/hyojun/techno_infra/14_gaiyou_ryoumoku.html

４ 完全性の面からIoT/M2Mを考える • こんなIoT/M2M嫌だ！

–使用電力が、多く計測されるスマートメータ

• 実感よりも、消費電力が多い感じ • 電気料金高いなあ~

–ぼったくりメータ！は嫌だ！

–笑い話では、ありません

４ 完全性の面からIoT/M2Mを考える • 1500件を交換、東北電力のスマートメーターに不具合 • http://itpro.nikkeibp.co.jp/atcl/news/16/012100184

• 東北電力は2016年1月20日、同社が設置していたスマートメーターの一部に不具合があったと発表した。2015年12月から設置を進めるスマートメーターの電子回路に設計ミスあり、正しく電力量を測定できなかった。不具合があった設置済みのスマートメーターは約1500件。

• 不具合があったスマートメーターは、容量が比較的大きな250アンペアの契約をしている顧客向けに、東北電力が2015年10月から設置を始めたもの。売電設備を持たない顧客で売電用の電力量が測定されたり、顧客が使用した電力量を正確に測定できないケースがあった。

• 「スマートメーターの電子回路内にある電波のノイズを検知する機能に、設計時から不具合があったことが原因」（東北電力の広報担当者）という。12月末に実施した検査の際に、東北電力の社員が不具合を発見した。

４ 完全性の面からIoT/M2Mを考える • 電気料金を高く取られるのは、嫌だし

– そんないい加減なスマートメータのメータデータをAルートを使って取集して、 MDMS（メータデータ管理システム）に集めたビッグデータからデータマイニングして 意味あるの？

• 大丈夫か！スマートメータ！

– 大丈夫か！スマートグリッド – 大丈夫か！IoT/M2M

• “ビッグデータ”と、言う前に 足元固めないと 気を付けましょう！

時間の関係で 次の話へ・・・

５ 可用性の面からIoT/M2Mを考える • 可用性 (アベイラビリティ)

–情報にアクセスできること – （見ても良い人は）必要な時に、情報にアクセスできる –使って良い人は、使いたいときに、使える

• 要は、動かないコンピュータ にならないこと！

５ 可用性の面からIoT/M2Mを考える • よくある可用性対策

–故障、障害対策 • 信頼性設計

– バックアップ » システムの2重化（冗長化）

– 縮退運転（フェールソフト、フォールバック） –災害対策

• サーバをIDCへ • データのバックアップ • 電源

– UPS・・・ – これも、大事 だけど・・・

…そもそも IoT/M2Mの場合

バックアップ

５ 可用性の面からIoT/M2Mを考える • その、IoT/M2Mのシステム

まともにフィールドで動作できるの？

• 例えば – センサーノードが数個の試験環境では動作した –研究室の中では、正常動作が確認できた

– センサーノードが数個の環境では

• 無線も混雑しない • トラフィックの発生も少ない

５ 可用性の面からIoT/M2Mを考える • 例えば、

–毎時0分0秒に、データを計測して、無線で上位の機器（サーバ）に伝送する・・・センサーノード

• 無線でのリトライがなければ、１秒動作して、後の時間は、デープスリープで省電力

• 無線モジュールのメーカの話では、ボタン電池1個で3年間、使用可能。

• これが、1個、2個では問題は無いと思うが・・・

５ 可用性の面からIoT/M2Mを考える • 何10、何100、何1000個・・・の センサーノードのシステムだと？？？ –毎時0分0秒に、センサーノードが一斉に無線で送信

• 電波の混雑。当然、干渉の可能性 – 送信に失敗、送信リトライ – センサーノードのマイコンは、 すぐに、省電力モードに移行できない

» 電池の減りが速くなる

– もし、リトライが起きなかったら、バースト的な トラフィックが発生 – 毎時0分0秒に、サーバがセンサーノードから

DoS(Denial of Service attack)攻撃受けるみたいなもの

５ 可用性の面からIoT/M2Mを考える • そのIoT/M2Mシステム

– スケーラビリティを考慮して、設計されていますか？

–例えば、HTTP(REST)で、クラウドのWebサーバへ、データをアップする、ネットにつながる機器

–試験での1個、2個のノードではOK

– これが、数100、数1000になると・・・

５ 可用性の面からIoT/M2Mを考える • なぜか、IoT/M2M向けのプロトコルに、 興味にもっていただけないことが多いような… 「HTTP(REST)で、いいんじゃないの？」 的な…

• Webサービスと、相性良いし • 一応、つながるし・・・ • スケーラビリティの面も、クラウドベースで スケールアップ、スケールアウトで頑張れは

• M2Mは、ともかく、IoTはHTTP(REST)だね • 別のプロトコル、覚えるのが大変

５ 可用性の面からIoT/M2Mを考える • HTTP(REST)の落とし穴

–数バイトのデータを送るだけでも、 最低でも9個のIPパケット

• １パケット MACヘッダ 14バイト IPV4ヘッダ 20バイト TCP ヘッダ 20バイト ＋ HTTPヘッダ・・・

※RFC上は、HTTP GETのURIの長さに上限なしとか

※参考にしたサイト http://www.autoidlab.jp/wp-content/themes/Autoid2011/rgthesis/hizumi-bachelor-thesis.pdf

５ 可用性の面からIoT/M2Mを考える

センサ

WEBサーバ

② 複数のノードがある場合 HTTPクライアント

センサ

センサ

・・・

HTTP 大量のパケットが集中

センサ

HTTPクライアント

HTTP TCP/IP

①HTTP（REST）ノードが1個の場合 GETリクエスト

WEBサーバ

最低9個のパケット 伝送遅延

５ 可用性の面からIoT/M2Mを考える • HTTP GET要求のパケットの例

1063バイトのパケット長

５ 可用性の面からIoT/M2Mを考える • こんなのが、せーのードン！で、数100、数1000きたら、大変だ！

• HTTPは、どう考えても 重たすぎる – データのアップロードには、使えても、 レスポンスを考えると、制御には使いづらい

• IoT/M2M向けの軽くて簡易なプロトコルも考えよう

• 有名どころでは – 実績がある

• MQTT 元々IBMが考えた、M2Mプロトコル – Representational State Transfer(REST) じゃないとダメ、なら

• CoAP(Constrained Application Protocol)がある

WEBサーバ

大量のパケットが集中

５ 可用性の面からIoT/M2Mを考える • MQTT（MQ Telemetry Transport)

• MQはMessage Queueingとの説有 （Queでは無いとの説もあり）

– IoT/M2M向けの軽量なプロトコル – パブリッシュ/サブスクライブ型のモデル

• メッセージを送信する側 – パブリッシャー (発行者)

• メッセージを受信する側 – サブスクライバー(購読者)

– 中継をするのが、 MQTTサーバ ブローカー • サブスクライバー（購読者）は、 欲しいデータ（トピックス）のみ、 Subscribeできる。

– 3段階のQoSの確保が可能 – 必要に応じてSSL/TLSで暗号化できる。

５ 可用性の面からIoT/M2Mを考える • Publish/Subscribe

– Publish • センサー側からMQTTサーバへ送信（発行）

– Subscribe • MQTTサーバから（購読している）データを転送

• MQTTの特徴

– 相手の状況に関係なく、メッセージを送ることができる。 – サブスクライバー（購読者）側がダウン（スリープ）または、無線等の回線がダウンしていてもパブリッシャー(発行者)は、メッセージを送れる。 （ブローカーが保存してくれている。）

– Will（遺言）機能 • サーバはクライアントを定期的に（デフォルト60秒）にPINGで死活を監視

• サーバがクライアントのダウンを検知すると、事前に設定しておいた、 Will（遺言）メッセージを配信

• 日経ネットワーク 2015年8月号

• IoT向けプロトコルMQTTを ラズパイで調査せよ！

こんな 記事を書いて みました

５ 可用性の面からIoT/M2Mを考える • MQTTを使ったIoT/M2Mシステム

温度センサ

制御対象機器

MQTTサーバ

MQTTクライアント

MQTTクライアント

１：多の通信可能 Publish

1階センサ パブリッシャーがトピックを名を付けて、ブローカー（サーバ）にメッセージを発行（パブリッシュ） ブローカーは、該当しているトピックを購読しているサブスクライバ（購読者）に、メッセージを送信

パブリッシャー MQTT ブローカー

サブスクライバ （購読者）

湿度センサ

パブリッシャー

温度センサ

湿度センサ

パブリッシャー

温度センサ

湿度センサ

2階センサ

3階センサ

sensors/1f/temp humid

temperature

sensors/1f/humid

全てのトピック を購読

1階制御機器

HVAC

2階制御機器

監視装置

５ 可用性の面からIoT/M2Mを考える • MQTTのパケットの例

MQTTのPINGで 死活を監視

全体で92バイト MQTTのメッセージ

HTTPに比べて、オーバーヘッドが 小さく、軽いプロトコル

５ 可用性の面からIoT/M2Mを考える • MQTTの実装は簡単

– Mosquitto の例

pi@raspberrypi ~ $ mosquitto_pub -h lite.mqtt.shiguredo.jp -u "tentenVVVF@github" -t "tentenVVVF@github/" -P scLb1m9jhzoe6Dk6 -l –d Client mosqpub/2412-raspberryp sending CONNECT Client mosqpub/2412-raspberryp received CONNACK pub1<RET> pub2<RET> pub3<RET> ・・・・

パブリッシャー側 pi@raspberrypi ~ $ sudo mosquitto_sub -h lite.mqtt.shiguredo.jp -u "tentenVVVF@github" -t "tentenVVVF@github/" -P scLb1m9jhzoe6Dk6 -d Client mosqsub/2450-raspberryp sending CONNECT Client mosqsub/2450-raspberryp received CONNACK Client mosqsub/2450-raspberryp sending SUBSCRIBE (Mid: 1, Topic: tentenVVVF@github/, QoS: 0) Client mosqsub/2450-raspberryp received SUBACK Subscribed (mid: 1): 0 Client mosqsub/2450-raspberryp received PUBLISH (d0, q0, r0, m0, 'tentenVVVF@github/', ... (4 bytes)) pub1 Client mosqsub/2450-raspberryp sending PINGREQ Client mosqsub/2450-raspberryp received PINGRESP ・・・・ pub2 ・・・・

サブスクライバー側

“pub1”をパブリッシュ

mosquittoの パブリッシュ コマンド

５ 可用性の面からIoT/M2Mを考える • CoAP（コープ）を使う方法も

• Webiop で、簡単にCoAPを使用できる

CoAPを使用して、 GPIOを制御できる

５ 可用性の面からIoT/M2Mを考える • CoAPクライアント側

CoAPクライアント側の Raspberry Pi

Pythonで記述したスプリクト

Python2の実行環境を（ Python Shell）呼出し

５ 可用性の面からIoT/M2Mを考える

from webiopi.clients import * from time import sleep # Create a WebIOPi client #client = PiHttpClient("192.168.0.7") #client = PiMixedClient("192.168.0.7") client = PiCoapClient("192.168.0.7") #client = PiMulticastClient() client.setCredentials("webiopi", "raspberry") # RPi native GPIO gpio = NativeGPIO(client) gpio.setFunction(25, "out") state = True while True: # toggle digital state state = not state gpio.digitalWrite(25, state) sleep(1)

繰り返し 1秒ごとに、GPIO25に論理１、論理0を交

互に出力

WebIOPのクライアント側で CoAPを使う設定

汎用IOポートの25番（GPIO25）を出力モードに設定

CoAPクライアント側のRaspberry Pi Pythonスプリクト

５ 可用性の面からIoT/M2Mを考える サーバ側の負荷や、レスポンスが気になる方は

• HTTP(REST)の代わりに、

MQTTやCoAPを使うことも、積極的に考えてみてください。

• もっとも・・・ TLS/SSLで暗号化すると パケット数、データ量は増えてしまう・・・ 課題もあり

５ 可用性の面からIoT/M2Mを考える • IoT/M2Mでは無線を使うシステムが多い。 • しかし…

2.4GHz帯の無線の混雑状況を考えると 正常に動作するのか？

• 2.4GHz帯の無線 – Bluetooth・BLE （Bluetooth Low Energy）

– IEEE802.15.4/ZigBee – 無線LAN（WiFi） – 小電力無線 – デジタルコードレス電話 – ラジコン – 電子レンジ – ワイヤレスマイク – 医療器具・・・・

電波が混雑すると、 伝送遅延 伝送エラー 回線の切断 等が発生する

事例

Bluetoothが ペアリング できない

• 2013年 第2回ものアプリハッカソン

129個のAP

メディアを含め100人以上の人が集まった

ほとんどの人が、スマホ タブレット、PCを使用

テザリングや無線ルータも使用

事例 WiFiの使用の自粛おねがい後

43個に減った！

Bluetooth ペアリングOK！

会場の参加者に 無線LANテザリングや 無線ルータの使用の

自粛を要請した

2.4GHz(ISMバンド)の電波の解析

電波が 干渉する

ZigBee WiFi

Bluetooth

Wi-Spy DBx & Chanalyzer

こんな 記事を書いて みました

ネットワーク実験室

• やってみた！ 無線LAN混雑時のBluetoothの実験 日経ネットワーク 2014年7月号 Bluetoothが切れる原因を 突き止めろ

2.4GHz帯無線のBluetoothへの影響 • 実験してみた

AP BT 機器

ペアリング（接続）や 音声の伝送への影響は？

複数の2.4GHz帯の無線の通信

AP

スマホ

Wifiテザリング

R Wifiルータ

Bluetooth

AP

BT 機器

♪ ペアリングして 接続する

♪

Bluetoothオーディオレシーバー

♪ ♪

BluetoothでMP3の 音楽データを送信 するandroidスマホ

Bluetooth オーディオレシーバー （USBで電源を供給）

ペアリングして 接続する

Bluetooth V.3.0+EDR A2DP V1.2

実験環境

AP

AP

AP AP

スマホ android

BT アンプ

Bluetooth オーディオレシーバー

♪

♪ ♪

WARPSTAR-ACF318 300Mbps 6ch+10ch

logitec53 450Mbps 3ch+7ch

その他のAP（外部のAP） 携帯電話会社のオフロード用APを始め 複数の無線LANが入り乱れている

Pingや ファイルの転送 で負荷をかける

Bluetooth

♪

logitec53 11n ／3ch+7 450Mbps 3ストリームMIMO logitec66 11n ／12ch 150Mbps 2ストリームMIMO WARPSTAR-ACF318 11n ／6ch+10ch 300Mbps 2ストリームMIMO

AP

logitec66 150Mbps 12ch

AP

元から設置してある 無線ブロードバンド ルータ

130Mbps／10ch

PC_A

PC_B

PC_C

L2SW

実験2～4

実験4

実験環境

R0024382

logitec53 11n／3ch+7 450Mbps 3ストリームMIMO logitec66 11n／12ch+8ch 300Mbps 2ストリームMIMO WARPSTAR-ACF318 11n／6ch+10ch 300Mbps 2ストリームMIMO

3台のAPを用意

Wi-SPY Chanalyzer

APとBluetoothオーディオレシーバーの距離は、見通し約7～8M

Bluetooth オーディオレシーバー

Bluetoothの邪魔 をする2.4GHz帯の 無線LANを搭載した パソコン

Bluetoothで 音楽を送信するスマホ （移動させて実験）

実験1 電波が空いている状態 BTが周波数ホッピングしている

Bluetoothが周波数をホッピングしながら、電

波を出している様子が、チラチラと見える

無線LANの電波が強い所は、 Bluetoothの電波が少ない（避けている）

実験2、3 APを2個追加 無線LANの隙間を縫うように狭い範囲で周波数ホッピングを行うBluetooth

実験2

実験3

特にBLEに注意！ • 実験２・３ 無線LANが混雑すると

たまに、音が途切れる

• さらに、混雑させてみたら 実験４ –接続が解除 –再度、ペアリングもなかなかできない状態に！

• ※極端な例とも言えるが、100以上の無線LANアクセスポイントが、立つような状況では、あり得る話

実験4 さらにAPを1個追加

実験4

接続が解除 ペアリングできない

特にBLEに注意！ • BLE(Bluetooth Low Energy）は、 Bluetooth（クラシックBluetooth ）よりも、 無線LANの混雑の影響を受けやすい

BLE内蔵マイコンモジュール mbed HRM1017

１ ？ • 日経ネットワーク

2015年7月号

• 電波が混雑した環境でのBLEの接

続性を検証せよ！

こんな記事を 書いてみた

実験環境

R0027046 Wi-SPY＋Chanalyzer（チャナライザ）で電波解析

BLE内蔵マイコンモジュール mbed HRM1017

https://www.switch-science.com/catalog/1755/

実験２で、邪魔をする無線LAN AP

Chanalyzer（チャナライザ）

図 実験環境

AP １

AP ２

1ch＋5ch 13ch BLE Windows8.1

クラシック Bluetooth

実験２で使用

設定用PC

実験２は、無線LANの影響下でBLE とBluetoothの接続性を確かめる

実験１では、電波が混雑していない状態 でBLEとBluetoothの接続性を確かめる

Wi-SPYで電波解析 BLEのアドバタイズチャンネル もとからある

無線LANの電波 IEEE802.11 b/g の10ch

BLEのアドバタイズチャンネル

• Bluetooth LE入門ｽﾏﾎにつながる低消費電力無線ｾﾝｻの開発をはじめよう

• 単行本 – 2014/6/19 鄭 立 (著) より

• BLEのアドバタイズチャンネルが、無線LANのチャネルと被っている

電波が混雑した状態

1ch＋5ch ＋13ch

電波混雑時 ペアリング失敗

• Orz… 大事なときに

無線問題の対策 • 無線LANの2.4GHz帯の電波は混雑が激しい • 根本的対策

– サブギガ帯 920MHｚなどへ移行 – 特にミッションクリティカルなシステムはサブギガ帯の使用を考える と言っても急には無理なはなし

• 運用面 – 紹介したツールなどを使ってモニタリング – 無線LANは５GHｚに移行し、2.4GHｚの使用を減らす – 人が集まる場合、 無線LANや、 Bluetoothの使用を減らすための お願いをする

• 特に、WiFiテザリングや無線ルータ • 代わりに、その限りの公衆無線LANなどを用意しておく

これ大事！結構有効！

問題解決には、まず知ること

• 電波は見えないだけに やっかい – 見えない電波を知ること – 見えない電波を調べること – みんなに 見えない電波 を 知ってもらうこと

• 節度をもって使えば、最高に便利なツール • 見えないことを良いことに、

各自が好き勝手やれば、最悪なツール

• 電波の有効利用を考えて、 みんなが HAPPY になりたいものですね

その他… IoT/M2Mのセキュリティ ＝サイバーセキュリティ＋リアル世界のセキュリティ リアル世界のセキュリティ センサーノードやネットにつながる機器のセキュリティ 装置の盗難、破壊、いたずら 誤操作、誤動作… 自然の脅威 温度、風雨、水、振動、直射日光… 動植物 鳥、獣、樹木に埋もれて発電できない 脅威は、いたるところにある それからどうシステムを守るか 従来のITの知見だけではダメ 人材が必要

まとめ • IoT/M2Mのセキュリティ

IoT/M2Mのセキュリティ ＝サイバーセキュリティ＋リアル世界のセキュリティ – 幅広い分野での対策が必要

• 特に、通信、デバイス、フィジカル面 • 全体がわかる人がいない

– 人材育成が急務 – 機密性・完全性・可用性 に分類して整理

• 動かないコンピュータ にならないように 可用性の確保も大事

• 通信プロトコル » HTTP(REST)以外の選択肢も

• 無線の混雑 に注意 » 運用の工夫やモニタリングも大切

ご清聴ありがとうございました つながるだけのIoTだけじゃなく セキュリティも確保して ハッピーなIoT/M2Mの時代を 目指して行きましょう！

IT&組込み技術ライター トライアングルエレクトロニクス 代表 久保幸夫

お問い合わせ 講演・執筆・IoT/M2M等の講習会 無線LANの調査等のご依頼は Tw:@tentenV3 FB: 久保幸夫 で検索 または http://triangle-ele.com/ のフォームから

大阪・日本橋（にっぽんばし） Roboba では 毎月 「ロボット連絡会」例会（勉強会） を開催しております http://roboba.jp

こっちもよろしくお願い致します

電子工作マガジン 連載中！