ในบทความนี้ จะขอนำทุกท่านไปรู้จักกับ Application Signing model และ Approval process พร้อมกับวิเคราะห์ถึงประโยชน์และข้อจำกัดในมุมมองด้านความมั่นคงปลอดภัย ขอเว้นการอธิบายถึงขั้นตอนการ Sign แอปพลิเคชันหรือการส่งแอปพลิเคชันเข้ากระบวนการ Approval เพื่อขึ้น Official App Store ของแต่ละ platform เนื่องจากสามารถหาอ่านได้จากเว็บไซต์ของ Platform provider

Application Signing model และ Approval process ถือเป็นอีกหนึ่งขั้นตอนสำคัญที่ช่วยยกระดับความมั่นคงปลอดภัยให้กับแอปพลิเคชันบนอุปกรณ์พกพา แต่ทุกอย่างย่อมมีข้อจำกัด แล้ว Application Signing model กับ Approval process จะมีส่วนช่วยด้านความมั่นคงปลอดภัยอย่างไร และมีข้อจำกัดอย่างไรบ้าง สามารถอ่านได้จากเนื้อหาต่อไปนี้

CHAPTER 1

Application Signing model

Application Signing หรือ Code Signing คือการ Sign แอปพลิเคชันด้วย Certificate หรือ keystore ของผู้เผยแพร่แอปพลิเคชันดังกล่าว การ Sign แอปพลิเคชันไม่ใช่เพื่อการระบุตัวตนของผู้พัฒนา แต่คือเพื่อยืนยันความเป็นเจ้าของของแอปพลิเคชันนั้น (Digital Signature) และรักษาความถูกต้องสมบูรณ์ (Integrity) ของแอปพลิเคชัน ไม่ให้ถูกดัดแปลงหรือแก้ไขได้โดยที่ผู้ที่ไม่ได้รับอนุญาต ที่ผู้เขียนตั้งใจใช้คำว่า "ผู้เผยแพร่ (Publisher)" เพราะว่าในบางครั้ง ผู้พัฒนากับผู้เผยแพร่แอปพลิเคชัน อาจไม่ใช่คนเดียวกันเสมอไป และบ่อยครั้ง แอปพลิเคชันมักถูกเผยแพร่ในนามของบริษัท/องค์กร

หมายเหตุ: ขออธิบายเพิ่มเติมอีกเล็กน้อยสำหรับคำว่า Certificate ในที่นี้หมายถึง Certificate ที่มีนามสกุลเป็น .pfx เท่านั้น เพราะ .pfx คือการรวมเอา Private key และ Public key มารวมกันไว้ในไฟล์เดียว และการ Sign แอปพลิเคชันตามทฤษฎีก็จะเหมือนกับการทำ Digital Signature คือต้องใช้ Private key ในการ Sign เพื่อจะได้คงคุณสมบัติความถูกต้องสมบูรณ์ของตัวแอปพลิเคชันได้นั่นเอง Certificate ทั่วไปที่เก็บเพียงค่าของ Public Key เช่น .cer, .pem, .crt และอื่น ๆ ไม่สามารถนำมาใช้ Sign แอปพลิเคชันได้

การ Sign แอปพลิเคชัน อย่างที่บอกไปแล้วว่า เพื่อรักษาความถูกต้องสมบูรณ์ของแอปพลิเคชัน นั่นหมายถึงหากมีใครมา Reverse Engineer แอปพลิเคชันของเราแล้วแก้ไขหรือฝัง Malware ลงไป วิธีนี้มักถูกเรียกกันทั่วไปว่า Mod(ify) Application; แอปพลิเคชันที่ถูก Mod จะต้องนำไป Sign ใหม่ และหากผู้ที่ทำ Mod app กับผู้เผยแพร่แอปพลิเคชันเป็นคนละคนกัน ก็จะทำให้ Mod app ถูก Sign ด้วย Identity ที่ต่างกัน เมื่อ Mod app ถูกนำไปติดตั้งลงบนอุปกรณ์ก็จะถูกมองว่าเป็นคนละแอปพลิเคชันแทนและไม่สามารถเข้าถึงข้อมูลของแอปพลิเคชันเดิมได้ (กรณีที่มีทั้งแอปพลิเคชัน ก่อนและหลังแก้ไขที่ถูก Sign ด้วยคนละ Identity ในอุปกรณ์เดียวกัน) แม้ว่า Mod app ดังกล่าวจะมีไอคอน ชื่อ และทุก ๆ อย่างเหมือนแอปพลิเคชันเดิมก็ตาม

