Apa implikasi daya mengenkripsi lalu lintas sensor saya?

13

Mempertimbangkan tipe aplikasi yang khas, sensor bertenaga baterai yang mengambil bacaan (nilai 32 bit) setiap 10 menit, apa dampak yang mungkin terjadi pada usia baterai jika saya memilih protokol siaran langsung yang tidak dienkripsi, dibandingkan dengan transmisi terenkripsi?

Asumsikan bahwa data saya tidak terlalu rahasia, tetapi menurut pertanyaan ini saya mungkin perlu mempertimbangkan untuk mengenkripsi, asalkan sebenarnya tidak ada biaya desain yang signifikan.

Untuk kesederhanaan, anggap saya menggunakan nCF51822 SoC yang mendukung BLE stack dan protokol 2,4 GHz yang lebih sederhana.

Karena saya sedang memikirkan aplikasi produk komersial daripada instalasi satu kali, enkripsi perlu komputasi intensif untuk dipecah (katakanlah setidaknya $ 500 dari komputasi awan 2016), daripada kebingungan sederhana. Sesuatu yang tetap aman bahkan dengan akses ke firmware perangkat.

— Sean Houlihane
sumber

2

"Sesuatu yang tetap aman bahkan dengan akses ke firmware perangkat." berarti bahwa Anda harus menggunakan kriptografi asimetris yang secara komputasi mahal untuk dibalik, atau Anda perlu menyimpan kunci simetris di mana itu tidak dapat diambil atau dilakukan untuk pemulihan (dikenal serangan plaintext, dll). Biasanya dalam kasus terakhir, setiap salinan produk memiliki kunci unik sehingga pemulihan dari satu sampel tidak merusak seluruh sistem; tetapi ini berarti receiver Anda perlu menyimpan semua kunci itu.

— Chris Stratton

8

Sebagian besar daya Anda kemungkinan akan dikeluarkan untuk transmisi RF, bukan siklus CPU yang dihabiskan dalam rutinitas enkripsi. Setiap bit tambahan yang dikirim akan dikenakan biaya lebih banyak daya daripada enkripsi yang Anda usulkan. Itu berarti jika Anda mengambil pendekatan naif, seperti menggunakan AES dalam mode CBC, Anda berisiko meningkatkan ukuran pesan untuk membawa bit tambahan di setiap blok.

Jika Anda menentukan bisnis Anda membutuhkan data yang akan dienkripsi, pertimbangkan untuk menggunakan AES dalam mode CTR untuk menghasilkan bit stream cypher. Counter mode praktis untuk menangani kasus-kasus di mana penerimaan bisa tidak dapat diandalkan dan paket mungkin hilang. Anda harus tetap menyinkronkan penghitung, jadi ketahuilah bahwa mentransmisikan nilai penghitung secara berkala akan menambah overhead. Dan Anda harus mencadangkan beberapa byte status untuk memegang penghitung, karena penggunaan kembali bit stream terenkripsi dapat mengarah langsung ke pemulihan data.

— John Deters
sumber

Kedengarannya meyakinkan, dan menempatkan masalah yang sangat berbeda, yang saya tidak terlalu memikirkan tentang kali ini.

— Sean Houlihane

2

Hati-hati karena RKT tidak memberikan keaslian data. Anda harus menggunakan mode enkripsi terotentikasi kecuali Anda memahami mengapa keaslian tidak menjadi masalah dalam aplikasi Anda.

— Gilles 'SANGAT berhenti menjadi jahat'

10

Ada berbagai metode enkripsi yang dapat Anda gunakan untuk mengamankan lalu lintas Anda, dan masing-masing memiliki penggunaan daya yang sedikit berbeda, jadi saya akan memilih beberapa pilihan populer. Metodologi yang saya gunakan untuk mengevaluasi setiap metode harus dapat diterapkan pada cipher lain yang Anda temukan dan ingin dibandingkan.

AES

AES adalah salah satu algoritma enkripsi kunci simetris yang paling populer (yang berarti Anda menggunakan kunci yang sama untuk mengenkripsi dan mendekripsi). Dalam hal keamanan, AES adalah taruhan yang aman:

Kriptanalisis publik terbaik

Serangan telah dipublikasikan yang secara komputasi lebih cepat daripada serangan brute force penuh, meskipun tidak ada pada tahun 2013 yang layak secara komputasi.

- Wikipedia

Makalah Biclique Cryptanalysis dari AES Penuh menggambarkan bahwa AES-128 membutuhkan 2 operasi ^126,1 , AES-192 membutuhkan 2 operasi ^189,7 , dan AES-256 membutuhkan 2 ^254,4 operasi untuk dipecahkan. Pada prosesor 2,9 GHz, dengan asumsi setiap 'operasi' adalah 1 siklus CPU (mungkin tidak benar), memecahkan AES-128 akan memakan waktu sangat lama . Dengan 10.000 dari mereka berjalan, masih akan memakan waktu hampir selamanya . Jadi, keamanan bukanlah masalah di sini; mari kita perhatikan aspek kekuatannya.

Makalah ini menunjukkan (pada halaman 15) bahwa mengenkripsi blok dengan AES digunakan 351 pJ. Saya akan membandingkan ini nanti setelah berbicara tentang beberapa algoritma umum lainnya.

SIMON

Saya mengajukan pertanyaan tentang SIMON dan SPECK sebelumnya, yang patut dibaca. Di mana SIMON unggul dalam situasi di mana Anda perlu mengenkripsi sedikit data, sering . Makalah yang saya tautkan sebelumnya menyatakan bahwa SIMON 64/96 menggunakan 213 pJ untuk 64 bit, yang praktis ketika Anda hanya perlu mengirim 32 bit payload.

