ความปลอดภัย

ภาพรวมโดยสังเขป

NextPDF Pro เพิ่มพื้นผิวความปลอดภัยไว้บน NextPDF Core ได้แก่ การปิดบังเนื้อหาในเวลาสร้าง การตรวจจับ PII ในชั้นข้อความ กลยุทธ์การลงนามแบบ remote และ cloud-KMS และการลงนามตามลำดับแบบหลายฝ่าย NextPDF Core ผลิตระดับ PAdES B-B และ B-T ส่วน Pro ผลิตระดับเดียวกันและเพิ่มเวิร์กโฟลว์การลงนามเหล่านี้ไว้บนระดับดังกล่าว (สำหรับ B-T คือลายเซ็น B-B พร้อม RFC 3161 signature-time-stamp หนึ่งรายการบนค่าลายเซ็น) หน้านี้อยู่ในระดับพฤติกรรม โดยระบุว่าแต่ละส่วนทำอะไร ไม่ทำอะไร และขอบเขตของ Enterprise เริ่มต้นที่ใด

ความพร้อมใช้งานและการให้สิทธิ์ใช้งาน

ความสามารถนี้จัดส่งใน NextPDF Pro (nextpdf/pro) และเปิดใช้งานด้วยซองสิทธิ์การใช้งานระดับ Pro การปรับใช้ที่ไม่มีสิทธิ์นั้นจะไม่โหลดคลาสของความสามารถนี้ เปรียบเทียบรุ่นและรับสิทธิ์การใช้งาน

Core จัดส่งตัวลงนาม CMS แบบซอฟต์แวร์ ไคลเอนต์การประทับเวลา RFC 3161 การตรวจสอบเส้นทาง RFC 5280 และการตรวจสอบการเพิกถอนด้วย OCSP และ CRL Pro เพิ่มการปิดบัง การตรวจจับ PII และเวิร์กโฟลว์การลงนามแบบ remote/cloud-KMS/ตามลำดับ เวิร์กโฟลว์เหล่านั้นผลิตระดับ B-B และ B-T เดียวกันของ Core ผ่าน stack RFC 3161 ของ Core (สำหรับ B-T คือ signature-time-stamp หนึ่งรายการบนค่าลายเซ็น) การปรับใช้ที่ไม่มีสิทธิ์ Pro ที่ใช้งานอยู่จะไม่โหลดคลาสเหล่านี้ สัญญาการลงนามของ Core ยังคงทำงานได้โดยไม่เปลี่ยนแปลง

การติดตั้ง

composer require nextpdf/pro:^3

ภาพรวมเชิงแนวคิด

เอนจินการปิดบังใช้รายการกฎที่มีลำดับกับข้อความก่อนที่หน้าจะถูกเขียน กฎแต่ละข้อ match expression แบบ regular กฎจะแทนที่ match ในหนึ่งในสามวิธี ได้แก่ การเติม black-box ที่ลบข้อความออกจาก content stream, run ของเครื่องหมายดอกจันที่มีจำนวนอักขระเท่ากัน หรือป้ายกำกับตายตัวเช่น [REDACTED] เอนจินลบ text object ที่อยู่เบื้องล่างสำหรับโหมด black-box ตามที่ได้ทดสอบไว้ มันไม่ยืนยันว่าพบเนื้อหาอ่อนไหวทุกรูปแบบ การตรวจจับขึ้นอยู่กับกฎที่คุณกำหนดค่า

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

