Category: Uncategorized

OpenSSL adalah toolkit kriptografi yang populer dengan lebih dari 20 tahun sejarah. Selama waktu yang lama, satu-satunya cara untuk memperluasnya adalah dengan menggunakan “engine”, yang mendefinisikan bagaimana algoritma kriptografi dihitung. Ini dapat mencakup perangkat keras dan bahkan algoritma baru yang tidak termasuk dalam pustaka utama, tetapi seiring berkembangnya OpenSSL, menjadi jelas bahwa API engine memiliki keterbatasan. Sistem baru yang dapat dipasang, yang disebut “provider”, diperkenalkan. Apa itu provider Provider, dalam istilah OpenSSL, adalah unit kode yang menyediakan satu atau lebih implementasi operasi kriptografi, sehingga membuat algoritma baru tersedia. Ini juga merupakan plugin yang dimuat secara dinamis yang dapat dimuat selama inisialisasi OpenSSL, selama sudah disebutkan dalam file konfigurasi OpenSSL. Provider juga dapat dimuat sesuai permintaan, yang sangat penting ketika Anda menggunakan algoritma lama (tidak aman) saat berinteraksi dengan sistem yang sangat lama, atau ketika Anda sedang bereksperimen dengan algoritma yang sangat baru. Konsep provider diperkenalkan ke dalam OpenSSL selama pengembangan versi 3.0. Tidak dapat dihindari bahwa beberapa konsep baru akan diimplementasikan untuk mencapai salah satu tujuan utama desain OpenSSL 3.0: Modul yang dapat dipelihara dan bersertifikat FIPS-140-3. Pendekatan sebelumnya yang menerapkan berbagai pengecekan runtime hampir tidak dapat dipertahankan, dan persyaratan FIPS adalah target yang selalu bergerak, sehingga penting untuk menerapkan model yang lebih kuat. API engine tidak memungkinkan pemisahan algoritma FIPS dan non-FIPS serta implementasinya dengan cara yang kokoh, dan juga tidak memastikan bahwa data tidak melintasi batas FIPS berulang kali, yang akan melanggar persyaratan FIPS. API provider dirancang dari awal, dan API engine telah deprecated. API yang deprecated mungkin akan dihapus di rilis utama mendatang. Apa yang telah berubah OpenSSL 3.0 diperkenalkan di Red Hat Enterprise Linux (RHEL) 9. Ini datang dengan tiga provider yang mencakup semua kasus penggunaan utama, termasuk modul FIPS. Di RHEL 9, tidak ada provider matang lainnya, jadi kami tidak memiliki pengganti yang sah untuk engine yang secara teratur digunakan di RHEL (yang paling penting adalah engine PKCS#11). Kami mendukung engine karena tidak ada pilihan lain. Namun, sejak saat itu, kami telah bekerja keras untuk menyediakan opsi pengganti untuk engine yang ada. Di RHEL 10, kami memiliki provider PKCS#11 baru. Kami juga menambahkan beberapa provider lainnya. Mengubah aplikasi dengan dukungan eksplisit untuk engine Untuk alasan kompatibilitas ABI, kami tidak dapat mengkompilasi OpenSSL tanpa dukungan engine. Namun, di RHEL 10 yang akan datang, kami akan menghapus deklarasi file header dari fungsi spesifik engine. Dengan menegakkan definisi OPENSSL_NO_ENGINE, kami menonaktifkan dukungan engine dalam aplikasi yang dengan benar mendeteksi dukungan engine pada waktu build. Kami menemukan sejumlah kecil aplikasi yang menggunakan engine dengan cara yang membutuhkan perubahan kode yang signifikan. Namun, sebagian besar aplikasi menghormati definisi OPENSSL_NO_ENGINE dan tidak memerlukan perubahan kode. Beberapa aplikasi menyertakan file header openssl/engine.h meskipun mereka mendukung definisi OPENSSL_NO_ENGINE. Di RHEL 10, kami mengubah file header engine.h menjadi file kosong. Beberapa aplikasi memiliki mekanisme kustom untuk mendeteksi keberadaan engine, tetapi sering kali salah. Beberapa mengharapkan engine selalu tersedia di OpenSSL, tetapi tidak di fork OpenSSL. Semua aplikasi ini memerlukan perubahan, baik di upstream maupun downstream. Kami memperkenalkan perubahan yang sama di Fedora. Komunitas tidak menyetujui ide untuk sekadar menghapus file engine.h di sana, jadi kami memindahkannya ke paket terpisah dan mendefinisikan simbol OPENSSL_NO_ENGINE hanya ketika header tersebut tidak diinstal. Provider yang menonjol di RHEL 10 RHEL 10 memiliki provider PKCS#11 baru. Ini sepenuhnya mencakup fungsionalitas dari engine PKCS#11 lama, dan memungkinkan penyesuaian untuk beberapa token spesifik. Provider ini telah diuji secara ekstensif oleh pelanggan internal dan eksternal dan tidak ada masalah besar yang kami ketahui. Kami juga menyertakan provider TPM2, solusi berbasis perangkat keras lainnya. TPM2 adalah chip yang ada di sebagian besar komputer modern. Chip ini memastikan bahwa proses boot dimulai dari kombinasi perangkat keras dan perangkat lunak yang terpercaya, dan membantu membangun lingkungan eksekusi yang terpercaya. Provider TPM2 memungkinkan pengguna untuk mengoperasikan chip ini dan menggunakan kunci-kuncinya melalui API OpenSSL. Akhirnya, kami menambahkan provider OQS, yang membawa algoritma pasca-kuantum ke OpenSSL. Transisi kriptografi pasca-kuantum adalah salah satu tantangan kriptografi terbesar dalam masa hidup RHEL 10. Provider ini memungkinkan pengguna akhir dan pengembang untuk melakukan eksperimen dengan kriptografi pasca-kuantum hingga OpenSSL menambahkan dukungan native. Kesimpulan Perubahan versi utama umumnya merupakan waktu yang baik untuk menghapus fungsionalitas yang sudah tidak didukung. Kami tidak mengetahui adanya skenario umum yang sebelumnya ditangani oleh engine yang tidak tercakup oleh provider. Aplikasi sekarang tidak perlu peduli tentang detail implementasi. Sebaliknya, kode dapat ditulis dengan cara yang secara transparan menggunakan kunci yang dikelola oleh provider, berlawanan dengan penggunaan engine sebelumnya yang memerlukan kode kustom.