การลงนามที่รองรับโดย HSM

Spec: ISO 32000-2, §12.8 Spec: FIPS 140-3 Evidence: Standard-backed

ภาพรวมโดยย่อ

ฮาร์ดแวร์ซีเคียวริตีโมดูล (HSM) ย้ายคีย์การลงนามออกจากกระบวนการของผู้ใช้ไปไว้หลังขอบเขตของอุปกรณ์ที่ลงนามตามคำขอ แต่ไม่เคยส่งคีย์กลับออกมา หน้านี้อธิบายตะเข็บ PKCS#11 ที่ NextPDF ใช้ลงนาม ตำแหน่งที่แน่นอนของเส้นแบ่งคีย์ และส่วนของผลลัพธ์ที่เป็นความรับผิดชอบของเอนจิน ไม่ใช่อุปกรณ์หรือผู้ใช้

เหตุใดเรื่องนี้จึงสำคัญ

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

การกำหนดเส้นแบ่งผิดมีต้นทุนแฝงสูง เวิร์กโฟลว์ที่ ดูเหมือน รองรับด้วยฮาร์ดแวร์แต่โหลดคีย์เข้าหน่วยความจำเพื่อลงนาม มีต้นทุนการดำเนินงานเท่ากับ HSM แต่มีโปรไฟล์ความเสี่ยงเท่ากับคีย์ซอฟต์แวร์ ความแตกต่างนี้มองไม่เห็นจาก PDF ที่เสร็จสมบูรณ์ จึงต้องออกแบบไว้ตั้งแต่ต้นและตรวจสอบให้แน่ใจ ไม่ใช่สันนิษฐานเอง

ฉบับย่อ

มาตรฐาน PKCS#11 กำหนดออบเจ็กต์คีย์ที่ทำเครื่องหมายว่าเป็นความลับและไม่สามารถสกัดออกได้ ค่าส่วนตัวของคีย์ ไม่สามารถเปิดเผยเป็นข้อความธรรมดาภายนอกโทเค็นได้ Spec: PKCS#11, v3.1 §10.9
NextPDF สร้างโครงสร้างลายเซ็น PDF และคอนเทนเนอร์ CMS โดยส่งไบต์ที่จะลงนามข้ามตะเข็บ PKCS#11 และรับลายเซ็นกลับมา คีย์ไม่เคยข้ามตะเข็บนั้น
ตะเข็บเป็นสัญญาที่เสถียร สัญญาเดียวกันนี้รองรับได้ด้วยโทเค็นแบบสมาร์ตการ์ด, USB HSM, HSM แบบเครือข่าย และคลาวด์ KMS โค้ดเอนจินไม่ต้องเปลี่ยนเมื่อเปลี่ยนระหว่างรูปแบบเหล่านี้
NextPDF เป็นซอฟต์แวร์เอนจินการลงนาม การรับประกันระดับฮาร์ดแวร์ของอุปกรณ์ สถานะการตรวจรับรอง นโยบาย PIN และการนำไปใช้งานเป็นสิ่งที่เอนจิน ไม่ รับรอง เอนจินใช้อุปกรณ์ แต่ไม่ได้รับประกันอุปกรณ์นั้น

แนวทางของ NextPDF

ตะเข็บอย่างละเอียด

NextPDF แยก การประกอบลายเซ็น ออกจาก การคำนวณค่าลายเซ็น การประกอบเป็นงานของเอนจิน: วางฟิลด์ลายเซ็น สำรองพื้นที่ในไฟล์ คำนวณช่วงไบต์ และสร้าง CMS SignedData พร้อมแอตทริบิวต์ที่ลงนามแล้ว Spec: ISO 32000-2, §12.8

การคำนวณค่าลายเซ็นถูกมอบหมายออกไป เอนจินกำหนดสัญญาขนาดเล็กสำหรับผู้ให้บริการการลงนาม: รับลำดับไบต์ทึบ (ในทางปฏิบัติคือแอตทริบิวต์ที่ลงนามแล้วซึ่งเข้ารหัสแบบ DER) และส่งคืนออกเท็ตลายเซ็นดิบ สัญญานั้นคือตะเข็บ ความรู้เกี่ยวกับ PDF และ CMS อยู่ด้านหนึ่ง ส่วนคีย์อยู่อีกด้านหนึ่ง ผู้ให้บริการอาจเก็บคีย์นั้นไว้ในกระบวนการกรณีเป็นคีย์ซอฟต์แวร์ในเครื่อง ในคลาวด์ KMS หรือบนโทเค็นฮาร์ดแวร์ผ่าน PKCS#11 โค้ดเอนจินเหนือตะเข็บเหมือนกันทุกกรณี ต่างกันเฉพาะผู้ให้บริการที่อยู่เบื้องหลัง

