Mi a zero-knowledge titkosítás? Egyszerű útmutató

A zero-knowledge titkosítás azt jelenti, hogy a szolgáltató nem fér hozzá az adataidhoz.

A zero-knowledge titkosítás a szolgáltatóra korlátozott felépítés, amelyben a szolgáltatásnál nincs meg a tárolt felhasználói tartalom visszafejtéséhez szükséges kulcs. A szokásos felhőtitkosítással szemben, ahol a tartalomkulcs a szolgáltató kezében van, a kliensoldali titkosítás ezt a képességet a felhasználó eszközein tarthatja. Egy jogi megkeresés, adatszivárgás vagy belső szereplő így is felfedheti a titkosított szöveget, a fiókrekordokat, a forgalmi adatokat vagy a szolgáltató által őrzött más metaadatokat. A NIST kulcskezelési útmutatója a kulcsok őrzését teszi a hozzáférés középpontjába, de a kliensapp, az operációs rendszer és a feloldott eszköz a bizalmi határon belül marad.

Hogyan működik a zero-knowledge titkosítás

A legegyszerűbb hasonlat: egy szállodai széf, amelynek kombinációját csak te állítod be, és a szálloda soha nem tudja meg. Ha elfelejted a kombinációt, a szálloda nem tudja kinyitni neked a széfet. Ez nem tervezési hiba. Ez maga a terv.

Műszaki szempontból a zero-knowledge titkosítás három lépésben működik:

1. Kulcsszármaztatás az eszközön. A felhasználó megad egy hitelesítő adatot, például jelszót, jelmondatot vagy mintát. Egy jelszóalapú kulcsszármaztató függvény sóval kombinálja, és a felhasználó eszközén kulcsot állít elő. Egy jól elkülönített kialakítás ezzel a kulccsal egy véletlenszerű tartalomtitkosító kulcsot old fel, ahelyett hogy minden fájlt közvetlenül az emberi hitelesítő adattal titkosítana.

2. Titkosítás továbbítás előtt. Minden adat a származtatott kulccsal titkosítódik az eszközön, mielőtt felhőtárolásra vagy mentésre elhagyná az eszközt. A titkosított kimenet (titkosított szöveg) kerül feltöltésre.

3. A szolgáltató nem kap nyílt tartalomkulcsot. A tartalomkulcsok használat közben szükségszerűen léteznek a kliens memóriájában, és helyben vagy távolról hitelesített titkosított borítékokban is tárolhatók. A szolgáltató úgy tárolhat titkosított szöveget és becsomagolt kulcsokat, hogy nincs nála a megnyitásukhoz szükséges felhasználói titok. A fiók-, forgalmi, rekordméret- és időzítési metaadatok így is láthatók maradhatnak.

A döntő korlát: ha a felhasználó minden érvényes hitelesítő adatot és helyreállítási utat elveszít, a titkosított tartalom elérhetetlenné válik. Helyreállítás ettől még létezhet, de a kulcsok őrzését meg kell magyarázni. Ha önmagában egy e-mailes visszaállítás olvasható tartalmat ad vissza régi eszköz jóváhagyása, helyreállítási kifejezés, helyreállítási kulcs vagy más, a felhasználónál lévő titok nélkül, akkor a szolgáltató megtartott egy tényleges utat a nyílt szöveghez.

A zero-knowledge titkosítás és a többi titkosítási típus

A „titkosítás” szó szinte minden felhőszolgáltatás marketinganyagában megjelenik. A típusok közötti különbségek jelentősek.

A „tároláskori titkosítást” és a „zero-knowledge titkosítást” keverik össze a leggyakrabban. Tároláskori titkosításnál a szolgáltató a saját kulcsaival titkosítja az adataidat a szerverein. Ez a szerverhardver fizikai ellopása ellen véd. Az ellen nem, hogy a szolgáltató elolvassa az adataidat, hogy egy hatóság kikérje az adatokat és a kulcsokat, vagy hogy belső fenyegetés érje őket. A visszafejtés képessége a szolgáltatónál van.

A szolgáltató elől rejtett kliensoldali titkosításnál a dokumentált protokoll nem adja át a szolgáltatásnak a nyílt tartalomkulcsot. A tárolt titkosított szöveg átláthatatlan maradhat a szolgáltató számára, a kliensszoftver, a helyreállítási út, a fiókmetaadatok és a szoftverterjesztési csatorna viszont továbbra is bizalmat és ellenőrzést igényel.

Miért fontos a zero-knowledge titkosítás

