Kormányablak, Ügyfélkapu, magyarorszag.hu, kormany.hu
KORMÁNYABLAK, ÜGYFÉLKAPU - A ZÁRT AJTÓK MÖGÖTT...
(nem hivatalos e-kormányzati témájú oldal)
  
BEMUTATKOZÁS 
E-KÖZIGAZGATÁS 
IT BIZTONSÁG 
  
































  Mottó:
Nálam mindig két forint ez a dal
/P. Mobil: Kétforintos dal/
2014. augusztus 4.  
 Bitcoin - Aprópénz? 
   
A Bitcoin egy érdekes valami... Valami, ami jogilag ugyanannyit ér, mint egy darab krumpli, mégis megvesznek érte az emberek... Valami, aminek értékét nehéz bármihez is kötni, mégis van hivatalos USD/BTC árfolyama... Valami, aminek ikonikus alakja Satoshi Nakamoto (a Genesis-block - 50 BTC, 2009-01-03 - létrehozója), Nick Szabo (a Bitcoin élharcosa), illetve Laszlo Hanyecz, aki az első (és második) pizzát fizette ezzel a virtuális eszközzel (10.000 BTC, 2009-01-12)... Valami, ami teljesen decentralizált és nyílt rendszeren alapul, de kezdetben elsősorban az alvilágban terjedt el (Silk Road, emberrablásoknál váltságdíj követelése stb.)...

Hogy ennél pontosabban mi is a Bitcoin? Azt jól leírja a magyar portál ([1]), de jól szemlélteti ez az ábra is:

Mi is kell ahhoz, hogy legyen Bitcoin-unk? Egy számítógép, okostelefon amire települhet a pénztárca alkalmazás, ami létrehozza a kulcspárunkat, sőt, erre akár ilyen szolgáltatást is igénybe vehetünk (tárolt kulcsos megoldás). Ezután ezt használva - elektronikusan aláírt tranzakciókat létrehozva - lehet pénzt küldözgetni másnak. A címzettről elég csak az ő azonosítóját (nyilvános kulcsáról képzett lenyomatát) ismerni. Persze, ahhoz, hogy küldeni tudjunk pénzt, előbb valahogy szerezni kell: lehet egyszerűen, hagyományos módon váltani pl. USD-ről (ilyenkor más által bányászott, kibocsátott pénzt veszünk), illetve lehet bányászni is, vagyis megfelelő kriptográfiai lenyomatokat (és bemenő blokk-paramétereket) keresni.

A cikkekben általában ennyit írnak erről a virtuális pénzről, crypto currency-ről. Érdemes tudni azonban, hogy a Bitcoin csak az egyik - jelenleg legnépszerűbb - ilyen eszköz, de számos vetélytársa van. Léteznek olyanok, amelyek csak a kriptográfiai rétegben térnek el, de vannak olyanok is, amelyeknél a működési modell is tartalmaz már egy-két csavart.

A crypto currency családfában az alkalmazott lenyomatképző algoritmus vízválasztónak számít: ez alapján két típusra (SHA-256 és scrypt) különíthetők el az egyes változatok. ([2], [3])

