Šodien tikai slinkie nav rakstījuši par blokķēdes tehnoloģiju, kriptovalūtām un to, cik tas ir forši. Bet šajā rakstā šī tehnoloģija netiks slavēta, mēs runāsim par tās trūkumiem un veidiem, kā tos novērst.

Strādājot pie viena no Altirix Systems projektiem, radās uzdevums nodrošināt drošu, pret cenzūru izturīgu datu apstiprināšanu no avota, kas nav blokķēde. Bija nepieciešams apstiprināt izmaiņas trešās sistēmas ierakstos un, pamatojoties uz šīm izmaiņām, viedā līguma loģikā izpildīt vienu vai otru atzaru. Uzdevums no pirmā acu uzmetiena ir diezgan triviāls, bet, kad vienas procesā iesaistītās puses finansiālais stāvoklis ir atkarīgs no tā izpildes rezultāta, parādās papildu prasības. Pirmkārt, tā ir visaptveroša uzticēšanās šādam apstiprināšanas mehānismam. Bet vispirms vispirms.

Problēma ir tāda, ka pati blokķēde ir autonoma, slēgta vienība, tāpēc viedie līgumi blokķēdē neko nezina par ārpasauli. Tajā pašā laikā viedo līgumu nosacījumi bieži ir saistīti ar informāciju par reālām lietām (lidojuma kavēšanās, valūtas kursi utt.). Lai viedie līgumi darbotos pareizi, informācijai, kas saņemta ārpus blokķēdes, jābūt uzticamai un pārbaudītai. Šī problēma tiek atrisināta, izmantojot tādus orākulus kā Town Crier un DECO. Šie orākuli ļauj viedajam līgumam blokķēdes tīklā uzticēties informācijai no uzticama tīmekļa servera; mēs varam teikt, ka tie ir uzticamas informācijas sniedzēji.

Orākuli

Iedomājieties, ka gudrs līgums pārskaita 0.001 btc uz jūsu bitcoin maku, ja jūsu iecienītākais futbola klubs uzvar Krievijas kausa izcīņā. Reālas uzvaras gadījumā viedajam līgumam ir jāpārsūta informācija par to, kurš klubs uzvarēja, un šeit rodas vairākas problēmas: kur iegūt šo informāciju, kā to droši pārnest uz viedo līgumu un kā nodrošināt, ka informācija viedajā līgumā saņemtais ir spēkā tiešām sakrīt ar realitāti?

Runājot par informācijas avotu, var būt divi scenāriji: viedā līguma pievienošana uzticamai vietnei, kurā tiek centralizēti glabāta informācija par spēļu rezultātiem, un otrā iespēja ir savienot vairākas vietnes vienlaikus un pēc tam atlasīt informāciju no vairuma avotu. kas sniedz tos pašus datus. Lai pārbaudītu informācijas pareizību, tiek izmantoti orākuli, piemēram, Oraclize, kas izmanto TLSNotary (TLS Notary Modification to Prove the Authenticity of Data). Bet Google ir pietiekami daudz informācijas par Oraclize, un ir vairāki raksti par Habré.Šodien es runāšu par orākuliem, kas izmanto nedaudz atšķirīgu pieeju informācijas pārraidei: Town Crier un DECO. Rakstā sniegts abu orākulu darbības principu apraksts, kā arī detalizēts salīdzinājums.

Town Crier

Town Crier (TC) tika ieviests ar IC3 (The Initiative for Crypto Currencies and Contracts) 2016. gadā CCS'16. TC galvenā ideja: pārsūtīt informāciju no vietnes uz viedo līgumu un pārliecināties, ka TC sniegtā informācija ir tāda pati kā vietnē. TC izmanto TEE (Trusted Execution Environment), lai autentificētu datu īpašumtiesības. Sākotnējā TC versijā ir aprakstīts, kā strādāt ar Intel SGX.
Town Crier sastāv no daļas blokķēdē un daļas pašā OS - TC Server.

TC līgums ir blokķēdē un darbojas kā TC priekšgals. Tas pieņem pieprasījumus no CU (lietotāja viedais līgums) un atgriež atbildi no TC servera. TC servera iekšpusē ir relejs, kas izveido savienojumu starp anklāvu un internetu (divvirzienu trafika) un savieno anklāvu ar blokķēdi. Enclave satur progencl, kas ir kods, kas veic pieprasījumus no blokķēdes un atdod ziņojumus blokķēdei ar ciparparakstu, progencl satur daļu no viedā līguma koda un būtībā veic dažas no tā funkcijām.

