/dev/random, một trình tạo số giả ngẫu nhiên được bảo mật bằng mật mã (CSPRNG), được biết là có một vấn đề khó chịu: chặn. Bài viết này giải thích cách bạn có thể giải quyết nó.
Trong vài tháng qua, cơ sở tạo số ngẫu nhiên trong kernel đã được làm lại một chút, nhưng các vấn đề trong hệ thống con này đã được giải quyết trong quá trình phát triển rộng hơn. . Hầu hết được thực hiện để ngăn lệnh gọi hệ thống getrandom() bị chặn trong một thời gian dài khi hệ thống khởi động, nhưng lý do cơ bản cho việc này là hành vi chặn của nhóm ngẫu nhiên. Một bản vá gần đây đã loại bỏ nhóm này và dự kiến nó sẽ hướng tới lõi chính.
Andy Lutomirski đã xuất bản phiên bản thứ ba của bản vá vào cuối tháng XNUMX. Anh ấy đóng góp "hai thay đổi lớn về ngữ nghĩa đối với các API Linux ngẫu nhiên". Bản vá bổ sung cờ GRND_INSECURE mới vào lệnh gọi hệ thống getrandom() (mặc dù Lutomirsky gọi nó là getentropy(), được triển khai trong glibc bằng cách sử dụng getrandom() với các cờ cố định); cờ này khiến cuộc gọi luôn trả về lượng dữ liệu được yêu cầu nhưng không đảm bảo rằng dữ liệu là ngẫu nhiên. Hạt nhân sẽ cố gắng hết sức để tạo ra dữ liệu ngẫu nhiên tốt nhất mà nó có tại thời điểm nhất định. "Có lẽ điều tốt nhất nên làm là gọi nó là 'KHÔNG AN TOÀN' (không an toàn) để ngăn API này được sử dụng cho những thứ cần bảo mật."
Các bản vá cũng loại bỏ nhóm chặn. Hạt nhân hiện duy trì hai nhóm dữ liệu ngẫu nhiên, một nhóm tương ứng với /dev/random và nhóm kia tương ứng với /dev/urandom, như được mô tả trong phần này 2015. Nhóm chặn là nhóm dành cho/dev/ngẫu nhiên; các lần đọc cho thiết bị đó sẽ chặn (có nghĩa là tên của nó) cho đến khi entropy "đủ" được thu thập từ hệ thống để đáp ứng yêu cầu. Các lần đọc thêm từ tệp này cũng bị chặn nếu không có đủ entropy trong nhóm.
Xóa nhóm khóa có nghĩa là việc đọc từ /dev/random hoạt động giống như getrandom() với các cờ được đặt thành 0 (và biến cờ GRND_RANDOM thành một noop). Khi trình tạo số ngẫu nhiên mật mã (CRNG) được khởi tạo, việc đọc từ /dev/random và gọi tới getrandom(...,XNUMX) sẽ không bị chặn và sẽ trả về lượng dữ liệu ngẫu nhiên được yêu cầu.
Lutomirsky nói: “Tôi tin rằng nhóm chặn Linux đã trở nên lỗi thời. CRNG Linux tạo ra đầu ra đủ tốt để thậm chí có thể được sử dụng để tạo khóa. Nhóm chặn không mạnh hơn về mặt vật chất và đòi hỏi nhiều cơ sở hạ tầng có giá trị đáng ngờ để hỗ trợ nó.”
Những thay đổi được thực hiện với mục tiêu đảm bảo rằng các chương trình hiện có sẽ không thực sự bị ảnh hưởng và trên thực tế, sẽ có ít vấn đề hơn khi phải chờ đợi lâu cho những việc như tạo khóa GnuPG.
“Những tập phim này không được làm gián đoạn bất kỳ chương trình hiện có nào. /dev/urandom không thay đổi. /dev/random vẫn chặn ngay khi khởi động nhưng ít chặn hơn trước. getentropy() với các cờ hiện có sẽ trả về kết quả phù hợp với mục đích thực tế như trước đây."
Lutomirsky lưu ý rằng vẫn còn là một câu hỏi mở liệu hạt nhân có nên cung cấp cái gọi là “số ngẫu nhiên thực sự” hay không, đó là điều mà hạt nhân chặn phải làm ở một mức độ nhất định. Anh ấy chỉ thấy một lý do cho điều này: “tuân thủ các tiêu chuẩn của chính phủ”. Lutomirsky gợi ý rằng nếu hạt nhân cung cấp tính năng này thì nó phải được thực hiện thông qua một giao diện hoàn toàn khác hoặc nó phải được chuyển vào không gian người dùng, cho phép người dùng truy xuất các mẫu sự kiện thô có thể được sử dụng để tạo một nhóm khóa như vậy.
Stephan Müller gợi ý rằng bộ của anh ấy dành cho Trình tạo số ngẫu nhiên Linux (LRNG) (hiện đã phát hành phiên bản 26) có thể là một cách để cung cấp số ngẫu nhiên thực sự cho các ứng dụng cần nó. LRNG “hoàn toàn tuân thủ Nguyên tắc SP800-90B về nguồn Entropy được sử dụng để tạo bit ngẫu nhiên”, khiến nó trở thành giải pháp cho vấn đề tiêu chuẩn của chính phủ.
Matthew Garrett phản đối thuật ngữ “dữ liệu ngẫu nhiên thực sự”, lưu ý rằng về nguyên tắc, các thiết bị được lấy mẫu có thể được mô hình hóa đủ chính xác để khiến chúng có thể dự đoán được: “chúng tôi không lấy mẫu các sự kiện lượng tử ở đây”.
Müller trả lời rằng thuật ngữ này xuất phát từ tiêu chuẩn AIS 31 của Đức để mô tả một trình tạo số ngẫu nhiên chỉ tạo ra kết quả "ở cùng tốc độ với nguồn nhiễu cơ bản tạo ra entropy".
Bỏ qua những khác biệt về thuật ngữ, việc có một nhóm khóa như được đề xuất bởi các bản vá LRNG sẽ đơn giản dẫn đến nhiều vấn đề khác nhau, ít nhất là nếu nó được truy cập mà không có đặc quyền.
Như Lutomirsky đã nói: “Điều này không giải quyết được vấn đề. Nếu hai người dùng khác nhau chạy các chương trình ngu ngốc như gnupg, họ sẽ làm tiêu hao lẫn nhau. Tôi thấy rằng hiện tại có hai vấn đề chính với /dev/random: nó dễ bị DoS (tức là cạn kiệt tài nguyên, ảnh hưởng độc hại hoặc điều gì đó tương tự) và vì không cần có đặc quyền để sử dụng nó nên nó cũng dễ bị lạm dụng. Gnupg đã sai, đó là sự sụp đổ hoàn toàn. Nếu chúng tôi thêm một giao diện không có đặc quyền mới mà gnupg và các chương trình tương tự sẽ sử dụng, chúng tôi sẽ lại thua."
Mueller lưu ý rằng việc bổ sung getrandom() giờ đây sẽ cho phép GnuPG sử dụng giao diện này, vì nó sẽ cung cấp sự đảm bảo cần thiết rằng nhóm đã được khởi tạo. Dựa trên các cuộc thảo luận với nhà phát triển GnuPG Werner Koch, Mueller tin rằng sự đảm bảo là lý do duy nhất khiến GnuPG hiện đọc trực tiếp từ /dev/random. Nhưng nếu có một giao diện không có đặc quyền dễ bị từ chối dịch vụ (như /dev/random ngày nay), Lutomirsky lập luận rằng nó sẽ bị một số ứng dụng lạm dụng.
Theodore Yue Tak Ts'o, nhà phát triển hệ thống con số ngẫu nhiên của Linux, dường như đã thay đổi quan điểm về sự cần thiết của một nhóm chặn. Ông nói rằng việc loại bỏ nhóm này sẽ loại bỏ một cách hiệu quả ý tưởng rằng Linux có một trình tạo số ngẫu nhiên thực sự (TRNG): "điều này không hề vô nghĩa, vì đây chính xác là điều *BSD luôn làm."
Ông cũng lo ngại rằng việc cung cấp cơ chế TRNG sẽ chỉ đóng vai trò là mồi nhử cho các nhà phát triển ứng dụng và tin rằng trên thực tế, với các loại phần cứng khác nhau được Linux hỗ trợ, không thể đảm bảo TRNG trong kernel. Ngay cả khả năng chỉ làm việc với thiết bị có quyền root cũng không giải quyết được vấn đề: "Các nhà phát triển ứng dụng chỉ định rằng ứng dụng của họ phải được cài đặt dưới dạng root vì mục đích bảo mật, vì vậy đây là cách duy nhất bạn có thể truy cập vào các số ngẫu nhiên 'thực sự tốt'."
Mueller hỏi liệu Cao có từ bỏ việc triển khai nhóm chặn mà chính ông đã đề xuất từ lâu hay không. Cao trả lời rằng anh ấy dự định sử dụng các bản vá của Lutomirsky và tích cực phản đối việc thêm giao diện chặn trở lại kernel.
“Hạt nhân không thể đưa ra bất kỳ đảm bảo nào về việc liệu nguồn nhiễu có được mô tả chính xác hay không. Điều duy nhất mà nhà phát triển GPG hoặc OpenSSL có thể nhận được là cảm giác mơ hồ rằng TRUERANDOM "tốt hơn" và vì họ muốn bảo mật hơn nên chắc chắn họ sẽ cố gắng sử dụng nó. Tại một thời điểm nào đó, nó sẽ bị chặn và khi một số người dùng thông minh khác (có thể là chuyên gia phân phối) chèn nó vào tập lệnh init và hệ thống ngừng hoạt động, người dùng sẽ chỉ phải khiếu nại với chính Linus Torvalds."
Cao cũng ủng hộ việc cung cấp cho các nhà mật mã học và những người thực sự cần TRNG một cách để thu thập entropy của riêng họ trong không gian người dùng để sử dụng khi họ thấy phù hợp. Ông nói rằng việc thu thập entropy không phải là một quá trình mà hạt nhân có thể thực hiện trên tất cả các phần cứng khác nhau mà nó hỗ trợ, và bản thân hạt nhân cũng không thể ước tính lượng entropy được cung cấp bởi các nguồn khác nhau.
"Nhân không nên trộn lẫn các nguồn nhiễu khác nhau với nhau và chắc chắn nó không nên cố gắng tuyên bố để biết nó nhận được bao nhiêu bit entropy khi nó đang cố chơi một loại "trò chơi entropy giật" nào đó trên một CPU cực kỳ đơn giản. kiến trúc dành cho người dùng tiêu dùng. Các trường hợp IOT/Embedded trong đó mọi thứ không đồng bộ với một bộ dao động chính duy nhất, trong đó không có lệnh CPU nào để sắp xếp lại hoặc đổi tên một thanh ghi, v.v.”
“Bạn có thể nói về việc cung cấp các công cụ cố gắng thực hiện những phép tính này, nhưng những việc như vậy phải được thực hiện trên phần cứng của mỗi người dùng, điều này đơn giản là không thực tế đối với hầu hết người dùng phân phối. Nếu điều này chỉ dành cho các nhà mật mã thì hãy để nó được thực hiện trong không gian người dùng của họ. Và đừng đơn giản hóa GPG, OpenSSL, v.v. để mọi người nói rằng "chúng tôi muốn" sự ngẫu nhiên thực sự " và sẽ không chấp nhận ít hơn." Chúng tôi có thể nói về cách chúng tôi cung cấp giao diện cho các nhà mật mã để họ có thể nhận được thông tin họ cần bằng cách truy cập vào các nguồn nhiễu chính, được tách biệt và đặt tên, và có lẽ bằng cách nào đó, nguồn nhiễu có thể tự xác thực với thư viện hoặc ứng dụng không gian người dùng."
Đã có một số cuộc thảo luận về giao diện như vậy có thể trông như thế nào, vì ví dụ như có thể có những tác động về bảo mật đối với một số sự kiện. Cao lưu ý rằng mã quét bàn phím (tức là các lần nhấn phím) được trộn vào một nhóm như một phần của bộ sưu tập entropy: "Đưa mã này vào không gian người dùng, ngay cả thông qua lệnh gọi hệ thống đặc quyền, sẽ là điều không khôn ngoan nếu nói như vậy." Rất có thể các thời điểm sự kiện khác có thể tạo ra một số loại rò rỉ thông tin qua các kênh bên lề.
Vì vậy, có vẻ như vấn đề tồn tại từ lâu với hệ thống con số ngẫu nhiên của Linux đang dần được giải quyết. Những thay đổi mà hệ thống con số ngẫu nhiên đã trải qua gần đây thực tế chỉ dẫn đến các vấn đề DoS khi sử dụng nó. Hiện nay có nhiều cách hiệu quả để có được số ngẫu nhiên tốt nhất mà hạt nhân có thể cung cấp. Nếu TRNG vẫn được ưa chuộng trên Linux thì lỗ hổng này sẽ cần được giải quyết trong tương lai, nhưng rất có thể điều này sẽ không được thực hiện trong chính kernel.
Một số quảng cáo 🙂
Cảm ơn bạn đã ở với chúng tôi. Bạn có thích bài viết của chúng tôi? Bạn muốn xem nội dung thú vị hơn? Hỗ trợ chúng tôi bằng cách đặt hàng hoặc giới thiệu cho bạn bè, , một dạng tương tự duy nhất của các máy chủ cấp đầu vào do chúng tôi phát minh ra dành cho bạn: (có sẵn với RAID1 và RAID10, tối đa 24 lõi và tối đa 40GB DDR4).
Dell R730xd rẻ hơn gấp 2 lần tại trung tâm dữ liệu Equinix Tier IV ở Amsterdam? Chỉ ở đây ở Hà Lan! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - từ $99! Đọc về
Nguồn: www.habr.com