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

IoT/M2Mのセキュリティ
～こんなはずじゃ！orz
になる前に知っておきたい IoT/M2M
の落とし穴～
IT&組込み技術ライター
トライアングルエレクトロニクス代表
久保幸夫
2016/2/11 オープンハードカンファレンス 2016 Tokyo/Winter

サマリ
• IoT/M2Mシステムは、プロトタイプから、実用フェーズへ。でも、そ
の前に大事なことが“セキュリティ”。
• セキュリティと言うと、情報漏洩とかサイバー攻撃とかを思い浮かべ
ますが、“きちんとあたりまえに動く”すなわち“可用性”についても、
考慮が必要です。
• 研究室では、上手く動いても、フィールドでの実証試験や数を増
やしたときに動作しない…
特に、センサーノード（デバイス）とインターネットを接続する”要”
となる、無線や通信のトラブルは、
システムにとって致命傷となる可能性があります。
• このカンファレンスでは、 IoT/M2Mシステムのセキュリティの概要と、
“動かないコンピュータ”にならないためにも、知っておきたい
“無線や通信プロトコル”のことについて、お話をさせていただきます。

講師紹介
• 講師紹介
トライアングルエレクトロニクス代表久保幸夫
• 関西の大手電鉄系エンジニアリング会社勤務後、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を考える
• ６まとめ

１セキュリティとは？
• 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システムの要素
– データ
• 蓄積・分析・判断ビッグデータ、機械学習…
– コネクタビリティ
• 無線（PAN、モバイル）、有線
– ノード（デバイス）
– センシング
– コントロール
– 実世界（リアル）
• 計測対象・制御対象
– これらが（これらの中に）情報資産があり
脅威から守るべき対象となる。
情報資産
情報資産
情報資産
情報資産情報資産

情報資産
情報資産
情報資産
情報資産情報資産
めっちゃ広い！
全てカバーできる
人材っているの？
– データ
– センシング
• 計測対象・制御対象
– これらが（これらの中に）情報資産があり
脅威から守るべき対象となる。

– データ
– センシング
– 物理セキュリティ
• IoT/M2Mのセキュリティ
＝サイバーセキュリティ＋リアル世界のセキュリティ
ここの、セキュリティは、
結構注目されているような・・・
レイヤが低めの
セキュリティが、
遅れているような・・・

３機密性の面からIoT/M2Mを考える
• みちゃイヤ！見ないで！と言う人いれば、
それを、見たい！と言う人もいる。
• 見られたくないデータが、外部に漏れたら
– 機密情報
• 企業機密
– 営業ノウハウ、顧客情報・・・
– 個人情報
• 基本的個人情報
• プライバシー
– 恥ずかしい
confidential

• こんな IoT/M2M嫌だ！
• 例
– IoT対応Bluetoothヘルスメータのデータが外部に
漏洩したら・・・
• 知らないBluetoothデバイスにペアリングしたら・・・
隣の家のヘルスメータだった・・・
• こんなの嫌だ！
• IoT/M2Mのシステムを作り、サービスを提供する
ほうも、個人情報への配慮が必要

• 個人情報が漏洩したときの代償
– 某、通信教育会社
• 秘匿性低
– 基本的情報
» 氏名、住所、性別、年齢・・・
– 500円の商品券/一人
– 下着メーカやエステ
• 秘匿性高い
– 知られると超！恥ずかしい
» スリーサイズ
» エステの施術コース
– 数万円/一人
–
– 参考
• 弁護士法人みずほ中央法律事務所
– http://www.mc-law.jp/kigyohomu/9055/

• IoT/M2M時代
– 家の中、社会の隅々までセンサーノードが
– ねっとにつながる機器が増える
– ウェアラブル機器
• バイタル情報・・・
– 今まで、見えなかったことも、可視化できる
– 恥ずかしいデータも、増える
• 匿名であれば問題無し
• これが、個人を特定できるデータと、紐づけられたら・・・
– しっかりと、対策を考える必要がある

