Os TPM são a raiz de toda a segurança. Sem TPM = Sem Segurança

 

Introdução

Todos concordam que os ATM devem ter a máxima segurança possível sem prejudicar a sua facilidade de utilização. No entanto, já parece haver menos consenso quanto à forma como isto pode ser conseguido. É claro que alguma dessa confusão surge devido à concorrência entre os fornecedores, com diferentes produtos de segurança que competem pela atenção do cliente. Mas há também bastante desinformação que confunde os clientes e, em última análise, leva a más implementações que são vulneráveis a ataques.

Este livro branco reunirá importantes fundamentos de segurança do sistema, começando pela linha de base de como os sistemas informáticos individuais devem ser protegidos e abordando em seguida o caso exclusivo da utilização de redes ATM que, obviamente, requerem o mais alto nível de proteção. As redes de ATM não só são responsáveis por milhões de dólares em numerário, como também são um ponto de entrada potencial para os sistemas informáticos anfitriões de um banco que podem transferir grandes quantidades de dinheiro em todo o mundo. Um ATM comprometido pode ser mais caro para um banco do que simplesmente o dinheiro que está dentro do seu cofre.

Em primeiro lugar, vejamos alguns conceitos vulgarmente incorretos sobre segurança. Talvez o maior equívoco em matéria de segurança do sistema é um mau entendimento do conceito de segurança por camadas. É verdade que não existe uma única solução cabal para proteger um sistema complexo – são necessárias múltiplas fechaduras coordenadas. No entanto, este conceito é muitas vezes mal compreendido, causando a ideia de que quanto mais obscura e complexa for a segurança, mais seguro é o sistema. Este não é, simplesmente, o caso. Existem técnicas criptográficas fundamentais que podem ser simples, abertamente discutidas e bem compreendidas que devem formar o núcleo de qualquer arquitetura de segurança. Tais técnicas não só proporcionam segurança quantificável, como também são fáceis de utilizar e não dependem de contorcionismos dos utilizadores para as fazer funcionar.

Vamos ilustrar isto com um exemplo rápido. Estamos todos habituados a sistemas de PC que requerem um nome de utilizador e uma palavra-passe para se entrar no sistema. À medida que o sistema de segurança baseado numa palavra-passe foi sendo atacado por hackers, as organizações criaram regras de palavra-passe cada vez mais complicadas que são altamente hostis aos utilizadores legítimos – alterações regulares de palavra-passe, não utilização das últimas x palavras-passe, composições de palavras-passe complicadas e difíceis de lembrar, etc. Depois, a Microsoft cortou tudo isso com o “Windows Hello”.

O Windows Hello combina o reconhecimento de dispositivos de hardware criptográficos seguros por TPM com o reconhecimento facial biométrico. Isto é, de facto, muito semelhante a um conceito de segurança que o setor dos ATM compreende bem – um chip e um PIN. Com o Windows Hello, o chip é o TPM, que é um processador criptográfico semelhante ao chip de um cartão de pagamento, e a informação biométrica toma o lugar do PIN. Este sistema não só é mais seguro do que qualquer sistema de nome de utilizador + palavra-passe, como também é de utilização fabulosamente fácil. Não só posso entrar no meu tablet Surface bastando olhar para ele, como também o posso fazer num instante – muito mais rapidamente do que posso digitar uma única letra da minha palavra-passe. É possível que um sistema seja simultaneamente mais seguro e mais fácil de usar? Absolutamente. Temos de nos afastar da ideia de que não há ganho sem dor – a verdadeira segurança não requer tortura para o utilizador.

Deverá ter notado que introduzimos o conceito de TPM no parágrafo anterior. Este artigo é construído em torno dos TPM como a “raiz central da confiança” na computação. O TPM é um chip semicondutor seguro constituído por uma arquitetura de segurança que foi concebida pelo Trusted Computing Group (TCG) de mais de 100 empresas, incluindo grandes empresas como a Intel, Microsoft, HP e IBM. O seu trabalho começou ainda em 1999 com o objetivo de criar um núcleo seguro para dispositivos informáticos, para que toda a segurança informática pudesse ser construída a partir desse núcleo seguro. A boa notícia é que os TPM são em absoluto uma característica padrão em todos os novos dispositivos de PC e já o são há muitos anos. A má notícia é que muitas organizações nem sequer sabem que têm esta joia da segurança dentro dos seus dispositivos informáticos e não tiram partido dela. Este artigo é uma tentativa de mudar essa situação – especialmente para o nosso setor dos ATM. Afinal, precisamos mais de computação segura do que a maioria dos setores de atividade.

