Reflections on Trusting Trust - Ken Thompson

Um dos artigos mais interessantes que já li. Vale a pena perder alguns minutos para rever esse material.

Alguns pontos interessantes do artigo:

• Facilidade de inserção de códigos maliciosos através do próprio compilador;
• O código fonte pode ser reproduzido integralmente e serem adicionadas algumas funções, procedures ou qualquer outro conteúdo em seu algoritmo principal;
• Assim pode-se desconfiar do próprio código gerado pelo autor e contar com a garantia dos fornecedores de compiladores e de ferramentas de desenvolvimento de software sobre seus produtos; e, principalmente
• Ética: Os profissionais ligados ao ramo devem ter em mente os conceitos de ética e boa conduta profissional;

RSA é um algoritmo para encriptação de dados, que deve o seu nome a três professores do Instituto MIT (fundadores da actual empresa RSA Data Security, Inc.), Ron Rivest, Adi Shamir e Len Adleman, que inventaram este algoritmo, a mais bem sucedida implementação de sistemas de chaves assimétricas, e fundamenta-se em Teorias Clássicas dos Números. Este algoritmo tem como princípio a construção de chaves públicas e privadas usando números primos.

Funcionamento do Algoritmo:
1) Dados dois números primos p e q, trabalha-se com a hipótese de que quanto maiores forem os números mais seguro será o algoritmo;
2) Obtém-se n, pela fórmula n = p * q;
3) Obtém-se z, pela fórmula z = (p - 1) * (q - 1)
4) Escolhe-se um número “e”, onde “e” e “z devem ser primos entre si;
5) Calcula-se “d” pela fórmula d = e^-1 mod z;

Encriptação
Para transformar uma mensagem m numa mensagem c encriptada usando a chave pública do destinatário n e e basta fazer uma potenciação modular:

c = m^e mod n

A mensagem então pode ser transmitida em canal inseguro para o receptor. Há um algoritmo para realizar esta potência rapidamente.

Decriptação
Para recuperar a mensagem m da mensagem encriptada c usando a respectiva chave privada do receptor n e d, basta fazer outra potenciação modular:

m = c^d mod n

Referências:
http://pt.wikipedia.org/wiki/RSA

SHA1 (Secure Hash Algoritm)

O primeiro membro da família, publicado em 1993, foi oficialmente chamado SHA; no entanto, é frequentement chamado SHA-0 para evitar confusões com os seus sucessores. Em 1994, SHA-1, o primeiro sucessor do SHA, foi publicado. Desde então quatro variantes foram lançadas com capacidades de saída aumentadas e um design ligeiramente diferente: SHA-224, SHA-256, SHA-384, e SHA-512 — por vezes chamadas de SHA-2.

O SHA1 implementa um algoritmo de hash sem chave, que pega uma mensagem de até 264 bits e produz um resumo da mensagem de 160-bits e é utilizado para a verificação de integridade da mensagem. Ele é baseado nos princípios de projeto dos algoritmos de hash MD4 e MD5 (Memory Digest 4 e 5). O SHA1 é considerado o sucessor do MD5, um dos primeiros e mais utilizado algoritmos de hash, processando sequencialmente blocos de 512 bits. Cada processamento é feito por bloco com cerca de 80 passos.

SHA-1 e seu funcionamento

A sua lógica de funcionamento pode ser dividida em cinco passos:

1) Acrescentar bits de enchimento: toda mensagem terá bits acrescentados, sendo o tamanho final modulo 512 congruente a 448. Assim, uma mensagem pode ter de 1 a 512 bits de enchimento, que consiste de um bit com valor 1 seguido de quantos bits 0 forem necessários.

2) Acrescentar tamanho da mensagem: um bloco de 64 bits é acrescentado à mensagem, sendo tratado como um inteiro sem sinal de 64-bit. Este bloco contém o tamanho original da mensagem (antes do enchimento).

