IOTA Crypto Core FPGA — Security

The full article was originally published by MicroEngineer on Medium. Read the full article here.

In case you missed the last article, click here

This article is also about the small red FPGA module. Sorry for using the image again and again 🙂

Security is not an easy topic, because the securing has to be done on the lowest hardware-level but I try to explain it as good as I can.

One of the main aspects of the ICCFPGA (short for IOTA Crypto Core FPGA) project was security.

Unlike a server that is secured by physical measurements —for example, in a data-center — the FPGA module could potentially be used outside in the field and be exposed to physical attacks.

Imagine the FPGA module used as payment processor in a vending-machine selling snacks or coffee — it would be disastrous if someone could break or steal the vending machine and gain access of the seeds.

Of course, if the FPGA module is used as a co-processor, the main-processor has to be as secure as the FPGA module, but the strength of this module is that it can be used as the main application processor since you can write your own code running on the module secured.

There are several security aspects I would like to explain.

Soft-CPU and Memory Protection Unit

The following picture shows what is on the FPGA-module — especially inside the FPGA.

In the middle of the picture is the RISC-V (Soft-)CPU which is connected to memories, peripherals (like I2C, SPI, …) and the debugger.

The CPU executes code located in the ROM and uses the RAM as memory-space for data. ROM stands for read-only-memory but in practice FPGAs don’t have ROM, they have to emulate ROM with RAM by limiting access to the memory.

By default, the RISC-V implementation I used, doesn’t really distinguish between ROM and RAM*, so it would have been possible to inject code from extern (e.g. via JSON-Api) by exploiting programming mistakes and provoking Buffer Overflows.

Fortunately, the VexRiscV could easily be extended with a memory protection plugin written in Scala which introduces access management to the memories and I/O-space.

In short, it blocks write access to ROM and blocks code execution from RAM.

Additionally, the RISC-V (it’s part of the ISA) supports different privilege levels. There is Machine mode (highest privilege level), Supervisor mode and User mode. The memory protection plugin also differentiates between these three modes and makes memory and peripherals which are only accessible from Machine- and Supervisor-mode possible.

Read the full Article

The full article was originally published by MicroEngineer on Medium, where people are continuing the conversation by highlighting and responding to this story.

You might also like

This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish. AcceptRead More