Enkripsi PDF AES-256 di Delphi: Penyiapan HotPDF dan Masalahnya

Sebuah flag izin PDF bukanlah gembok. Itu adalah permintaan yang diajukan file kepada apa pun yang membukanya, dan viewer bebas mengabaikannya. Fakta tunggal ini menentukan bagaimana seharusnya kita menalar setiap pilihan lain di halaman ini. Kerahasiaan yang sesungguhnya hanya berasal dari satu tempat: enkripsi AES-256 yang dikunci dengan password yang tidak dimiliki pembaca. Selain itu, checkbox "no printing" dan "no copying" hanyalah kebijakan yang disepakati untuk dihormati oleh software yang patuh dan tidak dihormati oleh software yang jahat. Campurkan kedua lapisan ini dan Anda akan merilis sesuatu yang terasa aman dalam demo namun bocor di lapangan

HotPDF adalah komponen PDF VCL native untuk Delphi dan C++Builder, dan ia mengekspos model proteksi ISO 32000 melalui sekumpulan kecil property. Property-property ini mudah untuk diatur. Bagian yang sulit adalah mengetahui yang mana yang benar-benar memberi proteksi kriptografis dan yang mana yang hanya memberi saran sopan, serta memastikan urutan penetapannya benar sehingga enkripsi yang Anda minta memang menjadi enkripsi yang Anda dapatkan

Apa yang sebenarnya dijanjikan oleh kedua password

Enkripsi PDF mendefinisikan dua kredensial dengan tugas yang berbeda, dan mencampuradukkan keduanya adalah kesalahan desain paling umum dalam kode output terproteksi. User password menjaga gerbang dekripsi. Tanpanya, atau tanpa owner password, sebuah reader yang patuh tidak dapat merekonstruksi file key dan konten tetap tidak terbaca secara kriptografis. Owner password sebaliknya menjaga gerbang pengaturan izin: reader yang menerima owner password diberi akses penuh apa pun isi flag pembatasannya

Bit izin berdiri di atas landasan yang lebih lemah. Pencetakan, ekstraksi konten, pengisian form: masing-masing adalah flag yang dibaca viewer dan dipilih untuk dihormati (ISO 32000-2 §7.6.4). Enkripsi melindungi byte-nya. Flag izin hanya menginstruksikan software yang patuh, dan instruksi itu diberikan setelah kejadiannya. Siapa pun yang membuka dokumen dengan user password sudah memegang konten yang telah didekripsi di memori, sehingga "no copy" dan "no print" berarti sesuatu bagi viewer yang berperilaku baik dan tidak berarti apa-apa bagi yang nekat. Bangun threat model Anda di sekitar garis itu. Kerahasiaan bermukim di user password. Izin membentuk apa yang ditawarkan oleh viewer arus utama, dan itulah keseluruhan yang mereka lakukan

Urutan konfigurasi: semuanya sebelum BeginDoc

HotPDF membangun dictionary enkripsi dan menurunkan file key pada saat BeginDoc dijalankan. Apa pun yang dipegang oleh property proteksi pada saat itu itulah yang didapatkan dokumen, dan mengubahnya sesudahnya tidak mengubah apa-apa. Property yang paling penting di sini adalah CryptKeyLength, yang memilih skema dari nilai THPDFKeyType k40, k128, aes128, dan aes256. Tetapkan setelah BeginDoc dan Anda tidak akan mendapat exception, tidak ada peringatan, hanya sebuah file yang diam-diam mempertahankan apa pun yang dimulainya. Jenis divergensi diam-diam seperti ini adalah yang paling buruk: ia lolos setiap uji lokal dan muncul berbulan-bulan kemudian sebagai temuan kepatuhan di meja pelanggan

var
  Pdf: THotPDF;
begin
  Pdf := THotPDF.Create(nil);
  try
    Pdf.FileName := 'statement.pdf';
    Pdf.ActivateProtection := True;
    Pdf.CryptKeyLength := aes256;        // harus diatur sebelum BeginDoc
    Pdf.UserPassword := 'open-secret';
    Pdf.OwnerPassword := 'admin-secret';
    Pdf.UseAES256R6 := False;            // R=5: dukungan viewer terluas
    Pdf.BeginDoc;
    Pdf.CurrentPage.SetFont('Arial', [], 11);
    Pdf.CurrentPage.TextOut(50, 720, 0, 'Account statement, June 2026');
    Pdf.EndDoc;
  finally
    Pdf.Free;
  end;
end;

