Pada messenger dengan enkripsi ujung ke ujung (E2E), pengguna bertanggung jawab atas kunci mereka. Ketika dia kehilangan mereka, dia terpaksa mengatur ulang akunnya.

Menyetel ulang akun berbahaya. Anda menghapus kunci publik dan dalam semua percakapan menjadi orang asing kriptografis. Anda perlu mengembalikan identitas Anda, dan dalam hampir semua kasus ini berarti pertemuan pribadi dan perbandingan "nomor keamanan" dengan masing-masing kontak. Seberapa sering Anda benar-benar menjalani tes seperti itu, yang merupakan satu-satunya perlindungan dari MiTM?

Bahkan jika Anda serius dengan nomor keamanan, Anda hanya melihat banyak mitra obrolan setahun sekali di sebuah konferensi, jadi Anda mandek.

Tetapi ini jarang terjadi, bukan?

Seberapa sering reset terjadi? Jawab: di sebagian besar aplikasi obrolan E2E sepanjang waktu.

Dalam messenger ini, Anda menjatuhkan kriptografi dan mulai mempercayai server: (1) setiap kali Anda beralih ke telepon baru; (2) setiap kali lawan bicara beralih ke telepon baru; (3) ketika mengatur ulang ke pengaturan pabrik telepon; (4) ketika lawan bicara melakukan reset ke pengaturan pabrik; (5) setiap kali Anda menghapus dan menginstal ulang aplikasi, atau (6) ketika seseorang yang Anda ajak bicara hapus instalan dan instal ulang aplikasi itu. Jika Anda memiliki puluhan kontak, reset akan dilakukan setiap beberapa hari.

Reset terjadi secara teratur sehingga aplikasi ini berpura-pura bahwa ini bukan masalah:


Sepertinya kami memiliki peningkatan keamanan! (Tapi tidak juga)

Apakah ini benar-benar TOFU?

Dalam kriptografi, istilah TOFU ("kepercayaan pada penggunaan pertama") menggambarkan permainan kesempatan ketika dua pihak berbicara untuk pertama kalinya. Alih-alih bertemu secara langsung, mediator bertanggung jawab untuk masing-masing pihak ... dan kemudian, setelah para pihak mempresentasikan diri mereka, masing-masing pihak dengan hati-hati memonitor kunci untuk memastikan tidak ada yang berubah. Jika kunci telah berubah, masing-masing pihak memberikan alarm.

Jika kunci dari host jarak jauh berubah dalam SSH dalam situasi seperti itu, itu tidak akan "hanya bekerja", tetapi menjadi benar-benar berperang:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
00:11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee:ff
Please contact your system administrator.
Add correct host key in /Users/rmueller/.ssh/known_hosts to get rid of this message.
Offending RSA key in /Users/rmueller/.ssh/known_hosts:12
RSA host key for 8.8.8.8 has changed and you have requested strict checking.
Host key verification failed.

Inilah perilaku yang benar. Dan ingat: ini bukan TOFU jika memungkinkan Anda untuk bekerja lebih jauh dengan peringatan kecil. Anda akan melihat tengkorak raksasa dengan tulang bersilang .

Tentu saja, pengirim pesan instan ini akan mengklaim bahwa semuanya baik-baik saja, karena pengguna diperingatkan. Jika dia mau, dia bisa memeriksa nomor keamanannya. Itu sebabnya kami tidak setuju:

1. Verifikasi tidak dilakukan karena terlalu sering terjadi.
   
2. Periksa payah.
   
3. Bahkan survei sepintas tentang teman-teman kita yang peduli tentang keamanan menunjukkan bahwa tidak ada yang khawatir dengan tes ini.
   
4. Jadi itu hanya mempercayai server dan mempercayai SMS (well, well!) Lagi, lagi dan lagi .
   
5. Akhirnya, aplikasi ini seharusnya tidak berfungsi seperti ini. Apalagi saat berganti perangkat. Kasus normal yang biasa dapat ditangani dengan lancar dan aman, dan semakin jarang situasinya, semakin buruk tampilannya. Sebentar lagi, tunjukkan solusi Keybase.

