BLOCO - BLOg dos COordenadores ou BLOg COmunitário da ComUnidade WirelessBRASIL

O conteúdo do BLOCO tem forte vinculação com os debates nos Grupos de Discussão Celld-group e WirelessBR. Participe!

• Crimes Digitais (43) - Msg de José Smolka sobre o "armazenamento dos dados de conexão" previsto no PL

Obrigado, José Smolka, pela preciosa colaboração! (mensagem abaixo)

Smolka, nós já o conhecemos de longa data mas, como esta mensagem vai para nosso BLOCO e também para alguns destinatários interessados em nosso debate, permito-me reproduzir aqui seu mini-currículo anotado no website com suas mensagens mantido pela ComUnidade:

José de Ribamar Smolka Ramos (smolka@terra.com.br) é engenheiro eletricista (UFBa 1982), com especialização em gestão da qualidade (CETEAD/UFBa 1994) e MBA executivo (FGV RJ/Grupo Telefonica 2001). Trabalha na área de Informática desde 1980, tendo atuado em empresas das áreas financeira, industrial e serviços, estando desde 1989 na área de telecomunicações. Área principal de interesse: projeto, implantação e gestão operacional da infraestrutura e serviços de comunicação baseados na arquitetura TCP/IP. Atualmente é especialista técnico na Diretoria de Planejamento e Tecnologia da Vivo S/A.

----- Original Message -----
From: José de Ribamar Smolka Ramos
To: wirelessbr@yahoogrupos.com.br
Sent: Tuesday, December 16, 2008 2:08 PM
Subject: [wireless.br] Re: Crimes Digitais (42) - Msgs de Chiaradia, Smolka, Nacinovic e Portugal + 02 notícias --> Fw: "Historinha" para entender o Art. 22 ...

O problema não é a quantidade de bits ou bytes a serem armazenados. O problema é modelar o banco de dados para a finalidade. O art.22 obrigará todos os provedores a acertarem a hora por um relógio atômico central, no sentido de que hora, data e referência GMT sejam únicas. Qualquer diferença alimentará questões judiciais.

Data do início da conexão no formato AAAAMMDD (8 bytes) + separador (1 byte);
Hora GMT do início da conexão no formato HHMMSS (6 bytes) + separador (1 byte);
Data do final da conexão no formato AAAAMMDD (8 bytes) + separador (1 byte);
Hora GMT do final da conexão no formato HHMMSS (6 bytes) + separador (1 byte);
Identificador do usuário - variável, conforme a prática de cada ISP (vamos supor 10 bytes) + separador (1 byte)
Endereço IP atribuído ao usuário (4 ou 16 bytes, dependendo se for IPv4 ou IPv6) + fim de registro (1 byte)

Então temos cerca de 60 bytes por conexão, o que não é muito. Os problemas da hora GMT e do formato do BD que vai ser montado com estes dados não são críticos, porque:
(a) a hora GMT de início e fim da conexão podem ser obtidas por queries ao serviço NTP (Network Time Protocol) (existem vários abertos ao público na Internet) - o que não quer dizer que não vá dar algum trabalho adaptar os procedimentos de login e logout dos usuários para garantir que os registros das conexões sejam efetivamente gravadas; e
(b) não é realmente obrigação do ISP-Internet Service Provider (de acordo com o inciso I) ter estes dados em um RDBMS (Relational Database Management System) - tê-los em formato texto já é suficiente, quem tem que se preocupar em como harmonizar os dados para consulta posterior são as autoridades (se e quando elas vierem a requisitá-los).

Uma operadora de telefonia guarda os CDRs (Call Detail Records) das chamadas feitas pelos assinantes, primeiramente por razões de tarifação (é dali que se extraem os dados para gerar a conta), e depois para servir de suporte a investigações autorizadas pela justiça, porque estes registros contém data/hora das chamadas e identificam as partes (números dos telefones) envolvidas na conversação. Claro que não dá pra saber o que foi falado, mas sabe-se com quem a conversa ocorreu, o que já é suficiente para dar um bocado de pistas para a investigação.

Só que os registros "pseudo-CDR" para o ISP, como o exemplo que eu descrevi acima, não dizem isto. Eles apenas mostram que alguém que conhece o userid/senha corretos de um determinado usuário esteve "logado" na rede em um determinado período de tempo. E isto não é nem mesmo prova suficiente que o(a) legítimo(a) detentor(a) do par userid/senha utilizado era quem estava usando a conexão.

Estes registros não mostram nada sobre que sites foram visitados, que arquivos foram baixados, e o que mais o usuário tenha feito durante aquela conexão. Ou seja, não ajuda em nada uma investigação. E não adianta dizer que ele prova que o usuário tinha um determinado endereço IP que vai ser "cruzado" com os dados de acesso obtidos em outro site. Dependendo das circunstâncias, endereços IP podem ser forjados (e os delinquentes realmente bons sabem muito bem como fazer isto).

Então concluo que: ou estes dados não vão servir para nada, ou vão servir somente para prender delinquentes "pé-de-chinelo". Considerando esta relação custo (embora não tão significativo, ainda assim real, para os ISPs) versus benefício (limitado ou nulo para as autoridades), será que isto realmente é uma boa idéia?

Ah sim! E voltando à questão de quem realmente estava "logado", aumentando o registro da conexão (mais bytes, nem todos simples para o ISP conseguir dinamicamente) com dados que registrem o meio físico utilizado na conexão (ex.: número associado a linhas xDSL, MIN de aparelhos celulares, etc.), ainda assim o que se prova é que a conexão foi feita a partir de algum local específico, mas ainda não se tem certeza que a pessoa usando o acesso era o seu legítimo detentor.

Aliás, como já foi mencionado em outro post, se eu quisesse delinquir a primeira coisa que eu ia fazer era descobrir (via war driving) redes WiFi (domésticas ou corporativas) desprotegidas ou mal-protegidas, e usá-las para encaminhar o meu tráfego ilícito. Se der rolo depois, vai ser problema do legítimo detentor da rede provar que ele não tem nada a ver com o peixe. Eu já vou estar longe, e seguro.