TCP bezpečnost

[Filip Jirsák]

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,

Šifrovací algoritmy obvykle vyžadují konkrétní délku klíče – např. u AES-256 je to 256 bitů (to je těch 256 v názvu). Když uživatel zadává heslo k RAR archivu, typicky zadá něco jiného než 256 bitů. Takže potřebujete jakékoli heslo znormalizovat na 256 bitů – a k tomu se právě používají algoritmy pro odvození klíče z hesla, například to PBKDF2. Pokud vy zvolíte rovnou klíč správné délky (což doporučuju), použijete ho pro šifrování rovnou, nebudete ho odvozovat z hesla.

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.

Pro ověřený integrity se používají hashe, třeba SHA-256, s tím se CRC co do kryptografické bezpečnosti opravdu nemůže porovnávat. Nicméně pokud v celém tom vašem bezpečnostním protokolu nebude žádná skulinka pro nějaký postranní kanál, mělo by i to CRC a struktura aplikačního protokolu poskytovat dostatečnou ochranu integrity. Ale je to založené na tom, že bude vše fungovat ideálně, čehož se v reálném světě obvykle nedaří dosáhnout...

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.

Holt už je to všechno tak daleko, že nedokážete třeba celou bezpečnost udělat sám. Ani kdybyste vystudoval jakoukoli školu. Proto se všichni snažíme, jakmile je to aspoň trochu možné, použít už něco hotového. Ideálně hotovou implementaci, nebo alespoň hotové protokoly.

[Reklama]

[Filip Jirsák]

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

Jedině pokud se pak ta výzva bude promítat do všech zpráv a bude se v průběhu komunikace měnit. Předpokládám, že by byl problém, pokud by útočník získal jednu zprávu v rámci TCP/IP spojení a později by dokázal do toho spojení tu samou zprávu zopakovat.

[hazardrok]

