pico-usb-wifi je open source firmware pro Raspberry Pi Pico W, který jej promění v USB Wi-Fi adaptér. Po připojení k počítači se objeví jako zařízení USB CDC-NCM.
Americká společnost Google ze skupiny Alphabet bude muset podle nových požadavků Evropské unie umožnit společnosti OpenAI i dalším konkurentům v oblasti umělé inteligence (AI) a internetových vyhledávačů přístup ke svým službám. Ve svém rozhodnutí o tom včera informovala Evropská komise (EK). Opatření má zajistit dodržování pravidel, jejichž cílem je omezit v EU tržní sílu velkých technologických firem. Google s tím nesouhlasí.
… více »Nové verze webových prohlížečů Chrome a Firefox jsou vydávány každé 4 týdny. Aktuální verze Chrome je 150. Aktuální verze Firefoxu je 152. V březnu bylo oznámeno, že od září přejde Chrome na dvoutýdenní cyklus vydávání verzí. To by znamenalo, že Chrome v číslování verzí Firefox brzy přeskočí. Vývojáři Firefoxu proto také od září přecházejí na dvoutýdenní cyklus vydávání verzí. :-)
Microsoft Comic Chat (Wikipedie), tj. grafický IRC klient z devadesátek, který převáděl konverzace na IRC do podoby komiksových panelů, a který zpopularizoval font Comic Sans, je dnešním dnem open source. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT.
Byla vydána (𝕏) nová verze 26.7 open source firewallové a routovací platformy OPNsense (Wikipedie). Jedná se o fork pfSense postavený na FreeBSD. Kódový název OPNsense 26.7 je Xenial Xenops. Přehled novinek v příspěvku na fóru.
Na Seznam nepovolených internetových her (Wikipedie) se k 13. 7. 2026 dostala predikční platforma Polymarket.
Nová čísla časopisů od nakladatelství Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 167 (pdf) a Hello World 30 (pdf).
Byla vydána nová verze 3.22.0 grafického vývojového prostředí a platformy Gambas (Wikipedie) založené na interpretru programovacího jazyka Basic s rozšířením o objektově orientované programování. Přehled novinek v poznámkách k vydání. Zdrojové kódy jsou k dispozici na GitLabu.
FreeBSD odstranilo poslední GPL kód ze základního systému. Konkrétně dpv, libdpv, libfigpar a dialog. Instalátor před čtyřmi lety přešel z dialogu na bsddialog.
Sociální síti 𝕏 (dříve Twitter) má dnes 20 let. Pro veřejnost byla zpřístupněna 15. července 2006.
Omezit počet přihlášení umí kdejaká čipová karta. Na to TPM netřeba.
Síla TPM je v tom, že má vlastní sériové číslo a vlastní tajný klíč. Klíč nelze přečíst, jen vygenerovat či zapsat. Kombinací těchto dvou hodnot vzniká jedinečný a nereplikovatelný iniciační vektor pro hashovací funkci. Ta potom řetězově hashuje spouštěný kód (firmware, zavadeč, jádro, initram disk atd.), čímž v kterékoliv fázi startu systému máme otisk kódu, který byl až dosud vykonán. Tento otisk pak funguje jako důkaz, že systém je v požadovaném (= nenapadnutém) stavu.
Když budete otisk držet v tajnosti, tak ho můžete použít jako heslo pro rozšifrování blokového zařízení.
Nebo můžete využít další funkci TPM, a to že na hodnotu otisku navážete vydání dalšího soukromého klíče z TPM. A blokové zařízení dešifrovat až tímto dalším soukromým klíčem.
Příště by to chtělo méně arogance a více studia.
To by mohlo fungovat, budou-li tím klíčem šifrovány všechny klíčové části systému, které nejsou hashovány (v opačném případě vyndám kartu, upravím na ní třeba /etc/passwd, vrátím, naloguji se jako root, vytáhnu klíč z RAM, a TPM mě už nezajímá).
Ano. Klasický postup je mít vše kromě jádra a initramdisku v šifrovaném blokovém zařízení a v něm LVM a v něm všechny souborové a swapovací systémy. Tohle umožňuje zajistit integritu i utajení.
Jiný postup je, když stačí integrita. Pak místo šifrování se použije IMA na veškerý kód (jaderné moduly, spustitelné programy a dynamické knihovny) nebo i data (konfigurační soubory). V podstatě se posbírají otisky všech souborů a proženou se TPM. Při přístupu k souborům se pak kontroluje, že se jejich otisk nezměnil.
Tedy pořád zbývají útoky na běžící systém, ale ty jsou těžší.
Samozřejmě. Před chybou v ověřeném kódu (jako když na Mac OS stačilo dvakrát zadat prázdné heslo pro roota) vás neochrání nic.
Ale tohle bude fungovat jen se secure bootem. Pokud by systém nabootoval jakoukoliv kartu, půjde tam dát program co tím TPM hashem prožene FW plus původní bootloader/kernel/initrd, a vytáhne soukromý klíč k těm datům.
Nikoliv. Když systém nabootuje z jiné karty, tak se do TPM pošle jiný obsah zavaděče atd. a tudíž hash bude jiný.
Je třeba si uvědomit, že do TPM se posílá kód, který teprve bude spuštěn, a posílá jej tam kód, který již byl takto do TPM odeslán. Čili aby kód mohl podvádět (posílat do TPM jiný obsah, než který hodlá spustit), musel by se takový kód lišit od původního poctivého kódu. Jenže pokud takový kód běží, znamená to, že jeho odlišnost již změnila otisk v TPM ještě před tím, než nepoctivý kód byl spuštěn a mohl začít podvádět.
To samozřejmě přináší otázku, jak je to s úplně prvním kódem, který se posílá do TPM. Tedy s firmware. Správná implementace je, že při zapnutí počítače existuje neměnitelný kód (v ROM), který nejprve odešle obsah firmware do TPM a pak teprve spustí firmware.
Secure boot má podobný ale horší problém: Kdo ověřuje podpis firmwaru a jak má vědět, že kořenový klíč nebyl podvržen? Vzhledem k tomu, že kořenový klíč je možné importovat, obávám se, že secure boot je ve skutečnosti velká habaďůra. Je ještě možnost, že secure boot má dva kořenové klíče. Jeden importovatelný uživatelem a jeden neměnný. Ten neměnný se použije právě pro ověřený firmwaru. Jenže když jsou dva nezávislé kořeny, tak mezi nimi nemůže existovat důvěra a tudíž secure boot opět stojí na vodě. Aby secure boot byl důvěryhodný, kořenový klíč by musel být jen jeden a neměnitelný a nesměl by být vypnutelný.
BIOS je dneska software jako každý jiný. Velký, modulární, plný chyb a aktualizovatelný. Samozřejmě že ověřování sám sebou není bezpečné.
Bezpečná metoda je mít neměnitelný zavaděč BIOSu. Protože jej nelze měnit, můžeme mu věřit. Ten může poslat BIOS do TPM, či může ověřit jeho podpis proti klíči, který má neměnitelný kód v sobě.
Takový neměnitelný kód opravdu existuje a používá se pro spuštění částí BIOSu, které inicializují plně procesor a chipset. Nicméně zdá se, že výrobci jej nepoužívají jako kořen důvěry.
Třeba IBM v OpenPower strojích má v secure boot dva kořenové klíče. Jedním ověřuje firmware a druhý si může uživatel změnit pro ověření operačního systému. Kořenové klíče jsou uloženy v paměti, do které lze nové kořenové klíče nahrát pouze skrze běžící firmware, který si již vynutí, aby nový firmwarový kořen byl podepsán starým kořenem (zrovna tak jako aktualizace firmwaru). (A uživatelský kořen pouze po předložení hesla, jehož otisk je pravděpodobně uložen v téže paměti). Čili se vychází z předpokladu, že první firmware neobsahuje žádnou bezpečnostní chybu. (Nějak takto byla zabezpečena PlayStation proti instalaci Linuxu a nějak tak si Microsoft představoval secure boot na zábavní technice s armovými procesory.)
Ve světě PC UEFI se TPM zapíná až ve fázi Pre EFI Inicialization. Sice UEFI se do TPM pošle celé, ale ten první neměnný kód, který provádí předešlou Security fázi, to nedělá. Asi se vsází na stejnou kartu jako u OpenPower – že UEFI lze aktualizovat jen z běžícího UEFI.
Přijde mi to docela smutné, protože dobře udělané TPM umožňuje ochránit systém před off-line útokem. Secure boot to nedokáže, protože stačí restovat heslo do setupu, což standardní podporovaná operace.
11.12.2017 21:12
pVit | skóre: 11
9.12.2017 18:23
k3dAR | skóre: 63
11.12.2017 21:08
pVit | skóre: 11
(Vypadá to na nejspolehlivější způsob)
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz