Gebotys e Gebotys (2003) propuseram o uso de um ambiente de segurança em NoC para acesso não autorizado, invasão de software, cópia não autorizada do núcleo e ataques de energia e de eletromagnetismo8. No mecanismo proposto, foi criada uma camada na interface de rede do núcleo para implementação de segurança (Secure Core) e de um núcleo centralizado para armazenar as chaves (Key-keeper). Antes da comunicação ocorrer entre os núcleos conectados à NoC, o Secure Core solicita ao Key-keeper a sua chave privada, a qual está armazenada de forma segura na memória. Essa comunicação entre o Key-keeper e o Secure Core é também criptografada, porém com uma chave de rede, armazenada dentro do próprio núcleo do Secure Core. Após a chave privada estar armazenada no Secure Core, a comunicação é feita através de criptografia de chave pública e privada. A solução foi avaliada e apresentou um impacto no desempenho menor que 11%.
Ashkenazi e Akselrod (2007) propuseram uma solução para o acesso não autorizado de execução de código em modos privilegiados e o acesso aos dados em memória pela porta de depuração, utilizada para testes e depuração de software em dispositivos móveis. O mecanismo proposto inclui vários elementos, criando uma arquitetura relacionada à segurança genérica incorporada ao processador de aplicação. Um controlador de porta de depuração é utilizado para manipular acessos não autorizados e permitir a depuração e testes de software. Verificadores de
8 Ataque que visa extrair informações através do vazamento de informações por campos eletromagnéticos.
integridade em tempo de execução são utilizados para proteger a modificação dos dados com acesso somente de leitura, usando mecanismos de armazenamento de dados, criptografia e proteção física.
A solução foi implementada usando a interface de depuração comercial JTAG (Joint Test Action Group) e um processador de aplicação baseado no núcleo ARM1136JF-STM. O trabalho não apresentou quais foram os experimentos de avaliação realizados, mas demonstrou que é possível montar uma arquitetura flexível que permita depurar e fazer manutenção sem comprometer a privacidade do proprietário do equipamento.
Diguet et al. (2007) propuseram uma solução para autenticação de entidades e de integridade de dados. O mecanismo proposto foi constituído por um gerenciador de segurança e por interfaces de rede (NI – Network Interface) seguras. As transações entre os núcleos são monitoradas e somente autorizadas se as configurações da política de segurança permitirem essas transações. A comunicação é feita por canais virtuais dedicados, separando aplicação do fluxo de dados seguros, monitorados e controlados. A solução foi implementada e verificada por simulação, pela ferramenta μSpider (EVAIN, DIGUET; HOUZET, 2004), e por prototipação, usando a ferramenta ISE da Xilinx. Os resultados mostraram que o custo da solução aumenta 45% quando comparada à solução sem a implementação de segurança. A principal causa do sobrecusto é devido à implementação do canal seguro nos roteadores, que passaram a ter dois canais virtuais ao invés de um único canal, como no roteador não seguro.
Fiorin, Silvano e Sami (2007) fizeram um levantamento e apresentaram algumas soluções para ataques de negação de serviço (DoS – Denial-of-Service), extração de informação secreta e hijacking em NoCs. O levantamento apresentou uma introdução a uma série de módulos que podem ser usados para aumentar o nível de segurança em NoCs. O primeiro módulo explorado foi do APU (Address Protection Unit), o qual pode restringir acesso à memória, evitando buffer overflow ou ataques que podem roubar ou modificar informações sensíveis da memória. O segundo módulo explorado foi de garantia de banda, no qual técnicas de qualidade de serviço (QoS – Quality-of- Service) podem ser utilizadas para reservar uma certa quantia de banda para cada núcleo, evitando que códigos maliciosos ou mal escritos possam consumir toda a banda da rede enviando ou requisitando dados por meio da rede. O autômato de segurança foi outro módulo explorado. Neste módulo as transações são monitoradas, mudando os estados até um nível seguro, possibilitando monitorar ataques conhecidos de/para um núcleo na rede. Por último, foi explorado o módulo de um sistema de detecção de intrusão (IDS – Intrusion Detection Systems), que monitora o canal de
comunicação entre os núcleos para detectar violações de segurança, que podem ser: (i) ocupação de buffers; (ii) comportamento anômalo do gerenciamento de energia; (iii) acesso não autorizado a locais de memória seguros; e (iv) violações na execução de rotinas críticas. Neste trabalho, nenhum dos módulos propostos foi implementado e, portanto, esses módulos não foram avaliados e não possuem resultados. Os autores destacaram a necessidade de investigações para avaliar o provimento do serviço de segurança em relação ao desempenho e os sobrecustos de área e de energia.
Anoop (2008) discutiu sobre o tema da necessidade da segurança em sistemas embarcados, a qual foi classificada em: (i) necessidade da segurança na transmissão dos dados; e (ii) necessidade de segurança dentro do dispositivo, como para armazenar os dados. O artigo discute sobre criptografia dos dados, o algoritmo de chaves públicas, assinatura digital e certificação digital para a segurança na transferência de dados entre os dispositivos. A necessidade de segurança dentro do dispositivo vai desde armazenar seguramente as chaves utilizadas na criptografia dos dados para a comunicação até para restringir o manuseio pelos usuários, como na proteção contra cópia de vídeo/música assim como proteção aos dados privados do usuário (arquivos pessoais, transações bancárias, etc.). O autor apresenta um protótipo de SoC, discutindo os pré-requisitos de hardware e de software para implementar segurança e evitar ataques físicos ao dispositivo. As conclusões são que a segurança na transferência de dados entre dispositivos possui uma maturidade suficiente para manter segura a transferência, porém a proteção dos dados dentro do dispositivo ainda não é inviolável. Adicionalmente, o autor conclui que os mecanismos de proteção em hardware oferecem um aumento na segurança, mas essa maior proteção nos dados implica diretamente no maior custo da implementação.
Fiorin et al. (2008) propuseram uma solução para proteção dos dados no acesso à memória em sistemas baseados em NoC. O mecanismo proposto foi o de uma arquitetura de rede segura baseada em unidade de proteção de dados (DPU – Data Protector Unit) integrada na interface de rede (NI – Network Interface) da NoC. A DPU garante acesso seguro à memória e/ou periféricos mapeados em memória, habilitando o acesso a espaço de memória somente se quem inicializou a requisição de acesso é autorizado. O acesso é filtrado considerando não somente a memória de endereço, mas também o tipo de operação requisitado (ler, gravar e executar) e o estado do inicializador (usuário ou supervisor e modo seguro ou inseguro). A configuração em tempo de execução da parte programável da DPU é gerenciada por uma unidade central, chamada de NSM
(Network Security Manager). Duas soluções foram apresentadas, configurando a DPU na origem, chamado de DPU@INI (DPU at Initiator NI), e no alvo, chamado de DPU@TNI (DPU at Target NI). A solução foi implementada por prototipação usando processador ARM920T e uma memória de 16Kb SRAM, usando as ferramentas Synopsys Design Compiler e Prime Power com a biblioteca da tecnologia 0.13µm HCMOS9GPHS da STMicroelectronics. Os experimentos de avaliação foram realizados analisando o consumo de energia, o sobrecusto de área e o atraso do caminho crítico para dois tipos de implementação, DPU@INI e DPU@TNI. Os resultados mostraram que a implementação da DPU tem um sobrecusto de 17% de área e de 7,5% de energia, sem impactar significativamente no desempenho do sistema.
Fiorin, Palermo e Silvano (2008) propuseram uma solução para evitar extração de dados sensíveis e ataques de DoS. O mecanismo proposto foi de um sistema de monitoração baseado na arquitetura NoC para detectar violações de segurança contra a NoC. Informações coletadas na interface dos núcleos são enviadas a uma unidade central (NSM - Network Security Manager) para eficientemente neutralizar ações exercidas pelo atacante. A arquitetura possui dois tipos de sondas (probes): (i) Illegal Access Probe (IAP), para detectar tentativas não autorizadas de acesso a locais de memória, e (ii) Denial-of-Service Probe (DoSP), que detecta um comportamento não natural de tráfego. A solução foi implementada por prototipação usando a tecnologia 0.13µm HCMOS9GPHS da STMicroelectronics. Os experimentos de avaliação foram realizados avaliando os sobrecustos de área e de energia, comparando com a solução sem o monitoramento de segurança. Os resultados mostraram que a implementação da sonda IAP na NI não é muito significativo (0,02% de sobrecusto de área) e a implementação do DoSP tem um aumento linear conforme a inclusão de configurações de entrada. O sobrecusto total é de 34,7% se comparado com a solução sem a monitoração de segurança.
Patel e Parameswaran (2008a) propuseram uma solução para evitar ataques de injeção de código em MPSoC. O mecanismo proposto foi a implementação de uma arquitetura (denominada LOCS), dividindo o programa em assembly em blocos e adicionando, no inicio de cada bloco, uma instrução de hardware especial, chamada de CHKBLK, com um valor criptografado. Esse valor é formado pelo código único de cada bloco (bId) e com o código único de cada processador. A instrução CHKBLK envia ao processador monitor as informações da execução. O processo monitor supervisiona os processadores de aplicação, analisando o fluxo de cada execução com a tabela de controle de fluxo que foi previamente carregada por scripts automáticos. A solução foi
implementada por prototipação em Xtensa LX2, da Tensilica Inc. Os experimentos de avaliação foram realizados comparando a solução com trabalhos relacionados, usando o benchmark multimedia (JPEG encoder/decoder e MP3). Os resultados mostraram que a implementação possui um sobrecusto muito menor que trabalhos relacionados, como o SHIELD (PATEL;
PARAMESWARAN, 2008b) e SW_MON (PATEL; PARAMESWARAN; SHEE, 2007).
Patel e Parameswaran (2008b) propuseram uma solução de hardware/software (denominada SHIELD) para detectar ataques de injeção de código em MPSoCs. A solução foi implementada usando um processador dedicado que atua como um monitor, e um hardware personalizado no processador de aplicação. A aplicação é previamente executada e com base nesta execução, a aplicação é dividida em blocos, as quais são inseridas duas instruções especiais, uma no inicio do bloco (inform) e outra no final (confirm). Essas instruções ainda levam consigo informações criptografadas de quantos ciclos esta leva para executar e o fluxo. As instruções especiais executam em um hardware personalizado o registro de que o bloco está começando ou finalizando a sua execução e envia essas informação ao processador monitor. O processador monitor analisa essas informações com os valores passados pelas instruções e verifica se houve uma inclusão não devida de código naquele bloco ou se o fluxo não está coerente. A implementação foi por prototipação em um processador Xtensa LX2Os e os experimentos de avaliação foram realizados por um programa de benchmark de codificador JPEG. Os resultados mostraram que a implementação teve sobrecustos de 6,6% no desempenho e de 26,9% na área. A solução se mostrou nove vezes mais rápida que soluções anteriores dos mesmos autores e além de detectar injeção de código, o sistema também possibilitou a detecção de 83% de erros do tipo bit flip (inversão de bit) nas instruções de controle de fluxo.
Abramovici e Bradley (2009) propuseram uma solução para a detecção de ataques Trojan9 em SoC. A solução proposta foi da inclusão de uma unidade lógica (DEFENSE – DEsign For ENabling SEcurity) implementando um monitor de segurança em tempo de execução. O mecanismo proposto é constituído de vários blocos: (i) o SM (Security Monitor), que é um mecanismo programável pelo usuário para verificar propriedades comportamentais dos sinais; (ii) o
9 Trojan, ou Cavalo de Tróia, é um ataque que se utiliza de um software malicioso disfarçado como um software comum e legítimo. A execução do Trojan permite que usuários mal intencionados possam invadir o sistema.
SPN (Signal Probe Networks), que é um multiplexador configurado para selecionar um conjunto de sinais monitorados e transportar ao SMs; e (iii) o SECOPRO (SEcurity and COntrol PROcessor), que reconfigura os SPNs para selecionar os grupos de sinais para serem verificados pelo SMs e reconfigura os SMs para desempenhar os requisitos de checagem. As configurações são criptografadas e armazenadas em memória flash segura. O projetista determina quais são os sinais importantes a serem monitorados e os liga ao SM. O DEFENSE desempenha dois tipos de verificação: (i) conjunto de violações de segurança especificado pelo usuário; e (ii) propriedades para o correto funcionamento do comportamento do sistema. Quando um ataque é detectado, o DEFENSE pode implementar contramedidas ao ataque por sinais específicos, que podem, por exemplo, desabilitar um núcleo suspeito. Porém, essa contramedida precisa ser integrada ao nível de sistema. Os autores não apresentaram informações sobre como a solução foi implementada, avaliada e nem os resultados da implementação.
Patel, Parameswaran e Ragel (2009) propuseram uma solução para detectar ataque de software em MPSoC. O mecanismo proposto foi um ambiente (denominado CUFFS) para detectar ataques de software. Cada aplicação possui um ou dois check-points, os quais possuem uma instrução especial que reporta a um núcleo dedicado, chamado iGuard. Informações estatísticas do controle de fluxo do programa e da quantidade de instruções entre dois check-points sequenciais são criadas durante o processo de compilação e armazenadas no iGuard durante a carga do sistema.
Durante a execução, as aplicações reportam ao iGuard, por meio das instruções especiais, qual bloco de instrução este executará. O iGuard verifica se o controle de fluxo e se a quantidade de instruções são corretos. Se forem, uma interrupção é enviada ao processador para abortar a execução. A solução foi implementada por prototipação usando o processador Xtensa LX2 da Tensilica Inc. Os experimentos de avaliação foram realizados usando três benchmarks multimídia (codificador JPEG e decodificadores MP3 e JPEG). Os resultados mostraram que a implementação tem um sobrecusto de desempenho menor que 1%. Comparado com outra solução, a LOCS – apresentada previamente (PATEL; PARAMESWARAN, 2008), a solução teve um sobrecusto de desempenho e código maior, porém, o consumo de área se mostrou menor.
Porquet, Schwarzt e Greiner (2009) propuseram uma solução de segurança no compartilhamento de memória para SoC. O mecanismo proposto permite que cada aplicação seja seguramente contida em entidades lógicas chamadas “compartment”. O conceito é baseado em duas premissas: (i) identificação, que permite o controle de acesso de cada transação; e (ii) proteção, que
permite o controle de acesso ao “compartment”. A solução é conceitual e ainda não foi implementada e, portanto, não possui resultados.
Sepúlveda, Strum e Chau (2009) propuseram uma solução de níveis de segurança na dimensão de QoS para controle de acesso, autenticação e disponibilidade aos dados. O mecanismo proposto define quatro níveis de segurança para cada serviço, do nível 0 (sem segurança) até 3 (segurança máxima). A solução foi implementada tanto no roteador como na interface de rede, usando o protocolo de comunicação OCP/IP (Open Core Protocol / Intellectual Property). A implementação na interface de rede foi realizada no núcleo escravo. O propósito do serviço de controle de acesso é permitir que somente transações autorizadas sejam feitas. O controle de acesso atua como um firewall. A implementação de diferentes níveis de controle de acesso usa três mecanismos que verificam: (i) a origem do pacote; (ii) o tipo de transação; e (iii) a regra do mestre.
O propósito do serviço de autenticação é garantir a integridade da origem do pacote e também foi implementado verificando: (i) a origem; (ii) o cálculo do caminho; e (iii) o par mestre-escravo. O propósito do serviço de disponibilidade é garantir que um recurso da rede pode ser utilizado quando requerido. A implementação foi realizada da seguinte forma: (i) implementando canais virtuais; (ii) modificando a arbitragem; e (iii) adotando um chaveamento híbrido (baseado em circuitos e em pacotes). Os experimentos de avaliação foram realizados por ambiente de simulação SystemC- TLM. Para efeito de comparação, foram implementados os três mecanismos, tanto no roteador quanto na interface de rede do núcleo escravo, usando uma NoC com topologia malha 2-D 4x4 e alterando os níveis de segurança de cada mecanismo. Os resultados mostraram que a implementação no roteador é mais eficiente do que na interface de rede. A implementação de controle de acesso e autenticação aumentam o consumo de energia e a latência, sendo que somente no serviço de disponibilidade é que essas métricas são reduzidas devido ao uso do mecanismo de chaveamento híbrido.
Stefan e Goossens (2009) propuseram uma solução para a extração de dados durante a comunicação entre núcleos em uma NoC. O mecanismo proposto baseia-se no uso de caminhos alternativos (determinístico) ou randômicos (não determinístico) para enviar os dados entre os núcleos, dificultando a extração de dados, caso um atacante consiga “escutar” um dos barramentos.
A solução foi implementada alterando a interface de rede de uma NoC Æthereal (GOOSSENS;
DIELISSEN; RADULESCU, 2005). Os resultados mostraram que a implementação do algoritmo
não determinístico protege a NoC contra o ataque, mas com a penalidade da alta utilização dos recursos da rede.
Huffmire et al. (2010) propuseram uma solução para a comunicação entre núcleos de um sistema embarcado por meio do conceito de fossos e pontes levadiças. Os fossos separam fisicamente (ou logicamente) os núcleos, enquanto que as pontes levadiças permitem controlar a interação entre os núcleos. O mecanismo proposto implementa dois tipos de fossos: (i) um com
“áreas mortas” (gap) e outro (ii) com separação lógica entre os núcleos através de técnicas de roteamento. A solução foi implementada com prototipação em FPGA e os experimentos de avaliação foram realizados usando o benchmark MCNC (Microelectronics Center of North Carolina). Os resultados mostraram que a área dos fossos no projeto é mínima, no pior dos casos é de 2,61% e no melhor dos casos é de 1,05%. Em fossos grandes, o período de clock é melhor, porém requerem maiores áreas.
Lukovic e Christianos (2010) propuseram uma solução de segurança em diferentes níveis, monitorando a execução da aplicação e validando se o comportamento é correto. A solução pode integrar vários tipos de abordagem de segurança para proteção a ataques específicos. O mecanismo proposto foi implementado em uma estrutura hierárquica de agentes de segurança. Os quatro tipos de agentes são: (i) agente especifico de ataque (ASA – Attack Specific Agent); (ii) agente de segurança local (LSA – Local Security Agent); (iii) agente de segurança do cluster (CLSA – Cluster Security Agent); e (iv) agente de segurança central (CSA – Central Security Agent). A solução foi implementada e verificada usando o FPGA Virtex-II Pro da Xilinx para ataques contra buffer overflow por intermédio da injeção de código. Os experimentos de avaliação também foram realizados por prototipação e os resultados mostraram que a implementação ocupa 68% do projeto e o PPS (Processor Protection System) é o componente que mais consome área, representando 77%
do projeto. Não foram verificados o sobrecusto de energia e o impacto na latência.
Sepúlveda, Strum e Chau (2010) apresentaram o uso de uma técnica de chaveamento híbrida em uma NoC combinando chaveamento por circuito com chaveamento por pacotes para evitar ataques de negação de serviços (DoS – Denial-of-Service) e garantir disponibilidade para tráfego de informações críticas sem reserva de recursos. No mecanismo proposto, as mensagens são classificadas por políticas de segurança como críticas ou não-críticas. As primeiras são transferidas utilizando-se chaveamento por circuito, enquanto que as últimas são transferidas com o uso de chaveamento por pacotes. As políticas de segurança foram implementadas adicionando
funcionalidades ao roteador e alterando alguns parâmetros nas configurações locais da NoC. Os experimentos de avaliação foram realizados com o uso de um ambiente de simulação SystemC- TLM (Transaction Level Modeling). Para efeito de comparação, foram implementadas quatro NoCs com topologia em malha 2-D 4x4: (i) NoC com chaveamento por pacote com reserva de canais virtuais; (ii) NoC com técnica de chaveamento por circuito; (iii) NoC com técnica TDM (Time- Division Multiplexing); e (iv) NoC com chaveamento híbrido (circuito e pacotes). Foram avaliados o impacto na eficiência e o desempenho das quatro implementações, variando o total de dados críticos de 30%, 50% e 70% do total do tráfego. Os resultados demonstraram que o mecanismo proposto evita contenção na rede, reservando recursos para mensagens críticas sem negar serviço de comunicação às mensagens não-críticas. A avaliação mostrou a eficiência de 98% de garantia contra ataques DoS. O consumo de energia e a latência na rede melhoraram até 62% e 55%, respectivamente, quando comparados com os da NoC de melhor esforço.
Lázaro et al. (2011) propuseram uma solução para comunicação segura entre chips usando a implementação de criptografia e autenticação AES-GCM (Advanced Encryption Standard - Galois/Counter Mode) em cima do padrão de comunicação I2C (Inter-Integrated Circuit). O mecanismo proposto (I2CSec – Inter Integrated Circuits Security) inclui criptografia e autenticação, AES-GCM, no protocolo. A solução foi implementada em FPGA, usando os processadores MicroBlaze10 para o mestre e o PicoBlaze11 para os escravos. Os experimentos de avaliação foram realizados por prototipação em FPGA e os resultados mostraram que a implementação no núcleo mestre utilizou 50% dos recursos, possuindo espaço suficiente para a implementação de aplicações específicas no mesmo núcleo. Já a implementação no núcleo escravo ocupou 75% da área, permitindo a implementação somente de aplicações mais modestas. A comparação com outras soluções relacionadas mostraram que é necessário um núcleo específico para a implementação de segurança ou que o processador utilizado no núcleo escravo maior que o PicoBlaze. Para trabalhos futuros, segundo os autores, o protocolo poderá suportar núcleos com sinais mistos e também melhorar o protocolo com a inclusão de um protocolo de troca de chave.
10 MicroBlaze é um microcontrolador de arquitetura RISC Harvard de 32-bit com conjunto de instruções otimizadas para aplicações embarcadas.
11 O PicoBlaze é um microcontrolador de arquitetura RISC de 8 bits compacto.