NIST IR 8547 กำหนดเส้นตายการเข้ารหัส 2030 และ 2035 ทีมระบบควรทำบัญชีการเข้ารหัสอะไรได้ตั้งแต่วันนี้

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

บทความนี้เขียนจากมุมของทีมที่ต้องออกแบบและส่งมอบระบบ ไม่ใช่ผู้เชี่ยวชาญด้านการเข้ารหัส เราจะเล่าสิ่งที่เอกสารของ NIST ฉบับล่าสุดระบุจริง บอกว่าอะไรผูกพันใคร และอธิบายงานที่ทำได้ตั้งแต่วันนี้โดยไม่ต้องซื้อผลิตภัณฑ์ใหม่ คือการทำบัญชีว่าระบบใช้ public-key cryptography อะไร อยู่ที่ไหน และใครถือกุญแจ

เอกสารระบุอะไร

NIST เผยแพร่ NIST IR 8547 ฉบับสุดท้าย ชื่อ Transition to Post-Quantum Cryptography Standards ในเดือนตุลาคม 2026 หน้าเอกสารของ NIST ระบุวันที่ฉบับสุดท้ายคือ 27 ตุลาคม 2026 และมีร่างฉบับก่อนหน้าลงวันที่ 12 พฤศจิกายน 2024 (ดูหน้าเอกสารของ NIST) เราเปิดตัวเอกสารฉบับ PDF อ่านเองแล้ว (DOI ของเอกสาร) เนื้อหาที่เกี่ยวข้องมีดังนี้

• NIST จะ deprecate การเข้ารหัสแบบกุญแจสาธารณะที่เสี่ยงต่อคอมพิวเตอร์ควอนตัมหลังปี 2030 และจะ disallow การใช้ภายใต้มาตรฐานและแนวปฏิบัติของ NIST หลังปี 2035

• ตารางในเอกสารระบุกลุ่มที่ได้รับผล เช่น ลายเซ็นดิจิทัลแบบ ECDSA, EdDSA และ RSA และการแลกเปลี่ยนกุญแจแบบ Finite Field DH, Elliptic Curve DH และ MQV

• สำหรับหน่วยงานรัฐบาลกลางสหรัฐฯ เอกสารอ้างถึง OMB Memorandum M-26-15 ว่าระบบที่มีข้อมูลอ่อนไหวสูงต้องใช้การเข้ารหัสแบบทนควอนตัมสำหรับการแลกเปลี่ยนกุญแจภายใน 31 ธันวาคม 2030 และสำหรับลายเซ็นดิจิทัลภายใน 31 ธันวาคม 2031

• หน่วยงานรัฐบาลกลางต้องรองรับ TLS 1.3 ไม่ช้ากว่า 2 มกราคม 2030 ตามเอกสารเดียวกัน

• เป้าหมายรวมของการย้ายไปสู่การเข้ารหัสแบบทนควอนตัมคือปี 2035 ซึ่งเอกสารอ้างถึง National Security Memorandum 10

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

เอกสารนี้ผูกพันใคร และไม่ผูกพันใคร

ข้อนี้ต้องพูดให้ชัด เพราะข่าวหลายชิ้นเขียนเหมือนว่าทุกองค์กรมีเส้นตายปี 2030

NIST IR 8547 เป็นเอกสารของหน่วยงานมาตรฐานสหรัฐฯ กำหนดทิศทางของมาตรฐานและแนวปฏิบัติของ NIST เอง และอ้างคำสั่งที่ผูกพันหน่วยงานรัฐบาลกลางสหรัฐฯ ตัวเอกสารไม่ได้เป็นกฎหมายไทย และไม่ได้บังคับองค์กรไทยโดยตรง เราไม่พบในเอกสารว่ามีข้อใดบังคับภาคเอกชนนอกสหรัฐฯ