Az adatszivárgások évente milliárdnyi rekordot tesznek közzé

Az Identity Theft Resource Center 2023-ban 3205 adatkompromittálást jelentett az Egyesült Államokban, amelyek körülbelül 353 millió embert érintettek. Ha a tartalomkulcsok a szolgáltatónál vannak, egyetlen feltörés a tárolt adatokat és a visszafejtésükhöz vezető utat is felfedheti. A szolgáltató elől rejtett titkosítás szétválasztja ezeket: egy szerverfeltörés így is felfedheti a titkosított szöveget és a metaadatokat, de szolgáltatónál lévő nyílt tartalomkulcsot nem. A hitelesítő adatok kitalálása és a kliens kompromittálása külön kockázat marad.

A jogi kényszer valós fenyegetés

A szolgáltatókat kötelezhetik az általuk őrzött adatok kiadására. Egy szolgáltató elől rejtett kialakítás ezt a választ a titkosított szövegre és az elérhető fiók-, forgalmi, számlázási vagy szolgáltatási metaadatokra korlátozhatja, mert a szolgáltatónál nincs nyílt tartalomkulcs. Az, hogy más fél megszerezheti-e a felhasználó hitelesítő adatát, kihasználhat-e egy klienst, vagy kikényszerítheti-e a közlést, külön kérdés. Az Apple az iOS 16.2-ben vezette be a Speciális adatvédelmet az iCloud-adatok végpontok közötti titkosításának választható kiterjesztéseként.

A „bízz bennünk” nem biztonsági felépítés

A szerveroldali titkosítás a szolgáltató által kezelt kulcsokra és szabályzatra támaszkodik. A szolgáltató elől rejtett titkosítás úgy változtatja meg a kulcsok őrzését, hogy a dokumentált szolgáltatási útból hiányzik a nyílt tartalomkulcs. Ez erősebb felépítési határ, de az ereje így is a helyes kliensoldali kódon, a hitelesített szoftverterjesztésen, a jól kialakított helyreállításon, a biztonságos eszközökön és a specifikációnak megfelelő megvalósításon múlik.

A kriptográfia mögötti NIST-szabvány

Az AES-GCM-et a National Institute of Standards and Technology szabványosította az SP 800-38D dokumentumban (2007). Magát az AES-t a NIST 2001-ben nyilvános versenyen választotta ki. Az AES-256-ban a „256” a 256 bites kulcsra utal. Egy egyenletesen véletlenszerű kulcs teljes átkutatása számítási szempontból kivitelezhetetlen, de egy emberi jelszó vagy minta jóval kevesebb entrópiát adhat, még ha a kulcsszármaztató függvény 256 bitet ad is ki.

A GCM (Galois/Counter Mode) hitelesített titkosítást ad, vagyis a visszafejtés észleli a titkosított szöveg minden manipulációját. Ha a titkosított adat egyetlen bitje is megváltozik, a visszafejtés sérült kimenet helyett meghiúsul. Így a támadók észrevétlenül nem manipulálhatják a titkosított adatot.

A PBKDF2 (Password-Based Key Derivation Function 2), amelyet az RFC 8018 határoz meg, ismételt álvéletlen függvényhívásokkal alakítja az ember által megadott hitelesítő adatot rögzített hosszúságú kulcsanyaggá. Több iteráció megemeli minden tipp költségét. Egy kiszámítható mintához vagy jelszóhoz nem ad entrópiát, így a hitelesítő adat megválasztása és az offline ellenőrzés továbbra is számít.

Hogyan valósítja meg a Vaultaire a szolgáltatói kulcsok elkülönítését

A Vaultaire kliensoldalon titkosított széf iPhone-ra. A termékmarketingben gyakran „zero-knowledge”-ként emlegetett értelemben a szűkebb, dokumentált állítása az, hogy a Wraxle nem kapja meg a nyílt széftartalmat vagy a visszafejtéséhez szükséges kulcsokat. Így működik a megvalósítás és a megmaradó bizalmi határok az egyes rétegekben.

Kulcsszármaztatás. A felhasználó mintát rajzol egy 25 pontos, 5x5-ös rácsra. A PBKDF2-HMAC-SHA512 600 000 iterációval kombinálja ezt a sorozatot egy, az egész eszközre érvényes kulcskarika-sóval, és 256 bites széfkulcsot származtat. A széfkulcs hitelesíti a titkosított indexet, és becsomagol egy külön, véletlenszerű 256 bites mesterkulcsot. A helyreállítási adatok, köztük a minta, AES-GCM-mel titkosított kulcskarika-adatbázisban vannak, nem nyílt szöveges fájlokban vagy Vaultaire-fiókban.

