[要約] 要約:RFC 5765は、リアルタイム通信のためのピア・ツー・ピアシステムにおけるセキュリティの問題と解決策について説明しています。 目的:このRFCの目的は、ピア・ツー・ピアシステムにおけるセキュリティの脆弱性を理解し、それに対する解決策を提供することです。

Internet Research Task Force (IRTF)                       H. Schulzrinne
Request for Comments: 5765                           Columbia University
Category: Informational                                       E. Marocco
ISSN: 2070-1721                                           Telecom Italia
                                                                 E. Ivov
                                                        SIP Communicator
                                                           February 2010
        

Security Issues and Solutions in Peer-to-Peer Systems for Realtime Communications

リアルタイムコミュニケーションのためのピアツーピアシステムのセキュリティ問題とソリューション

Abstract

概要

Peer-to-peer (P2P) networks have become popular for certain applications and deployments for a variety of reasons, including fault tolerance, economics, and legal issues. It has therefore become reasonable for resource consuming and typically centralized applications like Voice over IP (VoIP) and, in general, realtime communication to adapt and exploit the benefits of P2P. Such a migration needs to address a new set of P2P-specific security problems. This document describes some of the known issues found in common P2P networks, analyzing the relevance of such issues and the applicability of existing solutions when using P2P architectures for realtime communication. This document is a product of the P2P Research Group.

ピアツーピア(P2P)ネットワークは、フォールトトレランス、経済学、法的問題など、さまざまな理由で特定のアプリケーションと展開に人気があります。したがって、リソースを消費するために合理的になり、Voice over IP(VoIP)や一般的に、P2Pの利点を適応および活用するためのリアルタイム通信など、一般的に集中的にアプリケーションが合理的になりました。このような移行は、P2P固有のセキュリティ問題の新しいセットに対処する必要があります。このドキュメントでは、一般的なP2Pネットワークに見られる既知の問題のいくつかについて説明し、リアルタイム通信のためにP2Pアーキテクチャを使用する場合のこのような問題の関連性と既存のソリューションの適用性を分析します。このドキュメントは、P2P研究グループの製品です。

Status of This Memo

本文書の位置付け

This document is not an Internet Standards Track specification; it is published for informational purposes.

このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。

This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the Peer-to-Peer Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

このドキュメントは、インターネット研究タスクフォース(IRTF)の製品です。IRTFは、インターネット関連の研究開発活動の結果を公開しています。これらの結果は、展開に適していない場合があります。このRFCは、インターネット研究タスクフォース(IRTF)のピアツーピア研究グループのコンセンサスを表しています。IRSGによって公開されたことが承認された文書は、インターネット標準のレベルの候補者ではありません。RFC 5741のセクション2を参照してください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5765.

このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http://www.rfc-editor.org/info/rfc5765で取得できます。

Copyright Notice

著作権表示

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

Copyright(c)2010 IETF Trustおよび文書著者として特定された人。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

