É realmente impossível dizer o que uma CPU está fazendo? [fechadas]

24

Os programadores de computador costumam recitar o mantra de que as instruções x86 são totalmente opacas: a Intel nos diz que estão fazendo alguma coisa, mas não há esperança de que alguém possa verificar o que está acontecendo; portanto, se a NSA lhes disser para backdoor seus RNGs, não podemos realmente faça qualquer coisa sobre isso.

Bem, acredito que programadores de computador não podem fazer nada sobre esse problema. Mas como um engenheiro elétrico o atacaria? Existem técnicas que um engenheiro elétrico poderia usar para verificar se um circuito realmente executa as operações descritas em suas especificações e nenhuma outra operação?

cpu reverse-engineering user14717
fonte
5
Você teria que fazer algo como tirar o raio X do dado e analisar tudo para ver o que está realmente fazendo. Basicamente, faça a engenharia reversa do chip e explique a função de cada circuito. Totalmente impraticável.
DKNguyen
7
Nenhum circuito elétrico é executado com uma especificação exata devido ao ruído e à pequena possibilidade de que um dia haverá uma falha "grande o suficiente".
Andy aka
5
Informações divertidas: isso está vagamente relacionado ao demônio de Laplace .
Harry Svensson
6
Vai ser mais fácil roubar documentos internos do banco de dados de conteúdo da Intel do que seria fazer engenharia reversa até mesmo uma única CPU Intel moderna e complexa.
forest
14
@Herper sua atitude é pouco construtiva, e sua afirmação de que um backdoor não pode ser oculto em hardware não é verdadeira.
pjc50

Respostas:

14

O melhor artigo que li sobre o assunto é "Trojan de hardware furtivo em nível de dopante" (Becker et al) de 2014.

Como o circuito modificado parece legítimo em todas as camadas de fiação (incluindo todo o metal e polissilício), nossa família de cavalos de Tróia é resistente à maioria das técnicas de detecção, incluindo inspeção ótica de grãos finos e verificação de "lascas de ouro". Demonstramos a eficácia de nossa abordagem inserindo Trojans em dois designs - um pós-processamento digital derivado do design RNG criptograficamente seguro da Intel usado nos processadores Ivy Bridge e uma implementação SBox resistente a canal lateral - e explorando sua detectabilidade e seus efeitos na segurança.

O documento descreve como a alteração é feita, como é extremamente difícil detectar a inspeção do silício, técnicas para ocultá-lo do teste de produção e como pode ser feito para reduzir a segurança de uma criptografia de hardware RNG ou para vazar informações importantes através de um canal lateral do trilho de força de uma implementação do AES.

Canais laterais são um campo de interesse emergente. A Intel foi atormentada por problemas relacionados à execução especulativa que vazavam informações da memória que nem estavam sendo usadas pelo programa. Isso poderia ter sido uma falha de design deliberada? É quase impossível dizer.

pjc50
fonte
Um canal lateral não exigiria algum tipo de transmissor para enviar as informações à NSA? Caso contrário, certamente notaria alguém medindo a corrente do trilho de energia no meu laptop enquanto estou trabalhando nele.
Dmitry Grigoryev
24

Existem técnicas que um engenheiro elétrico poderia usar para verificar se um circuito realmente executa as operações descritas em suas especificações e nenhuma outra operação?

Em teoria, sim, acho que isso é possível. No entanto, para uma CPU complexa, será necessário muito tempo e dinheiro. Além disso, se você não conhecer e entender completamente o design, não poderá julgar se alguma atividade é "legítima" ou não.

Uma CPU é "apenas" um circuito digital complexo que consiste em muitas células lógicas.

É possível fazer engenharia reversa do chip e reconstruir o projeto observando as conexões de metal. Pode haver muitas dessas camadas de conexão, como até 8 camadas ou mais.

Você precisará de especialistas na área para reconhecer as células lógicas e, talvez, algum software possa descobrir como elas estão conectadas, para que você possa reconstruir a netlist.

Depois de ter a netlist, você "conhece" o design. Isso não significa que agora você também sabe como funciona!

Pode ser que uma determinada função ative 2 seções do design enquanto você acha que uma deve ser suficiente, para que você suspeite de alguma atividade suspeita. No entanto, o design faz alguns truques inteligentes que você não conhece para acelerar as operações.

Sem conhecer e entender o design, qualquer conclusão que você tire ainda pode estar errada. Somente os engenheiros que projetaram a CPU têm todas as informações de projeto e têm a melhor chance de descobrir ou adivinhar o que realmente acontece ou deveria acontecer em uma CPU.

