เอกสารอ้างอิง

หน้านี้รวบรวมข้อมูลอ้างอิงที่ใช้ร่วมกันระหว่างวิธีการผสานรวมต่าง ๆ ของบริการลงนามโค้ดระยะไกล sslTrus ได้แก่:

• กฎการนับจำนวนครั้งในการลงนามโค้ด
• โปรโตคอลการประทับเวลา Authenticode และ RFC 3161
• เซิร์ฟเวอร์ประทับเวลาที่ใช้บ่อยสำหรับการลงนามโค้ด
• ข้อควรคำนึงเมื่อเลือกบริการประทับเวลาในสภาพแวดล้อมการใช้งานจริง

การคำนวณจำนวนครั้งในการลงนาม

จำนวนครั้งในการลงนามคำนวณตามการดำเนินการลงนามที่เกิดขึ้นจริง

อธิบายอย่างง่าย:

一个文件成功完成一次签名 = 一次签名次数

จำนวนครั้งในการลงนามไม่ได้คำนวณตามจำนวนไฟล์ซอร์สโค้ด และไม่ได้คำนวณตามการ build หนึ่งครั้ง การแพ็กหนึ่งครั้ง หรือ CI/CD Pipeline หนึ่งครั้ง

ตัวอย่างเช่น:

100 个源代码文件
        ↓
编译生成 1 个 app.exe
        ↓
app.exe 成功签名一次
        ↓
1 次签名

ถ้าการ build หนึ่งครั้งสร้าง:

app.exe
helper.dll
installer.msi

และทั้งสามไฟล์ได้รับการลงนามเรียบร้อยแล้ว ดังนั้น:

签名次数 = 3 次

กฎพื้นฐาน

จำนวนครั้งในการลงนามขึ้นอยู่กับ:

1. ไฟล์หรือออบเจ็กต์ใดบ้างที่ถูกเซ็นในที่สุด
2. แต่ละออบเจ็กต์มีการลงนามสำเร็จจริงกี่ครั้ง
3. ใช้การลงนามผ่านไคลเอนต์ปกติ หรือใช้วิธีการเรียกการลงนามระดับล่าง เช่น KSP, Jarsigner
4. เครื่องมือ Build มีการลงนาม EXE, DLL, โปรแกรมถอนการติดตั้ง หรือแพ็กเกจติดตั้งเพิ่มเติมโดยอัตโนมัติหรือไม่

ออบเจ็กต์ที่มักถูกลงนาม ได้แก่:

• .exe
• .dll
• .msi
• .msp
• .sys
• .cat
• .jar
• โปรแกรมถอนการติดตั้ง เช่น uninstall.exe

ตราบใดที่ออบเจ็กต์ใดลงนามสำเร็จจริงหนึ่งครั้ง ระบบจะนับตามกฎการนับครั้งที่เกี่ยวข้อง

นับเฉพาะเมื่อสำเร็จเท่านั้น

จำนวนครั้งในการลงนามจะเกิดขึ้นเฉพาะเมื่อบริการลงนามโค้ดระยะไกลลงนามสำเร็จเท่านั้น

กรณีต่อไปนี้มักไม่นับ:

• การยืนยันตัวตนล้มเหลว
• พารามิเตอร์ไม่ถูกต้อง
• ใบรับรองไม่พร้อมใช้งาน
• คำขอผ่านเครือข่ายล้มเหลว
• ฝั่งเซิร์ฟเวอร์ไม่ส่งผลการลงนามกลับมาสำเร็จ
• การสอบถามใบรับรอง
• การสอบถามบันทึกการลงนาม
• การตรวจสอบลายเซ็น
• การลบลายเซ็นที่มีอยู่
• การสร้างไฟล์ยืนยัน

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

การประทับเวลาไม่นับแยกต่างหาก

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

ดังนั้น:

การเซ็นโค้ด        → สร้างจำนวนครั้งการเซ็น
การเพิ่ม Timestamp → ไม่สร้างจำนวนครั้งการเซ็นเพิ่มเติม
การตรวจสอบลายเซ็น → ไม่สร้างจำนวนครั้งการเซ็น

การประทับเวลาไม่ว่าจะสำเร็จหรือไม่ จะมีผลเฉพาะผลลัพธ์การประทับเวลาในไฟล์ลายเซ็นสุดท้ายเท่านั้น ไม่ได้หมายความว่ามีการดำเนินการลงนามโค้ดเพิ่มเติมแต่อย่างใด

