Quantum Computing and Cryptography Breaking

สัปดาห์ที่ผ่านมาเรื่องการเอา Quantum Computing มาทำลาย Cryptographic Algorithm กลับมาเป็นประเด็นอีกครั้งหนึ่ง ฟังดูน่ากลัวนะครับ แต่ว่าน่ากลัวขนาดนั้นจริงหรือ

เอาประเด็นแรกก่อน Quantum Computing สามารถทำลาย Cryptographic Algorithm ในปัจจุบันได้ในระยะเวลาที่น้อยกว่าการใช้ CPU+GPU ที่เป็นเทคโนโลยีปัจจุบันได้จริงหรือไม่ คำตอบคือ จริงครับ เรื่องนี้ไม่ได้เป็นที่ต้องถกเถียงกัน ของใหม่ย่อมเร็วกว่าของเก่า ไม่งั้นมันจะพัฒนามาทำไม

คำถามที่ควรจะต้องถามต่อไปคือ แล้วเมื่อไรถึงจะมีการใช้ Quantum Computing มาทำลาย Cryptographic Algorithm ที่ใช้กันอยู่ในปัจจุบัน คำตอบคือไม่รู้ แต่พอจะทำนายถึงการนำมาใช้ได้ โดยมีปัจจัยให้พิจารณาดังนี้

ปัจจัยแรกคือการเปลี่ยนจากการใช้งาน Quantum Computing ที่เกี่ยวข้องกับงานที่มีมูลค่าสูง เช่นการวิจัยทางการแพทย์ การทหาร มาเป็นงานเชิงพาณิชย์ เรื่องนี้เป็นเรื่องพื้นฐานทางเศรษฐศาสตร์เกี่ยวกับ demands & supplies เมื่อค่าใช้จ่ายของการประมวลผลสูงและ supplies น้อย มันก็จะถูกใช้กับงานที่คุ้มค่าที่จะทำก่อน การทำลาย Cryptographic Algorithm ไม่ได้มีความคุ้มค่าในลำดับต้นๆ ที่จะใช้ Quantum Computing แต่อาจจะอยู่ในรายการลำดับกลางๆ เว้นเสียแต่ว่าเป็นงานทางการทหาร

ปัจจัยที่สองคือการก้าวผ่านการใช้งาน Quantum Computing จาก Time Sharing มาเป็นซื้อมาใช้ได้เองในระดับองค์กร ไปจนถึงซื้อใช้ได้เองในระดับบุคคล เราถึงจะค่อยๆ เห็นแนวโน้มการอยากที่จะทำลาย Cryptographic Algorithm มากขึ้นตามลำดับจนถึงขั้นที่สมควรต้องเป็นกังวลได้

ปัจจัยที่สามคือเมื่อค่าใช้จ่ายในการใช้งาน Quantum Computing อยู่ในระดับใกล้เคียงกับค่าใช้จ่ายในการขโมย Secret หรือ Cryptographic Key ของ Algorithm ปัจจุบัน ซึ่งถ้ามันถูกขนาดนั้นคงไม่มีใครไปขโมย Secret Key ให้เมื่อยตุ้ม

จากการประเมินของผมน่าจะใช้เวลาเป็นสิบปีที่ Quantum Computing จะถูกนำมาใช้ทำลาย Cryptographic Algorithm ในทางการทหาร อาจถึง 20 ปีในระดับที่แฮกเกอร์จะนำมาใช้อย่างแพร่หลาย

คำถามต่อไปคือแล้วจะมีใครนำมาใช้เพื่อทำลาย Cryptocurrency ไหมในอนาคตเมื่อถึงเวลาที่ราคาการใช้ Quantum Computing ลงมาถูกมากพอ เพราะคนที่ถือคงจะหวั่นใจอยู่ว่าราคาจะตก คำตอบคือ ต้องพิจารณาว่าข้อกังวลอยู่ที่ไหน คือถ้าเปลี่ยนแปลง Transaction ที่ทำไปแล้ว ประเด็นนี้ไม่ต้องกังวลเท่าไร เพราะ Cryptocurrency กระแสหลักต่างเป็น Distributed Ledger ถ้าอยากจะแก้ต้องไปตามแก้แต่ละสำเนาจนกระทั่งมากพอที่จะยึดทั้ง Chain ได้ (ที่เหลือก็จะกลายเป็น Forked Chain โดยปริยาย) ซึ่งเป็นไปได้ยากมากในทางปฏิบัติ

แล้วถ้าเป็นการปลอม Wallet ล่ะ กรณีนี้ก็มีทางเป็นไปได้อยู่บ้าง แต่เนื่องจากไม่ใช่ผู้เชี่ยวชาญโดยตรง จึงประเมินได้ไม่ชัดเสียทีเดียวว่าเป็นไปได้มากน้อยเพียงใด แต่ก็พอที่จะลดความเสี่ยงได้โดยการกระจายไปหลายๆ Wallet เมื่อถึงเวลานั้น

เขียนมาทั้งหมดนี้ ไม่รู้ว่าจะช่วยอะไรใครได้หรือเปล่า

ก็ผมไม่ใช่ Guru นี่นา

Pulse Secure บน Windows กับการให้ Script ทำงานหลังจากเชื่อมต่อสำเร็จ

บันทึกไว้เพื่อทำซ้ำในครั้งต่อไป และแบ่งปันเผื่อเป็นประโยชน์กับสาธารณะ

ผมถนัดนั่งทำงานกับเครื่องที่เป็น Linux มากกว่า Windows และโดยส่วนตัวไม่ค่อยชอบ Windows เท่าไรแม้จะออก WSL มาก็ตาม อย่างไรก็ตามผมก็เลี่ยง Windows ไม่ได้เพราะเครื่องที่ทำงานให้มาใช้ก็เป็น Windows 10

