• Ingen resultater fundet

Security design

In document Improving Trust in the Wikipedia (Sider 89-93)

State of the Art

5.6 Security design

negative interaction and decreases the X value. Recommendations that are not within the defined interval will not be dealt with. See an example in section 6.4.6.3.

Similar is the adjustment of the N value, that is based on the user is content about the result or not. If the active user gives positive feedback on the recom-mendations that have had a high influence on the mark, the N value is adjusted towards a more optimistic curve and if it is a negative experience then the N value is adjusted towards a more cautious curve.

5.6 Security design

As described in section3.4.3some implementation of security is required in the WRS. In order to prevent the described attacks the ratings have to be secured.

We cannot rely on the Wikipedia to safeguard our ratings. Therefore users have to secure their ratings themselves.

5.6.1 Initialization of Security

In order to set up the WRS with the necessary security features, each user has to have a public and a private key. As described in section2.3.2the WRS does not have a central PKI. Each user creates a public and private key and creates a self signed X.509 certificate.

In order to use the WRS the generated keys will have to be distributed properly.

The private key is used to sign ratings that are put into the articles. It has to be inserted into the proxy and the public key will have to be distributed to the Wikipedia, so other users can verify the rating that the active user had given The public key will have to be available to everyone that need to verify ratings, so storing the public key on the Wikipedia seems a proper solution.

5.6.2 Domain

WRS are designed to work with one single wiki at a time. In this project our focus is on English Wikipedia, mainly because it is the largest and has the most users.

68 Design

Figure 5.5: Distribution of the public and private key

There is, however, also a quite important security aspect to this design choice.

When using the WRS, there has to be an associated user name. There has to be issued as an identifier to the public key. This is used to identify who put the ratings on a page, in order to get different trust value. And in order to identify persons we have to validate identity through their certificates. This certificate have to be stored somewhere where it is public available. In the WRS it is obvious to store this certificate on the user page, and then user the Wikipedia username as identifier that will be associated to the public key.

It would be preferred if we were to be able to use the same certificate and identifier on a different wiki (for instance the Danish wikipedia, or Simple Wi-kipedia). This would enlarge to possible number of trustees, and there by we could get more trustees in our RoR and by that, users would get better and more reliable results. But this opens up to a set of security related problems.

Identity theft. One username does not give access to all wikipedia databases.

A login to the English Wikipedia cannot be used on the Danish Wikipe-dia and vice versa. Two people can register the same username on two different databases. Registering some one else’s username, access to that database is prevented and the user who got his/hers name registered is prevented from obtaining information and submit recommendations on that wiki. This way the system would be prone to a denial of service attack.

Ratings Moving. The name of the article is included in the rating. This introduces a challenge when the same words have different meanings on different languages. For example, the English word ”coin” in French means corner. Naturally the two articles would be totally different. If a users identity covered the all possible wikis then it would be possible to move the

5.7 Summary 69

rating from one article to another, and there would be no way of knowing which one is real.

A solution to this problem could be to use the public key as identifier. This way a public key would be trusted instead of a username and each key could be used on several wikis. This however introduces another set op problems. With this approach all ratings that are put on the Wikipedia would be much larger and take up much more space. A 1024 bit key takes up 128 bytes compared to a 12-14 byte username. Furthermore a user would not be able to revoke his certificate and issue a new because this would lead to a new identity and all trust previously build in that user would be lost.

5.7 Summary

The design chapter describes the internal design of the WRS. We describe how a request from a user, is processed, and the different operations that are per-formed in order to provide the active user with a personalized recommendation.

We describe how the feedback, which the user gives is processed and how it influences the trust management system in the WRS.

This chapter also describes general security measures that have to be taken in order to protect the WRS from being prone to attacks.

70 Design

Chapter 6

Implementation

This chapter concern the implementation of the WRS. This chapter shows that implementation of the proposed system is feasible, within the described require-ments and design. However, the implementation should not be seen as a final product that is ready to be deployed.

In document Improving Trust in the Wikipedia (Sider 89-93)