➔ Trở về Trang chủ
OrangeCloud Insights
Security••⏱️ 2 phút đọc•Biên tập: OrangeCloud Insights (AI-assisted)•Nguồn: theregister.com
Nghiên cứu chỉ ra cơ chế tin cậy của attested TLS trong confidential computing có thể bị vượt qua

Nghiên cứu chỉ ra cơ chế tin cậy của attested TLS trong confidential computing có thể bị vượt qua

Tóm tắt kỹ thuật (TL;DR)

"Research on attested TLS in confidential computing found that the protocol can be cryptographically bound to the start of a TLS handshake, but not reliably to the eventual application traffic key. Formal verification uncovered diversion and relay attacks in multiple implementations, leading to CVE-2026-33697 (CVSS 7.5) and showing that a client may authenticate one machine while encrypting data to another. The proposed mitigation improves binding to level two, but the authors conclude that level three may not be achievable in the current intra-handshake attestation design without changing TLS 1.3 properties."

🛡️ Tác động Bảo mật8/10

Nguy cơ chính là relay/diversion attacks làm sai lệch ràng buộc giữa bằng chứng attestation và khóa mã hóa thực tế, dẫn tới khả năng xác thực nhầm máy. Điểm then chốt: CVE-2026-33697 (CVSS 7.5), giới hạn đạt mức 3 trong intra-handshake attestation, và sự cần thiết của ràng buộc mạnh hơn ngoài giao thức.

💼 Tác động Vận hành6/10

Tác động vận hành tập trung vào việc giảm mức tin cậy của các cam kết “confidential computing” cho mục tiêu digital sovereignty. Điểm then chốt: cần điều chỉnh kiến trúc (đặc biệt phần định danh/quản lý khóa), và tăng chi phí đánh giá lại triển khai vì lỗi được chứng minh trên nhiều hệ thống chạy thực tế.

Nghiên cứu độc lập về attested TLS trong confidential computing cho thấy giao thức có thể được ràng buộc mật mã với thời điểm bắt đầu bắt tay TLS, nhưng không ràng buộc đáng tin cậy với khóa dùng cho lưu lượng ứng dụng về sau. Nhóm tác giả dùng công cụ phân tích hình thức ProVerif để kiểm chứng các cơ chế “intra-handshake attestation” và phát hiện các diversion/relay attacks: kết nối dự định tới một máy chủ có thể bị chuyển hướng sang máy khác đã bị xâm phạm, trong khi phía khách vẫn tin rằng bằng chứng toàn vẹn phần mềm là đúng.

Kết quả dẫn tới CVE-2026-33697 (CVSS 7.5). Trong mô hình tin cậy được chia thành 3 mức ràng buộc, cơ chế tốt nhất được đề xuất chỉ đạt mức 2 (ràng buộc tới handshake traffic key), còn mức 3 (ràng buộc tới application traffic key) được kết luận là có thể không đạt được trong kiến trúc attestation hiện tại nếu không thay đổi các thuộc tính của TLS 1.3.

Khuyến nghị: đánh giá lại mức độ “bảo đảm” của attested TLS trong thiết kế hệ thống, ưu tiên kiểm soát bổ sung ở lớp định danh/quản lý khóa, và theo dõi bản vá/khuyến nghị từ cộng đồng và nhà cung cấp cho từng triển khai cụ thể.

Xem nguồn tin gốc để kiểm tra kỹ hơn các thông số kỹ thuật:Xem nguồn tin gốc ➔