Bagian 3: Genesis of Ledger Recover – Menghindari Kolusi dan Kebocoran | buku besar

Selamat datang kembali di bagian ketiga dari seri blog kami Pemulihan buku besarasal usulnya! Tujuan kami adalah untuk mengeksplorasi banyak rintangan teknis yang dihadapi saat membangun layanan pemulihan benih, dan bagaimana Ledger Recover, yang disediakan oleh Coincover menyelesaikannya dengan desain dan infrastruktur yang aman.

Di bagian sebelumnya, kami telah menjelaskan bagaimana entropi dari Frase Pemulihan Rahasia dibagi menjadi beberapa bagian (atau fragmen), dan dikirim ke penyedia cadangan tepercaya, dengan tetap menjaga tingkat keamanan tertinggi. Berkat alat kriptografi modern dan perangkat keras yang aman, kami dapat melakukan pencadangan penuh terhadap sebuah seed, dengan jaminan bahwa tidak ada penyerang yang dapat memperoleh bagian mana pun selama transit.

Kami sekarang akan melanjutkan ke langkah logis berikutnya, mencadangkan saham secara fisik. Menyediakan penyimpanan yang aman adalah kuncinya dan menimbulkan pertanyaan penting yang perlu kita jawab: Bagaimana kita memastikan saham disimpan dengan aman dan tidak dapat dicuri? Bagaimana kami dapat mencegah kolusi antar penyedia cadangan untuk merekonstruksi benih Anda?

Keamanan berlapis

Untuk memastikan keamanan penyimpanan saham, salah satu pendekatan yang mungkin dilakukan adalah dengan meminta setiap penyedia menyimpan sahamnya masing-masing di lokasi yang aman, seperti brankas. Alternatifnya, Anda dapat memilih untuk menyimpannya di brankas bank – yang berbeda – sendiri. Pengaturan ini memungkinkan penyedia untuk fokus hanya pada pengamanan kunci masing-masing, sehingga lebih mudah untuk mengontrol akses dan mengurangi risiko kebocoran dari keluarga dan teman.

Melindungi diri kita dari potensi kolusi menimbulkan lebih banyak tantangan. Anda mungkin mempertimbangkan untuk membuat beberapa pembagian yang didistribusikan ke berbagai kategori teman atau penyedia penyimpanan. Anda juga dapat mengikatnya dengan kontrak. Meskipun solusi-solusi ini dapat dilaksanakan, solusi-solusi tersebut masih memerlukan tingkat kepercayaan tertentu.

Solusi alternatifnya adalah dengan mengenkripsi share sebelum dikirim ke teman Anda. Dengan begitu, meskipun mereka berkolusi, mereka tidak akan bisa menggunakan sahamnya untuk membangun kembali benih Anda. Namun inilah kelemahan dari ruang fisik: Untuk mengenkripsi saham, Anda memerlukan kunci rahasia pribadi baru. Anda pada dasarnya membuat cadangan sebuah rahasia, benih Anda, oleh memperkenalkan rahasia lain yang harus kamu lindungi dan ingat.

Kami dapat berargumentasi bahwa rahasia baru ini kurang penting dibandingkan rahasia aslinya karena hanya digunakan untuk melindungi Anda dari kolusi antar teman Anda. Penyerang yang mendapatkan akses ke kunci baru ini tidak akan bisa mencuri dana Anda secara langsung, namun jika Anda kehilangannya, Anda juga akan kehilangan akses ke seed Anda.

Bagaimana Ledger Recover melakukannya: Perangkat Keras Aman dan enkripsi berbagai tingkat

Di Ledger Recover, yang disediakan oleh Coincover, kami menggunakan properti perangkat keras aman yang kami miliki untuk menjawab pertanyaan-pertanyaan tersebut dengan cara yang paling mudah digunakan. Kami mengandalkan Elemen Aman (SE) yang terdapat dalam dompet perangkat keras Ledger Anda, serta Modul Keamanan Perangkat Keras (HSM) yang digunakan oleh masing-masing penyedia pencadangan.

Elemen Aman: Kekuatan Keamanan di Telapak Tangan Anda

Elemen Aman adalah chip khusus yang biasa digunakan di paspor, kartu kredit, dan sistem pembayaran untuk menyimpan dan memproses data sensitif dengan aman. UK dirancang khusus untuk tahan terhadap berbagai serangan seperti gangguan fisik, saluran samping, injeksi kesalahan, eksploitasi perangkat lunak, atau malware. Chip ini disertifikasi oleh laboratorium keamanan pihak ketiga melalui pengujian intensif terkait serangan tersebut.

Ledger Nano Anda mengandalkan teknologi yang terbukti dan tepercaya ini untuk menyimpan dan melindungi benih Anda. OS Ledger yang berjalan pada SE ini akan selalu meminta persetujuan fisik Anda sebelum menggunakan seed.

HSM: Mengamankan Server

Modul Keamanan Perangkat Keras (HSM) adalah kantong keamanan yang biasanya tersedia sebagai kartu plug-in atau perangkat eksternal yang terpasang langsung ke komputer atau server jaringan. Ini memanfaatkan prosesor kriptografi, memori aman, dan berbagai tindakan pencegahan anti-gangguan untuk menyimpan dan memproses rahasia dengan aman. Modul-modul ini melindungi infrastruktur penting dan digunakan oleh organisasi yang sangat sadar akan keamanan, termasuk industri perbankan, untuk mengamankan kunci rahasia dan infrastruktur mereka.

Ledger menggunakan beberapa HSM untuk berbagai kasus penggunaan, termasuk memverifikasi keaslian perangkat Ledger Nano dan Ledger Stax, dan mengaktifkan pembaruan OS yang aman melalui saluran terenkripsi dan terautentikasi.

Baik UK maupun HSM memainkan peran penting dalam meningkatkan keamanan data dalam beragam aplikasi. Mereka membantu organisasi memenuhi persyaratan peraturan untuk privasi dan keamanan data serta mengamankan manipulasi data penting.

Enkripsi benih oleh Elemen Aman

Perlindungan lapisan pertama berasal dari Secure Element (SE) itu sendiri. Sebelum membagi entropi menjadi tiga bagian, SE mengenkripsinya menggunakan kunci simetris AES 256 yang disimpan dalam Sistem Operasinya (disebut sebagai 'Kunci Entropi Entropi'). Setelah enkripsi, entropi dibagi menjadi tiga bagian yang kemudian didistribusikan ke penyedia cadangan. Tentu saja, Anda memiliki kendali atas proses ini, dan SE akan selalu meminta persetujuan eksplisit Anda sebelum memulainya, sama seperti aplikasi lain yang meminta akses ke seed.

Bahkan jika terjadi kolusi di antara penyedia cadangan yang berupaya merekonstruksi benih (skenario yang hampir tidak mungkin dilakukan oleh perlindungan kuat lainnya yang akan kita bahas nanti), upaya mereka hanya akan menghasilkan benih terenkripsi. Tanpa kunci enkripsi yang disimpan dalam Elemen Aman (SE), mereka tidak akan dapat memanfaatkan benih tersebut.

Hal penting yang perlu dipahami: Kunci Entropi Entropi ini umum untuk semua Perangkat Buku Besar, sehingga Anda dapat memulihkan benih Anda di Perangkat Buku Besar mana pun yang sah. Itu disuntikkan ke dalam Sistem Operasi selama pembaruan OS, itu sendiri merupakan operasi yang sangat aman.

Dengan memasukkan Kunci Entropi Entropi langsung ke dalam perangkat, kami menghilangkan kebutuhan pengguna untuk mengingat atau menyimpan kunci enkripsi tambahan untuk melindungi terhadap risiko kolusi (kesalahan 22 yang disebutkan di atas). Pendekatan ini memastikan peningkatan keamanan tanpa memerlukan kepercayaan tambahan pada Ledger, karena sejalan dengan tingkat keamanan yang ada yang diberikan melalui pembaruan OS.

Melindungi Kunci Enkripsi Entropi

Mengingat tingkat kekritisannya, Kunci Entropi Entropi secara eksklusif digunakan oleh Sistem Operasi perangkat selama proses pemulihan dan pencadangan Ledger Recover yang autentik. Proses ini melibatkan pembentukan saluran aman yang diautentikasi dengan beberapa HSM dari perusahaan berbeda (masing-masing penyedia cadangan). Selain itu, berbagai komponen infrastruktur lainnya, seperti deteksi aktivitas mencurigakan (misalnya, memulihkan beberapa seed pada perangkat yang sama) dan verifikasi identitas, dikelola oleh tim terpisah, yang secara drastis meningkatkan jumlah orang yang diperlukan untuk melakukan serangan kolusi yang berhasil. Kami akan menggali lebih dalam tata kelola dan pemantauan yang telah kami lakukan pada bagian ke-5 seri ini!

Demikian pula, di Ledger, tidak ada satu orang pun yang memiliki wewenang untuk melakukan peningkatan OS baru untuk perangkat tersebut. Proses ini diterapkan secara kriptografis untuk selalu memerlukan tanda tangan digital dari kuorum beberapa individu dari tim berbeda, masing-masing dengan kepentingan berbeda dalam perusahaan.

