SIDNEI BARON
SEGURANÇA EM REDES-EM-CHIP:
MECANISMOS PARA PROTEGER A REDE SOCIN CONTRA
ATAQUES DE NEGAÇÃO DE SERVIÇO
Itajaí (SC), fevereiro de 2013
UNIVERSIDADE DO VALE DO ITAJAÍ
CURSO DE MESTRADO ACADÊMICO EM
COMPUTAÇÃO APLICADA
SEGURANÇA EM REDES-EM-CHIP:
MECANISMOS PARA PROTEGER A REDE SOCIN CONTRA
ATAQUES DE NEGAÇÃO DE SERVIÇO
por
Sidnei Baron
Dissertação apresentada como requisito parcial à
obtenção do grau de Mestre em Computação
Aplicada.
Orientador: Cesar Albenes Zeferino, Dr.
Co-Orientadora: Michelle Silva Wangham, Dra.
Itajaí (SC), fevereiro de 2013
SEGURANÇA EM REDES-EM-CHIP:
MECANISMOS PARA PROTEGER A REDE SOCIN CONTRA
ATAQUES DE NEGAÇÃO DE SERVIÇO
Sidnei Baron
Fevereiro / 2013
Orientador: Cesar Albenes Zeferino, Dr.
Co-Orientadora: Michelle Silva Wangham, Dra.
Área de Concentração: Computação Aplicada
Linha de Pesquisa: Sistemas Embarcados e Distribuídos
Palavras-chave: Redes-em-Chip, Segurança, Negação de Serviço.
Número de páginas: 117
RESUMO
Com o aumento do número de núcleos em um único chip, a escalabilidade de comunicação e a
largura de banda tornaram-se fatores críticos importantes. Para atender essas necessidades, as redes
de intercomunicação chaveadas estão substituindo os barramentos e canais ponto-a-ponto na
comunicação entre os núcleos de um sistema integrado (SoC – System-on-Chip). Essas redes são
denominadas Redes-em-Chip ou NoCs (Networks-on-Chip). Assim como sistemas distribuídos
tradicionais, um SoC e sua rede são suscetíveis a ataques as suas propriedades de segurança. Por
exemplo, ataques do tipo Negação de Serviço (DoS – Denial-of-Service) podem comprometer a
disponibilidade da rede, ou seja, sua capacidade de realizar as comunicações entre os componentes
do sistema. Neste contexto, este trabalho teve como objetivo investigar soluções para provimento
de segurança em NoCs utilizando como referência a rede SoCIN (SoC Interconnection Network).
Foram propostos mecanismos para proteger essa rede contra ataques de DoS, os quais foram
implementados como componentes de hardware, na forma de wrappers, que realizam a filtragem
dos fluxos de comunicação injetados na rede, descartando pacotes que comprometam a sua
disponibilidade ou regulando a taxa de injeção de fluxos que pretendam consumir uma largura de
banda maior do que a que foi prevista pelo projetista do SoC. Os resultados obtidos demonstraram
que a implementação em hardware da solução proposta é viável, apresenta baixo impacto no
desempenho da rede e um pequeno sobrecusto de área de silício.
NETWORKS-ON-CHIP SECURITY:
MECHANISMS TO PROTECT SOCIN NOC AGAINST
DENIAL-OF-SERVICE ATTACKS
Sidnei Baron
February / 2013
Advisor: Cesar Albenes Zeferino, Dr.
Co-Advisor: Michelle Silva Wangham, Dra.
Area of Concentration: Applied Computer Science
Research Line: Embedded and Distributed Systems
Keywords: Network-on-Chip, Security, Denial-of-Service.
Number of pages: 117
ABSTRACT
With the increasing in the number of cores on a single chip, the communication scalability and
bandwidth have become critically important. To meet these needs, switching networks are replacing
shared busses and point-to-point channels as interconnection architecture of SoCs (Systems-onchip). These networks are called Networks-on-Chip or NoCs. Like traditional distributed systems, a
SoC and its network are susceptible to attacks on their security properties. For example, attacks
like Denial-of-Service (DoS) can compromise network availability (i.e. the ability to perform
communications between system components). On this context, this work had as objective
investigates solutions for providing security on NoCs using as reference the SoCIN (SoC Network
Interconnection) NoC. Mechanisms were proposed to protect the network against DoS attacks.
These mechanisms were implemented as hardware-based wrappers that filter the communication
flows injected into the network by the cores, discarding packets that affect its availability, or
regulate the injection rate of flows that try to consume a bandwidth higher than the one that was
specified by the SoC designer. The obtained results demonstrated that the hardware implementation
of the proposed solution is feasible. The implemented solution presented a low impact on the NoC
performance and a reduced silicon overhead.
LISTA DE ILUSTRAÇÕES
Figura 1. Exemplos de topologia: (a) crossbar; (b) grelha 2-D; (c) toróide 2-D; (d) hipercubo 3-D 19
Figura 2. Componentes de uma NoC: enlace, roteador e interface de rede (NI) ............................... 20
Figura 3. Mensagem, Pacote, Flit e Phit ............................................................................................ 23
Figura 4. Roteador com quatro buffers: (a) FIFO, (b) SAFC; (c) SAMQ; (d) DAMQ ..................... 29
Figura 5. Abordagens para implementação de árbitros: (a) centralizada; (b) distribuída .................. 31
Figura 6. Gráfico com a relação dos ataques abordados .................................................................... 48
Figura 7. Gráfico com a relação de propriedade de segurança tratado .............................................. 50
Figura 8. Gráfico com a relação dos mecanismos de segurança adotados ........................................ 52
Figura 9. Gráfico com a relação de componentes utilizados ............................................................. 54
Figura 10. As duas topologias da SoCIN: (a) grelha e (b) toróide..................................................... 58
Figura 11. Enlace da SoCIN .............................................................................................................. 60
Figura 12. Sistema de coordenadas da SoCINfp ................................................................................ 60
Figura 13. Formato do pacote e bits de informação roteamento da SoCIN ....................................... 61
Figura 14. Interfaces do ParIS ............................................................................................................ 63
Figura 15. Organização do ParIS ....................................................................................................... 63
Figura 16. Geração do simulador SystemC do BrownPepper ........................................................... 66
Figura 17. Implementação do mecanismo de segurança na rede SoCIN ........................................... 73
Figura 18. Detalhamento do componente SEW ................................................................................. 74
Figura 19. Diagrama de bloco do wrapper que detecta ataque de endereçamento ............................ 75
Figura 20. FSM do wrapper que detecta ataque de endereçamento .................................................. 77
Figura 21. Circuito digital do wrapper que detecta ataque de endereçamento .................................. 78
Figura 22. Circuito digital do wrapper de controle de banda ............................................................ 79
Figura 23. Diagrama da FSM do controle de banda .......................................................................... 81
Figura 24. Circuito digital do bloco COUNT .................................................................................... 82
Figura 25. Circuito digital do bloco CALC ....................................................................................... 83
Figura 26. Diagrama RTL do Wrapper 1 ........................................................................................... 85
Figura 27. Diagrama RTL da estrutura interna do bloco Attack Detector ......................................... 86
Figura 28. Diagrama RTL do Wrapper 2 ........................................................................................... 86
Figura 29. Diagrama RTL do bloco COUNT .................................................................................... 87
Figura 30. Diagrama RTL do bloco CALC ....................................................................................... 88
Figura 31. Bloco testbench e o bloco SEW ....................................................................................... 92
Figura 32. Envio de um pacote sem ataque - VHDL ......................................................................... 93
Figura 33. Envio de um ataque a um endereço de destino X maior que ao tamanho da rede ........... 93
Figura 34. Envio de um ataque a um endereço de destino Y maior que ao tamanho da rede ........... 94
Figura 35. Envio de um ataque com endereço de destino ao próprio o núcleo de origem ................ 94
Figura 36. Envio de um ataque com a posição de origem X diferente do endereço do núcleo ......... 95
Figura 37. Envio de um ataque com a posição de origem Y diferente do endereço do núcleo ......... 95
Figura 38. Envio de um ataque com número de flits maior do que o permitido................................ 96
Figura 39. Envio de vários pacotes sem intervalo com 100% da largura de banda ........................... 97
Figura 40. Envio de vários pacotes sem intervalo com 11% da largura de banda ............................. 97
Figura 41. Envio de vários pacotes sem intervalo com 20% da largura de banda ............................. 98
Figura 42. Envio de vários pacotes sem intervalo com 33% da largura de banda ............................. 98
Figura 43. Envio de vários pacotes sem intervalo com 50% da largura de banda ............................. 98
Figura 44. Envio de vários pacotes sem intervalo com 67% da largura de banda ............................. 98
Figura 45. Envio de vários pacotes sem intervalo com 80% da largura de banda ............................. 99
Figura 46. Envio de vários pacotes sem intervalo com 89% da largura de banda ............................. 99
Figura 47. Diagrama da NoC 3x3 utilizada nos experimentos em SystemC ................................... 100
Figura 48. Envio de um pacote sem ataque – SystemC ................................................................... 100
Figura 49. Envio de um ataque a um endereço de destino X maior que ao tamanho da rede –
SystemC ................................................................................................................................... 101
Figura 50. Envio de um ataque a um endereço de destino Y maior que ao tamanho da rede –
SystemC ................................................................................................................................... 101
Figura 51. Envio de um ataque com endereço de destino ao próprio o núcleo de origem – SystemC
.................................................................................................................................................. 102
Figura 52. Envio de um ataque com a posição de origem X diferente do endereço do núcleo –
SystemC ................................................................................................................................... 102
Figura 53. Envio de um ataque com a posição de origem Y diferente do endereço do núcleo –
SystemC ................................................................................................................................... 103
Figura 54. Envio de um ataque com número de flits maior do que o permitido – SystemC ........... 103
Figura 55. Envio de vários pacotes sem intervalo com largura de banda alocada de 50% – SystemC
.................................................................................................................................................. 104
Quadro 1. Classificação dos algoritmos de roteamento ..................................................................... 30
Quadro 2. Ataques tratados nos trabalhos relacionados .................................................................... 47
Quadro 3. Propriedades de segurança tratadas nos trabalhos relacionados ....................................... 49
Quadro 4. Mecanismos adotados nos trabalhos relacionados ............................................................ 51
Quadro 5. Componentes utilizados nos trabalhos analisados ............................................................ 53
Quadro 6. Posicionamento deste trabalho com os trabalhos analisados ............................................ 55
Quadro 7. Relação de possíveis ataques a NoC ................................................................................. 67
Quadro 8. Vulnerabilidade da rede SoCIN a possíveis ataques e soluções de segurança ................. 70
Quadro 9. Tabela-verdade que descreve a função para detectar ataque de endereçamento .............. 76
Quadro 10. Tabela-verdade que descreve a função do contador do bloco COUNT .......................... 81
Quadro 11. Seleção de largura de banda alocada............................................................................... 83
Quadro 12. Ataques modelados para o experimento ......................................................................... 92
Quadro 13. Ataques modelados para o experimento ....................................................................... 104
LISTA DE ABREVIATURAS E SIGLAS
ACM
AES-GSM
APU
ASA
ATG
BOP
CID
CLSA
CPM
CSA
DAMQ
DEFENSE
DoS
DoSP
DPU
DSP
EOP
FIFO
FLIT
GUI
HLP
HOL
I2C
I2CSEC
IAP
IC
IDS
IFC
IP
IP
IRQ
IRS
FCFS
FPGA
LRS
LSA
MCA
MCNC
NSM
MPSoC
NI
NoC
OC
OCN
OCP
Association for Computing Machinery
Advanced Encryption Standard - Galois/Counter Mode
Address Protection Unit
Attack Specific Agent
Attacker Traffic Generator
Begin-of-Packet
Comportment Identifier
Cluster Security Agent
Crosspoint Matrix
Central Security Agent
Dynamically-Allocated, Multi-Queue
Design for Enabling Security
Denial-of-Service
Denial-of-Service Probe
Data Protector Unit
Digital Signal Processor
End-of-Packet
First-In First-Out
Flow Control Unit
Graphical User Interface
Higher Level Protocol
Head-of-Line
Inter-Integrated Circuit
Inter-Integrated Circuit Security
Illegal Access Probe
Input Controller
Intrusion Detection System
Input Flow Controller
Intellectual Property
Internet Protocol
Interrupt Request Line
Input Read Switch
First-Come-First-Served
Field-Programmable Gate Array
Least Recently Served
Local Security Agent
Mestrado em Computação Aplicada
Microelectronics Center of North Carolina
Network Security Manager
Multiprocessor System-on-Chip
Network Interface
Network-on-Chip
Output Controller
On-chip Network
Open Core Protocol
ODS
OFC
OWS
ParIS
PHIT
PPS
QoS
RASoC
RET
RIB
RTL
SAFC
SAMQ
SECOPRO
SEW
SM
SOC
SoCIN
SoCINfp
SPN
SRAM
TDM
TG
TL
TM
TLM
UNIVALI
VAL
VC
VCI
VHDL
VHSIC
Output Data Switch
Output Flow Controller
Output Write Switch
Parameterizable Interconnect Switch
Physical Unit
Processor Protection System
Quality of Service
Router Architecture for SoC
Return Signal
Routing Information Bits
Register Transfer Level
Statically Allocated, Fully Connected
Statically Allocated Multi-Queue
Security and Control Processor
Security Wrapper
Security Monitor
System-on-Chip
SoC Interconnection Network
SoC Interconnection Network fully parameterizable
Signal Probe Networks
Static Random Access Memory
Time-division multiplexing
Traffic Generator
Transaction Level
Traffic Measurer
Transaction Level Modeling
Universidade do Vale do Itajaí
Validation
Virtual Channel
Virtual Component Interface
VHSIC Hardware Description Language
Very High Speed Integrated Circuits
SUMÁRIO
1 INTRODUÇÃO.................................................................................... 10
1.1 CONTEXTUALIZAÇÃO ................................................................................. 10
1.2 PROBLEMA DE PESQUISA........................................................................... 12
1.2.1 Solução Proposta ............................................................................................. 13
1.2.2 Delimitação de Escopo .................................................................................... 14
1.3 OBJETIVOS ...................................................................................................... 14
1.3.1 Objetivo Geral ................................................................................................. 14
1.3.2 Objetivos Específicos ...................................................................................... 14
1.4 METODOLOGIA .............................................................................................. 14
1.4.1 Metodologia da Pesquisa ................................................................................ 15
1.4.2 Procedimentos Metodológicos........................................................................ 15
1.5 ESTRUTURA DO DOCUMENTO.................................................................. 16
2 FUNDAMENTAÇÃO TEÓRICA ...................................................... 17
2.1 REDES-EM-CHIP ............................................................................................. 17
2.1.1 Arquitetura de NoC ........................................................................................ 17
2.1.2 Controle de fluxo e chaveamento................................................................... 22
2.1.3 Memorização ................................................................................................... 27
2.1.4 Roteamento ...................................................................................................... 29
2.1.5 Arbitragem....................................................................................................... 31
2.2 SEGURANÇA EM SISTEMAS COMPUTACIONAIS ................................ 32
2.2.1 Ataque à segurança ......................................................................................... 33
2.2.2 Mecanismos de segurança .............................................................................. 35
2.3 CONSIDERAÇÕES .......................................................................................... 35
3 SEGURANÇA EM REDES-EM-CHIP ............................................. 37
3.1
3.2
3.3
3.4
TRABALHOS RELACIONADOS E O ESTADO DA ARTE ...................... 37
ANÁLISE COMPARATIVA............................................................................ 46
POSICIONAMENTO DESTE TRABALHO ................................................. 54
CONSIDERAÇÕES .......................................................................................... 56
4 ADICIONANDO SEGURANÇA À REDE SOCIN ......................... 57
4.1 REDE SOCIN..................................................................................................... 57
4.1.1 Arquitetura da rede SoCIN............................................................................ 58
4.1.2 Arquitetura do roteador ParIS ...................................................................... 62
4.1.3 BrownPepper ................................................................................................... 65
4.2 VULNERABILIDADES DA REDE SOCIN ................................................... 66
4.2.1 Definição dos ataques...................................................................................... 66
4.2.2 Análise das vulnerabilidades da SoCIN ........................................................ 68
4.3 SELEÇÃO DE ATAQUES E PREMISSAS DE PROJETO ......................... 71
4.4 PROTEGENDO A REDE SOCIN CONTRA ATAQUES DE DOS ............ 73
4.4.1 Controle de endereço origem e destino – Wrapper 1 .................................. 74
4.4.2 Controle de banda – Wrapper 2 .................................................................... 78
4.5 CONSIDERAÇÕES .......................................................................................... 84
5 IMPLEMENTAÇÃO E AVALIAçÃO .............................................. 85
5.1 IMPLEMENTAÇÃO EM VHDL .................................................................... 85
5.1.1 Diagramas RTL do Wrapper 1 ...................................................................... 85
5.1.2 Diagramas RTL do Wrapper 2 ...................................................................... 86
5.1.3 Resultados de síntese ....................................................................................... 88
5.1.4 Verificação baseada em simulação ................................................................ 91
5.2 IMPLEMENTAÇÃO EM SYSTEMC ............................................................ 99
5.2.1 Simulação ....................................................................................................... 100
5.3 ANÁLISE DA TAXA DE COBERTURA ..................................................... 104
6 CONCLUSÕES .................................................................................. 105
6.1 CONTRIBUIÇÃO DA DISSERTAÇÃO ...................................................... 106
6.2 TRABALHOS FUTUROS .............................................................................. 106
REFERÊNCIAS ..................................................................................... 108
APÊNDICE A – REVISÃO SISTEMÁTICA ..................................... 113
10
1 INTRODUÇÃO
1.1 CONTEXTUALIZAÇÃO
Com o advento dos processos submicrônicos1, a capacidade de integração de transistores
tem atingido níveis que possibilitam a construção de um sistema completo em uma única pastilha de
silício. Esses sistemas, denominados sistemas integrados ou SoCs (System-on-Chip), baseiam-se no
reuso de blocos previamente projetados e verificados, os quais são chamados de núcleos ou blocos
de propriedade intelectual (IP – Intelectual Property) (MARTIN; CHANG, 2003). A reusabilidade2
é um requisito crucial no projeto de sistemas eletrônicos para lidar com o aumento da complexidade
dos sistemas e com a redução do tempo disponível para colocação de um novo produto no mercado,
conhecido pela expressão time-to-market.
Segundo Jerger e Peh (2009), a busca pela diminuição do consumo de energia e o aumento
no desempenho fizeram impulsionar o advento de sistemas integrados com múltiplos núcleos
(multi-core). Nos últimos anos, várias indústrias produziram sistemas multi-core com um número
elevado de núcleos, permitindo que um único chip possua centenas a milhares de núcleos
integrados. Essa integração em um único chip, chamado de MPSoCs (Multiprocessor System-onChip), permitiu a adição de vários componentes, incluindo núcleos de processadores, memória
embarcada e aceleradores como os módulos DSP (Digital Signal Processor) e processadores
especializados como vídeo, áudio, comunicação, etc.
Tradicionalmente, os núcleos de um SoC são interconectados por meio de arquiteturas de
comunicação baseadas em canais ponto-a-ponto dedicados ou canais multiponto compartilhados
(também denominados barramentos). Conforme observado por Zeferino (2003), as arquiteturas em
barramento foram preferidas pelo fato de serem reutilizáveis, mesmo apresentando desempenho
inferior às arquiteturas baseadas em canais ponto-a-ponto.
1
Submicrônico – Com dimensão inferior ao micrometro (milionésima parte do metro).
2
Reusabilidade – O reuso de múltiplas cópias dos componentes pré-existentes em vários sistemas e com novas
configurações.
11
Com o aumento do número de núcleos em um único chip, a necessidade crescente
(escalabilidade) de comunicação e de largura de banda se tornaram criticamente importantes, sendo
que o barramento não oferece desempenho escalável. Para suprir essa necessidade de escalabilidade
e largura de banda, as redes de intercomunicação chaveadas estão substituindo os barramentos e
canais ponto-a-ponto na comunicação entre os núcleos de um sistema integrado (JERGER; PEH,
2009). Essas redes são denominadas Redes-em-Chip ou NoCs (Networks-on-Chip).
Exemplos de NoCs descritas na literatura incluem a SPIN (ADRIAHANTENAINA et al.,
2003), a Æthereal (GOOSSENS; DIELISSEN ; RADULESCU, 2005), a QNOC (BOLOTIN et al.,
2004), a xPipes (BERTOZZI; BENINI, 2004) e a SoCIN (ZEFERINO; SUSIN, 2003).
Como exemplo de NoC desenvolvida no meio acadêmico, pode ser citada a rede SoCIN –
System-on-Chip Interconnection Network, utilizada nesta dissertação. A SoCIN é uma NoC
parametrizável que utiliza uma topologia em malha 2-D e oferece técnicas alternativas para os
mecanismos de comunicação da rede (controle de fluxo, chaveamento, memorização, roteamento e
arbitragem) (ZEFERINO; SUSIN, 2003). Essa rede é utilizada como plataforma de referência nas
diversas pesquisas sobre NoCs realizadas no âmbito do Laboratório de Sistemas Embarcados e
Distribuídos da Universidade do Vale do Itajaí (UNIVALI), grupo de pesquisa no qual este trabalho
está inserido.
Um exemplo industrial de uso de NoC é o SoC apresentado pela Intel (HOSKOTE et al.,
2007) que implementa um multiprocessador em um único chip com 80 núcleos interconectados por
uma NoC em malha 2-D. Esse chip é constituído por blocos (ou tiles) e cada bloco possui um
roteador e unidades de processamento (FPMAC 0 e 1), memória (DMEM e IMEM) e outros. Esse
multiprocessador opera a uma frequência de relógio de 5 GHz e atinge um desempenho superior a
um TeraFLOP.
A preocupação com segurança da computação é um fator significativo no desenvolvimento e
na aplicação dos sistemas computacionais em toda a sociedade. Para um sistema ser seguro, cinco
propriedades de segurança devem ser garantidas: (i) Confidencialidade; (ii) Integridade; (iii)
Disponibilidade; (iv) Autenticidade; e (v) Não-repúdio (LANDWEHR, 2001). Por exemplo, a
propriedade de segurança de disponibilidade, foco deste trabalho, assegura que uma informação (ou
recurso) estará acessível para os usuários autorizados sempre que requisitada. Um ataque à
segurança pode ser definido como qualquer ação que comprometa a segurança da informação. Um
12
mecanismo de segurança é um processo projetado para detectar, impedir ou permitir a recuperação
de um ataque à segurança (STALLINGS, 2008).
Como todos os sistemas computacionais, um SoC (seja este baseado em barramento ou
NoC) também é alvo de ataques de segurança. Por exemplo, os invasores podem tentar extrair
alguma informação do sistema com o objetivo de obter dados pessoais dos seus usuários ou para
ignorar algumas licenças de uso de algum software executado pelo sistema. Outro ataque pode ter
por objetivo degradar o desempenho do sistema por meio de ações que levem à negação de serviços
dentro do SoC (este tipo de ataque, no âmbito das NoCs, é o foco desta dissertação).
Em um SoC que utilize uma NoC como infraestrutura de comunicação, a NoC é o coração
do sistema, pois gerencia todas as comunicações, e é por isso que os ataques contra NoC são
críticos. (TEXIER, 2009). Através da implementação mecanismos de segurança nos componentes
da NoC é possível bloquear ataques de uma tarefa (atacante) a outra (vítima) (SEPULVEDA;
STRUM; CHAU, 2009).
O aspecto de segurança em NoCs tem sido um dos alvos de estudos mais recentes dos grupos
de pesquisa. Para Fiorin, Palermo e Silvano (2008), a complexa comunicação das NoCs pode trazer
novas deficiências ao sistema que pode ser crítico e deve ser cuidadosamente estudado e avaliado.
Por outro lado, as NoCs podem contribuir para a segurança do sistema, fornecendo um meio ideal
para monitorar o comportamento do sistema e detectar ataques específicos. Dentro deste contexto,
este trabalho procura fazer uma contribuição na área de Segurança em NoC, conforme discutido na
seção a seguir.
1.2 PROBLEMA DE PESQUISA
Conforme apresentado anteriormente, os ataques podem levar ao comprometimento das
funcionalidades das NoCs e, para uma NoC ser segura, as propriedades de segurança precisam ser
garantidas. A rede SoCIN é uma NoC que foi desenvolvida sem levar em conta essas questões e não
possui mecanismos que garantam as propriedades de segurança. Portanto, um sistema que a utilize é
suscetível a ataques à segurança do sistema.
Dentre os diferente ataques, como já citado, a rede SoCIN é especialmente suscetível aos
ataques de negação de serviço que visem reduzir a disponibilidade do sistema. Isso pode ser feito de
13
diferentes maneiras, como, por exemplo, pelo envio de um pacote a um endereço de rede
inexistente. O pacote fica bloqueado em uma das extremidades (fronteira) da rede, ocupando
recursos necessários a outros pacotes que também são bloqueados e assim sucessivamente, podendo
levar à paralisação de todas as comunicações na rede. Com isso, o roteador e o acesso aos serviços
providos pelo núcleo são comprometidos (negação de serviço), dado que a rede não consegue
realizar a comunicação entre os núcleos.
Neste contexto, este trabalho busca tratar o problema da vulnerabilidade da rede SoCIN a
ataques de negação de serviço com o objetivo de assegurar maior disponibilidade da rede. Em
especial, busca-se responder os seguintes questionamentos:
1. É possível garantir a propriedade de disponibilidade da rede SoCIN implementando
mecanismos para provimento de segurança?
2. Qual é o impacto da implementação de mecanismos para provimento de segurança no
desempenho da rede SoCIN?
3. Qual é o impacto da implementação de mecanismos para provimento de segurança no
custo (área) da rede SoCIN?
1.2.1 Solução Proposta
A solução proposta neste trabalho para responder às perguntas de pesquisa apresentadas
anteriormente consiste em analisar, selecionar e implementar mecanismos de segurança na NoC
SoCIN para impedir ataques de negação de serviço contra a disponibilidade da rede e avaliar o
impacto desses mecanismos no desempenho e no custo de silício.
Como hipótese, têm-se as seguintes afirmações:

