Apakah praktik yang buruk untuk menyimpan sertifikat pada memori eksternal?

Kami sedang mengerjakan AWS-IoT menggunakan mikrokontroler STM32.

Hingga hari ini, kami sedang menulis sertifikat ke flash dan mengunci flash dari pembacaan eksternal. Seiring meningkatnya kode aplikasi, kami mendapatkan ruang yang lebih sedikit pada flash sehingga kami berencana untuk memindahkan sertifikat secara eksternal pada kartu SD / EEPROM dan membaca kapan saja diperlukan sebelum menghubungkan ke AWS-IoT.

Catatan:

• Kebijakan yang ditulis untuk hal ini hanya akan memungkinkan perangkat dengan nama tertentu untuk terhubung pada sertifikat tertentu.

• Masalahnya diperbolehkan untuk mempublikasikan ke hanya 2 saluran (itu nama dan saluran umpan data) yang terhubung ke prosesor data yang akan mengabaikan paket-paket jahat yang datang ke sana.

• Jika hal itu menerbitkan / berlangganan ke topik lain, AWS akan segera memutuskan hal itu.

Jika saya mendeteksi perangkat dicuri / jahat, kami menonaktifkan kunci dari server.

Apa yang dapat dilakukan oleh eksploiter dengan sertifikat (RootCA, kunci server, kunci klien)?

Apakah praktik yang buruk untuk menyimpan sertifikat untuk penggunaan seperti itu pada penyimpanan eksternal yang dapat diakses oleh eksploitasi?

Anda menyebutkan "sertifikat", tetapi dari konteksnya, saya pikir Anda mengacu pada dua hal yang berbeda.

• Perangkat Anda memiliki kunci pribadi , yang unik untuk perangkat ini dan tidak dikenal di luar perangkat. Kunci ini mengidentifikasi perangkat Anda. Siapa pun yang dapat mengakses kunci itu dapat menyamar sebagai perangkat. Itu berarti mereka dapat, khususnya:

  • Publikasikan data yang valid, tetapi salah pada saluran yang perangkat Anda sah untuk menerbitkannya.
  • Publikasikan data yang tidak valid yang akan membuat perangkat yang sah dilarang.
  • Mungkin, tergantung pada kasus penggunaan, memaparkan beberapa informasi pribadi dari pemilik perangkat.

  Kunci pribadi ini sebaiknya tetap dirahasiakan.

• Perangkat Anda mungkin memiliki setidaknya satu kunci publik , yang memungkinkannya mengenali server mana yang diajaknya bicara. Tidak masalah kalau ada yang bisa membaca kunci ini: ini untuk umum Tetapi seorang penyerang seharusnya tidak dapat memodifikasi kunci. Jika tidak, mereka dapat berkomunikasi dengan perangkat dan menyamar sebagai server. Ini dapat memungkinkan mereka untuk melakukan hal-hal seperti:

  • Dorong pembaruan firmware ke perangkat.
  • Dorong pembaruan konfigurasi ke perangkat.
  • Buat perangkat mengunggah datanya ke lokasi yang berbeda.

Berita baiknya adalah bahwa analisis ancaman ini sebenarnya tidak terlalu relevan. Anda tidak perlu mengorbankan keamanan apa pun ! (Setidaknya bukan sifat kerahasiaan dan keaslian - jika Anda menyimpan barang secara eksternal, maka ketersediaan akan terpukul, karena itu adalah salah satu bagian dari sistem yang bisa hilang.)

Selama Anda memiliki setidaknya 128 bit penyimpanan yang dapat Anda tulis setidaknya satu kali, yang Anda miliki dan banyak lagi, Anda dapat menerapkan solusi penyimpanan jarak jauh yang aman. Gunakan penyimpanan pada perangkat dengan ruang terbatas untuk menyimpan kunci rahasia. Kunci rahasia ini harus unik untuk setiap perangkat; STM32 memiliki RNG perangkat keras, sehingga Anda dapat membuatnya di perangkat saat boot pertama. Jika perangkat Anda tidak memiliki RNG perangkat keras, Anda dapat membuat kunci di lokasi yang tidak aman dengan perangkat dan menyuntikkannya ke perangkat.

Dengan kunci ini, gunakan enkripsi terautentikasi untuk hal-hal yang Anda simpan di perangkat. Saat Anda ingin membaca beberapa data dari penyimpanan eksternal, muat, dekripsi dan verifikasi. Saat Anda ingin menulis beberapa data ke penyimpanan eksternal, enkripsi dan tandatangani. Ini menjamin bahwa data bersifat rahasia dan otentik seperti data dalam penyimpanan internal.

