Pluggable symmetric cryptography, an awaitable asymmetric path, registrable security policies, and PubSub crypto offboarding (#4206, #4207, #4208, #4210)

[marcschier]

Description

Closes the three crypto-offboarding follow-ups split out of #4192. Each was recorded there as knowingly not done, with the reason and what would justify revisiting it. Those conditions are met, and where one of them turned out to be unachievable that is written down rather than worked around.

The safety property throughout: every seam is opt-in and null-checked, and in the default software configuration the added code is observably inert. No interface dispatch on the per-message path, and the asynchronous paths complete synchronously — so channel locking order, buffer ownership and error sequencing are unchanged for a deployment that configures nothing.

#4207 — symmetric, key-derivation and RNG provider seams

ISymmetricCryptoProvider, IKeyDerivationProvider and ISecureRandomSource, added on the terms #4207 set: only once a concrete requirement arrived (a validated module that must perform every operation, not just the asymmetric ones), behind a fast path, with SymmetricChannelCryptoBenchmarks as the gate.

They are facets discovered by type test, not members of ICryptoProvider, so providers written against the shipped interface still compile. PlatformCryptoProvider implements all three, which answers the "an interface nothing implements" objection recorded in the issue.

CryptoProviderFacets returns null both when no registry is configured and when resolution lands on the platform, because the platform facets are the inline code. Resolution happens once, in CalculateSymmetricKeySizes, and is held for the life of the channel.

CryptoCompliance.GetUnservedOperationPurposes closes the failure the seam would otherwise introduce: a provider bound to ChannelSymmetric without implementing the facet is silently replaced by the platform, so a deployment could believe its validated module performed the per-message cryptography while the platform did. Under FipsOnly that now refuses to start.

#4208 — the asymmetric path is awaitable

RSA and ECDsa are .NET's contracts and cannot be replaced without making every ready-made hardware and cloud implementation unusable. Instead an implementation may also declare IAsyncRsaKey / IAsyncEcdsaKey, which the stack finds by type test.

Now asynchronous: the secure channel open and renew path, user identity token signing and decryption, and session activation. A software key declares neither facet, so those paths complete synchronously and nothing about their ordering changes.

ReadAsymmetricMessage is refactored into shared helpers rather than duplicated — adding an await was not worth two hundred cloned lines of signature, padding and endpoint-selection logic. AsymmetricMessage / AsymmetricWriteResult exist because an asynchronous method cannot have out parameters.

The channel no longer serialises its state on a monitor. A monitor cannot be held across an await, and a plain SemaphoreSlim was not an option at the time: the code relied on re-entrancy in eight places (HandleIncomingMessage holds the lock and calls ForceChannelFault, which takes it again; ForceReconnect and Shutdown do the same). ChannelGate replaces it at 32 sites and DataLock is [Obsolete]. That reliance has since been removed as well — see Removing the gate's re-entrancy below.

Defects this surfaced, all fixed and regression-tested

Detached work started inline. Writes were started with _ = WriteBuffersAsync(...). An async method runs its prologue on the caller's stack, so LeaveInheritedContext — which exists to stop detached work inheriting the right to re-enter the gate — was stripping the caller's own entitlement; when the send then completed synchronously, the completion blocked on a gate that very thread was holding. The client sent its OpenSecureChannel request and never processed the response. Writes are now queued.

A synchronous gate handle held across an await. Enter() records the acquiring thread so an inline completion callback can re-enter — ChannelAsyncOperation invokes its callback both inline and detached. That record is only sound while the holder is synchronously on that thread; the token renewal path held it across an await, so a reused pool thread was recognised as the holder.

SignAsync rejected the policy that signs nothing. It validated the certificate before the algorithm, so SecurityPolicies.None — which carries no certificate — threw where the synchronous Sign returns null.

EnterAsync lost the holder when contended (found in review). The AsyncLocal recording ownership was written inside the awaiting method, and .NET restores the caller's execution context when an async method completes, so the write was discarded. The caller returned owning the semaphore while IsHeldByCurrentContext reported false — and any nested Enter() then blocked forever on a gate its own context held. Reachable remotely: HandleIncomingMessageAsync → error path → ForceChannelFault. The holder is now published from the caller's frame before the wait, and only its depth is raised in the continuation.

Queued writes lost their order (found in review). Sequence numbers are assigned under the gate, but independently queued work items reach the transport's FIFO send lock in arbitrary order, so a peer could reject a chunk with BadSequenceNumberInvalid. Writes are now appended to a chain: still off the caller's stack, but a write cannot start before its predecessor finishes.

Four more this surfaced in CI, on paths only the integration suites reach

Queuing the writes to fix the deadlock above turned out to have moved three implicit guarantees, and the gate had one more liveness bug. Each was reproduced locally against a clean baseline before it was changed.

A faulting channel's error message never reached the peer. A listener channel sends a UASC Error describing why it faulted and closes the transport as its next statement. That worked only because the write started on the caller's stack, so the bytes reached the socket first; queued, the close discarded them and the client saw BadConnectionClosed instead of the certificate status it was told to expect. Nine SecurityCertValidationTests cases assert exactly that status. The terminal error is written inline again, on a path that touches the gate only to disclaim what it inherited and reports nothing — a channel that is already faulted is owed nothing beyond its buffer.

The certificate of a rejected sender leaked. An asynchronous method cannot have out parameters, so the asymmetric read returns a record instead. That silently dropped an ownership guarantee: an out parameter reaches the caller even when the method goes on to throw, so the caller's catch disposed the sender certificate and reported it to the audit. A return value does not — nine leaked certificates, one per rejection case, which the leak detector fails the run on. The parsed certificate is now handed to the caller before anything that can reject the message, restoring both the disposal and the audit.

The gate could strand its own permit. It released only when the holder's depth returned to zero, but that depth lives in an AsyncLocal and is therefore shared with every context forked from the owner's — a timer callback whose timer was created inside the region, for instance. Such a context entering the gate raised the shared depth, so the owner's own exit saw a non-zero depth and returned without releasing, and nothing afterwards could: the nested exit is not the owner. Every later entry on that channel blocked forever. Opc.Ua.Features.Tests hung after its tests had finished, with a receive loop waiting on the gate and the server unable to stop. The owner now releases when it leaves; depth still gates re-entrancy, but liveness no longer depends on a count another context can move.

Write completion throttled the writer. Reporting a completed write sat inside the ordering chain, and the client channel implements that callback by entering the gate — so every write queued behind a gate the receive loop contends for on each incoming chunk. A session with fifty subscriptions publishing continuously had its publish requests throttled enough that the client kept topping them up past its own limit, which Subscriptions.Classic asserts against. Completion is now reported off the chain, which covers only what ordering actually requires.

Still synchronous, and why

Certificate, certificate request and revocation list signing cannot be made asynchronous at all: X509SignatureGenerator.SignData is invoked by .NET's own builders. Service faults and the Reconnect override are reached from synchronous call sites (SendServiceFault alone has eight) and are left as they are behind scoped, commented suppressions. All three are documented rather than left to be rediscovered.

#4210 — PubSub

This one produced a finding rather than the API the issue asked for, and the finding is the point:

With a standard Security Key Service the key necessarily exists in process memory. GetSecurityKeys (Part 14 §8.3.2) returns raw key bytes over the wire, so the "key never leaves the device" property #4192 achieved for client and server cannot be achieved for PubSub through the SKS pull profile. That is a property of the specification, not of this stack.

A wrapped-key envelope would change what is on the wire and break interoperability with third-party key services and publishers, so it was rejected rather than built.

What is achievable is delivered: the per-message AES-CTR and HMAC route through ISymmetricCryptoProvider, so a validated module performs them. IPubSubSecurityPolicy is not modified — new members would break every implementation of it; the provider is supplied through the policy constructor. PlatformSymmetricCryptoProvider gained AES counter mode, which the seam should have covered anyway since the algorithm enum names it.

Key lifetime is also tightened: unpacking an SKS response copied key material into intermediates that ByteString.Create then copied again, leaving plain keys in the heap for the lifetime of the process. Those are now zeroed.

Two wiring gaps this depended on, both found in review

The registrations above were inert, so this section originally claimed more than the code did:

• CryptoProviderConfiguration was applied nowhere outside tests, so AddCryptoProvider(configure) never reached the registry in a real host. The registry now applies every registered configuration when it is first resolved — which also affects Symmetric, key-derivation and RNG have no provider seam, so a validated module cannot perform every operation #4207's DI story.
• PubSubSecurityWrapperResolver selected PubSubAes256CtrPolicy.Instance, the provider-less static singleton, ignoring the provider-backed bundles registered for it. A FipsOnly deployment therefore certified while the platform did the work. The resolver now selects from the registered policies; the container and PubSubApplicationBuilder both supply theirs.

A third, smaller one: CryptoProviderBuilder.Use published a policy-scoped random source as the process-wide nonce source, so .For(purpose, policyUri).Use(hsm) redirected nonce generation for every other policy too. Only an unscoped binding does that now.

#4206 — a provider can contribute a security policy

Added in review: the policy set was fixed at compile time, so a provider could contribute key custody but not a profile. It is now table-driven and open, and the blockers #4206 listed are gone.

using IDisposable registration = SecurityPolicies.Register(
    new SecurityPolicyInfo("urn:vendor:SecurityPolicy#CustomProfile", "CustomProfile")
    {
        PlatformSupport = () => true,
        SupportedCertificateTypes = [ObjectTypeIds.RsaSha256ApplicationCertificateType],
        IsDefault = true
    });

services.AddOpcUa()
    .AddCryptoProvider(crypto => crypto
        .For(CryptoPurpose.ChannelSymmetric, "urn:vendor:SecurityPolicy#CustomProfile").Use(module))
    .AddSecurityPolicy(customPolicy);

• The reflection is gone. Four lookup tables were built by reflecting over the fields of SecurityPolicies and SecurityPolicyInfo. They are one explicit table now, which removes the last reflection in Security/Constants — so this is a trimming and Native AOT improvement as much as a feature.
• SecurityPolicyInfo is constructible from another assembly and carries the metadata the helpers need, so IsPlatformSupportedName, GetDefaultUris, MapSecurityPolicyToCertificateTypes and GetCurveFromCertificateTypeId read that table instead of each being hand-written. Adding a policy is one entry rather than five edits.
• The dead #if CURVE25519 conditional is deleted from Security/Constants.
• Registration is copy-on-write, so the read path stays lock-free. Shadowing a built-in policy requires replaceExisting: true and is reversible by disposing the registration.

RegisterLightsUpCurvePoliciesFromOutsideCore is the acceptance test the issue asked for: it registers ECC_curve25519 and ECC_curve448 from the test project and asserts they become discoverable through the public API.

Registering a policy makes it advertised and resolvable; it does not supply the cryptography behind it. For those two curve profiles the in-tree key agreement is still behind a compile symbol no project defines plus a BouncyCastle dependency, so a deployment lighting them up provides the operations through a provider. That division is the point: the policy set says what is offered, the provider says who performs it.

Removing the gate's re-entrancy

Folded in from #4242, which was merged into this branch.

ChannelGate was re-entrant, and that forced the design behind most of the defects above. A holder that awaits releases its thread, so ownership could not be tracked by thread identity — it had to live in an AsyncLocal<Holder?>. A logical context is inherited, so anything started while the gate was held inherited the right to re-enter and ran inside the guarded region alongside whatever started it, unless it opted out by hand via LeaveInheritedContext() at each of eight sites, enforced by review alone. Five of the defects listed above trace to that mechanism, including both CI hangs.

So the requirement was removed rather than the mechanism, and the AsyncLocal then deleted itself. Every path that re-entered now calls a lock-free Core method (ForceChannelFaultCore, ShutdownCore, ForceReconnectCore, CompleteConnectCore), and three regions stopped running foreign code under the lock: the RequestReceived dispatch is deferred until the gate is released, OnTransportError no longer wraps the HandleSocketError virtual, and the callback setters and EndpointDescription publish a single reference with a volatile write instead of locking — the last is load-bearing, because AsyncResultBase.OperationCompleted invokes the reverse-hello callback inline while the gate is held.

ChannelGate is now a SemaphoreSlim(1,1) behind a Releaser; Holder, the thread-identity fallback, LeaveInheritedContext, IsHeldByCurrentContext and all eight disclaimer calls are gone, with the call shape at all 32 sites unchanged. SaveIntermediateChunk, GetSavedChunks and DoMessageLimitsExceeded gained a gateHeld argument, because the client reaches them both with and without the gate and must pick the matching teardown — without it an oversized OpenSecureChannel response deadlocked the receive loop against itself.

The remaining paths were not found by reading the code, since that is what missed them originally. A temporary strict mode made every re-entrant acquisition throw with its stack, the suite was run under it until clean, and it was deleted with the re-entrancy it measured. It caught two sites review had missed: the EndpointDescription property getter taking the gate, and the RequestReceived dispatch to application code happening inside the guarded region.

Two deliberate residuals are documented for reviewers: Dispose no longer takes the gate (unavoidable — it is reached from ChannelFaulted with the gate held, where the old re-entrant acquisition excluded nothing anyway), and the deferred request dispatch builds SecureChannelContext just after gate release rather than under it.

Testing

New: the three seams and their platform implementations, facet discovery and resolution precedence, FipsOnly refusing a provider that cannot serve what it was bound to, AES counter mode (including a non-block-aligned round trip and a check that the counter carries, since one that did not would silently reuse key stream), ChannelGate (exclusion, re-entrancy across an await, re-entrancy on a reused thread, and the deadlocks above), the asynchronous channel paths, and the PubSub policy provider.

Each review finding got a test that fails without its fix:

• ContendedEntryStillRecordsTheHolderAsync — established contention deterministically, then re-entered; failed on the pre-fix gate. Removed with the re-entrancy it covered; ChannelGateTests now asserts the non-re-entrant contract instead.
• SecureClientAndTcpListenerKeepChunkOrderUnderConcurrentRequestsAsync — 60 concurrent multi-chunk SignAndEncrypt requests over a real loopback listener; failed 3 runs out of 3 with the previous dispatch, passes 3 out of 3 with the chain.
• DependencyInjectionRoutesPubSubCryptoThroughTheRegisteredProviderAsync — builds a container, registers a counting provider, wraps a message and asserts the provider actually performed the encryption and the signature. This is the assertion the PubSub claim above now rests on.
• PolicyScopedRandomBindingDoesNotEscapeItsPolicy.

Two further assertions are the ones that would catch a silent defect: a provider and the platform must produce byte-identical output — a validated module that disagreed could not interoperate — and with a software key the returned ValueTask must report IsCompletedSuccessfully, which is what makes "ordering is unchanged" checkable rather than merely asserted.

SymmetricChannelCryptoBenchmarks gains a provider-registered variant beside the existing baseline, so the cost of the indirection is measured rather than assumed.

Verified locally, every suite at or above its recorded baseline: dotnet build UA.slnx -c Release 0 warnings, 0 errors on all six target frameworks; Core 4413 (net10.0); Core.Security 617, with its certificate-leak detector clean; PubSub 1350 plus PubSub.Diagnostics 54 and PubSub.Udp 233; Features 156; Subscriptions.Classic 32; Server integration 4053; Client integration 2123; MigrationAnalyzer 151 and MigrationAnalyzer.Core 13. Zero failures in each.

Core moved from 4388 to 4381 when the gate change landed — eight re-entrancy tests were removed along with the behaviour they covered, and one deadlock regression test added — and has since grown to 4413 with the registry isolation, provider-output and security-review tests. ChannelGateTests was rewritten around the new contract — exclusion across both entry modes, an uncontended asynchronous entry not suspending, re-entry blocking by contract, and the property that used to be the hazard: work started while the gate is held is excluded without having to opt out.

Every CI failure this PR produced was reproduced locally, diagnosed against a clean origin/master baseline in a second worktree, and fixed at the source. Two hangs were found from --blame-hang-timeout dumps read with dotnet-dump. One failure that looked like a candidate was confirmed not to be: an intermittent Opc.Ua.Aot.Tests connect failure, pre-existing on origin/master (5 of 8 baseline runs failed, versus 3 of 14 here).

The publish request overshoot

Subscriptions.Classic.PublishRequestCountAsync failed on the Windows net10.0 leg with 207 outstanding publish requests against a cap of max(maxServerPublishRequest, subscriptions) = 50. It failed in 2 of 6 pipeline builds on this branch, never on master in 13 sampled builds, and never locally in 12 attempts including under deliberate CPU contention.

The mechanism is a genuine race. ClassicSubscriptionEngine.QueueBeginPublish was a check-then-act: it read GoodPublishRequestCount, compared it against GetDesiredPublishRequestCount(false), and issued a publish if it was below. It runs on every publish completion, so n completions that overlap each read the same value, each conclude they are below the cap, and each issue — overshooting by up to n per round. The read also lags: a request only becomes visible to GoodPublishRequestCount once AsyncRequestStarted has recorded it, which happens after the request has already been sent.

That code is pre-existing and was untouched by this PR. What this PR changed is how hard the race is hit: the server used to hold the channel gate across request processing, which serialised every request on a channel, so publish completions arrived one at a time. Dispatching RequestReceived outside the gate — an intended improvement, since a channel should not serialise on application request-processing time — lets them complete concurrently.

Rather than change the publish pipeline blind, the race was first made reproducible. ConcurrentPublishReEvaluationDoesNotExceedDesiredRequestCount drives 64 barrier-released completions against a mocked context whose count lags the send exactly the way the session's does. It issued 64 requests where 5 were desired — the same defect the CI leg hit, now deterministic and running in milliseconds.

The engine now tracks the requests it has in flight and reserves a slot with a compare-exchange before sending, so the decision and the send are one atomic step. The reservation is released when the request completes, when the send is declined, or when it throws. The repro test then issues at most the desired count.

StartPublishing is deliberately left uncapped. It is the recovery valve that refills a pipeline whose requests are outstanding but no longer expected to return, so gating it on the in-flight count would remove the only path out of a stalled pipeline. An earlier revision of this fix did gate it, and that is the one change here that could not be justified on the evidence — it was reverted.

The assertion was not loosened, retried away, or marked flaky: it caught a real throttling regression earlier in this PR and is worth keeping sharp.

Validated: the repro test red before the fix and green after; Subscriptions.Classic 32/32 five consecutive runs on net10.0 and once on net48; Opc.Ua.Client.Tests 2124 on net10.0 across four consecutive runs and 2127 on net48; Opc.Ua.Subscriptions.Tests 604 passed with this fix in place.

The SSH.NET advisory that turned CI red repo-wide

Partway through this work every build job began failing with NU1903: Package 'SSH.NET' 2025.1.0 has a known high severity vulnerability (GHSA-q939-rpr3-3284, <= 2025.1.0 affected, first patched 2026.0.0).

Nothing in the dependency graph changed — the advisory was published. Build 17026 failed on it where build 17000, two hours earlier on an identical graph, had passed every build job. SSH.NET is not referenced anywhere in the repository; it arrives transitively through Testcontainers.Kafka.

master landed the remediation independently while this was being investigated (a central transitive pin to 2026.0.0, which CentralPackageTransitivePinningEnabled exists for). This branch briefly carried its own identical pin, which made the merge commit hold two PackageVersion entries for SSH.NET and fail restore with NU1506. The duplicate is removed and master is merged, so the pin now comes from one place only.

The audit was not suppressed: NuGetAudit stays enabled and NU1903 stays an error. Verified after the merge — dotnet restore UA.slnx reports neither NU1903 nor NU1506, and dotnet build UA.slnx -c Release is 0 warnings, 0 errors with the audit live.

The remaining red check in build 17026 was not from this change either. aot-ubuntu-latest is the intermittent Opc.Ua.Aot.Tests failure already noted above — ReconnectSessionAsync timed out at 30s with 135 of 136 passing. It remains below the origin/master baseline rate (4 of 15 sampled here against 5 of 8 on the baseline), and the managed reconnect paths are green throughout: Opc.Ua.Client.Tests 2124 across four consecutive runs and Opc.Ua.Subscriptions.Tests 604.

Documentation

docs/CryptoProvider.md gains sections on substituting the symmetric primitives, using a key served over a network, and PubSub — including what cannot be claimed and why, the scope rule for a random-source binding, and how to supply a provider-backed policy outside the container. docs/MigrationGuide.md covers the [Obsolete] channel virtuals and DataLock, and the non-re-entrant gate's contract for channel subclasses. docs/WhatsNewIn2.0.md is updated. plans/cryptooffboard.md is deleted now that the work it planned has landed.

Note for reviewers

This touches the secure channel handshake, which is the most security-critical code in the stack. Nine distinct concurrency and lifetime defects were found and fixed in it during this work — three during development, two in review, four from CI — so ChannelGate, the write path and the certificate ownership across the new suspension points deserve the closest reading.

Five of those nine traced to the gate's AsyncLocal, which is why the re-entrancy was subsequently removed and the AsyncLocal deleted. The wrapper/Core split and the two documented residuals in that section are the parts most worth a second reading.

The #4206 work removes the last reflection from Security/Constants and rewrites the policy lookup tables, so SecurityConfiguration.SupportedSecurityPolicies and the endpoint set it feeds are worth a second look: an earlier revision of it changed that set and broke six server tests, which is now covered by SecurityConfigurationBuildsExpectedSupportedPolicySet.

Related Issues

• Fixes Security policies are fixed at compile time, so a crypto provider cannot contribute one #4206
• Fixes Symmetric, key-derivation and RNG have no provider seam, so a validated module cannot perform every operation #4207
• Fixes RSA and ECDsa are synchronous, so a network-backed crypto provider blocks a thread per operation #4208
• Fixes IPubSubSecurityPolicy takes raw key bytes, so a PubSub key cannot stay in a device #4210
• Follow-up Inject ISecurityPolicyRegistry into Session and the secure channel instead of falling back to the default singleton #4250 — this PR makes the security policy set injectable, but nothing in the stack resolves ISecurityPolicyRegistry from DI yet, so every production path still lands on the Default fallback. Inject ISecurityPolicyRegistry into Session and the secure channel instead of falling back to the default singleton #4250 tracks threading it through Session and UaSCBinaryChannel, which is what makes the injection points already added here load-bearing.

Checklist

• I have signed the CLA and read the CONTRIBUTING doc.
• I have added tests that prove my fix is effective or that my feature works and increased code coverage.
• I have added all necessary documentation.
• I have verified that my changes do not introduce (new) build or analyzer warnings.
• I ran all tests locally using the UA.slnx solution against at least .net framework and .net 10, and all passed.
• I fixed all failing and flaky tests in the CI pipelines and all CodeQL warnings.
• I have addressed all PR feedback received.

[github-actions]

Code coverage

✅ Coverage gate passed.

Check	Result	Threshold
✅ Project line rate	86.46% (216696/250640 lines)	>= 70.00%
✅ Project branch rate	76.16%	>= 60.00%
✅ Patch coverage	81.85% (1908/2331 changed lines)	>= 75.00% (> 100 changed lines)
ℹ️ Baseline delta (advisory)	+12.86 pp	73.60% recorded

Uncovered changed lines

• src/Opc.Ua.Core/Security/Crypto/CryptoCompliance.cs: 211, 212, 306, 307, 308
• src/Opc.Ua.Core/Stack/Tcp/UaSCBinaryChannel.Rsa.cs: 201, 246
• src/Opc.Ua.Server/Session/Session.cs: 742
• src/Opc.Ua.Core/Stack/Tcp/UaSCBinaryChannel.Asymmetric.cs: 628, 629, 630, 631, 632, 633, 634, 635, 636, 638, 639, 640, 641, 684, 705, 706, 708, 709, 712, 714, 716, 717, 720, 721, 723, 729, 731, 733, 735, 736, 739, 740, 742, 743, 745, 747, 752, 769, 770, 771, 772, 774, 775, 776, 777, 778, 779, 791, 805, 806, 818, 820, 821, 822, 831, 833, 843, 1337, 1341, 1364, 1366, 1367, 1370, 1371, 1372, 1373, 1374, 1375, 1376, 1378, 1379, 1380, 1381, 1382, 1383, 1384, 1385, 1386, 1531, 1533, 1534, 1535, 1538, 1572, 1573, 1574
• src/Opc.Ua.Core/Security/Crypto/CryptoProviderAuditor.cs: 210, 211, 213, 216, 217, 218, 219, 220
• src/Opc.Ua.Core/Security/Certificates/RsaUtils.cs: 362, 363, 381, 383, 384, 386, 388, 391, 392, 396, 397, 399, 400, 401, 403, 405, 406, 407, 409, 410, 411, 415, 416, 417, 418, 420, 422, 423, 424, 427, 428, 430, 434, 437
• src/Opc.Ua.Client/Session/Session.cs: 4758
• src/Opc.Ua.Core/Security/Crypto/PlatformSymmetricCryptoProvider.cs: 205, 207, 214, 249, 250, 251, 268, 269, 301, 460
• src/Opc.Ua.Core/Stack/Tcp/UaSCBinaryClientChannel.cs: 463, 572, 731, 752, 1029, 1030, 1041, 1042, 1043, 1044, 1046, 1066, 1088, 1089, 1212, 1242, 1252, 1436, 1446, 1449, 1451, 1452, 1454, 1457, 1459, 1460, 1464, 1467, 1468, 1471, 1472, 1473, 1474, 1477, 1480, 1482, 1483, 1484, 1485, 1487, 1488, 1489, 1490, 1491, 1494, 1496, 1498, 1501, 1503, 1506, 1820
• src/Opc.Ua.Core/Security/SecurityPolicies.cs: 142, 399, 401, 404, 405, 406, 407, 436, 441, 469, 470, 471, 472, 501, 502, 509, 510, 613, 614, 615, 616, 659, 667, 668, 673, 674, 680, 681, 682, 684, 685, 686, 687, 782, 906, 911, 949, 952, 957, 964, 1011, 1016, 1042, 1129, 1144, 1522
• src/Opc.Ua.PubSub/Security/Policies/PubSubAes128CtrPolicy.cs: 182, 183, 184, 200, 201, 202
• src/Opc.Ua.PubSub/Security/Policies/PubSubSecurityPolicyRegistry.cs: 94
• src/Opc.Ua.Core/Stack/Tcp/TcpReverseConnectChannel.cs: 150, 172, 218
• src/Opc.Ua.PubSub.Diagnostics/Dissection/PubSubOfflineDissector.cs: 328
• src/Opc.Ua.PubSub/Security/PubSubSecurityWrapperResolver.cs: 177
• src/Opc.Ua.Core/Security/Crypto/PlatformKeyDerivationProvider.cs: 80
• src/Opc.Ua.Core/Stack/Tcp/TcpListenerChannel.cs: 519, 665, 666, 668, 840
• src/Opc.Ua.Client/CoreClientUtils.cs: 309
• src/Opc.Ua.Core/Security/Certificates/CryptoUtils.cs: 488, 500, 501, 512, 513, 534, 536, 537, 538, 540, 549, 551, 552, 554, 592, 593, 594, 602, 603, 604, 607, 609, 612, 614, 618, 986, 987, 1098, 1099, 1100, 1101, 1102, 1103, 1104, 1105, 1187, 1188, 1189, 1190, 1191, 1192, 1193, 1194, 1196, 1197, 1258, 1259, 1260, 1261, 1262, 1263, 1264, 1265, 1345, 1346, 1347, 1348, 1349, 1350, 1351, 1352, 1354, 1355, 1667
• src/Opc.Ua.Core/Security/Crypto/OpcUaCryptoBuilderExtensions.cs: 138, 143, 172
• src/Opc.Ua.Core/Stack/Tcp/ChannelGate.cs: 184
• src/Opc.Ua.Core/Stack/Types/X509IdentityTokenHandler.cs: 245, 246, 247
• src/Opc.Ua.Core/Stack/Tcp/ChannelAsyncOperation.cs: 442, 443, 445, 446, 447, 448, 449, 450, 451, 452, 453, 454, 455, 456, 457, 458, 459, 460, 461, 462, 463, 464, 465, 466
• src/Opc.Ua.Core/Security/SecurityPolicyInfo.cs: 68
• src/Opc.Ua.Core/Stack/Tcp/UaSCBinaryChannel.cs: 557, 670, 847, 849, 851, 857, 858, 859, 860, 861, 1010, 1014, 1015, 1025, 1029, 1129, 1131, 1132
• src/Opc.Ua.PubSub/Security/Sks/InMemoryPubSubKeyServiceServer.cs: 285
• src/Opc.Ua.PubSub/Security/Policies/PubSubAes256CtrPolicy.cs: 151, 152
• src/Opc.Ua.Core/Stack/Tcp/TcpServerChannel.cs: 320, 444, 450, 451, 552, 637, 661, 763, 790, 791, 798, 936, 937, 1067, 1128, 1129, 1251, 1341, 1379, 1410
• src/Opc.Ua.Core/Security/Crypto/CryptoProviderOutput.cs: 87
• src/Opc.Ua.Core/Security/SecurityPolicyConfiguration.cs: 69
• src/Opc.Ua.Core/Stack/Tcp/UaSCBinaryChannel.Symmetric.cs: 300, 302, 305, 306, 307, 308, 309, 310, 318, 350, 352, 355, 357, 360, 375, 376, 377, 378, 379, 380
• src/Opc.Ua.Configuration/ApplicationConfigurationBuilder.cs: 1370

Coverage is above the recorded baseline - consider ratcheting coverage-thresholds.json.

_{Thresholds live in coverage-thresholds.json. Whole report before exclusions: line 85.73%, branch 75.29%.}

[codecov]

Codecov Report

❌ Patch coverage is 75.24668% with 577 lines in your changes missing coverage. Please review.
✅ Project coverage is 80.47%. Comparing base (64d2834) to head (d0bcca3).

Files with missing lines	Patch %	Lines
....Ua.Core/Stack/Tcp/UaSCBinaryChannel.Asymmetric.cs	60.40%	86 Missing and 13 partials ⚠️
...c/Opc.Ua.Core/Security/Certificates/CryptoUtils.cs	63.02%	62 Missing and 26 partials ⚠️
src/Opc.Ua.Core/Security/SecurityPolicies.cs	84.22%	46 Missing and 42 partials ⚠️
...c/Opc.Ua.Core/Stack/Tcp/UaSCBinaryClientChannel.cs	60.71%	51 Missing and 4 partials ⚠️
src/Opc.Ua.Core/Security/Certificates/RsaUtils.cs	7.69%	34 Missing and 2 partials ⚠️
src/Opc.Ua.Core/Stack/Tcp/ChannelAsyncOperation.cs	0.00%	24 Missing ⚠️
src/Opc.Ua.Core/Stack/Tcp/TcpServerChannel.cs	76.00%	20 Missing and 4 partials ⚠️
...c.Ua.Core/Stack/Tcp/UaSCBinaryChannel.Symmetric.cs	42.85%	20 Missing and 4 partials ⚠️
src/Opc.Ua.Core/Stack/Tcp/UaSCBinaryChannel.cs	73.23%	18 Missing and 1 partial ⚠️
...Security/Crypto/PlatformSymmetricCryptoProvider.cs	87.87%	10 Missing and 6 partials ⚠️
... and 27 more

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #4232      +/-   ##
==========================================
- Coverage   80.84%   80.47%   -0.38%     
==========================================
  Files        1816     1823       +7     
  Lines      249346   250640    +1294     
  Branches    43313    43501     +188     
==========================================
+ Hits       201577   201694     +117     
- Misses      32654    33801    +1147     
- Partials    15115    15145      +30     

Flag	Coverage Δ
actions	80.47% <75.24%> (-0.38%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
...lient/Identity/ClientIdentityProviderExtensions.cs	81.50% <100.00%> (ø)
.../Session/Subscription/ClassicSubscriptionEngine.cs	76.87% <100.00%> (-6.54%)	⬇️
...ore.Diagnostics/Dissection/OfflineSecureChannel.cs	93.61% <100.00%> (ø)
src/Opc.Ua.Core/Schema/ApplicationConfiguration.cs	72.89% <100.00%> (ø)
src/Opc.Ua.Core/Security/Audit.cs	66.66% <100.00%> (ø)
...ore/Security/Certificates/CertificateIdentifier.cs	59.49% <100.00%> (-0.51%)	⬇️
src/Opc.Ua.Core/Security/Certificates/Nonce.cs	76.66% <100.00%> (-0.83%)	⬇️
...ore/Security/Certificates/SecurityConfiguration.cs	76.03% <100.00%> (-1.62%)	⬇️
...pc.Ua.Core/Security/Crypto/CryptoProviderFacets.cs	100.00% <100.00%> (ø)
src/Opc.Ua.Core/Security/Crypto/CryptoPurpose.cs	90.90% <100.00%> (+0.90%)	⬆️
... and 50 more

... and 46 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Copilot]

Pull request overview

Implements the three crypto-offboarding follow-ups by adding pluggable symmetric/key-derivation/RNG facets, making key RSA/ECDsa paths awaitable (without changing default sequencing for software keys), and routing PubSub per-message crypto through the same symmetric provider seam while tightening key-material lifetime.

Changes:

• Added ISymmetricCryptoProvider, IKeyDerivationProvider, and IRandomSource facets (with platform implementations) plus resolution helpers and compliance checks for unserved operation purposes.
• Refactored UA-TCP secure channel receive/write pipeline to support await in the open/renew path via ChannelGate, async message handling, and async RSA decrypt/sign hooks (IAsyncRsaKey/IAsyncEcdsaKey).
• Updated PubSub AES-CTR policies to optionally use a resolved symmetric provider and zeroed intermediate SKS-unpacked key buffers; added extensive tests/benchmarks and docs/migration notes.

Reviewed changes

Copilot reviewed 47 out of 47 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
tests/Opc.Ua.PubSub.Tests/Security/Policies/PubSubPolicyProviderTests.cs	Adds tests proving PubSub policies route crypto through a symmetric provider and match platform output.
tests/Opc.Ua.Core.Tests/Stack/Transport/UaSCBinaryClientChannelDeterministicTests.cs	Updates deterministic client-channel tests for async incoming-message handling.
tests/Opc.Ua.Core.Tests/Stack/Transport/TcpServerChannelDeterministicTests.cs	Updates deterministic server-channel tests for async incoming-message handling.
tests/Opc.Ua.Core.Tests/Stack/Transport/TcpServerChannelBufferTests.cs	Updates buffer tests to await async chunk dispatch.
tests/Opc.Ua.Core.Tests/Stack/Tcp/ChannelGateTests.cs	Adds coverage for ChannelGate exclusion, re-entrancy, and inherited-context hazards.
tests/Opc.Ua.Core.Tests/Security/Crypto/SymmetricCryptoProviderTests.cs	Adds tests for symmetric/key-derivation/random seams, resolution rules, and byte-identical interoperability.
tests/Opc.Ua.Core.Tests/Security/Crypto/SymmetricChannelCryptoBenchmarks.cs	Adds benchmark variant measuring the provider-routed path.
tests/Opc.Ua.Aot.Tests/CryptoProviderAotTests.cs	Adds AOT/trimming coverage for facet discovery and platform facet functionality.
src/Opc.Ua.PubSub/Security/Sks/SksKeyResponse.cs	Clears intermediate plaintext key buffers after unpacking SKS responses.
src/Opc.Ua.PubSub/Security/Policies/PubSubAes256CtrPolicy.cs	Adds optional symmetric provider injection for AES-CTR/HMAC operations.
src/Opc.Ua.PubSub/Security/Policies/PubSubAes128CtrPolicy.cs	Adds optional symmetric provider injection for AES-CTR/HMAC operations.
src/Opc.Ua.PubSub/DependencyInjection/OpcUaPubSubBuilderExtensions.cs	Resolves a symmetric provider once in DI and constructs PubSub policies with it.
src/Opc.Ua.Core/Stack/Types/X509IdentityTokenHandler.cs	Switches identity-token signing to async signature creation.
src/Opc.Ua.Core/Stack/Types/UserNameIdentityTokenHandler.cs	Switches username token decryption to async decrypt.
src/Opc.Ua.Core/Stack/Types/IssuedIdentityTokenHandler.cs	Switches issued-token decryption to async decrypt.
src/Opc.Ua.Core/Stack/Tcp/UaSCBinaryClientChannel.cs	Replaces monitor locking with ChannelGate and makes handshake/open paths awaitable.
src/Opc.Ua.Core/Stack/Tcp/UaSCBinaryChannel.Symmetric.cs	Resolves/holds symmetric + key-derivation facets and routes symmetric ops through them.
src/Opc.Ua.Core/Stack/Tcp/UaSCBinaryChannel.Rsa.cs	Adds async RSA decrypt path to avoid blocking on network-backed keys.
src/Opc.Ua.Core/Stack/Tcp/UaSCBinaryChannel.cs	Introduces async receive dispatch, async message handling hooks, and queues writes to avoid gate inheritance issues; obsoletes sync overrides.
src/Opc.Ua.Core/Stack/Tcp/TcpServerChannel.cs	Makes server open response path async and replaces monitor locking with ChannelGate.
src/Opc.Ua.Core/Stack/Tcp/TcpReverseConnectChannel.cs	Routes reverse-connect receive pipeline through async chunk dispatch + ChannelGate.
src/Opc.Ua.Core/Stack/Tcp/TcpListenerChannel.cs	Replaces monitor locking with ChannelGate across listener-channel state transitions.
src/Opc.Ua.Core/Stack/Tcp/ChannelGate.cs	Adds ChannelGate (async-enterable, re-entrant) as replacement for channel monitor lock.
src/Opc.Ua.Core/Stack/Tcp/ChannelAsyncOperation.cs	Changes detached completion callback scheduling to avoid inheriting gate context.
src/Opc.Ua.Core/Stack/Tcp/AsymmetricMessage.cs	Adds async-friendly result structs replacing out parameters.
src/Opc.Ua.Core/Security/Crypto/PlatformSymmetricCryptoProvider.cs	Adds platform implementation for symmetric crypto operations (incl. AES-CTR).
src/Opc.Ua.Core/Security/Crypto/PlatformRandomSource.cs	Adds platform implementation for random source facet.
src/Opc.Ua.Core/Security/Crypto/PlatformKeyDerivationProvider.cs	Adds platform implementation for key derivation facet.
src/Opc.Ua.Core/Security/Crypto/PlatformCryptoProvider.cs	Extends platform provider to implement the new operation facets and adds KeyDerivation capability.
src/Opc.Ua.Core/Security/Crypto/ISymmetricCryptoProvider.cs	Defines the symmetric operation facet interface.
src/Opc.Ua.Core/Security/Crypto/IRandomSource.cs	Defines the RNG facet interface.
src/Opc.Ua.Core/Security/Crypto/IKeyDerivationProvider.cs	Defines the key-derivation facet interface.
src/Opc.Ua.Core/Security/Crypto/IAsyncAsymmetricKey.cs	Defines opt-in async RSA/ECDsa key facets for non-blocking network-backed operations.
src/Opc.Ua.Core/Security/Crypto/CryptoPurpose.cs	Adds CryptoPurpose.KeyDerivation.
src/Opc.Ua.Core/Security/Crypto/CryptoProviderFacets.cs	Adds facet resolution helpers that return null for platform/default fast paths.
src/Opc.Ua.Core/Security/Crypto/CryptoProviderBuilder.cs	Sets the process-wide nonce RNG when a random facet is registered.
src/Opc.Ua.Core/Security/Crypto/CryptoProviderAuditor.cs	Enhances FIPS-only compliance checks to fail closed on unserved operation purposes.
src/Opc.Ua.Core/Security/Crypto/CryptoCompliance.cs	Adds GetUnservedOperationPurposes to detect facetless bindings.
src/Opc.Ua.Core/Security/Constants/SecurityPolicies.cs	Adds async decrypt/signature creation helpers to avoid blocking for network-backed keys.
src/Opc.Ua.Core/Security/Certificates/RsaUtils.cs	Adds async RSA decrypt helper used by SecurityPolicies.DecryptAsync.
src/Opc.Ua.Core/Security/Certificates/Nonce.cs	Adds random-source pluggability and exposes static HKDF derivation helper.
plans/cryptooffboard.md	Marks #4207/#4208 done and records PubSub custody finding/approach.
docs/WhatsNewIn2.0.md	Documents new seams, awaitable asymmetric path, and PubSub implications.
docs/MigrationGuide.md	Adds migration guidance for channel subclasses/obsolete sync hooks.
docs/CryptoProvider.md	Documents symmetric facets, async key facets, and PubSub crypto limitations/approach.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.