Quantum-Safe File Trust & Evidence Platform

ส่งไฟล์อย่างปลอดภัย
พร้อมหลักฐานที่ตรวจสอบได้ในระยะยาว

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

Protect Prove Preserve

ดูแนวคิดการทำงาน ตรวจสอบไฟล์ ดูหลักฐานที่ตรวจได้ แผนภาพสถาปัตยกรรม

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

Confidentialityปกป้องเนื้อหาไฟล์

Integrityตรวจพบการเปลี่ยนแปลง

Authenticityผูกหลักฐานกับผู้ออก

Long-Term Evidenceรองรับการตรวจสอบระยะยาว

The long-lived data problem

ข้อมูลมีอายุยาว
แต่รูปแบบการเข้ารหัสที่คุ้มครองข้อมูลมีอายุจำกัด

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

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

X+Y>Z

Quantum Exposure Window

Data Lifetime
ระยะเวลาที่ข้อมูลยังต้องถูกเก็บ ปกป้อง และตรวจสอบย้อนหลังได้

Migration Time
เวลาที่องค์กรต้องใช้สำรวจระบบ เปลี่ยนอัลกอริทึม ย้ายกุญแจ และปรับกระบวนการ

Threat Horizon
ช่วงเวลาที่ภัยควอนตัมหรือการเสื่อมความมั่นคงของรูปแบบการเข้ารหัสเดิมอาจกระทบข้อมูล

สมการนี้เป็นกรอบคัดกรองเชิงกลยุทธ์สำหรับจัดลำดับความเร่งด่วน ไม่ใช่มาตรฐานประเมินความเสี่ยงของ NIST, ISO หรือ ETSI

What QSense Seal must answer

ไฟล์สำคัญหนึ่งไฟล์ ต้องตอบคำถามให้ได้มากกว่า “เปิดได้หรือไม่”

QSense Seal สร้างชุดหลักฐานประกอบไฟล์ในแต่ละช่วงของการใช้งาน เพื่อให้ผู้รับ ผู้ตรวจสอบ และผู้ดูแลระบบตอบคำถามสำคัญได้อย่างเป็นระบบ

ไฟล์นี้คือไฟล์เดิมหรือไม่

ตรวจความครบถ้วนของเนื้อหาและตรวจพบการแก้ไขแม้เพียงบางส่วน

ใครเป็นผู้ออกหรือรับรอง

ผูกลายเซ็นกับกุญแจ ตัวตนองค์กร และข้อมูล provenance ที่ตรวจสอบได้

ไฟล์มีอยู่ตั้งแต่เมื่อใด

ใช้หลักฐานเวลาและ daily anchor จากบุคคลที่สามประกอบการพิสูจน์

หลักฐานยังตรวจสอบได้หรือไม่

ตรวจสถานะอัลกอริทึม กุญแจ และต่ออายุหลักฐานก่อนกลไกเดิมเสื่อมความมั่นคง

01 · Protect

ปกป้องการรับส่งและการจัดเก็บ

ใช้ Hybrid Post-Quantum Key Establishment เพื่อสร้างกุญแจสำหรับเข้ารหัสไฟล์ และปกป้องช่องทางสื่อสารด้วย TLS 1.3 แบบ Hybrid PQC

X25519 + ML-KEM-768
AES-256-GCM · HKDF-SHA-256

02 · Prove

สร้างหลักฐานที่มาและความถูกต้อง

บันทึก hash, metadata, ผู้ส่ง, เวลา, ชั้นความลับ และข้อมูลกุญแจไว้ในขอบเขตลายเซ็น เพื่อให้การแก้ไขถูกตรวจพบและตรวจสอบที่มาได้

ML-DSA-65 · FIPS 204
Signed provenance · Merkle evidence

03 · Preserve

รองรับการตรวจสอบเมื่อรูปแบบการเข้ารหัสเปลี่ยนแปลง

สร้างหลักฐานชุดใหม่ด้วย hash และ timestamp ก่อนอัลกอริทึมหรือใบรับรองเดิมเสื่อมความมั่นคง โดยไม่แก้ไขไฟล์ต้นฉบับ

RFC 3161 timestamp
Evidence renewal aligned with RFC 4998 concepts

Ingest

รับไฟล์ คำนวณลายนิ้วมือ และบันทึก metadata

Classify

ตรวจเนื้อหา จัดชั้นข้อมูล และบังคับใช้นโยบาย

Seal

เข้ารหัส สร้าง Merkle evidence และลงลายเซ็น

Store & Transfer