A implementação de segurança aumenta a disponibilidade na NoC, mas degrada o seu
desempenho;

A implementação de segurança aumenta a disponibilidade na NoC, mas adiciona um
sobrecusto de área de silício.
14
1.2.2 Delimitação de Escopo
Neste trabalho, foram implementados mecanismos de segurança para garantir a propriedade
de disponibilidade da rede SoCIN. Não foi realizada a implementação em outras NoCs ou a
implementação de mecanismos contra ataques a outras propriedades de segurança.
1.3 OBJETIVOS
1.3.1 Objetivo Geral
Aumentar a disponibilidade da rede SoCIN por meio da implementação de soluções de
segurança.
1.3.2 Objetivos Específicos
1. Identificar as principais vulnerabilidades de segurança na rede SoCIN quanto à propriedade
de disponibilidade;
2. Melhorar a disponibilidade da rede SoCIN com a implementação
de mecanismos de
segurança; e
3. Analisar o impacto dos mecanismos de segurança implementados no desempenho e no custo
da rede.
O desempenho compreende a latência, ou seja, o atraso de tempo (em ciclos de relógio),
adicionada para injetar um pacote a rede e a frequência máxima de operação do mecanismo. O
custo da rede compreende a área de silício ocupada, a potência dissipada e a quantidade de circuitos
combinacionais, sequenciais e/ou de portas lógicas utilizadas.
1.4 METODOLOGIA
Nesta seção, serão apresentadas a metodologia de pesquisa e os procedimentos
metodológicos adotados nesta pesquisa.
15
1.4.1 Metodologia da Pesquisa
Neste trabalho, é utilizado o método hipotético-dedutivo, já que o trabalho parte de um
problema e segue para a obtenção da sua solução por meio da verificação de hipóteses (LAKATOS;
MARCONI, 2000). Segundo Gil (2002), a pesquisa é de natureza aplicada, pois tem como objetivo
investigar, comprovar ou rejeitar as hipóteses apresentadas na solução proposta.
Com relação ao ponto de vista da forma de abordagem do problema, este trabalho enquadra-se
como uma pesquisa quantitativa e qualitativa (LAKATOS; MARCONI, 2000). Quantitativa pelo
fato de que os resultados obtidos através dos experimentos serão classificados e analisados por
técnicas estatísticas, por exemplo, a análise do desempenho do sistema após a implementação da
solução. Já a classificação qualitativa se deve ao fato de que será feita uma análise descritiva sobre
garantia da propriedade de disponibilidade implementada.
No ponto de vista de seus objetivos, esse trabalho se enquadra em uma pesquisa exploratória
(LAKATOS ; MARCONI, 2000), pois visa investigar o tema de segurança em NoCs por meio de
levantamentos bibliográficos e de trabalhos correlacionados.
1.4.2 Procedimentos Metodológicos
Esta seção descreve os procedimentos adotados no desenvolvimento deste trabalho. Na
primeira fase, foi adotado o procedimento técnico de pesquisa bibliográfica para realizar a
fundamentação teórica que aborda a área de NoCs e de segurança de sistemas. Na segunda fase, foi
realizado um levantamento bibliográfico exaustivo, analisando na literatura (livros, artigos, teses e
dissertações) trabalhos correlatos que tratassem da questão do provimento de segurança em NoCs,
documentando-se o resultado da pesquisa. Esses trabalhos foram selecionados e analisados por
meio de critérios definidos na revisão sistemática, cujo protocolo de busca é apresentado em
apêndice (Apêndice A). Na terceira fase, foi modelada a solução selecionada para garantir a
propriedade de disponibilidade na rede SoCIN. Esta solução foi então implementada utilizando-se
as linguagens VHDL (VHSIC Hardware Description Language) e SystemC visando confirmar a
viabilidade de implementação física das técnicas selecionadas, medir o custo de silício dessas
técnicas e avaliar a efetividade dos circuitos implementados.
16
1.5 ESTRUTURA DO DOCUMENTO
O trabalho está organizado em seis capítulos correlacionados. O Capítulo 1, Introdução,
apresentou por meio de sua contextualização o tema proposto neste trabalho. Da mesma forma,
foram estabelecidos os resultados esperados por meio da definição de seus objetivos e apresentadas
as limitações do trabalho, permitindo uma visão clara do escopo proposto. O Capítulo 2 apresenta a
fundamentação teórica sobre NoCs e em segurança em redes computacionais. No Capítulo 3, são
apresentados os trabalhos relacionados e estado da arte sobre segurança em NoCs. Neste capítulo,
também são analisados os trabalhos quanto aos aspectos de segurança. O Capítulo 4 apresenta a
rede SoCIN, suas vulnerabilidades e o projeto dos mecanismos propostos para aumentar a sua
segurança. No Capítulo 5, são apresentados detalhes e resultados da implementação dos
mecanismos utilizando VHDL e SystemC. Por fim, no Capítulo 6, são tecidas as conclusões do
trabalho, relacionando os objetivos identificados inicialmente com os resultados alcançados.
17
2 FUNDAMENTAÇÃO TEÓRICA
Este capítulo apresenta, na Seção 2.1, a fundamentação teórica sobre redes-em-chip e
segurança em redes computacionais na Seção 2.2. Na Seção 2.3, são apresentadas as considerações
sobre o capítulo.
2.1 REDES-EM-CHIP
As denominações mais conhecidas para se referir às redes chaveadas aplicadas à
comunicação intrachip são NoC (Networks-on-Chip, ou redes-em-chip), micronetworks e On-Chip
Networks (OCNs) (ZEFERINO, 2003). Neste texto, será utilizado o termo NoC para se referir a
esta base arquitetural de comunicação.
Um projeto de NoC pode ser especificado pela sua arquitetura e pelos seus mecanismos de
comunicação. A topologia define a estrutura da rede, enquanto que a forma pela qual ocorre a
transferência das mensagens pela rede é definida pelos mecanismos de comunicação. Os
mecanismos de comunicação incluem: controle de fluxo, chaveamento, memorização, roteamento e
arbitragem (ZEFERINO, 2003).
As subseções a seguir discutem aspectos referentes à arquitetura de NoC (incluindo sua
topologia e componentes) e os mecanismos de comunicação.
2.1.1 Arquitetura de NoC
Devido às restrições de custo para integração em um único chip e aos seus requisitos de
desempenho, as soluções arquiteturais adotadas no projeto de NoCs são derivadas daquelas
utilizadas em redes de interconexão para computadores paralelos (ZEFERINO, 2003, p. 27-28).
Os componentes básicos, ou blocos, que constituem uma NoC podem ser organizados
fisicamente de diversas maneiras. Essa organização física, conhecida como topologia, tem como
objetivo a satisfação dos requisitos de comunicação do sistema e em segundo plano pode
aperfeiçoar o custo de área, o consumo de energia e/ou melhorar no desempenho da rede (BENINI;
DE MICHELI, 2006, p. 14).
18
2.1.1.1 Topologias
A topologia de uma NoC determina a organização física e as conexões entre os núcleos e os
canais na rede. Na topologia, é também determinada a quantidade de saltos (roteadores) que a
mensagem deve atravessar para chegar a seu destino (JERGER; PEH, 2009, p. 29).
Segundo Jerger e Peh (2009, p. 29), o custo da complexidade de implementação da
topologia depende de dois fatores principais: (a) quantidade, extensão e largura de enlaces em cada
núcleo; e (b) a facilidade de colocação da topologia em um chip. A quantidade de enlaces e o seu
tamanho impactam diretamente no custo estático (área em silício) e no consumo de energia
(JERGER; PEH, 2009, p. 29).
Benini e De Micheli (2009, p. 24) classificam a topologia de NoC em quatro grupos:

Redes de meio compartilhado: O enlace é compartilhado com todos os núcleos e
somente um núcleo pode enviar informação de cada vez;

Redes diretas: Cada núcleo tem um roteador e enlaces ponto-a-ponto para os outros
núcleos;

Redes indiretas: Cada núcleo é conectado a um switch e os switches têm enlaces pontoa-ponto com outros switches;

Redes híbridas: Uma mistura dos grupos anteriores com o objetivo de aumentar a largura
de banda e reduzir a distância entre os núcleos.
A seguir, as mais importantes topologias são discutidas quanto ao custo de área e
desempenho (BENINI; DE MICHELI, 2006, p. 158):

Crossbar: Essa rede pode possuir uma topologia de rede direta, quando todos os
roteadores são conectados em todos os outros roteadores, ou indireta quando os
roteadores somente estão conectados aos seus roteadores vizinhos (Figura 1.a). Redes
crossbar não são escalares para grandes redes devido à sua complexidade.

Malha ou Grelha n-dimensional (ou n-dimensional k-ary mesh): Possui uma topologia
direta e os roteadores podem ser colocados em um leiaute em que todos os enlaces têm o
mesmo tamanho. O número de interfaces de rede por roteador é usualmente um, mas
19
podem haver várias interfaces. Nas tecnologias atuais de circuitos integrados são
utilizadas as malhas 2-D (Figura 1.b) devido à natureza de implementação planar .

Toróide (ou k-ary n-cube): Possui uma topologia direta e o custo de área e a dissipação
de energia cresce linearmente com o número de núcleos (Figura 1.c). O desempenho
diminui com o tamanho da NoC devido à sua limitada largura de banda de bissecção3.

Hipercubo (ou express cube): As topologias em malha e em toróide podem ser
estendidas para ultrapassarem o enlace (Figura 1.d), aumentam o desempenho, porém
aumentam a quantidade de dissipação de potência por unidade de área (densidade). É
uma rede de topologia direta.

Árvore d-dimensional (ou d-dimensional k-ary (fat) trees): Possue uma topologia
indireta de d níveis, na qual cada roteador tem k filhos. As interfaces de rede são
anexadas somente nas folhas. A largura de banda de bissecção é muito baixa devido à
concentração de todo o tráfego na raiz da árvore. Para resolver esse problema, a raiz
pode ser duplicada (fat-tree), porém aumenta o custo de área.

Irregular: As NoCs podem ser otimizadas para um domínio particular de aplicação ou a
um conjunto de aplicações, melhorando o desempenho, consumo de energia e/ou de
área.
Figura 1. Exemplos de topologia: (a) crossbar; (b) grelha 2-D; (c) toróide 2-D; (d) hipercubo 3-D
Fonte: Adaptado de Zeferino (2003, p. 33-34).
3
Largura de banda de bissecção (divisão em duas partes iguais) é a menor largura de banda sobre todas as bissecções da
rede (DALLY; TOWLES, 2004, p.48).
20
2.1.1.2 Componentes
A arquitetura de NoC pode ser dividida em vários componentes ou blocos básicos (BENINI;
DE MICHELI, 2006, p. 14). A Figura 2 representa os principais componentes de uma NoC e suas
interconexões. Nas subseções a seguir, são detalhados estes componentes.
Figura 2. Componentes de uma NoC: enlace, roteador e interface de rede (NI)
Enlace
Um enlace (ou link) liga dois pontos na rede de interconexão, sendo que esses pontos podem
ser um roteador ou um núcleo. O enlace pode possuir um ou dois canais físicos de comunicação
simplex. Enlaces full-duplex são constituídos por dois canais unidirecionais opostos de modo a
permitir a transferência simultânea de informação nas duas direções do enlace (ZEFERINO, 2003,
p. 30).
Roteador
Segundo Zeferino (2003, p. 30), um roteador é constituído por um núcleo de chaveamento
(crossbar), uma lógica de controle para roteamento e arbitragem, e portas de entrada-e-saída para
comunicação com outros roteadores e/ou com os núcleos. Essas portas de comunicação podem
21
possuir uma pequena memória para armazenamento temporário de informações, a qual é
denominada buffer de memorização ou, simplesmente, buffer. As portas possuem ainda
controladores de enlace para a implementação do protocolo físico de comunicação. Estes regulam o
tráfego das informações que entram e saem do roteador.
Os roteadores devem ser projetados para atender aos requisitos de latência e de desempenho,
bem como às restrições de custo de área e de consumo de energia. A latência da rede é afetada pelo
atraso no roteador. A arquitetura interna e os circuitos fundamentais do roteador impactam no
consumo de energia e no tamanho da área (JERGER; PEH, 2009, p. 76).
Interface de rede
A interface de rede, ou NI (Network Interface), implementa o protocolo de comunicação
necessária para adaptar a comunicação dos núcleos na NoC. A NI deve ser projetada para ser
reutilizada por núcleos pré-projetados e pré-verificados de diferentes plataformas e também de
diferentes arquiteturas de comunicação (BENINI; DE MICHELI, 2006, p. 203).
Segundo Benini e De Micheli (2006, p. 210), a estrutura da NI é dividida em dois módulos:
(i) front-end e (ii) back-end. O módulo front-end implementa um protocolo padrão ponto-a-ponto,
permitindo o reuso pelo núcleo em diversas plataformas. A camada de transporte provê
transferência transparente de dados entre os núcleos utilizando o serviço da rede. Esses serviços são
implementados no módulo back-end, junto com a camada de enlace e a camada física.
Justamente no sentido de evitar os problemas de interligação entre os núcleos, os padrões
VCI (Virtual Component Interface) e OCP (Open Core Protocol) foram desenvolvidos. Ambos
consistem de uma especificação de interface para interligação ponto-a-ponto entre os núcleos,
independentemente da arquitetura da comunicação utilizada para interconectar esses núcleos. O
OCP apresenta, como diferencial ao VCI, a inclusão de sinais de teste (scan e JTAG) e de controle
(como o de interrupção) em sua interface. O estabelecimento desses padrões é baseado na premissa
de que somente será possível explorar completamente o poder do reuso de projeto se forem
suportadas descrições comuns de propriedade intelectual (IP – Intellectual Property) (ZEFERINO,
2003, p. 55).
22
2.1.2 Controle de fluxo e chaveamento
Segundo Jerger e Peh (2009, p. 59), o controle de fluxo controla a alocação dos buffers e dos
enlaces da rede, sendo que um bom protocolo de controle de fluxo diminui a latência, não
sobrecarregando os recursos e melhorando o desempenho através do compartilhamento efetivo dos
buffers e enlaces.
Já o chaveamento define a forma pela qual esses dados são transferidos de um canal de
entrada de um núcleo para um dos seus canais de saída. Os dois tipos principais de técnicas de
chaveamento são baseados ou no estabelecimento de um caminho completo entre o núcleo de
origem e o destinatário da mensagem (circuito) ou na divisão das mensagens em pacotes os quais
reservam seus caminhos dinamicamente na medida em que avançam em direção ao destinatário
(ZEFERINO, 2003, p. 39).
Enquanto alguns autores separam os mecanismos de controle de fluxo e de chaveamento
(DUATO; YALAMANCHILI; NI, 1997; ZEFERINO, 2003), outros (DALLY; TOWLES, 2004;
JERGER; PEH, 2009, p. 60) adotam uma visão unificada com níveis diferentes de granularidade:
controle de fluxo em nível de mensagem e controle de fluxo em nível de enlace.
2.1.2.1 Estrutura da mensagem
Quando a mensagem é injetada na rede, esta é dividida em pacotes, e os pacotes, por sua
vez, são divididos em unidades de transferência de tamanho fixo chamados de flit (flow control
unit). Um pacote é formado por flits de cabeçalho, corpo e cauda (JERGER; PEH, 2009, p. 59). O
corpo do pacote é também chamado de carga útil e a cauda de terminador (ZEFERINO, 2003).
Cada flit do pacote é composto de um ou mais phits (physical units). Segundo Benini e De
Micheli (2006, p. 67), a unidade de transferência física (phit) é a unidade na qual o pacote é
dividido e transmitido através da NoC. Enquanto que um phit de tamanho grande confere alta
23
largura de banda ao enlace4, um phit de tamanho pequeno reduz a área da rede5. Figura 3 ilustra a
diferença entre mensagem, pacote, flit e phit.
Figura 3. Mensagem, Pacote, Flit e Phit
O flit pode ser definido como a menor unidade de dados sobre a qual é realizado o controle
de fluxo e pode ser tão pequeno e ter tantos bits quanto um phit, ou ser tão grande quanto um pacote
(ZEFERINO, 2003, p. 41). Em geral, um flit tem o tamanho de um a quatro phits, para conter, no
mínimo, a informação necessária ao roteamento do pacote pelos roteadores, ou seja, o cabeçalho.
2.1.2.2 Controle de fluxo baseado em mensagem (chaveamento por circuito)
Esta técnica de controle de fluxo opera em nível de mensagem com base no estabelecimento
de um circuito entre os núcleos fonte e destinatário para a transferência de uma mensagem, sendo
também denominada chaveamento por circuito (circuit switching). Para o estabelecimento do
circuito, um flit do tipo uma sonda (probe) é enviado na rede reservando os enlaces necessários para
transmitir toda a mensagem (ou múltiplas mensagens) da origem ao destinatário. Quando a sonda
chega ao destinatário, uma mensagem de confirmação é enviada de volta ao núcleo origem. Quando
este recebe a confirmação, inicia o envio da mensagem, a qual atravessa rapidamente a rede sem
sofrer qualquer contenção. Uma vez que completou a travessia, os recursos são liberados. Com
4
A largura banda do canal é dada pelo produto entre sua largura física em bits (phit) e pela sua frequência de operação,
sendo expresso na unidade bps (ou bits por segundo).
5
Quando um pacote é bloqueado na rede, seus flits devem ser armazenados em buffers internos do roteador. Como o
tamanho de cada célula de armazenamento do buffer é igual ao tamanho do phit do canal, quanto menor o phit, menor
será o buffer.
24
mensagens suficientemente largas, a redução da latência pode ser amortizada do custo da fase de
reserva (alocação do circuito). Esta técnica não necessita de buffers (bufferless) o que diminui o
consumo de energia, porém, há uma má utilização da largura de banda, pois os enlaces ficam
ociosos durante a fase de reserva até que a transferência da mensagem se inicie e quando os
processos que estão se comunicando não ocupam o circuito (intervalo entre as mensagens)
(JERGER; PEH, 2009, p. 61).
2.1.2.3 Controle de fluxo baseado em pacotes (chaveamento por pacotes)
Segundo Jerger e Peh (2009, p. 62), no controle de fluxo baseado em pacotes (ou
chaveamento por pacotes), uma mensagem é dividida em pacotes e os pacotes de diferentes
mensagens são intercalados nos enlaces, melhorando a utilização da rede. Esta técnica requer buffer
em cada núcleo para armazenar os pacotes em trânsito que aguardam por um canal para seguirem
em direção ao seu destino.
Ainda segundo Jerger e Peh (2009, p. 62), esta técnica pode ser implementada de duas
formas diferentes:
1. Armazena e Repassa (ou SAF – Store-and-Forward): Nesta técnica, cada núcleo aguarda
até que todo o pacote seja recebido antes de encaminhar qualquer parte para o próximo
núcleo. O atraso para a entrega da mensagem é maior e necessita de um buffer de
tamanho suficiente para armazenar um pacote inteiro quando este é bloqueado;
2. Transpasse Virtual (ou VCT – Virtual Cut-Through): Nesta técnica, os pacotes são
encaminhados ao próximo núcleo antes que todo o pacote seja recebido no roteador
corrente. A latência cai drasticamente, porém, a largura de banda e o armazenamento
continuam alocados para o pacote. O pacote só irá mover-se adiante se existir
armazenamento suficiente no próximo roteador. Em caso de bloqueio, assim como na
técnica SAF, é necessário um buffer para um pacote completo no roteador.
2.1.2.4 Controle de fluxo baseado em flits
O controle de fluxo baseado em flits permite diminuir o tamanho dos buffers e ajuda os
roteadores a atender a estreita área e consumo de energia. Uma técnica de controle de fluxo baseado
em flits é a wormhole (também denominada de chaveamento wormhole). Assim como no VCT,
25
nesta técnica, os flits de um pacote podem ser movidos para o próximo roteador antes de todo o
pacote ser recebido inteiramente pelo roteador corrente. No entanto, diferentemente do VCT, os
buffers podem ser dimensionados para armazenar apenas alguns flits ao invés do pacote inteiro,
permitindo a utilização de pequenos buffers em cada roteador (JERGER; PEH, 2009, p. 63).
Ainda segundo Jerger e Peh (2009), enquanto o controle de fluxo wormhole usa buffers
eficientemente, este usa a largura de banda de forma não eficiente. Quando um pacote é bloqueado,
todo o enlace físico fica ocioso. Como um pacote formado pode ser formado por muitos flits, em
caso de bloqueio, esse flits podem potencialmente alcançar vários roteadores e resultar em muitos
enlaces físicos ociosos. Com isso, o desempenho da rede pode ser degradado devido à fila de
pacotes atrás do pacote bloqueado, que não podem usar os enlaces físicos ociosos. Tal problema é
conhecido como bloqueio de cabeça de linha ou HOL (Head-of-Line).
Por permitir a construção de roteadores com menor custo (de silício e de energia), o
wormhole é o tipo de controle de fluxo mais utilizado em NoCs (JERGER; PEH, 2009, p. 64).
2.1.2.5 Controle de fluxo baseado em canais virtuais
Segundo Jerger e Peh (2009, p. 65), a técnica de controle de fluxo baseada em canais
virtuais (ou VCs – Virtual Channels) implementa filas separada nos roteadores, permitindo que
múltiplos VCs compartilhem o mesmo canal físico de um enlace entre dois roteadores. Pela
associação de múltiplas filas, o problema do bloqueio HOL pode ser reduzido, dado que um pacote
bloqueado em um canal virtual pode ser contornado por um pacote de outro canal virtual que
compartilhe o mesmo canal físico. O escalonamento da largura de banda do canal físico entre os
canais virtuais é feita de ciclo em ciclo. Esta técnica pode ser aplicada em todas as técnicas de
controle de fluxo, sendo mais utilizada em combinação com a técnica wormhole.
2.1.2.6 Starvation, Livelock e Deadlock
Segundo Zeferino (2003), as NoCs tem a função principal de oferecer o suporte físico
necessário à comunicação entre núcleos. Uma comunicação é realizada com sucesso quando a
informação enviada é devidamente recebida pelo destinatário. Entretanto, existem três situações que
podem impedir que um pacote chegue ao seu destino:
26

