Pinning SPKI TLS Memerlukan Jalur Rotasi

Certificate pinning menambahkan batas trust lokal di atas pemeriksaan sertifikat yang sudah dilakukan TLS client. Alih-alih menerima setiap sertifikat yang memenuhi aturan PKI dan identitas service yang dikonfigurasi, client dengan pin juga mensyaratkan koneksi menyajikan material kriptografis yang cocok dengan nilai yang sudah ditanam, diprovisikan, atau dipercaya melalui mekanisme lain oleh client.

Policy yang lebih sempit ini dapat mengurangi paparan terhadap penerbitan sertifikat di luar key set yang dimaksud. Konsekuensinya adalah dependency operasional baru: client harus memiliki jalur yang valid dari key yang diterima saat ini menuju key yang dapat dipakai setelah rotasi.

Pin menjadi syarat penerimaan tambahan

Autentikasi HTTPS biasa umumnya menggabungkan certificate path validation dengan verifikasi identitas service. Keputusan sederhananya dapat ditulis sebagai:

chain valid
    AND
identitas sertifikat cocok dengan api.example.com
    => terima

Client dengan SPKI pinning menambahkan satu predikat:

chain valid
    AND
identitas sertifikat cocok dengan api.example.com
    AND
hash SPKI ada di pin set yang dikonfigurasi
    => terima

Pin tidak menggantikan verifikasi hostname, pemeriksaan masa berlaku sertifikat, atau path validation kecuali implementasi tertentu secara eksplisit menetapkan trust model yang berbeda. Menganggap pin yang cocok sebagai izin untuk melewati pemeriksaan tersebut dapat memperluas hal yang diterima client tanpa terlihat jelas.

Properti keamanan yang berguna berasal dari irisan semua syarat. Peer harus memenuhi policy autentikasi TLS normal sekaligus key policy aplikasi yang lebih sempit.

SPKI pin terikat ke public key, bukan seluruh sertifikat

Target pin yang umum adalah struktur SubjectPublicKeyInfo berformat DER, biasanya direpresentasikan melalui cryptographic hash. SPKI memuat identifier algoritma public key dan nilai public key.

Secara konseptual:

certificate
    |
    +-- subject
    +-- issuer
    +-- validity
    +-- extensions
    +-- SubjectPublicKeyInfo
            |
            +-- algorithm
            +-- public key
                    |
                    +-- hash untuk perbandingan pin

Hash terhadap SPKI, bukan seluruh sertifikat, memungkinkan renewal sertifikat sambil mempertahankan key pair yang sama. Field seperti masa berlaku, serial number, dan banyak extension dapat berubah tanpa mengubah nilai SPKI.

Fleksibilitas itu memiliki batas. Penggantian key pair mengubah SPKI dan dengan demikian mengubah pin. Renewal sertifikat yang sekaligus melakukan key rotation tidak transparan bagi client yang hanya membawa pin untuk key sebelumnya.

Satu pin aktif membentuk dependency yang rapuh

Pertimbangkan sebuah rilis aplikasi yang hanya memuat satu pin:

SPKI yang diterima:
    sha256/ACTIVE_KEY_HASH

Server kemudian beralih ke key baru, baik sebagai maintenance terencana maupun karena private key lama harus dipensiunkan. Sertifikat baru dapat memiliki chain valid dan identitas DNS yang benar, tetapi tetap gagal pada pemeriksaan pin aplikasi.

Kegagalan terjadi sebelum aplikasi dapat memakai koneksi TLS tersebut untuk mengambil pembaruan konfigurasi dari endpoint yang sama. Jika satu-satunya recovery channel bergantung pada koneksi yang ditolak, pin telah membentuk bootstrap deadlock.

Inilah risiko operasional utama static pinning. Trust state di sisi client dapat bertahan lebih lama daripada server key yang dirujuknya.

Backup pin menyediakan transisi yang sudah diotorisasi

Desain statis yang lebih aman dapat memprovisikan lebih dari satu nilai SPKI yang diterima sebelum rotasi:

SPKI yang diterima:
    sha256/CURRENT_KEY_HASH
    sha256/NEXT_KEY_HASH

Pada awalnya server menyajikan sertifikat untuk key saat ini. Sebelum key tersebut dipensiunkan, key berikutnya sudah diterima oleh client yang telah terpasang. Rotasi kemudian mengubah approved key yang disajikan server, bukan memperkenalkan key yang belum pernah diotorisasi client.