ส่งไปยังที่เก็บเดิมขององค์กรและตรวจยืนยันปลายทาง

Verify & Renew

ตรวจซ้ำเป็นรอบ สร้าง anchor และต่ออายุหลักฐาน

เปิดดูรายละเอียดกระบวนการเชิงเทคนิค 8 ขั้นตอน

รับไฟล์และคำนวณ SHA-256

ประมวลผลแบบ streaming เพื่อลดการใช้หน่วยความจำ และเก็บลายนิ้วมือของต้นฉบับตั้งแต่จุดรับเข้า

ตรวจเนื้อหาและจัดชั้นข้อมูล

ตรวจรูปแบบข้อมูลสำคัญและคำบ่งชี้ความลับ พร้อมบันทึกขอบเขตการตรวจให้ชัดเจน

บังคับใช้นโยบาย

กำหนดว่าข้อมูลแต่ละชั้นต้องเข้ารหัสหรือเซ็นหรือไม่ ส่งไปที่ใดได้ ใครส่งได้ และต้องเก็บนานเท่าใด

สร้างกุญแจแบบ Hybrid

ผสม shared secret จาก X25519 และ ML-KEM-768 ผ่าน KDF เพื่อสร้างกุญแจเข้ารหัสข้อมูล

เข้ารหัสและสร้าง Merkle tree

เข้ารหัสข้อมูลด้วย AES-256-GCM และสร้างหลักฐานระดับบล็อกเพื่อรองรับการตรวจบางส่วนและการทำ daily anchor

ลงลายเซ็น ML-DSA-65

ครอบ hash, metadata, provenance, classification, key identifier และราก Merkle ในข้อมูลที่ลงลายเซ็น

ส่งไปยังที่เก็บและตรวจยืนยัน

เชื่อมระบบ cloud storage, object storage, SFTP, WebDAV หรือ NAS ผ่าน rclone ecosystem และตรวจ hash ตามความสามารถของปลายทาง

ผูกหลักฐานเข้ากับ Daily Anchor

รวมหลักฐานประจำวันด้วย Merkle root ลงลายเซ็น และขอ RFC 3161 timestamp เพื่อสร้างหลักฐานจากบุคคลที่สาม

ข้อมูลต้นฉบับไม่ออกจาก Gateway สิ่งที่ขึ้นสู่ที่เก็บปลายทางคือ ciphertext และ manifest ที่ลงลายเซ็นแล้วเท่านั้น ดูแบบเต็มหน้า

Verify without trusting the platform

หลักฐานควรตรวจได้โดยไม่ผูกกับระบบเดิมเพียงระบบเดียว

QSense Seal แยก “ไฟล์” ออกจาก “ชุดหลักฐาน” และเปิดให้ส่งออกข้อมูลที่จำเป็นต่อการตรวจสอบ เพื่อหลีกเลี่ยงการผูกขาดกับแพลตฟอร์มเดียว

Evidence Package

ชุดหลักฐานควรบอกได้ว่าอะไรถูกลงลายเซ็น ใช้กุญแจใด ผู้ส่งได้รับการยืนยันจากระบบใด ไฟล์มี hash เท่าใด และมีหลักฐานเวลาใดประกอบ

File integritySHA-256 และ Merkle root ของข้อมูล

Signed provenanceข้อมูลผู้ออก เวลา ชั้นความลับ และ key identifier

External time evidenceRFC 3161 timestamp token และ certificate chain ของ TSA

Renewal chainลำดับหลักฐานใหม่ที่ครอบหลักฐานเดิมก่อนกลไกเดิมเสื่อมความมั่นคง

Verification statusผลตรวจพร้อมเหตุผล ไม่รายงานเพียง “ผ่าน/ไม่ผ่าน”

// ตัวอย่างส่วนหนึ่งของ signed manifest
{
  "file": {
    "name": "สัญญาบริการ.pdf",
    "sha256": "e2d64ad25819..."
  },
  "provenance": {
    "subject": "[email protected]",
    "identity_provider": "องค์กร.example",
    "sealed_at": "2026-07-29T01:40:56+07:00"
  },
  "classification": "confidential",
  "crypto": {
    "kem": "X25519+ML-KEM-768",
    "signature": "ML-DSA-65",
    "aead": "AES-256-GCM"
  },
  "evidence": {
    "merkle_root": "ca09e76d5c13...",
    "key_id": "7393e72c1e32..."
  }
}

โครงสร้างจริงควรกำหนด canonical encoding, versioning และ validation profile ให้แน่นอน เพื่อให้ตรวจซ้ำได้เหมือนกันทุกระบบ