Starvation: Um pacote em um buffer de entrada, ao competir com outros pacotes por uma
mesma saída, pode ficar bloqueado permanentemente se o recurso requisitado for sempre
concedido a outros pacotes;

Livelock: Ocorre quando um pacote mantém-se trafegando permanentemente pela rede
porque os canais necessários para este chegar ao núcleo destinatário nunca se encontram
disponíveis;

Deadlock: Quando existe uma dependência cíclica de recursos na rede, um ou mais
pacotes podem ficar permanentemente bloqueados, aguardando a liberação do recurso.
2.1.2.7 Controle de fluxo livre de impasses
A rede livre de impasses pode ser mantida através de pré-requisitos no algoritmo de
roteamento que garanta que não ocorrerão ciclos ou através do uso do controle de fluxo livre de
impasses (deadlock-free). A técnica de controle de fluxo livre de impasses permite a utilização de
qualquer algoritmo de roteamento. Esta técnica consiste em ordenar e priorizar os canais virtuais.
Para evitar a baixa utilização de alguns VCs, o primeiro VC é usado de forma ordenada e os outros
VCs podem ser roteados aleatoriamente (JERGER; PEH, 2009, p. 67).
2.1.2.8 Buffer backpressure
O buffer backpressure é uma técnica de controle de fluxo em nível de enlace que evita que
flits dos pacotes sejam descartados em caso de bloqueio (JERGER; PEH, 2009, p. 69). Existem
diferentes formas para realizar esse controle, sendo que as alternativas mais comuns são:

Baseado em créditos: Esta técnica mantém uma informação sobre a quantidade de
buffers disponíveis. Através de sinais entre os roteadores vizinhos, quando um buffer é
desocupado é enviado um crédito para o roteador anterior, o qual incrementa a
quantidade de créditos. Quando o flit sai do roteador, um crédito é decrementado.
Somente é enviado o flit ao roteador seguinte se houver crédito.

On/Off: Esta técnica usa sinais de On/Off entre os roteadores adjacentes para sinalizar
quando limite do buffer foi atingido. Quando o limite máximo do buffer é atingido, um
sinal de Off é enviado ao roteador anterior fazendo com que o roteador pare de enviar
27
flits. O sinal On é enviado somente quando houver novamente buffer disponível para o
recebimento de novos flits.
2.1.3 Memorização
A memorização (ou buffering) diz respeito ao mecanismo de armazenamento de pacotes ou
de flits bloqueados dentro do roteador (ZEFERINO, 2003, p. 44). As filas de buffer consomem a
maior parte da área e da energia dentre os blocos que compõe uma NoC. Os circuitos de buffers
podem ser implementados por meio de registradores (flip-flops) ou de células SRAM (BENINI e
DE MICHELI, 2006, p 64),
Os buffers de memória podem ser organizados de forma independente ou compartilhado e
suas posições podem ser localizadas na entrada, na saída ou centralizados no roteador (ZEFERINO,
2003, p. 44). Segundo Benini e De Micheli (2006, p. 64), uma fila de buffer também pode ser
utilizada na interface de rede. A seguir, são apresentadas algumas das estratégias de memorização
possíveis de serem utilizadas em um roteador.
Na abordagem de memorização compartilhada e centralizada, um buffer centralizado é
utilizado para armazenar os pacotes bloqueados em todos os canais de entrada e o espaço de
endereçamento é dinamicamente distribuído entre os pacotes bloqueados. Essa abordagem oferece
uma utilização do espaço de memória melhor do que aquelas abordagens estaticamente alocadas aos
canais de entrada, porém, no caso de uma saída estiver em uso por uma entrada e outra entrada com
pacotes destinados a essa mesma saída continuar a receber dados, o buffer se encherá, afetando as
outras comunicações também. Este problema pode ser evitado pela limitação do espaço alocável a
cada canal (ZEFERINO, 2003, p. 45).
Ainda segundo Zeferino (2003, p.45-46), na abordagem de memorização na entrada, o
espaço de memória é distribuído sob a forma de partições entre os canais de entrada do roteador.
Essas partições são implementadas por meio de buffers independentes, cada um com portas de
entrada próprias. Existem várias alternativas possíveis de implementação, entre as quais podem ser
destacadas as seguintes estratégias, descritos por Tamir e Frazier (1992, apud ZEFERINO, 2003):
28
a. FIFO (First-In, First-Out): Cada buffer FIFO possui um espaço de memória fixo nos
quais os dados são lidos na mesma ordem em que são escritos (Figura 4.a). Um grande
inconveniente dessa técnica é o problema do bloqueio HOL (Head-of-Line), esse
bloqueio ocorre quando um pacote bloqueado na saída do buffer impede o avanço de
outro pacote que esteja atrás dele, o qual a saída desejada está disponível. Essa é a
alternativa mais simples e de menor custo.
b. SAFC (Statically Allocated, Fully Connected): É uma alternativa para contornar o
problema do bloqueio HOL, a qual consiste em dividir cada buffer de entrada em N
partições com tamanho igual a 1/N do tamanho do buffer original (Figura 4.b). Cada
uma dessas partições deve ser atribuída estaticamente a um canal de saída. Isso requer o
uso de um crossbar N2×N ou, então, de N crossbars N×1 ao invés de um único crossbar
N×N. Os inconvenientes dessa alternativa são os custos adicionais referentes ao controle
do crossbar e ao controle dos N buffers por porta de entrada. Outros inconvenientes
também são a limitação da utilização dos buffers a 1/N do espaço de armazenamento
total e a maior complexidade na implementação do controle de fluxo.
c. SAMQ (Statically Allocated Multi-Queue): É uma alternativa a fim de simplificar o
gerenciamento do crossbar. Nessa alternativa, as saídas dos buffers de entrada atribuídos
a um mesmo canal de saída podem ser multiplexadas (Figura 4.c). Esta estratégia
elimina alguns dos inconvenientes da SAFC, pois reduz o custo do crossbar, entretanto
ainda mantém os outros dois problemas relacionados à utilização dos buffers e ao
controle de fluxo.
d. DAMQ (Dynamically-Allocated, Multi-Queue): É uma alternativa com o objetivo de
remediar os problemas das estratégias anteriores. Nessa arquitetura de buffer, o espaço
de memorização associado a um canal de entrada é particionado dinamicamente entre os
canais de saída conforme a demanda dos pacotes recebidos (Figura 4.d). Dessa forma,
evita-se o problema do bloqueio HOL dos buffers FIFO, aumenta-se a utilização do
espaço de memória disponível e o controle de fluxo é mais simples que nas estratégias
SAFC e SAMQ, não requerendo pré-roteamento. Entretanto, o gerenciamento do buffer
DAMQ, baseado em listas encadeadas, torna a sua implementação física mais complexa.
29
(a)
(b)
(c)
(d)
Figura 4. Roteador com quatro buffers: (a) FIFO, (b) SAFC; (c) SAMQ; (d) DAMQ
Fonte: Adaptado de Zeferino (2003, p. 45-46).
Assim como na abordagem de memorização na entrada, a estratégia na abordagem de
memorização na saída consiste em particionar o espaço de memorização, porém, posicionado nas
saídas do roteador. As partições podem ser implementadas como buffers FIFO. Cada buffer de saída
deve ser capaz de suportar a demanda simultânea das N entradas, o que pode ser implementado com
N portas de escrita ou com uma porta de escrita operando a uma velocidade N vezes maior que a das
entradas. Esta estratégia requer um controle de fluxo interno entre portas de entrada e de saída do
roteador (ZEFERINO, 2003, p. 47).
2.1.4 Roteamento
O roteamento é o método usado para decidir que caminho o pacote (ou mensagem) irá tomar
através da rede para chegar ao seu destinatário. O desempenho da comunicação na rede de
interconexão depende fortemente do algoritmo de roteamento utilizado (ZEFERINO, 2003, p. 37).
O objetivo do algoritmo de roteamento ideal é distribuir o tráfego uniformemente entre os
caminhos fornecidos pela topologia de rede, minimizando a contenção e com isso melhorando a
latência e o desempenho da rede. O consumo de energia do circuito do roteador é tipicamente baixo,
porém a escolha de uma rota específica afeta a quantidade de saltos (hop count) diretamente, ou
seja, a quantidade de roteadores pelos quais a mensagem passa e, por isso, afeta substancialmente o
consumo de energia (JERGER; PEH, 2009, p. 67).
30
Segundo Duato, Yalamanchili e Ni (1997) e Ashraf (1998 apud ZEFERINO, 2003, p. 37), os
algoritmos podem ser agrupados e classificados segundo critérios específicos. O agrupamento e a
classificação dos algoritmos de roteamento são apresentados a seguir no Quadro 1.
Quadro 1. Classificação dos algoritmos de roteamento
Critério
Momento da realização
do roteamento
Número de destinatários
de um mesmo pacote
Local onde as decisões
de roteamento são
tomadas
Classificação
Dinâmico
Estático
Unicast
Multicast
Centralizado
Distribuído
Tabela
Implementação
Máquina de estado
Determinístico
Adaptação
Adaptativo
Descrição
Realizado no tempo de execução da aplicação
Executado no tempo de compilação da aplicação
Cada pacote possui um único destinatário
O pacote pode ser encaminhado para múltiplos
destinatários
Os caminhos são estabelecidos por um
controlador central na rede
O núcleo fonte define o caminho a ser seguido
pelo pacote antes de injetá-lo na rede
Feito a partir de uma consulta a uma tabela em
memória
Realizado a partir da execução de um algoritmo
implementado em software ou em hardware
Fornece sempre o mesmo caminho entre um
determinado par fonte-destinatário
Utiliza alguma informação a respeito do tráfego
da rede e/ou do estado dos canais para evitar
regiões congestionadas ou com falhas
Fonte: Adaptado de Zeferino (2003, p. 38).
Ainda, segundo Zeferino (2003, p. 38), os algoritmos adaptativos podem ser de três classes:
1. Progressividade: O roteamento é considerado progressivo quando os cabeçalhos dos
pacotes sempre avançam pela rede, reservando um novo canal a cada passo de
roteamento, ou regressivo (backtracking) quando o cabeçalho de um pacote puder
retornar pela rede, liberando canais previamente reservados;
2. Minimalidade: O roteamento adaptativo é classificado como mínimo (ou profitable), se
o algoritmo pode selecionar apenas canais de saída que aproximem cada vez mais o
pacote do seu destinatário, ou não-mínimo (ou misrouting), se este pode selecionar
canais que levem o pacote a se afastar do seu destinatário;
31
3. Número de caminhos: pode ser subclassificado como completo (ou total), se o algoritmo
de roteamento puder utilizar todos os caminhos disponíveis, ou parciais, se apenas um
subconjunto desses caminhos puder ser considerado.
2.1.5 Arbitragem
Enquanto o roteamento é um mecanismo de seleção de saída do pacote no roteador, a
arbitragem determina qual canal de entrada pode utilizar um determinado canal de saída do
roteador. A arbitragem é fundamental para a resolução de conflitos decorrentes da existência de
múltiplos pacotes competindo por um mesmo canal de saída (ZEFERINO, 2003, p. 47).
Segundo Zeferino (2003, p. 48), o mecanismo de arbitragem pode ser baseado em diferentes
critérios: prioridades estáticas, prioridades rotativas (round-robin), escalonamentos por idade (ou
deadline), FCFS (First-Come-First-Served), LRS (Least Recently Served), entre outros.
Zeferino (2003, p. 48) também apresenta que o árbitro de um roteador pode ser
implementado de forma (a) centralizada ou (b) distribuída. Na primeira forma, a centralizada
(Figura 4.a), os mecanismos de roteamento e de arbitragem são implementados em um único
módulo. Esse módulo recebe os cabeçalhos dos pacotes, executa o roteamento, determina o canal de
saída e, a partir disso, faz a arbitragem. Na forma distribuída (Figura 4.b), o roteamento e a
arbitragem são realizados de forma independente para cada porta bidirecional do roteador. Cada
uma das portas possui um módulo de roteamento associado ao seu canal de entrada e um módulo de
arbitragem no seu canal de saída.
Figura 5. Abordagens para implementação de árbitros: (a) centralizada; (b) distribuída
Fonte: Zeferino (2003, p. 48).
32
2.2 SEGURANÇA EM SISTEMAS COMPUTACIONAIS
Segundo a NBR ISO/IEC 27001:2006 (2006), o conceito de segurança da informação
consiste na preservação das propriedades de confidencialidade, de integridade e de disponibilidade
da informação. A preocupação com a segurança da computação é um fator relevante no
desenvolvimento e na aplicação tecnológica dos computadores em toda a sociedade (LANDWEHR,
2001).
Para Landwehr (2001), para um sistema ser seguro, cinco propriedades de segurança devem
ser garantidas. A seguir essas propriedades são descritas:
1. Confidencialidade: garantia de que a informação não será divulgada sem autorização;
2. Integridade: garantia de que a informação não será modificada sem autorização;
3. Disponibilidade: garantia de que a informação ou recurso estará acessível para os usuários
autorizados sempre que requisitados6;
4. Autenticidade: garantia de que cada entidade é quem afirma ser;
5. Não-repúdio: garantia de que a participação de uma entidade em uma dada transação ou
evento não pode ser negada.
A violação de segurança ocorre quando há a quebra de uma ou mais propriedades de
segurança (BRANDÃO; FRAGA, 2008). Vulnerabilidade é a fraqueza em um sistema de
informação, nos procedimentos de segurança, nos controles internos ou na implementação do
sistema que pode ser explorada por uma ameaça (CNSSI-4009, 2006).
Ameaça é qualquer circunstância ou evento com potencial para afetar negativamente as
operações de um sistema de informação através de acesso não autorizado, da destruição, da
divulgação, da modificação de informações e/ou da negação de serviço. Intrusão é quando um
ataque foi bem sucedido, ou seja, um ato não autorizado de contornar os mecanismos de segurança.
(CNSSI-4009, 2006).
6
Esta dissertação tem como foco a propriedade de segurança de disponibilidade.
33
O risco é a medida da extensão em que uma entidade está ameaçada por um potencial
circunstância ou evento. O que pode ser representado na função dos impactos adversos que surgem
se a circunstância ou evento ocorrer e da probabilidade de ocorrência (CNSSI-4009, 2006).
Stallings (2008) apresenta a arquitetura de segurança OSI (Open System Interconnection)7
que oferece uma estrutura sistemática para definir os requisitos de segurança e caracterizar as
técnicas para satisfazer esses requisitos. Essa arquitetura engloba serviços de segurança, ataques e
mecanismos.
Um serviço de segurança aumenta a segurança dos sistemas de processamento de dados e as
transferências de informação. Os serviços de segurança servem para frustrar ataques à segurança e
utilizam um ou mais mecanismos de segurança para garantir as propriedades se segurança
(STALLINGS, 2008).
2.2.1 Ataque à segurança
Conforme Stallings (2008), um ataque à segurança pode ser definido como qualquer ação
que comprometa a segurança da informação. Esses ataques são classificados em ataques passivos e
ataques ativos.
Um ataque passivo tenta monitorar o sistema com o objetivo de obter informações, mas não
afeta os recursos ou altera os dados envolvidos. Por essa razão, esse tipo de ataque é muito difícil de
detectar. A prevenção dos ataques passivos é a melhor forma de impedir o sucesso do ataque e o
emprego de criptografia é normalmente adotado para esse fim (STALLINGS, 2008).
Ainda segundo Stallings (2008), os ataques passivos podem ser de dois tipos:

Liberação do conteúdo da mensagem (eavesdropping): ocorre quando uma informação é
captada e o seu conteúdo é lido pelo atacante; e
7
A arquitetura de segurança OSI é proposto pela ITU (International Telecomunications Union), a qual realiza uma série
de especificações para padrões de comunicação entre sistemas. A arquitetura de segurança OSI não está relacionada
com o modelo de rede em sete camadas, conhecido como modelo OSI ou camadas OSI.
34

Analise de tráfego: ocorre quando o tráfego da troca de uma informação (criptografada
ou não) é analisado para identificar padrões nas mensagens. Com a análise, o atacante
poderia descobrir o local, a identidade dos envolvidos e qual a natureza da comunicação.
Ao contrário das características dos ataques passivos, os ataques ativos envolvem alguma
modificação do fluxo de dados ou na formação de um fluxo falso, afetando a operação do sistema.
Stallings (2008) divide os ataques ativos em quatro categorias:

Disfarce (impersonation ou masquerading): ocorre quando uma entidade finge ser outra
entidade diferente;

Repetição (replay): ocorre quando os dados são capturados passivamente e
subsequentemente retransmitidos para produzir um efeito não autorizado;

Modificação da mensagem: ocorre quando alguma parte da mensagem original é
alterada para produzir um efeito não autorizado;

Negação de serviço (Denial-of-Service ou DoS): ocorre quando há um impedimento ou
inibição do uso ou gerenciamento normal das instalações de comunicação.
Segundo Texier (2009), um sistema baseado em uma NoC insegura pode ser alvo de três
categorias de ataque:

Sequestro (hijacking): Nesta categoria, o atacante faz um acesso de escrita em uma área
segura com o intuito de modificar a execução ou a configuração do sistema,
comprometendo a sua integridade;

Extração de informação secreta: Nesta segunda categoria, o atacante tenta obter dados
sensíveis ou privados em áreas de memória ou registradores; e

Negação de serviço: Assim como na categorização feita por Stallings (2009), nesta
categoria o atacante também visa degradar o desempenho do sistema seja: (i) consumindo
a largura de banda da rede com acessos repetitivos; (ii) injetando um pacote na rede
destinado a um endereço inexistente de modo a bloquear alguns recursos da rede (ex.:
buffers de roteadores); (iii) criando deadlocks que paralisam a rede inteira; ou (iv)
injetando um pacote que nunca encontre um destinatário e fique rodando infinitamente na
rede (em livelock), aumentando a latência, o consumo de banda e a energia.
35
2.2.2 Mecanismos de segurança
O mecanismo de segurança é um processo projetado para detectar, impedir ou permitir a
recuperação de um ataque à segurança (STALLINGS, 2008). Os mecanismos de segurança
específicos podem ser categorizados como:

Cifragem: mecanismo que usa algoritmos matemáticos para transformar dados em um
formato que não seja prontamente decifrável;

Assinatura digital: mecanismo que utiliza a transformação criptográfica ou através de
dados anexados para permitir que o destinatário comprove a origem e a integridade dos
dados;

Controle de acesso: mecanismo que impõe direitos de acesso aos recursos;

Integridade dos dados: mecanismo que busca garantir a integridade de dados ou fluxo de
dados;

Troca de informações de autenticação: mecanismo que busca garantir a identificação de
uma entidade por meio da troca de informações; e

Preenchimento de tráfego: mecanismo com a inserção de bits nas lacunas de um fluxo de
dados para frustrar as tentativas de análise de tráfego.
2.3 CONSIDERAÇÕES
Atualmente, o emprego de NoC para a interconexão entre vários núcleos em um sistema
integrado em chip é a maneira mais eficiente para oferecer um desempenho escalável e permitir a
reusabilidade da arquitetura de comunicação. Uma NoC pode ser organizada em diferentes
topologias, sendo que a escolha da topologia e dos mecanismo de comunicação pode influenciar na
complexidade de implementação, no desempenho da rede, no custo de área de silício e/ou no
consumo de energia.
A topologia de rede direta do tipo malha 2-D é a mais popular por sua característica regular
e elétrica. Algumas NoCs podem utilizar topologia de redes irregulares para otimizar a aplicação
em particular, melhorando o desempenho, o consumo de energia e/ou o sobrecusto de área, porém
aumenta consideravelmente a complexidade de implementação. O controle de fluxo pode melhorar
o desempenho da rede, diminuindo a latência e evitando a sobrecarga dos recursos. Existem várias
36
técnicas de controle de fluxo, essas técnicas ainda podem ser combinadas com canais virtuais para
melhorar o compartilhamento dos enlaces. As filas de buffers, ou seja, a memorização, são os
componentes que mais consomem energia e área em uma NoC. Estas armazenam temporariamente
os pacotes, ou partes dele (flits), nos canais de entrada do roteador ou na saída das interfaces de
rede. O roteamento faz a decisão para o caminho que o pacote deve seguir para chegar ao seu
destino. A arbitragem resolve os conflitos entre os pacotes que competem pelo mesmo canal de
saída, determinando um canal de entrada no roteador. Na arbitragem, assim com na decisão de
roteamento, a implementação pode ser feita de forma centralizada ou distribuída nos roteadores. O
chaveamento define como os pacotes (ou flits) são transferidos do canal de entrada para o canal de
saída.
A arquitetura de segurança OSI permite caracterizar as técnicas para satisfazer esses
requisitos, englobando ataque, propriedades e mecanismos de segurança. Os ataques afetam as
propriedades de segurança, as quais podem ser protegidas pelo emprego de mecanismos de
segurança. O aumento de segurança em um sistema está relacionado com quanto as propriedades de
segurança são garantidas contra os ataques. O emprego de mecanismos de segurança fornece
subsídios para aumentar a segurança no sistema.
Nesta dissertação são avaliadas as vulnerabilidades da rede SoCIN a ataques que violam a
propriedade de disponibilidade. Para aumentar a disponibilidade mediante a esses ataques, alguns
mecanismos de controle de acesso são propostos e modelados para a implementação em hardware.
No próximo capítulo, são analisados trabalhos relacionados ao provimento de segurança em
sistemas em SoCs e em SoCs baseados em NoCs, a fim de caracterizar o histórico e o estado da arte
do contexto desta pesquisa.
37
3 SEGURANÇA EM REDES-EM-CHIP
Neste capítulo, é apresentado o levantamento bibliográfico realizado para caracterizar quais
técnicas têm sido utilizadas para prover segurança em SoCs baseados em NoC, discutindo os
primeiros estudos publicados na literatura e o estado da arte com as contribuições mais recentes.
Como o tema “Segurança em NoCs” ainda é pouco explorado, este capítulo estende a revisão para
trabalhos referentes à segurança em SoCs.
A Seção 3.1 apresenta uma síntese dos trabalhos selecionados e analisados, a qual é feita por
ordem cronológica. A Seção 3.2 apresenta uma análise comparativa dos trabalhos descritos e, na
Seção 3.3, são apresentadas as considerações deste capítulo.
3.1 TRABALHOS RELACIONADOS E O ESTADO DA ARTE
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.
38
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-ofService) 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
39
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
40
(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
41
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.
42
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
43
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 SystemCTLM. 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
44
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
45
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 SystemCTLM (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 (TimeDivision 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.
46
Porquet, Schwarzt e Greiner (2011) apresentaram uma solução para a implementação de
uma arquitetura segura para o compartilhamento de memória em NoC. Um componente na interface
de rede atua como um firewall, filtrando o acesso com base em um identificador denominado CID
(Compartment IDentifier) e na transação requisitada no endereço de memória usando uma tabela de
permissão. Conforme reportado pelos autores, em 2011, a solução estava na fase de implementação
e ainda não estava concluída, portanto ainda não possuía resultados até o momento da publicação.
3.2 ANÁLISE COMPARATIVA
Nesta seção, é feita uma comparação dos trabalhos analisados quanto aos tipos de ataques,
as propriedades de segurança abordadas e os mecanismos adotados.
No Quadro 2, são identificados os ataques abordados em cada trabalho analisado, incluindo
ataques passivos (liberação do conteúdo da mensagem e analise do tráfego) e ativos (disfarce,
repetição, modificação de mensagem e negação de serviço). O ataque ativo de repetição não foi
representado no quadro porque nenhum dos trabalhos abordou esse ataque. Na categoria liberação
de conteúdo da mensagem, foram considerados ataques que fazem acesso à memória para obter
informações sem a devida autorização. O gráfico da Figura 6 apresenta um resumo, identificando os
ataques mais abordados nesses trabalhos, com destaque aos ataques de modificação de mensagem
(16 trabalhos), liberação do conteúdo da mensagem (13 trabalhos) e negação de serviço (10
trabalhos).
47
Quadro 2. Ataques tratados nos trabalhos relacionados
Ataques
Passivo
X
X
Negação de
serviço
Modificação
de mensagem
X
Disfarce
Análise do
tráfego
Sistema
alvo
Liberação do
conteúdo da
mensagem
Trabalhos
Ativo
Gebotys e Gebotys (2003)
NoC
Ashkenazi e Akselrod (2007)
SoC
Diguet et al (2007)
NoC
X
Fiorin, Silvano e Sami (2007)
NoC
X
Anoop (2008)
SoC
X
X
Fiorin et al (2008)
NoC
X
X
Fiorin, Palermo e Silvano (2008)
NoC
X
X
X
Patel e Parameswaran (2008a)
SoC
X
X
Patel e Parameswaran (2008b)
SoC
X
X
Abramovici e Bradley (2009)
SoC
X
X
Patel, Parameswaran e Ragel (2009)
SoC
X
X
Porquet, Schwarzt e Greiner (2009)
NoC
X
X
Sepúlveda, Strum e Chau (2009)
NoC
X
X
Stefan e Goossens (2009)
NoC
X
Huffmire et al (2010)
NoC
X
Lukovic e Christianos (2010)
NoC
Sepúlveda, Strum e Chau (2010)
NoC
Lázaro et al (2011)
NoC
X
Porquet, Schwarzt e Greiner (2011)
NoC
X
X
X
X
3.2.1.1.1.1.1.1
X 3.2.1.1.1.1.1.2
X
X
X
X
X
X
X
X
X
X
X
48
Ataques
18
16
14
12
10
8
6
4
2
0
Modificação de
mensagem
Liberação do
conteúdo da
mensagem
Negação de serviço
Disfarce
Análise do tráfego
Figura 6. Gráfico com a relação dos ataques abordados
No Quadro 3, são apresentadas as propriedades de segurança abordadas nos trabalhos
analisados (autenticação, disponibilidade, confidencialidade e integridade). A propriedade de não
repúdio não foi discutida em nenhum dos trabalhos e, portanto, não foi representada no quadro. O
gráfico na Figura 7 mostra que a propriedade de segurança mais abordada é a de integridade (15
trabalhos), seguida de confidencialidade (13 trabalhos) e de disponibilidade (10 trabalhos).
49
Quadro 3. Propriedades de segurança tratadas nos trabalhos relacionados
Propriedades de segurança
Autenticação
Confidencialidade
Integridade
Disponibilidade
Sistema
alvo
Gebotys e Gebotys (2003)
NoC
X
X
X
Ashkenazi e Akselrod (2007)
SoC
X
X
X
Diguet et al. (2007)
NoC
X
Fiorin, Silvano e Sami (2007)
NoC
Anoop (2008)
SoC
Fiorin et al. (2008)
NoC
X
Fiorin, Palermo e Silvano (2008)
NoC
X
Patel e Parameswaran (2008a)
SoC
X
X
Patel e Parameswaran (2008b)
SoC
X
X
Abramovici e Bradley (2009)
SoC
X
Patel, Parameswaran e Ragel (2009)
SoC
X
Porquet, Schwarzt e Greiner (2009)
NoC
Sepúlveda, Strum e Chau (2009)
NoC
Stefan e Goossens (2009)
NoC
X
Huffmire et al. (2010)
NoC
X
Lukovic e Christianos (2010)
NoC
X
Sepúlveda, Strum e Chau (2010)
NoC
X
Lázaro et al. (2011)
NoC
Porquet, Schwarzt e Greiner (2011)
NoC
Trabalhos
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
50
Propriedades de Segurança
16
14
12
10
8
6
4
2
0
Integridade
Confidencialidade
Disponibilidade
Autenticação
Figura 7. Gráfico com a relação de propriedade de segurança tratado
No Quadro 4, são relacionados os mecanismos de segurança adotados nos trabalhos
analisados (controle de acesso, cifragem, assinatura digital, integridade dos dados, troca de
informação de autenticação, controle de roteamento). Os mecanismos de segurança de
preenchimento de tráfego e de certificação não foram apresentados na relação, pois nenhum
trabalho utilizou esses mecanismos. Na Figura 8, é apresentada graficamente a relação de
mecanismos de segurança adotados, a qual aponta a integridade de dados como a mais abordada (14
trabalhos), seguida do controle de acesso (11 trabalhos).
51
Quadro 4. Mecanismos adotados nos trabalhos relacionados
Mecanismos de segurança
X
X
X
Ashkenazi e Akselrod (2007)
SoC
X
X
X
Diguet et al (2007)
NoC
X
X
Fiorin, Silvano e Sami (2007)
NoC
X
X
Anoop (2008)
SoC
Fiorin et al (2008)
NoC
X
X
Fiorin, Palermo e Silvano (2008)
NoC
X
X
Patel e Parameswaran (2008a)
SoC
X
X
Patel e Parameswaran (2008b)
SoC
X
X
Abramovici e Bradley (2009)
SoC
Patel, Parameswaran e Ragel (2009)
SoC
Porquet, Schwarzt e Greiner (2009)
NoC
X
X
Sepúlveda, Strum e Chau (2009)
NoC
X
X
Stefan e Goossens (2009)
NoC
Huffmire et al (2010)
NoC
Lukovic e Christianos (2010)
NoC
Sepúlveda, Strum e Chau (2010)
NoC
Lázaro et al (2011)
NoC
Porquet, Schwarzt e Greiner (2011)
NoC
X
Controle de
roteamento
Troca de
informações de
autenticação
Integridade dos
dados
Cifragem
NoC
Sistema
alvo
Assinatura digital
Controle de acesso
Gebotys e Gebotys (2003)
Trabalhos
X
X
X
X3.2.1.1.1.1.1.3
3.2.1.1.1.1.1.4
3.2.1.1.1.1.1
3.2
X
3.2.1.1.1.1.1.7
3.2.1.1.1.1.1.8
3.2.1.1.1.1.1.9
X
X
X
X
X
X
X
X
52
Mecanismos de Segurança
16
14
12
10
8
6
4
2
0
Integridade dos
dados
Controle de
acesso
Cifragem
Assinatura
digital
Controle de
roteamento
Troca de
informações de
autenticação
Figura 8. Gráfico com a relação dos mecanismos de segurança adotados
No Quadro 5, são identificados os componentes utilizados para garantir as propriedades de
segurança (núcleo, interface de rede – NI, roteador e protocolo) em cada trabalho analisado. Já o
gráfico da Figura 9 identifica em quantos trabalhos cada componente foi utilizado como local para
implementação da solução de segurança. Como pode ser observado, a interface de rede (NI) é o
componente preferencial e foi adotada por 10 dos 19 trabalhos analisados. Deve-se ressaltar que
alguns dos trabalhos eram focados em SoCs não necessariamente baseados em NoCs e, portanto,
utilizaram como componente os núcleos do sistema.
53
Quadro 5. Componentes utilizados nos trabalhos analisados
Componente
NI
Protocolo
Núcleo
Gebotys e Gebotys (2003)
NoC
X
X
Ashkenazi e Akselrod (2007)
SoC
X
Diguet et al. (2007)
NoC
X
X
Fiorin, Silvano e Sami (2007)
NoC
X
X
Anoop (2008)
SoC
Fiorin et al. (2008)
NoC
X
Fiorin, Palermo e Silvano (2008)
NoC
X
Patel e Parameswaran (2008a)
SoC
X
Patel e Parameswaran (2008b)
SoC
X
3.2.1.1.1.1.1.10
3.2.1.1.1.1
Abramovici e Bradley (2009)
SoC
X
3.2.1.1.1.1.1.12
3.2.1.1.1.1.1.13
3.2.1.1.1.1
Patel, Parameswaran e Ragel (2009)
SoC
X
Porquet, Schwarzt e Greiner (2009)
NoC
X
Sepúlveda, Strum e Chau (2009)
NoC
X
Stefan e Goossens (2009)
NoC
X
Huffmire et al. (2010)
NoC
Lukovic e Christianos (2010)
NoC
Sepúlveda, Strum e Chau (2010)
NoC
Lázaro et al. (2011)
NoC
Porquet, Schwarzt e Greiner (2011)
NoC
Trabalhos
Roteador
Sistema
alvo
X
X
X
X
X
X
X
X
X
X
54
Componentes
12
10
8
6
4
2
0
Interface de rede
Núcleo
Roteador
Protocolo
Figura 9. Gráfico com a relação de componentes utilizados
3.3 POSICIONAMENTO DESTE TRABALHO
Neste trabalho, abordou-se o aumento de segurança na propriedade de disponibilidade da
rede SoCIN contra ataques de negação de serviço. A proposta de implementação deste trabalho é de
mecanismos de controle de acesso, que foram modelados e implementados de tal forma que podem
ser futuramente integrados a interface de rede da SoCIN.
O Quadro 6 apresenta de forma geral o posicionamento deste trabalho com os demais
trabalhos selecionados e analisados que abordam o problema da segurança em NoCs.
55
Quadro 6. Posicionamento deste trabalho com os trabalhos analisados
Ataques
Fiorin, Palermo e Silvano (2008)
X
Porquet, Schwarzt e Greiner (2009)
X
X
Sepúlveda, Strum e Chau (2009)
X
X
Stefan e Goossens (2009)
X
Huffmire et al. (2010)
X
X
X
X
X
X
X
X
X
X
3.3.1.1.1.1.1.6
3.3.1.1.1.1.1.7
X
X
X
X
X
X
X X
X
X
X
X
X3.3.1.1.1.1.1.10
X
X
X3.3.1.1.1.1.1.12
X
X
X
3.3.1.1.1.1.1.14
X X
X
X
X
X
X
X
X
X
X
X
3.3.1.1.1.1.1.9
X
X
X
X
3.3.1.1.1.1.1.2
X
X
X
Sepúlveda, Strum e Chau (2010)
X
X X
X
X X
X3.3.1.1.1.1.1.11
Porquet, Schwarzt e Greiner (2011)
X
X3.3.1.1.1.1.1.4
X 3.3.1.1.1.1.1.5
X
X
3.3.1.1.1.1.1.8
X
X
X
X
X
X
X
X X
Lukovic e Christianos (2010)
Lázaro et al (2011)
X
X3.3.1.1.1.1.1.3
X
X
X
X
X3.3.1.1.1.1.1.1
X
X
Protocolo
X
X
X
Roteador
Fiorin et al. (2008)
X
X
NI
X
X
X
X
Núcleo
Fiorin, Silvano e Sami (2007)
X
Componentes
Controle de
roteamento
Troca de informações
de autenticação
X
Integridade dos dados
Diguet et al. (2007)
X
Assinatura digital
X
Cifragem
X
X
Mecanismos
Controle de acesso
X
Integridade
Gebotys e Gebotys (2003)
Confidencialidade
X
Este trabalho
Disponibilidade
Autenticação
Negação de Serviço
Modificação
Disfarce
Análise de tráfego
Liberação do conteúdo
da mensagem
Trabalhos
Propriedades
3.3.1.1.1.1.1.13
X
3.3.1.1.1.1.1.15
X
X
X
X
X
56
3.4 CONSIDERAÇÕES
O estudo realizado permitiu identificar que: (i) os principais ataques tratados pelas pesquisas
atuais são os ataques de modificação de mensagem, de liberação do conteúdo da mensagem e
negação de serviço; (ii) que as propriedades de segurança mais abordadas são as de integridade,
confidencialidade e disponibilidade; (iii) que os mecanismos mais utilizados são os de integridade
dos dados e de controle de acesso; e (iv) que a interface de rede é a estrutura da rede mais utilizada
na implementação das soluções de provimento de segurança nos SoCs, principalmente os baseados
em NoCs.
Diante dessa análise, nesta dissertação, optou-se por tratar ataques de negação de serviço
que visem comprometer a propriedade de disponibilidade da rede SoCIN. São propostos
mecanismos de controle de acesso a fim de assegurar que os pacotes injetados por núcleo na rede
não degradem o seu desempenho ou, ainda, tornem a rede indisponível aos demais núcleos. No
próximo capítulo, é apresentada a modelagem dos mecanismos propostos.
57
4 ADICIONANDO SEGURANÇA À REDE SOCIN
A rede SoCIN (SoC Interconnection Network) foi desenvolvida como uma NoC sintetizável
e parametrizável de baixo custo para interconexão de núcleos em sistemas integrados (ZEFERINO,
2003). No seu projeto original (ZEFERINO; SUSIN, 2003) e na sua versão estendida (ZEFERINO;
SANTO; SUSIN, 2004) não foram levados em consideração aspectos específicos relacionados à
segurança. Embora alguns tipos de ataques possam ser evitados pela natureza dos mecanismos de
comunicação utilizados (ex. roteamento ou arbitragem), esta pode ser vulnerável a outros tipos de
ataques. Nesse contexto, este trabalho busca identificar vulnerabilidades da rede SoCIN e
implementar soluções para proteger a rede contra alguns tipos de ataques.
Neste capítulo, na Seção 4.1, é feita uma descrição da arquitetura da rede SoCIN, após a
qual, na Seção 4.2, é feita uma análise de suas potenciais vulnerabilidades. Na Seção 4.3, são
selecionados ataques a serem abordados e para os quais são propostos mecanismos para aumentar a
segurança da rede SoCIN, os quais são descritos na Seção 4.4. Por fim, na Seção 4.5, são
apresentadas as considerações do capítulo, com uma análise do posicionamento das contribuições
deste trabalho em relação ao estado da arte sobre segurança em NoCs.
4.1 REDE SOCIN
A SoCIN é uma NoC escalável baseada em uma arquitetura de roteador parametrizável para
ser usada na síntese de redes de baixo custo. Sua arquitetura é baseada no chaveamento wormhole e
usa o algoritmo de roteamento determinístico XY baseado na origem. Também aplica o protocolo
handshake para controle de enlace, usa arbitragem round-robin e buffers de entrada (SUSIN e
ZEFERINO, 2003).
O roteador original da rede SoCIN, o RASoC (Router Architeture for SoC), pode ser
personalizado nas dimensões físicas (por exemplo no tamanho dos canais e na profundidade dos
buffers) para atender aos requisitos de custo e desempenho da aplicação alvo. Entretanto, esses
níveis de parametrização são limitados e para melhorar estes aspectos, foi desenvolvida uma
segunda versão da SoCIN, a SoCINfp (SoCIN fully parameterizable, ou seja, SoCIN totalmente
parametrizável), na qual foi estendida a capacidade de parametrização para técnicas de roteamento,
arbitragem e controle de fluxo. Devido a isso, também foi necessário um novo roteador,
58
denominado ParIS (Parameterizable Interconnect Switch), baseado em modelos e bibliotecas de
componentes construídos com diferentes alternativas e implementações de circuitos para o
encaminhamento de pacotes (ZEFERINO; SANTO; SUSIN, 2004).
A versão da SoCIN com o roteador RASoC está descontinuada e a SoCINfp com o roteador
ParIS é a implementação atual e ativa na comunidade científica. Neste texto, será empregado o
termo SoCIN para se referir à segunda versão, a SoCINfp.
4.1.1 Arquitetura da rede SoCIN
Nesta seção, são discutidos a topologia, o enlace, o modelo de comunicação, o chaveamento,
o roteamento, a arbitragem, o controle de fluxo e o armazenamento na rede SoCIN.
Topologias
A rede SoCIN pode ser construída usando uma topologia direta 2-D como do tipo grelha ou
a do tipo toróide. A primeira topologia apresenta baixo custo e a segunda reduz a latência da rede
(ZEFERINO; SANTO; SUSIN, 2004). A Figura 10 ilustra as duas topologias da SoCIN.
(a)
Figura 10. As duas topologias da SoCIN: (a) grelha e (b) toróide
Fonte: Susin e Zeferino (2003).
(b)
59
Modelo de comunicação
Segundo Susin e Zeferino (2003), na SoCIN existem dois tipos de núcleos: iniciador
(initiator) e alvo (target). O iniciador (ex.: processador) faz requisições para o alvo (ex.: memória) e
o alvo responde as requisições do iniciador. Um núcleo pode ser um iniciador e um alvo ao mesmo
tempo (ex.: co-processador). O modelo de comunicação utilizado é baseado em troca de mensagens,
ou seja, as requisições e as respostas são sempre enviadas por mensagens.
Chaveamento
Segundo Susin e Zeferino (2003), a abordagem de chaveamento de pacote da SoCIN é
wormhole. As mensagens são enviadas por meio de pacotes, os quais são compostos por flits (flow
control unit). Na SoCIN, um flit é igual à largura do canal (ou um phit – physical unit), tendo o
tamanho da largura do canal mais dois bits.
Enlace
Segundo Susin e Zeferino (2003), o enlace da SoCIN (Figura 11) inclui dois canais
unidirecionais opostos, cada um para dados, framing e sinais de controle de fluxo. Cada canal inclui
n bits para dados e dois bits para o enquadramento do pacote: (i) bop (begin-of-packet, ou inicio do
pacote) para o pacote de cabeçalho; e (ii) eop (end-of-packet, ou final de pacote) na última palavra
de payload. Os n bits de dados podem ser estendidos para incluir sinais para serviços não previstos
no protocolo, como por exemplo, sinais para controle de integridade de dados (de paridade e de
erro). Os valores típicos para n são 8, 16 ou 32 bits. Os sinais val (validate signal) e ret (return
signal) são usados para o controle de fluxo. O sinal val indica a presença de informação válida no
canal de dados. Já o significado do sinal ret pode variar conforme a técnica de controle de fluxo
utilizada (handshake ou baseado em crédito).
60
n+2
n
data
bop
eop
n+2
val
ret
Figura 11. Enlace da SoCIN
Fonte: Zeferino, Santo e Susin (2004).
Roteamento
Segundo Zeferino, Santo e Susin (2004), na versão atual da rede SoCIN (a SoCINfp), o
roteamento ocorre no roteador usando o sistema de coordenadas ilustrado na Figura 12. Essa
abordagem permite a implementação de diferentes algoritmos de roteamento, desde roteamentos
determinísticos a totalmente adaptativos12.
Y
3
0 ,3
1 ,3
2 ,3
3 ,3
2
0 ,2
1 ,2
2 ,2
3 ,2
1
0 ,1
1 ,1
2 ,1
3 ,1
0
0 ,0
1 ,0
2 ,0
3 ,0
0
1
2
3
X
Figura 12. Sistema de coordenadas da SoCINfp
Fonte: Zeferino, Santo e Susin (2004).
12
Atualmente a SoCINfp somente possui implementado roteamentos determinísticos e parcialmente adaptativos.
61
Pacote
O formato do pacote da SoCIN é apresentado na Figura 13. O pacote inclui um flit de
cabeçalho e um número ilimitado de flits de payload. Cada flit tem a largura de (n+2) bits e o
enésimo bit é o marcador de bop e o (enésimo+1) bit é o marcador eop. O campo HLP (Higher
Level Protocol, ou protocolo de nível superior) está reservado para a implementação de protocolos
acima da camada de rede, como por exemplo, a informação para reordenação de pacotes, e não é
processado pelos roteadores. O HLP tem o tamanho de (n-m) bits de largura e pode ser estendido
pelo aumento da largura do canal ou pelo uso do flit seguinte do pacote. O campo RIB (Routing
Information Bits) carrega a informação utilizada por cada roteador para realizar o encaminhamento
de pacote, em outras palavras, as coordenadas de destino (subcampos: xdest e ydest). O campo RIB
possui m bits de largura e, por consequência, a rede é limitada a 2m/2×2m/2 roteadores.
bop
eop
n bits
m bits
HLP
RIB.xdest
RIB.ydest
00
Flits de payload
10
Último flit de payload
ilimitado
01
Figura 13. Formato do pacote e bits de informação roteamento da SoCIN
Fonte: Zeferino, Santo e Susin (2004).
Arbitragem
Segundo Zeferino, Santo e Susin (2004), a arbitragem da SoCIN baseia-se em uma
abordagem distribuída do tipo estática ou dinâmica (randômica ou round-robin) em cada canal de
saída do roteador. Essa solução tem por característica permitir a arbitragem simultânea de múltiplos
recursos, dado que cada canal de saída possui um árbitro dimensionado de acordo com o número de
canais de entrada que pode requisitar esse canal de saída (isso varia com a posição da porta de saída
no roteador, com a posição do roteador na rede e com o algoritmo de roteamento utilizado).
62
Controle de fluxo
Segundo Zeferino, Santo e Susin (2004), o controle de fluxo da SoCIN é em nível de enlace
e pode ser handshake ou baseado em créditos. Na abordagem handshake, quando um dado é
colocado no enlace pelo remetente, o sinal de validade (val) é ativado e quando o dado estiver
pronto para ser consumido pelo destinatário, este deve ativar o sinal de reconhecimento (ret). Na
abordagem baseada em créditos, o sinal ret informa que uma posição foi liberada no buffer de
entrada do destinatário e um crédito está sendo retornado ao remetente. O remetente só pode enviar
um novo flit se a capacidade de armazenamento (buffer) do destinatário não for atingida. O estado
desses buffers é monitorado usando um contador up-down, que é inicializado com um número de
créditos igual à profundidade do buffer do destinatário. O contador é decrementado quando é
enviado um flit e incrementado quando um crédito é retornado. Se o contador for igual à zero,
significa que a capacidade de armazenamento do destinatário foi atingida e nenhum novo flit deve
ser enviado.
Buffer
Na SoCIN existem um buffer FIFO com capacidade de p flits em cada entrada ou saída do
canal, onde p depende dos requisitos de custo e desempenho da aplicação (ZEFERINO; SANTO;
SUSIN, 2004). O tamanho de cada buffer é igual a p × n bits.
4.1.2 Arquitetura do roteador ParIS
Segundo Zeferino, Santos e Susin, (2004), o ParIS é um roteador soft-core VHDL baseado
em
bibliotecas
de
blocos
pré-projetados
parametrizáveis,
incluindo
diferentes
abordagens/implementações para cada técnica utilizada para o encaminhamento de mensagem em
uma NoC de chaveamento de pacote wormhole.
O roteador ParIS possui até cinco portas, conforme Figura 14. A porta L (Local) é reservada
para conectar o núcleo ou a um subsistema de rede. As outras portas, N (North), E (East), S (South)
e W (West), são usadas para interconectar outros roteadores e seus nomes derivam dos quatro
pontos cardiais em inglês, norte, leste, sul e oeste (ZEFERINO; SANTO; SUSIN, 2004).
63
L
N
W
E
S
Figura 14. Interfaces do ParIS
Fonte: Zeferino, Kreutz e Susin (2004).
O roteador ParIS é estruturado internamente de forma distribuída e cada porta de
comunicação tem dois módulos: canal de entrada e canal de saída. Na Figura 15, é ilustrada a
organização interna do ParIS e são mostradas as estruturas dos módulos de entrada (in) e de saída
(out) das portas L e W.
IC
val
ret
din
IFC
wr
wok
req[ ]
idle
gnt[ ]
dout
FIFO
ro
rdk
I
R
S
}
...
ro
k
rok[ ]
wok[ ]
wok
...
...
...
...
Lout
O
C
O
D
S
O
W
S
}
din
... req[ ]
}
... idle[ ]
}
}
}
L in
din
wr
wok
dout
FIFO
ro
rdk
din
OF
C
val
ret
CPM
din
val
ret
din
IFC
wr
wok
req[ ]
idle
gnt[ ]
dout
FIFO
ro
rdk
I
R
S
}
...
ro
k
wok[ ]
Figura 15. Organização do ParIS
Fonte: Adaptado de Zeferino, Santo e Susin (2004).
rok[ ]
wok
...
...
...
}
IC
... req[ ]
}
... idle[ ]
}
}
}
Win
...
Wout
O
C
O
D
S
O
W
S
din
wr
wok
dout
FIFO
ro
rdk
din
OF
C
val
ret
64
Componentes
Segundo Zeferino, Santo e Susin (2004), os blocos do ParIS incluem:

