API ของ OpenSSL: โครงสร้างหลักและข้อผิดพลาดที่ควรระวัง

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

การเข้ารหัสแบบสมมาตรใน OpenSSL ใช้ออบเจ็กต์บริบท EVP_CIPHER_CTX ลำดับการดำเนินการคือ EVP_CIPHER_CTX_new เพื่อจัดสรรบริบท, EVP_EncryptInit_ex เพื่อเริ่มต้นด้วยชุดรหัสและคีย์, EVP_EncryptUpdate เพื่อประมวลผลข้อมูลซ้ำ ๆ, EVP_EncryptFinal_ex เพื่อล้างบล็อกสุดท้ายและรับผลลัพธ์ที่เหลือ และ EVP_CIPHER_CTX_free เพื่อคืนหน่วยความจำ การข้าม EncryptFinal_ex เป็นข้อผิดพลาดที่พบบ่อยและทำให้ผลลัพธ์ไม่ครบถ้วน

การสร้างค่าแฮชของข้อความใช้ EVP_MD_CTX ในลักษณะเดียวกัน ได้แก่ EVP_MD_CTX_new, EVP_DigestInit_ex พร้อมอัลกอริทึม (EVP_sha256(), EVP_sha3_256() และอื่น ๆ), EVP_DigestUpdate พร้อมชิ้นส่วนข้อมูล และ EVP_DigestFinal_ex เพื่อรับค่าแฮช การดำเนินการ HMAC ใช้ HMAC_CTX แยกต่างหากหรือ API EVP_MAC รุ่นใหม่กว่า การแยกส่วนด้วย EVP ช่วยให้เปลี่ยนอัลกอริทึมแฮชได้โดยแก้ไขการเรียกฟังก์ชันเพียงครั้งเดียว

EVP_PKEY คือออบเจ็กต์คีย์แบบอสมมาตรแบบรวมเป็นหนึ่งของ OpenSSL ซึ่งรองรับ RSA, ECDSA, Ed25519, DH และอัลกอริทึมอื่น ๆ ผ่านอินเทอร์เฟซเดียวกัน สามารถสร้างคีย์จากไฟล์ PEM หรือ DER ด้วย PEM_read_PrivateKey และ PEM_read_PUBKEY หรือสร้างขึ้นด้วย EVP_PKEY_keygen ได้ EVP_PKEY_sign และ EVP_PKEY_verify ใช้ลงนามและตรวจสอบสำหรับคีย์ทุกประเภทด้วยการเรียกฟังก์ชันชุดเดียวกัน

BIO (อินพุต/เอาต์พุตพื้นฐาน) คือชั้นการแยกส่วนด้านอินพุต/เอาต์พุตของ OpenSSL ซึ่งช่วยให้อ่านและเขียนข้อมูลที่ป้องกันด้วย TLS หรือข้อมูลดิบผ่านสายโซ่ของออบเจ็กต์ BIO ได้ สายโซ่ BIO อาจเป็น BIO_new_ssl (ชั้น TLS) ต่อกับ BIO_new_connect (การเชื่อมต่อ TCP) การเขียนไปยัง BIO ของ SSL จะเข้ารหัสและส่งข้อมูลโดยอัตโนมัติ ส่วนการอ่านจะถอดรหัสข้อมูลที่ได้รับ ออบเจ็กต์ BIO รองรับไฟล์ ซ็อกเก็ต บัฟเฟอร์หน่วยความจำ และตัวกรอง (base64 และการทำบัฟเฟอร์)

การเชื่อมต่อ TLS ใน OpenSSL ใช้ออบเจ็กต์สองชนิด: SSL_CTX (บริบท) จัดเก็บการกำหนดค่าร่วม ได้แก่ ใบรับรอง คีย์ส่วนตัว ชุดใบรับรอง CA ขีดจำกัดรุ่นโพรโทคอล และรายการชุดรหัส ส่วน SSL แทนการเชื่อมต่อแต่ละรายการที่สร้างจากบริบทนั้น ให้สร้าง SSL_CTX หนึ่งรายการต่อแอปพลิเคชัน แล้วสร้างออบเจ็กต์ SSL จากบริบทดังกล่าวสำหรับแต่ละการเชื่อมต่อ SSL_read และ SSL_write ใช้ถ่ายโอนข้อความธรรมดา ส่วน OpenSSL จะจัดการการจัดเฟรม TLS และการเข้ารหัสทั้งหมดภายใน

ข้อผิดพลาดของ OpenSSL ที่อันตรายที่สุดคือการเพิกเฉยต่อค่าที่ส่งกลับ EVP_EncryptFinal_ex, SSL_read และ SSL_write ล้วนส่งคืนค่าติดลบหรือศูนย์เพื่อระบุข้อผิดพลาด การเรียก SSL_read ในลูปโดยไม่ตรวจสอบ SSL_get_error อาจทำให้เกิดลูปไม่สิ้นสุดหรือพลาดข้อผิดพลาดได้ ต้องตรวจสอบค่าที่ส่งกลับจากฟังก์ชัน OpenSSL ทุกฟังก์ชันที่อาจล้มเหลว เพราะความล้มเหลวมักบ่งชี้เงื่อนไขที่เกี่ยวข้องกับความปลอดภัย เช่น การจับมือเชื่อมต่อล้มเหลวหรือการตรวจสอบใบรับรองผิดพลาด

