← Vissza
/

SecretConf & SecretCall — Biztonsági leírás

Ez a dokumentum azt foglalja össze, hogyan működik a rendszer titkosítása, mit lát a szerver és mit nem, illetve mi ellen véd és mi ellen nem ez a megközelítés. Célközönsége a rendszert használó szakemberek (orvosok, ügyvédek, tanácsadók) és az ő ügyfeleik.

Rövid válasz

A beszélgetés hangja, videója, chatje és megosztott fájljai végponttól végpontig titkosítva vannak. A SecretConf szerver csak a titkosított bájtokat routolja a résztvevők között — sem az üzemeltető, sem aki hozzáfér a szerverhez, nem tudja a hívás tartalmát visszafejteni.

Ez alól az egyetlen kivétel az az elméleti eset, amikor a szerver aktívan, valós időben manipulálná a kódot vagy a kulcscserét (ún. MITM-támadás). Ez a webes E2EE általános korláta — Signal, WhatsApp webes változata és minden más ugyanebben a helyzetben van. A gyakorlatban ehhez a támadónak a szerver teljes kontrollja és kliens-oldali JS-injektálás képessége is kell, és ha ezt megteszi, akkor a titkosítás már nem tartható.

Mit titkosítunk és hogyan

Szállítási réteg (TLS / DTLS-SRTP)

  • HTTPS: minden weboldali forgalom TLS-szel titkosítva (secretconf.com, secretcall.net, mindigorvos.hu).
  • WebSocket (Socket.io): TLS-en fut (wss), az Nginx reverse proxy terminálja.
  • WebRTC média: DTLS-SRTP a kliens és a LiveKit szerver között. Ez mindig ott van, E2EE nélkül is.

Végponttitkosítás (E2EE)

Ez az érdekes része. A SecretConf LiveKit-et használ SFU-ként (Selective Forwarding Unit). Alapból egy SFU felbontja a szállítási titkosítást, újrakódolja, és úgy küldi tovább — ilyenkor a szerveren a média egy pillanatra visszafejtett állapotban van. Ez nem igazi E2EE.

Mi ezen felül frame-szintű végponttitkosítást rakunk rá a LiveKit InsertableStreams API-val és ExternalE2EEKeyProvider-rel. A hang- és videócsomagok minden egyes frame-je a kliensen titkosítódik egy közös AES-GCM kulccsal, mielőtt a LiveKit SFU-ba érnének. A szerver csak titkosított bájtokat lát — nem tudja visszafejteni.

Hogyan jön létre a közös kulcs (kulcscsere)

A kulcsot nem a szerver generálja és nem is a szerveren fordul meg.

SecretCall / secretcall.net (1:1 biztonságos hívás):

1. Mindkét fél böngészője generál egy ephemer ECDH (P-256) kulcspárt a böngésző WebCrypto API-jával.

2. A publikus kulcsot átküldik egymásnak a Socket.io jelzőcsatornán.

3. Mindkét oldal egymástól függetlenül kiszámolja ugyanazt a közös titkot a saját privát kulcsából és a másik publikus kulcsából (Diffie-Hellman alapelv).

4. A közös titokból HKDF-SHA-256-tal 256 bites AES-GCM kulcs derivál.

5. Ezt a kulcsot kapja a LiveKit E2EE keyProvider.

Miért nem tudja kiszámolni a szerver? Mert nincs meg neki egyik fél privát kulcsa sem, csak a két publikus kulcs. A publikus kulcsokból a közös titkot kiszámolni a Diffie-Hellman probléma — nem megoldható észszerű időn belül.

SecretConf / MindigOrvos szobák (1 host + max 10 résztvevő):

1. A hozzáférést kezdeményező fél (orvos / ügyvéd / tanácsadó) böngészője generál egy véletlen 256 bites master keyt, amit csak ő tárol.

2. Amikor egy új résztvevő belép, a böngészői között ECDH kulcscserét végeznek (ugyanúgy, mint a /hivas esetén).

3. A host a közös ECDH-titokból AES-GCM kulcsot derivál, és ezzel titkosítva küldi át a master keyt az új résztvevőnek a Socket.io-n.

4. Az új résztvevő kibontja, és ugyanazt a master keyt adja a saját LiveKit E2EE keyProvider-ének.

5. Mindenki azonos master keyt használ → a LiveKit szerveren fordul meg a média, de csak titkosítva.

Mit lát a szerver és mit nem

Információ Látja a szerver?
Hogy hívás történt igen (a jelzés átmegy rajta)
Ki kivel beszél (identity-k, IP) igen (metaadat, ez szükséges a routoláshoz)
Hívás hossza igen
Hang tartalma nem (E2EE titkosítva)
Videó tartalma nem (E2EE titkosítva)
Chat üzenetek nem (LiveKit data channel, E2EE titkosítva)
Megosztott fájlok a híváson belül nem (E2EE titkosítva)
Képernyőmegosztás nem (E2EE titkosítva)
ECDH publikus kulcsok igen (de a privátokat nem)
Titkosított master key csomag igen (de AES-GCM védi, a wrapping kulcsot nem tudja kiszámolni)

Mi ellen véd ez és mi ellen nem

✅ Amitől megvéd

  • Passzív lehallgatás a szerveren — logok, memory dump, backup, hálózati csomag-sniffing: a tartalom ezekben is titkosított.
  • Ellopott szerver / adatszivárgás — mondjuk valaki ellopja a szerver merevlemezét: nem tud belehallgatni a korábbi beszélgetésekbe.
  • Rosszindulatú üzemeltetői kontroll, passzív esetben — ha valaki admin-jogot szerez a szerveren, a futó hívás médiáját akkor sem tudja visszafejteni, mert a kulcs nem fordul meg a szerveren.
  • Jogalap nélküli hozzáférési kísérletek — bírósági végzéssel a szerver-üzemeltető csak a metaadatot tudja kiadni (kik, mikor, meddig), a tartalmat nem, mert nincs nála.
  • Hálózati MITM a szerver és a kliens között — a TLS + DTLS-SRTP megoldja.

⚠️ Ami ellen nem véd (vagy csak részben)

  • Aktív, real-time MITM a szerverről. Ha a szervert olyan szintű kompromittálás éri, hogy a támadó valós időben le tudja cserélni a kliens oldali JS-t vagy manipulálni tudja a kulcscsere üzeneteket, akkor technikailag képes "középre állni". Ez minden webes E2EE közös problémája (Signal web, WhatsApp web, Google Meet is). Mi ezen a ponton rá vagyunk utalva a szerver fizikai és szoftveres biztonságára.
  • Megfertőzött végpont. Ha a felhasználó böngészőjébe rosszindulatú bővítmény kerül, vagy a telefonján malware fut, az olvasni tudja a mikrofont, képernyőt, chatet. Ez az E2EE általános korlátja — Signal, WhatsApp sem véd ez ellen.
  • Feltört Google / Apple fiók. A hozzáférés a SecretConf-on a Google vagy Apple fiók OAuth-hitelesítésén keresztül megy. Ha valaki hozzáfér a felhasználó Google/Apple fiókjához (pl. ellopja a jelszót + 2FA-t), be tud lépni a SecretConf-ra is. Ez nem a hívás titkosításának gyengesége, hanem az autentikációé — érdemes 2FA-t kapcsolni a Google/Apple fiókhoz.
  • Képernyőfotó / képernyőfelvétel a másik oldalról. Ha a partner felveszi vagy lefotózza a hívást, arról a rendszer nem tud. Ugyanez érvényes egy telefonhívásra vagy személyes találkozásra is.

Hitelesítés (ki kicsoda)

  • Host-ok (orvosok, ügyvédek, SecretConf felhasználók) — Google vagy Apple OAuth-alapú belépés. Nincs külön jelszó a SecretConf-nál, nincs külön regisztrációs adat. A felhasználó az identitás-szolgáltatóján (Google/Apple) keresztül azonosítja magát.
  • Vendégek / páciensek — 6 jegyű szobakóddal (SecretConf) vagy 4 jegyű hívásszámmal (SecretCall) csatlakoznak. Nincs regisztráció, nincs fiók. A kódok egyediek és csak a nyitott szobára érvényesek.

GDPR kontextus

  • Adatfeldolgozás alapja: GDPR 6. cikk (1) b) — szerződés teljesítése (szolgáltatás igénybevétele).
  • Tárolt adatok: user fiókok (SecretConf/MindigOrvos), szobák metadata (létrehozás, lezárás idő), nem-tartalom logok (kik, mikor csatlakoztak).
  • Nem tárolt adatok: a hívás hang-, videó-, chat- vagy képernyőmegosztás tartalma sehol, semmilyen formában. (Szerveroldali felvétel nincs, és nem is lenne technikailag értelmes, mert a tartalom titkosított a szerver felé.)
  • Adatfeldolgozó szerepkör: mivel a tartalomhoz nem férünk hozzá, sok forrás a hasonló szolgáltatókat (Zoom EE-mód, Signal) "post processor" vagy "csatornás szolgáltató" kategóriába sorolja. Az ügyvédi/orvosi titoktartás nem sérül, mert a szerver és üzemeltetője strukturálisan nem fér a titokhoz.

Technikai hivatkozások

Böngészőtámogatás

  • Chrome / Edge: 94+ (2021 szeptember óta)
  • Firefox: 117+ (2023 augusztus óta)
  • Safari: 15.4+ (2022 március óta)

Régebbi böngészővel a rendszer nem engedi a hívást — fail-closed működés, inkább megszakad a kapcsolat, mint hogy titkosítás nélkül jöjjön létre.

Kapcsolat

Ha kérdésed van a rendszer biztonságáról, írj az üzemeltetőnek — az impresszum és az adatkezelési tájékoztató tartalmazza az elérhetőségeket.