Digital Signature Techniques

When building a system for digitizing records and electronic documents, our team encountered a very practical problem: How can an officer use a USB Token plugged into a computer to sign and approve large PDF files (from 50MB to hundreds of MB) stored on the server?

It sounds simple at first, but once we set out to implement it on a Web platform, it became a genuinely demanding technical challenge.

This article shares how we approached and solved the problem with the Remote Hash-Signing method — fast, lightweight, and fully aligned with information-security standards.

---

1. The Real-World Problem and Three Major Barriers

In a digitization workflow, scanned documents are often very large. When a user wants to digitally sign with a USB Token plugged into their computer, we immediately face three barriers:

1. A web browser cannot read a USB Token: For security reasons, browsers such as Chrome or Edge run in isolation (Sandbox). A web page is never allowed to freely access hardware devices plugged into a USB port.
2. The private key cannot leave the USB Token: The entire legal value of a digital signature resides in the USB Token. The private key is protected inside a hardware chip; no one can copy it or send it to the server.
3. The document is too heavy to download to the workstation: If every signing operation required downloading a 100MB–200MB file from the server to the user’s computer, signing it, and then uploading it back:
   • The network would be very slow, especially when many people sign at the same time.
   • Low-spec computers would stutter, lag, or report out-of-memory errors.
   • Files temporarily stored on personal machines would be easy to misplace or leak.

The goal we set: Officers should only need to work in the browser, the server should keep the document, the USB Token should stay plugged into the workstation — and signing should complete almost instantly with absolute security.

---

2. The Solution Idea: Sign a “Fingerprint” Instead of the Entire File

Fortunately, in cryptography, a digital signature does not require us to process the entire heavy document file.

Instead of signing an entire 100MB document, we only need to create a hash (fingerprint) of that document — with a fixed size of just 32 bytes (about as long as a short message).

This fingerprint is like a “fingerprint”:

• Whether the document is 1 page or 1,000 pages, the fingerprint produced is still only 32 bytes.
• If the document is edited by even a single period, this fingerprint changes completely.
• If you sign this fingerprint, that is equivalent to signing the entire content of the original document.

From this idea, the signing model is split into two halves:

• The large document: Stays on the server.
• Data sent over the network: Only a 32-byte hash sent down to the user’s computer, and a 256-byte signature sent back.

  [Conventional approach]                   [Our approach]
  Download the entire heavy file            Send only the fingerprint string
  ───────────────────────                   ─────────────────────────
  Server ──(100MB file)──► Workstation      Server ──(32-byte hash)──► Workstation
  Workstation ──(100MB file)──► Server      Workstation ──(256B signature)─► Server
     (Slow, prone to network errors)           (Takes less than 1 second)

---

3. How Does the Signing Process Work?

To connect the web browser, the server, and the USB Token smoothly, we built a processing flow of three simple steps:

sequenceDiagram
    autonumber
    actor User as User
    participant App as Helper application (on the workstation)
    participant Server as System server
    participant Storage as Document storage

    Note over User,Server: STEP 1: SERVER PREPARATION
    User->>Server: Click "Sign document" on the web
    Server->>Storage: Open the PDF file to be signed
    Server->>Server: Draw the red seal image & reserve a blank space in the PDF
    Server->>Server: Compute the fingerprint (32 bytes)
    Server-->>App: Send the 32-byte hash to the user's machine

    Note over User,App: STEP 2: SIGN WITH USB TOKEN
    App->>User: Display a prompt asking for the USB Token PIN
    User->>App: Enter the PIN
    App->>App: USB Token signs the 32-byte string (private key never leaves the USB)
    App-->>Server: Send the signature result (256 bytes) to the server

    Note over Server,Storage: STEP 3: SERVER FINALIZATION
    Server->>Server: Embed the signature into the exact blank space reserved in Step 1
    Server->>Storage: Save the completed PDF file
    Server-->>User: Report successful signing on the web screen!

Step 1: The server prepares the document (Pre-Sign)

When the user clicks “Digital sign,” the server will:

• Retrieve the document file and draw a red seal image in advance (with the signer’s name, organization, and signing date/time).
• Reserve a small blank space inside the PDF file as the place to put the signature later.
• Compute the fingerprint (32 bytes) of the document together with the signing time, then send this 32-byte string down to the user’s machine.

Step 2: Sign with the USB Token on the user’s machine

Because a web browser cannot read a USB Token by itself, we developed a small helper application that runs in the background in the computer’s system tray (Local Signer):

• This application receives the 32-byte string from the server.
• It activates the USB Token and displays a window asking the user to enter the PIN.
• When the user enters the correct PIN, the chip on the USB Token signs this 32-byte string and returns a short signature string (256 bytes).
• The private key is kept absolutely safe inside the Token; no one can extract it.

Step 3: The server finalizes the document (Post-Sign)

The application sends the 256-byte signature string back to the server:

• The server places this signature precisely into the blank space reserved in Step 1.
• The PDF file is completed immediately.
• When this file is opened with standard PDF viewers such as Adobe Acrobat, the document displays a valid green checkmark seal, confirming that the document is intact and has not been modified.

---

4. Notable Practical Lessons

While putting the solution into real-world use, we drew three important lessons:

1. What if a document has multiple signers?

A document often must pass through multiple reviewers: Specialist initials ➔ Department head confirms ➔ Director signs and stamps.

If a later signer saves the file in the ordinary way, the file structure changes and invalidates the signatures of earlier signers (PDF software reports: “The document has been modified”).

How to handle it: Use the Incremental Update technique. That means not modifying the old document content, but only appending the new signature to the end of the file. As a result, a document can have as many signatures as needed, and all of them remain valid.

2. Handling the case where a user clicks sign and then... walks away

Sometimes a user clicks the sign button on the web, the server has already prepared the document, but the user changes their mind, shuts down the computer, or unplugs the USB Token.

How to handle it: Set a self-expiring wait time (for example, exactly 5 minutes). If after 5 minutes the server has not received a signature, the system automatically cancels the signing session and frees memory, preventing the server from filling up.

3. How do we sign scanned images and audio recordings?

Not every document is a PDF:

• Scanned images of physical artifacts: The system draws a red seal on the image, then creates a separate accompanying signature file (.p7s) to protect the original image.
• Meeting audio recordings: Nothing may be inserted that would distort the sound. The system only takes the fingerprint of the original audio file and creates an accompanying signature file (.p7s), preserving 100% of the audio quality.

---

5. Results Achieved

By changing the approach, the digital-signature system delivered clear results:

• Extremely fast: Signing completes in less than 1 second, instead of waiting tens of seconds to several minutes to transfer the file back and forth.
• 99% bandwidth savings: Only a few hundred bytes of data travel over the network instead of hundreds of megabytes.
• Absolute security: The private key never leaves the user’s device, fully meeting information-security standards and legal requirements.
• Easy experience: Users only need to plug in a USB Token and operate directly in the web browser, without installing complex office software.

---

Conclusion

Sometimes the solution to a complex problem lies in choosing the right piece of data to process. By separating “the document that must be stored” from “the fingerprint that must be signed,” we thoroughly solved the network-congestion problem while fully preserving the security of hardware digital signatures.

We hope this article offers a useful suggestion for those building digital document-management and electronic approval-signing systems!

---

Shared by the engineering team at BK Hightech.