Difference between revisions of "DistOS-2011W Reputation"

From Soma-notes
Jump to navigation Jump to search
Line 92: Line 92:


==Maintaining History==
==Maintaining History==
Problem domain:
Which history should I maintain? What to take as important, what to disregard?


===Reputation systems===
===Reputation systems===

Revision as of 13:44, 15 March 2011

Members

  • Waheed Ahmed
  • Trevor Gelowsky
    • MSN: Gelowt@gmail.com
    • E-Mail: tgelowsk@sce.carleton.ca
  • Michael Du Plessis
  • Nicolas Lessard

The problem

  • Emerge vs. Impose reputation on the system
  • Where do you store the data?
  • Where is the data queried from?
  • What defines good/bad reputation?

What technologies currently exist?

  • Digital signatures
    • Certificates signed by trusted organizations
  • Black hole- email, spam,
  • Google - search reputation
  • Credit bureaus
  • Yellow pages
  • Better business bureau
  • CRC - criminal records

What technologies don't currently exist?

Guaranteeing Authenticity/Public Key Infrastructure

Introduction

In order to build secure chain of trust Public-Key Infrastructure is used for internet based communication. It consists of various things like security policy , Certificate authority , registration authority , certificate distribution system PKI enabled applications.

Uses and Need

With development of modern e-commerce based businesses which has minimal customer face-to-face interactions is demanding more security and integrity. The online web based stores where huge amount of transactions take place needs to ensure customers that there information is confidential and processed through a secure channel. This is where implementation of PKI steps in to provide mechanisms to ensure trusted relationships are established and maintained. The specific security functions in which a PKI can provide foundation are confidentiality, integrity, non-repudiation,and authentication.

Issues & Solutions

I found out there are many different implementations of PKI , and they all focuses on their own issues and solutions. For example PKI used in DoD have following issues

  • Lack of PKI-enabled eCommerce applications and lack of interoperability among PKI applications
  • DoD is developing a single high assurance PKI
  • Very High Cost Impact to the EC/EB community.
  • The PKI community lacks metrics for mapping of trust models between the DoD :”high assurance” C2 and EC/EB domains
  • Education of everyone (policy maker through user) to a common level of understanding is a huge challenge.
  • While the purpose of using PKI in EC/EB is to provide additional trust to allow the Internet to serve as a vehicle for legally binding transactions , problems still exist with the methodologies associated with establishing a long-term burden of proof. Specifically, there are no widely adopted industry standards for maintenance of electronic signatures or for authenticated timestamps for record maintenance that have stood the test of time. These processes are untried and the case law has not yet been established to convince users that there are no issues with enforcement of these new processes. An additional barrier to EC/EB within this space is the current DoD Certificate policy in which DoD accepts


Common Issues With PKI Implementation

  • Commercial Off-The-Shelf (COTS) versus Customised applications : The choice between COTS or customised products is usually one of cost versus usability. In case of usability the thing to be focused should be error messages. If PKI is built int o applications (transparent to users) than its fine if not than user will require to have some understanding of the use of keys, certificates, Certificate Revocation Lists (CRLs)

and directories/certificate repositories so that they can make informed decisions.

  • Token Logistics (smart card): The point where keys and certificates are linked to their owner is a very critical point in a PKI. If a fraudulent certificate is issued by a registration officer and the certificate holder uses the certificate to commit a crime or prank, trust in the whole PKI hierarchy may be lost. The physical security requirements are high, and the registration officer, whether a person or a smartcard bureau, must be subject to strict security polices and practices. As it was problem with DoD mentioned in section above.
  • Network issues - Traffic : There is no doubt that the implementation of PKI will add to the network load, although just how much depends on the system architecture. Potential additional traffic that should be considered includes: Certificate issuance, Email usage, CRLs , and Directory Replication
  • Network issues - Encryption : Many organisations implement anti-virus software and content inspection on servers at the perimeter of their networks. Some have security policies that rejects or quarantines encrypted traffic. To provide user-to-user confidentiality, messages will traverse networks with their payload hidden from inspection by virus and content checking.
  • Email address in certificate :

Dissemination

Random Ramblings on Reputation Management and Distribution

This system has unique distribution requirements as compared to most distributed systems in general. In this system, we cannot assume that there will be a universally agreed-upon definition of good, or bad. Similarly, the system must be self-policing. It would be up to each and every group of autonomous systems to decide which updates to accept and reject. Updates themselves also should not cause the network to DDoS itself. Lastly, it would be impossible for every system to know what the reputation for a given system is. Therefore the system must disseminate information in some way that is query-able and localizes reputation information where required.

