How signing with a smart card works

The question everyone asks the first time is: if the computer signs the document, does my private key end up in the computer's memory? The answer is no, and that is the entire reason smart cards exist. The key never leaves the card. It is the card that signs.

The fundamental gesture

A signing smart card is not a USB stick. It is a small computer with its own cryptographic processor, holding the private key in memory that is physically unreadable from outside. There is no command, driver or software that can ask it «give me the key»: that command simply does not exist in its firmware.

The command that does exist is a different one: «here is a 32-byte digest, transform it with the key you hold and give me back the result». The card asks for the PIN, performs the operation internally, and hands over the signature. The computer receives a block of signed bytes and has never seen the key.

the computer contract.pdf SHA-256 → 32 bytes assembles the CMS envelope the digest + the PIN the signature inside the smart card cryptographic processor private key unreadable from outside C_Sign(digest) the signing happens in here what crosses the wire → the document's digest → the PIN ← the computed signature ← the public certificate never the private key Not even the document crosses the wire: the card sees 32 bytes of digest and has no idea what it is signing. Which is why you must trust the software computing the digest: the card cannot check it.
The dashed boundary is the security frontier. Everything to its right is inaccessible to the operating system, to drivers, and to any malware.

An uncomfortable corollary, rarely discussed: the card signs what you hand it. If malicious software passed it the digest of a document different from the one on your screen, the card would sign without objection. The key's security is absolute; the security of what you sign depends on the software.

PKCS#11: the lingua franca

For a program to say «sign this digest» to a card from any manufacturer, a common language is needed. That language is PKCS#11, a standard defining a set of functions — including the C_Sign from the diagram — that every card must expose.

What translates from the standard into a particular card's dialect is the middleware: a library the manufacturer ships, to be installed on the computer. Probatio does not talk to the card directly: it looks for middleware already present on the system and queries it.

The automatically recognised modules include Bit4id (the cards of Aruba, InfoCert and many professional bodies), OpenSC, A.E.T. SafeSign, Gemalto/Thales IDPrime, SafeNet eToken, IDEMIA/Oberthur AWP, Athena/ASE and the middleware of the Italian CIE electronic identity card.

If your card uses middleware that is not in the list, the module can be pointed at manually: a .dylib on macOS, a .dll on Windows.

Remote signing, when there is no card

There is an alternative in which the private key lives in a secure device at the service provider, not in your pocket. You sign by authenticating remotely, typically with a password and an OTP code.

The protocol is called CSC (Cloud Signature Consortium) and Probatio supports it. The mechanism is identical: the digest travels out, the signature comes back. Only the key's home changes — and with it the trust model, because a third party is now its custodian.

What you can produce

CAdES-BES attached .p7m envelope signs any file with signingCertificateV2 PAdES-BES a PDF, still a PDF incremental update visible or invisible signature XAdES signed XML ds:Signature node with canonicalisation JAdES JWS token RS256/384/512 only no ECDSA, no Ed25519 + RFC 3161 timestamp (optional) the signature moves from level -BES to level -T Untimestamped, a signature holds while the certificate is valid. Timestamped, it survives the certificate's expiry.
Level -BES is the bare signature. Adding a timestamp raises it to -T and gives it a date that stands up: the difference between a document that ages well and one that does not.

A note on the level names

Probatio labels the signatures it produces and verifies as -BES and -T. That is the nomenclature of the historical ETSI specifications (TS 101 733 for CAdES). The standards currently in force — ETSI EN 319 122-1 for CAdES and EN 319 142-1 for PAdES — call the same levels B-B (basic signature) and B-T (signature with a timestamp), and add two more for long-term preservation, B-LT and B-LTA.

A reader of technical reports will recognise both spellings. If you must cite them, the correct pairing is: «level -T under TS 101 733, corresponding to baseline level B-T of EN 319 122-1».

PAdES and the incremental update

Signing a PDF does not mean rewriting it. Probatio appends a new section at the end of the file, leaving the preceding bytes untouched — the incremental update technique foreseen by the PDF standard. Existing signatures keep verifying, because the intervals they cover were not touched.

That is how two people sign the same contract in sequence, and both signatures remain verifiable.

The procedure, step by step

  1. Insert the card and check the middleware is installed. Probatio lists the certificates it finds on the card.
  2. Pick the right certificate. A card often holds two: one for authentication and one for signing. Only the second carries the nonRepudiation flag, and only it produces a signature that stands up.
  3. Pick the format according to who receives it. CAdES and PAdES are both fully recognised formats. If the recipient or the applicable rules require the .p7m envelope — as happens in Italian court e-filing, in many public-administration procedures and in electronic invoicing — you sign in CAdES, PDF included. Absent such a constraint, PAdES is more convenient on a PDF, because the file stays openable in any reader.
  4. Decide about the timestamp. If the document must survive the certificate's expiry — and it nearly always must — add one.
  5. Enter the PIN. From here on the card does the work.
  6. Verify the result. Reopen the signed file and verify it, as the opposing party would. A signature your own software will not confirm should not be handed over.

Mistakes seen often

  • Signing with the authentication certificate. It technically succeeds; legally it is not a signature. Check nonRepudiation.
  • Forgetting the timestamp. In three years that certificate will have expired, and without a timestamp verification falls back on today's date, with a negative result.
  • Choosing the format without asking who receives it. There is no universally «right» format: a .p7m sent to someone expecting PAdES creates friction, but a PAdES sent to a system demanding the .p7m envelope is rejected outright. The right question is always: what does the recipient require?
  • Locking the PIN. Three wrong attempts and the card locks; you need the PUK. Not Probatio's problem, but it happens to everyone at least once.

From the user's point of view, digitally signing is a gesture of a few seconds. It is worth knowing that in those seconds the most delicate part of the operation happens inside a chip that does not obey you: it merely signs what you hand it, and never surrenders the key. The rest of the trust lives in the software.