SignTool CLI

ใช้ sslTrus SignTool CLI:

signtool sign \
  --cert-code CERT_CODE \
  --file app.exe

หากลงนามสำเร็จ:

1 个文件 × 1 次成功签名 = 1 次

ตัวอย่างเช่น:

signtool sign --cert-code CERT_CODE --file app.exe
signtool sign --cert-code CERT_CODE --file helper.dll
signtool sign --cert-code CERT_CODE --file installer.msi

ไฟล์ทั้งสามสำเร็จทั้งหมด:

合计 = 3 次

SignTool CLI การลงนามคู่

หากใช้ SignTool CLI ทั่วไปพร้อมเปิดใช้งานทั้ง SHA-1 และ SHA-2:

signtool sign \
  --cert-code CERT_CODE \
  --file app.exe \
  --sha1=true \
  --sha2=true

การลงนามคู่ด้วย CLI แบบปกติจะคำนวณตามงานลงนามของไคลเอนต์หนึ่งรายการ:

GUI / SignTool CLI 双签 = 1 次

นี่คือจุดที่กระบวนการลงนามของไคลเอนต์ทั่วไปสับสนได้ง่ายที่สุดกับการเรียกใช้การลงนามระดับล่างของ KSP

Windows KSP

KSP คือวิธีการผสานรวม Windows CNG Provider

เมื่อ Microsoft SignTool, MSBuild, Visual Studio, เครื่องมือแพ็กเกจ Electron หรือซอฟต์แวร์ Windows อื่นๆ เรียกใช้การลงนามโค้ดระยะไกลผ่าน KSP การนับจำนวนครั้งจะใกล้เคียงกับ:

底层远程私钥签名调用次数

ตัวอย่าง:

การดำเนินการ	จำนวนครั้งในการลงนาม
ดำเนินการลงนาม SHA256 หนึ่งครั้งกับ app.exe	1 ครั้ง
ดำเนินการ SHA256 ก่อน แล้วเพิ่ม SHA1	2 ครั้ง
ลงนามแยก app.exe, helper.dll, uninstall.exe	3 ครั้ง

ดังนั้น:

SignTool CLI 双签 = 1 次
KSP 双签          = 2 次

หากเครื่องมือดำเนินการลงนามพื้นฐานหลายครั้งกับไฟล์เดียวกัน การลงนามระยะไกลที่สำเร็จในแต่ละครั้งจะถูกนับแยกกัน

CSP

CSP คือ Windows CryptoAPI Provider แบบดั้งเดิม

CSP ถูกเรียกใช้โดย Microsoft SignTool หรือแอปพลิเคชัน Windows อื่นๆ ผ่าน Provider เพื่อเรียกใช้บริการลงนามระยะไกลเช่นเดียวกัน

เมื่อพิจารณาจำนวนครั้งของการลงนาม ควรยึดตามการดำเนินการลงนามด้วยคีย์ส่วนตัวระยะไกลที่เกิดขึ้นจริง

หากเครื่องมือลงนามหลายไฟล์แยกกัน หรือลงนามไฟล์เดียวกันหลายครั้ง ควรนับแยกกัน

Jarsigner

เมื่อใช้ sslTrusJarsigner Provider คำสั่ง jarsigner มาตรฐานจะเรียกใช้บริการลงนามโค้ดระยะไกลในระหว่างกระบวนการลงนาม

โดยทั่วไป:

การดำเนินการ	จำนวนครั้งการลงนาม
ลงนาม app.jar	1 ครั้ง
ลงนาม JAR 3 ไฟล์แยกกัน	3 ครั้ง
ลงนาม JAR เดิมอีกครั้ง	เพิ่มอีก 1 ครั้ง
jarsigner -verify	0 ครั้ง
สร้าง keystore สำหรับการตรวจสอบ	0 ครั้ง

ดังนั้น:

每个 JAR 每次成功完成签名 = 1 次

แพ็กเกจการติดตั้ง

แพ็กเกจการติดตั้งจำเป็นต้องแยกแยะระหว่าง:

1. ไฟล์ปฏิบัติการภายในแพ็กเกจการติดตั้ง
2. ตัวแพ็กเกจการติดตั้งเอง

ตัวอย่างเช่น:

app.exe       → เซ็นชื่อ 1 ครั้ง
installer.msi → เซ็นชื่อ 1 ครั้ง

ดังนั้น:

合计 = 2 次

หากมีไฟล์อื่น ๆ ด้วย:

ไฟล์	ลงนามหรือไม่	จำนวนครั้งที่ลงนาม
app.exe	ใช่	1
helper.dll	ใช่	1
driver.sys	ใช่	1
installer.msi	ใช่	1
รวม		4

จำนวนซอร์สโค้ด ไฟล์ทรัพยากร รูปภาพ หรือไฟล์คอนฟิกที่รวมอยู่ในแพ็กเกจติดตั้งไม่ส่งผลโดยตรงต่อจำนวนครั้งในการลงนาม

ประเด็นสำคัญคือ:

最终到底有哪些产物被实际签名

Electron

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

ออบเจ็กต์ที่พบบ่อย ได้แก่:

• โปรแกรมหลัก .exe
• DLL
• โปรแกรมอัปเดต
• โปรแกรมถอนการติดตั้ง
• แพ็กเกจการติดตั้ง .exe
• MSI
• ไฟล์ปฏิบัติการเสริมอื่น ๆ

ตัวอย่างเช่น:

ผลลัพธ์	จำนวนครั้งที่ลงนาม
MyApp.exe	1
ffmpeg.dll	1
update.exe	1
uninstall.exe	1
MyApp Setup.exe	1
รวม	5

ดังนั้น:

一次 Electron Build ≠ 一次签名

ควรคำนวณตามจำนวนอาร์ติแฟกต์ที่ลงนามจริงและจำนวนครั้งในการลงนามที่ดำเนินการต่ออาร์ติแฟกต์

หาก Electron ใช้ KSP และดำเนินการลงนามสองครั้งกับไฟล์เดียวกัน ไฟล์นั้นอาจทำให้เกิดการลงนามระยะไกลสองครั้งด้วย

การประเมินอย่างรวดเร็ว

เมื่อไม่ทราบว่าการบิลด์หนึ่งครั้งจะทำให้เกิดจำนวนครั้งในการลงนามเท่าใด สามารถตรวจสอบตามลำดับได้ดังนี้:

1. 最终有哪些文件被签名？
2. 每个文件签了几次？
3. 使用的是 SignTool CLI 还是 KSP / Jarsigner？
4. 构建工具有没有自动签额外文件？

สามารถเข้าใจได้ง่าย ๆ ว่า:

签名次数 = 成功完成的签名动作数量之和

ข้อควรระวังเป็นพิเศษ:

GUI / SignTool CLI 双签                = 1 次
KSP 对同一个文件执行两次底层签名       = 2 次
Jarsigner 每个 JAR 每次成功签名         = 1 次
时间戳                               = 0 次
验证签名                             = 0 次

เซิร์ฟเวอร์ประทับเวลา

การลงนามโค้ดมักใช้บริการประทับเวลาร่วมด้วย

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

การลงนามโค้ดมีโปรโตคอลการประทับเวลาที่ใช้กันทั่วไปสองแบบ:

โปรโตคอล	คำอธิบาย
Authenticode	โปรโตคอลการประทับเวลาแบบดั้งเดิมของ Microsoft ใช้เป็นหลักเพื่อความเข้ากันได้กับกระบวนการลงนามโค้ด Windows รุ่นเก่า
RFC 3161	โปรโตคอลการประทับเวลาแบบทั่วไป เหมาะสำหรับสถานการณ์การลงนามโค้ดสมัยใหม่

สถานการณ์การลงนามโค้ดสมัยใหม่มักให้ความสำคัญกับ RFC 3161 ก่อน

RFC 3161

คำขอประทับเวลา RFC 3161 ส่งข้อมูลย่อ (digest) ของข้อมูลที่ต้องการประทับเวลา ไม่ใช่ไฟล์ต้นฉบับ

ขั้นตอนพื้นฐาน:

代码签名
   ↓
计算待时间戳数据摘要
   ↓
发送摘要到 TSA
   ↓
TSA 返回时间戳令牌
   ↓
写入最终签名

โทเค็นการประทับเวลามักประกอบด้วย:

• ไดเจสต์ของข้อมูล
• เวลาที่ออกการประทับเวลา
• นโยบาย TSA
• ลายเซ็นดิจิทัลของ TSA

