🐽 🤽🏽 📢 DPKI: Mengatasi Kerugian PKI Terpusat oleh Cara Blockchain ✳️ 👃🏾 🚷

Sertifikat digital adalah salah satu alat bantu yang paling umum dikenal yang membantu melindungi data di seluruh jaringan publik. Namun, kelemahan utama dari teknologi ini juga umum dikenal: pengguna dipaksa untuk secara implisit mempercayai otoritas sertifikasi yang mengeluarkan sertifikat digital. Andrey Chmora, Direktur Teknologi dan Inovasi di ENCRY, menyarankan pendekatan baru untuk membangun Infrastruktur Kunci Publik (PKI) untuk menghilangkan kerugian yang ada dengan menggunakan teknologi ledger leded (blockchain).
Mari kita mulai dengan dasar-dasarnya.

Jika Anda sudah mengetahui dasar-dasar infrastruktur kunci publik yang ada dan kelemahan utamanya, silakan gulir ke bawah ke deskripsi tentang apa yang kami sarankan untuk diubah.

Apa itu tanda tangan digital dan sertifikat digital?

Interaksi melalui Internet selalu termasuk pertukaran data. Dan dengan demikian kita semua tertarik untuk menjaga keamanan data selama pertukaran tersebut. Tetapi apakah keamanan itu? Layanan keselamatan yang paling populer adalah kerahasiaan, integritas, dan keaslian. Hari ini, mereka didasarkan pada kriptografi asimetris, yang juga disebut kriptografi kunci publik.

Pertama-tama, metode ini mensyaratkan bahwa entitas interaksi harus memiliki dua pasangan kunci khusus: publik dan pribadi. Pasangan kunci ini menyediakan fitur keselamatan yang disebutkan di atas.

Tetapi bagaimana cara mencapai pertukaran informasi pribadi?

Gambar 1. Transmisi terenkripsi menggunakan kriptografi kunci publik

Sebelum mengirim data apa pun, pengirim mengenkripsi (mengubah secara kriptografis) data publik menggunakan kunci publik penerima, dan kemudian penerima mendekripsi data yang dienkripsi menggunakan pasangan kunci pribadi.

Bagaimana cara mencapai integritas dan keaslian informasi yang dikirim? Masalah ini dapat diselesaikan dengan menggunakan mekanisme lain.

Gambar 2. Penandatanganan / verifikasi digital

Meskipun data publik tidak dienkripsi, ini berisi nilai fungsi hash kriptografis, yaitu gambar "terkompresi" terenkripsi dari urutan data input. Hasil hashing semacam itu disebut "intisari" dan dienkripsi menggunakan kunci pribadi pengirim ("autentikator"). Hasil enkripsi intisari adalah tanda tangan digital, yang dikirim ke penerima ("verifikasi") bersama dengan teks yang tidak dienkripsi. Penerima mendekripsi tanda tangan digital menggunakan kunci publik autentikator dan kemudian membandingkannya dengan nilai fungsi hash kriptografis yang dihitung oleh verifikasi berdasarkan data publik yang diperoleh. Jika mereka cocok, maka data yang diterima sepenuhnya otentik, integral dan bebas dari modifikasi apa pun yang mungkin bisa dilakukan oleh penyerang.

Sebagian besar sumber daya yang memproses data pribadi dan informasi pembayaran (seperti bank, perusahaan asuransi, maskapai penerbangan, dan sistem pembayaran bersama dengan layanan pajak dan portal pemerintah lainnya) banyak menggunakan kriptografi asimetris.

Bagaimana sertifikat digital dapat membantu di sini? Sederhana saja. Kedua proses termasuk kunci publik yang memainkan peran yang sangat penting dan oleh karena itu kita harus selalu memeriksa bahwa itu milik pengirim (atau ke autentikator ketika kita perlu memverifikasi tanda tangan) atau penerima daripada penyerang. Dan di sinilah sertifikat digital dapat membantu memastikan keaslian dan integritas kunci publik.

