Hướng dẫn dành cho nhà phát triển TEE

Tác giả: prateeek, roshan, siddhartha & linguine (Marlin), krane (Asula) Trình biên dịch: Shew, Heavenly Being GodRealmX

Kể từ khi Apple công bố ra mắt Môi trường thực thi tin cậy (TEE) riêng tư ngày càng trở nên phổ biến kể từ khi đám mây và NVIDIA cung cấp khả năng tính toán bí mật trong GPU. Tính bảo mật của chúng giúp bảo vệ dữ liệu người dùng (có thể bao gồm khóa riêng tư), trong khi tính cách ly đảm bảo rằng việc thực thi các chương trình được triển khai trên chúng không thể bị giả mạo—dù là do con người, các chương trình khác hay hệ điều hành. Vì vậy, không có gì ngạc nhiên khi lĩnh vực Crypto x AI sử dụng TEE rộng rãi để xây dựng sản phẩm.

Giống như bất kỳ công nghệ mới nào, TEE đang trải qua giai đoạn thử nghiệm lạc quan. Bài viết này hy vọng sẽ cung cấp hướng dẫn khái niệm cơ bản cho các nhà phát triển và độc giả nói chung để hiểu TEE là gì, mô hình bảo mật của TEE, các lỗ hổng phổ biến và các phương pháp hay nhất để sử dụng TEE một cách an toàn. (Lưu ý: Để làm cho văn bản dễ hiểu hơn, chúng tôi đã cố ý thay thế các thuật ngữ TEE bằng các thuật ngữ tương đương đơn giản hơn).

TEE là gì

TEE đang được xử lý Một môi trường biệt lập trong máy chủ hoặc trung tâm dữ liệu nơi chương trình có thể chạy mà không có bất kỳ sự can thiệp nào từ phần còn lại của hệ thống. Để ngăn TEE bị các bộ phận khác can thiệp, chúng ta cần một loạt thiết kế, chủ yếu bao gồm kiểm soát truy cập nghiêm ngặt, nghĩa là kiểm soát quyền truy cập của các bộ phận khác của hệ thống vào các chương trình và dữ liệu trong TEE. TEE hiện có mặt khắp nơi trên điện thoại di động, máy chủ, PC và môi trường đám mây, khiến nó trở nên rất dễ tiếp cận và giá cả phải chăng.

Nội dung trên nghe có vẻ mơ hồ và trừu tượng. Trên thực tế, các nhà cung cấp máy chủ và đám mây khác nhau triển khai TEE theo những cách khác nhau, nhưng mục đích cơ bản của nó là tránh can thiệp vào TEE. với các chương trình khác.

Hầu hết độc giả có thể sẽ sử dụng thông tin sinh trắc học để đăng nhập vào thiết bị, chẳng hạn như mở khóa điện thoại bằng dấu vân tay. Nhưng làm cách nào để chúng tôi đảm bảo rằng các ứng dụng, trang web độc hại hoặc hệ điều hành đã bẻ khóa không thể truy cập và đánh cắp thông tin sinh trắc học này? Trên thực tế, ngoài việc mã hóa dữ liệu, mạch điện trong thiết bị TEE không cho phép bất kỳ chương trình nào truy cập vào vùng bộ nhớ và bộ xử lý bị chiếm giữ bởi dữ liệu nhạy cảm.

Ví phần cứng là một ví dụ khác về kịch bản ứng dụng TEE. Ví phần cứng kết nối và hộp cát liên lạc với máy tính, nhưng máy tính không có quyền truy cập trực tiếp vào cụm từ ghi nhớ được lưu trữ trong ví phần cứng. Trong cả hai trường hợp, người dùng tin tưởng nhà sản xuất thiết bị sẽ thiết kế chip phù hợp và cung cấp các bản cập nhật chương trình cơ sở thích hợp để ngăn chặn việc xuất hoặc xem dữ liệu bí mật trong TEE.

Mô hình bảo mật

