Programování s AI, jak funguje Unicode a jak na QUIC, zápisky z InstallFestu

David Čermák: Rychlý úvod do protokolu QUIC

QUIC je složitý protokol a dostat ho do malého embedded zařízení není jednoduché. QUIC také není nic nového, podle služby Cloudflare Radar je v Česku zastoupen jednou třetinou spojení. Dvěma třetinami stále dominuje TLS 1.3.

HTTPS spojuje spolehlivost TCP a šifrování pomocí TLS. Je to hezky propojené a je to krásné, ale dalo by se to dělat rychleji. To je také hlavní cíl protokolu QUIC: rychlost, multiplexované datové proudy a identifikace spojení, která je důležitá pro migraci spojení.

V klasickém HTTPS probíhá spousta kroků, nejprve TCP handshake, poté TLS handshake a teprve někdy v osmém paketu putují samotná data. Vidíte, že by se to určitě dalo dělat celé rychleji.

V případě QUIC se používá takzvané RTT 1, kdy se nejprve pošle inicializace, pak odpověď serveru a už ve třetím paketu putují data. Je možné to dělat za určitých okolností ještě rychleji pomocí 0-RTT. Už v prvním paketu od klienta je možné poslat validní data, ale počítá se s tím, že už bylo spojení navázáno dříve a obě strany mají uložené session tickety. Při dalším spojení už je možné rovnou posílat data.

Použití 0-RTT ale umožňuje replay attack, kdy útočník zaznamená přenášený paket a pak ho může znovu kdykoliv zopakovat. Proto se tato funkce zapíná jen v případě, že chceme posílat požadavky neměnící stav serveru. Pokud přijde nebezpečný požadavek, server ho může odmítnout a vyžádat si plnohodnotné spojení.

Pro integraci do embedded zařízení je možné použít celou řadu knihoven: ngtcp2 (​C), picoquic (​C), quiche (Rust) a esp-http3 (C++). Logicky se díváme hlavně na spotřebu paměti, ale také na integraci s TLS API. V některých případech totiž potřebujeme krypto primitiva.

Dmitrii Misharov: OpenSSL a práce s klíči v hardwaru

Soukromé klíče jsou obvykle uloženy v běžných souborech. Klíče se načtou do paměti a software s nimi může pracovat, je to jednoduché a běžné. Někdy to ale nestačí a potřebujeme s klíči zacházet lepším způsobem.

Jsme nuceni pracovat s klíči bezpečněji, pokud to po nás vyžaduje regulace a legislativa. V případě uložení v souborech je tu totiž riziko úniku klíče, které lze eliminovat speciálním hardwarem zvaným HSM (Hardware Security Module).

HSM je specializované kryptografické zařízení, které se stará o uložení klíčů a provádí kryptografické operace. Podstatné je, že generuje a chrání klíče, které nemůže útočník jednoduše ukrást.

Software pak potřebuje s takovým HSM mluvit a aplikace nemohou ovládat hardware přímo. Potřebujeme nějaké standardizované API, abychom s takovým zařízením mohli komunikovat. Takovému standardu se říká PKCS#11, což je rozhraní v jazyce C, které umožňuje přenášet kryptografické informace.

Původně vzniklo v RSA Laboratories v roce 1994 a od roku 2013 je spravováno organizací OASIS. Původní určení bylo pro komunikaci se smart kartami, hardwarovými tokeny a bezpečnostními zařízeními. Jde o opravdu starý standard, což vysvětluje také jeho starou terminologii.

Důležité je, že aplikace nikdy nevidí soukromý klíč a jen požaduje: tohle zašifruj, tohle podepiš a podobně. OpenSSL nabízí tuto funkcionalitu, klíče přitom mohou ležet kdykoliv. OpenSSL pak potřebuje jakýsi most k těmto datům a právě PKCS#11 je jedním z těchto mostů.

OpenSSL nespravuje klíče v HSM, nezabývá se celým životním cyklem klíčů. Dokáže používat už existující klíče. Pro správu klíčů v HSM je stále potřeba využívat nástroje dodané výrobcem zařízení.

Pokud potřebujete další nástroj pro ladění komunikace pomocí PKCS#11, můžete použít utilitu pkcs11-tool. Pořád to není nástroj pro správu klíčů, ale dokáže vám podat podrobné informace.

