Soma-notes - User contributions [en]

Distributed OS: Winter 2011 Reputation Systems Paper

2011-04-12T03:21:03Z

Tgelowsk:

=What is reputation?=

In the real world, people are generally quite conscious of certain behavioural actions that make. These actions are expected to fall within the social norms and are scrutinized continuously by the people around us. On a daily basis, Individuals build a personal set of judgment values and opinions on others in the society. When we listen to a politician on the news, or interact with a friends, we are updating this image that we have of the individual or group. It is this image we generate that helps us make conclusions as to whether we like the individual, whether we trust the individual, or whether we can relate to the individual. The global opinions that others have on us is known as reputation.

A reputation system's main purpose is to facilitate in providing a means for assumptions to be made about the level of trust one can have for a particular person or situation in executing a task to our liking. It is important to note the importance of the word assumption. With the gathered information, we are able to generate an estimate of their actions. It is by no means accurate. Furthermore, reputation is not a globally accepted view of an entity. In some cases, an individuals reputation can be quite varied between different observers. Some may have encountered contact with the entity in a different context or had a different level of expectation compared to others <ref name="krukow" />. Likewise, some individuals might be falsely persuaded to confirm to specific opinions by large and powerful groups, whereas others have a crystallized and hard-to-change opinion.

=How can reputation be used in a distributed environment?=

Reputation can be useful in acquiring an understanding of how congruent one's own goals are from another. If we are to accomplish a desired task that requires the cooperation of others, we carefully analyze whether the individuals we choose will be a good fit or whether they will hinder our progress. Or, worse yet, halt our progress completely.

In a more technical and distributed view, reputation is the process of recording, aggregating, and distributing information about an entity's behaviour in distributed applications. Reputation might be based on the entity's past ability to adhere to a mutual contract with another entity <ref name="krukow">Krukow K. et al. A Logical Framework for Reputation Systems and History-based Access Control. School of Electronics and Computer Science University of Southampton, UK [March 3, 2011]</ref>. As stated above, the validity of acquired reputation is largely subjective and unknown. Clearly, if we are to achieve an optimal reputation system we will need a fixed set of rules or norms that are expected to be followed in certain situations. If we look back to the analogy with human's, we are - to a fairly high degree - able to maintain order in some parts of the world by enforcing rules. It is unreasonable to think that we can prevent all wrong-doing. There are always outliers that will oppose the greater society, but eventually the greater community will overcome those outliers and prevent them from being detrimental to society. There is no perfect solution to maintaining social order in reality, and likewise, there is no perfect solution for maintaining good behaviour of computational entities.

The idea of enforcing rules or generating reputation of other entities to use in a decision-making process are both realistic options. This is known as the Emerge vs. Impose problem. Do we maintain records based on a fixed set of imposed rules? Or do we build rules as the system emerges and reputations are formed. In our opinion, we feel the answer is both.

=What systems are currently in place?=

Reputation systems are used in a wide array of projects and applications, from e-commerce sites to the web as a whole. Currently, existing distributed systems do not have an ideal reputation system in place. We will discuss two forms of existing systems. Peer-based and policy-based systems. Peer-based systems rely on emergent reputation, while policy-based systems rely on imposed rules.

Peer-based systems are ones in which end-users provide reputation information about a certain subject. Sites such as eBay and Youtube utilize rating and comment systems. Particularly, eBay uses an interaction-based form of reputation to provide information about buyers and sellers<ref name="ebayreputation">Reputation Management. Wikipedia. http://en.wikipedia.org/wiki/Reputation_management [March 28, 2011]</ref>.

Policy-based systems can be found in a variety of application frameworks. Two examples include Java and Android. These systems enforce a developer to state the intentions of the application in what's known as a policy file. The stated intentions are required as a security measure for access to crucial parts of the system<ref name="javapolicy">Default Policy Implementation and Policy File Syntax. Oracle. http://download.oracle.com/javase/1.3/docs/guide/security/PolicyFiles.html [March 7, 2011]</ref>. For mobile devices, if an application needs to acquire the GPS location or read/write contact information this must be stated in the policy file<ref name="android">Android. Google. http://developer.android.com/index.html [March 28, 2011]</ref>. Otherwise, an application cannot be deployed. Furthermore, items on this policy file are presented to the user and if a user is suspicious about an application needing access to unnecessary utilities, they can choose to not install the application. For example, a "stop-watch" application might appear extremely suspicious to a user if it requested access to contact information and internet access. Interestingly, Android and other mobile application frameworks such as iOS<ref name="ios">iOS Developer Guide. Apple. http://developer.apple.com/devcenter/ios/index.action [March 28, 2011]</ref> also use an emergent-based reputation system. They provide a means to rate and review applications similar to the buyer-seller reputation systems provided with eBay. The mentality is that if an application is untrustworthy or of poor quality, the greater public opinion will merge and polarize to negative opinions - eventually leaving the application as a non-threat to potential buyers. For trustworthy applications, the result would be quite the opposite.

==How can we improve on existing systems?==

Existing systems provide an adequate level of accurate reputation information for their purpose. For closed and centralized systems such as the example provided, eBay, this level of sophistication is sufficient. Buyers are able to favour certain sellers over others based on feedback and ratings left by previous sellers. However, to make this decision easier, these sites convert the data into a more readable and comparable form, a numerical scale. This abstraction process, however, prevents one from truly understanding the reasons behind the values. Buyers and sellers are able to bid with a fair degree of certainty and trust; if one party is unsatisfied with the transaction, eBay will step in to provide order<ref name="ebayreputation" />. This level of justice is not easily attainable in large-distributed systems. Although we can assume we have an adequate level of justice, in order for a reputation system to be plausible in such a large system and for justice systems to work, we need to store sets of event-based histories that can be attributed to each entity that interacts in the system. In the case where reputation data fails to protect machines and the individuals behind them, we can fall back on justice systems and provide them with accurate information.

=Our assumptions=

In this system, we will make a set of assumptions. Without these, a system of this size either would not function or would be too broad, in terms of scope, to ever be acceptable.

The justice assumption is where the assumption is made that some other system or set of rules will govern when reputation information needs to be updated and exchanged. Our system will not determine when exchange of information is required, only what information should be exchanged. Similarly, since each system will likely have its own perspective on what is right and wrong, no assumption will be made that there is a single fixed set of rules governing the operation of the system of justice on the whole. This means that the system should be adaptable to different purposes without compromising the integrity of the internet at large. Two opposing systems of justice issuing opposing reputation information will eventually result in the two segments of the network ignoring the opposing information, leading to an eventual stable, and consistent, state. This is appropriate, given the diversity of the internet at large.

In the attribution assumption it is assumed that all actions are being correctly attributed. This also includes assuming that information being exchanged between two peers can be properly sourced. Originally, a section on public-key infrastructure (PKI) was going to be included, but it was decided that this would be ultimately out of scope for this system.

In order to make sure that a system of this scale is feasible, it is necessary to make a public good assumption. This means that it will be assumed that resources are available on the whole system to maintain the reputation information necessary for the system to function. This assumption is generally valid considering the capacity of the modern internet, and the exponential growth of technology.

Finally the security in the majority assumption is made. It is assumed that in a sufficiently large system, even if a given number of nodes are currently acting maliciously, the large number of non-malicious nodes will eventually overwhelm the fraudulent messages resulting in a generally good result. It would be impossible to design a system that did not rely on this assumption, since if a majority of the nodes were acting against the general good of the system, it would fail regardless of the overall safety of the system. Now, in this context, majority takes on a very specific meaning. Since, for obvious reasons, each node is only going to trust trustworthy nodes, it is the case where we are going to rely on the security in the majority of the opinions of trusted nodes. This will give the system its own kind of inertia, helping to safeguard the system against gaming in the long term.

=Generating reputation=

==How do we represent reputation?==

Reputation data can be stored in a variety of different forms and representations. We start with a summary of previous attempts in creating a solution for representing reputation. A frequently used form is one that utilizes a numerical scale for reputation. These are known as EigenTrust systems<ref name="krukow" />. In their essence, they store and aggregate data into a numerical form. These values are easy to compare and because primitive data types can be used, they require very little storage space. Despite these lucrative advantages, there are some significant negative aspects of such a system. Firstly, information is typically lost in the abstraction process. Concrete data is acquired and then converted down to a minimal form. Once this conversion is done, there is little one can do to understand the concrete data that it was generated from. In other words, this abstraction process is irreversible. Likewise, the process can result in ambiguity among data. For example, a reputation of 0 might be interpreted as having no reputation history or having an average reputation rating of 0. And, of course, as a result of the irreversibility of numerical data, we cannot return the data to its original concrete form to better understand the reasons behind the reputation.

Another interesting form of reputation is one that was proposed by Shmatikov and Talcott<ref name="krukow" />. They attributed reputation to encompass the history of entities as a set of time-stamped events. The key difference between EigenTrust and their solution is that we can store data in its concrete form. Additionally, if we modify their solution to allow for the notion of sessions, we can generate a clear view of related actions that correspond to an entity's computational session. This provides a querying entity or a justice system with crucial information to make their respective decision. Clearly, there are some ethical and privacy issues that arise from this; we tackle this issue more closely in a following section.

==How do we gather reputation?==

Gathering reputation information in these kinds of systems will generally follow a push model. When a node receives reputation information deemed important and reliable enough to be disseminated, it will then push the information to it's peers, or superiors. This system can either be automated, or policy-based.

In the case where reputation information for a given system is required the information would be queried as outlined below, then stored and/or disseminated to its peers if deemed important enough. What constitutes "important enough" will vary depending on the specific context, but either way the information would be retrieved, and stored until deemed no longer relevant, and then discarded.

==Where do we store reputation?==

Reputation information will be stored at each individual host giving every system or group of systems their own perspective. This is both appropriate, and efficient given how each system or grouping of systems is likely to have a different objective and context.

Some hosts may also, optionally, act as repositories for this information. These might be elected (in an emergent system) or imposed (in a hierarchy, or publish-subscribe model). These systems will provide a public good, in that they will become query-able repositories of information.

It would be impractical for information to be stored at every node indefinitely, and eventually given reputation entries must be discarded. This occurrence would depend on a variety of factors. First, if a piece of reputation information was requested frequently from other nodes, the information would be regarded as highly valuable and therefore kept for future reference. If a piece of reputation information was very infrequently used, it might be remove or labelled for deletion at some future point. Essentially, the more important or relevant a piece of information is, the more likely it is to be stored. This provides good localization and excellent overall reliability of information, while still allowing systems to maintain a level of forgiveness.

==How do we maintain reputation?==

As stated earlier, we need to store an adequate level of information about interactions between entities. This "adequate" level can be quite large in terms of actual storage space. This brings us to the problem of how to maintain reputation history, since in a distributed system this is crucial to the scalability and success of the entire system. A solution here is to use the notion of Dynamic Model-Checking, by Havelund and Rosu<ref name="krukow" />. They came up with a way to re-evaluate stored reputation history and efficiently aggregate and combine eligible data. This can be thought of as a "reduce" function in the sense of Google's Map/Reduce algorithm<ref name="mapreduce">Dean J. et al. MapReduce: Simplified Data Processing on Large Clusters http://labs.google.com/papers/mapreduce.html [March 3, 2011]</ref>. We generate and store sets of events related to particular entities (this is an append function) and use a reduce function to minimize the storage space required. We realize, however, that some data will not be eligible to be "reduced". Significant negative reputation, for instance, such as DDoS attacks will likely need to be retained indefinitely in case justice systems need sufficient proof of a specific incident. This solution will work quite well as we maintain a sufficient amount of useful concrete information, yet still save space by merging and combining certain types of data. If we can assume that space will never be an issue or that processing time for searching through sets of reputation history items is negligible, then we would clearly not have to worry about implementing this type of "reduce" mechanism.

==How is reputation disseminated?==

The dissemination of reputation information is a core concern of reputation systems in general. This vital exchange of information is what allows these systems to function. Ideally, methods of information exchange should provide a given set of features. First, the information needs to be reliable, and this means that it needs to be as immune as possible to gaming and stored securely. Second, there needs to be good localization of the data to ensure it is where it is needed, when it is needed. Finally the system needs to be scalable and flexible. While the afore mentioned reasons form the technical requirements of the system, there is one additional non-functional requirement that must be considered: level of trust.

In general, there are three common modes of disseminating information of this type that would need to be supported in order to make a reputation system feasible: Hierarchy, Publish/Subscribe, and Peer-to-Peer.

In a hierarchy, there are pre-set, or elected nodes that are responsible for maintaining an authoritative list. A good example of this technology in practice is the domain name system (or DNS, for short). These systems allow for a great deal of control over the information in the system, at the expense of scalability and flexibility. These systems are very common in the corporate world today, and align well with organizational structure. It also means that if a flaw is detected at the information, manual intervention is possible. Unfortunately, these systems tend to be rife with single points of failure, and scalability issues. In addition, implementing this kind of a system on an internet-scale would mean designating a single authority for all reputation information, which would form a natural bottleneck despite advances in caching. finally, there would be the issue of trust in such a system. While hierarchies are ideal where an overall system architecture is imposed and trust is mandated, they are much less palatable on the internet-scale because it would be impossible to establish a single authority that everyone would trust. Also, if there are a single sets of authorities, then there is the added issue of security. Compromising one system would taint the reputation information across the entire reputation system.

Publish/subscribe is a model of dissemination of information that relies on central repositories, which are then queried by each client when an update is needed. Common examples of these in technology include Really Simple Syndication (RSS) feeds, bulletin board systems (BBS). Outside modern technology, analogies can be drawn between the publish/subscribe model and common sources of information like newspapers, magazines, and other forms of periodicals. First the source publishes an update, and then "subscribers" can receive updates through either a push from the publisher, or a query for updates. This technology has a couple of attractive features, and has been broadly researched over the last 10 years, especially in the area of how this technique can be applied to wireless networks <ref name="wifipublishsubscribe">Gajic, B.; Riihijärvi, J.; Mähönen, P.; , "Evaluation of publish-subscribe based communication over WiMAX network," Ultra Modern Telecommunications and Control Systems and Workshops (ICUMT), 2010 International Congress on , vol., no., pp.38-43, 18-20 Oct. 2010 </ref>. Being data-centric, they can be a very helpful way of exchanging information. Unfortunately they require some kind of a fixed infrastructure in most cases, using either fixed reference points (like a base station) or elected coordinating nodes arranged in a distributed hash table (DHT) <ref name="p2ppublishsubscribe">Dongcai Shi; Jianwei Yin; Zhaohui Wu; Jinxiang Dong; , "A Peer-to-Peer Approach to Large-Scale Content-Based Publish-Subscribe," Web Intelligence and Intelligent Agent Technology Workshops, 2006. WI-IAT 2006 Workshops. 2006 IEEE/WIC/ACM International Conference on , vol., no., pp.172-175, 18-22 Dec. 2006</ref>. Unfortunately, there are some drawbacks to these technologies. Mainly it involves some pre-selected, or elected nodes that act as authorities. This creates points of failure, and means that some nodes need to trust others with their authority information. While it is entirely possible that there will be publish-subscribe components in a complete reputation system, the information from such information repositories must be interpreted within the context of the source node's reputation. This means that if a given information repository has been a source of unreliable information in the past, then its own negative reputation would likely force most other nodes to disregard the information, further diminishing the possible benefits of hosting such a repository. These types of systems also do not provide good localization of data, meaning nodes may have to search longer for relevant information leading to greater overhead and latency in the system on a whole.

Finally Peer-to-peer is, perhaps, the newest method of disseminating information. While there are many ways to exchange information in a peer-to-peer fashion, gossiping is the most relevant of these <ref name="gossipreputation"> Zhou, R.; Hwang, K.; , "Gossip-based Reputation Aggregation for Unstructured Peer-to-Peer Networks," Parallel and Distributed Processing Symposium, 2007. IPDPS 2007. IEEE International , vol., no., pp.1-10, 26-30 March 2007 </ref>. In a gossip-based system, sets of peers exchange information in a semi-random way. It has been found in practice that this system of information exchange provides not only good localization, but also excellent scalability. The major issues surrounding gossip-based systems are that information for "far away" nodes would need to be queried, and there is the possibility of fraudulent information being exchanged (meaning that the system would have to rely on the safety of the consensus of the majority). The disadvantage to such a system is that it is unstructured, and if an error is propagated, it can take a while for a corrected, consistent picture to appear across the network.

In application, all of these methods of information dissemination would likely need to be supported in some fashion. Very few governments or organizations would be willing to support a system where they are required to accept updates from the cloud blindly, and similarly it is very unlikely that such organizations would be willing to publish or otherwise share information with the cloud at large. This means that any dissemination solution would have to be a hybrid solution allowing for the definition of fixed, strict hierarchies as well as the immensely scalable and dynamic peer-to-peer solutions. Where the line between these two will be drawn is not fixed. Some organizations may opt to make almost all information public, while others may not, and allow no external information to be published externally.

==How is reputation queried?==

Querying reputation is the problem of how one entity in a reputation system acquires reputation data on another entity in the system that it does not already have. There will need to be an established way of requesting, receiving and finally analyzing the reputation data to decide if a connection should be made or not. This needs to be done because depending on the size of the system it's highly unlikely any given entity will know about another given entity if it has never communicated with it before. In a system like the internet it is unreasonable to expect the regular process of information dissemination to provide every entity information on every other entity. It is even more unreasonable to expect an entity in the system to be able to store all this information.

In the greater scheme of a reputation system, querying assumes some systems need to already exist. There needs to be a means of authenticating messages, as to limit the spread of false information and guarantee the integrity of the system. There needs to be a way of maintaining the history of the system, so that reputation events can be recorded and accessed. There needs to be a means of dissemination, as querying in this sense won't be suited for the gradual distribution of information. In short, for there to be querying of reputation, you need to have something worth querying.

