Keamanan DDS dengan Cara Keras (ware) - SGX Bagian 3:Layanan DDS yang Diperkuat
Ini adalah Bagian 3 dalam enam -blog seri tentang topik ini. Jika Anda baru mengenal seri ini, silakan baca blog sebelumnya di sini.
Di Bagian 2 seri ini, saya membahas cara membuat titik akhir yang diperkeras menggunakan RTI Connext DDS Micro + Security, SCONE, dan Intel SGX. Meskipun menarik, kami belum memeriksa solusi praktis dengan SGX bawaan. Di Bagian 1, saya mengisyaratkan bahwa DDS + SGX lebih mungkin muncul di ruang server daripada sebagai titik akhir Industrial Internet of Things (IIoT) yang lebih tradisional. Dalam angsuran ini, kita akan melihat solusi yang lebih praktis untuk aplikasi DDS yang diperkuat SGX melalui lensa layanan DDS.
Banyak layanan DDS merupakan target utama untuk penguatan keamanan. Mereka sering berlangganan lebih banyak topik, dan dalam solusi aman DDS, oleh karena itu mereka memiliki lebih banyak akses ke kunci ephemeral. Kunci-kunci ini disimpan oleh kebutuhan dalam memori aplikasi. Dengan keterampilan dan tekad, pengguna atau penyerang yang memiliki hak istimewa dapat mengekstraknya, atau mungkin lebih efektif, dapat mengumpulkan data dari memori sistem tepat setelah perlindungan DDS dihapus – atau bahkan mengubah data sesaat sebelum perlindungan ditambahkan. Lagi pula, mengapa repot-repot dengan enkripsi ketika data sudah dalam teks biasa?
Gambar 1:Permukaan Serangan di Lingkungan DDS
Jika Anda telah mengikuti seri ini, Anda mungkin ingat bahwa di Bagian 1, saya menyajikan arsitektur di mana paket yang dilindungi DDS dapat tiba melalui kabel dan diteruskan ke ruang yang dilindungi SGX sebelum perlindungan DDS dihapus. Begitu berada di dalam aplikasi, SGX melindungi data, dan perlindungan DDS dapat dihapus. Karena CPU dapat melihat data dalam teks biasa, tidak diperlukan operasi eksotik pada data terenkripsi. Ini menawarkan keunggulan berbeda dibandingkan metode perlindungan lain seperti enkripsi homomorfik.
Desain ini memungkinkan aplikasi untuk mengambil data terenkripsi pada kabel, memindahkannya ke ruang terlindung sebelum menghapus enkripsi, mengoperasikan data dan menambahkan perlindungan kabel. Jika kita bisa membangun salah satu dari aplikasi ini, maka kita bisa membangun banyak. Selain itu, karena DDS memberikan perlindungan melalui kabel, kita dapat memiliki jaringan yang heterogen ketika aplikasi non-SGX dapat berkomunikasi dengan aplikasi SGX; beberapa dari aplikasi tersebut dapat berupa layanan DDS.
Untuk mengilustrasikannya, mari kita lihat Layanan Perutean RTI. Spesifikasi Keamanan DDS Object Management Group® (OMG®) memerlukan kode aplikasi Layanan Perutean untuk beroperasi pada data dengan jelas, meskipun hanya sebentar. Selain itu, Layanan Perutean memiliki semua kunci sementara dari setiap titik akhir tempat ia berkomunikasi. Beberapa arsitektur mengharuskan Layanan Perutean muncul di tepi jaringan, meningkatkan risiko serangan. Dengan demikian, ini adalah target bernilai tinggi untuk pengguna jahat.
Gambar 2:Layanan Perutean RTI Menyediakan Ruang Terlindungi untuk Aplikasi yang Berjalan di Lingkungan SGX
Meskipun kami belum menjelajahinya, SCONE memiliki dukungan bawaan dan transparan untuk penyimpanan file terenkripsi serta pengesahan. Dengan penyimpanan file bawaan, kami dapat memperluas fungsionalitas aplikasi kami. Dalam contoh Layanan Perutean, sekarang kita dapat menyimpan kunci pribadi yang digunakan untuk identitas dalam ruang terlindungi yang hanya tersedia untuk aplikasi; tidak ada pengguna + root yang memiliki akses ke sana.
Untuk mengambil ide lebih jauh, kita sekarang dapat menyimpan data apa pun ke disk dengan cara yang dilindungi.
Gambar 3:Layanan Perutean DDS dan RTI Dilindungi di Lingkungan SCONE
Misalnya, kami dapat menyimpan komunikasi DDS untuk pemutaran ulang resmi. SCONE mendukung komunikasi TLS asli (dan transparan) dengan wadah SCONE resmi lainnya seperti SQLite.
Dengan alat ini, kita dapat membangun infrastruktur di mana semua data dilindungi setiap saat, bahkan terhadap administrator sistem atau penyerang yang jahat. Tentu saja, sebuah aplikasi perlu mengukur dirinya dengan cara yang tepercaya sebelum dapat dipercaya untuk mengakses layanan tepercaya, termasuk toko dan koneksi jaringannya. Inilah peran layanan pengesahan.
Layanan pengesahan, singkatnya, adalah metode jarak jauh untuk memverifikasi bahwa aplikasi tidak dimodifikasi, asli dan berjalan pada CPU SGX asli. Pada dasarnya, layanan pengesahan adalah sistem yang lebih tepercaya yang memverifikasi bahwa sistem yang kurang tepercaya memiliki – dan dapat berjalan dengan aman – aplikasi tepercaya. Awalnya, layanan ini disediakan secara eksklusif oleh Intel, tetapi banyak hal berubah.
Pengesahan jarak jauh mungkin tampak seperti masalah bagi banyak sistem tertutup, terutama jika pengesahan disediakan oleh Intel. Namun, ini tidak sesulit yang dibayangkan karena pengesahan untuk aplikasi hanya perlu dilakukan sekali, dan pengesahan bertahan setelah reboot. Proses tersebut memverifikasi CPU dan aplikasi melalui instruksi ISA yang memiliki jaminan integritas kriptografi. Nilai-nilai tersebut dapat disegel ke disk dan digunakan kembali sesuai kebutuhan. Penggunaan kembali ini dapat mencakup aplikasi yang membuktikan kepada CPU bahwa itu tidak dimodifikasi, CPU yang membuktikan ke sistem jarak jauh bahwa itu asli, atau aplikasi yang membuktikan ke aplikasi lain bahwa itu tidak dimodifikasi. Fitur-fitur ini sangat berguna dalam sistem terdistribusi untuk memastikan bahwa aplikasi mitra jarak jauh aplikasi tertentu dapat dipercaya.
Karena kami telah menggunakan SCONE sebagai kerangka kerja SGX kami, penting untuk menunjukkan bahwa SCONE menyediakan layanan pengesahan. Layanan ini dapat dikelola secara lokal ke sistem Anda jika Anda adalah pemegang lisensi SCONE Enterprise. SCONE memiliki layanan pengesahan global untuk pengguna non-perusahaan, dan kami akan mengeksplorasi pengesahan dengan layanan global ini nanti di seri ini.
Di blog saya berikutnya, saya akan mengeksplorasi biaya keamanan di lingkungan DDS-SGX.
