Mi a végpontok közötti titkosítás? Így védi a fotóidat

Mi a végpontok közötti titkosítás? Így védi a fotóidat

A végpontok közötti titkosítás távol tartja a tárhelyszolgáltatótól az olvasható fotótartalmat és a nyílt tartalomkulcsokat.


A végpontok közötti titkosítás (E2EE) olyan biztonsági modell, amelyben a nyílt szöveget egy jogosult végpont titkosítja, és egy másik fejti vissza. A tárhely- vagy átviteli szolgáltatónál nincs nyílt tartalomkulcs. Ez a határ megvédi a tartalmat attól, hogy a szerveroldalon közvetlenül elolvassák, de nem rejt el minden metaadatot, és nem véd egy kompromittált végpontot, helyreállítási hitelesítő adatot, megosztott címzettet vagy rosszindulatú kliensfrissítést.

Fotótárolásnál a végpontok közötti titkosítás azt jelenti, hogy a telefonod feltöltés előtt titkosítja a fotók tartalmát, és a felhő olvasható képek helyett titkosított szöveget tárol. A visszafejtéshez egy jogosult eszközön vagy helyreállítási úton elérhető kulcs kell. A fájlméret, az időzítés, a fiókadatok, a megosztási kapcsolatok és más metaadatok láthatók maradhatnak. Ez az útmutató elmagyarázza ezt a határt, és összehasonlítja a gyakori szolgáltatási modelleket.

Hogyan működik a végpontok közötti titkosítás?

Az alapmechanizmus három szakaszból áll: kulcsgenerálás, titkosítás és visszafejtés.

Kulcsgenerálás

A felhasználó eszköze kriptográfiai kulcsot generál. Szimmetrikus titkosításnál (például AES-256) ugyanaz a kulcs titkosít és fejt vissza. Aszimmetrikus titkosításnál (például RSA) nyilvános kulcs titkosít, és privát kulcs fejt vissza. Sok E2EE-rendszer a kettőt kombinálja: az aszimmetrikus titkosítással egy szimmetrikus munkamenetkulcsot cserélnek, amely aztán a tömeges titkosítást végzi.

A fotószéf-alkalmazások többféle kulcskezelést használnak. Egyesek közvetlenül jelszóból származtatnak fájlkulcsot; az erősebb, rétegzett kialakítások egy hitelesítő adatból származtatott feloldókulccsal csomagolnak be egy véletlenszerű fájlkulcsot. A Vaultaire PBKDF2-HMAC-SHA512-vel 256 bites széfkulcsot származtat egy 5x5-ös mintából és egy, az egész eszközre érvényes sóból. Ez a széfkulcs hitelesíti a titkosított indexet, és kicsomagol egy külön, véletlenszerű mesterkulcsot, amely a fájlokat titkosítja.

Titkosítás

A nyílt szöveg (a fotód) a titkosítási kulcs és egy titkosítási algoritmus segítségével titkosított szöveggé alakul. Erre a célra az AES-256-GCM a legelterjedtebb szimmetrikus rejtjel. A GCM (Galois/Counter Mode) hitelesített titkosítást ad – titkosítja az adatot, és hitelesítő címkét is készít, amely minden manipulációt észlel. Minden fájl egyedi inicializálóvektort (IV) kap, így az azonos fájlokból is eltérő titkosított szöveg lesz.

Visszafejtés

A címzett eszköze ugyanazzal a kulccsal (szimmetrikus) vagy a hozzá tartozó privát kulccsal (aszimmetrikus) fordítja vissza az átalakítást. A helyes kulcs nélkül a titkosított szöveg megkülönböztethetetlen a véletlen adattól. Nincs matematikai rövidítés. Az AES-256-nak 2^256 lehetséges kulcsa van – több, mint a megfigyelhető világegyetem atomjainak becsült száma.

Végpontok közötti titkosítás és más titkosítási modellek

Nem minden titkosítás végpontok közötti. A különbségek határozzák meg, ki fér hozzá az adataidhoz.

Titkosítás átvitel közben (TLS/SSL)