FIPS 203 · ML-KEM FIPS 204 · ML-DSA TLS 1.3 · Hybrid PQC AES-256-GCM SHA-256 · Merkle Tree RFC 3161 · Timestamp RFC 4998 · Evidence Renewal Concepts OIDC · Enterprise Identity

การระบุชื่อมาตรฐานหมายถึงเทคโนโลยีหรือแนวคิดที่ใช้อ้างอิง ไม่ควรตีความว่าได้รับการรับรองความสอดคล้องหรือการรับรองผลิตภัณฑ์ เว้นแต่มีผลการทดสอบหรือใบรับรองแยกต่างหาก

Operational capabilities

ออกแบบให้ทำงานร่วมกับระบบเดิมขององค์กร

QSense Seal เป็น control layer สำหรับไฟล์สำคัญ ไม่ใช่บังคับให้องค์กรย้ายข้อมูลทั้งหมดเข้าสู่ repository ใหม่

Sealed package หรือ Sidecar evidence

เลือกผนึกไฟล์เป็นก้อนเดียว หรือเก็บต้นฉบับตามเดิมพร้อมหลักฐานประกบด้านข้างเพื่อรักษา workflow และ preview เดิม

เชื่อมระบบจัดเก็บหลายรูปแบบ

รองรับ cloud drive, object storage, SFTP, WebDAV และ NAS ผ่าน rclone ecosystem โดยไม่ยึดกับผู้ให้บริการรายเดียว

Policy-based classification

บังคับใช้นโยบายตามชั้นข้อมูล ผู้ส่ง ปลายทาง อายุจัดเก็บ การเข้ารหัส และการลงลายเซ็น

Tamper-evident audit trail

เชื่อมเหตุการณ์ด้วย hash และปิดรอบด้วยลายเซ็น เพื่อให้การเปลี่ยนแปลงย้อนหลังถูกตรวจพบ

Enterprise identity integration

รองรับ OIDC เพื่อเชื่อมตัวตนจาก Microsoft Entra ID, Google Workspace, Auth0 หรือ Keycloak เข้ากับ provenance

Periodic verification

ดึงไฟล์และหลักฐานมาตรวจซ้ำตามรอบ พร้อมบันทึกผลเป็นประวัติการคงสภาพที่ต่อเนื่อง

Evidence export

ส่งออก public key, signed manifest, timestamp token, Merkle proof และ renewal chain สำหรับการตรวจจากภายนอก

Crypto-agile evidence policy

กำหนดรอบตรวจและต่ออายุหลักฐานตามระดับข้อมูล สถานะอัลกอริทึม ใบรับรอง และอายุของกุญแจ

Transparent verification result

รายงานสิ่งที่พิสูจน์ได้ สิ่งที่ขาด และสาเหตุของความไม่สมบูรณ์ แทนการแสดงเครื่องหมายผ่านเพียงอย่างเดียว

Data governance

ชั้นข้อมูลที่พิสูจน์ได้ และนโยบายที่บังคับก่อนไฟล์ออกจากองค์กร

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

ชั้นข้อมูล	อายุจัดเก็บ	ต้องเข้ารหัส	ต้องลงลายเซ็น	ผู้มีสิทธิ์ส่ง	ที่เก็บที่อนุญาต
เปิดเผยได้	1 ปี	ไม่บังคับ	ไม่บังคับ	ทุกบทบาท	ทุกที่เก็บ
ใช้ภายใน	3 ปี	ไม่บังคับ	บังคับ	ทุกบทบาท	ทุกที่เก็บ
ความลับ	10 ปี	บังคับ	บังคับ	ทุกบทบาท	กำหนดรายการได้
ความลับสูงสุด	20 ปี	บังคับ	บังคับ	ผู้ดูแลระบบ	กำหนดรายการได้

ค่าข้างต้นเป็นค่าตั้งต้น องค์กรกำหนดชื่อชั้น อายุจัดเก็บ ข้อบังคับด้านการเข้ารหัสและลายเซ็น ที่เก็บที่อนุญาต และรอบการต่ออายุหลักฐานของแต่ละชั้นได้เอง

ชั้นข้อมูลอยู่ในขอบเขตลายเซ็น

ระดับชั้นถูกผนวกเข้ากับข้อมูลที่ลงลายเซ็น ML-DSA-65 จึงพิสูจน์ได้ว่าไฟล์ถูกจัดชั้นใดในขณะผนึก ไม่ใช่ค่าที่แก้ไขในฐานข้อมูลได้ภายหลัง

