FAQ / Technical process overview: What is uploaded where? Stored where (for how long)? Signed where? Compiled together where?

[porg]

Status quo: Neither the public website https://technology.a-sit.at/pdf-over-2/ nor the project's GitHub readme.md addresses how the process of signing PDFs with ID Austria works behind the scenes.

Inquiry: I'd appreciate public documentation, at least as a high level outline.

How does the signing of PDFs with ID Austria work technically?

For end users there are different possibilities to sign PDFs with ID Austria:

1. In the mobile app Digitales Amt.
2. In the desktop app https://technology.a-sit.at/pdf-over/
3. In the web app at https://secure.oesterreich.gv.at/digitales-amt/pdf-sign/

Also in method 2+3 you have to confirm the signing in the app "Digitales Amt". So I assume some part of the authorization and/or signing process happens there.

Please explain the whole process

• Which data travels from where to where?
• Where is the signing happening?
• Where is the final PDF compiled? Original PDF + digital signature + the optional visual signature seal → Final signed PDF. Does this happen server side or client side?
• Data retention along the way?

The more detailed the better!

I asked ChatGPT those questions and it gave me quite a convincing process outline:

1. PDF Preprocessing on the Client (PDF digest calculated + signature container prepared)
2. Communication with ID Austria (checks request syntax + initial authorization)
3. User Consent via Digitales Amt App (2FA)
4. Server-Side Signing of the digest (private key resides NOT in "Digitales Amt" mobile app but in virtual qualified signature creation device (QSCD) within the trusted server infrastructure of ID Austria, which signs the digest, the raw PDF never reaches the server)
5. Original PDF + digital signature + visual seal → Compiled into final PDF

ChatGPT's answer had some contradictions and ambiguity in it, especially regarding the web app:

• Ad step 1: It claimed the PDF is uploaded to the server
  • But I think only sent to the browser's local storage, there the digest is created (with the pdf.worker.js) and only that digest gets uploaded
• Ad step 4: Then the digest is signed in the server side QSCD
• Ad step 5: And the compilation of the final PDF also happens client side because it downloads "all the ingredients":
  • the marker_(de|en).pdf (visual seal template)
  • signature JSON (https://secure.oesterreich.gv.at/digitales-amt/pdf-sign/api/signature?reqId=xxx)
  • and the final download is a blob:// URL which is a strong indicator, that the original and final PDF only exist in client side local storage.

When confronting ChatGPT with these new findings it also assumed that original PDF and final PDF only ever exist client side, and never hit the server.

I'd very much appreciate an outline

• Here on Github in technical detail.
• On the end user web page, in easy understandable language, which nevertheless transparently lays out whether/how the raw PDF data travels, whether/where/how long data retention happens, and where the signature happens.
• Or at least proper links to the relevant sources.

Thanks!

[iaik-jheher]

I can only comment regarding PDF-Over.

When signing using ID Austria, signatures are created by a QSCD managed by A-Trust GmbH. You authorize this signature using your username+password plus an additional authentication factor (bound mobile app or hardware security key).

Technically speaking, PDF-Over first sends your username+password and receives your signing certificate in response. This allows us to extract your information and embed the visual signature stamp in the document. The entire document is then submitted to A-Trust GmbH servers for signing. This is so that the entire document can be independently reviewed by you in the mobile app; A-Trust GmbH does not currently offer any alternative process. Once you approve the signature in the app/using a hardware security key, PDF-Over then receives the signature value from the QSCD, and embeds it in the document.

Hopefully this answers your immediate question. We will consider updating the readme accordingly.

[mgrottenthaler]

Thank you for the clarification @iaik-jheher I was looking for this information, if the document is transmitted to a-trust for quite some time now.

But this is quite bad... The full document being transmitted to a-trust means that pdf-over cannot be used for highly confidential documents. A-Trust should offer the possibility to transmit just the hash. I guess it's out of your hands. Who can we write to about this issue? A-Trust directly or is there some public body that is governing this?

[iaik-jheher]

I am not immediately aware of where exactly the decision about this trade-off (document privacy versus independent document verifiability in the 2FA app) was made.

[dbeinder]

This process also introduces an undocumented file size limit (seems to be ~20MB). And at least when using a Fido2 Token, there is already a signature flow without second device verification in production right now.

So I'd love to see this implemented without uploading my PDFs in the background.

However, I suspect it all comes down to this question: Does the threat model allow citizens to sign arbitrary data/hashes with their certificate? For Bürgerkarte the answer was yes - and the ID-Austria whitepaper only argues that the Remote-HSM model is more user friendly - it does not argue that citizens fundamentally can not be trusted with a private key (or an authenticated API that signs arbitrary hashes).

If the answer is no - is it realistic for the server to verify that the blob it just got handed really is a PDF? Or would it be better altogether to just give everyone a dedicated file-signing certificate, that is more fully under the control of the user. Then there is no question whether the user can be tricked into signing a forged login request by presenting the user with a flow that looks like that of a PDF signature.

[iaik-jheher]

Without commenting on the underlying question you are posing: PDF-Over is ultimately limited by the interfaces offered to us. Currently, there is no interface offered that allows us to just provide a digest-to-be-signed.

[gunnarhaslinger]

It uploads the whole PDF without telling the User?! Is this even GDPR Compliant?

Just confirmed with PDF-Over 4.4.7 on Windows by using Wireshark: The whole PDF gets uploaded to an A-Trust Server 84.242.9.224 https://service.a-trust.at by HTTPS/TLS

I never was aware of this and the PDF-Over Client doesn't display this Information, that the Hash of the document is not calculated local but online by uploading the whole PDF.

PDF-Over gives no Information about this, and even in the linked Document "Datenschutzerklärung" which even doesn't mention PDF-Over at all but just talks about an App (possibly a smartphone app) I cannot find this Information.
https://www.a-trust.at/downloads/documents/datenschutzerklaerung.pdf

I don't think this is GDPR Compliant. Seems to me a mis-use of User-Trust in my opinion.

[stefan2904]

The information can, of course, always be more explicit, but in general, the information is there.

[dbeinder]

Without commenting on the underlying question you are posing: PDF-Over is ultimately limited by the interfaces offered to us. Currently, there is no interface offered that allows us to just provide a digest-to-be-signed.

Of course, I understand it is not your decision. What would be the appropriate forum to have that discussion, or send technical comments/wishes about the ID-Austria implementation?