PSA Crypto API adoption in Zephyr #43712
Comments
ceolin
added this to To do
in Security features/improvements/documentation
via automation
|
Given https://www.wolfssl.com/platform-security-architecture-psa-crypto-api-support-wolfssl/, I think we are past the point of really deciding if PSA is the correct API to implement, and just planning on how we are going to get there. |
|
Note: In the context of Bluetooth, there have been attempts to:
|
|
Snapshot of the current features of TinyCrypt that we would required replacements for: |
|
In my opinion moving towards the PSA crypto APIs as a universal solution does make a lot of sense. There are two notes that I would like to mention here.
I still believe that moving to the PSA APIs is the way to go. I am just noting some possible challenges that will need to be handled. |
|
@Vge0rge There is an effort to enable support for crypto accelerators in the PSA APIs, which I think is worth highlighting and solves a real problem: https://github.com/ARMmbed/mbedtls/blob/development/docs/proposed/psa-driver-interface.md EDIT: You link to that proposal in point two, sorry. 🥸 |
|
I'd second that moving towards the PSA Crypto API make a lot of sense to me, even if there are clearly some issues to resolve around their use, and valid considerations of code size with the MbedTLS implementation. But resolving those issues will be less work than designing something else from scratch. |
|
We are very happy with an intention to gravitate to PSA Crypto APIs! The latest (released) version of nRF Connect SDK has an additional file describing Kconfig options for all PSA_WANT_ALG_XXX configurations found in Mbed TLS https://github.com/nrfconnect/sdk-zephyr/blob/main/modules/mbedtls/Kconfig.psa We have plans to upstream this, but we were waiting for the final decision on standardization We have added two new configurations for the (for now) missing feature of configuring CTR_DRBG or HMAC_DRBG PRNG support: We have internal logic in our SDK to handle configuring NSPE and SPE in case TF-M is used to make sure that the configurations correctly transition into the TF-M build and is exposed in the secure services. The logic includes:
Our intention is to support both with and without TF-M and to make sure that there is only "one unit implementing PSA crypto" in the system. With regards to out-of-box experience, it wouldn't take much to get the Zephyr-module of Mbed TLS to make use of our proposed Kconfig logic. It is also possible to consider making µECC into a PSA driver to decrease the flash-size (if need be). HMAC DRBG is not a big item to fix in a downstream adaptation if we make use of our proposed PSA configuration PSA_WANT_ALG_HMAC_DRBG |
Glad to hear it, that is one of my main concerns, we should not make Zephyr dependent of TF-M in order to have cryptography support.
Nice, we have to find a solution for the TinyCrypt EOL, uECC sounds like the direct alternative for it, but we have to have only one API to not have the same problem in future. We need to understand exactly what is the minimum requirements regarding rom/ram usage.
|
|
From a cursory look it seems PSA Crypto API and Zephyr system interface have a common omission: calls that support a controlled de-initialization of the system. This matters when handing off the hardware from the boot image to the application image. And it affects not only the state of crypto hardware, but also the state of persistent storage, external chips, and even native UI. To check my assumptions and foster discussion, here are the needs and requirements I have come up with so far: Stakeholder needs:
System Requirements: Analysis: I expect I am pretty naïve here. What have I missed? |
|
Here are several more generally related to APIs: Stakeholder needs: |
|
Let me try to distill this down a bit, since most of these requirements are a bit higher level than what would be affected by the crypto API. The first point I want to make is that asking this as a question "Should Zephyr Adopt the PSA Crypto API" is kind of a moot point. Mbed TLS has been a component of Zephyr for some time, and the Mbed TLS project is in transition to the PSA crypto API. The question here isn't about a general crypto API, which is already the PSA Crypto API within Zephyr, but about a small number of cryptographic primitives that are used by other functionality built into Zephyr. Right now, these use some other ad-hoc libraries (e.g. tinycrypt) that have to be replaced due to lack of upstream support. We're proposing moving these to use the PSA crypto API, and in some sense, the requirements we need here are in regards to what these subsystems need. But, back to the above lists from @gregshue:
Again, to summarize. There are numerous points raised here. Many of them aren't really related to the use of a crypto API, and should be raised as their own issues. As far as using the PSA Crypto API within Zephyr, that's already the case. By officially adopting it, we're discussing migrating existing users of other crypto libraries (notably tinycrypt) to use the PSA API, and what requirements there are behind that. |
The crypto API would be affected by the system requirements, not the other way around.
We are evaluating an API to algorithms that could be implemented in hardware and may already be for downstream users, so "current" is irrelevant. For hardware implementations, those that interact with persistent storage, or even those that use generic DMA there may be something to de-initialize, so the API needs to provide the hook.
These need to be documented in the API and applied as constraints to all implementations. Now, what about for non-basic cryptographic operations? What about for the cases not done in by the networking worker threads? The downstream integrator must know this information to figure out if any implementation of this API is even an option.
Actually, it is pretty easy to enforce. Choose a relatively large number for N (e.g., 255); in a kernel file define two different types of symbols that are that differ only in the last character and the type associated with them (e.g., int8_t, uint8_t). If the linker doesn't support the necessary resolution you will get a build failure. If any symbol file includes a non-mangled symbol of >N characters generate a build failure.
We are gathering requirements related to APIs and related to system so we can evaluate whether or not the PSA crypto API meets them. It happens to meet this requirement, but not others already identified.
At the last TSC meeting they decided to kick off a new Project in the organization for looking in to Global Namespace Mgmt. It was created 5 days ago.
Zephyr does not support restarting threads, so canceling/killing a running thread is not an option. In general, the driver must solve the problem. If the problem requires a hardware change to support the capability, then that particular hardware does not meet all the system requirements and has a more limited application space. Now, what about supporting multiple API instances in the same executable (alternate implementations)? |
This is actually the opposite of what I mean by enforcing. In order for Zephyr to be able to say that it doesn't have any symbols that differ after N characters, we need a tool that can evaluate the entire Zephyr tree and determine if there are any conflicts. I don't believe this tool currently exists (although it wouldn't be difficult to add something to do this based on the output of 'nm' for a given build. You're approach really only would tell you if a given tool doesn't support N distinct characters, which isn't actually something Zephyr needs to know (it might be useful to someone). I do believe this is a fairly minor issue. It probably should be raised (completely independently of this issue), since it is real. But, I would like to see some evidence of toolchains that have small limits on distinct characters. Practically, I think this is much easier to solve by just fixing the issues that are found (since C99 requires 31 characters, and conflicts past that are likely to be uncommon). |
|
These issues aside, we are getting very distracted from the question being raised by this issue, which is whether or not Zephyr should consider the PSA crypto API to replace some of the other APIs that are used within the system. This issue is not about whether Zephyr will use or provide the PSA crypto API. That is already the case. What we are wanting to do here is replace the usage of two existing crypto APIs (both limited to a fairly small scope), and change the in-Zephyr code that uses these APIs to use the PSA API instead. In addition, this will involve deprecating these APIs, and giving an opportunity for any clients that are currently using them to migrate to the PSA API. In this light, I'd like to ask if we can try to keep this issue focused on this specific question. There are a lot of other concerns raised, and these should be raised in other issues, if necessary. Notably, whether we provide the PSA crypto API is not a question here, as this API is already available in Zephyr. This issue should focus on code, both within Zephyr, and external code that makes use of https://github.com/zephyrproject-rtos/zephyr/blob/main/include/crypto/crypto.h, as well as uses the tinycrypt library, as we want to deprecate these interfaces, and migrate this code to use the PSA crypto APIs. In light of this, the main constraint (brought up in the description of this issue) has to do with the compact implementation of elliptic curve crypto in the tiny crypt library. The Mbed TLS ECC implementation is both larger and slower, and also requires heap allocation, which tinycrypt does not. It is worth investigating whether implementing a PSA wrapper for the ECC operations in uECC (the upstream code used in Tinycrypt) will be sufficient for the needs of current code that makes use of the API. |
|
I'd also like to know that if anyone is aware of a crypto implementation that uses a different API, it would be good to hear about it. We would have to replace a lot of code to move to something that isn't Mbed TLS (at least that has a different API). I'm aware of Wolf-SSL, which, although would work with Zephyr, the free version is likely to not be license compatible with Zephyr code. Wolf SSL has also implemented the PSA Crypto API. Replacing the entire crypto API with a different one would be a lot of work, and probably of limited benefit, especially as I'm not aware of anything comparable. The Zephyr project is certainly not in a position to implement and maintain its own body of code comparable to Mbed TLS. |
|
I'm a bit confused by the overall conversation, particularly after the last security call. PSA doesn't cover every possible edge case. Clearly. It's also good to identify the use cases it doesn't give us 100% coverage of and figure out what we can or should do to address those. But does not having every use case covered exclude the choice to migrate to the PSA API, and if PSA is deemed 'insufficient', what's the alternative here? I don't really see anything else that would give us something better. PSA isn't perfect ... but what's the net gain alternative? This make me think of DeviceTree a bit. Zephyr makes use of DT as a useful abstraction for variations in HW, but the way we do DT today certainly doesn't cover every possible use case. It's imperfect. But that's how engineering works ... you have a goal in mind, and you take the tools that you do have today, you make compromises that at least move in the desired direction, and invest in tooling making things better as you go. We're constantly improving Zephyr's DT implementation and tooling to enable various edge cases as we go. It seems to me the PSA API is similar, and it brings clear value to the project as a common starting point, and we're certainly free to iterate on it, engage with the PSA authors upstream, and adapt it to our needs, and as with DT it brings more benefit to Zephyr than not having anything at all. I understand the valid concerns being made about things the PSA and Zephyr can't do today. But to me none of that precludes officially adopting PSA as a common API for crypto etc. Those feel like very different issues, and not being able to do X/Y/Z with PSA today doesn't, in my mind, exclude a migration to PSA, anymore than not being able to model X/Y/Z in DT means we should reject DT at a project level either. |
|
@carlescufi wrote:
Unfortunately, we do have to figure something out, because tinycrypt has become unmaintained. However, the ECC code within it isn't originally from tinycrypt, but comes from a project uECC (https://github.com/kmackay/micro-ecc, which although not highly active, does seem to have an active maintainer). It would be possible to replace hash and cipher options with Mbed TLS, and if configured properly, shouldn't be that large of a code-size increase, and either 1. continue to use the uECC code for the ECC operations within Bluetooth, or implement uECC as an ECC backend for PSA. Whether this solution is viable for Bluetooth is really the main point of this issue and discussion. |
|
@gregshue It seems like some of the concerns you're raising should in fact be individual requirements in the larger security planning of Zephyr, and they should be filed individually and tracked and addressed (via the security project page in Zephyr, etc.) based on current needs, resources and priorities. This issue specifically is trying to address one such problem: TinyCrypt being unmaintained, and Zephyr likely having to move away from it, and what we do at an API level to harmonize our general approach to crypto to resolve this issue today and in the future. PSA is the one viable API solution I'm aware of myself, imperfect as it may be, meaning that we need to figure out how to address the performance issues of MbedTLS as one implementation of the PSA API with the requirements of the BLE and other security-depedent subsystems. That can mean several things:
Relying on an unmaintained crypto library doesn't seem like a valid long term solution here, though, and PSA gives us a neutral, somewhat mature and vetted translation layer that allows us to solve this problem (with additional engineering effort), and adds flexibility as other crypto issues bubble to the surface in the future. It doesn't solve every problem, or consider every use case, but we can address those requirements case by case unless a better intial proposition is put on the table. The problem with TinyCrypt isn't going away, so we need to propose something. I'd encourage you to raise individual issues with the larger security planning/goals of the project (controlled de-initialization, etc.), tracking those goals here: https://github.com/zephyrproject-rtos/zephyr/projects/24 But I'm not persuaded those concerns preclude adopting PSA as a first large steps towards making crypto more maintainable longer term for the Zephyr project simply because PSA won't solve every problem out of the box. Of course it won't, but as a community we can still work towards addressing needs case by case, and again ... what's a better alternative if PSA is insufficient, as were early attempts at adopting DT in Zephyr? |
|
The statement that the PSA Crypto APIs doesn't do deinitialization is only partially true. I want to split my answer into two parts:
I'm going to use the standardized terms in PSA for crypto drivers. Crypto-functionality executed on an external chip is interfaced through an Transient states There are in fact standard features in Mbed TLS to do deinitialization of context information for individual crypto operations. These are used for error-scenarios and for aborted or finalized operations. A similar functionality is extended to PSA Crypto APIs run in environments with TrustZone features is used (e.g. in TF-M). In this case the functionality is also coupled with bookkeeping of a finite number of "accessible slots" to do cryptographic operations inside the secure image. Anything that fails or is finalized must be deinitialized by the system to make room for the next operation. The same functionality also exists for cryptography executed using oqaue drivers. It is completely up to the implementer of an opaque driver type to do bookeeping at failure or finalization or an operation to set the external chip in a quiescent state (including optionally handling DMA, interrupts etc.) Global states The Mbed TLS implementation keeps some global information after I would suggest proposing an addition to the PSA Crypto API spec for deinitialization. We can propose When it comes to PSA driver layer (transparent and opaque) the documentation in Mbed TLS project states that the drivers can have an init-function (if need be). We would need to propose an addition to do PSA driver deinitialization to handle clearing out global states. With a few additions, then there will be no problem to do cleanups of DMA, interrupts and caches and reaching quiescent state of any external chips. PSA Crypto APIs (and drivers) may be a bit simplistic on global state management right now, but it wouldn't take a lot to rectify this.... |
|
There are multiple ways persistent storage work in the PSA crypto APIs so a bit of explanation is needed to ensure a full understanding of the options (and the impacts). Simple usecase: Keys stored in regular flash The PSA Crypto APIs have been developed with the Arm PSA (e.g. via TF-M) as the backdrop. There is a distinguishing between crypto operations and storage operations inside the Arm PSA specification. The key storage for crypto operations is placed in a module called the Every API that handles persistent key storage and retrieval in PSA Crypto APIs in Mbed TLS will sooner or later call an ITS API under the hood. On devices that can use TF-M: Implement a flash driver for your device and everything is provided out-of-the-box Efforts on our part: The decision will be whether or not to use Mbed TLS implementation for key handling (with addition of native ITS support) or to build this functionality from scratch Complex usecase: Keys stored in external security chip The PSA Crypto implementation in Mbed TLS describes the term The opaque PSA drivers is supported in such a way that you can use pre-provisioned keys or import keys on your own (if the external security chip supports it). The way to distinguish between these keys and volatile key or keys stored in regular flash (e.g. using PSA ITS) is the identifier for the key. Efforts on our part: Limited. We just need to support opaque PSA drivers to ensure that any customer that has a specialized way of storing keys off-chip still get the features they need |
|
@d3zd3z wrote:
In that case this issue is poorly named and described. It sounds like you simply want to deprecate the existing non-PSA crypto APIs. There is no need to "adopt" or evaluate anything, the listing of a proprietary api as an alternative is really out-of-scope, and the problem of not being able to "take full advantage of HW accelerators" is irrelevant to this issue. Maintainers would automatically migrate to the existing non-deprecated API. @microbuilder wrote:
Safety systems, and now secure IoT systems (due to regulations), need to be engineered to meet requirements imposed on the system by the customers (end users)/stakeholders (Linux Foundation, etc.). We get to compromise on design decisions, but compromises on requirements must be negotiated with the stakeholders. @frkv wrote:
I completely agree that it wouldn't take a lot to rectify this. I just was raising awareness that it currently doesn't solve the stated problem and we have needs that they don't seem to be aware of or concerned with. |
|
@microbuilder Do you see de-initialization as an enhancement request (to SYS_INIT()), as a new feature, or as an RFC/proposal? |
Indeed, most of this probably is out of scope for this issue. But, that doesn't mean the discussion is unwanted or unwarranted. Bringing the issues up is how we learn about them. Keep in mind, also, that bringing up requirements, even creating issues to track them, doesn't necessarily mean they are going to be addressed. Zephyr is a collaborative effort. For the most part, there isn't anybody sitting around waiting to work on requested features, and for the most part, features will have to be implemented by those that need them. The advantage we have, is that a lot of these issues, esp things like deinitialization, are likely to be shared needs, and the implementation effort can also be shared. |
Ideally, an RFC/proposal in my opinion stating clearly how you think this could or should work. This brings up an interesting detail for the PSA API, though. PSA is written in isolation from the implementation(s) itself. As you alluded to in an earlier comment, it defines requirements, codifying those in an API and reference documentation, and those are then implemented in something like TF-M (as a reference PSA implementation). The requirement comes first. In order to influence the PSA API, we need to define new requirements for consideration in the published standards, and make a specific API suggestions to them. I'm not 100% sure what the ideal workflow for that is. We can do that in Zephyr as an RFC/proposal, and once consensus is reached that it solves our needs, escalate that for review to the PSA authors. But we probably do need to determine how this works to have it officially considered for adoption into the PSA, or if we're OK with Zephyr-specific additions on top of the published standards. |
|
I'll create the initial RFC for clean handoff of HW state from boot to app image. This will provide one user need for general de-initialization, leading to the PSA proposal. |
As part of ongoing work to move away from TinyCrypt and towards PSA (zephyrproject-rtos#43712), make fs_mgmt use either PSA (when available) or MbedTLS (as a fallback) for SHA-256. The use of PSA is guarded by CONFIG_MBEDTLS_PSA_CRYPTO_CLIENT which requires a locally-built PSA core for devices without TF-M. Signed-off-by: Tomi Fontanilles <[email protected]>
As part of ongoing work to move away from TinyCrypt and towards PSA (zephyrproject-rtos#43712), make fs_mgmt use either PSA (when available) or MbedTLS (as a fallback) for SHA-256. The use of PSA is guarded by CONFIG_MBEDTLS_PSA_CRYPTO_CLIENT which requires a locally-built PSA core for devices without TF-M. Signed-off-by: Tomi Fontanilles <[email protected]>
As part of ongoing work to move away from TinyCrypt and towards PSA (zephyrproject-rtos#43712), make fs_mgmt use either PSA (when available) or MbedTLS (as a fallback) for SHA-256. The use of PSA is guarded by CONFIG_MBEDTLS_PSA_CRYPTO_CLIENT which requires a locally-built PSA core for devices without TF-M. Signed-off-by: Tomi Fontanilles <[email protected]>
As part of ongoing work to move away from TinyCrypt and towards PSA (zephyrproject-rtos#43712), make fs_mgmt use either PSA (when available) or MbedTLS (as a fallback) for SHA-256. The use of PSA is guarded by CONFIG_MBEDTLS_PSA_CRYPTO_CLIENT which requires a locally-built PSA core for devices without TF-M. Signed-off-by: Tomi Fontanilles <[email protected]>
As part of ongoing work to move away from TinyCrypt and towards PSA (zephyrproject-rtos#43712), make fs_mgmt use either PSA (when available) or MbedTLS (as a fallback) for SHA-256. The use of PSA is guarded by CONFIG_MBEDTLS_PSA_CRYPTO_CLIENT which requires a locally-built PSA core for devices without TF-M. Signed-off-by: Tomi Fontanilles <[email protected]>
As part of ongoing work to move away from TinyCrypt and towards PSA (zephyrproject-rtos#43712), make fs_mgmt use either PSA (when available) or MbedTLS (as a fallback) for SHA-256. The use of PSA is guarded by CONFIG_MBEDTLS_PSA_CRYPTO_CLIENT which requires a locally-built PSA core for devices without TF-M. Signed-off-by: Tomi Fontanilles <[email protected]>
As part of ongoing work to move away from TinyCrypt and towards PSA (#43712), make fs_mgmt use either PSA (when available) or MbedTLS (as a fallback) for SHA-256. The use of PSA is guarded by CONFIG_MBEDTLS_PSA_CRYPTO_CLIENT which requires a locally-built PSA core for devices without TF-M. Signed-off-by: Tomi Fontanilles <[email protected]>
As part of ongoing work to move away from TinyCrypt and towards PSA (zephyrproject-rtos#43712), make fs_mgmt use either PSA (when available) or MbedTLS (as a fallback) for SHA-256. The use of PSA is guarded by CONFIG_MBEDTLS_PSA_CRYPTO_CLIENT which requires a locally-built PSA core for devices without TF-M. Signed-off-by: Tomi Fontanilles <[email protected]>
As part of ongoing work to move away from TinyCrypt and towards PSA (zephyrproject-rtos#43712), introduce a PSA option and remove the TinyCrypt one for the SHA-256 implementation. The Mbed TLS implementation is modified to use `mbedtls_sha256` directly for smaller code size. The reliance of mgmt/updatehub on storage/flash_map's configuration (`FLASH_AREA_CHECK_INTEGRITY_BACKEND`) is removed. The choice of which implementation to use is made automatically, based on whether a PSA API provider is present (`PSA_CRYPTO_CLIENT`). Signed-off-by: Tomi Fontanilles <[email protected]>
As part of ongoing work to move away from TinyCrypt and towards PSA (zephyrproject-rtos#43712), introduce a PSA option and remove the TinyCrypt one for the SHA-256 implementation. The Mbed TLS implementation is modified to use `mbedtls_sha256` directly for smaller code size. As of now the implementation defaults to PSA only if TF-M is enabled because a dependency loop happens if using `PSA_CRYPTO_CLIENT` as a condition in `FLASH_AREA_CHECK_INTEGRITY_BACKEND`. A test case is added for the PSA implementation, and an NS platform is added to the base test case to verify the compilation on a TF-M-enabled platform. Signed-off-by: Tomi Fontanilles <[email protected]>
As part of ongoing work to move away from TinyCrypt and towards PSA (zephyrproject-rtos#43712), introduce a PSA option and remove the TinyCrypt one for the SHA-256 implementation. The Mbed TLS implementation is modified to use `mbedtls_sha256` directly for smaller code size. The reliance of mgmt/updatehub on storage/flash_map's configuration (`FLASH_AREA_CHECK_INTEGRITY_BACKEND`) is removed. The choice of which implementation to use is made automatically, based on whether a PSA API provider is present (`PSA_CRYPTO_CLIENT`). Signed-off-by: Tomi Fontanilles <[email protected]>
As part of ongoing work to move away from TinyCrypt and towards PSA (zephyrproject-rtos#43712), introduce a PSA option and remove the TinyCrypt one for the SHA-256 implementation. The Mbed TLS implementation is modified to use `mbedtls_sha256` directly for smaller code size. As of now the implementation defaults to PSA only if TF-M is enabled because a dependency loop happens if using `PSA_CRYPTO_CLIENT` as a condition in `FLASH_AREA_CHECK_INTEGRITY_BACKEND`. A test case is added for the PSA implementation, and an NS platform is added to the base test case to verify the compilation on a TF-M-enabled platform. Signed-off-by: Tomi Fontanilles <[email protected]>
As part of ongoing work to move away from TinyCrypt and towards PSA (zephyrproject-rtos#43712), introduce a PSA option and remove the TinyCrypt one for the SHA-256 implementation. The Mbed TLS implementation is modified to use `mbedtls_sha256` directly for smaller code size. The reliance of mgmt/updatehub on storage/flash_map's configuration (`FLASH_AREA_CHECK_INTEGRITY_BACKEND`) is removed. The choice of which implementation to use is made automatically, based on whether a PSA API provider is present (`PSA_CRYPTO_CLIENT`). Signed-off-by: Tomi Fontanilles <[email protected]>
As part of ongoing work to move away from TinyCrypt and towards PSA (zephyrproject-rtos#43712), introduce a PSA option and remove the TinyCrypt one for the SHA-256 implementation. The Mbed TLS implementation is modified to use `mbedtls_sha256` directly for smaller code size. As of now the implementation defaults to PSA only if TF-M is enabled because a dependency loop happens if using `PSA_CRYPTO_CLIENT` as a condition in `FLASH_AREA_CHECK_INTEGRITY_BACKEND`. A test case is added for the PSA implementation, and an NS platform is added to the base test case to verify the compilation on a TF-M-enabled platform. Signed-off-by: Tomi Fontanilles <[email protected]>
As part of ongoing work to move away from TinyCrypt and towards PSA (zephyrproject-rtos#43712), introduce a PSA option and remove the TinyCrypt one for the SHA-256 implementation. The Mbed TLS implementation is modified to use `mbedtls_sha256` directly for smaller code size. The reliance of mgmt/updatehub on storage/flash_map's configuration (`FLASH_AREA_CHECK_INTEGRITY_BACKEND`) is removed. The choice of which implementation to use is made automatically, based on whether a PSA API provider is present (`PSA_CRYPTO_CLIENT`). Signed-off-by: Tomi Fontanilles <[email protected]>
As part of ongoing work to move away from TinyCrypt and towards PSA (zephyrproject-rtos#43712), introduce a PSA option and remove the TinyCrypt one for the SHA-256 implementation. The Mbed TLS implementation is modified to use `mbedtls_sha256` directly for smaller code size. As of now the implementation defaults to PSA only if TF-M is enabled because a dependency loop happens if using `PSA_CRYPTO_CLIENT` as a condition in `FLASH_AREA_CHECK_INTEGRITY_BACKEND`. A test case is added for the PSA implementation, and an NS platform is added to the base test case to verify the compilation on a TF-M-enabled platform. Signed-off-by: Tomi Fontanilles <[email protected]>
As part of ongoing work to move away from TinyCrypt and towards PSA (zephyrproject-rtos#43712), introduce a PSA option and remove the TinyCrypt one for the SHA-256 implementation. The Mbed TLS implementation is modified to use `mbedtls_sha256` directly for smaller code size. The reliance of mgmt/updatehub on storage/flash_map's configuration (`FLASH_AREA_CHECK_INTEGRITY_BACKEND`) is removed. The choice of which implementation to use is made automatically, based on whether a PSA API provider is present (`PSA_CRYPTO_CLIENT`). Signed-off-by: Tomi Fontanilles <[email protected]>
As part of ongoing work to move away from TinyCrypt and towards PSA (zephyrproject-rtos#43712), introduce a PSA option and remove the TinyCrypt one for the SHA-256 implementation. The Mbed TLS implementation is modified to use `mbedtls_sha256` directly for smaller code size. As of now the implementation defaults to PSA only if TF-M is enabled because a dependency loop happens if using `PSA_CRYPTO_CLIENT` as a condition in `FLASH_AREA_CHECK_INTEGRITY_BACKEND`. A test case is added for the PSA implementation, and an NS platform is added to the base test case to verify the compilation on a TF-M-enabled platform. Signed-off-by: Tomi Fontanilles <[email protected]>
As part of ongoing work to move away from TinyCrypt and towards PSA (zephyrproject-rtos#43712), introduce a PSA option and remove the TinyCrypt one for the SHA-256 implementation. The Mbed TLS implementation is modified to use `mbedtls_sha256` directly for smaller code size. The reliance of mgmt/updatehub on storage/flash_map's configuration (`FLASH_AREA_CHECK_INTEGRITY_BACKEND`) is removed. The choice of which implementation to use is made automatically, based on whether a PSA API provider is present (`PSA_CRYPTO_CLIENT`). This commit also add a test case with PSA (based on Mbed TLS) in samples/subsys/mgmt/updatehub/sample.yaml. Signed-off-by: Tomi Fontanilles <[email protected]> Signed-off-by: Valerio Setti <[email protected]>
As part of ongoing work to move away from TinyCrypt and towards PSA (zephyrproject-rtos#43712), introduce a PSA option and remove the TinyCrypt one for the SHA-256 implementation. The Mbed TLS implementation is modified to use `mbedtls_sha256` directly for smaller code size. As of now the implementation defaults to PSA only if TF-M is enabled because a dependency loop happens if using `PSA_CRYPTO_CLIENT` as a condition in `FLASH_AREA_CHECK_INTEGRITY_BACKEND`. A test case is added for the PSA implementation, and an NS platform is added to the base test case to verify the compilation on a TF-M-enabled platform. Signed-off-by: Tomi Fontanilles <[email protected]>
As part of ongoing work to move away from TinyCrypt and towards PSA (zephyrproject-rtos#43712), introduce a PSA option and remove the TinyCrypt one for the SHA-256 implementation. The Mbed TLS implementation is modified to use `mbedtls_sha256` directly for smaller code size. The reliance of mgmt/updatehub on storage/flash_map's configuration (`FLASH_AREA_CHECK_INTEGRITY_BACKEND`) is removed. The choice of which implementation to use is made automatically, based on whether a PSA API provider is present (`PSA_CRYPTO_CLIENT`). This commit also add a test case with PSA (based on Mbed TLS) in samples/subsys/mgmt/updatehub/sample.yaml. Signed-off-by: Tomi Fontanilles <[email protected]> Signed-off-by: Valerio Setti <[email protected]>
As part of ongoing work to move away from TinyCrypt and towards PSA (zephyrproject-rtos#43712), introduce a PSA option and remove the TinyCrypt one for the SHA-256 implementation. The Mbed TLS implementation is modified to use `mbedtls_sha256` directly for smaller code size. As of now the implementation defaults to PSA only if TF-M is enabled because a dependency loop happens if using `PSA_CRYPTO_CLIENT` as a condition in `FLASH_AREA_CHECK_INTEGRITY_BACKEND`. A test case is added for the PSA implementation, and an NS platform is added to the base test case to verify the compilation on a TF-M-enabled platform. Signed-off-by: Tomi Fontanilles <[email protected]>
As part of ongoing work to move away from TinyCrypt and towards PSA (#43712), introduce a PSA option and remove the TinyCrypt one for the SHA-256 implementation. The Mbed TLS implementation is modified to use `mbedtls_sha256` directly for smaller code size. The reliance of mgmt/updatehub on storage/flash_map's configuration (`FLASH_AREA_CHECK_INTEGRITY_BACKEND`) is removed. The choice of which implementation to use is made automatically, based on whether a PSA API provider is present (`PSA_CRYPTO_CLIENT`). This commit also add a test case with PSA (based on Mbed TLS) in samples/subsys/mgmt/updatehub/sample.yaml. Signed-off-by: Tomi Fontanilles <[email protected]> Signed-off-by: Valerio Setti <[email protected]>
As part of ongoing work to move away from TinyCrypt and towards PSA (#43712), introduce a PSA option and remove the TinyCrypt one for the SHA-256 implementation. The Mbed TLS implementation is modified to use `mbedtls_sha256` directly for smaller code size. As of now the implementation defaults to PSA only if TF-M is enabled because a dependency loop happens if using `PSA_CRYPTO_CLIENT` as a condition in `FLASH_AREA_CHECK_INTEGRITY_BACKEND`. A test case is added for the PSA implementation, and an NS platform is added to the base test case to verify the compilation on a TF-M-enabled platform. Signed-off-by: Tomi Fontanilles <[email protected]>
As part of ongoing work to move away from TinyCrypt and towards PSA (zephyrproject-rtos#43712), introduce a PSA option and remove the TinyCrypt one for the SHA-256 implementation. The Mbed TLS implementation is modified to use `mbedtls_sha256` directly for smaller code size. The reliance of mgmt/updatehub on storage/flash_map's configuration (`FLASH_AREA_CHECK_INTEGRITY_BACKEND`) is removed. The choice of which implementation to use is made automatically, based on whether a PSA API provider is present (`PSA_CRYPTO_CLIENT`). This commit also add a test case with PSA (based on Mbed TLS) in samples/subsys/mgmt/updatehub/sample.yaml. Signed-off-by: Tomi Fontanilles <[email protected]> Signed-off-by: Valerio Setti <[email protected]>
As part of ongoing work to move away from TinyCrypt and towards PSA (zephyrproject-rtos#43712), introduce a PSA option and remove the TinyCrypt one for the SHA-256 implementation. The Mbed TLS implementation is modified to use `mbedtls_sha256` directly for smaller code size. As of now the implementation defaults to PSA only if TF-M is enabled because a dependency loop happens if using `PSA_CRYPTO_CLIENT` as a condition in `FLASH_AREA_CHECK_INTEGRITY_BACKEND`. A test case is added for the PSA implementation, and an NS platform is added to the base test case to verify the compilation on a TF-M-enabled platform. Signed-off-by: Tomi Fontanilles <[email protected]>
Introduction
Zephyr has currently, at least, three different cryptography available and been used. They are:
The lack of an unified API to cryptography leads to a situation where we have different components using the one that best attend there needs and when an application needs those components we end up having multiple cryptography implementations in a single target. This means resources being waste.
To make things worse, one of these implementations (TinyCrypt) is no longer supported, which put us in a position of maintain it by ourselves or replace it with something else.
PSA Crypto implementation provides a portable interface to cryptographic operations on a wide range of hardware and software. Which means we may have Zephyr's using a single API that can have different implementations depending in build options.
More information about it can be found in https://armmbed.github.io/mbed-crypto/html/overview/intro.html
Problem description
The lack of ONE API may cause waste of resources (multiple implementations needed at same time), make products more vulnerable (multiple implementations increases the code surface and consequently the chance of bugs), and it does help us take full advantage of HW accelerators.
Proposed change
The proposal is to adopt psa crypto API on Zephyr to replace the direct usage of other cryptography implementations.
Detailed RFC
The initial idea is:
Concerns and Unresolved Questions
Alternatives
The text was updated successfully, but these errors were encountered: