OnlyFans: ex-Empregados Mantinham Acesso às Informações de Usuários

Alguns ex-funcionários da equipe de suporte do OnlyFans ainda continuavam com acesso aos dados dos usuários – incluindo informações pessoais e financeiras confidenciais, mesmo depois de serem demitidos da empresa – usada por profissionais do sexo para vender nus e vídeos pornôs.

Photo by Valeria Boltneva from Pexels

De acordo com um ex-funcionário do OnlyFans – que pediu para permanecer anônimo por temer retaliação, alguns ex-funcionários ainda tinham acesso ao Zendesk, um software de atendimento ao cliente usado por muitas empresas, incluindo o OnlyFans, para rastrear e responder a tíquetes de suporte ao cliente, muito tempo depois de sair da empresa. OnlyFans usa o Zendesk para se relacionar tanto com os usuários que postam conteúdo quanto com os usuários pagantes, consumidores de conteúdo. A revista Motherboard conseguiu confirmar essas informações com mais de um ex-funcionário.

De acordo com a fonte e os usuários do OnlyFans que falaram com a Motherboard, dependendo do assunto para o qual o usuário abre o chamado de suporte, os tíquetes podem conter informações de cartão de crédito, carteiras de motorista, passaportes, nomes completos, endereços, extratos bancários, quanto eles ganharam ou gastaram no OnlyFans, selfies do serviço Know Your Customer (KYC), em que o performer fotografa uma carteira de identificação ao lado do rosto para verificação, além de formulários de licenciamento do material produzido.

Nossa fonte demonstrou à Motherboard como eles faziam para acessar as informações muito depois de terem parado de trabalhar para o OnlyFans.

Em profundidade em motherboard.vice.com

A Apple Entrega os Pontos

A blogosfera está em polvorosa após o anúncio dos novos planos da Apple para monitorar o conteúdo que seus produtos usuários levantam para a iCloud. Nosso blog não pode ficar fora dessa conversa. Assim, buscamos com este post inaugurar essa discussão em português [uma vez que não tenho visto esse assunto alhures na mídia lusófona].

Eu sei que ninguém gosta de falar sobre de segurança na rede e o preço a pagar pela insistência nesse assunto pode ser a alienação dos leitores. Mas quis o destino que eu fosse a pessoa a falar dos assuntos desagradáveis – mas necessários. Sempre tentou-se aqui ilustrar por que os modelos de negócio do Google ou do Facebook [assim como os de todas as redes sociais] representam uma ameaça à privacidade e segurança das pessoas. É muito difícil explicar por que o novo mecanismo da Apple é ainda pior.

Na verdade, enquanto eu rascunhava esta postagem, Matthew Green e Alex Stamos publicaram um artigo no New York Times em que fazem uma boa tentativa de explicar, de forma concisa, essa questão para um público não técnico. Parece que há esperança. Não é minha intenção dar aqui uma explicação exaustiva do que exatamente a Apple planeja fazer, mesmo porque muitos outros artigos excelentes já foram escritos sobre isto na última semana.

Em essência, o iOS 15 introduzirá um mecanismo que permite comparar as fotos do telefone do usuário com um banco de dados de conteúdo CSAM [Child Sexual Abuse Materials – Material de Abuso Sexual de Crianças], e essa comparação começará no dispositivo do usuário. Essa é a grande diferença entre a abordagem da Apple e a de quase todas as outras empresas que hospedam grandes bibliotecas de fotos online. Um parágrafo do artigo de Ben Thompson publicado ontem resume muito bem:

Em vez de limitar a varredura CSAM ao iCloud Photos – a ‘nuvem’ que eles possuem e operam – a Apple resolveu comprometer o telefone de propriedade dos usuários, sem que nenhum deles tenha uma palavra a dizer sobre o assunto. Sim, você ainda pode desligar o iCloud Photos para desabilitar o monitoramento da Apple individualmente. Mas o que está em jogo é uma questão política: a capacidade de penetrar o telefone de um usuário agora existe e não há nada que um usuário de iPhone possa fazer para se livrar dela.

É claro que você poderia dizer que este é um tipo de argumento falacioso do tipo “ladeira escorregadia” [a ideia de que uma vez que algo é permitido não há mais caminho de volta] e que não deveríamos ficar tão preocupados. Talvez você dissesse que de fato devemos confiar que a Apple não usará essa funcionalidade para nenhuma outra finalidade.

Deixando de lado o absurdo de confiar em uma corporação gigante com fins lucrativos [em vez de um governo eleito democraticamente], devemos ter em mente que o histórico de privacidade da Apple até aqui tem sido muito menos estelar do que eles gostariam que pensássemos. A empresa coopera com o governo chinês, por exemplo, armazenando dados pessoais de cidadãos chineses apenas em servidores administrados por uma empresa chinesa, e já cancelou seus planos de disponibilizar a criptografia de backups no iCloud – sob pressão do FBI.

A Apple divulgou uma FAQ na terça-feira na qual tentou esclarecer e resolver os questionamentos, mas se alguma coisa aconteceu foi apenas a confirmação do que todos nós já presumiamos ser verdade: a política interna da Apple é agora a única coisa que impede qualquer agência governamental ou outro agente malicioso de inserir certos arquivos de imagem [por exemplo, fotografias de casais homossexuais em países onde a homossexualidade é ilegal] no registro CSAM.

Porta dos fundos sempre aberta

No mundo da segurança de computadores, essa tecnologia tem um nome: é chamada de “backdoor”. Uma porta dos fundos [para acesso remoto ao aparelho], neste caso bem documentada e bem intencionada, mas ainda assim uma porta dos fundos – instalada e ativada por padrão em milhões de dispositivos em todo o mundo.

Por que diabos a Apple, uma empresa que vem construindo uma imagem de proteção à privacidade nos últimos anos, escolheria tal solução? E por que agora?

A hipótese que muitos analistas de segurança consideram é que a Apple deseja se distanciar do trabalho tóxico e ingrato de verificar os dados dos usuários. Ela têm lutado com o FBI e o governo federal americano há anos. Ela também tem resistido a relatar o conteúdo CSAM que ela encontra nos iPhones ao Centro Nacional para Crianças Desaparecidas e Exploradas [National Center for Missing & Exploited Children – NCMEC].

Mas o fato é que parece que eles não querem mais se envolver em nada disso. Eles querem criar uma situação em que possam oferecer criptografia de ponta a ponta para seus produtos [iMessage, iCloud Drive, etc] e, ao mesmo tempo, manter perante o ‘establishment’ a postura de conformidade com a lei e os costumes. Essa pode ser a única maneira de a Apple ter ‘dois pássaros na mão’.

E ainda mais: devido à forma como o mecanismo é implementado, a Apple não precisa ver os dados reais do usuário. A foto do usuário é convertida em um hash [assinatura digital]. Esse hash é comparado aos hashes de imagens armazenadas em um banco de dados de fotos ‘manjadas’ – mantido pelo FBI em um servidor. A Apple, portanto, não verá o conteúdo das imagens. Só saberá se há uma correspondência entre os hashes do telefone e dos dados do servidor.

Fluxo de trabalho do monitoramento de imagens suspeitas nos produtos Apple. As assinaturas das imagens no celular do usuário são comparadas com as assinaturas das imagens de um banco de dados de referência. Se houver correspondência a Apple avalia o material e, se for o caso, encaminha às autoridades competentes. Gráfico: Vox Leone.

Dessa forma, em suas campanhas de marketing ela ainda poderá alegar que respeita a privacidade do usuário. E se esse mecanismo for usado para qualquer outra coisa, eles sempre podem alegar que estão simplesmente cumprindo as regulamentações locais e que eles próprios não censuram nem olham os dados nos telefones de seus usuários.

Infelizmente, devido à natureza intrinsecamente técnica do problema, acredito que o público geral não será capaz notar essas maquinações [ou mesmo se importar] e continuará a usar os produtos da Apple normalmente. E certamente veremos, durante o próximo evento público da Apple, Tim Cook, o CEO, anunciando triunfantemente alguns recursos de melhoria da privacidade no iOS, como a proteção dos dados pessoais contra rastreamento entre aplicativos ou oferecendo conexão anônima semelhante a VPN para Safari ou Apple Mail. Tudo isso enquanto mantém um backdoor instalado no seu telefone, sobre o qual você nada pode fazer.

É doloroso ver a Apple dando um passo em uma direção tão perigosa. Só posso esperar que a reação causada pela voz estridente da minoria faça a Apple reconsiderar, e talvez mudar a implementação em versões futuras do iOS.

O Zoom e o Voyeurismo Corporativo

Fatos assim não são mais novidade, mas o Zoom vai pagar US$ 85 milhões – aos advogados de uma ação coletiva e aos usuários representados – por mentir sobre criptografia de ponta a ponta e por fornecer dados do usuário ao Facebook e ao Google sem consentimento. O acordo proposto daria aos usuários reclamantes US$ 15 a US$ 25 cada e foi apresentado no último sábado (31/07) no Tribunal Distrital dos Estados Unidos para o Distrito Norte da Califórnia.

Imagem: iStock

Isso aconteceu nove meses depois que o Zoom concordou com um ajustamento de conduta que incluía melhorias de segurança e uma “proibição de declarações falsas sobre privacidade”, em um acordo com a Federal Trade Commission – embora o acordo não inclua compensação para os usuários.

Está correto quem disser que isso é estupro. Sinto-me tão vulnerável em meio aos meus dispositivos como me sentiria se saísse para caminhar depois da meia-noite, pelado, por uma rua escura de qualquer periferia. Eu posso dizer também que o que fazem conosco não é diferente de “stalkear”.

Estar sujeito ao voyeurismo das corporações me faz sentir miserável. Se fosse [apenas] meu governo nacional – legítimo – fazendo isso na suposta intenção de resguardar minha segurança, seria possível começar a entender. Mas saber que essa coleta de dados está sendo realizada por milhares de empresas e indivíduos pelo mudo afora, com o objetivo de nos mercantilizar e desumanizar é inaceitável, e nos torna todos vítimas.

O objetivo final de toda coleta de dados é sempre a exclusão de pessoas [do trabalho, do transporte aéreo, das oportunidades, do crédito, etc]. Os dados do Zoom são valiosos para o Facebook e o Google, não apenas por seu IP. Não apenas pelas conversas íntimas e segredos empresariais. Como consta do processo legal, o material também contém consultas médicas remotas e muitos outros detalhes das vidas privadas dos usuários.

Isso é um tipo de voyeurismo contínuo. Seria um pesadelo na vida real. Quando você é perseguido fisicamente na vida real, você ainda é capaz de esboçar alguma reação e tomar alguma providência legal. Mas, com o estupro de dados não há como impedir, ou mesmo saber quem está te estuprando – ou até que ponto sua vida está sendo destruída.

O teatro das multas

O voyeurismo é geralmente definido como um distúrbio psico-sexual [criminalizado]. Mas quantas pessoas se matam ou experimentam a ruína financeira por causa do voyeurismo corporativo facilitado pelo estupro de dados? Nos Estados Unidos, as corporações têm personalidade. É isso que lhes dá o direito de financiar eleições [ver Citizens United]. Portanto, se as empresas são pessoas, por que não são acusadas também de comportamento criminoso?

Benjamin Lawsky é o papa das leis de segurança cibernética de Nova York, com brilhante passagem pela Superintendência de Serviços Financeiros do governo estadual. Mesmo sendo um regulador experiente, ele nunca acreditou em multas. Segundo sua lógica, multar empresas parece ser um exercício em futilidade. Ele afirma que “as corporações são apenas uma abstração jurídica. É preciso impedir a real má conduta individual dentro das empresas. As pessoas de carne e osso têm que ser responsabilizadas. ”

O comportamento negligente intencional precisa ser criminalizado [quando um hospital ou empresa de energia é hackeado, pessoas podem morrer], se quisermos de fato combater os problemas de cyber-segurança. Para o direito romano, esse é um problema teórico não trivial, uma vez que, no nosso ordenamento jurídico, a negligência é um elemento da culpa e não do dolo [um amigo jurista me alerta sobre a figura do “dolo eventual” no direito brasileiro – obrigado, Dr. Celso]. Já na Common Law [nos EUA] existe a figura da “gross negligence”, que poderia talvez ser aplicada nesses casos. De qualquer forma, é um abacaxi conceitual para um jurista descascar.

Performance sofrível

Outro dia, o governo dos Estados Unidos divulgou um boletim de avaliação de segurança cibernética feito por uma agência governamental [o Departamento de Segurança Interna – Department of Homeland Security].
A maior parte do governo americano foi graduada com nota D [Neste ponto, realmente não quero sequer pensar a respeito do estado de coisas no Brasil].

O próprio DHS, que é o regulador de segurança cibernética dos EUA, também obteve uma classificação ruim. E eis aqui outra dificuldade com multas e investigações regulatórias no campo da informação: as empresas devem seguir o exemplo do governo, mas se o governo tem uma postura de segurança pior do que o setor privado, de onde vem a moral para julgar o setor privado?

O governo precisa seguir suas próprias leis e dar o exemplo. Se o governo continuar a falhar na cibernética, o setor privado não vai cooperar para resolver o problema, pois verá essa cooperação como uma ameaça potencial à sua própria segurança. Por que você deixaria um governo inepto, com limitado conhecimento tecnológico, espiar por trás de sua cortina? Isso cria todo um espectro de vulnerabilidades estruturais.

Portanto, esses passos em falso dos gigantes da Internet têm que ser tipificados como atos criminosos e não apenas passíveis de multa – porque as agências reguladoras simplesmente não têm como impedi-los. Isso está destruindo o tecido da sociedade, criando divisões e disparidades econômicas. Como fazer para enfrentar o problema será um questionamento muito válido no contexto das próximas eleições presidenciais.

Voto Eletrônico sem Tabus e sem Fetiches

A discussão a respeito da segurança do voto eletrônico no país tem refletido a mesma polarização observada em outros domínios. De um lado, temos o presidente da república defendendo a impressão do voto, para fins de “confirmação de eventuais fraudes”. De outro lado, o pensamento majoritário do establishment defende o sistema atual de voto eletrônico como absolutamente invulnerável a manipulações. Como sói acontecer, ambos os lados da discussão se deixam levar por falácias.

(AP Photo/Eraldo Peres)

De um lado [o do Presidente] temos a fetichização do voto; a ideia de que o objeto-urna ou o objeto-votoimpresso são o alfa e o ômega da eleição. De outro temos os guardiões do tabu da Urna Eletrônica Segura e Santificada, refratários a qualquer consideração prática sobre a natureza da segurança de sistemas eletrônicos digitais e da falibilidade humana. Ambos os lados parecem esquecer, se é que chegam a considerar, que a eleição é um processo, no qual objetos físicos (urnas, canetas, pedaços de papel) são pequenos componentes de uma intrincada estrutura. Nenhuma ação isolada em determinada parte componente do sistema vai resultar em solução de qualquer problema.

O que é pior, sinto que a mera discussão do [falso] problema do voto eletrônico x voto impresso está se tornado área proibida. Noto que se quer criar uma atmosfera de repressão à discussão, a qual não posso coonestar. Até mesmo altas instâncias da república se movimentam no sentido de criminalizar a investigação do tema.

Apresento hoje a primeira manifestação do que espero venha a ser uma série de posts visando ampliar o debate sobre esta questão de interesse existencial para o Brasil – que em minha opinião está muito longe de terminar. Na verdade nunca houve debate técnico aberto sobre este tema na sociedade. É preciso envolver as pessoas no debate qualificado [a blogosfera me parece um ambiente mais adequado do que as redes sociais]. Não me furtarei a comentar sobre o assunto quando assim me aprouver, como me é garantido pela Carta Magna [embora, nessas horas, devo admitir que um domínio e um site hospedado no exterior – em uma democracia ainda sólida – fazem a diferença].

De Hashes para Hashes

A necessidade de verificação e supervisão do software dos fabricantes de máquinas de votação tornou-se urgente em 2003, quando a Diebold Election Systems foi descoberta instalando software não certificado em máquinas de quatro municípios da Califórnia, o que levou a empresa a ser acusada de mentir para as autoridades municipais e estaduais sobre o problema.

Desde 2005, as diretrizes do sistema de votação federal americano exigem que os fabricantes de urnas eletrônicas forneçam também às autoridades eleitorais um método confiável para verificar a) se as versões corretas do sistema operacional estão instaladas em suas urnas; b) se o software não foi alterado desde a instalação e c) se não há software não-autorizado rodando no sistema [nada além do sistema operacional deve rodar].

“Se o processo de validação de hash tiver que ser realizado pelo mesmo técnico do fabricante do software”, escreveu o secretário de estado na época, “então o processo de validação perde um de seus principais objetivos, que é garantir que o fabricante seja honesto e cumpra os requisitos de certificação impostos pelo estado”.

Para fazer essa verificação, a Electoral Assistance Commission [EAC – Comissão de Assistência Eleitoral] federal e os laboratórios de teste do sistema de votação, que examinam e certificam o software e hardware de votação, criam um hash “confiável” de cada programa de software eleitoral certificado para uso nas eleições nos EUA. Para os não técnicos, o hash é uma cifra criada – a partir do conteúdo do arquivo – por uma função matemática que não permite reversão [a operação inversa]. Entretanto, um mesmo documento [ou programa de computador] gera o mesmo hash. Isso permite comparar dois documentos [ou dois programas]. Esse hash é então usado como a assinatura do documento ou do programa. Um hash é geralmente do tipo:

127e6fbfe24a750e72930c220a8e138275656b8e5d8f48a98c3c92df2caba935

Um mesmo documento, uma mesma assinatura. Assim, quando as autoridades eleitorais recebem um novo software eleitoral [ou atualizações de software existente] para instalar em suas máquinas, eles geram o hash desse software e usam a ferramenta de verificação do fornecedor para comparar esse hash com o hash EAC “confiável” guardado nos arquivos seguros do Sistema Eleitoral.

As jurisdições variam na forma como conduzem as verificações de hash.

Estudo de um caso

O caso enfocado aqui aconteceu em 2020 e dá uma mostra da formidável complexidade do voto eletrônico, complexidade essa que não se deixa capturar por formulações simplistas e voluntarismos inócuos de ambos os lados da polarização política brasileira.

Em setembro de 2020, poucas semanas antes dos eleitores irem às urnas em uma das eleições presidenciais mais críticas e contenciosas do país, as autoridades estaduais no Texas souberam de um problema preocupante com o software eleitoral amplamente usado em seu estado e no país: Brian Mechler, um cientista de computação dos Laboratórios de Pesquisa Aplicada da Universidade do Texas em Austin, descobriu enquanto testava o software da Election Systems & Software {ES&S} no ano passado, que a ferramenta de verificação de hash da empresa nem sempre funcionava corretamente.

O componente não estava envolvido na tabulação de votos; em vez disso, se tratava-se de uma ferramenta de diagnóstico fornecida pela ES&S para auxiliar os técnicos a verificar se o software de votação instalado no equipamento eleitoral era exatamente a versão do software certificada pelo laboratório federal e que o sistema não tinha sido alterado pelo fabricante ou qualquer outra pessoa desde a data da certificação.

Com o software ES&S no Texas foi seguido o seguinte protocolo para detecção de falhas:

  • O software extraído do equipamento eleitoral é carregado em uma unidade USB.
  • O hash EAC confiável é carregado em uma segunda unidade USB, junto com três scripts: um para fazer o hash do software extraído do equipamento de eleição; um que compara os hashes desse software ao hash EAC; e um terceiro script que relata os resultados dessa verificação de hash.
  • As unidades USB são inseridas em um sistema autônomo que não é usado para eleições, onde a verificação de hash é conduzida.
  • O script que verifica os hashes é um aplicativo de código aberto chamado “diff”; o script que relata os resultados é um item separado do pacote do software, e de autoria da ES&S.

No fim do processo de inspeção, Mechler encontrou o problema no script de relatório, que indicava hashes iguais mesmo quando não havia dois hashes sendo comparados. Isso foi descoberto por acidente quando Mechler um dia se esqueceu de carregar no sistema o hash EAC confiável que fazia a verificação de hash.

No relatório que escreveu para o gabinete do secretário de estado, Mechler criticou a ES&S por produzir um roteiro de verificação mal escrito [uma falha, portanto, de processo].

O script deveria ter executado verificações explícitas sobre a existência dos dois arquivos que estão sendo comparados, devendo falhar ruidosamente caso um deles não exista. Este bug indica que a ES&S não desenvolveu seu processo de verificação de hash com […] qualidade suficiente

Mas não foi apenas a ES&S que falhou em verificar a precisão do script. Os fornecedores são obrigados a incluir o método ou ferramenta de verificação no pacote de seu software de votação. Mas não há indicação de que os laboratórios concretamente verificam se os métodos e ferramentas de verificação do software fornecidas pelo fabricante funcionam; eles simplesmente verificam se o fornecedor enviou a ferramenta.

O Government Accountability Office [GAO – Escritório de Auditoria do Governo] reconheceu esse problema há mais de uma década em um relatório publicado em 2008. O GAO aconselhou o EAC a criar um repositório certificado de software de urnas eletrônicas, estabelecer procedimentos para conduzir verificações de hash desse software e criar um protocolo para testar as ferramentas de verificação de hash do fornecedor e certificar-se de que funcionam.

Quatro anos depois, no entanto, o GAO observou que o EAC havia ignorado seus conselhos e não tinha planos de desenvolver padrões para ferramentas de verificação de hash ou um protocolo de teste para verificar se funcionavam corretamente. Isso significava, escreveu o GAO, que as jurisdições estaduais e locais não teriam “os meios para verificar de forma efetiva e eficiente se os sistemas de votação usados ​​nas eleições federais estão usando o mesmo software que os certificados pela EAC”.

A falha relatada aqui refere-se a apenas um dos componentes do software [a aplicação que gera o relatório do sistema]. Mas veja que em qualquer dessas fases uma vulnerabilidade pode estar à espreita; nas pessoas, nos dispositivos, nos procedimentos, etc. Eu poderia passar dias [ou meses] postando sobre problemas semelhantes. Eu poderia até mesmo citar as suspeitas que eu mesmo tive sobre as urnas eletrônicas, vividas pessoalmente na jornada eleitoral de 2000. Mas deixo para depois. Fico com a análise fria dos fatos.

De fato, estou começando a pesquisa para uma revisão sistemática dos artigos acadêmicos que apontam problemas nos sistema de votação eletrônicos – que espero publicar aqui quando as circunstâncias permitirem. Já no início do trabalho noto que, ao contrário do Brasil, artigos críticos ao voto eletrônico pululam na Internet anglosférica, notadamente nos EUA. Essa revisão poderá ser o primeiro post da discussão que pretendo encetar na medida em que o ciclo eleitoral de 2022 evolui.


Fonte consultada e citada: https://zetter.substack.com/p/votings-hash-problem-when-the-system

O Que Torna uma Senha Forte

É obrigatório pela política das empresas. É uma boa prática recomendada por todos. E não é novidade para praticamente nenhum de nós: as senhas devem ser longas, variadas no uso de caracteres (maiúsculas, minúsculas, números, caracteres especiais) e não baseadas em palavras de dicionário. Bastante simples, certo? Mas deixe-me ir um pouco além e fazer uma pergunta não tão simples:

O que é mais forte, uma senha aleatória de 8 caracteres que potencialmente usa todo o conjunto de caracteres ASCII (maiúsculas, minúsculas, números, caracteres especiais (incluindo um espaço)) ou uma senha aleatória de 10 caracteres que usa apenas letras maiúsculas e minúsculas?

Desconsidere por um momento qualquer situação particular; essa não é a questão.

Como fazer uma comparação exata entre as duas senhas? Elas diferem de muitas maneiras. Na literatura especializada, um argumento afirma que uma senha mais longa, mesmo usando um conjunto de caracteres menor, é mais forte. Outro argumento pode afirmar que uma senha mais curta tem potencial de ser mais forte quando extraída de uma lista maior de caracteres potenciais. Um argumento é pela extensão, o outro é pela complexidade. Então, qual é o mais resistente a um ataque?

Esta questão se aplica diretamente a discussões de políticas dentro de uma organização. Como podemos avaliar a solidez de qualquer política de senhas proposta? Seus requisitos de política são arbitrários ou baseados em algum tipo de medida quantitativa? É simples dizer, “torne as senhas suficientemente longas, complexas e não baseadas em palavras do dicionário”, mas seria possivel quantificar o que é “suficiente” para uma determinada situação? Os cenários variam. Todos nós temos necessidades diferentes e os vários sistemas têm vários níveis de suporte de senha. Ainda cabem outras perguntas: existe um ponto de diminuição dos retornos sobre a complexidade da senha? Em que ponto elas se tornam tão longas e complexas que se tornam praticamente inutilizáveis? Existe uma resposta.

A resposta (ou parte dela, pelo menos) a essas perguntas está na quantidade de entropia informacional que a senha carrega. Volumes e mais volumes de discussão já foram impressos sobre os conceitos de entropia de informação e seus usos na comunicação, mas para nossos propósitos vamos apenas dizer que, no final, o conceito de entropia de senha nos fornece uma maneira de comparar empiricamente a força potencial de uma senha com base em seu comprimento e no universo de caracteres que ela pode conter. Para explicar o porquê, deixe-me começar com uma demonstração simples.

Selecione aleatoriamente uma letra de A – Z.

Agora vou tentar adivinhar. Quantas suposições você acha que vou precisar? Eu poderia adivinhar em apenas uma tentativa? Sim. Mas também posso precisar de 25 palpites, certo? Se eu simplesmente começasse a adivinhar aleatoriamente, meu sucesso também seria aleatório. Mas se eu aplicar os conceitos básicos da teoria da informação para a execução da tarefa, algo muito interessante acontece. Não importa qual letra você selecione, sempre precisarei de apenas quatro (4), e nunca mais do que cinco (5) perguntas para adivinhar sua letra. Em contraste, se eu fosse adivinhar ao acaso, precisaria, em média, de 13 tentativas para adivinhar sua letra. Mas quando conceitos de entropia de informação são aplicados, o número de perguntas / suposições cai para consistentes 4 ou 5. O motivo é bastante simples: eu não “adivinho” as letras; eu as elimino. Suponhamos que a letra que você selecionou seja “D”. Aqui está como minha cadeia de questionamento (o algoritmo) se comporta:

Pergunta 1: sua letra está entre N e Z? Resposta: Não.
    Se sim, sua letra está entre N-Z.
    Se não, sua letra é entre A-M.

Pergunta 2: sua letra está entre A e G? Resposta: sim.
    Se sim, sua letra é entre A-G.
    Se não, sua letra é entre H-M.

Pergunta 3: sua letra está entre A-D? Resposta: sim.
    Se sim, sua letra é entre A-D.
    Se não, sua letra é entre E-G.

Pergunta 4: sua letra está entre A-B? Resposta: Não.
    Se sim, sua letra é entre A-B.
    Se não, sua letra é entre C-D.

Pergunta 5: A sua letra é C? Resposta: Não.
    Se sim, sua letra é C.
    Se não, sua letra é D.

Resultado: sua letra é D. Estimativas: 5

Vamos fazer de novo. Desta vez, vamos supor que você escolheu aleatoriamente a letra “H”.

Pergunta 1: sua letra está entre N e Z? Resposta: Não.
    Se sim, sua letra está entre N-Z.
    Se não, sua letra é entre A-M.

Pergunta 2: sua letra está entre A e G? Resposta: Não.
    Se sim, sua letra é entre A-G.
    Se não, sua letra é entre H-M.

Pergunta 3: sua letra está entre H-I? Resposta: sim.
    Se sim, sua letra é entre H-I.
    Se não, sua letra é entre J-K.

Pergunta 4: A sua letra é H? Resposta: sim.
    Se sim, sua letra é H.
    Se não, sua letra é entre I-J.

Resultado: sua letra é H. Estimativas: 4

A imagem abaixo mostra a árvore de decisão usada. Cada ‘x’ laranja é uma pergunta. As letras destacadas em verde serão identificados em 4 questões e as letras destacadas em amarelo serão identificadas em 5. A árvore de decisão na imagem mostra apenas a metade esquerda do alfabeto (A-M). Você pode replicar o lado direito do alfabeto (N-Z) em uma árvore semelhante. Se você examinar o número de questões para todas as 26 letras do alfabeto, verá que seis (6) das letras podem ser identificadas em quatro (4) questões, enquanto as vinte (20) letras restantes serão identificadas em cinco (5) questões.

Árvore de decisão do problema

Então, se fôssemos jogar esse jogo de adivinhação indefinidamente, quantas perguntas, em média, eu precisaria para adivinhar a letra escolhida?

Para calcular o número médio de perguntas que terei que fazer para determinar sua letra, tenho que saber qual será a probabilidade de uma letra ser selecionada. Para este exemplo, estou supondo que cada uma das 26 letras do alfabeto tem uma chance estatisticamente igual de ser selecionada (mais sobre as nuances dessa suposição posteriormente). Um cálculo rápido mostra que 1/26 = 0,0384. Convertendo isso em porcentagem saberemos que cada letra tem 3,84% de chance de ser a letra selecionada aleatoriamente.

Como aqui não fugimos da matemática e valentemente a enfrentamos, há uma equação para essa pergunta. Vejamos:

Esta equação calcula H, que é o símbolo usado para entropia. Para o nosso alfabeto, a equação ficaria assim:

H = – [(0,038log2 • 0,038) + (0,038log2 • 0,038) + (0,038log2 • 0,038) + (0,038log2 • 0,038) +
(0,038log2 • 0,038) + (0,038log2 • 0,038) + (0,038log2 • 0,038) + (0,038log2 • 0,038) + (0,038log2 • 0,038) +
(0,038log2 • 0,038) + (0,038log2 • 0,038) + (0,038log2 • 0,038) + (0,038log2 • 0,038) + (0,038log2 • 0,038) +
(0,038log2 • 0,038) + (0,038log2 • 0,038) + (0,038log2 • 0,038) + (0,038log2 • 0,038) + (0,038log2 • 0,038) +
(0,038log2 • 0,038) + (0,038log2 • 0,038) + (0,038log2 • 0,038) + (0,038log2 • 0,038) + (0,038log2 • 0,038) +
(0,038log2 • 0,038) + (0,038log2 • 0,038)] = 4,7004

E agora temos a resposta: terei que fazer uma MÉDIA de 4.7004 perguntas para determinar a letra selecionada aleatoriamente no alfabeto.

Mais formalmente, diríamos que existem 4.7004 ‘bits de entropia’.

Se você aplicar esta matemática a um único caractere selecionado aleatoriamente a partir dos diferentes conjuntos de caracteres que existem, você obterá o seguinte:

Binário (0, 1) -> H = 1 (1 bit de entropia)
Terei que fazer uma pergunta para determinar se o valor selecionado aleatoriamente é 1 ou 0.

Decimal (0-9) -> H = 3,32193 (3,2193 bits de entropia)
    Terei que fazer uma média de 3,32193 perguntas para determinar o número selecionado aleatoriamente (0-9).

Hexadecimal (0-9, A-F) -> H = 4.000
    Terei que fazer quatro (4) perguntas para determinar seu valor (a-f, 0-9)

Alfabeto maiúsculo e minúsculo (a-z, A-Z) -> H = 5,7004
    Terei que fazer uma média de 5.7004 perguntas para determinar sua letra selecionada aleatoriamente (a-z, A-Z).

Todos os caracteres ASCII imprimíveis (incluindo espaço) -> H = 6,5699
    Terei que fazer uma média de 6.5699 perguntas para determinar seu valor selecionado aleatoriamente.

Vamos desenvolver isso um pouco mais. Os números acima são para uma ÚNICA letra selecionada aleatoriamente. E se eu pedisse para você escolher duas (2) letras aleatoriamente? Agora, adivinhando uma letra de cada vez, quantas tentativas, em média, eu precisaria para descobrir as duas? A resposta é aditiva, o que significa que você só precisa adicionar a entropia para cada letra. Se a entropia de uma única letra minúscula é 4,7004, a entropia de duas letras selecionadas aleatoriamente é 4,7004 + 4,7004. Isso é 9.4008 perguntas para determinar as duas letras (assumindo a-z, como em nosso exemplo original). Se eu pedisse a você para selecionar uma seqüência de dez (10) caracteres aleatórios, seria necessária uma média de 47,004 perguntas (4,7004 * 10) para adivinhar todos eles.