Az SHA-család ismert és elismert algoritmusokat tartalmaz, komolyabb törésről nincs információ (igaz, az SHA-3 esetében a Merkle-Damgard struktúra gyengeségei miatt már mást irányoztak elő). A scrypt ezzel szemben újoncnak számít, még a szabványosítóknál is csak draft változatban létezik ([4]), pedig komoly előnye lehet ennek a HMAC-alapú (PBKDF2-t kiegészítő) algoritmusnak, hiszen megfelelő paraméterválasztás esetén a memóriaigényes műveletek miatt nagyobb védelmet tud jelenteni, mint egy csak CPU-igényes SHA-256, amelyet hardveresen könnyebben meg lehet valósítani (ld. gyors FPGA, ASIC megoldások). A hangsúly viszont a "megfelelő paraméterválasztáson" van, legalábbis erre hívta fel a figyelmet Anthony Ferrara (ircmaxell), aki a scrypt-alapú pénzeknél alkalmazott értékeket (CPU_memory_cost: n = 1024; block_size: r = 1; parallelization: p = 1;) nem találja túl erősnek ([5]). A lenyomatképzésen túlmenően a Bitcoin és a többi crypto currency által alkalmazott ECDSA aláíró algoritmusra is nagyon kell figyelni. Igaz ugyan, hogy gyors, és kisebb kapacitású, beágyazott rendszereknél előszeretettel alkalmazzák az ECDSA-t, viszont az RSA-val szemben itt az aláírásnak is (nemcsak a kulcsgenerálásnak) fontos része a jó minőségű PRNG. Pont a Bitcoin csapata vette észre 2013. őszén, hogy az Android JCA által használt PRNG nem jól működik, így az azzal generált aláírások (tranzakciók) alapján a pénztárcák titkos ECDSA kulcsai kitalálhatóvá váltak (gyakorlatilag megismétlődött a Sony PlayStation3 esete). Egy ECDSA aláírást különböző elliptikus görbék alapján lehet létrehozni. A Bitcoin által kiválasztott secp256k1 viszont pont egy olyan görbe, amihez egyrészt nincs HW támogatás (pl. Thales HSM-ek is csak a secp256r1 görbét támogatják), másrészt bizonyos támadások ellen nem nyújt kellő védelmet (ld. Daniel J. Bernstein táblázatait, pqcrypto.org, [6]). A HW-támogatás hiánya részben az oka annak is, hogy a Bitcoin pénztárca szolgáltatók sem tudnak nagyobb biztonságot nyújtani ügyfeleiknek, SW tokenként tudják csak tárolni a kulcsokat, ezért, ha valaki betör a rendszerükbe, akkor az összes felhasználó tranzakciót aláíró kulcsai elveszhetnek. Ugyanígy a vastagkliens mellé is csak akkor lehet PKI chipkártyát használni, ha ezen görbe támogatását valaki megvalósítja egy JavaCard, .NET card applet-ként (és ezen applet kódja egy független szakértői auditon is átment).

Miért fontos az, hogy milyen algoritmust használnak ezek a pénzek? Az összes crypto currency esetében szükség van egy "proof of work" adatra, egy matematikailag nehéz probléma (pl. jó hash megtalálása) megoldására. Ez a lenyomatképzés a jóváhagyandó tranzakción és valamilyen véletlen adaton hajtódik végre, tulajdonképpen a visszaigazolásnál ezen véletlen adatnak a megtalálása a cél a hash-ek számolgatásával. A pénz létrehozása (mining) során is hasonló folyamat hajtódik végre (egyszerűbb esetben CPU, GPU + CUDA/OpenCL támogatás, Amazon cloud GPU segítségével, profiknál pedig FPGA vagy ASIC meghajtásával). Ennek a feladatnak a megoldását amennyire lehet szét kell kenni a hálózatban, máskülönben ha előfordul, hogy egy kézben túl sok számítási kapacitás összpontosul (">50% attack"), akkor az illető képes lehet irányítani a teljes rendszert (pl. alternatív láncok propagálása, "double spending"). Az SHA-256 esetében a CPU-igényes feladatot néhány ASIC felhasználásával jelentősen meg lehet támogatni ([7], [8], [9]), ugyanakkor scrypt esetében a hardveres megvalósításoknak gátat szab a nagy memóriaigény is (ennek ellenére már lehet hallani ASIC-ról scrypt esetében is, de ott a memória méretét érdemes lesz megnézni).

