คู่มือสำหรับนักพัฒนาที่เน้น TEE

金色财经_
POND-5.89%
X-12.77%

ผู้แต่ง: Prateek, Roshan, Siddhartha & Linguine (Marlin), Krane (Asula) ผู้รวบรวม Shew, GodRealmX

ตั้งแต่ Apple ประกาศเปิดตัว Private Cloud และ NVIDIA ให้บริการการคำนวณความลับใน GPU ตัวอย่างเช่นการใช้งาน Trusted Execution Environment (TEE) กลายเป็นที่นิยมมากขึ้น การรักษาความลับช่วยปกป้องข้อมูลของผู้ใช้ (ซึ่งอาจรวมถึงกุญแจส่วนตัว) ในขณะเดียวกันก็มั่นใจว่าการปฏิบัติงานของโปรแกรมที่ระบุไว้บนโดเมนนั้นจะไม่ถูกแก้ไข ไม่ว่าจะเป็นมนุษย์ โปรแกรมอื่น ๆ หรือระบบปฏิบัติการ ดังนั้น ไม่แปลกใจที่วงการ Crypto x AI ใช้ TEE อย่างกว้างขวางเพื่อสร้างผลิตภัณฑ์

เช่นเดียวกับทุกเทคโนโลยีใหม่ ๆ TEE กำลังผ่านช่วงการทดลองที่เต็มไปด้วยความหวัง บทความนี้หวังที่จะให้คำแนะนำพื้นฐานให้แก่นักพัฒนาและผู้อ่านทั่วไปเกี่ยวกับคอนเซ็ปต์พื้นฐานเกี่ยวกับ TEE โมเดลความปลอดภัยของ TEE ช่องโหว่ที่พบบ่อยและวิธีใช้ TEE อย่างปลอดภัยอย่างดีที่สุด

TEEคืออะไร

TEE เป็นสภาพแวดล้อมที่เป็นพื้นที่เฉพาะหรือศูนย์ข้อมูลที่โปรแกรมสามารถทำงานได้ โดยไม่ได้รับการรบกวนจากส่วนอื่นของระบบ เพื่อหลีกเลี่ยงการรบกวน TEE จากส่วนอื่น ๆ ของระบบ เราต้องมีการออกแบบที่เหมาะสม ซึ่งรวมถึงการควบคุมการเข้าถึงเป็นหลัก คือการควบคุมการเข้าถึงโปรแกรมและข้อมูลภายใน TEE ปัจจุบัน TEE มีอยู่ทั่วไปในโทรศัพท์มือถือ เซิร์ฟเวอร์ เครื่องคอมพิวเตอร์และสภาพแวดล้อมคลาวด์ ดังนั้นมันง่ายต่อการเข้าถึงและราคาเหมาะสม

เนื้อหาด้านบนอาจจะฟังเหมือนมัวและนานาเหมือน แต่ในความเป็นจริงวิธีการนำ TEE ไปสู่การปฏิบัติของเซิร์ฟเวอร์และผู้ให้บริการคลาวด์ต่างกัน แต่วัตถุประสงค์หลักคือเพื่อป้องกัน TEE ไม่ให้โปรแกรมอื่นมีส่วนแทรกแทรง

!

ส่วนใหญ่ของผู้อ่านอาจใช้ข้อมูลการระบุตัวบุคคลเข้าสู่อุปกรณ์ เช่น การปลดล็อคโทรศัพท์ด้วยลายนิ้วมือ แต่เราจะทำอย่างไรเพื่อให้แน่ใจว่าแอปพลิเคชันที่ไม่ดี หรือเว็บไซต์ หรือระบบปลดล็อคที่ถูกทำการ Jailbreak ไม่สามารถเข้าถึงและขโมยข้อมูลการระบุตัวบุคคลได้? ในความเป็นจริง นอกจากการเข้ารหัสข้อมูลแล้ว อุปกรณ์ TEE ไม่อนุญาตให้โปรแกรมใดๆ เข้าถึงพื้นที่หน่วยความจำและหน่วยประมวลผลที่ใช้สำหรับข้อมูลที่มีความลับ

กระเป๋าเงินฮาร์ดแวร์เป็นตัวอย่างสถานการณ์การใช้งานของ TEE อีกตัวอย่างหนึ่ง กระเป๋าเงินฮาร์ดแวร์เชื่อมต่อกับคอมพิวเตอร์และสื่อสารกับตัวเล็กมาก แต่คอมพิวเตอร์ไม่สามารถเข้าถึงคำอธิบายที่เก็บไว้ในกระเป๋าเงินฮาร์ดแวร์ได้โดยตรง ในทั้งสองกรณีที่กล่าวมานั้นผู้ใช้มั่นใจในการออกแบบชิปและให้การอัปเดตเฟิร์มแวร์ที่ถูกต้องโดยผู้ผลิตอุปกรณ์เพื่อป้องกันข้อมูลลับภายใน TEE จากการส่งออกหรือการดู

โมเดลความปลอดภัย

น่าเสียดายที่การดำเนินการของ TEE มีหลายรูปแบบที่แตกต่างกัน (Intel SGX、Intel TDX、AMD SEV、AWS Nitro Enclaves、ARM TrustZone) แต่ละรูปแบบต้องการการจำลองและการวิเคราะห์โมเดลความปลอดภัยที่เป็นอิสระกัน ในส่วนที่เหลือของบทความนี้ เราจะพูดถึง Intel SGX、TDX และ AWS Nitro โดยเฉพาะเนื่องจากเป็นระบบ TEE ที่ใช้งานได้มากที่สุดและมีเครื่องมือการพัฒนาที่สมบูรณ์ ระบบที่กล่าวมาเป็นระบบ TEE ที่ใช้ใน Web3 บ่อยที่สุด

