← Privacy Pass / privacy-pass / concepts

Modely nasazení

Tato stránka popisuje strukturu nasazení Privacy Pass: kdo provozuje každou ze čtyř rolí, podrobné modelové příklady nasazení, které modely nasazení vyhovují různým potřebám zákazníků a jak Privacy Pass zapadá do dalších produktů.

Tokeny Privacy Pass sice nabízejí kryptografickou ochranu pomocí slepých podpisů a velkých anonymizačních množin, záruky ochrany soukromí ale vyžadují také dostatečné oddělení jednotlivých rolí. Typické nasazení Cloudflare vypadá takto:

Nejdůležitější je, že se tím informace o Klientovi rozdělí tak, aby je žádná jednotlivá role neznala celé, čemuž se říká nespojitelnost. Různé modely nasazení sice mohou měnit, kdo přesně co ví, ale nespojitelnost zaručuje, že nikdo nezná zároveň to, kým Klient je, i to, kam směřuje. Informace se obecně rozdělují takto:

• Ověřovatel zná identitu Klienta a veškeré identifikovatelné informace sdílené během fáze atestace, ale nezná identitu Originu.
• Vydavatel ví pouze to, že Klient byl atestován a má nárok na podepsaný token. (Záleží na nasazení: pokud jsou Attester a Issuer stejný subjekt, může se Issuer dozvědět informace o identitě, identita Originu ale zůstává skrytá.)
• Origin ví pouze to, že Klient byl ověřen.

Je důležité si uvědomit, že nespojitelnost mezi vydáním a uplatněním tokenu, kterou Privacy Pass zajišťuje, závisí na oddělení rolí jen částečně. Aby bylo soukromí skutečně účinné, musí zůstat velká i anonymitní množina, tedy skupina klientů, kteří jsou součástí stejného nastavení nasazení. Cokoli, co způsobí, že klienti vidí odlišná nastavení, je rozděluje do menších skupin, čímž se anonymita zmenšuje.

Další informace naleznete v dokumentu RFC Privacy Pass, konkrétně v pokyny ↗.

Hlavní strukturální volbou je, zda se provozující subjekty Attesteru, Issueru a Originu překrývají, nebo jsou zcela oddělené. Plně oddělený model je sice nejbezpečnější, ale kombinace některých subjektů může být podle případu užití výhodná. Mezi další možné modely patří společný model Attester-Issuer a společný model Issuer-Origin, které záruky ochrany soukromí neporuší, pokud další pokyny ↗ jsou dodržovány.

Apple vytvořilo PAT ↗ téměř úplně obejít výzvy CAPTCHA pro své uživatele iOS 16 a novějších v Safari, v zúčastněných aplikacích i v prohlížečích třetích stran. V tomto nasazení Apple využívá svou roli poskytovatele hardwaru k tomu, aby mohl dokládat legitimitu zařízení pomocí signálů, jako je platné Apple ID a kontroly integrity zařízení, místo CAPTCHy. Rozdělení rolí vypadá takto:

Toto nasazení využívá plně oddělený model, kdy všechny role provozují subjekty, které spolu netajně nespolupracují. Rozdělený model je ideální pro Apple, protože jejich role poskytovatele hardwaru a infrastruktury přirozeně odpovídá roli Attesteru. Pro zákazníky, kteří vystupují jako Origin, však může být tento model méně užitečný, protože buď je nutné přizvat třetí stranu jako Attestera, nebo role sloučit mezi Cloudflare a zákazníka tak, aby byly obsazeny všechny tři role.

Vývojáři aplikací mohou chtít zajistit, že uživatelé jejich služby jsou předplatiteli nebo splňují určitý věk, aniž by tuto informaci trvale ukládali u jejich účtu. V takovém případě použití může rozdělení rolí vypadat takto:

Toto nasazení využívá společný model Attester-Issuer, kde Cloudflare provozuje jak Issuera, tak Attestera. Pokud zákazník vystupuje jako Origin, obvykle by neměl provozovat i Attestera, protože by tím vznikl subjekt Origin-Attester, který zná identitu uživatele i cíl, což výrazně ztěžuje zaručení soukromí. Provozování Attestera společně s Issuerem ze strany Cloudflare umožňuje vyhnout se zavádění zcela nové třetí strany, i když to není nutné. Společný model Attester-Issuer je užitečný i v opačném případě, kdy je zákazník autoritou pro identitu (například poskytovatel podnikového IdP/SSO) a chce nabídnout soukromé ověřování pro své Originy.

Privacy Pass také pohání stávající produkty Cloudflare. Nejzavedenějším příkladem je Privacy Proxy, používané v single-hop (Microsoft Edge Secure Network ↗) a double-hop (Apple Private Relay ↗) nasazení, kde Privacy Pass zajišťuje počáteční autentizaci mezi klientem a proxy (nebo první proxy v případě double-hop). Pokud váš případ použití odpovídá existujícímu produktu, může to být nejjednodušší cesta. Architekturu na úrovni proxy najdete v Modely nasazení Privacy Proxy.

• Protokol Privacy Pass
• Testování produkčního nasazení jak vypadá nasazení jednoho z těchto modelů s Cloudflare.
• Replace CAPTCHAs with Private Access Tokens (Apple WWDC22) ↗ přehled společnosti Apple k jejich nasazení Private Access Token.