Membangun CA Production Awal (Bagian 1)

Meninjau bagian Administrasi

Sekarang kita memasuki tahapan dimana kita akan membuat CA (SubCA) pertama kita. Ini dilakukan melalui interface web admin (Superadmin):

Sebelum kita memulai konfigurasi, berikut ini adalah penjelasan singkat mengenai tampilan halaman Admin EJBCA:

• CA Functions
  Bagian ini berfungsi untuk mengkonfigurasi fungsi Certification Authority dari EJBCA.
• RA Functions
  Bagian ini berfungsi untuk mengkonfigurasi fungsi Registration Authority dari EJBCA (Pendaftaran end user).
• Supervisor Functions
  Bagian ini berfungsi untuk melihat log EJBCA dan menyetujui permintaan.
• System Functions
  Bagian ini memiliki beberapa fungsi validasi, beberapa fungsi administrasi dan konfigurasi umum.

Dalam EJBCA, fungsi dari RA (Registration Authority) adalah mengatur permintaan untuk pembuatan sertifikat baru. RA mengatur akun pengguna yang terkait dengan setiap CA dan tipe sertifikat yang boleh diminta oleh user. RA juga menjawab pertanyaan tentang sertifikat yang sudah dikeluarkan (issued), meskipun fungsi ini berbeda dari VA.

Dalam pembuatan CA ini, RA diinstal menjadi satu dengan fungsi utama CA, jadi tidak dikonfigurasi secara terpisah.

Alur Kerja Pembuatan CA

Kita asumsikan bahwa kebanyakan sertifikat yang akan dikeluarkan oleh CA kita akan menjadi standar untuk koneksi HTTPS dengan menggunakan TLS. Jadi konfigurasi berikut akan diarahkan untuk tujuan tersebut. Pada saat selesai, kita seharusnya sudah mempunyai sebuah sertifikat yang dapat diinstal pada server manapun yang menggunakan apache.

Sangat penting untuk menuliskan atau menggambarkan akur kerja pembuatan CA di EJBCA, karena kita bisa memiliki banyak CA yang berbeda untuk tujuan yang berbeda-beda. Berikut ini adalah alur yang akan kita kerjakan:

1. Membuat sebuah Sertifikat Profile  (Certificate Profile) – Mendefinisikan beberapa nilai yang akan digunakan sebagai template.
2. Membuat sebuah Profil dari Entitas Akhir (End Entity Profile) – Template juga tetapi untuk user.
3. Membuat sebuah CA (Certification Authority) – Membuat CA.

Ketika langkah-langkah tersebut selesai, kita akan membuat sebuah entitas akhir (End Entity) dan mengeluarkan sebuah sertifikat untuknya.

Kita akan membuat sebuah CA terlebih dahulu, tetapi secara khusus saya menggunakan langkah-langkah ini untuk menggambarkan beberapa konsep:

• Kita harus tahu dulu algoritma dan panjang kunci (key lengths) yang akan kita gunakan sebelum membuat CA. Kebanyakan aplikasi PKI hanya mendukung beberapa algoritma alias terbatas, itulah mengapa kita harus tahu terlebih dahulu.
• Kita juga harus tahu detail dari sertifikat (extensi) yang akan kita gunakan.

Mendefinisikan sebuah Certificate Profile dan End Entity Profile terlebih dahulu memaksa kita untuk memiliki detail ini sebelum melakukan pembuatan CA (SubCA).

Penentuan Algoritma

Memilih algoritma enkripsi sebuah kunci publik adalah sebuah “topik sensitif” untuk beberapa orang akhir-akhir ini, dengan pendapat yang biasanya mengarah kepada:

• The NSA (National Security Agency) adalah sebuah badan yang dibentuk untuk melindungi masyarakat dari aksi-aksi orang jahat.

atau

• The NSA (National Security Agency) adalah sebuah badan yang jahat yang dibentuk untuk mencuri rahasia dan menghancurkan privasi dari orang-orang baik yang ada di dunia ini.

Terlepas dimana pilihan anda akan jatuh, apakah menganggap NSA itu baik atau buruk, pilihan kita untuk algoritma enkripsi kunci publik terbatas antara RSA dan Eliptic Curve DSA. Dengan RSA, Variabelnya hanyalah panjang dari modulus kunci kita, dengan opsi saat ini yaitu 2048, 4096 dan 8192 bits.

