Cripto-Casino
Torrent Gear
Como funciona a criptografia de dados em sistemas de pagamento
Os sistemas de pagamento operam os dados mais sensíveis - PAN (número do cartão), validade, CVV/CVC, 3-DS tokens, adereços bancários, identificadores de carteira. O vazamento deles são multas, revogação de merchant dos bancos/PSP e perda financeira direta. A segurança é construída em camadas múltiplas: criptografia em canal (TLS), criptografia e/ou tocenização em armazenamento, gerenciamento rigoroso de chaves e plug-ins de hardware (HSM). Abaixo, toda a linha de montagem de segurança com uma linguagem simples.
Tijolos básicos
Criptografia simétrica
Algoritmos: AES-GCM/CTR/CBC (em pagamentos de fato padrão AES-GCM).
Os benefícios são alta velocidade, chaves compactas.
Contras: É preciso negociar a chave com segurança e IV/nonce.
Criptografia assimétrica
Algoritmos: RSA-2048/3072, ECC (P-256/384, Ed25519).
Uso: troca/envio de chaves, assinaturas, PKI, certificados TLS.
Os benefícios não exigem segredos comuns com antecedência.
Contras: mais lento do que a criptografia simétrica.
Идея Perfect Forward Secrecy (PFS)
As chaves de sessão são negociadas com ECDHE. Mesmo que a chave privada do servidor alguma vez tenha vazado, as sessões passadas serão indefensáveis.
Criptografia no caminho: TLS 1. 2/1. 3
1. Aperto de mão (TLS handshake): cliente e servidor aceitam versões/cifra, o servidor apresenta certificado (PKI), trocam chaves efêmeras (ECDHE) → uma chave simétrica de sessão nasce.
2. Dados: transmitidos em modos AEAD (AES-GCM/ChaCha20-Poly1305) com autenticação.
3. Otimização: TLS 1. 3 reduz rodadas, suporta resumpção; 0-PTT é usado com cuidado (apenas consultas idumpotentes).
4. Prática de pagamento: proibindo SSLv3/TLS1. 0/1. 1, incluímos o TLS1. 2/1. 3, OCSP stapling, HSTS, cabeçalhos de segurança rigorosos.
Criptografia de armazenamento: at rest
Opções
Criptografia completa de volume/BD (TDE): Introduz-se rapidamente, protege-se do acesso «frio» à mídia, mas não do vazamento através de uma aplicação comprometida.
Campo de bits/nível (FLE): os campos individuais (PAN, BAN) são criptografados. Granular, mas difícil de implementar e indexar.
Criptografia de formatação (FPE): útil quando você precisa de «16 dígitos como 16 dígitos».
Toquenização: o PAN é substituído pelo token (linha sem sentido); O verdadeiro PAN é armazenado em token vault sob proteção reforçada. O pagamento/reembolso usa o token → o merchant não processa cartões crus.
Ideia-chave
O armazenamento não é mais importante do que «que algoritmo», mas onde estão as chaves e quem pode detonar. Por isso...
Gestão de chaves: KMS, HSM e envelopes
Hierarquia de chaves (envelope encrypition)
Root/KEK (Key Encrypition Key): Alta classe de proteção armazenada e executada no HSM.
DEK (Data Encrypition Key): criptografa dados/lotes/tabelas específicos; criptografado pelo KEC.
Rotação: regulamentos de rotação programada e não programada (no incidente) KEK/DEK; a versão das chaves é indicada nos metadados da cifra.
HSM (Hardware Security Module)
Um módulo de hardware certificado (por exemplo, FIPS 140-2/3) que armazena e realiza operações com chaves dentro de si.
Não dá chaves privadas para fora, suporta limites/políticas de uso, auditoria.
Usado para gerar chaves, embrulhos DEK, chaves de servidor 3-DS, chaves EMV, operações PIN, assinaturas de mensagens.
KMS
Centraliza a política de chaves, versionização, acessibilidade, revistas e API.
Em conexão com o HSM, implementa encrypition e rotação automática.
Padrões de cartas e especificidades da indústria
PCI DSS (e lógica de minimização)
A ideia principal é não armazenar CVV, minimizar a área de processamento do PAN (scope).
Quando possível - digitar PAN para Hosted Fields/Iframe PSP → o merchant não tem acesso a dados crus.
Logs, bacapes, dampas são as mesmas regras de protos, disfarce, encriptação, reticência.
EMV, PIN и POS
EMV chip/contato-less: criptogramas em nível de cartão/terminal, proteção contra clonagem de banda maga.
Blocos PIN e ISO 9564: PIN é encriptado de pin-pin a processamento, e funciona com HSM (traduções pin, áreas-chave).
DUKPT (Derived Unique Key Per Direction): em POS, cada pagamento é criptografado com uma chave única derivada do BDK → o comprometimento de uma mensagem não leva a outra.
PCI P2PE: sistema de criptografia de pin-pin certificado até o provedor de transcrição.
3-D Secure (2. x)
Autenticação do portador de cartão → menor do que o frode/charjbeek.
A criptografia é usada para assinaturas de mensagens, compartilhamento de chaves ACS/DS/3DS Server; chaves privadas normalmente no HSM.
Arquiteturas típicas de proteção de dados
Opção A (merchant online com PSP):- O navegador → HTTPS → Hosted Fields PSP (PAN não chega ao merchant).
- O PSP devolve o payment tocen.
- A base de dados de merchant armazena o token + os últimos 4 dígitos e o BIN (para UX e regras).
- Devoluções/repetições, apenas por token.
- Segredos/chaves - KMS, chaves privadas TLS/3-DS - HSM.
- Aplicativo ↔ API - TLS/mTLS.
- Campos sensíveis - FLE/FPE ou toquenização; vault está isolado.
- Acesso à detonação somente por papéis de serviço com «quatro olhos» e operações por HSM.
- Pin-pad → DUKPT/P2PE → processamento.
- As chaves de carregamento do terminal são feitas através de injetores-chave protegidos/HSM.
- Registro, anti-tamper proteção de dispositivos.
Rotação, auditoria e incidentes
Rotação de chaves: programado (X m.) e por evento (comprometimento). DEK rewrap sob o novo KEK sem decifrar dados do usuário.
Registros imutáveis: quem e quando acessou a detonação/chave; assinatura de logs.
Runbook comprometimento: revoke/rotate imediato, revezamento de certificados, unidade de API, notificação de parceiros, retrospectiva.
Erros frequentes e como evitá-los
1. «Estamos a encriptar o banco de dados».
Não. A aplicação comprometida lê os dados em aberto. É preciso o torneamento/FLE e o princípio dos direitos mais baixos.
2. Armazenamento CVV.
Não podes. O CVV nunca é armazenado, nem mesmo encriptado (PCI DSS).
3. As chaves estão perto dos dados.
Não podes. As chaves estão no KMS/HSM, acesso por papéis, menos privilégios, contas individuais.
4. Não há rotação/versão.
Sempre versionize as chaves, guarde 'key _ version' nos metadados da cifra.
5. O TLS está apenas no perímetro.
Criptografe atrás do CDN/WAF e dentro do plano de dados (servis→servis, webhooks).
6. Toquenização «para a vista».
Se detokenize pode qualquer serviço não é uma proteção. Limite a um círculo estreito e verifique as chamadas.
7. Bacapes não contabilizados/descarga analítica.
Criptografia e camuflagem devem ser estendidos a bacapes, snapshots, vitrines BI, logs.
Folha de cheque de implementação (resumido)
Canal
TLS 1. 2/1. 3, PFF, mTLS para HSTs, HSTS, segurança-headers rigorosos.
Armazenamento
Tocenização PAN, proibição de armazenamento CVV.
FLE/FPE para campos críticos; TDE como camada básica.
Chaves
KMS + HSM, envelope encrypition (KEK/DEK), rotação/versão, revistas imutáveis.
Arquitetura
Hosted Fields/SDK PSP, minimização da área PCI.
Separação de papéis/redes, zero trust, segredos - apenas através de um gerente de segredo.
Operações
Pentest/Red Team no perímetro e na lógica do negócio.
DLP/CTI monitoramento de ameixas, treinamento de pessoal.
Runbook на compromise: revoke/rotate/notify.
Mini FAQ
O que é melhor para o PAN: criptografia ou tocenização?
Na venda, toquenização (minimiza scope). Em vault - criptografia com HSM/KMS.
O certificado EV é necessário para o domínio de pagamento?
Não obrigatório. Mais importante que um perfil TLS correto, mTLS, chaves no HSM e disciplina.
Você pode usar o 0-PTT no TLS 1. 3 para pagamentos?
Para GET Idumpotentes, sim. Para POST, é melhor desligar ou limitar.
Como guardar os últimos 4 e BIN?
Separado do PAN; não são dados sensíveis ao isolar corretamente, mas mantenham o disfarce nos logs/BI.
A criptografia em sistemas de pagamento não é um único tumbler, mas um ecossistema: TLS/PFS no canal, tocenização e/ou FLE em armazenamento, gestão rigorosa de chaves via KMS + HSM, padrões de indústria (PCI DSS, EMV, 3-DS), rotatividade e auditoria. Essa arquitetura em camadas torna muito improvável a fuga de dados de cartas, facilita a realização de áudios e, sobretudo, mantém a confiança dos bancos, parceiros de pagamento e usuários.