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