Industrial IoT adalah pemantauan, penjadwalan, dan otomatisasi sistem teknik fasilitas industri, bangunan, fasilitas bisnis. Sensor dari berbagai parameter, meter dan pengontrol mengumpulkan data dari objek-objek ini, misalnya, suhu dan kelembaban di ruang server, pembacaan meter air di gedung apartemen, tingkat karbon dioksida di kamar. Pengendali memproses informasi ini dan mengirim semuanya ke "cloud".
Wiren Board memproduksi pengontrol Linux untuk IoT industri. Perangkat mengumpulkan data dari sumur minyak dan cabang bank, memantau iklim mikro di server dan supermarket. Pengendali terintegrasi dengan sistem mitra perusahaan tingkat atas. Sistem mengotentikasi perangkat - mereka mengerti bahwa mereka berbicara dengan sensor mereka, dan bukan dengan milik orang lain, dan kemudian mereka memberikan otorisasi. Pada tahap ini, muncul masalah - ada ribuan pengendali, ratusan pelanggan, tetapi tidak ada sistem integrasi tunggal. Metode tradisional sederhana, seperti pasangan login / kata sandi, rentan terhadap serangan dan tidak nyaman untuk digunakan.
Oleh karena itu, perusahaan mengembangkan otentikasi dalam sistem tingkat atas menggunakan kunci perangkat keras - berdasarkan kriptografi asimetris standar menggunakan elemen yang dilindungi perangkat keras untuk menyimpan kunci. Sekarang sistem integrasi terpadu tidak diperlukan - otentikasi dan otorisasi dilindungi dan berfungsi di luar kotak.
Evgeny Boger akan memberi tahu Anda bagaimana melakukan ini: bagaimana mereka memilih "chip kripto", bagaimana mereka mengacaukannya ke perangkat keras dan Linux, bagaimana perpustakaan umum dan perangkat lunak dibuat untuk menjadi teman dengannya. Penekanan khusus pada penyebaran: pengenalan inisialisasi perangkat dalam produksi, pengenalan dukungan untuk berbagai perangkat lunak tingkat atas, termasuk dalam perangkat orang lain dan perangkat tertutup.
Tentang pembicara: Eugene Boger (
evgeny_boger ) - CTO dan salah satu pendiri Wiren Board. Terlibat dalam sistem tertanam dan, terutama, Linux tertanam.
Masalahnya
Untuk mulai dengan, apa yang kita lakukan dan dari mana masalah ini berasal. Kami di Wiren Board mendesain dan memproduksi peralatan di Rusia. Dulu disebut M2M, tapi sekarang - IOT industri. Ini adalah otomatisasi sistem teknik bangunan, pemantauan dan penjadwalan. Secara singkat, semua pekerjaan terlihat seperti ini: sensor dari berbagai parameter, aktuator, penghitung dan pengontrol (edge-computing atau IoT-gateway) mengumpulkan data yang berbeda dari objek, memprosesnya, mengeksekusi logika lokal, dan kemudian mengumpulkannya dalam satu pengiriman besar, pemantauan atau sistem kontrol .
Kami tidak memiliki seluruh ekosistem, tidak seperti beberapa pesaing. Kami memproduksi peralatan yang terintegrasi dengan beberapa sistem tingkat atas dari mitra kami. Ada banyak perusahaan mitra dan mereka berbagi tanggung jawab. Tanpa sarana teknis yang baik, integrasi tidak akan berfungsi - tidak bisa dinegosiasikan.
Ada dua solusi sederhana untuk menyelesaikan masalah ini. Yang pertama adalah
memberikan nama pengguna / kata sandi kepada klien , seperti yang dilakukan semua orang, dan yang kedua adalah untuk
menghasilkan dan menjahit "rahasia" di tempat kerja . Kedua opsi tidak cocok untuk kami - saya akan memberi tahu Anda alasannya.
Solusi sederhana
Solusi pertama adalah dengan mengeluarkan nama pengguna dan kata sandi untuk klien . Kita semua melakukannya hingga saat ini.
Untuk mengotentikasi perangkat yang mengirim data ke beberapa sistem, Anda dapat membuat kunci rahasia - login / kata sandi kondisional ("rahasia"). Ini akan umum pada pengontrol dan pada sistem tingkat atas yang mengumpulkan data dari beberapa pengontrol.
Sepasang nama pengguna / kata sandi ("rahasia" yang umum) harus diberikan kepada klien - perusahaan atau orang tersebut. Seseorang harus menghasilkan pasangan rahasia, mengirimkannya melalui email, mengautentikasi klien dengan nomor akun. Ini adalah prosedur standar - teknologi rendah.
Masalah Kami memiliki banyak sistem seperti itu. Klien kami, dan dia dapat mengirim data ke sistem mitra kami. Ini adalah interaksi yang kompleks antara semua pihak yang terlibat.
Selain masalah banyak sistem, ada yang lain.
- Pengiriman buruk dan pengiriman ke pelanggan .
- Login dan kata sandi disimpan di server . Jika kita juga menyimpan hash, ini akan sedikit melindungi kita dari kebocoran. Namun demikian, perasaan tidak menyenangkan muncul ketika kunci rahasia untuk semua pengontrol klien disimpan di server. Beberapa dari mereka dapat menangani tugas-tugas penting: penerangan di luar ruangan, pemantauan rig minyak.
- Sinkronisasi antar layanan .
- Kerugian pemulihan . Tidak jelas apa yang harus dilakukan jika kehilangan, ketika klien menghapus memori controller - dalam memori apa saya harus menulis? Anda harus mengulanginya lagi.
- Perlindungan terhadap penyalinan detail . Ada sistem pemantauan berbayar yang menyediakan layanan dan membebankan biaya berlangganan kepada pelanggan. Saya tidak ingin pelanggan akhir dapat memintas sistem melalui kami - bayar satu kali, tetapi gunakan dua.
Solusi kedua adalah menghasilkan dan menjahit "rahasia" dalam produksi . Ini merupakan peningkatan pada solusi sebelumnya.
Skemanya adalah ini: kami, sebagai produsen pengontrol, pra-menghasilkan nama pengguna dan kata sandi untuk semua orang, menjahitnya ke dalam sistem kami dan memasukkannya ke dalam peralatan. Login dan kata sandi dari peralatan tidak dapat dibaca atau diubah. Ini lebih baik dari opsi sebelumnya, karena tidak memerlukan interaksi antar orang.
Masalahnya . Semua masalah tetap ada, kecuali yang pertama, tetapi yang utama adalah
sinkronisasi antara layanan dan intranet . Ada banyak layanan dan tidak jelas bagaimana menyinkronkannya - karena ini, kami tidak dapat mengimplementasikan solusi kedua. Kami memiliki klien yang menggunakan peralatan di jaringan tertutup mereka. Kami merilis pengontrol baru, menjualnya ke klien, dan sistemnya ditutup. Sudah diatur, itu berfungsi sekali, dan sulit untuk menyampaikan "rahasia" lebih lanjut. Laporkan dalam batch? Semuanya rumit dalam organisasi, meskipun secara teknis sederhana.
Kedua solusi tidak cocok untuk kita. Karena itu, kami memutuskan untuk mengambil jalan yang berbeda. Tetapi sebelum itu mereka memutuskan untuk menguraikan tujuan dan sasaran bersama.
Tugas dan Tujuan
Tugas umum pertama.
Otentikasi Ini adalah cara untuk memahami siapa yang berbicara dengan sistem tingkat atas, siapa yang sebenarnya terhubung ke sistem pengiriman.
Otentikasi tidak memberikan atau membatasi hak akses, tetapi cara memahami siapa yang berbicara kepada kami.
Tugas mengirim data . Pengontrol kami adalah komputer Linux yang dirancang untuk tugas khusus. Kami membutuhkan mereka untuk mengirim data ke sistem tingkat atas, terhubung melalui VPN. Pada saat yang sama, kami ingin pengiriman berfungsi "di luar kotak" - tanpa pengaturan dan interaksi pelanggan kami dan pengguna akhir sistem dengan kami dan dengan pelanggan.
Tugas lainnya . Ini adalah koneksi yang andal, enkripsi saluran data, tetapi masalah terpisah adalah
otorisasi . Tugas otorisasi dikaitkan dengan layanan eksternal dan dibagi menjadi tiga bagian.
- Layanan pabrikan gratis . Berikan akses dengan nomor seri perangkat.
- Daftar putih nomor seri untuk layanan mitra kami - menautkan pembelian dan akses ke akun klien.
- Lisensi Izinkan atau tolak akses berdasarkan opsi yang ditentukan dalam sertifikat.
Tujuan adalah apa yang ingin kita capai ketika kita memecahkan masalah.
Penerbitan dan pengiriman ke pelanggan . Tanpa partisipasi orang - informasi dijahit oleh robot dalam produksi.
Kerugian pemulihan . Kami ingin tidak ada kehilangan detail rahasia sama sekali.
Pengiriman dari produksi ke layanan . Kami ingin melakukannya tanpa itu, sehingga Anda tidak perlu mengirimkan apa pun ke layanan. Saat meluncurkan peralatan baru, kami tidak ingin memperbarui basis data semua layanan yang harus mengotentikasi perangkat ini.
Penyimpanan di server . Dianjurkan untuk tidak menyimpan apa pun di sana.
Sinkronisasi antara layanan dan intranet . Disarankan juga untuk tidak menyinkronkan apa pun - karena kami tidak akan menyimpan apa pun.
Perlindungan terhadap penyalinan detail . Kami menginginkan sesuatu yang rahasia, untuk mana uang itu diambil, tidak mungkin untuk menyalin dan menerima secara gratis.
Tanda tangan digital bergegas untuk menyelamatkan
Tanda tangan digital elektronik (EDS) adalah teknologi di mana semuanya bekerja untuk kita.
Ini seperti tanda tangan biasa, hanya digital. EDS mudah diverifikasi, tetapi sulit dipalsukan. Kebenaran umum kriptografi, yang sudah berusia puluhan tahun.
Tanda tangan elektronik adalah sesuatu yang dapat dihitung dengan pesan jika Anda tahu kunci pribadi rahasia (kunci pribadi). Jika Anda mengetahui kunci publik (kunci publik), mudah untuk memverifikasi bahwa tanda tangan elektronik untuk pesan itu benar. Namanya jelas - masyarakat biasa memberi tahu semua orang, dan rahasianya hanya untuk orang yang menandatanganinya.
Semua tanda tangan dan kunci hanya angka.
Dalam kasus kami, ini adalah 32 byte data, yang bekerja pada "sihir" matematika. Matematika memastikan tanda tangan itu mudah diverifikasi, tetapi sulit dipalsukan.
Kami menggunakan tanda tangan ECDSA-256 + SHA-256:
e = HASH(m) - fungsi hash kriptografis mengubah pesan m menjadi angka e;
private key (dA) - nomor acak;
public key (QA) - dihasilkan dari kunci pribadi, tetapi tidak sebaliknya;
signature (r,s) = sign(private key, e) - tanda tangan;
verify(public key, signature, e) - verifikasi tanda tangan.
Otentikasi EDS. Upaya pertama
Apa yang dapat dilakukan untuk tugas kita menggunakan mekanisme rumit ini, yang bekerja dengan satu arah secara sederhana dan yang sulit lainnya?
Penerbitan dan pengiriman ke pelanggan . Kami menghasilkan kunci pribadi acak untuk setiap perangkat dalam produksi. Kami tidak memberi tahu siapa pun, karena kami bahkan tidak mengenalnya, dan kami menulis ke perangkat.
Pengiriman dari produksi ke layanan . Selanjutnya, kami hanya menggunakan kunci publik perangkat ini untuk otentikasi pada layanan. Pada layanan, kami hanya menyimpan daftar kunci publik alih-alih kata sandi.
Algoritma pemeriksaan kesehatan standar:
- layanan mengirim pesan acak
m ke controller;
- controller:
sign(private key, m) ;
- controller mengirim tanda tangan ke layanan;
- layanan:
verify(public key, signature, m) .
Satu-satunya hal yang kami putuskan dengan cara ini adalah bahwa kami
tidak lagi menyimpan "rahasia" umum pada layanan kami dalam bentuk terbuka atau dalam cache. Ini bukan yang kita inginkan.
Otentikasi EDS. Upaya kedua
Kami tidak ingin menyimpan sesuatu di layanan. Untuk mencapai ini, kami dapat memaksa perangkat kami untuk mengirim kunci publik mereka ke layanan.
Pada tahap terakhir, kami memecahkan dua masalah. Yang pertama - kami
memeriksa bahwa mereka memberikan kunci ke layanan . Kami memiliki kunci publik, yang berarti kami juga membuat kunci pribadi. Yang kedua - kami memastikan bahwa
perangkat memiliki kunci pribadi , yang terletak di suatu tempat di USB flash drive. Jika perangkat dapat menandatangani sesuatu, maka itu memiliki kunci pribadi.
Sekarang perangkat juga akan mengirim kunci publik ke layanan. Bagaimana memeriksa bahwa tidak ada yang mencegatnya, tidak memalsukannya, dan semuanya bekerja?
Memeriksa kunci publik . Kami menciptakan diri kami sendiri kunci publik lainnya. Dia akan menjadi kunci kita sebagai produsen. Ini adalah kunci root "kunci pribadi kunci + kunci publik". Dengan kunci rahasia root ini dalam produksi, kami akan menandatangani kunci publik perangkat dan kami akan menyimpan tanda tangan ini pada perangkat. Perangkat harus mengirim kunci publik dan tanda tangan kunci publiknya ke layanan. Sekarang layanan dapat memeriksa kunci publik perangkat. Jika ditandatangani dengan kunci privat root, maka kami menerbitkan kunci ini.
Hanya pabrikan - kami dapat membuat dan menyimpan tanda tangan pada perangkat, tetapi memeriksa semuanya.
Kami menerbitkan kunci publik di situs di bagian "Kontak". Siapa pun dapat mengambilnya dan memeriksa kunci publik perangkat yang mengirim perangkat ke layanan. Kemudian Anda dapat memverifikasi bahwa perangkat itu sendiri memiliki kunci privatnya sendiri.
Algoritma umum terlihat seperti ini.
(once) random root private key ;
factory: random device private key ;
factory: sign(root private key, device public key) = signature_1 ;
device->service: device public key + signature_1 ;
service: verify(root public key, signature_1, device public key)?
Hasil percobaan kedua
Kami memecahkan masalah dengan
pengiriman ke klien - informasi dijahit di lokasi produksi, dan
tidak ada yang perlu dipulihkan .
Penting bagi kami untuk memecahkan masalah
pengiriman "rahasia" ke layanan tingkat atas , karena semua yang perlu disimpan pada layanan adalah kunci publik pabrikan. Seluruh kunci adalah 33 byte. Dengan bantuan dan keajaiban matematika, Anda dapat terus membuat koneksi jabat tangan dan memverifikasi bahwa perangkat memiliki kunci pribadi yang sesuai.
Di server kami hanya menyimpan kunci pabrikan (root public key).
Kami tidak memiliki
sinkronisasi antara layanan dan intranet , yang telah kami bicarakan. Selain itu, kami tidak memiliki
perlindungan terhadap penyalinan detail .
Satu-satunya hal yang kami lupakan adalah
otentikasi . Perangkat mengirim kunci pribadi, dan kami memeriksa apakah kami melakukannya dan mengeluarkannya, dan memeriksa apakah perangkat itu memilikinya. Tapi kami tidak tahu perangkat apa ini, dan kami memproduksi ribuan perangkat.
Karena itu, kami menerapkan trik yang disebut "Sertifikat".
Otentikasi dan Sertifikat
Pada langkah ini, di semua keajaiban matematika dengan tanda tangan dan ceknya, kami menambahkan
informasi tambahan - sertifikat . Untuk melakukan ini, kami masuk ke pabrik tidak hanya kunci publik (kunci publik perangkat), tetapi kunci dengan informasi tambahan.
Informasi tambahan dalam kasus kami.
- Tanggal pembuatan dan pabrikan.
- Konfigurasi model dan perangkat keras.
- Nomor seri yang digunakan perangkat untuk mengautentikasi.
- Opsi: perangkat keras dan perangkat lunak. Konfigurasi yang berbeda mungkin tidak berbeda secara fisik satu sama lain, tetapi sertifikat akan berisi informasi tentang apa yang dibayar klien.
- Nama pelanggan dan nomor akun.
Kami akan menandatangani semua informasi ini bersama dengan kunci publik dengan kunci publik kunci-kunci produsen kami. Setelah itu, informasi akan masuk ke layanan dan mereka akan dapat memastikan bahwa itu benar. Karena ini adalah layanan kami dan mitra kami, mereka mempercayai kami.
Status Sasaran
Informasi juga dijahit di pabrik, dan
pengiriman ke layanan tidak diperlukan.
Di server kami hanya menyimpan kunci pabrikan.
Kerugian pemulihan . Kami menjahit semua informasi dari sertifikat ke dalam memori flash perangkat. Secara teoritis, ini dapat secara tidak sengaja atau sengaja dihapus, tetapi tidak ada rahasia dalam informasi ini dalam sertifikat. Bahkan tanda tangan itu sendiri bukan rahasia - ada kunci publik dan tanda tangan dengan kunci kami. Satu-satunya rahasia dalam sertifikat adalah volume penjualan perangkat dengan opsi berbeda.
Sertifikat dapat disimpan di pabrik dan dikirim ke klien jika hilang. Klien jarang secara spesifik menghapus area layanan memori. Biasanya kita melakukan ini selama prosedur pemulihan perangkat: perangkat tiba dari klien, benar-benar melewati inisialisasi, semuanya terhapus, diunduh lagi, dan sertifikat disalin dari database pabrik.
Kami tidak memiliki
pemulihan kerugian, perlindungan salinan, dan
sinkronisasi antara layanan .
Pada tahap otentikasi, kami menerima dan memverifikasi sertifikat. Kami memahami perangkat apa itu - kami tahu pabrikan, model, dan nomor seri, apa yang bisa dan tidak bisa ia lakukan.
Login
Sertifikat memungkinkan Anda menyimpan informasi untuk otorisasi.
Layanan pabrikan gratis . Mengetahui nomor seri perangkat, Anda dapat memberikan akses ke semua orang. Dalam layanan kami, kami memberikan akses ke semua pelanggan dasar kami.
Daftar putih nomor seri . Untuk layanan mitra kami, Anda dapat membuat tabel dengan daftar putih nomor seri: "Klien dengan mudah membeli dari kami dua pengendali dengan nomor seri seperti itu yang terkait dengan akunnya"
Lisensi Anda dapat menjual sesuatu di muka, dan kemudian mengizinkan atau menolak akses
berdasarkan opsi yang ditentukan dalam sertifikat - pengontrol dengan lisensi untuk sistem X.
Tidak ada basis umum antara layanan, pabrikan atau pabrikan sistem. Semuanya bekerja secara eksklusif pada informasi dari pengontrol yang ditandatangani oleh kami, sebagai produsen, ketika diotentikasi dalam sistem.
Sertifikat Menengah
Masalah teknis lain yang kami selesaikan di jalan. Dalam skema yang baru saja saya bicarakan, ada sertifikat root dari pabrikan - root private key. Secara fisik diperlukan setiap kali Anda membuat perangkat. Tetapi jika ada banyak perangkat, maka kunci ini membutuhkan akses konstan untuk lingkaran terbatas orang. Ini buruk, karena jika Anda kehilangan itu, Anda harus memperbarui kunci publik di semua layanan, dan itu tidak boleh sampai ke penyerang. Ini adalah masalah organisasi yang besar. Tapi ada solusinya.
Kami memperkenalkan kunci perantara ke sejumlah perangkat yang tidak begitu menakutkan untuk hilang.
Kami melakukan hal yang sama, hanya rantai yang lebih panjang.
Dengan sertifikat pabrikan, kami menandatangani kunci perantara. Secara fisik, ini adalah "flash drive", yang diberikan kepada mandor di pabrik selama sehari. Perangkat keras membatasi jumlah perangkat yang dapat ditandatangani oleh suatu tombol. Di tengah skema, kami menambahkan sertifikat perantara, jika tidak, tidak ada yang berubah.
Amankan keystore
Dalam semua ini, kami tidak memiliki
perlindungan yang cukup
untuk kunci pribadi perangkat - ini masih merupakan file yang terletak pada USB flash drive. Seorang penyerang dapat menyalinnya, tetapi kemungkinan besar mereka akan kehilangannya atau secara tidak sengaja membuka akses.
Dalam kasus ideal, alangkah baiknya untuk melindungi kunci pribadi perangkat dari penyalinan - memasukkannya ke dalam kotak hitam.
Kotak hitam melakukan 4 operasi:
- di dalam dirinya sendiri menghasilkan kunci berdasarkan permintaan, tetapi tidak memberi;
- memberikan kunci publik;
- Menandatangani pesan
- memverifikasi tanda tangan.
Untuk memverifikasi tanda tangan, Anda hanya perlu kunci publik, sehingga tiga operasi sudah cukup.Dalam pemahaman saya, ini harus menjadi solusi perangkat keras, sebaiknya terpisah dari prosesor. Ada beberapa opsi, yang terbaik adalah
prosesor crypto khusus di dalam SoC atau sebagai chip terpisah.
Opsi kotak hitam pertama yang kami ulas adalah
modul CAAM dalam prosesor NXP i.mx 6, 7, 8 yang kami gunakan. Masalahnya adalah itu diimplementasikan secara programatik dalam Boot ROM prosesor.
Ini mungkin mengandung bug yang dapat ditemukan dan bahkan dieksploitasi melalui fungsi prosesor lainnya. Beberapa tahun yang lalu, lubang ditemukan dalam modul ini yang memungkinkan untuk memotong verifikasi tanda tangan saat mengunduh firmware. Ini bukan fungsi yang kita butuhkan, tetapi sedimen tetap ada. Masalah lain adalah bahwa sulit untuk mengimpor prosesor dengan modul ini ke Rusia, mereka perlu mengisi dokumen.
Karena itu, kami mengambil chip yang terpisah. Saya mengakui dengan jujur, saya mengandalkan fakta bahwa jika kita tidak bisa membawanya ke Rusia, kita akan menemukan sesuatu - chip itu kecil, harganya $ 1. Tapi semuanya berjalan baik - mereka menemukan chip
Microchip ATECC , yang sudah memiliki semua kertas.
Microchip ATECC608A
Ini adalah chip kecil terpisah yang harganya satu sen. Chip terhubung melalui I2C - dua "kaki" prosesor, yang juga dapat Anda bagikan dengan perangkat lain. Chip ini memiliki pinout standar. Kami menggunakan chip di versi pertama peralatan dan hanya menyoldernya di atas chip lain dengan protokol dan pinout yang sama, karena standar.
Chip dapat melakukan apa yang kita butuhkan dari chip seperti itu: baca tanda tangan, kunci toko, dan banyak lagi.
Karakteristik
- 16 slot kunci;
- dapat membaca tanda tangan ECSDSA, hash, MAC, dan mengenkripsi AES, dapat DH;
- memiliki penghitung angka acak dan penghitung kriptografi;
- Lampiran: SOIC-8, DFN6;
- protokol: I2C, kawat tunggal;
- ~0.7$@1000pcs.
Cara bekerja dengan sirkuit mikro
Ada
dokumentasi yang layak
untuk itu , tetapi di bawah NDA. Jika Anda segera menulis ke gamma.spb.ru, maka mereka akan memberikannya kepada Anda dalam 2 minggu. Jika di perusahaan lain - setelah 3 bulan. Kami menulis kepada dua perusahaan, dan ketika kami telah melakukan segalanya, dealer Microchip lain menjawab kami.
Ada beberapa catatan aplikasi dan lebih buruk dari rata-rata. Ada
perangkat lunak di GitHub - perpustakaan dengan HAL. Lucu - dokumentasinya ada di bawah NDA, dan perangkat lunak yang tertulis di dalamnya ada di GitHub. Perangkat lunak ini tidak mendukung Linux, tetapi mendukung Raspberry Pi dan Atmel MK - ini sedikit berbeda. Para pengembang percaya bahwa pada semua peralatan hanya ada satu bus I2C, misalnya, kakinya disebut seperti pada Raspberry Pi.
Ada
integrasi dengan
OpenSSL - tidak bekerja dengan baik, tetapi itu berhasil.
Tidak ada contoh di Linux dan tidak ada pekerjaan dengan
personalisasi .
Kustomisasi chip
Personalisasi adalah sakit kepala terbesar dengan chip.
Masalahnya adalah chip dapat melakukan banyak hal. Ini memiliki 16 slot di mana 16 kunci disimpan: data pengguna, atau kunci publik, atau penyimpanan sementara untuk slot lain - ada banyak opsi.
Anda perlu entah bagaimana membatasi akses ke slot, dan ada juga banyak opsi konfigurasi: batasi dengan kata sandi, dengan otentikasi di slot lain, pada saat akses ke pabrik.
Di tabel, jenis kunci, akses baca dan tulis, hubungan antara slot - SlotConfig, KeyConfig.Dalam topeng bit (16 bit) dari setiap kunci yang kita gunakan, ada angka yang berbeda di mana-mana.
Yang paling menyedihkan adalah bahwa zona konfigurasi adalah satu kali, yang menetapkan fungsi slot. Kami mengacaukan 50 chip sebelum melakukan semuanya dengan benar. Chip hanya berfungsi
setelah mengunci konfigurasi . Secara terpisah, ada
kunci untuk slot individualTidak ada dokumentasi dalam contoh atau perangkat lunak. Ada dokumentasi untuk bit individu, tetapi semuanya rumit di sana. Dalam semua contoh dari Microchip tertulis: "Unduh blok seperti itu, dan entah bagaimana itu akan bekerja untuk Anda, seperti dalam contoh pengiriman data ke Amazon."
Butuh banyak waktu, tetapi dalam prosesnya mereka membuat utilitas yang keren.
Utilitas Atecc-util
Ini adalah utilitas konsol yang dapat melakukan sebagian besar fungsi chip dan memungkinkan Anda untuk bekerja sedikit lebih mudah. Ini tersedia
di GitHub di bawah lisensi MIT.
Utilitas menggunakan CryptoAuthLib. Dia tahu cara bekerja lebih ramah dengan zona konfigurasi, dia tahu cara bekerja dengan SHA, MAC, ECDSA, DH. Antarmukanya ramah batch, karena kami telah menciptakan utilitas untuk digunakan dalam skrip. Fakta bahwa seseorang dapat menyebabkannya adalah fitur sampingan. Utilitas dapat membuat daftar - rencana perintah: "Pertama, mempersonalisasikan zona ini, kemudian tuliskan kunci seperti itu."
Contoh memanggil utilitas cukup mudah dibaca oleh manusia.
atecc - b 10 - c 'serial' - c 'read-config /tmp/config.dump'
Utilitas ini dibangun di bawah Linux, di bawah AMD64 - itu ada dalam paket Debian.
Alat personalisasi lainnya
Kami memiliki pelat Excel untuk membaca bit. Jika Anda menunjukkan kepada kami pemindaian NDA dengan Microchip, kami akan memberikannya kepada Anda.
Kami membahas semuanya dengan tes, karena ada banyak opsi ketika Anda dapat melupakan sedikit dan beberapa perintah layanan akan membaca kunci pribadi Anda. Tes menguji perangkat nyata. Mereka beralih ke sirkuit mikro dan memeriksa konfigurasi yang benar pada perangkat: dapatkah slot ini dibaca, dapatkah tanda tangan dibuat?
Sejalan dengan bit, kami membuat daftar jaminan bahwa perangkat ini harus memuaskan, dan memeriksa bagaimana semuanya bekerja. Kami menggunakan
kerangka kelelawar - hal yang sangat menarik. Ini terlihat seperti ini.
Daftar tes sebagai contoh. Yang atas dilewati, tetapi yang lebih rendah tidak.Pengaturan dalam perangkat
Bagi kami sendiri, kami hanya menggunakan dua slot untuk tugas yang saya bicarakan. Di kedua kami menyimpan kunci pribadi perangkat. Perbedaannya adalah bahwa yang pertama dikaitkan dengan
sertifikat permanen , yang dikeluarkan pada tahun 1970 selama 200 tahun.
Hal ini disebabkan oleh fakta bahwa dalam IoT waktu tidak selalu disinkronkan. Infrastruktur sertifikat melibatkan verifikasi keabsahan sertifikat. Jika sinkronisasi pada perangkat rusak, maka beberapa layanan penting mungkin gagal, misalnya, VPN.
Oleh karena itu,
satu slot tidak terbatas - permanen . Ini dihasilkan sekali dan tidak berubah sepanjang umur perangkat. Untuk kunci ini, sertifikat dihasilkan selama 200 tahun - untuk jaringan tertutup.
Slot lain sedang diperbarui. Masa berlaku sertifikat maksimum adalah satu tahun. Ini dilakukan untuk berjaga-jaga seandainya ada sesuatu yang dikompromikan. Kunci perangkat yang dapat diperbarui secara pribadi dihasilkan saat periode validitas sertifikat perangkat berakhir. Digunakan untuk otentikasi di jaringan terbuka, diperbarui sebulan sekali atau kurang, bersama dengan sertifikat.
Untuk pengguna, kami menghasilkan berbagai kombinasi , termasuk beberapa slot untuk kunci ECDSA pribadi. Pengguna dapat membuat kunci mereka di slot terpisah jika mereka tidak mempercayai kunci pribadi kami. Untuk ini, Anda hanya perlu mempercayai Microchip. Pengguna dapat membaca tanda tangan, melakukan enkripsi - kami memberikan semua yang dapat dilakukan chip.
Sejauh ini, sayangnya, belum ada yang menggunakan, tapi kami harap begitu.
Infrastruktur: Kunci Menengah
Saya sudah mengatakan bahwa pada beberapa titik kami menerapkan sertifikat perantara agar tidak bersinar dengan sertifikat root yang tidak boleh hilang. Dia tidak pernah muncul di pabrik.
Sertifikat perantara fisik adalah chip ATECC508A. Ini sedikit berbeda dari 608, tetapi pada 508 ada fungsi yang berguna untuk kunci, tetapi pada 608 tidak lagi ada.
Chip terhubung melalui adaptor USB-I2C. Ini adalah USBISP dengan firmware mungil-usb-i2c - seorang programmer yang dapat di-flash ke USB-I2C bridge. Sertifikat perantara menandatangani sertifikat perangkat dengan kunci privat mereka.
Dua fitur dari rangkaian mikro ternyata berguna bagi kami.
Slot perlindungan kata sandi perangkat keras . Chip dapat diprogram untuk membaca tanda tangan hanya jika dua kondisi terpenuhi:
- ketika perangkat macet di komputer;
- kata sandi dimasukkan.
Kami memberikan mandor kepada produksi kunci menengah dan kata sandi untuk sejumlah pengontrol. Karenanya, Anda perlu mencuri kunci dan kata sandi untuk mendapatkan akses. Kami mendapat kesempatan ini secara gratis, tetapi meningkatkan keamanan sistem.
Batas perangkat keras pada jumlah penggunaan . Penghitung kriptografi di dalam hanya dapat meningkat. Ketika mencapai batas yang telah ditentukan sekali, sirkuit mikro tidak menandatangani apa pun.
OpenSSL pada klien
Mari kita pertimbangkan bagaimana semuanya bekerja pada klien. Kami memiliki OpenSSL pada controller. Kami tidak menemukan apa pun - ini TLS biasa, PKI biasa. Kami juga membutuhkan perpustakaan klien. Pada sebagian besar perangkat lunak Linux, ini digunakan untuk koneksi yang aman.
Kami mengambil kode dari Microchip, menambahkannya sedikit, mendukung OpenSSL yang baru
1.1. Akibatnya, ia tahu cara bekerja dengan kunci perangkat keras - perangkat keras mendukung kata sandi untuk kunci pribadi.
Itu terlihat seperti ini.
openssl req -new -engine ateccx08 -keyform engine -key ATECCx08:00:04:C0:00 -subj "/CN=wirenboard-AP6V5MDG" -out device AP6V5MDG.csr
Ini adalah panggilan ke OpenSSL reguler dan instruksi untuk menggunakan modul engine yang sesuai. Kuncinya diatur di sini: alamat, model, dan dua byte terakhir adalah jumlah slot yang digunakan. Semuanya ditransmisikan seolah-olah itu adalah file kunci, tetapi itu bukan file - Anda harus masuk ke perangkat.
SSL di server
SSL apa pun berfungsi di server, termasuk OpenSSL. Tidak diperlukan modifikasi dan custom build di sisi server. Semua yang diperlukan di server adalah
untuk dapat memeriksa rantai bundel sertifikat (sertifikat perangkat + sertifikat menengah), dan
menyimpan kunci publik kami , yang kami publikasikan di situs - Wiren Board ROOT CA.
TLS standar mengatakan bahwa kedua pihak harus saling mengautentikasi. — — . — handshake.
: . , . letsencrypt SSL, , .
, — MQTT.
MQTT: mosquitto
IBM. .
Mosquitto — , , Linux. , OpenSSL engine ( ) «keyfile», .
, 20 .
bundle.
.
mosquitto_sub -h mqtt.wirenboard.com -p 8884 -cert /etc/ssl/device/device_bundle.crt.pem --key 'engine:ateccx08:ATECCx08:00:04:C0:00' --capath /etc/ssl/certs/ -t /# -v
. —
-cert . bundle- — .
--key . .
,
--capath , . SSL-, letsencrypt.
.
root@wirenboard-AXXVJI62:~# cat /etc/mosquitto/conf.d/bridge-hw.conf connection wb_devices_cloud.wirenboard-AXXVJI62 address contactless.ru:8884 bridge_capath /etc/ssl/certs/ bridge_certfile /etc/ssl/device/device_bundle.crt.pem bridge_keyfile engine:ateccx08:ATECCx08:00:04:C0:00 notifications true notification_topic /client/wirenboard-AXXVJI62/bridge_status topic/# both 1 ""/dient/wirenboard-AXXVJI62
Mosquito- .
Mosquitto — .
per _listener_settings true listener 8884 0.0.0.0 cafile/etc/mosquitto/certs/WirenBoard_Root_CA.crt certfile /etc/letsencrypt/live/contactless.ru/fullchain.pem keyfile/etc/letsencrypt/live/contactless.ru/privkey.pem require.certificate true use_identity_as_username true password_file /etc/mosquitto/passwd.conf allow_anonymous false acl_file /etc/mosquitto/ad.conf :~$ cat /etc/mosquitto/acl.conf pattern write /client/%u/# pattern read /client/%u/#
— .
- Root CA letsencrypt- — . .
- Mosquitto.
username MQTT.
- , , , (CN) wirenboard-AXXVJI62, , .
per_listener_settings: , / (>1.5.5).
MQTT- Wiren Board IoT Cloud Platform.
Openvpn
OpenVPN , , . , .
OpenVPN
, . , : bundle, , engine.
openvpn --capath /etc/ssl/certs/ --cert /etc/ssl/device/device_bundle.crt.pem --key engine:ateccx08:ATECCx08:00:04:C0:00
letsencrypt.
ca /etc/openvpn/WirenBoard_Root_CA.crt cert /etc/letsencrypt/live/vpn1.wirenboard.com/fullchain.pem key /etc/letsencrypt/live/vpn1.wirenboard.com/privkey.pem
— . - .
Nginx
. Nginx , , , SSL. nginx web-, reverse-proxy. — nginx.
nginx , HTTP-, . , : Common Name, , . , 400.
ssl_client_certificate WirenBoard_Root_CA.crt; ssl_verify_client on;
nginx . — , HTTP. Linux- nginx , SSL, , OpenSSL.
wget , bash , HTTP- TLS . 10 .
server { listen 8080; location / { proxy_pass https://example.com; proxy_ssl_name example.com; proxy_ssl_server_name on; proxy_ssl_certificate/etc/ssl/device/device_bundle.crt.pem; proxy_ssl_certificate_key engine:ateccx08;ATECCx08:00:04:C0:00; } }
Wiren Board 6 , . , .
web- cloud.wirenboard.com OpenVPN . Grafana InfluxDB, MQTT. saymon.info — (MQTT) .
, - , , Grafana, MQTT-, , , . — .
, , :
— OpenSSL ,
— . !
InoThings Conf 2019 . YouTube- 2019 . Telegram. , , IoT.