Catatan: Keaslian dan integritas kunci publik diverifikasi dengan cara yang persis sama dengan data publik, yaitu menggunakan tanda tangan digital (DS).

Siapa yang menerbitkan sertifikat digital?

Sertifikat digital dikeluarkan dan dikelola oleh Otoritas Sertifikasi (CA) yang tepercaya. Entitas yang mengajukan permintaan meminta CA untuk menerbitkan sertifikat, mendaftar di Pusat Registrasi (RC) dan kemudian menerima sertifikatnya di CA. CA menjamin bahwa kunci publik dari sertifikat milik entitas yang dikeluarkannya.

Jika Anda tidak memverifikasi keaslian kunci publik, maka penyerang akan dapat mengganti kunci yang ditransfer / disimpan dengan kunci mereka sendiri. Begitu kunci telah diganti, penyerang akan dapat mendekripsi segala sesuatu yang ditransfer pengirim ke penerima, atau bahkan memodifikasi data publik atas kebijakan mereka.

Sertifikat digital selalu digunakan bersama dengan kriptografi asimetris. Salah satu sertifikat digital paling populer adalah sertifikat SSL untuk komunikasi aman melalui HTTPS. Sertifikat SSL dikeluarkan oleh ratusan perusahaan di berbagai yurisdiksi. Pangsa pasar inti didistribusikan di antara lima hingga sepuluh otoritas sertifikasi tepercaya terbesar: IdenTrust, Comodo, GoDaddy, GlobalSign, DigiCert, CERTUM, Actalis, Secom, dan Trustwave.

CA dan RC adalah komponen PKI yang juga meliputi:

Kamus Umum: Database publik yang menyediakan penyimpanan andal untuk sertifikat digital
Daftar Sertifikat yang Dicabut: Database publik yang menyediakan penyimpanan yang andal untuk sertifikat digital kunci publik yang dicabut (mis. Karena kunci privat yang dikompromikan)
Entitas infrastruktur dapat mengakses database ini sendiri atau menggunakan Protokol Status Sertifikasi Online (OCSP) yang menyederhanakan proses verifikasi.
Pengguna Sertifikat: entitas PKI yang dilayani sesuai dengan perjanjian pengguna dengan CA dan memverifikasi tanda tangan digital dan / atau mengenkripsi data berdasarkan kunci publik dari sertifikat
Pelanggan: Entitas PKI yang dilayani oleh CA, memegang kunci pribadi dan memasangkan kunci publik dari sertifikat, dan telah menyimpulkan perjanjian pelanggan dengan CA. Pelanggan juga dapat menjadi pengguna sertifikat.

Dengan demikian, entitas tepercaya dari infrastruktur kunci publik, termasuk CA, RC, dan Kamus Umum, bertanggung jawab untuk:

Verifikasi entitas yang mengajukan permintaan
Pembuatan profil sertifikat kunci publik
Masalah sertifikat kunci publik untuk entitas yang diautentikasi membuat permintaan
Perubahan status sertifikat kunci publik
Penyediaan informasi tentang status saat ini dari sertifikat kunci publik.

Apa kerugian PKI?

Kerugian mendasar PKI adalah bergantung pada entitas tepercaya. Pengguna dipaksa untuk mempercayai CA dan RC secara membabi buta. Namun, kepercayaan buta semacam itu berbahaya.

Selama sepuluh tahun terakhir, kerentanan infrastruktur menyebabkan beberapa skandal besar.

Pada 2010, malware Stuxnet yang ditandatangani menggunakan sertifikat digital curian dari RealTek dan JMicron mulai menyebar di Internet.

Pada 2017, Google menuduh Symantec menerbitkan sejumlah besar sertifikat palsu. Pada saat itu, Symantec adalah salah satu CA terbesar dengan jumlah sertifikat yang dikeluarkan. Sejak versi 70 Google Chrome, Google telah menghentikan dukungan untuk semua sertifikat yang dikeluarkan oleh perusahaan ini dan afiliasinya GeoTrust dan Thawte sebelum 1 Desember 2017.

