Preparatório Caixa TI: Criptografia e segurança em aplicações e redes

Criptografia: objetivos e onde ela entra na prática

Em aplicações e redes, criptografia é usada para atingir três objetivos principais: confidencialidade (ninguém lê o conteúdo), integridade (ninguém altera sem ser detectado) e autenticidade/não repúdio (provar quem enviou/aprovou). Na prática, esses objetivos aparecem em cenários como: proteger tráfego HTTP com TLS, armazenar senhas com hash forte, assinar transações, criptografar dados em disco e validar identidades com certificados.

Criptografia simétrica

Conceito

Na criptografia simétrica, a mesma chave é usada para criptografar e descriptografar. É rápida e adequada para grandes volumes de dados (arquivos, backups, tráfego de sessão). O desafio é como compartilhar a chave com segurança.

Algoritmos e modos (visão prática)

• AES é o padrão mais comum (128/192/256 bits).
• Evite “criptografia caseira” e modos inseguros. Prefira modos autenticados como AES-GCM (confidencialidade + integridade).
• Conceitos importantes: IV/nonce (valor único por operação) e reutilização (reusar nonce em GCM é crítico e pode quebrar a segurança).

Passo a passo prático (exemplo de uso correto)

• 1) Gerar uma chave simétrica forte (aleatória, tamanho adequado).
• 2) Para cada mensagem/arquivo, gerar um nonce/IV único.
• 3) Criptografar usando AES-GCM, obtendo: ciphertext + tag de autenticação.
• 4) Armazenar/transmitir: nonce + ciphertext + tag (a chave nunca vai junto).
• 5) Na leitura, validar a tag antes de aceitar o conteúdo (se falhar, rejeitar).

Estrutura típica: [nonce || ciphertext || tag]

Criptografia assimétrica (chave pública/privada)

Conceito

Na criptografia assimétrica, há um par de chaves: pública (pode ser divulgada) e privada (mantida em segredo). Ela é mais lenta, mas resolve problemas de distribuição de chaves e habilita assinaturas digitais.

Usos típicos

• Troca de chaves (ex.: ECDHE no TLS) para estabelecer uma chave simétrica de sessão.
• Assinatura digital (ex.: ECDSA/RSA-PSS) para provar autoria e integridade.
• Criptografia de pequeno volume (menos comum hoje para dados grandes; geralmente usa-se híbrido).

Criptografia híbrida (o padrão em sistemas reais)

Em sistemas reais, combina-se assimétrica + simétrica: a assimétrica é usada para negociar/transportar uma chave de sessão, e a simétrica protege o tráfego/dados.

Passo a passo prático (modelo híbrido)

• 1) Cliente obtém a chave pública do servidor (via certificado).
• 2) Cliente e servidor executam um protocolo de troca de chaves (ex.: ECDHE) e derivam um segredo compartilhado.
• 3) A partir desse segredo, derivam chaves simétricas (criptografia e integridade).
• 4) A comunicação segue com AES-GCM/ChaCha20-Poly1305 (rápido e seguro).

Hash criptográfico

Conceito

Hash é uma função que transforma uma entrada em uma saída de tamanho fixo. Um hash criptográfico deve ter propriedades como resistência a colisão e resistência a pré-imagem. Hash não é criptografia reversível: não existe “descriptografar hash”.

Continue em nosso aplicativo

Você poderá ouvir o audiobook com a tela desligada, ganhar gratuitamente o certificado deste curso e ainda ter acesso a outros 5.000 cursos online gratuitos.

ou continue lendo abaixo...

Baixar o aplicativo

Usos corretos

• Integridade: comparar hash de um arquivo baixado com o hash esperado.
• Base para assinaturas: assina-se o hash do documento, não o documento inteiro.
• Derivação (em conjunto com KDFs) e autenticação (via HMAC).

Algoritmos comuns

• SHA-256/SHA-512: amplamente usados.
• Evitar: MD5 e SHA-1 para segurança (colisões conhecidas).

HMAC (Hash-based Message Authentication Code)

Conceito

HMAC combina um hash com uma chave secreta para garantir integridade + autenticidade da mensagem. Diferente de “hash puro”, o HMAC impede que um atacante gere um código válido sem conhecer a chave.

Passo a passo prático (validação de requisições)

• 1) Cliente e servidor compartilham uma chave secreta (armazenada com segurança).
• 2) Cliente monta a mensagem (ex.: método + caminho + corpo + timestamp).
• 3) Cliente calcula HMAC-SHA256 da mensagem e envia o resultado no header.
• 4) Servidor recalcula o HMAC com a mesma chave e compara em tempo constante.
• 5) Se bater, aceita; se não, rejeita.

Exemplo de string a assinar: METHOD + "\n" + PATH + "\n" + TIMESTAMP + "\n" + BODY_HASH

