TCP bezpečnost

[_Jenda]

Tohodle bych se nebal, protoze vlastni komunikacni protokol ma svuj pevne dany format a na konci je CRC soucet. Kdyz uz by nahodou kod prosel pres startovni sekvenci CRCcko ho urcite zastavi.

Jako že útočníka nenapadne, že by na konci mohlo být CRC a nevyzkouší všechny polynomy až mu nějaký vyjde? A to ani když zařízení fyzicky dostane, vytáhne z něj firmware a disassembluje ho? https://en.wikipedia.org/wiki/Security_through_obscurity

Popravde receno utajit je nepotrebuju, ale nesmi byt zmeneny. Jak nad tim ale premejslim tak moc nedokazu pochopit co se bude dit, kdyz utocnik zachyti dva zasifrovane ramce. Jeden bude znamenat napr. odemkni dvere a druhy zamkni dvere. Pokud jsou to platne ramce a utocnik je bude stridave odesilat, tak je zarizeni musi preci nutne vyhodnotit jako spravne. Nenapada me mechanismus jak by se dalo zajistit aby to zarizeni odmitlo pozadavek. Mozna mi stale neco unika...nebylo by to naposled

Tomu se říká replay a taky jsem o něm mluvil… Buď můžeš použít sekvenční čísla, nebo na začátku vždycky proběhne handshake, do kterého oba konce vloží nějakou náhodu.

Bezpecny protokol ani zarizeni neexistuje - sebevic se budete snazit, vzdy existuje vice ci mene slozita cesta, jak jakoukoliv ochranu ktera je obalkou zakladni funkcionality obejit (viz CD, copy protection, hry, sw a pod).

Ano, tohle jsme tu přesně potřebovali. Až na to, že a) tohle jsou úplně jiné případy (kdy se snažíš zabránit v úniku dat ze zařízení, které má útočník fyzicky v ruce; my řešíme síťovou bezpečnost), b) je úplně jiný level „Jenda udělá MITM na deset řádků Pythonu“ a „jó, teoreticky by někdo mohl cracknout AES!“.

I kdyby jste pouzili sebelepsi asymetricke krypto pro podepisovani dat, tak prvni co utocnika napadne je vydolovat klic z fyzickeho zarizeni.

To předpokládám, že v jeho use-case nevadí (e.g. pokud se útočník dostal fyzicky k zařízení, může si už dělat co chce).

[Reklama]

[RDa]

Šel bych na to úplně jinak. Na server, který jak říkáš má veřejnou IP nainstalovat OpenVPN nebo  WireGuard. Pokud je to Linux, tak jsi šťastný člověk :_)
Na klientovi pak jen oVPN klienta a hotovo a nepotřebuješ to dávat ani na routery.

Tohle je velice marne reseni. Kdokoliv kdo ma pristup k HW pak ziska pristup - samozrejme ze to odstini 99% nahodnych utoku, ale to 1%, ktere zajima nejaky pozitivni prinost z cracknuti autorovy site si holt nejakou jeho krabicku k analyze/zneuziti sezene :)

[_Jenda]

Šel bych na to úplně jinak. Na server, který jak říkáš má veřejnou IP nainstalovat OpenVPN nebo  WireGuard. Pokud je to Linux, tak jsi šťastný člověk :_)
Na klientovi pak jen oVPN klienta a hotovo a nepotřebuješ to dávat ani na routery.

Tohle je velice marne reseni. Kdokoliv kdo ma pristup k HW pak ziska pristup - samozrejme ze to odstini 99% nahodnych utoku, ale to 1%, ktere zajima nejaky pozitivni prinost z cracknuti autorovy site si holt nejakou jeho krabicku k analyze/zneuziti sezene

A v čem je teda přesně problém když tohle někdo udělá? Samozřejmě nepředpokládám (i když podle úrovně dotazů…) že by měl autor globální klíče.

[hazardrok]

Citace: hazardrok  Dnes v 21:01:04
Tohodle bych se nebal, protoze vlastni komunikacni protokol ma svuj pevne dany format a na konci je CRC soucet. Kdyz uz by nahodou kod prosel pres startovni sekvenci CRCcko ho urcite zastavi.
Jako že útočníka nenapadne, že by na konci mohlo být CRC a nevyzkouší všechny polynomy až mu nějaký vyjde? A to ani když zařízení fyzicky dostane, vytáhne z něj firmware a disassembluje ho? https://en.wikipedia.org/wiki/Security_through_obscurity

