Hướng dẫn không chính thức của Soatok về mô hình đe dọa
(soatok.blog)- Mô hình đe dọa không dừng ở việc ghi ra đối tượng cần bảo vệ và kẻ tấn công; nó chỉ hữu ích cho các quyết định thiết kế khi làm rõ cả quan hệ giữa tài sản, các giả định và những mối đe dọa bị cố ý loại trừ
- Một mô hình tốt xem tài sản như một đồ thị chứ không phải danh sách, đồng thời thu hẹp dần đầu vào, đầu ra và phụ thuộc của các component để kiểm tra rủi ro và tiền đề
- Khi giả định bị phá vỡ, các rủi ro đã chấp nhận cũng phải được xem xét lại; cuộc tấn công Invisible Salamanders trở thành vấn đề khi tính năng báo cáo lạm dụng trong E2EE xung đột với giả định “mỗi thông điệp có 1 khóa hợp lệ” của AEAD
- Trường hợp publickey.directory tách riêng giả định, tài sản, tác nhân và trạng thái rủi ro, nhưng không hoàn hảo; mô hình đe dọa của Matrix v1.18 gần với một danh sách kiểu tấn công hơn và thiếu phần mã hóa, quản lý khóa
- Mô hình hóa đe dọa giúp tách các ràng buộc của lựa chọn công nghệ khỏi rủi ro thực tế trong các chủ đề như xác thực passkey, thiết kế E2EE phân tán và tranh luận PQC, từ đó hỗ trợ quyết định thiết kế tốt hơn
Những câu hỏi mà mô hình đe dọa phải trả lời
- Mô hình đe dọa có thể là một quy trình an ninh mạng chính thức, nhưng cũng có thể được thực hiện không chính thức ở giai đoạn thiết kế và kiến trúc của sản phẩm hoặc dịch vụ mới
- Tối thiểu phải trả lời các câu hỏi sau
- Bảo vệ cái gì
- Ai hoặc điều gì đang cố gây hại cho đối tượng được bảo vệ
- Kẻ tấn công có thể tấn công bằng cách nào
- Sẽ làm gì để ngăn các cuộc tấn công đó
- Chỉ với bốn điểm này cũng có thể gọi là mô hình đe dọa, nhưng trong thực tế dễ bỏ sót các chi tiết quan trọng
- Các câu hỏi cần bổ sung gồm
- Các tài sản cần bảo vệ được kết nối với nhau như thế nào
- Đang đưa ra những giả định nào
- Những mối đe dọa nào được cố ý không xử lý
- Không thể xử lý mọi cuộc tấn công trong tương lai, nên cần nêu rõ các mối đe dọa bị loại trừ
- Nếu giả định sai, mô hình sẽ không đầy đủ, và danh sách rủi ro đã chấp nhận cũng phải được rà soát lại
- Mô hình đe dọa không nên là ảnh chụp tại một thời điểm cụ thể, mà phải là một tài liệu sống được cập nhật khi cần
Vấn đề phát sinh khi giả định bị phá vỡ
- Invisible Salamanders attack có thể phá vỡ tính năng báo cáo lạm dụng khi tính năng này được đưa vào một số thiết kế nhắn tin E2EE
- Cuộc tấn công này gắn với các giả định của những scheme AEAD như AES-GCM, ChaCha20-Poly1305
- Các scheme đó chứa giả định rằng có một khóa hợp lệ cho một thông điệp cụ thể
- Nếu đưa nhiều khóa hợp lệ vào một thông điệp, hoặc tạo ra confused deputies, bạn sẽ đi ra ngoài các đảm bảo bảo mật của thuật toán
- Việc ghi rõ giả định giúp nhận diện các unknown unknowns của chính mình
- Không cần hoàn hảo, nhưng phải rõ ràng về những gì được lấy làm tiền đề
Quy trình bắt đầu mô hình hóa đe dọa
- Nếu muốn mô hình hóa đe dọa một cách chuyên nghiệp, nên đọc Threat Modeling Manifesto
- Trong thực tế, hãy bắt đầu bằng cách ghi nhanh 7 mục ở một định dạng có thể sao chép để dùng
- Sau đó vẽ các component của hệ thống cần phân tích trên giấy hoặc bằng công cụ số
- Nếu widget nào giao tiếp trực tiếp, phụ thuộc hoặc tương tác với widget khác, hãy biểu diễn quan hệ đó
- Cách ký hiệu quan hệ chỉ cần là cách hữu ích nhất cho người thực hiện
- Bao toàn bộ đồ thị trong một hộp, rồi thu hẹp hộp dần để tập trung vào từng component
- Ở mỗi vòng lặp, ghi lại đầu vào và đầu ra của component
- Trả lời 7 câu hỏi nhiều nhất có thể
- Sau khi đi sâu đến mức trừu tượng cho phép, hãy brainstorm xem mình đang đưa ra những giả định nào về các tầng chưa đào sâu thêm
- Cơ sở dữ liệu có thể không phụ thuộc vào độ an toàn của X25519 theo cùng cách như load balancer
- Mục tiêu là ghi lại các quan hệ không phù hợp, chẳng hạn RSS feed đi vào cơ sở dữ liệu, và cắt bỏ nếu có thể
Trường hợp publickey.directory
- Công việc cung cấp key transparency cho Fediverse được theo dõi tại publickey.directory
- Công việc này bắt đầu từ đặc tả public-key-directory-specification, và đặc tả này có bao gồm mô hình đe dọa
- Mô hình đe dọa đó gồm các phần sau
- Giả định
- Tài sản
- Tác nhân và tên vai trò, bao gồm kẻ tấn công và những người cần bảo vệ
- Rủi ro và trạng thái rủi ro
- Trạng thái rủi ro được chia thành bốn loại
- Prevented by design: Cuộc tấn công không hoạt động do thiết kế
- Mitigated: Nếu các giả định không sai, cuộc tấn công không nên thành công
- Addressable: Có cách giảm thiểu, nhưng cần nỗ lực hoặc sự chú ý và operator phải biết
- Open: Rủi ro không thể giảm thiểu hoặc sẽ không được giảm thiểu, và cuộc tấn công đó sẽ thành công
- Mô hình đe dọa này cũng không hoàn hảo
- Chưa kết nối hoàn toàn quan hệ giữa tài sản và tác nhân thành một đồ thị dễ đọc với con người
- Phần rủi ro có thể có các điểm mù chưa được xét đến
- Có thể đã bỏ sót các giả định quan trọng đối với bảo mật hệ thống
So sánh Matrix và Signal
- Security Threat Model của Matrix v1.18 liệt kê các loại tấn công như từ chối dịch vụ, giả mạo, spam, theo dõi
- Tài liệu này có các vấn đề sau
- Gần với một danh sách kiểu tấn công
- Không có danh sách giả định
- Không có danh sách tài sản và quan hệ giữa các tài sản
- Danh sách tấn công không đầy đủ
- Dù Matrix được quảng bá là trình nhắn tin E2EE, mô hình đe dọa lại không xử lý mã hóa hoặc quản lý khóa
- Mô hình đe dọa của Matrix không thay đổi nhiều kể từ v1.1, trong khi ở giữa đã có các công bố lỗ hổng và hai cuộc tấn công mật mã học bổ sung của Lotte
- Dù vậy Matrix vẫn có mô hình đe dọa
- Signal cung cấp đặc tả kỹ thuật, nhưng mô hình đe dọa ở dạng người dùng phải tự suy ra
- Một mô hình đe dọa tệ vẫn tốt hơn không có mô hình đe dọa nào cả
Cách mô hình đe dọa cải thiện thiết kế
- Trong thực hành bảo mật, câu châm ngôn rằng người phòng thủ phải luôn đúng còn kẻ tấn công chỉ cần thành công một lần thường được nhắc đến
- Nếu người phòng thủ chuẩn bị đủ tốt, họ có thể quyết định địa hình mà kẻ tấn công phải di chuyển
- Defense-in-depth thực sự bao gồm việc hiểu đủ rõ mô hình đe dọa để dồn kẻ tấn công vào những ngõ cụt có thể dự đoán
-
Ngăn credential stuffing
- Credential stuffing là một cuộc tấn công đơn giản nhưng quá hiệu quả trong thực tế
- Nguyên nhân là mọi người tái sử dụng mật khẩu
- Vì người dùng khó nhớ nhiều mật khẩu riêng biệt và an toàn, trình quản lý mật khẩu từng là biện pháp giảm thiểu phù hợp trong một thời gian
- Hiện nay passkey được xem là lựa chọn tốt hơn
- Passkey là cách thân thiện hơn với người dùng để dùng mật mã bất đối xứng cho xác thực
- Trong trường hợp tốt nhất, sử dụng token bảo mật phần cứng như SoloKeys hoặc YubiKeys
- Trong trường hợp trung bình, hệ điều hành hoặc trình quản lý mật khẩu cung cấp điều này
- Để tránh các cuộc tấn công đơn giản tương tự credential stuffing, cần thiết kế như sau
- Thiết kế ứng dụng yêu cầu passkey
- Cho phép người dùng đăng ký nhiều passkey, hoặc tối thiểu yêu cầu một passkey dự phòng
- Cung cấp một đường dẫn break glass để quản trị viên có thể thêm passkey mới cho người dùng đã mất toàn bộ credential
- Ghi log thao tác quản trị đó theo cách quản trị viên không thể kiểm duyệt
- Nếu có thể, hoàn toàn không hỗ trợ mật khẩu dùng cho xác thực
- Mật khẩu dùng để dẫn xuất khóa mã hóa thì ổn trong ngữ cảnh riêng
- Passkey không thể bị phishing vì credential được ràng buộc bằng mật mã với tên miền khi đăng ký
- Dù có chi phí onboarding passkey, nó có thể giảm nhiều hơn gánh nặng hỗ trợ do credential stuffing và phishing gây ra
- Khi loại bỏ kỳ vọng phi thực tế rằng con người phải nhớ các bí mật entropy cao và không tái sử dụng chúng, ta có thể loại bỏ nhiều lớp tấn công và cải thiện cả tính dễ dùng
- Câu của Avi Douglen được trích dẫn: “Bảo mật đánh đổi khả dụng là đánh đổi chính bảo mật”
E2EE phân tán và mô hình đe dọa
- Có hai đề xuất đang được thảo luận cho E2EE trong tin nhắn trực tiếp
- ActivityPub E2EE specification, hướng tới DM riêng tư trong phần mềm Fediverse, ví dụ Mastodon
- Các dự án như Germ Network có cùng mục tiêu cho ATProto, ví dụ BlueSky
- Cả hai dự án đều từng cân nhắc dùng MLS làm giao thức quản lý khóa hội thoại E2EE ở một thời điểm nào đó
- Trong hệ thống phi tập trung, MLS có hai ràng buộc quan trọng
- MLS đặc tả một khái niệm trừu tượng gọi là Authentication Service
- Thứ tự thông điệp rất quan trọng đối với bảo mật của ratcheting tree đứng sau các epoch của MLS
- Với ràng buộc đầu tiên, nếu ActivityPub chấp nhận key transparency, nó phải chỉ rõ cách xử lý khi nhiều thông điệp KeyUpdate cạnh tranh trên nhiều server
- Tình huống của ATProto và BlueSky khó hơn
- ATProto không có các instance như Fediverse
- Trong phân tích bảo mật, gần như phải xem nó như P2P
- Có thể cần một giao thức phức tạp để đảm bảo thứ tự thông điệp trong hệ thống phân tán, chẳng hạn cách tiếp cận như Raft consensus algorithm
- Hoặc phải bỏ qua MLS và chọn pairwise E2EE, từ bỏ trừu tượng nhóm
- Nếu tính bí mật của tin nhắn giữa người dùng là mục tiêu bảo mật và muốn phân tán hosting, thiết kế kiểu blockchain của ATProto trở thành rào cản đối với việc dùng các giao thức thỏa thuận khóa nhóm hiệu quả đã được chuẩn hóa hiện nay
- Mô hình hóa đe dọa có thể làm lộ các ràng buộc thiết kế như vậy ngay từ giai đoạn bản vẽ ban đầu
Vai trò của mô hình hóa đe dọa thể hiện trong tranh luận PQC
- Liên quan đến hybrid post-quantum constructions, danh sách thư của nhóm làm việc IETF TLS đang thảo luận RFC thiết lập code point ML-KEM non-hybrid
- Các tiền đề của cuộc thảo luận như sau
- ML-KEM không phải do NSA thiết kế
- Người nộp chính là Peter Schwabe, từng hợp tác với Daniel J. Bernstein trong thư viện mật mã NaCl và sống tại Đức
- Các người nộp khác cũng ở nhiều khu vực châu Âu
- Như bài viết của Sophie Schmieg, lý thuyết thông tin loại trừ backdoor trong ML-KEM
- ML-KEM được chọn qua nỗ lực chuẩn hóa quốc tế công khai kéo dài 10 năm của NIST
- NIST, FIPS, NSA yêu cầu non-hybrid ML-KEM và ML-DSA trong các hệ thống mật
- Bản thảo IETF đó chỉ định non-hybrid ML-KEM và được đánh dấu Recommend=N
- RFC hybrid KEM dự kiến sẽ được đánh dấu Recommend=Y, và hybrid KEM được ưu tiên hơn non-hybrid KEM
- Các hệ thống đã cấu hình luôn dùng hybrid KEM sẽ không bị suy giảm bảo mật ngay cả khi RFC ML-KEM xuất hiện
- Google Chrome đã hỗ trợ non-hybrid ML-KEM, và điều này sẽ không thay đổi kể cả khi không có RFC của IETF
- Tác dụng thực tế của RFC này là gỡ các ràng buộc thủ tục cho những tổ chức phải tuân theo CNSA 2.0, FIPS 140-3 hoặc các quy tắc tương tự, và cần số RFC IETF ổn định thay vì Internet Draft
- Vấn đề này có thể phổ biến trong một số mảng kinh doanh, đặc biệt là những nơi bán cho khách hàng chính phủ
-
Khác biệt giữa Hybrid PQ+ECDH và Pure PQ
- Rủi ro đối mặt trong KEM không phải là “bẻ khóa mật mã sau Q-Day” mà là Harvest Now, Decrypt Later
- Q-Day được dùng như viết tắt chỉ thời điểm kẻ tấn công có máy tính lượng tử liên quan đến mật mã
- Có thể chia rủi ro như sau
- ECDH thuần, tức không có PQ, sẽ bị phá hồi tố vào Q-Day
- PQ thuần không bị phá vào Q-Day, với giả định thuật toán PQ không bị phá trước đó
- Hybrid PQ+ECDH là biện pháp hedge trước sự sụp đổ thuật toán trước Q-Day, nhưng sau Q-Day thì không có ích so với Pure PQ
- Việc ủng hộ ECDH + ML-KEM đồng nghĩa với việc thừa nhận ML-KEM là thuật toán an toàn về dài hạn
- Lý do ưu tiên hybrid có thể tóm gọn thành hai điểm
- Dễ chấp nhận hơn so với một thuật toán hoàn toàn xa lạ, giúp triển khai PQ nhanh hơn
- Có thể phòng trường hợp ML-KEM hoặc toàn bộ mật mã dựa trên lattice sụp đổ về thuật toán
- Để hedge theo cách chịu được cả máy tính lượng tử liên quan đến mật mã, cần hybrid PQ+PQ
- Nếu coi trọng đa dạng thuật toán, lập luận trung thực hơn sẽ gần với hybrid 3-way ML-KEM + HQC + ECDH
- ML-KEM là KEM dựa trên lattice và được cho là chịu được tấn công lượng tử
- HQC là KEM dựa trên code và được cho là chịu được tấn công lượng tử
- ECDH là cách đang được sử dụng hiện nay nhưng dễ bị tấn công lượng tử
- Mô hình hóa đe dọa có thể được dùng trong các cuộc tranh luận như vậy để tách phản đối mang tính ý thức hệ khỏi rủi ro kỹ thuật khi đánh giá
Kết luận
- Trên Internet có nhiều hướng dẫn xử lý chính thức mô hình đe dọa và các phương pháp liên quan
- Mục tiêu ở đây là có một smoke test để nhanh chóng sàng lọc chất lượng và hiệu quả của tài liệu mô hình đe dọa
- Một mô hình đe dọa tốt phải vượt ra ngoài đối tượng cần bảo vệ, kẻ tấn công, phương thức tấn công và biện pháp phòng thủ, đồng thời làm rõ quan hệ tài sản, giả định và rủi ro đã chấp nhận
1 bình luận
Các ý kiến trên Lobste.rs
“Sự thiếu thân thiện” là một lý do hợp lệ để báo cáo bình luận, nhưng nếu muốn làm cho Internet kỹ thuật trở nên tốt hơn, có lẽ chúng ta nên ngừng tiêu thụ và ngừng đề xuất giọng điệu công kích mà tác giả này quá thường xuyên dùng trên blog. Thậm chí cũng đáng cân nhắc cấm hẳn tên miền đó
Và tôi nghĩ một giao thức kiểu “mọi thứ đều là đồ thị” thực sự nên được xem như một dự án nghiên cứu. Kết luận rốt cuộc là “ôi, hóa ra các thuật toán đồ thị thực sự rất khó để suy luận”