Controladores de enlace: Componentes que regulam o tráfego dos flits na rede para fazer
a tradução entre o protocolo de controle de fluxo do enlace e as técnicas de controle de
fluxo dentro do roteador (FIFO). Existem dois tipos de blocos relacionados a essa tarefa.
(i) IFC (Input Flow Controller), que regula o tráfego dos flits entrantes no canal de
entrada; e (ii) OFC (Output Flow Controller), que regula o tráfego dos flits saintes no
canal de saída;

Buffers FIFO: Componentes usados para armazenar flits dos pacotes temporariamente
bloqueados dentro do roteador e aguardando para ser encaminhado. O uso de FIFO nos
módulos de entrada é obrigatório, porém é opcional nas portas de saída;

Controladores de agendamento: Componente que faz o agendamento dos recursos dentro
do roteador. Existem dois tipos de controladores, (i) IC (Input Controller) que agenda o
canal de saída para o canal de entrada e (ii) OC (Output Controller) que agenda um canal
de entrada para um canal de saída.

Chaveadores: Componentes que executam o chaveamento interconectando os dados e os
sinais internos do fluxo de controle dos canais de entrada e saída com base no sinal de
permissão emitido pelo bloco OC. A implementação distribuída do crossbar resulta em
três tipos de chaveadores: (i) ODS (Output Data Switch) que conecta o buffer de dados
do canal de entrada selecionado ao buffer de dados do canal de saída associado; (ii)
OWS (Output Write Switch), que conecta o sinal de estado rok do buffer do canal de
entrada ao sinal de comando wr do buffer de saída associado; e (iii) IRS (Input Read
Switch), que conecta o sinal de estado wok do buffer do canal de saída ao sinal de
comando rd do buffer de entrada associado.

Matriz de Chaveamento (CPM – Crosspoint Matrix): Componente responsável por
guiar o compilador VHDL para implementar somente as conexões permitidas pelo
algoritmo de roteamento selecionado.
65
4.1.3 BrownPepper
O projeto de uma NoC é complexo e encontrar os melhores parâmetros de configuração
para uma aplicação é um trabalho que demanda tempo. O BrownPepper é um ambiente integrado
que permite avaliar o desempenho da NoC SoCIN com configurações diferentes, facilitando a
análise de desempenho pelo projetista da NoC (BRUSH; PIZZONI; ZEFERINO, 2009).
Segundo Brush, Pizzoni e Zeferino (2009), o BrownPepper é baseado no modelo SystemC
RTL (Register Transfer Level) e um misto de RTL/TL (Transaction Level) da rede SoCIN e outros
componentes. O ambiente integra um conjunto de ferramentas para automatizar as tarefas
relacionadas à simulação de operações de rede em diferentes cenários de tráfego. O BrownPepper
possui uma interface gráfica de usuário (GUI – Graphical User Interface), a qual foi desenvolvida
para facilitar a configuração e a execução de experimentos, além da análise dos resultados.
Arquitetura do BrownPepper
O BrownPepper baseia-se em uma plataforma SoC composta pela rede SoCIN, instâncias de
um gerador de tráfego (TG) e de um medidor de tráfego (TM) anexados aos terminais da NoC.
Cada TG gera fluxos de comunicação compostos por uma sequência de pacotes a serem enviados a
um destinatário seguindo um padrão de tráfego específico. Além injetar pacotes na rede, o TG
também trabalha como um núcleo destinatário, ejetando pacotes da rede. Cada TM é responsável
por monitorar o tráfego em um terminal da rede e coleta os dados dos pacotes que chegam ao TG ao
qual está associado. Para parar a simulação, um bloco centralizado denominado StopSim determina
quando todos os pacotes são entregues ao seus destinatários (BRUSH; PIZZONI; ZEFERINO,
2009).
Os principais parâmetros incluem: (i) o requisito de banda; (ii) o número de pacotes a
enviar; (iii) o endereço do núcleo de destino ou a distribuição espacial usada para determinar o(s)
núcleo(s) destinatário(s); e (iv) o tipo da taxa de injeção do tráfego, que pode ser constante ou
variável (incluindo rajadas). Além desses parâmetros, o fluxo de comunicação pode ser rotulado em
quatro classes relacionadas ao requisito de qualidade de serviços (QoS – Quality-of-Service).
O fluxo de projeto oferecido pelo BrownPepper possui as etapas de: (i) geração do
simulador SystemC; (ii) geração do modelo de tráfego; (iii) execução da simulação; e (iv) análise
dos resultados. As ferramentas utilizadas para a geração do simulador SystemC são ilustrados na
66
Figura 16. Os parâmetros do sistema são lidos por dois geradores de código, o gnoc e o gsoc. O
gnoc gera o modelo de SystemC da SoCIN, já o gsoc, gera o modelo de SystemC para a plataforma
SoC (main), para o bloco SopSim e os parâmetros usados para configurar outros modelos de
SystemC (o roteador ParIS, para o TM e o TG). Após a geração do código, os modelos são
compilados pelo compilador gcc, no qual resulta em um simulador SystemC (arquivo binário
system.x).
Parâmetros do
Sistema
parâmetros
Modelos
SystemC
Simulador
SystemC
Figura 16. Geração do simulador SystemC do BrownPepper
Fonte: Brush, Pizzoni e Zeferino (2009).
4.2 VULNERABILIDADES DA REDE SOCIN
Nesta seção, é apresentada uma análise das vulnerabilidades da rede SoCIN a um conjunto
de possíveis ataques, conforme já apresentados e discutidos na Seção 3.2.
4.2.1 Definição dos ataques
Com base nos trabalhos analisados, uma relação de possíveis ataques à rede SoCIN foram
identificados e classificados quanto ao tipo de ataque e à propriedade de segurança afetada. Esses
ataques são listados no Quadro 7 e discutidos logo a seguir. Ataques referentes à aplicação (e.g.
acesso a uma região da memória de um núcleo) estão fora do escopo desse trabalho e não foram
relacionados.
67
Quadro 7. Relação de possíveis ataques a NoC
Ataque
Tipo de Ataque
Deadlock
Livelock
Starvation
Envio de pacotes para um endereço de
destino inexistente
Repetição do envio de pacote para um
determinado endereço
Responder a requisições não enviadas
Mascaramento de endereço de origem
Ativo/ Negação de serviço
Ativo/ Negação de serviço
Ativo/ Negação de serviço
Ativo/ Negação de serviço
Propriedade de
segurança
Disponibilidade
Disponibilidade
Disponibilidade
Disponibilidade
Ativo/ Negação de serviço
Disponibilidade
Envio de pacote sem terminador
Interceptação da mensagem
Interceptar a mensagem e retransmitir
Interceptar mensagem e depois reenviar a
mensagem alterada
Ativo/ Negação de serviço
Ativo/ Disfarce
Disponibilidade
Autenticação e
Não-repúdio
Ativo/ Negação de serviço
Disponibilidade
Passivo/ Liberação do conteúdo Confidencialidade
da mensagem
Ativo/ Repetição
Confidencialidade
e disponibilidade
Ativo/ Repetição
Confidencialidade,
disponibilidade e
Integridade
Um deadlock em uma NoC ocorre quando há uma dependência cíclica do recurso da rede. Já
um livelock pode ocorrer em uma NoC se os canais para chegar ao núcleo de destino sempre
estiverem ocupados e o pacote ficar trafegando permanentemente pela rede. O starvation pode
ocorrer quando dois ou mais pacotes em buffers de entrada competem pela mesma saída e se o
recurso requisitado for concedido de tal forma que um pacote (ou entrada) seja sempre postergado
sem avançar na rede.
O envio de pacotes para um endereço de destino inválido é um tipo de ataque que pode
ocorrer em uma NoC quando um núcleo envia pacote para ele mesmo ou para um endereço além
das fronteiras da rede, bloqueando sua porta de acesso à rede ou outros recursos (buffers dos
roteadores). Já um ataque de repetição do envio de pacote para um determinado endereço ocorre
quando um núcleo da NoC envia vários pacotes repetidamente a um mesmo endereço na tentativa
de tornar o núcleo de destino e/ou a rede indisponível. Por outro lado, um ataque de resposta a
requisições não enviadas ocorre quando um núcleo envia intencionalmente uma resposta a uma
requisição não efetuada por outro núcleo da rede.
O envio de pacote sem terminador ocorre quando um núcleo envia os flits na rede, porém
nunca envia o flit com o terminador de pacote. O terminador sinaliza o núcleo de destino que todos
68
os flits já foram enviados à rede e que os mesmos podem ser reconstituídos em um pacote
novamente. O flit com o terminador também serve para liberar os buffers alocados nos roteadores
para a transmissão do pacote. Sem o envio do terminador, o espaço em memória alocada para o
recebimento dos flits no núcleo de destino poderá chegar ao seu limite, não permitindo o
recebimento de novos pacotes. Além de indisponibilizar o núcleo de destino, os novos flits ficam
bloqueados nos buffers dos roteadores ao longo do caminho, podendo indisponibilizar também a
rede.
Um ataque do tipo “mascaramento de endereço de origem” ocorre quando um núcleo envia
uma mensagem para outro núcleo forjando o seu próprio endereço de origem com outro endereço
da rede, causando tráfego na rede e podendo causar indisponibilidade nos núcleos envolvidos, dado
que a resposta à requisição é enviada a um núcleo que não a solicitou.
O ataque de interceptação da mensagem ocorre quando um núcleo intercepta os pacotes que
trafegam pela rede a fim de conhecer o conteúdo da mensagem. O ataque “interceptar a mensagem
e retransmitir” é uma variante do ataque anterior em que além de ser interceptada, a mensagem é
retransmitida como se fosse a mensagem original, degradando a rede e tentando indisponibilizar o
núcleo de destino. Outra variante consiste em interceptar a mensagem e depois reenviá-la com
conteúdo alterado. Este tipo de ataque corrompe a integridade da mensagem e pode causar
indisponibilidade no núcleo de destino.
4.2.2 Análise das vulnerabilidades da SoCIN
A análise das vulnerabilidades da SoCIN foram realizadas com base nas características de
roteamento da rede SoCIN.
Na SoCIN, os ataque de Deadlock e Livelock são resolvidos pelo mecanismo de roteamento
adotado, o qual restringe certas rotas que poderiam levar a esses problemas. Como a rede pode
adotar algoritmos determinísticos ou parcialmente adaptativos, que proíbem algumas realizações de
rotas que poderiam resultar em dependências cíclicas, a rede torna-se livre de Deadlock. Além
disso, como os algoritmos de roteamento adotados são do tipo mínimo, um pacote não pode se
afastar do seu destino, o que o levaria à possibilidade de sofrer com Livelock.
69
O ataque de Starvation é resolvido na SoCIN pelo mecanismo de arbitragem round-robin, o
qual assegura uma distribuição balanceada no uso dos canais de saída pelos pacotes, evitando a
postergação infinita de qualquer pacote, o que levaria ao Starvation.
Por outro lado, a SoCIN é vulnerável ao ataque de envio de pacotes para um endereço de
destino inválido, pois seus roteadores não verificam se o endereço destino do pacote está além das
fronteiras da rede ou se o endereço de destino é o próprio endereço do núcleo de origem. Um pacote
injetado com destino a um endereço além da fronteira da rede ficaria retido nessa fronteira,
bloqueando os recursos (buffers e enlaces) anteriores no seu caminho. Já um pacote injetado pelo
núcleo para o seu próprio endereço ficaria retido no canal de entrada do roteador, bloqueando o
envio de novos pacotes pelo núcleo. Uma solução para este tipo de ataque pode ser implementada
com um controle na interface entre o núcleo e o roteador, verificando se o destino do pacote está
além da fronteira da rede ou se é igual ao endereço do núcleo. Caso detecte alguma dessas
condições, o pacote é descartado.
Com relação ao ataque de repetição do envio de pacote para um determinado endereço, a
SoCIN não possui mecanismos para resolver esta situação. Uma solução para este tipo de ataque
pode ser feita implementando um mecanismo de controle de banda na interface entre o núcleo e o
roteador, limitando o tráfego do núcleo de acordo com parâmetros pré-definidos pelo projetista.
Quanto ao ataque de resposta a requisições não enviadas, a SoCIN não possui mecanismos
de proteção dado que, atualmente, requisições e respostas são tratadas como o mesmo tipo de
mensagem pela rede, não recebendo tratamentos diferenciados pela rede. A solução seria incluir
mecanismos de identificação de tipo de mensagem (requisição e resposta) e de verificação de
requisições com respostas pendentes nas interfaces entre o núcleo e o roteador. Ao receber um
pacote com uma resposta para a qual não foi enviada uma requisição, o mecanismo deveria
descartar o pacote.
A SoCIN também não possui mecanismos de proteção contra ataques de mascaramento de
endereço de origem. Uma solução para este tipo de ataque pode ser implementada com um controle
na interface entre o núcleo e o roteador, verificando se a origem do pacote é a mesma do endereço
local. Caso detecte alguma inconsistência, o pacote é descartado.
70
O ataque de envio de pacote sem terminador também é vulnerável na rede SoCIN. Uma
possível implementação para solucionar este tipo de ataque pode ser feito por um controlador na
interface entre o núcleo e o roteador. O controlador verifica o tamanho do pacote e caso o tamanho
atinja o limite máximo previamente estabelecido pelo projetista, um sinal de interrupção é
transmitido ao núcleo para abortar o envio dessa mensagem. Além disso, um pacote é criado com o
terminador e enviado a rede, finalizando assim o envio desse pacote e liberando os buffers alocados
nos roteadores da rede.
A SoCIN não possui mecanismos específicos contra ataques de interceptação da mensagem.
Porém, não há como ocorrer este tipo de ataque sem que seja feita uma modificação no hardware do
roteador, pois um pacote só é entregue ao seu endereço destino. Sendo assim, os ataques de
interceptação da mensagem e retransmissão e de interceptação da mensagem e de reenvio da
mensagem alterada também são inviáveis na rede SoCIN.
Um resumo dos ataques é apresentado no Quadro 8, informando se o ataque a SoCIN é
vulnerável e qual a solução de segurança adotada ou da possibilidade de implementação.
Quadro 8. Vulnerabilidade da rede SoCIN a possíveis ataques e soluções de segurança
Ataque
Deadlock
Livelock
Starvation
Envio de pacotes para um
endereço de destino inválido
Repetição do envio de pacote
para um determinado endereço
Responder a requisições não
enviadas
Mascaramento de endereço de
origem14
Envio de pacote sem
terminador
13
Tipo de Ataque
Negação de serviço
Negação de serviço
Negação de serviço
Negação de serviço
Vulnerável?
Não
Não
Não
Sim
Solução de segurança
Algoritmo de roteamento
Algoritmo de roteamento
Algoritmo de arbitragem
Controle de acesso
Negação de serviço
Sim
Controle de banda
Negação de serviço
Não
Disfarce
Sim
Controle na camada13 de
sessão ou aplicação
Controle de acesso
Negação de serviço
Sim
Controle de banda
Camada do modelo OSI que permite que as aplicações entre diferentes computadores (ou núcleos) possam estabelecer
uma sessão de comunicação, usando marcações nos dados que estão sendo transferidos.
14
Mascaramento do endereço de origem no contexto de redes de computadores é conhecido como IP spoofing. Um
ataque que consiste em mascarar (spoof) pacotes IP (Internet Protocol) utilizando endereços de remetentes falsificados.
71
Quadro 8. Vulnerabilidade da rede SoCIN a possíveis ataques e soluções de segurança (cont.)
Ataque
Interceptação da mensagem
Tipo de Ataque
Vulnerável? Solução de segurança
Liberação do conteúdo
Não
Garantia em nível de
da mensagem
hardware do roteador
Interceptar a mensagem e
Repetição
Não
Garantia em nível de
retransmitir
hardware do roteador
Interceptar mensagem e depois Repetição
Não
Garantia em nível de
reenviar a mensagem alterada
hardware do roteador
4.3 SELEÇÃO DE ATAQUES E PREMISSAS DE PROJETO
Conforme discutido na seção anterior, a rede SoCIN é principalmente vulnerável a ataques
de negação de serviço e de disfarce que visem comprometer a propriedade de disponibilidade. Por
conta disso, neste trabalho, optou-se pela busca de soluções em hardware para proteger a SoCIN
contra ataques de DoS.
Conforme discutido no Capítulo 3, no âmbito específico de NoCs, ataques de DoS foram
abordados por alguns autores. Diguet et al (2007) apresentaram uma solução de autenticação para
permitir somente transações autorizadas sejam liberadas pela interface de rede na NoC. No trabalho
de Fiorin, Silvano e Sami (2007), foram propostos mecanismos de QoS para limitar a largura de
banda por núcleo, evitando o consumo excessivo dos recursos da rede. Em outro trabalho, Fiorin,
Palermo e Silvano (2008) propuseram a inclusão de um mecanismo na interface de rede para
detectar e bloquear comportamento não natural do tráfego destinado ao núcleo. No trabalho de
Sepúlveda, Strum e Chau (2009), foi abordada a implementação de QoS para garantir largura de
banda para o tráfego de dados críticos. Com abordagem semelhante, Sepúlveda, Strum e Chau
(2010) adotaram uma combinação de técnicas de chaveamento por circuitos e por pacotes para
distinção entre os tráfegos de dados críticos e não críticos. Já Lukovic e Christianos (2010)
implementaram um mecanismo para analisar a execução da aplicação no núcleo, validando se o
comportamento é o correto.
Outros trabalhos também abordaram ataques de DoS, porém com o foco em SoC, são estes
os trabalhos: Patel e Parameswaran (2008a), Patel e Parameswaran (2008b), Abramovici e Bradley
(2009) e Patel e Parameswaran (2009).
Este trabalho teve como objetivo desenvolver soluções de segurança contra ataques de DoS
que incluem: (i) controle do pacote que é injetado à rede mediante a análise prévia da origem e do
72
destinatário do pacote e, consequente, descarte do pacote quando este violar regras de segurança; e
(ii) controle da largura de banda utilizada pelos fluxos de comunicação (controle de admissão) de
modo a assegurar que nenhum núcleo injete pacotes na rede a uma taxa maior do que a que foi
dimensionada pelo projetista do sistema.
Adicionalmente, como requisitos funcionais e não funcionais de projeto assumiu-se que:
1. Os núcleos conectados à rede são nativamente compatíveis com o protocolo da rede
SoCIN ou utilizam uma interface de rede que realiza a adaptação de protocolo, o
empacotamento e o desempacotamento de dados;
2. Os núcleos e as interfaces de rede (se utilizadas) não implementam mecanismos de
controle de acesso ou de controle de banda;
3. A rede não realiza descarte de pacotes e qualquer pacote bloqueado dentro da rede será
mantido infinitamente, provocando buffer overflow e levando ao bloqueio de outros
pacotes;
4. Soluções para outros tipos de ataque que possam ser implementados nos núcleos, nas
interfaces de rede ou nos roteadores não interferem nos mecanismos de proteção
propostos neste trabalho. Por exemplo, soluções como cifragem de dados ou de controle
de integridade não modificam os campos dos pacotes analisados pelos mecanismos
propostos; e
5. Os mecanismos propostos são implementados na forma de wrappers cujas
funcionalidades podem ser integradas futuramente à interface de rede ou à porta local do
roteador da rede SoCIN (à qual os núcleos são conectados à rede).
No contexto de hardware, um wrapper é um circuito lógico que envolve outro circuito
realizando alguma adaptação de sinais ou implementando uma lógica de cola. No contexto de redes
computadores, por exemplo, um TCP wrapper é um software usado para filtrar acessos à rede. No
âmbito deste trabalho, são desenvolvidos wrappers de hardware com o propósito de filtrar pacotes
que violem políticas de segurança e que comprometeriam a disponibilidade da rede SoCIN.
73
4.4 PROTEGENDO A REDE SOCIN CONTRA ATAQUES DE DOS
Nesta seção são apresentados dois mecanismos para aumentar a segurança da rede SoCIN
contra ataques de negação de serviço (DoS), em particular, ataques à propriedade de
disponibilidade. Os mecanismos são implementados dentro do componente denominado SEW
(SEcurity Wrapper), conectados no canal de saída do núcleo para a porta local de entrada do
roteador, conforme representado na Figura 17. Somente a saída dos pacotes do núcleo é analisada, a
entrada dos pacotes no núcleo permanece inalterada.
Figura 17. Implementação do mecanismo de segurança na rede SoCIN
A Figura 18 apresenta em detalhes o componente SEW, que é composto por dois wrappers
(nomeados de wrapper 1 e wrapper 2), uma FIFO e uma OFC. A inclusão da FIFO e da OFC foram
necessários para fazer um controle de fluxo em nível de flit, mas, em uma futura implementação,
esse controle poderia ser integrado aos componentes já existentes da NIC ou da porta local do
roteador. Nos wrappers, estão implementados os filtros contra os ataques de DoS a rede. No
wrapper 1, é implementado o mecanismo de controle de endereço origem e destino e, no wrapper 2,
é implementado o controle de banda. O sinal de saída IRQ (Interrupt Request Line) é utilizado para
sinalizar o núcleo de que houve uma tentativa de ataque e uma ação de segurança foi realizada,
como, por exemplo o descarte do pacote. O funcionamento e a estrutura dos wrappers são
detalhados nas subseções seguintes.
74
Figura 18. Detalhamento do componente SEW
4.4.1 Controle de endereço origem e destino – Wrapper 1
O envio de pacotes para um endereço de destino inexistente causa congestionamentos na
NoC e, consequentemente, pode indisponibilizar toda a comunicação entre os núcleos. A solução
proposta para solucionar esse tipo de ataque é implementar um wrapper na porta local para verificar
o endereço de destino de todos os pacotes a serem enviados. Se o pacote estiver endereçado para
uma posição inválida (ou seja, endereço do próprio núcleo ou endereço além das fronteiras da rede),
o pacote é descartado, não consumindo os recursos do roteador.
Neste mesmo wrapper, também pode se verificar se o endereço de origem do pacote é
realmente o endereço deste núcleo, ou seja, do núcleo local. Com essa implementação, qualquer
tentativa de mascaramento de endereço de origem (disfarce) pode ser evitada. Somente os pacotes
com as origens corretas são enviados para o roteador, caso contrário são descartados.
Este wrapper pode ser implementado por um circuito digital com dois blocos (Figura 19): (i)
uma FSM (Finite State Machine, ou máquina de estados finitos); e (ii) um bloco operativo
(datapath ou caminho de dados), chamado de Attack Detector. O bloco Attack Detector possui
quatro parâmetros informados em nível de projeto no momento de sua instanciação na rede:
75
1. p_X_ID: Posição X do núcleo na rede15;
2. p_Y_ID: Posição Y do núcleo na rede;
3. p_X_SIZE: Tamanho da rede na dimensão X; e
4. p_Y_SIZE: Tamanho da rede na dimensão Y.
Figura 19. Diagrama de bloco do wrapper que detecta ataque de endereçamento
Quando o cabeçalho de pacote é recebido pelo wrapper (o que é sinalizado pela ativação dos
sinais i_VAL e i_BOP, com i_EOP em 0), o bloco Attack Detector compara os campos de endereço
de origem (w_X_SRC e w_Y_SRC) e endereço de destino (w_X_DST e w_Y_DST) no flit com os
parâmetros informados. Se a comparação detectar um ataque, um sinal w_ATTACK é enviado ao
controle (FSM), o qual é responsável por ativar o comando de descarte do pacote (w_FLUSH). Se
15
Este trabalho utiliza a convenção de denominação de parâmetros e sinais do grupo de pesquisa ao qual está associado
(o Laboratório de Sistemas Embarcados e Distribuídos) para o projeto de hardware. Os nomes são escritos em caixa alta
e precedidos pelos seguintes: p_ para parâmetros; i_ (de input) para sinais de entrada; o_ (de output) para sinais de
saída; e w_ (de wire) para sinais internos (fios).
76
não houver ataque, o pacote é encaminhado com a ativação dos sinais de controle de fluxo,
correspondentes ao recebimento dos flits do pacote enviados pelo núcleo (o_RET) e envio desses
flits ao roteador (o_VAL). O descarte é feito com a ativação de o_RET, sem a ativação do sinal
o_VAL.
Um ataque é detectado se uma das condições a seguir for verdadeira:

