มาลองทดสอบเขียน Application เล่นเพื่อใช้งานบน NDID กัน (ตอน 1: NDID คืออะไร)
กลับมาเขียน blog หลังจากที่ไม่ได้เขียนมานาน อันที่จริงตอนแรกตั้งใจว่าจะเขียน blog เรื่องการทดลอง implement application เชื่อมต่อกับ NDID เพื่อเป็นการศึกษา ASP.NET Core, Vue.js และ NDID ไปในตัว แต่พอเอาไปให้คนใกล้ตัวดู ก็ได้คำถามแรกมาว่า NDID คืออะไร? ก็เลยเป็นที่มาของ blog นี้เพื่ออธิบายภาพรวมคร่าวๆ
หมายเหตุ blog นี้เขียนในมุมมองของผม ที่เป็น developer ที่สนใจเรื่องแนวๆนี้เป็นการส่วนตัว และสิ่งที่เขียนนั้น มาจากความเข้าใจส่วนตัวจากการอ่าน whitepaper, เว็บ NDID, ฟังมา อีกที ดังนั้นถ้ามีจุดไหนที่ข้อมูลผิดพลาดก็ขออภัยด้วยนะครับ (และถ้า comment บอกจุดที่ผิดด้วยจะดีมากครับ :P)
NDID คืออะไร ?
NDID หรือชื่อเต็มคือ National Digital ID (หรือบางที่เรียกว่า e-KYC) ถ้าเอาสั้นๆก็น่าจะประมาณว่าเป็น project ที่จะใช้เป็นโครงสร้างพื้นฐานของประเทศ เพื่อใช้ในการยืนยันตัวตนและเชื่อมต่อหน่วยงาน/องค์กรต่างๆเข้าด้วยกัน
ทำไมถึงน่าสนใจ
ย่อหน้านี้จะเป็นการสารถยายถึงเรื่องความสนใจส่วนตัว ไม่จำเป็นต้องอ่านก็ได้นะ 555 เรื่องมีอยู่ว่าก่อนหน้านี้ ผมได้มีโอกาสทำ prototype project ด้าน electronic document แล้วเกิด paranoid ขึ้นเล็กน้อย เพราะเริ่มรู้สึกไม่เชื่อในการที่เราทำสำเนาแล้วเซ็นชื่อแบบที่ใช้อยู่ในปัจจุบัน เพราะว่าเราไม่สามารถพิสูจน์ได้เลยว่าไอ้ลายเซ็นที่เซ็นมานั้น มันมาจากตัวจริงหรือไม่ (และประเทศไทยก็ไม่ใช้ตราประทับฮังโกะแบบญี่ปุ่นซะด้วยสิ) ครั้นจะให้ไปใช้ digital signature ก็ประสบปัญหาหลักๆ 2 ประการ คือ ไม่รู้จะให้ใครมาเป็น CA สำหรับออก certificate ให้ใช้ในแต่ละองค์กร และเป็นการเพิ่มภาระให้กับผู้ใช้งานที่ต้องมาศึกษาทำความเข้าใจเรื่อง digital signature, PKI รวมไปถึงการขอหรือเก็บรักษา private key (แต่สมัยนี้ประเด็นนี้อาจจะพอมองข้ามได้ เพราะเริ่มมีกลุ่มผู้ใช้งานที่เล่น crypto currencies แล้วดูแลรักษา private key ของตนเองอยู่) นอกจากนี้ยังมีประเด็นอื่นๆอีกนิดหน่อยเช่น ไม่มีการยืนยันเวลาที่ทำธุรกรรมของเอกสารนั้น จึงคิดว่าเราควรจะมีระบบยืนยันตัวตนที่ใช้ได้ในหลายๆองค์กร ไม่ใช่แบบที่ใช้ได้แค่กับองค์กรใดองค์กรหนึ่งเท่านั้น จึงพบว่า project นี้มีความน่าสนใจ และน่าจะเป็นกรณีศึกษาที่ดีในการออกแบบระบบที่เกี่ยวข้องกับ blockchain ครับอีกประเด็นคือ project นี้เป็น open source นั่นหมายความว่าเราสามารถเข้าไปดูศึกษา source code ได้ด้วย โดยเบื้องต้นสามารถเข้าไปดูข้อมูลเพิ่มเติมได้ที่ https://ndidplatform.github.io/ ครับ
มีไปทำไม ทำแล้วได้อะไร?
ในมุมของผู้ใช้งานคือ สามารถทำธุรกรรมต่างๆผ่านระบบ online ได้ มีความสะดวกรวดเร็ว เพราะลดเวลาในการประสานงานในแต่ละองค์กร ลดงานเอกสารซำ้ซ้อน และ(น่าจะ)มีความปลอดภัยมากขึ้น เพราะโอกาสที่จะโดนการปลอมแปลงเอกสารน้อยลง และมีการยืนยัน digital signature ในการทำทุกธุรกรรม
ในมุมของผู้ให้บริการคือ สามารถให้บริการธุรกรรมผ่านช่องทาง online ได้ ผ่านทางผู้ให้บริการยืนยันตัวตน (หรือ IDP ซึ่งจะมีพูดถึงในหัวข้อถัดไป) ได้รับข้อมูลจากแหล่งข้อมูลโดยตรง ทำให้ลดโอกาสที่จะโดนการปลอมแปลงเอกสารได้ (ยกเว้นแต่หน่วยงานนั้นโดน hack 555)
และในมุมของระดับประเทศคือ มี infrastructure พื้นฐานในการยืนยันตัวตนเพื่อต่อยอดในการทำระบบอื่นๆต่อไป ซึ่งน่าจะเป็นประโยชน์ต่อผู้ที่ประกอบธุรกิจต่างๆ ทั้ง SME, corporate และ startup
หลักการทำงานเบื้องต้น
ก่อนอื่นเรื่องที่ต้องเข้าใจก่อนเป็นอย่างแรกคือ ระบบนี้ไม่ได้เป็นการนำข้อมูลผู้ใช้งานไปเก็บไว้บน blockchain และไม่ได้เกี่ยวข้องกับ crypto currencies โดยตรง (คือพวก token ต่างๆ แต่อาจจะการนำมาใช้ในระบบ เพื่อใช้เป็นค่าธรรมเนียม และกันการ ddos ก็ได้นะ) แบบที่หลายๆคนที่ผมเคยคุยด้วยเข้าใจ แต่จะเป็นการนำเทคโนโลยี 2 อย่างคือ blockchain และ message queue มาเชื่อมโยงผู้ที่เกี่ยวข้องทั้ง 3 role เข้าด้วยกัน ซึ่งก็คือ
- RP ( Relying Party) เป็นกลุ่มผู้ให้บริการในการทำธุรกรรมต่างๆ เช่น ธนาคารให้บริการเปิดบัญชี, กู้เงิน, ขอบัตรเครดิต หรือ ISP ให้บริการ internet เป็นต้น
- IdP ( Identity Provider) เป็นกลุ่มผู้ให้บริการยืนยันตัวตน โดยมีข้อมูลของผู้ใช้งานคนนั้นอยู่ เช่น ธนาคาร
- AS (Authoritative Source) คือกลุ่มผู้ให้บริการข้อมูลของลูกค้านั้นๆ เช่น ข้อมูลเครดิตแห่งชาติ, ข้อมูล statement การเงิน, ข้อมูลการตรวจสุขภาพ หรือแม้กระทั่งข้อมูลหนี้กยศ (ฮา)
จากนิยามดังกล่าว เราจะพบว่าใน 1 หน่วยงาน สามารถเป็นได้หลาย role ในเวลาเดียวกันได้ เช่น ธนาคารเป็น RP ในการเปิดบัญชีใหม่, เป็น IdP ในการให้บริการยืนยันตัวตน และเป็น AS ในการให้ข้อมูล bank statement ได้
“ ระบบนี้ไม่ได้เป็นการนำข้อมูลผู้ใช้งานไปเก็บไว้บน blockchain แต่จะเป็นการนำเทคโนโลยี 2 อย่างคือ blockchain และ message queue มาเชื่อมโยงผู้ที่เกี่ยวข้องทั้ง 3 role เข้าด้วยกัน ”
เพื่อให้เข้าใจง่าย ลองยกตัวอย่างเปรียบเทียบละกัน สมมติว่าเราต้องการเปิดบัญชี broker เพื่อไปเทรดหุ้น ปกติ process ก็น่าจะราวๆนี้ (process แต่ละที่อาจจะไม่เหมือนกัน ผมขอเลือกยกของ broker ที่ผมเคยไปเปิดละกันนะครับ)
- เข้าไปที่เว็บ broker กดสมัครและกรอกรายละเอียดต่างๆให้ครบ
- ระบบจะสร้างเอกสารใบสมัครขึ้นมา ให้ print ออกมาทั้งหมด และเซ็นชื่อให้ครบ
- สำเนาเอกสารอื่นๆ เช่น บัตรประชาชน, ทะเบียนบ้าน, หน้า book bank, bank statement พร้อมทั้งเซ็นสำเนาถูกต้อง
- นำเอกสารทั้งหมด ส่งให้ broker ทางไปรษณีย์
- ไปยืนยันตัวตนที่ 7–11 โดยนำบัตรประชาชนไปเสียบกับเครื่องอ่าน และใช้เลขที่ใบสมัครเป็นตัวอ้างอิง (แต่แอบเห็นว่า broker บางเจ้า สามารถยืนยันผ่านตัว authenticator ของ broker ได้แล้ว)
- รอการ approve เอกสาร
โดยรวม process ทั้งหมดนี้ น่าจะใช้เวลาประมาณ 2 ถึง 3 วัน ในการดำเนินการทั้งหมด (อาจจะเร็วกว่า ถ้า broker นั้น รองรับการ upload เอกสารขึ้นระบบได้เลย) โดยเท่าที่ผมเข้าใจขั้นตอนการยืนยันตัวตนน่าจะมีเพื่อพิสูจน์ว่าเราเป็นเจ้าของเอกสารทั้งหมดที่ส่งมาจริง ไม่ใช่คนร้ายที่แอบขโมยเอกสารมาใช้ (อ่านรายละเอียดเพิ่มเติมได้ที่ บทความ นี้ครับ) ซึ่งหากมีระบบ NDID เข้ามา process น่าจะคล้ายๆกับรูปนี้ (แต่รูปนี้มีเฉพาะการ authentication ดังนั้น process อาจจะมีขั้นตอนมากกว่าในรูปนิดนึง)
- เข้าไปที่เว็บ broker กดสมัครและกรอกข้อมูล (broker เป็น RP)
- upload หรือถ่ายรูป สิ่งที่เกี่ยวข้อง เช่น บัตรประชาชน
- RP จะทำการส่งคำขอการยืนยันตัวตน และข้อมูลที่เกี่ยวข้องจาก AS ไปยัง IdP ที่เราเลือกไว้ ให้เราไปทำการยืนยันตัวตนผ่านช่องทางที่ IdP นั้นเตรียมไว้ให้ (เช่น mobile banking)
- AS (ซึ่งในที่นี้ อาจจะเป็นธนาคารซึ่งให้บริการข้อมูล bank statement) ได้รับการ confirm การยืนยันตัวตน และส่งข้อมูลไปให้ RP
- RP ได้รับข้อมูลที่เกี่ยวข้องทั้งหมด พร้อมสำหรับการพิจารณาการเปิดบัญชีต่อไป
จะเห็นได้ว่า process ทั้งหมด สามารถทำได้โดยผ่านช่องทาง online และลดเวลาในการทำ process ทั้งหมดลงได้ ข้อมูลทั้งหมดยังอยู่ที่ role ต่างๆเช่นเดิม และถูกแชร์ให้เท่าที่จำเป็น แต่มีช่องทางที่ทำให้การแลกเปลี่ยนข้อมูลรวดเร็วมากขึ้น ผู้ใช้งานก็ไม่จำเป็นต้องไปเข้าเว็บขอ bank statement เอง และที่สำคัญคือ ไม่ต้อง print เอกสารทั้งหมดมาเซ็นอีกด้วยนะ :D
Architecture
ระบบนี้จะใช้ blockchain ที่ชื่อว่า tendermint ในการสร้าง แต่ตัว tendermint นั้น เป็นเพียง consensus engine เท่านั้น โดยในส่วนของ logic หรือ smart contract นั้น ผู้ใช้งานจะต้องทำการ implement ABCI ที่มี interface ตาม spec ที่ tendermint กำหนด เพื่อให้ tendermint เรียกใช้อีกทีดังรูป
สำหรับ consensus ที่ tendermint ใช้จะกึ่งๆลูกผสมระหว่าง Practical Byzantine Fault Tolerance (PBFT) กับ proof of stake (PoS) อีกที โดยจะใช้การ vote ผ่าน validator node ที่จะต้องมีเสียง vote อย่างน้อย 2/3 เพื่อที่จะผ่านการ consensus ได้ (จุดนี้เป็นหลักของ PBFT) และแต่ละ validator node สามารถมี weight ในการ vote ที่ไม่เท่ากันได้ (ขึ้นอยู่กับเรากำหนด ซึ่งจุดนี้เป็น concept ของ PoS)
ส่วนถัดมาคือ message queue (ในที่นี้ใช้ ZMQ) เพื่อใช้ในการติดต่อกันระหว่าง node สาเหตุที่ต้องมี message queue แยกออกมา เพราะข้อมูลทุกอย่างไม่จำเป็นต้องส่งผ่าน blockchain ที่มีการ broadcast ให้กับทุก node (เราก็คงไม่อยากเก็บข้อมูลที่ไม่เกี่ยวข้องกับเราไว้เยอะๆ ถ้าไม่จำเป็น และในทางกลับกัน บางคนเขาก็คงไม่อยากให้ข้อมูลเขาไปเก็บใน node ของคนที่ไม่เกี่ยวข้องอะนะ) ใช้ในการทำ proof ต่างๆ และเป็นช่องทางในการส่งข้อมูล เช่น ข้อมูล pdf จาก AS ไปยัง RP
ส่วนสุดท้ายเป็น API อันนี้ก็ไม่มีอะไรมาก เป็นตัวคุมการส่งคำสั่งไปยัง tendermint และ message queue และเป็น interface สำหรับเชื่อมต่อกับ application อีกที
มาทดลองเล่นกันดีกว่า
ก่อนอื่น repo บน github ที่เกี่ยวข้องกับ project นี้หลักๆ จะมีอยู่ 3 repo คือ
- smart-contract เป็น repo ของ smart contract (ABCI ของ tendermint)
- API เป็น repo ของ API
- examples เป็นตัวอย่างการ implement application เพื่อเชื่อมต่อกับ NDID พัฒนาบน Node.js
โดยสิ่งที่เราต้องเตรียมคือ docker และ docker compose ที่ไม่ใช่ของ windows นะครับ (ของผมลองแล้วไม่ได้ ก็เลยไปใช้ digital ocean ที่เป็น server ไว้ทดลอง develop แทน) เนื่องจาก version ล่าสุด ณ ตอนที่เขียน blog นี้ (5 Aug 2018) มีส่วนที่ breaking change ดังนั้นจึงขอใช้ version ที่รองลงมาแทนนะครับ
ขั้นแรกเราจะเริ่มที่ตัว smart-contract ก่อน
ต่อมาก็เปิดส่วนของ API
และส่วนสุดท้ายคือ examples ที่เป็นหน้าเว็บสำหรับทดสอบ
เมื่อเปิดหมดแล้ว เราสามารถเล่นได้ ตาม port ดังนี้
- 8000, 8001 จะเป็นหน้า web app ของ idp1 และ idp2
- 9000 จะเป็นหน้า web app ของ rp1
- 8080, 8100, 8101, 8200, 8300 จะเป็น api ของ ndid, idp1, idp2, rp1 และ as1 ตามลำดับ
- 45000–45003 จะเป็น rpc port ของ tendermint (port ไว้ส่งคำสั่งเข้า blockchain) ของ ndid, idp, rp และ as ตามลำดับ
- 47000–47003 จะเป็น p2p por ของ tendermint ไว้คุยกันเอง เพื่อทำ consensus โดยปกติเราไม่น่ายุ่งเกี่ยวกับ port กลุ่มนี้
เราสามารถทดลองเล่นตาม scenario ตามเว็บนี้ได้เลย โดย flow แรกจะเป็นการสมัคร identity ใหม่บน idp1 แล้วลองสมัครใหม่อีกที่ idp2
เริ่มต้นเราก็เข้าไปที่ port 8000 เพื่อเข้าหน้าเว็บของ idp1 กรอกข้อมูลแล้วกด Create New Identity
ระบบจะเข้าสู่หน้าดู request ขอ authen ของ cid ที่ 1234567890123 (ซึ่งในสถานการณ์จริงก็คือ เลขบัตรประชาชน 1234567890123)
ไปลองอีกรอบที่ idp2 แต่คราวนี้จะกลายเป็นหน้าจอแบบนี้แทน เพราะต้องรอ consent จากผู้ใช้งานบน idp1 ก่อน
เมื่อกลับไปที่หน้า idp1 จะมีคำขอเพิ่ม identity โผล่ขึ้นมาดังรูป
เมื่อเรากด Accept ไป แล้วกลับไปที่หน้า idp2 จะพบว่าเราได้เพิ่ม identity เราบน idp2 เรียบร้อยแล้ว :D ซึ่งจากหน้าจอของ idp เราจะพบว่ามีอีกปุ่มคือ Add Accessor ซึ่งจุดนี้ผมก็ไม่ค่อยแน่ใจเหมือนกัน แต่เข้าใจว่าน่าจะเป็นการเพิ่มชุด key สำหรับ encrypt/sign สำหรับ identity นั้นอีกชุดครับ (เพราะใน 1 identity ของ idp อาจจะมี key หลายชุดตาม channel ที่ idp นั้นให้บริการได้ เช่น mobile application, face to face, ฯลฯ)
ทีนี้เราจะมาลองดูอีก flow นึง คือการที่เราไปหา rp แล้ว rp จะให้เราไป authen (ลืมขี้เกียจเขียนว่ายืนยันตัวตนล่ะ :3) และขอข้อมูลจาก as ด้วย เริ่มต้นให้เราไปหน้าเว็บของ rp1 แล้วลองกรอกรายละเอียดคร่าวๆ (สามารถลองเล่นที่ค่าอื่นๆได้) แล้วกดที่ “Request identity verification with data request”
ที่หน้า rp จะแสดงสถานะรอการ consent จาก idp ทั้ง 2 ที่ เพราะเราใส่ค่าว่าเราต้องการให้มีการ authen จาก 2 idp
สังเกตุว่าจะมีให้ขึ้น consent ทั้ง 2 idp (เพราะเราไม่ได้กำหนดเจาะจงว่าจะให้ไป authen ที่ idp ตัวไหนบ้าง) ให้ลองกด Accept ที่ทั้ง 2 idp
เมื่อกลับไปที่หน้า rp แล้ว จะพบว่าได้รับการ consent และได้รับ data จาก as แล้วดังรูป
สรุปส่งท้าย
จากหัวข้อที่แล้ว จะพบว่า application สามารถติดต่อสื่อสารกันได้อย่างรวดเร็ว เป็น infrastructure สำหรับการ authen และขอข้อมูลที่มีความน่าเชื่อถือ ทำให้การ hack ทำได้ยากขึ้น เช่น เพราะทุกกระบวนการต้องผ่านการขอ authen หรือ consent ที่ idp ก่อน เช่น มีคนเอาบัตรไปแอบสมัครบริการ rp เราก็จะรู้ทันทีเพราะต้องมีการ authen ที่ idp แต่ทั้งนี้เราจำเป็นจะต้องมี identity กับ idp สักเจ้าก่อน ดังนั้นถ้าใครกลัวโดนปลอมแปลง การไปสมัคร identity กับ idp ไว้ก่อนเพื่อกันคนมาแอบอ้างก็อาจจะเป็นสิ่งดี
โดยความเห็นส่วนตัวของผม มองว่า project นี้เป็น blockchain ที่เริ่มมีการ implement และมี stakeholder ที่เกี่ยวข้องจำนวนมาก จึงมีความน่าสนใจ น่าติดตาม เพราะทำให้เห็นถึงวิธีการออกแบบ และปัญหาที่อาจจะเกิดขึ้น แต่อย่างไรก็ตาม project นี้ก็ยังมีประเด็นอื่นๆให้คิดอยู่พอสมควร เช่น เรื่อง privacy ที่อาจจะทำให้รู้ว่าเราใช้ idp เจ้าไหนบ้าง ซึ่งประเด็นนี้ดูเหมือนผู้ใช้งานที่เป็นเจ้าของข้อมูลอาจจะไม่ค่อยเดือดร้อนเท่าไร แต่ในทางผู้ให้บริการก็ไม่น่าจะ happy เพราะมีโอกาสที่จะทำให้คู่แข่งรู้ถึงจำนวนผู้ใช้บริการของตนเองได้ ซึ่งประเด็นนี้ก็อาจจะต้องหาทางแก้ไขต่อไป (หรืออาจจะไม่แก้ แต่ร่วมมือกันแชร์ข้อมูลส่วนนี้ เพื่อต่อสู้กับบริษัทใหญ่ๆต่างประเทศที่เข้ามากินส่วนแบ่งในไทยแบบ Alibaba, Facebook, Amazon แบบนี้ก็น่าสนใจไปอีกแบบนะ :P) นอกจากนี้ก็ยังมีประเด็นอื่นๆอีก เช่น การ maintain version ของ software ในแต่ละ node, ความพร้อมในด้านไอทีของแต่ละผู้ให้บริการ, ความใหม่ของ technology, ความพร้อมในด้านการ support ปัญหาที่อาจจะเกิดขึ้นขององค์กร NDID และอื่นๆ หลายๆอย่างก็เป็นเพราะของไทยทำเป็นที่แรก ดังนั้นอาจจะยังไม่มี case study ตรงๆสำหรับรับมือในสถานการณ์ที่อาจจะเกิดขึ้น ซึ่งจุดนี้อาจจะเป็นข้อที่ทำให้หลายคนกังวล (รวมถึงผมด้วย) แต่ยังไงความอยากรู้อยากเห็นระบบนี้ได้ถูกใช้งานนั้นมีมากกว่า 555 สุดท้ายก็ขอเชียร์ให้กำลังใจแก่ทีมพัฒาและผู้ที่เกี่ยวข้อง สามารถผลักดันให้ project นี้สำเร็จละกันครับ
สำหรับ ตอนต่อไป เราจะมาลอง implement application ล้อเลียน examples กันแต่กากกว่า ด้วย ASP.Net Core ดูครับ
Refernece
- https://ndidplatform.github.io/
- ความเข้าใจผิดๆ กรณียกเลิกสำเนาบัตรประชาชน เสี่ยงต่อความปลอดภัย?
https://techsauce.co/tech-and-biz/dr-bhume-id-card-security/ - Identity Proofing vs Authentication
https://narudomr.blogspot.com/2018/02/identity-proofing-authentication.html - NDID Whitepaper
https://goo.gl/v4Cfpe