TPM – a “raiz fundamental da confiança”.

O que significa “raiz fundamental da confiança” e porque é que o TPM é fulcral para a segurança informática? Para compreender isto, é importante compreender que toda a segurança informática se baseia na utilização inteligente da encriptação. A encriptação é um método informático que converte dados de uma forma “não encriptada” numa forma aparentemente aleatória e vice-versa.

Quando os dados ou as informações estão na sua forma não encriptada, podem ser utilizados para um fim previsto. Quando os dados são encriptados, são inutilizáveis até serem desencriptados. O aspeto crucial a apreciar sobre a encriptação e a desencriptação é que é necessária uma “chave” segura para encriptar ou desencriptar dados. Sem a chave, os dados encriptados são inúteis. De facto, a palavra “chave”, neste sentido, não é diferente de uma chave para um cofre. Se a chave de um cofre se perder, não se pode aceder ao ouro que estiver dentro desse cofre. No caso da computação, o ouro são os dados que são protegidos pelo processo de encriptação.

Agora, o importante é compreender que a chave em si deve estar em forma não encriptada para que possa ser utilizada para decifrar uma mensagem. Isto significa que é necessário ter uma forma de armazenar a chave em segurança. Sim, é possível encriptar essa chave com outra chave. Isso tornaria a chave original segura – mas depois ter-se-á o problema de saber onde guardar a segunda chave. De facto, pode ter uma cadeia de chaves (e, muitas vezes, tal cadeia existe). Mas a chave inicial tem de ser armazenada num local seguro e de forma não encriptada. Onde se poderá armazenar uma chave-mestra não encriptada dentro de um computador? A resposta não está no disco rígido (ou SSD). É impossível armazenar uma chave não encriptada na unidade de forma segura – um hacker que possa ter acesso físico à unidade pode sempre encontrar essa chave não encriptada. Só o software não a pode proteger se um atacante tiver acesso físico a ela.

Aí entra o TPM. O TCG concebeu o TPM como um cofre de hardware para segredos, e está incorporado dentro da placa-mãe. Em algumas configurações, o TPM pode estar dentro do próprio chip da CPU. Foi concebido para o objetivo exato de armazenar chaves em segurança. É também muito mais do que um simples chaveiro – e já iremos ver isso na próxima secção. De momento, considere que um sistema informático pode ter uma cadeia de chaves, mas que a chave do início dessa cadeia tem de estar não encriptada e tem de ser armazenada com muita segurança para que só possa ser utilizada para fins de fiáveis. O TPM é esse chaveiro.

CRTM – a raiz nuclear da medição da confiança

Prometi que o TPM não seria apenas um chaveiro glorioso. Pensemos no primeiro problema que um chaveiro seguro irá enfrentar no seu primeiro dia de trabalho. Se alguém disser ao TPM: “Por favor, posso ter essa chave não encriptada?” como é que sabemos quem está a pedir a chave? Está muito bem guardar uma chave em segurança, mas a quem é que se vai dar essa chave? Será um código legítimo a pedir para usar a chave ou será algum malware? Será que um hacker modificou o software no PC com malware e depois disse-lhe muito educadamente: “Por favor, TPM, posso usar a chave?” Já está a ver o problema – não é suficiente ser apenas um chaveiro superseguro. É preciso autenticar o software que está a pedir para usar essas chaves. Agora entra em cena o segundo número de magia do TPM – a raiz nuclear da medição da confiança (CRTM).

A CRTM funciona com uma cadeia de confiança que começa no ato de ligar. O hardware e o TPM trabalham de mãos dadas para “medir” a sequência de arranque do PC desde o arranque inicial e depois para o BIOS/UEFI, e até ao arranque do Sistema Operativo. “Mede” se algum do software do PC foi modificado ou adulterado durante o processo de arranque. Este processo é mais conhecido como Secure Boot, que hoje em dia é uma característica padrão dos novos núcleos de PC que utilizam firmware UEFI para fazer arrancar o computador.

Para ajudar no Secure Boot, o desenho do TPM introduziu um conceito chamado PCR (Platform Configuration Registers). ). Os valores de PCR são calculados pelo TPM num processo chamado “extensão do PCR” de forma algo semelhante à criação de blocos em cadeia, daí resultando que os PCR tenham uma impressão digital única (ou seja, um conjunto de hashes) da sequência de arranque do PC. Se os PCR não forem modificados do passado, o software de arranque no PC está então inalterado – e isso é garantido criptograficamente. É impossível que o malware possa modificar um único byte do software de arranque medido sem afetar os valores do PCR

