Bagaimana cara mengamankan komunikasi antara aplikasi dan perangkat IoT?


18

Saat ini saya sedang mengerjakan proyek yang mencakup komunikasi Bluetooth antara aplikasi seluler (saat ini menggunakan platform Ionic) dan perangkat yang disematkan. Sebagai perbandingan, produk kami mirip dengan kunci pintar .

Keamanan sangat memprihatinkan, dan kami mencari cara untuk memastikan perangkat keras dan lunak kami tidak dapat diretas. Langkah apa yang harus kita ambil untuk memastikan sistem kita aman?

Sunting: Ya, kami sedang mengenkripsi komunikasi, dan menggunakan HTTPS ketika perangkat berkomunikasi dengan server kami.


Gunakan HTTPS? Apakah Anda mengkode kedua perangkat? Enkripsi?
Mawg mengatakan mengembalikan Monica


2
@ Mawg Sejauh yang saya tahu HTTPS tidak berlaku untuk bluetooth (atau setidaknya, tidak dalam arti normatif / waras).
goldilocks

1
Saya memberikan suara untuk menutup pertanyaan ini sebagai di luar topik karena ini gagal menunjukkan bagaimana ini spesifik untuk IoT. Ini hanya mengamankan komunikasi antar perangkat.
Helmar

4
@Helmar Komunikasi antar perangkat adalah fitur yang cukup penting dari IoT, bahkan fitur yang menentukan, jadi saya gagal melihat mengapa pertanyaan ini akan di luar topik.
Gilles 'SO- berhenti menjadi jahat'

Jawaban:


13

Untuk memastikan bahwa perangkat Anda cukup aman, saya punya beberapa tips:

  1. Tambahkan beberapa enkripsi ke komunikasi Bluetooth. Saya akan merekomendasikan agar kunci enkripsi tidak disiarkan. Misalnya, Anda mungkin meminta pengguna untuk memindai kode QR yang ada di perangkat, dicetak di kotak, dll. Di penyetelan awal aplikasi seluler, mungkin dengan kunci AES? Terserah kamu. Ini untuk mencegah seseorang melihat kata sandi dikirimkan melalui udara dengan teks biasa.
  2. Jika Anda bisa, menjauhlah dari mode ECB (gunakan CBC) dari algoritma enkripsi yang Anda pilih, karena mungkin memberikan beberapa info tentang data yang dikirimkan. Info lebih lanjut tentang itu dapat ditemukan di sini .
  3. Pada transmisi data bluetooth, pastikan untuk memasukkan beberapa ID unik, sehingga pesan tidak dapat diulangi (misalnya, Anda mungkin menyertakan stempel waktu). Anda mungkin juga menerapkan beberapa sistem seperti TOTP.
  4. Letakkan port pada perangkat yang memungkinkannya untuk dengan mudah di-flash, sehingga jika Anda menyadari bahwa perangkat lunak tersebut memiliki bug (dan untuk beberapa alasan Anda tidak dapat memperbaruinya OTA), perangkat tersebut bukan pemberat kertas yang mahal, hanya perangkat yang perlu dicolokkan ke PC dan di-flash ke perangkat lunak baru.
  5. Ekstra: Untuk memastikan bahwa seseorang dengan sertifikat root jahat (mungkin diterbitkan sendiri dan diinstal pada perangkat klien) tidak dapat mencegat komunikasi server Anda, verifikasi sertifikat HTTPS. Ini adalah SO yang menanyakannya untuk Android, Anda juga harus dapat menemukan sumber daya serupa untuk iOS .

Juga, jika Anda ingin mempelajari lebih lanjut tentang kriptologi dan enkripsi yang akan Anda gunakan untuk mengamankan perangkat Anda, periksa ebook ini (gratis) . Ini berbicara banyak tentang implementasi algoritma enkripsi yang baik dan buruk, dan akan membantu Anda dalam mengamankan produk Anda. (Catatan 1: Tolong, tolong jangan buat algoritma Anda sendiri. Catatan 2: Saya tidak berafiliasi dengan crypto101 atau lvh.)


2
"Jika Anda bisa, menjauhlah dari ECB". Tidak, saran yang buruk. Saran yang lumayan adalah "jangan pernah menggunakan ECB", tetapi masih belum lengkap. Jawaban yang lebih baik akan mengatakan bahwa jika Anda mengetik huruf CBC ke dalam kode Anda, Anda salah melakukannya . Secara khusus AES-CBC tidak menjamin integritas atau keaslian komunikasi.
Gilles 'SO- berhenti menjadi jahat'

@Gilles ECB tentu lebih baik daripada semua perangkat iot di luar sana saat ini yang hanya mengirimkan barang-barang sebagai plaintext atau hanya untuk atau dengan nilai yang ditetapkan, tapi ya, ECB hampir tidak membuat produk Anda "tidak dapat diretas" (secara teknis tidak ada yang bisa dilakukan, tetapi Anda dapat mencoba melakukan sesuatu yang akan membuatnya seaman mungkin saat ini untuk waktu yang paling lama, dan itu, tidak melibatkan ECB, tetapi implementasi yang tepat dari AES-CBC 256).
Ave

13

Jika Anda dapat memiliki TCP ujung ke ujung, gunakan TLS ujung ke ujung (misalnya dengan HTTPS).

Jangan menemukan kembali roda, terutama ketika menyangkut kriptografi - kebanyakan orang salah. Kecuali jika perangkat terlalu terbatas sumber daya untuk mendukung TLS, jika Anda turun ke level AES, Anda salah melakukannya . Kesalahan # 1 adalah mengenkripsi dan lupa untuk mengautentikasi - jika Anda memiliki saluran terenkripsi antara server Anda dan man-in-the-middle, alih-alih saluran terenkripsi antara server Anda dan perangkat Anda, maka enkripsi belum memberikan manfaat apa pun . Jika Anda tidak dapat menggunakan TLS, pastikan protokol apa pun yang Anda gunakan mengotentikasi semuanya , dan mengenkripsi apa yang perlu dirahasiakan.

Untuk menggunakan TLS dengan aman, pikirkan jaminan apa yang perlu Anda miliki, dari sudut pandang masing-masing peserta. Umumnya perangkat perlu tahu bahwa itu berbicara ke server yang sah. Itu berarti harus memeriksa sertifikat server. Perangkat harus memiliki sertifikat X.509 dari otoritas sertifikat yang dicatat sebagai tepercaya; ini membutuhkan penyimpanan yang tidak dapat dimodifikasi oleh penyerang, tetapi tidak memerlukan kerahasiaan penyimpanan. Perhatikan bahwa Anda tidak boleh secara langsung membuat kode sertifikat server, karena itu tidak akan membiarkan Anda dengan mudah mengganti sertifikat itu jika dikompromikan. Sebagai gantinya, perangkat menyimpan identitas yang diharapkan(nama host) dari server, dan sertifikat otoritas sertifikat yang menjamin bahwa kunci publik tertentu milik nama host yang diharapkan. Sekali lagi, jangan menemukan kembali roda, bergantung pada pemeriksaan sertifikat yang disediakan oleh perpustakaan atau aplikasi TLS Anda.

Jika server perlu tahu bahwa itu berbicara kepada klien yang sah, maka setiap klien harus memiliki sertifikat klien sendiri. Itu membutuhkan penyimpanan rahasia pada klien. Lulus sertifikat klien ke fungsi pembukaan sesi TLS dari perpustakaan TLS Anda, atau atur dalam konfigurasi aplikasi.

Itu menjaga keamanan komunikasi antara server Anda dan perangkat Anda. Jika aplikasi seluler dapat berbicara dengan perangkat secara langsung (mis. Untuk memungkinkan operasi terputus saat berada di jaringan wifi lokal), Anda harus terlebih dahulu melakukan pemasangan antara sakelar cerdas dan ponsel. Pemasangan berarti pertukaran kunci, lebih disukai pertukaran kunci publik jika sumber daya mengizinkan, jika tidak, kesepakatan kunci rahasia. Tujuan dari pemasangan ini adalah untuk memastikan bahwa setiap perangkat tahu dengan siapa ia berbicara.

Anda juga harus mengamankan saluran kontrol, baik langsung dari perangkat seluler ke sakelar pintar atau melalui server. Pikirkan tentang otorisasi: apakah ada berbagai tingkat akses ke sakelar, mis. Tingkat kendali yang memungkinkan melakukan konfigurasi ulang dan saluran dasar yang hanya memungkinkan sakelar on / off? Ini umumnya ditangani oleh langkah otentikasi setelah membuat saluran aman (TLS jika memungkinkan).

Pertimbangan lain adalah pembaruan firmware. Itu yang rumit: di satu sisi, tidak ada yang namanya keamanan absolut, jadi Anda akan memiliki patch keamanan untuk diterapkan sekarang dan nanti. Di sisi lain, mekanisme peningkatan firmware adalah hal yang kompleks dan mungkin memiliki bug. Paling tidak, pastikan upgrade firmware Anda sudah ditandatangani. Bergantung murni pada keamanan saluran komunikasi untuk peningkatan adalah cerdik, karena tepercaya untuk saluran aman lebih besar daripada verifikasi keamanan statis, dan kadang-kadang Anda mungkin ingin menerapkan pembaruan firmware tanpa koneksi jaringan. Selain memverifikasi tanda tangan, idealnya Anda harus memiliki perlindungan terhadap rollback, sehingga musuh dapat '

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.