４完全性の面からIoT/M2Mを考える
• 完全性 (インテグリティ）
– 情報が正しく、書き換えられていないこと
• デジタル署名などにより、改ざんを検知
• と、書くと
– 悪意の第三者（攻撃者）によって、
データが,“改ざん”される
• 書き換えられるのは嫌だ！
• 正しいデータがあってはずの、BigData
– じゃ、デジタル署名やMAC（メッセージ認証符号）
を使って・・・メッセージの認証を・・・
• それも大事であるが、その前に・・・
今日は、オープンハード
カンファレンスなので、
ハードの話も

そもそも、そのデータ、正確ですか？
例 Arduinoなどのマイコンに、
アナログ出力の温度センサーをつなぐ
LM35 ANALOG IN
良くある回路！
でも、正確に動きますか
温度
センサー
+5V
GND
Arduinoなどのマイコン
OUT

• IoT/M2M あるある
こんな形の
温度センサー

• そもそも、そのデータ、正確ですか？
• 動くこともあるが、
思ったように動かないことも
（精度が出ない、ずれが大きい…）
• 原因
– そもそも校正されていない
– AD変換器のインピーダンスミスマッチング
– ブレッドボートからの長い線にノイズがのる
– USB給電 PCの電源ラインからノイズ
– VCC が＋５Vよりも低い
– などなど

• そもそも、そのデータ、取引に使えますか？
• 計量法
– 計量法第10条第1項は、法定計量単位により取引又
は証明における計量をする者に、正確に計量をするよう
努めることを義務づけています。この規定は、2．で後述
する特定商品以外の商品を取引する場合にも適用され
ます。・・・
– 詳しくは経済産業省
– 計量法における商品量目制度の概要
» http://www.meti.go.jp/policy/economy/hyojun/te
chno_infra/14_gaiyou_ryoumoku.html

• こんなIoT/M2M嫌だ！
– 使用電力が、多く計測されるスマートメータ
• 実感よりも、消費電力が多い感じ
• 電気料金高いなあ~
– ぼったくりメータ！は嫌だ！
– 笑い話では、ありません

• 1500件を交換、東北電力のスマートメーターに不具合
• http://itpro.nikkeibp.co.jp/atcl/news/16/012100184
• 東北電力は2016年1月20日、同社が設置していたスマートメーター
の一部に不具合があったと発表した。2015年12月から設置を進める
スマートメーターの電子回路に設計ミスあり、正しく電力量を測定できな
かった。不具合があった設置済みのスマートメーターは約1500件。
• 不具合があったスマートメーターは、容量が比較的大きな250アンペ
アの契約をしている顧客向けに、東北電力が2015年10月から設置を
始めたもの。売電設備を持たない顧客で売電用の電力量が測定され
たり、顧客が使用した電力量を正確に測定できないケースがあった。
• 「スマートメーターの電子回路内にある電波のノイズを検知する機能
に、設計時から不具合があったことが原因」（東北電力の広報担当
者）という。12月末に実施した検査の際に、東北電力の社員が不具
合を発見した。

• 電気料金を高く取られるのは、嫌だし
– そんないい加減なスマートメータのメータデータをAルートを
使って取集して、 MDMS（メータデータ管理システム）
に集めたビッグデータからデータマイニングして
意味あるの？
• 大丈夫か！スマートメータ！
– 大丈夫か！スマートグリッド
– 大丈夫か！IoT/M2M
• “ビッグデータ”と、言う前に足元固めないと
気を付けましょう！時間の関係で
次の話へ・・・

５可用性の面からIoT/M2Mを考える
• 可用性 (アベイラビリティ)
– 情報にアクセスできること
– （見ても良い人は）必要な時に、情報にアクセスできる
– 使って良い人は、使いたいときに、使える
• 要は、動かないコンピュータ
にならないこと！

• よくある可用性対策
– 故障、障害対策
• 信頼性設計
– バックアップ
» システムの2重化（冗長化）
– 縮退運転（フェールソフト、フォールバック）
– 災害対策
• サーバをIDCへ
• データのバックアップ
• 電源
– UPS・・・
– これも、大事だけど・・・
…そもそも IoT/M2Mの場合
バックアップ

• その、IoT/M2Mのシステム
まともにフィールドで動作できるの？
• 例えば
– センサーノードが数個の試験環境では動作した
– 研究室の中では、正常動作が確認できた
– センサーノードが数個の環境では
• 無線も混雑しない
• トラフィックの発生も少ない

• 例えば、
– 毎時0分0秒に、データを計測して、無線で上位の
機器（サーバ）に伝送する・・・センサーノード
• 無線でのリトライがなければ、１秒動作して、後の時間は、
デープスリープで省電力
• 無線モジュールのメーカの話では、ボタン電池1個で3年間、
使用可能。
• これが、1個、2個では問題は無いと思うが・・・

• 何10、何100、何1000個・・・の
センサーノードのシステムだと？？？
– 毎時0分0秒に、センサーノードが一斉に無線で送信
• 電波の混雑。当然、干渉の可能性
– 送信に失敗、送信リトライ
– センサーノードのマイコンは、
すぐに、省電力モードに移行できない
» 電池の減りが速くなる
– もし、リトライが起きなかったら、バースト的な
トラフィックが発生
– 毎時0分0秒に、サーバがセンサーノードから
DoS(Denial of Service attack)攻撃受けるみたいなもの

• そのIoT/M2Mシステム
– スケーラビリティを考慮して、設計されていますか？
– 例えば、HTTP(REST)で、クラウドのWebサーバへ、
データをアップする、ネットにつながる機器
– 試験での1個、2個のノードではOK
– これが、数100、数1000になると・・・

• なぜか、IoT/M2M向けのプロトコルに、
興味にもっていただけないことが多いような…
「HTTP(REST)で、いいんじゃないの？」的な…
• Webサービスと、相性良いし
• 一応、つながるし・・・
• スケーラビリティの面も、クラウドベースで
スケールアップ、スケールアウトで頑張れは
• M2Mは、ともかく、IoTはHTTP(REST)だね
• 別のプロトコル、覚えるのが大変

• 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

センサ
WEBサーバ
② 複数のノードがある場合
HTTPクライアント
センサ
センサ
・・・
HTTP
大量のパケットが集中
センサ
HTTPクライアント
HTTP TCP/IP
①HTTP（REST）ノードが1個の場合
GETリクエスト
WEBサーバ
最低9個のパケット
伝送遅延

• HTTP GET要求のパケットの例
1063バイトのパケット長

• こんなのが、せーのードン！で、数100、数1000きたら、
大変だ！
• HTTPは、どう考えても重たすぎる
– データのアップロードには、使えても、
レスポンスを考えると、制御には使いづらい
• IoT/M2M向けの軽くて簡易なプロトコルも考えよう
• 有名どころでは
– 実績がある
• MQTT 元々IBMが考えた、M2Mプロトコル
– Representational State Transfer(REST)
じゃないとダメ、なら
• CoAP(Constrained Application Protocol)がある
WEBサーバ
大量のパケットが集中

• MQTT（MQ Telemetry Transport)
• MQはMessage Queueingとの説有
（Queでは無いとの説もあり）
– IoT/M2M向けの軽量なプロトコル
– パブリッシュ/サブスクライブ型のモデル
• メッセージを送信する側
– パブリッシャー (発行者)
• メッセージを受信する側
– サブスクライバー(購読者)
– 中継をするのが、 MQTTサーバブローカー
• サブスクライバー（購読者）は、
欲しいデータ（トピックス）のみ、 Subscribeできる。
– 3段階のQoSの確保が可能
– 必要に応じてSSL/TLSで暗号化できる。