แอปพลิเคชันที่ไม่ได้รับการ Sign จะไม่สามารถนำไปติดตั้งหรือรันบนอุปกรณ์ได้ บางคนอาจอยากแย้งว่า "เคยเขียนแอปพลิเคชันก็ไม่เห็นต้อง Sign อะไรเลย สามารถเอาไปรันบน Emulator หรือบนอุปกรณ์ทดสอบได้ปกติ" นั่นเพราะว่า IDE ที่แต่ละ Mobile Platform Provider ได้พัฒนาขึ้นมาไม่ว่าจะเป็น Xcode, Android Studio, Visual Studio และอื่น ๆ ส่วนมากล้วนมีฟีเจอร์ในการ Sign แอปพลิเคชันมาให้ในตัวอยู่แล้ว เพื่ออำนวยความสะดวกให้นักพัฒนาสามารถ Build แอปพลิเคชันเพื่อนำไปทดสอบได้ง่ายขึ้น โดยแอปพลิเคชันที่ Build สำหรับใช้ทดสอบจะถูก Sign ด้วย debug key หรือ Self-signed Certificated ที่ตัว IDE สร้างให้อัตโนมัติ

แล้วจะเกิดอะไรขึ้น ถ้าแอปพลิเคชันถูก Signed ด้วย Keystore/Certificate ที่หมดอายุ หรือไม่น่าเชื่อถือ?

ถ้า Keystore/Certificate หมดอายุ Keystore/Certificate ดังกล่าวจะไม่สามารถนำไป Sign แอปพลิเคชันใดได้อีก ตัวโปรแกรมที่ใช้ในการ Sign จะฟ้องว่า Keystore/Certificate ดังกล่าวหมดอายุแล้ว และสำหรับแอปพลิเคชันที่ถูก Sign ด้วย Keystore/Certificate ที่หมดอายุไปแล้ว จะไม่สามารถนำไปติดตั้งได้ เพราะก่อนการติดตั้งลงบนอุปกรณ์ ตัว OS จะมีการตรวจสอบความถูกต้องของ Keystore/Certificate เสียก่อน โดยกรณีนี้สามารถแก้ไขได้โดยการต่ออายุ หรือสร้าง Keystore/Certificate ใหม่ขึ้นมาใช้แทนอันเดิม

ส่วน Keystore/Certificate ที่ไม่น่าเชื่อถือ เช่น debug key, self-signed certificateเป็นต้น สาเหตุของกรณีนี้มักมาจากการติดตั้งแอปพลิเคชันที่ไม่อยู่บน Official Application Store จึงถือว่าไม่ได้รับการรับรองอย่างถูกต้องจาก Platform Provider ตัว OS จะให้ผู้ใช้เป็นคนตัดสินใจเองว่าจะยอมเชื่อแอปพลิเคชันดังกล่าวหรือไม่ และแอปพลิเคชันดังกล่าวจะไม่สามารถรันได้ จนกว่าผู้ใช้จะเชื่อถือแอปพลิเคชันนั้นก่อน

Application Signing model ของ Apple

Apple จะใช้คำว่า Application Code Signing ขั้นตอนการ Sign คือผู้เผยแพร่จะต้องมี Certificate เสียก่อน โดย Certificate นี้จะออกโดย Apple แต่ก็ไม่ได้หมายความว่าจะปลอดภัย เพราะแค่หมายถึงผู้เผยแพร่คนดังกล่าวได้รับอนุญาตให้เผยแพร่แอปพลิเคชันสำหรับอุปกรณ์ Apple เพียงเท่านั้น ไม่ได้การันตีถึงคุณภาพหรือความปลอดภัยของตัวผู้เผยแพร่แต่อย่างใด

ด้วยเหตุนี้ Apple จึงมีสิทธิเพิกถอน Certificate ของผู้เผยแพร่ได้ทุกเมื่อ หากพบว่ามีการกระทำความผิด เมื่อ Certificate ไม่ได้รับการรับรองอีกต่อไป จะทำให้แอปพลิเคชันที่ถูก Sign ด้วย Certificate ดังกล่าวจะไม่สามารถนำไปรันต่อได้ แต่แอปพลิเคชันเดิมสามารถถูก Sign ด้วย Certificate ใหม่และนำไปเผยแพร่ใหม่ได้

