Đánh tan những lầm tưởng về /dev/urandom và bảo mật mã hóa

Có rất nhiều quan niệm sai lầm được lặp đi lặp lại về /dev/urandom và /dev/random trên các hệ thống UNIX. Tuy nhiên, phần lớn trong số đó là không chính xác và gây hiểu lầm cho các lập trình viên cũng như chuyên gia bảo mật.

Lầm tưởng số 1: /dev/urandom không an toàn

Nhiều người tin rằng /dev/urandom là không an toàn và luôn luôn nên sử dụng /dev/random cho các mục đích mã hóa.

Thực tế: /dev/urandom là nguồn tạo số ngẫu nhiên được ưu tiên sử dụng cho các mục đích mã hóa trên các hệ thống giống UNIX.

Lầm tưởng số 2: Sự khác biệt giữa "ngẫu nhiên thực" và "giả ngẫu nhiên"

Một ý kiến phổ biến cho rằng /dev/urandom là trình tạo số giả ngẫu nhiên (PRNG), trong khi /dev/random là trình tạo số "ngẫu nhiên thực".

Thực tế: Cả /dev/urandom và /dev/random đều sử dụng chính xác cùng một CSPRNG (Trình tạo số giả ngẫu nhiên an toàn về mặt mã hóa). Chúng chỉ khác nhau ở rất ít điểm và sự khác biệt đó không liên quan gì đến việc tính "ngẫu nhiên thực" hay không.

Lầm tưởng số 3: /dev/random luôn là lựa chọn tốt hơn

Người ta thường nghĩ rằng /dev/random rõ ràng là lựa chọn tốt hơn cho mật mã học, và ngay cả khi /dev/urandom an toàn tương đương, cũng không có lý do gì để chọn后者.

Thực tế: /dev/random có một vấn đề rất lớn: nó chặn (block).

Vấn đề về việc chặn và Entropy

Nhiều người cho rằng việc chặn là tốt vì /dev/random chỉ đưa ra lượng ngẫu nhiên tương ứng với lượng entropy trong pool của nó. Họ lo ngại rằng /dev/urandom sẽ đưa ra các số ngẫu nhiên không an toàn khi entropy cạn kiệt.

Thực tế: Không phải vậy. Vấn đề về việc entropy "cạn kiệt" là một vấn đề giả tạo. Chỉ cần khoảng 256 bit entropy là đủ để tạo ra các số bảo mật về mặt tính toán trong một thời gian rất dài.

Cách thức hoạt động bên trong hạt nhân (Kernel)

Rất nhiều người hình dung kernel hoạt động theo cách: entropy "thực" được đưa vào pool, /dev/random lấy trực tiếp từ pool này và chặn khi hết, còn /dev/urandom sẽ dùng một PRNG phụ khi hết entropy.

Điều này là hoàn toàn sai. Trong thực tế, CSPRNG là một phần không thể tách rời của quá trình tạo số ngẫu nhiên. Mọi đầu vào từ các nguồn ngẫu nhiên đều được trộn và băm trong CSPRNG trước khi xuất ra dưới dạng số ngẫu nhiên, dù là qua /dev/urandom hay /dev/random.

Cả hai thiết bị đều được cấp dữ liệu từ cùng một CSPRNG. Sự khác biệt duy nhất nằm ở hành vi khi ước lượng entropy trong pool thấp: /dev/random sẽ chặn, trong khi /dev/urandom thì không.

Tại sao việc chặn là xấu?

Việc /dev/random chặn lại gây ra vấn đề lớn về tính sẵn sàng (availability). Bạn có thể đã từng gặp tình huống phải chờ đợi khi tạo khóa PGP trong máy ảo hoặc khi kết nối đến máy chủ web đang chờ thêm số ngẫu nhiên.

Khi hệ thống không hoạt động vì bị chặn, người dùng thường tìm cách giải quyết. Họ có thể vá lỗi gọi hàm random(), tắt SSL, hoặc sử dụng các ioctl lạ để tăng bộ đếm entropy. Điều này dạy cho người dùng làm những điều ngớ ngẩn làm tổn hại đến bảo mật mà bạn không hề hay biết.

Chặn là không cần thiết cho bảo mật. /dev/urandom cung cấp cùng một loại số ngẫu nhiên như /dev/random, trực tiếp từ một CSPRNG.

Quan điểm của các chuyên gia

Daniel Bernstein (djb), một nhà mật mã học nổi tiếng, đã chỉ ra sự mâu thuẫn trong trang hướng dẫn (man page) của /dev/random. Nếu chúng ta không thể mở rộng một đầu ra 256-bit thành một dòng khóa vô hạn dự đoán được (những gì urandom cần), thì làm sao chúng ta có thể sử dụng một khóa duy nhất để mã hóa an toàn nhiều thông điệp (những gì SSL, PGP cần)?

Thomas Pornin, một chuyên gia khác trên StackExchange, cũng khẳng định: /dev/urandom tạo ra dữ liệu không thể phân biệt được với sự ngẫu nhiên thực tế với công nghệ hiện nay. Việc cố gắng tìm kiếm sự ngẫu nhiên "tốt hơn" so với /dev/urandom là vô nghĩa, trừ khi bạn đang sử dụng một trong số ít thuật toán mật mã "lý thuyết thông tin".

Khi nào thực sự cần lo lắng?

Vấn đề thực sự duy nhất nằm ở thời điểm khởi động hệ thống (boot) hoặc trên các máy ảo (VM).

Trên Linux, /dev/urandom không chặn ngay cả khi kernel chưa thu thập đủ entropy ban đầu. Điều này có thể nguy hiểm nếu hệ thống chưa từng khởi động trước đó. Tuy nhiên, các bản phân phối Linux hiện nay thường lưu trữ seed ngẫu nhiên từ lần chạy trước để giải quyết vấn đề này.

Đối với máy ảo, việc sao chép (clone) hoặc khôi phục checkpoint có thể làm cho seed file trở nên vô ích. Giải pháp ở đây không phải là dùng /dev/random khắp nơi, mà là đảm bảo seed (hạt giống) ban đầu là duy nhất và an toàn cho mỗi máy ảo sau khi clone.

Kết luận

Đừng để những huyền thoại về "entropy thực" hay "ngẫu nhiên thực" đánh lừa. Trong bối cảnh của các thuật toán mã hóa tính toán mà chúng ta sử dụng hàng ngày (AES, RSA, ECC), /dev/urandom là lựa chọn đúng đắn, an toàn và hiệu quả. Hãy sử dụng nó và quên đi thói quen lo lắng vô cớ về việc entropy bị cạn kiệt.