Technologie

Jak funguje Kavozi pod kapotou

Co kdyby ses mohl na internetu prokázat, aniž bys musel komukoliv říkat, kdo jsi?

Jak může služba poznat, že se vrací stejný člověk, když nezná jeho jméno, e-mailovou adresu ani heslo? Odpověď nabízí kryptografie — a právě od této otázky se odvíjí technologie Kavozi.

Kavozi jsem začal vytvářet, protože jsem chtěl jednoduchý způsob, jak najít člověka se stejným záměrem. Brzy jsem narazil na další problém: proč by kvůli jednorázovému hledání měl kdokoliv vyplňovat další registrační formulář? A proč by kontakt, který díky službě vznikne, měl zůstat navždy závislý na jejím provozovateli?

Rozhodl jsem se proto oddělit kryptografickou identitu od klasického uživatelského účtu a přemýšlet o vztazích jako o něčem, co má smysl i po skončení původního záměru.

Na této stránce se postupně dostaneš přes čtyři témata: identitu, spojení, důvěru a svobodu. Každé navazuje na předchozí. K základnímu příběhu nepotřebuješ znalosti programování; technická vysvětlení, algoritmy a schémata najdeš v rozbalovacích částech Pod kapotou.


Kdo jsi, když nemáš účet?

Představ si, že objevíš zajímavou internetovou službu. Chceš ji vyzkoušet, ale ještě než se dostaneš k tomu, kvůli čemu jsi přišel, čeká tě známý postup.

Zadej e-mail. Vymysli heslo. Potvrď registraci. Vyplň profil.

Možná službu použiješ jen jednou. Možná se k ní už nikdy nevrátíš.

Přesto jsi jí právě svěřil část svých osobních údajů a získal další účet, o který se musíš starat.

Ale potřebuje služba skutečně znát tvoji totožnost? Nebo jí stačí poznat, že se vrací stejný uživatel?

To jsou dvě velmi odlišné věci.

Účet a identita odpovídají na jiné otázky

Když se s někým seznámíš na veřejné akci, nemusíš znát jeho adresu ani datum narození. Při dalším setkání stačí, že ho poznáš.

Na internetu chybí podobný spolehlivý signál. Aplikace proto potřebuje způsob, jak ověřit, že s ní znovu jedná držitel stejné digitální identity.

Mnoho služeb tuto kontinuitu zajišťuje uživatelskými účty. Kavozi pro ni používá kryptografickou identitu.

Kryptografická identita nepotřebuje tvoje jméno ani e-mail. Umožňuje prokázat kontrolu nad určitým soukromým klíčem. Sama o sobě přitom neověřuje občanskou totožnost člověka.

A ostatní si to mohou ověřit, aniž bys jim svůj klíč musel prozradit.

Dva klíče místo dalšího hesla

Při vytváření identity vznikne na tvém zařízení dvojice kryptografických klíčů.

Soukromý klíč slouží k vytváření digitálních podpisů. Má zůstat pod tvou kontrolou a chráněný před přístupem ostatních.

Veřejný klíč můžeš bez obav sdílet. Ostatním umožňuje ověřit, že určitá data byla podepsána odpovídajícím soukromým klíčem.

Oba klíče spolu matematicky souvisejí. Z veřejného klíče ale není prakticky možné odvodit ten soukromý.

Představ si osobní pečeť: nástroj k jejímu vytvoření držíš ty, zatímco ostatní umějí výsledek ověřit.

Na rozdíl od běžného hesla nemusíš při ověřování svoji tajnou informaci nikomu posílat.

A právě to je zásadní rozdíl.

Pod kapotou: Ed25519 a digitální podpisy

Kavozi pro podpisovou identitu používá algoritmus Ed25519, založený na kryptografii eliptických křivek. Jeho specifikaci popisuje RFC 8032. [1]

Při generování klíčového páru vzniknou:

  • Private key — tajný podpisový klíč.
  • Public key — veřejný ověřovací klíč.

Podepisování lze zjednodušeně zapsat jako:

signature = Sign(privateKey, message)

Ověření podpisu:

valid = Verify(publicKey, message, signature)

Pokud je podpis platný, ověřovatel má silný kryptografický důkaz, že jej vytvořil někdo s přístupem k odpovídajícímu soukromému klíči.

To samo o sobě neprokazuje občanskou totožnost člověka. Prokazuje to kontrolu nad klíčem.

Digitální podpis také není šifrování. Podepsaná zpráva nemusí být tajná — podpis pouze chrání její autenticitu a integritu.

Jak Kavozi pozná, že jsi to opravdu ty?

Klíčový pár je připravený. Jak může Kavozi ověřit, že soukromý klíč skutečně ovládáš?

Představ si, že serveru jednoduše pošleš svůj veřejný klíč a oznámíš:

„Tohle jsem já.“

Samotné tvrzení nestačí: veřejný klíč může znát kdokoliv. Rozhodující je důkaz, že dokážeš použít odpovídající soukromý klíč.

Kavozi proto při registraci kryptografické identity používá postup označovaný jako challenge–response.

Funguje to následovně:

  1. Požádáš o registraci identity. Kavozi ti pošle jednorázovou výzvu — challenge.
  2. Výzvu podepíšeš. Tvoje zařízení použije soukromý klíč k podpisu přesně definovaných registračních dat obsahujících tuto výzvu.
  3. Odešleš podpis. Server obdrží podepsaná data a tvůj veřejný klíč. Soukromý klíč mu nikdy neposíláš.
  4. Kavozi podpis ověří. Pomocí veřejného klíče zkontroluje, zda podpis odpovídá očekávaným datům.
  5. Identita je zaregistrována. Kavozi nyní zná tvůj veřejný klíč a má důkaz, že při registraci byl použit odpovídající soukromý klíč.

Proč je důležitá jednorázová výzva?

Brání tomu, aby někdo jednoduše zachytil a později znovu použil starý registrační podpis.

Každá nová výzva vyžaduje nový platný podpis.

Pod kapotou: Challenge–response krok za krokem

Zjednodušené schéma registračního procesu:

KLIENT                         KAVOZI
  |                               |
  |------ Request challenge ----->|
  |                               |
  |<----- Random challenge -------|
  |                               |
  |  Construct registration       |
  |  statement with challenge     |
  |                               |
  |  Sign using Ed25519           |
  |                               |
  |------ Public key ------------>|
  |------ Signed statement ------>|
  |------ Signature ------------->|
  |                               |
  |                    Verify signature
  |                    Verify challenge
  |                    Validate registration
  |                               |
  |<----- Registered identity ----|
  |                               |

Server musí ověřit nejen digitální podpis, ale také platnost, účel a jednorázovost výzvy a správnou strukturu podepisovaných dat.

Tím se omezuje riziko replay útoků a použití podpisu v jiném kontextu, než pro který byl vytvořen.

V Kavozi takto vzniká node: registrovaná kryptografická identita klienta s veřejným klíčem na serveru a soukromým klíčem spravovaným klientem. Node nemusí odpovídat jedné fyzické osobě ani všem jejím zařízením.

Registrační mechanismus je však třeba odlišovat od autorizace každého dalšího API požadavku. Ta může používat další samostatné mechanismy.

K čemu je potom účet?

Pro správu některých služeb, například předplatného, může být uživatelský účet praktický. V Kavozi může existovat vedle kryptografické identity, která funguje bez klasického přihlášení e-mailem a heslem.

Teď už máš identitu, kterou lze ověřit. Zatím však nikdo neví, co hledáš — a ty nevíš, koho by stálo za to oslovit.

Právě tento krok řeší další kapitola.

Jak se dvě identity propojí?

Kryptografická identita umožňuje prokázat, že se vrací stejný node. Sama však žádné lidi nepropojí. K tomu je potřeba objevit společný záměr, získat souhlas a vytvořit prostor pro komunikaci.

Cesta od dvou neznámých identit k první zprávě začíná otázkou: co chceš dělat?

Nejdřív musíš vědět, co hledáš

Představ si, že se chceš naučit fotografovat noční oblohu.

Máš fotoaparát, trochu času a chuť vyrazit někam za město. Jen bys uvítal společnost někoho, kdo má podobný zájem.

V Kavozi jednoduše vytvoříš záměr:

„Hledám někoho na společné fotografování hvězdné oblohy.“

Můžeš určit oblast, ve které hledáš, a případně také čas, kdy by ses chtěl aktivitě věnovat.

Kavozi pak může vyhledávat další záměry, které s tím tvým souvisejí.

Třeba zjistí, že někdo v okolí plánuje pozorování meteorického roje a uvítal by společnost.

Takovému vyhledávání říkáme discovery.

Podle nastavení může být záměr vyhledatelný i poté, co zavřeš stránku. Jeho dostupnost a životnost závisejí na pravidlech služby a nastavení vyhledávání.

Nemusíš vědět, koho hledáš. Stačí vědět, co bys chtěl uskutečnit.

Pod kapotou: Presence, intent a discovery

Kavozi rozlišuje několik důležitých konceptů.

Node

Kryptografická identita klienta představená v první kapitole.

Presence

Reprezentuje aktuální účast klienta v systému. Může obsahovat informace potřebné k discovery, například nastavení oblasti vyhledávání.

Intent

Popisuje záměr uživatele. Může mít vlastní pravidla dostupnosti, geografické podmínky nebo časový plán.

Discovery

Proces vyhledávání kompatibilních záměrů podle pravidel platformy.

Zjednodušený vztah mezi těmito koncepty:

       NODE
        |
        | participates through
        v
     PRESENCE
        |
        | makes discoverable
        v
      INTENT
        |
        | discovery
        v
   COMPATIBLE INTENT

