Mengamankan protokol nirkabel menggunakan LoRaWAN sebagai contoh

Hai, Habr.

Sekali lagi, saya ingin berbicara tentang bagaimana tingkat dasar (baca: minimum yang diperlukan) keamanan data dalam jaringan nirkabel yang digunakan dalam perangkat IoT disediakan, menggunakan LoRaWAN sebagai contoh.

Kenapa LoRaWAN? Pertama, karena ini merupakan standar yang dijelaskan dan dikembangkan dengan baik yang harus dipandu sebagai referensi jika Anda mengembangkan semacam protokol nirkabel Anda sendiri. Kedua, karena ini adalah solusi IoT yang sangat asli dan khas; Anda dapat, tentu saja, membongkar keamanan di Wi-Fi atau LTE, tetapi bagi sebagian besar pengembang ini akan menjadi analisis yang tidak berguna: Anda tidak perlu menulis implementasi Wi-Fi Anda sendiri. Ketiga, itu adalah perangkat IoT berdaya rendah di mana pengembang menyimpan setiap byte yang sering berubah menjadi yang paling bocor - di sini LoRaWAN memberikan ide bagus tentang bagaimana cara menyimpan byte dan tidak diserang. Keempat, akhirnya, karena secara harfiah dalam beberapa hari terakhir, beberapa klien kami meminta untuk memberi tahu mereka lebih banyak tentang perlindungan data di LoRaWAN, dan dengan artikel ini saya membunuh dua burung dengan satu batu.


Perpesanan LoRaWAN antara server dan perangkat

Meskipun skema perpesanan di LoRaWAN dalam gambar terlihat cukup sederhana - kesederhanaan ini menyesatkan: ia memiliki banyak pekerjaan yang harus dilakukan, dan tidak satu piksel pun di dalamnya berlebihan. Sekarang Anda akan mengerti mengapa.

Kami akan menganalisis menggunakan LoRaWAN 1.0.2 sebagai contoh dan menari terhadap kemungkinan ancaman - untuk pengembang yang baik harus selalu berpikir bukan tentang bagaimana sistemnya dilindungi, tetapi tentang bagaimana sistem itu dapat rusak. Kalau tidak, orang lain akan memikirkannya untuknya.

Jadi, apa saja ancaman utama dalam jaringan nirkabel - dan bagaimana melindungi diri Anda dari mereka?

Intersepsi data pengguna

Ancaman paling sederhana adalah intersepsi data reguler: Karena gelombang radio merambat tidak terkendali, maka siapa pun dapat mengambil penerima yang disetel ke kisaran dan jenis modulasi yang diinginkan, dan mendengarkan semua yang Anda transmisikan.

Cara termudah untuk melindungi dari ini adalah enkripsi data.

Dalam LoRaWAN, data pengguna dienkripsi menggunakan algoritma AES-128 dengan panjang kunci masing-masing 128 bit (16 byte). AES adalah algoritma yang andal, pada mikrokontroler modern minimal yang bahkan tidak memiliki blok enkripsi perangkat keras, penggunaannya tidak memerlukan overhead yang signifikan: pada Cortex-M3 dengan frekuensi 48 MHz, satu blok 16-byte dienkripsi dalam sekitar 100 μs dari awal.

Pengulangan data

Dalam beberapa kasus, penyerang tidak perlu tahu persis apa yang Anda transmisikan di sana. Sebagai contoh, jika sensor Anda memiliki jendela tertutup yang mentransmisikan satu hal, dan yang terbuka mentransmisikan sesuatu yang lain, maka Anda dapat merekam satu tanpa masuk ke rincian isinya, meredam sensor, dan sehingga sistem tidak mencurigai ada sesuatu yang salah karena kurangnya paket dari sensor - menyiarkan pesan yang direkam sebelumnya.

Di LoRaWAN, penghitung ditambahkan ke setiap paket . Jika sebuah paket tiba di server jaringan dengan penghitung yang sama dengan atau kurang dari yang sebelumnya, maka paket ini dibuang begitu saja. Dengan dua byte per meter dan kecepatan transmisi pesan sistem IoT, itu akan bertahan untuk waktu yang sangat lama - misalnya, bahkan stasiun cuaca rumah tangga yang mentransmisikan suhu setiap menit akan meluap hanya setelah satu setengah bulan (LoRaWAN memungkinkan penghitung 4-byte sama sekali).

Namun, ada masalah yang jelas - setelah overflow, paket dengan angka 0 akan datang dari perangkat, yang, jelas, akan lebih sedikit dari angka lainnya, tetapi server jaringan harus melihatnya dengan benar dan mulai menghitung paket lagi. Selain itu, perangkat dapat mengatur ulang penghitung dengan hanya me-reboot.

