Mac security Handling in OpenThread

[joseph-jayanth]

Hi Members

In RCP model of open thread implementation where does the mac security can be handled?
Should it be done in the Open thread controller or in the open-thread core(host processor) in the host?
If it can be done in the controller should it be done in HW crypto engine or in between the spinel and OT drivers?
Also please advise on the config aspects related to the mac security handling for Open thread!

Thanks in advance.

Regards
Joseph

[abtink]

In RCP model of open thread implementation where does the mac security can be handled?
Should it be done in the Open thread controller or in the open-thread core(host processor) in the host?

The RCP model requires the RCP to provide and handle TX frame security processing (for Thread 1.2 or later versions). RX frame security processing is done on the host in the Mac layer.

Regarding the firmware running on the RCP itself, TX security processing can be handled by either OpenThread's Mac/SubMac implementation or delegated to the radio platform. The radio platform indicates its capabilities (see OT_RADIO_CAPS), and the OT stack will delegate supported functionality to the platform or use its own implementation otherwise. The choice is up to the radio platform, but typically they provide OT_RADIO_CAPS_TRANSMIT_SEC.

openthread/include/openthread/platform/radio.h

Lines 124 to 141 in 19dadd9

	/**
	* Defines constants that are used to indicate different radio capabilities. See `otRadioCaps`.
	*
	*/
	enum
	{
	OT_RADIO_CAPS_NONE = 0, ///< Radio supports no capability.
	OT_RADIO_CAPS_ACK_TIMEOUT = 1 << 0, ///< Radio supports AckTime event.
	OT_RADIO_CAPS_ENERGY_SCAN = 1 << 1, ///< Radio supports Energy Scans.
	OT_RADIO_CAPS_TRANSMIT_RETRIES = 1 << 2, ///< Radio supports tx retry logic with collision avoidance (CSMA).
	OT_RADIO_CAPS_CSMA_BACKOFF = 1 << 3, ///< Radio supports CSMA backoff for frame transmission (but no retry).
	OT_RADIO_CAPS_SLEEP_TO_TX = 1 << 4, ///< Radio supports direct transition from sleep to TX with CSMA.
	OT_RADIO_CAPS_TRANSMIT_SEC = 1 << 5, ///< Radio supports tx security.
	OT_RADIO_CAPS_TRANSMIT_TIMING = 1 << 6, ///< Radio supports tx at specific time.
	OT_RADIO_CAPS_RECEIVE_TIMING = 1 << 7, ///< Radio supports rx at specific time.
	OT_RADIO_CAPS_RX_ON_WHEN_IDLE = 1 << 8, ///< Radio supports RxOnWhenIdle handling.
	OT_RADIO_CAPS_TRANSMIT_FRAME_POWER = 1 << 9, ///< Radio supports setting per-frame transmit power.
	};

---

If it can be done in the controller should it be done in HW crypto engine or in between the spinel and OT drivers?

This decision is entirely up to the platform.

• If TX frame security processing is implemented in the radio platform, the platform developer decides how to handle it.
• When security processing is performed by the OpenThread stack, OT defines a set of platform APIs otPlatCrypto, allowing the platform to specify its crypto implementation. A default implementation using mbedtls is provided by the OT stack in crypto_platform.cpp, but the platform can choose to provide its own implementation (which may use HW crypto engines).

[jchellap]

Thanks @abtink
What about Secured RX frame processing in RCP model? Can it be passed onto OT submac for decryption rather than platform level processing? What is the suggestions/recommendation? Should open thread controller handle it or handled by open thread core?

[abtink]

RX security processing is exclusively handled by the OT core (within the Mac class). The radio platform and/or RCP are not involved in this process.

[jchellap]

Thanks, that clarifies.

[joseph-jayanth]

Thanks @abtink for the clarification!