SLUTRAPPORT 30 JANUARI 2017

Transkript

1 SLUTRAPPORT 30 JANUARI 2017 plattform för säkra, distribuerade & sociala appar mist.nu visiarc.com

2 MIST: SLUTRAPPORT 30 januari 2017 VISIARC AB Box LINKÖPING visiarc.com 1. Inledning MIST är ett projekt med vision om en ny typ av distribuerade, sociala, applikationer, där användaren styr och kontrollerar var data lagras och hur den delas. I och med det här projektet har vi kommit en lång bit på vägen att realisera denna vision. Nu finns det fundamentet som krävs för att vi ska kunna börja experimentera med att bygga dessa applikationer. Det finns dessutom tillgängligt för alla i och med att koden släpps som fri programvara (öppen källkod). När projektet utvärderas inom 24 månader hoppas vi att det kommer att finnas en community av utvecklare som använder MIST till att bygga fantastiska applikationer som släpps som öppen källkod, samt en diversifierad bas av användare som dagligen använder dessa applikationer. 2. Mål och syfte MIST:s vision är att det ska finnas en stor flora av säkra, distribuerade, sociala, applikationer, som låter användaren ha full kontroll över hur data lagras och delas. Att man är mån om sin personliga integritet och oroas sig över massövervakning ska inte innebära att man står utan bra digitala tjänster. Målet med det här projektet, som är den första etappen av MIST, är att bygga ett C++-bibliotek som består av två delar, en nätverksdel och en databasdel. Nätverksdelen ger en säker uppkoppling mellan två användare, eller noder, i ett distribuerat nätverk. Databasdelen löser hur man synkar data mellan användare, eller noder, samt hur man lagrar data versionshanterat. Syftet är att biblioteket ska användas av MIST, som en grund för att bygga säkra, distribuerade sociala applikationer. Biblioteket ska också vara tillgängligt för utvecklare som har behov av tekniken, utan att för den skull behöva dela MIST:s övriga vision och mål. Därför distribueras biblioteket som fri programvara (öppen källkod). Postadress Telefon Org.nr. Besöksadress Webb VISIARC AB & styrelsens säte visiarc.com Box 244 Fax VAT-nr. Repslagaregatan 19 Epost LINKÖPING SE LINKÖPING info@visiarc.com

3 3. Projektbeskrivning Projektet har bestått i att designa och implementera ett nätverks- och ett databasbibliotek. När vi startade projektet visste vi vad vi ville åstadkomma, men inte hur. Därför började projektet med en lång designfas som till slut mynnade ut i ett design/kravdokument. Därefter försökte vi hitta en partner som kunde leverera i enlighet med detta design/kravdokument, utan framgång. Vi valde istället att först skapa prototyper. Vi byggde en prototyp av nätverksbiblioteket i JavaScript samt en prototyp av databasen i TypeScript. Prototypen till databasen blev aldrig helt färdig. Slutligen portades dessa prototyper till C++, och C++-biblioteket gjordes tillgängligt som en node.js-modul. Inför porten till C++ tog vi bort en del funktionalitet som funnits i databasprototypen, för att hinna bli klara i tid. Vi utvärderade olika bibliotek för grundläggande funktioner som vi skulle behöva. Ett krav var att de skulle vara öppen källkod. Andra att de verkade trovärdiga och att vi kunde göra allt vi behövde med deras API. I slutändan valde vi NSS (Network Security Services, från Mozilla) för TLS, nghttp2 för HTTP/2 samt SQLite3 för lagring. Dessutom valde vi att integrera med TOR för att få anonymitet. TOR finns inte tillgängligt som ett bibliotek utan startas som ett separat program. När man bygger ett C++-bibliotek finns det många olika sätt att hantera trådning och livscykler. Vi valde därför att se till så biblioteket kunde användas i node.js, så att det passar med trådning och livscykel för moduler i node.js. Detta för att vi avser använda node.js för att utveckla fler delar av MIST. Under hela projektet har vi testkört biblioteket på Windows, Linux och Mac OS X. 4. Leverabler Ett C++-bibliotek innehållande en nätverksdel, en databasdel och en node.jskoppling, som fungerar på Windows, Linux och Mac OS X. Levererat till En uppslagningsserver, implementerad i JavaScript och Node.js. Levererat till En tjänst, lookup.mist.nu, som kör en uppslagningsserver för allmän användning. Utvecklare som vill använda MIST behöver inte själva driftsätta någon infrastruktur. 1

