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.
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.
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.
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.Myslel jsem si, že vůbec nechápete princip asymetrické kryptografie. Děkuji, že jste nám to potvrdil.
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.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.
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 daneAno, 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ý.
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.
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 naposledTo 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í).
CitaceJe to symetrická a asymetrická, ne synchronní a asynchronní
Jak jsem spise z toho fochu drateniku, tak hold vsude vidim motory a generatory
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í.
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é?
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í.
Otazka je kdo a proc ji oznacil jako duveryhodna.Když si seznam důvěryhodných autorit sestavujete sám, označil jste ji za důvěryhodnou vy. Když Používáte seznam vytvořený někým jiným, označil ji za důvěryhodnou někdo jiný. Typické je, že používáte seznam důvěryhodných autorit dodaných výrobcem operačního systému / distribuce nebo prohlížeče.
Nemluvim o teto ale obecne, ja neduveruji v podstate zadne protoze je to jen byznys.Co jiného než byznys by to mělo být? Zrovna to nepřijít o ten byznys je docela dobrá motivace, proč dodržovat pravidla.
TYPICKÉ ZNAKY PODVODNÉ ZPRÁVY ČI TELEFONÁTU:
Zpráva obsahuje ODKAZ PŘÍMO DO INTERNETOVÉHO BANKOVNICTVÍ nebo na stránku pro ověření Vašich údajů.
JAK SE CHRÁNIT?
Do internetového bankovnictví Raiffeisenbank se vždy přihlašujte přes www.rb.cz.
A tak nějak z podstaty mi přijde bezpečnější autentizace heslem na PC s linuxem + pomocí SMS (na "hloupém telefonu"), než se jakkoliv autentizovat jen na jednom zařízení (telefonu, kde tak nějak z podstaty se dá předpokládat větší zacílení malwaru a spol. - právě protože to tak používá "každý").To ovšem vycházíte z předpokladu, že na tom PC s Linuxem a na mobilu je stejný bezpečnostní model. Tento předpoklad ovšem není splněn. Tudíž je rozdíl v tom, co může udělat malware na mobilu a co může udělat malware na PC.
Prosím experty o radu. V naší nemocnici ukládáme i dosti těžké případy Covidu na oddělení, která rozhodně nejsou určená pro intenzivnější péči. V řadě případů je potřeba monitorace životních funkcí (t.j. tlak, tep, prokysličení, ev. EKG) a přenos těchto informací k lékaři.
Normálně se to na JIPkách řeší tak, že u každého pacienta je monitorovací jednotka s čidly, která přenáší kabelem tyto informace na centrální monitor do pracovny lékařů.
A můj dotaz je, zda by se to dalo zaimprovizovat i na oddělení, které k tomu naprosto není uzpůsobeno.
Teze:
1) Pro naše potřeby stačí snímání tepové frekvence (TF) a okysličení (spO2). Běžně se dají celkem levně koupit tzv. oxymetry, které to umí. Lepší z nich umí spárování přes bluetooth s telefonem nebo tabletem.
2) Moje představa je, že na ten telefon nebo tablet by se nainstalovalo NĚCO, co by tato data po wifi posílalo někam na server.
3) Doktoři by ve svých pracovnách měli puštěné okno prohlížeče, ve kterém by byla načtené jakési rozhraní k těmto zasílaným datům a ve výsledku by v reálném čase viděli hodnoty TF a spO2, tak jak to ten oxymetr snímá.
Jak těžké je to realizovat?
Nechci trolit ale IMHO při platbě embosovanou kartou pomocí té "žehličky" se na formulář otiskne nejen číslo karty, ale také jméno a platnost.Ano, jenže jméno je veřejný údaj – pokud by se jednalo o e-mailový phishing, je nutné předpokládat, že odesílatel e-mailu jméno zná. A platnost – když budu předpokládat pětiletou platnost karty, nejpozději na 60. pokus to útočník trefí, reálně podstatně dřív.
Takže samotné číslo karty IMHO na platbu nestačí.
Nicméně je možné ale že v určitých případech postačí číslo a alespoň platnost (osobní zkušenost s neautorizovanými platbami z usa).
Root.cz (www.root.cz), informace nejen ze světa Linuxu. ISSN 1212-8309
Copyright © 1998 – 2023 Internet Info, s.r.o. Všechna práva vyhrazena. Powered by Linux.
