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
16
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 :-)


17
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ý.

18
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.

19
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čí?

20
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

21
Vývoj / Re:TCP bezpečnost
« kdy: 04. 02. 2021, 15:21:07 »
No žádná autentizace tam teď v podstatě není, ale možná si jen nerozumíme :-) Server si vyžádá data o zařízení a to mu je pošle jako acsii znaky. Server nemá možnost zjistit jestli klient kecá (jen poznámka: data jsou jen chráněna pomocí CRC to je jediná ochrana). Současně zařízení bude komunikovat s jakýmkoliv serverem, který zná protokol a umí vypočítat CRC.

Můj návrh s autentizací pomocí AES jen tento (má za cíl autorizovat mezi sebou obě strany jen při navazování spojení)...a nemění komunikační protokol
1. jen obě strany už od začátku znají šifrovací klíč
2. server vygeneruje náhodný vektor, který použije k inicializaci šifry a zašifruje nějaký text (třeba náhodný nebo "5*9=")
3. Do zařízení odešle jak vektor tak i šifru
4. Zařízení rozšifruje zprávu a vygeneruje nový náhodný vektor pomocí něj zašifruje výsledek 45. To odešle zpět serveru.

Tím se zajistí, že klient i server si musí rozumět a můžou spolu komunikovat.

22
Vývoj / Re:TCP bezpečnost
« kdy: 04. 02. 2021, 14:51:42 »
Protokol je jasně daný
No a kde teda je popsaný?

Přesný popis není důležitý, protože ten útočník rozklíčuje kompletně jen velice težce. Zkusím večer vygenerovat zničující zprávu a ta se pro celý proces může použít, protože bezpečně to zbortí.

23
Vývoj / Re:TCP bezpečnost
« kdy: 04. 02. 2021, 14:46:32 »
Citace
A ten Tiny AES běží přímo na tom zařízení? Pokud to zvládne ještě SHA-2, tak se tam dá udělat AES + HMAC a to bude podstatně lepší. Ale musí to dělat někdo ví co dělá, ne někdo kdo neví jak se dělá MITM. Jinak tohle se normálně řeší tak, že nakoupíš nějaké malé routříky na kterých běží OpenWRT, nastavíš na tom OpenVPN (nebo jinou VPN, wireguard, ...) a dáš to před to zařízení. Samozřejmě ne vždy to jde provést (cena, prostor, spotřeba). Jako bonus získáš přístup na to zařízení i když je za NATem atd.

Na tom zařízení běží pouze komunikační protokol hodně příbuzný protokolu IRlan nebo možná MODBUS. Používá se na některé průmyslové systémy už desítky let. Ten není možné změnit, ale můžu do něj něco přidat. A také není možné přidávat moc, protože tam je jen STM32F100 a to dělá mnohem důležitější věci než jen komunikaci a počítání klíčů.

To s tím malým routerem s OpenWRT je krásná myšlenka. Škoda, že to někoho nenapadlo už před lety...

24
Vývoj / Re:TCP bezpečnost
« kdy: 04. 02. 2021, 14:37:21 »
protokol zdokumentovany byt nemusi, pokud mam k dispozici klienta i server, abych si mohl cist sitovou komunikaci, tak to je lehke.
„Lehké“ je relativní, samozřejmě je možné že ten protokol bude jednoduchý a udělat to bude na pět minut, ale taky tam může být něco nezjevného a reverzování bude chvíli trvat. A protože cílem je hodnotit bezpečnost protokolu, tak je blbost pálit čas na implementaci a řešení toho proč to nefunguje. Navíc s tímhle rozpočtem, a když to vynásobíš odhadem že se to celé podaří (jak technicky, tak že uživatel hazardrok nezdrhne bez zaplacení, případně si nevymyslí ze své neznalosti nějaký pseudodůvod proč se tvůj útok nepočítá, a taky že tě tu někdo nepředběhne - jak vidíme tak už jsme dva co to jako chtějí implementovat) tak 50% tak to celé musíš stihnout za několik málo hodin aby to bylo rentabilní. Jinak z toho co popsal mi přijde že to bude deset řádků Pythonu (necháš projít ten úvodní handshake a pak už si komunikaci upravuješ jak je libo) a tak bych do toho šel :), ale necháme se překvapit.

Protokol je jasně daný a jediné co bude případnému útočníkovy stačit, když mu dám pevně danou sekvenci bajtů, kterou tam pošle a má vyhráno. Nic víc nic míň. Klidně poskytnu HW, který třeba začne hrát mozartovu operu, když se to podaří do zařízení zapsat. Předvedu, že já jsem schopen to udělat, aby jste si nemysleli, že to je podvod. Peníze dám klidně do úschovy někomu zde spolehlivému, kdo je buď předá tomu kdo to dokáže nebo je vrátí.

25
Vývoj / Re:TCP bezpečnost
« kdy: 04. 02. 2021, 14:27:25 »
Citace
Z tohoto mi přijde, že se snažíš implementovat si protokol pro šifrování a autentizaci „na koleně“, což vzhledem k tomu, jak se ptáš na základy typu únos TCP spojení a MITM, nedopadne dobře. Kdybys použil nějaký normální standardní protokol (třeba TLS) nebo o tom něco věděl (no offense), tak bys to samozřejmě udělal tak, že je šifrovaná a podepisovaná celá komunikace. I ten AES a spol. k tomu lze samozřejmě použít - buď si vybereš mód, který je autentizovaný by default (AEAD, například GCM), nebo do komunikace vkládáš HMAC podpisy zašifrovaných bloků. Dále se bojím, že to naprogramuješ tak, že bude možný replay útok, nebo tam nasekáš chyby typu neautentizovaný CBC nebo counter mód, takže útočník bude moct přehazovat jednotlivé bity ve zprávě, transplantovat bloky atd.