Praktek ini, dikenal sebagai pemisahan tugas, adalah langkah keamanan siber penting lainnya yang akan kita bahas lebih dalam pada bagian keamanan operasional.

Bagikan enkripsi saat istirahat untuk Penyedia Cadangan

Sekarang di sisi penyedia cadangan, kami memiliki pengaturan yang setara.

Setiap penyedia cadangan menggunakan Modul Keamanan Perangkat Keras untuk memanipulasi bagian benih mereka. Ketika HSM mereka menerima bagian dari perangkat dengan aman (dienkripsi ganda oleh Kunci Entropi Entropi dan kunci sementara saluran aman yang dijelaskan dalam postingan blog sebelumnya), Enkripsi Saluran Aman dicabut dan konsistensi berbagi diverifikasi langsung di dalam HSM.

Karena kapasitas memori yang terbatas, HSM tidak dapat menyimpan share dalam jumlah besar. Oleh karena itu, untuk tujuan penyimpanan, setiap share dienkripsi ulang menggunakan kunci enkripsi simetris AES 256, yang dikenal sebagai 'Kunci Penyimpanan Penyedia'. Lapisan enkripsi tambahan ini memungkinkan pembagian disimpan dengan aman di luar batas HSM dalam RDMS. Dengan kata lain, saham tersebut tidak akan pernah muncul di luar kantong aman tanpa skema enkripsi ganda.
Kunci Penyimpanan Penyedia dibuat di dalam HSM oleh masing-masing penyedia, dan tidak pernah meninggalkannya tidak terbuka. Itu tidak pernah dapat diakses oleh siapa pun, termasuk karyawan penyedia cadangan itu sendiri. Ini adalah praktik keamanan siber standar dari perusahaan yang menangani data yang sangat rahasia dan sangat sensitif.

Saham tersebut juga tidak pernah meninggalkan batasan HSM dengan jelas, dan selalu dienkripsi baik saat transit maupun saat disimpan.

Sekali lagi, pemisahan tugas yang ketat diberlakukan bagi individu yang memiliki kemampuan untuk memanipulasi dan mengakses HSM. Tanggung jawab yang berbeda, seperti memperbarui kode, akses fisik ke HSM, mengakses database, dan menginstal perangkat lunak pada host fisik HSM, ditugaskan kepada individu berbeda dengan hak akses terbatas. Selain itu, perangkat lunak apa pun yang berjalan di HSM harus menjalani penandatanganan digital oleh kuorum beberapa individu dari tim berbeda dan dengan beragam kepentingan dalam perusahaan.

Semua ini membuat sangat sulit – hampir tidak mungkin – bagi satu orang di perusahaan mana pun yang terlibat untuk memiliki akses terhadap saham tersebut.

HSM Menyerang Lagi: Diversifikasi basis data

Oke, kita semakin dekat dengan solusi lengkap untuk menyimpan saham kita dengan aman!

Namun bagaimana jika beberapa orang dalam dalam penyedia cadangan secara kolektif ingin mendapatkan kembali entropi individu, mengatur kolusi besar yang efektif di antara tim dan anggota kuorum dari masing-masing perusahaan?

Apakah mungkin untuk menerapkan langkah-langkah teknis yang menjadikannya sangat menantang, bahkan tidak mungkin untuk dicapai? Bisakah kita menerapkan pengamanan yang memberikan waktu yang cukup bagi orang dalam perusahaan mana pun untuk memperingatkan semua pengguna sebelum terjadi sesuatu?

Salah satu solusinya adalah dengan menggunakan apa yang dikenal sebagai “Diversifikasi Basis Data”. Sekali lagi, kami memanfaatkan kemampuan HSM kami untuk mengimplementasikannya.

Jika Anda telah mengikuti entri blog ini dari awal, kini Anda memahami bahwa pemrosesan pembagian dikelola secara eksklusif dalam batasan aman HSM, namun penyimpanan sebenarnya dari pembagian terenkripsi tersebut dilakukan di basis data backend terpisah di luar HSM.

Inilah yang akan kita lakukan: biarkan HSM menghasilkan ID database unik untuk setiap share, yang berfungsi sebagai pengidentifikasi spesifiknya dalam database backend. ID ini akan dihasilkan dengan cara yang 'diversifikasi', berasal dari rahasia yang dibuat oleh HSM itu sendiri, disimpan dengan aman dalam memori amannya sendiri, dan tidak pernah diekspos tanpa bungkusan. Oleh karena itu, backend hanya berfungsi sebagai penyimpanan eksternal, tidak dapat membaca konten basis datanya atau memutuskan pengidentifikasi entri basis datanya sendiri.