zkusim to tedy jeste jednou bodove (neresim replay attack ani korektnost zdrojaku, ktere hodlam pouzit):
1. vygeneruju nahodny IV, mam klic '256bit', zasifruju zpravu metodou CTR(je pro me pohodlnejsi nez CBC), vznikne ciphertext (https://github.com/kokke/tiny-AES-c)
2. pres IV a ciphertext provedu hash SHA-256, vznikne HMAC (https://github.com/B-Con/crypto-algorithms)
3. ciphertext + IV + HMAC odeslu pres TCP

4. prijmu paket rozdelim ho na ciphertext + IV a HMAC
5. opet provedu hash SHA-256 a overim tim integritu dat...nyni muzu predpokladat, ze utocnik data nezmenil, nebo je zahodim protoze overeni se nepodarilo
6. z ciphertext a IV ziskam desifrovanim pomoci klice '256bit' plaintext
7. otevru dvere, protoze nastal utok typu replay attack...a zacinam odznova

Uteklo mi principielne jeste neco? Mozna je na to pozde, ale moc diky klukum co do tohodle vlakna prispivaj hlavne Filip Jirsák a _Jenda. To co jste tu zatim popsali, tak na to bych urcite sam nikdy neprisel. A ani bych se to nikde nedocetl, protoze takhle velkej rozsah rozhodne nemam a kdyz si to nemuzu osahat sroubovakem, tak mi to spise prijde abstraktni, jak obrazky od dcery

[TS]

Jako příklad k prvotnímu dotazu (snad se nemýlím) mě připadne tento výchozí stav:

Klient IP: 1.1.1.1
Server IP: 8.8.8.8 (telnet server)
Příkaz u klienta: "telnet 8.8.8.8"
Žádné šifrování, žádný firewall, žádné pravidla, oba veřejné IP.

Úkol (dotaz?): Pošlete mi zprávu na klienta, nebo na server!

(pro zkoušku je samozřejmě nutné, vytvořit rozumné testovací prostředí)

[RDa]

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íč.

A tohle je to obri zdani bezpecnosti. Vy falesne duverujete necemu, co vam klient rekne - klidne muzete mit nejaky malware (ci antivirak), ktery se vam vlozi do sitove komunikace, prebali to SSL na jinak podepsany, podvrhne CA.

Pokud uz chcete aplikovat chain of trust, tak to overeni NESMITE delat na tom samem zarizeni, protoze nemate jistotu zda neni kompromitovana sit nebo rovnou stroj. A jaksi z principu bude blby aby u kazdeho klienta stal clovicek s papirovym otiskem klicu (ktery jde samozrejme take podvrhnout). Proto rikam, ze ultimatni bezpecnost neexistuje.

[Reklama]

[Exceptions]

nevšiml jsem si, jestli jsi zmiňoval na jakém HW to běží, neutáhne to něco takovéhoto https://github.com/wolfSSL/wolfssl či přímo využít https://github.com/wolfSSL/wolfMQTT i pro transportní vrstvu, vyřeší ti to všechny tyhle komplikace.

Zároveň všechny tyhle SSL/TLS knihovny mají ověřeně vyřešený samotný AES, lze to s nich vzít, působí to na mě věrohodněji než to tiny-aes-c. Tady je třeba ukázka s wolfSSL https://github.com/wolfSSL/wolfssl-examples/blob/master/crypto/aes/aescfb-file-encrypt.c. Podle zkušenosti to umí běhat na dost slabých MC.

[Filip Jirsák]

A tohle je to obri zdani bezpecnosti. Vy falesne duverujete necemu, co vam klient rekne - klidne muzete mit nejaky malware (ci antivirak), ktery se vam vlozi do sitove komunikace, prebali to SSL na jinak podepsany, podvrhne CA.

Tak ještě jednou a pomaleji. Když mám v ruce krabičku, ze které vedou dráty pro ovládání otevírání a zavírání dveří, nebudu složitě hackovat software v té krabičce, ale prostě se připojím přímo na ty dráty a tu krabičku úplně obejdu.

Pořád řešíte problémy, které nikdo řešit nechce.

[Filip Jirsák]

zkusim to tedy jeste jednou bodove (neresim replay attack ani korektnost zdrojaku, ktere hodlam pouzit):
1. vygeneruju nahodny IV, mam klic '256bit', zasifruju zpravu metodou CTR(je pro me pohodlnejsi nez CBC), vznikne ciphertext (https://github.com/kokke/tiny-AES-c)
2. pres IV a ciphertext provedu hash SHA-256, vznikne HMAC (https://github.com/B-Con/crypto-algorithms)
3. ciphertext + IV + HMAC odeslu pres TCP

4. prijmu paket rozdelim ho na ciphertext + IV a HMAC
5. opet provedu hash SHA-256 a overim tim integritu dat...nyni muzu predpokladat, ze utocnik data nezmenil, nebo je zahodim protoze overeni se nepodarilo
6. z ciphertext a IV ziskam desifrovanim pomoci klice '256bit' plaintext
7. otevru dvere, protoze nastal utok typu replay attack...a zacinam odznova

Uteklo mi principielne jeste neco? Mozna je na to pozde, ale moc diky klukum co do tohodle vlakna prispivaj hlavne Filip Jirsák a _Jenda. To co jste tu zatim popsali, tak na to bych urcite sam nikdy neprisel. A ani bych se to nikde nedocetl, protoze takhle velkej rozsah rozhodne nemam a kdyz si to nemuzu osahat sroubovakem, tak mi to spise prijde abstraktni, jak obrazky od dcery

Připadá mi zbytečné hashovat tu zašifrovanou zprávu, protože to samé může udělat i útočník – má k tomu všechny potřebné informace. Raději bych hashoval přímo zprávu (spolu s klíčem) a teprve zprávu+hash bych šifroval. HMAC má smysl používat tehdy, pokud do hashované zprávy můžete přidat něco, co útočník nezná. Když pak hash ověříte, máte jistotu, že ho musel vytvořit odesílatel a ne útočník.

[_Jenda]

Připadá mi zbytečné hashovat tu zašifrovanou zprávu, protože to samé může udělat i útočník – má k tomu všechny potřebné informace.

Nemá, tazatel tím hashem myslí HMAC (keyed hash). Teda doufám.

Raději bych hashoval přímo zprávu (spolu s klíčem) a teprve zprávu+hash bych šifroval.

Tomu se říká mac-then-encrypt a umožňuje to například padding oracle útoky.

[Filip Jirsák]

Tomu se říká mac-then-encrypt a umožňuje to například padding oracle útoky.

Jejich podmínkou je, že útočník může ovlivnit obsah otevřeného textu (zprávy před zašifrováním), ne?

Jinak ale platí to, co jsem psal výše – všeobecně používaná schémata (jako třeba TLS 1.3) mají spoustu ochran proti různým útokům postranním kanálem. Jakmile se někdo rozhodne z jednotlivých komponent poskládat vlastní schéma (jako teď děláme), určitě tam bude spousta děr umožňujících útok postranním kanálem. V podstatě jde jen o tom, nepřehlédnout nějakou opravdu základní chybu (což my dva neuděláme, kdyby nic jiného, tak proto, že neznáme přesný scénář použití – že útočník nemůže v tomto případě ovlivnit otevřený text zprávy je jen moje domněnka, nemám to potvrzené od tazatele) a pak doufat, že ty díry, které tam určitě jsou, nebudou v tomhle případě nikomu stát za zkoumání. Je v tom holt kus security through obscurity.

[xyz]

Nedavno jsem si delal jakysi kurs neuronovych siti a skolitel rikal. Nesnazte se implementovat maticove a jine vypocty sami, pouzijte uz hotove knihovny. Lidi, kteri se tim zabyvaji maji doktoraty z pocitacove algebry.

Tak security je neco podobneho. Na nejake hrani, nebo zjistit, jak to funguje asi dobry, ale jinak je to vyssi divci. 

[_Jenda]

Tomu se říká mac-then-encrypt a umožňuje to například padding oracle útoky.

Jejich podmínkou je, že útočník může ovlivnit obsah otevřeného textu (zprávy před zašifrováním), ne?

Přiznám se, že jsem ho nikdy neimplementoval, ale myslím, že ne. Ale je potřeba, aby se útočník dozvěděl, jestli došlo k chybě při dešifrování (odstraňování paddingu) nebo při autentizaci - což mu může autor jednoduše neříct (ale může se stát, že jedno z toho bude trvat delší dobu, obzvláště na tom pomalém hardwaru, a pak se to dá zjistit z toho).

Tak security je neco podobneho. Na nejake hrani, nebo zjistit, jak to funguje asi dobry, ale jinak je to vyssi divci.

Samozřejmě, ale tazatel je bohužel v situaci, že tam plnohodnotnou knihovnu pro TLS nedá, tak se snažíme aby tam bylo ,,alespoň něco" (jak píše Filip Jirsák). Pokud před to nemůže předřadit ten router s VPN.

[RDa]

A tohle je to obri zdani bezpecnosti. Vy falesne duverujete necemu, co vam klient rekne - klidne muzete mit nejaky malware (ci antivirak), ktery se vam vlozi do sitove komunikace, prebali to SSL na jinak podepsany, podvrhne CA.

Tak ještě jednou a pomaleji. Když mám v ruce krabičku, ze které vedou dráty pro ovládání otevírání a zavírání dveří, nebudu složitě hackovat software v té krabičce, ale prostě se připojím přímo na ty dráty a tu krabičku úplně obejdu.

Pořád řešíte problémy, které nikdo řešit nechce.

Pokud je si autor 100% jisty ze mu klice a kod neunikne, plus server i ta spousta zarizeni odola fyzickemu utoku (coz je v realnem nasazeni opravdu nemozne splnit), tak bude cesta nejmensiho odporu nasadit symetrickou sifru nad daty ve formatu  "pocitadlo+payload+checksum". Jestli to presune z aplikacni urovne nekam hloub do IP, tak z toho mame co? Zcela klasicky IPsec.

Takze nevymyslejte lamersky TLS ohejbak, kdyz to jde udelat zcela standardne, dokonce i s omezenymi zdroji ktere ta aplikace pry ma.

[Filip Jirsák]

Pokud je si autor 100% jisty ze mu klice a kod neunikne, plus server i ta spousta zarizeni odola fyzickemu utoku (coz je v realnem nasazeni opravdu nemozne splnit), tak bude cesta nejmensiho odporu nasadit symetrickou sifru nad daty ve formatu  "pocitadlo+payload+checksum". Jestli to presune z aplikacni urovne nekam hloub do IP, tak z toho mame co? Zcela klasicky IPsec.

Takze nevymyslejte lamersky TLS ohejbak, kdyz to jde udelat zcela standardne, dokonce i s omezenymi zdroji ktere ta aplikace pry ma.

Vy tu pořád trousíte obecná rádoby moudra, ovšem vždy se prozradíte tím, že do toho zamontujete nějaký nesmysl. Já jsem původně rozporoval vaše tvrzení, že v případě asymetrické kryptografie je problém, pokud unikne kterýkoli klíč (tedy privátní nebo veřejný).

Teď zase plácáte nesmysly o úniku kódu – ne, ani já, ani _Jenda ani hazardrok jsme opravdu nikdy nenapsali nic v tom smyslu, že bude zabezpečení založené na tom, že bude utajená implementace bezpečnostních algoritmů. A také nesmysly o fyzické bezpečnosti klientů – každý klient bude mít svůj unikátní klíč, takže pokud unikne klíč jednoho klienta, budou použitelný pouze pro ovládání toho jednoho klienta. A pokud už někdo fyzicky ovládá toho klienta, nepotřebuje na něj útočit vzdáleně. To už vám tu ale vysvětlovalo opakovaně několik lidí.

Použití TLS jsem navrhoval hned od začátku, ale hazardrok nemá zařízení, na kterém by mohl použít existující knihovnu – a implementovat celé TLS od nuly by byla sebevražda.

No a to řešení cestou nejmenšího odporu s šifrováním symetrickou šifrou a zajištěním integrity pomocí HMAC se tu snažíme popsat.

Nápad použít IPsec je zajímavý (pokud jste tedy svým zašmodrchaným komentářem myslel tohle), nicméně implementovat IPsec není nic jednoduchého.

[RDa]

Nápad použít IPsec je zajímavý (pokud jste tedy svým zašmodrchaným komentářem myslel tohle), nicméně implementovat IPsec není nic jednoduchého.

Tak ono postaci nejake minimum (jedna sifra, jeden rezim), a protistrana se patricne nastavi.
Je to lepe testovatelne a neni treba vymyslet transportni kodovani.


Ohledne zbytku - bohuzel mam prakticke zkusenosti a onu hru na kocku a mys, kdy se bezpecnost zvysovala vsemoznym teoretickym zpusobem (padlo zde ve vlakne mnoho tipu a nic z toho opravdu nebyla prekazka), zastavilo az nasazeni specialniho biosu a sifrovanych medii, ktere pri jakemkoliv naznaku naruseni tripnou a vymazou klice. Proto kazdy, kdo to mysli s bezpecnosti vazne, nespoleha jen na sifry a metody, ale resi se to systemem bezpecnych enklav (to je ta moje pozadovana fyzicka bezpecnost) - HSM a pod.

Nejde o to, ze prolomeni muzete provest jednorazove na miste cinu - ale o to, ze po obfuskaci ("sifrovani") spojeni, bude dalsi nejslabsi clanek onen fyzicky endpoint. A kdo bude mit zajem.. si pro nej fakt prijde. Pak vam prijde treba reklamace, ze "sory, ono se z toho zakourilo", tak to vymenite. Ale po teto udalosti, treba uz ta bezpecna sit neni jenom vase.. protoze je v ni nekdo dalsi.

Myslim ze resit protokol samo o sobe je malo - jestli to chce mit autor bezpecnejsi, mel by o tom premyslet jako o celku.