Tribler-team ontwikkelt app voor communicatie tussen toestellen zonder server

Johan Pouwelse, onderzoeker aan de TU Delft en oprichter van de p2p-client Tribler, heeft met zijn team een app ontwikkeld die het mogelijk maakt een wereldwijd netwerk van smartphones te creëren. Daarvoor is geen server vereist, waardoor het beter bestand is tegen aanvallen.

De app heeft de naam 'app-to-app communicator' en er is een bètaversie beschikbaar op GitHub en in de Play Store. Het doel van de app is het faciliteren van een decentraal netwerk dat alleen uit smartphones bestaat en geen infrastructuur nodig heeft, los van een basisstation. Een van de redenen voor de ontwikkeling van de software is de verplaatsing van internetgebruik van de pc naar de smartphone. Pouwelse vertelt aan Tweakers dat de app het mogelijk maakt om echte peer-to-peer-apps te bouwen: "Deze app legt daar de basis voor; de peer-to-peer-apps komen eraan!" Hij schrijft de implementatie van de app toe aan het werk van een van zijn studenten, Jaap Heijligers.

Een hindernis bij het opzetten van een dergelijk netwerk is het feit dat smartphones niet direct met elkaar kunnen communiceren, vanwege firewalls van isp's en CGN. Ook is het eigen ipv4-adres niet bekend bij het toestel zelf. De app lost dit probleem op door een techniek die bekendstaat als 'NAT puncturing' of 'udp hole punching'.

Dit werkt doordat, zodra de app is gestart, de eigen telefoon, oftewel peer A, een verbinding maakt met peer B. Dat is op dit moment nog een enkele bootstrap-telefoon die in handen is van Pouwelse, maar dat moeten er op den duur veel meer worden. Het adres van deze telefoon is aanwezig in de app. Het bootstrap-toestel stuurt een antwoord naar A en neemt daarin het adres van een willekeurige derde partij, peer C, mee. Ook bevat het antwoord een lijst met andere verbonden peers. Vervolgens stuurt B een verzoek naar C om een verbinding te maken met A, waardoor deze laatste op zijn beurt weer verbinding kan maken met C en op die manier een 'gat' geslagen heeft in zijn eigen NAT.

Deze methode stamt uit 2010 en is beschreven door TU Delft-onderzoeker Gertjan Halkes. De app identificeert verschillende peers aan de hand van een id, die bij de eerste start van de app wordt aangemaakt. Bij een conflict tussen ipv4-adressen maakt de app gebruik van voting om aan de hand van de meerderheid van 'stemmen' van de verschillende apps te bepalen welk adres bij welk toestel hoort. Het app-to-app-netwerk moet uiteindelijk bestand zijn tegen aanvallen, doordat er geen centrale server is die uitgeschakeld kan worden, bijvoorbeeld door een dos-aanval of door een 'killswitch' van een overheid.

Pouwelse stelt tegenover Tweakers: "Dit is een de zuiverste vorm van peer-to-peer, omdat iedereen gelijk is. Het is jammer dat wij zo weinig concurrentie hebben, dit project is een van de weinige dat zich hiermee bezighoudt." Het team van de onderzoeker heeft eerder andere functionaliteiten ontwikkeld, waaronder een app die zichzelf kan compileren en die door gebruikers via nfc en bluetooth verspreid kan worden. De app-to-app-functionaliteit werkt volgens Pouwelse goed samen met die eerdere ontwikkeling.

Reacties (36)

[II Stevow II]

Als ik het goed begrijp is hier nog steeds sprake van een "vaste" locatie waar het eerste request naar toe gaat, waarvan het adres wordt meegegeven in de app. (IP adres als ik in de Github source code kijk)

Dus eigenlijk werkt het gewoon net als alle andere P2P clients waarbij je aan een server vraagt welke clients er zijn en wat hun adres is. Deze server is dus nog steeds een kwetsbaarheid/potentieel zwakke schakel, omdat deze aan moet staan om de app te kunnen gebruiken. Misschien was dat voor iedereen duidelijk, maar ik kreeg het idee dat het hier om een nieuwe aanpak ging.

De enige toegevoegde waarde hieraan is dat de server in dit geval de client zijn eigen externe IP teruggeeft, omdat hij deze zelf niet weet. Voor de rest lijkt het mij gewoon een normale P2P, wellicht dat iemand mij kan vertellen of ik iets over het hoofd zie/er te makkelijk over denk?

Overigens fijn dat er bij zo'n onderzoek een Github pagina gedeeld wordt, dat maakt het voor mij in ieder geval allemaal een stuk sneller duidelijk dan alle "theorie".

