Příspěvky

286

Vývoj / Re:Šifrovací knihovna s obtížným dešifrováním

« kdy: 03. 02. 2014, 22:29:23 »

Tak jenom kvůli tomuhle bych ten program chtěl vidět. Kdybych ho chtěl spustit na 10 počítačích v 10 městech, které nebudou nijak připojeny do sítě, tak spolu ty instance budou komunikovat ultrazvukem vytvářeným vibracemi procesoru, nebo jak, aby jste zajistil jedno spuštění za XY sekund napříč všemi instancemi? Přidat do programu sleep není problém, ale Ondřej Novák chtěl něco odolného i proti tomu, že útočník ten sleep dokáže odstranit. Ostatně, pokud váš nastavovací algoritmus opravdu dokáže heslo prodloužit, tak nepotřebujete podvádět snadno odstranitelnými zdržovačkami. A vy jste chtěl přece ukázat, že zdržování rozšifrování není potřeba, že je lepší heslo nastavit.

Já předpokládám, že útočníkovi se dostane do rukou binárka a zašifrované klíče a z mého pohledu (z uživatelského pohledu) téměř nekonečný výpočetní výkon (clustery grafáren v nějaké šílené farmě)

287

Odkladiště / Bezpečný přenos hesla/klíče

« kdy: 03. 02. 2014, 21:45:23 »

Ahoj.

Tak zajímavě se rozjela diskuze o obtížném dešifrování, doufám, že stejně dobře mi poradíte i v tomto případě. Potřebuju bezpečně přenést heslo/klíče z jednoho počítače na druhý, který má bohužel jednu zásadní nevýhodu. Je pořád stejné. Ale mělo by se vždy po použití smazat. Přesněji je součástí jiného většího hesla/klíče a slouží k tomu, aby k odemčení zašifrovaných dat byly vždy dvě strany. Ta druhá strana zároveň svou částí hesla autorizuje požadavek, který zasílá, tedy mělo by být nemožné, aby se za tuto stranu někdo vydával. Je samozřejmě jisté že,

1. přenášet mohu pochopitelně po zabezpečeném kanále (SSL/TSL)
2. mohu k autentifikaci použít digitální podpis.
I tak to ale znamená, že přijímaci strana musí vědět, že nebyla oklamána. Ideální bylo, kdyby součástí požadavku bylo i heslo k odemčení zabezpečených dat nutných k dokončení akce.

Příklad.
Mám dva stroje.
1. agent
2. master

Agent se neustále chodí ptát mastera na úkoly a pokud se objeví úkol, master mu v odpovědi zašle parametry úkolu. Předpokládá se, že agent je zodpovědný za provedení zabezpečené operace například s citlivými daty (třeba výplatu peněz).

Je mi blbý do odpovědi dávat přímo to heslo, i když bude putovat zabezpečeným kanálem. Lepší by bylo, kdyby heslo bylo předáno po kanálu nějak fikaně. Třeba jako OTP autentifikace. Ale je potřeba nakonec získat vlastní text hesla, tedy nestačí jen potvrzení Ano/Ne, zda druhá strana se správně identifikovala.

Opět jsem nejprve použil googla, abys se pokusil najít řešení vlastními silami. Dovedlo mě to k D/H key exchange a RSA.

• Agent pošle na mastera požadavek a s ním vyšle náhodný řetězec jako challenge
• Master kromě toho, že sestaví odpověď, tak provede výpočet X = F(a,b,s), kde X heslo, který chci přenést, F je hledaná funkce, a je challenge, s je tajná hodnota, kterou mohou znát obě strany, ale by se X nemělo nechat spočítat. Server vypočítá b a odešle ho v odpovědi.
• agent přijme b, hodnotu a zná,  spočítá F(a,b,s) a získá X. to použije na odemčení zabezpečených dat a pak X z paměti vymaže.

Pokud by vládu nad agentem převzal útočník, nebude schopen spočítat b, protože nezná x. I kdyby se mu podařilo agenta kompromitovat (třeba pomocí jiné chyby) a vyřadil by kontrolu autorizace požadavku, tak bez správného hesla a tedy hodnoty x nezmůže nic.

Otázka zní, jaká je funkce F.

