หมดยุคการเข้ารหัสแบบเดิม? เตรียมองค์กรให้พร้อมสู่ยุค Post-Quantum Cryptography

ช่วงหลายปีที่ผ่านมา เวลาพูดถึง quantum computing คนมักนึกถึงภาพไกลตัว เหมือนเป็นเรื่องของห้องวิจัย บริษัทเทคโนโลยีรายใหญ่ หรืออนาคตอีกหลายปีข้างหน้า แต่ถ้ามองจากมุมของคนดูแลระบบ คนวาง security architecture หรือคนที่ต้องรับผิดชอบข้อมูลสำคัญขององค์กร ผมคิดว่าโจทย์มันไม่ใช่เรื่องไกลตัวขนาดนั้นแล้ว

เหตุผลไม่ใช่เพราะพรุ่งนี้จะมีเครื่อง quantum computer ที่ออกมาเจาะทุกอย่างได้ทันที แต่เพราะงานเปลี่ยนผ่านด้าน cryptography เป็นงานที่ใช้เวลานานมาก ตั้งแต่การหาว่าในองค์กรใช้ public-key cryptography อยู่ตรงไหนบ้าง ไปจนถึงการคุยกับ vendor, การทดสอบ compatibility, การอัปเกรดระบบเก่า และการจัดลำดับว่าข้อมูลชุดไหนต้องป้องกันระยะยาว ถ้ารอให้โลกประกาศว่า "quantum มาแล้ว" ค่อยเริ่มจริง ส่วนใหญ่ก็จะช้าเกินไป

NIST ระบุชัดว่าเมื่อวันที่ 13 สิงหาคม 2024 ได้ออกมาตรฐาน PQC ชุดแรกแล้ว ได้แก่ FIPS 203 สำหรับ ML-KEM, FIPS 204 สำหรับ ML-DSA และ FIPS 205 สำหรับ SLH-DSA ส่วนเมื่อวันที่ 11 มีนาคม 2025 NIST ก็ประกาศเลือก HQC เป็นอัลกอริทึมสำรองสำหรับงาน encryption เพิ่มอีกหนึ่งตัว โดยคาดว่าจะออก draft standard และปิดเป็นมาตรฐานถัดไปในภายหลัง ภาพนี้สะท้อนว่าเรื่อง PQC ไม่ได้อยู่ในสถานะทดลองลอย ๆ อีกต่อไป แต่เริ่มเข้าสู่ช่วงที่องค์กรควรวางแผน migration อย่างจริงจังแล้ว

Post-Quantum Cryptography คืออะไร และอะไรที่กำลังเสี่ยง

พูดแบบสั้นที่สุด PQC คือชุดอัลกอริทึมใหม่ที่ออกแบบมาเพื่อให้ยังต้านทานการโจมตีได้ แม้อนาคตจะมี quantum computer ที่มีความสามารถมากพอจะทำลาย public-key cryptography แบบที่เราใช้กันทุกวันนี้

จุดสำคัญคือความเสี่ยงไม่ได้เท่ากันทุกอย่าง สิ่งที่ถูกพูดถึงมากที่สุดคือระบบที่อาศัย public-key cryptography เช่น การแลกกุญแจ การยืนยันตัวตนด้วย digital signature ใบรับรองดิจิทัล และโปรโตคอลที่อยู่ใต้ TLS, VPN, email security, code signing หรือระบบ identity ต่าง ๆ ขณะที่การเข้ารหัสแบบ symmetric ยังไม่ได้อยู่ในสถานะเดียวกันนี้ ดังนั้นคำว่า "หมดยุคการเข้ารหัสแบบเดิม" จึงไม่ควรถูกตีความว่าเราต้องรื้อทุกอย่างในวันเดียว แต่ควรมองว่า public-key cryptography แบบเดิมกำลังเข้าสู่ช่วงเปลี่ยนผ่าน

อีกประเด็นที่ผมคิดว่าสำคัญมากคือแนวคิด "harvest now, decrypt later" ซึ่ง NIST อธิบายไว้ชัดเจน หมายถึง adversary อาจยังถอดข้อมูลไม่ได้ในวันนี้ แต่สามารถดักเก็บข้อมูลที่เข้ารหัสไว้ก่อน แล้วรอวันที่มีความสามารถถอดรหัสได้ในอนาคต ถ้าข้อมูลขององค์กรมีอายุความลับยาว เช่น ข้อมูลสุขภาพ ข้อมูลทางการเงิน ข้อมูลวิจัย เอกสารสัญญาระยะยาว หรือความลับทางธุรกิจบางประเภท ความเสี่ยงนี้จะไม่ใช่เรื่องทฤษฎีอย่างเดียว

สิ่งที่หลายองค์กรเข้าใจผิดเกี่ยวกับ PQC

เวลาคุยเรื่องนี้ ผมเห็นความเข้าใจผิดอยู่บ่อย 3 แบบ

1. คิดว่ายังไม่ต้องทำอะไร เพราะ quantum computer ที่อันตรายจริงยังไม่มา