Az adat az eszközöd és a szerver között titkosítva halad. A szerver megérkezéskor visszafejti. Ez véd a lehallgatás ellen az átvitel során, de a szerveren olvasható marad az adat. Minden nagy felhőszolgáltatás használ átvitel közbeni titkosítást. Ez az alapszint, nem a mérce.

Titkosítás tároláskor (szerveroldali)

A szerver a saját maga által kezelt kulcsokkal titkosítja a tárolt adatokat. Ez véd a szerverhardver fizikai ellopása ellen, de a szolgáltatóval, annak munkatársaival vagy a szolgáltatóhoz intézett jogi megkeresésekkel szemben nem. Az iCloud, a Google Drive és a Dropbox is szerveroldali titkosítást használ tároláskor. A kulcsok a szolgáltatónál vannak.

Végpontok közötti titkosítás

Az adat egy jogosult végponton titkosítódik, mielőtt a tárhelyszolgáltató megkapná. Egy jó kialakítás kívül tartja a nyílt tartalomkulcsot a szolgáltató rutinszerű szerveroldali őrizetén, így egy csak a tárhelyet érintő feltörés vagy a tárolt tartalomra vonatkozó jogi megkeresés olvasható fotók helyett titkosított szöveget ad. A szolgáltató ettől még átadhat titkosított szöveget és metaadatokat, terjesztheti a klienst, vagy üzemeltethet helyreállítási és megosztási rendszereket, amelyeket a fenyegetési modellbe is bele kell számítani.

Titkosítási modell Kinél vannak a kulcsok Olvashatja a szolgáltató az adatokat? Véd a szolgáltatóval szemben?
Csak átvitel közben (TLS) Szerver Igen Nincs
Tároláskor (szerveroldali) Szerver Igen Nincs
Végpontok közötti Jogosult végpontok vagy helyreállítási kulcsok birtokosai Pusztán a tárolt titkosított szövegből nem Véd a tartalomra a szolgáltatónál lévő tárolókulcsokkal szemben
A szolgáltató elől rejtett kliensoldali titkosítás A kliens és a dokumentált helyreállítási utak A kialakításból adódóan nincs hozzáférése a nyílt tartalomhoz Védi a tartalmat; a metaadatok és a kliensbe vetett bizalom megmarad

Hogyan kezelik a titkosítást a fotótárhely-szolgáltatások?

A titkosítási modell szolgáltatásonként jelentősen eltér. Egyesek „titkosítást” hirdetnek a modell megnevezése nélkül, ami elhitetheti a felhasználókkal, hogy a fotóik E2EE-vel védettek, pedig nem azok.

iCloud-fotók

Az Apple átvitel közbeni és tároláskori titkosítást használ. Alapértelmezés szerint a titkosítási kulcsok az Apple-nél vannak. Érvényes jogi megkeresésre az Apple kiadhatja az iCloud-fotók adatait. Kivétel: az Apple 2022 decembere óta elérhető Speciális adatvédelme végpontok közötti titkosítást ad az iCloud-fotókhoz. A Speciális adatvédelmet kifejezetten be kell kapcsolni a Beállításokban. Bekapcsolt állapotban az Apple nem fér hozzá az iCloud-fotók adataihoz. A legtöbb felhasználó nem kapcsolta be.

Google Fotók

A Google átvitel közbeni és tároláskori titkosítást használ szerveroldali kulcsokkal. Minden Google Fotók-adat titkosítási kulcsa a Google-nél van, a Zárolt mappa tartalmát is beleértve. A Google teljesítheti a jogi adatkéréseket. A Google Fotókhoz nincs végpontok közötti titkosítási lehetőség.

Dropbox

Átvitel közbeni titkosítás (TLS 1.2+) és tároláskori titkosítás (AES-256, a Dropbox által kezelt kulcsokkal). A kulcsok a Dropboxnál vannak, és hozzáférhet a fájljaidhoz. A Dropboxot érte már adatszivárgás (2012, 68 millió fiók). A Dropbox Vault (fizetős funkció) PIN-védelmet ad, de végpontok közötti titkosítást nem.

OneDrive