ที่องค์กรไทยควรสนใจจึงเป็นผลทางอ้อมสามทาง ทางแรก มาตรฐานของ NIST ถูกใช้อ้างอิงในแบบประเมินความปลอดภัย ข้อกำหนดการจัดซื้อ และผลิตภัณฑ์ที่ผู้ขายจะทยอยปรับตาม ทางที่สอง ลูกค้าต่างประเทศหรือหน่วยงานที่ทำงานกับรัฐบาลสหรัฐฯ อาจส่งข้อกำหนดนี้ลงมาตามห่วงโซ่ ทางที่สาม เอกสารกล่าวถึงภัยที่เรียกว่า harvest now, decrypt later คือผู้โจมตีเก็บข้อมูลที่เข้ารหัสไว้ตอนนี้เพื่อถอดรหัสเมื่อมีเครื่องที่ทำได้ ซึ่งหมายความว่าข้อมูลที่ต้องเป็นความลับนานหลายปี มีความเสี่ยงที่เริ่มนับตั้งแต่วันที่มันถูกส่งออกไป ไม่ใช่วันที่เครื่องควอนตัมพร้อม

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

บัญชีการเข้ารหัสคืออะไร

บัญชีการเข้ารหัสคือตารางที่ตอบได้ว่า ในระบบทั้งหมดที่องค์กรใช้ มีการใช้ public-key cryptography ตรงไหนบ้าง ใช้อัลกอริทึมอะไร ใครเป็นเจ้าของ และเปลี่ยนได้ยากแค่ไหน คำว่า public-key cryptography ในที่นี้คือกลุ่มที่เอกสาร NIST ระบุว่าอ่อนไหวต่อคอมพิวเตอร์ควอนตัม เช่น RSA และ ECC ไม่ใช่การเข้ารหัสทุกชนิด

สำหรับแต่ละจุดที่ใช้ เราแนะนำให้บันทึกเรื่องเหล่านี้

• ที่อยู่ของมัน เช่น ใบรับรองของเว็บไซต์และ API, การเชื่อมต่อ VPN, การลงนาม token ของระบบล็อกอินแบบ SSO, การลงนามโค้ดหรือไฟล์ติดตั้ง, การเข้ารหัสอีเมล, การเชื่อมต่อฐานข้อมูล

• อัลกอริทึมและขนาดกุญแจ ที่ใช้อยู่จริง ดูจากการตั้งค่าหรือจากใบรับรอง ไม่ใช่จากความจำของคน

• ใครถือกุญแจ และกุญแจอยู่ในที่ใด เช่น ในเซิร์ฟเวอร์ ในบริการจัดการกุญแจของผู้ให้บริการ Cloud หรืออยู่ในเครื่องของคนคนหนึ่ง

• ฝังอยู่ในโค้ดของเราหรืออยู่ในผลิตภัณฑ์ของผู้อื่น ถ้าอยู่ในผลิตภัณฑ์ของผู้อื่น การเปลี่ยนเป็นเรื่องที่ต้องรอผู้ขาย

• ข้อมูลที่มันปกป้องต้องเป็นความลับนานแค่ไหน ข้อมูลที่หมดความสำคัญภายในไม่กี่วันต่างจากข้อมูลที่ต้องเก็บเป็นความลับหลายปี

• เปลี่ยนได้ง่ายหรือยาก ใบรับรองที่ต่ออายุอัตโนมัติทุกไม่กี่เดือนเปลี่ยนง่าย ลายเซ็นที่ฝังในเฟิร์มแวร์ของอุปกรณ์ที่ติดตั้งแล้วเปลี่ยนยาก

คอลัมน์สุดท้ายสำคัญมากในแง่การวางแผน เพราะมันแยกงานที่ทำได้ในการต่ออายุปกติออกจากงานที่ต้องวางโครงการ

จุดที่การเข้ารหัสซ่อนอยู่

เมื่อเราไล่ดูระบบขององค์กรหนึ่งเป็นรายระบบ การเข้ารหัสมักอยู่ในที่ที่ทีมไม่นึกถึงตอนมีคนถามครั้งแรก