พื้นผิวการลงนามเพิ่มเวิร์กโฟลว์แบบ remote และ asynchronous ไว้บนตัวลงนามของ Core เซสชันคำนวณ digest ของเอกสาร สร้างแอตทริบิวต์ที่ลงนามแล้วของ CMS และส่งไบต์ของแอตทริบิวต์ที่ลงนามแล้วให้กลยุทธ์การลงนาม กลยุทธ์อาจเป็น cloud KMS, ตัวลงนามภายนอกแบบ deferred หรือเส้นทาง ingest ที่ห่อหุ้มลายเซ็น CAdES หรือ XAdES ที่มีอยู่แล้ว จากนั้นเซสชันจะประกอบ CMS SignedData และจัดเก็บแบบเข้ารหัส DER ในรายการ Contents ของพจนานุกรมลายเซ็น — ISO 32000-2 §12.8.1 SignerInfo พกแอตทริบิวต์ที่ลงนามแล้ว content-type และ message-digest ส่วนกระบวนการคำนวณ message digest คือ RFC 5652 §5.4 ผู้ตรวจสอบต้องไม่พึ่งพา digest ที่ผู้สร้างคำนวณ แต่คำนวณ digest ของเนื้อหาใหม่อย่างอิสระและเปรียบเทียบกับแอตทริบิวต์ message-digest การเปรียบเทียบต้องตรงกันลายเซ็นจึงจะถูกต้อง — RFC 5652 §5.6 กระบวนการตรวจสอบลายเซ็น

NextPDF Core ผลิตระดับ PAdES B-B และ B-T ส่วน NextPDF Pro ผลิตระดับเดียวกันและเพิ่มเวิร์กโฟลว์การลงนามของตนไว้บนระดับดังกล่าว สำหรับ B-B เซสชันประกอบ CMS SignedData ด้วยชุดแอตทริบิวต์ที่ลงนามแล้วของ B-B และไม่ใช้การประทับเวลา สำหรับ B-T เซสชันจะเพิ่ม RFC 3161 signature-time-stamp หนึ่งรายการพอดีเป็นแอตทริบิวต์ CMS แบบ unsigned บนค่าลายเซ็น กล่าวคือ signature-time-stamp เป็นแอตทริบิวต์ที่ไม่ลงนามซึ่งบรรจุโทเค็นการประทับเวลาหนึ่งรายการที่คำนวณบนค่าลายเซ็นดิจิทัลสำหรับผู้ลงนาม — ETSI EN 319 122-1 §5.3 และ MessageImprint ของมันเป็น hash ของค่าฟิลด์ลายเซ็นใน SignerInfo ที่ระบุด้วย OID id-aa-timeStampToken — RFC 3161 Appendix A genTime ของการประทับเวลาคือเวลา UTC ที่สร้างโทเค็น — RFC 3161 §2.4.2 เนื่องจากการประทับเวลาเป็นแอตทริบิวต์ที่ไม่ลงนาม digest ที่ลงนามแล้วของ B-B, ค่าลายเซ็นของ SignerInfo และ /ByteRange ของ PDF จึงไม่เปลี่ยนแปลง มีเพียง CMS ที่ขยายขึ้น โทเค็น RFC 3161 ได้มาจากผู้ให้บริการการประทับเวลาที่กำหนดค่าไว้ (ไคลเอนต์ RFC 3161 ของ Core ที่เป็นค่าเริ่มต้น หรือผู้ให้บริการที่ผู้เรียกใช้จัดหา) B-T ใช้ message imprint แบบ SHA-256 ในเส้นทางผู้ให้บริการเริ่มต้น NextPDF Pro นำการรองรับการลงนาม PAdES B-T มาใช้ตาม ETSI EN 319 122-1 §5.3, RFC 3161, RFC 5652 และ RFC 5816 สิ่งนี้ได้รับการตรวจสอบด้วย fixture NextPDF Pro ไม่ อ้างการรับรอง ETSI EN 319 142-1 อิสระ และไม่อ้างความถูกต้องทางกฎหมายของเอกสาร B-LT และ B-LTA เพิ่ม Document Security Store และการประทับเวลาเอกสารสำหรับการตรวจสอบความถูกต้องเพื่อการเก็บถาวรระยะยาว — ETSI EN 319 142-2 §5.5 ระดับเหล่านั้นเป็นความสามารถของ Enterprise (nextpdf/enterprise) และไม่ถูกผลิตโดย Pro ดูขอบเขตของ Enterprise ด้านล่าง

เหตุใดจึงทำงานเช่นนี้

