Eida.cz - Křivkami ověřované temnoslužby

Je pravda, že poslední koronadny na každého kladou nějaké nároky a sem tam se najde i někdo, koho přestanou basic věci naprosto motivovat a rozhodne se utéct do světa temnoslužeb a být u toho děsně dárk a ívl. Takže kromě toho, že se při přípravě demo virtuálu k dnešnímu povídání ukázalo, že výchozí nastavení Debianu 10 (tedy alespoň z netinstallu a po prvním bootu) vůbec nepočítá se zahrnutím /usr/sbin do systémové cesty, se vlastně neděje nic jakože převratného. Řeč bude o skrytých službách Toru (hidden services) verze 3 a možnostech jejich ještě hlubšího skrytí pomocí vícevrstvé autentizace s využitím budoucnosti, tedy asymetrické kryptografie nad eliptickými křivkami. A proč? Protože proč ne přece.

Temnoslužby dárknetu s křivkami Ed25519 – ilustrační artwork.

Takhle myšlenka sice celkově není vůbec nová, i když je pravda, že v češtině o této problematice nic napsaného prakticky neexistuje a co je někde v angličtině, to zas úplně nepopisuje možnosti nějakého škálování, nebo jak to říct jazykem posledního týdne, možnosti skrytí se v šatu noslagie hyperkonvergované kryptoinfrastruktury. Myslet hyperkonvergovaně a zároveň mluvit o overlay sítích je možná trochu paradox, neboť rychlost a vysoká dostupnost v nich není úplně prioritou, ale dá se to celé pochopit i třeba tak, že můžeme mít k dispozici geograficky distribuovaný systém složený z maličkých částí (třeba Raspberry Pi strojů) zapojených prakticky kdekoliv a dostupných prakticky odkudkoliv. Samozřejmě základem takové pseudo-krypto-HCI bude muset být očividně mesh, ale to je právě to, co z toho udělalo zajímavé téma.

S přeskočením basic věcí budu automaticky předpokládat, že zhruba víme, co Tor je, a že dovedeme nastavit jeho skrytou službu (asi dále jen HS jako hidden service) pod linuxovým systémem. Jako příklad tady zjednodušeně použijeme SSH – to může mít spoustu výhod, třeba když si zapojíme Píčko někde u Verči na stole za NATem a chceme z něj sosat statistiky měření zlobivého ISP. Žádné tunelování, žádná VPN, prostě takhle nějak jednoduše. Takže když to nazvu jako service-B, patřičná změna v /etc/torrc bude

a po restartu služby tor v systemd se sama vygeneruje nějaká nová adresa verze 3, v tomhle případě třeba jako je tomu na obrázku. Jak je vidno, adresy třetí verze mají 56 znaků a jsou složené z několika částí, ale používat se dají samozřejmě úplně stejně, jako ty kratší starší. Tadyc u SSH se tohle pochopitelně neotevírá v předpřipraveném TorBrowseru, ale vyloženě se skrze torsocks začaruje ssh klient a naváže spojení na vzdálený stroj.

Běžná situace spojení s HS.

Každé spojení jde pokaždé de facto z localhostu, takže je to vlastně úplně jedno, jaká služba to je a pro co je vlastně určená. U SSH je to o to vtipnější, že se u něj z principu používá ověřování a každý určitě zná ten den, kdy mu nějaká robot z Číny začne bruteforcem hackovat názvy účtů z 80tek. Tohle se obvykle vylepšuje zákazem přihlašování pomocí hesel a na řadu přicházejí, tadá, asymetrické šifry, z nichž je teď velitelem budoucnosti právě eliptično a konkrétně soudobá posedlost Edwardsovou křivkou 25519. No a kdo v asymetrické kryptografii nemá platný privátní klíč ke svému veřejnému protějšku, nepřihlásí se. Jenže co kdybychom to zakryptovali ještě o level výše a služba využívající ECC ověření by neexistovala do chvíle, kdy by se uživatel pro dané spojení neověřil jinou ECC? Asi by to vypadalo možná následovně.

Ověření spojení klienta s HS pomocí asymetrické kryptografie.

Tohle funguje skutečně tak, že HS na straně serveru ověřuje klienta podle jeho prokázání se odpovídajícím klíčem a pokud se to nezdaří, klient dostane na úrovni sítě hlášení no route a očekávaná služba se vůbec neukáže. To zní prostě úžasně, ale teď jak na to a proč? V první řadě protože je to cool. Za další... se to musí nějak nastavit, ale to už tak intuitivní není. Protože tor obvykle běží jako systémový démon mimo uživatelský kontext, není možné si správu klíčů představit jako třeba u toho SSH. Namísto toho právě démon má přiřazené nějaké úložiště privátních klíčů specifikované v jeho instanci (takže čistě teoreticky nějakým jiným torrc můžeme simulovat uživatelský kontext), které se ale vztahuje na konkrétní vzdálené služby. Každá vzdálená HS pak eviduje v seznamu veřejné klíče svých povolených klientů.

