Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

7,249 views

Published on

2016/2/11 オープンハードカンファレンス 2016 Tokyo/Winter
講演 IoT/M2Mのセキュリティ 

Published in: Technology

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のセキュリティ • 1 セキュリティとは? • 2 IoT/M2Mのセキュリティ • 3 機密性の面からIoT/M2Mを考える • 4 完全性の面からIoT/M2Mを考える • 5 可用性の面からIoT/M2Mを考える • 6 まとめ
  7. 7. 1 セキュリティとは? • JIS Q 27002 (ISO/IEC 27002)の定義 – 機密性 (confidentiality) • 情報へのアクセスを認められた者だけが、その情 報にアクセ スできる状態を確保すること – 完全性 (integrity) • 情報が破壊、改ざん又は消去されていない状態を確保す ること – 可用性 (availability) • 情報へのアクセスを認められた者が、必要時に中断す るこ となく、情報及び関連資産にアクセスできる状態を確保す ること – 以上3点(CIA)を維持すること。
  8. 8. 1 セキュリティとは? • JIS Q 27002 (ISO/IEC 27002)の定義 – 機密性 (confidentiality) • 情報へのアクセスを認められた者だけが、その情 報にアクセ スできる状態を確保すること – 完全性 (integrity) • 情報が破壊、改ざん又は消去されていない状態を確保す ること – 可用性 (availability) • 情報へのアクセスを認められた者が、必要時に中断す るこ となく、情報及び関連資産にアクセスできる状態を確保す ること – 以上3点(CIA)を維持すること。 はあ?
  9. 9. 1 セキュリティとは? • 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. 2 IoT/M2Mのセキュリティ • IoT/M2M時代 なんでもかんでも、ネットにつながる時代 • やっぱ、 セキュリティ 大事だよね! • じゃ、IoT/M2Mのセキュリティについて、3つの観 点から、見直してみよう C 機密性 (コンフィデンシャリィ) I 完全性 (インテグリティ) A 可用性 (アベイラビリティ)
  13. 13. 2 IoT/M2Mのセキュリティ • IoT/M2Mシステムの要素 – データ • 蓄積・分析・判断 ビッグデータ、機械学習… – コネクタビリティ • 無線(PAN、モバイル)、有線 – ノード(デバイス) – センシング – コントロール – 実世界(リアル) • 計測対象・制御対象 – これらが(これらの中に)情報資産があり 脅威から守るべき対象となる。 情報資産 情報資産 情報資産 情報資産 情報資産
  14. 14. 情報資産 情報資産 情報資産 情報資産 情報資産 めっちゃ 広い! 全てカバーできる 人材っているの? 2 IoT/M2Mのセキュリティ • IoT/M2Mシステムの要素 – データ • 蓄積・分析・判断 ビッグデータ、機械学習… – コネクタビリティ • 無線(PAN、モバイル)、有線 – ノード(デバイス) – センシング – コントロール – 実世界(リアル) • 計測対象・制御対象 – これらが(これらの中に)情報資産があり 脅威から守るべき対象となる。
  15. 15. 2 IoT/M2Mのセキュリティ • IoT/M2Mシステムの要素 – データ • 蓄積・分析・判断 ビッグデータ、機械学習… – コネクタビリティ • 無線(PAN、モバイル)、有線 – ノード(デバイス) – センシング – コントロール – 実世界(リアル) – 物理セキュリティ • IoT/M2Mのセキュリティ IoT/M2Mのセキュリティ =サイバーセキュリティ+リアル世界のセキュリティ ここの、セキュリティは、 結構注目されているような・・・ レイヤが低めの セキュリティが、 遅れているような・・・
  16. 16. 3 機密性の面からIoT/M2Mを考える • みちゃイヤ!見ないで! と言う人いれば、 それを、見たい! と言う人もいる。 • 見られたくないデータが、外部に漏れたら – 機密情報 • 企業機密 – 営業ノウハウ、顧客情報・・・ – 個人情報 • 基本的個人情報 • プライバシー – 恥ずかしい confidential
  17. 17. 3 機密性の面からIoT/M2Mを考える • こんな IoT/M2M嫌だ! • 例 – IoT対応Bluetoothヘルスメータのデータが外部に 漏洩したら・・・ • 知らないBluetoothデバイスにペアリングしたら・・・ 隣の家のヘルスメータだった・・・ • こんなの嫌だ! • IoT/M2Mのシステムを作り、サービスを提供する ほうも、個人情報への配慮が必要
  18. 18. 3 機密性の面からIoT/M2Mを考える • 個人情報が漏洩したときの代償 – 某、通信教育 会社 • 秘匿性 低 – 基本的情報 » 氏名、住所、性別、年齢・・・ – 500円の商品券/一人 – 下着メーカやエステ • 秘匿性 高い – 知られると超!恥ずかしい » スリーサイズ » エステの施術コース – 数万円/一人 – – 参考 • 弁護士法人みずほ中央法律事務所 – http://www.mc-law.jp/kigyohomu/9055/
  19. 19. 3 機密性の面からIoT/M2Mを考える • IoT/M2M時代 – 家の中、社会の隅々までセンサーノードが – ねっとにつながる機器が増える – ウェアラブル機器 • バイタル情報・・・ – 今まで、見えなかったことも、可視化できる – 恥ずかしいデータも、増える • 匿名であれば問題無し • これが、個人を特定できるデータと、紐づけられたら・・・ – しっかりと、対策を考える必要がある
  20. 20. 4 完全性の面からIoT/M2Mを考える • 完全性 (インテグリティ) – 情報が正しく、書き換えられていないこと • デジタル署名などにより、改ざんを検知 • と、書くと – 悪意の第三者(攻撃者)によって、 データが,“改ざん”される • 書き換えられるのは嫌だ! • 正しいデータがあってはずの、BigData – じゃ、デジタル署名やMAC(メッセージ認証符号) を使って・・・メッセージの認証を・・・ • それも大事であるが、その前に・・・ 今日は、オープンハード カンファレンスなので、 ハードの話も
  21. 21. 4 完全性の面からIoT/M2Mを考える そもそも、そのデータ、正確ですか? 例 Arduinoなどのマイコンに、 アナログ出力の温度センサーをつなぐ LM35 ANALOG IN 良くある回路! でも、正確に動きますか 温度 センサー +5V GND Arduinoなどのマイコン OUT
  22. 22. 4 完全性の面からIoT/M2Mを考える • IoT/M2M あるある こんな形の 温度センサー
  23. 23. 4 完全性の面からIoT/M2Mを考える • そもそも、そのデータ、正確ですか? • 動くこともあるが、 思ったように動かないことも (精度が出ない、ずれが大きい…) • 原因 – そもそも校正されていない – AD変換器のインピーダンスミスマッチング – ブレッドボートからの長い線にノイズがのる – USB給電 PCの電源ラインからノイズ – VCC が +5Vよりも低い – などなど
  24. 24. 4 完全性の面からIoT/M2Mを考える • そもそも、そのデータ、取引に使えますか? • 計量法 – 計量法第10条第1項は、法定計量単位により取引又 は証明における計量をする者に、正確に計量をするよう 努めることを義務づけています。この規定は、2.で後述 する特定商品以外の商品を取引する場合にも適用され ます。 ・・・ – 詳しくは 経済産業省 – 計量法における商品量目制度の概要 » http://www.meti.go.jp/policy/economy/hyojun/te chno_infra/14_gaiyou_ryoumoku.html
  25. 25. 4 完全性の面からIoT/M2Mを考える • こんなIoT/M2M嫌だ! – 使用電力が、多く計測されるスマートメータ • 実感よりも、消費電力が多い感じ • 電気料金高いなあ~ – ぼったくりメータ!は嫌だ! – 笑い話では、ありません
  26. 26. 4 完全性の面からIoT/M2Mを考える • 1500件を交換、東北電力のスマートメーターに不具合 • http://itpro.nikkeibp.co.jp/atcl/news/16/012100184 • 東北電力は2016年1月20日、同社が設置していたスマートメーター の一部に不具合があったと発表した。2015年12月から設置を進める スマートメーターの電子回路に設計ミスあり、正しく電力量を測定できな かった。不具合があった設置済みのスマートメーターは約1500件。 • 不具合があったスマートメーターは、容量が比較的大きな250アンペ アの契約をしている顧客向けに、東北電力が2015年10月から設置を 始めたもの。売電設備を持たない顧客で売電用の電力量が測定され たり、顧客が使用した電力量を正確に測定できないケースがあった。 • 「スマートメーターの電子回路内にある電波のノイズを検知する機能 に、設計時から不具合があったことが原因」(東北電力の広報担当 者)という。12月末に実施した検査の際に、東北電力の社員が不具 合を発見した。
  27. 27. 4 完全性の面からIoT/M2Mを考える • 電気料金を高く取られるのは、嫌だし – そんないい加減なスマートメータのメータデータをAルートを 使って取集して、 MDMS(メータデータ管理システム) に集めたビッグデータからデータマイニングして 意味あるの? • 大丈夫か!スマートメータ! – 大丈夫か!スマートグリッド – 大丈夫か!IoT/M2M • “ビッグデータ”と、言う前に 足元固めないと 気を付けましょう! 時間の関係で 次の話へ・・・
  28. 28. 5 可用性の面からIoT/M2Mを考える • 可用性 (アベイラビリティ) – 情報にアクセスできること – (見ても良い人は)必要な時に、情報にアクセスできる – 使って良い人は、使いたいときに、使える • 要は、動かないコンピュータ にならないこと!
  29. 29. 5 可用性の面からIoT/M2Mを考える • よくある可用性対策 – 故障、障害対策 • 信頼性設計 – バックアップ » システムの2重化(冗長化) – 縮退運転(フェールソフト、フォールバック) – 災害対策 • サーバをIDCへ • データのバックアップ • 電源 – UPS・・・ – これも、大事 だけど・・・ …そもそも IoT/M2Mの場合 バックアップ
  30. 30. 5 可用性の面からIoT/M2Mを考える • その、IoT/M2Mのシステム まともにフィールドで動作できるの? • 例えば – センサーノードが数個の試験環境では動作した – 研究室の中では、正常動作が確認できた – センサーノードが数個の環境では • 無線も混雑しない • トラフィックの発生も少ない
  31. 31. 5 可用性の面からIoT/M2Mを考える • 例えば、 – 毎時0分0秒に、データを計測して、無線で上位の 機器(サーバ)に伝送する・・・センサーノード • 無線でのリトライがなければ、1秒動作して、後の時間は、 デープスリープで省電力 • 無線モジュールのメーカの話では、ボタン電池1個で3年間、 使用可能。 • これが、1個、2個では問題は無いと思うが・・・
  32. 32. 5 可用性の面からIoT/M2Mを考える • 何10、何100、何1000個・・・の センサーノードのシステムだと??? – 毎時0分0秒に、センサーノードが一斉に無線で送信 • 電波の混雑。当然、干渉の可能性 – 送信に失敗、送信リトライ – センサーノードのマイコンは、 すぐに、省電力モードに移行できない » 電池の減りが速くなる – もし、リトライが起きなかったら、バースト的な トラフィックが発生 – 毎時0分0秒に、サーバがセンサーノードから DoS(Denial of Service attack)攻撃受けるみたいなもの
  33. 33. 5 可用性の面からIoT/M2Mを考える • そのIoT/M2Mシステム – スケーラビリティを考慮して、設計されていますか? – 例えば、HTTP(REST)で、クラウドのWebサーバへ、 データをアップする、ネットにつながる機器 – 試験での1個、2個のノードではOK – これが、数100、数1000になると・・・
  34. 34. 5 可用性の面からIoT/M2Mを考える • なぜか、IoT/M2M向けのプロトコルに、 興味にもっていただけないことが多いような… 「HTTP(REST)で、いいんじゃないの?」 的な… • Webサービスと、相性良いし • 一応、つながるし・・・ • スケーラビリティの面も、クラウドベースで スケールアップ、スケールアウトで頑張れは • M2Mは、ともかく、IoTはHTTP(REST)だね • 別のプロトコル、覚えるのが大変
  35. 35. 5 可用性の面からIoT/M2Mを考える • HTTP(REST)の落とし穴 – 数バイトのデータを送るだけでも、 最低でも9個のIPパケット • 1パケット 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. 5 可用性の面からIoT/M2Mを考える センサ WEBサーバ ② 複数のノードがある場合 HTTPクライアント センサ センサ ・・・ HTTP 大量のパケットが集中 センサ HTTPクライアント HTTP TCP/IP ①HTTP(REST)ノードが1個の場合 GETリクエスト WEBサーバ 最低9個のパケット 伝送遅延
  37. 37. 5 可用性の面からIoT/M2Mを考える • HTTP GET要求のパケットの例 1063バイトのパケット長
  38. 38. 5 可用性の面からIoT/M2Mを考える • こんなのが、せーのードン!で、数100、数1000きたら、 大変だ! • HTTPは、どう考えても 重たすぎる – データのアップロードには、使えても、 レスポンスを考えると、制御には使いづらい • IoT/M2M向けの軽くて簡易なプロトコルも考えよう • 有名どころでは – 実績がある • MQTT 元々IBMが考えた、M2Mプロトコル – Representational State Transfer(REST) じゃないとダメ、なら • CoAP(Constrained Application Protocol)がある WEBサーバ 大量のパケットが集中
  39. 39. 5 可用性の面からIoT/M2Mを考える • MQTT(MQ Telemetry Transport) • MQはMessage Queueingとの説有 (Queでは無いとの説もあり) – IoT/M2M向けの軽量なプロトコル – パブリッシュ/サブスクライブ型のモデル • メッセージを送信する側 – パブリッシャー (発行者) • メッセージを受信する側 – サブスクライバー(購読者) – 中継をするのが、 MQTTサーバ ブローカー • サブスクライバー(購読者)は、 欲しいデータ(トピックス)のみ、 Subscribeできる。 – 3段階のQoSの確保が可能 – 必要に応じてSSL/TLSで暗号化できる。
  40. 40. 5 可用性の面からIoT/M2Mを考える • Publish/Subscribe – Publish • センサー側からMQTTサーバへ送信(発行) – Subscribe • MQTTサーバから(購読している)データを転送 • MQTTの特徴 – 相手の状況に関係なく、メッセージを送ることができる。 – サブスクライバー(購読者)側がダウン(スリープ)または、無線等 の回線がダウンしていてもパブリッシャー(発行者)は、メッセージを送 れる。 (ブローカーが保存してくれている。) – Will(遺言)機能 • サーバはクライアントを定期的に(デフォルト60秒)にPINGで死活を監 視 • サーバがクライアントのダウンを検知すると、事前に設定しておいた、 Will(遺言)メッセージを配信
  41. 41. • 日経ネットワーク 2015年8月号 • IoT向けプロトコ ルMQTTを ラズパイで調査 せよ! こんな 記事を書いて みました
  42. 42. 5 可用性の面からIoT/M2Mを考える • MQTTを使ったIoT/M2Mシステム 温度センサ 制御対 象機器 MQTTサーバ MQTTクライアント MQTTクライアント 1:多の通信可能Publish 1階センサ パブリッシャーがトピックを名を付けて、ブローカー(サーバ)にメッ セージを発行(パブリッシュ) ブローカーは、該当しているトピック を購読しているサブスクライバ(購読者)に、メッセージを送信 パブリッシャー MQTT ブローカー サブスクライバ (購読者) 湿度センサ パブリッシャー 温度センサ 湿度センサ パブリッシャー 温度センサ 湿度センサ 2階センサ 3階センサ sensors/1f/temphumid temperature sensors/1f/humid 全てのトピック を購読 1階制御機器 HVAC 2階制御機器 監視装置
  43. 43. 5 可用性の面からIoT/M2Mを考える • MQTTのパケットの例 MQTTのPINGで 死活を監視 全体で92バイト MQTTのメッセージ HTTPに比べて、オーバーヘッドが 小さく、軽いプロトコル
  44. 44. 5 可用性の面から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. 5 可用性の面からIoT/M2Mを考える • CoAP(コープ)を使う方法も • Webiop で、簡単にCoAPを使用できる CoAPを使用して、 GPIOを制御できる
  46. 46. 5 可用性の面からIoT/M2Mを考える • CoAPクライアント側 CoAPクライアント側の Raspberry Pi Pythonで記述したスプリクト Python2の実行環境を ( Python Shell)呼出し
  47. 47. 5 可用性の面から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に論理1、論理0を交 互に出力 WebIOPのクライアント側で CoAPを使う設定 汎用IOポートの25番(GPIO25)を出力 モードに設定 CoAPクライアント側のRaspberry Pi Pythonスプリクト
  48. 48. 5 可用性の面からIoT/M2Mを考える サーバ側の負荷や、レスポンスが気になる方は • HTTP(REST)の代わりに、 MQTTやCoAPを使うことも、積極的に考えてみ てください。 • もっとも・・・ TLS/SSLで暗号化すると パケット数、データ量は増えてしまう・・・ 課題もあり
  49. 49. 5 可用性の面から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に注意! • 実験2・3 無線LANが混雑すると たまに、音が途切れる • さらに、混雑させてみたら 実験4 – 接続が解除 – 再度、ペアリングもなかなかできない状態に! • ※極端な例とも言えるが、100以上の無線LAN アクセスポイントが、立つような状況では、あり得 る話
  61. 61. 実験4 さらにAPを1個追加 実験4 接続が解除 ペアリングできない
  62. 62. 特にBLEに注意! • BLE(Bluetooth Low Energy)は、 Bluetooth(クラシックBluetooth )よりも、 無線LANの混雑の影響を受けやすい BLE内蔵マイコンモジュール mbed HRM1017
  63. 63. 1 ? • 日経ネットワーク 2015年7月号 • 電波が混雑した 環境でのBLEの接 続性を検証せ よ! こんな記事を 書いてみた
  64. 64. 実験環境 R0027046 Wi-SPY+Chanalyzer(チャナライザ)で 電波解析 BLE内蔵マイコンモジュール mbed HRM1017 https://www.switch-science.com/catalog/1755/ 実験2で、邪魔をする無線LAN AP Chanalyzer(チャナライザ)
  65. 65. 図 実験環境 A P 1 A P 2 1ch+5ch 13ch BLE Windows8.1 クラシック Bluetooth 実験2で使用 設定用PC 実験2は、無線LANの影響下でBLE とBluetoothの接続性を確かめる 実験1では、電波が混雑していない状態 で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帯の電波は混雑が激しい • 根本的対策 – サブギガ帯 920MHzなどへ移行 – 特にミッションクリティカルなシステムはサブギガ帯の使 用を考える と言っても急には無理なはなし • 運用面 – 紹介したツールなどを使ってモニタリング – 無線LANは5GHzに移行し、2.4GHzの使用を減らす – 人が集まる場合、 無線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 こっちもよろしくお願い致します 電子工作マガジン 連載中!

×