คีย์ส่วนตัวของ VPN ควรอยู่ที่ไหน: ไฟล์, CNG หรือ TPM?

สองคำถามตัดสินว่าคีย์ส่วนตัวของ VPN ควรอยู่ที่ใด: วัสดุคีย์ถูกคัดลอกออกจากโฮสต์ได้หรือไม่ และกระบวนการใดใช้คีย์นั้นได้โดยไม่มีใครอยู่ที่แป้นพิมพ์หรือไม่ ป้ายการตลาดของที่เก็บไม่ได้ตอบทั้งสองข้อ เดมอนอุโมงค์ที่ต้องกลับมาหลังรีบูตต้องใช้แบบไม่มีคนเฝ้า ซึ่งตัดทุกอย่างที่ขึ้นกับ PIN ที่มนุษย์พิมพ์

เลือกระหว่างการคัดลอกและการใช้งาน

การคัดลอกและการใช้งานล้มเหลวต่างกัน จึงควรถือเป็นสองข้อกำหนดไม่ใช่ข้อเดียว ผู้โจมตีที่อ่านไบต์ของคีย์ได้จะพาตัวตนไปยังโฮสต์อื่น และเครื่องต้นทางไม่รู้ตัว ผู้โจมตีที่อ่านไบต์ไม่ได้แต่เข้าถึงกระบวนการลงนามได้ก็ยังพิสูจน์ตัวตนได้ตราบที่การเข้าถึงนั้นยังอยู่

คีย์ในไฟล์คัดลอกได้ง่ายมาก จึงเป็นสิ่งที่สำรองและกู้คืนง่ายที่สุดด้วย ที่เก็บคีย์แบบซอฟต์แวร์เปลี่ยน API ไม่ใช่ขอบเขต: ผู้ให้บริการปฏิเสธการเรียกส่งออกของตัวเอง แต่บริบทผู้ดูแลระบบเดียวกันที่ติดตั้งคีย์มักมีเส้นทางอื่นไปยังวัสดุนั้น การเป็นแบบส่งออกไม่ได้ในผู้ให้บริการซอฟต์แวร์เป็นคำกล่าวเกี่ยวกับการดำเนินการที่รองรับ ไม่ใช่หลักฐานของกำแพงฮาร์ดแวร์ มองว่าเป็นตัวหน่วงการคัดลอกโดยไม่ตั้งใจ ไม่ใช่การป้องกันจากคนที่ถือเซสชันของคุณอยู่แล้ว

TPM หรือสมาร์ตการ์ดดำเนินการลงนามภายในฮาร์ดแวร์และคืนเฉพาะผลลัพธ์ สิ่งนี้ปิดเส้นทางการคัดลอกและเปิดเส้นทางการใช้งานให้ทุกสิ่งที่ขอลายเซ็นได้

จับคู่ที่เก็บกับเดมอนอุโมงค์

เดมอนจำกัดเรื่องนี้มากกว่านโยบายความปลอดภัย WireGuard รับคีย์ส่วนตัวแบบ base64 จากไฟล์หรือจากอินพุต wg set และไม่มีเส้นทางไปยังที่เก็บใบรับรอง คีย์อินเทอร์เฟซที่หนุนด้วย TPM จึงไม่อยู่ในขอบเขต OpenVPN ที่คอมไพล์กับ OpenSSL 3 โหลดคีย์ผ่าน URI ของผู้ให้บริการได้ และ strongSwan มีปลั๊กอิน TPM ควบคู่กับการรองรับ PKCS#11 แต่ทั้งสองขึ้นกับการคอมไพล์แพ็กเกจของคุณ

เดมอนที่ไม่ถึงที่เก็บที่เลือกทำให้ขอบเขตฮาร์ดแวร์กลายเป็นของประดับ มีคนส่งออกคีย์หนึ่งครั้ง ทิ้งไว้ในไฟล์ และส่วนที่เหลือของการออกแบบทำงานเงียบ ๆ บนสำเนานั้น

การต่ออายุคืออีกครึ่งของการจับคู่ และนี่คือที่ที่การออกแบบส่วนใหญ่พังทลาย ที่เก็บที่ใช้ได้ในการลงทะเบียนครั้งแรกแต่ต้องล็อกอินคอนโซลทุกครั้งที่ออกใหม่จะถูกข้ามครั้งแรกที่ใบรับรองหมดอายุในเวลาที่ไม่สะดวก ทดสอบเส้นทางการออกใหม่ขณะที่คีย์ปัจจุบันยังมีเดือนเหลือ

ทำรายการคีย์ก่อนย้าย

บันทึกว่าคีย์คืออะไรก่อนเปลี่ยนว่ามันอยู่ที่ใด เพราะการย้ายที่ทำ subject alternative names หายจะทำให้อุโมงค์เสียในลักษณะที่อ่านเป็นความผิดพลาดของการกำหนดเส้นทาง ส่งออกใบรับรอง ยืนยันว่าคีย์ส่วนตัวอ่านได้ในที่ที่เดมอนคาดหวัง และตรวจสอบว่าคู่กันตรงกันจริง

openssl x509 -in vpn.crt -noout -subject -ext subjectAltName
openssl pkey -in vpn.key -check -noout
openssl x509 -in vpn.crt -noout -pubkey | openssl sha256
openssl pkey -in vpn.key -pubout | openssl sha256

