A NSA e o software livre

Mais Lidos

  • “A destruição das florestas não se deve apenas ao que comemos, mas também ao que vestimos”. Entrevista com Rubens Carvalho

    LER MAIS
  • Povos Indígenas em debate no IHU. Do extermínio à resistência!

    LER MAIS
  • “Quanto sangue palestino deve fluir para lavar a sua culpa pelo Holocausto?”, questiona Varoufakis

    LER MAIS

Revista ihu on-line

Zooliteratura. A virada animal e vegetal contra o antropocentrismo

Edição: 552

Leia mais

Modernismos. A fratura entre a modernidade artística e social no Brasil

Edição: 551

Leia mais

Metaverso. A experiência humana sob outros horizontes

Edição: 550

Leia mais

Por: André | 16 Setembro 2013

Nos últimos dias, houve duas notícias bastante interessantes. A primeira, declarações de Kevin Mitnick, assegurando que a NSA (Agência Nacional de Segurança dos Estados Unidos) havia “infiltrado” o código PGP (Pretty-Good-Privacy); a outra, que a NSA havia “infiltrado” as decisões para que o dispositivo gerador de números aleatórios (/dev/random) do sistema Linux, dependesse do hardware, neste caso, de extensões de hardware do CPUs Intel e AMD, comprometendo a segurança do núcleo...

 
Fonte: http://bit.ly/19smltA  

A reportagem está publicada no sítio Phenobarbital con Soda, 07-09-2013. A tradução é de André Langer.

Estas notícias afetam a credibilidade do software livre? Pelo contrário. Vejamos por quê.

Do PGP ao GNU PG

O PGP é um software “comercial” (e é “a esse software” que Mitnick se refere). Atualmente, as patentes em torno tanto do PGP como dos algoritmos criptografados, estão a cargo da Symantec, inclusive o criptografado IDEA que faz uso PGP; em seu lugar e graças ao uso de algoritmos livres (tanto de patentes, como limpos em suas especificações, como o RSA-AES) foi desenvolvido o GNU PG (GNU Privacy Guard) como uma implementação do openPGP e que é a versão utilizada por TODAS as distribuições de software livre em nível mundial.

É preciso recordar duas histórias chaves do GNU PG: o caso do famoso bug detectado pelo pessoal do Entrust de 2004, que causou a reescrita de um dos métodos de criptografia simétrica; o outro caso, em 2006, que foi detectado pelo pessoal da segurança do Gentoo Linux e que (ao contrário de outros “bugs” – no Windows – que duraram 10 anos) demorou apenas seis dias para ser corrigido.

Random Number Generator

O “/dev/random” é um pseudo-dispositivo de software, que existe no núcleo Linux com o único propósito de prover uma máquina geradora de números aleatórios, o “/dev/random” faz uso de extensões de hardware nos CPUs (Intel, AMD, Texas Instruments-ARM, etc.) para poder gerar números “pseudo-aleatórios” (diz-se “pseudo”, porque, por ser o computador um sistema determinista, necessita-se de uma probabilidade remota de que os números não sejam realmente aleatórios).

Assim como com o PGP, no Linux existe também o “/dev/urandom”, a diferença entre eles é fundamental: o primeiro, baseado em “entropia de hardware”, pode chegar a ficar “exausto” de bytes, por conseguinte, esperará encher o pool de entropia para te entregar “mais números aleatórios”, isto faz com que o “/dev/random” seja, em consequência, mais lento que o “/dev/urandom”, que simplesmente reutiliza a fonte de entropia uma e outra vez para obter mais números aleatórios por software (é por esta razão que tem o “U” na frente, de “unblock”, ou seja, não se bloqueia como /dev/random).

