การตรวจสอบและคัดเลือกส่วนพึ่งพาด้านการเข้ารหัส

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

หนึ่งในคำถามแรกสำหรับไลบรารีการเข้ารหัสใด ๆ คือ มีการตรวจสอบโดยอิสระครั้งล่าสุดเมื่อใด และการตรวจสอบนั้นครอบคลุมเรื่องใดบ้าง การตรวจสอบเมื่อห้าปีก่อนบนเวอร์ชัน 1.0 ให้ความมั่นใจแก่เวอร์ชัน 3.0 ที่ใช้อยู่ในปัจจุบันได้น้อยกว่า ควรมองหาการตรวจสอบที่ดำเนินการโดยบริษัทความปลอดภัยที่มีชื่อเสียง เช่น NCC Group, Trail of Bits, Quarkslab และ Cure53 และครอบคลุมฟังก์ชันการทำงานเฉพาะที่คุณวางแผนจะใช้ ไลบรารีบางแห่งเผยแพร่รายงานการตรวจสอบต่อสาธารณะ การไม่มีการตรวจสอบใด ๆ ถือเป็นปัจจัยเสี่ยงที่สำคัญ

ตรวจสอบประวัติ CVE ของไลบรารีใน NVD (ฐานข้อมูลช่องโหว่แห่งชาติ) โดยพิจารณาว่ามี CVE กี่รายการ ระดับความรุนแรงเป็นอย่างไร ช่องโหว่เหล่านั้นเป็นประเภทใด เช่น ข้อผิดพลาดทางตรรกะ ความเสียหายของหน่วยความจำ หรือจุดอ่อนของอัลกอริทึม และผู้ดูแลไลบรารีออกโปรแกรมแก้ไขได้รวดเร็วเพียงใด ไลบรารีที่มี CVE เป็นครั้งคราวและแก้ไขได้อย่างรวดเร็วแสดงให้เห็นถึงการบำรุงรักษาที่ตอบสนองได้ดี ส่วนไลบรารีที่มี CVE ระดับรุนแรงจำนวนมากหรือแก้ไขช้า ถือเป็นสัญญาณอันตราย

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

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

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

ไลบรารีการเข้ารหัสที่ดีควรรองรับอัลกอริทึมสมัยใหม่และมีแผนเลิกใช้อัลกอริทึมที่ล้าสมัย ควรมี ChaCha20-Poly1305 หรือ AES-256-GCM สำหรับการเข้ารหัส Ed25519 หรือ ECDSA P-256 สำหรับลายมือชื่อ X25519 สำหรับการแลกเปลี่ยนกุญแจ และ Argon2id สำหรับการแฮชรหัสผ่าน ไลบรารีที่มีเฉพาะอัลกอริทึมรุ่นเก่า เช่น DES, RC4, MD5 และ SHA-1 ไม่เหมาะสำหรับการนำไปใช้งานใหม่ ไม่ว่าจะมีคุณสมบัติด้านอื่นดีเพียงใด

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

อุตสาหกรรมที่อยู่ภายใต้การกำกับดูแล เช่น การแพทย์ การเงิน และภาครัฐ มักกำหนดให้ใช้โมดูลการเข้ารหัสที่ผ่านการตรวจสอบความถูกต้องตาม FIPS 140-2 หรือ 140-3 การตรวจสอบตาม FIPS มีค่าใช้จ่ายสูงและใช้เวลานาน จึงมีไลบรารีเพียงบางส่วนที่ผ่านการตรวจสอบนี้ OpenSSL ที่มีผู้ให้บริการ FIPS, BoringCrypto ซึ่งใช้ใน Go's crypto/tls และไลบรารี HSM บางรายการผ่านการตรวจสอบความถูกต้องตาม FIPS แล้ว หากการนำระบบไปใช้งานของคุณต้องปฏิบัติตาม FIPS ข้อกำหนดนี้จะจำกัดตัวเลือกไลบรารีลงอย่างมาก

โมดูลความปลอดภัยฮาร์ดแวร์ (HSM) และบริการ KMS บนคลาวด์มักมี API เฉพาะสำหรับการดำเนินการเกี่ยวกับกุญแจ การผูกแอปพลิเคชันของคุณไว้กับ AWS KMS หรือผู้จำหน่าย HSM รายใดรายหนึ่งอย่างแน่นหนาจะสร้างความเสี่ยงจากการผูกติดผู้ขาย ควรประเมินว่าไลบรารีมีชั้นนามธรรม เช่น การผสานรวม KMS ของ Tink ที่ช่วยให้เปลี่ยนผู้ให้บริการได้หรือไม่ นอกจากนี้ควรพิจารณาด้วยว่า หากผู้จำหน่าย HSM หยุดให้การสนับสนุนหรือขึ้นราคา ค่าใช้จ่ายในการย้ายระบบอาจสูงมาก

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

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