CA ini terganggu dan, akibatnya, CA itu sendiri bersama dengan pengguna dan pelanggan terkena dampak. Selain itu, kepercayaan terhadap infrastruktur juga terpengaruh. Selain itu, sertifikat digital mungkin dilarang karena konflik politik dan karenanya berdampak pada banyak sumber daya. Ini sebabnya pada tahun 2016 pihak berwenang Rusia mempertimbangkan penciptaan pusat sertifikasi nasional untuk mengeluarkan sertifikat SSL untuk situs web Runet. Dalam situasi saat ini, portal pemerintah Rusia menggunakan sertifikat digital yang dikeluarkan oleh perusahaan AS Comodo atau Thawte (anak perusahaan Symantec).

Masih ada masalah lain: bagaimana cara mengotentikasi pengguna pada awalnya? Bagaimana cara mengidentifikasi pengguna anonim yang telah meminta sertifikat digital dari CA? Saat ini, sering dibuat sewenang-wenang tergantung pada kemampuan infrastruktur. Beberapa informasi diambil dari basis data publik (misalnya tentang badan hukum yang meminta sertifikat) atau dari bank dan kantor pos tempat individu dapat diidentifikasi dengan kartu identitas dan dokumen lainnya.

Peniruan berdasarkan kredensial palsu adalah salah satu masalah mendasar. Dan, sayangnya, tidak ada solusi lengkap dari masalah ini bahkan mungkin ada karena aspek informasi dan teoritis: tanpa informasi yang dapat diandalkan, tidak mungkin untuk memverifikasi keaslian suatu entitas. Sebagai aturan, proses verifikasi memerlukan seperangkat dokumen yang membuktikan identitas entitas yang mengajukan permintaan. Meskipun ada banyak metode verifikasi, tidak ada satupun yang dapat menjamin keaslian dokumen. Dengan demikian, keaslian entitas yang membuat permintaan juga tidak dapat diidentifikasi dengan pasti.

Bagaimana cara menghilangkan kerugian ini?

Karena masalah PKI saat ini terutama disebabkan oleh sentralisasi, jelas bahwa desentralisasi dapat membantu menghilangkan setidaknya beberapa dari mereka.

Desentralisasi tidak bergantung pada entitas tepercaya, karena penciptaan Infrastruktur Kunci Publik Terdesentralisasi (DPKI) akan membuat CA dan RC tidak perlu. Mari kita menolak konsep sertifikat digital dan sebagai gantinya menggunakan buku besar yang didistribusikan untuk menyimpan informasi tentang kunci publik. Dalam kasus kami, buku besar adalah database linier yang terdiri dari catatan individual (blok) dan terhubung menggunakan teknologi blockchain. Mari kita ganti istilah "sertifikat digital" dengan istilah "pemberitahuan".

Beginilah tanda terima, verifikasi, dan pencabutan pemberitahuan di DPKI yang diusulkan:

Setiap entitas yang mengajukan permintaan mengajukan pemberitahuan sendiri dengan mengisi formulir pendaftaran, dan kemudian membuat transaksi yang akan disimpan dalam kumpulan khusus.
Informasi tentang kunci publik bersama dengan rincian pemilik dan metadata lainnya disimpan dalam buku besar yang didistribusikan daripada dalam sertifikat digital yang dikeluarkan oleh CA di PKI terpusat.
Entitas yang mengajukan permintaan kemudian diautentikasi oleh upaya bersama komunitas pengguna DPKI dan bukan oleh RC.
Hanya pemilik pemberitahuan tersebut yang dapat mengubah status kunci publik.
Semua orang dapat mengakses buku besar yang didistribusikan dan memeriksa status kunci publik saat ini.

