iMessage’ın iç yapısının açıklaması

 (jjtech.dev)
3 puan yazan GN⁺ 2023-12-06 | 1 yorum | WhatsApp'ta paylaş
  • iMessage, APNs’i basit bir bildirim kanalı olarak değil, çift yönlü aktarım temeli olarak kullanır; IDS üzerinden açık anahtar kaydı ve sorgulama ile mesaj iletim hazırlığını birlikte işler
  • Cihaz, APNs bağlantısından sonra bir push token alır ve iMessage topic’i olan com.apple.madrid’i filtreleyerek alacağı mesaj kapsamını belirler
  • IDS kaydı; Apple ID kimlik doğrulama token’ı, uzun ömürlü sertifika, açık şifreleme ve imzalama anahtarlarının yüklenmesi ve validation data gönderilmesini gerektirir; bu da Apple dışı cihazların kullanımını zorlaştıracak şekilde tasarlanmıştır
  • Mesaj şifreleme eski pair ve yeni pair-ec olarak ikiye ayrılır; pair-ec, Signal’a benzer pre-key tabanlı forward secrecy sağlar
  • Gönderen, alıcı başına ayrı şifrelenmiş payload gönderebilir ya da bunları paketleyerek gönderebilir; ancak güncel cihazlarda şifrenin çözülebilmesi için AES anahtarına HMAC etiketi dahil edilmelidir

iMessage aktarım temelinde APNs’in rolü

  • iMessage’ın temel katmanlarından biri Apple Push Notification Service(APNs)’tir
  • APNs, App Store uygulamalarının kapalıyken bile gerçek zamanlı bildirim ve güncellemeler almak için kullandığı servisle aynı katmandır
  • iMessage’da APNs yalnızca bildirim almak için değil, mesaj aktarımı için de kullanılan çift yönlü bir servis olarak çalışır
  • Cihaz APNs’e bağlandığında bir push token alır
    • Bu token, bildirimleri belirli bir cihaza yönlendirmek için kullanılır
    • application:didRegisterForRemoteNotificationsWithDeviceToken: API’sinden alınan token’dan teknik olarak farklıdır
    • Bu API’nin token’ı uygulama kapsamındadır ve uygulamanın bundle ID’siyle istenir; ancak amacı benzerdir
  • Bir cihaza push notification gönderirken mesajın topic’i de belirtilmelidir
    • Topic genellikle Bundle ID gibi görünür
    • iMessage’ın topic’i com.apple.madrid’dir
  • Cihaz APNs’e bağlandığında, hangi mesajların iletileceğini sunucuya bildiren bir filter message gönderir
    • APNs sunucusu APNs Courier olarak da adlandırılır
    • Filter message, durumlara göre topic listeleri içerebilir
    • Topic durumu enabled, opertunistic, paused, disabled değerlerinden biri olabilir

APNs üzerinde çalışan IDS sorguları

  • APNs yalnızca iMessage’ın gerçek mesaj iletimi için kullanılmaz
  • APNs üzerindeki pseudo-HTTP katmanı aracılığıyla IDS sorgu gönderebilir ve yanıt alabilir
  • APNs’e bağlanmak için Albert activation server tarafından verilen bir istemci sertifikası gerekir

IDS ve Apple ID kimlik doğrulama akışı

  • IDS, iMessage’ın anahtar sunucusu rolünü üstlenir ve FaceTime gibi diğer servislerde de kullanılır
  • IDS’in IDentity Services’in kısaltması olduğu düşünülür, ancak bunun resmen doğrulanmadığı belirtilir
  • iMessage uçtan uca şifreleme kullandığı için her katılımcının açık anahtarını güvenli şekilde değiş tokuş etmesi gerekir
  • IDS kaydının ilk adımı bir kimlik doğrulama token’ı almaktır
    • API’ye Apple ID kullanıcı adı ve parolası sağlanmalıdır
  • 2FA, IDS API’sine sonradan uyarlanmış biçimde dahil edilmiştir
    • Legacy yöntemde 2FA kodu doğrudan parolanın sonuna eklenir
    • GrandSlam yöntemi, aynı cihaz olduğunu “Anisette data” ile kanıtlayarak 2FA kodunun yeniden girilmesini önler
    • Ardından Password Equivalent Token(PET) alınabilir ve parola ile 2FA kodu gibi kullanılabilir
  • Kimlik doğrulama token’ı alındıktan sonra hemen daha uzun süre geçerli olan bir sertifika ile değiştirilmelidir
    • Bu sertifika IDS kaydını mümkün kılar; ancak tek başına anahtar sorgusu yapmak için yeterli değildir