SIMON 64/96 secara signifikan lebih mudah dipatahkan daripada AES; makalah yang saya tautkan menyarankan operasi 2 ^63,9 , sehingga pengaturan CPU 10.000 kami dapat memecahkan enkripsi hanya dalam beberapa tahun , yang bertentangan dengan jutaan milenium.

Apakah itu penting?

Pada tingkat yang Anda rencanakan untuk ditransmisikan, jawabannya hampir pasti tidak ; penggunaan energi dari kriptografi akan sepenuhnya diabaikan. Untuk AES, Anda akan menggunakan 50 544 pJ per hari , jadi baterai AA karbon-seng murah dengan energi 2340 J akan bertahan jauh melampaui masa pakai perangkat . Jika Anda mengevaluasi kembali perhitungan dengan SIMON, Anda akan merasakan bahwa masa pakainya juga sangat panjang

Singkatnya, kecuali jika Anda mentransmisikan sangat sering, radio jauh lebih mempedulikan daya . Wikipedia mengutip penggunaan daya antara 0,01 dan 0,5 W. Jika Anda mentransmisikan selama 1 detik pada 0,01 W , Anda telah menggunakan lebih banyak daya daripada yang dilakukan AES sepanjang hari .

Untuk BLE, Anda mungkin baik-baik saja hanya mengandalkan keamanan default; BLE menggunakan AES-CCM secara default untuk keamanan link-layer :

Enkripsi dalam Bluetooth dengan energi rendah menggunakan kriptografi AES-CCM. Seperti BR / EDR, LE Controller akan melakukan fungsi enkripsi. Fungsi ini menghasilkan data terenkripsi 128-bit dari kunci 128-bit dan 128-bit plaintextData menggunakan cipher blok AES-128-bit seperti yang didefinisikan dalam FIPS-1971.

Ada beberapa kekhawatiran bahwa ada kelemahan keamanan dengan implementasi BLE tentang keamanan link-layer; ini bukan cacat pada AES; bukan Bluetooth SIG memutuskan untuk memutar mekanisme pertukaran kunci mereka sendiri di 4.0 dan 4.1 . Masalah ini sekarang diselesaikan di 4.2 sebagai Elliptical Curve Hellman-Diffie sekarang didukung.

— Aurora0001
sumber

1

"Pada prosesor 2,9 GHz, dengan asumsi setiap 'operasi' adalah 1 siklus CPU (mungkin tidak benar)" - mungkin dikompensasi oleh prosesor paralel (seperti GPU) yang berjalan pada kecepatan lebih rendah tetapi menghasilkan beberapa hasil per siklus [dan bahkan pada CPU IIRC Anda dapat mencapai hampir 1 operasi / jam pada inti tunggal]. Itu tidak mengubah urutan besarnya terlalu banyak.

— Maciej Piechotka

@MaciejPiechotka Itu poin yang bagus. Seperti yang Anda sarankan, urutan besarnya tidak boleh terlalu terpengaruh, dan pada skala yang sedang kami kerjakan, faktor 10 masih sangat tidak signifikan (10 ^ 33 hari vs 10 ^ 32 hari tidak akan menjadi masalah banyak sekali!).

— Aurora0001

1

Sistem simetris seperti AES bermasalah kecuali jika setiap perangkat memiliki kunci unik - jika tidak mengeluarkan hanya dari satu sampel yang dibedah akan merusak keseluruhan sistem.

— Chris Stratton

4

Kecuali Anda melakukan hardware yang dipercepat crypto, biaya daya kemungkinan besar karena Anda memiliki prosesor yang pada dasarnya dikalahkan untuk kebutuhan dasar (bukan crypto). Namun, dalam kebanyakan kasus penggunaan radio yang mengkonsumsi daya paling besar pula.

Karena Anda secara khusus mencari Bluetooth SOC, pertimbangkan BGM-111 , yang memiliki kripto akselerasi perangkat keras pada chip. Saya telah bermain dengan chip ini dan sepertinya bagus, meskipun saya belum melihat fungsi crypto secara khusus.

Rute lain, dan mungkin rute 'terbaik' jika Anda ingin memastikan tidak ada yang bisa mendapatkan kunci Anda, bahkan jika mereka membongkar perangkat. Ini termasuk chip TPM, seperti TPM OPTIGA , yang memiliki chip I2C dan SPI TPM yang didukung oleh kernel Linux.

Singkatnya, Anda akan membakar baterai tanpa crypto perangkat keras tertentu. Baik membangun papan dengan chip TPM, atau memilih SoC lebih modern yang memiliki perangkat keras kripto sudah built-in.

— Simon Munro
sumber

2

Pertanyaannya menyarankan SoC 2.5GHz dan mengirimkan nilai 32-bit setiap 10 menit. Jumlah perhitungan yang diperlukan untuk kripto benar-benar dapat diabaikan. Memang, bahwa SoC tampaknya dikuasai tugas. Tetapi untuk 32 bit setiap 10 menit, prosesor basis termurah yang dapat Anda temukan akan lebih dari cukup.

— Gilles 'SANGAT berhenti menjadi jahat'

3

Dengan interval 10 menit, tidak masalah berapa banyak waktu yang diperlukan untuk mengenkripsi, hanya berapa banyak energi . Anda harus melihat rincian implementasi seperti beban parasit untuk mengetahui apakah chip cepat yang melakukannya dalam 1 ms atau lambat yang membutuhkan 500 ms akan menang pada konsumsi daya, dengan asumsi keduanya secara efektif tidur ketika tidak sibuk. Mesin perangkat keras mungkin bisa lebih baik daripada perangkat lunak, tetapi untuk efisiensi energi - sehingga menyelesaikan pekerjaan lebih cepat tidak relevan.

— Chris Stratton