Catatan: Sekilas, otentikasi entitas yang membuat permintaan mungkin tampak tidak dapat diandalkan. Namun, penting untuk diingat bahwa saat ini semua pengguna layanan digital meninggalkan jejak digital yang terus tumbuh. Alat yang tersedia untuk umum meliputi basis data digital badan hukum, peta, gambar teritern digital, media sosial, dan banyak lagi. Mereka sudah berhasil digunakan dalam penyelidikan oleh wartawan dan lembaga penegak hukum. Salah satu contoh khas termasuk penyelidikan Bellingcat dan kelompok gabungan JIT, yang menyelidiki kecelakaan pesawat Boeing Malaysia.

Jadi, bagaimana infrastruktur kunci publik terdesentralisasi bekerja dalam praktik? Mari selami teknologi yang telah kami patenkan pada tahun 2018 dan pertimbangkan keahlian terbaik kami.

Misalkan ada seseorang yang memiliki satu set kunci publik, di mana setiap kunci adalah semacam transaksi yang disimpan dalam buku besar. Bagaimana cara memverifikasi bahwa semua kunci ini benar-benar milik pemilik yang diberikan tanpa CA? Untuk menyelesaikan tugas ini, kita dapat membuat transaksi nol untuk menyimpan informasi tentang pemilik dan e-wallet mereka (dari mana biaya komisi untuk menambahkan transaksi ke buku besar didebet). Transaksi nol adalah semacam "jangkar" untuk menghubungkan transaksi berikutnya bersama dengan data tentang kunci publik. Setiap transaksi jenis ini berisi struktur data khusus yang disebut "notifikasi".

Pemberitahuan adalah kumpulan data terstruktur bidang fungsional yang menyimpan informasi tentang kunci publik pemilik dan menjamin persistensi kunci ini dengan menambahkannya ke salah satu catatan terkait dalam buku besar yang didistribusikan.

Pertanyaan jelas berikutnya adalah bagaimana membentuk transaksi nol? Transaksi nol, sama seperti semua transaksi berikutnya, adalah agregasi dari enam bidang data. Untuk membentuk transaksi nol, kami menggunakan pasangan kunci publik / pribadi untuk e-wallet. Pasangan kunci publik / pribadi ini dibuat ketika pengguna membuat dompet mereka dari mana biaya komisi untuk menambahkan transaksi nol ke buku besar dan untuk operasi selanjutnya dengan pemberitahuan akan didebet.

Gambar 3. Membuat transaksi nol

Gambar 3 menunjukkan bagaimana intisari kunci publik e-wallet dibentuk menggunakan fungsi hash SHA256 dan kemudian fungsi hash RIPEMD160. Di sini, RIPEMD160 bertanggung jawab untuk merepresentasikan data dengan ukuran digest hingga 160 bit. Ini sangat penting, karena buku besar adalah database mahal. Kunci publik itu sendiri termasuk dalam bidang kelima. Bidang pertama berisi data yang menautkan transaksi yang diberikan dengan yang sebelumnya. Dalam transaksi nol, tidak seperti semua transaksi lainnya, bidang ini kosong. Kolom kedua berisi data untuk verifikasi konektivitas transaksi. Demi singkatnya, kami akan merujuk data di bidang pertama dan kedua masing-masing sebagai "bind" dan "verifikasi".

Gambar 4. Pengikatan dan verifikasi transaksi

Data dalam bidang ini dapat dibentuk menggunakan hashing berulang seperti yang ditunjukkan pada Gambar 4 di atas untuk mengikat transaksi kedua dan ketiga.
Data dalam lima bidang pertama dikonfirmasi dengan DS yang dihasilkan menggunakan kunci pribadi e-wallet. Dan itu saja - transaksi sekarang dapat ditambahkan ke kumpulan dan kemudian, setelah verifikasi berhasil (seperti yang ditunjukkan pada Gambar 5 ), ke buku besar.

