หลักพื้นฐาน — กุญแจคืออะไร#

Encryption ไม่ใช่แค่ “ปลอดภัยแล้ว” จบ มันมี 4 องค์ประกอบที่กำหนดความแข็งแรงจริง:

• Algorithm — สูตรคณิตศาสตร์ที่ใช้แปลง plaintext → ciphertext
• Key — ตัวแปรที่ทำให้ผลลัพธ์ unique ต่อการใช้งาน
• Key length — ยิ่งยาวยิ่ง brute force ยาก
• Key management — การเก็บ แจก เปลี่ยน ทำลาย key

ลองเปรียบ ถ้า encryption เหมือนการล็อกของในตู้เซฟ:

• Algorithm = ยี่ห้อกลไกของล็อค
• Key = รหัสที่ใช้ปลด
• Key length = จำนวนหลักของรหัส
• Key management = ใครรู้รหัส เก็บที่ไหน เปลี่ยนเมื่อไหร่

ระบบที่ดีต้องครบทั้ง 4 algorithm แข็งแกร่งแต่ key สั้น = อ่อน, key ยาวแต่เก็บไว้ใน plaintext = อ่อนเหมือนกัน

Symmetric vs Asymmetric — แยกให้ชัด#

Hybrid Approach — TLS/HTTPS ใช้ทั้งสอง#

ในชีวิตจริง ระบบที่ดีใช้ทั้งสองพร้อมกันเลย:

1
Step 1: ใช้ Asymmetric เพื่อแลก session key อย่างปลอดภัย
2
Step 2: ใช้ Symmetric (session key นั้น) encrypt ข้อมูลจริง

นี่แหละเหตุผลที่ HTTPS เร็ว ใช้ asymmetric แค่ตอน handshake แลก key แล้วใช้ symmetric กับข้อมูลจริงทั้ง session

Hashing — ทาง 1 ทาง#

Hashing ≠ encryption

• Encryption = encrypt → decrypt ได้ (ไป-กลับ)
• Hashing = แปลงไป ทางเดียว decrypt กลับไม่ได้

ใช้สำหรับ:

• Integrity verification — hash ก่อน + hash หลัง ตรงกันไหม
• Password storage — เก็บ hash ไม่เก็บ plaintext
• Digital signature — hash + sign

Algorithms:

• MD5 — broken ห้ามใช้
• SHA-1 — broken ห้ามใช้สำหรับ security
• SHA-2 (SHA-256, SHA-512) — current standard
• SHA-3 — current alternative

ข้อสอบ trap: “องค์กรใช้ SHA-1 สำหรับ file integrity — auditor กังวลอะไร?”

หลอก: SHA-1 ช้า จริง: SHA-1 broken แล้ว (collision attacks demonstrated) ต้อง upgrade เป็น SHA-2/SHA-3

Link Encryption vs End-to-End Encryption#

Link encryption

• Encrypt ที่ทุก hop ของ network
• ที่ intermediate node ต้อง decrypt → encrypt ใหม่
• Intermediate nodes เห็น plaintext ระหว่างนั้น

End-to-End Encryption (E2EE)

• Encrypt ที่ต้นทาง → decrypt ที่ปลายทางเท่านั้น
• ไม่มี node กลางอ่านได้
• ตัวอย่าง: WhatsApp messaging, Signal

E2EE ดีกว่าสำหรับการสื่อสารที่ sensitive เพราะแม้ provider เอง (Meta, Google) ก็อ่านไม่ได้

Digital Signature ≠ Encryption — Top Trap ของ Crypto#

trap นี้ใหญ่ของ Domain 5 เลยครับ

Digital Signature ทำได้ 3 อย่าง:

• Authentication — พิสูจน์ว่าใครเป็นคนส่ง
• Integrity — พิสูจน์ว่าไม่ถูกแก้ระหว่างทาง
• Non-repudiation — ผู้ส่งปฏิเสธไม่ได้ว่าไม่ได้ส่ง

Digital Signature ไม่ได้ทำ confidentiality ใครก็อ่านได้

วิธีทำ signature:

1. Hash ของ message
2. Encrypt hash นั้นด้วย private key ของผู้ส่ง
3. แนบไปกับ message

วิธีตรวจ signature:

1. Decrypt signature ด้วย public key ของผู้ส่ง → ได้ hash ที่ส่งมา
2. Hash message อีกครั้ง → เปรียบเทียบกัน
3. ตรงกัน = ของจริง + ไม่ถูกแก้

ในมุมบ้าน เปรียบเสมือนตราประทับลงทะเบียนของไปรษณีย์

• พิสูจน์ว่าส่งจากที่นี่ (authentication)
• พิสูจน์ว่าซองไม่ถูกเปิด (integrity)
• ไม่ได้ป้องกันคนอื่นอ่าน (confidentiality ต้องใช้ encryption แยกอีกอันนะ)

ข้อสอบ trap: “Digital signature ตอบโจทย์ security อะไร?”

หลอก: Confidentiality จริง: Integrity + Authentication (ไม่ใช่ confidentiality)

Digital Envelope#

Digital Envelope = symmetric key ที่ถูก encrypted ด้วย public key ของผู้รับ

ใช้แก้ปัญหา key distribution ของ symmetric encrypt ข้อมูลด้วย symmetric key (เร็ว) แล้วเอา symmetric key ใส่ envelope ด้วย public key ของผู้รับ (ปลอดภัย)

ECC, Quantum, Homomorphic — เรื่องอนาคต#

ECC (Elliptic Curve Cryptography)

• Asymmetric ที่ใช้ key สั้นกว่า RSA แต่ปลอดภัยเท่ากัน
• เหมาะกับ mobile, IoT, low-power devices

Quantum threat

• Quantum computer (เมื่อพร้อม) จะ break RSA และ asymmetric ปัจจุบันหลายตัว
• Symmetric (AES) ทนกว่า quantum แค่ลดความแข็งแรงครึ่งหนึ่ง
• “Harvest now, decrypt later” attack เก็บ encrypted data วันนี้ รอ quantum มา decrypt วันหน้า
• NIST กำลัง standardize post-quantum cryptography

Homomorphic Encryption

• ประมวลผลข้อมูล encrypted ได้โดยไม่ต้อง decrypt
• ใช้สำหรับ privacy-preserving cloud computation
• ยังช้ามากในปัจจุบัน ใช้งาน production จำกัด

ข้อสอบ trap: “Quantum threat — algorithm ไหนกระทบที่สุด?”

หลอก: Symmetric AES จริง: RSA / asymmetric public key (ที่อิง integer factorization)

Hardware Root of Trust — HSM, TPM, Secure Boot#

Software-only crypto มีจุดอ่อน key อยู่ใน memory ของ OS malware ที่ admin level อ่านได้สบาย

Hardware-based crypto แก้ปัญหานี้ key อยู่ใน chip ที่ extract ออกไม่ได้

Common Criteria / EAL / FIPS 140 — Security Certification#

ก่อนซื้อ crypto product auditor จะดู certification ที่ third party ตรวจแล้ว

Email Security — SMTP / SPF / DKIM / DMARC#

Email ปกติเดินทางแบบ plaintext ใครก็อ่านได้

ระบบ email security:

• SMTP — protocol ส่ง email
• SPF (Sender Policy Framework) — ระบุว่า server ไหนส่ง email ในนาม domain ได้
• DKIM (DomainKeys Identified Mail) — sign email ด้วย private key ของ domain
• DMARC — policy ว่าจะทำอย่างไรกับ email ที่ fail SPF/DKIM

ทั้ง 3 ตัวรวมกันป้องกัน email spoofing คือกัน domain ถูก impersonate

มุมผู้บริหาร: SPF + DKIM + DMARC = one-time configuration ที่ป้องกัน phishing ที่ปลอม email บริษัทได้ ROI สูงมากเลย

ปัญหาที่ PKI แก้#

Asymmetric encryption ใช้ public key ที่ใครก็เห็น แต่ปัญหาคือ:

“public key ที่ฉันใช้ เป็นของคนที่ฉันคิดจริงๆ ไหม?”

ถ้าผู้ไม่หวังดีปลอม public key ของธนาคารแล้วส่งให้ฉัน ฉัน encrypt ข้อมูลด้วย key ปลอม → ผู้ไม่หวังดี decrypt ได้ ธนาคารไม่ได้รับข้อมูลจริง

นี่แหละ man-in-the-middle attack

PKI = ระบบที่แก้ปัญหานี้ด้วย chain of trust

CA — Certificate Authority#

Certificate Authority = หน่วยงานที่ออกใบรับรอง (certificate) ยืนยันว่า “public key นี้ เป็นของคนนี้/บริษัทนี้จริง”

ในมุมบ้าน เปรียบเหมือน กรมที่ดิน ที่ออกโฉนดบ้าน

• ใครก็อ้างว่าเป็นเจ้าของบ้านได้
• แต่ถ้ามีโฉนดที่กรมที่ดินรับรอง = trust ที่พิสูจน์ได้

ใน PKI:

• ถ้าเชื่อ CA = เชื่อ certificate ที่ CA sign
• Browser/OS มี list ของ CA ที่ trusted (Root CA Store) มาให้แล้ว

Certificate Lifecycle#

Key management cycle:

• Generation — สร้าง key pair
• Distribution — แจก public key ผ่าน certificate
• Storage / Custody — เก็บ private key ปลอดภัย (HSM, smart card)
• Rollover — เปลี่ยน key ตามรอบ (อย่างน้อยทุก 1-2 ปี)
• Recovery / Backup — มี escrow หรือ backup กรณีลืม
• Destruction — ทำลาย key อย่างเป็นทางการ (มี certificate การทำลาย)

หลัก audit คลาสสิก: ขั้นที่ บกพร่องบ่อยที่สุด คือ destruction certification องค์กรหลายแห่งไม่มีหลักฐานว่า key เก่าถูกทำลายจริง

Certificate Revocation — ก่อนหมดอายุ#

Certificate ปกติมี expiration date แต่บางครั้งต้องเพิกถอนก่อนหมดอายุ:

• พนักงานออก
• private key compromised
• ระบบถูก decommission
• CA โดน hack

นี่แหละ revocation ต่างจาก expiration ตรงที่ revocation เป็นการเพิกถอนทันที

CRL vs OCSP — วิธีบอก client ว่า cert ถูก revoke#

CRL (Certificate Revocation List)

• รายชื่อ serial number ของ certificate ที่ถูก revoke
• CA publish เป็นรอบ (เช่น ทุก 24 ชั่วโมง)
• มี latency — ระหว่างรอบ publish — มีหน้าต่างที่ certificate ที่เพิ่ง revoke ยังถูก trust อยู่

OCSP (Online Certificate Status Protocol)

• Real-time query ไป CA: “certificate ใบนี้ยังใช้ได้ไหม?”
• ได้ status ทันที
• ปัญหา: CA load สูง + privacy (CA รู้ว่า client check certificate ไหน)

OCSP Stapling

• Server แนบ OCSP response มากับ certificate ระหว่าง TLS handshake
• ลด load ของ CA + ลด privacy leak

ข้อสอบ trap: “CRL vs OCSP — อันไหนให้ revocation status ที่ current ที่สุด?”

หลอก: CRL (publish เป็นประจำ) จริง: OCSP (real-time query) — CRL มี latency

Root CA Compromise — Worst Case#

ถ้า Root CA ถูก compromise ทั้ง PKI พังทันที

เพราะ certificate ทุกใบที่ Root CA sign กลายเป็น untrusted ต้อง reissue ใหม่หมด เป็นหายนะระดับ system-wide เลย

ดังนั้น Root CA ต้อง:

• เก็บใน HSM (Hardware Security Module)
• อยู่ใน offline environment
• มี dual custody (ต้องมี 2 คนมาเปิด)
• มี physical security ระดับสูงสุด

ข้อสอบ trap: “Root CA private key compromised — consequence ที่ร้ายแรงที่สุด?”

หลอก: บาง certificate untrusted จริง: ทั้ง PKI infrastructure untrusted ต้อง reissue certificate ทั้งหมด

Certificate Expiry — Preventable Outage#

เคยมี mobile network operator รายใหญ่ในยุโรปประสบ outage ครั้งใหญ่ สาเหตุคือ certificate หมดอายุที่ไม่มีใคร track

นี่คือปัญหาที่ป้องกันได้ แต่หลายองค์กรยังจัดการ certificate ด้วย spreadsheet ที่ไม่มีใคร update อยู่ดี

หลัก audit: องค์กรต้องมี automated certificate lifecycle management (CLM) ไม่ใช่ manual tracking

PKI Audit Procedures — สรุป#

Auditor ตรวจ PKI ดูอะไรบ้าง:

• Root CA security (physical, logical, dual custody) — Root CA ตัวจริง offline + อยู่ใน HSM + ต้อง 2 คนถึงเปิดได้
• RA (Registration Authority) enrollment process — ใครจะออก cert ได้
• Key strength (RSA 2048+ minimum, ECC ที่เหมาะสม)
• Certificate lifecycle automation — automate ขั้นตอน issue / renew / revoke certificate (เช่น ACME, cert-manager) แทนทำมือ
• Revocation mechanism (CRL/OCSP) ทำงานจริงไหม
• CPS (Certification Practice Statement) compliance — เอกสารที่ CA บอกว่าตัวเอง issue cert ตาม process อะไร verify ว่าทำตามจริงไหม
• Audit logs ของ CA operations — log ทุก issue / revoke / config change ของ CA