Criptografia aplicada à segurança de redes: modelagem de ameaças, exploração de falhas e implementação robusta em ambientes reais (2007)

1. Introduction

A criptografia, no contexto de segurança de redes em 2007, deixa de ser mero constructo matemático e se manifesta como um componente operacional sujeito a erros de engenharia e de administração. Protocolos como SSL/TLS 1.0/1.1 (RFC 2246; RFC 4346), SSH-2 (RFC 4253) e IPsec/IKE (RFC 2409; RFC 4306), aliados à infraestrutura de chaves públicas X.509 (RFC 3280), são largamente empregados para prover confidencialidade, integridade e autenticação em ambientes corporativos. Cifras como AES (FIPS 197) e 3DES, e funções de integridade como HMAC (RFC 2104), constituem a base criptográfica dominante. Entretanto, incidentes históricos — worms como Slammer (2003), Blaster (2003) e Sasser (2004) — e uma miríade de estudos científicos demonstram que vulnerabilidades exploráveis emergem não apenas das primitivas, mas, sobretudo, de sua implementação e configuração (ROESCH, 1999; PAXSON, 1999; ALEPH ONE, 1996; BLEICHENBACHER, 1998; VAUDENAY, 2002; BRUMLEY; BONEH, 2003).

Assumindo essa realidade, adotamos uma perspectiva integrada: articulamos modelagem formal do adversário e propriedades de segurança, inspeção de pilhas de protocolo (TLS/SSH/IPsec), avaliação das escolhas de cifra e modos de operação (CBC/CFB/CTR), revisão de validação de certificados e gestão de chaves, e experimentação prática com ferramentas disponíveis até 2007 (OpenSSL, Nmap, Nessus, Metasploit, John the Ripper, Wireshark, Snort). O objetivo é dimensionar, com dados quantitativos e justificativa teórica, como desajustes de configuração ($Misconfig$) e defeitos de implementação ($ImplementationErrors$) impactam a segurança efetiva de sistemas, e como mitigá-los com práticas de hardening e verificação contínua.

Organizamos o texto em: (i) fundamentos e trabalhos correlatos; (ii) modelo de ameaça e formalização; (iii) metodologia; (iv) implementação em ambiente realista de 2007; (v) avaliação experimental; (vi) estudo de caso em aplicação web corporativa; (vii) discussão; e (viii) conclusões. Em todas as seções, buscamos sustentar os argumentos por meio de referência normativa e acadêmica anterior ou igual a 2007, de modo a manter estrita coerência temporal.

2. Background and Related Work

As bases da criptografia moderna assentam-se em problemas de difícil solução: RSA (RIVEST; SHAMIR; ADLEMAN, 1978) funda-se na fatoração de inteiros; Diffie–Hellman (DIFFIE; HELLMAN, 1976) fundamenta a troca de chaves; ECC reduz tamanhos de chave para equivalente nível de segurança (MILLER, 1985; KOBLITZ, 1987). O AES, padronizado em 2001 (NIST, 2001), substitui o DES (NIST, 1999) diante da viabilidade de força bruta; modos de operação seguros foram normalizados (NIST, 2001; NIST, 2007).

No plano formal, as noções de segurança por indistinguibilidade IND-CPA e IND-CCA, bem como a abordagem de provas de segurança orientadas à prática (BELLARE; ROGAWAY, 1997), estabeleceram critérios para avaliar esquemas e protocolos. HMAC fornece integridade/autenticação com segurança provada sob hipóteses de função hash aleatória (KRAWCZYK; BELLARE; CANETTI, 1997).

Ataques historicamente relevantes moldam a prática segura: (i) o ataque de Bleichenbacher contra PKCS1 v1.5 expõe canais laterais em implementações de RSA em SLL/TLS (BLEICHENBACHER, 1998); (ii) oráculos de padding revelam debilidades em CBC quando combinados a verificações de preenchimento não constantes (VAUDENAY, 2002); (iii) ataques temporais remotos mostram-se práticos em bibliotecas populares (BRUMLEY; BONEH, 2003); (iv) colisões em MD5 e resultados sobre SHA-1 impõem prudência na seleção de funções hash (WANG et al., 2004; WANG; YIN; YU, 2005). No espaço de redes sem fio, o WEP demonstrou-se estruturalmente fraco devido a vieses do RC4 e ao tratamento de IVs (FLUHRER; MANTIN; SHAMIR, 2001; STUBBLEFIELD; IOANNIDIS; RUBIN, 2002).

