Biztonság a qubnál

Hatálybalépés dátuma: 2026. szeptember 23. Verzió: 1.1 — megvalósítás-pontossági felülvizsgálat

Kutatóknak — gyors referencia:

• Hová küldd a bejelentéseket: support@qub.social, [SECURITY] tárgyelőtaggal.
• Mit foglalj bele: a sérülékenységet, a reprodukálás lépéseit és bármilyen koncepcióbizonyítékot.
• A válaszunk: 3 munkanapon belül visszaigazoljuk a kézhezvételt, és arra törekszünk, hogy 90 napon belül kiadjunk egy javítást.
• Biztonságos kikötő: nem indítunk jogi eljárást olyan jóhiszemű kutatás ellen, amely betartja a 12. § szabályait (nincs hozzáférés olyan adatokhoz, amelyek nem a tieid, nincs szolgáltatásromlás, nincs megszerzett adat megőrzése azon túl, amennyi a probléma bemutatásához szükséges, adj nekünk ésszerű közzétételi ablakot).

A teljes részletek a 12. §-ban (összehangolt közzététel) találhatók.

Kik vagyunk

A qub.social üzemeltetője a VSPRY AUSTRALIA PTY LIMITED (ABN 41 631 026 330), Level 38, 71 Eagle Street, Brisbane QLD 4000, Ausztrália. A „qub", „mi", „minket" és „miénk" hivatkozások erre a jogi személyre vonatkoznak.

Biztonsági elérhetőség: support@qub.social, [SECURITY] tárgyelőtaggal.

1. A megközelítésünk

A qub bizalmi infrastruktúra. A termék értéktelen, ha nem biztonságos, így a biztonság nem funkció — ez az alapanyag. Ez az oldal konkrét értelemben leírja, hogyan védjük a technológiai készletünket, az adataidat és a lepecsételt tartalom integritását.

Egy ellenőrizhető időbeli elköteleződés értéke nő, ahogy az internet egyre nagyobb hányada gépi úton előállítottá válik. Egy ellenőrzött tárolási tranzakció vagy átláthatósági napló horgonya megállapíthatja, hogy a titkosított szöveg legkésőbb a blokk idején már létezett; a lepecsételt műtárgy külön bizonyítja a tartalom integritását, a drand-körhöz kötést és az esetleges szerzőségi aláírásokat. Ennek a két állításnak az elkülönítése az a mérce, amelyhez ezt az oldalt mérjük.

Nem kérjük, hogy bízz bennünk. Úgy tervezünk, hogy a tőlünk megkövetelt bizalom a lehető legkisebb legyen, és ahol bizalom szükséges, pontosan elmagyarázzuk, mi az, amiben bízni kell, és miért.

Három alapelv vezérli minden tervezési döntésünket:

• Minimalizáld, mit láthat a szerver. Az alapértelmezett böngészős üzenetfolyamatban a nyílt szöveg és a burkolókulcs az eszközödön marad. A kiszolgálóoldali Builder-pecsételésnek, a paktum ellenjegyzésének és a kifejezetten engedélyezett helyreállításnak eltérő bizalmi határai vannak, amelyeket alább ismertetünk. Ahol metaadatot tartunk, azt a kiválasztott funkció szükségleteire korlátozzuk.
• Tedd a kompromittálódást helyileg korlátozottá. Bármely egyetlen komponens (a szerverünk, az e-mail-szolgáltató, egy drand-csomópont) feltörése nem fedhet fel olyan lepecsételt tartalmat, amely még nem érte el a feltárási idejét.
• Tedd a protokollt auditálhatóvá. A lepecsételt műtárgy végpontok között ellenőrizhető nyilvános kriptográfiával. Nem kell bíznod a qub szolgáltatásban ahhoz, hogy ellenőrizz egy qub műtárgyat.

2. Fenyegetésmodell

2.1 Mi ellen védünk

• Egy támadó, aki a felfedési idő előtt olvasási hozzáférést szerez a szerveroldalon tárolt adatainkhoz. Az alapértelmezett privát böngészős folyamatban metaadatokat és átlátszatlan, burkolt bájtokat szerez, nem nyílt szöveget vagy K-t. Ez a védelem nem vonatkozik a helyreállításhoz kifejezetten megőrzött K-ra, a drand-kör után nyilvános/csupasz kézbesítésre, illetve a Builder /api/v1/seal és a paktumfolyamatok számára átmenetileg megadott nyílt szövegre.
• Egy támadó, aki elfogja a forgalmat a böngésződ és az infrastruktúránk között. A TLS a CDN-peremünkön végződik; a lepecsételt adatok már titkosítottak az átvitel előtt.
• Egy támadó, aki manipulál egy tárolt adatot. A külső burkoló hitelesítése (ha van), a kanonikus dekódolás, a test hash-e, a qub_id újralevezetése, a körhöz kötés és az opcionális aláírások miatt a manipuláció megbukik az ellenőrzésen; a megtekintő megtagadja a megjelenítést.
• Egy támadó, aki egy hamisított szerzői e-mailt próbál egy aláíró kulcshoz kötni. Az e-mail-igazolás megköveteli mind a privát aláíró kulcs, mind az e-mail-postaládába kézbesített egyszer használatos kód birtoklását.
• Egy kompromittált drand-beacon-üzemeltető. A drand-hálózat küszöbértékes BLS-aláírásokat használ több független üzemeltetőn át; egy kisebbség nem tud korai kibocsátású aláírásokat hamisítani.

