Giải thích cấu trúc bên trong của iMessage

 (jjtech.dev)
3 điểm bởi GN⁺ 2023-12-06 | 1 bình luận | Chia sẻ qua WhatsApp
  • iMessage sử dụng APNs không chỉ như một kênh thông báo đơn thuần mà như một nền tảng truyền hai chiều, đồng thời dùng IDS để gộp việc đăng ký/tra cứu khóa công khai với khâu chuẩn bị chuyển tin nhắn
  • Sau khi kết nối tới APNs, thiết bị nhận push token và lọc theo topic iMessage là com.apple.madrid để xác định phạm vi tin nhắn sẽ nhận
  • Việc đăng ký IDS đòi hỏi token xác thực Apple ID, chứng chỉ dài hạn, tải lên khóa công khai để mã hóa và ký, cùng với validation data, khiến việc dùng thiết bị không phải của Apple trở nên khó khăn theo đúng thiết kế
  • Mã hóa tin nhắn được chia thành kiểu cũ pair và kiểu mới pair-ec; pair-ec cung cấp forward secrecy dựa trên pre-key tương tự Signal
  • Người gửi có thể gửi riêng payload đã mã hóa cho từng người nhận hoặc gộp lại, nhưng để thiết bị mới giải mã được thì khóa AES phải kèm thẻ HMAC

Nền tảng truyền iMessage do APNs đảm nhiệm

  • Một trong những lớp nền tảng của iMessage là Apple Push Notification Service(APNs)
  • Đây là cùng lớp dịch vụ được dùng để nhận thông báo và cập nhật theo thời gian thực ngay cả khi ứng dụng từ App Store đã bị đóng
  • Trong iMessage, APNs không chỉ dùng để nhận thông báo mà còn hoạt động như một dịch vụ hai chiều phục vụ truyền tin nhắn
  • Khi thiết bị kết nối tới APNs, nó sẽ nhận một push token
    • Token này được dùng để định tuyến thông báo tới một thiết bị cụ thể
    • Về mặt kỹ thuật, nó khác với token nhận từ API application:didRegisterForRemoteNotificationsWithDeviceToken:
    • Token của API đó có phạm vi theo từng ứng dụng và được yêu cầu bằng bundle ID của ứng dụng, nhưng mục đích thì tương tự
  • Khi gửi một push notification tới thiết bị, cũng phải chỉ định topic của thông điệp
    • Topic thường trông giống như Bundle ID
    • Topic của iMessage là com.apple.madrid
  • Khi thiết bị kết nối tới APNs, nó gửi một filter message để báo cho máy chủ biết mình muốn nhận loại thông điệp nào
    • Máy chủ APNs cũng được gọi là APNs Courier
    • Filter message có thể chứa danh sách topic theo từng trạng thái
    • Trạng thái của topic có thể là enabled, opertunistic, paused, hoặc disabled

Các truy vấn IDS chạy trên APNs

  • APNs không chỉ được dùng cho việc chuyển phát tin nhắn thực tế của iMessage
  • Thông qua lớp pseudo-HTTP chạy trên APNs, IDS có thể gửi truy vấn và nhận phản hồi
  • Để kết nối tới APNs, cần có chứng chỉ máy khách do Albert activation server cấp

Luồng xác thực IDS và Apple ID

  • IDS đóng vai trò máy chủ khóa của iMessage và cũng được dùng cho các dịch vụ khác như FaceTime
  • IDS dường như là viết tắt của IDentity Services, nhưng được nói là chưa có xác nhận chính thức
  • Vì iMessage dùng mã hóa đầu cuối, nên cần trao đổi an toàn khóa công khai của từng bên tham gia
  • Bước đầu tiên của đăng ký IDS là lấy token xác thực
    • Cần cung cấp tên người dùng Apple ID và mật khẩu cho API
  • 2FA được ghép vào IDS API theo cách bổ sung về sau
    • Cách cũ là nối trực tiếp mã 2FA vào mật khẩu
    • Phương thức GrandSlam dùng “Anisette data” để chứng minh đó là cùng một thiết bị, nhờ vậy không phải nhập lại mã 2FA
    • Sau đó có thể nhận Password Equivalent Token(PET) để dùng như mật khẩu và mã 2FA
  • Sau khi nhận token xác thực, phải lập tức đổi nó lấy chứng chỉ có thời hạn dài hơn
    • Chứng chỉ này cho phép đăng ký IDS, nhưng chỉ riêng nó thì chưa đủ để thực hiện tra cứu khóa