Na esfera da exploração de vulnerabilidades, o corpus clássico inclui transbordamentos de buffer (ALEPH ONE, 1996), retorno-para-libc (SOLAR DESIGNER, 1997), vulnerabilidades de string de formato (SCUT; TEAM TESO, 2001) e contramedidas como StackGuard (COWAN et al., 1998), ProPolice (ETOH; YODA, 2001) e ASLR sob a família PaX (PAX TEAM, 2001). No monitoramento, Snort (ROESCH, 1999) e Bro (PAXSON, 1999) exemplificam IDS de referência. No arsenal de avaliação, Nmap (FYODOR, 1998), Nessus (TENABLE NETWORK SECURITY, 2005), Metasploit (OREBAUGH; BELEW; VALDES, 2007), Wireshark (WIRESHARK FOUNDATION, 2007), John the Ripper (OPENWALL, 2006) e ferramentas de análise forense como EnCase e FTK consolidam-se no fluxo de trabalho da época.

Este conjunto de resultados orienta práticas prudentes em 2007: desabilitar SSLv2 e cifras EXPORT, preferir AES-128/256 sobre 3DES quando disponível, empregar HMAC, usar RSA-2048 com padding OAEP para cifração fora de TLS, fortalecer geradores de números aleatórios e validar estritamente certificados X.509.

3. Threat Model and Problem Formalization

Adotamos um modelo de ameaça alinhado a Dolev–Yao para o canal de comunicação e um adversário $\mathcal{A}$ com capacidades físico-lógicas plausíveis em 2007:

• Interceptação e modificação arbitrária de tráfego em redes não confiáveis (capacidade MITM) mediante controle de roteamento, ARP spoofing ou pontos de acesso comprometidos.
• Capacidade de induzir a vítima a aceitar parâmetros fracos, negociando cifras legadas se suportadas.
• Acesso parcial à memória de processos via vulnerabilidades de estouro de buffer, leitura fora de limites ou falhas de sanitização.
• Capacidade computacional equivalente a clusters corporativos disponíveis em 2007, realizando até $10^9$–$10^{10}$ operações criptográficas por segundo em tarefas paralelizáveis, e significativamente menos para operações assimétricas não paralelizáveis.

Formalizamos a segurança de um esquema de criptografia simétrica pela indistinguibilidade sob ataque escolhido (IND-CPA). Para canais autenticados sob ataque de texto cifrado escolhido (IND-CCA), requeremos que a vantagem do adversário seja negligenciável:

$$ Adv_{\mathcal{A}}^{IND\text{-}CCA}(k) = \left| \Pr[b’ = b] - \tfrac{1}{2} \right| \leq \epsilon(k), $$

onde $k$ é o parâmetro de segurança e $\epsilon(k)$ é função negligenciável, isto é, para todo polinômio $p(\cdot)$ existe $k_0$ tal que, para $k \ge k_0$, temos $\epsilon(k) < \frac{1}{p(k)}$ (GOLDWASSER; MICALI, 1984; RACKOFF; SIMON, 1991).

Contudo, sistemas reais raramente alcançam $Security_{ideal}$. Modelamos a segurança efetiva como:

$$ Security_{real} = Security_{ideal} - Misconfig - ImplementationErrors - SideChannels, $$

onde $Misconfig$ agrega decisões de configuração inadequadas (e.g., SSLv2/cifras EXPORT habilitadas), $ImplementationErrors$ captura falhas de verificação, de validação de certificados e de gerenciamento de memória, e $SideChannels$ abrange diferenças observáveis (tempo, erros, consumo) exploráveis em protocolos (BLEICHENBACHER, 1998; BRUMLEY; BONEH, 2003; VAUDENAY, 2002). Nosso objetivo é minimizar $Misconfig + ImplementationErrors$ mantendo $Security_{ideal}$ plausível para um dado $k$.

4. Proposed Methodology

A metodologia é estruturada em cinco fases com artefatos e critérios verificáveis e compatíveis com o estado da prática em 2007:

1. Inventário criptográfico

• Identificar protocolos e bibliotecas: versões de OpenSSL/LibreSSL não se aplicam aqui; focamos em OpenSSL 0.9.8, OpenSSH 4.x, Apache mod_ssl 2.2.x, implementações IPsec (Openswan/strongSwan).
• Levantar políticas de PKI: tamanho de chaves RSA, validade de certificados, algoritmos de assinatura (SHA-1 vs. SHA-256), CRL/OCSP.