ใบรับรองที่ใช้ภายในองค์กรสำหรับบริการที่ไม่เปิดสู่ภายนอกมักถูกออกด้วยเครื่องมือเดิมตั้งแต่หลายปีก่อนและไม่มีใครดู ระบบล็อกอินแบบ SSO ใช้กุญแจลงนาม token และกุญแจนั้นอาจเป็น RSA ที่ตั้งไว้ตั้งแต่วันติดตั้ง ระบบเก่าที่ผู้พัฒนาเดิมไม่อยู่แล้วอาจเชื่อมต่อกับระบบอื่นด้วยโปรโตคอลที่ล็อกเวอร์ชันไว้ อุปกรณ์เครือข่ายและเครื่องพิมพ์ที่มีหน้าเว็บบริหารจัดการมีใบรับรองของตัวเอง ฟังก์ชันที่ลงนามไฟล์สัญญาหรือใบเสร็จอิเล็กทรอนิกส์ใช้กุญแจที่เก็บอยู่ในเครื่องของผู้ดูแลคนเดียว

เรื่องผู้ดูแลที่ถือกุญแจ เราเขียนแนวทางเรื่องการส่งต่อสิทธิ์เมื่อทีมเปลี่ยนมือไว้ในบทความเรื่องใครถือกุญแจบัญชี Cloud ขององค์กร หลักการเดียวกันใช้กับกุญแจเข้ารหัส ถ้ามีเพียงคนเดียวรู้ว่ากุญแจอยู่ที่ไหน บัญชีของคุณก็มีจุดเสี่ยงที่ไม่เกี่ยวกับควอนตัมเลย

คำถามที่ถามผู้ขายและผู้พัฒนาได้เลย

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

1. ผลิตภัณฑ์หรือบริการนี้ใช้ public-key cryptography ตรงไหนบ้าง และอัลกอริทึมอะไร

2. ผู้ขายมีแผนหรือกรอบเวลาที่เผยแพร่เกี่ยวกับการรองรับการเข้ารหัสแบบทนควอนตัมหรือไม่ และเมื่อมี การอัปเดตจะอยู่ในสัญญาบำรุงรักษาเดิมหรือไม่

3. ถ้าต้องเปลี่ยนอัลกอริทึม ระบบต้องหยุดให้บริการหรือไม่ และใครเป็นผู้ทำ

เราแนะนำให้ขอคำตอบเป็นลายลักษณ์อักษร ผู้ขายที่ยังไม่มีแผนก็ตอบตรง ๆ ได้ว่ายังไม่มี ซึ่งเป็นข้อมูลที่ผู้ซื้อต้องการเช่นกัน แนวคิดนี้สอดคล้องกับเรื่องข้อกำหนดที่ควรอยู่ใน TOR สำหรับระบบที่ต้องดูแลต่อได้ ซึ่งเราเขียนไว้ในบทความเรื่องเงื่อนไขใน TOR

เรื่องที่ไม่ควรทำตอนนี้

ในมุมของเรา มีสามเรื่องที่ไม่ควรทำเพียงเพราะอ่านข่าวนี้

เรื่องแรกคือซื้อผลิตภัณฑ์ที่โฆษณาว่า "พร้อมควอนตัม" ทั้งชุด โดยยังไม่รู้ว่าระบบของตัวเองใช้การเข้ารหัสอะไรอยู่ ผลิตภัณฑ์ที่แก้ปัญหาที่ยังไม่ได้ระบุ มักไม่แก้ปัญหาที่มีจริง เรื่องที่สองคือเปลี่ยนอัลกอริทึมของระบบที่ใช้งานอยู่โดยไม่ผ่านขั้นตอนการเปลี่ยนแปลงปกติ การเปลี่ยนการเข้ารหัสเป็นการเปลี่ยนที่กระทบการเชื่อมต่อทุกจุด และควรผ่านการทดสอบเหมือนการเปลี่ยนระบบอื่น ซึ่งเราเขียนไว้ในบทความเรื่องการจัดการ release บน production เรื่องที่สามคือเชื่อว่าการเข้ารหัสแบบสมมาตรหรือการแฮชปลอดภัยเสมอ เอกสารของ NIST เองระบุว่ามีมาตรฐานสมมาตรบางระดับความปลอดภัยที่จะถูก disallow ในปี 2030 และฟังก์ชันแฮช SHA-1 จะถูก disallow สำหรับโมดูลที่ผ่านการรับรอง FIPS หลังปี 2030 ดังนั้นบัญชีที่ดีควรครอบคลุมอัลกอริทึมเก่าเหล่านี้ด้วย ไม่ใช่เฉพาะ RSA และ ECC

