Halo para pecinta Internet of Things. Catatan lanjutan penyedia IoT.
Bagian pertama > || >
Bagian kedua > || >
Bagian ketiga > || >
Bagian keempatHari ini saatnya berbicara tentang keamanan di LoRaWAN. Ada banyak rumor dan legenda. Kami akan mencoba mencari tahu cara kerjanya dan apa risikonya.
Untuk beralih ke topik keamanan, Anda harus membuat pengantar kecil dan berbicara tentang inisialisasi awal modul radio pada jaringan. Proses dalam LoRaWAN ini disebut aktivasi.
Untuk singkatnya, saya akan daftar di bawah persyaratan yang kami butuhkan. Jika Anda sedikit bingung - Anda dapat kembali ke sini dan memeriksa. Anda mungkin harus kembali, karena singkatan banyak istilah sangat mirip. Selain itu, dalam uraian ini saya akan memberikan analogi sehingga Anda memahami kira-kira dengan apa istilah ini atau itu dapat dibandingkan. Tidak selalu mungkin untuk memilih analogi yang tepat, karena itu jangan menilai kolom ini terlalu ketat.
Jadi, aktivasi di LoRaWAN dapat dilakukan melalui udara (OTAA), atau dengan preset (ABP).
OTAA (Over-the-Air-Activation)
Dalam hal aktivasi melalui udara, tiga parameter harus ditetapkan pada modul radio kami. Pengidentifikasi unik (DevEUI), pengidentifikasi server (AppEUI), dan kunci server (AppKey).
Di sisi server, pengidentifikasi modul radio, pengidentifikasi server dan kunci juga harus terdaftar. Yaitu server pada awalnya harus tahu perangkat yang akan mencoba untuk bergabung dengannya. Jika kita mengetahui pengidentifikasi dan kunci server, tetapi DevEUI kita tidak terdaftar di databasenya, maka koneksi akan gagal.
Setelah penyalaan awal, radio mengirimkan paket join_request di udara di salah satu dari tiga frekuensi gabungan yang telah ditentukan. Dengan paket ini, ia bertanya apakah ada jaringan di dekatnya yang akan "mengenalinya". Berikut ini adalah komposisi dari paket join_request. Seperti yang Anda lihat, ini berisi DevEUI dan AppEUI, serta DevNonce.
DevNonce adalah variabel acak. Server menyimpannya dalam memori untuk beberapa waktu dan jika join_request tiba dengan DevNonce yang sama dengan yang sebelumnya, server akan mengabaikan permintaan ini. Ini untuk melindungi dari serangan berulang ketika penyerang dapat menuliskan permintaan aktivasi dan kemudian mengulanginya dari perangkatnya. By the way, tidak semua standar IoT dapat membanggakan perlindungan terhadap serangan ini.
AppKey tidak secara langsung digunakan dalam pesan ini, tetapi melaluinya MIC checksum pada akhir frame dipertimbangkan.
Kami akan membutuhkan kunci ini sedikit lebih jauh, dalam pesan respon dari server join_accept.
Join_request ditransmisikan tidak terenkripsi.
Join_accept akan diterima jika server mengetahui AppEUI dan DevEUI, serta tidak ada kecocokan di bidang DevNonce dan tidak ada masalah dengan MIC. Jika tidak, tidak akan ada jawaban. Jika semua pemeriksaan dilewati, server menghasilkan pesan respons join_accept. Komposisinya ditunjukkan pada gambar di bawah ini.
Bahkan, dua kunci sesi dihasilkan - server jaringan (NwkSKey) dan server aplikasi (AppSKey). Kunci-kunci ini bersama dengan informasi lain dienkripsi oleh AppKey dan dikirim ke modul radio. Selanjutnya, semua olahpesan terjadi dengan enkripsi ganda dengan kunci sesi (dengan pengecualian paket dengan perintah MAC, mereka tidak dienkripsi dengan kunci server aplikasi). NwkSKey tidak mengambil bagian dalam enkripsi paket hanya dengan data (tanpa perintah), tetapi sebuah checksum dianggap melaluinya.
NwkSkey dan AppSKey unik untuk setiap modul radio.
Dua kunci digunakan untuk perlindungan informasi tambahan. Setiap kali paket dari modul radio tiba di sistem kami, sebagian akan dienkripsi untuk server jaringan dan sebagian untuk server aplikasi. Yaitu server jaringan akan dapat mendekripsi hanya pesan-pesan yang ditujukan kepadanya (berbagai pesan layanan). Server aplikasi hanya akan melihat komponen yang berguna dari paket (sebenarnya data yang diteruskan). Ini diperlukan karena server jaringan dengan probabilitas 99 persen akan berada di provider. Tetapi server aplikasi mungkin di-host oleh klien. Enkripsi ganda mempersulit penyedia untuk mengetahui konten paket.
Selain dua kunci, ada hal penting lain untuk join_accept di OTAA - daftar frekuensi yang diperluas (CFList). Biarkan saya mengingatkan Anda bahwa pada awalnya modul radio hanya tahu tiga frekuensi di mana ia dapat beroperasi. Setelah aktivasi, frekuensi tambahan terdaftar untuk berkomunikasi.
Ini sangat nyaman jika tidak diketahui secara pasti di jaringan mana perangkat akan bekerja. Kami dapat menyetujui bahwa di semua jaringan 3 frekuensi (+ RX2) akan selalu bertepatan, dan lima sisanya berada pada kebijaksanaan penyedia.
Juga, untuk masa depan, untuk bekerja dengan sejumlah besar perangkat CFList dapat digunakan untuk pengelompokan
Ini adalah ketika Anda membagi jaringan menjadi beberapa kelompok dan di dalam kelompok ada perencanaan frekuensi. Katakanlah modul radio kami tahu tiga frekuensi F1, F2 dan F3. Ini aktif di salah satu frekuensi dan jika ada di cluster1, maka ia menerima tabel frekuensi tambahan dalam bentuk F4-1, F5-1 dan F6-1. Untuk klaster 2, ia akan mendapatkan F4-2 yang sangat berbeda, F5-2, F6-2. Pada saat yang sama, kita dapat mengkonfigurasi semua modul radio dengan cara yang sama dan tidak benar-benar berpikir yang mana yang akan termasuk dalam kelompok mana. Dan di kelompok tetangga, kemungkinan tabrakan akan menurun tajam.
ABP (Aktivasi berdasarkan Personalisasi)
Prosedur yang disederhanakan ketika kunci sesi segera ditransfer ke modul radio dan pada awalnya terdaftar di sisi server. Nyaman karena Anda tidak perlu mengaktifkan, modul radio segera siap digunakan. Tidak ada yang lebih nyaman, karena keamanan dalam hal ini begitu-begitu. Selain itu, Anda tidak dapat menarik frekuensi dari server. Saya belum pernah melihat kasus penggunaan nyata. Kami tidak akan mempertimbangkannya, dan semua yang berikut adalah tentang OTAA.
Dan bagaimana dengan keamanan?
Jadi, pada dasarnya, kami memiliki beban enkripsi utama pada kunci sesi dari server jaringan dan server aplikasi.
Pertimbangkan mereka sedikit lebih hati-hati.
Keluhan utama kritik terhadap standar LoRaWAN adalah bahwa ketika perangkat diaktifkan di jaringan, kami memiliki dua kunci, yang kemudian dapat tetap tidak berubah selama berbulan-bulan. Lebih tepatnya, mereka mungkin tidak berubah selama bertahun-tahun sampai perangkat diaktifkan kembali. Dalam kondisi normal, kami mengaktifkan dan melupakan modul radio, sehingga usia kunci tiga hingga empat tahun adalah prospek yang sangat realistis. Sebenarnya, dari instalasi hingga meninggalkan baterai nol.
Seberapa andalkah kunci kami?
Spesifikasi mengatakan bahwa mereka mematuhi RFC4493 yang misterius.
Apa ini Ini adalah algoritma enkripsi, lebih dikenal sebagai AES-CMAC.
Mari kita tidak merangkak ke belantara kriptografi dan membatasi diri kita pada pemahaman umum tentang gambar. Ini disajikan pada gambar di bawah ini.
Prinsip AES-CMAC kira-kira sebagai berikut: pesan terenkripsi dibagi menjadi blok 128-bit. Setiap blok dienkripsi secara terpisah dengan kunci AES. Selain itu, ketika mengenkripsi blok kedua, selain kunci, hasil enkripsi yang pertama digunakan. Dan ketika mengenkripsi yang ketiga - hasil yang kedua dan (secara tidak langsung) yang pertama. Seperti rantai komplikasi.
Seberapa andalkah prinsip ini?
Sangat bisa diandalkan. Algoritma keluar lebih dari sepuluh tahun yang lalu. Sejak itu, ia telah diserang oleh banyak serangan berbeda, dan akhirnya, secara teori, mereka membuktikan bahwa ia dapat diretas. Masalahnya adalah bahwa sejumlah besar paket, beberapa ribu, akan diperlukan untuk memecahkannya. Lalu ada kesempatan untuk memahami apa yang ada di dalam blok terenkripsi.
Bisakah penyerang dengan pengetahuan yang diperlukan mendapatkan sampel ini jika kita berbicara tentang mencegat paket LoRaWAN? Mari kita perkirakan. Biarkan paket pergi sekali dalam satu jam. Dalam sebulan, 720 paket akan keluar dari modul radio. Tidak cukup
Untuk ancaman nyata, kita membutuhkan pasien yang sangat sabar yang akan menulis paket selama berbulan-bulan. Dan itu bukan fakta bahwa dia masih bisa memecahkan algoritma dan mendapatkan kunci berharga. Jangan lupa bahwa kesabaran seperti itu perlu diperlihatkan sehubungan dengan setiap modul radio secara terpisah. Dan ingat bahwa mengirim paket sekali dalam satu jam adalah SANGAT sering. Dalam praktiknya, intervalnya jauh lebih lama - enam jam, atau bahkan sehari.
Tetapi bahkan kesempatan hantu ini sekarang ditutup setelah rilis spesifikasi 1.1, di mana re-aktivasi dan bergabung dengan perintah server diimplementasikan. Mari kita bicarakan spesifikasi ini. Untuk saat ini, saya ingat pemikiran saya dari artikel sebelumnya: ketika standar terbuka dan memiliki komunitas, semua lubangnya terlihat. Selama upgrade, pengembang tahu persis apa yang harus dilihat pada awalnya.
Akibatnya, kami mendapat bahwa ancaman keamanan agak ilusi. Di suatu tempat dalam teori yang mendalam, peretasan dapat dilakukan, tetapi dalam praktiknya itu praktis tidak realistis. Sekarang kalikan dengan nilai informasi yang diterima. Akankah penyerang kami mulai menulis paket selama berbulan-bulan untuk mengetahui penghitungnya? Tidak mungkin.
LoRaWAN memenuhi rasio harga-kinerja yang wajar. Kami memahami bahwa perlindungan dapat ditingkatkan. Tapi ini adalah kekuatan komputasi pada akhirnya, ini adalah beban tambahan pada baterai, adalah mungkin untuk meningkatkan ukuran paket atau mengurangi muatan.
Bagi saya, ini lebih dari sekadar tugas telemetri.
Dalam komentar, saya akan senang mendengar lawan dan pendukung saya. Ingatlah bahwa topik keamanan selalu membutuhkan diskusi dan jangan pernah berpijak pada pendapat satu orang.