Tác giả: prateek, roshan, siddhartha & linguine (Marlin), krane (Asula)Biên dịch: Shew, Realm Thần Thánh X
Từ khi Apple thông báo ra mắt điện toán đám mây riêng và NVIDIA cung cấp tính toán bí mật trong GPU, môi trường thực thi đáng tin cậy (TEE) đã trở nên ngày càng phổ biến. Sự đảm bảo bí mật của chúng giúp bảo vệ dữ liệu người dùng (bao gồm cả khóa riêng tư), trong khi tính cách ly đảm bảo rằng việc thực thi chương trình trên nó không bị thay đổi - bất kể là người dùng, chương trình khác hoặc hệ điều hành. Do đó, không có gì ngạc nhiên khi trong lĩnh vực Crypto x AI có rất nhiều sản phẩm được xây dựng bằng TEE.
Như bất kỳ công nghệ mới nào, TEE đang trải qua một giai đoạn thử nghiệm lạc quan. Bài viết này nhằm cung cấp một hướng dẫn cơ bản về khái niệm cho các nhà phát triển và độc giả chung, giúp họ hiểu rõ TEE là gì, mô hình bảo mật của TEE, các lỗ hổng phổ biến và cách sử dụng TEE an toàn nhất. * (Lưu ý *: Để làm cho văn bản dễ hiểu, chúng tôi có ý thức thay thế các thuật ngữ TEE bằng các từ đồng nghĩa đơn giản hơn).
TEE là gì
TEE là môi trường cô lập trong bộ xử lý hoặc trung tâm dữ liệu, trong đó chương trình có thể chạy mà không bị ảnh hưởng bởi bất kỳ phần còn lại của hệ thống. Để tránh TEE bị can thiệp bởi các phần khác, 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, tức là kiểm soát việc truy cập của các phần còn lại của hệ thống vào các chương trình và dữ liệu trong TEE. Hiện nay, TEE có mặt khắp mọi nơi trên điện thoại di động, máy chủ, PC và môi trường đám mây, do đó rất dễ truy cập và giá cả hợp lý.
Nội dung trên có thể nghe có vẻ mơ hồ và trừu tượng, thực tế, các máy chủ và nhà cung cấp đám mây khác nhau triển khai TEE theo cách khác nhau, nhưng mục đích cơ bản là để tránh TEE bị can thiệp bởi các chương trình khác.
Đa số độc giả có thể sử dụng thông tin nhận dạng sinh học để đăng nhập thiết bị, chẳng hạn như mở khóa điện thoại bằng vân tay. Nhưng làm thế nào để đảm bảo ứng dụng độc hại, trang web hoặc hệ điều hành jailbreak không thể truy cập và đánh cắp thông tin nhận dạng sinh học này? Trên thực tế, ngoài việc mã hóa dữ liệu, mạch trên thiết bị TEE hoàn toàn không cho phép bất kỳ chương trình nào truy cập khu vực bộ nhớ và bộ xử lý mà dữ liệu nhạy cảm chiếm giữ.
Ví cứng là một ví dụ khác về ứng dụng TEE. Ví cứng được kết nối với máy tính và giao tiếp với nó thông qua hộp cát, nhưng máy tính không thể truy cập trực tiếp vào từ khóa ghi nhớ được lưu trữ trong ví cứng. Trong cả hai trường hợp trên, người dùng đều tin tưởng rằng nhà sản xuất thiết bị có thể thiết kế chíp đúng cách và cung cấp các bản cập nhật firmware thích hợp để ngăn chặn dữ liệu bí mật trong TEE bị xuất khẩu hoặc xem.
mô hình an toàn
Rất tiếc, có rất nhiều loại TEE được triển khai, những triển khai khác nhau này (IntelSGX, IntelTDX, AMDSEV, AWSNitroEnclaves, ARMTrustZone) đều yêu cầu mô hình bảo mật riêng biệt cho phân tích và xây dựng. Trong phần còn lại của bài viết này, chúng tôi sẽ tập trung thảo luận chính về IntelSGX, TDX và AWSNitro, vì những hệ thống TEE này có nhiều người dùng hơn và có các công cụ phát triển đầy đủ và sẵn có. Những hệ thống trên cũng là những hệ thống TEE phổ biến nhất trong Web3.
Nhìn chung, quy trình làm việc của các ứng dụng triển khai trong TEE như sau:
Những “nhà phát triển” đã viết một số mã nguồn mở hoặc có thể không
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.
EIF được lưu trữ trên một 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 và cung cấp dịch vụ ra bên ngoài.
Người dùng có thể tương tác với ứng dụng thông qua giao diện được định nghĩa trước.
Rõ ràng, có 3 rủi ro tiềm tàng ở đây:
Nhà phát triển: Mục đích của việc chuẩn bị mã EIF là gì? Mã EIF có thể không phù hợp với logic kinh doanh của dự án được công bố công khai, có thể đánh cắp dữ liệu riêng tư của người dùng
Máy chủ: TEE máy chủ có chạy tệp EIF như dự kiến không? Hoặc liệu EIF có thực sự được thực thi trong TEE không? 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 sau nào để rò rỉ dữ liệu trong TEE cho nhà cung cấp không?
May mắn thay, hiện nay TEE đã có giải pháp để loại bỏ các rủi ro trên, đó là xây dựng có thể tái tạo(Reproducible Builds) và chứng nhận từ xa(Remote Atteststations).
Vậy làm thế nào để xây dựng có thể lặp lại? Phát triển phần mềm hiện đại thường yêu cầu nhập rất nhiều phụ thuộc, chẳng hạn như công cụ, thư viện hoặc framework bên ngoài và các tệp phụ thuộc này cũng có thể có các vấn đề tiềm ẩn. Hiện nay, các giải pháp như npm sử dụng mã băm của tệp phụ thuộc như một định danh duy nhất. Khi npm phát hiện rằng một tệp phụ thuộc không khớp với giá trị băm được ghi lại, nó có thể cho rằng tệp phụ thuộc đã bị chỉnh sửa.
Còn có thể xây dựng có thể được coi là một tập hợp tiêu chuẩn, mục tiêu là khi bất kỳ mã nào chạy trên bất kỳ thiết bị nào, chỉ cần tuân theo quy trình đã được xác định trước, cuối cùng sẽ nhận được giá trị băm nhất quán. Tất nhiên, trong thực tế, chúng ta cũng có thể sử dụng các sản phẩm bên ngoài giá trị băm như là các định danh, chúng ta gọi là đo lường mã (code measurement).
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 bị lộ, 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 bất cứ điều gì bất thường và bất kỳ ai cũng có thể xây dựng mã bằng Nix để kiểm tra xem sản phẩm được xây dựng có cùng số liệu mã / hàm băm với sản phẩm được nhóm dự án triển khai trong sản xuất hay không. Nhưng làm thế nào để chúng ta biết các số liệu mã cho một chương trình trong TEE? Điều này đưa chúng ta đến khái niệm gọi là "bằng chứng từ xa". **
Chứng thực từ xa là tin nhắn được ký từ nền tảng TEE (bên tin cậy), trong đó chứa các giá trị đo lường mã code của chương trình, phiên bản của nền tảng TEE, v.v. Chứng thực từ xa giúp người quan sát bên ngoài biết rằng một chương trình đang chạy trong một vị trí an toàn mà không ai có thể truy cập (TEE thực sự phiên bản xx).
Việc xây dựng có thể lặp lại và chứng minh từ xa cho phép bất kỳ người dùng nào biết mã nguồn thực tế và phiên bản nền tảng TEE đang chạy trong TEE, từ đó ngăn chặn các nhà phát triển hoặc máy chủ có hành vi xấu.
Tuy nhiên, trong trường hợp TEE, luôn cần phải tin tưởng nhà cung cấp của nó. Nếu nhà cung cấp TEE gian lận, có thể trực tiếp tạo ra chứng chỉ từ xa giả mạo. Do đó, nếu coi nhà cung cấp là một phương tiện tấn công có thể xảy ra, nên tránh chỉ phụ thuộc vào TEE, tốt nhất là kết hợp chúng với ZK hoặc giao thức đồng thuận.
Sức hút của TEE
The TEE's popularity, especially its deployment friendliness for AI Agents, is mainly due to the following features in our opinion:
**Hiệu năng: **TEE có thể chạy mô hình LLM với hiệu năng và chi phí tương tự như máy chủ thông thường. **Trong khi đó, zkML yêu cầu sử dụng nhiều sức mạnh tính toán để tạo ra chứng minh zk cho LLM.
Hỗ trợ GPU：NVIDIA cung cấp hỗ trợ tính toán TEE trong loạt GPU mới nhất của mình (Hopper, Blackwell, vv.)
Độ chính xác : LLMs là không xác định; nhập cùng một từ gợi ý nhiều lần sẽ cho kết quả khác nhau. Do đó, nhiều nút (bao gồm cả những người quan sát cố gắng tạo ra bằng chứng gian lận) có thể không bao giờ đạt được sự thống nhất về kết quả chạy của LLM. Trong các tình huống như vậy, chúng ta có thể tin tưởng rằng LLM chạy trong TEE không thể bị kẻ xấu can thiệp, chương trình trong TEE sẽ luôn chạy theo cách đã viết, điều này khiến cho TEE phù hợp hơn opML hoặc sự thống nhất để đảm bảo tính đáng tin cậy của kết quả suy luận của LLM
Bảo mật: Dữ liệu trong TEE không thể nhìn thấy từ các chương trình bên ngoài. Do đó, các khóa riêng tư được tạo ra hoặc nhận vào trong TEE luôn được bảo mật. Tính năng này có thể đảm bảo cho người dùng rằng bất kỳ tin nhắn nào được ký bằng khóa này đều đến từ các chương trình nội bộ của TEE. Người dùng có thể an tâm giao khóa riêng tư cho TEE và thiết lập một số điều kiện ký, và có thể xác nhận chữ ký từ TEE đáp ứng các điều kiện ký trước đã định sẵn
Kết nối mạng: Các chương trình chạy trong TEE có thể truy cập Internet một cách an toàn thông qua một số công cụ (không cần tiết lộ truy vấn hoặc phản hồi cho máy chủ chạy trong TEE, đồng thời vẫn đảm bảo cung cấp dữ liệu truy xuất chính xác cho bên thứ ba). Đ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 để giao việc tính toán cho nhà cung cấp mô hình tin cậy và độc quyền.
Quyền ghi: Trái ngược với phương án zk, mã chạy trong TEE có thể xây dựng tin nhắn (cả tweet lẫn giao dịch) và gửi chúng đi qua mạng lưới API và RPC
Thân thiện với nhà phát triển: Các framework và SDK liên quan đến TEE cho phép viết mã bằng bất kỳ ngôn ngữ nào và dễ dàng triển khai chương trình vào TEE giống như trên máy chủ đám mây
Hiện tại, rất khó tìm thấy các giải pháp thay thế cho các trường hợp sử dụng TEE, dù tốt hay xấu. Chúng tôi tin rằng việc giới thiệu TEE sẽ mở rộng thêm không gian phát triển ứng dụng trên chuỗi khối và 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
Chương trình chạy trong TEE vẫn dễ bị ảnh hưởng bởi một loạt các cuộc tấn công và lỗi. Giống như hợp đồng thông minh, chúng dễ gặp phải một loạt vấn đề. Để đơn giản, chúng ta sẽ phân loại lỗ hổng có thể như sau:
Nhà phát triển đã lơ là
Lỗ hổng thời gian chạy
Lỗi thiết kế kiến trúc
Vấn đề vận hành
Sơ suất của nhà phát triển
Dù có ý đồ hay không, nhà phát triển có thể yếu đi sự bảo đảm an ninh của chương trình trong TEE thông qua mã có ý đồ hoặc không có ý đồ. Điều này bao gồm:
**Mã không minh bạch: ** Mô hình an ninh TEE phụ thuộc vào tính minh bạch của bên ngoài. Tính minh bạch của mã là rất quan trọng đối với việc xác minh của bên thứ ba từ bên ngoài.
Vấn đề về đo lường mã nguồn: Ngay cả khi mã nguồn là công khai, nếu không có bên thứ ba xây dựng lại mã và kiểm tra giá trị đo lường của mã trong bằng chứng từ xa và thực hiện kiểm tra dựa trên giá trị đo lường mã được cung cấp trong bằng chứng từ xa. Điều này tương tự như nhận được chứng cứ zk nhưng không xác minh nó.
Mã không an toàn: Ngay cả khi bạn cẩn thận tạo và quản lý khóa trong TEE đúng cách, có thể có logic trong mã gọi từ bên ngoài mà có thể tiết lộ khóa trong TEE. Ngoài ra, mã có thể chứa cửa sau hoặc lỗ hổng. So với phát triển backend truyền thống, nó đòi hỏi quy trình phát triển và kiểm toán phần mềm có tiêu chuẩn cao, tương tự như phát triển hợp đồng thông minh.
Tấn công chuỗi cung ứng: Phát triển phần mềm hiện đại sử dụng rất nhiều mã nguồn thứ ba. Tấn công chuỗi cung ứng đe dọa tính toàn vẹn của TEE một cách nghiêm trọng.
Lỗ hổng thời gian chạy
Ngay cả những nhà phát triển cẩn thận cũng có thể trở thành nạn nhân của lỗ hổng thời gian chạy. Nhà phát triển phải cân nhắc kỹ xem bất kỳ yếu tố nào dưới đây có ảnh hưởng đến bảo đảm an ninh của dự án hay không:
Mã động: Không phải lúc nào cũng có thể giữ cho tất cả mã nguồn là minh bạch. Đôi khi, trường hợp sử dụng yêu cầu chính nó thực thi mã không minh bạch được tải vào TEE trong thời gian chạy. Mã không minh bạch này dễ dàng tiết lộ thông tin bí mật hoặc phá vỡ tính không đổi và cần phải cẩn thận ngăn chặn tình huống này.
Dữ liệu động: Đa số ứng dụng sử dụng API bên ngoài và nguồn dữ liệu khác trong quá trình thực thi. Mô hình an toàn mở rộng để bao gồm các nguồn dữ liệu này, các nguồn dữ liệu này có cùng vị trí với các dự đoán trong DeFi, dữ liệu không chính xác hoặc lỗi thời có thể dẫn đến thảm họa. Ví dụ, trong trường hợp sử dụng AI Agent, quá phụ thuộc vào dịch vụ LLM như Claude.
Giao tiếp không an toàn và không ổn định: TEE cần chạy trong máy chủ chứa thành phần TEE. Về mặt an ninh, máy chủ chạy TEE thực tế là trung gian hoàn hảo giữa TEE và giao tiếp bên ngoài (MitM). Máy chủ không chỉ có thể xem xét kết nối bên ngoài của TEE và xem nội dung đang được gửi, mà còn có thể kiểm tra IP cụ thể, hạn chế kết nối và tiêm gói dữ liệu vào kết nối, nhằm mục đích lừa đảo một bên khiến nó tin rằng nó đến từ xx.
Ví dụ, trong TEE có thể chạy một bộ máy phù hợp để xử lý giao dịch mã hóa, bộ máy này không thể đảm bảo sắp xếp công bằng (chống MEV) vì bộ định tuyến/cổng truy cập/máy chủ vẫn có thể loại bỏ, trì hoãn hoặc ưu tiên xử lý dựa trên địa chỉ IP nguồn của gói tin.
Lỗ hổng kiến trúc
Các công nghệ mà ứng dụng TEE sử dụng nên được sử dụng cẩn thận. Khi xây dựng ứng dụng TEE, có thể phát sinh các vấn đề sau:
**Ứng dụng có bề dày tấn công lớn: **Bề dày tấn công của ứng dụng đề cập đến số lượng module mã nguồn cần đảm bảo an toàn hoàn toàn. Mã nguồn có bề dày tấn công lớn rất khó để kiểm định và có thể ẩn bug hoặc lỗ hổng có thể tận dụng. Điều này thường xung đột với trải nghiệm của các nhà phát triển. Ví dụ, so với các chương trình TEE không phụ thuộc vào Docker, các chương trình TEE phụ thuộc vào Docker có bề dày tấn công lớn hơn nhiều. So với các chương trình TEE sử dụng hệ điều hành siêu nhẹ, Enclaves phụ thuộc vào hệ điều hành trưởng thành có bề dày tấn công lớn hơn.
Độ di động và tính sẵn sàng: Trong Web3, ứ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 các thành viên hệ thống không hoạt động và làm cho ứng dụng trong TEE có thể di động. **Thách thức lớn nhất ở đây là tính di động của khóa. Một số hệ thống TEE có cơ chế phân phối khóa, nhưng một khi đã sử dụng cơ chế phân phối khóa trong TEE, thì các máy chủ khác sẽ không thể tạo ra khóa bên trong ứng dụng TEE bên ngoài địa phương, ** điều này làm cho các chương trình TEE thường chỉ giới hạn trong cùng một máy tính, điều này không đủ để duy trì tính di động.
RỄ NIỀM TIN KHÔNG AN TOÀN：Ví dụ, khi chạy AI Agent trong TEE, làm thế nào để xác minh địa chỉ cụ thể có thuộc về Agent đó không? Nếu không thiết kế cẩn thận ở đây, có thể dẫn đến việc Rễ niềm tin thực sự có thể là bên thứ ba hoặc nền tảng lưu trữ khóa bên ngoài, chứ không phải là TEE chính nó.
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ố điểm lưu ý thực tế về cách vận hành một máy chủ thực thi chương trình TEE:
Phiên bản nền tảng không an toàn: Đôi khi nền tảng TEE sẽ nhận được cập nhật bảo mật, những cập nhật này sẽ được phản ánh dưới dạng phiên bản nền tảng trong chứng minh 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, kẻ tấn công có thể tận dụng các phương tiện 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ể chạy trên phiên bản nền tảng an toàn hôm nay, nhưng ngày mai có thể đã không an toàn.
Không có an ninh vật lý: Mặc dù bạn đã cố gắng hết sức, nhưng TEE có thể bị tấn công theo phương thức kênh phụ, điều này thường đòi hỏi truy cập vật lý và kiểm soát vào máy chủ chứa TEE. Do đó, an ninh vật lý là một tầng phòng thủ sâu quan trọng. Một khái niệm liên quan là chứng minh đám mây, 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ó bảo đảm an ninh vật lý.
Xây dựng chương trình TEE an toàn
Chúng tôi sẽ chia đề xuất của chúng tôi thành các điểm sau đây:
Giải pháp an toàn nhất
các biện pháp phòng ngừa cần thiết
Dựa vào các đề xuất của trường hợp sử dụng
1. Giải pháp an toàn nhất: không có phụ thuộc vào bên ngoại
Việc tạo ứng dụng an toàn cao có thể liên quan đến việc loại bỏ các phụ thuộc bên ngoài như đầu vào bên ngoài, API hoặc dịch vụ, từ đó giảm thiểu diện tích tấn công. Phương pháp này đảm bảo ứng dụng chạy độc lập mà không có tương tác bên ngoài có thể làm hỏng tính toàn vẹn hoặc an toàn của nó. 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ó có thể cung cấp mức độ an toàn rất cao.
Nếu mô hình được chạy cục bộ, thì độ an toàn ở mức này có thể được đảm bảo cho hầu hết các trường hợp sử dụng của CryptoxAI.
2. Các biện pháp phòng ngừa cần thiết
Dù ứng dụng có phụ thuộc vào các thành phần bên ngoài hay không, những nội dung sau đây là bắt buộc!
Xem ứng dụng TEE như một hợp đồng thông minh thay vì ứng dụng backend; duy trì tần suất cập nhật thấp, kiểm thử nghiêm ngặt.
Xây dựng chương trình TEE phải được thực hiện một cách nghiêm ngặt như việc viết, kiểm tra 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à không thể bị sửa đổi, trong đó lỗi 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 việc mất hoàn toàn tiền tệ. Kiểm toán toàn diện, kiểm tra rộng rãi và ít nhất là cập nhật được kiểm toán cẩn thận là cực kỳ quan trọng để đảm bảo tính toàn vẹn và đáng tin cậy của các ứng dụng dựa trên TEE.
Kiểm tra mã kiểm toán và kiểm tra đường ống xây dựng
Độ an toàn của ứng dụng không chỉ phụ thuộc vào mã nguồn chính nó, 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 lỗ hổng. TEE chỉ đảm bảo mã nguồn cung cấp sẽ chạy theo quy trình dự kiến, nhưng không thể sửa chữa các lỗi được giới thiệu trong quá trình xây dựng.
Để giảm thiểu rủi ro, việc kiểm tra và kiểm toán mã nguồn một cách nghiêm ngặt là cần thiết để loại bỏ lỗi và ngăn chặn rò rỉ thông tin không cần thiết. Ngoài ra, quá trình xây dựng có thể lặp lại đóng vai trò quan trọng, đặc biệt là khi mã nguồn được phát triển bởi một bên và sử dụng bởi một bên khác. Quá trình xây dựng có thể lặp lại cho phép bất kỳ ai kiểm tra xem chương trình được thực thi trong TEE có khớp với mã nguồn gốc hay không, đảm bảo tính minh bạch và tin cậy. Nếu không có quá trình xây dựng có thể lặp lại, việc xác định nội dung chính xác của chương trình được thực thi trong TEE là gần như không thể, đe dọa tính an toàn của ứng dụng.
Ví dụ, mã nguồn của dự án DeepWorm (một mô hình mô phỏng não giun chạy trong TEE) là hoàn toàn công khai. Chương trình thực thi trong TEE được xây dựng một cách tái lập bằng Nix pipeline.
Sử dụng thư viện đã được kiểm toán hoặc xác minh
Trong quá trình xử lý dữ liệu nhạy cảm trong chương trình TEE, chỉ sử dụng thư viện đã được kiểm toán để quản lý khóa và xử lý dữ liệu riêng tư. Thư viện chưa được kiểm toán có thể tiết lộ khóa và đe dọa tính bảo mật của ứng dụng. Ưu tiên các phần phụ thuộc đã được kiểm tra kỹ càng, tập trung vào an ninh để duy trì tính bí mật và toàn vẹn của dữ liệu.
Luôn xác minh chứng chỉ từ TEE
Người dùng tương tác với TEE phải xác minh bằng chứng từ xa hoặc cơ chế xác minh mà TEE tạo ra để đảm bảo tương tác an toàn và đáng tin cậy. Nếu thiếu các kiểm tra này, máy chủ có thể can thiệp vào phản hồi, dẫn đến khó phân biệt giữa đầu ra TEE thực và dữ liệu bị sửa đổi. Chứng từ từ xa cung cấp bằng chứng quan trọng về thư viện mã và cấu hình được thực thi trong TEE, giúp chúng ta đánh giá xem chương trình đang chạy trong TEE có khớp với dự kiến hay không.
Chứng thực cụ thể có thể được thực hiện trên chuỗi (IntelSGX, AWSNitro), sử dụng chứng minh ZK (IntelSGX, AWSNitro) để xác minh ngoại chuỗi, hoặc có thể được xác minh bởi người dùng hoặc dịch vụ lưu trữ (như t16z hoặc MarlinHub).
Lời khuyên dựa trên trường hợp sử dụng
Dựa trên các trường hợp sử dụng mục tiêu của ứng dụng và cấu trúc của nó, những gợi ý sau có thể giúp làm cho ứng dụng của bạn an toàn hơn.
Đảm bảo luôn thực hiện tương tác người dùng với TEE trên kênh an toàn
Máy chủ chứa TEE về bản chất không được tin cậy. Máy chủ có thể chặn và sửa đổi giao tiếp. Trong một số trường hợp, việc máy chủ đọc dữ liệu nhưng không thay đổi dữ liệu có thể chấp nhận được, trong khi trong các trường hợp khác, việc đọc dữ liệu có thể không chấp nhận được. Để giảm thiểu những rủi ro này, việc thiết lập kênh mã hóa đầu cuối an toàn giữa người dùng và TEE là rất quan trọng. Ít nhất, hãy đảm bảo tin nhắn bao gồm chữ ký để xác minh tính chính xác và nguồn gốc của nó. Ngoài ra, người dùng cần luôn kiểm tra chứng minh từ xa mà TEE cung cấp để xác minh liệu họ đang truyền thông với TEE đúng hay không. Điều này đảm bảo tính toàn vẹn và tính bảo mật của giao tiếp.
Ví dụ, Oyster có thể hỗ trợ phát hành TLS an toàn bằng cách sử dụng bản ghi CAA và RFC8657. Ngoài ra, nó còn cung cấp một giao thức TLS cơ bản TEE có tên Scallop, không phụ thuộc vào WebPKI.
Biết rằng bộ nhớ TEE là tạm thời
Bộ nhớ TEE là tạm thời, điều này có nghĩa là khi TEE tắt, nội dung của nó (bao gồm cả khóa mã hóa) sẽ bị mất. Nếu không có cơ chế an toàn để lưu trữ thông tin này, dữ liệu quan trọng có thể trở nên không thể truy cập vĩnh viễn, gây khó khăn cho vốn tiền hoặc hoạt động.
Mạng tính toán đa phương tiện (MPC) với hệ thống lưu trữ phi tập trung như IPFS có thể được sử dụng làm giải pháp cho vấn đề này. Mạng MPC chia khóa thành nhiều nút để đảm bảo không có một nút đơn lẻ nào giữ toàn bộ khóa, đồng thời cho phép mạng tái tạo khóa khi cần thiết. 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ần, mạng MPC có thể cung cấp khóa cho máy chủ TEE mới chạy cùng hình ảnh, với điều kiện cụ thể. Phương pháp này đảm bảo tính linh hoạt và an ninh mạnh mẽ, giữ cho dữ liệu có thể truy cập và bí mật ngay cả trong môi trường không tin cậy.
Còn một giải pháp khác, đó là TEE sẽ chia các giao dịch liên quan cho các máy chủ MPC khác nhau, MPC server sẽ ký tên và ký tập hợp các giao dịch trước khi đưa chúng lên chuỗi. Phương pháp này có độ linh hoạt thấp hơn và không thể được sử dụng để lưu trữ khóa API, mật khẩu hoặc bất kỳ dữ liệu nào khác (không có dịch vụ lưu trữ của bên thứ ba đáng tin cậy).
Giảm diện tích tấn công
Đối với các trường hợp sử dụng quan trọng về an ninh, đáng giá để thử nghiệm việc giảm thiểu phụ thuộc ngoại vi một cách tối đa, thậm chí là với sự hy sinh trải nghiệm phát triển của nhà phát triển. Ví dụ, Dstack đi kèm với một nhân cơ bản dựa trên Yocto chỉ bao gồm các module cần thiết để Dstack hoạt động. Đôi khi có thể xứng đáng sử dụng các công nghệ cũ như SGX (hơn cả TDX) vì công nghệ này không cần trở thành một phần của TEE trong quá trình khởi động hoặc hệ điều hành.
Cách ly vật lý
Bằng cách cách ly vật lý TEE khỏi sự can thiệp con người có thể xảy ra, có thể tăng cường độ an toàn của TEE. Mặc dù chúng ta có thể tin tưởng rằng việc đặt máy chủ TEE tại trung tâm dữ liệu và nhà cung cấp đám mây có thể đảm bảo an ninh vật lý, nhưng 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 SpaceTEE dựa trên các biện pháp bảo mật như đo đạc moment quán tính sau khi phóng, để xác minh liệu vệ tinh có lệch khỏi dự đoán trong quá trình nhập vào quỹ đạo hay không.
Người chứng minh đa quyền
Giống như Ethereum phụ thuộc vào nhiều phiên bản khách hàng để giảm thiểu rủi ro lỗi ảnh hưởng đến toàn bộ mạng, multiprovers sử dụng các giải pháp triển khai TEE khác nhau để nâng cao tính bảo mật và linh hoạt. 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 khác nhau, việc xác thực đa lớp đảm bảo rằng lỗi trong một triển khai TEE không đe dọa toàn bộ ứng dụng. Mặc dù phương pháp này đòi hỏi quá trình tính toán là xác định, hoặc định nghĩa sự nhất trí giữa các triển khai TEE khác nhau trong trường hợp không xác định, nhưng nó cũng cung cấp nhiều lợi ích đáng kể như cách ly lỗi, dự phòng và xác thực chéo, làm cho nó trở thành một lựa chọn tốt cho các ứng dụng đòi hỏi đảm bảo đáng tin cậy.
Nhìn vào 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 đó, sự phổ biến của AI và quyền truy cập liên tục 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 của dịch vụ của họ.
Mặt khác, cộng đồng mã hóa luôn chú trọng đến an ninh. 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 ta đã thấy TEE trở nên phổ biến như một giải pháp cân bằng đúng giữa tính năng và giả định tin tưởng. Mặc dù TEE không tối giản hóa niềm tin như một giải pháp ZK đầy đủ, nhưng chúng tôi dự đoán rằng TEE sẽ trở thành cách tiếp cận đầu tiên để từ từ kết hợp sản phẩm của các công ty Web3 và các công ty công nghệ lớn.
Nội dung chỉ mang tính chất tham khảo, không phải là lời chào mời hay đề nghị. Không cung cấp tư vấn về đầu tư, thuế hoặc pháp lý. Xem Tuyên bố miễn trừ trách nhiệm để biết thêm thông tin về rủi ro.
Hướng dẫn cho nhà phát triển hướng TEE
Tác giả: prateek, roshan, siddhartha & linguine (Marlin), krane (Asula)Biên dịch: Shew, Realm Thần Thánh X
Từ khi Apple thông báo ra mắt điện toán đám mây riêng và NVIDIA cung cấp tính toán bí mật trong GPU, môi trường thực thi đáng tin cậy (TEE) đã trở nên ngày càng phổ biến. Sự đảm bảo bí mật của chúng giúp bảo vệ dữ liệu người dùng (bao gồm cả khóa riêng tư), trong khi tính cách ly đảm bảo rằng việc thực thi chương trình trên nó không bị thay đổi - bất kể là người dùng, chương trình khác hoặc hệ điều hành. Do đó, không có gì ngạc nhiên khi trong lĩnh vực Crypto x AI có rất nhiều sản phẩm được xây dựng bằng TEE.
Như bất kỳ công nghệ mới nào, TEE đang trải qua một giai đoạn thử nghiệm lạc quan. Bài viết này nhằm cung cấp một hướng dẫn cơ bản về khái niệm cho các nhà phát triển và độc giả chung, giúp họ hiểu rõ TEE là gì, mô hình bảo mật của TEE, các lỗ hổng phổ biến và cách sử dụng TEE an toàn nhất. * (Lưu ý *: Để làm cho văn bản dễ hiểu, chúng tôi có ý thức thay thế các thuật ngữ TEE bằng các từ đồng nghĩa đơn giản hơn).
TEE là gì
TEE là môi trường cô lập trong bộ xử lý hoặc trung tâm dữ liệu, trong đó chương trình có thể chạy mà không bị ảnh hưởng bởi bất kỳ phần còn lại của hệ thống. Để tránh TEE bị can thiệp bởi các phần khác, 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, tức là kiểm soát việc truy cập của các phần còn lại của hệ thống vào các chương trình và dữ liệu trong TEE. Hiện nay, TEE có mặt khắp mọi nơi trên điện thoại di động, máy chủ, PC và môi trường đám mây, do đó rất dễ truy cập và giá cả hợp lý.
Nội dung trên có thể nghe có vẻ mơ hồ và trừu tượng, thực tế, các máy chủ và nhà cung cấp đám mây khác nhau triển khai TEE theo cách khác nhau, nhưng mục đích cơ bản là để tránh TEE bị can thiệp bởi các chương trình khác.
Đa số độc giả có thể sử dụng thông tin nhận dạng sinh học để đăng nhập thiết bị, chẳng hạn như mở khóa điện thoại bằng vân tay. Nhưng làm thế nào để đảm bảo ứng dụng độc hại, trang web hoặc hệ điều hành jailbreak không thể truy cập và đánh cắp thông tin nhận dạng sinh học này? Trên thực tế, ngoài việc mã hóa dữ liệu, mạch trên thiết bị TEE hoàn toàn không cho phép bất kỳ chương trình nào truy cập khu vực bộ nhớ và bộ xử lý mà dữ liệu nhạy cảm chiếm giữ.
Ví cứng là một ví dụ khác về ứng dụng TEE. Ví cứng được kết nối với máy tính và giao tiếp với nó thông qua hộp cát, nhưng máy tính không thể truy cập trực tiếp vào từ khóa ghi nhớ được lưu trữ trong ví cứng. Trong cả hai trường hợp trên, người dùng đều tin tưởng rằng nhà sản xuất thiết bị có thể thiết kế chíp đúng cách và cung cấp các bản cập nhật firmware thích hợp để ngăn chặn dữ liệu bí mật trong TEE bị xuất khẩu hoặc xem.
mô hình an toàn
Rất tiếc, có rất nhiều loại TEE được triển khai, những triển khai khác nhau này (IntelSGX, IntelTDX, AMDSEV, AWSNitroEnclaves, ARMTrustZone) đều yêu cầu mô hình bảo mật riêng biệt cho phân tích và xây dựng. Trong phần còn lại của bài viết này, chúng tôi sẽ tập trung thảo luận chính về IntelSGX, TDX và AWSNitro, vì những hệ thống TEE này có nhiều người dùng hơn và có các công cụ phát triển đầy đủ và sẵn có. Những hệ thống trên cũng là những hệ thống TEE phổ biến nhất trong Web3.
Nhìn chung, quy trình làm việc của các ứng dụng triển khai trong TEE như sau:
Rõ ràng, có 3 rủi ro tiềm tàng ở đây:
May mắn thay, hiện nay TEE đã có giải pháp để loại bỏ các rủi ro trên, đó là xây dựng có thể tái tạo(Reproducible Builds) và chứng nhận từ xa(Remote Atteststations).
Vậy làm thế nào để xây dựng có thể lặp lại? Phát triển phần mềm hiện đại thường yêu cầu nhập rất nhiều phụ thuộc, chẳng hạn như công cụ, thư viện hoặc framework bên ngoài và các tệp phụ thuộc này cũng có thể có các vấn đề tiềm ẩn. Hiện nay, các giải pháp như npm sử dụng mã băm của tệp phụ thuộc như một định danh duy nhất. Khi npm phát hiện rằng một tệp phụ thuộc không khớp với giá trị băm được ghi lại, nó có thể cho rằng tệp phụ thuộc đã bị chỉnh sửa.
Còn có thể xây dựng có thể được coi là một tập hợp tiêu chuẩn, mục tiêu là khi bất kỳ mã nào chạy trên bất kỳ thiết bị nào, chỉ cần tuân theo quy trình đã được xác định trước, cuối cùng sẽ nhận được giá trị băm nhất quán. Tất nhiên, trong thực tế, chúng ta cũng có thể sử dụng các sản phẩm bên ngoài giá trị băm như là các định danh, chúng ta gọi là đo lường mã (code measurement).
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 bị lộ, 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 bất cứ điều gì bất thường và bất kỳ ai cũng có thể xây dựng mã bằng Nix để kiểm tra xem sản phẩm được xây dựng có cùng số liệu mã / hàm băm với sản phẩm được nhóm dự án triển khai trong sản xuất hay không. Nhưng làm thế nào để chúng ta biết các số liệu mã cho một chương trình trong TEE? Điều này đưa chúng ta đến khái niệm gọi là "bằng chứng từ xa". **
Chứng thực từ xa là tin nhắn được ký từ nền tảng TEE (bên tin cậy), trong đó chứa các giá trị đo lường mã code của chương trình, phiên bản của nền tảng TEE, v.v. Chứng thực từ xa giúp người quan sát bên ngoài biết rằng một chương trình đang chạy trong một vị trí an toàn mà không ai có thể truy cập (TEE thực sự phiên bản xx).
Việc xây dựng có thể lặp lại và chứng minh từ xa cho phép bất kỳ người dùng nào biết mã nguồn thực tế và phiên bản nền tảng TEE đang chạy trong TEE, từ đó ngăn chặn các nhà phát triển hoặc máy chủ có hành vi xấu.
Tuy nhiên, trong trường hợp TEE, luôn cần phải tin tưởng nhà cung cấp của nó. Nếu nhà cung cấp TEE gian lận, có thể trực tiếp tạo ra chứng chỉ từ xa giả mạo. Do đó, nếu coi nhà cung cấp là một phương tiện tấn công có thể xảy ra, nên tránh chỉ phụ thuộc vào TEE, tốt nhất là kết hợp chúng với ZK hoặc giao thức đồng thuận.
Sức hút của TEE
The TEE's popularity, especially its deployment friendliness for AI Agents, is mainly due to the following features in our opinion:
Hiện tại, rất khó tìm thấy các giải pháp thay thế cho các trường hợp sử dụng TEE, dù tốt hay xấu. Chúng tôi tin rằng việc giới thiệu TEE sẽ mở rộng thêm không gian phát triển ứng dụng trên chuỗi khối và 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
Chương trình chạy trong TEE vẫn dễ bị ảnh hưởng bởi một loạt các cuộc tấn công và lỗi. Giống như hợp đồng thông minh, chúng dễ gặp phải một loạt vấn đề. Để đơn giản, chúng ta sẽ phân loại lỗ hổng có thể như sau:
Sơ suất của nhà phát triển
Dù có ý đồ hay không, nhà phát triển có thể yếu đi sự bảo đảm an ninh của chương trình trong TEE thông qua mã có ý đồ hoặc không có ý đồ. Điều này bao gồm:
Lỗ hổng thời gian chạy
Ngay cả những nhà phát triển cẩn thận cũng có thể trở thành nạn nhân của lỗ hổng thời gian chạy. Nhà phát triển phải cân nhắc kỹ xem bất kỳ yếu tố nào dưới đây có ảnh hưởng đến bảo đảm an ninh của dự án hay không:
Ví dụ, trong TEE có thể chạy một bộ máy phù hợp để xử lý giao dịch mã hóa, bộ máy này không thể đảm bảo sắp xếp công bằng (chống MEV) vì bộ định tuyến/cổng truy cập/máy chủ vẫn có thể loại bỏ, trì hoãn hoặc ưu tiên xử lý dựa trên địa chỉ IP nguồn của gói tin.
Lỗ hổng kiến trúc
Các công nghệ mà ứng dụng TEE sử dụng nên được sử dụng cẩn thận. Khi xây dựng ứng dụng TEE, có thể phát sinh các vấn đề sau:
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ố điểm lưu ý thực tế về cách vận hành một máy chủ thực thi chương trình TEE:
Xây dựng chương trình TEE an toàn
Chúng tôi sẽ chia đề xuất của chúng tôi thành các điểm sau đây:
1. Giải pháp an toàn nhất: không có phụ thuộc vào bên ngoại
Việc tạo ứng dụng an toàn cao có thể liên quan đến việc loại bỏ các phụ thuộc bên ngoài như đầu vào bên ngoài, API hoặc dịch vụ, từ đó giảm thiểu diện tích tấn công. Phương pháp này đảm bảo ứng dụng chạy độc lập mà không có tương tác bên ngoài có thể làm hỏng tính toàn vẹn hoặc an toàn của nó. 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ó có thể cung cấp mức độ an toàn rất cao.
Nếu mô hình được chạy cục bộ, thì độ an toàn ở mức này có thể được đảm bảo cho hầu hết các trường hợp sử dụng của CryptoxAI.
2. Các biện pháp phòng ngừa cần thiết
Dù ứng dụng có phụ thuộc vào các thành phần bên ngoài hay không, những nội dung sau đây là bắt buộc!
Xem ứng dụng TEE như một hợp đồng thông minh thay vì ứng dụng backend; duy trì tần suất cập nhật thấp, kiểm thử nghiêm ngặt.
Xây dựng chương trình TEE phải được thực hiện một cách nghiêm ngặt như việc viết, kiểm tra 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à không thể bị sửa đổi, trong đó lỗi 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 việc mất hoàn toàn tiền tệ. Kiểm toán toàn diện, kiểm tra rộng rãi và ít nhất là cập nhật được kiểm toán cẩn thận là cực kỳ quan trọng để đảm bảo tính toàn vẹn và đáng tin cậy của các ứng dụng dựa trên TEE.
Kiểm tra mã kiểm toán và kiểm tra đường ống xây dựng
Độ an toàn của ứng dụng không chỉ phụ thuộc vào mã nguồn chính nó, 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 lỗ hổng. TEE chỉ đảm bảo mã nguồn cung cấp sẽ chạy theo quy trình dự kiến, nhưng không thể sửa chữa các lỗi được giới thiệu trong quá trình xây dựng.
Để giảm thiểu rủi ro, việc kiểm tra và kiểm toán mã nguồn một cách nghiêm ngặt là cần thiết để loại bỏ lỗi và ngăn chặn rò rỉ thông tin không cần thiết. Ngoài ra, quá trình xây dựng có thể lặp lại đóng vai trò quan trọng, đặc biệt là khi mã nguồn được phát triển bởi một bên và sử dụng bởi một bên khác. Quá trình xây dựng có thể lặp lại cho phép bất kỳ ai kiểm tra xem chương trình được thực thi trong TEE có khớp với mã nguồn gốc hay không, đảm bảo tính minh bạch và tin cậy. Nếu không có quá trình xây dựng có thể lặp lại, việc xác định nội dung chính xác của chương trình được thực thi trong TEE là gần như không thể, đe dọa tính an toàn của ứng dụng.
Ví dụ, mã nguồn của dự án DeepWorm (một mô hình mô phỏng não giun chạy trong TEE) là hoàn toàn công khai. Chương trình thực thi trong TEE được xây dựng một cách tái lập bằng Nix pipeline.
Sử dụng thư viện đã được kiểm toán hoặc xác minh
Trong quá trình xử lý dữ liệu nhạy cảm trong chương trình TEE, chỉ sử dụng thư viện đã được kiểm toán để quản lý khóa và xử lý dữ liệu riêng tư. Thư viện chưa được kiểm toán có thể tiết lộ khóa và đe dọa tính bảo mật của ứng dụng. Ưu tiên các phần phụ thuộc đã được kiểm tra kỹ càng, tập trung vào an ninh để duy trì tính bí mật và toàn vẹn của dữ liệu.
Luôn xác minh chứng chỉ từ TEE
Người dùng tương tác với TEE phải xác minh bằng chứng từ xa hoặc cơ chế xác minh mà TEE tạo ra để đảm bảo tương tác an toàn và đáng tin cậy. Nếu thiếu các kiểm tra này, máy chủ có thể can thiệp vào phản hồi, dẫn đến khó phân biệt giữa đầu ra TEE thực và dữ liệu bị sửa đổi. Chứng từ từ xa cung cấp bằng chứng quan trọng về thư viện mã và cấu hình được thực thi trong TEE, giúp chúng ta đánh giá xem chương trình đang chạy trong TEE có khớp với dự kiến hay không.
Chứng thực cụ thể có thể được thực hiện trên chuỗi (IntelSGX, AWSNitro), sử dụng chứng minh ZK (IntelSGX, AWSNitro) để xác minh ngoại chuỗi, hoặc có thể được xác minh bởi người dùng hoặc dịch vụ lưu trữ (như t16z hoặc MarlinHub).
Dựa trên các trường hợp sử dụng mục tiêu của ứng dụng và cấu trúc của nó, những gợi ý sau có thể giúp làm cho ứng dụng của bạn an toàn hơn.
Đảm bảo luôn thực hiện tương tác người dùng với TEE trên kênh an toàn
Máy chủ chứa TEE về bản chất không được tin cậy. Máy chủ có thể chặn và sửa đổi giao tiếp. Trong một số trường hợp, việc máy chủ đọc dữ liệu nhưng không thay đổi dữ liệu có thể chấp nhận được, trong khi trong các trường hợp khác, việc đọc dữ liệu có thể không chấp nhận được. Để giảm thiểu những rủi ro này, việc thiết lập kênh mã hóa đầu cuối an toàn giữa người dùng và TEE là rất quan trọng. Ít nhất, hãy đảm bảo tin nhắn bao gồm chữ ký để xác minh tính chính xác và nguồn gốc của nó. Ngoài ra, người dùng cần luôn kiểm tra chứng minh từ xa mà TEE cung cấp để xác minh liệu họ đang truyền thông với TEE đúng hay không. Điều này đảm bảo tính toàn vẹn và tính bảo mật của giao tiếp.
Ví dụ, Oyster có thể hỗ trợ phát hành TLS an toàn bằng cách sử dụng bản ghi CAA và RFC8657. Ngoài ra, nó còn cung cấp một giao thức TLS cơ bản TEE có tên Scallop, không phụ thuộc vào WebPKI.
Biết rằng bộ nhớ TEE là tạm thời
Bộ nhớ TEE là tạm thời, điều này có nghĩa là khi TEE tắt, nội dung của nó (bao gồm cả khóa mã hóa) sẽ bị mất. Nếu không có cơ chế an toàn để lưu trữ thông tin này, dữ liệu quan trọng có thể trở nên không thể truy cập vĩnh viễn, gây khó khăn cho vốn tiền hoặc hoạt động.
Mạng tính toán đa phương tiện (MPC) với hệ thống lưu trữ phi tập trung như IPFS có thể được sử dụng làm giải pháp cho vấn đề này. Mạng MPC chia khóa thành nhiều nút để đảm bảo không có một nút đơn lẻ nào giữ toàn bộ khóa, đồng thời cho phép mạng tái tạo khóa khi cần thiết. 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ần, mạng MPC có thể cung cấp khóa cho máy chủ TEE mới chạy cùng hình ảnh, với điều kiện cụ thể. Phương pháp này đảm bảo tính linh hoạt và an ninh mạnh mẽ, giữ cho dữ liệu có thể truy cập và bí mật ngay cả trong môi trường không tin cậy.
Còn một giải pháp khác, đó là TEE sẽ chia các giao dịch liên quan cho các máy chủ MPC khác nhau, MPC server sẽ ký tên và ký tập hợp các giao dịch trước khi đưa chúng lên chuỗi. Phương pháp này có độ linh hoạt thấp hơn và không thể được sử dụng để lưu trữ khóa API, mật khẩu hoặc bất kỳ dữ liệu nào khác (không có dịch vụ lưu trữ của bên thứ ba đáng tin cậy).
Giảm diện tích tấn công
Đối với các trường hợp sử dụng quan trọng về an ninh, đáng giá để thử nghiệm việc giảm thiểu phụ thuộc ngoại vi một cách tối đa, thậm chí là với sự hy sinh trải nghiệm phát triển của nhà phát triển. Ví dụ, Dstack đi kèm với một nhân cơ bản dựa trên Yocto chỉ bao gồm các module cần thiết để Dstack hoạt động. Đôi khi có thể xứng đáng sử dụng các công nghệ cũ như SGX (hơn cả TDX) vì công nghệ này không cần trở thành một phần của TEE trong quá trình khởi động hoặc hệ điều hành.
Cách ly vật lý
Bằng cách cách ly vật lý TEE khỏi sự can thiệp con người có thể xảy ra, có thể tăng cường độ an toàn của TEE. Mặc dù chúng ta có thể tin tưởng rằng việc đặt máy chủ TEE tại trung tâm dữ liệu và nhà cung cấp đám mây có thể đảm bảo an ninh vật lý, nhưng 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 SpaceTEE dựa trên các biện pháp bảo mật như đo đạc moment quán tính sau khi phóng, để xác minh liệu vệ tinh có lệch khỏi dự đoán trong quá trình nhập vào quỹ đạo hay không.
Người chứng minh đa quyền
Giống như Ethereum phụ thuộc vào nhiều phiên bản khách hàng để giảm thiểu rủi ro lỗi ảnh hưởng đến toàn bộ mạng, multiprovers sử dụng các giải pháp triển khai TEE khác nhau để nâng cao tính bảo mật và linh hoạt. 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 khác nhau, việc xác thực đa lớp đảm bảo rằng lỗi trong một triển khai TEE không đe dọa toàn bộ ứng dụng. Mặc dù phương pháp này đòi hỏi quá trình tính toán là xác định, hoặc định nghĩa sự nhất trí giữa các triển khai TEE khác nhau trong trường hợp không xác định, nhưng nó cũng cung cấp nhiều lợi ích đáng kể như cách ly lỗi, dự phòng và xác thực chéo, làm cho nó trở thành một lựa chọn tốt cho các ứng dụng đòi hỏi đảm bảo đáng tin cậy.
Nhìn vào 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 đó, sự phổ biến của AI và quyền truy cập liên tục 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 của dịch vụ của họ.
Mặt khác, cộng đồng mã hóa luôn chú trọng đến an ninh. 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 ta đã thấy TEE trở nên phổ biến như một giải pháp cân bằng đúng giữa tính năng và giả định tin tưởng. Mặc dù TEE không tối giản hóa niềm tin như một giải pháp ZK đầy đủ, nhưng chúng tôi dự đoán rằng TEE sẽ trở thành cách tiếp cận đầu tiên để từ từ kết hợp sản phẩm của các công ty Web3 và các công ty công nghệ lớn.