Manual de Seguranca PIX
Manual de Seguranca PIX
Manual de Seguranca PIX
Versão 3.6
Versão 3.0
1
SUMÁRIO
2
Histórico de revisão
Data Versão Descrição das alterações
16/01/2020 1.0 Versão inicial.
24/03/2020 2.0 • Alteração do nome do Ecossistema de Pagamentos
Instantâneos para PIX;
• Atualização e inclusão de referências;
• Alteração da seção 1.2 e subseções para incluir o
processo de assinatura digital no DICT;
• Detalhamento dos processos de ativação e
desativação de certificados digitais do BC e dos
participantes (seções 1.3.2 a 1.3.4)
• Inclusão da seção 1.3.5: Verificação da revogação de
certificados digitais;
• Inclusão da seção 1.4: Segurança de QR Codes
dinâmicos.
12/08/2020 3.0 • Renumeração e reordenação das seções do Manual;
• Inclusão da seção 6: “Logs de auditoria”;
• Aprimoramento da seção 4: “Segurança de QR Codes
dinâmicos”;
• Alterações na seção 5: “Certificados digitais”,
incluindo:
o Detalhamento de cada tipo de certificado digital
utilizado no Pix;
o Maior clareza das regras para envio de
certificados;
o Aprimoramentos nas seções de ativação,
desativação e verificação de revogação de
certificados.
• Alteração no exemplo de mensagem pacs.008 na
seção 3.2;
• Atualização de referências;
• Correção de pequenos erros no documento.
06/10/2020 3.1 • Aprimoramentos na seção 5: “Certificados digitais”,
em especial no que tange aos certificados para
sites/domínios de QR Codes dinâmicos;
• Pequenas alterações e correções no documento.
04/02/2021 3.2 • Aprimoramentos nas seções 4.2 (“Definições do
padrão JWS”) e 4.3 (“Validações a serem feitas pelos
aplicativos”);
• Atualização de referências.
05/07/2021 3.3 • Criação da nova seção 6, intitulada “Implementação
segura de aplicativos, APIs e outros sistemas”.
3
29/10/2021 3.4 • Alteração da seção 5 “Certificados digitais” para
prever a transição para o novo padrão do certificado
de autenticação e criptografia da conexão utilizado
pelo BC e mudança no procedimento de desativação
do certificado dos participantes.
• Ajustes de redação para maior clareza.
16/11/2022 3.5 • Ajustes na seção de certificados digitais – itens 5.1,
5.4.3, 5.4.4 e 5.5.
• Ajustes na seção 6 – alteração dos itens 1 e 5,
inclusão do item 7 e outras pequenas alterações.
19/01/2024 3.6 • Inclusão (seção 5.2) de prazo regulamentar para
atualização de certificados digitais.
• Ajustes de redação para enfatizar a obrigatoriedade
da adequada guarda de chaves criptográficas
privadas e de boas práticas de gestão de certificados
e chaves (seção 5.2 e 5.3).
• Ajustes de redação para maior clareza.
4
Apresentação
Este manual descreve os principais requisitos técnicos de segurança do ecossistema
de pagamentos instantâneos (Pix), e tem como objetivo descrever como deve ser
implementada a criptografia da comunicação, a autenticação, os processos de
assinatura digital e de gestão dos certificados digitais utilizados no ecossistema, bem
como os aspectos de segurança associados à iniciação de pagamentos por QR Codes
dinâmicos. Os requisitos para implementação segura de aplicativos, APIs e sistemas
relacionados ao Pix também constam neste manual, assim como os requisitos para
manutenção de logs de auditoria.
5
Referências
Estas especificações baseiam-se, referenciam, e complementam onde aplicável, os
seguintes documentos:
Referência Origem
Resolução BCB nº 1 (Regulamento do https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Res
Pix) olu%C3%A7%C3%A3o%20BCB&numero=1
Manual de Segurança do SFN https://www.bcb.gov.br/estabilidadefinanceira/comunicacaodados
Manual de Redes do SFN https://www.bcb.gov.br/estabilidadefinanceira/comunicacaodados
Catálogo de Serviços do SFN https://www.bcb.gov.br/estabilidadefinanceira/comunicacaodados
Manual das Interfaces de Comunicação https://www.bcb.gov.br/estabilidadefinanceira/comunicacaodados
Diretório de Identificadores de Contas
https://www.bcb.gov.br/estabilidadefinanceira/pix
Transacionais (DICT)
Padrões para Iniciação do Pix https://www.bcb.gov.br/estabilidadefinanceira/pix
Sistema de Transferência de Arquivos
https://www.bcb.gov.br/estabilidadefinanceira/pix
do Banco Central (STA)
Aplicação BC Correio https://bccorreio.bcb.gov.br/bccorreio/
ICP-Brasil https://www.iti.gov.br/icp-brasil
ISO 20.022 https://www.iso20022.org/
XML Signature Syntax and Processing
https://www.w3.org/TR/2008/REC-xmldsig-core-20080610/
(Second Edition)
Padrão de assinatura digital JSON Web
https://tools.ietf.org/html/rfc7515
Signature (JWS) – RFC 7515
JSON Web Key – RFC 7517 https://tools.ietf.org/html/rfc7517
JSON Web Algorithms (JWA) – RFC
https://tools.ietf.org/html/rfc7518
7518
Padrão de certificados X.509 – RFC
https://tools.ietf.org/html/rfc5280
5280
Well-Known URIs – RFC 8615 https://tools.ietf.org/html/rfc8615
https://www.w3.org/TR/capability-urls/ - ver o último draft, disponível
Good Practices for Capability URLs
em: https://w3ctag.github.io/capability-urls/.
Randomness Recommendations for
https://tools.ietf.org/html/rfc4086
Security – RFC 4086
A Universally Unique IDentifier (UUID)
https://tools.ietf.org/html/rfc4122
URN Namespace – RFC 4122
OCSP – Online Certificate Status
https://tools.ietf.org/html/rfc6960
Protocol – RFC 6960
Lei Geral de Proteção de Dados (LGPD) http://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709.htm
Sugestões, críticas ou pedidos de esclarecimento de dúvidas podem ser enviados ao
BC por meio do e-mail [email protected].
6
1. Introdução
A segurança é um elemento primordial do Pix e, para garanti-la, requisitos
importantes devem ser estabelecidos e diversos controles devem ser colocados em
prática, não só pelo Banco Central, mas por todos os participantes do ecossistema.
Nesse contexto, é necessário implementar criptografia e autenticação mútua na
comunicação entre os participantes e as APIs do Pix e as mensagens transmitidas no
âmbito do sistema devem ser assinadas digitalmente. A iniciação de pagamentos, em
especial quando ocorre por meio de QR Codes dinâmicos, também possui aspectos de
segurança importantes que devem ser considerados. Ademais, logs de auditoria
devem ser mantidos pelas instituições no intuito de prover a rastreabilidade das
mensagens e transações realizadas no Pix.
1
Resolução BCB Nº 1, de 12 de agosto de 2020 – disponível em:
https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Resolu%C3%A7%C3%A3o%20BCB&nu
mero=1.
7
2. Comunicação segura
A comunicação entre cada participante e o Pix é realizada por meio da Rede do
Sistema Financeiro Nacional (RSFN). A conexão do participante com a RSFN deve
observar as regras e padrões dispostos no Manual de Redes do SFN2.
Fase/Função Algoritmo
Troca de chaves ECDHE (Elliptic Curve Diffie Hellman Ephemeral)
Autenticação RSA
Criptografia simétrica AES com chaves de 128 bits utilizando o modo GCM
MAC (Message Authentication Code) SHA de 256 bits
Tabela 1: Algoritmos utilizados na criptografia TLS.
Os clientes HTTP do participante devem sempre respeitar o TTL (Time To Live) dos
servidores DNS. A falha em respeitar o TTL pode causar indisponibilidade no acesso às
APIs do Pix.
2
Manual de Redes do SFN – última versão disponível na página:
https://www.bcb.gov.br/estabilidadefinanceira/comunicacaodados.
8
3. Assinatura digital
No intuito de garantir a integridade e o não repúdio das transações no âmbito do Pix,
todas as mensagens trafegadas no Sistema de Pagamentos Instantâneos (SPI) devem
ser assinadas digitalmente pelo emissor. No caso do Diretório de Identificadores de
Contas Transacionais (DICT)3, apenas as requisições de consulta (GET) não precisam
ser assinadas, enquanto todas as demais requerem assinatura. Seja qual for a
operação realizada, tanto no SPI como no DICT, a resposta do BC para o participante
é sempre assinada.
# Elemento/tag Descrição
Elemento raiz da assinatura XMLDSig, onde se define o
namespace, que aponta para a URI do esquema XML
(XML Schema Definition – XSD) a ser utilizado para a
1 <Signature>
assinatura digital. Inclui todos os elementos descritos
nas demais linhas desta tabela. No Pix, é utilizado
XMLDSig: http://www.w3.org/2000/09/xmldsig#
Contém as principais informações necessárias para a
1.1 <SignedInfo> assinatura, e inclui as tags <CanonicalizationMethod>,
<SignatureMethod> e tags <Reference>, descritas abaixo.
Especifica o algoritmo de canonicalização a ser
aplicado no elemento <SignedInfo>, com o objetivo de
gerar a forma canônica do conteúdo a partir do qual
1.1.1 <CanonicalizationMethod> será gerado o resumo (digest) para posterior
assinatura digital. No Pix, deve ser utilizado o
algoritmo de canonicalização XML exclusiva:
http://www.w3.org/2001/10/xml-exc-c14n#.
3
A API do DICT é documentada em manual específico, cuja última versão está disponível na
página: https://www.bcb.gov.br/estabilidadefinanceira/pix.
4
W3C Recommendation – XML Signature Syntax and Processing (Second Edition), disponível em:
https://www.w3.org/TR/2008/REC-xmldsig-core-20080610/
5
Padrão ISO 20.022 – mais informações disponíveis em: https://www.iso20022.org/
6
Mais detalhes sobre o BAH podem ser obtidos na página da ISO 20.022 (ver referência anterior).
7
Catálogo de Serviços do SFN – última versão disponível em
https://www.bcb.gov.br/estabilidadefinanceira/comunicacaodados.
9
Define o algoritmo utilizado para geração e validação
da assinatura digital. No Pix, utiliza-se RSA-SHA256:
1.1.2 <SignatureMethod>
http://www.w3.org/2001/04/xmldsig-more#rsa-
sha256.
Elemento que referencia o conteúdo a ser assinado, e
inclui as tags <Transforms>, <DigestMethod> e
1.1.3 <Reference>
<DigestValue>. A utilização do elemento <Reference> é
detalhada na seção 3.1 a seguir.
Inclui uma ou mais tags <Transform>, que indicam que
transformações devem ser aplicadas, sempre em
1.1.3.1 <Transforms> sequência, no conteúdo a partir do qual será gerado o
resumo (digest). As transformações realizadas constam
nas tabelas 3 e 4 da seção 3.1.
Identifica qual algoritmo de digest será aplicado ao
1.1.3.2 <DigestMethod> conteúdo a ser assinado. No Pix, utiliza-se SHA-256:
http://www.w3.org/2001/04/xmlenc#sha256.
Elemento que contém o resumo (digest) codificado em
1.1.3.3 <DigestValue>
base64.
Elemento que contém os dados do certificado utilizado
1.2 <KeyInfo> para assinar digitalmente o conteúdo. Inclui a tag
<X509Data>, explicada abaixo.
Contém os dados do certificado X509 utilizado pelo
1.2.3 <X509Data> assinador. Inclui a tag <X509IssuerSerial>, descrita
abaixo.
Contém as tags <X509IssuerName> e
1.2.3.1 <X509IssuerSerial>
<X509SerialNumber>, descritas abaixo.
Contém o nome (Distinguished Name – DN) da AC que
1.2.3.1.1 <X509IssuerName>
gerou o certificado utilizado para assinatura digital.
Contém o número de série do certificado utilizado
1.2.3.1.2 <X509SerialNumber>
para assinatura digital.
Elemento que contém a assinatura digital
1.3 <SignatureValue>
propriamente dita, codificada em base64.
Tabela 2: Elementos que compõem a assinatura digital no Pix.
10
Tag Conteúdo referenciado Transformações a serem realizadas
<Reference <KeyInfo Id=”unique-id-to-KeyInfo”>
Canonicalização XML Exclusiva:
URI=”<unique-id-to- (...................)
http://www.w3.org/2001/10/xml-exc-c14n#
KeyInfo> </KeyInfo>
XMLDSig Enveloped Signature:
BAH (excluindo os elementos da
http://www.w3.org/2000/09/xmldsig#envelope
assinatura digital):
d-signature
<Reference URI =””> <AppHdr>
e
(...................)
Canonicalização XML Exclusiva:
</AppHdr>
http://www.w3.org/2001/10/xml-exc-c14n#
<Document>
Canonicalização XML Exclusiva:
<Reference> (...................)
http://www.w3.org/2001/10/xml-exc-c14n#
</Document>
Tabela 3: Elementos <Reference> utilizados no SPI, bem como as transformações realizadas.
Observação: no SPI, a tag <Reference>, sem o atributo URI, deve ser interpretada pela aplicação de
forma a referenciar a mensagem ISO 20.022 propriamente dita (elemento <Document>).
Observação: ressalta-se que, no caso do DICT, a tag <Reference URI =””> aponta para a raiz do XML,
diferentemente do que ocorre no SPI.
11
7. Efetuar as transformações nos conteúdos, conforme tabela 3;
8. Gerar os digests para os conteúdos referenciados nos itens acima, incluindo-
os nos respectivos elementos <DigestValue>;
9. Canonicalizar o elemento <SignedInfo> e assiná-lo digitalmente conforme
algoritmos definidos no passo 5 acima;
10. Inserir a assinatura digital gerada no passo anterior no elemento
<SignatureValue>.
12
Figura 1 – Fluxo de assinatura digital da mensagem no SPI.
13
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<Envelope xmlns="https://www.bcb.gov.br/pi/pacs.008/1.4">
<AppHdr>
(...)
<Sgntr>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
<ds:Reference URI="#key-info-id">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<ds:DigestValue>J9fL+QyrtblrJnk0gjGnGPaDt42AKfNRM3uv4EbdbrM=</ds:DigestValue>
</ds:Reference>
<ds:Reference URI="">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<ds:DigestValue>D8tkpivJTLnU5YQt8E9T/723ykNv1h41qu07hnIwV+4=</ds:DigestValue>
</ds:Reference>
<ds:Reference>
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<ds:DigestValue>B/xG0ETsGoVLZtgbdvPtfHMYJORIpEzkBPTWfL1gMbI=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>
QfbSxaFsYZ89+EkweSWRcoP9hcam3NFwr2gwrbK50XZdZJA/DqaH6icqU/Ys2AHwR78KNx1LVqpg
J6bdVg4kDYu9PAoWzCcRLBJb6gRlSchyR7Uaih2PnNfaJ+OU7YREJW391d5hGds0F/ufNpVc2r6+
9DrYvxcphC9YKKb7v0Qw7Jyj13TimghPsqH1XTxeKHmby+MU7aObksTHBXgpEIMezsZhPOG5LNqT
Kq1e3tiQQvseHW6qO8rcHtIeI/Q9jtw+Idipwhu7lbS2XvoOcdHf2LWlQo6Tm77PJVvkJaQTd8tw
iUwaQkubtWuoGmUB4blYafy5Sby1OjZR5EAaMg==
</ds:SignatureValue>
<ds:KeyInfo Id="key-info-id">
<ds:X509Data>
<ds:X509IssuerSerial>
<ds:X509IssuerName>CN=AC Exemplo, OU=CSPB-0, O=ICP-Brasil, C=BR</ds:X509IssuerName>
<ds:X509SerialNumber>20200130224837516000</ds:X509SerialNumber>
</ds:X509IssuerSerial>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
</Sgntr>
</AppHdr>
<Document>
(...)
</Document>
</Envelope>
Observação: trechos do XML não relacionados à assinatura foram cortados e estão representados
com (...). Mais informações sobre o XML como um todo constam no Catálogo de Serviços do SFN.
14
No DICT, por sua vez, o processo de assinatura digital inclui os passos abaixo:
15
Figura 2 – Fluxo de assinatura digital no DICT.
16
3.3. Verificação da assinatura digital
(*) Cada participante é responsável por manter uma base atualizada com os números
de série e respectivas chaves públicas dos certificados digitais do BC utilizados para
assinatura digital. O BC ativará seus certificados conforme descrito na seção 5.4.
17
Figura 3 – Fluxo de verificação da assinatura digital da mensagem no SPI.
18
Já no DICT, o processo de verificação da assinatura digital consiste nos seguintes
passos:
19
Figura 4 – Fluxo de verificação da assinatura digital no DICT.
20
4. Segurança de QR Codes dinâmicos
Esta seção apresenta as especificações de segurança de QR Codes dinâmicos gerados
pelo recebedor.
A URL presente no QR code dinâmico não deve incluir prefixo de protocolo, uma vez
que este deve ser sempre HTTPS, conforme já especificado no início desta seção.
Respeitadas as regras de formação de URL11 e as definições do Manual do BR Code12,
os seguintes componentes devem estar presentes:
fqdnPspRecebedor/pixEndpoint/pixUrlAccessToken/
8
Manual de Padrões para Iniciação do Pix” – última versão disponível na página:
https://www.bcb.gov.br/estabilidadefinanceira/pix.
9
Padrão de assinatura digital JSON Web Signature (JWS), definido pela RFC 7515, disponível em
https://tools.ietf.org/html/rfc7515.
10
DNS CAA (Certificate Authority Authorization, disponível em
https://tools.ietf.org/html/rfc6844.
11
A sintaxe, a semântica e outros aspectos a respeito de URLs são definidas pela RFC 1738,
disponível em https://tools.ietf.org/html/rfc1738.
12
Conforme estabelecido pela Carta Circular 4.014/2020, disponível em
https://www.bcb.gov.br/estabilidadefinanceira/arranjosintegrantesspb.
21
(FQDN). O endpoint/aplicação do recebedor é opcional, mas, se presente, deve ser
respeitado.
Para impedir a dedução do pixUrlAccessToken por terceiros, o PSP recebedor deve criá-
lo conforme as recomendações do documento do W3C intitulado “Good Practices for
Capability URLs”14, além de considerar aspectos que garantam alto grau de entropia e
de aleatoriedade – ver RFC 4086 (“Randomness Requirements for Security”)15. Uma
abordagem possível é utilizar o padrão UUID16 v4 para representar o pixUrlAccessToken,
desde que o algoritmo utilizado para gerá-lo atenda ao requisito de aleatoriedade real.
É importante frisar que o uso da versão 4 é obrigatório caso se opte por esse padrão,
pois ela é a única em que o UUID é gerado com valores aleatórios.
13
A URL estará exposta a qualquer agente que tenha acesso ao QR Code gerado.
14
W3C – “Good Practices for Capability URLs”, disponível em https://www.w3.org/TR/capability-
urls/. Ver o último draft, que consta em: https://w3ctag.github.io/capability-urls/.
15
RFC 4086 (“Randomness Requirements for Security”), disponível em
https://tools.ietf.org/html/rfc4086, apresenta as melhores práticas para geração de dados
aleatórios.
16
RFC 4122 (“A Universally Unique IDentifier (UUID) URN Namespace”), disponível em:
https://tools.ietf.org/html/rfc4122.
22
que o payload é assinado digitalmente pelo PSP recebedor, para garantir a integridade
e não-repúdio das informações da transação. A estrutura JWS inclui:
• Cabeçalho (JSON Object Signing and Encryption – JOSE Header), onde se define o
algoritmo utilizado e inclui informações sobre a chave pública ou certificado
que podem ser utilizadas para validar a assinatura;
• Payload (JWS Payload): conteúdo propriamente dito;
• Assinatura digital (JWS Signature): assinatura digital, realizada conforme
parâmetros do cabeçalho.
Cada elemento acima deve ser codificado utilizando o padrão Base64url17 e, feito isso,
os elementos devem ser concatenados com “.” (método JWS Compact Serialization,
conforme definido na RFC 7515).
O JWK Set disponível na URL acima deve incluir o parâmetro keys, cujo valor consiste
em uma ou mais chaves no padrão JWK, conforme definido na RFC 7517. A estrutura
JWK, por sua vez, deve incluir no mínimo os parâmetros abaixo:
17
As definições sobre o padrão Base64url constam na seção 5 da RFC 4648, disponível em
https://tools.ietf.org/html/rfc4648#section-5.
18
A estrutura JSON Web Key é definida pela RFC 7517, disponível em
https://tools.ietf.org/html/rfc7517.
23
(*) Neste caso, também devem ser inclusos no JWK os parâmetros
abaixo:
▪ “n”: módulo da chave pública RSA;
▪ “e”: expoente da chave.
(**) Neste caso, também devem ser inclusos no JWK os parâmetros
que definem a curva elíptica utilizada:
▪ “crv”: identificador da curva criptográfica utilizada;
• Valores permitidos: “P-256”, “P-384” e “P-521”.
▪ “x”: coordenada X do ponto da curva elíptica;
▪ “y”: coordenada Y do ponto da curva elíptica.
• “key_ops” (Key Operations): operação para a qual a chave deve ser utilizada.
o Deve ser sempre “verify”, pois a chave será usada para verificar a
assinatura digital do JWS.
• “kid” (Key ID): Identificador único da chave no JWK Set.
• “x5t” (X.509 Certificate SHA-1 Thumbprint) (*): thumbprint, codificado em
Base64url, do certificado que corresponde à chave privada utilizada para
assinatura do JWS.
(*) Alternativamente, poderá ser utilizado o parâmetro x5t#S256 (X.509
Certificate SHA-256 Thumbprint) ou superior, de acordo com a função hash
utilizada para gerar o thumbprint.
• “x5c” (X.509 Certificate Chain): certificado digital X.509, contendo a chave
pública que corresponde à chave privada utilizada na assinatura digital, bem
como sua respectiva cadeia completa de certificação, incluindo o certificado
da AC raiz.
o Deve-se utilizar um array JSON com os certificados, começando com o
certificado cuja chave privada correspondente foi utilizada na assinatura,
seguido pelo certificados adicionais da cadeia, onde cada certificado
subsequente tenha sido utilizado para emissão do certificado anterior,
conforme exemplo do Appendix B da RFC 7515.
o Assim como no caso do certificado associado ao site que hospeda a
estrutura JWS, o certificado neste caso deve ser válido e emitido por AC
amplamente conhecida.
Os parâmetros “x5t” e “kid” definidos no JWK Set devem corresponder aos parâmetros
de mesmo nome que constam no cabeçalho JWS, permitindo que a aplicação cliente
consiga identificar de maneira inequívoca o certificado e a chave pública a ser utilizada
para verificar a assinatura digital do JWS.
Mais informações sobre os parâmetros do JWS e JWK Set constam na RFC 751819, além
das RFCs 7515 e 7517 já citadas anteriormente.
19
RFC 7518 – “JSON Web Algorithms (JWA)”, disponível em https://tools.ietf.org/html/rfc7518.
24
4.3. Validações a serem feitas pelos aplicativos
Após efetuar a leitura de um QR Code dinâmico, os aplicativos de cada participante
devem seguir os passos abaixo:
20
O padrão de certificados X.509 é definido pela RFC 5280, disponível em
https://tools.ietf.org/html/rfc5280). Nele, o processo de validação da cadeia de certificação é
descrito em detalhes.
21
A definição do recurso denominado Well-Known URIs é feita pela RFC 8615, disponível em:
https://tools.ietf.org/html/rfc8615.
22
O formato do documento host-meta é definido pela RFC 6415, disponível em:
https://tools.ietf.org/html/rfc6415.
25
processamento de transações via QR Codes dinâmicos quando o recebedor for aquele
PSP.
Por fim, para garantir o não-repúdio das transações efetuadas por meio de QR Codes
dinâmicos, recomenda-se que os participantes mantenham registros históricos das
transações efetuadas, incluindo as respectivas estruturas JWS, certificados e chaves
públicas relacionados a cada transação.
26
5. Certificados digitais
Esta seção apresenta os detalhes a respeito dos tipos de certificados a serem
utilizados e descreve o processo de ativação, desativação e de verificação da
revogação de certificados.
Tanto para autenticação e criptografia da conexão com as APIs do Pix como para
assinatura digital das mensagens, todos os participantes devem utilizar certificados
digitais ICP-Brasil no padrão SPB. As especificações para a geração e requisitos desse
tipo de certificado constam no Manual de Segurança do SFN 23. O Banco Central
também utiliza certificados digitais padrão SPB para assinatura digital. Porém, apenas
no caso do BC, para autenticação e criptografia da conexão são utilizados certificados
SSL da cadeia v10 da ICP-Brasil.
Nos sites que hospedam URLs de QR Codes dinâmicos gerados pelo recebedor, não é
necessário que o certificado associado seja padrão SPB, porém ele deve atender aos
requisitos abaixo:
23
Manual de Segurança do SFN, disponível para download na página
https://www.bcb.gov.br/estabilidadefinanceira/comunicacaodados.
27
• Possuir o valor “Autenticação do Servidor” (“Server Authentication”) no campo
“Uso Avançado da Chave” (“Extended Key Usage”);
• Ser cadastrado no Pix conforme especificado na seção 5.2.
24
Sistema de Transferência de Arquivos do Banco Central, disponível em:
https://www.bcb.gov.br/acessoinformacao/sistematransferenciaarquivos
28
• Para envio de certificado digital do ambiente de Homologação, deverá ser
utilizado o STA de homologação25. Para envio de certificado do ambiente de
Produção, deverá ser usado o STA de produção26.
• Ao receber um certificado via STA, o BC terá o prazo de 7 dias para ativá-lo no
Pix. Portanto, recomenda-se que os participantes enviem novos certificados
com antecedência igual ou superior a esse prazo.
• O envio do arquivo CERTQRC é permitido apenas para usuários com acesso ao
serviço “Sisbacen SCERTQRC”, que só deve ser concedido às pessoas
devidamente autorizadas pelo PSP para essa função.
• Recomenda-se o envio dos arquivos de certificados em dias úteis, em horário
comercial. Somente haverá suporte do BC para resolução de eventuais
problemas no envio de arquivos durante o horário comercial.
• O arquivo poderá ser obtido por meio de consulta à interface ARQ27, nos
caminhos abaixo:
/api/v1/download/pub/cert/certqrc.zip (produção)
/api/v1/download/pub/cert/certqrc-h.zip (homologação).
• Cada participante deverá realizar o download do arquivo no máximo uma vez
a cada 24 horas.
• O participante deve manter cache do arquivo nas 24 horas seguintes a cada
consulta.
25
Disponível em https://sta-h.bcb.gov.br/sta.
26
Disponível em https://sta.bcb.gov.br/sta.
27
Mais informações sobre a interface ARQ estão disponíveis no Manual das Interfaces de
Comunicação, cuja última versão disponível consta na página:
https://www.bcb.gov.br/estabilidadefinanceira/comunicacaodados.
29
• Cada participante poderá consultar se o arquivo foi modificado e, caso não
tenha havido alteração no arquivo desde o último download, não será
necessário baixá-lo novamente.
• A interface ARQ de cada ambiente (Homologação ou Produção)
disponibilizará no arquivo apenas os certificados de sites de QR Codes
dinâmicos para aquele ambiente.
• É responsabilidade do participante pagador verificar o status de revogação do
certificado do site associado ao QR Code do PSP recebedor. O arquivo de
certificados disponibilizado pela interface ARQ terá atualização frequente,
porém podem ocorrer revogações entre tais atualizações.
• Os participantes devem distribuir os novos certificados que forem ativados
pelo BC para os seus softwares clientes em até 7 dias após a ativação.
Com base nas informações dos certificados que constarem no arquivo – incluindo o
campo CN ou SAN, onde constará o site de QR Code dos demais participantes –, cada
participante terá meios de implementar em seus aplicativos a validação, tanto do site
como do certificado associado, no momento da leitura de um QR Code dinâmico,
conforme descrito na seção 4.3 deste documento.
Cada PSP deve considerar que pode levar certo tempo para que os demais
participantes propaguem nos seus aplicativos as informações dos certificados de sites
de QR Codes dinâmicos recém cadastrados. Portanto, para evitar indisponibilidades
devido a falhas de validação por parte dos aplicativos dos demais participantes,
recomenda-se que cada PSP só implemente um novo certificado em seu(s) site(s) de
QR Codes dinâmicos 7 dias após seu cadastro junto ao BC.
Recomenda-se ainda que cada instituição utilize certificados distintos, exclusivos para
cada finalidade.
30
5.4. Ativação de certificados digitais do BC
Processo de ativação:
Processo de ativação:
28
Disponível somente para os participantes da RSFN, no endereço: http://www.rsfn.net.br
29
O certificado raiz da cadeia deve ser o da “Autoridade Certificadora Raiz Brasileira v10”,
disponível em http://acraiz.icpbrasil.gov.br/credenciadas/RAIZ/ICP-Brasilv10.crt.
31
Todos os certificados – tanto do BC como dos participantes – serão automaticamente
desativados 24 horas antes de sua data de expiração. Tentativas de autenticação com
certificados desativados, bem como as mensagens e requisições assinadas com
chaves privadas associadas a certificados desativados serão rejeitadas pelo BC.
30
A aplicação BC Correio está disponível em: https://bccorreio.bcb.gov.br/bccorreio/.
31
A Central de Atendimento do Pix está disponível nos telefones (61) 3414-5100 e (61) 3553-
5100 ou no e-mail [email protected].
32
inviável efetuar essa verificação de forma online – a cada conexão ou mensagem – por
dois motivos principais:
32
LCRs: Listas de Certificados Revogados providas pelas Autoridades Certificadoras.
33
OCSP: Online Certificate Status Protocol, definido pela RFC 6960, disponível em
https://tools.ietf.org/html/rfc6960.
33
6. Implementação segura de aplicativos,
APIs e outros sistemas
Os aplicativos, APIs34 e outros sistemas relacionados ao Pix devem ser desenvolvidos
seguindo os princípios de proteção de dados pessoais previstos no artigo 6º e outros
dispositivos da Lei Geral de Proteção de Dados (LGPD) 35. De todo modo, é
imprescindível que todos os sistemas envolvidos no Pix sejam desenvolvidos e
implementados de forma segura. Os itens abaixo tratam dos aspectos de segurança
obrigatórios na implementação desses sistemas.
34
O termo API utilizado nesta seção refere-se a quaisquer APIs utilizadas pelos participantes ao
longo de toda a cadeia de provimento de funcionalidades do Pix para seus clientes. Vale ressaltar
que a API Pix, detalhada no Manual de Padrões para Iniciação do Pix, possui requisitos de
segurança próprios que constam naquele Manual.
35
Lei Geral de Proteção de Dados (LGPD): http://www.planalto.gov.br/ccivil_03/_ato2015-
2018/2018/lei/l13709.htm.
36
mTLS ou Mutual TLS authentication: técnica de autenticação mútua utilizando o protocolo TLS,
em que o servidor se identifica com o seu certificado e requer que o cliente se autentique com um
certificado próprio.
37
man-in-the-middle: ataque por meio do qual o atacante intercepta e modifica a comunicação
entre o cliente e o servidor, podendo se passar como uma das partes envolvidas. Mais detalhes
disponíveis em https://csrc.nist.gov/glossary/term/man_in_the_middle_attack.
34
com a segurança do software cliente ou aplicativo. Evita-se, assim, que um
agente malicioso explore eventual falha do cliente ou aplicativo e obtenha
acesso indevido.
5. Os sistemas e APIs devem fornecer apenas as informações estritamente
necessárias para o correto funcionamento dos aplicativos do participante.
a. No caso de consultas por chaves Pix e transações utilizando QR Code,
informações como CPF completo (sem máscara), dados de agência e
conta de destinatários de pagamentos via Pix, bem como informações
para fins de segurança vinculadas às chaves Pix devem ser de uso
exclusivo dos sistemas internos do participante e, portanto, não
devem ser expostas aos seus aplicativos e softwares clientes.
b. A restrição acima não se aplica apenas no caso de transações Pix por
meio de inserção manual de dados bancários nos ambientes Pix e
Open Finance, onde os dados de agência e conta precisarão ser
exibidos.
6. Conforme disposto no Regulamento do Pix38, a base interna de chaves Pix de
cada PSP deve ter mecanismos para:
a. prevenir ataques de leitura de chaves, de forma equivalente aos
mecanismos que constam no item 13 do Manual Operacional do
DICT39;
b. limitar o número de requisições oriundas de um mesmo software
cliente ou aplicativo, de forma equivalente ao controle disposto no
item 15 do Manual Operacional do DICT.
7. A realização de consultas de chaves e transações Pix por meio do site web do
participante só deve ser permitida a usuários devidamente logados, e deve
estar sujeita a mecanismos de segurança que impeçam o uso de robôs e a
automatização de consultas e transações. Dentre os mecanismos possíveis,
constam: autenticação do usuário por dois fatores, CAPTCHA, token em
dispositivo cadastrado previamente, etc.
38
Resolução BCB nº 1, que institui o arranjo de pagamentos Pix e aprova seu Regulamento:
https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Resolu%C3%A7%C3%A3o%
20BCB&numero=1
39
Manual Operacional do DICT: https://www.bcb.gov.br/estabilidadefinanceira/pix
35
7. Logs de auditoria
Esta seção trata dos logs de auditoria que devem ser mantidos por todos os
participantes do Pix, com o objetivo de permitir a rastreabilidade e auditoria das
mensagens transmitidas e recebidas, bem como das transações realizadas no âmbito
do ecossistema de pagamentos instantâneos.
36
Assim como no caso da ICOM, é recomendado que o participante armazene os
cabeçalhos HTTP das requisições e respectivas respostas do DICT. Caso não sejam
armazenados os cabeçalhos HTTP completos, é obrigatório que pelo menos os
cabeçalhos abaixo, quando existentes, sejam armazenados:
• PI-RequestingParticipant;
• PI-PayerId;
• PI-EndToEndId.
37