Thật không may, các loại triển khai TEE Nhiều, nhiều cách triển khai khác nhau này (IntelSGX, IntelTDX, AMDSEV, AWSNitroEnclaves, ARMTrustZone) yêu cầu phân tích mô hình mô hình bảo mật độc lập. Trong phần còn lại của bài viết này, chúng ta sẽ chủ yếu thảo luận về IntelSGX, TDX và AWSNitro, vì các hệ thống TEE này có nhiều người dùng hơn và có sẵn các công cụ phát triển hoàn chỉnh. Hệ thống trên cũng là hệ thống TEE được sử dụng phổ biến nhất trong Web3.

Nói chung, quy trình làm việc của một ứng dụng được triển khai trong TEE như sau:

1. "Nhà phát triển" viết một số mã có thể có hoặc không phải là nguồn mở

   < /li>< li>

   Sau đó, nhà phát triển sẽ đóng gói mã vào Tệp hình ảnh Enclave (EIF), tệp này có thể chạy trong TEE

2. EIF được lưu trữ trên máy chủ có hệ thống TEE. Trong một số trường hợp, nhà phát triển có thể trực tiếp sử dụng máy tính cá nhân có TEE để lưu trữ EIF nhằm cung cấp dịch vụ bên ngoài

3. Người dùng có thể xác định trước giao diện để tương tác với ứng dụng.

Rõ ràng, có ba rủi ro tiềm ẩn ở đây:

• Nhà phát triển: Chính xác thì mã được sử dụng để chuẩn bị EIF có tác dụng gì? Mã EIF có thể không tuân theo logic kinh doanh do bên dự án thúc đẩy và có thể lấy cắp dữ liệu riêng tư của người dùng

• Máy chủ: Máy chủ TEE có chạy tệp EIF như mong đợi không? Hay EIF thực sự được thực thi trong TEE? Máy chủ cũng có thể chạy các chương trình khác trong TEE

• Nhà cung cấp: Thiết kế của TEE có an toàn không? Có cửa hậu nào làm rò rỉ tất cả dữ liệu trong TEE cho nhà cung cấp không?

Rất may, TEE hiện đã có kế hoạch loại bỏ các rủi ro trên, cụ thể là Reproducible Bản dựng và trạm chứng thực từ xa.

Vậy bản dựng lặp lại là gì? Việc phát triển phần mềm hiện đại thường yêu cầu nhập một số lượng lớn các phần phụ thuộc, chẳng hạn như các công cụ, thư viện hoặc khung bên ngoài, v.v. Những tệp phụ thuộc này cũng có thể tiềm ẩn những mối nguy hiểm. Các giải pháp như npm hiện sử dụng mã băm tương ứng với tệp phụ thuộc làm mã định danh duy nhất. Khi npm phát hiện thấy tệp phụ thuộc không nhất quán với giá trị băm được ghi, có thể coi tệp phụ thuộc đã bị sửa đổi.

Các bản dựng lặp lại có thể được coi là một bộ tiêu chuẩn. Mục tiêu là khi bất kỳ mã nào được chạy trên bất kỳ thiết bị nào, miễn là nó được xây dựng theo quy trình được chỉ định trước, thì có thể thu được giá trị băm nhất quán trong sự kết thúc. Tất nhiên, Trong thực tế, chúng tôi cũng có thể sử dụng các sản phẩm khác ngoài hàm băm làm giá trị nhận dạng mà chúng tôi gọi là đo lường mã ở đây.

Nix ​​là một công cụ phổ biến cho các bản dựng lặp lại. Khi mã nguồn của chương trình được công khai, bất kỳ ai cũng có thể kiểm tra mã để đảm bảo rằng nhà phát triển không chèn nội dung bất thường. Bất kỳ ai cũng có thể sử dụng Nix để xây dựng mã và kiểm tra xem sản phẩm được xây dựng có giống với sản phẩm được triển khai hay không. dự án trong môi trường sản xuất. Mã số liệu/Hash. Nhưng làm cách nào để chúng tôi biết số liệu mã của chương trình trong TEE? Điều này liên quan đến một khái niệm gọi là "chứng thực từ xa".

Chứng thực từ xa là một tin nhắn được ký từ nền tảng TEE (bên đáng tin cậy) chứa số liệu mã của chương trình, phiên bản nền tảng TEE, v.v. Chứng thực từ xa cho phép những người quan sát bên ngoài biết rằng một chương trình đang thực thi ở một vị trí an toàn (phiên bản xx của TEE thực) mà không ai có thể truy cập được.