Tudo bom, tudo bem, mas isso presume que sou capaz de adivinhar apenas um valor de cada vez. Se você escolhesse aleatoriamente 10 letras do alfabeto, eu poderia adivinhar a primeira em cerca de 4,7 tentativas, a segunda em 4,7 tentativas, a terceira em 4,7 tentativas e assim por diante. Mas no mundo real, não é assim que se adivinha senhas (um caractere por vez). Um invasor terá que adivinhar corretamente todos os dez valores de uma só vez para determinar as letras selecionadas aleatoriamente. Isso é, obviamente, uma coisa muito mais difícil de fazer. Mas quão difícil? Para descobrir, vamos voltar à pergunta original que fiz:

O que é mais forte, uma senha aleatória de 8 caracteres que potencialmente usa todo o conjunto de caracteres ASCII (maiúsculas, minúsculas, números, caracteres especiais ( incluindo um espaço)) ou uma senha aleatória de 10 caracteres que usa apenas letras maiúsculas e minúsculas?

Bem, se seu conjunto de caracteres tiver 26 letras minúsculas (az), 26 caracteres maiúsculos (AZ), e sua senha tiver 10 caracteres, haverá 5210 combinações possíveis de letras (26 caracteres (az) + 26 caracteres ( AZ) = 52 caracteres). Esse é um número grande. 144.555.105.949, 057.000 (144,5 quatrilhões), para ser exato ..

Então, para resumir esses valores:

Número de caracteres no conjunto de caracteres (a-z, A-Z): 52
Número de caracteres na senha: 10
Número total de combinações possíveis de sequências de 10 caracteres: = 52^10 = 144.555.105.949.057.000

É aqui que a magia entra em ação:

Qual é a entropia de um único caractere no conjunto completo de caracteres alfa (a-z, A-Z)? Já determinamos que é 5.7004.

Qual é o tamanho da sequência de caracteres selecionada aleatoriamente? 10 caracteres.

Qual é a entropia de uma string de 10 caracteres usando o conjunto de caracteres alfa maiúsculos / minúsculos? 5,7004 * 10 = 57,004

O que é 257,004 ? São 144.555.105.949.057.000 !!! Caramba!!! É o mesmo número que 5210 !!!

Sua string de 10 caracteres, maiúsculas / minúsculas (senha) tem 57,004 bits de entropia. Supondo que um invasor acertaria a string em 50% de todas as suposições possíveis, estimamos que ele / ela terá que fazer 72.277.552.974.528.300 suposições (sim, em média) antes de adivinhar sua string de 10 caracteres.

Para dizer isso de forma mais significativa: Uma senha de 10 caracteres maiúsculos / minúsculos tem 57,004 bits de entropia.

Então, quantos bits de entropia nossa senha concorrente tem? É uma senha de 8 caracteres que utiliza o conjunto completo de caracteres ASCII (incluindo um espaço). Se você voltar ao meio desta postagem, verá que um caractere selecionado aleatoriamente do conjunto completo de caracteres ASCII tem 6,5699 bits de entropia. Isso significa que uma senha de 8 caracteres selecionada aleatoriamente nesse intervalo terá 52.559 (8 * 6.5699) bits de entropia.

Para resumir os valores das senhas de 8 caracteres:

Número de caracteres no conjunto de caracteres (a-z, A-Z, 0-9, todos os caracteres especiais, incluindo espaço): 95
Número de caracteres na senha: 8
Número total de combinações possíveis de sequências de 8 caracteres: = 958 = 6.634.204.312.890.620 (6,63 quatrilhões)

E vemos que a magia é real:

Qual é a entropia de um único caractere no conjunto de caracteres ASCII completo (incluindo espaço)? Já determinamos que é 6,5699.

Qual é o tamanho da sequência de caracteres selecionada aleatoriamente? 8 caracteres.

Qual é a entropia de uma string de 8 caracteres usando o conjunto de caracteres alfa maiúsculos e minúsculos? 6,5699 * 8 = 52,559

O que é 252.559? É 6.634.204.312.890.620 !!! Caramba, de novo !!! É o mesmo número que 958 !!!

Nossa senha de 10 caracteres em maiúsculas / minúsculas tem 57,004 bits de entropia.
Nossa senha de conjunto de caracteres ASCII completa de 8 caracteres tem 52.559 bits de entropia.

Quanto mais bits de entropia uma senha possui, mais forte ela é. E, isso é importante, pois um único bit de entropia representa um aumento EXPONENCIAL na resistencia da senha. Há uma grande diferença entre a força de nossas duas senhas (4,445 ordens de magnitude); isso não é trivial. É algo enorme.

Então, por que usar a entropia como a expressão da força (resistência) da senha? Os gurus da teoria da informação podem certamente dar palestras por dias sobre essas questões, mas há uma resposta simples: os humanos são realmente péssimos para lidar com grandes números. Basta ver como lembramos números de telefone, endereços IP, números de cartão de crédito e números de CPF para evidenciar nossa repulsa por grandes números. Se houver uma maneira de simplificar a expressão de um valor, sempre optaremos por ela. Afinal, o que é mais fácil de dizer e entender ?:

Minha senha tem 5210 possibilidades vs 958 possibilidades.
ou;
Minha senha tem 57,004 bits de entropia vs 52,559 bits de entropia.

Com certeza você achará esta última forma mais agradável.

Quanto maior o número de bits de entropia de uma senha, mais forte ela tem o potencial de ser. Eu uso a palavra “potencial” aqui porque há muitas nuances nessa discussão que podem tornar esses números um reflexo impreciso da força da senha. A principal delas é o fato de que a maioria das senhas são geradas por humanos, não por geradores de números aleatórios. Os humanos são muito, muito ruins em gerar aleatoriedade. Somos terrivelmente péssimos nisso. Isso significa que a equação usada acima, que assume que cada caracter tem uma probabilidade igual de ser selecionado, não é tão precisa quando é uma pessoa que está escolhendo as letras. Quando invasores, com auxilio do poder de computação, começam a fazer suposições realmente boas sobre como as senhas estão sendo criadas (permitindo que eles excluam certos valores, por exemplo), a entropia pode cair muito rapidamente. Isso é não é bom.

É frequente acontecer que um dos sistemas de uma organização pode suportar o uso do conjunto de caracteres ASCII completo ao definir senhas, enquanto outro pode suportar apenas senhas alfanuméricas. Quantos bits de entropia uma senha deve ter para ser adequadamente segura? Quão longa uma senha alfanumérica deve ser para ser tão forte quanto uma senha que usa o conjunto completo de caracteres? Essas são perguntas muito importantes, especialmente quando se trata de uma política corporativa de senhas. Especificar o comprimento da senha pode ser uma medida inadequada de resistencia; especificar requisitos de entropia de senha tem o potencial de ser uma expressão muito mais consistente dos requisitos de segurança. Não tenho uma citação aqui, mas muitas organizações gostam de ter 80 bits de entropia ou mais. Nos dias de hoje, isso é muita entropia. Cheque novamente em alguns anos e certamente veremos que essa declaração se tornou falsa (pela Lei de Moore).

Uma observação final: há muitas variáveis ​​que devem ser discutidas ao explorar o assunto “senhas”. Complexidade, comprimento e entropia são todos ótimos itens para se entender, mas outros fatores podem ser tão importantes quanto. Por exemplo, quais mecanismos subjacentes suas senhas empregam? Qual algoritmo de hash? As senhas são “salgadas”? Há algum tipo de mecanismo de compatibilidade com versões anteriores habilitado (NTLM, etc.)? Essas coisas influenciam a discussão tanto quanto a entropia e podem ter um grande impacto em quanto esforço um invasor terá de fazer para adivinhar a senha. É um grande tópico, digno de muita reflexão e reflexão cuidadosa. A entropia é um ótimo lugar para começar… mas não é a única coisa a se considerar.

Os Perigos do Software Evidencial – ou Quem Garante o Bafômetro?