Se o endereço de origem na posição X (w_X_SRC) for diferente do parâmetro p_X_ID;

Se o endereço de origem na posição Y (w_Y_SRC) for diferente do parâmetro p_Y_ID;

Se o endereço de destino nas posições X e Y (w_X_DEST e w_Y_DEST) forem iguais,
simultaneamente às coordenadas do núcleo (parâmetros p_X_ID e p_Y_ID,
respectivamente);

Se o endereço de destino na posição X (w_X_DEST) for maior ou igual ao tamanho da
rede na dimensão X (p_X_SIZE); ou

Se o endereço de destino na posição Y (w_Y_DEST) é maior ou igual ao tamanho da
rede na dimensão Y (p_Y_SIZE).
O Quadro 9 apresenta a tabela-verdade que descreve função do bloco Attack Detector, ou
seja, para detectar os ataques de endereço de destino inválido e de mascaramento de endereço de
origem.
Quadro 9. Tabela-verdade que descreve a função para detectar ataque de endereçamento
Entradas
i_VAL
i_BOP i_EOP w_X_SRC w_Y_SRC
Saídas
w_X_DST
w_Y_DST
w_ATTACK
o_VAL o_RET
0
×
×
×
×
×
×
0
i_VAL
i_RET
1
0
×
×
×
×
×
0
i_VAL
i_RET
1
1
0
≠ p_X_ID
×
×
×
1
0
1
1
1
0
×
≠ p_Y_ID
×
×
1
0
1
1
1
0
×
×
= p_X_ID
= p_Y_ID
1
0
1
1
1
0
×
×
≥ p_X_SIZE
×
1
0
1
1
1
0
×
×
×
≥ p_Y_SIZE
1
0
1
1
1
0
< p_X_SIZE
< p_Y_SIZE
0
i_VAL
i_RET
= p_X_ID = p_Y_ID
Nota: Neste projeto, considera-se uma nova implementação da SoCIN em que o cabeçalho é marcado por bop-eop =
“10”. As outras combinações referem-se a: “00” = flit do corpo do pacote; “11” = flit do corpo do pacote com bits
invertidos (decorrente do uso de técnica para redução de consumo de energia na comunicação); e “10” = terminador.
77
Na Figura 20, é mostrada a FSM do wrapper. Enquanto nenhum ataque é detectado, o
estado da FSM permanece em Idle. Caso um ataque ocorra, o estado da FSM muda para Flushing,
ativando o sinal w_FLUSH para descartar os flits do pacote. Enquanto o estado Flushing não recebe
os sinais de entrada de i_VAL e i_EOP em 1 e i_BOP em 0, o estado continua em Flushing,
descartando os flits.
Figura 20. FSM do wrapper que detecta ataque de endereçamento
Na Figura 21, é representado o caminho de dados do circuito digital que implementa a
lógica discutida anteriormente. Quando o i_VAL e i_BOP estiverem ativos e i_EOP em zero, um
cabeçalho é detectado (w_HEADER_PRESENT = 1) e o sinal w_ATTACK é habilitado, sendo o
seu estado definido pelos circuitos de detecção de ataque que analisam as condições descritas no
Quadro 9.
78
Figura 21. Circuito digital do wrapper que detecta ataque de endereçamento
4.4.2 Controle de banda – Wrapper 2
O ataque de envio de pacotes repetidamente com o intuito de causar congestionamentos na
NoC aumenta a latência da comunicação dos demais pacotes. A solução proposta para solucionar
esse tipo de ataque é implementar um wrapper entre o núcleo e o roteador para controlar a banda
utilizada pelos fluxos de comunicação gerados pelo núcleo.
O wrapper contabiliza a quantidade de ciclos de relógio gastos para enviar um pacote ao
roteador, retardando o envio do próximo pacote por um período mínimo proporcional à largura de
banda máxima alocada pelo projetista do sistema ao núcleo.
Este wrapper pode ser implementado por um circuito digital usando três blocos (Figura 22):
(i) uma FSM; (ii) um contador crescente e decrescente denominado COUNT; e (iii) um circuito de
deslocamento chamado CALC.
79
Figura 22. Circuito digital do wrapper de controle de banda
Ao enviar um pacote à rede, o sinal de i_BOP é ativado e a FSM habilita o bloco de controle
COUNT. Primeiramente, é zerada a contagem anterior e então habilitada a contabilização da
quantidade de ciclos de relógio gastos pelo pacote desde o recebimento do cabeçalho até o final do
envio do pacote. O bloco CALC lê a contagem dos ciclos de relógio gastos do bloco COUNT e
calcula quanto tempo de penalização será dado para o envio do próximo pacote. Esse tempo é
calculado pela porcentagem informada pelo projetista. O resultado deste cálculo é retornado para o
bloco COUNT. Quando o terminador do pacote é recebido, a FSM muda a operação do bloco
COUNT para carregar o valor do bloco CALC e decrementar o seu valor. Quando o valor chega à
zero, um sinal (w_CONTINUE) é enviado à FSM para que o próximo pacote possa ser enviado.
Para evitar que pacotes com tamanho grande (acima de um determinado limite) sejam
injetados na rede, no bloco COUNT, é verificado se a quantidade de ciclos de relógio gasto para
enviar um pacote é maior do que parâmetro limite informado pelo projetista (p_SIZE). Caso isso
80
ocorra, o pacote é truncado com a inserção de um terminador no flit atual (eop = 1 e bop = 0),
possibilitando que a rede libere os buffers alocados. Todos os novos flits relacionados a esse pacote
serão descartados até que o seu terminador seja recebido pelo wrapper, caracterizando o fim do
pacote. Em um ataque, é possível que, de forma mal intencionada, o terminador do pacote nunca
seja recebido pelo wrapper. Neste caso, o núcleo mal intencionado ficará bloqueado infinitamente,
mas a rede estará protegida contra este tipo de ataque.
A Figura 23 apresenta o diagrama da FSM. Enquanto não houver um pacote a ser enviado, o
estado da FSM fica em Idle. Neste estado, o contador é zerado para que, no estado Forward, este
contabilize o número de ciclos gastos pelo pacote. Ao finalizar o envio do pacote, o estado Load 1
carrega a penalidade calculada e, no estado Wait, o circuito fica aguardando conforme o tempo da
penalidade. Caso o número de flits transferidos atinja o valor limite informado pelo projetista, a
FSM vai para o estado Break e, no estado seguinte, Send EOP, um terminador é injetado, quebrando
o pacote. No Load 2, é carregado o tempo de penalidade e, no estado Wait EOP, o contador fica
decrementando o valor da penalidade enquanto espera pelo terminador do pacote. Por fim, se ainda
houver algum tempo a ser penalizado, o estado Wait aguarda até terminar a penalidade.
81
Figura 23. Diagrama da FSM do controle de banda
No Quadro 10, é apresentada a tabela-verdade do bloco COUNT e, na Figura 24, a
representação do circuito digital deste bloco.
Quadro 10. Tabela-verdade que descreve a função do contador do bloco COUNT
i_CLR
i_ENA
i_SEL
i_OP
o_COUNT*
1
×
×
×
0
0
o_COUNT + 1
1
o_COUNT – 1
×
o_COUNT
0
0
1
1
2
×
i_COUNT
* Nota: o registrador o_COUNT é atualizado no final do ciclo de relógio (exceto
quando i_CLR igual a 1, pois esta é uma entrada assíncrona)
82
Figura 24. Circuito digital do bloco COUNT
O circuito digital do bloco CALC, ilustrado na Figura 25, permite que o projetista informe o
valor para o percentual de largura de banda alocado ao canal. Pelo valor informado, é selecionado
um deslocador que irá definir a penalização a ser aplicada ao fluxo de comunicação a partir do
número de ciclos gastos pelo último pacote. Ou seja, será calculada a quantidade de ciclos de espera
após os quais o próximo pacote poderá ser injetado, conforme explicado a seguir.
83
Figura 25. Circuito digital do bloco CALC
O Quadro 11 apresenta os possíveis valores para o percentual de penalidade. Na escolha do
valor 0 (zero), é disponibilizada 100% da largura de banda do canal e os envios dos pacotes não
serão penalizados. Mas, por exemplo, se o projetista alocar uma largura de banda de 33%,
escolhendo o seletor 3 como parâmetro p_PERCENT, o valor recebido pela entrada i_COUNT será
multiplicado por 2 por meio de uma operação de deslocamento de um bit à esquerda. Assim, com
uma penalidade de 2 × i_COUNT a largura de banda alocada ao pacote será limitada a
i_COUNT/(i_COUNT + 2 × i_COUNT), ou seja, 1/3 ou 33%.
Quadro 11. Seleção de largura de banda alocada
Largura de banda alocada
100%
11%
20%
33%
50%
67%
80%
89%
Seletor p_PERCENT
0
1
2
3
4
5
6
7
o_COUNT
0
i_COUNT × 8 = i_COUNT << 3
i_COUNT × 4 = i_COUNT << 2
i_COUNT × 2 = i_COUNT << 1
i_COUNT ÷ 1 = i_COUNT >> 0
i_COUNT ÷ 2 = i_COUNT >> 1
i_COUNT ÷ 4 = i_COUNT >> 2
i_COUNT ÷ 8 = i_COUNT >> 3
84
Considerando o exemplo de alocação de 33% da largura de banda, se um pacote consumir 4
ciclos de relógio, o próximo pacote terá que aguardar 8 ciclos de relógio de penalidade para ser
enviado para que caracterize o uso de 33% (4/12 = 1/3) da largura de banda do canal pelo pacote
anterior a ele. Se o pacote levar 50 ciclos de relógio, o próximo pacote só poderá ser enviado após
100 ciclos de relógio (ou seja, 50/150 = 1/3 = 33%).
O circuito proposto utiliza deslocadores (shifters) para implementar operações de
multiplicação e de divisão por potências de 2 (i.e. 1, 2, 4 e 8), pois isso permite obter uma solução
de baixo custo. Porém, por outro lado, essa solução faz com que o cálculo seja limitado pelas
potências de 2. Por exemplo, o circuito não permite escolher uma largura de banda de 25%, pois
isso implicaria em multiplicar i_COUNT por 3 (25% = 1/(1+3)), o qual não pode ser calculado por
um potência de 2.
4.5 CONSIDERAÇÕES
A rede SoCIN, com o roteador ParIS, permite criar NoCs com diferentes configurações para
a análise do projetista. O BrownPeeper oferece uma melhor usabilidade para o projetista na
parametrização, geração de tráfego e também na análise dos resultados mediante a simulação.
Assim como outras NoCs, a SoCIN também possui vulnerabilidades. A análise feita
identificou alguns tipos de ataques possíveis à rede SoCIN. Como resultado da análise, foram
propostos mecanismos de hardware para garantir a propriedade de segurança de disponibilidade à
rede SoCIN aos ataques especificados.
A proposta de implementação de um wrapper na porta local para verificar o endereçamento
de origem e de destino evita ataques de envio de pacote a destinatários inválidos e ao mascaramento
do endereço de origem. Com a proposta da implementação de outro wrapper para controle de
banda, é possível reduzir o risco do ataque DoS de repetição do envio de pacote e do ataque DoS de
pacotes com tamanho grande ou sem o flit com o terminador.
85
5 IMPLEMENTAÇÃO E AVALIAÇÃO
Neste capítulo, são discutidos aspectos referentes à implementação e à avaliação dos
wrappers propostos no capítulo anterior.
5.1 IMPLEMENTAÇÃO EM VHDL
A implementação descrita em VHDL foi realizada utilizando o ambiente de
desenvolvimento Quartus II versão 12.0 da Altera e sintetizada para a tecnologia de dispositivo
lógico programável FPGA (Field Programmable Gate Array). Posteriormente foi sintetizada para
uma tecnologia ASIC (Application Specific Integrated Circuit), usando a ferramenta Design
Compiler da Synopsys. As ilustrações dos diagramas RTL (Register Transfer Level) foram geradas
pós-síntese diretamente pela ferramenta Quartus II e evidenciam a viabilidade de implementação
física dos mecanismos propostos.
5.1.1 Diagramas RTL do Wrapper 1
A Figura 26 apresenta o diagrama RTL do Wrapper 1, detalhando os blocos Attack Detector
(w1_attackdetector), a FSM (w1_fsm), os fios de interconexão e suas portas de entrada e saída. O
diagrama RTL da estrutura interna do bloco Attack Detector é apresentada na Figura 27.
Figura 26. Diagrama RTL do Wrapper 1
86
Figura 27. Diagrama RTL da estrutura interna do bloco Attack Detector
5.1.2 Diagramas RTL do Wrapper 2
A Figura 28 apresenta o diagrama RTL do Wrapper 2, detalhando os blocos CALC
(w2_calc), COUNT (w2_count), a FSM (w2_fsm), os fios de interconexões e suas portas de entrada
e saída.
Figura 28. Diagrama RTL do Wrapper 2
87
O diagrama RTL da estrutura interna do bloco COUNT é apresentada na Figura 29.
Figura 29. Diagrama RTL do bloco COUNT
O diagrama RTL da estrutura interna do bloco CALC é diferente do diagrama de bloco
apresentado na Seção 4.4.2. Apesar da diferença, a funcionalidade é a mesma. O valor do percentual
de largura de banda é informado pelo projetista durante a fase de projeto. A ferramenta gera os
componentes personalizados para a execução de somente ao cálculo daquele percentual de largura
de banda informado. Na Figura 30, é apresentado o diagrama RTL do hardware gerado pela
ferramenta para todos os valores: (a) 100% de largura de banda; (b) 11% de largura de banda; (c)
20% de largura de banda; (d) 33% de largura de banda; (e) 50% de largura de banda; (f) 67% de
largura de banda; (g) 80% de largura de banda; e (h) 89% de largura de banda.
88
Figura 30. Diagrama RTL do bloco CALC
5.1.3 Resultados de síntese
Os wrappers foram sintetizados utilizando a ferramenta Quartus II para o dispositivo FPGA
EP2C35F672C6 da família Cyclone II da Altera. O custo silício de uma instância dos wrappers foi
comparado com o de uma instância do roteador ParIS e da interface de rede XIRU (eXtensible
InteRface Unit). A XIRU é uma interface de rede extensível desenvolvida para a rede SoCIN e que
utiliza uma arquitetura em camadas a fim de facilitar a geração de variantes compatíveis com
diferentes protocolos intrachip e a inclusão de novos serviços à interface (MELO, 2012). Os
resultados do roteador ParIS referem-se a uma instância com 5 portas de comunicação, com canais
de 32 bits, um buffer FIFO de 4 flits em cada canal de entrada, utilizando roteamento XY, controle
de fluxo baseado em créditos, chaveamento por pacotes do tipo wormhole e arbitragem roundrobin. Já os resultados da interface XIRU referem-se a uma instância com dois canais de
comunicação e um buffer FIFO de 4 flits em cada canal (entrada e saída), oferecendo os serviços de
adaptação ao barramento Avalon, empacotamento e desempacotamento de dados, controle de
integridade em nível de flit (paridade) e redução da atividade de chaveamento baseada na
codificação bus invert.
A Tabela 1 apresenta uma síntese dos custos em circuitos combinacionais (LUTS – LookUp Tables), em circuitos sequenciais (FFs – Flip-Flops, ou registradores) e da frequência máxima
de operação (Fmax).
89
Tabela 1. Síntese em FPGA comparada com o ParIS e a XIRU
Componente
paris
xiru
wrappers
LUTs
918
566
79
FFs
800
436
18
Fmax (MHz)
164,74
253,49
417,89
Obs: Dispositivo Altera EP2C35F672C6
Pela análise da tabela, observa-se que os wrappers representam 13,9% do custo de LUTs da
interface XIRU e 8,6% do roteador ParIS. Analisando o custo de FFs, os wrappers representam
4,1% da XIRU e 2,2% de ParIS. Referente a Fmax, os wrappers por ter uma frequência máxima de
operação maior que os outros componentes, se incorporados na XIRU ou em ParIS, os mesmos não
limitarão a frequência de operação do sistema.
Conforme é mostrado na Tabela 2, considerando um núcleo composto pelo roteador ParIS,
pela interface XIRU e pelos wrappers propostos nesta dissertação, observa-se que o custo dos
wrappers tem uma ordem de magnitude menor que os demais componentes, adicionando um custo
reduzido ao sistema.
Tabela 2. Custos relativos em um núcleo ParIS + XIRU + Wrappers
Componente
paris
xiru
wrappers
LUTs
58,73%
36,21%
5,05%
FFs
63,80%
34,77%
1,44%
Obs: Dispositivo Altera EP2C35F672C6
A Tabela 3 apresenta o percentual da síntese dos custos em circuitos combinacionais
(LUTS) e em circuitos sequenciais (FFs) de cada um dos dois wrappers desenvolvidos. O maior
percentual, tanto de LUTs como de FFs, é do wrapper 2, dado que utiliza um circuito de maior
complexidade.
90
Tabela 3. Custos de silício em FPGA de cada wrapper
Componente
wrapper 1
wrapper 2
% LUTs
17%
83%
% FFs
11%
89%
Obs: Dispositivo Altera EP2C35F672C6
Os wrappers também foram sintetizados na tecnologia ASIC de 90nm utilizando-se a
ferramenta Design Compiler da Synopsys com a biblioteca saed90nm e condições de operação no
modo TYPICAL. Foi realizada a síntese lógica e com frequência de operação de 100 MHz. Como
resultado, obteve-se a área de silício expressa em µm² e a frequência máxima de operação. A Tabela
4 apresenta os resultados da síntese em ASIC incluindo: a área de silício ocupada, a quantidade de
portas lógicas16, a frequência máxima de operação e a potência dissipada para cada um dos
componentes (ParIS, XIRU e wrappers). Observa-se que os wrappers ocupam uma área total
correspondente a 7,26% da área ocupada pela XIRU e a 4,13% da área ocupada pelo roteador ParIS,
ressaltando-se que essa área corresponde ao somatório das áreas gastas com lógica combinacional,
lógica sequencial e interconexões. Esses resultados são diferentes dos que foram expressos
anteriormente para a tecnologia FPGA, pois estes últimos separaram os recursos consumidos pelos
circuitos combinacionais e sequenciais. Com relação à frequência máxima de operação, observa-se
que os wrappers podem operar a uma frequência maior que os demais componentes, não
comprometendo o desempenho da rede. Finalmente, destaca-se que os wrappers apresentam uma
baixa dissipação de potência quando comparada com a potência dissipada pela XIRU e pelo ParIS.
16
O número aproximado de portas lógicas foi determinado pela razão entre a área do componente e a área da porta
lógica básica utilizada pela tecnologia-alvo. Na biblioteca saed90nm_typ, corresponde a uma porta NAND2, com área
de 5,5296 µm².
91
Tabela 4. Síntese em ASIC comparada com o ParIS e a XIRU
Componente
paris
xiru
wrappers
Área
(µm²)
47.905,37
27.278,70
1.982,12
Portas Lógicas
Equivalentes
8.664
4.934
358
Fmax Potência @ 100 MHz
(MHz)
(µW)
218,34
947,42
139,66
447,52
250,62
23,41
Obs: Tecnologia ASIC SAED 90nm da Synopsys
Na Tabela 5, é apresentado o percentual dos custos em ASIC de cada wrapper. Assim como
nos resultados em FPGA, o wrapper 2 é o componente de maior custo, ocupando 84% da área total
do wrapper e respondendo por 85% da potência dissipada.
Tabela 5. Custos de silício em ASIC de cada wrapper
Componente
wrapper 1
wrapper 2
% Área
16%
84%
% Potência
15%
85%
Obs: Tecnologia ASIC SAED 90nm da Synopsys
5.1.4 Verificação baseada em simulação
A verificação do correto funcionamento dos circuitos implementados e a confirmação do
atendimento das suas especificações foi feita com base em simulação funcional utilizando-se a
ferramenta ModelSim-Altera Starter Edition 10.0d da Mentor Graphics.
Foi descrito um sistema constituído de um testbench e do módulo SEW – Security Wrapper
(Figura 31), operando a uma frequência de 1 GHz (ciclo de relógio igual a 1 ns). O testbench foi
descrito para gerar fluxos que representassem os ataques à propriedade disponibilidade
considerados neste trabalho. O tamanho máximo permitido para um pacote ser injetado na rede é
de 10 flits, valor definido em nível de projeto para os testes e para facilitar a visualização de um
ataque com um pacote grande no diagrama de forma de ondas.
92
Figura 31. Bloco testbench e o bloco SEW
O Quadro 12 sumariza os ataques modelados a fim de testar o correto funcionamento,
através da simulação, da solução desenvolvida.
Quadro 12. Ataques modelados para o experimento
Ataque
Implementação
Envio de pacote a um endereço de destino na posição X maior que
ao tamanho da rede
Envio de pacotes para um
Envio de pacote a um endereço de destino na posição Y maior que
endereço de destino
ao tamanho da rede
inexistente
Envio de pacote ao próprio endereço do núcleo
Envio de pacote com a posição de origem X diferente do endereço
Mascaramento de endereço do núcleo
de origem
Envio de pacote com a posição de origem Y diferente do endereço
do núcleo
Repetição do envio de
Envio de um pacote com número de flits maior do que o permitido
pacote para um
Envio de vários pacotes em sequência, sem intervalo
determinado endereço
Na Figura 32, é apresentado o diagrama em formas de onda da injeção de um pacote sem
ataque, da origem (1,1) para o destino (2,2). Esses endereços estão codificados nos quatro dígitos
menos significativos do flit cabeçalho os quais representam as coordenadas do núcleo origem
(XSRC, YSRC) e do núcleo destinatário (XDST, YDST). Observa-se que o pacote possuiu apenas 3
flits: (a) o cabeçalho; (b) um flit de payload; e (c) o terminador. Como o wrapper 2 possui um
registrador, é inserido um atraso de 1 ciclo de relógio entre a entrada do flit no SEW (sinal
i_DATA) até a sua saída (sinal o_DATA). Disso, conclui-se que os wrappers impactam no
desempenho da comunicação adicionando um 1 ciclo à latência de transferência dos pacotes. O
sinal o_VAL ativo (= 1) determina que existe um flit válido no canal de saída e o sinal o_IRQ não
ativo = 0) indica que nenhum ataque foi encontrado nesse pacote.
93
1
2
(b)
(a)
3
4
(c)
(b)
(a)
(c)
Figura 32. Envio de um pacote sem ataque - VHDL
Na Figura 33 é apresentado o diagrama de formas de onda do ataque com o envio de pacote
a um endereço de destino com posição X igual a 7 e, por tanto, maior que o tamanho da rede (NoC
3x3). Como houve uma tentativa de ataque, o sinal o_IRQ foi ativado (a), indicando que um ataque
foi detectado, e que o pacote foi descartado. Por isso, sinal o_VAL não é ativado (b).
1
2
3
4
(b)
(a)
Figura 33. Envio de um ataque a um endereço de destino X maior que ao tamanho da rede
Na Figura 34, é apresentado o diagrama de formas de onda do ataque com o envio de pacote
a um endereço de destino na posição Y igual a 7 e, portanto, maior que o tamanho da rede (NoC
3x3). Como houve uma tentativa de ataque, o sinal o_IRQ foi ativado (a), para sinalizar o ataque, e
o pacote foi descartado, não ativando o sinal o_VAL (b).
94
1
2
3
4
(b)
(a)
Figura 34. Envio de um ataque a um endereço de destino Y maior que ao tamanho da rede
Na Figura 35, é apresentado o diagrama de formas de onda do ataque com envio de pacote
ao próprio endereço do núcleo, ou seja, endereço destino igual a (1,1). Como houve uma tentativa
de ataque, o sinal o_IRQ foi ativado (a), para sinalizar o ataque, e o pacote foi descartado, não
ativando o sinal o_VAL (b).
1
2
3
4
(b)
(a)
Figura 35. Envio de um ataque com endereço de destino ao próprio o núcleo de origem
Na Figura 36, é apresentado o diagrama de formas de onda do ataque com o envio de pacote
com a posição de origem XSRC igual a 2 e, portanto, diferente do endereço do núcleo (1,1). Como
houve uma tentativa de ataque, o sinal o_IRQ foi ativado (a), para sinalizar o ataque, e o pacote foi
descartado, não ativando o sinal o_VAL (b).
95
1
2
3
4
(b)
(a)
Figura 36. Envio de um ataque com a posição de origem X diferente do endereço do núcleo
Na Figura 37, é apresentado o diagrama de formas de onda do ataque de envio de pacote
com a posição de origem YSRC igual a 2, ou seja, diferente do endereço do núcleo (1,1). Como
houve uma tentativa de ataque, o sinal o_IRQ foi ativado (a), para indicar a detecção do ataque, e o
pacote foi descartado, não ativando o sinal o_VAL (b).
1
2
3
4
(b)
(a)
Figura 37. Envio de um ataque com a posição de origem Y diferente do endereço do núcleo
Na Figura 38, é apresentado o diagrama de formas de onda do ataque de envio de um pacote
com número de flits maior do que o permitido. Para esse exemplo, foi definido um limite máximo
de 6 flits de payload. Quando esse número é atingido, o sinal o_IRQ é ativado (a), sinalizando o
ataque. Nesse momento o envio do pacote é interrompido e um flit terminador é gerado (b). No
entanto, o wrapper continua consumindo flits recebidos do núcleo, descartando-os até receber o
terminador original do pacote (c). O descarte dos flits é caracterizado pela não ativação do sinal
o_VAL (d), o qual serve para sinalizar o encaminhamento dos flits. Se um fim de pacote não for
detectado, o wrapper vai continuar descartando os flits indeterminadamente.
96
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
(c)
(b)
(a)
Figura 38. Envio de um ataque com número de flits maior do que o permitido
(d)
97
Para proteger a rede de ataques que visem consumir a largura de banda da rede, o projetista
pode definir, em nível de projeto, a largura de banda máxima a ser alocada ao núcleo. O wrapper
deve assegurar que essa largura de banda seja respeitada. Os diagramas de formas de onda a seguir
ilustram o funcionamento do wrapper quando da transferência de um fluxo composto por pacotes
com 13 flits no total (sendo 11 de payload) para diferentes configurações de alocação largura de
banda, incluindo: 100% (Figura 39), 11% (Figura 40), 20% (Figura 41), 33% (Figura 42), 50%
(Figura 43), 67% (Figura 44), 80% (Figura 45), 89% (Figura 46). A máquina de estados do wrapper
2 adicionou uma latência de 2 ciclos de relógio para o envio de um pacote após outro. Portanto, a
utilização de 100% da largura de banda não é possível. Além disso, devido ao truncamento do
cálculo dos ciclos de espera, feito por operações deslocamento lógico, o percentual pode não ser
preciso.
Na Figura 39, é alocada uma largura de banda de 100%, porém, são inseridos dois ciclos de
espera entre dois pacotes sucessivos, conforme já citado. Na Figura 40, são inseridos 98 ciclos de
espera para uma largura de banda alocada de 11%. Nas próximas figuras, são inseridas,
respectivamente, as seguintes quantidades de ciclos de espera: 50 ciclos, 26 ciclos, 14 ciclos, 7
ciclos e 5 ciclos.
(a)
Figura 39. Envio de vários pacotes sem intervalo com 100% da largura de banda
13 ciclos
11%
Aguardando 98 ciclos
89%
Figura 40. Envio de vários pacotes sem intervalo com 11% da largura de banda
98
13 ciclos
20%
Aguardando 50 ciclos
80%
Figura 41. Envio de vários pacotes sem intervalo com 20% da largura de banda
13 ciclos
33%
Aguardando 26 ciclos
67%
Figura 42. Envio de vários pacotes sem intervalo com 33% da largura de banda
13 ciclos
48%
Aguardando 14 ciclos
52%
Figura 43. Envio de vários pacotes sem intervalo com 50% da largura de banda
13 ciclos
65%
Aguardando 7 ciclos
35%
Figura 44. Envio de vários pacotes sem intervalo com 67% da largura de banda
99
13 ciclos
72%
Aguardando 5 ciclos
28%
Figura 45. Envio de vários pacotes sem intervalo com 80% da largura de banda
13 ciclos
81%
Aguardando
3 ciclos 19%
Figura 46. Envio de vários pacotes sem intervalo com 89% da largura de banda
Os resultados de simulação apresentados nesta subseção comprovam o correto
funcionamento dos wrappers implementados em VHDL.
5.2 IMPLEMENTAÇÃO EM SYSTEMC
A implementação em SystemC foi realizada utilizando a versão do conjunto de bibliotecas
C++ SystemC 2.3.0 e o BrownPepper com o objetivo de validar e avaliar a operação dos wrappers
quando integrados à rede SoCIN. O BrownPepper foi adotado para o auxílio nos testes e simulação
da implementação, na qual foram utilizados os geradores de tráfego (TGs – Traffic Generators)
padrão da ferramenta para gerar o tráfego na rede SoCIN e um módulo de ataque denominado ATG
(Attacker Traffic Generator), desenvolvido nesta dissertação para gerar ataques pré-definidos na
rede. A Figura 47 apresenta o diagrama de blocos da NoC 3x3 utilizada nos experimentos. Cada
roteador possui um TG conectado na porta local, exceto o roteador localizado no centro da NoC,
posição (1,1), que possui um ATG conectado na sua porta local.
100
Figura 47. Diagrama da NoC 3x3 utilizada nos experimentos em SystemC
5.2.1 Simulação
Os mesmos ataques validados em VHDL foram utilizados para a simulação em SystemC.
Na Figura 48 é apresentado o diagrama em formas de onda da injeção de um pacote sem ataque, da
origem (1,1) para o destino (0,0). O pacote possui 4 flits: (a) o cabeçalho; (b) dois flits de payload; e
(c) o terminador. Devido ao registrador do wrapper 2, um atraso de 1 ciclo de relógio é inserido
entre a entrada do flit no SEW (sinal L_1_1_in_data) até a sua saída (sinal L_1_1_out_data). O
sinal L_1_1_in_val_wire_sew é ativado (VAL=1) durante a permanecia do dado válido na entrada
do roteador e o sinal L_1_1_out_ret_wire_sew não é ativado (IRQ=0), indicando que nenhum
ataque foi encontrado nesse pacote.
Figura 48. Envio de um pacote sem ataque – SystemC
101
Na Figura 49 é apresentado o diagrama de formas de onda do ataque com o envio de pacote
a um endereço de destino (8,1) e, portanto, maior que o tamanho da rede (NoC 3x3) na posição X.
Como houve uma tentativa de ataque, o sinal IRQ (L_1_1_out_irq_wire_sew) foi ativado (a),
indicando que um ataque foi detectado, e que o pacote foi descartado. Por isso, sinal VAL
(L_1_1_in_val_wire_sew) não é ativado (b).
Figura 49. Envio de um ataque a um endereço de destino X maior que ao tamanho da rede –
SystemC
Na Figura 50, é apresentado o diagrama de formas de onda do ataque com o envio de pacote
a um endereço de destino (1,8) e, portanto, maior que o tamanho da rede (NoC 3x3) na posição Y.
Como houve uma tentativa de ataque, o sinal IRQ (L_1_1_out_irq_wire_sew) foi ativado (a),
indicando que um ataque foi detectado, e que o pacote foi descartado. Por isso, sinal VAL
(L_1_1_in_val_wire_sew) não é ativado (b).
Figura 50. Envio de um ataque a um endereço de destino Y maior que ao tamanho da rede –
SystemC
Na Figura 35, é apresentado o diagrama de formas de onda do ataque com envio de pacote
ao próprio endereço do núcleo, ou seja, endereço destino igual a (1,1). Como houve uma tentativa
de ataque, o sinal IRQ (L_1_1_out_irq_wire_sew) foi ativado (a), indicando que um ataque foi
detectado, e que o pacote foi descartado, não ativando o sinal VAL (L_1_1_in_val_wire_sew) (b).
102
Figura 51. Envio de um ataque com endereço de destino ao próprio o núcleo de origem – SystemC
Na Figura 52, é apresentado o diagrama de formas de onda do ataque com o envio de pacote
com origem (2,1) e, portanto, diferente do endereço do núcleo na posição de origem XSRC. Como
houve uma tentativa de ataque, o sinal IRQ (L_1_1_out_irq_wire_sew) foi ativado (a), para
sinalizar o ataque, e o pacote foi descartado, não ativando o sinal VAL (L_1_1_in_val_wire_sew)
(b).
Figura 52. Envio de um ataque com a posição de origem X diferente do endereço do núcleo –
SystemC
Na Figura 53, é apresentado o diagrama de formas de onda do ataque com o envio de pacote
com origem (2,1) e, portanto, diferente do endereço do núcleo na posição de origem YSRC. Como
houve uma tentativa de ataque, o sinal IRQ (L_1_1_out_irq_wire_sew) foi ativado (a), para
sinalizar o ataque, e o pacote foi descartado, não ativando o sinal VAL (L_1_1_in_val_wire_sew)
(b).
103
Figura 53. Envio de um ataque com a posição de origem Y diferente do endereço do núcleo –
SystemC
Na Figura 54, é apresentado o diagrama de formas de onda do ataque de envio de um pacote
com número de flits maior do que o permitido. Para esse exemplo, foi definido um limite máximo
de 3 flits de payload. Quando esse número é atingido, o sinal IRQ (L_1_1_out_irq_wire_sew) é
ativado (a), sinalizando o ataque. Nesse momento o envio do pacote é interrompido e um flit
terminador é gerado (b). No entanto, o wrapper continua consumindo flits recebidos do núcleo,
descartando-os até receber o terminador original do pacote (c). O descarte dos flits é caracterizado
pela não ativação do sinal VAL (L_1_1_in_val_wire_sew) (d), o qual serve para sinalizar o
encaminhamento dos flits.
Figura 54. Envio de um ataque com número de flits maior do que o permitido – SystemC
Para ilustrar a proteção da rede aos ataques que visam consumir a largura de banda da rede,
a Figura 55 apresenta o diagrama de forma com a alocação da largura de banda de 50%. Os pacotes
são enviados sem intervalo pelo núcleo (a), mas o wrapper atrasa a injeção do próximo pacote a
rede (b), regulando a alocação de largura de banda conforme o percentual pré-definido pelo
projetista (c).
104
Figura 55. Envio de vários pacotes sem intervalo com largura de banda alocada de 50% – SystemC
5.3 ANÁLISE DA TAXA DE COBERTURA
A taxa de cobertura dos wrappers aos ataques considerados foi de 100%, pois bloquearam
todos os ataques para os quais foram projetados. O Quadro 13 resume os ataques modelados e a
eficácia dos wrappers contra o ataque enviados a NoC.
Quadro 13. Ataques modelados para o experimento
Ataque
Implementação
Envio de pacote a um endereço de destino na posição X
Envio de pacotes para maior que ao tamanho da rede
Envio de pacote a um endereço de destino na posição Y
um endereço de
maior que ao tamanho da rede
destino inexistente
Envio de pacote ao próprio endereço do núcleo
Envio de pacote com a posição de origem X diferente do
endereço do núcleo
Mascaramento de
endereço de origem
Envio de pacote com a posição de origem Y diferente do
endereço do núcleo
Repetição do envio
Envio de um pacote com número de flits maior do que o
de pacote para um
permitido
determinado
Envio de vários pacotes em sequencia, sem intervalo
endereço
Bloqueou?
Sim
Sim
Sim
Sim
Sim
Sim
Sim
105
6 CONCLUSÕES
A manipulação de dados críticos dentro da NoC faz com que seja de grande importância a
implementação de requisitos de segurança. Esses requisitos podem ser caracterizados pela
arquitetura de segurança OSI, que engloba ataques, mecanismos e as propriedades de segurança. O
emprego de mecanismos de segurança garante que as propriedades de segurança não sejam afetadas
pelos ataques.
O objetivo desse trabalho foi o de buscar soluções de segurança para prover maior
disponibilidade à rede SoCIN. A metodologia foi realizada em três fases. Na primeira fase, foi
executado um procedimento técnico de pesquisa bibliográfica para realizar a fundamentação
teórica, que abordou a área de NoCs e de segurança de sistemas. Ainda nessa fase, foi realizada a
revisão sistemática, selecionando-se e analisando-se trabalhos correlatos e o estado da arte. Na
segunda fase, foram identificadas as vulnerabilidades da rede SoCIN e modeladas soluções para
garantir a propriedade de disponibilidade na rede SoCIN contra alguns ataques de negação de
serviço. Na terceira fase, as soluções propostas foram implementadas, em VHDL e em SystemC, a
fim de avaliar a viabilidade de implementação e caracterizar seus custos e o impacto no
desempenho da rede.
Com a identificação das principais vulnerabilidades de segurança na rede SoCIN quanto à
propriedade de disponibilidade, pela implementação de mecanismos de segurança e pela análise dos
impactos dessa implementação, pode-se afirmar que os objetivos específicos desse trabalho foram
atingidos. Os resultados obtidos mostram que é possível aumentar a propriedade de disponibilidade
da rede SoCIN com a implementação em hardware de mecanismos para o provimento de segurança,
atendendo o objetivo geral deste trabalho. Isso responde à primeira pergunta de pesquisa deste
trabalho.
Os resultados demostraram também que os wrappers desenvolvidos introduzem uma
latência de 1 ciclo de relógio na transferência de um pacote, degradando minimamente o
desempenho da rede, sem porém limitar a frequência máxima de operação, dado que os demais
componentes da rede operam a frequências menores. Isso responde à segunda pergunta de pesquisa
desta dissertação.
106
Além disso, os resultados mostraram que os wrappers adicionam um pequeno sobrecusto de
área de silício, quando comparadas às áreas do roteador ParIS e da interface de rede XIRU,
respondendo à terceira pergunta de pesquisa.
Por fim, os resultados obtidos permitiram confirmar as hipóteses de pesquisa, dado que
aumentou-se a disponibilidade da rede SoCIN, com uma mínima redução do seu desempenho e um
pequeno sobrecusto de silício.
6.1 CONTRIBUIÇÃO DA DISSERTAÇÃO
A principal contribuição desta dissertação reside na análise das vulnerabilidades da rede
SoCIN e a proposta e implementação de soluções que a protegem a rede contra ataques à sua
propriedade de disponibilidade. Ressalta-se que os wrappers foram implementados de forma a
permitir que os mesmos sejam facilmente integrados à interface de rede XIRU ou à porta local do
roteador ParIS.
Os ataques de DoS no âmbito específico de NoCs foram abordados por alguns autores. Este
trabalho tem como diferencial a proteção da propriedade de segurança de disponibilidade da rede
(roteadores, buffers, enlaces, etc), evitando que os pacotes maliciosos sejam injetados na rede e
assim não consumindo os recursos da rede. Também foi implementado um controle de largura de
banda que evita que um núcleo injete pacotes na rede com uma taxa maior do que a que foi
dimensionada pelo projetista do sistema, e novamente, não onerando os recursos da rede.
6.2 TRABALHOS FUTUROS
Como trabalhos futuros, propõem-se:

Integrar os mecanismos propostos (wrappers) na interface de rede XIRU ou na porta
local do roteador ParIS;

Implementar um mecanismo pós-ataque para colocar em quarentena o núcleo malicioso;

Implementar um mecanismo de segurança dinâmica que ao invés de utilizar um
parâmetro estático de controle de banda definido em tempo de projeto, avalie se a
quantidade de pacotes enviadas oferece riscos à rede SoCIN e regule a largura de banda
alocada dinamicamente, alterando as taxas de inserção de ciclos de espera; e
107

Análise e implementação de soluções para assegurar outras propriedades de segurança
na rede SoCIN.
108
REFERÊNCIAS
ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR ISO/IEC 27001:2006: Sistema
de Gestão de Segurança da Informação. Rio de Janeiro, 2006.
ABRAMOVICI, Miron; BRADLEY, Paul. Integrated circuit security new threats and solutions. In:
ANNUAL WORKSHOP ON CYBER SECURITY AND INFORMATION INTELLIGENCE
RESEARCH (CSIIRW), 5., 2009, Knoxville. Proceedings… New York: ACM, 2009.
ADRIAHANTENAINA, Adrijean; CHARLERY, Herve; GREINER, Alain.; MORTIEZ, Laurent;
ZEFERINO, Cesar A. SPIN: A Scalable, Packet Switched, On-Chip Micro-Network. In: DESIGN
AUTOMATION AND TEST ON EUROPE (DATE) – DESIGNER´S FORUM, 2003, Messe
Munich. Proceedings… Piscataway : IEEE Computer Society, 2003. p. 70-74.
ANOOP MS. Security needs in embedded systems. Tata Elxsi, 2008. Disponível em:
<http://www.infosecwriters.com/text_resources/pdf/Anoopms_Embedded_Systems.pdf>. Acesso
em: 10 jul. 2011.
ASHKENAZI, Asaf; AKSELROD, Dimitry. Platform independent overall security architecture in
multi-processor system-on-chip integrated circuits for use in mobile phones and handheld devices.
Computers and Electrical Engineering, Tarrytown, v.33, n. 5-6, p. 407-409, set. 2007.
BARROS, Aldil J.; LEHFELD, Neide. Fundamentos de metodologia científica: Um Guia para
Iniciação Científica. São Paulo: Makron Books, 2000.
BARBETTA, Pedro A.; REIS, Marcelo M. e BORNIA, Antonio C. Estatística para cursos de
Engenharia e Informática. 3. ed. São Paulo: Editora Atlas, 2010.
BENINI, Luca; DE MICHELI, Giovanni. Networks on Chips: a new SOC paradigm. IEEE
Computer, v. 35, n. 1, p. 70-78, jan. 2002.
BENINI, Luca; DE MICHELI, Giovanni. Networks on chip: Technology and tools. New York:
Elsevier North-Holland, 2006.
BERTOZZI, Davide.; BENINI, Luca. xPipes: A network-on-chip architecture for gigascale
systems-on-chip. IEEE Circuits and Systems Magazine, v. 4, n. 2, p. 18-31, set. 2004.
BOLOTIN, Evgeny; CIDON, Israel; GINOSAR, Ran; KOLODNY, Avinoam. QNoC: QoS
architecture and design process for network on chip. Journal of Systems Architecture, v. 50, v. 23, p. 105-128, fev. 2004.
BRANDÃO, José. E. M. S.; FRAGA, Joni. S. Gestão de Riscos. In: SIMPÓSIO BRASILEIRO EM
SEGURANÇA DA INFORMAÇÃO E DE SISTEMAS COMPUTACIONAIS (SBSeg), 8., 2008,
Gramado. Proceedings… [S.l.: s.n], 2008.
BRUSH, Jaison V.; PIZZONI, Magnos R.; ZEFERINO, Cesar A. BrownPepper: a SystemC-based
simulator for performance evaluation of Network-on-Chip. In: INTERNATIONAL CONFERENCE
109
ON VERY LARGE SCALE INTEGRATION (VLSI-SOC), 17., 2009, Florianópolis.
Proceedings… Piscataway: IEEE Computer Society, 2009, p. 223-226.
NATIONAL INFORMATION ASSURANCE GLOSSARY. CNSSI-4009: Committee on National
Security Systems. [S.l], 2006.
DALLY, William J.; TOWLES, Brian. Principles and practices of interconnection networks.
San Francisco: Morgan Kaufmann, 2004.
DIGUET, Jean-Philippe; EVAIN, Samuel; VASLIN, Romain; GOGNIAT, Guy; JUIN, Emmanuel.
NoC-centric security of reconfigurable SoC. In: INTERNATIONAL SYMPOSIUM ON
NETWORKS-ON-CHIP (NOCS), 1., 2007, Princeton. Proceedings… Washington: IEE Computer
Society, 2007. p. 223-232.
DUATO, Jose; YALAMANCHILI, Sudhakar; NI, Lionel M.. Interconnection networks: an
engineering approach. Los Alamitos: IEEE Computer Society Press, 1997.
EVAIN, Samuel; DIGUET, Jean-Philippe; HOUZET, Dominique. μSpider: a CAD tool for efficient
NoC design. In: IEEE NORCHIP, 2004, Oslo. Proceedings... New York: IEEE, 2004. p. 218-221.
FIORIN, Leandro; PALERMO, Gianluca; SILVANO, Cristina. A security monitoring service for
NoCs. Architecture. In: IEEE/ACM/IFIP INTERNATIONAL CONFERENCE ON
HARDWARE/SOFTWARE CODESIGN AND SYSTEM SYNTHESIS (CODES+ISSS), 6., 2008,
Atlanta. Proceedings… New York: ACM, 2008. p. 197-202.
FIORIN, Leandro; PALERMO, Gianluca; SILVANO, Cristina. MPSoCs Run-Time Monitoring
through Networks-on-Chip. In: DESIGN, AUTOMATION AND TEST IN EUROPE (DATE), 57.,
2009, Nice. Proceedings… Leuven: European Design and Automation Association, 2009. p. 558561.
FIORIN , Leandro; PALERMO, Gianluca; LUKOVIC, Slobodan; CATALANO, Valerio;
SILVANO, Cristina. Secure memory accesses on Networks-on-Chip. IEEE Transactions on
Computers, Washington, v. 57, n.9, p. 1216-1229, 2008.
FIORIN, Leandro; SILVANO, Cristina; SAMI, Mariagiovanna. Security aspects in Networks-onChips overview and proposals for secure implementations. In: EUROMICRO CONFERENCE ON
DIGITAL SYSTEM DESIGN ARCHITECTURES, METHODS AND TOOLS (DSD), 10., 2007,
Lubeck. Proceedings… Washington: IEEE Computer Society, 2007.
GEBOTYS, Catherine H.; GEBOTYS, Robert J.. A Framework for Security on NoC Technologies.
In: IEEE COMPUTER SOCIETY ANNUAL SYMPOSIUM ON VLSI (ISVLSI), 2003, [S.l.].
Proceedings… Washington: IEEE Computer Society, 2003, p. 113-117.
GIL, Antônio C. Como elaborar projetos de pesquisa. 4. ed. São Paulo: Atlas, 2002.
GOOSSENS, Kees; DIELISSEN, John; RADULESCU Andrei. A Æthereal network on chip:
concepts, architectures, and implementations. IEEE Design & Test of Computers, Los Alamitos,
v.22, n. 5, p. 414-421, 2005.
110
GUERRIER, Pierre; GREINER, Alain. A generic architecture for on-chip packet-switched
interconnections. In: DESIGN, AUTOMATION AND TEST IN EUROPE CONFERENCE AND
EXIBITION (DATE), 2000, Paris. Proceedings... Los Alamitos: IEEE Computer Society Press,
2000. p. 250-256.
GUERRIER, Pierre; GREINER, Alain. A scalable architecure for system-on-chip interconnections.
In: SOPHIA-ANTIPOLIS MICRO-ELECTRONICS CONFERENCE (SAME), 1999, France.
Proceedings… Sophia Antipolis: [s.n.], 1999. p. 90-93.
HEMANI, Ahmed et al. Networks on Chip: an architecture for billion transistor era. In: NORCHIP,
2000, Turku. Proceedings... [S.l.: s.n], 2000. p.166-173.
HOSKOTE, Yatin; VANGAL, Sriram; SINGH, Arvidn; BORKAR, Nitin; BORKAR, Shekhar. A
5-GHz Mesh Interconnect for a Teraflops Processor. IEEE Micro, Los Alamitos, v. 27, n. 5, p. 5161, 2007.
HUFFMIRE, Ted; LEVIN, Timothy; NGUYEN, Thuy; IRVINE, Cynthia. Security Primitives for
reconfigurable hardware-based Systems. Acm Transactions on Reconfigurable Technology and
Systems, New York, v.3, n.2, mai. 2010.
JERGER, Natalie Enright; PEH, Li-Shiuan. On-Chip Networks: Synthesis Lectures on Computer
Architecture. [S.l.]: Morgan & Claypool, 2009.
KITCHENHAN, Bárbara, et.al. Systematic literature reviews in software engineering – A
systematic literature review. Information and Software Technology, New York , v.51 , n.1 , p. 715, jan. 2009.
LAKATOS, Eva M.; MARCONI, Mariana A. Fundamentos de metodologia científica. 3. ed. São
Paulo: Atlas, 2000.
LANDWEHR, Carl E. Computer security. International Journal of Information Security (IJIS),
New York, p. 3-13, jul. 2001.
LÁZARO, Jesús; ASTARLOA, Armando; ZULOAGA, Aitzol; BIDARTE, Unai; JIMÉNEZ,
Jaime. I2CSec: A secure serial Chip-to-Chip communication protocol. Journal of Systems
Architecture, New York, v. 57, n. 2, p. 206-213, fev. 2011.
LUKOVIC, Slobodan; CHRISTIANOS, Nikolaos. Hierarchical multi-agent protection system for
NoC based MPSoCs. In: INTERNATIONAL WORKSHOP ON SECURITY AND
DEPENDABILITY FOR RESOURCE CONSTRAINED EMBEDDED SYSTEMS (S&D4RCES),
10., 2010, Naples. Proceedings… New York: ACM, 2010.
MARTIN, Grant E.; CHANG, Henry. Winning the SoC revolution: experiences in real design.
New York: Springer, 2003, p. 320.
MELO, Douglas. R.. Interfaces de comunicação extensível para a Rede-em-Chip SoCIN. 2012.
Dissertação (Mestrado em Ciência da Computação) – Programa de Pós-Graduação em Computação,
Universidade do Vale do Itajaí, Itajaí, 2012.
111
PATEL, Krutartha; PARAMESWARAN, Sri; RAGEL, Roshan G.. CUFFS: An instruction count
based architectural framework for security of MPSoCs. In: DESIGN, AUTOMATION AND TEST
IN EUROPE (DATE), 2009, Nice. Proceedings… Leuven: European Design and Automation
Association, 2009. p. 779-784.
PATEL, Krutartha; PARAMESWARAN, Sri; SHEE, Seng Lin. Ensuring secure program execution
in multiprocessor embedded systems: a case study. In: INTERNATIONAL CONFERENCE ON
HARDWARE/SOFTWARE CODESIGN AND SYSTEM SYNTHESIS (CODES+ISSS), 5., 2008,
Salzburg. Proceedings… New York: ACM, 2007, p.57-62.
PATEL, Krutartha; PARAMESWARAN, Sri. LOCS: a low overhead profiler-driven design flow
for security of MPSoCs. In: INTERNATIONAL CONFERENCE ON HARDWARE/SOFTWARE
CODESIGN AND SYSTEM SYNTHESIS (CODES+ISSS), 6., 2008, Salzburg. Proceedings…
New York: ACM, 2008a, p.79-84.
PATEL, Krutartha; PARAMESWARAN, Sri. SHIELD: a software hardware design methodology
for security and reliability of MPSoCs. In: DESIGN AUTOMATION CONFERENCE (DAC), 45.,
2008, Anaheim. Proceedings… New York: ACM, 2008b.
PORQUET, Joel; SCHWARZT, Christian; GREINER, Alain. NoC-MPU: a secure architecture for
flexible co-hosting on shared memory MPSoCs. In: DESIGN, AUTOMATION & TEST IN
EUROPE CONFERENCE & EXHIBITION (DATE), 2011, Grenoble. Proceedings… [S.l.: s.n.],
2011. p. 1-4.
PORQUET, Joel; SCHWARZT, Christian; GREINER, Alain. Multi-compartment a new
architecture for secure co-hosting on SoC. In: INTERNATIONAL SYMPOSIUM ON SYSTEMON-CHIP, 11., 2009, Tampere. Proceedings… Piscataway: IEEE Computer Society, 2009. p. 124127.
SEPÚLVEDA, M. Johanna; STRUM, Marius; CHAU, Wang Jiang. An hybrid switching approach
for NoC-based systems to avoid Denial-of-Service SoC attacks. In: IBERCHIP WORKSHOP, 16.,
2010, Iguazu Falls. Proceedings… , Iguazu Falls: IBERCHIP Workshop, 2010.
SEPÚLVEDA, M. Johanna; STRUM, Marius; CHAU, Wang Jiang. Performance impact of QoSS
(Quality-of-Security-Service) inclusion for NoC-based systems. In: INTERNATIONAL
CONFERENCE ON VERY LARGE SCALE INTEGRATION (VLSI-SOC), 17., 2009,
Florianópolis. Proceedings… Piscataway: IEEE Computer Society, 2009.
STALLINGS, William. Criptografia e segurança de redes: princípios e práticas, 4. ed. New
Jersey: Prentice Hall, 2008.
STEFAN, Radu; GOOSSENS, Kees. NoC security using multipath routing. In: WORKSHOP ON
CIRCUITS, SYSTEMS AND SIGNAL PROCESSING (ProRISC), 20., 2009, Veldhoven.
Proceedings… [S.l.: s.n], 2009. p. 522-525.
SILVA, Edna L.; MENEZES, Estera M.. Metodologia da Pesquisa e Elaboração de Dissertação.
3. ed. Florianópolis:[s.n], 2001.
112
SUSIN, Altamiro A.; ZEFERINO, Cesar A.. SoCIN: A Parametric and Scalable Network-on-Chip.
In: SYMPOSIUM ON INTEGRATED CIRCUITS AND SYSTEMS DESIGN, 2003, São Paulo.
Proceedings… Piscataway: IEEE Computer Society, 2003, p. 169-174.
TAMIR, Yuval; FRAZIER, Gregory L. Dynamically-allocated multi-queue buffers for VLSI
communication switches. In: IEEE Transactions on Computers, 41., 1992, New York.
Washington: IEEE Computer Society, 1992. p. 725-737.
TEXIER, Matthieu. Network-on-Chip security: overview of existing solutions. Architecture.
2009. Disponível em: <http://www.mtexier.com/noc-security>. Acesso em: 12 jul. 2011.
ZEFERINO, Cesar. A. Redes-em-Chip: arquiteturas e modelos para avaliação de área e
desempenho. 2003. Tese (Doutorado) – Programa de Pós-Graduação em Computação, Universidade
Federal do Rio Grande do Sul, Porto Alegre, 2003.
ZEFERINO, Cesar A.; SUSIN, Altamiro A.. SoCIN: a parametric and scalable Network-on-Chip.
In: SYMPOSIUM ON INTEGRATED CIRCUITS AND SYSTEMS, 16., 2003, São Paulo.
Proceedings... Los Alamitos: IEEE Computer Society Press, 2003. p. 169-174.
ZEFERINO, Cesar A.; KREUTZ, Márcio E. e SUSIN, Altamiro A. RASoC: A Router Soft-Core for
Networks-on-Chip. In: DESIGN AUTOMATION AND TEST IN EUROPE CONFERENCE AND
EXHIBITION, 3., 2004. Paris. Proceedings… Paris: IEEE Computer Society, 2004, p. 198-203.
ZEFERINO, CESAR A.; SANTO, FREDERICO G. M. E. e SUSIN, ALTAMIRO A. ParIS: A
Parameterizable Interconnect Switch for Network-on-Chip. In: SYMPOSIUM ON INTEGRATED
CIRCUITS AND SYSTEM DESIGN, 2004, Pernambuco. Proceedings… New York:ACM, 2004,
p. 204-209.
113
APÊNDICE A – REVISÃO SISTEMÁTICA
Uma revisão sistemática de literatura é um meio para identificar, interpretar e avaliar todos
os resultados relevantes de uma pesquisa acerca de uma questão, área ou fenômeno em particular.
Utilizando uma metodologia rigorosa e que possa ser reproduzida posteriormente. A revisão
sistemática tem por objetivo apresentar uma avaliação concisa a respeito de um tópico
(KITCHENHAN, 2009).
A primeira atividade desta revisão sistemática foi a definição de um protocolo, que visa
levantar a literatura relevante acerca do tema sobre segurança em NoCs. O escopo da pesquisa é
voltado para a identificação de técnicas utilizadas para prover segurança em uma NoC, porém como
o tema é ainda recente (FIORIN; PALERMO; SILVANO, 2008), foi incluído no trabalho de revisão
sistemática técnicas de segurança relacionada a SoC (System-on-Chip) e a MPSoC (Multiprocessor
System-on-Chip).
QUESTÃO DA PESQUISA

