หน้านี้ตอบคำถามเดียว: ของที่ทำเสร็จแล้ว มันทำงานยังไง — เขียนจากโค้ดที่ merge แล้วจริง ไม่ใช่จากแผน

ไม่มีขั้นตอนติดตั้ง ไม่มีโค้ดให้ copy (อยู่หน้าติดตั้ง) · ที่นี่มีแค่ ของเทียบให้เห็นภาพ + ภาพลำดับว่าใครคุยกับใคร

ตอนนี้มี 2 กลไกที่ทำเสร็จและพิสูจน์แล้วบน service จริง

1. Body signature — ลายเซ็นกำกับทุกคำขอ

เทียบกับของจริง: เช็คที่เซ็นสั่งจ่าย

เวลาเราเขียนเช็ค เราไม่ได้เซ็นลอย ๆ — เราเซ็นบนใบที่มีตัวเลขเขียนอยู่แล้ว ถ้ามีคนไปแก้ตัวเลขทีหลัง ลายเซ็นนั้นใช้ไม่ได้ทันที เพราะมันผูกกับเนื้อความทั้งใบ

ระบบนี้ทำแบบเดียวกันกับทุก request:

จุดสำคัญ: ไม่มีความลับฝั่ง server เลย — server เก็บแต่ “ตัวอย่างลายเซ็น” ซึ่งเป็นของสาธารณะ หลุดไปก็ปลอมลายเซ็นไม่ได้ · กลไกนี้ไม่ต้องใช้ Key Vault

ลงทะเบียนครั้งแรก — ครั้งเดียวต่อเครื่อง

sequenceDiagram
    autonumber
    participant B as เบราว์เซอร์
    participant S as Service
    participant R as Redis

    B->>B: สร้างกุญแจคู่ ECDSA P-256 ครั้งแรกที่เปิดเว็บ
    Note over B: ครึ่งลับถูกตั้งให้เอาออกจากเครื่องไม่ได้ตั้งแต่วินาทีที่สร้าง
    B->>S: ส่งเฉพาะครึ่งเปิดเผยไปลงทะเบียน
    S->>R: จองช่องของผู้ใช้คนนี้ ถ้ายังว่าง
    alt ช่องว่าง
        R-->>S: จองสำเร็จ
        S-->>B: ลงทะเบียนแล้ว
    else มีกุญแจเดิมอยู่ และเป็นดอกเดียวกัน
        S-->>B: ถือว่าสำเร็จเงียบ ๆ เผื่อผู้ใช้ refresh หน้า
    else มีกุญแจเดิมอยู่ แต่คนละดอก
        S-->>B: ปฏิเสธ 409
    end

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

ผลข้างเคียงที่เจอบ่อย: ล้างข้อมูลเบราว์เซอร์ หรือเปิด profile ใหม่ = กุญแจใหม่ = โดน 409 ต้องลบของเดิมใน Redis ก่อน

ทุกคำขอหลังจากนั้น

sequenceDiagram
    autonumber
    participant B as เบราว์เซอร์
    participant S as Service
    participant R as Redis
    participant H as Handler

    B->>B: ประกอบข้อความสรุปคำขอ แล้วเซ็นด้วยกุญแจในเครื่อง
    B->>S: ส่งคำขอ พร้อมลายเซ็นและเวลาแนบไปในหัวจดหมาย
    S->>S: เวลาห่างเกิน 5 นาทีไหม
    S->>R: ขอตัวอย่างลายเซ็นของผู้ใช้คนนี้
    R-->>S: ครึ่งเปิดเผยที่ลงทะเบียนไว้
    S->>S: ประกอบข้อความสรุปคำขอเองอีกรอบ แล้วเทียบลายเซ็น
    S->>R: จดลายนิ้วมือของคำขอไว้ ถ้ายังไม่เคยเห็น
    alt เคยเห็นแล้ว
        S-->>B: ปฏิเสธ ยิงซ้ำ
    else ยังไม่เคยเห็น
        S->>H: ปล่อยเข้า handler
    end

“ข้อความสรุปคำขอ” คืออะไร — ทั้ง 2 ฝั่งประกอบเองจากของเดียวกัน 6 บรรทัด ไม่ได้ส่งข้ามมา:

v1
{เวลาเป็นวินาที}
{METHOD ตัวใหญ่}
{path}
{query ที่เรียงแล้ว}
{ลายนิ้วมือของ body}

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