Intel SGX anklāvu var uzskatīt par koplietojamu bibliotēku ar API, kas darbojas, izmantojot ecall. Ecall nodod kontroli anklāvam. Anklāvs izpilda savu kodu, līdz tas iziet vai līdz notiek izņēmums. ocal izmanto, lai izsauktu funkcijas, kas definētas ārpus anklāva. Ocall tiek izpildīts ārpus anklāva, un tas tiek uzskatīts par neuzticamu zvanu. Pēc ocal izpildes vadība tiek atgriezta anklāvā.

Enklāva daļā drošs kanāls ir konfigurēts ar tīmekļa serveri, pats anklāvs veic TLS rokasspiedienu ar mērķa serveri un veic visas kriptogrāfijas darbības iekšēji. TLS bibliotēka (mbedTLS) un samazināts HTTP kods ir eksportēti uz SGX vidi. Turklāt Enclave ir saknes CA sertifikāti (sertifikātu kolekcija), lai pārbaudītu attālo serveru sertifikātus. Pieprasījumu apstrādātājs pieņem datagrammas pieprasījumu Ethereum nodrošinātajā formātā, atšifrē to un parsē. Pēc tam tas ģenerē Ethereum transakciju, kas satur pieprasīto datagrammu, paraksta to ar skTC un pārsūta uz Relay.

Releja daļa ietver klienta interfeisu, TCP, blokķēdes interfeisu. Klienta saskarne ir nepieciešama, lai sertificētu anklāva kodu un sazinātos ar klientu. Klients nosūta atestācijas pieprasījumu, izmantojot ecall, un saņem skTC parakstītu laikspiedolu kopā ar att (atestācijas parakstu), pēc tam att tiek pārbaudīts, izmantojot Intel atestācijas pakalpojumu (IAS), un laikspiedolu pārbauda uzticama laika pakalpojums. Blockchain interfeiss pārbauda ienākošos pieprasījumus un ievieto darījumus blokķēdē, lai piegādātu datagrammas. Geth ir oficiālais Ethereum klients un ļauj Relay mijiedarboties ar blokķēdi, izmantojot RPC zvanus.

Darbs ar TEE, TC ļauj paralēli vadīt vairākus anklāvus, tādējādi palielinot informācijas apstrādes ātrumu 3 reizes. Ja ar vienu skriešanas anklāvu ātrums bija 15 tx/sek, tad ar 20 paralēli darbojošiem anklāviem ātrums palielinās līdz 65 tx/sek, salīdzinājumam maksimālais darbības ātrums Bitcoin blokķēdē ir 26 tx/sek.

DECO

DECO (Decentralized Oracle for TLS) tika prezentēts CCS'20, darbojas ar vietnēm, kas atbalsta TLS savienojumus. Nodrošina datu konfidencialitāti un integritāti.
DECO ar TLS izmanto simetrisku šifrēšanu, tāpēc klientam un tīmekļa serverim ir šifrēšanas atslēgas, un klients var viltot TLS sesijas datus, ja vēlas. Lai atrisinātu šo problēmu, DECO izmanto trīsvirzienu rokasspiediena protokolu starp pārbaudītāju (viedais līgums), pārbaudītāju (Oracle) un tīmekļa serveri (datu avots).

DECO darbības veids ir tāds, ka verificētājs saņem datu daļu D un apstiprina verificētājam, ka D ir nācis no TLS servera S. Vēl viena problēma ir tā, ka TLS neparaksta datus un TLS klientam ir grūti pierādīt, ka dati tika saņemti tieši no īstā servera (izcelsmes grūtības).

DECO protokols izmanto šifrēšanas atslēgas KEnc un KMac. Klients nosūta pieprasījumu Q uz tīmekļa serverisAtbilde no servera R pienāk šifrēta, taču klientam un serverim ir viens un tas pats KMac, un klients var viltot TLS ziņojumu. DECO risinājums ir "paslēpt" KMac no klienta (pārbaudītāja), līdz tas atbild uz pieprasījumu. Tagad KMac ir sadalīts starp pārbaudītāju un verificētāju — KpMac un KvMac. Serveris iegūst KMac, lai šifrētu atbildi, izmantojot atslēgu sadalīšanas darbību KpMac ⊕ KvMac = KMac.

Iestatot trīsvirzienu rokasspiedienu, datu apmaiņa starp klientu un serveri tiks veikta ar drošības garantiju.

Runājot par decentralizētu orākula sistēmu, nevar nepieminēt Chainlink, kuras mērķis ir izveidot decentralizētu orākula mezglu tīklu, kas ir savietojams ar Ethereum, Bitcoin un Hyperledger, ņemot vērā modularitāti: katru sistēmas daļu var atjaunināt. Tajā pašā laikā, lai nodrošinātu drošību, Chainlink piedāvā katram orākulam, kas piedalās uzdevumā, izsniegt atslēgu kombināciju (publisko un privāto). Privātā atslēga tiek izmantota, lai ģenerētu daļēju parakstu, kas satur viņu lēmumu par datu pieprasījumu. Lai iegūtu atbildi, ir jāapvieno visi tīkla orākulu daļējie paraksti.

