Biztonsági Audit (Jean Philippe Aumasson által)

Örömmel értesítjük, hogy az Ergo sikeresen átment a kód bizonyos (legkritikusabb) részeinek biztonsági auditján. Ezúttal az auditot Jean-Philippe Aumasson (más néven veorq, https://aumasson.jp/) végezte.

A részletes jelentés alább található. Nincs kritikus probléma. Megjegyzések a talált problémákról:

1. A pénztárca jelszavával kapcsolatban ajánlást fogunk adni a protokoll kliens következő verzióiban. Nem biztos, hogy a jelszó szigorú érvényesítése megvalósul, de további konzultációkat fogunk folytatni ezzel kapcsolatban.
2. Az "n" és "k" paraméterek megváltoztatása csak új hálózat indításakor értelmes. Ezeknek a paramétereknek a bányászati csomópontban való megváltoztatása érvénytelen blokkokat eredményez a többi csomópont számára. A protokoll kliensben történő megváltoztatás egy másik forkra való áttérést jelent (a tisztességes protokoll résztvevőitől származó blokkokat el fogják utasítani). Tehát talán nincs szükség extra ellenőrzésekre, mivel az új hálózatokat indító emberek megfelelően beállítják az "n" és "k" értékeket.
3. Jelenleg az Ergo csomópont (valamint más blockchain protokoll kliens és pénztárcák, amelyekről tudomásunk van, valamint a használt kriptográfiai könyvtárak) nem nyújt védelmet a helyben futó oldalsó csatornás támadások ellen (pl. időzítési támadások vagy memóriaellenőrzés rosszindulatú programok vagy vírusok által). Kérjük, védje meg azokat a gépeket, amelyeken pénztárcákat futtat!

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

% Ergo biztonsági értékelés % Jean-Philippe Aumasson % 2019. dec. 07.

Összefoglaló

Az Ergo megkeresett minket, hogy végezzünk biztonsági értékelést az Ergo Platform több összetevőjéről:

• Sigma protokoll bizonyítékok létrehozása és ellenőrzése
• A pénztárca titkos adatainak biztonságos tárolása
• Proof-of-Work érvényesítés

Ez a rövid jelentés összefoglalja értékelésünket, és leírja megállapításainkat és a mérséklési ajánlásainkat.

Sigma protokoll bizonyítékok

Az Ergo protokoll az ErgoScript-re támaszkodik, amely egy szkriptnyelv, amely támogatja a sigma-nyilatkozatokat, amelyeket nem-interaktív tudásbizonyítékok révén lehet bizonyítani és ellenőrizni.

Ezek a bizonyítékok olyan nyilatkozatok, amelyeket AND, OR és küszöbfeltételek fájaként írnak le, amelyek levelei a diszkrét logaritmus problémájának tudásbizonyítékai.

A sigma-nyilatkozat bizonyítéka ezután nem-interaktívvá válik a Fiat-Shamir transzformációnak köszönhetően.

Ez a logika az ErgoScript papírban van meghatározva, és a konkrét
bizonyítási és ellenőrzési rutinok az A függelékében találhatók.

A megvalósítási kihívások a következők:

• Olyan bizonyítékok kódolásának meghatározása, amelyek biztonságosak és hatékonyak, és olyan sorosítás és deszerializálás megvalósítása, amely mindig sikeresen feldolgozza a érvényes bemenetet, és amely mindig elegánsan megbukik az érvénytelen bemenet feldolgozása során.
• A bizonyítási és ellenőrzési funkciók helyes megvalósítása, a specifikációval összhangban, és ami a legfontosabb, hogy semmilyen érvénytelen nyilatkozat ne tudjon sikeresen átmenni az ellenőrzésen.

Ezeket a két szempontot átnéztük, a sigmastate-interpreter tárolóban található kód és az ErgoScript papír alapján, gondosan összehasonlítva a szándékolt viselkedést (az A függelékben) a megvalósított tényleges viselkedéssel.

Különösen a SigSerializer, Interpreter és ProverInterpreter típusok és objektumok kódját vizsgáltuk.

Főként a következő osztályokból kerestünk hibákat:

• Érvénytelen bemenet nem biztonságos feldolgozása
• Szokatlanul hosszú vagy rövid bemenet nem biztonságos feldolgozása
• Viselkedés nagy fa mélység vagy rekurziós szint esetén
• Scala típusok és struktúrák nem biztonságos használata
• Nem megfelelő változó típusok
• Egész számok túlcsordulása
• Versenyhelyzetek
• Logikai hibák

A széleskörű áttekintés ellenére nem azonosítottunk biztonsági problémát.

A protokoll logikája és belső működése azonban viszonylag összetett, és úgy véljük, hogy a legnagyobb kockázat a bizonyítékok elemzésében és ellenőrzésében rejlik. Az ilyen problémák kihasználásához azonban a támadónak egy szemantikailag helyes szkriptet kellene létrehoznia, amely valamilyen módon előnyös számára, de amely az ellenőrzés során nem teljesíti a követelményeket.

A szoftverbiztonság szempontjából a Scala bizonyos hibakategóriákat kiküszöböl, de a Scala kód még mindig szenvedhet hibáktól a Scala specifikus viselkedése vagy a nem kezelt hibák miatt.

Pénztárca

Az Ergo pénztárca funkciója lehetővé teszi a felhasználók számára, hogy titkos adatokat tároljanak lemezen, és visszaállítsák azokat, a pénztárcát új maggal inicializálva, amikor először használják.

Ez a logika főként az ErgoWalletActor fájlban van meghatározva, és a titkos adatok tárolásával kapcsolatos kulcsfontosságú összetevő a JsonSecretStorage.

Az első alkalommal, amikor egy pénztárcát létrehoznak, az InitWallet parancs a következőket végzi:

• Generál settings.walletSettings.seedStrengthBits véletlenszerű bitet, mint kezdeti entrópiát. Alapértelmezés szerint 160 bitet generálnak.
• Generál egy BIP39-et a generált véletlenszerű bitekből, amely az entrópia bitek kódolásaként tekinthető. A standard BIP39 logikát használják, opcionális jelszóval.
• Kinyer egy magot a mnemonikából a BIP39 PBKDF2-alapú kinyerési logikájával.
• Titkosítja ezt a magot lemezre AES-GCM-mel, véletlenszerű nonce használatával, és egy kulcsot nyer ki a jelszóból a PBKDF2-HMAC-SHA256 segítségével 128000 iteráción keresztül, véletlenszerű sóval.

A már létrehozott pénztárca feloldásához a felhasználónak meg kell adnia a jelszót, és a pénztárca megpróbálja dekódolni a tárolt adatokat.

A meglévő fiók BIP39 jelszavából való helyreállításához hasonló folyamatot hajtanak végre, kivéve, hogy a pénztárca a mnemonikából nyeri ki a magot, ahelyett, hogy véletlenszerű mnemonikát választana.

A két kockázat, amelyet itt azonosítottunk:

• A jelszó hosszának ellenőrzésének hiánya: mivel a jelszó elegendő a mag eléréséhez a pénztárca lemezen tárolt titkos adatainak ismeretében, a jelszónak elméletileg legalább annyi entrópiával kell rendelkeznie, mint a mnemonikának, és a gyakorlatban nehezen feltörhetőnek kell lennie. Ezért javasoljuk, hogy érvényesítsenek egy minimális jelszóhosszt, például 16 karaktert.
• A titkos értékek (jelszó, mag és származtatott privát kulcsok) másolatainak valószínűleg a memóriában kell maradniuk a pénztárca szoftver végrehajtása után, ami a Scala nyelvek, például a Scala belső korlátozása.

Egy másik folyamat vagy felhasználó, aki ugyanazon memória címzési térben osztozik, potenciálisan visszaállíthatja a titkokat, és ezek a hibakibővítésekben is megjelenhetnek. Tudomásunk szerint nincs hatékony mérséklés a tiszta Scala esetében.

PoW érvényesítés

A korábbi Autolykos PoW biztonságának áttekintése után egy újabb áttekintést végeztünk, amely a legújabb ellenőrzési logikára összpontosít, különösen a eb0f85a elkötelezettség változásaira.

A legfontosabb releváns fájl az AutolykosPowScheme, és más fontos műveletek például a HeadersProcessor és a ModifierValidator fájlokban találhatók.

Ellenőriztük, hogy a megvalósított ellenőrzési logika összhangban van az Autolykos specifikációkban megadottakkal, és hogy megfelelően integrálva van a blokkfejléc érvényesítési logikájába.

Úgy véljük, hogy a következő pontokat kezelni kell:

• Szigorúbb érvényesítés az k és n esetében: bár az osztály érvényesíti, hogy k<=32 (a megoldás elemeinek száma) és n<31 (az elemek összes számának log2-je), gyenge még mindig létrehozható a megengedett paraméterekből. A validate() funkciónak ezért további érvényesítést kellene végeznie, hogy n és k egyenlő legyen a szándékolt
  értékekkel.
• Biztosítani kell, hogy k és n pozitív értékek legyenek, mivel jelenleg a negatív értékek (mint Ints) átmennek az assert állításokon.