พื้นผิวการลงนามส่งไบต์ของแอตทริบิวต์ที่ลงนามแล้วให้กับ SigningStrategy แทนที่จะถือครองคีย์ส่วนตัว การตัดสินใจข้อเดียวนั้นเป็นตัวรับน้ำหนัก cloud KMS, ตัวลงนามภายนอกแบบ deferred หรือเส้นทาง ingest แบบ CAdES/XAdES ต่างก็เป็นไปตามสัญญาเดียวกัน ดังนั้นโค้ดที่เรียกใช้จึงเหมือนเดิมและคีย์แมทีเรียลไม่เคยเข้าสู่ NextPDF การแยกเซสชันออกเป็น RemoteSigningSession::prepare() และ RemoteSigningSession::complete() ทำให้ลายเซ็นถูกคืนกลับมาแบบ asynchronous ได้ เพราะ digest ถูกกำหนดตายตัวก่อนที่จะเข้าถึงคีย์ การประทับเวลาถูกแนบเป็นแอตทริบิวต์ CMS แบบ unsigned ดังนั้น B-T จึงยังคงเป็นการเพิ่มเติม digest ที่ลงนามแล้วของ B-B, ค่าลายเซ็นของ SignerInfo และ /ByteRange ไม่ถูกแตะต้อง ทุกรอยต่อเป็นแบบ fail-closed เพราะเส้นทางการลงนามที่ลดระดับลงอย่างเงียบ ๆ ย่อมแย่กว่าเส้นทางที่หยุด ภูมิหลังการออกแบบ: Signing at scale, without compromise

พื้นผิว API

Type	Kind	Role	Stability	Since
RemoteSigningSession	class	เซสชันการลงนามแบบ remote หรือ asynchronous สองเฟส	stable	1.9.0
RemoteSigningConfig	class	การกำหนดค่าเซสชันแบบ immutable รวมถึงระดับ PAdES	stable	1.9.0
SequentialSigner	class	การลงนามตามลำดับแบบหลายฝ่ายพร้อมการรองรับ DocMDP	stable	1.9.0
SigningStrategy	interface	สัญญากลไกการลงนามที่เซสชันเรียกใช้	stable	1.9.0
PadesWrapper	class	ห่อหุ้มลายเซ็น CAdES หรือ XAdES ที่มีอยู่แล้วเพื่อฝังแบบ PAdES	stable	1.9.0
KmsSignerInterface	interface (SPI)	สัญญา driver ของ HSM และ KMS จากบุคคลที่สาม	stable	2.1.0
GenerationTimeMasker	class	การปิดบังที่ขับเคลื่อนด้วยกฎ ใช้ก่อนที่หน้าจะถูกเขียน	stable	1.9.0
MaskingConfig / MaskingRule / MaskingMode	types	การกำหนดค่าการปิดบัง กฎ และโหมดการแทนที่	stable	1.9.0

RemoteSigningConfig พกฟิลด์ระดับ PAdES ซึ่ง enum ของมันคือ SignatureLevel ของ Core เส้นทางการลงนามของ Pro ผลิตระดับพื้นฐาน B-B และระดับ B-T ให้กำหนดค่า RemoteSigningConfig::default()->withLevel(SignatureLevel::PAdES_B_T) (หรือใช้ SequentialSigner::withTimestamping()) และให้ผู้ให้บริการการประทับเวลา แล้วเซสชันจะเพิ่มแอตทริบิวต์ที่ไม่ลงนาม RFC 3161 signature-time-stamp พื้นที่ /Contents ที่จองไว้สำหรับ B-T ถูกเพิ่มอัตโนมัติเพื่อให้โทเค็นพอดี พื้นที่ที่กำหนดค่าไว้เล็กเกินไปจะ fail closed พร้อมข้อผิดพลาดการกำหนดค่าที่มีชนิดแทนที่จะตัดทอน ระดับที่สูงกว่า B-T ที่พกไว้ในการกำหนดค่า (B-LT หรือ B-LTA) เป็นค่าที่ประกาศไว้ล่วงหน้าซึ่ง Pro ไม่ได้ดำเนินการกับมัน ตัวสร้างแบบระยะยาวนั้น resolve ในขณะรันไทม์ผ่านสัญญาของ Core และจัดส่งมาในแพ็กเกจ nextpdf/enterprise

