Asrar-Al-Mujahideen – bezpečnost teroristického šifrovacího programu

Už v několika článcích jsem se tu zabýval bezpečností TrueCryptu a zdaleka ne vždy vyzněly mé závěry pozitivně. To je ovšem hodně relativní – moje hodnocení TrueCryptu možná nejsou extra pozitivní ve srovnání s tím, co se o TrueCryptu tvrdí, ale pokud by se měla postavit vedle hodnocení jiných produktů, hned by vypadala skvěle. Měl jsem například možnost podívat se na program Asrar-Al-Mujahideen, který údajně používají teroristé pro šifrovanou komunikaci mezi sebou, protože nevěří běžně dostupným řešením. Pokud je to pravda, tak jsou to idioti.

Zkoumal jsem Asrar-Al-Mujahideen ve verzi 2.0, konkrétně následující soubor:

• URL: http://ia700402.us.archive.org/2/items/Asrar-gimf/asrar.rar
• heslo k archívu: Asrar@_EkLaAs.TsG@[$^/!p@]z-2008
• MD5 archívu: 21ec5aa8743c5c68002a72e6fde4673f

Základní charakteristika

Asrar je bezpečnostní nástroj určený pro komunikaci mezi muslimskými teroristy. Těžiště jeho zájmu leží v asymetrické kryptografii – program se zabývá zejména posíláním šifrovaných zpráv a souborů přes internet, plus několika vedlejšími aspekty jako je bezpečné smazání souborů nebo porovnání souborů na shodu (resp. porovnání dvou hashů na shodu). Nejde tedy o alternativu k TrueCryptu v tom smyslu, že se nezabývá ochranou souborů uložených na pevných discích.

Ze zamýšlených uživatelů vyplývá několik skutečností, které značně zesložiťují podrobnější zkoumání, jako například to, že velká většina dostupné dokumentace je v arabštině. Musel jsem tedy vycházet ze sekundárních zdrojů, které obecně nelze považovat za důvěryhodné; to, co šlo použít z primárních zdrojů, také nelze brát úplně vážně, protože nerozumím kontextu a nemám tušení, jestli výskyt „AES 256“ v textu znamená „používáme AES 256“ nebo „nepoužíváme AES 256“ nebo co vlastně. Dokumentace dostupná v angličtině (např. článek al-Qaeda’s Embrace of Encryption Technology: 2007-2011) se technickými detaily vesměs nezabývá.

Teoretická bezpečnost

Pokud se mi podařilo dohledat, bezpečnostní primitiva jsou:

1. Asymetrická kryptografie využívá RSA s 2048bitovým klíčem.

2. Symetrická kryptografie využívá volitelně jeden z následujících algoritmů, vždy s 256bitovým klíčem: Rijndael, Serpent, Twofish, RC6, Mars (tzn. pět finalistů soutěže o AES).

3. Měla by být podporována steganografie označovaná jako „stealthy cipher“. Předpokládám, že jde o implementaci Stealthy Ciphertext, ale nepodařilo se mi to ověřit, mimo jiné proto, že se mi nepodařilo program k této činnosti přinutit.

Další detaily nejsou dokumentovány v mě srozumitelném jazyce.

Na čistě algoritmické úrovni tedy nelze Asraru nic vyčítat – všechny použité šifry platí v současné době za neprolomitelné. Jak ukážu dále, s konkrétní implementací už je to horší.

Bezpečnost z uživatelského pohledu

Na úrovni uživatele, který si chce program stáhnout a používat, vykazuje Asrar několik zajímavých aspektů. Některé jsou pozitivní, některé ne.

1. Podle všeho neexistuje věrohodný důkaz, že je program napsán „bratrem teroristou“ a ne ďábly z bezpečnostních agentur USA. Veškeré indicie o původu programu jsou nepřímé, založené na tom, že program doporučuje k použití teroristický časopis Inspire (psaný anglicky, aby si ho mohli přečíst i potenciální teroristé, kteří nikdy v Arábii nebyli; „oficiální“ URL neznám, ale obrázky jsou zde) nebo že světová média informují, že za ním stojí jakýsi Jemenský šejk. Ne že by mě to překvapovalo, kdyby někdo spolehlivě prokázal svoje autorství, tak už nejspíš sedí na Guantánamu, ale kdybych já byl terorista, který chce komunikovat se svými kolegy, tak by mě určitě zajímalo, „proč mám věřit, že program napsali přátelé a ne například NSA“. Připouštím, že například o autorech TrueCryptu také neví nikdo nic, ale TrueCrypt je aspoň open-source s řadou analýz od důvěryhodných kapacit. (Znovu zdůrazňuji, že to neznamená, že je TrueCrypt bezpečný; ale pořád je důvěryhodnější program, ke kterému takové analýzy existují, než program, ke kterému neexistují.)