Berhenti menyebutnya TOFU

Ada serangan yang sangat efektif. Misalkan Hawa ingin masuk ke percakapan Alice dan Bob yang ada dan berdiri di antara mereka. Alice dan Bob telah berhubungan selama bertahun-tahun, telah lama berlalu di TOFU.

Eve hanya membuat Alice berpikir bahwa Bob membeli telepon baru:

Bob (Eve): Hei, hei!

Alice: Yo, Bob! Sepertinya Anda memiliki nomor keamanan baru.

Bob (Eve): Ya, saya membeli iPhone XS, telepon yang bagus, sangat senang dengannya. Mari bertukar nomor keamanan di RWC 2020. Hei, apakah Anda memiliki alamat Caroline Anda saat ini? Saya ingin mengejutkannya saat saya di San Francisco.

Alice: Saya tidak bisa membandingkan, Android 4 hidup! Ya, Cozy Street 555.

Oleh karena itu, sebagian besar kurir terenkripsi tidak mungkin mendapatkan kepatuhan TOFU. Ini lebih seperti TADA - kepercayaan setelah menambahkan perangkat. Ini adalah masalah nyata, bukan fiktif, karena ini menciptakan peluang untuk implementasi jahat dalam percakapan yang sudah ada sebelumnya. Dalam TOFU nyata, pada saat seseorang tertarik pada percakapan Anda, mereka tidak akan dapat menyusup ke dalamnya. Dengan TADA, ini dimungkinkan.

Dalam obrolan kelompok, situasinya bahkan lebih buruk. Semakin banyak orang dalam obrolan, semakin sering akun akan diinstal ulang. Di perusahaan yang hanya terdiri dari 20 orang, ini akan terjadi kira-kira setiap dua minggu, menurut perkiraan kami. Dan setiap orang di perusahaan harus bertemu orang ini. Secara pribadi Kalau tidak, seluruh obrolan dikompromikan oleh satu mol atau hacker.

Solusi

Apakah ada solusi yang baik yang tidak menyiratkan kepercayaan pada server kunci pribadi? Kami pikir ada: dukungan nyata untuk beberapa perangkat. Ini berarti bahwa Anda mengelola rantai perangkat yang mewakili identitas Anda. Saat Anda menerima perangkat baru (telepon, laptop, komputer desktop, iPad, dll.), Ia menghasilkan pasangan kunci sendiri, dan perangkat Anda sebelumnya menandatanganinya. Jika Anda kehilangan perangkat, maka "hapus" dari salah satu yang tersisa. Secara teknis, penghapusan seperti itu adalah penarikan kembali, dan dalam hal ini ada juga semacam pembalikan kunci yang terjadi secara otomatis.

Akibatnya, Anda tidak perlu mempercayai server atau bertemu langsung ketika teman bicara atau kolega menerima perangkat baru . Demikian pula, Anda tidak perlu mempercayai server atau bertemu langsung ketika menghapus perangkat, jika itu bukan yang terakhir. Satu-satunya waktu Anda perlu melihat peringatan adalah ketika seseorang benar-benar kehilangan akses ke semua pengaturannya. Dan dalam hal ini, Anda akan melihat peringatan serius, sebagaimana mestinya:


Khususnya jelek maksimal

Akibatnya, lebih sedikit akun yang direset dan diinstal ulang. Secara historis, di Keybase, jumlah total add-on dan ulasan perangkat adalah sepuluh kali jumlah debit akun (Anda tidak perlu mengambil kata kami untuk itu, ini tersedia untuk umum di pohon Merkle kami). Tidak seperti messenger lain, kami dapat menunjukkan peringatan yang benar-benar menakutkan ketika Anda berbicara dengan seseorang yang baru saja menginstal ulang kunci.