A Microsoft átvitel közbeni és tároláskori titkosítást használ a Microsoft által kezelt kulcsokkal. A kulcsok a Microsoftnál vannak. A OneDrive Személyes tárolója személyazonosság-ellenőrzést (2FA) ad, de végpontok közötti titkosítást nem – a Microsoft továbbra is hozzáfér az adatokhoz. Vállalati ügyfeleknek elérhetők az ügyfél által kezelt kulcsok.

Vaultaire

Kliensoldali titkosítás, a szolgáltatónál tartott kulcsok kizárásával. A Vaultaire minden felhőfeltöltés előtt az eszközön titkosítja a fotókat és a metaadatokat AES-256-GCM-mel. A széfadatokat egy véletlenszerű mesterkulcs titkosítja. A felhasználó mintájából és egy eszközsóból származtatott helyi széfkulcs csomagolja be ezt a mesterkulcsot, a privát CloudKit-mentési rekordokat pedig egy külön, mintából származtatott mentési kulcs védi. A Vaultaire nem üzemeltet tartalomszervert, és nem kapja meg ezeket a kulcsokat, így egy CloudKit-rekordot sem tud nyílt szöveggé alakítani. Az app, az iOS és egy feloldott eszköz a bizalmi határon belül marad, és egy jogi megkeresés továbbra is kikérheti az illetékes szolgáltatónál lévő fiók- vagy szolgáltatási metaadatokat.

Szolgáltatás Titkosítás átvitel közben Titkosítás tároláskor Végpontok közötti titkosítás A szolgáltató hozzáfér
iCloud-fotók (alapértelmezett) Igen Igen (Apple-kulcsok) Nincs Igen
iCloud-fotók (Speciális adatvédelemmel) Igen Igen Igen Nincs
Google Fotók Igen Igen (Google-kulcsok) Nincs Igen
Dropbox Igen Igen (Dropbox-kulcsok) Nincs Igen
OneDrive Igen Igen (Microsoft-kulcsok) Nincs Igen
Vaultaire Igen Igen Kliensoldalon titkosított mentés, alapértelmezés szerint bekapcsolva Nincs nyílt tartalomkulcs; a CloudKit-metaadatok megmaradnak

Miért fontos a végpontok közötti titkosítás a fotóknál?

A fotók különösen érzékeny adatok. Arcokat, helyeket (GPS-metaadatok), időbélyegeket és privát pillanatok vizuális nyomait tartalmazzák. A fotókönyvtárad kiszivárgása szinte minden más adattípusnál több személyes információt tár fel.

Adatszivárgások

Ha egy szolgáltató szerveroldali kulcsokkal tárolja a fotókat, a tárhely és a kulcskezelés együttes feltörése olvasható tartalmat fedhet fel. Egy jól megvalósított E2EE mellett a csak a tárhelyet érintő feltörés titkosított szöveget és a szolgáltatás által őrzött metaadatokat adja. A végpont feltörése, az ellopott helyreállítási hitelesítő adatok, a rosszindulatú kliensszoftver és a kulcsszolgáltatás hibái külön utak maradnak a nyílt szöveghez.

Jogi és hatósági hozzáférés

A szolgáltatókat kötelezhetik a birtokukban lévő adatok átadására. E2EE mellett ez olvasható fotótartalom helyett titkosított szöveget, fiókadatokat, hozzáférési naplókat, rekordméreteket, időzítést és megosztási metaadatokat jelenthet. Az, hogy egy megkeresés elérhet-e egy eszközt, helyreállítási módot, címzettet vagy a kliens jövőbeli viselkedését, külön jogi és műszaki kérdés.

Belső hozzáférés

A szolgáltató által kezelt tárolókulcsokhoz hozzáférő munkatársak vagy támadók elérhetik a szerveroldalon titkosított tartalmat. Az E2EE megszünteti ezt a közvetlen tárolókulcs-utat, ha a szolgáltatónál nincsenek nyílt tartalomkulcsok. A belső visszaélést nem teszi eleve lehetetlenné, mert a szolgáltató kezelheti a kliens terjesztését, a fiókállapotot, a metaadatokat, a megosztást vagy a helyreállítási összetevőket.