Chainlink plāno veikt sākotnējo PoC DECO, koncentrējoties uz decentralizētām finanšu lietojumprogrammām, piemēram, Mixicles. Rakstīšanas laikā Forbes parādījās ziņas, ka Chainlink iegādājās DECO no Kornela universitātes.

Uzbrukumi orākuliem

No informācijas drošības viedokļa tika apsvērti šādi uzbrukumi Town Crier:

1. Negodīga viedkontakta koda ievadīšana TEE mezglos.
   Uzbrukuma būtība: apzināti nepareiza viedlīguma koda pārsūtīšana uz TEE, tādējādi uzbrucējs, kurš ieguvis piekļuvi mezglam, uz atšifrētajiem datiem varēs izpildīt savu (krāpniecisko) viedo līgumu. Tomēr atgriešanas vērtības tiks šifrētas ar privāto atslēgu, un vienīgais veids, kā piekļūt šādiem datiem, ir šifrētā teksta noplūde atgriešanas/izvades laikā.
   Aizsardzība pret šo uzbrukumu sastāv no tā, ka anklāvs pārbauda pašreizējā adresē esošā koda pareizību. To var panākt, izmantojot adresācijas shēmu, kurā līguma adrese tiek noteikta, sajaucot līguma kodu.

2. Līguma stāvokļa šifrētā teksta izmaiņu noplūde.
   Uzbrukuma būtība: mezglu īpašniekiem, kuros tiek noslēgti viedie līgumi, ir piekļuve līguma stāvoklim šifrētā veidā ārpus anklāva. Uzbrucējs, ieguvis vadību pār mezglu, var salīdzināt kontakta stāvokli pirms un pēc darījuma un noteikt, kuri argumenti tika ievadīti un kura viedā līguma metode tika izmantota, jo pats viedā līguma kods un tā tehniskās specifikācijas ir publiski pieejamas.
   Aizsardzība, nodrošinot paša mezgla uzticamību.

3. Sānu kanālu uzbrukumi.
   Īpašs uzbrukuma veids, kas izmanto anklāva atmiņas un kešatmiņas piekļuves uzraudzību dažādos scenārijos. Šāda uzbrukuma piemērs ir Prime un Probe.
   
   Uzbrukuma secība:

   • t0: uzbrucējs aizpilda visu upura procesa datu kešatmiņu.
   • t1: upuris izpilda kodu ar piekļūšanu atmiņai, kas ir atkarīga no upura sensitīvajiem datiem (kriptogrāfiskajām atslēgām). Kešatmiņas rinda tiek atlasīta, pamatojoties uz tastatūras bitu vērtību. Attēlā redzamajā piemērā keybit = 0 un tiek nolasīta adrese X kešatmiņas rindā 2. X saglabātie dati tiek ielādēti kešatmiņā, izspiežot datus, kas tur bija iepriekš.
   • t2: uzbrucējs pārbauda, ​​kuras no viņa kešatmiņas rindām ir izliktas — upura izmantotās līnijas. Tas tiek darīts, mērot piekļuves laiku. Atkārtojot šo darbību katram tastatūras bitam, uzbrucējs iegūst visu atslēgu.

Uzbrukuma aizsardzība: Intel SGX ir aizsardzība pret sānu kanālu uzbrukumiem, kas novērš ar kešatmiņu saistītu notikumu uzraudzību, taču Prime un Probe uzbrukums joprojām darbosies, jo uzbrucējs uzrauga sava procesa kešatmiņas notikumus un koplieto kešatmiņu ar upuri.

Tādējādi šobrīd nav drošas aizsardzības pret šo uzbrukumu.

Ir zināmi arī tādi uzbrukumi kā Spectre un Foreshadow (L1TF), līdzīgi kā Prime un Probe. Tie ļauj nolasīt datus no kešatmiņas, izmantojot trešās puses kanālu. Tiek nodrošināta aizsardzība pret Spectre-v2 ievainojamību, kas darbojas pret diviem no šiem uzbrukumiem.

Saistībā ar DECO trīsvirzienu rokasspiediens nodrošina drošības garantiju:

1. Pārbaudītāja integritāte: uzlauzts pārbaudītājs nevar viltot servera izcelsmes informāciju un nevar likt serverim pieņemt nederīgus pieprasījumus vai nepareizi atbildēt uz derīgiem pieprasījumiem. Tas tiek darīts, izmantojot pieprasījumu modeļus starp serveri un pārbaudītāju.
2. Verificētāja integritāte: uzlauzts pārbaudītājs nevar likt pārbaudītājam saņemt nepareizas atbildes.
3. Konfidencialitāte: uzlauztais verificētājs pārbauda tikai publisko informāciju (pieprasījumu, servera nosaukumu).

