Příspěvky

436

Sítě / Re:T-Mobile ADSL insider?

« kdy: 12. 04. 2017, 21:13:31 »

Neni to bitstream, ale sluzba od CETINu s predavacim bodem v Praze.

Prvni hop za modemem je BRAS (protoze se vyuziva PPPoE) v infrastrukture CETINu, casto az v krajskem meste. Neni tedy pravda, ze by cesta mezi modemem a prvnim hopem byla 300 m dratu a latenci to nabiralo na ni. Ve skutecnosti muze byt cesta dost dlouha. :-)

Latence na VDSL je kupodivu o dost vyssi nez byva(la) na ADSL, kde jsem obvykle dosahoval 8 ms mezi modemem (resp. PPPoE klientem) a BRASem. Na VDSL to je uz od spusteni 20 ms, nicmene treba se to v poslednich letech nejak zlepsilo. DSL neni optika, DSLAMy jsou pripojene optikou, ale zakaznici metalikou. Vykon DSLAMu muze latenci taky ovlivnit dost vyrazne.

S TM tohle nema cenu resit, v TM jde o dva hopy (prechod mezi infrastrukturou CETINu a ISP routerem exTSystems, kde se provoz predava, pak mezi routerem exTSystems a ISP routerem TM, a pak uz jsou na rade routery ostatnich provideru v NIXu, peeringu nebo tranzitu.

437

Software / Re:TrustedGrub, TPM a autoodemykání LUKS volume

« kdy: 21. 02. 2017, 22:03:38 »

Zakladatel sem zadny takovy link ("ze je to blbost") rozhodne nedaval. Je to bezpecne s tim, ze bezpecnost ma urcitou uroven. Ta se da ruznymi dalsimi opatrenimi zvysit (doplnujici/podpurne kontroly pro odemceni) i snizit (diry v konceptu).

438

Software / Re:TrustedGrub, TPM a autoodemykání LUKS volume

« kdy: 15. 02. 2017, 20:45:47 »

Neni zac :-)
Moc jsem tam toho nenaprogramoval a zatim je to porad spis alfaverze.
Nedavno jsem mel problem s UEFI na novem Dell XPS, pocital jinak hash pro PCR[5] a jeste jsem se nedostal k hlubsi analyze, jak (jen tusim). Takze pokud byste na to nekdo narazil, doporucuju vypnout sealing na PCR[5] v /etc/tpm-luks.conf.

EDIT: a taky se to nema uplne rado s disky jinde nez na /dev/sd* (tzn. treba /dev/vda prip. /dev/nvm*). Opet mam nejakou alfa opravu, ale hardware s NVMe diskem jsem vratil...

439

Distribuce / Re:Linux/Debian Kaby Lake

« kdy: 17. 01. 2017, 12:32:25 »

Pořídil jsem včera Kaby Lake (i7-7700T) a po výměně CPU zatím (nejspíš) všehchno běží.
Kernel si zahlásil, že mu chybí firmware pro grafiku i s odkazem, odkud jej stáhnout a se slovy, že disabluje runtime power management grafiky (URL pro firmware je https://01.org/linuxgraphics/intel-linux-graphics-firmwares).
Virtuály přes KVM/QEMU běží bez problémů. Aplikace aplikují.

Kernel 4.8.0. Sice provozuju Ubuntu, ale to by snad tolik původního autora otázky nemuselo trápit. :-)
Osobně asi pro Kaby Lake můžu "co-nejnovější-kernel" jen doporučit. (Večer plánuju upgrade na 4.9.)

440

Windows a jiné systémy / Re:Android a IPv6

« kdy: 11. 01. 2017, 19:57:11 »

Jeste je tu moznost, ze tazatel ma pripojeni od O2 bez verejne adresy a na tehle siti Arduino. Ted se chce pripojovat na to Arduino (zvenku pres mobilni sit? Protoze domaci sit i v pripade NATovane pripojky stale je k dispozici) z Androidu a zajima ho, jak na to.
Kazdopadne potrebujeme vic informaci.

441

Sítě / Re:Levné SIM karty pro IoT

« kdy: 03. 01. 2017, 12:56:38 »

Nulový tarif na míru od VF není úplně ideálním řešením, protože:
1. se těžko získává (není oficiálně v nabídce)
2. oficiálně neumožňuje účtování po kB (jde k němu aktivovat Připojení na den, Na týden a Flexidata, příp. balíčky 500+ MB; nic z toho není vhodné pro přenos do 10 MB měsíčně); neoficiálně by možná účtování po kB aktivovat šlo (zkuste otravovat VF infolinku)
3. účtování po kB už ani není v ceníku, takže těžko říct, kolik si účtují dneska, ale kdysi dávno stával kilobyte tuším 0,06 Kč. To je 614,4 Kč za 10 MB.