Při nasazení HSM nejsou hlavním problémem algoritmy, ale nastavení, důvěryhodnost a dokumentované postupy. Stále jsou v procesu hodně zapojené nástroje od dodavatele.

Klíče jsou uložené ve specializovaném HSM, které je sice nedokáže exportovat, ale to neznamená, že je není možné v případě havárie obnovit. Existují různé postupy, které zahrnují sestavení klíče z uložených klíčových slov nebo z většího množství smart karet.

Josef Reidinger: Code assisted AI a praxe

Josef Reidinger pracuje v SUSE a při práci používá Gemini Pro, protože jeho zaměstnavatel se musí chránit proti právním postihům. Placená verze zaručuje, že se na používaných datech nebude model učit. Brání se tím zejména úniku dat zákazníků.

V praxi používá VSCode bez agentů, kdy AI nemůže přímo zasahovat do kódu, ale vždy vytvoří jen patch. Já si ho můžu prohlédnout a přijmout celý nebo ho ještě před přijetím upravit. Širší možnosti má pak gemini-cli, který už může spouštět příkazy a dělat mnoho věcí. Je to trochu strašidelné, proto to pouštím v kontejneru.

Ukazuje se, že AI je v odpovědích velmi nekonzistentní. Jeden den vám odpoví něco jiného než druhý den. Nebo při code review najde jednou důležitou věc a jindy si jí vůbec nevšimne. To jen pokud máte nové kontextové okno, pokud máte stejné, tak to má tendenci se držet svých předchozích zjištění.

AI je vlastně švýcarský nůž, kterým je možné udělat spoustu věcí. Klasický specializovaný nástroj je ale stále schopen dosáhnout lepších výsledků. Důležité je vždy ověřovat výsledky, někdy si AI vymýšlí a dělá chyby.

Při přímých úpravách kódu se AI chová jako snaživý student, který jde nad rámec zadání. Snaží se měnit ještě další kód, který se mu nějak nelíbí, přestože jsem to po něm nechtěl. Někdy je tak lepší zavřít kontextové okno a začít znovu.

AI je možné použít pro napovídání v editoru, což už přes standardní LSP funguje dlouho správně. Pokud na stejnou úlohu nasadíme AI, začne halucinovat a vymyslí si vlastní metody, které neexistují. Horší je to u jazyků se striktním typováním, třeba v Rustu. Naopak v Ruby není LSP tak účinné a AI může být zajímavější.

Příjemné je použití AI na generování dokumentace, jejíž příprava téměř žádného vývojáře nebaví. Výhodou je, že AI rozumí více jazykům, takže se není třeba zabývat přechodem mezi jazyky. Já to používám jako kostru, do které doplním další informace. Ve vygenerované dokumentaci se obvykle dozvíte, co daná funkce dělá, ale už ne proč to dělá.

Osvědčilo se použití AI pro vytvoření bindingů mezi programovacími jazyky. Máme docela pokročilou knihovnu napsanou v C++, ale potřebujeme ji volat v Rustu. Ukázalo se, že AI se naučí vzorec z existujícího kódu a poté umí automaticky sekat další. Dělá méně chyb než já, protože já při kopírování občas na něco zapomenu. Pořád je potřeba ho ale kontrolovat, jestli jeho práce dává smysl.

Standardně se code review provádí lidskými silami, ale generovaného kódu přibývá, takže je potřeba zapojit AI. Mně osobně to příliš nevyhovuje, protože to je nekonzistentní. Navíc mají modely tendenci psát příliš mnoho komentářů a označovat i drobnosti. Je možné to ale udělat i obráceně, nejprve kód projít ručně a poté pro kontrolu ještě nechat stejnou práci udělat AI.

Klasický vtip říká, že dvěma nejsložitějšími věcmi při programování jsou: pojmenování, invalidace keše a chyba off-by-one. Největší problémy mi dělá pojmenování, které je ovlivněno spoustou pravidel daného jazyka. AI umí vyprodukovat různá doporučení různých délek. Někdy mě až překvapí, co to umí navrhnout.

AI umí nabídnout i obecné konzultace, ale je třeba dát pozor na to, že se snaží vždycky vyhovět. Nikdy to neřekne, že je to úplný nesmysl. Přesto dokáže přijít s dobrými nápady a navést třeba na neznámou knihovnu nebo užitečnou metodu. Je možné do AI například vložit velký výstup s chybou a on se pokusí poradit řešení. Často to funguje efektivněji než vyhledávání.

Ondřej Caletka: Jak funguje Unicode

Počítače jsou digitální stroje, tedy pracují pouze s čísly. Drtivá většina počítačů používá binární soustavu, ve které používáme jen nulu a jedničku. Tuhle nedokonalost kompenzujeme tím, že máme těch bitů hodně. Měli jsme tu 8bitové počítače, dnes používáme 64bitové. Stále je ale základní jednotkou jeden bajt, tedy osmice bitů.

Abychom lépe rozuměli tomu, co se děje uvnitř počítačů, vymysleli jsme si osmičkovou a šestnáctkovou soustavu. Převádět to na desítkovou soustavu je nevhodné, protože pracujeme s mocninami dvojky. V šestnáctkové soustavě potřebujeme symbol pro vyšší hodnoty než devítku, pro ty používáme písmena A až F.

Samotná data však nestačí, vždy záleží na reprezentaci. Potřebujeme tedy vědět, co jednotlivé informace znamenají, zda jde o skupinu čísel, jedno číslo, kladné číslo nebo číslo desetinné. Může jít také o velké číslo rozdělené do více bajtů, pak ukládáme buď nejprve nejméně významnou část (Little Endian) nebo naopak nejvýznamnější (Big Endian). Máme jeden vnitřní stav počítače, ale záleží na tom, jaký mu dáme význam.

Jakákoliv počítačová informace je číslo a některé počítačové informace je zakázáno šířit. Například 128bitový šifrovací klíč AACS pro HD DVD a Blu-ray. Kdokoliv takové číslo zveřejnil, po tom šli, protože tohle se šířit nesmí. Někdo přišel s nápadem, že klíč zakóduje pomocí RGB do vlajky zvané Free speech flag.

ASCII je American Standard Code for Information Interchange a jde o nejrozšířenější kódovou tabulku pro převod uložených čísel do tabulky znaků. Každému kódu je přiřazen jeden znak americké abecedy, číslice, další symboly a řídicí znaky. Je dobré znát tabulku alespoň částečně zpaměti. Tabulka je už dneska vlastně zastaralá, protože umožňuje zobrazit jen znaky americké abecedy a i tam jsou nějaké problémy.

Když se podíváte na teletext, najdete v něm stranu 899, kde najdete hvězdičky střídané s písmenem U a text: „Optimální synchronizace dekodéru“. Teletex kóduje binární data do nevyužitých televizních řádků a umožňuje přenést 40 znaků na 24 řádcích. Kombinace těchto testovacích znaků U a * se používá, protože pravidelně střídá jedničky a nuly. Díky tomu jste si mohli sesynchrnonizovat svůj analogový dekodér.

ASCII nám v mnoha případech nestačí, často potřebujeme do tabulky přidat další znaky – například pro češtinu. ASCII je 7bitové kódování, takže tím nejjednodušším je rozšířit tabulku ještě o druhou polovinu využívající osmý bit. Tak vznikla kódová stránka CP437, která doplňuje řadu různých znaků pro kreslení tabulek, šipek a dalších symbolů. Pořád tam ale není třeba česká diakritika.

Svou vlastní kódovou stránku vytvořili bratři Kameničtí, kteří vzali původní tabulku CP437, našli v ní znaky podobné českým znakům s diakritikou a ty nahradili. Výhodou je, že když zobrazíte český text v původním kódování, stále jste schopni ho nějak přečíst. Šlo ovšem o lokální řešení, které se nikdy nestalo širším standardem.

Takových řešení existovala celá řada: CP852, Windows-1250, ISO-8859–2. Všechna využívají 8bitový zápis a liší se mezi sebou. Druhou možností je zápis pomocí variabilní délky pomocí ISO-6937, kdy se nejprve napíše diakritický symbol a poté teprve znak samotný. Je to podobné, jako na psacím stroji. Jen to nemůžete realizovat v grafické kartě, protože tam máte v paměti pro každý znak jen jeden bajt. Takové ukládání dat se používá například v metadatech digitální televize DVB.

Osmibitové rozšíření nevytváří dostatek místa pro všechny možné kombinace znaků. V jednom textu tak není možné kombinovat různé jazyky a je vždy nutné synchronizovat zdroj a příjemce jazyků. Pokud to nedodržíte, text se nezobrazí správně.