But what does a system for querying need to address? It needs to be able to request information on demand, and receive that information quickly and efficiently. Specifically, the system needs to be able to handle any given entity in sending out a request for reputation information, and have other entities process that request and return a response. There needs to be a way for an entity to handle the likely event that there is no reputation information on another entity. Finally, the entity needs a way to process and interpret the information it receives.

As previously mentioned, in this paper, there are two primary layouts for a reputation system: hierarchical and distributed. Both of which will need to interact with each other. In a hierarchical-centralized system, there is a hierarchy of nodes who defer to each other. Any given node in the system will defer to an authority, known as its authority node. Most, if not all, reputation information will go through this node, and as far as their subordinate nodes are concerned, his 'views', or interpretation of the reputation data, will be absolute. In this scheme nothing is lost if a node were to leave the network.<ref name="repest">Xing Jin, S.-H. Gary Chan, "Reputation Estimation and Query in
Peer-to-Peer Networks", IEEE Communications Magazine, April 2010. http://www.chennaisunday.com/ieee%202010/Reputation%20Estimation%20and%20Query%20in%20Peer-to-Peer%20Networks.pdf </ref> In a distributed, peer to peer system, reputation information will be acquired from trusted peers and analyzed to determine whether to connect or not.

The actual process of querying should be fairly simple. A given entity or node in the system needs to decide if it should contact another node in the system. First, it must check its local representation of reputation data to see if it already has both enough, and up-to-date information on a node. If it does, it can move toward making a decision, which is discussed later. If however, the information needed is not already held by the node, it will need to be queried. This would be similar to the XREP system used in some peer-to-peer file sharing networks, Which can “Query” and “Poll” peers to decide who to obtain resources from. <ref name="repest" /> Another similar concept is a “TrustNet”, wherein an “Agent”, after determining another “Agent” isn't already acquainted with him, will query all his Neighbours on the secondary agents trustworthiness.<ref name="EviMod">Bin Yu, Munindar P. Singh, "An Evidential Model of Distributed Reputation Management", AAMAS’02, July 19, 2002, http://portal.acm.org/citation.cfm?id=544809&coll=DL&dl=ACM&CFID=17527626&CFTOKEN=24792561&retn=1#Fulltext </ref>.

This brings us back to the two primary types of reputation systems, hierarchical and distributed. In a hierarchical system the process is incredibly simple: ask your superior node, and wait for a response. The superior node might have enough information on hand to decide, or it might ask its peers or superiors. Either way, the response received from the superior node will be used by the original querying node.

The distributed querying is a little more complex. The querying node will need to decide whom to ask, perhaps asking nodes it trusts if it's been operating in the reputation system for a while, or just any nearby node in general. It will perhaps ask for just a quick reputation value, or maybe a snapshot of relevant historical events. In any case, it will use the evidence collected (if any) to ultimately make a decision. In a way this node is it's own authority node.

=Making decisions=
==How do we make decisions based on reputation?==

Every entity will have its own interpretation of reputation data. There will most likely be a common set of events considered bad for essentially any system, such as one entity participating in a DDOS on another entity, the distribution of malware, and so on. Other things are more abstract and unique to certain groups. Things like distributing unverifiable claims might be considered a negative reputation event by a reputable news source, perfectly acceptable by a tabloid, and irrelevant to the average entity representing a single person's personal computer. Entities will need to decide what's important to them, most likely via a human defining which events are worth taking note of and which aren't. It is entirely possible, and likely, that different entities won't record events that other entities would consider noteworthy. It would therefore be beneficial to have multiple people using the same rule set (though not completely useless, as you can still record personal instances of these events for your own history store).

Once an entity has obtained this information, either via the regular process of dissemination, querying, or witnessing an event firsthand, it needs to make a decision. This is, ultimately, very open ended and up to each entity. For example, A very simple mechanism would be to only communicate with entities that have no negative reputation events of any kind, and that are only viewed neutrally or positively by other entities. Another would be to ignore other entities opinions, assign a weight to each type of reputation event and do a calculation based on the evidence. However these are only two options among many, there is no need for a standardized process. In short, the process and details of actually making the decision are not that important, as long as what's decided upon is something that other entities can understand. That is, using a collection of evidence that's been stored to form an opinion that other entities can query you on, and deciding whether or not and under what conditions to connect to the other entity.

=Implementation=

The implementation and deployment of such a reputation system is a very difficult task. Ideally, all systems would simultaneously switch over to a new protocol for reputation management. On a distributed system as large as the web, this is highly improbable. Typically, the success of updates and layers built on top of the web's existing architecture comes down to the fact that they are incrementally deployable. Updates are incremental and so the entire system is not succumbed to a system-wide blackout.

==Can we achieve this through incremental updates?==

The key question is whether we can deploy this reputation system using incremental updates. Obviously, a large-scale wholesale changeover wouldn't be palatable to anyone. Organizations and individuals are historically, and understandably reticent to change. That said, it is very likely that such a large change in operating mentality will require adoption at both the corporate level, and the individual level.

Basically, phasing this in will rely on companies deciding that it is in their own best interests to have this running locally. Individuals part of the greater organization would then have to decide to switch to the gossip-based solution. Eventually, an emergent and cohesive system would appear. Reputation is currently facilitated by justice systems and imposed rules for entities within systems. We can continue to use imposed rules or existing infrastructure if we don't have adequate emergent information. This way we can incrementally update the environment and eventually have a full-fledged emergent reputation system. This evolutionary system is much preferable to the alternative revolutionary system because it avoids the disruption that a revolutionary change necessitates.

=Conclusion=

This paper has covered what reputation is, and how it can be applied to computer networks. We have discussed what constitutes reputation, and how it can be useful for judging the nature of a member of a reputation system. This leads to why reputation is useful; it provides a means for quickly judging another system, and a distributed reputation system would allow for members of said system to judge one another based upon past actions. Such a system would need to have and allow for imposed rules to punish actions that are universally shunned, such as the distribution of malware. It would also need to allow for emergent rules, as many entities in a system will have different views as to what would constitute a reputation lowering event. Existing systems for reputation, which are peer-to-peer and policy-based, are not suitable for a completely open, large distributed network, such as the internet.

<more coming>

Reputations systems have already formed an important part of the internet in some areas. It is very likely that they will continue to do so in the future, and their scope is only likely to only increase. This paper presented an overview on current reputation systems, as well as providing an outline on how the idea of a reputation system can be implemented on an internet-wise scale. By dividing up the problem of designing and implementing a reputation system into several smaller components, this paper tackled the complicated questions associated with the overall architecture of a reputation system and how such a system can be created in a way to satisfy the multitude of stakeholders that exist in the cloud. While such a system might not be immediately implementable, it is the likely that such a system would provide tangible long-term benefits in the future.

=References=

<references />

Distributed OS: Winter 2011 Reputation Systems Paper

2011-04-11T09:07:59Z

Tgelowsk:

=What is reputation?=

In the real world, people are generally quite conscious of certain behavioural actions that make. These actions are expected to fall within the social norms and are scrutinized continuously by the people around us. On a daily basis, Individuals build a personal set of judgment values and opinions on others in the society. When we listen to a politician on the news, or interact with a friends, we are updating this image that we have of the individual or group. It is this image we generate that helps us make conclusions as to whether we like the individual, whether we trust the individual, or whether we can relate to the individual. The global opinions that others have on us is known as reputation.

A reputation system's main purpose is to facilitate in providing a means for assumptions to be made about the level of trust one can have for a particular person or situation in executing a task to our liking. It is important to note the importance of the word assumption. With the gathered information, we are able to generate an estimate of their actions. It is by no means accurate. Furthermore, reputation is not a globally accepted view of an entity. In some cases, an individuals reputation can be quite varied between different observers. Some may have encountered contact with the entity in a different context or had a different level of expectation compared to others <ref name="krukow" />. Likewise, some individuals might be falsely persuaded to confirm to specific opinions by large and powerful groups, whereas others have a crystallized and hard-to-change opinion.

=How can reputation be used in a distributed environment?=

Reputation can be useful in acquiring an understanding of how congruent one's own goals are from another. If we are to accomplish a desired task that requires the cooperation of others, we carefully analyze whether the individuals we choose will be a good fit or whether they will hinder our progress. Or, worse yet, halt our progress completely.

In a more technical and distributed view, reputation is the process of recording, aggregating, and distributing information about an entity's behaviour in distributed applications. Reputation might be based on the entity's past ability to adhere to a mutual contract with another entity <ref name="krukow">Krukow K. et al. A Logical Framework for Reputation Systems and History-based Access Control. School of Electronics and Computer Science University of Southampton, UK [March 3, 2011]</ref>. As stated above, the validity of acquired reputation is largely subjective and unknown. Clearly, if we are to achieve an optimal reputation system we will need a fixed set of rules or norms that are expected to be followed in certain situations. If we look back to the analogy with human's, we are - to a fairly high degree - able to maintain order in some parts of the world by enforcing rules. It is unreasonable to think that we can prevent all wrong-doing. There are always outliers that will oppose the greater society, but eventually the greater community will overcome those outliers and prevent them from being detrimental to society. There is no perfect solution to maintaining social order in reality, and likewise, there is no perfect solution for maintaining good behaviour of computational entities.

The idea of enforcing rules or generating reputation of other entities to use in a decision-making process are both realistic options. This is known as the Emerge vs. Impose problem. Do we maintain records based on a fixed set of imposed rules? Or do we build rules as the system emerges and reputations are formed. In our opinion, we feel the answer is both.

=What systems are currently in place?=

Reputation systems are used in a wide array of projects and applications, from e-commerce sites to the web as a whole. Currently, existing distributed systems do not have an ideal reputation system in place. We will discuss two forms of existing systems. Peer-based and policy-based systems. Peer-based systems rely on emergent reputation, while policy-based systems rely on imposed rules.

Peer-based systems are ones in which end-users provide reputation information about a certain subject. Sites such as eBay and Youtube utilize rating and comment systems. Particularly, eBay uses an interaction-based form of reputation to provide information about buyers and sellers<ref name="ebayreputation">Reputation Management. Wikipedia. http://en.wikipedia.org/wiki/Reputation_management [March 28, 2011]</ref>.

Policy-based systems can be found in a variety of application frameworks. Two examples include Java and Android. These systems enforce a developer to state the intentions of the application in what's known as a policy file. The stated intentions are required as a security measure for access to crucial parts of the system<ref name="javapolicy">Default Policy Implementation and Policy File Syntax. Oracle. http://download.oracle.com/javase/1.3/docs/guide/security/PolicyFiles.html [March 7, 2011]</ref>. For mobile devices, if an application needs to acquire the GPS location or read/write contact information this must be stated in the policy file<ref name="android">Android. Google. http://developer.android.com/index.html [March 28, 2011]</ref>. Otherwise, an application cannot be deployed. Furthermore, items on this policy file are presented to the user and if a user is suspicious about an application needing access to unnecessary utilities, they can choose to not install the application. For example, a "stop-watch" application might appear extremely suspicious to a user if it requested access to contact information and internet access. Interestingly, Android and other mobile application frameworks such as iOS<ref name="ios">iOS Developer Guide. Apple. http://developer.apple.com/devcenter/ios/index.action [March 28, 2011]</ref> also use an emergent-based reputation system. They provide a means to rate and review applications similar to the buyer-seller reputation systems provided with eBay. The mentality is that if an application is untrustworthy or of poor quality, the greater public opinion will merge and polarize to negative opinions - eventually leaving the application as a non-threat to potential buyers. For trustworthy applications, the result would be quite the opposite.

==How can we improve on existing systems?==

Existing systems provide an adequate level of accurate reputation information for their purpose. For closed and centralized systems such as the example provided, eBay, this level of sophistication is sufficient. Buyers are able to favour certain sellers over others based on feedback and ratings left by previous sellers. However, to make this decision easier, these sites convert the data into a more readable and comparable form, a numerical scale. This abstraction process, however, prevents one from truly understanding the reasons behind the values. Buyers and sellers are able to bid with a fair degree of certainty and trust; if one party is unsatisfied with the transaction, eBay will step in to provide order<ref name="ebayreputation" />. This level of justice is not easily attainable in large-distributed systems. Although we can assume we have an adequate level of justice, in order for a reputation system to be plausible in such a large system and for justice systems to work, we need to store sets of event-based histories that can be attributed to each entity that interacts in the system. In the case where reputation data fails to protect machines and the individuals behind them, we can fall back on justice systems and provide them with accurate information.

=Our assumptions=

In this system, we will make a set of assumptions. Without these, a system of this size either would not function, or would be of too broad of scope to ever be acceptable.

The justice assumption is where the assumption is made that some other system or set of rules will govern when reputation information needs to be updated and exchanged. Our system will not determine when exchange of information is required, only what information should be exchanged. Similarly, since each system will likely have its own perspective on what is right and wrong, no assumption will be made that there is a single fixes set of rules governing the operation of the system of justice on the whole. This means that the system should be adaptable to different purposes without compromising the integrity of the internet at large. Two opposing systems of justice issuing opposing reputation information will eventually result in the two segments of the network ignoring the opposing information, leading to an eventual stable, if not consistent, state. This is appropriate, given the diversity of the internet at large.

In the attribution assumption it is assumed that all actions are being correctly attributed. This also includes assuming that information being exchanged between two peers can be properly sourced. Originally, a section on public-key infrastructure (PKI) was going to be included, but it was decided that this would be ultimately out of scope for this system.

In order to make sure that a system of this scale is feasible, it is necessary to make a public good assumption. This means that it will be assumed that resources are available on the whole system to maintain the reputation information necessary for the system to function. This assumption is generally valid considering the capacity of the modern internet, and the exponential growth of technology.

Finally the security in the majority assumption is made. It is assumed that in a sufficiently large system, even if a given number of nodes are currently acting maliciously, the large number of non-malicious nodes will eventually overwhelm the fraudulent messages resulting in a generally good result. It would be impossible to design a system that did not rely on this assumption, as if a majority of the nodes were acting against the general good of the system, it would fail regardless of the overall safety of the system itself. Now, in this context, majority takes on a very specific meaning. Since, for obvious reasons, each node is only going to trust trustworthy nodes, it is the case where we are going to rely on the security in the majority of the opinions of trusted nodes. This will give the system it's own kind of inertia, helping to safeguard the system against gaming in the long term.

=Generating reputation=

==How do we represent reputation?==

Reputation data can be stored in a variety of different forms and representations. We start with a summary of previous attempts in creating a solution for representing reputation. A frequently used form is one that utilizes a numerical scale for reputation. These are known as EigenTrust systems<ref name="krukow" />. In their essence, they store and aggregate data into a numerical form. These values are easy to compare and because primitive data types can be used, they require very little storage space. Despite these lucrative advantages, there are some significant negative aspects of such a system. Firstly, information is typically lost in the abstraction process. Concrete data is acquired and then converted down to a minimal form. Once this conversion is done, there is little one can do to understand the concrete data that it was generated from. In other words, this abstraction process is irreversible. Likewise, the process can result in ambiguity among data. For example, a reputation of 0 might be interpreted as having no reputation history or having an average reputation rating of 0. And, of course, as a result of the irreversibility of numerical data, we cannot return the data to its original concrete form to better understand the reasons behind the reputation.

Another interesting form of reputation is one that was proposed by Shmatikov and Talcott<ref name="krukow" />. They attributed reputation to encompass the history of entities as a set of time-stamped events. The key difference between EigenTrust and their solution is that we can store data in its concrete form. Additionally, if we modify their solution to allow for the notion of sessions, we can generate a clear view of related actions that correspond to an entity's computational session. This provides a querying entity or a justice system with crucial information to make their respective decision. Clearly, there are some ethical and privacy issues that arise from this; we tackle this issue more closely in a following section.

==How do we gather reputation?==

Gathering reputation information in these kinds of systems will generally follow a push model. When a node receives reputation information deemed important and reliable enough to be disseminated, it will then push the information to it's peers, or superiors. This system can either be automated, or policy-based.

In the case where reputation information for a given system is required the information would be queried as outlined below, then stored and/or disseminated to its peers if deemed important enough. What constitutes "important enough" will vary depending on the specific context, but either way the information would be retrieved, and stored until deemed no longer relevant, and then discarded.

==Where do we store reputation?==

Reputation information will be stored at each individual host giving every system or group of systems their own perspective. This is both appropriate, and efficient given how each system or grouping of systems is likely to have a different objective and context.

Some hosts may also, optionally, act as repositories for this information. These might be elected (in an emergent system) or imposed (in a hierarchy, or publish-subscribe model). These systems will provide a public good, in that they will become query-able repositories of information.

It would be impractical for information to be stored at every node indefinitely, and eventually given reputation entries must be discarded. When this occurs would depend on a variety of factors. First, if a piece of reputation information was requested a lot from other nodes, or it indicated an extreme state. Essentially, the more important or relevant a piece of information is, the more likely it is to be stored. This provides good localization and excellent overall reliability of information, while still allowing given systems to be forgiven.

==How do we maintain reputation?==

As stated earlier, we need to store an adequate level of information about interactions between entities. This "adequate" level can be quite large in terms of actual storage space. This brings us to the problem of how to maintain reputation history, since in a distributed system this is crucial to the scalability and success of the entire system. A solution here is to use the notion of Dynamic Model-Checking, by Havelund and Rosu<ref name="krukow" />. They came up with a way to re-evaluate stored reputation history and efficiently aggregate and combine eligible data. This can be thought of as a "reduce" function in the sense of Google's Map/Reduce algorithm<ref name="mapreduce">Dean J. et al. MapReduce: Simplified Data Processing on Large Clusters http://labs.google.com/papers/mapreduce.html [March 3, 2011]</ref>. We generate and store sets of events related to particular entities (this is an append function) and use a reduce function to minimize the storage space required. We realize, however, that some data will not be eligible to be "reduced". Significant negative reputation, for instance, such as DDoS attacks will likely need to be retained indefinitely in case justice systems need sufficient proof of a specific incident. This solution will work quite well as we maintain a sufficient amount of useful concrete information, yet still save space by merging and combining certain types of data. If we can assume that space will never be an issue or that processing time for searching through sets of reputation history items is negligible, then we would clearly not have to worry about implementing this type of "reduce" mechanism.

==How is reputation disseminated?==

The dissemination of reputation information is a core concern of reputation systems in general. This vital exchange of information is what allows these systems to function. Ideally, methods of information exchange should provide a given set of features. First, the information needs to be reliable, and this means that it needs to be as immune as possible to gaming and stored securely. Second, there needs to be good localization of the data to ensure it is where it is needed, when it is needed. Finally the system needs to be scalable and flexible. While the afore mentioned reasons form the technical requirements of the system, there is one additional non-functional requirement that must be considered: level of trust.

In general, there are three common modes of disseminating information of this type that would need to be supported in order to make a reputation system feasible: Hierarchy, Publish/Subscribe, and Peer-to-Peer.

In a hierarchy, there are pre-set, or elected nodes that are responsible for maintaining an authoritative list. A good example of this technology in practice is the domain name system (or DNS, for short). These systems allow for a great deal of control over the information in the system, at the expense of scalability and flexibility. These systems are very common in the corporate world today, and align well with organizational structure. It also means that if a flaw is detected at the information, manual intervention is possible. Unfortunately, these systems tent to be rife with single points of failure, and scalability issues. In addition, implementing this kind of a system on an internet-scale would mean designating a single authority for all reputation information, which would form a natural bottleneck despite advances in caching. finally, there would be the issue of trust in such a system. While hierarchies are ideal where an overall system architecture is imposed and trust is mandated, they are much less palatable on the internet-scale because it would be impossible to establish a single authority that everyone would trust. Also, if there are a single sets of authorities, then there is the added issue of security. Compromising one system would taint the reputation information across the entire reputation system.

Publish/subscribe is a model of dissemination of information that relies on central repositories, which are then queried by each client when an update is needed. Common examples of these in technology include Really Simple Syndication (RSS) feeds, bulletin board systems (BBS). Outside modern technology, analogies can be drawn between the publish/subscribe model and common sources of information like newspapers, magazines, and other forms of periodicals. First the source publishes an update, and then "subscribers" can receive updates through either a push from the publisher, or a query for updates. This technology has a couple of attractive features, and has been broadly researched over the last 10 years, especially in the area of how this technique can be applied to wireless networks <ref name="wifipublishsubscribe">Gajic, B.; Riihijärvi, J.; Mähönen, P.; , "Evaluation of publish-subscribe based communication over WiMAX network," Ultra Modern Telecommunications and Control Systems and Workshops (ICUMT), 2010 International Congress on , vol., no., pp.38-43, 18-20 Oct. 2010 </ref>. Being data-centric, they can be a very helpful way of exchanging information. Unfortunately they require some kind of a fixed infrastructure in most cases, using either fixed reference points (like a base station) or elected coordinating nodes arranged in a distributed hash table (DHT) <ref name="p2ppublishsubscribe">Dongcai Shi; Jianwei Yin; Zhaohui Wu; Jinxiang Dong; , "A Peer-to-Peer Approach to Large-Scale Content-Based Publish-Subscribe," Web Intelligence and Intelligent Agent Technology Workshops, 2006. WI-IAT 2006 Workshops. 2006 IEEE/WIC/ACM International Conference on , vol., no., pp.172-175, 18-22 Dec. 2006</ref>. Unfortunately, there are some drawbacks to these technologies. Mainly it involves some pre-selected, or elected nodes that act as authorities. This creates points of failure, and means that some nodes need to trust others with their authority information. While it is entirely possible that there will be publish-subscribe components in a complete reputation system, the information from such information repositories must be interpreted within the context of the source node's reputation. This means that if a given information repository has been a source of unreliable information in the past, then its own negative reputation would likely force most other nodes to disregard the information, further diminishing the possible benefits of hosting such a repository. These types of systems also do not provide good localization of data, meaning nodes may have to search longer for relevant information leading to greater overhead and latency in the system on a whole.

Finally Peer-to-peer is, perhaps, the newest method of disseminating information. While there are many ways to exchange information in a peer-to-peer fashion, gossiping is the most relevant of these <ref name="gossipreputation"> Zhou, R.; Hwang, K.; , "Gossip-based Reputation Aggregation for Unstructured Peer-to-Peer Networks," Parallel and Distributed Processing Symposium, 2007. IPDPS 2007. IEEE International , vol., no., pp.1-10, 26-30 March 2007 </ref>. In a gossip-based system, sets of peers exchange information in a semi-random way. It has been found in practice that this system of information exchange provides not only good localization, but also excellent scalability. The major issues surrounding gossip-based systems are that information for "far away" nodes would need to be queried, and there is the possibility of fraudulent information being exchanged (meaning that the system would have to rely on the safety of the consensus of the majority). The disadvantage to such a system is that it is unstructured, and if an error is propagated, it can take a while for a corrected, consistent picture to appear across the network.

In application, all of these methods of information dissemination would likely need to be supported in some fashion. Very few governments or organizations would be willing to support a system where they are required to accept updates from the cloud blindly, and similarly it is very unlikely that such organizations would be willing to publish or otherwise share information with the cloud at large. This means that any dissemination solution would have to be a hybrid solution allowing for the definition of fixed, strict hierarchies as well as the immensely scalable and dynamic peer-to-peer solutions. Where the line between these two will be drawn is not fixed. Some organizations may opt to make almost all information public, while others may not, and allow no external information to be published externally.

==How is reputation queried?==

Querying reputation is the problem of how one entity in a reputation system acquires reputation data on another entity in the system that it does not already have. There will need to be an established way of requesting, receiving and finally analyzing the reputation data to decide if a connection should be made or not. This needs to be done because depending on the size of the system it's highly unlikely any given entity will know about another given entity if it has never communicated with it before. In a system like the internet it is unreasonable to expect the regular process of information dissemination to provide every entity information on every other entity. It is even more unreasonable to expect an entity in the system to be able to store all this information.

In the greater scheme of a reputation system, querying assumes some systems need to already exist. There needs to be a means of authenticating messages, as to limit the spread of false information and guarantee the integrity of the system. There needs to be a way of maintaining the history of the system, so that reputation events can be recorded and accessed. There needs to be a means of dissemination, as querying in this sense won't be suited for the gradual distribution of information. In short, for there to be querying of reputation, you need to have something worth querying.

But what does a system for querying need to address? It needs to be able to request information on demand, and receive that information quickly and efficiently. Specifically, the system needs to be able to handle any given entity in sending out a request for reputation information, and have other entities process that request and return a response. There needs to be a way for an entity to handle the likely event that there is no reputation information on another entity. Finally, the entity needs a way to process and interpret the information it receives.

As previously mentioned, in this paper, there are two primary layouts for a reputation system: hierarchical and distributed. Both of which will need to interact with each other. In a hierarchical-centralized system, there is a hierarchy of nodes who defer to each other. Any given node in the system will defer to an authority, known as its authority node. Most, if not all, reputation information will go through this node, and as far as their subordinate nodes are concerned, his 'views', or interpretation of the reputation data, will be absolute. In a distributed, peer to peer system, reputation information will be acquired from trusted peers and analyzed to determine whether to connect or not.

The actual process of querying should be fairly simple. A given entity or node in the system needs to decide if it should contact another node in the system. First, it must check its local representation of reputation data to see if it already has both enough, and up-to-date information on a node. If it does, it can move toward making a decision, which is discussed later. If however, the information needed is not already held by the node, it will need to be queried.

This brings us back to the two primary types of reputation systems, hierarchical and distributed. In a hierarchical system the process is incredibly simple: ask your superior node, and wait for a response. The superior node might have enough information on hand to decide, or it might ask its peers or superiors. Either way, the response received from the superior node will be used by the original querying node.

The distributed querying is a little more complex. The querying node will need to decide whom to ask, perhaps asking nodes it trusts if it's been operating in the reputation system for a while, or just any nearby node in general. It will perhaps ask for just a quick reputation value, or maybe a snapshot of relevant historical events. In any case, it will use the evidence collected (if any) to ultimately make a decision. In a way this node is it's own authority node.

=Making decisions=
==How do we make decisions based on reputation?==

Every entity will have its own interpretation of reputation data. There will most likely be a common set of events considered bad for essentially any system, such as one entity participating in a DDOS on another entity, the distribution of malware, and so on. Other things are more abstract and unique to certain groups. Things like distributing unverifiable claims might be considered a negative reputation event by a reputable news source, perfectly acceptable by a tabloid, and irrelevant to the average entity representing a single person's personal computer. Entities will need to decide what's important to them, most likely via a human defining which events are worth taking note of and which aren't. It is entirely possible, and likely, that different entities won't record events that other entities would consider noteworthy. It would therefore be beneficial to have multiple people using the same rule set (though not completely useless, as you can still record personal instances of these events for your own history store).

Once an entity has obtained this information, either via the regular process of dissemination, querying, or witnessing an event firsthand, it needs to make a decision. This is, ultimately, very open ended and up to each entity. For example, A very simple mechanism would be to only communicate with entities that have no negative reputation events of any kind, and that are only viewed neutrally or positively by other entities. Another would be to ignore other entities opinions, assign a weight to each type of reputation event and do a calculation based on the evidence. However these are only two options among many, there is no need for a standardized process. In short, the process and details of actually making the decision are not that important, as long as what's decided upon is something that other entities can understand. That is, using a collection of evidence that's been stored to form an opinion that other entities can query you on, and deciding whether or not and under what conditions to connect to the other entity.

<Is that the idea?> looks good - maybe wrap up the idea at the end. we'll see what Trevor has to say.
<That should tie it together but again that's only how I would do it. ie what goes in and what come out need to be standardized but what happens in the middle is completely arbitrary. Not exactly an original idea or anything.>
<Trevor: This is mostly a justice thing. We need to talk about it, but I also listed it as an assumption above. But yes, this is in general the right idea>

=Implementation=
==Can we achieve this through incremental updates?==

<possible we can... we can use imposed rules or existing infrastructure if we don't have adequate emergent information. This way we can incrementally update the system and eventually we will have a full-fledged emergent reputation system. Hope this helps someone... I don't quite know enough to write about this.>

<Trevor: Basically, phasing this in will reply on companies deciding it's in their own best interests to have this running locally, and then individuals will have to decide to use the gossip-based solution, and eventually, emergent, a cohesive system would appear.>

=Conclusion=

=References=

<references />

=DELETE=
Why PKI should be omitted
reputation must be trusted = we get this trust through interactions. We BELIEVE this trust because we assume we have attribution!

Distributed OS: Winter 2011 Reputation Systems Paper

2011-04-11T08:44:36Z

Tgelowsk:

=What is reputation?=

In the real world, people are generally quite conscious of certain behavioural actions that make. These actions are expected to fall within the social norms and are scrutinized continuously by the people around us. On a daily basis, Individuals build a personal set of judgment values and opinions on others in the society. When we listen to a politician on the news, or interact with a friends, we are updating this image that we have of the individual or group. It is this image we generate that helps us make conclusions as to whether we like the individual, whether we trust the individual, or whether we can relate to the individual. The global opinions that others have on us is known as reputation.

A reputation system's main purpose is to facilitate in providing a means for assumptions to be made about the level of trust one can have for a particular person or situation in executing a task to our liking. It is important to note the importance of the word assumption. With the gathered information, we are able to generate an estimate of their actions. It is by no means accurate. Furthermore, reputation is not a globally accepted view of an entity. In some cases, an individuals reputation can be quite varied between different observers. Some may have encountered contact with the entity in a different context or had a different level of expectation compared to others <ref name="krukow" />. Likewise, some individuals might be falsely persuaded to confirm to specific opinions by large and powerful groups, whereas others have a crystallized and hard-to-change opinion.

=How can reputation be used in a distributed environment?=

Reputation can be useful in acquiring an understanding of how congruent one's own goals are from another. If we are to accomplish a desired task that requires the cooperation of others, we carefully analyze whether the individuals we choose will be a good fit or whether they will hinder our progress. Or, worse yet, halt our progress completely.

In a more technical and distributed view, reputation is the process of recording, aggregating, and distributing information about an entity's behaviour in distributed applications. Reputation might be based on the entity's past ability to adhere to a mutual contract with another entity <ref name="krukow">Krukow K. et al. A Logical Framework for Reputation Systems and History-based Access Control. School of Electronics and Computer Science University of Southampton, UK [March 3, 2011]</ref>. As stated above, the validity of acquired reputation is largely subjective and unknown. Clearly, if we are to achieve an optimal reputation system we will need a fixed set of rules or norms that are expected to be followed in certain situations. If we look back to the analogy with human's, we are - to a fairly high degree - able to maintain order in some parts of the world by enforcing rules. It is unreasonable to think that we can prevent all wrong-doing. There are always outliers that will oppose the greater society, but eventually the greater community will overcome those outliers and prevent them from being detrimental to society. There is no perfect solution to maintaining social order in reality, and likewise, there is no perfect solution for maintaining good behaviour of computational entities.

The idea of enforcing rules or generating reputation of other entities to use in a decision-making process are both realistic options. This is known as the Emerge vs. Impose problem. Do we maintain records based on a fixed set of imposed rules? Or do we build rules as the system emerges and reputations are formed. In our opinion, we feel the answer is both.

=What systems are currently in place?=

Reputation systems are used in a wide array of projects and applications, from e-commerce sites to the web as a whole. Currently, existing distributed systems do not have an ideal reputation system in place. We will discuss two forms of existing systems. Peer-based and policy-based systems. Peer-based systems rely on emergent reputation, while policy-based systems rely on imposed rules.

Peer-based systems are ones in which end-users provide reputation information about a certain subject. Sites such as eBay and Youtube utilize rating and comment systems. Particularly, eBay uses an interaction-based form of reputation to provide information about buyers and sellers<ref name="ebayreputation">Reputation Management. Wikipedia. http://en.wikipedia.org/wiki/Reputation_management [March 28, 2011]</ref>.

Policy-based systems can be found in a variety of application frameworks. Two examples include Java and Android. These systems enforce a developer to state the intentions of the application in what's known as a policy file. The stated intentions are required as a security measure for access to crucial parts of the system<ref name="javapolicy">Default Policy Implementation and Policy File Syntax. Oracle. http://download.oracle.com/javase/1.3/docs/guide/security/PolicyFiles.html [March 7, 2011]</ref>. For mobile devices, if an application needs to acquire the GPS location or read/write contact information this must be stated in the policy file<ref name="android">Android. Google. http://developer.android.com/index.html [March 28, 2011]</ref>. Otherwise, an application cannot be deployed. Furthermore, items on this policy file are presented to the user and if a user is suspicious about an application needing access to unnecessary utilities, they can choose to not install the application. For example, a "stop-watch" application might appear extremely suspicious to a user if it requested access to contact information and internet access. Interestingly, Android and other mobile application frameworks such as iOS<ref name="ios">iOS Developer Guide. Apple. http://developer.apple.com/devcenter/ios/index.action [March 28, 2011]</ref> also use an emergent-based reputation system. They provide a means to rate and review applications similar to the buyer-seller reputation systems provided with eBay. The mentality is that if an application is untrustworthy or of poor quality, the greater public opinion will merge and polarize to negative opinions - eventually leaving the application as a non-threat to potential buyers. For trustworthy applications, the result would be quite the opposite.

==How can we improve on existing systems?==

Existing systems provide an adequate level of accurate reputation information for their purpose. For closed and centralized systems such as the example provided, eBay, this level of sophistication is sufficient. Buyers are able to favour certain sellers over others based on feedback and ratings left by previous sellers. However, to make this decision easier, these sites convert the data into a more readable and comparable form, a numerical scale. This abstraction process, however, prevents one from truly understanding the reasons behind the values. Buyers and sellers are able to bid with a fair degree of certainty and trust; if one party is unsatisfied with the transaction, eBay will step in to provide order<ref name="ebayreputation" />. This level of justice is not easily attainable in large-distributed systems. Although we can assume we have an adequate level of justice, in order for a reputation system to be plausible in such a large system and for justice systems to work, we need to store sets of event-based histories that can be attributed to each entity that interacts in the system. In the case where reputation data fails to protect machines and the individuals behind them, we can fall back on justice systems and provide them with accurate information.

=Our assumptions=

In this system, we will make a set of assumptions. Without these, a system of this size either would not function, or would be of too broad of scope to ever be acceptable.

The justice assumption is where the assumption is made that some other system or set of rules will govern when reputation information needs to be updated and exchanged. Our system will not determine when exchange of information is required, only what information should be exchanged. Similarly, since each system will likely have its own perspective on what is right and wrong, no assumption will be made that there is a single fixes set of rules governing the operation of the system of justice on the whole. This means that the system should be adaptable to different purposes without compromising the integrity of the internet at large. Two opposing systems of justice issuing opposing reputation information will eventually result in the two segments of the network ignoring the opposing information, leading to an eventual stable, if not consistent, state. This is appropriate, given the diversity of the internet at large.

In the attribution assumption it is assumed that all actions are being correctly attributed. This also includes assuming that information being exchanged between two peers can be properly sourced. Originally, a section on public-key infrastructure (PKI) was going to be included, but it was decided that this would be ultimately out of scope for this system.

