ໃນມື້ນີ້, ມີພຽງແຕ່ຄົນຂີ້ຄ້ານທີ່ບໍ່ໄດ້ຂຽນກ່ຽວກັບເທກໂນໂລຍີ blockchain, cryptocurrencies ແລະວິທີການເຢັນ. ແຕ່ບົດຄວາມນີ້ຈະບໍ່ສັນລະເສີນເຕັກໂນໂລຢີນີ້;

ໃນຂະນະທີ່ເຮັດວຽກຢູ່ໃນໂຄງການຫນຶ່ງທີ່ Altirix Systems, ວຽກງານດັ່ງກ່າວໄດ້ເກີດຂື້ນກັບການຢືນຢັນທີ່ປອດໄພ, ທົນທານຕໍ່ censorship ຂອງຂໍ້ມູນຈາກແຫຼ່ງພາຍນອກກັບ blockchain. ມັນເປັນສິ່ງຈໍາເປັນເພື່ອຢືນຢັນການປ່ຽນແປງໃນບັນທຶກຂອງລະບົບທີສາມແລະ, ອີງຕາມການປ່ຽນແປງເຫຼົ່ານີ້, ດໍາເນີນການຫນຶ່ງຫຼືສາຂາອື່ນໃນເຫດຜົນສັນຍາສະຫມາດ. ວຽກງານຢູ່ glance ທໍາອິດແມ່ນຂ້ອນຂ້າງ trivial, ແຕ່ໃນເວລາທີ່ສະພາບທາງດ້ານການເງິນຂອງຫນຶ່ງໃນພາກສ່ວນທີ່ເຂົ້າຮ່ວມຂະບວນການແມ່ນຂຶ້ນກັບຜົນຂອງການປະຕິບັດຂອງຕົນ, ຄວາມຕ້ອງການເພີ່ມເຕີມປະກົດວ່າ. ກ່ອນ​ອື່ນ​ຫມົດ, ນີ້​ແມ່ນ​ຄວາມ​ໄວ້​ວາງ​ໃຈ​ທີ່​ສົມ​ບູນ​ແບບ​ໃນ​ກົນ​ໄກ​ການ​ຢັ້ງ​ຢືນ​ດັ່ງ​ກ່າວ. ແຕ່ສິ່ງທໍາອິດທໍາອິດ.

ບັນຫາແມ່ນວ່າ blockchain ຕົວຂອງມັນເອງເປັນເອກະລາດ, ຫນ່ວຍງານປິດ, ດັ່ງນັ້ນສັນຍາສະຫລາດພາຍໃນ blockchain ບໍ່ຮູ້ຫຍັງກ່ຽວກັບໂລກພາຍນອກ. ໃນເວລາດຽວກັນ, ຂໍ້ກໍານົດຂອງສັນຍາສະຫມາດແມ່ນມັກຈະກ່ຽວຂ້ອງກັບຂໍ້ມູນກ່ຽວກັບສິ່ງທີ່ແທ້ຈິງ (ການຊັກຊ້າຂອງການບິນ, ອັດຕາແລກປ່ຽນ, ແລະອື່ນໆ). ສໍາລັບສັນຍາສະຫມາດທີ່ຈະເຮັດວຽກຢ່າງຖືກຕ້ອງ, ຂໍ້ມູນທີ່ໄດ້ຮັບຈາກພາຍນອກ blockchain ຕ້ອງມີຄວາມຫນ້າເຊື່ອຖືແລະຖືກກວດສອບ. ບັນຫານີ້ຖືກແກ້ໄຂໂດຍໃຊ້ oracles ເຊັ່ນ Town Crier ແລະ DECO. oracles ເຫຼົ່ານີ້ອະນຸຍາດໃຫ້ສັນຍາສະຫມາດໃນເຄືອຂ່າຍ blockchain ໄວ້ວາງໃຈຂໍ້ມູນຈາກເຄື່ອງແມ່ຂ່າຍເວັບທີ່ເຊື່ອຖືໄດ້;

Oracles

ຈິນຕະນາການວ່າສັນຍາສະຫມາດໂອນ 0.001 btc ກັບກະເປົາເງິນ bitcoin ຂອງທ່ານຖ້າສະໂມສອນບານເຕະທີ່ທ່ານມັກຊະນະເຕະບານລັດເຊຍ. ໃນກໍລະນີຂອງໄຊຊະນະທີ່ແທ້ຈິງ, ສັນຍາສະຫມາດຕ້ອງການໂອນຂໍ້ມູນກ່ຽວກັບສະໂມສອນໃດຊະນະ, ແລະບັນຫາຈໍານວນຫນຶ່ງເກີດຂື້ນຢູ່ທີ່ນີ້: ບ່ອນທີ່ໄດ້ຮັບຂໍ້ມູນນີ້, ວິທີການໂອນຢ່າງປອດໄພກັບສັນຍາສະຫມາດແລະວິທີການຮັບປະກັນວ່າຂໍ້ມູນ. ໄດ້ຮັບໃນສັນຍາສະຫມາດແມ່ນຖືກຕ້ອງຕົວຈິງ coincides ກັບຄວາມເປັນຈິງ?

