Como atender (e superar!) os requisitos da norma IEEE 1735

No mês passado, recebi um e-mail de recrutamento de alguém que alegava ser um Recrutador Sênior da Workday.

Refinado. Personalizado. Sem erros de digitação. Meu primeiro nome no assunto, passando por todos os filtros de e-mail.

Eu não respondi. Verifiquei o domínio do remetente: `hiring-workday.co`.

Não `workday.comOs registros DNS mostraram o roteamento de e-mail através deemx.mail.ruOs cabeçalhos SMTP brutos confirmaram a origem em `send35.i.mail.ru [89.221.237.130]`, um servidor de retransmissão russo, às 1h23 da manhã, horário de Moscou. Seletor DKIM: `mailru`. Política DMARC: `p=NONE`. Proxy Cloudflare, TTL zero em todos os registros. Infraestrutura criada especificamente para entregar e desaparecer.

O texto provavelmente foi gerado por IA. Eu sei disso porque um recrutador que realmente lesse meu perfil teria citado algo dele. Em vez disso, quatro dados do LinkedIn — nome, cargo, setor e localização — foram inseridos em um modelo de texto e aplicados simultaneamente a milhares de candidatos. A personalização é a superfície de ataque. A infraestrutura é a pista.

Com muita frequência, os sistemas não são projetados pensando no atacante real. O perfil do LinkedIn foi criado para ser lido por um recrutador humano realizando contato manual. Agora, os atacantes executam fluxos de trabalho automatizados em larga escala, usando IA para converter dados públicos em confiança armada. Essa discrepância entre o atacante que o sistema pressupõe e o atacante que de fato explora a vulnerabilidade não é exclusiva das plataformas sociais. É o modo de falha característico dos sistemas de segurança em diversos setores.

Isso me fez pensar no precedente estabelecido pela norma IEEE P1735 – Recommended Practice for Encryption and Management of Electronic Design Intellectual Property – uma norma desenvolvida para proteger a propriedade intelectual de projetos de hardware, como o código HDL para Verilog/VHDL na cadeia de suprimentos de semicondutores.

Em 2017, Chotaray, Nahiyan, Shrimpton, Forte e Tehranpoor publicaram "Standardizing Bad Cryptographic Practice", desmantelando a norma IEEE 1735-2014. Um artigo de 2021, de autoria de Speith, Schweins, Ender, Fyrbiack, May e Paar, demonstrou a recuperação completa de chaves privadas a partir de implementações de produção na Intel, Cadence, Siemens, Lattice e outras empresas.

O padrão utilizado foi AES-CBC com transporte de chave RSA. A criptografia não era o elo fraco, mas sim o modelo de ameaça. A norma P1735 designou a ferramenta EDA como confiável. Ela modelou o adversário como um usuário IP passivo tentando ler um arquivo protegido em repouso. Não modelou um adversário que controlasse o ambiente de execução, capaz de fornecer à ferramenta entradas de texto cifrado manipuladas e ler sistematicamente suas saídas de erro.

Como o padrão exigia AES-CBC sem autenticação no bloco de dados e incentivava explicitamente as ferramentas EDA a retornarem erros de sintaxe descritivos durante o processamento, a própria ferramenta tornou-se o oráculo da descriptografia. A própria orientação de usabilidade do padrão, que afirmava que "mensagens de erro de qualidade refletem a qualidade da propriedade intelectual protegida", foi o vetor de ataque. (Observe que as recomendações não consideravam a CWE 209 – Exposição de Informações por meio de uma Mensagem de Erro). O artigo de 2021 foi além: encontrou esquemas de criptografia white-box baseados em RSA já implementados em ferramentas EDA, evidenciando que a indústria havia reconhecido independentemente a ameaça Man-At-The-End (MATE) e adotado o WBC como solução, porém sem a camada de integridade em tempo de execução necessária para proteger a implementação contra um atacante já presente no ambiente de execução.

A conclusão dos pesquisadores foi inequívoca: as fragilidades do padrão IEEE 1735 não podem ser corrigidas apenas com soluções criptográficas, dado o processo de projeto de hardware atual. Qualquer proteção que assuma o contrário falha justamente na fronteira que não modelou.

O e-mail de recrutamento de IA e a norma IEEE 1735 compartilham uma causa raiz: a proteção foi avaliada contra o atacante errado no ambiente errado. A norma IEEE 1735 pressupunha um leitor passivo, mas o atacante real manipulou o ambiente de execução. 

 Os perfis do LinkedIn pressupõem um leitor humano realizando contato manual, mas o atacante real executa um fluxo automatizado: extrair, classificar, gerar e distribuir em escala. O LLM é a ferramenta EDA, a caixa de entrada humana é o oráculo e o texto simples extraído é a fonte de confiança, não o HDL.

Este é o modo de falha predominante nas aquisições de segurança de aplicativos atualmente.

O que isso significa para a seleção de soluções de segurança?

Ao avaliar produtos de segurança para software de distribuição pública, os desenvolvedores verificam a abrangência da conformidade, a complexidade da integração e a sobrecarga de desempenho. As perguntas que geralmente são ignoradas são as seguintes:  
(1) O que essa proteção pressupõe que o atacante não possa fazer, e  
(2) As suposições ainda são válidas quando o atacante possui ferramentas assistidas por IA, acesso total ao ambiente de execução e orçamento de consulta ilimitado? 
 
Uma arquitetura de proteção que não leva em consideração o modelo de ameaça correto, ou seja, o ataque Man-At-The-End ou Man-In-The-Client, onde o atacante controla o dispositivo o software funciona colocando-os na mesma posição que IEEE 1735. A criptografia pode ser som. A suposição de limite não é válida. Um atacante que já esteja dentro do ambiente de execução não interage com o Formulário on lineA forma como a proteção foi concebida leva a expectativas e, geralmente, a problemas graves.  
 
A resposta para a qual a indústria de semicondutores convergiu, no entanto, foi a criptografia de caixa branca para proteger chaves dentro de um ambiente de execução hostil, combinada com verificação de integridade em tempo de execução para detectar e responder à instrumentação ativa. Esta é a mesma arquitetura que pertence at a camada de aplicativos móveis. Não como uma mera formalidade para cumprir requisitos. Como uma resposta direta a uma ameaça. modelo O padrão não foi atingido. 
 
Em 1993, Ross Anderson argumentou em "Por que os criptossistemas falham"" que as falhas de segurança raramente são criptográficas. Ele demonstraram que a matemática se mantém, mas o modelo de ameaça e As suposições sobre o atacante, seu acesso e seu ambiente falham. A carreira de Anderson mostrou que essas suposições levam a sistemas tecnicamente compatíveis, mas operacionalmente falhos. IEEE O projeto 1735 e o sistema de recrutamento com IA direcionado a perfis do LinkedIn são exemplos disso. 
 
Antes de aprovar uma solução de segurança para qualquer aplicação distribuída publicamente, faça uma pergunta: Existem proteções de software que considerem tudo o que o atacante não pode fazer? 
 
Se a resposta não for registrada por escrito, o modelo de ameaças não foi realizado. 
 
Se yoVocê gostaria de discutir o seu IEEE 1735 ou outras criptomoedas de caixa brancanecessidades gráficas com umtrês, Contate-Nos aqui.: https://digital.ai/why-digital-ai/contact/

Referências

Anderson, RJ (1994). Por que os criptossistemas falham  
https://doi.org/10.1145/188280.188291 
 
Chhotaray et al., “Padronizando as Más Práticas Criptográficas” https://doi.org/10.1145/3133956.3134040 
 
Spiith e outros, “Como NÃO proteger sua propriedade intelectual”  
https://doi.org/10.1109/SP46214.2022.9833605 
 
https://cwe.mitre.org/data/definitions/209.html