In order to make sure that a system of this scale is feasible, it is necessary to make a public good assumption. This means that it will be assumed that resources are available on the whole system to maintain the reputation information necessary for the system to function. This assumption is generally valid considering the capacity of the modern internet, and the exponential growth of technology.

Finally the security in the majority assumption is made. It is assumed that in a sufficiently large system, even if a given number of nodes are currently acting maliciously, the large number of non-malicious nodes will eventually overwhelm the fraudulent messages resulting in a generally good result. It would be impossible to design a system that did not rely on this assumption, as if a majority of the nodes were acting against the general good of the system, it would fail regardless of the overall safety of the system itself.

=Generating reputation=
==How do we represent reputation?==

Reputation data can be stored in a variety of different forms and representations. We start with a summary of previous attempts in creating a solution for representing reputation. A frequently used form is one that utilizes a numerical scale for reputation. These are known as EigenTrust systems<ref name="krukow" />. In their essence, they store and aggregate data into a numerical form. These values are easy to compare and because primitive data types can be used, they require very little storage space. Despite these lucrative advantages, there are some significant negative aspects of such a system. Firstly, information is typically lost in the abstraction process. Concrete data is acquired and then converted down to a minimal form. Once this conversion is done, there is little one can do to understand the concrete data that it was generated from. In other words, this abstraction process is irreversible. Likewise, the process can result in ambiguity among data. For example, a reputation of 0 might be interpreted as having no reputation history or having an average reputation rating of 0. And, of course, as a result of the irreversibility of numerical data, we cannot return the data to its original concrete form to better understand the reasons behind the reputation.

Another interesting form of reputation is one that was proposed by Shmatikov and Talcott<ref name="krukow" />. They attributed reputation to encompass the history of entities as a set of time-stamped events. The key difference between EigenTrust and their solution is that we can store data in its concrete form. Additionally, if we modify their solution to allow for the notion of sessions, we can generate a clear view of related actions that correspond to an entity's computational session. This provides a querying entity or a justice system with crucial information to make their respective decision. Clearly, there are some ethical and privacy issues that arise from this; we tackle this issue more closely in a following section.

==How do we gather reputation?==

Gathering reputation information in these kinds of systems will generally follow a push model. When a node receives reputation information deemed important and reliable enough to be disseminated, it will then push the information to it's peers, or superiors. This system can either be automated, or policy-based.

In the case where reputation information for a given system is required the information would be queried as outlined below, then stored and/or disseminated to its peers if deemed important enough. What constitutes "important enough" will vary depending on the specific context, but either way the information would be retrieved, and stored until deemed no longer relevant, and then discarded.

==Where do we store reputation?==

Reputation information will be stored at each individual host giving every system or group of systems their own perspective. This is both appropriate, and efficient given how each system or grouping of systems is likely to have a different objective and context.

Some hosts may also, optionally, act as repositories for this information. These might be elected (in an emergent system) or imposed (in a hierarchy, or publish-subscribe model). These systems will provide a public good, in that they will become query-able repositories of information.

It would be impractical for information to be stored at every node indefinitely, and eventually given reputation entries must be discarded. When this occurs would depend on a variety of factors. First, if a piece of reputation information was requested a lot from other nodes, or it indicated an extreme state. Essentially, the more important or relevant a piece of information is, the more likely it is to be stored. This provides good localization and excellent overall reliability of information, while still allowing given systems to be forgiven.

==How do we maintain reputation?==

As stated earlier, we need to store an adequate level of information about interactions between entities. This "adequate" level can be quite large in terms of actual storage space. This brings us to the problem of how to maintain reputation history, since in a distributed system this is crucial to the scalability and success of the entire system. A solution here is to use the notion of Dynamic Model-Checking, by Havelund and Rosu<ref name="krukow" />. They came up with a way to re-evaluate stored reputation history and efficiently aggregate and combine eligible data. This can be thought of as a "reduce" function in the sense of Google's Map/Reduce algorithm<ref name="mapreduce">Dean J. et al. MapReduce: Simplified Data Processing on Large Clusters http://labs.google.com/papers/mapreduce.html [March 3, 2011]</ref>. We generate and store sets of events related to particular entities (this is an append function) and use a reduce function to minimize the storage space required. We realize, however, that some data will not be eligible to be "reduced". Significant negative reputation, for instance, such as DDoS attacks will likely need to be retained indefinitely in case justice systems need sufficient proof of a specific incident. This solution will work quite well as we maintain a sufficient amount of useful concrete information, yet still save space by merging and combining certain types of data. If we can assume that space will never be an issue or that processing time for searching through sets of reputation history items is negligible, then we would clearly not have to worry about implementing this type of "reduce" mechanism.

==How is reputation disseminated?==

The dissemination of reputation information is a core concern of reputation systems in general. This vital exchange of information is what allows these systems to function. Ideally, methods of information exchange should provide a given set of features. First, the information needs to be reliable, and this means that it needs to be as immune as possible to gaming and stored securely. Second, there needs to be good localization of the data to ensure it is where it is needed, when it is needed. Finally the system needs to be scalable and flexible. While the afore mentioned reasons form the technical requirements of the system, there is one additional non-functional requirement that must be considered: level of trust.

In general, there are three common modes of disseminating information of this type that would need to be supported in order to make a reputation system feasible: Hierarchy, Publish/Subscribe, and Peer-to-Peer.

In a hierarchy, there are pre-set, or elected nodes that are responsible for maintaining an authoritative list. A good example of this technology in practice is the domain name system (or DNS, for short). These systems allow for a great deal of control over the information in the system, at the expense of scalability and flexibility. These systems are very common in the corporate world today, and align well with organizational structure. It also means that if a flaw is detected at the information, manual intervention is possible. Unfortunately, these systems tent to be rife with single points of failure, and scalability issues. In addition, implimenting this kind of a system on an internet-scale would mean designating a single authority for all reputation information, which would form a natural bottleneck despite advances in caching. finally, there would be the issue of trust in such a system. While hierarchies are ideal where an overall system architecture is imposed and trust is mandated, they are much less palatable on the internet-scale because it would be impossible to establish a single authority that everyone would trust. Also, if there are a single sets of authorities, then there is the added issue of security. Compromising one system would taint the reputation information across the entire reputation system.

Publish/subscribe is a model of dissemination of information that relies on central repositories, which are then queried by each client when an update is needed. Common examples of these in technology include Really Simple Syndication (RSS) feeds, bulletin board systems (BBS). Outside modern technology, analogies can be drawn between the publish/subscribe model and common sources of information like newspapers, magazines, and other forms of periodicals. First the source publishes an update, and then "subscribers" can receive updates through either a push from the publisher, or a query for updates. This technology has a couple of attractive features, and has been broadly researched over the last 10 years, especially in the area of how this technique can be applied to wireless networks <ref name="wifipublishsubscribe">Gajic, B.; Riihijärvi, J.; Mähönen, P.; , "Evaluation of publish-subscribe based communication over WiMAX network," Ultra Modern Telecommunications and Control Systems and Workshops (ICUMT), 2010 International Congress on , vol., no., pp.38-43, 18-20 Oct. 2010 </ref>. Being data-centric, they can be a very helpful way of exchanging information. Unfortunately they require some kind of a fixed infrastructure in most cases, using either fixed reference points (like a base station) or elected coordinating nodes arranged in a distributed hash table (DHT) <ref name="p2ppublishsubscribe">Dongcai Shi; Jianwei Yin; Zhaohui Wu; Jinxiang Dong; , "A Peer-to-Peer Approach to Large-Scale Content-Based Publish-Subscribe," Web Intelligence and Intelligent Agent Technology Workshops, 2006. WI-IAT 2006 Workshops. 2006 IEEE/WIC/ACM International Conference on , vol., no., pp.172-175, 18-22 Dec. 2006</ref>. Unfortunately, there are some drawbacks to these technologies. Mainly it involves some pre-selected, or elected nodes that act as authorities. This creates points of failure, and means that some nodes need to trust others with their authority information. While it is entirely possible that there will be publish-subscribe components in a complete reputation system, the information from such information repositories must be interpreted within the context of the source node's reputation. This means that if a given information repository has been a source of unreliable information in the past, then its own negative reputation would likely force most other nodes to disregard the information, further diminishing the possible benefits of hosting such a repository. These types of systems also do not provide good localization of data, meaning nodes may have to search longer for relevant information leading to greater overhead and latency in the system on a whole.

Finally Peer-to-peer is, perhaps, the newest method of disseminating information. While there are many ways to exchange information in a peer-to-peer fashion, gossiping

In application, all of these methods of information dissemination would likely need to be supported in some fashion. Very few governments or organizations would be willing to support a system where they are required to accept updates from the cloud blindly, and similarly it is very unlikely that such organizations would be willing to publish or otherwise share information with the cloud at large. This means that any dissemination solution would have to be a hybrid solution allowing for the definition of fixed, strict hierarchies as well as the immensely scalable and dynamic peer-to-peer solutions. Where the line between these two will be drawn is not fixed. Some organizations may opt to make almost all information public, while others may not, and allow no external information to be published externally.

==How is reputation queried?==

Querying reputation is the problem of how one entity in a reputation system acquires reputation data on another entity in the system that it does not already have. There will need to be an established way of requesting, receiving and finally analyzing the reputation data to decide if a connection should be made or not. This needs to be done because depending on the size of the system it's highly unlikely any given entity will know about another given entity if it has never communicated with it before. In a system like the internet it is unreasonable to expect the regular process of information dissemination to provide every entity information on every other entity. It is even more unreasonable to expect an entity in the system to be able to store all this information.

In the greater scheme of a reputation system, querying assumes some systems need to already exist. There needs to be a means of authenticating messages, as to limit the spread of false information and guarantee the integrity of the system. There needs to be a way of maintaining the history of the system, so that reputation events can be recorded and accessed. There needs to be a means of dissemination, as querying in this sense won't be suited for the gradual distribution of information. In short, for there to be querying of reputation, you need to have something worth querying.

But what does a system for querying need to address? It needs to be able to request information on demand, and receive that information quickly and efficiently. Specifically, the system needs to be able to handle any given entity in sending out a request for reputation information, and have other entities process that request and return a response. There needs to be a way for an entity to handle the likely event that there is no reputation information on another entity. Finally, the entity needs a way to process and interpret the information it receives.

As previously mentioned, in this paper, there are two primary layouts for a reputation system: hierarchical and distributed. Both of which will need to interact with each other. In a hierarchical-centralized system, there is a hierarchy of nodes who defer to each other. Any given node in the system will defer to an authority, known as its authority node. Most, if not all, reputation information will go through this node, and as far as their subordinate nodes are concerned, his 'views', or interpretation of the reputation data, will be absolute. In a distributed, peer to peer system, reputation information will be acquired from trusted peers and analyzed to determine whether to connect or not.

The actual process of querying should be fairly simple. A given entity or node in the system needs to decide if it should contact another node in the system. First, it must check its local representation of reputation data to see if it already has both enough, and up-to-date information on a node. If it does, it can move toward making a decision, which is discussed later. If however, the information needed is not already held by the node, it will need to be queried.

This brings us back to the two primary types of reputation systems, hierarchical and distributed. In a hierarchical system the process is incredibly simple: ask your superior node, and wait for a response. The superior node might have enough information on hand to decide, or it might ask its peers or superiors. Either way, the response received from the superior node will be used by the original querying node.

The distributed querying is a little more complex. The querying node will need to decide whom to ask, perhaps asking nodes it trusts if it's been operating in the reputation system for a while, or just any nearby node in general. It will perhaps ask for just a quick reputation value, or maybe a snapshot of relevant historical events. In any case, it will use the evidence collected (if any) to ultimately make a decision. In a way this node is it's own authority node.

=Making decisions=
==How do we make decisions based on reputation?==

Every entity will have its own interpretation of reputation data. There will most likely be a common set of events considered bad for essentially any system, such as one entity participating in a DDOS on another entity, the distribution of malware, and so on. Other things are more abstract and unique to certain groups. Things like distributing unverifiable claims might be considered a negative reputation event by a reputable news source, perfectly acceptable by a tabloid, and irrelevant to the average entity representing a single person's personal computer. Entities will need to decide what's important to them, most likely via a human defining which events are worth taking note of and which aren't. It is entirely possible, and likely, that different entities won't record events that other entities would consider noteworthy. It would therefore be beneficial to have multiple people using the same rule set (though not completely useless, as you can still record personal instances of these events for your own history store).

Once an entity has obtained this information, either via the regular process of dissemination, querying, or witnessing an event firsthand, it needs to make a decision. This is, ultimately, very open ended and up to each entity. For example, A very simple mechanism would be to only communicate with entities that have no negative reputation events of any kind, and that are only viewed neutrally or positively by other entities. Another would be to ignore other entities opinions, assign a weight to each type of reputation event and do a calculation based on the evidence. However these are only two options among many, there is no need for a standardized process. In short, the process and details of actually making the decision are not that important, as long as what's decided upon is something that other entities can understand. That is, using a collection of evidence that's been stored to form an opinion that other entities can query you on, and deciding whether or not and under what conditions to connect to the other entity.

<Is that the idea?> looks good - maybe wrap up the idea at the end. we'll see what Trevor has to say.
<That should tie it together but again that's only how I would do it. ie what goes in and what come out need to be standardized but what happens in the middle is completely arbitrary. Not exactly an original idea or anything.>

=Implementation=
==Can we achieve this through incremental updates?==

<possible we can... we can use imposed rules or existing infrastructure if we don't have adequate emergent information. This way we can incrementally update the system and eventually we will have a full-fledged emergent reputation system. Hope this helps someone... I don't quite know enough to write about this.>

=Conclusion=
=References=

<references />

=DELETE=
Why PKI should be omitted
reputation must be trusted = we get this trust through interactions. We BELIEVE this trust because we assume we have attribution!

Distributed OS: Winter 2011 Reputation Systems Paper

2011-04-09T22:37:27Z

Tgelowsk: /* How is reputation disseminated? */

DistOS-2011W Reputation

2011-03-29T17:50:49Z

Tgelowsk:

==Members==
* Waheed Ahmed
* Trevor Gelowsky
** MSN: Gelowt@gmail.com
** E-Mail: tgelowsk@sce.carleton.ca
* Michael Du Plessis
* Nicolas Lessard (nick.lessard @t gmail.com / nlessard @t carleton.connect.ca)

==Our presentation==
Our current presentation can be viewed at the following link: https://docs.google.com/present/edit?id=0AbY-UrFwVEEVZHgyZmJoel8yMmhkZzI3aGM1&hl=en&authkey=CIDatKoH

==Our Paper==

Our final paper can be found here: [[Distributed OS: Winter 2011 Reputation Systems Paper]]

==The problem==
* Emerge vs. Impose reputation on the system?
** Probably both, how do we account for both systems?
* Where do you store the data?
* Where is the data queried from?
* What defines good/bad reputation?
* Who provides the good/bad reputation?
* Who do we trust for this information?
* Should reputation be mutable? Can we be pardoned, or can reputations be reversed?
* What entities are able to contribute to reputations?
* How do we access reputation about entities?
* Who is authorized to access particular reputations? How much to reveal? (Information flow)

==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==

In our paper we must explain why PKI/Authentication fits into reputation. Why must it be handled by both Attribution and Reputation systems?

===Problems===

===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 :In order to use certificates for S/MIME signed/encrypted email, the users’ email address must be in the certificate. Most people change their email addresses more frequently than the certificate. Unless a solution is built which allows users to keep the same email address over a long period, certificates would have to be re-issued every time a user changes email address. S/MIME v.3 stipulates that the receiving application must check the From: or Sender: field in the mail header and compare it to an email address in the sender’s certificate. If the check does not match, the mail application should perform another explicit check to ensure that the person who signed the message is indeed the person who sent it. As usual, the ‘devil is in the detail’ when it comes to implementation.

*Certificate Validity Checking:CRLs have been the conventional method of providing certificate validity checking. CRLs do not scale very well as discussed earlier, but are usually kept for backward compatibility, archiving/historical verification and for use in off-line mode. The other issue with CRLs is that they are generally issued at certain intervals of 6, 12 or 24 hours, causing a time lag from the time a certificate is revoked until it appears on the published CRL. This may present a security risk, as a certificate may verify correctly after it has been reported as compromised and revoked; (however some would argue that the time from actual compromise until the discovery and reporting of it would in most cases be a more significant lag). The Online Certificate Status Protocol (OCSP) (RFC2560) allows a client to query an OCSP responder for the current status of a certificate. This saves searching through a large CRL and can save bandwidth if the CRL would normally be downloaded - although it may increase network traffic. Most OCSP responders are based on CRLs and thus do not solve the problem of time lag as outlined above.

*Availability and storage of reliable user information : For an identity certificate scheme, names in certificates need to be unique, meaningful - and correct. Few large user communities have all their member details in a central and accurate database or directory, and the exercise of consolidating, checking and updating all user data can turn into a massive and expensive exercise.

*Archiving/historic verification : Digital signatures need to be verifiable even after the keys used to sign have expired. Likewise, we need to be able to verify that the certificate was valid at the time the datawas signed. This means we would need to archive: the signed file,the public key certificate of the signer, the CRL that was valid at the time of signing, a reliable timestamp to prove the accuracy of the time of signing and, the hardware environment that can run the software that was used at the time

==Dissemination==

===The Problem Domain===

===Random Ramblings on Reputation Management and Distribution===

Publish/Subscribe?

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:
* http://ieeexplore.ieee.org.proxy.library.carleton.ca/xpls/abs_all.jsp?arnumber=4537308 "Reputation management in distributed systems"

