Smart Contract Security Concisely

บทความ Smart Contract Security Concisely ผู้เขียนจะรวบรวมความเห็น คำแนะนำและแนวทางการทำให้ Smart Contract มีความมั่นคงปลอดภัยต่อการนำไปใช้งาน โดยจะมีการ update ไปเรื่อย ๆ และจะขยายความอธิบายรายละเอียดหากเป็นหัวข้อที่ผู้เขียนสนใจหรือผู้อ่านอยากรู้

SCSC#1 Smart Contract คือรูปแบบของการนิยาม agreement ในรูปแบบของ Computing + Mathematical language ถ้ามองในรูปแบบที่เป็นรูปธรรมก็คือ สัญญา (Traditional Contract)ตามกฎหมายจะถูกระบุรายละเอียดในรูปแบบภาษากฎหมายที่มนุษย์ใช้อ้างอิงได้ และถูกตีความ (Interpretation) ตามที่นักกฎหมายแต่ละคนพยายามตีความ ส่วน Smart contract ถูกระบุรายละเอียดในรูปแบบของ Code ที่ถูกตีความด้วยคอมพิวเตอร์

SCSC#2 Nick Szabo เป็น cryptographer และ programmer ไปเรียนต่อด้านกฎหมาย จากนั้นต่อยอดและคิด idea เรื่อง Smart contract มาตั้งแต่ปี 1996 แต่วันนั้น Blockchain technology ยังไม่มี

SCSC#3 Smart contract ถูกบรรยายด้วย computer language การทำงานของมันจะถูกตีความเหมือน ๆ กันบนเครื่องคอมพิวเตอร์ที่จะ run Smart contract นั้น ๆ

SCSC#4 Traditional contract อาศัย trusted authority ในการตีความความถูกต้อง ซึ่งแน่นอนว่าความลำเอียงและความอยุติธรรมย่อมเกิดขึ้นได้ ส่วน Smart Contract อาศัย Blockchain technology ในการทำงาน ถูกหรือผิดเป็นไปตาม Logic ของ code ที่เขียนขึ้น

SCSC#5 ในแวดวง Blockchain จะมีคำพูดที่ว่า "in code we trust", "in maths we trust", และ "in crypto we trust" นั่นแสดงให้เห็นว่า trust ไม่ได้ถูกกำจัดออกจาก Blockchain Technology เพียงแต่ trust ถูก shift จาก central authority/intermediary หรือคนกลางไปยัง technology แทน ลองอ่านเพิ่มเติมจากบทความ Trust in Human or Trust in Technology

SCSC#6 ถ้าทำการ deploy Smart contract ไปแล้วมี bug หรือมีปัญหาด้าน security ไม่มีใครสามารถแก้ไขหรือเปลี่ยนแปลง Smart contract นั้นได้ owner และผู้พัฒนาจะต้อง take action ในการจัดการปัญหาที่ตามมาตามความสามารถที่มี (due diligence) ได้เท่านั้น อย่าลืมว่า Smart contract คือ agreement ที่ set up แล้ว ถ้ามันมีปัญหา ยังไงก็ตามคุณก็ต้อง agree และ respect ที่จะทำตามที่ Smart contract ระบุเอาไว้

SCSC#7 Use case ของ Smart contract ที่เห็นได้บ่อยในปัจจุบันจะพบในกรณี

1. Programmable money รับ-ส่ง เงิน crypto หรือ token ตาม condition ที่ set เอาไว้
2. Fundraising หรือทำ ICO เพื่อจะได้ขาย tokens และนำเงินกระดาษ (fiat money) ไปใช้ในการประกอบกิจการของบริษัทที่กำลังเปิด service ใหม่
3. Decentralised Autonomous Organisations (DAOs) คือบริษัทหรือองค์กรที่บริหาร จัดการและขับเคลื่อนด้วย set ของ Smart contracts แทนที่กลุ่มคนที่ตัดสินใจในรูปแบบบริษัททั่ว ๆ ไป เป็น use case ที่ผู้เขียนคิดว่าซับซ้อนและยังไม่คิดว่า จะตัดคนออกจากการมีอิทธิพลต่อการตัดสินใจได้ 100%

SCSC#8 Blockchain technology เป็น emerging techology (คือเทคโนโลยีอุบัติใหม่ ประมาณ 10 ปี ในขณะที่ Internet เกิดขึ้นประมาณ 50 ปีแล้ว) เวลามองเรื่อง security ต้องมองเป็น layer-approach แม้แต่ Vitalik ยังกล่าวว่า "Progress in smart contract safety is necessarily going to be layered, incremental, and necessarily dependent href="https://blog.ethereum.org/2016/06/19/thinking-smart-contract-security/" rel="noopener nofollow">https://blog.ethereum.org/2016/06/19/thinking-smart-contract-security/