Setelah cukup banyak client membawa backup berikutnya, rilis aplikasi selanjutnya dapat menghentikan pin lama. Urutannya penting:

rilis A: accept key 1 + key 2
server:  present key 1

server:  rotate to key 2

rilis B: accept key 2 + key 3
server:  present key 2

Pola ini tidak membuat rotasi berjalan otomatis. Distribution lag, versi client yang tidak lagi didukung, penggantian key darurat, dan perilaku trust yang berbeda antarplatform tetap memerlukan policy eksplisit. Namun, pola ini menghapus asumsi bahwa key yang sedang dipakai akan terus tersedia sampai setiap client menerima rilis baru.

Cakupan pin menentukan blast radius

Pin pada end-entity key mengikat client secara ketat ke satu service key. Pin pada intermediate CA key dapat memberi fleksibilitas lebih besar untuk sertifikat dan leaf key, tetapi juga mengotorisasi kumpulan sertifikat yang lebih luas yang chain-nya melewati intermediate tersebut, tetap tunduk pada policy validasi client lainnya.

Tidak ada satu cakupan yang selalu lebih tepat. Pemilihannya adalah keputusan trust.

Pin leaf key yang sempit dapat mengurangi jumlah key yang diterima untuk sebuah service sambil meningkatkan kebutuhan koordinasi saat rotasi. Pin tingkat issuer yang lebih luas dapat mempermudah leaf rotation sambil mendelegasikan otoritas lebih besar kepada issuer key yang dipin. Target pin perlu sesuai dengan otoritas yang memang hendak diberikan aplikasi.

Shared infrastructure menambah dimensi lain. Jika beberapa hostname memakai pinned key yang sama, compromise atau penggantian darurat pada key tersebut berdampak pada setiap client yang bergantung padanya. Pin reuse dapat menyederhanakan operasi sekaligus memperluas failure domain.

Policy kedaluwarsa memerlukan mode kegagalan yang tegas

Sebagian sistem pinning memasang waktu kedaluwarsa pada pin state yang diprovisikan secara remote; sistem lain mengirim pin sebagai konfigurasi aplikasi tanpa lifetime terpisah. Kedua desain ini gagal dengan cara berbeda.

Pin yang setelah kedaluwarsa kembali ke validasi PKI biasa dapat memulihkan konektivitas ketika pin state menjadi usang, tetapi pembatasan tambahan juga hilang setelah masa itu. Pin yang tidak pernah kedaluwarsa mempertahankan pembatasan, tetapi dapat membuat client tidak dapat terhubung jika semua key yang diterima tidak lagi tersedia.

Perilaku yang tepat bergantung pada threat model dan recovery channel yang tersedia. Hal yang penting adalah semantik kedaluwarsa ditetapkan secara eksplisit. Fallback implisit yang ditambahkan saat insiden dapat menghapus properti keamanan yang menjadi alasan awal penerapan pinning.

Recovery tidak boleh bergantung pada trust path yang gagal

Perencanaan operasional perlu mencakup kondisi ketika semua server key yang sedang disajikan tidak ada dalam pin set client. Mekanisme recovery berbeda menurut platform: application update yang didistribusikan melalui channel terautentikasi terpisah, backup key yang sudah diprovisikan, atau endpoint berbeda dengan trust yang dikelola secara independen.

Mekanisme recovery harus memiliki authentication path yang kredibel. Mengambil pin pengganti melalui koneksi yang baru diterima setelah pemeriksaan pin yang gagal dinonaktifkan akan mengubah recovery menjadi bypass.

Syarat ini mudah terlewat karena rotasi sertifikat sering dianggap sebagai maintenance server. Dengan pinning, rotasi juga mengubah acceptance state pada client. Proses rilis server dan client menjadi bagian dari trust lifecycle yang sama.

Pinning adalah komitmen lifecycle

SPKI pinning dapat membuat penerimaan sertifikat lebih selektif, tetapi pin set menjadi konfigurasi sensitif terhadap keamanan yang dibawa client. Nilainya bergantung pada seluruh lifecycle: provisioning awal, renewal sertifikat normal, key rotation, penyimpanan backup key, keterlambatan update client, penggantian darurat, dan penghentian pin lama.

Deployment yang tangguh karena itu memperlakukan key berikutnya yang dapat diterima sebagai bagian dari konfigurasi saat ini. Key yang disajikan sekarang hanyalah satu titik dalam urutan trust; jalur rotasi menjaga urutan tersebut tetap ketat sekaligus operasional.