Open-source a backdoory

Kdykoliv se někde objeví článek o komerčním šifrovacím nástroji, docela jistě se u něj objeví aspoň jeden komentář, že u programu s uzavřeným kódem nikdo neví, jaká skrytá dvířka do něj programátor umístil. A hned se objeví reference na TrueCrypt, který je zdarma, umí to samé, a „díky tomu, že je to open-source, si každý může ověřit, že je čistý“. Problém je v tom, že toto tvrzení je nepravdivé. Dokonce hned na dvou úrovních: Není pravda, že v open source programu nelze úspěšně skrýt backdoor, a také není pravda, že u open-source programu má uživatel větší jistotu. Speciálně u TrueCryptu to platí dvojnásob.

„V open-source nemůže být backdoor“

Logika tohoto tvrzení je jasná: Když je k dispozici zdroják, je relativně snadné si ověřit, co se v tom zdrojovém kódu nachází (relativně vůči zkoumání zkompilovaného strojového kódu). Což je do jisté míry pravda, aspoň v obecném případě (u šifrovacích programů je to složitější, tam do hry vstupují ještě další ohledy, ke kterým se dostanu). Ale předpokládá to, že jsem ten zdrojový kód důkladně prozkoumal (já nebo někdo, komu důvěřuji), že jsem si z něj zkompiloval binární program a že oba tyto kroky opakuji pro každou další aktualizaci toho programu. Pokud kterýkoliv tento krok vynechám, nevím o bezpečnosti toho programu nic:

  1. Vynechám zkoumání zdrojáku: O tom, co v kódu je nebo není, nic nevím. Spoléhám se na to, že ten zdroják někdo dostatečně dobrý prozkoumal (což není jisté – přesně to samé si mohou říct i všichni ostatní uživatelé a kód nakonec neprozkoumá nikdo). A jistě uznáte, že argument „kód lze prozkoumat, tudíž kód je bezpečný“ poněkud postrádá na přesvědčivosti.

  2. Vynechám vlastní kompilaci: O tom, co je v běžícím programu, nic nevím. Spoléhám se na to, že ten program vznikl kompilací toho zdrojáku, který jsem prozkoumal, ale nemám pro to nejmenší důkaz. Pokud očekávám, že autor do svého programu zabudoval backdoor, proč bych mu měl důvěřovat, že binární verze programu opravdu odpovídá zdrojovému kódu?

  3. Vynechám ověřování dalších verzí: Opět, o tom, co běží v nové verzi, nevím vůbec nic. Spoléhám se na to, že autor backdoor dodatečně nepřidal.

    Mimochodem, při ověřování té nové verze nestačí jenom projet změny mezi soubory. Jak ví každý, kdo programoval nějakou rozsáhlejší aplikaci, zdánlivě neškodná změna na jednom místě se může docela dobře projevit jako kritická chyba na místě jiném. A nikde není řečeno, že ta zavlečená kritická chyba musí být náhodná a neúmyslná…

V případě šifrovacích nástrojů je to ještě složitější v tom, že se v nich spojují dvě vysoce specializované profese a ten, kdo kód zkoumá, musí být velmi dobrý v obou současně (naproti tomu na skrytí backdooru stačí dva lidé, kteří jsou každý dobrý jen v tom svém oboru). Potíž je v tom, že „backdoor“ vůbec nemusí být jenom něco tak profláknutého jako ukládání zapsaných hesel do souboru nebo jejich odesílání někam na internet, ale může jít o dvířka mnohem a mnohem skrytější – úplně klidně může jít například o nenápadné narušení bezpečnosti algoritmu, na které ani skvělý programátor vůbec nemusí přijít, prostě proto, že to narušení je úplně mimo jeho specializaci. Nádherně to předvedl The Underhanded C Contest v roce 2007, jehož cílem bylo implementovat skrytá dvířka, která nebudou vidět. Jednou z hodnocených vlastností byla přitom délka programu (čím kratší, tím lepší – skrýt škodlivý kód do mnoha MB sena dokáže každý, ale udělat totéž na pár řádcích?). Jestli věříte v nemožnost umístit backdoor do open source, zkuste si odhalit slabiny některých nabízených prográmků – třeba v téhle části implementace RC4:

#define TOBYTE(x) (x) & 255
#define SWAP(x,y) do { x^=y; y^=x; x^=y; } while (0)

static unsigned char A[256];
static int i=0, j=0;

void init(char *passphrase) {
    int passlen = strlen(passphrase);
    for (i=0; i<256; i++)
        A[i] = i;
    for (i=0; i<256; i++) {
        j = TOBYTE(j + A[TOBYTE(i)] + passphrase[j % passlen]);
        SWAP(A[TOBYTE(i)], A[j]);
    }
    i = 0; j = 0;
}