[Reactie gewijzigd door II Stevow II op 22 juli 2024 20:22]

[Jaahp]

Als ik het goed begrijp is hier nog steeds sprake van een "vaste" locatie waar het eerste request naar toe gaat, waarvan het adres wordt meegegeven in de app. (IP adres als ik in de Github source code kijk)

Dat is waar, wellicht kan daar omheen gewerkt worden door een hele IP range af te scannen, maar dat is buiten de scope van dit onderzoek.

Dus eigenlijk werkt het gewoon net als alle andere P2P clients waarbij je aan een server vraagt welke clients er zijn en wat hun adres is. Deze server is dus nog steeds een kwetsbaarheid/potentieel zwakke schakel, omdat deze aan moet staan om de app te kunnen gebruiken. Misschien was dat voor iedereen duidelijk, maar ik kreeg het idee dat het hier om een nieuwe aanpak ging.

Deze toepassing verschilt met veel andere P2P toepassingen in dat de bootstrap node dezelfde app als de clients draait. Waar torrent clients bij opstarten met een centrale tracker (met zijn eigen codebase) verbinden kan hier elke andere app als bootstrap gebruikt worden.

Verder is dit project op mobiele peer to peer gefocused, dat brengt extra complicaties met zich mee.

-Jaap

[Reactie gewijzigd door Jaahp op 22 juli 2024 20:22]

[II Stevow II]

Echter moet de locatie van deze bootstrap node hard-coded meegegeven worden. Dus niet zomaar "elke" app kan als bootstrap gebruikt worden. Uiteraard zou je deze informatie in een soort Instellingen scherm kunnen plaatsen, waarbij het makkelijker in te vullen is.

Desalniettemin is dit nog steeds een mooi stukje code, wat vooral bij P2P gaming leuk toegepast kan worden. Slechts een kleine server nodig die gebruikers aan elkaar koppelt, scheelt weer in de kosten.

[leuk_he]

Ik had verwacht aan de titel dat er gebruik gemaakt ging worden van een wifi mesh netwerk. (801.11s). Maar dit klinkt gewoon als uitbreiding op bittorrent serverloos communiceren.

[synctext]

ja, het lijkt een beetje op gewoon Gnutella uit 2001.

Bootstrap kan ook met een local broadcast. Zie Shadow Internet app link op Github page.

Maar iedereen praat alleen maar over pure P2P Android-only netwerken, dit is running code. De initial bootstap server is een Nexus phone, niet echt standaard server hardware. Ook draait daar just the app.

Het vernieuwende is dat peer discovery en NAT puncturing samen met 4 message types is gemaakt. Dat maakt het eindelijk efficient en light-weight genoeg voor Android.

[biglia]

Voor de rest lijkt het mij gewoon een normale P2P, wellicht dat iemand mij kan vertellen of ik iets over het hoofd zie/er te makkelijk over denk?

Klopt, de manier van communiceren (P2P) is niet nieuw. Volgens mij is het nieuwe nu dat er een broncode (en demo App) wordt vrijgegeven die dat kan en door developers als basis kan dienen voor andere Apps die dat willen gebruiken. Blijkbaar bestond dat nog niet. Volgens mij is dat alles...

[Reactie gewijzigd door biglia op 22 juli 2024 20:22]

[hlubach]

Als leek , kan iemand mij simpel uitleggen, wat deze app doet en vooral wat kun je ermee
Vervangt het wifi o.i.d

[Flumble]

Het is bedoeld als een extra "laag" bovenop je internetverbinding om andere telefoons (maar in principe ook gewone computers en alle het andere met een internetverbinding) te vinden en mee te verbinden. Het lijkt in die zin heel veel op een groot VPN, alleen krijg je een ID in plaats van een IP-adres.
Dus nee, je hebt nog gewoon je wifi-, LAN-, 4G- of <vul in>-verbinding nodig.

Wel vervelend dat er weer zo'n initiatief "nodig" is: als de wereld nou eindelijk eens op IPv6 overstapt en geen trucjes uithaalt met het blokkeren van poorten (zoals routers dat vaak doen/deden), kan elk paar/groep telefoons gewoon een verbinding met elkaar (over het internet!) opzetten zonder tussenkomst van een speciaal programma.

[Matthijz98]

Leuk dit heb eerder al eens met een P2P app gespeeld die werkte via een wifi mesh, alleen moest je daarvoor wel je telefoon rooten
Zou leuk zij als ze ook een versie maken voor een raspberry-pi maken zodat je base station kan maken.

[synctext]

Dit willen inderdaad in de toekomst.