3) Inicialização do buffer MD: um buffer de 160 bits é utilizado para manter os resultados intermediários e final da função de hash. Este buffer pode ser representado como cinco registradores de 32 bits, que são inicializados com o seguinte valor (em hexadecimal):
A = 67 45 23 01
B = EF CD AB 89
C = 98 BA DC FE
D = 10 32 54 76
E = C3 D2 E1 F0

4) Processamento da mensagem em blocos de 512 bits: o centro do algoritmo é uma função de compressão que consiste de quatro iterações, que possuem 20 passos cada. Estas iterações são similares, mas utilizam uma estrutura lógica diferente.

5) Saída: depois de processar todos os blocos de 512 bits, a saída da última iteração fornece o hash de 160 bits.

Conclusões:

• O NIST planeja substituir o SHA1 até 2010.
  
• Apesar do SHA-1 ser um algoritmo de hash já quebrado através de técnicas de colisão de múltiplos blocos, ele é muito utilizado como função de verificação em diversos outros programas.
  

Referências bibliográficas:

- http://pt.wikipedia.org/wiki/SHA1
- http://www.schneier.com/blog/archives/2005/02/sha1_broken.html
- MARGI, Cíntia – “UM MECANISMO PARA DISTRIBUIÇÃO SEGURA DE VÍDEO MPEG”

Enigma – um lição aprendida (ou não) ao não considerar os fatores humanos na segurança de informação?

Artigo da semana: "The Weakest Link: The Human Factor - Lessons Learned from the German WWII Enigma Cryptosystem".

No blog de hoje, vamos usar um exemplo do passado como uma lição. Algo que a história nos mostra e que pede reflexão.

Uma grande parte dos negócio ocorre em ambientes puramente computacionais e essa migração cada vez mais aumenta. Conceitos de segurança e logicamente a criptografia passa a ser cada vez mais um fator crítico para o sucesso das dessas transações. Na área militar, esse preocupação é antiga, pois é naturalmente uma área de vanguarda, já que muitas inovações tecnológicas nascem no ambiente do mercado de defesa, nucleado por entidades e institutos ligados ao departamento de defesa de diversos países. Nesse ponto em específico, a preocupação é fundamental pois a informação precisa ser identificada e protegida, pois no caso de serem corrompidas ou descobertas geram danos materiais e humanos.

Durante a Segunda Guerra, a máquina do Enigma era uma evolução considerável para o seu momento. Sem a menor sombra de dúvidas. a melhor tecnologia em criptografia da época, e considerado um ambiente extremamente seguro e imune a ataques. A Alemanha possuía esse diferencial com o Enigma, uma máquina fabulosa. Os códigos gerados pelo Enigma, mesmo com outra máquina, não conseguiriam ser quebrado de imediato, pois seria necessária a chave e os ajustes corretos nos rotores da máquina. Essa segurança que o Enigma deu aos alemães, fez com que eles descartassem a possibilidade de que o sistema poderia ter vulnerabilidades. Esse foi sem dúvida o maior erro, pois o seu sistema de segurança não era perfeito e as falhas dos seus operadores foi o que levou seu código a ser quebrado. A Polônia e mais tarde a Inglaterra, começaram a investir pesado para quebrar os códigos do Enigma gerado pelo alemães. Apesar de ser uma tarefa complexa, que exigiu um esforço grande, nada faria parar o objetivo de quebrar o código dos alemães. As vulnerabilidades foram exploradas, como por exemplo, ao investigar-se as rotinas dos operadores, documentos que não eram descartados de maneira correta e claro a traição de alguns, levando ao fim do sonho do alemães de que o Enigma era um ambiente imune.