2. Obdobně neexistuje žádný věrohodný důkaz, proč bych si měl myslet, že zrovna ta verze, kterou jsem stáhnul, je totožná s originální verzí. To, že můj zdroj uvedl MD5 „originálního archívu“, je sice hezké, ale jak mám vědět, že píše pravdu? Kdyby odkazoval na zfalšovaný archív a uvedl odpovídající MD5, bude se mi to jevit přesně stejně.

3. Velikým překvapením pro mě bylo, že se Asrar chová jako slušný přenositelný program: Nepotřebuje instalaci, stačí rozbalit. Zřejmě nezapisuje do registru. Nepodařilo se mi najít žádný náznak, že by se po spuštění snažil vnutit systému nějaké nastavení pro automatické spouštění. Podle všeho „nevolá domů“ – neprovádí sám o sobě žádnou komunikaci do sítě, nebo to přinejmenším dělá tak šikovně, že ho při tom můj firewall ani Wireshark nezachytí.

4. Pro zašifrování souboru (resp. zprávy) je třeba znát veřejný klíč protějšku. Asrar neřeší získání tohoto klíče ani ověření, že skutečně pochází od dotyčné osoby. Prostě se předpokládá, že uživatel získal veřejný klíč nějakým důvěryhodným kanálem, tzn. zřejmě při osobním setkání. Na dálku se zřejmě uvažuje jen řešení typu „O Inspire všichni vědí, že je to autentický teroristický časopis, takže když bude veřejný klíč zveřejněn tam, může si ho každý zájemce přeťukat do svého počítače a používat pro komunikaci s vydavatelem“; nějaká alternativa pro PGPčkovskou „síť důvěry“ zřejmě není předmětem zájmu programu.

5. Totéž platí o případné revokaci existujících podpisů: Asrar tuto otázku neřeší.

6. Pro dešifrování souboru (zprávy) od někoho jiného a/nebo pro podepsání souboru pro někoho jiného je třeba vygenerovat dvojici asymetrických klíčů. Když odhlédnu od toho, že tady Asrar není zrovna dvakrát stabilní, jsou tu přinejmenším dvě slabiny: ta malá se zabývá požadavky na jméno a heslo (5 znaků na jméno, 8 na heslo, není však vyžadována žádná složitost – bez problémů projdou i hesla typu „11111111“), ta velká se týká entropie – Asrar nepoužívá žádný externí zdroj entropie, vychází jenom ze stavu programu a/nebo operačního systému. To znamená, že veškerá náhodnost pochází zevnitř počítače a případný útočník ji může více či méně snadno napadnout. (To je mimochodem důvod, proč po vás TrueCrypt i další programy chtějí náhodně mačkat klávesy nebo pohybovat myší – aby nasbíraly entropii, která zevnitř počítače nepochází.)

7. Jeden a tentýž soubor se pokaždé zašifruje do jiného výstupu, ovšem s tím, že 2. až 7. bajt byly ve všech mých pokusech konstantní. Přesné detaily se mi nepodařilo dohledat, pokud by ale skutečně šlo o stabilní obsah, může být snadno využit pro detekování teroristické komunikace.

Pohled na kód programu

Asrar není open-source, nebo přinejmenším jeho zdrojový kód není dostupný. To však neznamená, že by program nešel prozkoumat, jen to je trochu pracnější. Rovnou přiznávám, že vzhledem k tomu, že mě už dřívějších zjištění nepřesvědčila o kvalitě programu, nebyl jsem ochoten do toho vrážet až tak moc sil; nicméně několik zajímavých skutečností jsem přesto našel.

1. Program je napsán v programovacím prostředí Delphi 5. Nic proti tomu, používám ho taky, protože produkují relativně velmi krátký cílový kód (ve srovnání s Delphi 2009 nebo FreePascalem). Zajímalo by mě, jaký důvod měl autor Asraru – jestli šlo jenom o to, jakou verzi měl k dispozici, nebo jestli svou roli sehrálo i stáří Delphi 5 (pocházejí z doby ještě před Dvojčaty a tudíž je menší pravděpodobnost, že je do nich zabudovaný backdoor pro NSA).

2. Pro šifrování je použita knihovna DCPCrypt ve verzi 2. Jde o jednu ze dvou nejčastěji používaných šifrovacích knihoven pro Delphi a lze tudíž doufat, že neobsahuje závažné implementační chyby.