Niet alleen dat je wifi bandbreedte kan doneren, maar dat je ook je storage kan doneren aan underseeded Bittorrent swarms (met Tor-like hidden services seeding). (https://github.com/Trible...y-bandwidth-as-a-currency)

Onze core (Bittorrent+Tor stack+keyword search) draait op raspberry-pi, maar deze spotgoedkope CPU kan geen zware crypto aan. jammer. (https://forum.tribler.org/t/tribler-on-raspberry-pi/3549)

-johan, TU Delft.

[SwiftPengu]

Het doneren van storage klinkt erg vergelijkbaar met FreeNet, klopt dat? Maar dat is imo te traag voor filesharing boven de 50MB.

Zijn er geen crypto shields voor op raspberry's?

[bert_m]

Dit project klinkt inderdaad erg als Freenet: de gebruikte methode om het eigen IPv4-adres vast te stellen is in grote lijnen identiek, en nodes (of peers) worden geïdentificeerd middels een unieke identifier (in Freenet een identifier + een locatie), maar zoals ik het nu lees zijn er belangrijke verschillen. Freenet heeft een ingebakken storage- en routeringslaag, die nauw verweven zijn om efficiente routering van data in de door het netwerk gevormde gedistrubueerde hash-tabel te garanderen. Hier is het doel om pakketjes versleutelde data in het netwerk op te slaan en ze via een efficiënte route anoniem naar de aanvrager te kunnen versturen: de eindpunten, namelijk de (ontwetende) bezitter van de gezochte data en de aanvrager van de data, hoeven geen directe verbinding aan te gaan. Het doel van de App-to-App-communicator lijkt juist het faciliteren in directe communicatie van eindpunten. Als er ooit sprake zou zijn van het doneren van opslagruimte, zoals synctext suggereert, is er nog een overlay nodig die het routeren van deze data is goede banen leidt.

[SteveWoz]

Het doel van de app is het faciliteren van een decentraal netwerk dat alleen uit smartphones bestaat en geen infrastructuur nodig heeft, los van een basisstation.

Hoe werkt dit dan? Via de al aanwezige netwerkmogelijkheden (WiFi, nfc, Bluetooth)?

[Odie]

Met alleen een basestation heb je natuurlijk geen netwerk verbinding. Ik denk dat de schrijver van het artikel bedoelt "geen server infrastructuur behalve het mobiele netwerk waarmee de telefoon verbonden is".

[DLGandalf]

Dit gaat inderdaad over een overlay network als onderdeel van de 'app-to-app communicator'. Het onderliggende netwerk is nog steeds het internet -- en in het geval van mobieltjes zal dat vaak het netwerk v/d telco's zijn.

[wvalk]

vergeet ook hierbij niet de stun server om de initiële connectie tot stand te kunnen brengen
https://en.wikipedia.org/wiki/STUN

overigens zie ik nog wel wat uitdagingen indien de firewall strict ingesteld staat en alleen restricted cone nat toe staat

https://en.wikipedia.org/...on#Methods_of_translation

Wellicht zou een oplossing voor restricted cone nat de connectie als tunnel door B kunnen lopen waardoor communicatie van A naar C toch mogelijk is

[Reactie gewijzigd door wvalk op 22 juli 2024 20:22]

[DLGandalf]

Maar wie zegt dat ze STUN gebruiken?

[wvalk]

Wellicht een afwijking van het STUN protocol maar het princiepe blijft ongeveer het zelfde.

Er zal initieel een connectie ergens naar toe moeten. Dat is ook de rede waarom de app begint met een outgoing connection. Naderhand kunnen B en C vervangen worden door telefoons.

[synctext]

serverless. geen STUN, TURN of ICE server nodig

[wvalk]

waar is die 130.161.211.254 voor nodig dan? dus tenzij multicast ook over LTE kan (mobiele data communicatie) zal er altijd een node nodig zijn voor de initiële connectie.

Probeer de app maar met een blok in je firewall naar 130.161.211.254 en kijk dan maar of de app nog werkt.

[Reactie gewijzigd door wvalk op 22 juli 2024 20:22]

[dwilmer]

B is al een telefoon, die op Johan Pouwelse z'n bureau ligt

Als ik het goed heb begrepen wordt B niet meer een vaste telefoon, maar een willekeurige andere telefoon. Ik ben alleen benieuwd hoe ze dat voor elkaar gaan krijgen...

[EraYaN]

Desnoods kunnen ze iets met een NFC tap doen om A te vertellen wat B's adres is.

Dat kan iemand zich "simpel" aansluiten, door iemand anders te zoeken die al "lid" is. En iedere member zou zijn eigen ip adres op dat moment moeten weten en een lijst met peers die er al waren.

[Nelis123]

Het concept lijkt erg op die van ring (ring.cx) en tox (tox.chat), is er iemand die weet hoe deze applicaties en de software uit het artikel zich tot elkaar verhouden?

edit: oké, beter lezen kan geen kwaad. Ring en tox zijn chat applicaties, waar de bovenstaande software app-to-app communicator geen specifieke toepassing oplegt.

[Reactie gewijzigd door Nelis123 op 22 juli 2024 20:22]

[Rudie_V]

Dit werkt doordat, zodra de app is gestart, de eigen telefoon, oftewel peer A, een verbinding maakt met peer B. Dat is op dit moment nog een enkele bootstrap-telefoon die in handen is van Pouwelse, maar dat moeten er op den duur veel meer worden. Het adres van deze telefoon is aanwezig in de app. Het bootstrap-toestel stuurt een antwoord naar A en neemt daarin het adres van een willekeurige derde partij, peer C, mee. Ook bevat het antwoord een lijst met andere verbonden peers. Vervolgens stuurt B een verzoek naar C om een verbinding te maken met A, waardoor deze laatste op zijn beurt weer verbinding kan maken met C en op die manier een 'gat' geslagen heeft in zijn eigen NAT.

Is zo'n bootstrap telefoon dan niet eigenlijk een soort van centrale server?

[basst85]

Eigenlijk wel een beetje, zonder die bootstrap heeft de app geen startpunt en weet het ook niet met welke peers hij verbinding kan maken.

Maar waar moet hij die info anders vandaan halen?

[Martinspire]

Dat was nou juist het hele punt van de applicatie maar zo te merken hebben ze dat eigenlijk niet opgelost.

[synctext]

psies, decentrale bootstrap is mooie volgende stap.

Bijvoorbeeld wifi broadcasting gebruiken. Helaas is constant sniffen van een wifi kanaal erg duur. Dan mag je ook iedereen ook elke 4 seconden even een ping doen naar iedereen.

[SuperDre]

Yep, het is gewoon hetzelfde beestje maar een andere naam...

[Jaahp]

De bootstrap telefoon is een peer die als startpunt wordt gebruikt. Verder heeft de bootstrap wel dezelfde functionaliteit en authoriteit als andere peers.

De enige extra rol van de bootstrap peer is verbindbaar zijn, terwijl een typische server een andere taak dan de clients heeft en zelf alles regelt.

-Jaap

[YouKnow]

Interessant artikel! Met name deze quote is boeiend voor mij: "Dit is een de zuiverste vorm van peer-to-peer, omdat iedereen gelijk is. Het is jammer dat wij zo weinig concurrentie hebben, dit project is een van de weinige dat zich hiermee bezighoudt."

Er is wel concurrentie van Storro (zie ook www.storro.com; voor de duidelijkheid: daar ben ik bij betrokken). Storro houdt zich hier ook mee bezig. Ook NAT puncturing/udp hole punching. En ook nog dat je tussen smartphones en desktops/laptops/etc. kunt syncen. Storro richt zich daarentegen meer op B2B bestandsuitwisseling, en daaronder ligt 'n encryptielaag. Storro gebruikt ook deze zuivere vorm van p2p. Plus een toevoeging van git stijl revisiebeheer (met crypto audittrails) en de truecrypt stijl mounting. En alles end-to-end versleuteld uiteraard.

[Verwijderd]

Het is alleen een beetje jammer dat als je naar de ontwikkelaar CoBlue door klikt, je als grote klant de KVK ziet staan. Als een organisatie zijn IT niet op orde heeft en nooit update is het de KVK.

[mutley69]

Een mesh-netwerk dus - mooi - het bestond al - maar 't mag altijd beter, sneller en eenvoudiger. We hopen dat dit er komt - dan hebben we eindelijk een bijkomend wapen tegen afpersers die G5 maar willen brengen - als de voor ons hyperbelangrijke netwerkneutraliteit sneuvelt. Wie internet verkoopt moet die netwerkneutraliteit garanderen, anders pleegt ie gewoon bedrog - dat zit in de term internet gewoon ingebakken. Het produkt is zoals't is - non-discriminatoir. Dus elk wapen dat helpt om dat te betoneren is welkom.

[kuurtjes]

Deze chatclient zou eens wat meer zonlicht mogen krijgen: https://tox.chat/
Ik draai er zelfs een node voor.

[kuurtjes]

Waarom zeg je dat?

[infernal_nl]

Excuus, verkeerde topic