963,Ve středu 28. října zemřel v Los Angeles sir Patrick Stewart. Kluk z Yorkshiru, který vyrůstal v domě bez koupelny, zahrál nejlidštějšího kapitána sci-fi a pro celou generaci techniků se stal velitelem, kterého by si přáli mít nad sebou. Vzpomínka na herce, jenž lodi velel hlasem, ne pěstí.

„Make it so.“ Tři slova, kterými kapitán Jean-Luc Picard posílal posádku Enterprise do práce. Patrick Stewart si je později půjčil i do názvu svých pamětí. A dnes večer, když jsem dočetla zprávu o jeho smrti, mi došlo, že ta věta patří i nám, co něco pájíme, ladíme a kompilujeme. Rozhodni se, řekni to nahlas a pak to udělej.

Stewart zemřel ve středu doma v Los Angeles, v péči své ženy Sunny. Bylo mu 86 let. Podle prohlášení rodiny prošel krátkou a těžkou cestou Alzheimerovy choroby a demence s Lewyho tělísky, informují TV Insider a ČTK.

Kluk bez koupelny

Narodil se 13. července 1940 v Mirfieldu, dělnickém městečku v západním Yorkshiru. Doma neměli záchod ani koupelnu. Otec, vyznamenaný voják, se z války vrátil s traumatem, o víkendech pil a bil matku, která pracovala v textilce. Stewart to bez obalu popsal v pamětech Making It So z roku 2023. Deníku The Guardian tehdy řekl, že pochopit otcův vliv na sebe mu trvalo 25 až 30 let terapie.

Únik našel na jevišti. U Shakespeara si jako školák umínil, že jednou bude hrát v Royal Shakespeare Company. V roce 1966 se tam dostal a zůstal čtrnáct let. Hrál Macbetha, Othella, Prospera i Shylocka, píše Guardian.

Hollywood si ho našel, až když mu bylo 47.

Kapitán, který nejdřív poslouchal

Picard nebyl Kirk. Neskákal po každém mimozemšťanovi na planetě z papírmaše. Sedl si do zasedačky, vyslechl Data, Geordiho i doktorku Crusherovou, a teprve pak rozhodl. Kdo kdy pracoval v technickém týmu, ten typ zná jen z vyprávění: šéf, který technikovi věří, ale odpovědnost za rozhodnutí si nechá u sebe.

Star Trek: Nová generace běžela sedm sezon, od roku 1987 do roku 1994, a Stewart v ní natočil 176 epizod. Přidal čtyři celovečerní filmy a v letech 2020 až 2023 tři řady seriálu Star Trek: Picard, u kterého byl i výkonným producentem.

Ze 176 epizod si každý fanoušek nese svou. Moje je The Inner Light, kde Picard během jediného dílu prožije celý cizí život a na konci mu zůstane jen flétna. A pak „There are four lights!“ z dvojdílu Chain of Command. Lepší lekci o tom, že pravda se nemění podle toho, kdo zrovna drží ovladač, televize nenatočila.

Tablet z rozpočtové nouze

Na palubě Enterprise-D se pracovalo s PADDy, tenkými dotykovými deskami, které vypadaly podezřele jako dnešní tablety. Vznikly ze šetření. Art director seriálu Michael Okuda vysvětloval pro Ars Technica, že nakreslit ovládání jako grafiku vyšlo štábu levněji než kupovat elektroniku. A když se ho někdo ptal, kde je tlačítko pro akci, se kterou nepočítal, odpověděl, že je v softwaru. To bylo v roce 1987.

Doug Drexler, který na trekových rekvizitách pracoval desítky let, o prvním iPadu prohlásil, že je to „pravý startrekový sen“, píše Time.

Mimochodem, Picard nosil PADDy po hromadách. Tvůrci tak divákům ukazovali, že má práce nad hlavu, připomíná Inverse. Dnes by stačil jeden tablet a tři nedočtené kanály na Slacku (pokrok je pokrok).

LeVar Burton, seriálový Geordi La Forge, k tomu pro Adweek řekl, že věří v jednoho konkrétního kluka: ten koukal na původní Star Trek, vyrostl, stal se inženýrem a navrhl véčkový telefon. Kolik takových kluků a holek vyrostlo u Nové generace, nikdo nespočítá. Pár jich čte tenhle web.

Hlas, který znáte, i když nevíte odkud

V roce 2000 nasedl Stewart do vozíku Profesora X a ve filmové sérii X-Men si podmanil další generaci. Proti němu stál jeho blízký přítel Ian McKellen jako Magneto. Roli si zopakoval mimo jiné v Loganovi a objeví se v ní ještě jednou, ve filmu Avengers: Doomsday, který jde do kin 18. prosince.

Hráči ho znají z The Elder Scrolls IV: Oblivion, kde jako císař umírá hned v úvodu, a z Castlevania: Lords of Shadow. Picarda namluvil v zhruba deseti trekových hrách, uvádí Game Informer. V roce 2010 ho královna Alžběta II. pasovala na rytíře za zásluhy o drama.

Rodinné prohlášení, které citoval server Variety, připomíná i to, o čem se v nekrolozích mluví méně. Stewart celý život podporoval oběti domácího násilí, uprchlíky, péči o duševní zdraví válečných veteránů a ochranu zvířat, hlavně svých adoptovaných pitbulů. Kdo zná jeho dětství, tomu první položka na seznamu nepřijde náhodná.

Jonathan Frakes, jeho první důstojník Riker, sdílel nekrolog s jedinou větou: „Rest in peace my friend.“ Marvel Studios o něm napsali, že byl jedinečný talent, velkorysý kolega a skutečný gentleman.

Picard by teď nejspíš řekl, ať se vrátíme k práci. Tak dobře, kapitáne.

S úctou a pokorou
Valentino Hesse

Make it so.

The post Sbohem, kapitáne. Patrick Stewart odešel ve věku 86 let first appeared on Hard Wired.

Třetí díl série o klonování DESFiru. V prvních dvou jsme rozebrali teorii a praxi zálohy. Teď je na stole skutečný dump pravé Mifare DESFire karty z Flipper Zero a projdeme ho řádek po řádku: co z karty vypadlo, kde se čtečka zastavila a co o zabezpečení systému prozradí i to málo, co jde přečíst bez klíče. A protože Flipper umí DESFire i víc než jen přečíst obálku, přidávám detailní rozbor a návod k aplikaci DFC. UID v ukázce je anonymizovaný, změnil jsem jeho poslední bajt.

Teoretický rozbor je jedna věc, reálný výpis z karty druhá. Vzal jsem pravou DESFire kartu, ke které mám přístup, přiložil ji na Flipper Zero a nechal ji přečíst. Výsledkem je soubor .nfc, který se vejde na jednu obrazovku a který ilustruje obě předchozí části líp než jakýkoli diagram.

Ukazuje totiž přesně to rozhraní, o kterém byla celou dobu řeč: hranici mezi tím, co z DESFiru dostaneš zadarmo, a tím, co je zamčené za kryptografií.

Rozeberme ho.

Co máme na stole

Tady je celý dump. UID jsem anonymizoval změnou posledního bajtu, jinak je přesně takový, jak ho Flipper vyčetl.

Filetype: Flipper NFC device
Version: 4
# Device type can be ISO14443-3A, ISO14443-3B, ISO14443-4A, ISO14443-4B, ISO15693-3, FeliCa, NTAG/Ultralight, Mifare Classic, Mifare Plus, Mifare DESFire, SLIX, ST25TB, NTAG4xx, Type 4 Tag, EMV
Device type: Mifare DESFire
# UID is common for all formats
UID: 04 80 C4 1A 28 25 00
# ISO14443-3A specific data
ATQA: 03 44
SAK: 20
# ISO14443-4A specific data
T0: 75
TA(1): 77
TB(1): 81
TC(1): 02
T1...Tk: 80
# Mifare DESFire specific data
PICC Version: 04 01 01 33 00 1A 05 04 01 01 03 00 1A 05 04 80 C4 1A 28 25 00 21 52 59 30 30 91 26
PICC Free Memory: 8032
PICC Change Key ID: 00
PICC Config Changeable: true
PICC Free Create Delete: true
PICC Free Directory List: true
PICC Key Changeable: true
PICC Flags: 00
PICC Max Keys: 01
PICC Key 0 Version: 00
Application Count: 1
Application IDs: A1 70 F4
Application a170f4 Change Key ID: 00
Application a170f4 Config Changeable: false
Application a170f4 Free Create Delete: false
Application a170f4 Free Directory List: false
Application a170f4 Key Changeable: false
Application a170f4 Flags: 00
Application a170f4 Max Keys: 00

Na první pohled nic dramatického. Na druhý pohled učebnice.

Co karta prozradila o sobě

Než se dostaneme k tomu, co Flipper nepřečetl, projděme to, co přečetl. Už z hlaviček se dá karta přesně zařadit.

Device type: Mifare DESFire potvrzuje, že jde o pravou DESFire, ne o magic kartu, která by se za Classic jen vydávala. UID: 04 80 C4 1A 28 25 00 je sedmibajtové a začíná bajtem 04, což je výrobní kód NXP. UID je pevné a čitelné, takže Random ID tahle karta zapnuté nemá a je sledovatelná podle svého čísla.

SAK: 20 je drobnost, na které stojí půlka prvního článku. Hodnota 0x20 znamená, že karta podporuje ISO 14443-4, tedy že jede přes RATS a ATS do přenosového protokolu T=CL, a ne jen přes antikolizi jako Mifare Classic. Řádky ATS pod tím (T0: 75, TA(1): 77 a dál) jsou právě ta odpověď na RATS, kde se dohodne rámcování a rychlost. Tohle je ta vrstva -4 černé na bílém.

Z PICC Version se dá vyčíst generace a velikost. Bajt velikosti úložiště 1A odpovídá osmi kilobajtům, což sedí na PICC Free Memory: 8032. Hlavní verze hardwaru 33 ukazuje na generaci EV3 (0x01 je EV1, 0x12 EV2, 0x33 EV3); pro stoprocentní jistotu stačí kartu hodit do NXP TagInfo, ale vychází to na EV3. Konec řetězce Version nese UID znovu a za ním výrobní dávku a datum.

Shrnuto: osmikilová DESFire EV3 od NXP, bez Random ID.

To všechno Flipper zjistil, aniž by znal jediný klíč.

Kde se Flipper zastavil

A tady přichází pointa.

Všimni si, kde výpis končí.

Application IDs: A1 70 F4
Application a170f4 Config Changeable: false
Application a170f4 Free Create Delete: false
Application a170f4 Free Directory List: false
Application a170f4 Key Changeable: false
Application a170f4 Max Keys: 00

Seznam aplikací Flipper dostal, je tam jedna s AID a170f4. Ale uvnitř té aplikace nevidíš nic. Žádné soubory, žádný obsah, žádné klíče. Max Keys: 00 neznamená, že aplikace nemá klíče, ale že se k nim Flipper nedostal. Narazil na hranici aplikace a bez autentizačního klíče neprošel.

Proč vůbec dostal ten seznam aplikací? Kvůli jednomu nastavení o pár řádků výš, PICC Free Directory List: true, které listing aplikací bez autentizace povoluje. Kdyby bylo false, neviděl by ani AID.

A přesně tohle je závěr druhého článku na živém vzorku. Stock NFC aplikace přečetla obálku, dovnitř dopisu se nepodívala. Soubor .nfc není klon a funkčním klonem se nestane. Kdybys to UID zapsal na sedmibajtovou magic kartu, projdeš jedině u systému, který věří pouhému UID a nic neověřuje. U skutečné DESFire autentizace magic karta mlčí, protože nemá čím odpovědět na výzvu.

Co z toho čte bezpečák

Teď to zajímavé, protože i ta neautentizovaná hlavička dokáže o nasazení hodně napovědět. Podívej na nastavení na úrovni celé karty.

PICC Key 0 Version:       00
PICC Config Changeable:   true
PICC Free Create Delete:  true
PICC Free Directory List: true
PICC Key Changeable:      true

Nejsilnější signál je verze master klíče. PICC Key 0 Version: 00 skoro vždy znamená, že master klíč nikdo nerotoval a sedí tam pořád výchozí hodnota, tedy samé nuly. K tomu Free Create Delete: true, což dovoluje zakládat a mazat aplikace bez autentizace master klíčem. Dohromady je úroveň PICC měkká: výchozí master klíč a volná správa aplikací. Kdo se autentizuje tím výchozím klíčem, může na kartě aplikace přidávat nebo rovnou mazat. Data v uzamčené aplikaci a170f4 sice nepřečte, na to potřebuje aplikační klíč, ale integrita a dostupnost celé karty na tom stojí vratce.

Kontrast se samotnou aplikací je přitom poučný. Aplikace a170f4 je zamčená slušně:

Application a170f4 Config Changeable:  false
Application a170f4 Free Create Delete:  false
Application a170f4 Free Directory List: false
Application a170f4 Key Changeable:      false

Config neměnný, klíče neměnné, listing i create/delete zakázané. Kdo tu aplikaci personalizoval, udělal na její úrovni hygienu správně. Jenže PICC kolem ní nechal rozvolněný. A to je přesně ten mismatch z prvního dílu: kryptografie čipu drží, slabina je v personalizaci, ne v křemíku.

DESFire tady nechybuje. Obrany, které karta nabízí, musí někdo zapnout a nastavit. Random ID je vypnuté, master klíč nerotovaný, správa aplikací volná. Žádná z těch věcí není porucha karty, všechny jsou rozhodnutím při nasazení.

Jenže Flipper umí DESFire i víc: aplikace DFC

Dump výš vylezl ze stock NFC aplikace, která se u DESFiru zastaví na obálce. To ale není poslední slovo Flipperu. V katalogu je komunitní aplikace DFC (DESFire-compatible) od autora cindersocket, fork seos_compatible od Erica Bettse, která mluví nativním DESFire command setem a jde dál. S jedním velkým ale, na které si dej pozor, než si z toho uděláš falešný obrázek.

DFC neláme. Nerecovruje klíče, nekrákuje AES, žádný nested útok jako u Classic. Klíč si musíš přinést. Buď ho máš, protože čteš svou kartu, nebo credential napíšeš ručně ze známých klíčů. Emulace jede výhradně s klíči, které do credentialu vložíš. Je to nástroj pro práci s vlastními kartami, ne bypass cizích, a na kartu bez klíče se nedostane o nic víc než stock appka. Na náš uzamčený a170f4 by si DFC bez jeho klíče taky vylámal zuby.