3. Šifrování souborů je řešeno následujícím algoritmem:

   1. Úvodní testy na existenci souborů, vybrané klíče atd., včetně vykreslení okna s průběhem.
   2. Zkomprimování vstupního souboru algoritmem Deflate. To jednoznačně hodnotím kladně, entropie vstupního souboru se tak „zhušťuje“ a vztah mezi otevřeným a šifrovým textem je obtížněji napadnutelný.
   3. Inicializace Delphovského generátoru náhodných čísel pomocí System.Randomize. Samo o sobě to až tak nevadí, ale pokud by snad program měl v úmyslu používat náhodná čísla z Delphovského generátoru, je to docela problém.
   4. Z řady údajů se poskládá řetězec. Podrobné zkoumání, o které všechny údaje jde, by dalo příliš mnoho práce, ale skutečnost, že do něj Vstupuje systémový čas a náhodná číslo ze System.RandInt(256) (násobící generátor, kryptograficky naprosto nepoužitelný), je velmi varující.
   5. Tento řetězec se prožene SHA256 a výsledek tvoří symetrický klíč.
   6. Symetrický klíč se zašifruje pomocí RSA a odešle na výstup.
   7. Pak proběhne ještě několik operací, které jsem úplně nepochopil, ale které často používají systémový RandInt a nevypadají, že by nastavovaly něco zásadně důležitého, jako například šifrovací režim nebo jeho inicializační vektor. Všechna volání RandInt mají parametr (rozsah) 256, tzn. vrací „náhodné“ číslo od 0 do 255.
   8. Zavolá se metoda EncryptStream zvolené šifry, která zašifruje celý vstup se zadanými parametry. Přednastavené parametry, jejichž změnu jsem nikde neviděl, jsou CBC a inicializační vektor tvořený samými nulami, tzn. první blok šifrového textu se chová, jako kdyby byl šifrován v režimu ECB. O „vhodnosti“ tohoto režimu se nebudu rozepisovat, zájemci ať se podívají na obrázek tučňáka v článku Block cipher modes of operation na Wikipedii.
   9. Vyčistí se použité proměnné, zavřou soubory apod. a operace se ukončí.

   Pokud dokážu říci, nikde se nepoužívá žádný salt a dokonce ani náhodný inicializační vektor, veškerá rozdílnost výstupů pro stejné vstupy je daná tím, že je pokaždé generován jiný symetrický klíč. A to ještě stěžejní část pseudonáhodného generátoru tvoří standardní RNG Delphi, který rozhodně nelze označit za kryptograficky silný. Ve srovnání s TrueCryptem je to velmi slabé.

4. Pro hašování jsou použity algoritmy SHA256 a SHA1. SHA256 se používá při generování symetrických hesel a rád bych doufal, že i při generování digestů zpráv pro účely podepisování. K čemu se používá SHA1 nevím, nehledal jsem.

Další části programu jsem nezkoumal, tyhle informace mi docela stačí. Použití slabého náhodného generátoru je katastrofa sama o sobě, a to, že program téměř ve všech svých operacích používá výchozí nastavení komponent, vnucuje otázku, jestli jeho autor věděl, co dělá. Spíš bych řekl, že ne.

Zhodnocení

Asrar-Al-Mujahideen mě na jednu stranu příjemně překvapil tím, že zřejmě neobsahuje žádný malware, který jsem v něm najisto očekával, po kryptologické stránce už ale tak pozitivní není. Zejména náhodnému generátoru není věnována skoro žádná pozornost a lze se důvodně obávat, že použití standardního Delphovského RNG výrazně zeslabuje šifru jako takovou.

Samostatným, ale stejně vážným problémem pak je obecná nedůvěryhodnost programu a jeho autora. Příčiny, proč si autor nemůže dovolit vyjít na veřejnost, jsou zřejmé, důsledky ovšem také – potenciální uživatel nemá žádný podklad pro rozhodnutí, kdo vlastně program stvořil, mohla to být zrovna tak dobře Al Kajdá i NSA. Je tu nějaký dobrovolník, který si hodí mincí a výsledku svěří svůj život?

(Tohle je mimochodem standardní výsledek toho, když si laik zkusí naimplementovat vlastní kryptosystém, protože existujícím „nevěří“ – i když použije kvalitní a ověřené mechanismy, skoro vždy přehlédne nějakou „drobnost“, která do jeho systému zavleče zásadní slabiny. Vřele doporučuji, pokud se kryptologií nezabýváte hlouběji, použijte raději ověřená řešení, i za cenu rizika, že v nich třeba je backdoor.)

Podobné příspěvky:

• UpdVer
• TrueCrypt v6.3
• TrueCrypt prolomen? Ale kdepak!
• Formáty: *.PDB
• Ochrana přenášených dat

10 Responses to “Asrar-Al-Mujahideen – bezpečnost teroristického šifrovacího programu”