Password menggunakan UTF-8 dan dibatasi maksimal 127 byte, yang merupakan batas ISO 32000-2 untuk skema AES-256. Jika kebijakan password Anda memberikan secret yang lebih panjang, lakukan pemotongan sendiri, di sisi Anda, di mana Anda mengendalikan persis di mana batas potongnya jatuh. Serahkan pada keberuntungan dan library serta viewer di masa depan bisa saja berbeda pendapat soal titik potongnya, yang menghasilkan file yang terbuka bagi Anda namun menolak password yang sama di tempat lain

Revision 5 atau revision 6: satu boolean, dua ekosistem

UseAES256R6 memilih di antara dua jabat tangan (handshake) AES-256, dan pilihan ini lebih berkonsekuensi daripada yang disarankan oleh tipe boolean-nya. Biarkan False dan HotPDF menulis revision 5, skema AES-256 yang hadir sebagai ekstensi PDF 1.7 dan yang bisa dibuka oleh viewer selama kurang lebih lima belas tahun terakhir. Atur ke True dan Anda mendapat revision 6, penurunan key yang diperkeras dan distandarkan dalam ISO 32000-2 untuk PDF 2.0, yang menutup kelemahan yang diketahui pada cara revision 5 memverifikasi password

Jadi secara kriptografis revision 6 adalah cerita yang lebih baik. Namun ia juga yang paling sering merusak sesuatu. File revision 6 membutuhkan viewer yang dibangun untuk PDF 1.7 Extension Level 3 atau PDF 2.0, dan banyak software yang sudah di-deploy bukan keduanya: arsip records-management, renderer tertanam pada produk lain, tool line-of-business yang sudah bertahun-tahun tidak disentuh. Software-software itu akan menolak file secara langsung, dan itu terjadi di mesin pelanggan, tidak pernah di mesin Anda. Karena itu default yang praktis adalah revision 5. Gunakan revision 6 hanya ketika sebuah kebijakan keamanan menyebutkan ISO 32000-2 berdasarkan revision-nya, dan ketika Anda benar-benar sudah memastikan setiap konsumen bisa membacanya. Apa pun pilihannya, catat mana yang Anda pilih dan alasannya, karena orang berikutnya yang menyentuh kode ini akan bertanya-tanya

Tipe key yang lebih lama layak mendapat satu kalimat agar Anda tahu untuk melewatkannya. THPDFKeyType masih mencantumkan k40, k128, dan aes128, namun keberadaannya untuk mereproduksi arsip historis, bukan untuk melindungi arsip baru. RC4 40-bit dapat ditembus oleh hardware komoditas, dan skema 128-bit mendahului revision AES-256 yang akan diharapkan oleh review keamanan mana pun saat ini. Untuk dokumen yang Anda buat pada 2026, pertanyaan sesungguhnya hanyalah revision 5 versus revision 6; jika Anda mendapati diri Anda menggunakan tipe lawas pada desain baru, ada sesuatu di hulu yang sudah keliru

Flag izin tanpa open password

Sering kali kebutuhannya justru kebalikan dari kerahasiaan. Siapa pun harus bisa membaca dokumen, namun pencetakan atau ekstraksi dimaksudkan untuk dibatasi. Anda menyatakan itu dengan user password kosong dan owner password yang tidak kosong, yang oleh PDF disebut open-password mode, dan Anda mendaftarkan operasi yang ingin diizinkan dalam ProtectOptions

Pdf.ActivateProtection := True;
Pdf.CryptKeyLength := aes256;
Pdf.UserPassword := '';                      // siapa pun bisa membuka file ini
Pdf.OwnerPassword := 'rotate-me-quarterly';  // menjaga kumpulan izin
Pdf.ProtectOptions := [prPrint, prPrint12bit, prExtractContent];
Pdf.BeginDoc;
// ... konten halaman ...
Pdf.EndDoc;

Set THPDFProtectOptions memetakan ke bit izin ISO: prPrint dan prPrint12bit untuk pencetakan resolusi tinggi, prInformationCopy untuk penyalinan dan ekstraksi umum, prExtractContent untuk ekstraksi assistive-technology, ditambah prModifyStructure, prEditAnnotations, prFillAnnotations, dan prAssemble. Dua di antaranya layak mendapat peringatan. Biarkan prExtractContent tetap aktif di hampir setiap profil yang Anda buat. Itulah bit yang dibutuhkan screen reader untuk menjangkau teks, dan menonaktifkannya diam-diam mengubah sebuah keputusan hak menjadi cacat aksesibilitas yang dialami seseorang dengan disabilitas dan tidak pernah Anda lihat sendiri. Jebakan lainnya adalah prPrint yang berdiri sendiri, tanpa prPrint12bit: beberapa viewer meresponsnya dengan menurunkan kualitas cetak, dan pengguna Anda akan melaporkannya sebagai bug rendering, padahal sebenarnya itu adalah pengaturan izin