Các bản dựng lặp lại và chứng thực từ xa cho phép bất kỳ người dùng nào biết mã thực tế đang chạy trong TEE và thông tin phiên bản nền tảng TEE, từ đó ngăn chặn các nhà phát triển hoặc máy chủ làm điều xấu.

Tuy nhiên,trong trường hợp TEE, luôn cần phải tin tưởng vào nhà cung cấp của mình. Nếu nhà cung cấp TEE xấu, họ có thể trực tiếp giả mạo chứng chỉ từ xa. Do đó, nếu nhà cung cấp được coi là một vectơ tấn công có thể xảy ra, nên tránh chỉ dựa vào TEE và tốt hơn là nên kết hợp chúng với ZK hoặc các giao thức đồng thuận.

Sự quyến rũ của TEE

Trong us Có vẻ như các tính năng đặc biệt phổ biến của TEE, đặc biệt là tính thân thiện với việc triển khai AI Agent, chủ yếu nằm ở các điểm sau:

• < p style="văn bản-căn chỉnh: left;">Hiệu suất:TEE có thể chạy các mô hình LLM và hiệu suất cũng nhưchi phí chung của nó tương tự như các máy chủ thông thường. ZkML yêu cầu rất nhiều sức mạnh tính toán để tạo ra bằng chứng zk của LLM

• Hỗ trợ GPU: NVIDIA cung cấp hỗ trợ tính toán TEE trong dòng GPU mới nhất của mình (Hopper, Blackwell, v.v.)

• Tính chính xác: LLM không mang tính xác định; việc nhập cùng một từ gợi ý nhiều lần sẽ mang lại các kết quả khác nhau. Do đó, nhiều nút (bao gồm cả những người quan sát đang cố gắng tạo bằng chứng gian lận) có thể không bao giờ đạt được sự đồng thuận về kết quả của hoạt động LLM. Trong kịch bản này, chúng ta có thể tin tưởng rằng LLM chạy trong TEE không thể bị thao túng bởi các tác nhân xấu và các chương trình trong TEE luôn chạy như được viết.Điều này làm cho TEE phù hợp hơn opML hoặc sự đồng thuận để đảm bảo độ tin cậy của kết quả suy luận LLM

• Tính bảo mật:Cặp dữ liệu trong các chương trình TEE Bên ngoài không thể nhìn thấy được. Do đó, khóa riêng được tạo hoặc nhận trong TEE luôn an toàn. Tính năng này có thể được sử dụng để đảm bảo với người dùng rằng bất kỳ thông báo nào được ký bởi khóa này đều bắt nguồn từ các thủ tục nội bộ của TEE. Người dùng có thể giao phó khóa riêng cho TEE một cách an toàn và đặt một số điều kiện ký, đồng thời có thể xác nhận rằng chữ ký từ TEE đáp ứng các điều kiện ký đặt trước

  li >

• Kết nối mạng:Với một số công cụ, các chương trình chạy trong TEE có thể truy cập Internet một cách an toàn (mà không tiết lộ các truy vấn tới máy chủ mà TEE đang chạy) hoặc phản hồi trong khi vẫn đảm bảo cho bên thứ ba về việc truy xuất dữ liệu chính xác). Điều này rất hữu ích để truy xuất thông tin từ API của bên thứ ba và có thể được sử dụng để thuê ngoài tính toán cho nhà cung cấp mô hình độc quyền nhưng đáng tin cậy

• Quyền ghi: Ngược lại với sơ đồ zk, mã chạy trong TEE có thể tạo tin nhắn (dù là tweet hay giao dịch) và gửi chúng thông qua quyền truy cập mạng API và RPC Thoát ra

• Thân thiện với nhà phát triển:Các khung và SDK liên quan đến TEE cho phép mọi người viết mã bằng bất kỳ ngôn ngữ nào và triển khai các chương trình lên TEE dễ dàng như trên máy chủ đám mây

Dù tốt hay xấu, khá nhiều trường hợp sử dụng sử dụng TEE hiện khó tìm được giải pháp thay thế. Chúng tôi tin rằng việc giới thiệu TEE sẽ mở rộng hơn nữa không gian phát triển cho các ứng dụng trên chuỗi, điều này có thể thúc đẩy sự xuất hiện của các kịch bản ứng dụng mới.