ເມື່ອເວົ້າເຖິງແຫຼ່ງຂໍ້ມູນ, ມັນສາມາດມີ 2 ສະຖານະການ: ການເຊື່ອມຕໍ່ສັນຍາສະຫມາດກັບເວັບໄຊທ໌ທີ່ເຊື່ອຖືໄດ້ທີ່ຂໍ້ມູນກ່ຽວກັບຜົນໄດ້ຮັບຂອງການແຂ່ງຂັນຖືກເກັບໄວ້ໃນສູນກາງ, ແລະທາງເລືອກທີສອງແມ່ນການເຊື່ອມຕໍ່ຫຼາຍໆສະຖານທີ່ໃນເວລາດຽວກັນແລະຫຼັງຈາກນັ້ນເລືອກເອົາຂໍ້ມູນຈາກແຫຼ່ງສ່ວນໃຫຍ່. ທີ່ສະຫນອງຂໍ້ມູນດຽວກັນ. ເພື່ອກວດສອບຄວາມຖືກຕ້ອງຂອງຂໍ້ມູນ, oracles ຖືກນໍາໃຊ້, ຕົວຢ່າງ Oraclize, ເຊິ່ງໃຊ້ TLSNotary (TLS Notary Modification ເພື່ອພິສູດຄວາມຖືກຕ້ອງຂອງຂໍ້ມູນ). ແຕ່ມີຂໍ້ມູນພຽງພໍໃນ Google ກ່ຽວກັບ Oraclize, ແລະມີບົດຄວາມຈໍານວນຫນຶ່ງກ່ຽວກັບ Habré ມື້ນີ້ຂ້ອຍຈະເວົ້າກ່ຽວກັບ oracles ທີ່ໃຊ້ວິທີການຖ່າຍທອດຂໍ້ມູນທີ່ແຕກຕ່າງກັນເລັກນ້ອຍ: Town Crier ແລະ DECO. ບົດຄວາມໃຫ້ຄໍາອະທິບາຍກ່ຽວກັບຫຼັກການການດໍາເນີນງານຂອງທັງສອງ oracles, ເຊັ່ນດຽວກັນກັບການປຽບທຽບລາຍລະອຽດ.

ເມືອງ Crier

Town Crier (TC) ຖືກນໍາສະເຫນີໂດຍ IC3 (ການລິເລີ່ມສໍາລັບ CryptoCurrencies ແລະສັນຍາ) ໃນປີ 2016 ຢູ່ CCS'16. ແນວຄວາມຄິດຕົ້ນຕໍຂອງ TC: ການໂອນຂໍ້ມູນຈາກເວັບໄຊທ໌ໄປຫາສັນຍາສະຫມາດແລະໃຫ້ແນ່ໃຈວ່າຂໍ້ມູນທີ່ສົ່ງໂດຍ TC ແມ່ນຄືກັນກັບຢູ່ໃນເວັບໄຊທ໌. TC ໃຊ້ TEE (Trusted Execution Environment) ເພື່ອກວດສອບຄວາມເປັນເຈົ້າຂອງຂໍ້ມູນ. ສະບັບຕົ້ນສະບັບຂອງ TC ອະທິບາຍວິທີການເຮັດວຽກກັບ Intel SGX.
Town Crier ປະກອບດ້ວຍສ່ວນຫນຶ່ງພາຍໃນ blockchain ແລະສ່ວນຫນຶ່ງພາຍໃນ OS ຕົວຂອງມັນເອງ - TC Server.

ສັນຍາ TC ແມ່ນຢູ່ໃນ blockchain ແລະເຮັດຫນ້າທີ່ເປັນສ່ວນຫນ້າສໍາລັບ TC. ມັນຍອມຮັບການຮ້ອງຂໍຈາກ CU (ສັນຍາສະຫມາດຂອງຜູ້ໃຊ້) ແລະສົ່ງຄືນຄໍາຕອບຈາກ TC Server. ພາຍໃນ TC Server ມີ Relay, ເຊິ່ງສ້າງການເຊື່ອມຕໍ່ລະຫວ່າງ enclave ແລະອິນເຕີເນັດ (ການຈະລາຈອນ bidirectional) ແລະເຊື່ອມຕໍ່ enclave ກັບ blockchain. Enclave ປະກອບມີ progencl, ເຊິ່ງເປັນລະຫັດທີ່ເຮັດການຮ້ອງຂໍຈາກ blockchain ແລະສົ່ງຄືນຂໍ້ຄວາມໄປຫາ blockchain ທີ່ມີລາຍເຊັນດິຈິຕອນ, progencl ປະກອບມີສ່ວນຫນຶ່ງຂອງລະຫັດສັນຍາສະຫມາດແລະປະຕິບັດບາງຫນ້າທີ່ຂອງມັນ.

