Internet Hal-Hal Saya: Kastil Tamu (Bagian 2)

Hai GT! Semua dengan kedatangan dan masa lalu!
Saya melanjutkan kisah tentang bagaimana saya menghubungkan kunci pintu ke Internet. Mulai di sini .
Terima kasih banyak untuk semua komentarnya. Benar-benar ada solusi yang sudah jadi, tetapi ada juga sejumlah nuansa yang tidak memungkinkan saya untuk menggunakannya. Apartemen masih bukan hotel, jadi kami segera memberhentikan kastil hotel khusus. Kunci kunci, antena untuk NFC, agar tidak menakuti tetangga, kami juga tidak mempertimbangkan. Tidak ada kartu, token, atau media fisik lainnya yang dapat digunakan, dapat dipahami bahwa tidak ada cara untuk memindahkannya ke tamu sebelum ia membuka pintu.
Kevo, August atau Lockitron tidak dapat digunakan, karena mereka didasarkan pada jenis kunci Amerika (deadbolt), yang tidak terpasang dengan baik pada pintu baja setebal 65-70 mm. Pilihan kami adalah CISA elektromekanis untuk pintu lapis baja, dengan harga sekitar 500 euro (belum dibeli, karena mahal).
Dan yang paling penting, saya ingin melakukan sesuatu dengan tangan saya sendiri, bukan untuk menjadi egois demi arus hobi.


Biarkan saya mengingatkan Anda bahwa pengontrol kunci terletak jauh di belakang NAT di jaringan rumah lokal, dan karena itu tidak masuk akal untuk meningkatkan server web di Arduin, tidak mungkin untuk mencapai itu dari Internet. Server ditulis dalam Python menggunakan kerangka Twisted, berjalan di Linux di tempat lain di mana ada alamat IP nyata, dan controller terhubung ke sana dan menunggu perintah.

Sekarang saya ingin berbicara tentang logika kerja dan kriptografi.
Saya tidak menemukan sesuatu yang mengenkripsi lalu lintas untuk Arduina, karena komunikasi kastil dan server akan melalui saluran terbuka dengan lalu lintas yang tidak dienkripsi.
Dalam prototipe pertama, saya menggunakan MD5, sekarang saya mengubahnya menjadi SHA-1, di sini di perpustakaan Cryptosuite ini . Ini mengkonsumsi lebih sedikit memori, dan sudah ada fungsi HMAC yang sudah jadi.
Kuncinya adalah kata sandi hingga 30 karakter ASCII, disimpan dalam memori EEPROM controller.
Dalam prototipe pertama, kata sandi yang sama disimpan secara eksplisit di server, yang tentu saja bukan keamanan. Prototipe kedua membutuhkan dua kata sandi. Yang pertama adalah untuk mengotentikasi kunci ketika terhubung ke server, Anda tidak dapat membuka kunci dengan kata sandi ini, diperlukan agar hanya kunci yang benar yang dapat terhubung ke server.
Kunci terhubung ke server dan pertama-tama memberitahu pengenalnya. Server memeriksa dalam database jika ada kunci seperti itu, dan jika ada, ia mengirimkan urutan ASCII yang dihasilkan secara acak sebagai tanggapan. Kunci “menandatanganinya” dengan kata sandi dan mengirim hash kembali. Server membandingkan hash yang diterima dengan apa yang dihitung sendiri, dan jika cocok, itu akan mengotorisasi pengontrol yang terhubung sebagai "kunci".
Kalau tidak, koneksi diatur ulang.
Kata sandi kedua sudah menjadi kunci digital, tidak disimpan di server.
Ini berfungsi sebagai berikut: aplikasi pengguna panggilan melalui fungsi SOAP di server, menunjukkan ID kunci dan perintah yang ingin ia kirim kepadanya. Akibatnya, fungsi mengembalikan ID permintaan. Server meneruskan perintah ini ke controller, controller mengirimkan urutan ASCII yang dihasilkan secara acak sebagai respons, dan menunggu respons "benar" selama beberapa detik. Selanjutnya, aplikasi pengguna perlu mendapatkannya dari server, melalui SOAP yang sama dengan ID permintaan, menandatanganinya dengan kunci digital dan mengirimkannya kembali.
Kontroler membandingkan hash yang diterima dengan yang dihitung sendiri dan jika cocok, ia mengeksekusi perintah yang sebelumnya diterima, yang dilaporkan ke server.
Waktu untuk mengkonfirmasi perintah dibatasi hingga 2 detik, jika tidak ada respons yang diterima selama waktu ini, pengontrol mengabaikan perintah yang sebelumnya diterima. Jika hash tidak cocok, perintah ini juga diabaikan.
Jadi, saya mencoba melindungi diri dari serangan “man in the middle”, yang sangat mudah untuk mengatur kabel penyedia saya. Koneksi ada sederhana, tidak ada kata sandi dan sertifikat, cukup untuk memotong twisted pair di perisai, memerasnya di kedua sisi, tancapkan ke jaringan dari sisi apartemen dengan alamat IP dari server perintah, meniru kunci di ujung lain (saya juga menulis skrip untuk emulasi pada python untuk debugging ), setelah mengatur "firewall" seperti itu dengan penyadapan.
Dalam hal ini, menurut saya, kastil itu ternyata cukup terlindungi.
Bahkan meretas server perintah dan mencuri basis datanya dengan kata sandi untuk otorisasi oleh kunci tidak akan banyak masalah, karena mereka tidak dapat membuka kunci.
Tetap hanya berurusan dengan para tamu. Ini adalah persyaratan No. 6-8 dari artikel pertama.
Keyboard, proksi, RFID, dan NFC bukan opsi, alasan di atas tulis. Tetapi hampir semua orang memiliki smartphone dan semua smartphone memiliki Bluetooth, pilihannya jelas!

