- Việc Cloudflare quảng bá số ngẫu nhiên dựa trên đèn lava gần với marketing và trình diễn bảo mật hơn là đóng góp thực chất lớn cho mã hóa Internet
- Trong mật mã học, điều quan trọng không phải là tính ngẫu nhiên nội tại của giá trị mà là kẻ tấn công biết bao nhiêu về giá trị đó, và chính sự chênh lệch về tri thức này quyết định độ an toàn
- One-time pad che giấu thông tin của bản rõ nếu dùng khóa đủ ngẫu nhiên và chỉ dùng một lần, nhưng sẽ bị phá vỡ nếu tái sử dụng cùng một khóa vì nó kết hợp với thông tin đã bị quan sát
- Các hệ thống hiện đại dùng CSPRNG và stream cipher thay cho one-time pad, và ChaCha20 hay AES-256-CTR cung cấp mức an toàn thực tế với khóa 256 bit
- true RNG vật lý khó loại bỏ độ lệch và mức tăng bảo mật cũng nhỏ, nên thiết kế đơn giản hơn là để máy chủ tự tạo seed và dùng fast key erasure sẽ an toàn hơn
Tính ngẫu nhiên phụ thuộc vào tri thức của người quan sát hơn là bản thân đối tượng
- Cloudflare quảng bá rằng lava lamp giúp ích cho mã hóa Internet, nhưng cách làm này gần với marketing và trình diễn bảo mật hơn là đóng góp lớn cho an ninh
- Ngoài lava lamp, Cloudflare còn dùng các thiết bị tạo tính khó dự đoán vật lý như double pendulums, wave motion, mobiles
- Hàm kiểu XKCD chỉ
return 4 nên bản thân nó không ngẫu nhiên vì luôn trả về 4, nhưng nếu người gọi chỉ biết thông tin rằng đó là “một hằng số được chọn bằng xúc xắc công bằng” và chỉ gọi một lần, thì trong phân phối xác suất của người quan sát nó vẫn có thể được xem là ngẫu nhiên
- Trong mật mã học, câu hỏi quan trọng không phải là kết quả có ngẫu nhiên về bản chất hay không, mà là kẻ tấn công biết bao nhiêu về kết quả đó
- Cùng một giá trị nhưng ý nghĩa của tính ngẫu nhiên thay đổi tùy theo ai đang nắm thông tin gì, và trong hệ mật mã, chính chênh lệch về tri thức đó quyết định độ an toàn
Cách one-time pad hoạt động và bị phá vỡ
- Trong phép so sánh với trò Russian roulette, đồng phạm biết vị trí viên đạn và chỉ công bố ra ngoài kết quả sau khi cộng vị trí viên đạn với giá trị xúc xắc đã chia sẻ trước với người chơi
- Người chơi có thể khôi phục vị trí viên đạn bằng cách lấy giá trị đã hô trừ đi giá trị xúc xắc, nhưng đối phương không biết giá trị xúc xắc nên không thể suy ra vị trí viên đạn chỉ từ giá trị được hô
- Nếu xúc xắc là công bằng, thì xác suất tiên nghiệm
P(Ci) mà đối phương có và xác suất hậu nghiệm P(Ci|S3) sau khi nghe một con số cụ thể S3 sẽ bằng nhau
- Theo công thức Bayes,
P(Ci|S3) = P(Ci) × 1/6 ÷ 1/6 = P(Ci); do đó đối phương không học được thêm thông tin nào dù đã nghe giá trị được hô
- Đây chính là cốt lõi của One-time pad: nếu kết hợp thông điệp với một khóa đủ ngẫu nhiên và chỉ dùng một lần, bản mã sẽ không để lộ thông tin về bản rõ
- Nếu tái sử dụng cùng khóa đó cho ván chơi thứ hai, thì vì thông tin đã lộ ra ở ván đầu, đối phương có thể thu hẹp phạm vi khả năng của giá trị xúc xắc
- Nếu ở ván đầu đã xác nhận bốn khoang đầu của khẩu súng đều trống, đối phương sẽ biết chỉ còn khả năng xúc xắc là 3 hoặc 4; và nếu ở lần thứ hai đồng phạm hô “Four”, đối phương sẽ còn suy ra được viên đạn nằm ở khoang đầu tiên hoặc khoang cuối cùng
- One-time pad đúng như tên gọi chỉ an toàn một lần; nếu tái sử dụng cùng khóa, bản mã quan sát được sẽ kết hợp với thông tin trước đó và làm sụp đổ độ an toàn
Độ dài khóa và mức an toàn thực tế của mật mã hiện đại
- Trên Internet, thay vì gửi vị trí viên đạn, ta gửi bit và byte; một thông điệp một bit kiểu “yes/no” có thể được che giấu bằng một lần tung đồng xu
- Nếu ra mặt ngửa thì giữ nguyên thông điệp, còn nếu ra mặt sấp thì đảo “yes” và “no”; với người quan sát không biết kết quả đồng xu, cách này che giấu được bản rõ
- Nhưng nếu dùng cùng một kết quả tung đồng xu để mã hóa hai bit, thì bản mã sẽ rút gọn bốn khả năng bản rõ xuống còn hai
- “Yes yes” có nghĩa bản rõ là “yes yes” hoặc “no no”
- “No no” có nghĩa bản rõ là “no no” hoặc “yes yes”
- “Yes no” có nghĩa bản rõ là “yes no” hoặc “no yes”
- “No yes” có nghĩa bản rõ là “no yes” hoặc “yes no”
- Nói tổng quát, khi mã hóa n bit bằng chỉ một lần tung đồng xu, không gian bản rõ khả dĩ sẽ bị thu từ
2^n xuống còn 2
- Theo nghĩa thông tin học hoàn hảo, để mã hóa đúng n bit thì cần khóa n bit; với thông điệp dài hơn mức đó, một phần sẽ bị giải lộ, và nếu người quan sát đã biết trước hơn n bit thông tin thì thường có thể khôi phục toàn bộ
- Có vẻ như để áp dụng one-time pad cho toàn bộ lưu lượng mà Cloudflare xử lý thì sẽ cần lượng số ngẫu nhiên khổng lồ, nhưng các hệ thống hiện đại không dùng one-time pad
- Nếu dùng đúng authenticated encryption và stream cipher, khóa 256 bit có thể mã hóa một lượng lớn dữ liệu một cách an toàn trong thực tế
- Với các stream cipher phù hợp như ChaCha20 hay AES-256-CTR, một người quan sát thụ động sẽ phải thử khoảng
2^255 tổ hợp để tìm ra bản rõ
- Với người biết khóa, chuỗi đầu ra là hoàn toàn có thể dự đoán; nhưng với người quan sát ở cấp độ nền văn minh trên Trái Đất không biết khóa, nó hoạt động như “entropy” hoàn toàn không thể dự đoán
- Tên chính thức của cách này là Cryptographically Secure Pseudo-Random Number Generator, viết tắt là CSPRNG
Tạo số ngẫu nhiên thực tế và fast key erasure
- Để suy ra lượng số ngẫu nhiên cần thiết từ một master key 256 bit, có thể đặt master key trong máy chủ trung tâm hoặc hardware security module, tạo local key stream và phân phối an toàn trong toàn công ty
- Mỗi máy chủ hoặc mỗi lõi CPU có thể tạo ra số byte ngẫu nhiên cần thiết bằng local key 256 bit và một bộ đếm
- Vấn đề cốt lõi là phân phối an toàn cực kỳ khó
- Nếu local key bị lộ, mọi thông điệp mà máy đó đã mã hóa trong quá khứ và sẽ mã hóa trong tương lai đều gặp rủi ro; nếu master key bị lộ, thiệt hại còn lớn hơn nhiều
- fast key erasure là quy trình nhằm giảm khả năng lộ khóa và giảm mức thiệt hại khi khóa bị lộ
- Đặt một seed ngẫu nhiên 32 byte ở đầu bộ đệm 512 byte
- Dùng seed đó sinh ra 512 byte để ghi đè toàn bộ bộ đệm
- Xuất phần còn lại trừ 32 byte đầu theo yêu cầu rồi xóa đi
- Khi dùng hết bộ đệm thì quay lại bước sinh mới
- “erasure” xuất phát từ việc giai đoạn sinh mới sẽ xóa mất khóa cũ
- Nếu bộ đệm bị lộ, các thông điệp tương lai có thể gặp nguy cơ, nhưng các giá trị quá khứ đã được xuất ra rồi xóa thì vẫn được bảo vệ
- Điểm cần lưu ý quan trọng hơn là không sao chép bộ đệm
- Không được tạo hai stream từ cùng một seed
- Khi fork process, cần tách stream đúng cách thành hai phần
- Nếu có từ hai stream giống nhau trở lên, các byte ngẫu nhiên trùng lặp có thể lặp lại và gây hậu quả nghiêm trọng
- Vì vậy RNG ở user space không được khuyến nghị; RNG trong kernel tuy không hề đơn giản nhưng có ít đối tượng cần audit hơn
Lựa chọn stream cipher và biên độ an toàn
- Kích thước khối nội bộ của stream cipher nền tảng cũng quan trọng
- Khối 512 bit của ChaCha20 đủ lớn để không cần lo, và khối 128 bit của AES cũng đủ lớn
- Với AES, đã có các tấn công thực tế tốt hơn nhiều so với brute force đơn thuần; AES-128 có thể bị phá, còn AES-256 được xem là an toàn
- Kích thước khối nhỏ hơn nữa thì trong trường hợp sử dụng này nên xem như đã bị phá
- Lựa chọn được khuyến nghị là ChaCha20 hoặc AES-256, và ưu tiên nghiêng về ChaCha20
- Stream cipher hiện đại rất an toàn, và nếu xét tài liệu học thuật cùng các trường hợp sử dụng của nhiều chính phủ, đặc biệt là Mỹ, thì khả năng chúng bị phá trong tương lai gần là rất thấp
- Cả CSPRNG lẫn mã hóa đều phụ thuộc vào mật mã, nên nếu một trong hai bị phá thì toàn bộ hệ thống cũng bị phá
- Nếu giả định rằng khả năng AES-256 hoặc ChaCha20 bị phá trong tương lai gần là đáng kể, vẫn có vài cách để tăng biên độ an toàn
- Nếu dùng cùng một mật mã cho cả CSPRNG và mã hóa, thì thay vì cho kẻ tấn công lựa chọn phá AES hoặc ChaCha, ta buộc họ phải phá đúng một loại cụ thể
- Tăng số vòng không chỉ làm tăng chi phí brute force mà còn giúp ngăn các tấn công tốt hơn brute force
- AES-256 dùng 14 vòng, ChaCha20 dùng 20 vòng
- Có tấn công tốt hơn exhaustive search đối với ChaCha7, nhưng hiện chưa có tấn công như vậy với ChaCha8
- ChaCha20 dùng 20 vòng để có dư địa an toàn, nên kể cả nếu đột ngột xuất hiện tấn công trên 12 vòng thì cũng không thành vấn đề
- Cách dùng nhiều hệ thống song song sẽ làm tăng mạnh độ phức tạp tổng thể, và chính độ phức tạp đó có khả năng tạo ra lỗ hổng nghiêm trọng cao hơn cả một cuộc tấn công toán học vào một thành phần riêng lẻ
true RNG vật lý và seed ban đầu
- Cần thận trọng với ý nghĩ rằng true RNG vật lý an toàn hơn CSPRNG chỉ vì CSPRNG về mặt lý thuyết có thể bị phá
- Đầu ra ngẫu nhiên thường cần không có độ lệch có thể phát hiện được để đảm bảo an ninh; điều này có nghĩa là phân phối phải đủ đồng đều đến mức ngay cả khi phân tích
2^64 mẫu cũng không phát hiện ra độ lệch
- Rất khó tinh chỉnh một quá trình vật lý đến mức đó, nên trên thực tế người ta phải đưa đầu ra của nguồn nhiễu qua một hàm băm mật mã
- So với stream cipher dùng fast key erasure, mức tăng bảo mật là nhỏ, còn chi phí hiệu năng thì có thể lớn tùy nhu cầu
- Để tạo ra một lượng số ngẫu nhiên bất kỳ, vẫn cần vài byte seed ban đầu
- Có thể ghi lại số hóa một nguồn khó dự đoán trong thời gian đủ dài để thu được hơn 256 bit entropy, rồi băm bản ghi đó bằng hàm băm 256 bit như SHA-256 hoặc BLAKE2s để tạo master seed
- Các nguồn ngẫu nhiên khả dĩ gồm hardware random number generator, CPU jitter, ảnh chụp ngẫu nhiên của cây, beam splitter, thao tác gõ phím hoặc sự kiện chuột, xúc xắc, v.v.
- Việc phân phối số ngẫu nhiên giữa các site là không thực tế; nó không chỉ phức tạp mà còn có thể trở thành nguyên nhân của sự cố xâm nhập
- Số ngẫu nhiên không chỉ cần một lần, mà còn cần mỗi khi nghi ngờ có xâm nhập hoặc khi thực hiện cập nhật bảo mật quan trọng
- Để giảm phiền toái và rủi ro, nhìn chung tốt hơn là để chính máy tính đó tự tạo random seed cho việc sử dụng của mình thay vì lấy từ bên ngoài
- Máy chủ thông thường có CPU jitter, tương tác thiết bị ngoại vi và sự kiện mạng, nên thường là đủ cho mục đích phổ biến
- Nếu muốn tăng thêm bảo mật, có thể gắn vài dongle hardware RNG cho mỗi rack máy chủ, nhưng các cách phức tạp hơn thế là độ phức tạp không cần thiết
Vì sao bức tường đèn lava là không cần thiết
- Bức tường đèn lava của Cloudflare là không cần thiết, và nếu kết nối tới máy chủ qua mạng nội bộ thì nó chỉ làm tăng thêm độ phức tạp và bề mặt tấn công
- Nếu triển khai đúng cách, rủi ro có thể rất thấp, nhưng dù vậy rủi ro vẫn lớn hơn lợi ích đạt được
- Nếu Cloudflare thực sự nghiêm túc với bảo mật, họ nên ngừng dùng đèn lava cho mục đích bảo mật và chỉ giữ lại như vật trang trí và công cụ marketing
- Sẽ đơn giản hơn và an toàn hơn nếu mỗi máy chủ tự tạo số ngẫu nhiên
- Cũng có khả năng Cloudflare thực ra đã làm như vậy
1 bình luận
Ý kiến trên Lobste.rs
Bài này có vẻ vừa dựa trên hiểu nhầm, vừa hơi làm mất hứng. Bộ sinh số ngẫu nhiên hiện đại dùng nhiều nguồn entropy độc lập và liên tục trộn chúng vào entropy pool bằng hàm băm trong suốt thời gian máy tính hoạt động
Máy tính không có chỉ đúng một “hạt giống ngẫu nhiên”, mà trong lúc chạy sẽ liên tục được gieo lại bằng entropy từ nhiều nguồn theo kiểu
seed = hash(seed, new_data). Việc thêm dữ liệu camera chụp đèn lava hoàn toàn không làm giảm độ an toàn của hệ thống. Dữ liệu đưa vào entropy pool sẽ được băm cùng với dữ liệu khác đã có trong đó. Hệ thống được thiết kế để an toàn chỉ cần có dù là một lượng rất nhỏ thông tin mà kẻ tấn công không biết, nên việc trộn thêm nhiều dữ liệu có mức độ ngẫu nhiên khác nhau cũng không làm hỏng bảo mậtĐèn lava không gây hại cho bảo mật hệ thống, và cá nhân tôi xem đó là một tác phẩm nghệ thuật vui mắt nhưng vẫn có chức năng như một phần của hệ thống. Nó cũng cải thiện chất lượng số ngẫu nhiên ở mức cực nhỏ và giúp minh họa trực quan khái niệm ngẫu nhiên và entropy
Đúng, nhưng các bộ sinh số ngẫu nhiên trong kernel đã dùng nhiều dạng ngẫu nhiên từ phần cứng suốt hơn 30 năm nay, và tốt nhất không nên cường điệu chuyện nó được gieo lại “liên tục” hay “không ngừng nghỉ”
Tính ngẫu nhiên từ phần cứng được thu thập liên tục, nhưng bộ sinh số ngẫu nhiên của Linux được gieo lại theo chu kỳ. Trong phút đầu sau khi khởi động thì vài giây một lần, sau đó chậm lại còn khoảng một lần mỗi phút
https://zx2c4.com/projects/linux-rng-5.17-5.18/…
Tôi không rõ bài viết đã tạo ấn tượng ở đâu rằng nó đang nói hay ám chỉ các hệ thống hiện có không làm vậy. Ở đây, ngoài phần đèn lava ra, mục tiêu không phải là mô tả hệ thống hiện có mà là nhấn mạnh rằng thứ chúng ta thực sự cần là rất ít, tức chỉ 256 bit là đủ
Khi nói thêm dữ liệu camera chụp đèn lava không làm giảm bảo mật, tôi lại nghĩ ngay đến bề mặt tấn công. Tức là bạn đang bổ sung một máy tính nhúng và cả liên lạc mạng giữa máy đó với máy chủ. Với tôi, mức rủi ro nhỏ được thêm vào như vậy vẫn lớn hơn nhiều so với mức rủi ro cực kỳ phi lý mà ở đó đèn lava mới thực sự trở nên cần thiết
Có thể diễn đạt khác cho sự phân biệt mang tính triết học này như sau: có bao nhiêu kết quả có thể xảy ra, và kết quả đó dự đoán được đến mức nào
Với mục đích mật mã, người ta đã chốt mức khả năng dự đoán ở cỡ 2^-256, nhưng thú vị là có những quá trình rất phổ biến có số lượng kết quả khả dĩ lớn hơn nhiều, và đôi khi bạn muốn có khả năng tạo ra mọi kết quả có thể có, dù xác suất của chúng nhỏ đến đâu. Trong những trường hợp đó, tính ngẫu nhiên mật mã có thể là chưa đủ
Một bộ bài chuẩn có 52! cách xáo, xấp xỉ 2^226, nên một seed ngẫu nhiên mật mã vẫn có thể tạo ra mọi cách xáo. Nhưng nếu chơi Uno hoặc trộn nhiều bộ bài với nhau, bộ sinh số ngẫu nhiên 256 bit sẽ không có đủ trạng thái để tạo ra mọi cách xáo. Nếu toàn bộ tính ngẫu nhiên ở user space của hệ thống đều đến từ kernel, và kernel đưa toàn bộ tính ngẫu nhiên phần cứng qua một CSPRNG 256 bit, thì có thể vẫn chưa đủ để xào bài ở Las Vegas :-)
Điều còn thiếu trong bài là gieo lại, đây là chủ đề thú vị vì nó cho thấy cách nó tương tác với fast key erasure cũng như độ khó của việc lấy được seed ban đầu. Bài viết gợi ý như thể Linux chỉ dùng CPU jitter, nhưng đó là cách đơn giản hóa quá mức. Linux dùng nhiều nguồn ngẫu nhiên, còn điệu nhảy jitter chỉ là phương án cuối cùng
Trong thế giới thực, bạn thậm chí không thể thu được đến 2^128 mẫu. Thực tế còn ít hơn rất nhiều, và vì vậy AES-128 vẫn đủ an toàn cho nhiều mục đích. Khi số lượng kết quả khả dĩ lớn hơn 2^256, chuyện “chạy hết mọi kết quả có thể” là hoàn toàn bất khả thi. Tốt nhất là quên nó đi. Thứ đó không tồn tại
Ngay cả trong blackjack dùng 6 bộ bài thay vì 1 bộ, thứ bạn muốn trong thực tế cũng không phải là một quy trình xáo phân bố xác suất thật đều lên mọi cách xáo có thể có. Chỉ cần một phân bố đủ tốt đến mức dù lấy mẫu nhiều nhất có thể bạn cũng không phân biệt ra khác biệt là được. Dù số cách xáo bị giới hạn ở 2^256, hay thậm chí 2^128, bạn cũng sẽ không nhận ra khác biệt
Việc bỏ qua chuyện gieo lại trong bài là có chủ ý. Chỉ cần gieo lại ở những thời điểm cụ thể như khi nghi ngờ bị xâm nhập hoặc khi có một số bản cập nhật bảo mật. Việc đó cũng hợp lý khi khởi động lại nếu nó đơn giản hoặc an toàn hơn so với việc giữ trạng thái bộ sinh số ngẫu nhiên trong bộ nhớ không mất dữ liệu. Vì vậy thay vì gọi là “gieo lại”, tôi thích xem nó như khởi động lại với một seed ban đầu mới
Trong vận hành bình thường thì hoàn toàn không cần gieo lại. Cố triển khai chỉ làm tăng độ phức tạp
Tôi đúng là nên kiểm tra lại hàm ý rằng Linux chỉ dùng CPU jitter. Theo như tôi hiểu thì ở thời điểm khởi động đó là nguồn duy nhất. Cụ thể là trước khi có đầu vào từ người dùng và đầu vào mạng thì tôi nghĩ là như vậy. Có nguồn nào khác mà bạn biết không? Hỗ trợ bộ sinh số ngẫu nhiên phần cứng thì có lẽ đã có rồi
Không làm được. Nhưng bỏ qua điểm đó, đây là cách để làm một cách an toàn…
Tôi đoán rằng các card phần cứng sinh số ngẫu nhiên tồn tại không chỉ để lấy mật độ bit mà còn để có nguồn ngẫu nhiên song song được đo bằng số bit trên một đơn vị thời gian
Không có nhiều ý riêng lẻ mà tôi phản đối mạnh, nhưng lập luận tổng thể lại cho cảm giác hơi mơ hồ. Bài viết xây dựng quanh ý “mật mã hiện đại cần ít ngẫu nhiên thật hơn rất nhiều so với mọi người nghĩ”, rồi kết ở chỗ “vì vậy đèn lava mở rộng bề mặt tấn công nên tệ hơn”
Cả hai mệnh đề đều có thể đúng, nhưng dòng suy luận nối giữa chúng tạo cảm giác hơi gượng
LavaRand đã làm kiểu việc này từ hơn 20 năm trước. Hồi đó thì thấy dễ thương, nhưng cảm biến camera thời ấy nhỏ hơn nhiều và vì các đặc tính có thể đoán trước của ống kính cùng những thứ tương tự nên nó không phải nguồn entropy tốt
Tôi vẫn thích đèn lava, nhưng mức điện năng tiêu thụ của một bức tường hàng trăm chiếc với tôi là khá lớn đối với một thiết bị mang tính đồ chơi như vậy
Hơi giống tự quảng bá. Gần như không chia sẻ liên kết nào, mà đã chia sẻ thì lại đăng liên kết của chính mình. 5 bài gần nhất thì cả 5 đều trỏ về nội dung của bản thân
“Tác giả tham gia vào cộng đồng là điều tốt, nhưng không nên lạm dụng nó như một công cụ chỉ để phát đi thông báo sản phẩm hay kéo lưu lượng về công việc của mình. Theo kinh nghiệm, nội dung tự quảng bá nên chiếm dưới một phần tư tổng stories và comments của người đó.”
Nếu có 15 bài đăng và 1399 bình luận thì rõ ràng người đó có tham gia cộng đồng. Trừ khi họ còn tự để lại hơn 90 bình luận dưới mỗi bài của chính mình
Cloudflare đóng góp entropy lấy từ đèn lava, University of Chile đóng góp dữ liệu động đất, nếu tôi nhớ đúng thì EPFL đóng góp số đo phân rã phóng xạ, và nhiều bên khác nữa đã đóng góp nhiều loại dữ liệu khác nhau vào nghi thức tạo khóa ban đầu của mạng drand
Liệu có thể dùng CSPRNG không? Tất nhiên là được. Nhưng như vậy thì còn gì vui nữa?