Kerckhoffs’s Principle
ระบบต้องปลอดภัยแม้ทุกอย่างเปิดเผย — ยกเว้นกุญแจลับ
ใจความสำคัญ
หัวข้อที่มีชื่อว่า “ใจความสำคัญ”Kerckhoffs’s Principle ตั้งชื่อตาม Auguste Kerckhoffs นักเข้ารหัสชาวดัตช์ ผู้ตีพิมพ์บทความ “La Cryptographie Militaire” ในปี 1883 โดยวางกฎ 6 ข้อสำหรับการออกแบบระบบเข้ารหัสทางทหาร มีเพียงข้อที่สองเท่านั้นที่ยังคงถูกอ้างถึงจนถึงทุกวันนี้ นั่นคือ ระบบต้อง ไม่จำเป็นต้องเก็บเป็นความลับ และต้องสามารถตกไปอยู่ในมือศัตรูได้โดยไม่เกิดความเสียหาย
พูดให้สั้นและใช้งานได้จริงกว่านั้น ระบบความปลอดภัยควร ยังคงปลอดภัยแม้ผู้โจมตีจะรู้ทุกรายละเอียดของระบบ ยกเว้นกุญแจลับ (secret key) ต่อมาในปี 1949 Claude Shannon ได้สรุปแนวคิดเดียวกันนี้เป็นประโยคสั้น ๆ ที่รู้จักกันในชื่อ Shannon’s Maxim: “the enemy knows the system” — ให้สมมติว่าศัตรูรู้จักระบบของเราอย่างละเอียดอยู่แล้ว แล้วออกแบบให้ปลอดภัยบนสมมติฐานนั้น
หัวใจคือการแบ่งเส้นให้ชัดระหว่าง code ซึ่งเป็นความรู้สาธารณะได้ กับ data/key ซึ่งต้องเป็นความลับเท่านั้น — Public Code, Private Keys
ความหมายและนัยยะ
หัวข้อที่มีชื่อว่า “ความหมายและนัยยะ”ทำไมหลักการนี้ถึงสำคัญกว่าที่คิด? เพราะมันชี้ปัญหาพื้นฐานของแนวทางตรงข้ามคือ security by obscurity (ความปลอดภัยด้วยการปิดบัง):
- ความลับที่รั่วไหลไม่สามารถย้อนกลับได้ — ถ้าความปลอดภัยของระบบขึ้นกับการปิดบัง algorithm หรือ source code เมื่อมันหลุดออกไปครั้งเดียว (ผ่าน reverse engineering, memory dump, insider, หรือ leak) ระบบทั้งหมดพังทันทีและแก้ไม่ได้ด้วยการเปลี่ยนอะไรง่าย ๆ ต้องออกแบบระบบใหม่ทั้งหมด
- key ที่รั่วไหลแก้ไขได้ง่ายกว่ามาก — ถ้าความปลอดภัยขึ้นกับ key เท่านั้น เมื่อ key หลุด เราแค่ หมุนเวียน (rotate) key ใหม่ ระบบเดิมยังใช้งานได้ต่อ นี่คือสิ่งที่ Bruce Schneier อธิบายไว้ว่า “every secret creates a potential failure point” — ยิ่งมีความลับน้อยจุด ยิ่งมีจุดเสี่ยงน้อย
- การเปิดเผย algorithm เชิญชวนให้ผู้เชี่ยวชาญภายนอกมาช่วยตรวจสอบ — ประวัติศาสตร์ cryptanalysis แสดงให้เห็นซ้ำแล้วซ้ำเล่าว่าการวิเคราะห์แบบเปิดเผย (open review) มักเผยจุดอ่อนที่ทีมออกแบบเดิมมองข้าม และทำให้ algorithm แข็งแกร่งขึ้นในระยะยาว เช่น AES ที่ผ่านการแข่งขันสาธารณะและตรวจสอบโดยนักเข้ารหัสทั่วโลกก่อนถูกเลือกเป็นมาตรฐาน
- obscurity ไม่ใช่ศูนย์ แต่ไม่ควรเป็น “ชั้นความปลอดภัยเดียว” — Kerckhoffs’s Principle ไม่ได้บอกว่าการปิดบังไม่มีประโยชน์เลย (defense in depth ยังมีที่ทางของมัน) แต่เตือนว่า ห้ามพึ่งพามันเป็นกลไกป้องกันหลัก เพราะมันเป็นฐานที่เปราะบางเกินไป
ในบริบทของ software engineering ทั่วไป (ไม่ใช่แค่ cryptography) หลักการนี้แปลงเป็นแนวปฏิบัติที่คุ้นเคย:
- Source code เป็น open source ได้ (หรือแม้แต่ถูก decompile ได้เสมอในกรณี client-side) แต่ credential, API key, password hash, encryption key ต้องแยกเก็บใน environment variable, secrets manager หรือ vault — ไม่ hardcode ลงใน source
- Password ไม่ควรถูกเก็บเป็น plaintext แม้แต่ในระบบที่ “ปลอดภัยดีอยู่แล้ว” — เก็บเป็น hash (พร้อม salt) เพื่อให้ต่อให้ database รั่วไหล ผู้โจมตีก็ยังต้องเจาะ hash function อยู่ดี
- Protocol และ API spec ควรเผยแพร่ได้ (เช่น OAuth 2.0, TLS handshake) เพราะความปลอดภัยพึ่งพา key/certificate ไม่ใช่ความลับของ spec เอง
- การ “ซ่อน” endpoint หรือ business logic โดยหวังว่าไม่มีใครเจอ (obscurity ผ่าน URL ที่เดายาก, ผ่าน minify/obfuscate เพียงอย่างเดียว) ไม่ใช่มาตรการความปลอดภัยที่แท้จริง — เป็นได้แค่ชั้นเสริมที่ทำให้ผู้โจมตีช้าลงชั่วคราว ต้องมี authentication/authorization ที่แท้จริงรองรับอยู่เสมอ
flowchart LR
System[System Design] -->|public knowledge OK| Algorithm[Algorithm and Source Code]
System -->|must stay secret| Key[Secret Key or Credential]
Algorithm -->|reviewed openly| Strength[Stronger over time]
Key -->|compromised| Rotate[Rotate key, system still safe]
Algorithm -->|compromised| Redesign[Full redesign needed]
ตัวอย่างในโลกจริง
หัวข้อที่มีชื่อว่า “ตัวอย่างในโลกจริง”- Content Scrambling System (CSS) ของ DVD (1996) — ระบบเข้ารหัสป้องกันการคัดลอก DVD พึ่งพาการปิดบัง algorithm เป็นหลัก ในปี 1999 โปรแกรมเมอร์ชาวนอร์เวย์ Jon Lech Johansen ทำ reverse engineer จากเครื่องเล่น DVD เชิงพาณิชย์เครื่องหนึ่ง แล้วปล่อยเครื่องมือ DeCSS ที่ถอดรหัสแผ่นได้ในไม่กี่วินาที เพราะ CSS ออกแบบมาโดยฝากความหวังไว้ที่ความลับของ algorithm ล้วน ๆ เมื่อ algorithm หลุด ระบบทั้งระบบก็ใช้ไม่ได้ทันทีสำหรับทุกแผ่นที่เคยผลิตมา — ตัวอย่างคลาสสิกของการละเมิด Kerckhoffs’s Principle
- AES (Advanced Encryption Standard) — ตรงข้ามกับ CSS โดยสิ้นเชิง NIST เปิดให้ทั่วโลกส่ง algorithm เข้าประกวดและให้นักเข้ารหัสจากทุกประเทศช่วยกันโจมตี/วิเคราะห์อย่างเปิดเผยหลายปีก่อนเลือก Rijndael เป็นมาตรฐาน ทุกวันนี้ทุกคนรู้ algorithm ของ AES ทั้งหมด ความปลอดภัยขึ้นอยู่กับความยาวและความลับของ key เท่านั้น — ระบบยังไม่เคยถูกเจาะในทางปฏิบัติ
- Hardcoded credential ใน source code / mobile app — เหตุการณ์ที่พบซ้ำ ๆ ในอุตสาหกรรมคือทีมพัฒนาฝัง API key หรือรหัสผ่านฐานข้อมูลลงใน source code ที่ commit เข้า public GitHub repository หรือฝังไว้ใน mobile app ที่ decompile ได้ง่าย เมื่อ obfuscation ถูกถอดหรือ repo รั่ว ความลับก็หลุดพร้อมกับความมั่นใจที่ผิดว่า “code ปิดอยู่แล้วไม่มีใครเห็น”
- Diebold electronic voting machines (ต้น 2000s) — นักวิจัยด้านความปลอดภัยพบว่าระบบพึ่งพาการปิดบัง source code และ hardware design เป็นหลัก เมื่อ source code หลุดออกมา (โดยไม่ตั้งใจ) นักวิจัยพบช่องโหว่ร้ายแรงจำนวนมากที่ไม่เคยถูกตรวจสอบแบบเปิดมาก่อน สะท้อนความเสี่ยงของระบบ security-critical ที่ปฏิเสธการตรวจสอบสาธารณะ
บทเรียนที่นำไปใช้
หัวข้อที่มีชื่อว่า “บทเรียนที่นำไปใช้”- แยก code ออกจาก secret เสมอ ในโครงสร้างระบบจริง: เก็บ connection string, API token, signing key ไว้ใน secrets manager (เช่น environment variable ที่ inject ตอน deploy, หรือ vault) ไม่ใช่ใน source code หรือ config ที่ commit เข้า repository
- อย่าไว้ใจ obfuscation หรือ minification เป็นมาตรการความปลอดภัย — มันช่วยชะลอผู้โจมตีมือใหม่ได้บ้าง แต่ไม่ใช่การป้องกันจริง ต้องมี authentication/authorization ที่แท้จริงอยู่เบื้องหลังเสมอ (ดู Authentication และ Authorization)
- ออกแบบระบบให้ rotate key ได้ง่าย — ถ้าโครงสร้างระบบผูก key ไว้แน่นจนเปลี่ยนไม่ได้โดยไม่ downtime ก็เท่ากับกำลังสร้างจุดเปราะบางแบบเดียวกับ secret algorithm การ rotate credential ควรเป็นกระบวนการปกติ ไม่ใช่เหตุการณ์ฉุกเฉิน
- เปิดใจให้ code ถูกตรวจสอบ ไม่ว่าจะเป็น code review ภายในทีมหรือ open source — ยิ่งมีสายตาตรวจสอบมากเท่าไร ยิ่งพบจุดอ่อนเร็วขึ้นเท่านั้น แนวคิดนี้สอดคล้องกับ Linus’s Law ที่ว่า “ตาที่มากพอทำให้ bug ทุกตัวตื้น”
- อย่าออกแบบระบบที่ปลอดภัยได้ก็ต่อเมื่อไม่มีใครรู้ว่ามันทำงานอย่างไร — ถ้าพบว่าตัวเองกำลังพึ่งพาการซ่อน business logic หรือปิดบังโครงสร้างระบบเพื่อความปลอดภัย นั่นคือสัญญาณให้กลับไปออกแบบ authentication/authorization ให้แข็งแรงกว่าเดิม เพราะ security ที่แท้จริงต้องรอดแม้ผู้โจมตีมี source code ทั้งหมดอยู่ในมือ
- นำไปปรับใช้กับ software engineering ทั่วไป ไม่จำกัดแค่ cryptography: การเก็บ password เป็น hash, การใช้ signed token แทน session ที่เดาได้, การใช้ least-privilege access control ล้วนเป็นการนำ Kerckhoffs’s Principle มาประยุกต์ใช้ในบริบทกว้างกว่าการเข้ารหัสข้อความ