FOKS is gefedereerd, opensource alternatief voor Keybase van originele oprichter

De oprichter van Keybase, Maxwell Krohn, heeft een gefedereerd alternatief voor het keybeheer- en chatplatform gemaakt. FOKS, of Federated Open Key Service, is nagenoeg dezelfde tool, maar kan door iedereen worden opgezet.

Krohn schrijft in een blogpost over het initiatief, dat FOKS heet. Dat staat voor Federated Open Key Service. Het is 'zoals Keybase, maar volledig opensource en gefedereerd', schrijft Krohn. Hij is ook medeoprichter van Keybase, dat in 2020 door Zoom werd overgenomen. Krohn zegt dat hij veel van de ideeën die hij nu in FOKS wil implementeren ook al had toen hij Keybase oprichtte.

Net als Keybase is FOKS een protocol om cryptografische sleutels te beheren en met anderen te delen. Op het moment bestaat daar nog geen interface voor, maar de makers hopen in de toekomst een product met een GUI te kunnen maken zoals een mobiele app of een webbased tool. Het grootste verschil met Keybase is dat FOKS gefedereerd is, wat betekent dat iedere gebruiker een eigen server kan opzetten. Wel willen de makers kijken of ze zelf betaalde hosting kunnen aanbieden als verdienmodel. Daarna kunnen gebruikers berichten naar anderen sturen die end-to-end versleuteld zijn.

Een ander belangrijk verschil is volgens de oprichter dat er ondersteuning komt voor single sign-on via OAuth2. Ook moet FOKS ondersteuning krijgen voor YubiKeys.

FOKS is geen fork van Keybase, maar een nieuwe tool, zegt Krohn. Het gaat om een volledig nieuw geschreven tool gemaakt in Go. De broncode is onder een MIT-licentie opensource beschikbaar op GitHub. Daarnaast hebben de makers een whitepaper geschreven over de cryptografische implementatie.

Reacties (23)

[Oon]

Wel mooi dat iemand die zich met een dergelijk niveau van opsec bezig houdt dan als voorbeeld een bash script van het internet runt zonder controle

[GertMenkel]

Als je het script zelf geschreven hebt, kun je het script vertrouwen

[Oon]

Niet als je dat script weer van een extern adres naar binnen haalt. Genoeg mogelijkheden voor MITM e.d. die dat een slecht idee maken.

Dan zou je op z'n allerminst eerst (lokaal) een hash check moeten doen obv een bekende hash om te zien of het script dat je hebt gedownload exact hetzelfde is.

[svane]

"genoeg" mogelijkheden? Ik daag je graag uit om er één te noemen. Https is juist bedoeld om MITM aanvallen te voorkomen. Ik zou graag een voorbeeld zien van een aanval waar curl zonder problemen een script download met een certificaat wat niet klopt.

Als je een site genoeg vertrouwt om een binary te downloaden en uit te voeren, dan is er vrijwel geen legitieme reden om niet ook een script uit te voeren van diezelfde site.

[malmeloo]

MITM? De transfer gebeurt gewoon over HTTPS hoor. Het probleem zit hem vooral in het standaardiseren van de "kopiëer-plak" methode voor het installeren van software; zo wordt het wel heel makkelijk om per ongeluk scriptjes te draaien van een malafide website.

Ben het overigens wel met je eens dat een hash/signature check wel een stuk beter is. Maar dan moet die hash of pubkey eigenlijk niet op dezelfde website staan, anders schiet je er nog niet veel mee op.

[djwice]

DNSSec + DNS CAA wellicht?

[malmeloo]

DNSSEC is niet bijzonder interessant voor HTTPS mits je client aangeboden certificaten goed verifieert. CAA beschermt eigenlijk alleen tegen het scenario waarin een malafide of gehackte CA een certificaat voor jouw website uitgeeft, maar in dat geval hebben we een veel groter probleem :-). Beide zijn nog steeds interessant om te implementeren, maar gaan je niet helpen als een hacker de website overneemt bijvoorbeeld.

Daarom moeten de hashes/signatures eigenlijk ook op een andere server staan: als je ze op dezelfde website zet, kan een hacker die hashes in principe net zo goed vervangen. Dat is ook waarom package managers veel veiliger zijn: ze houden die hashes bijna altijd in hun eigen repositories bij, en forceren dat die hash geverifiëerd wordt ipv dat ze op de eindgebruiker leunen om dat zelf te doen.

[djwice]

Maar als een hacker je code kan wijzigen is de kans groot dat ie het proces om de hash en code te updaten heeft overgenomen.