โดยทั่วไปแล้ว การทำงานของโปรแกรมที่ถูกติดตั้งใน TEE มีขั้นตอนดังนี้:

  1. "นักพัฒนา"ได้เขียนโค้ดบางส่วนซึ่งอาจมีการเปิดเผยหรือไม่
  2. จากนั้น นักพัฒนาจะทำการแพ็คโค้ดเข้าสู่ Enclave ภาพลักษณ์ไฟล์ (EIF) ซึ่งไฟล์นี้สามารถรันใน TEE ได้
  3. EIFถูกจัดเก็บบนเซิร์ฟเวอร์ที่มีระบบTEEบางกรณีนั้น นักพัฒนาสามารถที่จะโฮสต์ EIF บนเครื่องคอมพิวเตอร์ส่วนตัวที่มีTEEเพื่อให้บริการต่อภายนอกโดยตรง
  4. ผู้ใช้สามารถแสดงออกจากแอปพลิเคชันผ่านอินเตอร์เฟซที่กำหนดไว้ล่วงหน้า

!

โดยชัดเจนว่ามีความเสี่ยงที่ซ่อนอยู่ 3 ประการ:

  • ผู้พัฒนา: โค้ดที่ใช้ในการเตรียม EIF ใช้สำหรับอะไรและมีประโยชน์อย่างไร? โค้ด EIF อาจไม่ตรงกับตรรกะธุรกิจที่โครงการต้องการเผยแพร่ต่อสาธารณชน และอาจเกิดการลักลอบเพื่อขโมยข้อมูลส่วนบุคคลของผู้ใช้
  • เซิร์ฟเวอร์: ไฟล์ EIF บนเซิร์ฟเวอร์ TEE ทำงานตามที่คาดหวังหรือไม่? หรือ EIF จริง ๆ ถูกดำเนินการใน TEE? เซิร์ฟเวอร์อาจทำงานใน TEE กับโปรแกรมอื่น ๆ อีกด้วย
  • ผู้ขาย: การออกแบบ TEE ของ TEE ปลอดภัยหรือไม่? มีทางออกของ TEE เพื่อรั่วข้อมูลทั้งหมดไปยังผู้ขายหรือไม่?

คุ้มค่าที่จะระลึกว่า TEE ในปัจจุบันได้มีวิธีการในการกำจัดความเสี่ยงดังกล่าว นั่นคือ การสร้างซ้ำที่สามารถทำได้(Reproducible Builds)และการรับรองระยะไกล(Remote Atteststations)

ดังนั้น การสร้างซ้ำได้อย่างไร การพัฒนาซอฟต์แวร์ในปัจจุบันมักต้องนำเข้าขึ้นมาเป็นจำนวนมาก เช่น เครื่องมือภายนอก ไลบรารี หรือเฟรมเวิร์ค เป็นต้น ไฟล์เหล่านี้อาจมีความไม่ปลอดภัย ตอนนี้ npm และวิธีการอื่น ๆ ใช้รหัสแฮชของไฟล์ที่ตรงกับรหัสเฉพาะเพื่อระบุ หาก npm พบว่าไฟล์ที่ต้องการเป็นของคุณไม่ตรงกับค่าแฮชที่บันทึก จะถือว่าไฟล์ที่ต้องการนั้นได้รับการแก้ไขแล้ว

!

การสร้างได้อย่างที่เป็นไปได้ซึ่งสามารถทำซ้ำได้ สามารถถือว่าเป็นชุดมาตรฐานซึ่งเป้าหมายคือเมื่อรหัสใดก็ตามที่ทำงานบนอุปกรณ์ใดก็ตาม ถ้ามีการสร้างตามกระบวนการที่กำหนดล่วงหน้า สุดท้ายก็จะได้รับค่าแฮชที่สอดคล้องกัน เพื่อนำไปใช้งานต่อไป แน่นอนว่า ในการปฏิบัติจริง เรายังสามารถใช้ผลลัพธ์ต่างๆที่เกิดจากแฮชเป็นตัวระบุ ในที่นี้เราเรียกว่าการวัดค่าของรหัส (code measurement)

Nix เป็นเครื่องมือที่สามารถสร้างได้ซ้ำได้ หลังจากรหัสซอร์สของโปรแกรมถูกเปิดเผยแล้ว ทุกคนสามารถตรวจสอบรหัสเพื่อให้แน่ใจว่านักพัฒนาไม่ได้แทรกเนื้อหาที่ผิดปกติ ทุกคนสามารถใช้ Nix ในการสร้างรหัส และตรวจสอบผลลัพธ์ที่สร้างออกมาว่ามีการวัดรหัส/แฮชที่เหมือนกับผลลัพธ์ที่โครงการติดตั้งในสภาพแวดล้อมการผลิต ** แต่เราจะรู้ได้อย่างไรถึงค่าการวัดรหัสของโปรแกรมใน TEE นี่เกี่ยวข้องกับคอนเซปต์ที่เรียกว่า "remote attestation" **

!

การรับรองระยะไกลคือข้อความที่ลงนามจากแพลตฟอร์ม TEE (ฝ่ายที่เชื่อถือได้) ที่มีเมตริกโค้ดของโปรแกรมเวอร์ชันแพลตฟอร์ม TEE และอื่น ๆ การรับรองระยะไกลช่วยให้ผู้สังเกตการณ์ภายนอกทราบว่าโปรแกรมกําลังดําเนินการในตําแหน่งที่ปลอดภัย (เวอร์ชัน xx ของ TEE จริง) ที่ทุกคนไม่สามารถเข้าถึงได้

!

การสร้างซ้ำและการพิสูจน์ทางไกลทำให้ผู้ใช้ทุกคนสามารถทราบรหัสที่ทำงานจริงภายใน TEE และข้อมูลเวอร์ชันของแพลตฟอร์ม TEE อันจะป้องกันนักพัฒนาซอฟต์แวร์หรือเซิร์ฟเวอร์ที่ทำผิด

แต่ในกรณีของ TEE เสมอเราต้องการมั่นใจในผู้ผลิต ถ้าผู้ผลิต TEE มีการกระทำที่ไม่ดี เขาสามารถปลอมข้อมูลการพิสูจน์ระยะไกลได้โดยตรง ดังนั้นหากเรามองผู้ผลิตเป็นสื่อโจมตีที่เป็นไปได้ เราควรหลีกเลี่ยงการพึ่งพา TEE เท่าที่จะเป็นไปได้ และควรนำมาใช้ร่วมกับ ZK หรือโครงสร้างเห็นสมควร

เสน่ห์ของ TEE

ในความเห็นของเรา TEE มีคุณสมบัติที่น่าสนใจมากๆ โดยเฉพาะอย่างยิ่งสำหรับความเป็นมิตรของการติดตั้ง AI Agent ที่สำคัญอย่างยิ่งมีดังนี้:

  • **การทำงาน:**TEE สามารถเรียกใช้โมเดล LLM และมีประสิทธิภาพและค่าใช้จ่ายที่เทียบเท่ากับเซิร์ฟเวอร์ปกติ ส่วน zkML ต้องใช้พลังการคำนวณมากเพื่อสร้าง zk พิสูจน์ของ LLM
  • GPUสนับสนุน:NVIDIA ในชุด GPU ล่าสุดของตน (Hopper, Blackwell ฯลฯ) มีการสนับสนุนการคำนวณ TEE
  • ความถูกต้อง:LLMs เป็น non-deterministic; การป้อนคำใบ้เดียวกันหลายครั้งจะได้ผลลัพธ์ที่แตกต่างกัน ดังนั้น โหนดหลายๆ ตัว (รวมถึงผู้สังเกตการณ์ที่พยายามสร้างหลักฐานของการทุจริต) อาจจะไม่เคยเห็นด้วยกันเกี่ยวกับผลการทำงานของ LLM ในกรณีนี้เราสามารถเชื่อใจใน LLM ที่ทำงานอยู่ใน TEE ที่ไม่สามารถถูกคนร้ายคนหนึ่งควบคุม โปรแกรมใน TEE จะทำงานตามที่เขียนไว้เสมอ นี้ทำให้ TEE เหมาะกว่า opML หรือความเห็นร่วมในการรักษาความเชื่อถือของผลลัพธ์การคิดของ LLM
  • ความลับ: ข้อมูลใน TEE ไม่สามารถมองเห็นได้โดยโปรแกรมภายนอก ดังนั้น คีย์ส่วนตัวที่สร้างหรือรับผลิตใน TEE เป็นความปลอดภัยตลอดเวลา คุณสมบัตินี้สามารถใช้ในการให้ความมั่นใจแก่ผู้ใช้ว่าข้อความใด ๆ ที่ได้รับลายเซ็นด้วยคีย์ที่มาจากโปรแกรมภายในของ TEE ผู้ใช้สามารถส่งคีย์ส่วนตัวให้กับ TEE และตั้งเงื่อนไขลายเซ็นและสามารถยืนยันลายเซ็นจาก TEE ที่ตรงกับเงื่อนไขลายเซ็นที่ตั้งไว้ล่วงหน้าได้**
  • การเชื่อมต่อเครือข่าย: โปรแกรมที่ทำงานใน TEE สามารถเข้าถึงอินเทอร์เน็ตได้อย่างปลอดภัย (โดยไม่ต้องเปิดเผยคำค้นหาหรือการตอบสนองกับเซิร์ฟเวอร์ที่ทำงานใน TEE และยังสามารถรับประกันการเรียกข้อมูลที่ถูกต้องสำหรับบุคคลที่สาม) นั่นเป็นประโยชน์อย่างมากสำหรับการดึงข้อมูลจาก API ของบุคคลที่สามซึ่งสามารถนำไปใช้กับผู้ให้บริการโมเดลที่ได้รับความเชื่อถือแต่เป็นที่ประเมิน
  • สิทธิ์ในการเขียน ตรงกันข้ามกับแผนการเขียน zk รหัสที่ทำงานใน TEE สามารถสร้างข้อความ (ไม่ว่าจะเป็นทวีตหรือธุรกรรม) และส่งออกผ่านเครือข่าย API และ RPC
  • เป็นมิตรกับนักพัฒนา: เฟรมเวิร์กและ SDK ที่เกี่ยวข้องกับ TEE ช่วยให้ผู้คนสามารถเขียนโค้ดในภาษาใดก็ได้และสามารถใช้งานโปรแกรมบน TEE ได้อย่างง่ายดายเหมือนในเซิร์ฟเวอร์คลาวด์

ไม่ว่าจะดีหรือไม่ดี การใช้งาน TEE มีหลายที่ที่ยากที่จะหาทางเลือกในขณะนี้ เราเชื่อว่าการนำเข้า TEE ไปยังพื้นที่การพัฒนาแอปพลิเคชันบนโซนนี้เพิ่มขึ้น นี่อาจส่งผลให้เกิดสถานการณ์แอปพลิเคชันใหม่

TEEไม่ใช่กระสุนเงิน