2.2 Mi ellen nem tudunk védeni

Őszinték vagyunk a korlátainkkal kapcsolatban. A qub nem tud védeni az alábbiak ellen:

• Az eszközöd kompromittálódása, mielőtt pecsételsz. A helyi billentyűnaplózók, rosszindulatú böngészőbővítmények vagy a fizikai hozzáférés egy feloldott eszközhöz elfoghatják a nyílt szöveget az összeállítás pontján.
• A drand-küszöbérték összeomlása. Több független szervezet futtatja a drand-hálózatot kifejezetten azért, hogy ezt megnehezítse, de ez nem kriptográfiailag lehetetlen: ha elég üzemeltető összejátszik, korán levezethetnék az időzáró kulcsokat.
• Egy érvényes másolat felszabadulási tulajdonságai. Egy nyilvános/csupasz qub a drand-köre után visszafejthetővé válik. Egy privát/burkolt qubhoz emellett K is szükséges; aki a tárolt bájtokat és K-t is megszerzi, a kör után visszafejtheti. Az állandó tárolási és lehorgonyzott naplórekordok nem hívhatók vissza pusztán azzal, hogy eltávolítjuk őket a qub termékfelületéről.
• Egy globális ellenfél, aki feltöri a mögöttes kriptográfiát (AES-GCM, BLS12-381 párosítási feltevések, SHA3-256, ML-DSA-65). Ha ezek a primitívek elesnek, a kriptográfiai ökoszisztémának általában nagyobb problémái vannak.

3. Kliensoldali kriptográfia

Az alapértelmezett böngészős üzenetfolyamatban a tartalom titkosítása a feltöltési kérés előtt történik. Két kifejezett útvonal eltér ettől: a Builder /api/v1/seal szándékosan nyílt szöveget és a hívó által generált K-t küld a Workernek memórián belüli lepecsételésre, a paktum előkészítése és ellenjegyzése pedig az aláírt strukturált paktumot küldi a szolgáltatásnak, hogy véglegesíthesse a kétoldalú műtárgyat. Egyik kivétel sem tévesztendő össze a böngészős útvonal végpontok közötti titkosításával.

3.1 Időzáras titkosítás

A qub a tlock-ot használja — identitásalapú titkosítás, amely egy jövőbeli drand-beacon-körhöz van kulcsolva. A titkosítás a böngésződben zajlik a drand-hálózat nyilvános kulcsával; a visszafejtő kulcsot a drand-hálózat csak akkor bocsátja ki nyilvánosan, amikor a célkör elérkezik. Senki, beleértve minket is, nem tudja előre rekonstruálni a visszafejtő kulcsot.

A quicknet láncot célozzuk:

• 3 másodperces körperiódus
• Láncolatlan mód (minden kör független)
• BLS12-381 G1 aláírások
• Lánc hash 52db9ba70e0cc0f6eaf7803dd07447a1f5477735fd3f661792ba94600c84e971

A quicknet lánc nyilvános kulcsa és genezisideje be van fordítva a kliensbe. Nem kérünk le lánc-paramétereket futásidőben, így egy rosszindulatú csomópont nem tud egy általunk vezérelt láncot helyettesíteni.

3.2 Szimmetrikus titkosítás

A tlock séma egy AES-256-GCM tartalomkulcsot burkol. Az AES-GCM hitelesített titkosítást nyújt: a titkosított szövegben egyetlen átbillentett bit a visszafejtés meghiúsulását okozza, ahelyett, hogy csendben sérült nyílt szöveget állítana elő.

3.3 Kanonikus szerializálás

A protokollstruktúrákat determinisztikus CBOR-ral szerializáljuk (RFC 8949 §4.2 alapvető determinisztikus kódolás). Két megvalósítás ugyanazt a logikai struktúrát azonos CBOR-ként kódolja. A teljes lepecsételt adatok nem determinisztikusak: a tlock és a külső burkoló titkosítása friss véletlenszerűséget használ. A test hash-e a nyers testbájtokon számolódik, míg a kanonikus kódolás egyértelművé teszi a környező aláírt és wire-struktúrákat.

A CBOR-kódolót kézzel írtuk meg mind a kliens-, mind a szerveroldali megvalósításunkhoz, ahelyett, hogy egy általános szerializáló könyvtárra támaszkodnánk — a követelmény a pontosság, nem az ergonómia, és tulajdonságtesztek futnak mindkét megvalósításban annak ellenőrzésére, hogy egyetértenek.

Egy regressziós teszt állítja, hogy a kanonikus wire-formátum nem tartalmaz qub-márka bájtsorozatot a protokoll-primitív qub_id mezőkulcson túl. A wire-formátum szándékosan márkafüggetlen — bármely megfelelő megtekintő (a miénk vagy egy harmadik félé) bármely qubot meg tud jeleníteni a tartós tárolóból, függetlenül attól, melyik telepítés pecsételte le. A teszt egy botlódrót, amely megakadályozza, hogy egy jövőbeli változás véletlenül egy márkahivatkozást süssön be olyan bájtokba, amelyek, ha egyszer tartós tárolóban vannak, nem írhatók át.

3.4 Test-hashelés és feltárás előtti integritás