1. pepak napsal:

   5. 3. 2012 (06:55)

   Scar: To se nedá říct takhle obecně, záleží na přesném algoritmu generátoru. Ale můžeš si to představit tak, že kdyby se veškerá náhodná data získávala z operačního systému (např. ze souboru /dev/random na Linuxu), tak by útočník mohl zkusit nahradit příslušný modul OS, aby vytvářel méně náhodná čísla. Pokud by náhodný generátor vycházel z nějakého čítače založeného na čase nebo počtu provedených instrukcí, mohl by útočník změřit přesné intervaly s úmyslem omezit prostor možných generovaných čísel. (V případě Asraru by útočník mohl vyjít z toho, že všechna náhodná čísla jsou generována kryptograficky slabou funkcí Random(), která je inicializována na začátku programu ze systémového času; pokud bude vědět, kdy přesně byl program spuštěn, může celou „náhodnou sekvenci“ určit.)

   Z tohoto důvodu se prakticky každý šifrovací program ptá na to, aby uživatel jezdil chvíli náhodně myší nebo mačkal náhodně klávesy – protože to je něco, co do počítače vstupuje zvenku a nedá se to zopakovat, takže to zaručí určitou minimální míru náhodnosti, i kdyby útočník na pseudonáhodný generátor opravdu zaútočil.

2. Scar napsal:

   4. 3. 2012 (20:49)

   Mohl bys popsat jak ovlivnit tu entropii, respektive náhodnost generovaných čísel v počítači?Např mám-li například aplikaci, která si generuje náhodná čísla, mohu nějak zjistil kterou funkci systému využila, jakou hodnotu ta funkce aplikaci vrátila a případně jak je komplikované tam podvrhnout hodnotu?

3. Kojot napsal:

   6. 12. 2011 (10:01)

   Zajimave,,

4. pepak napsal:

   4. 12. 2011 (07:49)

   Honza77: Tenhle článek je primárně o dvou slabinách, z nichž ani jedna nesouvisí s použitým algoritmem nebo knihovnou:
   1) U šifrovacího programu je nezbytná důvěra k autorovi, aspoň v nějaké minimální míře. K anonymnímu autorovi bez minulosti důvěru mít nelze.
   2) Riziko backdooru je i u programu, který jsem si napsal sám. Autor Asraru zjevně neměl dost znalostí o šifrování, aby se dokázal vyhnout slabým místům jako je špatný náhodný generátor nebo nevhodný šifrovací režim.
   Oboje jsou věci, se kterými by ti nepomohlo ani sto algoritmů použitých v kaskádě. Zrovna tak by nepomohlo, kdyby místo DCPCrypt (což vůbec není špatná knihovna) vytáhl implementaci algoritmů třeba z TrueCryptu.

5. Honza77 napsal:

   3. 12. 2011 (14:39)

   Myslel jsem to tak, ze riziko nejakeho backdooru tu proste je u kazdeho programu, ktery jsem si nenapasal (a i tam, pokud vyuziji nejake cizi knihovny). Taktez program muze mit neumyslnou implementacni chybu.

   Pokud data zasifruji vice zpusoby (zasifrovani jiz zasifrovanych dat), tak snizim riziko, ze to nekdo bude moci desifrovat. Je jiste mensi pravdepodobnost, ze backdoor/chybu bude mit kazdy z n (n>1) pouzitych programu nez jeden zvoleny. Navic v pripade backdooru by ten, ktery by to chtel rozlustit, musel byt autorem/zadavatelem vsech tech programu nebo provadet jejich detailni analyzu, aby backdoory odhalil. S analylou v takovych pripadech sice pocitat lze, ale nejakou dobu to trva a cim dele trva rozlusteni, tim lepe. Informace v tomto „oboru“ jiste rychle zastaravaji. Tedy je velky rozdil, kdyz se nekdo dozvi, ze za hodinu ma nekde neco bouchnout nez kdyz se dozvi az po vybuchu.

6. Zlobr napsal:

   24. 11. 2011 (23:16)

   Diky za zajimavou analyzu. Docela me to zaujalo uz kdyz vysel prvni dil Inspire, vic jsem se o to ale nestaral. A ohledne toho slabeho sifrovani – je tu porad moznost, ze je ten program nastrceny a backdoor tam nedali, protoze by to bylo prilis pruhledne.

7. michal zobec napsal:

   18. 11. 2011 (18:40)

   moc pěkný popis, kvůli těmto článkům čtu tento blog 😉

8. petr napsal:

   16. 11. 2011 (20:41)

   úvodní odstavec pobavil:) díky za analýzu

9. pepak napsal:

   15. 11. 2011 (18:02)

   Honza77: Slabiny v popisovaném programu nejsou v šifrovacích algoritmech, tudíž použití kaskád by na mých výhradách nic nezměnilo.

10. Honza77 napsal:

    14. 11. 2011 (22:17)

    A není lepší použití více způsobů šifrování (sériově – tedy šifrovat jedním způsobem a výsledek šifrovat znovu jinak)? Bude to pomalejší, ale stejně ta podstatná data jsou typicky malá.

    PS: Doufám, že to tu nečtou teroristi 🙂