/dev/random ซึ่งเป็นโปรแกรมสร้างตัวเลขสุ่มหลอก (CSPRNG) ที่ปลอดภัยด้วยการเข้ารหัส เป็นที่รู้กันว่ามีปัญหาที่น่ารำคาญประการหนึ่งนั่นคือการบล็อก บทความนี้จะอธิบายวิธีการแก้ปัญหาดังกล่าว
ในช่วงไม่กี่เดือนที่ผ่านมา สิ่งอำนวยความสะดวกในการสร้างตัวเลขสุ่มในเคอร์เนลได้รับการปรับปรุงใหม่เล็กน้อย แต่ปัญหาในระบบย่อยนี้ได้รับการแก้ไขแล้วในวงกว้าง . ที่สุด ถูกสร้างขึ้นเพื่อป้องกันไม่ให้การเรียกของระบบ getrandom() จากการบล็อกเป็นเวลานานเมื่อระบบบูท แต่สาเหตุที่สำคัญคือพฤติกรรมการบล็อกของพูลสุ่ม แพตช์ล่าสุดน่าจะลบพูลนี้ออกไปและคาดว่าจะมุ่งหน้าไปยังคอร์หลัก
Andy Lutomirski เผยแพร่แพทช์เวอร์ชันที่สามเมื่อปลายเดือนธันวาคม เขามีส่วนช่วย "การเปลี่ยนแปลงความหมายที่สำคัญสองประการใน Linux API แบบสุ่ม". แพทช์เพิ่มแฟล็ก GRND_INSECURE ใหม่ให้กับการเรียกระบบ getrandom() (แม้ว่า Lutomirsky จะอ้างถึงเป็น getentropy() ซึ่งนำไปใช้ใน glibc โดยใช้ getrandom() พร้อมแฟล็กคงที่); การตั้งค่าสถานะนี้จะทำให้การเรียกส่งคืนจำนวนข้อมูลที่ร้องขอเสมอ แต่ไม่รับประกันว่าข้อมูลจะเป็นแบบสุ่ม เคอร์เนลจะพยายามอย่างเต็มที่เพื่อสร้างข้อมูลสุ่มที่ดีที่สุดที่มีอยู่ในเวลาที่กำหนด “บางทีสิ่งที่ดีที่สุดที่ควรทำคือเรียกว่า 'ไม่ปลอดภัย' (ไม่ปลอดภัย) เพื่อป้องกันไม่ให้ API นี้ถูกใช้กับสิ่งที่ต้องการความปลอดภัย"
แพตช์ยังลบพูลการบล็อกออกด้วย ปัจจุบันเคอร์เนลรักษากลุ่มข้อมูลสุ่มสองกลุ่ม กลุ่มหนึ่งสอดคล้องกับ /dev/random และอีกกลุ่มเป็น /dev/urandom ตามที่อธิบายไว้ในนี้ 2015. พูลที่บล็อกคือพูลสำหรับ /dev/random; การอ่านสำหรับอุปกรณ์นั้นจะบล็อก (หมายถึงชื่อของมัน) จนกว่าจะรวบรวมเอนโทรปี "เพียงพอ" จากระบบเพื่อตอบสนองคำขอ การอ่านเพิ่มเติมจากไฟล์นี้จะถูกบล็อกเช่นกัน ถ้ามีเอนโทรปีไม่เพียงพอในพูล
การลบพูลล็อคหมายความว่าการอ่านจาก /dev/random จะทำงานเหมือน getrandom() โดยตั้งค่าสถานะเป็นศูนย์ (และเปลี่ยนการตั้งค่าสถานะ GRND_RANDOM ให้เป็น noop) เมื่อเริ่มต้นตัวสร้างตัวเลขสุ่มเข้ารหัส (CRNG) การอ่านจาก /dev/random และการเรียกไปยัง getrandom(...,0) จะไม่บล็อกและจะส่งคืนข้อมูลสุ่มตามจำนวนที่ร้องขอ
Lutomirsky พูดว่า: “ฉันเชื่อว่าพูลการบล็อก Linux ล้าสมัยไปแล้ว CRNG Linux สร้างเอาต์พุตที่ดีพอที่จะใช้สำหรับการสร้างคีย์ด้วยซ้ำ กลุ่มการบล็อกไม่ได้แข็งแกร่งกว่าในแง่วัตถุใดๆ และต้องการโครงสร้างพื้นฐานที่มีมูลค่าที่น่าสงสัยจำนวนมากเพื่อรองรับ”
การเปลี่ยนแปลงนี้จัดทำขึ้นโดยมีเป้าหมายเพื่อให้แน่ใจว่าโปรแกรมที่มีอยู่จะไม่ได้รับผลกระทบจริงๆ และในความเป็นจริง จะมีปัญหาน้อยลงหากต้องรอนานสำหรับสิ่งต่างๆ เช่น การสร้างคีย์ GnuPG
“ตอนเหล่านี้จะต้องไม่รบกวนโปรแกรมที่มีอยู่ /dev/urandom ยังคงไม่เปลี่ยนแปลง /dev/random ยังคงบล็อกทันทีเมื่อบู๊ตเครื่อง แต่จะบล็อกน้อยกว่าเมื่อก่อน getentropy() ด้วยแฟล็กที่มีอยู่จะส่งกลับผลลัพธ์ที่เหมาะสมสำหรับการใช้งานจริงเหมือนเมื่อก่อน"
Lutomirsky ตั้งข้อสังเกตว่ามันยังคงเป็นคำถามเปิดอยู่ว่าเคอร์เนลควรจัดเตรียมสิ่งที่เรียกว่า "ตัวเลขสุ่มจริง" ซึ่งเป็นสิ่งที่เคอร์เนลบล็อกควรทำในระดับหนึ่งหรือไม่ เขาเห็นเหตุผลเดียวเท่านั้นสำหรับสิ่งนี้: “การปฏิบัติตามมาตรฐานของรัฐบาล” Lutomirsky แนะนำว่าหากเคอร์เนลจัดเตรียมสิ่งนี้ ควรทำผ่านอินเทอร์เฟซที่แตกต่างอย่างสิ้นเชิง หรือควรย้ายไปยังพื้นที่ผู้ใช้ เพื่อให้ผู้ใช้สามารถดึงตัวอย่างเหตุการณ์ดิบที่สามารถใช้เพื่อสร้างล็อคพูลดังกล่าวได้
สเตฟาน มุลเลอร์ แนะนำว่าฉากของเขา สำหรับ Linux Random Number Generator (LRNG) (ปัจจุบันเปิดตัวเวอร์ชัน 26) อาจเป็นวิธีหนึ่งในการจัดหาตัวเลขสุ่มที่แท้จริงสำหรับแอปพลิเคชันที่ต้องการ LRNG “ปฏิบัติตามหลักเกณฑ์ SP800-90B เกี่ยวกับแหล่งที่มาของเอนโทรปีที่ใช้ในการสร้างบิตสุ่ม” อย่างสมบูรณ์ ทำให้สิ่งนี้เป็นวิธีแก้ปัญหามาตรฐานของรัฐบาล
แมทธิว การ์เร็ตต์คัดค้านคำว่า "ข้อมูลสุ่มที่แท้จริง" โดยสังเกตว่าโดยหลักการแล้วอุปกรณ์ที่สุ่มตัวอย่างสามารถจำลองแบบจำลองได้อย่างแม่นยำเพียงพอที่จะคาดเดาได้: "เราไม่ได้สุ่มตัวอย่างเหตุการณ์ควอนตัมที่นี่"
มุลเลอร์ตอบว่าคำนี้มาจากมาตรฐาน AIS 31 ของเยอรมัน เพื่ออธิบายเครื่องกำเนิดตัวเลขสุ่มที่สร้างผลลัพธ์เท่านั้น "ในอัตราเดียวกับแหล่งกำเนิดเสียงที่ก่อให้เกิดเอนโทรปี"
นอกเหนือจากความแตกต่างของคำศัพท์แล้ว การมีระบบล็อคพูลตามที่แนะนำโดยแพตช์ LRNG จะนำไปสู่ปัญหาต่างๆ มากมาย อย่างน้อยก็หากมีการเข้าถึงโดยไม่มีสิทธิ์พิเศษ
ดังที่ Lutomirsky กล่าวว่า: “นี่ไม่ได้แก้ปัญหา หากผู้ใช้สองคนใช้งานโปรแกรมโง่ๆ เช่น gnupg พวกเขาจะระบายซึ่งกันและกัน ฉันเห็นว่าขณะนี้มีปัญหาหลักสองประการเกี่ยวกับ /dev/random: มีแนวโน้มที่จะเกิด DoS (เช่น ทรัพยากรหมดสิ้น อิทธิพลที่เป็นอันตราย หรืออะไรทำนองนั้น) และเนื่องจากไม่จำเป็นต้องใช้สิทธิ์ใด ๆ ในการใช้งาน จึงมีแนวโน้มที่จะถูกละเมิดเช่นกัน Gnupg ผิด มันเป็นการล่มสลายโดยสิ้นเชิง หากเราเพิ่มอินเทอร์เฟซใหม่ที่ไม่ได้รับสิทธิ์ซึ่ง gnupg และโปรแกรมที่คล้ายกันจะใช้ เราจะสูญเสียอีกครั้ง"
Mueller ตั้งข้อสังเกตว่าการเพิ่ม getrandom() จะทำให้ GnuPG สามารถใช้อินเทอร์เฟซนี้ได้ เนื่องจากจะให้การรับประกันที่จำเป็นว่าพูลได้รับการเตรียมใช้งานแล้ว จากการหารือกับนักพัฒนา GnuPG Werner Koch Mueller เชื่อว่าการรับประกันเป็นเหตุผลเดียวที่ GnuPG อ่านโดยตรงจาก /dev/random แต่หากมีอินเทอร์เฟซที่ไม่มีสิทธิ์ซึ่งเสี่ยงต่อการถูกปฏิเสธการให้บริการ (เนื่องจาก /dev/random เป็นอยู่ในปัจจุบัน) Lutomirsky ให้เหตุผลว่าแอปพลิเคชันบางตัวจะถูกนำไปใช้ในทางที่ผิด
Theodore Yue Tak Ts'o ผู้พัฒนาระบบย่อยตัวเลขสุ่มของ Linux ดูเหมือนจะเปลี่ยนใจเกี่ยวกับความจำเป็นในการบล็อคพูล เขากล่าวว่าการลบพูลนี้จะกำจัดความคิดที่ว่า Linux มีตัวสร้างตัวเลขสุ่มที่แท้จริง (TRNG) ได้อย่างมีประสิทธิภาพ: "นี่ไม่ใช่เรื่องไร้สาระ เนื่องจากนี่คือสิ่งที่ *BSD ทำมาตลอด"
นอกจากนี้เขายังกังวลว่าการจัดหากลไก TRNG จะเป็นเพียงเหยื่อล่อสำหรับนักพัฒนาแอปพลิเคชัน และเชื่อว่าในความเป็นจริง เนื่องจากฮาร์ดแวร์ประเภทต่างๆ ที่ Linux รองรับ จึงเป็นไปไม่ได้ที่จะรับประกัน TRNG ในเคอร์เนล แม้แต่ความสามารถในการทำงานกับอุปกรณ์ที่มีสิทธิ์ใช้งานรูทเท่านั้นก็ไม่สามารถแก้ปัญหาได้: “นักพัฒนาแอพพลิเคชั่นระบุว่าแอพพลิเคชั่นของพวกเขาถูกติดตั้งเป็นรูทเพื่อความปลอดภัย ดังนั้นนี่จึงเป็นวิธีเดียวที่คุณสามารถเข้าถึงตัวเลขสุ่มที่ 'ดีจริงๆ' ได้"
Mueller ถามว่า Cao ละทิ้งการดำเนินการ Blocking Pool ที่เขาเสนอมานานแล้วหรือไม่ Cao ตอบว่าเขาวางแผนที่จะนำแพตช์ของ Lutomirsky และต่อต้านการเพิ่มอินเทอร์เฟซการบล็อกกลับไปยังเคอร์เนลอย่างแข็งขัน
“เคอร์เนลไม่สามารถรับประกันได้ว่าแหล่งกำเนิดเสียงนั้นได้รับการระบุลักษณะอย่างเหมาะสมหรือไม่ สิ่งเดียวที่นักพัฒนา GPG หรือ OpenSSL จะได้รับคือความรู้สึกที่คลุมเครือว่า TRURANDOM นั้น "ดีกว่า" และเนื่องจากพวกเขาต้องการความปลอดภัยมากขึ้น พวกเขาจึงต้องพยายามใช้มันอย่างไม่ต้องสงสัย เมื่อถึงจุดหนึ่งมันจะถูกบล็อก และเมื่อผู้ใช้อัจฉริยะคนอื่นๆ (อาจเป็นผู้เชี่ยวชาญด้านการจัดจำหน่าย) แทรกมันลงในสคริปต์เริ่มต้นและระบบหยุดทำงาน ผู้ใช้จะต้องร้องเรียนกับ Linus Torvalds เองเท่านั้น”
Cao ยังสนับสนุนให้นักเข้ารหัสและผู้ที่ต้องการ TRNG มีวิธีเก็บเกี่ยวเอนโทรปีของตนเองในพื้นที่ผู้ใช้เพื่อใช้ตามที่เห็นสมควร เขากล่าวว่าการรวบรวมเอนโทรปีไม่ใช่กระบวนการที่เคอร์เนลสามารถทำได้บนฮาร์ดแวร์ต่างๆ ทั้งหมดที่เคอร์เนลรองรับ และเคอร์เนลเองก็ไม่สามารถประมาณปริมาณเอนโทรปีที่ได้รับจากแหล่งต่างๆ ได้
"เคอร์เนลไม่ควรผสมแหล่งกำเนิดเสียงที่แตกต่างกันเข้าด้วยกัน และแน่นอนว่าไม่ควรพยายามอ้างว่ารู้ว่าได้รับเอนโทรปีจำนวนเท่าใดเมื่อพยายามเล่น "เกมเอนโทรปีกระตุก" บน CPU ที่เรียบง่ายอย่างอุกอาจ สถาปัตยกรรมสำหรับผู้ใช้ทั่วไป กรณี IOT/Embedded ที่ทุกอย่างไม่ซิงค์กับออสซิลเลเตอร์หลักตัวเดียว โดยที่ไม่มีคำสั่ง CPU ให้เรียงลำดับหรือเปลี่ยนชื่อรีจิสเตอร์ ฯลฯ”
“คุณสามารถพูดคุยเกี่ยวกับการจัดหาเครื่องมือที่พยายามทำการคำนวณเหล่านี้ แต่จะต้องทำสิ่งเหล่านี้บนฮาร์ดแวร์ของผู้ใช้แต่ละคน ซึ่งไม่เหมาะกับผู้ใช้การกระจายส่วนใหญ่ หากสิ่งนี้มีไว้สำหรับผู้เข้ารหัสเท่านั้น ให้ดำเนินการในพื้นที่ผู้ใช้ของตน และอย่าทำให้ GPG, OpenSSL ฯลฯ ง่ายขึ้น เพื่อให้ทุกคนพูดว่า "เราต้องการ "ความสุ่มที่แท้จริง" และจะไม่ยอมจ่ายให้น้อยลง" เราสามารถพูดคุยเกี่ยวกับวิธีที่เราจัดเตรียมอินเทอร์เฟซให้กับนักเข้ารหัสเพื่อให้พวกเขาสามารถรับข้อมูลที่ต้องการได้โดยการเข้าถึงแหล่งกำเนิดเสียงหลัก แยกและตั้งชื่อ และบางทีแหล่งกำเนิดเสียงนั้นสามารถตรวจสอบตัวเองกับห้องสมุดหรือแอปพลิเคชันพื้นที่ผู้ใช้ได้”
มีการพูดคุยกันว่าอินเทอร์เฟซดังกล่าวอาจมีหน้าตาเป็นอย่างไร เนื่องจากตัวอย่างเช่น อาจมีผลกระทบด้านความปลอดภัยสำหรับบางเหตุการณ์ Cao ตั้งข้อสังเกตว่าโค้ดสแกนคีย์บอร์ด (เช่น การกดแป้นพิมพ์) จะถูกผสมลงในพูลซึ่งเป็นส่วนหนึ่งของการรวบรวมเอนโทรปี: "การนำสิ่งนี้มาสู่พื้นที่ผู้ใช้ แม้จะผ่านการเรียกของระบบที่มีสิทธิพิเศษ ก็ไม่ฉลาดเลยที่จะพูดน้อยที่สุด" ค่อนข้างเป็นไปได้ที่การกำหนดเวลาของเหตุการณ์อื่นๆ อาจทำให้เกิดข้อมูลบางอย่างรั่วไหลผ่านช่องทางด้านข้าง
ดูเหมือนว่าปัญหาที่มีมายาวนานกับระบบย่อยตัวเลขสุ่มของ Linux กำลังอยู่ในแนวทางแก้ไข การเปลี่ยนแปลงที่เกิดขึ้นกับระบบย่อยตัวเลขสุ่มเมื่อเร็วๆ นี้ จริงๆ แล้วส่งผลให้เกิดปัญหา DoS ขณะใช้งานเท่านั้น ขณะนี้มีวิธีที่มีประสิทธิภาพในการรับตัวเลขสุ่มที่ดีที่สุดที่เคอร์เนลสามารถให้ได้ หาก TRNG ยังคงเป็นที่ต้องการบน Linux ข้อบกพร่องนี้จะต้องได้รับการแก้ไขในอนาคต แต่มีแนวโน้มว่าจะไม่เกิดขึ้นภายในเคอร์เนลเอง
โฆษณาบางส่วน🙂
ขอบคุณที่อยู่กับเรา คุณชอบบทความของเราหรือไม่? ต้องการดูเนื้อหาที่น่าสนใจเพิ่มเติมหรือไม่ สนับสนุนเราโดยการสั่งซื้อหรือแนะนำให้เพื่อน , อะนาล็อกที่ไม่เหมือนใครของเซิร์ฟเวอร์ระดับเริ่มต้นซึ่งเราคิดค้นขึ้นเพื่อคุณ: (ใช้ได้กับ RAID1 และ RAID10 สูงสุด 24 คอร์ และสูงสุด 40GB DDR4)
Dell R730xd ถูกกว่า 2 เท่าในศูนย์ข้อมูล Equinix Tier IV ในอัมสเตอร์ดัม? ที่นี่ที่เดียวเท่านั้น ในเนเธอร์แลนด์! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - จาก $99! อ่านเกี่ยวกับ
ที่มา: will.com