Gambar 5. Verifikasi transaksi nol

Sekarang transaksi ini dapat digunakan untuk "menghubungkan" transaksi selanjutnya. Mari kita lihat Gambar 6 untuk melihat bagaimana semua transaksi non-nol terbentuk.

Gambar 6. Membuat transaksi non-null

Hal pertama yang Anda perhatikan adalah banyak pasangan kunci publik / pribadi. Selain pasangan kunci publik / pribadi e-wallet yang sudah akrab, kami juga menggunakan pasangan kunci biasa dan layanan.

Kunci publik biasa adalah bagian terpenting di sini. Kunci ini digunakan dalam berbagai prosedur dan proses di dunia sekitarnya (seperti perbankan dan transaksi lainnya, aliran dokumen, dll.). Misalnya, kunci pribadi dari pasangan kunci publik / pribadi biasa dapat digunakan untuk pembuatan DS untuk berbagai dokumen, seperti pesanan pembayaran, sementara kunci publik dapat digunakan untuk verifikasi DS dengan pelaksanaan selanjutnya dari ini. pesanan.

Pasangan kunci publik / pribadi layanan dikeluarkan untuk entitas DPKI yang terdaftar. Nama pasangan kunci publik / pribadi ini dengan jelas mencerminkan tujuannya. Perhatikan bahwa kunci layanan tidak digunakan untuk pembangkitan / verifikasi transaksi nol.

Supaya jelas, mari kita perbaiki tujuan dari kunci-kunci ini:

Kunci E-wallet digunakan untuk menghasilkan dan / atau memverifikasi transaksi null dan non-null. Kunci pribadi e-wallet hanya diketahui oleh pemilik e-wallet yang juga memiliki seperangkat kunci publik biasa.
Tujuan dari kunci publik biasa adalah sama dengan kunci publik dimana sertifikat dalam PKI terpusat dikeluarkan.
Pasangan kunci publik / swasta milik DPKI. Kunci pribadi dikeluarkan untuk entitas terdaftar dan digunakan untuk membuat DS dari semua transaksi non-nol. Kunci publik digunakan untuk verifikasi DS untuk transaksi sebelum menambahkannya ke buku besar.

Jadi, kami memiliki dua kelompok kunci. Grup pertama mencakup kunci layanan dan kunci e-wallet yang hanya memenuhi syarat dalam DPKI. Grup kedua termasuk kunci biasa yang dapat digunakan untuk berbagai keperluan tergantung pada bidang aplikasi yang diberikan. Pada saat yang sama, DPKI memastikan integritas dan keaslian kunci publik biasa.

Catatan: Pasangan kunci publik / pribadi layanan dapat diungkapkan ke berbagai entitas DPKI. Dalam kasus tertentu, pasangan mungkin sama untuk semua entitas. Inilah sebabnya mengapa membentuk tanda tangan untuk setiap transaksi non-null membutuhkan dua kunci pribadi, salah satunya adalah kunci e-wallet: kunci ini hanya diketahui oleh pemilik e-wallet yang juga memiliki seperangkat kunci publik biasa. Semua kunci ini memiliki tujuan tertentu. Sebagai contoh, kita selalu dapat membuktikan bahwa transaksi tertentu dimasukkan dalam buku besar oleh entitas DPKI terdaftar, karena tanda tangan dibentuk menggunakan kunci pribadi layanan juga. Selain itu, ini mencegah setiap serangan DOS dan kegiatan penipuan lainnya, karena pemilik membayar untuk setiap transaksi.

Semua transaksi yang mengikuti transaksi nol dibentuk sama: kunci publik (dari pasangan kunci biasa, bukan kunci e-wallet seperti untuk transaksi nol) diproses menggunakan dua fungsi hash: SHA256 dan RIPEMD160. Ini adalah bagaimana data di bidang ketiga terbentuk. Bidang keempat berisi informasi tambahan (mis. Informasi tentang status saat ini, periode validitas, cap waktu, ID algoritma kriptografi, dll.). Bidang kelima berisi kunci publik dari pasangan kunci publik / pribadi layanan. Kunci ini direplikasi, karena akan digunakan untuk verifikasi DS. Mari kita buktikan bahwa pendekatan seperti itu perlu.

