CISA Series ตอนที่ 46 : D5 - ตู้เซฟดิจิทัล + กรมที่ดิน: Cryptography และ PKI

มาถึง 2 หัวข้อที่หลายคน “กลัว” ที่สุดในการสอบ CISA — Cryptography และ PKI

📚 อ่าน CyberSecurity Foundation EP.19 Cryptography 101 + EP.23 PKI & Certificates ก่อน — เข้าใจ Symmetric/Asymmetric, Digital Signature ≠ Encryption, CA/CRL/OCSP, Email security stack ในภาษาคน — กลับมา D5 ตรงนี้จะอ่านสบายขึ้นเยอะ

ข่าวดีคือ auditor ไม่ต้องเป็น cryptographer ไม่ต้องคำนวณ RSA (Rivest-Shamir-Adleman / asymmetric algorithm ที่ตั้งชื่อตามผู้คิดค้น) ไม่ต้องเขียน algorithm แค่ต้องเข้าใจ concept + audit perspective ก็พอ: ใช้อะไรเมื่อไหร่ จุดอ่อนอยู่ตรงไหน แล้วตัวจริงในข้อสอบคืออะไร

ในมุมบ้านดิจิทัล:

Cryptography = ตู้เซฟดิจิทัลสำหรับข้อมูล (Section 5.6)
PKI (Public Key Infrastructure / โครงสร้างพื้นฐานสำหรับ public-key cryptography) = กรมที่ดินที่รับรองว่ากุญแจนั้นเป็นของจริง (Section 5.7)

แบ่งบทเป็น 2 ส่วน

ส่วนที่ 1 — Cryptography: ตู้เซฟดิจิทัล (Section 5.6)#

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

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 — แยกให้ชัด#

Symmetric Key (กุญแจเดียวกันทั้ง encrypt และ decrypt)#

ทั้งสองฝ่ายใช้ key เดียวกัน
เร็วมาก เหมาะกับข้อมูลปริมาณเยอะ
ปัญหาหลัก: จะส่งสำเนา key ไปให้อีกฝ่ายอย่างปลอดภัยได้ยังไง?

ในมุมบ้าน ถ้าจะให้แม่บ้านเข้าได้ ต้องทำสำเนากุญแจให้ ปัญหาคือจะส่งกุญแจสำเนาไปให้แม่บ้านยังไงโดยไม่มีคนอื่นแอบก๊อบระหว่างทาง?

Algorithms:

AES (Advanced Encryption Standard) — มาตรฐานปัจจุบัน (128, 192, 256-bit)
3DES (Triple DES) — เก่าแล้ว phase out
RC4 (Rivest Cipher 4) — stream cipher เก่า มีช่องโหว่
DES (Data Encryption Standard) — broken แล้ว ห้ามใช้

Asymmetric Key (key คู่ — public + private)#

มี key คู่: public key (เปิดเผยได้) + private key (เก็บเป็นความลับ)
ใช้ public key encrypt → ใช้ private key decrypt (และในทางกลับ)
ช้ากว่า symmetric มาก (~1000x)
แก้ปัญหา key distribution ของ symmetric

ในมุมบ้าน ตู้รับพัสดุ ใครก็โยนของเข้าตู้ได้ (public key = ล็อคได้ทุกคน) แต่มีแค่เจ้าของที่เปิดตู้ออกได้ (private key = ไขได้คนเดียว)

Algorithms:

RSA — มาตรฐาน (1024 bit เก่าแล้ว, 2048+ ปัจจุบัน, 4096 สำหรับงาน sensitive)
ECC (Elliptic Curve Cryptography) — key สั้นกว่า ปลอดภัยเท่ากัน (เหมาะกับ mobile/IoT = Internet of Things)

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 (Message-Digest Algorithm 5) — broken ห้ามใช้
SHA-1 (Secure Hash Algorithm version 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) (เข้ารหัสจากต้นทางถึงปลายทาง โดย node กลางอ่านไม่ได้)

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:

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

วิธีตรวจ signature:

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

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

พิสูจน์ว่าส่งจากที่นี่ (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 (การเข้ารหัสแบบประมวลผลได้)

ลองคิด scenario นี้ครับ — โรงพยาบาลอยากให้ Google Cloud วิเคราะห์ข้อมูลผู้ป่วยเพื่อหา pattern โรค แต่ส่งข้อมูลให้ตรงๆ ก็ leak สุขภาพคนไข้ทันที (PDPA / HIPAA โดน fine ยับ) Homomorphic encryption แก้ปัญหาคือ — encrypt ข้อมูลก่อน, Google คำนวณบน ciphertext ได้เลย โดยที่ไม่เห็นค่าจริง, แล้วส่ง result เข้ารหัสกลับมา โรงพยาบาลถอดรหัสเอง

3 ระดับของ Homomorphic Encryption (CRM list)

ระดับ	ทำได้แค่ไหน	ตัวอย่าง algorithm
PHE (Partially Homomorphic Encryption)	รองรับ operation อย่างเดียว — บวก หรือ คูณ อย่างใดอย่างหนึ่ง แต่ทำได้ไม่จำกัดจำนวนครั้ง	RSA (multiplicative homomorphism), Paillier (additive homomorphism), ElGamal
SHE (Somewhat Homomorphic Encryption)	รองรับทั้งบวกและคูณ แต่จำนวนครั้งจำกัด ก่อน “noise” ใน ciphertext จะสะสมจนถอดรหัสไม่ได้	BGV variant ตอนเริ่มยุค
FHE (Fully Homomorphic Encryption)	บวก + คูณ ไม่จำกัด — desired state	Gentry 2009 breakthrough, BFV, CKKS, TFHE

Use cases ที่ใช้ได้จริงตอนนี้

Cloud computation บนข้อมูล sensitive — outsource compute โดยไม่ leak ข้อมูล
Private ML inference — ส่ง encrypted input ไปให้ ML model, ได้ encrypted prediction กลับ (model owner ไม่เห็น input, user ไม่เห็น model weight)
GDPR / privacy-by-design — ประมวลผลโดยไม่ต้อง decrypt = ลด risk ของ data breach

Challenge ที่ CRM ย้ำ

ช้ามาก — FHE overhead เคยอยู่ระดับ 10^6 เท่าของ plaintext computation (ดีขึ้นเรื่อยๆ แต่ยังไม่ practical สำหรับ workload ใหญ่)
Algorithm ใหญ่ ซับซ้อน — multiplication เป็น operation ที่ noise สะสมเร็วสุด
Scaling problem — ทุก user ต้องมี database แยกของตัวเอง encrypt ด้วย key ตัวเอง = cost บาน
Standardization ยังไม่เสร็จ — NIST, ISO ยังทำมาตรฐานอยู่

ในมุม exam Homomorphic ยังไม่ใช่ technology ที่ใช้ production scale ทั่วไป แต่ ISACA ถามเพราะมัน represent direction ของ privacy-preserving computation ในอนาคต

ข้อสอบ 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 ออกไม่ได้

HSM — Hardware Security Module#

HSM (Hardware Security Module / ฮาร์ดแวร์เฉพาะสำหรับเก็บ private key) = อุปกรณ์ hardware เฉพาะสำหรับ:

Generate key — สร้าง key คู่ใหม่ภายในกล่อง (private key ไม่เคยออกจาก HSM)
Store key (extract ไม่ได้) — เก็บ key ในกล่องที่งัดทางกายภาพไม่ได้ ทำลายตัวเองถ้าโดนทุบ
Perform crypto operation (sign, encrypt) ภายใน HSM — ทำงาน sign / encrypt ในกล่อง โดยที่ key ไม่ออกไปไหน

ใช้กับ:

PKI Root CA — private key ของ Root CA ห้ามออกจาก HSM
Payment processing — PCI DSS require HSM สำหรับ card data
Banking — HSM ที่ ATM, online banking
Cloud KMS (Key Management Service) — AWS CloudHSM, Azure Dedicated HSM

ข้อสอบ trap: “Root CA private key — เก็บที่ไหน?”

หลอก: encrypted file บน server
จริง: HSM ใน offline environment + dual custody

TPM — Trusted Platform Module#

TPM (Trusted Platform Module) = chip บน motherboard ที่:

เก็บ encryption key สำหรับ disk encryption (BitLocker, FileVault)
Verify integrity ของ boot process
Attestation — พิสูจน์ว่า OS ที่ boot ไม่ถูก tamper

Secure Boot#

Secure Boot = process ที่ verify firmware + bootloader + OS kernel ก่อน load

แต่ละชั้น sign โดย key ที่ trusted — ถ้า signature ไม่ valid → ไม่ load

ป้องกัน rootkit ที่ฝังก่อน OS load

มุม IS auditor: ระบบ critical (ATM, PoS, medical device) ที่ไม่มี TPM + Secure Boot = supply chain risk + persistent malware risk รออยู่

Common Criteria / EAL / FIPS 140 — Security Certification#

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

Common Criteria (ISO/IEC 15408)#

Common Criteria = international standard สำหรับ evaluate IT product security

แต่ละ product ที่ผ่าน CC ได้ EAL (Evaluation Assurance Level) 1-7:

EAL 1-2 — basic — functional testing
EAL 3-4 — moderate — methodically tested + reviewed (commercial product ทั่วไปสูงสุดที่ได้)
EAL 5-7 — high — semi/formally verified (military, intelligence)

กับดักของ exam: “EAL 7 = ใช้กับธุรกิจทั่วไปดีกว่า” — ผิดเลย EAL สูง = development cost สูง + flexibility ต่ำ เลือก EAL ที่เหมาะกับ risk

FIPS 140 — US Standard สำหรับ Crypto Module#

FIPS 140-2 / 140-3 (Federal Information Processing Standards / มาตรฐาน US) = US Federal standard สำหรับ certify crypto module

4 ระดับ:

Level 1 — basic — algorithm ผ่าน NIST validation
Level 2 — tamper-evidence (เห็นถ้าถูกแกะ)
Level 3 — tamper-resistance (resist physical attack)
Level 4 — tamper-active (zero out key เมื่อถูก attack)

HSM ส่วนใหญ่ที่ใช้ใน production = FIPS 140-2 Level 3 ขึ้นไป

มุม IS auditor: ก่อน approve crypto product สำหรับระบบ critical verify FIPS validation certificate ที่ NIST CMVP

Email Security — SMTP / SPF / DKIM / DMARC#

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

ระบบ email security:

SMTP (Simple Mail Transfer Protocol) — protocol ส่ง email
SPF (Sender Policy Framework) — ระบุว่า server ไหนส่ง email ในนาม domain ได้
DKIM (DomainKeys Identified Mail) — sign email ด้วย private key ของ domain
DMARC (Domain-based Message Authentication, Reporting and Conformance) — policy ว่าจะทำอย่างไรกับ email ที่ fail SPF/DKIM

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

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

S/MIME vs PGP — Encrypt/Sign Email Content#

SPF/DKIM/DMARC ป้องกัน domain spoofing แต่ content ของ email ยังเป็น plaintext อยู่

ถ้าต้องการ confidentiality ของเนื้อหา → ใช้:

S/MIME (Secure/Multipurpose Internet Mail Extensions) — ใช้ X.509 certificate (จาก PKI ขององค์กร) — เหมาะ enterprise
PGP (Pretty Good Privacy) / OpenPGP / GPG (GNU Privacy Guard) — ใช้ web-of-trust (ผู้ใช้รับรองกันเอง ไม่ต้องผ่าน CA) — เหมาะ individual

ทั้งคู่ทำได้:

Sign — integrity + authentication + non-repudiation
Encrypt — confidentiality

กับดักของ exam: S/MIME vs PGP ต่างกันยังไง — S/MIME = X.509/CA-based, PGP = web-of-trust exam ออก distinguish trust model

Encryption Audit Procedures — ตรวจ encryption ดูอะไรบ้าง#

post นี้คุยเรื่อง encryption ไปเยอะแล้ว แต่ขาดเรื่องที่ auditor ต้องลงมือทำจริง คือ audit procedures เปิดเข้าไปดูระบบ encryption ขององค์กรแล้วจะตรวจอะไร เก็บหลักฐานยังไง

CISA framework แบ่งการตรวจ encryption เป็น 5 area:

1. Governance — มี policy ไหม#

Encryption policy เขียนไว้เป็นลายลักษณ์อักษรไหม
ผู้บริหารระดับสูง (CIO / CISO / board) อนุมัติแล้วหรือยัง
ทบทวนทุกปีไหม หรือทิ้งไว้ตั้งแต่ปี 2015

ถ้าไม่มี policy = ใครก็เลือก algorithm ใช้กันเองตามใจ คือเสี่ยงสุด

2. Design — algorithm + key length เหมาะกับ data ไหม#

ข้อมูล confidential ใช้อะไรเข้ารหัส
AES-256 สำหรับ symmetric, RSA 2048+ สำหรับ asymmetric เป็นมาตรฐานขั้นต่ำปัจจุบัน
ECC ใช้กับ mobile/IoT ที่ resource จำกัด

trap คลาสสิก องค์กรใช้ AES-128 กับข้อมูลธรรมดา แต่ใช้ DES กับข้อมูลพนักงานเก่า เพราะ “ระบบเดิมยังไม่ migrate” ตรงนี้ auditor ต้อง flag เลยครับ

3. Key Management — ขั้นที่บกพร่องที่สุด#

ตรงนี้แหละที่ตกบ่อย ตรวจ 5 ขั้น:

Key generation สร้าง key ด้วยอะไร random source แข็งแรงพอไหม
Key storage เก็บใน HSM/KMS หรือเก็บใน config file plaintext
Key rotation เปลี่ยน key ตามรอบไหม (อย่างน้อยปีละครั้ง)
Key escrow + recovery มีสำรองกรณีเจ้าของลืม / ลาออกไหม
Key destruction ทำลาย key เก่าด้วยขั้นตอนเป็นทางการ + มีหลักฐาน

4. Digital Signatures — PKI ใช้งานจริงไหม#

มี PKI infrastructure ไหม
CA ดูแลถูกต้องไหม (รายละเอียดในส่วน PKI ด้านล่าง)
CRL/OCSP ทำงาน + update ตามรอบไหม

5. Algorithm currency — ของเก่าเลิกใช้แล้วยัง#

DES, MD5, SHA-1, RC4 ห้ามใช้ในระบบ production
มีแผน transition ไป post-quantum cryptography ไหม (NIST เริ่ม standardize แล้ว)

Audit area	คำถามที่ต้องถาม	หลักฐานที่ต้องเก็บ	สัญญาณอันตราย
Governance	มี encryption policy ไหม approved by ใคร	Policy document + approval signature	ไม่มี policy หรือ policy เก่ากว่า 3 ปี
Design	ใช้ algorithm + key length อะไรกับ data class ไหน	Architecture document + algorithm inventory	ใช้ AES-128 กับ confidential / RSA 1024 ใน production
Key Management	key เก็บที่ไหน rotation ทุกกี่เดือน	HSM/KMS config + rotation log + destruction certificate	key เก็บใน config file / ไม่มี rotation log / ไม่มีหลักฐานทำลาย
Digital Signatures	PKI / CA / CRL ทำงานปกติไหม	CA audit log + CRL freshness report	CRL ไม่ update เกิน 30 วัน
Algorithm currency	ยังมี DES/MD5/SHA-1/RC4 ใน production ไหม	Cryptographic inventory scan	ใช้ deprecated algorithm + ไม่มีแผน migrate

หัวใจของ encryption audit ไม่ใช่ “ใช้ AES ไหม” แต่คือ “ครบทั้ง 5 area ไหม” ระบบที่ใช้ AES-256 แต่เก็บ key ใน plaintext file = อ่อนพอๆ กับไม่ encrypt เลย

ส่วนที่ 2 — PKI: กรมที่ดินดิจิทัล (Section 5.7)#

ปัญหาที่ 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 (CA / ผู้ออกใบรับรอง digital) = หน่วยงานที่ออกใบรับรอง (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 / รายการ cert ที่ revoke)

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

OCSP (Online Certificate Status Protocol) (real-time query ไปยัง CA)

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 — 7 area framework#

ตรวจ PKI ไม่ใช่แค่ “มี CA ไหม” จบ แต่ต้องดู 7 area:

1. CA Review — หัวใจของทุกอย่าง#

Physical security ของ CA server อยู่ใน data center ที่เข้าได้แค่คนที่ได้รับอนุญาตไหม
HSM use private key อยู่ใน HSM (extract ไม่ได้) ไม่ใช่ใน file
CA log integrity log ทุก operation, log นั้นแก้ไม่ได้ (write-once / append-only)

Root CA ต้อง offline + dual custody เสมอ ถ้า Root CA online = ตกเลย

2. RA Review — คนกลั่นกรองก่อนออก cert#

RA (Registration Authority / ผู้ verify ตัวตนก่อน CA sign cert) = หน่วยงานที่ verify identity ของผู้ขอ certificate ก่อนส่งให้ CA issue

ขั้นตอน verify identity ทำยังไง (เอกสาร / face-to-face / digital ID)
Separation of duties คนทำ RA ต้องไม่ใช่คนเดียวกับ CA admin (ถ้าเป็นคนเดียวกัน = ออก cert ปลอมให้ตัวเองได้)

3. Certificate Policy (CP) — “what”#

CP (Certificate Policy) คือเอกสารระดับ policy ที่บอก “PKI นี้ trust ระดับไหน, ใช้กับงานอะไรได้บ้าง” สั้นกว่า เป็น high-level statement

4. Certification Practice Statement (CPS) — “how”#

CPS (Certification Practice Statement) คือ operational manual ของ CA เอกสาร 50+ หน้าที่บอกทุกขั้นตอน ตั้งแต่ verify identity ถึง revoke cert

CP vs CPS — exam-trap คลาสสิก:

เอกสาร	บอกอะไร	อุปมา
CP (Certificate Policy)	“what” — trust statement	นโยบายบริษัท
CPS (Certification Practice Statement)	“how” — operational procedure	คู่มือพนักงาน

ข้อสอบ trap: “เอกสารไหนบอกว่า PKI ดำเนินการ ยังไง?”

หลอก: CP
จริง: CPS (CP บอก “what” / CPS บอก “how”)

5. CRL + OCSP — ช่องทาง revocation ยังไหวไหม#

Distribution channel CRL publish ที่ไหน (HTTP URL ที่ระบุใน certificate)
Update frequency กี่ชั่วโมง / กี่วัน
Freshness check auditor sample certificate มาตรวจว่า revocation status update จริงไหม

CRL ที่ไม่ update เกิน 30 วัน = red flag

6. Key Management — เหมือน encryption แต่ระดับ PKI#

Key escrow มีสำรอง private key กรณีเจ้าของลืม / ลาออกไหม (เฉพาะ encryption key — signing key ไม่ควร escrow เพราะกระทบ non-repudiation)
Recovery process ขั้นตอน recover key ที่ต้องมี approval หลายระดับ
Destruction เมื่อ certificate หมดอายุ key เก่าทำลายยังไง มีหลักฐานไหม

7. Compliance — มาตรฐานที่ third party ตรวจแล้ว#

FIPS 140-2 / 140-3 HSM ของ CA ผ่าน validation level เท่าไหร่ (Level 3 ขึ้นไปสำหรับ production)
PCI DSS ถ้า PKI เกี่ยวกับ payment data
WebTrust for CA มาตรฐาน trust ที่ browser vendor (Microsoft, Mozilla, Apple, Google) ใช้ตัดสินใจ trust public CA
ETSI EN 319 411 มาตรฐาน EU สำหรับ trust service provider

Audit area	ดูอะไร	หลักฐาน	สัญญาณอันตราย
CA Review	physical + HSM + log	data center access log + HSM serial + CA audit log	Root CA online / private key อยู่ใน file
RA Review	identity verification + separation of duties	RA procedure + org chart	RA = CA admin คนเดียวกัน
CP	high-level trust statement	CP document	ไม่มี CP / CP ไม่ approve โดย management
CPS	operational manual	CPS document	CPS เก่ากว่า 2 ปี / ไม่ตรงกับ practice จริง
CRL + OCSP	freshness + availability	CRL timestamp + OCSP response sample	CRL ไม่ update เกิน 30 วัน
Key Management	escrow + recovery + destruction	KMS log + destruction certificate	signing key มี escrow / ไม่มีหลักฐานทำลาย
Compliance	FIPS + WebTrust + ETSI	validation certificate	HSM ไม่ผ่าน FIPS Level 3

ข้อสอบ trap: “Public CA ที่อยากให้ browser trust ต้องผ่าน audit อะไร?”

หลอก: FIPS 140
จริง: WebTrust for CA (FIPS ดู crypto module, WebTrust ดู CA operation)

Trap Summary ทั้ง Section 5.6 + 5.7#

สถานการณ์	คำตอบหลอก	คำตอบจริง
Digital signature ตอบ security ไหน	Confidentiality	Integrity + Authentication (ไม่ใช่ confidentiality)
Symmetric encryption ปัญหาหลัก	ช้า	Key distribution — ส่ง key อย่างปลอดภัยยังไง
Quantum threat algorithm ไหนน่ากังวล	Symmetric AES	RSA / asymmetric
Homomorphic encryption ใช้สำหรับอะไร	Email security	ประมวลผลข้อมูล encrypted บน cloud โดยไม่ decrypt
Root CA compromise ผลกระทบ	บาง cert ใช้ไม่ได้	ทั้ง PKI infrastructure ต้อง reissue
OCSP vs CRL อันไหน current	CRL	OCSP (real-time)
1024-bit RSA — auditor concern	ไม่กังวล	อ่อน — ขั้นต่ำควร 2048-bit
Web cert expired — กังวลที่สุด	website เข้าไม่ได้	untrusted connection + อาจถูก intercept

เชื่อมไปบทถัดไป#

ตอนนี้บ้านดิจิทัลมี:

กฎ + กำแพง (ตอน 43)
กุญแจ (ตอน 44)
ถนน + ยามตรวจของออก (ตอน 45)
ตู้เซฟ + กรมที่ดิน (ตอน 46 — บทนี้)

แต่บางคนไม่ได้สร้างบ้านเอง เช่าอพาร์ตเมนต์ในตึกของคนอื่น (cloud) ให้ cleaning services ดูแลให้ (managed services)

ทั้งหมดนี้คือเรื่องของ Cloud Security เมื่อขอบเขตของบ้านดิจิทัลขยายไปอยู่ในตึกของคนอื่น ใครรับผิดชอบอะไร?

จะคุยต่อตอนหน้าใน Section 5.8 ครับ

เรื่องที่ลึกกว่านี้อ่านได้ที่:#

Cryptography deep#

Kerberos internals (KDC/TGS/AS/TGT + Session Key + ST + Mimikatz/Golden/Silver/Kerberoasting attacks) → cybersec EP.14 — Kerberos (CRM placement: Section 5.6.14)
TLS Handshake + Record Protocol + cipher suite negotiation → cybersec EP.24 — TLS + HTTPS
N×2 vs N²/2 key scaling math + Quantum Cryptography (QKD/BB84) + Homomorphic 3 types + SSH 9 best practices → cybersec EP.21 — Asymmetric RSA/DH (เพิ่มรอบนี้)
DNSSEC 2-stage + NSEC/NSEC3 zone enumeration + DNS cache poisoning + Kaminsky → cybersec EP.30 — VPN/Proxy/DNS
IPSec internals (Transport vs Tunnel + SA + ISAKMP + IKE) → cybersec EP.30
Email security MOSS/PEM legacy formats → cybersec EP.25 — Email Security SPF/DKIM/DMARC
Cryptanalysis + key randomness + brute force time complexity → cybersec EP.20 — Symmetric AES

PKI deep#

PKI Repository as component + RA separation + 6 revocation reasons (Affiliation / Key Compromise / CA Compromise / Cessation / Privilege Withdrawn / Superseded) + 11 PKI risks catalog + CRL data fields + CP vs CPS distinction + Compliance (FIPS / PCI DSS / WebTrust / ETSI) → cybersec EP.23 — PKI + Certificates (เพิ่มรอบนี้)

อ้างอิง CRM (CISA Review Manual 28th Edition): Domain 5: Section 5.6 Data Encryption + Section 5.7 Public Key Infrastructure