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

จุดกำเนิดพร้อมกับระบบ public-key

Merkle Tree (ชื่อเดิม hash tree หรือ authentication tree) เป็นผลงานของ Ralph C. Merkle หนึ่งในผู้บุกเบิกวงการการเข้ารหัสแบบกุญแจสาธารณะ และผู้สร้างกระบวนการแฮชแบบปลอดภัย โดยเขายื่นขอสิทธิบัตร authentication tree ในปี 1979 เพื่อเป็นการยืนยันว่ามีการส่งข้อความจากต้นทางถึงปลายทางแล้ว และข้อความที่ส่งนั้นไม่สามารถเปลี่ยนแปลงได้อีก โดยให้ผู้ใช้ส่งข้อมูลเข้าฐานข้อมูล และทั้งสองฝ่ายได้รับคำยืนยัน (ที่ตรวจสอบได้จากกระบวนการทาง cryptography) ว่าข้อมูลถูกรวมไว้ในฐานข้อมูลแล้ว

โดยหลักการแล้ว เราสามารถเก็บข้อมูลโดยยืนยันว่าฐานข้อมูลรวมทุกขุดข้อมูลเข้าไว้แล้วได้ไม่ยากนัก รูปแบบที่เข้าใจง่ายที่สุดคือการทำเป็น list เช่น ภาพของ Cloudflare แสดงการเก็บข้อมูล 8 ชุด ทุกครั้งที่ใส่ข้อมูล (วงกลมสีฟ้า) เข้าไปแล้ว ฐานข้อมูลจะนำไปแฮชคู่กับปลาย list เดิม เพื่อประกาศเป็น root hash แต่กระบวนการนี้ไม่มีประสิทธิภาพในการใช้งานจริง

ในกรณีที่เราต้องการยืนยันว่าข้อมูลของเราถูกรวมอยู่ในฐานข้อมูลหรือไม่ เราสามารถใช้ค่าแฮชก่อนหน้า ร่วมกับข้อมูลชุดที่เราต้องการตรวจสอบ และข้อมูลที่เข้ามายังฐานข้อมูลทั้งหมดหลังจากเรา เช่น หากต้องการตรวจข้อมูล d8 เราสามารถใช้แฮช g คำนวณ SHA256(g + d8) ได้เลย เมื่อคำนวณแล้วก็ทำมาเทียบค่ากับ root hash ที่ฐานข้อมูลประกาศไว้ หากตรงกันก็แสดงว่าข้อมูลยังอยู่ในรายการ แต่การทำเป็น list เช่นนี้หากต้องการตรวจสอบข้อมูลเก่าๆ เช่น d1 จะกลายเป็นว่าเราต้องใช้ข้อมูลทั้งฐานข้อมูลเพื่อคำนวณยืนยัน กลายเป็นสมการ SHA256(SHA256(SHA256(SHA256(SHA256(SHA256(SHA256(SHA256(d1) + d2) + d3) + d4) + d5) + d6) + d7) + d8) ซึ่งกินเวลานานมาก เฉพาะข้อมูล certification transparency ของ Google ปีล่าสุดก็มีข้อมูลมากกว่าสองพันล้านรายการแล้ว

Merkle Tree นั้นเป็นการเก็บข้อมูลแบบ tree โดยเก็บข้อมูลที่ leaf node (ปลายสุดของกราฟ) เท่านั้น โหนดภายใน (internal node) ทั้งหมดจะเก็บการเก็บค่าแฮชของข้อมูลชั้นก่อนหน้าไม่เกินสองตัวซ้าย/ขวา เท่านั้น ทำให้ตอนนี้แม้จะมีข้อมูลกว่าสองพันล้านรายการ ขนาด tree ก็มีเพียง 29-30 ชั้นเท่านั้น

ตัวอย่างการยืนยันว่า d8 ถูกรวมไว้ในฐานข้อมูล จะใช้ข้อมูล g, k, m และ d8 เองเท่านั้น เพื่อคำนวณหา root hash ซึ่งประกาศเอาไว้ สังเกตว่าข้อมูลที่จำเป็นสำหรับการ ตรวจสอบนั้นน้อยมากเมื่อเทียบกับจำนวนข้อมูลโดยรวม โดยปริมาณข้อมูลที่ใช้สำหรับการตรวจสอบข้อมูลแต่ละ record นั้นมี Big-O ที่ระดับ log(n) เนื่องจากเป็น tree

