300Mbps Mini Wireless N USB Adapter Marca: TP-LINK Modelo: TL-WN823N(EU) Versão:2.0
Neste tutorial, ensinarei como instalar este dongle USB para wireless no Debian 9. Mas não simplesmente entregar um passo-a-passo, eu quero que você entenda o que está fazendo, e seus conhecimentos expandam-se, consequentemente.
O problema
O manual do produto diz que há suporte oficial para o Linux, pela TP-LINK, porém não existe suporte de verdade pela TP-LINK, e eu penei um bocado para fazê-lo funcionar. Trago então minha solução para você!
O driver oficial, do site da TP-LINK, está obsoleto! O que há ali é o código, a partir do qual você deve compilar (produzir) o driver especificamente para seu sistema, não é só dar 2 cliques. Mas para compilar, você precisa ter o ambiente adequado, isto é, seu sistema tem de possuir algumas características específicas. A característica crucial nesse caso é o kernel do Linux: o site oficial diz que o driver é compatível com as versões 2.6.18 até a 3.10.10. Legal, mas o suporte para a versão 3.10 acabou em novembro de 2017, e já estamos em 2018... O Debian que uso, segundo o comando lsb_release -r é a 9.5, e o kernel, segundo o comando uname -r, é o 4.9.0-7-amd64 (suportado até janeiro de 2019). Então este driver não dá suporte ao Debian 9, apenas versões mais antigas...
Obtendo o firmware
Os repositórios oficiais do Debian 9 incluem o pacote firmware-realtek, que por sua vez inclui o firmware do chipset Realtek rtl8192eu, que é o que está dentro do dongle. Os repositórios do Debian 8 incluem um pacote de mesmo nome (firmware-realtek), que porém, não dá suporte ao chipset em questão (rtl8192eu). Então faça um upgrade do seu sistema, se ainda não estiver usando a versão 9.
Dado que o pacote firmware-realtek não é software livre, é necessário alterar sua lista de repositórios para "tornar visíveis" os pacotes de software proprietário:
em um terminal root, abra a lista de repositórios no editor de texto nano: nano /etc/apt/sources.list;
adicione non-free (com um espaço antes) após cada linha escrita no arquivo;
salve as alterações com ^O (CTRL+O), e depois feche o editor de texto com ^X (CTRL+X);
atualize sua lista de fontes de software com apt update, e instale o firmware com apt install firmware-realtek;
reinicie o computador, para que o firmware seja carregado na próxima inicialização do sistema e entre em ação.
Encontrando redes sem-fio
Após reiniciar, você já deve ser capaz de encontrar as redes sem-fio das redondezas. Por exemplo, se você tiver o network-manager-gnome instalado, o nm-applet (um ícone na barra de aplicativos que exibe informações de rede) deve mostrar-lhe uma lista de redes wireless disponíveis, se você clicar nele. Se você consegue essa geração de lista de redes, você tem o firmware adequado para o seu dongle, e o passo-a-passo anterior teve sucesso em seu objetivo.
Escanear o ar buscando redes sem fio é necessário, mas não suficiente. Tente conectar-se a alguma, mesmo uma sem senha e sem segurança - se não tiver uma assim por perto, você pode configurar seu roteador para tal. O nm-applet roda, roda, mas não conecta? Então ainda tem algo errado.
digite echo "blacklist rtl8xxxu" | tee /etc/modprobe.d/rtl8xxxu.conf;
reinicie o computador. Se ainda assim não funcionar, dê modprobe rtl8xxxu no terminal.
Após configurar o dispositivo assim, tente novamente se conectar a uma rede sem senha e sem segurança, ou com segurança WEP. Conseguiu? Ótimo. Mas e as conexões WPA, WPA2, e WPA-WPA2, funcionam? Se não, siga adiante o tutorial.
Conectando-se a redes WPA, WPA2, e WPA-WPA2
As proteções WPA, WPA2 e WPA-WPA2 são mais recentes que a WEP, já obsoleta devido à falta de segurança. Por isto mesmo, funcionam diferente e exigem configuração adicional.
Conferindo nos logs do sistema (comando nano /var/log/messages como root), constatei que existem quatro "apertos de mão" (4-way handshake) entre o dongle e o roteador sem fio, compondo uma etapa de negociação. É esta etapa que falha e impede e a conexão, registrando no log, após a troca de mensagens "eapol", que a autenticação falhou pela "razão 15". O protocolo do "eapol" é uma inovação das tecnologias WPA e WPA2 (não existiam na WEP). E a razão 15 significa que o handshake estourou o tempo-limite.
O que faz o handshake falhar é a aleatorização do endereço MAC do dongle, pelo que pesquisei. Esse recurso é importante para previnir que clientes wireless sejam identificados pessoalmente quando usarem wifis públicos: a cada conexão, um endereço MAC diferente é usado pelo aparelho, dando certa privacidade. Mas isso não funciona bem com o dongle TL-WN823N(EU) v2.0, e o recurso precisa ser desabilitado. Isso é simples de resolver:
abra um terminal root, e edite o gerenciador de redes no editor de textos nano, com nano /etc/NetworkManager/NetworkManager.conf;
adicione as linhas ao arquivo:[device]wifi.scan-rand-mac-address=no
salve as alterações com ^O (CTRL+O), e depois feche o editor de texto com ^X (CTRL+X);
reinicie o computador.
Voilà! Resolvido. Agora o dongle deve funcionar perfeitamente. Se para você, ainda assim não estiver dando certo, deixe um comentário neste post explicando o que deu errado, e talvez eu possa lhe ajudar.
Em 2007, Evan Prodromou desenvolveu o "esqueleto" do que eventualmente se tornaria o GNU Social. Na época de sua concepção, ele era conhecido como Laconica, e era utilizado em um serviço de microblogging chamado Identi.ca. Após ser financiado, Prodromou renomeou Laconica para StatusNet e começou o desenvolvimento do serviço. A ideia por detrás da StatusNet era que qualquer um pudesse baixar o software e rodar seu próprio serviço de microblogging. O nobre objetivo estava embrulhado em estratégia de marca, e buscas corporativas, na esperança de um dia levar o microblog para as massas (tanto marcas quanto indivíduos) tal qual WordPress fez para os blogs.
Várias pessoas contribuíram código para a StatusNet e o projeto cresceu. Em 2010, Prodromou documentou o protocolo OStatus que ele criou e fez a StatusNet usar, e conseguiu levar este protocolo para o W3C, para que fosse mais desenvolvido (o que não ocorreria até 6 anos depois). OStatus tornou-se o padrão sucessor do protocolo OpenMicroBlogging. Esta foi uma grande conquista, pois o OStatus é a tecnologia que o W3C mantém e desenvolve, e é basicamente o procedimento operativo padrão para comunidades coesas de microblog. A maioria destas comunidades OStatus podem comunicar-se umas com as outras (Federação).
Em algum momento por aqui, Matt Lee começou a explorar opções para ferramentas sociais para o GNU FM, e a StatusNet capturou sua atenção. Algum interesse continua a crescer, mas nade demais acontece. Prodromou eventualmente perde seu financiamento em 2012, e o desenvolvimento real da StatusNet parece estar condenada à morte, apesar de continuar um pouco.
Devido ao projeto usar uma licença livre, as pessoas tinham a capacidade de fazer "forks" (ramificações do desenvolvimento), e Mikael Nordfeldth havia feito um fork da StatusNet para um projeto chamado Free Social. O projeto de Mikael era "por diversão", mas após Prodromou ter decidido seguir adiante com o pump.io, Matt e Mikael oferecem a ideia de fundir o projeto StatusNet em um novo, nomeado GNU Social (já que os desenvolvedores em questão eram desenvolvedores e apoiadores do Projeto GNU / Fundação do Software Livre). Mikael continua a manter e dar suporte ao GNU Social em 2017, mas houveram vários forks que constroem por sobre seu próprio trabalho, enquanto tentam seus próprios objetivos.
Existe um rumor de que a Identi.ca era um serviço de microblogging independente, e não federava com os nos StatusNet. Este rumor está errado: a companhia StatusNet fazia ser fácil criar seu nó "nome.status.net", de graça para nós de usuário único, e também provia vários nós com nomes como "240.status.net", "unlimited.status.net", para que se experimentasem diferentes tamanhos de mensagem. Prodromou realmente tentou fazer com que pessoas mesclassem-se com a Federação e saíssem do nó com o nome da empresa. Mas Identi.ca era a face da StatusNet, e continuou crescendo. Não foi até o "pumpocalypse" que sites alternativos como Quitter.se realmente deslanchassem, no grande êxodo da Identi.ca por pessoas que estavam confusas ou não gostavam no novo software (pump.io).
O GNU Social é um projeto de rede social que está em desenvolvimento há alguns anos. Originalmente implementado através do serviço Identi.ca, logo evoluiu quando a Free Software Foundation se juntou em seu desenvolvimento. Trata-se de uma rede social de aparência muito similar ao Twitter, porém com algumas vantagens, como a possibilidade de enviar mensagens de mais de 140 caracteres, participar de grupos, e seguir usuários de outras instâncias que utilizem os mesmos padrões abertos.
Diferente do Twitter, que é um serviço centralizado, o GNU Social é um software livre que pode ser instalado em qualquer servidor. Cada instância da rede social inter-opera com as demais de maneira horizontal, formando assim uma rede distribuída onde os participantes não dependem das políticas corporativas de uma única empresa, e aonde a adoção de novas funcionalidades é livre, desde que siga-se os protocolos de comunicação.
Como é de se imaginar, existem muitos serviços "públicos" de GNU Social. Alguns dos mais conhecidos são: Quitter.se, Quitter.es e lamatriz.org; porém, existem muitos outros, que você pode conferir no site Fediverse.org. Mesmo estando em um nó qualquer, é possível conectar-se às demais instâncias e assim inter-conectar-se com os outros usuários também.
Porquê usar?
De que nos interessaria criar um novo perfil em uma outra rede social que tem uma aparência similar ao Twitter? Porquê se dar ao trabalho e tempo?
Em primeiro lugar, porquê na Internet, sempre vamos estar vivendo mudanças e saltos, de uma tecnologia a outra. Se não o fizermos conscientemente e por escolha própria, os donos das grandes plataformas nos obrigarão, de qualquer maneira, a aceitar as mudanças que eles impõe a partir de suas políticas empresariais centralizadas, em termos que não conhecemos nem controlamos. Assim, somar-se à história de uma tecnologia livre, aberta, e descentralizada, como o GNU Social, é abrir uma janela de ar fresco em direção a uma comunicação que podemos controlar mais coletivamente, sob normas comunitárias de netiqueta, e não sob Termos de Uso abusivos, e sob permanente ameaça de censura.
Em segundo lugar, porquê nestas redes sociais distribuídas, estão acontecendo coisas interessantes! Estão somando-se cada vez mais pessoas, e estão se abrindo novos nós nos quais prosperam todo tipo de comunicades, com sua variedade de idiomas e temas a explorar. Entramos em um território livre de algoritmos de personalização, e que assim não podem ser manipulados visando lucros com propaganda. Bem distante dos ruídos impostos pelos grandes meios de massa, das marcas, das celebridades, e dos trolls que inundam o Twitter e Facebook, podemos retomar espaços de comunicação mais adequados para o diálogo real.
Entender como funciona o OStatus facilita que novos desenvolvedores possam unir-se ao projeto e criar novas possibilidades para o GNU Social.
OStatus: as peças da engrenagem
Ostatus combina de forma natural e eficiente um conjunto de peças, protocolos, que permitem implementar comunicações distribuídas na Web:
Activity Streams codifica as publicações, atividades e eventos sociais dos usuários nos padrões Atom ou RSS;
PubSubHubbub envia, em tempo real, estes feeds a seus assinantes ao redor da Web;
Salmon notifica aos usuários sobre as respostas a suas publicações;
Webfinger torna fácil encontrar outros usuários na rede de nós.
Ainda que cada um destes protocolos cumpra uma função determinada, veremos como colaboram entre si e ganham sentido ao trabalharem como uma engrenagem dentro de cada nó do GNU Social. Seguiremos agora os passos que o GNU Social dá quando lhe pedimos para assinar os posts de um usuário remoto, ou seja, um usuário que não está cadastrado no próprio nó de quem assina.
Porém, antes de passar à ação, vejamos onde encontrar OStatus dentro do código-fonte do GNU Social:
OStatus no código-fonte do GNU Social
Uma das maravilhas do GNU Social é sua modularidade. E, como não podia ser de outra forma, a implementação do OStatus está encapsulada dentro do plugin OStatus que podemos encontrar no diretório plugins.
O plugin OStatus agrega ao GNU Social um conjunto de bibliotecas, funcionalidades, e rotas para fazer possível a comunicação entre os nós do GNU Social. Vamos seguir os passos do processo de assinatura entre usuários remotos. O ponto de acesso principal para esta opção em qualquer nó do GNU Social é main/ostatussub. Por exemplo, na instância Quitter España, é no endereço https://quitter.es/main/ostatussub.
Esta URL será nosso ponto de partida para dar uma viagem guiada pelo processo de assinatura a usuários remotos. Um processo aonde centramo-nos no trabalho que realiza o protocolo PubSubHubbub.
Iniciamos a viagem até a assinatura
Estando no ponto de partida, main/ostatussub, perante o usuário final o processo não tem grandes segredos: insere-se o endereço do OStatus, usuario@exemplo.net ou https://exemplo.net/usuario, do usuário que deseja-se seguir, e então o GNU Social pede-lhe para confirmar a assinatura, realiza a confirmação e, a partir deste momento, começa a receber todas as publicações do usuário a que foi solicitado seguir, em sua linha do tempo pessoal.
Sigamos estes mesmos passos, mas agora fazendo referência às linhas de código do GNU Social adonde se desenvolve a ação:
Executa-se a ação. Quando o usuário aperta o botão «continuar», executa-se uma solicitação POST, que inclui a variável profile, sobre a ação ostatussub implementada pelo plugin OStatus.A partir deste momento o GNU Social lança-se à caça do feed, tudo é um feed, que se esconde por detrás do usuario OStatus que indicamos a ele.
Uma URI ou um e-mail? O primeiro a se fazer é confirmar se o usuário introduziu no formulário uma URI ou um usuário em formato de endereço de e-mail. Se o que temos é um usuário OStatus em formato de endereço de e-mail, teríamos que extrair pelo Webfinger. Porém, para este post, vamos a supor que temos uma URI para encontrar o feed que buscamos. A partir deste momento é quando entra en ação o PubSubHubbub.PubSubHubbub permite-nos assinar um feed em tempo real. Não temos que fazer solicitações regulares ao feed para obter as novas publicações, ao invés disto nós é que seremos notificados, e nos será enviado o novo conteúdo, em tempo real, quando o feed se atualizar. Para entender a lógica por detrás do PubSubHubbub recomendo ver este vídeo.Nos passos paraimplementarPubSubHubbub, o primeiro é descobrir como assinarmos o feed, descobrir qual é o agente (hub) a que temos que pedir que o feed assine. Este hub se encarrega de informar aos assinantes remotos sobre as atualizações dos feeds dos usuários em seu nó. Cada nó do GNU Social tem seu próprio agente (hub).
Descobrir o hub. Uma vez que tenhamos a ULR do feed, o GNU Social realiza uma solicitação GET para obter a informação sobre o hub ao qual tem de solicitar assinatura, dá persitência aos dados encontrados (URL do feed, hub do feed, etc), guarda-os na base de dados associados ao usuário OStatus para o qual recebemos uma pedido de assinatura. Terminado este passo, o GNU Social nos apresenta os dados do usuário do qual queremos assinar, e nos pede confirmação.
Enviamos solicitação de assinatura ao hub. Uma vez que o usuário confirme a assinatura, o GNU Social dá início ao processo de assinatura. Seguindo a especificação do PubSubHubbub, para solicitar a assinatura a um hub, temos que fazer uma solicitação POST enviando-lhe a seguinte informação: mode=subscribe, topic=, callback=, verify=sync. O "topic" é a URL do feed a que queremos assinar, e "callback" é a URL à qual queremos receber primeiro a chave de confirmação, e a partir daí, as atualizações do feed. Aqui está o código que implesmenta isto no GNU Social. Enviada a solicitação, temos que esperar que o hub faça-nos uma petiação GET com a chave de confirmação.
Já estamos seguindo!! A partir deste momento o hub nos vai enviar as atualizações do feed ao qual nós acabamos de assinar, com solicitações à URL do callback que passamo-lho.
Descoberta do hub.Solicitação de assinatura.
O texto deste post de Anders Bateva está liberado sob domínio público.Baseado no trabalho disponível no blog Las Indias.
Artigo em que os fundadores do Google apresentaram seu protótipo, em 1998. Explicam quais eram os problemas dos mecanismos de busca da época, e como se propunham a resolvê-lo, principalmente com o algoritmo PageRank. Também, considerações sobre o modelo de negócios baseado em propagandas, e que complicações podem surgir do funcionamento de um web crawler.
Neste artigo, nós apresentamos o Google, um protótipo de um mecanismo de busca de larga-escala que faz uso pesado da estrutura presente no hypertexto. O Google foi projetado para fazer crawling e indexar a Web eficientemente, e produzir resultados de busca muito mais satisfatórios do quê os sistemas existentes. O protótipo, com um texto completo e banco de dados de hyperlinks com pelo menos 24 milhões de páginas, está disponível em http://google.stanford.edu/ .
— trecho do Resumo.
Já deu pra sentir a relevância do artigo? Simplesmente é o artigo acadêmico onde os fundadores do Google apresentam este projeto da universidade deles como atividade do curso que faziam. Abaixo, resumo o que é apresentado no texto. Não me preocupei em resumir a Seção 4 "Anatomia do Google", pois são detalhes de funcionamento interno que não são exatamente relevantes para o usuário normal.
Dados: o banco de dados de 24 milhões de páginas requeria apenas 147GB de espaço em disco, ou 53,5GB quando comprimido - o que já era barato na época. Foi gerado em aproximadamente 9 dias (incluindo todo o tipo de erro que atrasou o processo). O total de links em 24 milhões de páginas era 322 milhões.
Problemas na época:
as pessoas usam listas de sites (como o Yahoo!) cuja manutenção é humana, e por isso são subjetivas, caras de construir e manter, lentas de melhorar, e não podem cobrir todos os tópicos "exotéricos";
mecanismos de busca automatizados que baseiam-se em palavras-chave normalmente retornam muitos resultados de baixíssima qualidade, e anunciantes tomam medidas para enganar esses mecanismos e ganhar a atenção das pessoas.
Por exemplo, nós vimos um grande mecanismo de busca retornar uma página contendo apenas "Bill Clinton é ruim" e uma foto, a partir de uma busca por "Bill Clinton". Alguns argumentam que, na web, os usuários deveriam especificar com maior precisão o que eles querem, e adicionar mais palavras a suas buscas. Nós discordamos veementemente desta posição. Se um usuário realizar uma busca tal como "Bill Clinton", ele deveria receber resultados razoáveis, dada a existência de enorme quantia de informação de alta qualidade disponível sobre este assuntos. Considerando exemplos como esse, nós acreditamos que o trabalho padrão de recuperação de informação precisa ser extendido para lidar efetivamente com a web.
—Seção 3.1: Recuperação de Informação.
Soluções do Google:
PageRank: dá uma pontuação de qualidade para cada página web baseado na estrutura de links;
links são utilizados para melhorar resultados de busca.
PageRank
O gráfico de citações (links) da web foi considerado importante por Sergey Brin e Lawrence Page, e era algo largamente não-utilizado. Tais mapas de links entre as páginas permitem o cálculo do PageRank, uma medida objetiva da importância de citação, que corresponde bem, disseram eles, com a ideia subjetiva de importância que as pessoas têm. Isso permitia ao PageRank priorizar bem as buscas por palavras-chave, comparado ao que havia na época: em assuntos mais populares, uma simples busca por coincidência de texto nos títulos das páginas gera bons resultados. E também ajuda muito em buscas por texto completo das páginas, tal como no Google.
O PageRank pega o conceito de citação acadêmica (aonde um artigo menciona o outro como referência), e expande para a web. Porém, de forma diferente, as citações não têm todas o mesmo valor: é feita uma relação entre o número de citações feitas para a página, e o número de citações que a página fez, e isso determina o valor de cada citação.
Por exemplo, compare a informação de uso de uma grande página inicial, como a do Yahoo, que atualmente recebe milhões de visualizações a cada dia, com um artigo histórico obscuro que pode receber uma visualização a cada 10 anos. Claramente, estes dois itens devem ser tratados bem diferentemente por um mecanismo de busca.
—Seção 3.2: Diferenças Entre a Web e Coleções Bem-Controladas.
A fórmula usada pelo PageRank foi apresentada assim:
PR(A) = (1-d) + d (PR(T1)/C(T1) + ... + PR(Tn)/C(Tn))
A ideia é que o PageRank seja um modelo de comportamento de usuário: o PageRank (PR) é a probabilidade de um surfista web aleatório visite uma página, e o fator "dampening" seria a probabilidade deste surfista aleatório, em cada página, se entediar e requisitar outra página aleatória. Uma variação seria adicionar esse fator "d" a uma única página, ou um grupo de páginas, permitindo personalização e tornando "praticamente impossível" que alguém deliberadamente engane o sistema para ganhar um ranking mais alto.
Dado: calcular o PageRank de 26 milhões de páginas podia ser feito em poucas horas com uma workstation de tamanho médio.
Links
Links dão descrições melhores da página para a qual levam, do quê as próprias páginas dariam de si mesmas. Também, links permitem indexar conteúdos que normalmente não poderiam sê-lo por mecanismos de busca textuais, como imagens, programas, e bancos de dados.
Copiando a Web
Rodar um web crawler é uma tarefa desafiadora. Há problemas capciosos de desempenho e confiabilidade, e mais importantemente, há problemas sociais. Crawling é a aplicação mais frágil, dado que envolve interagir com centenas de milhares de servidores web, e vários servidores de nomes de domínio, estando todos além do controle do sistema.
[...]
Ocorre que rodar um crawler que conecta-se a mais de meio milhão de servidores, e gera dezenas de milhares de entradas de log, gera uma boa quantia de e-mails e chamadas telefônicas. Por conta do vasto número de pessoas vindo à linha, há sempre aquelas que não sabem o que um crawler é, pois este é o primeiro que viram. Quase que diariamente, nós recebemos um e-mail como "Uau, você olhou um bocado de páginas no meu website. Que achou dele?". Há também algumas pessoas que não conhecem o protocolo de exclusão de robôs, e pensam que suas páginas devem estar protegidas de serem indexadas por conta de uma declaração como "Esta página é protegida por copyright e não deve ser indexada", o que, não é nem necessário dizer, é difícil para web crawlers entenderem. [...] Uma vez que sistemas grandes e complexos como crawlers irão invariavelmente causar problemas, é preciso haver significantes recursos dedicados a ler os e-mails e solucionar estes problemas conforme apareçam.
— Seção 4.3: Rodando um Web Crawler.
Propaganda e conflitos de interesse
Atualmente, o modelo de negócios predominante para mecanismos de busca comerciais é a propaganda. Os objetivos do modelo de negócios de propaganda não sempre corresponde a prover busca de qualidade para os usuários. Por exemplo, em nosso mecanismo de busca prototípico, um dos principais resultados para uma busca por "telefone celular" é "O Efeito do Uso de Telefone Celular Sobre a Atenção dos Motoristas", um estudo que explica em grande detalhe as distrações e riscos associados com conversar num celular enquanto dirige. Este resultado de busca veio em primeiro, devido à sua alta importância conforme julgada pelo algoritmo PageRank, uma aproximação da importância de citação na web. É claro que um mecanismo de busca que estivesse recebendo dinheiro para exibir propagandas de telefones celulares teria dificuldade em justificar a página que nosso sistema retornou, para os seus anunciadores pagantes. Por este tipo de razão, e experiência história com outra mídia, nós expectamos que mecanismos de busca financiados por propagandas serão inerentemente enviesados rumo aos anunciantes, e distante das necessidades dos consumidores.
Dado que é bem difícil, mesmo para especialistas, avaliar mecanismos de busca, o viés de mecanismos de busca é particulamente insidioso. Um bom exemplo foi o OpenText, que reportadamente vendia a companhias o ireito de ser listada no topo de resultados de busca para pesquisas específicas. Este tipo de viés é muito mais insidioso do quê a propaganda, pois não é claro quem "merece" estar ali, e quem está disposto a pagar dinheiro para ser listado. Este modelo de negócios resultou em uma revolta, e o OpenText deixou de ser um mecanismo de busca viável. Mas, vieses menos gritantes têm a probabilidade de serem tolerados pelo mercado. Por exemplo, um mecanismo de busca poderia adicionar um pequeno fator para resultados de busca de companhias "amigáveis", e subtrair um fator de resultados dos competidores. Este tipo de viés é bem difícil de detectar, mas poderia ainda assim ter um efeito significativo no mercado. Além disto, faturamentos de propaganda com frequência provêem um incentivo para prover resultados de busca de má qualidade. Por exemplo, nós notamos que um grande mecanismo de busca não retornava a página inicial de uma companhia aérea quando o nome desta companhia era inserido numa busca. Aconteceu então que a companhia aérea colocou uma propaganda cara, linkada à busca que consistia de seu nome. Um mecanismo de busca melhor não iria requerer esta propaganda, e possivelmente resultaria em perda de rendimentos da companhia aérea para o mecanismo de busca. No geral, poderia ser argumentado que, do ponto de vista do consumidor, quão melhor for o mecanismo de busca, tanto menos propagandas serão necessárias para o consumidor encontrar o que ele deseja. Isto, é claro, erode o modelo de negócio suportado por propagandas dos mecanismos de busca existentes. Entretanto, sempre haverá dinheiro dos anunciantes que querem que um cliente mude de produtos, ou tenha algo que é genuinamente novo. Mas nós acreditamos que o problema da propaganda causa conflito de interesses o bastante para que seja crucial ter um mecanismo de busca competitivo que seja transparente e no âmbito acadêmico.
O artigo detalha as conclusões e experimentos feitos pelo grupo, que participou da 2ª edição de Testes Públicos de Segurança da urna eletrônica, evento organizado pelo TSE em 2012.
Durante o evento, foram detectadas vulnerabilidades no software que permitiram a recuperação em ordem dos votos computados. Apresentamos cenários onde as vulnerabilidades permitem a possibilidade de fraude eleitoral e sugestões para se restaurar a segurançaa dos mecanismos afetados.
Este post sobre o artigo foi feito depois o estudo ter sido mencionado em uma palestra do Diego Aranha na CryptoRave 2014, já publicada aqui; daí que fiquei sabendo da existência da publicação. Busquei assim poder pegar, e dar, mais informações sobre o que foi dito naquela ocasião.
Limitações do estudo
Os experimentos foram feitos apenas em software pois os autores do artigo não são especialistas em hardware; também, foram feitos testes apenas em uma pequena parte do código-fonte da urna (durante 5 horas), e excluindo qualquer sistema externo à urna em si (como o totalizador de votos, que soma os votos das urnas), devido a limitações nas regras do evento (até mesmo a formatação como competição), e na disponibilidade de tempo dos autores do artigo. Essas limitações acabaram por permitir que a equipe que publicou o artigo só pudesse testar a identificação do voto do eleitor, e não a possibilidade do voto dado poder ser fraudado (adulterado), como pretendiam.
Sem a possibilidade de se efetuar testes extensos e sem qualquer tipo de restrição, seguindo metodologia cientı́fica, não é possı́vel afirmar que o formato atual do evento colabora significativamente para o incremento da segurança da urna eletrônica. Permite apenas encontrar vulnerabilidades pontuais que permitam ataques de fácil execução, mas com efeitos limitados.
Seção "Resumo"
Já na seção "resumo" do artigo, apresenta-se aproximadamente isto:
sigilo fraco do voto: é fácil quebrar o sigilo, ou seja, colocar os votos computados em ordem, permitindo então saber quem votou em quem. Basta ter o resultado público da votação e um acesso mínimo ao código-fonte da urna, aos quais os partidos têm acesso;
criptografia sem grande utilidade: a chave criptográfica da urna está na própria urna, em uma parte sem criptografia, e a mesma chave criptográfica é usada para TODAS as urnas do país;
hash obsoleto: o algoritmo que gera o hash criptográfico (SHA-1) não deveria ser usado há 6 anos (ou seja, desde 2006), pois já foi avisado que ele não tem segurança suficiente;
vulnerável a atacantes internos: o modelo de segurança é focado em ataques externos, mas quem gera mais risco é quem está dentro do esquema de votação;
processo de desenvolvimento mal-feito: falhas podem ser inseridas, acidentalmente ou propositalmente, devido a práticas inseguras no desenvolvimento;
auto-verificação de integridade: a urna verifica a si mesma para saber se foi adulterada, sendo que, se foi adulterada, o próprio sistema de verificação estaria comprometido. Era necessário ter verificão externa! De qualquer forma, essa verificação só serve para dar certeza de que o programa veio do TSE, não que os milhões de linhas de código funcionam como deveria.
pode-se observar de antemão que vários dos recursos implementados no software da urna eletrônica não representam mecanismos de segurança, mas apenas de ofuscação, não resistindo a colaboradores internos ou atacantes persistentes. Como vários dos problemas encontrados resultam de falhas arquiteturais ou premissas inadequadas de projeto, é improvável que a intervenção pontual em algumas dessas questões resolva as causas fundamentais para a sua ocorrência.
O sigilo do voto
Os testes feitos pela equipe conseguiram pôr na ordem de votação os 950 votos (vereador e prefeito) de 475 eleitores fictícios usados no teste.
Registrar os votos inseridos pelo eleitor de forma desordenada é um procedimento crı́tico para se proteger o sigilo do voto. Fica claro, portanto, que a metodologia da equipe permitiu derrotar o único mecanismo utilizado pela urna eletrônica para proteger o sigilo do voto.
Esse tipo de vulnerabilidade não deixa rastro ou vestígio ao ser abusada, pois não é preciso abrir a urna eletrônica e adulterá-la, basta usar os produtos públicos da votação... Mas não é dada a identidade dos eleitores diretamente, apenas a ordem do voto. As identidades de quem votou precisariam ser adquiridas externamente, para ser feita a correlação. Numa situação de voto de cabresto, em que um agente coloque as pessoas em uma ordem específica, por exemplo, dá pra verificar quem votou em quem.
O problema parte do Registro Digital de Voto (RDV), uma tabela com colunas para os cargos que armazena os números dos candidatos votados, mas fora da ordem de voto. Em 2002, foi instituída a impressão do voto, para permitir a verificação do voto em relação ao sistema eletrônico, mas em 2003 foi extinguido, e trocado pelo RDV. O RDV existe para permitir verificar que o Boletim de Urna (BU), que entrega o resultado parcial da urna, está certo, mas isso é inútil, pois é o mesmo software que gera tanto o BU quanto o RDV, e por isso a adulteração do programa alteraria ambos os "documentos". Além disso, se implementado errado, permite quebrar o sigilo do voto!
Com a adoção do voto impresso pela Índia, o Brasil permanece como o único paı́s no mundo a adotar sistema de votação sem verificação independente de resultados.
Números aleatórios
Um bom embaralhamento dos resultados, ou seja, um suficientemente aleatório, precisa de rigor criptográfico, e o desenvolvedor precisa de suficiente entendimento de Segurança Computacional para poder perceber isto e fazer certo. O que ocorre é que a urna usa números pseudo-aleatórios, e além disso foi decidido usar o geramento padrão da linguagem C: rand()/srand()! Esse processo de geração não tem qualidade criptográfica, aceita apenas sementes muito curtas, de até 32-bit. Além disso, a semente é simplesmente a combinação hora, minuto e segundo obtida pela função time(), que pega a representação Unix do calendário UTC.
O calendário UTC é um fuso horário que a Era Unix segue, e essa contagem da era é feita em segundos desde o seu começo, representados em um valor de 32-bit (exemplo: 1466404014).
Como o sistema de votação tem que ser ligado entre as 7AM e as 8AM, isso dá 3600s de variação máxima, então 3600 valores diferentes de semente (dia, mês, ano obviamente já são conhecidos por todos, se não, como as pessoas iriam até a urna votar?). Para completar, a semente é publicada no LOG (público para os partidos ao fim da eleição) e na zerésima (imediatamente pública), essa sendo a "comprovação" de que há zero votos na urna no começo da eleição.
Ou seja, qualquer um que pegue a zerésima (pública) saberá a hora, e portanto a semente de geração de números pseudo-aleatórios, e poderá assim determinar a ordem certa dos votos. Tanto o LOG quanto a zerésima são assinados digitalmente, e à mão pelos fiscais, então fica confirmado: 'os números são embaralhados seguindo essa semente!'. O padrão de posições vazias no RDV, mais o total (público) de eleitores que compareceram à votação, permite comparar o resultado da geração de números aleatórios, vendo se coincidem os espaços vazios, ou seja, se foi deduzido certo.
Solução
A forma mais segura para se efetuar a correção é substituir o gerador pseudo-aleatório atualmente utilizado por outro gerador pseudo-aleatório com propriedades estatı́sticas superiores. Exemplos de geradores assim são documentados em padrões e podem ser encontrados em bibliotecas criptográficas de uso geral.
Esse gerador pseudo-aleatório melhorado apenas precisaria de uma semente mais segura, i.e. não algo que está impresso e divulgado em todo lado. Para resultados realmente aleatórios, seria preciso um gerador em hardware, que depende de algum processo físico conhecido. Nada demais também, os modelos de urna fabricados de 2009 em diante já têm uma CPU AMD Geode que faz isto! Note-se que isso não extingue a necessidade de testes para essas soluções também...
O VeraCrypt é um sistema de software para a criação e manutenção de volumes criptografados (containers) on-the-fly-encrypted. Ou seja, os dados são criptografados automaticamente antes de serem salvos e decodificados logo após serem carregados, sem intervenção do usuário. Nenhum dado armazenado em um container pode ser lido (descriptografado) sem a utilização das chaves de criptografia corretas, como senha e key-file(s) este último se existir. O software criptografa o sistema de arquivo inteiro, como por exemplo: Nomes de arquivos, nomes de pastas, o conteúdo de cada arquivo, espaço livre, metadados, etc. Os arquivos são automaticamente descriptografados (em memória / RAM) enquanto são lidos ou copiados. Da mesma forma, os arquivos que estão sendo gravados ou copiados para o container VeraCrypt são automaticamente criptografados on-the-fly (antes de serem escritos no disco) na RAM.
— Anderson Luís
O artigo visa analisar se é possível pegar as chaves criptográficas dos containers criados pelo VeraCrypt enquanto este programa está em execução, afinal, a memória RAM (memória temporária volátil) é o único local onde não há criptografia dos dados manipulados pelo programa enquanto ele está em execução. Após ser finalizado, os dados que estavam na RAM podem ser apagados (aleatoriamente) e aí restariam apenas os dados criptografados no disco rígido. Em outros termos, a memória RAM parece ser o ponto mais fraco de todo o processo.
Para copiar a memória RAM do computador periciado, foi usado o programa DumpIt (para Windows), e para copiar uma imagem do disco, o software dcfldd (para UNIX e similares) - criado pelo Laboratório de Forênsica Computacional do Departamento de Defesa dos EUA. Para analisar a memória RAM, foi usado o programa forense código-abertoVolatility. O processo foi feito 4 vezes, para garantir um padrão no funcionamento do VeraCrypt.
De forma relativamente simples, as keyfiles do volume criptografado foram encontradas, com base em comparação de datas de acesso a arquivos e execução de programas - lembrando que isso apenas porquê esses registros foram tirados diretamente da memória RAM - . As keyfiles, conforme a documentação própria do VeraCrypt, são arquivos que, usados em combinação com as senhas, provêem mais segurança à criptografia, pois sem os arquivos certos não é possível montar o volume. Tendo o realizador do estudo encontrado as keyfiles, pôde montar o volume.
Porém, para de fato acessar o volume, é preciso saber também a senha! A senha não é guardada em forma pura, como texto simples, mas como hash. Ou seja, estão codificadas de uma maneira "praticamente impossível" de reverter, só sendo usável se o usuário digitar a mesma senha no programa, este gerar o mesmo hash, comparar com o hash guardado e eles coincidirem. O desenvolvedor do estudo tentou encontrá-la na memória RAM, onde ficaria armazenada, mas observou que o VeraCrypt em particular tem o devido cuidado de sobrescrever esses dados, impedindo que a senha pura ou os hashes sejam encontráveis nesse tipo de análise posterior.
Dentre os fatores que a equipe de desenvolvimento do VeraCrypt se propôs a melhorar [em relação ao TrueCrypt], o tratamento dos dados armazenados temporariamente na memória RAM foi um ponto de fundamental importância para o presente artigo.
— Anderson Luís
A única alternativa a encontrar a senha ou hash seria quebrá-la na força bruta (tentativas sucessivas exaustivas), mas o uso de derivação de chaves torna isso imprático... se o usuário seguiu a boa prática de usar senha adequada. Se a senha for fraca, ainda pode ser possível! Mas é tema para outros estudos...
Uma rede torrent é formada por computadores normais com um certo programa instalado: um cliente de BitTorrent (exemplos: uTorrent no Windows, Transmission no Linux), tal como para acessar sites é preciso ter um cliente HTTP ("navegador web"). Neste tipo de rede, os arquivos ficam descentralizados, então a conexão não é cliente-servidor, mas par-a-par. Dizendo de outro modo, não é como as redes tradicionais, onde há um nó (um ponto) central, o servidor, com o arquivo inteiro e que o envia a todos os que não o têm e o solicitam, os clientes.
Em redes torrent, todos os pontos são pessoas normais que têm diferentes partes de diferentes arquivos, e trocam entre si, sem depender de um único nó que tenha o arquivo inteiro. Enxergando pela ótica das redes tradicionais, é como se todo computador fosse cliente e servidor ao mesmo tempo; traduzindo para a ótica torrent, cada peer (pessoa) é leecher (cliente) e seeder (servidor) de diferentes arquivos. Como os arquivos são divididos em milhares de pedacinhos - bits - que são distribuídos em forte fluxo - torrent - aleatoriamente (por padrão), foi dado este nome ao protocolo, lançado em 2001.
E onde entra o tracker?
O tracker é como um servidor que não possui os arquivos (han?!): é similar a um catálogo telefônico, apenas aponta onde estão as pessoas com os arquivos (números de IP delas). Em 2001, não havia outra forma de descobrir quem tinha os arquivos, pois o protocolo BitTorrent foi desenvolvido, por Bram Cohen, então estudante da University at Buffalo (EUA), baseado no uso de trackers. É preciso contextualizar a época para entender o motivo do que acabou se tornando uma limitação: as conexões de internet tinham baixa largura de banda, haviam poucos usuários de internet no mundo, a guerra dos direitos de cópia era fraca... Assim, não foram previstos vários problemas que se desenvolveram mais tarde por guerras judiciais contra os trackers - diminuindo a quantidade deles - e aumento gigantesco do número de usuários e da taxa de transmissão - exigindo mais trackers/trackers mais poderosos.
Os trackers acabaram virando um problema grande: eram um alvo fácil para derrubar a rede (afinal, não era tão descentralizada assim...), e os que eram públicos estavam sendo sobrecarregados (mesmo porquê não é todo mundo que quer abrir um serviço público assim, sem ganhar dinheiro com ele). Por isto, em 2005 surgiu o (Mainline) DHT, uma melhoria no serviço BitTorrent aonde parte do próprio catálogo de localização dos pares fica distribuído... com os pares. Indo além, foi criado o PEX, outra tecnologia de comunicação sem-tracker onde os próprios peers "conversam" e trocam informações sobre possíveis pares, sem depender de partes de tabelas já prontas. Assim o ponto fraco, o tracker, já não diminui a qualidade da rede.
Criptografia: ponto a melhorar no protocolo BitTorrent
O que tenho a dizer nesta seção não tem relação direta com os trackers, mas tem com a eliminação de pontos fracos que descrevi na seção anterior, e por isso vale constar:
Um ponto fraco que ainda não foi resolvido diretamente é a exposição que os peers têm: como o endereço IP de quem tem ou quer os arquivos fica sendo passado de um lado a outro sempre que alguém quer enviar ou receber o arquivo, é muito fácil um detentor de direitos de cópia se passar por leecher e pedir os IPs dos outros peers.
O protocolo BitTorrent não tem criptografia implementada, e novamente tenho que apelar à contextualização histórica: os computadores domésticos conseguiam por acaso processar criptografia em 2001? Havia preocupação com isto pelas "pessoas comuns"? Ao menos já haviam ouvido falar este nome? Como comparativo, o HTTPS, versão criptográfica do HTTP, só ganhou popularidade no começo da década de 2010 (apesar de ter sido desenvolvido entre 1994 e 2000)!