Setiap transaksi termasuk dalam kumpulan dan disimpan di sana sampai diproses. Namun, menjaga transaksi di kolam berisiko, karena data transaksi dapat dipalsukan. Pemilik mengotentikasi data transaksi menggunakan DS. Kunci publik untuk verifikasi DS ini secara eksplisit ditentukan dalam salah satu bidang transaksi dan kemudian dimasukkan dalam buku besar. Transaksi diproses dengan cara yang memungkinkan penyerang untuk memodifikasi data atas kebijakan mereka sendiri, memverifikasinya dengan kunci pribadi sendiri dan kemudian menentukan kunci publik yang sesuai untuk verifikasi DS langsung dalam transaksi. Jika keaslian dan integritas dipastikan hanya menggunakan DS, pemalsuan semacam itu mungkin tetap tidak diperhatikan. Namun, memperluas DS dengan mekanisme tambahan yang menyediakan pengarsipan dan kegigihan informasi yang disimpan akan membantu mendeteksi pemalsuan tersebut. Yang perlu kita lakukan adalah memasukkan kunci publik asli pemilik ke dalam buku besar. Mari kita lihat cara kerjanya.

Misalkan penyerang sedang mencoba untuk memalsukan data transaksi. Dalam hal kunci dan DS, opsi berikut dimungkinkan:

Penyerang menempatkan kunci publik mereka sendiri dalam transaksi sambil menjaga DS pemiliknya tidak berubah.
Penyerang membentuk DS baru menggunakan kunci pribadi mereka sendiri sambil menjaga kunci publik pemiliknya tidak berubah.
Penyerang membentuk DS baru menggunakan kunci pribadi mereka sendiri dan menempatkan kunci publik yang sesuai dalam transaksi.

Jelas bahwa opsi 1 dan 2 tidak berguna, karena verifikasi DS akan selalu mendeteksi pemalsuan tersebut. Satu-satunya opsi yang masuk akal adalah opsi 3: jika penyerang membuat DS menggunakan kunci pribadi mereka sendiri, maka mereka terpaksa menyimpan kunci publik yang sesuai dalam transaksi, dan kunci ini akan berbeda dari kunci publik pemilik. Ini satu-satunya cara bagi penyerang untuk menegakkan data palsu mereka.

Misalkan pemilik memiliki pasangan kunci publik / pribadi yang diperbaiki. Misalkan data diautentikasi dengan DS menggunakan kunci pribadi dari pasangan ini sementara kunci publik ditentukan dalam transaksi. Misalkan juga bahwa kunci publik ini telah dimasukkan sebelumnya dalam buku besar dan telah sepenuhnya dikonfirmasi. Kemudian pemalsuan dapat diungkapkan oleh fakta bahwa kunci publik dalam transaksi tidak cocok dengan kunci publik dalam buku besar.

Mari kita simpulkan. Saat memproses data dari transaksi pertama pemilik, kami harus mengotentikasi kunci publik yang termasuk dalam buku besar. Untuk melakukan ini, kita dapat membaca kunci dari buku besar dan kemudian mencocokkan kunci ini dengan kunci publik asli pemilik dalam perimeter keamanan (area yang relatif kebal). Jika kunci yang ditempatkan dikonfirmasi dan sepenuhnya persisten, maka kunci dari transaksi berikutnya juga dapat dengan mudah diautentikasi dengan mencocokkannya dengan kunci dari buku besar. Dengan kata lain, kunci dari buku besar digunakan sebagai referensi. Semua transaksi lain dari pemilik akan diproses dengan cara yang sama.