TEE không phải là viên đạn bạc

Trong TEE Các chương trình chạy trong Windows vẫn dễ bị tấn công và gặp lỗi. Giống như hợp đồng thông minh, chúng dễ gặp phải nhiều vấn đề. Để đơn giản, chúng tôi phân loại các lỗ hổng có thể xảy ra như sau:

• Phát triển Toán tử đã sơ suất

• Lỗ hổng trong thời gian chạy

• Lỗi thiết kế kiến ​​trúc

• Vấn đề vận hành

Sự sơ suất của nhà phát triển

Dù cố ý hay không, các nhà phát triển có thể làm suy yếu sự đảm bảo an ninh của các chương trình trong TEE thông qua mã cố ý hoặc vô ý. Điều này bao gồm:

• Mã độ mờ: Mô hình bảo mật của TEE dựa vào khả năng xác minh bên ngoài. Tính minh bạch của mã rất quan trọng đối với việc xác minh bên ngoài của bên thứ ba.

• Các vấn đề về số liệu mã: Ngay cả khi mã là Công khai, nếu không có bên thứ ba nào xây dựng lại mã và kiểm tra số liệu mã trong chứng thực từ xa thì sau đó kiểm tra lại các số liệu mã được cung cấp trong chứng thực từ xa. Điều này tương tự như việc nhận được bằng chứng zk nhưng không xác minh nó.

• Mã không an toàn: Ngay cả khi bạn cẩn thận làm đúng trong TEE Tạo và quản lý khóa,Logic có trong mã cũng có thể rò rỉ khóa trong TEE trong các cuộc gọi bên ngoài. Ngoài ra, mã có thể chứa các cửa hậu hoặc lỗ hổng bảo mật. So với phát triển back-end truyền thống, nó đòi hỏi các tiêu chuẩn cao trong quy trình kiểm tra và phát triển phần mềm, tương tự như phát triển hợp đồng thông minh.

• Tấn công chuỗi cung ứng:Việc phát triển phần mềm hiện đại sử dụng một lượng lớn dữ liệu thứ ba -mã đảng. Các cuộc tấn công vào chuỗi cung ứng gây ra mối đe dọa đáng kể đối với tính toàn vẹn của TEE.

Lỗ hổng thời gian chạy

< p style="text-align: left;">Cho dù nhà phát triển có thận trọng đến đâu, họ vẫn có thể trở thành nạn nhân của các lỗ hổng trong thời gian chạy. Các nhà phát triển phải cân nhắc cẩn thận liệu bất kỳ điều nào sau đây có ảnh hưởng đến việc đảm bảo an ninh cho dự án của họ hay không:

• Mã động: Không phải lúc nào cũng có thể giữ tất cả mã trong suốt. Đôi khi bản thân trường hợp sử dụng yêu cầu thực thi động mã mờ được tải vào TEE khi chạy. Mã như vậy có thể dễ dàng tiết lộ bí mật hoặc phá vỡ các bất biến và phải hết sức cẩn thận để ngăn chặn điều này.

• Dữ liệu động:Được sử dụng bởi hầu hết các ứng dụng trong quá trình thực thi API bên ngoài và các nguồn dữ liệu khác. Mô hình bảo mật mở rộng để bao gồm các nguồn dữ liệu này, giống như các oracle trong DeFi, trong đó dữ liệu không chính xác hoặc thậm chí lỗi thời có thể dẫn đến thảm họa. Ví dụ: trong trường hợp sử dụng Tác nhân AI, có sự phụ thuộc quá mức vào các dịch vụ LLM, chẳng hạn như Claude.