Mesmo com um exemplo bastante antigo percebemos que os problemas em Segurança sempre tem a falha humana como aliado, seja por prepotência, negligência ou ainda dinheiro. O fator humano é potencialmente o elo mais fraco da segurança da informação. Começa errada qualquer política de proteção à informação que só enxerga o ponto de vista tecnológico. Treinamentos adequados e freqüentes é um ponto-chave dessa discussão. O freqüente é importantíssimo, pois na medida em que as pessoas são treinadas e executam uma rotina, elas tendem a degradar a execução visto que conhecem bem os procedimentos, porém essa é uma vulnerabilidade alta em qualquer sistema de segurança de informação. Todas as camadas de uma empresa devem ser contempladas por uma política de segurança da informação. O exemplo do Enigma demonstra exatamente isso. Os alemães acreditavam ter um sistema imune a qualquer falha. Sem dúvida uma lição. Se foi aprendida ou não, fica a questão do título deste blog. Não são raros os casos similares ao Enigma, mesmo hoje, com as inovações tecnológicas disponíveis e em estudo.

O que vem por aí?

Estarei um tempo fora do blog, por que estou de mudança de endereço e também com provas nas disciplinas que curso. No dia 26 de abril de 2007 estará no ar minhas considerações sobre o artigo: "The Weakest Link: The Human Factor - Lessons Learned from the German WWII Enigma Cryptosystem". Esse artigo foi uma publicação do SANS Institute 2001, como parte do Information Security Reading Room.

Falhas de Segurança Acidentais X Propositais – A necessidade de uma base de conhecimento comum.

Artigo da semana: A Taxonomy of Computer Program Security Flaws, with Examples - CARL E. LANDWEHR, ALAN R. BULL, JOHN P. MCDERMOTT, AND WILLIAM S. CHOI

No artigo selecionado da semana, veremos uma publicação do ano de 1994 que catalogou e caracterizou as diversas falhas de segurança existentes. Fazendo uma leitura do artigo referido, podemos identificar algumas passagens e conceitos bastante interessantes.

As falhas em softwares, em geral, não são documentadas e quando são possuem natureza descritiva muito pobre que não esclarece completamente quais pontos de falha ocorreram. Esse fato possui inúmeras vertentes de explicações. Exemplificando, baseado na hipótese que expor as falhas pode ferir a confiança por parte de clientes e investidores de uma instituição financeira, evitar tais falhas deveria ser um ponto de extrema preocupação de engenheiros e programadores que, em geral, não dedicam esforço suficiente em documentar as falhas e principalmente evitá-las criando requisitos específicos de segurança lógica ainda no período de concepção dos produtos de software que produzem.

Ao se conhecer, classificar e documentar falhas encontradas em produtos de software, certamente despertaria interesse de seus desenvolvedores em criar e gerenciar como parte da concepção de requisitos de segurança, gerando sistemas mais robustos sobre a ótica de segurança lógica e menos vulneráveis às falhas já existentes. O próprio artigo define claramente que fazendo uma análise quantitativa, percebe-se que em geral a natureza das falhas são normalmente as mesmas.

A criação de um repositório dedicado onde todas as falhas de produtos de software de uma determinada empresa fossem cadastradas, certamente geraria uma base de conteúdo e conhecimento relevante que auxiliaria certamente os desenvolvedores de produtos de software. Uma falha, ao ocorrer, seria cadastrada nesse repositório, que inclusive poderia ser aberto, possibilitando que demais empresas pudessem se atualizar com essas informações e se prevenir. Dados históricos comprovam que uma falha normalmente é explorada inúmeras vezes, em diversas instituições de mesmo gênero ou até da mesma empresa. Com certeza a falta de documentação é incentivo claro para que esse cenário se repita. Um repositório comum com certeza é fator primordial na taxonomia de falhas de segurança em software registrando e classificando as falhas de modo a que elas possa ser facilmente pesquisada, evitando assim sua propagação e aumentando a segurança dos softwares como um todo.

Uma falha de segurança, em geral conhecida como “bug de software”, normalmente aparece de maneira acidental, ou seja, sem objetivo específico do desenvolvedor do produto de software em gerar tal falha. Mas não se pode descartar a possibilidade de falhas maliciosas, onde os próprios desenvolvedores deixam lacunas de segurança em seus produtos de software visando futuramente uma exploração indevida. Uma falha, de maior ou menor impacto deve ser combatida e corrigida. Ignorar falhas que inicialmente não representam uma ameaça forte pode significar uma oportunidade a ser explorada.