Certification Transparency หัวใจแห่งความปลอดภัยอินเทอร์เน็ต

ในช่วงเวลาสิบกว่าปีที่ผ่านมา อัตราการเข้ารหัสเว็บสูงขึ้นอย่างรวดเร็วจากความพยายามผลักดันของหลายฝ่าย โดยรากฐานของความปลอดภัยในการเข้ารหัสเหล่านี้คือหน่วยงานออกใบรับรองการเข้ารหัส (certification authority - CA) แม้ว่าหน่วยงานเหล่านี้โดยรวมจะมีมาตรฐานความปลอดภัยที่ค่อนข้างสูง แต่หากหน่วยงานเหล่านี้พลาดพลั้งไป คนร้ายก็จะสามารถปลอมตัวเป็นเว็บใดก็ได้ในอินเทอร์เน็ต

เมื่อปี 2011 CA ที่ชื่อว่า DigiNotar ถูกแฮก และคนร้ายสามารถออกใบรับรอง *.google.com สำเร็จ ส่งผลให้คนร้ายสามารถดักฟังการเชื่อมต่อของเหยื่อได้ทั้งหมด หากสามารถคั่นกลางการเชื่อมต่อได้

ความเสี่ยงเช่นนี้ทำให้ผู้ผลิตเบราว์เซอร์พบว่าไม่สามารถไว้ใจ CA ให้ทำงานโดยไม่มีการตรวจสอบได้อีกต่อไป กูเกิลซึ่งเป็นเหยื่อโดยตรงของการที่ CA ออกใบรับรองผิดพลาด ออกมาผลักดันให้ CA ต้องส่งรายงานการออกใบรับรองเสมอ เปิดให้มีการตรวจสอบตลอดเวลาในชื่อมาตรฐาน Certification Transparency Log (CT Log) หรือ RFC6962 ต่อมาอัพเดตเป็น RFC9162

CT Log บังคับให้ CA ต้องเปิดเผยรายการออกใบรับรองทั้งหมดต่อหน่วยงานเก็บ log อีกทีหนึ่ง โดยต้องส่ง log ไปยังหน่วยงานอย่างน้อยสองหน่วยงาน และมีหนึ่งหน่วยงานที่แยกความเป็นเจ้าของออกไป เช่น ใบรับรองของ Blognone.com ล่าสุดออกใบรับรองโดย Google และส่งข้อมูลไปยัง Google และ Sectigo ปัจจุบันบริษัทออกใบรับรองมักตั้งเซิร์ฟเวอร์ CT Log ไปพร้อมกัน แม้แต่ Let's Encrypt ที่ให้บริการฟรีก็มี CT Log ของตัวเอง

Audit Path ของใบรับรอง Blognone.com หมายเลข enty 2328098657 บน CT log Xenon2024 ของกูเกิล

หลังจากส่ง log ไปยัง CT Log แล้ว บริษัทต่างๆ สามารถตั้งระบบตรวจสอบมามอนิเตอร์การออกใบรับรองของ CA ทั่วโลกได้ บริการตรวจสอบใบรับรองสามารถช่วยแจ้งเตือนหากมีการออกใบรับรองผิดพลาด

การบังคับให้ CA ส่งข้อมูลไปยัง CT Log นั้นอาศัยกระบวนการที่ CT Log จะต้องออก "ใบเสร็จ" ว่าใบรับรองนี้ได้ถูกส่งเข้า CT Log แล้ว เรียกว่าข้อมูล Signed Certificate Timestamp (SCT) เบราว์เซอร์จะตรวจสอบว่าใบรับรองที่ส่งมายังเบราว์เซอร์นั้นแนบ SCT มาด้วยหรือไม่ หากไม่แนบมาเบราว์เซอร์ก็จะไม่ยอมรับเสมอ

