Capabilityモデルに基づくスマートホームデバイスのネットワークアクセス制御

DICOMO2021 7/2 クラウド・ホスティングセッション 7H-4

Transcript

1. Capabilityモデルに基づく スマートホームデバイスのネットワークアクセス制御 DICOMO2021 7/2 クラウド・ホスティングセッション 7H-4 京都大学 松本 直樹,小谷 大祐,岡部 寿男 1 DICOMO2021 7H-4
2. 本研究の背景 • スマートホームデバイスの普及,デバイス間で直接通信する規格の登場 →悪意のある第三者・デバイスによる攻撃や情報剽窃のリスク • あらゆるデバイスでアクセス制御ができるわけではない → ネットワーク側でのきめ細かいアクセス制御が必要 ホームネットワーク 攻撃 (不正な操作) スマートスピーカ パソコン ヒータ 不適切な通信 (画像取得) IPカメラ 2 DICOMO2021 7H-4
3. 既存研究の問題点 • ホームネットワークにおけるアクセス制御 • OpenFlow などの SDN 技術の活用 • 外部システムと組み合わせたホームネットワークの制御 → 技術的な可能性は示した 問題点:一般家庭におけるアクセス制御の要件を考慮していない • ユーザーが通信の目的を把握できない • ポリシ記述のコスト • 可用性やプライバシの問題 3 DICOMO2021 7H-4
4. 本研究の提案 • 提案1：Capabilityモデルに基づく認可アーキテクチャ • 一般家庭におけるアクセス制御の要件を整理 • ユーザーがデバイスの機能,通信毎に認可(自動認可,手動認可) • 提案2：認可に基づくネットワークアクセス制御 • 認可内容に基づくデバイス間のネットワークアクセス制御 • フロー単位の制御とパケット単位の制御を行う • 認可とアクセス制御を統合することで既存研究の問題を解決 4 DICOMO2021 7H-4
5. 一般家庭におけるアクセス制御の要件 家庭におけるアクセス制御の指針(Mazurek et al., 2010) • 細かい制御が可能であること • デバイスの貸与を考慮すること • Reactive Policy Creation が可能であること • ログを含むこと • 事前設定の複雑さを軽減すること • ポリシの頻繁な書き換えを考慮すること 5 DICOMO2021 7H-4
6. ポリシによるアクセス制御 • 既存のネットワークアクセス制御で用いられる手法 • デバイスの仕様を調べてポリシを記述 • 細かい制御はポリシ記述が困難 DICOMO2021 7H-4 6 デバイスA デバイスB デバイスC アクセス制御装置のポリシ - from : デバイスA to : デバイスB action: allow port : 80/tcp protocol : HTTP URL : /power/on - from : デバイスC to : デバイスA action: allow port : 4000/udp protocol : ProtocolA topic : voice operation : get アクセス 制御装置 80/tcp HTTP 電源操作: /power/on /power/off 4000/udp ProtocolA topic: power(電源操作) operation : {on, off} topic: voice(音声関連) operation : {get} ポリシに基づき アクセス制御
7. Capabilityモデルによるアクセス制御 • 1970 年代からOS等の権限管理で利用されているモデル • 機能を提供する主体が機能ごとにアクセス権限を付与できる → 発行されたトークン(Capability)によってアクセス制御 • 通信仕様を埋め込むことも可能 7 DICOMO2021 7H-4 デバイスA デバイスB デバイスC アクセス 制御装置 - Cap(電源ON) - Cap(電源OFF) - Cap(電源ON) - Cap(電源OFF) - Cap(音声取得) デバイスBのCap(電源ON) - 80/tcp HTTP - /power/on デバイスAのCap(音声取得) - 4000/udp ProtocolA - topic: voice, operation: get デバイスが持つ Capに基づき制御 Capを発行
8. ポリシによる手法との比較 • ポリシによる手法とCapabilityモデルを比較 → 一般家庭ではCapabilityモデルが適している 要件 ポリシ Capabilityモデル 細かい制御 △(少数多種類は苦手) ◦(Cap単位での制御) デバイスの貸与 △ △ Reactive Policy Creation △(モデルの範囲外) ◦ ログ ◦ ◦ 事前設定軽減 ✕(ポリシ記述) ◦(Capの認可,発行のみ) 頻繁な書き換え △(管理の手間) ◦(Capごとの操作) 8 DICOMO2021 7H-4
9. 提案1 Capability モデルに基づく認可アーキテクチャ • ユーザーが Capability ごとに認可を毎回行う作業(手動認可)は大変 → 条件にマッチしたら自動で認可(自動認可)することで負担を軽減 • Capability の委譲を利用し、Capability Provider(CP)が認可を行う Capability Provider ベンダAの ヒータ ベンダAの スマートスピーカ ヒータの温度を取得したい Cap(温度取得) 条件にマッチしたから Cap(温度取得)を認可！ 9 Cap(温度取得)を要求 Capability: 温度取得 Protocol: UDP Port: 8000 Condition: Vendor Allowed Vendor: ベンダA ベンダAのデバイスは 自動で認可 Cap(温度取得) DICOMO2021 7H-4
10. Capability モデルに基づく認可アーキテクチャ • 自動認可をできない場合はユーザーに認可判断を依頼 ベンダAの ヒータ ベンダBの スマートスピーカ Cap(暖房操作) 認可判断できないから ユーザーに判断を任せる 適切な通信だから認可 Cap(暖房操作) Capability Provider 10 Cap(暖房操作)を要求 Capability: 暖房操作 Protocol: UDP Port: 9000 Condition: Manual 自動で認可しない Cap(暖房操作) DICOMO2021 7H-4
11. 提案2 認可に基づくネットワークアクセス制御 • Capabilityに含まれるプロトコル,ポート番号を元にOpenFlowを用いた制御 • 必要に応じてパケット単位での制御を行う • 既存のデバイスにおける機能不足を仮想デバイスで補う OpenFlow 仮想デバイス Cap(温度取得) ベンダAの ヒータ ベンダAの スマートスピーカ ヒータとスマートスピーカ間で 温度取得の通信は許可！ 温度取得の通信 暖房操作の通信 11 DICOMO2021 7H-4 Policy Enforcement Point (PEP)
12. PEPネットワーク • Open vSwitch(OVS) によるフロー単位の制御 → HTTP等の同一ポートで通信を行う場合は不十分 • 仮想デバイスによるペイロードを考慮した制御 • DNSプロキシによる対外通信の制御 • DHCPを利用した仮想デバイスの自動構成 12 DICOMO2021 7H-4
13. 仮想デバイス • 物理デバイスに不足する機能をサポートするソフトウェア • Capability の処理 • ペイロードを解釈しパケット単位で通信の制御 • 物理デバイス側の処理のオフロード 13 DICOMO2021 7H-4
14. フロー単位の制御とパケット単位の制御 ア ク セ ス 制 御 用 O V S スマートスピーカ ヒータ 仮想ヒータ B.パケット転送制御 eth_src: 00:11:22:33:44:55 eth_dst: FF:FF:FF:FF:FF:FF ip_src: 192.168.1.2 Ip_dst: 192.168.1.255 udp_dst: 8000 なパケットはヒータへ転送 A.フロー制御 仮想スマートスピーカ コントローラ MAC Addr: 00:11:22:33:44:55 IPv4 Addr: 192.168.1.2/24 MAC Addr: 00:11:33:44:55:66 IPv4 Addr: 192.168.1.3/24 Capability Cap(近傍探索) Protocol: UDP Port: 8000 Action: Discovery Capability Cap(温度取得) Protocol: UDP Port: 8000 Action: GET Topic: Temperature パケットペイロードを解釈し Action: GET Topic: Temperature ならば転送 14 DICOMO2021 7H-4
15. 検証 • 温湿度計測を行うスマートセンサとアプリを作成し実験 UDP/8000 スマートフォンアプリ 15 温湿度センサ スマートセンサ スマートセンサ スマートフォン アプリ CP,PEP稼働用 ホスト 近傍探索 値の取得 DICOMO2021 7H-4
16. 検証内容 スマートセンサから取得可能な値の種類を制限出来ることを確認 • スマートセンサはCap(近傍探索),Cap(温度取得),Cap(湿度取得)を持つ • Cap(近傍探索)は自動認可,その他は手動認可 16 通信内容を確認して認可 PEP Capability Provider DICOMO2021 7H-4
17. ア ク セ ス 制 御 用 O V S デバイスの接続,自動認可 • デバイスをPEPに接続すると対応する仮想デバイスが起動 • Capability の自動認可が行われる Cap(近傍探索) Cap(温度取得) Cap(湿度取得) Capability Provider Cap(近傍探索) コントローラ 仮想スマートセンサ 仮想スマートフォン Cap(近傍探索)を 自動認可 スマートフォン スマートセンサ 17 DICOMO2021 7H-4 1.DHCPによる アドレス割当 2.仮想デバイス起動 専用DHCPサーバー 3.Capを委譲 192.168.1.1/24 192.168.1.2/24
18. デバイスの接続,自動認可 • Cap(近傍探索)を元にデバイス間のブロードキャスト通信を許可 スマートフォン スマートセンサ ア ク セ ス 制 御 用 O V S コントローラ 仮想スマートセンサ 仮想スマートフォン Cap(近傍探索) 18 DICOMO2021 7H-4 6.適用 7.フロー追加 専用DHCPサーバー ブロードキャストパケットを許可 192.168.1.2/24 192.168.1.1/24
19. 手動認可 • Cap(温度取得)を手動で認可することで値を取得できる スマートフォン スマートセンサ ア ク セ ス 制 御 用 O V S コントローラ 仮想スマートセンサ 仮想スマートフォン 専用DHCPサーバー Capability Provider Cap(温度取得)を 認可 Cap(温度取得) 19 DICOMO2021 7H-4 1.判断の依頼 2.Capを発行 192.168.1.2/24 192.168.1.1/24
20. 手動認可 • 温度取得に関するパケットのみ許可 スマートフォン スマートセンサ ア ク セ ス 制 御 用 O V S コントローラ Cap(温度取得) 仮想スマートセンサ 20 DICOMO2021 7H-4 3.適用 仮想スマートフォン 4.ペイロードをチェック 専用DHCPサーバー opcode == 0 ならば通す { “opcode”:0, //温度取得 “value”:0, // 要求時は0 } 192.168.1.2/24 192.168.1.1/24
21. 手動認可(動画) DICOMO2021 7H-4 21
22. 今後の展望 • 要求されるCapabilityで不自然なものを自動で検出,スコアリング 例: ヒータがIPカメラのCap(画像取得)を要求 • 外部へのユーザー主体なデバイス,資源の利用権限提供 例: 映像データ提供(監視サービス等) 22 監視 サービスB CP,PEP CP,PEP Cap(映像取得) ホームネットワークA ホームネットワークC 監視 サービスA DICOMO2021 7H-4 CP,PEP ホームネットワークB Cap(映像取得)
23. まとめ • 目的:一般家庭におけるスマートホームデバイスの保護 • ネットワーク側で通信を制御しスマートホームデバイスを保護する • 提案1：Capabilityモデルに基づくユーザー主体の認可アーキテクチャ • デバイスの機能単位で通信の許可・拒否を決定する • 提案2：認可に基づくネットワークアクセス制御手法 • 提案1の認可に基づいたフロー,パケット単位のアクセス制御 • 実装,検証：提案1,2のプロトタイプを実装し検証環境で動作することを確認 23 DICOMO2021 7H-4
24. 補足スライド 24
25. Appendix A. 関連研究(ホームネットワークにおけるアクセス制御) デバイスごとにネットワークを分離(Mortier et al., 2012) IoT機器ごとにプロファイルから自動でアクセス制御(Lear et al., 2019) 等 • 利点 • 外部に依拠しない (プライバシ,スケーラビリティの問題がない) • 大規模なシステムを必要としない • 欠点 • 一般ユーザーの技術的知識の欠如 (ACL 等の記述は到底不可能) • 家庭内でのアクセス制御の要件を考慮した提案がなされていない 25
26. 外部のシステムに管理を委託する手法 • 利点 • 複数のホームネットワークを集中管理することで全体としての効率を 改善する • 膨大な情報を利用してデバイスの危険性判断を自動で行いアクセス制 御(Osman, et al., 2020) • 欠点 • プライバシの問題 • スケーラビリティの問題 • ユーザーは外部へ制御を委託することに否定的(Yao, et al., 2019) (ユーザーの望む制御が行われているか分からない) 本研究では外部に依拠しない手法を提案 26 Appendix A. 関連研究(ホームネットワークにおけるアクセス制御) Moyano, et al.,2017
27. Appendix B. 実装 27
28. Appendix B. 実装 DICOMO2021 7H-4 28 CPからユーザーに対する委譲 ユーザーからデバイスに対する発行
29. Appendix B. 実装 DICOMO2021 7H-4 29 無線AP (hostapd) CP PEP デバッグ用
30. Appendix C. デバイス間の直接通信 DICOMO2021 7H-4 30
31. Appendix C. デバイス間の直接通信 DICOMO2021 7H-4 31
32. Appendix D. Capability に対する信頼 • Capability に対する信頼 = Capability の署名の正当性 • Capability Provider は Delegation で署名を行う • 秘密鍵を保持する必要がある • Capability Provider は IoT ハブなどの家庭内に設置されるデバイスで稼働する • どうやって秘密鍵を安全に保持するのか？ • IoT のための PKI によるシステム構築方法の提案(飯田, 2016, CSS 2016) • 署名以外のアプローチ • ICAP における2者間の相互認証・認可(Sivaselvan et al., 2020) • ブロックチェーンを利用した分散型CapBAC(Xu et al., 2018)