Tohle trosku mi vypadlo z kontextu viz toto:

Další věc – šifrování zajišťuje to, aby nikdo cizí data neviděl, ale nezajišťuje, že je nemůže měnit (integritu dat). Pokud někdo přepíše zašifrovaná data, na výstupu (po rozšifrování) asi dostanete nesmysly, ale nemáte to jak zjistit, že to někdo změnil.

Prepokladam, ze pokud utocnik nema moznost data desifrovat/zmenit/zasifrovat, ale umi jen narusit integritu dat tak po vlastnim desifrovani z nich musi byt rozsypany caj. V ten moment je dost nepravdepodobny, aby data mela platnou startovni sekvenci, ukoncovaci sekvenci a jeste ke vsemu platne CRC...je to pozicne dane

[Filip Jirsák]

I kdyby jste pouzili sebelepsi asymetricke krypto pro podepisovani dat, tak prvni co utocnika napadne je vydolovat klic z fyzickeho zarizeni.

To je právě výhoda asymetrické kryptografie. Že privátní klíč pro podepisování bude jenom na serveru. U něj předpokládám, že je bezpečný.

Pokud by byl podpis založený na symetrickém klíči (kvůli jednodušší implementaci), bude to symetrická kryptografie. V takovém případě by útočník mohl získat klíč z klienta. Ovšem stejně by bylo možné mít jiný klíč pro každého klienta – no a pokud někdo má fyzicky v ruce to klientské zařízení, asi nebude pro jeho ovládání potřebovat ten server. Takže únik klíče v takovém případě nebude problém.

Zminilo se tady, co je to vubec za aplikaci, co potrebuje vyresit nejakou ochranu? Protoze urcity bezpecnostni kompromis lze najit na te aplikacni urovni, a realna aplikace by spis mela umet identifikovat narusitele a ochranu pak zalozit na ponekud vyssi urovni (je to srovnatelny se spamem - neco nezachytite, neco zbytecne zahodite.. dokonalost neexistuje).

Pokud to zařízení nemá dost prostředků na implementaci TLS, asi nebude mít prostředky na takovouhle sofistikovanou ochranu. Navíc u jednotlivých příkazů takováhle ochrana asi nebude k ničemu. Pokud to zařízení má něco otvírat a zavírat, asi byste nechtěl, aby to bylo bylo tak „spolehlivé“, jako detekce spamu.

[Reklama]

[Filip Jirsák]

Prepokladam, ze pokud utocnik nema moznost data desifrovat/zmenit/zasifrovat, ale umi jen narusit integritu dat tak po vlastnim desifrovani z nich musi byt rozsypany caj. V ten moment je dost nepravdepodobny, aby data mela platnou startovni sekvenci, ukoncovaci sekvenci a jeste ke vsemu platne CRC...je to pozicne dane

Ano, v ideálním případě (ideální šifra, ideální implementace) z toho v takovém případě vypadnou náhodná data. Já v tom v tuto chvíli žádnou možnost pro útok nevidím, ale tohle je přesně ten typ situace, ve kterých se často objevují útoky postranním kanálem. Váš případ asi nebude tak kritický, abyste to musel řešit, každopádně by to chtělo pak projít celý návrh, jestli tam není nějaká díra.

[RDa]

I kdyby jste pouzili sebelepsi asymetricke krypto pro podepisovani dat, tak prvni co utocnika napadne je vydolovat klic z fyzickeho zarizeni.

To je právě výhoda asymetrické kryptografie. Že privátní klíč pro podepisování bude jenom na serveru. U něj předpokládám, že je bezpečný.

Jak si predstavujete podepisovani dat odesilanych ze zarizeni na server, klicem, ktery je "bezpecne" na serveru?

Utocnikovi se v pripade asymetricke krypto se postaci zmocnit jedne strany spojeni/systemu, a druha ho bude poslouchat na slovo.
A je zcela jedno, kdo drzi verejny a kdo privatni klic - mate jeden, mate nad-vladu nad protistranou.

V pripade symetricke krypto se to zjednodusuje o to, ze klic je stejne a muzete ho ziskat od kterekoliv strany.

[_Jenda]

Prepokladam, ze pokud utocnik nema moznost data desifrovat/zmenit/zasifrovat, ale umi jen narusit integritu dat tak po vlastnim desifrovani z nich musi byt rozsypany caj. V ten moment je dost nepravdepodobny, aby data mela platnou startovni sekvenci, ukoncovaci sekvenci a jeste ke vsemu platne CRC...je to pozicne dane

