Ochrana binárek matematickou obfuskací

[osforever]

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.

[Reklama]

[Kolemjdoucí]

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.

[andy]

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.

[osforever]

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

[VK]

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, jeho mikrokód a BIOS.

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

[Reklama]

[JS]

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.

[Johny]

Mathematical obfuscation je fakt nabubřelý jméno pro packer.

[Ondra Satai Nekola]

Cetl jsi ten paper, ze ktereho se vychazi?

[dasd]

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.

[JS]

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

[Mirek Prýmek]

Vůbec tomu nerozumím, ale podle mě se to umí a říká se tomu Fully homomorphic encryption. Tady 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

Kód [Vybrat] Rozbalit


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á?

[Mirek Prýmek]

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

[asdfasdf]

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

[Mirek Prýmek]

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