Qualified electronic signatures: your smartphone as the key

AI-generated, human-reviewed

27/09/2026 · eudi-wallet

Signing a contract digitally with full legal effect takes a qualified electronic signature (QES). It is legally equivalent to a handwritten signature, but cumbersome: an account with a trust service provider, identification by online ID or video ident, then signing through their portal. The key sits in the provider’s data centre. With the EUDI Wallet, your own phone can become the key. We have already built this into id-call.eu; here is how the signature ends up in the PDF.

What changes with eIDAS 2.0

The revised eIDAS Regulation (EU 2024/1183) requires every member state to provide its citizens with an EUDI Wallet. One mandatory feature: natural persons can use it to create qualified electronic signatures free of charge, at least for non-professional purposes. In Germany, the state wallet d-you launches on 2 January 2027; according to the federal government, the signing feature is to follow during 2027. Our overview of EUDI Wallet integration covers the timeline and the integration side.

The phone as a cryptographic key

Every digital signature rests on a key pair: the private key signs, the public key verifies. What matters is where the private key lives and who can reach it.

Modern smartphones have a dedicated security chip for this: the Secure Enclave on the iPhone, StrongBox on Android. A key generated there never leaves the chip, not even for a backup. The chip signs only after a fresh biometric confirmation. In our iOS app the key is also bound to the currently enrolled Face ID data: if someone enrols an additional face, the key becomes unusable.

The Face ID confirmation is also the declaration of intent: you see the document, confirm, and only then does the chip compute.

Who vouches that the key is yours?

A key on its own says nothing about who holds it. A certificate makes that link: a certification authority signs a statement that this public key belongs to Erika Mustermann. For a QES, that authority must be a qualified trust service provider listed on the EU trusted list.

This is also where we need to be candid: no qualified trust service provider certifies keys held in a smartphone’s security chip yet. Whether wallet signatures will ultimately use such a local key or a remote signing module at the provider is not finally settled in the European architecture. We built the local variant because it keeps the key with the person.

How we simulate the process today in id-call.eu

In id-call.eu, our video call with identity from the wallet, participants can sign documents together. With the iOS app, it works like this:

sequenceDiagram
    participant W as EUDI Wallet
    participant A as id-call app
    participant C as Security chip
    participant S as id-call server (demo CA)
    W->>S: Present ID data (PID) in the call
    A->>C: Sign certificate request
    C-->>A: Face ID, then signature
    A->>S: Certificate request (public key only)
    S-->>A: Certificate in the name from the PID
    A->>C: Sign document
    C-->>A: Face ID, then signature
    A->>A: Embed signature in the PDF

1. Identity: the participant presents their digital ID (PID) from the wallet during the call. The server verifies it.
2. Certificate: the app creates a certificate request and has the chip sign it (first Face ID prompt). The server issues the certificate in the name from the verified PID, not whatever name the request contains.
3. Signature: each document takes exactly one more Face ID prompt.

The document travels end-to-end encrypted between participants; the server never sees it.

What is real today and what is simulated:

The demo CA plays the role a qualified provider will take later. Every certificate carries “DEMO, nicht rechtsgültig” (demo, not legally valid) in its name, and the interface says so visibly.

Browser participants can sign with their phone: after scanning a QR code, the phone receives the complete PDF, not just a hash, and renders every page itself. A phone that signs a hash handed to it by the browser would sign whatever the browser claims.

How the signature gets into the PDF

A PDF signature is not a stamp image on the page but a block of data inside the file. So that later signatures don’t break earlier ones, the file is never rewritten, only extended: each signature appends a new section at the end (an incremental update).

A real example produced with the id-call code; the appended section contains this signature object (shortened):

5 0 obj
<<
/Type /Sig
/Filter /Adobe.PPKLite
/SubFilter /ETSI.CAdES.detached
/ByteRange [0 619 33389 750]
/Contents <308205ad06092a864886f70d010702a082059e3082059a…0000>
/M (D:20260927173216Z)
/Name (Erika Mustermann)
>>

This is how it comes about:

1. Reserve space: the object is first written with a gap in /Contents, 16,384 bytes of room, as hexadecimal zeros.
2. Define the byte ranges: /ByteRange states what gets signed: 619 bytes from position 0, then 750 bytes from position 33,389. The gap lies exactly in between.
3. Compute the fingerprint: a SHA-256 hash is calculated over these bytes, a digital fingerprint that changes completely with any modification. In the example it is 206dd4e7…e78d29.
4. Sign: the hash goes, together with a reference to the certificate, into a small bundle of signed attributes. The chip signs this bundle, not the document itself.
5. Embed: signature, signed attributes and certificate chain form a CMS container (a standardised signature format). It is written hex-encoded into the gap; the rest stays padded with zeros.

ETSI.CAdES.detached declares that the signature follows the European PAdES standard. Our signatures meet its baseline level B-B. The signing time in /M is only a claim by the signing device. A reliable point in time requires a qualified timestamp (level B-T); see our article on court-proof evidence preservation.

Check it yourself

Any signature can be verified without our software. This Python script cuts the signed bytes and the signature container out of the PDF:

import hashlib, re

pdf = open("contract-signed.pdf", "rb").read()
a, b, c, d = map(int, re.search(rb"/ByteRange\s*\[\s*(\d+) (\d+) (\d+) (\d+)", pdf).groups())

signed = pdf[a:a + b] + pdf[c:c + d]              # everything except the gap
open("signed-bytes.bin", "wb").write(signed)
print("SHA-256:", hashlib.sha256(signed).hexdigest())

raw = bytes.fromhex(pdf[a + b + 1:c - 1].decode())  # hex between < and >
length = 4 + int.from_bytes(raw[2:4], "big")         # DER header 30 82 LL LL
open("signature.p7s", "wb").write(raw[:length])      # the rest is zero padding

OpenSSL then checks two things separately:

# 1. Does the signature match the bytes? (certificate chain skipped)
openssl cms -verify -binary -inform DER -in signature.p7s \
  -content signed-bytes.bin -noverify -out /dev/null
# → CMS Verification successful

# 2. Is the issuer trusted?
openssl cms -verify -binary -inform DER -in signature.p7s \
  -content signed-bytes.bin -out /dev/null
# → Verify error: self-signed certificate in certificate chain

That is the crux: mathematically the signature is sound and the document provably unchanged. Legally it only counts once the issuer can be traced to a trusted authority.

Verifying in Acrobat Reader

Acrobat Reader draws the same line. Our signature carries no image on the page; you open it via the signature bar at the top or the Signatures panel. There, Acrobat shows:

• Document unchanged: the hash and signature check passes.
• Identity unknown: the demo CA is on neither Adobe’s own trust list nor the EU trusted list, so the signature’s validity is reported as unknown.
• Time per device: without a timestamp, the signing time comes from the signer’s clock.

Under “Signature Properties” and “Show Signer’s Certificate” you see the chain: the certificate for Erika Mustermann, above it the “id-call Demo-CA”, each with the demo notice in its name.

With a real QES, only the issuer changes. Acrobat keeps a regularly updated snapshot of the EU trusted list. If the certificate chain leads to a qualified provider listed there, Acrobat explicitly labels the signature as a qualified electronic signature under the eIDAS Regulation. For a check independent of Adobe, the European Commission’s EU DSS validator also determines the PAdES level.

What is still missing for a qualified electronic signature

• A qualified provider that certifies keys in a smartphone chip and so replaces the demo CA.
• Proof that the key really sits in the chip: Apple and Google offer attestations for this (key attestation), which a provider would check before certifying.
• Qualified timestamps to move from B-B to B-T.

In id-call.eu the certificate issuer is a swappable component; everything else stays as it is.

Key takeaways

• With the EUDI Wallet, citizens are to be able to create qualified electronic signatures free of charge; Germany has announced this for 2027.
• The signing key can live in the security chip of your own phone and is only used after Face ID.
• Inside the PDF, a signature covers every byte except its own gap (/ByteRange); each further signature is appended.
• Whether a signature counts legally depends on the certificate issuer. Acrobat and EU DSS check it against the EU trusted list.
• id-call.eu simulates the complete flow today with a demo CA and is ready to swap it for a qualified provider.

Bringing signatures or wallet identities into your own processes starts with one question: which documents need which signature level? More on our EUDI Wallet integration page and in the id-call app case study.

This text is a technical overview, not legal advice.