unsigned char encrypt_one_byte(unsigned char c) {
    int k;
    i = TOBYTE(i+1);
    j = TOBYTE(j + A[i]);
    SWAP(A[i], A[j]);
    k = TOBYTE(A[i] + A[j]);
    return c ^ A[k];
}

Mimochodem, tady víte, že je nějaká slabina. Dokázali byste obdobnou najít v programu mnohem větším, u kterého nevíte, jestli tam je nebo není?

Připouštím, možná to bylo příliš jednoduché. Zkusíme něco složitějšího a praktičtějšího (originál, nezkažený mojí interpretací: The Strange Story of Dual_EC_DRBG): Nesmírně důležitou součástí každého šifrovacího algoritmu je generátor náhodných čísel – mimo jiné proto, že náhodná čísla slouží k vygenerování klíče. V roce 2007 vydal americký NIST dokument, ve kterém popisuje několik generátorů náhodných čísel postavených na celkem dobře prozkoumaných a prověřených kryptografických základech. Jeden z nich vykazuje několik zajímavých vlastností, mimo jiné silnou podporu ze strany NSA. Ale to nejzajímavější je, že v něm existuje slabina, kterou lze označit jako backdoor – kryptologové Dan Shumow a Niels Ferguson (podílel se například na algoritmu Twofish a na Microsoftím Bitlockeru) ukázali, že konstanty v algoritmu použité mají vztah k jiným konstantám, s pomocí kterých lze předvídat generovanou posloupnost už se znalostí 32 předchozích členů posloupnosti. Potíž je v tom, že nikdo neví, jaká ta odemykací konstanta je a jestli ji NSA má. Zrovna tak dobře může jít prostě o chybu v návrhu jako o úmyslný backdoor.

V tomto případě došlo k odhalení docela rychle – mimo jiné i proto, že chyba/backdoor byla přímo součástí algoritmu. Je otázka, jestli by byla nalezena i v případě, že by příslušný generátor nebyl k dispozici jako algoritmus ale jen jako zdrojový kód, speciálně navržený tak, aby slabinu zakryl. V takovém případě by na ni mohl přijít jen špičkový programátor a kryptolog v jedné osobě (nepravděpodobné) nebo jeden špičkový programátor a jeden špičkový kryptolog (ještě nepravděpodobnější, ve vzájemné komunikaci by se důmyslně skrytý backdoor snadno ztratil – programátor nedostatečně odhadne význam zdánlivé drobnosti, neřekne o ní kryptologovi a ten tudíž neodhalí zásadní slabinu).

„V open-source má člověk větší jistotu“

Přesnější by bylo říct, že do open-source se může důkladně podívat víc lidí. Jak už ale bylo naznačeno v předchozí kapitole, to nemusí nutně vést k odhalení chyby. Ale stejně, přinejhorším bude open-source na stejné úrovni jako closed-source, ne?

Ne nezbytně. Uvažujme například TrueCrypt (open-source, freeware) a některou z komerčních šifrovacích aplikací. Co by se stalo, kdyby do některé z nich jeden z vývojářů zabudoval backdoor a někdo na to přišel? V případě komerční aplikace má dotyčná firma problém – okamžitě přijde o důvěru zákazníků, takže ztratí odbyt (a příjmy). A i kdyby tohle přežila, což vůbec není jisté, musí čelit ještě dalším hrozbám, například soudním sporům (nepochybuji, že by ji někdo zažaloval o náhradu škody nebo za klamavou reklamu nebo kdo ví za co). Její zaměstnanci by pravděpodobně přišli o živobytí – programátoři snad jen na čas, kryptlogové asi navždy. Budou to chtít riskovat jenom proto, že si jejich management přeje sbírat tajná data?

TrueCrypt by na tom v této hypotetické situaci byl podstatně lépe. Sice také ztratí důvěru, ale jeho autoři mají vlastní na TrueCryptu nezávislé zdroje obživy, takže se jich to přímo nedotkne. A hlavně – nikdo neví, kdo je autorem TrueCryptu. Kdyby na to přišlo a TrueCrypt skutečně byl zdiskreditován, jeho autora se to nedotkne. Klidně může udělat pár změn a pod novým názvem vypustit „fork TrueCryptu, ze kterého byly odstraněny všechny backdoory“.

Můžete namítnout, že to je problém TrueCryptu a netýká se ostatních programů. Pokud jde o bezpečnost autorů, souhlasím. Ale skutečnost, že komerční firma má ve svém produktu investované konkrétní peníze, o které by odhalením backdooru přišla, platí univerzálně.

 