Intel SGX enclave ສາມາດຄິດວ່າເປັນຫ້ອງສະຫມຸດທີ່ໃຊ້ຮ່ວມກັນກັບ API ທີ່ເຮັດວຽກຜ່ານ ecall. Ecall ໂອນການຄວບຄຸມໄປ enclave ໄດ້. enclave ປະຕິບັດລະຫັດຂອງມັນຈົນກ່ວາມັນອອກຫຼືຈົນກ່ວາການຍົກເວັ້ນເກີດຂຶ້ນ. ocall ຖືກນໍາໃຊ້ເພື່ອໂທຫາຫນ້າທີ່ກໍານົດຢູ່ນອກ enclave. Ocall ຖືກປະຕິບັດຢູ່ນອກວົງແຫວນແລະຖືກປະຕິບັດວ່າເປັນການໂທທີ່ບໍ່ຫນ້າເຊື່ອຖືໂດຍມັນ. ຫຼັງຈາກ ocall ຖືກປະຕິບັດ, ການຄວບຄຸມແມ່ນກັບຄືນໄປຫາ enclave.

ໃນສ່ວນ Enclave, ຊ່ອງທາງທີ່ປອດໄພຖືກຕັ້ງຄ່າກັບເຄື່ອງແມ່ຂ່າຍເວັບໄຊຕ໌, enclave ຕົວຂອງມັນເອງປະຕິບັດການຈັບມື TLS ກັບເຄື່ອງແມ່ຂ່າຍເປົ້າຫມາຍແລະປະຕິບັດການເຂົ້າລະຫັດລັບທັງຫມົດພາຍໃນ. ຫ້ອງສະຫມຸດ TLS (mbedTLS) ແລະລະຫັດ HTTP ຫຼຸດລົງໄດ້ຖືກສົ່ງອອກໄປສູ່ສະພາບແວດລ້ອມ SGX. ນອກຈາກນີ້, Enclave ປະກອບມີໃບຢັ້ງຢືນ CA ຮາກ (ຊຸດຂອງໃບຢັ້ງຢືນ) ເພື່ອກວດສອບໃບຢັ້ງຢືນຂອງເຄື່ອງແມ່ຂ່າຍຫ່າງໄກສອກຫຼີກ. Request Handler ຍອມຮັບຄຳຮ້ອງຂໍ datagram ໃນຮູບແບບທີ່ສະໜອງໃຫ້ໂດຍ Ethereum, ຖອດລະຫັດມັນ ແລະວິເຄາະມັນ. ຫຼັງຈາກນັ້ນ, ມັນສ້າງທຸລະກໍາ Ethereum ທີ່ມີ datagram ຮ້ອງຂໍ, ເຊັນມັນກັບ skTC ແລະສົ່ງມັນໄປຫາ Relay.

ສ່ວນ Relay ປະກອບມີການໂຕ້ຕອບລູກຄ້າ, TCP, Blockchain Interface. ການໂຕ້ຕອບລູກຄ້າແມ່ນຈໍາເປັນເພື່ອຢັ້ງຢືນລະຫັດ enclave ແລະຕິດຕໍ່ສື່ສານກັບລູກຄ້າ. ລູກຄ້າສົ່ງຄໍາຮ້ອງຂໍການຢັ້ງຢືນໂດຍໃຊ້ ecall ແລະໄດ້ຮັບເວລາລົງນາມໂດຍ skTC ພ້ອມກັບ att (ລາຍເຊັນຢັ້ງຢືນ), ຫຼັງຈາກນັ້ນ att ຖືກກວດສອບໂດຍໃຊ້ Intel Attestation Service (IAS), ແລະເວລາຖືກກວດສອບໂດຍການບໍລິການເວລາທີ່ເຊື່ອຖືໄດ້. Blockchain Interface ກວດສອບການຮ້ອງຂໍທີ່ເຂົ້າມາແລະວາງການເຮັດທຸລະກໍາໃນ blockchain ສໍາລັບການຈັດສົ່ງ datagrams. Geth ເປັນລູກຄ້າ Ethereum ຢ່າງເປັນທາງການແລະອະນຸຍາດໃຫ້ Relay ພົວພັນກັບ blockchain ຜ່ານການໂທ RPC.

ການເຮັດວຽກກັບ TEE, TC ຊ່ວຍໃຫ້ທ່ານສາມາດດໍາເນີນການ enclaves ຫຼາຍຂະຫນານ, ດັ່ງນັ້ນການເພີ່ມຄວາມໄວຂອງການປະມວນຜົນຂໍ້ມູນຂ່າວສານ 3 ເທົ່າ. ຖ້າກັບຫນຶ່ງແລ່ນ enclave ຄວາມໄວແມ່ນ 15 tx / ວິນາທີ, ຫຼັງຈາກນັ້ນດ້ວຍ 20 ແລ່ນຂະຫນານ enclaves ຄວາມໄວເພີ່ມຂຶ້ນເປັນ 65 tx / ວິນາທີ, ຄວາມໄວປະຕິບັດງານສູງສຸດໃນ Bitcoin blockchain ແມ່ນ 26 tx / ວິນາທີ.

DECO