Manajemen perangkat adalah operasi rekayasa yang kompleks yang telah kami sempurnakan beberapa kali. Perangkat yang ada menandatangani kunci publik perangkat baru dan mengenkripsi semua data rahasia penting untuk kunci publik perangkat baru. Operasi ini harus dilakukan dengan cepat (dalam satu detik), karena kita berbicara tentang jangkauan perhatian pengguna. Akibatnya, Keybase menggunakan hierarki kunci, sehingga saat mentransfer 32 byte data rahasia dari perangkat lama, perangkat baru dapat melihat semua data kriptografi yang berumur panjang (lihat FAQ di bawah untuk lebih jelasnya). Ini mungkin tampak sedikit mengejutkan, tetapi itulah titik kriptografi . Itu tidak memecahkan masalah manajemen rahasia Anda, itu hanya membuat sistem lebih terukur.

Gambaran lengkap keamanan

Sekarang kita dapat merumuskan empat sifat keamanan dasar untuk aplikasi Keybase:

1. kunci rahasia yang tahan lama tidak pernah meninggalkan perangkat yang membuatnya
   
2. dukungan multi-perangkat penuh meminimalkan penurunan akun
   
3. pencabutan kunci tidak dapat ditunda atau dibatalkan dengan jahat
   
4. kerahasiaan langsung menggunakan pesan waktu singkat

Dua yang pertama tampaknya bisa dimengerti. Yang ketiga menjadi penting dalam desain di mana penarikan perangkat diharapkan dan dianggap normal. Sistem harus memeriksa apakah server jahat tidak dapat menunda ulasan perangkat, yang kami tulis sebelumnya .

Lihat artikel kami tentang pesan singkat untuk informasi lebih lanjut tentang fitur keamanan keempat.

Banyak kriptografi baru, apakah semuanya dilaksanakan dengan benar?

Keybase tidak pernah mengimplementasikan fungsi keamanan dasar sebelumnya dan bahkan tidak pernah menggambarkannya dalam artikel ilmiah. Kami harus membuat sendiri beberapa protokol kriptografi. Untungnya, ada banyak algoritma kriptografi yang tidak resmi, standar, dan banyak digunakan untuk situasi apa pun. Semua kode klien kami terbuka . Secara teoritis, siapa pun dapat menemukan kesalahan desain atau implementasi. Tapi kami ingin menunjukkan struktur internal dan menyewa firma audit keamanan terbaik untuk analisis penuh.

Hari ini kami menyajikan laporan NCC Group dan sangat didorong oleh hasilnya. Keybase menghabiskan lebih dari $ 100.000 untuk mengaudit, dan NCC Group mempekerjakan pakar keamanan dan kriptografi tingkat atas. Mereka menemukan dua kesalahan penting dalam implementasi kami, dan kami segera memperbaikinya. Bug ini hanya dapat muncul jika server kami bertindak jahat. Kami dapat memastikan bahwa mereka tidak akan bertindak seperti itu, tetapi Anda tidak memiliki alasan untuk mempercayai kami. Itu masalahnya!

Kami percaya tim NCC telah melakukan pekerjaan dengan sangat baik. Hormati waktu yang mereka habiskan untuk sepenuhnya memahami arsitektur dan implementasi kami. Mereka menemukan kesalahan halus yang menarik perhatian pengembang kami, meskipun kami baru-baru ini menonton bagian basis kode ini berulang kali. Kami menyarankan Anda melihat laporan di sini , atau buka FAQ kami.

Faq

Beraninya kamu menyerang produk XYZ?

Kami telah menghapus referensi ke produk tertentu dari artikel.

Apa lagi

Kami bangga bahwa Keybase tidak memerlukan nomor telepon dan secara kriptografi dapat memeriksa Twitter, HackerNews, Reddit, dan pengidentifikasi Github jika Anda mengenal seseorang.

Dan ... segera ... akan ada dukungan untuk Mastodon.

Bagaimana dengan serangan pengalihan ponsel?

Banyak aplikasi yang rentan terhadap serangan pengalihan. Eve berjalan ke kios di pusat perbelanjaan dan meyakinkan Bob, operator seluler, untuk meneruskan nomor telepon Bob ke perangkatnya. Atau dia meyakinkan perwakilan melalui telepon. Sekarang, Hawa dapat mengotentikasi pada server messenger, mengklaim bahwa dia adalah Bob. Hasilnya terlihat seperti contoh kami Alice, Bob dan Hawa lebih tinggi, tetapi Hawa tidak perlu menembus server apa pun. Beberapa aplikasi menawarkan "pemblokiran registrasi" untuk melindungi dari serangan ini, tetapi secara default mereka mengganggu.