Questão: Quais principais ataques e vulnerabilidades nas NoC?

Questão de pesquisa adicional: Quais os requisitos (propriedades) de segurança
para uma NoC?

Questão de pesquisa adicional: Quais técnicas são adotadas para prover segurança
em uma NoC?

População: Ataques; Vulnerabilidades ; propriedades de segurança; técnicas de
segurança

Intervenção:
o
Para a questão principal: Ataques e vulnerabilidades das NoCs
o
Para a questão secundária: Propriedades de segurança das NoCs.

Resultados: Ataques; Vulnerabilidades ; propriedades de segurança; técnicas de
segurança adotadas em NoCs

Contexto: Segurança em NoC ou SoC
114
ESTRATÉGIA UTILIZADA PARA PESQUISA DOS ESTUDOS PRIMÁRIOS
O escopo da pesquisa se dá em bases de dados eletrônicas, incluindo journals e anais de
conferências.

Termos de busca:
o Em português: “segurança” AND (“redes-em-chip” OR “NoC” OR “rede intrachip”
OR “SoC” OR “MPSoC” OR “System-on-Chip”).
o Em Inglês: “security” AND ( “network-on-chip” OR “NoC” “OCN” OR “SoC” OR
“MPSoC” OR “System-on-Chip”)

Fontes:
o Google acadêmico: http://scholar.google.com.br
o IEEExplore: http://ieeexplore.ieee.org
o CAPES: www.periodicos.capes.gov.br
o ACM Digital Library: http://portal.acm.org
CRITÉRIOS E PROCEDIMENTOS PARA A SELEÇÃO DE ESTUDOS
Os trabalhos foram filtrados a partir dos seguintes critérios:

Pela análise do título do trabalho;

Pela análise do resumo e das conclusões do trabalho;

Pela data de publicação do trabalho;

Critérios para inclusão de estudo:
o Para a questão primária: Foram incluídos no estudo trabalhos cujos títulos e
resumos contenham informações referente à segurança em NoC ou SoC . A
conclusão foi analisada para verificar a contribuição do trabalho. A data de
publicação do trabalho deve ser superior ou igual ao ano 2000.
o Para a questão secundária: Os mesmos critérios da questão primária, porém
o título e resumo deviam conter também a informação sobre ataques,
vulnerabilidades ou técnicas de segurança.

Critérios para exclusão de estudo:
o Para a questão primária: Foram excluídos do estudo trabalhos cujos títulos e
resumos sejam conflitantes, ou seja, o título remete a um assunto enquanto o
115
resumo remete a outro assunto. Os trabalhos publicados antes do ano 2000
não foram analisados.
o Para a questão secundária: Os mesmos critérios da questão primária além de
que o título e resumo que não estavam informando sobre segurança em NoC
ou SoC.

Processo de seleção preliminar:
o As estratégias de pesquisa foram aplicadas para identificar os estudos
primários potenciais. O trabalho selecionado que não atendeu aos critérios
de inclusão e também não atendeu aos critérios de exclusão, o mesmo foi
incluído.

Processo de seleção final:
o Cópias dos trabalhos incluídos como resultados da pesquisa inicial foram
revisados. Esta revisão concluiu a seleção de trabalhos incluídos no
processo de extração de dados.
LISTA DE VERIFICAÇÃO E PROCEDIMENTOS PARA AVALIAÇÃO DA
QUALIDADE DOS ESTUDOS
Os estudos foram avaliados em sua qualidade abordando os seguintes aspectos:

Objetivos: Os objetivos do trabalho devem ser no sentido de estabelecer ou aplicar
uma técnica para evitar ataques em NoC ou SoC. Os mesmos devem estar bem definidos e
delimitados, sem a pretensão de resolver problemas de grande abrangência.

Condução: O projeto deve estar bem referenciado e possuir, preferencialmente uma
etapa experimental, com a validação das hipóteses. Eventos negativos ocorridos durante o estudo,
como por exemplo, dificuldades quanto a população e os equipamentos, tornarão o trabalho elegível
a ter uma atribuição de menor qualidade.

Experimentos: A população deve ser escolhida de forma aleatória evitando vieses na
amostra e com o tamanho considerável (acima de 30) de indivíduos.
116
ESTRATÉGIA PARA EXTRAÇÃO DOS DADOS
Para cada artigo aprovado pelo processo de seleção completo, tanto para a questão primária
quanto para a questão secundária, foram extraídos os seguintes dados:

Informação para referência bibliográfica;

Tipo de artigo: teórico, experimental ou ambos;

Problema alvo;

Propriedades de segurança atacada;

NoC utilizada (caso existir);

Componentes do circuito atacado;

Solução proposta;

Metodologia ou materiais utilizados;

Resultados obtidos;

Métricas de avaliação;

Problemas em aberto;
SÍNTESE DOS DADOS EXTRAÍDOS
Os resultados foram organizados em tabelas. A partir da tabulação dos dados, foram
extraídos os dados que possui a maior quantidade de incidentes, identificando qual é o item mais
tratado pelos trabalhos relacionados.