โปรแกรมที่ทำงานในTEE ยังคงเป็นเป้าหมายง่ายต่อชุดของการโจมตีและความผิดพลาด เหมือนกับสัญญาอัจฉริยะ พวกเขายังคงเจอปัญหาชุดเดียวกัน ตามความสะดวกเราจะจัดหมวดหมู่ช่องโหว่ที่เป็นไปได้ดังต่อไปนี้:

  • ผู้พัฒนาขาดความสะดวกในการดำเนินการ
  • ช่องโหว่ในการเรียกใช้งาน
  • ข้อบกพร่องในการออกแบบสถาปัตยกรรม
  • ปัญหาการดำเนินงาน

การประมาณผิดพลาดของนักพัฒนา

ไม่ว่าจะเจต หรือไม่เจต นักพัฒนาสามารถทำให้ความมั่นคงของโปรแกรมใน TEE ลดลงได้ ทั้งโดยมีเจต หรือไม่มีเจต ซึ่งรวมถึง:

  • รหัสที่ไม่โปร่งใส: รูปแบบความปลอดภัยของ TEE ขึ้นอยู่กับการตรวจสอบจากภายนอก ความโปร่งใสของรหัสเป็นสิ่งสำคัญอย่างยิ่งสำหรับการตรวจสอบจากภายนอก
  • ปัญหาในการวัดระดับของโค้ด: แม้ว่าโค้ดจะเปิดเผยไว้ หากไม่มีบุคคลที่สามที่สร้างโค้ดใหม่และตรวจสอบค่าการวัดระดับของโค้ดในการพิสูจน์ระดับระยะไกล และจากนั้นตรวจสอบโค้ดการวัดระดับจากระยะไกลที่ให้มา นี่คล้ายกับการได้รับพิสูจน์ zk แต่ไม่ตรวจสอบมัน
  • โค้ดที่ไม่ปลอดภัย: แม้ว่าคุณจะสร้างและจัดการกุฏลับใน TEE อย่างรอบคอบ แต่โค้ดที่มีอยู่ก็สามารถทำให้กุฏลับใน TEE รั่วไหลขณะที่ถูกเรียกใช้จากภายนอกได้ อย่างไรก็ตาม โค้ดอาจมีประตูหลังหรือช่องโหว่อยู่ด้วย การพัฒนาซอฟต์แวร์และกระบวนการตรวจสอบจำเป็นต้องมีมาตรฐานสูง เหมือนกับการพัฒนาสัญญาอัจฉริยะ
  • การโจมตีโซ่อุปทาน: การพัฒนาซอฟต์แวร์ในยุคปัจจุบันนั้นใช้รหัสจากบุคคลที่สาม. การโจมตีโซ่อุปทานเป็นการลุกลามอย่างมากต่อความสมบูรณ์ของTEE

ช่องโหว่ระหว่างการทำงาน

นักพัฒนาอาจกลายเป็นเหยื่อของช่องโหว่ระหว่างการทำงานได้ถึงแม้จะระมัดระวังมากแค่ไหน นักพัฒนาต้องพิจารณาอย่างรอบคอบว่าสิ่งใดบ้างที่อาจส่งผลกระทบต่อความมั่นคงปลอดภัยของโครงการ

  • รหัสแบบไดนามิก: ไม่ใช่ทุกกรณีที่รักษาความโปร่งใสของรหัสทั้งหมดได้เสมอ บางครั้งกรณีการใช้งานต้องการให้รหัสที่ไม่โปร่งใสที่โหลดเข้า TEE ในเวลาที่สถานการณ์เปลี่ยนไป รหัสที่ไม่โปร่งใสเช่นนี้มีโอกาสรั่วไหลข้อมูลลับหรือทำลายสิ่งที่ไม่เปลี่ยนแปลงได้และต้องปฏิบัติอย่างระมัดระวังเพื่อป้องกันสถานการณ์เช่นนี้
  • ข้อมูลแบบไดนามิก: แอปพลิเคชันส่วนใหญ่ใช้ API จากแหล่งข้อมูลภายนอกและแหล่งข้อมูลอื่น ๆ ในระหว่างการดำเนินการ โมเดลความปลอดภัยถูกขยายให้รวมถึงแหล่งข้อมูลเหล่านี้ ที่มีตำแหน่งเดียวกับ Oracle ใน DeFi ข้อมูลที่ไม่ถูกต้องหรือล้าสมัยอาจส่งผลให้เกิดภัยคุกคาม ตัวอย่างเช่นในกรณีของ AI Agent การพึ่งพาบริการ LLM เกินไป เช่น Claude
  • การสื่อสารที่ไม่ปลอดภัยและไม่เสถียร: TEE ต้องทำงานภายในเซิร์ฟเวอร์ที่มีส่วนประกอบของ TEE การดำเนินการของเซิร์ฟเวอร์ที่ทำงาน TEE จริงๆ แล้วเป็นตัวแทนกลางที่เป็นตัวกลางที่สมบูรณ์รอบด้านความปลอดภัยระหว่าง TEE และการสื่อสารข้ามเขตของภายนอก ซึ่งเซิร์ฟเวอร์ไม่เพียงแค่สามารถดูการเชื่อมต่อของ TEE และเนื้อหาที่กำลังส่งไปได้ แต่ยังสามารถตรวจสอบ IP ที่เฉพาะเจาะจง จำกัดการเชื่อมต่อ และภายในการเชื่อมต่อฉุกเฉินเพื่อหลอกลวงฝ่ายหนึ่งให้เชื่อว่ามาจาก xx