แม้ว่าจะให้เครื่องมาใช้ แต่ที่ทำงานก็อนุญาตให้ใช้เรื่อง Windows ที่ติดตั้ง Security Software ต่างๆ ผ่านมาตรฐานให้ใช้งานผ่าน Pulse Secure VPN ได้ โดยผมขอใช้ Hard Token ซึ่งจะสร้าง One Time Password มาให้เพื่อทำการเชื่อมต่อ ผมจึงได้สร้าง VM บน VirtualBox เพื่อลง Windows 10 ทำการติดตั้ง Security Software ตามมาตรฐานและลง Pulse Secure เพื่อเชื่อมต่อ VPN

แต่ผมไม่อยากทำงานบน Windows VM เพราะถ้าต้องประชุมเปิดกล้องบน Microsoft Teams จะต้องโอน USB Camera ไปให้ ในขณะที่ ผมมีประชุมกับภายนอก อย่าง Zoom, Google Meet หรือ WebEx ซึ่งไม่จำเป็นที่จะต้องทำผ่าน VPN ผมก็เลยใช้วิธีตั้ง Proxy แล้วทำ Port Forwarding จาก Linux Host ไปยัง Windows VM ตรงนี้ไปดูคู่มือ VirtualBox เอา ผมจะไม่อธิบาย

ปัญหาก็คือ Proxy ใน Windows VM จะต้อง Start หลังจากที่ VPN ทำการเชื่อมต่อสำเร็จเท่านั้น ตอนแรกพยายามทำด้วย Batch โดยสั่งให้ pulselaucher.exe ซึ่งเป็น command line ทำงานก่อน ตามด้วยเรียก Proxy ให้ทำงาน แต่ปรากฎว่า pulselaucher.exe เกิด Exit with Error ตลอดเพราะไม่รองรับการตรวจสอบ Policies ที่บริษัทตั้งไว้เหมือกับที่ทำผ่าน Pulse Secure UI

ก็เลยคิดว่ามีทางไหมที่จะใช้ Pulse Secure UI นั่นแหละแล้วเมื่อเชื่อมต่อได้แล้วถึงสั่งให้ Proxy ทำงาน ก็เลยไปดู Windows Event Log ว่ามี Event ไหนที่บอกได้ว่าได้เชื่อมต่อ VPN สมบูรณ์แล้วก็พบว่ามี IVE Event 312, 306 และ 305 ตามลำดับดังรูป

พอได้ Event มาก็ไปทำ Task Scheduler ให้ Trigger ในเงื่อนไขตามรูป

ส่วน Action ก็สั่ง "Start a program" แล้วก็ใส่ command และ arguments เพื่อให้ Proxy ทำงาน

ต่อไปทุกครั้งที่เชื่อมต่อสำเร็จ Proxy ก็จะทำงานอัตโนมัติ

หวังว่าจะเป็นประโยชน์ต่อผู้ที่ต้องการ Run Script หลังจาก Pulse Secure เชื่อมต่อสำเร็จ (ซึ่งไม่รู้ว่าจะมีหรือเปล่า) นะครับ

Low Code != Low Effort

หลังจากที่เห็น Clip พูดถึง Low Code ว่าช่วยทำให้เขียนโปรแกรมได้ง่ายขึ้น เร็วขึ้น ก็รู้สึกว่าทำไมมันช่างต่างจากที่ผมเคยสัมผัสและได้ยินจากปากคนที่เคยใช้มาเสียเหลือเกิน ผมก็เลยอยากจะเล่าให้ฟังแบบ "อาศัยความรู้สึก" เป็นหลัก ไม่ได้ให้ใครจะมาคล้อยตาม เพียงแต่กระตุกให้คิดสักนิดนึง

ในโลกของ Low Code มีวิธีตั้งต้นการพัฒนา App อยู่หลายวิธี แต่ส่วนใหญ่จะเริ่มด้วยสองวิธีนี้คือ เริ่มต้นด้วย User Interface ซึ่งตัวที่เริ่มต้นด้วยวิธีนี้ ได้แก่ Microsoft Power App เข้าใจว่าอีกหลายตัวก็เริ่มแบบนี้เหมือนกัน แต่เนื่องจากไม่ได้ผ่านมาในงานที่เคยทำจึงไม่ขอพูดถึง การพัฒนาในเริ่มต้นด้วย UI เป็นเรื่องที่ Front-End Developer ส่วนใหญ่เข้าใจได้ง่าย

อีกวิธีคือเริ่มต้นด้วย Data Model ซึ่งวิธีนี้เป็นวิธีที่ดีถ้ามีการออกแบบโครงการอย่างครบถ้วนก่อนลงมือ Implement ตัวอย่างผลิตภัณฑ์ที่ไปในแนวทางนี้ได้แก่ Mendix ซึ่ง Front-End Developer มักจะมีปัญหากับการพัฒนาในแนวทางนี้ แต่คนที่ทำงานกับข้อมูลมากๆ จะชอบ

คำถามก็คือความคาดหวังของคนส่วนใหญ่ที่อยากใช้ Low Code คืออะไร พัฒนาโปรแกรมได้เร็ว เขียนโปรแกรมน้อยลง ซึ่งความเห็นของผมคือ ขึ้นอยู่กับว่าคุณจะทำอะไร ซึ่งผมมีความเห็นตามนี้

Low Code Platform เหมาะกับ Application ประเภทไหน

ประเภทแรกคือ Stand Alone App ที่มีเพียง App กับ Database หรือ Data Object ไม่ได้มีการ Integrate กับภายนอก ทั้งหมดจบอยู่ใน App ซึ่ง Low Code Platform จะเหมาะกับ App แบบนี้มากที่สุด