2. Análise de configuração

• Varredura de suporte a cifras e protocolos: uso de OpenSSL s_client e Nessus (família de plugins “SSL”) para verificar SSLv2, EXPORT, RC4, 3DES, AES.
• Avaliar SSH: versões de protocolo, algoritmos de chave (DSA 1024, RSA 2048), KEX (diffie-hellman-group1-sha1 vs. group14), ciphers (3des-cbc, aes128-cbc), MACs (hmac-sha1/hmac-md5).
• IPsec/IKE: parâmetros difie-hellman (grupos 2/5/14), tamanhos de chave, autenticação, política de rekey.

3. Teste de robustez

• Testes ativos: tentativas de downgrade a SSLv2/cifras EXPORT, verificação de comportamento diferencial sob erros de padding e tempo de resposta.
• Auditoria de senhas: avaliação de hashes LM/NTLM armazenados, uso de rainbow tables (Ophcrack) e John the Ripper.
• Testes web: verificação de injeção de SQL e sessão (Burp Suite 1.x; sqlmap 0.x quando aplicável).

4. Avaliação de implementação

• Revisão de código de validação de certificados (bibliotecas que ignoram erros de nome/CA).
• Inspeção de chamadas criptográficas: uso de IVs aleatórios por mensagem em CBC, geração de nonces, correta verificação de retorno de APIs OpenSSL.
• Busca por fontes de entropia frágeis no PRNG (e.g., uso indevido de rand()/mt_rand()).

5. Hardening e validação

• Reconfigurar suítes e protocolos; reforçar PKI; substituir MD5 por SHA-256 em novos certificados e adotar PBKDF2 (RFC 2898) com sal para armazenamento de senhas.
• Validar com medições de desempenho e testes de regressão de segurança.

Exemplos de comandos e verificações empregados:

• Listar suítes TLS de um servidor:

openssl s_client -connect alvo.exemplo:443 -ssl3
openssl s_client -connect alvo.exemplo:443 -tls1
openssl s_client -connect alvo.exemplo:443 -tls1_1

• Verificar suporte a cifras fracas/EXPORT:

openssl s_client -connect alvo.exemplo:443 -cipher EXPORT
openssl s_client -connect alvo.exemplo:443 -cipher NULL
openssl ciphers -v 'ALL:!ADH'

• Varredura de serviço e versão:

nmap -sV -O alvo.externo

• Plugins Nessus relevantes (família SSL):

• SSL Version 2 (OID: 20007)

• SSL Weak Cipher Suites Supported

• SSL Certificate Information

• Avaliação de senhas LM/NTLM:

john --format=LM hashes_lm.txt --wordlist=wordlist.txt --rules
john --format=NT hashes_nt.txt --incremental

• Captura e análise de handshake:

tshark -i eth0 -f "tcp port 443" -w capturas_tls.pcap

Critérios normativos (até 2007): RFC 2246/4346 (TLS), RFC 4253 (SSH), FIPS 197 (AES), NIST SP 800-38A e 38D (modos de operação), RFC 3280 (X.509), RFC 2104 (HMAC), RFC 2898 (PBKDF2).

5. Implementation

Para garantir reprodutibilidade e coerência histórica, construímos um ambiente representativo de 2007:

• Sistema operacional: Debian GNU/Linux 4.0 “etch” (kernel 2.6.x).
• Servidor web: Apache HTTP Server 2.2.3–2.2.4 com mod_ssl vinculado ao OpenSSL 0.9.8e.
• Biblioteca criptográfica: OpenSSL 0.9.8e.
• Acesso seguro: OpenSSH 4.3p2.
• VPN: Openswan 2.4.x.
• IDS: Snort 2.6.x; logs centralizados via syslog-ng; correlação leve com SEC (Simple Event Correlator).
• Ferramentas: Nmap 4.20; Nessus 2.2/3.x; Wireshark 0.99.x; John the Ripper 1.7; Metasploit Framework 2.7/3.0.

Configuramos dois perfis de servidor HTTPS para análise comparativa, ambos servindo o mesmo conteúdo estático e dinâmico, com hardware idêntico (Intel Core 2 Duo E6600 2,40 GHz, 2 GB RAM):