Enkripsi terautentikasi sudah cukup untuk menjamin kerahasiaan dan keaslian data, tetapi tidak cukup menjamin integritasnya .

• Jika ada lebih dari satu chunk data, maka ketika perangkat membaca kembali chunk data, tidak dapat memastikan bahwa ini adalah chunk yang benar. Solusi: dilengkapi pengenal yang unik dalam isi masing-masing potongan (misalnya mulai setiap potongan dengan salah satu "AWS-IoT private key.", "configuration CA certificate.", "publishing server CA certificate.", "user personal data.", ...).
• Jika Anda memperbarui data di beberapa titik, maka ketika Anda membacanya kembali, Anda tidak dapat memastikan bahwa Anda mendapatkan versi terbaru dari data itu. Jika seseorang dapat memodifikasi penyimpanan eksternal, mereka tidak dapat memasukkan data palsu karena itu akan gagal memeriksa keaslian, tetapi mereka dapat mengembalikan data lama, karena apa yang dulu otentik masih asli. Solusi: di setiap potongan data yang disimpan secara eksternal, sertakan penghitung yang Anda tambahkan setiap kali Anda menulis versi baru dari potongan itu. Saat Anda membaca potongan, verifikasi bahwa itu adalah versi yang diharapkan.

Untuk menghindari bricking perangkat jika penyimpanan eksternal rusak atau hilang, di ruang terbatas Anda memiliki ruang penyimpanan internal, Anda harus memberikan prioritas pada apa pun yang diperlukan untuk mengatur ulang perangkat ke keadaan "baik", misalnya reset pabrik . Prioritas kedua adalah pertimbangan kinerja.

Sedikit konteks

Karena Anda menggunakan MQTT dengan AWS IoT, Anda diharapkan menggunakan sertifikat X.509 untuk otentikasi dan keamanan. Amazon memiliki sedikit panduan tentang bagaimana Anda harus mengamankan sertifikat Anda, jadi saya akan mengutipnya di sini:

Sertifikat memungkinkan kunci asimetris untuk digunakan dengan perangkat. Ini berarti Anda dapat membakar kunci pribadi ke penyimpanan aman di perangkat tanpa pernah membiarkan materi kriptografi yang sensitif meninggalkan perangkat.

Karena Anda saat ini menggunakan STM32's Read Out Protection (RDP), semua kecuali penyerang yang paling gigih akan kesulitan mengakses sertifikat Anda dalam skema Anda saat ini:

Global Read Out Protection memungkinkan kode firmware tertanam (dimuat dalam memori Flash) untuk melindungi terhadap rekayasa balik, pembuangan menggunakan alat debug atau cara lain dari serangan intrusif.

• Level 0 - Tidak ada perlindungan (default)
• Level 1 - Memori flash dilindungi dari pembacaan dengan debugging atau dump kode oleh kode yang dimuat RAM
• Level 2 - Semua fitur debug dinonaktifkan

Apakah penyimpanan eksternal akan aman?

Ini mungkin tidak seperti yang aman . Jika kunci pribadi klien Anda dicuri, penyerang dapat mengirim data yang tampaknya berasal dari perangkat Anda, padahal sebenarnya tidak. Meskipun tidak jelas data apa yang Anda kirim, data yang tidak dipercaya bisa menjadi risiko keamanan.

Bit mana yang saya perlukan untuk tetap pribadi?

Saat Anda membuat sertifikat perangkat di AWS IoT, Anda akan melihat gambar seperti ini:

^{Gambar dari halaman Buat dan Aktifkan Sertifikat Perangkat dari dokumentasi AWS IoT.}

Kunci pribadi adalah hal yang benar-benar harus Anda jaga ... pribadi , dan tentunya harus disimpan pada memori yang dilindungi baca jika memungkinkan. Kunci publik dan sertifikat dirancang untuk dibagikan, jadi jika Anda kehabisan ruang, Anda dapat dengan aman memindahkannya ke penyimpanan eksternal. Anda bisa mendapatkan sedikit lebih banyak konteks di halaman Bagaimana cara kerja SSL / TLS? di Keamanan Informasi Stack Exchange dan kriptografi kunci publik di Wikipedia. Saya pikir saya akan merugikan Anda jika saya tidak menyertakan gambar ini untuk menjelaskan mengapa kunci pribadi perlu dirahasiakan:

.

^{Gambar dari Wikipedia , dirilis ke domain publik.}

Kunci publik perangkat Anda adalah apa yang digunakan AWS IoT untuk menandatangani pesan untuk dikirim ke perangkat Anda (tetapi itu tidak membuktikan siapa yang mengirim pesan ). Jadi, sungguh, ini bukan bencana besar jika seseorang mencuri kunci publik, karena itu tidak dimaksudkan untuk menjadi rahasia.

The kunci pribadi adalah apa kegunaan perangkat Anda untuk mendekripsi pesan, sehingga masalah sedikit lebih besar jika penyerang mencuri ini.

Anda juga bertanya apa yang akan terjadi jika penyerang mencuri sertifikat RootCA. Jika seseorang mencuri kunci pribadi AWS IoT , itu akan menjadi bencana, tetapi sertifikat RootCA pada perangkat Anda bukanlah itu . Yang RootCA.crtdiberikan Amazon kepada Anda sepenuhnya bersifat publik , dan tujuannya adalah agar Anda dapat memverifikasi bahwa Anda tidak diserang dengan cara apa pun (kemungkinan besar seorang lelaki berpura-pura menjadi server AWS IoT).

Kerusakan apa yang bisa dilakukan oleh perangkat yang diretas?

Perangkat Anda yang dicuri hanya dapat melakukan tindakan yang tercantum dalam kebijakan . Cobalah untuk mengikuti prinsip hak istimewa yang paling rendah ; hanya berikan perangkat Anda hak istimewa yang benar - benar dibutuhkan , jadi jika yang terburuk terjadi, itu tidak dapat menimbulkan kerusakan terlalu banyak. Untuk kasus spesifik Anda:

Masalahnya diperbolehkan untuk mempublikasikan hanya ke 2 saluran (namanya dan saluran umpan data) yang terhubung ke pemroses data yang akan mengabaikan paket-paket jahat yang datang kepadanya.

Itu bagus. Setiap serangan harus diisolasi hanya pada dua topik MQTT yang dapat dipublikasikan perangkat, sehingga tidak akan menyebabkan kerusakan skala besar.

Idealnya Anda ingin keseluruhan sistem Anda memiliki desain sedemikian rupa sehingga membedah satu unit hanya mematahkan unit itu, dan bukan sistem secara umum.

Terutama jika Anda menyimpan kunci dalam memori yang berbeda sehingga mereka melewati antarmuka listrik standar antara chip, maka mereka hanya boleh menjadi kunci yang sudah aman untuk diterbitkan, atau unik untuk instance fisik tertentu perangkat.

Jika kunci individu diekstraksi dari satu perangkat, dan mulai disalahgunakan atau muncul dalam volume lalu lintas yang harus dari beberapa klon yang tidak sah, maka Anda bisa melarang kunci itu di sisi server.

Kunci Anda tentu saja harus memiliki sifat tidak menjadi sesuatu yang dapat ditebak oleh pihak yang tidak berwenang dari beberapa contoh yang diekstraksi atau menghasilkan contoh asli yang kompatibel sendiri - yaitu, Anda memerlukan catatan kunci yang telah Anda buat di mana yang valid hanya bagian kecil dan tak terduga dari ruang kemungkinan besar, atau Anda harus menandatangani kunci yang Anda buat dan membuat sistem Anda hanya menerima kunci dalam kombinasi dengan bukti tanda tangannya.

Anda harus mencoba merahasiakan kunci klien (tetapi pahami implikasi kehilangannya (1), seperti yang dijelaskan dalam jawaban lain). Kunci publik server, dan sertifikat publik AWS penting untuk mengamankan pada perangkat bukan karena Anda ingin merahasiakannya, tetapi karena dengan mengganti sertifikat AWS (pada perangkat yang dikompromikan) penyerang dapat membujuk perangkat untuk melakukan tukar dengan tuan rumah si penyerang, atau utarakan komunikasi Anda ke AWS.

Dengan melakukan ini (2), seorang penyerang dapat menghapus keamanan TLS yang dapat mengakibatkan pengurangan keamanan yang cukup sehingga mereka dapat merekayasa balik kunci klien.

Dengan alasan ini, satu-satunya kunci yang aman untuk diekspos dalam perangkat memori eksternal adalah kunci publik server. Mengubah ini (3) hanya akan memungkinkan perangkat Anda dipaksa untuk terhubung ke layanan AWS jahat yang mungkin sulit merekayasa akses. Bahkan membocorkan hanya kunci ini dapat memungkinkan seseorang untuk mengintip atau memalsukan beberapa transmisi (misalnya jika lapisan TLS entah bagaimana dapat diturunkan).

Jadi, secara ringkas, risikonya bukan hanya pada informasi yang bocor, ada risiko jika firmware (yang seharusnya dipercaya) dapat diberikan dengan informasi aman yang tidak tepercaya.