Penjelasan Struktur Internal iMessage

 (jjtech.dev)
3 poin oleh GN⁺ 2023-12-06 | 1 komentar | Bagikan ke WhatsApp
  • iMessage menggunakan APNs bukan sekadar sebagai saluran notifikasi, tetapi sebagai basis transmisi dua arah, dan melalui IDS menggabungkan pendaftaran/pengambilan kunci publik serta persiapan pengiriman pesan
  • Setelah terhubung ke APNs, perangkat menerima push token lalu memfilter topik iMessage com.apple.madrid untuk menentukan cakupan pesan yang akan diterima
  • Pendaftaran IDS memerlukan token autentikasi Apple ID, sertifikat jangka panjang, unggahan kunci publik enkripsi dan penandatanganan, serta pengiriman validation data, sehingga dirancang agar sulit dipakai di perangkat non-Apple
  • Enkripsi pesan terbagi menjadi format lama pair dan format baru pair-ec, dan pair-ec menyediakan forward secrecy berbasis pre-key yang mirip Signal
  • Pengirim dapat mengirim payload terenkripsi secara terpisah untuk tiap penerima atau menggabungkannya, tetapi agar perangkat terbaru bisa mendekripsi, kunci AES harus menyertakan tag HMAC

APNs sebagai basis pengiriman iMessage

  • Salah satu lapisan dasar iMessage adalah Apple Push Notification Service(APNs)
  • APNs berada pada lapisan yang sama dengan layanan yang dipakai aplikasi App Store untuk menerima notifikasi dan pembaruan secara real-time bahkan saat aplikasinya tertutup
  • Dalam iMessage, APNs berfungsi bukan hanya untuk menerima notifikasi, tetapi juga sebagai layanan dua arah untuk pengiriman pesan
  • Saat perangkat terhubung ke APNs, perangkat akan menerima push token
    • Token ini digunakan untuk merutekan notifikasi ke perangkat tertentu
    • Secara teknis token ini berbeda dari token yang diterima lewat API application:didRegisterForRemoteNotificationsWithDeviceToken:
    • Token dari API tersebut memiliki cakupan per aplikasi dan diminta dengan bundle ID aplikasi, tetapi tujuannya serupa
  • Saat mengirim push notification ke perangkat, topic pesan juga harus ditentukan
    • Topic biasanya terlihat seperti Bundle ID
    • Topic untuk iMessage adalah com.apple.madrid
  • Saat perangkat terhubung ke APNs, perangkat mengirim filter message untuk memberi tahu server pesan apa yang ingin diteruskan
    • Server APNs juga disebut APNs Courier
    • Filter message dapat memuat daftar topic menurut status
    • Status topic dapat berupa enabled, opertunistic, paused, atau disabled

Kueri IDS yang berjalan di atas APNs

  • APNs tidak hanya dipakai untuk pengiriman pesan iMessage yang sebenarnya
  • Melalui lapisan pseudo-HTTP di atas APNs, IDS dapat mengirim kueri dan menerima respons
  • Untuk terhubung ke APNs, diperlukan sertifikat klien yang diterbitkan oleh Albert activation server

Alur autentikasi IDS dan Apple ID

  • IDS berperan sebagai server kunci untuk iMessage dan juga dipakai layanan lain seperti FaceTime
  • IDS tampaknya merupakan singkatan dari IDentity Services, tetapi disebutkan tidak ada konfirmasi resmi
  • Karena iMessage menggunakan enkripsi end-to-end, kunci publik setiap peserta harus dipertukarkan dengan aman
  • Langkah pertama dalam pendaftaran IDS adalah memperoleh token autentikasi
    • API memerlukan nama pengguna dan kata sandi Apple ID
  • 2FA kemudian ditambahkan ke API IDS dalam bentuk adaptasi belakangan
    • Metode lawas menempelkan kode 2FA langsung ke kata sandi
    • Metode GrandSlam menggunakan “Anisette data” untuk membuktikan bahwa ini perangkat yang sama sehingga tidak perlu memasukkan ulang kode 2FA
    • Setelah itu, pengguna bisa memperoleh Password Equivalent Token(PET) untuk digunakan seperti kata sandi dan kode 2FA
  • Setelah mendapatkan token autentikasi, token tersebut harus segera ditukar dengan sertifikat yang lebih tahan lama
    • Sertifikat ini memungkinkan pendaftaran IDS, tetapi dengan sendirinya belum cukup untuk melakukan pencarian kunci

Pendaftaran IDS dan validation data

  • Langkah terpenting dalam penyiapan IDS adalah registration
  • Dalam registration, kunci publik enkripsi dan kunci penandatanganan diunggah ke server kunci
  • Berbagai client data tentang kemampuan yang didukung perangkat juga ikut diunggah
  • Permintaan IDS registration memerlukan blob biner bernama “validation data”
    • Ini adalah mekanisme verifikasi Apple untuk mencegah perangkat non-Apple menggunakan iMessage
  • Pembuatan validation data menggunakan informasi seperti serial number, model, dan UUID disk perangkat
    • Tidak semua validation data bisa diperlakukan sama
    • Mirip Hackintosh, usia akun dan “score” menentukan apakah serial yang salah masih bisa dipakai atau apakah muncul galat “customer code”
  • Biner yang menghasilkan validation data dibuat dengan obfuscation yang kuat
    • pypush mengatasi hal ini dengan mengemulasikan biner yang di-obfuscate memakai custom mach-o loader dan Unicorn Engine
    • pypush menyediakan properti perangkat seperti serial number ke biner yang diemulasikan melalui berkas data.plist

Pencarian kunci dan session token

  • Setelah pendaftaran IDS, perangkat akan menerima identity keypair
  • Keypair ini dipakai untuk melakukan pencarian kunci publik
  • Dengan memberikan akun yang ingin dicari, akan diperoleh daftar “identities”
    • Setiap identity mewakili satu perangkat yang terdaftar pada akun tersebut
    • Daftar ini memuat informasi penting seperti public key, push token, dan session token
  • Session token diperlukan untuk mengirim pesan ke perangkat
    • Token ini berfungsi sebagai bukti bahwa pencarian baru saja dilakukan
    • Session token memiliki masa berlaku
    • Hanya akun yang melakukan permintaan pencarian yang bisa menggunakannya, sehingga tidak dapat dibagikan

Pesan masuk dan format enkripsi

  • Untuk menerima pesan, cukup filter koneksi APNs ke com.apple.madrid dan kirim active state packet
  • Format enkripsi pesan masuk bergantung pada capability yang diumumkan saat pendaftaran IDS dan versi iOS perangkat pengirim
    • Format lama sebelum iOS 13 adalah pair
    • Format baru adalah pair-ec
  • Format pair lebih banyak didokumentasikan dan lebih mudah diimplementasikan
  • Tidak seperti pair-ec yang lebih baru, pair tidak menyediakan forward secrecy dengan “pre-keys”
  • Pesan dapat didekripsi berdasarkan berbagai paper dan implementasi pypush
  • Verifikasi tanda tangan pesan bersifat opsional, tetapi penting untuk membuat klien yang aman

Cara pengiriman dan hal yang perlu diperhatikan saat implementasi

  • Pengiriman pesan pada dasarnya adalah proses kebalikan dari penerimaan
  • Pesan dapat dikirim satu per satu untuk tiap penerima
  • Ada juga cara menggabungkan banyak penerima dan payload terenkripsi untuk masing-masing penerima ke dalam satu bundle besar
    • Dalam kasus ini APNs akan memisahkannya
  • Pesan dikirim ke semua peserta percakapan
    • Termasuk ke perangkat lain milik akun sendiri
  • Hal yang sering terlewat saat mengirim adalah bahwa kunci AES tidak sepenuhnya acak
    • Pada kunci AES terdapat HMAC yang ditempelkan sebagai tag
    • Jika memakai kunci AES yang sepenuhnya acak, perangkat terbaru akan gagal mendekripsi pesan

Implementasi terkait dan materi referensi

Bacaan terkait