Este é um conceito extremamente importante em criptografia. O que é conhecido como a “função hash segura” é uma função semelhante à encriptação que converte um bloco de dados numa cadeia de caracteres de comprimento fixo que atua como uma impressão digital dos dados originais. Se os dados mudarem, a impressão digital muda. Esta é, portanto, uma forma segura de detetar até a mais leve modificação a um grande corpo de software. O TPM utiliza uma variante de hashing chamada HMAC. Um HMAC é um hash que se define como um “hash com chave”, o que significa que só alguém que tenha a chave segura certa será capaz de gerar ou verificar o hash HMAC. É uma espécie de “hash encriptado”.

Há uma razão pela qual analisámos esta parte com algum pormenor. Esta é a forma pela qual a tecnologia TPM garante que o software central no ATM é 100% seguro. Não há maneira de modificar sequer um único pedaço de software na sequência de arranque de um ATM protegido por um TPM sem quebrar a própria criptografia moderna. É também o conceito que depois alargamos neste artigo para assegurar tudo o resto do ATM.

Temos agora um núcleo de software seguro – e quanto ao software de aplicação?

Num ATM Windows 10, há duas tecnologias importantes da Microsoft que são preponderantes neste momento: o Bitlocker e o Device Guard (agora conhecido como Windows Defender Application Control – WDAC). O Bitlocker é a tecnologia de encriptação de unidades da Microsoft. É capaz de encriptar todo o disco rígido, ou SSD, e, mais importante ainda, guarda a sua chave de encriptação da unidade “no TPM”. Na verdade, é um pouco mais complicado do que simplesmente guardar a chave no TPM – vamos lançar um pouco de luz sobre isto.

Tenha em mente que não basta apenas guardar as chaves em segurança, é essencial saber “quem” está a pedir a chave antes de a entregar. O TPM tem outro novo truque que tem o nome de “selar” a chave. Quando a unidade de um ATM é encriptada pela primeira vez num ambiente seguro e uma nova chave é gerada pelo Windows, essa chave é então encriptada usando uma “chave da chave de encriptação” separada, chamada KEK (key-encription-key). A própria KEK é ainda mais encriptada num processo chamado “selagem” utilizando os valores PCR e uma chave privada do TPM. Quando o ATM arranca, a chave KEK só fica disponível se todas as impressões digitais do núcleo do software medidas pelos PCR tiverem sido validadas – o que significa que o BIOS e o código Windows não foram adulterados, como explicado anteriormente. Utilizando a KEK, o Windows desencripta a sua chave de encriptação da unidade e usa-a para desencriptar toda a unidade. Uma vez obtida a KEK, o Windows fecha a porta KEK atrás dela. Faz isto “estendendo” os PCR 11 – o que significa que os PCR 11 são modificados após a KEK ser desselada, para que mais ninguém possa posteriormente recuperar a KEK. A KEK é mantida segura pelo TPM até à próxima sequência de arranque e só é disponibilizada novamente se os PCR confirmarem que nenhum do software central foi adulterado e depois tranca novamente a porta assim que a KEK for disponibilizada ao Bitlocker para desencriptar a unidade.

Como se pode ver, construímos o software central passo a passo, verificando cada um desses passos e usando os PCR para assegurar que não ocorreu qualquer adulteração, até completarmos o processo de arranque e carregarmos o Windows. Precisamos agora de iniciar o software da aplicação do ATM e verificar se todos os executáveis que estamos a correr não foram adulterados antes de os utilizarmos. Por outras palavras, estendemos os mesmos conceitos de verificação da impressão digital criptográfica de cada componente do software antes de o utilizarmos. Esta parte final da cadeia de arranque é executada pelo Windows WDAC (ou por um software de terceiros com funcionalidade semelhante). Isto é frequentemente chamado de lista de permissões e resulta no hash (ou seja, a impressão digital computorizada) de cada executável a ser verificado antes de ser permitida a sua execução.

Lista de permissões no ATM

A melhor maneira de utilizar o software do ATM no modo de lista de permissões usando o Windows WDAC (ou outro software de modo de lista de permissões) é usar o que é conhecido como uma “regra de certificado”. Exige que o software que se implementa no ATM tenha sido previamente assinado pelo criador desse software. Assim, por exemplo, os executáveis do Windows 10 são assinados pela Microsoft com a sua chave privada. Isto significa que qualquer pessoa pode verificar que os executáveis do Windows não foram modificados ou adulterados em trânsito e que estão no mesmo estado em que estavam no momento em que foram assinados pela Microsoft, verificando-os simplesmente com a utilização da chave pública de assinatura de código da Microsoft. Para que o WDAC confirme isso, basta criar uma “regra de certificado” que diga que os executáveis assinados pela Microsoft são seguros de utilizar.