ตัวอย่างเช่นใน TEE ที่สามารถดำเนินการจัดการกับตัวจับคู่การทำธุรกรรมที่เข้ารหัสได้ ตัวจับคู่เหล่านี้ไม่สามารถให้การรับประกันการเรียงลำดับที่เป็นธรรมและต้านการ MEV (การแข่งขันในการเปลี่ยนแปลงอัตราการซื้อขาย) ได้ เนื่องจากโดยตัวกลาง/เกตเวย์/โฮสต์ยังคงสามารถละเลย ความสำคัญ ล่าช้าหรือจัดการเป็นอันดับแรกตามที่มาของแพ็คเกจ IP ได้

ข้อบกพร่องในโครงสร้าง

การใช้เทคโนโลยีสแต็กของแอปพลิเคชัน TEE ควรระมัดระวัง ขณะสร้างแอปพลิเคชัน TEE อาจเกิดปัญหาต่อไปนี้:

  • **แอปพลิเคชันที่มีพื้นที่โจมตีใหญ่: พื้นที่โจมตีของแอปพลิเคชันหมายถึงจำนวนโมดูลโค้ดที่ต้องรักษาความปลอดภัยอย่างสมบูรณ์ ๆ ด้วย โค้ดที่มีพื้นที่โจมตีใหญ่มีความยากที่จะตรวจสอบ อาจซ่อนบั๊กหรือช่องโหว่ที่สามารถใช้ได้ สิ่งนี้มักเกิดขึ้นในทางประสบการณ์ของนักพัฒนาโดยเฉพาะ ยกตัวอย่างเช่น โปรแกรม TEE ที่พึ่ง Docker มีพื้นที่โจมตีมากกว่าโปรแกรม TEE ที่ไม่พึ่ง Docker และ Enclaves ที่พึ่งระบบปฏิบัติการเบา ๆ มีพื้นที่โจมตีมากกว่า TEE ที่พึ่งระบบปฏิบัติการที่เป็นมืออาชีพ
  • ความเคลื่อนย้ายและความกระตือรือร้น: ใน Web3 แอปพลิเคชันจำเป็นต้องสามารถต้านการตรวจสอบ ใครก็สามารถเริ่มต้น TEE และเข้าร่วมผู้เข้าร่วมระบบที่ไม่ใช้งานอยู่และทำให้แอปพลิเคชันใน TEE สามารถเคลื่อนย้ายได้ **ที่ท้ายสุดนี้คือความท้าทายที่ใหญ่ที่สุดคือความเคลื่อนย้ายของคีย์ มีกลไกการสืบทอดคีย์ในระบบ TEE บางระบบ แต่หากใช้กลไกการสืบทอดคีย์ใน TEE จะทำให้เซิร์ฟเวอร์อื่น ๆ ไม่สามารถสร้างคีย์ภายในโปรแกรม TEE จากภายนอก ** ทำให้โปรแกรม TEE มักจะถูก จำกัด ให้อยู่ในเครื่องเดียวกันเท่านั้น ซึ่งไม่เพียงพอที่จะรักษาความเคลื่อนย้าย
  • รากที่ไม่ปลอดภัยของความไว้วางใจ : เช่น เมื่อเรียกใช้ AI Agent ใน TEE อย่างไรเพื่อทำการตรวจสอบว่าที่อยู่ที่กำหนดนั้นเป็นของ AI Agent หรือไม่? หากไม่มีการออกแบบอย่างระมัดระวังที่นี่ จะทำให้รากที่ไว้วางใจจริง ๆ อาจจะเป็นฝ่ายที่สามภายนอกหรือแพลตฟอร์มการจัดเก็บกุญแจแทน TEE เอง

ปัญหาด้านดำเนินงาน

ข้อสำคัญที่สุด แต่ไม่ได้หมายถึงว่าไม่สำคัญสำหรับวิธีการที่แท้จริงในการเรียกใช้เซิร์ฟเวอร์ที่ดำเนินโปรแกรม TEE ยังมีปัญหาทางปฏิบัติบางประการ:

  • รุ่นแพลตฟอร์มที่ไม่ปลอดภัย: TEE บางครั้งจะได้รับการอัปเดตความปลอดภัยซึ่งจะแสดงในรูปแบบของรุ่นแพลตฟอร์มในพิสูจน์ระยะไกล หาก TEE ของคุณไม่ทำงานบนรุ่นแพลตฟอร์มที่ปลอดภัย เจ้าหน้าที่แฮ็กเกอร์สามารถลอกเลียนแบบสมัครใจใน TEE เพื่อขโมยคีย์ได้ ที่แย่กว่าคือ TEE ของคุณอาจทำงานบนรุ่นแพลตฟอร์มที่ปลอดภัยวันนี้ แต่อาจไม่ปลอดภัยในวันพรุ่งนี้
  • ไม่มีความปลอดภัยทางกายภาพ: แม้ว่าคุณจะพยายามทำให้ TEE ปลอดภัยมากที่สุด แต่อาจมีการโจมตีด้วยช่องโหว่ข้างเคียงที่ต้องการเข้าถึงและควบคุมเซิร์ฟเวอร์ที่มี TEE ดังกล่าวทางกายภาพ ดังนั้นความปลอดภัยทางกายภาพเป็นชั้นการป้องกันความปลอดภัยที่สำคัญ หนึ่งในแนวคิดที่เกี่ยวข้องคือการพิสูจน์ในรูปแบบคลาวด์ที่คุณสามารถพิสูจน์ว่า TEE กำลังทำงานในศูนย์ข้อมูลคลาวด์และแพลตฟอร์มคลาวด์นั้นมีการรักษาความปลอดภัยทางกายภาพ

สร้างโปรแกรม TEE ที่ปลอดภัย

