OpenSSL: CLI Introduction - Revision history

Onnowpurbo: /* openssl.cnf: let’s configure a few things */

2017-06-07T23:11:12Z

openssl.cnf: let’s configure a few things

Onnowpurbo: /* Creation of a user certificate */

2017-06-07T23:10:39Z

Creation of a user certificate

Onnowpurbo: /* 4.2 My first PKI with OpenSSL */

2017-06-07T23:08:15Z

4.2 My first PKI with OpenSSL

Show changes

Onnowpurbo: /* 4.1 What is a PKI? (in short) */

2017-06-07T22:57:47Z

4.1 What is a PKI? (in short)

Onnowpurbo: /* Digital signature */

2017-06-07T22:48:06Z

Digital signature

Onnowpurbo: /* Digital signature */

2017-06-07T22:45:33Z

Digital signature

Onnowpurbo: /* 4 Public Key Infrastructure */

2017-06-07T22:44:55Z

4 Public Key Infrastructure

Onnowpurbo: /* 3.3 Digital signatures */

2017-06-07T22:44:34Z

3.3 Digital signatures

Onnowpurbo: /* Key generation */

2017-06-07T21:32:44Z

Key generation

Show changes

Onnowpurbo: /* Public Key Cryptography */

2017-06-07T21:09:29Z

Public Key Cryptography

@@ Line 242: / Line 242: @@
   openssl.cnf
+  #
   # OpenSSL example configuration file.

@@ Line 345: / Line 345: @@
 ====Creation of a user certificate====
-Now the PKI has got its own pair of keys and certificate, let’s suppose a user wants to get a certificate from the PKI. To do so he must create a certificate request, that will contain all the information needed for the certificate (name, country, ... and the public key of the user of course). This certificate request is sent to the PKI.
+Sekarang PKI telah mendapatkan sepasang kunci dan sertifikatnya sendiri, misalkan pengguna ingin mendapatkan sertifikat dari PKI. Untuk melakukannya, dia harus membuat permintaan sertifikat, yang berisi semua informasi yang diperlukan untuk sertifikat (nama, negara, ... dan kunci publik pengguna tentu saja). Permintaan sertifikat ini dikirim ke PKI.
   openssl req -new -keyout userkey.pem -out usercert-req.pem
-Note this command will create the pair of keys and the certificate request. The pair of keys is saved in userkey.pem and the certificate request in usercert-req.pem. The PKI is ready for the next step: signing the certificate request to obtain the user’s certificate.
+Perhatikan perintah ini akan membuat sepasang kunci dan permintaan sertifikat. Sepasang kunci disimpan dalam userkey.pem dan permintaan sertifikat di usercert-req.pem. PKI siap untuk langkah selanjutnya: menandatangani permintaan sertifikat untuk mendapatkan sertifikat pengguna.
   openssl ca -in usercert-req.pem -out usercert.pem
@@ Line 383: / Line 382: @@
   Sign the certificate? [y/n]:y
-usercert.pem is the public certificate signed by the PKI. If you want to import this certificate into your browser you need to convert it in PKCS12 format:
+Usercert.pem adalah sertifikat publik yang ditandatangani oleh PKI. Jika Anda ingin mengimpor sertifikat ini ke browser anda, anda perlu mengonversinya dalam format PKCS12:
   openssl pkcs12 -export -in usercert.pem -inkey userkey.pem > usercert.p12
-Congratulations! You have created your first home-made PKI!
+Selamat! Anda berhasil membuat sendiri PKI!
 ==Referensi==
 * https://users.dcc.uchile.cl/~pcamacho/tutorial/crypto/openssl/openssl_intro.html

@@ Line 214: / Line 214: @@
 ==Public Key Infrastructure==