Da mesma forma, o software da KAL é sempre assinado pelo código da KAL que assina a chave privada. Os nossos clientes podem verificar que o software da KAL não foi adulterado instalando o certificado de assinatura de código KAL em cada ATM. Mas e quanto a outro software que possa não estar pré-sinalizado dessa forma? Há três opções em aberto para o banco:

1. Pedir ao seu fornecedor que assine o seu código.
2. Despedir o fornecedor. (Existem realmente fornecedores de ATM que não assinem o seu código no ano de 2020? Aparentemente, sim).
3. Usar uma “regra de hash”.

Uma regra de hash é uma regra que adiciona à sua política do modo de lista de permissões para o WDAC, segundo a qual o banco calcula um hash para cada um dos ficheiros que sejam de um fornecedor que não assinou os seus executáveis. Por outras palavras, é o utilizador que faz a assinatura do código por eles. Obviamente, isto não é tão bom como o código assinado na origem, pois qualquer adulteração que ocorra em trânsito entre o fornecedor e o banco não pode ser detetada (embora possam existir outros mecanismos para garantir uma transmissão segura).

Uma segunda desvantagem com a sua implementação desta forma é que o banco precisa de criar uma “regra de hash” para cada ficheiro executável. Isto é muito menos elegante do que simplesmente instalar o certificado público do fornecedor no ATM, que cobrirá então todos os executáveis desse fornecedor, incluindo todas as futuras atualizações do mesmo.

Já terminámos?

Quando chegarmos a este ponto e o ATM estiver a funcionar, todo o software foi verificado criptograficamente. Nenhum executável que tenha sido adulterado ou modificado de qualquer forma está autorizado a funcionar. Nem um único bit dos gigabytes que formam os executáveis de software num ATM moderno pode ser pirateado sem ser detetado e bloqueado.

No entanto, ainda não chegámos ao fim do caminho. Um ATM protegido desta forma é à prova de bala no que diz respeito à modificação não autorizada do seu conjunto de software. Mas isto não é o fim da história. Injetar malware no ATM não é o único método de ataque a um ATM. Vamos agora analisar como o TPM pode ajudar com outros tipos de ataque.

Compreender o que os TPM podem fazer

O TPM não tem apenas a ver com a segurança no processo de arranque de um ATM. É a raiz central de confiança que permite que tudo o resto seja também protegido. Vejamos um livro fabuloso escrito pelos membros do Trusted Computing Group, Will Arthur, David Challener e Kenneth Goldman. O livro “A practical guide to TPM 2.0” (Um guia prático do TPM 2.0) é notável e um tesouro de ideias que me inspirou a escrever este livro branco. O livro é gratuito para download a partir daqui.

A melhor maneira de resumir rapidamente este livro neste artigo é concentrarmo-nos nos 53 casos de utilização enumerados no livro. Com a permissão dos autores, reproduzo os seus casos de utilização abaixo:

Por favor, dê uma vista de olhos aos casos de utilização acima. A primeira coisa a ter em conta é que os TPM não se limitam a proteger o processo de arranque. Como dissemos anteriormente, o TPM é a raiz central da confiança que permite que cada passo do que devemos fazer com os ATM seja feito em segurança, um passo de cada vez. Evidentemente, cada caso de utilização acima referido pode não se aplicar necessariamente ao nosso setor de atividade. E lembrem-se que estes casos de utilização têm a ver com o estabelecimento da segurança desse item de uma forma criptográfica segura.

Portanto, tomemos um exemplo – N.º 40 – “Chaves VPN”. Em utilização normal, seria criada uma VPN entre um ATM e um servidor, instalando certificados digitais (ou seja, chaves públicas assinadas) nos dois sistemas. Mas o que acontece se alguém piratear os certificados? É verdade que os certificados armazenados num ambiente Windows protegido por TPM com o bloqueio descrito até aqui, neste documento, seriam inalteráveis. No entanto, podemos ir um passo mais longe. As chaves VPN podem ser seladas contra PCR usando o TPM. Isto significa que, no momento em que a VPN está prestes a ser configurada, as chaves necessárias para a configurar só podem ser disponibilizadas se os PCR estiverem no estado correto. Qualquer diferença e a ligação VPN é rejeitada. Agora consideremos que este conceito pode aplicar-se a ambos os lados do túnel da VPN. Não só os PCR devem estar no estado correto do lado do ATM, como também pode ser exigido que estejam no estado correto para o servidor de ATM no centro de dados. Se isso for feito, teremos confirmado criptograficamente que tanto o ATM como o servidor do ATM estão num estado seguro antes de se ligarem. Saberíamos que todos os executáveis que funcionaram tanto no ATM como no servidor de ATM, até esse ponto, são imaculados e sem alterações e permitimos que ambos se liguem se, e apenas se, esse cenário for cumprido por ambos os sistemas.