No úplně na koleně to být nemělo. Chtěl jsem použít https://github.com/kokke/tiny-AES-c a ten algoritmus CTR s AES-256. Můj návrh byl ten, že bude pevně daný klíč, který budou znát jen client a server. Pro každé zašifrování se vygeneruje inicializační vektor a ten se pošle spolu s daty (nešifrovaně). Pokud to správně chápu a bude pro každou šifru jiný vektor, který bude generován s co největší náhodností je to neprůstřelné. Současně toto by mělo být jen kvůli ověření pravosti serveru resp. clienta při navazování spojení. Chci si s tou myšlenkou ještě po večerech hrát, protože se mi to docela líbí. Nebo jí zavrhnu, protože najdu slabinu.

Je to celé naprd, protože znám systém za statisíce a stovky zařízení, které jsou takto blbě navržena a už roky běží (né mojí vinou). Změnit šifrování na TLS není už realizovatelné. A v minulosti s tím pracovalo desítky IT odborníků a ani jeden jediný nikdy funkci neoponoval ani neupozornil na možná rizika...zde je vidět jak naši IT odborníci pracujou a za co berou platy (nechci se nikoho dotknout, to je bohužel tvrdá realita). Také to nelze jednoduše stopnou a říci uděláme to jinak.



26
Vývoj / Re:TCP bezpečnost
« kdy: 04. 02. 2021, 13:37:01 »
Díky uživateli Filip Jirsák za komentář. Tomuto asi rozumím, ale jaká je reálná šance, že to někdo dokáže? Myslím tím, jestli toto dokáže 9 z deseti hackerů, který se o to pokusí, protože to je tak strašně jednoduché nebo to dokáže 1 z tisíce, protože má zrovna přístup k nějaké páteřní síti a ví co má hledat. Já mám např. přístup jak ke klientovy tak k serveru a vím jak celej princip pracuje. Znamená to tedy, že mi stačí jen udělat kroky 1..2...3, zmačknout enter a data, která systém poškodí jsou odeslaná?

27
Vývoj / Re:TCP bezpečnost
« kdy: 04. 02. 2021, 13:29:26 »
Dam komukoliv 5000Kč když to dokáže nabourat...má někdo zájem?

napis verejnou ip, kde ti jede server :-)

No pokud bys o to měl skutečně zájem, o víkendu si nějakej pronajmu a rozjedu na něm ten systém. A myslím to naprosto seriózně, protože mě opravdu zajímá jestli to lze takto jednoduše. Jsem přesvědčen, že to nedokážeš. Máš nějakej tip na poskytovatele nějakých virtuálních serverů, který by byl vhodný?

28
Vývoj / Re:TCP bezpečnost
« kdy: 04. 02. 2021, 12:23:42 »
Dam komukoliv 5000Kč když to dokáže nabourat...má někdo zájem?

29
Vývoj / Re:TCP bezpečnost
« kdy: 04. 02. 2021, 11:40:13 »
Autorizaci klienta chci teď po novu řešit pomocí AES a předpokládám, že SERVER i CLIENT při navazování spojení pozná zda je to fejk nebo ne. Pro mě je největší otázkou co se bude po tom co je spojení navázané. Klidně ať ten operátor data vidí to je mi úplně jedno (jedná se o data z měření, žádné tajnosti). Ten systém ale umožňuje data i přijímat např. konfiguraci. Tu bych docela nerad aby mi někdo měnil. Kdybych komunikaci zašifroval, bylo by všechno v cajku, ale je to vůbec nutné? Snad chápete co tím chci říci...

30
Vývoj / TCP bezpečnost
« kdy: 04. 02. 2021, 11:10:09 »
Ahoj, v poslední době mi příjde, že by se pomalu každý kdo používá přenos dat na internetu měl bát o jejich bezpečnost. Proto bych se chtěl jen teoreticky zeptat, jak by se dala hacknout tato situace...

Mám TCP klienta, který se připojuje na TCP server s veřejnou IP adresou. Jakmile se naváže spojení, tak veškerou komunikaci přebírá TCP server. Tj. server vždy zahajuje komunikaci a client mu odpovídá. Komunikace je nezabezpečená.

Moc nerozumim tomu, jak by někdo třetí, který sedí někde buhví kde mohl zasáhnout do této komunikace.
Jediné co mě napadá je že existuje hackerský TCP server, který má stejnou IP adresu jako můj a tak se client připojí k němu. Jak by to ale mohl dokázat, když jsou všichni z jiného města? V rámci jedné budovy client-hacker možná, ale jiná síť...

Existuje nějaká metoda jak se do toho spojení dostat, nebo možná ještě jinak jak bych to mohl sám dokázat? Abych to zjednodušil tak je mi úplně jedno, jestli ten hacker data sleduje. Jediné co nechci je, aby do toho spojení mohl data poslat.


Stran: 1 [2] 3 4