PT2280365E

PT2280365E - Um método implementado em processador para garantir a integridade de software

Info

Publication number: PT2280365E
Application number: PT09166439T
Authority: PT
Inventors: Henri Kudelski; Marco Macchetti
Original assignee: Nagravision Sa
Priority date: 2009-07-27
Filing date: 2009-07-27
Publication date: 2012-10-23
Also published as: EP2280365A1; PL2280365T3; ES2390796T3; US8683224B2; EP2280365B1; US20110022854A1

Description

1

DESCRIÇÃO "UM MÉTODO IMPLEMENTADO EM PROCESSADOR PARA GARANTIR A INTEGRIDADE DE SOFTWARE"

INTRODUÇÃO A presente invenção é relativa ao dominio da proteção de software e, mais em particular, a um dispositivo e a meios para tornar o software inviolável, garantindo assim a integridade de um elemento de software.

ESTADO DA TÉCNICA

No dominio do processamento de dados seguro, é necessário proporcionar um ambiente inviolável, no qual o processamento possa ocorrer de modo seguro. Uma primeira abordagem do problema da segurança de aplicação focou-se em tornar o hardware que albergava o software o mais seguro possível. A noção de inviolável na altura significava que esse hardware era de abertura difícil ou, uma vez aberto, destruiria o chip onde se encontrava o software seguro. No entanto, atualmente reconhece-se dum modo geral que as técnicas de software para conseguir a segurança de aplicação oferecem mais flexibilidade e um menor custo e, na maioria dos casos em que uma boa segurança de aplicação implica a garantia de que um elemento de software não foi violado, recorre-se a uma combinação de abordagens de software e de hardware.

Um sistema típico onde corre uma aplicação compreende geralmente uma unidade de processamento, uma série de periféricos e memória. Na maioria dos casos onde seja necessária segurança recorreu-se a esquemas de encriptação. 2

Nesses esquemas, a informação que tem de ficar segura, ou seja, os dados de trabalho ou um código executável, está encriptada. A encriptação é usualmente realizada num módulo de segurança, que constitui uma parte do sistema. É possível implementar o módulo de segurança de diversas formas, como num cartão microprocessador, num cartão inteligente ou em qualquer módulo eletrónico na forma de um distintivo ou de uma chave. Estes módulos são geralmente móveis e destacáveis do recetor e são concebidos para serem invioláveis. A forma mais comummente empregue tem contactos elétricos, mas também existem versões sem contacto do tipo ISO 14443.

Existe outra implementação do módulo de segurança, sendo este diretamente soldado dentro do recetor, sendo uma variação disto um circuito numa tomada ou num conetor como é o caso de um módulo SIM. Ainda outra implementação é ter o módulo de segurança integrado num chip que tem outra função, por exemplo, num módulo de descodificação ou num módulo de microprocessador de um descodificador. 0 módulo de segurança também pode ser implementado em software.

Apesar da utilização de módulos de segurança e de técnicas de encriptação avançadas em sistemas de processamento seguros atuais, esses sistemas representam ainda um foco de atração significativo de tentativas de quebras de segurança. As técnicas que foram utilizadas para quebrar a segurança desses sistemas incluem, por exemplo, engenharia reversa do hardware em questão ou a análise estática ou dinâmica do software aí empregue e a violação subsequente desse software. A análise estática trata-se de alguma forma de desmontagem ou descompilação de código de não-execução. A análise dinâmica significa realizar a análise enquanto o código está a correr, ou seja, observar certos sinais enquanto o software está a correr. Essas análises poderão 3 levar a manipulação maliciosa, sendo o software modificado através, por exemplo, da realização de um ataque de branch-jamming, sendo introduzido um salto incondicional em vez de um salto condicional, forçando assim um ramo a executar quando as condições atuais não indicam essa execução. Tipicamente, um ataque desse tipo obrigará um programa a desviar-se de uma etapa de autenticação, como, por exemplo, uma verificação de número de série ou uma verificação de palavra-passe.