このドキュメントは、BCP 78およびIETFドキュメント(http://trustee.ietf.org/license-info)に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。

Table of Contents

目次

   1. Introduction ....................................................4
      1.1. Purpose of This Document ...................................6
      1.2. Structure of This Document .................................7
   2. The Attackers ...................................................8
      2.1. Incentive of the Attacker ..................................8
      2.2. Resources Available to the Attacker ........................9
      2.3. Victim of the Attack ......................................10
      2.4. Time of Attack ............................................10
   3. Admission Control ..............................................10
   4. Determining the Position in the Overlay ........................11
   5. Resilience against Malicious Peers .............................12
      5.1. Identification of Malicious Peers .........................13
           5.1.1. Proactive Identification ...........................13
           5.1.2. Reactive Identification ............................13
      5.2. Reputation Management Systems .............................14
           5.2.1. Unstructured Reputation Management .................14
           5.2.2. Structured Reputation Management ...................14
   6. Routing and Data Integrity .....................................15
      6.1. Data Integrity ............................................15
      6.2. Routing Integrity .........................................15
   7. Peer-to-Peer in Realtime Communication .........................16
      7.1. Peer Promotion ............................................17
           7.1.1. Active vs. Passive Upgrades ........................17
           7.1.2. When to Upgrade ....................................18
           7.1.3. Which Clients to Upgrade ...........................18
           7.1.4. Incentives for Clients .............................19
      7.2. Security ..................................................19
           7.2.1. Targeted Denial of Service .........................19
           7.2.2. Man-in-the-Middle Attack ...........................20
           7.2.3. Trust between Peers ................................20
           7.2.4. Routing Call Signaling .............................20
           7.2.5. Integrity of Location Bindings .....................21
           7.2.6. Encrypting Content .................................21
           7.2.7. Other Issues .......................................22
   8. Open Issues ....................................................22
   9. Security Considerations ........................................23
   10. Acknowledgments ...............................................23
   11. Informative References ........................................23
        
1. Introduction
1. はじめに

Peer-to-peer (P2P) overlays have become quite popular with the advent of file-sharing applications such as Napster [NAPSTER], KaZaa [KAZAA], and BitTorrent [BITTORRENT]. After their success in file-sharing and content distribution [Androutsellis-Theotokis], P2P networks are now also being used for applications such as Voice over IP (VoIP) [SKYPE] [Singh] and television [PPLIVE] [COOLSTREAM]. However, most of these systems are not purely P2P and have centralized components like the login server in Skype [Baset] or moderators and trackers in BitTorrent [Pouwelse]. Securing pure P2P networks is therefore still a field of very active research [Wallach].

ピアツーピア(P2P)オーバーレイは、Napster [Napster]、Kazaa [Kazaa]、Bittorrent [Bittorrent]などのファイル共有アプリケーションの出現に非常に人気があります。ファイル共有とコンテンツの分布[Androuteslelis-Theotokis]で成功した後、P2Pネットワークは現在、Voice Over IP(VoIP)[Skype] [Singh]やTelevision [Pplive] [Coolstream]などのアプリケーションにも使用されています。ただし、これらのシステムのほとんどは純粋にP2Pではなく、Skype [ベース]のログインサーバーやBitTorrent [Pouwelse]のモデレーターとトラッカーなどのコンポーネントを集中しています。したがって、純粋なP2Pネットワークを保護することは、非常に活発な研究の分野です[Wallach]。

P2P overlays can be broadly classified as structured and unstructured [RFC4981], depending on their routing model. Unstructured overlays are often relatively simple, but search operations in them, usually based on flooding, tend to be inefficient. Structured P2P overlays use distributed hash tables (DHTs) [Stoica] [Maymounkov] [Rowstron] to perform directed searches, which make lookups more efficient in locating data. This document will mostly focus on DHT-based P2P overlays.

P2Pオーバーレイは、ルーティングモデルに応じて、構造化および非構造化[RFC4981]として広く分類できます。非構造化されたオーバーレイはしばしば比較的単純ですが、通常は洪水に基づいている検索操作は非効率的である傾向があります。構造化されたP2Pオーバーレイは、分散ハッシュテーブル(DHTS)[Stoica] [Maymounkov] [Rowstron]を使用して、データの検索をより効率的にする方向の検索を実行します。このドキュメントでは、主にDHTベースのP2Pオーバーレイに焦点を当てます。

When analyzing the various attacks that are possible on P2P systems, it is important to first understand the motivation of the attackers as well as the resources (e.g., computation power, access to different IP subnets) that they would have at their disposal.

P2Pシステムで可能なさまざまな攻撃を分析する場合、最初に攻撃者の動機と、リソース(例:計算能力、異なるIPサブネットへのアクセス)を自由に使用することが重要です。

Once the threat has been identified, admission control is a first step towards security that can help avoid a substantial number of attacks [Kim]. Most solutions rely on the assumption that malicious nodes represent a small fraction of all peers. It is therefore important to restrict their number in the overlay.

脅威が特定されると、入学管理は、かなりの数の攻撃を回避するのに役立つセキュリティへの最初のステップです[Kim]。ほとんどのソリューションは、悪意のあるノードがすべてのピアのごく一部を表しているという仮定に依存しています。したがって、オーバーレイに数を制限することが重要です。

Other P2P-specific security problems discussed here include attacks on the routing of queries, targeted denial-of-service attacks, and attacks on data integrity.

ここで議論されるその他のP2P固有のセキュリティ問題には、クエリのルーティングに対する攻撃、ターゲットを絞ったサービス拒否攻撃、およびデータの整合性に対する攻撃が含まれます。

In the remainder of this document, we outline the main security issues and proposed solutions for P2P systems. Following this, we focus on a particular class of P2P applications that provide realtime communications. Realtime communications use the same DHTs used by file-sharing applications; however, the data that is saved in these DHTs is different. In realtime communications, the contents stored in the DHTs comprises user location, the DHT being the substitute for a centralized registration server.

このドキュメントの残りの部分では、主なセキュリティ問題とP2Pシステムのソリューションの提案を概説しました。これに続いて、リアルタイム通信を提供する特定のクラスのP2Pアプリケーションに焦点を当てます。リアルタイム通信は、ファイル共有アプリケーションで使用される同じDHTを使用します。ただし、これらのDHTに保存されているデータは異なります。リアルタイム通信では、DHTSに保存されている内容はユーザーの場所で構成され、DHTは集中登録サーバーの代替品です。

At first glance, it may appear that requirements on peer-to-peer systems for realtime communication services are no different than those for file-sharing services. Table 1 demonstrates that there are sizeable differences related to privacy, availability, and a marked increase in the general security requirements.

一見すると、リアルタイム通信サービスのピアツーピアシステムの要件は、ファイル共有サービスの要件と違いはないように見えるかもしれません。表1は、プライバシー、可用性、および一般的なセキュリティ要件の著しい増加に関連するかなりの違いがあることを示しています。

   +-----------------+-----------------------+-------------------------+
   |                 | File-sharing          | Realtime communication  |
   +-----------------+-----------------------+-------------------------+
   | Distributed     | Shared file locations | User locations are      |
   | database        | are indexed in a      | indexed in a table      |
   |                 | table distributed     | distributed among       |
   |                 | among peers; often    | peers; rarely more than |
   |                 | hundreds or thousands | one per peer.           |
   |                 | per peer.             |                         |
   | Availability    | Same files are        | Users are unique;       |
   |                 | usually available at  | attacks targeting       |
   |                 | multiple locations    | single users may be     |
   |                 | and failures          | addressed both to the   |
   |                 | involving single      | distributed index and   |
   |                 | instances are         | to the user's device    |
   |                 | overcome by abundancy | directly.               |
   |                 | of resources; attacks |                         |
   |                 | targeting single      |                         |
   |                 | files need to be      |                         |
   |                 | addressed to the      |                         |
   |                 | distributed index.    |                         |
   | Integrity       | Attackers may want to | Attackers may want to   |
   |                 | share corrupted files | impersonate different   |
   |                 | in place of popular   | users in order to       |
   |                 | content, e.g., to     | handle calls directed   |
   |                 | discourage users from | to them; constitute a   |
   |                 | acquiring copyrighted | particular threat for   |
   |                 | material; constitute  | the user as, in case of |
   |                 | a threat for the      | success, the attacker   |
   |                 | service, but not for  | acquires full control   |
   |                 | the users.            | on the victim's         |
   |                 |                       | personal                |
   |                 |                       | communications.         |
   | Confidentiality | Shared files are, by  | Communications are      |
   |                 | definition, readable  | usually meant to be     |
   |                 | by all users; in some | private and need to be  |
   |                 | cases, encryption is  | encrypted;              |
   |                 | used to avoid         | eavesdropping may       |
   |                 | elements not involved | reveal sensitive data   |
   |                 | in the service to     | and is a serious threat |
   |                 | detect traffic.       | for users.              |
        
   | Bitrate and     | The file-transfer use | Realtime traffic almost |
   | latency         | case is particularly  | always requires a       |
   |                 | tolerant to unstable  | constant minimum        |
   |                 | bitrates and ability  | bitrate and low latency |
   |                 | to burst on and off   | in order to avoid       |
   |                 | as peers disappear or | problems like jitter.   |
   |                 | new ones become       | While this is not       |
   |                 | available.            | directly related to a   |
   |                 |                       | specific sort of        |
   |                 |                       | attacks, it is a        |
   |                 |                       | significant constraint  |
   |                 |                       | to the design of        |
   |                 |                       | certain design          |
   |                 |                       | solutions, and in       |
   |                 |                       | particular those that   |
   |                 |                       | somehow affect routing. |
   | Peer lifetime   | File-sharing users do | Realtime communication  |
   |                 | not need to stay in   | applications need not   |
   |                 | the overlay more than | leave the overlay for   |
   |                 | the time required for | as long as the user     |
   |                 | downloading the       | wants to stay connected |
   |                 | content they are      | and be reachable.  This |
   |                 | looking for.          | gives the attackers     |
   |                 |                       | longer time for         |
   |                 |                       | conducting successful   |
   |                 |                       | targeted attacks.       |
   +-----------------+-----------------------+-------------------------+
        

Table 1: Main differences between P2P applications used for file-sharing and for realtime communication.

表1:ファイル共有とリアルタイム通信に使用されるP2Pアプリケーションの主な違い。

1.1. Purpose of This Document
1.1. このドキュメントの目的

The goal of this document is to provide authors of P2P protocols for realtime communications with background that they may find useful while designing security mechanisms for specific cases. The document has been extensively discussed during face-to-face meetings and on the P2PRG mailing list; it has been reviewed both substantially and editorially by two members of the research group and reflects the consensus of the group.

このドキュメントの目標は、特定のケースのセキュリティメカニズムを設計する際に有用であると思われるバックグラウンドを持つリアルタイム通信用のP2Pプロトコルの著者を提供することです。この文書は、対面会議およびP2PRGメーリングリストで広く議論されています。研究グループの2人のメンバーによって実質的かつ編集的にレビューされており、グループのコンセンサスを反映しています。

The content of this document was partially derived from the article "Peer-to-peer Overlays for Real-Time Communication: Security Issues and Solutions," published in IEEE Surveys & Tutorials, Vol. 11, No. 1, and originally authored by Dhruv Chopra, Henning Schulzrinne, Enrico Marocco, and Emil Ivov.

このドキュメントの内容は、IEEE Surveys&Tutorials、Vol。11、No。1、そしてもともとDhruv Chopra、Henning Schulzrinne、Enrico Marocco、およびEmil Ivovによって執筆されました。

It is important to note that this document considers "security" from the perspective of application developers and protocol architects. It is hence entirely agnostic to potential legislation issues that may apply when protecting applications against a specific attack, as, for example, in the case of lawful interception.

このドキュメントは、アプリケーション開発者とプロトコルアーキテクトの観点から「セキュリティ」を考慮していることに注意することが重要です。したがって、たとえば、合法的な傍受の場合のように、特定の攻撃から申請を保護するときに適用される可能性のある潜在的な法律の問題に対して完全に不可知論的です。

1.2. Structure of This Document
1.2. このドキュメントの構造

The document is organized as follows. In Section 2, we discuss P2P security attackers. We try to elaborate on their motivation, the resources that would generally be available to them, their victims, and the timing of their attacks. In Section 3, we discuss admission control problems. In Section 4, we identify the problem of where a node joins in the overlay. In Section 5, we describe problems related to identification of malicious nodes and the dissemination of this information. In Section 6, we describe the issues of routing and data integrity in P2P networks. Finally, in Section 7 we discuss how issues and solutions previously presented apply in P2P overlays for realtime communication.

ドキュメントは次のように編成されています。セクション2では、P2Pセキュリティ攻撃者について説明します。私たちは、彼らの動機、彼らが一般的に利用できるリソース、彼らの犠牲者、そして彼らの攻撃のタイミングについて詳しく説明しようとします。セクション3では、入学管理の問題について説明します。セクション4では、ノードがオーバーレイで結合する場所の問題を特定します。セクション5では、悪意のあるノードの識別とこの情報の普及に関連する問題について説明します。セクション6では、P2Pネットワークのルーティングとデータの整合性の問題について説明します。最後に、セクション7では、以前に提示された問題とソリューションが、リアルタイム通信のためにP2Pオーバーレイでどのように適用されるかについて説明します。

Table 2 and Table 3 provide an index of the attacks and the solutions discussed in the rest of this document.

表2と表3は、このドキュメントの残りの部分で説明した攻撃と解決策のインデックスを示します。

   +---------------------------------------+---------------------------+
   | Attack name                           | Referring sections        |
   +---------------------------------------+---------------------------+
   | botnets (use of)                      | Section 2.1, Section 2.2  |
   | denial of service (DoS)               | Section 2.1,              |
   |                                       | Section 7.2.1             |
   | man in the middle (MITM)              | Section 7.2.2             |
   | poisoning                             | Section 6.1,              |
   |                                       | Section 7.2.2             |
   | pollution                             | Section 2.1, Section 6.1  |
   | sybil                                 | Section 2.2, Section 4    |
   | targeted denial of service            | Section 7.2.1             |
   +---------------------------------------+---------------------------+
        

Table 2: Index of some of the more popular attacks and problems discussed in this document.

表2:このドキュメントで議論されているより人気のある攻撃と問題のいくつかのインデックス。

   +---------------------------------------+---------------------------+
   | Solution name                         | Referring sections        |
   +---------------------------------------+---------------------------+
   | admission control                     | Section 3                 |
   | anonymity                             | Section 5.2               |
   | asymmetric key pair                   | Section 7.2.5             |
   | CAPTCHA                               | Section 3                 |
   | certificates                          | Section 7.2.3             |
   | CONNECT (SIP method)                  | Section 7.2.4             |
   | cryptographic puzzles                 | Section 4                 |
   | diametrically opposite IDs            | Section 4                 |
   | end-to-end encryption                 | Section 7.2.4             |
   | group authority                       | Section 3                 |
   | group charter                         | Section 3                 |
   | iterative routing                     | Section 7.2.2             |
   | no profit for newcomers               | Section 5.2               |
   | online phone book                     | Section 7.2.5             |
   | passive upgrades                      | Section 7.1.1             |
   | peer promotion                        | Section 7.1               |
   | proactive identification              | Section 5.1.1             |
   | reactive identification               | Section 5.1.2             |
   | recommendation                        | Section 3                 |
   | reputation management systems         | Section 5.2               |
   | self-policing                         | Section 5.2               |
   | signatures                            | Section 3                 |
   | social networks (using)               | Section 4, Section 6.2,   |
   | SRTP                                  | Section 7.2.6             |
   | structured reputation management      | Section 5.2.2             |
   | SybilGuard (protocol)                 | Section 4                 |
   | transitivity of trust                 | Section 5.2.2             |
   | trust and distrust vectors            | Section 5.2.1             |
   | trust and trusted nodes               | Section 3, Section 6.2,   |
   |                                       | Section 7.2.3             |
   | unstructured reputation management    | Section 5.2.1             |
   | voluntary moderators                  | Section 6.1               |
   +---------------------------------------+---------------------------+
        

Table 3: Index of some of the more popular solutions discussed in this document.

表3:このドキュメントで説明されているより一般的なソリューションのいくつかのインデックス。

2. The Attackers
2. 攻撃者
2.1. Incentive of the Attacker
2.1. 攻撃者のインセンティブ

Attacks on networks happen for a variety of reasons such as monetary gain, personal enmity, or even for fame in the hacker community.

ネットワークへの攻撃は、金銭的利益、個人的な敵意、またはハッカーコミュニティの名声など、さまざまな理由で発生します。

There are quite a few well-known cases of denial-of-service attacks for extortion in the client-server model [McCue]. One of the salient points of the P2P model is that the services it provides have higher robustness against failure. However, denial-of-service attacks are still possible against individuals within the overlay if the attackers possess sufficient resources. For instance, a network of worm-infected malicious nodes spread across the Internet and controlled by an attacker (often referred to as botnet) could simultaneously bombard lookup queries for a particular key in the DHT. The peer responsible for this key would then come under a lot of load and could crash [Sit]. However, with replication of key-value pairs at multiple locations, such threats can be mitigated.

クライアントサーバーモデル[McCue]で恐torのためのサービス拒否攻撃のよく知られているケースがかなりあります。P2Pモデルの顕著なポイントの1つは、それが提供するサービスが障害に対してより高い堅牢性を持つことです。ただし、攻撃者が十分なリソースを持っている場合、オーバーレイ内の個人に対して、サービス拒否攻撃は依然として可能です。たとえば、ワームに感染した悪意のあるノードのネットワークは、インターネット全体に広がり、攻撃者(しばしばボットネットと呼ばれる)によって制御されているネットワークは、DHTの特定のキーの検索クエリを同時に攻撃する可能性があります。このキーを担当するピアは、多くの負荷がかかり、クラッシュする可能性があります。ただし、複数の場所でキー価値ペアを複製すると、そのような脅威を軽減できます。

Attackers may also have other incentives indirectly related to money. With the growth of illegal usage of sharing files with copyrights, record companies have been known to pollute content in the overlays by putting up nodes with corrupt chunks of data but with correct file names to degrade the service [Liang] and in hope that users would get frustrated and stop using it. Similarly, competition between different communication service providers, either or both based on P2P technologies, and the low level of traceability of attacks targeted to single users could be considered as motivation for attempting service disruption.

攻撃者はまた、お金に間接的に関連する他のインセンティブを持っているかもしれません。著作権とファイルを共有するという違法な使用の成長に伴い、レコード会社は、データの腐敗したチャンクを備えているが、サービスを分解するための正しいファイル名でノードを配置することにより、オーバーレイ内のコンテンツを汚染することが知られています[liang]とユーザーがユーザーがそうすることを望んでいますイライラして、それを使用するのをやめてください。同様に、P2Pテクノロジーに基づいたさまざまな通信サービスプロバイダー間の競争、および単一ユーザーを対象とした攻撃のトレーサビリティの低いレベルは、サービスの混乱を試みる動機と見なすことができます。

Attacks can also be launched by novice attackers who are attacking the overlay for fun or fame in a community. These are perhaps less likely to be successful or cause damage, since their resources tend to be relatively limited.

攻撃は、コミュニティの楽しみや名声のためにオーバーレイを攻撃している初心者の攻撃者によっても開始できます。これらのリソースは比較的限られている傾向があるため、これらはおそらく成功したり、損傷を引き起こす可能性が低いでしょう。

2.2. Resources Available to the Attacker
2.2. 攻撃者が利用できるリソース

Resource constraints play an important role in determining the nature of the attack. An attacker who controls a botnet can use an Internet relay channel and launch distributed denial-of-service attacks against another node. With respect to attacks where a single node impersonates multiple identities, as in the case of the Sybil attack [Douceur] described in Section 4, IP addresses are also an important resource for the attacker since in DHTs such as Chord [Stoica], the position in the overlay is determined by using a base hash function such as SHA-1 [SHA1] on the node's IP address. The cryptographic puzzles [Rowaihy] that are sometimes suggested as a way to deter Sybil attacks by making the join process harder are futile against an attacker with a botnet and virtually unlimited computation power. Douceur [Douceur] proves that even with the assumption that attackers only have minimum resources at their disposal, it is not possible to defend against them in a pure P2P system.

リソースの制約は、攻撃の性質を決定する上で重要な役割を果たします。ボットネットを制御する攻撃者は、インターネットリレーチャネルを使用して、分散型のサービス拒否攻撃を別のノードに対して起動できます。セクション4で説明されているシビル攻撃[Douceur]の場合のように、単一のノードが複数のアイデンティティになりすましている攻撃に関して、IPアドレスは、Chord [Stoica]、The PositionなどのDHTSなどの攻撃者にとって重要なリソースでもあります。オーバーレイでは、ノードのIPアドレスでSHA-1 [SHA1]などのベースハッシュ関数を使用することにより決定されます。結合プロセスを難しくすることでシビル攻撃を阻止する方法として提案される暗号化パズル[Rowaihy]は、ボットネットと事実上無制限の計算能力を持つ攻撃者に対して無駄になります。Douceur [Douceur]は、攻撃者が自由に最小限のリソースしか持っていないという仮定があっても、純粋なP2Pシステムでそれらを防御することは不可能であることを証明しています。

2.3. Victim of the Attack
2.3. 攻撃の犠牲者

The victim of an attack could be an individual node, a particular content entry, or the entire overlay service. If malicious nodes are strategically placed in the overlay, they can block a node from using its services. Attacks could also be launched against specific content [Sit] or even the entire overlay service. For example, if the malicious nodes are randomly placed in the overlay and drop packets or upload malicious content, then the quality of the overlay would deteriorate.

攻撃の犠牲者は、個々のノード、特定のコンテンツエントリ、またはオーバーレイサービス全体である可能性があります。悪意のあるノードがオーバーレイに戦略的に配置されている場合、ノードがそのサービスを使用するのをブロックできます。攻撃は、特定のコンテンツ[SIT]またはオーバーレイサービス全体に対しても起動することもできます。たとえば、悪意のあるノードがオーバーレイとドロップパケットにランダムに配置されたり、悪意のあるコンテンツをアップロードしたりすると、オーバーレイの品質が悪化します。

2.4. Time of Attack
2.4. 攻撃の時間

A malicious node could start misbehaving as soon as it enters the overlay or it could follow the rules of the overlay for a finite amount of time and then attack. The latter could prove to be more harmful if the overlay design suggests accumulating trust in peers based on the amount of time they have been present and/or not misbehaving. In Kademlia [Maymounkov], for instance, the routing tables are populated with nodes that have been up for a certain amount of time. While this provides some robustness from attacks in which the malicious nodes start dropping routing requests from the moment they enter, it would take time for the algorithm to adapt to nodes that start misbehaving in a later stage (i.e., after they have been recorded in routing tables). Similarly for reputation management systems, it is important that they adapt to the current behavior of a peer.

悪意のあるノードは、オーバーレイに入るとすぐに不正行為を開始したり、オーバーレイのルールに沿って有限の時間に従ってから攻撃を開始する可能性があります。後者は、オーバーレイの設計が、存在していた時間、または不正行為ではない時間に基づいて、ピアへの信頼を蓄積することを示唆している場合、より有害であることが証明される可能性があります。たとえば、Kademlia [Maymounkov]では、ルーティングテーブルには、一定の時間稼働しているノードが入力されています。これにより、悪意のあるノードが入力した瞬間からルーティングリクエストの削除を開始する攻撃からいくらかの堅牢性が提供されますが、アルゴリズムが後の段階で不正行為を開始するノードに適応するには時間がかかります(つまり、ルーティングで記録された後に表)。同様に、評判管理システムについては、ピアの現在の行動に適応することが重要です。

3. Admission Control
3. 入場管理

Admission control depends on who decides whether or not to admit a node and how this permission is granted. Kim et al. [Kim] answer these questions independently of any particular environment or application. They define two basic elements for admission in a peer group, a group charter, which is an electronic document that specifies the procedure of admission into the overlay, and a group authority, which is an entity that can certify group admission. A prospective member first gets a copy of the group charter, satisfies the requirements, and approaches the group authority. The group authority then verifies the admission request and grants a group membership certificate.

入場管理は、誰がノードを認めるかどうか、この許可がどのように付与されるかを決定するかによって異なります。キムら。[キム]特定の環境やアプリケーションとは無関係にこれらの質問に答えます。彼らは、ピアグループでの入場のための2つの基本要素、グループチャーター、オーバーレイへの入場手順を指定する電子文書、およびグループの入学を証明できるエンティティであるグループ当局を定義します。将来のメンバーが最初にグループチャーターのコピーを取得し、要件を満たし、グループ当局にアプローチします。次に、グループ当局は入学要求を検証し、グループメンバーシップ証明書を付与します。

The group charter and authority verification can be provided by a centralized certificate authority or a trusted third party, or it could be provided by the peers themselves (by voting). The former is more practical and tends to make the certification process simpler although it is in violation of the pure P2P model and exposes the system to attacks typical for server-based solutions (e.g., denial- of-service attacks targeted to the central authority). In the latter case, the group authority could either be a fixed number of peers or it could be a dynamic number based on the total membership of the group. The authors argue that even if the group charter requires a prospective member to get votes from peers, the group membership certificate must be issued by a distinct entity. The reason for this is that voters need to accompany their votes with a certificate that proves their own membership. Possible signature schemes that could be used in voting such as plain digital signature, threshold signature, and accountable subgroup multisignature are also described. Saxena et al. [Saxena] performed experiments with the different signature schemes and suggest the use of plain signatures for groups of moderate size and where bandwidth is not a concern. For larger groups and where bandwidth is a concern, they suggest threshold signature [Kong] and multisignature schemes [Ohta].

グループチャーターおよび当局の検証は、集中型認定当局または信頼できる第三者によって提供されるか、(投票により)仲間自身によって提供される可能性があります。前者はより実用的であり、純粋なP2Pモデルに違反しているが、認証プロセスをより簡単にする傾向があり、システムをサーバーベースのソリューションに典型的な攻撃に公開します(例:中央当局を対象とした拒否のサービス攻撃など)。後者の場合、グループ当局は固定数のピアであるか、グループの合計メンバーシップに基づいて動的な数になる可能性があります。著者は、グループチャーターが将来のメンバーにピアから投票を取得することを要求している場合でも、グループメンバーシップ証明書は明確なエンティティによって発行されなければならないと主張しています。この理由は、有権者が自分のメンバーシップを証明する証明書で投票を伴う必要があるためです。プレーンデジタル署名、しきい値署名、説明責任のサブグループマルチシグネチャなど、投票で使用できる可能性のある署名スキームも説明されています。Saxena et al。[Saxena]は、さまざまな署名スキームを使用して実験を行い、中程度のサイズのグループと帯域幅が懸念事項ではない場合に、単純な署名を使用することを提案しました。より大きなグループおよび帯域幅が懸念される場合、彼らはしきい値の署名[Kong]およびマルチシグネチャスキーム[OHTA]を提案します。

Another way of handling admission would be to use mechanisms based on trust and recommendation where each new applicant has to be known and vouched for by at least N existing members. The difficulties that such models represent include identity assertion and preventing bot/ worm attacks. A compromised node could have a valid certificate identifying a trustworthy peer, and it would be difficult to detect this. Possible solutions include sending graphic or logic puzzles easily addressed by humans but hard to solve by computers, also known as CAPTCHA [Ahn]; however, reliability of such mechanisms is at the time of writing a topic of lively debate [Tam] [Chellapilla].

入場を処理する別の方法は、少なくともn既存のメンバーによってそれぞれの新しい申請者が知られ、保証されなければならない信頼と推奨に基づいてメカニズムを使用することです。そのようなモデルが表す困難には、アイデンティティの主張とボット/ワーム攻撃の防止が含まれます。侵害されたノードは、信頼できるピアを識別する有効な証明書を持つことができ、これを検出することは困難です。可能なソリューションには、人間が簡単に対処するグラフィックパズルまたはロジックパズルの送信が含まれますが、Captcha [ahn]としても知られるコンピューターで解決するのは難しいです。しかし、そのようなメカニズムの信頼性は、活発な議論のトピックを書いている時点であります[Tam] [Chellapilla]。

4. Determining the Position in the Overlay
4. オーバーレイ内の位置を決定します

For ring-based DHT overlays such as Chord [Stoica], Kademlia [Maymounkov], and Pastry [Rowstron], when a node joins the overlay, it uses a numeric identifier (ID) to determine its position in the ring. The positioning of a node determines what information it stores and which nodes it serves. To provide a degree of robustness, content and services are often replicated across multiple nodes. However, it is possible for an adversary with sufficient resources to undermine the redundancy deployed in the overlay by representing multiple identities. Such an attack is called a Sybil attack [Douceur]. This makes the assignment of IDs very important. One possible scheme to tackle such attacks on the ID mapping is to have a temporal mechanism in which nodes need to re-join the network after some time [Condie] [Scheideler]. Such temporal solutions, however, have the drawback that they increase the maintenance traffic and possibly deteriorate the efficiency of caching. Danezis et al. [Danezis] suggest mechanisms to mitigate the effect of Sybil attacks by reducing the amount of information received from malicious nodes. Their idea is to vary the nodes used for routing with time. This helps avoiding trust bottlenecks that may occur when applications only route traffic through a limited set of highly trusted nodes. Other solutions suggest making the joining process harder by introducing cryptographic puzzles as suggested by Rowaihy et al. [Rowaihy]. The assumption is that the adversary has limited computational resources, which may not be true if the adversary has control over a botnet. Another drawback of such methods is that non-malicious nodes would also have to perform the extra computations before they can join the overlay.

コード[Stoica]、Kademlia [Maymounkov]、Pastry [Rowsstron]などのリングベースのDHTオーバーレイの場合、ノードがオーバーレイに結合すると、数値識別子(ID)を使用してリング内の位置を決定します。ノードの位置は、保存する情報と提供するノードを決定します。ある程度の堅牢性を提供するために、コンテンツとサービスは多くの場合、複数のノードで複製されます。ただし、複数のアイデンティティを表すことにより、オーバーレイに展開された冗長性を損なうのに十分なリソースを備えた敵が可能です。このような攻撃は、シビル攻撃[Douceur]と呼ばれます。これにより、IDの割り当てが非常に重要になります。IDマッピングへのそのような攻撃に取り組むための1つの可能なスキームは、しばらくしてからノードがネットワークに再参加する必要がある時間[Condie] [Scheideler]を使用することです。ただし、このような時間的ソリューションには、メンテナンストラフィックが増加し、キャッシュの効率が悪化する可能性があるという欠点があります。Danezis et al。[Danezis]は、悪意のあるノードから受け取った情報の量を減らすことにより、シビル攻撃の効果を軽減するメカニズムを提案します。彼らのアイデアは、時間とともにルーティングに使用されるノードを変更することです。これは、アプリケーションが限られた高度に信頼できるノードのセットを介してトラフィックをルーティングする場合に発生する可能性のある信頼ボトルネックを回避するのに役立ちます。他のソリューションは、Rowaihy et al。[Rowaihy]。仮定は、敵に計算リソースが限られているということです。これは、敵がボットネットを管理している場合は真実ではないかもしれません。このような方法のもう1つの欠点は、非悪質なノードがオーバーレイに参加する前に追加の計算を実行する必要があることです。

A possible heuristic to hamper Sybil attacks is to employ redundancy at nodes with diametrically opposite IDs (in the DHT ID space) instead of successive IDs as in Chord. The idea behind choosing diametrically opposite nodes is based on the fact that a malicious peer can grant admission to others as its successor without them actually possessing the required IP address (whose hash is adjacent to the former's), and then they can cooperate to control access to that part of the ring. If, however, admission decisions and redundant content (for robustness) also involve nodes that are the farthest away (diametrically opposite) from a given position, then the adversary would require double resources (IP addresses) to attack. This happens because the adversary would need presence in the overlay at two independent positions in the ring.

シビル攻撃を妨げる可能性のあるヒューリスティックは、コードのように連続したIDではなく(DHT IDスペース)、IDS(DHT IDスペース)のノードで冗長性を使用することです。直径反対のノードを選択する背後にあるアイデアは、悪意のあるピアが実際に必要なIPアドレス(ハッシュが前者に隣接している)を持たない後継者として他の人に入場を付与できるという事実に基づいています。リングのその部分に。ただし、入学決定と冗長コンテンツ(堅牢性のため)には、特定の位置から最も遠い(正反対の)ノードにも含まれる場合、敵は攻撃に二重リソース(IPアドレス)を必要とします。これは、敵がリング内の2つの独立した位置でオーバーレイに存在する必要があるために起こります。

Another approach proposed by Yu et al. [Yu] to limit Sybil attacks is based on the usage of the social relations between users. The solution exploits the fact that as a result of Sybil attacks, affected P2P overlays end up containing a large set of Sybil nodes connected to the rest of the peers through an irregularly small number of edges. The SybilGuard protocol [Yu] defines a method that allows to discover such kinds of discontinuities in the topology by using a special kind of a verifiable random walk and hence without the need of one node having a global vision of the graph.

Yuらによって提案された別のアプローチ。[Yu]シビル攻撃を制限することは、ユーザー間の社会的関係の使用に基づいています。このソリューションは、シビル攻撃の結果として、影響を受けるP2Pオーバーレイが、不規則に少数のエッジを介して他のピアに接続されたシビルノードの大きなセットが含まれることになるという事実を活用しています。SybilGuardプロトコル[Yu]は、特別な種類の検証可能なランダムウォークを使用して、1つのノードがグラフのグローバルビジョンを持つ必要なく、トポロジのこのような種類の不連続性を発見できる方法を定義します。

It is also worth mentioning that in DHT overlays using different geometric concepts (e.g., hypercubes instead of rings), peer positions are usually not related to identifiers. In the content addressable network (CAN) [Ratnasamy], for example, the position of an entering node may be either selected by the node itself or, with little modification to the original algorithm, assigned by peers already in the overlay. However, even when malicious nodes do not know their position before joining, the overlay is still vulnerable to Sybil attacks.

また、DHTオーバーレイでは、さまざまな幾何学的概念(リングの代わりにハイパーキューブなど)を使用して、ピアポジションは通常識別子とは関係がないことに言及する価値があります。たとえば、コンテンツアドレス可能なネットワーク(can)[ratnasamy]では、入力ノードの位置は、ノード自体によって選択されるか、元のアルゴリズムの変更がほとんどなく、すでにオーバーレイにあるピアによって割り当てられます。ただし、悪意のあるノードが参加する前の位置を知らない場合でも、オーバーレイはシビル攻撃に対して依然として脆弱です。

5. Resilience against Malicious Peers
5. 悪意のある仲間に対する回復力

Making overlays robust against even a small percentage of malicious nodes is difficult [Castro]. It is therefore important for other peers to identify such nodes and keep track of their number. There are two aspects to this problem. One is the identification itself, and the second is the dissemination of this information amongst the peers. Different metrics need to be defined depending on the peer group for the former, and reputation management systems are needed for the latter.

あらゆる割合の悪意のあるノードに対してもオーバーレイを堅牢にすることは困難です[カストロ]。したがって、他のピアがそのようなノードを特定し、その数を追跡することが重要です。この問題には2つの側面があります。1つは識別そのものであり、2つ目はピア間のこの情報の普及です。前者のピアグループに応じて異なるメトリックを定義する必要があり、後者には評判管理システムが必要です。

5.1. Identification of Malicious Peers
5.1. 悪意のある仲間の識別

For identifying a node as malicious, malicious activity has to be observed first. This could be done in either a proactive way or a reactive way.

ノードを悪意のある悪意のあるアクティビティとして識別するには、最初に観察する必要があります。これは、積極的な方法または反応的な方法で実行できます。

5.1.1. Proactive Identification
5.1.1. 積極的な識別

When acting proactively, peers perform periodic operations with the purpose of detecting malicious activity. A malicious node could prevent access to content for which it is responsible (e.g., by claiming the object doesn't exist), or return references to content that does not match the original queries [Sit]. With this approach, publishers of content can later perform lookups for it at periodic intervals and verify the integrity of whatever is returned. Any inconsistencies could then be interpreted as malicious activity. The problem with proactive identification is the management of the overhead it implies: if checks are performed too often, they may actually hinder scalability, while, if they are performed too rarely, they would probably be useless.

積極的に行動するとき、ピアは悪意のある活動を検出する目的で定期的な操作を実行します。悪意のあるノードは、責任のあるコンテンツへのアクセスを防ぐことができます(たとえば、オブジェクトが存在しないと主張することにより)、または元のクエリ[SIT]と一致しないコンテンツへの参照を返すことができます。このアプローチにより、コンテンツの出版社は後で定期的な間隔で検索を実行し、返されるものの完全性を検証できます。矛盾は、悪意のある活動として解釈される可能性があります。積極的な識別の問題は、それが意味するオーバーヘッドの管理です:チェックがあまりにも頻繁に実行される場合、それらは実際にスケーラビリティを妨げる可能性がありますが、それらがあまりにも実行されない場合、それらはおそらく役に立たないでしょう。

An additional approach for mitigating routing attacks and identifying malicious peers consists in sending multiple copies of the same message on different paths. With such an approach, implemented, for example, in Kademlia [Maymounkov], the sending peer can identify anomalies comparing responses coming in from different paths.

ルーティング攻撃を緩和し、悪意のあるピアを特定するための追加のアプローチは、異なるパスで同じメッセージの複数のコピーを送信することにあります。たとえば、Kademlia [Maymounkov]で実装されたこのようなアプローチにより、送信ピアは異なるパスからの応答を比較する異常を特定できます。

5.1.2. Reactive Identification
5.1.2. 反応性識別

In a reactive strategy, the peers perform normal operations and if they happen to detect some malicious activity, then they can label the responsible node as malicious and avoid sending any further message to it. In a file-sharing application, for example, after downloading content from a node, if the peer observes that data does not match its original query it can identify the corresponding node as malicious. Poon et al. [Poon] suggest a strategy based on the forwarding of queries. If routing is done in an iterative way, then dropping of packets, forwarding to an incorrect node, and delay in forwarding arouse suspicion and the corresponding peer is identified as malicious.

リアクティブ戦略では、ピアは通常の操作を実行し、悪意のあるアクティビティを検出した場合、責任あるノードに悪意を持ってラベルを付け、それ以上のメッセージを送信することを避けることができます。たとえば、ファイル共有アプリケーションでは、ノードからコンテンツをダウンロードした後、ピアがデータが元のクエリと一致しないことを観察すると、対応するノードを悪意があると識別できます。Poon et al。[POON]は、クエリの転送に基づいた戦略を提案します。ルーティングが反復的な方法で行われた場合、パケットをドロップし、間違ったノードに転送し、転送の遅延が疑いを引き起こし、対応するピアが悪意があると特定されます。

5.2. Reputation Management Systems
5.2. 評判管理システム

Reputation management systems are used to allow peers to share information about other peers based on their own experience and thus help in making better judgments. Most reputation management systems proposed in the literature for file-sharing applications [Uzun] [Damiani] [Lee] [Kamvar] aim at preventing misbehaving peers with low reputation to rejoin the network with a different ID and therefore start from a clean slate. To achieve this, Lee et al. [Lee] store not only the reputation of a peer but also the reputation of files based on file name and content to avoid spreading of a bad file. Another method is to make the reputation of a new peer the minimum possible. Kamvar et al. [Kamvar] define five design considerations for reputation management systems:

評判管理システムは、ピアが自分の経験に基づいて他の仲間に関する情報を共有できるようにし、より良い判断を下すのに役立ちます。ファイル共有アプリケーションの文献で提案されているほとんどの評判管理システム[uzun] [damiani] [lee] [kamvar]は、評判の低い誤動作を防ぐことを目的としています。これを達成するために、リーら。[Lee]は、ピアの評判だけでなく、ファイル名とコンテンツに基づいたファイルの評判も保存して、悪いファイルの広がりを避けます。別の方法は、新しいピアの評判を最小限にすることです。Kamvar et al。[Kamvar]評判管理システムに関する5つの設計上の考慮事項を定義します。

o The system should be self-policing.

o システムは自己ポリックである必要があります。

o The system should maintain anonymity.

o システムは匿名性を維持する必要があります。

o The system should not assign any profit to newcomers.

o システムは、新人に利益を割り当てるべきではありません。

o The system should have minimal overhead in terms of computation, infrastructure, storage, and message complexity.

o システムは、計算、インフラストラクチャ、ストレージ、メッセージの複雑さに関して最小限のオーバーヘッドを持つ必要があります。

o The system should be robust to malicious collectives of peers who know one another and attempt to collectively subvert the system.

o システムは、お互いを知っていて、システムをまとめて破壊しようとする仲間の悪意のある集団に対して堅牢でなければなりません。

5.2.1. Unstructured Reputation Management
5.2.1. 構造化されていない評判管理

Unstructured reputation management systems have been proposed by Uzun et al. [Uzun] and Damiani et al. [Damiani]. The basic idea of these is that each peer maintains information about its own experience with other peers and resources, and shares it with others on demand. In the system proposed by Uzun et al. [Uzun], each node maintains trust and distrust vectors for every other node with which it has interacted. When reputation information about a peer is required, a node first checks its local database, and if insufficient information is present, it sends a query to its neighbors just as it would when looking up content. However, such an approach requires peers to get reputation information from as many sources as possible; otherwise, malicious nodes may successfully place targeted attacks returning false values for their victims.

構造化されていない評判管理システムは、ウズンらによって提案されています。[ウズン]およびダミアニ等。[ダミアニ]。これらの基本的な考え方は、各ピアが他のピアやリソースとの独自の経験に関する情報を維持し、それを他の人と需要のあるものと共有することです。ウズンらによって提案されたシステムで。[uzun]、各ノードは、相互作用した他のすべてのノードの信頼と不信のベクターを維持します。ピアに関する評判情報が必要な場合、ノードは最初にローカルデータベースをチェックし、情報が不十分な情報が存在する場合、コンテンツを検索するときと同じように隣人にクエリを送信します。ただし、このようなアプローチでは、ピアができるだけ多くのソースから評判情報を取得する必要があります。それ以外の場合、悪意のあるノードは、被害者の誤った値を返すターゲット攻撃を正常に配置する可能性があります。

5.2.2. Structured Reputation Management
5.2.2. 構造化された評判管理

One of the problems with unstructured reputation management systems is that they either take the feedback from few peers or, if they do so from all, then they incur large traffic overhead. Systems such as those proposed by [Lee] [Kamvar] try to resolve it in a structured manner. The idea of the eigen trust algorithm [Kamvar], for example, is transitivity of trust. If a node trusts peer X, then it would also trust the feedback it gives about other peers. A node builds such information in an iterative way; for maintaining it in a structured way, the authors propose to use a content addressable network (CAN) DHT [Ratnasamy]. The information about each peer is stored and replicated on different peers to provide robustness against malicious nodes. They also suggest favoring peers probabilistically with high trust values instead of doing it deterministically, to allow new peers to slowly develop a reputation. Eventually, they suggest the use of incentives for peers with high reputation values.

構造化されていない評判管理システムの問題の1つは、少数のピアからフィードバックを取得するか、すべてからそうする場合、大量のトラフィックオーバーヘッドが発生することです。[Lee] [Kamvar]によって提案されているようなシステムは、構造化された方法でそれを解決しようとします。たとえば、Eigen Trustアルゴリズム[Kamvar]のアイデアは、信頼の推移性です。ノードがピアXを信頼している場合、他のピアについて与えるフィードバックも信頼します。ノードは、そのような情報を反復的な方法で構築します。構造化された方法でそれを維持するために、著者はコンテンツアドレス可能なネットワーク(CAN)DHT [Ratnasamy]を使用することを提案します。各ピアに関する情報は、さまざまなピアに保存および複製され、悪意のあるノードに対して堅牢性を提供します。彼らはまた、新しい仲間がゆっくりと評判を育むことを可能にするために、それを決定的に行うのではなく、高い信頼価値で確率的に仲間を支持することを提案します。最終的に、彼らは高い評判の価値を持つ仲間のためのインセンティブの使用を提案します。

6. Routing and Data Integrity
6. ルーティングとデータの整合性

Preserving integrity of routing and data, or, in other words, preventing peers from returning corrupt responses to queries and routing through malicious peers, is an important security issue in P2P networks. The data stored on a P2P overlay depends on the applications that are using it. For file-sharing, this data would be the files themselves, their location, and owner information. For realtime communication, this would include user location bindings and other routing information. We describe such data integrity issues in Section 7.

ルーティングとデータの整合性を維持するか、言い換えれば、ピアがクエリに対する腐敗した応答や悪意のあるピアを介したルーティングを返すことを防ぐことは、P2Pネットワークの重要なセキュリティ問題です。P2Pオーバーレイに保存されているデータは、それを使用しているアプリケーションによって異なります。ファイル共有の場合、このデータはファイル自体、その場所、および所有者情報です。リアルタイム通信のために、これにはユーザーの場所のバインディングやその他のルーティング情報が含まれます。セクション7のこのようなデータの整合性の問題について説明します。

6.1. Data Integrity
6.1. データの整合性

For file-sharing applications, insertion of wrong content (e.g., files not matching their names or descriptions) and introduction of corrupt data chunks (often referred to as poisoning and pollution) are a significant problem. BitTorrent uses voluntary moderators to weed out bogus files and the SHA-1 algorithm to determine the hash of each piece of a file to allow verification of integrity. If a peer detects a bad chunk, it can download that chunk from another peer. With this strategy, different peers download different pieces of a file before the original peer disappears from the network. However, if a malicious peer modifies the pieces that are only available on it and the original peer disappears, then the object distribution will fail [Zhang]. An analysis of BitTorrent in terms of integrity and performance can be found in the work of Pouwelse et al. [Pouwelse].

ファイル共有アプリケーションの場合、間違ったコンテンツの挿入(たとえば、名前や説明と一致しないファイル)および破損したデータチャンクの導入(多くの場合、中毒および汚染と呼ばれる)は重大な問題です。Bittorrentは、自主的なモデレーターを使用して、偽のファイルとSHA-1アルゴリズムを除去し、ファイルの各部分のハッシュを決定して、完全性の検証を可能にします。ピアが悪いチャンクを検出した場合、別のピアからそのチャンクをダウンロードできます。この戦略により、異なるピアは、元のピアがネットワークから消える前に、ファイルの異なる部分をダウンロードします。ただし、悪意のあるピアがそれでのみ利用可能なピースを変更し、元のピアが消えると、オブジェクト分布が失敗します[Zhang]。完全性とパフォーマンスの観点からのBitTorrentの分析は、Pouwelse et al。[Pouwelse]。

6.2. Routing Integrity
6.2. ルーティングの完全性

To enhance the integrity of routing, it is important to reduce the number of queries forwarded to malicious nodes. Marti et al. [Marti] developed a system that uses social network information to route queries over trusted nodes. Their algorithm uses trusted nodes to forward queries (if one exists and is closer to the required ID in the ID space). Otherwise, they use the regular Chord [Stoica] routing table to forward queries. While their results indicate good average performance, it cannot guarantee log(N) hops for all cases. Danezis et al. [Danezis] suggest a method for routing in the presence of a large number of Sybil nodes. Their method is to ensure that a peer queries a diverse set of nodes and does not place too much trust in a node. Both the above works have been described based on Chord. However, unlike Chord, in DHTs like Pastry [Rowstron] and Kademlia [Maymounkov] there is flexibility in selecting nodes for any row in a peer's routing table. Potentially many nodes have a common ID prefix of a given length and are candidates for routing a given query. To exploit the social network information and still guarantee log(N) hops, a peer should select its friends to route a query, but only when they are present in the appropriate row selected by the DHT algorithm.

ルーティングの整合性を高めるには、悪意のあるノードに転送されるクエリの数を減らすことが重要です。Marti et al。[Marti]は、ソーシャルネットワーク情報を使用して信頼できるノードを介してクエリをルーティングするシステムを開発しました。それらのアルゴリズムは、信頼できるノードを使用してフォワードクエリを使用します(IDスペースの必要なIDに存在し、必要なIDに近い場合)。それ以外の場合は、通常のコード[Stoica]ルーティングテーブルを使用してクエリを転送します。彼らの結果は良好な平均パフォーマンスを示していますが、すべてのケースのログ(n)ホップを保証することはできません。Danezis et al。[Danezis]は、多数のシビルノードの存在下でルーティングする方法を提案します。彼らの方法は、ピアが多様なノードのセットを照会し、ノードにあまり信頼を置かないようにすることです。上記の両方の作品は、コードに基づいて説明されています。ただし、コードとは異なり、ペストリー[Rowstron]やKademlia [Maymounkov]などのDHTでは、ピアのルーティングテーブルの任意の行のノードを選択する柔軟性があります。潜在的に多くのノードには、特定の長さの共通のIDプレフィックスがあり、特定のクエリをルーティングする候補です。ソーシャルネットワーク情報を活用してログ(n)ホップを保証するには、ピアが友人を選択してクエリをルーティングする必要がありますが、DHTアルゴリズムによって選択された適切な行に存在する場合のみです。

7. Peer-to-Peer in Realtime Communication
7. リアルタイムコミュニケーションのピアツーピア

The idea of using P2P in realtime communication essentially implies distributing centralized entities from conventional architectures over P2P overlays and thus reducing the costs of deployment and increasing reliability of the different services. Initiatives such as the P2PSIP working group in IETF [P2PSIP] are currently concentrating on achieving this by using a DHT for services such as registration, location lookup, and support for NAT traversal, which are normally handled by dedicated servers.

リアルタイム通信でP2Pを使用するという考えは、本質的に、P2Pオーバーレイを介して従来のアーキテクチャから集中型エンティティを分配することを意味し、したがって、展開のコストを削減し、さまざまなサービスの信頼性を高めます。IETF [P2PSIP]のP2PSIPワーキンググループなどのイニシアチブは、現在、登録、ロケーションルックアップ、NATトラバーサルのサポートにDHTを使用して、通常専用サーバーによって処理されるNAT Traversalのサポートに集中しています。

Even if based on the same technology, overlays used for realtime communication differ from those used for file-sharing in at least two aspects:

同じテクノロジーに基づいていても、リアルタイム通信に使用されるオーバーレイは、少なくとも2つの側面でファイル共有に使用されるものとは異なります。

o Resource consumption. Contrary to file-sharing systems where the DHT is used to store huge amounts of data (even if the distributed database is used only for storing file locations, each user usually indexes hundreds or thousands of files), realtime communication overlays only require a subset of the resources available at any given time as users only register a limited number of locations (rarely more than one).

o リソース消費。DHTが膨大な量のデータを保存するために使用されるファイル共有システムに反して(分散データベースがファイルの場所の保存にのみ使用されている場合でも、通常、各ユーザーは数百または数千のファイルをインデックスします)、リアルタイム通信オーバーレイにはサブセットのみが必要です。ユーザーが限られた数の場所のみを登録するため、いつでも利用可能なリソースは(めったに複数ではありません)。

o Confidentiality. In file-sharing applications, eavesdropping and identity theft do not constitute real threats; after all, files are supposed to be made publicly available. This is not true in realtime communications, where the privacy and confidentiality of the participants are of paramount importance. Furthermore, the notion of identity plays an important role in realtime communications since it is the basis for starting a communication session. As such, it is essential to have mechanisms to unequivocally assert identities in realtime communication systems.

o 機密性。ファイル共有アプリケーションでは、盗聴と個人情報の盗難は実際の脅威を構成しません。結局のところ、ファイルは公開されることになっています。これは、参加者のプライバシーと機密性が最も重要であるリアルタイムコミュニケーションでは当てはまりません。さらに、アイデンティティの概念は、コミュニケーションセッションを開始するための基礎であるため、リアルタイムコミュニケーションで重要な役割を果たします。そのため、リアルタイム通信システムで明確にアイデンティティを主張するメカニズムを持つことが不可欠です。

In this section we go over the admission issues and security problems discussed in previous sections, and discuss solutions that would be applicable to realtime communication in P2P.

このセクションでは、前のセクションで議論された入場の問題とセキュリティの問題について説明し、P2Pでのリアルタイムコミュニケーションに適用できるソリューションについて説明します。

7.1. Peer Promotion
7.1. ピアプロモーション

In order to remain compatible with existing user agents, P2P communication architectures would have to allow certain nodes to use their services without actually using overlay-specific semantics. One way to achieve this would be for overlay-agnostic nodes to register with an existing peer or a dedicated proxy via a standard protocol like SIP [RFC3261]. Through the rest of this document, we will refer to nodes that access the service without actually joining the overlay as "clients".

既存のユーザーエージェントと互換性を維持するために、P2P通信アーキテクチャは、実際にオーバーレイ固有のセマンティクスを使用せずに特定のノードがサービスを使用できるようにする必要があります。これを達成する1つの方法は、オーバーレイに依存しないノードが、SIP [RFC3261]のような標準プロトコルを介して既存のピアまたは専用のプロキシに登録することです。このドキュメントの残りの部分を通じて、「クライアント」としてオーバーレイを実際に結合せずにサービスにアクセスするノードを参照します。

In most cases, users would be able to benefit from the overlay by only acting as clients. However, in order to keep the solution scalable, at some point clients would have to be promoted to peers (admission to the DHT). This requires addressing the following issues.

ほとんどの場合、ユーザーはクライアントとしてのみ行動することでオーバーレイから利益を得ることができます。ただし、ソリューションをスケーラブルに保つために、ある時点でクライアントをピアに昇格させる必要があります(DHTへの入場)。これには、次の問題に対処する必要があります。

7.1.1. Active vs. Passive Upgrades
7.1.1. アクティブ対パッシブアップグレード

Most existing P2P networks [KAZAA] [BITTORRENT] [PPLIVE] would generally leave it to the clients to determine if and when they would apply for becoming peers. A well-known exception to this trend is the Skype network [SKYPE], arguably one of the most popular overlay networks used for realtime communications today. Instances of the Skype application are supposed to operate as either super-nodes, directly contributing to the distributed provision of the service, or ordinary-nodes, simply using the service, and the "promotions" are decided by the higher levels of the hierarchy [Baset]. Even if there is not much difference for a client whether it has to actively ask for authorization to join an overlay or passively wait for an invitation, the latter approach has some advantages that fit well in overlays where only a subset of the peers is required to provide the service (as in realtime communication):

ほとんどの既存のP2Pネットワーク[kazaa] [bittorrent] [pplive]は、通常、クライアントに任せて、ピアになるために適用するかどうか、いつ応募するかを判断します。この傾向のよく知られた例外は、Skypeネットワーク[Skype]です。これは、おそらく今日のリアルタイム通信に使用されている最も人気のあるオーバーレイネットワークの1つです。Skypeアプリケーションのインスタンスは、スーパーノードとして動作することになっており、サービスの分散提供に直接貢献するか、単にサービスを使用し、「プロモーション」はより高いレベルの階層によって決定されます[プロモーション]は決定されます[ベース]。クライアントに積極的にオーバーレイに参加する許可を求めなければならないか、招待状を受動的に待つ必要があるかどうかにかかわらず、後者のアプローチには、ピアのサブセットだけが必要なオーバーレイに適したいくつかの利点があります。サービスを提供します(リアルタイムコミュニケーションのように):

o An attacker cannot estimate in advance when and if it would be invited to join the overlay as a peer.

o 攻撃者は、ピアとしてオーバーレイに参加するように招待される場合、いつでも事前に見積もることができません。

o It allows peers to perform long-lasting measurements on sets of candidates, in order to accurately select the most appropriate for upgrading and only invite it when they are "ready" to do so. The opposite approach, that is, when clients initiate the join themselves, adds an extra constraint for the peer that has to act upon the request since it doesn't know if and when the peer would attempt to join again.

o これにより、ピアは、アップグレードに最も適したものを正確に選択し、「準備ができている」場合にのみ招待するために、候補者のセットで長期にわたる測定を実行できます。反対のアプローチ、つまり、クライアントが自分で参加を開始すると、ピアが再び参加しようとするかどうか、いつ参加しようとするかがわからないため、リクエストに応じて行動する必要があるピアに追加の制約を追加します。

o It discourages malicious peers from attempting Sybil and, more generally, brute force attacks, as only a small ratio of clients has chances to join the overlay (possibly after an accurate examination).

o 悪意のある仲間がシビルを試みることを思いとどまらせ、より一般的にはブルートフォース攻撃を妨げます。クライアントの比率はわずかであるだけで、オーバーレイに参加する可能性があります(おそらく正確な検査の後)。

7.1.2. When to Upgrade
7.1.2. いつアップグレードするか

In order to answer this question, one would have to define some criteria that would allow determination of the load on a peer and a reasonable threshold. When the load exceeds this threshold, a client is invited to become a peer and share the load. Several mechanisms to diagnose the status of P2P systems have recently been proposed [P2PSIP-DIAG]; in general, reasonable criteria for determining load can be:

この質問に答えるには、ピアの負荷の決定と合理的なしきい値を決定できる基準を定義する必要があります。負荷がこのしきい値を超えると、クライアントはピアになり、負荷を共有するように招待されます。P2Pシステムの状態を診断するためのいくつかのメカニズムが最近提案されました[P2PSIP-DIAG]。一般に、負荷を決定するための合理的な基準は次のとおりです。

o Number of clients attached.

o 添付のクライアントの数。

o Bandwidth usage for DHT maintenance, forwarding requests, and responses to and from peers and from the attached clients.

o DHTメンテナンス、転送要求、およびピアへのと添付クライアントからの対応のための帯域幅の使用。

o Memory usage for DHT routing table, DHT neighborhood table, application-specific data, and information about the attached clients.

o DHTルーティングテーブル、DHT近隣テーブル、アプリケーション固有のデータ、および添付のクライアントに関する情報のメモリ使用量。

7.1.3. Which Clients to Upgrade
7.1.3. アップグレードするクライアント

Selecting which clients to upgrade would require defining and keeping track of new metrics. The exact set of metrics and how they influence decisions should be the subject of serious analysis and experimentation. These could be based on the following observations:

アップグレードするクライアントを選択するには、新しいメトリックを定義して追跡する必要があります。メトリックの正確なセットとそれらが決定にどのように影響するかは、深刻な分析と実験の対象となるはずです。これらは、次の観察に基づいている可能性があります。

o Uptime. A peer could easily record the amount of time that it has been maintaining a connection with a client and take it into account when trying to determine whether or not to upgrade it.

o 稼働時間。ピアは、クライアントとの接続を維持している時間を簡単に記録し、アップグレードするかどうかを判断するときに考慮に入れることができます。

o Level of activity. It is reasonable to assume that the more a client uses the service (e.g., making phone calls), the less they would be willing to degrade it.

o アクティビティレベル。クライアントがサービスを使用するほど(たとえば、電話をかける)、それを劣化させる意思が少なくなると想定するのは合理的です。

o Keeping track of history. Peers could record history of the clients they invite and the way they contribute to the overlay.

o 歴史を追跡します。ピアは、招待するクライアントの歴史とオーバーレイへの貢献方法を記録できます。

Other metrics such as public vs. private IP addresses, computation power, and bandwidth should also be taken into account even though they do not necessarily have a direct impact on security.

パブリックとプライベートのIPアドレス、計算能力、帯域幅などの他のメトリックも考慮する必要があります。

Note however that a set of colluded malicious peers can manufacture basically any criteria considered for the upgrade. Furthermore, sophisticated peers can overload the system or run denial-of-service attacks against existing super-nodes in order to improve their chances of being upgraded.

ただし、一連の共謀された悪意のある仲間は、基本的にアップグレードで考慮されたすべての基準を製造できることに注意してください。さらに、洗練されたピアは、システムに過負荷をかけたり、既存のスーパーノードに対してサービス拒否攻撃を実行して、アップグレードの可能性を向上させることができます。

7.1.4. Incentives for Clients
7.1.4. クライアントのインセンティブ

Clients need to have incentives for accepting upgrades in order to prevent excessive burden on existing peers. One way to handle this would be to maintain separate incentive management through the use of currency or credits. Another option would involve embedding these incentives inside the protocol itself:

クライアントは、既存のピアの過度の負担を防ぐために、アップグレードを受け入れるためのインセンティブを持つ必要があります。これを処理する1つの方法は、通貨またはクレジットを使用して個別のインセンティブ管理を維持することです。別のオプションには、プロトコル自体にこれらのインセンティブを埋め込むことが含まれます。

o Peers share with clients only a fraction of their bandwidth (uplink and downlink). This would result in higher latency when using the services of the overlay as a client and better service quality for peers.

o ピアは、帯域幅のほんの一部(アップリンクとダウンリンク)のみをクライアントと共有します。これにより、オーバーレイのサービスをクライアントとして使用すると、ピアのサービス品質が向上すると、遅延が高くなります。

o Peers could restrict the number or types of calls that they allow clients to make.

o ピアは、クライアントができるようにする電話の数や種類を制限することができます。

Introducing such incentives, however, may turn out to be somewhat risky. Differences in quality would probably be perceptible for end users who would not always be able to understand the difference between the roles that their user agent is playing in the overlay. Such behavior may therefore be interpreted as arbitrary and make the service look unreliable.

ただし、このようなインセンティブを導入することは、やや危険であることが判明する可能性があります。品質の違いは、ユーザーエージェントがオーバーレイで再生している役割の違いを常に理解できるとは限らないエンドユーザーにとって、おそらく知覚可能です。したがって、そのような動作は任意として解釈され、サービスを信頼できないように見せることができます。

7.2. Security
7.2. 安全
7.2.1. Targeted Denial of Service
7.2.1. 対象となるサービスの拒否

In addition to bombardment with queries as described in Section 2, the denial-of-service attack against an individual node can be conducted in DHTs if the peers that surround a particular ID are compromised. These peers that act as proxy servers for the victim can fake the responses from the victim by sending fictitious error messages back to peers trying to establish a session. Danezis et al.'s solution [Danezis] can also provide protection against such attacks, as in their solution peers vary the nodes used in queries.

セクション2で説明されているようにクエリの砲撃に加えて、特定のIDを囲むピアが損なわれている場合、個々のノードに対するサービス拒否攻撃をDHTSで実行できます。被害者のプロキシサーバーとして機能するこれらのピアは、セッションを確立しようとするピアに架空のエラーメッセージを送り返すことで、被害者からの回答を偽造できます。Danezis et al。のソリューション[Danezis]は、そのような攻撃に対する保護を提供することもできます。そのソリューションでは、ピアはクエリで使用されるノードが異なるためです。

7.2.2. Man-in-the-Middle Attack
7.2.2. 中間の攻撃

The man-in-the-middle attack is well described by Seedorf [Seedorf1] in the particular case of P2PSIP [P2PSIP] and consists of an attack that exploits the lack of integrity when routing information. A malicious node could return IP addresses of other malicious nodes when queried for a particular ID. The requesting peer would then establish a session with a second malicious node, which would again return a "poisoned" reply. This could go on until the Time to Live (TTL) expires and the requester gives up the "wild goose chase" [Danezis]. A simple way for entities to verify the correctness of the routing lookup is to employ iterative routing and to check the node-ID of every routing hop that is returned, and it should get closer to the desired ID with every hop. However, this is not a strong check and can be defeated [Seedorf1].

中間の攻撃は、P2PSIP [P2PSIP]の特定のケースでSeedorf [SedeOrf1]によってよく説明されており、情報をルーティングする際の完全性の欠如を活用する攻撃で構成されています。悪意のあるノードは、特定のIDを照会すると、他の悪意のあるノードのIPアドレスを返すことができます。要求するピアは、2番目の悪意のあるノードでセッションを確立し、再び「毒された」返信を返します。これは、生きる時間(TTL)が失効するまで続く可能性があり、リクエスターは「野生のガチョウの追跡」[Danezis]を放棄します。エンティティがルーティングの検索の正確性を確認する簡単な方法は、反復ルーティングを使用し、返されるすべてのルーティングホップのノードIDを確認することです。ただし、これは強力なチェックではなく、敗北する可能性があります[Seedorf1]。

7.2.3. Trust between Peers
7.2.3. 仲間の間で信頼します

The effect of malicious peers could be mitigated by introducing the concept of trust within an overlay. This can be done in different ways:

悪意のある仲間の効果は、オーバーレイ内に信頼の概念を導入することで緩和できます。これはさまざまな方法で実行できます。

o Using certificates assigned by an external authority. The drawback with this approach is that it requires a centralized element.

o 外部当局によって割り当てられた証明書を使用します。このアプローチの欠点は、集中要素が必要であることです。

o Using certificates reciprocally signed by peers. This mechanism is quite similar to PGP [Zimmermann]; every peer signs certificates of "friend" peers and trusts any other peer with a certificate signed by one of its friends. However, even though it might be theoretically possible, in reality it is extremely difficult to obtain long enough trust chains.

o ピアが署名した証明書を使用する。このメカニズムはPGP [Zimmermann]に非常に似ています。すべてのピアは、「友人」のピアの証明書に署名し、他のピアを友人の一人が署名した証明書で信頼しています。しかし、理論的には可能かもしれませんが、実際には、十分に長い信頼チェーンを取得することは非常に困難です。

7.2.4. Routing Call Signaling
7.2.4. ルーティングコールシグナリング

One way for implementing realtime communication overlays (as we have mentioned in earlier sections) would be to simply replace centralized entities in signaling protocols like SIP [RFC3261] with distributed services. In some cases, this might imply reusing existing protocol mechanisms for routing signaling messages. In the case of SIP, this would imply regarding peers as SIP proxies. However, the design of SIP supposes that such proxies are trusted, and makes it possible for them to fork requests or change their destination, add or remove header fields, act as the remote party, and generally manipulate message content and semantics.

リアルタイム通信オーバーレイを実装する1つの方法(以前のセクションで述べたように)は、SIP [RFC3261]などのシグナリングプロトコルで集中型エンティティを分散サービスに置き換えることです。場合によっては、これはシグナリングメッセージをルーティングするための既存のプロトコルメカニズムを再利用することを意味する場合があります。SIPの場合、これはピアがSIPプロキシとしてのことを意味します。ただし、SIPの設計は、そのようなプロキシが信頼されていると想定しており、宛先をフォークするか、目的地を変更したり、ヘッダーフィールドを追加または削除したり、リモートパーティーとして機能したり、一般的にメッセージコンテンツとセマンティクスを操作することを可能にします。

However, in a P2P environment where messages may be routed through numerous successive peers, some of which might be compromised, it is important not to treat them as trusted proxies. One way to limit what peers can do is by protecting signaling with some kind of end-to-end encryption.

ただし、メッセージが多数の連続した仲間を通じてルーティングされる可能性のあるP2P環境では、その一部が妥協される可能性があるため、信頼できるプロキシとして扱わないことが重要です。ピアができることを制限する1つの方法は、何らかのエンドツーエンド暗号化でシグナリングを保護することです。

Another option would be to extend existing signaling protocols and modify the way they route messages in order to guarantee secure end-to-end transmission. Gurbani et al. [Gurbani] define a similar mechanism for SIP that allows nodes to establish a secure channel by sending a CONNECT SIP request, and then tunnel all SIP messages through it, adopting a similar mechanism to the one used for upgrading from HTTP to HTTPS [RFC2818].

別のオプションは、既存のシグナル伝達プロトコルを拡張し、安全なエンドツーエンドの送信を保証するためにメッセージをルーティングする方法を変更することです。Gurbani et al。[Gurbani]接続SIPリクエストを送信してノードが安全なチャネルを確立できるようにするSIPの同様のメカニズムを定義し、HTTPからHTTPS [RFC2818]へのアップグレードに使用されるメカニズムと同様のメカニズムを採用し、それを通してすべてのSIPメッセージをトンネルします[RFC2818]。

7.2.5. Integrity of Location Bindings
7.2.5. ロケーションバインディングの完全性

It is important to ensure that the location that a user registers, usually a (URI, IP) pair, is what is returned to the requesting party. Or the entities that issue the lookup request must be able to verify the integrity of this pair. A pure P2P approach to allow verification of the integrity of location binding information is presented in [Seedorf2]. The idea is for an entity to choose an asymmetric key pair and hash its public key to generate its URI. The entity then signs its present location with its private key and registers with the quadruple (URI, IP, signature, public key). Any entity that looks up the URI and receives such a quadruple can then verify its integrity by using the public key and the certificate. Another possible merit of such an approach could be that it is possible to identify the malicious nodes and maintain a black list. However, the resulting URIs are not easy to remember and associate with entities. Discovering these URIs and associating them with entities would therefore require some sort of a directory service. The authors suggest using existing authentication infrastructure for this such as a certified web service using SSL that can publish an "online phone book" mapping users to URIs.

ユーザーが登録する場所、通常は(URI、IP)ペアが要求者に返される場所であることを確認することが重要です。または、ルックアップリクエストを発行するエンティティは、このペアの整合性を検証できる必要があります。位置結合情報の整合性の検証を可能にする純粋なP2Pアプローチは、[SEDORF2]に示されています。アイデアは、エンティティが非対称キーペアを選択し、その公開キーをハッシュしてURIを生成することです。エンティティは、現在の場所に秘密キーと四重材(URI、IP、署名、公開鍵)を登録します。URIを検索してそのような四角形を受け取るエンティティは、公開キーと証明書を使用してその完全性を検証できます。このようなアプローチのもう1つのメリットは、悪意のあるノードを特定して黒いリストを維持することが可能であることです。ただし、結果のURIは、覚えておくことが容易ではありません。したがって、これらのURIを発見し、エンティティと関連付けるには、ある種のディレクトリサービスが必要です。著者は、「オンライン電話帳」をURISにマッピングする「オンライン電話帳」を公開できるSSLを使用して、認定されたWebサービスなど、既存の認証インフラストラクチャを使用することを提案します。

7.2.6. Encrypting Content
7.2.6. コンテンツの暗号化

Using P2P overlays for realtime communication implies that content is likely to traverse numerous intermediate peers before reaching its destination. A typical example could be the use of peers as media relays as a way of traversing NATs in VoIP calls.

P2Pオーバーレイを使用してリアルタイム通信を使用すると、コンテンツが目的地に到達する前に多数の中間ピアを通過する可能性が高いことを意味します。典型的な例は、VoIP呼び出しでNATを通過する方法として、メディアリレーとしてピアを使用することです。

Contrary to publicly shared files, communication sessions are in most cases expected to be private. It is therefore very important to make sure that no media leaves the client application without being encrypted and securely transported through a protocol like SRTP [RFC3711]. However, the processing required by the encryption algorithms and the extra resources necessary for managing the keying material (e.g., for retrieving public keys when interacting with unknown peers) may be expensive, especially for mobile devices.

公開されたファイルとは反対に、コミュニケーションセッションはほとんどの場合、プライベートであると予想されます。したがって、暗号化されずにクライアントアプリケーションを離れるメディアがSRTP [RFC3711]のようなプロトコルを介して安全に輸送されないことを確認することが非常に重要です。ただし、暗号化アルゴリズムに必要な処理と、キーイング素材の管理に必要な追加リソース(例:未知のピアとの対話時にパブリックキーを取得するために)は、特にモバイルデバイスの場合は高価になる場合があります。

7.2.7. Other Issues
7.2.7. その他の問題

Details on cost and payment regimes could help identify further threats. Such details could also be important when determining the impact of a potential attack in the context of the specific business models associated with particular overlays. In many cases, answers to the following simple questions significantly aid the design of protection mechanisms:

コストと支払い制度の詳細は、さらなる脅威を特定するのに役立ちます。このような詳細は、特定のオーバーレイに関連する特定のビジネスモデルのコンテキストでの潜在的な攻撃の影響を判断する際にも重要です。多くの場合、次の簡単な質問に対する回答は、保護メカニズムの設計を大幅に支援します。

o Whom do the users pay?

o ユーザーは誰を支払いますか?

o Do the users only pay when accessing the public telephone network?

o ユーザーは、公衆電話網にアクセスするときにのみ支払いますか?

o Is the billing done per call or is it fixed?

o 請求は電話ごとに行われていますか、それとも修正されていますか?

For instance, the implications of an attack such as taking control over another's user agent or its identity and using it for outbound calls would depend on whether or not this would be economically advantageous for the attacker. Baumann et al. [Baumann] suggest that to prevent unwanted communication costs, gateways for the public telephone network should only be accessible via authenticated servers and dialing authorizations should be enforced. Also, it seems that it would be difficult to do billing in a pure P2P manner as it would mean keeping the billing details with untrusted peers.

たとえば、他のユーザーエージェントまたはそのアイデンティティを制御したり、アウトバウンドコールにそれを使用するなどの攻撃の意味は、これが攻撃者にとって経済的に有利であるかどうかによって異なります。Baumann et al。[Baumann]は、望ましくない通信コストを防ぐために、公的電話網のゲートウェイに認証されたサーバーを介してのみアクセスできるようにする必要があることを示唆しており、ダイヤル承認を実施する必要があります。また、純粋なP2Pの方法で請求を行うことは困難であるように思われます。

8. Open Issues
8. 未解決の問題

Existing systems used for file-sharing, media streaming, and realtime communications all achieve a reasonable level of security relying on centralized components (e.g., login servers in Skype [Baset], moderators and trackers in BitTorrent [Pouwelse]). Securing pure P2P networks is therefore still a very active research field; at the time of writing the main open issues fall in five areas:

ファイル共有、メディアストリーミング、およびリアルタイムコミュニケーションに使用される既存のシステムはすべて、集中コンポーネント(たとえば、Skype [Baset]のログインサーバー、BitTorrent [Pouwelse]のモデレーター、トラッカー)に依存する合理的なレベルのセキュリティを実現します。したがって、純粋なP2Pネットワークを保護することは、非常に活発な研究分野です。執筆時点で、主なオープンな問題は5つの領域にあります。

o Secure assignment of node IDs.

o ノードIDの安全な割り当て。

o Entity-identity association.

o エンティティアイデンティティ協会。

o Distributed trust among peers.

o 仲間の間で信頼を分配しました。

o Resistance against malicious peer collusion.

o 悪意のあるピア共謀に対する抵抗。

o Robustness and damage recovery.

o 堅牢性と損傷の回復。

In general, P2P overlays are designed to work when the vast majority of their peers are interested in the service provided by the system and act benevolently. Understanding how operations in different overlays are perturbed as the number of malicious or compromised peers grows is another interesting area of research. Also, a widely adopted methodology for the evaluation and classification of security solutions would be likely to help research in the field of P2P security progress more efficiently.

一般に、P2Pオーバーレイは、ピアの大多数がシステムが提供するサービスに関心があり、慈悲深く行動するときに機能するように設計されています。悪意のあるまたは侵害された仲間が増加するにつれて、さまざまなオーバーレイでの運用がどのように混乱するかを理解することは、研究のもう1つの興味深い分野です。また、セキュリティソリューションの評価と分類のために広く採用されている方法論は、P2Pセキュリティの進歩の分野での研究をより効率的に支援する可能性があります。

9. Security Considerations
9. セキュリティに関する考慮事項

This document, tutorial in nature, discusses some of the security issues of P2P systems used for realtime communications. It does not aim at identifying all possible threats and the corresponding solutions; instead, starting from an analysis of the attackers, it delves into some important aspects of P2P security, referencing the most relevant works published at the time of writing and discussing how they apply (or could apply) to the case of realtime communications.

このドキュメントであるチュートリアルは、リアルタイム通信に使用されるP2Pシステムのセキュリティ問題のいくつかについて説明します。それは、可能なすべての脅威と対応するソリューションを特定することを目的としていません。代わりに、攻撃者の分析から始めて、P2Pセキュリティのいくつかの重要な側面を掘り下げ、リアルタイム通信の場合にどのように適用するか(または適用できる)ことを議論する時点で公開された最も関連性の高い作品を参照します。

10. Acknowledgments
10. 謝辞

The authors are particularly grateful to Dhruv Chopra, who contributed to the writing of the article "Peer-to-peer Overlays for Real-Time Communication: Security Issues and Solutions" (IEEE Surveys & Tutorials, Vol. 11, No. 1) from which this work is partially derived.

著者は、Dhruv Chopraに特に感謝しています。DhruvChopraは、「リアルタイムコミュニケーションのためのピアツーピアオーバーレイ:セキュリティの問題とソリューション」(IEEE Surveys&Tutorials、Vol。11、No。1)の記事の執筆に貢献しました。この作業は部分的に導き出されています。

The authors would also like to thank Vijay Gurbani and Song Haibin for reviewing the document and the many others who provided useful comments.

著者はまた、ドキュメントと有用なコメントを提供してくれた他の多くの人々をレビューしてくれたVijay GurbaniとSong Haibinに感謝したいと思います。

11. Informative References
11. 参考引用

[Ahn] Ahn, L., Blum, M., and J. Langford, "Telling humans and computers apart automatically", Communications of the ACM, vol. 47, no. 2, February 2004.

[Ahn] Ahn、L.、Blum、M。、およびJ. Langford、「人間とコンピューターを自動的に伝える」、ACMの通信、Vol。47、いいえ。2、2004年2月。

[Androutsellis-Theotokis] Androutsellis-Theotokis, S. and D. Spinellis, "A survey of peer-to-peer content distribution technologies", ACM CSUR, vol. 36, no. 4, December 2004.

[Androutsellis-Theotokis] Androutsellis-Theotokis、S。およびD. Spinellis、「ピアツーピアコンテンツ配信技術の調査」、ACM CSUR、Vol。36、いいえ。4、2004年12月。

[BITTORRENT] "BitTorrent", <http://www.bittorrent.com/>.

[Bittorrent] "Bittorrent"、<http://www.bittorrent.com/>。

[Baset] Baset, S. and H. Schulzrinne, "An analysis of the skype peer-to-peer internet telephony protocol", Proceedings of IEEE INFOCOM 2006, April 2006.

[Baset] Baset、S。and H. Schulzrinne、「Skype Peer-to-Peerインターネットテレフォニープロトコルの分析」、IEEE Infocom 2006の議事録、2006年4月。

[Baumann] Baumann, R., Cavin, S., and S. Schmid, "Voice Over IP - Security and SPIT", Technical Report, University of Berne, September 2006.

[Baumann] Baumann、R.、Cavin、S。、およびS. Schmid、「Voice over IP -Security and Spit」、テクニカルレポート、ベルン大学、2006年9月。

[COOLSTREAM] "COOLSTREAMING", <http://www.coolstreaming.us>.

[coolstream] "coolstreaming"、<http://www.coolstreaming.us>。

[Castro] Castro, M., Druschel, P., Ganesh, A., Rowstron, A., and D. Wallach, "Secure routing for structured peer-to-peer overlay networks", Proceedings of 5th symposium on Operating systems design and implementation, December 2002.

[カストロ]カストロ、M.、Druschel、P.、Ganesh、A.、Rowstron、A。、およびD. Wallach、「構造化されたピアツーピアオーバーレイネットワークの安全なルーティング」、オペレーティングシステム設計に関する第5回シンポジウムの議事録および実装、2002年12月。

[Chellapilla] Chellapilla, K. and P. Simard, "Using Machine Learning to Break Visual Human Interaction Proofs (HIPs)", Proceedings of Advances in Neural Information Processing Systems, December 2004.

[Chellapilla] Chellapilla、K。およびP. Simard、「機械学習を使用して視覚的な人間の相互作用証明(HIP)を破る」、2004年12月、神経情報処理システムの進歩の議事録。

[Condie] Condie, T., Kacholia, V., Sankararaman, S., Hellerstein, J., and P. Maniatis, "Maelstorm: Churn as Shelter", Proceedings of 13th Annual Network and Distributed System Security Symposium, November 2005.

[Condie] Condie、T.、Kacholia、V.、Sankararaman、S.、Hellerstein、J。、およびP. Maniatis、「Maelstorm:Churn as Shelter」、第13回年次ネットワークおよび分散システムセキュリティシンポジウムの議事録、2005年11月。

[Damiani] Damiani, E., Vimercati, D., Paraboschi, S., Samarati, P., and F. Violante, "A Reputation-Based Approach for Choosing Reliable Resources in Peer-to-Peer Networks", Proceedings of Conference on Computer and Communications Security, November 2002.

[Damiani] Damiani、E.、Vimercati、D.、Paraboschi、S.、Samarati、P。、およびF. Violante、「ピアツーピアネットワークで信頼できるリソースを選択するための評判に基づいたアプローチ」、会議の議事録2002年11月、コンピューターおよび通信セキュリティについて。

[Danezis] Danezis, G., Lesniewski-Laas, C., Kaashoek, M., and R. Anderson, "Sybil-resistant DHT routing", Proceedings of 10th European Symposium on Research in Computer Security, September 2005.

[Danezis] Danezis、G.、Lesniewski-Laas、C.、Kaashoek、M.、およびR. Anderson、「Sybil-Resistant DHT Routing」、2005年9月、コンピューターセキュリティの研究に関する第10回欧州シンポジウムの議事録。

[Douceur] Douceur, J., "The Sybil Attack", Revised Papers from First International Workshop on Peer-to-Peer Systems, March 2002.

[Douceur] Douceur、J。、「シビル攻撃」、2002年3月、ピアツーピアシステムに関する最初の国際ワークショップから論文を改訂しました。

[Gurbani] Gurbani, V., Willis, D., and F. Audet, "Cryptographically Transparent Session Initiation Protocol (SIP) Proxies", Proceedings of IEEE ICC '07, June 2007.

[Gurbani] Gurbani、V.、Willis、D。、およびF. Audet、「暗号化的に透明なセッション開始プロトコル(SIP)プロキシ」、IEEE ICC '07の議事録、2007年6月。

[KAZAA] "KaZaa", <http://www.kazaa.com/>.

[kazaa] "kazaa"、<http://www.kazaa.com/>。

[Kamvar] Kamvar, S., Garcia-Molina, H., and M. Schlosser, "The EigenTrust Algorithm for Reputation Management in P2P Networks", Proceedings of 12th international conference on World Wide Web, May 2003.

[Kamvar] Kamvar、S.、Garcia-Molina、H。、およびM. Schlosser、「P2Pネットワークの評判管理のためのEigentrust Algorithm」、2003年5月、World Wide Webに関する第12回国際会議の議事録。

[Kim] Kim, Y., Mazzocchi, D., and G. Tsudik, "Admission Control in Peer Groups", Proceedings of Second IEEE International Symposium on Network Computing and Applications, April 2003.

[キム]キム、Y。、マッツッチ、D。、およびG.ツディク、「ピアグループの入場管理」、ネットワークコンピューティングとアプリケーションに関する第2回IEEE国際シンポジウムの議事録、2003年4月。

[Kong] Kong, J., Zerfos, P., Luo, H., Lu, S., and L. Zhang, "Providing robust and ubiquitous security support for MANET", Proceedings of 9th International Conference on Network Protocols, November 2001.

[Kong] Kong、J.、Zerfos、P.、Luo、H.、Lu、S。、およびL. Zhang、「Manetに堅牢でユビキタスなセキュリティサポートを提供する」、2001年11月、第9回ネットワークプロトコルに関する第9回国際会議の議事録。

[Lee] Lee, S., Kwon, O., Kim, J., and S. Hong, "A Reputation Management System in Structured Peer-to-Peer Networks", Proceedings of 14th IEEE International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprise, June 2005.

[Lee] Lee、S.、Kwon、O.、Kim、J。、およびS. Hong、「構造化されたピアツーピアネットワークの評判管理システム」、テクノロジーの有効化に関する第14 IEEE国際ワークショップの議事録:インフラストラクチャ共同企業、2005年6月。

[Liang] Liang, J., Kumar, R., Xi, Y., and K. Ross, "Pollution in p2p file sharing systems", Proceedings of IEEE INFOCOM 2005, March 2005.

[Liang] Liang、J.、Kumar、R.、Xi、Y。、およびK. Ross、「P2Pファイル共有システムの汚染」、IEEE Infocom 2005、2005年3月の議事録。

[Marti] Marti, S., Ganesan, P., and H. Garcia-Molina, "SPROUT: P2P Routing with Social Networks", Proceedings of First International Workshop on Peer-to-Peer and Databases, March 2004.

[Marti] Marti、S.、Ganesan、P。、およびH. Garcia-Molina、「Sprout:P2P Routing with Social Networks」、2004年3月、ピアツーピアおよびデータベースに関する第1回の国際ワークショップの議事録。

[Maymounkov] Maymounkov, P. and D. Mazi, "Kademlia: A Peer-to-peer Information System Based on the XOR Metric", Proceedings of First International Workshop on Peer-to-peer Systems, March 2002.

[Maymounkov] Maymounkov、P。and D. Mazi、「Kademlia:XORメトリックに基づくピアツーピア情報システム」、2002年3月、ピアツーピアシステムに関する最初の国際ワークショップの議事録。

[McCue] McCue, Andy., "Bookie reveals 100,000 cost of denial-of-service extortion attacks", available from http://www.silicon.com, June 2004.

[McCue] McCue、Andy。、「Bookieは、2004年6月、http://www.silicon.comから入手可能な、100,000のサービス拒否の恐tor攻撃を明らかにしています」。

[NAPSTER] "Napster", <http://www.napster.com/>.

[Napster] "Napster"、<http://www.napster.com/>。

[Ohta] Ohta, K., Micali, S., and L. Reyzin, "Accountable Subgroup Multisignatures", Proceedings of 8th ACM conference on Computer and Communications Security, November 2001.

[Ohta] Ohta、K.、Micali、S。、およびL. Reyzin、「説明責任のあるサブグループマルチ署名」、2001年11月、コンピューターおよび通信セキュリティに関する第8回ACM会議の議事録。

[P2PSIP] "Peer-to-Peer Session Initiation Protocol (P2PSIP) IETF Working Group", <http://www.ietf.org/html.charters/ p2psip-charter.html>.

[P2PSIP]「ピアツーピアセッション開始プロトコル(P2PSIP)IETFワーキンググループ "、<http://www.ietf.org/html.charters/ p2psip-charter.html>。

[P2PSIP-DIAG] Yongchao, S., Jiang, X., Even, R., and D. Bryan, "P2PSIP Overlay Diagnostics", Work in Progress, December 2009.

[P2PSIP-DIAG] Yongchao、S.、Jiang、X。、Even、R。、およびD. Bryan、「P2PSIPオーバーレイ診断」、2009年12月、進行中の作業。

[PPLIVE] "PPLive", <http://www.pplive.com>.

[pplive] "pplive"、<http://www.pplive.com>。

[Poon] Poon, W. and R. Chang, "Robust Forwarding in Structured Peer-to-Peer Overlay Networks", Proceedings of ACM SIGCOMM 2004, August 2004.

[Poon] Poon、W。およびR. Chang、「構造化されたピアツーピアオーバーレイネットワークにおける堅牢な転送」、ACM Sigcomm 2004、2004年8月の議事録。

[Pouwelse] Pouwelse, J., Garbacki, P., Epema, D., and H. Sips, "The Bittorent P2P File-Sharing System: Measurements and Analysis", Proceedings of 4th International Workshop of Peer-to-peer Systems, February 2005.

[Pouwelse] Pouwelse、J.、Garbacki、P.、Epema、D。、およびH. Sips、「Bittorent P2Pファイル共有システム:測定と分析」、ピアツーピアシステムの第4回国際ワークショップの議事録、2005年2月。

[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

[RFC2818] Rescorla、E。、「TLS上のHTTP」、RFC 2818、2000年5月。

[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.

[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP:SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。

[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.

[RFC3711] Baugher、M.、McGrew、D.、Naslund、M.、Carrara、E。、およびK. Norrman、「The Secure Real-Time Transport Protocol(SRTP)」、RFC 3711、2004年3月。

[RFC4981] Risson, J. and T. Moors, "Survey of Research towards Robust Peer-to-Peer Networks: Search Methods", RFC 4981, September 2007.

[RFC4981] Risson、J。およびT. Moors、「堅牢なピアツーピアネットワークへの研究の調査:検索方法」、RFC 4981、2007年9月。

[Ratnasamy] Ratnasamy, S., Francis, P., Handley, M., Karp, R., and S. Shenker, "A Scalable Content-Addressable Network", Proceedings of ACM SIGCOMM 2001, January 2001.

[Ratnasamy] Ratnasamy、S.、Francis、P.、Handley、M.、Karp、R。、およびS. Shenker、「スケーラブルなコンテンツアドレス可能なネットワーク」、ACM Sigcomm 2001、2001年1月の議事録。

[Rowaihy] Rowaihy, H., Enck, W., McDaniel, P., and T. Porta, "Limiting Sybil attacks in structured peer-to-peer networks", Proceedings of IEEE INFOCOM 2007, May 2007.

[Rowaihy] Rowaihy、H.、Enck、W.、McDaniel、P。、およびT. Porta、「構造化されたピアツーピアネットワークでのシビル攻撃の制限」、IEEE Infocom 2007、2007年5月の議事録。

[Rowstron] Rowstron, A. and P. Druschel, "Pastry: Scalable, distributed object location and routing for large-scale peer-to-peer systems", Proceedings of 18th IFIP/ACM International Conference on Distributed Systems Platforms (Middleware 2001), November 2001.

[Rowstron] Rowstron、A。and P. Druschel、「ペストリー:スケーラブルな分散オブジェクトの位置と大規模なピアツーピアシステムのルーティング」、分散システムプラットフォームに関する第18回IFIP/ACM国際会議の議事録(Middleware 2001)、2001年11月。

[SHA1] 180-1, FIPS., "Secure Hash Standard", April 2005.

[SHA1] 180-1、FIPS。、「Secure Hash Standard」、2005年4月。

[SKYPE] "Skype", <http://www.skype.com/>.

[Skype]「Skype」、<http://www.skype.com/>。

[Saxena] Saxena, N., Tsudik, G., and J. Yi, "Admission Control in Peer-to-Peer: Design and Performance Evaluation", Proceedings of 1st ACM workshop on Security of ad hoc and sensor networks, October 2003.

[Saxena] Saxena、N.、Tsudik、G。、およびJ. Yi、「ピアツーピアの入場管理:設計とパフォーマンス評価」、Ad HocおよびSensor Networksのセキュリティに関する第1 ACMワークショップの議事録、2003年10月。

[Scheideler] Scheideler, C., "How to Spread Adversarial Nodes?: Rotate!", Proceedings of 37th Annual ACM Symposium on Theory of Computing, May 2005.

[Scheideler] Scheideler、C。、「敵対的なノードを広める方法?:Rotate!」、2005年5月、コンピューティング理論に関する第37回年次ACMシンポジウムの議事録。

[Seedorf1] Seedorf, J., "Security Challenges for Peer-to-Peer SIP", IEEE Network, vol. 20, no. 5, September 2006.

[Seedorf1] Seedorf、J。、「ピアツーピアSIPのセキュリティチャレンジ」、IEEE Network、Vol。20、いいえ。5、2006年9月。

[Seedorf2] Seedorf, J., "Using Cryptographically Generated SIP-URIs to Protect the Integrity of Content in P2P-SIP", Proceedings of 3rd Annual VoIP Security Workshop, June 2006.

[Seedorf2] Seedorf、J。、「P2P-SIPのコンテンツの完全性を保護するために暗号化されたSIP-URIを使用して」、2006年6月、第3回VOIPセキュリティワークショップの議事録。

[Singh] Singh, K. and H. Schulzrinne, "Peer-to-Peer Internet Telephony using SIP", Proceedings of International Workshop on Network and Operating System Support for Digital Audio and Video, June 2005.

[Singh] Singh、K。and H. Schulzrinne、「SIPを使用したピアツーピアインターネットテレフォニー」、2005年6月、デジタルオーディオおよびビデオのネットワークおよびオペレーティングシステムサポートに関する国際ワークショップの議事録。

[Sit] Sit, E. and R. Morris, "Security considerations for peer- to-peer distributed hash tables", Revised Papers from First International Workshop on Peer-to-Peer Systems, March 2002.

[Sit] Sit、Sit、E。およびR. Morris、「ピアトゥーピア分散ハッシュテーブルのセキュリティ上の考慮事項」は、2002年3月のピアツーピアシステムに関する最初の国際ワークショップから論文を改訂しました。

[Stoica] Stoica, I., Morris, R., Karger, D., Kaashoek, M., and H. Balakrishnan, "Chord: A Scalable Peer-to-peer Lookup Service for Internet Applications", Proceedings of Applications, Technologies, Architectures, and Protocols for Computer Communication 2001, May 2001.

[Stoica] Stoica、I.、Morris、R.、Karger、D.、Kaashoek、M.、およびH. Balakrishnan、「コード:インターネットアプリケーション向けのスケーラブルなピアツーピアルックアップサービス」、アプリケーション、テクノロジーの議事録、2001年5月、コンピューター通信2001年のアーキテクチャ、およびプロトコル。

[Tam] Tam, J., Simsa, J., Hyde, S., and L. Ahn, "Breaking Audio CAPTCHAs with Machine Learning Techniques", Proceedings of Advances in Neural Information Processing Systems, December 2009.

[Tam] Tam、J.、Simsa、J.、Hyde、S。、およびL. Ahn、「機械学習技術でオーディオキャプチャを壊す」、神経情報処理システムの進歩の進行、2009年12月。

[Uzun] Uzun, E., Pariente, M., and A. Selpk, "A Reputation-Based Trust Management System for P2P Networks", Proceedings of International Symposium on Cluster Computing and the Grids, April 2004.

[Uzun] Uzun、E.、Pariente、M。、およびA. Selpk、「P2Pネットワーク向けの評判に基づいた信頼管理システム」、クラスターコンピューティングとグリッドに関する国際シンポジウムの議事録、2004年4月。

[Wallach] Wallach, D., "A Survey of Peer-to-Peer Security Issues", Proceedings of International Symposium of Software Security 2002, November 2002, <http://www.cs.rice.edu/~dwallach/pub/ tokyo-p2p2002.pdf>.

[Wallach] Wallach、D。、「ピアツーピアセキュリティ問題の調査」、2002年11月、ソフトウェアセキュリティの国際シンポジウムの議事録、<http://www.cs.rice.edu/~dwallach/pub/ Tokyo-P2P2002.pdf>。

[Yu] Yu, H., Kaminsky, M., Gibbons, P., and A. Flaxman, "SybilGuard: Defending Against Sybil Attacks via Social Networks", Proceedings of ACM SIGCOMM 2006, September 2006.

[Yu] Yu、H.、Kaminsky、M.、Gibbons、P。、およびA. Flaxman、「Sybilguard:ソーシャルネットワークを介したSybil攻撃に対する防御」、ACM Sigcomm 2006、2006年9月の議事録。

[Zhang] Zhang, X., Chen, S., and R. Sandhu, "Enhancing Data Authenticity and Integrity in P2P Systems", IEEE Internet Computing, vol. 9, no. 6, September 2005.

[Zhang] Zhang、X.、Chen、S。、およびR. Sandhu、「P2Pシステムにおけるデータの信頼性と完全性の強化」、IEEE Internet Computing、Vol。9、いいえ。6、2005年9月。

[Zimmermann] Zimmermann, Philip., "Pretty good privacy: public key encryption for the masses", Building in big brother: the cryptographic policy debate pag. 103-107, 1995.

[Zimmermann] Zimmermann、Philip。、「かなり良いプライバシー:大衆の公開キー暗号化」、ビッグブラザーの建物:暗号化政策討論PAG。103-107、1995。

Authors' Addresses

著者のアドレス

Henning Schulzrinne Columbia University 1214 Amsterdam Avenue New York, NY 10027 USA

ヘニングシュルツリンコロンビア大学1214アムステルダムアベニューニューヨーク、ニューヨーク10027アメリカ

   EMail: hgs@cs.columbia.edu
        

Enrico Marocco Telecom Italia Via G. Reiss Romoli, 274 Turin 10148 Italy

G. Reiss Romoli経由のEnrico Marocco Telecom Italia、274トリノ10148イタリア

   EMail: enrico.marocco@telecomitalia.it
        

Emil Ivov SIP Communicator / University of Strasbourg 4 rue Blaise Pascal Strasbourg Cedex F-67070 France

エミールIVOV SIPコミュニケーター /ストラスブール大学4 RUE BLAISE PASCAL STRASBOURG CEDEX F-67070フランス

   EMail: emcho@sip-communicator.org