Assinaturas em dispositivos móveis
Quem assina num computador pode usar o Web PKI para chegar ao certificado guardado no computador, num token ou num cartão inteligente. No celular isso não funciona. Por isso, uma funcionalidade de assinatura móvel começa com uma escolha: onde estará a chave privada quando o usuário assinar?
Este artigo compara as quatro respostas que os produtos da Lacuna oferecem e aponta a documentação, os exemplos e as demos de cada uma:
- Um certificado em nuvem guardado por um PSC, pelo CloudHub
- Um certificado dentro do aplicativo do Web PKI
- Uma chave guardada no seu servidor ou num HSM
- Um token numa estação de trabalho, comandado do celular pelo TrustBridge
Por que o celular é diferente
No computador, uma assinatura web usa o Web PKI: uma extensão do navegador e um componente nativo que chegam ao repositório de certificados do sistema operacional (onde costuma ficar um certificado A1) e ao token ou cartão inteligente que guarda um certificado A3. A página pede ao Web PKI que assine, e a chave privada nunca sai da máquina do usuário.
O celular não tem nenhuma dessas peças. Os navegadores móveis não executam a extensão do Web PKI, uma página web não alcança o repositório de chaves do próprio celular, e os tokens USB e os cartões inteligentes que guardam certificados A3 não são suportados em celulares. Então a chave precisa estar num lugar que o celular alcance de outro jeito: num PSC, dentro de um aplicativo, no seu servidor ou num computador que continua ligado.
1. Um certificado em nuvem guardado por um PSC, pelo CloudHub
Um certificado em nuvem guarda a chave privada no HSM de um Prestador de Serviço de Confiança (PSC) credenciado pelo ITI. O titular autoriza cada uso no aplicativo do próprio PSC, com um PIN, uma notificação push ou um QR code. Entre os PSCs brasileiros estão o BirdID (Soluti), o SafeID (Safeweb), o VIDaaS (Valid), o RemoteID (Certisign) e o NeoID (Serpro).
O CloudHub liga a sua aplicação a todos eles por uma única API REST: descobre quais PSCs têm um certificado para o CPF do signatário, envia o usuário ao escolhido para autorizar e assina o hash que a sua biblioteca de assinatura calculou. O documento não sai do seu servidor, e a chave privada não sai do PSC.
Como fica no celular. A sua página envia o navegador ao PSC, o aplicativo do PSC abre, o titular aprova ali e o navegador volta para a sua página. A volta é a única diferença entre os sistemas:
- No Android, o aplicativo do PSC consegue devolver o usuário ao navegador sozinho.
- No iOS, o aplicativo do PSC não pode devolver o usuário ao navegador automaticamente. Depois de aprovar, o próprio usuário volta ao navegador. Avise isso na sua página antes de enviá-lo, por exemplo: "depois de aprovar no aplicativo do seu PSC, volte para esta aba".
A integração é a mesma do computador. As chamadas ao CloudHub, a sessão, a URI de redirecionamento e a assinatura são idênticas; só o aviso do iOS é próprio do celular. Siga Como funciona e Assinando um PDF.
Vários documentos, uma autorização. Crie a sessão com o tipo SignatureSession e um tempo de vida
que baste para o lote: o usuário aprova uma vez e o seu servidor assina todos os documentos com a
mesma sessão. Veja Tipos de sessão.
O que o usuário precisa ter. Um certificado em nuvem. Um certificado em token ou em arquivo é outro certificado: quem hoje assina com um token A3 precisa obter um certificado em nuvem num PSC. A emissão é remota, com a identidade conferida por videoconferência, costuma sair em cerca de uma hora e custa na faixa de R$ 150, conforme o provedor.
Uma organização que queira operar o seu próprio PSC pode fazê-lo com o Lacuna PSC e o Amplia.
2. Um certificado dentro do aplicativo do Web PKI
O aplicativo do Web PKI, para Android e iOS, guarda certificados no repositório de chaves do
celular e permite que páginas web assinem com eles. Toda assinatura passa por uma verificação
biométrica; uma verificação bem-sucedida vale para as assinaturas seguintes por 2 minutos, só para o
mesmo site e só enquanto o aplicativo estiver na tela. O titular importa um certificado A1 (um
arquivo .pfx) para o aplicativo lendo um QR code.
Ele funciona de três formas:
- Assinando no celular, dentro do aplicativo. A sua página de assinatura abre dentro do aplicativo, por um deep link ou por um QR code. O aplicativo exibe a página no seu próprio navegador e responde à biblioteca JavaScript do Web PKI no lugar da extensão, então uma página que assina com o Web PKI no computador também assina no celular.
- Assinando dentro do seu próprio aplicativo. Uma organização que tenha o seu próprio aplicativo Android, iOS ou Flutter pode embutir nele a mesma assinatura. Fale com o suporte da Lacuna.
- Aprovando no celular uma assinatura iniciada no computador. O usuário pareia o aplicativo com a extensão do Web PKI num computador lendo um QR code. A partir daí, quando uma página nesse computador pede uma assinatura com o certificado do celular, o pedido chega ao celular como notificação e o usuário o aprova ali.
O que o usuário precisa ter. O aplicativo, com um certificado A1 importado. Um certificado A3 não pode ser importado: a chave dele nunca sai do token ou do cartão.
3. Uma chave guardada no seu servidor ou num HSM
A sua aplicação guarda a chave do usuário e assina no servidor quando ele pede. Um certificado A1 fica guardado criptografado; uma chave A3 é gerada e guardada num HSM, como um HSM de rede ou o Azure Key Vault. O usuário se autentica na sua aplicação com um PIN e, opcionalmente, com outros fatores, como um código de uso único ou uma verificação biométrica, e o seu servidor assina.
Esta é a melhor experiência no celular: uma página web comum, sem aplicativo para instalar, sem ida ao PSC e sem diferença entre iOS e Android. Um lote é assinado de uma vez, depois de uma única autenticação.
O preço é a responsabilidade: o seu serviço passa a guardar chaves que pertencem a pessoas. Proteja-as como um PSC faria, com a chave criptografada ou num HSM, um PIN que só o titular conhece e que a sua aplicação nunca guarda, e um registro de cada autorização.
Para implementar:
- .NET: assine com o PKI SDK, carregando o certificado como em Certificados com chave privada. Veja Assinaturas de servidor.
- Qualquer linguagem: deixe o Rest PKI Core preparar e concluir a assinatura e assine o hash no seu servidor, como em Assinaturas em duas etapas.
- Pronto para usar: o TrustBridge pode guardar certificados A1 no seu Cofre de Certificados e assinar com eles depois que o PIN do titular abre uma sessão, pela mesma API da próxima abordagem.
4. Um token numa estação de trabalho, comandado do celular pelo TrustBridge
Alguns usuários já assinam com tokens ou cartões A3 que ficam conectados a um computador Windows sempre ligado, como acontece em hospitais. O TrustBridge permite que eles assinem de qualquer lugar, inclusive do celular, enquanto a chave continua no token.
O Workstation Service do TrustBridge roda no computador e se conecta ao Servidor do TrustBridge. A sua aplicação, que o usuário acessa pelo celular, chama a API REST do Servidor com o CPF e o PIN do usuário para abrir uma Sessão de Assinatura e depois envia os PDFs a assinar, um por vez ou até 50 numa só chamada. O Servidor faz a estação de trabalho que tem o token assinar o hash e deixa o Lacuna Signer ou o Rest PKI Core montar o PDF assinado.
Pontos a planejar:
- O computador precisa estar ligado, com o token conectado. Peça ao titular que digite o PIN do token no Tray App do TrustBridge ao conectá-lo. Quando não há PIN guardado naquele computador, o TrustBridge o pede no Tray App, na tela do computador, e quem assina pelo celular não tem como responder.
- O celular e o computador não precisam estar na mesma rede. As estações de trabalho se conectam ao Servidor por conexões de saída e não abrem nenhuma porta de entrada. Quando o Servidor fica numa rede privada, os computadores de fora o alcançam por VPN. Veja Postura de rede.
- O PIN do usuário nunca é enviado à estação de trabalho. O Servidor confere uma prova que a estação calcula a partir do PIN que o titular digitou nela. Veja Segurança.
Comparando as abordagens
| Certificado em nuvem (CloudHub) | Aplicativo do Web PKI | Chave no seu servidor ou HSM | Token numa estação de trabalho (TrustBridge) | |
|---|---|---|---|---|
| Experiência no celular | Sai para o aplicativo do PSC, aprova, volta | Assina dentro do aplicativo, com verificação biométrica | Uma página web e um PIN | Uma página web e um PIN |
| Onde fica a chave | No HSM do PSC | No repositório de chaves do celular | No seu servidor ou HSM | No token, no computador do usuário |
| O que o usuário precisa ter | Um certificado em nuvem de um PSC | O aplicativo, com um A1 importado | Nada além da sua aplicação | Um computador ligado, com o token conectado |
| A1 / A3 | Certificado em nuvem (nenhum dos dois) | Só A1 | A1 criptografado, A3 num HSM | A3 em token, ou A1 no repositório do Windows |
| iOS / Android | No iOS o próprio usuário volta ao navegador | Os dois | Os dois, sem diferença | Os dois, sem diferença |
| Quem guarda a chave | O PSC | O usuário | Você | O usuário |
| Implementação | Baixa: a integração do computador, mais um aviso para o iOS | Baixa para uma página com Web PKI; maior para embutir no seu aplicativo | Média: guarda das chaves e autenticação do usuário | Média: um Servidor TrustBridge e as suas estações de trabalho |
Como escolher. Se os seus usuários podem obter um certificado em nuvem, o CloudHub lhes dá uma assinatura móvel que funciona em qualquer lugar com pouco código. Se eles precisam continuar com os tokens A3 que já têm, o TrustBridge mantém esses tokens em uso. Se você pode assumir a guarda das chaves, uma chave no servidor ou num HSM dá a experiência mais simples. O aplicativo do Web PKI serve a usuários com certificado A1 dispostos a instalar um aplicativo, e cobre o caso de uma assinatura iniciada no computador e aprovada no celular.
Uma aplicação pode oferecer mais de uma: quem tem certificado em nuvem assina pelo CloudHub, e os demais usam uma das outras abordagens.
Implemente em duas etapas
Seja qual for a abordagem, prefira uma assinatura em duas etapas: o seu servidor prepara a assinatura e calcula o hash a assinar, a chave assina só esse hash e o seu servidor conclui o documento assinado. O documento fica no seu servidor, trafegam só alguns kilobytes e o mesmo código de servidor atende às quatro abordagens:
| Abordagem | Quem assina o hash |
|---|---|
| Certificado em nuvem | O CloudHub, no PSC |
| Aplicativo do Web PKI | O Web PKI, no aplicativo |
| Chave no seu servidor ou HSM | O seu servidor, com o PKI SDK ou o HSM |
| TrustBridge | A estação de trabalho, pela Assinatura de hash ou pelos endpoints de PDF |
Veja Assinaturas web remotas e Assinaturas em duas etapas com o Rest PKI Core.
Exemplos e demos
O quadro abaixo lista os exemplos do PKI Suite Samples para cada peça: uma assinatura PAdES em duas etapas com o PKI SDK ou o Rest PKI Core, uma chave guardada no servidor, um certificado em nuvem pelo CloudHub e um lote de PDFs.
Para experimentar uma assinatura com certificado em nuvem pelo celular, abra Assinar um arquivo (Certificado em nuvem, com CloudHub) no site de demos da Lacuna.