DECO ir iespējamas tikai datplūsmas ievades ievainojamības. Sākotnēji trīspusējas rokasspiediena laikā verificētājs var noteikt servera identitāti, izmantojot jaunu nonsu. Tomēr pēc rokasspiediena verificētājam jāpaļaujas uz tīkla slāņa indikatoriem (IP adreses). Tāpēc savienojumam starp verificētāju un serveri jābūt aizsargātam no datplūsmas ievadīšanas. Tas tiek panākts, izmantojot starpniekserveri.

Orākulu salīdzinājums

Town Crier pamatā ir darbs ar anklāvu servera daļā, savukārt DECO ļauj pārbaudīt datu izcelsmes autentiskumu, izmantojot trīsvirzienu rokasspiedienu un datu šifrēšanu ar kriptogrāfiskajām atslēgām. Šo orākulu salīdzinājums tika veikts pēc šādiem kritērijiem: veiktspēja, drošība, izmaksas un praktiskums.

Town Crier
DECO

sniegumu
Ātrāk (0.6 s līdz beigām)
Lēnāk (10.50 s, lai pabeigtu protokolu)

drošība
Mazāk drošs
Drošāka

izmaksāt
Dārgāks
Lētāk

praktiskums
Nepieciešama īpaša aparatūra
Darbojas ar jebkuru serveri, kas atbalsta TLS

Performance: Lai strādātu ar DECO, ir nepieciešams trīsvirzienu rokasspiediens, iestatot caur LAN, tas aizņem 0.37 sekundes, mijiedarbībai pēc savienojuma izveidošanas ir efektīvs 2PC-HMAC (0,13 s uz vienu ierakstu). DECO veiktspēja ir atkarīga no pieejamajiem TLS šifru komplektiem, privāto datu lieluma un pierādījumu sarežģītības konkrētai lietojumprogrammai. Kā piemēru izmantojot bināro opciju lietojumprogrammu no IC3: protokola pabeigšana, izmantojot LAN, aizņem apmēram 10,50 sekundes. Salīdzinājumam, Town Crier prasa aptuveni 0,6 sekundes, lai pabeigtu līdzīgu lietojumprogrammu, kas ir aptuveni 20 reizes ātrāk nekā DECO. Ja viss ir vienāds, TC būs ātrāks.

Drošība: Uzbrukumi Intel SGX anklāvam (sānu kanālu uzbrukumi) darbojas un var radīt reālus bojājumus viedā līguma dalībniekiem. Attiecībā uz DECO ir iespējami uzbrukumi, kas saistīti ar satiksmes iepludināšanu, taču starpniekservera izmantošana šādus uzbrukumus samazina līdz neko. Tāpēc DECO ir drošāks.

Izmaksāt: Intel SGX atbalsta aprīkojuma izmaksas ir augstākas nekā DECO protokola iestatīšanas izmaksas. Tāpēc TC ir dārgāks.

Praktiskums: Lai strādātu ar Town Crier, ir nepieciešams īpašs aprīkojums, kas atbalsta TEE. Piemēram, Intel SGX tiek atbalstīts 6. paaudzes Intel Core procesoru saimē un jaunākās versijās. DECO ļauj strādāt ar jebkuru aprīkojumu, lai gan ir DECO iestatījums, izmantojot TEE. Saskaņā ar iestatīšanas procesu DECO trīsvirzienu rokasspiediens var aizņemt kādu laiku, taču tas nav nekas, salīdzinot ar TC aparatūras ierobežojumiem, tāpēc DECO ir praktiskāka.

Secinājums

Aplūkojot divus orākulus atsevišķi un salīdzinot tos pēc četriem kritērijiem, ir skaidrs, ka Town Crier ir zemāks par DECO trīs no četriem punktiem. DECO no informācijas drošības viedokļa ir uzticamāks, lētāks un praktiskāks, lai gan trīspusēju protokola iestatīšana var aizņemt kādu laiku un tai ir savi trūkumi, piemēram, papildu darbības ar šifrēšanas atslēgām. TC ir ātrāks par DECO, taču sānu kanālu uzbrukuma ievainojamības padara to jutīgu pret konfidencialitātes zaudēšanu. Jāņem vērā, ka DECO tika ieviests 2020. gada janvārī, un nav pagājis pietiekami daudz laika, lai to uzskatītu par drošu. Town Crier ir uzbrukts 4 gadus un ir izgājis daudzus testus, tāpēc tā izmantošana daudzos projektos ir pamatota.

Avots: www.habr.com