Dus zo'n grote extra veiligheid geeft de hash niet.

Dan zou ik meer focussen om zorgen dat het uit de juiste bron komt met het juiste certificaat en de juiste DNS entry (geen ander IP met certificaat van andere host).

[malmeloo]

Ja precies, daarom moet de hash ook op een andere server staan. Als je client volgens de standaard functioneert ben je met 'slechts' TLS al beschermd tegen het scenario waar iemand je packets naar een ander IP adres stuurt; die nieuwe host heeft immers geen geldig certificaat voor de domeinnaam die je probeert te bereiken. En zowel DNSSEC and CAA beschermt je niet tegen het scenario wat jij ook al aangeeft, waarbij een hacker je server overneemt. Maar een hash op een andere server plaatsen doet dat wel (zolang die server niet óók overgenomen wordt).

[djwice]

De hash verschilt per build. Wordt dus bij de build gemaakt. Gedistribueerd vanaf dezelfde build, dus wie de build aan kan passen kan de hash aanpassen.
Of die naar een andere server gedistribueerd wordt maakt niet uit.

Kijkt de andere server zelfstandig naar de build? Dan hebben we het zelfde probleem.

En dus is de hash even betrouwbaar als dat jij de build van de server af haalt.

Of heb jij een manier om dat wel veiliger te doen?

[malmeloo]

Als je build server (+ evt signing privkey) gecompromitteerd is dan is elke vorm van cryptografie sowieso hopeloos. Het signen (en/of vrijgeven van hashes) helpt alleen bij het distributieprobleem, en daarbij is het veiliger als je die signatures en/of hashes op meer plekken vrijgeeft dan alleen op dezelfde server als waar mensen de software zelf vanaf downloaden.

[xzaz]

Wie zegt dat je DNS op dat moment nog goed is en dat je wel echt dat bestand binnen haalt?

[Yggdrasil]

Je TLS cert zegt dat. Natuurlijk zegt dat niks over de inhoud van het bestand.

[Llopigat]

Ja maar hij wil dat de gebruikers het ook doen.

Bovendien, de veiligheid van je gebruikers laat je nu afhangen van de beveiliging van je webserver. In dit geval is het niet eens GitHub (die hier behoorlijk goed in is) maar een eigen site, die waarschijnlijk door een of andere derde partij wordt gehost. Die ook weer zijn eigen kwetsbaarheden zal hebben en waar iemand een ander script kan uploaden in zo'n geval.

Er zijn best veel apps die zo werken tegenwoordig. Ik download het script dan altijd handmatig en kijk het door voor ik het run. Of nog liever, ik pull gewoon een image van docker. Is nog veel makkelijker te verhuizen en herinstalleren ook. En hoewel een docker container geen perfecte afscherming biedt (is wel uit te ontsnappen) is het ook een extra bescherming tegen fouten in de code.

[Reactie gewijzigd door Llopigat op 11 juli 2025 16:05]

[sfranken]

... En ingelogd is als root user

[powerboat]

Wat je open zet, hoef je ook niet te beschermen

[Reactie gewijzigd door powerboat op 11 juli 2025 15:41]

[Llopigat]

Het verbaast me wel dat Zoom toen geen anti concurrentie beding heeft afgesproken. Met andere woorden: Na de verkoop van je produkt ga je niet een gelijkwaardig produkt oprichten. Daar kopen ze het immers niet voor.

Maar misschien is dit verlopen of gewoon niet afgesproken.

[sIRwa3]

misschien kochten ze het voor de kennis, die hebben ze nu. maar willen ze het niet als product op de markt brengen? Zal hopelijk wel contractueel zijn vastgelegd

[Yinchie]

Zie alternatief dat al langer bestaat: https://keyoxide.org

[Reactie gewijzigd door Yinchie op 12 juli 2025 06:58]

[Zebby]

Kun je hiermee dan een HSM maken? Dat zou interessant zijn!

[aikebah]

Nee, geen H(ardware) security module, want

- het is software

- het geeft sleutels vrij

Een HSM doet de ver/ontsleuteling voor jou in tamper-proof hardware en keys kun je er in opslaan/vervangen, maar niet uit opvragen.

[Llopigat]

Het idee van een HSM is dat de hardware heel goed beveiligd is, dus ik denk niet dat het zin heeft om dit gewoon op een PC te stoppen en het als HSM te zien. Dan heb je gewoon een keyserver.

[Zebby]

Wij hebben als VAR en partner die dat kan regelen, en die hebben een hsm op de lijst staan. Dus als er een open source variant bestaat voor de kerk management dan zijn we er.