Consumo máxima hora (CMH)

stored on it before if OnlyIfPutBefore is set to false. If the malicious nodes collude (SameInvalidContent = true), then all of them respond with the same fake content item; otherwise, each one uses its own fake content item.

A node should only receive a GetValue query if it has previously responded to a GetHash request and is among the node group that is chosen by the group trust value evaluation (with TrustedKad) or the majority decision (without TrustedKad). So the option of re- sponding with “unknown item” is included in Figure 29 for completeness only. Inoffensive nodes respond to a GetValue request by sending the value of the content item. Again, a malicious node always attacks if OnlyIfPutBefore is set to false. If TrustedKad’s conceal- ment of the content item ID is used (OnlyIfPutBefore = true), it can only attack GetValue requests if the item has been stored on it before.

5.6 Trust Information Management

As mentioned above, the trust information is stored centrally in the simulations per- formed for this thesis. The central storage replaces the distributed trust management nodes and the caching of the trust information. The GlobalNodeList class uses the helper classes PeerStorage and PeerInfo: PeerInfo contains the information about one node and PeerStorage contains all PeerInfo objects of all simulated nodes. All three classes have been extended to be able to store trust information. For each node, there is a TrustInfor- mationDetails object that contains four lists which store the positive and negative routing and storage ratings, respectively. This simplifies the calculation of the trust values be- cause only the sizes of the four lists are relevant. If there were only two lists containing routing or storage ratings or even only one list for all routing and storage ratings, these lists would have to be iterated and filtered during every request, which would decrease the performance of the simulation. The lists are implemented as a key-value store (“map”). The node that gives the rating is used as key and the rating is the value. This way, it can be easily ensured that a node can be rated only once by another node. The most recent rating is kept, older ones are discarded.

5.6.1 Storing Trust Information

When a node rates another node, e.g., for routing, it calls the appropriate method of the GlobalNodeList class as shown in Figure 30. The rating is given to the TrustInformationDe-

Figure 30: Flowchart of the rating storage procedure Node A rates node B

Rating type Remove node A’s ratings from positive and negative

storage rating list Rated action Routing GlobalNodeList::rateNode is called Node B’s TrustInformationDetails

object is fetched from PeerStorage

Insert node A’s rating into positive routing rating list

Positive Negative

Rating type

Positive Negative

Storage

Remove node A’s ratings from positive and negative

routing rating list

Insert node A’s rating into negative routing rating list

Insert node A’s rating into positive storage rating list

Insert node A’s rating into negative storage rating list

5 Implementation

5.6 Trust Information Management 77

tails object of the rated node together with the information about which node gives the rating. The TrustInformationDetails object removes any existing rating from the two lists that contains the positive and the negative routing ratings. Afterwards, the new rating is inserted into the correct list.

5.6.2 Retrieving Trust Information

Just as when trust information is stored, the TrustInformationDetails object of a node is fetched from the PeerStorage when its trustworthiness is evaluated. If there is no TrustIn- formationDetails object for the node in question, this node does not exist because such an object is created for each legitimate node when it joins the network; hence, the call evaluates the trustworthiness of a non-existing fake node. Fake nodes do not have valid cached trust information and are therefore discarded. However, as already mentioned in

Figure 31: Flowchart of the rating retrieval procedure Node A evaluates node B

Rated action Routing GlobalNodeList::isNode- Trustworthy is called Node B’s TrustInformationDetails

object is fetched from PeerStorage Node B is trustworthy for routing Unchoke node? Storage Evaluation for Bootstrap? Evaluation for

Bootstrap? Object exists?

Yes No

Node B is not trustworthy for routing Yes

No

Calculate node B’s routing trust value

Value  node A’s routing threshold?

No Unchoke node?

Calculate node B’s storage trust value

Value  node A’s storage threshold?

No

Node B is trustworthy for storage

Node B is not trustworthy for storage Yes Yes Yes No Yes No # ratings £ # grace routing ratings? Yes Yes No # ratings £ # grace storage ratings? No Yes Yes Evaluation for Bootstrap? Worst-case scenario? No No

5 Implementation

78 5.6 Trust Information Management

Section 5.3.1, also a worst-case scenario is evaluated. In this scenario, the fake nodes are regarded as trustworthy except for when the trustworthiness of a potential Bootstrap node is evaluated: The cached trust information of Bootstrap nodes is verified at the trust management nodes, and this check fails if the cached trust information is not valid. In addition, the number of grace routing ratings during Bootstrap operations is set to 0 (as explained in Section 4.10.1).

Figure 31 shows how a node’s trustworthiness is evaluated: If no TrustInformationDetails object exists for the node, it is discarded during evaluations for Lookup and Bootstrap operations in normal scenarios. Only if the worst case is evaluated, the node is regarded as trustworthy for Lookups. The node is still not a Bootstrap candidate node because in a full implementation of TrustedKad, the verification of the cached trust information at the trust management nodes would most probably fail because they do not exist.

If the evaluated peer does exist and the storage trustworthiness is evaluated, the evaluat- ing node first decides whether it unchokes the node; if it does, the trust value is not calcu- lated. Instead, the node is regarded as trustworthy regardless of its trust value. If no un- choking is performed, the total number of storage ratings is checked. If it is below the grace number of storage ratings, the node is regarded as trustworthy (see 𝑇_𝑆,𝑖= 1 𝑖𝑓 𝑅_𝑆,𝑖+ _{+ 𝑅}

𝑆,𝑖− ≤ 𝑔𝑆 in Section 4.6). If the node has enough storage ratings, its

trust value is calculated and compared to the storage trust value threshold. If it is greater than or equal to the threshold, the node is regarded as trustworthy for storage.

Evaluations of the routing trustworthiness work in the same way except for when it is performed to assess a Bootstrap candidate node: If so, unchoking is not performed and the number of grace routing ratings is set to 0. However, if the node that is evaluated has no routing ratings yet (𝑅_𝑅,𝑖+ + 𝑅_𝑅,𝑖− = 0), it is regarded as trustworthy during the simula- tions. This is required, e.g., for the Bootstrap of the second node that joins the network so that it trusts the first node for Bootstrap.

79

6 Evaluation

This chapter presents the results of the simulations that are conducted to analyze Trust- edKad’s effectiveness. First, the general settings of the simulation runs and the technical simulation environment are explained. Afterwards, the comparison indicators that are used to evaluate TrustedKad’s effectiveness are introduced.

The main part of the chapter discusses the simulation results. For comparison, a baseline of a network that does not use TrustedKad is presented first. Then, analyses of configura- tions in which the malicious nodes only attack routing or storage operations follow. At the end of the chapter, a configuration is presented in which TrustedKad counters attacks against both routing and storage.

Different variations of the attacks on routing and storage are used to thoroughly analyze TrustedKad’s features. In addition, parts of TrustedKad’s features are disabled to show their influence on the results.