Na tohle jako fakt nespoléhej. Například pokud je zpráva známá (například posíláš na všechna zařízení stejnou zprávu s nějakým globálním updatem, nebo posíláš jednou za čas „keepalive“ zprávu), tak ji vyxorujeme s odchyceným ciphertextem, dostaneme keystream, a už můžeme posílat cokoli chceme. Dále bych se fakt nedivil, kdyby existoval způsob, jak flipovat bity tak aby se tím pak i CRC opravilo. A dále „startovni sekvenci, ukoncovaci sekvenci“ - tohle bude konstantní pro všechny zprávy, že. A dále „je to pozicne dane“ - no právě, a díky tomu když můžu dělat bitflipy na dané pozici, tak vím přesně, co měním. A dále: stejně jako je na tom cryptopals "cbc padding oracle attack", tak tímto způsobem můžeš nejspíš hádat i CRC.

Nechápu jak jsi přišel na „tak po vlastnim desifrovani z nich musi byt rozsypany caj“, celou dobu se ti snažím říct, že běžné jednoduché módy šifer umožňují cílené bitflipy nebo myslím i transplantace bloků.

[RDa]

Šel bych na to úplně jinak. Na server, který jak říkáš má veřejnou IP nainstalovat OpenVPN nebo  WireGuard. Pokud je to Linux, tak jsi šťastný člověk :_)
Na klientovi pak jen oVPN klienta a hotovo a nepotřebuješ to dávat ani na routery.

Tohle je velice marne reseni. Kdokoliv kdo ma pristup k HW pak ziska pristup - samozrejme ze to odstini 99% nahodnych utoku, ale to 1%, ktere zajima nejaky pozitivni prinost z cracknuti autorovy site si holt nejakou jeho krabicku k analyze/zneuziti sezene

A v čem je teda přesně problém když tohle někdo udělá? Samozřejmě nepředpokládám (i když podle úrovně dotazů…) že by měl autor globální klíče.

Vypocetni kryptografie bez fyzicke bezpecnosti (klicu, vypoctu) nema vyznam.
Mam pocit, ze autor se snazi zajistit nejakou zdanlive lepsi ochranu sveho reseni, nez je prakticky realizovatelna.

[_Jenda]

Vypocetni kryptografie bez fyzicke bezpecnosti (klicu, vypoctu) nema vyznam.

Jaktože ne? Já to pochopil tak, že autor řídí pomocí PLC nějaký průmyslový proces, a nechce, aby ho někdo po cestě mohl řídit místo něj. A k tomu přesně se kryptografie používá. Když někdo vleze dovnitř k tomu PLC, tak je hezké, že může extrahovat klíče, ale také může ty dráty co z toho PLC vedou připojit kam chce a proces tak řídit rovnou.

[RDa]

Vypocetni kryptografie bez fyzicke bezpecnosti (klicu, vypoctu) nema vyznam.

Jaktože ne? Já to pochopil tak, že autor řídí pomocí PLC nějaký průmyslový proces, a nechce, aby ho někdo po cestě mohl řídit místo něj. A k tomu přesně se kryptografie používá. Když někdo vleze dovnitř k tomu PLC, tak je hezké, že může extrahovat klíče, ale také může ty dráty co z toho PLC vedou připojit kam chce a proces tak řídit rovnou.

Jestli budu chtit ridit nejaky takovy proces jako utocnik, tak rozhodne nebudu posilat nahodne pakety do Internetu. Ale pujdu na to aplikovane a zmocnim se jedne nebo druhe strany - na uspesny utok ani nemusite mit moc nad online koncem - casto postaci offline kopie/snapshot onoho zarizeni na jednom konci.

Pro me je fascinujici jak se dokaze teoreticky radit co je dokonaly - ale opomiji se zakladni vec - ten, kdo vam dokaze skodit, bude znat vas system lepe nez vy sami. A pak je tam jen faktor toho, co tou cinnosti ziska - at uz se jedna primo o penize, protoze se jedna o financni system, nebo vam jenom nenapadne rozhodi centrifugy v jadernem zarizeni...

[Filip Jirsák]

Jak si predstavujete podepisovani dat odesilanych ze zarizeni na server, klicem, ktery je "bezpecne" na serveru?

Bavíme se o zasílání příkazů ze serveru na klienta.