No Lawfare Blog, Susan Landau escreve um excelente ensaio sobre os riscos apresentados pelos aplicativos usados em dispositivos de coleta de evidências (um bafômetro é provavelmente o exemplo mais óbvio). Bugs e vulnerabilidades nessa classe de equipamento podem levar a evidências imprecisas. Para compor o problema, a natureza proprietária do software torna difícil para a equipe de defesa dos réus examiná-lo. A seguir um brevíssimo resumo da essência do material.

Imagem: iStock

[…]

Os engenheiros de software propuseram um teste de três partes.

Primeiro, o tribunal deve ter acesso ao “Log de erros conhecidos”, algo que deve fazer parte de qualquer bom projeto de software desenvolvido profissionalmente.

Em seguida, o tribunal deve considerar se as provas apresentadas podem ser afetadas materialmente por um erro de software. Ladkin e seus co-autores observaram que a maioria das funcionalidades não apresentará erro, mas o momento preciso em que o software registra o uso do dispositivo pode facilmente estar incorreto.

Finalmente, os especialistas em confiabilidade recomendaram verificar se o código adere a um determinado padrão da indústria usado em uma versão não computadorizada da tarefa (por exemplo, os contadores sempre registram todas as transações – portanto, o software usado na contabilidade também deve registrar).

[…]

Objetos inanimados há muito servem como prova em tribunais: a maçaneta da porta contendo uma impressão digital, a luva encontrada na cena de um crime, o resultado do bafômetro que mostra um nível de álcool no sangue três vezes o limite legal. Mas o último desses exemplos é substancialmente diferente dos outros dois. Os dados de um bafômetro não são a entidade física em si, mas sim um cálculo de um software a respeito do nível de álcool no hálito de um motorista potencialmente bêbado. Desde que a amostra de respiração tenha sido preservada, pode-se sempre voltar e testá-la novamente em um dispositivo diferente.

O que acontece se o software cometer um erro e não houver mais nenhuma amostra para verificar? Ou, e se o próprio software produzir a evidência contra o réu? No momento em que escrevemos este artigo, não havia nenhum precedente no qual a lei permita que o próprio réu examine o código subjacente.

[…]

Dada a alta taxa de erros em sistemas de software complexos, meus colegas e eu concluímos que, quando programas de computador produzem uma prova, os tribunais não podem presumir que o software probatório seja confiável. Em vez disso, a acusação deve disponibilizar o código para uma “auditoria contraditória” pelos especialistas designados pelo réu[1]. E para evitar problemas em que o governo não tenha o código para que este seja inspecionado, os contratos de compras governamentais devem incluir a garantia de entrega do código-fonte do software adquirido – código que seja mais ou menos legível pelas pessoas – para cada versão do código ou dispositivo.

Ler o trabalho na íntegra [em inglês] em Lawfare Blog.

* * *

O comentário pertinente é: o Estado pode exigir calibração regular do bafômetro, mas quem os inspeciona? Há garantia de que o poder público multará a polícia por não verificar se os bafômetros estão calibrados de forma adequada além de estar também funcionando corretamente? E quem calibra os calibradores?

Se nenhuma amostra da respiração for retida, apenas o registro da observação do software, como a leitura de um bafômetro é essencialmente diferente de um boato ou palavra-de-boca? Será porque o bafômetro é “tecnológico”? Assumir que o instrumento é mais preciso que uma testemunha humana, apenas porque é tecnológico, gera outros grandes problemas conceituais.

Mas acho que o ponto mais amplo é este: dada a quase total falta de responsabilidade da indústria do software, a inescrutabilidade do código proprietário e a qualidade duvidosa da maioria do software comercial, um tribunal – que busca a verdade – não deve acolher prima facie evidências que consistam exclusivamente do resultado de um software.

Este não é um problema técnico, mas um problema legal causado por políticas inadequadas: a indústria do software precisa de regulamentação, responsabilidade e reforma das leis de direitos autorais.

[1] Um especialista que consultei – que um dia estará escrevendo neste espaço, gentilmente me explicou [o que agradeço penhoradamente] que esse protocolo não existe no ordenamento brasileiro. Mas da explicação depreendo que a lei brasileira pode comportar soluções análogas a essa.

Confiança Zero: Nada é Seguro na Internet

O decreto de segurança cibernética do presidente Joe Biden, assinado no último 12 de maio, estipula que o governo federal americano adote uma “arquitetura de confiança zero” em seus sistemas computacionais. Isso levanta algumas questões. O que é segurança de confiança zero? E mais, se a confiança no usuário é ruim para a segurança, por que a maioria das organizações do governo e do setor privado a pratica?

Imagem: iStock

Uma consequência do excesso de confiança online é a epidemia de ‘ransomware‘ [programas maliciosos que sequestram o sistema em que operam, através da encriptação do conteúdo], um problema global crescente, que afeta grandes e pequenas organizações. Intrusões de alta visibilidade, como a recentemente experimentada pela empresa Colonial Pipeline, nos EUA, são apenas a ponta do iceberg.

Houve pelo menos 2.354 ataques de ransomware em governos locais, instalações de saúde e escolas nos Estados Unidos no ano passado. Embora as estimativas variem, as perdas com ransomware parecem ter triplicado em 2020 para mais de US$ 300.000 por incidente. E os ataques estão ficando mais sofisticados.

Um tema recorrente em muitas dessas violações é a confiança perdida – em fornecedores, funcionários, software e hardware. Como profissional de sistemas e estudioso de segurança digital tenho interesse em questões de confiança. Comentemos aqui alguns aspectos da arquitetura de confiança zero, e como ela contribui para a resistência dos sistemas distribuidos.

Segurança sem confiança

A confiança, no contexto das redes de computadores, refere-se a sistemas que permitem o acesso de pessoas, ou outros computadores, com pouca ou nenhuma verificação sobre quem são e se estão autorizados a ter acesso. Por outro lado, ‘confiança zero’ é um modelo de segurança que pressupõe que as ameaças são onipresentes, dentro e fora das redes. Assim, a confiança zero depende de verificações contínuas por meio de informações de várias fontes. Essa abordagem pressupõe a inevitabilidade da violação dos dados. Em vez de se concentrar exclusivamente na prevenção de violações, a segurança de confiança zero procura garantir que os danos sejam limitados, que o sistema seja resiliente e possa se recuperar rapidamente.

Usando uma analogia epidemiológica, a abordagem da confiança zero para a segurança cibernética sempre pressupõe que uma infecção está apenas a um perdigoto – ou, neste caso, um clique – de distância. Dito de outra forma, em vez de defender o castelo, esse modelo assume que os invasores já estão dentro das muralhas.

Não é difícil ver os benefícios do modelo de confiança zero. Se a Colonial Pipeline tivesse adotado um sistema parecido, o ataque de ransomware de que foi vítima provavelmente teria falhado e as pessoas não teriam entrado em pânico. E se a segurança de confiança zero fosse de uso generalizado na rede, a epidemia de ransomware que nos flagela seria muito menos custosa

Quatro obstáculos para perder a confiança

Existem pelo menos quatro barreiras que impedem a adoção de arquiteturas de confiança zero nos sistemas governamentais e privados.

Em primeiro lugar, os sistemas legados e a infraestrutura geralmente são impossíveis de atualizar. Alcançar a segurança de confiança zero requer uma defesa em camadas, que envolve a construção de vários níveis de segurança. No entanto, é muito difícil de implementar em sistemas que não foram construídos com esse objetivo em mente, porque essa arquitetura requer verificação independente em cada camada.

Em segundo lugar, mesmo que seja possível fazer upgrade, o custo será significativo. É caro, demorado e potencialmente perigoso reprojetar e reimplantar sistemas, especialmente se eles forem feitos sob medida. O Departamento de Defesa dos EUA sozinho opera mais de 15.000 redes em 4.000 instalações espalhadas por 88 países.

Terceiro, as tecnologias ponto-a-ponto, como os computadores que executam Windows 10 em uma rede local, não são adequadas à confiança zero porque são baseadas principalmente em senhas, e não em autenticação multifator em tempo real. Senhas podem ser quebradas por botnets que calculam rapidamente muitas senhas possíveis – os chamados ‘ataques de força bruta’ – enquanto a autenticação multifator em tempo real requer, além de senhas, uma ou mais formas adicionais de verificação – normalmente um código enviado por e-mail ou texto. (*)O Google anunciou recentemente a decisão de exigir autenticação multifator para todos os seus usuários.