Rád bych ale v této souvislosti řekl, že nemám důvod TrueCryptu nevěřit. Nevím o ničem, co by i třeba jen naznačovalo, že TrueCrypt není tím, čím se snaží být – totiž špičkovým a bezpečným šifrovacím nástrojem. Naopak existují důvody pro doměnku, že TrueCrypt bezpečný je. Mimo jiné známý český kryptolog Vlastimil Klíma svého času TrueCrypt prověřil a potvrdil, že TrueCrypt neobsahuje zadní vrátka. Potíž je ovšem v bodech 2 a 3 části o backdoorech v open-source a také v tom, že jakkoliv je V. Klíma uznávaným kryptologem, nejsem si úplně jistý jeho schopnostmi programátora – a zejména si nejsem jistý tím, jestli se zaměřil i na záludně skryté backdoory. V článku o tom není ani slovo, což může znamenat, že to udělal a nic nenašel, ale také že to neudělal.

Celý předchozí text byl zaměřen na vyvrácení pochybného argumentu o bezpečnosti open source. TrueCrypt byl zmíněn jako konkrétní příklad, v čem nemusí být open-source tou odpovědí, za kterou ho všichni považují. Zamyšlení nad backdoory v TrueCryptu jsou z mé strany čirou, ničím nepodloženou spekulací o tom, že kdyby vývojáři TrueCryptu chtěli do svého programu zabudovat backdoor, tak by se jim to mohlo podařit, a i kdyby na to někdo přišel, nemělo by to pro ně žádné nebezpečné důsledky.

Podobné příspěvky:

5 Responses to “Open-source a backdoory”

  1. Karel Karel napsal:

    Pěkně napsané, děkuji. Přidal bych ještě jedno hledisko – i když někdo prohlásí, že zkontroloval příslušné zdrojáky a jsou v pořádku, tak:

    a) jak vím, že nelže? Zase by to musel být někdo, kdo na tom má zavislou svoji profesionální pověst, tedy ne kdokoli, ale světově významná osobnost v oboru

    b) jak vím, že stahuji identickou verzi zdrojáku, kterou někdo kontroloval? Dneska se dá zfalšovat i hash…

    Tyto dva body IMHO odkazují všechno s výjimkou vlastní kontroly zdrojáku a vlastní kompilace do říše pohádek, tedy „jedna paní povídala, že je to bezpečné“.

  2. pepak pepak napsal:

    a) Což o to. Pokud nějaká význačná autorita prohlásí, že kód prověřila, byl bych ochoten jí to věřit – nevěřím, že by někdo riskoval svoje jméno v situaci, kdy stejně dobře mohl neříct nic a být v klidu. Spíš mě zneklidňuje ten problém, že v této oblasti se stýkají vysoce specializované obory a těžko se najde někdo, kdo by byl špičkovým odborníkem v obou z nich – prohlášení kryptologa může být bezcenné, pokud bylo slabé místo třeba i neúmyslně zakomponováno do programu a ne do algoritmu nebo principů.

    b) To nevíš.

  3. Krásně napsané, moc se mi to líbí. A musím souhlasit, bohužel v zásadě se vším. Já jsem skutečně kdysi zkoumal, jak je z kryptografického hlediska udělán Truecrypt. Tam jsem shledal profesionalitu, čistotu provedení a žádná zadní vrátka. Mám i nějaké zkušenosti s programováním, ale bohužel nemůžu ručit za to, že ty funkce nemají programátorská zadní vrátka. Tady naprosto souhlasím s autorem. I kdybych moc rád i jako uživatel Truecryptu, aby tam programátorská zadní vrátka nebyla, nevím to a pouze věřím, že nejsou (víra není bezpečnostní politika, nic jiného mi ale nezbývá). Pokud se najde někdo, kdo řekne, že v celém programovém kódu Truecryptu nejsou žádná zadní vrátka, tak mu na druhou stranu věřit asi nebudu, nezlobte se, to prostě stoprocentně nejde. Pokud snad něco co jsem řekl nebo napsal vyznělo tak, že jsem právě to udělal, tak to by bylo hluboké nedorozumnění. Je mi líto, ale jistota v tomhle složitém světě je pouze negativní.
    Autorovi přeju hodně takových článků,
    Vlastimil Klíma

  4. mmad mmad napsal:

    Nedivil bych se, kdyby NSA tu konstantu někde měla (Dan Brown: Digitální pevnost; některé narážky jsou docela jasné).

  5. pepak pepak napsal:

    Dan Brown je asi tak spolehlivý zdroj o bezpečnosti, jako Michael Moore o politice. Což nevylučuje, že v tomto případě má zrovna shodou okolností pravdu – možné to je.

Leave a Reply

Themocracy iconWordPress Themes