Boas práticas: incluir timestamp e/ou nonce para mitigar replay; usar comparação em tempo constante para reduzir risco de ataques por timing.

Assinaturas digitais

Conceito

Assinatura digital usa a chave privada para assinar e a chave pública para verificar. Garante: integridade (qualquer alteração invalida), autenticidade (quem assinou) e não repúdio (dificulta negar a autoria, dependendo do controle da chave privada).

Passo a passo prático (assinando um documento/transação)

• 1) Calcular o hash do conteúdo (ex.: SHA-256).
• 2) Assinar o hash com a chave privada (ex.: ECDSA ou RSA-PSS).
• 3) Enviar conteúdo + assinatura + (opcionalmente) certificado do assinante.
• 4) O verificador calcula o hash do conteúdo recebido.
• 5) Verifica a assinatura com a chave pública (obtida do certificado).

Observação prática: a assinatura não “esconde” o conteúdo; ela prova integridade e autoria.

Certificados digitais, PKI e cadeia de confiança

Conceito de certificado

Um certificado (ex.: X.509) vincula uma chave pública a uma identidade (domínio, organização, pessoa). Ele é assinado por uma Autoridade Certificadora (CA), criando confiança verificável.

PKI (Public Key Infrastructure)

PKI é o conjunto de processos e componentes que permitem emitir, gerenciar e validar certificados: CAs, políticas, emissão/renovação, revogação e validação.

Cadeia de confiança (chain of trust)

Quando um cliente acessa um servidor HTTPS, ele valida uma cadeia: certificado do servidor (leaf) → intermediária(s) → CA raiz (root) confiável instalada no sistema/navegador. Se a assinatura e as regras forem válidas, a chave pública do servidor é aceita como pertencente àquele domínio.

Verificações essenciais na validação de certificado

• Assinatura do certificado (cadeia até uma raiz confiável).
• Validade (datas).
• Nome do domínio (CN/SAN deve corresponder ao host acessado).
• Uso pretendido (EKU/KU, quando aplicável).
• Revogação (CRL/OCSP, dependendo do cenário).

TLS/HTTPS: como a segurança acontece “na rede”

O que o TLS entrega

• Confidencialidade: criptografia do tráfego.
• Integridade: detecção de alteração.
• Autenticação: normalmente do servidor via certificado; opcionalmente do cliente (mTLS).

Troca de chaves (visão conceitual e prática)

No TLS moderno, é comum usar (EC)DHE para troca de chaves efêmeras, fornecendo Perfect Forward Secrecy (PFS): mesmo que a chave privada do servidor vaze no futuro, sessões passadas permanecem protegidas.

Passo a passo prático (handshake simplificado)

• 1) Cliente inicia conexão e informa versões/ciphers suportados.
• 2) Servidor responde com parâmetros e envia seu certificado.
• 3) Cliente valida o certificado (cadeia, domínio, validade).
• 4) Cliente e servidor realizam a troca (EC)DHE e derivam chaves de sessão.
• 5) A partir daí, dados trafegam criptografados e autenticados (ex.: AES-GCM).

Ponto de prova: HTTPS = HTTP sobre TLS. Sem validação correta do certificado, perde-se a autenticação e abre-se espaço para MITM.

Senhas: armazenamento seguro (salt e algoritmos de hash para senha)

Por que não usar “hash simples” (ex.: SHA-256) para senha

Senhas têm baixa entropia (usuários escolhem padrões previsíveis). Se você armazenar SHA-256(senha), um atacante pode usar força bruta e tabelas rainbow rapidamente. Para senha, o objetivo é tornar tentativas caras e únicas por usuário.

Salt

Salt é um valor aleatório único por usuário, armazenado junto com o hash. Ele impede que duas senhas iguais gerem o mesmo hash e dificulta ataques pré-computados.

bcrypt/Argon2 (nível conceitual)

• bcrypt: função de hash adaptativa (custo configurável), amplamente suportada.
• Argon2: projetada para ser resistente a ataques com GPU/ASIC, com parâmetros de memória/tempo.

Passo a passo prático (cadastro e login)

• Cadastro: 1) gerar salt aleatório; 2) calcular hash de senha com bcrypt/Argon2 usando parâmetros de custo; 3) armazenar: algoritmo + parâmetros + salt + hash.
• Login: 1) recuperar registro do usuário; 2) recalcular hash com os mesmos parâmetros e salt; 3) comparar de forma segura; 4) aplicar políticas como rate limiting e bloqueio progressivo.

Armazenar: $algoritmo$parametros$salt$hash  (formato conceitual)

Boas práticas adicionais: nunca armazenar senha em texto, nunca “descriptografar senha”, usar MFA quando aplicável e proteger o banco (princípio do menor privilégio).

Criptografia em repouso e em trânsito