Dengan ECDSA, kita memiliki banyak varian yang membingungkan untuk dipilih. Dari banyaknya varian tersebut, berikut ini adalah ringkasannya (Terima kasih untuk SECG dan Fabio Pietrosanti):

Fokus pertama kita adalah pada konvensi SECG untuk penamaan ECDSA:

• “sec” hanya menunjukkan nama spsefikasi: “Standards for Efficient Cryptography“.
• “p” atau “t” merujuk pada 2 varian dari algoritma Elliptic Curve. “p” adalah “prime“.
• Tiga nomor berikutnya merujuk pada panjang (dalam bits) dari modulus.
• “r” atau “k” merujuk pada bagian dari Curve yang digunakan oleh persamaan Elliptic – “Random” atau “Koblitz“.
• nomor terakhir adalah nomor sequence, mengacu pada varian matematika.

Dan sekarang bagian dari judul kolom pada tabel:

• SECG NAME – Nama panggilan SECG dari varian Elliptic Curve.
• SIZE – panjang field dalam bits.
• RSA EQ – Ukuran perkiraan dari sebuah modulus RSA pada kekuatan setara.
• Curve – menunjukkan apakah curve ini Koblitz atau Random.
• NIST – Nama dari standar ekuivalen NIST untuk Curve.

SECG NAME	SIZE	RSA EQ	CURVE	NIST
sect163k1	163		Koblitz	K-163
sect163r1	163		Random
sect163r2	163		Random	B-163
sect193r1	193		Random
sect193r2	193		Random
sect233k1	233		Koblitz	K-233
sect233r1	233		Random	B-233
sect239k1	239		Koblitz
sect283k1	283		Koblitz	K-283
sect283r1	283		Random	B-283
sect409k1	409		Koblitz	K-409
sect409r1	409		Random	B-409
sect571k1	571		Koblitz	K-571
sect571r1	571		Random	B-571
secp160k1	160	1024	Koblitz
secp160r1	160	1024	Random
secp160r2	160	1024	Random
secp192k1	192	1536	Koblitz
secp192r1	192	1536	Random	P-192
secp224k1	224	2048	Koblitz
secp224r1	224	2048	Random	P-224
secp256k1	256	3072	Koblitz
secp256r1	256	3072	Random	P-256
secp384r1	384	7680	Random	P-384
secp521r1	521	15360	Random	P-521

Tabel ECDSA

Mari kita bandingkan dengan lebih ketat kali ini antara Koblitz dan Random (ECC) yang setara dengan RSA (dalam bits):

Koblitz	ECC	DH/DSA/RSA
163	192	1024
283	256	3072
409	384	7680
571	521	15360

Perbandingan Koblitz, ECC dan RSA

Yang bisa diangkat dari informasi pada tabel-tabel ini adalah:

• Persamaan Elliptic Curve jauh lebih efisien dibanding persamaan RSA.
• Persamaan Elliptic Curve menggunakan Koblitz sedikit kurang efisien (sekitar 10%) dibandingkan menggunakan Random.
• Ketika memilih persamaan Elliptic Curve, adalah ide yang bagus untuk memilih sebuah varian yang didukung oleh banyak organisasi (SECG, NIST, dll) untuk tujuan kompatibilitas.

Secara singkat, kekhawatiran tertinggi didapat dari pembawaan Random Curves, dan apakah benar atau tidak mereka benar-benar “random”. Jika kalian khawatir mengenai NSA yang memiliki “backdoor” dalam Elliptic Curves, sarannya adalah menggunakan varian Koblitz seperti yang digunakan oleh Bitcoin. Namun, Curve ini akan memakan 10%  dari efisiensimu, dan algoritma yang berbasis Koblitz belum diterima secara luas oleh banyak orang seperti layaknya Random Curve.

• Pada akhirnya, tidak ada jaminan bahwa NSA bisa memecahkan enkripsi kalian terlepas dari algoritma yang kalian pilih.

