อธิบายโครงสร้างภายในของ iMessage
(jjtech.dev)- iMessage ใช้ APNs ไม่ใช่แค่เป็นช่องทางแจ้งเตือนธรรมดา แต่ใช้เป็นฐานการส่งข้อมูลแบบสองทาง และใช้ IDS เพื่อจัดการการลงทะเบียน/ค้นหา public key และการเตรียมส่งข้อความร่วมกัน
- หลังอุปกรณ์เชื่อมต่อกับ APNs แล้วจะได้รับ push token และกำหนดขอบเขตข้อความที่จะรับโดยกรอง topic ของ iMessage คือ
com.apple.madrid - การลงทะเบียน IDS ต้องใช้โทเค็นยืนยันตัวตนของ Apple ID, ใบรับรองระยะยาว, การอัปโหลดกุญแจสาธารณะสำหรับเข้ารหัสและลงนาม และการส่ง validation data ทำให้ถูกออกแบบมาให้ใช้งานบนอุปกรณ์ที่ไม่ใช่ Apple ได้ยาก
- การเข้ารหัสข้อความแบ่งเป็นแบบเก่า
pairและแบบใหม่pair-ecโดยpair-ecให้ forward secrecy ที่อิง pre-key คล้ายกับ Signal - ผู้ส่งสามารถส่ง payload ที่เข้ารหัสแยกตามผู้รับแต่ละราย หรือรวมส่งเป็นชุดได้ แต่เพื่อให้อุปกรณ์รุ่นใหม่ถอดรหัสได้ ต้องมี แท็ก HMAC รวมอยู่ในกุญแจ AES
ฐานการส่ง iMessage ที่ APNs รับผิดชอบ
- หนึ่งในชั้นพื้นฐานของ iMessage คือ Apple Push Notification Service(APNs)
- APNs เป็นชั้นเดียวกับบริการที่แอปใน App Store ใช้เพื่อรับการแจ้งเตือนและอัปเดตแบบเรียลไทม์ แม้แอปจะปิดอยู่
- ใน iMessage, APNs ทำงานเป็นบริการสองทางที่ใช้ไม่เพียงรับการแจ้งเตือน แต่ยังใช้สำหรับ ส่งข้อความ ด้วย
- เมื่ออุปกรณ์เชื่อมต่อกับ APNs จะได้รับ push token
- โทเค็นนี้ใช้สำหรับ route การแจ้งเตือนไปยังอุปกรณ์เฉพาะเครื่อง
- ในเชิงเทคนิคแตกต่างจากโทเค็นที่ได้รับจาก API
application:didRegisterForRemoteNotificationsWithDeviceToken: - โทเค็นของ API ดังกล่าวมีขอบเขตต่อแอป และถูกร้องขอด้วย bundle ID ของแอปพลิเคชัน แต่มีจุดประสงค์คล้ายกัน
- เมื่อต้องส่ง push notification ไปยังอุปกรณ์ ต้องระบุ topic ของข้อความด้วย
- topic มักดูคล้าย Bundle ID
- topic ของ iMessage คือ
com.apple.madrid
- เมื่ออุปกรณ์เชื่อมต่อกับ APNs จะส่ง filter message เพื่อแจ้งเซิร์ฟเวอร์ว่าต้องการให้ส่งต่อข้อความใดบ้าง
- เซิร์ฟเวอร์ APNs ยังถูกเรียกว่า APNs Courier ด้วย
- filter message อาจมีรายการ topic ตามสถานะรวมอยู่ได้
- สถานะของ topic อาจเป็นหนึ่งใน
enabled,opertunistic,paused,disabled
IDS query ที่ทำงานบน APNs
- APNs ไม่ได้ถูกใช้เฉพาะสำหรับการส่งต่อข้อความจริงของ iMessage เท่านั้น
- IDS สามารถส่ง query และรับ response ผ่าน ชั้น pseudo-HTTP ที่อยู่บน APNs ได้
- การเชื่อมต่อกับ APNs ต้องใช้ใบรับรอง client ที่ออกโดย Albert activation server
IDS และ flow การยืนยันตัวตนด้วย Apple ID
- IDS ทำหน้าที่เป็น key server ของ iMessage และยังใช้กับบริการอื่นอย่าง FaceTime ด้วย
- IDS ดูเหมือนจะย่อมาจาก IDentity Services แต่มีการระบุว่ายังไม่มีการยืนยันอย่างเป็นทางการ
- iMessage ใช้การเข้ารหัสแบบ end-to-end ดังนั้นจึงต้องแลกเปลี่ยน public key ของผู้เข้าร่วมแต่ละคนอย่างปลอดภัย
- ขั้นตอนแรกของการลงทะเบียน IDS คือการรับโทเค็นยืนยันตัวตน
- ต้องส่งชื่อผู้ใช้และรหัสผ่าน Apple ID ให้กับ API
- 2FA ถูกเพิ่มเข้ามาใน IDS API ภายหลังในรูปแบบที่ปรับให้เข้ากัน
- วิธีแบบ legacy คือแนบรหัส 2FA ต่อท้ายรหัสผ่านโดยตรง
- วิธี GrandSlam ใช้ “Anisette data” เพื่อพิสูจน์ว่าเป็นอุปกรณ์เครื่องเดิม ทำให้ไม่ต้องกรอกรหัส 2FA ซ้ำ
- หลังจากนั้นสามารถรับ Password Equivalent Token(PET) และใช้แทนรหัสผ่านกับรหัส 2FA ได้
- หลังได้รับโทเค็นยืนยันตัวตนแล้ว ต้องแลกเป็น ใบรับรอง ที่มีอายุยาวกว่าทันที
- ใบรับรองนี้ทำให้ลงทะเบียน IDS ได้ แต่เพียงตัวมันเองยังไม่เพียงพอสำหรับการค้นหากุญแจ
การลงทะเบียน IDS และ validation data
- ขั้นตอนที่สำคัญที่สุดในการตั้งค่า IDS คือ registration
- ใน registration จะอัปโหลดกุญแจสาธารณะสำหรับเข้ารหัสและกุญแจสำหรับลงนามไปยัง key server
- มีการอัปโหลด client data หลายรายการเกี่ยวกับความสามารถที่อุปกรณ์รองรับไปพร้อมกันด้วย
- คำขอ IDS registration ต้องใช้ binary blob ที่เรียกว่า “validation data”
- นี่คือกลไกตรวจสอบของ Apple เพื่อไม่ให้อุปกรณ์ที่ไม่ใช่ Apple ใช้ iMessage ได้
- การสร้าง validation data ใช้ข้อมูลอย่าง serial number, model, disk UUID ของอุปกรณ์
- ไม่สามารถปฏิบัติกับ validation data ทั้งหมดเหมือนกันได้
- คล้ายกับ Hackintosh อายุของบัญชีและ “score” ส่งผลต่อว่าจะใช้ serial ที่ไม่ถูกต้องได้หรือไม่ หรือจะเกิดข้อผิดพลาด “customer code” หรือไม่
- ไบนารีที่ใช้สร้าง validation data ถูก obfuscate อย่างหนัก
pypushเลี่ยงปัญหานี้ด้วยการใช้ custom mach-o loader และ Unicorn Engine เพื่อ emulate ไบนารีที่ถูก obfuscatepypushใส่คุณสมบัติของอุปกรณ์ เช่น serial number ไว้ในไฟล์data.plistแล้วส่งให้ไบนารีที่ถูก emulate
การค้นหากุญแจและ session token
- หลังจากลงทะเบียน IDS แล้ว จะได้รับ identity keypair
- สามารถใช้ keypair นี้เพื่อค้นหา public key ได้
- เมื่อระบุบัญชีที่ต้องการค้นหา จะได้รับรายการ “identities”
- identity แต่ละรายการสอดคล้องกับอุปกรณ์หนึ่งเครื่องที่ลงทะเบียนไว้กับบัญชีนั้น
- มีข้อมูลสำคัญ เช่น public key, push token, session token รวมอยู่ด้วย
- session token จำเป็นสำหรับการส่งข้อความไปยังอุปกรณ์
- ทำหน้าที่พิสูจน์ว่าเพิ่งทำการค้นหาไปไม่นาน
- session token มีวันหมดอายุ
- ใช้ได้เฉพาะกับบัญชีที่ส่งคำขอค้นหาเท่านั้น จึงแชร์ไม่ได้
ข้อความขาเข้าและรูปแบบการเข้ารหัส
- หากต้องการรับข้อความ เพียงกรองการเชื่อมต่อ APNs ด้วย
com.apple.madridแล้วส่ง active state packet - รูปแบบการเข้ารหัสของข้อความขาเข้าขึ้นอยู่กับ capabilities ที่แจ้งไว้ตอนลงทะเบียน IDS และเวอร์ชัน iOS ของอุปกรณ์ผู้ส่ง
- รูปแบบเก่าก่อน iOS 13 คือ
pair - รูปแบบใหม่คือ
pair-ec
- รูปแบบเก่าก่อน iOS 13 คือ
- รูปแบบ
pairมีเอกสารมากกว่าและ implement ได้ง่ายกว่า pairไม่ได้ให้ forward secrecy โดยใช้ “pre-keys” ต่างจากpair-ecรุ่นใหม่- สามารถถอดรหัสข้อความได้ตาม paper หลายฉบับและ implementation ของ
pypush - การตรวจสอบลายเซ็นของข้อความเป็นทางเลือก แต่สำคัญหากต้องการสร้าง client ที่ปลอดภัย
วิธีส่งและข้อควรระวังในการ implement
- การส่งข้อความใกล้เคียงกับกระบวนการย้อนกลับของการรับ
- สามารถส่งข้อความแยกเป็นรายผู้รับได้
- สามารถรวมผู้รับหลายคนและ payload ที่เข้ารหัสสำหรับผู้รับแต่ละคนไว้ใน bundle ขนาดใหญ่ชุดเดียวแล้วส่งได้เช่นกัน
- ในกรณีนี้ APNs จะแยกออกให้
- ข้อความจะถูกส่งถึงผู้เข้าร่วมทุกคนในการสนทนา
- รวมถึงอุปกรณ์อื่นของบัญชีตนเองด้วย
- จุดที่มักพลาดตอนส่งคือ AES key ไม่ได้สุ่มทั้งหมด
- AES key มี HMAC แนบเป็นแท็ก
- หากใช้ AES key ที่สุ่มทั้งหมด อุปกรณ์รุ่นใหม่จะถอดรหัสข้อความไม่สำเร็จ
implementation ที่เกี่ยวข้องและเอกสารอ้างอิง
pypush: โปรเจกต์โอเพนซอร์สที่ reimplement iMessage- IMFreedom Knowledge Base: iMessage: ฐานความรู้เกี่ยวกับ iMessage
- M. Frister:
pushproxy: implementation ที่เกี่ยวข้อง - Nicolás:
apns-dissector: เครื่องมือวิเคราะห์ APNs - QuarkSlab: iMessage Privacy: เอกสารเกี่ยวกับความเป็นส่วนตัวของ iMessage
- Garman et al. Chosen Ciphertext Attacks on Apple iMessage: paper เรื่อง chosen ciphertext attacks ต่อ Apple iMessage
- NowSecure: Reverse Engineering iMessage: เอกสาร reverse engineering iMessage
- Elcomsoft: iMessage Security and Attachments: เอกสารเกี่ยวกับความปลอดภัยของ iMessage และไฟล์แนบ
- Eric Rabil’s
open-imcore: โปรเจกต์ที่เกี่ยวข้อง - The Apple Wiki: Apple Push Notification Service: เอกสารเกี่ยวกับ APNs
- Mihir Bellare and Igors Stepanovs: Security under Message-Derived Keys: Signcryption in iMessage: paper เกี่ยวกับ signcryption ใน iMessage
- Apple Platform Security: How iMessage sends and receives messages securely: คำอธิบายด้านความปลอดภัยของ iMessage จาก Apple
- Nicolás: Apple IDS payload keys: เอกสารเกี่ยวกับ Apple IDS payload key
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ดูเหมือนว่า Apple จะเริ่มล็อก iMessage ด้วย attestation (DeviceCheck)
แต่มีปัญหาว่าอุปกรณ์รุ่นเก่าจะต้องมีการอัปเดตซอฟต์แวร์
ตอนสร้าง “validation data” มีการใช้ข้อมูลอย่างหมายเลขซีเรียลของอุปกรณ์ รุ่น และ UUID ของดิสก์ และเหมือนกับ Hackintosh ผลลัพธ์จะแตกต่างกันไปตามอายุบัญชีและ “คะแนน” ว่าจะใช้หมายเลขซีเรียลที่ไม่ถูกต้องได้หรือจะเจอข้อผิดพลาด “customer code”
ข้อผิดพลาด “customer code” โดยพื้นฐานแล้วคือพรอมป์ที่บอกว่า attestation ของ Apple ล้มเหลว ถ้าโดนแล้วต้องติดต่อ Apple Support เพื่อปลดล็อก Apple ID
ลูกค้าปกติผ่านได้ง่าย ๆ ด้วยการอนุมัติการล็อกอินจากอุปกรณ์ที่ถูกต้องตามกฎหมาย แต่ผู้ใช้ Hackintosh จะหลอกกระบวนการนี้ด้วยเทคนิคการเลี่ยงต่าง ๆ
https://old.reddit.com/r/hackintosh/comments/gij9rt/getting_...
ฟังดูเหมือนเป็นฟีเจอร์ที่อย่างน้อยควรอยู่ใน Lockdown Mode ของ Apple มากกว่าจะเป็นส่วนหนึ่งของความปลอดภัยของระบบปฏิบัติการทั้งหมด
บางที Apple อาจมองว่าตอนนี้เป็นโอกาสดีที่จะเปลี่ยนทิศไปทางเปิดกว้างมากขึ้น
การแกะสัญญาได้ถือว่ายอดเยี่ยม แต่ก็อยากรู้เกี่ยวกับ สแต็กโครงสร้างพื้นฐานของ iMessage ด้วย
ยิ่งน่าทึ่งเพราะถึงจะมีสเกลมหาศาลแต่กลับทำงานได้ดีมาก ขณะที่เว็บเซอร์วิสอื่น ๆ ของ Apple เช่น ฟอรัมหรือพอร์ทัลนักพัฒนา กลับมีบั๊กเยอะและให้ความรู้สึกเหมือนยังไม่เสร็จ
การแจ้งเตือนแบบพุชของแอปแชตบุคคลที่สามทั้งหมดก็วิ่งผ่านระบบนี้ และแอปที่ไม่ใช่แชตแต่มีการแจ้งเตือนก็เช่นกัน
รวมถึงการแจ้งเตือนเงียบภายในระบบด้วย ถ้าเพิ่มประชุมใน Calendar บน Mac ก็จะมีพุชไปยัง iPhone เพื่อบอกว่าข้อมูล iCloud เปลี่ยนแล้วให้อัปเดต และถ้าแก้ไฟล์ใน iCloud Drive ก็จะมีพุชเพื่อซิงก์กับอุปกรณ์อื่น
เวลาโทรศัพท์เข้า Mac ก็ดังผ่าน Continuity ซึ่งนี่ก็เป็นการแจ้งเตือนแบบพุชที่เข้ารหัสเหมือน iMessage
ทำให้อยากรู้จริง ๆ ว่ามีข้อความกี่ข้อความต่อวินาทีที่วิ่งผ่านบริการนี้
นี่เป็นข้อมูลที่เหมาะกับ Hack Club มาก น่าลองเข้าร่วมดู: https://hackclub.com/
เป็นผลงานที่ยอดเยี่ยมจริง ๆ
ถ้าเขียนสั้น ๆ ด้วยว่าเข้ามาในสายนี้ได้อย่างไรก็น่าจะดี
บน Reddit มีนักเรียนมัธยมและนักศึกษามหาวิทยาลัยจำนวนมากที่คิดเรื่องการเก่งเทคโนโลยี การเรียนเขียนโปรแกรม และการได้งานสายเทค มุมมองแบบนี้น่าจะช่วยได้มาก
ด้วยการทำงานให้เสร็จเร็ว ช่วงเวลาว่าง และการแอบทำงานของตัวเองในเวลาที่จริง ๆ ไม่ควรทำ ผมจึงสร้างและปล่อยแอปได้ในราว 6 เดือน และมีผลิตภาพสูงมาก
สงสัยจริง ๆ ว่าหัวข้อนี้ตั้งใจเป็น
opertunisticได้จริงไหม หรือเป็นแค่พิมพ์ผิดของผู้เขียนพวก คำพิมพ์ผิด ที่กลายเป็นฟอสซิลข้ามรุ่นอย่าง
refererนี่น่าสนใจแต่ไม่รู้ว่านี่เป็นคำพิมพ์ผิดฝั่ง Apple หรือเปล่า ถึงอย่างไรก็แปลกแน่นอน ตรงนี้ต้องใช้
WindowSerialไม่ใช่เติม s อีกตัวแบบWindowsSerialhttps://github.com/JJTech0130/pypush/blob/8b33c0ee5d540d8ac7...
มีเนื้อหาที่เกี่ยวข้องเพิ่มเติม: https://news.ycombinator.com/item?id=38531759
โปรเจกต์โอเพนซอร์ส pypush ซึ่งเป็นพื้นฐานของข่าวการรีเวิร์ส iMessage วันนี้ เผยแพร่ภายใต้ Server Side Public License ของ MongoDB และเจ้าของคือ Beeper
ตามที่ JJTech พูดใน Discord เขาขายสิทธิ์ให้ Beeper แล้ว
ไลบรารียอดเยี่ยม แต่เป็นไลเซนส์แบบ copyleft ที่เข้มมาก จึงน่าจะมีผลต่อว่าจะนำไปใช้ที่ไหนได้บ้าง
ได้ยินว่า “validation data” ที่จำเป็นตอนสร้างคำขอลงทะเบียน IDS เป็นกลไกที่ Apple ใช้ตรวจสอบไม่ให้อุปกรณ์ที่ไม่ใช่ของ Apple ใช้ iMessage เลยสงสัยว่าถ้า DSA หรือ DMA ของ EU มีผลบังคับใช้ สิ่งนี้จะถือว่าละเมิดหรือไม่
ไม่ว่า Apple จะปฏิบัติตาม DSA และ DMA ด้วยวิธีใด ก็คงไม่ใช่วิธีนี้
iMessage ข้ามแพลตฟอร์มแบบ 1st-party เป็นเพียงความฝันลม ๆ แล้ง ๆ ของสายเทคเป็นหลัก และโดยส่วนตัวก็คิดว่าแค่นั้นก็โอเคพอแล้ว
เมื่อดูประกาศของ Beeper Mini [1] จะเห็นว่าระบุชัดเจนว่าผู้ใช้สามารถลงทะเบียนหมายเลขโทรศัพท์และส่งรับ iMessage ได้โดยไม่ต้องมี Apple ID
นอกจากนี้ยังอธิบายว่าอุปกรณ์สื่อสารกับ Apple โดยตรง
แต่บทความนี้บอกว่า IDS ถูกใช้เป็นคีย์เซิร์ฟเวอร์ของ iMessage และขั้นแรกของการลงทะเบียน IDS ต้องใช้ชื่อผู้ใช้และรหัสผ่าน Apple ID เพื่อรับโทเค็นยืนยันตัวตน จากนั้นจึงใช้ identity keypair ที่ได้รับหลังลงทะเบียนเพื่อค้นหากุญแจสาธารณะ
ถ้าอย่างนั้นก็สงสัยว่าแอป Beeper Mini ลงทะเบียนหมายเลขโทรศัพท์ Android ใด ๆ กับ IDS เป็นกุญแจสาธารณะ และค้นหากุญแจสาธารณะของผู้รับได้อย่างไร โดยไม่ใช้ Apple ID
คำตอบน่าจะเป็น SMS Gateway ซึ่งแทบไม่ได้อธิบายไว้ทั้งในบทความต้นฉบับหรือ [1] และดูเหมือนจะเป็นส่วนผสมลับ
[1] https://blog.beeper.com/i/139416474/security-and-privacy
เป็นงานที่น่าทึ่งจริง ๆ
แต่มีจุดหนึ่งในบทความที่ติดใจ คือส่วนที่บอกว่ารูปแบบ pair เดิมมีเอกสารดีกว่าและนำไปใช้ได้ง่ายกว่า แต่ไม่ให้ forward secrecy ด้วย “pre-keys” แบบคล้าย Signal เหมือนรูปแบบ pair-ec ใหม่
ไม่แน่ใจว่ามีหลักฐานหรือไม่ว่า iMessage รุ่นใหม่ หรือก็คือที่ใช้ ECIES ใช้ pre-key จริง ๆ
ในมุมผม มันดูเหมือนแค่เอา ECIES มาเสียบแทน RSA ในส่วนการเข้ารหัส หรืออาจรวมถึงส่วนลายเซ็น ซึ่งแค่นั้นไม่ได้ทำให้เกิด forward secrecy
ถ้าไม่มีหลักฐาน ก็อาจเป็นการตีความความสัมพันธ์ระหว่าง RSA, elliptic curve และ forward secrecy ผิด
บทความ iMessage ใน Wikipedia ก็ดูเหมือนจะเผยแพร่ความผิดพลาดเดียวกัน และเอกสารอ้างอิงที่อ้างถึงก็ไม่ได้กล่าวอ้างแบบนั้นจริง ๆ