Signatures on mobile devices
A user who signs on a computer can use Web PKI to reach the certificate on that computer, on a token or on a smart card. On a phone this doesn't work, so a mobile signing feature starts with a choice: where will the private key be when the user signs?
This article compares the four answers Lacuna's products support and points to the documentation, samples and live demos for each:
- A cloud certificate held by a PSC, through CloudHub
- A certificate inside the Web PKI app
- A key kept on your server or in an HSM
- A token on a workstation, commanded from the phone with TrustBridge
Why phones are different
On a computer, a web signature uses Web PKI: a browser extension and a native component that reach the operating system's certificate store (where an A1 certificate usually lives) and the token or smart card that holds an A3 certificate. The page asks Web PKI to sign, and the private key never leaves the user's machine.
A phone has neither piece. Mobile browsers don't run the Web PKI extension, a web page cannot reach the phone's own key store, and the USB tokens and smart cards that hold A3 certificates aren't supported on phones. So the key has to be somewhere the phone can reach in another way: at a PSC, inside an app, on your server, or on a computer that is still switched on.
1. A cloud certificate held by a PSC, through CloudHub
A cloud certificate (certificado em nuvem) keeps its private key in the HSM of a Prestador de Serviço de Confiança (PSC), a trust service provider accredited by ITI. The holder authorizes each use in the PSC's own app, with a PIN, a push notification or a QR code. Brazilian PSCs include BirdID (Soluti), SafeID (Safeweb), VIDaaS (Valid), RemoteID (Certisign) and NeoID (Serpro).
CloudHub connects your application to all of them through one REST API: it finds which PSCs hold a certificate for the signer's CPF, sends the user to the chosen one to authorize, and signs the hash your signature library computed. The document never leaves your server and the private key never leaves the PSC.
How it looks on a phone. Your page sends the browser to the PSC, the PSC's app opens, the holder approves there, and the browser comes back to your page. The return trip is the one difference between phones:
- Android can take the user from the PSC's app back to the browser on its own.
- iOS does not let the PSC's app send the user back to the browser automatically. After approving, the user switches back to the browser themselves. Tell them so on your page before you send them out, for example "after you approve in your PSC's app, come back to this tab".
The integration is the same as on a computer. The CloudHub calls, the session, the redirect URI and the signature are identical; only the iOS instruction is specific to phones. Follow How it works and Signing a PDF.
Several documents, one authorization. Create the session with the SignatureSession type and a
lifetime long enough for the batch: the user approves once and your server signs every document
with the same session. See Session types.
What the user needs. A cloud certificate. A certificate on a token or in a file is a different certificate: a user who signs with an A3 token today has to get a cloud certificate from a PSC. It is issued remotely, with identity checked by video call, typically within the hour, and costs in the order of R$ 150, depending on the provider.
An organization that wants to run its own PSC can do so with Lacuna PSC and Amplia.
2. A certificate inside the Web PKI app
The Web PKI app, for Android and iOS, keeps certificates in the phone's key store and lets web
pages sign with them. Every signature passes a biometric check; a successful check covers further
signatures for 2 minutes, only for the same site and only while the app is on screen. The holder
imports an A1 certificate (a .pfx file) into the app by scanning a QR code.
It works in three ways:
- Signing on the phone, in the app. Your signing page opens inside the app, from a deep link or a QR code. The app runs the page in its own browser view and answers the Web PKI JavaScript library in place of the browser extension, so a page that signs with Web PKI on a computer can sign on the phone too.
- Signing inside your own app. An organization that has its own Android, iOS or Flutter app can embed the same signing in it. Talk to Lacuna support about it.
- Approving from the phone a signature started on a computer. The user pairs the app with the Web PKI extension on a computer by scanning a QR code. From then on, when a page on that computer asks for a signature with the phone's certificate, the request arrives on the phone as a notification and the user approves it there.
What the user needs. The app, and an A1 certificate imported into it. An A3 certificate cannot be imported: its key never leaves the token or smart card.
3. A key kept on your server or in an HSM
Your application keeps the user's key and signs on the server when the user asks. An A1 certificate is stored encrypted at rest; an A3 key is generated and kept in an HSM, such as a network HSM or Azure Key Vault. The user authenticates to your application with a PIN, and optionally with more factors such as a one-time code or a biometric check, and your server signs.
This is the best experience on a phone: a plain web page, with no app to install, no trip to a PSC and no difference between iOS and Android. A batch is signed in one go, after one authentication.
The cost is responsibility: your service now holds keys that belong to people. Protect them as a PSC would, with the key encrypted at rest or in an HSM, a PIN that only the holder knows and that your application never stores, and a record of every authorization.
To build it:
- .NET: sign with the PKI SDK, loading the certificate as in Certificates with private key. See Server signatures.
- Any language: let Rest PKI Core prepare and complete the signature and sign the hash on your server, as in Two-step signatures.
- Off the shelf: TrustBridge can keep A1 certificates in its Certificate Vault and sign with them once the holder's PIN opens a session, through the same API as the next approach.
4. A token on a workstation, commanded from the phone with TrustBridge
Some users already sign with A3 tokens or smart cards that stay plugged into a Windows computer that is always on, as happens in hospitals. TrustBridge lets them sign from anywhere, the phone included, while the key stays on that token.
The TrustBridge Workstation Service runs on the computer and connects to the TrustBridge Server. Your application, which the user reaches from the phone, calls the Server's REST API with the user's CPF and PIN to open a Signing Session, then sends the PDFs to sign, one at a time or up to 50 in one call. The Server has the hash signed on the workstation that holds the token and has Lacuna Signer or Rest PKI Core build the signed PDF.
Things to plan for:
- The computer has to be on, with the token inserted. Have the holder type the token's PIN at the TrustBridge Tray App when they insert it. When no PIN is cached on that computer, TrustBridge asks for it at the Tray App, on the computer's screen, which a user signing from the phone cannot answer.
- The phone and the computer don't have to share a network. Workstations connect outbound to the Server and open no inbound port. Where the Server stays on a private network, computers outside it reach it over a VPN. See Network posture.
- The user's PIN is never sent to the workstation. The Server checks a proof that the workstation computes from the PIN the holder typed there. See Security.
Comparing the approaches
| Cloud certificate (CloudHub) | Web PKI app | Key on your server or HSM | Token on a workstation (TrustBridge) | |
|---|---|---|---|---|
| Experience on the phone | Leave for the PSC's app, approve, come back | Sign inside the app, with a biometric check | A web page and a PIN | A web page and a PIN |
| Where the key is | The PSC's HSM | The phone's key store | Your server or HSM | The token on the user's computer |
| What the user needs | A cloud certificate from a PSC | The app, with an A1 imported | Nothing beyond your application | A computer on, with the token in |
| A1 / A3 | Cloud certificate (neither) | A1 only | A1 encrypted, A3 in an HSM | A3 on a token, or A1 in the Windows store |
| iOS / Android | On iOS the user returns to the browser themselves | Both | Both, no difference | Both, no difference |
| Who holds the key | The PSC | The user | You | The user |
| Implementation | Low: the desktop integration, plus a note for iOS | Low for a Web PKI page; more to embed in your own app | Medium: key custody and user authentication | Medium: a TrustBridge Server and its workstations |
Choosing. If your users can get a cloud certificate, CloudHub gives them a mobile signature that works everywhere with little code. If they must keep the A3 tokens they already have, TrustBridge keeps those tokens in use. If you can take on key custody, a server or HSM key gives the smoothest experience. The Web PKI app suits users who hold A1 certificates and are willing to install an app, and covers the case of a signature started on a computer and approved on the phone.
An application can offer more than one: users with a cloud certificate sign through CloudHub, while the others use one of the remaining approaches.
Build it in two steps
Whichever approach you choose, prefer a two-step signature: your server prepares the signature and computes the hash to sign, the key signs only that hash, and your server completes the signed document. The document stays on your server, only a few kilobytes travel, and the same server code serves all four approaches:
| Approach | What signs the hash |
|---|---|
| Cloud certificate | CloudHub, at the PSC |
| Web PKI app | Web PKI, in the app |
| Key on your server or HSM | Your server, with the PKI SDK or the HSM |
| TrustBridge | The workstation, through Hash Signing or the PDF endpoints |
See Web remote signatures and Two-step signatures with Rest PKI Core.
Samples and demos
The box below lists the PKI Suite Samples for each building block: a two-step PAdES signature with the PKI SDK or Rest PKI Core, a key kept on the server, a cloud certificate through CloudHub and a batch of PDFs.
To try a cloud-certificate signature from your phone, open Sign a file (Cloud certificate, with CloudHub) on Lacuna's demo site.