• Så här fungerar säkerheten i Egendata

  • Säkerheten i Egendata är självklart väldigt central. Ett stort arbete är nedlagt i att hitta en bra kombination av säkra krypteringslösningar som ändå blir enkla att använda både för användaren och tjänsteleverantörer. Dessutom måste de gå att implementera på många plattformar, både på anslutande tjänster och i telefonen. Förutom kryptering som beskrivs nedan är även den distribuerade och användarkontrollerade lagringen en del av säkerhetslösningen.

    Vi använder oss av moderna krypteringsbibliotek som redan finns inbyggda i webbläsare och mobiltelefoner

    Vi använder JWE (JSON Web Encryption) som format för krypterat innehåll. JWE i sig kan användas med flera olika algoritmer men den som vi har valt är AES128CBC (ev. blir det AES256CBC) för kryptering av den faktiska informationen. AES är ett extremt säkert (även kvantsäkert), symmetriskt krypto.

    För varje dokument som krypteras genereras en symmetrisk nyckel (i praktiken 128 slumpade bits, alt. 256 bits om vi väljer AES256). Med den nyckeln kan man alltså avkryptera innehållet. Nyckeln krypteras sedan mha asymmetriskt krypto (RSA), en gång för varje part som har rätt att läsa.

    Alla läsare får egna nycklar som krypteras med asymmetrisk kryptering

    Läsnycklarna genereras hos varje service samt i mobilappen för dig som användare. Varje, enskild läsrättighet får ett eget nyckelpar. Så som RSA fungerar, finns det en publik och en privat nyckel. Den publika är "allmänt" känd och kan kryptera information medan den privata är hemlig och kan användas för att avkryptera information.

    Du som användare har dina egna nycklar lagrade på ett ställe: din telefon och kan när som helst dra tillbaka nycklar för olika tjänster

    Din tjänst (eller du själv via mobilen) kommer alltså ha en nyckel för innehållet vilken ligger med dokumentet och som är krypterad med din publika nyckel. När du hämtar dokumentet, använder du din privata nyckel för att avkryptera dokumentnyckeln och därefter använder du dokumentnyckeln för att avkryptera informationen. När en användare drar tillbaka sitt medgivande för läsning, krypteras informationen om med en ny, slumpad, symmetrisk nyckel vilken biläggs krypterad med publika nycklar för de som fortfarande har läsrättigheter (dock ingen nyckel för den tjänst som just förlorade sitt medgivande). Det gör att informationen inte längre är läsbar.

    Varje gång informationen uppdateras används en ny sk. initialiseringsvektor. Detta, i kombination med krypteringsalgoritmen, gör att du inte heller kan avgöra vad i informationen som har ändrats om du saknar läsrättighet. Protokollet läcker därmed inte metainformation.

    Som utvecklare är det ändå enkelt att komma igång

    Allt detta sköts internt av de kodbibliotek vi tar fram så även om det låter komplicerat kommer det vara enkelt för utvecklare att implementera Egendata som lagringsplattform.

    Här finns en instruktion för hur du enklast kommer igång

    Men... ÄR det säkert?

    Informationssäkerhet är svårt. Det är lätt att begå misstag. När information läcker beror det inte på att algoritmer som AES och RSA har forcerats utan på att de har implementerats fel eller att nycklar har läckt.

    En central del av vårt säkerhetsarbete är att publicera koden öppet. Om du är kunnig inom infosec. och/eller kryptering får du mer än gärna gå igenom lösningen och hjälpa oss leta efter hål – vi uppskattar all hjälp vi kan få. Om du dessutom lämnar en Pull Request blir vi ännu gladare.

    Hur kommer jag i kontakt med er?

    Vill du testa och använda tjänsten eller har feedback på ovanstående lösning är vi väldigt glada för din input. Vi är fullt medvetna om komplexiteten i vad vi försöker lösa och vill därför gärna höra din feedback eller förslag på förbättringar.

    Koden hittar du här (lämna gärna issues eller pull-requests där)

    För att komma i kontakt med oss är det enklast att ansluta till vår Slack

    Tack för att du intresserade dig för Egendata!