4 5. Resultat Nätverksdelen Nätverksdelen av biblioteket gör så att två användare/noder kan kommunicera med varandra på ett säkert sätt. Det betyder att vi behöver lösa konfidentialitet, integritet, autentisering och anonymitet. Konfidentialitet så att ingen utomstående kan avlyssna, integritet så att ingen utomstående kan förändra kommunikationen, autentisering så vi kan vara säkra på vem vi kommunicerar med och anonymitet så att ingen utomstående kan ta reda på vem vi kommunicerar med. Kryptering är svårt - det finns många fallgropar. Därför försökte vi inte skapa ett nytt protokoll, eller någon egen implementation av kryptofunktioner. Istället har vi använt existerande standarder som löser uppgiften, samt öppna källkodsimplementationer av dessa standarder. För att lösa konfidentialitet, integritet, autentisering använder vi oss av TLS (Transport Layer Security). Som TLS-implementation använder vi NSS (Network Security Services) från Mozilla. Varje användare har ett publikt/privat RSA nyckelpar, som används för autentisering, i form av server- och klientcertifikat i TSL-förbindelsen. TLS är ett rent klient-server protokoll, där servern är publik. Någon som avlyssnar får alltid reda på serverns identitet. För att få anonymitet använder vi därför TOR, som är ett system för anonym routing som drivs på frivillig basis med öppen källkod. För att få full anonymitet så påverkas nätverksprestanda i form av kapacitet och framförallt latens. Därför har vi gjort så att användningen av anonymitet är frivillig, den går att slå av när båda användarna/noderna så önskar. Ovanpå den säkra TSL-förbindelsen använder vi oss av HTTP/2. HTTP/2 tillåter att man gör flera parallella anrop över samma förbindelse, något som gör att man kan blanda små, korta anrop med långa. Till exempel blanda ett kort chatmeddelande med överföringen av en stor fil. Chatmeddelandet behöver inte vänta på att hela filöverföringen ska bli klar, utan kommer fram snabbt. HTTP/2 är också ett rent klient-server protokoll. Det är också det protokoll som flest utvecklare har erfarenhet av, då det är bakåtkompatibelt med HTTP. För att anpassa HTTP/2 till peer-to-peer skapar vi två förbindelser. Dels den vanliga, klient till server. Dels en virtuell som går åt andra hållet, server till klient. Varje ändpunkt är både klient och server. Det gör att man kan bygga REST (Representational state transfer) tjänster ovanpå MIST, Enda skillnaden mot vanlig webbutveckling är att man behöver kombinera en klient och server i samma program, istället för att ha en separat klient och en separat server. Förutom HTTP/2 går det också att öppna en virtuell socket för att kommunicera med vilket protokoll som helst. Dessa implementeras som WebSocket över HTTP/2. Det finns ingen begränsning i hur många sådana sockets kan öppnas. 2

5 Slutligen behöver vi ett sätt att få reda på hur man kopplar upp sig till en annan användare. Det görs via en uppslagningsserver, där man kan fråga efter en användares TOR hidden service adress. Steg 1 Uppslagningsserver TOR Network Anna Steg 2 Hidden Service Bosse (Steg 3) Bilden illustrerar hur en uppkoppling sker. Anna ska koppla upp sig mot Bosse. För att detta ska ske måste Anna känna till Bosses publika nyckel. Dessutom måste Bosse känna till Annas publika nyckel. Vi tillåter inte anonyma uppkopplingar, eller uppkopplingar från okända. Utbytet av publika nycklar måste normalt ske utanför MIST (finns ett undantag i databasdelen). Själva uppkopplingen sker i två eller tre steg. Först slår Anna upp Bosses TOR hidden service -address. Detta görs via ett anrop till Uppslagsservern. Därefter kopplar Anna upp sig till Bosses TOR hidden service, och gör en normal TLS-handskakning, med autentisering via klientcertifikat. Bosse accepterar uppkopplingen om han känner igen Annas publika nyckel. När väl TLS-förbindelsen är gjord har vi en förbindelse över vilken vi kan köra HTTP/2, och MIST övriga protokoll. Men vi kan också gå vidare till ett tredje steg. Om Anna och Bosse tycker att prestanda är viktigare än anonymitet kan de välja att göra en direktuppkoppling. Detta gör de genom att flytta TLS-förbindelsen till en vanlig socket. Notera att det 3