ประเด็นนี้ฟังดูสมเหตุสมผล แต่ถ้ามองเชิงปฏิบัติกลับอันตราย เพราะ CISA, NSA และ NIST ออก factsheet ร่วมกันตั้งแต่เดือนสิงหาคม 2023 เพื่อบอกองค์กรให้เริ่มทำ quantum-readiness roadmap แล้ว เหตุผลก็ตรงไปตรงมา คือการย้ายระบบคริปโตกราฟีไม่ได้ทำได้เร็วเหมือน patch version มันมีทั้ง dependency ที่มองไม่เห็น ระบบ legacy ที่แตะยาก และ vendor ที่ยังไม่พร้อมเท่ากัน

2. คิดว่า migration คือการเปลี่ยนอัลกอริทึมตัวเดียวจบ

ในความจริง cryptography มักฝังอยู่ในหลายชั้นของระบบ ไม่ว่าจะเป็น library, certificate lifecycle, hardware security module, device firmware, SaaS integration, mobile app, API gateway หรือเครื่องมือของ third party เพราะฉะนั้นการเปลี่ยนจริงจึงไม่ใช่แค่เปลี่ยน config บรรทัดเดียว แต่เป็นเรื่อง architecture, inventory และ change management ด้วย

3. คิดว่ารอ vendor ทำให้ก็พอ

vendor สำคัญแน่นอน แต่ถ้าองค์กรไม่รู้ก่อนว่าตัวเองใช้ crypto อยู่ตรงไหนและระบบไหนมีข้อมูลอายุยาว ต่อให้ vendor พร้อม เราก็ยังจัดลำดับไม่ถูกว่าควรเริ่มตรงไหนก่อน หรือควรยอมรับความเสี่ยงตรงไหนได้บ้าง

ถ้าจะเริ่มวันนี้ ควรทำอะไรก่อน

ถ้าถามแบบ practical ว่าองค์กรควรเริ่มอย่างไร ผมคิดว่าควรเริ่มจาก 5 เรื่องนี้

1. ทำ cryptographic inventory ก่อนซื้อเครื่องมือ

CISA และ NIST ย้ำเรื่องนี้ตรงกันมาก คือเราต้องรู้ก่อนว่าที่ไหนใช้ public-key cryptography อยู่บ้าง ไม่ใช่เฉพาะระบบหลัก แต่รวมถึง service account, certificate, network appliances, remote access, email gateway, code signing pipeline, CI/CD, backup encryption workflow และการเชื่อมต่อกับ partner ด้วย

หลายองค์กรมี asset inventory พอใช้ได้ แต่ไม่มี cryptographic inventory จริง ๆ ซึ่งต่างกันพอสมควร เพราะเครื่องหนึ่งอาจมีการใช้ cryptography หลายแบบหลายชั้น และบางจุดก็ถูกซ่อนอยู่ใน dependency หรือ managed service ที่ทีมปฏิบัติการไม่เห็นตรง ๆ

2. จัดลำดับข้อมูลตามอายุความลับและผลกระทบ

ไม่ใช่ทุกข้อมูลต้องรีบย้ายพร้อมกัน ถ้าข้อมูลมีอายุสั้นและกระทบจำกัด อาจยังไม่ต้องอยู่ในกลุ่มแรก แต่ข้อมูลที่มีมูลค่าระยะยาวควรถูกจัดเป็น priority ก่อน เพราะมีความเสี่ยงแบบ harvest now, decrypt later ชัดกว่า

จุดนี้ช่วยให้การคุยกับผู้บริหารง่ายขึ้นด้วย เพราะเราจะเปลี่ยนบทสนทนาจาก "quantum ฟังดูน่ากลัว" ไปเป็น "ข้อมูลชุดไหนถ้าโดนเปิดในอีก 10 ปีแล้วยังเสียหายหนัก" ซึ่งเป็นภาษาความเสี่ยงที่ตัดสินใจได้จริงกว่า

3. ออกแบบ crypto agility

คำนี้สำคัญมาก ผมมองว่า crypto agility คือความสามารถของระบบในการเปลี่ยนหรืออัปเกรดอัลกอริทึมได้โดยไม่ต้องรื้อระบบใหม่ทั้งหมด ถ้า architecture วันนี้ผูกแน่นกับ algorithm เดิมมากเกินไป การย้ายไป PQC จะช้าและแพงกว่าที่ควร

ในทางปฏิบัติ crypto agility อาจแปลเป็นเรื่องพื้นฐานแต่สำคัญ เช่น แยก configuration ออกจาก business logic, ลด hard-code ที่ผูกกับ algorithm เดิม, ทำ versioning ของ protocol ให้ดี, และเลือกผลิตภัณฑ์ที่มี roadmap ชัดว่ารองรับมาตรฐาน NIST ชุดใหม่เมื่อไร

4. เริ่มทดสอบในห้องแล็บก่อน production