A fase de verificação, testes e validação dos produtos de software, em geral eliminam grande parte das falhas não propositais. As falhas com características propositais, em geral possuem uma estrutura mais rebuscada, visto que essa falha não foi só simplesmente introduzida, foi também planejada, arquitetada e muitas vezes testada para ver se proporciona o resultado malicioso esperado.

A mensagem final é que uma boa segurança lógica de software só pode ser obtida com dois segmentos bem sedimentados:

• Uma preocupação com a criação de requisitos específicos de segurança: Os desenvolvedores dos produtos de software se preocuparem com esse aspecto.

• Um trabalho de aproximação forte com os recursos humanos envolvidos na concepção de produtos de software: Confiança nos programadores e desenvolvedores dos produtos de software, eliminando suas insatisfações, que podem acarretar na maliciosa ação de inserção de falhas propositais.

O autor enriquece bastante seu trabalho com os anexos, pois trazem diversos exemplos, que mostram as categorias catalogadas em seu artigo.Vale a pena explorar o artigo como um todo, pois uma série de exemplos de falhas de segurança selecionados.

O que vem por aí?

No dia 28 de março de 2007 estará no ar minhas considerações sobre o artigo: "A Taxonomy of Computer Program Security Flaw". Esse artigo foi uma publicação ACM de 1994, com autoria de Carl E. Landwehr, Alan R. Bull, John P. McDermott e William S. Choi.

Fraude no Sumitomo Bank alerta para fraudes em transações bancárias

O banco Sumitomo, importante instituição do mercado financeiro japonês, foi vítima de uma tentativa de fraude, felizmente sem sucesso, a partir do roubo de senhas de funcionários que trabalham diretamente com transações bancárias de importantes quantias. A investida só foi possível através do uso de uma ferramenta específica, que guarda as senhas utilizadas e digitadas por funcionários. Porém aplicativos de software e até hardware também são comuns e podem facilmente ser baixados da Internet ou adquiridos como produtos de software completos para uso pessoal. Tal acometimento, por si só, já é uma notícia relevante para a comunidade financeira, porém a grande evolução desse acontecimento não se deu no forte esquema implementado para inibir a ação e sim ao fato do Sumitomo Bank divulgar amplamente o ocorrido, algo inesperado, pois normalmente os bancos gostam de passar segurança para seus clientes e investidores, não evidenciando publicamente tais iniciativas, visando proteção direta da boa imagem do estabelecimento bancário.

Se por um lado o Sumitomo Bank resolveu se sensibilizar e divulgando e colocando em risco sua personalidade empresarial, de outro, essa ação sensibilizou e trouxe para toda a comunidade um alerta para melhoria em seus processos para evitar que outras ações semelhantes resultem em uma fraude eficaz. Algo a se repensar no futuro, caso outras instituições também divulguem seus incidente, embora seja bastante improvável que alguma instituição divulgue e confirme alguma fraude de sucesso, limitando-se ao máximo em apresentar os casos onde as ações foram neutralizadas.

Nem sempre se perde dinheiro sendo vítima de um furto ou desvio. As empresas de tecnologia, por exemplo, possuem uma série de informações sensíveis de projetos em andamento ou planos de expansão que são tão ou mais valiosos do que somas diretas que possam ser desviadas.

As medidas de segurança de informações em uma instituição financeira ou qualquer outra devem ser assuntos prioritários, porém não adianta nada criar um robusto processo para combater tais investidas, sem a participação consciente e também com treinamento e sensibilização de seus funcionários.

Ações de segurança de informação devem contemplar três naturezas distintas: processo, pessoas e ferramentas. Mesmo atacando essas três frentes, ainda sim, o problema não é eliminado, mas torna-se provavelmente minimizado.

(Texto publicado em 8 de março de 2007 e revisado no dia 22 de março de 2007)

Veja +:

http://www.cioupdate.com/trends/article.php/3600126

http://www.computerworld.com/securitytopics/security/story/0,10801,100455,00.html