• Giao tiếp không an toàn và không ổn định:TEE cần được đưa vào The Thành phần TEE chạy trong máy chủ. Từ góc độ bảo mật,máy chủ chạy TEE thực sự là trung gian hoàn hảo (MitM) giữa TEE và các tương tác bên ngoài. Máy chủ không chỉ có thể xem xét các kết nối gửi đi của TEE và xem những gì đang được gửi, nó còn có thể kiểm duyệt các IP cụ thể, hạn chế kết nối và đưa các gói vào kết nối với mục tiêu lừa một bên nghĩ rằng nó đến từ xx.

  Ví dụ: chạy công cụ so khớp trong TEE có thể xử lý các giao dịch tiền điện tử không thể mang lại đảm bảo đặt hàng công bằng (Anti -MEV) vì bộ định tuyến/cổng/máy chủ vẫn có thể loại bỏ, trì hoãn hoặc ưu tiên các gói dựa trên địa chỉ IP nguồn của chúng.

Lỗi kiến ​​trúc

Cần phải thận trọng với ngăn xếp công nghệ được các ứng dụng TEE sử dụng. Khi xây dựng ứng dụng TEE, các vấn đề sau có thể xảy ra:

• < strong>Ứng dụng có bề mặt tấn công lớn:Bề mặt tấn công của ứng dụng là số lượng mô-đun mã cần được bảo mật hoàn toàn. Mã có bề mặt tấn công lớn rất khó kiểm tra và có thể che giấu các lỗi hoặc lỗ hổng có thể khai thác được. Điều này cũng thường xung đột với trải nghiệm của nhà phát triển. Ví dụ: chương trình TEE dựa trên Docker có bề mặt tấn công lớn hơn nhiều so với chương trình TEE không dựa trên Docker. Các khu vực dựa trên hệ điều hành hoàn thiện có bề mặt tấn công lớn hơn các chương trình TEE sử dụng hệ điều hành nhẹ nhất

• Tính di động và tính sống động: Trong Web3, các ứng dụng phải có khả năng chống kiểm duyệt. Bất kỳ ai cũng có thể khởi động TEE và tiếp quản những người tham gia hệ thống không hoạt động cũng như tạo các ứng dụng trong TEE di động. Thách thức lớn nhất ở đây là tính di động chính. Một số hệ thống TEE có cơ chế phái sinh khóa được tích hợp sẵn, nhưng một khi cơ chế phái sinh khóa trong TEE được sử dụng, các máy chủ khác không thể tạo khóa cục bộ trong chương trình TEE bên ngoài. Điều này khiến chương trình TEE thường bị giới hạn ở cùng một máy chủ. không đủ để duy trì tính di động

• Gốc niềm tin không an toàn

  strong> : Ví dụ: chạy AI trong TEE Khi sử dụng Tác nhân, làm cách nào để xác minh xem một địa chỉ nhất định có thuộc về Tác nhân hay không? Nếu điều này không được thiết kế cẩn thận, nguồn gốc thực sự của sự tin cậy có thể là một bên thứ ba bên ngoài hoặc nền tảng ký quỹ quan trọng, chứ không phải chính TEE.

Vấn đề vận hành

Cuối cùng nhưng không kém phần quan trọng, có một số cân nhắc thực tế về cách chạy một máy chủ thực thi các chương trình TEE:

• Phiên bản nền tảng không an toàn: Nền tảng TEE thỉnh thoảng nhận được các bản cập nhật bảo mật, được phản ánh dưới dạng phiên bản nền tảng trong chứng thực từ xa. Nếu TEE của bạn không chạy trên phiên bản nền tảng an toàn, tin tặc có thể khai thác các vectơ tấn công đã biết để đánh cắp khóa từ TEE. Tệ hơn nữa, TEE của bạn có thể đang chạy trên phiên bản nền tảng an toàn hôm nay và không an toàn vào ngày mai.

• Không có bảo mật vật lý: Tuy nhiên, bất chấp những nỗ lực hết mình của bạn, TEE có thể bị tấn công kênh bên và những kẻ tấn công thường yêu cầu quyền truy cập và kiểm soát vật lý đối với máy chủ nơi đặt TEE. Vì vậy, an ninh vật lý là một lớp phòng thủ quan trọng theo chiều sâu. Một khái niệm liên quan là bằng chứng trên đám mây, nơi bạn có thể chứng minh rằng TEE đang chạy trong trung tâm dữ liệu đám mây và nền tảng đám mây có đảm bảo an ninh vật lý.

Xây dựng các chương trình TEE an toàn

Chúng tôi đã chia đề xuất của mình thành các điểm sau:

• Giải pháp an toàn nhất

• Các biện pháp phòng ngừa cần thiết cần thực hiện

• Các đề xuất dựa trên các trường hợp sử dụng

  < p>

1. Giải pháp an toàn nhất: không phụ thuộc vào bên ngoài

< p style ="căn chỉnh văn bản: left;">Việc tạo ra các ứng dụng có độ bảo mật cao có thể liên quan đến việc loại bỏ các phần phụ thuộc bên ngoài như đầu vào, API hoặc dịch vụ bên ngoài, từ đó làm giảm bề mặt tấn công. Cách tiếp cận này đảm bảo rằng ứng dụng hoạt động theo cách khép kín, không có tương tác bên ngoài nào có thể ảnh hưởng đến tính toàn vẹn hoặc bảo mật của ứng dụng. Mặc dù chiến lược này có thể hạn chế tính đa dạng chức năng của chương trình nhưng nó cung cấp mức độ bảo mật cực cao.

Mức bảo mật này có thể đạt được trong hầu hết các trường hợp sử dụng CryptoxAI nếu mô hình được chạy cục bộ.

2. Cần thực hiện các biện pháp phòng ngừa cần thiết

Bất kể trường hợp nào ứng dụng Cho dù chương trình có phụ thuộc bên ngoài hay không thì những điều sau đây là bắt buộc!

Hãy coi các ứng dụng TEE như hợp đồng thông minh thay vì các ứng dụng phụ trợ; giữ tần suất cập nhật ở mức thấp và kiểm tra nghiêm ngặt.

Việc xây dựng chương trình TEE phải nghiêm ngặt như việc viết, thử nghiệm và cập nhật hợp đồng thông minh. Giống như hợp đồng thông minh, TEE hoạt động trong một môi trường rất nhạy cảm và bất biến, trong đó các sai sót hoặc hành vi không mong muốn có thể dẫn đến hậu quả nghiêm trọng, bao gồm cả việc mất hoàn toàn tiền. Việc kiểm tra kỹ lưỡng, thử nghiệm rộng rãi và các bản cập nhật được kiểm tra cẩn thận, tối thiểu là rất quan trọng để đảm bảo tính toàn vẹn và độ tin cậy của các ứng dụng dựa trên TEE.

Kiểm tra mã và kiểm tra quy trình xây dựng

Tính bảo mật của ứng dụng không chỉ phụ thuộc vào chính mã mà còn phụ thuộc vào các công cụ được sử dụng trong quá trình xây dựng. Quy trình xây dựng an toàn là rất quan trọng để ngăn chặn các lỗ hổng. TEE chỉ đảm bảo rằng mã được cung cấp sẽ chạy như mong đợi nhưng không thể sửa các lỗi phát sinh trong quá trình xây dựng.

Để giảm thiểu rủi ro, mã phải được kiểm tra và kiểm tra nghiêm ngặt để loại bỏ lỗi và ngăn chặn rò rỉ thông tin không cần thiết. Hơn nữa, các bản dựng lặp lại đóng một vai trò quan trọng, đặc biệt khi mã được một bên phát triển và được một bên khác sử dụng. Các bản dựng có thể lặp lại cho phép mọi người xác minh rằng chương trình được thực thi trong TEE khớp với mã nguồn ban đầu, đảm bảo tính minh bạch và tin cậy. Nếu không có bản dựng có thể tái tạo, gần như không thể xác định nội dung chính xác của chương trình được thực thi trong TEE, do đó gây nguy hiểm cho tính bảo mật của ứng dụng.

Ví dụ: mã nguồn của DeepWorm (dự án chạy mô hình mô phỏng não sâu trong TEE) là hoàn toàn mở. Các bộ thực thi trong TEE được xây dựng theo cách có thể tái tạo bằng cách sử dụng các đường dẫn Nix.

Sử dụng thư viện đã được kiểm tra hoặc xác minh

Trong TEE Khi xử lý dữ liệu nhạy cảm trong chương trình của bạn, chỉ sử dụng các thư viện đã được kiểm tra để quản lý khóa và xử lý dữ liệu riêng tư. Các thư viện chưa được kiểm tra có thể làm lộ khóa và xâm phạm tính bảo mật của ứng dụng. Ưu tiên các phần phụ thuộc tập trung vào bảo mật, được kiểm tra kỹ lưỡng để duy trì tính bảo mật và tính toàn vẹn của dữ liệu.