6 inte sker en ny, öppen, handskakning utan den krypterade förbindelsen flyttas. På så sätt behålls viss anonymitet - vare sig Annas eller Bosses publika nyckel skickas i klartext. Uppslagningsserver Uppslagningsservern är en webbtjänst med ett REST-protokoll, som använder TLS och HTTP/2. Den innehåller två funktioner, en för att lagra en användare/nods TOR hidden service -adress, en för att hämta en annan användare/nods TOR hidden service adress. För att lagra sin egen TOR hidden service adress måste användaren/noden identifierar sig med sitt klientcertifikat. Det krävs autentisering för att vi ska kunna verifiera användarens/nodes publika nyckel. För att slå upp en annan användare/nods TOR hidden service adress behöver man inte identifiera sig, utan det kan ske anonymt. Man måste dock känna till användarens/nodens publika nyckel. Det finns ingen möjlighet att söka fram användare. Det kan ses som ett udda designval att en distribuerad tjänst förlitar sig på en centraliserad uppslagningsserver. Tanken är dock inte att man ska behöva använda den särskilt mycket. Den är mer tänkt att användas första gången två användare/noder kopplar upp sig. Senare ska informationen cachas, samt delas via gemensamma vänner. I framtiden skulle man kunna tänka sig att den centrala tjänsten ersätts med lagring i en distribuerad hashtabell. Databasdelen Databasdelens huvudsyfte är att hantera databaser, som kan synkas mellan flera användare/noder, som kanske inte alltid är online. En sådan databas kan ha olika tillstånd beroende på vem man har synkat mot senast. Databaserna är därför inte atomära, en egenskap som anses nödvändig för SQL-databaser, men som flera NoSQL-databaser har skippat. Anledningen till att många NoSQL-databaser skippar denna egenskap är för att kunna skala bättre. MIST databaser löser synkningen genom att vara versionshanterade. En databas växer alltid, den kan aldrig bli mindre, då den behåller alla tidigare versioner av sitt innehåll. Det gör också att det alltid går att synka, oavsett tillstånd. Information som behövs för att synka två databaser finns alltid sparad. Versionshantering är också en efterfrågad egenskap för att bygga sociala applikationer. Exempel är wiki - som bygger på att man kan se redigeringshistorik - eller forum där man också vill kunna se när någon redigerat sina inlägg. Vi kan således lösa både ett tekniskt och användarmässigt problem på samma gång. En MIST användare/nod förväntas innehålla mer än en databas. Varje databas kan ha olika behörighet, och således synkas mellan olika användare. Information i databasen lagras i som objekt, där varje objekt innehåller JSON. Det finns inget schema - godtycklig JSON kan lagras. 4

7 Databasdelen använder ett REST-protokoll för att synkronisera databaser mellan användare/noder. Varje version i en databas är en transaktion. En sådan transaktion kan innehålla nya objekt, ändrade objekt, flyttade objekt eller borttagna objekt. Dessa transaktioner synkas sedan mellan användarna/noderna. Varje transaktion signeras av den användare/nod som skapas transaktionen. en skickas som ett JSONobjekt. Vi vill inte hålla en separat transaktionslogg. Istället lagras varje transaktions innehåll i den underliggande SQLite-databasen. Där kan de sedan hämtas genom att man ställer frågor i databasens frågespråk. När en transaktion ska synkas till en annan användare/nod hämtas den från databasen och formateras som JSON. Ett problem är att det finns många olika sätt att beskriva samma underliggande data i JSON-format. En sträng eller ett nummer kan formateras på olika sätt. Innehållet i ett objekt kan placeras i godtycklig ordning. Man kan ha olika mängs mellanslag och radbrytningar. Detta är normalt inte ett problem, utan en styrka. Men i vårt fall blir det problem med signering. För att kontrollera en signatur måste datat som signeras kunna återskapas exakt. Därför använder vi oss av en egen delmängd av JSON som vi kallar ordnad JSON. Ordnad JSON är alltid korrekt JSON, och kan således parsas av alla JSON-bibliotek. Korrekt JSON är dock inte alltid ordnad JSON. För att skapa ordnad JSON måste man använda en rutin som är specialskriven för detta ändamål. I ordnad JSON finns det bara ett sätt att skriva en sträng eller ett nummer. Innehållet i objekt sorteras i byteordning. Användningen av mellanslag är konsekvent, radbrytningar förekommer inte. Ett problem i en distribuerad databas är att flera användare/noder kan skapa transaktioner innan dessa har hunnit synkas. Bilden nedan visar hur en sådan situation hanteras. 5