Este livro branco não é o local em que me proponha discutir todas as ideias do eBook. De facto, existem casos de utilização adicionais que se aplicam especificamente aos ATM e que precisam de ser discutidos, concebidos e implementados. Espero que o setor dos ATM o faça através de uma ou mais das suas comissões. Voltaremos a falar sobre isso mais adiante.

Garantir a segurança das ligações de rede

A secção anterior abordou a segurança da rede. Agora vamos explorar isso com um pouco mais de detalhe, pois este é um caso de utilização que tem particular importância para os ATM. É evidente que não só queremos que os ATM sejam individualmente seguros, como também exigimos que qualquer sistema de servidor back-end em que tocamos esteja igualmente seguro e sem compromissos. Tenha em consideração o diagrama abaixo:

 

 

O diagrama mostra o cenário de ligação num grande banco típico com serviços de ATM sofisticados. Os ATM ligam-se a um processador de terminais que orquestra os serviços de múltiplos servidores back-end. Um HSM (módulo de segurança de hardware) fornece serviços criptográficos e ajuda no zoneamento dos PIN. Depois de uma transação ser encenada e necessitar de autorização, é enviada para o sistema bancário central se for uma transação “On Us” (quando o emitente e o adquirente são uma única entidade ou pertencem à mesma entidade), ou para os esquemas de cartões se for uma transação “Off Us” (se aqueles forem de entidades diferentes).

Agora considere uma Utopia de segurança onde cada ATM e cada servidor tem um TPM (que é o caso de todo o hardware recente), todos os sistemas foram verificados desde o arranque com medições PCR e todas as ligações TLS e VPN foram configuradas utilizando certificados não selados pelo TPM e, por conseguinte, têm a garantia criptográfica de não terem sido adulterados. Uma Utopia, de facto. A triste situação em agosto de 2020 é que muito poucos bancos atingiram este nível de segurança.

Um potencial desafio de implementação aqui é a escalabilidade e a criação de clusters. Como se cria um cluster de servidores se as ligações estão ligadas a TPM individuais? Veja o caso de utilização N.º 47 acima “Um conjunto de servidores atua como um só”. O TCG já pensou nisso.

Proteção das ligações do dispositivo de hardware do ATM

Este documento tem-se centrado até agora no núcleo do PC do ATM e em como assegurar que o software esteja livre de malware após o arranque e durante o seu funcionamento. Agora vejamos os dispositivos de hardware individuais dentro do ATM – o leitor de cartões, o teclado numérico e, claro, o distribuidor de numerário. Qual é a situação de segurança com as ligações entre o núcleo do PC e os dispositivos individuais? Na maioria dos ATM, estas ligações são ligações USB que podem ser fisicamente adulteradas. Se estas ligações tiverem dados não encriptados, o ATM é vulnerável a ataques – mesmo que esteja livre de malware. Vamos discutir isto novamente com um diagrama:

 

 

Como podem ver, desenhei as ligações USB como uma nuvem para indicar o risco de ataque. O TPM assegura o núcleo do PC, mas os cabos USB estão em risco de ataque se não estiverem protegidos. É discutível que a proteção destas ligações seja da responsabilidade do fornecedor de hardware dos ATM. No entanto, a situação não é assim tão simples, pois depende também dos requisitos de interoperabilidade entre os dispositivos de hardware e o resto do sistema. Por exemplo, se as mensagens para o CDM (distribuidor de numerário) são encriptadas de ponto a ponto, onde deveria estar esse “outro ponto”? Se o outro ponto termina no processador do terminal, por exemplo, há muitos requisitos de interoperabilidade que precisam de ser discutidos e acordados.