SCSC#9 ถ้าเอา Blockchain technology มาฉีกเป็นชั้น ๆ จะพบว่า
— — — — — — — — — -
Data — จะเก็บหรือรับ-ส่งอะไร และจะ secure อะไรคือคำถามสำคัญสำหรับ layer นี้
— — — — — — — — — -
Application — ยังใช้ concept ด้าน Application Security มาใช้ได้
— — — — — — — — — -
Smart Contract — ส่วนใหญ่ปัญหาด้าน security เกิดขึ้นที่ layer นี้
— — — — — — — — — -
Compute หรือ Blockchain — มีหลาย platform แล้วแต่เลือก ถ้าเทียบกับ layer Smart contract แล้ว security ของ layer นี้ ดีกว่าเยอะ ลองไปดูรายการช่องโหว่ของ code ตระกูล Bitcoin Core ก็จะพบว่าไม่เท่าไร — https://www.cvedetails.com/vulnerability-list/vendor%5Fid-12094/Bitcoin.html
— — — — — — — — — -
Consensus — layer ที่ active ในหมู่ mathematician, cryptographer และ computer scientist
โดยส่วนใหญ่ถ้าเราไม่คิดอะไรใหม่ขึ้นมาเอง แต่ใช้สิ่งที่ถูก prove ไว้แล้วจะเป็น practice ที่ดีที่สุด
— — — — — — — — — -
Infrastructure — network และ system ตาม traditional infrastructure
— — — — — — — — — -

SCSC#10 Blockchain technology การันตีเรื่อง Integrity และ Availability แต่เรื่อง Confidentiality และ Privacy เป็นความรับผิดชอบของคนใช้และคนที่พัฒนาระบบ

SCSC#11 หากมี capability ในการสร้าง chain ขึ้นมาใช้งานเองยังพอรับได้ แต่หากสร้าง cryptography algorithms ขึ้นมาใหม่เป็นเรื่องที่ควรหลีกเลี่ยง

SCSC#12 Solidity เป็นภาษาที่จะพัฒนาไปอีกเรื่อย ๆ feature สำหรับนักพัฒนาก็จะเพิ่มขึ้นเรื่อย ๆ แต่เรื่อง security นั้น feature ยังไม่เท่าไร นักพัฒนาต้องควบคุมการทำงานของ code ของตัวเองให้ดี อย่าลืมว่ายิ่งภาษามันมี feature ที่ rich มากขึ้น แต่ security ไม่ได้ไปด้วยกัน ช่องโหว่ก็มักจะเกิดขึ้นตามมา

SCSC#13 ตัวอย่างที่ผู้เขียนรู้สึกขัดใจเช่น private attribute ถึงแม้ delcare ว่า private แต่เราก็สามารถ access ได้ผ่าน function ของ platform นั้น ๆ ที่ provide ให้ใช้ได้เช่น web3.eth.getStorageAt

SCSC#14 ก่อนจะพัฒนาระบบขึ้นมาคิดก่อนว่าจะ centralised หรือ decentralised มันไม่มีความจำเป็นที่จะต้องใช้ Blockchain technology หากเราสามารถสร้างมันขึ้นมาโดยใช้ระบบแบบปกติที่เราคุ้นเคยอยู่ได้

SCSC#15 เวลาจะใช้ Smart contract หรือบริการที่ควบคุมด้วย Smart contract ลองพิจารณาด้วยว่า owner มีสิทธิ์พิเศษในการทำกิจกรรมแปลก ๆ หรือไม่ เช่นถ้ามอง use case ของ token Smart contract เราต้องดูว่า owner ทำเรื่อง transfer, approve การ transfer, การ minting หรือ burning ที่ไม่ควรจะทำได้หรือไม่

SCSC#16 ใน Cryptocurrency Ecosystem ประกอบด้วย end user, ระบบ Exchange ที่มี hot/cold storage และ Crypto components ที่มี node, wallets, smart contract ตามแต่ละ Cryptocurrency หรือ platform

SCSC#17 Threats actor และ attack surface บน Cryptocurrency Ecosystem ก็จะมีเรื่องของ Fraud, Malware, Attackers, Network attack และการโจมตีไปยังผู้ใช้งานใน ecosystem นี้เช่น social engineering

SCSC#18 Smart contract code ถูก deploy อยู่บน blockchain platform ที่ทุกคนสามารถเข้าถึงได้ก็จริง แต่ไม่ใช่ทุก ๆ Smart contract ที่เราจะมี source code ดังนั้นการทำ manual code review จะทำได้ยากเพราะเหลือแต่ bytecode เท่านั้น ต้องใช้วิธีการอื่นช่วย

SCSC#19 วิธีการทำ Smart Contract Audit มีหลายเทคนิคและวิธีการเช่น formal verification, symbolic execution, fuzzing, control-flow analysis, debugging และอื่น ๆ ซึ่ง tools ตรวจสอบได้ไม่ครบ ต้องใช้คนด้วย(ถ้ามีโอกาสผู้เขียนจะมาเล่าให้ทุกท่านได้ทราบภายหลัง)

SCSC#20 Category ของช่องโหว่บน Smart contract สามารถดูภาพรวมจาก Decentralized Application Security Project (DASP) ของ NCC Group หากอยากดูรูปแบบคล้าย ๆ CWE ให้ดูที่ SWC Registry

SCSC#21 การพัฒนา software อย่าง secure มี checklist และ guideline ให้อ้างอิงเยอะแล้ว แต่ถ้าต้องการ guideline สำหรับการพัฒนา Smart contract ให้ secure ให้ลองดู Parity’s Checklist for Secure Smart Contract Development ซึ่ง founder ของ Parity ก็คือ Dr Gavin Wood ที่เขียน Ethereum Yellow Paper

ยังมีอีกมากที่อยากจะเอามาแชร์ให้ผู้อ่านทุกท่านได้ติดตาม แล้วจะกลับมา Update บทความนี้เรื่อย ๆ นะครับ