Khi học máy kể sai câu chuyện
(jackcook.com)- Dự án bảo mật phần cứng của MIT, trong lúc tái hiện một cuộc tấn công kênh kề được hỗ trợ bởi machine learning khả thi trên trình duyệt web, đã phơi bày một cái bẫy: độ chính xác cao của mô hình không chứng minh được nguyên nhân thực sự
- Các nghiên cứu website fingerprinting trước đây xem tranh chấp bộ nhớ đệm CPU là nguyên nhân, nhưng một phương pháp loại bỏ truy cập cache và chỉ tăng một bộ đếm đơn giản lại đạt độ chính xác cao hơn trong nhiều môi trường
- Nhóm nghiên cứu lần lượt loại trừ các giả thuyết về co giãn tần số CPU, tranh chấp lõi CPU và cache; bằng đo đạc eBPF, họ xác nhận rằng hơn 99% các đoạn dừng từ 100ns trở lên là do xử lý interrupt
- Chỉ riêng tín hiệu interrupt hệ thống cũng làm lộ hoạt động tải website, và trên Chrome/Linux, độ chính xác nhận diện website nạn nhân trong 100 website lên tới 96,6%
- Để thiết kế biện pháp phòng thủ, trước hết cần phân tích để xác nhận cơ chế thực sự của kênh kề, thay vì chỉ dựa vào việc mô hình dự đoán đúng
Cơ duyên bắt đầu nghiên cứu
- Năm 2020, trong lớp Secure Hardware Design của MIT, một dự án tái triển khai tấn công website fingerprinting đã bắt đầu, dựa trên kinh nghiệm về phát triển web và machine learning
- Mengjia Yan cho rằng có điều gì đó không khớp trong các nghiên cứu website fingerprinting mới nhất, vốn dùng machine learning để tấn công các điểm yếu phần cứng, nên đã đề xuất tái triển khai
- Dự án về sau dẫn tới bài báo There’s Always a Bigger Fish: A Clarifying Analysis of a Machine-Learning-Assisted Side-Channel Attack
- Bài báo giành giải nhất Intel 2024 Hardware Security Academic Award và được đưa vào IEEE Micro Top Picks năm 2023
- Nghiên cứu xoay quanh ba trục: tấn công trình duyệt, rò rỉ interrupt hệ thống và lỗi diễn giải machine learning
Kênh kề và website fingerprinting
- Cách ly tiến trình tách biệt bộ nhớ và tài nguyên của các ứng dụng, nhưng trên máy tính thực tế, các tài nguyên như card mạng, GPU và CPU vẫn liên tục được chia sẻ
- Tài nguyên dùng chung có thể vô tình làm rò rỉ thông tin về hoạt động của người dùng
- Nếu một người dùng cùng router Wi-Fi xem video dung lượng lớn, thời gian tải xuống của người dùng khác có thể chậm lại
- Biến động tiêu thụ điện năng hoặc bức xạ điện từ cũng có thể trở thành kênh kề để suy đoán khóa mã hóa hoặc hoạt động của người dùng
- Website fingerprinting là kiểu tấn công trong đó website của kẻ tấn công ở một tab cố gắng nhận diện website nạn nhân đang mở ở tab khác
- Nghiên cứu trước đây của Shusterman et al. trình bày một cuộc tấn công dùng CPU cache để đoán website đang mở trong 100 website ứng viên
- Kẻ tấn công tạo một mảng có kích thước bằng CPU cache và điền toàn bộ bằng 1
- Trong khi website nạn nhân đang tải, cứ mỗi 2ms lại đo thời gian truy cập mảng
- Trong 15 giây, tổng cộng thu thập 7.500 giá trị đo
- Vì mỗi website thường lặp lại các mẫu script, hình ảnh, stylesheet và render tương tự nhau, trace đo được có thể được dùng như dấu vân tay
- Thu thập 100 trace cho mỗi website trong 100 website, tạo thành tập dữ liệu có nhãn gồm tổng cộng 10.000 mẫu, rồi huấn luyện mô hình machine learning
- Đạt độ chính xác tối đa 91,4% trên nhiều trình duyệt và hệ điều hành
Tấn công bằng bộ đếm khi loại bỏ cache
- Trong lần tái triển khai ban đầu, việc phân loại 4 website khá dễ, và một bộ phân loại Random Forest đơn giản đạt độ chính xác 98%
- Khi mở rộng thử nghiệm lên 10 website, ban đầu độ chính xác là 75%, nhưng sau đó được cải thiện tới mức phân loại 10, 50 và 100 website
- Thay đổi mang tính quyết định là bỏ truy cập mảng cache và để kẻ tấn công lặp
value++nhanh nhất có thể- Nếu lưu giá trị bộ đếm theo từng khoảng thời gian, trace sẽ cho biết máy tính đã thực thi được bao nhiêu trong khoảng đó
- Các hoạt động khác như thay đổi kích thước cửa sổ trình duyệt hoặc mở tab mới cũng được phản ánh trong trace bộ đếm
- Trong bài báo, giá trị được lưu mỗi 5ms để thu được nhiều thông tin hơn trong một khoảng thời gian cố định
- Mô hình được huấn luyện bằng trace bộ đếm cho thấy độ chính xác nhận diện website cao hơn trace độ trễ cache trước đây
- Kết quả này đặt ra nghi vấn liệu cuộc tấn công trước đó có thực sự khai thác tranh chấp cache hay không, và dẫn tới phân tích nhằm tìm nguyên nhân
Khoảng cách giữa độ chính xác mô hình và phân tích nguyên nhân
- Trong các cuộc tấn công kênh kề được hỗ trợ bởi machine learning, việc mô hình dự đoán ổn định hoạt động của người dùng chỉ cho thấy sự tồn tại của tín hiệu
- Độ chính xác cao không chứng minh tín hiệu đó đến từ kênh kề nào
- Dù mô hình của Shusterman et al. đoán đúng website nạn nhân với độ chính xác 91,4%, điều đó không có nghĩa là nó đã bắt được tranh chấp CPU cache
- Thứ mô hình tìm ra là tương quan, chứ không giải thích nguyên nhân của tín hiệu
- Phân tích sai nguyên nhân có thể dẫn sai hướng khi thiết kế biện pháp phòng thủ
- Các nhà nghiên cứu thiết kế biện pháp phòng thủ để làm máy tính an toàn hơn dựa trên các bài báo tấn công
- Nếu hiểu sai nguyên nhân tấn công, thời gian và công sức có thể bị lãng phí
Kiểm chứng giả thuyết: tần số, lõi, interrupt
- Nhóm nghiên cứu so sánh cuộc tấn công dựa trên cache trước đây và cuộc tấn công mới dựa trên bộ đếm trong nhiều môi trường
- Trong bài toán nhận diện 100 website, tấn công dựa trên bộ đếm đạt độ chính xác cao hơn ở gần như mọi cấu hình thử nghiệm
- Trên Safari của macOS, tấn công cache đạt 72,6%, còn tấn công bộ đếm đạt 96,6%
- Ở cấu hình mặc định, website đúng trong 100 website được nhận diện với độ chính xác 95,2%
-
Giả thuyết co giãn tần số CPU
- CPU hiện đại tăng hoặc giảm tần số theo khối lượng công việc để tiết kiệm năng lượng
- Nhóm đặt giả thuyết rằng tần số CPU thay đổi trong lúc website nạn nhân tải, khiến giá trị bộ đếm thay đổi
- Sau khi tắt co giãn tần số trong BIOS, họ thu thập dữ liệu mới và huấn luyện mô hình
- Độ chính xác chỉ giảm 1 điểm phần trăm, từ 95,2% xuống 94,2%, nên biến động giá trị bộ đếm khó có thể được giải thích bằng thay đổi tần số CPU
-
Giả thuyết tranh chấp lõi CPU
- Nếu tab của kẻ tấn công và tab nạn nhân chạy trên cùng một lõi CPU, việc tải tab nạn nhân có thể làm giảm thời gian thực thi bộ đếm của kẻ tấn công
- Dùng
tasksettrên Linux để cố định kẻ tấn công và nạn nhân chạy trên các lõi khác nhau - Ngay cả khi đã tắt co giãn tần số CPU, độ chính xác vẫn duy trì ở 94,0%
- Vì vậy, tranh chấp lõi CPU cũng khó được xem là nguyên nhân chính
-
Giả thuyết interrupt hệ thống
- Giả thuyết tiếp theo là interrupt hệ thống chính là tín hiệu của tấn công dựa trên bộ đếm
- Hệ điều hành dùng interrupt để giao tiếp với các thiết bị phần cứng như bàn phím, chuột, màn hình và card mạng
- Khi interrupt đến một lõi CPU, chương trình đang chạy trên lõi đó lập tức dừng lại và interrupt handler được thực thi
- Trong khi website nạn nhân tải, nhiều thiết bị như mạng và đồ họa phát sinh interrupt; nếu chúng được xử lý trên cùng lõi với kẻ tấn công, giá trị bộ đếm của kẻ tấn công có thể giảm
- Trên Linux có thể kiểm tra việc xử lý interrupt bằng
cat /proc/interrupts
Interrupt có thể di chuyển và không thể di chuyển
- Linux có thể định tuyến một số interrupt có thể di chuyển tới một lõi cụ thể
- Các interrupt có ID dạng số thuộc loại này
- Chúng thường đến từ các thiết bị phần cứng bên ngoài như bàn phím hoặc card mạng
- Nhiều interrupt không thể di chuyển không thể được cô lập vào một lõi cụ thể
- Các interrupt có ID gồm ba chữ cái thuộc loại này
- Vì được dùng để đồng bộ hoạt động giữa các lõi CPU, chúng phải được xử lý trên mọi lõi
- Trong môi trường thử nghiệm, chúng chiếm phần lớn hoạt động interrupt
- Dùng
irqbalanceđể gửi các interrupt có thể di chuyển tới lõi 1, và dùngtasksetđể cho kẻ tấn công và nạn nhân chạy trên lõi 2 và 3 - Khi tần số CPU cũng được cố định, độ chính xác giảm gần 6 điểm phần trăm, khiến giả thuyết interrupt trở nên thuyết phục hơn
Xác nhận nguyên nhân thực sự bằng eBPF
- Vì về mặt kiến trúc hệ điều hành không thể thực hiện thí nghiệm cô lập hoàn toàn cả các interrupt không thể di chuyển, nhóm đã đo đạc quá trình thực thi bằng eBPF
- Thông qua eBPF, họ ghi lại hai loại thời điểm
- Thời điểm chương trình của kẻ tấn công bắt đầu và dừng
- Thời điểm interrupt handler bắt đầu và dừng
- Vì tần số CPU đã được cố định, nếu kẻ tấn công không bị cản trở thì trong một khoảng thời gian cố định nó phải thực thi gần như cùng một số lệnh
- Bằng mã eBPF do Jonathan Behrens viết, nhóm so sánh các đoạn kẻ tấn công bị dừng với các đoạn xử lý interrupt
- Hơn 99% các đoạn gián đoạn thực thi của kẻ tấn công kéo dài từ 100ns trở lên được xác nhận là thời gian xử lý interrupt
- Lõi CPU của kẻ tấn công thực chất gần như luôn ở một trong hai trạng thái: chạy mã đếm hoặc xử lý interrupt; khi thời gian xử lý interrupt giảm thì giá trị bộ đếm tăng, và khi thời gian đó tăng thì giá trị bộ đếm giảm
Hai kết quả chính của bài báo
- Kết quả đầu tiên là interrupt hệ thống làm rò rỉ hoạt động của người dùng
- Các thuộc tính bảo mật của interrupt hệ thống chưa từng được nghiên cứu trong tài liệu trước đây
- Nhóm nghiên cứu lần đầu tiên phân tích kênh kề dựa trên interrupt hệ thống
- Kết quả thứ hai là cần phân tích thận trọng các cuộc tấn công kênh kề được hỗ trợ bởi machine learning
- Mô hình machine learning có thể tạo ra một cuộc tấn công mạnh ngay cả khi không hiểu kênh kề
- Nếu không đo đạc hệ điều hành, đã không thể kết luận cuộc tấn công đang sử dụng kênh kề nào
- Biện pháp phòng thủ trước đây cho tấn công dựa trên cache là liên tục evict CPU cache để thêm nhiễu
- Một biện pháp phòng thủ tạo ra nhiều interrupt, chẳng hạn gửi yêu cầu mạng tới địa chỉ IP cục bộ, hoạt động tốt hơn với cả tấn công dựa trên cache lẫn tấn công dựa trên bộ đếm
- So sánh này củng cố bằng chứng rằng cuộc tấn công của Shusterman et al. chủ yếu sử dụng tín hiệu interrupt hơn là cache
Thử nghiệm bổ sung và khả năng phòng thủ
- Bài báo cũng bao gồm các kết quả bổ sung
- Đề xuất cách giảm nhẹ hoàn toàn cuộc tấn công bằng cách chỉnh sửa clock của trình duyệt cung cấp cho JavaScript
- Thực hiện thí nghiệm cô lập kẻ tấn công và nạn nhân trong các máy ảo riêng biệt
- Phân tích tần suất và thời gian xử lý của nhiều interrupt không thể di chuyển
- Trình duyệt giảm độ chính xác của clock cung cấp cho JavaScript để làm khó các cuộc tấn công dựa trên timing độ chính xác cao
- Chrome làm tròn theo đơn vị 0,1ms và thêm nhiễu ngẫu nhiên
- Firefox và Safari làm tròn theo đơn vị 1ms
- Tor Browser làm tròn theo đơn vị 100ms, hạ độ chính xác tấn công từ 96,6% của Chrome xuống 49,8%
- Việc giảm độ chính xác của clock có đánh đổi
- Các game engine chạy trên trình duyệt cần timer độ chính xác cao cho render và animation
- Người dùng Tor Browser khó chơi phần lớn trò chơi, nhưng điều này có thể không phải vấn đề với những người ưu tiên bảo mật
Các câu hỏi nghiên cứu còn bỏ ngỏ
- Interrupt hệ thống liên quan tới các cơ chế phần cứng nằm sâu trong máy tính hiện đại, giống như Spectre và Meltdown
- Hiện chưa thể triển khai biện pháp phòng thủ cô lập interrupt không thể di chuyển khỏi kẻ tấn công, và cũng chưa rõ phải thiết kế lại máy tính như thế nào để làm được điều đó
- Mối quan hệ giữa hoạt động website và interrupt cũng chưa được hiểu đầy đủ
- weather.com gây ra nhiều rescheduling interrupt, nhưng nytimes.com và amazon.com thì không
- Chưa phân tích các hình ảnh, quảng cáo và script bổ sung ảnh hưởng thế nào tới trace bộ đếm
- Cuộc tấn công có thể trở nên mạnh hơn
- Bài báo giống “bài báo phân tích” hơn là “bài báo tấn công”
- Độ chính xác 96,6% đạt được trên Chrome/Linux có thể là cận dưới chứ không phải cận trên
- Vẫn còn khả năng áp dụng vào các bài toán như phân loại 1.000 website, xác định có xem phim hay không, có dùng VPN hay không, hoặc tần suất kiểm tra Robinhood, bằng mô hình tốt hơn hoặc phương pháp luận khác
- Các biện pháp phòng thủ dựa trên trình duyệt cũng cần được triển khai trên trình duyệt thực tế và đánh giá xem có thực dụng với người dùng phổ thông hay không
Ảnh hưởng của nghiên cứu tới con đường cá nhân
- Trước dự án này, học cao học chưa từng là một lựa chọn nghiêm túc; sau kỳ thực tập nghiên cứu deep learning tại NVIDIA, tác giả từng nghĩ tới việc làm ở các công ty công nghệ lớn hoặc startup AI
- Sau dự án, tác giả có được trải nghiệm rằng nghiên cứu có thể thú vị và đẹp đẽ
- Sau khi tốt nghiệp MIT, tác giả học thêm một năm chương trình MEng ngành khoa học máy tính, rồi nhận Rhodes scholarship và học 2 năm tại University of Oxford
- Năm sau, tác giả dự định bắt đầu chương trình PhD khoa học máy tính kéo dài 6 năm tại MIT
1 bình luận
Các ý kiến trên Hacker News
Bài viết hay, và phần nghiên cứu phía sau cũng gọn gàng
Theo tôi, đóng góp của bài báo thật ra không liên quan nhiều đến machine learning, mà nằm ở việc tìm ra một kênh kề mới dùng interrupt
Ở đây machine learning gần như chỉ đóng vai trò thu hút độc giả hơn; nếu gọi tương tự là “thống kê” thì có lẽ cũng không khác mấy
Tôi nhớ trước đây giáo sư hướng dẫn từng nói: “Khi em biết bài báo thực sự nói về điều gì, hãy viết lại và lược bỏ những phần trước đó em tưởng là chủ đề”
Tôi nghĩ tiêu đề của bài báo này đáng ra nên tập trung vào kênh kề mới hơn là câu chuyện machine learning. Dù vậy đây chỉ là bắt bẻ nhỏ, còn công trình thì rất xuất sắc
Lý do phát hiện về hiểu nhầm machine learning đặc biệt quan trọng là vì nó đặt dấu hỏi lên khá nhiều nghiên cứu kiến trúc máy tính hiện có
Trước đây, để thực hiện kiểu tấn công này, cần hiểu sâu kênh kề bị khai thác; nhưng các mô hình machine learning, ở đây là LSTM, vượt xa “thống kê” đơn giản và cho phép độ chính xác cao hơn nhiều, khiến việc tạo ra các cuộc tấn công mạnh khai thác những kênh kề chưa được hiểu rõ trở nên dễ dàng hơn
Ngày nay có khá nhiều cuộc tấn công được hỗ trợ bởi machine learning theo kiểu này, và chỉ riêng bài báo của Shusterman cùng cộng sự đã được trích dẫn gần 200 lần, một con số cực lớn đối với một bài báo về kiến trúc máy tính
Mục đích công bố những nghiên cứu như vậy là để hiểu hệ thống tốt hơn và xây dựng phòng thủ mạnh hơn; cái giá của việc hiểu sai rồi dẫn dắt cộng đồng đi chệch hướng là rất lớn
Điều này vẫn đúng ngay cả khi nguyên nhân của cuộc tấn công trước đó rốt cuộc được xác định là cache, nhưng nhờ trong quá trình ấy phát hiện ra một kênh kề mới, thông điệp đã rõ ràng hơn rất nhiều. Có lẽ bài blog có thể nhấn mạnh phần này hơn
Trong thực tế, khi bị nhấn chìm trong biển dữ liệu, kiến thức phổ thông như vậy có thể biến mất giữa lũ tương quan, nhưng thiết kế thí nghiệm tốt và phản biện đồng cấp vốn phải lọc ra các kết luận và diễn giải yếu kém
Theo nghĩa đó, nghiên cứu tái lập này đã làm rất tốt việc ấy
Bài viết tuyệt vời. Tôi không ngờ tấn công kênh kề lại có thể được giải thích dễ hiểu đến vậy
Đọc như một truyện trinh thám án mạng: ngay từ đầu đã biết kẻ xấu là ai, nhưng theo dõi để tìm ra “hắn đã làm bằng cách nào”
Đã cho vào mục yêu thích
Nhưng nhờ phản hồi này mà tôi đã đọc, và quả thật rất hay
Đoạn “Năm tới tôi sẽ quay lại MIT để bắt đầu chương trình tiến sĩ khoa học máy tính 6 năm. Tôi không thể hào hứng hơn!” thật đáng kinh ngạc
Điều ấn tượng là mọi chuyện bắt đầu từ một ý tưởng may mắn của tác giả: thay vì dùng cuộc tấn công đẩy cache tinh vi hơn nhiều của tấn công kênh kề ban đầu, thử dùng counter kiểu ngẫu nhiên; và nhờ những khái niệm mà khi đó tác giả chưa biết, cách đó lại hiệu quả
Có lẽ tôi là một trong hàng nghìn người không có may mắn như vậy, nên đã sớm từ bỏ ý định ở lại học thuật, chuyển sang ngành và có một sự nghiệp bình thường
Tôi bắt đầu một Honours Degree ngành khoa học máy tính kiểu Úc, gần giống thạc sĩ, và khoảng năm 2010, tức rất lâu trước cơn sốt AI hiện nay, tôi muốn viết một bài báo về trí tuệ nhân tạo dựa trên các ví dụ ứng dụng học được trong một môn AI chính quy
Tôi muốn bắt đầu từ cách các winery dùng AI để cải thiện chất lượng và sản lượng rượu vang, rồi áp dụng sang những ứng dụng “tổng quát” hơn, nhưng giáo sư hướng dẫn được phân cho tôi hoàn toàn không có hứng thú giúp đỡ, và không có hỗ trợ nào khác nên rất khó tiếp tục
Đặc biệt là khi tôi có một lời mời làm việc toàn thời gian với mức lương khá tốt, và dù có tiếp tục thì có lẽ tôi cũng chẳng đạt được gì nhiều
Như tác giả cũng nói, mọi việc thuận lợi là nhờ giáo sư hướng dẫn và sự giúp đỡ xung quanh; còn một mình thì cần động lực và tài năng khổng lồ, mà tôi nghĩ mình thiếu cả hai
Khi làm chương trình tiến sĩ đầu tiên ở Nhật, trong 3 năm, giáo sư và những người xung quanh chỉ phê bình mọi thứ tôi đề xuất mà không đưa ra ý tưởng khả thi nào
Một giáo sư ở phòng thí nghiệm bên cạnh thích nghiên cứu của tôi, nhưng tôi biết điều đó quá muộn để chuyển phòng thí nghiệm
Giờ tôi đang ở một nơi có thể làm việc với một nửa số người trên cả nước có thể hoàn toàn hiểu và quan tâm đến dự án khác của tôi, tức tổng cộng 2 người, và dữ liệu của họ đã giúp dự án tốt hơn rồi
Viện trưởng cũng có thiện cảm với tôi nên cho tôi tham gia các hoạt động của phòng thí nghiệm dù tôi không thuộc biên chế chính thức
Trong môi trường như thế này thì có thể thành công. Tìm đúng môi trường và đúng người rất khó nhưng mang tính quyết định; nếu không, ngay cả công việc rất tốt cũng có thể thành công cốc
Bài viết hay
Một góp ý cực nhỏ liên quan đến trang: kiểu đường phân cách bằng các chấm lớn nối tiếp nhau trông giống chỉ báo vị trí của carousel ảnh, nên hơi gây nhầm lẫn
Bài viết rất xuất sắc, cách giải thích cực kỳ dễ tiếp cận và demo tương tác cũng thật sự tuyệt
Tôi cũng thích phần kể bối cảnh vì sao tác giả bắt đầu làm việc này
Rất thú vị và được giải thích tốt. Nếu nghiên cứu đã ra được 2 năm thì các bên thu thập dữ liệu quan tâm hẳn đã tính đến rồi
Quên hacker đi. Đây là exploit dành cho doanh nghiệp và chính phủ
Liệu một website coi trọng quyền riêng tư có thể phát hành một gói tạo interrupt ngẫu nhiên không? Một tiện ích mở rộng trình duyệt có thể làm vậy cho mọi trang web không?
Biện pháp đối phó tạo interrupt ngẫu nhiên của chúng tôi được triển khai dưới dạng tiện ích mở rộng trình duyệt, và mã nguồn ở đây: https://github.com/jackcook/bigger-fish
Tuy nhiên khó mà khuyên dùng hằng ngày. Tôi nhớ trong thử nghiệm, thời gian tải trang chậm hơn khoảng 10%
Một số demo thay đổi khá nhiều khi máy tính được sử dụng nặng, nhưng có vẻ Safari có thể đã có sẵn một số biện pháp giảm thiểu
Dù vậy bài báo thật sự rất hay