2. Encryption Field — เข้ารหัสเฉพาะช่องที่อ่อนไหว

ไม่ได้เข้ารหัสทั้งคำขอ — เข้ารหัสเฉพาะช่องที่ระบุไว้ เช่น เลขบัตรประชาชน เบอร์โทร ที่อยู่ ส่วนช่องอื่นยังอ่านออกตามปกติ (จำเป็น เพราะ log กับ trace ต้องยังตามงานได้)

handler ไม่รู้เรื่องทั้ง 2 ทาง — ตอนรับก็เห็นค่าปกติ ตอนตอบก็ใส่ค่าปกติ มีตัวกลางแกะและห่อให้ก่อนและหลัง

เทียบกับของจริง: กล่องพัสดุที่มีซองกุญแจติดไปด้วย

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

ปัญหาคือ ถ้ากุญแจห้อยอยู่ข้างกล่อง ใครหยิบก็เปิดได้ ⇒ ต้องเอากุญแจใส่ซองแล้วล็อกซองไว้อีกที ให้เฉพาะปลายทางเปิดซองได้

นี่คือหัวใจ: กุญแจสุ่มมีจริงและสุ่มใหม่ทุกครั้ง — แต่มันเดินทางไปกับของ เลยไม่ได้แทนที่แม่กุญแจ มันแค่ทำให้แม่กุญแจทำงานน้อยลง (ล็อกแค่ซองเล็ก ๆ ไม่ต้องล็อกทั้งกล่อง) และถ้ากุญแจสุ่มดอกเดียวหลุด ก็เสียแค่กล่องใบนั้น

คำถามที่เหลืออยู่ข้อเดียวคือ ใครล็อกซอง — และคำตอบต่างกันตามทิศทาง เพราะ “ฝั่งไหนเป็นคนเปิด ฝั่งนั้นต้องมีแม่กุญแจถาวร”

ขาออกไม่ต้องใช้ Key Vault ไม่ใช่เพราะเลือกวิธีเก่งกว่า แต่เพราะเราเป็นฝ่ายส่ง ไม่ใช่ฝ่ายเปิด — แม่กุญแจถาวรมีอยู่จริง แต่มันเป็นของผู้ใช้ ไม่ใช่ของเรา เราเลยไม่มีอะไรต้องเก็บ

ขาเข้า — เบราว์เซอร์เข้ารหัสมา service ถอด

sequenceDiagram
    autonumber
    participant B as เบราว์เซอร์
    participant S as Service
    participant KV as Key Vault
    participant H as Handler

    S->>KV: ตอนแอปสตาร์ท ไปเอาแม่กุญแจของตัวเองมา
    Note over S: ไม่มีกุญแจ แอปไม่ยอมสตาร์ท ตั้งใจให้พังตอนนี้ ไม่ใช่ตอนผู้ใช้ยิงจริง
    B->>S: ขอครึ่งเปิดเผยของแม่กุญแจ service
    S-->>B: ครึ่งเปิดเผย พร้อมหมายเลขรุ่นของกุญแจ
    B->>B: สุ่มกุญแจใหม่ 1 ดอก ล็อกเฉพาะช่องที่อ่อนไหว
    B->>B: เอาครึ่งเปิดเผยของ service ล็อกซองที่ใส่กุญแจสุ่มไว้
    B->>S: ส่งคำขอ ช่องนั้นกลายเป็นก้อนอ่านไม่ออก ช่องอื่นปกติ
    S->>S: เปิดซองด้วยแม่กุญแจของตัวเอง ได้กุญแจสุ่มมา
    S->>S: ใช้กุญแจสุ่มเปิดค่าจริง แล้วใส่กลับเข้าที่เดิม
    S->>H: handler เห็นค่าปกติ ไม่รู้เลยว่าเมื่อกี้ถูกเข้ารหัสมา

ทำไมขาเข้าถึงเลี่ยง Key Vault ไม่ได้ — คนส่งมีเป็นพันเครื่อง คนเปิดมีตัวเดียวคือ service · request จะมาถึงตอนไหนก็ได้ ตอนตี 3 ก็ต้องเปิดได้ ⇒ แม่กุญแจต้องมีอยู่ตลอดเวลา ⇒ ต้องเก็บในที่ที่ปลอดภัย · เปลี่ยนไปใช้สูตรอื่นก็ยังต้องเก็บอยู่ดี เพราะเงื่อนไขคือ “service เป็นฝ่ายเปิด” ไม่ใช่เรื่องสูตร