Bimpelrekkie
fonte
77
Somente os engenheiros que projetaram a CPU sabem tudo o que acontece - sou um engenheiro que trabalha neste setor e deixo-me avaliar esta afirmação como muito otimista :)
Eugene Sh.
18
Não, os projetistas de CPU não saberiam tudo o que acontece - o design nesse nível depende de ferramentas de síntese, e eles poderiam injetar um comportamento além daquele no design do HDL. Para dar um exemplo não nefasto, muitas ferramentas FPGA permitem compilar em um analisador lógico.
Chris Stratton
9
A engenharia reversa de um chip com "bilhões de transistores" seria um desafio. spectrum.ieee.org/semiconductors/processors/…
Voltage Spike
4
@ Wilson Porque os circuitos complexos (incluindo CPUs) conterão muitos projetos proprietários (e secretos, com marca registrada / patenteada) que não são disponibilizados ao público em geral porque as empresas que possuem esses projetos desejam se beneficiar (ganhar dinheiro) com eles. O 6502 é um design antigo , não possui mais informações valiosas sobre o design; portanto, é totalmente aberto e disponível para todos.
Bimpelrekkie
3
@Bimpelrekkie: Se são patenteados, por definição não são secretos. Esse é o objetivo de uma patente. Você troca um segredo por um monopólio temporário.
MSalters
9

Bem, acredito que programadores de computador não podem fazer nada sobre esse problema. Mas como um engenheiro elétrico o atacaria?

Não há boas maneiras de encontrar portas traseiras, uma maneira de encontrar uma porta traseira de hardware seria testar combinações ou instruções não documentadas. Aqui está uma boa conversa sobre alguém que realmente faz isso e faz auditorias no hardware x86 . Isso pode ser feito sem quebrar o chip. Um problema com a intel (não tenho certeza sobre outros chips) é que, na verdade, ele possui um processador com o Linux sendo executado, então também há software sendo executado em alguns processadores e você não tem acesso a isso supostamente.

Existem técnicas que um engenheiro elétrico poderia usar para verificar se um circuito realmente executa as operações descritas em suas especificações e nenhuma outra operação?

Existem maneiras de testar o uso do próprio hardware para testar a funcionalidade. Como o x86 possui uma parte não documentada de seu conjunto de instruções, seria incomum introduzir backdoors em instruções normais, porque isso apresentaria a possibilidade de erros (como se você tivesse um backdoor em uma instrução add ou mult), portanto, o primeiro lugar para procurar estaria nas instruções não documentadas.

Se você precisou testar a funcionalidade das instruções regulares, pode observar o tempo necessário para executar as instruções, observe a quantidade de energia necessária para executar as instruções para verificar se existem diferenças em relação ao que você esperaria.

Voltage Spike
fonte
3
Eu discordo, não é impossível que alguém faça isso, mas improvável. digamos que você backdoored uma instrução regular como uma instrução add e, se você executou uma instrução adicional, digamos que ela abriu uma backdoor. Em seguida, um cliente desenvolve um programa que possui exatamente essa combinação, ele procura, encontra a porta dos fundos e todo mundo fica bravo e você é processado. Muito mais seguro colocar um backdoor nas instruções não documentadas (ou no computador Linux embutido nas CPUs)
Voltage Spike
4
O IME executa o Minix, que não é Linux e é muito menor e mais simples. O Linux foi inspirado pela existência do Minix e originalmente usou seu sistema de arquivos e foi anunciado em seu grupo de notícias, mas eles eram bem diferentes na época e são extremamente agora.
Chris Stratton
5
@ user14717 - a possibilidade desagradável seria uma sequência de disparos em um executável nativo preso, algo como cliente nativo. Mas não há razão para ter que ser código e não dados .
Chris Stratton
5
@ laptop2d Erros em que as CPUs não fazem o que a documentação teórica do conjunto de instruções diz que acontece o tempo todo ; normalmente, ninguém é processado: leia a seção de erratas na atualização de documentos da família Intel i7 de 7a geração Core i7, por exemplo. Usar uma instrução não documentada soaria imediatamente o alarme de qualquer pesquisador de malware. O uso de uma combinação incomum de ADDs rítmicos com os MOVs entre registros corretos tem menos probabilidade de disparar qualquer alarme.
Marcus Müller
6
@ laptop2d Fiquei impressionado com a declaração "linux incorporado na CPU". Então eu fiz um pouco de pesquisa, acho que você fala sobre o mecanismo Intel ME. Bem, ele não roda na própria CPU, mas no chipset da ponte norte. Parece que houve muita desinformação sobre isso, consulte itsfoss.com/fact-intel-minix-case
dim
6

A única maneira seria desmontar a camada de chip por camada e registrar todos os transistores com um microscópio eletrônico, inseri-lo em algum tipo de programa de simulação e depois vê-lo funcionar.

Este é essencialmente o problema da Caixa Preta, no qual você tenta reconstruir os internos a partir da medição de entradas e saídas. Uma vez que a complexidade dos internos, ou número de E / S, ultrapassa o trivial, ocorre uma explosão combinatória em que o número de possíveis estados internos se torna astronômico. Onde números como o Googol são divulgados .

Dirk Bruere
fonte
2
... e é mais fácil roubar o design usando engenharia social :)
Eugene Sh.
8
Não. O erro gritante aqui é que a simulação não seria suficiente. Mesmo que você recebesse um modelo de simulação preciso , ainda não seria capaz de encontrar um comportamento cuidadosamente oculto, porque não tem idéia de como ativá- lo.
Chris Stratton
4
@ ChrisStratton Eu não chamaria esse erro gritante . É uma suposição razoável de que o design tenha sido baseado em simplificações fisicamente usuais, por exemplo, que você não coloque dois traços de metalização tão próximos que eles sejam acoplados indutivamente o suficiente para alterar o estado de uma porta MOSFET. Isso é apenas um erro se: a) suas simplificações não correspondem ao modelo físico do que o designer usou ou b) o designer está ocultando algo intencionalmente, quebrando intencionalmente os requisitos para essas simplificações de maneiras não óbvias.
Marcus Müller
7
@ ChrisStratton ah, desculpe, ok, acho que agora estou entendendo o seu ponto. Você diz que mesmo os modelos com clock digital / comportamental de uma CPU são complexos o suficiente para ocultar casos em que o entendimento / suposições do programador simplesmente não se aplicam. Isso é verdade. Alguém poderia ter documentado os efeitos que levam ao SPECTER em detalhes excruciantes, e a maioria das pessoas nunca pensaria em cache para ter efeitos colaterais relevantes para o fluxo de dados ou programas. De fato!
Marcus Müller
3
Obrigado :) Seu argumento traz de volta o tópico inteiro da verificação formal da correção dos ISAs ("este ISA realmente garante que uma CPU compatível não conceda privilégios RING 0 ao código não privilegiado?") E da verificação formal do HDL / RTL contra essas especificações ISA (eu gosto especialmente deste projeto de verificação do núcleo de CPU RISC-V .)
Marcus Müller
5

Provar que a CPU não está fazendo algo furtivo é extraordinariamente difícil. O exemplo clássico é uma máquina de votação. Se houver um único pedaço que exija uma cópia do seu voto e depois o esclareça para algum ditador, pode ser vida ou morte para você em alguns lugares. E provar que não há nada disso entre os bilhões é bastante difícil.

Você pode pensar em isolar o chip fisicamente, por isso é prático verificar que não há conexões de fio impróprias para ele. E colocar outro chip, ou mais de um chip em série (de fontes diferentes) em sua conexão de rede que garante que ele se conecte apenas ao lugar certo. Depois, desligue e ligue novamente após o seu voto. E esperando que não haja bits não voláteis lá. Ou conexões sem fio sorrateiras. Mas você confiaria sua vida nisso?

emrys57
fonte
5

A transmissão de todos os dados para a NSA exigirá acesso à rede, por isso será muito fácil identificar esse backdoor executando um sistema operacional com os serviços de rede desativados e verificando o tráfego nas interfaces de rede. Para um sistema operacional de código-fonte aberto, é possível executar com suporte total à rede e localizar conexões não autorizadas pelo IP de destino, que não corresponde a nenhum endereço que o sistema operacional possa acessar legitimamente.

Um backdoor baseado em RNG sem transmissão de dados terá utilidade muito limitada. A menos que o RNG da CPU seja a única fonte de entropia, as chances de que esse backdoor forneçam alguma vantagem ao invasor, embora não sejam óbvias ao mesmo tempo, são praticamente nulas . A menos que você insista que o bule de chá de Russel esteja lá fora, apesar de não haver boas razões para existir, você poderá aplicar o mesmo argumento às backdoors de RNG de hardware.

Dmitry Grigoryev
fonte
5
Então você assume que o adversário tem tempo, dinheiro e habilidade para criar e ocultar um cavalo de troia de hardware, mas a primeira coisa que ele faz é telnet www.nsa.gov? Este parece ser um ponto de vista muito ingênuo.
Elliot Alderson
11
Se a NSA tivesse escondido uma vulnerabilidade, sim, eles esperariam que as pessoas usassem rdrandou rdseedcomo a Intel sugeriu: como a única fonte de entropia para uma semente PRNG. Linux (kernel) optou por não fazer isso para /dev/random, mas glibc / libstdc ++ 's atual std::random_device faz uso apenas rdrandse estiver disponível em tempo de execução em vez de abrir /dev/random. Entre na chamada da biblioteca padrão com godbolt
Peter Cordes
@ ElliotAlderson Qual é o seu ponto de vista, então? Como alguém pode roubar dados valiosos sem nunca transmiti-los em algum lugar?
Dmitry Grigoryev
O @PeterCordes std::random_devicenão é um RNG criptograficamente forte. O padrão C ++ permite implementá-lo com um PRNG, retornando efetivamente a mesma sequência todas as vezes , portanto é óbvio que ninguém deve usá-lo para criptografia.
Dmitry Grigoryev
Ah, claro, esqueci que não há garantia de que seja bom, xD. Ele é bom em muitas implementações, mas MinGW é a exceção destaque para a intenção do projeto que lhe dá como números aleatórios de boa qualidade como a plataforma é capaz de, derrotando o objetivo principal da biblioteca. (O que, como você diz, não é criptográfico, mas semeia PRNGs para outros fins). ( Por que obtenho a mesma sequência para cada execução com std :: random_device com mingw gcc4.8.1? ). Isso seria aceitável em uma plataforma sem entropia (dispositivo incorporado mínimo), mas não no Windows x86!
Peter Cordes