ตัวอย่างโค้ด — เริ่มต้นอย่างรวดเร็ว

Sign with a cloud-KMS strategy

<?php

declare(strict_types=1);

require_once __DIR__ . '/vendor/autoload.php';

use NextPDF\Pro\Security\Signing\RemoteSigningSession;
use NextPDF\Pro\Security\Signing\SigningStrategy;

/**
 * Produce a signed PDF using any signing strategy.
 *
 * @param string          $pdfWithPlaceholder PDF bytes with a signature placeholder.
 * @param SigningStrategy  $strategy           A cloud-KMS, deferred, or ingest strategy.
 *
 * @return string The signed PDF bytes.
 */
function signWithStrategy(string $pdfWithPlaceholder, SigningStrategy $strategy): string
{
    $session = RemoteSigningSession::create($pdfWithPlaceholder);

    $session->prepare(
        certDer: $strategy->getCertificateDer(),
        chainDer: $strategy->getCertificateChainDer(),
        algorithmOid: $strategy->getSignatureAlgorithmOid(),
        digestAlgorithm: $strategy->getDigestAlgorithm(),
        contentsHexStart: 0,
        contentsHexEnd: 0,
    );

    return $session->complete($strategy);
}

ผู้เรียกใช้ขึ้นอยู่กับสัญญา SigningStrategy กลยุทธ์ cloud-KMS และกลยุทธ์ ingest แบบ CAdES ต่างก็ satisfy สัญญานี้ ดังนั้นโค้ดนี้จึงไม่เปลี่ยนระหว่างกลยุทธ์ต่าง ๆ

ตัวอย่างโค้ด — การใช้งานจริง

Multi-party sequential signing with audit logging

<?php

declare(strict_types=1);

require_once __DIR__ . '/vendor/autoload.php';

use NextPDF\Pro\Security\Signing\SequentialSigner;
use NextPDF\Pro\Security\Signing\SigningStrategy;
use Psr\Log\LoggerInterface;

final readonly class ApprovalWorkflow
{
    public function __construct(private LoggerInterface $logger) {}

    /**
     * Sign a PDF with two parties in sequence.
     *
     * @param string          $pdfData   The PDF bytes to sign.
     * @param SigningStrategy  $approver  The first-party strategy.
     * @param SigningStrategy  $reviewer  The second-party strategy.
     *
     * @return string The signed PDF bytes.
     */
    public function run(string $pdfData, SigningStrategy $approver, SigningStrategy $reviewer): string
    {
        try {
            $result = SequentialSigner::create($pdfData)
                ->addSigner($approver, 'Approver', reason: 'Approved')
                ->addSigner($reviewer, 'Reviewer', reason: 'Reviewed')
                ->sign();

            $this->logger->info('Sequential signing complete', [
                'signatures' => $result->signatureCount,
            ]);

            return $result->pdfData;
        } catch (\Throwable $e) {
            $this->logger->error('Sequential signing failed', ['error' => $e->getMessage()]);

            throw $e;
        }
    }
}

ผู้ลงนามแต่ละรายเป็น incremental revision แยกกัน บล็อก catch บันทึกและ rethrow มันไม่กลืนความล้มเหลว ซึ่งทำให้เส้นทางการลงนามคง fail-closed ไว้

กรณีขอบและข้อควรระวัง