Num trabalho intitulado "Tamper-Resistance for Software Protection", apresentado em 2005 como tese de mestrado em ciências (Master of Science), Ping Wang descreve uma técnica de encriptação de multiblocos, em que um programa de software é dividido numa série de blocos independentes de acordo com o fluxo do programa. Cada bloco do programa é depois encriptado, tendo cada bloco uma diferente chave de encriptação. A chave de encriptação para cada bloco é o valor hash do bloco precedente de acordo com o fluxo do programa. Esta técnica funciona em programas que têm uma estrutura em árvore, sendo os blocos dispostos numa estrutura hierárquica, indo um bloco levar a outro. Nesta técnica, o primeiro bloco a ser executado tem de estar em claro. Um código para chamar a rotina de desencriptação é colocado dentro de cada um dos blocos, e um controlador de programa para implementar a verificação de integridade dinâmica é adicionado ao fim do programa. Se um adversário tenta alterar uma parte do programa, então o valor hash para o bloco contendo a parte modificada do programa será diferente e, assim, o bloco seguinte não será desencriptado corretamente e o programa cracha.

Este esquema tem a desvantagem de cada bloco necessitar assim de ser lido duas vezes. Ainda tem a desvantagem de a encriptação ser realizada bloco por bloco, em vez de 4 instrução por instrução, sendo uma chave de desencriptação válida para um bloco inteiro. Isto significa que a descoberta de uma chave deixa vulnerável um bloco completo de software. 0 tamanho do bloco mais pequeno possivel é determinado pelo bloco mais pequeno contendo totalmente um ciclo, dado que na sua conceção, por definição, um bloco deverá conter a totalidade de um ciclo. Mesmo que um programa pudesse ser reduzido para uma instrução por bloco no caso de existirem dois ciclos, o overhead resultante na implementação do método tornaria o resultado final pesado em termos de tamanho e de velocidade de execução. Além disso, é possivel imaginar um possivel ataque em que uma modificação poderia ser realizada a um bloco e uma modificação correspondente poderia ser realizada no controlador de programa, para compensar a modificação, de modo a calcular o valor hash correto relativamente à modificação realizada ao bloco, mantendo assim a integridade perceptível do programa. 0 documento EP-0908810-A2 revela um processo seguro com memória externa, utilizando encriptação progressiva e reordenação em bloco, em que a informação de autenticação é combinada por XOR com o último bloco de dados em claro (por exemplo, informação de programa) e é opcionalmente desencriptada para dar origem a um valor de verificação, permitindo assim a verificação da integridade de cada bloco. A presente invenção permite que o código executável exista no formato encriptado, sendo a encriptação realizada numa base de instrução por instrução e não requerendo que as instruções sejam lidas duas vezes. O esquema pode ser executado inteiramente em hardware com a vantagem inerente de as chaves de encriptação nunca aparecerem em lado nenhum em que possam ficar vulneráveis a ser intercetadas. Não 5 existe overhead de software e, por isso, a velocidade de execução aumenta muito. No estado da técnica, a chave de encriptação para o bloco seguinte dependia apenas dos conteúdos do bloco precedente. Na presente invenção, a chave de encriptação poderá depender da acumulação de uma série de valores de chave de encriptação precedentes. Por exemplo, a chave para desencriptar a instrução seguinte poderá ter por base a instrução atual combinada com uma acumulação das chaves para as duas instruções prévias.

BREVE RESUMO DA INVENÇÃO A presente invenção tem por objetivo resolver o problema de segurança causado pela análise de software e pela subsequente violação do referido software, minimizando ao mesmo tempo o overhead, de modo a chegar à solução e a torna-la flexível e aplicável a sistemas que utilizam o software de muitos tipos estruturais diferentes. Consegue-se isto utilizando um método implementado em processador, para garantir a integridade de software numa memória de programa, compreendendo o referido software uma série de instruções encriptadas, indo uma instrução compreender pelo menos um opcode (código de operação), utilizando o referido método uma chave de instrução inicializada e compreendendo as seguintes etapas: - ler uma instrução encriptada atual, - utilizar a chave de instrução para desencriptar a instrução encriptada atual, - atualizar a chave de instrução utilizando um cálculo com base no valor atual da chave de instrução e um digest da instrução atual, de modo a que a instrução seguinte encriptada a ser lida possa ser desencriptada com a chave de instrução atualizada, 6 - executar a instrução atual. A invenção pode ser aplicada a programas, cuja estrutura não seja necessariamente em árvore, e pode ser executada em software ou inteiramente em hardware, eliminando desse modo a possibilidade de terceiros intercetarem uma instrução desencriptada ou uma chave de desencriptação.