Ini dicapai dalam satu dari dua cara:

• Sebelum mengirim paket seperti itu, perangkat harus menjalani prosedur pendaftaran di jaringan (di jaringan LoRaWAN, prosedur ini disebut Gabung)
• server memungkinkan kedatangan paket berikutnya dengan nomor 0, sementara hitungan mundur dimulai lagi

Kedua skema digunakan dalam LoRaWAN tergantung pada bagaimana perangkat diaktifkan - OTAA atau ABP (kami akan membicarakannya di bawah). Opsi pertama digunakan untuk OTAA, sementara perangkat juga diberikan kunci enkripsi baru - sehingga bahkan penyerang yang telah menghabiskan satu setengah bulan di bawah stasiun cuaca Anda tidak akan dapat mengirimkan paket yang direkam sebelumnya sehingga sistem menerimanya.

Untuk ABP, di mana tidak ada prosedur registrasi dalam jaringan, opsi kedua digunakan - namun, jika periode counter overflow secara signifikan melebihi perkiraan masa pakai perangkat, dan itu dapat dinonaktifkan. Jika terjadi reboot yang tidak disengaja setelah mengirim setiap paket, perangkat akhir tersebut menyimpan nilai penghitung dalam memori yang tidak mudah menguap.

Skema kedua, tentu saja, kurang aman, tetapi dalam praktiknya diizinkan - penyerang perlu merekam tidak ada paket di dalamnya, tetapi khususnya nol. Jika diinginkan, Anda dapat membuat isinya berbeda dari semua paket lain - misalnya, mengirimkan bukan data di dalamnya, tetapi informasi tentang jenis dan pengaturan perangkat; maka intersepsi dan pengulangannya tidak akan memberikan sesuatu yang masuk akal.

Counter palsu

Namun, pertanyaan segera muncul - bagaimana jika penghitung itu dipalsukan? Anda bisa meletakkannya di bagian terenkripsi dari paket, tetapi kemudian jumlah data pengguna yang sebenarnya akan berkurang dua byte. Anda dapat mengenkripsi tidak hanya data pengguna, tetapi kemudian, pertama, Anda harus beradaptasi dengan ukuran blok 16-byte, dan kedua, beban pada server jaringan akan meningkat, yang harus mendekripsi terlebih dahulu untuk setiap tindakan pada paket (dalam skema, saat hanya data pengguna yang dienkripsi, jika paket diabaikan secara formal, maka tidak ada yang perlu didekripsi).

Jelas bahwa tidak masalah bagi kami apakah penyerang mengetahui nomor paket atau tidak - dalam skema dengan pendaftaran ulang jaringan (OTAA) pengetahuan ini tidak akan membantunya sama sekali, dan di ABP ia akan menunggu waktu yang sangat lama di laut untuk cuaca, mis. kedatangan paket berikutnya dengan nomor N-1.

Karena itu, cukup tidak membiarkannya mengubah nomor ini.

Untuk melakukan ini, seluruh paket di LoRaWAN ditandatangani dengan tanda tangan kriptografi - AES-CMAC, tanda tangan ini dalam standar disebut MIC, Kode Integritas Pesan. Itu memeriksa bahwa seluruh paket , termasuk semua header dan data, telah mencapai server tidak berubah.

Yaitu, setelah menerima paket berikutnya, kita dapat dengan cepat melihat konternya (alamat pengirim, dll), dan jika itu milik kita dan benar, maka sudah memverifikasi tanda tangan (menghabiskan sumber daya tambahan di atasnya), dan jika tanda tangan juga benar - mendekripsi data dan mengirimkan mereka lebih jauh.

Melacak data yang tidak berubah

Sayangnya bagi kami, itu tidak cukup untuk mencegah penyerang memahami data atau setidaknya mengulanginya - dalam beberapa kasus itu akan cukup baginya untuk memahami bahwa mereka tidak berubah. Contoh buku teks adalah meter air rumah: jika Anda hanya ingin mengetahui apakah pemiliknya ada di rumah, tidak masalah bagi Anda berapa liter yang ada, penting bagi Anda untuk mengetahui apakah nilai ini meningkat .

Jelas, enkripsi data adalah prosedur reversibel (mereka dapat didekripsi), yang berarti bahwa data yang sama dienkripsi dengan kunci yang sama selalu terlihat sama. Saat menerima paket dari meteran air, yang bacaannya tidak berubah, Anda dapat, tanpa mendekripsi paket , memahami bahwa mereka tidak berubah.

