Ik krijg die vraag eigenlijk meteen als ik het heb over ons project om iets te bouwen wat minder onderhevig is aan de grillen van wetten en regeltjes. Blijkbaar maken de mensen die het vragen alleen maximaal gegarandeerd veilige infrastructuur en gebruiken ze software die niet onveilig kan zijn…
Je weet wel, die mensen sturen je een WhatsApp-boodschap (Meta) over wat ze hebben gedaan en dat staat dan op Facebook en Instagram. Of nog leuker, als ze vertellen dat ze geen last hebben van censuur omdat ze op LinkedIn (Microsoft) hun hart luchten.
Ook blijken er legio mensen te geloven dat als het “Open-Source” is, het dan pas goed is. Vervolgens zetten ze hun code op GitHub (Microsoft). Dat “hun” code vervolgens wereldwijd gebruikt kan worden door de community die ook code schrijft is tof. En commercieel geïnteresseerden zoals Microsoft kijken hier niet naar, toch?
Maar nu over IPFS… Voor het project Abundomy / 1coinh heb ik alles naar IPFS omgebouwd. En om de “swarm” van IPFS-nodes te versterken kan je meer nodes toevoegen die deel van deze swarm uitmaken. (Standaard zal IPFS zo’n 20 nodes selecteren om “hashes” op te zetten zodat de bestanden altijd te herbouwen zijn als iemand de bestanden opvraagt.) En ja hoor, niet onterecht trouwens, kwam deze vraag langs waarbij ik meteen de indruk had dat het een antwoord van een AI-chat was:
“Using IPFS for sensitive information poses substantial privacy risks, as all traffic and content are public unless encrypted, making it easy for third parties to monitor and access data. Additionally, once content is published on IPFS, it becomes accessible to anyone, which can lead to potential misuse or exposure of sensitive data.” Is het door jou gebruikte systeem encrypted?
De eerlijkheid geeft dit antwoord (wat hocus-pocus is voor de meesten…):
Kan data gemanipuleerd worden?
OrbitDB-entries zijn cryptografisch gesigneerd. Elke write naar de database is ondertekend met de private key van de schrijver. Iemand die een nep-transactie probeert in te voegen zonder die key, wordt door het netwerk geweigerd — de handtekening klopt niet.
| Aanvalsvector | Mogelijk? | Waarom |
|---|---|---|
| IPFS-blok aanpassen | ❌ Nee | CID = hash van content, onveranderlijk |
| OrbitDB-entry vervalsen | ❌ Nee | Vereist de private signing key |
| Bestaande transactie wijzigen | ❌ Nee | Immutable log — OrbitDB werkt als append-only |
| Nep-transactie injecteren | ❌ Nee (tenzij key gestolen) | Signature verification op netwerkniveau |
Waar liggen de eventuele risico’s?
VPS-compromittering
De relay (12D3KooWAdaFx…) en de API (https://178-105-222-179.sslip.io) draaien allebei op de VPS. Als de VPS gecompromitteerd wordt: relay valt weg (app kan niet verbinden), maar de OrbitDB-data zelf blijft cryptografisch integer — niemand kan met gestolen toegang tot de VPS nep-transacties injecteren zonder de signing key van de applicatie.
Private signing key
De énige manier om valse transacties in te voegen is via de private key die de app gebruikt om entries te signeren. Als die key ooit uitlekt (bijv. hardcoded in de app-bundle op IPFS), is dat het kritieke risico.
relay.json is publiek leesbaar
Dit is expres zo gemaakt — peers moeten de relay en store-adressen kennen. Geen probleem. Maar het onthult wel het VPS-IP en de libp2p PeerID van de relay, wat gericht scannen makkelijker maakt. Maar dat is een afweging die we moesten maken omdat Abundomy op openheid, en hopelijk daardoor ook vertrouwen, is gestoeld.
IPNS-pointer op de app
De abundomy-app IPNS-key op de VPS wijst naar de huidige app-CID. Als die key gestolen wordt, kan een aanvaller een andere relay.json publiceren die naar een kwaadaardige relay wijst — waardoor de app van gebruikers naar een nepomgeving verbindt.
Conclusie
De content is niet manipuleerbaar. De transacties zijn cryptografisch beschermd via OrbitDB-signing. Het systeem is architectureel solide voor wat de IPFS-laag betreft. De kwetsbaarheden zitten in klassieke beveiligingsvlakken: VPS-toegang, beheer van de signing key, en de IPNS-key voor de app. Die zijn al gedekt door de VPS-hardening die is ingericht.