Também é evidente que mesmo o distribuidor de numerário ainda não está bem acondicionado em muitos ATM – vejam-se os vários “ataques à caixa negra” nos relatórios dos meios de comunicação social. Um ataque à caixa negra do ATM ocorre quando os hackers intercetam a ligação ao CDM e distribuem numerário utilizando o seu próprio núcleo de PC. A maioria dos ATM modernos têm uma ligação encriptada do núcleo do PC ao CDM, mas a KAL suspeita que o conceção da segurança deixa muito a desejar, uma vez que alguns destes ATM não têm TPM. Vamos ser muito claros: Sem TPM = Sem Segurança. Formas obscuras de encriptar a ligação usando chaves que são protegidas por magia não é segurança. É obscuridade e esperança. Se o seu fornecedor de hardware não pode publicar informações sobre como as chaves de encriptação são protegidas, que fique muito claro que isso se deve ao facto de as chaves não estarem devidamente protegidas.

XFS4IoT e a proteção de dispositivos de hardware

A boa notícia é que a comissão XFS do setor dos ATM está a discutir como a próxima geração de dispositivos ATM deve ser protegida. Alguns de vós já devem ter ouvido falar do próximo lançamento do XFS 4.0, que foi nomeado XFS4IoT. A parte da IoT demonstra a intenção de a especificação estar pronta para o mundo moderno da Internet das Coisas (IoT – Internet of Things). Há vários objetivos principais para o XFS4IoT:

• 1. A especificação é agnóstica quanto ao Sistema Operativo. Isto significa que os ATM podem ter o Windows, bem como o Linux ou qualquer outro sistema operativo, dentro do ATM.
  2. É adaptado à nuvem. Os dispositivos de ATM podem expor os serviços diretamente à nuvem. O cérebro do ATM pode estar na nuvem e não apenas dentro do ATM, como acontece hoje em dia. Por exemplo, o leitor de cartões poderia expor os serviços do leitor de cartões à nuvem. O distribuidor de numerário poderia expor os serviços de distribuição de dinheiro à nuvem.
  3. Os serviços Web expostos dessa forma devem ser seguros. O XFS4IoT terá segurança incorporada para garantir segurança de ponto a ponto para os dispositivos. O protocolo de transporte foi selecionado como Web Sockets protegidos por TLS com certificados em ambos os lados. Além disso, cada dispositivo XFS4IoT pode ter um elemento de segurança de hardware para permitir uma segurança de ponto a ponto para a ligação. Essa ligação pode terminar dentro do próprio ATM (como é comum hoje em dia) ou pode terminar num servidor de nuvem.

O diagrama abaixo demonstra o conceito:

Os ATM XFS4 podem ser concebidos como o ATM convencional do lado esquerdo do diagrama, onde os dispositivos se ligam a uma aplicação de software no núcleo do PC, ou podem expor um serviço seguro à nuvem, como no lado direito. No segundo caso, pode não existir um núcleo de PC no interior do ATM e cada dispositivo pode ser completamente independente um do outro, mas fisicamente próximo e funcionando em tandem, orquestrado pela aplicação da nuvem.

O mais importante a salientar são as caixas com a etiqueta “HSE”. HSE significa “elemento seguro de hardware” e a especificação XFS, claro, deixa-o aberto para os fornecedores de hardware determinarem a melhor forma de o implementar. É óbvio que o HSE tem de ser ou um TPM ou conter um subconjunto de características de TPM. Como mínimo, o HSE precisa de ser capaz de:

• Armazenar chaves privadas de forma segura
• Implementar uma “raiz nuclear da medição de confiança” (CRTM) para garantir que apenas firmware seguro possa utilizar o HSE
• Implementar serviços de encriptação e assinatura

A KAL discutiu isto com a comissão do TCG que indicou que teriam todo o prazer em ajudar o setor dos ATM a analisar as opções. De facto, o TCG já fez alguns progressos com os conceitos de “mini TPM”. Um é o desenho DICE do TCG e o outro é o desenho MARS do TCG. O DICE e o MARS estão prontos para serem utilizados no setor dos ATM? Teremos de descobrir.

Um pensamento interessante neste ponto é se os TPM padrão poderiam ser utilizados como HSE dentro de cada dispositivo. De um ponto de vista de custos, a resposta pode ser sim – os TPM custam menos de 1 USD em volume de OEM. O DICE poderia custar ainda menos. Para o nosso setor que protege milhões de dólares de fundos de consumo, o custo de um TPM ou outro tipo de HSE é pouco provável que seja o elemento bloqueador.

Os ATM têm uma segunda raiz de confiança – o EPP

Discutimos a proteção de dispositivos na secção anterior, mas há um dispositivo único que precisamos de destacar no contexto da segurança, e que é o EPP (“Encrypting Pin Pad”), ou seja, o teclado encriptador de PIN. O EPP é, de facto, uma raiz independente de confiança dentro da ATM. É altamente seguro, é regulado pelos requisitos do PCI PED e cada EPP é gerido e controlado individualmente numa base global pelo setor. Tem a sua própria medição CRTM do seu próprio firmware e autodestrói-se, se for detetada adulteração. É, de facto, muito seguro.