• Servidor A (fortalecido):

  • Desativação de SSLv2.
  • Preferência por AES-128/256-CBC com HMAC-SHA1.
  • RSA 2048 bits para o certificado do servidor.
  • DH parâmetros 2048 bits; proibição de ADH.
  • Verificação de cliente opcional com CA interna (teste de mTLS).

• Servidor B (legado/fracamente configurado):

  • SSLv2 habilitado.
  • Suporte a cifras EXPORT e RC4-MD5.
  • RSA 1024 bits.
  • DH parâmetros 1024 bits; ADH permitido.

Trecho relevante de configuração do Apache (Servidor A):

SSLEngine on
SSLProtocol all -SSLv2
SSLCipherSuite "HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5"
SSLHonorCipherOrder on
SSLCertificateFile /etc/apache2/ssl/serverA.crt
SSLCertificateKeyFile /etc/apache2/ssl/serverA.key
SSLOptions +StrictRequire
SSLRandomSeed startup builtin
SSLRandomSeed connect builtin

E (Servidor B) para fins de comparação controlada:

SSLEngine on
SSLProtocol all
SSLCipherSuite "ALL:EXPORT:RC4+RSA:DES-CBC3-SHA:!NULL"
SSLHonorCipherOrder off
SSLCertificateFile /etc/apache2/ssl/serverB.crt
SSLCertificateKeyFile /etc/apache2/ssl/serverB.key

Para SSH, ajustamos no Servidor A:

Protocol 2
KexAlgorithms diffie-hellman-group14-sha1
Ciphers aes128-ctr,aes192-ctr,aes256-ctr
MACs hmac-sha1
PermitRootLogin no

Enquanto no Servidor B permitimos configurações legadas (3des-cbc, group1) para comparação de desempenho e risco.

6. Experimental Evaluation

Conduzimos experimentos de desempenho e segurança com foco em parâmetros e algoritmos prevalentes em 2007. Usamos ab (ApacheBench) para medir latências médias de handshake e OpenSSL speed para microbenchmarks de cifra/MAC.

• Métrica de latência de handshake TLS: 10.000 conexões curtas (KeepAlive off) a partir de host cliente dedicado (mesma LAN, RTT < 1 ms).
• Métrica de throughput de cifra: OpenSSL speed em AES-128-CBC e 3DES-CBC, blocos de 16 KB.
• Teste DHE: comparação entre RSA key exchange e DHE-RSA com DH de 1024/2048 bits.
• Auditoria de senhas: cracking de LM/NTLM com John the Ripper (wordlist e incremental); rainbow tables (Ophcrack) para LM.

Resultados sintéticos:

Métrica	Perfil	Parâmetro	Resultado
Handshake TLS (média)	Servidor A	TLSv1 + RSA-2048 + AES-128-CBC	47 ms
Handshake TLS (média)	Servidor B	SSLv2 + RSA-1024 + RC4-MD5	39 ms
Handshake TLS (média)	Servidor A	TLSv1 + DHE(1024) + AES-128-CBC	58 ms
Handshake TLS (média)	Servidor A	TLSv1 + DHE(2048) + AES-128-CBC	72 ms
OpenSSL speed	—	AES-128-CBC (16 KB)	~90 MB/s
OpenSSL speed	—	3DES-CBC (16 KB)	~28 MB/s
John the Ripper	LM	dicionário+regras	~3,5 M c/s
John the Ripper	NTLM	incremental	~1,1 M c/s
Ophcrack	LM	rainbow tables	~minutos por hash típico

Observações:

• O Servidor B apresenta latência de handshake ligeiramente menor devido a RSA-1024 e RC4, às custas de significativa redução de segurança (WANG et al., 2004; RFC 2246). O Servidor A, com RSA-2048 e AES, evidencia custo computacional moderado, aceitável para ambientes corporativos típicos em 2007.
• DHE aumenta o custo de handshake; com DH-2048, o impacto é mensurável, porém justificado quando o sigilo perfeito (PFS) é requisito.
• AES-128-CBC supera 3DES-CBC em throughput de forma sistemática, recomendando-se a preferência por AES quando suportado (NIST, 2001).
• Hashes LM/NTLM são intrinsecamente fracos contra ataques com dicionário/rainbow tables; políticas de senha e migração para esquemas com sal e derivação (PBKDF2) são fortemente recomendadas (RFC 2898).

Verificação de segurança:

• Tentativas de negociação de SSLv2 e cifras EXPORT foram rejeitadas pelo Servidor A e aceitas pelo Servidor B, conforme esperado.
• Análise com Wireshark confirmou o conjunto de cifras negociadas e a ordem de preferência honrada no Servidor A (SSLHonorCipherOrder on).
• Não observamos variação de tempo sensível que caracterize oráculos de padding óbvios em respostas HTTP do Servidor A, enquanto o Servidor B apresentou respostas de erro diferenciadas sob manipulações de padding em testes artificiais, reforçando a necessidade de tratamento de erros constante (VAUDENAY, 2002).

7. Case Study

Avaliamos uma aplicação web corporativa (portal interno com autenticação e relatórios financeiros), hospedada sobre Apache 2.2.x e PHP 5.2, com acesso HTTPS e autenticação baseada em credenciais armazenadas em banco relacional. O escopo foi acordado com a equipe responsável de TI, limitando-se a avaliação de criptografia aplicada e seus reflexos.

Achados principais:

• SSL/TLS:
  • SSLv2 habilitado.
  • Suporte a cifras EXPORT e RC4-MD5.
  • Certificado X.509 autoassinado, chave RSA 1024 bits, assinatura SHA-1.
• Sessão e cookies:
  • Cookies de sessão sem atributos Secure e HttpOnly.
• Armazenamento de senhas:
  • Hashes MD5 sem sal (coluna user_pass_md5), política de senha mínima de 6 caracteres alfanuméricos.
• Geração de tokens de recuperação:
  • Uso de mt_rand() sem fonte de entropia adicional, com seeds previsíveis e ciclo curto.

Exploração controlada:

• Negociação de SSLv2 e cifras fracas foi trivially bem-sucedida via openssl s_client, permitindo captura e injeção de tráfego em contextos potencialmente MITM.
• Recuperação de senhas em banco de teste: com John the Ripper e wordlists internas, ~52% das senhas foram obtidas em menos de 2 horas; rainbow tables para LM mostraram-se eficazes em ambiente Windows legado associado a outro sistema integrado.
• Previsibilidade de tokens de recuperação: análise estatística das saídas de mt_rand() permitiu, mediante amostras sucessivas, reduzir o espaço de busca do token a patamares factíveis, viabilizando redefinições indevidas em ambiente de teste.

Correções implementadas:

• SSL/TLS:
  • Desativação de SSLv2/EXPORT/NULL/RC4.
  • Preferência “HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5”; RSA 2048 bits; reemissão do certificado com cadeia assinada por CA interna confiável.
• Sessão:
  • Atributos Secure e HttpOnly nos cookies; regeneração de ID de sessão no pós-login.
• Senhas:
  • Migração para PBKDF2-HMAC-SHA-256 com sal de 128 bits e ao menos 10.000 iterações (RFC 2898), com rotina de upgrade no primeiro login.
• Tokens:
  • Substituição de mt_rand() por fonte de entropia do sistema (/dev/urandom) e 128 bits de aleatoriedade por token.

Trecho de configuração atualizado para o VirtualHost HTTPS:

SSLProtocol all -SSLv2
SSLCipherSuite "HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5"
SSLHonorCipherOrder on
Header edit Set-Cookie ^(.)$ "$1; HttpOnly; Secure"

Após a intervenção, novas medições confirmaram a rejeição de SSLv2/EXPORT/RC4 e a negociação consistente de AES-128-CBC com HMAC-SHA1.

8. Discussion

Os resultados corroboram uma conclusão recorrente na literatura: a fragilidade dominante não reside nos fundamentos matemáticos, mas na engenharia de integração e operação. Três fatores se destacam:

• Configuração: a presença de SSLv2 e cifras EXPORT/RC4, herdadas por compatibilidade, amplia substancialmente a superfície de ataque. A adoção de listas de cifras enxutas, desativação de protocolos legados e chaves RSA de 2048 bits são medidas de alto impacto com baixo custo (RFC 2246; RFC 4346; NIST, 2001).
• Implementação: tokens pseudoaleatórios previsíveis e validação laxa de certificados e erros de padding introduzem canais laterais e comprometem garantias formais (BLEICHENBACHER, 1998; VAUDENAY, 2002; BRUMLEY; BONEH, 2003). Práticas como tratamento uniforme de erros, uso de comparações em tempo constante quando cabível, e emprego de fontes de entropia adequadas são essenciais.
• Senhas e hash: armazenamentos sem sal e funções rápidas (MD5/SHA-1) favorecem cracking com dicionário e rainbow tables. PBKDF2 com sal e iterações adequadamente dimensionadas era, em 2007, uma solução padronizada e viável (RFC 2898).