SSL_read และ SSL_write อาจส่งคืน SSL_ERROR_WANT_READ หรือ SSL_ERROR_WANT_WRITE ซึ่งระบุว่าควรลองดำเนินการอีกครั้งหลังจากรออินพุต/เอาต์พุต ค่าเหล่านี้ไม่ใช่ข้อผิดพลาดจริง แต่เป็นการแจ้งเตือนอินพุต/เอาต์พุตแบบไม่บล็อก โค้ดที่ไม่เรียก SSL_get_error และไม่แยกแขนงตาม want-read/want-write อย่างถูกต้อง จะวนลูปไม่หยุดหรือปฏิบัติต่อเงื่อนไขเหล่านี้เป็นข้อผิดพลาดอย่างไม่ถูกต้อง ควรใช้ SSL_get_error เพื่อตีความค่าที่ส่งกลับติดลบจากการดำเนินการอินพุต/เอาต์พุตของ TLS เสมอ

OpenSSL มีฟังก์ชันระดับต่ำที่เลิกใช้แล้วจำนวนมาก ซึ่งไม่ควรปรากฏในโค้ดใหม่ ได้แก่ การเรียก DES_encrypt1 โดยตรง การใช้ฟังก์ชันแฮช SHA1 หรือ MD5 โดยตรงโดยไม่ผ่านชั้น EVP, RSA_private_encrypt แทน EVP_PKEY_sign และ AES_encrypt (AES ECB ที่ไม่มีการยืนยันความถูกต้อง) API เหล่านี้ข้ามการตรวจสอบความปลอดภัย ใช้อัลกอริทึมที่เลิกใช้แล้ว หรือไม่ปลอดภัยเทียบเท่ากับ API EVP ที่สอดคล้องกัน คำเตือนจากคอมไพเลอร์มักแจ้งการใช้ API ที่เลิกใช้แล้ว

OpenSSL ใช้การจัดการหน่วยความจำอย่างชัดเจน ออบเจ็กต์ที่จัดสรรทุกตัวต้องได้รับการคืนหน่วยความจำอย่างชัดเจน หน่วยความจำรั่วที่พบบ่อย ได้แก่ ลืมเรียก EVP_CIPHER_CTX_free หลังการเข้ารหัส ไม่เรียก SSL_free หลังปิดการเชื่อมต่อ หรือไม่เรียก X509_free หลังตรวจสอบใบรับรอง ในเซิร์ฟเวอร์ที่ทำงานต่อเนื่องเป็นเวลานาน หน่วยความจำรั่วเหล่านี้ทำให้หน่วยความจำหมดลงทีละน้อย ควรใช้เครื่องมืออย่าง valgrind หรือ AddressSanitizer เพื่อตรวจหาหน่วยความจำรั่วของ OpenSSL ระหว่างการพัฒนา

OpenSSL 3.0 นำโมเดลผู้ให้บริการมาใช้แทน API ENGINE รุ่นเก่าสำหรับการเร่งความเร็วด้วยฮาร์ดแวร์ ผู้ให้บริการคือโมดูลที่โหลดได้ซึ่งใช้งานอัลกอริทึมการเข้ารหัสลับ ได้แก่ ผู้ให้บริการเริ่มต้น (ซอฟต์แวร์) ผู้ให้บริการรุ่นเก่า (อัลกอริทึมรุ่นเก่า) ผู้ให้บริการ FIPS (ผ่านการตรวจรับรอง FIPS 140-2) และผู้ให้บริการจากบุคคลที่สามสำหรับ HSM ผู้ให้บริการ FIPS ช่วยให้ทำงานตามข้อกำหนดได้ โดยจำกัดอัลกอริทึมที่ใช้ได้ให้เหลือเฉพาะอัลกอริทึมที่ FIPS 140-2 อนุมัติ โดยไม่ต้องเปลี่ยนโค้ดแอปพลิเคชัน

เหตุใดจึงควรใช้ API EVP ของ OpenSSL แทน API ระดับต่ำที่เฉพาะเจาะจงกับอัลกอริทึม

สรุป API ของ OpenSSL: ใช้ API EVP ระดับสูงเสมอ, ใช้ EVP_CIPHER_CTX สำหรับการดำเนินการแบบสมมาตร, ใช้ EVP_MD_CTX สำหรับการแฮช, ใช้ EVP_PKEY สำหรับคีย์แบบอสมมาตร, ใช้สายโซ่ BIO เพื่อแยกส่วนอินพุต/เอาต์พุต, ใช้ SSL_CTX และ SSL สำหรับการเชื่อมต่อ TLS, ตรวจสอบค่าที่ส่งกลับและเรียก SSL_get_error เสมอ, คืนหน่วยความจำของออบเจ็กต์ที่จัดสรรทั้งหมดเพื่อป้องกันหน่วยความจำรั่ว, หลีกเลี่ยงฟังก์ชันระดับต่ำที่เลิกใช้แล้ว และใช้ผู้ให้บริการของ OpenSSL 3.0 เพื่อให้เป็นไปตามข้อกำหนด FIPS หรือเพื่อเร่งความเร็วด้วยฮาร์ดแวร์