Napadla mě primitivní odpověď jako příklad   F(a,b,s) = a XOR b XOR s.  Ze znalosti X,a,s jsem schopen spočítat b. Ze znalosti a,b,s jsem schopen spočítat X. Ovšem bez jedne z obou proměnných X neodvodím.

A otázka. Kde bych hledal podobnou funkci, ale s mnohem lepší implementací. Cílem je, aby v případě, že útočník získá jedno nebo i oba řetězce (například z komunikace), aby i tak nebyl schopen spočítat X a zejména pak simulovat mastera a tím ho donotit provést neautorizovanou operaci.

PS: není to jediné zabezpečení

288

Vývoj / Re:Šifrovací knihovna s obtížným dešifrováním

« kdy: 03. 02. 2014, 16:13:27 »

- Pokud tedy napriklad zvolime SHA512 misto SHA256, je to ekvivalentni tomu, prodlouzit cas desifrovani o 2^256. :-) Pochybuji, ze bude uzivatel ochoten tak dlouho cekat, kdyz zivotnost vesmiru je nekde kolem 2^60.

Jinak receno, zvolte delsi klic, bude to mnohem efektivnejsi, a hlavne (jak uz tu nekdo zminil) nezapomente na salt.

Pořád je to o tom, že nakonec tam to heslo zadá člověk, který ho musí mít v hlavě, pokud si ho tedy nezapsal na papír (což by neměl). Nebo snad považujete privátní klíč k bitcoinové peněžence uložený v dropboxu zašifrovaný heslem o délce osm znaků i přesto že používá čísla symboly za bezpečné uložení?

Já si nejsem jist (ačkoliv takový klíč tam mám)

289

Vývoj / Re:Šifrovací knihovnu s obtížným dešifrováním

« kdy: 03. 02. 2014, 14:51:59 »

Jestli ho chápu správně, netvrdí, že tím primitivním postupem udělá ze slabé šifry silnou, ale že jednoduchou úpravou podstatně ztíží dešifrování, což je přesně to, o com v tomhle vláknu jde. Mě se ten jeho postup líbí, vezme šifru třeba AES+Twofish a přidáním

Já tam vidím problém ten, že pokud někdo zjistí, jak se tvoří ty dlouhá hesla, pak nebude pro něj problém nasadit brutalforce attack před jeho úžasný algoritmus a tím smrsknout problém jen na krátké heslo. Proto mi přijde navržené PBKDF2 lepší, protože tam bude proti útočníkovi stát čas a výpočetní výkon. Útočník si tak může vybrat, jestli se mu vyplatí louskat původní heslo, nebo jeho derivovanou podobu. V obou případech to bude mít náročné.

290

Vývoj / Re:Šifrovací knihovnu s obtížným dešifrováním

« kdy: 03. 02. 2014, 14:42:17 »

TVŮJ SOFTWARE NIKOHO NEZAJÍMÁ!

Pokud bude můj software spravovat nějaké peníze, cryptoměnu nebo něco jinak hodnotného, tak bude zajímat každého. Tohle je snad největší chyba, kterou člověk může ve svých úvahách udělat!

Hodně právě uvažuji nad tím, jak ochránit dedikovaný počítač proti leaknutím důležitých informací vedoucí k neoprávněnému získání spravovaných hodnot.

Jaké jsou tam rizika?

• Klasické napadení z venku (vlámat se dovnitř skrze známou chybu a plně jej ovládnout)
• Ovládnutí z venku (přesvědčit stroj, aby mne poslouchal)
• Ukrást ho fyzicky
• Ukrást některou HW součást (HW klíč, disk)
• Přinutit provozovatele telehausu, aby udělal kopii stroje + dump paměti
• Riziko že si ho vykrade sám majitel nebo společník

Zatímco první bod jsem schopen řešit třeba tak, že stroj nebude jednat jako server, tedy bude se chovat jako klientský počítač, nebude mít otevřený žádný port například, Druhý bod už je těžší, protože znamená to, že útočník musí získat kontrolu na počítačem, který tenhle stroj poslouchá a věří mu (master). Zabezpečení HTTPS např. nebo vzájemná autentifikace stran, vyhnout se DNS a podobně může pomoci tím, že útočník nebude moci dotazy stroje přesměrovat a vydávat se tak za mastera