IDS kaydı ve validation data

  • IDS kurulumundaki en önemli aşama registration’dır
  • Registration sırasında açık şifreleme anahtarı ve imzalama anahtarı anahtar sunucusuna yüklenir
  • Cihazın desteklediği özelliklere dair çeşitli client data da birlikte yüklenir
  • IDS registration isteği “validation data” adlı ikili bir blob gerektirir
    • Bu, Apple dışı cihazların iMessage kullanmasını engellemeye yönelik Apple’ın doğrulama mekanizmasıdır
  • Validation data üretiminde cihazın serial number’ı, modeli, disk UUID’si gibi bilgiler kullanılır
    • Tüm validation data aynı şekilde ele alınamaz
    • Hackintosh’a benzer şekilde, hesabın yaşı ve “score” yanlış bir serial’ın kullanılıp kullanılamayacağını veya “customer code” hatası alınıp alınmayacağını belirler
  • Validation data üreten ikili dosya güçlü biçimde obfuscate edilmiştir
    • pypush, custom mach-o loader ve Unicorn Engine ile obfuscate edilmiş ikili dosyayı emüle ederek bu sorunu aşar
    • pypush, serial number gibi cihaz özelliklerini data.plist dosyasına koyup emüle edilen ikili dosyaya sağlar

Anahtar sorgulama ve session token

  • IDS kaydından sonra bir identity keypair alınır
  • Bu keypair kullanılarak açık anahtar sorgusu yapılabilir
  • Sorgulanacak hesap sağlandığında “identities” listesi alınır
    • Her identity, ilgili hesaba kayıtlı bir cihaza karşılık gelir
    • Public key, push token, session token gibi önemli bilgiler içerir
  • session token, cihaza mesaj göndermek için gereklidir
    • Yakın zamanda sorgu yapıldığını kanıtlama rolü görür
    • Session token’ın süresi dolar
    • Yalnızca sorgu isteğini yapan hesap tarafından kullanılabilir; paylaşılamaz

Gelen mesajlar ve şifreleme biçimi

  • Mesaj almak için APNs bağlantısını com.apple.madrid ile filtrelemek ve active state packet göndermek yeterlidir
  • Gelen mesajın şifreleme biçimi, IDS kaydı sırasında bildirilen capabilities’e ve gönderen cihazın iOS sürümüne göre değişir
    • Eski, iOS 13 öncesi biçim pair’dir
    • Yeni biçim pair-ec’dir
  • pair biçimi daha fazla belgelenmiştir ve uygulanması daha kolaydır
  • pair, yeni pair-ec’den farklı olarak “pre-keys” kullanan forward secrecy sağlamaz
  • Mesajlar, çeşitli makalelere ve pypush uygulamasına göre çözülebilir
  • Mesaj imzası doğrulaması isteğe bağlıdır; ancak güvenli bir istemci oluşturmak için önemlidir

Gönderim yöntemi ve uygulamada dikkat edilmesi gerekenler

  • Mesaj gönderimi, almaya yakın biçimde ters bir süreçtir
  • Alıcı başına mesaj ayrı ayrı gönderilebilir
  • Birden fazla alıcı ve her alıcıya özel şifrelenmiş payload tek bir büyük bundle halinde de gönderilebilir
    • Bu durumda APNs bunu ayrıştırır
  • Mesaj, konuşmadaki tüm katılımcılara iletilir
    • Kendi hesabınızdaki diğer cihazlara da iletilir
  • Gönderim sırasında sık atlanan nokta, AES key’in tamamen rastgele olmadığıdır
    • AES key’e etiket olarak HMAC eklenmiştir
    • Tamamen rastgele bir AES key kullanılırsa güncel cihazlarda mesajın şifresi çözülemez

İlgili uygulamalar ve başvuru kaynakları

İlgili okumalar

