KeyMeld: Yleinen Avain iPhoneen ja Androidiin sekä Zero Vault -arkkitehtuuri projektille

Kross-platformisilla sovelluksilla on ongelma, jonka käyttäjä ei yleensä huomaa. Näytöllä hän näkee yhden tilin ja odottaa samanlaista toimintaa kaikilla laitteilla. Mutta sisäisesti iPhone ja Android käyttävät erilaisia suojausmekanismeja ja käsittelevät paikallisia avaimia eri tavoin.

iPhonessa sovellus voi suojata paikallisen laitteen avaimen Apple Keychainin avulla. Androidin kohdalla tätä varten käytetään Android Keystorea. Nämä teknologiat on suunniteltu siten, että herkät avaimet pysyvät laitteen suojatussa ympäristössä, mutta ne eivät ole keskenään vaihdettavissa.

Käyttäjälle sillä ei ole merkitystä. Hän haluaa vain avata sovelluksen iPhonessa, asentaa sen Androidiin ja jatkaa työskentelyä samoilla suojatuilla tiedoilla.

Kehittäjälle tämä herättää arkkitehtuurisia kysymyksiä: miten järjestää yleinen pääsy kahdella alustalla, äläkä siirrä paikallisia laitekohtaisia avaimia tai kopioi niitä backendin tietokantaan?

Tutkiessani KeyMeldiä huomasin, että palvelu tarjoaa tähän tarkoitukseen erillisen yleisen avaimen, joka ei puutu iOS:n eikä Androidin sisäiseen suojausmekanismiin.

Yleinen avain eri alustoille

Paikallinen laiteavain liittyy tiettyyn puhelimeen ja sitä suojaa vastaavan käyttöjärjestelmän teknologia. Se pysyy laitteen suojatussa ympäristössä eikä ole tarkoitettu siirrettäväksi vapaasti laitteiden välillä.

KeyMeldin yleinen avain on eri asia. Se luodaan tietylle projektille, tilille ja suojatulle alueelle ja siitä tulee yhteinen kaikkien siihen kirjautuneiden asiakkaiden välillä eri alustoilla.

Palvelu ei poimi avainta iPhonelta, ei siirrä sitä Androidiin eikä yritä tehdä niistä yhtenäistä avainta. Alustakohtainen suojaus säilyy itsenäisenä, ja sovellus saa yhteisen pääsyn tason projektiinsa.

Tämä määrittää KeyMeldin arkkitehtuurisen roolin. Se ei tee iOS:sta ja Androidista samanlaisia eikä korvaa niiden sisäisiä mekanismeja. Se lisää yhteisen tason, jonka avulla projekti ei joudu itse hallitsemaan alustojen välistä avainten jakamista.

Eri tuotteille ja tileille luodaan erilliset avainalueet. Näin jokainen projekti säilyttää oman pääsytasonsa, ja useat tilit samalla laitteella pysyvät erillään.

Zero Vault kuuluu projektille

On tärkeää täsmentää heti, että Zero Vault ei ole KeyMeldin nimi. Kyseessä on arkkitehtuurimalli, jonka liitetty tuote voi rakentaa.

KeyMeld toimii erillisenä SaaS-palveluna. Sitä ei asenneta sovelluksen backendin sisälle eikä sijoiteta projektin tietokannan viereen yhtenä ohjelmallisena moduulina. Yleinen avain hoidetaan itsenäisen KeyMeld SaaS-konseptin kautta, ulkopuolella sovelluksen backendistä.

Jotta tämä malli säilyisi, luottamuksen rajojen projektiin ja KeyMeldiin pitää olla erilliset. Backendin ja ulkoisen palvelun tunnistetiedot, käyttöoikeudet ja hallintamekanismit ovat toisistaan erillisiä.

Tämä tulos arkkitehtuurissa voidaan nimittää Zero Vault -malliksi: sen palvelinperusta ei säilytä avainta asiakaspuolen suojatusta tallennustilasta.

Zero Vault ei tarkoita, että sovelluksen backend ei säilyttäisi mitään. Siinä pysyvät edelleen tilit, asetukset, liiketoimintatiedot ja kaikki sovelluksen toiminnan kannalta tarpeellinen. Mutta yleistä avainta ei säily missään näiden yhteydessä.