No a teď jsem se dostal k bodům, kdy se řeší, že informace uložené na serveru leaknou jinou cestou. Když už se útočník dostane do stroje, tak z něho pouze vytáhne údaje, klíče, hesla, a teď jde o to, aby mu to i přesto bylo k ničemu. Pokud ho ukradne fyzicky (tedy ho bude muset například odpojit) nebo mu ukradne disk, tak je zde možnost snížit riziko ukradení tím, že některá část hesla bude uložena v paměti, zadaná při startu systému a odpojením se ta informace smaže. Pokud ale získá i DUMP paměti, je to víceméně v háji.

Decryptace lze řešit C++ kódem, což je jen o píď lepší, než to když to bude napsané v pythonu nebo v PHP. Záleží, co útočník získá. Například se do stroje vláme jako user s omezenými právy, tak pravděpodobně nezíská binárku (bude spouštěná pod rootem a následně se jí ponízí práva). Skriptovací jazyky zpravidla vyžadují, aby kód byl dostupný pod uživatelem, ve kterém je proces spuštěný (takže je útočník může získat)

Zpět k tématu, nebudu uvažovat plné ovládnutí stroje a získání všech klíčů, včetně zadaných (část klíče může být zasílána z mastera při každém požadavku, takže samotný dump stroje i s paměti nemusí dostačující, bude vyžadovat aby se stroj spojil se svým masterem). Když už útočník získal všechny klíče ale vše má zašifrované, chybí mu jedna část, kterou nezískal, může si jí dopočítat. Proto mi připadá rozumné, aby zde byl i nějaký časový faktor, klidně hodně přehnaný, klidně vytažen i na jednotky sekund, aby útočník nemohl klíče, které nezískal rychle dopočítat.

Jinak ještě k posledním bodům. Předposlední body lze asi řešit diverzifikací... tedy nedržet vše na jednom místě a tím vytvořit single point of failure. Riziko majitele a společníka bude potřeba asi řešit na straně práva.

Cold wallet samozřejmě uvažuju také, pokud jde o cryptoměnu.

291

Vývoj / Re:Šifrovací knihovnu s obtížným dešifrováním

« kdy: 03. 02. 2014, 12:13:19 »

Odpovím na otázku k čemu jsem to chtěl.

Když zašifruju privátní klíč k bitcoinové adrese pomocí passphrase, jakou jistotu mám, že mě to ochrání při zcizení toho klíče. Útočník vesele provede útok offline a pokusí se uhodnout moji passphrase. Bude na to mít ohromné množství času a ohromné množství výpočetního výkonu. Proto jsem hledal způsob, jak udělat, aby dešifrace  privátního klíče správným heslem trvala co nejdéle. Klidně i minutu. To chci pak vidět, kolik prostředku bude muset útočník investovat do takového lámání hesla, aby to rozlousknul v reálném čase.

(Nejvíc se mě líbí hláška u NXT - vaše passphrase je moc krátká, úročník ji může lehce ohalit: Napsal jsem tam celé jméno a příjmené své dcery i s datumem narození a místo mezer strčil nějaké ty symboly)

292

Vývoj / Re:Šifrovací knihovnu s obtížným dešifrováním

« kdy: 01. 02. 2014, 16:07:53 »

Chceš použít nějakou key derivation function, třeba PBKDF2 nebo scrypt. Tyhlety funkce mají jako jeden z parametrů počet iterací. Ten nastavíš tak vysoko, aby operace trvaly (pro tebe) přijatelně dlouho.

Díky, našel jsem i nějaké zdrojáky, které PBKDF2 počítají, tak si to s tím zkusím.

293

Vývoj / Šifrovací knihovna s obtížným dešifrováním

« kdy: 01. 02. 2014, 13:01:45 »

Zdar

Potřebuju poradit, ukázat kde hledat následující (bohužel nevím, jak se zeptat googla)

Knihovnu (nějaký libXXX-dev, ještě lépe se zdrojáky) která by realizovala šifrování a dešifrování s tím, že při zadání správného hesla by dešifrování trvalo nějakou významnou dobu, třeba stovky milisekund až sekundy. Ideálně, kdyby se obtížnost zašifrování dalo nastavit při šifrování.

Cílem je významně ztížit offline louskání hesla brutal force. Je mi jasné, že když útočník použije nějaký distribuovaný systém louskání, tak že stejně nemám moc šancí, ale to bych řešil tím, že bych obtížnost nastavoval podle toho, jakou data mají hodnotu. (příklad... zašifrování privátního klíče bitcoinové adresy)