Fájltitkosítás. Minden importált fájl AES-256-GCM-mel titkosítódik a véletlenszerű mesterkulccsal. A CryptoKit friss nonce-okkal hitelesített lezárt dobozokat hoz létre, a folyamatos (streaming) formátum pedig minden sorrendbe állított darabhoz külön nonce-t származtat.

Metaadat-titkosítás. A fájlneveket, a MIME-típusokat, a dátumokat, az indexrekordokat és a bélyegképadatokat szintén AES-256-GCM védi. A Vaultaire nem használ ChaCha20-at a széf metaadataihoz.

Kulcskezelés. A Vaultaire az eszközsót és a titkosított helyreállítási adatbázist szokásos iOS-kulcskarika általános jelszóelemekként tárolja, a WhenUnlockedThisDeviceOnly hozzáférési osztállyal védve. A mintából származtatott széfkulcsokat és a véletlenszerű mesterkulcsokat a CryptoKit az app memóriájában kezeli. A zárolás eldobja az aktív kulcsállapotot, de a Swift és az iOS nem garantálja, hogy minden átmeneti másolat felülíródik.

Széfek felfedezése. A normál felület nem mutat széflistát. Minden széf lapjai egy közös mappában vannak, véletlen nevekkel, ezért a fájlnevekből nem derül ki, melyik fájl melyik széfhez tartozik, és mintákat, neveket vagy nyílt tartalmat sem árulnak el. Aki hozzáfér az app tárolójához, így is megbecsülheti, hány széfed van, mert a tárolóarénák száma felső korlátot ad rá. Nézd meg a teljes biztonsági felépítést és a mintatitkosítás magyarázatát.

Így derítsd ki, hogy egy app valódi zero-knowledge titkosítást használ-e

Kezdd három gyors teszttel, aztán ellenőrizd a közzétett felépítést:

1. Az elfelejtett jelszó teszt. Ha önmagában egy e-mailes visszaállítás olvasható adatot ad vissza, kérdezd meg, milyen, a szolgáltatónál lévő mechanizmus állította vissza a tényleges tartalomkulcsot. A felhasználónál lévő helyreállítási kifejezés, a régi eszköz jóváhagyása és a szolgáltató által kezelt visszaállítás különböző kialakítások.

2. Az új eszköz teszt. Ha egy új eszköz olvasható tartalmat állít vissza, derítsd ki, milyen titok vagy megbízható eszköz engedélyezte. Ha elég hozzá a fiókba való bejelentkezés, az szolgáltató által kezelt helyreállítási útra utal; egy helyreállítási kifejezés és a titkosított mentési rekordok együtt megőrizhetik a szolgáltatói kulcsok elkülönítését.

3. A fiókteszt. Egy e-mail-cím vagy telefonszám a személyazonosságot a szolgáltatási metaadatokhoz köti, de önmagában nem bizonyítja, hogy a szolgáltató vissza tudja fejteni a tartalmat. Vizsgáld meg a kulcshierarchiát, a helyreállítási kialakítást, a kliens kódját vagy auditját, a metaadat-szabályzatot, és azt, hogy a hitelesített titkosított szöveg lehetővé teszi-e a hitelesítő adatok offline ellenőrzését.

Ezek a tesztek szűrők, nem biztonsági bizonyítékok. Egy következetes specifikáció megnevezi a tartalomkulcsot, a feloldókulcsot, a sókat, a származtatási paramétereket, a hitelesített titkosítási formátumot, a nonce-szabályokat, a helyreállítási borítékokat, a helyi titoktárolást, a felhős metaadatokat, és azt a pontot, ahol nyílt kulcsok léteznek. A független felülvizsgálat erősebb bizonyíték egy termékcímkénél.

Gyakran ismételt kérdések

Ugyanaz a zero-knowledge titkosítás, mint a végpontok közötti titkosítás?

Átfedik egymást, de nem azonosak. A végpontok közötti titkosítás (E2EE) azt jelenti, hogy az adat a küldő eszközén titkosítódik, és csak a címzett eszközén fejtődik vissza. A zero-knowledge titkosítás azt jelenti, hogy a szolgáltató nem fér hozzá az adatokhoz. Egy szolgáltatás lehet végpontok között titkosított anélkül, hogy zero-knowledge lenne, ha a szolgáltató valamikor létrehozta a kulcsokat vagy hozzáfért azokhoz. A zero-knowledge titkosítás a szigorúbb mérce.

