NoC, NoC: Your Chip May Be Under Attack

SoCs face a lot of issues related to security and the Network-on-Chip (NoC) is in a good position to facilitate system-wide services. SoCs are now so complex that one of the challenges is to make sure that the chip does what it is meant to do and doesn’t do what it isn’t meant to do. Just as in software, security used to be largely ignored when doing a chip design but with all the latest revelations about the NSA (and others) you can’t just assume your blocks have no security holes and that it impossible to run malicious code on your control processor.

Chips are vulnerable to attack in all sorts of subtle ways as well as the obvious ones of violating security policies such as writing out encryption keys to non-secure areas. Just as a website is vulnerable to DDOS attack (distributed denial of service) IP blocks on a chip are vulnerable to starvation, forced errors and unauthorized access.

Sonics has a broad set of security features in its products SSX and SGN that can be used in conjunction with error management to enable content protection, core hijacking prevention, and denial of service protection and thus ensure that an SoC cannot be compromised.

The protection mechanism allows for access restrictions to user-specified targets using flexible, user-defined protection regions. The initiator access can be additionally qualified with the use of in-band qualifiers. Incoming requests at the target are qualified using the address, the user bits, the initiator id and the type of command to decide whether to grant or refuse the request. Two tests are done: is the incoming request type (read, write, both) permitted by the permissions and are the role bits of the incoming request in the pattern allowed by the user-defined network permission bits.

The access rights are stored in a table of run-time configurable registers—these registers reside in a protected region. The request address and protection group are used to look up read, write, and role permissions from a table of protection regions.

In a little more detail, access control at the target agent is based on the following attributes of each request:

• The address is used to determine the protection region. Because the initiator agent can do address fill-in and/or multi-channel operations, the address received by a target agent may not be the same as the address sent by the initiator.
• Initiator ID is used to determine protection groups.
• Command is used to determine if a read or write is requested (the ReadEx command is evaluated as both a read and a write).
• Separate portions of user defined signals can be used to determine the protection group and the role associated with the request.

Another important aspect of security is to track issues and capture error conditions. Of course there are lots of reasons for errors on an SoC and security is not necessarily the most likely. As Hanson’s razor says, “Never attribute to malice that which can just be explained by stupidity.” Well, OK, chip designers are not stupid but the most likely reason for sending, say, an unsupported command is an error. But it might not be so capturing errors is a very important part of security.

The combination of the protection mechanism along with error management helps address many SoC security vulnerabilities such as information extraction, core hijacking (running malicious code) and DoS attacks.

More information here.