01 กุมภาพันธ์ 2561

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) ในตอนต่อๆ ไป

15 พฤศจิกายน 2560

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 ตรงนี้ก่อน

20 ตุลาคม 2560

National Digital Identity: Chapter 1 ผมมาเกี่ยวข้องกับโครงการนี้ได้อย่างไร

โครงการ Digital Identity ของประเทศไทย

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

ขอย้อนกลับไปตั้งแต่สมัยผมทำงานให้กับบริษัท IT ชั้นนำแห่งหนึ่ง ผมได้มีโอกาสไปงาน CeBIT ในเดือนมีนาคมปี 2010 ได้งานนั้นสิ่งที่ผมสนใจมากอย่างหนึ่งก็คือเรื่องของ e-ID ของประเทศเยอรมันและของประเทศอื่นๆในกลุ่มยุโรป เทคโนโลยีในตอนนั้นพึ่งพาเรื่องบัตรประชาชนที่เป็นสมาร์ทการ์ดเป็นหลักไม่ว่าจะเป็นอยู่ในรูปบัตรหรือเป็น USB Token เพื่อใช้ในการธุรกรรมต่างๆ ไม่แค่เพียงของรัฐ แต่ยังโยงไปถึงธุรกรรมเกี่ยวกับ ธนาคาร การเงินฯลฯ ในตอนนั้นก็กลับมาย้อนนึกว่าทำไมเราถึงไม่สามารถใช้บัตรประจำตัวประชาชนของเราซึ่งเป็นสมาร์ทการ์ดเช่นกันทำธุรกรรมแบบนั้นได้ แต่เนื่องจากไม่ได้เกี่ยวข้องกับเรื่องนี้โดยตรงก็ได้แต่คิดและเก็บเอาเรื่องนี้ไว้ในใจ

จนมาถึงเดือนกันยายนปี 2015 ได้ไปเที่ยวที่อัมพวากับกลุ่มผู้เชี่ยวชาญทางด้าน Security กลุ่มใหญ่ ขากลับได้ติดรถของผู้เชี่ยวชาญท่านหนึ่ง ได้คุยกันระหว่างทางกลับมากรุงเทพหลายเรื่อง หนึ่งในเรื่องนั้นก็มีเรื่อง e-ID ของเยอรมัน แล้วก็พูดถึงความตั้งใจที่ อยากให้เมืองไทยใช้ Digital Identity ผ่านบัตรประชาชนได้ แต่ตอนนั้นผมยังมองเรื่อง Digital Identity ค่อนข้างแคบไปหน่อย ต่อมาผู้เชี่ยวชาญท่านนั้นก็ได้ทำโครงการเรื่องนี้ Digital Identity ให้กับหน่วยงานหนึ่ง

หลังจากนั้นกระแสเรื่องของการพิสูจน์ตัวตนผ่านทางอุปกรณ์ Mobile เช่น Smartphone ก็เริ่มมาถึงวงการธนาคารในกระบวนการเช่นการทำ E-KYC (Know Your Customer) การพิสูจน์ตัวตนลูกค้า E-Consent การให้ความยินยอมเปิดเผยข้อมูลด้วยวิธีการทางอิเล็กทรอนิกส์ ซึ่งกลายเป็นว่าความต้องการหลักเป็นเรื่องเดียวกันก็คือทำอย่างไรถึงจะพิสูจน์ทราบได้ว่าผู้ที่จะมาทำธุรกรรมนั้นเป็นบุคคลตามที่กล่าวอ้างจริงๆ

สิ่งที่เกิดขึ้นก็คือแค่เฉพาะในวงการธนาคารก็มีแนวคิดที่จะทำเรื่อง Digital Identity ออกไปหลายหลายรูปแบบ แต่ไม่ว่ารูปแบบไหนก็ต้องกลับมาเกี่ยวข้องกับผมซึ่งทำงานในสายงาน Information Security อยู่ดี ในรายการที่ผมต้องไปเกี่ยวข้อง หลายเรื่องนั้นก็มีวิธีการออกแบบที่ไม่ดีเลย

หมายความว่าอย่างไร ปกติในการออกแบบกระบวนการหรือวิธีการที่เกี่ยวข้องกับเรื่อง information Security เหล่านี้ผมมักจะสร้างแบบจำลองสถานการณ์ที่สามารถละเมิดกระบวนการเหล่านี้แล้วทดสอบว่ามีโอกาสเป็นไปได้หรือไม่ (Misuse Case Scenario) ผมพบว่าคนที่พยายามออกแบบกระบวนการเหล่านั้นไม่เคยทดสอบสมมติฐานในรูปแบบการละเมิดขั้นตอนว่าเป็นไปได้หรือไม่ ทำให้ผมต้องพยายามสื่อสารออกไปให้ได้ว่าการออกแบบเหล่านั้นไม่ถูกต้อง แต่ก็ไม่ค่อยมีใครเชื่อผมเท่าไหร่

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

ทำให้ผมได้มาร่วมงานกับผู้เชี่ยวชาญท่านนั้น ที่ผมได้ติดรถกลับบ้านในเดือนกันยายนปี 2015

จบปฐมบทเรื่อง Digital Identity ของผม

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

17 ตุลาคม 2560

WPA2 Key Reinstallation Attack (KRACK)

ช่องโหว่ WPA2 ของ Wireless LAN ทำให้ชีวิตดูเหมือนอยู่ยาก แต่อย่างไรก็ตามอาศัยความรู้อันน้อยนิด ให้ความกระจ่างได้ดังนี้
1. เนื่องจากต้องทำ Rouge Access Point in the Middle ดังนั้นถ้าบ้านคุณไม่ใหญ่จนคนมาทำ Access Point ปลอมในบ้านคุณได้ ก็ไม่ต้องวิตกกังวลอะไรนัก หรือแม้แต่ Pocket WiFi ก็ยังไม่น่ากังวล
2. คนที่ต้องกังวลคือคนที่ใช้ Wireless Access Point ในสถานที่ที่ควบคุมไม่ได้ เช่นที่ทำงาน (เวรล่ะ) วิธีแก้คือเดินไปหา Access Point แล้วนั่งทำงานใกล้ๆ ให้สัญญาณแรงๆ เข้าไว้ (ทำได้เรอะ)
แก้ไข: ไปนั่งกินเนื้อย่างคุยกับคนที่อ่าน Paper นี้ครบแล้ว สรุปว่าถ้า Attacker ตั้งใจโจมตีรายคน เอาเสาส่งแบบ Beam ไปยิงเพื่อเปลี่ยน Channel ทำ Man-In-The-Middle Rouge Access Point ได้ ดังนั้นอยู่ใกล้ Access Point ก็อาจไม่ช่วย
3. ส่วนคนที่ใช้ Public WiFi แบบไม่รู้สึกตะขิดตะขวงใจ ไม่ได้ผลกระทบอะไรเพิ่ม ไม่ปลอดภัยยังไง ก็ไม่ปลอดภัยเท่าเดิม
ทางแก้ ก็ Update WPA2 Patch ของ Wireless LAN Adapter ที่เครื่องตัวเอง ส่วนมือถือถ้าไม่มี WiFi Patch หรือ Update ออกนอกบ้านก็ 3G/4G โลด

Update: Ubuntu ออก WPA Package Update แล้วนะ แก้ Program ชื่อ wpa_supplicant (2.4-0ubuntu6.2) อย่าลืม Update กัน

KRACK Attacks: Bypassing WPA2 against Android and Linux

07 ตุลาคม 2560

Security ใน DevOps ต่างจาก DevSecOps อย่างไร

มีคำถามเรื่อง DevSecOps ว่า Dev กับ Ops ก็มี Security อยู่แล้วไม่ใช่หรือ ทำไมต้องมี DevSecOps เพิ่มขึ้นมา คำตอบของคำถามแรกคือทั้งใช่และไม่ใช่ ส่วนคำถามหลังต้องอธิบายเพิ่มเติม
ในการทำ DevOps ในส่วน Security ที่ควรจะมีอยู่แล้วด้าน Dev ก็คือเรื่องของ Secure Design และ Secure Coding ซึ่งเป็น Practice ที่จำเป็นต้องมีในการ Implementation เช่นการปฏิบัติตาม OWASP Application  Security Verification Standard เป็นต้น อีกด้านคือฝั่ง Ops ที่ควรจะมีโดยพื้นฐานก็เช่นการทำ Hardening หรือ Secure Deployment Process เป็นต้น
แล้ว DevSecOps มาช่วยอะไร
ในการพัฒนา Software นั้นถ้าอ้างอิงตาม Microsoft Security Development Lifecycle (SDL ดู https://www.microsoft.com/en-us/sdl/) การทำ Automation ของ DevSecOps นั้นอยู่ที่ Implementation และ Verification
Microsoft Security Development Lifecycle

ในขั้นตอนหลังจาก Implementation จะต้องมีการทำ Security Practice ก็คือตรวจสอบว่าใช้เครื่องมือในการพัฒนา (Tool Chain) และ Library ที่ได้รับการอนุมัติแล้วหรือเปล่า รวมทั้งการทำ Static Code Analysis  เป็นต้น นี่เป็นขั้นตอนก่อนการ Compile และ Build เพื่อทำ Automate Testing
ขั้นตอน Verification ประกอบด้วยการทำ Dynamic Analysis เช่นทำ Vulnerability Assessment Scanning ทำ Fuzz Testing โดยการลองป้อนข้อมูลที่ไม่อยู่ในรูปแบบที่ถูกต้อง (Malformed Data) เพื่อทดสอบว่าแอพพลิเคชั่นสามารถจัดการกับข้อมูลเหล่านี้ได้โดยไม่ก่อให้เกิดปัญหาทางด้าน Security ไปจนถึงการทํา Penetration Testing ซึ่งขั้นตอนนี้ควรทำหลังจากทำ Automate Testing เสร็จเรียบร้อยแล้ว และก่อน Deployment
นอกเหนือไปจากการตรวจสอบ Security แล้วยังมีส่วนที่ต้องทำการตรวจสอบเพิ่มเติมก็คือการตรวจสอบเพื่อเป็นไปตามการกำกับดูแล (Compliance) สิ่งต่างๆเหล่านี้รวมทั้งหมดแล้วไม่ได้ถูกเขียนไว้ในกระบวนการการทำ DevOps แบบที่ทำโดยทั่วไป
สำหรับท่านที่สนใจสามารถหาอ่านรายละเอียดได้จากเอกสาร White Paper ตามลิงค์ด้านล่าง
http://www.devseccon.com/wp-content/uploads/2017/07/DevSecOps-whitepaper.pdf

07 มิถุนายน 2560

Software Security Requirement Guideline กับการปล่อยไก่ของผม

เรื่องเล่ายามดึก
ตอนเข้ามาเกียรตินาคินใหม่ๆ ได้เขียน Software Security Requirement Guideline ฉบับหนึ่งเพื่อให้ทาง Development Team และ Vendor ทำตาม โดยอ้างอิงจากเอกสารของ OWASP ฉบับหนึ่ง (ซึ่งเดี๋ยวจะบอกทีหลัง) เป็นหลัก โดยมีการปรับแก้เพิ่มเติมบางอย่างตาม IT Policy ของธนาคาร และ Industrial Standard และ Regulation เช่น PCI-DSS หรือ Best Practice ของธนาคารแห่งประเทศไทยเข้าไป (ซึ่งไม่ได้มากมายเพราะส่วนใหญ่ของ OWASP จะดีกว่าอยู่แล้ว)
หลังจากนั้นเอกสารฉบับนี้ก็มีการรวมร่างกับ Software Architecture Requirement กลายเป็น Software Security and Architecture Guideline ล่าสุดคือ Version 4 และผมก็ไม่ได้เขียนเองแล้ว แต่เป็นคน Review
ตัดกลับมาเมื่อคืนวาน น้องในกลุ่ม OWASP บอกว่าหาคนไปพูดเรื่อง
ASVS ในงาน Thailand Security Day อะไรสักอย่างที่ ETDA วันที่ 26 มิถุนายน ผมก็บอกว่า ASVS คืออะไร ไม่เคยได้ยิน สักพักก็มีการส่ง Link ของเอกสารมาให้ เปิดไปดูก็เห็นเขียนว่า OWASP Application Security Verification Standard 3.0.1 (July 2016) เราก็อืม มันเป็นตัวย่อนี่เอง นั่งอ่านไปสักพักก็รู้สึกว่าคุ้นๆ แฮะ นึกไปนึกมาก็จำได้ว่าเราเคยใช้รายการในเอกสารฉบับนี้เขียน Software Security Guideline ของธนาคาร กลับไปเช็คดู เฮ้ย เราใช้ Version 2.0 เป็นต้นฉบับนี่นา
ด้วยอารมณ์ที่คิดว่าต้อง Update รายการให้ทันสมัยเลยส่ง Link ไปให้น้องในทีมที่ดูแลเอกสารต่อ บอกว่าเราต้อง Update ให้กับเอกสาร Software Security and Architecture Guideline แล้วล่ะ
วันนี้น้องในทีมมาบอกว่า พี่ ผมใช้เอกสารของ OWASP ฉบับนี้มาแก้เอกสารของเราในเวอร์ชันปัจจุบันแล้วนะ พี่เป็นคนรีวิวเองด้วย
ไก่วิ่งเต็มที่ทำงาน จับแทบไม่ทัน

02 ธันวาคม 2559

เรามาเขียนโค้ดได้ไง

ไม่แน่ใจว่าชัยพฤกษ์วิทยาศาสตร์หรือเซมิคอนดักเตอร์อิเลคทรอนิคส์ทำให้เราได้รู้จักกับ Apple ][ กับภาษา Basic เริ่มเขียนโค้ดครั้งแรกตอน ม.3 แต่เขียนบนกระดาษ ไม่มีคอมพิวเตอร์ให้ใช้เพราะอยู่ต่างจังหวัด กว่าจะได้ใช้ครั้งแรกก็ตอนอยู่ม.4 เพราะเข้ามาเรียนกรุงเทพ ตอนเปลี่ยนมาเป็น MS Windows ใช้หากินจาก VB และ VBA อยู่พักใหญ่
ภาษาที่สองที่เขียนเป็นคือ Assembly บน 6502 โดยได้หนังสือสามจากร้าน Book Chest แถวสยาม ไม่มี Assembler ใช้วิธีเปิดตาราง Opcode เอา แล้วโปรแกรมเป็น Hexadecimal เข้าไปบนเครื่อง Apple ][ ของเพื่อน ต่อมาจึงขยับขยายเป็น Z-80, 8048, 8086 และ MCS-51
ภาษาที่สามเป็น Lego เรียนตอนม.4ที่เตรียม สนุกดี แต่ไม่มีสาระ ลืมไปแล้วด้วย
ภาษาที่ 4 คือ FORTRAN เรียนตอนปีหนึ่ง ชอบที่จัดการ Matrix และ Imaigantion Numberได้
ภาษาที่ 5 ที่เขียนได้คือ C โดยได้หนังสือชื่อ ปอกส้มเข้าปาก ที่แถมมาจากวารสารคอมพิวเตอร์ฉบับหนึ่ง ลองหัดเขียนโดยใช้ Microsoft C ซึ่งเป็น Command Line Compiler แล้วจึงย้ายมาใช้ Turbo C เพราะเป็น IDE รุ่นแรกๆ บน MSDOS ชอบเพราะสั้นและทำ Bitwise Operation ได้เหมือน Assembly ตอนนี้ชำนาญเป็นอันดับหนึ่ง
ภาษาที่ 6 คือ Pascal โดย Turbo Pascal ไม่ชอบภาษานี้เพราะเยิ่นเย้อ ไม่ชอบการแยก Procedure กะ Function
ภาษาที่ 7 คือ C++ อ่านตอนอยู่ปี 1 แต่ไม่เชี่ยวชาญมาก มาเชี่ยวตอนเล่น Linux กะเขียนโปรแกรมลง Microsoft Pocket PC เลยเถิดมาบน ARM Embeded System เชี่ยวเป็นลำดับที่ 2
ภาษาที่ 8 คือ COBOL ตอนเรียนภาคคอม ลืมไปแล้ว
ภาษาที่ 9 คือ Java ตอนที่ออกใหม่ๆ เขียน Applet บน Web หลังๆ พอมาดังบน J2EE แล้วก็ไม่ค่อยได้เขียน
ภาษาที่ 10 คือ JavaScript เพราะต้องเขียน Web Page ให้มีลูกเล่น เป็นเหตุให้ต้องเรียนรู้ DOM ในเวลาต่อมา
ภาษาที่ 11 คือ VBScript บน ASP Classic ที่ออกมาพร้อม IIS 3 เป็น Server Side Scripting แรกที่หัด
ภาษาที่ 12 คือ PHP ตอนเขียน Web Server Component Linux ช่วงแรกๆ แต่ก็เลยเถิดมาไกล ใช้เยอะมากจนถนัดเป็นอันดับสาม รู้ไส้รู้พุงดีว่า Security มันเป็นไง
ภาษาที่ 13 คือ Python ไม่เชี่ยวแต่เขียน GUI ได้ก็แล้วกัน มาหัดตอนอยู่ที่เกียรตินาคินเพราะเห็น exploit code ส่วนใหญ่มันเป็น Python

ภาษาที่เป็นแต่ไม่นับก็คือพวก Shell Script เช่น Perl, DOS/Windows Batch, Bash
C# ไม่นับเพราะมันเป็นลูกหลานของ C++
ไม่นับพวก Markup Language แล้วกัน เอาแต่ Programming Language
ว่าจะหัด Ruby เหมือนกันเพราะ Metasploit แต่ตอนนี้ยุ่งเกินกว่าจะหัดใหม่

ไขข้อข้องใจว่าทำไมผมทำ Secure Code Review ได้