Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - hazardrok

Stran: 1 2 [3] 4 5 6
31
DPS (super) a Amaro (dost nuda).

32
Hardware / Re:ESP32 STA nebo AP
« kdy: 19. 03. 2021, 19:38:22 »
Tak jsem to vyresil k obrazu svemu...kdyby to nekoho nekdy zajimalo, tak zde je postup...
V souboru "wifi_netif.c" nahradit fnukci:
Kód: [Vybrat]
static esp_err_t wifi_sta_receive(void *buffer, uint16_t len, void *eb)
{   
    return s_wifi_rxcbs[WIFI_IF_STA](s_wifi_netifs[WIFI_IF_STA], buffer, len, eb);
}

touto:
Kód: [Vybrat]
static esp_err_t wifi_sta_receive(void *buffer, uint16_t len, void *eb)
{   
    esp_err_t ret;
    uint16_t port;
    uint8_t *p_port = (uint8_t*)&port;
   
    p_port[0] = *(uint8_t*)(buffer + 0x25);
    p_port[1] = *(uint8_t*)(buffer + 0x24);
   
    if(port == 80){
      len = 0;
      }   
   
    ret = s_wifi_rxcbs[WIFI_IF_STA](s_wifi_netifs[WIFI_IF_STA], buffer, len, eb);
   
    return ret;
}

O tom, zda je to prasarna nepochybuju :D
Kazdopadne to dela to co chci a pokud je ma domnenka, ze pozice cisla portu je v datagramu pevne dana, melo by to fungovat spolehlive.

Sory ze jsem Vas v patek k veceru nutil toto cist...

33
Hardware / Re:ESP32 STA nebo AP
« kdy: 19. 03. 2021, 18:56:50 »
No vidis, vyjadruju se spatne neustale. Myslel jsem to tak, ze pokud budu vedet jaka MAC jsou pripojena na rozhrani AP (to vim), tak pokud budu vedet jakemu MAC patri prichozi paket TCP, jsem schopen provest filtraci a zahodit nezadouci. Kdyby to slo bylo by to super, protoze bych se nemusel hrabat v esp-idf, ale zvladnul bych to na urovni user_app. Tohle se mi ale zatim nedari.

S cislem portu jsem asi schopen pracovat pomoci funkce wifi_sta_receive() a wifi_ap_receive(), ktere maji jako argumet prijaty datagram. Tim padem jsem schopen zjistit na jaky port je to smerovane a mozna to zablokovat. Je to ale na urovni esp-idf coz se mi moc nelibi.

34
Hardware / Re:ESP32 STA nebo AP
« kdy: 19. 03. 2021, 16:26:33 »
No mozna jsem se spatne vyjadril nebo nerozumim jak tuto funkci pouzit.
Tato funkce jak ji chapu je pouzitelna pouze pro zjisteni MAC adresy pripojenych zarizeni k rozhrani. Toto mi k pozadovanemu vysledku nestaci, protoze jeste potrebuju tuto informaci ziskat z konkterniho pateku TCP. Napisu k cemu to chci pouzit...v tom espcku bezi tcp server. Ja ale chci aby se k tomu TCP serveru mohlo jen z rozhrani AP. Pokud se na nej bude chtit pripojit neco ze STA rozhrani, bude to blokovane.

35
Hardware / ESP32 STA nebo AP
« kdy: 19. 03. 2021, 15:35:06 »
Ahoj, narazil jsem na problem se kterym si nevim rady. Snazim se u ESP32 detekovat zda prichozi TCP pakety jsou z rozhrani STA nebo AP. Moje prvotni myslenka byla takova, ze to rozhodnu podle IP adresy. Jenze pak jsem zjistil, ze na STA i AP muzu mit stejnou IP adresu, takze toho nebude fungovat. Dale me napada ze by to mohlo jit podle MAC adresy, jenze zde jsem narazil na to, za nedokazu z prichoziho spojeni MAC adresu zjistit nebo nevim jak. Nenapada nekoho jak toto vyresit? Dik.