Docela drahá sranda.

442

Software / Re:TrustedGrub, TPM a autoodemykání LUKS volume

« kdy: 23. 12. 2016, 18:04:37 »

Cold boot nebo zneuziti DMA pomoci firewire a pod. jsou utoky, proti kterym pomuze jen uplne jina uroven zabezpeceni.

443

Software / Re:TrustedGrub, TPM a autoodemykání LUKS volume

« kdy: 23. 12. 2016, 08:06:12 »

S tim sniffovanim je to hodne teoreticky utok. Praktickou realizaci se mi najit nepodarilo, takze bud to nikdo neumi, nebo je to tak slozity, ze to nikdo nedela. (Tady muzou byt tezsi a lehci realizace v zavislosti na tom, kde je TPM - krome samostatnyho odpojitelnyho modulu, mezi kterej a desku muzes zapojit relativne univerzalni odposlouchavaci elektroniku, muze byt tekzy az nerealizovatelny delat odposlech u TPM napajenyho na desce, a pak prakticky nemozny u firmwareTPM, ktery jsou soucasti Intel TXT a TPM je tudiz v procesoru.)
Neco malo materialu k utokum, ovsem bez dukazu, ze z toho nekomu tecou data v podobe, ktera by byla citelna:
https://online.tugraz.at/tug_online/voe_main2.getvolltext?pCurrPk=59565
https://securingtomorrow.mcafee.com/business/security-connected/tpm-undressed/

444

Software / Re:TrustedGrub, TPM a autoodemykání LUKS volume

« kdy: 23. 12. 2016, 00:27:57 »

Stejne jako u Windows je i tohle reseni jen omezene bezpecne. :-) Microsofti k tomu maji pekny diagram na https://technet.microsoft.com/en-us/library/ee706531(v=ws.10).aspx.

Zjednodusene:
1) je to samozrejme nachylne na cold boot attack a tam, kde jsou dost citliva data, je tohle pouziti samozrejme nedostacujici. Paranoici necht zustanou u rucniho zadavani hesla a duvere v to, ze jim dabelska pokojska nepodvrhla initrd.
2) Dal se da TPM teoreticky odposlechnout (je pripojen pres LPC https://en.m.wikipedia.org/wiki/Low_Pin_Count). To se dela hur tam, kde je TPM primo na desce, ale jinak data poputuji po sbernici v cleartextu.
3) Je treba pohlidat, aby pouzivany initrd neskoncil NIKDY v shellu. Proc? No, pokud napr. prepisu LUKS header docasne nulami, selze odemykani. V takovem pripade by me system hodil do shellu, ve kterem si muzu data z tpm vycist. Debiani initramdisky v pripade, ze je kernelu pridan parametr panic=X, rovnou rebootuji a heslo k disku tak neni ohrozeno.
4) V bezicim systemu je treba provest alespon zakladni zabezpeceni (bezny uzivatel nesmi mit moznost cist data z NVRAM TPM; do systemu se nesmi prihlasit guest; a pod.)
5) Sitove sluzby toho taky muzou dost prozradit a dost dat vydat. Nabizi se moznost provest lockdown v okamziku, kdy bude system nabootovan na miste, ktere nebudu znat.

445

Hardware / Re:Je TPM bezpečné? Jak ho bezpečně používat?

« kdy: 23. 12. 2016, 00:10:31 »

Windows si klic z TPM netahaji. Bitlocker funguje v principu takhle:
Disk je zasifrovan klicem pro full disk encryption. Tenhle klic je ulozen na disku a je zasifrovan tzv. Master klicem. Pristup k Master klici hlidaji protectors (jimi je pristup k master klici sifrovan): temi muze byt ciselne heslo (recovery key), usb flashka, tpm+pin, tpm, pripadne tpm+pin+flashka.
Kdyz se pouziva tpm, pozadaji windows o zasifrovani "tpm protectoru" pri "definovanem stavu systemu" tpmkem.
Odemykani pak funguje tak, ze tpm desifruje tento protector key jen tehdy, je-li system opet v predem definovanem stavu. Stav meni i vyber jine polozky z menu bootmanageru. Pokud system neni v definovanem stavu, tom nedesifruje korektne protector key a windows si vyzadaji recovery key od uzivatele, kterym pak odemknou master key a ten odemkne full volume encryption key.