Kompatibilita záměrů představuje aplikační rozhodnutí. Kryptografie sama o sobě neurčuje, zda dva lidé hledají totéž.

Kavozi musí pro discovery zpracovávat příslušná data o záměrech a jejich podmínkách.

Rozsah těchto informací je proto důležitou součástí bezpečnostního a soukromého modelu systému.

O spojení rozhodujete oba

Nalezení kompatibilního záměru je teprve začátek.

Kavozi může upozornit na člověka, který hledá něco podobného. Samotná podobnost záměrů však ještě neznamená, že spolu chcete komunikovat.

Proto má vznik spojení vlastní pravidla souhlasu.

Když dostaneš nabídku propojení, můžeš se rozhodnout, zda chceš pokračovat.

Stejnou možnost má i druhá strana.

Některé záměry mohou mít nastavený automatický souhlas, pokud si jej uživatel předem výslovně zvolí.

Jakmile jsou splněny podmínky obou stran, může vzniknout encounter.

Encounter je v Kavozi prostor pro konkrétní propojení dvou digitálních identit.

Právě zde mohou účastníci začít komunikovat a domluvit se, co bude dál.

Může z toho vzniknout jednorázové setkání, společná aktivita nebo dlouhodobější kontakt.

A někdy se také ukáže, že společný záměr nakonec nevede nikam. I taková možnost je přirozenou součástí lidského rozhodování.

Od encounteru k první zprávě

Obě strany souhlasily se spojením a encounter vznikl. Teď si chtějí napsat.

Zpráva musí nějakým způsobem putovat od odesílatele k příjemci. Kavozi zde vystupuje jako prostředník.

Pomáhá komunikaci zprostředkovat a doručovat jednotlivé zprávy.

Tím se ale dostáváme k důležité otázce.

Musí Kavozi znát obsah zprávy, aby ji dokázalo doručit?

Koncepce end-to-end šifrování (E2EE) umožňuje přenášet zprávy tak, aby k jejich obsahu měli přístup jen účastníci konverzace. Úroveň této ochrany závisí na konkrétním protokolu a jeho implementaci.

Při správně navrženém a implementovaném end-to-end šifrování vzniká šifrovaná podoba zprávy přímo na zařízení odesílatele.

Server přenáší zašifrovaná data.

Čitelnou podobu zprávy získá až zařízení určeného příjemce.

Taková komunikace vyžaduje, aby si obě strany dokázaly bezpečně vytvořit nebo odvodit šifrovací klíče.

A zde znovu využijeme asymetrickou kryptografii.

Jak se domluvit na tajemství, které nikomu nepošleš?

Představ si, že chceš s druhým člověkem komunikovat pomocí společného tajného klíče.

Pokud bys mu tento klíč jednoduše poslal, musel bys nejprve vyřešit, jak jej při přenosu ochránit.

Kryptografie nabízí elegantnější možnost.

Dvě strany mohou pomocí svých soukromých klíčů a veřejně vyměněných údajů nezávisle odvodit stejné sdílené tajemství.

Jedním z algoritmů pro takovou dohodu je X25519. [2]

Každý účastník provede výpočet na svém zařízení. Výsledkem může být společné tajemství, ze kterého se následně odvodí klíče potřebné k šifrování komunikace.

Soukromé klíče přitom zůstávají u svých vlastníků.

Zní to možná překvapivě. Obě strany provedou odlišné výpočty, ale díky matematickým vlastnostem algoritmu dospějí ke stejnému výsledku.

A právě to umožňuje bezpečnou dohodu klíčů i prostřednictvím komunikačního kanálu, který sám o sobě není tajný.

Pod kapotou: Ed25519, X25519 a šifrování

Při návrhu kryptografické komunikace je důležité oddělit dvě úlohy.

Ed25519 — digitální podpisy

Slouží k vytváření a ověřování digitálních podpisů.

Umožňuje ověřit, že data podepsal držitel odpovídajícího soukromého klíče. [1]

X25519 — dohoda sdíleného tajemství

Umožňuje dvěma stranám nezávisle odvodit stejné tajemství prostřednictvím Diffie–Hellmanova mechanismu na eliptické křivce. [2]

Schematický příklad:

Alice                          Bob
  |                             |
  |                             |
  | Generate X25519 keypair     |
  |                 Generate X25519 keypair
  |                             |
  |------ Public Key A -------->|
  |<----- Public Key B ---------|
  |                             |
  |                             |
  | Compute shared secret       |
  |                 Compute shared secret
  |                             |
  v                             v
Shared Secret              Shared Secret
       \                     /
        \                   /
         SAME SECRET VALUE

Získané tajemství se následně používá jako vstup pro bezpečné odvození šifrovacích klíčů.

Samotný X25519 nešifruje zprávy a nezajišťuje autentizaci protistrany.