• ลายเซ็นที่ผลิตขึ้นไม่ใช่ลายเซ็นที่ผ่านการตรวจสอบ การตรวจสอบเส้นทางทำงานที่ฝ่ายตรวจสอบด้วย trust anchor ของฝ่ายตรวจสอบนั้น — RFC 5280 §6.1 ฝ่ายผู้ผลิตไม่สามารถยืนยันผลลัพธ์ได้
• การตรวจจับของการปิดบังขึ้นอยู่กับกฎที่กำหนดค่าไว้ ชุดกฎที่ไม่ match ค่าใดจะไม่ปิดบังค่านั้น เอนจินไม่ยืนยันว่าพบเนื้อหาอ่อนไหวทั้งหมด
• การตรวจจับ PII เป็นเฉพาะชั้นข้อความเท่านั้น หน้าที่สแกนแล้วซึ่งไม่มีชั้นข้อความจะไม่ให้ match ใด เครื่องมือไม่เขียนทับ glyph ที่เรนเดอร์บนหน้า
• โครงสร้าง CMS ต้องพอดีกับพื้นที่ Contents ที่จองไว้ B-B SignedData ที่มีห่วงโซ่ใบรับรองครบถ้วนมีขนาดหนึ่ง ให้กำหนดขนาดพื้นที่ที่จองไว้ให้เหมาะสม มิฉะนั้นเซสชันจะยกข้อผิดพลาด overflow
• กลยุทธ์ cloud-KMS ขึ้นอยู่กับความสามารถในการเข้าถึงเครือข่ายและความพร้อมใช้งานของผู้ให้บริการ ข้อผิดพลาดด้านเครือข่ายหรือผู้ให้บริการจะยกข้อยกเว้นที่มีชนิด เซสชันจะไม่ผลิตเอกสารที่ไม่ลงนามอย่างเงียบ ๆ
• OCSP unknown ไม่ใช่ good ให้ถือ unknown เป็นการไม่สามารถตัดสินได้ — RFC 6960 §2.2

ประสิทธิภาพ

ลายเซ็นแบบซอฟต์แวร์ใช้เวลาในระดับมิลลิวินาทีหลักเดียว ลายเซ็น cloud-KMS เพิ่มการรับส่งข้อมูลไปกลับทางเครือข่ายหนึ่งรอบไปยังผู้ให้บริการ ลายเซ็น B-T เพิ่มการรับส่งข้อมูลไปกลับหนึ่งรอบไปยังผู้ให้บริการการประทับเวลาที่กำหนดค่าไว้บนการดำเนินการลงนาม งบประมาณ wall 1500 ms ครอบคลุมลายเซ็น B-B หนึ่งรายการกับผู้ให้บริการ remote บนการเชื่อมต่อแบบอุ่น ต้นทุนการปิดบังปรับขนาดตามจำนวนกฎและความยาวของข้อความ โปรไฟล์ความสามารถในการทำซ้ำได้คือ structural แอตทริบิวต์ที่ลงนามแล้วของ B-B ฝังเวลาของการลงนาม และลายเซ็น B-T ฝังโทเค็นการประทับเวลาเพิ่มเติม ดังนั้นการรันสองครั้งจะต่างกันในไบต์ของ signing-time และการประทับเวลา แต่โครงสร้างที่ลงนามแล้วเหมือนกัน

บันทึกด้านความปลอดภัย

นี่คือขอบเขตเชิงการเข้ารหัสลับ ดังนั้นแบบจำลองภัยคุกคามจึงชัดเจน byte range ถูกคำนวณโดยเอนจินและไม่เคยรับมาจากผู้เรียกใช้ เส้นทางการลงนามเป็น fail-closed กล่าวคือ ความล้มเหลวของไพรมิทีฟหรือช่องว่างด้านความสามารถจะยกข้อยกเว้นที่มีชนิดและไม่เคยลดระดับลงเป็นอัลกอริทึมที่อ่อนแอกว่าอย่างเงียบ ๆ กลยุทธ์ cloud-KMS เป็นจุดผสานรวม ไม่ใช่ที่เก็บคีย์ การปกป้องคีย์ขึ้นอยู่กับการจัดการคีย์ KMS ที่กำหนดค่าไว้ และการปรับใช้ NextPDF Pro ไม่ถือครองคีย์ส่วนตัวสำหรับกลยุทธ์ KMS Pro ทำงานในโหมดที่เข้ากันได้กับ FIPS เมื่อกำหนดค่าให้ใช้ KMS หรือ HSM ที่ผ่านการตรวจรับรอง FIPS NextPDF Pro เองไม่ใช่โมดูลการเข้ารหัสลับที่ผ่านการตรวจรับรอง FIPS หน้านี้เกี่ยวข้องกับการลงนามเชิงการเข้ารหัสลับ ทุกซอร์สเชิงบรรทัดฐานถูกถอดความ และไม่มีซอร์สใดถูกทำซ้ำ