ตัว CT Log เองถูกมอนิเตอร์การทำงานด้วยแนวทางการใช้ Merkle Tree โดยผู้ตรวจสอบการทำงานของ CT Log จะสามารถตรวจสอบได้เสมอว่ามีการรวมใบรับรองเข้าไว้ทั้งหมดหรือไม่ หรือมีการแก้ไขส่วนใดส่วนหนึ่งของฐานข้อมูลหรือไม่ โดยมี API /ct/v2/get-sth-consistency สำหรับการคืนค่าที่จำเป็นสำหรับการตรวจสอบ root node ในอดีตและปัจจุบันว่าสืบย้อนกลับได้ว่าไม่มีการแก้ไขระหว่างทาง และผู้ตรวจสอบการทำงานสามารถเข้าไปขอข้อมูลมารันกระบวนการตรวจสอบตามมาตรฐาน RFC9162 ได้เอง

กูเกิลเปิดซอฟต์แวร์ CT Log เป็นโอเพนซอร์สในชื่อ Trillian โดยฐานข้อมูลด้านล่างใช้ MySQL/MariaDB ซึ่งทาง Let's Encrypt ก็นำไปรันเป็นบริการ CT Log ของตัวเอง

CT Log น่าจะเป็น Merkel Tree ที่ใหญ่ที่สุดตัวหนึ่ง เมื่อปี 2022 เฉพาะ Let's Encrypt รายเดียวรับข้อมูลสูงกว่าเตือนละ 400GB โดย log เหล่านี้ต้องบันทึกการออกใบรับรองทุกใบในโลก

ฐานข้อมูลที่ลบไม่ได้ ไม่มีประโยชน์ถ้าไม่มีคนตรวจ

เวลาที่เราพูดว่าเรามี "ฐานข้อมูลที่ลบไม่ได้" นั้นแท้จริงแล้ว ไม่เคยมีข้อมูลใดที่ลบไม่ได้จริงๆ เจ้าของเซิร์ฟเวอร์สามารถลบข้อมูลออกจากดิสก์ของตัวเองได้เสมอ แม้จะใช้ Merkle Tree เจ้าของฐานข้อมูลก็สามารถลบข้อมูลออกบางส่วนแล้วสร้างขึ้นใหม่ได้ แต่กระบวนการ Merkle Tree นั้นเปิดให้มีการตรวจสอบการลบได้ตลอดเวลา การลบข้อมูลออกจะทำให้บริษัทจำนวนมากที่ตั้งระบบมอนิเตอร์จะมองเห็นได้ทันทีว่ามีการแก้ไขข้อมูล

ข้อจำกัดว่าทุกคนสามารถแก้ไขข้อมูลในระบบขของตัวเองได้นี้ แม้แต่ Blockchain รายสำคัญอย่าง Ethereum ก็เคยตัดสินใจลบข้อมูลการแฮก The DAO ออกจากระบบ ฐานข้อมูลเดิมนั้นแยกสายออกเป็น Ethereum Classic ทุกวันนี้ ขณะที่ชุมชน Ethereum เดิมนั้นเดินหน้ายอมรับการแก้ไข (ที่มองเห็นและรู้ตัว) พร้อมๆ กัน

กระบวนการสร้างฐานข้อมูลที่ป้องกันการแก้ไขเช่นนี้ จึงมีคำถามสำคัญว่าระบบจะเปิดให้ใครเข้าถึงและตรวจสอบข้อมูลบ้าง ในกรณีของ Blockchain ทั้งหลายและ CT Log ระบบเหล่านี้เปิดให้สาธารณะเข้าตรวจสอบ เช่น CT Log มี REST API และสามารถยิงขอข้อมูลได้โดยมักไม่ต้องยืนยันตัวตน ขณะที่ Blockchain ต่างๆ มักดาวน์โหลดฐานข้อมูลทั้งก้อนมาดูได้

การที่องค์กรสักแห่งจะทำ "ฐานข้อมูลที่ลบไม่ได้" หรือติดตั้ง Blockchain รันอยู่ในองค์กรของตัวเอง โดยไม่มีการตรวจสอบจากคนภายนอกก็จะเป็นคำถามว่ามีอะไรบังคับไม่ให้องค์กรเหล่านั้นสร้างฐานข้อมูลขึ้นใหม่เพื่อลบข้อมูลเดิมทิ้งไป เพราะอย่างไรเสียก็ไม่มีใครมองเห็น

ภาพจาก Cloudflare Blog