Skip to content

Security

Jump to bottom Edit New page
g4jc edited this page Jul 10, 2014 · 1 revision

WORK IN PROGRESS, please contribute and discuss on #seeks (irc.freenode.net)

Table of Contents

Introduction

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.

Security considerations

Confidentiality

Confidentiality means that your data is kept secret from unintended listeners.

Data Integrity

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.

Systems Security

In general, systems security is concerned with protecting one's machines and data

Unauthorized Usage

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.

Active Attacks

When an attack involves writing data to the network, we refer to this as an Active Attack.

Sybil 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.

Eclipse attack

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.

Routing 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
  • Partition

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.

Active Pollution

These attacks aim at polluting the content served by Seeks and its distributed network.

Profile Pollution

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, ...).

Common Issues

User Authentication

Consider SASL.

Shared Keys

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.

Certificates

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.

Host Authentication

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.

Trust ring

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.

SSL/TLS

They provide channel security for a TCP connection at the application level.

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.

Types:

  • Blind Denial of Service
  • Distributed Denial of Service
Defenses:
  • Make your attacker prove they can receive data from you
    • http://en.wikipedia.org/wiki/SYN_cookies
    • 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.

Use Cases

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

References

Irrelevant

Passive 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.

Random thoughts 

 (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.
Add a custom footer
Add a custom sidebar
Clone this wiki locally