Kompletní protokol proto musí řešit také:

  • Ověření identity účastníků.
  • Vazbu mezi podpisovou identitou a klíči pro komunikaci.
  • Odvozování a oddělování šifrovacích klíčů.
  • Autentizované šifrování obsahu.
  • Ochranu proti opakování zpráv.
  • Životní cyklus klíčů a jejich případnou obnovu.

Jako příklad standardizovaného řešení lze uvést HPKE, které kombinuje ustavení a odvození klíčů s autentizovaným šifrováním. [3] Z této zmínky nevyplývá, že Kavozi používá HPKE.

Schéma výše vysvětluje obecný princip. Přesný handshake a bezpečnostní záruky protokolu KAVOZI_E2EE_V1 je nutné doložit jeho implementací; samotná deklarace podpory protokolu nestačí.

Jak putuje zašifrovaná zpráva?

Jakmile mají účastníci bezpečně ustavené komunikační klíče, přichází na řadu samotná zpráva.

Účastníci mají navázaný encounter. Jeden z nich napíše:

„Ahoj, můžeme se domluvit na sobotu?“

Jeho zařízení zprávu zašifruje.

Kavozi přijme její šifrovanou podobu a zajistí předání druhému účastníkovi.

Příjemcovo zařízení zprávu rozšifruje a zobrazí ji v konverzaci.

Celý princip lze vyjádřit jednoduše:

ODESÍLATEL             KAVOZI             PŘÍJEMCE
    |                     |                   |
    |  "Ahoj!"            |                   |
    |                     |                   |
    |  Encrypt            |                   |
    |                     |                   |
    |---- Ciphertext ---->|                   |
    |                     |                   |
    |                     |---- Ciphertext -->|
    |                     |                   |
    |                     |             Decrypt
    |                     |                   |
    |                     |                "Ahoj!"

V tomto modelu server přenáší šifrovaná data. Pokud je E2EE správně implementované, klíče jsou autentizované a koncová zařízení nejsou kompromitovaná, server nepotřebuje znát obsah zprávy.

Provoz služby přesto vyžaduje některé informace o přenosu. Právě k nim se vrátím v další kapitole.

Pod kapotou: Životní cyklus zabezpečené konverzace

Následující schéma představuje koncepční model komunikace. Nejde o přesný seznam API operací současné implementace.

ALICE               KAVOZI                BOB
  |                    |                    |
  |    ENCOUNTER ALREADY ESTABLISHED        |
  |                    |                    |
  |                    |                    |
  |--- Key material -->|                    |
  |                    |--- Key material -->|
  |                    |                    |
  |<------ Authenticated key agreement ---->|
  |                    |                    |
  | Derive keys        |        Derive keys |
  |                    |                    |
  |                    |                    |
  | Encrypt message    |                    |
  |                    |                    |
  |--- Ciphertext ---->|                    |
  |                    |---- Ciphertext --->|
  |                    |                    |
  |                    |     Decrypt message|
  |                    |                    |
  |                    |                    |
  |                    |<---- Ciphertext ---|
  |<--- Ciphertext ----|                    |
  |                    |                    |
  | Decrypt reply      |                    |
  |                    |                    |

Bezpečnost tohoto modelu závisí zejména na autentizaci vyměňovaných klíčů.

Pokud útočník dokáže během výměny neoprávněně nahradit veřejný klíč, může se pokusit o útok typu man-in-the-middle.

Komunikační protokol proto potřebuje spolehlivou vazbu mezi identitou nodu a klíči použitými pro konkrétní konverzaci.

Protokol musí zároveň definovat, co se stane při výměně klíče, opětovném navázání spojení nebo ztrátě zařízení.

Co po setkání zůstává

Cesta začala kryptografickou identitou, pokračovala záměrem a přes vzájemný souhlas vedla k encounteru. Teď se účastníci mohou domluvit na společném pozorování noční oblohy.

Původní plán jednou skončí. Kontakt, který při něm vznikl, může pokračovat — k jeho přenositelnosti se dostanu ve čtvrté kapitole.

Nejdřív je však potřeba pojmenovat hranice soukromí. I při šifrované komunikaci Kavozi vyhledává záměry, propojuje identity a doručuje data. Co se z těchto operací může dozvědět?

Co o tobě Kavozi skutečně ví?

V předchozí kapitole prošla zpráva přes Kavozi v zašifrované podobě. Server přesto potřeboval vědět, komu ji doručit. A ještě předtím pracoval se záměrem a oblastí vyhledávání.

Právě tyto informace určují hranice důvěry mezi tebou a službou. Chci jejich množství omezovat na to, co je skutečně potřeba. Tento princip odpovídá doporučení OWASP minimalizovat uchovávání citlivých údajů. [4]

Co tedy Kavozi potřebuje zpracovávat a co se z takových informací může dozvědět?