Quarto, fazer a migração dos sistemas de informação de uma organização para serviços em nuvem pode melhorar as condições para a adoção da confiança zero, mas apenas se tudo for feito da maneira correta. Isso exige a criação de novos aplicativos na nuvem, em vez de simplesmente mover os aplicativos existentes para a nuvem. As organizações precisam de expertise para planejar uma segurança de confiança zero ao migrar para a nuvem, o que nem sempre está disponível.

O Decreto de Biden

A ordem executiva do governo Biden tenta promover uma defesa em camadas para enfrentar os problemas de segurança cibernética do país. A ordem executiva seguiu várias recomendações da Cyberspace Solarium Commission, uma comissão formada pelo Congresso para desenvolver uma abordagem estratégica para defesa dos EUA no ciberespaço.

Entre outras coisas, a abordagem se inspira nas estruturas de confiança zero propostas pelo Instituto Nacional de Padrões e Tecnologia (National Institute for Standards and Technology – NIST). Ela também convoca o Departamento de Segurança Interna (Department of Homeland Security – DHS) a assumir a liderança na implementação dessas técnicas, inclusive em seus programas baseados em nuvem.

Quando combinada com as outras iniciativas definidas na ordem executiva – como a criação de um Conselho de Segurança Cibernética e a imposição de novos requisitos para a segurança da cadeia de suprimentos de software para fornecedores federais – a segurança de confiança zero pode, de fato, levar os EUA na direção certa.

No momento, essa ordem executiva se aplica apenas aos sistemas governamentais. Ela não teria impedido o ataque à Colonial Pipeline, por exemplo. Para colocar o país como um todo em uma posição mais segura é preciso ajudar o setor privado a também adotar essas práticas de segurança. Isso exigirá ação do Congresso.

Publicado sob a Licença Creative Commons 4.0

Adaptado de “The Conversation

Verdades, Mentiras e Automação

Sob licença, apresentamos a seguir, traduzido e adaptado, um muito temporâneo estudo publicado no último dia 21 pelos autores Ben Buchanan, Andrew Lohn, Micah Musser e Katerina Sedova, do Centro para Segurança e Tecnologia Emergente (CSET – Center for Security and Emerging Technology), analisando o terrivel problema da desinformação turbinada por tecnologias de “Inteligência Artificial” (mais propriamente referida como Aprendizado de Máquina). O texto é narrado na primeira pessoa do plural

Por milênios, campanhas de desinformação têm sido empreendimentos fundamentalmente humanos. Seus perpetradores misturam verdades e mentiras em potentes combinações, que visam semear a discórdia, criar dúvidas e provocar ações destrutivas. A campanha de desinformação mais famosa do século XXI – o esforço russo para interferir na eleição presidencial dos EUA de 2016- contou com centenas de pessoas trabalhando juntas para ampliar as fissuras preexistentes na sociedade americana.

Desde o início, escrever sempre foi um esforço fundamentalmente humano. Mas as coisas não são mais assim. Em 2020, a empresa OpenAI revelou o GPT-3, (Generative Pre-trained Transformer) um poderoso sistema de “inteligência artificial” que gera texto baseado em um estímulo provocado por operadores humanos. O sistema, que combina uma vasta rede neural, um poderoso algoritmo de aprendizado de máquina e mais de um trilhão de palavras de escrita humana para orientação, é notável. Entre outras realizações, ele já redigiu um artigo de opinião encomendado pelo The Guardian, escreveu histórias originais que a maioria dos leitores pensava ter sido escrita por humanos e criou novos memes para a Internet.

Diante dessa descoberta, consideramos uma questão simples, mas importante: pode a automação gerar conteúdo para campanhas de desinformação? Se o GPT-3 pode escrever notícias aparentemente confiáveis, é possível também que possa escrever notícias falsas convincentes; se pode redigir artigos de opinião, talvez possa redigir tweets enganosos.

Para resolver esta questão, primeiro apresentamos o conceito de parceria ou equipe homem-máquina, mostrando como o poder do GPT-3 deriva, em parte, do estímulo criado pelo homem, ao qual ele responde. Ganhamos acesso gratuito ao GPT-3 – um sistema que não está disponível para uso público – para estudar a capacidade do GPT-3 de produzir desinformação como parte de uma equipe homem-máquina.

Mostramos que, embora o GPT-3 seja bastante capaz por seus próprios méritos, ele atinge novos patamares de capacidade quando combinado com um operador/editor humano experiente. Como resultado, concluímos que, embora o GPT-3 não substitua totalmente os humanos nas operações de desinformação, ele é uma ferramenta que pode ajudar a criar mensagens de qualidade moderada a alta, em uma escala muito maior do que anteriormente possível.

Para chegar a esta conclusão, avaliamos o desempenho do GPT-3 em atividades que são comuns em muitas campanhas de desinformação modernas. A Tabela 1 descreve essas tarefas e o desempenho do GPT-3 em cada uma.

Tabela 1

Entre essas e outras avaliações, o GPT-3 provou ser tão poderoso como limitado. Quando estimulada de maneira adequada, a máquina funciona como um gravador versátil e eficaz que, no entanto, é limitado pelos dados nos quais foi treinada. Sua redação é imperfeita, mas essas suas desvantagens – como falta de foco na narrativa e tendência a adotar pontos de vista extremos – têm pouca importância na criação de conteúdo para campanhas de desinformação.

Caso os adversários optem por empregar esse tipo de automação em suas campanhas de desinformação, acreditamos que a implantação de um algoritmo como o GPT-3 esteja dentro da capacidade de governos estrangeiros, especialmente os que entendem de tecnologia, como China e Rússia. Será difícil, mas quase certamente possível para esses governos construir a capacidade computacional necessária para treinar e operar tal sistema, caso desejem fazer isso.

Mitigar os perigos da automação na desinformação é um desafio. Uma vez que o texto produzido pela GPT-3 combina tão bem com a escrita humana, a melhor maneira de impedir o uso de sistemas como o GPT-3 em campanhas de desinformação é se concentrar na infraestrutura usada para propagar as mensagens da campanha, como contas falsas nas redes sociais, em vez de tentar determinar a quem atribuir o texto.

Vale a pena considerar as mitigações porque nosso estudo mostra que há uma possibilidade real de se usar ferramentas automatizadas para gerar conteúdos para campanhas de desinformação. Em particular, nossos resultados devem ser encarados como uma estimativa pessimista do que sistemas como o GPT-3 podem oferecer. Adversários não limitados por preocupações éticas e estimulados por grandes recursos e capacidade técnica, provavelmente serão capazes de usar sistemas como o GPT-3 de maneira mais abrangente do que nós nesta pesquisa, embora seja difícil saber se eles realmente vão optar por essa linha de ação.

Em particular, com a infraestrutura certa, eles provavelmente serão capazes de aproveitar a escalabilidade que tais sistemas automatizados oferecem, gerando um grande número de mensagens e inundando o cenário de informações com as criações mais mirabolantes.

Nosso estudo mostra a plausibilidade – mas não a inevitabilidade – desse futuro, no qual mensagens automatizadas de divisão política e informações enganosas se propagam pela Internet. Enquanto mais desenvolvimentos ainda certamente estejam por vir, um fato já é aparente: as máquinas construídas por humanos agora podem ajudar a temperar a verdade e a mentira a serviço da desinformação.

Publicado sob a licença Creative Commons nc 4.0

Link para o trabalho original, na íntegra:

Blockchain e o Voto

De vez em quando sou questionado sobre ideias envolvendo sistemas de votação eletrônicos, remotos e blockchains. Este post fala sobre as propriedades mínimas de segurança que um sistema de votação precisa ter, e sobre onde as blockchains ajudam e onde não ajudam. Usamos como exemplo o sistema criptografado de votação STAR-vote. Pode ser um pouco árido para os usuários não técnicos, mas também pode ser interessante para quem gosta de se envolver mais profundamente no tema.

Uma interface digital abstrata, mostrando pastas com chave pública e dados de hash escritos em código.