ประเภทที่สองคือ App ที่มี Integration กับภายนอกผ่านตัว Low Code Platform เองที่เรียกว่า Connector ไม่ว่าจะเป็นของเจ้าของ Platform หรือ Third-Party Connectors ก็แล้วแต่ ซึ่งการเลือกใช้ Low Code กับงานประเภทนี้ ต้องคำนึงเสมอว่าในอนาคตนั้น App ของเราไม่ควรจะมีการ Integrate กับบริการที่ไม่มี Connector รองรับ

Low Code Platform ไม่เหมาะกับ Application ประเภทไหน

ผมเจองานสองแบบที่ไม่เหมาะกับ Low Code Platform เลย งานเหล่านี้ประเภทแรกได้แก่ งานที่อยากใช้ความสามารถของ Hardware เช่นอยากให้กล้องมือถือสแกน Bar-code ไม่ว่าจะเป็นมิติเดียวหรือสองมิติอย่าง QR Code ก็ตาม แบบนี้ต้องอาศัยการพลิกแพลงที่เยอะมากเพราะ Platform ส่วนใหญ่ไม่รองรับ

ประเภทที่สองคือมีการ Integration กับหลายระบบ แม้ว่าหลาย Platform จะรองรับ Integration กับ In-House Service ก็ตาม พอทำงานจริงๆ เจอท่าแปลกๆ อย่าง Asynchronous Callback หลาย Platform ก็ไปลำบาก เหมือนกัน (แต่ก็อีกงาน Development ทั่วไปคงเป็นแต่ Synchronous)

แล้วทำไม Low Code != Low Effort

ถ้าคุณทำงานในองค์กรขนาดเล็กที่ไม่ได้มี Integration เยอะแยะไปหมด ไม่มีความต้องการแปลกๆ ในการทำงาน Low Code อาจทำให้ Low Effort ในการได้สักแอปขึ้นมา แต่ถ้าคุณอยู่ในองค์กรใหญ่ Low Code Platform ทำให้ Effort ในการทำงานอาจจะไม่ได้ Low จริงเช่น

1. ถ้าคุณต้องทำการเชื่อมต่อกับระบบอื่นๆ มากมาย แต่ไม่ได้มี Connector มากับ Platform นั้นๆ คุณคงต้องพลิกแพลงในการทำงานมาก บางกรณีอาจจะมากกว่าการเขียนแอปแบบปกติ
2. บางทีคุณจะพบว่า Feature ที่คุณอยากได้ ไม่ได้อยู่ใน Low Code Platform ที่คุณเลือก แต่มีใน Platform อื่น คุณจะเลือกใช้อีก Platform หรือไม่ หรือทนใช้ของที่มีอยู่
3. ตามที่ผมเข้าใจ Low Code Platform ไม่ได้ทำงานข้ามค่ายได้ ไม่เหมือนกับการเลือกใช้ Framework ต่างๆ ในการพัฒนา Software ตามปกติ

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

ต้องขอย้ำว่าบทความนี้เป็นความเห็นส่วนตัวล้วนๆ ถ้าใครมีประสบการณ์แบบอื่นลองมาเล่าสู่กันฟัง

ตั้งค่า Citrix Workspace App บน Linux ให้ใช้งานกับ Citrix XenDesktop/XenApp ได้

ผมมีงานที่ต้องใช้ VPN ผ่าน Citrix XenApp Server มานานหลายปี โดยหลักๆ แล้ว Admin ของระบบได้ออกคู่มือการติดตั้ง Citrix Workspace หรือ ชื่อเดิมคือ Citrix Receiver สำหรับ Windows, iOS และ Android ออกมา แต่ไม่มี Linux นั่นทำให้ผมต้องหาทางเชื่อมต่อด้วย Linux เอง ซึ่งก็ไม่ได้ประสบปัญหาอะไรจนกระทั่ง Citrix Receiver v.13.x เกิดปัญหาเรื่อง TLS/ SSL Compatibility เป็นอย่างมาก จนผมต้องไปใช้ Citrix ใน Linux ที่วิ่งอยู่บน VirtualBox ซึ่งวันดีคืนดีพอทางฝั่ง Server Update Patch ก็ใช้ไม่ได้ขึ้นมาดื้อๆ จนถอดใจยอมใช้ผ่าน Citrix Workspace for Android ซึ่งไม่มีปัญหานี้ โดยซื้อ Tablet มาใช้ แต่ก็ทำงานลำบากเพราะจอเล็ก (8 นิ้ว)

กาลเวลาผ่านไปผมซื้อ Laptop ที่มี Spec ต่ำมาใช้งาน (AMD A6-9225 RAM 4 GB จอ 14 นิ้ว Full HD) ซึ่งจะลง Virtual Box ก็กระไรอยู่ จะลง Android x86 มาเป็น Dual Boot ก็กังวลเรื่อง Driver เลยกลับมาหาทางทำให้ Citrix Work Space for Linux ใช้งานได้บน Linux ที่ทำงานอยู่บน Hardware จริง ลองหลายทางแต่เอาที่สำเร็จ และติดตั้งไป 3 เครื่องในบ้านแล้ว โดยสรุปขั้นตอนดังนี้

Root Certificates ที่มากับ Citrix Workspace App for Linux

