0fc

Obrolan Web Discreet End-to-End dengan Kriptografi Kuat

0FC memungkinkan Anda menjalankan obrolan grup dalam browser yang aman dengan ruang obrolan terisolasi, memiliki beberapa fitur khusus:

• End-to-end untuk ruang obrolan tertentu: Server tidak dapat melakukan yang lebih baik dari serangan DOS
• Server dianggap zona tepercaya minimal, semua operasi penting terjadi di sisi klien:
  • Kunci fana yang digunakan untuk melindungi lalu lintas ruang obrolan dihasilkan di dalam browser pemilik kamar dan disebarkan ke sisanya
  • Token rahasia, digunakan untuk memberikan akses ke ruang obrolan, dihasilkan di sisi klien (meskipun bagian dari verifikasi terjadi di sisi server)
• Selama berbagi kunci, setiap pesan layanan dilindungi oleh kunci, berasal dari data acak lebih dari satu pihak
• Pesan keluar dienkripsi dan dikirim hanya sekali (semua anggota kamar berbagi kunci simetris yang sama)
• Token akses rahasia digunakan sekali (dihapus setelah konfirmasi kunci)

0FC dimulai sebagai pengujian taman bermain untuk beberapa kasus penggunaan tema/webthemis yang canggih, tetapi menjadi cukup menarik untuk melepaskannya sebagai gumpalan kode yang terpisah.

PENTING: Untuk dianggap sangat aman, 0FC harus divalidasi oleh pihak ketiga dan digunakan dengan benar. Tidak ada alat kriptografi yang harus dipercaya tanpa audit pihak ketiga. Sebelum itu terjadi (jika pernah terjadi), ada deskripsi protokol di akhir dokumen ini, yang memungkinkan Anda untuk melihat cara kerja dalam 0FC dan membuat penilaian Anda sendiri. Kita sendiri menyadari beberapa ancaman yang jarang terjadi tidak terkait dengan kriptografi, tetapi lebih pada cara kerja browser (lihat bagian model ancaman posting blog).

Backend 0FC ditulis dalam Python, front-end berbasis webthemis, sehingga hanya bekerja di browser berbasis Google Chrome saja (belum).

0FC dilisensikan melalui lisensi Apache 2. Kami akan senang jika Anda membangun sesuatu berdasarkan kode ini dan protokol 0FC; Jika Anda ingin bantuan dengan ini, hubungi kami.

Baca posting blog untuk mempelajari lebih lanjut tentang 0FC dan teknologi yang mendasari.

Menginstal dan menggunakan

0FC terdiri dari dua komponen: server dan klien.

Server 0FC

Server 0FC membutuhkan:

• Python 3.4
• Pip
• Themis (membangun dan memasang)

Pertama, Anda perlu menginstal dependensi Python:

 pip install -r requirements.txt

Setelah melakukannya, Anda dapat menjalankan server:

 python3 server.py

Server secara default akan mendengarkan port 5103. Untuk mengubah port add -p <port> :

 python3 server.py -port 333

Klien 0FC

Klien 0FC sudah dikompilasi di / statis / folder. Ingatlah bahwa ia memiliki kunci server yang hardcoded; Jika Anda meregenerasi kunci, Anda perlu membangun kembali klien (lihat di bawah).

Menggunakan 0FC

... cukup jelas. Anda dapat membuat kamar baru, menghasilkan token dan mengundang orang untuk bergabung, atau memasukkan token yang ada untuk memasuki ruangan.

Membangun kembali klien 0FC

Jika Anda ingin mengkompilasi ulang klien 0FC (objek PNACL) sendiri, inilah yang harus Anda lakukan:

1. Untuk membangun objek PNACL, Anda perlu menginstal NaCl SDK dan membuat variabel lingkungan PNACL_ROOT dengan jalur ke file SDK yang diinstal.
2. Repositori klon 0FC dengan submodule dari GitHub:

 git clone https://github.com/cossacklabs/0fc
cd 0fc
git submodules update --init --recursive

3. Bangun webthemis:

 cd webthemis
make

4. Bangun Modul PNACL 0FC:

 cd ..
make

Anda selesai!

Arsitektur

0FC terdiri dari 2 komponen klasik: klien dan server.

Klien bertanggung jawab atas:

• Menampilkan UI kepada pengguna
• Semua fungsi kriptografi dan manajemen kepercayaan
• Komunikasi dengan server relay

Server bertanggung jawab atas:

• Melayani UI + PEXE (Modul PNACL) untuk klien melalui http get
• Menjalankan layanan Relay Websocket, yang menerima pesan dan menyampaikannya kepada semua orang.