Utocnikovi se v pripade asymetricke krypto se postaci zmocnit jedne strany spojeni/systemu, a druha ho bude poslouchat na slovo.
A je zcela jedno, kdo drzi verejny a kdo privatni klic - mate jeden, mate nad-vladu nad protistranou.

Myslel jsem si, že vůbec nechápete princip asymetrické kryptografie. Děkuji, že jste nám to potvrdil.

Pro info – veřejný klíč se nazývá veřejný proto, že je veřejný, tj. může ho znát každý. Rozklikněte si v prohlížeči tady na Rootu v adresním řádku zámeček, tam budete mít možnost zobrazení certifikátu. A v certifikátu najdete veřejný klíč toho certifikátu vydaného pro root.cz. Víte, co s tím veřejným klíčem můžete udělat? Vůbec nic. Teda můžete ověřit, že komunikujete s protistranou, která k tomu klíči má privátní klíč.

V pripade symetricke krypto se to zjednodusuje o to, ze klic je stejne a muzete ho ziskat od kterekoliv strany.

Což je právě rozdíl oproti asymetrické kryptografii, kde je tajný klíč jenom ten privátní.

Ale pujdu na to aplikovane a zmocnim se jedne nebo druhe strany - na uspesny utok ani nemusite mit moc nad online koncem - casto postaci offline kopie/snapshot onoho zarizeni na jednom konci.

Když se zmocníte klienta, nebudete už na něj potřebovat útočit po síti. A zabezpečit server je snazší, než zabezpečit komunikaci mezi klientem a serverem – zvlášť když nemáte k dispozici osvědčené knihovny jako OpenSSL a forky.

[_Jenda]

Jestli budu chtit ridit nejaky takovy proces jako utocnik, tak rozhodne nebudu posilat nahodne pakety do Internetu. Ale pujdu na to aplikovane a zmocnim se jedne nebo druhe strany - na uspesny utok ani nemusite mit moc nad online koncem - casto postaci offline kopie/snapshot onoho zarizeni na jednom konci.

Chápu správně, že tvrdíš, že používat například SSH nebo HTTPS je zbytečné, protože útočník přece nebude na síti, ale dojde se fyzicky zmocnit jedné ze stran?

[hazardrok]

Po vsech aktualne ziskanych znalostech bych ulohu asi rozdelil na dve casti:
1. sifrovani/desifrovani
2. obrana proti replay attack

Druhym bodem se zatim nebudu zabyvat, protoze ten to hodne komplikuje, ale teoreticky mam napad.

K prvnimu bodu jsem se inspiroval tim jak to dela napr. sifrovanej archiv RAR viz: https://www.rar.cz/faq.php?title=napoveda%3Asifrovani

Zde popis citat z uvedeneho odkazu:

K šifrování RAR archivu se používá algoritmus AES-256 v režimu CBC pro archivy RAR 5.0 a AES-128 v režimu CBC pro archivy typu RAR 4.x. Algoritmus odvození klíče u archivů RAR 5.0 je založen na PBKDF2 s použitím HMAC-SHA256.

Pokud bych tedy neco takoveho chtel zrealizovat mohl bych si rici, ze jsem schopen zasifrovat zpravu pomoci AES-256 a mam kod i na CBC (predpokladam, ze implementace je funkcni). Takze mam klic, ktery zna pouze klient a server (verme tomu ze to tak je), mam zakodovanou zpravu a mam nahodne vygenerovany inicializacni vektor. Az sem to chapu. Proc nemuzu tedy tuto zpravu odeslat? Bez klice a znalosti vektoru zpravu preci nedesifruju. K cemu mi je tedy HMAC-SHA256 a klic odvozenej od PBKDF2? To je neco co mi unika. Pokud predpokladam, ze utocnik nikdy nevidel rozsifrovanou zpravu tak preci nemuze pochopit co je v tech datech skryto, kdyz je to zasifrovane. Nemusim tedy resit, ze by byl tak hustej aby z toho rozsypanyho caje pochopil, ze je tam nejaky CRC, takze proc resit integritu dat, kdyz o tu se mi principielne postara samotny aplikacni protokol, nebo to je take alfa omega 101 jak tu nekdo psal? Dyt to jsou jen nejaky pakety v siti, ktery se v podstate stale meni, protoze se meni vektor. Ja bych se hrozne moc rad dobral k necemu co se da pouzit.