Saya mendengar Keybase mengirim beberapa kunci pribadi ke server?

Pada hari-hari awal (2014 dan awal 2015), Keybase bekerja sebagai aplikasi web PGP, dan pengguna dapat memilih fungsi untuk menyimpan kunci PGP pribadi mereka di server kami, dienkripsi dengan frasa sandi (yang tidak diketahui Keybase).

Pada bulan September 2015, kami memperkenalkan model Keybase baru. Kunci PGP tidak pernah digunakan (dan tidak pernah digunakan) dalam obrolan Keybase atau sistem file.

Bagaimana obrolan lama langsung muncul di ponsel baru?

Di beberapa aplikasi lain, perangkat baru tidak melihat pesan lama, karena menyinkronkan pesan lama melalui server bertentangan dengan kerahasiaan langsung. Aplikasi Keybase memungkinkan Anda untuk menunjuk pesan tertentu - atau seluruh percakapan - sebagai “sesaat”. Mereka dihancurkan setelah waktu tertentu dan dienkripsi dua kali: sekali menggunakan kunci enkripsi obrolan yang berumur panjang, dan yang lainnya menggunakan kunci sesaat yang sering berubah. Dengan demikian, pesan singkat memberikan kerahasiaan langsung dan tidak dapat disinkronkan antara telepon.

Pesan non-tetap tetap sampai pengguna secara eksplisit menghapusnya dan menyinkronkan E2E dengan perangkat gaya Slack baru, hanya dengan enkripsi! Karenanya, saat Anda menambahkan seseorang ke tim atau menambahkan perangkat baru untuk Anda sendiri, pesan tidak terblokir.

Lebih lanjut tentang sinkronisasi di paragraf berikutnya.

Ceritakan tentang PUK!

Dua tahun lalu, kami memperkenalkan kunci untuk pengguna (PUK) . Setengah publik dari PUK diiklankan di sigchain publik pengguna. Setengah rahasia dienkripsi untuk kunci publik setiap perangkat. Ketika Alice sedang mempersiapkan perangkat baru, perangkat lamanya tahu setengah rahasia dari PUK-nya dan kunci publik dari perangkat baru. Ini mengenkripsi setengah rahasia PUK untuk kunci publik dari perangkat baru, dan perangkat baru mengunduh ciphertext ini melalui server. Perangkat baru mendekripsi PUK dan dapat langsung mengakses semua pesan obrolan yang berumur panjang.

Setiap kali Alice mengingat suatu perangkat, ia mengganti PUK-nya, sehingga semua perangkatnya, kecuali yang terakhir dipanggil, menerima PUK baru.

Skema sinkronisasi ini secara fundamental berbeda dari sistem PGP Keybase awal. Di sini, semua kunci yang terlibat memiliki 32 byte entropi sejati, mereka tidak putus dengan kekerasan jika terjadi peretasan server. Benar, jika Curve25519 atau PRNG dari Go rusak, maka semuanya rusak. Tetapi sinkronisasi PUK tidak membuat asumsi kriptografi signifikan lainnya.

Bagaimana dengan obrolan grup besar?

tL; Grup dr memiliki rantai tanda tangan diaudit sendiri untuk mengubah peran, menambah dan menghapus anggota.

Peneliti keamanan menulis tentang serangan pengguna hantu pada obrolan grup. Jika klien pengguna tidak dapat secara kriptografis memverifikasi keanggotaan grup, maka server jahat dapat menanamkan spyware dan mol di obrolan grup. Keybase memiliki sistem yang sangat andal dalam bentuk fungsi khusus kelompok , yang akan kami tulis di masa depan.

Bisakah Anda bicara tentang NCC-KB2018-001?

Kami percaya bahwa bug ini adalah temuan paling signifikan dari audit NCC. Keybase secara aktif menggunakan struktur data yang tidak dapat diubah untuk melindungi dari ambiguitas server dari penambahan saja. Dalam kasus bug, server yang jujur ​​mungkin mulai menghindar: "Sudah saya katakan sebelumnya, tetapi bug terjadi, maksud saya B". Tetapi klien kami memiliki kebijakan umum untuk tidak memberikan fleksibilitas seperti itu kepada server: mereka memiliki pengecualian hard-kode jika ada bug.

Baru-baru ini, kami juga memperkenalkan Sigchain V2 : sistem ini memecahkan masalah skalabilitas yang kami tidak memprediksi dengan benar di versi pertama. Sekarang klien lebih ekonomis dengan data kriptografi yang mereka tarik dari server, hanya menerima satu tanda tangan dari ujung rantai tanda tangan, daripada tanda tangan dari setiap tautan perantara. Dengan demikian, pelanggan telah kehilangan kesempatan untuk pergi dalam siklus mencari hash tanda tangan tertentu, tetapi kami sebelumnya menggunakan hash ini untuk mencari tautan rantai buruk dalam daftar pengecualian kode-keras ini. Kami sedang mempersiapkan untuk rilis Sigchain V2, melupakan detail ini terkubur di bawah beberapa lapisan abstraksi, sehingga sistem hanya mempercayai bidang dari respons server.

Setelah NCC menemukan kesalahan ini, perbaikannya cukup sederhana: mencari pengecualian hard-coded dengan hash chainlink daripada hash signature chainlink. Klien selalu dapat secara langsung menghitung hash ini.

Kami juga dapat mengaitkan kesalahan ini dengan kompleksitas tambahan yang diperlukan untuk mendukung Sigchain V1 dan Sigchain V2 secara bersamaan. Klien modern menulis tautan Sigchain V2, tetapi semua klien harus mendukung tautan lawas v1 untuk waktu yang tidak terbatas. Ingat bahwa pelanggan menandatangani tautan dengan kunci pribadi mereka untuk setiap perangkat. Kami tidak dapat mengoordinasikan semua pelanggan menimpa data historis dalam waktu yang wajar, karena klien ini dapat offline.

Bisakah Anda bicara tentang NCC-KB2018-004?

Seperti pada 001 (lihat di atas), kami dikecewakan oleh kombinasi tertentu dari dukungan simultan untuk solusi usang dan optimisasi, yang tampaknya penting karena kami memperoleh lebih banyak pengalaman bekerja dengan sistem.

Di Sigchain V2, kami mengurangi ukuran rantai dalam byte untuk mengurangi bandwidth yang dibutuhkan untuk mencari pengguna. Penghematan ini sangat penting pada ponsel. Dengan demikian, kami menyandikan tautan rantai dengan MessagePack , bukan JSON , yang memberikan penghematan yang baik. Pada gilirannya, pelanggan menandatangani dan memverifikasi tanda tangan pada rantai ini. Para peneliti di NCC telah menemukan cara rumit untuk membuat "tanda tangan" yang terlihat seperti JSON dan MessagePack pada saat yang sama, yang mengarah ke konflik. Kami tanpa sadar memperkenalkan ambiguitas penguraian kode ini selama optimisasi ketika kami mengganti parser JSON dari parser Go standar ke parser yang lebih efisien. Parser cepat ini dengan diam-diam melewatkan sekelompok sampah sebelum menemukan JSON yang sebenarnya, yang termasuk fitur serangan polyglot ini. Kesalahan diperbaiki dengan verifikasi input tambahan .

Di Sigchain V2, kami juga menerima saran Adam Langley bahwa penandatangan mendahului paket mereka dengan tanda tangan oleh awalan garis konteks dan byte \0 sehingga verifier tidak menjadi bingung dengan niat penandatangan. Di sisi verifikasi ide awalan konteks ini, ada kesalahan yang dapat menyebabkan serangan polyglot lainnya. Kami dengan cepat memperbaiki kekurangan ini dengan daftar putih .

Setelah memperbaiki kedua bug, server menolak beban berbahaya serangan polyglot, sehingga eksploitasi kerentanan ini hanya mungkin dilakukan dengan bantuan server yang dikompromikan.

