RFC: Virtual Secure Element Device (VSED)

[nandojve]

Introduction

Security is located on several places inside a product. It can be handled in general with some secure API that allows access to operations. The usual way is define a library and use that API. The problem start when security is already in place and, for instance, it is necessary switch the library itself. An API to close to the library create a dependency that difficult introduce new libraries as alternatives.

Problem description

To expose a way to easy switch from a secure element to another and It should be preferable by using Device Tree. Currently there is no way to have a standard to execute a crypto algorithm. Some people can use tinycript and others may enable mbed to execute same method. It can bloated firmware with both libraries and not guarantee that is hardware accelerated.

Proposed change

The Virtual Secure Element Device (VSED) can be an alternative to direct access APIs. The concept is simple, the code that needs that algorithms should get the VSED instance and use their API, instead access directly any secure API like mbed. It detach all secure API aspects like: communication channels, buses, storage; from the system secure part and create a standard way to access that devices and or operations.

Detailed RFC

An simple example can be IEEE 802.15.4 stack. To implement security it is necessary AES-128. The AES-128 can be implemented 100% in software or partial in software and HW accelerated. Any vendor may have your own secure API side already ready on HAL and can benefit that, no need to bind with mbed. There are I2C elements to store and execute crypto routines. The same way, there are SoC that have accelerators to some operations. It is complex to connect all possible scenarios unless a glue like VSED is available.

IEEE 802.15.4 example in more details:

/{
	my_secure_element {
		compatible = "vsed,by_eeprom_and_tinycript";
		store-dev = <&eeprom>;
	};
};

&i2c {
	eeprom {
	};
};

&spi {
	driver {
		vsed = <&my_secure_element>;
	};
};

The "vsed,by_eeprom_and_tinycript" virtual driver expects an EEPROM to store/retrieve crypto keys. The DT define a EEPROM on the I2C bus as storage element. The IEEE 802.15.4 driver requires the VSED element to be present to enable and expose the security part of IEEE 802.15.4. The security can be dropped by simple detaching VSED driver, as an alternative, at runtime. Depending of the project, the same struct will be replicated but the storage can be on a internal EEPROM or on another bus like SPI.

Since this is a Secure Element proposal keep on a external EEPROM sensitive data is not a good example, but the intention is illustrate the idea instead apply security. As alternative, true secure elements can be used like Microchip ATSHA204A, ATECC108A, and ATECC508A, NXP SE050, Infineon SLS32AIA, ST STSAFE-A1SX. This means, the driver for those elements will be created anyway. However, to use it, a virtual device can abstract it and expose it as an VSED API. At end, stack software will access the device instance and check if secure element is available by VSED node.

Dependencies

The VSED concept not obligate refactors. In general, the dependency is related to what VSED should expose instead what damage it can create. That means, will decouple the software that start to use it.

To include Sigfox on Zephyr the Virtual Device (VD) concept will be necessary.

Concerns and Unresolved Questions

There is no clear place to define device tree bindings. A VSED that exposes SHA, RAND, AES probably will reside on the crypto directory. The VSED is a concept, it can motivate other Virtual Devices (VD) drivers to manage different aspects of the whole system and it should be evaluated case base case.

The place on the device tree for the VSED definition is not clear and should be defined. The drivers that need a reference to VSED probably will use a phandle node to reference it.

Pros:

• drivers/stacks/subsystems can define a VD API (standard way to do it)
• It can reduce Kconfig use
• gives freedom about how to store/retrieve sensitive data like pkey
• easy to switch from one compatible VSED to another
• can be used to interface secure software with non secure software
• allows users/vendors have their own VSED element out of tree
• VD can be used to mock any system aspect related to their own use
• VD can be tested by their own API which can simplifies tests
• VD can expose an standard API to userspace and shell

Cons:

• Add one more layer to hide APIs and expose VD

Possible applications but not limited to:

• Sigfox SE implementation
• IEEE 802.15.4
• ZAUTH

CC: @galak @deangereaux @d3zd3z @tbursztyka

[d3zd3z]

We've had a few discussions in the security subcommittee as far as a secure API. Although we haven't reached any conclusions yet, we did kind of determine that it is probably not beneficial to invent a new API for Zephyr. Two possible API candidates would be PKCS#11, or the PSA crypto API.

Aside from the API discussion, I think there could be some value in having a way to use the devicetree to determine what implementation the API is connected to. But that will be harder to solve without deciding on the API.

At least mbed TLS is moving toward using the PSA crypto API.

[0Grit]

I'm a fan of the PSA Crypto API.
The Mbed OS project should provide a decent reference implementation.

[0Grit]

@hannestschofenig

[hannestschofenig]

I obviously have a preference for the PSA Crypto API and I recently uploaded examples here: Mbed-TLS/mbedtls#5064

I was planning to create a mini-tutorial to help developers quickly understand the functionality. Let me know if that would be useful to help get make a decision regarding the API.

FWIW the RIOT OS project has recently implemented the PSA Crypto API into their RTOS as well, see https://www.youtube.com/watch?v=ryylGMNRwnE

[0Grit]

Awesome thanks for the input. @beriberikix @mniestroj

[d3zd3z]

@hannestschofenig any guess as to how difficult it would be to have a wrapper for the PSA crypto API that just calls into Tiny Crypt. It would only need to support the few hash/cipher/modes that this library supports. This would move us a lot closer to getting rid of a lot of ifdefs.

[d3zd3z]

Since Zephyr has largely decided to use the PSA API for crypto, I believe the best place to work on this (and I believe there is some work on this) is within the PSA API, which has pluggable implementations as a goal.

[beriberikix]

Sounds reasonable - where's the best place to track the VSED APIs in the context of PSA? If there isn't one yet, can someone remember to update this issue? 🙏