Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: win 17. 08. 2014, 02:52:08
-
Tak kolik si kdo vsadi na jake datum konce opensource?
http://spectrum.ieee.org/tech-talk/computing/software/cybersecurity-center-mathematical-obfuscation
-
Nechápu, jak se odkazovaný článek týká opensource.
-
Binárky nejdou chránit vůbec nijak, ať se stavějí klidně na hlavu stejně nakonec procesoru musejí předhodit dekryptovaný kód a dál je to jasné.
-
Nechápu, jak se odkazovaný článek týká opensource.
to ti vysvetli vyzkumnik z microsoftu, v clanku odkazanem uvnitr clanku pod “Scrambled Code Keeps Software Safe” a k desifrovani binarky ne tak uplne pokud to bude v ramci neceho jako DMCA nebo ATCA povinne soucasti HW a bude se to odehravat mimo dosah OS.
-
V HW by to samozřejmě fungovalo, ale jenom do té doby než se k tomu provalí klíče. Pokud k tomu žádné klíče nebudou a bude to jenom algoritmus zabudovaný do HW, tak je k ničemu.
-
Binárky nejdou chránit vůbec nijak, ať se stavějí klidně na hlavu stejně nakonec procesoru musejí předhodit dekryptovaný kód a dál je to jasné.
Cílem není udělat kód, který nepůjde lousknout. Ale jde o to, jeho disassemblování natolik znepříjemnit, že to odradí všechny kromě těch nejvíc odhodlaných, a i těm to může prodloužit dobu disassemblování natolik, že to pro ně přestane být rentabilní. Například, pokud by kód vypadal tak, že je vždycky jedna instrukce a pak skok někam do háje, tak to je ručně jen obtížně dekódovatelné, protože nikdy nebude vidět tolik souvisejících instrukcí najednou, aby se dal pochopit smysl jednotlivých rutin. Tohle kódování by se samozřejmě dalo jednoduše strojově zase odstranit (prográmkem, který simuluje provádění kódu, loguje normální instrukce a ignoruje skoky), ale je zcela myslitelné, že složitější postupy budou na dekódování obtížnější, možná dokonce i jednosměrné.
-
V pořádku, ať si kdo chce binárky chrání, ale stále mi uniká to ohrožení opensource. Leda by se našel někdo, kdo věří výkřikům Microsoftu, že ostatní vykrádají jejich kód.
-
To mi připomíná jistý "pseudofuzzy" algoritmus, který vypadal v kritické části nějak takto: naplň pole náhodně zamíchanými cílovými adresami, náhodně vyber index, přečti adresu a skoč tam. Index se stanovoval za pomoci generátoru a uživatelského vstupu (PINu). Zhruba v 98 % to perbektně fungovalo, v jednom případě z padesáti si uživatel myslel, že udělal chybu v PINu a zkusil to znova.
Aneb není nad šikovné Gaussovo rozdělení.
-
Je to jen další důvod, proč používat opensource.
Pokud binárky nepůjdou zkontrolovat ani reverzním inženýrstvím, tak to už je naprostá ztráta kontroly. A softwareovým firmám to přinese účinnější způsob, jak vydírat zákazníky pomocí vendor lock-in. Opensource software vznikl proto, aby takovým věcem zabránil, a toto ho ještě posílí.
Nicméně, jsem trochu skeptický, co se týče fungování té věci - pokud jde něco za pomoci nějakého algoritmu udělat složitější, většinou je i způsob, jak to za pomoci algoritmu udělat jednodušší...
-
Binárky nejdou chránit vůbec nijak, ať se stavějí klidně na hlavu stejně nakonec procesoru musejí předhodit dekryptovaný kód a dál je to jasné.
Vůbec tomu nerozumím, ale podle mě se to umí a říká se tomu Fully homomorphic encryption. Tady (https://eprint.iacr.org/2012/266.pdf) se tváří, že z toho umí vyrobit turingáč.
-
Obfuscatoru a nastroju, ktere znemoznuji (cti velmi zneprijemnuji) disassembling existuje cela rada uz ted, nedelal bych z toho halo (a uz vubec ne v souvislosti s open source).
-
Pokud binárky nepůjdou zkontrolovat ani reverzním inženýrstvím, tak to už je naprostá ztráta kontroly. A softwareovým firmám to přinese účinnější způsob, jak vydírat zákazníky pomocí vendor lock-in. Opensource software vznikl proto, aby takovým věcem zabránil, a toto ho ještě posílí.
Já bych řekl, že už dneska máme každý v počítači věci, u kterých je kontrola prakticky nemožná. Například procesor (http://sharps.org/wp-content/uploads/BECKER-CHES.pdf), jeho mikrokód (http://www.inertiawar.com/microcode/) a BIOS (http://www.coreboot.org/Binary_situation).
Nicméně, jsem trochu skeptický, co se týče fungování té věci - pokud jde něco za pomoci nějakého algoritmu udělat složitější, většinou je i způsob, jak to za pomoci algoritmu udělat jednodušší...
Někdy ale nikdo ten zjednodušující algoritmus ani po 20 letech nevymyslel. Mně by se například hodil algoritmus na zjednodušení dešifrování AES bez znalosti klíče.
Koukni se na ten paper (http://eprint.iacr.org/2013/451.pdf). Není to obfuskace typu zpřeházení instrukcí, jdou na to pomocí silné kryptografie.
-
Tohle kódování by se samozřejmě dalo jednoduše strojově zase odstranit (prográmkem, který simuluje provádění kódu, loguje normální instrukce a ignoruje skoky), ale je zcela myslitelné, že složitější postupy budou na dekódování obtížnější, možná dokonce i jednosměrné.
Přesně tak, šel by snadno sestavit emulátor.
Algoritmus musí být obousměrný z principu věci.
Vůbec tomu nerozumím, ale podle mě se to umí a říká se tomu Fully homomorphic encryption.
Není to obfuskace typu zpřeházení instrukcí, jdou na to pomocí silné kryptografie.
Patrně je to nepochopení věci. Tyto postupy existují zatím jenom teoreticky a to pro hypotetický účel že chci poslat druhé straně data tak aby se vlastní data nedozvěděla, ale zároveň aby na nich mohla provést nějaké operace, typicky full-text index nad PDF v cloudu. Dál je postup jak to provést i na triviálně jednoduchý program. V případě spouštění programu v PC, např. Office, se jedná o naprosto jinou záležitost.
-
oprava, tak full-text index v clodu tím asi udělat nejde.
-
Přesně tak, šel by snadno sestavit emulátor.
Algoritmus musí být obousměrný z principu věci.
Nemusí. Například taková tradiční obfuskace kódů šířených v podobě zdrojáku, která spočívá v nahrazení všech jmen proměnných, funkcí a tříd anonymními názvy. Je to jednosměrné a přesto takový obfuskovaný program jde spustit. Na úrovni strojového kódu lze vytvořit něco podobného. (Jednosměrnost neznamená, že druhý směr je nemožný; stačí, že je výpočetně nezvladatelný.)
Je to jen další důvod, proč používat opensource.
Pokud binárky nepůjdou zkontrolovat ani reverzním inženýrstvím,
Backdoory lze zamontovat i do open source software, dokonce to ani není moc složité.
A softwareovým firmám to přinese účinnější způsob, jak vydírat zákazníky pomocí vendor lock-in.
Vendor lock-in lze bez problémů udělat i s OSS, respektive s otevřenou specifikací formátů. Stačí, když ta specifikace bude dostatečně rozsáhlá, aby bylo příliš složité a pracné ji implementovat. Už se tomuto stavu dost blížíme s HTML5 a CSS3, "úspěchu" už bylo dosaženo s xmldsig, xmlenc.
-
Open-source kašle na podobné věci. Proč schovávat kód? Většinou jsou stejně náklady na schování daleko větší než užitek. Pokud někdo kódy veme a nedokáže je dál upravovat, tak je mu to stejně k ničemu.
-
Nemusí. Například taková tradiční obfuskace kódů šířených v podobě zdrojáku, která spočívá v nahrazení všech jmen proměnných, funkcí a tříd anonymními názvy. Je to jednosměrné a přesto takový obfuskovaný program jde spustit. Na úrovni strojového kódu lze vytvořit něco podobného. (Jednosměrnost neznamená, že druhý směr je nemožný; stačí, že je výpočetně nezvladatelný.)
Tradiční metody obfuskace jsou všechny obousměrné, na procesor se dostane původní algoritmus. Jména proměnných a funkcí nejsou součástí algoritmu.
Jednosměrná obfuskace by znamenala, že procesor vykonává jiný kód než původní, který ovšem dává stejné výsledky.
-
No zase na druhu stranu keby bola niecim nedesifrovatelnym chranena iba aktivacia os, tak by to vobec nevadilo. Predsalen keygen je iba hlupa kradez a nie je dovod, aby existoval.
-
No zase na druhu stranu keby bola niecim nedesifrovatelnym chranena iba aktivacia os, tak by to vobec nevadilo. Predsalen keygen je iba hlupa kradez a nie je dovod, aby existoval.
Jakože aktivace třeba Debianu? A důvod? A pokud někdo kopíruje komerční SW, tak to také ničemu nevadí. Není to krádež.
-
Já bych řekl, že už dneska máme každý v počítači věci, u kterých je kontrola prakticky nemožná. Například procesor (http://sharps.org/wp-content/uploads/BECKER-CHES.pdf), jeho mikrokód (http://www.inertiawar.com/microcode/) a BIOS (http://www.coreboot.org/Binary_situation).
Je jasné, že u spousty věcí v počítači je kontrola téměř nemožná. To ale neznamená, že to budu ještě zhoršovat, a cpát si tam nějaký zašifrovaný software, když mám k dispozici alternativu v podobě open source. Svět samozřejmě není dokonalý, ale podle mne důležitější než současný stav je trend, kam se věci ubírají. A nějaké zašifrované binárky ho nezlepší...
Backdoory lze zamontovat i do open source software, dokonce to ani není moc složité.
Vendor lock-in lze bez problémů udělat i s OSS, respektive s otevřenou specifikací formátů. Stačí, když ta specifikace bude dostatečně rozsáhlá, aby bylo příliš složité a pracné ji implementovat. Už se tomuto stavu dost blížíme s HTML5 a CSS3, "úspěchu" už bylo dosaženo s xmldsig, xmlenc.
Backdoory lze zamontovat i do open source software, i viry a kdovíco ještě. Ale mám větší šanci, že si kód přečte někdo nezávislý, a způsobí poplach. Takový software by pak nikdo nepoužíval, a to většinou není cílem lidí, kteří jej tvoří.
Zajistit si vendor lock-in s OSS a otevřenými formáty je o dost těžší. Jak jsem četl, Microsoft se o to pokusil obfuskací specifikace OOXML (specifikace několikanásobně delší (10x?) než pro ODF), ale nyní i MS Office zavedl podporu formátu ODF, takže se mi zdá, že se v tom svém formátu nevyzná ani Microsoft, a nakonec zvítězí ODF :-)
-
To co popisuje ten clanek ma jeden zasadni hacek - ta obfuskace (skutecne kryptograficky silna) ten kod silenym zpusobem zkomplikuje. Dokazu si predstavit, ze by se to na nejaky super proprietarni algoritmus dalo pouzit; jenze cilem takovych algoritmu je obvykle rychlost, ktera se tou obfuskaci zcela ztrati. Takze je to opravdu spis teoreticke. :-)
Ackoliv jedno pouziti bych videl - navrhoval jsem v tom vytvorit pocitacovou hru - adventuru, ktera by se nedala vyhrat jinak nez hranim - nikdo by ji nemohl rozkodovat a zjistit, jak se ma hrat, a nemohl by ani zjistit, jestli byla uz dohrana cela. Takze na takove "umelecke" projekty by to mozna aplikovat slo. Ale open source se niceho bat nemusi.
-
Mathematical obfuscation je fakt nabubřelý jméno pro packer.
-
Cetl jsi ten paper, ze ktereho se vychazi?
-
Toto je skoro normalna obfuskacia, akurat je spustenie obfuskovaneho kodu poriadne narocne a toto sa neda dost dobre obist pri debugovani. Prelomitelne to zrejme je.
Cele to stavia na podla mna nikdy nefunkcnom principe "strelime sa do nohy a utocnika to bude boliet viac, lebo je zly".
PS: Podla komentarov sa mi nezda, ze ste citali to iste.
-
Toto je skoro normalna obfuskacia, akurat je spustenie obfuskovaneho kodu poriadne narocne a toto sa neda dost dobre obist pri debugovani. Prelomitelne to zrejme je.
Cele to stavia na podla mna nikdy nefunkcnom principe "strelime sa do nohy a utocnika to bude boliet viac, lebo je zly".
PS: Podla komentarov sa mi nezda, ze ste citali to iste.
Je otazka, co povazujes za "prolomitelne". Jak to pochopil ja, tak to skutecne sifruje funkcni program. To znamena, ze utocnik (pokud nema astronomicky hodne casu) nemuze ani z casti rozkodovat, jak program vnitrne funguje. To ovsem neznamena, ze nemuze pouzit urcity vstup toho algoritmu, pripadne zkouset simulovat ruzne vstupy a na zaklade toho zjistit, co to dela (pricemz nebude vedet s jistotou, co to muze delat, a zda to na jiny vstup nedava neco zcela jineho).
Takze napriklad na DRM se tohle neda pouzit, protoze tam uzivateli davame jak algoritmus, tak vstup. Tohle muze mit skutecne pouziti jen pokud by nekdo chtel schovat jen samotny algoritmus (tedy z definice vec, ktera bere nekonecne nebo aspon velke mnozstvi vstupu). Uzitecnost takove cinnosti na ochranu autorstvi je dost diskutabilni, protoze je patrne snazsi vymyslet algoritmus pro stejnou ulohu znova, nez se snazit lousknout tu sifru. Mozna zapletka filmu by se na tom dala postavit ("genialni vedec ukryl unikatni algoritmus do zasifrovaneho programu"), ale v praxi vyvoj algoritmu probiha natolik inkrementalne, ze neni opravdu moc duvod neco sifrovat.
P.S. Priroda neco takoveho pouziva, akorat nevime, jestli je to kryptograficky silne (nejspis neni). Muj kolega rad vypravi historku, jak vedci merili neuronove impulsy ovladajici svaly v ruce. Pro 100 stejnych jednoduchych pohybu dostali 100 naprosto odlisnych zaznamu o neuronove aktivite. Poslali tam znovu totez - nic se nestalo. A nejak podobne bude vypadat ten zasifrovany program v debuggeru - jeho chovani bude mozne zvenku pozorovat, ale pri trivialni variaci vstupu nebo vystupu se vnitrni stav zmeni velice komplikovanym zpusobem, vzdorujicim lidskemu chapani. Na toto tema (co je a co neni prolomitelne a v jakem smyslu) existuje filozoficka povidka: http://ase.tufts.edu/cogstud/dennett/papers/twoblackboxes.pdf (http://ase.tufts.edu/cogstud/dennett/papers/twoblackboxes.pdf)
-
Vůbec tomu nerozumím, ale podle mě se to umí a říká se tomu Fully homomorphic encryption. Tady (https://eprint.iacr.org/2012/266.pdf) se tváří, že z toho umí vyrobit turingáč.
Pokud jsem správně pochopil problém, jde o to, že nedůvěryhodná strana může provést přesně dané výpočty nad tajnými daty aniž by se dostala k datům v otevřené formě. Takže bych třeba mohl podnikové účetnictví počítat někde fklaudu aniž by provozovatel mohl zjistit, kolik vydělávám.
Takže
D(f'(E(x,K1)),K2)=y kde y=f(x)
E...zašifrování
D...dešifrování
K1,K2...klíče
f...funkce, kterou chci vypočítat
f'...funkce, která provádí výpočet nad zašifrovanými daty
problém je, jak pro danou f zkonstruovat f'
Není mi jasné, jak by se tohle dalo použít pro obfuskaci software, protože v takové situaci má uživatel software k dispozici data v otevřeném formátu. Muselo by to fungovat tak, že svoje data pošlu vydavateli sw, ten je zašifruje (on jediný má K1), já zašifrovanou formu vrazím do algoritmu f', provedu výpočet na svém železe a výsledek rozšifruju pomocí K2, který mi vydavatel sw dá.
Nenapadá mě způsob, jak to udělat bez toho, aby jenom vydavatel měl K1 a při každém výpočtu jsem s ním musel interagovat.
Co mi uniká?
-
...abych to řekl úplně polopaticky: pokud to zadání je tak, jak jsem ho popsal, tak pro jeho řešení imho automaticky neplatí, že při znalosti x,y,K1,K2,D,E a f' neumím zjistit f. To je imho jiný problém, ne?
-
...abych to řekl úplně polopaticky: pokud to zadání je tak, jak jsem ho popsal, tak pro jeho řešení imho automaticky neplatí, že při znalosti x,y,K1,K2,D,E a f' neumím zjistit f. To je imho jiný problém, ne?
Neviem, ci si rozumieme (a ci rozumiem ostatnemu), ale skusim naznak, preco by to malo platit automaticky:
1. Pri behu f' nad zasifrovanymi datami nemozeme zistit nic o datach (hovori o bezpecnosti behu "fklaudu")
2. Pri behu funkcie g' nevieme efektivne citat efektivny algoritmus napisany programatorom popisany funkciou g (hovori o obfuskacii)
1=>2
(tu f=g, f'=g' - rozne znacenie je len aby bolo jasne, na co sa odkazuje)
Sporom: nemozeme zistit nic o datach a vieme efektivne citat g. Ale to uz nam prezradi nieco o datach, cim dostaneme spor.
A co nam to prezradi? Ked pozname popis algoritmu a mozeme si ho napasovat na vstup a vystup, tak uhadneme, ktore podmienene skoky / matematicke operacie dopadli s akym vysledkom.
Keby bol algoritmus velmi velka jednotka (bolo by treba skusit nieco ako 2^{pocet podmienenych skokov} operacii, pri mat. operaciach je to este narocnejsie), tak mozeme pouzit lubovolnu cast algoritmu, cim sa utok zjednodusi.
-
2. Pri behu funkcie g' nevieme efektivne citat efektivny algoritmus napisany programatorom popisany funkciou g (hovori o obfuskacii)
Neformální důkazy mají tu nevýhodu, že se nám může zdát, že něco dokazují a ono ne :)
Můžu ti dát protipříklad, proč tohle neplatí:
Předpokládejme, že g' má takovou vlastnost, že každý krok výpočtu generuje data, která jsou rozšifrovatelná klíčem K2. Prostě stejnou vlastnost jako má výsledek mají i všechny mezi výsledky. To klidně můžu předpokládat, protože takový algoritmus splňuje zadání problému. Potom znám nejenom vstupní data v otevřeném tvaru, ale i data, která vzniknou v každém výpočetním kroku, čili efektivně znám algoritmus g za předpokladu, že kroky jsou natolik elementární, že ze znalosti vstupu a výstupu kroku umím odvodit, co krok dělá.
Takže to, co píšeš, obecně neplatí.