36
Vývoj / Re:TCP bezpečnost
« kdy: 05. 02. 2021, 00:27:47 »
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 :D

37
Vývoj / Re:TCP bezpečnost
« kdy: 04. 02. 2021, 23:12:34 »
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:
Citace
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 :D



38
Vývoj / Re:TCP bezpečnost
« kdy: 04. 02. 2021, 22:13:11 »
Citace
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:
Citace
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

39
Vývoj / Re:TCP bezpečnost
« kdy: 04. 02. 2021, 21:01:04 »
Citace
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.

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.

Citace
Takže co potřebujete zajistit – utajení dat, jejich nezměnitelnost, nebo obojí?

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 ;D


40
Vývoj / Re:TCP bezpečnost
« kdy: 04. 02. 2021, 20:40:32 »
Citace
Je to symetrická a asymetrická, ne synchronní a asynchronní

Jak jsem spise z toho fochu drateniku, tak hold vsude vidim motory a generatory :)

41
Vývoj / Re:TCP bezpečnost
« kdy: 04. 02. 2021, 19:52:25 »
Citace
Teda, ehm: doufám že ten CTR mód inicializuješ vždycky správně a negeneruješ omylem pokaždé stejný keystream, že ne?!? Pak by šly ty challenge navzájem vyXORovat a jsi více či méně v řiti (podle konkrétních detailů protokolu)

No v podmínkách je (pokud jsem je správně pochopil), že nesmím dvě různé zprávy zašifrovat stejným klíčem a stejným inicializačním vektorem. Inicializační vektor chápu jako absolutně náhodné číslo. Pokud tedy každou zprávu zašifruju stejným klíčem, ale pokaždé jiným vektorem, který si budu náhodně generovat a posílat ho veřejně vedle zašifrovaných dat logicky bych si myslel, že podmínky šifrování jsou splněny. A data jsou šifrovaná bezpečným způsobem. Dokážeš mi tento můj závěr vyvrátit? Klidně pošlu i ten kód, kterým to testuju.

Kdybych tady teď neseděl a nesnažil se o socializaci na této síti měl jsem na plánu doma testovat to šifrování a hledat bezpečnostní chyby. Např se mi moc líbí toto: https://cs.wikipedia.org/wiki/Provozn%C3%AD_re%C5%BEim_blokov%C3%BDch_%C5%A1ifer
Chtěl jsem si vyzkoušet jak by vypadal můj zašifrovaný tučňák :-)


42
Vývoj / Re:TCP bezpečnost
« kdy: 04. 02. 2021, 19:40:18 »
Těch věcí co si můžu spolehlivě dovolit moc není. Resp. implementovat nějaký kód, který šifruje není problém, ale implementovat celou knihovnu TLS, aby to ověřovalo obě strany už je problém. A ověřit obě strany potřebuji, protože server musí věřit klientovy, aby mu posílal platné hodnoty z měření a klient musí věřit, že mu server posílá správnou konfiguraci. Proto jsem se také začal zabývat šifrováním, ale zatím jen při navazování spojení. Po posledních komentářích chápu, že to není reálné a je potřeba k tomu přistoupit líp.
Používat asynchronní šifru se mi zdálo složitější než synchronní (jen dojem za posledních pár dní co se tím zabývám) hlavně z pohledu výpočtu. Proto jsem se pokusil implementovat ten AES-256 s CTR, protože se tam používá stejný algoritmus k šifrování i dešifrování což by mi ušetřilo dost paměti. Nejsem ale schopen posoudit zda to někdo prolomí a jak říkáte, proč by to také dělal. Na druhou stranu rád bych tomu co to dělá rozumněl a chtěl bych, aby to bylo přinejmenším nesnadné prolomit. Podepisování hashem se mi líbí...

Můžete se tedy pokusit odpovědět na tyto otázky, nemusí to být složité odpovědi...
1. Je lepší použít synchronní šifru nebo asynchronní (je nějaká jednoduchá na implementaci)?
2. Pokud použiju synchronní např. zmíněný AES metodou CRT a budu každou zprávu šifrovat pomocí náhodného vektoru, který budu předávat v každé zprávě bude to spolehlivé? Pokud nebude, existuje nějaká jiná synchronní šifra, kterou můžu napsat v céčku s minimální zdroji která bude spolehlivá?

