bacen / pix-api

API Pix: a API do Arranjo de Pagamentos Instantâneos Brasileiro, Pix, criado pelo Banco Central do Brasil.
https://bacen.github.io/pix-api
2.32k stars 262 forks source link

[Dúvida] no [QR Code] - Certificado para assinatura do JWS #43

Closed cicloalcano closed 3 years ago

cicloalcano commented 3 years ago

ATENÇÃO: Não crie issue para questões relativas ao ambiente de produção !

Descreva sua dúvida ou problema Qual é a modalidade exata do certificado para assinatura do payload JWS (QR Codes dinâmicos) ?

Sistema ou Área QR Code

Identificador do Problema Manual de Segurança (Anexo II, pág. 26) consta apenas o certificado deve ser emitido por AC amplamente conhecida, e Key Usage=Digital Signature, mas não especifica qual Modalidade Exata do tipo de certificado.

Mensagens Enviadas / Recebidas Não se aplica

URL de conexão Não se aplica

Dados adicionais Manual de Segurança do Pix versão 3.0 (12/08/2020) (pdf) https://www.bcb.gov.br/content/estabilidadefinanceira/cedsfn/Manual%20de%20Seguranca%20do%20PIX%20v3.0.pdf

dmkamers commented 3 years ago

@cicloalcano por favor você pode exemplificar com algumas 'modalidades' de certificado, que você está considerando utilizar?

cicloalcano commented 3 years ago

Certificadora ofereceu as seguintes Modalidades:

rubenskuhl commented 3 years ago

Eu não vejo pq usar EV nesse ecossistema, já há uma relação direta de confiança entre as partes estabelecida pelos fatores de autenticação da habilitação do acesso à API. Exigir ICP-Brasil gera problemas operacionais enormes para fazer os end-points terem acesso ao hardware do certificado A3. Há um banco que exige ICP-Brasil no webservice de boletos e não temos nenhuma boa lembrança disso (esse fornecedor foi substituído). Múltiplos domínios também não precisa, mas não vejo pq objetar caso alguém queira usar.

Ou seja, seria SSL.

cicloalcano commented 3 years ago

Mas faz sentido usar um certificado de SSL para assinar um JWS ? SSL terá que ser associado a uma URL, correto?

rubenskuhl commented 3 years ago

Um certificado mostra que alguém checou algo que sua empresa tem (um domínio) ou que sua empresa é (OV ou EV). Eu imaginaria para quem tem atendedor de webhook usar o hostname do end-point do webhook, mas poderia ser string-aleatoria.exemplo.com.br de forma geral, onde exemplo.com.br é um domínio registrado para o CNPJ do correntista.

rturk commented 3 years ago

Complementando comentários do @rubenskuhl minha leitura é que certificado tem que ser SSL ou SSL Múltiplos domínios tendo quem vista que um certificado SSL com múltiplos domínios nada mais é que um certificado SSL com mais de um dominio, os quais também foram validados.

dmkamers commented 3 years ago

Prezados, um certificado 'SSL' (TLS) 'simples' apenas atesta que alguém (literalmente qualquer um) é dono de um domínio. Requisitos adicionais de validação (como no caso de certificados "EV") tornam essa 'identidade' mais forte. A certificadora vai necessariamente verificar a organização 'em nome de quem' o certificado é emitido. Isto agrega segurança para quem publica a 'location' (presente no QR), e para quem a acessa depois.

Os requisitos estão postos no Manual de Segurança tanto para o certificado SSL que protege a conexão inicial com a location hospedada no PSP recebedor, quanto para a chave que assina o JWS (que é informada pelo PSP no padrão JWKS). A critério do PSP recebedor, e caso o certificado SSL tenha os requisitos necessários para a assinatura digital JWS segundo o Manual de Segurança, o certificado SSL que protege a location também pode ser usado para assinar o payload, mas não necessariamente. A chave (certificado) que assina o JWS não deve ser 'auto-gerada' (auto-assinada), mas sim proveniente de uma Autoridade Certificadora amplamente reconhecida (pelos 'clientes'), não apenas para que o 'cliente' (que lê o payload JSON da cobrança) verifique a integridade dos dados, mas principalmente para que possa evitar o 'repúdio' posterior da cobrança publicada pelo PSP recebedor. Assim, a 'cadeia de confiança' dessa chave (JWS) deve ser passível de verificação e validação pelos clientes que acessam o location/payload JWS.

Note-se, que estes requisitos se referem especificamente à segurança no acesso à location obtida do QR code e ao payload JWS. Não se confunde com a segurança da API Pix em si, objeto deste repositório (que logicamente deve utilizar TLS também). Os requisitos de segurança do acesso à API Pix estão em seção específica, anexa ao Manual de Padrões para Iniciação do Pix.

dmkamers commented 3 years ago

@rubenskuhl @rturk obrigado pelos comentários. @cicloalcano para assinar o JWS pode ser utilizado o mesmo certificado TLS que protege o acesso à location (lida em um QR Dinâmico), desde que ele tenha os atributos apropriados. Ou, pode ser utilizado qualquer certificado de "assinatura digital" (por exemplo, um 'e-CNPJ' ou 'e-CPF', ou outro certificado digital para assinatura de 'documentos'), desde que sejam certificados passíveis de validação pelo 'cliente' que acessa o payload JWS (raiz reconhecida) e cumpram os requisitos que estão no Manual de Segurança quanto à proteção do payload JWS.

cicloalcano commented 3 years ago

Um certificado do tipo SPB atenderia ?

dmkamers commented 3 years ago

Um certificado do tipo SPB atenderia ?

@cicloalcano Os certificados padrão SPB poderiam ser utilizados para assinatura digital do JWS, porém, existe a possibilidade de que a cadeia de certificados da ICP-Brasil não seja reconhecida como confiável pelo dispositivo que efetuará a leitura do QR Code - tipicamente um celular.

ninrod commented 3 years ago

Prezados, podemos responder alguma dúvida adicional?