Co tedy DFC s klíči umí:

• Čte DESFire karty. Autentizuje se v režimech legacy DES, ISO 3DES, AES i EV2 a na straně čtečky sáhne klíčem 0 do primární aplikace a přečte její nakonfigurované soubory.
• Emuluje uloženou credential, takže se Flipper vydává za DESFire kartu. K emulaci použije jen klíče uložené přímo v té credentialu.
• Emuluje prázdný DESFire (režim Blank Card). Když do něj čtečka při zápisu něco pošle, po odchodu z emulace tě to vyzve uložit zachycená data jako credential.

Credential je textový soubor .dfc (nebo předkompilovaný binární .dfcb) a nese UID, AID, key settings, autentizační mód a klíče i soubory po slotech. To je přesně ta logická struktura z druhého dílu, jen v jiném kabátě: místo abys obsah zapsal zpět na prázdnou kartu, necháš ho emulovat Flipper.

Tím se zpřesňuje jedna věta z celé série. Psal jsem ve smyslu „Flipper DESFire nedá“. Teď přesněji: Flipper DESFire nenaláme, ale s aplikací DFC a se znalostí klíčů ho přečte i emuluje. Hranice se neposunula o kousek dál k prolomení, posunula se jen o to, co dovede handheld, když klíče už máš v ruce. Jedno upozornění k aktuálnosti: DFC staví na EV1 a EV2 příkazech, pokrytí EV2 a EV3 hardwaru se teprve ověřuje na fyzických čtečkách a radiová kompatibilita není zaručená. Není to oficiální nástroj NXP a autor sám nedává záruku funkčnosti.

DFC krok za krokem

Takhle s tím zacházíš, když chceš číst nebo emulovat vlastní kartu.

Instalace. Nejjednodušší je nainstalovat DFC přímo z katalogu přes Flipper Lab (lab.flipper.net/apps/dfc). Kdo chce stavět ze zdrojáku, naklonuje repozitář, dotáhne submoduly a sestaví přes ufbt:

git submodule sync --recursive
git submodule update --init --recursive
ufbt

Čtení vlastní karty. Přilož kartu na Flipper a nech DFC přečíst primární aplikaci. Aplikace se autentizuje klíčem 0 a stáhne nakonfigurované soubory. Přečtená karta se uloží jako credential i se svým AID, key settings, autentizačním módem a klíči a soubory po slotech. Soubory credentialů patří na kartu do SD Card/apps_data/dfc/.

Emulace. Vyber uloženou credential a Flipper se začne vydávat za tu kartu. K autentizaci vůči čtečce použije jen klíče, které credential obsahuje; žádné jiné nemá odkud vzít. Tohle je ten „funkční klon“, který na magic kartě z principu nejde, ale na emulátoru se správnými klíči ano.

Blank Card. Když chceš vidět, co ti do karty zapíše cizí čtečka, zvol Blank Card. Flipper bude emulovat zapisovatelný prázdný DESFire (ve výchozím stavu s nulovým DES klíčem na úrovni PICC, AID 00 00 00). Pokud čtečka během emulace zapíše data, po odchodu z emulačního okna tě to vyzve uložit je jako .dfc.

Formát a limity credentialu. Textový .dfc se při načtení zkompiluje do binárního tvaru, případně rovnou podáš .dfcb. UID musí mít 7 bajtů a začínat 04. Jedna credential pojme nejvýš 4 aplikace, 16 souborů, 3 KiB dat celkem, 2 KiB v jednom souboru a 512 bajtů na klíče; samotný soubor .dfc nebo .dfcb nesmí přesáhnout 16 KiB. U velkých textových credentialů hrozí, že kompilace na zařízení vyčerpá heap, takže je zkompiluj radši na počítači:

python3 tests/compile_dfcb.py path/to/card.dfc path/to/card.dfcb

Ověření na hostu. Repozitář má k tomu dva testovací skripty. probe_dfcb.py pustí .dfcb proti virtuální kartě jádra přímo na počítači, nahlásí nepodporované credentials a vypíše APDU odpovědi; netestuje UI, NFC listener ani radiové časování, jen logiku. Výchozí APDU přečtou verzi a seznam aplikací, další hex APDU můžeš doplnit a proběhnou v pořadí v jedné relaci:

python3 tests/probe_dfcb.py path/to/card.dfcb
python3 tests/probe_dfcb.py path/to/card.dfcb 9060000000 90AF000000

Druhý skript, probe_pcsc_mac_read.py, je manuální hardwarová zkouška na macOS s PC/SC čtečkou a vyžaduje pythoní knihovnu cryptography. Nejdřív na Flipperu rozjeď emulaci credentialu, pak probe vybere aplikaci 0, autentizuje se ISO 2K3DES klíčem 1, přečte celý soubor 0 a ověří data i MAC v odpovědi. Aplikaci, soubor, klíč a čtečku přepíšeš přepínači --application, --file, --key a --reader:

python3 tests/probe_pcsc_mac_read.py path/to/card.dfc

Ber to jako experimentální nástroj. U EV2 a EV3 karet si funkčnost ověř na své konkrétní čtečce, protože hardwarové pokrytí se teprve dolaďuje.

Co si z toho vzít

Tenhle jeden výpis uzavírá celou sérii, protože v něm je vidět obojí najednou. Pevná část i měkká část DESFiru v jednom souboru.

Pevná část: stock NFC aplikace se k ničemu zabezpečenému nedostala a bez klíčů by aplikaci a170f4 neotevřel ani DFC. AES a tříprůchodová autentizace odvedly svoje, zamčená aplikace zůstala zamčená, naklonovat obsah na magic kartu nejde. Pokud systém kontroluje víc než UID, tahle karta je proti nástrojům bez klíčů tichá.

Měkká část: i tak výpis prozradil, že nasazení není dotažené. Verze master klíče 00 a volné create/delete jsou věci, které si v auditu přístupového systému přečteš jako první, a ani k tomu nepotřebuješ klíče. Útočník je čte stejně snadno jako ty.

A DFC do toho vnáší třetí rovinu. Se svými klíči Flipper DESFire přečte i emuluje, takže patří do výbavy na práci s vlastními kartami vedle Proxmarku a hostových knihoven z druhého dílu. Co nedokáže ani on, je dostat se do karty bez klíče. Přesně v tom je celá pointa série.

Flipper tu kartu nenaklonoval a bez klíčů ji nenaklonuje ani s DFC. Ale přečetl dost na to, aby ukázal, kde by se v nasazení dalo zatlačit, a s DFC zase dost na to, aby se tvoje vlastní karty daly emulovat. Kde končí jedno a začíná druhé, rozhoduje jediná věc: jestli ten klíč máš.

The post Rozbor reálného DESFire dumpu: co Flipper vyčte a co ne first appeared on Hard Wired.

Navazující díl k rozboru klonování DESFiru. V minulém článku padlo, že funkční kopii dostaneš jedině na prázdnou DESFire kartu, kterou si znovu napersonalizuješ. Tady je přesně ten postup: logický dump přes Proxmark3 a python-desfire, bezpečné odložení klíčů a obnova struktury i dat na čistý čip. Včetně toho, co tahle záloha není a kdy ti nepomůže.

Rovnou na úvod: je to runbook na zálohu a obnovu karty, ke které máš klíče, protože je tvoje. Žádné klonování cizích karet. Počítej s hodinou práce u první karty, pak už to jde rychleji. Co budeš na konci umět: přečíst celou strukturu DESFiru, uložit ji i s daty do souboru, založit ji znovu na prázdném čipu a nastavit zpět klíče.

Než se do toho pustíš, přečti si sekci o hranicích. Ušetří ti to zklamání, že „záloha“ nefunguje tam, kde fungovat ani nemůže.

Co budeš potřebovat

Hardware: čtečku, která umí ISO 14443-4 a autentizaci k DESFiru, a dvě karty. Zdrojovou DESFire kartu se svými klíči a prázdnou (blank) DESFire kartu stejné nebo vyšší generace a aspoň stejné paměti. Blank znamená kartu ve výrobním stavu, kde jsou všechny klíče na samých nulách; prodávají se jako „DESFire EV1/EV2/EV3 blank“.

Software podle toho, co preferuješ. Buď Proxmark3 s firmwarem Iceman (fork RfidResearchGroup), kde je celá rodina příkazů hf mfdes. Nebo PC/SC čtečku (ACR122U, ACR1252U, Omnikey) a Python s knihovnou python-desfire. Obojí umí jak čtení, tak personalizaci, takže si vyber podle toho, co máš po ruce.

A hlavně klíče. Bez klíčů s právem číst se k obsahu nedostaneš a žádný z dále popsaných kroků nemá smysl. To je vlastnost, ne chyba.

Hranice, které musíš znát předem

Záloha DESFiru má tři tvrdá omezení a je lepší je vědět teď než po hodině práce.

UID se nepřenese. Pravá DESFire karta má sedmibajtové UID zapečené z výroby a nejde přepsat. Prázdná karta má svoje vlastní. Obnovená karta tedy ponese jiné UID než originál, a to nezměníš. Magic DESFire s přepisovatelnou identitou neexistuje, jak padlo v minulém díle.

Systém s diverzifikací klíčů ti obnovenou kartu nevezme. Pokud přístupový systém odvozuje klíče z UID (diverzifikace podle AN10922), čtečka si pro nové UID spočítá jiný klíč, než jaký má tvoje obnovená karta. Autentizace selže. Obejít to jde jedině tak, že vlastníš site klíč celého systému a dopočítáš diverzifikované klíče pro nové UID, což dává smysl jen u systému, který sám provozuješ. Pro cizí přístupový systém tohle není cesta.

Přečteš jen to, na co máš právo. Každý soubor má přístupová práva navázaná na konkrétní klíče. Když tvůj klíč smí číst jen některé soubory, zbytek zůstane skrytý, i když kartu „otevřeš“.

Z toho plyne, k čemu záloha reálně slouží: k archivaci obsahu tvé vlastní karty, k migraci nebo havarijní obnově v systému, který si personalizuješ sám, a k laboratorní práci. Ber ji jako zálohu dat a struktury, ne jako výrobu náhradní přístupové karty do cizí budovy.

Jedna věc k bezpečnosti ještě předtím, než začneš sypat příkazy. Klíče drž mimo dump. Data a struktura můžou do obyčejného souboru, klíče patří do šifrovaného trezoru. Dump s klíči v plaintextu je ta nejhorší možná poznámka pod čarou.

Krok 1: Inventura karty

Napřed si kartu zmapuj, ať víš, co vůbec zálohuješ. Přilož zdrojovou kartu na Proxmark a projdi ji shora dolů.

hf mfdes info
hf mfdes getuid

info vypíše generaci, velikost paměti a volné místo, getuid skutečné UID (u karty se zapnutým Random ID ho vydá až po autentizaci, takže případně přidej secure channel a klíč). Dál si nech vypsat aplikace a soubory:

hf mfdes lsapp --files
hf mfdes lsfiles --aid 123456 -t aes

lsapp --files ukáže všechny aplikace podle jejich tříbajtového AID i s jejich soubory. Pokud jsou klíče nestandardní, autentizuj se jimi; --no-auth zkusí listing bez autentizace, pokud to karta v nastavení dovolí. U každého souboru si zjisti jeho nastavení, protože bez něj kartu věrně neobnovíš:

hf mfdes getfilesettings --aid 123456 --fid 01

Zapiš si typ souboru (Standard, Backup, Value, Linear Record, Cyclic Record), komunikační režim (Plain, MACed, plně šifrovaný), přístupová práva a velikost. Tohle je kostra, kterou budeš na prázdné kartě stavět znovu. U Value souboru si navíc poznamenej dolní a horní limit a aktuální hodnotu, u záznamových souborů počet a velikost záznamů.

Když klíče neznáš celé a chceš je dohledat ze slovníku, pomůže detekce, ale u vlastní karty bys klíče měl mít:

hf mfdes detect --save --dict mfdes_default_keys

Krok 2: Logický dump

Teď vyčteš obsah. Nejjednodušší je dump po aplikaci:

hf mfdes dump --aid 123456

dump projde soubory v aplikaci a vypíše jejich obsah. Pro jednotlivý soubor nebo pro přesnou kontrolu použij read s typem souboru:

hf mfdes read --aid 123456 --fid 01
hf mfdes read --aid 123456 --fid 02 --type record
hf mfdes read --aid 123456 --fid 03 --type value

read bez typu se pokusí typ odhadnout, u záznamových a hodnotových souborů ale radši typ uveď. Výstup si ulož do strukturovaného souboru, ideálně JSON, kde každý soubor nese svoje AID, FID, typ, komunikační režim, práva, velikost a surová data v hexu. Klíče do tohohle souboru nepatří, ty jdou zvlášť.

Takhle vznikne tvoje záloha: popis struktury plus obsah. Co s ní uděláš dál, je obnova na prázdný čip.

Krok 3: Příprava prázdné karty

Prázdnou kartu uveď do známého stavu. Pokud v ní něco je, naformátuj ji, a pamatuj, že k formátu potřebuješ PICC master klíč (u čisté karty samé nuly):

hf mfdes auth -n 0 -t aes -k 00000000000000000000000000000000
hf mfdes formatpicc

Po formátu máš čistý PICC s jednou prázdnou kořenovou aplikací a výchozími klíči. Na téhle základně postavíš kopii struktury.

Krok 4: Obnova struktury a dat

Teď znovu založíš aplikace a soubory podle toho, cos zapsal v kroku 1, a naliješ do nich data z kroku 2. Konkrétní vlajky příkazů createapp a createfile se mezi verzemi firmwaru liší, takže si u své verze vždy ověř přesný tvar přes hf mfdes createapp -h a hf mfdes createfile -h. Orientačně to vypadá takhle:

hf mfdes createapp --aid 123456 --dfname hesse --ks1 0B --ks2 AE
hf mfdes createfile --aid 123456 --fid 01 --amode encrypt --size 000020

--ks1 a --ks2 kódují nastavení klíčů aplikace, tedy počet klíčů, jejich typ a oprávnění; --amode je komunikační režim souboru, --size velikost v bajtech. Hodnoty musí sedět na to, cos vyčetl z originálu, jinak nedostaneš věrnou kopii. Value a záznamové soubory se zakládají vlastními příkazy s limity a počtem záznamů.