-===4.1  What is a PKI? (in short)===
+===What is a PKI?===
-====4.1.1  The Problem: Man in the Middle Attack====
+====The Problem: Man in the Middle Attack====
-One of the major breakthrough of public key cryptography is to solve the problem of key distribution. Secret key cryptography supposes the participants already agreed on a common secret. But how do they manage this in practice? Sending the key through an encrypted channel seems the more natural and practical solution but once again we need a common secret key to do this. With public key cryptography things are a lot simpler: if I want to send a message to Bob, I only need to find Bob’s public key (on his homepage, on a public key directory ...) encrypt the message using this key and send the result to Bob. Then Bob using his own private key can recover the plain text. However a big problem remains. What happens if a malicious person called The Ugly makes me believe that the public key he owns is in fact Bob’s one? Simply I will send an encrypted message using The Ugly’s public key thinking I’m communicating with Bob. The Ugly will receive the message, decrypt it, and will then encrypt the plaintext with Bob’s (real) public key. Bob will receive the encrypted message, will answer probably with another encrypted message using The Ugly’s public key (who once again managed to convince Bob, this public key belongs to me). Afterwards The Ugly will decrypt the message, reencrypt it with my public key, so I will really receive the Bob’s answer. Indeed I will be communicating with Bob, but without confidentiality. This attack is called “Man in the middle Attack”, where the man is of course The Ugly of our little story. So we need a mechanism to associate in a trustworthy way a public key to the identity of a person (name, identity card number ...). One of this mechanism is implemented in PGP. The idea is that every one builds his own net of trust, by having a list of trusted public keys, and by sharing these keys. The other solution is the use of a PKI.
+Salah satu terobosan utama kriptografi kunci publik adalah memecahkan masalah distribusi kunci. Kriptografi kunci rahasia mengisyaratkan para peserta sudah menyetujui sebuah rahasia umum. Tapi bagaimana mereka mengelola ini dalam praktek? Mengirim kunci melalui saluran terenkripsi tampaknya merupakan solusi yang lebih alami dan praktis namun sekali lagi kita membutuhkan kunci rahasia untuk melakukan hal ini. Dengan hal-hal kriptografi kunci publik jauh lebih mudah: jika saya ingin mengirim pesan ke Bob, saya hanya perlu menemukan kunci publik Bob (di beranda, di direktori kunci publik ...) mengenkripsi pesan menggunakan kunci ini dan mengirim hasilnya ke Bob. Kemudian Bob menggunakan kunci pribadinya dapat memulihkan menjadi teks biasa. Namun masalah besar tetap ada. Apa yang terjadi jika orang jahat bernama Ugly membuat saya percaya bahwa kunci publik yang dimilikinya sebenarnya adalah milik Bob? Cukup saya akan mengirim pesan terenkripsi menggunakan pemikiran kunci publik Ugly yang sedang saya komunikasikan dengan Bob. Ugly akan menerima pesan tersebut, mendekripsinya, dan kemudian akan mengenkripsi plaintext dengan kunci publik Bob (sebenarnya). Bob akan menerima pesan terenkripsi, akan menjawab mungkin dengan pesan terenkripsi lain menggunakan kunci publik Ugly (yang sekali lagi berhasil meyakinkan Bob, kunci publik ini adalah milik saya). Setelah itu Ugly akan mendekripsi pesannya, mengenkripsi ulang dengan kunci publik saya, jadi saya akan benar-benar menerima jawaban Bob. Memang saya akan berkomunikasi dengan Bob, tapi tanpa kerahasiaan. Serangan ini disebut "Man in the middle Attack", dimana pria itu tentu saja adalah Ugly dari cerita kecil kita. Jadi kita membutuhkan mekanisme untuk mengasosiasikan dengan cara yang dapat dipercaya sebagai kunci publik untuk identitas seseorang (nama, nomor kartu identitas ...). Salah satu mekanisme ini diterapkan di PGP. Idenya adalah setiap orang membangun jaring kepercayaannya sendiri, dengan memiliki daftar kunci publik tepercaya, dan dengan berbagi kunci ini. Solusi lainnya adalah penggunaan PKI.
-====4.1.2  A solution: Public Key Infrastructure====
+====A solution: Public Key Infrastructure====
-Public Key Infrastructure is a centralized solution to the problem of trust. The idea is to have a trusted entity (organization, corporation) that will do the job of certifying that a given public key belongs really to a given person. This person must be identified by his name, address and other useful information that may allow to know who this person is. Once this work his done, the PKI emits a public certificate for this person. This certificate contains between others:
+Public Key Infrastructure adalah solusi terpusat untuk masalah kepercayaan. Idenya adalah memiliki entitas terpercaya (organisasi, perusahaan) yang akan melakukan pekerjaan untuk memastikan bahwa kunci publik tertentu dimiliki oleh orang tertentu. Orang ini harus diidentifikasi dengan nama, alamat dan informasi bermanfaat lainnya yang memungkinkan untuk mengetahui siapa orang ini. Begitu pekerjaan ini selesai, PKI mengeluarkan sertifikat publik untuk orang ini. Sertifikat ini berisi antara yang lain:
-    All the information needed to identify this person (name, birth date,...).
+* Informasi yang dibutuhkan untuk mengidentifikasi seseorang (nama, tanggal lahir,...).
-    The public key of this person.
+* Public key orang tersebut
-    The date of creation of the certificate.
+* Tanggal pembuatan Certificate.
-    The date of revocation of the certificate (a certificate is valid during 1 or 3 years in practice).
+* Tanggal Revocation (pencabutan) Certificate (dalam prakteknya sebuah certificate valid untuk 1-3 tahun saja).
-    The digital signature of all this previous information emitted by the PKI.
+* Tanda tangan digital dari semua informasi yang diterbitkan oleh PKI
-So now, if I want to send a private message to Bob, I can ask for his certificate. When I received the certificate, I must check the signature of the PKI who emitted it and for the date of revocation. If verifications pass then I can safely use the public key of the certificate to communicate with Bob. Indeed, in practice the way a PKI works is much more complicated. For example sometimes a certificate may be revocated before the date of end of validity has been reached. So a kind of list of revocated certificated has to be maintained and accessed every time you want to use a certificate. The problem of certificate revocation is really difficult in practice.
+Jadi sekarang, jika saya ingin mengirim pesan pribadi kepada Bob, saya dapat meminta surat keterangannya. Ketika saya menerima sertifikat tersebut, saya harus memeriksa tanda tangan PKI yang mengeluarkannya dan untuk tanggal pencabutan. Jika verifikasi lulus, saya dapat dengan aman menggunakan kunci publik sertifikat untuk berkomunikasi dengan Bob. Memang, dalam praktiknya cara kerja PKI jauh lebih rumit. Misalnya terkadang sertifikat dapat dibatalkan sebelum tanggal akhir masa berlaku telah tercapai. Jadi semacam daftar sertifikat yang telah dibatalkan harus dipelihara dan diakses setiap kali Anda ingin menggunakan sertifikat. Masalah pembatalan sertifikat sangat sulit dilakukan.
 ===4.2  My first PKI with OpenSSL===