Jaké informace Kavozi potřebuje

Vraťme se k záměru fotografovat noční oblohu. Aby Kavozi mohlo hledat vhodné propojení, pracuje s popisem záměru a s oblastí, ve které chceš hledat. Potřebuje také rozlišit digitální identity, ke kterým jsou jednotlivé operace přiřazené.

To jsou informace, se kterými služba pracuje při vyhledávání a propojování lidí.

Pro provoz Kavozi jsou relevantní zejména následující kategorie údajů:

Informace K čemu slouží
Veřejný kryptografický klíč Identifikace nodu a ověřování podpisů
Záměr Vyhledávání kompatibilních požadavků
Oblast hledání Geografické omezení vyhledávání
Presence Informace o aktuální účasti ve vyhledávání
Encounter Evidence vzniklého propojení
Provozní metadata Doručování, zabezpečení a provoz služby

Každá z těchto informací má konkrétní účel.

A každá zároveň představuje určitou odpovědnost.

Soukromí začíná už při vytváření záměru

Když vytvoříš záměr, jeho formulací zároveň rozhoduješ, kolik detailů o sobě poskytneš.

Například věta „Hledám společnost na fotografování hvězdné oblohy v okolí města“ sděluje podstatu plánu bez zveřejnění konkrétní adresy.

Můžeš ale zveřejnit i mnohem osobnější údaje. Třeba přesné místo, kde pravidelně trávíš čas, nebo podrobnosti o svých denních návycích.

A právě tady má ochrana soukromí svůj první limit.

Informace, kterou se rozhodneš sdílet s ostatními, může sama o sobě prozradit více, než očekáváš.

Proto chci, aby lidé měli kontrolu nad obsahem záměrů, oblastí jejich vyhledávání a ukončením jejich dostupnosti.

Obsah zprávy a okolnosti jejího doručení

Ve Spojení už zaznělo, jak může E2EE chránit obsah konverzace. Pro posouzení soukromí je stejně důležité vědět, které informace vznikají kolem samotného přenosu.

Šifrovaná zpráva může být pro server nečitelná, zatímco její směrování a doručování stále zanechává provozní metadata. Ochrana těchto dvou kategorií vyžaduje odlišná opatření.

Pod kapotou: Co chrání end-to-end šifrování?

Rozsah ochrany E2EE závisí na autentizaci klíčů a konkrétním komunikačním protokolu. Nestačí pouze zašifrovat jednotlivé zprávy.

Je potřeba posoudit zejména:

  • Způsob ověřování veřejných klíčů účastníků.
  • Výměnu a odvozování šifrovacích klíčů.
  • Autentizaci a integritu zpráv.
  • Ochranu před opakovaným přehráním zprávy.
  • Rotaci klíčů a případnou forward secrecy.
  • Chování při kompromitaci koncového zařízení.

Důležité je také oddělení transportního šifrování TLS od koncového šifrování obsahu.

TLS chrání komunikaci mezi klientem a serverem. E2EE při správné implementaci chrání obsah i před prostředníkem, který zprávu doručuje.

Pro bezpečnost celku je zásadní správa klíčů, autentizace protistran a bezpečnost klientské aplikace. [5]

Metadata: informace kolem zpráv

Představ si zalepenou obálku.

Její obsah zůstává skrytý, ale doručovací služba potřebuje vědět, kam ji má dopravit.

Podobně funguje i elektronická komunikace.

I při end-to-end šifrování mohou být pro zprostředkování komunikace dostupné některé provozní informace.

Například:

  • Které digitální identity spolu komunikují.
  • Kdy byla zpráva odeslána nebo doručena.
  • Jak velká je přenášená zpráva.
  • Z jaké síťové adresy klient komunikuje se serverem.

Přesný rozsah těchto informací závisí na implementaci, konfiguraci serveru a pravidlech jejich uchovávání.

Šifrování obsahu tedy automaticky neodstraňuje všechna metadata.

Právě metadata mohou při dlouhodobém sledování vypovídat o chování uživatelů.

Proto považuji za důležité zveřejňovat, které údaje Kavozi zpracovává, proč jsou potřeba a jak dlouho se uchovávají. Konkrétní retenční lhůty musí odpovídat skutečné konfiguraci služby.

Znamená kryptografická identita anonymitu?

Každý uživatel Kavozi může mít svou digitální identitu, aniž by při jejím vytvoření musel sdělit jméno nebo e-mailovou adresu.

To poskytuje určitou míru soukromí.

Současně však veřejný klíč představuje stabilní identifikátor. Pokud jej používáš opakovaně, lze s ním spojovat více aktivit.

Další informace mohou pocházet ze zveřejněných záměrů, lokality nebo samotné komunikace.

GDPR mezi možné osobní údaje řadí také lokalizační údaje a online identifikátory, pokud umožňují přímo nebo nepřímo identifikovat člověka. [6]