Examples are as follows:
* http://ieeexplore.ieee.org.proxy.library.carleton.ca/xpls/abs_all.jsp?arnumber=4228013 "Gossip-based Reputation Aggregation for Unstructured Peer-to-Peer Networks"
* http://ieeexplore.ieee.org.proxy.library.carleton.ca/xpls/abs_all.jsp?arnumber=5569965 "Improving Accuracy and Coverage in an Internet-Deployed Reputation Mechanism"
* http://ieeexplore.ieee.org.proxy.library.carleton.ca/xpls/abs_all.jsp?arnumber=4459326 "GossipTrust for Fast Reputation Aggregation in Peer-to-Peer Networks"
* http://ieeexplore.ieee.org.proxy.library.carleton.ca/xpls/abs_all.jsp?arnumber=4777496 "Adaptive trust management in P2P networks using gossip protocol"

Another possibility is using "Reputation chains"
* http://dx.doi.org.proxy.library.carleton.ca/10.1109/TKDE.2009.45 "P2P Reputation Management Using Distributed Identities and Decentralized Recommendation Chains"

==Maintaining History==

===Problem domain===

* Emerge vs. Impose reputation on the system?
** Probably both, how do we account for both systems?
*** Do we maintain records based on a fixed set of imposed rules? Or do we build rules as the system emerges and reputations are formed?
* Where do you store the data?
** Distributed storage systems. Reputation in real-life is stored in interactions that an entity has with others. Reputation is not stored centrally. Reputation is most often a shared view of an entity by the masses, but sometimes an entities reputation can be disjoint among the masses: many different entities having differing views of reputation for the same entity.
* Where is the data queried from?
** (should I mention this?)
* What defines good/bad reputation?
** (should I mention this?)
* Who provides the good/bad reputation?
** Impose/Emerge problem: reputation for an interaction can be calculated immediately or can be a function of time.
* Who do we trust for this information?
** Trusting the masses is generally a good way of ensuring trustworthiness. Imposed rules will not always fit every situation well - could potentially set bad reputation to a "good" entity.
* Should reputation be mutable? Can we be pardoned, or can reputations be reversed?
** Do we maintain an ever-growing set of history items for interactions between entities? Do we look focus on the bad reputations?
* What entities are able to contribute to reputations?
* How do we access reputation about entities?
* Who is authorized to access particular reputations? How much to reveal? (Information flow)

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

Immutable data structure
Who could add data?
Who could remove data?
Authority