DECO (Decentralized Oracles for TLS) ຖືກນຳສະເໜີຢູ່ທີ່ CCS'20, ເຮັດວຽກກັບເວັບໄຊທີ່ຮອງຮັບການເຊື່ອມຕໍ່ TLS. ຮັບປະກັນຄວາມລັບແລະຄວາມຊື່ສັດຂອງຂໍ້ມູນ.
DECO ກັບ TLS ໃຊ້ການເຂົ້າລະຫັດແບບ symmetric, ດັ່ງນັ້ນລູກຄ້າແລະເຄື່ອງແມ່ຂ່າຍເວັບມີລະຫັດການເຂົ້າລະຫັດ, ແລະລູກຄ້າສາມາດປອມແປງຂໍ້ມູນ Session TLS ຖ້າມັນຕ້ອງການ. ເພື່ອແກ້ໄຂບັນຫານີ້, DECO ໃຊ້ໂປໂຕຄອນຈັບມືສາມທາງລະຫວ່າງ prover (ສັນຍາສະຫມາດ), verifier (oracle) ແລະ web-server (ແຫຼ່ງຂໍ້ມູນ).

ວິທີທີ່ DECO ເຮັດວຽກແມ່ນວ່າຜູ້ກວດສອບໄດ້ຮັບຂໍ້ມູນ D ແລະຢືນຢັນກັບຜູ້ກວດສອບວ່າ D ມາຈາກເຄື່ອງແມ່ຂ່າຍ TLS S. ບັນຫາອີກຢ່າງຫນຶ່ງແມ່ນວ່າ TLS ບໍ່ໄດ້ເຊັນຂໍ້ມູນແລະມັນເປັນການຍາກສໍາລັບລູກຄ້າ TLS ທີ່ຈະພິສູດວ່າ. ຂໍ້​ມູນ​ໄດ້​ຮັບ​ຈາກ​ແທ້​ຂອງ​ເຄື່ອງ​ແມ່​ຂ່າຍ​ທີ່​ຖືກ​ຕ້ອງ (ຄວາມ​ຫຍຸ້ງ​ຍາກ​ພິ​ສູດ​)​.

ໂປໂຕຄອນ DECO ໃຊ້ກະແຈເຂົ້າລະຫັດ KEnc ແລະ KMac. ລູກຄ້າສົ່ງຄຳຮ້ອງຂໍ Q ໄປຫາ ເວັບເຊີບເວີການຕອບສະໜອງຈາກເຊີບເວີ R ມາຮອດແບບຖືກເຂົ້າລະຫັດ, ແຕ່ລູກຄ້າ ແລະ ເຊີບເວີແບ່ງປັນ KMac ດຽວກັນ, ແລະ ລູກຄ້າສາມາດປອມແປງຂໍ້ຄວາມ TLS ໄດ້. ວິທີແກ້ໄຂຂອງ DECO ແມ່ນການ "ເຊື່ອງ" KMac ຈາກລູກຄ້າ (ຕົວພິສູດ) ຈົນກວ່າມັນຈະຕອບສະໜອງຕໍ່ການຮ້ອງຂໍ. ດຽວນີ້ KMac ຖືກແບ່ງອອກລະຫວ່າງຕົວພິສູດ ແລະ ຕົວກວດສອບ—KpMac ແລະ KvMac. ເຊີບເວີໄດ້ຮັບ KMac ເພື່ອເຂົ້າລະຫັດການຕອບສະໜອງໂດຍໃຊ້ການດຳເນີນການແບ່ງສ່ວນກະແຈ KpMac ⊕ KvMac = KMac.

ໂດຍການຕັ້ງຄ່າການຈັບມືສາມທາງ, ການແລກປ່ຽນຂໍ້ມູນລະຫວ່າງລູກຄ້າແລະເຄື່ອງແມ່ຂ່າຍຈະຖືກປະຕິບັດດ້ວຍການຮັບປະກັນຄວາມປອດໄພ.

ເມື່ອເວົ້າກ່ຽວກັບລະບົບ oracle ທີ່ມີການແບ່ງຂັ້ນຄຸ້ມຄອງ, ຄົນເຮົາບໍ່ສາມາດທີ່ຈະກ່າວເຖິງ Chainlink, ເຊິ່ງມີຈຸດປະສົງເພື່ອສ້າງເຄືອຂ່າຍການກະຈາຍສູນກາງຂອງ oracle nodes ທີ່ເຂົ້າກັນໄດ້ກັບ Ethereum, Bitcoin ແລະ Hyperledger, ໂດຍຄໍານຶງເຖິງ modularity: ທຸກໆສ່ວນຂອງລະບົບສາມາດປັບປຸງໄດ້. ໃນຂະນະດຽວກັນ, ເພື່ອຮັບປະກັນຄວາມປອດໄພ, Chainlink ສະເຫນີໃຫ້ແຕ່ລະ oracle ເຂົ້າຮ່ວມໃນວຽກງານທີ່ຈະອອກການລວມຄີ (ສາທາລະນະແລະເອກະຊົນ). ກະແຈສ່ວນຕົວແມ່ນໃຊ້ເພື່ອສ້າງລາຍເຊັນບາງສ່ວນທີ່ປະກອບດ້ວຍການຕັດສິນໃຈຂອງເຂົາເຈົ້າຕໍ່ກັບການຮ້ອງຂໍຂໍ້ມູນ. ເພື່ອໃຫ້ໄດ້ຮັບຄໍາຕອບ, ມັນຈໍາເປັນຕ້ອງສົມທົບການລົງລາຍເຊັນບາງສ່ວນຂອງ oracles ຂອງເຄືອຂ່າຍ.