V Linuxu existuje par pokusu o rozchozeni jednodussi varianty desifrovani, ktera se bude chovat podobne jako Bitlocker (tedy za definovaneho stavu odemkne disk). Vetsina z nich je vsak bohuzel uzivatelsky neprivetiva (kompilace) nebo nefunkcni (neaktualni software, nutnost prepsani). Kombinaci TPM+PIN jsem na Linuxu jeste nevidel, podobne TPM+PIN+UsbKey.

Taky mi ale neni uplne jasne, jakou predstavu o cilovem stavu ma puvodni pisatel.

446

Software / Re:TrustedGrub, TPM a autoodemykání LUKS volume

« kdy: 22. 12. 2016, 23:32:27 »

Tak tu mame prvni balicky dostupny pres PPA. Zatim pro Ubuntu 16.10 a 17.04.
Grub2 (i pro UEFI) s podporou TPM a sada skriptu a nastroju pro automatizaci nasazeni jsou na https://launchpad.net/~radek-zajic/+archive/ubuntu/measuredluks

Zatim bez dokumentace. :-)

447

Bazar / Re:Prodám DELL Optiplex 980

« kdy: 12. 12. 2016, 21:32:28 »

Nabizim 1000 Kc.

448

Software / Re:TrustedGrub, TPM a autoodemykání LUKS volume

« kdy: 29. 11. 2016, 23:24:54 »

Kdyby tam žádné šifrování nebylo, tak kdokoli nabootuje livecd (po vymazání hesla v BIOSu resetem CMOS) a k datům se dostane.
Kdyby byl klíč k LUKSu uložen na připojené flashce, tak jej dokáže kdokoli se schopností "číst v initramdisku" zkopírovat, disk si odemknout a k datům se dostat. Podobně (hůř) kdyby byl klíč přímo v initramdisku.

Rozdíl je v tom, že z TPM dostanete data jen tehdy, když bude systém v předem definovaném stavu. A to platí pro BIOS, kompletní zavaděč, linuxové jádro, initramdisk a cmdline.

Změna jakéhokoli byte v kterékoli fázi bootu způsobí odchylku od definovaného stavu a TPM klíč k odšifrování disku nevydá.

Oddíl s LUKSem má víc keyslotů a v jednom z nich je i dlouhé a složité heslo pro recovery, pokud by došlo k poškození TPM nebo rozbití "definovaného stavu systému".

449

Software / Re:TrustedGrub, TPM a autoodemykání LUKS volume

« kdy: 29. 11. 2016, 22:20:30 »

Cilem je full disk encryption na masine, ke ktere potencialne muze mit pristup dost lidi vcetne uklizecek (stroj pobezi v praci) a automaticke odemykani disku, aniz by klic mohl kdokoli vzit a disk si odemknout.
Roli samozrejme hraje i pohodli (automaticke odemceni disku bez nutnosti zadavani dlouheho hesla).

Pokud se k datum v pocitaci nekdo pokusi pristoupit, musel by zajistit pritomnost spravneho bootloaderu (hashe MBR a celeho grubu musi sedet), kernelu, initrd (hashe museji sedet) a kernelove cmdline (opet musi sedet hash).

Uplne jinou kapitolou je nastaveni systemu tak, aby se k datum v PC nikdo nedostal pomoci klavesnice, monitoru a dalsich periferii, pripadne po siti, v okamziku, kdy je uspesne nabootovano. :-)

450

Software / Re:TrustedGrub, TPM a autoodemykání LUKS volume

« kdy: 29. 11. 2016, 00:15:47 »

OK, takze to funguje a docela dobre.
TrustedGrub2 po opatchovani poslusne plni PCR registry sha1 hashem cmdline, vmlinuz a initrd
Luks-tpm po opatchovani funguje dobre s trousers, umi si brat hesla (TPM owner a TPM NVRAM) ze souboru s hesly
Dalsi skripty vycitaji hodnoty z TPM pri bootu a pokud narazi na takovou ulozenou hodnotu, ktera je overena v aktualnim PCR prostredi, tak ji pouzijou pro luksOpen

Jeste mi chybi doplnit do tpm-luks podporu pro checksum trustedgrub2, ale i bez tehle kontroly se pouzity pristup ukazuje jako funkcni...

Co s tim ovsem pak? Udelat fork vsech patricnych nastroju na githubu, udelat patche oproti aktualnim verzim, nebo z toho udelat *.deb baliky, ktere pujdou nejak rozumne nainstalovat?

Napsat clanek na root?