IBM, Intel, AMD seguem caminhos diferentes para criptografia baseada em hardware

Temos criptografia para dados em movimento. Temos criptografia para dados em repouso. Mas um tipo de dado é difícil de manter criptografado – dados que estão sendo usados. Para que um aplicativo faça algo com os dados, como verificar se há erros de ortografia em um documento, ele deve ser capaz de ver os dados.

As soluções baseadas em software incluem metodologias como tokenização e preservação de formato, homomórfico (que permite operações matemáticas) e criptografia multipartidária. Elas são lentas, complicadas e não funcionam para todos os casos de uso.

O que funciona são as proteções baseadas em hardware. Os smartphones já as usam – enclaves seguros que permitem o processamento de dados de identidade e pagamento de uma forma que não é visível para o resto do dispositivo.

Em servidores corporativos, isso é chamado de computação confidencial e dois tipos principais dessa tecnologia estão em uso. O mais conhecido é o SGX da Intel, um enclave seguro dentro dos chips Intel que protege aplicativos e dados durante o uso. Esses enclaves são relativamente pequenos e os aplicativos geralmente devem ser reinicializados ou reescritos para tirar proveito deles. Ao mantê-lo pequeno, no entanto, o risco potencial devido a falhas na lógica do aplicativo também é minimizado.

A outra abordagem é usada pela IBM nos chips S390 em seus mainframes Z System e servidores LinuxOne, e pela AMD em seus chips EPYC. Aqui, o enclave protegido é um pouco maior e pode conter não apenas um aplicativo, mas toda a máquina virtual em que está. Isso significa que os aplicativos não precisam ser reprojetados ou reescritos para funcionar dentro do enclave.

Os provedores de nuvem estão começando a embarcar. Embora a Amazon ainda não tenha lançado uma solução baseada em hardware, a Microsoft optou por usar Intel SGX e Google Cloud com AMD Epyc.

IBM S390 escolhido para as mais altas necessidades de segurança

A confidential computing ou computação confidencial ainda é relativamente nova e os primeiros a adotar tendem a ser empresas de serviços financeiros e outras empresas com altos requisitos de segurança. Considere, por exemplo, a Hex Trust, uma empresa com sede em Hong Kong que oferece custódia de banco para ativos digitais como criptomoedas. “Precisamos da mesma infraestrutura nos mercados de criptografia que temos hoje nos mercados financeiros”, disse Rafal Czerniawski, CTO da Hex Trust. Czerniawski trabalhou anteriormente na indústria de serviços financeiros.

O espaço da criptomoeda foi assolado por uma onda de violações e perdas embaraçosas e de alto nível nos últimos anos. “Se as grandes instituições vão adotá-lo, precisaremos da mesma infraestrutura, especialmente sob custódia”, diz Czerniawski. “Mas você ouve histórias o tempo todo sobre pessoas perdendo suas chaves, ou desaparecendo com as chaves, ou fingindo sua própria morte”.

Não é suficiente apenas descobrir como armazenar com segurança algumas chaves de criptografia, diz Czerniawski. Na empresa, em grandes ambientes institucionais, os clientes podem ter centenas ou milhares de ativos e diferentes blockchains. Mesmo que um aplicativo de gerenciamento de chaves tenha sido reescrito para caber em um enclave Intel SGX, isso não oferece a capacidade de infraestrutura para gerenciar as chaves. “Como você escala isso?”, ele adiciona. “Como você tem muitos serviços em execução simultaneamente usando as mesmas chaves? Se minha máquina cair, como faço para retomar o processamento em outro servidor? Precisamos executar o processamento de transações em escala”.

Existem também camadas de autenticação criptográfica e políticas de segurança criptograficamente aplicadas, como listas brancas de endereços de onde as transações podem ser enviadas. “Executar tudo isso dentro do enclave seguro nos dá muita flexibilidade”, diz Czerniawski.

A IBM opera em grande escala, diz Czerniawski. Além disso, a tecnologia está disponível no local e na nuvem. “Talvez inicialmente nossos clientes queiram começar pequenos, com uma prova de conceito na nuvem da IBM”, diz ele. “À medida que seus negócios crescem e a exposição ao risco aumenta, eles podem fazer a transição para uma solução local. Isso dá bastante flexibilidade aos nossos clientes”.

O enclave seguro do IBM Z pode ter até 16 terabytes de tamanho. “Você não precisa escolher quais partes de nossa carga de trabalho deseja proteger”, diz Rebecca Gott, Engenheira do IBM Z e LinuxOne, e a pessoa que lidera o desenvolvimento de blockchain e Z-as-a-service por meio da IBM Cloud. “Você pode proteger tudo de uma vez”. Nenhuma mudança de código é necessária, ela acrescenta.

A maneira como a tecnologia funciona é que cada enclave seguro tem seu próprio conjunto de chaves de criptografia usadas para criptografar as comunicações dentro ou fora do enclave. O cliente corporativo envia o aplicativo, empacotado dentro de uma máquina virtual, junto com seus dados criptografados e as chaves usadas para desbloqueá-lo, para o enclave, por meio de um canal criptografado seguro.

O aplicativo faz seu trabalho dentro do enclave, protegido dos olhos curiosos de qualquer outra pessoa, incluindo os próprios administradores de sistema do provedor de nuvem. “Essa é uma parte fundamental de nossa proposta de valor”, diz Gott. “Qualquer pessoa com credenciais de sistema elevadas – administradores de infraestrutura, administradores de hipervisor, administradores de nuvem, qualquer um desses jogadores – não pode ver os dados ou software do usuário”.

O envio de uma máquina virtual inteira cria exposição adicional, e a IBM trata disso, fazendo com que cada enclave passe por um processo de inicialização seguro para garantir que a imagem inicial não seja adulterada e que as chaves de criptografia do enclave sejam estabelecidas no momento da fabricação para cada máquina. “O material da chave raiz nunca sai do módulo de segurança de hardware”, diz Gott. “A arquitetura subjacente tem a mais alta certificação de segurança federal disponível para um processador comercial. Isso significa que se houver qualquer violação física no dispositivo, a violação é detectada e o material da raiz é zerado em 100 nanosegundos”.

Então, para garantir que a máquina virtual e o aplicativo não sejam comprometidos, há um processo em vigor para clientes corporativos carregarem seu código em um repositório GitHub privado onde ele pode ser verificado e assinado, diz Gott. “Portanto, você pode ter certeza de que não há adulteração em qualquer lugar do pipeline. Você conhece a proveniência do código e tem uma trilha de auditoria completa e proteções ao longo de todo o processo”.

A computação confidencial baseada em hardware do IBM Z está no mercado há mais tempo, diz Charles King, Analista Principal da Pund-IT – tendo sido apresentada pela primeira vez em 2016 -, e oferece um nível de desempenho superior aos concorrentes. Como outras tecnologias de mainframe Z, diz ele, os enclaves seguros “são claramente projetados para atender às necessidades de segurança mais rigorosas dos grandes clientes corporativos da empresa”.

AMD visa computação segura na nuvem

Como a abordagem da IBM, a AMD permite que os usuários coloquem uma máquina virtual inteira dentro do enclave seguro. A AMD visa o mercado de nuvem pública com seus chips EPYC, diz King.

Isso o torna atraente para empresas nativas da nuvem, como a francesa iExec, que fornece a infraestrutura para permitir que as empresas executem aplicativos blockchain baseados em nuvem. “Alugamos espaço do Google Cloud, reempacotamos como blockchain e off-blockchain e o alugamos para empresas”, disse Lei Zhang, Chefe de Segurança da iExec,

O Google Cloud foi o primeiro provedor de nuvem pública a oferecer computação confidencial baseada em AMD EPYC como uma versão beta pública em meados de julho. Por exemplo, um dos clientes da iExec é um hospital que deseja compartilhar seus dados médicos com empresas de pesquisa. “Os dados médicos são de alta sensibilidade, por isso precisamos garantir a privacidade e a propriedade dos dados”, diz Zhang. Outro cliente está usando a plataforma de renderização 3D para filmes. “Você não quer que uma cena vaze”, diz ele.

O enclave seguro AMD EPYC é grande o suficiente para que todo o processo de renderização possa ser executado dentro dele. As redes blockchain são uma forma confiável de lidar com dados e alguns outros casos de uso, diz Zhang. “Contratos inteligentes e alguma lógica de negócios são executados diretamente no blockchain, mas há um problema com escalabilidade”.

É aí que entram os enclaves seguros. “Você não pode executar algoritmos sofisticados como IA diretamente em redes blockchain”, diz Zhang. “É caro e não é eficiente. É por isso que queremos descarregar esses aplicativos para redes off-blockchain, mas devemos garantir um nível semelhante de confiança”.

A computação confidencial permite que a empresa faça exatamente isso, diz Zhang. “Mesmo os administradores do serviço Google Cloud não podem penetrar nesta máquina virtual segura para inspecionar meus dados”. Intel SGX não seria capaz de executar uma máquina virtual completa, diz ele. “Foi desenvolvido para preservar microsserviços, cargas de trabalho altamente sensíveis, mas pequenas. A tecnologia AMD foi projetada para serviços de infraestrutura em nuvem”.

Tal como acontece com a plataforma IBM Z, os aplicativos podem ser executados como estão, acrescenta Zhang. “Você não precisa modificar o código-fonte. Se você desenvolve aplicativos SGX baseados no Intel SDK, é necessário fazer muitas modificações no código do aplicativo. É extremamente doloroso”.

O enclave seguro do Google Cloud não é tão grande quanto o da IBM, até 896 gigabytes. Mas, como com a IBM, o enclave tem suas próprias chaves de criptografia, geradas por uma combinação de hardware e software, que permite que clientes corporativos enviem suas cargas de trabalho para o enclave.

“Os clientes podem mantê-los criptografados usando suas próprias chaves ou usar a tecnologia HSM [módulo de segurança de hardware] em nuvem para criptografar os dados quando eles os trazem para a nuvem”, disse Nelly Porter, Gerente de Produto Sênior do Google Cloud. “O aplicativo – isso é muito importante para nós – não precisa ser alterado.”

O Google havia tentado usar enclaves seguros Intel SGX e procurado maneiras de tornar o processo mais fácil para os clientes, mas no final forçar as empresas a rearquitetar seus aplicativos era muito complicado. O código-fonte pode não estar disponível e, mesmo com o código-fonte aberto, pode haver dependências ou outros motivos pelos quais o aplicativo não pode ser alterado.

Em vez disso, com a abordagem da AMD, apenas o código do hipervisor precisa ser alterado para funcionar com o enclave seguro. “Há apenas um punhado deles”, diz Greg Gibby, Gerente Sênior de Marketing de Produto para EPYC na Advanced Micro Devices. “Para Linux, para todas as principais distribuições, isso é feito, e o código foi atualizado e aceito pela comunidade”. Ele acrescenta que a VMware se comprometeu a habilitar essa tecnologia em seu próximo lançamento e que a AMD está trabalhando com outras empresas que possuem seus próprios hipervisores.

Permitir que hypervisors e máquinas virtuais acessem o enclave expande a superfície de ataque potencial. “Se você tivesse um hipervisor malicioso, existem maneiras possíveis de entrar na máquina virtual”, diz Gibby. Em um ambiente de produção, outras soluções de segurança impediriam que isso acontecesse, mas, atualmente, a própria plataforma da AMD não protege contra hipervisores maliciosos. As proteções estão no roteiro do EPYC, diz ele, “mas não queríamos esperar. Não queríamos deixar o perfeito ser inimigo do bom”.

Microsoft aposta em Intel SGX

Nem todos concordam com a abordagem da AMD. A Microsoft decidiu ir com o Intel SGX e seus enclaves menores. De acordo com Mark Russinovich, CTO da Microsoft Azure, os enclaves Intel SGX vão até 256 kilobytes – uma pequena fração do que o AMD EPYC ou o IBM Z podem oferecer.

O benefício para os clientes é que eles têm proteção total contra o acesso lógico e físico – as únicas coisas em seus enclaves são o que eles colocam. “Um cliente pode instalar software e processar dados sem depender de nada da Microsoft”, diz Russinovich. “Ele fornece níveis extremos de proteção e garantia”.

Enquanto o Intel SGX normalmente é executado em estações de trabalho menores, não em servidores de classe de datacenter de vários soquetes, a Microsoft trabalhou com a Intel para colocar o SGX em seus centros de nuvem com servidores de soquete único. “Não há dúvida de que é mais fácil se você pode iniciar uma máquina virtual inteira, mas isso cria uma enorme área de superfície que expõe você a ataques de canal lateral”, diz Russinovich.

A Microsoft olhou atentamente para a abordagem da AMD, “mas decidiu passar por causa de algumas das limitações”, disse Russinovich. Os clientes precisam escrever um código ciente de que está sendo executado dentro do Intel SGX, diz ele. “Mas estamos trabalhando em tecnologias, SDKs e ferramentas para tornar mais fácil colocar o software nesses enclaves”.

A Microsoft também está trabalhando com o Confidential Computing Consortium – AMD, Google, Intel, Red Hat e Oracle também são membros – e contribuiu com o Open Enclave SDK, que abstrai as diferenças entre ambientes de computação confiáveis. O banco de dados SQL suporta Intel SGX, acrescenta ele, portanto, se um aplicativo usa SQL para seu trabalho mais sensível, o resto do aplicativo não precisa ser reescrito para aproveitar as vantagens do enclave.

Steve Riley, Analista do Gartner, confirma que a Intel SGX exige que o código seja reescrito, e o EPYC da AMD não. Os bancos de dados SQL do Azure podem colocar informações em enclaves sem modificação, diz ele, “mas qualquer outro aplicativo executado em instâncias de computação comuns exigirá modificação”.

O framework Open Enclave da Microsoft não é o único que está tentando resolver esse problema, diz Riley. O Google tem sua própria abordagem, chamada Asylo. “Nenhum é um padrão declarado”, diz ele, “e é improvável que algum venha a surgir como um padrão de fato”.