Mitä on zero-knowledge-salaus? Selkeä opas
Zero-knowledge-salaus tarkoittaa, että palveluntarjoaja ei pääse dataasi.
Zero-knowledge-salaus on palveluntarjoajaan rajattu arkkitehtuuri, jossa palvelulla ei ole avainta, jota tallennetun käyttäjäsisällön purkaminen vaatii. Tavallisessa pilvisalauksessa palveluntarjoaja hallitsee sisältöavainta, mutta asiakaspuolen salaus voi pitää tämän kyvyn käyttäjän laitteilla. Oikeudellinen pyyntö, tietomurto tai sisäpiiriläinen voi silti paljastaa salatekstin, tilitiedot, liikennetiedot tai muut metatiedot, joita palveluntarjoaja säilyttää. NIST:n avaintenhallintaohjeistus tekee avainten hallussapidosta pääsyn keskeisen tekijän, mutta asiakasappi, käyttöjärjestelmä ja avattu laite kuuluvat edelleen luottamusrajan sisään.
Miten zero-knowledge-salaus toimii
Yksinkertaisin vertaus: hotellin tallelokero, jonka yhdistelmän asetat vain sinä ja jota hotelli ei koskaan saa tietää. Jos unohdat yhdistelmän, hotelli ei voi avata lokeroa puolestasi. Se ei ole suunnitteluvirhe. Se on koko suunnitelma.
Teknisesti zero-knowledge-salaus toimii kolmessa vaiheessa:
Avaimen johtaminen laitteella. Käyttäjä antaa tunnistetiedon, kuten salasanan, tunnuslauseen tai kuvion. Salasanapohjainen avaimenjohtamisfunktio yhdistää sen suolaan ja tuottaa avaimen käyttäjän laitteella. Hyvin eriytetty rakenne voi käyttää tätä avainta satunnaisen sisällön salausavaimen avaamiseen sen sijaan, että jokainen tiedosto salattaisiin suoraan ihmisen tunnistetiedolla.
Salaus ennen siirtoa. Kaikki data salataan laitteella johdetulla avaimella ennen kuin se lähtee laitteelta pilvitallennukseen tai varmuuskopioon. Salattu tulos (salateksti) on se, mikä ladataan.
Palveluntarjoaja ei saa selväkielistä sisältöavainta. Sisältöavaimet ovat väistämättä asiakasohjelman muistissa käytön aikana, ja ne voidaan myös tallentaa paikallisesti tai etänä todennettujen salattujen kuorien sisään. Palveluntarjoaja voi tallentaa salatekstin ja kääretyt avaimet ilman käyttäjän salaisuutta, jota niiden avaaminen vaatii. Tili-, liikenne-, tietuekoko- ja ajoitusmetatiedot voivat silti näkyä.
Ratkaiseva rajoitus: jos käyttäjä menettää kaikki kelvolliset tunnistetiedot ja palautusreitit, salattu sisältö muuttuu saavuttamattomaksi. Palautus voi silti olla olemassa, mutta sen avainten hallinta on selitettävä. Jos pelkkä sähköpostinollaus palauttaa luettavan sisällön ilman vanhan laitteen hyväksyntää, palautuslausetta, palautusavainta tai vastaavaa käyttäjän hallussa olevaa salaisuutta, palveluntarjoajalla on edelleen toimiva reitti selväkieliseen sisältöön.
Zero-knowledge-salaus verrattuna muihin salaustyyppeihin
Sana "salaus" esiintyy lähes jokaisen pilvipalvelun markkinointimateriaalissa. Tyyppien väliset erot ovat suuria.
| Tyyppi | Kenellä avain on | Palveluntarjoaja voi lukea datan | Kestää palveluntarjoajan tietomurron | Esimerkki |
|---|---|---|---|---|
| Ei salausta | Ei koske | Kyllä | Ei | Dropbox (perustaso) |
| Salaus siirron aikana (TLS) | Palveluntarjoaja | Kyllä (levossa sen palvelimilla) | Ei | Google Kuvat |
| Palvelinpuolen salaus levossa | Palveluntarjoaja | Kyllä (sillä on purkuavain) | Osittain (riippuu murron laajuudesta) | iCloud (tavallinen) |
| Alustan päästä päähän -salaus | Asiakaslaitteet ja tilin palautusjärjestelmä | Ei tavallisen palvelureitin kautta | Riippuu asiakasohjelmasta, palautuksesta ja metatietojen paljastumisesta | iCloud ja Edistyksellinen tietosuojaus |
| Palveluntarjoajalta piilotettu asiakaspuolen salaus | Asiakasohjelma ja käyttäjän hallitsema palautusreitti | Palveluntarjoajalla ei ole selväkielistä sisältöavainta | Sisältö voi pysyä salattuna; metatietoja ja salatekstiä voi silti vuotaa | Salatut holvi- ja varmuuskopiojärjestelmät |
Ero "levossa salaamisen" ja "zero-knowledge-salauksen" välillä sekoitetaan useimmin. Levossa salaamisessa palveluntarjoaja salaa datasi palvelimillaan omilla avaimillaan. Tämä suojaa palvelinlaitteiston fyysiseltä varkaudelta. Se ei suojaa siltä, että palveluntarjoaja lukee datasi, viranomainen vaatii datan ja avaimet tai sisäpiiriläinen käyttää niitä. Purkukyky on palveluntarjoajalla.
Palveluntarjoajalta piilotetussa asiakaspuolen salauksessa palvelu ei saa selväkielistä sisältöavainta dokumentoidun protokollan kautta. Tallennettu salateksti voi pysyä palveluntarjoajalle läpinäkymättömänä, mutta asiakasohjelma, palautusreitti, tilin metatiedot ja ohjelmiston jakelukanava vaativat edelleen luottamusta ja tarkastusta.
Miksi zero-knowledge-salaus on tärkeää
Tietomurrot paljastavat miljardeja tietueita vuosittain
Identity Theft Resource Center raportoi Yhdysvalloissa 3 205 tietomurtoa vuonna 2023, ja ne koskivat noin 353 miljoonaa ihmistä. Kun sisältöavaimet ovat palveluntarjoajalla, yksi tietomurto voi paljastaa sekä tallennetun datan että keinon purkaa se. Palveluntarjoajalta piilotettu salaus erottaa nämä: palvelinmurto voi silti paljastaa salatekstin ja metatiedot, mutta ei palveluntarjoajan hallussa olevaa selväkielistä sisältöavainta. Tunnistetietojen arvaaminen ja asiakasohjelman murtaminen ovat erillisiä riskejä.
Oikeudellinen pakko on todellinen uhka
Palveluntarjoajat voidaan velvoittaa luovuttamaan säilyttämänsä data. Palveluntarjoajalta piilotettu rakenne voi rajata luovutuksen salatekstiin ja saatavilla oleviin tili-, liikenne-, laskutus- tai palvelumetatietoihin, koska palveluntarjoajalla ei ole selväkielistä sisältöavainta. Se, voiko joku muu saada käyttäjän tunnistetiedon, hyödyntää asiakasohjelman haavoittuvuutta tai pakottaa luovutukseen, on erillinen kysymys. Apple toi Edistyksellisen tietosuojauksen iOS 16.2:ssa valinnaiseksi laajennukseksi iCloud-datan päästä päähän -salaukseen.
"Luota meihin" ei ole tietoturva-arkkitehtuuri
Palvelinpuolen salaus nojaa palveluntarjoajan hallitsemiin avaimiin ja käytäntöihin. Palveluntarjoajalta piilotettu salaus muuttaa avainten hallussapitoa niin, että dokumentoidulla palvelureitillä ei ole selväkielistä sisältöavainta. Se on vahvempi arkkitehtoninen raja, mutta sen teho riippuu edelleen oikeasta asiakaskoodista, todennetusta ohjelmistojakelusta, toimivasta palautuksesta, turvallisista laitteista ja toteutuksesta, joka vastaa määrittelyä.
Salauksen taustalla oleva NIST-standardi
National Institute of Standards and Technology (NIST) standardoi AES-GCM:n julkaisussa SP 800-38D (2007). NIST valitsi itse AES:n julkisessa kilpailussa vuonna 2001. Nimen AES-256 luku "256" viittaa 256-bittiseen avaimeen. Tasaisen satunnaisen avaimen täydellinen läpikäynti on laskennallisesti mahdotonta, mutta ihmisen valitsemassa salasanassa tai kuviossa voi olla paljon vähemmän entropiaa, vaikka avaimenjohtamisfunktio tuottaisi 256 bittiä.
GCM (Galois/Counter Mode) lisää todennetun salauksen: purkuvaihe havaitsee kaiken salatekstin peukaloinnin. Jos salatusta datasta muutetaan yksikin bitti, purku epäonnistuu eikä tuota vioittunutta tulosta. Näin hyökkääjä ei voi muokata salattua dataa huomaamatta.
PBKDF2 (Password-Based Key Derivation Function 2), joka on määritelty julkaisussa RFC 8018, muuntaa ihmisen antaman tunnistetiedon kiinteän pituiseksi avainmateriaaliksi toistuvilla näennäissatunnaisfunktion kutsuilla. Useammat iteraatiot nostavat jokaisen arvauksen hintaa. Ne eivät lisää ennustettavan kuvion tai salasanan entropiaa, joten tunnistetiedon valinta ja offline-tarkistus ovat edelleen tärkeitä.
Miten Vaultaire toteuttaa palveluntarjoajan avainten erottelun
Vaultaire on asiakaspuolella salattu holvi iPhonelle. Markkinoinnissa tällaista kutsutaan usein nimellä "zero knowledge", mutta sen suppeampi dokumentoitu väite on, että Wraxle ei saa selväkielistä holvin sisältöä eikä avaimia sen purkamiseen. Näin toteutus ja jäljellä olevat luottamusrajat toimivat kullakin tasolla.
Avaimen johtaminen. Käyttäjä piirtää kuvion 5x5-ruudukolle, jossa on 25 pistettä. PBKDF2-HMAC-SHA512 yhdistää tämän sarjan yhteen koko laitteen yhteiseen Avainnipun suolaan 600 000 iteraatiolla ja johtaa 256-bittisen holviavaimen. Holviavain todentaa salatun hakemiston ja käärii erillisen satunnaisen 256-bittisen pääavaimen. Palautustiedot, kuvio mukaan lukien, tallennetaan AES-GCM-salattuun Avainnipun tietokantaan eikä selväkielisiin tiedostoihin tai Vaultaire-tiliin.
Tiedostojen salaus. Jokainen tuotu tiedosto salataan AES-256-GCM:llä satunnaisen pääavaimen alla. CryptoKit luo todennettuja sinetöityjä laatikoita tuoreilla nonce-arvoilla, ja suoratoistomuoto johtaa jokaiselle järjestetylle lohkolle oman noncen.
Metatietojen salaus. Myös tiedostonimet, MIME-tyypit, päivämäärät, hakemistotietueet ja pikkukuvadata suojataan AES-256-GCM:llä. Vaultaire ei käytä ChaCha20:tä holvin metatiedoille.
Avaintenhallinta. Vaultaire tallentaa laitesuolansa ja salatun palautustietokantansa tavallisina iOS:n Avainnipun yleisinä salasanakohteina, joita suojaa käytettävyysluokka WhenUnlockedThisDeviceOnly. Kuviosta johdettuja holviavaimia ja satunnaisia pääavaimia käsitellään apin muistissa CryptoKitin kautta. Lukitseminen pudottaa aktiivisen avaintilan, mutta Swift ja iOS eivät takaa, että jokainen väliaikainen kopio ylikirjoitetaan.
Holvien löytäminen. Tavallinen käyttöliittymä ei näytä holviluetteloa. Kaikkien holvien sivut ovat yhdessä jaetussa kansiossa satunnaisin nimin, joten tiedostonimistä ei näe, mihin holviin tiedosto kuuluu, eivätkä ne paljasta kuvioita, nimiä tai selväkielistä sisältöä. Henkilö, jolla on pääsy apin säiliöön, voi silti arvioida, montako holvia sinulla on, koska tallennusareenoiden määrä rajaa sen. Katso koko tietoturva-arkkitehtuuri ja kuviosalauksen selitys.
Miten tunnistaa, käyttääkö appi aitoa zero-knowledge-salausta
Aloita kolmella nopealla testillä ja tarkista sitten julkaistu arkkitehtuuri:
Unohtuneen salasanan testi. Jos pelkkä sähköpostinollaus palauttaa luettavan datan, kysy, millä palveluntarjoajan hallussa olevalla mekanismilla toimiva sisältöavain palautettiin. Käyttäjän hallussa olevat palautuslauseet, vanhan laitteen hyväksyntä ja palveluntarjoajan hallitsemat nollaukset ovat eri rakenteita.
Uuden laitteen testi. Jos uusi laite palauttaa luettavan sisällön, selvitä, mikä salaisuus tai luotettu laite sen valtuutti. Pelkkä tilille kirjautuminen viittaa palveluntarjoajan hallitsemaan palautusreittiin. Palautuslause yhdessä salattujen varmuuskopiotietueiden kanssa voi säilyttää palveluntarjoajan avainten erottelun.
Tilitesti. Sähköpostiosoite tai puhelinnumero yhdistää henkilöllisyyden palvelun metatietoihin, mutta se ei yksinään todista, että palveluntarjoaja voi purkaa sisällön. Tarkista avainhierarkia, palautuksen rakenne, asiakaskoodi tai auditointi, metatietokäytäntö ja se, sallivatko todennetut salatekstit tunnistetietojen tarkistamisen offline-tilassa.
Nämä testit ovat suodattimia, eivät tietoturvatodiste. Johdonmukaisen määrittelyn tulee nimetä sisältöavain, avausavain, suolat, johtamisparametrit, todennetun salauksen muoto, nonce-säännöt, palautuskuoret, paikallinen salaisuuksien säilytys, pilven metatiedot ja kohta, jossa selväkieliset avaimet ovat olemassa. Riippumaton arviointi on vahvempi todiste kuin tuotteen nimike.
Usein kysytyt kysymykset
Onko zero-knowledge-salaus sama asia kuin päästä päähän -salaus?
Ne ovat osittain päällekkäisiä, mutta eivät samoja. Päästä päähän -salaus (E2EE) tarkoittaa, että data salataan lähettäjän laitteella ja puretaan vain vastaanottajan laitteella. Zero-knowledge-salaus tarkoittaa, että palveluntarjoaja ei pääse dataan. Palvelu voi olla päästä päähän -salattu olematta zero-knowledge, jos palveluntarjoaja on jossain vaiheessa luonut avaimet tai sillä on pääsy niihin. Zero-knowledge-salaus on tiukempi vaatimus.
Mitä tapahtuu, jos kadotan salasanani zero-knowledge-salauksessa?
Datasi muuttuu pysyvästi saavuttamattomaksi, jos kaikki kelvolliset tunnistetiedot ja palautuskuoret katoavat. Palveluntarjoajan hallitsema nollaus tai pääavain heikentäisi palveluntarjoajan rajaa, joten palautus on suunniteltava erikseen. Vaultaire luo mukautetun yhdeksän sanan lauseen, jonka johdettu palautusavain avaa salatun holviavaimen kuoren. Lause ei luo avainta uudelleen eikä koodaa sitä, ja palautus uudelle laitteelle vaatii myös vastaavat salatut CloudKit-tietueet.
Pääsevätkö viranomaiset zero-knowledge-salattuun dataan?
Palveluntarjoaja voi joutua luovuttamaan tallennetun salatekstin sekä säilyttämänsä tili-, liikenne-, laskutus- tai palvelumetatiedot. Ilman palveluntarjoajan hallussa olevaa selväkielistä sisältöavainta se ei voi purkaa sisältöä tavallista palvelureittiään. Laitteen murtaminen, tunnistetietojen selvittäminen, palautuskopiot ja pakotettu luovutus ovat erillisiä reittejä, joiden laillisuus ja teho vaihtelevat lainkäyttöalueen ja tosiseikkojen mukaan.
Onko zero-knowledge-salaus hitaampi kuin tavallinen salaus?
AES-256-GCM:n suorituskyky ei riipu siitä, kenellä avain on. Salasanapohjainen avaimen johtaminen lisää työtä avaamisen aikana, ja sen kesto riippuu algoritmista, iteraatioiden määrästä, laitteesta ja toteutuksesta. Appien tulee mitata tämä kustannus tuetulla laitteistolla ja tasapainottaa reagointikyky ja jokaiselle offline-arvaukselle asetettu hinta.
Tarkoittaako zero-knowledge, ettei appi kerää dataa lainkaan?
Ei välttämättä. Termi koskee palveluntarjoajan sisältöavaimen rajaa, ei jokaista tietovirtaa. Appi voi silti käsitellä tilitietoja, analytiikkaa, kaatumisraportteja, IP-osoitteita, tietueiden kokoja, ajoitustietoja tai muita palvelun metatietoja. Vaultaire ei vaadi tunnistetiliä. Sen appianalytiikka ja kaatumisdiagnostiikka ovat oletuksena päällä, ja ne voi poistaa käytöstä Asetuksissa kohdasta ”Jaa virheet nimettömästi”. Dokumentoitu tapahtumakäytäntö sulkee pois holvin sisällön, kuviot, lauseet ja purkuavaimet. Tietosuojakäytäntö kuvaa nykyiset keruu- ja säilytyssäännöt.
Miten zero-knowledge-salaus vertautuu Applen Edistykselliseen tietosuojaukseen?
Applen Edistyksellinen tietosuojaus (ADP), joka tuli iOS 16.2:ssa, laajentaa päästä päähän -salauksen uusiin iCloud-luokkiin ja käyttää Apple-tilin palautusmallia. Vaultaire salaa holvin sisällön laitteella eikä vaadi Vaultaire-tunnistetiliä. Sen iCloud-varmuuskopio, joka on oletuksena päällä, sekä synkronointi ja jakaminen käyttävät asiakaspuolella salattuja CloudKit-tietueita käyttäjän Apple-tilillä. Vaultaire tarjoaa myös kuvioilla erotetun pääsyn holveihin ja pakotustilan. Tallennuksen ja palautuksen rajat on kuvattu sen kiistettävyyden dokumentaatiossa.
Yhteenveto
Zero-knowledge-salausta kannattaa pitää palveluntarjoajan avainten erottelua koskevana väitteenä: palvelulla ei ole selväkielistä avainta, jota tallennetun sisällön purkaminen vaatii. Se on vahvempi kuin palvelinpuolen salaus palveluntarjoajan hallitsemilla avaimilla, mutta se ei väitä, että avaimet ovat olemassa vain muistissa, että metatiedot katoavat tai että jokainen asiakasohjelman ja laitteen murto torjutaan. Arvioi tuotetta sen avainhierarkian, palautuksen rakenteen, toteutuksen ja riippumattoman arvioinnin perusteella.