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

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

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

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

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

ความเข้าใจโดยย่อ:

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

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

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

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

ถ้าการบิลด์หนึ่งครั้งสร้างผลลัพธ์:

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 หรือการประมวลผลขั้นถัดไป การลงนามระยะไกลที่เสร็จสมบูรณ์แล้วจะยังคงถูกนับเป็นการลงนามที่สำเร็จ

Timestamp ไม่นับแยกต่างหาก

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

ดังนั้น:

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

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

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

เมื่อใช้ Provider sslTrusJarsigner คำสั่ง 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 และทำการลงนามคู่ (dual sign) กับไฟล์เดียวกัน ไฟล์นั้นอาจทำให้เกิดการลงนามระยะไกลสองครั้งด้วย

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

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

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 ดั้งเดิม

หากเครื่องมือลงนามเป้าหมายหรือระบบเดิมมีข้อจำกัดด้านความเข้ากันได้กับอัลกอริทึมคีย์ที่ 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

เป็นบริการประทับเวลาแบบ RFC 3161 ซึ่งเป็นส่วนหนึ่งของระบบนิเวศการลงนามโค้ดของ Apple

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

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

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

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

https://freetsa.org/tsr

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

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

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

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

สภาพแวดล้อมการใช้งานจริงควรตรวจสอบลายเซ็นด้วยแพลตฟอร์มเป้าหมายจริง

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

ก่อนเพิ่มเซิร์ฟเวอร์ timestamp ลงในการกำหนดค่าการใช้งานจริง อย่างน้อยควรยืนยันว่า:

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

อย่าพิจารณาเพียงจาก:

浏览器可以打开
HTTP 返回 200

判断ว่า Timestamp Server เหมาะสมสำหรับการลงนามโค้ดหรือไม่

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

คำแนะนำในการเลือก Timestamp

สำหรับการลงนามโค้ด SHA-2 บน Windows สมัยใหม่ โดยทั่วไปควรเลือกใช้บริการ timestamp ที่รองรับ 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