Luôn xác minh bằng chứng từ TEE

Người dùng tương tác với TEE phải xác minh cơ chế xác minh hoặc chứng thực từ xa do TEE tạo ra để đảm bảo các tương tác an toàn và đáng tin cậy. Nếu không có những bước kiểm tra này, máy chủ có thể thao túng các phản hồi khiến nó không thể phân biệt giữa dữ liệu đầu ra TEE thực và dữ liệu giả mạo. Chứng thực từ xa cung cấp bằng chứng chính cho cơ sở mã và cấu hình đang chạy trong TEE. Dựa trên chứng thực từ xa, chúng tôi có thể xác định xem chương trình được thực thi trong TEE có phù hợp với mong đợi hay không.

Xác thực cụ thể có thể được xác minh trên chuỗi (IntelSGX, AWSNitro), ngoài chuỗi bằng chứng nhận ZK (IntelSGX, AWSNitro) hoặc bởi chính người dùng hoặc được lưu trữ service (chẳng hạn như t16z hoặc MarlinHub) để xác minh.

3. Đề xuất phụ thuộc vào trường hợp sử dụng

Tùy thuộc vào ứng dụng Trường hợp sử dụng mục tiêu của chương trình của bạn và cấu trúc của nó, các mẹo sau có thể giúp ứng dụng của bạn an toàn hơn.

Đảm bảo rằng tương tác của người dùng với TEE luôn được thực hiện trên kênh an toàn

Máy chủ đặt TEE vốn không đáng tin cậy. Máy chủ có thể chặn và sửa đổi thông tin liên lạc. Trong một số trường hợp, máy chủ có thể chấp nhận đọc dữ liệu nhưng không thay đổi dữ liệu đó, trong khi trong các trường hợp khác, ngay cả việc đọc dữ liệu cũng có thể là điều không mong muốn. Để giảm thiểu những rủi ro này, điều quan trọng là phải thiết lập kênh được mã hóa hai đầu an toàn giữa người dùng và TEE. Ít nhất, hãy đảm bảo tin nhắn có chữ ký để xác minh tính xác thực và nguồn gốc của nó. Ngoài ra,Người dùng cần phải luôn kiểm tra xem TEE có cung cấp chứng thực từ xa để xác minh rằng họ đang liên lạc với đúng TEE hay không. Điều này đảm bảo tính toàn vẹn và bảo mật của thông tin liên lạc.

Ví dụ: Oyster có thể hỗ trợ phát hành TLS an toàn thông qua việc sử dụng bản ghi CAA và RFC8657. Ngoài ra, nó còn cung cấp giao thức TLS gốc TEE có tên là Scallop, không dựa vào WebPKI.

Biết rằng trí nhớ TEE là nhất thời

Bộ nhớ TEE là tạm thời, có nghĩa là nội dung của nó (bao gồm cả khóa mã hóa) sẽ bị mất khi tắt TEE. Nếu không có cơ chế bảo mật để lưu giữ thông tin này, dữ liệu quan trọng có thể vĩnh viễn không thể truy cập được, có khả năng làm tê liệt quỹ hoặc hoạt động.

Mạng tính toán nhiều bên (MPC) với hệ thống lưu trữ phi tập trung như IPFS có thể được sử dụng như một giải pháp cho vấn đề này. Mạng MPC phân chia khóa trên nhiều nút, đảm bảo rằng không có nút nào giữ toàn bộ khóa đồng thời cho phép mạng xây dựng lại khóa khi cần. Dữ liệu được mã hóa bằng khóa này có thể được lưu trữ an toàn trên IPFS.

Nếu được yêu cầu, mạng MPC có thể cung cấp khóa cho các máy chủ TEE mới chạy cùng một hình ảnh, miễn là đáp ứng một số điều kiện nhất định. Cách tiếp cận này đảm bảo khả năng phục hồi và bảo mật mạnh mẽ, giữ cho dữ liệu có thể truy cập và bảo mật ngay cả trong môi trường không đáng tin cậy.

