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

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 ได้ (ทาง 2 ทาง)
• 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)

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#

ในปี 2021 มี 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)
• RA (Registration Authority) enrollment process — ใครจะออก cert ได้
• Key strength (RSA 2048+ minimum, ECC ที่เหมาะสม)
• Certificate lifecycle automation
• Revocation mechanism (CRL/OCSP) ทำงานจริงไหม
• CPS (Certification Practice Statement) compliance
• Audit logs ของ CA operations