8 Anna Bosse Efter Anna och Bosse synkar Äldre transaktioner Äldre transaktioner Äldre transaktioner ab12... ab12... ab12... ed78... c53e... c53e f5... ed f5... Anna och Bosse har i detta exempel synkat fram till transaktion ab12. Därefter har Anna skapat transaktionerna ed78 och Bosse har skapat transaktionerna c53e och 98f5. När Anna och Bosse synkar bildar dessa fyra nya transaktioner en förgrening av transaktionshistoriken. Normalt har varje transaktion en förälder, och transaktionshistoriken består av en lista av transaktioner sorterade efter förälder, barn, barnbarn mm. Men eftersom Anna och Bosse skapade transaktioner utan att vara i synk, så har transaktionen ab12 två barn istället för ett. Databasdelen hanterar inte förgreningar på något speciellt sätt, utan inordnar transaktionerna i en transaktionshistorik. Istället för att ordna efter förälder, barn ordnas transaktionerna efter tiden då de skapades. Skulle två transaktioner skapas samma millisekund ordnas de efter ett hash-värde, som är slumpmässigt. Då det skapats en förgrening, och transaktionsordningen inte längre är barnförälder, kan det uppstå konflikter. Exempelvis skulle ett objekt kunna tas bort i en transaktion, samtidigt som det ändras i en senare transaktion. Konflikter hanteras per objekt. I vårt exempel sparar vi båda transaktionerna, men ändringen av objektet genomförs aldrig eftersom det tagits bort. Dessutom lagras all information om konflikten. I vårt exempel går det att hämta ändringarna av objektet, ifall de skulle vara värdefulla. Användare riskerar aldrig att permanent förlora data på grund av konflikthantering. 6

9 Efter Anna och Bosse synkar Nästa transaktion efter synkning Äldre transaktioner Äldre transaktioner ab12... ab12... c53e... c53e... ed78... ed f f5... Ny transaktion 4217 Det är inte bra med förgreningar. Därför finns det en mekanism för att läka dessa. Ifall databasen består av två grenar så kommer nästa transaktion att få två föräldrar. På så sätt lagas databasen och får en transaktionshistorik med så få förgreningar, och potentiella konflikter, som möjligt. Databasdelen innehåller ett enkelt frågespråk för att hämta information från databaser. Frågespråket är inspirerat av SQL, men använder JavaScript-syntax. Målsättningen är att kunna skriva databasfrågor direkt i ett JavaScript-program, utan att behöva använda språk i språk som när man använder SQL. I och med att databasdelen använder SQLite så är frågespråket implementerat som en parser som i sin tur generar SQL-frågor. Det gör att det är enkelt att utöka frågespråket. Förutom att ställa frågor så kan man också prenumerera på frågor. I vanliga fall får man ett svar på sin fråga. När man prenumererar får man nya svar så fort databasens innehåll ändras. Om man använder databasdelen för att implementera ett chattsystem kan man prenumerera på en fråga som hämtar de senaste meddelandena. När ett meddelande synkas in från en annan användare så kommer man direkt att få ett nytt svar från frågan man prenumererar på. Denna egenskap gör att det behövs mycket mindre programkod för att skriva en applikation där flera användare skapar data. 7

10 Behörighetssystem Behörighetssystemet kontrollerar vem som får koppla upp sig till en nod/användare. Bara användare/noder som har blivit explicit tillagda tillåts koppla upp sig. Anonyma eller okända användare/noder kan inte koppla upp sig. Behörighetssystemet kontrollerar vilka tjänster en användare/nod får koppla upp sig till. Tjänster använder nätverksbibliotekets HTTP/2- eller socket-api. Behörighetssystemet är integrerat med databasdelen. Behörigheten till databaser lagras i varje databas, inklusive behöriga användare/noders publika nycklar. En användare/nod kan ha läs, skriv eller admin-behörighet till en databas. Adminbehörighet betyder att man kan ändra vem som har behörigheter till databasen. En användare/nod som blir tillagd till en databas får en inbjudan. Det går naturligtvis att tacka nej till inbjudan. När en användare/nod tackar ja till en inbjudan kommer databasdelen att börja synkronisera den databasen. De användarna/noderna som har behörighet till databasen kommer då att läggas till i behörighetssystem. Dessa användare/noder kommer att få koppla upp sig och synka den databasen, så länge de inte explicit blockeras. Node.js C++-biblioteket finns tillgängligt som en node.js-modul. Det gör att MIST funktionalitet kan användas från både C++ och från JavaScript. Förhoppningen är att kunna göra sådana integrationer med fler programmeringsspråk, så att utvecklare kan välja. 8

11 6. Utvärdering och analys a. Utvärdering av resultat Projektet har resulterat i ett C++-bibliotek som uppfyller de funktionella kraven i projektansökan. Utöver kraven i ansökan innehåller det koppling till node.js som gör det möjligt att använda från JavaScript. Kvaliteten på kod och dokumentation kan förbättras t.ex. saknas dokumentation för hur biblioteket fungerar internt. En utvecklare som vill använda biblioteket idag behöver ha visst tålamod och vara beredd på att buggrapporter. Projektplanen var tidsoptimistiskt och vi hann inte lägg så mycket tid på testning som vi skulle önskat. Vi använder enhetstester för enskilda funktioner men hann inte bygga automattester som testade hela systemet. Det var dessutom först i slutet av projektet som vi kunde integrera de två delarna - nätverksdelen och databasdelen. Det var först efter denna integration som det gick att testa helheten. Rent tekniskt hittade vi ett antal lösningar som vi tror kommer att bli väldigt användbara. Användningen av HTTP/2 i nätverksdelen är ett exempel. Den gör dels att nätverksdelen blir enklare att implementera och underhålla, eftersom vi kan bygga på en standard. Det gör också att det blir enklare att bygga applikationer med MIST, då utvecklare kan tillämpa kunskap från webbutveckling. Att använda versionshantering både för att kunna synka mellan användare/noder, samt för att kunna bygga mer funktionalitet för användarna, är också en sådan smart lösning. Prenumeration av frågor tror vi också kommer att minska hur mycket kod som behövs för att skriva en applikation till MIST. b. Förslag på förbättringar Vi borde bli bättre på att tidsuppskatta, och arbete mer agilt så att det finns fungerande delleveranser. Det är svårt när man börjar med ett vitt papper och det finns mycket som behöver byggas innan man får funktionalitet som blir användbar. Den goda nyheten är att vi nu har ett komplett bibliotek. Det är således enkelt att arbeta agilt framöver. Vi kan nu göra mindre etapper där vi hela tiden har en fungerande version. Det är möjligt att vi borde ha valt ett annat språk än C++. Ett bibliotek i JavaScript eller TypeScript hade kunnat vara lika värdefullt för MIST-projektet. Då hade det gått snabbare att implementera och varit lättare att rekrytera utvecklare till projektet. Särskilt med tanke på att vi faktiskt skapade prototyper i JavaScript och TypeScript innan vi började implementera i C++. Å andra sidan är ett bibliotek i C++ väldigt värdefullt eftersom det kan användas från många fler språk. Ett bibliotek i JavaScript är låst till att användas i JavaScript, och måste skrivas om för att användas i ett annat programmeringsspråk. Ett bibliotek 9

12 skrivet i ett kompilerande språk som C++ kan enkelt integreras med de flesta programmeringsspråk. Vi är osäkra på om ordnad JSON var en bra design, eller om det kommer att orsaka problem framöver. Ett alternativ är vore att använda ett binärt format för lagring och synkning. Det skulle vara relativt enkelt att förbättra synkningen så att man kan återuppta hämtandet av en transaktion. Idag måste man ladda ner en hel transaktion och får börja om ifall nedladdningen avbryts. 7. Framtida arbeten Vi kommer att fortsätta utveckla MIST. Första steget är att bygga mer automattestning, förbättra dokumentationen samt göra en refactor av koden för synkning av databaser. Vi hoppas bli klara med detta arbete under våren. Därefter kommer vi att bygga en Python-modul som använder biblioteket. Att kunna skriva applikationer i C++, JavaScript och Python tror vi är viktigt för att få fler utvecklare intresserade. Sen är det dags för nästa stora steg i projektet - att börja utveckla MISTapplikationer. Vi kommer att utveckla applikationer i TypeScript och HTML5. Förhoppningen är att få till en utvecklingscykel där vi genom applikationsutvecklingen lär oss vad vi behöver förbättra i databasen. Idén är inte att skapa en generell databas som följer en matematisk modell, såsom SQLdatabaser följer relationsalgebra. Istället vill vi ha en databas som är väldigt bra på just distribuerade, sociala applikationer. Det är dessa applikationers behov som ska bestämma vilken funktionalitet vi utvecklar i databasen. Förhoppningen är förstås att vi ska attrahera fler utvecklare som utvecklar applikationer - det är ju en av de stora poängerna med fri programvara och öppen källkod. För att lyckas håller vi på att rekrytera ett advisory board till projektet. Detta för att få mer input från fler personer om hur vi bör driva projektet vidare. 10

13 plattform för säkra, distribuerade & sociala appar mist.nu visiarc.com