Palvelimen tietokannan kompromettoiminen ei sinänsä paljasta yleistä avainta, koska sitä ei säilytetä tilien tai muiden palvelininformaation kanssa. Tämä malli ei kuitenkaan lupaa, että mahdollinen järjestelmän häiriö olisi automaattisesti vaaraton. Se ratkaisee tietyn ongelman — poistaa välttämättömyyden säilyttää yleinen avain asiakkaan tallennustilassa tietokannassa.

Elävä skenaario: yksi tili iPhonessa ja Androidissa

Kuvitellaan sovellus, jossa on paikallisesti suojatut tiedot. Se voi olla esimerkiksi tunnistimeen perustuva sisäänkirjautumisjärjestelmä, yrityssovellus tai mikä tahansa palvelu, joka käsittelee salattuja tietoja suoraan laitteella.

iPhonessa sovellus suojaa paikallisen avaimen iOS:n mekanismeilla. Androidissa käytetään Androidin omaa suojausmekanismia. Laitteiden sisäiset avaimet eroavat kyllä, eikä sekään ole ongelma.

Ilman erillistä yhteistä kerrosta kehittäjän olisi täytynyt ratkaista, miten pääsy yhteisiin suojattuihin tietoihin järjestetään molemmilla alustoilla. Alustokohtainen tallennus olisi pysynyt erillään, ja tuotteen olisi ollut itse sovitettava nämä kaksi toteutusta yhteen.

Voitaisiin luoda erillisiä malleja iOS:lle ja Androidille, siirtää paikallisia avaimia manuaalisesti tai säilyttää niitä kopioina palvelimella.

KeyMeld mahdollistaa paikallisten avainten siirron ja kopioiden säilyttämisen palvelimella pois sulkematta sitä, vaan lisäämällä yhteisen yleisen avaimen.

iPhonen ja Androidin asiakkaat saavat pääsyn samaan yleiseen avaimeen samalla projekti- ja tilitasolla. Samalla kumpikin puhelin käyttää omaa suojausteknologiaansa.

Käyttäjälle tämä näyttää yhtenä tilinä eri laitteilla. Hän ei tarvitse tietää, mikä suojaus toimii iPhonessa tai Androidissa.

Uuden puhelimen vaihdossa ei tarvitse viedä paikallista avainta vanhasta laitteesta tai luoda uutta suojattua tallennustilaa uudelle alustalle. Uusi asiakas liittyy samaan projektiin ja saa pääsyn samaan yleiseen avaimeen.

Backend osallistuu pyynnön vahvistamiseen, mutta yleinen avain on tarkoitettu vain valtuutetulle asiakkaalle eikä sitä säilytetä sovelluksen serverissä.

KeyMeld ei myöskään siirrä sovelluksen tietokantaa eikä korvaa käyttäjätietojen synkronointijärjestelmää. Sen tehtävä on yksinkertaisesti tarjota asiakasavain suojattujen tietojen käsittelyyn. Tallennustilaa ja sen päivitystä vastaa itse tuote.

Kolme erilaista avaintyyppiä ja sekretia

Jotta arkkitehtuurin eri osat pysyisivät selkeinä, on hyvä erottaa kolme käsitettä.

• Paikallinen laiteavain kuuluu tiettyyn puhelimeen ja sitä suojaa iOS:n tai Androidin mekanismi.

• Yleinen avain on tietyn projektin ja tilin autorisoitujen asiakkaiden käytössä. Se yhdistää eri alustat itse sovelluksessa.

• Palvelinasetti on backendille tarkoitettu salainen avain, jolla käytetään suojattua vuorovaikutusta KeyMeldin kanssa. Sitä ei jaeta mobiilisovellukselle tai selaimelle.

Salaista avainta ja yleistä avainta käytetään eri tarkoituksiin. Zero Vault -arkkitehtuurissa yleistä avainta ei säilytä sovelluksen tietokannassa aside backendin tiedoista.

KeyMeldin käyttö ei vaadi henkilön nimeä, salasanaa, TOTP-tallennetta tai liiketoimintatietojen sisältöä. Palvelulle tärkeämpää on projekti-, tili-, ja oikeustieto, jotka oikeuttavat yleisen avaimen saavuttamiseen.

Pääsy avaimeen pysyy hallinnassa