Em trânsito

Protege dados enquanto trafegam entre cliente e servidor (ou entre serviços internos). Prática comum: TLS em APIs, bancos de dados (conexão TLS), mensageria e integrações.

• Mitigação típica: TLS bem configurado, validação de certificado, desabilitar versões antigas, preferir suites modernas.
• Em ambientes internos: considerar mTLS para autenticar ambos os lados.

Em repouso

Protege dados armazenados (disco, backups, objetos). Pode ser em nível de disco/volume, banco de dados, coluna/campo ou aplicação.

• Criptografia de disco/volume: protege contra perda/roubo de mídia; não substitui controles de acesso.
• Criptografia no banco: TDE (transparente) ou por campo; útil para reduzir impacto de vazamento de arquivos de dados/backups.
• Criptografia na aplicação: útil quando se quer que nem o banco veja o dado em claro; exige bom gerenciamento de chaves.

Gerenciamento de chaves (pontos de prova)

• Separar chaves dos dados (não deixar chave no mesmo local do backup).
• Rotação e versionamento de chaves.
• Controle de acesso e auditoria de uso de chaves.
• Preferir envelopes: chave de dados (DEK) criptografada por uma chave mestra (KEK).

Vulnerabilidades comuns e mitigações

Phishing

Engana o usuário para revelar credenciais ou aprovar ações. Não é “quebra de criptografia”, mas contorna a segurança.

• Mitigações: educação e simulações, MFA, verificação de domínio, filtros anti-phishing, proteção de e-mail, políticas de senha e monitoramento de login anômalo.
• Em aplicações: usar WebAuthn/FIDO2 quando possível (reduz eficácia de phishing), e alertas de novo dispositivo/local.

MITM (Man-in-the-Middle)

Atacante intercepta e possivelmente altera o tráfego entre cliente e servidor.

• Mitigações: TLS com validação correta de certificado, HSTS em web, evitar aceitar certificados inválidos, mTLS em serviços internos sensíveis.
• Em APIs: validar hostname, cadeia e revogação conforme política; não desabilitar verificação em produção.

Replay

Atacante captura uma requisição válida (ou token) e a reenvia para repetir uma ação (ex.: transferência).

• Mitigações: nonce único por requisição, timestamp com janela curta, tokens com expiração, idempotency keys, e vincular assinatura/HMAC ao nonce/timestamp.

Exemplo de mitigação: assinar (HMAC) também o timestamp e um nonce; servidor rejeita nonce repetido.

Questões de diferenciação: algoritmos e cenários de uso correto

1) Hash x criptografia

Pergunta: “Quero armazenar senhas. Uso AES para poder recuperar depois?”

Resposta esperada: Não. Senha deve ser verificada, não recuperada. Use hash de senha (bcrypt/Argon2) com salt. AES é reversível e aumenta o impacto de vazamento da chave.

2) Integridade: hash puro x HMAC

Pergunta: “Para garantir que uma mensagem não foi alterada, basta enviar SHA-256(mensagem)?”

Resposta esperada: Não garante autenticidade. Um atacante pode alterar a mensagem e recalcular o hash. Use HMAC (chave compartilhada) ou assinatura digital (chave privada).

3) Assinatura digital x criptografia assimétrica

Pergunta: “Assinatura digital serve para manter o conteúdo secreto?”

Resposta esperada: Não. Assinatura prova autoria/integridade. Para sigilo, use criptografia (geralmente simétrica) e, se necessário, um esquema híbrido para distribuir a chave.

4) Simétrica x assimétrica no desempenho

Pergunta: “Por que TLS não usa RSA/ECC para criptografar todo o tráfego?”

Resposta esperada: Porque assimétrica é mais lenta. Usa-se assimétrica para negociar chaves e simétrica (AES-GCM/ChaCha20-Poly1305) para o tráfego.

5) Certificado e cadeia de confiança

Pergunta: “Se o servidor envia um certificado, isso já prova que ele é legítimo?”

Resposta esperada: Só se o cliente validar a cadeia até uma CA confiável, conferir domínio, validade e demais restrições. Aceitar certificado inválido abre espaço para MITM.

6) Replay em APIs

Pergunta: “Uma API usa HMAC, então está imune a replay?”

Resposta esperada: Não necessariamente. Se a mesma requisição assinada puder ser reenviada, o atacante pode repetir a ação. É preciso incluir nonce/timestamp e rejeitar repetição.

7) Criptografia em repouso: o que ela não resolve

Pergunta: “Criptografar o banco elimina risco de vazamento por SQL Injection?”

Resposta esperada: Não. Se o atacante consegue consultar via aplicação, ele pode obter dados já em claro (após decriptografia). Criptografia em repouso reduz impacto de roubo de mídia/backups; não substitui validação de entrada, controle de acesso e hardening.