Dalam prototipe pertama, seorang tamu dikaitkan dengan satu kode akses tunggal. Dalam database server untuk kode ini disimpan ID kunci, tanggal dan waktu awal dan akhir akses tamu, well, bidang teks untuk nama tamu yang dapat dibaca manusia.
Tamu datang ke kastil, meluncurkan aplikasi mobile di smartphone-nya, mengirimkan kode akses via Bluetooth ke controller, sebuah pesan datang dari controller ke server yang menyatakan bahwa seorang tamu telah mendekatinya dengan kode akses seperti itu. Server memeriksa terhadap database, dan jika tamu yang benar tiba pada waktu yang tepat di tempat yang tepat, mengirimkan perintah untuk membuka kunci. Bahkan, alih-alih kode akses yang jelas, tamu akan mengirim hash HMAC yang ditandatangani dengan "stempel sementara" (representasi string waktu Unix dibagi dengan 30 dengan bagian fraksional dibuang). Server untuk verifikasi membuat permintaan ke database dengan pilihan semua kode akses yang berlaku saat ini untuk kunci yang diberikan, kemudian beralih melalui itu dan menghitung HMAC yang sama untuk mereka, jika menemukan kecocokan, mengirimkan perintah untuk membuka,jika pencarian kode akses berakhir sebelum kecocokan dapat ditemukan, respons negatif dikirim ke kunci pada upaya untuk membukanya.
Masalahnya adalah bahwa kunci digital untuk otorisasi tersebut harus disimpan di server.
Saya harus mempersulit otorisasi "tamu" untuk prototipe kedua. Kode akses tamu sekarang terdiri dari dua kunci, sebut saja "server" dan "pribadi". Server diperlukan untuk membuat akun tamu di server, dan pribadi untuk membuka kunci itu sendiri. Ruang server akan secara eksplisit disimpan di server, dan dari ruang privat hanya akan ada hash, tetapi bukan yang sederhana, tetapi HMAC dengan kunci digital untuk kunci.
Sekarang sesi otorisasi tamu terlihat seperti ini:
1. Aplikasi tamu meneruskan kunci "server" ke controller (seperti pada prototipe pertama hash-nya) dan
2. Server memeriksa dengan cara yang sama, tetapi alih-alih perintah terbuka mengirim hash kunci pribadi
3. Pengontrol membandingkan hash kunci pribadi yang diterima dari server dengan yang dihitung secara independen dan jika cocok, kunci terbuka.
Dengan demikian, server tidak menyimpan apa pun yang bisa membuka kunci. Ini tidak akan berfungsi untuk menghasilkan hash yang diinginkan tanpa mengetahui kunci digital.
Bluetooth yang sama juga digunakan untuk akses "master" tanpa Internet. Pengontrol menerima perintah melalui itu, merespons dengan kode satu kali, yang harus ditandatangani dengan kunci digital yang benar selama 2 detik.
Melalui itu, saya ingin membuat pengaturan dasar controller. Pemilik menekan tombol khusus pada pengontrol, setelah itu ia mulai menerima serangkaian perintah yang diperluas, seperti pengaturan ID kunci, kunci rahasia, alamat port server, pengaturan jaringan, dll. Tetapi di Adruin memori habis dan sketsa tidak cocok.
Pada akhirnya, demonstrasi singkat dari karya tersebut.

Source: https://habr.com/ru/post/id382677/