Nykyään vain laiskot eivät ole kirjoittaneet lohkoketjuteknologiasta, kryptovaluutoista ja kuinka siistiä se on. Mutta tämä artikkeli ei ylistä tätä tekniikkaa; puhumme sen puutteista ja tavoista poistaa ne.
Kun työskentelimme yhdessä Altirix Systemsin projekteista, tehtävänä syntyi turvallinen, sensuurin kestävä tietojen vahvistus lohkoketjun ulkopuolisesta lähteestä. Kolmannen järjestelmän tietueiden muutokset piti vahvistaa ja näiden muutosten perusteella suorittaa yksi tai toinen haara älykkään sopimuslogiikassa. Tehtävä on ensi silmäyksellä varsin triviaali, mutta kun jonkin prosessiin osallistuvan osapuolen taloudellinen tilanne riippuu sen toteuttamisen tuloksesta, ilmaantuu lisävaatimuksia. Ensinnäkin tämä on kattavaa luottamusta tällaiseen validointimekanismiin. Mutta ensin asiat ensin.
Ongelmana on, että lohkoketju itsessään on itsenäinen, suljettu kokonaisuus, joten lohkoketjun sisällä olevat älykkäät sopimukset eivät tiedä mitään ulkomaailmasta. Samaan aikaan älysopimusten ehdot liittyvät usein tietoihin todellisista asioista (lennon viivästyminen, valuuttakurssit jne.). Jotta älykkäät sopimukset toimisivat kunnolla, lohkoketjun ulkopuolelta saatujen tietojen on oltava luotettavia ja tarkistettuja. Tämä ongelma ratkaistaan käyttämällä oraakkeleita, kuten Town Crier ja DECO. Nämä oraakkelit sallivat lohkoketjuverkon älykkään sopimuksen luottaa luotetulta verkkopalvelimelta tulevaan tietoon; voimme sanoa, että nämä ovat luotettavan tiedon tarjoajia.
Oraakkelit
Kuvittele, että älykäs sopimus siirtää 0.001 btc bitcoin-lompakkoosi, jos suosikkijalkapalloseurasi voittaa Venäjän Cupin. Todellisen voiton sattuessa älysopimuksen on siirrettävä tiedot siitä, mikä seura voitti, ja tässä syntyy useita ongelmia: mistä nämä tiedot saadaan, kuinka ne voidaan siirtää turvallisesti älysopimukseen ja miten varmistetaan, että tiedot Älykäs sopimus on voimassa todellakin todellisuuden kanssa?
Tietolähteen osalta voi olla kaksi skenaariota: älysopimuksen yhdistäminen luotettavaan verkkosivustoon, jolle tiedot ottelun tuloksista tallennetaan keskitetysti, ja toinen vaihtoehto on yhdistää useita sivustoja kerralla ja valita sitten tiedot useimmista lähteistä. jotka tarjoavat samat tiedot. Tietojen oikeellisuuden varmistamiseen käytetään oraakkeleita, esimerkiksi Oraclizea, joka käyttää TLSnotaria (TLS Notary Modification to Prove the Authenticity of Data). Mutta Googlessa on tarpeeksi tietoa Oraclizesta, ja Habresta on useita artikkeleita.. Tänään puhun oraakkeleista, jotka käyttävät hieman erilaista lähestymistapaa tiedon välittämiseen: Town Crier ja DECO. Artikkelissa on kuvaus molempien oraakkelien toimintaperiaatteista sekä yksityiskohtainen vertailu.
Kaupunki Crier
Town Crier (TC) esitteli IC3:n (The Initiative for Crypto Currencies and Contracts) vuonna 2016 CCS'16:ssa. TC:n pääidea: siirtää tiedot verkkosivustolta älykkääseen sopimukseen ja varmistaa, että TC:n toimittamat tiedot ovat samat kuin verkkosivustolla. TC käyttää TEE:tä (Trusted Execution Environment) tietojen omistajuuden todentamiseen. TC:n alkuperäinen versio kuvaa, kuinka Intel SGX:n kanssa työskentelee.
Town Crier koostuu osasta lohkoketjun sisällä ja osasta itse käyttöjärjestelmän sisällä - TC Server.
TC Contract on lohkoketjussa ja toimii TC:n etupäänä. Se hyväksyy pyynnöt CU:lta (user smart contract) ja palauttaa vastauksen TC-palvelimelta. TC-palvelimen sisällä on Relay, joka muodostaa yhteyden erillisalueen ja Internetiin (kaksisuuntainen liikenne) ja yhdistää erillisalueen lohkoketjuun. Enclave sisältää progencl, joka on koodi, joka tekee pyyntöjä lohkoketjusta ja palauttaa viestejä lohkoketjuun digitaalisella allekirjoituksella, progencl sisältää osan älykkään sopimuskoodista ja suorittaa olennaisesti osan sen toiminnoista.
Intel SGX -enklaavia voidaan pitää jaettuna kirjastona, jonka API toimii ecallin kautta. Ecall siirtää ohjauksen erillisalueelle. Enklaavi suorittaa koodiaan, kunnes se poistuu tai kunnes tapahtuu poikkeus. ocallilla kutsutaan enklaavin ulkopuolella määriteltyjä toimintoja. Ocall suoritetaan erillisalueen ulkopuolella ja se käsittelee sitä epäluotettavana kutsuna. Kun okall on suoritettu, ohjaus palautetaan erillisalueelle.
Enclave-osassa suojattu kanava konfiguroidaan verkkopalvelimen kanssa, erillisalue itse suorittaa TLS-kättelyn kohdepalvelimen kanssa ja suorittaa kaikki salaustoiminnot sisäisesti. TLS-kirjasto (mbedTLS) ja supistettu HTTP-koodi on viety SGX-ympäristöön. Enclave sisältää myös juuri CA -varmenteita (varmenteiden kokoelma) etäpalvelimien sertifikaattien tarkistamiseksi. Request Handler hyväksyy datagrammipyynnön Ethereumin tarjoamassa muodossa, purkaa sen salauksen ja jäsentää sen. Sitten se luo Ethereum-tapahtuman, joka sisältää pyydetyn datagrammin, allekirjoittaa sen skTC:llä ja lähettää sen Relaylle.
Relay-osa sisältää Client Interface, TCP, Blockchain Interface. Asiakasliittymää tarvitaan erillisalueen koodin varmentamiseen ja kommunikointiin asiakkaan kanssa. Asiakas lähettää todistuspyynnön ecallilla ja vastaanottaa skTC:n allekirjoittaman aikaleiman yhdessä att:n kanssa (todistusallekirjoitus), sitten att varmennetaan Intelin todistuspalvelulla (IAS) ja aikaleiman varmentaa luotettava aikapalvelu. Blockchain Interface tarkistaa saapuvat pyynnöt ja sijoittaa tapahtumat lohkoketjuun datagrammien toimittamista varten. Geth on virallinen Ethereum-asiakas ja antaa Relaylle mahdollisuuden olla vuorovaikutuksessa lohkoketjun kanssa RPC-kutsujen kautta.
Työskentely TEE:n kanssa TC mahdollistaa useiden erillisalueiden ajamisen rinnakkain, mikä lisää tiedonkäsittelyn nopeutta 3 kertaa. Jos yhdellä käynnissä olevalla erillisalueella nopeus oli 15 tx/sek, niin 20 rinnakkain ajettavalla erillisalueella nopeus kasvaa 65 tx/sek:iin, vertailun vuoksi Bitcoin-lohkoketjun suurin toimintanopeus on 26 tx/s.
DECO
CCS'20:ssa esiteltiin DECO (Decentralized Oracles for TLS), joka toimii TLS-yhteyksiä tukevien sivustojen kanssa. Varmistaa tietojen luottamuksellisuuden ja eheyden.
DECO ja TLS käyttää symmetristä salausta, joten asiakkaalla ja verkkopalvelimella on salausavaimet ja asiakas voi halutessaan väärentää TLS-istuntotietoja. Tämän ongelman ratkaisemiseksi DECO käyttää kolmisuuntaista kättelyprotokollaa todistajan (älykäs sopimus), todentajan (Oracle) ja verkkopalvelimen (tietolähde) välillä.
DECO toimii siten, että todentaja vastaanottaa datan D ja vahvistaa todentajalle, että D tuli TLS-palvelimelta S. Toinen ongelma on, että TLS ei allekirjoita tietoja ja TLS-asiakkaan on vaikea todistaa, että tiedot saatiin täsmälleen oikealta palvelimelta (alkuperä vaikeus).
DECO-protokolla käyttää KEnc- ja KMac-salausavaimia. Asiakas lähettää pyynnön Q verkkopalvelimelle, vastaus palvelimelta R tulee salatussa muodossa, mutta asiakas ja palvelin omistavat saman KMacin ja asiakas voi väärentää TLS-sanoman. DECOn ratkaisu on "piilottaa" KMac asiakkaalta (todistaja), kunnes se vastaa pyyntöön. Nyt KMac on jaettu todistajan ja todentajan kesken - KpMac ja KvMac. Palvelin vastaanottaa KMacin salaamaan vastauksen avainosatoiminnolla KpMac ⊕ KvMac = KMac.
Kolmisuuntaisen kättelyn avulla tiedonvaihto asiakkaan ja palvelimen välillä toteutetaan turvallisuuden takaamiseksi.
Hajautetusta oraakkelijärjestelmästä puhuttaessa ei voi olla mainitsematta Chainlinkiä, jonka tavoitteena on luoda hajautettu verkosto oraakkelisolmuista, jotka ovat yhteensopivia Ethereumin, Bitcoinin ja Hyperledgerin kanssa ottaen huomioon modulaarisuuden: järjestelmän jokainen osa voidaan päivittää. Samaan aikaan turvallisuuden takaamiseksi Chainlink tarjoaa jokaiselle tehtävään osallistuvalle oraakkelille yhdistelmän avaimista (julkinen ja yksityinen). Yksityistä avainta käytetään osittaisen allekirjoituksen luomiseen, joka sisältää heidän päätöksensä tietopyyntöön. Vastauksen saamiseksi on tarpeen yhdistää kaikki verkon oraakkelien osittaiset allekirjoitukset.
Chainlink aikoo toteuttaa ensimmäisen PoC DECOn keskittyen hajautettuihin rahoitussovelluksiin, kuten Mixiclesiin. Kirjoitushetkellä Forbesissa julkaistiin uutinen, että Chainlink osti DECOn Cornellin yliopistosta.
Hyökkäykset oraakkeleihin
Tietoturvallisuuden näkökulmasta katsottiin seuraavat hyökkäykset Town Crieriin:
-
Rogue smart-contact-koodin injektio TEE-solmuihin.
Hyökkäyksen ydin: tietoisesti virheellisen älysopimuksen koodin lähettäminen TEE:lle, jolloin solmulle pääsyn saanut hyökkääjä pystyy toteuttamaan oman (vilpillisen) älysopimuksensa salauksen puretuille tiedoille. Palautusarvot kuitenkin salataan yksityisellä avaimella, ja ainoa tapa päästä tällaisiin tietoihin on vuotaa salateksti palautuksen/tulostuksen yhteydessä.
Suojaus tätä hyökkäystä vastaan koostuu erillisalueesta, joka tarkistaa nykyisessä osoitteessa sijaitsevan koodin oikeellisuuden. Tämä voidaan saavuttaa käyttämällä osoitejärjestelmää, jossa sopimusosoite määritetään tiivistämällä sopimuskoodi. -
Sopimustilan salateksti muuttuu vuotaa.
Hyökkäyksen ydin: Solmujen, joissa älykkäitä sopimuksia toteutetaan, omistajilla on pääsy sopimustilaan salatussa muodossa erillisalueen ulkopuolella. Solmun hallintaansa saanut hyökkääjä voi verrata kontaktitilaa ennen tapahtumaa ja sen jälkeen sekä määrittää, mitkä argumentit syötettiin ja mitä älykkään sopimusmenetelmää käytettiin, koska itse älykäs sopimuskoodi ja sen tekniset tiedot ovat julkisesti saatavilla.
Suojaus itse solmun luotettavuuden varmistamisessa. -
Sivukanavahyökkäykset.
Erityinen hyökkäystyyppi, joka käyttää erillisen muistin ja välimuistin käytön valvontaa eri tilanteissa. Esimerkki tällaisesta hyökkäyksestä on Prime and Probe.
Hyökkäysjärjestys:- t0: Hyökkääjä täyttää uhriprosessin koko tietovälimuistin.
- t1: Uhri suorittaa koodin muistiin pääsyillä, jotka riippuvat uhrin arkaluontoisista tiedoista (salausavaimet). Välimuistirivi valitaan näppäinbitin arvon perusteella. Kuvan esimerkissä näppäinbitti = 0 ja välimuistirivillä 2 oleva osoite X. X:ään tallennetut tiedot ladataan välimuistiin syrjäyttäen siellä aiemmin olleet tiedot.
- t2: Hyökkääjä tarkistaa, mitkä hänen välimuistiriveistään on häädetty – uhrin käyttämät rivit. Tämä tehdään mittaamalla pääsyaika. Toistamalla tämän toiminnon jokaiselle avainbitille, hyökkääjä saa koko avaimen.
Hyökkäyssuojaus: Intel SGX:ssä on suojaus sivukanavahyökkäyksiä vastaan, mikä estää välimuistiin liittyvien tapahtumien valvonnan, mutta Prime- ja Probe-hyökkäys toimii silti, koska hyökkääjä tarkkailee prosessinsa välimuistitapahtumia ja jakaa välimuistin uhrin kanssa.
Tällä hetkellä ei siis ole luotettavaa suojaa tätä hyökkäystä vastaan.
Hyökkäykset, kuten Spectre ja Foreshadow (L1TF), jotka ovat samanlaisia kuin Prime ja Probe, ovat myös tunnettuja. Niiden avulla voit lukea tietoja välimuistista kolmannen osapuolen kanavan kautta. Tarjolla on suojaus Spectre-v2-haavoittuvuutta vastaan, mikä toimii kahta näistä hyökkäyksistä vastaan.
Kolmisuuntainen kättely takaa DECOn turvallisuuden:
- Todistajan eheys: Hakkeroitu testaaja ei voi väärentää palvelimen alkuperätietoja eikä saada palvelinta hyväksymään virheellisiä pyyntöjä tai vastaamaan virheellisesti kelvollisiin pyyntöihin. Tämä tehdään palvelimen ja testaajan välisten pyyntömallien avulla.
- Todentajan eheys: Hakkeroitu todentaja ei voi saada todistajaa saamaan vääriä vastauksia.
- Yksityisyys: Hakkeroitu todentaja tutkii vain julkisia tietoja (pyyntö, palvelimen nimi).
DECOssa vain liikenteen lisäämisen haavoittuvuudet ovat mahdollisia. Ensinnäkin, kolmisuuntaisella kättelyllä todentaja voi määrittää palvelimen identiteetin käyttämällä uutta noncea. Kättelyn jälkeen todentajan on kuitenkin turvauduttava verkkokerroksen ilmaisimiin (IP-osoitteisiin). Näin ollen varmentajan ja palvelimen välinen viestintä on suojattava liikenteen lisäämiseltä. Tämä saavutetaan käyttämällä välityspalvelinta.
Oraakkelien vertailu
Town Crier perustuu työskentelyyn palvelinosan erillisen kanssa, kun taas DECO mahdollistaa tietojen alkuperän aitouden tarkistamisen käyttämällä kolmisuuntaista kättelyä ja tietojen salausta kryptografisilla avaimilla. Näiden oraakkelien vertailu suoritettiin seuraavien kriteerien mukaan: suorituskyky, turvallisuus, hinta ja käytännöllisyys.
Kaupunki Crier
DECO
esitys
Nopeampi (0.6 s loppuun)
Hitaampi (10.50 sekuntia protokollan loppuun saattamiseksi)
turvallisuus
Vähemmän turvallinen
Turvallisempi
maksaa
Kalliimpi
Halvempi
käytännöllisyys
Vaatii erikoislaitteiston
Toimii minkä tahansa palvelimen kanssa, joka tukee TLS:ää
nopeus: DECOn kanssa työskentelyyn tarvitaan kolmisuuntainen kättely, LAN:in kautta määritettäessä se kestää 0.37 sekuntia, vuorovaikutukseen yhteyden muodostamisen jälkeen on tehokas 2PC-HMAC (0,13 s per kirjoitus). DECOn suorituskyky riippuu käytettävissä olevista TLS-salaussarjoista, yksityisten tietojen koosta ja todisteiden monimutkaisuudesta tietylle sovellukselle. Esimerkkinä IC3:n binäärioptiosovelluksen käyttö: protokollan suorittaminen LAN:n kautta kestää noin 10,50 sekuntia. Vertailun vuoksi, Town Crier kestää noin 0,6 sekuntia suorittaakseen samanlaisen sovelluksen, mikä on noin 20 kertaa nopeampi kuin DECO. Jos kaikki asiat ovat samat, TC on nopeampi.
Безопасность: Hyökkäykset Intel SGX -enklaaviin (sivukanavahyökkäykset) toimivat ja voivat aiheuttaa todellista vahinkoa älykkään sopimuksen osapuolille. DECOn osalta liikenneruiskutukseen liittyvät hyökkäykset ovat mahdollisia, mutta välityspalvelimen käyttö vähentää tällaiset hyökkäykset tyhjäksi. Siksi DECO on turvallisempi.
Maksaa: Intel SGX:tä tukevien laitteiden hinta on korkeampi kuin protokollan määrittäminen DECOssa. Siksi TC on kalliimpi.
käytännöllisyys: Town Crierin kanssa työskentelyyn tarvitaan TEE:tä tukevat erikoislaitteet. Esimerkiksi Intel SGX:ää tuetaan kuudennen sukupolven Intel Core -suoritinperheessä ja uudemmissa. DECO mahdollistaa työskentelyn minkä tahansa laitteen kanssa, vaikka DECO-asetus on olemassa TEE:tä käyttämällä. Asennusprosessin mukaan DECOn kolmisuuntainen kättely voi kestää jonkin aikaa, mutta tämä ei ole mitään verrattuna TC:n laitteistorajoituksiin, joten DECO on käytännöllisempi.
Johtopäätös
Kun tarkastellaan kahta oraakkelia erikseen ja vertaamalla niitä neljällä kriteerillä, on selvää, että Town Crier on huonompi kuin DECO kolmella neljästä pisteestä. DECO on tietoturvallisuuden näkökulmasta luotettavampi, halvempi ja käytännöllisempi, vaikka kolmiosapuolen protokollan käyttöönotto voi viedä jonkin aikaa ja siinä on haittapuolensa, esimerkiksi lisätoiminnot salausavaimilla. TC on nopeampi kuin DECO, mutta sivukanavan hyökkäyksen haavoittuvuudet tekevät siitä alttiin luottamuksellisuuden menettämiselle. On otettava huomioon, että DECO otettiin käyttöön tammikuussa 2020, eikä aikaa ole kulunut tarpeeksi sen pitämiseksi turvallisena. Town Crier on ollut hyökkäyksen kohteena 4 vuotta ja se on käynyt läpi monia testejä, joten sen käyttö monissa projekteissa on perusteltua.
Lähde: will.com