Přesně tak - tak to vyznívá i ze stránek yubico...
Mám jeden Yubico 5 NFC (USB-A) firmware 5.4.3 :-(.
Asi půjde pryč - a budu muset zvolit rozumnější zařízení - pokud existuje varianta, protože defacto kvůli novému firmwaru kupovat nový klíč se mi opravdu nechce.
Pokud má někdo tip na alternativu - prosím sem s ním. Předem díky....
Dobrý den,
pokud používáte z tokenu FIDO2 funkcionalitu v módu bez PINu, obrana je nastavit si PIN.
Pokud využíváte jiné moduly (PIV, OpenPGP) a v nich spoléháte na ECDSA, obrana je přejít na RSA - https://support.yubico.com/hc/en-us/articles/15705749884444-Infineon-ECDSA-Private-Key-Recovery-Customer-Resources
Útok není vůbec triviální (viz ninjalab report), útočník musí mít excelentní znalosti, vybavení a nenávratně poškodí token (zejména v případě Y5NFC a Y5CNFC). Tím situaci nijak nezlehčuji, ale rozhodně to není důvod k zahození tokenu (či dokonce návratu k obyčejným heslům), jak z některých diskuzí vyplývá.
Stačí aplikovat výše navrhované a i tento laboratorní útok bude pro vás rázem irelevantní.
Zajimavy je, ze se nikde nevyjadruji k EdDSA, ale vsude se mluvi a pise jen o ECDSA. Coz se muze jevit jako totez, ale totez to neni, i kdyz se to velmi rado zamenuje. A ono i minulost uz pamatuje pripad, kdy se prave EdDSA v case "vyjmulo" z tvrzeni o zranitelnosti, i kdyz tam puvodne bylo take.. a zustalo se ciste jen u zranitelne implementace ECDSA.
u HSM se ale upgraduje ta část okolo a ne ta, která se stará o šifrování. Víš o nějakém, kde to je jinak?
Důvod je zabezpečení dodavatelského řetězce, aby se ti nestalo, že se objeví tokeny, které budou záměrně obsahovat chybný FW. Poté viz i tenhle report, ani útočník v laboratoři nemůže snadno změnit SW na read-only paměti a musí dělat husarské kousky, aby se do toho dostal.
Sice mě to krátce prošlo pod rukama před víc než dekádou, ale tak třeba tohle nevypadá jen na upgrade věcí okolo https://thalesdocs.com/gphsm/luna/7/docs/network/Content/admin_hsm/updates/upgrade.htm (firmware part.)
A třeba i backup proces je dost poučné čtení https://thalesdocs.com/gphsm/luna/7/docs/network/Content/admin_cluster/cluster_backup_restore.htm - existuje bezpečný proces, jak klíče zmigrovat na nové zařízení.
S tím dodavatelským řetězcem it depends, pokud člověk nemá důvěru u podobné hračky v (certifikovaný a) podepsaný updatnutý firmware, tak ze stejného důvodu by nemusel mít důvěru ani v ten původní. Navíc procesně se upgrady bez vážného důvodů (vulnerabilita/chyba) obvykle nedělají.
Naopak, flashnuti ti umozni naprosto kazde jedno svepravne zarizeni. A jak tu zaznelo, dela se to pochopitelne pouze v pripade jako je treba tento = je objeven nejaky security problem.
Stejne tak se daji klice prenaset mezi vice krabicemi, protoze se kupodivu predpoklada, ze ta krabice muze chcipnout. A ono se kupodivu nikomu moc nechce obihat treba mililardu zarizeni a vymenovat v nich CA cert. Protoze presne v okamzeni kdyby ti neco takoveho chciplo bys tohle musel udelat ... pekne rucne.
A nemusime mluvit ani o zadne uberkrabici, staci kdyz si predstavis, ze mas 10k zamestnancu a kazdy ma token. Neco takoveho vazne nechces 5x rocne kompletne vymenovat.
A soucasne proces flashnuti sam o sobe proste moznym vektorem utoku je, jak uz mate napsano vyse. Takze i nemoznost zarizeni flashnout je moznym a casto uzivanym zpusobem obrany. A samozrejme jednim ze vstupnich pozadavku je i to, aby privatni klic proste vykopirovat (tzn. naklonovat) nesel. Takze kritizujete vlastnosti, ktere jsou ale vstupnimi pozadavky.
A samozrejme, pokud dojde ke skutecne kompromitaci, tak ty klice proste vymenite, stejne jako musite zmenit heslo - pokud fakt nekde utece. Coz ale neni pripad nutne ted u YK - jsou popsane zpusoby, jak rizika v podstate eliminovat k nule. A to, co vy sam tady kritizujete jako nejakou chybu zarizeni (nemoznost prenest - vykopirovat privatni klic) je ve skutecnosti samotny vektor utoku - tedy samotna podstata vady - to, ze za urcitych specifickych okolnosti ten klic vykopirovat ven jde, i kdyz by nemel jit. Akorat to taky jaksi neudelate tak, ze by si od vas nekdo na pet minut nepozorovane pujcil ten token, ze?
Z principu na žádném z těchto ultrabezpečných pokladů nelze FW upgradovat.
To není tak úplně pravda, např. Nitrokey 3 s možností updatu firmware počítá (je ovšem otázka, kdy (jestli vůbec někdy) bude plně funkční). A asi nebude jediný. Háček je ale v tom, že možnost updatu firmware v podstatě vylučuje získání certifikace od FIDO Aliance. A pro některá využití, např. přihlášení do Identity občana (nebo jak zrovna dneska zní oficiální název) přes MojeID je tahle certifikace podmínkou.
Takže chudák uživatel si bohužel musí vybrat: buď bude mít token, který má open source firmware s možností updatu, aby ho při nalezení bezpečnostní chyby nemusel vyhodit, nebo bude mít token, který je "bezpečný" z pohledu certifikace, a tedy i institucí, které na certifikace slepě věří - a pak ho po nalezení bezpečnostní chyby může použít tak akorát jako cool klíčenku. :-(
Ono je to logické, protože ty certifikace (mimo jiné) ověřují, že nejde z daného zařízení žádným rozumným způsobem získat privátní klíč. No a pokud chyba ve firmware může znamenat únik privátního klíče, znamená to, že firmware má přístup k privátnímu klíči a „aktualizovaný“ (podvržený) firmware by tedy mohl privátní klíče ukrást.
Dalo by se to obejít tím, že by aktualizace firmware byla chráněná tak, aby ji mohl provést jen oprávněný uživatel (třeba zadáním PUK), jenže udělat to tak, aby to nešlo obejít, by nebylo jednoduché (v podstatě by to znamenalo mít dvě úrovně firmwaru, což může dávat smysl pro HSM, ale ne pro tokeny za pár drobných).
No a pokud chyba ve firmware může znamenat únik privátního klíče, znamená to, že firmware má přístup k privátnímu klíči a „aktualizovaný“ (podvržený) firmware by tedy mohl privátní klíče ukrást.
...což se právě stalo. U tokenu, který má certifikaci a nemá updatovatelný firmware, takže ani žádný podvržený firmware nebyl potřeba. Tolik k té logice.
Stalo se to, ale je to považováno za chybu, tj. je nežádoucí, aby to bylo trvale.
Jenže to ukazuje, že ani slavná certifikace, na které se tolik bazíruje, ve skutečnosti nezaručuje vůbec nic. Navíc nic nebrání tomu, aby certifikace byla vázána na konkrétní verzi firmware (což je i tak) a firmware byl přesto upgradovatelný. Je to jen předsudek, že firmware "vytesaný do kamene" je a priori bezpečnější.
Navíc se nabízí i další kacířská otázka: co teď vlastně bude? Ztratí teď Yubikey 5 s FW < 5.7.1 certifikaci? Pak se pro velkou část uživatelů stanou bezcennými a pro další bude jejich použitelnost značně omezená, a bude se to týkat i těch, kdo používali výhradně RSA. Nebo zůstane certifikace zachována a budeme si říkat "jo, ten je bezpečný, je na seznamu", a to i tam, kde bude chyba zneužitelná? Ani jedna varianta není moc povzbudivá.
Jenže to ukazuje, že ani slavná certifikace, na které se tolik bazíruje, ve skutečnosti nezaručuje vůbec nic.
Bezpečnost není ano/ne. Je to větší či menší bezpečnost. Certifikace zaručuje vyšší bezpečnost.
Navíc nic nebrání tomu, aby certifikace byla vázána na konkrétní verzi firmware (což je i tak) a firmware byl přesto upgradovatelný.
To by ovšem vyžadovalo, aby upgrade firmware vždy začal bezpečným smazáním klíčů. A jak jsem už psal, to by znamenalo nějaký víceúrovňový firmware, což asi není něco pro levné tokeny.