What your DSC token is actually doing

There is nothing on a DSC token that resembles your signature. No image of your handwriting, no scan of your name, nothing that could be pasted onto a page. What the plastic contains is a small computer with a number on it that it will not tell you, and the whole apparatus exists to keep that number from ever being copied.

Most of the confusion around digital signing comes from the word signature doing two unrelated jobs. One is a mark on a page that a person recognises. The other is a value computed from the bytes of a document and a private key, which a machine checks. They have nothing in common except the name, and the second one is what a token produces.

What is inside the housing

Strip the USB shell off and you have a smart card chip. The key pair was generated on that chip, and the private half was marked non-exportable at the moment it was created. That is not a policy setting in software: there is no command in the device's interface that returns the private key, and recovering it means attacking the hardware.

A private key held this way also cannot be backed up. If the token is lost, the key is gone and a new certificate has to be issued. That is the trade the design makes: no copies means no copies, including yours.

What crosses the cable

Your document does not go to the token. It could not — a smart card chip has neither the memory nor the patience for a forty-page PDF.

The application computes a digest of the byte range being signed, using SHA-256. That digest is a fixed number of bytes regardless of whether the document was a page or a thousand. It is wrapped in the padding the algorithm requires and handed to the token. The token performs the RSA operation with the private key and returns the result. That result, together with your certificate and the chain above it, is packed into a signature object and written into the file.

So the traffic on the USB cable is a hash in and a signature out. The token never learns what it signed, which answers the question of whether a signing device could leak a document. It cannot, because it never had one.

What the PIN is protecting

The PIN authorises one thing: the use of that key, on that device, now. It does not encrypt the document. It does not identify you to anybody remote. It is not a password to a service.

It is checked by the token itself rather than by the software asking for the signature, and the token keeps a retry counter. A few wrong attempts and the key locks, permanently in some configurations, which is why the counter exists — it turns an offline guessing attack on a four-to-eight digit number into something that gets three tries.

This is why the PIN dialog belongs to the token's own driver and looks nothing like the application that triggered it. The application asks the operating system for a signature from a key it does not have; the provider for that device puts up its own prompt; the PIN goes from the prompt to the chip. An application offering a tidy in-house PIN box in its own visual style would be an application that has your PIN.

How Windows gets involved

The token's middleware registers a cryptographic provider with Windows. From then on, while the device is plugged in, its certificate appears in your personal certificate store alongside anything else you have, and Windows routes private-key operations for that certificate to the device.

That is the whole integration, and it is why signing software on Windows generally does not ask you to configure the token at all. It reads the certificate store. If the certificate is not there, the software cannot see it either, and the fix is with the vendor's middleware.

The same store also holds every other certificate you have accumulated, which is the trap. A server certificate somebody installed years ago will sign a PDF perfectly well and is never what anyone meant. So will an expired one, and a signature made with an expired certificate is rejected by whoever checks it.

What a verifier checks, and what it ignores

When a reader says a signature is valid, this is roughly what it did.

1. Read the byte range the signature declares it covers, and recompute the digest over exactly those bytes.
2. Compare that digest against the one inside the signed attributes, and check the signature over those attributes using the public key in the certificate.
3. Build a chain from your certificate up through the intermediates to a root it has been told to trust, and check the dates, the key usage and the constraints at every step.
4. Ask, if it can reach the network, whether any certificate in the chain has been revoked.

Note what is not in that list. The picture is not in that list. The visible signature block on the page — the box with a name in it, a date, sometimes a graphic — is an annotation with an appearance stream, and it can say anything at all. It can carry somebody else's name. It can be present on a document with no signature in it, or absent from a document with a perfectly good one. Nothing checks the drawing against the certificate, because the drawing is decoration and the certificate is the claim.

The word "valid" hides a question

A PDF signature covers a byte range given as two spans: everything before the signature value and everything after it, with a hole in the middle where the value itself sits. The natural assumption is that those two spans add up to the entire file. They do not have to.

A file can be assembled so that the declared range covers only part of it, leaving content that no signature protects. Careful readers report this — some form of "the signature covers only part of the document" — and it is worth reading that message rather than the green tick beside it.

The related case is legitimate. A document signed by one person and then countersigned by a second is not rewritten; the second signature is appended as a new revision, precisely so the first signature still verifies over the bytes it originally covered. An appended revision can, however, change what a page displays. That is why readers distinguish between a document unchanged since signing and one where the later changes were of a permitted kind.

What a timestamp adds

Without one, the signing time in a document is an attribute the signer asserted, taken from the signer's own clock, which the signer controls. It is signed, so it cannot be altered afterwards without breaking the signature, but it was never independently established in the first place.

A timestamp under RFC 3161 fixes that. A time authority receives a hash of your signature value together with a random nonce, and returns a token countersigned with its own key and its own clock. Anyone checking the document later can see that a third party attested this signature already existed by that moment.

The practical value arrives later. Certificates expire, and they are sometimes revoked. Without a trusted time, a verifier looking at your document in three years cannot tell whether you signed while the certificate was valid or afterwards, and the safe assumption is the unhelpful one. With a trusted time it can decide. What crosses the network is the hash and the nonce, never the document or its name, and the authority does see that a request came from your address at that hour and has its own policy about what it keeps.

In Creasepoint the timestamp is off unless you switch it on, no authority is pre-selected, and the offline verification result says plainly that it did not ask anybody about revocation — because asking is a network request, and a signing tool that quietly telephoned a certificate authority on your behalf would be doing something it never told you about.

Revocation is the gap that no offline check closes. A signature can be cryptographically perfect over bytes that have not moved, made with a certificate that was withdrawn the week before. Only the issuer knows that, and only a network request asks.