Đăng ký IDS và validation data

  • Bước quan trọng nhất trong thiết lập IDS là registration
  • Trong registration, khóa mã hóa công khai và khóa ký được tải lên máy chủ khóa
  • Nhiều client data về các tính năng mà thiết bị hỗ trợ cũng được tải lên cùng lúc
  • Yêu cầu đăng ký IDS cần một blob nhị phân gọi là “validation data”
    • Đây là cơ chế kiểm chứng của Apple nhằm ngăn thiết bị không phải của Apple sử dụng iMessage
  • Việc tạo validation data sử dụng thông tin như serial number, model và disk UUID của thiết bị
    • Không thể coi mọi validation data là giống nhau
    • Tương tự Hackintosh, tuổi đời tài khoản và “score” ảnh hưởng tới việc có thể dùng serial không hợp lệ hay có gặp lỗi “customer code” hay không
  • Binary tạo validation data bị làm rối rất mạnh
    • pypush vượt qua vấn đề này bằng cách mô phỏng binary đã bị làm rối với custom mach-o loader và Unicorn Engine
    • pypush cung cấp các thuộc tính thiết bị như serial number cho binary được mô phỏng thông qua tệp data.plist

Tra cứu khóa và session token

  • Sau khi đăng ký IDS, sẽ nhận được identity keypair
  • Có thể dùng keypair này để thực hiện tra cứu khóa công khai
  • Khi cung cấp tài khoản cần tra cứu, sẽ nhận được danh sách “identities”
    • Mỗi identity tương ứng với một thiết bị đã đăng ký của tài khoản đó
    • Nó chứa thông tin quan trọng như public key, push token và session token
  • Session token là cần thiết để gửi tin nhắn tới thiết bị
    • Nó đóng vai trò chứng minh rằng việc tra cứu đã được thực hiện gần đây
    • Session token sẽ hết hạn
    • Chỉ tài khoản đã thực hiện truy vấn tra cứu mới dùng được, nên không thể chia sẻ

Tin nhắn nhận được và định dạng mã hóa

  • Để nhận tin nhắn, chỉ cần lọc kết nối APNs theo com.apple.madrid và gửi active state packet
  • Định dạng mã hóa của tin nhắn nhận được phụ thuộc vào capabilities đã khai báo khi đăng ký IDS và phiên bản iOS của thiết bị gửi
    • Định dạng cũ, trước iOS 13, là pair
    • Định dạng mới là pair-ec
  • Định dạng pair đã được tài liệu hóa nhiều hơn và dễ triển khai hơn
  • Khác với pair-ec mới hơn, pair không cung cấp forward secrecy sử dụng “pre-keys”
  • Tin nhắn có thể được giải mã dựa trên nhiều bài nghiên cứu và phần triển khai của pypush
  • Việc xác minh chữ ký tin nhắn là tùy chọn, nhưng rất quan trọng nếu muốn xây dựng một client an toàn

Cách gửi và những điểm cần lưu ý khi triển khai

  • Việc gửi tin nhắn gần như là quá trình ngược lại của nhận tin
  • Có thể gửi riêng tin nhắn cho từng người nhận
  • Cũng có thể gộp nhiều người nhận và payload đã mã hóa cho từng người nhận vào một bundle lớn
    • Trong trường hợp này, APNs sẽ tách chúng ra
  • Tin nhắn được chuyển tới mọi thành viên trong cuộc trò chuyện
    • Bao gồm cả các thiết bị khác thuộc chính tài khoản của mình
  • Một điểm thường bị bỏ sót khi gửi là khóa AES không hoàn toàn ngẫu nhiên
    • Khóa AES có kèm HMAC dưới dạng thẻ
    • Nếu dùng khóa AES hoàn toàn ngẫu nhiên, thiết bị mới sẽ không giải mã được tin nhắn

Các phần triển khai liên quan và tài liệu tham khảo

Bài viết liên quan

