Developers targeting browser-wasm can use Web Crypto APIs

[marek-safar]

We want to avoid shipping OpenSSL for Browser as that’s not something that aligns well with web nature of WebAssembly as well as it has noticeable impacts on the size of the final app. This would also save us from having to deal with zero-day vulnerabilities as well as support for crypto algorithms which are only secure if they use special CPU instructions (RNG and AES for example).

Using the platform native crypto functions is the preferred solution as it does not have any noticeable size and it’s also the most performant solution. All browser have nowadays support for Crypto APIs which we should be able to use to implement the core crypto functions required by BCL.

Relevant documentation can be found at https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto. The tricky part will be to deal with the async nature of these APIs but we could introduce new async APIs to make the integration easier.

.NET has support for old/obscure algorithms and also other features like certificates which are not relevant in browser space and for them, we would keep throwing PNSE.

Design Proposal

The design proposal for how we will enable cryptographic algorithms in .NET for WebAssembly can be found here:
https://github.com/dotnet/designs/blob/main/accepted/2021/blazor-wasm-crypto.md

We intend on providing the most secure implementations of cryptographic algorithms when available. On browsers which support SharedArrayBuffer, we will utilize that as a synchronization mechanism to perform a sync-over-async operation, letting the browser's secure SubtleCrypto implementation act as our cryptographic primitive. On browsers which do not support SharedArrayBuffer, we will fall back to in-box managed algorithm implementations of these primitives.

Where managed algorithm implementations are needed, they can be migrated from the .NET Framework Reference Source.

• https://github.com/microsoft/referencesource/tree/master/mscorlib/system/security/cryptography
• https://github.com/microsoft/referencesource/tree/master/System.Core/System/Security/Cryptography

Work Items

• SHA1
• SHA256
• SHA384
• SHA512
• HMACSHA1
• HMACSHA256
• HMACSHA384
• HMACSHA512
• AES-CBC
  • AES-ECB and AES-CFB should throw PlatformNotSupportedException, as they are not available in webcrypto
• PBKDF2 (via Rfc2898DeriveBytes)
• HKDF

Acceptance Criteria

• Integrate into arch-wasm infrastructure
• Ensure a productive development/testing workflow with WebAssembly
• Get all existing unit tests for the algorithms passing in WebAssembly
• Look for opportunities to improve argument validation
• Look for opportunities to modernize the code, such as using Span
• Validate end-to-end scenarios in desktop browsers that support SharedArrayBuffer
• Validate end-to-end scenarios in mobile browsers that support SharedArrayBuffer
• Validate end-to-end scenarios in desktop browsers that do not support SharedArrayBuffer
• Validate end-to-end scenarios in mobile browsers that do not support SharedArrayBuffer

Issues to address

• review SubtleCrypto fallback scenarios #69741
• WASM error handling in SubtleCrypto through web worker #69740
• Test failures in hashing on Browser #69806

[ghost]

Tagging subscribers to this area: @bartonjs, @vcsjones, @krwq
See info in area-owners.md if you want to be subscribed.

[jaykrell]

only secure if they use special CPU instructions (RNG and AES for example

Really "only secure"? Or just faster?

[bartonjs]

Really "only secure"? Or just faster?

AES is literally only secure with dedicated hardware instructions on modern CPUs. All software implementations are subject to various timing problems that ultimately leak the key to a dedicated attack (http://cr.yp.to/antiforgery/cachetiming-20050414.pdf).

[GrabYourPitchforks]

As part of this work item, we should also verify that RandomNumberGenerator is correctly plumbed down to crypto.getRandomValues. Right now it's plumbed through /dev/random, which I think the Mono wasm engine ties through correctly, but it's always good to remove indirection and points of failure where possible.

[kjpou1]

Looking into support and providing a prototype that works with browser os.

[jeffhandley]

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. As a result, we've changed the scope of what will be included in .NET 7 to no longer include AES-CBC. Additionally, instead of using SubtleCrypto via the SharedArrayBuffer to reach the native implementations of other algorithms, we will rely wholly on managed implementations.

Please see #73858 for more information and refer to the design document for more information about the managed implementation expectations.

Where native implementations need to be accessed, they will need to be called via JavaScript interop.