search

dotnet / runtime

.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.
https://docs.microsoft.com/dotnet/core/
MIT License
15.15k stars 4.71k forks source link

Remove AES and SubtleCrypto from WASM #73858

Closed radical closed 2 years ago

radical commented 2 years ago

We've concluded that using the SharedArrayBuffer approach via a worker is not yielding the end-to-end experience or quality necessary to release this integration. Details and commentary on dotnet/runtime#72810 show some specific challenges that emerged:

  1. Blazor uses their own runtime initialization path and the crypto initialization call is not included in that path (or public)
    • This was addressable
  2. Blazor's publish targets limit what files end up in the publish output history
    • This was addressable
  3. Chromium is soon going to start limiting SharedArrayBuffer to be available only for cross-origin isolated sites. This will take effect as of Chromium v106.
    • This would require impactful changes to behavior that can't be justified at this stage of the release cycle for this feature
    • dotnet/aspnetcore#42114
  4. A deadlock that was discovered
    • This specific deadlock was addressable, but it's possible others are lurking
    • dotnet/runtime#73537

These challenges lead to discussions about how often the managed implementations apply vs. the SubtleCrypto implementations. When we laid out the plan to rely on SubtleCrypto through SharedArrayBuffer, we understood this would enable us to use SubtleCrypto in ~90% of scenarios. The plan was to only fall back to managed implementations "on browsers which do not support SharedArrayBuffer. However, with the recognition that the default end-to-end experience disallows use of SharedArrayBuffer broadly, that changed the picture dramatically. We now find ourselves in the situation where 90% or more of scenarios will be relying on the managed implementations, and customers desiring the native implementations must consider tradeoffs for other behavior changes that will occur in their applications. That's not an acceptable outcome.

With these findings and realizations, we're dialing back what we'll be able to support, and we will not rely on a SharedArrayBuffer bridge to invoke async SubtleCrypto APIs from synchronous .NET code. Instead, the supported algorithms will be exclusively supported via managed code and scoped to algorithms without known side channel leaks of the key. Per the original design document:

The implementations of our in-box managed algorithms will be faithful to the appropriate standards. However, we will not pursue FIPS 140-2 or any other certification for them. Our in-box managed algorithm implementations are not intended to be free of side channels.

Here's the net result of the changes to what will be supported.

API .NET 6 .NET 7 - Planned .NET 7 - Actual
MD5 Not Supported Not supported Not supported
SHA1 Managed SubtleCrypto (managed fallback) Managed
SHA256 Managed SubtleCrypto (managed fallback) Managed
SHA384 Managed SubtleCrypto (managed fallback) Managed
SHA512 Managed SubtleCrypto (managed fallback) Managed
HMACMD5 Not supported Not supported Not supported
HMACSHA1 Not supported SubtleCrypto (managed fallback) Managed
HMACSHA256 Not supported SubtleCrypto (managed fallback) Managed
HMACSHA384 Not supported SubtleCrypto (managed fallback) Managed
HMACSHA512 Not supported SubtleCrypto (managed fallback) Managed
AES-CBC (key sizes 128 + 256) Not supported SubtleCrypto (managed fallback) Not supported
PBKDF2 (via Rfc2898DeriveBytes) Not supported SubtleCrypto (managed fallback) Managed
HKDF Not supported SubtleCrypto (managed fallback) Managed
Asymmetric Not supported Not supported Not supported
Certificates Not supported Not supported Not supported

We do not have plans to try this integration with SubtleCrypto again. Instead, for customers needing native implementations or unsupported algorithms such as AES, we advise they use JavaScript interop to invoke SubtleCrypto directly. That approach will allow the application to be written such that the call can be made in an asynchronous context.

Tasks

cc @pavelsavara @maraf @lambdageek @eerhardt

ghost commented 2 years ago

Tagging subscribers to 'arch-wasm': @lewing See info in area-owners.md if you want to be subscribed.

Issue Details
- [ ] Remove the worker from WasmAppBuilder - [ ] Remove the call from startup.ts - [ ] Remove the DLLImports - [ ] Remove the C# code that is calling this - [ ] Remove the special behavior type cc @pavelsavara @maraf @lambdageek @eerhardt
Author: radical
Assignees: -
Labels: `arch-wasm`, `area-VM-meta-mono`
Milestone: -
vcsjones commented 2 years ago

No rush but.. can someone explain a bit what exactly the intention is here? We found a way to use subtlecrypto without SharedArrayBuffer?

jeffhandley commented 2 years ago

@vcsjones I've updated the issue title and description to capture what we found we need to do. At a high level, we found the SharedArrayBuffer bridge to SubtleCrypto was not yielding the end-to-end experience we had relied on being able to achieve.

vcsjones commented 2 years ago

~@jeffhandley is this specific to AES, or is HMAC / PBKDF2 included as well?~

Never mind I can't read. It's spelled out nicely in the table.

vcsjones commented 2 years ago

I am curious why AES specifically, when it was my understanding that HMAC and PBKDF were also using the SharedArrayBuffer.

pavelsavara commented 2 years ago

No rush but.. can someone explain a bit what exactly the intention is here? We found a way to use subtlecrypto without SharedArrayBuffer?

There is new interop with JavaScript based on [JSImportAttribute]. It could be used to wrap subtlecrypto's asynchronous API. Applications with requirements to use certified crypto could find a way how to call it asynchronously.

That integration could be independent Nuget package and doesn't have to be in the runtime code. It could also wrap asymmetric algorithms.