ไดเจสต์สองตัวสุดท้ายต้องเหมือนกัน ถ้าไม่ เดมอนจะตั้งค่าเสร็จแล้วล้มเหลวทุกครั้งด้วยข้อผิดพลาดใบรับรองหรือลายเซ็นที่ไม่ชี้ไปใกล้สาเหตุจริงเลย คู่เทียบของ WireGuard สั้นกว่าเพราะคีย์สาธารณะได้มาจากคีย์ส่วนตัวโดยตรง: wg pubkey < /etc/wireguard/wg0.key ต้องพิมพ์คีย์เพียร์ที่เซิร์ฟเวอร์ของคุณเก็บไว้แล้ว

สิทธิ์อยู่ในรายการเดียวกัน stat -c '%a %U:%G' /etc/wireguard/wg0.key ควรคืนค่า 600 root:root และอะไรก็ตามที่กลุ่มหรือทั้งโลกระอ่านได้หมายความว่าคีย์เคยพร้อมให้กระบวนการที่คุณไม่เคยตั้งใจ

ตรวจที่เก็บและเส้นทางการใช้งาน

การตรวจสอบมีสามส่วน และส่วนที่สามคือส่วนที่ถูกข้าม ยืนยันว่าคีย์อยู่ในที่เก็บที่เลือก ยืนยันว่าเดมอนโหลดคีย์นั้นไม่ใช่สำเนาที่ตกค้าง แล้วยืนยันว่ายังเริ่มทำงานได้เมื่อสิ่งส่งออกหายไป

certutil -store -user My
certutil -csp "Microsoft Platform Crypto Provider" -key -user
certutil -verifykeys -user My
ipsec listcerts

บน Windows คำสั่งแรกระบุที่เก็บส่วนบุคคลและพิมพ์ผู้ให้บริการคีย์ข้างแต่ละรายการ และนั่นคือที่ที่ ใบรับรองที่ดูเหมือนหนุนด้วยฮาร์ดแวร์แต่กลับอยู่ในผู้ให้บริการซอฟต์แวร์ ปรากฏขึ้น คำสั่งที่สองระบุคีย์ที่ผู้ให้บริการคริปโตของแพลตฟอร์มถืออยู่ ตัวตน VPN ที่หายไปที่นั่นทั้งที่ใบรับรองยังอยู่จึงหมายความว่าครึ่งส่วนตัวอยู่ที่อื่น บนเกตเวย์ Linux ipsec listcerts รายงานว่า strongSwan โหลดอะไร รวมถึงคีย์จากปลั๊กอิน TPM เปรียบเทียบลายนิ้วมือหรือแฮชคีย์สาธารณะกับรายการแทนการเชื่อจำนวนรายการ

การทดสอบเชิงลบคือสิ่งที่พิสูจน์การออกแบบ ย้ายคีย์ที่ส่งออกออกจากไดเรกทอรีการกำหนดค่าของเดมอน รีสตาร์ตบริการ และอ่านในบันทึกว่ามันแสดงตัวตนใด อุโมงค์ที่ยังขึ้นได้แสดงว่าใช้ที่เก็บ ส่วนการเริ่มที่ล้มเหลวหมายความว่าการออกแบบทำงานบนสำเนาจริง ๆ

เขียนการต่ออายุและการย้อนกลับ

การย้อนกลับต่างกันมากระหว่างสองตระกูล และความต่างนั้นเป็นของการบันทึกการออกแบบ ไม่ใช่การโทรแจ้งเหตุ คีย์ในไฟล์สำรองแบบเข้ารหัสและกู้คืนได้ การย้ายที่ล้มเหลวจึงย้อนกลับได้ คีย์ที่ส่งออกไม่ได้สำรองไม่ได้เลย ซึ่งทำให้การออกใหม่และการลงทะเบียนใหม่เป็นทางกู้คืนเดียวเมื่ออุปกรณ์ตาย

ตรวจการหมดอายุก่อนที่จะกลายเป็นการหยุดชะงัก: openssl x509 -in vpn.crt -noout -checkend 2592000 จบด้วยรหัสที่ไม่เป็นศูนย์เมื่อใบรับรองหมดอายุภายในสามสิบวัน จึงเสียบเข้ากับการตรวจสอบเฝ้าระวังได้ทันที การรันบรรทัดนั้นทุกสัปดาห์จับการต่ออายุที่ไม่มีใครวางแผน

การลบเกิดขึ้นที่เซิร์ฟเวอร์: ลบเพียร์หรือเพิกถอนหมายเลขซีเรียล แล้วยืนยันว่าอุโมงค์ล้มเหลว เพราะไคลเอนต์ที่มีเซสชันแคชอยู่อาจซ่อนการเพิกถอนที่ทำค้างไว้ได้ระยะหนึ่ง การเพิกถอนต้องไปถึงเส้นทาง CRL หรือ OCSP ของตัวรวมศูนย์ ไม่ใช่แค่ฐานข้อมูล CA ใบรับรองเป็นเอกสารสาธารณะ และโปรไฟล์ RFC 5280 ครอบคลุมวิธีการตรวจสอบ ไม่มีส่วนใดของการตรวจสอบนั้นป้องกันคีย์ส่วนตัวที่ถูกคัดลอกก่อนการหมุน

เขียนการตัดสินใจไว้ที่เดียว: ที่เก็บใดถือคีย์ กระบวนการใดใช้ได้ ใครออกใหม่ได้ และการย้อนกลับคืออะไร ย่อหน้านั้นคือสิ่งที่ผู้ตรวจสอบถาม และคือสิ่งที่อยู่รอดจากการเปลี่ยนบุคลากร