Minden lepecsételt adat a nyers testbájtjai SHA3-256 hash-ét hordozza. A hash a qub_id-ba, szerzőségi aláírás használatakor pedig a V2 aláírási bemenetbe van kötve. A megtekintő visszafejtés után újraszámolja, és eltérés esetén elutasítja az adatot.

A 32 bájtos tartalomazonosító qub_id egy 108 bájtos előképből származik, amely lefedi a protokollverziót, a tartalomtípust, a létrehozási és feloldási időbélyegeket, az opcionális kimeneti időbélyeget (vagy annak nulla őrértékét), a cél drand-kört, a test hash-ét és az opcionális, NFC-normalizált cím SHA3-256 hash-ét. Egy átjáró vagy CDN nem módosíthat következetesen egyetlen kötött mezőt sem úgy, hogy az újralevezetés továbbra is sikerüljön. A címek legfeljebb 100 NFC-kódpontból állhatnak, és a közös ellenséges/vezérlő kódpont-osztályt elutasítjuk (beleértve a kétirányú felülírásokat, a nulla szélességű karaktereket, a tagblokkot, a BOM-ot, a C0-t, a C1-et és a DEL-t).

3.5 Aláírás (ML-DSA-65)

A szerzőségi aláírás az ML-DSA-65-öt (FIPS 204) használja, egy NIST-szabványosított posztkvantum aláírási sémát. Szándékosan posztkvantum primitívet választottunk az aláíráshoz, mert a lepecsételt tartalom végleges: egy aláírásnak, amely ma ellenőrizhető, évtizedek múlva is ellenőrizhetőnek kell maradnia, beleértve azután is, hogy a nagy léptékű kvantumszámítógépek gyakorlativá válnak.

Az aláírókulcsok a böngészőben generálódnak. A helyi titkot egy nem exportálható WebCrypto-kulccsal burkoljuk az IndexedDB-ben való tárolás előtt. Ha a fiókhoz kötött, eszközök közötti helyreállítást használod, egy AEAD-titkosított hordozható kulcsblob tárolódik a szerveroldalon; a titkos kulcs titkosított szövege a megváltoztathatatlan fiókazonosítóhoz kötött, a szolgáltatás pedig ellenőrzi a nyilvános borítékot, de nem tudja visszafejteni a titkos anyagot. A nyers privátkulcs-bájtokat nem küldjük a szervernek. A nyilvános kulcsokat és igazolásrekordokat ellenőrzéshez és identitásmegjelenítéshez tároljuk.

Ugyanaz a böngészőn belüli tlock-visszafejtés alkalmazandó a qub beágyazáson belül: amikor egy lepecsételt qubot egy <qub-embed>-en keresztül jelenítenek meg egy harmadik fél oldalán, a visszafejtés még mindig a beágyazott iframe-ben történik a megtekintő böngészőjében. A beágyazás nem változtatja meg a bizalmi modellt — a nyílt szöveg sosem fejtődik vissza egy qub szerveren.

3.6 Nyilvános hozzárendelés — opcionális

A lepecsételt qubok nem hordoznak láncon belüli mutatót az alkotójukra, hacsak az alkotó kifejezetten nem választja, hogy csatol egyet. Amikor lepecsételsz egy qubot, a referenciaalkalmazás csak akkor bocsát ki Author tárolási címkét (az aláíró nyilvános kulcsod 64 karakteres hexadecimális ujjlenyomatát), amikor a „Nyilvános hozzárendelés" engedélyezve van a dátumválasztó lépésnél. A kapcsoló kikapcsolva — az alapértelmezett — nem íródik Author címke, és a qub hozzárendelés nélküli a tartós tárolóban: semmi a tárolóban nem köti a feltöltést a felhasználónevedhez, az e-mail-címedhez vagy más qubjaidhoz. A kapcsoló bekapcsolva az ujjlenyomat a @handle-edre oldódik fel a 6.3. / 10. §-ban lévő igazolási láncon keresztül, és a megtekintői visszaszámlálás a „Lepecsételte: @{handle}" feliratot mutatja a feltárás előtt.

Ez egy szándékos védelem a felsorolási kockázat ellen, amelyet egy mindig bekapcsolt Author címke teremtene: egy harmadik fél, aki megtudja egy alkotó ujjlenyomatát, egyébként rákereshetne a tartós tárolóra a címke alapján, és rekonstruálhatná az adott alkotó teljes történelmi kimenetét. Az opcionális hozzárendelés bezárja azt a csatornát — csak azok a qubok jelennek meg egy ujjlenyomat alatt a tartós tárolóban, amelyeket az alkotó kifejezetten hozzárendelni választ.

A /u/{handle} profiloldal egy ellenőrzött-identitás kártya — felhasználónév, opcionális megjelenítendő név + URL, „ellenőrzött e-mail" jelvény (nincs cím) és a kriptográfiai ujjlenyomat rövid formája. Nem sorolja fel egy alkotó qubjait. A látogatók, akik egy konkrét qubot szeretnének látni egy alkotótól, közvetlenül az adott qub kézbesítési URL-jét követik.

3.7 Külső titkosítási burkoló