To this end, we need a way of spreading information that while reliable, does not depend on one universally agreed-upon set of reputations.

For example, on an internet-scale operating system it would be entirely reasonable for one group of systems to not want to accept updates, or want to avoid communication with a given series of systems.

Any solution would assume that the problems of attribution are solved.

Current Examples of Reputation Dissemination

The first protocol that immediately comes to mind in this situation is a gossip-based protocol. These protocols are designed to operate in highly decentralized, large-scale systems.

Here's a nice overview:

Examples are as follows:

Another possibility is using "Reputation chains"

Maintaining History

Problem domain: Which history should I maintain? What to take as important, what to disregard?

Reputation systems

  • record, aggregate, distribute information about an entity's behaviour in distributed applications
  • reputation might be based on the entity's past ability to adhere to a license agreement (mutual contract between issuer and licensee)

History-based access control systems

  • make decision based on an entity's past security-sensitive actions

Examples of reputation systems (trust-informing technologies)

  • eBay - Feedback forum (positive, neutral, negative)

Do reputation systems have some validity?

Resnick et al. argue that reputation systems foster an incentive for principals to well-behave because of “the expectation of reciprocity or retaliation in future interactions

Abstractions are used to model the aggregated information of each entity. These abstractions may not encompass the full details of transactions and provide context to specific issues relating to feedback. In turn we can end up with ambiguous values.

So we need a system that provides sufficient information in order to verify the precise properties of a past behaviour.

  • Krukow, K. A Logical Framework for Reputation Systems and History-based Access Control. School of Electronics and Computer Science University of Southampton, UK. (March 3, 2011) [1]

Abstract

Reputation systems are meta systems that record, aggregate and distribute information about principals’ behaviour in distributed applications. Similarly, history-based access control systems make decisions based on programs’ past security-sensitive actions. While the applications are distinct, the two types of systems are fundamentally making decisions based on information about the past behaviour of an entity. A logical policy-centric framework for such behaviour-based decisionmaking is presented. In the framework, principals specify policies which state precise requirements on the past behaviour of other principals that must be fulfilled in order for interaction to take place. The framework consists of a formal model of behaviour, based on event structures; a declarative logical language for specifying properties of past behaviour; and efficient dynamic algorithms for checking whether a particular behaviour satisfies a property from the language. It is shown how the framework can be extended in several ways, most notably to encompass parameterized events and quantification over parameters. In an extended application, it is illustrated how the framework can be applied for dynamic history-based access control for safe execution of unknown and untrusted programs.

  • Khosrow-Pour, M. Emerging trends and challenges in information technology management (March 7, 2011) [2]

Abstract

  • Bolton, G. et al. How Effective are Electronic Reputation Mechanisms? (March 10, 2011) [3]

Abstract

Electronic reputation or “feedback” mechanisms aim to mitigate the moral hazard problems associated with exchange among strangers by providing the type of information available in more traditional close-knit groups, where members are frequently involved in one another’s dealings. In this paper, we compare trading in a market with electronic feedback (as implemented by many Internet markets) to a market without, as well as to a market in which the same people interact with one another repeatedly (partners market). We find that, while the feedback mechanism induces quite a substantial improvement in transaction efficiency, it also exhibits a kind of public goods problem in that, unlike the partners market, the benefits of trust and trustworthy behavior go to the whole community and are not completely internalized. We discuss the implications of this perspective for improving these systems.

Querying Reputation

Since this won't be the actual page the paper is written on, I'm going to dump possibly relevant links here. If they actually get used I'll make them into proper references.

http://www.kirkarts.com/wiki/images/1/13/Resnick_eBay.pdf - Trust Among Strangers in Internet Transactions: Empirical Analysis of eBay’s Reputation System (maybe not too relevant)

http://portal.acm.org/citation.cfm?id=544741.544809 - An Evidential Model of Distributed Reputation Management

http://portal.acm.org/citation.cfm?id=775152.775242&type=series%EF%BF%BD%C3%9C -- The EigenTrust Algorithm for Reputation Management in P2P Networks

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.4.2297&rep=rep1&type=pdf -- A Robust Reputation System for Mobile Ad-hoc Networks

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.125.8729&rep=rep1&type=pdf -- EigenRep: Reputation Management in P2P Networks

http://www.chennaisunday.com/ieee%202010/Reputation%20Estimation%20and%20Query%20in%20Peer-to-Peer%20Networks.pdf -- Reputation Estimation and Query in Peer-to-Peer Networks

Here is another paper that might be interesting for you. -- Lester http://dcg.ethz.ch/publications/netecon06.pdf

Possible implementations

Conclusion

References