Untuk mengatasinya cukup sederhana - data atau kunci harus berubah. Untuk mengubah data, Anda dapat menambahkan garam ke dalamnya - beberapa byte acak yang dibuang begitu saja setelah dekripsi. Sayangnya, 16 byte paket sudah jarang, jadi dalam kasus umum kami tidak ingin menghabiskan 2-4 byte paket untuk sampah.

LoRaWAN menggunakan skema yang lebih rumit . Ingat kami memiliki penghitung paket? Jadi, penghitung khusus ini ditambah informasi tentang perangkat dan paket (alamat pendek perangkat di jaringan LoRaWAN, arah transfer data, penghitung 16-byte) dienkripsi menggunakan algoritma AES, dan hasil XOR adalah dengan paket data pengguna.

Akibatnya, byte payload tidak sia-sia, dan setiap pesan terlihat berbeda terlepas dari apakah beban telah berubah atau tidak.

PS Ada opsi lain, sedikit lebih sederhana: gunakan penghitung pesan sebagai N byte terakhir kunci. Dalam hal ini, kuncinya akan menjadi baru setiap kali, tetapi karena Karena server mengetahui nilai penghitung pesan (itu ada di bagian pesan yang tidak terenkripsi), server akan dapat mengembalikannya. Minus - jika paket Anda terdiri dari beberapa blok 16-byte, dan mereka memiliki data yang sama, maka setelah enkripsi mereka akan tetap sama.

Penyerang telah mempelajari kunci enkripsi

Ini adalah situasi yang sangat nyata - IoT ditandai dengan penggunaan sejumlah besar perangkat, di mana Anda mungkin tidak memiliki kendali yang cukup andal atas akses ke orang luar (dan jika Anda juga operator jaringan, maka pelanggan Anda, menurut definisi, orang luar).

Oleh karena itu, jika semua perangkat Anda memiliki kunci enkripsi yang sama, pemilik salah satu dari mereka dapat mendengarkan lalu lintas perangkat lain (secara umum, jika ia memiliki kemampuan untuk memodifikasi firmware, maka untuk operasi seperti itu Anda bahkan mungkin tidak mengetahui kunci secara eksplisit - biarkan firmware baru mengambilnya dari tempat yang sama dengan yang lama, dan hanya memberi kami data orang lain).

LoRaWAN mengimplementasikan dua skema untuk menggunakan kunci, masing-masing untuk setiap perangkat:

• Over The Air Activation, OTAA - kunci dihasilkan oleh server jaringan setiap kali perangkat terdaftar di dalamnya
• Aktivasi Menurut Personalisasi - kunci ditetapkan oleh pabrikan dan disimpan pada perangkat, tidak pernah berubah

Setidaknya ada dua kunci total - AppSKey, yang mengenkripsi data pengguna, dan NwkSKey, yang menandatangani pesan.

Jelas, skema OTAA lebih nyaman dan dapat diandalkan - kunci dapat berubah sesering yang Anda inginkan, mereka dijamin unik dan tidak diketahui siapa pun kecuali server jaringan. Dalam ABP, kunci tidak pernah berubah, keunikannya tergantung pada kesadaran produsen perangkat (misalnya, kami membuat kunci ini dari ID unik mikrokontroler, sehingga kemungkinan kebetulan mereka pada dua perangkat dapat diabaikan), dan mereka harus disimpan secara eksplisit di suatu tempat, jadi ketika harus menghubungkan perangkat secara eksplisit, ke jaringan daftarkan mereka di server.

Namun, prosedur untuk mendapatkan kunci di OTAA adalah cerita yang terpisah, yang, jika diterapkan secara tidak akurat, dapat menimbulkan beberapa jenis serangan lagi.

Intersepsi kunci yang dihasilkan

Jelas, jika kunci baru dihasilkan setiap kali selama pendaftaran di jaringan, maka mereka harus disinkronkan antara perangkat dan server, yang berarti bahwa penyerang dapat mencegatnya, sehingga melanggar semua perlindungan.

Oleh karena itu , perangkat LoRaWAN memiliki kunci ketiga - AppKey, yang dihubungkan dengan kabel ke dalam perangkat dan digunakan pada satu saat: ketika mendaftar di jaringan. Dengannya, pertukaran kunci sesi antara perangkat dan server ditandatangani.

Idealnya, AppKey harus unik untuk setiap perangkat, tetapi dalam banyak kasus penggunaan AppKey yang sama diperbolehkan - karena hanya diperlukan sekali, ini dapat dikenali sebagai valid.

AppKey sebelum menghubungkan perangkat dimasukkan dalam pengaturannya di server jaringan.

