Enterprise phiên bản
Watermark số và nhúng steganographic
Tổng quan nhanh
Phần tiêu đề “Tổng quan nhanh”NextPDF Enterprise nhúng một payload ẩn, đã mã hóa vào một PDF được tạo ra bằng cách thực hiện các điều chỉnh nhỏ, có kiểm soát đối với khoảng cách giữa các cặp chữ. Bạn cung cấp một payload — thường là một mã định danh theo từng người nhận — và một khóa bí mật; bộ mã hóa ghi payload thành các sai lệch không thể nhận biết so với kerning tự nhiên của văn bản. Một bộ giải mã tương ứng, khi được cung cấp cùng khóa đó, sẽ khôi phục payload. Trang này ở mức hành vi: nó nêu rõ bộ mã hóa ghi gì, mật mã nó dùng, và ranh giới của kỹ thuật.
Mục đích sử dụng dự kiến là truy vết rò rỉ tài liệu nội bộ: khi một tài liệu có kiểm soát bị rò rỉ, dấu được khôi phục sẽ nhận diện bản sao của người nhận. Nó không phải là steganography đối kháng và không phải là một bảo đảm về việc sống sót qua xử lý tùy ý.
Các điều kiện tiên quyết được nêu trong front matter và được lặp lại tại Điều kiện tiên quyết.
Tính khả dụng và cấp phép
Phần tiêu đề “Tính khả dụng và cấp phép”Năng lực này đi kèm trong NextPDF Enterprise (nextpdf/enterprise) và được kích hoạt bằng một license envelope cấp Enterprise. Một triển khai không có quyền đó sẽ không nạp các lớp của năng lực này. Năng lực này chạy hoàn toàn trong tiến trình trong khi tạo tài liệu; không có nội dung tài liệu nào rời khỏi host. So sánh các phiên bản và nhận giấy phép.
Năng lực này làm gì
Phần tiêu đề “Năng lực này làm gì”Văn bản PDF được vẽ với một mảng kerning mang theo một điều chỉnh số học giữa các glyph. Bộ mã hóa coi mỗi vị trí điều chỉnh như một vật mang cho vài bit:
- Nó mã hóa payload bằng một thuật toán mã hóa được xác thực kèm dữ liệu liên kết (AEAD) — AES-256-GCM theo mặc định, hoặc ChaCha20-Poly1305. AEAD cung cấp cả tính bảo mật và tính toàn vẹn, nên một vật mang bị giả mạo sẽ thất bại khi giải mã thay vì âm thầm tạo ra một payload sai.
- Nó suy dẫn khóa mã hóa 32 byte từ khóa bí mật của bạn và khóa font bằng Hàm Suy Dẫn Khóa dựa-trên-HMAC (HKDF) với SHA-256. HKDF trích xuất một khóa giả ngẫu nhiên có độ dài cố định từ tài liệu khóa đầu vào, rồi mở rộng nó tới độ dài cần thiết, theo RFC 5869 §2.
- Nó sinh một vector khởi tạo (IV) 12 byte ngẫu nhiên mới cho mỗi lần mã hóa. AES-GCM yêu cầu IV phải duy nhất cho một khóa nhất định, nếu không bảo đảm xác thực sẽ mất, theo NIST SP 800-38D §5.2.1.
- Nó ánh xạ các byte đã mã hóa thành một chuỗi bit và phân phối các bit qua các vị trí cặp-chữ sẵn có, mã hóa một hoặc hai bit cho mỗi vị trí. Sai lệch nó thêm vào kerning tự nhiên được giới hạn bởi một phần có thể cấu hình của em — đủ nhỏ để duy trì sự không thể nhận biết về mặt thị giác.
Bộ giải mã đảo ngược quy trình: nó đọc các điều chỉnh kerning từ một content stream, trừ đi kerning tự nhiên, lượng tử hóa các sai lệch trở lại thành bit, lắp ráp lại blob đã mã hóa, và giải mã nó bằng cùng khóa. Nếu khóa sai hoặc vật mang bị phá hủy, việc giải mã trả về không gì cả thay vì một payload sai.
Dung lượng tỷ lệ thuận với độ dài văn bản: mỗi vị trí cặp-chữ mang một hoặc hai bit, nên một payload phải vừa với các vị trí mà văn bản cung cấp. Bộ mã hóa phát sinh một lỗi tràn có kiểu khi payload vượt quá dung lượng.
Một chế độ tương-thích-PDF/A giảm một nửa sai lệch tối đa để duy trì dưới ngưỡng dung sai chiều rộng của một trình xác thực, đánh đổi dung lượng để lấy sự phù hợp nghiêm ngặt hơn.
Vì sao nó hoạt động theo cách này
Phần tiêu đề “Vì sao nó hoạt động theo cách này”Lựa chọn cốt lõi là giấu dấu trong kerning thay vì trong một lớp phủ hiển thị hay một trường metadata. Một dấu metadata là chuyện tầm thường để tước bỏ, và một dấu đóng hiển thị làm thay đổi trang. Thay vào đó, các sai lệch kerning nằm bên trong văn bản mà người nhận phải giữ lại, và duy trì không thể nhận biết. Mã hóa được xác thực là trụ cột thứ hai: một vật mang bị giả mạo hoặc một phần sẽ thất bại xác thực, nên bộ giải mã trả về không gì cả thay vì một người nhận sai. Khóa được suy dẫn theo từng font bằng HKDF, gắn dấu với ngữ cảnh tài liệu, chứ không phải với một secret chia sẻ trần trụi. Phần công bố trung thực về độ bền theo sau trực tiếp: dấu sống sót qua việc phân phối lại thông thường nhưng không sống sót qua việc cố ý viết lại content stream, nên phạm vi được nêu là truy vết rò rỉ nội bộ, không phải steganography đối kháng.
Bối cảnh thiết kế: Che thông tin không phải là một hình chữ nhật đen.
Điều kiện tiên quyết
Phần tiêu đề “Điều kiện tiên quyết”- Cài đặt NextPDF Core và gói Enterprise, và giữ một giấy phép Enterprise đang hoạt động.
- Tạo tài liệu với một font phơi bày các số đo cặp kerning; bộ mã hóa đọc kerning tự nhiên từ các số đo font.
- Cung cấp khóa bí mật từ trình quản lý secret của bạn, không phải từ mã nguồn. Cùng khóa đó được yêu cầu để giải mã.
- Quyết định độ sâu bit (một hoặc hai bit cho mỗi vị trí) và liệu có cần tương thích PDF/A hay không, dựa trên nhu cầu về dung lượng và sự phù hợp của bạn.
Cấu hình
Phần tiêu đề “Cấu hình”Cấu hình mã hóa là bất biến và được xác thực khi dựng:
- Độ sâu bit — một hoặc hai bit cho mỗi vị trí cặp-chữ. Độ sâu cao hơn cho dung lượng nhiều hơn nhưng sai lệch lớn hơn.
- Tỷ lệ điều chỉnh tối đa — trần sai lệch tính theo một phần của em, trong một khoảng có giới hạn. Giá trị lớn hơn cho nhiều khoảng dư hơn nhưng có nguy cơ về tính hiển thị.
- Mật mã — AES-256-GCM (mặc định) hoặc ChaCha20-Poly1305. Cả hai đều là AEAD.
- Tương thích PDF/A — khi được bật, giảm một nửa sai lệch tối đa hiệu dụng.
Hãy dùng cùng cấu hình cho việc mã hóa và giải mã; một sự không khớp sẽ tạo ra không có payload nào được khôi phục.
Từng bước
Phần tiêu đề “Từng bước”- Đọc khóa bí mật từ trình quản lý secret của bạn.
- Dựng cấu hình mã hóa (độ sâu bit, tỷ lệ sai lệch, mật mã, cờ PDF/A).
- Tính các điều chỉnh kerning cho văn bản bạn sắp render, truyền vào payload, văn bản, khóa font, các số đo font, khóa bí mật, và cấu hình.
- Áp dụng các điều chỉnh được trả về khi bạn ghi đoạn văn bản, để dấu được nhúng trong khi tạo.
- Để truy vết một bản sao bị rò rỉ, chạy bộ giải mã trên content stream của tài liệu nghi vấn với cùng khóa font, các số đo font, khóa bí mật, và cấu hình, rồi đọc payload được khôi phục.
<?php
declare(strict_types=1);
require_once __DIR__ . '/../../vendor/autoload.php';
/** * Reject a payload that cannot fit the carrier text before encoding. * * Each letter-pair position carries $bitDepth bits. Guarding capacity up * front turns an unencodable payload into a clear caller-side error instead * of relying on the encoder's overflow exception alone. * * @param non-empty-string $payload The bytes to embed (already minimal). * @param positive-int $textLength The character count of the carrier text. * @param int<1, 2> $bitDepth Bits encoded per letter-pair position. * * @throws \OverflowException When the payload cannot fit the available positions. */function assertPayloadFits(string $payload, int $textLength, int $bitDepth): void{ $positions = $textLength - 1; $capacityBytes = \intdiv($positions * $bitDepth, 8);
if (\strlen($payload) > $capacityBytes) { throw new \OverflowException(\sprintf( 'Payload of %d bytes exceeds carrier capacity of %d bytes.', \strlen($payload), $capacityBytes, )); }}<?php
declare(strict_types=1);
require_once __DIR__ . '/../../vendor/autoload.php';
use NextPDF\Enterprise\Security\Steganography\SteganographyDecoder;use NextPDF\Enterprise\Security\Steganography\SteganographyConfig;use NextPDF\Typography\FontMetrics;use Psr\Log\LoggerInterface;
final readonly class LeakTracer{ public function __construct(private LoggerInterface $logger) {}
/** * Recover the embedded marker from a suspect document's content stream. * * Decoding returns null on a wrong key or a destroyed carrier rather than * a wrong payload, so the caller treats null as "no marker recovered". * * @param string $contentStream The suspect content-stream bytes. * @param non-empty-string $fontKey The font key used at generation. * @param FontMetrics $metrics Font metrics with kerning pairs. * @param string $secretKey The same secret key used to encode. * @param SteganographyConfig $config The same configuration used to encode. * * @return string|null The recovered marker, or null when none is found. */ public function trace( string $contentStream, string $fontKey, FontMetrics $metrics, string $secretKey, SteganographyConfig $config, ): ?string { $marker = SteganographyDecoder::decodeFromContentStream( $contentStream, $fontKey, $metrics, $secretKey, $config, );
if ($marker === null) { $this->logger->info('No steganographic marker recovered from content stream.'); }
return $marker; }}Xác minh
Phần tiêu đề “Xác minh”- Mã hóa một payload đã biết vào một đoạn văn bản đã biết, rồi giải mã nó trở lại với cùng khóa và cấu hình; xác nhận payload được khôi phục khớp.
- Giải mã với một khóa cố ý sai và xác nhận kết quả là null, không phải một payload sai — đây là bảo đảm toàn vẹn AEAD đang hoạt động.
- Kiểm tra trang đã render và xác nhận thay đổi khoảng cách không hiển hiện về mặt thị giác ở tỷ lệ sai lệch đã cấu hình.
- Khi cần tương thích PDF/A, xác thực đầu ra so với hồ sơ PDF/A của bạn và xác nhận dung sai chiều rộng không bị vượt.
Bảo mật và tuân thủ
Phần tiêu đề “Bảo mật và tuân thủ”- Mã hóa được xác thực. Payload được mã hóa bằng AES-256-GCM hoặc ChaCha20-Poly1305. Một vật mang bị giả mạo hoặc bị cắt cụt sẽ thất bại xác thực khi giải mã; nó không tạo ra một payload sai.
- IV cho mỗi lần mã hóa. Một IV 12 byte ngẫu nhiên mới được sinh cho mỗi lần mã hóa, thỏa mãn yêu cầu duy nhất của AES-GCM theo NIST SP 800-38D §5.2.1.
- Khóa suy dẫn. Khóa mã hóa được suy dẫn bằng HKDF-SHA-256 từ secret của bạn và khóa font (RFC 5869 §2). Hãy giữ secret trong trình quản lý secret của bạn; hãy coi nó như bất kỳ secret ký nào.
- Dấu là nội dung tài liệu. Các byte được nhúng là một phần của nội dung trang, không phải nội dung nhật ký. Đừng ghi payload hay khóa bí mật vào nhật ký.
Trang này liên quan đến việc nhúng mã hóa. Mọi nguồn quy phạm đều được diễn giải lại; không có văn bản quy phạm nào được tái hiện. ### Công bố về độ bền
Dấu được mang trong các điều chỉnh kerning. Nó có thể bị phá hủy bởi việc in và quét lại, bởi các công cụ chuyển đổi PDF, bởi việc tuyến tính hóa lại, hoặc bởi bất kỳ việc viết lại content-stream nào chuẩn hóa kerning. Kỹ thuật này phù hợp nhất cho việc truy vết rò rỉ nội bộ của các tài liệu được phân phối ở dạng được tạo ra của chúng. Nó không phải là steganography đối kháng và không sống sót qua xử lý hạ nguồn tùy ý. Đừng dựa vào nó như biện pháp kiểm soát duy nhất ở nơi mô hình mối đe dọa bao gồm việc cố ý tước bỏ.
Xử lý thất bại
Phần tiêu đề “Xử lý thất bại”- Payload quá lớn. Bộ mã hóa phát sinh một lỗi tràn có kiểu khi payload vượt quá dung lượng văn bản. Hãy rút ngắn payload hoặc kéo dài văn bản vật mang.
- Quá ít văn bản vật mang. Văn bản ngắn hơn hai ký tự không cung cấp vị trí vật mang nào và phát sinh một lỗi.
- Khóa sai khi giải mã. Việc giải mã trả về null. Hãy coi null là “không có dấu nào được khôi phục”, không phải một kết quả một phần.
- Không khớp cấu hình. Việc mã hóa và giải mã phải dùng cùng độ sâu bit, tỷ lệ sai lệch, mật mã, và cờ PDF/A; một sự không khớp sẽ tạo ra không có payload nào được khôi phục.
Ranh giới công bố
Phần tiêu đề “Ranh giới công bố”Trang này chỉ ghi lại hành vi có thể quan sát từ bên ngoài và bề mặt public API được hỗ trợ. Các đường dẫn namespace nội bộ, các lớp trợ giúp, các bảng cơ chế, các tên tệp runbook, và các tiền tố ticket đều nằm ngoài phạm vi.
Xem thêm
Phần tiêu đề “Xem thêm”- Steganography — NextPDF Enterprise — tài liệu tham chiếu API cho bộ mã hóa và bộ giải mã steganographic.
- Security — NextPDF Enterprise — bề mặt bảo mật Enterprise kết hợp.
- Branding — NextPDF Enterprise — watermark hiển thị và dấu đóng trên trang.
- Forensics — NextPDF Enterprise — khám nghiệm tài liệu và truy vết.
- Security — NextPDF Core — bề mặt mã hóa và chữ ký cốt lõi.
- AEAD · HKDF · kerning — các thuật ngữ bảng chú giải.