Hlavní navigace

Bezpečnostní audit TrueCryptu bude pokračovat

23. 2. 2015

Sdílet

V říjnu 2013 spustili profesor Matthew Green a bezpečnostní analytik Kenneth White projekt bezpečnostního auditu programu TrueCrypt. První fáze auditu proběhla a nebyly odhaleny vážné nedostatky. Poté ovšem došlo k něčemu nepředvídatelnému – projekt TrueCrypt byl z neznámých důvodů ukončen, což vyvolalo paniku a vedlo k vytvoření několika klonů.

Neproběhla ovšem druhá fáze auditu, která měla za úkol kontrolu kódu a především implementace šifrovacích funkcí. Cílem bylo samozřejmě najít potenciální bezpečnostní díry, které by mohly být hrozbou pro uživatele. Po roce se audit vrací na scénu a provede ho tým expertů ze společností iSEC Partners, Matasano, Intrepidus Group a NCC Group. Cena auditu je odhadována na 70 000 dolarů, peníze byly už dříve vybrány pomocí několika crowdfundingových kampaní. Zkoumána bude nejnovější vydaná verze 7.1a.

Nutno říct, že bezpečnostních analýz TrueCryptu proběhlo v minulosti několik. V roce 2007 o jedné psal tady na Rootu Vlastimil Klíma, vlastní rozbor si v roce 2011 udělal i Ubuntu Privacy Remix Team. Ani jedna z těchto analýz nenašla v TrueCryptu žádnou výraznou bezpečnostní chybu. Nová analýza ale bude daleko důkladnější (a dražší), takže snad přinese definitivní potvrzení bezpečnosti TrueCryptu.