Az alkalmazott kriptográfián túlmenően (pl. Litecoin a scrypt algoritmussal az SHA-256 helyett) maga a crypto currency rendszer protokollja is tehet ellenintézkedéseket az ">50% attack" támadással szemben. A Peercoin esetében pl. bevezetésre került a "proof of stake" érték is, ami nemcsak a számítási kapacitás alapján korlátozza egy felhasználó "hatalmát", hanem az általa birtokolt pénz mennyiségétől függően is. Így aztán, hiába van nagy számítási kapacitása valakinek, ha nincs elég pénze, akkor nem valósulhat meg az ">50% attack", ha pedig mégis van sok pénze (pl. kisebb hálózatok esetében ez előfordulhat), akkor pedig az illetőnek nem áll érdekében csalni, mivel lezuhanna a crypto currency árfolyama, és csak vesztesége keletkezne. A Peercoin, mint alternatív crypto currency más újításokat is megvalósított. A közgazdászok által emlegetett deflációs spirál elleni védelemként beépítettek a rendszerbe egy rögzített mértékű inflációt, illetve a coin-mennyiséget is korlátlanná tették. A Bitcoin megkapta annak idején, hogy inkább befektetésként használják a coin-okat, nem fizetőeszközként. Megindulhat belőlük a felhalmozás, egyre nehezebben lehet szerezni, emelkedhet az értékük, nehézzé válhat pénzre váltani az eladni kívánt árut, szolgáltatást, amelynek ára emiatt csökkenhet és ez deflációhoz vezethet. A Peercoin beépített inflációja és "korlátlan" coin-készlete viszont pont a költekezésre, a fizetőeszközként való felhasználásra ösztönöz a felhalmozással szemben. A harmadik említésre méltó dolog a Peercoin rendszerében a "checkpointing" rendszeres alkalmazása, az aktuális állapotok időszakos rögzítése, lementése. Részben emiatt a Peercoin jóval kevésbé érzékeny a Bitcoin kapcsán 2013. november 1-én bemutatott "selfish mining strategy" támadásra ([10]), amelynél azt használták ki, hogy több azonos blokklánc közül kizárólag a hossz alapján választ a rendszer, hogy melyiknek a továbbépítését javasolja az összes peer-nek. Ha sikerül egy blokkláncból másik irányba elindulni és ahhoz a háttérben több elemet hozzáfűzni, majd a kellő hosszúságú láncot publikálni, akkor elérhető, hogy a támadók által felépített blokkláncot kezdi el továbbépítgetni a rendszer összes bányásza (a pl. webshop-os utalást tartalmazó blokklánc helyett). Az alternatív pénzrendszerek közül a Mastercoin-t is érdemes kiemelni, amelynél - többek közt - lehetőség van a tranzakciók visszavonására a virtuális letét protokollba illesztése révén (a valós piaci igényeknek megfelelően). A Zerocoin pedig egyfajta pénzmosodai (laundry) funkciót valósít meg (Bitcoin és Zerocoin pénzrendszerek közötti pénzmozgatással, egymáshoz rögzített árfolyamon), így biztosítva a tényleges anonimitást (hiszen jelenleg a Bitcoin csak addig anonim, amíg nem kötődik össze a virtuális cím a való életbeli entitással). Léteznek olyan virtuális pénzek is, amelyek egy-egy adott játékhoz kapcsolódóan bírnak értékkel. Ilyeneket viszont bárki (klub, kisváros stb.) létrehozhat ([11]), amihez elég csak megadni a mintát, az alkalmazandó algoritmust (Bitcoin és SHA-256 vagy Litecoin és scrypt).

És ha van már pénz a rendszerben, és az elfogadóhelyek száma nő, akkor vélhetőleg a kereskedés/felhalmozás is megindul, attól függően, hogy a felhasználók mit várnak az árfolyamtól. Innentől kezdve már mindenki maga dönti el, hogy befektetésként gondol-e rá, vagy fizetőeszközként, amivel akár pizzát is tud venni.

