Wi-Fiを用いた人流分析における課題とその解決に向けたFree Wi-Fi認証機能の検討
秋山 豊和1，上東 亜佑稀1 ，石原 真太郎1，望月祐洋2 ，西田 純二21京都産業大学
2（株）社会システム総合研究所

背景（１）• 外国人観光客の増加– トリップアドバイザー「外国人に人気の観光スポット2017」を発表
https://prtimes.jp/main/html/rd/p/000000465.0000
01853.html
第1位
第2位
第3位

伏見稲荷大社
アキバフクロウ
広島平和記念資料館：
第22位 マジックバーフレンチドロップ
第23位 RORコメディー：
第27位 なばなの里：

アキバフクロウ
http://akiba2960.com/jp/

マジックバーフレンチドロップ

日本人には馴染みのないスポットも外国人から見た日本の魅力を理解する必要がある

RORコメディー

なばなの里

https://prtimes.jp/main/html/rd/p/000000465.000001853.html

背景（２）• 新規観光スポット開拓の課題– 観光スポットはSNS等から発見できるが，観光圏（※１）が抱える課題は不明• 例）トイレの数や案内表示の多言語対応– 自治体施策の優先度付け• 例）交通の利便性・安全性
観光流動分析に基づく観光客への利便性の提供により，観光圏の品質向上を目指す※１ 自然・歴史・文化等において密接な関係のある観光地を一体とした区域

背景（３）• 携帯電話網（格安SIM等）を用いた人流分析については既に通信事業者が提供中– 例）docomo モバイル空間統計

地方の観光協会など中小企業の予算では利用が難しい
Wi-Fiパケットキャプチャによる人流分析であれば低コストに実現可能

Wi-Fiパケットキャプチャシステム（現行システム）
クラウドストレージサーバ
ログデータ
受信・蓄積

人流解析処理系

問合せ処理系
可視化処理系

ログデータ

Internet

OUIの最上位バイトの情報のみ，ランダム化MACアドレスの判定に利用{ TIMESTAMP, AMAC, AMPID, OUI, SC, RSSI }Wi-Fiパケットセンサ

海の京都エリアに50台程度展開済み匿名化したデータを収集

NTP時刻同期

Wi-Fi対応機器

Probe Request
キャプチャ

一方向

ハッシュ化

ログデータ
保存

ログデータ

アップロードエンドユーザにはWebページ，観光案内所等での提⽰で情報共有

収集している情報
一定期間ごとに変化するソルトと• タイムスタンプ
MACアドレスで生成したハッシュ値．
• 匿名化MACアドレス ソルトは保存しないため，一定期間経過後はMACアドレスとは照合不能．
• センサID（位置情報）• OUI 最上位バイトの情報のみをランダム化MACアドレスの判定に利用• SC• RSSI センサの位置情報とRSSI値から現在位置を推定

宮津市での人流分析の活用事例①7月から8月の観光客数分布②②道の駅舞鶴とれとれセンターの８月１５日の来客の滞留時間分布
観光客と地域住民は識別できるが，外国人や出身国などは識別できない③①今年はお盆休みが長く、この１週間の来客数が多い。
②観光施設の売上は来客数✕滞留時間により影響を受けるため、滞留時間を増やすための工夫が求められている。
③天橋立のような核観光地から、他の観光地にどのように誘導していくかが観光計画の課題となる。

③各施設間流動のコードダイアグラム

属性情報の取得• 位置情報に加えて属性情報を取得できれば出身国などの情報を踏まえて分析できる属性情報を取得するためには？

現行システムに加えてFree Wi-Fiで承諾&情報収集
承諾を得た
ログのみ同期
クラウド環境インターネット
認証後はアクセス可能

観光案内所 A
アクセスログインターネット回線（観光案内所のものを利⽤）

CaptivePortal
サーバ

認証前はCaptive Portalにリダイレクト

Wi-Fiパケット
キャプチャシステム
（既存）
情報同
アクセ
期
ス
ログ
機構

承諾を得た
属性情報を保存
ユーザ情報
アクセスロ
グ

MACアドレスとユーザ情報のSNS認証 マッピングを更新

オンラインサインアップ

Wi-Fi
アクセスポイント

⽒名Twitter

国籍⼩型PC
認証成功時にWi-Fiプロファイルを配布
観光客のデバイス 以降は直接認証

性別MAC

⾃動取得

E-mailPassword

ローカルWeb認証E-mailPassword

プロトタイプ実装での使用機器• Wi-Fi AP: Aruba IAP 207• Wi-Fi パケットキャプチャ（AMPセンサ）:– Raspberry Pi 3
– Wi-Fiドングル(BUFFALO)– 3Gアップロード用ドングル• 認証サーバ– Ubuntu Linux 16.04– Apache HTTPD + passenger– Captive Portalサーバ（Railsアプリ）• https://github.com/toyokazu/captive̲portal• omniauthを用いた複数認証方式サポート– Facebook, Twitter, GoogleなどのSNS認証– サインアップによるローカル認証

認証の目的1. Free Wi-Fiの認証– 不正なユーザがFree Wi-Fiネットワークを悪用して他のサイトを攻撃した場合など，ユーザを追跡できる必要がある

2. 属性取得と属性提供の承認プロセス– SNS認証では自動的に必要な属性を取得することができる– また認証画面とともに同意事項を提示することで承認フェーズを設けることができる

記録が必要な情報とその分離
1. Free Wi-Fiの認証– 本人への連絡が可能な情報••