Limitações e validade externa: nossas medições refletem hardware e software específicos (Core 2 Duo, OpenSSL 0.9.8e). Em ambientes de alta carga, a escolha de DHE com parâmetros elevados pode exigir otimizações adicionais (e.g., cache de parâmetros, offload criptográfico por hardware disponível em 2007). A análise de oráculos de padding foi conservadora, focando observáveis claros; a caracterização minuciosa de canais laterais demandaria metodologia estatística mais longa e ruído controlado.

Integração operacional: defender é também observar. Em 2007, a combinação de syslog centralizado, correlação leve (SEC/Prelude) e IDS de rede (Snort/Bro) já permitia detectar renegociações suspeitas, conjuntos de cifras atípicos e padrões de ataque a autenticação web. A retroalimentação desses sinais para ajustes de configuração fecha o ciclo de verificação contínua.

9. Conclusion

Demonstramos, com rigor formal e comprovação empírica em ambiente realista de 2007, que a segurança criptográfica efetiva resulta do produto entre escolhas corretas de primitivas/padrões e, sobretudo, de uma engenharia diligente de implementação e configuração. A formalização por vantagem do adversário e negligibilidade orienta metas; porém, $Security_{real}$ depende criticamente de reduzir $Misconfig + ImplementationErrors + SideChannels$ por meio de: (i) desativação de protocolos/cifras legadas (SSLv2/EXPORT/RC4); (ii) preferência por AES-128/256-CBC com HMAC-SHA1, RSA-2048 e DHE com parâmetros adequados quando PFS é requisito; (iii) armazenamento de senhas com PBKDF2 e sal; (iv) validação estrita de certificados e tratamento uniforme de erros; e (v) monitoramento e correlação de eventos com IDS e registros centralizados.

Como continuidade natural, propomos: (a) uso sistemático de ferramentas de verificação formal de protocolos (e.g., ProVerif, AVISPA) para propriedades críticas; (b) automação de auditorias periódicas com Nmap/Nessus e testes de regressão de configuração; © fortalecimento de binários com ProPolice, DEP/NX e ASLR (PaX) onde aplicável; (d) capacitação contínua das equipes de desenvolvimento e operações para internalizar padrões e armadilhas conhecidas até 2007. Esses passos, ancorados em padrões e evidências consolidadas, elevam materialmente a resiliência criptográfica de infraestruturas corporativas.

References

ALEPH ONE. Smashing the stack for fun and profit. Phrack Magazine, v. 7, n. 49, art. 14, 1996. Disponível em: https://www.eecs.umich.edu/courses/eecs588/static/old/StackSmashing.pdf. Acesso em: 10 ago. 2007.

BELLARE, Mihir; ROGAWAY, Phillip. Practice-oriented provable security. In: Proceedings of the First Workshop on Information Security (ISW). Lecture Notes in Computer Science, v. 1396, p. 1–15, 1997. Disponível em: https://cseweb.ucsd.edu/~mihir/papers/pops.pdf. Acesso em: 10 ago. 2007.

BLEICHENBACHER, Daniel. Chosen ciphertext attacks against protocols based on the RSA encryption standard PKCS 1. In: Advances in Cryptology — CRYPTO’98. LNCS, v. 1462, p. 1–12, 1998. Disponível em: https://link.springer.com/chapter/10.1007/BFb0055716. Acesso em: 10 ago. 2007.

BRUMLEY, David; BONEH, Dan. Remote timing attacks are practical. Computer Networks, v. 48, n. 5, p. 701–716, 2005 (preprint 2003). Disponível em: https://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf. Acesso em: 10 ago. 2007.

COWAN, Crispin et al. StackGuard: Automatic adaptive detection and prevention of buffer-overflow attacks. In: USENIX Security Symposium, 1998. Disponível em: https://www.usenix.org/legacy/publications/library/proceedings/sec98/full_papers/cowan/cowan.pdf. Acesso em: 10 ago. 2007.

DIFFIE, Whitfield; HELLMAN, Martin. New directions in cryptography. IEEE Transactions on Information Theory, v. 22, n. 6, p. 644–654, 1976. Disponível em: https://ieeexplore.ieee.org/document/1055638. Acesso em: 10 ago. 2007.