Jadi, perangkat menghasilkan permintaan pendaftaran (JoinRequest), bukan mengenkripsi (tidak memiliki informasi sensitif), tetapi menandatanganinya dengan kunci AppKey. Server jaringan, setelah menerima paket ini dan memeriksa alamat pengirim (apakah ini perangkat kami sama sekali) dan kemudian tanda tangan, merespons dengan paket JoinAccept, di mana ia mentransfer pengaturan jaringan - yah, itu sebenarnya mengkonfirmasi pendaftaran.

Dari mana kunci AppSKey dan NwkSKey berasal?

Ini adalah hasil enkripsi AES-128 dengan kunci AppKey dari kombinasi nomor acak AppNonce, nomor kunci (1 atau 2), ID jaringan, dan nomor acak DevNonce lain yang dikirim oleh server dalam respons:

NwkSKey = aes128_encrypt(AppKey, 0x01 | AppNonce | NetID | DevNonce) AppSKey = aes128_encrypt(AppKey, 0x02 | AppNonce | NetID | DevNonce) 

Karena perangkat dan server setelah bertukar paket pendaftaran mengetahui semua parameter ini, mereka akan menghasilkan kunci yang sama. Jadi, kapan saja kunci apa pun akan ditransmisikan oleh radio sendiri, tetapi pada saat yang sama, perangkat dan server akan menerima enkripsi unik dan kunci penandatanganan paket.

Intersepsi aliran data pada dirinya sendiri

Tapi bukan itu saja!

Ya, acara pendaftaran di jaringan biasanya merupakan hal yang jarang, tetapi bayangkan bahwa seorang penyerang dapat memulai dan mencegatnya.

Kemudian, jika ia hanya mengirim paket JoinRequest yang ia rekam, tanpa mengubah apa pun di dalamnya, server akan meresponsnya dengan paket JoinAccept, menghasilkan kunci baru. Setelah ini, perangkat yang diserang berhenti berkomunikasi dengan server, karena tidak memulai JoinRequest dan tidak melihat alasan untuk memperbarui kunci. Artinya, serangan yang sama diulang - tetapi sudah pada prosedur pendaftaran di jaringan.

Seorang penyerang tidak akan bisa memalsukan data, karena untuk ini Anda perlu tahu kunci, dan untuk mendapatkannya Anda perlu tahu AppKey, yang dia tidak tahu. Tetapi untuk menjatuhkan perangkat dari jaringan - dia bisa.

Untuk menghindarinya, saat registrasi, perangkat mengirim DevNonce ke server secara acak (lihat, ada di paket-paket di atas). Selain fakta bahwa kunci dihasilkan atas dasar itu, ia melayani tujuan lain - server LoRaWAN menyimpan arsip DevNonce . Jika perangkat menerima permintaan pendaftaran berulang dengan DevNonce sudah digunakan, server akan mengabaikannya.

Pada gilirannya, perangkat berkewajiban untuk menghasilkan DevNonce baru di setiap pendaftaran (yaitu, rangkaian dengan relay paket konvensional - "tidak menerima respons, meludahkan paket yang sama di radio untuk kedua kalinya" - tidak berfungsi di sini, JoinRequest dibuat ulang setiap waktu).

Kesimpulan

Meskipun ternyata banyak teks dan beberapa gambar, bahkan ini bukan skema lengkap dari kemungkinan serangan di radio saja (pertanyaan tentang mengapa, misalnya, pengaturan harus dienkripsi pada perangkat, dan kami meninggalkan kunci dengan kunci individual untuk setiap perangkat di luar kurung, ini bukan lagi tentang radio). Misalnya, dalam LoRaWAN 1.1, skema perlindungan menjadi semakin rumit.

Namun demikian, ini adalah seperangkat protokol radio pria yang mengklaim memiliki perlindungan informasi minimum yang layak dan pada saat yang sama dirancang untuk bekerja pada perangkat berdaya rendah di jaringan berkecepatan rendah. Selain itu, ini adalah contoh yang sangat baik dari penerapan bukan hanya protokol yang aman, tetapi protokol yang ditulis untuk perangkat berdaya rendah dan meminimalkan konsumsi airtime dan daya komputasi sedapat mungkin tanpa kerusakan signifikan terhadap keamanan.

Dan jika Anda merancang protokol Anda sendiri untuk IoT, maka LoRaWAN yang ditentukan dengan baik, dikombinasikan dengan pemahaman tentang metode dasar melakukan serangan, memberikan kesempatan yang sangat baik untuk belajar bagaimana mengatur perlindungan ini dengan benar.