เซิร์ฟเวอร์การประทับเวลาจะไม่ใช้จำนวนครั้งการลงนามโค้ด sslTrus เพิ่มเติมเนื่องจากการเพิ่มการประทับเวลา

เซิร์ฟเวอร์การประทับเวลาที่ใช้บ่อย

เอนด์พอยต์ต่อไปนี้เหมาะสำหรับสถานการณ์การลงนามโค้ดทั่วไป

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

Microsoft

http://timestamp.acs.microsoft.com

ใช้เป็นหลักสำหรับการประทับเวลา RFC 3161

เหมาะสำหรับเป็นตัวเลือกการประทับเวลาในสถานการณ์การลงนามโค้ดสมัยใหม่ของ Windows

ตัวอย่าง:

--timestamp-rfc3161=http://timestamp.acs.microsoft.com

Microsoft SignTool：

/tr http://timestamp.acs.microsoft.com
/td SHA256

Sectigo

http://timestamp.sectigo.com

รองรับ:

• Authenticode
• RFC 3161

สามารถใช้ได้กับ Windows และเครื่องมือการลงนามโค้ดอื่น ๆ ที่รองรับโปรโตคอลที่เกี่ยวข้อง

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

DigiCert

http://timestamp.digicert.com

รองรับ RFC 3161 สามารถใช้ในสถานการณ์การลงนามโค้ด เช่น Microsoft Authenticode ได้

Certum

http://time.certum.pl

รองรับ:

• Authenticode
• RFC 3161

เอกสารการลงนามโค้ดอย่างเป็นทางการของ Certum ครอบคลุมสถานการณ์การลงนาม Windows และ Java JAR

GlobalSign

http://timestamp.globalsign.com/tsa/r45standard

ปัจจุบัน เอกสารการลงนามโค้ดของ GlobalSign ใช้ที่อยู่ Timestamp ตามมาตรฐาน RFC 3161 นี้

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

SSL.com

http://ts.ssl.com

สนับสนุน RFC 3161 ไม่รองรับโปรโตคอล Authenticode Timestamp แบบดั้งเดิม

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

การเปรียบเทียบเซิร์ฟเวอร์ประทับเวลา

ผู้ให้บริการ	ที่อยู่	Authenticode	RFC 3161
Microsoft	http://timestamp.acs.microsoft.com	ยังไม่ยืนยัน	รองรับ
Sectigo	http://timestamp.sectigo.com	รองรับ	รองรับ
DigiCert	http://timestamp.digicert.com	ยังไม่ยืนยัน	รองรับ
Certum	http://time.certum.pl	รองรับ	รองรับ
GlobalSign	http://timestamp.globalsign.com/tsa/r45standard	ยังไม่ยืนยัน	รองรับ
SSL.com	http://ts.ssl.com	ไม่รองรับ	รองรับ

“รองรับ” ในตารางอธิบายถึงความสามารถของโปรโตคอลที่ได้รับการยืนยันจากเอกสารสาธารณะของผู้ให้บริการที่เกี่ยวข้อง

นโยบายบริการประทับเวลาอาจเปลี่ยนแปลงได้ ควรตรวจสอบเอกสารทางการปัจจุบันของผู้ให้บริการอีกครั้งก่อนกำหนดค่าในระบบจริง

บริการประทับเวลาที่มีข้อจำกัด

เซิร์ฟเวอร์ประทับเวลาบางแห่งแม้ให้บริการ RFC 3161 แต่ไม่สามารถใช้เป็น TSA สาธารณะแบบไม่ระบุตัวตนได้โดยตรง

QuoVadis

ที่อยู่ RFC 3161 สาธารณะ ได้แก่:

http://ts.quovadisglobal.com/eu
http://ts.quovadisglobal.com/ch

บริการนี้กำหนดให้ต้องลงทะเบียน IP ขาออกของผู้เรียกใช้ล่วงหน้า ดังนั้นก่อนเชื่อมต่อจึงจำเป็นต้องดำเนินการอนุญาตที่เกี่ยวข้องให้เสร็จสิ้น

Apple

http://timestamp.apple.com/ts01

เป็นบริการประทับเวลา (Timestamp Service) ที่ใช้ในระบบนิเวศการลงนามโค้ดของ Apple

ไม่ควรนำไปใช้เป็นเซิร์ฟเวอร์ประทับเวลาแบบทั่วไปสำหรับ Windows Authenticode โดยตรง