Všechny tyto problémy má řešit Unicode, který pracuje s šestnáctibitovými čísly, která dnes dokážeme zpracovat stejně efektivně, jako dříve osmibitové hodnoty. Díky dostatečné kapacitě lze pro každý znak definovat unikátní kódový bod. V prvních 128 znacích také může zůstat původní ASCII. Unicode má být tak velký, aby do sebe mohl pohltit veškerá jiná kódování.

Velmi brzy se ukázalo, že 65 tisíc znaků nebude stačit pro celý svět. Proto Unicode 2.0 v roce 1996 rozšířilo prostor do dalších bitů. Stále platí, že pro naprostou většinu použití nás to nemusí trápit, protože světové jazyky se do původního prostoru vejdou.

Unicode se věnuje také tomu, jak se ukládají sekvence kódových bodů do souboru. K tomu se historicky používal Unicode Transformation Format, nyní je to Unicode Encoding Form/Scheme. Podle délky slova vznikají standardy UTF-32, UTF-16 a UTF-8.

V případě UTF-32 je každý jeden kódový bod reprezentován jedním 32bitovým číslem. Tohle bude dobře fungovat, pokud máme alespoň 32bitový počítač. Pokud nás netrápí, že je to extrémně prostorové neefektivní, je to funkční varianta.

Naopak nejefektivnější je UTF-8, které kóduje do osmibitových slov s proměnnou délkou. Prvních 128 znaků (ASCII) se mapuje do jednoho bajtu, ve kterém je nejvyšší bit roven nule. Výhodou je, že výsledek je úplně stejný jako ASCII.

Vyšší kódové body se kódují do dvou- až čtyř-oktetových sekvencí. Spočítáme tedy vždy jedničky na začátku bajtu, které jsou následovány nulou. Tím zjistíme, do kolika bajtů je kódován aktuální znak. UTF-8 je tedy velmi efektivní, proto je velmi oblíbený. Výhodou také je, se dokáže automaticky synchronizovat, pokud začneme data číst od libovolného bajtu. Hned zjistíme, jestli se nacházíme uvnitř znaku nebo na hranici mezi znaky.

Unicode má problém v tom, že je nejednoznačný. Jeden řetězec „Ondřej“ můžeme zapsat pomocí šesti bajtů, nebo sedmi bajty – když kombinujeme znak „r“ a kód pro háček. Výstup je úplně stejný, ale uložený řetězec se liší. Proto Unicode definuje způsob normalizace, kdy každý znak má definovanou nejvýš jednu dekompozici.

Součástí Unicode jsou také emoji, což je pro veřejnost nejzajímavější součást standardu. Nabízejí také různé modifikátory jako barva kůže, pohlaví, typ vlasů nebo směr pohybu. Těmi je možné kombinovat jednotlivá emoji do samostatného symbolu. Pokud to příjemce neumí, může zobrazit samostatné znaky. Takto například je možné spojit znak pro ženu, bílou kůži a hasičské auto a vznikne žena-hasička.

Matyáš Pech: Android – od uživatele k vlastnímu systému

Android většina uživatelů vnímá jako telefon, na kterém mohou používat vlastní aplikace. Jde vlastně ale o několik vrstev, přičemž dole je linuxové jádro, nad ním AOSP a služby Google. Vlastní ROM znamená vzít AOSP, vyházet odpad a doplnit vlastní věci.

Jednou z nejslavnějších ROM je CyanogenMod, která vznikla už v roce 2009 a později se pokusila přejít do komerčního režimu. To dopadlo katastrofálně a firma musela zavřít. Komunita se nevzdala a vytvořila fork pod názvem LineageOS.

Při zavádění vlastní ROM je nutné odemknout bootloader, což způsobí smazání všech dat. Je tu také riziko bootloopu a případné ztráty záruky. Při flashování se nejprve musí do telefonu nahrát takzvaný recovery, který se pak používá pro zápis nového operačního systému a další akce.

Díky alternativní ROM můžete získat také rootovská oprávnění, tedy plnou kontrolu nad telefonem. To vám umožňuje hluboké zálohy aplikací nebo další zápis do oblastí, kam může obvykle zapisovat jen operační systém.

