Bezpečnostný audit (Jean Philippe Aumasson)

Radi by sme oznámili, že Ergo úspešne prešiel bezpečnostným auditom určitých (najkritickejších) častí kódu. Tentokrát audit vykonal Jean-Philippe Aumasson (alias veorq, https://aumasson.jp/ ).

Podrobná správa je nižšie. Neboli zistené žiadne kritické problémy. Komentáre k zisteným problémom:

1. K heslu peňaženky poskytneme odporúčanie v nasledujúcich verziách protokolu klienta. Nie sme si istí, či sa zavedenie prísneho vynútenia hesla uskutoční, ale budeme sa o tom viac poradiť.
2. Zmena parametrov "n" a "k" má zmysel len pri spúšťaní novej siete. Zmena týchto parametrov v ťažobnom uzle spôsobí, že bloky vyprodukované budú neplatné pre ostatné uzly. Zmena týchto parametrov v protokolovom klientovi znamená prechod na iný fork (bloky prichádzajúce od čestných účastníkov protokolu budú odmietnuté). Takže možno nie je potrebné robiť ďalšie kontroly, pretože ľudia spúšťajúci nové siete správne nastavia "n" a "k".
3. V súčasnosti Ergo uzol (ako aj iné protokoly blockchain klientov a peňaženiek, o ktorých vieme, ako aj kryptografické knižnice, ktoré používame) neposkytujú ochranu pred útokmi bočného kanála, ktoré prebiehajú lokálne (napr. časové útoky alebo kontrola pamäte malvérom alebo vírusmi). Takže prosím chráňte stroje, na ktorých spúšťate peňaženky!

==========================================================================================================

% Bezpečnostné hodnotenie Ergo % Jean-Philippe Aumasson % 07/Dec/19

Zhrnutie

Boli sme požiadaní spoločnosťou Ergo, aby sme vykonali bezpečnostné hodnotenie niekoľkých komponentov ich platformy Ergo:

• Vytváranie a overovanie dôkazov protokolu Sigma
• Bezpečné ukladanie tajomstiev peňaženky
• Overovanie Proof-of-Work

​Táto stručná správa sumarizuje naše hodnotenie a popisuje naše zistenia a odporúčania na zmiernenie.

Dôkazy protokolu Sigma

​Protokol Ergo sa spolieha na ErgoScript, skriptovací jazyk podporujúci sigma-vyhlásenia, ktoré môžu byť dokázané a overené prostredníctvom neinteraktívnych dôkazov znalosti.

Tieto dôkazy sú vyhlásenia opísané ako strom podmienok AND, OR a prahových podmienok, ktorých listy sú dôkazmi znalosti problému diskrétneho logaritmu.

Dôkaz sigma-vyhlásenia je potom spravený neinteraktívnym spôsobom vďaka transformácii Fiat-Shamir.

Táto logika je špecifikovaná v dokumente ErgoScript, a konkrétne
rutiny dokazovania a overovania sú opísané v jeho Prílohe A.

​Implementačné výzvy sú potom:

• Definovať kódovanie dôkazov, ktoré sú bezpečné a efektívne, a implementovať serializáciu a deserializáciu, ktorá vždy úspešne spracováva platný vstup a ktorá vždy elegantne zlyhá pri spracovaní neplatného vstupu.
• Správne implementovať funkcie dokazovania a overovania v súlade so špecifikáciou, a najdôležitejšie, aby žiadne neplatné vyhlásenie nemohlo úspešne prejsť overením.

Preskúmali sme tieto dva aspekty na základe kódu v repozitári sigmastate-interpreter a na základe dokumentu ErgoScript, starostlivo porovnávajúc zamýšľané správanie (v Prílohe A) s aktuálnym správaním, ako je implementované.

​Osobitne sme preskúmali kód z SigSerializer, Interpreter a ProverInterpreter vlastností a objektov.

​Hlavne sme hľadali chyby z nasledujúcich tried:

• ​Nezabezpečené spracovanie nesprávneho vstupu
• Nezabezpečené spracovanie nezvyčajne dlhého alebo krátkeho vstupu
• Správanie pri veľkej hĺbke stromu alebo úrovni rekurzie
• Nezabezpečené použitie typov a štruktúr Scala
• Nevhodné typy premenných
• Pretečenia celých čísel
• Pretečenia podmienok
• Logické chyby

​Napriek rozsiahlemu preskúmaniu sme nezistili žiadny bezpečnostný problém.

Logika a vnútornosti protokolu sú napriek tomu relatívne zložité a veríme, že najvyššie riziko spočíva v analýze a overovaní dôkazov. Na to, aby sa takéto problémy využili, by však útočník musel vytvoriť sémanticky správny skript, ktorý by mu nejako prospieval, ale ktorý by prešiel overením, keď by nemal.

Pokiaľ ide o bezpečnosť softvéru, Scala eliminuje určité triedy chýb, ale kód Scala môže stále trpieť chybami kvôli špecifickému správaniu Scaly alebo kvôli nevybaveným chybám.

Peňaženka

Funkcionalita peňaženky Ergo umožňuje svojim používateľom uložiť tajomstvo na disk a obnoviť ho, pričom pri prvom použití inicializuje peňaženku s novým semenom.

​Táto logika je hlavne definovaná v ErgoWalletActor, a kľúčovou súčasťou týkajúcou sa ukladania tajomstiev je JsonSecretStorage.

​Pri prvom vytvorení peňaženky príkaz InitWallet vykonáva nasledujúce:

• Generuje settings.walletSettings.seedStrengthBits náhodných bitov ako počiatočnú entropiu. Podľa predvoleného nastavenia sa generuje 160 bitov.
• Generuje BIP39 z náhodných bitov, ktoré môžu byť považované za kódovanie entropických bitov. Používa sa štandardná logika BIP39, s voliteľným heslom.
• Odvodí semeno z mnemotechnickej frázy pomocou logiky derivácie založenej na PBKDF2 BIP39.
• Šifruje toto semeno na disk pomocou AES-GCM, pričom používa náhodný nonce a kľúč odvodený z hesla pomocou PBKDF2-HMAC-SHA256 s 128000 iteráciami, pričom používa náhodnú soľ.

Aby odomkol už vytvorenú peňaženku, používateľ poskytne heslo a peňaženka sa pokúsi dešifrovať uložené údaje.

​Na obnovenie existujúceho účtu z BIP39 frázy sa vykonáva podobný proces ako pri inicializácii, s tým rozdielom, že peňaženka odvodí semeno z mnemotechnickej frázy namiesto výberu náhodnej mnemotechnickej frázy.

​Dve riziká, ktoré sme tu identifikovali, sú:

• Absencia kontrol na dĺžku hesla: keďže heslo je dostatočné na prístup k semenu vzhľadom na tajomstvo uložené na disku peňaženky, heslo by teoreticky malo mať aspoň toľko entropie ako mnemotechnická fráza a v praxi by malo byť prakticky ťažké ho prelomiť. Odporúčame preto vynútiť minimálnu dĺžku hesla, napríklad 16 znakov.
• Kópie tajných hodnôt (heslo, semeno a odvodené súkromné kľúče) pravdepodobne zostanú v pamäti po vykonaní softvéru peňaženky, čo je vnútorné obmedzenie jazykov s garbage collection, ako je Scala.

Iný proces alebo používateľ zdieľajúci rovnaký priestor adresy pamäte by mohol potenciálne obnoviť tajomstvá a mohli by sa tiež objaviť v dumpoch pri zlyhaní. Podľa našich najlepších vedomostí neexistuje účinné zmiernenie v čistej Scale.

​

Overenie PoW

​Po predchádzajúcom preskúmaní bezpečnosti Autolykos PoW sme vykonali ďalšie kolo preskúmania zamerané na jeho najnovšiu overovaciu logiku, a najmä zmeny v commite eb0f85a.

​Hlavný relevantný súbor je AutolykosPowScheme, a iné dôležité operácie sú napríklad implementované v
HeadersProcessor a ModifierValidator.

​Skontrolovali sme, že implementovaná overovacia logika je konzistentná s tou, ktorá je špecifikovaná v špecifikáciách Autolykos, a že je správne integrovaná do logiky overovania hlavičky bloku.

​Veríme, že nasledujúce body by mali byť riešené:

• Prísnejšia validácia k a n: hoci trieda vynucuje k<=32 (počet prvkov v riešení) a n<31 (log2 celkového počtu prvkov), slabé by sa stále mohli vytvoriť z autorizovaných parametrov. Funkcia validate() môže preto mať ďalšiu validáciu, že n a k sú rovné zamýšľaným
  hodnotám.
• Potvrdiť, že k a n sú kladné hodnoty, pretože v súčasnosti by negatívne hodnoty (ako Ints) prešli assert vyhláseniami.