IoT/M2Mのセキュリティ　　～こんなはずじゃ！orz になる前に知っておきたい IoT/M2Mの落とし穴～

IoT/M2Mのセキュリティ　　～こんなはずじゃ！orz になる前に知っておきたい IoT/M2Mの落とし穴～

1. 1. IoT/M2Mのセキュリティ ～こんなはずじゃ！orz になる前に知っておきたい IoT/M2M の落とし穴～ IT&組込み技術ライター トライアングルエレクトロニクス 代表 久保幸夫 2016/2/11 オープンハードカンファレンス 2016 Tokyo/Winter
2. 2. サマリ • IoT/M2Mシステムは、プロトタイプから、実用フェーズへ。でも、そ の前に大事なことが“セキュリティ”。 • セキュリティと言うと、情報漏洩とかサイバー攻撃とかを思い浮かべ ますが、“きちんとあたりまえに動く”すなわち“可用性”についても、 考慮が必要です。 • 研究室では、上手く動いても、フィールドでの実証試験や数を増 やしたときに動作しない… 特に、センサーノード（デバイス）とインターネットを接続する”要” となる、無線や通信のトラブルは、 システムにとって致命傷となる可能性があります。 • このカンファレンスでは、 IoT/M2Mシステムのセキュリティの概要と、 “動かないコンピュータ”にならないためにも、知っておきたい “無線や通信プロトコル”のことについて、お話をさせていただきます。
3. 3. 講師紹介 • 講師紹介 IT&組込み技術ライター トライアングルエレクトロニクス 代表 久保幸夫 • 関西の大手電鉄系エンジニアリング会社勤務後、2001年にIT関連セミ ナー講師として独立。現在は、日経BP社、電波新聞社、CQ出版社、オー ム社など技術系の出版社で執筆や講演活動を行う。ITや組込み、エレク トロニクス関連まで、幅広くてがける“何でも屋”。最近は、IoT/M2Mがら みの執筆仕事や講演・講座が急増中。 • 大阪・日本橋 ROBOBAの住人 – 日本橋でんでんタウン・ロボット連絡会 監事 • 雑誌連載 – 日経ネットワーク誌 ネットワーク実験室シリーズ 2003年4月～ – 電波新聞社 電子工作マガジン 工作記事 2008年～ – オーム社 電気と工事 ネットワークQ&A 20016年4月～ • CQ出版 インタフェース誌 2007年7月～2008年7月 その他
4. 4. • 日経ネットワーク 2016年1月号 • 連載100回記念 スペシャル • 無線LANの天敵 を再確認せよ！ こんな雑誌 記事を ぼちぼち 書いています
5. 5. もちろん 電子工作も 電子工作マガジン 工作記事連載中 オーディオ工作 初心者向け パッチン電子工作 アナログ電子工作 IEEE802.15.4 無線ラジコン
6. 6. IoT/M2Mのセキュリティ • １ セキュリティとは？ • ２ IoT/M2Mのセキュリティ • ３ 機密性の面からIoT/M2Mを考える • ４ 完全性の面からIoT/M2Mを考える • ５ 可用性の面からIoT/M2Mを考える • ６ まとめ
7. 7. １ セキュリティとは？ • JIS Q 27002 (ISO/IEC 27002)の定義 – 機密性 (confidentiality) • 情報へのアクセスを認められた者だけが、その情 報にアクセ スできる状態を確保すること – 完全性 (integrity) • 情報が破壊、改ざん又は消去されていない状態を確保す ること – 可用性 (availability) • 情報へのアクセスを認められた者が、必要時に中断す るこ となく、情報及び関連資産にアクセスできる状態を確保す ること – 以上3点（CIA）を維持すること。
8. 8. １ セキュリティとは？ • JIS Q 27002 (ISO/IEC 27002)の定義 – 機密性 (confidentiality) • 情報へのアクセスを認められた者だけが、その情 報にアクセ スできる状態を確保すること – 完全性 (integrity) • 情報が破壊、改ざん又は消去されていない状態を確保す ること – 可用性 (availability) • 情報へのアクセスを認められた者が、必要時に中断す るこ となく、情報及び関連資産にアクセスできる状態を確保す ること – 以上3点（CIA）を維持すること。 はあ？
9. 9. １ セキュリティとは？ • C:機密性 (コンフィデンシャリィ) – （見たらイケない人は）情報を見れない • 暗号化により、イケない人が見ても意味不明 • I：完全性 (インテグリティ） – 情報が正しく、書き換えられていないこと • デジタル署名などにより、改ざんを検知 • A:可用性 (アベイラビリティ) – 情報にアクセスできること • （見ても良い人は）必要な時に、情報にアクセスできる • 要は、いつも使えること • 以上3点（CIA）を維持すること。
10. 10. 試験に出ます！！ 情報セキュリティマネジメント試験 平成28年度春期試験（4月17日[日]実施） の受験申込み、現在受付中！ http://www.jitec.ipa.go.jp
11. 11. ちなみに・・・今は… サイバーセキュリティ月間 2月1日～3月18日 IPA (独立行政法人 情報処理推進機構) NISC（内閣サイバー セキュリティセンター） JNSA（NPO 日本ネット ワークセキュリティ協会）
12. 12. ２ IoT/M2Mのセキュリティ • IoT/M2M時代 なんでもかんでも、ネットにつながる時代 • やっぱ、 セキュリティ 大事だよね！ • じゃ、IoT/M2Mのセキュリティについて、３つの観 点から、見直してみよう C 機密性 (コンフィデンシャリィ) I 完全性 (インテグリティ） A 可用性 (アベイラビリティ)
13. 13. ２ IoT/M2Mのセキュリティ • IoT/M2Mシステムの要素 – データ • 蓄積・分析・判断 ビッグデータ、機械学習… – コネクタビリティ • 無線（PAN、モバイル）、有線 – ノード（デバイス） – センシング – コントロール – 実世界（リアル） • 計測対象・制御対象 – これらが（これらの中に）情報資産があり 脅威から守るべき対象となる。 情報資産 情報資産 情報資産 情報資産 情報資産
14. 14. 情報資産 情報資産 情報資産 情報資産 情報資産 めっちゃ 広い！ 全てカバーできる 人材っているの？ ２ IoT/M2Mのセキュリティ • IoT/M2Mシステムの要素 – データ • 蓄積・分析・判断 ビッグデータ、機械学習… – コネクタビリティ • 無線（PAN、モバイル）、有線 – ノード（デバイス） – センシング – コントロール – 実世界（リアル） • 計測対象・制御対象 – これらが（これらの中に）情報資産があり 脅威から守るべき対象となる。
15. 15. ２ IoT/M2Mのセキュリティ • IoT/M2Mシステムの要素 – データ • 蓄積・分析・判断 ビッグデータ、機械学習… – コネクタビリティ • 無線（PAN、モバイル）、有線 – ノード（デバイス） – センシング – コントロール – 実世界（リアル） – 物理セキュリティ • IoT/M2Mのセキュリティ IoT/M2Mのセキュリティ ＝サイバーセキュリティ＋リアル世界のセキュリティ ここの、セキュリティは、 結構注目されているような・・・ レイヤが低めの セキュリティが、 遅れているような・・・
16. 16. ３ 機密性の面からIoT/M2Mを考える • みちゃイヤ！見ないで！ と言う人いれば、 それを、見たい！ と言う人もいる。 • 見られたくないデータが、外部に漏れたら – 機密情報 • 企業機密 – 営業ノウハウ、顧客情報・・・ – 個人情報 • 基本的個人情報 • プライバシー – 恥ずかしい confidential
17. 17. ３ 機密性の面からIoT/M2Mを考える • こんな IoT/M2M嫌だ！ • 例 – IoT対応Bluetoothヘルスメータのデータが外部に 漏洩したら・・・ • 知らないBluetoothデバイスにペアリングしたら・・・ 隣の家のヘルスメータだった・・・ • こんなの嫌だ！ • IoT/M2Mのシステムを作り、サービスを提供する ほうも、個人情報への配慮が必要
18. 18. ３ 機密性の面からIoT/M2Mを考える • 個人情報が漏洩したときの代償 – 某、通信教育 会社 • 秘匿性 低 – 基本的情報 » 氏名、住所、性別、年齢・・・ – 500円の商品券/一人 – 下着メーカやエステ • 秘匿性 高い – 知られると超！恥ずかしい » スリーサイズ » エステの施術コース – 数万円/一人 – – 参考 • 弁護士法人みずほ中央法律事務所 – http://www.mc-law.jp/kigyohomu/9055/
19. 19. ３ 機密性の面からIoT/M2Mを考える • IoT/M2M時代 – 家の中、社会の隅々までセンサーノードが – ねっとにつながる機器が増える – ウェアラブル機器 • バイタル情報・・・ – 今まで、見えなかったことも、可視化できる – 恥ずかしいデータも、増える • 匿名であれば問題無し • これが、個人を特定できるデータと、紐づけられたら・・・ – しっかりと、対策を考える必要がある
20. 20. ４ 完全性の面からIoT/M2Mを考える • 完全性 (インテグリティ） – 情報が正しく、書き換えられていないこと • デジタル署名などにより、改ざんを検知 • と、書くと – 悪意の第三者（攻撃者）によって、 データが,“改ざん”される • 書き換えられるのは嫌だ！ • 正しいデータがあってはずの、BigData – じゃ、デジタル署名やMAC（メッセージ認証符号） を使って・・・メッセージの認証を・・・ • それも大事であるが、その前に・・・ 今日は、オープンハード カンファレンスなので、 ハードの話も
21. 21. ４ 完全性の面からIoT/M2Mを考える そもそも、そのデータ、正確ですか？ 例 Arduinoなどのマイコンに、 アナログ出力の温度センサーをつなぐ LM35 ANALOG IN 良くある回路！ でも、正確に動きますか 温度 センサー +5V GND Arduinoなどのマイコン OUT
22. 22. ４ 完全性の面からIoT/M2Mを考える • IoT/M2M あるある こんな形の 温度センサー
23. 23. ４ 完全性の面からIoT/M2Mを考える • そもそも、そのデータ、正確ですか？ • 動くこともあるが、 思ったように動かないことも （精度が出ない、ずれが大きい…） • 原因 – そもそも校正されていない – AD変換器のインピーダンスミスマッチング – ブレッドボートからの長い線にノイズがのる – USB給電 PCの電源ラインからノイズ – VCC が ＋５Vよりも低い – などなど
24. 24. ４ 完全性の面からIoT/M2Mを考える • そもそも、そのデータ、取引に使えますか？ • 計量法 – 計量法第10条第1項は、法定計量単位により取引又 は証明における計量をする者に、正確に計量をするよう 努めることを義務づけています。この規定は、2．で後述 する特定商品以外の商品を取引する場合にも適用され ます。 ・・・ – 詳しくは 経済産業省 – 計量法における商品量目制度の概要 » http://www.meti.go.jp/policy/economy/hyojun/te chno_infra/14_gaiyou_ryoumoku.html
25. 25. ４ 完全性の面からIoT/M2Mを考える • こんなIoT/M2M嫌だ！ – 使用電力が、多く計測されるスマートメータ • 実感よりも、消費電力が多い感じ • 電気料金高いなあ~ – ぼったくりメータ！は嫌だ！ – 笑い話では、ありません
26. 26. ４ 完全性の面からIoT/M2Mを考える • 1500件を交換、東北電力のスマートメーターに不具合 • http://itpro.nikkeibp.co.jp/atcl/news/16/012100184 • 東北電力は2016年1月20日、同社が設置していたスマートメーター の一部に不具合があったと発表した。2015年12月から設置を進める スマートメーターの電子回路に設計ミスあり、正しく電力量を測定できな かった。不具合があった設置済みのスマートメーターは約1500件。 • 不具合があったスマートメーターは、容量が比較的大きな250アンペ アの契約をしている顧客向けに、東北電力が2015年10月から設置を 始めたもの。売電設備を持たない顧客で売電用の電力量が測定され たり、顧客が使用した電力量を正確に測定できないケースがあった。 • 「スマートメーターの電子回路内にある電波のノイズを検知する機能 に、設計時から不具合があったことが原因」（東北電力の広報担当 者）という。12月末に実施した検査の際に、東北電力の社員が不具 合を発見した。
27. 27. ４ 完全性の面からIoT/M2Mを考える • 電気料金を高く取られるのは、嫌だし – そんないい加減なスマートメータのメータデータをAルートを 使って取集して、 MDMS（メータデータ管理システム） に集めたビッグデータからデータマイニングして 意味あるの？ • 大丈夫か！スマートメータ！ – 大丈夫か！スマートグリッド – 大丈夫か！IoT/M2M • “ビッグデータ”と、言う前に 足元固めないと 気を付けましょう！ 時間の関係で 次の話へ・・・
28. 28. ５ 可用性の面からIoT/M2Mを考える • 可用性 (アベイラビリティ) – 情報にアクセスできること – （見ても良い人は）必要な時に、情報にアクセスできる – 使って良い人は、使いたいときに、使える • 要は、動かないコンピュータ にならないこと！
29. 29. ５ 可用性の面からIoT/M2Mを考える • よくある可用性対策 – 故障、障害対策 • 信頼性設計 – バックアップ » システムの2重化（冗長化） – 縮退運転（フェールソフト、フォールバック） – 災害対策 • サーバをIDCへ • データのバックアップ • 電源 – UPS・・・ – これも、大事 だけど・・・ …そもそも IoT/M2Mの場合 バックアップ
30. 30. ５ 可用性の面からIoT/M2Mを考える • その、IoT/M2Mのシステム まともにフィールドで動作できるの？ • 例えば – センサーノードが数個の試験環境では動作した – 研究室の中では、正常動作が確認できた – センサーノードが数個の環境では • 無線も混雑しない • トラフィックの発生も少ない
31. 31. ５ 可用性の面からIoT/M2Mを考える • 例えば、 – 毎時0分0秒に、データを計測して、無線で上位の 機器（サーバ）に伝送する・・・センサーノード • 無線でのリトライがなければ、１秒動作して、後の時間は、 デープスリープで省電力 • 無線モジュールのメーカの話では、ボタン電池1個で3年間、 使用可能。 • これが、1個、2個では問題は無いと思うが・・・
32. 32. ５ 可用性の面からIoT/M2Mを考える • 何10、何100、何1000個・・・の センサーノードのシステムだと？？？ – 毎時0分0秒に、センサーノードが一斉に無線で送信 • 電波の混雑。当然、干渉の可能性 – 送信に失敗、送信リトライ – センサーノードのマイコンは、 すぐに、省電力モードに移行できない » 電池の減りが速くなる – もし、リトライが起きなかったら、バースト的な トラフィックが発生 – 毎時0分0秒に、サーバがセンサーノードから DoS(Denial of Service attack)攻撃受けるみたいなもの
33. 33. ５ 可用性の面からIoT/M2Mを考える • そのIoT/M2Mシステム – スケーラビリティを考慮して、設計されていますか？ – 例えば、HTTP(REST)で、クラウドのWebサーバへ、 データをアップする、ネットにつながる機器 – 試験での1個、2個のノードではOK – これが、数100、数1000になると・・・
34. 34. ５ 可用性の面からIoT/M2Mを考える • なぜか、IoT/M2M向けのプロトコルに、 興味にもっていただけないことが多いような… 「HTTP(REST)で、いいんじゃないの？」 的な… • Webサービスと、相性良いし • 一応、つながるし・・・ • スケーラビリティの面も、クラウドベースで スケールアップ、スケールアウトで頑張れは • M2Mは、ともかく、IoTはHTTP(REST)だね • 別のプロトコル、覚えるのが大変
35. 35. ５ 可用性の面から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
36. 36. ５ 可用性の面からIoT/M2Mを考える センサ WEBサーバ ② 複数のノードがある場合 HTTPクライアント センサ センサ ・・・ HTTP 大量のパケットが集中 センサ HTTPクライアント HTTP TCP/IP ①HTTP（REST）ノードが1個の場合 GETリクエスト WEBサーバ 最低9個のパケット 伝送遅延
37. 37. ５ 可用性の面からIoT/M2Mを考える • HTTP GET要求のパケットの例 1063バイトのパケット長
38. 38. ５ 可用性の面からIoT/M2Mを考える • こんなのが、せーのードン！で、数100、数1000きたら、 大変だ！ • HTTPは、どう考えても 重たすぎる – データのアップロードには、使えても、 レスポンスを考えると、制御には使いづらい • IoT/M2M向けの軽くて簡易なプロトコルも考えよう • 有名どころでは – 実績がある • MQTT 元々IBMが考えた、M2Mプロトコル – Representational State Transfer(REST) じゃないとダメ、なら • CoAP(Constrained Application Protocol)がある WEBサーバ 大量のパケットが集中
39. 39. ５ 可用性の面からIoT/M2Mを考える • MQTT（MQ Telemetry Transport) • MQはMessage Queueingとの説有 （Queでは無いとの説もあり） – IoT/M2M向けの軽量なプロトコル – パブリッシュ/サブスクライブ型のモデル • メッセージを送信する側 – パブリッシャー (発行者) • メッセージを受信する側 – サブスクライバー(購読者) – 中継をするのが、 MQTTサーバ ブローカー • サブスクライバー（購読者）は、 欲しいデータ（トピックス）のみ、 Subscribeできる。 – 3段階のQoSの確保が可能 – 必要に応じてSSL/TLSで暗号化できる。
40. 40. ５ 可用性の面からIoT/M2Mを考える • Publish/Subscribe – Publish • センサー側からMQTTサーバへ送信（発行） – Subscribe • MQTTサーバから（購読している）データを転送 • MQTTの特徴 – 相手の状況に関係なく、メッセージを送ることができる。 – サブスクライバー（購読者）側がダウン（スリープ）または、無線等 の回線がダウンしていてもパブリッシャー(発行者)は、メッセージを送 れる。 （ブローカーが保存してくれている。） – Will（遺言）機能 • サーバはクライアントを定期的に（デフォルト60秒）にPINGで死活を監 視 • サーバがクライアントのダウンを検知すると、事前に設定しておいた、 Will（遺言）メッセージを配信
41. 41. • 日経ネットワーク 2015年8月号 • IoT向けプロトコ ルMQTTを ラズパイで調査 せよ！ こんな 記事を書いて みました
42. 42. ５ 可用性の面からIoT/M2Mを考える • MQTTを使ったIoT/M2Mシステム 温度センサ 制御対 象機器 MQTTサーバ MQTTクライアント MQTTクライアント １：多の通信可能Publish 1階センサ パブリッシャーがトピックを名を付けて、ブローカー（サーバ）にメッ セージを発行（パブリッシュ） ブローカーは、該当しているトピック を購読しているサブスクライバ（購読者）に、メッセージを送信 パブリッシャー MQTT ブローカー サブスクライバ （購読者） 湿度センサ パブリッシャー 温度センサ 湿度センサ パブリッシャー 温度センサ 湿度センサ 2階センサ 3階センサ sensors/1f/temphumid temperature sensors/1f/humid 全てのトピック を購読 1階制御機器 HVAC 2階制御機器 監視装置
43. 43. ５ 可用性の面からIoT/M2Mを考える • MQTTのパケットの例 MQTTのPINGで 死活を監視 全体で92バイト MQTTのメッセージ HTTPに比べて、オーバーヘッドが 小さく、軽いプロトコル
44. 44. ５ 可用性の面から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の パブリッシュ コマンド
45. 45. ５ 可用性の面からIoT/M2Mを考える • CoAP（コープ）を使う方法も • Webiop で、簡単にCoAPを使用できる CoAPを使用して、 GPIOを制御できる
46. 46. ５ 可用性の面からIoT/M2Mを考える • CoAPクライアント側 CoAPクライアント側の Raspberry Pi Pythonで記述したスプリクト Python2の実行環境を （ Python Shell）呼出し
47. 47. ５ 可用性の面から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スプリクト
48. 48. ５ 可用性の面からIoT/M2Mを考える サーバ側の負荷や、レスポンスが気になる方は • HTTP(REST)の代わりに、 MQTTやCoAPを使うことも、積極的に考えてみ てください。 • もっとも・・・ TLS/SSLで暗号化すると パケット数、データ量は増えてしまう・・・ 課題もあり
49. 49. ５ 可用性の面からIoT/M2Mを考える • IoT/M2Mでは無線を使うシステムが多い。 • しかし… 2.4GHz帯の無線の混雑状況を考えると 正常に動作するのか？ • 2.4GHz帯の無線 – Bluetooth・BLE （Bluetooth Low Energy） – IEEE802.15.4/ZigBee – 無線LAN（WiFi） – 小電力無線 – デジタルコードレス電話 – ラジコン – 電子レンジ – ワイヤレスマイク – 医療器具・・・・ 電波が混雑すると、 伝送遅延 伝送エラー 回線の切断 等が発生する
50. 50. 事例 Bluetoothが ペアリング できない • 2013年 第2回ものアプリハッカソン 129個のAP メディアを含め100人以上の人 が集まった ほとんどの人が、スマホ タブレット、PCを使用 テザリングや無線ルータも使用
51. 51. 事例 WiFiの使用の自粛おねがい後 43個に減った！ Bluetooth ペアリングOK！ 会場の参加者に 無線LANテザリングや 無線ルータの使用の 自粛を要請した
52. 52. 2.4GHz(ISMバンド)の電波の解析 電波が 干渉する ZigBeeWiFi Bluetooth Wi-Spy DBx & Chanalyzer
53. 53. こんな 記事を書いて みました ネットワーク実験室 • やってみた！ 無線LAN混雑時のBluetoothの実験 日経ネットワーク 2014年7月号 Bluetoothが切れる原因を 突き止めろ
54. 54. 2.4GHz帯無線のBluetoothへの影響 • 実験してみた AP BT 機 器 ペアリング（接続）や 音声の伝送への影響は？ 複数の2.4GHz帯の無線の通信 AP ス マ ホ Wifiテザリング RWifiルータ Bluetooth AP BT 機 器 ♪ ペアリングして 接続する ♪
55. 55. Bluetoothオーディオレシーバー ♪ ♪ BluetoothでMP3の 音楽データを送信 するandroidスマホ Bluetooth オーディオレシーバー （USBで電源を供給） ペアリングして 接続する Bluetooth V.3.0+EDR A2DP V1.2
56. 56. 実験環境 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
57. 57. 実験環境 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で 音楽を送信するスマホ （移動させて実験）
58. 58. 実験1 電波が空いている状態 BTが周波数ホッピングしている Bluetoothが周波数をホッピングしながら、電 波を出している様子が、チラチラと見える 無線LANの電波が強い所は、 Bluetoothの電波が少ない（避けている）
59. 59. 実験2、3 APを2個追加 無線LANの隙間を縫うように狭い範囲で周波数ホッピングを行うBluetooth 実験2 実験3
60. 60. 特にBLEに注意！ • 実験２・３ 無線LANが混雑すると たまに、音が途切れる • さらに、混雑させてみたら 実験４ – 接続が解除 – 再度、ペアリングもなかなかできない状態に！ • ※極端な例とも言えるが、100以上の無線LAN アクセスポイントが、立つような状況では、あり得 る話
61. 61. 実験4 さらにAPを1個追加 実験4 接続が解除 ペアリングできない
62. 62. 特にBLEに注意！ • BLE(Bluetooth Low Energy）は、 Bluetooth（クラシックBluetooth ）よりも、 無線LANの混雑の影響を受けやすい BLE内蔵マイコンモジュール mbed HRM1017
63. 63. １ ？ • 日経ネットワーク 2015年7月号 • 電波が混雑した 環境でのBLEの接 続性を検証せ よ！ こんな記事を 書いてみた
64. 64. 実験環境 R0027046 Wi-SPY＋Chanalyzer（チャナライザ）で 電波解析 BLE内蔵マイコンモジュール mbed HRM1017 https://www.switch-science.com/catalog/1755/ 実験２で、邪魔をする無線LAN AP Chanalyzer（チャナライザ）
65. 65. 図 実験環境 A P １ A P ２ 1ch＋5ch 13ch BLE Windows8.1 クラシック Bluetooth 実験２で使用 設定用PC 実験２は、無線LANの影響下でBLE とBluetoothの接続性を確かめる 実験１では、電波が混雑していない状態 でBLEとBluetoothの接続性を確かめる
66. 66. Wi-SPYで電波解析 BLEのアドバタイズチャンネル もとからある 無線LANの電波 IEEE802.11 b/g の10ch
67. 67. BLEのアドバタイズチャンネル • Bluetooth LE入門ｽﾏﾎにつながる低消費電力無線ｾﾝｻの 開発をはじめよう • 単行本 – 2014/6/19 鄭 立 (著) より • BLEのアドバタイズチャンネルが、無線LANのチャネルと被っている
68. 68. 電波が混雑した状態 1ch＋5ch ＋13ch
69. 69. 電波混雑時 ペアリング失敗 • Orz… 大事なときに
70. 70. 無線問題の対策 • 無線LANの2.4GHz帯の電波は混雑が激しい • 根本的対策 – サブギガ帯 920MHｚなどへ移行 – 特にミッションクリティカルなシステムはサブギガ帯の使 用を考える と言っても急には無理なはなし • 運用面 – 紹介したツールなどを使ってモニタリング – 無線LANは５GHｚに移行し、2.4GHｚの使用を減らす – 人が集まる場合、 無線LANや、 Bluetoothの使用を減らすための お願いをする • 特に、WiFiテザリングや無線ルータ • 代わりに、その限りの公衆無線LANなどを用意しておく これ大事！結構有効！
71. 71. 問題解決には、まず知ること • 電波は見えないだけに やっかい – 見えない電波を知ること – 見えない電波を調べること – みんなに 見えない電波 を 知ってもらうこと • 節度をもって使えば、最高に便利なツール • 見えないことを良いことに、 各自が好き勝手やれば、最悪なツール • 電波の有効利用を考えて、 みんなが HAPPY になりたいものですね
72. 72. その他… IoT/M2Mのセキュリティ ＝サイバーセキュリティ＋リアル世界のセキュリティ リアル世界のセキュリティ センサーノードやネットにつながる機器のセキュリティ 装置の盗難、破壊、いたずら 誤操作、誤動作… 自然の脅威 温度、風雨、水、振動、直射日光… 動植物 鳥、獣、樹木に埋もれて発電できない 脅威は、いたるところにある それからどうシステムを守るか 従来のITの知見だけではダメ 人材が必要
73. 73. まとめ • IoT/M2Mのセキュリティ IoT/M2Mのセキュリティ ＝サイバーセキュリティ＋リアル世界のセキュリティ – 幅広い分野での対策が必要 • 特に、通信、デバイス、フィジカル面 • 全体がわかる人がいない – 人材育成が急務 – 機密性・完全性・可用性 に分類して整理 • 動かないコンピュータ にならないように 可用性の確保も大事 • 通信プロトコル » HTTP(REST)以外の選択肢も • 無線の混雑 に注意 » 運用の工夫やモニタリングも大切
74. 74. ご清聴ありがとうございました つながるだけのIoTだけじゃなく セキュリティも確保して ハッピーなIoT/M2Mの時代を 目指して行きましょう！ IT&組込み技術ライター トライアングルエレクトロニクス 代表 久保幸夫
75. 75. お問い合わせ 講演・執筆・IoT/M2M等の講習会 無線LANの調査等のご依頼は Tw:@tentenV3 FB: 久保幸夫 で検索 または http://triangle-ele.com/ のフォームから 大阪・日本橋（にっぽんばし） Roboba では 毎月 「ロボット連絡会」例会（勉強会） を開催しております http://roboba.jp こっちもよろしくお願い致します 電子工作マガジン 連載中！