1 komentar

 
GN⁺ 2023-12-06
Opini Hacker News

  • Sepertinya Apple akan mulai mengunci iMessage dengan attestation (DeviceCheck)
    Namun ada masalah bahwa perangkat lama akan membutuhkan pembaruan perangkat lunak

    • Sebagian hal itu sebenarnya sudah dilakukan
      Saat membuat “validation data”, informasi seperti nomor seri perangkat, model, dan UUID disk digunakan; seperti pada Hackintosh, bergantung pada umur akun dan “skor”, hasilnya bisa menentukan apakah nomor seri yang tidak valid bisa dipakai atau justru muncul galat “customer code”
      Galat “customer code” pada dasarnya adalah prompt kegagalan attestation dari Apple, jadi kalau sudah terkena, pengguna harus menghubungi Apple Support untuk membuka kunci Apple ID
      Pelanggan normal bisa melewatinya dengan mudah, misalnya dengan menyetujui login dari perangkat yang sah, tetapi pengguna Hackintosh mengakali proses ini dengan teknik bypass
      https://old.reddit.com/r/hackintosh/comments/gij9rt/getting_...
    • Apple sudah menyediakan pembaruan keamanan untuk perangkat iOS sekitar 5 tahun terakhir, jadi tampaknya tidak akan terlalu lama sampai pembaruan tersebar ke hampir semua perangkat iOS yang benar-benar masih dipakai
    • Untuk perangkat lama, yaitu perangkat tanpa TPM, sepertinya yang dibutuhkan bukan pembaruan perangkat lunak, melainkan pembaruan perangkat keras
    • Sepertinya BBM dulu bekerja dengan cara seperti itu, tapi saya tidak yakin
      Ini terdengar seperti fitur yang setidaknya semestinya masuk ke Lockdown Mode Apple, bukan sekadar bagian dari keamanan sistem operasi secara keseluruhan
    • Bisa saja, tetapi Apple juga baru saja mengumumkan dukungan RCS: https://9to5mac.com/2023/11/16/apple-rcs-coming-to-iphone/
      Mungkin mereka melihat saat ini sebagai kesempatan bagus untuk berbelok ke arah yang lebih terbuka

  • Mengurai protokolnya memang hebat, tetapi saya juga penasaran dengan stack infrastruktur iMessage
    Skalanya sangat besar tetapi berjalan sebaik ini, sementara layanan web Apple lain, seperti forum atau portal developer, terasa penuh bug dan belum matang, jadi makin mengherankan

    • Skala yang benar-benar mengejutkan adalah bahwa Apple Push Notification service tidak hanya mengangkut iMessage
      Notifikasi push dari semua aplikasi messenger pihak ketiga juga melewatinya, begitu juga aplikasi non-messenger yang memiliki notifikasi
      Termasuk notifikasi senyap internal. Saat Anda menambahkan rapat ke kalender di Mac, push dikirim ke iPhone agar memperbarui karena data iCloud berubah; saat Anda mengubah file iCloud Drive, push dikirim untuk sinkronisasi perangkat lain
      Saat ada panggilan telepon, Mac ikut berdering melalui Continuity, dan ini juga notifikasi push terenkripsi seperti iMessage
      Jadi penasaran, berapa banyak pesan per detik yang melewati layanan ini

  • Ini materi yang sangat cocok untuk Hack Club. Sebaiknya ikut mencoba: https://hackclub.com/

  • Benar-benar pekerjaan yang luar biasa
    Akan bagus juga kalau menulis singkat tentang bagaimana bisa masuk ke bidang ini
    Di Reddit ada banyak siswa SMA dan mahasiswa yang pandai teknologi, belajar pemrograman, dan memikirkan cara mendapatkan pekerjaan teknis; sudut pandang seperti ini sepertinya akan cukup membantu

    • Rasanya ini bukan resep rahasia, melainkan kemungkinan besar kombinasi latihan konsisten dalam jumlah besar, energi yang nyaris tak terbatas saat masih muda untuk mencurahkan diri pada hal yang disukai, serta orang tua atau panutan yang suportif
    • Saat SMA, saya punya waktu hampir sepanjang hari untuk mengerjakan proyek sendiri
      Karena bisa selesai lebih awal, ada waktu kosong, dan diam-diam mengerjakan hal saya sendiri saat seharusnya tidak, saya bisa membuat dan merilis aplikasi dalam sekitar 6 bulan, dan produktivitas saya sangat tinggi

  • Saya benar-benar penasaran, apakah topiknya memang bisa opertunistic, atau itu salah ketik dari penulis
    Salah ketik seperti referer yang memfosil lintas generasi memang menarik

    • Sayangnya kode saya memang banyak salah ketik :P
      Namun saya tidak tahu apakah ini salah ketik dari pihak Apple, tetapi jelas aneh. Di sini harus memakai WindowSerial, bukan menambahkan satu s seperti WindowsSerial
      https://github.com/JJTech0130/pypush/blob/8b33c0ee5d540d8ac7...
    • Sepertinya nilai itu tidak dipakai di kode, tetapi karena mungkin itu kode integer, besar kemungkinan ini salah eja dari penulis

  • Ada pembahasan terkait lainnya: https://news.ycombinator.com/item?id=38531759

  • Proyek open source pypush, yang menjadi dasar kabar reverse engineering iMessage hari ini, didistribusikan dengan Server Side Public License milik MongoDB, dan pemiliknya adalah Beeper
    Menurut yang JJTech katakan di Discord, ia menjual haknya kepada Beeper
    Library-nya bagus, tetapi karena lisensinya copyleft yang sangat kuat, sepertinya itu akan memengaruhi di mana ia bisa dipakai

    • Sekarang saatnya melakukan reverse reverse engineering

  • “Validation data” yang dibutuhkan saat membuat permintaan registrasi IDS disebut sebagai mekanisme Apple untuk memastikan perangkat non-Apple tidak dapat memakai iMessage; saya penasaran apakah ini akan menjadi pelanggaran saat DSA atau DMA Uni Eropa diberlakukan

    • DSA dan DMA tidak secara ajaib memberi hak untuk mengirim permintaan sesuka hati ke server Apple, dan juga tidak memaksa Apple untuk selalu memberikan respons valid tertentu
      Apa pun cara Apple mematuhi DSA dan DMA, caranya bukan yang ini
    • Apalagi sekarang iOS akan mendukung RCS
      iMessage lintas platform first-party hanyalah mimpi kosong para penggemar teknologi, dan secara pribadi menurut saya itu sudah cukup baik

  • Jika melihat pengumuman Beeper Mini [1], mereka jelas mengatakan bahwa pengguna bisa mendaftarkan nomor telepon serta mengirim dan menerima iMessage tanpa Apple ID
    Mereka juga menjelaskan bahwa perangkat berkomunikasi langsung dengan Apple
    Namun tulisan ini mengatakan IDS digunakan sebagai server kunci iMessage, tahap pertama registrasi IDS harus mendapatkan token autentikasi dengan nama pengguna dan kata sandi Apple ID, dan setelah registrasi, identity keypair yang diterima dipakai untuk pencarian kunci publik
    Kalau begitu, pertanyaannya: bagaimana aplikasi Beeper Mini mendaftarkan nomor telepon Android sembarang ke IDS sebagai kunci publik, dan bahkan melakukan pencarian kunci publik penerima tanpa Apple ID?
    Jawabannya tampaknya adalah SMS Gateway, yang nyaris tidak dijelaskan baik di tulisan asli maupun di [1], dan itu tampaknya menjadi bahan rahasianya
    [1] https://blog.beeper.com/i/139416474/security-and-privacy

    • Saya mencoba memasang Beeper Mini di ponsel Android; setelah gagal saat mencoba mengirim SMS ke Apple untuk registrasi nomor telepon, muncul jendela yang meminta Apple ID

  • Benar-benar pekerjaan yang mengagumkan
    Namun ada bagian yang mengganjal: tulisan itu mengatakan format pair lama lebih terdokumentasi dan mudah diimplementasikan, tetapi tidak menyediakan forward secrecy menggunakan “pre-keys” mirip Signal seperti format pair-ec baru
    Saya tidak tahu apakah ada bukti bahwa iMessage versi terbaru, yaitu yang memakai ECIES, benar-benar memakai pre-key
    Menurut saya, ini hanya menyisipkan ECIES sebagai pengganti RSA pada bagian enkripsi, mungkin juga penandatanganan; itu saja tidak menghasilkan forward secrecy
    Jika tidak ada buktinya, bisa jadi ini salah menafsirkan hubungan antara RSA, kurva eliptik, dan forward secrecy
    Artikel iMessage di Wikipedia juga tampaknya menyebarkan kesalahan yang sama, dan referensi yang dikutip sebenarnya tidak membuat klaim seperti itu