Verifikasi ini hanya butuh lima menit dan seharusnya menjadi bagian dari release checklist Anda. Buka satu sampel dari setiap profil di Acrobat, buka Document Properties, dan baca tab Security, yang menjabarkan algoritma yang dipakai ("AES 256-bit") dan mendaftarkan operasi yang diizinkan satu per satu. Lalu buka file yang sama di viewer tertua yang benar-benar dipakai pelanggan Anda, bukan yang terbaru di mesin Anda. Pembukaan kedua ini adalah asuransi murah terhadap file revision 6 yang lolos mulus selama pengembangan namun gagal di pelanggan yang tidak pernah melakukan upgrade

Menghapus proteksi dari file yang sudah ada

Dekripsi menjalankan model property yang sama secara terbalik. Muat dokumen dengan kredensial yang valid, matikan proteksi, dan simpan hasilnya tanpa proteksi tersebut

var
  Pdf: THotPDF;
  PageCount: Integer;
begin
  Pdf := THotPDF.Create(nil);
  try
    PageCount := Pdf.LoadFromFile('encrypted.pdf', 'open-secret');
    if PageCount > 0 then
    begin
      Pdf.ActivateProtection := False;   // hapus enkripsi saat menyimpan
      Pdf.SaveLoadedDocument('plain.pdf');
    end;
  finally
    Pdf.Free;
  end;
end;

Jalur itu mem-parsing seluruh dokumen ke dalam memori, yang baik-baik saja untuk file biasa namun boros untuk file yang sangat besar. Ketika input mencapai ratusan megabyte, DecryptFile adalah opsi yang lebih murah: ia mendekripsi selama proses penyalinan pada level file, mengambil jalur penulisan-ulang AES-256 langsung yang melewati pembangunan pohon objek lengkap kapan pun input mengizinkannya. Ini adalah bagian dari Direct File API yang dibahas di artikel pendamping tentang pemrosesan PDF besar dari Delphi

Batasan yang berinteraksi dengan enkripsi

Ada dua batasan yang layak diketahui sebelum, bukan sesudah, Anda merancang seputar enkripsi. Batasan pertama adalah kesesuaian arsip. ISO 19005 melarang enkripsi dalam PDF/A, sehingga workflow apa pun yang mengenkripsi dokumen sekaligus mengklaim kesesuaian PDF/A secara konstruksi saling bertentangan; HotPDF tidak akan mengizinkan Anda memiliki keduanya dalam satu file. Ketika Anda benar-benar membutuhkan keduanya, jawabannya adalah dua artifact: salinan terenkripsi untuk distribusi dan salinan terpisah tanpa enkripsi untuk arsip

Batasan kedua lebih tegas lagi. Enkripsi PDF tidak memiliki escrow dan tidak memiliki pemulihan. Kehilangan user password pada file R5 atau R6 dan pilihan Anda hanya brute force atau menyerah. Jadi perlakukan secret owner dan user sebagaimana Anda memperlakukan kredensial produksi mana pun. Generate secret tersebut, simpan dalam vault, rotasi secara terjadwal. Satu hal yang tidak boleh dilakukan adalah hard-code sebagai konstanta dalam sebuah unit, di mana secret itu langsung ikut masuk ke version control dan bersemayam selamanya di working copy setiap developer

Ada satu refleks terakhir yang layak dibangun. Mengubah proteksi pada file yang bukan Anda buat menggunakan mesin yang sama dengan dekripsi, bukan fitur terpisah: muat file itu dengan passwordnya melalui LoadFromFile, edit ProtectOptions atau password-nya langsung di tempat, lalu tulis kembali dengan SaveLoadedDocument. Jika Anda bisa mendekripsi sebuah file, Anda juga bisa mengatur ulang izinnya, dan kodenya terlihat hampir identik dengan contoh di atas

Property proteksi yang ditunjukkan di sini merupakan bagian dari HotPDF Delphi Component standar untuk Delphi dan C++Builder; halaman produk memuat referensi enkripsi lengkap, termasuk enumerasi izin secara menyeluruh