Můžeme začít tedy tím nejjednodušším, vytvořením direktivy specifikující výchozí systémové úložiště privátních klíčů. Není na to vyloženě inline dokumentace, ale prakticky do /etc/tor/torrc přijde extra řádek ve tvaru 

a je to prakticky vybavené. Vlastně není, protože pokus o restart démona skončí havárií neskutečných rozměrů, neboť na rozdíl od tvorby nové HS není žádná adresářová struktura vytvořena. Takže manuálně v Debianu to bude nějak takhle. A pozor, je to všechno hodně háklivé na patřičný chmod.

Tím je sice vytvořený adresář s úložištěm, ale chybí ještě... ty klíče. No a bohužel neexistuje žádná přímočará utilita na vygenerování Tor klíče, zatím se to celé musí manuálně. Použít se naštěstí dá prakticky cokoliv, co dovede pracovat s křivkou Ed25519, takže OpenSSL, PyNaCl pro Python, Crypt::Ed25519 v Perlu a jiné, hodně podobné knihovny a nadstavby. Obdobně jako je to výborně vidět třeba u I2P, i Tor pracuje implicitně se vším v base32. To je totiž prima kódování umožňující naprosto bezpečný ASCII přenos psanou formou po webu, kdy není potřeba si dávat pozor na velikost písmenek. Takže je nutné získané klíče – jak privátní, tak veřejný – zakódovat do základu 32 a odebrat z nich nadbytečná rovnítka. Třeba v případě OpenSSL je na to celé docela přímočarý postup v genpkey při volbě algoritmu x25519. Když se výsledek privátního klíče uloží ve formátu PEM, lze z něj stejně dobře extra oddělit i veřejný klíč ve formátu PEM. Takové PEM jsou ale kódovány v b64, takže je musíme streamově dekódovat do binární podoby, a tu následně zakódovat v základu 32 a vymazat přebytečná rovnítka. Postupů je tedy více, ale budeme uvažovat dle obrázku, že si nový náš klient vytvořil následující pár.

Co teď s tím? Začneme tou jednodušší částí. Veřejný klíč potřebuje dostat vzdálená HS (service-B), aby věděla, s kým má tu čest. Takže na stroji B bude někde v /var/lib/tor/ adresář služby service-B a v něm podadresář authorized_clients. Jeho úkolem je schraňovat textové soubory s příponou .auth, Ty mají přesně definovaný tvar složený ze tří částí oddělených dvojtečkou, tou první je magické slovíčko descriptor, následuje jediný podporovaný algoritmus x25519 a jako poslední přichází na řadu veřejný klíč klienta A. Takže stručně a jasně, veřejný klíč klienta A bude mít služba service-B uložený takhle.

descriptor:x25519:RKVMZPI47DOFVBPR3EXX26REL6IMQ5QUQYQGBA2XQMJVUL27UI5Q

A teď následuje to složitější, konfigurace klienta A. Oproti analogii s SSH, kde v known_hosts schraňujeme IP/hostname vzdáleného systému s jeho otiskem, potřebujeme pro Tor klienta vytvořit jednotlivé soubory určené pro jednotlivé HS uložené v adresáři specifikovaném direktivou uvedenou výše (adresář onion_auth), a to ve formátu {adresa služby – 56 bajtů bez pseudodomény .onion}, slovíčko descriptor, označení x25519 a privátní klíč klienta, opět vše oddělené dvojtečkami. Takže klient A bude mít u sebe ve /var/lib/tor/onion_auth soubor s libovolným pojmenováním a příponou .auth_private, v tomhle konkrétním případě pro HS B s následujícím obsahem.

7ppmgbgumugmoppc2j2ro4ougpifbzosuqaqxkstq3gvhcedk4xz3oyd:descriptor:x25519:MBFNE2A5JNLWNJV6QLEBGEMQMFUWGOUUMLO5EPMOBCACTCUXCVCQ

Tohle stačí pro to, aby se první klient dostal na HS B a mohl s ní pohodově komunikovat po dárknetu. Jenže na začátku byla položena nějaká hypotéza o vzájemném propojení, což teda znamená, že klient nebude jen klientem, ale bude také hostovat vlastní službu HS A, nazvěme si ji třeba zase service-A, která dostane adresu y2mh5xbaguxqqj3vanpddal3fnzpv7qpf4uzqiia5h6qpvv3weoexmqd.onion. Situace dostane úplně nový rozměr, najednou se sebou musí komunikovat dvě služby klient/server.

Vzájemná komunikace klient/server bodů A a B.

Už je z toho jasné, že se situace dá posunout do nových hloubek obousměrným vyžadováním autorizace pomocí asymetrické kryptografie, kde oba klienti budou mít nějaké své klíče pro dané služby.

Veřejné a privátní klíče klientů A a B.

V tomhle případě to zase odpovídá nějakému příkladu, kdy se podle výše uvedeného postupu pro klienta B vygeneruje pár ve křívce 25519.

Tento pár zase rozdělíme na privátní a veřejnou část, přičemž tu veřejnou bude u sebe schraňovat nově spuštěná služba HS A ve svém adresáři authorized_clients, v tomto konkrétním případě třeba s označením klient_A.