Metaadat-védelem

Egyes E2EE-megvalósítások csak a fájltartalmat titkosítják, a metaadatokat, például a fájlneveket és a dátumokat, védtelenül hagyják. A Vaultaire a fájlfejléceket, a MIME-típusokat, az indexeket, a bélyegképeket és a többi széfmetaadatot AES-256-GCM hitelesített titkosítással védi. A tárolt titkosított szövegek hossza és a titkosított tárolófájlok száma ettől még szerkezeti információt árulhat el annak, aki hozzáfér az alkalmazás tárolójához, például becslést arra, hány széfben vannak fájlok.

Gyakori tévhitek az E2EE-ről

„A felhőtárhelyem titkosított, tehát a fotóim biztonságban vannak.” A szerveroldali titkosítás a szerverhardvert érő külső támadások ellen véd. A szolgáltatóval, a jogi megkeresésekkel és a belső fenyegetésekkel szemben nem. A kulcsok a szolgáltatónál vannak.

„A HTTPS azt jelenti, hogy a fotóim végpontok között titkosítottak.” A HTTPS (TLS) az eszközöd és a szerver közötti átvitel során titkosítja az adatot. Amint az adat megérkezik a szerverre, visszafejtődik. A HTTPS a csövet titkosítja, nem az adatot.

„A végpontok közötti titkosítás azt jelenti, hogy soha senki nem láthatja a fotóimat.” Az E2EE azt jelenti, hogy kulcs nélkül senki sem láthatja a fotóidat. Akinél ott a jelszavad vagy a kulcsod, vissza tudja fejteni az adatot. A kulcskezelés és az erős jelszavak továbbra is elengedhetetlenek.

„Az Apple/Google nem látja a fotóimat.” Alapértelmezés szerint mindkét cégnél ott vannak a felhőben tárolt fotóid titkosítási kulcsai. Az Apple Speciális adatvédelmét neked kell bekapcsolnod. A Google egyáltalán nem kínál E2EE-lehetőséget a Google Fotókhoz.

Hogyan valósítja meg a Vaultaire a végpontok közötti titkosítást?

A Vaultaire rétegzett E2EE-megközelítést használ:

  1. Az AES-256-GCM titkosít minden fájltartalmat. Minden fájl egyedi inicializálóvektort kap. A hitelesített titkosítás észleli a manipulációt.
  2. A PBKDF2 HMAC-SHA512-vel a felhasználó rajzolt mintájából és egy eszközsóból helyi széfkulcsot származtat. A munkaigény megnöveli minden offline tipp költségét, de nem ad entrópiát a mintához. Ez a széfkulcs hitelesíti a titkosított indexet, és kicsomagolja a fájladatokhoz használt véletlenszerű mesterkulcsot.
  3. Az AES-256-GCM a metaadatokhoz hitelesített titkosítással védi a fájlneveket, a dátumokat, a méreteket, az indexeket és a bélyegképeket.
  4. Az iOS-kulcskarika és az iOS adatvédelme védi az eszközsót és a titkosított helyreállítási adatbázist. Az AES-GCM-műveletek és az aktív szimmetrikus kulcsok az alkalmazás folyamatában maradnak, amíg egy széf nyitva van.
  5. A szolgáltatói kulcs elkülönítése azt jelenti, hogy a Wraxle nem kap nyílt széf-, mester-, mentési vagy helyreállítási kulcsot. A CloudKit-mentés (alapértelmezés szerint bekapcsolva), a szinkronizálás és a megosztás titkosított rekordokat és titkosított kulcsborítékokat tárol, az Apple pedig továbbra is láthatja a szolgáltatási metaadatokat. A Vaultaire-hez nem kell Vaultaire-fiók.

A Vaultaire a helyreállítási adatokat, köztük a mintát, egy AES-GCM-mel titkosított adatbázisban tárolja az iOS-kulcskarikában. Ezek nem kerülnek nyílt szöveges fájlokba, és nem kerülnek Vaultaire-fiókszolgáltatáshoz. Ha nem marad használható minta, helyreállítási kifejezés vagy már feloldott eszköz, a Vaultaire-nél nincs olyan szolgáltatói helyreállítási kulcs, amely visszaadhatná a hozzáférést.