ที่ตั้งข้อมูลและการลดทอน PII

พื้นผิวการปิดบังและ PII ทำงานในกระบวนการ ไม่มีเนื้อหาเอกสารออกจากโฮสต์สำหรับการปิดบังหรือการตรวจจับ PII กลยุทธ์ cloud-KMS ส่ง digest ของแอตทริบิวต์ที่ลงนามแล้ว ไม่ใช่เอกสาร ไปยังผู้ให้บริการสำหรับการดำเนินการลงนาม การตรวจจับ PII เป็นการ match รูปแบบบนชนิดที่กำหนดค่าไว้ และลบ text object ที่อยู่เบื้องล่างสำหรับโหมด black-box ตามที่ได้ทดสอบไว้ มันไม่ใช่การรับประกันการลบข้อมูลส่วนบุคคลอย่างสมบูรณ์และไม่ใช่คำแถลงด้านการปฏิบัติตามกฎระเบียบ

การวัดและส่งข้อมูลที่ปลอดภัยและการล้างข้อมูลในบันทึก

ไลบรารียกข้อยกเว้นที่มีชนิดพร้อมข้อความเชิงโครงสร้าง มันไม่เขียนเนื้อหาเอกสารหรือค่า PII ที่ตรวจพบลงในข้อความข้อยกเว้นหรือบันทึก การปรับใช้ที่บันทึกรอบ ๆ เส้นทางการลงนามควรบันทึกฟิลด์เชิงโครงสร้างที่แสดงในตัวอย่างการใช้งานจริง ไม่ใช่ไบต์ของเอกสาร

พฤติกรรมในโหมด FIPS

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

ขอบเขตของ Enterprise

NextPDF Pro ผลิตระดับพื้นฐาน B-B และระดับ B-T B-T เพิ่ม RFC 3161 signature-time-stamp หนึ่งรายการเป็นแอตทริบิวต์ CMS แบบ unsigned บนค่าลายเซ็น ที่คำนวณบนค่าลายเซ็นดิจิทัลสำหรับผู้ลงนาม — ETSI EN 319 122-1 §5.3 NextPDF Pro นำสิ่งนี้มาใช้ตาม ETSI EN 319 122-1 §5.3, RFC 3161, RFC 5652 และ RFC 5816 มันได้รับการตรวจสอบด้วย fixture NextPDF Pro ไม่อ้างการรับรอง ETSI EN 319 142-1 อิสระ และไม่อ้างความถูกต้องทางกฎหมายของเอกสาร

ระดับ B-LT และ B-LTA เป็นความสามารถของ Enterprise และ ไม่ ถูกผลิตโดย Pro B-LT และ B-LTA เพิ่ม Document Security Store และการประทับเวลาเอกสารสำหรับการตรวจสอบความถูกต้องเพื่อการเก็บถาวรระยะยาว — ETSI EN 319 142-2 §5.5 การกำหนดค่าที่ร้องขอ Document Security Store หรือลูปการเก็บถาวรระยะยาวจะ resolve ตัวสร้างนั้นในขณะรันไทม์ผ่านสัญญาของ Core ตัวสร้างนั้นจัดส่งมาในแพ็กเกจ nextpdf/enterprise ในการปรับใช้แบบ Pro เท่านั้น การร้องขอ B-LT หรือ B-LTA จะ fail closed พร้อมข้อความที่ระบุชื่อส่วนประกอบ Enterprise ที่ขาดหายไป Pro ไม่ผลิต Document Security Store, พจนานุกรม VRI, การประทับเวลาเอกสาร หรือลูปการเก็บถาวรใด ๆ และไม่กล่าวอ้างการตรวจสอบความถูกต้องแบบระยะยาว (LTV) การเก็บรักษาคีย์ในฮาร์ดแวร์ผ่าน PKCS#11 และโปรไฟล์นโยบายการเข้ารหัส FIPS 140-3 ก็เป็นความสามารถของ Enterprise เช่นกัน