Então, a decisão de Torvalds compromete a segurança de algo? Certamente, nas distribuições de GNU/Linux em que o “/dev/random” utilizar exclusivamente a entropia do CPU (que hoje e depois dos trabalhos de Gutterman e Reinman em 2006, creio que nenhuma); há “patch” [literalmente, "remendo", é um programa criado para atualizar ou corrigir um software] em Debian GNU/Linus (não aprovado na LKML – Linux Kernel Mailing List) que modificam o /dev/random para fazer uso de mais entropia como ioctl (movimento do mouse, barulho do fluxo de vídeo, barulho do tráfico da rede, etc.), estes “patch” são aplicados desde 2006 por requerimento de aplicações “precisamente” como GNU PG e GNU TLS.

Creio que inclusive depois de “descoberto” o compromisso das extensões de CPU Intel por parte da NSA, um simples “patch” será coisa de alguns dias. Não acredita?

Cones de papel alumínio e a NSA chegou a minha casa...

 
Fonte: http://bit.ly/19smltA  

Uma vez alguém me escreveu que iria “desativar o SELINUX porque era um produto maléfico da NSA”, além do fato de existir vários milhares de olhos dentro do código do SELinux (admitir que há código malicioso dentro do núcleo Linux é contradizer expressamente o que se define acerca das quatro liberdades  que a FSF defende até a morte), está mais do que claro com o fato acima (/dev/random não está comprometido, mas uma de suas tantas fontes de aleatoriedade, como o são os CPU da Intel/AMD) que o software livre provou, uma vez mais, que se devem comprometer coisas “mais obscuras” que o código, para embaçar a segurança do núcleo Linux (ou do freeBSD, por exemplo).

Da Intel se acredita tudo. Lá pela Guerra do Golfo, distribuiu-se pela “conspironoosfera”, uma *notícia* que indicou que todos os CPU Intel “enlouqueceram e queimaram” deixando sem serventia milhares de computadores em Bagdá, minutos antes de iniciar a invasão do Iraque. Possível? 100% confiável?, muito confiável... da NSA espero tudo.

Mas, como indicara alguém nas listas do Fedora (precisamente para a resposta do SELINUX e sua relação com a NSA), qualquer relação com “desativar SELinux porque é fabricado pela NSA” e fabricar cones de papel alumínio para “livrar-se de leitores mentais”, é pura coincidência... “Os cones de papel alumínio devem ser feitos de dois lados, um lado refratário para fora, para evitar que ‘entrem’ coisas enviadas com raios mentais pela NSA, mas também com papel refratado ‘para dentro’, para evitar que a NSA use raios mentais para ler a nossa mente, ah!, é preciso evitar que haja um ‘curto circuito’ entre ambas as camadas, para não ficar comprometido”.

Ou seja, se o CPU (hardware) é comprometido por alguma “instrução maléfica”, não importa o sistema operacional que você tiver, não acredita?...

Claro, aí se caímos na retórica da “eterna conspiração”, poderíamos indicar “ahh!, mas Selinux poderia *restaurar* seus *troianos* através do compilador”, então lembre-se do compilador livre GCC (GNU C), “Ahh!, mas certamente o GCC usa extensões de CPU e se lhe comprometem o CPU?”, bom, construa a sua própria máquina (começando pelo CPU)! Para isso há movimentos de hardware livre? Não, chegar a pensar dessa maneira (nessa eterna cadeia conspiranóica), teria que se colocar a questão posta por alguns conspiranóicos que falam de IPv8 (não sai mais fácil isto se quer privacidade?), se não teríamos que morar em covas, com o nosso próprio hardware de computador, nossas próprias redes, fabricando inclusive o nosso próprio cabo (imune às ondas eletromagnéticas que os Estados Unidos lançam regularmente antes de qualquer invasão), isolando nossas cabeças com cones de alumínio (bem desenhados, por favor!) e evitando qualquer contato com outro ser humano “suspeito”.

Vivemos esta realidade e é preciso enfrentá-la... não tratar de voltar às covas e ao obscurantismo...

Comunicar erro

close

FECHAR

Comunicar erro.

Comunique à redação erros de português, de informação ou técnicos encontrados nesta página:

A NSA e o software livre - Instituto Humanitas Unisinos - IHU