===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) [http://www.brics.dk/~krukow/research/publications/online_papers/concrete-jcs.pdf]

====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 fulﬁlled 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
eﬃcient dynamic algorithms for checking whether a particular behaviour
satisﬁes a property from the language. It is shown how the framework can
be extended in several ways, most notably to encompass parameterized
events and quantiﬁcation 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) [http://books.google.ca/books?id=ybzS-yylJfAC&lpg=PA822&ots=V7hn_RzqXA&dq=maintaining%20history%20in%20reputation%20systems&pg=PA822#v=onepage&q=maintaining%20history%20in%20reputation%20systems&f=false]

====Abstract====

* Bolton, G. et al. How Effective are Electronic Reputation Mechanisms? (March 10, 2011) [http://ccs.mit.edu/dell/reputation/BKOMSsub.pdf]

====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==

=== Problems ===

* Emerge vs. Impose reputation on the system?
** Probably both, how do we account for both systems?
***If you want to know someone's reputation, you either need to start asking around for it, imposing yourself. Or you need the data to be sent around, so you already have access to it; emergent.
* Where do you store the data?
***You need to know who has the data to ask them for it, or to go get it yourself.
* Where is the data queried from?
***First you need to know who's storing it. then you need to know if you're allowed to ask that node directly, do you ask a intermediary keeper of data. Will you even need to Query-- that is, do you already have all you need to know on hand? you need not get the latest updates on a node if every other node who's ever talked to it got DDOSed. (or do you?)
* What defines good/bad reputation?
***Should I make my own definition for bad reputation, and query if someone engaged in activities I consider bad, or should their be a global agreed upon reputation?
* Who provides the good/bad reputation?
***Who should I ask for information from?
* Who do we trust for this information?
***Whoever you trust, presumably their opinion on a given node is more important then a node you trust less.
* Should reputation be mutable? Can we be pardoned, or can reputations be reversed?
***topically, would you bother asking for 10 year old reputation data on a node, if it's been a model citizen for the last 9?
* What entities are able to contribute to reputations?
***Should I ask everyone I trust for an opinion on a given node, or just certain keepers of trust data?
* How do we access reputation about entities?
***You query someone in the know who you trust and are allowed to query.
***you could say, ask everyone you know and trust, and ask them to ask people they know and trust, (and so on...if they're willing) until you find a node with the information you need.
***in a more centralized system you need to ask some kind of keeper of information for the information you want, and that keeper may or may not provide you with the reputation info you want.
* Who is authorized to access particular reputations? How much to reveal? (Information flow)
***The ability to control this would depend on how centralized a system you have. In a truly distributed system where every node has an opinion on any other node they've talked to you'll be able to find somebody who can tell you about the CIA node, but in a more centralized system the keepers of information might be less...willing to give Joe 6 cores information on who Iran is DDOSing.

===Maybe 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==
==Implementation Requirements==
==Conclusion==

==References==
* Joel Weise : "Public Key Infrastructure Overview " http://www.sun.com/blueprints/0801/publickey.pdf Accessed 2nd March 2011

* Security Glossary : http://www.cafesoft.com/support/security-glossary.html Accessed on 2nd March 2011

* Mattila, Anssi; and Mattila, Minna "What is the Effect of Product Attributes on Public-Key Infrastructure adoption? " http://internetjournals.net/journals/tir/2006/January/Paper%2003.pdf Accessed on 2nd March 2011

*Electronic Commerece Conference , PKI Sub-Group , Issue Paper : http://www.defense.gov/dodreform/ecwg/pki.pdf date accessed 5th March 2011

*SANS Institute InfoSec Reading Room, Common issues in PKI implementations - climbing the Slope of Enlightenment : http://www.sans.org/reading_room/whitepapers/authentication/common-issues-pki-implementations-climbing-slope-enlightenment_1198 date accessed 15th March 2011

DistOS-2011W Distributed File System Security

2011-03-18T13:50:44Z

Tgelowsk:

=Distributed File System Security=

COMP 5102 - Distributed Operating Systems

Trevor Gelowsky (100657001)

March 1st, 2011

==Abstract==
This paper provides an overview on how data security is maintained both in traditional distributed file systems, and cloud-based systems. It begins by providing background information on distributed file systems, and then continues with a series of examples of how the data is secured. Finally, an overview of a new system providing not only data, but computational security is discussed.

==An Introduction to Distributed File System Security==
Distributed file systems are a core part of modern distributed operating systems. Without them, it would be impossible to catalogue, sort, or access the huge volumes of data required by distributed systems conveniently. Similarly, they facilitate high-performance computing (HPC) in a way not possible before the advent of distributed file systems.

There are numerous examples of distributed file system in use today. These include the Google File System (GFS) [1]⁠, Lustre[2]⁠, Parallel Virtual File System Version 2 (PVFS2) [3]⁠, and The Global File System (GFS) [4]⁠, Kosmos File System (KFS), and Hadoop[5]⁠. Each of these are designed to provide high-availability, and scalability.

With the advent of distributed file systems, however, there is the added issue of security. It is no longer the case where it is necessarily possible for all data to exist within a walled garden. Now it is possible for a single file system to be spread among multiple cloud or grid computing services (such as Amazon S3, among many others). This has necessitated the creation higher levels of abstraction which are capable of operating on a much larger scale, and with a higher level of security than traditional distributed file systems.

So how do modern distributed filing systems provide guarantees of data security, and what mechanisms of authentication are used to safeguard data? To answer these questions, this paper will explore this evolving field of study, drawing in examples from existing solutions.

==The Scope of This Paper==

This literature review will be focusing on the various aspects of distributed filing systems, and how they address the core issue of security. Background material will be provided for the sake of clarity where required, but it will be assumed that the basic underlying concepts of distributed file systems are well understood.

This paper will begin with a discussion of the basic commercially available distributed file systems, and their built-in features, and then continue with the common systems built on top of these to provide or enhance the security features of the underlying distributed filing system.

Like the field of distributed file systems itself, the area of security is quite diverse, and for that reason this paper will focus on a few key examples highlighting the variety, and promenade types of solutions available for solving the problems of distributed file system security, and distributed computation in general.

==Distributed File System Security==

Distributed file system security can be provided in two ways. The first is to have some kind of an authentication and security layer built-in to the file system itself. Examples of these include Lustre [2]⁠, Panasas, Parallel Virtual File System Version 2 (PVFS2), and the Redhat Global File System (RGFS) [6]⁠. These systems typically consider security among their primary concerns, and therefore take great care to provide a mechanism to authenticate and protect access to data.

Alternatively, many distributed filing systems, such as the Google File System (GFS), Kosmos File System (KFS), and Hadoop, posses no built-in security mechanism[6]⁠. It is assumed in these cases that the nodes and clients in the system are trusted and secure. To extend the functionality of these systems a number of solutions have been developed in order to create a trusted, and secure computing environment based on these insecure distributed filing systems.

===File Systems with a Dedicated Security Mechanism===

The vast majority of distributed file systems that include built-in security mechanisms rely on a trusted storage-area network (SAN) with UNIX-like permissions (user/group) being used to manage the access of data via one or more coordinating nodes [3,4,6]⁠. These systems rely on the trusted nodes in the network to provide access to data in the way they best see fit.

There are two notable exceptions, however, which provides authentication in a much finer-grained way using a more advanced request authentication system: The Andrew File System (AFS), and The Lustre file system, and its descendants.

====Network File System====

The Network File System protocol (NFS) [7]⁠ was introduced as a way of providing distributed file system services. Until version 4, however, security was not a concern, and it followed a largely UNIX-based security scheme that was user and group centric. As of NFS version 4, however, it became more heavily influenced by alternative systems that were now available (including the Andrew File System below) and introduced a more comprehensive security scheme [8]⁠. In addition, many security layers have been created that use NFS as a back-end for low-level storage[9]⁠.

====The Andrew File System====

The Andrew File System (AFS) [10]⁠ behaves a lot like it's predecessor, NFS, except in that it uses a series of Access Control Lists (ACL) [11]⁠ to govern access to files. It does this by employing the Kerberos authentication mechanism [12]⁠ to apply a fine-grained security properties to data being stored in the distributed file system. This system, however, does not mandate the use of system-wide encryption.

====The Lustre Distributed File System====

The Lustre file system bases its security around the popular Public Key Infrastructure (PKI)[2]⁠, and Kerberos [12]⁠. This is similar to the AFS, and allows for fine-grained security profiles to be applied to every piece of data stored in the system. Like many distributed file systems, it divides information into to categories: Data, and Metadata. Data is stored in Lustre Object Storage Targets (OST), while metadata is stored in Metadata Servers (MDS).

In order to provide security, Lustre grants access to data in a four-step process. Fist the user requests information from the Metadata Server (MDS). Second, the MDS authenticates the request using the Public Key Infrastructure (PKI). Next, the MDS transmits data to the OST required, and the client granting access to the information. Finally, the OST and the client connect directly with the OST validating the request before sending data to the client.

This system effectively prevents replay attacks, data interception, and client identity theft. Since all communication between nodes in this system is encrypted, data security is guaranteed.

==Cloud-Based and Other Security Mechanisms==

Given the lack of built-in support for securing data in many common distributed filing system, it's unsurprising that higher-level systems have been developed in order to provide data security. These systems tend to be based around cloud storage [13]⁠. Cloud storage differs from traditional distributed file systems in that from the perspective of the system there is no hardware concerns, and it is expected that the provider of the cloud storage will provide all the required replication, reliability, and backup. Cloud storage does not traditionally provide faculties to manage security.

====Provable Data Possession and Proof of Retrievability====

Provable Data Possession (PDP) [14]⁠ is a scheme used to verify that the underlying storage mechanism possesses the original copy of the data stored on it, without modification, by storing a set of metadata separately in a client store. This metadata utilizes a homomorphic verifiable tag generated from a probabilistic sampling of the resource in question. This scheme means that tampering of the underlying file can be detected.

A fully homomorphic tag ensures that it can be recomputed without needing to reveal the encryption key itself [15]⁠. In a PDP system, this allows the tags computed for multiple file blocks can be combined into one value. This value can then be challenged randomly by clients at any time without having to actually retrieve the block of data in question.

Proof of Retrievability (POR) [16]⁠ builds on the idea of PDP by adding spot-checking and error-correcting codes that guarantee both possession and retrievability of the data stored on the underlying file system [17]⁠.

===Attribute-Based Encryption===

There is a relatively new style of security being introduced into modern distributed file systems known as Attribute-Based Encryption (ABE) [18]⁠. These systems, unlike more central systems that rely on some kind of an ACL, are identity-based and encrypt objects based on the attributes required to access those objects. The required cryptographic keys are maintained and managed separately. In addition, these schemes are collision-resistant. This solved the problems of distributed and cloud storage by ensuring that the underlying storage mechanism does not ever have access to the unencrypted data.

To phrase it in another way, if only administrators should be able to access a given resource, then the administrator attribute would become a part of the encryption key for the resource, so you would require at least that attribute to access the information. Users lacking that attribute would be unable to access the data.

===SecCloud: Secure Storage and Computation===

This system takes things one step further than just securing the data on the storage-end of things. SecCloud is a system that attempts to address both the concerns in secure cloud storage, and secure computation [17]⁠. It accomplished this by incorporating many of the same concepts as PDP and POR, extending them with an auditing scheme based on a probabilistic sampling technique to further increase overall data security.

This is extended by adding in a hash tree based commit scheme. Once the commit is completed, the result is then challenged, and verified ensuring not only the completion of the commit, but also verifies that the request was completed[17]⁠.

==Conclusion==

In this paper the central issues surrounding the security of distributed filing systems were discussed. As with most non-trivial areas of computer science, the correct solution for any problem will vary greatly based on the individual requirements that any system is required to meet. For many systems, it may be perfectly acceptable to assume that no security is adequate, whereas with others a great deal of time and resources may be allocated to ensuring that the data being stored in these petabyte-scaled systems remains secure.

==References==

[1] S. Ghemawat, H. Gobioff, and S.-T. Leung, “The Google file system,” ACM SIGOPS Operating Systems Review, vol. 37, Dec. 2003, p. 29.

[2] S.-qin Liu, X.-sheng Li, J. Shuo, J. Wang, and H.-hui Liu, Lustre Security Mechanism: Models, Schemes and Research Based on PKI, IEEE, 2010.

[3] J.M. Kunkel and T. Ludwig, “Performance Evaluation of the PVFS2 Architecture,” 15th EUROMICRO International Conference on Parallel, Distributed and Network-Based Processing (PDPʼ07), Feb. 2007, pp. 509-516.

[4] S. Soltis, G. Erickson, K. Preslan, and T. Ruwart, “The Global File System: A file system for shared disk storage,” IEEE Transactions on Parallel and Distributed Systems, vol. 1, 1997, p. 1.

[5] J. Shafer, S. Rixner, and A.L. Cox, “The Hadoop distributed filesystem: Balancing portability and performance,” Performance Analysis of Systems & Software (ISPASS), 2010 IEEE International Symposium on, IEEE, 2010, p. 122–133.

[6] T.D. Thanh, S. Mohan, E. Choi, S. Kim, and P. Kim, “A Taxonomy and Survey on Distributed File Systems,” 2008 Fourth International Conference on Networked Computing and Advanced Information Management, Sep. 2008, pp. 144-149.

[7] B. Callaghan, B. Pawlowski, and P. Staubach, “RFC 1813: NFS version 3 protocol specification, June 1995,” See also RFC1094 [Sun89]. Status: Informational, 1995, pp. 1-127.

[8] B. Callaghan, D. Robinson, and R. Thurlow, “Network File System (NFS) version 4 Protocol,” 2003, pp. 1-276.

[9] R. Pletka and C. Cachin, “Cryptographic Security for a High-Performance Distributed File System,” 24th IEEE Conference on Mass Storage Systems and Technologies (MSST 2007), Sep. 2007, pp. 227-232.

[10] R. Tobbicke, “Distributed file systems: focus on Andrew File System/Distributed File Service (AFS/DFS),” Proceedings Thirteenth IEEE Symposium on Mass Storage Systems. Toward Distributed Storage and Data Management Systems, 1994, pp. 23-26.

[11] S.V. Nagaraj, “Access control in distributed object systems: problems with access control lists,” Enabling Technologies: Infrastructure for Collaborative Enterprises, 2001. WET ICE 2001. Proceedings. Tenth IEEE International Workshops on, IEEE, 2002, p. 163–164.

[12] B.C. Neuman and T. Tsʼo, “Kerberos: an authentication service for computer networks,” IEEE Communications Magazine, vol. 32, 1994, pp. 33-38.

[13] J. Wu, L. Ping, X. Ge, Y. Wang, and J. Fu, “Cloud Storage as the Infrastructure of Cloud Computing,” 2010 International Conference on Intelligent Computing and Cognitive Informatics, Jun. 2010, pp. 380-383.

[14] G. Ateniese, R. Burns, R. Curtmola, J. Herring, L. Kissner, Z. Peterson, and D. Song, “Provable data possession at untrusted stores,” Proceedings of the 14th ACM conference on Computer and communications security, New York, New York, USA: ACM, 2007, p. 598–609.

[15] C. Gentry, “A fully homomorphic encryption scheme,” Stanford University, 2009.

[16] K.D. Bowers, A. Juels, and A. Oprea, “Proofs of retrievability: Theory and implementation,” Proceedings of the 2009 ACM workshop on Cloud computing security, ACM, 2009, p. 43–54.

[17] L. Wei, H. Zhu, Z. Cao, and W. Jia, “SecCloud: Bridging Secure Storage and Computation in Cloud,” 2010 IEEE 30th International Conference on Distributed Computing Systems Workshops, Jun. 2010, p. xxxix-xl.

[18] M. Pirretti, P. Traynor, P. McDaniel, and B. Waters, “Secure attribute-based systems,” Proceedings of the 13th ACM conference on Computer and communications security - CCS ’06, 2006, p. 99.

DistOS-2011W Reputation

2011-03-15T18:14:37Z

Tgelowsk: /* Random Ramblings on Reputation Management and Distribution */

==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==

===Problems===

===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==

===The Problem Domain===

===Random Ramblings on Reputation Management and Distribution===

Publish/Subscribe?

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:
* http://ieeexplore.ieee.org.proxy.library.carleton.ca/xpls/abs_all.jsp?arnumber=4537308 "Reputation management in distributed systems"

Examples are as follows:
* http://ieeexplore.ieee.org.proxy.library.carleton.ca/xpls/abs_all.jsp?arnumber=4228013 "Gossip-based Reputation Aggregation for Unstructured Peer-to-Peer Networks"
* http://ieeexplore.ieee.org.proxy.library.carleton.ca/xpls/abs_all.jsp?arnumber=5569965 "Improving Accuracy and Coverage in an Internet-Deployed Reputation Mechanism"
* http://ieeexplore.ieee.org.proxy.library.carleton.ca/xpls/abs_all.jsp?arnumber=4459326 "GossipTrust for Fast Reputation Aggregation in Peer-to-Peer Networks"
* http://ieeexplore.ieee.org.proxy.library.carleton.ca/xpls/abs_all.jsp?arnumber=4777496 "Adaptive trust management in P2P networks using gossip protocol"

Another possibility is using "Reputation chains"
* http://dx.doi.org.proxy.library.carleton.ca/10.1109/TKDE.2009.45 "P2P Reputation Management Using Distributed Identities and Decentralized Recommendation Chains"

==Maintaining History==

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

Immutable data structure
Who could add data?
Who could remove data?
Authority

===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) [http://www.brics.dk/~krukow/research/publications/online_papers/concrete-jcs.pdf]

====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 fulﬁlled 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
eﬃcient dynamic algorithms for checking whether a particular behaviour
satisﬁes a property from the language. It is shown how the framework can
be extended in several ways, most notably to encompass parameterized
events and quantiﬁcation 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) [http://books.google.ca/books?id=ybzS-yylJfAC&lpg=PA822&ots=V7hn_RzqXA&dq=maintaining%20history%20in%20reputation%20systems&pg=PA822#v=onepage&q=maintaining%20history%20in%20reputation%20systems&f=false]

====Abstract====

* Bolton, G. et al. How Effective are Electronic Reputation Mechanisms? (March 10, 2011) [http://ccs.mit.edu/dell/reputation/BKOMSsub.pdf]

====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==
* Joel Weise : "Public Key Infrastructure Overview " http://www.sun.com/blueprints/0801/publickey.pdf Accessed 2nd March 2011

* Security Glossary : http://www.cafesoft.com/support/security-glossary.html Accessed on 2nd March 2011

* Mattila, Anssi; and Mattila, Minna "What is the Effect of Product Attributes on Public-Key Infrastructure adoption? " http://internetjournals.net/journals/tir/2006/January/Paper%2003.pdf Accessed on 2nd March 2011

*Electronic Commerece Conference , PKI Sub-Group , Issue Paper : http://www.defense.gov/dodreform/ecwg/pki.pdf date accessed 5th March 2011

DistOS-2011W Reputation

2011-03-15T18:11:26Z

Tgelowsk: /* Guaranteeing Authenticity/Public Key Infrastructure */

==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==

===Problems===

===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==

===The Problem Domain===

===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:
* http://ieeexplore.ieee.org.proxy.library.carleton.ca/xpls/abs_all.jsp?arnumber=4537308 "Reputation management in distributed systems"

Examples are as follows:
* http://ieeexplore.ieee.org.proxy.library.carleton.ca/xpls/abs_all.jsp?arnumber=4228013 "Gossip-based Reputation Aggregation for Unstructured Peer-to-Peer Networks"
* http://ieeexplore.ieee.org.proxy.library.carleton.ca/xpls/abs_all.jsp?arnumber=5569965 "Improving Accuracy and Coverage in an Internet-Deployed Reputation Mechanism"
* http://ieeexplore.ieee.org.proxy.library.carleton.ca/xpls/abs_all.jsp?arnumber=4459326 "GossipTrust for Fast Reputation Aggregation in Peer-to-Peer Networks"
* http://ieeexplore.ieee.org.proxy.library.carleton.ca/xpls/abs_all.jsp?arnumber=4777496 "Adaptive trust management in P2P networks using gossip protocol"

Another possibility is using "Reputation chains"
* http://dx.doi.org.proxy.library.carleton.ca/10.1109/TKDE.2009.45 "P2P Reputation Management Using Distributed Identities and Decentralized Recommendation Chains"

==Maintaining History==

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

Immutable data structure
Who could add data?
Who could remove data?
Authority

===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) [http://www.brics.dk/~krukow/research/publications/online_papers/concrete-jcs.pdf]

====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 fulﬁlled 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
eﬃcient dynamic algorithms for checking whether a particular behaviour
satisﬁes a property from the language. It is shown how the framework can
be extended in several ways, most notably to encompass parameterized
events and quantiﬁcation 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) [http://books.google.ca/books?id=ybzS-yylJfAC&lpg=PA822&ots=V7hn_RzqXA&dq=maintaining%20history%20in%20reputation%20systems&pg=PA822#v=onepage&q=maintaining%20history%20in%20reputation%20systems&f=false]

====Abstract====

* Bolton, G. et al. How Effective are Electronic Reputation Mechanisms? (March 10, 2011) [http://ccs.mit.edu/dell/reputation/BKOMSsub.pdf]

====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==
* Joel Weise : "Public Key Infrastructure Overview " http://www.sun.com/blueprints/0801/publickey.pdf Accessed 2nd March 2011

* Security Glossary : http://www.cafesoft.com/support/security-glossary.html Accessed on 2nd March 2011

* Mattila, Anssi; and Mattila, Minna "What is the Effect of Product Attributes on Public-Key Infrastructure adoption? " http://internetjournals.net/journals/tir/2006/January/Paper%2003.pdf Accessed on 2nd March 2011

*Electronic Commerece Conference , PKI Sub-Group , Issue Paper : http://www.defense.gov/dodreform/ecwg/pki.pdf date accessed 5th March 2011

DistOS-2011W Reputation

2011-03-15T18:05:44Z

Tgelowsk: /* Dissemination */

==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==

===The Problem Domain===

===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:
* http://ieeexplore.ieee.org.proxy.library.carleton.ca/xpls/abs_all.jsp?arnumber=4537308 "Reputation management in distributed systems"

Examples are as follows:
* http://ieeexplore.ieee.org.proxy.library.carleton.ca/xpls/abs_all.jsp?arnumber=4228013 "Gossip-based Reputation Aggregation for Unstructured Peer-to-Peer Networks"
* http://ieeexplore.ieee.org.proxy.library.carleton.ca/xpls/abs_all.jsp?arnumber=5569965 "Improving Accuracy and Coverage in an Internet-Deployed Reputation Mechanism"
* http://ieeexplore.ieee.org.proxy.library.carleton.ca/xpls/abs_all.jsp?arnumber=4459326 "GossipTrust for Fast Reputation Aggregation in Peer-to-Peer Networks"
* http://ieeexplore.ieee.org.proxy.library.carleton.ca/xpls/abs_all.jsp?arnumber=4777496 "Adaptive trust management in P2P networks using gossip protocol"

Another possibility is using "Reputation chains"
* http://dx.doi.org.proxy.library.carleton.ca/10.1109/TKDE.2009.45 "P2P Reputation Management Using Distributed Identities and Decentralized Recommendation Chains"

==Maintaining History==

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

Immutable data structure
Who could add data?
Who could remove data?
Authority

===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) [http://www.brics.dk/~krukow/research/publications/online_papers/concrete-jcs.pdf]

====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 fulﬁlled 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
eﬃcient dynamic algorithms for checking whether a particular behaviour
satisﬁes a property from the language. It is shown how the framework can
be extended in several ways, most notably to encompass parameterized
events and quantiﬁcation 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) [http://books.google.ca/books?id=ybzS-yylJfAC&lpg=PA822&ots=V7hn_RzqXA&dq=maintaining%20history%20in%20reputation%20systems&pg=PA822#v=onepage&q=maintaining%20history%20in%20reputation%20systems&f=false]

====Abstract====

* Bolton, G. et al. How Effective are Electronic Reputation Mechanisms? (March 10, 2011) [http://ccs.mit.edu/dell/reputation/BKOMSsub.pdf]

====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==
* Joel Weise : "Public Key Infrastructure Overview " http://www.sun.com/blueprints/0801/publickey.pdf Accessed 2nd March 2011

* Security Glossary : http://www.cafesoft.com/support/security-glossary.html Accessed on 2nd March 2011

* Mattila, Anssi; and Mattila, Minna "What is the Effect of Product Attributes on Public-Key Infrastructure adoption? " http://internetjournals.net/journals/tir/2006/January/Paper%2003.pdf Accessed on 2nd March 2011

*Electronic Commerece Conference , PKI Sub-Group , Issue Paper : http://www.defense.gov/dodreform/ecwg/pki.pdf date accessed 5th March 2011

DistOS-2011W Reputation

2011-03-15T17:13:52Z

Tgelowsk: /* Guaranteeing Authenticity */

==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:
* http://ieeexplore.ieee.org.proxy.library.carleton.ca/xpls/abs_all.jsp?arnumber=4537308 "Reputation management in distributed systems"

Examples are as follows:
* http://ieeexplore.ieee.org.proxy.library.carleton.ca/xpls/abs_all.jsp?arnumber=4228013 "Gossip-based Reputation Aggregation for Unstructured Peer-to-Peer Networks"
* http://ieeexplore.ieee.org.proxy.library.carleton.ca/xpls/abs_all.jsp?arnumber=5569965 "Improving Accuracy and Coverage in an Internet-Deployed Reputation Mechanism"
* http://ieeexplore.ieee.org.proxy.library.carleton.ca/xpls/abs_all.jsp?arnumber=4459326 "GossipTrust for Fast Reputation Aggregation in Peer-to-Peer Networks"
* http://ieeexplore.ieee.org.proxy.library.carleton.ca/xpls/abs_all.jsp?arnumber=4777496 "Adaptive trust management in P2P networks using gossip protocol"

Another possibility is using "Reputation chains"
* http://dx.doi.org.proxy.library.carleton.ca/10.1109/TKDE.2009.45 "P2P Reputation Management Using Distributed Identities and Decentralized Recommendation Chains"

==Maintaining History==

===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) [http://www.brics.dk/~krukow/research/publications/online_papers/concrete-jcs.pdf]

====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 fulﬁlled 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
eﬃcient dynamic algorithms for checking whether a particular behaviour
satisﬁes a property from the language. It is shown how the framework can
be extended in several ways, most notably to encompass parameterized
events and quantiﬁcation 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) [http://books.google.ca/books?id=ybzS-yylJfAC&lpg=PA822&ots=V7hn_RzqXA&dq=maintaining%20history%20in%20reputation%20systems&pg=PA822#v=onepage&q=maintaining%20history%20in%20reputation%20systems&f=false]

====Abstract====

* Bolton, G. et al. How Effective are Electronic Reputation Mechanisms? (March 10, 2011) [http://ccs.mit.edu/dell/reputation/BKOMSsub.pdf]

====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==
* Joel Weise : "Public Key Infrastructure Overview " http://www.sun.com/blueprints/0801/publickey.pdf Accessed 2nd March 2011

* Security Glossary : http://www.cafesoft.com/support/security-glossary.html Accessed on 2nd March 2011

* Mattila, Anssi; and Mattila, Minna "What is the Effect of Product Attributes on Public-Key Infrastructure adoption? " http://internetjournals.net/journals/tir/2006/January/Paper%2003.pdf Accessed on 2nd March 2011

*Electronic Commerece Conference , PKI Sub-Group , Issue Paper : http://www.defense.gov/dodreform/ecwg/pki.pdf date accessed 5th March 2011

DistOS-2011W Reputation

2011-03-15T17:13:19Z

Tgelowsk: /* Public-key infrastructure */

==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==

===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:
* http://ieeexplore.ieee.org.proxy.library.carleton.ca/xpls/abs_all.jsp?arnumber=4537308 "Reputation management in distributed systems"

Examples are as follows:
* http://ieeexplore.ieee.org.proxy.library.carleton.ca/xpls/abs_all.jsp?arnumber=4228013 "Gossip-based Reputation Aggregation for Unstructured Peer-to-Peer Networks"
* http://ieeexplore.ieee.org.proxy.library.carleton.ca/xpls/abs_all.jsp?arnumber=5569965 "Improving Accuracy and Coverage in an Internet-Deployed Reputation Mechanism"
* http://ieeexplore.ieee.org.proxy.library.carleton.ca/xpls/abs_all.jsp?arnumber=4459326 "GossipTrust for Fast Reputation Aggregation in Peer-to-Peer Networks"
* http://ieeexplore.ieee.org.proxy.library.carleton.ca/xpls/abs_all.jsp?arnumber=4777496 "Adaptive trust management in P2P networks using gossip protocol"

Another possibility is using "Reputation chains"
* http://dx.doi.org.proxy.library.carleton.ca/10.1109/TKDE.2009.45 "P2P Reputation Management Using Distributed Identities and Decentralized Recommendation Chains"

==Maintaining History==

===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) [http://www.brics.dk/~krukow/research/publications/online_papers/concrete-jcs.pdf]

====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 fulﬁlled 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
eﬃcient dynamic algorithms for checking whether a particular behaviour
satisﬁes a property from the language. It is shown how the framework can
be extended in several ways, most notably to encompass parameterized
events and quantiﬁcation 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) [http://books.google.ca/books?id=ybzS-yylJfAC&lpg=PA822&ots=V7hn_RzqXA&dq=maintaining%20history%20in%20reputation%20systems&pg=PA822#v=onepage&q=maintaining%20history%20in%20reputation%20systems&f=false]

====Abstract====

* Bolton, G. et al. How Effective are Electronic Reputation Mechanisms? (March 10, 2011) [http://ccs.mit.edu/dell/reputation/BKOMSsub.pdf]

====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==
* Joel Weise : "Public Key Infrastructure Overview " http://www.sun.com/blueprints/0801/publickey.pdf Accessed 2nd March 2011

* Security Glossary : http://www.cafesoft.com/support/security-glossary.html Accessed on 2nd March 2011

* Mattila, Anssi; and Mattila, Minna "What is the Effect of Product Attributes on Public-Key Infrastructure adoption? " http://internetjournals.net/journals/tir/2006/January/Paper%2003.pdf Accessed on 2nd March 2011

*Electronic Commerece Conference , PKI Sub-Group , Issue Paper : http://www.defense.gov/dodreform/ecwg/pki.pdf date accessed 5th March 2011

DistOS-2011W Reputation

2011-03-15T14:34:33Z

Tgelowsk: /* Members */

==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?==

==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

==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:
* http://ieeexplore.ieee.org.proxy.library.carleton.ca/xpls/abs_all.jsp?arnumber=4537308 "Reputation management in distributed systems"

Examples are as follows:
* http://ieeexplore.ieee.org.proxy.library.carleton.ca/xpls/abs_all.jsp?arnumber=4228013 "Gossip-based Reputation Aggregation for Unstructured Peer-to-Peer Networks"
* http://ieeexplore.ieee.org.proxy.library.carleton.ca/xpls/abs_all.jsp?arnumber=5569965 "Improving Accuracy and Coverage in an Internet-Deployed Reputation Mechanism"
* http://ieeexplore.ieee.org.proxy.library.carleton.ca/xpls/abs_all.jsp?arnumber=4459326 "GossipTrust for Fast Reputation Aggregation in Peer-to-Peer Networks"
* http://ieeexplore.ieee.org.proxy.library.carleton.ca/xpls/abs_all.jsp?arnumber=4777496 "Adaptive trust management in P2P networks using gossip protocol"

Another possibility is using "Reputation chains"
* http://dx.doi.org.proxy.library.carleton.ca/10.1109/TKDE.2009.45 "P2P Reputation Management Using Distributed Identities and Decentralized Recommendation Chains"

==Maintaining History==

===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) [http://www.brics.dk/~krukow/research/publications/online_papers/concrete-jcs.pdf]

====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 fulﬁlled 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
eﬃcient dynamic algorithms for checking whether a particular behaviour
satisﬁes a property from the language. It is shown how the framework can
be extended in several ways, most notably to encompass parameterized
events and quantiﬁcation 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) [http://books.google.ca/books?id=ybzS-yylJfAC&lpg=PA822&ots=V7hn_RzqXA&dq=maintaining%20history%20in%20reputation%20systems&pg=PA822#v=onepage&q=maintaining%20history%20in%20reputation%20systems&f=false]

====Abstract====

* Bolton, G. et al. How Effective are Electronic Reputation Mechanisms? (March 10, 2011) [http://ccs.mit.edu/dell/reputation/BKOMSsub.pdf]

====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==
* Joel Weise : "Public Key Infrastructure Overview " http://www.sun.com/blueprints/0801/publickey.pdf Accessed 2nd March 2011

* Security Glossary : http://www.cafesoft.com/support/security-glossary.html Accessed on 2nd March 2011

* Mattila, Anssi; and Mattila, Minna "What is the Effect of Product Attributes on Public-Key Infrastructure adoption? " http://internetjournals.net/journals/tir/2006/January/Paper%2003.pdf Accessed on 2nd March 2011

*Electronic Commerece Conference , PKI Sub-Group , Issue Paper : http://www.defense.gov/dodreform/ecwg/pki.pdf date accessed 5th March 2011

DistOS-2011W Reputation

2011-03-10T14:38:42Z

Tgelowsk: /* Members */

==Members==
* Waheed Ahmed
* Trevor Gelowsky
** MSN: Gelowt@gmail.com
** E-Mail: tgelowsk@sce.carleton.ca
** Current Status: Snowed-in somewhere in the outskirts of Orleans...
* Michael Du Plessis
* Nicolas Lessard

==The problem==
Emerge vs. Impose reputation on the system
==What currently exists?==
* Digital signatures
** Certificates signed by trusted organizations
==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.

==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:
* http://ieeexplore.ieee.org.proxy.library.carleton.ca/xpls/abs_all.jsp?arnumber=4537308 "Reputation management in distributed systems"

Examples are as follows:
* http://ieeexplore.ieee.org.proxy.library.carleton.ca/xpls/abs_all.jsp?arnumber=4228013 "Gossip-based Reputation Aggregation for Unstructured Peer-to-Peer Networks"
* http://ieeexplore.ieee.org.proxy.library.carleton.ca/xpls/abs_all.jsp?arnumber=5569965 "Improving Accuracy and Coverage in an Internet-Deployed Reputation Mechanism"
* http://ieeexplore.ieee.org.proxy.library.carleton.ca/xpls/abs_all.jsp?arnumber=4459326 "GossipTrust for Fast Reputation Aggregation in Peer-to-Peer Networks"
* http://ieeexplore.ieee.org.proxy.library.carleton.ca/xpls/abs_all.jsp?arnumber=4777496 "Adaptive trust management in P2P networks using gossip protocol"

Another possibility is using "Reputation chains"
* http://dx.doi.org.proxy.library.carleton.ca/10.1109/TKDE.2009.45 "P2P Reputation Management Using Distributed Identities and Decentralized Recommendation Chains"

==Maintaining History==

===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) [http://www.brics.dk/~krukow/research/publications/online_papers/concrete-jcs.pdf]

* Khosrow-Pour, M. Emerging trends and challenges in information technology management (March 7, 2011) [http://books.google.ca/books?id=ybzS-yylJfAC&lpg=PA822&ots=V7hn_RzqXA&dq=maintaining%20history%20in%20reputation%20systems&pg=PA822#v=onepage&q=maintaining%20history%20in%20reputation%20systems&f=false]

==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==
* Joel Weise : "Public Key Infrastructure Overview " http://www.sun.com/blueprints/0801/publickey.pdf Accessed 2nd March 2011

* Security Glossary : http://www.cafesoft.com/support/security-glossary.html Accessed on 2nd March 2011

* Mattila, Anssi; and Mattila, Minna "What is the Effect of Product Attributes on Public-Key Infrastructure adoption? " http://internetjournals.net/journals/tir/2006/January/Paper%2003.pdf Accessed on 2nd March 2011

DistOS-2011W Reputation

2011-03-10T14:27:15Z

Tgelowsk: /* Members */

==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
==What currently exists?==
* Digital signatures
** Certificates signed by trusted organizations
==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.

==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:
* http://ieeexplore.ieee.org.proxy.library.carleton.ca/xpls/abs_all.jsp?arnumber=4537308 "Reputation management in distributed systems"

Examples are as follows:
* http://ieeexplore.ieee.org.proxy.library.carleton.ca/xpls/abs_all.jsp?arnumber=4228013 "Gossip-based Reputation Aggregation for Unstructured Peer-to-Peer Networks"
* http://ieeexplore.ieee.org.proxy.library.carleton.ca/xpls/abs_all.jsp?arnumber=5569965 "Improving Accuracy and Coverage in an Internet-Deployed Reputation Mechanism"
* http://ieeexplore.ieee.org.proxy.library.carleton.ca/xpls/abs_all.jsp?arnumber=4459326 "GossipTrust for Fast Reputation Aggregation in Peer-to-Peer Networks"
* http://ieeexplore.ieee.org.proxy.library.carleton.ca/xpls/abs_all.jsp?arnumber=4777496 "Adaptive trust management in P2P networks using gossip protocol"

Another possibility is using "Reputation chains"
* http://dx.doi.org.proxy.library.carleton.ca/10.1109/TKDE.2009.45 "P2P Reputation Management Using Distributed Identities and Decentralized Recommendation Chains"

==Maintaining History==

===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) [http://www.brics.dk/~krukow/research/publications/online_papers/concrete-jcs.pdf]

* Khosrow-Pour, M. Emerging trends and challenges in information technology management (March 7, 2011) [http://books.google.ca/books?id=ybzS-yylJfAC&lpg=PA822&ots=V7hn_RzqXA&dq=maintaining%20history%20in%20reputation%20systems&pg=PA822#v=onepage&q=maintaining%20history%20in%20reputation%20systems&f=false]

==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==
* Joel Weise : "Public Key Infrastructure Overview " http://www.sun.com/blueprints/0801/publickey.pdf Accessed 2nd March 2011

* Security Glossary : http://www.cafesoft.com/support/security-glossary.html Accessed on 2nd March 2011

* Mattila, Anssi; and Mattila, Minna "What is the Effect of Product Attributes on Public-Key Infrastructure adoption? " http://internetjournals.net/journals/tir/2006/January/Paper%2003.pdf Accessed on 2nd March 2011

DistOS-2011W Reputation

2011-03-07T21:57:33Z

Tgelowsk: /* Dissemination */

==Members==
* Waheed Ahmed
* Trevor Gelowsky
* Michael Du Plessis
* Nicolas Lessard

==The problem==
Emerge vs. Impose reputation on the system
==What currently exists?==
* Digital signatures
** Certificates signed by trusted organizations
==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.

==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:
* http://ieeexplore.ieee.org.proxy.library.carleton.ca/xpls/abs_all.jsp?arnumber=4537308 "Reputation management in distributed systems"

Examples are as follows:
* http://ieeexplore.ieee.org.proxy.library.carleton.ca/xpls/abs_all.jsp?arnumber=4228013 "Gossip-based Reputation Aggregation for Unstructured Peer-to-Peer Networks"
* http://ieeexplore.ieee.org.proxy.library.carleton.ca/xpls/abs_all.jsp?arnumber=5569965 "Improving Accuracy and Coverage in an Internet-Deployed Reputation Mechanism"
* http://ieeexplore.ieee.org.proxy.library.carleton.ca/xpls/abs_all.jsp?arnumber=4459326 "GossipTrust for Fast Reputation Aggregation in Peer-to-Peer Networks"
* http://ieeexplore.ieee.org.proxy.library.carleton.ca/xpls/abs_all.jsp?arnumber=4777496 "Adaptive trust management in P2P networks using gossip protocol"

Another possibility is using "Reputation chains"
* http://dx.doi.org.proxy.library.carleton.ca/10.1109/TKDE.2009.45 "P2P Reputation Management Using Distributed Identities and Decentralized Recommendation Chains"

==Maintaining History==
==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''

==Possible implementations==
==Conclusion==

==References==
* Joel Weise : "Public Key Infrastructure Overview " http://www.sun.com/blueprints/0801/publickey.pdf Accessed 2nd March 2011

* Security Glossary : http://www.cafesoft.com/support/security-glossary.html Accessed on 2nd March 2011

* Mattila, Anssi; and Mattila, Minna "What is the Effect of Product Attributes on Public-Key Infrastructure adoption? " http://internetjournals.net/journals/tir/2006/January/Paper%2003.pdf Accessed on 2nd March 2011

* 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) [http://www.brics.dk/~krukow/research/publications/online_papers/concrete-jcs.pdf]

DistOS-2011W Distributed File System Security

2011-03-02T05:29:49Z

Tgelowsk:

The full PDF can be found [http://www.megaupload.com/?d=C1YA0WPS here].

=Abstract=
This paper provides an overview on how data security is maintained both in traditional distributed file systems, and cloud-based systems. It begins by providing background information on distributed file systems, and then continues with a series of examples of how the data is secured. Finally, an overview of a new system providing not only data, but computational security is discussed.

DistOS-2011W Distributed File System Security

2011-03-01T02:40:07Z

Tgelowsk:

The full PDF can be found [http://www.qfpost.com/download.do?get=ca5ef89d58f567e899f4a04da89d5c8a here].

=Abstract=
This paper provides an overview on how data security is maintained both in traditional distributed file systems, and cloud-based systems. It begins by providing background information on distributed file systems, and then continues with a series of examples of how the data is secured. Finally, an overview of a new system providing not only data, but computational security is discussed.

DistOS-2011W Distributed File System Security

2011-03-01T02:14:17Z

Tgelowsk: Created page with "=Abstract= This paper provides an overview on how data security is maintained both in traditional distributed file systems, and cloud-based systems. It begins by providing backg…"

=Abstract=
This paper provides an overview on how data security is maintained both in traditional distributed file systems, and cloud-based systems. It begins by providing background information on distributed file systems, and then continues with a series of examples of how the data is secured. Finally, an overview of a new system providing not only data, but computational security is discussed.

Distributed OS: Winter 2011

2011-03-01T02:12:59Z

Tgelowsk: /* Literature review paper (graduate students) */

==Evaluation==

Grades in this class will be determined based on the following criteria.

Undergraduate Students:
* 20% Class participation
* 20% Wiki participation
* 10% Group project oral presentation (April 5th in class)
* 30% Group project written report (Due April 11th)
* 20% Implementation report (Due March 1st)

Graduate Students:
* 15% Class participation
* 20% Wiki participation
* 10% Group project oral presentation (April 5th in class)
* 30% Group project written report (Due April 11th)
* 25% Literature review paper (Due March 1st)

Proposals for Implementation reports & Literature reviews should be emailed to Prof. Somayaji by '''February 1st'''.

===Implementation report (undergrads)===

An implementation report is a 5-10 page paper that either
# describes in detail one existing software system with distributed OS-like properties,
# compare and contrasts an important characteristic of 3 or more software systems with distributed OS-like properties, or
# reports on experiences setting up and using a software system with distributed OS-like properties.
Topics for an implementation report must be approved by Prof. Somayaji.

Implementation reports for Winter 2011:
* [[DistOS-2011W NTP |NTP]]
* [[DistOS-2011W Globus |Globus Toolkit]]
* [[DistOS-2011W Implementation Template|Implementation Template]]
* [[DistOS-2011W BigTable|BigTable]]
* [[DistOS-2011W Cassandra and Hamachi|Cassandra and Hamachi]]
* [[DistOS-2011W Wuala |Wuala]]
* [[DistOS-2011W FWR |FWR]]
* [[DistOS-2011W Plan 9| Plan 9]]
* [[DistOS-2011W Akamai and CDN| Akamai and CDN]]
* [[DistOS-2011W Diaspora| Diaspora]]
* [[DistOS-2011W Eucalyptus |Eucalyptus]]

Students: please add your report above following the template.

===Literature review paper (graduate students)===

The literature review paper should be a 8-12 page paper that reviews research and well-known commercial work in an area of distributed operating systems research or a closely related area.

Literature Review papers for Winter 2011:
* [[DistOS-2011W Naming and Locating Objects in Distributed Systems|Naming and Locating Objects in Distributed Systems]]
* [[DistOS-2011W User Controlled Bandwidth: How Social Protocols Affect Network Protocols and Our Need for Speed|User Controlled Bandwidth]]
* [[DistOS-2011W General Purpose Frameworks for Performance-Portable Code|General Purpose Frameworks for Performance-Portable Code]]
* [[DistOS-2011W Distributed Data Structures: a survey|Distributed Data Structures: a survey]]
* [[DistOS-2011W Distributed File System Security|Distributed File System Security]]

Students: please add your paper above.

==Readings==

===January 13, 2011===
[http://keys.ccrcentral.net/ccr/writing/ CCR] (two papers)

===January 18, 2011===
[http://homeostasis.scs.carleton.ca/~soma/distos/2008-02-25/oceanstore-sigplan.pdf OceanStore] and [http://homeostasis.scs.carleton.ca/~soma/distos/2008-02-25/fast2003-pond.pdf Pond]

===February 3, 2011===

*'''[http://ieeexplore.ieee.org.proxy.library.carleton.ca/xpls/abs_all.jsp?arnumber=1450841 Robert E. Kahn, "Resource-Sharing Computer Communications Networks" (1972)]:'''
* [http://video.google.com/videoplay?docid=4989933629762859961 Computer Networks - The Heralds of Resource Sharing] (video - optional).

===February 8, 2011===

* Karlin et al. (2008), [http://dx.doi.org.proxy.library.carleton.ca/10.1016/j.comnet.2008.06.012 Autonomous security for autonomous systems].

Optional readings:

* O'Donnell (2009), [http://ieeexplore.ieee.org.proxy.library.carleton.ca/xpls/abs_all.jsp?arnumber=5350725 Prolog to A Survey of BGP Security Issues and Solutions]
* Butler et al. (2009), [http://ieeexplore.ieee.org.proxy.library.carleton.ca/xpls/abs_all.jsp?arnumber=5357585 A Survey of BGP Security Issues and Solutions]

===February 10, 2011===

* Savage et al. (2000), [http://conferences.sigcomm.org/sigcomm/2000/conf/paper/sigcomm2000-8-4.pdf Practical Network Support For IP Traceback].

===February 15, 2011===

* Satyanarayanan et al. (1990), [http://dx.doi.org.proxy.library.carleton.ca/10.1109/12.54838 Coda: a highly available file system for a distributed workstation environment].
* Ghemawat et al. (2003), [http://labs.google.com/papers/gfs.html The Google File System].

===February 17, 2011===

* Weil et al. (2006), [http://www.usenix.org/events/osdi06/tech/weil.html Ceph: A Scalable, High-Performance Distributed File System].

===March 1, 2011===
* Oda et al. (2008), [http://people.scs.carleton.ca/~soma/pubs/oda-ccs-08.pdf SOMA: Mutual Approval for Included Content in Web Pages].
* Oda & Somayaji (2008), [http://people.scs.carleton.ca/~soma/pubs/oda-asia-08.pdf Content Provider Conflict on the Modern Web].

===March 3, 2011===
Authentication
* OpenID
* non-password authentication (OTP, biometrics, graphical pass)

===Problems to Solve===
*Attack computers with almost no consequences
**DDoS
**botnets
**capture and analyze private traffic
**distribute malware
**tampering with traffic
**Unauthorized access to data and resources
**Impersonate computers, individuals, applications
**Fraud, theft
**regulate behavior

===Design Principles===
*subjects of governance: programs and computers
*bind programs and computers to humans & human organizations, but recognize binding is imperfect
*recognize that "bad" behavior is always possible. "good" behavior is enforced through incentives and sanctions.
*rules will change. Even rules for rule changes will change. Need a "living document" governing how rules are chosen and enforced.

==Scenarios==

===1: Stopping DDoS===
Group members: Seyyed, Andrew Schoenrock, Thomas McMahon, Lester Mundt, AbdelRahman, Rakhim Davletkaliyev

*Have the machine routing packets(could be ISP provider) detect suspicious packets, if the packets are signed, then those suspicious packets could be blocked,
the sender could be put on a black list.

* (AS) Stopping DDoS against files, services, programs, etc
** (AS) Have file replication built into the system (similar to OceanStore) so that files are always available from different servers
** (AS) If files are not replicated then we could have a tiered messaging system (at the top level would be OS messages) and servers could then prioritize the incoming traffic. If a given server is experiencing an overload, it could send out a distress signal to its neighbours and then distribute what it is has to them. The system should have a built-in mechanism to re-balance the overall load after something like this happens. This would then mean that any DDoS attack would result in the service being more available.
*** I like this idea of having service fallover
*** Expanding on the idea of file replication and sending distress signals to it's neighbours, I could envision a group of servers that would learn to help each other out. Lending processing and storage when they are under utilized. The would sort of form a collective, club or gang. Members who didn't contribute ( always fully utilized ) would eventually be identified and banned. It would be these other computers that the targeted server would rely on for help in this situation. However cool this is it isn' really a solution because one could suppose the attackers might utilize the same strategy to recruit additional help in there attack.

* (AS) Stopping DDoS against specific machines
** (AS) I don't think that this should be specifically addressed. I think measures introduced to guard against this will ultimately negatively impact the overall system in terms of performance.
*** I don't like the idea of sacrificing the one for the many though.
**** (AS) The main thing with what I've proposed is that the motivation behind doing a DDoS attack is completely gone (by doing one a service would either maintain or increase its overall availability). I think by eliminating the main result of a DDoS attack would mean that there would be no reason to guard against DDoS attacks on a specific machine.

*Stopping DDoS
** Many of the DDoS attacks utilize the property of anonymity. These services serve anyone who requests there service. Many DDoS attacks then ensure sufficient traffic that the computer behind the service can no longer cope. If we remove anonymity and only serve 'known' parties the spurious requests would be ignored. So we need to 'know' who our friends are.
*** This of course requires a form of unspoofable authentication unlike IP.
**** (RD) Serving only 'known' parties reduces the distribution of information, or at least its rate. I was thinking of removing anonymity on a lower level, so that any party that's not anonymous while sending a packet to your machine is considered 'known', and anything unknown (unsigned, unrepresented in some way) is blocked. So, we don't really need to 'know' who our friends are, we just need to know who aren't.
**** (RD) Another thing I had in mind is punishment in case a 'known' party participates in DDoS-attack: not punishing the owner of that machine (who probably is a victim as well), but the software or hardware in some sense.

*Stopping DDoS
** (RD) How about developing such a network topology and protocols that make DDoS attacks less efficient or harder to perform? Some sort of CAPTCHA, but for machines and protocols, to distinguish them from bots, maybe?

*Stopping DDoS
** I'm not sure what it means by stopping, I don't think we can stop DDos given the way things are currently ran, we can only block it. From my knowledge most softwares that stop DDoS do so by blocking, or even complete shut down like Mccolo.

*Stopping DDos
**One method is to use the same way of eliminating DoS by rejecting a specific rate of subsequent requests but from irrelevant sources.

*How we could stop DDoS would be to have each connection to the internet assigned to a particular identity. This identity would be used to verify who is attempting connections. The reason DDoS works is because currently, IP addresses can be spoofed. The only way to verify an identity is to request a response, but by then the damage is done. With a verified identity, connection attempts being routed can be verified during transmission, so that the request may not necessarily even reach the destination host.

Basically, we need some encryption system using keys so that as the packets are being routed, the identity of the packet's sender can be verified. Ideally the decryption would be trivial so as to prevent noticeable latency. Because an identity is verified, if there is spoofing of packets, they would be dropped during the routing. If all the identities are verified and are still attempting a DDoS attack, the attacker's identity will be traced back to the attacker.

(RD) (I think we're not looking low enough. We're trying to find a solution for this problem assuming the system that made that problem possible is still unchanged. We enforce more security by identification, encryption, etc, but the system is still problem-prone. This will allow to identify an attacker, but after the attack was started (or even finished). It's like trying to eliminate theft from a society of poor, unemployed, uneducated people by enforcing more security and punishment. Which will help to reduce the rate and motivation, but can't stop the possible attack. It is pretty stupid analogy, but rather than policing that society, I want to make them rich, employed and educated, so that thefts are just not efficient way of getting goods for them. So, rather than protecting machines from attacks, I want to make the system where DDoS-attacks are just inappropriate.)

===2: Stopping phishing===
Group members: Waheed Ahmed, Nicolas Lessard, Raghad Al-Awwad, Tarjit Komal

* A way of automatically checking the signature of a message to make sure it really is from a trusted source.
** ie: "Nation of Banks, did your member TD send me a message to reset my password?"

*There should be filters to ensure where the message is coming from.If the message is coming from unknown source , it should be blocked.
*Don't use the links in an email to get to any web page, if you suspect the message might not be authentic.
*Avoid filling out forms in email messages that ask for personal financial information. Phishers can make exact forms which you can find on financial institution.
*Make is so a machine needs to be authorized to use your information -- A machine that you don't own can't use your information to do anything, regardless of whether he has it or not.
*Ensure that any website that requires the filling of personal information be a secure website which can be traced to the original organisation.
*Ensure that whatever browser you are using is up to date with the most recent security patches applied.
*Obviously, report and suspected phishing to the appropriate authorities so that proper action can be taken
*"three strikes and you're out"
**Each machine is responsible for the massages it releases. When a machine is a repeat offender it loses access privileges
*Revamp the security login process to something similar to:
**User enters username and clicks next.
**Server returns a user predefined image to the User.
**If image is the right image then user enters password to logon.

===3: Limiting the spread of malware===
Group members: keith, Andrew Luczak, David Barrera, Trevor Gelowsky, Scott Lyons
*(KM) Heterogenous systems - it is much easier to write code to attack a single type of system
*(KM) Individualized security policies
**(AL) A baseline security level would help prevent malware spreading to/from a system with "individual non-security"
*(KM) Identify all programs through digital signatures
*(KM) Peer rating system for programs, customize security policies based on peer ratings
**(SL) Need some way to keep rating system from being "gamed"
***(AL) Maybe a program gets flagged if it experiences a rapid approval increase?
**(AL) Need to protect against benign programs with good ratings being updated into malware
*(KM) System level forensics on program execution and resource/file modification
*(KM) Customizable user and program blacklists
*(SL) Sandboxing with breach management - know what files have been modified by a process
*(SL) Trending - what does the application spend most of its time doing?

*(DB)Multiple control/chokepoints where malware is looked for. This way, it's more difficult for attackers to take over several control points and for malware to remain unnoticed.
*(DB)Heterogeneous systems help limit the spread of malware too. There's 2 points here. (1) If we're designing this system where we're all masters of our own domains, then we're likely to have different system configurations. However (2), if we want to communicate and interact with other domains, we need some standardized communication layer or mechanism. Standardization is very closely tied to homogeneous.
*(DB)There should be consequences if you harbor malware or if malware originates from within your domain. This could be and incentive to help people be more proactive in terms of security.

===4: Bandwidth hogs===
Group members: Mike Preston, Fahim Rahman, Michael Du Plessis, Matthew Chou, Ahmad Yafawi

*limit bandwidth for each user
*if user has significant bandwidth demands for a certain period of time
**add them to a watch list
**monitor their behaviour
**divert communication to other hosts that can satisfy requests.
***if there are no other hosts that can satisfy the request, then distribute data to other idle and capable hosts. Load is now reduced on the one link.
*QoS
*Tiered Bandwidth Distribution
**The main idea is you get more bandwidth to your machine as much as you give back to the community.
***It's similar to some trackers and dark net programs in which they wont increase your download speed unless you contribute X amount of Bytes back to your peers.
**Tier 1, Basic privileges i.e. all machines have minimal bandwidth.
**Tier n, we define some requirements to be met then we increase bandwidth accordingly.
***Drop a Tier if machine doesn't maintain the specified requirements of that specific tier.
***Advantage, monitoring bandwidth on the network is cheap while implementing what is stated above is not.
*As a metaphor to our "real world society", bandwidth control can be treated as we do speed for cars.
**Certain areas need more free flowing traffic, so speed limits are increased. Others require a slower pace which is enforced. These "areas" can be translated to users or programs in our distributed OS model
**There are repercussions to breaking any of these imposed limits
**Throttling provides once possible implementation of these constraints

====Bandwidth Hog Additional Sources and Information====
1. [http://repository.lib.ncsu.edu/ir/bitstream/1840.16/1197/1/etd.pdf A Solution to Bandwidth Hogs in a Cable Network]
*Starting at page 120 of this thesis is a proposed solution to bandwidth hogs on a cable network. In general, the proposal suggests a solution essentially equal to throttling however I did find the description of the solution to be helpful. I feel it may go well with our tiered suggestion if we were to keep the "earned trust" approach to bandwidth access but at the same time allow users in low congestion times to go above their tier. For example, if congestion is low, why not allow the people on the network to occupy much larger bandwidths. On the network include some form of monitoring protocol which can decide how much access a user is allowed. If more bandiwdth is available, let them have it if it is needed for their request. On the other hand, if congestion is high, the user will be capped at the upper limit of their bandwidth capacity if they are doing something that requires a large amount of bandwidth. In this manner each user will be guaranteed the amount they have earned at their tier, however if they do not want to earn a higher level for high usage timeframes they can instead opt to make use of low congestion timeframes and run their bandwidth heavy applications at that time. The network could also include live data regarding the current bandwidth usage levels as well as trending data so that people can plan when to start bandwidth heavy applications.

2. [http://yuba.stanford.edu/rcp/flowCompTime-dukkipati.pdf Why Flow-Completion Time is the Right Metric for Congestion Control]
*This is a short article which raises an interesting question related to our topic, how should we determine what is considered "bandwidth hogging". For example, do we look at the strain on the network in some capacity (i.e. dropped packets, usage level of the capacity of the pipe,etc.) which is important information for those who build the network; or do we make use of the time it takes for some transaction to occur when a user requests it? This article argues that from a user's point of view, they do not care how much bandwidth they get as long as the task they are requesting is completed as quickly as possible. In our discussion in class we had talked about how majority of people currently do not require large bandwidth needs for normal transactions ( email, web searching, wikis ;-) ), and a much smaller percentage of the population are the ones who actually eat up the larger bandwidth through hog-like applications. Maybe instead of focusing on the bandwidth as the main issue, we should think about how long it takes to complete tasks. Maybe our tiered system would also incorporate some aspect of this train of thought, i.e. people who only send email and surf the web are at tier one, people who use online storage and FTP are on level 2, people who stream movies and other data are at level 3, etc. Then, we could have each tier cost a separate amount and apply some form of control on the technologies available at each tier so that the restrictions of a tier are adhered to.

3. [http://research.microsoft.com/en-us/people/asellen/pap0209-chetty.pdf Who’s Hogging The Bandwidth?: The Consequences Of Revealing The Invisible In The Home]
*This article is from Micrsoft reasearch and it is an interesting look into controlling bandwidth usage by providing people with a tool to monitor the usage and alter how bandwidth is allocated. This tool essentially boils down to the social control idea that we discussed in class. If you know that your neighbours are hogging the bandwidth for very low priority issues then should you not be able to appeal to their conscience in order to gain usage of resources you need? The article provides some examples of homes they provided this control to and how the household politcs factored into the usage of the bandwidth. When usage was no longer hidden it seems as though it became easier to openly discuss how to divide the finite amount of bandwidth. Initial concerns revolved around people just hogging the bandwidth for themselves or playing practical jokes on others in the house by reducing their usage when they were in the middle of some task. Another issue that this type of control brings up is how to prioritize what tasks are "more important". One example given was if a Skype call to family and friends is more important than watching YouTube videos for a work related task. Interestingly the field studies provided some other examples of a "bandwidth etiqutte" that emerged. For example, it was considered very rude to limit somone's bandwidth when he/she was on a Skype call due to the immediate and negative effect but it was deemed acceptable to limit bandwidth during a file transfer as it just meant a few extra minutes for the transfer to complete.

Talk:Distributed OS: Winter 2011

2011-01-20T13:07:08Z

Tgelowsk: /* 3: Limiting the spread of malware */

===3: Limiting the spread of malware===
Group members: keith, Andrew, David Barrera, Trevor Gelowsky

Ideas:
*Multiple control/chokepoints where malware is looked for. This way, it's more difficult for attackers to take over several control points and for malware to remain unnoticed.
*Heterogeneous systems help limit the spread of malware too. There's 2 points here. (1) If we're designing this system where we're all masters of our own domains, then we're likely to have different system configurations. However (2), if we want to communicate and interact with other domains, we need some standardized communication layer or mechanism. Standardization is very closely tied to homogeneous.
*There should be consequences if you harbor malware or if malware originates from within your domain. This could be and incentive to help people be more proactive in terms of security.

System Proposal (TG):

In this case, what exactly do we look for? Malware is just another piece of software, especially in an internet-scale operating system. "Attackers" are just users with malicious intent.

My idea (continuing the countries analogy) is that every piece of software would execute with a "passport" representing key information about the software executing. At this point, based on the "passport" information, domains can deny or limit the ability of software to interact. For example, if a user runs an application, then their "stamp", along with their domain "stamp" and system "stamp" would become a part of that application's passport. Any domain or system can reference the signature's origin and verify it's authenticity (think of public key encryption, but every domain/person/system has its own key server). If a part of the passport is fraudulent or unverifiable then the communication or work can be rejected. If one system becomes a source of malware, then that system, user, or domain passport "stamp" can be rejected. The more legitimate "stamps" a piece of software has, the more trusted the software may be. Every domain can decide which passport stamps to accept, and which to reject. Even if a portion of a passport is fraudulent, the fraud can be detected and the information regarding untrusted passport information can be circulated between trusted peer domains. This proposed system would inherently prevent malware from spreading, because after a piece of malware was discovered, it's passport could be rejected. A continued source of malware could also be rejected.

Talk:Distributed OS: Winter 2011

2011-01-20T03:06:19Z

Tgelowsk: /* 3: Limiting the spread of malware */

===3: Limiting the spread of malware===
Group members: keith, Andrew, David Barrera, Trevor Gelowsky

Ideas:
*Multiple control/chokepoints where malware is looked for. This way, it's more difficult for attackers to take over several control points and for malware to remain unnoticed.
*Heterogeneous systems help limit the spread of malware too. There's 2 points here. (1) If we're designing this system where we're all masters of our own domains, then we're likely to have different system configurations. However (2), if we want to communicate and interact with other domains, we need some standardized communication layer or mechanism. Standardization is very closely tied to homogeneous.
*There should be consequences if you harbor malware or if malware originates from within your domain. This could be and incentive to help people be more proactive in terms of security.

System Proposal:

In this case, what exactly do we look for? Malware is just another piece of software, especially in an internet-scale operating system. "Attackers" are just users with malicious intent.

My idea (continuing the countries analogy) is that every piece of software would execute with a "passport" representing key information about the software executing. At this point, based on the "passport" information, domains can deny or limit the ability of software to interact. For example, if a user runs an application, then their "stamp", along with their domain "stamp" and system "stamp" would become a part of that application's passport. Any domain or system can reference the signature's origin and verify it's authenticity (think of public key encryption, but every domain/person/system has its own key server). If a part of the passport is fraudulent or unverifiable then the communication or work can be rejected. If one system becomes a source of malware, then that system, user, or domain passport "stamp" can be rejected. The more legitimate "stamps" a piece of software has, the more trusted the software may be. Every domain can decide which passport stamps to accept, and which to reject. Even if a portion of a passport is fraudulent, the fraud can be detected and the information regarding untrusted passport information can be circulated between trusted peer domains. This proposed system would inherently prevent malware from spreading, because after a piece of malware was discovered, it's passport could be rejected. A continued source of malware could also be rejected.

Distributed OS: Winter 2011

2011-01-20T02:40:49Z

Tgelowsk: /* 3: Limiting the spread of malware */

==Readings==

January 13, 2011: [http://keys.ccrcentral.net/ccr/writing/ CCR] (two papers)

January 18, 2011: [http://homeostasis.scs.carleton.ca/~soma/distos/2008-02-25/oceanstore-sigplan.pdf OceanStore] and [http://homeostasis.scs.carleton.ca/~soma/distos/2008-02-25/fast2003-pond.pdf Pond]

==Internet Governance==

===Problems to Solve===
*Attack computers with almost no consequences
**DDoS
**botnets
**capture and analyze private traffic
**distribute malware
**tampering with traffic
**Unauthorized access to data and resources
**Impersonate computers, individuals, applications
**Fraud, theft
**regulate behavior

===Design Principles===
*subjects of governance: programs and computers
*bind programs and computers to humans & human organizations, but recognize binding is imperfect
*recognize that "bad" behavior is always possible. "good" behavior is enforced through incentives and sanctions.
*rules will change. Even rules for rule changes will change. Need a "living document" governing how rules are chosen and enforced.

==Scenarios==

===1: Stopping DDoS===
Group members: Seyyed, Andrew Schoenrock, Thomas McMahon, Lester Mundt, AbdelRahman

*Have the machine routing packets(could be ISP provider) detect suspicious packets, if the packets are signed, then those suspicious packets could be blocked,
the sender could be put on a black list.

*Stopping DDoS against files, services, programs, etc
**Have file replication built into the system (similar to OceanStore) so that files are always available from different servers
**If files are not replicated then we could have a tiered messaging system (at the top level would be OS messages) and servers could then prioritize the incoming traffic. If a given server is experiencing an overload, it could send out a distress signal to its neighbours and then distribute what it is has to them. The system should have a built-in mechanism to re-balance the overall load after something like this happens. This would then mean that any DDoS attack would result in the service being more available.

*Stopping DDoS against specific machines
**I don't think that this should be specifically addressed. I think measures introduced to guard against this will ultimately negatively impact the overall system in terms of performance.

*Stopping DDoS
** I'm not sure what it means by stopping, I don't think we can stop DDos given the way things are currently ran, we can only block it. From my knowledge most softwares that stop DDoS do so by blocking, or even complete shut down like Mccolo.

*Stopping DDos
**One method is to use the same way of eliminating DoS by rejecting a specific rate of subsequent requests but from irrelevant sources.

*How we could stop DDoS would be to have each connection to the internet assigned to a particular identity. This identity would be used to verify who is attempting connections. The reason DDoS works is because currently, IP addresses can be spoofed. The only way to verify an identity is to request a response, but by then the damage is done. With a verified identity, connection attempts being routed can be verified during transmission, so that the request may not necessarily even reach the destination host.

Basically, we need some encryption system using keys so that as the packets are being routed, the identity of the packet's sender can be verified. Ideally the decryption would be trivial so as to prevent noticeable latency. Because an identity is verified, if there is spoofing of packets, they would be dropped during the routing. If all the identities are verified and are still attempting a DDoS attack, the attacker's identity will be traced back to the attacker.

===2: Stopping phishing===
Group members: Waheed Ahmed, Nicolas Lessard, Raghad Al-Awwad

* A way of automatically checking the signature of a message to make sure it really is from a trusted source.
** ie: "Nation of Banks, did your member TD send me a message to reset my password?"

*There should be filters to ensure where the message is coming from.If the message is coming from unknown source , it should be blocked.
*Don't use the links in an email to get to any web page, if you suspect the message might not be authentic.
*Avoid filling out forms in email messages that ask for personal financial information. Phishers can make exact forms which you can find on financial institution.

===3: Limiting the spread of malware===
Group members: keith, Andrew, David Barrera, Trevor Gelowsky
*(KM) Heterogenous systems - it is much easier to write code to attack a single type of system
*(KM) Individualized security policies
*(KM) Identify all programs through digital signatures
*(KM) Peer rating system for programs, customize security policies based on peer ratings
*(KM) System level forensics on program execution and resource/file modification
*(KM) Customizable user and program blacklists

===4: Bandwidth hogs===
Group members: Mike Preston, Fahim Rahman, Michael Du Plessis, Matthew Chou

*limit bandwidth for each user
*if user has significant bandwidth demands for a certain period of time
**add them to a watch list
**monitor their behaviour
*bandwidth management/scheduling (similar to OS scheduling)
**utilizing a round robin schedule to allow for periodic increases in bandwidth per user
**priority system that allows for more critical operations being done by a user to take precedence over others
*have the bandwidth separated evenly across all users and allow for users to donate their bandwidth amount for others to use, but can revoke it at any time