• Publish/Subscribe
– Publish
• センサー側からMQTTサーバへ送信（発行）
– Subscribe
• MQTTサーバから（購読している）データを転送
• MQTTの特徴
– 相手の状況に関係なく、メッセージを送ることができる。
– サブスクライバー（購読者）側がダウン（スリープ）または、無線等
の回線がダウンしていてもパブリッシャー(発行者)は、メッセージを送
れる。
（ブローカーが保存してくれている。）
– Will（遺言）機能
• サーバはクライアントを定期的に（デフォルト60秒）にPINGで死活を監
視
• サーバがクライアントのダウンを検知すると、事前に設定しておいた、
Will（遺言）メッセージを配信

2015年8月号
• IoT向けプロトコ
ルMQTTを
ラズパイで調査
せよ！
こんな
記事を書いて
みました

• MQTTを使ったIoT/M2Mシステム
温度センサ
制御対
象機器
MQTTサーバ
MQTTクライアント
MQTTクライアント
１：多の通信可能Publish
1階センサ
パブリッシャーがトピックを名を付けて、ブローカー（サーバ）にメッ
セージを発行（パブリッシュ）ブローカーは、該当しているトピック
を購読しているサブスクライバ（購読者）に、メッセージを送信
パブリッシャー
MQTT
ブローカー
サブスクライバ
（購読者）
湿度センサ
温度センサ
湿度センサ
温度センサ
湿度センサ
2階センサ
3階センサ
sensors/1f/temphumid
temperature
sensors/1f/humid
全てのトピック
を購読
1階制御機器
HVAC
2階制御機器
監視装置