เราจะแบ่งคำแนะนำของเราเป็นหลายๆ จุดต่อไปนี้:

  • วิธีที่ปลอดภัยที่สุด
  • ข้อควรระวังที่จําเป็น
  • ข้อเสนอแนะที่ขึ้นอยู่กับกรณีใช้งาน
  1. วิธีที่ปลอดภัยที่สุด: ไม่มีรายการที่ต้องพึ่งพาจากภายนอก

การสร้างแอปพลิเคชันที่มีความปลอดภัยสูงอาจเกี่ยวข้องกับการกำจัดการพึ่งพาภายนอก เช่น ข้อมูลนำเข้าจากภายนอก การใช้ API หรือบริการ ซึ่งจะลดพื้นที่ที่สามารถโจมตีได้ วิธีนี้จะทำให้แอปพลิเคชันทำงานอย่างเองโดยไม่มีการปฏิสัมพันธ์ภายนอกที่อาจทำให้เสียหายต่อความสมบูรณ์หรือความปลอดภัยของแอปพลิเคชัน แม้ว่ายุทธวิธีนี้อาจจำกัดความหลากหลายในฟังก์ชันของโปรแกรม แต่ก็สามารถให้ความปลอดภัยสูงมากได้

หากโมเดลทำงานบนเครื่องหรือเซิร์ฟเวอร์ในพื้นที่ จะสามารถทำให้ระดับความปลอดภัยนี้เป็นไปได้สำหรับกรณีใช้งาน CryptoxAI ส่วนใหญ่

2. ข้อควรระวังที่จําเป็น

ไม่ว่าแอปพลิเคชันจะมีการพึ่งพาภายนอกหรือไม่ ข้อมูลต่อไปนี้จะเป็นสิ่งที่ต้องมีเสมอ!

มองแอปพลิเคชัน TEE ว่าเป็นสัญญาอัจฉริยะ ไม่ใช่แอปพลิเคชันด้านหลัง; รักษาอัตราการอัปเดตต่ำ และทดสอบอย่างเข้มข้น

การสร้างโปรแกรม TEE ควรเคร่งครัดเช่นเดียวกับการเขียน ทดสอบ และอัปเดตสมาร์ทคอนแทรค การทำงานของ TEE ในสภาพแวดล้อมที่อ่อนไหวและไม่สามารถปรับเปลี่ยนได้เหมือนกับสมาร์ทคอนแทรค ที่เกิดขึ้นในสภาพแวดล้อมที่แข็งแกร่ง การที่เกิดข้อผิดพลาดหรือพฤติกรรมที่ไม่คาดคิดอาจส่งผลให้เกิดผลกระทบที่รุนแรง เช่น การสูญเสียเงินอย่างสมบูรณ์ การตรวจสอบอย่างละเอียด การทดสอบอย่างแพร่หลาย และการอัปเดตอย่างน้อยจำเป็นต้องมีการตรวจสอบอย่างละเอียด เพื่อให้แน่ใจว่าความสมบูรณ์และความเชื่อถือได้ของแอพพลิเคชันที่ใช้ TEE ได้ถูกดูแลอย่างเหมาะสม

ตรวจสอบรหัสการตรวจสอบและตรวจสอบท่อการสร้าง

ความปลอดภัยของแอปพลิเคชันไม่เพียงอย่างที่ขึ้นอยู่กับรหัสต้นฉบับเท่านั้น แต่ยังขึ้นอยู่กับเครื่องมือที่ใช้ในกระบวนการสร้าง การสร้างท่อความปลอดภัยเป็นสิ่งสำคัญในการป้องกันช่องโหว่ TEE รับรองเพียงแค่รหัสที่ให้ไปแต่ไม่สามารถแก้ไขข้อบกพร่องที่เกิดขึ้นในกระบวนการสร้างได้

เพื่อลดความเสี่ยง จำเป็นต้องทดสอบและตรวจสอบโค้ดอย่างเข้มงวดเพื่อกำจัดข้อผิดพลาดและป้องกันการรั่วไหลของข้อมูลที่ไม่จำเป็น นอกจากนี้ การสร้างได้ซ้ำซ้อนมีบทบาทสำคัญเป็นพิเศษ โดยเฉพาะเมื่อโค้ดถูกพัฒนาโดยฝ่ายหนึ่งและถูกใช้โดยอีกฝ่ายหนึ่ง การสร้างได้ซ้ำซ้อนช่วยให้ทุกคนสามารถตรวจสอบว่าโปรแกรมที่ทำงานใน TEE สอดคล้องกับโค้ดต้นฉบับหรือไม่ โดยทำให้มั่นใจและมีความโปร่งใส หากไม่มีการสร้างได้ซ้ำซ้อน การกำหนดเนื้อหาของโปรแกรมที่ทำงานใน TEE อย่างแม่นยำเกือบเป็นไปไม่ได้ ซึ่งอาจเป็นอันตรายต่อความปลอดภัยของแอปพลิเคชัน

ตัวอย่างเช่น โครงการ DeepWorm (โครงการจำลองโมเดลสมองของเสมีที่ทำงานใน TEE) มีโค้ดที่เปิดเต็มรูปแบบ การดำเนินการภายในของ TEE ถูกสร้างขึ้นอย่างสามารถทำซ้ำได้โดยใช้ท่อ Nix

การใช้คลังข้อมูลที่ผ่านการตรวจสอบหรือตรวจสอบ

ในการจัดการข้อมูลที่เป็นอ่อนไหวในโปรแกรม TEE โปรดใช้ไลบรารีที่ผ่านการตรวจสอบเท่านั้นสำหรับการจัดการคีย์และข้อมูลส่วนตัว ไลบรารีที่ไม่ผ่านการตรวจสอบอาจเปิดเผยคีย์และทำให้แอปพลิเคชันไม่ปลอดภัย คำสำคัญคือการพิจารณาอย่างเพียงพอ พฤติกรรมที่เป็นศูนย์กลางของความปลอดภัยเพื่อรักษาความลับและความสมบูรณ์ของข้อมูล

ยืนยันพิสูจน์จาก TEE ตลอดเวลา

**ผู้ใช้ที่มีการโต้ตอบกับ TEE จะต้องตรวจสอบการพิสูจน์ระยะไกลหรือกลไกการตรวจสอบที่ TEE สร้างขึ้นเพื่อให้มั่นใจในความปลอดภัยและความน่าเชื่อถือของการโต้ตอบ หากไม่มีการตรวจสอบเหล่านี้ การเซิร์ฟเวอร์อาจทำการตอบสนองอย่างที่ไม่ถูกต้อง ซึ่งอาจทำให้เราไม่สามารถแยกแยะระหว่างเอาท์พุทของ TEE ที่แท้จริงและข้อมูลที่ถูกแก้ไขไป การพิสูจน์ระยะไกลจะให้พิสูจน์ที่สำคัญสำหรับไลบรารีโค้ดและการกำหนดค่าที่ทำงานใน TEE ซึ่งเราสามารถใช้การพิสูจน์ระยะไกลเพื่อตรวจสอบว่าโปรแกรมที่ทำงานอยู่ใน TEE สอดคล้องกับที่คาดหวัง

การรับรองที่แน่ชัดสามารถทำได้บนเชื่อมโยง (IntelSGX, AWSNitro) การตรวจสอบภายในเชื่อมโยงโดยใช้การพิสูจน์ ZK (IntelSGX, AWSNitro) หรือผู้ใช้หรือบริการโฮสต์ที่เป็นเจ้าของ (เช่น t16z หรือ MarlinHub)

3. ข้อเสนอที่ขึ้นอยู่กับกรณีใช้

ตามกรณีใช้งานและโครงสร้างของแอปพลิเคชันเป้าหมาย ที่เราจะแนะนำเพื่อช่วยทำให้แอปพลิเคชันของคุณปลอดภัยมากขึ้น

ให้แน่ใจว่าการแสดงผลของผู้ใช้งานและการโต้ตอบกับ TEE เป็นไปในช่องทางที่ปลอดภัยเสมอ

เซิร์ฟเวอร์ที่เกี่ยวข้องกับ TEE ไม่น่าไว้วางใจ สามารถดักจับและแก้ไขการสื่อสารได้ ในบางกรณีเซิร์ฟเวอร์อาจอ่านข้อมูลแต่ไม่เปลี่ยนแปลงข้อมูลอาจเป็นได้ยินยอมให้ ในกรณีอื่นๆ การอ่านข้อมูลอาจเป็นสิ่งที่ไม่เหมาะสม ในการลดความเสี่ยงเหล่านี้ สร้างทางสื่อสารที่เข้ารหัสด้วยการเชื่อมต่อปลายทางที่ปลอดภัยระหว่างผู้ใช้และ TEE สำคัญอย่างยิ่ง อย่างน้อย ๆ กรุณาตรวจสอบให้แน่ใจว่าข้อความมีลายเซ็นเพื่อยืนยันความถูกต้องและแหล่งที่มา นอกจากนี้ผู้ใช้จำเป็นต้องตรวจสอบการพิสูจน์ระยะไกลที่ TEE ให้มาเพื่อยืนยันว่ากำลังสื่อสารกับ TEE ที่ถูกต้อง นี้จัดให้มั่นใจในความสมบูรณ์และความลับของการสื่อสาร

ตัวอย่างเช่น Oyster สามารถรองรับการออกใบรับรอง TLS ที่ปลอดภัยโดยใช้ระเบียบการบันทึก CAA และ RFC8657 อีกทั้งยังให้บริการโปรโตคอล TLS ชื่อ Scallop ซึ่งเป็นภาษาเดียวกับ TEE และไม่ต้องพึ่งพา WebPKI

รู้ว่าหน่วยความจำ TEE เป็นชั่วขณะ

หน่วยความจำ TEE เป็นชั่วคราว นั่นหมายความว่าเมื่อ TEE ปิด ข้อมูล (รวมถึงคีย์เข้ารหัส) จะหายไป หากไม่มีกลไกการรักษาข้อมูลเหล่านี้อย่างปลอดภัย ข้อมูลสำคัญอาจไม่สามารถเข้าถึงได้อีกตลอดกาล ซึ่งอาจทำให้เงินทุนหรือการดำเนินงานตกอยู่ในความไม่แน่นอน

เครือข่ายการคำนวณหลายฝั่ง (MPC) ที่มีระบบจัดเก็บแบบไม่มีจุดศูนย์อย่าง IPFS สามารถใช้เป็นโซลูชันสำหรับปัญหานี้ได้ เครือข่าย MPC แยกคีย์เป็นหลายๆ โหนดเพื่อให้แน่ใจว่าไม่มีโหนดเดียวที่ถือคีย์ทั้งหมด ในเวลาเดียวกันยังอนุญาตให้เครือข่ายสร้างคีย์ใหม่เมื่อจำเป็น ข้อมูลที่เข้ารหัสด้วยคีย์นี้สามารถเก็บรักษาได้อย่างปลอดภัยบน IPFS

หากจำเป็น MPC สามารถให้คีย์กับเซิร์ฟเวอร์ TEE ใหม่ที่เรียกด้วยภาพกระจายเดียวกัน โดยเงื่อนไขพิเศษ วิธีนี้สามารถให้ความแข็งแรงและป้องกันการเข้าถึงข้อมูลและความลับได้ แม้ในสภาพแวดล้อมที่ไม่น่าเชื่อถือ

!

ยังมีวิธีการแก้ไขอีกหนึ่งวิธีคือ ** TEE จะมอบหมายงานที่เกี่ยวข้องให้กับเซิร์ฟเวอร์ MPC ที่แตกต่างกัน และเซิร์ฟเวอร์ MPC จะทำการเซ็นต์ทรานแซ็กชันและรวมเซ็นต์ทรานแซ็กชันแล้วนำทรานแซ็กชันสุดท้ายขึ้นโซ่บล็อก วิธีนี้มีความยืดหยุ่นต่ำกว่าและไม่สามารถใช้ในการเก็บรักษาคีย์ API รหัสผ่านหรือข้อมูลอื่น ๆ (ไม่มีบริการจัดเก็บฝั่งที่ไม่น่าเชื่อถือ) **

!

ลดพื้นที่การโจมตี

สำหรับกรณีใช้ที่มีความสำคัญในเรื่องความปลอดภัย คุณควรพยายามลดการพึ่งพาภายนอกให้น้อยที่สุด แม้ว่าจะต้องเสียความสะดวกสบายของนักพัฒนาเป็นราคา ตัวอย่างเช่น Dstack มาพร้อมกับเคอร์เนลขนาดเล็กที่พื้นฐานบน Yocto ที่มีโมดูลที่จำเป็นสำหรับการทำงานของ Dstack เท่านั้น อาจเป็นความคุ้มค่าในการใช้เทคโนโลยีเก่าอย่าง SGX (เกิน TDX) ซึ่งไม่ต้องการตัวโหลดบูตหรือระบบปฏิบัติการเป็นส่วนหนึ่งของ TEE

การแยกกั้นทางกายภาพ

โดยการแยกอุปกรณ์ที่มีการป้องกันความปลอดภัยแบบ TEE จากการเข้าถึงโดยมนุษย์ อาจเสริมความปลอดภัยของ TEE ได้อีกเพิ่ม ถึงแม้เราสามารถที่จะทำให้เซิร์ฟเวอร์ TEE ถูกโฮสต์ในศูนย์ข้อมูลและผู้ให้บริการคลาวด์ เชื่อว่าศูนย์ข้อมูลสามารถให้ความปลอดภัยทางกายภาพ แต่โครงการเช่น Spacecoin กำลังสำรวจทางเลือกที่น่าสนใจอย่างมาก — อวกาศ SpaceTEE พิจารณาจากเอกสารวิจัยในด้านความปลอดภัย ด้วยมาตรการที่ปลอดภัย เช่น การวัดข้อมือเนื่องหลังการปล่อย ใช้เพื่อยืนยันว่าดาวเทียมไหว้ถอนออกจากเส้นวงโคจะไปอยู่ในลักษณะที่แตกต่างจากที่คาดหวัง

ผู้รับรองหลายทาง

เช่นเดียวกับที่ Ethereum อาศัยการใช้งานไคลเอนต์หลายตัวเพื่อลดความเสี่ยงของข้อบกพร่องที่ส่งผลกระทบต่อเครือข่ายทั้งหมด multiprofessionals ใช้การใช้งาน TEE ที่แตกต่างกันเพื่อปรับปรุงความปลอดภัยและความยืดหยุ่น ด้วยการเรียกใช้ขั้นตอนการคํานวณเดียวกันในหลายแพลตฟอร์ม TEE การตรวจสอบหลายปัจจัยช่วยให้มั่นใจได้ว่าช่องโหว่ในการใช้งาน TEE เดียวจะไม่ส่งผลกระทบต่อแอปพลิเคชันทั้งหมด ในขณะที่วิธีการนี้ต้องการให้การไหลของการคํานวณเป็นตัวกําหนดหรือเพื่อกําหนดฉันทามติระหว่างการใช้งาน TEE ที่แตกต่างกันในกรณีที่ไม่กําหนด แต่ก็มีประโยชน์ที่สําคัญเช่นการแยกข้อผิดพลาดความซ้ําซ้อนและการตรวจสอบข้ามทําให้เป็นตัวเลือกที่ดีสําหรับแอปพลิเคชันที่ต้องการการรับประกันความน่าเชื่อถือ

!

มองหน้า

TEE เป็นสิ่งที่น่าตื่นเต้นมากในขณะนี้ ตามที่กล่าวไว้ก่อนหน้านี้ AI อยู่ทั่วไปและการเข้าถึงข้อมูลที่ใช้ในการติดต่อของผู้ใช้ทำให้บริษัทเทคโนโลยีขนาดใหญ่เช่น Apple และ NVIDIA ใช้ TEE ในผลิตภัณฑ์ของพวกเขาและให้ TEE เป็นส่วนหนึ่งของผลิตภัณฑ์ของพวกเขา

ในทางกลับกัน, ชุมชนคริปโตได้ให้ความสำคัญกับความปลอดภัยอย่างสูง เมื่อนักพัฒนาพยายามขยายการใช้งานและกรณีการใช้งานบนเชื่อมโยง พวกเราได้เห็น TEE เป็นทางเลือกที่เป็นที่นิยมในการให้ความสมดุลระหว่างความสามารถและความเชื่อถือ ** แม้ว่า TEE จะไม่ได้เชื่อถือเช่นเครื่องช่วยซุปเปอร์และเราคาดว่า TEE จะเป็นทางเลือกที่ค่อนข้างช้าสำหรับบริษัท Web3 และผลิตภัณฑ์ของบริษัทเทคโนโลยีขนาดใหญ่ครั้งแรก

ดูต้นฉบับ
news.article.disclaimer
แสดงความคิดเห็น
0/400
ไม่มีความคิดเห็น