メールアドレス
SNS ID– 本人への紐付けが可能なため個人情報となる

2. 属性取得と属性提供の承認プロセス– 今回のターゲットは人流分析••

人流分析に必要な匿名化ID（MACアドレスから生成）
国籍，性別などの属性情報はこちらに紐付け

匿名化処理の概要
Free Wi-Fiアクセスログ
タイムスタンプ

個人識別情報MACアドレス

2017/11/9 10:50

hoge@example.com (Mail)

11:22:33:44:55:66

2017/11/9 10:57

foo@facebook.com (SNS ID)

aa:bb:cc:dd:ee:ff::

一定期間を越えると紐付けできない

属性付き匿名化IDリスト（ソルト更新まで保存）
匿名化ID

国籍等

8dL37fvXlbGiXVhp

アメリカ

g0TkMhAB3d2InJOQ

中国::

許諾を得たもの
のみ紐付け:

一週間でソルトを更新取得した属性

一定期間紐付けできる現行システムの情報
タイムスタンプ

匿名化ID

位置情報・その他

2017/11/9 11:05

8dL37fvXlbGiXVhp

35.658581, 139.745433

2017/11/9 11:20

8dL37fvXlbGiXVhp

35.681167, 139.767052:::

実証実験で調査したい内容• （予想）オンラインサインアップがないとサービス利用してもらえない
課題：オンラインサインアップではメールアドレス確認などができず，トレーサビリティが不十分• （知りたいこと）どのくらいのユーザがSNS認証を利用するか？
– できればオンラインサインアップは省略したい残課題
1. APの機能でSNS認証用に適切にアクセス制御ができない– ホストベースのアクセス制御のみで，URIベースのアクセス制御ができない• www.facebook.comやtwitter.comにアクセスできてしまう• 自前APならどの程度制御可能かは検証予定– APベンダ側の今後の機能拡張に期待？

2. SNS認証における二段階認証の罠– 普段用いているブラウザでの認証がうまく使えない3. Webベース認証はローミングするたびに再認証がかかって鬱陶しい
4. Webベース認証はフィッシングAPに弱い– 認証部分についてさらなる検討が必要

SNS認証とFree Wi-Fi認証の例• 例）Facebook– 初めてログインする端末では二段階認証を要求– 海外に来てて電話とれないのに非常にもSMSにメッセージが送られる (>̲<)
え？一旦ブラウザで認証しておけば，クライアントは保存されるのでは？

• 例）MacOSでのCaptive Portal実装– プライバシモードでブラウザ起動されるため，異なる端末と認識されてしまう (>̲<)– しかも保存しているパスワードも利用してくれない• iOSの場合はパスワードは利用できる

残課題
1. APの機能でSNS認証用に適切にアクセス制御ができない– ホストベースのアクセス制御のみで，URIベースのアクセス制御ができない• www.facebook.comやtwitter.comにアクセスできてしまう• 自前APならどの程度制御可能かは検証予定– APベンダ側の今後の機能拡張に期待？

2. SNS認証における二段階認証の罠– 普段用いているブラウザでの認証がうまく使えない

3. Webベース認証はローミングするたびに再認証がかかって鬱陶しい
4. Webベース認証はフィッシングAPに弱い– 認証部分についてさらなる検討が必要

Wi-Fiプロファイルを活用した認証

Wi-Fiプロファイルを活用した認証
承諾を得た
ログのみ同期
クラウド環境インターネット
認証後はアクセス可能

観光案内所 A
アクセスログインターネット回線（観光案内所のものを利⽤）

認証前はCaptive Portalにリダイレクト

承諾を得た
属性情報を保存
ユーザ情報
アクセス
ログ

Captive
Portalサーバ

Wi-Fiパケット
キャプチャシス
テム（既存）
情報同
アク期
セス
ログ
機構

MACアドレスとユーザ情報のSNS認証 マッピングを更新

ここオンラインサインアップ

Wi-Fi
アクセス
ポイント

⽒名

Twitter

国籍
⼩型PC

認証成功時にWi-Fiプロファイルを配布
以降は直接認証
観光客のデバイス※captive portalとWi-Fiプロファイルでの接続先SSID（ネットワーク）は分ける

性別
MAC

⾃動取得

E-mailPassword

ローカルWeb認証

E-mailPassword

課題：プロファイルへの署名が必要

無線経由のプロファイルの配布と構成
https://developer.apple.com/jp/documentation/iPhoneOTAConfiguration.pdf

Wi-Fiプロファイル利用時の課題• 自動再接続だと変なとこに繋がっててもわからないのでは？
– 認証なしSSID + Captive Portalリダイレクトを残す
限りフィッシングは避けられない– でもCaptive Portalをなくすと承諾プロセスが入れられない
悩ましい．．．

• Wi-Fiプロファイル自体の課題– 後藤英昭, 中村素典, 曽根秀昭「デジタル時代の教育・研究を支える基盤としてのeduroamと次世代ホットスポット」，AXIES年次大会@広島国際会議場（2017年
12月13日（水）〜15日（金））（発表予定）

まとめ• Wi-Fiを用いた人流分析における課題の整理[今後の課題]• 残課題解決への取り組み• 実証実験の実施– どの程度データ収集できるか？
– データ収集できない場合の次の一手は？

ご静聴いただきありがとうございました• 謝辞– 本研究の一部は総務省の「戦略的情報通信研究開発推進事業（SCOPE）」（契約番号：0159-0089）の支援を受けて実施されました。