Yleisen avaimen saaminen ei ole automaattinen oikeus kaikilla asiakkailla.

Jos laitetta ei enää voida pitää luotettavana, tilan status muuttuu tai järjestelmä peruuttaa pääsyn projektiin, KeyMeld voi lopettaa yleisen avaimen jakelemisen tälle asiakkaalle.

On tärkeää olla tekemättä liian laajoja johtopäätöksiä. Tämä ei tarkoita, että vanha paikallinen avain häviäisi automaattisesti. Kyse on siitä, että kontrolli avaimen lisäantoon ja uusien asiakkaiden liittymiseen pysyy hallinnassa.

Käyttäjän näkökulmasta tämä merkitsee sitä, että uusien laitteiden liittäminen ja niiden pääsyn hallinta avaimen jakoon kuuluu samaan järjestelmään.

Kehittäjän näkökulmasta tämä tarkoittaa, että tällaisia logiikoita ei tarvitse rakentaa erikseen iOS:lle ja Androidille. Lopullinen Zero Vault -malli riippuu edelleen siitä, säilyttääkö projekti yleisen avaimen itsellään ja pysyykö infrastruktuurinsa erillisenä kenttäroska SaaS-konseptin kanssa.

Mitä KeyMeld ei tee

KeyMeld ei ole salasanojen hallintaohjelma eikä säilytä käyttäjän TOTP-talleja. Se ei ole pilvipohjainen sovellustietokanta eikä korvaa käyttäjän synkronointijärjestelmiä.

Se ei korvaa Apple Keychainia tai Android Keystorea. Palvelu säilyttää paikalliset laite- ja alustan mekanismit, mutta lisää yhteisen tason sovellukselle.

Se ei myöskään ole käyttäjän tunnistuksen ja validoimisen pakollinen palvelu. Tunnistukseen ja pääsynhallintaan voi olla oma palvelunsa, kuten MeldID, kun taas KeyMeld tarjoaa erillisen avaimen pienemmän sovelluksen käyttöön ilman, että sitä säilytetään omaan backendiin.

Lopuksi, KeyMeld ei automaattisesti tee Zero Vaultista. Se tarjoaa projektille ulkoisen yleisen avaimen konseptin. Säilyttääkseen tämän arkkitehtuurin, kehittäjän ei pidä säilyttää yleistä avaimea omassa palvelininfrastruktuurissaan. Luottamukselliset ja erilliset alueet pitää pysyä jaettuina.

Kenelle tämä saattaa olla hyödyksi

Tällainen lähestymistapa sopii sovelluksille, jotka toimivat useilla alustoilla heti ja käyttävät paikallista suojausta sisältäviä tietoja.

Eli esimerkiksi tunnistintoteutukset, yrityssovellukset, SaaS-tuotteet, monilaitteiset palvelut ja kaikki projektit, joissa yksi tili toimii samalla tavalla iPhonessa ja Androidissa.

Kehittäjälle tämä ei ainoastaan vähennä alustakohtaisten logiikoiden määrää, vaan antaa myös mahdollisuuden jakaa vastuut. Tuotantotason backend säilyttää omat tietonsa, ja ulkoinen SaaS-palvelu, kuten KeyMeld, tarjoaa yleisen avaimen ja hallinnoi sen jatkotoimitusta.

Projektista tutustuessani kuvailisin KeyMeldiä ennemmin työkaluna kuin valmiina Zero Vault -mallina, jonka avulla kehittäjä voi rakentaa kyseisen mallin omaan tuotteeseensa.

iOS ja Android käyttävät edelleen omia suojausmekanismejaan. Asiakkaat saavat yhteisen yleisen avaimen. Sovelluksen backend, jos se ei säilytä avainta itsellään ja pitää infrastruktuurinsa erillisenä KeyMeldistä, ei muutu arkkitehtuurisesti varastoksi, jossa avain säilyisi.

Käyttäjälle tämä tarkoittaa yhtä pääsyä eri alustoilla, kehittäjälle mahdollista ulkoistaa yleisen avaimen omaan backendiin, ja projektissa ensisijaisesti Zero Vault -arkkitehtuuria, jossa palvelin ei säilytä asiakkaan suojattua avainta.

Lisätietoja projektista: KeyMeld