A Bitcoin árfolyamát elnézve pl. jó lett volna az októberi fizetést BTC-ben kapni, hiszen 5 hét alatt termelt volna 400% nyereséget (aki akkor nem realizálta ezt, az is még elég jól járna a jelenlegi árfolyam szerint). Az is igaz, hogy fáj belegondolni abba, hogy 2009-ben, egy téli estén 10.000 BTC-ért vettek két pizzát, ami a december 4-i árfolyam alapján 2.5 milliárd Ft-ért jött házhoz. Az árfolyamok azonban a különböző kereskedőknél eltérhetnek. Ennek hátterében a korábban piacvezetőnek számító Mt. Gox rendszerében sokáig nem kezelt hibák húzódtak meg, amik végül csődbe is rántották a céget.

A Bitcoin működésének részleteit a forráskódokból kiolvasva lehet megismerni a legegyszerűbben (vannak ugyan jó wiki leírások, de a script-elgetései miatt könnyen el lehet veszíteni a fonalat pl. akkor, amikor a pontos aláírandó adatot kell keresni). A témával ilyen szinten - a pénztárca alkalmazások fejlesztőin kívül - csak néhány kíváncsi bitbuherátor foglalkozott, közülük is Ken Shirriff leírása ([12]) talán az, ami a legrészletesebb (az engem érdeklő kriptográfiai rétegen túlmenően ő a network részt is elemezte).

Hol is kezdjük a Bitcoin blokkok és tranzakciók kriptográfiai elemzését? Nézzük meg a felépítésüket! A blokkok fejrészből, lábrészből és az egyes tranzakciók leírásaiból állnak. A tranzakciók tartalmazzák a bejövő ("in") és kimenő ("out") adatokat, azaz kitől jött a pénz, és kinek megy tovább. Azok az "in" tranzakciók (blokkok első tranzakciója), amelyek nem egy megelőző tranzakcióra épülnek, hanem újonnan keletkeztek ("mining"), egy "coinbase" értéket tartalmaznak, míg a többinél az ECDSA aláírás értéke foglal helyet a "scriptSig" elemben. Az "out" tranzakciók tartalmazzák többek közt az átutalt összeget, illetve az átutalás címzettjét.

Általánosságban elmondható, hogy a tranzakciók, blokkok, Merkle-fák, címek leképzése során dupla hash-elést alkalmaz a Bitcoin rendszere, csak SHA-256 alapokon, vagy vegyesen használva az SHA-256 és RIPEMD-160 algoritmusokat. A byte-sorrendre azonban ügyelni kell, mert gyakran kell fordítani rajta!

A Bitcoin esetében a címzés a felhasználók ECDSA nyilvános kulcsa alapján adható meg több formában is: a "scriptPubKey" elemben a teljes kulcsból képzett lenyomat (OP_HASH160), illetve ezen lenyomat base58 kódolt változata (BASE58) is szerepelhet.

Ha minden paraméter a helyén van, akkor létre lehet hozni az adott tranzakció ECDSA aláírását, egy új "scriptSig" elemet.

A "scriptSig" létrehozása után a tranzakcióknak keretet adó blokk fejrészét is ki lehet tölteni, amelynek része egy Merkle-fa továbbépítése is (a blokk lábrészében).

Általánosságban ennyit lehet elmondani a folyamatról. Az alábbi képeken lehet nyomon követni részletesebben, hogy milyen bemenő adatok alapján milyen kimenetek születnek, és mi a pontos sorrendje ezen műveleteknek (ennél több információt a bejegyzés végén levő forráskód adhat).

Mind az első ("coinbase") tranzakciót tartalmazó blokknál, mind a többinél az új tranzakció lenyomatának kiszámolása után ezen új hash hozzáfűzésre kerül a Merkle-fa meglevő elemeihez, majd a Merkle-fa legfelső eleme beíródik a blokk fejrészébe. A fejrész módosított elemei alapján indul meg a keresés egy olyan nonce érték után, amivel sikerül a kitűzött szintű nehézségnek (pl. X db 0-val kezdődik) megfelelő lenyomatot megtalálni, amellyel visszaigazolásra ("confirmation") kerül az új tranzakció beszúrása a blokkba.

