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

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

Transcript

1. Capabilityモデルに基づく
   スマートホームデバイスのネットワークアクセス制御
   DICOMO2021 7/2 クラウド・ホスティングセッション 7H-4
   京都大学
   松本 直樹,小谷 大祐,岡部 寿男
   1
   DICOMO2021 7H-4
   

   View Slide

2. 本研究の背景
   • スマートホームデバイスの普及,デバイス間で直接通信する規格の登場
   →悪意のある第三者・デバイスによる攻撃や情報剽窃のリスク
   • あらゆるデバイスでアクセス制御ができるわけではない
   → ネットワーク側でのきめ細かいアクセス制御が必要
   ホームネットワーク
   攻撃
   (不正な操作)
   スマートスピーカ
   パソコン
   ヒータ
   不適切な通信
   (画像取得)
   IPカメラ
   2
   DICOMO2021 7H-4
   

   View Slide

3. 既存研究の問題点
   • ホームネットワークにおけるアクセス制御
   • OpenFlow などの SDN 技術の活用
   • 外部システムと組み合わせたホームネットワークの制御
   → 技術的な可能性は示した
   問題点:一般家庭におけるアクセス制御の要件を考慮していない
   • ユーザーが通信の目的を把握できない
   • ポリシ記述のコスト
   • 可用性やプライバシの問題
   3
   DICOMO2021 7H-4
   

   View Slide

4. 本研究の提案
   • 提案1：Capabilityモデルに基づく認可アーキテクチャ
   • 一般家庭におけるアクセス制御の要件を整理
   • ユーザーがデバイスの機能,通信毎に認可(自動認可,手動認可)
   • 提案2：認可に基づくネットワークアクセス制御
   • 認可内容に基づくデバイス間のネットワークアクセス制御
   • フロー単位の制御とパケット単位の制御を行う
   • 認可とアクセス制御を統合することで既存研究の問題を解決
   4
   DICOMO2021 7H-4
   

   View Slide

5. 一般家庭におけるアクセス制御の要件
   家庭におけるアクセス制御の指針(Mazurek et al., 2010)
   • 細かい制御が可能であること
   • デバイスの貸与を考慮すること
   • Reactive Policy Creation が可能であること
   • ログを含むこと
   • 事前設定の複雑さを軽減すること
   • ポリシの頻繁な書き換えを考慮すること
   5
   DICOMO2021 7H-4
   

   View Slide

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}
   ポリシに基づき
   アクセス制御
   

   View Slide

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を発行
   

   View Slide

8. ポリシによる手法との比較
   • ポリシによる手法とCapabilityモデルを比較
   → 一般家庭ではCapabilityモデルが適している
   要件 ポリシ Capabilityモデル
   細かい制御 △(少数多種類は苦手) ○(Cap単位での制御)
   デバイスの貸与 △ △
   Reactive Policy Creation △(モデルの範囲外) ○
   ログ ○ ○
   事前設定軽減 ✕(ポリシ記述) ○(Capの認可,発行のみ)
   頻繁な書き換え △(管理の手間) ○(Capごとの操作)
   8
   DICOMO2021 7H-4
   

   View Slide

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
   

   View Slide

10. Capability モデルに基づく認可アーキテクチャ
    • 自動認可をできない場合はユーザーに認可判断を依頼
    ベンダAの
    ヒータ
    ベンダBの
    スマートスピーカ
    Cap(暖房操作)
    認可判断できないから
    ユーザーに判断を任せる
    適切な通信だから認可
    Cap(暖房操作)
    Capability
    Provider
    10
    Cap(暖房操作)を要求
    Capability: 暖房操作
    Protocol: UDP
    Port: 9000
    Condition: Manual
    自動で認可しない
    Cap(暖房操作)
    DICOMO2021 7H-4
    

    View Slide

11. 提案2 認可に基づくネットワークアクセス制御
    • Capabilityに含まれるプロトコル,ポート番号を元にOpenFlowを用いた制御
    • 必要に応じてパケット単位での制御を行う
    • 既存のデバイスにおける機能不足を仮想デバイスで補う
    OpenFlow
    仮想デバイス
    Cap(温度取得)
    ベンダAの
    ヒータ ベンダAの
    スマートスピーカ
    ヒータとスマートスピーカ間で
    温度取得の通信は許可！
    温度取得の通信
    暖房操作の通信
    11
    DICOMO2021 7H-4
    Policy Enforcement Point
    (PEP)
    

    View Slide

12. PEPネットワーク
    • Open vSwitch(OVS) によるフロー単位の制御
    → HTTP等の同一ポートで通信を行う場合は不十分
    • 仮想デバイスによるペイロードを考慮した制御
    • DNSプロキシによる対外通信の制御
    • DHCPを利用した仮想デバイスの自動構成
    12
    DICOMO2021 7H-4
    

    View Slide