descriptor:x25519:RKVMZPI47DOFVBPR3EXX26REL6IMQ5QUQYQGBA2XQMJVUL27UI5Q

Privátní část bude potřeba na klientu B zase manuálně vytvořit specifikováním direktivy v jeho torrc a bude obsahovat zase konkrétní službu, tj. v případě HS A bude mít klient B soubor v následujícím smyslu:

y2mh5xbaguxqqj3vanpddal3fnzpv7qpf4uzqiia5h6qpvv3weoexmqd:descriptor:x25519:5Q5LBBT5HZB5XLHGIQJIRII624O4HDAP4XQ2HDCPPBRRMGPNBTSA

Tohle je celkem přímočaré a dá se to dohledat právě v nějakých anglicky psaných cancech a snippetech, co už ale není úplně jasné, jak tohle funguje při tvorbě komplexní meshe. Bohužel to už tak přímočarné není, protože nám sice pohodově stačí veřejné klíče v počtu N, ale soubory s privátními klíči už musí být kvůli specifikaci adresy HS v počtu N*(N-1). Takže poměrně jednoduchý příklad se třemi uzly

Tři klienti/služby.

a adresami

se dovede poměrně rychle zkomplikovat na soustavu o třech souborech s veřejnými klíči, které bude sice vlastnit každá služba, ale taky šesti souborech s privátními klíči, které budou vlastnit klienti pro každou službu zvlášť. Posledním zopakováním generování klíčů pro klienta C vypadne třeba 

a výsledek se hned začne rýsovat už skoro podle úvodního obrázku.

Tři klienti/služby s využitím autorizace.

Takže opět to snadné, každá HS bude mít ve svých autorizovaných klientech .auth soubory pro každého z nich, tedy HS A bude obsahovat klíče pro klienta B a C, HS B bude obsahovat klíče pro klienta A a C a HS C bude obsahovat klíče pro klienta A a B.

descriptor:x25519:RKVMZPI47DOFVBPR3EXX26REL6IMQ5QUQYQGBA2XQMJVUL27UI5Q

descriptor:x25519:QVIKORN4T5FTKLRG2JCP4A6GOEQ7ZHLO2CNOBSSVB5ZERPD4FJHQ

descriptor:x25519:YXZZ5GOTMVAB3TV2QOM2V67FU3VUQD2UEBQ4KEY7TKU6BKJ25NTQ

Na straně klientů se bohužel situace zkomplikuje, protože tam se už soubory nedá úplně jednoduše šetřit. Klient A bude potřebovat svůj privátní klíč extra pro služby HS B a HS C, klient B pro služby HS A a HS C, klient C zas pro služby HS A a HS B – v tomto pořadí tedy následovně, klient A:

7ppmgbgumugmoppc2j2ro4ougpifbzosuqaqxkstq3gvhcedk4xz3oyd:descriptor:x25519:MBFNE2A5JNLWNJV6QLEBGEMQMFUWGOUUMLO5EPMOBCACTCUXCVCQ

jlq7xtnuplfsm3yewvv76ioij5t2qprxjlu5xaribslrwu5p2yxdp3yd:descriptor:x25519:MBFNE2A5JNLWNJV6QLEBGEMQMFUWGOUUMLO5EPMOBCACTCUXCVCQ

Klient B:

y2mh5xbaguxqqj3vanpddal3fnzpv7qpf4uzqiia5h6qpvv3weoexmqd:descriptor:x25519:5Q5LBBT5HZB5XLHGIQJIRII624O4HDAP4XQ2HDCPPBRRMGPNBTSA

jlq7xtnuplfsm3yewvv76ioij5t2qprxjlu5xaribslrwu5p2yxdp3yd:descriptor:x25519:5Q5LBBT5HZB5XLHGIQJIRII624O4HDAP4XQ2HDCPPBRRMGPNBTSA

Klient C:

y2mh5xbaguxqqj3vanpddal3fnzpv7qpf4uzqiia5h6qpvv3weoexmqd:descriptor:x25519:UQ4ZVMKENTFC2D6Q4OIQ2XNRD2JAQ6F6OKJ6BZFBUP7SY3HO4CXA

7ppmgbgumugmoppc2j2ro4ougpifbzosuqaqxkstq3gvhcedk4xz3oyd:descriptor:x25519:UQ4ZVMKENTFC2D6Q4OIQ2XNRD2JAQ6F6OKJ6BZFBUP7SY3HO4CXA

Přestože je to docela magické a může to být matoucí, tímhle způsobem se ale dá skutečně postavit relativně dobře zabezpečená a výborně skrytá mesh, nad kterou může svým způsobem probíhat další čarování podporující hyperkonvergované kryptomyšlení. Je potřeba si umět představit, jak by se asi takovým způsobem dal postavit masivně redundantní, distribuovaný systém, který by odolal téměř libovolnému pokusu o zničení a zavirování. A přitom jsou to jen křivkami ověřované temnoslužby, objednej si temnokoně online, zítra ho dodáme.