1 yorum

 
GN⁺ 2023-12-06
Hacker News yorumları

  • Apple’ın iMessage’ı attestation (DeviceCheck) ile kilitlemeye başlayacağını düşünüyorum.
    Ancak eski cihazlarda yazılım güncellemesi gerekecek olması gibi bir sorun var.

    • Zaten kısmen bunu yapıyor.
      “validation data” oluşturulurken cihaz seri numarası, model, disk UUID’si gibi bilgiler kullanılıyor; Hackintosh’ta olduğu gibi hesabın yaşına ve “puanına” göre hatalı seri numarası kullanıp kullanamayacağınız ya da “customer code” hatası alıp almayacağınız belirleniyor.
      “customer code” hatası aslında Apple’ın attestation başarısızlığı uyarısı; bir kez takılırsanız Apple ID kilidini açtırmak için Apple Support ile iletişime geçmeniz gerekiyor.
      Normal müşteriler meşru bir cihazdan oturum açmayı onaylayarak bunu kolayca geçiyor, ancak Hackintosh kullanıcıları bu süreci çeşitli baypas yöntemleriyle kandırıyor.
      https://old.reddit.com/r/hackintosh/comments/gij9rt/getting_...
    • Apple zaten son yaklaşık 5 yılın iOS cihazlarına güvenlik güncellemesi sağlıyor; bu yüzden fiilen kullanımda olan neredeyse tüm iOS cihazlara güncellemenin dağıtılması çok uzun sürmez gibi görünüyor.
    • Eski cihazlar, yani TPM’i olmayan cihazlar için yazılım değil, donanım güncellemesi gerekecek gibi.
    • BBM’in bu şekilde çalıştığını sanıyorum ama emin değilim.
      Tüm işletim sistemi güvenliğinin bir parçası olmaktan ziyade, en azından Apple’ın Lockdown Mode’una dahil edilmesi gereken bir özellik gibi geliyor.
    • Öyle olabilir, ama Apple az önce RCS desteğini de duyurdu: https://9to5mac.com/2023/11/16/apple-rcs-coming-to-iphone/
      Belki de şu anı açıklığa doğru yönelmek için iyi bir fırsat olarak görmüş olabilir.

  • Protokolü çözmeleri harika, ama iMessage altyapı yığını da merak konusu.
    Ölçeği devasa olmasına rağmen bu kadar iyi çalışması, buna karşılık Apple’ın forumlar veya geliştirici portalı gibi diğer web servislerinin bol hatalı ve tamamlanmamış gibi hissettirmesi daha da ilginç.

    • Asıl şaşırtıcı ölçek, Apple Push Notification service’in yalnızca iMessage taşımıyor olması.
      Tüm üçüncü taraf mesajlaşma uygulamalarının push bildirimleri de bunun üzerinden geçiyor; bildirimi olan mesajlaşma dışı uygulamalar da aynı şekilde.
      Dahili sessiz bildirimler de dahil. Mac’te takvime bir toplantı eklediğinizde iCloud verisi değiştiği için iPhone’a güncelleme yapması amacıyla push gidiyor; iCloud Drive dosyasını değiştirdiğinizde diğer cihazların senkronizasyonu için push gidiyor.
      Telefon araması geldiğinde Continuity ile Mac’te de çalıyor; bu da iMessage gibi şifreli bir push bildirimi.
      Bu servisten saniyede acaba kaç mesaj geçtiğini merak ettiriyor.

  • Bu, Hack Club için biçilmiş kaftan bir kaynak. Katılmanız iyi olur: https://hackclub.com/

  • Gerçekten müthiş bir çalışma.
    Bu alana nasıl girdiğini de kısaca yazsa iyi olur.
    Reddit’te teknolojiye yatkın, programlamayı öğrenen ve teknik bir işe nasıl girileceğini düşünen çok sayıda lise ve üniversite öğrencisi var; böyle bir bakış açısı epey faydalı olabilir.

    • Gizli bir formülden ziyade, muazzam miktarda düzenli pratik, gençken sevdiğin işe akıtabileceğin neredeyse sınırsız enerji ve muhtemelen bilinçli ebeveynler ya da rol modeller var gibi görünüyor.
    • Lisedeyken neredeyse tüm gün kendi işlerimle uğraşacak zamanım vardı.
      Erken bitirmek, boş saatler ve aslında yapılmaması gereken zamanlarda gizlice kendi işimi yapmak sayesinde yaklaşık 6 ayda bir uygulama geliştirip yayımlayabildim; üretkenliğim çok yüksekti.

  • Gerçekten merak ediyorum: konunun gerçekten opertunistic olup olamayacağını mı, yoksa yazarın yazım hatası mı olduğunu bilmiyorum.
    Nesiller boyunca fosilleşen referer gibi yazım hataları ilginç.

    • Ne yazık ki kodumda çok yazım hatası var :P
      Bunun Apple tarafındaki bir yazım hatası olup olmadığını bilmiyorum ama kesinlikle tuhaf. Burada WindowsSerial gibi fazladan bir s eklemek yerine WindowSerial kullanmak gerekiyor.
      https://github.com/JJTech0130/pypush/blob/8b33c0ee5d540d8ac7...
    • Kodda o değeri kullanıyor gibi görünmüyor, ama muhtemelen bir tamsayı kodu olduğundan yazarın yazım hatası olma ihtimali yüksek görünüyor.

  • İlgili daha fazla içerik var: https://news.ycombinator.com/item?id=38531759

  • Bugünkü iMessage reverse engineering haberinin temelini oluşturan açık kaynak proje pypush, MongoDB’nin Server Side Public License’ı ile dağıtılıyor ve sahibi Beeper.
    JJTech’in Discord’da söylediğine göre hakları Beeper’a satmış.
    Kütüphane harika, ancak çok güçlü bir copyleft lisansı olduğu için nerelerde kullanılabileceğini etkileyecek gibi.

    • Şimdi sıra ters reverse engineering yapmaya geldi.

  • IDS kayıt isteği oluştururken gereken “validation data”nın, Apple’ın Apple dışı cihazların iMessage kullanmasını engellemek için doğrulama mekanizması olduğu söyleniyor; AB’nin DSA veya DMA düzenlemeleri yürürlüğe girince bunun ihlal sayılıp sayılmayacağını merak ediyorum.

    • DSA ve DMA, Apple sunucularına istediğiniz gibi istek gönderme hakkını sihirli biçimde vermez ve Apple’ı belirli bir geçerli yanıtı mutlaka sağlamaya da zorlamaz.
      Apple DSA ve DMA’ya hangi yöntemle uyarsa uysun, bu yöntem bu olmayacaktır.
    • Özellikle de iOS artık RCS destekleyecekken.
      Birinci taraf, çapraz platform iMessage ancak teknoloji meraklılarının boş bir hayaline yakın; şahsen bunun böyle olması benim için gayet yeterli.

  • Beeper Mini duyuru metnine [1] bakınca, kullanıcıların Apple ID olmadan da telefon numaralarını kaydedip iMessage alıp gönderebileceğini açıkça söylüyor.
    Ayrıca cihaz ile Apple’ın doğrudan iletişim kurduğunu açıklıyor.
    Ancak bu yazı, IDS’nin iMessage’ın anahtar sunucusu olarak kullanıldığını; IDS kaydının ilk adımında Apple ID kullanıcı adı ve parolasıyla kimlik doğrulama token’ı alınması gerektiğini ve kayıt sonrasında alınan identity keypair ile açık anahtar sorgusu yapıldığını söylüyor.
    O halde Beeper Mini uygulamasının rastgele bir Android telefon numarasını IDS’ye açık anahtarla nasıl kaydettiği ve alıcının açık anahtar sorgusunu Apple ID olmadan nasıl yaptığı sorusu ortaya çıkıyor.
    Cevap, ne orijinal yazıda ne de [1]’de neredeyse hiç açıklanmayan SMS Gateway gibi görünüyor; gizli malzeme bu olabilir.
    [1] https://blog.beeper.com/i/139416474/security-and-privacy

    • Android telefonuma Beeper Mini kurdum; telefon numarası kaydı için Apple’a SMS göndermeye çalışıp hata verdikten sonra Apple ID girmemi isteyen bir pencere çıktı.

  • Gerçekten şaşırtıcı bir çalışma.
    Yalnız yazıda, eski pair biçiminin daha iyi belgelendiği ve uygulanmasının daha kolay olduğu, ancak yeni pair-ec biçimi gibi Signal’e benzer “pre-keys” kullanarak forward secrecy sağlamadığı söylenen kısım aklıma takıldı.
    Güncel, yani ECIES kullanan iMessage’ın gerçekten pre-key kullandığına dair kanıt var mı bilmiyorum.
    Bana göre şifreleme, belki de imza tarafında RSA yerine ECIES yerleştirilmiş gibi duruyor; tek başına bu forward secrecy sağlamaz.
    Kanıt yoksa RSA, eliptik eğri ve forward secrecy arasındaki ilişki yanlış yorumlanmış olabilir.
    Wikipedia’daki iMessage maddesi de aynı hatayı yayıyor gibi görünüyor; alıntılanan kaynaklar aslında böyle bir iddiada bulunmuyor.