Chainlink ວາງແຜນທີ່ຈະດໍາເນີນການ PoC DECO ເບື້ອງຕົ້ນໂດຍເນັ້ນໃສ່ຄໍາຮ້ອງສະຫມັກທາງດ້ານການເງິນທີ່ມີການແບ່ງຂັ້ນຄຸ້ມຄອງເຊັ່ນ Mixicles. ໃນເວລາຂຽນ, ຂ່າວອອກມາໃນ Forbes ວ່າ Chainlink ໄດ້ຊື້ DECO ຈາກມະຫາວິທະຍາໄລ Cornell.

ການໂຈມຕີ oracles

ຈາກທັດສະນະຄວາມປອດໄພຂອງຂໍ້ມູນ, ການໂຈມຕີຕໍ່ໄປນີ້ກ່ຽວກັບເມືອງ Crier ໄດ້ຖືກພິຈາລະນາ:

1. Rogue smart-contact ສີດລະຫັດໃສ່ TEE nodes.
   ໂດຍເນື້ອແທ້ແລ້ວຂອງການໂຈມຕີ: ການສົ່ງລະຫັດສັນຍາສະຫມາດທີ່ບໍ່ຖືກຕ້ອງໂດຍເຈດຕະນາໄປຫາ TEE, ດັ່ງນັ້ນ, ຜູ້ໂຈມຕີທີ່ເຂົ້າເຖິງ node ຈະສາມາດປະຕິບັດສັນຍາສະຫມາດຂອງຕົນເອງ (ການສໍ້ໂກງ) ໃນຂໍ້ມູນທີ່ຖອດລະຫັດ. ຢ່າງໃດກໍ່ຕາມ, ຄ່າກັບຄືນຈະຖືກເຂົ້າລະຫັດດ້ວຍລະຫັດສ່ວນຕົວ, ແລະວິທີດຽວທີ່ຈະເຂົ້າເຖິງຂໍ້ມູນດັ່ງກ່າວແມ່ນການຮົ່ວໄຫລຂອງ ciphertext ໃນການກັບຄືນ / ຜົນຜະລິດ.
   ການປົກປ້ອງການໂຈມຕີນີ້ປະກອບດ້ວຍ enclave ການກວດສອບຄວາມຖືກຕ້ອງຂອງລະຫັດທີ່ຕັ້ງຢູ່ໃນທີ່ຢູ່ປັດຈຸບັນ. ນີ້ສາມາດເຮັດໄດ້ໂດຍໃຊ້ໂຄງການທີ່ຢູ່ບ່ອນທີ່ທີ່ຢູ່ສັນຍາຖືກກໍານົດໂດຍການ hashing ລະຫັດສັນຍາ.

2. ການປ່ຽນແປງລະຫັດລັບຂອງລັດສັນຍາຮົ່ວໄຫຼ.
   ໂດຍເນື້ອແທ້ແລ້ວຂອງການໂຈມຕີ: ເຈົ້າຂອງໂນດທີ່ສັນຍາສະຫມາດຖືກປະຕິບັດມີການເຂົ້າເຖິງສະຖານະຂອງສັນຍາໃນຮູບແບບທີ່ຖືກເຂົ້າລະຫັດຢູ່ນອກ enclave. ຜູ້ໂຈມຕີ, ໄດ້ຮັບການຄວບຄຸມຂອງ node, ສາມາດປຽບທຽບສະຖານະການຕິດຕໍ່ກ່ອນແລະຫຼັງຈາກການເຮັດທຸລະກໍາແລະສາມາດກໍານົດວ່າການໂຕ້ຖຽງທີ່ເຂົ້າມາແລະວິທີການສັນຍາສະຫມາດຖືກນໍາໃຊ້, ເນື່ອງຈາກວ່າລະຫັດສັນຍາສະຫມາດຂອງມັນເອງແລະຂໍ້ມູນສະເພາະທາງດ້ານວິຊາການຂອງມັນແມ່ນມີຢູ່ໃນສາທາລະນະ.
   ການປົກປ້ອງໃນການຮັບປະກັນຄວາມຫນ້າເຊື່ອຖືຂອງ node ຕົວຂອງມັນເອງ.

