| emLib | ||||||||||||||||||||
Rodi (P2P)
|
||||||||||||||||||||
| How to... | ||||||||||||||||||||
| Message board | ||||||||||||||||||||
|
Privacy
Two different problems here
- Real 100% secured and anonymous access
- Fight intercepting equipment
Bouncers do not provide 100% anonymity, because the adversary can still attack the system using statistical analysis of response time, intercepting ALL incoming and outgoing requests from a specific node, etc. Still the concept looks good enough for many applications. Rodi uses UDP packets for both data and control messages; such as search. It can be argued that the source IP of any packet can be faked and the traffic log can not be regarded as proof that a specific host sent the packet. Let's say that adversary sends a data request to specific IP address and receives a reply - a packet containing some other IP source and the data. The Publisher of the data can argue that the data request was handled by some other node. In the real network we can bounce data requests but data transfers can still be P2P. This is very Important! We use conectionless protocol like IP. In case of IP it's enough to specify correct destination IP for data delivery. All retransmission requests are routed through the network.
Bouncers.
Let's call the publisher server P, downloader D and some
other peer B (bouncer). Let's assume also that the protocol is IP based.
P never accepts data/look requests directly from D. D sends the packet to
B with it's (D's) source IP in the IP header and in the "get data" request.
B forwards the packet to P with B's IP address in the IP header. P receives
the packet and conditionally checks that the IP source in the header is
(or is not) the same as in the request and then may check that the source
IP (IP of B) belongs to friendly host (group security server,
for example). P sends data directly to D.
Essentially the idea here is to bounce control messages but directly send the data by itself. Because the protocol is UDP based it can not be reliably proved that P published the data, because P can always argue that the IP address was spoofed by B. B has no idea about actual data transfer because it sees only the "get data" request and not the data itself. D can argue that it sent request to one peer but received (or did not receive) data from the other and the data was not what it (D) was looking for.
No one of the participants has to set IP source correctly in the IP header of the IP packet.
The only requirements that downloader sends it's correct IP address in the UDP packet payload.
Optionally payload can be signed and encrypted providing additonal layer of protection.
Bouncer and Publisher can agree upon using this or that IP address space in order to recognize each other.
Together with MD5 signature and encryption this scheme helps the publisher to work in stealth mode. Publisher
simply ignores any packets arriving from unknown IP addresses. Bouncer never see a single packet from the publisher.
And downloader never see any packet from the bouncer.
While adversary can easily find all participants - P, D and B, it is much
harder to prove that the data transfer indeed took place.
Let's say that B is adversary - it sees only data reqest.
Let's say that adversary is D - there is no proof that incoming packets
with P's IP address are indeed generated by P.
Let's say that adversary is P. D can argue that it did not receive a single packet and even more,
that D never asked for the data in first place and it is B which did the work.
Let's say that adversary runs both B and D. P can choose bouncer(s) randomly among existing peers or from list of well known
IP addresses preventing or making it unlikely for the adversary to run bouncer. P can also argue that there are more than one
bouncer participate in the data transfer and that P is only one of them.
Data transfer between downloaders and publishers can be encrypted by weak or strong enctyption making it impossible or very hard
for the analysing equipment in the middle to discover the content of the packets.
In normal scenario bouncer can only examine
control packets, not the data itself and control packets can be encrypted as well. If required by the adversary to filter the
packets containing specific information bouncer can argue that the scheme is not reliable and is not going to work, because deep
inspection of the encrypted packets even if encryption is weak can not be done in realtime.
The only way adversary can attack the network is to log traffic from all
three participants - P, D and B. One solution adversary can use is to sign
agreement with all service providers (ISPs) where ISPs are oblidged to log
the traffic from any peer upon request and request can come in real-time.
Let's say that all ISPs open access to their routers for the adversary.
While it's possible it is not easy for large scale network.
Another aplication for bouncres is centralized security server holding encryption
keys to control part of the protocol. Distinct pairs of keys can be generated
for all participants and security server is the only place where all keys
(public and/or private) are kept.
Authorization and friendly peers.
Rodi network provides key servers,
where
content publisher can post Nickname and RSA public key as part of the process of
advertising of IP range (see example of simple identification server
here)
. When sending data packets
publisher signs the packets with the private key. Downloaders or
subscribers are expected with time to learn the nickname of the publisher.
This way publisher and subscribers can create network of trust. Key servers
belong to trusted 3rd party.
Key server assures uniqueness of the nicknames
in the Rodi network. Both - name of the Rodi House and name of the peer, are unique. Rodi House
can post it's public key and all members of the House can use the same public
key when releasing content.
If key server is compromised it means that posted pairs
nickname/public key are not reliable. Downloaders who already learned and stored copy of the pair
will continue to work without disruptions. Key server does not keep any personal
information, but only range of IP addresses, nicknames and generated by the peers public keys.
Optionally publisher can receive from the key server signature encrypted with private key of the key
server. Key server signature contains nickname of the publisher, public key of the publisher and
credentials of the server, for example URL. Publisher then can attach signature information element to every
sent packet. Signature information element contains following parts
- binary part hash (MD5) of the packet
- nickname of the publisher/URL of the key server
Key server provides XML based interface to the database containing nicknames and public keys of the publishers. Rodi client can load the database and periodically check for updates.
Rodi House can run own key server(s) and provide to the publishers belonging to the house House Signature.
MD5 software speeds are adequate for most of the deployed 'last mile' connections, but can be found to be slow for next generation of high speed connections. Publishers behind fast connections can prepare signed packets and store most frequently asked data blocks in cache to improve performance. Publishers can use separate cache servers to store prepared data blocks.
Signature information element is optional if the whole payload of the UDP packet is encrypted. If signature does not contain nickname or the whole payload is encrypted downloader is expected to find corresponding public key using destination IP address and IP port to which the original request is issued.
Hash of the packet is calculated for the whole packet including signature information element where the binary part is zeroed. Publisher encrypts the resulting hash with private key, copies the encrypted hash into the signature information element and sends the packet. Publisher can attach multiple signature information elements to the packet, for example, personal signature and signature of the key server.
Publisher is free to use different private keys for different destinations. At this point it is not permitted to use different keys with the same destination node.
Rodi publisher maintains data base of private keys. Rodi client application never stores private key and requires to add private keys after every power up. Private keys can be stored in separate encrypted files. Rodi supports loading of encrypted key files using master key. User will enter master key to load private key. Important ! Rodi client application keeps the private keys in the RAM unencrypted.
Rodi downloader maintains data base of public keys. Entry of the data base contains following fields
- Publisher ID, like nick name or IP address.
- Type of the key
- Publisher public key
- Flags, for example trusted or not trusted to download data from, to upload data to, to manage the application, etc.
If Rodi client application receives signed packet and can not recognize Publisher ID and find public key the correspondent entry will be added to the log and the packet will be treated as regular unsigned packet.
Normally downloader starts to upload data to other peers immediately after the first block is downloaded and hash of the block
is checked. There are two ways to ensure integrity of the data coming from untrusted source - downloaders.
In one
scheme downloader receives table of hashes from the trusted publisher. The packet containing block(s) hash is signed by
the publisher and assumed to be authentic. Downloader compares every downloaded block with the relevant hash from the table.
In the second scheme downloader
can store (cache) received from the publisher signed blocks and upload them as required. The second scheme is probably usefull
when publisher creates dedicated network of servers to upload sensitive content. Normally MD5 is calculated for the whole packet
inlcuding
system related information elements like session ID. If cache servers are used publisher will calculate MD5 only for the data
payload (does it create a loophole in the logic ? session ID is 64 bits randomly generated key and data payload contains
block offset, but not the file hash. in different scheme publisher can zero variant fields of the packet before calculating MD5
and it is possible to define order of the information elements for MD5 calculation. More design here )
Protection.
The first priority is to protect publisher. Two
types attack are most often
- DDOS (distributed denial of service) attack
- Attack against security holes in specific application/OS
The Rodi peer generates a unique 32 bit session ID for every established connection. Also there is support for MD5 signature and different types of encryption. So it looks very unlikely that faked blocks will be sent by adversary because every block can be checked against MD5 table received directly from the publisher.
How does a downloader knows that the downloaded data came from the publisher and not from the adversary? This is where friendly bouncers come into play. When publisher advertises (for example, on a website) a new document, she specifies one or more IP addresses she (publisher) will accept as a bouncers. It would be relatively simple to support a closed community protected by strong encryption and hierarchical passwords. Such a community will typically install a security server to provide all registration/key exchange.
Loosely related notes
Rodi can provide limited routing capabilities. Optionally publisher can specify
to use a randomly generated ID (see MUTE filesharing network for details)
instead of an IP address. Client's looking for the data receive the publisher's
ID and not publisher IP address. Every client stores a routing table to
support anonymous operations and allocate part of the upstream. The rule
here is: if you don't route you don't get routing services from the neighbors.
This is also called Autonomous Reputation Scheme (ARS) or autonomous tit-for-tat
mechanism.
Also nodes can stamp the outgoing packets with arbitrary source IP (usually
it's not possible if you behind DSL/cable modems, NAT). Rodi can ignore
source IP of the packet and fetch the contact information from the payload.
Another approach to the problem of anonymous internet access is WiFi. ISP
can sell service not on monthly subscription base but pay-per-day/pay-per-hour.
For example, imagine ISP providing services in the appartment building or
in train. Customer simply buys a card with a key/coupon and pay in cash
(coupon can be printed on the train ticket). The ISP does not have to keep
billing information. MAC address and DHCP server log is the only way to
find out what desktop was using any specific IP. Even if ISP keeps DHCP
logs client can always argue that anybody could fake the MAC because MAC
address is configurable on most Ethernet cards.
| Message board |
| Home |