Open AccessDetection and Countermeasures of Security Attacks and Faults on NoC-Based Many-Cores
Author(s) -
Rafael Follmann Faccenda,
Luciano L. Caimi,
Fernando Gehm Moraes
Publication year - 2021
Publication title -
ieee access
Language(s) - English
Resource type - Journals
SCImago Journal Rank - 0.587
H-Index - 127
ISSN - 2169-3536
DOI - 10.1109/access.2021.3127468
Subject(s) - aerospace , bioengineering , communication, networking and broadcast technologies , components, circuits, devices and systems , computing and processing , engineered materials, dielectrics and plasmas , engineering profession , fields, waves and electromagnetics , general topics for engineers , geoscience , nuclear engineering , photonics and electrooptics , power, energy and industry applications , robotics and control systems , signal processing and analysis , transportation
The modularization and manufacture of many-cores system-on-chip that involve several vendors open up a vulnerability: the inclusion of Hardware Trojans (HT). In addition to that, the reduced feature size of transistors may accelerate aging effects, leading to faults. The literature presents techniques to tackle security and fault-tolerance, such as cryptography, authentication codes, error correction codes, creation at runtime of flow profiles to detect anomalous behavior. However, at the communication level (i.e., NoC), there is a gap in generic methods to detect attacks or faults. As detailed in the state-of-the-art session, approaches targeting the NoC protection against attacks add additional hardware in the NoC itself, which is prone to security attacks or faults. This work decouples the detection of attacks or faults by using data and control NoCs. The adoption of a control NoC enables the proposal of the Communication Session Protocol to monitor message exchange, detect abnormal behavior, and recover the communication from an eventual failure or attack. The execution time overhead varies according to the application communication model, from 3.5% to 33%. Such overhead is acceptable because once detected an abnormal communication behavior, the protocol changes the path between communicating task pairs and resumes the application execution.