Ani používání náhodného identifikátoru proto samo o sobě nezaručuje anonymitu.

Pod kapotou: Anonymita a pseudonymizace

Z pohledu ochrany osobních údajů je důležité rozlišovat:

Anonymizace znamená, že informaci již nelze přiměřeně dostupnými prostředky přiřadit ke konkrétní osobě.

Pseudonymizace omezuje možnost přiřazení informací ke konkrétnímu člověku, například nahrazením přímého identifikátoru pseudonymem.

Pseudonymizované údaje mohou podle GDPR nadále představovat osobní údaje. [6][7]

Veřejný kryptografický klíč může fungovat jako pseudonym, pokud se k němu vážou další informace.

Při návrhu Kavozi proto posuzuji také možnost propojovat jednotlivé údaje do podrobnějšího obrazu uživatelské aktivity.

Co když ztratíš zařízení?

Vlastnictví kryptografické identity přináší také odpovědnost za její ochranu.

Soukromý klíč je důležitou součástí identity. Pokud o něj přijdeš a nemáš bezpečný způsob jeho obnovy, můžeš ztratit možnost tuto identitu dále používat.

Vytvoření nového klíčového páru znamená vznik nové kryptografické identity.

Dříve vytvořené kontakty přitom nemusí automaticky rozpoznat, že jde o stejného člověka.

Možnost obnovy nebo bezpečného převodu identity proto patří mezi důležité otázky dlouhodobého rozvoje Kavozi.

A právě zde vzniká zajímavé napětí:

Chci, aby identita zůstala pod tvou kontrolou a zároveň se dala bezpečně používat i po změně zařízení.

To vyžaduje promyšlenou správu klíčů a jasná pravidla pro případnou obnovu. [5]

Pod kapotou: Uložení klíčů v prohlížeči

Webové aplikace mohou ke kryptografickým operacím využívat Web Crypto API.

Objekty CryptoKey lze v podporovaných prostředích ukládat do IndexedDB prostřednictvím strukturovaného klonování. [8]

Vlastnost extractable určuje, zda lze klíčový materiál exportovat pomocí příslušných operací Web Crypto API. [8]

Zákaz exportu však sám o sobě neřeší všechny bezpečnostní hrozby. Kompromitovaná aplikace může například zneužít operace dostupné s klíčem, i když nedokáže přímo exportovat jeho materiál.

Při návrhu obnovy identity je nutné zvážit:

  • Bezpečnost zálohování.
  • Přenos mezi zařízeními.
  • Revokaci kompromitovaných klíčů.
  • Propojení staré a nové identity.
  • Dopady ztráty přístupu k lokálnímu úložišti.

Konkrétní možnosti obnovy musí odpovídat implementovanému key lifecycle.

Důvěra musí mít jasné hranice

Kavozi potřebuje určité informace, aby mohlo propojovat lidi. Některé vznikají přímo při používání služby, jiné jsou nezbytné pro její bezpečný provoz.

Každou kategorii údajů chci umět zdůvodnit. Čtenář by měl rozumět tomu, co sdílí s ostatními, co zpracovává server a nad čím si zachovává kontrolu.

Kryptografie dokáže část těchto hranic vynucovat technicky. Zbytek vyžaduje transparentní pravidla, odpovědný provoz a průběžné bezpečnostní ověřování.

Důvěru si služba zaslouží tehdy, když její sliby odpovídají tomu, jak skutečně funguje.

Důvěra ovšem souvisí i se svobodou odejít. Pokud se rozhodneš službu přestat používat, co by se mělo stát s kontakty, které sis přes ni vytvořil?

Touto otázkou začíná poslední kapitola.

Proč by tvoje vztahy měly přežít platformu?

Představ si, že se původní plán fotografovat noční oblohu povedl. Z jedné společné výpravy vznikla malá skupina lidí, kteří se dál setkávají a sdílejí zkušenosti.

Po čase se rozhodneš Kavozi přestat používat. Jak si zachovat kontakty, které díky němu vznikly?

U většiny internetových služeb jsou digitální vztahy úzce propojené s jejich infrastrukturou. Kontakty, konverzace i samotná možnost někoho znovu oslovit závisí na dostupnosti konkrétní aplikace.

A pokud služba jednoho dne skončí, může s ní zmizet i část tvého digitálního života.

Chci, aby vztahy navázané prostřednictvím Kavozi mohly v budoucnu pokračovat i jinde. Přenositelnost zatím představuje architektonický cíl, nikoli hotovou funkci.

Tvoje identita má vlastní základ

Na začátku celého příběhu vznikla identita pod tvou kontrolou. Právě tento základ otevírá cestu k přenositelnosti.

Svoji digitální identitu můžeš prokazovat pomocí soukromého klíče. Pro její kryptografické ověření stačí odpovídající veřejný klíč a znalost pravidel, podle kterých se podpisy vytvářejí.