3. ການໂຈມຕີທາງຂ້າງ.
   ການໂຈມຕີປະເພດພິເສດທີ່ໃຊ້ການກວດສອບຄວາມຊົງຈໍາ enclave ແລະການເຂົ້າເຖິງ cache ໃນສະຖານະການຕ່າງໆ. ຕົວຢ່າງຂອງການໂຈມຕີດັ່ງກ່າວແມ່ນ Prime ແລະ Probe.
   
   ຄໍາ​ສັ່ງ​ການ​ໂຈມ​ຕີ​:

   • t0: ຜູ້ໂຈມຕີຕື່ມຂໍ້ມູນໃສ່ແຄດຂໍ້ມູນທັງໝົດຂອງຂະບວນການຜູ້ເຄາະຮ້າຍ.
   • t1: ຜູ້ຖືກເຄາະຮ້າຍປະຕິບັດລະຫັດທີ່ມີການເຂົ້າເຖິງຫນ່ວຍຄວາມຈໍາທີ່ຂຶ້ນກັບຂໍ້ມູນທີ່ລະອຽດອ່ອນຂອງຜູ້ຖືກເຄາະຮ້າຍ (ລະຫັດລະຫັດລັບ). ເສັ້ນ cache ຖືກເລືອກໂດຍອີງໃສ່ຄ່າຂອງປຸ່ມກົດ. ໃນຕົວຢ່າງໃນຮູບ, keybit = 0 ແລະທີ່ຢູ່ X ໃນ cache line 2 ແມ່ນອ່ານຂໍ້ມູນທີ່ເກັບໄວ້ໃນ X ຖືກໂຫລດເຂົ້າໄປໃນ cache, displaced ຂໍ້ມູນທີ່ມີກ່ອນ.
   • t2: ຜູ້ໂຈມຕີກວດເບິ່ງວ່າສາຍ cache ຂອງລາວໃດໄດ້ຖືກຂັບໄລ່ - ສາຍທີ່ໃຊ້ໂດຍຜູ້ຖືກເຄາະຮ້າຍ. ນີ້ແມ່ນເຮັດໄດ້ໂດຍການວັດແທກເວລາເຂົ້າເຖິງ. ໂດຍການເຮັດຊ້ໍາການດໍາເນີນການນີ້ສໍາລັບແຕ່ລະປຸ່ມກົດ, ຜູ້ໂຈມຕີຈະໄດ້ຮັບລະຫັດທັງຫມົດ.

ການປົກປ້ອງການໂຈມຕີ: Intel SGX ມີການປ້ອງກັນການໂຈມຕີທາງຂ້າງທີ່ປ້ອງກັນການຕິດຕາມເຫດການທີ່ກ່ຽວຂ້ອງກັບ cache, ແຕ່ການໂຈມຕີ Prime ແລະ Probe ຈະຍັງເຮັດວຽກເພາະວ່າຜູ້ໂຈມຕີຈະຕິດຕາມເຫດການ cache ຂອງຂະບວນການຂອງລາວແລະແບ່ງປັນ cache ກັບຜູ້ຖືກເຄາະຮ້າຍ.

ດັ່ງນັ້ນ, ໃນເວລານີ້, ບໍ່ມີການປົກປ້ອງທີ່ເຊື່ອຖືໄດ້ຕໍ່ກັບການໂຈມຕີນີ້.

ການໂຈມຕີເຊັ່ນ Spectre ແລະ Foreshadow (L1TF), ຄ້າຍຄືກັນກັບ Prime ແລະ Probe, ຍັງເປັນທີ່ຮູ້ຈັກ. ພວກເຂົາເຈົ້າອະນຸຍາດໃຫ້ທ່ານສາມາດອ່ານຂໍ້ມູນຈາກຫນ່ວຍຄວາມຈໍາ cache ຜ່ານຊ່ອງທາງພາກສ່ວນທີສາມ. ການປົກປ້ອງຕໍ່ກັບຊ່ອງໂຫວ່ Spectre-v2 ແມ່ນສະຫນອງໃຫ້, ເຊິ່ງເຮັດວຽກຕໍ່ກັບສອງການໂຈມຕີເຫຼົ່ານີ້.

ກ່ຽວຂ້ອງກັບ DECO, ການຈັບມືສາມທາງສະຫນອງການຮັບປະກັນຄວາມປອດໄພ:

1. Prover Integrity: ຜູ້ພິສູດທີ່ຖືກແຮັກບໍ່ສາມາດປອມແປງຂໍ້ມູນຕົ້ນກໍາເນີດຂອງເຄື່ອງແມ່ຂ່າຍແລະບໍ່ສາມາດເຮັດໃຫ້ເຄື່ອງແມ່ຂ່າຍຍອມຮັບຄໍາຮ້ອງຂໍທີ່ບໍ່ຖືກຕ້ອງຫຼືຕອບສະຫນອງຄໍາຮ້ອງຂໍທີ່ບໍ່ຖືກຕ້ອງ. ນີ້ແມ່ນເຮັດໄດ້ໂດຍຜ່ານຮູບແບບການຮ້ອງຂໍລະຫວ່າງເຄື່ອງແມ່ຂ່າຍແລະ prover.
2. ຄວາມສົມບູນຂອງຜູ້ຢັ້ງຢືນ: ຕົວກວດສອບທີ່ຖືກແຮັກບໍ່ສາມາດເຮັດໃຫ້ຜູ້ພິສູດໄດ້ຮັບຄຳຕອບທີ່ບໍ່ຖືກຕ້ອງ.
3. ຄວາມ​ເປັນ​ສ່ວນ​ຕົວ: ຕົວກວດ​ສອບ​ທີ່​ຖືກ​ແຮັກ​ກວດ​ສອບ​ຂໍ້​ມູນ​ສາ​ທາ​ລະ​ນະ​ເທົ່າ​ນັ້ນ (ຄຳ​ຮ້ອງ​ຂໍ, ຊື່​ເຊີບ​ເວີ).

