Harvest Now, Decrypt Later คืออะไร: ใช้สมการ Mosca (X + Y > Z) เลือกข้อมูลที่ต้องเริ่มก่อนในตลาดทุน Harvest Now, Decrypt Later คืออะไร ใช้สมการ Mosca X + Y > Z ตามคู่มือ ก.ล.ต. จัดลำดับประวัติซื้อขาย แฟ้ม KYC และสัญญาที่ต้องลับนาน พร้อมคำถามสำหรับกรรมการ
Harvest Now, Decrypt Later คืออะไร: ใช้สมการ Mosca (X + Y > Z) เลือกข้อมูลที่ต้องเริ่มก่อนในตลาดทุน
ลองนึกภาพว่ามีคนแอบเก็บสำเนา traffic ระหว่างระบบของโบรกเกอร์กับคู่ค้าไว้ทั้งหมด ในนั้นมีประวัติการซื้อขายของลูกค้า แฟ้ม KYC และร่างสัญญาที่ฝ่ายกฎหมายส่งไปมา ทุกอย่างเข้ารหัสไว้ วันนี้เขาเปิดอ่านไม่ได้ แต่เขาไม่รีบ เพราะสิ่งที่รอคือวันที่มีคอมพิวเตอร์ควอนตัมเก่งพอจะถอดรหัสแบบที่เราใช้อยู่
คู่มือของ ก.ล.ต. เรื่องความเสี่ยงจากเทคโนโลยีควอนตัมเรียกสิ่งนี้ว่า Harvest Now, Decrypt Later (HNDL) และวางเป็นเหตุผลข้อแรกที่ควรเริ่มเตรียมตัวตั้งแต่วันนี้: “ข้อมูลสำคัญอาจถูกดักเก็บในวันนี้ เพื่อรอถอดรหัสเมื่อเทคโนโลยีมีความพร้อมในอนาคต” (สรุปผู้บริหาร, PDF หน้า 2)
คำตอบสั้นสำหรับกรรมการ: ความเสียหายจาก HNDL เกิดทีหลัง แต่การดักเก็บเกิดได้ตั้งแต่วันนี้ คู่มือเสนอสมการของ Mosca คือ X + Y > Z ถ้าอายุความลับของข้อมูล (X) บวกเวลาที่ต้องใช้เปลี่ยนระบบ (Y) ยาวกว่าเวลาที่คาดว่ายังเหลือ (Z) ข้อมูลชุดนั้นอาจเสี่ยงแล้ว
คู่มือระบุเองว่า “เป็นแนวทางหรือข้อแนะนำในเบื้องต้น มิใช่ข้อกำหนดหรือข้อบังคับทางกฎหมาย” (PDF หน้า 2) ส่วนที่ยกจากคู่มือจะระบุเลขหน้าไว้ ส่วนตัวอย่างและข้อเสนอของเราจะบอกไว้ชัดว่าเป็นของเรา ภาพรวมทั้งเล่มอ่านได้ที่สรุปคู่มือ ก.ล.ต. เรื่อง Quantum Risk และการเปลี่ยนผ่านสู่ PQC
HNDL ทำงานอย่างไร
อินโฟกราฟิกในคู่มือ (หน้า 6) แบ่ง HNDL เป็นสี่จังหวะ: “ดักเก็บข้อมูลที่เข้ารหัส” → “เก็บข้อมูลไว้โดยยังอ่านไม่ได้” → “รอคอมพิวเตอร์ควอนตัมที่มีขีดความสามารถเพียงพอ” → “ถอดรหัสและเปิดเผยข้อมูลลับ”
คู่มือหน้า 6 อธิบายว่าผู้โจมตีอาจเก็บสำเนาข้อมูลที่เข้ารหัสไว้เพื่อรอถอดรหัสในอนาคต วันที่ข้อมูลถูกดักกับวันที่ถูกอ่านจึงอาจไม่ใช่วันเดียวกัน
รหัสที่เสี่ยงคือกลุ่มกุญแจสาธารณะ คู่มือ (หน้า 5) อธิบายว่างานหลักของตลาดทุน ตั้งแต่เปิดบัญชี ส่งคำสั่งซื้อขาย ไปจนถึงชำระราคาและส่งมอบ ใช้ RSA และ ECC แลกเปลี่ยนกุญแจและลงลายมือชื่อดิจิทัล ซึ่งคอมพิวเตอร์ควอนตัมที่มีขีดความสามารถพออาจใช้อัลกอริทึมของชอร์ทำลายได้ ส่วนรหัสแบบกุญแจเดียวกันอย่าง AES ได้รับผลกระทบน้อยกว่ามาก และจัดการได้ด้วยขนาดกุญแจที่เหมาะสม คู่มือจึงให้แยกว่าส่วนไหนเสี่ยงสูง ส่วนไหนปรับเองได้ และส่วนไหนต้องรอคู่ค้า ไม่ใช่สั่งเลิกใช้การเข้ารหัสทั้งหมด
เอกสารร่วมของ CISA, NSA และ NIST ปี 2023 ก็เตือนทำนองเดียวกันว่าผู้โจมตีอาจกำลังเก็บข้อมูลที่มี “อายุความลับยาว” (long secrecy lifetime) ไว้ตั้งแต่วันนี้
ข้อมูลแบบไหนในตลาดทุนที่ควรห่วง
คู่มือ (หน้า 6) ยกตัวอย่างไว้หลายกลุ่ม ตารางนี้ขยายต่อด้วยงานที่บริษัทหลักทรัพย์และ บลจ. เจอประจำ คอลัมน์ขวาสุดเป็นความเห็นของเรา
ข้อมูล อะไรกำหนดว่าต้องลับนานแค่ไหน (X) ข้อสังเกตของเรา ประวัติการซื้อขายและข้อมูลผู้ลงทุน ระยะเวลาเก็บตามกฎหมาย (หน้า 5–6) และความอ่อนไหวของข้อมูลการลงทุน นโยบายลบข้อมูลลบได้แค่สำเนาของเรา ไม่ใช่สำเนาที่ถูกดักไป แฟ้ม KYC ข้อมูลส่วนบุคคล ที่องค์กรต้องดูแลความปลอดภัยตาม พ.ร.บ.คุ้มครองข้อมูลส่วนบุคคล (หน้า 18) เลขบัตรประชาชนกับวันเกิดไม่หมดความลับตอนลูกค้าปิดบัญชี ดีลควบรวม บทวิเคราะห์ คำสั่งขนาดใหญ่ ช่วงที่ยังไม่เปิดเผยต่อสาธารณะ (หน้า 6) บางส่วนหมดความลับเมื่อประกาศ แต่รายละเอียดการเจรจาอาจยังต้องลับ สัญญาระยะยาว เช่น สัญญาบริการหลายปี ข้อตกลงรักษาความลับในสัญญา ซึ่งคู่มือนับเป็นที่มาหนึ่งของ X (หน้า 13) ความลับอาจต้องอยู่นานกว่าอายุสัญญา ราคาตลาดที่เผยแพร่แล้ว แทบไม่มีความลับให้รักษา HNDL ไม่ใช่ประเด็นหลัก แต่ระบบที่ลงนามคำสั่งยังสำคัญ
แถว KYC คุ้นที่สุดสำหรับทีม compliance คู่มือ (หน้า 18) ย้ำว่าข้อมูลส่วนบุคคลที่รั่วอาจนำไปสู่ความรับผิดตามกฎหมายด้วย ถ้ายังไล่งาน PDPA ไม่ครบ 8 ข้อที่องค์กรต้องทำตาม PDPA เป็นจุดตั้งต้นที่ดี
สมการของ Mosca: X + Y > Z
บทที่ 3 (หน้า 12) เปลี่ยนคำถามจากการเดาว่าคอมพิวเตอร์ควอนตัมจะมาปีไหน เป็นการถามว่าถ้ามาเร็วกว่าที่คาด องค์กรจะเปลี่ยนผ่านทันหรือไม่ เครื่องมือคือกฎของมอสกา (Mosca's Theorem) กล่องสรุปในหน้า 13 นิยามไว้ว่า
X — ข้อมูลต้องเป็นความลับอีกนานเท่าใด: เช่น ข้อมูลลูกค้า ความลับทางการค้า หรือข้อมูลควบรวมกิจการ เป็นต้น
Y — องค์กรต้องใช้เวลากี่ปีในการเปลี่ยน: ครอบคลุมการสำรวจ การจัดซื้อ การทดสอบ ระบบเดิม และคู่ค้า / ผู้ให้บริการ
Z — คาดว่าองค์กรยังมีเวลาเหลือเท่าใด: ยังไม่มีคำตอบแน่นอน จึงควรลองคำนวณทั้งกรณีมาเร็ว ตามคาด และมาช้า
หาก X + Y > Z แล้วองค์กรควรเร่งจัดลำดับและเริ่มเปลี่ยนผ่าน เพราะข้อมูลอาจเสี่ยงแล้วตั้งแต่วันนี้
ภาพประกอบหน้า 12 ตั้งชื่อช่วงอันตรายว่า Quantum Exposure Window คือ “ช่วงที่ข้อมูลยังต้องได้รับการปกป้อง แต่ภัยอาจมีขีดความสามารถถอดรหัสแล้ว” และสรุปไว้ว่า “ยิ่ง X ยาว หรือ Y นาน องค์กรยิ่งต้องเริ่มเร็ว”
X ไม่ใช่ระยะเวลาเก็บข้อมูล ระยะเวลาเก็บตามกฎหมายเป็นแค่ข้อมูลตั้งต้น คำถามจริงคือข้อมูลต้อง “ลับ” ไปอีกนานแค่ไหน คู่มือให้กำหนด X จากข้อกำหนดทางธุรกิจ กฎหมาย และสัญญา (หน้า 13) คนตอบจึงต้องมีเจ้าของข้อมูล ฝ่ายกฎหมาย และ compliance ไม่ใช่ฝ่าย IT ฝ่ายเดียว
Y ต้องรวมงานตั้งแต่สำรวจจนถึงยุติระบบเดิม ภาพหน้า 12 ให้นับเวลาสำรวจ ทดสอบ จัดซื้อ ประสานคู่ค้า เปลี่ยนใช้งาน และยุติระบบเดิม ระบบสำเร็จรูปที่ผูกกับ vendor อาจต้องรอรุ่นใหม่ แม้ทีมเราจะพร้อมแล้ว (หน้า 22)
Z ไม่มีใครรู้ และคู่มือก็ไม่ได้ให้ตัวเลข คู่มืออ้างรายงาน Quantum Threat Timeline ของ Global Risk Institute ว่าความเสี่ยง “อาจมีนัยสำคัญตั้งแต่ช่วงทศวรรษ 2030” และยอมรับว่ายังไม่มีใครระบุได้แน่ชัด (หน้า 1) คู่มือจึงให้ลองอย่างน้อยสามกรณี แล้วดูว่าระบบไหนเปลี่ยนไม่ทันถ้าภัยมาเร็ว (หน้า 12–13) ปี 2030 และ 2035 ที่เห็นในคู่มือเป็นกรอบวางแผน ไม่ใช่ค่า Z (ดูคำถามที่พบบ่อยด้านล่าง)
ยังไม่รู้ Z แน่ชัดก็เริ่มประเมินได้ ฝ่ายบริหารรวบรวมค่า X และ Y ของแต่ละระบบ แล้วคำนวณกับ Z ทั้งสามกรณีข้างต้นตามที่คู่มือแนะนำ (หน้า 12–13) จากนั้นนำผลไปพิจารณาร่วมกับปัจจัยจัดลำดับทั้งห้าในหน้า 17 ข้อเสนอของเราคือใช้ผลคำนวณเป็นตัวคัดรายการที่ต้องประเมินต่อ ไม่ใช่สรุปลำดับจาก X + Y อย่างเดียว
ข้อมูลและระบบไหนควรไปก่อน
คู่มือไม่ให้จัดลำดับจากความลับของข้อมูลอย่างเดียว บทที่ 5 (หน้า 17) ให้ดูอย่างน้อยห้าปัจจัยประกอบกัน ได้แก่ ข้อมูลต้องได้รับการคุ้มครองนานแค่ไหน ระบบสำคัญต่อธุรกิจเพียงใด ใช้รหัสที่ควอนตัมอาจทำลายได้หรือไม่ เสี่ยงต่อการสวมรอยหรือการปลอมลายมือชื่อดิจิทัลแค่ไหน และพึ่งคู่ค้า ผู้ให้บริการ หรือระบบเดิมมากเพียงใด
หน้า 18 เสริมว่าไม่ควรตั้งเกณฑ์ตายตัวว่าข้อมูลต้องเก็บเกิน 10 ปีจึงจะเสี่ยงสูง และระบบที่ใช้ยืนยันตัวตน ลงลายมือชื่อ หรือทำธุรกรรมอาจสำคัญไม่แพ้กันแม้ไม่ได้เก็บข้อมูลนาน เพราะถ้าถูกปลอม ผลกระทบเกิดทันที คู่มือเรียกความเสี่ยงด้านการปลอมแปลงนี้ว่า Trust Now, Forge Later (TNFL) ระบบส่งคำสั่งซื้อขายจึงอาจมี X สั้น แต่ก็อาจต้องอยู่ต้นแถว
ลำดับงานต่อไปนี้เป็นข้อเสนอของเรา เรียบเรียงจากคู่มือหน้า 12–18
ทำรายการประเภทข้อมูลพร้อมค่า X และที่มาของตัวเลขแต่ละค่าโยงข้อมูลเข้ากับระบบที่เก็บหรือรับส่ง และดูว่าระบบนั้นใช้รหัสอะไร ข้อมูลนี้เป็นส่วนหนึ่งของบัญชีรายการการใช้รหัสลับ (CBOM) ซึ่งควรระบุหน้าที่ของรหัส เจ้าของระบบ และระบบหรือผู้ให้บริการที่พึ่งพาด้วย (หน้า 17) รายละเอียดอยู่ในบทความถัดไปในซีรีส์ หลักคิดเดียวกับการป้องกัน Ransomware ที่เริ่มจากรู้ว่ามีเครื่องอะไรบ้าง ถ้ายังไม่รู้ว่ามีอะไร ก็จัดลำดับไม่ได้ประเมิน Y รายระบบ รวมเวลาจัดซื้อ ทดสอบ แก้ระบบเดิม และรอผู้ให้บริการ ถ้ายังไม่แน่ใจว่าจะเริ่มเก็บตัวเลขชุดนี้จากตรงไหน คุยกับทีมเราได้ ลองสามกรณีของ Z แล้วทำเครื่องหมายระบบที่เลยเส้นในกรณีภัยมาเร็วจัดลำดับด้วยห้าปัจจัย แล้วสรุปเป็นรายการระบบที่ต้องทำก่อน พร้อมเหตุผล ผู้รับผิดชอบ กรอบเวลา และทางเลือกในการแก้ไข ตามรูปแบบที่คู่มือแนะนำ (หน้า 18)
ควรทำ / ไม่ควรทำ ตามคู่มือบทที่ 3 (หน้า 13)
✓ ควรทำ ✗ ไม่ควรทำ ขอให้ฝ่ายบริหารใช้ข้อมูลเฉพาะขององค์กรเป็นฐาน ทั้งอายุความลับของข้อมูลและเวลาที่ต้องใช้เปลี่ยนระบบใช้ตัวเลขเฉลี่ยของอุตสาหกรรมแทนทั้งหมด จนมองข้ามระบบเก่าหรือข้อมูลเฉพาะขององค์กรกำกับให้ฝ่ายบริหารประเมินอย่างน้อยสามกรณี: มาเร็ว ตามคาด และมาช้า เพื่อระบุระบบที่อาจเปลี่ยนผ่านไม่ทันยึดปีคาดการณ์เพียงปีเดียว แล้วหยุดรอเมื่อผู้เชี่ยวชาญให้ความเห็นไม่ตรงกันใช้ปี 2030–2035 เป็นกรอบเวลาสำหรับวางแผนและจัดลำดับการดำเนินงาน ไม่ใช่วันที่คาดว่าเหตุการณ์จะเกิดขึ้นเข้าใจว่าแผนเปลี่ยนผ่านคือวันเกิดเหตุ หรือคิดว่าระบบจะยังปลอดภัยแน่นอนจนถึงปีนั้นกำหนดให้ฝ่ายบริหารจัดลำดับระบบสำคัญก่อน และเสนอเป้าหมายตามความเสี่ยงกับความพร้อมของระบบและคู่ค้า / ผู้ให้บริการกำหนดกรอบเวลาเดียวกันทุกระบบ โดยไม่ดูผลกระทบและเวลาที่ต้องใช้จริง
ขอบเขตและรูปแบบราคาดูได้ที่หน้าราคา
คำถามที่กรรมการถามได้ในการประชุมครั้งถัดไป
จาก “คำถามเพื่อการกำกับดูแล” ของคู่มือ
“ข้อมูลหรือธุรกรรมใดขององค์กรต้องได้รับการคุ้มครองเป็นเวลานาน และมีความเสี่ยงจากการถูกดักเก็บวันนี้เพื่อรอถอดรหัสในอนาคต?” (หน้า 8)
“ข้อมูลประเภทใดต้องรักษาความลับนานที่สุด และฝ่ายบริหารกำหนดค่า X จากข้อกำหนดทางธุรกิจ กฎหมาย และสัญญาไว้อย่างไร?” (หน้า 13)
“ค่า Y ของระบบสำคัญรวมเวลาสำรวจ จัดซื้อ ทดสอบ แก้ระบบเดิม และประสานคู่ค้า / ผู้ให้บริการครบแล้วหรือไม่ และมีหลักฐานใดสนับสนุน?” (หน้า 13)
“ฝ่ายบริหารลองคำนวณทั้งกรณีที่เหตุการณ์เกิดขึ้นเร็วกว่าที่คาด เป็นไปตามที่คาด และช้ากว่าที่คาดแล้วหรือยัง และหากเกิดขึ้นเร็วกว่าประมาณการ ระบบใดอาจจะเปลี่ยนไม่ทัน?” (หน้า 13)
คำตอบควรมีหลักฐาน เช่น “อายุความลับและผลกระทบทางธุรกิจ” และ “รายการความเสี่ยงสำคัญพร้อมเหตุผล” (ภาคผนวก ก หน้า 30) ไม่ใช่รายงานว่า “อยู่ระหว่างดำเนินการ” โดยไม่มีขอบเขต ซึ่งคู่มือหน้า 7 จัดเป็นสิ่งที่ไม่ควรทำ
คำถามที่พบบ่อย
ข้อมูลที่ถูกดักไปแล้ว เปลี่ยนเป็น PQC ทีหลังช่วยได้ไหม
ข้ออนุมานของเราจากกลไก HNDL ในคู่มือหน้า 6 คือ การเปลี่ยนระบบขององค์กรภายหลังไม่ได้เปลี่ยนวิธีเข้ารหัสของสำเนาที่ผู้โจมตีเก็บไปแล้ว ส่วนข้อมูลในระบบขององค์กรจะได้รับการป้องกันแค่ไหน ขึ้นกับขอบเขตและผลทดสอบของการเปลี่ยนผ่าน
ก.ล.ต. บังคับให้เปลี่ยนให้เสร็จภายในปี 2030 หรือเปล่า
ไม่ใช่ คู่มือเป็นแนวทาง ไม่ใช่ข้อบังคับ (PDF หน้า 2, หน้า 4) ปี 2030 และ 2035 อิงกับ (ร่าง) กรอบการเตรียมความพร้อมเข้าสู่ยุคควอนตัม พ.ศ. 2569–2578 ของ สกมช. ซึ่ง ก.ล.ต. บอกว่าองค์กรในตลาดทุน “อาจพิจารณา” จัดแผนให้สอดคล้อง (หน้า 2) ตารางเป้าหมายในหน้า 3 ระบุว่าระบบที่ถือครองข้อมูลที่ต้องลับนาน “ควร” ลดความเสี่ยงหรือเปลี่ยนผ่านส่วนที่เสี่ยงสูงภายในปี 2030 และหมายเหตุใต้ตารางเขียนไว้ว่า “กรอบเวลาข้างต้นใช้เพื่อวางแผนการเตรียมความพร้อม มิใช่การคาดการณ์ปีที่ภัยจากคอมพิวเตอร์ควอนตัมจะเกิดขึ้น” (หน้า 3)
เคล็ดลับสุดท้าย: วางรายการ X คู่กับรายการ algorithm
ในขั้นที่ 2 ส่วนที่เป็นรายการ certificate และ algorithm นั้น zcrX มี cryptography posture ที่ให้คะแนนรายการบนเครื่องที่ติดตั้ง Agent เป็น quantum-safe, ready หรือ not ready เครื่องที่ไม่มี Agent จะขึ้นว่าไม่มีการวัด แทนที่จะถูกนับว่าปลอดภัย ทีมอาจนำรายการ not ready มาเทียบกับอายุความลับที่เจ้าของข้อมูลยืนยันแล้ว เพื่อใช้ประกอบการจัดลำดับร่วมกับปัจจัยทั้งห้าตามคู่มือหน้า 17 ทั้งนี้ การวัด cryptography posture ครอบคลุมเครื่องที่ติดตั้ง Agent และคู่มือก็เตือนไม่ให้อาศัยเครื่องมือค้นหาแหล่งเดียว (หน้า 18) ค่า X, Y, Z การวางแผน และการเปลี่ยนผ่านยังเป็นงานของทีมคุณและพาร์ทเนอร์ ดูขอบเขตการวัดของ zcrX ได้ที่หน้า PQC Readiness
อ่านต่อในซีรีส์นี้
ติดต่อทีมงาน
อยากคุยว่าข้อมูลและระบบขององค์กรควรเริ่มประเมิน X และ Y จากตรงไหน คุยกับทีมเราได้ฟรี ไม่มีค่าใช้จ่าย zcr ให้ซอฟต์แวร์ ส่วนงานสำรวจ วางแผน และเปลี่ยนผ่านแบบลงมือจริงดำเนินการผ่านพาร์ทเนอร์
แหล่งข้อมูลอ้างอิง
ทุกแหล่งเปิดอ่านเมื่อ 27 ตุลาคม 2026
ก.ล.ต. — คู่มือการกำกับดูแลความเสี่ยงจากเทคโนโลยีควอนตัม (Quantum Risk Governance & PQC Transition) สำหรับกรรมการบริษัท, กันยายน 2569 — สถานะแนวทาง (PDF หน้า 2, หน้า 4), HNDL และ TNFL (หน้า 1, 5–6), (ร่าง) กรอบของ สกมช. (หน้า 2–3), กฎของมอสกา (หน้า 12–13), ห้าปัจจัยจัดลำดับและ PDPA (หน้า 17–18), ตาราง do/don't (หน้า 7, 13), คำถามเพื่อการกำกับดูแล (หน้า 8, 13), หลักฐานในภาคผนวก ก (หน้า 30)CISA, NSA และ NIST — Quantum-Readiness: Migration to Post-Quantum Cryptography (สิงหาคม 2023, PDF) — การดักเก็บข้อมูลที่มีอายุความลับยาว (harvest now, decrypt later) สินค้า | ราคา | ทรัพยากร | บทความ | ติดต่อ 