[Dúvida] no [QR-Code do Pagador] - Funcionamento e segurança

[rubenskuhl]

Olá.

Eu estava imaginando a questão de autenticação do QR-Code do pagador, QR-Code off-line ou o nome que venha a ser definido... pois se não há comunicação com o PSP, como ele pode autenticar o pagador ?

Uma idéia que foi comentada é a de ter um estoque de códigos de autorização(ex: 10 códigos) que foi obtido enquanto havia conectividade do pagador com o PSP, armazenados no dispositivo para pagamento. Uma possibilidade seria o mecanismo de HOTP (RFC 4226), já usado por diversos sistemas de autenticação de 2 fatores (em geral como código de recuperação), que geraria códigos que seriam inutilizados a cada uso.

É algo nessa linha que vinha sendo imaginado ? Será que isso dá a experiência razoável nesse cenário ? Esses códigos teriam limite de valor inferior ao do Pix com conectividade ? (Eu acredito que sim devam ter valor limite inferior)

Porém... isso não permitiria que um dispositivo furtado ou roubado fizesse 10(ou número definido) compras indevidas ?

[carlosnetto]

O que está sendo pensado é um mecanismo de assinatura digital com chaves assimétricas (RSA, por exemplo). Os devices atuais (Android e IOS) já possuem mecanismos seguros de geração de par de chaves, onde nem mesmo o dev do App consegue ter acesso à chave privada. A chave pública fica no PSP do pagador. O PSP Recebedor recebe a ordem de pagamento assinada pelo Pagador e o transmite PSP Pagador. O PSP Pagador valida se a ordem de pagamento foi de fato emitida pelo usuário Pagador (validando a assinatura digital) e dá sequência no pagamento da mesma forma que faz hoje.

Na prática o Pagador usou a tela para transmitir dados para o Recebedor e, assim, conseguiu usar a Internet do Recebedor para falar com seu próprio PSP pagador. Na prática, a transação é online, mas a transmissão dos dados para o Recebedor é via QRCode; o Recebedor atua como um tipo de Proxy entre o Pagador e seu PSP. O pagamento continua sendo "push" como o Pix funciona hoje.

[rubenskuhl]

Se suportado pelo Android e pelo IOS, seria interessante o uso de curvas elípticas, que é a tendência atual (ao menos até os computadores quânticos exigirem criptografia bem mais onerosa).

Se o processo é quasi-online, quantas etapas seriam necessárias na experiência de uso ? Seriam mostrados 2 QR-Codes pelo pagador, um para começar o processo e outro para confirmar ?

[carlosnetto]

Os algoritmos a serem usados é pauta do Forum Pix. O BC não fechou questão ainda. Tá na hora de contribuir. Só o pagador apresenta o QR Code. O vendedor recebe uma mensagem de confirmação no seu device, como acontece hoje com os cartões de crédito/débito: se a "maquininha" falar "transação aprovada", o vendedor confia que recebeu.

Tudo indica que pode acontecer do pagador ter que ler o QR Code do lojista antes. O motivo para isso é que o QR Code gerado seja tipo um "cheque nominal" e não um "cheque ao portador". Uma forma de resolver isso é ler um QR Code do lojista antes que tem os dados do mesmo. Outra forma é um App de uso específico já gerar o QR destinado a um recebedor (ex.: o App do Metro gera o QR que funciona no Metro. Enfim, o ponto é o QR Code "nominal", mas a forma de obter isso pode não ser necessariamente lendo o QR Code do lojista.

Importante citar que o atual QR Code do lojista já tem os dados necessários para o funcionamento do QR Code apresentado pelo pagador. Alguns dados no QR são redundantes com o Payload e a resposta do BC foi "é redundante sim, para que o pagador offline consiga ter estes dados mesmo sem Internet". Enfim, não vai mudar quase nada - ou nada - no atual SPI.

[dmkamers]

Se suportado pelo Android e pelo IOS, seria interessante o uso de curvas elípticas, que é a tendência atual (ao menos até os computadores quânticos exigirem criptografia bem mais onerosa).

Curva elíptica tende a ter segurança equivalente com menos bits no que se refere a chave. Para o QRPagador isto deverá ser criticamente importante (tamanho do QR). HOTP também é promissor. E com NFC o cheque nominal fica simples de implementar, a princípio. Vamos esperar o povo conseguir tratar utf8 e calcular crc aí gente... :'(

[rubenskuhl]

Se suportado pelo Android e pelo IOS, seria interessante o uso de curvas elípticas, que é a tendência atual (ao menos até os computadores quânticos exigirem criptografia bem mais onerosa).

Curva elíptica tende a ter segurança equivalente com menos bits no que se refere a chave. Para o QRPagador isto deverá ser criticamente importante (tamanho do QR). HOTP também é promissor. E com NFC o cheque nominal fica simples de implementar, a princípio. Vamos esperar o povo conseguir tratar utf8 e calcular crc aí gente... :'(

Eu imagino que apesar da curva elíptica ter um requisito de processamento ligeiramente maior, a diferença de tamanho justifique sim no caso de uso.

HOTP é exatamente como faz o Samsung Pay(pelo menos no sentido de CX, não sei se seguem a RFC de HOTP), incluindo algo que melhora a usabilidade que é baixar automaticamente novos tokens quando há conectividade, para não depender do usuário lembrar de fazer refresh.

Vou pensar nessa relação do NFC com pagamento nominativo, não tinha me ocorrido. Quer dizer, depois que UTF8, CRC, txid e cadeia de certificação deixarem de ser pauta do dia...

[carlosnetto]

A patente US 2015/0006386 aborda este processo de envio prévio de Tokens para o celular pagador. Usar este processo envolveria uma licença prévia do detentor da patente.

Com o processo da assinatura digital, só a chave pública é transferida do celular do pagador para seu PSP. Depois disso, nada mais precisa ser transferido (o celular pode ficar meses offline) para o celular pois todo pagamento emtido será assinado pela chave privada, que fica em área segura do celular.

Em termos de experiência de uso, funciona muito bem, pois não há necessidade de ficar online de tempos em tempos.

Os mesmos bits que vão estar no QR Code apresentado pelo pagador poderão ser transferidos pelo BlueTooth ou pelo NFC. Na prática, o QR Code apresentado pelo pagador é só uma forma de transferir alguns bits do Pagador para seu PSP, via o Recebedor. Esta trasnferência para o recebedor pode ser via outro meio sem problema algum.

Quanto a usar menos bits com mesma seguraça, isso é muito importante. Contribuam no Forum Pix com isso. Se o QR Code ficar muito grande, sua leitura fica dificultada. Já consegui sucesso com total de 2000 bits (incluindo assinatura de 1500 mais dados), mas tive que comprimir em base 10 para não ficar muito difícil de ler. Otimizações ai são bem vindas.

[renatofrota]

https://youtu.be/613Mai1xsUw