Díky standardním digitálním podpisům může stejný veřejný klíč v principu ověřovat více nezávislých systémů. [1]

Pokud dvě služby rozumějí stejnému způsobu identifikace a ověřování, mohou v principu rozpoznat stejnou kryptografickou identitu.

V praxi je k tomu potřeba také kompatibilní protokol, bezpečná správa klíčů a způsob, jak ověřit, že veřejný klíč skutečně patří očekávanému účastníkovi.

Vztah mezi dvěma identitami

V Kavozi vzniká kontakt postupně.

Nejdříve se potkají kompatibilní záměry. Následuje vzájemný souhlas a vytvoření spojení, kterému říkáme encounter.

Dva lidé tak získají možnost spolu komunikovat.

Do budoucna chci umožnit, aby takové propojení mělo přenositelnou podobu.

Představ si, že si obě strany uchovají kryptograficky ověřitelný záznam o navázaném kontaktu.

Každá z nich pak může nezávisle prokázat svou identitu a za předem stanovených podmínek obnovit komunikaci prostřednictvím jiné kompatibilní infrastruktury.

Jednou vytvořený kontakt by se tak mohl stát trvalou součástí tvého digitálního života.

Samozřejmě pouze v rozsahu, se kterým souhlasí oba účastníci. Každý musí mít možnost kontakt odmítnout, ukončit nebo zablokovat další komunikaci.

Pod kapotou: Jak by mohl fungovat přenositelný vztah?

Jedním z možných přístupů je reprezentovat dlouhodobé propojení kryptograficky ověřitelným záznamem.

Zjednodušený příklad:

{
  "type": "KAVOZI_CONTACT_V1",
  "participants": [
    {
      "identity": "alice-public-key"
    },
    {
      "identity": "bob-public-key"
    }
  ],
  "establishedAt": "2026-10-12T12:00:00Z",
  "proofs": [
    {
      "signer": "alice",
      "signature": "..."
    },
    {
      "signer": "bob",
      "signature": "..."
    }
  ]
}

Jde o ilustrativní návrh, nikoliv o současný formát protokolu Kavozi.

Aby byl takový záznam bezpečně použitelný, bylo by nutné definovat například:

  • Kanonickou reprezentaci podepisovaných dat.
  • Jednoznačnou identifikaci účastníků.
  • Ověření souhlasu obou stran.
  • Ochranu před opakovaným použitím.
  • Možnost ukončení nebo zneplatnění vztahu.
  • Pravidla pro výměnu a obnovu klíčů.
  • Způsob bezpečného vyhledání druhého účastníka.

Podpisy Ed25519 mají veřejně dostupnou specifikaci. [1]

Jiný pohled na identifikátory a jejich ověřovací metody nabízí standard W3C Decentralized Identifiers (DID). [9]

Kavozi však v současnosti netvrdí kompatibilitu s DID standardem.

Co když budeš chtít změnit server?

Dnes funguje Kavozi s vlastní serverovou infrastrukturou, která zajišťuje vyhledávání záměrů, registraci nodů a zprostředkování komunikace.

Do budoucna chci prozkoumat možnost přesunout komunikaci na jinou kompatibilní infrastrukturu.

Třeba na server provozovaný komunitou, organizací nebo někým, komu důvěřuješ.

Při takovém přesunu by měla být zachována kontinuita identity a podle možností také existujících kontaktů.

To přináší několik technických otázek.

Jak druhá strana zjistí, na kterém serveru tě zastihne?

Jak ověří, že nový server skutečně zastupuje tvoji identitu?

A jak zabránit tomu, aby někdo neoprávněně oznámil změnu tvého komunikačního místa?

Odpovědi budou vyžadovat otevřený komunikační protokol a kryptograficky ověřitelné změny kontaktních informací.

Mým dlouhodobým cílem je, aby změna poskytovatele nemusela znamenat ztrátu digitální identity a kontaktů.

Pod kapotou: Identita, hosting a decentralizace

Pro pochopení architektury je užitečné oddělit tři vrstvy:

1. Kryptografická identita

Identita je reprezentována kryptografickým materiálem, který umožňuje ověřit kontrolu nad soukromým klíčem.

2. Discovery a koordinace

Server pomáhá vyhledávat kompatibilní záměry, spravovat jejich životní cyklus a zprostředkovávat vznik spojení.

3. Komunikační infrastruktura

Server může zprostředkovávat doručování zpráv mezi účastníky.

Tyto vrstvy mohou být architektonicky oddělené, přestože dnes využívají společnou infrastrukturu Kavozi.

Možný budoucí model:

           KRYPTOGRAFICKÁ IDENTITA
                    |
             Public Key
                    |
          +---------+---------+
          |                   |
          v                   v
    Kavozi Server       Community Server
          |                   |
          |                   |
          +---------+---------+
                    |
              Kontakt / Relay
                    |
             Jiná identita