NCCoE ของ NIST ทำ practice guide ด้าน migration ไว้เพื่อช่วยเรื่องนี้โดยตรง เพราะการย้ายไป PQC มีประเด็นด้าน interoperability และ performance ที่ต้องดูจริง โดยเฉพาะระบบที่ต้องรับโหลดสูง อุปกรณ์ปลายทางที่ทรัพยากรจำกัด หรือ use case ที่ latency สำคัญ

ผมคิดว่า mindset ที่ถูกคือ เริ่มจาก lab, proof-of-concept และ compatibility testing ก่อน อย่าเพิ่งมองว่าต้องเปลี่ยน production ทั้งก้อนในรอบเดียว แต่ก็อย่าปล่อยให้ทุกอย่างค้างอยู่แค่ PoC โดยไม่มี roadmap ต่อ

5. กดดัน vendor ด้วยคำถามที่ชัดขึ้น

ถ้าใช้ผลิตภัณฑ์สำเร็จรูปเยอะ เรื่องนี้หนีไม่พ้น vendor แน่นอน แต่คำถามต้องชัด ไม่ใช่ถามแค่ว่า "รองรับ PQC ไหม" ควรถามต่อว่า

1. รองรับมาตรฐาน NIST ตัวใดแล้วบ้าง
2. รองรับในส่วน handshake, signature หรือ key management ตรงไหน
3. มี roadmap สำหรับ production support เมื่อไร
4. มีแนวทาง migration โดยไม่ break compatibility อย่างไร
5. ระบบ logging, monitoring และ certificate lifecycle จะเปลี่ยนตามอย่างไร

แล้วต้องรีบเปลี่ยนทุกอย่างตอนนี้ไหม

คำตอบสั้น ๆ คือไม่ใช่ แต่ต้องเริ่มวางแผนตอนนี้

จากข้อมูลของ NIST เอง ยังไม่มีใครบอกได้แน่ชัดว่า cryptographically relevant quantum computer จะมาถึงเมื่อไร อาจอีกหลายปีหรืออาจนานกว่านั้น แต่สิ่งที่รู้แน่คือรอบการเปลี่ยนระบบจริงในองค์กรใช้เวลานาน และมาตรฐานที่พร้อมใช้งานก็เริ่มมีแล้ว ดังนั้นสิ่งที่เหมาะที่สุดไม่ใช่ panic migration และไม่ใช่การนิ่งเฉย แต่เป็น phased transition

ในมุมของผม องค์กรที่ทำถูกมักไม่ได้เริ่มจากการสั่งเปลี่ยน algorithm ทุกจุดพร้อมกัน แต่เริ่มจาก

1. มองเห็น dependency ของตัวเองก่อน
2. รู้ว่าข้อมูลและระบบไหนต้องมาก่อน
3. เตรียม architecture ให้เปลี่ยนง่ายขึ้น
4. คุยกับ vendor ด้วย requirement ที่วัดได้
5. ทดสอบและทยอยย้ายในจุดที่มี business case ชัด

สรุปแบบตรงไปตรงมา

Post-Quantum Cryptography ยังไม่ใช่เรื่องที่ต้องตื่นตระหนก แต่ก็ไม่ใช่เรื่องที่ควรรอจนถึงวันสุดท้าย เพราะความเสี่ยงของมันผูกกับทั้งอายุของข้อมูลและระยะเวลาที่องค์กรต้องใช้ในการเปลี่ยนระบบจริง

ถ้าจะสรุปให้สั้นที่สุด ผมคิดว่าโจทย์ของวันนี้ไม่ใช่ "จะเปลี่ยนเป็น PQC พรุ่งนี้หรือไม่" แต่คือ "องค์กรของเรารู้หรือยังว่าตัวเองพึ่งพา cryptography ตรงไหน และถ้าต้องย้ายจริง เราจะย้ายแบบมีลำดับและมีเหตุผลได้หรือไม่"

คนที่เริ่ม inventory วันนี้ เริ่มคุยกับ vendor วันนี้ และเริ่มสร้าง crypto agility วันนี้ จะมีทางเลือกมากกว่าคนที่รอให้ความเสี่ยงชัดเจนค่อยขยับเสมอ เพราะในงาน security ส่วนใหญ่ คนที่ได้เปรียบไม่ใช่คนที่รีบที่สุด แต่คือคนที่เตรียมตัวก่อนและรู้ว่าตัวเองกำลังปกป้องอะไร

แหล่งอ้างอิง

• NIST FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard
• NIST FIPS 204: Module-Lattice-Based Digital Signature Standard
• NIST FIPS 205: Stateless Hash-Based Digital Signature Standard
• NIST: What Is Post-Quantum Cryptography?
• NIST NCCoE: Migration to Post-Quantum Cryptography Practice Guide
• CISA: Post-Quantum Cryptography Initiative
• CISA, NSA, NIST: Quantum-Readiness - Migration to Post-Quantum Cryptography
• NIST: NIST Selects HQC as Fifth Algorithm for Post-Quantum Encryption