13. 仮想デバイス
    • 物理デバイスに不足する機能をサポートするソフトウェア
    • Capability の処理
    • ペイロードを解釈しパケット単位で通信の制御
    • 物理デバイス側の処理のオフロード
    13
    DICOMO2021 7H-4
    

    View Slide

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
    

    View Slide

15. 検証
    • 温湿度計測を行うスマートセンサとアプリを作成し実験
    UDP/8000
    スマートフォンアプリ
    15
    温湿度センサ
    スマートセンサ
    スマートセンサ
    スマートフォン
    アプリ
    CP,PEP稼働用
    ホスト
    近傍探索
    値の取得
    DICOMO2021 7H-4
    

    View Slide

16. 検証内容
    スマートセンサから取得可能な値の種類を制限出来ることを確認
    • スマートセンサはCap(近傍探索),Cap(温度取得),Cap(湿度取得)を持つ
    • Cap(近傍探索)は自動認可,その他は手動認可
    16
    通信内容を確認して認可
    PEP
    Capability
    Provider
    DICOMO2021 7H-4
    

    View Slide

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
    

    View Slide

18. デバイスの接続,自動認可
    • Cap(近傍探索)を元にデバイス間のブロードキャスト通信を許可
    スマートフォン
    スマートセンサ
    ア
    ク
    セ
    ス
    制
    御
    用
    O
    V
    S
    コントローラ
    仮想スマートセンサ
    仮想スマートフォン
    Cap(近傍探索)
    18
    DICOMO2021 7H-4
    6.適用
    7.フロー追加
    専用DHCPサーバー
    ブロードキャストパケットを許可
    192.168.1.2/24
    192.168.1.1/24
    

    View Slide

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
    

    View Slide

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
    

    View Slide

21. 手動認可(動画)
    DICOMO2021 7H-4 21
    

    View Slide

22. 今後の展望
    • 要求されるCapabilityで不自然なものを自動で検出,スコアリング
    例: ヒータがIPカメラのCap(画像取得)を要求
    • 外部へのユーザー主体なデバイス,資源の利用権限提供
    例: 映像データ提供(監視サービス等)
    22
    監視
    サービスB
    CP,PEP CP,PEP
    Cap(映像取得)
    ホームネットワークA ホームネットワークC
    監視
    サービスA
    DICOMO2021 7H-4
    CP,PEP
    ホームネットワークB
    Cap(映像取得)
    

    View Slide

23. まとめ
    • 目的:一般家庭におけるスマートホームデバイスの保護
    • ネットワーク側で通信を制御しスマートホームデバイスを保護する
    • 提案1：Capabilityモデルに基づくユーザー主体の認可アーキテクチャ
    • デバイスの機能単位で通信の許可・拒否を決定する
    • 提案2：認可に基づくネットワークアクセス制御手法
    • 提案1の認可に基づいたフロー,パケット単位のアクセス制御
    • 実装,検証：提案1,2のプロトタイプを実装し検証環境で動作することを確認
    23
    DICOMO2021 7H-4
    

    View Slide

24. 補足スライド
    24
    

    View Slide

25. Appendix A.
    関連研究(ホームネットワークにおけるアクセス制御)
    デバイスごとにネットワークを分離(Mortier et al., 2012)
    IoT機器ごとにプロファイルから自動でアクセス制御(Lear et al., 2019) 等
    • 利点
    • 外部に依拠しない
    (プライバシ,スケーラビリティの問題がない)
    • 大規模なシステムを必要としない
    • 欠点
    • 一般ユーザーの技術的知識の欠如
    (ACL 等の記述は到底不可能)
    • 家庭内でのアクセス制御の要件を考慮した提案がなされていない
    25
    

    View Slide

26. 外部のシステムに管理を委託する手法
    • 利点
    • 複数のホームネットワークを集中管理することで全体としての効率を
    改善する
    • 膨大な情報を利用してデバイスの危険性判断を自動で行いアクセス制
    御(Osman, et al., 2020)
    • 欠点
    • プライバシの問題
    • スケーラビリティの問題
    • ユーザーは外部へ制御を委託することに否定的(Yao, et al., 2019)
    (ユーザーの望む制御が行われているか分からない)
    本研究では外部に依拠しない手法を提案
    26
    Appendix A.
    関連研究(ホームネットワークにおけるアクセス制御)
    Moyano, et al.,2017
    

    View Slide

27. Appendix B. 実装
    27
    

    View Slide

28. Appendix B. 実装
    DICOMO2021 7H-4 28
    CPからユーザーに対する委譲
    ユーザーからデバイスに対する発行
    

    View Slide

29. Appendix B. 実装
    DICOMO2021 7H-4 29
    無線AP
    (hostapd)
    CP
    PEP
    デバッグ用
    

    View Slide

30. Appendix C. デバイス間の直接通信
    DICOMO2021 7H-4 30
    

    View Slide

31. Appendix C. デバイス間の直接通信
    DICOMO2021 7H-4 31
    

    View Slide

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)
    

    View Slide