参考にできそうなもの


タイトル

  • 暗号化された通信内容を検査可能な
      アプリケーションレベルファイアウォールの仮想化技術を用いた実装


序論

  • 背景
    • 近年、多くの人々が複雑なアプリケーションを身近に利用している。そのようなアプリケーションは、しばしばインターネットと通信する。アプリケーションが行う通信内容とその通信先を検証し、利用者が意図しない通信を防ぎたいという要求がある。例えば、あるアプリケーションが開発元に統計情報を送信しているとき、その通信内容に事前の許可なく個人情報が含まれてないか確認したい場合や、他のホストとは通信させたくない場合が考えられる。そのような場合、Little Snitch[1] のようなアプリケーションレベルでのファイアウォールを使うことが有効である。
  • 問題点
    • 従来のアプリケーションレベル・ファイアウォールの実装は比較的容易であるが、TLS 等を用いて暗号化された通信は内容の検証が困難であるという問題がある。
  • 目的
    • 本研究の目的は、暗号通信含め、利用者が予期しないような通信が発生していないか確認および検査できるようにすることである。この目的を達成するため、本研究では

関連研究（提案手法と入れ替わるかも）

  • 相違点があるなら提案手法の後に入れる
  • （相違点）
  • 他の研究の brief explanation と citing
  • 当研究の brief explanation
  • https://doaj.org/article/9efef5c7e7ee4a339de3f289c847a16d
  • https://link.springer.com/chapter/10.1007/978-3-031-06975-8_6
    • https://arxiv.org/pdf/2104.09828.pdf
    • 事前に選んだホストと利用者のマシンの間で SSL 通信が発生した際に、ネットワーク内の通信をパッシブに監視する Zeek NSM（Network Security Monitor）に対し、その際の共通鍵を利用者のマシンから送信することで NSM で通信内容の復号および解析をするための仕組みが実装されている。
      • 類似点
        • MitM（Man-in-the-Middle）プロキシの仕組みを持たないため、利用者のマシンで MitM プロキシの CA 証明書を信頼するなどの事前準備が不要
      • 相違点
        • NSM は IDS（Instrusion Detection System）としてパッシブに機能するため、利用者が通信内容に基づいて対話的に通信を遮断するための機能は備えておらず、そのような通信は素通しされる。

提案手法

  • やること
    • eBPF で network interface 監視
    • 図を貼る

結論

  • 当提案手法の brief explanation
  • 現状
  • 今後の展望

参考文献

  • Alphakai さんの論文
  • Alphakai さんの論文が参照している論文があればそれを読んでよさげなら cite
    • 孫引きしないように気をつける
  • eng-b にある論文でよさげなやつ


レビュー結果: 2023-10-13@interim-review-memo