@@ Line 210: / Line 210: @@
 Dimana,
-* -pubin is used like before when the key is the public one, which is natural as we are verifying a signature.To complete the verification, one needs to compute the digest of the input file and to compare it to the digest obtained in the verification of the digital signature.
+* -pubin dipakai jika key yang digunakan adalah public key, ini biasa digunakan untuk memverifikasi signature. Untuk menyelesaikan proses verifikasi, kita perlu menghitung digest dari input file dan membandingkannya dengan digest yang di peroleh dari verifikasi digital signature.
 ==Public Key Infrastructure==

← Older revision		Revision as of 22:45, 7 June 2017
Line 187:		Line 187:


−	==Digital signature==	+	===Digital signature===

	Langkah selanjutnya adalah membuat tanda tangan digital dan untuk memverifikasinya. Tidak terlalu efisien untuk menandatangani file besar dengan menggunakan algoritma kunci publik secara langsung. Itulah sebabnya pertama-tama kami menghitung intisari informasi yang akan ditandatangani. Perhatikan bahwa dalam praktiknya ada sedikit hal yang lebih kompleks. Keamanan yang diberikan oleh skema ini (hashing dan kemudian masuk langsung menggunakan RSA) tidak sama (kurang sebenarnya) daripada langsung menandatangani keseluruhan dokumen dengan algoritma RSA. Skema yang digunakan dalam aplikasi real disebut RSA-PSS yang efisien dan terbukti menjaga tingkat keamanan terbaik		Langkah selanjutnya adalah membuat tanda tangan digital dan untuk memverifikasinya. Tidak terlalu efisien untuk menandatangani file besar dengan menggunakan algoritma kunci publik secara langsung. Itulah sebabnya pertama-tama kami menghitung intisari informasi yang akan ditandatangani. Perhatikan bahwa dalam praktiknya ada sedikit hal yang lebih kompleks. Keamanan yang diberikan oleh skema ini (hashing dan kemudian masuk langsung menggunakan RSA) tidak sama (kurang sebenarnya) daripada langsung menandatangani keseluruhan dokumen dengan algoritma RSA. Skema yang digunakan dalam aplikasi real disebut RSA-PSS yang efisien dan terbukti menjaga tingkat keamanan terbaik