BREVE DESCRIÇÃO DAS FIGURAS A presente invenção será melhor entendida com referência à seguinte descrição detalhada de execuções preferidas, se lida em ligação com as Figuras anexas, onde:

Fig. 1 é um diagrama de blocos simplificado de uma execução da presente invenção.

Fig. 2 mostra um diagrama de fluxo de uma execução da presente invenção.

Fig. 3 é um diagrama de blocos simplificado, gue mostra como os saltos ou os ramos de software poderão ser tratados de acordo com uma execução da presente invenção.

DESCRIÇÃO DETALHADA

Como acima mencionado, a presente invenção tem por objetivo fornecer um meio para fazer correr software de modo seguro, sendo o software armazenado numa memória numa forma encriptada, e sendo desencriptado e executado num processador seguro numa base de instrução em instrução, longe da possibilidade de ser monitorizado. A chave para a desencriptação de uma instrução atual depende de pelo menos uma instrução prévia ter sido descodificada corretamente, enguanto a chave para a desencriptação de uma instrução seguinte depende da desencriptação correta da instrução 7 atual. Deste modo, consegue-se um meio de autoverificação para garantir a integridade de um elemento de software. A mera execução com êxito do software é uma garantia que nem o fluxo nem o conteúdo foram violados, uma vez que uma modificação realizada numa instrução iria invalidar a capacidade de desencriptar a instrução seguinte, levando ao encerramento prematuro do programa ou pelo menos a uma corrupção do rastreio de execução do programa. 0 esquema empregue na presente invenção pode ser executado em software, mas é de se ter em consideração que o mesmo pode ser inteiramente executado em hardware, retirando assim a possibilidade de terceiros intercetarem as instruções em claro ou interceptarem qualquer uma das chaves de desencriptação implicadas. A invenção resulta em praticamente nenhum overhead em comparação com as soluções do estado da técnica. 0 esquema pode ser aplicado ao software de diversas arquitecturas ou estruturas diferentes, inclusive aquelas com saltos e interrupções, e não fica limitado às estruturas conhecidas como estruturas em árvore.