jeffhandley commented 2 years ago

I am curious why AES specifically, when it was my understanding that HMAC and PBKDF were also using the SharedArrayBuffer.

Thanks for calling that out, @vcsjones. I've edited the description again to be clearer that what remains supported is now only supported via managed implementations, with that scope being limited to algorithms without known side-channel leaks of keys.

ghost commented 2 years ago

Tagging subscribers to this area: @dotnet/area-system-security, @vcsjones See info in area-owners.md if you want to be subscribed.

Issue Details
We've concluded that using the `SharedArrayBuffer` approach via a worker is not yielding the end-to-end experience or quality necessary to release this integration. Details and commentary on dotnet/runtime#72810 show some specific challenges that emerged: 1. Blazor uses their own runtime initialization path and the crypto initialization call is not included in that path (or public) * This was addressable 2. Blazor's publish targets limit what files end up in the publish output history * This was addressable 3. Chromium is soon going to start limiting `SharedArrayBuffer` to be available only for cross-origin isolated sites. This will take effect as of Chromium v106. * This would require impactful changes to behavior that can't be justified at this stage of the release cycle for this feature * dotnet/aspnetcore#42114 4. A deadlock that was discovered * This specific deadlock was addressable, but it's possible others are lurking * dotnet/runtime#73537 These challenges lead to discussions about how often the managed implementations apply vs. the SubtleCrypto implementations. When we laid out the [plan to rely on SubtleCrypto through `SharedArrayBuffer`](https://github.com/dotnet/designs/blob/main/accepted/2021/blazor-wasm-crypto.md#discussion-1), we understood this would enable us to use SubtleCrypto in ~90% of scenarios. The plan was to only fall back to managed implementations "on browsers which do not support `SharedArrayBuffer`. However, with the recognition that the default end-to-end experience disallows use of `SharedArrayBuffer` broadly, that changed the picture dramatically. We now find ourselves in the situation where 90% or more of scenarios will be relying on the managed implementations, and customers desiring the native implementations must consider tradeoffs for other behavior changes that will occur in their applications. That's not an acceptable outcome. With these findings and realizations, we're dialing back what we'll be able to support, and we will not rely on a `SharedArrayBuffer` bridge to invoke async SubtleCrypto APIs from synchronous .NET code. Instead, the supported algorithms will be exclusively supported via managed code and scoped to algorithms without known side channel leaks of the key. Per the original design document: > The implementations of our in-box managed algorithms will be faithful to the appropriate standards. However, we will not pursue FIPS 140-2 or any other certification for them. Our in-box managed algorithm implementations are not intended to be free of side channels. Here's the net result of the changes to what will be supported. | API | .NET 6 | .NET 7 - Planned | .NET 7 - Actual | |-|-|-|-| | MD5 | Not Supported | Not supported | Not supported | | **SHA1** | **Managed** | **SubtleCrypto (managed fallback)** | **Managed** | | **SHA256** | **Managed** | **SubtleCrypto (managed fallback)** | **Managed** | | **SHA384** | **Managed** | **SubtleCrypto (managed fallback)** | **Managed** | | **SHA512** | **Managed** | **SubtleCrypto (managed fallback)** | **Managed** | | HMACMD5 | Not supported | Not supported | Not supported | | **HMACSHA1** | **Not supported** | **SubtleCrypto (managed fallback)** | **Managed** | | **HMACSHA256** | **Not supported** | **SubtleCrypto (managed fallback)** | **Managed** | | **HMACSHA384** | **Not supported** | **SubtleCrypto (managed fallback)** | **Managed** | | **HMACSHA512** | **Not supported** | **SubtleCrypto (managed fallback)** | **Managed** | | **AES-CBC (key sizes 128 + 256)** | **Not supported** | **SubtleCrypto (managed fallback)** | **Not supported** | | **PBKDF2 (via Rfc2898DeriveBytes)** | **Not supported** | **SubtleCrypto (managed fallback)** | **Managed** | | **HKDF** | Not supported | **SubtleCrypto (managed fallback)** | **Managed** | | Asymmetric | Not supported | Not supported | Not supported | | Certificates | Not supported | Not supported | Not supported | We do not have plans to try this integration with SubtleCrypto again. Instead, for customers needing native implementations or unsupported algorithms such as AES, we advise they use JavaScript interop to invoke SubtleCrypto directly. That approach will allow the application to be written such that the call can be made in an asynchronous context. ### Tasks - [ ] Remove the worker from WasmAppBuilder - [ ] Remove the call from startup.ts - [ ] Remove the DLLImports - [ ] Remove the C# code that is calling this - [ ] Remove the special `js-module-crypto` in `AssetBehaviours` typescrypt - [ ] Remove `js-module-crypto` handling in the SDK (replace it with `js-module-threads` would be useful) - [ ] Remove managed AES implementation - [x] Remove the subtlecrypto run of the tests (https://github.com/dotnet/runtime/pull/73884) cc @pavelsavara @maraf @lambdageek @eerhardt
Author: radical
Assignees: eerhardt
Labels: `arch-wasm`, `area-System.Security`, `blocking-release`
Milestone: 7.0.0
eerhardt commented 2 years ago

Re-opening to backport to 7.0

lewing commented 2 years ago

@eerhardt are we done here now?

eerhardt commented 2 years ago

Yes, the last task:

Remove js-module-crypto handling in the SDK was completed this morning when the new dotnet/runtime made its way into dotnet/sdk.

lewing commented 2 years ago

thanks again for all the help