Még miután az időzáras visszafejtés matematikailag lehetségessé válik — amikor a kötött kör drand-aláírása már megjelent —, a kanonikus időzáras réteg önmagában lehetővé tenné egy indexelő számára a felfedezhető qubok tömeges visszafejtését. A privát kézbesítés egy további szimmetrikus réteggel zárja le ezt a csatornát az időzárral titkosított bájtok körül (Protokoll 13. §). A nyilvános kézbesítés szándékosan elhagyja a burkolót, hogy az értesítési, beágyazási és felfedezési linkek titkos töredék nélkül működhessenek.

A burkoló az AES-256-GCM-et használja, egy NIST-szabványosított hitelesített titkosítót, egy friss, 256 bites K kulccsal, amelyet qubonként a böngésződ CSPRNG-je generál. K a qub qub_id-jéhez van kötve hitelesített kiegészítő adatként, így egy qubból származó kulcs nem használható újra egy másik qub visszafejtéséhez.

Az alapértelmezett privát böngészős folyamatban K sosem éri el a szervereinket. A megosztási hivatkozás URL-töredékébe van kódolva (https://qub.social/c/<tx_id>#<base64url(K)>). A böngészők nem továbbítják az URL-töredékeket a szervereknek — az RFC 3986 a töredéket a kérésen kívülre helyezi —, így ebben a folyamatban a qub.social, a tárolóátjárók, a CDN-ek és a kérésfigyelés nem látják K-t. A tárolt OuterWrapper felismerhető strukturált CBOR, de hitelesített titkosított szöveg mezője elrejti a belső SealedQub-szerkezetet, és K nélkül nem nyitható meg.

Nettó következmények:

• A qub.social a tárolt adatokból önmagában nem tudja visszafejteni az alapértelmezett privát böngészős pecsételéseket. Egy adattároló kompromittálódása K nélküli, átlátszatlan titkosított szöveget ér el. A nyilvános és a helyreállítást engedélyező qubok kitettsége szándékosan eltér.
• A töredék elvesztése opcionális helyreállítási csatorna nélkül helyreállíthatatlan. Ha egy privát hivatkozást töredék nélkül mentesz, és nem engedélyezted a helyreállítást, a qub azon a hivatkozáson keresztül olvashatatlanná válik. A pecsételési folyamat ezért kifejezett „mentsd el ezt az URL-t" közlést jelenít meg.
• Opcionális helyreállítás. Amikor egy qubhoz kiválasztod az alkotói életciklus-e-maileket, ÉS az e-mail egyezik az ellenőrzött identitásoddal, elfogadjuk K-t a feltöltéssel, eltároljuk a teljes kézbesítési URL-t az identitásod lepecsételt-előzmény rekordján, és hivatkozásként használjuk a pecsételés-megerősítő e-mailben. Ez a csere — egy szerveroldali helyreállítási csatorna a végpontok közötti tisztaság egy részéért cserébe — csak kifejezett kiválasztásra lép működésbe, és csak az adott qubhoz. Az alapértelmezett hozzáállás a kriptográfiai megsemmisítés.

A Worker szerveroldali /api/v1/seal végpontja (amelyet MI-ágensek és más API-hívók használnak) megköveteli, hogy a hívó egy CSPRNG-vel generálja K-t, helyben megtartsa, és wrapper_key_b64url-ként adja meg. A Worker ezen a kifejezetten megbízhatónak tekintett útvonalon szükségszerűen látja a nyílt szöveget és K-t is a memóriában, de egyiket sem őrzi meg. Egy kötelező Idempotency-Key megakadályozza, hogy egy elveszett válasz egy második, számlázott qubot hozzon létre, miközben a hívó által megtartott K kombinálható az újrajátszott, töredék nélküli URL-lel. Ez eltér az alapértelmezett böngészős útvonaltól, ahol K sosem éri el a Workert, hacsak az alkotó kifejezetten nem engedélyezi a helyreállítást.

4. Átvitel és perem

4.1 TLS

A qub böngészőforgalmát HTTPS-en szolgáljuk ki a Cloudflare peremén. A válaszok HTTP Strict Transport Security fejlécet állítanak be (max-age=63072000; includeSubDomains; preload). A ténylegesen egyeztetett TLS-verziót és titkosítókészletet az aktív peremkonfiguráció szabályozza, nem az alkalmazáskód állítása. Nem teszünk elérhetővé külön közvetlenül elérhető origin szervert.

4.2 Tartalombiztonság

A lefordított kliens szigorú tartalomtípus- és gyorsítótár-fejlécekkel kerül kiszolgálásra. Az SPA-keret egyetlen origin. Nem ágyazunk be harmadik féltől származó szkripteket analitikához vagy reklámhoz. A termék két harmadik fél érintkezési pontja egyaránt szűken behatárolt: a vásárlási folyamat teljesen elhagyja az SPA-t egy teljes oldalas átirányítással a Stripe által üzemeltetett fizetésre (https://checkout.stripe.com/…) — a Stripe felülete sosem fut az originünkben, és sosem látunk kártyaadatot —, a pecsételési folyamat pedig betölti a Cloudflare Turnstile widgetjét, egy adatvédelmet megőrző CAPTCHA-alternatívát, amelyet a Cloudflare a saját sandboxolt iframe-jén belül jelenít meg. Egyik fél sem tudja olvasni az oldal többi részét.

A qub beágyazott iframe (a qub.social/embed/{tx_id}-ből kiszolgálva és az embed.js által harmadik fél oldalakra betöltve) saját Content-Security-Policyt hordoz. A connect-src engedélyezőlistája: 'self', https://qub.social, https://arweave.net, https://ar-io.dev, https://permagate.io, https://api.drand.sh és https://drand.cloudflare.com. Az iframe sandbox="allow-scripts allow-top-navigation-by-user-activation" beállítással fut (allow-same-origin nélkül): a gazdaoldal nem tudja olvasni a DOM-ját, az iframe pedig csak felhasználói művelet után navigálhatja a gazdaoldalt.

4.3 CORS és lekérési hatókör

A böngészőkliens csak az alábbiakhoz intéz lekérési kéréseket:

• A saját API-nk (api.qub.social és staging megfelelői)
• Tárolóátjárók (csak olvasható, a burkolt privát vagy csupasz nyilvános bájtok lekéréséhez — 3.6. §)
• drand-beacon-végpontok (csak olvasható, a feltárási idejű kör-aláírásokhoz)

A beágyazás célállomásait a CSP kényszeríti ki. A fő SPA tervezett célállomásait a kód és a konfiguráció rögzíti, böngészős és integrációs ellenőrzések pedig gyakorolják őket; a Subresource Integrity nem hálózati célállomás-vezérlés.

A beágyazás az engedélyezőlistán szereplő qub-/tárolóoriginokon keresztül kéri le a tárolt bájtokat, a böngészőben bontja ki a privát adatokat az URL-töredékből származó K-val, és a két engedélyezett drand-originról kéri le a felfedési idejű köraláírásokat. A fő SPA a config/drand-endpoints.json négy végpontos tartalékkészletét (drand.cloudflare.com, api.drand.sh, api2.drand.sh és api3.drand.sh) használja, így egyetlen végpont kiesése nem akadályozza meg a felfedést. A beágyazás CSP-je minden, a kifejezett listán kívüli kapcsolatot megtilt.

5. Szerveroldali infrastruktúra

5.1 Szerver nélküli perem

Az API-nk teljes egészében egy menedzselt szerver nélküli futtatókörnyezetben fut a peremen. Nincsenek virtuális gépek, nincsenek konténerek, és nincsenek általunk adminisztrált tartós szerverfolyamatok. Ez drámaian csökkenti a támadási felületet, amelyért felelősek vagyunk: nem üzemeltetünk operációs rendszert, webszervert vagy alkalmazás-futtatókörnyezetet, amelyet javítanunk kell.

Egy külön nyilvános CORS köztesréteg lép érvénybe Access-Control-Allow-Origin: * a következő megvalósított útvonalhoz beállítva: /embed.js, /embed/v1.js, minden alá /embed/; /api/v1/telemetry; /api/v1/openapi.json; minden alá /api/v1/qub/ (beleértve a bájtokat, metaadatokat, bizonyítékot, részvételt, értesítést és push alútvonalakat); minden alatta /api/v1/log/; nyilvános kezelő lekérdezések alatt /api/v1/handle/; és a nyilvános avatar alatt olvas /api/v1/identity/avatar/. Előzetes repülési engedélyei GET, POST, és OPTIONS val vel Content-Type kérési fejléc. Ez az előtag-alapú felület szélesebb, mint az a hívások köre, amelyet az embed jelenleg végrehajt, ezért minden, azokon az előtagokon belüli kezelőnek továbbra is érvényesítenie kell a saját érvényesítését, hitelesítését, aránykorlátait és visszaélés-ellenőrzéseit. Más API útvonalak megtartják a qub.social-korlátozott CORS szabályzatot.

5.2 Tárolás

• A metaadat- és koordinációs tárolók identitás- és igazolásrekordokat, jogosultságokat és számlázási hivatkozásokat, API-kulcsrekordokat, tiltólista-bejegyzéseket, munkameneteket, idempotenciaállapotot, sorokat, valamint sebességkorlát- és párhuzamossági állapotot tartanak. Az eltérő konzisztenciaigényeket KV, D1 és Durable Objects szolgálja ki egyetlen univerzális tároló helyett.
• Az objektumtárolónk egyben tartóssági alapréteg. A feltöltéskor visszaigazolt pontos burkolt vagy csupasz qub-bájtokat, az átláthatósági napló leveleit és koordinátakulcsos Merkle-csomópontjait, horgonyanyagot, strukturált eseménynaplókat, valamint válasz- és metaadat-gyorsítótárakat tartja.
• Az állandó nyilvános tároló átláthatósági naplóhorgonyokat, a T3 útvonalon vagy halasztott közzétételnél pedig egyedi qub-tranzakciókat tart. Ezt a hálózatot nem mi üzemeltetjük. A privát böngészős adatok K nélkül ott is átlátszatlanok maradnak; a nyilvános/csupasz adatok szándékosan nem rendelkeznek ezzel a további linkképességi réteggel.

Az alapértelmezett böngészős üzenetfolyamat nem őriz meg nyílt szöveget a qub infrastruktúráján. A Builder /api/v1/seal a nyílt szöveget és K-t a memóriában kezeli, de egyiket sem őrzi meg. A paktum előkészítése szükségképpen tárolja az aláírt strukturált paktumot az ellenjegyzésig, visszavonásig vagy lejáratig. Az opcionális helyreállítás kézbesítési képességet — a töredéket tartalmazó teljes linket — tárol, hogy később visszanyerhető legyen. Ezért nem nevezzük a teljes tárolási réteget „csak metaadatnak".

5.3 Titkok

A titkokat (aláíró pénztárcákat, szolgáltatói tokeneket és HMAC-kulcsokat) platformtitok-/környezeti kötéseken keresztül adjuk át, nem a forráskódkezelésből. A futtatási komponensek csak a szükséges kötéseket kapják meg. A rotációs és átfedési eljárások komponensenként eltérnek; nem állítjuk, hogy egyetlen univerzális automatikus vagy auditált rotációs mechanizmusunk van.

5.4 Naplózás és telemetria

Strukturált JSON-naplók íródnak minden API-kérésen egy korrelációs azonosítóval, amely az X-Request-Id válaszfejlécben jelenik meg. A kliens-telemetria anonim — nincs eszközazonosító, nincs IP-cím, nincs tartalom-előnézet. Az események a memóriában pufferelődnek, és legjobb erőfeszítés alapon ürülnek; egy meghiúsult ürítés eldobódik, nem próbálkozik újra. A telemetriát úgy tervezték, hogy a hálózati rétegen letiltható legyen a termék befolyásolása nélkül.

6. Hitelesítés

6.1 Magic-link bejelentkezés

A bejelentkezés egy egyszer használatos, HMAC-aláírt tokent használ, amelyet az e-mail-postaládádba kézbesítünk. A hivatkozás 15 percig érvényes, a beváltását pedig atomikusan foglaljuk le, így a párhuzamos vagy újrajátszott használat zártan hibázik. Siker esetén a böngésző átlátszatlan __Host-qub_session sütit kap Secure, HttpOnly, SameSite=Strict és Path=/ attribútumokkal.

A munkamenetek inaktivitási korlátja 30 nap, abszolút korlátja 90 nap; 24 óra után rotálódnak, és csak a közvetlenül előző generációt fogadják el 120 másodperces, elveszett válaszra szolgáló türelmi idővel. Az érzékeny fiókmódosítások az előző 10 percen belüli hitelesítést igényelnek. A HMAC aláíró titka platformkötés; a metaadatok puszta olvasása önmagában nem teszi lehetővé érvényes token kibocsátását.

6.2 API-kulcsok (fejlesztői szint)

A fejlesztői API-kulcsok a qub_sk_ előtagot használják a könnyű felismerhetőség és greppelhetőség érdekében. Minden kulcs:

• Egy fiókhoz, hatókörökhöz és egy opcionális IP-CIDR-engedélyezőlistához van kötve
• Nyers formában csak egyszer jelenik meg; a tartós rekordok az SHA-256 hash-ét őrzik, nem a bearer titkot
• Egyórás türelmi leképezéssel rotálható, amelyben a régi kulcs a helyettesítőre oldódik fel
• Független kvóta- és sebességkorlát-állapota van
• Sosem naplózódik teljes egészében; a naplók csak a kulcsazonosítót rögzítik

Az admin kulcskezelő végpontok egy külön admin hitelesítő adat mögött vannak korlátozva.

6.3 E-mail-igazolás (szerzőségi aláírás)

Egy e-mail-cím egy aláíró kulcshoz kötése megköveteli:

1. A privát aláíró kulcs birtoklását (aláírsz egy kihívást)
2. Az e-mail-postaláda birtoklását (megadsz egy 6 jegyű kódot, amelyet e-mailben kézbesítünk)

Egyik önmagában nem elegendő. A visszavonás egy aláírt rekord a saját fiókodon, és azonnal hatályba lép; az igazolást lekérő megtekintők a visszavont állapotot látják, és annak megfelelően jelenítenek meg.

7. Fizetések

A kártyaadatok megadása és feldolgozása a Stripe által üzemeltetett fizetési felületen történik. Sosem kapunk kártyaszámot, lejárati dátumot vagy CVC-t. Tároljuk viszont a Stripe ügyfél- és előfizetés-azonosítóit, az előfizetés állapotát és az időszakadatokat a jogosultság-/API-kulcsrekordokon, hogy a hozzáférés, megújítás, mérés, lemondás és visszatérítés egyeztethető legyen. A Stripe adatvédelmi és biztonsági nyilatkozatai szabályozzák a fizetési adatok kezelését.

A pecsételési végpont keresztellenőrzi a jogosultságrekordot az eszközazonosítóval szemben, és a bejelentkezett felhasználók esetében a kapcsolt identitással szemben. Egy jogosultság nem használható újra eszközök között anélkül, hogy a felhasználó kifejezetten helyreállítaná magic-link bejelentkezéssel.

8. Visszaélés-ellenállás

8.1 Botészlelés

A pecsételési folyamatot egy adatvédelmet megőrző CAPTCHA-alternatíva korlátozza, amely nem használ sütiket követésre, és nem készít ujjlenyomatot reklámhoz. Egy meghiúsult kihívást a perem-Workerünk elutasít, mielőtt bármilyen pecsételésoldali feldolgozás megtörténne.

8.2 Sebességkorlátozás

A sebességkorlátok több rétegen érvényesülnek:

• IP-nkénti és kulcsonkénti korlátok a pecsételési, olvasási és hitelesítési végpontokon
• E-mailenkénti korlátok a magic-link kéréseken (megakadályozza a postaláda-elárasztást)
• Másik félenkénti korlátok a paktummeghívó e-maileken (tíz fogadó címenként UTC-naponként, az elsődleges spam-relay enyhítés; a tisztességes paktumok szinte sosem közelítik meg a felső korlátot)
• IP-nkénti korlátok a telemetria-beküldésen

A számlálók és atomikus foglalások a végpont konzisztenciaigényei szerint KV, Durable Objects és platform-sebességkorlát-kötések között oszlanak meg. A sebességkorlátozott kérések 429-es választ kapnak; a várakozási ablakot kiszámítani képes végpontok Retry-After fejlécet is adnak.

8.3 Tartalommoderálás

Az alapértelmezett böngésző-feltöltési útvonal nem tudja átvizsgálni a törzset: csak az ügyfél által lezárt artefaktumot kapja meg. A Builder /api/v1/seal Az útvonal átmenetileg látja a sima szöveget, és a megállapodás előkészítése struktúrált feltételeket tart fenn a véglegesítésig, de ezek a bizalmi kivételek nem változtatják a általános bájtoknak vak feltöltési utat tartalomszkennerré. A működési moderáció egy tiltólista a néző rétegén: egy tiltólistán szereplő qub-ot a nézőnk elutasít, függetlenül attól, hogy a tárolt adatmennyiség elérhető marad-e. A tiltólistára vétel nem vonja vissza a tartós bájtokat, az átláthatósági naplóbejegyzéseket vagy a már közzétett állandó hálózati adatokat.

A visszaélési bejelentések sebességkorlátozása a bejelentő IP-jének egyirányú hash-ével történik; nem tárolunk IP-ket nyíltan erre a célra.

9. Ellátási lánc és build-integritás

9.1 Eszközlánc-rögzítés

A fordító- és futtatókörnyezeti verziók a tároló konfigurációjában vannak rögzítve, a függőségeket pedig a verziókezelt zárolófájlok oldják fel. A CI ellenőrzi a generált fájlok frissességét és a reprodukálhatóság szempontjából érzékeny invariánsokat. Nem állítjuk ennél erősebben, hogy minden tiszta build minden támogatott gépen bitről bitre azonos.

9.2 Lintek és statikus elemzés

A munkaterület engedélyezi a legszigorúbb lint-csoportjainkat a deny szinten. A CI minden figyelmeztetést — beleértve a dokumentáció-hivatkozás figyelmeztetéseket — buildhibaként kezel. Ez szándékos: a lint-szigorúságot botlódrótként használjuk a finom regressziókhoz.

9.3 CI-kapuk

A CI-munkafolyamat lefedi a formázást és a szigorú linteket; a Rust-, WASM-/böngésző-, Worker-, beágyazási és API-teszteket; a típusellenőrzést; a kódlefedettséget; a mutációs/invariáns ellenőrzéseket; a függőségek és munkafolyamatok statikus elemzését; az i18n-kulcsok, lefedettség, drift és ellenséges kódpontok ellenőrzését; a generált dokumentumok/API/tudásbázis frissességét; a dokumentumleltárt és belső hivatkozásokat; a stíluslap- és csomagméret-kereteket; valamint az OpenAPI-validációt. Néhány költséges mutációs feladat ütemezve fut, nem minden pushnál.

Az egyetlen kötelező ci összesítő piros marad, ha bármely kötelező feladat meghiúsul. A védett ágak és a telepítési munkafolyamatok ezt az eredményt használják, ahelyett hogy egy kisebb biztonsági kaput ismételnének meg.

9.4 Mutációs tesztelés

Egy heti munka mutációs tesztelést futtat a biztonságkritikus tiszta modulokkal szemben: hashelés, kanonikus CBOR, pecsételés, feloldás, a wire-formátum newtype-ok, a protokolltípus-érvényesítők és a felhasználónév-névtér. A mutációs tesztelés arra a kérdésre válaszol, hogy „elkapja-e a tesztkészletünk a finoman hibás kódot?" — ha egy mutált megvalósítás még mindig átmegy minden teszten, tudjuk, hogy van egy teszt-lefedettségi hézagunk, és foglalkozunk vele.

9.5 Git-hookok

A helyi hookok (pre-commit, pre-push) tükrözik a CI-kapukat, így a regressziók elkapásra kerülnek, mielőtt elhagyják a fejlesztő gépét. A hookok egy tároló-szkripten keresztül települnek; nem kerülik meg őket a munkafolyamatunkban, és a CI a mérvadó kapu, ha kihagyják őket.

10. Tesztelés

A biztonságkritikus kód háromféle tesztet hordoz:

• Az egységtesztek ellenőrzik a várt viselkedést ismert bemeneteken, beleértve a protokoll-specifikációból származó tesztvektorokat.
• A tulajdonságtesztek több ezer tetszőleges bemenetet generálnak, és invariánsokat állítanak: kanonikus CBOR-körutazások, aláírás-ellenőrzési körutazások, e-mail-kötési predikátumok, paktum-nyugtázási determinizmus.
• A megvalósításközi tesztek ellenőrzik, hogy a kliens- és szerveroldali megvalósításaink bájtról bájtra egyetértenek a kanonikus kódolásokon. Ez elkapja a két megvalósítás közötti eltérést, mielőtt eléri a termelést.

11. Ág- és kiadáshigiénia

A funkcióágak csak Gate 1 pull requesten keresztül léptethetik előre a staging ágat: a kötelező ci zöld, nincs megoldatlan változtatási kérés, nincs egyesítési ütközés, és a felülvizsgált munkafa tiszta; az egyesítés squash-and-delete. A main csak a Gate 2 staging → main pull requesten keresztül halad tovább, és egyesítési committal őrzi meg a leszármazást. A közvetlen ág-push nem része a kiadási munkafolyamatnak.

A staging- és éles telepítések a megfelelő védett staging és main ágállapotból, a CI után indulnak. A pull-request kódja és a forkok hitelesítő adatai nem kapnak telepítési titkokat.

A telepítési munkafolyamatokban használt titkok a CI-platformunk által a telepítési környezetre vannak behatárolva. Nem érhetők el a forkokból származó pull-request munkafolyamatok számára.

12. Összehangolt közzététel

Ha úgy véled, hogy biztonsági sérülékenységet találtál a qubban, gyorsan hallani szeretnénk róla, és elkötelezzük magunkat a bejelentés szakszerű kezelése mellett.

• Küldj e-mailt a support@qub.social címre [SECURITY] tárgyelőtaggal.
• Írd le a sérülékenységet, a reprodukálás lépéseit és bármilyen koncepcióbizonyítékot.
• Adj nekünk ésszerű közzétételi ablakot (jellemzően 90 nap), mielőtt nyilvánosságra hoznád.
• Ne férj hozzá olyan adatokhoz, amelyek nem hozzád tartoznak, ne rontsd a szolgáltatást más felhasználók számára, és ne őrizz meg kutatás során szerzett adatokat azon túl, amennyi a probléma bemutatásához szükséges.

Három munkanapon belül visszaigazoljuk a kézhezvételt, és tájékoztatunk, ahogy vizsgálódunk. A beleegyezéseddel megemlítjük a bejelentőket a kiadási megjegyzésekben.

12.1 Biztonságos kikötő

Ha a kutatásod betartja a fenti szabályokat (jóhiszemű vizsgálat, nincs kár más felhasználóknak vagy a szolgáltatásnak, ésszerű közzétételi ablak), nem indítunk jogi eljárást ellened, és nem kérjük a bűnüldözést, hogy tegye. A munkádat engedélyezett tesztelésként kezeljük, és inkább te találd meg a hibát, mint valaki más.

Ez a biztonságos kikötő a következőkre vonatkozik:

• Az élő qub.social szolgáltatáson végzett kutatás (nem az erre a célra közzétett tesztkellékeken).
• A közzétett binárisaink és a nyílt forráskódú qub-core / qub-app crate-ek visszafejtése.
• Bármilyen sérülékenységi osztály — protokoll, alkalmazás, infrastruktúra, ellátási lánc —, amely a qubot érinti.

Nem vonatkozik a qub-csapat tagjainak social engineeringjére, szolgáltatásmegtagadási tesztekre vagy más felhasználók adataihoz való hozzáférésre azon túl, amennyi a probléma bemutatásához szükséges. Ha nem vagy biztos abban, hogy valami a biztonságos kikötőn belülre esik-e, kérdezz először ugyanazzal a [SECURITY] tárgyelőtaggal.

13. Őszinte korlátok

A biztonság gyakorlat, nem állapot. Néhány korlátot érdemes közvetlenül megnevezni:

• Kis csapat vagyunk. A felülvizsgálati mélységünk nem éri el egy nagyvállalat dedikált alkalmazásbiztonsági funkcióját. Szigorú automatizált kapukkal és egy minimális támadási felülettel kompenzálunk, de nem állítjuk a tévedhetetlenséget.
• A tárolási háttérrendszerünk állandósága egyirányú ajtó. Ha egy hiba azt okozza, hogy a lepecsételt tartalom a szándékoltnál korábban visszafejthetővé válik, nem tudjuk visszacsinálni. A pecsételési folyamatot ennek megfelelő gondossággal kezeljük.
• A drand-hálózat egy külső függőség. A drand katasztrofális meghibásodása minden qub feltárási viselkedését érintené. Monitorozzuk a drand állapotát, és van vészhelyzeti dokumentációnk a láncmigrációhoz, ha szükséges. A 2 évnél távolabbi feloldási dátumoknál a pecsételés-idejű megerősítő modális egy kifejezett közlést mutat: a hosszú időhorizontú qubok a drand-lánc tartósságától függenek, és egy jövőbeli drand-láncmigráció helyreállítási lépéseket igényelhet a qub feloldásához. Az 5 évnél távolabbi feloldási dátumoknál egy extra négyzetet kell bejelölnöd, megerősítve, hogy elolvastad és elfogadod ezt a kockázatot, mielőtt a pecsételés folytatódik.
• A kriptográfiai primitívek, amelyekre támaszkodunk, szabványosítottak és széles körben felülvizsgáltak, de a kriptográfia fejlődik. Ahol választásunk van (posztkvantum aláírás, hitelesített titkosítás), a konzervatívabb opciót választjuk.

14. Az oldal módosításai

A lényeges változásokat a tetején lévő hatálybalépési dátum frissítésével jegyezzük. Ahol egy változás konkrét biztonsági fejlesztést tükröz, röviden leírjuk a nyilvános változásnaplóban. Ahol egy változás irányelvi pontosítást tükröz, leírjuk, mi változott és miért.

Az ezen oldalon lévő bármivel kapcsolatos kérdésekhez küldj e-mailt a support@qub.social címre [SECURITY] tárgyelőtaggal.

15. Változásnapló