ข้อมูลเพิ่มเติม: https://developer.apple.com/support/code-signing/

Application Signing model ของ iOS

Application Signing model ของ Android

Android เสนอ 2 ทางเลือกให้กับผู้เผยแพร่ในการ Sign แอปพลิเคชัน ซึ่งแต่ละทางเลือกจะมีข้อดีข้อเสียต่างกัน ขึ้นอยู่กับว่า ใครถนัดแบบไหน และเหมาะกับแบบไหนมากกว่า

1. ฝาก Signing key ไว้กับ Google — ผู้เผยแพร่ไม่ต้องเก็บรักษา key ไว้เอง ทำให้โอกาสที่ Signing key จะถูกขโมยจากการถูกยึดเครื่องลดลง แต่จะไปเสี่ยงที่การถูกขโมยระหว่างการส่งให้กับ Google แทน ขั้นตอนคือผู้เผยแพร่จะต้องทำการเข้ารหัส Signing key และส่งให้กับ Google ก่อน จากนั้นให้ทำการสร้าง key อีกอันที่ชื่อว่า Upload key แล้วนำไปลงทะเบียนกับ Google เพื่อผูกกับ Signing key ที่ได้ส่งไปก่อนหน้านี้ กระบวนการนี้จะทำเพียงครั้งเดียว ข้อดีของวิธีนี้คือเน้นความปลอดภัยสูงแค่ตอนส่ง Signing key ให้กับ Google ก็พอ ทำให้ประหยัดเวลาและงบได้มากกว่าการต้องปกป้อง Signing key ไว้กับตัวเอง

Application Signing model ของ Android แบบที่ 1

เมื่อผู้เผยแพร่ต้องการส่งแอปพลิเคชันขึ้น Playstore ก็จะ Sign แอปพลิเคชันดังกล่าวด้วย Upload key ส่งให้กับทาง Google ซึ่งทาง Google ก็จะใช้ Upload key ที่ได้ Sign ไปในการระบุหา Siging key ของผู้เผยแพร่ที่ฝากไว้ แล้วใช้ Signing key นั้นในการ Sign แอปพลิเคชันและเผยแพร่แทน

วิธีนี้อาจถูกมองว่าปลอดภัย เพราะ Signing key ฝากไว้กับ Google แต่ว่า Upload key ก็ยังคงอยู่ในความรับผิดชอบของผู้เผยแพร่อยู่ดี เพียงแต่ว่าหาก Upload key หายหรือถูกขโมย ผู้เผยแพร่แค่แจ้งไปยัง Google เพื่อยกเลิกการใช้งาน Upload key ดังกล่าวและสร้าง Upload key ใหม่แทน ซึ่งช่วยประหยัดเวลาได้มากกว่าการสร้าง Signing key ใหม่ การยกเลิก Upload key จะไม่ส่งผลใด ๆ ต่อแอปพลิเคชันที่เคยถูก Sign ไปแล้ว เพราะ Upload key ใช้เพื่อระบุหา Signing key ที่ฝากไว้กับ Google เท่านั้น

2. เก็บ Signing key ไว้เอง — เป็นวิธีที่ดูเหมือนจะอันตรายเพราะหาก Signing key ถูกขโมยก็จะเกิดผลกระทบมหาศาล แถมยังต้องเสียเวลาเพิกถอนและสร้างขึ้นใหม่อีก ซึ่งยุ่งยากกว่าการสร้าง Upload key หลายเท่าตัว แต่หากคิดว่าสามารถเก็บรักษา Signing key ได้อย่างปลอดภัยอยู่แล้ว วิธีนี้ก็ค่อนข้างเหมาะสม เพราะไม่ต้องเสียเวลาส่ง key ให้กับ Google และต้องคอยรักษา Upload key อีกอยู่ดี

Application Signing model ของ Android แบบที่ 2

ข้อมูลเพิ่มเติม: https://developer.android.com/studio/publish/app-signing

Application Signing model ของ Microsoft