บริการประทับเวลาประเภททดสอบ

บริการ RFC 3161 สาธารณะบางรายการเหมาะสำหรับการทดสอบโปรโตคอลมากกว่าการนำไปใช้เป็น TSA สำหรับการลงนามโค้ดในระบบจริงโดยตรง

ตัวอย่างเช่น:

https://freetsa.org/tsr

บริการประเภทนี้อาจใช้ใบรับรอง CA และ TSA ของตนเอง

ดังนั้นจึงไม่สามารถสันนิษฐานได้ว่า:

Windows
macOS
Java
其他代码签名验证器

โดยค่าเริ่มต้นจะเชื่อถือสายใบรับรอง (certificate chain) ของ TSA นั้น

สภาพแวดล้อมการใช้งานจริง (Production) ควรใช้แพลตฟอร์มเป้าหมายตรวจสอบลายเซ็นที่เกิดขึ้นจริง

การตรวจสอบในสภาพแวดล้อมการใช้งานจริง

ก่อนเพิ่มเซิร์ฟเวอร์ประทับเวลา (Timestamp Server) เข้าในการกำหนดค่าการใช้งานจริง อย่างน้อยควรยืนยันว่า:

1. เอกสารทางการของผู้ให้บริการระบุเอนด์พอยต์ (endpoint) นี้อย่างชัดเจน
2. ผู้ให้บริการรองรับโปรโตคอลการประทับเวลาที่ต้องการอย่างชัดเจน
3. ใช้อัลกอริทึมไดเจสต์การประทับเวลาแบบ SHA-256 หรือแข็งแกร่งกว่า
4. ระบบเป้าหมายสามารถตรวจสอบสายใบรับรองทั้งหมดของ TSA ได้
5. DNS, พร็อกซี, ไฟร์วอลล์ และเครือข่ายขาออกสามารถเข้าถึง TSA ได้อย่างเสถียร
6. ยืนยันวิธีการยืนยันตัวตน ขีดจำกัดอัตราการเรียกใช้ ข้อจำกัดด้านภูมิภาค และข้อกำหนดการให้บริการแล้ว
7. ใช้ผลิตภัณฑ์ลายเซ็นที่เกิดขึ้นจริงทำการทดสอบการตรวจสอบลายเซ็นครบถ้วนแล้ว

อย่าพึ่งพาเพียง:

浏览器可以打开
HTTP 返回 200

ตรวจสอบว่าเซิร์ฟเวอร์ประทับเวลาเหมาะสมสำหรับการลงนามโค้ดหรือไม่

ต้องใช้เครื่องมือลงนามจริงส่งคำขอประทับเวลา และตรวจสอบผลลัพธ์สุดท้าย

คำแนะนำในการเลือกการประทับเวลา

สำหรับการลงนามโค้ด SHA-2 บน Windows สมัยใหม่ โดยทั่วไปควรเลือกใช้บริการประทับเวลาที่รองรับ RFC 3161 เป็นลำดับแรก

ตัวอย่างเช่น:

Microsoft
Sectigo
DigiCert
Certum
GlobalSign

การตัดสินใจขั้นสุดท้ายควรพิจารณาอย่างครอบคลุมดังนี้:

• ระบบปฏิบัติการเป้าหมาย
• เครื่องมือลงนาม
• ห่วงโซ่ใบรับรอง TSA
• ความสามารถในการเข้าถึงเครือข่าย
• ข้อจำกัดตามภูมิภาค
• ข้อจำกัดความถี่ในการเรียกใช้
• ข้อกำหนดในการให้บริการ
• ข้อตกลงระดับการให้บริการ
• ผลการตรวจสอบผลิตภัณฑ์ที่ลงนามจริง

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

วิธีการผสานรวมที่เกี่ยวข้อง

วิธีการผสานรวมที่แตกต่างกันจะใช้จำนวนการลงนามและกฎการประทับเวลาในหน้านี้:

สถานการณ์การใช้งาน	เอกสาร
SignTool CLI	เครื่องมือไคลเอนต์
Windows KSP / CSP	Windows Provider
Jarsigner	การผสานรวม Java
GitHub Actions, Electron Builder, Advanced Installer	CI/CD และเครื่องมือสร้าง
เรียกใช้อินเทอร์เฟซการลงนามระยะไกลโดยตรง	การผสานรวม API