ข้อจำกัดที่ต้องบอกตรง ๆ

ถ้าระบบของคุณมีอายุใช้งานสั้นกว่าห้าปี ไม่เก็บข้อมูลที่ต้องเป็นความลับนาน และไม่ต้องส่งมอบให้ลูกค้าที่มีข้อกำหนดของภาครัฐสหรัฐฯ บัญชีการเข้ารหัสแบบเต็มอาจเกินความจำเป็น หน้ากระดาษเดียวที่ระบุใบรับรอง จุดล็อกอิน และกุญแจลงนาม พอเป็นจุดเริ่มต้นแล้ว

อีกข้อ เรายืนยันได้เฉพาะสิ่งที่เอกสารของ NIST ระบุ เราไม่ได้ตรวจสอบกำหนดการของ OMB หรือคำสั่งประธานาธิบดีที่เอกสารอ้างถึงจากต้นฉบับ และเราไม่ได้ตรวจสอบรายละเอียดเทคนิคของมาตรฐานการเข้ารหัสแบบทนควอนตัมที่ NIST เลือก ถ้าคุณต้องวางแผนทางเทคนิคจริง ควรปรึกษาผู้เชี่ยวชาญด้านการเข้ารหัสที่อ่านเอกสารฉบับเต็มและประเมินระบบของคุณ

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

ข้อโต้แย้งที่ได้ยินบ่อย

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

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

จะเริ่มตรงไหน

1. ไล่ใบรับรองทั้งหมดที่องค์กรถืออยู่ ทั้งที่เปิดสู่ภายนอกและใช้ภายใน บันทึกวันหมดอายุ อัลกอริทึม และผู้ดูแล

2. ตรวจกุญแจลงนามของระบบล็อกอินและ API ว่าอยู่ที่ไหน ใครเข้าถึงได้ และเปลี่ยนครั้งล่าสุดเมื่อไร

3. ถามผู้ขายหลักแต่ละรายด้วยคำถามสามข้อ และบันทึกคำตอบพร้อมวันที่

4. แยกข้อมูลที่ต้องเป็นความลับนาน ออกจากข้อมูลทั่วไป แล้วดูว่าข้อมูลกลุ่มแรกถูกปกป้องด้วยอะไร

5. เก็บบัญชีไว้กับเอกสารระบบ และกำหนดวันทบทวน เช่น ทุกครั้งที่ต่ออายุสัญญาดูแลระบบ เพื่อให้คนที่มารับช่วงต่ออ่านได้

สรุป

NIST IR 8547 ฉบับสุดท้ายระบุว่า การเข้ารหัสแบบกุญแจสาธารณะที่เสี่ยงต่อควอนตัมจะถูก deprecate หลังปี 2030 และ disallow หลังปี 2035 ภายใต้มาตรฐานของ NIST โดยเส้นตายที่เข้มกว่านั้นผูกกับหน่วยงานรัฐบาลกลางสหรัฐฯ ไม่ใช่องค์กรไทย ถ้าจะหยิบไปใช้อย่างเดียวจากบทความนี้ ให้ทำตารางหนึ่งหน้าที่บอกว่าระบบของคุณใช้ RSA หรือ ECC ตรงไหน ใครถือกุญแจ และเปลี่ยนยากหรือง่าย ตารางนั้นใช้ตอบแบบประเมินของลูกค้า ใช้วางแผนกับผู้ขาย และใช้ส่งต่อให้คนที่มารับช่วงระบบ

หากต้องการคุยรายละเอียดของโครงการ ติดต่อเราได้ที่ 088-983-9386 หรืออีเมล [email protected] สำนักงานของเราอยู่ที่บางกะปิ กรุงเทพฯ สำหรับองค์กรที่ยังอยู่ระหว่างร่างขอบเขตงาน เรายินดีนัดคุยเพื่อทำความเข้าใจโจทย์ก่อน โดยยังไม่ต้องมีเอกสารครบ และหากคุยแล้วพบว่าโจทย์ยังไม่ถึงเวลาต้องพัฒนาระบบใหม่ เราจะบอกตรง ๆ เพราะการเริ่มโครงการผิดจังหวะ มีต้นทุนสูงกว่าการรออีกหนึ่งไตรมาส