Closed AntonHermann closed 1 year ago
Hi Anton:
Shared memory regions are required in some applications and therefore fully supported by MultiZone policies. Integrity and availability are preserved via non-execute read-only access.
Your attestation zone should have one additional non-execute read only policy for each code segment to measure.
The MultiZone Trusted Firmware implements a similar approach for remote OTA firmware deployment via secure split buffers. Note that in this case code attestation is implicit as the communication is mutually authenticated via TLS. See https://github.com/hex-five/multizone-iot-sdk/blob/master/bsp/X300/multizone.cfg
Good luck with your thesis!
Cesare
Hi Cesare,
that makes sense, thanks for clarifying :)
Your attestation zone should have one additional non-execute read only policy for each code segment to measure.
That's what I did, nice :)
All the best, Anton
Hey :)
for my bachelors thesis, I am designing a Remote Attestation procedure on top of MultiZone. My design uses a dedicated attestation zone to read and hash the memory of application zones.
Clearly, this use-case doesn't work with the MultiZone secure communication interface and in the paper (Secure IoT Firmware For RISC-V Processors, 2021) you state that no shared memory is used for communication. As I understand it, this primarily regards the communication interface provided by MultiZone, but is it actually discouraged to use shared memory?
The reference application uses it for GPIO and the MultiZone Configurator emits a warning, but I wasn't sure if this approach is future-proof or whether mapping a memory region to multiple zones may be prohibited eventually.
Thanks in advance, Anton