บังคับใช้ก่อนการส่งออก

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

เสนอชั้นข้อมูลจากเนื้อหา

ตรวจเลขประจำตัวประชาชนที่ผ่านการตรวจหลักตรวจสอบ เลขบัตรชำระเงินที่ผ่าน Luhn คำบ่งชี้ความลับ และการรวมกลุ่มของข้อมูลติดต่อส่วนบุคคล

ยกระดับเท่านั้น ไม่ลดระดับ

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

มุมมองชั้นข้อมูลต่อที่เก็บ

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

อายุจัดเก็บกำหนดรอบต่ออายุ

ระยะเวลาจัดเก็บของแต่ละชั้นคือค่า X ในสมการความเสี่ยง และเป็นตัวกำหนดว่าหลักฐานของไฟล์นั้นต้องได้รับการต่ออายุเมื่อใด

แยกบทบาทผู้ใช้งาน

ผู้ปฏิบัติงานเข้าถึงเฉพาะเอกสารของตนเอง ส่วนการกำหนดนโยบาย ที่เก็บ หลักฐาน และผู้ใช้ เป็นสิทธิ์ของผู้ดูแลระบบ

บันทึกการเปลี่ยนแปลงนโยบาย

การแก้ไขนโยบายของแต่ละชั้นถูกบันทึกลงในบันทึกหลักฐานที่แก้ย้อนหลังไม่ได้ พร้อมระบุผู้ดำเนินการและค่าที่เปลี่ยน

ขอบเขตของการตรวจเนื้อหา

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

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

High-X information

เหมาะกับข้อมูลที่ต้องเก็บเป็นความลับและตรวจสอบย้อนหลังในระยะยาว

QSense Seal เหมาะกับข้อมูลที่มีระยะเวลาจัดเก็บยาว มีผลกระทบสูง หรือจำเป็นต้องใช้เป็นหลักฐานอ้างอิงในอนาคต

Healthcare

เวชระเบียนและข้อมูลสุขภาพ

ปกป้องความลับและตรวจสอบความครบถ้วนตลอดระยะเวลาจัดเก็บตามข้อกำหนดและการใช้งาน

Government

เอกสารภาครัฐและจดหมายเหตุ

รักษาที่มา เวลารับรอง และประวัติการคงสภาพสำหรับเอกสารที่ต้องอ้างอิงระยะยาว

Legal

สัญญาและหลักฐานทางกฎหมาย

จัดเก็บหลักฐานประกอบที่ตรวจสอบได้ โดยแยกความถูกต้องของไฟล์ออกจากคำกล่าวอ้างของระบบ

Finance

งบการเงินและงานตรวจสอบ

สร้าง chain of evidence สำหรับไฟล์ที่ต้องตรวจย้อนกลับตามรอบบัญชีและข้อกำกับ

Research

ผลงานวิจัยและชุดข้อมูล

พิสูจน์ที่มา เวอร์ชัน และช่วงเวลาที่ข้อมูลหรือผลการทดลองมีอยู่

ทรัพย์สินทางปัญญา

ผูก hash, ผู้สร้าง และหลักฐานเวลาเพื่อรองรับการพิสูจน์ลำดับการสร้างและการถือครอง

CII

ข้อมูลโครงสร้างพื้นฐานสำคัญ

ปกป้องไฟล์กำหนดค่า แบบระบบ และข้อมูลปฏิบัติการที่มีผลกระทบสูง

Backup

Backup และหลักฐานเหตุการณ์

ตรวจว่าชุดสำรองและ log สำคัญยังเป็นชุดเดิมและมีประวัติการตรวจสอบต่อเนื่อง

What QSense Seal provides

เมื่อองค์กรส่งมอบไฟล์สำคัญ ผู้รับควรตอบได้ว่า
“ไฟล์นี้เชื่อถือได้เพราะอะไร”

QSense Seal จัดเก็บชุดหลักฐานที่สามารถตรวจสอบ ส่งต่อ และต่ออายุได้ตามระยะเวลาที่องค์กรต้องใช้ข้อมูล

เข้าใช้งาน QSense Seal ตรวจสอบไฟล์ที่ได้รับ

ส่งไฟล์อย่างปลอดภัยพร้อมหลักฐานที่ตรวจสอบได้ในระยะยาว

ข้อมูลมีอายุยาวแต่รูปแบบการเข้ารหัสที่คุ้มครองข้อมูลมีอายุจำกัด