Kdyz to pozoruju tak to studium byly zabity roky...misto toho jsem mohl delat uplne neco jinyho, protoze mi prijde, ze dneska neco vyvyjet je fakt vo drzku. Kdyz uz neco elektrickyho vymyslim a vyrobim musim do zkusebny (70000Kc), pak to musite prodat pokud to dokazete, musite mit vsechny zkousky a opravneni to vubec delat, kazde tri roky opakovat (dalsi prachy navic),shanite soucastky, , kdykoliv se neco muze posrat (zkuste si treba dneska sehnat par tisic STM32...moje posledni informace je 11tydnu a 100za kus), pak resite servis apod.... No a pak prijede mladej borec v mercedesu, rekne Vam, ze umite prd a nebude se s Vami zabejvat protoze on umi nainstalovat webserver a implementovat botstrap. Tim se nikoho nechci dotknou, ale asi je fakt doba zla.

Jdu objednat ten mikrotik

[_Jenda]

Po vsech aktualne ziskanych znalostech bych ulohu asi rozdelil na dve casti:
1. sifrovani/desifrovani
2. obrana proti replay attack

Druhym bodem se zatim nebudu zabyvat, protoze ten to hodne komplikuje, ale teoreticky mam napad.

Mně přijde že to vyměnění náhodné výzvy na začátku by mělo být docela v pohodě, ne?

K prvnimu bodu jsem se inspiroval tim jak to dela napr. sifrovanej archiv RAR viz: https://www.rar.cz/faq.php?title=napoveda%3Asifrovani

Zde popis citat z uvedeneho odkazu:

K šifrování RAR archivu se používá algoritmus AES-256 v režimu CBC pro archivy RAR 5.0 a AES-128 v režimu CBC pro archivy typu RAR 4.x. Algoritmus odvození klíče u archivů RAR 5.0 je založen na PBKDF2 s použitím HMAC-SHA256.

Uvedené neříká nic o autentizaci a naopak odvozování klíče ty dělat nebudeš.

Pokud bych tedy neco takoveho chtel zrealizovat mohl bych si rici, ze jsem schopen zasifrovat zpravu pomoci AES-256 a mam kod i na CBC (predpokladam, ze implementace je funkcni). Takze mam klic, ktery zna pouze klient a server (verme tomu ze to tak je), mam zakodovanou zpravu a mam nahodne vygenerovany inicializacni vektor. Az sem to chapu. Proc nemuzu tedy tuto zpravu odeslat? Bez klice a znalosti vektoru zpravu preci nedesifruju. K cemu mi je tedy HMAC-SHA256

Aby nešlo přehazováním bitů v ciphertextu přehazovat bity v plaintextu, viz tato tabulka https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Error_propagation

Aby nešlo dělat padding oracle útoky.

Aby nešlo dělat dalších 20 útoků, kdy jen tak bez mrknutí oka natvrdo dešifruješ útočníkem dodaný vstup, které si my ani nedokážeme představit.

Bez klice a znalosti vektoru zpravu preci nedesifruju.

Vektor musíš předat v čitelné formě spolu se zprávou (a MAC počítej z něj i ze zprávy, viz ta tabulka na wikipedii).

a klic odvozenej od PBKDF2?

Ten ti opravdu k ničemu nebude, nemáš přece žádný důvod PBKDF počítat. Víš co je to "P" v PBKDF? Tak já vám to řeknu, pane redaktore . Password. Password. Máte snad nějaké password?

Pokud predpokladam, ze utocnik nikdy nevidel rozsifrovanou zpravu

Tak to předpokládáš blbě. Těch zařízení máš předpokládám víc - opravdu se nemůže stát, že jedno z nich někdo ukradne, rozebere, a na zprávy se podívá?

Nemusim tedy resit, ze by byl tak hustej aby z toho rozsypanyho caje pochopil, ze je tam nejaky CRC

Ve skutečnosti „na konci je CRC“ a „nasbíral jsem 1000 zpráv, tady jsou nějaké bloky co jsou furt podobné, a tady je něco co se náhodně mění, tak to asi bude CRC“ jsou doslova první dvě věci co útočníka napadnou.

takze proc resit integritu dat, kdyz o tu se mi principielne postara samotny aplikacni protokol, nebo to je take alfa omega 101 jak tu nekdo psal?

Protože (a se svými znalostmi už vůbec) tohle nedokážeš ohlídat. S CTR tam bude díra téměř určitě, s CBC možná. Takže než se v noci strachovat co kde tiká za časovanou bombu tak tam prostě ten HMAC přilep a neřeš to, tečka.