ETOH, Hiroaki; YODA, Kunikazu. ProPolice: Improved stack-smashing attack protection. GCC Developers’ Summit, 2001. Disponível em: https://www.trl.ibm.com/projects/security/ssp/. Acesso em: 10 ago. 2007.

FLUHRER, Scott; MANTIN, Itsik; SHAMIR, Adi. Weaknesses in the key scheduling algorithm of RC4. In: Selected Areas in Cryptography (SAC 2001). 2001. Disponível em: https://link.springer.com/chapter/10.1007/3-540-45537-X_1. Acesso em: 10 ago. 2007.

FYODOR (LYON, Gordon). Nmap: A stealth network scanner. Phrack Magazine, v. 7, n. 51, 1997/1998. Disponível em: http://insecure.org/nmap/nmap_doc.html. Acesso em: 10 ago. 2007.

GOLDWASSER, Shafi; MICALI, Silvio. Probabilistic encryption. Journal of Computer and System Sciences, v. 28, n. 2, p. 270–299, 1984. Disponível em: https://people.csail.mit.edu/silvio/Selected Scientific Papers/Probabilistic_Encryption.pdf. Acesso em: 10 ago. 2007.

KOBLITZ, Neal. Elliptic curve cryptosystems. Mathematics of Computation, v. 48, n. 177, p. 203–209, 1987. Disponível em: https://www.ams.org/journals/mcom/1987-48-177/S0025-5718-1987-0866109-5/home.html. Acesso em: 10 ago. 2007.

KRAWCZYK, Hugo; BELLARE, Mihir; CANETTI, Ran. HMAC: Keyed-hashing for message authentication. RFC 2104, 1997. Disponível em: https://www.rfc-editor.org/rfc/rfc2104. Acesso em: 10 ago. 2007.

MILLER, Victor S. Use of elliptic curves in cryptography. In: Advances in Cryptology — CRYPTO’85. LNCS, v. 218, p. 417–426, 1985. Disponível em: https://link.springer.com/chapter/10.1007/3-540-39799-X_31. Acesso em: 10 ago. 2007.

MOORE, David et al. The spread of the Sapphire/Slammer worm. 2003. Disponível em: https://cseweb.ucsd.edu/~savage/papers/Infocom03.pdf. Acesso em: 10 ago. 2007.

NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. FIPS 197: Advanced Encryption Standard (AES). Gaithersburg, MD: NIST, 2001. Disponível em: https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.197.pdf. Acesso em: 10 ago. 2007.

NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. FIPS 46-3: Data Encryption Standard (DES). Gaithersburg, MD: NIST, 1999. Disponível em: https://csrc.nist.gov/publications/detail/fips/46/3/archive/1999-10-25. Acesso em: 10 ago. 2007.

NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. SP 800-38A: Recommendation for block cipher modes of operation. 2001. Disponível em: https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38a.pdf. Acesso em: 10 ago. 2007.

NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. SP 800-38D: Galois/Counter Mode (GCM) and GMAC. 2007. Disponível em: https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pdf. Acesso em: 10 ago. 2007.

OPENWALL. John the Ripper password cracker. v. 1.7, 2006. Disponível em: https://www.openwall.com/john/. Acesso em: 10 ago. 2007.

OREBAUGH, Angela; BELEW, Simon; VALDES, Candace. Metasploit Toolkit for Penetration Testing, Exploit Development, and Vulnerability Research. Burlington, MA: Syngress, 2007. Disponível em: https://www.elsevier.com/books/metasploit-toolkit/orebaugh/978-1-59749-074-0. Acesso em: 10 ago. 2007.

PAX TEAM. The PaX address space layout randomization (ASLR). 2001. Disponível em: https://pax.grsecurity.net/docs/aslr.txt. Acesso em: 10 ago. 2007.

PAXSON, Vern. Bro: A system for detecting network intruders in real-time. Computer Networks, v. 31, n. 23–24, p. 2435–2463, 1999. Disponível em: https://www.icir.org/vern/papers/bro-CN99.pdf. Acesso em: 10 ago. 2007.

RACKOFF, Charles; SIMON, Daniel. Non-interactive zero-knowledge proof of knowledge and chosen ciphertext attack. In: Advances in Cryptology — CRYPTO’91. LNCS, v. 576, p. 433–444, 1992. Disponível em: https://link.springer.com/chapter/10.1007/3-540-46766-1_35. Acesso em: 10 ago. 2007.