ระดับ PAdES	เพิ่ม	รุ่นที่ผลิต
B-B	ลายเซ็น CMS พร้อมแอตทริบิวต์ที่ลงนามแล้ว	Core, Pro, Enterprise
B-T	แอตทริบิวต์ที่ไม่ลงนาม RFC 3161 signature-time-stamp หนึ่งรายการบนค่าลายเซ็น	Core, Pro, Enterprise
B-LT	Document Security Store พร้อมแมทีเรียลการตรวจสอบความถูกต้อง	Enterprise (nextpdf/enterprise)
B-LTA	การประทับเวลาเอกสารสำหรับความถูกต้องเพื่อการเก็บถาวร	Enterprise (nextpdf/enterprise)

สัญญาพฤติกรรม

• การปิดบังใช้กฎที่กำหนดค่าไว้ก่อนที่หน้าจะถูกเขียน และลบ text object ที่อยู่เบื้องล่างสำหรับโหมด black-box ตามที่ได้ทดสอบไว้
• การตรวจจับ PII สกัดชั้นข้อความ ใช้รูปแบบที่กำหนดค่าไว้ และคืนมุมมองที่ปิดบังแล้วและจำนวน match มันไม่เขียนทับ glyph ที่เรนเดอร์
• การลงนามแบบ remote มีสองเฟส prepare คำนวณ digest และสร้างแอตทริบิวต์ที่ลงนามแล้ว complete ประกอบ CMS และฝังมัน
• Pro ผลิตระดับพื้นฐาน B-B และระดับ B-T สำหรับ B-T เซสชันเพิ่ม RFC 3161 signature-time-stamp หนึ่งรายการเป็นแอตทริบิวต์ CMS แบบ unsigned บนค่าลายเซ็น digest ที่ลงนามแล้วของ B-B และ /ByteRange ไม่เปลี่ยนแปลง คำขอ B-T ที่ไม่มีผู้ให้บริการการประทับเวลา หรือมีพื้นที่ Contents ที่กำหนดค่าไว้เล็กเกินไป จะ fail closed พร้อมข้อผิดพลาดการกำหนดค่าที่มีชนิด คำขอ B-LT หรือ B-LTA โดยไม่มีแพ็กเกจ Enterprise จะ fail closed พร้อมข้อผิดพลาดที่ระบุชื่อ
• กลยุทธ์ cloud-KMS รับ digest ของแอตทริบิวต์ที่ลงนามแล้ว ไม่ใช่เอกสาร และคืนไบต์ลายเซ็นดิบ

ความสอดคล้องกับมาตรฐาน