1. ติดตั้ง Citrix Workspace App for Linux ล่าสุด v.1912 ผมเลือกแบบ Debian Package (deb) ซึ่งไม่ว่าจะ เป็น Debain, RPM, หรือ Tarball Package ก็จะไปอยู่ที่ /opt/Citrix/ICAClient
2. เนื่องจากตัว App รู้จัก root certificates แค่ 8 ตัวตามรูปด้านบน ต้องหาว่ามี root certificates ที่สามารถจะมาเพิ่มได้ไหม ซึ่งต้องเป็น PEM format ผมแนะนำให้ไปเอาจาก Mozilla Folder ถ้าหากลง Firefox ไว้อยู่แล้ว ถ้าเป็นสาย Debian ก็อยู่ที่ /usr/share/ca-certificates/mozilla แม้ว่าจะ .crt แต่ก็เป็น PEM format
3. link file จาก Folder ดังกล่าวมาไว้ที่ /opt/Citrix/ICAClient/keystore/cacerts
4. สั่งคำสั่ง ctx_rehash เพื่อให้ App รู้จัก

ถ้าลง Firefox บนสาย Debian อยู่แล้วก็สั่งสองคำสั่งนี้

sudo ln -s /usr/share/ca-certificates/mozilla/* /opt/Citrix/ICAClient/keystore/cacerts

sudo /opt/Citrix/ICAClient/util/ctx_rehash

จากนั้นก็ลองเชื่อมต่อ Server เข้าไปใช้งาน

บันทึกไว้กันลืม 

ครบรอบ 1 ปี WannaCry ความตระหนักที่กำลังเลือนหายไปตามกาลเวลา

13 พฤษภาคม 2017 เป็นวันที่เกิดการระบาดของ WannCry Ransomware แม้ว่าบางรายงานบอกว่าเป็นวันที่ 12 แต่เนื่องจากประเทศไทยตื่นมารับรู้ในวันที่ 13 เพราะ Time Zone ที่เร็วกว่ายุโรปที่ได้รับรายงานการระบาดเป็นจุดแรก ผมขอใช้วันนี้ก็แล้วกัน

อันที่จริงมัลแวร์ลูกผสมไม่ได้เป็นเรื่องที่น่าแปลกใจนักสำหรับผู้เชี่ยวชาญด้าน Information Security จำได้ว่าตอนที่เดินทางขึ้นไปขอนแก่นเพื่อร่วมงานแต่งงานของเจ้าของบริษัททำ Penetration Testing ท่านหนึ่ง บรรดาผู้เชี่ยวชาญหลายคนที่นั่งรถไปคันเดียวกับผมก็ได้วิเคราะห์เรื่องมัลแวร์ต่างๆ และหนึ่งในการทำนายถึงมัลแวร์ที่จะเกิดขึ้นก็คือลูกผสมของ Ransomware กับ Worm เพียงแค่ปีเดียวสิ่งที่ทำนายก็เกิดขึ้น

สำหรับผม มันเป็นความทรงจำที่ออกจะแปลกประหลาดไม่น้อย เพราะเป็นช่วงที่บินไปยังบาหลีเพื่อร่วมสัมมนา Cyber Security Exchange for FSI ซึ่งผมบินไปก่อน 2 วัน (วันเสาร์) เพื่อพักผ่อน ปกติแล้วผมจะอ่าน News Feed ทุกเช้าและเริ่มสัมผัสได้ว่าการระบาดของ WannaCry น่าจะสาหัส จึงได้ส่งข้อความลงไปใน Line กลุ่มของหัวหน้าทีม IT ของธนาคารก่อนขึ้นเครื่องบิน พร้อมบอกวิธีเตรียมการคร่าวๆ เพื่อรับมือวันจันทร์ที่เปิดงาน จากข้อมูลเท่าที่มีอยู่ตอนนั้น พอลงเครื่องมาก็เริ่มมีการคุยกันต่อเนื่องใน Line ตั้งแต่ยังไม่ออกจาก ตม. จนนั่งรถไปถึงโรงแรม ขอเล่าเพื่อไม่เสียเวลาสรุปว่าทีม Infrastructure และ IT Service เตรียมการทุกอย่างพร้อมในวันอาทิตย์ เพื่อรอการเปิดทำงานวันจันทร์ เป็นการคุยงานไป เดินชายหาดไป ว่ายน้ำไป ประมาณนี้

นอกจากงานของธนาคารตัวเองแล้ว ก็ยังต้องมาช่วยเกลาและเรียบเรียงเอกสารเผยแพร่ในนาม Information Sharing Group (ISG ซึ่งต่อมาเป็น TB-CERT) ร่วมกับเพื่อนๆ ตัวแทนของธนาคารต่างๆ ด้วย และน่าจะเป็นเอกสารเผยแพร่ฉบับแรกๆ ของทีม

เป็นการพักผ่อนที่ประหลาดดี

ผมขอรวบรวมเรื่องที่ประสบพบเจอในระหว่างการระบาดทั้งบทเรียนที่ผมได้รับ ทั้งเรื่องดีและไม่ดี รวมๆ กันไปนะครับ

1. ระหว่างช่วงชุลมุนและยังได้ข้อมูลไม่ครบ แต่จำเป็นต้องสั่งการ ผมเองเลือกที่สั่งเกินความจำเป็นไปนิด ในกรณีนี้ตอนที่ยังไม่มีข้อมูลที่ชัดเจนว่าโจมตีผ่านช่องโหว่ Ethernal Blue เท่านั้น (SMBv1) ด้วยความที่เป็น Ransomware ผมเลยสั่งให้ Monitor ช่องทาง Mail และ Web Site ไปด้วย อย่างไรก็ตามหลังจากมานั่งคิดว่าถ้าย้อนกลับไปสั่งการใหม่ จะเป็นแบบเดิมไหม คำตอบก็ยังเป็นแบบเดิมอยู่ดี 
2. หน่วยงาน Regulator ติดตามอย่างกับโดน Compromised ไปแล้ว เอิ่มสถานการณ์ Malware Outbreak จัดการคนละแบบกับการโดน Targeted Attacks นะขอรับ
3. บรรดากูรูเกิดขึ้นมาอย่างกับดอกเห็ด มั่วซะเป็นส่วนใหญ่ แถมตอน Spectre/Meltdown ก็ด้วย มีอะไรเกิดอีก ก็เดาได้เลยว่ามีกูรูเกิดขึ้นมาใหม่อย่างแน่นอน มีบางคนมาบอกผมว่ากูรูบางคนพูดออกทีวีอย่างดิบดีว่าทำอย่างนี้ป้องกันได้แน่นอน แต่ว่าเอกสาร WannaCry Analysis ในมือผมบอกว่า ทำอย่างที่กูรูบอกไม่มีประโยชน์อันใด ขอร้องกูรูอ่านเยอะๆ ดีกว่านะครับ
4. หน่วยงานรัฐออก Infographics ไม่ได้ฟังคำท้วงติงของผู้เชี่ยวชาญด้าน Information Security ที่มีข้อมูลอ้างอิงในมือว่าควรสื่อสารอย่างไร ผมก็ไม่แน่ใจว่าการสอบทานเป็นอย่างไร หวังว่าคงไม่ฟังคนที่ไม่มีข้อมูลที่แท้จริงในมือแล้วสื่อสารออกไปผิดๆ หรือตอนนั้นเพียงคิดว่านี่เป็น Ransomware ตัวหนึ่ง
5. อาจารย์มหาวิทยาลัยแห่งหนึ่งเขียนโปรแกรมเพื่อหลอก WannaCry ว่าเครื่องฉันติดแกแล้ว ไม่ต้อง Load ตัวเองขึ้นมาอีก มีการออกข่าวใหญ่โต สุดท้ายได้ประกาศเป็นผู้ทำงานด้าน Security ยอดเยี่ยมประจำปีที่แล้ว ในขณะที่ผู้เชี่ยวชาญ Information Security ทั่วโลกบอกว่า ลง Patch เถอะครับ ย้อนแย้งจริงๆ

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

ไว้นึกอะไรออกอีก จะมาใส่ไว้ก็แล้วกัน

Identity Proofing vs Authentication

Identity Proofing = การพิสูจน์อัตลักษณ์
Authentication = การพิสูจน์ตัวจริง (ศัพท์บัญญัติราชบัณฑิตยสถาน - เทคโนโลยีสารสนเทศ ๑๑ มี.ค. ๒๕๔๕)

เพื่อที่จะไม่เกิดความสับสนในคำแปลภาษาไทย ในบทความนี้จะขอใช้ทับศัพท์ภาษาอังกฤษ ทั้งคู่เป็นกระบวนการที่ไม่เหมือนกันแต่เป็นสองกระบวนการที่สำคัญในการทำ Digital Identity ซึ่งหลายครั้งในมีการใช้งานสองคำนี้อย่างสับสนดังนั้นจึงต้องอธิบายอย่างละเอียด ในสิ่งที่แตกต่างกัน

Identity Proofing

Identity Proofing เป็นกระบวนการที่พิสูจน์ว่าบุคคลคนนั้นเป็นคนเดียวกันกับบุคคลที่กล่าวอ้างหรือไม่ ในที่นี้จะกล่าวถึงการทำ Identity Matching แบบ one to one เท่านั้น ไม่รวมไปถึงการพิสูจน์อัตลักษณ์ว่าบุคคลนี้เป็นใครซึ่งเป็นการทำ Identity Matching แบบ one to many

กระบวนการนี้เป็นกระบวนการที่สำคัญมากในการสร้างข้อมูลตัวตนใน Digital Identity Platform นอกจากนั้นยังเป็นกระบวนการเดียวกันกับการทำ KYC (Know Your Customer) อย่างไรก็ตาม Identity Proofing ทำได้หลายแบบซึ่งแต่ละแบบมีความแม่นยำถูกต้องไม่เท่ากัน แต่หลักการก็คือเป็นการพิสูจน์ข้อมูลเฉพาะบุคคลที่ได้รับการยืนยันจากบุคคลที่สาม

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

อย่างไรก็ตามในการทำ Identity Proofing เราไม่สามารถให้บุคคลที่สามที่น่าเชื่อถือมายืนยันได้เสมอไป ในทางปฏิบัติเราจึงมักจะใช้เอกสารยืนยันที่น่าเชื่อถือจากบุคคลที่สามมากกว่าที่จะให้บุคคลที่สามเป็นผู้ยืนยันเช่นการใช้บัตรประชาชนแทนการขอคำยืนยันจากกรมการปกครอง การใช้บัตรข้าราชการแทนการขอคำยืนยันจากสํานักงานข้าราชการพลเรือน

แล้วความน่าเชื่อถือในการทำ Identity Proofing มีมากหรือน้อยขึ้นอยู่กับอะไร ประการแรกก็คือข้อมูลที่ใช้ในการพิสูจน์อัตลักษณ์ (Identity attributes) ยิ่งข้อมูลมีความเป็นเอกลักษณ์สูงและมีหลายประเภทมากเท่าใด ความน่าเชื่อถือในการพิสูจน์อัตลักษณ์ก็จะมีมากยิ่งขึ้น ยกตัวอย่างถ้าเป็นข้อมูลทางชีวภาพของบุคคลก็ย่อมมีความน่าเชื่อถือกว่าข้อมูลที่ถูกสร้างขึ้นเช่นที่อยู่ หมายเลขโทรศัพท์ ถิ่นที่เกิด บัตรประชาชน เป็นต้น

ประการที่สองก็คือกระบวนการพิสูจน์อัตลักษณ์ กระบวนการมีความสำคัญมากตั้งแต่วิธีการในการพิสูจน์ข้อมูลอัตลักษณ์ วิธีการที่แม่นยำสูง ดำเนินการได้ง่ายโดยไม่ต้องอาศัยความสามารถเฉพาะบุคคล และทุจริตยาก ย่อมน่าเชื่อถือกว่าวิธีที่ไม่ค่อยแม่นยำ ดำเนินการได้ยาก หรือทุจริตง่าย นอกจากนั้นความสม่ำเสมอของการใช้กระบวนการก็เป็นอีกหนึ่งในปัจจัยของความน่าเชื่อถือด้วย หากกระบวนการนั้นไม่มีการควบคุมหรือมีการดำเนินงานที่ย่อหย่อนในบางครั้งก็จะทำให้ความน่าเชื่อถือลดลง

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

แม้ว่าการทำ Identity Proofing จะมีความสำคัญในการทำธุรกรรมหลายอย่างแต่เราก็ไม่สามารถใช้กระบวนการนี้ทุกครั้งในการทำธุรกรรมต่างๆได้ เนื่องจากมีค่าใช้จ่ายสูง ใช้เวลานาน และไม่สามารถทำได้โดยไม่ต้องพบกัน ดังนั้นกระบวนการที่สองที่มาช่วยในการทำธุรกรรมก็คือ Authentication

Authentication

Authentication เป็นกระบวนการที่ใช้ในการตรวจสอบผู้มีสิทธิ์เข้าใช้บริการ ทำธุรกรรม หรือใช้ทรัพยากรที่บุคคลนั้นเป็นเจ้าของ แต่ไม่ได้บอกว่าผู้มีสิทธิ์นั้นเป็นบุคคลใดหากไม่ได้ทำ Identity Proofing มาก่อน ตัวอย่างเช่น หากเราใช้บริการของ Google ที่ต้องใช้ทรัพยากรแยกตามบุคคลเช่น Gmail, Drive หรือ Play Store เราต้องสมัคร Google Account ซึ่งจะมีวิธี Authentication พื้นฐานโดยใช้ Gmail Address กับ Password การสมัครนั้นเราไม่จำเป็นให้ข้อมูลส่วนบุคคลที่ถูกต้อง เพราะ Google ไม่ได้ทำ Identity Proofing ดังนั้น Google Account โดยทั่วไปแล้วจึงไม่สามารถระบุอัตลักษณ์ได้ และนี่คือสาเหตุที่ Authentication ไม่สามารถทำการแทน Identity Proofing ได้

อย่างไรก็ตามหากกระบวนการ Authentication สามารถเชื่อมโยงได้กับการทำ Identity Proofing จึงจะสามารถทำธุรกรรมแบบระบุตัวตนที่แท้จริงบนโลกได้เช่นหากบุคคลใดก็ตามเปิดบัญชีธนาคารและมีการทำ Identity Proofing หรือ KYC ที่ถูกต้อง แล้วเปิดบริการ Internet Banking การทำ Authentication บน Internet Banking จึงทำให้การทำธุรกรรมเช่น การโอนเงิน ก็สามารถระบุตัวตนได้

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

มีผู้นิยามเกี่ยวกับ Strong Authentication อยู่หลายหน่วยงาน สามารถอ่านได้จาก https://en.wikipedia.org/wiki/Strong_authentication แต่ผมขอจำแนกมิติของการตรวจสอบไว้ดังนี้

มิติแรกปัจจัยในการตรวจสอบ (Factor) ซึ่งตามตำราด้าน Information Security มี 3 ปัจจัยก็คือ สิ่งที่คุณรู้ (Something You Know) สิ่งที่คุณมี (Something You Have เช่นโทรศัพท์มือถือ Google Authenticator) และสิ่งที่คุณเป็น (Something You Are เช่น ลายนิ้วมือ ม่านตา หรือใบหน้า) ความแข็งแรงในการตรวจสอบก็คือ สิ่งที่คุณรู้ ด้อยกว่า สิ่งที่คุณมี และสิ่งที่คุณเป็นจะมีความแข็งแรงสูงสุด อย่างไรก็ตามการใช้สิ่งที่คุณเป็นในการตรวจสอบมีความเสี่ยงมากที่สุดหากมีการปลอมแปลงได้ เพราะเป็นกลุ่มเดียวที่คุณเปลี่ยนไม่ได้ ไม่ว่าจะเป็นลายนิ้วมือ (แม้จะเปลี่ยนนิ้วได้) ม่านตา หรือใบหน้า

มิติที่สองคือจำนวนของปัจจัยที่ใช้ในการตรวจสอบ (Number of Factor) จำนวนปัจจัยที่มากขึ้นย่อมทำให้ Authentication แข็งแรงมากขึ้น ยกตัวอย่างที่เราคุ้นเคยก็ได้แก่ 2-Factor Authentication ที่ใช้รหัสผ่านเป็นปัจจัยแรก และใช้ SMS OTP ส่งไปยังเบอร์โทรศัพท์มือถือที่เรามีเป็นปัจจัยที่สอง

มิติที่สามคือกระบวนการในการส่งข้อมูลเพื่อตรวจสอบ กระบวนการที่มีความแข็งแรงต้องป้องกันการใช้ข้อมูลที่ถูกดักจับหรือขโมยมาได้เพื่อใช้ในการทำซ้ำ (Replay) ตัวอย่างเช่นการตรวจสอบลายนิ้วมือโดยการส่งภาพลายนิ้วมือมาเปรียบเทียบกับภาพที่เก็บไว้บนเครื่องแม่ข่าย ซึ่งใช้ปัจจัยคือ”สิ่งที่คุณเป็น”ในการตรวจสอบ มีความแข็งแรงสูงสุด แต่กระบวนการสามารถดักหรือทำสำเนาภาพเพื่อเล่นซ้ำได้ ความน่าเชื่อถือของ Authentication ก็ลดลงมาก

ตัวอย่างของกระบวนการที่แข็งแรงและน่าเชื่อถือได้แก่ Challenge-Response Authentication ที่ใช้เทคนิคด้าน Cryptographics เข้ามาช่วยทำให้ไม่สามารถดักจับหรือขโมยข้อมูลเพื่อใช้ในการทำซ้ำได้ ซึ่งมีหลายวิธี หนึ่งในวิธีที่แพร่หลายได้แก่วิธีที่เสนอโดย FIDO (Fast IDentity Online) Alliance นอกจากนั้น Authentication แบบหลายปัจจัยที่ใช้ช่องทางในการสื่อสารแตกต่างกัน (Out of Band Authentication) ก็เป็นอีกกระบวนการหนึ่งทำให้ยากต่อการปลอมแปลงหรือหลอกลวงผู้ใช้งานเช่นกัน

ความน่าเชื่อถือของ Digital ID

เนื่องจาก Digital ID ต้องพึ่งพาทั้งกระบวนการ Identity Proofing และ Authentication ดังนั้นทั้งสองกระบวนการต้องน่าเชื่อถือทั้งคู่ ทั้งนี้ความน่าเชื่อถือขึ้นอยู่กับระดับความเสี่ยงที่ยอมรับได้ของผู้ที่เกี่ยวข้องในระบบอย่างไรก็ตามสามารถอธิบายให้เห็นภาพได้ดังนี้

หากกระบวนการ Identity Proofing ไม่มีความน่าเชื่อถือแม้ว่ากระบวนการ Authentication จะมีความน่าเชื่อถือมาก เราก็มีโอกาสที่จะได้ Digital ID ของตัวปลอม ที่น่าเชื่อถือทุกครั้งที่ทำธุรกรรม

หากกระบวนการ Identity Proofing มีความน่าเชื่อถืออย่างยิ่ง แต่กระบวนการ Authentication ไม่มีความน่าเชื่อถือแล้ว เราจะได้ Digital ID ของตัวจริง ที่การทำธุรกรรมไม่ค่อยน่าเชื่อถือเนื่องจากมีโอกาสถูกปลอมแปลงการทำธุรกรรมได้

ที่จริงแล้ว Identity Proofing และ Authentication ที่น่าเชื่อถือนั้นไม่เพียงพอ ยังต้องมีองค์ประกอบอื่นๆ เช่น ความสามารถในการป้องกันการหลอกลวงโดยที่เจ้าของ Identity ไม่รู้ตัวได้ (Identity Retention) เป็นต้น เพื่อเสริมความน่าเชื่อถือของ Digital ID

อย่างไรก็ตามเป้าหมายของบทความตอนนี้เพื่อจะปูพื้นฐานให้เข้าใจเรื่อง Identity Proofing และ Authentication เพื่อที่จะกล่าวถึงเรื่อง Identity Assurance Level (IAL) และ Authenticator Assurance Level (AAL) ในตอนต่อๆ ไป

National Digital Identity: Chapter 2 ความพยายามในการรวมโครงการที่เกี่ยวข้องมาอยู่ด้วยกัน

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

จากตอนที่แล้วจบลงตรงที่ดร.อนุชิต พยายามรวบรวมโครงการต่างๆเข้ามาอยู่ด้วยกัน การเริ่มต้นการรวมโครงการเริ่มจากการที่มีการพูดคุยในที่ประชุมโครงการพัฒนาระบบอำนวยความสะดวกในการประกอบธุรกิจแบบครบวงจร ซึ่งเจ้าภาพการจัดประชุมคือสำนักงานรัฐบาลอิเล็กทรอนิกส์ (EGA) ช่วงเดือนสิงหาคม ซึ่งมีตัวแทนของหน่วยงานราชการและองค์การมหาชนหลายหน่วยงานที่มาประชุม โดยดร.อนุชิตได้เสนอว่าควรจะสร้างโครงสร้างพื้นฐานที่ไม่ยึดติดกับเทคโนโลยีในการพิสูจน์ตัวตนใดๆ และเป็นโครงสร้างแบบกระจายศูนย์ (Decentralized) ก็มีทั้งคนที่เห็นด้วยและไม่เห็นด้วยคละกันไป

อย่างไรก็ตามก็ได้ตกลงกันว่าจะมีการพูดคุยเรื่องแนวทางที่จะรวมโครงการต่างๆ ที่เกี่ยวข้องกับการพิสูจน์ตัวตน ในสัปดาห์ต่อมาที่สำนักงานพัฒนาธุรกรรมทางอิเล็กทรอนิกส์ (ETDA) โดยสรุปคร่าวๆ เท่าที่ผมจำได้โครงการต่างๆ ประกอบด้วย

• การพัฒนาระบบกลางในการยืนยันตัวตนออนไลน์ (Digital Authentication) ที่เป็นส่วนหนึ่งในโครงการพัฒนาระบบอำนวยความสะดวกในการประกอบธุรกิจแบบครบวงจร (Doing Business Portal)
• โครงการ Cross verification ของธนาคารแห่งประเทศไทย (ธปท.)
• โครงการ e-Concent ของบริษัท ข้อมูลเครดิตแห่งชาติ จำกัด (National Credit Bureau - NCB)
• โครงการ eKYC ของกลุ่มตลาดทุนโดยมีคณะกรรมการกำกับหลักทรัพย์และตลาดหลักทรัพย์ (กลต.) เป็นผู้เริ่มต้น
• โครงการอื่นๆ อีกที่คล้ายกันซึ่งผมจำชื่อไม่ได้

ในการพูดคุยครั้งนั้นก็ได้เชิญหน่วยงานที่เข้ามาร่วมนอกจาก ETDA ก็คือตัวแทนจากกระทรวงการคลัง EGA ธนาคารต่างๆ ประมาณ 7-8 แห่ง กลต. ธปท. (มีหน่วยงานอื่นอีกแต่จำได้แค่นี้) ในการประชุมกว่าจะนิยามถึงเรื่อง Identity  และองค์ประกอบที่เกี่ยวข้องกับการพิสูจน์ตัวตน ของทุกคนให้ตรงกันก็ใช้เวลาไปสองสามครั้ง ใช้เวลาประมาณ 3 สัปดาห์ ก่อนที่จะตกลงกันที่จะใช้คำนิยามให้ตรงกัน ในวันที่ตกลงให้คำนิยามนั้นผมไม่ได้อยู่ด้วย แต่ดูเหมือนว่าจะอ้างมาจาก NIST SP 800-63 Digital Identity Guidelines (คนที่อยู่ในที่ประชุมช่วยมาแก้ให้ผมด้วยนะถ้าผิด) โดยจำแนกบทบาทที่สำคัญ ได้แก่

Relying Party (RP)
An entity that relies upon the subscriber’s authenticator(s) and credentials or a verifier’s assertion of a claimant’s identity, typically to process a transaction or grant access to information or a system.
หรือสรุปง่ายๆก็คือ ผู้ให้บริการทำธุรกรรมใดๆก็ตาม เช่น ให้กู้เงิน ขายของออนไลน์ เป็นต้น

Identity Provider (IdP)
The party that manages the subscriber’s primary authentication credentials and issues assertions derived from those credentials. This is commonly the CSP (Credential Service Provider) as discussed within this document suite.
ซึ่งก็คือผู้ให้บริการยืนยันตัวตน ถ้าเปรียบเทียบให้เห็นภาพ ก็เช่น Facebook หรือ Google ให้บริการยืนยันตัวตนกับเว็บไซต์อื่น แต่ในนิยามจริงๆ IdP ทำหน้าที่มากกว่านั้น

Authoritative Source (AS)
An entity that has access to, or verified copies of, accurate information from an issuing source such that a CSP (IdP) can confirm the validity of the identity evidence supplied by an applicant during identity proofing. An issuing source may also be an authoritative source. Often, authoritative sources are determined by a policy decision of the agency or CSP (IdP) before they can be used in the identity proofing validation phase.
คือผู้ที่มีข้อมูลที่เที่ยงตรงและเชื่อถือได้และพร้อมที่จะส่งให้ผู้อื่นเมื่อมีการตรวจสอบการยืนยันตัวตนของเจ้าของข้อมูลมาครบถ้วน ตามเงื่อนไขที่กำหนดไว้ ตัวอย่าง AS เช่น บริษัท ข้อมูลเครดิตแห่งชาติ จำกัดพร้อมที่จะส่งข้อมูลเครดิตของบุคคลเมื่อบุคคลนั้นได้ยืนยันตัวตนและยินยอมให้ส่งข้อมูลนั้น กับธนาคาร (ในที่นี้คือ RP) ที่บุคคลนั้นขอสินเชื่อ

โดยที่แต่ละหน่วยงานสามารถมีบทบาทใดบทบาทหนึ่งหรือมากกว่าก็ได้เช่น ธนาคารสามารถเป็น RP ให้บริการสินเชื่อ ในขณะเดียวกันก็เป็น IdP ให้บริการยืนยันตัวตนได้ และสามารถเป็น AS เพื่อให้ข้อมูล เช่นรายการเดินบัญชี (Bank Statement) เพื่อไปขอสินเชื่อกับธนาคารอื่น เป็นต้น

องค์ประกอบอีกชิ้นที่ไม่ได้เป็นองค์ประกอบหลัก แต่มีส่วนสำคัญที่ทำให้ความน่าเชื่อถือของข้อมูลการยืนยันตัวตนสูงขึ้นก็คือ Registration Authority (RA) ยกตัวอย่างเช่นกรมการปกครอง กรมพัฒนาธุรกิจการค้า สำนักงานตรวจคนเข้าเมือง เป็นต้น

ส่วนสุดท้ายก็คือแพลตฟอร์มกลางที่จะเชื่อม หน่วยงานที่มีบทบาทต่างๆ ตามที่เขียนไว้ด้านบนนั้น ในเวลานั้นมีการตั้งชื่อว่า Universal Identity Platform ซึ่งภายหลังมาเปลี่ยนชื่อเป็น National Digital Identity Infrastructure

ความสัมพันธ์ระหว่าง Universal Identity Platform กับ RP, IdP, AS และ RA

จากนั้นดร.อนุชิต ก็พยายามที่จะให้ผู้ร่วมประชุมแสดงความคิดเกี่ยวกับการออกแบบโครงสร้าง Digital Identity แต่ก็เกิดปัญหาว่าแต่ละคนไม่สามารถที่จะเริ่มต้นอธิบายเพื่อแสดงความคิดไปในแนวทางเดียวกันได้ บ้างก็มีการนำเสนอที่ลอกแบบมาจากต่างประเทศ บางคนก็มีเฉพาะ Component Diagram ผมจึงได้เริ่มเขียน Business Process  เบื้องต้น รวมทั้ง Process ที่อยากเห็นให้กับดร.อนุชิต โดยมีรายการดังนี้

1. Identity Registration
• Individual Identity Registration
• Additional Authentication Provider
• Juristic Person Identity Registration/Change
2. Authentication
3. Information Request
4. Delegation
5. De-registration
6. Expiration
7. Renewal

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

ขอจบบทที่ 2 ตรงนี้ก่อน