Sekarang ini, dunia bergerak menuju Kriptografi Elliptic Curves. Saat EJBCA mengimplementasikan ini, ini akan menjadi algoritma terbaik untuk digunakan oleh CA dan sertifikat.

• Untuk alasan interoperabilitas, sebaiknya kita menggunakan standard de facto untuk TLS pada internet yaitu 2048-bit RSA tetapi dengan sebuah SHA-256 Key.
• Ketika kita membuat CA di EJBCA, 4096-bit RSA bisa menjadi pilihan yang baik.

Penjelasan Field-Field pada Sertifikat

Spesifikasi X.509 mengizinkan banyaknya field yang bisa disertakan dalam sertifikat. Untungnya, kebanyakan field tersebut ditolak oleh implementasi PKI

Untuk mengilustrasikan ini, berikut ada sebuah sertifikat yang digunakan oleh google untuk mengamankan Gmail dan kita akan membukanya dengan menggunakan Firefox Certificate Viewer:

Pada Firefox Viewer, informasi lengkapnya dapat dilihat pada tab “Details”:

Pada Sertifikat di atas, Google menggunakan field-field berikut:

• Version: 3
• Serial Number: 07:29:38:9A:3E:F9:9C:B1
• Certificate Signature Algorithm: SHA-1 with RSA
• Issuer: CN=Google Internet Authority G2,O=Google Inc, C=US
• Validity: Not After 7-21-2014
• Subject: (the DN) CN=mail.google.com, O=Google Inc, L=Mountain View, ST=California,C=US
• Algorithm Identifier: Elliptic Curve Public Key
• Algorithm Parameters: ANSI X9.62 elliptic curve prime256v1 (aka secp256r1, NIST P-256)
• Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication
• Certificate Subject Alt Name: DNS Name=mail.google.com
• Certificate Key Usage: Signing
• Authority Information Access:
  • CA Issuers: URI: http://pki.google.com/GIAG2.crt
  • OCSP: URI http://clients1.google.com/ocsp
• Certificate Subject Key ID: (160 bit number)
• Certificate Basic Constraints: Is not a Certificate Authority
• Certificate Authority Identifier: (160 bit number)
• Certificate Policies: 1.3.6.1.4.1.11129.2.5.1
• CRL Distribution Points: URI: http://pki.google.com/GIAG2.crl
• Certificate Signature Value: (2048-bit number)

Field-field tersebut adalah titik awal yang bagus untuk kita dapat menentukan isi dari sertifikat kita nanti.

Sangat penting untuk dicatat bahwa banyak parameter di atas dapat di-set dengan menggunakan sesuatu yang disebut “Critical Flag”.  Secara umum, pada sertifikat yang digunakan untuk TLS Web, Critical Flag hanya di-set untuk field “Basic Certificate Constraints“.

• Jangan menggunakan “Critical Flag” pada semua paremeter dalam sertifikat kita, atau sertifikat tersebut tidak akan bekerja.

Sebagia perbandingan, berikut ini adalah sertifikat untuk RootCA yang memvalidasi sertifikat GMAIL:

Root CA menggunakan field yang lebih sedikit dari sertifikat Gmail, dan menggunakan enkripsi 2048-bit RSA:

• Version: 3
• Serial Number: 02:34:56 (this is not a typo)
• Certificate Signature Algorithm: SHA-1 with RSA
• Issuer: CN=GeoTrust Global CA, O=GeoTrust, Inc.,C=US
• Validity: Not After 5/20/2022
• Subject: CN=GeoTrust Global CA,O=GeoTrust, Inc.,C=US
• Subject Public Key Algorithm: RSA Encryption
• Subject’s Public Key: (2048-bit number)
• Certificate Basic Constraints: Is a Certificate Authority, Unlimited Intermediate CAs
• Certificate Subject Key ID: (160-bit number)
• Certificate Authority Key ID: (the same 160-bit number)
• Certificate Signature Value: (2048-bit number)

Sertifikat ini akan digunakan sebagai Template untuk menjelaskan field pada Profil Awal, CA dan sertifikat.

Okay sampai di situ dulu bagian pertama, untuk bagian kedua akan dilanjut pada postingan berikutnya.

Pantau terus ya 🙂

Source: EJBCACENTOS