1 bình luận

 
GN⁺ 2023-12-06
Ý kiến trên Hacker News

  • Có vẻ Apple sẽ bắt đầu khóa iMessage bằng attestation (DeviceCheck)
    Tuy nhiên vấn đề là các thiết bị cũ sẽ cần cập nhật phần mềm

    • Thực ra họ đã làm một phần như vậy rồi
      Khi tạo “validation data”, các thông tin như số sê-ri thiết bị, model, UUID ổ đĩa được dùng; với Hackintosh, tùy theo tuổi đời tài khoản và “điểm số” mà việc dùng số sê-ri sai có được chấp nhận hay sẽ gặp lỗi “customer code”
      Lỗi “customer code” về thực chất là prompt báo attestation của Apple thất bại, và một khi dính lỗi này thì phải liên hệ Apple Support để mở khóa Apple ID
      Khách hàng bình thường có thể vượt qua dễ dàng bằng cách phê duyệt đăng nhập trên thiết bị hợp pháp, còn người dùng Hackintosh thì dùng các kỹ thuật обход để đánh lừa quy trình này
      https://old.reddit.com/r/hackintosh/comments/gij9rt/getting_...
    • Apple hiện đã cung cấp cập nhật bảo mật cho các thiết bị iOS trong khoảng 5 năm gần đây, nên có lẽ sẽ không mất quá lâu để bản cập nhật được triển khai tới gần như mọi thiết bị iOS đang được sử dụng thực tế
    • Với thiết bị cũ, tức thiết bị không có TPM, có lẽ sẽ cần cập nhật phần cứng chứ không phải phần mềm
    • Hình như BBM từng hoạt động theo kiểu đó, nhưng tôi không chắc
      Nghe giống một tính năng ít nhất nên nằm trong Lockdown Mode của Apple hơn là một phần của bảo mật toàn hệ điều hành
    • Có thể là vậy, nhưng Apple vừa công bố hỗ trợ RCS: https://9to5mac.com/2023/11/16/apple-rcs-coming-to-iphone/
      Có lẽ họ xem đây là cơ hội tốt để chuyển hướng sang cởi mở hơn

  • Việc hiểu được giao thức là rất tuyệt, nhưng tôi cũng tò mò về stack hạ tầng iMessage
    Điều càng lạ là dù quy mô khổng lồ như vậy mà nó vẫn hoạt động rất tốt, trong khi các dịch vụ web khác của Apple, chẳng hạn diễn đàn hay cổng developer, lại nhiều lỗi và có cảm giác chưa hoàn thiện

    • Quy mô thật sự đáng kinh ngạc nằm ở chỗ Apple Push Notification service không chỉ vận chuyển iMessage
      Push notification của mọi ứng dụng nhắn tin bên thứ ba cũng đi qua đó, và các ứng dụng không phải nhắn tin nhưng có thông báo cũng vậy
      Bao gồm cả thông báo im lặng nội bộ. Khi bạn thêm một cuộc họp vào lịch trên Mac, iPhone sẽ nhận push để cập nhật vì dữ liệu iCloud đã thay đổi; khi bạn sửa một tệp iCloud Drive, push sẽ được gửi để đồng bộ các thiết bị khác
      Khi có cuộc gọi đến, Mac cũng đổ chuông qua Continuity, và đây cũng là push notification được mã hóa giống iMessage
      Tự hỏi rốt cuộc mỗi giây có bao nhiêu thông điệp đi qua dịch vụ này

  • Đây là tài liệu rất hợp với Hack Club. Nên thử tham gia: https://hackclub.com/

  • Công việc thật sự ấn tượng
    Sẽ rất hay nếu viết ngắn gọn về việc bạn đã bước vào lĩnh vực này như thế nào
    Trên Reddit có nhiều học sinh cấp ba và sinh viên đại học đang băn khoăn về cách giỏi kỹ thuật, học lập trình và kiếm việc trong ngành công nghệ; góc nhìn như vậy có lẽ sẽ khá hữu ích

    • Có vẻ không phải bí quyết bí mật gì, mà nhiều khả năng là một lượng luyện tập đều đặn khổng lồ, gần như vô hạn năng lượng khi còn trẻ để dồn vào việc mình thích, và có cha mẹ hoặc hình mẫu đủ khai sáng
    • Hồi cấp ba tôi gần như có cả ngày để làm việc của mình
      Nhờ hoàn thành việc sớm, thời gian trống, và lén làm việc riêng vào những lúc lẽ ra không nên, tôi có thể xây dựng và phát hành một ứng dụng trong khoảng 6 tháng, và năng suất khi đó rất cao

  • Tôi thật sự tò mò liệu chủ đề có thực sự có thể là opertunistic hay chỉ là lỗi gõ của tác giả
    Những lỗi chính tả kiểu referer bị hóa thạch qua nhiều thế hệ khá thú vị

    • Đáng tiếc là code của tôi có rất nhiều lỗi chính tả :P
      Tuy không biết đây có phải lỗi gõ từ phía Apple không, nhưng rõ ràng là kỳ lạ. Ở đây phải dùng WindowSerial, chứ không phải thêm một chữ s như WindowsSerial
      https://github.com/JJTech0130/pypush/blob/8b33c0ee5d540d8ac7...
    • Có vẻ code không dùng giá trị đó, nhưng có lẽ đó là mã số nguyên, nên nhiều khả năng là lỗi chính tả của tác giả

  • Có thêm nội dung liên quan: https://news.ycombinator.com/item?id=38531759

  • Dự án mã nguồn mở pypush, nền tảng cho tin tức reverse engineering iMessage hôm nay, được phát hành theo Server Side Public License của MongoDB, và chủ sở hữu là Beeper
    Theo lời JJTech nói trên Discord, anh ấy đã bán quyền cho Beeper
    Thư viện rất tuyệt, nhưng vì đây là giấy phép copyleft rất mạnh nên có lẽ sẽ ảnh hưởng đến việc nó có thể được dùng ở đâu

    • Giờ đến lượt làm reverse engineering ngược

  • “validation data” cần để tạo yêu cầu đăng ký IDS được cho là cơ chế Apple dùng để kiểm tra nhằm ngăn thiết bị không phải Apple dùng iMessage; tôi tự hỏi liệu điều này có vi phạm khi DSA hoặc DMA của EU được thực thi không

    • DSA và DMA không trao quyền một cách thần kỳ để gửi yêu cầu tùy ý tới máy chủ Apple, cũng không buộc Apple phải cung cấp một phản hồi hợp lệ cụ thể
      Dù Apple tuân thủ DSA và DMA theo cách nào, thì sẽ không phải bằng cách này
    • Đặc biệt là khi giờ iOS đã hỗ trợ RCS
      iMessage đa nền tảng chính chủ gần như chỉ là giấc mơ viển vông của dân mê công nghệ, và cá nhân tôi thấy như vậy cũng đủ ổn

  • Nhìn vào bài công bố Beeper Mini [1], họ nói rõ rằng người dùng có thể đăng ký số điện thoại và gửi nhận iMessage mà không cần Apple ID
    Họ cũng giải thích rằng thiết bị giao tiếp trực tiếp với Apple
    Nhưng bài viết này nói IDS được dùng làm key server của iMessage; bước đầu đăng ký IDS cần lấy token xác thực bằng tên người dùng và mật khẩu Apple ID, và sau khi đăng ký thì dùng identity keypair nhận được để tra cứu khóa công khai
    Vậy câu hỏi là ứng dụng Beeper Mini làm thế nào để đăng ký một số điện thoại Android bất kỳ vào IDS với khóa công khai, rồi còn thực hiện tra cứu khóa công khai của người nhận mà không cần Apple ID
    Câu trả lời có vẻ là SMS Gateway, thứ gần như không được giải thích trong bài gốc hay trong [1], và dường như đó là nguyên liệu bí mật
    [1] https://blog.beeper.com/i/139416474/security-and-privacy

    • Tôi đã cài Beeper Mini trên điện thoại Android; sau khi nó cố gửi SMS cho Apple để đăng ký số điện thoại rồi báo lỗi thất bại, một cửa sổ yêu cầu nhập Apple ID hiện ra

  • Công việc thật sự đáng kinh ngạc
    Tuy nhiên tôi hơi vướng ở đoạn bài viết nói định dạng pair cũ được tài liệu hóa tốt hơn và dễ triển khai hơn, nhưng không cung cấp forward secrecy bằng “pre-keys” giống Signal như định dạng pair-ec mới
    Tôi không biết có bằng chứng nào cho thấy iMessage hiện đại, tức bản dùng ECIES, thật sự dùng pre-key hay không
    Theo tôi thấy thì có vẻ họ chỉ nhét ECIES vào thay cho RSA ở phần mã hóa, có lẽ cả phần ký nữa, nhưng chỉ thế thôi thì không tạo ra forward secrecy
    Nếu không có bằng chứng, có thể đây là diễn giải sai về quan hệ giữa RSA, đường cong elliptic và forward secrecy
    Tài liệu iMessage trên Wikipedia dường như cũng lan truyền cùng lỗi này, và tài liệu tham khảo được trích dẫn thực ra không đưa ra tuyên bố đó