ตำแหน่งที่แท้จริงของเส้นแบ่ง

PKCS#11 — อินเทอร์เฟซโทเค็นเข้ารหัสลับของ OASIS หรือที่ในอดีตเรียกว่า “Cryptoki” — คืออินเทอร์เฟซ C มาตรฐานสำหรับโทเค็นฮาร์ดแวร์ เส้นทางฮาร์ดแวร์ของ NextPDF สื่อสารผ่าน PKCS#11 (โดยตรง หรือผ่านบริดจ์บรรทัดคำสั่ง OpenSSL สำหรับการนำเอนจิน หรือผู้ให้บริการไปใช้งานที่การเชื่อมโยงภายในกระบวนการไม่สามารถโหลดโทเค็นได้)

ออบเจ็กต์คีย์บนโทเค็นถูกสร้างขึ้นด้วยแอตทริบิวต์สองรายการที่กำหนดเส้นแบ่ง หากคีย์ถูกทำเครื่องหมายว่าเป็นความลับ หรือทำเครื่องหมายว่าไม่สามารถสกัดออกได้ แอตทริบิวต์ส่วนตัวบางอย่าง ไม่สามารถเปิดเผยเป็นข้อความธรรมดาภายนอกโทเค็นได้ Spec: PKCS#11, v3.1 §10.9 ปฏิบัติการลงนามเองเป็นการเรียกโทเค็นชุดเดียว — C_SignInit แล้วตามด้วย C_Sign — ดำเนินการโดยอุปกรณ์ Spec: PKCS#11, v3.1 §5.10 ข้อความธรรมดาที่ NextPDF จัดการสำหรับปฏิบัติการลงนามคือไบต์ที่จะลงนาม สิ่งที่ส่งกลับมาคือลายเซ็นและใบรับรอง คีย์ส่วนตัวไม่อยู่ในเส้นทางใดเลย นั่นคือเส้นแบ่ง และโทเค็นเป็นผู้บังคับใช้ ไม่ใช่ไลบรารี

Step 1 of 4: ISO 32000-2 §12.8 — signature dictionary, ByteRange, Contents
Step 2 of 4: RFC 5652 CMS SignedData — the signature container
Step 4 of 4: FIPS 140-3 / ISO/IEC 19790 cryptographic module assurance (device-level, deployment-dependent)