A comunidade de computação concorda que sistemas votação rodando em máquinas de votar modernas têm ao seu dispor processadores muito rápidos e uma quantidade enorme de armazenamento. Esse hardware moderno torna menos árdua a tarefa de implementar redes que exigem computação de alta-performance, como a Blockchain. Vamos então usar esse dado estrutural para um experimento mental:

Usando o work-flow da Blockchain, vamos colocar as máquinas de votação em rede, dentro da Blockchain. Assim, voilà, temos uma estrutura descentralizada, com uma cópia de cada voto em cada máquina de votação; podemos até usar o emaranhamento da linha do tempo, para que o histórico de cada máquina seja protegido por hashes armazenados em todas as outras máquinas. O problema da votação eletrônica está resolvido.

Em um sistema eleitoral implementado na Blockchain, todas as máquinas do sistema possuem todos os registros de votos, tornando impossível a fraude. É o mesmo esquema que legitima transações financeiras. Neste caso, a transação é o voto.

Mas qual é o ponto forte de uma blockchain? No aspecto mais fundamental, trata-se de ter um registro histórico inviolável sobre eventos. No contexto de um sistema de votação, significa que uma blockchain é um lugar perfeito para armazenar cédulas e proteger sua integridade. O STAR-Vote e muitos outros sistemas de votação criptografados “ponta a ponta” adota o conceito de “quadro público de avisos” para onde os votos criptografados são enviados para armazenagem até a contagem. Blockchain é a maneira óbvia de implementar o quadro público de avisos.

Cada eleitor do STAR-Vote sai do local de votação com um “recibo” que é apenas o hash de sua cédula criptografada, que por sua vez tem o hash da cédula do eleitor anterior. Em outras palavras, todos os eleitores do STAR-Vote deixam o local de votação com um ponteiro para a blockchain que pode ser verificado de forma independente.

Acontece que mesmo os sistemas de votação baseados em blockchain precisam de muitas propriedades de segurança adicionais antes que possam ser efetivamente confiáveis. Aqui está uma lista simplificada, empregando algum vocabulário típico desta área de estudos para referenciar essas propriedades.

Propriedade “Votado como pretendido”.

Um eleitor está olhando para uma tela de algum tipo e escolhe em um botão: “Alice para presidente”. A máquina de votação prontamente indica isso com um pop-up, ou algum texto destacado, ou sons. Contudo, é totalmente possível que algum malware dentro da máquina possa registrar silenciosamente o voto como “Bernie para presidente”. Portanto, qualquer sistema de votação precisa de um mecanismo para derrotar malware que ameace comprometer a integridade da votação.

Nota: Uma abordagem interessante aqui [e já consagrada pelo costume americano] é ter cédulas de papel impressas (e/ou cédulas de papel marcadas à mão) que podem ser comparadas estatisticamente às cédulas eletrônicas. Outra abordagem é ter um processo pelo qual a máquina pode ser “desafiada” a provar que criptografou corretamente a cédula.

Propriedade “Votado em privacidade”.

É importante que não seja possível identificar um eleitor em particular pela forma como ele votou. A votação moderna deve garantir que os votos sejam secretos, com várias medidas tomadas para tornar difícil ou impossível para os eleitores violarem esse sigilo.

Quando se deseja manter a propriedade de privacidade eleitoral nas máquinas da votação, significa que deve-se evitar que a máquina retenha o estado interno (ou seja, mantenha em seus circuitos uma lista dos votos em texto aberto, na ordem de votação) e também deve garantir que o texto cifrado dos votos, publicado na blockchain, não está vazando silenciosamente, por meio de canais subliminares, informações sobre o texto aberto que o gerou.

Propriedade “Contado como votado”.

Se temos eleitores levando para casa um recibo de algum tipo que identifica seu voto de texto cifrado na blockchain, então eles também podem querer ter algum tipo de prova criptográfica de que a contagem final do voto inclui seu voto específico. Isso acaba sendo uma aplicação direta de primitivos criptográficas homomórficos.

Se olharmos para essas três propriedades, é possível notar que a blockchain não ajuda muito com as duas primeiras, embora seja muito útil para a terceira.

Atingir a propriedade “votado como pretendido” requer uma variedade de mecanismos que vão de cédulas de papel a desafios pontuais para máquinas. A blockchain protege a integridade do voto registrado, mas nada tem a dizer sobre sua fidelidade à intenção do eleitor.

Para alcançar uma propriedade “votado em privacidade”, é necessário bloquear o software na plataforma de votação e, nesse caso, bloquear a máquina de votar. E como essa propriedade de bloqueio pode ser verificada? Precisamos de garantias fortes que possam ser verificadas de forma independente. Também precisamos garantir que o usuário não possa ser enganado e levado a executar um aplicativo de votação falso. Podemos conseguir isso no contexto das urnas eletrônicas comuns, que são utilizadas exclusivamente para fins de votação. Podemos implantar centralmente uma infraestrutura de chave criptográfica e colocar controles físicos sobre o movimento das máquinas.

Mas, se estendermos este experimento mental para incluir o voto pela Internet, um desejo comumente expresso pelo público de alguns países [que talvez aconteça], veremos que não temos infraestrutura hoje para fazer isso usando telefones celulares e computadores pessoais – e provavelmente não a teremos nos próximos anos. O voto remoto [em casa, no escritório, na rua] também torna excepcionalmente fácil para um cônjuge, um chefe ou um vizinho vigiar por cima do seu ombro e “ajudá-lo” a votar da maneira que eles querem que você vote.

As blockchains acabam sendo incrivelmente úteis para verificar a propriedade “contado como votado”, porque obriga todas as máquinas do sistema a concordar com o conjunto exato de cédulas que está sendo tabulado. Se um funcionário eleitoral precisar desqualificar uma cédula por qualquer motivo, esse fato precisa ser público e todos precisam saber que uma cédula específica, ali na blockchain, precisa ser descontada, caso contrário, a matemática criptográfica não vai fechar.

Concluindo, é fácil ver como as blockchains fornecem elementos primitivos excepcionalmente úteis, que podem ajudar a construir sistemas de votação em que a contagem final é consistente com os registros de votos lançados. No entanto, um bom sistema de votação precisa satisfazer muitas propriedades adicionais que uma blockchain não pode fornecer. Embora haja uma certa sedução intelectual em fingir que votar não é diferente do que mover criptomoedas em uma blockchain, a realidade do problema é um pouco mais complicada.

Nova Vulnerabilidade no Zoom

Uma vulnerabilidade “dia-zero” no Zoom, que pode ser usada para lançar ataques de execução de código remoto (Remote Code Execution, RCE), foi divulgada por pesquisadores. Pwn2own, organizado pela iniciativa Zero-Day, é um concurso para profissionais de segurança cibernética com o objetivo de descobrir falhas em software e serviços populares.

A última competição incluiu 23 participantes, em várias categorias, como navegadores Web, software de virtualização, servidores, comunicação empresarial e escalada local de privilégio.

Para os participantes bem-sucedidos, as recompensas financeiras podem ser altas – e, neste caso, os holandeses Daan Keuper e Thijs Alkemade ganharam US$ 200.000 por sua descoberta sobre o Zoom.

Os pesquisadores (da Computest) demonstraram uma cadeia de ataque consistindo de três falhas, que provocou uma Execução Remota de Código em uma máquina-alvo, sem qualquer interação do usuário.

Zoom ainda não teve tempo para corrigir essa questão crítica de segurança.

A vulnerabilidade

Atendendo aos requisitos da divulgação responsável, os detalhes completos do método são mantidos em segredo. O que sabemos é que é uma falha de execução de código remoto (RCE): uma classe de falhas de segurança de software que permitem que um ator malicioso execute o código de sua escolha em uma máquina remota sobre uma LAN, Wan ou a Internet.

Também sabemos que o método funciona na versão Windows e Mac do Zoom, mas não afeta a versão do navegador. Não está claro se os sistemas operacionais iOS- e Android são vulneráveis, já que Keuper e Alkemade não estavam analisando essa questão.

A organização Pwn2own twittou um gif demonstrando a vulnerabilidade em ação. Pode-se ver o atacante abrir a calculadora no sistema rodando o Zoom. Calc.exe é o executável que hackers usam frequentemente como prova-de-conceito para mostrar que eles podem executar códigos arbitrários em uma máquina afetada.