Azt már látjuk, hogy egy új tranzakció esetén hogy kell módosítani a blokkot, de hogy szerkesszük meg magát a tranzakciót? Ehhez össze kell gyűjteni a kiinduló tranzakció adatait, majd az átutalni kívánt összeget és annak címzettjét, mint kimeneti adatokat. Ezek alapján készül el a felhasználó titkos kulcsa segítségével az ECDSA aláírással ellátott tranzakció. Ezután kerülhet sor az új tranzakció lenyomatának kiszámolására, majd a blokkba való beszúrásra a fent említett módon.

A crypto currency megoldások száma, és néhány komolyabb rendszerben történt bevezetésük miatt (még ha egyébként nagyon megosztottak is a szakértők az elfogadhatósága kapcsán) úgy tűnik, hogy a témával érdemes foglalkozni. Az elmúlt év tapasztalatai viszont azt is megmutatták, hogy a protokoll szintjén (pl. "selfish mining strategy") és a háttérszolgáltatásoknál is (pl. Mt. Gox) komoly problémák vannak, amelyek miatt egyáltalán nem biztos, hogy a jelenleg legnépszerűbb Bitcoin lesz a befutó, sőt! Az alternatív coin-ok némelyike (pl. az 2012. augusztus 19-én indult Peercoin) nem véletlenül született meg, hiszen újításaik a Bitcoin eredeti működésének komoly hibáit orvosolják, hiányosságait pótolják. Az is látszik, hogy a teljes decentralizáltság, mint kiinduló feltétel sem biztos, hogy tartható: elég csak a Zerocoin pénzmosodáira ("laundry") gondolni, ahol meg kell bízni egy harmadik félben (ez nem is olyan egyszerű: vannak fórumok szép számmal, ahol a "fake laundry" témakörről van szó). Kérdés, hogy a folyamat pontosan mely részének decentralizáltsága fontos a felhasználók számára? A jegybanki funkciók közül a bankjegykiadás továbbra is maradhat független, a megfelelő lenyomatú coin-ok keresése és bevitele a rendszerbe nem tűnik annyira problémásnak, amíg a kriptográfiai szabályok, mint egyfajta "jegybank", mindenkire egyformán érvényesek. A tranzakciók felügyelete, jóváhagyása viszont olyan dolog, amit több támadás is érint, itt lehet, hogy egy megbízható harmadik fél bevonása maradhat az egyetlen értelmes megoldás (pl. "selfish mining strategy" és blokklánc hosszán alapuló döntés helyett kriptográfiai időbélyeg beszerzése és feldolgozása tranzakciónként, időbélyeg szolgáltatóktól, mint jogi értelemben is létező entitásoktól egy jó megoldás lehet). Mindezeken felül azt sem szabad elfelejtenünk, hogy a bankóriások is gondolkodnak a háttérben: a J. P. Morgan kapcsán már cikkeztek is saját, alternatív crypto currency bevezetéséről, igaz, egyelőre erről kevés részletes információ hozzáférhető...

Megjegyzés:
A számítások bemutatására gyártottam néhány függvényt ([13]), amikkel valódi blokkok, tranzakciók, ECDSA aláírások ellenőrizhetők. Az ECDSA aláírás-ellenőrzés alapját Matyas Danter (mdanter) PHPECC függvényei adják. A témában a PPKE-n elhangzott előadás anyagát is csatoltam ([14]), illetve elérhető Bura Pál PPKE-s önálló labor dolgozata is ([15]).

(Az iromány megszületéséhez igencsak hozzájárult Kőműves Balázs és Bura Pál fejtágító előadása, aminek megtartására a budapesti hackerspace műhely, a H.A.C.K. adott lehetőséget a Cryptonite rendezvénysorozat keretében stef, dnet és Buherátor jelentős közreműködésével. Köszönet érte!)

Kapcsolódó anyagok:
 vissza 
   
  info@kormanyablak.org
info@ugyfelkapu.info