Toto schéma představuje dlouhodobý architektonický směr.

Jeho praktická realizace by vyžadovala zejména:

  • Standardizovanou reprezentaci identity.
  • Mechanismus nalezení aktuálního komunikačního endpointu.
  • Autentizované oznámení změny serveru.
  • Interoperabilní komunikační protokol.
  • Pravidla pro zneplatnění starých endpointů.
  • Ochranu soukromí při migraci.

Podobné problémy řeší také ekosystém decentralizovaných identifikátorů; jde o inspiraci pro návrh, nikoli o deklaraci kompatibility Kavozi s DID. [9]

Kontinuita identity i při změně klíče

V kapitole Důvěra zaznělo, proč je ztráta zařízení a soukromého klíče závažná. Přenositelnost přidává ještě jednu otázku: co když bude potřeba klíč bezpečně vyměnit?

Jestliže kontakty ověřují tvou identitu prostřednictvím určitého veřejného klíče, potřebují důvěryhodný důkaz, že nový klíč patří stejnému účastníkovi.

Správa této kontinuity musí počítat také s kompromitací klíčů a se situací, kdy původní klíč už není dostupný. [10]

Pod kapotou: Rotace klíčů a kontinuita identity

Při změně kryptografického klíče může vzniknout problém s kontinuitou identity.

Pokud například nová identita pouze oznámí, že nahrazuje starou, ostatní účastníci nemají dostatek důkazů, aby takové tvrzení přijali.

Jednou z možných metod je autorizovat přechod podpisem původního soukromého klíče.

Old Identity
     |
     | Signs key transition
     v
New Identity
     |
     | Verification by contacts
     v
Identity continuity accepted

Tento postup je použitelný pouze za předpokladu, že původní klíč zůstává důvěryhodný.

Při jeho kompromitaci je potřeba nezávislý mechanismus obnovy důvěry.

Možnosti zahrnují například předem registrované obnovovací klíče, více nezávislých autorizačních prostředků nebo potvrzení změny prostřednictvím jiného důvěryhodného kanálu.

Konkrétní pravidla musejí být součástí bezpečnostního modelu protokolu.

Obecná doporučení pro životní cyklus kryptografických klíčů uvádí NIST SP 800-57. [10]

Internet, na kterém mohou vztahy pokračovat

Kavozi začalo jako nástroj pro nalezení lidí se společným záměrem.

Postupně se ale ukazuje, že samotné propojení může mít mnohem delší životnost než původní důvod, kvůli kterému vzniklo.

Ze společné aktivity se může stát pravidelné setkávání. Ze setkávání komunita. A z náhodného kontaktu dlouholeté přátelství.

Bylo by škoda, kdyby takové vztahy zůstaly navždy závislé na osudu jedné internetové služby.

Proto chci Kavozi rozvíjet směrem k otevřené architektuře, která by v budoucnu umožnila zachovat identitu i navázané kontakty napříč kompatibilními systémy.

Je to dlouhodobý cíl, ke kterému vede řada technických i bezpečnostních rozhodnutí.

Nejdůležitější součástí Kavozi jsou lidé a vztahy, které mezi nimi vznikají.

Věřím, že technologie jim má dávat možnost rozhodovat, kde a jak budou pokračovat.


Reference

[1] RFC 8032 — Edwards-Curve Digital Signature Algorithm (EdDSA). Specifikace Ed25519 a ověřování digitálních podpisů.

[2] RFC 7748 — Elliptic Curves for Security. Specifikace X25519 a mechanismu pro dohodu sdíleného tajemství.

[3] RFC 9180 — Hybrid Public Key Encryption. Příklad standardního propojení ustavení klíče, jejich odvození a autentizovaného šifrování; nejde o deklaraci, že Kavozi používá HPKE.

[4] OWASP — Cryptographic Storage Cheat Sheet. Doporučení minimalizovat ukládání citlivých informací a chránit uložená data podle rizik.

[5] OWASP — Key Management Cheat Sheet. Zásady ochrany a správy kryptografických klíčů.

[6] GDPR — Nařízení (EU) 2016/679, článek 4. Definice osobních údajů, online identifikátorů a pseudonymizace.

[7] European Data Protection Board — Anonymisation / Pseudonymisation. Materiály k anonymizaci, pseudonymizaci a ochraně osobních údajů.

[8] MDN — SubtleCrypto a CryptoKey. Ukládání klíčů do IndexedDB, rozhraní CryptoKey a vlastnost extractable.

[9] W3C — Decentralized Identifiers (DIDs) v1.0. Standard decentralizovaných identifikátorů a ověřovacích metod, využitý zde jako architektonická inspirace.

[10] NIST SP 800-57 Part 1 Rev. 5 — Recommendation for Key Management. Doporučení pro bezpečný životní cyklus kryptografických klíčů.