ความสามารถในการเข้ารหัสจากปลายทางถึงปลายทาง (end-to-end encryption) เป็นความสามารถที่ผู้ให้บริการหลายรายใช้โฆษณากันว่าบริการส่งข้อมูลของตนมีความสามารถปลอดภัยจากการดักฟัง
แนวคิดของการเข้ารหัสจากปลายทางถึงปลายทางเป็นผลจากผู้ให้บริการส่วนมากมักสามารถดูข้อมูลของเราได้เสมอ บริการเช่น Gmail นั้นตัวกูเกิลเองอาจจะเข้ามาดูข้อมูลอีเมลของเราเมื่อใดก็ได้หากต้องการ และในความเป็นจริงก็มีการใช้ซอฟต์แวร์เข้ามาวิเคราะห์เนื้อหาในอีเมลของเราเพื่อแสดงโฆษณาให้ตรงเนื้อหาที่เราสนใจ แต่ในหลายกรณีเราไม่ต้องการให้ใครแม้แต่ผู้ให้บริการเองเข้ามาอ่านเนื้อหาของเรา
กระบวนการเข้ารหัสจากปลายทางถึงปลายทางมีการใช้งานมานาน ที่พอจะได้รับความนิยมอยู่บ้างคือระบบอีเมลแบบ PGP (Pretty Good Privacy) ที่ผู้ใช้ทุกคนต้องสร้างกุญแจลับและกุญแจสาธารณะขึ้นมาด้วยตนเอง จากนั้นเมื่อต้องการส่งอีเมล แทนที่จะส่งอีเมลเป็นเนื้อความธรรมดา ก็เปลี่ยนเป็นอีเมลที่เข้ารหัสด้วยกุญแจสาธารณะของฝั่งตรงข้าม ทำให้เรามีผู้ที่สามารถอ่านอีเมลได้เพียงแค่ผู้ที่ถือกุญแจลับที่เข้าคู่กับกุญแจสาธารณะที่เราส่งไปหาเท่านั้น
ปัญหาสำคัญของ PGP คือกระบวนการหาว่ากุญแจสาธารณะที่ถูกต้องของฝั่งตรงข้ามนั้นคือกุญแจใดกลายเป็นเรื่องยุ่งยากและซับซ้อน หลายคนส่งกุญแจสาธารณะกันทางนามบัตร เพื่อให้สามารถส่งอีเมลแบบเข้ารหัสถึงกันได้เฉพาะเวลา กระบวนการนี้ยุ่งยาก ซับซ้อน จนทำให้ PGP ไม่ได้รับความนิยมแม้จะมีกระบวนการที่ปลอดภัยเป็นอย่างดีตลอดหลายสิบปีที่ผ่านมา บริการสมัยใหม่แม้จะมีแนวคิดอยากเข้ารหัสจากปลายทางถึงปลายทาง เช่นบริการ iMessage ของแอปเปิล แต่เพื่อความสะดวกก็มักจะอาศัยเซิร์ฟเวอร์ของบริษัทเพื่อแจกกุญแจสาธารณะ
ปัญหาของกระบวนการใช้กุญแจสาธารณะจากเซิร์ฟเวอร์ศูนย์กลาง คือในความเป็นจริงแล้ว ผู้ให้บริการมีสิทธิที่จะเปลี่ยนกุญแจด้วยตัวเองเป็นกุญแจใดๆ ก็ได้ ไม่มีอะไรรับประกันว่าหากแอปเปิลได้รับคำสั่งจากรัฐบาล แล้วแอปเปิลจะไม่เปลี่ยนกุญแจเข้ารหัสเป็นกุญแจที่สร้างขึ้นใหม่สำหรับการดักฟังโดยเฉพาะทำให้ข้อมูลที่เราส่งออกไปสามารถดักฟังจากจุดดักฟังได้ แม้จะมีการเข้ารหัสที่เราเชื่อว่าเป็นการเข้ารหัส "จากปลายทางถึงปลายทาง"
เพื่อให้ยุติธรรมกับแอปเปิล เราควรตระหนักว่าระบบแบบนี้ที่จริงแล้วค่อนข้างปลอดภัยกว่าบริการทั่วไปมาก บริการทั่วไปที่ไม่มีการเข้ารหัสจากปลายทางถึงปลายทางเลย เช่น บริการ Hangouts ของกูเกิลนั้นอาศัยความเชื่อใจระหว่างเรากับกูเกิลเป็นสำคัญ หากกูเกิลร่วมมือกับใครก็สามารถเข้าค้นประวัติข้อความของเราได้ทันทีโดยไม่ต้องส่งกุญแจปลอมมาให้เราใหม่แต่อย่างใด
กระบวนการของแอปเปิลนั้นมีประเด็นสำคัญคือผู้ใช้ไม่ได้รับรู้ว่า Apple ID ใดมีกุญแจสาธารณะค่าใดบ้าง แอปเปิลเลือกที่จะซ่อนความซับซ้อนในกระบวนการรหัสวิทยาเอาไว้ไม่ให้ผู้ใช้ทั่วไปเข้าถึง ช่วงปลายปีที่แล้วมีการเสนอทางออกให้ผู้ใช้ iMessage สามารถอ่านค่ากุญแจสาธารณะของบัญชีที่กำลังเชื่อมต่อด้วยได้ ทำให้ผู้ใช้รู้ตัวตลอดเวลาว่ากุญแจของผู้ใช้รายอื่นๆ ที่เรากำลังพูดคุยด้วยมีการเปลี่ยนค่าไปจากเดิมหรือไม่ (หากเปลี่ยนค่าไปเราก็ต้องแน่ใจว่าเป็นค่าจริง เช่น เพื่อนของเราเปลี่ยนโทรศัพท์หรือไม่) โดยใช้ชื่อซอฟต์แวร์ว่า iMITMProtect แม้แอปเปิลจะไม่เปิดให้ตรวจสอบได้ แต่ในความเป็นจริงแล้วหากผู้ใช้เป็นผู้มีความรู้ความชำนาญก็สามารถสังเกตได้ว่าแอปเปิลเปลี่ยนกุญแจอย่างจงใจหรือไม่
บริการเข้ารหัสแชตแบบปลายทางถึงปลายทางมีการเสนอให้มีความปลอดภัยเทียบเท่าหรือมากกว่าอีเมลเข้ารหัสแบบ PGP กันเรื่อยมา ในบทความนี้เราจะยกตัวอย่าง TextSecure แอพพลิเคชั่นแชตบนโทรศัพท์มือถือทั้งแอนดรอยด์และไอโฟน จุดสำคัญที่ทำให้ TextSecure ได้รับความสนใจ คือ โปรโตคอลของมันถูกออกแบบโดย Moxie Marlinspike นักรหัสวิทยาที่มีชื่อเสียงจากการวิเคราะห์โปรโตคอลความปลอดภัยมาแล้วหลายครั้ง เช่นปัญหา sslstrip, null prefix, เสนอให้ทำ certificate pinning ที่เริ่มได้รับความนิยมในปัจจุบัน, และสาธิตการโจมตี MSCHAPv2 ที่ใช้งานเป็นวงกว้างในการทำ VPN แบบ PPTP ภายใน 24 ชั่วโมง
Alice
Sending | Receiving
MK CK RK CK MK ECDH(A0,B0)
|
|
ECDH(A1,B0) +
/|
/ |
/ + ECDH(A1,B1)
CK-A1-B0 |\
| | \
MK-0 ----+ | \
| | CK-A1-B1
MK-1 ----+ | |
| | +---- MK-0
MK-2 ----+ | |
| +---- MK-1
ECDH(A2,B1) +
/|
/ |
/ |
CK-A2-B1 |
| + ECDH(A2,B2)
MK-0 ----+ \
\
\
CK-A2-B2
|
+---- MK-0
|
+---- MK-1โปรโตคอลเข้ารหัสที่เป็นหัวใจของ TextSecure มีชื่อว่า Axolotl Ratchet กระบวนการหลักของมันคือการอาศัยการสร้างกุญแจการแลกเปลี่ยนข้อมูลด้วยกระบวนการ Diffie-Hellman เพื่อรับประกันความเป็นความลับในอนาคต (forward secrecy) โดยมีกระบวนการสับเปลี่ยนกุญแจไปเรื่อยๆ เป็นลำดับ (ratchet - สับฟันเฟือง) ทำให้เมื่อมีการพูดคุยในห้องแชต ทุกครั้งที่มีการส่งข้อความกลับไปมา กุญแจเข้ารหัสข้อความจะถูกเปลี่ยนไปทุกครั้ง และตัวแอพพลิเคชั่นจะลืมกุญแจที่ถูกส่งไปแล้วก่อนหน้านี้ไปเรื่อยๆ ทำให้แม้จะดักข้อความที่เข้ารหัสแล้วได้ กระบวนการกู้คืนข้อความที่ยังไม่ได้เข้ารหัสก็ทำได้ยากมาก เพราะตัวแอพพลิเคชั่นเองก็เก็บกุญแจสำหรับถอดรหัสเอาไว้ไม่นานนัก โปรโตคอลนี้มีขนาดข้อความโดยรวมที่เล็ก และแยกโปรโตคอลนี้ออกจากตัวแอพพลิเคชั่นแชตอย่างชัดเจนทำให้สามารถนำไปใช้ในแอพพลิเคชั่นอื่นๆ ได้ เช่น Pond ก็ตัดสินใจใช้ Axolotl Ratchet เช่นกัน
note: ที่ถูกต้องคือกระบวนการ Elliptic curve Diffie–Hellman หรือ ECDH หลักการทำงานคล้าย Diffie-Hellman ปกติ แต่ใช้การคำนวณ Elliptic curve เพื่อให้ได้ความปลอดภัยเท่ากันในขณะที่ตัวเลขกุญแจมีขนาดเล็กลงมาก อ่านเรื่อง Diffie-Hellman เพิ่มเติมได้ในบทความเก่า โดย TextSecure เลือกใช้ ECDH บน Curve25519 ที่รับอินพุตเป็นกุญแจสาธารณะของฝั่งตรงข้ามและกุญแจลับของเรา ฟังก์ชั่น Curve25519 จะให้ผลลัพธ์เป็นตัวเลขที่เป็นความลับระหว่างเราและฝ่ายที่ให้กุญแจสาธารณะกับเราขนาด 256 บิตออกมา โดยเป็นค่าเฉพาะสำหรับคู่กุญแจลับและกุญแจสาธารณะแต่ละคู่
ตัว Axolotl Ratchet นั้นเป็นเพียงกระบวนการ "แลกกุญแจ" (key exchange) เท่านั้น เมื่อแลกกุญแจซึ่งเป็นเลขสุ่มขนาดใหญ่ได้แล้วก็จะใช้หมายเลขนี้เป็นกุญแจสำหรับการเข้ารหัสแบบ AES-256 ต่อไป
TextSecure ยังรองรับความสามารถเพิ่มเติม เช่น การส่งข้อความผ่าน SMS ด้วยการส่งข้อความเข้ารหัส แต่ encode แบบ Base64 เพื่อให้กลายเป็นตัวอักษรส่งผ่าน SMS ไปได้ ทำให้เราสามารถพูดคุยกับคนรู้จักอยู่แล้วผ่านทางหมายเลขโทรศัพท์ได้ทันที โดยที่ผู้ให้บริการโทรศัพท์มือถือไม่สามารถอ่านข้อความของเราได้อีกต่อไป
กระบวนการเข้ารหัสที่ซับซ้อนของ TextSecure ถูกซ่อนไว้ด้วยกระบวนการใช้งานที่ไม่ต่างจาก iMessage หรือ Hangouts มากนัก เพื่อเราส่งข้อความผ่าน TextSecure ไปหาเพื่อนของเราครั้งแรกไม่ว่าจะผ่านอินเทอร์เน็ตหรือ SMS ตัวซอฟต์แวร์จะแลกกุญแจสาธารณะต่อกัน พร้อมกับขึ้นเตือนผู้ใช้ว่าซอฟต์แวร์ไม่รู้จักกุญแจนี้มาก่อน จุดนี้เป็นจุดต่างสำคัญที่ iMessage ของแอปเปิลไม่แจ้งเตือนเพราะเชื่อว่าแอปเปิลจะไม่ส่งกุญแจปลอมมาให้ แม้ผู้ใช้เปลี่ยนเครื่องหรือไม่เหตุอื่นๆ ที่ต้องเปลี่ยนคู่กุญแจสาธารณะ/กุญแจลับ ตัว iMessage ก็จะเปลี่ยนให้เองโดยผู้ใช้ไม่สามารถตรวจสอบได้ ในกรณีของ TextSecure นั้นผู้ใช้จะมองเห็นกุญแจสาธารณะของผู้ใช้ที่เราเพิ่มยอมรับเข้ามาทั้งหมด พร้อมกับสามารถดูกุญแจสาธารณะของเราเองที่อยู่ในเครื่องของเราได้ด้วย
กระบวนการยืนยันว่าเรากำลังติดต่อกับฝ่ายตรงข้ามที่เป็นคนที่เรารู้จักจริงหรือไม่ของ TextSecure จึงไม่จำเป็นต้องอาศัยความเชื่อใจบริการ TextSecure (หรือเซิร์ฟเวอร์อื่นๆ ที่ใช้โปรโตคอลเดียวกัน) เมื่อเราพบกับคนที่เราคุยด้วยใน TextSecure หรือมีช่องทางอื่นๆ ในการสื่อสารถึงกัน เราสามารถส่ง "ลายนิ้วมือ" (fingerprint) ของกุญแจของเราเพื่อยืนยันตัวตนกับเพื่อนของเราได้ ว่าที่กำลังคุยกันอยู่นี้เป็นคู่สนทนาที่ถูกต้อง
การยืนยันกุญแจสาธารณะที่ต้องทำยืนยันซ้ำจากการสื่อสารด้วยช่องทางอื่น ทำให้รายชื่อคู่สนทนา (contact list) ของ TextSecure ต้องรักษาไว้อย่างดี เช่นเดียวกับคู่กุญแจลับและกุญแจสาธารณะของเราที่สร้างขึ้นใหม่ในตอนที่ลงแอพพลิเคชั่นครั้งแรกก็จำเป็นต้องรักษาไว้ด้วยเช่นกัน ตัว TextSecure เมื่อติดตั้งนั้นจะแนะนำให้ผู้ใช้ใส่รหัสผ่าน เพื่อล็อกการเข้าถึงแอพพลิเคชั่น หากเราเลือกที่จะตั้งรหัสผ่านนี้ TextSecure จะเข้ารหัสไฟล์ทั้งหมดด้วย AES-128 ทันที ล็อกข้อความที่คุยกันทั้งหมดจะไม่สามารถเปิดกลับขึ้นมาได้อีกหากไม่มีรหัสที่ถูกต้อง และไม่มีกระบวนการกู้คืนรหัสใดๆ ไฟล์สำรองข้อมูลของ TextSecure เมื่อเราสั่ง export ไฟล์เพื่อเก็บสำรองไว้ใช้ในอนาคตจะสามารถเลือกได้ว่าต้องการเข้ารหัสไฟล์หรือไม่ หากเราเลือกที่จะไม่เข้ารหัสต้องเก็บรักษาไฟล์นี้ไว้อย่างดี เพราะหากมีคนอื่นได้ไปก็สามารถปลอมตัวเป็นเราได้อย่างสมบูรณ์
TextSecure เป็นโปรโตคอลที่เป็นตัวอย่างของการเข้ารหัสแบบปลายทางถึงปลายทาง อย่างสมบูรณ์ ความเสี่ยงของมันเองทุกวันนี้ยังมีอยู่บ้างเช่นผู้ผลิตซอฟต์แวร์ เช่น หากวันหนึ่งบริษัท OpenWhisperSystems ผู้ผลิตแอพพลิเคชั่นไม่ได้ทำตามโปรโตคอลที่เปิดเผยไว้แต่อาจจะส่งกุญแจลับกลับเซิร์ฟเวอร์ก็อาจจะเป็นช่องทางสำหรับการดักฟังหรือปลอมแปลงได้ อย่างไรก็ดี การเปิดเผยโปรโตคอลรวมถึงซอร์สโค้ดทั้งหมดเป็นจุดเริ่มต้นสำคัญของกระบวนการ ในตอนนี้เริ่มมีการอิมพลีเมนต์แอพพลิเคชั่นบนแพลตฟอร์มอื่นๆ ตามโปรโตคอลบ้างแล้ว หากได้รับความนิยมพอในอนาคตก็อาจจะมีผู้ให้บริการรายอื่นๆ เปิดเซิร์ฟเวอร์ของตัวเองตามมา การฝังช่องโหว่ไว้ในซอฟต์แวร์ก็จะมีความเสี่ยงน้อยลงเพราะผู้ใช้แต่ละคนอาศัยซอฟต์แวร์จากผู้ผลิตแตกต่างกันไป
ที่มา - TextSecure ProtocolV2, Advanced cryptographic ratcheting, Curve25519, iMessage Privacy (PDF)