ข้อกล่าวอ้าง	มาตรฐาน	ข้อ
ลายเซ็น CMS ถูกจัดเก็บแบบเข้ารหัส DER ในรายการ Contents ของพจนานุกรมลายเซ็น	ISO 32000-2	§12.8.1
กระบวนการคำนวณ message digest แอตทริบิวต์ที่ลงนามแล้วพก content-type และ message-digest	RFC 5652	§5.4
ผู้ตรวจสอบต้องไม่พึ่งพา digest ที่ผู้สร้างคำนวณ แต่คำนวณใหม่อย่างอิสระและเปรียบเทียบ (กระบวนการตรวจสอบลายเซ็น)	RFC 5652	§5.6
PAdES B-T signature-time-stamp เป็นแอตทริบิวต์ที่ไม่ลงนามซึ่งบรรจุโทเค็นการประทับเวลาหนึ่งรายการที่คำนวณบนค่าลายเซ็นดิจิทัลสำหรับผู้ลงนาม (Pro ผลิต B-T)	ETSI EN 319 122-1	§5.3
โทเค็น id-aa-timeStampToken ของ signature-time-stamp มี MessageImprint เป็น hash ของค่าฟิลด์ลายเซ็นใน SignerInfo	RFC 3161	Appendix A
ในฝั่งการตรวจสอบ NextPDF ผูก MessageImprint ของ signature-time-stamp เข้ากับค่าลายเซ็นใน SignerInfo และ fail closed เมื่อไม่ตรงกัน โทเค็นขาดหายไป/ซ้ำซ้อน หรือ imprint แบบ SHA-1 (การตรวจสอบแบบเข้มงวด ไม่ใช่การรับรอง)	RFC 3161	Appendix A
โทเค็นการประทับเวลา B-T พก genTime แบบ UTC ซึ่งเป็นเวลาที่สร้างโทเค็น	RFC 3161	§2.4.2
การตรวจสอบเส้นทางการรับรองตรวจสอบ basic constraint และอินพุตเส้นทางไปยัง trust anchor	RFC 5280	§6.1
OCSP รายงาน certStatus เป็น good, revoked หรือ unknown	RFC 6960	§2.2
B-LT และ B-LTA เพิ่ม Document Security Store และการประทับเวลาเอกสารสำหรับการตรวจสอบความถูกต้องแบบระยะยาว (ขอบเขต Enterprise)	ETSI EN 319 142-2	§5.5

ทุกข้อกำหนดเป็นการถอดความ NextPDF ไม่ได้ทำซ้ำข้อความเชิงบรรทัดฐาน โปรดดูมาตรฐานที่เผยแพร่เพื่อถ้อยคำที่เป็นทางการ NextPDF Pro นำการรองรับการลงนาม PAdES B-T มาใช้ตาม ETSI EN 319 122-1 §5.3 (signature-time-stamp), RFC 3161, RFC 5652 และ RFC 5816 และได้รับการตรวจสอบด้วย fixture ส่วน ETSI EN 319 142-1 (ส่วนระดับพื้นฐานของ PAdES) อยู่นอกชุดหลักฐานที่อ้างอิง ดังนั้น NextPDF Pro จึง ไม่ อ้างการรับรอง ความสอดคล้อง หรือการปฏิบัติตาม ETSI EN 319 142-1 อิสระ และไม่อ้างความถูกต้องทางกฎหมายของเอกสาร หน้านี้ระบุโครงสร้างที่ผลิตขึ้น มาตรฐานที่การรองรับ B-T นำมาใช้ และขอบเขต B-LT/B-LTA ของ Enterprise ไม่ใช่ระดับความสอดคล้องที่ได้รับการรับรอง

ขอบเขตการเผยแพร่

หน้านี้บันทึกเฉพาะพฤติกรรมที่สังเกตได้จากภายนอกและพื้นผิว API สาธารณะที่รองรับเท่านั้น เส้นทาง namespace ภายใน คลาสตัวช่วย ตารางกลไก ชื่อไฟล์ runbook และคำนำหน้าหมายเลข ticket อยู่นอกขอบเขต

ดูเพิ่มเติม

• Security — Deep Reference — การอ้างอิงเชิงลึกสำหรับพื้นผิวความปลอดภัยของ Pro นี้
• Core signing — ตัวลงนาม CMS, การประทับเวลา RFC 3161, การตรวจสอบเส้นทาง RFC 5280, OCSP และ CRL
• PAdES clause map — B-B, B-T, B-LT, B-LTA ในแต่ละรุ่น
• NextPDF Pro — พื้นผิวฟีเจอร์ทั้งหมดของ Pro
• Core security — การเข้ารหัสและพื้นผิวลายเซ็นที่กว้างขึ้น
• CMS · PAdES · RFC 3161 timestamp · KMS · DSS — คำศัพท์ในอภิธานศัพท์