Tor står för 'The Onion Router' men är också en fornnordisk gud. Balder är en annan fornnordisk gud som också tillskrivs att vara rättvis och skamlös. Det passar ett annonymitetsnät som skapar kommunikationsrättvisa mellan folk och stat, som tillåter oss ett privatliv så vi vågar leva som vi vill, så vi vågar vara skamlösa!
Rättvisa är en viktig aspekt i Balder anonymitets protokoll också, att försöka se till att alla bidrar någorlunda lika mycket som de använder, i alla fall om de använder mycket. Det bidrar till protokollet skalar bra när det kommer fler användare och blir robust mot attacker.
Målet är inte perfekt kommunikation, men tillräckligt nära perfekt kommunikation för att både vara brukbart för vardagsurf och fildelning och och framför allt omöjliggöra nästan perfekt övervakning.
Att omöjliggöra perfekt avlyssning är lätt, det är bara att kryptera, men att omöjliggöra perfekt övervakning är svårt (förhindra trafikdataanalys, bevara anonymitet).
Varpourware
Balder är inget existerande system, utan detta är en ideskiss på en uppsättning protokoll, som vi kanske kan göra något av om intresse uppstår och ingen hittar fatala designfel. Det är tänkt som öppna protokoll som ska gå att integrera i nya och gamla program. Jag är ingen säkerhetsexpert men en drägligt erfaren utvecklare, så synpunkter och peer-rewiew är mer än välkommen. Känner du någon med kunskap - be dom att läsa!
Balder anonymitets protokoll
Balder är tänkt som ett utbyggbart system av protokoll för vilket BAP (Balder anonymitets protokoll) är grunden. BAP själv hanterar bara en anonym till känd anslutning, på detta byggs senare ändpunktstjänster, anonym till anonym tjänster, informations caching tjänster mfl.
BAP - Virtuellt paketförmedlat nät
Varje deltagare är en nod, som via https ansluter till andra noder, ju fler desto bättre för både nätets och nodens säkerhet, men varje nod gör själv en avvägning mot sina tillgängliga resurser. Vid behov kopplas nya anslutningar upp och gamla stängs så nätet är i ständig förändring.
BAP Paket
Informationen sänds som paket som innehåller mottagare (antingen nod ip eller ett serviceID), men inte avsändare. Det innehåller också data, och dataID om datan är krypterad. Paketen är på en högre nivå och stora jämfört med IP-paket även om små paket kan förekomma. För att tillåta deltagare med begränsad bandbredd bör inget paket vara allt för stort.
Paket sänds via de krypterade anslutningarna från nod till nod. Varje nod sänder det vidare till en delvis slumpmässigt nod, men en nod som bedöms närmare målet. varje nod vet vilken nod de fick paketet ifrån, men inte varifrån det ursprungligen kommer. På det sättet kan paket sändas till en mottagare eller tjänst utan att enkelt kunna spåras tillbaks.
BAP Returpaket
Om ett paket har returID satt (kan vara löpnummer per nod och anslutning) så spar noden returID och anslutning samt ersätter returid i paketet med ett eget returID. När det sedan kommer ett paket i retur så sätts ursprungliga returID:t på paketet som sänds vidare på den ursprungliga anslutningen. Precis som NAT, fast i varje nod längs vägen. På det sättet tillåts svar komma på anonyma anslutningar.
BAP - End to end kryptering.
Med hjälp av BAP och asymmetriska nycklar överenskoms om en symmetrisk krypteringsnyckel med ändpunkten. Ändpunkten vet dock inte vem källan är så ett dataID behövs för att ändpunkten ska veta vilken nyckel den ska använda. Men det bör inte utifrån gå att se på paketen att de kommer från samma källa eller tillhör samma session.
Det uppnås med en ID-mall, slumpmässig text med ett anta markeringar i. I samband med att man kommer överens om en symetrisk nyckel så gör man upp om en mall, startvärde och stegvärde för löpnummer. Sändaren sätter sedan in löpnumret vid varje markering och skapar en checksumma. Ändpunkten förberäknar checksummor för de närmaste löpnumren så den kan känna igen dom när de kommer.
På det sättet kan en nod kontrollerad av fi inte se om två paket till samma ändpunkt är del i samma session eller ens från samma källa. Vilket förhindrar att en infiltratör kan lista ut för mycket.
Fi kommer bara över en del av paketen så checksummealgoritmen kan vara optimerad för fart, mallen kan bytas regelbundet för att hålla uppe säkerheten.
Ändpunkten måste vara känd till IP på nätverket så dess publika nyckel som ändpunkt kan vara offentlig. Källan kan sända med sin publika nyckel när en kontakt till ändpunkt etableras, källan bör generera ett nytt nyckelpar ofta annars kan ev infiltrerande fi se att två anslutningar har samma källa, ingen katastrof vid enstaka tillfällen men lite skadligt. Det är dock källans klockcykler som krävs och källans säkerhet som berörs så källan kan bestämma det själv.
Våra klockcykler är vapen som slåss
Våra klockcykler är vapen för oss
Om en ändpunkt agerar källa ska den i vart fall aldrig använda sin ändpunktsnyckel som lätt kan knytas till IP!
BAP Poll
På varje sänt paket kommer max ett i retur, så om svaret innehåller för mycket data måste källan sända pollpaket, paket till ändpunkten med dataID men inget data/bara statusdata, så ändpunkten har nått att svara på. Förväntar sig källan många svar kan den sända pollpaket i förväg, annars ska svarspaketet innehålla information om att mer data finns att hämta. Varje pollpaket kan (och kommer att) sändas olika vägar vilket försvårar analys av trafiken.
BAP Ping
Diagnostiskt paket som instruerar ändpunkten att returnera en tidstämpel från ändpunkten för att testa fart och stabilitet på anslutningen. Kan ha krypterad 'barlast' för att testa hur storleken på ett paket påverkar farten. Att det en Ping ska inte framgå utan att titta i den krypterade lasten för mellanliggande noder får inte förstå att de 'testas' för då kan en fi anpassa sitt beteende. Kan också vid behov sändas i rent 'förvirringssyfte' för att dölja annan trafik, då lämpligen med hög latency.
BAP onions
Om fi aggressivt infiltrerar nätet så kommer de ibland, men inte ofta, att kunna ha infiltrerat både ändpunkten och en nod längs vägen. Om ändpunkten, som känner uppströmsanslutningen, och fi:s andra noder kommunicerar aggressivt kan anslutningen kännas igen på dataID. Det avslöjar noden för fi:s nod, men inte startpunkten. Det är ingen stor risk jämfört med insattsen för fi men ändå värd att begrunda.
Nätet väljer också väg, inte källan. Men ibland vill man vara säker på att en väg som leder utanför fi:s horisont väljs.
För båda dessa saker finns BAP onions, små lökar. Det är paket som i den krypterade lasten innehåller ett BAP-paket som ändpunkten sprider vidare till en ny ändpunkt. Det är tillåtet med upp till tre paket i varandra vilket tillåter två falska 'ändpunkter' för den riktiga. För varje 'ändpunkt' längs vägen kommer därmed även nya dataID. Källan väljer alla dessa ändpunkter och kan därmed kontrollera vägen till viss del.
Värt att notera är att även om den 'riktiga' ändpunkten är samma för många paket så kan de två mellan 'ändpunkterna' bytas för varje paket
Anslutningen blir klart långsammare med onions, men det kan tas till då säkerbehovet så kräver.
Droppade paket
Noder måste få droppa info om returväg om inte svar kommer inom rimlig tid. Noder kan också ha buggar eller avsiktligt bete sig illa. Det är dock inte bra att sända om information rent tidsmässigt eftersom det är vad underliggande IP-protokoll gör, vilket leder till en lavineffekt om en anslutning är överbelastad. Andra strategier är nödvändiga.
Består anslutningen av fler paket (BAP-poll) kan de grupperas 3-9 stycken som sänds olika vägar där en är en xor på de övriga. Sådana paket ska i den krypterade lasten innehålla info om hur bred gruppen är, vilken position aktuellt paket har och om de ska sammanfogas seriellt (efter varandra) eller horisontellt (en bit från varje i tur och ordning). Då kan källan rädda situationen själv och bara notera vilken anslutning som misslyckades om max ett paket uteblir.
I annat fall eller om det inte räcker får källan be om en statusrapport från ändpunkten som lämpligen sänds en annan väg än de misslyckade försöken. Statusrapporten bör innehålla info om vilka löpnummer som det uteblivit svar på och var källan befinner sig på för löpnummer nu, så en resync vid behov är möjligt då löpnummer i dataID kan vara i otakt hos källa och ändpunkt vid svåra störningar. Av samma orsak ska ett speciellt dataID användas som statusbegäran. Det kan vara samma mall men med ett i förväg överenskommet löpnummer som inte kan dyka upp i nummerserien. Ändpunkten bör spara sända svarspaket en stund så de kan omläggas för hämtning med poll vid en statusbegären. Ett paket kan sändas som svar redan på statusförfrågan.
Misslyckas också det får anslutningen ses som trasig och droppas eller startas om, lämpligen med annan ändpunkt. För så länge är det inte rimligt att kräva att ändpunkten sparar paket att fler försök vore nyttiga.
BAP Services
Som tidigare nämnt kan paket adresseras till en nod eller till en service (tjänst). Det finns två sorters tjänster:
- IPservices: Tjänster som förutsätter att tjänstens ip också är känst, så källan kan välja den tjänsten vi en utvald ändpunkt. Dessa nås med nod IP och information om önskad tjänst döljs i den krypterade lasten.
- Services: Tjänster som det inte spelar någon roll vilken nod som tillhandahåller. Nås med ServiceID och varken källa eller tjänst vet om varandras identitet. Kan kombineras med landskod eller IP-wildcards för att styra var tjänsten tillhandahålls.
BAP är tänkt att vara utbyggbart med olika tjänster, men några tjänster är nödvändiga för att ha nån som helst nytta av systemet.
- Onion: En del av BAP som nämnts ovan, men ändå en tjänst. Kan erbjudas både som Service och IPservice.
- PollOnion: Dito men kan hantera fler paket. Måste vara IPservice.
- DNS: Namnuppslagning, kan erbjudas både som Service och IPservice.
- http: Webbläsning, kan erbjudas som IPservice.
- https: Säker webbläsning, kan erbjudas som IPservice.
- ssh: säker terminalanslutning, kan erbjudas som IPservice.
- rendevu: Mötesplats. Två noder kontaktar samma rendevu nod med en tidigare överenskommen rendevu ID i den krypterade lasten tillsammans med en rendevu last som har annan kryptering. Rendevu nod spar den första, väntar på nästa och sänder sen resp krypterade rendevulast till den andre. På det sättet kan två noder utbyta data utan att känna varandra och utan att vara kända av rendevu tjänsten. Vanligen IPservice men kan förekomma som Service, men då endast brukbar om rendevuID är ett känt syfte, där vem som helst ute i samma syfte kan vara intressant att kontakta.
Några aptitretare:
- Message: En tjänst där man kan registrera ett ID, uppdatera och kolla närvaro, lämna och hämta meddelanden. Vill två kontakter utbyta mycket data eller ha en långvarig chatt bör kontakten flyttas till en farm av rendevu tjänster. För att minska skadan om messageservern är komprometterad och tillåta högre genomströmmning. Måste vara IPservice
- DataCach: En distrubuerad data cach, där anonyma 'block' spars med en hash, och storlek. Verjae server har en slumvald hash, och försöker holla koll på andra servar fast flest med nästan samma hash. Så en förfrågan kan styras mot servrar som troligen har biten. När svar sedan går tillbaks kan servrar på svarsvägen välja att cacha biten. Sanolikheten att cacha och tiden den cachas styrs av hur nära bitens hash ligger resp servers hash. Det bör också gå att pusha saker ut i cachen. Servrar som godtar en push bör spara biten längre tid. Sedan kan liknande torrentfiler berätta vilka bitar som tillhör vilken fil. Måste rimligen vara en IPservice, men då det är en ömsesidig tjänst är det möjligt att tillåta anonym deltagande via rendevu service, där 'DataCach' används som rendevu ID.
- Distrubuerade databaser: av alla de slag.
Båda de senare tjänsterna är bra för BAP då de skapar trafik som troligen ofta kan gå som high latency förbindelse.
Välja säkerhet vs fart
Ett sätt att välja högre säkerhet är att använda onions. Men det vore bra (och bra även för onion anslutningar) om vanliga anslutningar vore så säkra som möjligt.
Det är också viktigt att dölja vilken som är källa, i synnerhet om första noden är infiltrerad av fi. Det är synnerligen viktigt om källa och ändpunkt ligger nära varandra i IP-rymden. Då skulle routingkedjan bli väldigt kort om inte källan skickade meddelandet bort från målet, något som skulle se misstänkt ut för första noden som vet sitt eget IP, källans IP och ändpunktens IP (eftersom routingregeln säger att man ska försöka gå närmare målet). Även om det fortfarande inte går att veta ifall noden före är källan eller bara en 'mellanändpunkt' i en lök så är det illa nog.
Lösningen är att ge paketen noll, en eller två barriärer. Barriärerna anges som antal bitar i nodens IP som är lika med ändpunktens IP. Om en nod ligger innanför en barriär tas först barriären bort och sedan routas paketet ut utanför den bortagna barriären. Finns två barriärer och noden ligger innanför båda så är det slumpmässigt vilken barriär som tas bort.
På det sättet blir det normalt att paket routas utåt från målet ibland, vilket hjälper till att dölja när en källa gör det i första steget. När en källa sänder ett paket utåt så får det dock max ha en barriär för att inte röja sig.
Ju längre 'ut' den yttre barriären ligger ju större slump i routingen och ju oftare går paket 'i sidled' eller rent av lite utåt. Detta för att ett paket med två barriärer inte nödvändigtvis ska vara helt nära källan.
Genom att sätta en eller två barriärer kan källan på det sättet garrantera en längre och krokigare väg som blir svårare att spåra.
Det ska gå att sätta även en latency, fördröjning. Det betyder att en nod får vänta upp till så länge med att sända ett paket (och svaret) vidare för att kunna dölja det med samtidiga andra överföringar. Finns barriärer kan fler latancys anges. Då gäller först den första, men då en barriär tas bort tas också denna latency bort men gäller fortfarande för den noden som tar bort den. Det skyddar ytterligare en källa som sänder utåt. Inte bara kan det vara en barriär det beror på - latencyvärdet kan vara högre för den noden och tidigare noder än det är nu - så det blir extra osäkert att försöka analysera trafik bakåt.
Ett speciellt latency värde ska också kunna anges för lök 'ändpunkter' i den krypterade lasten. Så en löktjänst kan ha högre fördröjning än övriga noder. Det gör det ytterligare svårare att avgöra om en nod är 'riktig' ändpunkt eller källa.
Paket med hög latency är inte bara svårare att spåra själv, de hjälper även till att dölja annan trafik så de är väldigt önskvärda. Det är OK om en nod prioritera att dölja den trafik där den själv är källa - för det betyder att varje nod längs vägen kan vara en potentiell källa och spårning blir svårare.
BAP discovery
Det måste finnas ett sätt att hitta noder att ansluta till eller använda som ändpunkt för olika tjänster. De bör sändas till en wildkardIP adress med info om vad som söks, och 'nätet' väljer en som vill erbjuda det och som svarar med sitt IP. Vi förfrågan om anslutning ska en wildcard på egna IP adressen sändas med och en angivelse om man är bakom fw, så de i andra sidan kan avgöra om de är intresserade. Sedan utbyts info som behövs för att starta en anslutning, det kan inkludera portnr mm. även om standar https port är det normala i BAP.
Det ska vara någorlunda svårt att kartlägga alla som deltar i nätet eller alla som erbjuder vissa tjänster.
Anslutningar
Det måste finnas kända noder, minst en, för nya deltagare att ansluta till. En uppsättning rootnoder är lämpligt. Olika grupper som dataföreningar, fackföreningar, medborgarrättsrörelser, politiska rörelser etc kan hålla sig med egna listor på noder - antingen öppna för allmänheten eller slutna för medlemmar. De listorna kan även lista 'pålitliga' ändpunkter för olika tjänster. En ny deltagare kan också välja att ansluta till vänner som redan är med. Balder är i grunden ett öppet nät men det finns några varianter att ansluta på som kan ge mer eller mindre 'darknet' effekt.
- Vit nod: Låter sitt IPnr spridas på nätet och blir tillgänglig för anslutningar utifrån samt kan köra IPservices.
- Grå nod: Låter inte sitt IPnr spridas på nätet och måste därför upprätta alla sina anslutningar själv. Deltar fortfarande i förmedlandet av trafik mellan noder.
- Svarta noder: Dito men förmedlar heller ingen trafik. Måste snylta på andras trafik.
Samtliga varianter ska kunna delta från bakom en firewall. Grå och svarta noder kan vara delvis darknet (bara ansluta till vänner), de bör vara darknet om det är viktigt för dom att var 'hemliga' eftersom den dom ansluter till (som kan vara fi) vet deras IP och för svarta noder är det kanske inget annat än vänner som går med på snyltandet. Det går att ansluta bara till grå/svarta noder. Även om man ansluter bara till grå darknetnoder kan man fortfarande delta i att förmedla trafik om man vill.
Gamla anslutningar som används lite ska stängas för att ge platts för nya. Det bör meddelas respektive nod en stund före paket slutar accepteras så ändrad routinginfo hinner spridas. Efter att nya paket slutar tillåtas ska anslutningen hållas öppen till alla 'utestående' paket i båda riktningar är klara eller timar ut.
Routing
Vita noder är dom som syns och är adresserbara så de måste veta så mycket om sitt omedelbara granskap att de kan avgöra om en IP-adress inte finns. Därför bör de känna till alla IP adresser inom sin horisont som ska vara alla som är olika i max de sista n bitarna där n är minst 9 men ska ökas om noden ser mindre än 32 IP innanför horisonten. Regelbundna discovery ska sändas efter andra inanför horisonten, dessa discoverys ska inehålla hela avsändarIP. Fås en discovery från ett IP innanför Horisonten som noden inte känner till ska en anslutning upprättas för att alla inom samma horisont ska känna till varandra.
Grannoder sänder routing information till varandra som innehåller info om Subnät och IP-nummer och hur snabb anslutningen är. Den informationen ska exkludera info som kommer från grannen själv. Vita noder ska få och spara info om alla subnät som skiljer sig från deras eget IPnr i max de 8 första bitarna efter de bitar man har gemensamt med subnätet. Om två grannar ligger inom varandras horisont ska de utbyta alla IP som är innanför bådas horisont. Det ger noggrannare info ju närmare man ligger målet. En vit nod ska också försöka ha proportionellt fler anslutningar till närmare noder. Routinginformationen bör sändas med hög latancy för att inte bromsa utan istället hjälpa till att dölja annan trafik.
Grå noder ska få och spara routinginfo om de första 12 bitarna i subnät oberoende av vilket IP de själv har. Till Vita noder ska de sända routinginfo enligt reglerna för vita noder och vita noder sänder enligt reglerna för grå noder till grå noder. Grå noder ska också eftersträva att ansluta till så många av dessa subnät som möjligt och inte alls prioritera närhet. Det gör att grå noder ofta är lämpliga i början av en routingkedja.
En vit nod som är källa bör dock inte alltid starta med en grå nod för att försvåra avslöjande. Paket som startar i en grå nod måste (darknet undantagna) först passera en vit nod och paket kan mycket möjligt går vit-grå-vit-grå så det blir inte för avslöjande. Att det kan dölja sig darknet bakom en nod ökar osäkerheten ytterligare om en nod är källa eller ej.
Ekonomi
Många noder kommer att bidra mer än dom använder, så i sig själv bör nätet ha resurser över. Det är ändå viktigt att se till att de noder som använder mycket också måste bidra med mycket om brist uppstår. För att göra nätet robust, inte minst mot attacker som försöker överbelasta det.
Tanken är enkel. Den som sänder ett paket (ut) får 'betala' för det, inklusive ev svar. Det gör att en nod går +-0 på paket den vidarebefordrar. Men det gör ändå nytta för in och ut summeras separat per anslutning. Det som avgör en anslutnings 'värde' är kvoten in delat med ut. Så en större volym gör att man kan sända mer ut innan kvoten förändras mycket. Kvoten kan lite påverka routing (sänd mer till de som har låg kvot), men framför allt ska det påverkar prioriteringen vid hög last (prioritera grannoder med hög kvot).
Noden ska också hålla koll på mängden förlorade paket, om ett paket förloras behöver det inte vara grannodens fel, men om det blir vanligt bör den undersökas extra noga med diagnospaket, mindre trafik tas emot från den och mindre 'riktig' trafik routas genom den. De som är granne med en dålig nod bör märka mest och kan routa runt den för att undgå att själv bli sedd som dålig. På det sättet tvingas noder, även fi:s noder, att bete sig väl.
Att svarstiderna ofta stämmer rimligt med vad routinginfo säger bör också kollas, för att en fi inte lätt ska kunna locka till sig viss trafik genom att ljuga om sin routing.
Källan går back, ändpunkten går plus. Så det lönar sig att var vit och köra tjänster, i synerhet rendavu-tjänster som är ändpunkt för två förbindelser! En nod som är mycket källa men inte ändpunkt får en kvot under 1, den måste vidarebefodra mycket trafik för att hålla kvoten tillräckligt nära ett.
Den som tar emot förbindelse från en svart nod får själv betala också den svart nodens trafik.
Noder som ofta har förbindelse med varandra bör spara statistiken mellan förbindelser. Statistik åtminstone något dygn bakåt bör beaktas så användaren kan dra nytta av den nytta noden gör då användaren sover och jobbar.
Denna enkla grundekonomi ger ofta automatiskt vettig ekonomi i tillägstjänster, om än kanske inte alltid.
Avslutning
Detta borde vara ett system med robust ekonomi, tillräcklig och styrbar säkerhet, effektivt nog och utbyggbart för de flesta behov.
Det är många detaljer kvar att undersöka, men i det här läget är kritik och förslag rörande grundkonceptet viktigast. Nästa steg är att skapa kod att experimentera med för att få detaljerna rätt.
Jag försvinner från nätet nu i en dryg vecka, men kommentera och tipsa folk som kan vara intresserade, har kunskap och kanske rent av kan bidra.
En ASA post!
Läs även andra bloggares åsikter om internet, programmering, datorer, it, frihet, FRA, FRA-lagen, Tor, anonymitet
För övrigt anser jag alla borde gå med i alfa-testningen av micro peer publishing!