Pokud si telefon rootnete, odmítne se spustit většina bankovních aplikací. Pro řešení tohoto problému vznikl Magisk, který vytváří iluzi, kdy jsou systému za běhu podsouvány jiné soubory a je takto může například ukrýt před aplikacemi rootovská práva.

Nemusíme používat jen ROM vytvořenou někým jiným, ale můžeme si postavit svou vlastní. Potřebujeme ale hodně volného místa, jen stažené zdrojové kódy zaberou 150 až 200 GB, při práci se pak vytvoří zhruba stejné množství dočasných souborů. Budete potřebovat minimálně 32 GB paměti, jinak kompilátor během práce spadne.

Po zkompilování pak ROM nahrajeme do telefonu a budeme doufat, že nabootuje. Pokud ne, ve většině případů jde o takzvaný soft lock, kdy jádro naběhlo a reaguje, ale vrstva AOSP se zasekla. Stačí pak telefon restartovat do bootloaderu a zkusit to znovu. V horším případě jde o hard lock a máte pěknou cihlu.

Albert Vala, Lukáš Kavalír, Ondřej Hummel: 2025 v kyberbezpečnosti

Nejzásadnější bezpečnostní chybou loňského roku byl MongoBleed, což byla chyba v MongoDB, která v něm byla od roku 2017. Tato zranitelnost ovlivnila přes 87 000 zařízení. MongoDB do verze 3.4 neměla komprimovanou komunikaci, která byla zavedena později, společně s novým opcodem OP_MESSAGE. Součástí komprimované datové struktury je také údaj uncompressedSize o velikosti, který se ovšem nevaliduje. Útočník tak může číst další data patřící procesu MongoDB.

Další závažnou chybou byl React2Shell, což byla zranitelnost v React Server Components s hodnocením 10.0. Většina stránek se renderuje přímo v prohlížeči, což ale znamená přenášet ke klientovi spoustu dat, která se načítají postupně. React umí část této práce udělat na serveru a pro přenos na klienta používá React Flight Protocol. React ale nekontroluje reference mezi přenášenými objekty, což umožňuje vytvářet vlastní javascriptové funkce a ty na serveru spustit. Stačí poslat jeden požadavek a ovládnete celou aplikaci a pokud neběží v kontejneru, máte přístup k systému.

Ivanti je služba, která se zabývá provozem VPN, které uživatele pustí jen ke správným zdrojům. Používá to řada velkých firem, asi 80 ze stovky největších amerických společností. V jejich nástrojích se objevila chyba, kdy bylo možné do paměti uložit libovolně dlouhá data, ze kterých se ale odstraňovala číslice a tečka. My ale potřebujeme zapsat adresu do stacku, k čemuž bychom potřebovali čísla. Proto se využije technika heap spray, která zajistí, že budou data zapsaná na moha místech a je pak jedno, které z nich si pro skok vybereme. Poté je potřeba sestavit nový stack z dat, která už máme. Ve zneužití nám brání ASLR, ale ta má poměrně nízkou entropii, takže nám stačí několik stovek pokusů.

Ivanti chybu odstranila, ale nepovažovala ji za bezpečnostní problém. Mysleli si, že je tak složitá, že není v praxi zneužitelná. Čínská skupina ji ale objevila a poté ráda využívala. Když objevíte nějaký problém, dobře se ujistěte, že není zneužitelný.

GTG-1002 byl útok, který umožnil autonomně zneužít model Claude. Jak ale někdo mohl takový model zneužít? Obvykle přeci odmítne nebezpečnou akci provést. Nejprve byl model přesvědčen, že je zaměstnanec bezpečnostní firmy a provádí penetrační testy. Dále došlo k dekompozici úkolů na jednotlivé neškodné kroky. Jednotlivé úlohy na sebe nenavazují a vypadají neškodně. Agentů byla spuštěna spousta a jejich práce byla koordinována.

Claude pak na pokyn lidského uživatele začal analyzovat zvenčí svůj cíl, poté se zaměřil na kritická místa a následně se začal pohybovat po vnitřní infrastruktuře napadeného systému. To vše se získá, zdokumentuje, zabalí a pošle svému uživateli. Zajímavé je, že AI nevytvářela vlastní exploity, ale využívala už existující koncepty. Vlastně šlo jen o automatizaci celého procesu. Claude ovšem rád halucinuje, takže si sám někdy vymyslel údaje, které musel správce vždy kontrolovat.