ข้อควรระวังที่จะกล่าวในบทความนี้คือ ไฟล์ XML ที่ถูกลงลายเซ็นดิจิทัลด้วยใบรับรองอิเล็กทรอนิกส์ จะต้องถูกนำส่งกรมสรรพากรก่อนวันที่หมดอายุของใบรับรองอิเล็กทรอนิกส์ เช่น หากใบรับรองอิเล็กทรอนิกส์หมดอายุวันที่ 31 ม.ค. 2565 และเอกสารใบเสร็จรับเงิน/ใบกำกับภาษี ของเดือน ม.ค. 2565 ที่ถูกลงลายเซ็นดิจิทัลด้วยใบรับรองนี้ จะต้องนำส่งไฟล์ XML ให้กรมสรรพากรก่อนวันที่ 31 ม.ค. 2565 เพราะระบบของกรมสรรพากรจะเช็ควันหมดอายุของใบรับรองอิเล็กทรอนิกส์ที่ลงลายเซ็นดิจิทัลบนไฟล์ XML Show
หากนำส่งไฟล์ XML หลังวันที่หมดอายุของใบรับรองอิเล็กทรอนิกส์ที่ใช้ลงลายเซ็นดิจิทัลบนไฟล์ ระบบ e-Tax Invoice & e-Receipt ของกรมสรรพากรจะไม่ยอมรับไฟล์ XML นี้ วิธีป้องกันปัญหาที่จะเกิดขึ้นนี้ สามารถป้องกันได้โดยขอใบรับรองอิเล็กทรอนิกส์ที่มีอายุการใช้งานนานที่สุด และก่อนที่ใบรับรองอิเล็กทรอนิกส์หมดอายุประมาณ 30-60 วัน ให้ดำเนินการขอใบรับรองอิเล็กทรอนิกส์ใหม่เตรียมไว้ครับ เชื่อว่าทุกคนเคยเซ็นลายมือชื่อลงในเอกสาร ไม่ว่าจะเป็นการเปิดบัญชีธนาคาร หรือลายเซ็นประกอบกับข้อความสำเนาถูกต้องให้กับสำเนาเอกสารต่าง ๆ สำหรับคนที่ไม่ได้มีหน้าที่ ที่จะต้องเซ็นเอกสารบ่อยนักก็คงไม่ได้เป็นปัญหาอะไร แต่ในองค์กรหรือหน่วยงานราชการ ที่มีเอกสารหนา ๆ เป็นปึก ๆ ทุก ๆ เดือน ที่จะต้องลงลายมือชื่อทุกหน้า ก็เป็นอะไรที่ไม่มีใครอยากเสียเวลาทำ คำถามคือ จะดีแค่ไหน ถ้าหาก เราสามารถที่จะลงลายมือชื่อในเอกสาร แบบอิเล็กทรอนิกส์ภายในองค์กรได้? โดยมีคุณสมบัติดังนี้
หลายคนอาจจะยังไม่รู้ว่าประเทศไทย เรามี พ.ร.บ. ว่าด้วยธุรกรรมทางอิเล็กทรอนิกส์ พ.ศ. 2544 ที่แก้ไขเพิ่มเติม (ฉบับที่ 3) พ.ศ. 2562 สรุปเป็นภาษาเข้าใจง่าย ๆ ลายมือชื่ออิเล็กทรอนิกส์ “ตามกฏหมาย” แบ่งออกเป็น 2 ประเภทหลัก ๆ คือ
ในบทความนี้ขอไม่พูดถึง PKI เชิงลึกมากเกินเดี๋ยวจะง่วงนอน ขอนิดเดียวพอ.. PKI ในเรื่องของลายเซ็นดิจิทัล คือ ชื่อเรียกรวม ๆ ของกระบวนการที่ใช้ในการบริหารจัดการกุญแจ และใบรับรองต่าง ๆ ที่ให้ผู้ใช้งานแต่ละคนเอาไว้ (1) เซ็นเอกสารจากเจ้าของลายเซ็นตัวจริง (2) ยืนยันได้ว่าเอกสาร ที่มีคนเซ็นนั้นเป็นลายเซ็นของคน ๆ นั้นจริง ๆ สิ่งที่อยากให้ผู้อ่านได้กลับไปจากการอ่านบทความนี้คือมี คู่มือหรือ Playbook ที่สามารถนำไป Copy & Paste เพื่อทำระบบตัวอย่างแบบใช้ได้จริง (Proof of Concept) เอาไปลองใช้ในองค์กรสำหรับการทำลายเซ็นดิจิทัลให้เอกสารประเภท PDF ที่น่าจะใช้ส่งหากันแล้วติดลายเซ็นมากที่สุด มาตรฐานลายเซ็นดิจิทัลใน PDF (PAdES)ก่อนจะลงวิธีทำ มาทำความคุ้น ๆ คำศัพท์กันก่อนเล็กน้อยว่า ลายเซ็นดิจิทัลด้วยซอฟต์แวร์ ทำได้หลายแบบ ไม่ว่าจะเป็น PGP หรือใช้ กุญแจลับ (Private Key) สร้างลายเซ็นไฟล์ด้วยอัลกอริทึมอย่าง RSA (ใช้โปรแกรม openssl ก็ทำได้) แต่ว่า เหตุผลที่เราน่าจะมาสนใจวิธีการตามมาตรฐาน PAdES ในบทความนี้มากกว่า PGP หรือ RSA ทั่วไปเพราะว่า
นอกจากลายเซ็นดิจิทัลที่ถูกรวมไปในเอกสาร PDF ของผู้ลงลายมือชื่อแล้ว (ไม่ได้แยกออกมาเป็นไฟล์อื่นเหมือนบางมาตรฐาน) ยังมีการเก็บข้อมูลอื่น ๆ ในลายเซ็นรวมไปกับเอกสาร PDF อีก ซึ่งการเซ็นลายเซ็นในกระดาษอาจไม่ได้มีด้วยอย่าง เช่น วัน-เวลาที่เซ็นเอกสาร รวมถึงมีความสามารถในการลงลายเซ็นซ้อน ๆ กันหลายครั้ง (จากคนเดียวกัน หรือต่างคนก็ได้) ตัวอย่างการ เซ็นลายเซ็นดิจิทัลบนเอกสาร PDF ที่เปิดด้วยโปรแกรม Adobe Reader นอกเหนือจากมาตรฐาน PAdES แล้วยังมีมาตรฐานอื่น ๆ ที่ใช้ลงลายเซ็นดิจิทัลได้อีกและอยู่ภายใต้กลุ่มของมาตรฐาน Advanced Electronic Signature (AdES) เดียวกัน เช่น XAdES ไว้ใส่ลายเซ็นใน XML อย่างที่ระบบ e-Tax ของกรมสรรพากรใช้ หรือ CAdES ไว้สร้างไฟล์ลายเซ็นแยกกับเอกสารอื่น ๆ นอกจาก PDF ได้ แต่จะไม่ขอพูดถึง ถ้าใครสนใจไปหาอ่านกันต่อเองโลด ปัจจุบันก็มีผู้ให้บริการแบบเสียเงินสำหรับการสร้างลายเซ็นดิจิทัลมากมาย เช่น ของ Adobe เจ้าของโปรแกรม Adobe Reader เองก็มีเช่นกัน โดยส่วนมากจะเสียค่าใช้จ่ายเป็นต่อจำนวนผู้ใช้งาน โดยบริการประเภทเสียเงินก็จะเข้ามาช่วยจัดการในแง่มุมของ การออกใบรับรอง (Certificate) และชุดกุญแจ ที่สำหรับออกให้ผู้ใช้งานที่จะต้องเซ็นเอกสาร โดยจะประกอบไปด้วยมีข้อมูลที่เรียกว่ากุญแจสาธารณะ (Public Key) และกุญแจลับ (Private Key) ของแต่ละคน โดยบางเจ้าอาจรวมถึง การจัดเก็บและบริหารจัดการเอกสารให้ด้วย แต่ในบทความนี้เราจะมาดู ท่าที่ทำฟรี ไม่ต้องเสียเงิน และเอาไปปรับใช้ได้ง่าย ๆ ในองค์กรกัน ! วิธีการทำระบบลายเซ็นดิจิทัลในองค์กรฟรีด้วย opensslความท้าทายของการทำ “ลายเซ็นดิจิทัล” อย่างหนึ่งคือ เราจะตรวจสอบได้อย่างไรว่า เอกสารที่ถูกเซ็นมานั้น ถูกเซ็นมาด้วยเจ้าของลายเซ็นจริง ๆ วิธีการโดยย่อก็คือ ในลายเซ็นจะมีข้อมูล “ใบรับรองของลายเซ็น” ที่ประกอบด้วย กุญแจสาธารณะ และข้อมูลของเจ้าของลายเซ็นอยู่ เราก็เลยสามารถตรวจสอบได้ว่า ลายเซ็นนั้นเป็นของจริง แต่เดี๋ยวก่อน.. แล้วเราจะมั่นใจได้อย่างไรว่า “ใบรับรองของลายเซ็น” ข้างในลายเซ็นดิจิทัลนั้น เป็นของจริง? ไม่ใช่มีแฮกเกอร์ ที่ออกใบรับรองแล้วใส่ข้อมูลชื่อคนอื่นลงไป มาเซ็นเอกสารนั้น? คำตอบแบบเข้าใจง่าย ๆ ก็คือ ใบรับรองของแต่ละคน จะถูกรับรอง ต่อมาอีกทีโดย หน่วยงานผู้ให้บริการออกใบรับรอง (Root Certificate Authority หรือ Root CA หรือย่อ ๆ ว่า CA) .. ทีนี้กลับไปคำถามเดิมอีกที แต่เดี๋ยวก่อน.. แล้วเราจะมั่นใจได้อย่างไรว่า ใบรับรองของ “ผู้ให้บริการออกใบรับรอง หรือ CA” ที่มารับรองใบรับรองของลายเซ็นในเอกสารนั้นเป็นของจริง? คำตอบ ก็คือในโปรแกรมเปิดเอกสาร PDF อย่าง Adobe Reader จะมีการ ติดตั้ง CA ที่น่าเชื่อถือและตรวจสอบมาแล้วให้ล่วงหน้า ดังนั้น ถ้าใบรับรองของผู้ให้บริการออกใบรับรอง (CA) ใด ที่ Adobe Reader บอกว่าน่าเชื่อถือได้ จึงถือว่าเชื่อถือได้ไปโดยปริยายเป็นค่าเริ่มต้น ซึ่งเจ้าของ CA เองก็จะมีค่าใช้จ่ายในการถูกตรวจสอบอย่างเข้มข้น และนำตัวเองเข้าไปอยู่ในโปรแกรม Adobe Reader และในระบบปฏิบัติการต่าง ๆ เป็นค่าเริ่มต้น ดังนั้น การที่เราจะไปขอ ใบรับรองสำหรับการเซ็นเอกสาร จาก CA โดยทั่วไปจึงเสียเงินนั่นเอง แต่ช้าก่อน ถ้าหาก การทำลายเซ็นดิจิทัลนั้น มีจุดประสงค์เพื่อใช้ภายในองค์กรเป็นหลัก หรือข้ามองค์กร ที่อยู่ภายใต้เงื่อนไขอะไรบางอย่างร่วมกัน เช่น เป็นบริษัทหลัก กับบริษัทลูก หรือบริษัทในเครือ หรือมีข้อตกลงร่วมกัน เราสามารถที่จะออกแบบกระบวนการให้ องค์กรเราสร้าง CA ไว้ใช้เองได้ฟรี ๆ หรือเรียกกันว่า Internal Root CA และให้ พนักงาน ที่จะเซ็นเอกสารดิจิทัล หรือตรวจสอบลายเซ็นดิจิทัล ติดตั้งเจ้า Internal Root CA นี้ลงไปในคอมพิวเตอร์ขององค์กร เราก็จะไม่ต้องเสียค่าใช้จ่าย เพื่อซื้อใบรับรองจาก CA มาเซ็นลายเซ็นดิจิทัลให้เอกสาร แนวทางเดียวกันกับ การเปิดใช้ใบรับรองการเข้ารหัส https ให้เว็บในระบบเครือข่ายภายในขององค์กรด้วย Internal Root CA เป๊ะ ๆ ถ้าใครเคยทำมาก่อน การสร้าง CA อาจซับซ้อน เอ๊ย!! ปลอดภัยได้มากกว่านั้นอีก คือการมี CA ย่อยจาก Root CA มาอีกเรียกว่า Intermediate CA สำหรับให้แต่ละหน่วยงานภายใต้ Root CA นั้น ๆ ออกใบรับรองสำหรับการใช้งานจริงของแต่ละบุคคล ซึ่งจะเรียกว่า Leaf Certificate กระบวนการออกและยืนยันความน่าเชื่อถือของ Root CA, Intermediate CA และ Leaf Certificate จะเป็นไปตามรูป ด้านล่างนี้ คือ Root CA ใหญ่สุด ออก Intermediate CA และ Intermediate CA ออก Leaf Certificate ย่อย ๆ สำหรับการใช้งานจริง ๆ จะสังเกตเห็นว่า Root CA ใส่ลายเซ็นดิจิทัลของตัวเองลงในใบรับรอง (และ Issuer คือตัวเองด้วย) ดังนั้น Root CA ในเชิงเทคนิคแล้วจริง ๆ อาจถือว่าเป็น Self-Signed Certificate คือรับรองให้ตัวเอง ว่าตัวเองน่าเชื่อถือ แต่ในบทความนี้จะขอข้าม Intermediate CA ไปจะมีแค่ Root CA ที่สร้างขึ้นเองภายในองค์กรหรือเรียกรวม ๆ ว่า Internal Root CA และใบรับรองของพนักงานแต่ละคนที่ใช้ในการเซ็นเอกสาร หรือ Leaf Certificate ตามรูปด้านบนนั้นเอง สรุปสิ่งที่จะต้องทำ เพื่อทำให้เกิดลายเซ็นดิจิทัลในบทความนี้ได้ก็จะมี 4 ส่วนได้แก่
มาเริ่มกันเลยดีกว่า 1.สร้าง Internal Root CA ขององค์กรด้วย opensslเราสามารถใช้โปรแกรม openssl ที่มีอยู่ในระบบปฏิบัติการ Linux ทั่วไป ในตัวอย่างนี้จะใช้ MacOS แต่ใน Ubuntu หรือ CentOS ก็ใช้วิธีเดียวกันได้ การสร้าง Internal Root CA มี 2 ขั้นตอนย่อยง่าย ๆ คือ – การสร้าง กุญแจลับ (Private Key) ในรูปแบบ RSA – การสร้าง Internal Root CA จากกุญแจลับ (Private Key) 1.1 การสร้าง กุญแจลับ (Private Key) ในรูปแบบ RSAโดยการใช้คำสั่ง openssl ต่อไปนี้ สร้างไฟล์ ca.key
ถัดจากนั้นจะเป็น 1.2 การสร้าง Internal Root CA จากกุญแจลับ (Private Key)จริง ๆ แล้ว Root CA ก็จะคล้ายกับ (Leaf) Certificate ธรรมดานี่แหละ เป็นไฟล์ Binary ที่อ้างอิงโครงสร้างจากมาตรฐานชื่อว่า X.509 ที่เก็บว่ามีคุณสมบัติเป็นค่าอะไรบ้าง เป็นคู่ ๆ Key/Value แต่จะมีคุณสมบัติที่ต่างกันหลัก ๆ คือการที่เป็น Self-Signed Certificate เป็นคนรับรองให้ตัวเอง ว่าตัวเองนั้นถูกต้อง ในเชิงเทคนิคคือค่า Field ชื่อว่า Issued to (Subject) คนถูกเซ็น กับ Issued by (Issuer) คนเซ็น เป็นคนเดียวกัน ตัวอย่าง Root CA ของเว็บไซต์ที่ใช้ https ก็มีคุณสมบัตินี้เช่นกัน รวมถึงถ้าเป็น มาตรฐาน X.509 รุ่น 3 จะมี Field อันหนึ่งชื่อว่า isCA อยู่ในส่วนที่เรียกว่า Extension Block เอาไว้ตรวจสอบว่า Certificate ใด ๆ เป็น CA หรือเปล่าด้วย (แต่เว็บเบราว์เซอร์หลัก ๆ ไม่แปลใส่มาในรายละเอียด Certificate ให้ อยากเห็นต้อง Hex dump!) โดยทั่วไป Root CA จะมีวันหมดอายุ และมีการกำหนด วันหมดอายุที่ค่อนข้างนานอย่าง 20 ปี (หรือก่อนหน้านั้นถ้าหาก กุญแจลับถูกแฮก) และใช้ในการรับรองให้ CA ลำดับถัดไปเรียกว่า Intermediate CA ที่จะมีอายุน้อยกว่าเช่น 5 ปี และนำ Intermediate CA ไปออกใบรับรองสุดท้าย (Leaf Certificate) ในกรณีนี้คือ ใบรับรองของพนักงานแต่ละคน ที่อาจจะมีอายุน้อยสุดเช่น 1 ปี โดยความน่าเชื่อถือของใบรับรองดิจิทัล จะเป็นการเซ็นรับรองต่อ ๆ กันมาเป็นทอด ๆ อย่าง Root CA รับรองให้ Intermediate CA และจากนั้น Intermediate CA รับรองให้ Leaf Certificate โดยเราจะเรียกการรับรองต่อ ๆ กันมานี้ว่า Chain of Trust (ตามในรูปวงกลมสามวงด้านบนนั่นเอง) คำสั่ง openssl ต่อไปนี้เป็นตัวอย่างที่ใช้ในการสร้าง Root CA จะได้ไฟล์ ca.crt (อายุ 10 ปี)
สุดท้ายแล้วจากขั้นตอนที่ 1 นี้ เราจะได้ไฟล์ชื่อ ca.key (กุญแจลับ) และ ca.crt (ใบรับรอง) ของ Internal Root CA สิ่งสำคัญมาก ๆ ในขั้นตอนนี้คือ ca.key หรือกุญแจลับนั้น ต้องถูกเก็บรักษาไว้อย่างปลอดภัย ไม่ให้บุคคลที่ไม่มีสิทธิ์ล่วงรู้ ถ้าให้ดีคือไม่ควรย้ายออกไปที่ไหน สร้างและเก็บไว้ในเครื่อง ๆ หนึ่งโดยเฉพาะ หรือถ้าให้ดีกว่า เก็บไว้ในระบบบริหารจัดการกุญแจโดยเฉพาะ เช่นซอฟต์แวร์ Secret Vault หรือ Hardware Security Module (HSM) แต่จะไม่ขอพูดถึงในบทความนี้ ขอย้ำแค่ห้ามหายหรือห้ามเอาไปให้ใครที่ไม่ได้รับอนุญาต! 2. สร้าง Private/Public Key ของพนักงานแต่ละคน ด้วย opensslถัดจากที่เรามี Internal Root CA แล้ว (ca.key กับ ca.crt) จากนั้น เราจะนำ Internal Root CA ที่ได้ มาสร้างใบรับรอง (Leaf Certificate) ให้พนักงานแต่ละคน นำไปเซ็นเอกสาร PDF กัน ! โดยมีขั้นตอนดังนี้ – เตรียมไฟล์ cert.ext เก็บข้อมูลเกี่ยวกับใบรับรองที่จะสร้าง – เตรียมไฟล์ create_signing_cert.sh สำหรับสร้างใบรับรอง PKCS#12 (.p12) ของพนักงาน จากตัวอย่างต่อไปนี้เราจะใช้สคริปท์ Bash ง่าย ๆ ชื่อ create_signing_cert.sh ในการสร้างใบรับรองให้พนักงาน 1 คน แต่ในทางปฏิบัติ ผู้อ่านสามารถ เขียนโปรแกรมวนลูปดึงข้อมูลจาก ฐานข้อมูลหรือไฟล์มาสร้าง ใบรับรองให้พนักงานครั้งละจำนวนมาก ๆ ได้เช่นกัน 2.1 เตรียมไฟล์ cert.ext เก็บข้อมูลเกี่ยวกับใบรับรองที่จะสร้างโดยไฟล์นี้จะใช้เก็บค่าที่จะถูกใส่ในใบรับรอง เพื่อบอกซอฟต์แวร์ต่าง ๆ ตอนจังหวะมีการใช้งาน ว่าใบรับรองนี้เอาไว้ใช้งานเกี่ยวกับลายเซ็นดิจิทัล File: cert.ext
2.2 เตรียมไฟล์ create_signing_cert.sh สำหรับสร้างใบรับรอง PKCS#12 (.p12) ของพนักงานขั้นตอนนี้จะซับซ้อนหน่อย โดยจะมีสิ่งต่าง ๆ ในสคริปท์ดังนี้
มาดูโค้ดกันเลยดีกว่า จะได้เห็นภาพมากยิ่งขึ้น File: create_signning_cert.sh
จะได้ผลลัพธ์เป็นไฟล์ PKCS#12 (pichaya_pdf_signing.p12) ดังนี้ สรุปคือไฟล์ tmp.key, tmp.csr และ tmp.crt ใช้แค่ชั่วคราวในขั้นตอนการสร้างไฟล์ PKCS#12 (.p12) ที่สุดท้ายแล้ว พนักงานแต่ละคนจะได้ไฟล์ PKCS#12 (.p12) นี้กลับไปเก็บไว้สำหรับการ เซ็นเอกสาร โดยในไฟล์ PKCS#12 (.p12) จะมี 2 อย่างหลัก ๆ คือ
อ่านแล้วอาจจะดูซับซ้อนหน่อย ๆ ถ้าเขียนเป็นสมการให้เข้าใจง่าย ๆ จะได้เป็น PKCS#12 (.p12) = [tmp.key กุญแจลับของพนักงาน, ใบรับรองพนักงานที่เซ็นรับรองโดย tmp.key กุญแจลับของพนักงาน พร้อมกับ ca.key ใบรับรองขององค์กรแล้ว] + ถูกเข้ารหัสอีกชั้นด้วย Passphrase ดังนั้นไฟล์ PKCS#12 (.p12) กับ Passphrase นี้พนักงานแต่ละคนจะต้องเก็บเป็นความลับมาก ๆ ห้ามหาย ห้ามโดนขโมย และก่อนจะให้ Internal Root CA (ca.key) เซ็นรับรองให้ใบรับรองพนักงานใด ๆ ต้องมีกระบวนการตรวจสอบให้แน่ใจว่า ใบรับรองที่ร้องขอมาให้เซ็น (CSR) นั้น มาจากพนักงานคนนั้นจริง ๆ (ถ้าเซ็นรับรองมั่ว ๆ ก็อาจจะโดนหลอกสร้างใบรับรองจริง ให้แฮกเกอร์ได้) ในขั้นตอนจริง ๆ แบบปลอดภัยสูงสุด เราสามารถให้พนักงานแต่ละคน สร้างกุญแจลับ (tmp.key) กับ CSR (tmp.csr) ของตัวเอง จากนั้นส่งไฟล์ CSR มาให้ ผู้ดูแลระบบ เซ็นรับรอง ออกมาเป็นไฟล์ tmp.crt ส่งกลับคืนพนักงานคนนั้น จากนั้น ให้พนักงานเอาไฟล์ tmp.crt กลับไปยัดลงกล่อง ไฟล์ PKCS#12 (pichaya_pdf_signing.p12) ของตัวเองพร้อมกับ tmp.key ก็จะทำให้ ผู้ดูแลระบบไม่เคยเข้าถึง กุญแจลับของพนักงานแต่ละคนเลย สิ่งที่เราข้ามไปไม่ได้อธิบายในบทความนี้ และผู้อ่านสามารถไปหาอ่านต่อกันเองได้คือ จะทำยังไงถ้าหากไฟล์ PKCS#12 (.p12) ของพนักงานถูกแฮก ขโมยออกไป? (keyword: certificate revocation list, OCSP stapling) ณ จุดนี้สิ่งที่เราได้มาในมือแล้วคือ
ต่อไปเราจะมาดูกระบวนการเซ็นเอกสารและตรวจสอบลายเซ็นกัน! 3. การทำลายเซ็นดิจิทัลจาก Private Key พนักงานใน Adobe Reader3.1 การใช้งานครั้งแรกติดตั้ง Internal Root CAผู้ใช้งานจะต้องดาวน์โหลดและติดตั้งโปรแกรม Adobe Acrobat Reader DC (ต่อไปจะขอเรียกย่อ ๆ ว่า Adobe Reader) ก่อน URL: https://get.adobe.com/uk/reader/ ติ๊กถูกที่ Optional Offers ต่าง ๆ ออกและกดปุ่ม “Download Acrobat Reader” ได้เลย จากนั้นเมื่อเปิดโปรแกรม Adobe Reader ขึ้นมา เนื่องจาก CA ของเราสร้างขึ้นมาเอง ไม่ได้อยู่ใน รายชื่อที่ถูกติดตั้งมาโดยอัตโนมัติของ Adobe Reader ดังนั้น พนักงานในองค์กร ทั้งผู้รับและผู้ส่งไฟล์เอกสาร PDF จะต้องนำไฟล์ ca.crt มาติดตั้งในเครื่อง (ไฟล์นี้เป็นข้อมูลกุญแจสาธารณะไม่เป็นความลับ) ขั้นตอนคือ ในตัวเลือกเมนูด้านบนโปรแกรมไปที่ Edit → Preferences… > เลือก Categories เป็น Signature จากไปที่ Identities & Trusted Certificates แล้วกด More… จากนั้นเลือกเมนู Trusted Certificates และกด ปุ่ม Import > กดปุ่ม Browse เลือกไฟล์ Internal Root CA ที่เราสร้างมา (ca.crt) โดยโปรแกรม Adobe Reader อาจจะเห็นไฟล์นามสกุล .cer เท่านั้นให้เปลี่ยนนามสกุลไฟล์จาก ca.crt เป็น ca.cer ได้เลย จากนั้นกดตามรูปภาพ ตามลำดับ (1) เลือก ชื่อ Internal Root CA -> (2) เลือกเสร็จจะมีรายการ Certificate ขึ้นมาให้เลือก คลิกหนึ่งครั้ง -> (3) กดปุ่ม Trust … -> (4) ติ๊กถูกในช่อง Certified documents -> (5) กดปุ่ม OK -> (6) กดปุ่ม Import กด OK ออกมาจากเมนูการตั้งค่า เป็นอันเสร็จสิ้นการติดตั้ง Internal Root CA ครั้งแรกให้โปรแกรม Adobe Reader ในคอมพิวเตอร์แต่ละเครื่อง 3.2 วิธีการเซ็นเอกสารครั้งแรก ติดตั้งใบรับรองของผู้ใช้งาน PKCS#12 (.p12)เมื่อพนักงาน ได้รับไฟล์เอกสาร PDF ที่จะต้องการเซ็นรับรองการอนุมัติ เปิดในโปรแกรม Adobe Reader จากนั้นไปที่เมนู Tools ด้านบน แล้วเลือก Certificates แถวที่ 2 แล้วกดปุ่ม Open (ถ้าคนไม่ทราบอาจจะเผลอกดผิดไป เลือก Fill & Sign ได้ เพราะเป็นรูปลายเซ็น แต่สำหรับลายเซ็นดิจิทัล ต้องเลือกที่ Certificates) จากนั้นกด Digitally Sign ที่ เมนูด้านบนตรงกลาง และเมาส์เราจะสามารถคลิกและลากกล่องสี่เหลี่ยม บริเวณที่เราต้องการจะ ลงลายเซ็นดิจิทัลได้ สำหรับการเซ็นเอกสารครั้งแรกจะเจอข้อความแบบนี้ จำเป็นจะต้องเพิ่ม ใบรับรองของพนักงานที่เราสร้างก่อนหน้านี้ ให้กดปุ่ม “Configure Digital ID” -> เลือก “Use a Digital ID from a file” -> กด Browse เลือกไฟล์ PKCS#12 (.p12) และใส่ Passphrase กดปุ่ม Continue รัว ๆ จะพบฟังก์ชันของ Adobe Reader ให้เรากด Create และเลือกได้ว่า เราอยากให้ลายเซ็นดิจิทัลของเราแนบไปกับสิ่งที่แสดงในเอกสารเป็นรูปแบบไหน ได้แก่
ส่วนมากแล้วเอกสารเป็นทางการ อาจจะ มีไฟล์รูปลายเซ็นแล้วใช้ ลายเซ็นดิจิทัลเซ็นลงไปที่รูปนั้นในเอกสารอีกทีหนึ่ง เพื่อที่ว่าในกรณีที่ไฟล์ถูกพิมพ์เป็นกระดาษจะได้มีรูปลายเซ็นเราติดไปด้วย แต่ถ้าเป็นเอกสารอิเล็กทรอนิกส์ (.pdf) จะสามารถยืนยันได้ว่ามีการเซ็นลายเซ็นดิจิทัล จากเจ้าของลายเซ็นนั้น ๆ แล้ว (น่าเชื่อถือกว่า) เรียกว่า Backward Compatible เซ็นครั้งเดียวให้รองรับแบบกระดาษได้ด้วยนั่นเอง ในตัวอย่างนี้ขอเลือกเป็น Draw วาดลายเซ็นเองไปก่อน จากนั้นใส่ Passphrase และกด Sign และตั้งชื่อไฟล์ใหม่ แนะนำว่าถ้าเซ็นคนเดียวอาจจะเติมคำว่า _signed ไปต่อท้ายชื่อไฟล์ เช่นจาก doc.pdf เป็น doc_signed.pdf เป็นต้น เพื่อจัดระเบียบเอกสารให้เข้าใจง่าย จากนั้นเมื่อเรากด Sign ครั้งถัด ๆ ไปจะไม่จำเป็นต้องเพิ่มใบรับรองหรือสิ่งที่จะแสดงในเอกสารประกอบกับลายเซ็นดิจิทัลอีกรอบแล้ว สามารถใช้ที่ตั้งค่าไว้ครั้งแรกได้เลย (ถ้าต้องการ) 4. วิธีการตรวจสอบว่าลายเซ็นดิจิทัลนั้น ถูกเซ็นมาโดยเจ้าของลายเซ็นตัวจริงถ้าหาก ผู้รับไฟล์ ได้ติดตั้ง Internal Root CA เรียบร้อย และได้รับไฟล์เอกสาร PDF ที่ถูกเซ็นด้วยลายเซ็นดิจิทัลมานั้น สามารถที่จะตรวจสอบด้วย Adobe Reader ได้ทันทีว่า ลายเซ็นดิจิทัลนั้นถูกเซ็นมาอย่างถูกต้อง จากกุญแจลับของเจ้าของลายเซ็นนั้นจริง ๆ จากเครื่องหมายติ๊กถูกสีเขียว ๆ และข้อความ “Signed and all signatures are valid.” ในทางกลับกัน ถ้าหากเอกสารมีการเซ็นมาโดยลายเซ็นดิจิทัลปลอม ที่สร้างจาก CA ที่เราไม่ได้เชื่อถือ ก็จะรู้ได้ในทันทีอีกเช่นกันจากภาพต่อไปนี้
กรณี ลายเซ็นเกิดปัญหา (ไม่ถูกต้อง) จะเห็นเป็นเครื่องหมายตกใจ พร้อมข้อความ “At least one signature has problems.” ให้ตรวจสอบเอกสารจากผู้ส่งหรือผู้เซ็นใหม่อีกครั้ง อาจโดนปลอมแปลงไปแล้ว! ในเชิงเทคนิคสำหรับชาว Geek แล้ว การรับรองว่าเอกสาร PDF ใด ๆ ตามมาตรฐาน PAdES ถูกเซ็นรับรองมาด้วยลายเซ็นดิจิทัลหรือเปล่านั้น สามารถอ้างอิงได้จากรูปด้านล่างนี้
จะเห็นว่าจากตัวอย่างนี้เราทำหลายอย่างด้วยมือพิมพ์คำสั่ง openssl เองทั้งตอนสร้าง Internal Root CA, สร้างใบรับรองของผู้ใช้งาน และเซ็นเอกสารด้วยลายเซ็นดิจิทัลผ่านโปรแกรม Adobe Reader แต่ในสถานการณ์จริงแล้วนั้น ผู้อ่านสามารถพัฒนาระบบ ขึ้นมาเพื่อเชื่อมต่อกับ Internal Root CA ได้ตัวอย่างเช่น
โดยตัวอย่างโค้ดภาษา Python ต่อไปนี้ ผู้อ่านสามารถนำไปศึกษาและปรับใช้ได้ เป็นกรณีที่ทำฟังก์ชันขึ้นมา สำหรับการรับไฟล์ PDF เข้ามา และนำ ใบรับรองมาสร้างลายเซ็นดิจิทัล ด้วยไฟล์ PKCS#12 (.p12) ว่าเป็นเอกสารที่ออกอย่างถูกต้องโดยองค์กร โดยไม่จำเป็นต้องใช้คนมาเซ็นผ่านโปรแกรม Adobe Reader File: pdf_signer.py
ในบทความนี้ผู้อ่านน่าจะได้รับแนวทางท่าหนึ่ง ที่จะสร้างและนำ Internal Root CA ไปปรับใช้ภายในองค์กร เพื่อการสร้างลายเซ็นดิจิทัล โดยไม่ต้องเสียค่าใช้จ่ายจาก บริการเสียเงินต่าง ๆ ภายใต้เงื่อนไขที่เครื่องคอมพิวเตอร์ของพนักงานในองค์กร จะต้องติดตั้ง Internal Root CA นั้น ๆ ซึ่งโดยทั่วไปแล้ว องค์กรขนาดใหญ่ มักจะมี Internal Root CA ที่ใช้ในการออกใบรับรองให้บริการเว็บที่เข้ารหัส (https) ในเครือข่ายภายในอยู่แล้ว จึงอาจไม่มีความจำเป็นจะต้องติดตั้ง Internal Root CA เพิ่มเติม สิ่งที่ต้องทำเพิ่มเติมคือการสร้างใบรับรองให้พนักงานแต่ละคนและการออกนโยบาย, อบรม, จัดทำวิธีการเซ็นเอกสารด้วยลายเซ็นดิจิทัล หรือพัฒนาระบบอัตโนมัติสำหรับการทำลายเซ็นดิจิทัลให้เอกสาร ที่ออกจากแอปพลิเคชันภายในของบริษัทให้กับคู่ค้าหรือบริษัทในเครือที่มีการติดตั้ง Internal Root CA ดังกล่าวนั้นเอง พิชญะ โมริโมโตหัวหน้าทีมทดสอบเจาะแฮกระบบ (lead penetration tester) ของบริษัท สยามถนัดแฮก, เป็นที่ปรึกษาด้านความปลอดภัยให้หน่วยงานเอกชน, เป็นที่รู้จักกันในฐานะ หนึ่งในแอดมินกลุ่ม 2600 Thailand และเป็นหนึ่งในคนเขียนบทความลงเพจ สอนแฮกเว็บแบบแมว ๆ |