Yusuf Yamak

A research initiative by Yusuf Yamak

Mithril.

Security, by default.

A proposed RISC-V system-on-chip for resource-constrained Internet of Things devices. Designed around one goal: make protection part of the platform’s normal operation.

Explore the vision Get in touch

RISC-V / HARDWARE SECURITY / IoT

Mithril conceptual processor illustration A processor at the centre of a circuit, with identity, execution, control-flow and software layers around it. This illustration represents the proposed platform.RISC-VIDENTITYSOFTWAREEXECUTIONCONTROL FLOW
Conceptual platformRV32 / IoT

01 / THE VISION

Small devices.
A system-wide approach to security.

IoT devices have tight resource budgets. Mithril will explore how hardware and software can work together to make protection practical, consistent and enabled by default.

Protection as the default

The platform will aim to establish a protection policy during boot and retain it throughout normal execution, with hardware locks preventing runtime software from disabling it.

Designed for constraints

Processing time, memory, energy and hardware area will guide the design. The research will evaluate how much protection can be provided within practical IoT resource budgets.

One coordinated system

Hardware, boot firmware, the compiler and the operating system will be developed together so that protection can remain consistent across application and task transitions.

02 / PROPOSED ARCHITECTURE

From the first instruction
to the application.

The design will centre on a small Ibex-class RV32 processor. Four coordinated layers will connect firmware identity, execution policy, control-flow checks and the software environment.

DESIGN CONCEPT
TRUSTED STARTBootROM + DICEFirmware measurement & identity
EXECUTION POLICYDSEE + memory protectionImage verification & access rules
RISC-V PROCESSORIbex-class RV32
Return checksLanding pads
SOFTWARE ENVIRONMENTCompiler + Zephyr + HALCalls, tasks & interrupts
Conceptual relationships in the proposed platform.
01Firmware-bound identity

BootROM · DICE

Immutable boot code will measure firmware and derive identity material using the Device Identifier Composition Engine (DICE) approach. Firmware measurements will contribute to the derived identity chain.

02Execution and memory policy

DSEE · SHA-256 · execute-only memory

The Dynamic Secure Execution Engine (DSEE) will be designed to pause execution at firmware handoffs, check image digests against a locked whitelist and reject mismatches. Bus-level policies will address access to executable memory.

03Control-flow protection

Pointer authentication · landing pads

Pointer authentication will protect function and trap return state. RISC-V landing-pad checks will constrain eligible indirect branches to marked entry points. The compiler will supply the corresponding instrumentation.

04An integrated software environment

Compiler · Zephyr RTOS · HAL

The software work will include compiler support, Zephyr real-time operating system (RTOS) integration and a hardware abstraction layer (HAL). Task switching and interrupts will be designed to preserve the required protection state.

The research will define each mechanism’s guarantees within an explicit threat model and supported software configuration.

03 / RESEARCH DIRECTIONS

Design the protection.
Investigate the trade-offs.

The evaluation will examine security properties alongside the processing, memory, energy and hardware costs of enabling them.

SYSTEM ASSURANCE

How can the policy stay enforced?

Attack-response experiments and formal modelling will investigate policy locks, firmware transitions and the handling of protected execution state.

RESOURCE COST

What will protection cost?

FPGA experiments will compare matched configurations and examine application performance, code size, boot latency, RTOS behaviour and hardware resources.

PHYSICAL VALIDATION

How much can power traces reveal?

Stochastic Pipeline Flooding (SPF) will be investigated as a way to add dummy cryptographic activity alongside pointer authentication. ChipWhisperer experiments will assess its effect on physical leakage and its energy cost.

04 / DEVELOPMENT PATH

From research questions
to a platform.

The work will progress through architecture definition, coordinated implementation and experimental evaluation.

  1. 01Define

    Architecture & scope

    Specify the threat model, protection policy, hardware interfaces and target resource budgets.

  2. 02Develop

    Hardware & software

    Build the processor extensions, execution engine, boot firmware and supporting software stack.

  3. 03Evaluate

    FPGA & security tests

    Investigate enforcement, formal properties, performance, resource use and physical leakage.

  4. 04Share

    Research & documentation

    Document the architecture, evaluation methods and findings as the research progresses.

LET’S TALK

Interested in secure
embedded systems?

I’m Yusuf Yamak, an embedded systems engineer and doctoral researcher. Mithril will bring together my work on computer architecture, firmware and hardware security.

I welcome conversations with researchers, embedded teams and potential collaborators about the project’s direction and future applications.

Contact Yusuf yusuf@yusufyamak.com
More about my work