ໃນ DECO, ມີພຽງຊ່ອງໂຫວ່ການສີດການຈະລາຈອນເທົ່ານັ້ນທີ່ເປັນໄປໄດ້. ໃນເບື້ອງຕົ້ນ, ໃນລະຫວ່າງການຈັບມືສາມທາງ, ຕົວກວດສອບສາມາດສ້າງຕົວຕົນຂອງເຊີບເວີໂດຍໃຊ້ nonce ໃໝ່. ຢ່າງໃດກໍຕາມ, ຫຼັງຈາກການຈັບມື, ຕົວກວດສອບຕ້ອງອີງໃສ່ຕົວຊີ້ວັດຊັ້ນເຄືອຂ່າຍ (ທີ່ຢູ່ IP). ດັ່ງນັ້ນ, ການເຊື່ອມຕໍ່ລະຫວ່າງຕົວກວດສອບ ແລະ ເຊີບເວີຕ້ອງໄດ້ຮັບການປົກປ້ອງຈາກການສີດການຈະລາຈອນ. ສິ່ງນີ້ສາມາດບັນລຸໄດ້ໂດຍການໃຊ້ proxy.

ການປຽບທຽບຂອງ oracles

Town Crier ແມ່ນອີງໃສ່ການເຮັດວຽກກັບ enclave ໃນສ່ວນຂອງເຄື່ອງແມ່ຂ່າຍ, ໃນຂະນະທີ່ DECO ຊ່ວຍໃຫ້ທ່ານສາມາດກວດສອບຄວາມຖືກຕ້ອງຂອງແຫຼ່ງກໍາເນີດຂອງຂໍ້ມູນໂດຍໃຊ້ການຈັບມືສາມທາງແລະການເຂົ້າລະຫັດຂໍ້ມູນດ້ວຍລະຫັດລັບ. ການປຽບທຽບ oracles ເຫຼົ່ານີ້ແມ່ນໄດ້ດໍາເນີນໄປຕາມເງື່ອນໄຂດັ່ງຕໍ່ໄປນີ້: ການປະຕິບັດ, ຄວາມປອດໄພ, ຄ່າໃຊ້ຈ່າຍແລະການປະຕິບັດ.

ເມືອງ Crier
DECO

ການປະຕິບັດ
ໄວ​ຂຶ້ນ (0.6 ວິ​ທີ່​ຈະ​ສໍາ​ເລັດ​)
ຊ້າລົງ (10.50ວິເພື່ອສຳເລັດໂປຣໂຕຄໍ)

ຄວາມປອດໄພ
ປອດໄພໜ້ອຍກວ່າ
ປອດໄພກວ່າ

ຄ່າ​ໃຊ້​ຈ່າຍ
ແພງ​ກວ່າ
ລາຄາຖືກກວ່າ

ພາກປະຕິບັດ
ຕ້ອງການຮາດແວພິເສດ
ເຮັດວຽກກັບເຄື່ອງແມ່ຂ່າຍໃດໆທີ່ສະຫນັບສະຫນູນ TLS

ການປະຕິບັດ: ເພື່ອເຮັດວຽກກັບ DECO, ການຈັບມືສາມທາງແມ່ນຈໍາເປັນ, ເມື່ອຕັ້ງຄ່າຜ່ານ LAN ມັນໃຊ້ເວລາ 0.37 ວິນາທີ, ສໍາລັບການໂຕ້ຕອບຫຼັງຈາກການເຊື່ອມຕໍ່ໄດ້ຖືກສ້າງຕັ້ງຂຶ້ນ, 2PC-HMAC ມີປະສິດທິພາບ (0,13 s ຕໍ່ການຂຽນ). ການປະຕິບັດຂອງ DECO ແມ່ນຂຶ້ນກັບຊຸດລະຫັດລັບ TLS ທີ່ມີຢູ່, ຂະຫນາດຂອງຂໍ້ມູນສ່ວນຕົວ, ແລະຄວາມຊັບຊ້ອນຂອງຫຼັກຖານສໍາລັບຄໍາຮ້ອງສະຫມັກສະເພາະໃດຫນຶ່ງ. ການນໍາໃຊ້ຄໍາຮ້ອງສະຫມັກທາງເລືອກຄູ່ຈາກ IC3 ເປັນຕົວຢ່າງ: ການສໍາເລັດໂປໂຕຄອນຜ່ານ LAN ໃຊ້ເວລາປະມານ 10,50 ວິນາທີ. ໂດຍການປຽບທຽບ, Town Crier ໃຊ້ເວລາປະມານ 0,6 ວິນາທີເພື່ອເຮັດສໍາເລັດຄໍາຮ້ອງສະຫມັກທີ່ຄ້າຍຄືກັນ, ເຊິ່ງໄວກວ່າ DECO ປະມານ 20 ເທົ່າ. ທຸກສິ່ງທີ່ເທົ່າທຽມກັນ, TC ຈະໄວຂຶ້ນ.

ຄວາມປອດໄພ: ການໂຈມຕີຂອງ Intel SGX enclave (ການໂຈມຕີທາງຂ້າງ) ເຮັດວຽກແລະສາມາດເຮັດໃຫ້ເກີດຄວາມເສຍຫາຍທີ່ແທ້ຈິງຕໍ່ຜູ້ເຂົ້າຮ່ວມຂອງສັນຍາສະຫມາດ. ກ່ຽວກັບ DECO, ການໂຈມຕີທີ່ກ່ຽວຂ້ອງກັບການສີດການຈະລາຈອນແມ່ນເປັນໄປໄດ້, ແຕ່ການນໍາໃຊ້ຕົວແທນຫຼຸດຜ່ອນການໂຈມຕີດັ່ງກ່າວບໍ່ມີຫຍັງເລີຍ. ດັ່ງນັ້ນ DECO ແມ່ນປອດໄພກວ່າ.

ຄ່າໃຊ້ຈ່າຍຂອງ: ຄ່າໃຊ້ຈ່າຍຂອງອຸປະກອນທີ່ສະຫນັບສະຫນູນ Intel SGX ແມ່ນສູງກວ່າຄ່າໃຊ້ຈ່າຍໃນການຕັ້ງຄ່າໂປໂຕຄອນໃນ DECO. ນັ້ນແມ່ນເຫດຜົນທີ່ TC ແພງກວ່າ.

Practicality: ເພື່ອເຮັດວຽກຮ່ວມກັບ Town Crier, ອຸປະກອນພິເສດທີ່ສະຫນັບສະຫນູນ TEE ແມ່ນຕ້ອງການ. ຕົວຢ່າງ, Intel SGX ໄດ້ຮັບການສະຫນັບສະຫນູນໃນຄອບຄົວຂອງໂປເຊດເຊີ Intel Core ຮຸ່ນທີ 6 ແລະຕໍ່ມາ. DECO ອະນຸຍາດໃຫ້ທ່ານເຮັດວຽກກັບອຸປະກອນໃດກໍ່ຕາມ, ເຖິງແມ່ນວ່າມີການຕັ້ງຄ່າ DECO ໂດຍໃຊ້ TEE. ອີງຕາມຂະບວນການຕິດຕັ້ງ, ການຈັບມືສາມທາງຂອງ DECO ອາດຈະໃຊ້ເວລາບາງເວລາ, ແຕ່ນີ້ບໍ່ມີຫຍັງທຽບກັບຂໍ້ຈໍາກັດຂອງຮາດແວຂອງ TC, ດັ່ງນັ້ນ DECO ແມ່ນປະຕິບັດໄດ້ຫຼາຍກວ່າ.

ສະຫລຸບ

ຊອກຫາຢູ່ໃນສອງ oracles ແຍກຕ່າງຫາກແລະປຽບທຽບພວກເຂົາຢູ່ໃນສີ່ເງື່ອນໄຂ, ມັນເປັນທີ່ຊັດເຈນວ່າ Town Crier ແມ່ນຕ່ໍາກວ່າ DECO ໃນສາມໃນສີ່ຈຸດ. DECO ມີຄວາມຫນ້າເຊື່ອຖືຫຼາຍຂຶ້ນຈາກມຸມເບິ່ງຄວາມປອດໄພຂອງຂໍ້ມູນ, ລາຄາຖືກກວ່າແລະປະຕິບັດໄດ້ຫຼາຍ, ເຖິງແມ່ນວ່າການຕັ້ງຄ່າໂປໂຕຄອນສາມຝ່າຍສາມາດໃຊ້ເວລາບາງເວລາແລະມີຂໍ້ເສຍຂອງມັນ, ຕົວຢ່າງ, ການດໍາເນີນງານເພີ່ມເຕີມທີ່ມີລະຫັດການເຂົ້າລະຫັດ. TC ແມ່ນໄວກວ່າ DECO, ແຕ່ຊ່ອງໂຫວ່ການໂຈມຕີທາງຂ້າງເຮັດໃຫ້ມີຄວາມອ່ອນໄຫວຕໍ່ກັບການສູນເສຍຄວາມລັບ. ມັນຕ້ອງໄດ້ຮັບການພິຈາລະນາວ່າ DECO ໄດ້ຖືກນໍາສະເຫນີໃນເດືອນມັງກອນ 2020, ແລະບໍ່ມີເວລາພຽງພໍທີ່ຈະພິຈາລະນາວ່າມັນປອດໄພ. ເມືອງ Crier ໄດ້ຖືກໂຈມຕີເປັນເວລາ 4 ປີແລະໄດ້ຜ່ານການທົດສອບຫຼາຍຢ່າງ, ດັ່ງນັ້ນການນໍາໃຊ້ຂອງມັນໃນຫຼາຍໂຄງການແມ່ນສົມເຫດສົມຜົນ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com