Gyakran ismételt kérdések

Legális a végpontok közötti titkosítás?

A titkosítás, a kikényszerített hozzáférés és a titkosított szolgáltatások jogi megítélése joghatóságonként eltér, és változhat. Ez az útmutató a műszaki modellt írja le, nem jogi tanácsot ad. Nézd meg a hatályos helyi jogszabályokat, ha a használatod határellenőrzést, bírósági végzést, szabályozott iratokat vagy más magas kockázatú helyzetet érint.

Fel tudják törni a hatóságok a végpontok közötti titkosítást?

A támadásoknak ritkán kell a teljes AES-256 kulcsteret átkutatniuk. Egy vizsgáló célba veheti a gyenge jelszót vagy mintát, egy feloldott végpontot, a memóriát, a helyreállítási kifejezést, egy címzettet, egy mentést vagy egy megvalósítási hibát. A helyesen megvalósított, véletlenszerű, nagy entrópiájú kulcsot használó AES-256-GCM a közvetlen kulcskeresésnek ellenáll, de ez csak a rendszer egyik része.

Mi a különbség az E2EE és a zero-knowledge titkosítás között?

Az E2EE azt írja le, hol történik a nyílt szöveg titkosítása és visszafejtése, és kinél vannak a használható tartalomkulcsok. A „zero-knowledge” kifejezést a termékmarketing gyakran használja a szolgáltató elől rejtett titkosításra, de nem szabad szó szerint érteni: egy szolgáltatónál lehet, hogy nincsenek nyílt kulcsok, mégis láthatja a titkosított szöveget, a fiókadatokat, a méreteket, az időzítést, a megosztási kapcsolatokat és más metaadatokat. A címke helyett a dokumentált kulcs- és helyreállítási utakat értékeld.

Lelassítja a telefonomat a végpontok közötti titkosítás?

A modern eszközök hatékonyan kezelik az AES-256-ot a rendszer kriptográfiai könyvtárain keresztül elérhető hardveres gyorsítással. iPhone-on a Vaultaire a CryptoKit segítségével végzi az AES-GCM-et az alkalmazás folyamatában. Az Apple nyilvános Secure Enclave API-jai nem tetszőleges AES-GCM-motorok fájltitkosításhoz. A titkosítás és a visszafejtés többletterhelése a fájlmérettől és az eszköztől függ, de a kialakítás célja, hogy normál használat közben ne legyen útban.

Mi történik, ha elveszítem a titkosítási kulcsomat?

Ha minden használható visszafejtési és helyreállítási út elvész, a titkosított adatot senki sem tudja visszaállítani. Sok E2EE-rendszer ezért helyreállítási kifejezést, megbízható eszközöket, helyreállítási kapcsolattartókat, vészhelyzeti csomagokat vagy titkosított kulcsborítékokat használ. Ezek megőrzik a hozzáférést, de mindegyik a biztonsági modell részévé válik.

Összegzés

A végpontok közötti titkosítás megszüntetheti a tárhelyszolgáltató nyílt kulcsútját, ha a titkosítás feltöltés előtt egy jogosult végponton történik. Ez érdemi védelem, nem garancia az egész rendszerre. Mielőtt privát fotókat bíznál egy szolgáltatásra, ellenőrizd a tartalomkulcsok őrzését, a helyreállítást, a metaadatokat, a kliensfrissítéseket, a végpontok biztonságát és a megosztást.

A Vaultaire kliensoldali titkosítást valósít meg iOS-re. A fotóidat és a széf metaadatait mentés vagy szinkronizálás előtt az eszközön titkosítja AES-256-GCM-mel. A Vaultaire nem kapja meg a visszafejtő kulcsokat, és nem üzemeltet olyan szervert, amely ezeket a titkosított rekordokat a fotóiddá alakíthatná. Ez a szolgáltatói határ nem teszi megbízhatóvá a kompromittált vagy feloldott iPhone-t.