Našli jste v článku chybu?
  • Aktualita je stará, nové názory již nelze přidávat.
  • 23. 2. 2015 16:04

    cz3dtc

    Vcelku bezpečný software se velmi špatně prolamuje a to se NSA a podobným nehodí , proto zanesou strach a lidi přejdou na děravou alternativu. Jak jednoduché.

  • 23. 2. 2015 16:33

    Pali (neregistrovaný)

    "...snad přinese definitivní potvrzení bezpečnosti TrueCryptu."

    Definitivne to bude iba vtedy ak tam najdu nejaky vazny bezpecnostny problem...
    Ak tam opat nic nenajdu, tak stale sa najdu ludia co si budu mysliet svoje o bezpecnosti...

  • 23. 2. 2015 19:27

    _pepak (neregistrovaný)

    Bezpečnost programu nelze definitivně prokázat. Definitivně prokázat jde pouze ne-bezpečnost. Ale to ničemu nevadí - pokud známí experti dají TrueCryptu "potvrzení", že v něm nic nenašli, bude to *mnohem* víc, než má jakýkoliv jiný veřejně dostupný šifrovací SW.

  • 23. 2. 2015 21:48

    Kolemjdoucí (neregistrovaný)

    Bezpečnost průměrného programu lze až na pár výjimek prokázat zaručeně a definitivně, pro sérii exaktně definovaných příkazů jde určit exaktní výsledek série.
    Bezpečnost šifer se při bezpečnostním auditu nezkoumá.

  • 24. 2. 2015 10:19

    Karel (neregistrovaný)

    Prokázat neexistenci vady není možné. Nenechte se zmást pojmem "existence bezpečnosti", protože ve skutečnosti se ověřuje, že tam není žádná chyba ani vada.

    Vaše věta "pro sérii exaktně definovaných příkazů jde určit exaktní výsledek série" pak zřejmě předpokládá systém, který nemá žádné vstupní parametry. Tedy třebas konstanta. Jakmile jsou nějaké vstupní parametry, tak už je potřeba zkoumat, jak na tyto parametry systém reaguje. Třebas generátor konstanty PI, kde jako parametr je požadovaný počet desetinných míst. A rázem musíte zkoumat, jak to reaguje na malá čísla, jak na velká, jak na záporná, jak na desetinná a jak na hodně velká (nedojde tomu pamět? Nepřeteče tam nějaká proměnná?) Navíc jako auditor hledáte právě takové kombinace vstupních hodnot, kdy se to začne chovat chybně. A ta nemožnost to "absolutně ověřit" plyne z toho, že nemůžete zkusit všechny kombinace vstupů, ale jen nějakou množinu. Že pro ni to funguje ještě neznamená, že neexistuje jiná, pro kterou začne "chodit pěšinkama".

    A ještě jedna věc, k té vaší "zaručeně a definitivně". Zkuste tohle v několika programovacích jazycích, ve skriptech, zkuste to jako float i jako double:

    a = 2000000
    b = 0.000002
    c = a + b
    echo a
    echo b
    echo c

    Co může být jednoduššího, než sečíst dvě čísla? Přesto většinu lidí překvapí, co se při použití 32bitového floatu uloží do c. A otázka pak je, zda by to nešlo nějak zneužít. Přidejte fakt, že řada lidí používá desetinná čísla a operátor porovnání na přesnou shodu a máte dost možná útočný vektor.

  • 24. 2. 2015 11:06

    Kolemjdoucí (neregistrovaný)

    Samozřejmě deterministický proces zahrnuje i vstupní proměnné a ano může to být časově náročné, mimo jiné proto jsou audity finančně náročné.

    Mohu Vás ubezpečit, že chování IEEE754 je taktéž exaktně definované a bezpečnostní auditor ho zná jako když bičem mrská.

  • 24. 2. 2015 14:45

    d.c. (neregistrovaný)

    O koze a o voze...

    Jasne, ze nejde najit *obecny zpusob*. Kdyby to slo, nejsou auditori potreba, protoze by se to pridalo do kompilatoru a bylo by (tedy az na chyby kompilatoru) hotovo.

    Jasne, ze metodologicky vzato nelze potvrdit platnost hypotezy. Ale tady se nebavime o hypotezach pri pozorovani, ale o vcelku deterministickem systemu (at uz tomu sami programatori veri nebo ne - ze nerozumim tomu, jak to funguje, neznamena preci, ze to tak nefunguje).

  • 24. 2. 2015 20:17

    agent (neregistrovaný)

    Halting problém taky řeší deterministický systém a říká, že pro známý program a známý vstup neexistuje obecná metoda, která rozhodne, zda program někdy skončí. Security audit je ještě o řád složitější, protože se pro známý program a neznámý (libovolný) vstup snaží dokázat, že program neskončí v nedefinovaném stavu. Tohle exaktně vyřešit neumíme. Jistě, můžete se zeptat nějakého "experta", který se podívá do křišťálové koule a prohlásí daný program za bezpečný, ale nic to nedokazuje, je to tvrzení postavené na dobré víře, které nemáte jak ověřit.

  • 24. 2. 2015 21:41

    Pali (neregistrovaný)

    Nie, halting problem hodnoti ci *lubovolny* program vzdy skonci alebo nie. Security audit pre *konkretny* program, hodnoti ci skonci vzdy v definovanom stave.

    Vseobecny halting problem nie je mozne riesit algoritmicky. Ale pre nejaku mnozinu problemov (napr. uz LBA) algoritmicky riesitelny je.

    Pri security audite sa hodnoti iba jeden program (a nie nekonecne velku mnozninu programov).

    Najdu sa aj konkretne priklady programov o ktorych ide rozhodnut ci vzdy skoncia alebo nie. A taktiez teoreticky pre nejake programy ide formalne dokazat ze vzdy skoncia v definovanom stave. Neznamena to ale ze bude nutne existovat vseobecny nejaky postup ako sa k dokazu dopracovat.

  • 25. 2. 2015 2:36

    Lael Ophir (neregistrovaný)

    Nepotřebujete řešit halting problém. Potřebujete zaručit, že kód nemá vedlejší efekty. Například že konkrétní metoda nezasahuje do jiných dat, než vstupních a výstupních. Tohle a řada jiných věcí se dá ověřit kombinací vhodného jazyka a systematického strojového ověření zdrojáku.
    Dá se to dokonce dovést tak daleko, že celý OS může běžet v jednom procesu, protože je formální verifikací ověřeno, že žádný kód nebude lézt kam nemá. Bohužel to stojí nějaký výkon, a vyžaduje to přepsání prakticky veškerého SW, takže si na to ještě počkáme.
    http://research.microsoft.com/pubs/69431/osr2007_rethinkingsoftwarestack.pdf

  • 25. 2. 2015 7:14

    _pepak (neregistrovaný)

    Pokud dokazujete bezpečnost programu, tak musíte dokázat mnohem víc. Program se může chovat zcela bez vedlejších efektů a přesto nebude bezpečný. Systematické ověření zdrojáku vám nepomůže, protože bezpečnostní slabina nemusí být ve zdrojáku rozpoznatelná jako slabina. Abych dal názorný příklad: Můžete mít program šifrující pomocí 3DES. Z programátorského hlediska to bude naprosto v pořádku, nikde nebude docházet k přepisům neočekávané paměti nebo k používání neinicializovaných proměnných apod., ale pokud tvůrce programu dosáhne toho, že jsou všechny tři použité klíče stejné, tak výstup programu sice bude v pořádku z hlediska specifikací (tzn. ani ověřením testových vektorů nic špatného nezjistíte), ale bude snadno prolomitelný (složitost jako DES, ne jako 3DES). No a vy jako bezpečnostní auditor byste potřeboval dokázat, že pro žádnou kombinaci vstupů a vnitřních stavů k tomuto nemůže dojít. A že neexistuje ani žádné jiné myslitelné oslabení algoritmu. A to nedokážete. Dokážete akorát říct, že jste nenašel nic, co by nasvědčovalo této možnosti. Problém je v tom, že na tohle oslabení programátor nepřijde, protože nerozpozná bezpečnostní dopady zdánlivě neškodné operace, a kryptolog, který by to rozpoznat mohl, zase v programu nerozpozná (když to útočník udělá šikovně), že program dělá něco navíc. I když budou program zkoumat programátor a kryptolog společně, budou mít problémy kvůli komunikaci (co jednomu přijde samozřejmé, to nebude říkat tomu druhému, a pravděpodobně tak slabé místo přeskočí).

  • 25. 2. 2015 8:01

    agent (neregistrovaný)

    Já jen doplním, to co už psal _pepak. Když budu mít kód typu:

    // authenticate user
    do {
        username = GetUsername();
        password = GetPassword();
    } while (!UserValid(username, password))
    // send money
    destinationAccountNumber = GetDestinationAccountNumber();
    amountOfMoney = GetAmountOfMoney()
    SendMoney(destinationAccountNumber, amountOfMoney);

    Tak musím řešit halting problem (skončí ten do while cyklus někdy? skončí jen pro platná data?), ale to je jen malá část problému. Musím navíc ověřit, že všechny funkce dělají to, co mají dělat. Vhodnou volbou jazyka lze omezit chyby typu buffer overflow (za předpokladu, že veříme kompilátoru/virtual machine) a možná i ten halting problem, pokud použiju něco ultimátně funkcionálního, ale jazyk sám o sobě nezaručí, že tam nebudou záměrné nebo náhodné chyby. Když bude ve funkci SendMoney podmínka typu:

    if (date() == datumMojiCestyNaBahamy && amountOfMoney >= 1000000) {
        PosliPenizeNaMujUcetNaBahamach(amountOfMoney)
    }

    Nezjistí to automatický test a je určitá pravděpodobnost (ne 100%), že to objeví auditor. Takových chyb ať už úmyslných nebo neúmyslných tam může být celá řada docela dobře schovaných. Takže ani po auditu kódu nelze nikdy na 100% prohlásit, že je to bezpečné.

  • 28. 2. 2015 21:16

    Lael Ophir (neregistrovaný)

    Chyba v kódu a špatný (volitelně záměrně špatný) design jsou dvě různé věci. Když se podíváte na ty stovky ročně bugů v každém browseru, v Adobe Flashi, Adobe Readeru, Javě, všech OS atd., jde typicky o chyby v kódu, o side effecty. Typicky jde o různé variace na téma práce s pamětí, nejčastěji (trestuhodně) buffer overflow. SW průmysl je ve velmi špatném stavu, děravé je prakticky všechno od kernelů až po browsery. Přitom s tímhle si už poradit umíme, vizte projekt Singularity, který jsem linkoval. Samozřejmě u toho zapomeňte na jazyk C, který je z hlediska verifikace noční můrou, a na standardní funkce knihoven typu strcpy(), které jsou nebezpečné už z principu.

    Samozřejmě projekt typu Singularity není schopný odhalit, že je špatný návrh aplikace, případně že je návrh špatný záměrně. To ze samotného kódu odhalit ani nelze. Dá se ale verifikovat kód podle strojově čitelné specifikace.

    Jinak co se týká problému zastavení, tam to není tak problematické. Ve vámi uvedeném případu můžete v některých variantách říct zcela jistě, že se kód nezastaví (například pokud UserValid() vrací vždy false), a v jiných případech se minimálně dozvíte, že se zastavit nemusí. To pro většinu účelů stačí.

  • 28. 2. 2015 21:23

    Lael Ophir (neregistrovaný)

    Chyba v kódu a špatný (volitelně záměrně špatný) design jsou dvě různé věci. Když se podíváte na ty stovky ročně bugů v každém browseru, v Adobe Flashi, Adobe Readeru, Javě, všech OS atd., jde typicky o chyby v kódu, o side effecty. Typicky jde o různé variace na téma práce s pamětí, nejčastěji (trestuhodně) buffer overflow. SW průmysl je ve velmi špatném stavu, děravé je prakticky všechno od kernelů až po browsery. Přitom s tímhle si už poradit umíme, vizte projekt Singularity, který jsem linkoval. Samozřejmě u toho zapomeňte na jazyk C, který je z hlediska verifikace noční můrou, a na standardní funkce knihoven typu strcpy(), které jsou nebezpečné už z principu.

    Samozřejmě projekt typu Singularity není schopný odhalit, že je špatný návrh aplikace, případně že je návrh špatný záměrně. To ze samotného kódu odhalit ani nelze. Dá se ale verifikovat kód podle strojově čitelné specifikace.

    Jinak co se týká problému zastavení, tam to není tak problematické. Ve vámi uvedeném případu můžete v některých variantách říct zcela jistě, že se kód nezastaví (například pokud UserValid() vrací vždy false), a v jiných případech se minimálně dozvíte, že se zastavit nemusí. To pro většinu účelů stačí.

  • 26. 2. 2015 8:53

    mixss (neregistrovaný)

    I problém různých hodnot proměnných je při analýze kódu možné řešit, viz. např. statický analyzátor kódu ASTREE od AirBusu. Pro všechny proměnné si drží maximální interval známých hodnot a, kromě jiného, tyto údaje používá právě k testování možného přetečení.

    Ad. není možné dokázat absolutní bezpečnost softwaru, ale je to možné. Stojí to sice zhruba 1000$/SLOC, ale už to někdo udělal, viz. microkernel seL4.

  • 24. 2. 2015 7:34

    Jakub L. (neregistrovaný)

    Spousta šifrovacích aplikací prochází audity... třeba Encfs nedávno prošlo auditem (ne moc hladce, ale hned mají vývojáři co dělat)

  • 25. 2. 2015 7:19

    _pepak (neregistrovaný)

    Proto jsem také psal, že to bude zajímavé, pokud *známí experti* dají TrueCryptu potvrzení, *že nic nenašli*. Třeba to EncFS určitě nesplnilo druhý požadavek. První požadavek je samozřejmě vysoce subjektivní, pro mě T. Hornby "známý expert" není, což může být samozřejmě jen moje chyba, ale počet výskytů jeho jména na Google Scholar mě moc neuspokojil.

  • 16. 3. 2015 23:00

    Anonym [dev.] (neregistrovaný)

    1.

    True Crypt použivá zastaralý systém hashovaní/šifrovaní hesla
    [(malý počet iretací)] je malý což stačí prolomení metodou BrutefForce.

    Hlavní chyba v True-Cryptu je v šifrovaní hesla které se pak následně ukládá jako headr-key.

    Před 10lety program byl bezpečný z důvodu že nebyli tak výkoné stroje co by ho prolomily...

    2. Slabá funkce CRC32 pro keyfiles je slabá

    3. matematický model [ je vytečný 2^256 nebo 2^512 nebo 2^728]
    počet moňných klíčů

    Když jsou hlavní chyby jsou ve vstupu je lepsí program zahodit.

    Doporučujeme verzi programu VeraCrypt který převzal Francouzky matematik a kryptograf Mounir IDRASSI.

    4. V True Cryptu nejsou Backdoory.!!!!!

    """Projekt True Crypt na dobro skončil,,,,,,

    TC foundation

Byl pro vás článek přínosný?

Autor zprávičky

Petr Krčmář pracuje jako šéfredaktor serveru Root.cz. Studoval počítače a média, takže je rozpolcen mezi dva obory. Snaží se dělat obojí, jak nejlépe umí.