No entanto, o EPP tem sido um pró e um contra para o setor. Uma vez que o EPP proporciona um certo nível de segurança para os ATM (discutiremos as suas limitações dentro de momentos), os bancos têm confiado nele para garantir a segurança das transações nos ATM. O EPP armazena a chave-mestra do banco em segurança e, utilizando uma cadeia de chaves, assegura que o bloco dos PIN é seguro e as mensagens de comunicação entre o ATM e o anfitrião são encriptadas e sujeitas a mensagem de código de autenticação MAC. Isto é uma boa segurança. No entanto, não é segurança suficiente.

O EPP fica indisponível quando o ATM arranca e permanece indisponível até que o Windows tenha arrancado e os SP do XFS (os drivers de hardware do ATM) se tenham iniciado. Isto significa que o EPP não tem nada a dizer sobre a validade do software dentro do ATM. Se uma aplicação de ATM infetada por malware desejar aceitar um PIN ou fazer passar uma mensagem MAC para o anfitrião do ATM, o EPP fará o seu papel. O perímetro de proteção do EPP é demasiado pequeno para poder ajudar a garantir a segurança de todo o ATM. É uma joia da segurança numa massa de software potencialmente desprotegido onde não há TPM.

Como se atualiza o software quando protegido por um TPM?

O leitor talvez pense nesta fase que, se for impossível alterar qualquer software dentro de um ATM protegido por um TPM, será difícil levar a cabo atualizações de software válidas. Lembre-se de que o software de aplicação é protegido utilizando uma regra de certificado. É assinado pelo criador da aplicação (que pode ser o próprio banco ou o fornecedor de confiança do banco). Tudo o que é necessário é que o software atualizado seja assinado com a chave privada segura da organização de desenvolvimento de software e o ATM aceitará a alteração. É tão simples quanto isso.

As alterações ao software principal, medidas pelos PCR, necessitam de um passo extra. O software principal pode ser atualizado completamente à distância sem a visita de um técnico, mas requer uma chave temporária a ser criada durante o processo de instalação que é selada contra os PCR inalterados. Uma vez terminada a instalação, as novas chaves são seladas contra o conjunto completo de PCR. Fácil.

Lembre-se do nosso exemplo anterior sobre o Windows Hello – uma boa segurança não precisa de ser difícil de usar. De facto, a segurança de classe mundial – que é o que a proteção TPM dá aos bancos – é mais fácil de utilizar, além de ser criptograficamente segura, quando comparada com os métodos tradicionais.

Defender-se contra ataques físicos

Embora não o tenhamos dito especificamente antes, grande parte da discussão acima é sobre a proteção do ATM contra ataques, tanto físicos como de software. Um método de ataque comum nos ATM é remover a unidade, modificar o software e restaurar as alterações a esse ATM, bem como a outros ATM. Esse método de ataque não é possível se a unidade for encriptada e a cadeia de arranque for protegida pelo TPM.

Outro tipo de ataque é tentar “forçar o TPM” e tentar várias chaves em sucessão rápida. O TPM tem incorporada uma proteção “anti-hammering” que o bloqueia.

Finalmente, existem certos outros tipos de ataques extremos que podem envolver interferência direta com a eletrónica da placa-mãe. Um tal ataque seria dispendioso, uma vez que requer equipamento especializado e, tanto quanto sabemos, não aconteceu até agora. Contudo, existem formas de baixo custo de proteção contra tais ataques, tais como a utilização de resina para proteger as ligações eletrónicas expostas na placa-mãe.

Cuidado com as soluções mágicas

Proteger o ATM e o PC com o TPM como raiz da confiança é a única forma conhecida e publicada de proteger totalmente os sistemas informáticos. O nosso setor deve questionar-se por que razão a segurança baseada em TPM não é mais comum nas redes de ATM. Evidentemente, diferentes empresas quererão competir no mercado e quererão posicionar os seus produtos de segurança. Isso é de esperar. Mas é muito importante que os bancos não caiam em soluções ilusórias. Aqui está uma lista de coisas a ter em conta:

Mito: “Não há necessidade de um elemento de segurança de hardware”.