Setiap transaksi diautentikasi dengan DS, dan di sini kita membutuhkan kunci privat: kunci privat layanan dan kunci privat e-wallet. Berdasarkan dua kunci privat, kami dapat memastikan tingkat keamanan target, karena kunci privat layanan dapat diketahui oleh pengguna lain, sedangkan kunci privat e-wallet hanya diketahui oleh pemilik pasangan kunci biasa. Kami menyebut tanda tangan dua kunci seperti itu sebagai "konsolidasi" DS.

Transaksi non-nol diverifikasi menggunakan dua kunci publik: kunci e-wallet dan kunci layanan. (Gambar 7)

Gambar 7. Verifikasi transaksi non-nol

Proses verifikasi terdiri dari dua langkah dasar: langkah pertama termasuk verifikasi intisari kunci publik e-wallet sementara langkah kedua mengimplementasikan verifikasi DS "konsolidasi" transaksi yang dibentuk menggunakan dua kunci privat (yaitu e- kunci dompet dan kunci layanan). Ketika DS diotentikasi, maka transaksi yang sesuai, setelah verifikasi tambahan, dimasukkan dalam buku besar.

Namun, pertanyaan berikut muncul: bagaimana cara memverifikasi apakah transaksi yang diberikan milik rantai transaksi tertentu yang dimulai dari transaksi nol? Untuk melakukan ini, kami telah memperbarui proses verifikasi dengan langkah lain - verifikasi konektivitas. Langkah ini akan membutuhkan data dari dua bidang pertama yang belum kami gunakan sampai saat ini.

Misalkan kita perlu memverifikasi apakah transaksi # 2 benar-benar diikuti oleh transaksi # 3 . Untuk melakukan ini, kita bisa menggunakan metode hashing gabungan untuk menghitung nilai fungsi hash untuk data di bidang ketiga, keempat, dan kelima. Kita dapat menggabungkan data dari bidang pertama transaksi # 3 dan nilai fungsi hash gabungan yang dihitung sebelumnya untuk data di bidang ketiga, keempat, dan kelima bidang transaksi # 2 . Semua nilai ini kemudian diproses menggunakan dua fungsi hash: SHA256 dan RIPEMD160. Jika nilai yang dihasilkan cocok dengan data di bidang kedua transaksi # 2 , maka verifikasi berhasil dilewati dan konektivitas terbukti. Ini ditunjukkan lebih detail pada gambar di bawah ini.

Gambar 8, Gambar 9. Binding verifikasi, contoh transaksi kedua dan ketiga

Secara umum, membentuk dan memasukkan notifikasi dalam buku besar terlihat seperti ini. Alur kerja pembentukan rantai pemberitahuan secara jelas ditunjukkan pada gambar berikut:

Gambar 10. Struktur dan pemrosesan transaksi

Dalam artikel ini, kami tidak akan membahas lebih dalam dan kembali ke pembahasan konsep infrastruktur terdesentralisasi untuk kunci publik.

Jadi, karena entitas yang mengajukan permintaan mengirimkan permintaan registrasi notifikasi yang disimpan dalam buku besar daripada dalam database CA, komponen arsitektur inti dari DPKI adalah sebagai berikut:

Buku Besar Pemberitahuan Valid (LVN)
Buku Besar Notifikasi Penarikan (LWN)
Buku Besar Pemberitahuan Ditangguhkan (LSN).

Informasi tentang kunci publik disimpan dalam LVN / LWN / LSN sebagai nilai fungsi hash. Perhatikan juga bahwa itu bisa berupa buku besar yang berbeda atau rantai yang berbeda atau bahkan rantai tunggal sebagai bagian dari buku besar tunggal, ketika informasi tentang status kunci publik biasa (penarikan, penskorsan, dll.) Ditambahkan ke bidang keempat dari struktur data sebagai nilai kode yang sesuai. Ada banyak opsi untuk implementasi arsitektur DPKI tergantung pada berbagai kriteria optimisasi, seperti biaya untuk penyimpanan jangka panjang kunci publik dalam memori, dll.