ขาออก — service เข้ารหัสตอบกลับ เบราว์เซอร์ถอด

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

sequenceDiagram
    autonumber
    participant H as Handler
    participant S as Service
    participant R as Redis
    participant B as เบราว์เซอร์

    H->>S: คืนค่าปกติ ไม่ได้เข้ารหัสอะไร
    S->>R: ขอกุญแจรับของที่ผู้ใช้คนนี้ลงทะเบียนไว้
    alt ไม่เคยลงทะเบียน
        R-->>S: ไม่มี
        S-->>B: ส่งค่าปกติกลับไป ของเดิมยังใช้ได้ ไม่พัง
    else มี
        R-->>S: ครึ่งเปิดเผยของผู้ใช้
        S->>S: สร้างกุญแจใช้แล้วทิ้งขึ้นมาใหม่หนึ่งคู่
        S->>S: เอาครึ่งลับของตัวเอง ผสมกับครึ่งเปิดเผยของผู้ใช้ ได้แม่กุญแจ
        S->>S: สุ่มกุญแจล็อกค่าจริง แล้วใช้แม่กุญแจนั้นล็อกซองไว้
        S->>S: ทิ้งครึ่งลับของตัวเองทันที
        S-->>B: ส่งกลับ พร้อมแนบครึ่งเปิดเผยของกุญแจใช้แล้วทิ้ง
        B->>B: เอาครึ่งลับถาวรของตัวเอง ผสมกับครึ่งที่แนบมา
        Note over B: ได้แม่กุญแจดอกเดียวกันเป๊ะ ทั้งที่ไม่มีใครส่งแม่กุญแจข้ามสายเลย
        B->>B: เปิดซอง เอากุญแจสุ่มมาเปิดค่าจริง
    end

จุดที่คนเข้าใจผิดบ่อยที่สุด

“ในเมื่อกุญแจสุ่มหมด คนดักกลางก็ถอดได้สิ” — ไม่ได้ครับ เพราะแม่กุญแจไม่เคยเดินทาง มันถูกคำนวณขึ้นทั้งสองฝั่ง

เทียบง่าย ๆ เหมือนผสมสี: แต่ละฝ่ายมีสีลับของตัวเอง เอามาผสมกับสีที่อีกฝ่ายเปิดเผยไว้ แล้วได้สีผลลัพธ์เหมือนกันเป๊ะทั้งคู่ — คนกลางเห็นแต่สีเปิดเผยของทั้งสองฝ่าย ผสมยังไงก็ไม่ได้สีนั้น เพราะขาดสีลับ

ของลับสองอันที่คนกลางไม่มีทางได้:

• ครึ่งลับของ service — ทิ้งไปแล้วตั้งแต่ส่งเสร็จ ต่อให้บุกเข้า server ทีหลังก็ไม่มีให้ขโมย และเปิด response เก่าที่ดักไว้ไม่ได้
• ครึ่งลับของผู้ใช้ — ถูกสร้างมาแบบเอาออกจากเครื่องไม่ได้ตั้งแต่แรก

ทั้งสองกลไกอยู่ตรงไหนของคำขอเดียวกัน

sequenceDiagram
    autonumber
    participant B as เบราว์เซอร์
    participant G as Gateway
    participant S as Service
    participant H as Handler

    B->>G: คำขอ พร้อมลายเซ็น และช่องที่อ่อนไหวถูกเข้ารหัสไว้แล้ว
    G->>S: แปลง session เป็น token แล้วส่งต่อ
    S->>S: ตรวจ token ว่าเป็นใคร
    S->>S: ตรวจลายเซ็น ว่าคำขอนี้เจ้าตัวส่งเองและไม่ถูกแก้กลางทาง
    S->>S: ถอดช่องที่เข้ารหัสมา
    S->>H: handler ทำงานกับค่าปกติ
    H->>S: คืนค่าปกติ
    S->>S: เข้ารหัสช่องที่ระบุไว้ ให้เฉพาะเครื่องที่ขอมาเปิดได้
    S-->>B: ตอบกลับ

ลำดับนี้สลับไม่ได้ — ต้องรู้ก่อนว่าเป็นใคร (token) ถึงจะไปหยิบตัวอย่างลายเซ็นของคนนั้นมาตรวจได้ และต้องตรวจลายเซ็นให้ผ่านก่อน ถึงจะยอมเสียเวลาถอดรหัสให้

สรุปสั้นที่สุด