Apa artinya ini? Pengidentifikasi berbagi akan berbeda di berbagai penyedia cadangan, termasuk Ledger, Coincover, dan EscrowTech. Selain itu, karena data pengguna juga tetap terenkripsi dan terdiversifikasi, bahkan jika terjadi kolusi antara dua penyedia, hal ini tidak akan memberikan petunjuk apa pun mengenai entri basis data mana yang sesuai dengan pengguna mana atau entri mana dalam basis data penyedia lain.

Satu-satunya pendekatan yang mungkin adalah dengan memaksa semua kemungkinan kombinasi pembagian di seluruh database dari semua penyedia cadangan yang terlibat. Proses ini sangat memakan waktu, memerlukan alur pemulihan penuh yang melibatkan pemanfaatan infrastruktur penuh HSM dan perangkat Ledger yang sah untuk mendekripsi setiap kombinasi dengan persetujuan manual melalui kode PIN. Sebagaimana diharapkan, pendekatan ini memerlukan banyak waktu dan usaha.

Pengidentifikasi pengguna yang tidak terdiversifikasi tentu saja ada dalam komponen yang bertanggung jawab untuk mengatur aliran pemulihan (hanya ada di sisi Ledger). Inilah sebabnya, seperti disebutkan sebelumnya, pemisahan tugas yang ketat diberlakukan antara tim dan individu yang mengelola komponen Orkestrasi dan mereka yang mengawasi HSM dan database Penyedia Cadangan.

Aman dan nyaman, sekarang untuk membuktikan bahwa saya adalah saya

Setelah memisahkan dan membagikan Frasa Pemulihan Rahasia dengan aman, kini kami telah merancang solusi yang memastikan penyimpanan aman dari berbagai bagian. Hal ini bergantung pada perangkat keras, konstruksi kriptografi, dan pemisahan operasional yang semuanya penting untuk membangun produk yang aman. Kami kini terlindungi dari risiko di titik akhir sumber dan tujuan, serta selama transit dan penyimpanan. Kami juga telah mengurangi risiko kolusi dari individu di setiap perusahaan, atau di dalam perusahaan itu sendiri, hingga mendekati nol.

Pada titik ini, Anda mungkin bertanya-tanya tentang bagian terakhir yang hilang: Melepaskan share yang dienkripsi oleh setiap penyedia cadangan. Proses ini harus sangat dilindungi, lalu bagaimana kita memastikan bahwa pemilik sebenarnya dari benih tersebut adalah yang memulai permintaan pelepasan saham?

Sekarang saatnya memperkenalkan proses Verifikasi Identitas (atau IDV), yang merupakan bagian terakhir dari teka-teki ini. Ketika penyedia cadangan diminta untuk melepaskan bagian benihnya, ia mengharapkan untuk menerima otorisasi dari penyedia IDV yang merupakan bukti bahwa permintaan tersebut telah dimulai oleh pemilik sebenarnya dari benih tersebut.

Dengan memiliki penyedia IDV yang berbeda untuk setiap penyedia Cadangan, kami menambahkan lapisan perlindungan ekstra terhadap kolusi.

Menerapkan IDV untuk beberapa penyedia cadangan bisa jadi cukup rumit, itulah sebabnya kami akan mendedikasikan postingan blog berikutnya untuk menjelaskannya secara mendetail. Bergabunglah jika Anda ingin tahu lebih banyak!

Pierre AOUN / Yacine BADIS

Arsitek Perangkat Lunak

• Konten Bertenaga SEO & Distribusi PR. Dapatkan Amplifikasi Hari Ini.
• PlatoData.Jaringan Vertikal Generatif Ai. Berdayakan Diri Anda. Akses Di Sini.
• PlatoAiStream. Intelijen Web3. Pengetahuan Diperkuat. Akses Di Sini.
• PlatoESG. Otomotif / EV, Karbon, teknologi bersih, energi, Lingkungan Hidup, Tenaga surya, Penanganan limbah. Akses Di Sini.
• PlatoHealth. Kecerdasan Uji Coba Biotek dan Klinis. Akses Di Sini.
• ChartPrime. Tingkatkan Game Trading Anda dengan ChartPrime. Akses Di Sini.
• BlockOffset. Modernisasi Kepemilikan Offset Lingkungan. Akses Di Sini.
• Sumber: https://www.ledger.com/blog/part-3-genesis-of-ledger-recover-avoiding-collusion-and-leaks