Có một giải pháp khác,đó là TEE sẽ lần lượt bàn giao các giao dịch liên quan đến các máy chủ MPC khác nhau. Sau khi máy chủ MPC ký, nó sẽ tổng hợp chữ ký và cuối cùng đưa giao dịch lên chuỗi. Phương pháp này kém linh hoạt hơn nhiều và không thể sử dụng để lưu khóa API, mật khẩu hoặc dữ liệu tùy ý (không có dịch vụ lưu trữ đáng tin cậy của bên thứ ba).

Giảm bề mặt tấn công

Đối với các trường hợp sử dụng quan trọng về bảo mật, điều này đáng để thử với chi phí của nhà phát triển kinh nghiệm Giảm càng nhiều phụ thuộc ngoại vi càng tốt. Ví dụ: Dstack cung cấp hạt nhân dựa trên Yocto tối thiểu chỉ chứa các mô-đun cần thiết để Dstack hoạt động. Thậm chí có thể đáng sử dụng công nghệ cũ hơn như SGX (trên TDX) vì công nghệ đó không yêu cầu bộ tải khởi động hoặc hệ điều hành trở thành một phần của TEE.

Cách ly vật lý

Bằng cách kết hợp TEE với Sự cách ly về mặt vật lý khỏi sự can thiệp của con người có thể nâng cao hơn nữa sự an toàn của TEE. Mặc dù chúng tôi có thể lưu trữ máy chủ TEE trong trung tâm dữ liệu và nhà cung cấp đám mây, nhưng chúng tôi tin rằng trung tâm dữ liệu có thể cung cấp bảo mật vật lý. Nhưng các dự án như Spacecoin đang khám phá một giải pháp thay thế khá thú vị - không gian. Bài báo của SpaceTEE dựa vào các biện pháp an toàn, chẳng hạn như đo mômen quán tính sau khi phóng, để xác minh xem vệ tinh có đi chệch khỏi mong đợi trong quá trình đi vào quỹ đạo hay không.

Nhiều người chứng minh

Giống như Ethereum dựa vào nhiều Just vì việc triển khai máy khách giúp giảm nguy cơ lỗi ảnh hưởng đến toàn bộ mạng, nên các nhà cung cấp đa dịch vụ sẽ sử dụng các cách triển khai TEE khác nhau để cải thiện tính bảo mật và khả năng phục hồi. Bằng cách chạy các bước tính toán giống nhau trên nhiều nền tảng TEE, tính năng xác thực đa dạng đảm bảorằng lỗ hổng trong một lần triển khai TEE không ảnh hưởng đến toàn bộ ứng dụng. Mặc dù cách tiếp cận này yêu cầu quá trình tính toán phải mang tính xác định hoặc xác định sự đồng thuận giữa các triển khai TEE khác nhau trong các tình huống không xác định, nhưng nó cũng mang lại những lợi thế đáng kể như cách ly lỗi, dự phòng và xác thực chéo, khiến nó trở thành một giải pháp đáng tin cậy khi có một lựa chọn tốt cho một ứng dụng đảm bảo tình dục.

Hướng tới tương lai

TEE rõ ràng đã trở thành một lĩnh vực rất thú vị. Như đã đề cập trước đó, tính phổ biến của AI và khả năng tiếp tục truy cập vào dữ liệu nhạy cảm của người dùng có nghĩa là các công ty công nghệ lớn như Apple và NVIDIA đang sử dụng TEE trong các sản phẩm của họ và cung cấp TEE như một phần sản phẩm của họ.

Mặt khác, cộng đồng mã hóa luôn rất chú trọng đến bảo mật. Khi các nhà phát triển cố gắng mở rộng các ứng dụng và trường hợp sử dụng trên chuỗi, chúng tôi nhận thấy TEE trở nên phổ biến như một giải pháp mang lại sự cân bằng phù hợp giữa chức năng và các giả định về độ tin cậy. Mặc dù TEE không giảm thiểu độ tin cậy như một giải pháp ZK đầy đủ, nhưng chúng tôi hy vọng TEE sẽ là con đường đầu tiên để tích hợp từ từ các sản phẩm từ các công ty Web3 và các công ty công nghệ lớn.