Mengamankan komunikasi antara sistem tertanam terbatas
Saat ini saya mencoba memperkuat komunikasi melalui saluran komunikasi fisik terbatas pada sistem tertanam.
Skenario
Saya pikir sistem ini agak khas untuk aplikasi kecil yang disematkan:
Sistem tertanam yang terlibat adalah mikrokontroler kecil tanpa OS apa pun, yang dapat dianggap berada dalam lingkungan fisik yang aman. Saluran koneksi secara fisik dapat diakses oleh penyerang, mereka dapat mengganggu pesan yang diinginkan.
Saluran komunikasi yang berbeda dimungkinkan: misalnya RS485 atau RS232. Ada protokol kasar yang menangani hal-hal seperti pengalamatan dan integritas kasar (misalnya CRC16 untuk bitflips) yang dapat kita bangun. Anggap saja sebagai TCP yang lambat.
Setiap mitra komunikasi mengetahui sertifikat akar yang dapat bertindak sebagai CA dan memiliki sertifikat unik (+ kunci) yang ditandatangani olehnya. Sertifikat ditandatangani sendiri, kurva elips prime256v1
Library mbedTLS tersedia untuk sistem ini (dengan DH, AES, ..).
Sebagian besar waktu tidak tersedia internet.
Sistem dapat menjaga waktu dan dapat membuat angka acak yang cukup
Saya ingin mencapai privasi, keaslian, dan integritas.
Bagaimana itu bisa diselesaikan
Aturan dalam protokol kriptografi adalah jangan pernah mengimplementasikannya sendiri. Sayangnya saya tidak menemukan apa pun yang cocok dengan kasus penggunaan ini.
Saya juga melihat-lihat pertanyaan yang ada, tetapi tidak ada yang memberikan solusi lengkap yang saya cari.
Akhirnya dalam jawaban ini menerapkan protokol sendiri diberikan sebagai opsi terakhir.
Inilah sebabnya mengapa saya menemukan solusi yang dijelaskan di bawah ini - tetapi saya tidak sepenuhnya yakin tentang itu. Saya berorientasi pada jawaban ini tentang cara mengotentikasi Diffie-Hellmann Key Exchange , jawaban ini tentang cara memeriksa integritas dan utas ini memberi saya beberapa ide tentang cara mengimplementasikan protokol semacam itu .
Protokol untuk mengamankan komunikasi
Hal pertama yang harus dilakukan adalah membuat kunci simetris secara acak K. Hal pertama yang dikirim adalah pesan jabat tangan. Ini memiliki bidang berikut:
| Bidang | Deskripsi |
|---|---|
| DH | Tukar kunci Diffie-Hellmann msg g K |
| Cert | Sertifikat (-chain) dari perangkat pengirim |
| MsgIdNonce | Nilai 64-bit acak |
| Tanda tangan | Tanda tangan dari pesan lengkap menggunakan kunci pribadi Cert |
Kedua perangkat mengirim (dan menerima) pesan seperti itu.
Ketika pesan diterima, berikut ini dilakukan:
- Periksa apakah sertifikat ditandatangani oleh CA yang diharapkan (harus dalam rantai)
- Periksa apakah msg benar ditandatangani dengan sertifikat dan kuncinya
Ketika pemeriksaan ini berhasil, pesan DH g K yang dikirim dan diterima digunakan untuk menghitung kunci simetris.
Mulai saat ini, aplikasi dapat mengirim pesan yang dienkripsi dengan AES-CBC. Karena pesan relatif sering hilang, IV selalu ada dalam pesan.
Ini adalah format pesannya:
| Bidang | Deskripsi | Dienkripsi |
|---|---|---|
| IV | Awalnya Random IV untuk AES | Tidak |
| MsgIdNonce | Jabat Tangan / Pesan Terakhir + 1 atau + 2 | Iya |
| data aplikasi | Data / perintah yang harus dilindungi | Iya |
| CMAC dipotong menjadi 64 Bit | MAC untuk memeriksa integritas | Iya |
Agar pesan diterima, itu harus
- Miliki MsgIdNonce yang diharapkan (1 atau 2 di atas terakhir menerima satu) - mencegah serangan replay, memungkinkan untuk kehilangan 1 pesan
- Memiliki CMAC yang valid - mencegah serangan terhadap integritas
- Diterima max. T detik setelah pesan terakhir - mencegah serangan penundaan
Jika ada yang tidak sesuai harapan, Jabat tangan dikirim lagi, lalu pesan dikirim lagi dengan parameter yang baru ditukar.
Pertanyaan
Apakah saya berada di jalan yang benar atau haruskah saya mencoba sesuatu yang sama sekali berbeda?
Apakah ini memberikan tujuan keamanan saya atau apakah saya melewatkan kerentanan yang jelas di sini?
Bisakah ini bekerja?
Saya harap Anda dapat membantu saya dan teknisi tersemat lainnya yang menghadapi masalah serupa!
Jawaban
Aturan dalam protokol kriptografi adalah jangan pernah mengimplementasikannya sendiri. Sayangnya saya tidak menemukan apa pun yang cocok dengan kasus penggunaan ini.
Sudahkah Anda mempertimbangkan DTLS ? Itu mencoba untuk mengatasi masalah yang sama (kecuali untuk stempel waktu; yang dapat ditambahkan dengan memasukkan stempel waktu di datagram), dan sudah memikirkan semuanya. Kemungkinan lain adalah IPsec; namun DTLS berusaha mengatasi masalah yang Anda hadapi (kecuali lalu lintas data yang Anda lindungi adalah lalu lintas IP).
Karena itu, berikut beberapa pemikiran tentang protokol yang Anda uraikan:
Apa yang terjadi jika dua pesan berurutan dijatuhkan (mis. Diterima secara tidak benar)? Akankah kedua belah pihak menyadari apa yang terjadi, atau akankah mereka melanjutkan untuk membuang semua pesan berikutnya (karena aturan 'nonce harus menaikkan tidak lebih dari 2')?
Menganggap mereka mencoba rekey, bagaimana ini terkoordinasi? Jika satu pihak berpikir bahwa mereka belum mengikuti, dan pihak lain berpikir demikian, apa yang akan terjadi pada pesan yang dienkripsi dengan kunci lama? Kami merasa umumnya berguna untuk menyertakan tag 'which key this is encrypted under' dengan ciphertext (dalam DTLS, ini adalah 'epoch').
Dapatkah saluran komunikasi Anda menyusun ulang pesan? Saya curiga tidak bisa dalam kasus Anda, tetapi jika bisa, Anda harus memikirkan bagaimana itu harus ditangani.
Apa yang terjadi jika seseorang memasukkan pesan jabat tangan sebelumnya (valid)? Bagaimana hal itu akan membingungkan?
Di jalur enkripsi data, Anda menggunakan enkripsi CBC dan integritas CMAC. Meskipun ini adalah solusi yang bisa diterapkan, ini rentan terhadap berbagai serangan padding jika tidak terintegrasi dengan benar. Mode saat ini adalah menggunakan mode AEAD (seperti GCM atau Chacha20 / Poly1305) yang melakukan keduanya.
Apakah lalu lintas terenkripsi searah atau dua arah? Jika lalu lintas berjalan dua arah, apakah Anda menggunakan kumpulan kunci yang sama untuk melindungi kedua kumpulan lalu lintas?
"Jika ada yang tidak sesuai harapan, Jabat tangan dikirim lagi, lalu pesan dikirim lagi dengan parameter yang baru ditukar." - bagaimana cara kerjanya? Jika penerima memutuskan tidak menyukai pesan tersebut, bagaimana pengirim tahu untuk mengirimnya kembali?