Dengan demikian, DPKI dapat berubah menjadi kompleksitas arsitektur yang sama atau bahkan lebih rendah dibandingkan dengan solusi terpusat.

Jadi, pertanyaan utama di sini adalah buku besar mana yang lebih cocok untuk menerapkan teknologi ini?

Persyaratan inti untuk buku besar adalah untuk dapat melakukan transaksi dalam jenis apa pun. Contoh buku besar yang paling terkenal adalah Bitcoin. Namun, menerapkan teknologi di atas untuk Bitcoin mungkin menghadapi kesulitan tertentu: keterbatasan bahasa scripting yang ada, kurangnya mekanisme yang diperlukan untuk memproses dataset sewenang-wenang dan metode untuk menghasilkan transaksi jenis sewenang-wenang, dan sebagainya.

Kami di ENCRY mencoba untuk memecahkan masalah di atas dan mengembangkan buku besar, yang, menurut pendapat kami, menampilkan beberapa keuntungan penting:

Mendukung beberapa jenis transaksi: dalam buku besar ini, Anda dapat bertukar aset (mis. Melakukan transaksi keuangan) dan membentuk transaksi dari struktur yang arbitrer
Pengembang dipersilakan untuk menggunakan bahasa pemrograman eksklusif PrismLang yang sangat fleksibel dalam menyelesaikan berbagai masalah teknologi
Mekanisme yang diterapkan untuk memproses dataset sewenang-wenang.

Sederhananya, langkah-langkah berikut harus diselesaikan:

Entitas yang membuat permintaan mendaftar di DPKI dan memperoleh e-wallet. Alamat e-wallet adalah nilai fungsi hash yang diterapkan pada kunci publik e-wallet. Kunci pribadi e-wallet hanya diketahui oleh entitas yang mengajukan permintaan
Setelah pendaftaran, entitas memperoleh akses ke kunci pribadi layanan
Entitas membentuk transaksi nol dan kemudian mengesahkan DS-nya menggunakan kunci pribadi e-wallet
Saat membentuk transaksi non-null, entitas harus mengotentikasi DS-nya menggunakan dua kunci pribadi: kunci e-wallet dan kunci layanan
Entitas mengirimkan transaksi ke pool
Node jaringan ENCRY membaca transaksi dari pool dan kemudian memverifikasi DS transaksi dan konektivitas
Jika DS valid dan konektivitas terbukti, maka node akan menyiapkan transaksi untuk ditambahkan ke buku besar.

Di sini, buku besar berfungsi sebagai basis data terdistribusi yang menyimpan informasi tentang pemberitahuan yang valid, ditarik, dan ditangguhkan.

Tentu saja, desentralisasi bukanlah solusi satu ukuran untuk semua. Masalah inti dengan otentikasi pengguna utama masih berlanjut: sementara entitas yang membuat permintaan saat ini diverifikasi oleh CA, DPKI mengusulkan untuk mendelegasikan verifikasi ini kepada anggota masyarakat dan memotivasi mereka secara finansial. Teknologi verifikasi berdasarkan sumber publik umumnya dikenal. Efisiensi verifikasi semacam itu juga telah terbukti dalam praktiknya: beberapa investigasi tingkat tinggi yang dilakukan oleh Bellingcat adalah contoh yang baik untuk hal ini.

Tetapi secara umum, kami cukup yakin bahwa DPKI mampu menghilangkan banyak, jika tidak semua, kerugian PKI yang tersentralisasi.

Jangan ragu untuk berlangganan blog kami di Habr , di mana kami akan membahas penelitian dan pengembangan lebih lanjut, dan ikuti Twitter kami untuk terus mengikuti berita tentang proyek ENCRY.

DPKI: Mengatasi Kerugian PKI Terpusat oleh Cara Blockchain

More articles: