WORK IN PROGRESS, please contribute and discuss on #seeks (irc.freenode.net)
If someone looks for "clafoutis" on the net, the result found will be used if it is relevant and if the answer comes from a trusted source. Most of the time, however, the result is neither the most relevant nor does it come from the most trustworthy source. There is no truth but what we decide it is. The problem discussed in this document is how security policies are implemented in seeks and how it influences the truth defined by its users.
- Distributed systems with centralized access control are well protected against the usual DHT vulnerabilities. But the users of such systems need to accept the rules and authority of the person running the centralized access control.
- Distributed systems with no access control are vulnerable, to the extent that a single malicious computer can compromise or shutdown a ring of hundreds of nodes.
Our goal is to find tradeoffs between these two extremes so that users can use seeks effectively.
This topic needs to be addressed during the design phase of the software. The strategy chosen will have a major impact on the architecture of the software. To the extent that trying to resolve them later rather than sooner will almost certainly imply a complete rewrite.
This document is inspired by RFC 3552 that is used as an inventory of issues that must be addressed. For a commentaries that help understand the general topic, read Stéphane Bortzmeyer article on Guidelines for Writing RFC Text on Security Considerations. Two RFC have good security sections : RFC 2338 and RFC 2821.
Confidentiality means that your data is kept secret from unintended listeners.
The basic idea here is that we want to make sure that the data we receive is the same data that the sender has sent.
Peer Entity authentication
What we mean by this is that we know that one of the endpoints in the communication is the one we intended.
In general, systems security is concerned with protecting one's machines and data
Most systems are not intended to be completely accessible to the public. Rather, they are intended to be used only by certain authorized individuals. Seeks users do not have the same privileges as the seeks administrators running the software.
Denial of Service
Recall that our third goal was that the system should be available to legitimate users. A broad variety of attacks are possible which threaten such usage.
Adversary Model / Threat Model
A threat model describes the capabilities that an attacker is assumed to be able to deploy against a resource. It should contain such information as the resources available to an attacker in terms of information, computing capability, and control of the system.
The Internet environment has a fairly well understood threat model. In general, we assume that the end-systems engaging in a protocol exchange have not themselves been compromised. By contrast, we assume that the attacker has nearly complete control of the communications channel over which the end-systems communicate.
The adversaries that we consider are participants in a distributed hash lookup system that do not follow the protocol correctly. Instead, they seek to mislead legitimate nodes by providing them with false information.
When an attack involves writing data to the network, we refer to this as an Active Attack.
It exploits the fact that in a distributed system, remote entities are perceived as informational abstractions known as identities. If the system fails to guarantee that each logical identity refers to a single physical entity, an attacker could create a large number of identities and dominate the overlay network by fooling the protocols and subverting mechanisms based on redundancy.
Nodes in an overlay network have links to a few other peers commonly referred to as neighbors. If an attacker controls a sufficient fraction of the neighbors of correct nodes, then some correct nodes can be “eclipsed” by the malicious nodes. This attack is also known in the literature as routing table poisoning. An Eclipse attack can be used to facilitate other attacks, especially routing and storage attacks.
The routing portion of a lookup protocol involves maintaining routing tables, then dispatching requests to the nodes in the routing table. It is critical that routing is correct in a distributed hash table. However, there is considerable room for an adversary to play in existing systems.
- Incorrect Lookup Routing
- Incorrect Routing Updates
Storage and Retrieval Attacks
A malicious node could join and participate in the lookup protocol correctly, but deny the existence of data it was responsible for. Similarly, it might claim to actually store data when asked, but then refuse to serve it to clients.
These attacks aim at polluting the content served by Seeks and its distributed network.
An attacker would fake one / up to a very high number of user search profiles and register on many search groups. Data fragments from these profiles would then pollute the results of those search groups users (typically in the form of garbage or poisonous URLs, spam domains, ...).
CHALLENGE-RESPONSE type systems can be made secure against dictionary attack by using randomly generated shared keys instead of user-generated passwords.
Key Distribution Centers
Online "trusted third party" that mediates between the authenticating parties. The trusted third party (generally called a a KEY DISTRIBUTION CENTER (KDC)) shares a symmetric key or password witheach party in the system.
All users have CERTIFICATES which they then use to authenticate in some protocol-specific way. The signer of a certificate is a CERTIFICATE AUTHORITY (CA), whose certificate may itself be signed by some superior CA.
When requesting such a service, one has to ensure that the entity that one is talking to not only has a certificate but that that certificate corresponds to the expected identity of the server.
All users have a PGP key that is signed by at least one other user in the DHT ring.
It lies between a completely open DHT ring and a completely closed DHT ring where access is controlled by a central authority. It is good enough to ensure Debian packages security.
Ranking scheme for each seeks nodes/operators based on the number of OpenPGP signatures and their respective trust level. http://www.seas.upenn.edu/~cse400/CSE400_2005_2006/Margolis/paper.pdf http://pgp.cs.uu.nl/plot/ (can be used as a data source to validate the trust of a node operator).
The Monkeysphere project's goal is to extend OpenPGP's web of trust to new areas of the Internet to help us securely identify servers we connect to, as well as each other while we work online. http://web.monkeysphere.info/
Generic Security Frameworks
The idea is that you design a protocol that allows you to negotiate various security mechanisms in a pluggable fashion.
Authorization vs. Authentication
Authorization is the process by which one determines whether an authenticated party has permission to access a particular resource or service.
Access Control Lists
Lists users that are permitted access to a resource.
Certificate Based Systems
Presenting a valid signature does not imply authorization. The signature must be backed by a certificate chain that contains a trusted root.
Providing Traffic Security
Securely designed protocols should provide some mechanism for securing (meaning integrity protecting, authenticating, and possibly encrypting) all sensitive traffic.
They provide channel security for a TCP connection at the application level.
- http://www.springerlink.com/content/c47676782v654757/ UDT and DTLS
Denial of Service Attacks and Countermeasures
It is possible to design protocols so that denial of service attacks are made more difficult, if not impractical. Because complete DoS protection is so difficult, security against DoS must be dealt with pragmatically. In particular, some attacks which would be desirable to defend against cannot be defended against economically.
- Blind Denial of Service
- Distributed Denial of Service
- Make your attacker prove they can receive data from you
- DoS Protection for UDP-Based Protocols
- designing the protocol so that messages are small enough not to require fragmentation until a cookie is verified, and having IKE pass to the IP reassembly process a list of preferred IP addresses (those that have returned a valid cookie).
- designing the protocol so that the cookie is in the first fragment, and changing the API so that IP can pass the first fragment of an unreassembled IP packet to a process, if the process requests. Then, once IKE has verified the cookie in the first fragment, IKE will inform the reassembly process to add the IP address from which the fragment was received to its preferred list.
- designing IKE to do its own MTU discovery and fragmentation, so as not to depend on IP reassembly
- putting cookies into a new IP option, and having IKE pass the cookie-verification algorithm to IP, which will verify all fragments carrying that option
- having IKE pass the cookie-verification algorithm to IP, as well as the cookie to be carried in the packet identifier field in the IP header.
- p2p-hackers discussion
- Make your attacker do more work than you do (see example HIP)
Object vs. Channel Security
Object security refers to security measures which apply to entire data objects. Channel security measures provide a secure channel over which objects may be carried transparently but the channel has no special knowledge about object boundaries.
A user finds the answer to question Q by sending a request to the DHT node responsible for Q (the question Q is hashed into a DHT key). A malicious node may try to impersonate the node responsible for Q and return an answer that is irrelevant.
Tools and methods
- seeks security discussion on p2p-hackers mailing list
- non repudiation
- Password Sniffing
- Offline Cryptographic Attacks
In a passive attack, the attacker reads packets off the network but does not write them. A node is only able to examine packets addressed to itself. That is, malicious nodes are not able to overhear or modify communication between other nodes.
On-path versus off-path
In order for a datagram to be transmitted from one host to another, it generally must traverse some set of intermediate links and gateways.
(03:39:03 PM) beniz: autre truc dachary dans le réseau p2p, on peut aussi laisser se propager des éléments certifiés (ou pas). (03:39:24 PM) beniz: par exemple, la mise à jour des noeuds n'a pas besoin d'appeler un serveur au démarrage (comme fait FF par ex). (03:40:06 PM) beniz: au contraire, on peut faire un protocol distribué pour ça, lorsqu'un noeud intéragit avec un noeud d'une version plus récente, il peut alors engager l'utilisateur à mettre à jour. (03:40:13 PM) beniz: idem pour une liste de révocation (03:40:20 PM) beniz: ça peut se propager dans le réseau. (03:41:04 PM) beniz: c'est moins immédiat en général. Mais ça evite les 'single point of failure' aka le serveur.