รูปแบบของ Microsoft จะคล้ายกับ Apple คือ ใช้ Certificate ในการ Sign แอปพลิเคชันเหมือนกัน แต่ว่า Microsoft ปล่อยให้ผู้เผยแพร่เป็นคนสร้าง Certificate ขึ้นมาเอง แทนที่จะสร้างให้เหมือนกับ Apple ขั้นตอนก็คือ เริ่มต้นจากการสร้าง key-pair ขึ้นมา (Public key & Private key) แล้วทำการแปลง key-pair ให้ไปเป็น Personal Infomation Exchange (.pfx) เพื่อนำไปใช้ Sign แอปพลิเคชันต่อไป แต่การให้สร้าง Certificate เองก็ไม่ได้หมายความว่ารูปแบบนี้ของ Microsoft ไม่ปลอดภัย เพราะ Certificate ดังกล่าวจะต้องมี Root CA ที่เชื่อถือได้เหมือนกัน (ต้องมี Certificate ที่ออกอย่างถูกต้อง ไม่ใช่ Self-Signed)

ข้อมูลเพิ่มเติม how-to-create-a-package-signing-certificate

ประโยชน์ของ Application Siging model

1. ช่วยให้ผู้เผยแพร่และผู้ใช้งานมั่นใจได้ว่าแอปพลิเคชันนั้นจะไม่ถูกดัดแปลงโดยผู้อื่นอย่างแน่นอน และผู้เผยแพร่เพียงคนเดียวเท่านั้นที่สามารถการแก้ไข/ดัดแปลงแอปพลิเคชันแล้วเผยแพร่ใหม่ในนามของแอปพลิเคชันเดิมได้ หรือก็คือ Version Update
2. แอปพลิเคชันที่ถูก Sign ด้วย Identity เดียวกัน จะสามารถแชร์ข้อมูลให้กันและกันได้ด้วยการตั้งค่าแอปพลิเคชันให้อยู่ใน App Group เดียวกัน **แอปพลิเคชันจะสามารถเข้าถึง shared directory ที่ถูกกำหนดไว้เท่านั้น ไม่สามารถเข้าถึงข้อมูลที่อยู่ใน Sandbox หรือแทรกแซงการทำงานระหว่างแอปพลิเคชันได้

ข้อจำกัดของ Application Signing model

1. แม้ว่าแอปพลิเคชันถูก Sign โดยผู้เผยแพร่ที่น่าเชื่อถือเพียงใดก็ไม่ได้การันตีว่าแอปพลิเคชันดังกล่าวมีความปลอดภัยหรือไร้ช่องโหว่
2. การ Sign แอปพลิเคชันไม่ได้การันตีว่าแอปพลิเคชันไม่มี Malware แอบแฝง
3. หาก Certificate หรือ keystore ของผู้เผยแพร่ถูกขโมยไป คนที่ได้ Certificate หรือ keystore นั้นไปก็เท่ากับมีสิทธิในการแก้ไขหรือดัดแปลงแอปพลิเคชันทั้งหมดของผู้เผยแพร่ได้อย่างเต็มที่โดยที่ยังคง Identity ของผู้เผยแพร่ไว้ได้ ซึ่งถือว่าส่งผลกระทบอย่างมหาศาลทั้งต่อผู้เผยแพร่และผู้ใช้

ด้วยข้อจำกัดของ Application Signing model ทำให้การ Sign แอปพลิเคชันอย่างเดียวอาจไม่เพียงพอที่จะปกป้องผู้ใช้ให้ปลอดภัยจากการติดตั้งแอปพลิเคชันทั้งหลายได้ ดังนั้น Platform Provider แต่ละเจ้าจึงต้องมีกระบวนการคัดกรองแอปพลิเคชันให้แน่ใจเสียก่อนว่าแอปพลิเคชันดังกล่าวจะไม่เป็นภัยต่อผู้ใช้งาน ซึ่งกระบวนการดังกล่าวถูกเรียกว่า Approval Process โดยจะขอพูดถึงในตอนต่อไป

To be continued…

Part 2

Application Signing model and Approval process (2/2)

Application Signing model มีจุดประสงค์หลักเพื่อใช้ในการยืนยันความถูกต้อง (Integrity) ของแอปพลิเคชันว่าไม่ได้ถูกดัดแปลงหรือแก้ไขโดยผู้ที่ไม่ใช่เจ้าของ หรือเรียกง่าย ๆ ก็คือการทำ Digital Signature สำหรับแอปพลิเคชันที่ไม่ได้รับการ Sign จะไม่สามารถนำไปติดตั้งลงบนอุปกรณ์ได้ ทั้งนี้การ Sign แอปพลิเคชันไม่ได้หมายความว่าแอปพลิเคชันนั้นจะปลอดภัยต่อการใช้งาน

To be continued