Osobně jsem k té asynchronní šifře docela skeptickej, protože se mi nelíbí ten privátní a veřejnej klíč. Také moc nechápu jak se dají pomocí veřejného klíče získat data zašifrovaná privátním, ale to je asi jen detail, kterej snad někdy pochopím. Je mi jasné, že v moderním světě se to takto dělá a všichni to přijímají ale na rovinu... v tomto vlákně je vidět jakási píle něco udělat líp, ale když si firma vezme 1,5mil Kč za vývoj SW paskvilu, za rok řekne sorry, ale my už to dělat nebudem a nic se jim neděje je to smutné. Na druhou stranu jsem nedavno byl u jednoho chlapíka v domě za 50mil+ a tam nedostanete ani kafe. U nás dostane kafe a sušenku i kominík co udělá nerezovej komín na krb do domu kde neni hromosvod :-D Všechno není tedy jen o penězích...

Takže pokud tu ještě někdo má sílu se tím zabývat, zapomeňte na mikrotik a jiný názory o TSL, protože to mi nepomůže a spíš mi poraďte jakou šifru mám použít. Klidně udělám ještě jednu obálku nad celou komunikací, která bude celá zašifrovaná, ale jak to nepůjde napsat do 512b ramky je to špatný.

43
Vývoj / Re:TCP bezpečnost
« kdy: 04. 02. 2021, 16:41:50 »
Citace
Takže jak psali kluci přede mnou, asi bych se nezabýval vynalézáním kola

Jen taková poznámka k této větě. Když jsem se kdysi chtěl naučit programovat, tak jsem si mimo jiné koupil knihu o tom jak různí přední světoví programátoři (nebo alespoň to tak bylo publikováno) radí ze svých zkušeností, jak se vyvarovat chyb. Jedna rada byla:
Citace
Znovu a znovu vynalézejte kolo.
Napadá mě otázka čemu pak věřit. Když se mě tady třeba snažíte přesvědčit, že metody útoků na toto existují a že je potřeba to šifrovat je to vůbec správné tvrzení? Pořád by mě ještě zajímala odpověď na to, zda by to někdo tady skutečně dokázal prolomit a ukázat mi to v reálném provozu. Nechápejte to špatně, myslím to tak, že se mi dost těžko věří tomu, že něco lze, když jsem to ještě neviděl a to i přes to, že na internetu se to píše.

44
Vývoj / Re:TCP bezpečnost
« kdy: 04. 02. 2021, 15:48:03 »
Je to mnohem horší, což osobně vidím jako velkej průser.

no podle toho co popisuješ, tak ta autorizace to moc dál neposune ... případnej MITM nechá server a klient se autorizovat dle libosti a do komunikace vleze, až budeš zpět v plaintextu. Takže jak psali kluci přede mnou, asi bych se nezabýval vynalézáním kola, a hodil tam malýho mikrotika, kterej bude volat domů na openVPN server a máš řešení s cenou ~30€ na koncový zařízení..

To že crypto knihovny maj commity každej den není kvůli grafomanství autorů, ale proto, že mít dobrej bezpečnostní model je těžký a málokdy trvalý.

Nějakej osvědčenej typ na model se kterým se každej naučí?

45
Vývoj / Re:TCP bezpečnost
« kdy: 04. 02. 2021, 15:24:42 »
Citace
Takže celé je to o tom, jestli se někomu vyplatí se tím zabývat, a jakou vám to způsobí škodu. Pokud tím měříte počasí nebo zhasínáte veřejné osvětlení v Horní Dolní, tak je to asi jedno.

Je to mnohem horší, což osobně vidím jako velkej průser. Naštěstí mě se to netýká, protože já jsem jen z FEL a kreslím pouze čáry. To, že se jako hobby zajímám o programování nikoho kolem mě nezajímá :-D

Stran: 1 2 [3] 4 5 6