Tối 14/5, dòng tweet của CertiK xé toạc bầu không khí vốn đang phấn khích của giới AI. Công ty bảo mật xuất thân từ Web3 tuyên bố phát hiện một lỗ hổng trên Google EdgeTPU, đồng thời đưa ra một thông điệp đầy ám gợi: AI security không thể dừng ở model. Không CVE, không mã khai thác, không một dòng mô tả kỹ thuật nào. Google giữ im lặng. Thị trường xôn xao. Một số người gọi đây là phát hiện mang tính thời đại; số khác nghi ngờ đây chỉ là một cú marketing chuẩn bị cho vòng gọi vốn tiếp theo.
Với tôi, cảnh tượng này gợi nhớ đến buổi tối tháng 6/2018, lần đầu tôi cọc 3 ETH vào một ICO tên là "DataChain". Whitepaper của họ đẹp long lanh, lộ trình phát triển rõ ràng, đội ngũ có cả tiến sĩ từ Stanford. Hai tuần sau, dự án biến mất, trang web sập, Telegram xoá sạch. Lúc đó tôi mới ra trường, tin vào những lời hứa trong một bản PDF mà không bao giờ đọc dòng code. Tôi mất sạch. Kể từ hôm đó, tôi đặt ra nguyên tắc sống còn: kiểm tra contract trước, tin sau. Và giờ đây, cả giới đầu tư AI đang phải đối mặt với một câu hỏi y hệt: chúng ta nên tin vào công bố của CertiK, hay tin vào sự im lặng của Google? Rug pull: học phí đắt, nhưng nhớ lâu.
Đặt sự kiện vào bối cảnh lớn hơn. EdgeTPU là một ASIC do Google thiết kế riêng cho tác vụ suy luận AI tại biên. Nó được tích hợp trong camera, thiết bị IoT, robot công nghiệp và các bộ kit phát triển như Coral Dev Board. Khác với Cloud TPU - nơi Google kiểm soát hoàn toàn phần cứng trong trung tâm dữ liệu, có hàng rào vật lý, ảo hoá và đội ngũ vận hành chuyên nghiệp - EdgeTPU chạy trên những thiết bị nằm ngoài phạm vi kiểm soát của Google. Bạn có thể chạm vào nó, đo điện năng tiêu thụ của nó, gắn logic analyzer vào chân của nó. Điều đó tạo ra một bề mặt tấn công mà không một API model hiện đại nào có thể sánh được.
CertiK không phải là một công ty bảo mật thông thường. Họ được thành lập bởi các giáo sư khoa học máy tính khởi nguồn từ đại học Yale, với vũ khí chính là formal verification - một nhánh kỹ thuật dùng logic toán học để chứng minh rằng một chương trình hoặc một mạch điện tử hoạt động đúng như thiết kế. Thị trường chính của họ trong nhiều năm qua là bảo mật hợp đồng thông minh. Họ audit hàng ngàn dự án DeFi, xây dựng nền tảng kiểm định cho hàng loạt protocol Ethereum, và được định giá 2 tỷ USD trong vòng gọi vốn gần nhất. Rất nhiều nhà đầu tư Web3 xem báo cáo audit của CertiK như một điều kiện tiên quyết trước khi rót vốn. Vậy một công ty như vậy có lý do gì để đưa ra một tuyên bố không kèm bằng chứng về con chip AI của Google?
Có một lý do thuần tuý kỹ thuật: formal verification chính là công cụ phù hợp nhất để săn lỗi trong chip. Phần mềm thông thường có thể được kiểm thử bằng hàng ngàn test case, nhưng để chứng minh rằng một mạch điện tử không có hành vi không mong muốn trong mọi ngõ ngách của trạng thái, bạn cần suy luận toán học. Những đội ngũ chuyên về formal verification là một trong số ít người có khả năng đối chiếu mã nguồn Verilog hoặc VHDL với các quy tắc bảo mật để tìm ra một nhánh lệnh bị bỏ quên. Nếu lỗ hổng EdgeTPU thực sự nằm trong logic firmware, CertiK là ứng viên sáng giá để phát hiện ra nó. Nhưng tôi cần nhiều dữ liệu hơn là một câu khẳng định.
Bây giờ đi vào trọng tâm. Hãy liệt kê các lớp tấn công có thể xảy ra trên EdgeTPU. Lớp thứ nhất là Linux kernel driver. EdgeTPU được điều khiển thông qua một driver kernel do Google phát triển, có nhiệm vụ quản lý bộ nhớ, hàng đợi lệnh và truyền dữ liệu giữa CPU và NPU. Trong lịch sử của NVIDIA, rất nhiều lỗ hổng nghiêm trọng - bao gồm CVE-2021-1070 - nằm ngay trong kernel driver. Một lỗi nhỏ trong việc kiểm tra quyền truy cập vùng nhớ có thể cho phép tiến trình không đặc quyền ghi vào vùng địa chỉ kernel. Từ đó dẫn đến leo thang đặc quyền root và vô hiệu hoá mọi cơ chế bảo vệ. Nếu CertiK tìm ra một lỗi cùng lớp trong driver EdgeTPU, kẻ tấn công có thể chiếm quyền điều khiển toàn bộ thiết bị mà không cần đụng tới model bên trong.
Lớp thứ hai là firmware chạy trên chính con chip EdgeTPU. Chip không chỉ có các đơn vị tính toán ma trận. Nó còn có bộ điều khiển bộ nhớ, một bộ xử lý vi điều khiển phụ, các mạch quản lý điện năng, và quan trọng nhất là một bộ xác minh lệnh chịu trách nhiệm kiểm tra tính hợp lệ của các lệnh được đưa vào NPU. Nếu có một lỗ hổng trong bộ xác minh này, kẻ tấn công có thể nạp một chuỗi lệnh bất hợp pháp đủ để khiến chip thực thi các phép tính sai. Điều này giống hệt lỗ hổng mà tôi từng phát hiện trong một dApp trên zkSync Era - một lỗi trong quá trình xác minh zk-proof khiến kẻ tấn công có thể rút tiền vô hạn. Trong trường hợp đó, nhóm dự án tập trung hoàn toàn vào giao diện người dùng, làm cho trải nghiệm trở nên mượt mà, nhưng quên rằng lớp xác minh bằng chứng mới là nơi quyết định an toàn. Bug tồn tại ba tháng không một ai nhìn thấy. Tôi gửi báo cáo lên Immunefi, nhận 50.000 USD. Khi CertiK nói "không thể dừng ở model", tôi tin rằng họ đang nói về điều tương tự: một sai sót ở lớp dưới cùng có thể phá vỡ mọi bức tường phòng thủ phía trên.
Cách tôi tiếp cận một báo cáo audit cũng giống như cách tôi phân tích một smart contract. Tôi không bao giờ nhảy vào phần tử đầu tiên. Tôi đọc những giả định. Tôi tìm nơi mà một dev có thể lười biếng: bỏ qua kiểm tra số dư, dùng timestamp không an toàn, không kiểm tra giá trị trả về. Với chip cũng vậy, kỹ sư phần cứng thường tập trung tối ưu diện tích và năng lượng, và trong quá trình đó, họ có thể tạo ra một trạng thái "không nên xảy ra" mà không ai lường trước. Formal verification, nếu được làm đúng cách, liệt kê tất cả các trạng thái này. Nó mệt mỏi và tốn kém, nhưng hiệu quả. Sau khi tôi phát hiện lỗi zk-proof trong zkSync Era, một đồng nghiệp hỏi tôi tại sao người khác không thấy nó. Tôi chỉ nói: vì họ dừng lại ở việc chạy thử nghiệm và quên mất việc chứng minh. Với con chip, việc chạy thử nghiệm cũng không bao giờ đủ.
Lớp thứ ba là side-channel. Vì EdgeTPU thường nằm trong các thiết bị có thể bị tiếp cận vật lý, kẻ tấn công có thể đo lượng điện năng tiêu thụ của chip trong khi nó xử lý một ảnh đầu vào. Các nghiên cứu đã chứng minh rằng mô hình AI có thể được trích xuất bằng phân tích công suất. Nếu kẻ tấn công biết kiến trúc mạng nơ-ron và giá trị trọng số - dù chỉ xấp xỉ - họ có thể tái tạo một mô hình có giá trị thương mại hoặc xác định được dữ liệu đầu vào nhạy cảm đang được xử lý. Điều này đặc biệt nguy hiểm trong các ứng dụng nhận diện khuôn mặt hay chẩn đoán y tế, nơi thông tin sinh trắc học là bất khả xâm phạm. Ngay cả khi chính phủ hay tập đoàn mã hoá dữ liệu trên đường truyền, một khi dữ liệu nằm trong bộ đệm của EdgeTPU và bị mất qua kênh phụ, mọi nỗ lực bảo mật tầng trên coi như vô ích.
Lớp thứ tư là xác thực chuỗi tin cậy. Một thiết bị EdgeTPU cần một cơ chế secure boot - xác minh chữ ký số của firmware mỗi lần khởi động - để ngăn chặn phần mềm giả mạo chiếm quyền. Không phải thiết bị nào cũng triển khai đầy đủ. Nếu một lỗ hổng cho phép bỏ qua quá trình kiểm tra chữ ký trong boot ROM, kẻ tấn công có thể ghi một firmware độc hại vĩnh viễn vào chip, biến nó thành một "con rối" điều khiển từ xa. Đối với các hệ thống an ninh công cộng, giám sát giao thông hoặc cơ sở hạ tầng quốc gia, kịch bản này giống như việc một con camera được sử dụng làm bàn đạp để đột nhập toàn bộ mạng lưới. Đó chính là thứ mà các cơ quan tình báo đang tìm kiếm: một lỗ hổng để xâm nhập vào chuỗi cung ứng phần cứng AI.
Một câu hỏi mấu chốt: lỗ hổng này ảnh hưởng đến Google Cloud TPU hay không? Theo hiểu biết của tôi, EdgeTPU và Cloud TPU có các yêu cầu thiết kế hoàn toàn khác nhau. Cloud TPU chạy trong trung tâm dữ liệu được bảo vệ nhiều lớp. Nó bắt buộc phải có cơ chế ảo hoá, cách ly giữa các khách hàng và một mô hình tin cậy phần cứng rõ ràng. EdgeTPU thì không. Nó được tối ưu cho mức tiêu thụ điện năng thấp, chi phí rẻ, và kích thước nhỏ. Nếu phải cài đặt đầy đủ các module bảo mật như Cloud TPU, giá thành sẽ tăng vọt. Vì vậy, nếu lỗ hổng nằm trong một mạch chỉ có trên EdgeTPU mà không có trên Cloud TPU, Google có thể vá bằng bản cập nhật firmware hoặc phần mềm. Nhưng nếu lỗ hổng nằm trong một thành phần dùng chung, vấn đề sẽ lan rộng hơn nhiều. Chúng ta chưa có dữ liệu để kết luận.
Đợi một chút. Hãy nhìn vào một chi tiết mà phần lớn báo chí bỏ qua. CertiK không hề đề cập đến việc liệu họ đã liên hệ với Google trước khi công bố hay chưa. Trong giới bảo mật, quy trình chuẩn là "responsible disclosure": báo cáo cho nhà sản xuất, chờ 90 ngày để họ vá lỗi, sau đó mới công khai toàn bộ chi tiết để cộng đồng tự bảo vệ. Google Project Zero, đội ngũ săn lỗ hổng nổi tiếng nhất thế giới, cũng tuân theo quy tắc này một cách nghiêm ngặt. Nếu CertiK có một lỗ hổng thực sự nghiêm trọng trong tay, họ đáng ra phải để Google có thời gian sửa chữa. Việc công bố trước mà không kèm bằng chứng đặt ra câu hỏi về động cơ. Liệu họ có đang muốn ghi điểm truyền thông trước khi Google có thể phản bác? Liệu họ có đang dùng một phát hiện chưa hoàn thiện để phục vụ cho chiến lược gọi vốn? Tôi không biết. Nhưng tôi biết rằng thị trường tăng giá đang khiến người ta dễ dàng quên đi việc kiểm chứng.
Đến đây, tôi cần phản biện một số giả định phổ biến. Thứ nhất, nhiều người vội vàng kết luận rằng "Google EdgeTPU không an toàn" chỉ dựa trên một tuyên bố. Điều này phi logic. Có một sự khác biệt lớn giữa việc phát hiện ra một lỗi trong phòng thí nghiệm và việc lỗi đó có thể bị khai thác trên thực tế. Trong quá khứ, nhiều công ty đã công bố các lỗ hổng phần cứng hoa mỹ, nhưng sau đó lại không thể đưa ra bản PoC hoạt động trên thiết bị thật. Điều đó không có nghĩa là họ cố tình nói dối, mà là các điều kiện khai thác lỗ hổng - như phần cứng cụ thể, phiên bản firmware, cấu hình bộ nhớ - có thể không giống như trong môi trường mô phỏng.
Thứ hai, nếu CertiK thực sự phát hiện ra một lỗ hổng nhưng không cung cấp chi tiết, điều đó có thể tạo ra sự hoang mang không cần thiết cho thị trường. Các quỹ phòng hộ và nhà đầu tư tổ chức đang chi hàng tỷ đô la cho hạ tầng AI. Một tuyên bố vô căn cứ có thể khiến họ trì hoãn các quyết định mua thiết bị, gây thiệt hại cho các công ty phân phối EdgeTPU. Giống như một tin đồn rug pull trong crypto có thể làm giá token của một dự án tốt sụp đổ trước khi có bằng chứng về việc rút thảm. Thị trường không vận hành dựa trên sự thật, mà dựa trên nhận thức về sự thật. Và những nhận thức đó có thể bị điều khiển.
Đầu năm 2022, tôi ngồi nhìn BAYC floor giảm từ 120 ETH xuống 45 ETH. Đồng đội bảo tôi liều khi tôi short, nhưng tôi chỉ nhìn vào một con số: số lượng holder đã giảm 20% trong một tháng. Dữ liệu không nói dối. Nó cũng là lý do tôi khuyên các doanh nghiệp đang dùng EdgeTPU đừng hoảng sợ vì một tweet. Hãy nhìn vào dữ liệu: có CVE chưa, có PoC chưa, có bản vá chưa. Nếu chưa có, hãy đợi. Đợi và quan sát cũng là một dạng chiến lược.
Thứ ba, nếu lỗ hổng thực sự nghiêm trọng và Google đã biết nhưng chưa kịp vá, việc CertiK công khai sớm sẽ tạo ra một cửa sổ nguy hiểm cho kẻ xấu. Trong khi Google cần vài tuần để phát triển bản vá, kẻ tấn công có thể tận dụng thông tin đã bị lộ để xây dựng mã khai thác. Việc tiết lộ có trách nhiệm không phải là một hình thức, mà là một quy trình cứu sinh. Vi phạm quy trình đó có thể đặt người dùng vào rủi ro, đi ngược lại chính sứ mệnh bảo mật mà CertiK tuyên bố theo đuổi. Đây là lý do khiến tôi luôn giữ một sự hoài nghi lành mạnh với những gì không có code, không có PoC, không có CVE.
Vậy câu chuyện này cho chúng ta điều gì? Dù CertiK có thật sự chứng minh được lỗ hổng trong những tuần tới hay không, một sự thay đổi mang tính cấu trúc đang diễn ra. AI security không còn được phép dừng ở model, ở prompt hay ở alignment. Nó phải đi xuống tận con chip, vi mạch, driver và chuỗi cung ứng phần cứng. Những ai đang vận hành các hệ thống AI ở biên, từ camera cho đến robot, cần bắt đầu yêu cầu các nhà sản xuất cung cấp bằng chứng về secure boot, về quá trình cập nhật firmware, về các bài kiểm tra side-channel. Họ không được phép ngủ quên trên một niềm tin rằng "model của chúng tôi an toàn". Tôi từng bị rug pull vì tin whitepaper, và từ đó không bao giờ đầu tư vào dự án nào mà không kiểm tra contract. Bây giờ, tôi muốn hỏi bạn: liệu con chip mà bạn đang chạy bot, chạy model, chạy cả tương lai của bạn - bạn đã thực sự kiểm tra nó như một hợp đồng thông minh chưa? Bot chạy, tôi ngủ. Yield vẫn vào. Nhưng nếu con chip phản bội, ngay cả bot cũng chỉ là một cỗ máy của rủi ro.