fique muito claro que é impossível armazenar as chaves privadas no disco/SSD de um ATM de forma segura. O motivo é que, por muito longa que seja a cadeia de chaves, tem de haver uma chave inicial não encriptada. Se essa chave estiver “escondida” na unidade, pode sempre ser recuperada. Algumas soluções afirmam gerar a chave no arranque. Mas lembrem-se que é necessário um código não encriptado para gerar essa chave. Tem de estar não encriptada, pois ainda não decifrámos a unidade. Se estiver não encriptada, pode muito simplesmente ser desenhada de forma inversa ao código executável, que será desencriptado antes da desencriptação da unidade.

Pense nisto de outra forma. Se fosse possível guardar as chaves em segurança num ATM utilizando apenas técnicas de software, o nosso setor não se teria dado ao trabalho de construir os EPP...

Mito: “Não é necessário nenhum elemento seguro de hardware, uma vez que as chaves são armazenadas na rede”.

Se o ATM não for suficientemente seguro para conter as chaves com segurança porque não há TPM, não é possível resolver esse problema movendo as chaves para um local de rede. Eis a razão: quando o ATM arranca, precisa de aceder à rede para obter a chave segura. Não dispõe então de uma forma criptográfica segura para se autenticar na rede porque não tem um chaveiro. Isto significa que o servidor de rede não sabe “quem está a pedir a chave”. Por exemplo, quando o Bitlocker armazena chaves na rede, continua a precisar de um TPM para se autenticar nessa rede. Sem TPM = Sem Segurança.

Mito: “Não há necessidade de chaves de encriptação”.

O fornecedor afirma que o armazenamento de chaves é desnecessário porque têm uma tecnologia mágica que permite que a encriptação aconteça sem chaves. Bem, isso seria de facto demasiado bom para ser verdade. Porque é que o mundo tem lutado desde sempre com técnicas de Gestão de Chaves quando não se precisa delas? Todas as técnicas de encriptação conhecidas, tais como a 3DES, AES e RSA, requerem chaves privadas. As chaves privadas são chamadas assim, pois devem ser armazenadas em segurança. O que torna um sistema de encriptação seguro é que as chaves são escolhidas a partir de um número verdadeiramente enorme de possibilidades. Por exemplo, a 3DES tem, pelo menos, 2 ¹¹² chaves. Levaria 30 anos a experimentar todas as chaves, se fossem tentadas à taxa de 5 mil milhões por segundo. Com o AES, levaria 10 ²² anos ao mesmo ritmo.

Mito: “O nosso algoritmo é confidencial”.

A verdadeira segurança é construída sobre padrões abertos e algoritmos abertos juntamente com chaves confidenciais. O único aspeto de um sistema de segurança que deve ser confidencial são as chaves. Se as chaves ficarem comprometidas, altera-se a chave e o sistema fica novamente seguro.

Mito: “Listas de controlo de acesso (as ACL) mantêm-nos seguros”.

As listas de controlo de acesso são facilmente contornadas na ausência de um bloqueio do TPM. Também existem vários outros inconvenientes para as ACL, que não vamos aprofundar aqui, mas é suficiente dizer que as ACL, por si só, são uma proteção insuficiente para os ATM.

Conclusões

Espero que o leitor tenha chegado a uma apreciação da razão pela qual o TPM é fulcral para a segurança informática e, portanto, fulcral para a segurança dos ATM. Espero também que seja claro que a maioria dos bancos ainda tem algum caminho a percorrer para proteger a sua rede de uma forma criptograficamente garantida. É também importante notar que qualquer sistema de segurança deste tipo tem de ser concebido tendo em mente a interoperabilidade. Uma vez que múltiplos fornecedores e múltiplas soluções de produtos são uma parte padrão do cenário da tecnologia moderna dos ATM, não seria possível que os bloqueios fossem implementados por cada fornecedor independentemente. Isso criaria um ATM inutilizável.

Espero que este documento seja o início de um processo que permita o desenvolvimento de especificações de segurança interoperáveis utilizando as bases criptográficas disponíveis nos TPM. O Trusted Computing Group ofereceu-nos a sua ajuda. Cabe agora às várias comissões do nosso setor – XFS4IoT, ATMIA e EAST – juntamente com os bancos e fornecedores, conceber o caminho a seguir.

Os meus agradecimentos

Gostaria de agradecer às seguintes pessoas pela sua contribuição para este projeto:

• Michael Moltke (NCC Group Denmark)
• Kit Patterson (KAL)
• Will Arthur, David Challener and Kenneth Goldman for writing the eBook on TPMs, and David Challener for organizing support from the TCG

Para mais informações, envie-nos um e-mail para Este endereço de email está protegido contra piratas. Necessita ativar o JavaScript para o visualizar.