Když struktura stojí, zapiš data:

hf mfdes write --aid 123456 --fid 01 -d 0102030405060708...
hf mfdes write --aid 123456 --fid 02 --type record -d 0102030405 --updaterec 0
hf mfdes write --aid 123456 --fid 01 --type data -d 01020304 --commit

U Backup souborů nezapomeň na --commit, bez něj zůstane zápis jen v dočasném bufferu a po odpojení karty se ztratí. U Value souborů se hodnota nenastavuje přímo, ale přes počáteční hodnotu při založení, případně přes credit a debit.

Krok 5: Nastavení klíčů

Tohle je nejchoulostivější krok celé obnovy, protože tady si můžeš kartu zamknout. Dokud jsi pracoval s výchozími nulovými klíči, šlo všechno hladce. Teď je vyměníš za ty původní.

hf mfdes changekey --aid 123456 -n 1 -t aes -k 00000000000000000000000000000000 --newkey 00112233445566778899AABBCCDDEEFF --newver 01

Drž se tří pravidel. Klíče měň odspodu, aplikační klíče před aplikačním master klíčem, a aplikační master klíč před PICC master klíčem; jakmile změníš klíč, kterým ses autentizoval, musíš se autentizovat znovu tím novým. Verzi klíče (--newver) nastav na stejnou hodnotu jako na originálu, jinak ti pozdější autentizace nemusí projít. A než přepíšeš poslední master klíč, dvakrát si ověř, že ho máš zapsaný správně, protože špatně zadaný master klíč znamená kartu, do které se už nedostaneš.

Jemnější nuance: změna klíče číslo 0 (master klíč aplikace) používá jiné krypto než změna ostatních klíčů a může zároveň měnit nastavení aplikace. Proto ji nech až úplně nakonec a odděleně.

Celý cyklus v Pythonu

Kdo nechce ťukat do Proxmarku ručně, zvládne totéž skriptem přes python-desfire na PC/SC čtečce. Knihovna umí čtení i personalizaci, takže pokryje obě fáze. Čtecí část vypadá v jádru takhle:

from desfire import DESFire, PCSCDevice
from smartcard.System import readers

conn = readers()[0].createConnection()
conn.connect()
card = DESFire(PCSCDevice(conn.component))

card.authenticate(0x000000, picc_master_key)   # PICC master
dump = {"uid": card.get_real_uid(), "apps": []}

for aid in card.get_application_ids():
    card.select_application(aid)
    card.authenticate(aid, app_keys[aid])
    app = {"aid": aid, "files": []}
    for fid in card.get_file_ids():
        settings = card.get_file_settings(fid)
        data = card.read_file_data(fid)
        app["files"].append({"fid": fid, "settings": settings, "data": data})
    dump["apps"].append(app)
# dump ulož do JSON; klíče (app_keys) drž mimo tenhle soubor

Obnova na prázdnou kartu je zrcadlový postup. Autentizuješ se výchozím nulovým klíčem, založíš aplikaci, přepneš se do ní, vytvoříš soubory podle uložených nastavení, zapíšeš data a nakonec vyměníš klíče:

blank.authenticate(0x000000, default_key)
blank.create_application(aid, key_settings, num_keys, DESFireKeyType.DF_KEY_AES)
blank.select_application(aid)
blank.authenticate(aid, default_app_key)
blank.create_standard_file(fid, comm_mode, access_rights, file_size)
blank.write_file_data(fid, 0, comm_mode, data)
blank.change_key(key_no, new_key, old_key, key_version)

Přesné signatury metod se mezi verzemi knihovny trochu liší, takže si je ověř v její dokumentaci; logika kroků ale zůstává stejná jako u Proxmarku. Knihovna staví na EV1, pro specifické funkce EV2 a EV3 počítej s tím, že je nemusí pokrývat.

Když něco nefunguje

Nejčastější zádrhel je selhání autentizace. Zkontroluj tři věci: správný typ klíče (-t des, 2tdea, 3tdea nebo aes), správné číslo klíče (-n) a správný secure channel (-s d40, ev1, ev2). Když nesedí byť jen jedno, karta tě odmítne, i když máš klíč správně.

Když čtení projde, ale vrátí nesmysl, nejspíš čteš ve špatném komunikačním režimu. Plně šifrovaný soubor čtený jako Plain vrátí šifrovaný balast, ne data. Ověř si režim z nastavení souboru.

Když se obnovená karta tváří hotově, ale originální systém ji nevezme, vrať se k sekci o hranicích. Buď systém diverzifikuje klíče podle UID, které se změnilo, nebo kontroluje jen UID a tvoje nové mu nesedí. Ani jedno nespravíš na straně karty.

A nejbolestivější případ: autentizace k aplikaci najednou nejde ani tobě. Nejspíš sedí špatná verze klíče nebo ses při změně master klíče přepsal. U vlastní testovací karty z toho ven vede jen formát přes PICC master klíč, pokud ho ještě znáš. Pokud ne, karta je pro tebe ztracená. Proto se master klíče mění jako poslední a s rozmyslem.

Co sis vlastně zazálohoval

Na konci máš dvě věci. Soubor s popisem struktury a daty, který přežije kartu, a schopnost tu kartu znovu postavit na čistém čipu. Co nemáš, je identický klon s původním UID, protože ten na pravém DESFiru neexistuje.

A přesně v tom je ta záloha užitečná i poctivá zároveň. Archivuje obsah, umožní migraci ve tvém vlastním systému a zachrání tě, když fyzická karta doslouží. Jen si pamatuj, čím tenhle postup je a čím není, a nebudeš čekat zázrak tam, kde ho DESFire z principu neslíbil.

The post Jak si zálohovat DESFire kartu a obnovit ji na prázdnou first appeared on Hard Wired.

Proč DESFire nenaklonuješ, i když Mifare Classic jde

Magic karty s přepisovatelným UID udělají kopii obyčejné Mifare Classic za pár minut. DESFire stejný trik nedonese, a není to kvůli tajnému klíči, ale kvůli tomu, jak je karta postavená. Podrobný rozbor: jak DESFire funguje, jak ověřuje, čím se brání útokům a proč celé zabezpečení nakonec stojí a padá se systémem kolem něj.

Máš svůj vlastní klíč k DESFire kartě, chceš si ji zálohovat, a po ruce zrovna není prázdný DESFire. Jenom magic karta. Zní to jako banalita.

Přitom se právě na tomhle scénáři nejlíp ukáže, proč jde jedna karta zkopírovat za pár minut a druhá vůbec. Obkreslit UID je málo. Klon musí zreplikovat celé chování karty vůči čtečce, kryptografii nevyjímaje. Projdeme to od začátku: proč je Mifare Classic odsouzená ke klonování, jak je naproti tomu postavený DESFire, jak probíhá jeho ověřování krok za krokem, čím se brání útokům, kde ho jednou v historii zlomili a proč dnešní průšvihy nemají s čipem nic společného.

Magic karta a otevřený blok 0

U běžné Mifare Classic je blok 0 uzamčený z výroby. Sedí v něm UID, jednobajtový kontrolní součet BCC a výrobní data, a normální čtečka ho nepřepíše. Magic karty tenhle zámek obcházejí. Způsob obcházení dělí jednotlivé generace a není to jen akademické dělení, protože rozhoduje o tom, jestli tě klon prozradí.

Nejstarší „UID karty“ (Gen1a) poslouchají nestandardní backdoor příkazy. Karta se uspí a pak reaguje na dvojici příkazů (0x40 v sedmibitovém rámci jako buzení, následně 0x43), které odemknou čtení i zápis libovolného bloku včetně nultého, a to bez znalosti jakéhokoli klíče. Na Proxmarku to obsluhují příkazy csetblk, cgetblk a spol. Háček je v tom, že ta samá ochota reagovat na backdoor kartu odhalí: čtečka pošle odemykací sekvenci, karta odpoví, a je jasno.

Gen2 (CUID) backdoor nemá. UID se u ní mění přímým zápisem do bloku 0 jako do kteréhokoli jiného, přes standardní wrbl s vynuceným zápisem. Pozor na BCC: když ho spočítáš špatně, část čteček kartu odmítne nebo rovnou zablokuje. CUID má proti Gen1a výhodu, že na backdoor nereaguje, takže ji sken backdoorem neodhalí. Zrádný je ovšem přístup, kdy se čtečka sama pokusí přepsat blok 0, protože běžná Classic to nedovolí a CUID ano, čímž se prozradí. Na to je FUID, který se po prvním zápisu zamkne natvrdo a od té chvíle je k nerozeznání od pravé Classic. UFUID je mezistupeň: chová se jako CUID, dokud mu nepošleš zamykací sekvenci, a teprve pak ztuhne.

Špičkou je dnes Gen4, prodávaný jako „Ultimate Magic Card“. Funguje jako konfigurovatelná platforma, ne jako jedna pevná emulace. Umí se vydávat za libovolnou Classic (1K, 4K, Mini), za Ultralight i za NTAG, se čtyř-, sedmi- i desetibajtovým UID, a svou konfiguraci chrání heslem. Má takzvaný shadow mode, kdy se po přiložení jednou ukáže jako klon a pak jako zapsaná data, čímž umí obejít i otravnější anti-copy kontroly.

Všechny tyhle karty mají společné jedno. Emulují Mifare Classic, Ultralight nebo NTAG, tedy typy postavené na prolomené šifře Crypto1 nebo rovnou bez autentizace. A Classic je rozbitá na několika úrovních zároveň. Crypto1 padla akademicky už kolem roku 2008 (Nohl, Garcia a další), útoky Darkside, Nested a HardNested vytáhnou klíče z běžné karty v řádu sekund až minut. Loni to dostalo ještě jeden rozměr: Philippe Teuwen z Quarkslabu v srpnu 2024 popsal hardwarový backdoor ve Fudan FM11RF08S, tedy v „tvrzené“ variantě s šifrovaným statickým nonce, která měla nested útokům odolávat. Backdoor umožňuje autentizovat se neznámým klíčem společným všem těm kartám a vyčíst z karty během pár minut všechny klíče i bez jediného známého klíče. Nástroje skončily v Proxmarku. Jinými slovy: žádná karta z rodiny Classic není bezpečný nosič identity, ať je magic nebo ne.

DESFire mezi nimi nenajdeš.

A to je jádro věci.

Jak DESFire funguje

DESFire a Classic spojuje leda ta frekvence 13,56 MHz. Jinak to jsou dva odlišné světy, a začíná to už u komunikační vrstvy. Norma ISO/IEC 14443 má čtyři části: fyziku karty, rádiové rozhraní, inicializaci s antikolizí (část -3, kde se řeší ATQA, SAK a výběr UID) a konečně přenosový protokol (část -4). Mifare Classic končí u části -3 a dál jede proprietární Crypto1, žádný standardní protokol nad tím není. Právě proto „čtení“ Classic znamená jen antikolizi plus Crypto1 a právě proto ji magic karta tak snadno napodobí.

DESFire jede až po vrstvu -4. Po antikolizi pošle čtečka příkaz RATS, karta odpoví svým ATS a tím se dohodne half-duplexní protokol T=CL s datovými rychlostmi od 106 až po 848 kbit/s. Nad ním se posílají APDU podle ISO/IEC 7816-4, stejné stavební kameny jako u kontaktních čipových karet a pasů. Nativní příkazy DESFiru se dají balit do ISO 7816 APDU (wrapped mode, s hlavičkou 0x90), takže s kartou umí mluvit i obyčejná PC/SC čtečka přes standardní rozhraní.

Paměť je hierarchická, jako malý šifrovaný souborový systém. Na nejvyšší úrovni je PICC, tedy celá karta, s master klíčem a globální konfigurací. Pod ním sedí aplikace, každá se svým tříbajtovým identifikátorem AID a vlastní sadou až čtrnácti klíčů. V každé aplikaci je až 32 souborů, a souborů je šest druhů: Standard Data pro statická data, Backup Data s transakční ochranou, Value pro čítače a peněženky, Linear Record a Cyclic Record pro záznamové logy a konečně Transaction MAC, který přibyl v EV3 a podepisuje transakce. Každý soubor má vlastní přístupová práva navázaná na konkrétní klíče, takže čtení může vyžadovat jiný klíč než zápis.

Klíče jsou AES-128, nebo starší DES, 2K3DES a 3K3DES, vždy s verzí klíče. Generace jdou za sebou a drží zpětnou kompatibilitu. D40 je původní z roku 2002, dnes dožilá. EV1 přišel v roce 2008 s certifikací Common Criteria EAL4+ a pamětí 2, 4 nebo 8 kB. EV2 z roku 2016 zvedl laťku na EAL5+, zrušil limit počtu aplikací, přidal rolling keys a sadu obranných mechanismů, ke kterým se dostaneme. EV3 z roku 2020 drží EAL5+, přidává Secure Dynamic Messaging i konfigurovatelné ATS a nabízí paměť až 32 kB. V defaultním stavu se EV3 chová jako EV2 nebo EV1, nové funkce se aktivují až při personalizaci, takže integrátor musí vědomě zapnout, co chce používat.

Jak DESFire ověřuje

Tohle je srdce celé věci, a proto se u toho zastavíme podrobně. DESFire používá tříprůchodovou vzájemnou autentizaci (three-pass mutual authentication). Jde o to, že si karta i čtečka navzájem dokážou znalost sdíleného klíče, aniž by klíč nebo jeho prostá podoba kdy proletěly éterem. Zjednodušeně to běží takhle:

1. Čtečka řekne, kterým klíčem se chce autentizovat. Karta vygeneruje náhodné číslo RndB, zašifruje ho klíčem a pošle zpět. Útočník odposlechem dostane jen šifrovaný balast.
2. Čtečka balast dešifruje, získá RndB, vygeneruje vlastní náhodné RndA, číslo RndB cyklicky posune o bajt (RndB') a dvojici RndA a RndB' zašifruje zpět kartě. Posunutím dokazuje, že RndB rozluštila, tedy že klíč zná.
3. Karta dešifruje, zkontroluje, že její RndB' sedí, čímž má ověřenou čtečku. Pak posune RndA, zašifruje a pošle zpět. Čtečka ověří, že sedí její RndA, a tím má ověřenou kartu.

Z úlomků obou náhodných čísel se nakonec na obou stranách odvodí stejný dočasný session klíč, kterým se šifruje zbytek relace. Odposlech celé výměny útočníkovi nedá nic použitelného, protože náhodná čísla jsou pokaždé jiná a klíč sám se nikdy neposílá.

Varianty se liší kryptem a detaily. Legacy autentizace běží na DES a 3DES, ISO varianta přidává delší náhodná čísla, AES autentizace jede na AES-128. EV2 to posunul k příkazu AuthenticateEV2First: při navázání relace se dohodne transakční identifikátor (TI) a čítač příkazů (CmdCtr), vzniknou oddělené session klíče pro šifrování a pro MAC a každý další příkaz nese narůstající čítač. Tím padá možnost přehrát odposlechnutou výměnu i proskládat cizí příkazy do běžící relace.

Nad samotnou autentizací stojí tři komunikační režimy souborů. V režimu Plain jdou data nechráněně. V režimu MACed se ke každé zprávě připojí CMAC, který hlídá integritu a původ. V plně šifrovaném režimu je obsah zašifrovaný a navíc podepsaný CMAC. Který režim platí, se nastavuje u každého souboru zvlášť, takže veřejný údaj může jet Plain a citlivý plně šifrovaně na stejné kartě.

A právě tady je pointa k tvé záloze. Magic karta nemá kryptoengine. Nemá čím RndB vygenerovat, zašifrovat ani posunout. Ve chvíli, kdy čtečka zahájí tříprůchodovou výměnu, karta mlčí, a tvůj legitimní klíč na tom nic nezmění, protože klíč je klíč k DESFiru, ne něco, čím rozchodíš cizí křemík. Zazálohovat umíš data a strukturu (logický dump po autentizaci), ale funkční kopii dostaneš jedině na prázdnou DESFire kartu, kterou si znovu napersonalizuješ.

Čím se DESFire brání útokům

Samotná šifra je jen začátek. DESFire od EV1 výš nese vrstvu obran, které cílí přesně na způsoby, jakými se contactless karty reálně napadají.

Proti postranním útokům stojí hardwarové protiopatření certifikované na úrovni EAL4+ u EV1 a EAL5+ u EV2 a EV3. Common Criteria na téhle úrovni znamená, že se čip musel ubránit i neinvazivnímu měření spotřeby a vyzařování, tedy přesně tomu, co zabilo původní D40. EV2 a EV3 k tomu přidávají LRP (Leakage Resilient Primitive), alternativní režim AES navržený tak, aby z každé operace unikalo do spotřeby co nejméně informace. Útok měřením stop je proti LRP mnohem dražší.

Soukromí řeší Random ID spolu s architekturou virtuální karty (VCA). Se zapnutým Random ID hlásí karta při každém přiložení jiné náhodné číslo místo pevného UID, takže ji nelze sledovat napříč čtečkami. Skutečné UID vydá teprve po úspěšné autentizaci. VCA pak umožňuje, aby se správná aplikace vybrala a identifikovala, aniž by se to zvenčí dalo zneužít ke sledování nositele.

Proti relay útokům, kdy útočník natáhne komunikaci mezi vzdálenou kartou a čtečkou přes dvojici zařízení, stojí Proximity Check. Čtečka pošle kartě sérii výzev a měří, za jak dlouho přijde odpověď. Když je zpoždění větší, než dovoluje rychlost světla na krátkou vzdálenost, relay se prozradí a kontrola selže. Má to jeden háček, ke kterému se vrátím: funguje jen tehdy, když ho někdo v systému zapne.

Transaction MAC dává kartě schopnost podepsat každou transakci kryptografickým otiskem, takže se zpětně pozná neoprávněný zápis, třeba dobití peněženky mimo oficiální terminál. Rolling keys, tedy až šestnáct sad klíčů na aplikaci s rychlým přepínáním, zase dovolují vyměnit klíče v celém systému bez výměny karet. Když se jedna sada zkompromituje, přepne se na další, aniž by lidé museli odevzdat kartičky.

Žádná z těch obran ale neběží sama od sebe. To je přesně ten důvod, proč DESFire padá častěji na nasazení než na matematiku.

Jediné reálné prolomení za dvacet let

DESFire padl v historii jednou, a ne přes šifru. Původní MF3ICD40 byl uvnitř asynchronní osmibitový procesor řady 8051 s 3DES jádrem a takzvanou glue logikou, uvedený Philipsem kolem roku 2002, tedy v době, kdy se postranní útoky na čipy ještě nebraly jako běžná hrozba. V říjnu 2011 předvedli David Oswald a Christof Paar z Porúrské univerzity v Bochumi na konferenci CHES, co to znamená. Nešli po matematice 3DES, šli po fyzice čipu: měřili spotřebu a elektromagnetické vyzařování během šifrování (differential power analysis a šablonové útoky). Z řádově 250 tisíc naměřených stop zrekonstruovali tajný klíč, celé asi za sedm hodin, s vybavením za pár tisíc eur.

NXP útok uznal a připomněl, že MF3ICD40 stejně plánoval ukončit ke konci roku 2011. EV1, uvedený už o tři roky dřív, byl proti stejnému postrannímu útoku odolný, a právě proto ta certifikace EAL. Od té doby se žádné veřejné prolomení kryptografie EV1, EV2 ani EV3 neobjevilo. Těžiště se nepřesunulo na kartu.

Přesunulo se na systém kolem ní.

Co musí umět čtečka

Častý omyl zní: „přečetl jsem kartu“ u DESFiru neznamená skoro nic. Vyčíst náhodné UID zvládne každá čtečka podle ISO 14443-3. Dostat se k zabezpečenému obsahu je úplně jiná operace a čtečka k ní potřebuje tři věci.

Zaprvé protokol. Musí umět ISO/IEC 14443-4, tedy projít přes RATS a ATS do režimu T=CL, a posílat APDU, ne jen řešit antikolizi. Zadruhé kryptografii. Buď má bezpečnostní modul SAM, kde leží klíče v hardwaru a který provede autentizaci za čtečku, nebo kryptografii dělá host či backend softwarově a klíče jsou uložené v key store řadiče. NXP k tomu dodává moduly MIFARE SAM AV2 a AV3; AV3 pojme až 128 položek pro symetrické klíče, umí offline diverzifikaci klíčů, chráněný kanál mezi hostem a SAM a v takzvaném X-módu i výkonovou spolupráci s čtecím čipem. Zatřetí samotné klíče, bez nich čtečka k šifrovaným souborům prostě nepustí.

V praxi to vypadá takhle. PC/SC čtečky jako ACR122U, postavená na čipu PN532, zvládají APDU passthrough a autentizaci k DESFiru jde dělat softwarově, například přes knihovny python-desfire, libfreefare, TapLinx nebo projekty AndroidCrypto. Novější ACR1252U a ACR1255U nebo čtečky Omnikey míří na DESFire EV1 a EV2 přímo. Proxmark3 má celou rodinu příkazů hf mfdes. V přístupových systémech se klíče často drží v řadiči a čtečka běží v transparentním režimu, typicky přes OSDP. Co nikde nekoupíš, je magic DESFire. Prázdnou kartu k personalizaci ano, ale „otevřenou“ DESFire s přepisovatelnou identitou ne.

A ještě jedna věc, protože se na ní láme většina reálného zabezpečení. Pokud přístupový systém DESFire kartu jen přečte podle UID a dál se spokojí, že se karta ozvala, celá kryptografie je k ničemu. Takový systém pak podvede i obyčejná sedmibajtová magic karta se stejným UID. DESFire reader a UID čtečka jsou dvě různé věci, i když se navenek tváří stejně.

Kde DESFire přesto padá

Neprůstřelná karta ještě není neprůstřelný systém. Většina reálných průšvihů s DESFirem se šifrou vůbec nesouvisí.

Nejčastější je výchozí klíč. Čerstvá DESFire aplikace má všechny klíče nastavené na samé nuly. Když je integrátor nezmění, útočník se autentizuje výchozím klíčem a má vystaráno, přečte i přepíše obsah. Druhá klasika je chybějící diverzifikace klíčů. NXP v aplikační nótě AN10922 popisuje, jak z jednoho site klíče odvodit jedinečný klíč pro každou kartu, pomocí AES-CMAC nad UID, AID a číslem klíče. Když to systém neudělá a sype do všech karet stejný klíč, stačí vytáhnout klíč z jediné karty nebo z jediné čtečky a padne celá instalace naráz. A přesně tím směrem dnešní útoky jdou, po extrakci klíčů ze čtečky nebo po kompromitaci site klíče, ne po prolomení čipu.

Nad tím vším visí lidský faktor nasazení. Proximity Check proti relay útokům je skvělá obrana, pokud ji někdo zapne. Random ID chrání soukromí, pokud se aktivuje. Rolling keys umožní rotaci, pokud má systém proceduru, jak ji provést. NXP to sepsal do systémové nóty AN10969, kde kromě diverzifikace doporučuje i detekci podvodných karet, černé a bílé listiny a stínové účty, tedy obranu, která nestojí na kartě, ale na backendu. Školní příklad z praxe: londýnská Oyster přešla na DESFire, zatímco řada jiných dopravních karet zůstala na prolomené Classic, a rozdíl v bezpečnosti nedělá jen čip, ale celý návrh systému.

Bezpečnost DESFire nebydlí v kartě. Bydlí v tom, jak je nasazená.

A proto ti magic karta zálohu neudělá, ne proto, že by byl klíč tak tajný, ale proto, že na magic kartě není co s tím klíčem provést.

The post Proč DESFire nenaklonuješ, i když Mifare Classic jde first appeared on Hard Wired.

V 1:31 moskevského času, v noci na 8. října, se na stavové stránce Yandex Cloudu objevila nenápadná zpráva. V zóně dostupnosti ru-central1-b vypadlo napájení a zákazníci mají podle možností přesunout zátěž do jiných zón, informoval server Lenta.ru. Rjazaňský gubernátor Pavel Malkov o pár hodin později mluvil jen o tom, že v Sasovském okrese chytla střecha „jednoho z podniků", píše Kommersant.

Tím podnikem bylo datacentrum Yandexu. A „jiné zóny" vydržely přesně tři dny.

Do 11. října zasáhly ukrajinské drony tři z velkých datacenter firmy: Sasovo v noci ze 7. na 8. října, Kalugu ráno 9. října a Vladimir v noci na 11. října. Yandex Cloud pak zákazníkům oznámil, že běží v nouzovém režimu, a doporučil jim, ať sáhnou po vlastních plánech obnovy po havárii, uvádí Help Net Security. Válečnou stránku věci nechám jiným. Mě zajímá, co se stane s cloudem, když selže fyzická vrstva, kterou v architektonických diagramech kreslíme jako obláček.

Co stálo v Sasovu

Datacentrum v Sasovu běží od roku 2014 v části bývalého závodu Sasta, píše Meduza. Nebyla to žádná okrajová lokalita. Stály tu dva ze tří superpočítačů, na kterých Yandex trénuje neuronové sítě: Červoněnkis s nominálním výkonem 29,42 PFLOPS a Ljapunov s 20,03 PFLOPS. Třetí stroj, Galuškin (20,64 PFLOPS), stojí ve Vladimiru, uvádí server Militarnyi s odvoláním na ruský web T-Invariant.

Podle T-Invariant jsou teď mimo provoz všechny tři. Slovo „zničené" bych zatím nepoužívala. Yandex sám řekl stanici CNBC, že nedokáže potvrdit, jestli jde vybavení v Sasovu obnovit. Satelitní snímky z 12. října ukazují poškozenou zhruba třetinu budovy, píše ukrajinský 24tv. (Moscow Times mimochodem tvrdí, že Galuškina vyřadil už úder na Kalugu. Ostatní zdroje ho drží ve Vladimiru, takže tady se reportéři rozcházejí.)

Zajímavý detail přidal server CNews: datacentrum v Sasovu napájejí dvě nezávislé linky 110 kV. Proti výpadku sítě je to slušná redundance. Proti dronu na střeše žádná.

Zóna dostupnosti není region

Tady je jádro celé věci pro každého, kdo kdy kreslil architekturu v cloudu.

Zóny dostupnosti (availability zones) jsou oddělená datacentra s vlastním napájením a chlazením. Vymyslely se proto, aby výpadek jedné budovy nepoložil celou službu. Kdo nasadí aplikaci do dvou nebo tří zón, udělal přesně to, co radí každá certifikace. Úder na Vladimir ale podle Moscow Times shodil zónu ru-central1-a, tedy druhou ze zón Yandex Cloudu během tří dnů. Zbytek infrastruktury firma označila za „nestabilní".

Model zón dostupnosti počítá s nekorelovanými poruchami: blesk, porucha transformátoru, bagr přes optiku. Útočník, který si vybírá cíle podle mapy, poruchy koreluje schválně. Jeden ze zdrojů Meduzy to popsal až bolestně prakticky: v Rjazaňské, Kalužské ani Vladimirské oblasti se nečekají zemětřesení, takže nikoho nenapadlo platit fyzickou ochranu budov.

Ruský ministr pro digitální rozvoj označil útok za bezprecedentní a jeho úřad teď s ministerstvem obrany řeší, jak datacentra krýt, píše rádio Echo. Protivzdušná obrana jako součást SLA. To v žádném ceníku cloudu zatím nenajdete.

Kdo všechno visel na Yandexu

Výpadek vyhledávače nebo hudební služby by byl nepříjemný, ale přežitelný. Horší je, kolik cizích webů má Yandex zašitý uvnitř. Vypadly vestavěné služby jako Yandex ID pro přihlašování, Metrika a AppMetrica, reklamní síť, mapy na cizích webech, SmartCaptcha, Yandex Pay, odložené platby Split a firemní pošta Yandex 360, vyjmenovává Echo.

Po úderu na Sasovo měly problémy weby Ruských drah, operátora MegaFon a několika médií, uvádí ukrajinský server ua.news. Meduza přidává aplikaci řetězce Vkusno i točka, letiště Pulkovo a služby pro kontinuální monitorování glukózy u lidí s diabetem.

Ten poslední příklad stojí za chvilku ticha. Senzor na paži funguje dál, jen data nemají kam odtéct.

Yandex Pro mezitím radil taxikářům, ať jezdí podle Google Maps nebo Waze, a firma omezila stahování z Yandex Disku, aby ušetřila kapacitu pro ostatní služby, píše Meduza. Řízené vypínání méně důležitých funkcí (load shedding) je přesně to, co se v takové chvíli dělat má. Jen to obvykle nevidíte tak naplno.

Data doma, služba jinde

Nejlíp mi celou situaci shrnul případ Kazachstánu. Yandex tvrdí, že osobní data kazašských uživatelů zůstala uložená v Kazachstánu. Řidiči přesto nedostávali zakázky a cestující si nemohli objednat taxi, upozorňuje The Times of Central Asia. Problémy hlásili i uživatelé v Arménii, Bělorusku, Gruzii a Srbsku, uvádí Meduza.

Lokalizace dat a lokalizace služby jsou dvě různé věci. Databáze může ležet v Almaty, ale pokud řídicí vrstva (control plane) běží v Rjazaňské oblasti, máte v Almaty jen velmi bezpečně uložený archiv.

Kam utéct, když nesmíte za hranice

Ukrajina v únoru 2022, těsně před invazí, narychlo změnila zákon a státní registry přestěhovala do zahraničních cloudů. Rusko tuhle cestu zavřelo samo sobě. Zákon o lokalizaci osobních dat platí od roku 2015 a data ruských občanů musí zůstat na ruských serverech. Yandex se proto domluvil na urychleném přesunu klientských dat a služeb k domácí konkurenci: VK Cloud, Selectel a K2 Cloud, píše Meduza. Záložní plán tedy existuje, jen vede do datacenter, která leží ve stejném dosahu dronů.

Druhý problém je železo. Výměna poškozeného vybavení má podle Meduzy trvat až půl roku. Tom's Hardware upozorňuje, že část komponent už pod sankcemi nemusí jít vůbec sehnat a Yandex může být pro trénink dalších modelů odkázaný na čínskou infrastrukturu. A financovat to bude za klíčovou sazbu centrální banky 14 %, kterou regulátor v září podržel, uvádí server retail.ru.

Sberbank: další na řadě

V noci na 14. října zasáhly drony datacentrum Sberbanku v Balakovu v Saratovské oblasti, víc než 650 km od ukrajinských hranic. Komplex byl stále ve výstavbě, část kapacit už ale běžela. Plánovaný příkon je 82 MW, kapacita až 3 000 racků a přes 120 000 serverů a datacentrum mělo hostit i státní platformu GosTech, píše web www1.ru. Sberbank tvrdí, že všechny služby fungují normálně. Uživatelé přesto hlásili nefunkční bankovnictví a platby, informuje Meduza, i když souvislost s útokem nikdo nepotvrdil.

Pro kontext: tohle všechno je odveta. Od 23. září ruské útoky poškodily nebo zničily datacentra nejméně osmi ukrajinských firem, mezi nimi MiroHost, DataGroup a CityHost, uvádí Tom's Hardware.

A co ty boty?

Na sítích se rychle rozšířila teorie, že po úderech utichly ruské trollí farmy. Opírá se o graf z Cloudflare Radar, který ukazuje propad automatizovaného provozu ze sítě Yandexu (AS13238). Ilja Lozovskij z OCCRP ale upozornil, že graf měří automatizovaný webový provoz, třeba roboty vyhledávače, a ne boty na sociálních sítích, píše Help Net Security. Když vám spadnou datacentra, crawler vyhledávače přestane crawlovat. To je fyzika, ne kontrarozvědka.

Yandex mezitím na vlastních mapách rozmazal všechna svá cloudová datacentra, píše UNITED24 s odvoláním na web Verstka. Ochrana by fungovala skvěle, kdyby drony navigovaly podle Yandex Map.

Zdroje

• Lenta.ru: https://lenta.ru/news/2026/10/08/long-yandeks-soobschil-o-masshtabnom-sboe-v-rabote-servisov-iz-za-ataki-vsu-chto-izvestno/
• Kommersant: https://www.kommersant.ru/doc/9008807
• Help Net Security: https://www.helpnetsecurity.com/2026/10/13/ukraine-drone-strikes-yandex-data-centers/
• Meduza (EN, 8. 10.): https://meduza.io/en/feature/2026/10/08/ukraine-strikes-yandex-data-center-housing-two-of-the-company-s-supercomputers
• Meduza (EN, 15. 10.): https://meduza.io/en/feature/2026/10/15/ukrainian-strikes-on-yandex-s-data-centers-could-set-back-russia-s-ai-development-by-years-never-a-rival-to-the-u-s-or-china-in-ai-russia-may-now-fall-behind-kazakhstan-too
• Meduza (RU, 12. 10.): https://meduza.io/feature/2026/10/12/kak-yandeks-spravlyaetsya-s-posledstviyami-udarov-ukrainy-po-svoim-data-tsentram
• Meduza (Sberbank): https://meduza.io/en/news/2026/10/14/users-start-reporting-outages-in-sberbank-services-after-ukrainian-drone-attack-on-company-s-data-center
• Militarnyi: https://militarnyi.com/en/news/drone-strikes-may-have-knocked-out-all-three-yandex-supercomputers/
• CNBC: https://www.cnbc.com/2026/10/08/russia-yandex-ukraine-drone-strike-data-center.html
• 24tv.ua (satelitní snímky): https://24tv.ua/ru/povrezhdenija-data-centra-jandeksa-v-sasovo-sputnikovye-snimki_n3161081
• The Moscow Times: https://themoscowtimes.com/2026/10/15/from-wildberries-to-yandex-ukraine-is-turning-russian-business-giants-dominance-into-a-liability-a93976
• CNews: https://www.cnews.ru/news/top/2026-10-08_sklady_nadoelibombim_data-tsentry
• Echo: https://echofm.online/stories/vsu-atakovali-tri-data-czentra-yandeksa-za-nedelyu-chto-proishodit-s-servisami-kompanii-i-svyazannymi-s-nej-resursami
• ua.news: https://ua.news/en/war-vs-rf/tri-data-tsentri-za-tizhden-iak-udari-po-iandeksu-ogolili-zalezhnist-rosiyi-vid-tsifrovoyi-infrastrukturi
• The Times of Central Asia: https://timesca.com/drone-strikes-on-russian-data-centers-disrupt-yandex-services-across-central-asia/
• Tom's Hardware: https://www.tomshardware.com/tech-industry/data-centers/ukrainian-drones-hit-russias-yandex-data-centers-housing-two-top-supercomputers-major-outage-follows-retaliatory-strike
• retail.ru (klíčová sazba): https://www.retail.ru/news/tsb-rf-sokhranil-klyuchevuyu-stavku-na-urovne-14-godovykh-12-sentyabrya-2026-282051/
• www1.ru (Sberbank Balakovo): https://www1.ru/en/news/2026/10/14/bespilotniki-atakovali-krupneisii-data-centr-sberbanka-v-rossii-stoimostiu-v-desiatki-milliardov-rublei.html
• Ukrainska Pravda: https://www.pravda.com.ua/eng/news/2026/10/14/8057949/
• UNITED24 Media: https://united24media.com/war-in-ukraine/ukraine-struck-yandex-data-centers-russian-bots-went-silent-now-questions-are-mounting-23339
• Inspirace: InfoTalks s Jiřím Justem, info.cz: https://www.info.cz/podcasty/infotalks/utoky-na-ruska-datacentra-yandex-jiri-just

The post Tři datacentra za čtyři dny: co drony udělaly s Yandex Cloudem first appeared on Hard Wired.

Výzkumníci ze skupiny Paradigm Shift zveřejnili 18. června 2026 funkční exploit pro SecureROM čipů A12 a A13. Apple to nevyřeší aktualizací. Nikdy.

BootROM je první kód, který se spustí při zapnutí iPhonu. Je vypálený přímo do křemíku při výrobě. Žádná aktualizace se k němu nedostane, žádný patch ho nepřepíše. Chyba v BootROMu je chybou navždy – a přesně to je případ usbliter8.

Tým Paradigm Shift zveřejnil 18. června 2026 fungující proof of concept, který dosahuje spuštění libovolného kódu uvnitř SecureROM čipů Apple A12 a A13. Dotčená zařízení to ponesou do konce svého života, píše The Hacker News.

Co přesně se stalo

Útok kombinuje hardwarovou chybu v USB řadiči s chybnou konfigurací DART (DMA Address Remap Table) v SecureROMu. Na A12 a A13 běží DART v bypass režimu – útočník tak může přepisovat SRAM prakticky volně. Na A11 to nešlo, protože tamní USB driver po každém paketu manuálně resetuje DMA adresu. A14 a novější generace konfigurují DART správně od začátku.

Na A12 je cesta k PC control přímočará: DMA buffer leží v paměti hned vedle zásobníku USB tasku. Přepsat saved link register a počkat na context switch – hotovo.

Na A13 to bylo podstatně větší drama. Apple tam přidal Pointer Authentication (PAC), který chrání návratové adresy na zásobníku. Paradigm Shift to obešel ve více fázích: nejdřív poškodil struktury DART na haldě, aby získal omezené write primitives, pak přepsal čítač panic depth (čip místo restartu začal cyklit na chybách) a nakonec přepsal pointer USB interrupt handleru v BSS. Příští USB přerušení spustilo kód útočníka. Výsledek v obou případech: spuštění na EL1, privilegovaném režimu, uvnitř SecureROMu.

Po úspěšném exploitu se do USB serial stringu zařízení zapíše PWND:[usbliter8]. Trochu jako podpis.

Jaká zařízení jsou postižena

Potvrzené: A12 (iPhone XS, XR, iPad Air 3, iPad mini 5), A13 (iPhone 11 řada, iPad 9. generace, druhý SE), S4 a S5 (Apple Watch Series 4 a 5, HomePod mini). Technicky možné, ale zatím neimplementované: A12X a A12Z (iPad Pro 2018–2019), uvádí MacRumors.

Jak moc se bát

Exploit není vzdálený útok. Útočník potřebuje fyzický přístup k zařízení, správný kabel, RP2350-based mikrokontrolér a zařízení v DFU módu. Celý exploit trvá méně než dvě sekundy – ale než ho spustí, musí mít iPhone v ruce.

Secure Enclave zůstává nedotčena. Hesla a šifrovaná data uživatele jsou stále chráněna. Paradigm Shift sám upozorňuje, že kompromitace BootROMu může otevřít nové útočné vektory vůči Secure Enclave – ale žádný takový útok zatím nebyl demonstrován.

Srovnání s checkm8 z roku 2019 se nabízí samo. Ten exploit trvale vyřadil A5 až A11 z dosahu patchů – usbliter8 teď totéž udělal s další generací čipů. Checkm8 dal světu roky jailbreaků, forenzní extrakce dat a alternativních boot prostředí. Dá se předpokládat, že usbliter8 otevře podobné hřiště pro XS, XR a jedenáctky.

Pro firemní správce mobilních zařízení je situace přímočará: náhrada hardwaru za A14 a novější je jediná dostupná mitigace. Pro běžné uživatele – pokud máte iPhone pevně v kapse a nikomu ho nedáváte, riziko zůstává spíše teoretické.

Apple Security zatím nevydal žádné CVE ani bezpečnostní advisory. Celkem příznačné pro chybu, kterou stejně nemůže opravit.

Zdroje: The Hacker News, MacRumors, AppleInsider, Paradigm Shift (ps.tc), Privacy Guides

The post usbliter8: nový nepatchovatelný exploit rozlomil boot řetězec A12 a A13 first appeared on Hard Wired.

Shrnutí: New York jako první americký stát přijal zákon, který nařizuje výrobcům 3D tiskáren, CNC frézek a dalších digitálních výrobních strojů zabudovat do jejich zařízení software, jenž před každým tiskem nebo obráběním prohledá soubor se vzorem a porovná ho s databází zbrojních plánů. Pokud algoritmus vyhodnotí soubor jako podezřelý, stroj se nespustí. Zákon byl přijat jako součást státního rozpočtu na fiskální rok 2026–2027 a podepsán guvernérkou Kathy Hochul.

1. Jak zákon vznikl a co přesně říká

Příslušná ustanovení jsou součástí rozpočtového zákona S.9005 / A.10005C (New York State Budget 2026–2027). Klíčová část je skryta v Part C, která obsahuje dva podčástky:

• Subpart A — trestněprávní ustanovení týkající se výroby nelegálních zbraní na 3D tiskárnách a sdílení digitálních plánů.
• Subpart B — technický mandát: povinné zabudování tzv. blocking technology do všech 3D tiskáren a CNC strojů prodávaných v New Yorku.

Zákon definuje „3D tiskárnu" extrémně široce — jako:

jakýkoliv stroj schopný vyrobit trojrozměrný objekt z digitálního návrhového souboru metodou přídavné výroby (additive manufacturing) nebo trojrozměrných úprav objektu metodou subtraktivní výroby (subtractive manufacturing).

Tato definice tedy pokrývá nejen klasické FDM/SLA 3D tiskárny, ale i CNC frézy, CNC routery, soustruhy, laserové řezačky a v důsledku i hobbyistické plotry jako je Cricut. Jednoduše: pokud stroj převádí digitální soubor na fyzický objekt, zákon se na něj vztahuje.

2. Co je "blocking technology" a jak má fungovat

Zákon definuje blocking technology jako hardware, software, firmware nebo jiná integrovaná technická opatření, která zajistí, že stroj nezahájí zpracování žádné zakázky, dokud nebude příslušný soubor vyhodnocen algoritmem detekce zbrojních plánů (firearms blueprint detection algorithm).

Algoritmus má za úkol:

1. Vyhodnotit soubor (STL, G-code nebo jiný CAD formát).
2. Zjistit, zda lze soubor použít k výrobě střelné zbraně nebo nelegálního dílu.
3. Podezřelý soubor zablokovat — stroj se nespustí.

Zákon nevyžaduje jen software. Vyžaduje, aby byl tento mechanismus přítomen přímo v každém prodávaném zařízení. Zároveň ruší možnost online prodeje a zásilkového doručení — veškerý prodej a přenos 3D tiskáren musí probíhat osobně (in-person). Pokuty za porušení dosahují až 10 000 USD za incident.

Zákon neobsahuje žádné výjimky pro:

• komerční výrobce (automobilový, letecký, medicínský průmysl),
• výzkumné instituce,
• federálně licencované zbrojíře (federally licensed gunsmiths),
• školy a vzdělávací instituce.

3. Trestný čin za digitální soubor

Subpart A zavádí nový typ trestného činu: distribuci nebo držení digitálního návrhového souboru, který by mohl sloužit k výrobě dílu střelné zbraně, je nově zločinem třídy E (Class E felony), pokud jej sdílíte s kýmkoliv, kdo není federálně licencovaným zbrojířem registrovaným v New Yorku.

Podle výkladu zákona se tato definice teoreticky vztahuje na:

• novináře reportující o dané problematice,
• výzkumné pracovníky studující 3D tisk a bezpečnost,
• designéry a umělce pracující s tvarovými soubory.

Trestní třída E v New Yorku odpovídá trestu odnětí svobody až na 4 roky.

4. Technický problém: proč to pravděpodobně nefunguje

Zákon naráží na zásadní technické překážky, na které upozornily firmy i nezávislí experti.

4a. Algoritmus čte geometrii, ne záměr

Detekční algoritmus porovnává tvary — geometrii objektu. Problém je, že běžné průmyslové díly sdílejí geometrii se součástkami zbraní. Trubka vypadá jako hlaveň, konzola jako rám zbraně, konektor jako spoušťový mechanismus. Jeden výrobce otestoval svůj firmware na navrhovaném algoritmu ještě před přijetím zákona: systém označil 17 % zcela legitimních tisků jako podezřelých — šlo o díly motorů, jígy, nástroje.

Firma Adafruit a její spoluzakladatel Philip Torrone to shrnuli lapidárně:

„Nevyžadujeme, aby stolní pily skenovaly dřevo kvůli zbraňovým tvarům. Nevyžadujeme, aby soustruhy volaly domů, než začnou obrábět kov. Ale přesně to tento zákon dělá s každým strojem, každým souborem a každou zakázkou."

4b. Open-source firmware — Marlin, Klipper, RepRap

Drtivá většina desktopových 3D tiskáren a CNC strojů běží na open-source firmwaru — primárně Marlin a Klipper. Tento software vyvíjejí dobrovolníci a komunity, není připojen ke státní databázi a není navržen pro compliance infrastrukturu. Stroje jsou navíc velmi často offline — záměrně nepřipojeny k internetu. Implementace zákonného požadavku by vyžadovala kompletní přepis firmwaru, což je technicky i kapacitně mimo možnosti komunitních projektů.

EFF (Electronic Frontier Foundation) zákon veřejně oponovala a označila blocking technology za "cenzurní software sledující každý tisk".

5. Software ThreeDGunT a role manhattanského státního zástupce

Zákon nevznikl ve vzduchoprázdnu. Španělská firma Print&Go se sídlem v Lleida (Katalánsko) již dříve vyvinula software nazvaný 3D GUN'T. Tento systém:

• porovnává každou tiskovou zakázku s databází zbrojních plánů,
• používá AI k rozpoznávání tvarů typických pro součástky zbraní,
• v případě shody automaticky blokuje tisk a upozorní správce.

Print&Go má přes 420 000 uživatelů a software je integrován přímo do firmwaru zařízení při výrobě.

Manhattanský okresní státní zástupce Alvin Bragg začal tento software prosazovat u výrobců 3D tiskáren ještě před tím, než zákon existoval. V roce 2025 zaslal dopisy firmám Creality a Flashforge s hrozbou právní odpovědnosti, pokud software 3D GUN'T neadoptují. Vyzval rovněž k odstranění zbrojních CAD souborů z cloudových platforem výrobců.

Jinými slovy: vymáhací mechanismus byl postaven dříve, než byl zákon napsán. Zákon pak byl upraven tak, aby odpovídal již existujícímu řešení.

6. Chystané zákony: prověrka před koupí tiskárny

Paralelně se v zákonodárném sboru New Yorku projednává Assembly Bill A2228 (a jeho senátní protějšek S3562), který dosud nebyl přijat, ale je aktivní v komisích obou komor. Tento návrh by zavedl povinnou prověrku trestní minulosti při koupi 3D tiskárny — stejný typ prověrky jako při koupi střelné zbraně. Prodejce by musel žádat státní divizi trestního soudnictví, která má 15 pracovních dní na rozhodnutí.

Zákon sponzoruje assembleymemberka Jenifer Rajkumar a v různých podobách koluje v zákonodárném sboru od roku 2023.

7. Šíření do dalších států

New York není jediný. Washington State projednával HB 2321 — prakticky identický zákon vyžadující blocking technology v 3D tiskárnách. Podle návrhu by washingtonský generální prokurátor vytvořil a průběžně aktualizoval databázi zakázaných zbrojních souborů. Zákon byl v lednu 2026 postoupen do komise pro občanská práva a soudnictví.

Vzorový zákon, jakmile projde v jednom státě, mají ostatní tendenci kopírovat — a výrobci, kteří chtějí prodávat v celých USA, si nemohou dovolit vyrábět dvě různé verze produktu. V praxi tedy regulace jednoho státu de facto ovlivní zboží prodávané v celé zemi.

Přehled klíčových faktů

Zdroje

• New York State Legislature — S.9005 / A.10005C text zákona
• The Reload — New York Bans Digital Gun Files, Aims at 3D Printers
• Electronic Frontier Foundation — Stop New York's Attack on 3D Printing
• Reclaim the Net — New York Budget Bill Mandates File Scans for 3D Printers
• 3D Printing Industry — Adafruit Warns of Flaws in the New Firearm Screening Bills
• Manhattan DA — D.A. Bragg Calls On 3D-Printing Companies To Address Proliferation Of Illegal Firearms
• Print&Go — 3D GUN'T: Print&Go's solution to prevent 3D printed Ghost Guns
• Fabbaloo — Washington Bill Would Require Weapon-Blocking Software in 3D Printers
• NY State Assembly — A2228 — background check bill
• NYS Focus — What's in the 2026 NY State Budget
• Times Union — Hochul pushes ban on 3D technology used to make guns

The post New York schválil zákon o sledování 3D tiskáren a CNC strojů first appeared on Hard Wired.

Nálepka za pár korun, telefon, a najednou Vám URL otevírá samo. NFC tagy z rodiny NTAG patří k nejlevnějším způsobům, jak fyzickému světu přidat softwarovou vrstvu — a přitom na to nepotřebujete pájku, kompilátor ani Arduino. Tenhle článek je hands-on návod, jak zapsat URL na NTAG215 přímo z iPhonu pomocí aplikace NFC Tools. Po cestě vysvětlím, co se v čipu při zápisu skutečně děje, protože pochopit, co máte v ruce, je polovina úspěchu příštího projektu.

Co je NTAG a proč by Vás měl zajímat

NTAG je rodina pasivních NFC čipů od firmy NXP Semiconductors. Pracují na 13,56 MHz, splňují standard NFC Forum Type 2 a ISO/IEC 14443-A, a nemají vlastní napájení — energii i hodinový signál si berou z magnetického pole čtečky (typicky Vašeho telefonu). To je důvod, proč Vám tag vydrží roky bez údržby a proč stojí v řádu korun.

Pro makery jsou zajímavé tři varianty:

Čísla v praxi: do NTAG213 se vejde URL do zhruba 130 znaků (po odečtení NDEF režie), do 215 přibližně jeden plnohodnotný kontakt s telefonem a e-mailem, do 216 i krátká Wi-Fi konfigurace plus URL bokem. Nálepky se prodávají od 5 Kč za kus, kvalitní plastové karty od 15 Kč, klíčenky od 20 Kč. Pro experimenty se hodí balíček deseti kusů od českého dodavatele (neven.cz) nebo dvacet kusů z AliExpressu — cenový rozdíl je marginální, ale dodací doba zásadní.

Potkáte je všude. Marketingové nálepky v obchodech, vstupenky na lyžovačku, visačky na zboží proti padělání, Amiibo figurky od Nintenda, párovací tagy bezdrátových sluchátek. NXP udává životnost 10 let retence dat a 100 000 zápisových cyklů, což pro většinu maker projektů znamená „vydrží to déle než zájem o projekt".

Anatomie čipu

Vnitřek NTAG215 si lze představit jako sešit rozdělený na 135 stránek po 4 bajtech. Některé stránky jsou Vaše hřiště, jiné jsou výrobní data, která nezměníte ani kdybyste chtěl.

Page 0x00 – 0x02   UID a system bytes      (read-only)
Page 0x03          Capability Container    (jednou píšete, OR-uje se)
Page 0x04 – 0x81   User memory             (504 B, zde žije Vaše data)
Page 0x82          Dynamic Lock Bytes
Page 0x83 – 0x84   Konfigurace (AUTH0, ACCESS)
Page 0x85          PWD (heslo, 4 bajty)
Page 0x86          PACK (potvrzení, 2 bajty)

UID (Unique Identifier) má 7 bajtů a je z výroby spálené v křemíku — žádná aplikace ho nepřepíše. Slouží mimo jiné jako sůl pro výpočet hesla u Amiibo (ale o tom zase jindy).

User memory je oblast, kam píšete přes NFC Tools. Data se ukládají ve formátu NDEF (NFC Data Exchange Format), což je standardizovaná obálka NFC Fora. Bez NDEF by si Váš iPhone se zápisem na Android tagem nerozuměl — díky NDEF rozumí oba.

Configuration pages určují, jestli je čip chráněn heslem (registry PWD a AUTH0), jestli a od které stránky platí ochrana (AUTH0), a jestli má heslo limit neúspěšných pokusů (ACCESS bit AUTHLIM). Když na ně narazíte v NFC Tools, většinou se jim chcete vyhnout, dokud nevíte, co děláte — špatně nastavený AUTHLIM dokáže udělat z funkčního tagu drahou nálepku natrvalo.

NTAG215 navíc umí pár chytrostí navíc oproti staršímu NTAG203: 32-bitové heslo (PWD_AUTH), digitální podpis pravosti od NXP (ECC originality signature, který odlišuje pravé NTAG od čínských klonů) a tzv. UID mirror, kdy si do NDEF zprávy můžete nechat automaticky zrcadlit UID čipu — užitečné pro per-tag analytiku bez nutnosti programovat každý kus zvlášť.

Co budete potřebovat

K tomu, co budeme dělat, stačí překvapivě málo:

• iPhone 7 nebo novější s iOS 13 a výš. Starší modely NFC sice mají, ale nepodporují třetí stranou ovládaný zápis. Pokud máte iPhone 13 a novější, bude čtení a zápis jednoznačně rychlejší a spolehlivější díky lepší anténě.
• NFC Tools od vývojáře Wakdev, zdarma z App Store. Existuje i placená „Pro Edition", ale pro zápis jednoduché URL ji nepotřebujete. Pro varianty jsou navíc plánovací funkce a profily — užitečné, až budete chtít sériově programovat víc tagů najednou.
• NTAG215 nálepku, kartu nebo klíčenku. Pro tento návod používám NTAG215, ale postup je identický pro NTAG213 i NTAG216, lišit se bude jen kapacita.

Jedna technická poznámka k platformě: iPhone má NFC anténu v horní části zařízení, kolem objektivu kamery. Android telefony ji mívají vzadu uprostřed nebo dole. Pokud jste zvyklý držet Android telefon plochou stranou na tag, s iPhonem to nepůjde — musíte přiložit horní hranu. Začátečníci se tady často zaseknou na tom, že „tag prostě nefunguje", přitom jen čtou špatnou částí telefonu.

Druhá poznámka, méně příjemná: iOS je v NFC schopnostech rok zpátky oproti Androidu. Pro zápis NDEF a čtení standardních tagů je vše v pořádku, ale na low-level operace (přímý přístup k jednotlivým stránkám, práce s MIFARE Classic, dump celé paměti) potřebujete buď Android, nebo specializovaný hardware jako Proxmark3 či Flipper Zero. Pro náš úkol je iPhone naprosto dostatečný.

Hands-on: zápis URL hardwired.dev

Konečně k věci. Předpokládám, že máte NFC Tools nainstalovanou a v ruce prázdný NTAG215. Postup má pět kroků.

Krok 1: Přečtěte tag

Otevřete NFC Tools a v dolním menu zvolte záložku Read. Telefon se přepne do skenovacího režimu a nahoře vyskočí systémový dialog „Připraveno ke skenování". Přiložte horní hranu iPhonu k tagu a držte ji nehnutě zhruba sekundu. Telefon zavibruje a vrátí Vám informace o čipu.

V odpovědi uvidíte něco jako:

Serial Number: 04:A3:B7:12:5F:80:C1
Tag type: ISO 14443-3A (NXP - NTAG215)
Technologies available: NFC A
Manufacturer: NXP Semiconductors
Maximum data size: 504 bytes
NDEF: Yes (writable, 0/504 bytes used)

Tohle je výchozí stav nového čipu. UID začínající 04 je typické pro NXP. NDEF je deklarováno jako prázdné a zapisovatelné.

Krok 2: Vytvořte záznam

Přepněte se na záložku Write. Klepněte na Add a record. Otevře se seznam typů — vCard, Wi-Fi, Bluetooth pairing, e-mail, telefon, geolokace, a další. Vás zajímá první položka: URL / URI.

V dalším okně vyberte schéma. NFC Tools má rozbalovací menu s běžnými prefixy (http://, https://, tel:, mailto: a další), a zbytek URL napíšete do textového pole. Pro náš účel:

• Schéma: https://
• URL: hardwired.dev

Aplikace Vám pod políčkem ukáže, kolik bajtů záznam zabere — pro https://hardwired.dev to bude méně než 20 bajtů. Klepněte na OK. Vrátíte se na obrazovku Write, kde teď uvidíte jeden NDEF záznam typu URI připravený k zápisu.

Krok 3: Zapište na tag

Klepněte na velké tlačítko Write. Telefon znovu otevře skenovací dialog. Přiložte horní hranu iPhonu k tagu a držte. Zápis NDEF zprávy o 20 bajtech trvá zhruba 200 milisekund — celý dialog ale obvykle zmizí až po vteřině, protože iOS si dává malou rezervu na ověření.

Po úspěšném zápisu uvidíte zelenou hlášku Write complete. Pokud místo toho dostanete chybu, nejčastější příčiny jsou tři: tag je zamčený lock bytes (nelze nic dělat), tag má heslo (potřebujete ho zadat ve Security menu), nebo jste ho odtrhli moc rychle (zkuste znovu).

Krok 4: Ověřte zápis

Vraťte se na záložku Read a tag přečtěte znovu. Tentokrát uvidíte v odpovědi přibyl řádek navíc:

NDEF: Yes (writable, 17/504 bytes used)

Record 0
  Type: URI
  URI: https://hardwired.dev

Tag teď nese Vaši URL. 17 z 504 bajtů využito — zbytek paměti je stále volný a Vy můžete přidat další záznamy (např. WhatsApp link, kontakt, Wi-Fi heslo) bez omezení, dokud nevyplníte kapacitu.

Krok 5: Otestujte v reálném světě

A teď to nejlepší. Zamkněte iPhone (jen stisk power tlačítka, do podivných stavů ho dávat nemusíte) a přiložte ho horní hranou k tagu. Na zamčené obrazovce se objeví banner s URL hardwired.dev. Klepnutím se otevře Safari.

Tohle je důležitý moment: na iPhonu funguje background NFC scanning pouze pro NDEF záznamy standardních typů — URL, telefonní číslo, e-mail, geolokace a několik dalších. Wi-Fi konfigurace nebo vCard se zamčené obrazovce neobjeví, protože iOS je nevyhodnocuje na pozadí (z bezpečnostních důvodů). Pokud chcete, aby tag spustil Wi-Fi připojení, musíte mít NFC Tools otevřenou, nebo využít Shortcuts Automation, kterou iOS k NFC tagům umí přivázat (ale to je téma na samostatný článek).

Gratuluji — máte první funkční NTAG.

The post NTAG čipy a jak je naprogramovat z iPhonu first appeared on Hard Wired.

15. dubna 2026 prolomil bezpečnostní výzkumník Paul Moore oficiální evropskou aplikaci pro ověřování věku za dvě minuty. Snímky obličejů z dokladů ukládala nešifrované. Biometrickou autentizaci šlo obejít přepnutím jednoho booleanu v config souboru. Francouzský výzkumník Baptiste Robert to nezávisle potvrdil.

O necelý měsíc později, 6. května, sdílela Výzkumná služba Evropského parlamentu na sociálních sítích lednový briefing o VPN. Označila je za „loophole in the legislation that needs closing". Tedy mezeru, kterou je třeba zacelit, protože děti přes VPN obcházejí ten samý systém ověřování věku, který jiný hacker prolomil v podivně krátkém čase.

A v tuhle chvíli česká média ztratila nervy.

Anatomie titulkové paniky

cnews.cz: „Konec anonymního surfování přes VPN". tiscali.cz: „EU jde po soukromém internetu". centrum.cz/cdr.cz: „Závažný útok na soukromí". V překladu: Brusel zítra zatne.

Reálně? EPRS je think-tank Evropského parlamentu. Píše analytické briefy pro poslance, ne zákony. Materiál ze 6. května není legislativní návrh, je to shrnutí debaty, ve které někdo nahodil tezi a publicistika ji zachytila jako fakt.

Nejstřízlivější hlas v ČR má v tomhle Petr Koubský v rozhlasovém Online Plus. „Orgán demokratické Evropy to udělat nemůže," říká k případnému zákazu. „Drtivá většina podobně radikálních návrhů skončí pod stolem."

Koubský má pravdu v jedné věci. Plošný zákaz VPN je v EU politicky neprůchodný. Naráží na DSA, GDPR, na ekonomický fakt, že VPN potřebují všechny korporace s remote workery. A pokud by k němu náhodou došlo, technicky by ho šlo vynutit jedině přes deep packet inspection na úrovni ISP. Což je infrastruktura, kterou dnes provozují Čína, Rusko a Írán. EU ne. A nikdo soudný nechce, aby ji EU začala stavět.

Jenže Koubský upozorňuje ještě na něco. Pracovní materiál Rady EU z roku 2025 zmiňuje, že členské státy zvažují přidat VPN na seznam služeb spadajících pod data retention. Čili povinné ukládání metadat o připojení. Kdo se kdy odkud kam připojil. Bez obsahu, ale s identitou.

A o tom by se mělo psát. Ne o zákazu, který nepřijde.

Goodhartův zákon pro internetovou regulaci

Když cíl regulace prochází přes proxy ukazatel, ten proxy ukazatel se sám stane cílem a celý smysl regulace se rozpadne. Britský Online Safety Act platí od července 2025. Měl chránit děti před pornografickým obsahem. Reálný výstup? Po jeho zavedení vyletěla stahování VPN aplikací v UK o 1 800 % během prvního měsíce. Proton VPN hlásil nárůst registrací o 1 400 až 2 000 procent v hodinách po zapnutí kontrol. Děti se nepřestaly dívat na porno. Naučily se obcházet věkové kontroly v devíti letech místo třinácti. A jejich rodiče si nainstalovali NordVPN spolu s nimi, protože měli pocit, že British Telecom je sleduje.

Britská Children's Commissioner Rachel de Souza na to v BBC Newsnight reaguje předvídatelně. VPN označuje za „absolutely a loophole that needs closing". Volá po věkovém ověřování pro samotné VPN služby. House of Lords v lednu odhlasoval 207 ku 159 dodatek k Children's Wellbeing and Schools Bill, který by zakázal poskytování VPN dětem. Vrátilo se to do Dolní sněmovny. Není to zákon.

Ale logika je tady jasná. Když ověřování věku funguje špatně, přidej další vrstvu ověřování. Když ani ta nefunguje, přidej třetí. Až nakonec stojí mezi devítiletým dítětem a kdejakým webem tři biometrické skeny, dva systémy national ID a jeden požadavek na verifikaci VPN klienta. Devítileté dítě mezitím používá Tor přes Tails na flash disku, který si vyrobilo podle YouTube návodu.

Goodhart by se bavil.

Děti budou.

Bezpečnost přes obscurantismus, jen obráceně

Co EU reálně řeší, není dětská pornografie. Je to nepříjemný fakt, že po dvou desetiletích politiky „internet pro všechny" se objevuje cosi jako digitální nepřehlednost. Lidé používají Signal. Šifrovaný DNS. WireGuard běžící na vlastní VPS za pět euro měsíčně. Self-hosted instance Nextcloudu. Místo Chromu Brave nebo Mullvad Browser. A státní aparát, který si zvykl, že webový provoz teče přes pět velkých korporací s funkčním legal interface, najednou neví, co se mu děje pod nosem.

Místopředsedkyně Evropské komise Henna Virkkunen to 29. dubna 2026 řekla na tiskové konferenci nahlas. VPN by neměly sloužit k obcházení age verification. Tečka. Že VPN ale slouží primárně k něčemu úplně jinému, třeba k tomu, abych se z hotelové WiFi v Bangkoku připojil bezpečně do firemní infrastruktury, to v jejím prohlášení nezaznělo. Já sám používám WireGuard denně pro připojení k vlastní laboratoři přes Tailscale. Sto procent provozu jde tunelem. A je mi naprosto jedno, jestli tam někde v paketu plave packet, který by někoho v Bruselu naštval.

Tedy bylo mi to jedno. Dokud jsem nečetl Council Working Paper, který Koubský zmiňuje.

Data retention je tichý jed

Logování metadat má jednu vlastnost, kterou plošný zákaz nemá: nedělá rozruch. NordVPN, Mullvad, Proton, všichni budou dál fungovat. Reklama bude dál slibovat anonymitu. Logo zámku v rohu obrazovky bude dál uklidňovat uživatele. Jenom v server room v Bukurešti nebo v Zürichu poběží daemon, který do databáze ukládá: IP X se v 14:23:11 připojila k serveru Y, který má ven adresu Z. Trvalo to 4 hodiny. Přeneslo se 12 GB.

Žádný obsah. Žádné dešifrované zprávy. Jen kdo, kdy, odkud, kam. Což je v digitální stopě často víc, než je obsah samotný. Metadata mají tu nepříjemnou vlastnost, že přežijí všechno end-to-end šifrování světa. Vědí to v NSA. Vědí to vyšetřovatelé. A teď to ví Rada EU.

Pro VPN poskytovatele to znamená dvě možnosti.

Buď vyhoví, a celá jejich marketingová narativa o no-logs policy se stane fikcí. Mullvad dnes hrdě tvrdí, že nezná IP svých uživatelů. V regulovaném scénáři by ji znát museli. Nebo se z EU stáhnou. Což udělá ten lepší kus z nich, jenže pak zbude uživateli volba mezi statně registrovaným provozovatelem s povinným logováním a turkmenstánskou společností s pochybným whois záznamem. Nebudu hádat, co si vybere medián českého uživatele.

A k tomu se přidá ještě jeden detail, který se v české debatě skoro neobjevuje. Open Dialogue Foundation prezidentka Lyudmyla Kozlovska upozorňuje, že přesně tímhle jazykem se argumentuje v autoritářských režimech. „VPN slouží k obcházení zákonů" je rétorická figura, kterou používá Roskomnadzor v Rusku, Ministerstvo informací v Bělorusku a regulátoři v Číně už dvacet let. Když ji začne používat Brusel, nezíská tím morální převahu. Ztrácí ji.

Co s tím

Devatenáct organizací (Mozilla, EFF, Proton, Tor Project, Mullvad a další) poslalo 5. května 2026 britským ministrům otevřený dopis. Cituji volně, protože stojí za to: omezení nástrojů pro ochranu soukromí podkopává schopnost uživatelů pohybovat se po síti bezpečně a budovat digitální gramotnost. Přeloženo do hardwired řeči: vyrobíte děti, které neumí používat HTTPS, ale umí obcházet státní DPI.

V Bruselu se zatím nic neděje. Formálně. EPRS briefing je analytický papír. Council Working Paper je interní pracovní materiál. Henna Virkkunen na jedné tiskovce vyslovila jednu větu. Komise zatím nepředstavila konkrétní návrh.

Jenže když se podíváš na vektory tlaku, na Online Safety Act v UK, Senate Bill 73 v Utahu, australský zákaz sociálních sítí pro děti do šestnácti let, French double-blind verification system, vidíš, že západní demokracie se v posledních dvou letech pomalu přesouvají od regulace obsahu k regulaci samotné infrastruktury anonymity. Není to konspirace. Je to inercie. Každý regulátor řeší svůj malý problém. Skleníkový efekt vznikne sám.

Pokud nás v ČR něco potká, nebude to oznámení „VPN je od dnešního dne zakázána". Bude to novela zákona o elektronických komunikacích, která rozšíří povinnost ukládání provozních a lokalizačních údajů na poskytovatele VPN služeb. Předloženo poslancem, kterého nikdo nezná. Schválena ve třetím čtení v pátek odpoledne. A v pondělí budeš mít metadata svého WireGuard tunelu uložená v centrální databázi po dobu šesti měsíců.

A teď zkus někomu na Twitteru vysvětlit, proč tě to štve.

The post EU nezakáže VPN. Donutí poskytovatele logovat metadata first appeared on Hard Wired.

Předmluva

• OS
  • Operační systém, software, na kterém bezi jiný software.
• Android
  • Operační systém od společnosti Google, Inc. pro chytré telefony.
• GOS
  • GrapheneOS, zkratka pro tento OS založený na OS Android
• LOS
  • LineageOS, zkratka pro tento OS založený na OS Android.
  • LineageOS je založený na AOSP.
• AOSP
  • Android Open Source Project, jedná se o Android, který je "očištěný" od služeb Google a má v sobě pouze licenčně svobodné programy.
• Raspberry Pi
  • Raspberry Pi je jednodeskový počítač, zaměřený hlavně pro kutily.
  • Tento počítač má tzv. GPIO pinout, ke kterému lze připojit čidla a ty poté přímo z OS programovat.
• DDNS
  • Dynamic DNS, neboli dynamická domena.
  • Jedná se o domenu, kterou vam přideli nejaky poskytovatel (třeba freedns.afraid.org), který vam doménu aktualizuje periodicky, což se hodi, kdyz mate dynamickou IP adresu.
• Desktop Mode
  • v kontextu OS Android se jedná o funkcionalitu operačního systému, který umožňuje ovládat telefon připojený k počítačovému monitoru (společně s periferiemi jako myš a klávesnice) jako klasicky stolni počítač, byť s jinou filozofií ovládání.
  • Telefon se tak chová jako klasický stolní počítač, ačkoliv si ponechává své rozhraní pro dodatečnou funkcionalitu.
  • Jinymi slovy lze říci, že telefon plní funkci stolniho počítače i telefonu zároveň.
  • Subjektivně si myslim, že budoucnost výpočetní techniky půjde i tímto směrem.

Co předcházelo

V květnu 2022 jsem se po delší době používání svého tehdejšího telefonu Nokia 5 (Čistý Android) rozhodl k zakoupení nového přístroje, jelikož Nokia přestávala stačit mým potřebam, stejně tak i co se velikosti displeje týče.
Volba tehdy padla na Xiaomi Mi 11 Lite 5G, verze 8G/128G v černé barvě.

Společně s tím jsem pořídil i ochranné prvky, jako je ochranné sklo, pouzdra. Jinymi slovy snaha o to, aby telefon vydržel užívání v dalších letech.

Nicméně, nebylo to pouze o pozitivech.

Pomerně rychle jsem si zvykl na nové prostředí, s ním však přišly i věci jinak mě neznámé a kolikrát i "podezřelé". Jelikož Xiaomi je čínského "návrháře" (rozlišuji zde, že produkt je vyrobený v Číně / ČLR, kdo jej však navrhuje je pro mě subjektivně další entita), byly zde i aplikace, které jsem k dispozici mít nechtěl, místy to bylo i podivné chování OS.

Je pravdou, že krátce po koupi přišla slíbená aktualizace na Android 13, nicméně tím jinak nedůležité aktualizace ze strany výrobce (v tomto případě považuji jak fyzicky výrobce HW, tak i dodavatel OS) ustaly. Vlastně jedinými aktualizacemi - dodám, že pouze akutními, řešícími konkrétní bezpečnostní problém - byly pouze bezpečnostní.

Příchod Garmin Pay

Časem jsem se rozhodl si pořídit i chyté hodinky, jelikož jsem v té době rozhodl vyzkoušet si placení právě chytrými hodinkami.

První pokus byl s Xiaomi Watch 2. Paradoxní volba pro tohoto výrobce byla pro "čistý" operační systém s možností Google Wallet/Pay přímo v hodinkách.
Nicméně nepovedlo se mi tohoto docilit, hodinky při pokusu nahlásily chybu a odmítly platební kartu přidat. Původní způsob užití bylo "zpohodlnit" placení (při nástupu do MHD, v obchodě...). Už v té době jsem se snažil najít myšlenku "Jak separovat platby od (relativně permanentně) k datům připojeného telefonu. Dá se říci, že o sledování fyzického pohybu bankovními institucemi jsem tušil, nicméně čím dál více jsem měl potřebu toto oddělit. V této době (duben 2025) mi "stačilo", kdyz na domácí Wi-Fi jednorázově sesynchronizuji peněženky.

Ač se mi Xiaomi Watch 2 líbily, vrátil jsem je zpět a rozhodl se jít cestou Garmin Forerunner 255, společně s Garmin Pay.

Záhy jsem zjistil, že hodinky od Garminu nejenže nabídly styl placení, který jsem hledal, ale také možnost si napsat vlastní program. Garmin jako takový má sice uzavřený systém, nicméně má k němu k dispozici SDK (Software Development Kit, sadu programu na vývoj softwaru pro daný produkt, zjednodušeno), což mi otevřelo cestu časem i k tomu si naprogramovat vlastní "statistiky" k jednomu mému oblíbenému sportu/relaxaci.

Lze tedy říci, že Garmin vyřešil nejen problém v té době pro mě aktuální, ale přidal mi do života i možnost žít aktivněji s možností si to sledovat.

Závěrem, mé současné hodinky mi doporucil člověk jménem Valentino Hesse, čímž mu za doporučení chci poděkovat i formou tohoto textu.

Nástup VPN

V pozdějších fázích, asi tak rok před změnou jsem ve zvýšeném měřítku začal užívat domácí VPN. Konkretne jsem na svoji Raspberry Pi 3. generace (verze B) nastavil WireGuard. Jelikož už v té době jsem měl na své DDNS i certifikát přes LetsEncrypt, vlastnictví VPN dávalo smysl, hlavně kvůli bezpečnosti týkající se bankovních aplikací.

S nástupem a nastavením VPN se trochu pojí i nová filozofie užívání telefonu. Na Xiaomi jsem si všiml tzv. "sekundárního prostoru", přeloženě jde o jiný profil/uživatele na stejném telefonu. Telefon s touto funkcionalitou se chová, jako kdyby byl právě čerstvě nainstalován / zapnut, de facto jde o stejné prostředí. Výhodou tohoto prostředí je možnost mít separované aplikace (takže třeba "normální" profil bez bankovních věcí a "bankovní" profil s bankovními aplikacemi různých bank, aplikace na nákup, popřípadě komunikátory se separovaným účtem).

S tímto se však pojí vyšší nároky na baterii telefonu, jelikož "klasický" Android / LineageOS / AOSP "neumí" ukončit profil, kdyz není potřebný. Znamená to tedy, že profil běží na pozadí i nadále (což není vždy nevýhoda). Nezřídka se stávalo, že i po jedné cestě do obchodu telefon dokázal "propálit" i 20 %. To sice na cestu tam i zpět stačilo, místy bylo však užívání s ohledem na maximální dostupnost náročné, což ne vždy bylo příjemné, zvláště při delších cestách.

Od ledna 2026 jsem začal řešit, čím Xiaomi Mi 11 Lite 5G nahradím.

Google Pixel 10 Pro XL

Postupne jsem začal zkoumat specifikace různých telefonu, co by daný přistroj měl umet. V zasade jsem měl tyto požadavky:

• Profiling (rozšířená forma "sekundárního prostoru" od Xiaomi, alespoň 2 profily), ideálně s možností daný profil ukončit,
• Always-On VPN (čili zablokování veškerého provozu, není-li VPN aktivní)
• Dual-SIM (historicky mám více SIM karet, které i do dnešního dne udržuji v "provozu")
• větší display (hodně dobré zkušenosti u Xiaomi Mi 11 Lite, který měl velký display)
• Na základě zkušeností u Xiaomi i dlouhodobá podpora výrobce/dodavatele OS.

Volbou po cca 4 měsících, rešeršovaného výzkumu i za pomocí jazykových modelů (Gemini, ChatGPT) v několika instancich (tímto mám na mysli opakované využití AI "Jaký telefon? Zde jsou mé požadavky"), tak i dotazování různých diskusních fór jsem dospěl ke konečnému závěru, kterým se stal Google Pixel 10. generace, verze Pro, velikost XL. Formalním jménem "Google Pixel 10 Pro XL 16/256 GB".

Telefon jsem se rozhodl po delším váhání objednat a jelikož jsem v té době měl i členství v jednom větším internetovém obchodě, definitivně jsem se rozhodl pro koupi, konkretně zelené verze "Jade", která mi "zapadala do korporatního stylu".

Lze říci, že další den mi byl telefon doručen a já se tak mohl začít radovat z nového stroje. Samozřejmě, pro maximalni ochranu nového stroje jsem i jako v případě Xiaomi Mi 11 Lite přiobjednal ochranné prvky.

GrapheneOS

Zjednoduším-li to, Pixel jsem si neobjednal pouze jako náhradu, ale i jako cilený důvod. Už asi 2 měsíce před koupí jsem měl povedomí o operačním systému "GrapheneOS", který oproti standardnímu Androidu nabízel i od základu přeimplementovanou funkcionalitu týkající se bezpečnosti a soukromí.

I to byla součást mého předchozího rešeršovaného vyhledavání, který OS chci použít. Ano, jinymi kandidaty byla i Motorola, nicméně některé funkce jako GrapheneOS nenabízela a byť s autory GrapheneOS uzavřela partnerství na oficiálního dodavatele hardware (tím rozumím telefony), první přístroje od Motoroly mající jako OS GrapheneOS nebudou k dispozici dříve, než v roce 2027.

Funkcionalita společná a rozdilná

Jednou z motivaci pro nový telefon byla i funkcionalita tzv. "Desktop Mode", která se předchozích verzích Androidu objevovala pouze od výrobce Samsung, tzv. "DeX". Jiná varianta - která hovořila i v prospěch dříve zmíněné Motoroly - byl "Smart Connect", nicméně důvodem pro Pixel (a později i GrapheneOS) byly aktualizace operačního systému samotného.

"Zakladní" Android

Desktop Mode

Základní Android - záleží zde i na hardwaru telefonu - funkcionalitu Desktop Mode umí. Předchůdcem jím bylo USB OTG (USB On-The-Go), což je možnost připojit USB flash do telefonu a zacházet s ním podobným stylem, jako kdyby šlo o počítač, stejně tak ovladaní přes klávesnici a myš.
Desktop Mode přidává DisplayPort Alt Mode přes USB-C, která vyjma datového/ovladacího přenosu přenáší i obrazové data možné zobrazit právě na externím monitoru. Je to umožněné tzv. propustností rozhranní, v tomto případě USB-C.

Aktualizce

Ač společnost Google má snahu o snižovaní tzv. e-waste (elektronický odpad), ne každý výrobce je tomu nakloneň. Ano, stále jde o výdělek, nicméně funguje-li telefon i po své moralní zastaralosti, výrobce zpravidla nechce poskytovat opravy jinak starým strojům.

Řada Pixel od Google má v tomto případě jinou filozofii, jelikož jde o "vlajkové lodě" pro Android, filozofie aktualizaci je zde jiná a mnohem otevřenější k tomu udržet stroj v aktuálním stavu, jelikož hardware je poměrně schopný.

Rozdíl GrapheneOS oproti "základu"

Co se GrapheneOS týče, většína funkcí je v tomto systému oproti zakladnímu OS Android zachována, nicméně GrapheneOS má zaměření hlavně na bezpecnost.
Velkým rozdilem je zde nejen Always-On VPN (formalně dostupná již od verze Androidu 7/8), nicméně společně s profilovaním (které oproti zakladu má funkci cíleného vypnutí) je možnost zablokovat veškerý síťový provoz, neběží-li VPN na pozadí.

Toto je především zajímavé, má-li uživatel domácí VPN.

Základní Android nabízí aplikacím tzv. "pískoviště", nicméně v GrapheneOS je této funckionalitě věnována mnohem větší pozornost po stránce zabezpečení a soukromí. Lze i v určitých ohledech aplikaci dovolit, kam bude moci pristupovat (což je hodně zajimavé u některých aplikací typu Messenger od Meta, stejně tak WhatsApp).

Dále je hodně zajimavé - především s užitím vypínatelného profilu - právě pro bankovní aplikace, kdy nejenže dovolíte této aplikací běžet explicitně pouze tehdy, kdy je potřeba, ale také donutíte její provoz jít třeba přes vaši domácí síť. Lze tak říci, že telefon máte elektronicky stále připojený přes síťový prvek, kterému důvěřujete (což o "datech" - datovému připojení přímo z telefonu platí dvojnásob).

Jinou variantou jsou i aplikace, které chcete mít "zamknuté" za specialním heslem a dostupné pouze a pouze majiteli přístroje.

Post Scriptum ke GrapheneOS

Mám-li v krátkosti udělat výtah, lze říci, že GrapheneOS jsem na svůj Pixel 10 Pro XL nainstaloval v podstatě hned druhý den po přijetí telefonu. Možnost vyzkoušet si zakladní OS přímo od Google jsem zde moc nevyužil, jelikož i přes vlastnictví nového telefonu (a s tím spojenym "WOW" efektem) jsem měl jasný záměr.

Nicméně musím dodat, že byl by nějaký závažnější problém s GrapheneOS, příručka, respektive postup pro instalaci "sériového" Androidu je velmi jednoduchá. V zásadě stačí upravený webový prohlížeč, USB kabel do počítače a trocha času. Je to tedy změna lehce zvrátitelná a dívám se tedy na GrapheneOS s "mentalitou" "Lze to vrátit, bude-li třeba".

Vedlejší efekt na předchozím telefonu

Ač jsem zmínil, že Pixel 10 Pro XL s GrapheneOS se stal hlavním "tažným koněm" mobilního života, otevřelo mi to možnost si "hrát" do té doby s "produkčním" telefonem od Xiaomi.

Měl jsem povědomí, že telefony od Xiaomi - nachází-li se na uzemí Evropské Unie - lze tzv. odemknout a nainstalovat jiný operační systém, v mem případě LineageOS / LOS. Je to forma AOSP, která v sobě nemá predinstalované aplikace od spolecnosti Google a i daného výrobce/návrháře. Jedná se tak o "De-Googled" software, místy i "de-bloated" systém.

Učinil jsem tak a telefon jsem začal užívat jako "záložní". Ač LineageOS podporu pro vypínání profilů nemá, Always-On VPN funkcionalita je zde také přitomna a lze ji užít podobným způsobem, jako na GrapheneOS.

Kdyz zmíním paradox, že Xiaomi Mi 11 Lite 5G po instalaci LineageOS "ožilo", nebudu daleko od pravdy. Pominu-li některé funkcionality řešitelné externě, telefon je plně funkční a stačilo by jej prodat s poznamkou "Toto nefunguje, je to záměr nikoliv můj, ale dodavatele systému".

Přislušenství k telefonum přidané

V kratkosti zde zminím i "obnovu" přislušenství pro oba přístroje. Puvodní, originální nabijecí adaptér pro Xiaomi postupně ztrácel na výkonu, rozhodl jsem se tedy - i s ohledem na pracovní Samsung Galaxy S25 - vyzkoušet si bezdrátové nabíjení, které jsem doteď neměl možnost využít.

Postupne volba padla na nejen GaN nabíjecí adaptér (vzhledem k dobrým referencím jsem užil "AlzaPower Ultímate X500 67W"), tak nabíjecí "puk" "AlzaPower WQT110" s podporou Qi2.

Jelikož jsem 3Dtiskař a 3Dmodelář, návrh a 3Dtisk stojánku přímo pro tento puk (zohledňuící proporce i slabší "MagSafe" u Samsungu Galaxy S25) byl logickym krokem.

Paradox s ohledem na bezpečnost aktualizovaného OS Android

Dostavám se tímto do poslední kapitoly, kde budu řešit a pokládat otázky, na které nejspíše nedostanu odpovědi.
Jakožto člověk IT-znalý (pro kontext, pracuji jako automation engineer, server administrator a on-call ve větší IT firmě) vnímám paradox, kdy výrobcem dodaný software má "certifikaci" pro určité funkce - v tomto případě třeba Google Wallet. Funkcionalitu Tap-n-Pay zde musím nahrazovat právě Garmin Pay.

Lze se na to i dívat z jiného úhlu pohledu, kdy platba hodinkami je paradoxně bezpečnější (NFC čip v hodinkách je jinak vypnut, zapíná se pouze, když uživatel funkci pro placení explicitně zapne v daný okamžik).

To platí jak pro GrapheneOS, tak pro LineageOS.

Telefony, obecně systémy (jak Android, tak i Debian, Arch Linux) se snažím držet v aktualním stavu a nezřídka si sám zajišťuji i aktualizace / opravy.

Otázka - kterou si kladu - je "Proc je alternativní systém jinak pravidelně aktualizovaný méně bezpečný, než zastaralý systém dodaný výrobcem, který nemá dalšího důvodu se o daný přistroj / hardware starat?"

Narážím tak na paradox, kdy i pravidelně aktualizovaný - ale necertifikovaný - software je bezpečnější, než jinak "certifikovaný" software od výrobce, který se rozhodl od určitého data aktualizace nedodavat. Pokud telefon nadále funguje, proč jeho funkcionalitu ořezávat, když by to samé mohl zvládat i dalších - dejme tomu - 5 let a tím tak ještě více "rozprostřít" náklady na iniciální pořízení?

Závěrem

GrapheneOS byl cílem snažení nejen o na to najít soukromí ve světě stále více a více připomínající 1984, ale také i tom, že jinak morálně zastaralé přístroje mají i nadále svůj důvod existovat.

Mým pohledem GrapheneOS - byť s určitými nedostatky, které jsem akceptoval - plní přesně to, co jsem od něj očekával, tedy nabídnout alespoň soukromí ve světě, kdy je každý krok monitorován.

Jako přidaným benefitem i nabídnout funkcionalitu, která by v roce rozmachu informačních technologií na začátku 21. stoleti mohla působit jako sci-fi - mít skoro plnohodnotný počítač ne v batohu, ale přímo v kapse.

Galerie

| Nabíjecí stojánek pro Qi2 wireless | "Dockovací" stanice s užitím 3Dtisku |
| | |

The post GrapheneOS, poznatky z užívání first appeared on Hard Wired.