Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: hazardrok 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.
-
To může odposlouchávat jakýkoli operátor, který má zařízení v cestě paketu. Při špatném nastavení se pakety klidně kopírují i na spoustu dalších zařízení. Když se bude jednat o pravidelný provoz, tak už to může někdo logovat v rámci diagnostiky apod... Určitě počítej, že na server ti bude chodit různý bordel a budeš to muset filtrovat.
Oprávnění klienta chceš potvrzovat minimálně nějakým heslem. A to chceš mít nějak šifrované, jinak se ti tam přihlásí kdokoli.
-
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...
-
těch útoků je celá řada, nikdy asi nebudeš mít znalosti, abys dokázal sám posoudit jestli je daný útok možný a nebo ne, útočník bývá chytřejší než většina adminů/programátorů, nezbývá než věřit doporučením a nedělat svoji cestu bez dostatečných znalostí.
Namátkou, někdo cestou může otrávit arp cache a přesměrovat provoz na jiné servery (TCP/IP je poměrně vysoko položený protokol). Stejnou věci lze udělat přes ICMP redirect, pokud se útočník zmocní nějakého aktivního prvku na cestě (např. veřejná wifi na tohle je super).
Poté existují útoků na přímo změnu obsahu TCP zpráv, ať již formou MiTM nebo pokročilejší s odhadováním sequence numbe a ISN. Stejně jako je nepřeberné množství útoků, které zapřičiní, že se spojení nenaváže. TCP samo o sobě postrádá možnost ověřit obě strany komunikace a ani neklade velké překážky pro napadení již probíhající komunikace (hledej tcp session hijack). Šifrování zároveň slouží i pro validace přenášených dat, nelze je totiž změnit.
Nevymýšlel svoje způsoby zabezpečení, uděláš v tom miliony chyb, existuje SSL/TLS s client certifikátem, poměrně solidní a robustní, můžeš použít ipsec jako ověřený standard. AES je super slovo, ale jak chceš přenášet heslo? Budeš ho rotovat? Server a ani klient při navazování nemá šanci poznat, že to je fejk, naopak nikdy nevíš ke komu jsi se připojil a kdo se k tobě připojil.
-
dobre u nejake hracicky co mas na mereni teploty na chalupe, tak te to nevzrusuje.
ale uz by stacilo, abys me na chalupe k serveru pripojeny kotel a vnejsi utocnik ti ho muze zhasnout nebo rozpalit do bela.
takze proc nezkusit knihovny ssl a mit to bezpecne od zacatku.
-
Dam komukoliv 5000Kč když to dokáže nabourat...má někdo zájem?
-
Dam komukoliv 5000Kč když to dokáže nabourat...má někdo zájem?
napis verejnou ip, kde ti jede server :-)
-
První věc je, jak klient zjistí tu IP adresu. Možná klient ve skutečnosti komunikuje s IP adresou útočníka a teprve útočník komunikuje s cílovým serverem. Pak je myslím způsob útoku jasný – veškerá komunikace jde přímo přes útočníka, tedy si s ní může dělat, co chce.
Pokud má klient správnou IP adresu, pořád může dojít k napadení komunikace kdekoli po cestě. Útočník sice může fyzicky sedět kdekoli, ale může ovládat nějaké zařízení po cestě. A na tomto zařízení opět bude schopen odklonit komunikaci k sobě nebo ji upravit.
Protože neřešíte čtení, ale jen poslání dat, má útočník ještě další, mnohem jednodušší možnost. Na úrovni sítě vlastně žádné TCP/IP spojení neexistuje – jsou to jen pakety, které mají stejnou dvojici IP adres a portů. A pak se podle dat uvnitř paketu (pořadové číslo) určí, kam přesně uvnitř spojení patří data, která paket přenáší. Takže pokud útočník ví tu čtveřici, může poslat paket, který cílový počítač vyhodnotí tak, že patří do spojení. Tři údaje útočník obvykle zná (zdrojovou a cílovou IP adresu a cílový port – ten obvykle odpovídá službě). Zbývá tedy zdrojový port – obvykle je snaha volit ho náhodně, ale moc možností není. Útočník může zkusit hádat, může různými technikami získávat další informace, které mu umožní okruh možných čísel portů zúžit. Takže předpokládejme, že útočník umí poslat paket, který cílový systém vyhodnotí tak, že patří do daného spojení. Akorát bude řešit, kam přesně patří. Pořadová čísla paketů nezačínají od nuly nebo jedničky, ale opět se volí náhodně. Takže když to bude útočník jen tak zkoušet, pošle data, který cílový systém vyhodnotí tak, že patří někam před začátek spojení (což je nesmysl, takže paket zahodí), nebo někam daleko za místo, kde je teď (takže paket nejspíš také zahodí). Ale opět – pořadové číslo je určené pro detekci chyb sítě, není dostatečně robustní na to, aby dokázalo zabezpečit bezpečnost. Opět útočník může zkoušet různé techniky, jak zjistit, kde asi se ta aktuální komunikace pohybuje. No a pokud útočník může komunikaci odposlouchávat, má to triviální – čtveřici IP adresy a porty si prstě odposlechne, stejně jako pořadová čísla paketů.
Ve výsledku tedy útočník pošle paket, který má identifikační údaje úplně stejné, jako by ho odesílal server (nebo klient). Proti strana nemá jak poznat, že ten paket odeslal někdo jiný. Takže data zpracuje, pro něj jsou to data, která normálně přišla po TCP/IP spojení. Takže pokud by váš protokol umožňoval třeba ze serveru poslat klientovi příkaz k vypnutí, klient ten příkaz normálně přijme a vypne se. Pokud ten klient nebude mít nějakou ochranu před DoS útoky, nemusí útočník ani zjišťovat číslo portu a přesné sekvenční číslo, stačí mu znát ho přibližně. Prostě těch paketů odešle hodně, se všemi možnými hodnotami. Většinu cíl zahodí jako nesmyslné, ale ten jeden správný paket se ujme.
-
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ý?
-
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á?
-
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é.
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.
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íť...
Tak jednak řešení, které funguje jen proti útočníkům z jiného města, ale nikoli proti útočníkům ze stejného města, je dost k ničemu. A jednak: v rámci sítě (ARP spoofing) a po cestě u ISP (jeho děravá infrastruktura; když jsem sám ISP - různé veřejné wifi) na obou stranách. Dále třeba zmíněný DNS poisoning. A pak byly i nějaké další způsoby, co zneužívaly různé implementační problémy se sekvenčními čísly atd., ale ty jsem nikdy podrobně nezkoumal a bylo složitější je provést.
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ý?
Když sem dáš dokumentaci protokolu (rozhodně to za 5kKč nikdo nebude reverzovat) a ukázkovou implementaci klienta (abychom to nemuseli implementovat), tak se ti na to možná podívám.
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.
Opět, řešení, která se spoléhají na tyhle věci, jsou rozbitá.
-
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ý?
Když sem dáš dokumentaci protokolu (rozhodně to za 5kKč nikdo nebude reverzovat) a ukázkovou implementaci klienta (abychom to nemuseli implementovat), tak se ti na to možná podívám.
----
protokol zdokumentovany byt nemusi, pokud mam k dispozici klienta i server, abych si mohl cist sitovou komunikaci, tak to je lehke.
mi jen pristup k ip serveru, tak je to slozite, protoze se musi zkouset, neni pristup ke klientu ani k existujici komunikaci.
-
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á?
Hrozby se většinou kombinují. Např. botnet se šíří a rozšíří se nepozorovaně do různých sítí. Teprve na pokyn začne dělat činnost č. 2, tedy samotné sledování nebo zásah do dat. Pokud se takové práce ujme botnet, může Vám být srdečně jedno, jestli to umí jeden z milionu nebo deset ze sta.
Jinými slovy, i kdyby se Vám dnes zdálo, že není velká pravděpodobnost, že by Vás to ohrožovalo, tak zítra můžete být vyveden z omylu.
Pokud se v příkladech píše "někdo na trase", neznamená to geeka číhajícího u klávesnice, ale obecně jakékolovi zařízení - např. jiný napadený počítač, router, ...
Dále pak musíte počítat s riziky od konkurence nebo od (bývalých) zaměstnanců. Ti mohou škodit cíleně.
U bezpečnosti se tedy moc neřeší pravděpodobnost, ale spíš jak moc by Vás to bolelo, kdyby to nastalo.
-
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.
-
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 (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.
-
No úplně na koleně to být nemělo. Chtěl jsem použít https://github.com/kokke/tiny-AES-c (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é.
Nepopsal jsi jak pak proběhne to samotné ověření (a jak je dále zajištěna integrita dat). A pro začátek u CTR můžu flipovat jednotlivé bity ciphertextu a tím se flipují bity na stejné pozici v plaintextu.
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 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.
-
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í.
-
Protokol je jasně daný
No a kde teda je popsaný?
-
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...
-
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í.
-
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í.
No minimálně by se nám hodilo vědět jak funguje ta autentizace, nebo alespoň co autentizace je (to by šlo asi i uhodnout kdyby se těch zpráv nasniffovalo víc, bude to něco na začátku co vypadá náhodně). Samozřejmě se neptám na formát payloadu, to je mi fuk a nezajímá mě.
-
Š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.
-
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á.
No, jestli tomu dobře rozumím, tak tvoje komunikace je bezpečná pouze pokud máš síť mezi klientem a serverem pod svoji kontrolou (třeba díky VPN).
Pokud ne, tak případný man-in-the-middle může počkat, až si klient zahájí komunikaci, unese TCP spojení a klientovi poslat něco ošklivého, a serveru třeba, hmm, RST.
Tím že komunikace byla nezabezpečená, MITM měl dost času naposlouchat správný formát a zjistit co klient rád přijme.
Moc nerozumim tomu, jak by někdo třetí, který sedí někde buhví kde
Vhodné scénáře nasazení MITM, třeba pomocí social engineeringu jsou publikované, HW nástroje typu badUSB jsou dostupné.
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.
zde je vidět jak naši IT odborníci pracujou
často to je tak, že dostaneš to, co si zaplatíš, a nebo taky že se na projekt nabalují nové a nové features, až původní koncept přestane dostačovat.
-
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.
-
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
-
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ý.
-
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čí?
-
Nějakej osvědčenej typ na model se kterým se každej naučí?
výhoda mikrotiků je, že maj všechny stejnej koncept konfigurace, takže není rozdíl mezi 8-portovým routerem který mi běží v serverovně, wifi krabičkou kterou jsem u kohosi doma řešil wifi a CPE boxy kterejma jsem za starejch špatnejch časů tahal internety po střechách.
Takže si klidně pořiď něco, co ti bude vyhovovat velikostí a počtem portů - hEX lite nebo mAP (to dvojportový mysím)
-
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: 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.
-
To asi prohlížeče vyžadují https jen pro buzeraci majitelů stránek.
-
IMHO tady nikdo nebude jen tak něco hackovat, protože to může být ilegální a proč by to někdo dělal?
Ale hacknout to určitě jde a může se to stát i mimochodem. Takže by se to mělo řešit jaksi projektově v rámci kompetencí.
Že nebudete ani první ani poslední, komu se to přihodilo, je vidět například z osudu zdravotnických zařízení.
-
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á?
Schopnosti na to má velká spousta lidí. Jediné reálné omezení je motivace. Pokud napadením útočník nic nezíská, budou to nejspíš zkoušet jenom tací, kteří si prostě jen něco chtějí zkusit. Buď si dokázat, že to zvládnou, nebo se na tom něco naučit. A pak je samozřejmě otázka, zda narazí zrovna na vaše zařízení.
Úplně něco jiného ale je, pokud tím může útočník něco získat. Nebo vám způsobit škodu a tím pádem vás vydírat („zaplaťte, nebo vám způsobím tuhle škodu“). Může vám tím útočník způsobit škodu 5000 Kč? No, pak se asi nikdo nebude obtěžovat. Může tím poškodit zařízení, pokazit pověst firmy, zmařit třeba investice v řádech statisíců nebo milionů? Pak už výhružka „pošlete mi 100 000 Kč v bitcoinech, nebo několik vašich zařízení vypnu“ dává smysl a za tu částku už se někomu vyplatí se tomu věnovat.
Pokud máte přístup ke klientovi a serveru, odeslat data samozřejmě můžete. V drtivé většině případů byste to mohl udělat i tehdy, pokud byste měl přístup jen k routeru některé z těch sítí. Kdybyste měl přístup jen do některé z těch sítí (ne přímo na router), bylo by to jen o něco složitější.
Nevím, co je to za zařízení a co si tam můžete dovolit implementovat. Pokud je to nějaký hardware, na kterém běží linux (nebo něco o něco menšího), moc bych se s tím nepáral a použil bych HTTPS. Pokud trváte na tom, že ta data musí být veřejná a chcete zabezpečit jenom důvěryhodnost příkazů ze serveru, pak je podepisujte. Ideálně podpisem založeným na asymetrické šifře – zařízení budou mít veřejný klíč, server bude podepisovat privátním. Pokud můžete zařízením důvěřovat, že z nich nikdo nevydoluje citlivé informace, můžete podepisovat i jenom hashem. Pošlete ze serveru zprávu, ke zprávě připojíte tajné heslo a to celé zahashujete – a ten hash pošlete na konci zprávy. Klient bude znát stejné tajné heslo a s přijatou zprávou provede to samé. Když mu vyjde stejný hash, ví, že to posílal oprávněný server.
-
jak se vyvarovat chyb. Jedna rada byla: Znovu a znovu vynalézejte kolo.
Napadá mě otázka čemu pak věřit.
"Why shouldn't we create our own security schemes?" - https://security.stackexchange.com/questions/18197/why-shouldnt-we-roll-our-own
Pořád by mě ještě zajímala odpověď na to, zda by to někdo tady skutečně dokázal prolomit
Koncept jsem ti výše napsal. MITM. - https://www.greycampus.com/opencampus/ethical-hacking/network-or-tcp-session-hijacking
Pořád by mě ještě zajímala odpověď na to, zda by to někdo tady skutečně dokázal prolomit
Tohle se dodává jako služba, akorát rýpat se v custom aplikaci něco stojí - ať se dostaneš do kontextu, testování vlastních řešení je v té "premium": https://csirt.cz/cs/penetracni-testovani/
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.
huh.
-
No žádná autentizace tam teď v podstatě není, ale možná si jen nerozumíme :-)
Aha, tak o čem se bavíme? Jestli dokážeme v TCP spojení, které přes nás jde, nahradit jedny ASCII znaky za jiné ASCII znaky (a přepočítat CRC)? Na to je všude na netu návodů hromada, ale jestli chceš, tak to za těch 5kKč klidně naprogramuju :).
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=")
Zbytečně složité, stačí do zařízení poslat zašifrovaný text a zařízení ho pošle rozšifrovaný (nebo naopak, ale ono je to v CTR módu vlastně jedno).
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)
Tím se zajistí, že klient i server si musí rozumět a můžou spolu komunikovat.
No dobře, tím server ověřil, že komunikuje se správným klientem. Jak je tohle ale navázáno na celý zbytek komunikace? Co se stane, pokud v tento okamžik do komunikace vstoupí útočník?
Je to mnohem horší, což osobně vidím jako velkej průser.
No tak si na to najměte konzultanta. Já se klidně hlásím, když mě trochu postalkuješ tak najdeš že mám za sebou pár projektů podle kterých bych toho měl být schopen (a už jsem vám poradil to OpenWRT :)). Jenom se bojím, že mě nedokážete zaplatit, když s tím zjevně zápasíte několik let a za tu dobu jste nedokázali sehnat programátora co by tomu rozuměl.
Nějakej osvědčenej typ na model se kterým se každej naučí?
Tohle je běh na dlouhou trať, pokud chceš rozumět těm principům za tím, tak budeš muset nastudovat aplikovanou kryptografii (začal bych tady: https://cryptopals.com/) a sítě (začal bych tady http://www.earchiv.cz/l225/index.php3 a tady http://www.earchiv.cz/l226/index.php3). Pokud chceš hotové bezpečné řešení, tak nějakou existující knihovnu implementující široce známý standard (např. TLS). Pokud to tvůj embedded systém neumí a potřebuješ si napsat něco vlastního, tak to opravdu bez porozumění výše uvedeným zdrojům nedáš.
Jestli ses ptal na model routeru, tak bych doporučil tyhle levné bílé mikrotiky - https://www.alza.cz/mikrotik-rb750r2-d2646618.htm (existuje jich víc, RB750, RB952… pro tebe jsou všechny ekvivalentní) a do toho flashnout OpenWRT. Pokud je 900 Kč za Mikrotik moc, tak bych zkusil na AliExpressu GL-MT300N-V2, který stojí polovinu, ale je to „neznačkové“ řešení.
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.
Já teď nevím co teda jako máme ukázat že prolomíme. Jde o to editování spojení které přes nás jde, příp. jsme ho na sebe přesměrovali třeba pomocí ARP spoof? Jako sorry, ale to je snad síťařské „101“, ne?
-
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ý.
-
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 (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 :-)
-
Je to symetrická a asymetrická, ne synchronní a asynchronní ::)
Asymetrické šifrování je složité implementovat a na omezeném hardwaru je složité ho počítat. Pro tvůj případ si vystačíš se symetrickým. Budeš potřebovat blokovou šifru (AES) a hash (SHA-256 a z toho odvozený HMAC). Oboje se do malého prostoru snad vejde.
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á?
Nebude, a problém je v tom counter módu. Jak už jsem psal a jako hardwarář by sis měl hned uvědomit, tak když to dělá XOR s keystreamem, tak můžu pomocí XORování těch šifrovaných dat ta data pod tím libovolně měnit. To nemusí být nutně na závadu, i když bych osobně raději použil mód CBC (který ale tímto problémem částečně trpí taky, a na tom Matasano je na tohle cvičení), pokud tuto změnu dat zjistíš. A k tomu právě potřebuješ ten HMAC. Takže na konec zprávy přilepíš její HMAC (pozor, používá se schéma encrypt-then-MAC, tj. HMAC spočítáš ze zašifrované zprávy) a tím to máš ověřeno. Pak ještě chceš mít nějaké počítadlo nebo náhodnou challenge aby nešly dělat replay útoky a pak bych tomu řešení už docela věřil.
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.
Upřímně já to taky chápu na úrovni „algrebra magic“ [mává rukama]. A jinak implementovat RSA from scratch je o držku, protože tam jsou věci jako padding, správná volba exponentu a tak. U ECC je to podobně příšerné, různé handlování nevalidních bodů na křivce a tak. Proto bych se tomu snažil co nejvíc vyhnout a používal bych symetrické řešení.
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.
Ano, to je v pořádku.
-
Ještě jsem si vzpomněl na tohle http://mj.ucw.cz/vyuka/2021/kry/, „díky“ koronaviru tam jsou záznamy přednášek pro vzdálené studium. Nekoukal jsem na to, ale možná to bude vyžadovat trochu matfyz-level matematiky, a nevím, jak to bude srozumitelné bez toho.
-
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.
Předpokládám, že myslíte symetrické a asymetrické šifrování.
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.
Takže co potřebujete zajistit – utajení dat, jejich nezměnitelnost, nebo obojí?
1. Je lepší použít synchronní šifru nebo asynchronní (je nějaká jednoduchá na implementaci)?
Záleží jak na co :-) Symetrické šifrování používá na obou stranách stejný klíč, takže musíte věřit oběma stranám (a musíte být schopen klíč na obě strany bezpečně dopravit). U asymetrické šifry se šifruje veřejným klíčem a dešifruje privátním. Asymetrické šifry jsou podstatně pomalejší, než symetrické – takže pokud je potřeba šifrovat větší množství dat (třeba ve spojení), vytvoří se na začátku klíč, který se vymění pomocí asymetrického šifrování, a dál už se šifruje symetricky s pomocí toho klíče.
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á?
Viz výše. Úvodní výměna klíče se obvykle řeší asymetrickou šifrou. Případně pokud je komunikace déle trvající, klíče se v průběhu ještě obměňují.
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.
To, že je veřejný a privátní klíč, je naopak obrovská výhoda. Šifrovat pak může kdokoli (šifrovací klíč je veřejný). A je to opačně, než jste napsal – šifruje se veřejným, dešifruje privátním. Opačné pořadí se používá pro podepisování (podepisuje se privátním, podpis ověřuje veřejným).
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ý.
Viz výše – co přesně potřebujete zajistit? Aby data nikdo neviděl, aby je nemohl změnit, nebo obojí? Je to stejné v obou směrech komunikace nebo v každém směru jiné?
-
Pro tvůj případ si vystačíš se symetrickým. Budeš potřebovat blokovou šifru (AES) a hash (SHA-256 a z toho odvozený HMAC). Oboje se do malého prostoru snad vejde.
A kdyby se nevešlo, tak hash se dá použít jako šifra v counter mode (jednoduše hashuješ klíč + zvyšující se počítadlo a to generuje keystream), a naopak bloková šifra se dá použít jako hash (detaily jsem zapomněl). Ale je to další věc, ve které se dají nasekat chyby, takže to radši nedělej.
-
Je to symetrická a asymetrická, ne synchronní a asynchronní
Jak jsem spise z toho fochu drateniku, tak hold vsude vidim motory a generatory :)
-
Je to symetrická a asymetrická, ne synchronní a asynchronní
Jak jsem spise z toho fochu drateniku, tak hold vsude vidim motory a generatory :)
:-) Je to pojmenované podle těch klíčů. Symetrická má na obou stranách stejný klíč, je to tedy symetrické, strany nelze rozlišit. Asymetrická používá veřejný a privátní klíč, proto je to asymetrické – strany se liší.
-
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.
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
-
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.
To je dost odvážné tvrzení :-) CRC je příliš krátké na to, aby někoho určitě zastavilo. Útočník akorát nepošle změněná data hned na první pokus, ale bude muset vystřílet těch pokusů víc.
Popravde receno utajit je nepotrebuju, ale nesmi byt zmeneny.
Pokud to opravdu stačí, stačí ta data podepisovat. Buď klasicky asymetrickými klíči, nebo pokud můžete klientům věřit, pak stačí použít ten hash (data + sdílený klíč). Inspirovat se můžete třeba u JSON Web Token, jakým způsobem je to podepisováno.
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
To je zase jiná věc – obrana proti replay attack. Tam je potřeba vyřešit, aby každý požadavek musel být jiný. Například můžete na obou stranách držet sekvenční číslo – server zvýší číslo o jedničku a pošle požadavek. Klient si ověří, že sekvenční číslo požadavku je nižší, než poslední známé číslo – pokud ano, požadavek je platný a provede se, a čítač se posune na nejnovější číslo. Kdyby útočník vzal data a poslal je znovu, klient bude vědět, že tohle sekvenční číslo už vylo použité dříve a že je to opakování požadavku. Díky tomu, že to celé máte v TCP/IP spojení, nemusíte řešit, že by požadavky přišly v jiném pořadí. Ještě bude potřeba dořešit přetočení sekvence – buď ji nadimenzovat tak, aby se nikdy nepřetočila (např. pokud zařízení fyzicky zvládne provést cca 1000 příkazů a pak už bude tak opotřebované, že přestane fungovat, je sekvence s prostorem 4 miliardy hodnot dostatečná rezerva). Případně se dají sekvenční čísla počítat jen v rámci jednoho TCP/IP spojení, pak ale zase musíte řešit, jak zabránit tomu, aby útočník nezopakoval celé dřívější spojení (nebo jeho začátek). Pomůže třeba pokud má ten klient přesný čas (pak může být součástí přenášených dat, klient ho ověří – pokud by někdo data zopakoval, buď nebude sedět čas, nebo opakování přijde velice rychle za sebou – předpokládám, že pokud přijdou třeba během vteřiny dva příkazy na zavření ničemu to nevadí).
Akorát to trochu vypadá, že tu znovu vymýšlíme TLS. A to není zrovna jednoduché – i experti v tom dělají chyby, takže dnes už máme 6. verzi. Chápu, že bude problém použít hotovou knihovnu, implementovat celé TLS na zelné louce je hodně náročné – ale tohle vyzobávání dílčích částí, které vám budou stačit a které bude snadné implementovat, určitě povede k tomu, že na něco zapomeneme. Další věc je, jakou úroveň spolehlivosti potřebujete. TLS věří i banky a vlády, vám možná stačí nižší spolehlivost, takže by pak nemuselo tolik vadit, že tam budou nějaké menší díry, které bude relativně náročné zneužít.
-
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). I kdyby jste pouzili sebelepsi asymetricke krypto pro podepisovani dat, tak prvni co utocnika napadne je vydolovat klic z fyzickeho zarizeni.
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).
-
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 ;D
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).
-
Š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 :)
-
Š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.
-
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
-
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.
-
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.
-
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.
-
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ů.
-
Š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.
-
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.
-
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...
-
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.
-
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?
-
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 (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 :D
-
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 (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 :D. 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.
-
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.
-
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.
-
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 (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 (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
-
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í)
-
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.
-
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.
-
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.
-
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 (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 (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
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
WTF WTF WTF. Máš docela dobrou historii, takže věřím, že nejsi troll, a ještě to zkusím.
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.
Ale tohle přece není ten případ, který tazatel řeší.
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.
Každý endpoint má vlastní klíč, a když vyrobíš nový jako náhradu za shořelý starý, tak do něj samozřejmě také nahraješ nový, unikátní, vygenerovaný, náhodný klíč. Je ti úplně jedno, že u ostatních endpointů jejich uživatelé klíče znají a třeba je pověsili na nástěnku a zná je kde kdo - pro ta zařízení, u kterých klíče kompromitovány nebyly, je znalost jiných klíčů úplně k ničemu.
-
Tak ono postaci nejake minimum (jedna sifra, jeden rezim), a protistrana se patricne nastavi.
Co konkrétně je to minimum a jak obtížné bude implementovat to?
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.
Dokud si budete myslet, že je problém, když někdo získá veřejný klíč, jsou vaše pohádky o bezpečnosti k ničemu.
Jasně, k nějakému termostatu nebo dvířkům do kurníku ovládaným z mobilu si budou lidi pořizovat HSM.
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.
O žádné bezpečné síti ale nebyla řeč. To jste si zase jen vymyslel další nesmysl.
Prosím vás, představte si třeba krabičku u bojleru, která je schopná mi do mobilu hlásit aktuální teplotu vody a spotřebu elektřiny. A také umí na povel z mobilu ten bojler zapnout nebo vypnout – abych si mohl ohřát vodu před tím, než přijedu na chatu, a bojler mohl zase vypnout z domova, když zjistím, že jsem na to na chatě zapomněl. To je podle dosavadního popisu zhruba úroveň zařízení, o kterém se tu bavíme (možná bude ve skutečnosti o málo závažnější). Takže jde o to, aby mi hacker ten bojler nezapnul v listopadu a neohřívala se tam voda zbytečně několik měsíců, když tam nebudu. A aby mi zlomyslný soused nevypnul bojler půl hodiny po té, co jsem si ho zapnul před odjezdem na chatu. Pokud se někdo do té chaty vloupá, tak bojler zapne normálně knoflíkem na té krabičce, a nebude z té krabičky získávat šifrovací klíč, aby mohl hacknout komunikaci a zapnut ten bojler přes mobil. A určitě k tomu bojleru nebudu budovat vyhrazenou síť, pronajímat černé vlákno a klíč ukládat do HSM.
Myslim ze resit protokol samo o sobe je malo - jestli to chce mit autor bezpecnejsi, mel by o tom premyslet jako o celku.
Nemyslím si, že by to chtěl mít autor bezpečnější. Autor akorát nechce, aby si s tím zařízením mohl hrát každý desetiletý kluk z Číny.
-
Samozřejmě, ale tazatel je bohužel v situaci, že tam plnohodnotnou knihovnu pro TLS nedá,
IMHO jediná správná cesta je takové zařízení oddělit od NETu něčím, co zvládne spolehlivý ověřený
transportní protokol(ať už nějakou VPN, TLS, nebo nevímco).Cokoli jiného je hezké pro naučení se, ale jinak to bude vždycky ve výsledku dražší a přitom děravé.
-
Tak Integritu bychom měli na straně 4 a Důvěrnost bychom měli na straně 3, a Utajení na straně 5.
Ale jaké má tazatel nároky na Robustnost, co když někdo překopne kabel (https://www.youtube.com/watch?v=BlCI8iXmm_o) , a měsíc si nanastaví teplotu bojleru?
A možná jsem zapomněl na ochranu proti replay útoku, ale to se tá zamést pod Integritu.
PS: co je to černé vlákno? Má to něco společné s černým rybízem nebo pasažérem?
-
PS: co je to černé vlákno? Má to něco společné s černým rybízem nebo pasažérem?
To je vlakno ve kterem neni zadne svetlo, logicky tam tedy je černočerná tma...
-
Zde bude nejjednodušším řešením použít standardní IPSec ať už v čistě transportním nebo v běžnějším tunelovacím módu dle potřeby a stávající konfigurace. Implementace není nic složitého...