Nějaký nápad?

294

Vývoj / Re:Jazyk podobný C#

« kdy: 17. 01. 2014, 16:08:17 »

Já vím, že pro linuxáka je to urážka něco takového vytahovat, ale co takhle jazyk

C++

295

/dev/null / Re:Nevzdáváme to - nová burza bitcoinů

« kdy: 15. 01. 2014, 17:04:10 »

Je vůbec možný to dát takhle rychle do kupy a hlavně do ostrého provozu?
Vždyť takhle rychle nevznikne ani program na daňovou evidenci.
A chtěl bych vidět jak to mají právně všechno ošetřeno.

Demo aplikace byla za 14 dní. Ale je fakt, že to rozběhli na můj vkus moc rychle. Já jsem původně plánoval ostrému provozu dát tak tři možná čtyři měsíce. To bylo prý moc.

Docela mě mrzi ale i těší, že provozovatel se nezměnil. Trochu to dává za pravdu mému přesvědčení, že ten placeholder, ta firma tam napsaná nakonec nebyl placeholder, ale člověk, který to měl převzít. Zda zaplatil za práci ostatním mi není známo - mne tedy nikdo nezaplatil, a je dobře, že jsem odešel tak brzo, než být odejit po tom, co bych vyplácal moře energie na těch nejzásadnějších core věcech.

Takový projekt si člověk musí zorganizovat a zaplatit sám.

296

Server / Re:Jak zálohovat MySQL databázi?

« kdy: 28. 12. 2013, 21:04:56 »

Muzete mi nekdo vysvetlit, proc nepostaci zalohovat repliku (slave)? To tu někdo pořád vymýšlí kolo?

297

Vývoj / Re:Binární zápis do souboru

« kdy: 11. 12. 2013, 01:22:15 »

BOM je zpravidla před <?php
takže se přepíše do výstupu.

Některé verze PHP dokonce odmítají odeslat hlavičky, když je ten soubor s BOMem. Když se ale výstup bufferuje, tak se chyba hned neprojeví a hlavičky se přesto podaří nastavit navzdory tomu, že na výstup už byl odeslán znak.

298

Server / Re:Boj proti spamu principem z bitconů

« kdy: 11. 12. 2013, 01:18:27 »

Asi se budu opakovat... ale - opět jste nezklamal. 

Jsem rád, že se bavíte. Většina takových jako vy to totiž řeší tím, že to hodí na někoho jiného, nakoupí víc strojů a vyplácají tisíce člověkohodin, než aby udělali pořádnou analýzu logů a pokusili se zjistit, kde je chyba. Proto naštěstí to byla chyba. Mnohem horší by bylo, kdyby se ukázalo, že to ty stroje fakt nezvládají.

Ale ani vy mě nikdy nezklamete. Konečně, jste tu ikona, kterou nikdo nebere vážně 

299

Server / Re:Boj proti spamu principem z bitconů

« kdy: 11. 12. 2013, 01:05:41 »

Musím říci, že se nám kdysi stalo že nám spadlo víc serverů najednou, ale jako kladné reference jsem to nikde neuváděl, to mě nenapadlo. 

Já osobně bych nikdy nepřijal programátora, který by tvrdil, že nikdy neudělal chybu. Protože vím, že lže. To radši přijmu člověka, který jich za život udělal stovky a staly se mu větší průsery, pokud je dokázal rychle a operativně vyřešit. Chyby děláme každý a kolikrát to ani nemusí být chyba se kterou se dalo dopředu počítat (zrovna v tomto případě to bylo nevhodně navržené SQL query, které při trošku větší zátěži vytížilo databázi deadlockama... to fakt nikdo nemohl dopředu vědět)

300

Server / Re:Boj proti spamu principem z bitconů

« kdy: 10. 12. 2013, 21:57:29 »

Čéče Ondřeji, ty jsi ocitoval otázku, ale zapomněl odpovědět. Jaké máš reálné zkušenosti? Na mě to působí, že s e-mailem naprosto nulové.

No bude stačit, když řeknu, že v ponděli mi jeden newsletter od kasa.cz položil čtyři stroje ve dvou lokalitách? Naštestí to byla moje chyba a rychle jsme to s adminy opravili.