Over WebSocket Link, klien berbicara dengan server melalui objek Securession Themis, yang menyediakan keamanan transportasi tingkat tinggi. Kunci server hardcoded menjadi klien, jadi kepercayaan ditetapkan berdasarkan korelasi antara kunci server nyata dan kunci server yang diumpankan ke klien di binari.

Dalam tautan pengamanan ini, pesan terenkripsi SecureCell dikirimkan.

Protokol & Skema

Penciptaan kamar

• Pemilik kamar menghasilkan pasangan kunci [client]
• Pemilik kamar menghasilkan kunci kamar (yang akan digunakan untuk mengenkripsi pesan di ruangan) [client]
• Pemilik kamar meminta server untuk membuat ruangan, menerima ID kamar sebagai respons [client] + [server]

Mengundang orang lain (berbagi kunci)

• Pemilik kamar menghasilkan token [client]
• Pemilik kamar mengirimkan undangan oleh beberapa saluran out-of-band (seperti email), yang mencakup Token Undangan, kunci publik dan ID kamarnya [client]
• Pengguna menerima token undangan [client]
• Pengguna menghasilkan pasangan kunci [client]
• Pengguna menghasilkan kunci gabungan acak [client]
• Pengguna mengirim pesan yang aman ke pemilik kamar melalui server dengan kunci gabungan terenkripsi [client]
• Server dapat memeriksa ACL apakah undangan ini valid dan meneruskan pesan ke pemilik kamar [server]
• Pemilik Kamar Membatalkan BRAPS Bergabung dengan Kunci [client]
• Pemilik Kamar Mengirim Kunci Kamar Tertutup Ke Pengguna Melalui Server Menggunakan Kunci Bergabung sebagai Kunci Master dan Undang Token Sebagai Konteks [client]
• Server dapat memeriksa ACL apakah respons ini valid dan meneruskan pesan ke pengguna [server]
• Pengguna membuka kunci kamar [client]
• Pengguna mengirimkan pesan tertutup konfirmasi kepada pemilik kamar. [client]
• Pemilik, Setelah memeriksa Pengguna Konfirmasi menandatangani kunci publiknya dan mengirim ke server [client] + [server]
• Server memeriksa tanda tangan dan menganggap pengguna sebagai ditambahkan ke ruang obrolan [server]
• Setelah mengundang token yang telah digunakan, itu dibuang oleh pemilik kamar [server]

Pertukaran pesan

• Anggota kamar bertukar pesan menyegelnya dengan kunci kamar. Server hanya meneruskan pesan terenkripsi tanpa memiliki akses ke kontennya. [server]

Manajemen kunci

• Keypair dihasilkan untuk setiap kamar [client]
• KeyPair disimpan di browser persisten penyimpanan [client]
• Browser Penyimpanan Persisten Dienkripsi dengan Sel Aman (Segel Mode), kunci yang berasal dari kata sandi pengguna, input saat bergabung dengan obrolan [client]

Komunikasi server

• Klien berkomunikasi dengan server menggunakan sesi aman temhem [server]
• Kunci publik tepercaya server hardcoded di klien [client]
• Server tidak melakukan otentikasi klien, secara otomatis mempercayai setiap kunci klien SS (ini adalah langkah yang jelas untuk mengeras jika keamanan lebih penting daripada di mana -mana dan anonimitas) [server]

Rotasi kunci

• Setiap 100 pesan (dapat dikonfigurasi) yang dikirim dan diterima, pemilik kamar menghasilkan kunci baru, mengenkripsi dengan kunci lama dan mengirim pesan khusus [client]
• Server menegakkan pesan seperti itu mungkin hanya berasal dari pemilik kamar [server]

Orkestrasi Kamar

• Daftar anggota dikelola untuk setiap kamar sebagai daftar kunci publik (+indikasi siapa pemilik kamar) [server]
• Setiap kamar memiliki pemilik kamar (awalnya, pencipta kamar) [server]
• Pemilik kamar bertanggung jawab atas rotasi utama [client]

Riwayat obrolan

• Server memungkinkan klien untuk mengambil riwayat obrolan sejak keberangkatan terakhir mereka untuk anggota yang telah online dan tahu kunci sebelum rotasi [server]
• Server memungkinkan klien untuk mengambil riwayat obrolan sejak rotasi kunci terakhir untuk anggota baru [server]

Ingin tahu lebih banyak?

Baca posting blog kami dengan beberapa latar belakang tentang pengembangan 0FC dan berbagai pertimbangan keamanan.