@@ Line 187: / Line 187: @@
-==3.3  Digital signatures==
+==Digital signature==
   openssl dgst -<hash_algorithm> -out <digest> <input_file>
-Where:
+Dimana,
-    hash_algorithm is the hash algorithm used to compute the digest. Among the available algorithm there are: SHA-1 (option -sha1 which computes a 160 bits digests), MD5(option -md5) with 128 bits output length and RIPEMD160 (option -ripemd160) with 160 bits output length.
+* hash_algorithm - algoritma hash yang digunakan untuk menghitung digest. Ada beberapa algoritma yang tersedia, seperti: SHA-1 (opsi -sha1) dengan 160 bit digests output, MD5(opsi -md5) dengan 128 bit output dan RIPEMD160 (opsi -ripemd160) dengan 160 bit output.
-    digest is the file that contains the result of the hash application on input_file.
+* digest - file yang berisi hasil hash dari aplikasi di input_file.
-    input_file file that contains the data to be hashed.
+* input_file - berisi file yang akan di hitung hash-nya.
-This command can be used to check the hash values of some archive files like the openssl source code for example. To compute the signature of the digest:
+Perintah ini bisa digunakan untuk mengecek nilai hash dari file / arsip. Untuk menghitung tanda tangan dari ringkasannya:
   openssl rsautl -sign -in <digest> -out <signature> -inkey <key>
-To check to validity of a given signature:
+Untuk mencek validitas dari sebuah tanda tangan:
   openssl rsautl -verify -in <signature> -out <digest> \
           -inkey <key> -pubin
--pubin is used like before when the key is the public one, which is natural as we are verifying a signature.To complete the verification, one needs to compute the digest of the input file and to compare it to the digest obtained in the verification of the digital signature.
+Dimana,
 ==4  Public Key Infrastructure==

@@ Line 83: / Line 83: @@
 ==Public Key Cryptography==
-To illustrate how OpenSSL manages public key algorithms we are going to use the famous RSA algorithm. Other algorithms exist of course, but the principle remains the same.
+Berikut ini akan di gambarkan bagaimana OpenSSL melakukan manajemen untuk public key. Algoritma RSA akan digunakan. Tentunya ada juga algoritma lainnya.
 ===Key generation===
-First we need to generate a pair of public/private key. In this example we create a pair of RSA key of 1024 bits.
+Membuat pasangan public/private key. Disini pasangan kunci dibuat dengan RSA key 1024 bit,
-> openssl genrsa -out key.pem 1024
+ openssl genrsa -out key.pem 1024
   cat key.pem
-The next line allows to see the details of the RSA key pair (modulus, public and private exponent between others).
+ openssl rsa -in key.pem -text -noout
   Private-Key: (1024 bit)
