e-Contract (Digital Contract : dContract)
สัญญาอิเล็กทรอนิกส์เป็นหนึ่งใน Digital Transformation ที่จะช่วยยกระดับการดำเนินธุรกิจให้มีความสะดวก คล่องตัว มากยิ่งขึ้น แทนการใช้เอกสารสัญญาแบบ Paper เนื่องด้วยการใช้ Paper นั้น เป็นที่ทราบกันดีว่า มีความสิ้นเปลืองทรัพยากร และเวลาอย่างมาก ตั้งแต่ การจัดเตรียมเอกสาร, การพิมพ์เอกสาร, การจัดส่งเอกสารให้แก่ผู้ลงนามและนำกลับ, การ Scanกระดาษกลับเป็นไฟล์ในคอมพิวเตอร์, การอัพโหลดไฟล์เข้าในระบบจัดเก็บเอกสาร, การจัดเก็บ Hardcopy เข้าคลังเอกสาร, การเช่าสถานที่คลังเก็บเอกสาร, การสืบค้นเรียกดู Hardcopy จากคลังเอกสาร เป็นต้น หากว่ากระบวนการเหล่านี้ถูกแทนที่ด้วย Digital และทุกขั้นตอนกระทำผ่าน Application ก็จะช่วยประหยัดทรัพยากร งบประมาณ และเวลาได้เป็นอันมาก อีกทั้งยังเพิ่มความน่าเชื่อถือ และสามารถเชื่อมโยงกับระบบงาน Automation ได้อีกด้วย
พ.ร.บ. ธุรกรรมอิเล็กทรอนิกส์ ได้ให้นิยามของ Electronics Signature ไว้ว่า หมายถึง อักษร อักขระ ตัวเลข เสียง หรือสัญลักษณ์อื่นใดที่สร้างขึ้นให้อยู่ในรูปแบบอิเล็กทรอนิกส์ซึ่งนำมาใช้ประกอบกับข้อมูลอิเล็กทรอนิกส์ เพื่อแสดงความสัมพันธ์ระหว่างบุคคลกับข้อมูลอิเล็กทรอนิกส์ โดยมีวัตถุประสงค์เพื่อระบุตัวบุคคลผู้เป็นเจ้าของลายมือชื่ออิเล็กทรอนิกส์ที่เกี่ยวข้องกับข้อมูลอิเล็กทรอนิกส์นั้น และเพื่อแสดงว่าบุคคลดังกล่าวยอมรับข้อความในข้อมูลอิเล็กทรอนิกส์นั้น
พ.ร.บ.ว่าด้วยธุรกรรมทางอิเล็กทรอนิกส์ฯ รองรับการลงลายมือชื่ออิเล็กทรอนิกส์ (Electronics Signature) ให้มีผลทางกฎหมาย เช่นเดียวกับการลงลายมือชื่อบนเอกสารกระดาษ
สำหรับการใช้งาน Electronics Signature ในประเทศไทยนั้น แบ่งประเภทเป็นแบบทั่วไป และแบบที่เชื่อถือได้
- Electronics Signature แบบทั่วไป ตามมาตรา 9
- Electronics แบบที่เชื่อถือได้ ตามมาตรา 26 (ใช้ PKI เพื่อสร้าง Digital Signature) และ ตามมาตรา 28 (เพิ่มเติมการใช้ Certificate ที่ออกโดย Certificate Authority)
Electronics Signature แบบทั่วไป
Electronics Signature แบบทั่วไป ตามมาตรา 9 ถ้าจะยกตัวอย่างให้ง่ายๆ ตัวอย่างแรกให้นึกถึง การ Scan หรือถ่ายภาพ ลายเซ็นต์ไว้ แล้ว save ภาพเก็บไว้ในคอม แล้วมีกระบวนการนำไฟล์ภาพไปใส่ในเอกสาร หรือการใช้ปากกา Stylus เขียนลายเซ็นต์บนหน้าจอ ซึ่งหลายๆคนอาจจะเคยทำแบบนี้มาบ้างแล้ว โดยที่การใช้งาน ต้องมีความมั่นคงรัดกุม และคำนึงถึงลักษณะ ประเภท หรือขนาดของธุรกรรม
อย่างไรก็ตาม การนำ Electronics Signature ลักษณะนี้มาใช้งานจริง ต้องเผชิญกับความท้าทายหลายประการ ได้แก่
- การปลอมตัวเป็นผู้อื่น (Impersonation) เช่น ผู้ลงลายมือชื่อไม่ใช่ตัวจริง อาจะมีคนอื่นปลอมลายมือชื่อ หรือคนอื่นขโมยไฟล์ภายลายมือชื่อไปใช้
- การปฏิเสธความรับผิด (Repudiation) เช่น ผู้ลงลายมือชื่อพยายามปฏิเสธว่าตนเองไม่ได้ทำ
- ข้อมูลไม่มีความครบถ้วน (Loss of data integrity) เช่น ข้อมูลมีการเปลี่ยนแปลงหลังจากที่ได้ลงลายมือชื่อ โดยอาจใช้โปรแกรมคอมพิวเตอร์แก้ไขเนื้อหาของเอกสาร
- การไม่มีอำนาจลงนาม (Exceeding authority) เช่น การลงลายมือชื่อโดยผู้ที่ไม่ได้รับอนุญาต
ความท้าทายดังกล่าวนี้ สามารถจัดการด้วยการนำ Public Key Infrastructure มาใช้ในการลงลายมือชื่อให้มีความน่าเชื่อถือ ดังที่จะกล่าวต่อไป
Electronics Signature แบบเชื่อถือได้
Electronics Signature แบบเชื่อถือได้ สำหรับมาตรา 26 นั้นต้องนำ PKI (Public Key Infrastructure – โครงสร้างพื้นฐานกุญแจสาธารณะ) มาใช้ในการสร้าง Digital Signature ของเอกสาร โดยที่ Digital Signature คือ การลงลายมือชื่ออิเล็กทรอนิกส์โดยใช้ใบรับรองอิเล็กทรอนิกส์ (Certificate) ที่ระบุตัวบุคคล หรือองค์กรผู้เป็นเจ้าของลายมือชื่อ เพื่อแสดงว่าบุคคล หรือองค์กร ดังกล่าวยอมรับข้อความในข้อมูลอิเล็กทรอนิกส์นั้น
ศึกษาเพิ่มเติมเกี่ยวกับ PKI ได้จาก บทความของ ETDA
ในที่นี้จะขออธิบายถึงหลักการสร้าง Digital Signature คร่าวๆ ดังต่อไปนี้
1. สมมติให้มีบุคคล 2 คน คนแรกเป็นผู้ส่งเอกสาร คนที่สองเป็นผู้รับเอกสาร สองคนนี้ไม่ได้รู้จักหรือมีความสัมพันธ์กันมาก่อน และต้องส่งเอกสารแก่กันผ่านระบบคอมพิวเตอร์
2. ผู้ส่งเอกสารต้องมี Private-Public Key ของตนเองขึ้นมาก่อน และต้องมี Certificate ที่ถูกรับรองโดย CA (Certificate Authority – ผู้ให้บริการออกใบรับรอง) ที่ผู้ส่งเอกสารใช้บริการอยู่ นอกจากนี้ต้องเก็บรักษา Key, Certificate ไว้อย่างปลอดภัยและลับส่วนตัวที่สุด ป้องกันการถูกขโมยไปใช้งาน Certificate ที่ว่านี้ ประกอบด้วยข้อมูลส่วนบุคคลและ Public Key ของบุคคลนั้น การมี Certificate เป็นการรับรองว่าบุคคลที่มีชื่อปรากฏอยู่ใน Certificate นี้ มีตัวตนบนโลกใบนี้จริง โดยผ่านการพิสูจน์ตัวตนอย่างเข้มงวดมาแล้วโดย Certificate Authority นั้น (เช่น ต้องไปแสดงตนต่อหน้าเจ้าหน้าที่ มีการตรวจสอบ Identity ด้วยวิธีการต่างๆที่รัดกุม) มิใช่ใครก็ได้ที่อยู่ๆตั้งชื่อสมมติขึ้นมาและไม่มีตัวตนจริง กล่าวคือเป็นการเชื่อมโยงผูกตัวตนในโลก Digital กับโลกความเป็นจริงไว้ด้วยกัน
ตัวอย่าง Certificate
3. จากนั้นเข้าสู่ขั้นตอนการสร้าง Digital Signature โดยใช้ Application ที่ผู้ส่งเอกสารใช้บริการอยู่ ไฟล์เอกสาร (PDF format) จะถูกนำมาคำนวณ Hash Value ด้วย Hashing Algorithm มาตรฐาน จากนั้นทำการ Encrypt ค่า Hash Value นี้ด้วย Private Key ของผู้ส่ง ผลลัพธ์ที่ได้คือ Digital Signature จากนั้น ผนวก Certificate, Digital Signature ลงในไฟล์เอกสาร (PDF)
4. ผู้ส่งเอกสาร จัดส่งเอกสารให้แก่ผู้รับทางช่องทางที่ตกลงกันไว้
5. ผู้รับเอกสาร ตรวจสอบว่าเอกสาร PDF นั้น ใครเป็นผู้ลงลายมือชื่อโดยดูจาก Certificate ใน PDF ซึ่งสามารถเห็น ชื่อผู้ลงลายมือชื่อและ CA ที่เป็นผู้รับรอง หากผู้รับยอมรับว่า CA นั้นเป็นที่น่าเชื่อถือ ก็มั่นใจได้ว่า Digital Signature นั้น มาจากบุคคลนั้นจริง (อย่างที่ได้กล่าวไว้ว่า CA ได้พิสูจน์ตัวตนของบุคคลนั้นแล้ว ก่อนที่จะออก Certificate ให้)
6. ผู้รับเอกสาร ใช้ Application ตรวจสอบว่าเนื้อหาในไฟล์ถูกแก้ไขหลังจากลงลายมือชื่อไปแล้วหรือไม่ โดย Application อาจเป็น Software จำพวก PDF Reader หรือเป็นระบบ Application ใดๆที่ตนใช้บริการอยู่ ซึ่งมักมีหลักการตรวจสอบดังนี้
-
- นำไฟล์ PDF มาคำนวน Hash value เก็บค่าไว้เปรียบเทียบภายหลัง (a)
- ใช้ Public Key ที่อยู่ใน Certificate ไป Decrypt ข้อมูล Digital Signature ให้ได้ค่า Hash Value เดิมออกมา (b) ซึ่งเป็น Hash Value ที่ผู้ส่งสร้างไว้ ณ จังหวะที่เขาลงลายมือชื่อนี้
- เปรียบเทียบ Hash Value ทั้งสอง (a & b) ถ้าตรงกัน แสดงว่าเนื้อหาในไฟล์ไม่ได้ถูกแก้ไข แต่ถ้าต่างกัน แสดงว่ามีการแก้ไขเนื้อหาในไฟล์ (Hash value a จะได้ค่าต่างจาก b)
การลงลายมือชื่ออิเล็กทรอนิกส์ ด้วยเทคโนโลยี PKI ผ่านการใช้ใบรับรองอิเล็กทรอนิกส์ (Certificate) นั้น เป็นวิธีการที่ช่วยให้ผู้ที่เกี่ยวข้องกับข้อมูลอิเล็กทรอนิกส์นั้นๆ เชื่อมั่นได้ว่าผู้ที่ลงลายมือชื่ออิเล็กทรอนิกส์ด้วยเทคโนโลยี PKI เป็นผู้ทำธุรกรรมหรือยอมรับข้อความในข้อมูลอิเล็กทรอนิกส์ดังกล่าวจริง และจะไม่สามารถปฏิเสธความรับผิดได้ อีกทั้งยังสามารถตรวจสอบได้ว่า ข้อมูลอิเล็กทรอนิกส์ดังกล่าวถูกแก้ไขหลังจากที่มีการลงลายมือชื่อหรือไม่ ซึ่งสอดคล้องตามพระราชบัญญัติว่าด้วยธุรกรรมทางอิเล็กทรอนิกส์ พ.ศ. 2544 มาตรา 9 และ 26 และสามารถตอบโจทย์ความท้าทายที่กล่าวถึงในตอนแรก คือ Impersonation, Repudiation, และ Loss of Integrity ได้นั่นเอง
Long Term Validation (LTV)
Certificate ที่ออกโดย CA นั้น มีกำหนดวันหมดอายุ (Expiration) ซึ่งผู้ใช้บริการจำเป็นต้องต่ออายุเป็นระยะๆ และ Certificate ยังถูกเพิกถอน (Revocation) ได้ด้วย หากเจ้าของพบว่า Key ของตนถูกเปิดเผย และแจ้งเพิกถอนไปยัง CA
ภาพจาก: https://www.etda.or.th/
ประเด็นที่อาจจะเกิดขึ้นคือ เมื่อ Certificate ที่ฝังอยู่ใน PDF นั้นหมดอายุหรือถูกเพิกถอนไปนานแล้ว เมื่อผู้อ่านเอกสารเปิดไฟล์ขึ้นมาด้วย Application อาจจะพบว่ามีข้อความแจ้งเตือนว่า Verify ความถูกต้องไม่ผ่านได้ ด้วยเหตุนี้จึงมีการทำคุณสมบัติ LTV (Long Term Validation) มาประกอบ ซึ่งก็คือ บันทึกข้อมูลสถานะของ Certificate และ Timestamp ณ ตอนที่เอกสารถูกลงลายมือชื่อไว้ใน PDF เพื่อพิสูจน์ในภายหลังได้ได้ว่า Certificate ยังคง Valid ณ เวลาที่ลงนามเอกสารนี้
PDF Archiving (PDF/A) and Long Term Preservation
เอกสาร PDF นั้น อาจมีทั้งตัวอักษรและภาพ ดังนั้นเพื่อให้แน่ใจว่าไฟล์ PDF ที่เราเปิดอ่านในตอนนี้ แสดงผลให้เห็นเป็นอย่างไร อนาคตกลับมาเปิดไฟล์นี้ใหม่ ก็ต้องเห็นแบบเดียวกันทุกประการ ทั้ง Font, Color ไม่ว่าจะใช้ซอฟต์แวร์ใดรุ่นใดอ่าน หรือใช้งานกับระบบคอมพิวเตอร์รุ่นใดในอนาคตก็ตาม ดังนั้นจึงมีการกำหนดมาตรฐานที่เรียกว่า PDF/A (PDF Archiving) ขึ้น ซึ่งกำหนดให้ Embed font, color, metadata ต่างๆลงในไฟล์ สำหรับ PDF/A นี้มีการพัฒนาต่อยอดมาแล้วหลายรุ่น จนกระทั่งมาตรฐานเวอร์ชัน PDF/A-3 ได้ เพิ่มคุณสมบัติที่สำคัญ 1 อย่าง คือ สามารถฝังไฟล์เอกสารชนิดอื่นที่มาตรฐาน PDF/A ไม่ได้รองรับลงไปในไฟล์ PDF ได้ เช่น Excel, Word, HTML, CAD หรือ XML ซึ่งเป็นประโยชน์มากในการนำไฟล์ไปประมวลผลด้วยระบบคอมพิวเตอร์ต่อ
ตัวอย่างอันหนึ่งของการใช้ประโยชน์ PDF/A-3 ในประเทศไทย คือ e-Tax ซึ่งข้อกำหนดของกรมสรรพากรระบุให้แนบไฟล์ XML ที่มีโครงสร้างตามที่ระบุไว้ที่เอกสาร “ข้อเสนอแนะมาตรฐานฯการใช้ข้อความ XML สำหรับการแลกเปลี่ยนข้อมูลอิเล็กทรอนิกส์ระหว่างหน่วยงาน (ขมธอ. 14-2560)” เพื่อให้ซอฟต์แวร์ของกรมสรรพากรอ่านข้อมูลได้
ตัวอย่างใบกำกับภาษีอิเล็กทรอนิกส์ที่แนบไฟล์ XML
ส่วนการนำ PDF/A-3 มาใช้ในการลงลายมือชื่อใน eContract เราสามารถบันทึกข้อมูลเกี่ยวกับการทำสัญญาและลงลายมือชื่อนี้เป็นรูปแบบ JSON หรือ XML ได้
Key Management
จากหลักการของ Digital Signature ที่ User ที่เป็นผู้ส่งเอกสารต้องมี Certificate ที่ออกโดย CA (Certificate Authority เป็น Issuer) โดยที่ภายใน Certificate นั้น บรรจุ Public Key ของ User ไว้ และ Certificate ต้องถูก Sign ด้วย Private Key ของทาง CA เอง รูปต่อไปนี้แสดงการรับรอง Certificate ของ A ด้วย Private Key ของผู้รับรอง B และ Certificate ของ B ถูกรับรองด้วย C ซึ่งเป็น Root CA อีกชั้น
ภาพจาก https://darutk.medium.com/illustrated-x-509-certificate-84aece2c5c2e
ช่องโหว่ที่อาจเกิดขึ้นได้คือ หากการจัดเก็บ Key ของทาง CA เอง ไม่มั่นคงปลอดภัย อาจถูกจารกรรมได้และถูกนำไปใช้ Sign Certificate ให้กับผู้บุกรุก และสามารถเข้าสู่ระบบคอมพิวเตอร์ไปสร้างความเสียหายแก่องค์กรได้ แนวทางหนึ่งที่แก้ไขคือ ใช้ Hardware Security Module (HSM) จัดเก็บ Key ที่สำคัญเหล่านี้ หากจะเปรียบเทียบ HSM กับเครื่องใช้ในชีวิตประจำวัน โดยหลักการก็คล้ายๆกับ การมีกล่องนิรภัยสำหรับเก็บกุญแจของห้องลับในบ้านไว้ หากจะเปิดห้องลับ ก็ต้องมาหากล่องนิรภัยนี้ก่อน ใส่รหัสเปิดกล่อง แล้วจึงหยิบกุญแจไปไขห้องลับ ดังภาพ
สำหรับ HSM นี้นอกจากการทำตัวเสมือนกล่องนิรภัยเพื่อเก็บกุญแจแล้ว ยังมีความสามารถในการตรวจจับและป้องกันการบุกรุกในลักษณะต่างๆหลากหลาย มีฟังก์ชันปิดตัวเองได้หากพบการบุกรุกที่มีความเสี่ยงสูง ทำให้ไม่สามารถใช้งานอุปกรณ์ได้เลย จนกว่าผู้ดูแลจะปลดล็อก
HSM ที่เป็นที่นิยมใช้อันหนึ่งก็คือ Luna HSM ของบริษัท Thales ซึ่งมีคุณสมบัติด้านประสิทธิภาพและความปลอดภัยอันดับต้นๆในอุตสาหกรรม
Our Solution
บริษัท Stream I.T. Consulting Ltd. ได้พัฒนา Solution สำหรับงานด้านการลงลายมือชื่อสัญญาแบบอิเล็กทรอนิกส์ โดยมีลักษณะการทำงานตามมาตรา 26 ของพ.รบ.ธุรกรรมอิเล็กทรอนิกส์ โดย
- ใช้ Microsoft CA เป็น Certificate Authority (CA) ภายในองค์กร เพื่อทำ Signing Certificate ของ User เพื่อรับรองตัวตนของผู้ใช้งาน โดยที่องค์กรเป็นผู้พิสูจน์ตัวตนของ User
- ใช้ Luna HSM เป็น Hardware Security Module สำหรับบริหารจัดการ Key ต่างๆ เพิ่มความมั่นคงปลอดภัยของระบบ
- มี REST API สำหรับใช้งานเกี่ยวกับ Certificate, Signing, Verification โดยใช้งานได้ง่ายดาย
- เสริมด้วย Onboarding application และ Document Signing Application สำหรับองค์กรที่ยังไม่มี Application ทางบริษัทสามารถพัฒนา Application ดังกล่าวให้เข้ากับระบบงานขององค์กรท่านได้ โดย
ภาพต่อไปนี้แสดง Component ส่วนของ Digital Signature Services ซึ่งเป็น REST API ที่ให้บริการด้าน Certificate Management, Document Signing ซึ่ง Encapsulate ส่วนของ Luna HSM เพื่อขจัดความยุ่งยากในการศึกษาเรียนรู้การใช้งาน HSM ออกไป Application สามารถ Integrate มาใช้งาน REST API นี้ได้อย่างง่ายดาย หากองค์กรของท่านมีทีมพัฒนา Mobile/Web Application อยู่แล้ว ท่านสามารถซื้อเฉพาะส่วนของ Digital Signature Services ไปใช้งานได้
นอกจากนี้ ในกรณีที่องค์กรของท่านต้องการพัฒนา Mobile Application หรือ Web Application ส่วนเพิ่มเติมสำหรับบริการ e-Contract ทางบริษัทฯ สามารถให้บริการพัฒนา Application ได้ โดยลักษณะของ Architecture ก็จะมีส่วนของ Backend ที่เป็น Container & Microservice ขึ้นมาคั่นระหว่ง Mobile/Web Application และ Digital Signature Services สตรีมฯ เองก็สามารถทำได้ ซึ่งเรียกได้ว่าเรามีบริการครบทุกความต้องการของลูกค้าเลยทีเดียว
ดังนั้น สตรีมฯ กล้าพูดได้อย่างเต็มปากว่าเรามีความพร้อมในการเป็นผู้นำสำหรับโซลูชั่น e-Contract (Digital Contract : dContract) พร้อมเข้ามายกระดับการเซ็นสัญญาสำหรับองค์กรของท่านให้มีความคล่องตัวมากขึ้น ลดการใช้กระดาษลงได้เป็นอย่างมาก และมีความปลอดภัยสูง รวมถึงมีกฎหมายรองรับในการทำธุรกรรมอีกด้วย
สนใจสอบถามรายละเอียดเพิ่มเติมได้ที่
marketing@stream.co.th หรือโทร 0-2679-2233
เรียบเรียงโดย Siripod Surabotsophon
Stream I.T. Consulting Ltd.