• MQTTのパケットの例
MQTTのPINGで
死活を監視
全体で92バイト
MQTTのメッセージ
HTTPに比べて、オーバーヘッドが
小さく、軽いプロトコル

• 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の
パブリッシュコマンド

• CoAP（コープ）を使う方法も
• Webiop で、簡単にCoAPを使用できる
CoAPを使用して、
GPIOを制御できる

• CoAPクライアント側
CoAPクライアント側の
Raspberry Pi
Pythonで記述したスプリクト
Python2の実行環境を
（ Python Shell）呼出し

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スプリクト

サーバ側の負荷や、レスポンスが気になる方は
• HTTP(REST)の代わりに、
MQTTやCoAPを使うことも、積極的に考えてみ
てください。
• もっとも・・・
TLS/SSLで暗号化すると
パケット数、データ量は増えてしまう・・・
課題もあり

• 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バンド)の電波の解析
電波が
干渉する
ZigBeeWiFi
Bluetooth
Wi-Spy DBx & Chanalyzer

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

2.4GHz帯無線のBluetoothへの影響
• 実験してみた
AP BT
機
器
ペアリング（接続）や
音声の伝送への影響は？
複数の2.4GHz帯の無線の通信
AP
ス
マ
ホ
Wifiテザリング
RWifiルータ
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（チャナライザ）

図実験環境
A
P
１
A
P
２
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 になりたいものですね

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

まとめ
• IoT/M2Mのセキュリティ
– 幅広い分野での対策が必要
• 特に、通信、デバイス、フィジカル面
• 全体がわかる人がいない
– 人材育成が急務
– 機密性・完全性・可用性に分類して整理
• 動かないコンピュータにならないように
可用性の確保も大事
• 通信プロトコル
» HTTP(REST)以外の選択肢も
• 無線の混雑に注意
» 運用の工夫やモニタリングも大切

ご清聴ありがとうございました
つながるだけのIoTだけじゃなく
セキュリティも確保して
ハッピーなIoT/M2Mの時代を
目指して行きましょう！
トライアングルエレクトロニクス代表久保幸夫

お問い合わせ
講演・執筆・IoT/M2M等の講習会
無線LANの調査等のご依頼は
Tw:@tentenV3
FB: 久保幸夫で検索
または
http://triangle-ele.com/ のフォームから
大阪・日本橋（にっぽんばし） Roboba では
毎月「ロボット連絡会」例会（勉強会）
を開催しております
http://roboba.jp
こっちもよろしくお願い致します
電子工作マガジン連載中！

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

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

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

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

Mais de Yukio Kubo

Mais de Yukio Kubo (8)