ตำแหน่งที่ลายเซ็น PDF ที่รองรับด้วยฮาร์ดแวร์ยึดโยงอยู่ ตามลำดับ: ตัวรับส่ง PDF (ISO 32000-2 §12.8) คอนเทนเนอร์ CMS ที่ตัวรับส่งบรรจุ อินเทอร์เฟซโทเค็นที่ NextPDF ลงนามผ่าน (PKCS#11) และมาตรฐานการรับประกันโมดูลที่อธิบาย — แต่ไม่ได้รับประกันด้วยตัวเอง — อุปกรณ์ที่อยู่เบื้องหลัง

หนึ่ง PIN หนึ่งการตรวจสอบสิทธิ์ซ้ำ

PKCS#11 อนุญาตให้กำหนดคีย์ให้ต้องตรวจสอบสิทธิ์ซ้ำทุกครั้งที่ใช้งาน: เมื่อ แอตทริบิวต์ CKA_ALWAYS_AUTHENTICATE ถูกตั้งค่า ผู้ใช้ต้องแสดง PIN อีกครั้งสำหรับปฏิบัติการเข้ารหัสลับ แต่ละครั้ง ไม่ใช่ครั้งเดียวต่อเซสชัน Spec: PKCS#11, v3.1 §10.9 เส้นทาง PKCS#11 ของ NextPDF ถูกออกแบบมาสำหรับกรณีนี้ PIN เป็นพารามิเตอร์ที่อ่อนไหว จะไม่ถูกบันทึกล็อกหรือ ทำให้เป็นอนุกรม เมื่อเซสชันรายงานว่ามีการล็อกอินอยู่แล้ว NextPDF จะคืนค่า ให้กลับสู่สถานะสะอาด เพื่อให้ลายเซ็นถัดไปต้องตรวจ PIN ใหม่ สิ่งนี้สำคัญสำหรับ โทเค็นแบบ PIV ซึ่งนโยบายกำหนดให้ใช้ PIN ต่อหนึ่งลายเซ็น เป็นพฤติกรรมของเอนจิน ที่เคารพนโยบายของอุปกรณ์ ไม่ได้ผ่อนปรนนโยบายนั้น

หลักฐานบอกอะไร

Evidence: Standard-backed คุณสมบัติคีย์ที่ไม่สามารถสกัดออกได้ ไม่ใช่คำกล่าวอ้างของ NextPDF แต่เป็นแบบจำลองของ PKCS#11: ออบเจ็กต์คีย์ที่ CKA_SENSITIVE เป็นจริง หรือ CKA_EXTRACTABLE เป็นเท็จ จะไม่ให้ ค่าส่วนตัวเป็นข้อความธรรมดาภายนอกโทเค็น Spec: PKCS#11, v3.1 §10.9 สิ่งที่ NextPDF สนับสนุนคือการไม่จำเป็นต้องใช้ค่านั้นเลย: ลงนาม ผ่าน ปฏิบัติการ C_Sign ของโทเค็น แทนที่จะขอวัสดุคีย์

Evidence: Standard-backed ด้าน PDF ยึดโยงอยู่กับ Spec: ISO 32000-2, §12.8 ไดเจสต์ของช่วงไบต์ คำนวณจากไฟล์โดยไม่รวมค่าลายเซ็น ค่าลายเซ็น ที่วางไว้ในรายการ Contents คือออบเจ็กต์ CMS SignedData ที่เข้ารหัสแบบ DER สำหรับ ลายเซ็นแบบคีย์สาธารณะ HSM ผลิตเฉพาะออกเท็ตลายเซ็นชั้นในสุดเท่านั้น NextPDF สร้างทุกอย่างรอบๆออกเท็ตเหล่านั้น และเขียนลงในโครงสร้างที่ มาตรฐานกำหนด

Evidence: Standard-backed การรับประกันอุปกรณ์อธิบายไว้โดย Spec: FIPS 140-3 และมาตรฐานพื้นฐาน ISO/IEC 19790 ซึ่ง กำหนดระดับความปลอดภัยเชิงคุณภาพที่เพิ่มขึ้นสี่ระดับ ครอบคลุมพื้นที่ข้อกำหนดสิบเอ็ดด้าน — ตั้งแต่ข้อกำหนดอัลกอริทึมไปจนถึงหลักฐานการงัดแงะทางกายภาพ มาตรฐาน เหล่านี้อธิบายสิ่งที่ โมดูล ต้องตอบสนองเพื่ออ้างระดับใดระดับหนึ่ง มาตรฐานเหล่านี้เป็น คุณสมบัติของอุปกรณ์และการตรวจรับรองของอุปกรณ์ ไม่ใช่ของ NextPDF และ — ตาม ถ้อยคำของ ISO/IEC 19790 เอง — ความสอดคล้องตามมาตรฐาน ไม่เพียงพอด้วยตัวเอง ที่จะ รับประกันว่าโมดูลปลอดภัยในการนำไปใช้งานหนึ่งๆ

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

ตัวอย่างเชิงปฏิบัติ

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

<?php

declare(strict_types=1);

use NextPDF\Contracts\HsmSignerInterface;

/**
 * Sign a PDF where the private key lives on a PKCS#11 token.
 *
 * `$hsm` is a hardware-backed signer. Its sign() delegates to the token;
 * the key never enters this process. Everything that makes the bytes a
 * valid PDF signature — field, byte range, CMS SignedData — is built by
 * the engine around the value the device returns.
 *
 * Token wiring (library path, slot, PIN, key label) is deployment
 * configuration and is intentionally out of scope here: those values are
 * operator-owned secrets, not library inputs to hardcode.
 */
function signWithToken(
    string $pdfPath,
    HsmSignerInterface $hsm,
): string {
    // The engine asks the signer only for: the certificate (to embed in
    // the CMS) and a signature over the bytes it computes. It never asks
    // for, and the contract never exposes, the private key.
    $certificateDer = $hsm->getCertificateDer();
    $chainDer       = $hsm->getCertificateChainDer();

    // Pseudocode for the engine's own assembly step: build the signature
    // dictionary + CMS SignedData, then hand the signed-attributes bytes
    // to $hsm->sign(...) and place the returned octets in /Contents.
    return nextpdf_sign_pdf(
        pdfPath: $pdfPath,
        signer: $hsm,
        certificateDer: $certificateDer,
        chainDer: $chainDer,
    );
}

ข้อสังเกตที่ต้องพูดให้ชัดมีสองประการเกี่ยวกับรูปแบบนี้ การเชื่อมโยง PKCS#11 ภายในกระบวนการเป็นส่วนขยาย PHP แยกต่างหากที่ PHP รุ่นมาตรฐาน ไม่ มีให้ การใช้งานฮาร์ดแวร์ต้องติดตั้งและตรวจสอบส่วนขยายนั้น (หรือใช้บริดจ์บรรทัดคำสั่ง OpenSSL) ให้เป็นส่วนหนึ่งของแพลตฟอร์มตั้งแต่ต้น ไม่ใช่ค่อยทำภายหลัง และอัลกอริทึมที่ขอจากอุปกรณ์ต้องเป็นอัลกอริทึมที่คีย์ทำได้จริง เอนจินจะปฏิเสธตั้งแต่เนิ่นๆเมื่ออัลกอริทึมที่กำหนดค่าไว้ไม่มีการแมปสำหรับผู้ให้บริการที่เลือก แทนที่จะล้มเหลวลึกลงไปในการเรียกโทเค็น

ความเข้าใจผิดที่พบบ่อย

“การใช้ HSM หมายความว่าการลงนามได้รับการตรวจรับรอง FIPS”

ไม่ การสับสนระหว่างสองสิ่งนี้คือกับดัก HSM คือ สถานที่ ที่คีย์อาศัยอยู่และที่ปฏิบัติการถูกดำเนินการ การตรวจรับรอง FIPS 140-3 / ISO/IEC 19790 เป็นคุณสมบัติที่ อุปกรณ์ (หรือการกำหนดค่าโมดูลเฉพาะ) อาจมี ซึ่งกำหนดขึ้นโดยโปรแกรมการตรวจรับรอง — ไม่ใช่สิ่งที่ไลบรารีที่เรียกใช้งานมอบให้ และไม่ใช่สิ่งที่ NextPDF ยืนยันในนามของอุปกรณ์ NextPDF เข้ากันได้กับ การลงนามผ่านอุปกรณ์ PKCS#11 และเส้นทางการลงนามของ NextPDF ได้รับการ ทดสอบกับ โทเค็นที่เป็นตัวแทนของแต่ละหมวด ส่วนการนำไปใช้งานหนึ่งๆจะได้รับการตรวจรับรอง ในระดับโมดูล FIPS หรือไม่นั้นขึ้นอยู่กับฮาร์ดแวร์ ใบรับรองของฮาร์ดแวร์ และวิธีการกำหนดค่าและการใช้งานจริงทั้งหมด ใช้ถ้อยคำให้ตรงกับสิ่งที่มีอยู่จริง

ข้อจำกัดและขอบเขต

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

ความรับผิดชอบของเอนจิน สร้างฟิลด์ลายเซ็น สำรองพื้นที่ คำนวณช่วงไบต์ ประกอบ CMS SignedData เรียกผู้ให้บริการการลงนาม และเขียนลายเซ็นที่ถูกต้องเชิงโครงสร้างตาม Spec: ISO 32000-2, §12.8 เส้นทางฮาร์ดแวร์ของ NextPDF สอดคล้องกับ อินเทอร์เฟซการลงนาม PKCS#11 เพื่อวัตถุประสงค์นี้
ความรับผิดชอบของอุปกรณ์และผู้ปฏิบัติงาน ความทนทานต่อการงัดแงะของฮาร์ดแวร์ สถานะการตรวจรับรอง FIPS 140-3 / ISO/IEC 19790 การสร้างและการดูแลรักษาคีย์ นโยบาย PIN การกำหนดค่าสล็อต เฟิร์มแวร์ และความปลอดภัยทางกายภาพ ไม่มีรายการใดในกลุ่มนี้ที่เอนจินรับรอง
การทดสอบกับไม่ใช่การตรวจรับรอง การที่ NextPDF มี เส้นทางที่ตรวจสอบแล้ว กับหมวดโทเค็นที่เป็นตัวแทน — รูปแบบสมาร์ตการ์ด USB เครือข่าย และคลาวด์ KMS ที่เข้าถึงผ่านสัญญา PKCS#11 เดียวกัน — เป็นคำกล่าวเรื่องความเข้ากันได้ ไม่ใช่การตรวจรับรอง จำนวนโมดูลที่ตรวจรับรองแล้ว หรือข้ออ้างเกี่ยวกับอุปกรณ์เฉพาะของผู้ใช้ แต่อย่างใด หมวดฮาร์ดแวร์ด้านล่างเป็น รูปแบบ การผสานรวมผ่านอินเทอร์เฟซมาตรฐานหนึ่งเดียว ให้ถือว่าเป็น “ตำแหน่งที่ตะเข็บได้รับการทดสอบ” ไม่ใช่การรับประกันสำหรับรุ่นที่ยังไม่ได้ทดสอบด้วยตนเอง
การลงนามแบบโพสต์ควอนตัมยังเป็นการทดลอง ในกรณีที่เอนจินเปิดให้ใช้การลงนามแบบโพสต์ควอนตัมผ่านโทเค็น ฟังก์ชันนั้นเป็นแบบที่ต้องเลือกใช้ มีการควบคุม และตรวจสอบกับม็อก ไม่ใช่เฟิร์มแวร์ HSM แบบโพสต์ควอนตัม แค็ตตาล็อกชุดการเข้ารหัสลับของ PAdES และ AdES ยังไม่ได้รับรองชุดเหล่านั้นสำหรับการเก็บถาวรระยะยาว ไม่ควรถือว่าพร้อมใช้งานในระดับโปรดักชัน

HSM-backed signing via PKCS#11 — edition availability
Edition	Availability
Core	ไม่มีในรุ่นนี้ Core มีเอนจินการลงนามและ ตะเข็บผู้ให้บริการการลงนาม พร้อมผู้ให้บริการคีย์ซอฟต์แวร์ในเครื่อง
Pro	การจัดการคีย์บนคลาวด์ — การลงนามผ่านคีย์ KMS ที่มีการจัดการ — เป็น ความสามารถของ Pro ซึ่งอธิบายในระดับพฤติกรรมเท่านั้น
Enterprise	มีให้ใช้งาน การลงนามด้วยโทเค็นฮาร์ดแวร์ผ่านอินเทอร์เฟซ PKCS#11 (และ บริดจ์บรรทัดคำสั่ง OpenSSL สำหรับการนำ engine/provider ไปใช้งาน) เป็น ความสามารถของ Enterprise การระบุว่ามีให้ใช้งานเป็นคำกล่าวด้านความสามารถ ไม่ใช่ การตรวจรับรองอุปกรณ์หรือการนำไปใช้งานใดๆ

รูปแบบการผสานรวมผ่านอินเทอร์เฟซหนึ่งเดียว

รายการต่อไปนี้คือ รูปแบบ ที่ใช้ทดสอบตะเข็บ PKCS#11 คอลัมน์นี้หมายถึง “การผสานรวมมีลักษณะอย่างไร” ไม่ใช่ “รายการอุปกรณ์ที่ตรวจสอบ ตรวจรับรอง หรือนับจำนวนแล้ว”

รูปแบบการผสานรวม	วิธีการเข้าถึง	เส้นแบ่งคีย์	การรับประกันเป็นคุณสมบัติของ
โทเค็นสมาร์ตการ์ด / PIV	PKCS#11 โมดูล; มักพบ PIN ต่อการใช้งาน	บนการ์ด ไม่สามารถสกัดออกได้	การ์ดและผู้ปฏิบัติงานที่ดูแลการ์ด
USB HSM	PKCS#11 โมดูล	บนอุปกรณ์ ไม่สามารถสกัดออกได้	อุปกรณ์และผู้ปฏิบัติงานที่ดูแลอุปกรณ์
HSM แบบเครือข่าย / แอปพลายแอนซ์	PKCS#11 โมดูลไปยังอุปกรณ์เครือข่าย	บนแอปพลายแอนซ์ ไม่สามารถสกัดออกได้	แอปพลายแอนซ์ การกำหนดค่าของแอปพลายแอนซ์ และผู้ปฏิบัติงาน
คลาวด์ KMS	ผู้ให้บริการคีย์ที่มีการจัดการ (Pro)	อยู่ในบริการคลาวด์ ไม่เคยส่งคืน	ผู้ให้บริการคลาวด์และการรับรองของผู้ให้บริการ
บริดจ์ผู้ให้บริการ OpenSSL	PKCS#11 ผ่านบริดจ์ OpenSSL	บนโทเค็น ไม่สามารถสกัดออกได้	โทเค็นและผู้ปฏิบัติงานของโทเค็น

คำถามที่พบบ่อยฉบับย่อ

คีย์เคยเข้าสู่กระบวนการ PHP หรือไม่ ไม่ สำหรับคีย์ PKCS#11 ที่ไม่สามารถสกัดออกได้ ค่าส่วนตัวไม่สามารถเปิดเผยเป็นข้อความธรรมดาภายนอกโทเค็นได้ NextPDF ลงนามผ่านปฏิบัติการของโทเค็น และเห็นเพียงไบต์ที่จะลงนามกับลายเซ็นที่ส่งกลับมาเท่านั้น

ลายเซ็นที่รองรับด้วย HSM แตกต่างกันภายใน PDF หรือไม่ ไม่ โครงสร้างลายเซ็นเป็น CMS SignedData เดียวกัน ในรายการ Contents เดียวกัน ครอบคลุมช่วงไบต์เดียวกัน HSM เปลี่ยน ตำแหน่งที่การลงนามเกิดขึ้น ไม่ใช่รูปแบบบนดิสก์

ฉันสามารถอ้างความสอดคล้องตาม FIPS ได้หรือไม่เพราะใช้ HSM ผ่าน NextPDF ต้องอ้างอย่างระมัดระวังเท่านั้น NextPDF ไม่ยืนยันสิ่งใดเกี่ยวกับสถานะ FIPS ของอุปกรณ์ คำกล่าวอ้างเช่นนั้นต้องมาจากการตรวจรับรองของอุปกรณ์เองและวิธีการนำไปใช้งาน ไม่ใช่จากข้อเท็จจริงที่ว่า NextPDF เรียกอุปกรณ์นั้น

จะเกิดอะไรขึ้นหากการเชื่อมโยง PKCS#11 ในกระบวนการไม่พร้อมใช้งาน เอนจินจะรายงานว่าการลงนามด้วยฮาร์ดแวร์ไม่พร้อมใช้งาน แทนที่จะย้อนกลับไปใช้คีย์ซอฟต์แวร์อย่างเงียบๆ มีเส้นทางบริดจ์บรรทัดคำสั่ง OpenSSL สำหรับการนำไปใช้งานที่การเชื่อมโยงในกระบวนการไม่สามารถโหลดโทเค็นได้

เอกสารที่เกี่ยวข้อง

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

อภิธานศัพท์

HSM (ฮาร์ดแวร์ซีเคียวริตีโมดูล) — อุปกรณ์ที่เสริมความแข็งแกร่งด้านความปลอดภัยสำหรับเก็บคีย์และดำเนินปฏิบัติการเข้ารหัสลับ เพื่อให้วัสดุคีย์ไม่เคยออกจากอุปกรณ์
PKCS#11 — มาตรฐานอินเทอร์เฟซสำหรับโทเค็นเข้ารหัสลับของ OASIS (ในอดีตเรียกว่า “Cryptoki”) อินเทอร์เฟซ C ที่ NextPDF ใช้เพื่อสื่อสารกับโทเค็นฮาร์ดแวร์
คีย์ที่ไม่สามารถสกัดออกได้ — ออบเจ็กต์คีย์ PKCS#11 ที่ค่าส่วนตัวไม่สามารถเปิดเผยเป็นข้อความธรรมดาภายนอกโทเค็นได้ (CKA_SENSITIVE เป็นจริง หรือ CKA_EXTRACTABLE เป็นเท็จ)
ตะเข็บ — เส้นแบ่งของผู้ให้บริการการลงนามใน NextPDF: ไบต์ทึบเข้า ออกเท็ตลายเซ็นออก ความรู้เกี่ยวกับ PDF และ CMS อยู่เหนือตะเข็บ ส่วนคีย์อยู่หลังตะเข็บ
CMS SignedData — โครงสร้าง Cryptographic Message Syntax (RFC 5652) ที่บรรจุลายเซ็นและใบรับรองไว้ภายใน PDF
FIPS 140-3 / ISO/IEC 19790 — มาตรฐานความปลอดภัยของโมดูลเข้ารหัสลับที่กำหนดระดับเชิงคุณภาพสี่ระดับ เป็นคุณสมบัติของอุปกรณ์และการตรวจรับรองของอุปกรณ์ ไม่ใช่ของไลบรารีที่เรียกใช้งาน