Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

松本直樹
July 02, 2021
110

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

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

松本直樹

July 02, 2021
Tweet

Transcript

  1. 既存研究の問題点 • ホームネットワークにおけるアクセス制御 • OpenFlow などの SDN 技術の活用 • 外部システムと組み合わせたホームネットワークの制御

    → 技術的な可能性は示した 問題点:一般家庭におけるアクセス制御の要件を考慮していない • ユーザーが通信の目的を把握できない • ポリシ記述のコスト • 可用性やプライバシの問題 3 DICOMO2021 7H-4
  2. 本研究の提案 • 提案1:Capabilityモデルに基づく認可アーキテクチャ • 一般家庭におけるアクセス制御の要件を整理 • ユーザーがデバイスの機能,通信毎に認可(自動認可,手動認可) • 提案2:認可に基づくネットワークアクセス制御 •

    認可内容に基づくデバイス間のネットワークアクセス制御 • フロー単位の制御とパケット単位の制御を行う • 認可とアクセス制御を統合することで既存研究の問題を解決 4 DICOMO2021 7H-4
  3. 一般家庭におけるアクセス制御の要件 家庭におけるアクセス制御の指針(Mazurek et al., 2010) • 細かい制御が可能であること • デバイスの貸与を考慮すること •

    Reactive Policy Creation が可能であること • ログを含むこと • 事前設定の複雑さを軽減すること • ポリシの頻繁な書き換えを考慮すること 5 DICOMO2021 7H-4
  4. ポリシによるアクセス制御 • 既存のネットワークアクセス制御で用いられる手法 • デバイスの仕様を調べてポリシを記述 • 細かい制御はポリシ記述が困難 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} ポリシに基づき アクセス制御
  5. 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を発行
  6. ポリシによる手法との比較 • ポリシによる手法とCapabilityモデルを比較 → 一般家庭ではCapabilityモデルが適している 要件 ポリシ Capabilityモデル 細かい制御 △(少数多種類は苦手)

    ◦(Cap単位での制御) デバイスの貸与 △ △ Reactive Policy Creation △(モデルの範囲外) ◦ ログ ◦ ◦ 事前設定軽減 ✕(ポリシ記述) ◦(Capの認可,発行のみ) 頻繁な書き換え △(管理の手間) ◦(Capごとの操作) 8 DICOMO2021 7H-4
  7. 提案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
  8. Capability モデルに基づく認可アーキテクチャ • 自動認可をできない場合はユーザーに認可判断を依頼 ベンダAの ヒータ ベンダBの スマートスピーカ Cap(暖房操作) 認可判断できないから

    ユーザーに判断を任せる 適切な通信だから認可 Cap(暖房操作) Capability Provider 10 Cap(暖房操作)を要求 Capability: 暖房操作 Protocol: UDP Port: 9000 Condition: Manual 自動で認可しない Cap(暖房操作) DICOMO2021 7H-4
  9. 提案2 認可に基づくネットワークアクセス制御 • Capabilityに含まれるプロトコル,ポート番号を元にOpenFlowを用いた制御 • 必要に応じてパケット単位での制御を行う • 既存のデバイスにおける機能不足を仮想デバイスで補う OpenFlow 仮想デバイス

    Cap(温度取得) ベンダAの ヒータ ベンダAの スマートスピーカ ヒータとスマートスピーカ間で 温度取得の通信は許可! 温度取得の通信 暖房操作の通信 11 DICOMO2021 7H-4 Policy Enforcement Point (PEP)
  10. フロー単位の制御とパケット単位の制御 ア ク セ ス 制 御 用 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
  11. ア ク セ ス 制 御 用 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
  12. デバイスの接続,自動認可 • Cap(近傍探索)を元にデバイス間のブロードキャスト通信を許可 スマートフォン スマートセンサ ア ク セ ス 制

    御 用 O V S コントローラ 仮想スマートセンサ 仮想スマートフォン Cap(近傍探索) 18 DICOMO2021 7H-4 6.適用 7.フロー追加 専用DHCPサーバー ブロードキャストパケットを許可 192.168.1.2/24 192.168.1.1/24
  13. 手動認可 • 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
  14. 手動認可 • 温度取得に関するパケットのみ許可 スマートフォン スマートセンサ ア ク セ ス 制

    御 用 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
  15. 今後の展望 • 要求されるCapabilityで不自然なものを自動で検出,スコアリング 例: ヒータがIPカメラのCap(画像取得)を要求 • 外部へのユーザー主体なデバイス,資源の利用権限提供 例: 映像データ提供(監視サービス等) 22

    監視 サービスB CP,PEP CP,PEP Cap(映像取得) ホームネットワークA ホームネットワークC 監視 サービスA DICOMO2021 7H-4 CP,PEP ホームネットワークB Cap(映像取得)
  16. まとめ • 目的:一般家庭におけるスマートホームデバイスの保護 • ネットワーク側で通信を制御しスマートホームデバイスを保護する • 提案1:Capabilityモデルに基づくユーザー主体の認可アーキテクチャ • デバイスの機能単位で通信の許可・拒否を決定する •

    提案2:認可に基づくネットワークアクセス制御手法 • 提案1の認可に基づいたフロー,パケット単位のアクセス制御 • 実装,検証:提案1,2のプロトタイプを実装し検証環境で動作することを確認 23 DICOMO2021 7H-4
  17. Appendix A. 関連研究(ホームネットワークにおけるアクセス制御) デバイスごとにネットワークを分離(Mortier et al., 2012) IoT機器ごとにプロファイルから自動でアクセス制御(Lear et al.,

    2019) 等 • 利点 • 外部に依拠しない (プライバシ,スケーラビリティの問題がない) • 大規模なシステムを必要としない • 欠点 • 一般ユーザーの技術的知識の欠如 (ACL 等の記述は到底不可能) • 家庭内でのアクセス制御の要件を考慮した提案がなされていない 25
  18. 外部のシステムに管理を委託する手法 • 利点 • 複数のホームネットワークを集中管理することで全体としての効率を 改善する • 膨大な情報を利用してデバイスの危険性判断を自動で行いアクセス制 御(Osman, et

    al., 2020) • 欠点 • プライバシの問題 • スケーラビリティの問題 • ユーザーは外部へ制御を委託することに否定的(Yao, et al., 2019) (ユーザーの望む制御が行われているか分からない) 本研究では外部に依拠しない手法を提案 26 Appendix A. 関連研究(ホームネットワークにおけるアクセス制御) Moyano, et al.,2017
  19. 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)