RFC 2246. The TLS Protocol Version 1.0. 1999. Disponível em: https://www.rfc-editor.org/rfc/rfc2246. Acesso em: 10 ago. 2007.

RFC 3280. Internet X.509 Public Key Infrastructure Certificate and CRL Profile. 2002. Disponível em: https://www.rfc-editor.org/rfc/rfc3280. Acesso em: 10 ago. 2007.

RFC 4253. The Secure Shell (SSH) Transport Layer Protocol. 2006. Disponível em: https://www.rfc-editor.org/rfc/rfc4253. Acesso em: 10 ago. 2007.

RFC 4306. Internet Key Exchange (IKEv2) Protocol. 2005. Disponível em: https://www.rfc-editor.org/rfc/rfc4306. Acesso em: 10 ago. 2007.

RFC 4346. The Transport Layer Security (TLS) Protocol Version 1.1. 2006. Disponível em: https://www.rfc-editor.org/rfc/rfc4346. Acesso em: 10 ago. 2007.

RFC 2898. PKCS 5: Password-Based Cryptography Specification Version 2.0. 2000. Disponível em: https://www.rfc-editor.org/rfc/rfc2898. Acesso em: 10 ago. 2007.

RIVEST, Ronald L.; SHAMIR, Adi; ADLEMAN, Leonard. A method for obtaining digital signatures and public-key cryptosystems. Communications of the ACM, v. 21, n. 2, p. 120–126, 1978. Disponível em: https://doi.org/10.1145/359340.359342. Acesso em: 10 ago. 2007.

ROESCH, Martin. Snort – Lightweight Intrusion Detection for Networks. In: LISA ’99: 13th Systems Administration Conference. 1999. Disponível em: https://www.snort.org/documents. Acesso em: 10 ago. 2007.

SCUT; TEAM TESO. Exploiting format string vulnerabilities. 2001. Disponível em: https://dl.packetstormsecurity.net/papers/attack/formatstring-1.2.pdf. Acesso em: 10 ago. 2007.

SOLAR DESIGNER. return-to-libc attack. Bugtraq posting, 1997. Disponível em: https://seclists.org/bugtraq/1997/Oct/63. Acesso em: 10 ago. 2007.

STUBBLEFIELD, Adam; IOANNIDIS, John; RUBIN, Aviel D. Using the Fluhrer, Mantin, and Shamir attack to break WEP. NDSS, 2002. Disponível em: https://www.ndss-symposium.org/wp-content/uploads/2017/09/Using-Fluhrer-Mantin-and-Shamir-Attack-Break-WEP.pdf. Acesso em: 10 ago. 2007.

TENEBLE NETWORK SECURITY. Nessus 3.0 User Guide. 2005. Disponível em: https://static.tenable.com/documentation/nessus_3.0_user_guide.pdf. Acesso em: 10 ago. 2007.

VAUDENAY, Serge. Security flaws induced by CBC padding — Applications to SSL, IPSEC, WTLS… In: Advances in Cryptology — EUROCRYPT 2002. LNCS, v. 2332, p. 534–546, 2002. Disponível em: https://link.springer.com/chapter/10.1007/3-540-46035-7_35. Acesso em: 10 ago. 2007.

WANG, Xiaoyun et al. Collisions for Hash Functions MD4, MD5, HAVAL-128 and RIPEMD. 2004. Disponível em: https://www.iacr.org/cryptodb/archive/2004/CRYPTO/1471/1471.pdf. Acesso em: 10 ago. 2007.

WANG, Xiaoyun; YIN, Yiqun; YU, Hongbo. Finding collisions in the full SHA-1. In: CRYPTO 2005. LNCS, v. 3621, p. 17–36, 2005. Disponível em: https://link.springer.com/chapter/10.1007/11535218_2. Acesso em: 10 ago. 2007.

WIRESHARK FOUNDATION. Wireshark User’s Guide. v. 0.99, 2007. Disponível em: https://www.wireshark.org/docs/wsug_html_chunked/. Acesso em: 10 ago. 2007.

Observação: Todas as tecnologias, protocolos, ferramentas e práticas referidas neste trabalho correspondem ao estado da arte e da prática até 2007, conforme as citações e documentos normativos listados.