Mi történik, ha zero-knowledge titkosítás mellett elveszítem a jelszavamat?

Az adataid véglegesen elérhetetlenné válnak, ha minden érvényes hitelesítő adat és helyreállítási boríték elvész. Egy szolgáltató által kezelt visszaállítás vagy mesterkulcs gyengítené a szolgáltatói határt, ezért a helyreállítást külön kell megtervezni. A Vaultaire helyreállítási kifejezést használ, egy generált kilencszavas kifejezést vagy egy legalább hatszavas egyénit, és az ebből származtatott helyreállítási kulcs egy titkosított széfkulcs-borítékot nyit meg. A kifejezés nem állítja elő újra és nem kódolja a kulcsot, az új eszközön való visszaállításhoz pedig a hozzá tartozó titkosított CloudKit-rekordok is kellenek.

Hozzáférhetnek a hatóságok a zero-knowledge titkosítású adatokhoz?

Egy szolgáltatót kötelezhetnek a tárolt titkosított szöveg és az általa őrzött fiók-, forgalmi, számlázási vagy szolgáltatási metaadatok kiadására. Szolgáltatónál lévő nyílt tartalomkulcs nélkül a szolgáltató a szokásos szolgáltatási úton nem tudja visszafejteni a tartalmat. Az eszköz kihasználása, a hitelesítő adatok felderítése, a helyreállítási másolatok és a kikényszerített közlés külön utak, amelyek jogszerűsége és hatékonysága joghatóságonként és esetenként eltér.

Lassabb a zero-knowledge titkosítás a szokásos titkosításnál?

Az AES-256-GCM teljesítménye nem függ attól, kinél van a kulcs. A jelszóalapú származtatás a feloldáskor többletmunkát jelent, amelynek időtartama az algoritmustól, az iterációszámtól, az eszköztől és a megvalósítástól függ. Az alkalmazásoknak a támogatott hardveren kell mérniük ezt a költséget, és egyensúlyt kell teremteniük a gyors válasz és az egyes offline tippekre rótt költség között.

A zero-knowledge azt jelenti, hogy az app egyáltalán nem gyűjt adatot?

Nem feltétlenül. A kifejezés a szolgáltató tartalomkulcs-határára vonatkozik, nem minden adatfolyamra. Egy app ettől még kezelhet fiókadatokat, analitikát, összeomlási jelentéseket, IP-címeket, rekordméreteket, időzítést vagy más szolgáltatási metaadatokat. A Vaultaire-hez nem kell személyes fiók. Az app analitikája és összeomlási diagnosztikája alapértelmezés szerint be van kapcsolva, és a Beállításokban a „Hibák névtelen megosztása” kapcsolóval kikapcsolható. A dokumentált eseményszabályzat kizárja a széftartalmat, a mintákat, a kifejezéseket és a visszafejtő kulcsokat; az adatvédelmi irányelvek leírják a jelenlegi gyűjtési és megőrzési szabályokat.

Hogyan viszonyul a zero-knowledge titkosítás az Apple Speciális adatvédelméhez?

Az Apple iOS 16.2-ben bevezetett Speciális adatvédelme (ADP) további iCloud-kategóriákra terjeszti ki a végpontok közötti titkosítást, és az Apple-fiók helyreállítási modelljét használja. A Vaultaire az eszközön titkosítja a széf tartalmát, és nem kell hozzá Vaultaire-fiók; az alapértelmezés szerint bekapcsolt iCloud-mentése, valamint a szinkronizálás és a megosztás kliensoldalon titkosított CloudKit-rekordokat használ a felhasználó Apple-fiókjában. A Vaultaire mintánként elkülönített széfhozzáférést és kényszermódot is kínál, a hihető letagadhatóságról szóló dokumentációban leírt tárolási és helyreállítási korlátokkal.

Összefoglalás

A zero-knowledge titkosítást érdemes a szolgáltatói kulcsok elkülönítésére vonatkozó állításként kezelni: a szolgáltatásnál nincs meg a tárolt tartalom visszafejtéséhez szükséges nyílt kulcs. Ez erősebb a szolgáltató által kezelt kulcsokkal végzett szerveroldali titkosításnál, de nem azt állítja, hogy a kulcsok csak a memóriában léteznek, hogy a metaadatok eltűnnek, vagy hogy minden kliens- és eszközkompromittálás kivédhető. A terméket a kulcshierarchiája, a helyreállítási kialakítása, a megvalósítása és a független felülvizsgálata alapján ítéld meg.

Olvasd el a biztonsági felépítést