Por conseguinte, a presente invenção fornece um método para garantir a execução de software inviolável num sistema compreendendo pelo menos uma memória de programa (PMEM) para guardar instruções de programa encriptadas (INSTP', INSTC', INSTF' ) , um módulo de desencriptação (DECR) para desencriptar as referidas instruções de programa, uma unidade de processamento de dados (SCPU) para executar as instruções de programa desencriptadas (INSTP, INSTC, INSTF) e um meio para construir chaves de desencriptação, conhecidas por chaves de instrução (KP, KC, KF), para desencriptar as instruções de programa encriptadas. Os meios para construir as chaves de instrução poderão obviamente estar localizados na unidade de processamento de dados. 0 módulo de desencriptação e a unidade de 8 processamento de dados deverão encontrar-se preferencialmente dentro do módulo de segurança de qualquer um dos tipos bem conhecidos do estado da técnica.

Durante a execução do programa encriptado, a instrução encriptada atual (INSTC') é lida pela memória de programa (PMEM) e é desencriptada (DECR) para dar origem a uma instrução atual (INSTC), utilizando uma chave de desencriptação atual (KC) que é construída a partir de uma combinação (Fn) , por um lado, de um digest da chave de desencriptação prévia (KP) e, por outro, de um digest da instrução previamente executada (DIG(INSTRP)), como mostrado na Fig. 1. "Digest" significa qualquer operação aplicada a todo ou a uma parte de um operando e dando origem a um output (saída) . Ter em atenção que o digest, quando realizado num operando, poderá dar origem a um output que é igual ao próprio operando. Em conformidade com uma execução da presente invenção, o digest inclui uma função unidirecional no operando. Isto permite travar ainda mais qualquer tentativa por terceiros de retroceder e deduzir chaves anteriores ou instruções anteriores. Uma função hash é um exemplo desse tipo de função unidirecional (SHA2, MD5, por exemplo) . "Combinação" significa qualquer forma de combinação dos operandos mencionados, seja lógica, aritmética ou criptográfica. Deste modo, garante-se o fluxo e o conteúdo do programa, uma vez que, se a instrução encriptada atual não for a instrução pretendida pelo criador do programa, então a chave de desencriptação atual (KC), se utilizada para desencriptar a instrução encriptada atual, dará origem a outro valor não pretendido. Deste modo, obtemos um elemento de software que se autoverifica, dado que a integridade do software é meramente garantida pela sua execução com êxito. Se o software tiver sido violado, o mesmo não conseguirá executar. 9 A Fig. 2 mostra um diagrama de fluxo que representa a execução anterior da presente invenção. Esta representação descreve a invenção do ponto de vista de uma imagem instantânea no tempo, em vez de estar em questão uma instrução atual com a sua chave de desencriptação atual e uma instrução prévia com a respetiva chave prévia, etc., referindo-se apenas a uma chave de instrução (Kl) que é atualizada à medida que cada instrução é executada. Como normal em qualquer unidade de processamento, utiliza-se um contador de instruções (PC) para indicar a localização da instrução seguinte a ser executada. Este contador de instruções é incrementado a seguir à execução de uma instrução, ou será de outro modo atualizado se a referida instrução ditar outra forma de atualização que não um simples incremento. Por exemplo, se uma instrução implicar um comando para carregar um valor de um registo, o contador de instruções irá usualmente ser simplesmente incrementado para indicar a localização seguinte. No entanto, se a instrução implicar um salto para uma determinada localização, o contador de instruções será atualizado com o valor da localização indicado pelo salto. 0 contador de instruções (PC) e a chave de instrução (Kl) são primeiro inicializados (INI PC, INI Kl). Uma instrução encriptada é lida da memória de programa numa localização indicada pelo contador de instruções (RD INST' c.f. PC) e desencriptada utilizando a chave de instrução (DCPT INST, Kl) . A instrução é executada (EX INST) e o contador de instruções é atualizado (UPD PC) através de um simples incremento ou através da substituição de um novo valor, como ordenado pela instrução. A chave de instrução é atualizada (UPD Kl, INST) utilizando um digest da instrução executada. A atualização da chave de instrução tem assim em consideração não apenas a instrução que acabou de ser executada, mas também o valor da chave que foi utilizada 10 para desencriptar a instrução. Por sua vez a chave de instrução, que foi previamente utilizada para desencriptar a instrução prévia, foi construída a partir da instrução prévia e da chave de instrução que foi utilizada para desencriptar a instrução antes dessa. Deste modo, o valor da chave de instrução não depende apenas da última instrução executada, mas da combinação de todas as instruções previamente executadas. De facto, numa execução da presente invenção, a atualização da chave de instrução tem em consideração o valor da última instrução executada e os valores de pelo menos duas instruções executadas anteriores. Por exemplo, a chave para desencriptar a instrução 4 poderia ser uma combinação de um digest da instrução 3, um digest da instrução 2 e um digest da instrução 1.

Como mostrado na Fig. 2, o método da presente invenção implica um ciclo, sendo a chave de instrução atualizada utilizando uma instrução previamente executada. Isto leva à questão de como desencriptar a primeira instrução num programa. Se não houver instrução previamente executada, como será então calculada a primeira chave de instrução? Numa execução da presente invenção, a primeira instrução num programa é deixada em claro, enquanto todas as outras instruções são encriptadas. Por conseguinte, a primeira instrução é executada diretamente, iniciando assim o ciclo, e a segunda instrução é desencriptada utilizando uma chave de instrução com base na primeira instrução e por aí fora. Noutra execução da presente invenção, todo o programa é encriptado, inclusive a primeira instrução, e a chave de instrução é inicializada utilizando um valor que desencriptará a primeira instrução. Este valor poderá ser uma chave-mestra que é incorporada no módulo de segurança ou que é de outro modo comunicada ao módulo de segurança a partir do exterior. 11

Durante a execução de um programa, as circunstâncias poderão proporcionar que uma instrução atual (INSTC'), localizada numa localização de memória atual (C), possa ser referenciada por mais do que uma de instruções prévias (INSTP1, INSTP2). Por outras palavras, uma instrução atual, ou chamado, pode ser referenciada por um ou mais chamadores, por exemplo, quando se encontra uma instrução do tipo ramo (inclusive salto, ramo ou chamada, por exemplo). A Fig. 3 ilustra um cenário em que dois chamadores (INSTP1, INSTP2) se referem a um chamado (INSTC). Neste caso, uma vez que são possíveis dois valores diferentes para a chave de instrução face aos diferentes históricos possíveis, isto levará a dois resultados diferentes, consoante qual a chave que será utilizada para desencriptar o chamado encriptado. Obviamente que esta situação não é desejável, uma vez que o chamado encriptado só pode ter sido encriptado por uma chave. Para contornar este problema, é realizada uma modificação (CORRI, C0RR2) ao cálculo, de modo a forçar a chave de instrução resultante para o valor requerido, com vista a desencriptar corretamente o chamado. Por exemplo, um chamado localizado na localização C é referenciado por dois chamadores diferentes nas localizações PI e P2. A chave de instrução requerida para desencriptar de forma correta a instrução encriptada na localização C (INSTC') é KCiN. No entanto, o valor da chave de instrução a seguir à execução da instrução localizada em PI (INSTP1) é KP10ut e o valor da chave de instrução a seguir à execução da instrução localizada em Ρ2 (INSTP2) é ΚΡ20υτ· Além disso, é razoável assumir que KP10ut não é igual a KP20Ut e que nem KP10ut nem ΚΡ2ουτ são iguais a KCiN. Por conseguinte, o método requer que seja realizada uma modificação (CORRI, C0RR2), permitindo assim que o valor da chave de instrução seja levado para o valor necessário, sempre que uma instrução do 12 tipo ramo seja executada. Uma vez que o valor da chave necessário para desencriptar o chamado é conhecido (ou seja, KCin) e o valor da chave a seguir à execução do chamador é conhecido, é possível prever um valor de modificação para cada chamador, sendo que esse valor de modificação , se empregue no cálculo, levará a chave de instrução para o valor requerido. 0 valor de modificação correto é depois implementado em cada tipo de ramo, de modo a realizar a modificação necessária à chave de instrução cada vez que seja empregue este tipo de instrução - sendo realizada uma modificação diferente por chamador. De acordo com uma execução da presente invenção, o valor de modificação é introduzido como outro operando na combinação da chave de desencriptação prévia e do digest da instrução prévia, como acima descrito.

Como exemplo de como a modificação da chave de instrução acima descrita é realizada, tem-se em consideração uma instrução de salto. Numa execução preferida da presente invenção, uma instrução de salto compreende um parâmetro de destino, como é usualmente o caso para uma instrução de salto, e compreende ainda um parâmetro de modificação, por exemplo, JMP C, #C0RR1. 0 valor de modificação (#C0RR1) é depois utilizado como parâmetro adicional na combinação da chave de instrução prévia e de toda ou de uma parte da instrução prévia. É útil notar que em vez de extrair o valor de modificação da instrução e utiliza-lo como parâmetro extra na etapa de combinação, o digest da instrução de salto poderá já ter em conta o valor de modificação. A seguinte Tabela TI ilustra o estado das chaves de instrução, dado que a execução de um programa decorre através de uma instrução de salto modificada do tipo acima descrito. A tabela inclui o valor da chave necessário para desencriptar uma instrução, e o valor da chave a seguir à execução da instrução e o cálculo de uma 13 nova chave. Uma vez que o valor da chave necessário para desencriptar a instrução na labell é conhecido, segue-se que os valores de correção apropriados, CORRI ou C0RR2, podem ser calculados de modo a levar os valores não modificados, K4 ou K14, para o valor requerido K91.

TI

Chave necessária Label Instrução Chave resultante Kl Instruçãol K2 K2 Instrução2 K3 K3 JMP labell, CORRI K91=Fn(K4,CORRI) Kll Instruçãol1 K12 K12 Instruçãol2 K13 K13 JMP labell, C0RR2 K91=Fn(K14,C0RR2) K91 labell Instrução91 K92 K92 Instrução92 K93

Noutra execução da presente invenção, em vez de se ter uma instrução de salto modificada, por exemplo, utiliza-se uma instrução de salto padrão, e a modificação da chave de instrução acima descrita é realizada por uma instrução "de modificação" dedicada com um valor de modificação como parâmetro. A função de uma instrução de modificação deste tipo é a de atuar diretamente na chave de instrução com base no valor de modificação. A instrução de modificação é colocada mesmo antes da instrução tipo ramo ou salto, permitindo assim à chave de instrução ser atualizada de forma apropriada, de modo a desencriptar corretamente o chamado. É útil ter em consideração que a função "de modificação" como acima descrita poderá de facto ser uma série de instruções concebidas para realizar a operação de 14 modificação pretendida sobre o valor da chave de instrução. Por exemplo, se o valor da chave de instrução necessário para desencriptar corretamente o chamado for #39, poderá existir, mesmo antes, por exemplo, de uma instrução de salto, um XOR da chave de instrução (Kl) com #39 para encontrar o valor de modificação (CORRI) e, depois, uma adição de CORR e Kl para originar um valor Kl novo (corrigido):

Noutro exemplo, a chave de instrução no chamado "labell" tem o valor K91. Devido ao facto de o fluxo de programa poder chegar de diferentes vias, uma instrução de correção Inst_CORR é adicionada mesmo antes do salto, de modo a que a chave de instrução seja atualizada para um valor predeterminado K90. A execução da instrução tipo ramo, que neste caso é um salto, modificará a chave de instrução de K90 para K91. Como aparente na Tabela T2 abaixo, o valor de correção (Cl, C2) associado à instrução de correção (Inst_CORR) destina-se a modificar a chave de instrução atual (K3, K13) para o valor predefinido K90. Em consequência disso, a execução do salto atualizará a chave de instrução de K90 para K91, o valor utilizado para desencriptar a instrução no chamado (labell).

No caso de a instrução tipo ramo ter um valor diferente, por exemplo, quando a instrução é um ramo curto BRA, o digest produzido por esta instrução será diferente do digest produzido pela instrução de salto. Em consequência disso, o valor de correção C3 anexado à instrução de correção Inst_CORR deverá ter em conta a diferença, e a chave de instrução ao executar a instrução de ramo não será a mesma que para a instrução de salto. No entanto, devido ao valor de correção C3, o valor final após a execução da instrução de ramo curto continuará a ser K91. 15 Τ2

Chave necessária Label Instrução Chave resultante Kl Instruçãol K2 K2 Instrução2 K3 K3 Inst_CORR, Cl K90=Fn(Cl,K4) K90 JMP labell K91 Kll Instruçãoll K12 K12 Instruçãol2 K13 K13 Inst_CORR, C2 K90=Fn(C2,K14) K90 JMP labell K91 K2 0 Instruçãol K2 K21 Instrução2 K3 K22 Inst_CORR, C3 K80=Fn(C3,K23) K80 BRA labell K91 K91 labell Instrução91 K92 K92 Instrução92 K93 A seguinte Tabela T3 ilustra o estado das chaves de instrução à medida que a execução do programa decorre através de uma instrução de salto condicional, sendo possíveis dois destinos diferentes, labell e label2, a seguir à execução do salto condicional. Neste caso, a chave necessária para desencriptar as instruções nos dois destinos deverá ser a mesma. A tabela inclui o valor da chave necessário para desencriptar uma instrução e o valor da chave a seguir à execução da instrução e o cálculo de uma nova chave. 16 Τ3

Chave nec. Lab Instrução Chave res. K91 LI Instruçãol K2 K2 Instrução2 K3 K3 C0RR=C1 K90 K90 JMP COND Ll, L2 K91 Kll Instruçãol1 K12 K12 Instruçãol2 Kl 3 K13 JMP L2, C0RR2 K91 K91 L2 Instrução91 K92 K92 Instrução92 K93

Outra situação em que um chamado poderá ser referenciado por uma série de chamadores, requerendo assim uma modificação a ser realizada na chave de instrução, de modo a desencriptar corretamente o chamado, é uma chamada de função ou uma chamada de subrotina. Tipicamente, durante este tipo de chamada, os parâmetros podem ser passados durante a chamada, aumentando assim o número de diferentes fluxos possíveis na função ou na subrotina e, consequentemente, o número de resultados possíveis a seguir à execução da função ou da subrotina. Quando se encontra uma chamada deste tipo, uma modificação é realizada na chave de instrução, para que o seu estado possa ser conhecido no início da função ou da subrotina, e realiza-se outra modificação aquando do retorno da chamada, ou seja, mesmo antes de sair da função ou da subrotina.

Ter em atenção que, no contexto da presente invenção, a modificação como acima descrita também poderá contemplar simplesmente uma substituição de uma chave por outra. 17

Como é bem do conhecimento dos especialistas da técnica do processamento de dados, uma instrução compreende pelo menos um opcode, que define uma operação a ser realizada. A instrução deve compreender não mais do que isto ou poderá ainda compreender um ou mais operandos nos quais a operação será realizada. Além do opcode e do operando ou operandos, caso existam, uma instrução poderá compreender uma marca de autenticação, também conhecida por valor de integridade, que é utilizada como forma de verificar a validade da instrução. Por consequência, noutra execução da presente invenção, antes da execução de uma instrução, a instrução pode ser primeiro verificada utilizando uma marca de autenticação como acima descrito. A marca de autenticação poderá assumir a forma de uma soma de controlo ou de um valor hash de todo ou de uma parte do opcode e do(s) operando(s). Na maioria dos casos, a marca de autenticação poderá ser considerada uma assinatura do opcode. Ao encriptar toda ou uma parte de uma instrução, fica-se perante a escolha de encriptar apenas o opcode ou o opcode com a marca de autenticação ou também incluir o(s) operando(s). Qualquer combinação das anteriores funcionará, mas, contudo, no casos em que seja importante esconder o conteúdo de um programa de terceiros, a presente invenção prefere a encriptação do opcode e da marca de autenticação, uma vez que a marca de autenticação poderá dar a um atacante potencial uma pista de qual poderá ser o opcode. 0 método empregue nesta execução da presente invenção compreende assim ler a instrução encriptada atual; utilizar a chave de instrução para desencriptar a instrução encriptada atual e a marca de autenticação; verificar a marca de autenticação assim extraida; atualizar a chave de instrução utilizando um cálculo com base no valor atual da chave de instrução (ou um respetivo digest) e um digest da instrução atual, de modo a que a instrução encriptada seguinte a ser lida possa ser desencriptada com a chave de 18 instrução atualizada; executar a instrução atual na condição de que a marca de autenticação tenha sido considerada válida. Se a marca de autenticação não tiver sido considerada válida, poderá definir-se que o programa encerre de forma graciosa, ou seja, gerando um alarme apropriado.

Dado que em alguns casos onde possa ser implementada a invenção, um objetivo possa não ser necessariamente impedir que terceiros sejam capazes de copiar um elemento de software, mas meramente impedir que terceiros alterem o software sem que essa alteração seja detetada, existe uma execução da invenção em que os opcodes das instruções são deixados em claro e apenas as marcas de autenticação são encriptados. Isto é suficiente para atingir o objetivo de garantia da integridade do software proporcionada pela invenção. De modo semelhante, é possível noutra execução encriptar apenas os operandos, caso existam. Do mesmo modo, é possível a encriptação de qualquer um dentre opcode, operandos ou marcas de autenticação, ou de qualquer outra combinação dos mesmos.

De modo semelhante, numa execução da presente invenção, é possível manter o opcode e os operandos em claro e encriptar apenas uma parte da marca de autenticação. No caso de um salto, em vez de utilizar um valor de modificação como acima descrito, é possível simplesmente desativar a verificação da marca de autenticação após uma instrução de salto. A vantagem desta solução é que a instrução de salto não requereria assim um valor de modificação. A presente invenção fornece, por conseguinte, uma solução ao problema de garantir a integridade de programas de software, através da encriptação de toda ou de uma parte de 19 cada instrução de um programa, utilizando uma chave com base em toda ou numa parte de uma ou mais instruções prévias, tendo assim por resultado uma chave de encriptação diferente por instrução. A invenção é aplicável a programas de software cujas estruturas não sejam necessariamente de natureza em árvore e também é aplicável nos casos em que o programa inclua ciclos, saltos, chamadas ou interrupções, etc. A invenção permite que uma exceção seja assinalada, se uma instrução encriptada for incorretamente desencriptada. A primeira instrução não tem necessariamente de estar em claro, uma vez que a chave de instrução pode ser inicializada de forma apropriada como requerido. É possível executar a invenção em software ou inteiramente em hardware, eliminando desse modo a possibilidade de terceiros intercetarem uma instrução desencriptada ou uma chave de desencriptação. A encriptação da instrução pode utilizar um algoritmo dentre um grande número de algoritmos de encriptação, tais como, por exemplo, uma cifra encadeada, uma cifra em blocos, um one-time pad, um scrambler como a inversão de bits, bit shifting, bit swapping, um algoritmo de paridade ou um código de redundância cíclica.

Claims

1 REIVINDICAÇÕES 1. Um método implementado em processador para garantir a integridade de software numa memória de programa, caracterizado por o referido software compreender uma série de instruções encriptadas, em que uma instrução contém pelo menos um opcode, sendo que o referido método emprega uma chave de instrução inicializada e compreende as seguintes etapas: ler uma instrução encriptada atual, utilizar a chave de instrução para desencriptar pelo menos uma parte da instrução encriptada atual, atualizar a chave de instrução utilizando um cálculo com base num digest do valor atual da chave de instrução e um digest da instrução atual, de modo a que a instrução encriptada seguinte a ser lida possa ser desencriptada com a chave de instrução atualizada, executar a instrução atual.

2. Método de acordo com a reivindicação 1, caracterizado por uma primeira instrução na memória de programa não estar encriptada.

3. Método de acordo com uma das reivindicações 1 ou 2, caracterizado por a instrução atual compreender uma marca de autenticação, sendo a referida marca de autenticação utilizada para autenticar a referida instrução antes da execução.

4. Método de acordo com uma das reivindicações 1 a 3, caracterizado por se realizar uma modificação à chave de instrução, indo essa modificação permitir a 2 desencriptação da instrução encriptada seguinte, utilizando a referida chave de instrução modificada, para dar origem a uma instrução executável.

5. Método de acordo com a reivindicação 4, caracterizado por a instrução atual compreender ainda um valor de modificação a ser utilizado para atingir a modificação, sendo o referido valor de modificação extraído do valor de instrução e atuando na etapa de atualização, enquanto determina a chave de encriptação seguinte.

6. Método de acordo com uma das reivindicações 1 a 5, caracterizado por qualquer um ou por todos os processos de desencriptação de uma instrução encriptada, de atualização da chave de instrução, de autenticação da instrução atual ou de execução da instrução atual ser ou serem realizados num módulo de segurança.

7. Método de acordo com uma das reivindicações 1 a 6, caracterizado por um referido digest ser um resultado de uma função aplicada a toda ou a uma parte da referida instrução atual, sendo a referida função selecionada de uma função lógica, de uma função aritmética, de uma função criptográfica ou de uma função unidirecional.

8. Método de acordo com uma das reivindicações 1 a 7, caracterizado por a atualização da chave de instrução se basear ainda num valor de modificação, sendo o referido valor de modificação utilizado para levar a chave de instrução para um valor conhecido. 3

9. Método de acordo com uma das reivindicações 1 a 8, caracterizado por uma chave-mestra ser utilizada para inicializar a chave de instrução.

10. Dispositivo caracterizado por compreender um contador de instruções (PC) e uma memória de programa (PMEM) para armazenar um programa encriptado, compreendendo o referido programa encriptado uma série de instruções encriptadas (INST'), indo as referidas instruções compreender pelo menos um opcode, compreendendo o referido dispositivo ainda um módulo de desencriptação (DECR) e uma unidade de processamento de dados (SCPU), tendo o referido dispositivo acesso a uma chave de instrução inicializada (Kl), sendo o referido dispositivo caracterizado por ainda compreender meios para atualizar de forma recorrente a chave de instrução (Kl), com base em toda ou numa parte da referida chave de instrução e num digest de pelo menos uma instrução previamente executada.

11. Dispositivo de acordo com a reivindicação 10, caracterizado por os meios para a atualização de forma recorrente da chave de instrução serem executados em hardware.

12. Dispositivo de acordo com uma das reivindicações 10 ou 11, caracterizado por a atualização da chave de instrução ter ainda por base um valor de modificação, sendo o referido valor de modificação utilizado para levar a chave de instrução para um valor conhecido.