-> openssl rsa -in key.pem -text -noout
+ modulus:
-Private-Key: (1024 bit)
+:bb:89:74:d9:f8:35:4e:ea:3c:e3:50:cc:c9:2a:
-modulus:
+    ...
-:bb:89:74:d9:f8:35:4e:ea:3c:e3:50:cc:c9:2a:
+e:e3:42:23:c9:4c:12:de:9f:5c:9f:10:8f:ea:5d:
-   ...
+:d9:5a:d0:63:da:92:e7:95
-e:e3:42:23:c9:4c:12:de:9f:5c:9f:10:8f:ea:5d:
+ publicExponent: 65537 (0x10001)
-:d9:5a:d0:63:da:92:e7:95
+ privateExponent:
-publicExponent: 65537 (0x10001)
+:94:df:e7:ed:69:47:18:60:86:f9:85:99:2c:50:
-privateExponent:
+    ...
-:94:df:e7:ed:69:47:18:60:86:f9:85:99:2c:50:
+:ef:b1:28:63:bb:fc:70:de:52:3a:08:69:c9:9e:
-   ...
+:d8:7e:8b:39:13:ab:24:39
-:ef:b1:28:63:bb:fc:70:de:52:3a:08:69:c9:9e:
+ prime1:
-:d8:7e:8b:39:13:ab:24:39
+:f2:18:f9:0d:62:fc:af:fb:df:10:23:d9:e4:b4:
-prime1:
+    ...
-:f2:18:f9:0d:62:fc:af:fb:df:10:23:d9:e4:b4:
+:f8:ca:9c:64:a1:42:ec:2f:4a:7f:7c:59:57:1c:
-   ...
+    be:33:09:95:d3
-:f8:ca:9c:64:a1:42:ec:2f:4a:7f:7c:59:57:1c:
+ prime2:
-   be:33:09:95:d3
+:c6:4e:66:2a:11:2c:42:fb:69:30:9a:c3:8b:57:
-prime2:
+    ...
-:c6:4e:66:2a:11:2c:42:fb:69:30:9a:c3:8b:57:
+    d0:fc:50:7d:da:8c:51:2d:02:53:5b:d1:e9:4d:cc:
-   ...
+b:7b:9a:a3:f7
-   d0:fc:50:7d:da:8c:51:2d:02:53:5b:d1:e9:4d:cc:
+ exponent1:
-b:7b:9a:a3:f7
+:be:44:6f:fd:59:f0:7c:50:96:64:81:e7:56:8f:
-exponent1:
+    ...
-:be:44:6f:fd:59:f0:7c:50:96:64:81:e7:56:8f:
+e:48:d4:2e:fd:84:c3:2d:a4:25:3b:07:d3:19:13:
-   ...
+    c4:05:b2:5d
-e:48:d4:2e:fd:84:c3:2d:a4:25:3b:07:d3:19:13:
+ exponent2:
-   c4:05:b2:5d
+:94:59:63:fe:46:58:89:47:50:da:c6:7c:50:8a:
-exponent2:
+    ...
-:94:59:63:fe:46:58:89:47:50:da:c6:7c:50:8a:
+:18:2c:12:ea:62:9b:fb:82:c8:df:60:ba:1a:b4:
-   ...
+:2f:93:70:e3
-:18:2c:12:ea:62:9b:fb:82:c8:df:60:ba:1a:b4:
+ coefficient:
-:2f:93:70:e3
+:9f:3c:71:db:ba:2a:20:5f:8a:7a:f0:99:e7:f0:
-coefficient:
+    ...
-:9f:3c:71:db:ba:2a:20:5f:8a:7a:f0:99:e7:f0:
+    c4:00:cf:b1:d7:fc:6c:bc:97:26:72:91:00:f7:ee:
-   ...
+    f5:4e:3e:39:b4
@@ Line 246: / Line 239: @@
 -pubin is used like before when the key is the public one, which is natural as we are verifying a signature.To complete the verification, one needs to compute the digest of the input file and to compare it to the digest obtained in the verification of the digital signature.
   Public Key Infrastructure