Di mana dokumentasinya?

https://keybase.io/docs

Dalam beberapa bulan mendatang, kami akan mencurahkan lebih banyak waktu untuk mengerjakan dokumentasi.

Anda dapat mengetahui lebih lanjut tentang pernyataan ini oleh NCC: "Namun, seorang penyerang dapat menolak untuk memperbarui sigchain atau memutar kembali sigchain pengguna ke keadaan sebelumnya dengan memotong tautan selanjutnya dalam rantai"

Keybase menggunakan banyak-banyak struktur data publik yang tidak dapat diubah, append yang memaksa infrastruktur server untuk menangkap satu representasi sebenarnya dari pengidentifikasi pengguna. Kami dapat menjamin penarikan perangkat dan penghapusan anggota grup sedemikian rupa sehingga server yang dikompromikan tidak dapat memutar kembali. Jika server memutuskan untuk menampilkan tampilan yang tidak konsisten, penyimpangan ini menjadi bagian dari catatan publik yang tidak dapat diubah. Pelanggan keybase atau auditor pihak ketiga dapat mendeteksi ketidakcocokan setiap saat setelah serangan. Kami percaya bahwa jaminan ini jauh melampaui jaminan produk yang bersaing dan hampir optimal, dengan mempertimbangkan keterbatasan praktis ponsel dan pelanggan dengan daya komputasi yang terbatas.

Sederhananya, Keybase tidak dapat menemukan tanda tangan orang lain. Seperti server mana pun, ia dapat menyimpan data. Tetapi pohon Merkle transparan kami dirancang untuk menyimpannya dalam waktu yang sangat singkat, dan selalu dapat ditemukan.

Bagaimana Keybase menangani pengaturan ulang akun?

Ketika pengguna Keybase benar-benar kehilangan semua perangkat mereka (yang bertentangan dengan menambahkan yang baru atau kehilangan beberapa), mereka perlu mengatur ulang. Setelah mengatur ulang akun, pengguna pada dasarnya baru, tetapi ia memiliki nama pengguna yang sama. Dia tidak dapat menandatangani "instruksi reset" karena dia telah kehilangan semua kuncinya. Jadi sebagai gantinya, server Keybase melakukan pernyataan tidak bisa dihapus ke pohon Merkle, yang berarti mengatur ulang. Klien memaksakan kemustahilan untuk mengembalikan instruksi ini. Dalam artikel mendatang, mekanisme spesifik akan dijelaskan secara rinci.

Pengguna ini harus menambahkan kembali verifikasi identitas (Twitter, Github, apa pun) dengan kunci baru.

Bisakah server cukup menukar daun pohon Merkle seseorang untuk mengiklankan serangkaian kunci yang sama sekali berbeda?

Penulis NCC sedang mempertimbangkan server Keybase yang bermusuhan yang benar-benar mengubah daun pohon Merkle, menggantikan set kunci Bob yang sebenarnya dengan set palsu yang benar-benar baru. Server penyerang memiliki dua opsi. Pertama, dia dapat memotong keadaan dunia dengan menempatkan Bob di satu garpu, dan yang ingin dia mainkan di yang lain. Kedua, ia dapat "menipu" dengan menerbitkan versi pohon Merkle dengan set kunci Bob yang benar dan versi lain dengan set palsu. Pengguna yang secara teratur berinteraksi dengan Bob akan mendeteksi serangan ini, karena mereka akan memverifikasi bahwa versi riwayat Bob yang sebelumnya diunduh adalah awalan yang valid dari versi baru yang mereka unduh dari server. Validator pihak ketiga yang memindai semua pembaruan Keybase juga akan melihat serangan ini. Jika Anda menulis validator Keybase pihak ketiga yang kami sukai, kami dapat menawarkan hadiah yang signifikan. Lihat max pada Keybase. Jika tidak, kami berharap dapat segera merencanakan pembuatan validator otonom.

Bisakah Anda percaya apa yang saya baca sampai akhir?

Baca atau gulir ke bawah saja?