PR Summary

Creates a dotnet core native implementation of the CryptoUtils key exchange enabling cross-platform remote sessions to successfully serialize SecureString.

PR Context

Currently, after importing a remote session between a Windows and a Linux host (in either direction), any imported cmdlets parameterized with SecureString are broken-by-design. There is a lazily triggered operation that happens during a SecureString serialization that uses the windows native CAPI crypto functions (e.g. CryptGenKey) to do the following:

1. Generate a public/private keypair.
2. Export/import the public key.
3. Generate a symmetric session key.
4. Encrypt and exchange the session key.
5. Encrypt the SecureString for transit.

The implementation of this protocol is conditioned on the UNIX compile flag and, for non-Windows builds, it simply throws a PSCryptoException. The result is that any and all cmdlets that use a SecureString parameter are broken for cross-platform importation/invocation.

This PR fixes this problem by doing the following:

1. Extracts an interface from PSRSACryptoServiceProvider.

2. Re-names the current PSRSACryptoServiceProvider to Win32PSRSACryptoServiceProvider.

3. Implements CorePSRSACryptoServiceProvider with the same external semantics as Win32PSRSACryptoServiceProvider but uses the core-compatible AES and RSA classes to do key generation, importation, exportation, encrypt, and decrypt.

4. Uses a small set of conversions to enable CorePSRSACryptoServiceProvider to return/digest the key blob formats to/from the documented CAPI formats so as to retain compatibility with native windows systems.

5. Conditions the use of CorePSRSACryptoServiceProvider on the UNIX compile flag.

Notes

• I looked for an issue specifically for this problem and, while there are a number of closed issues relating to more general SecureString problems (having to do with the DPAPI and other things) I didn't see one directly related to this. Would be happy to tag an issue in here if I just missed it.

• This PR fixes the same issue raised with the PS team in discussion with the SkyKick team. Specifically Paul Higinbotham (@PaulHigin) (via email) and TylerLeonhardt (on his livestream).

PR Checklist

• PR has a meaningful title
  • Use the present tense and imperative mood when describing your changes
• Summarized changes
• Make sure all .h, .cpp, .cs, .ps1 and .psm1 files have the correct copyright header
• This PR is ready to merge and is not Work in Progress.
  • If the PR is work in progress, please add the prefix WIP: or [ WIP ] to the beginning of the title (the WIP bot will keep its status check at Pending while the prefix is present) and remove the prefix when the PR is ready.
• Breaking changes
  • None
  • OR
  • Experimental feature(s) needed
    • Experimental feature name(s):
• User-facing changes
  • Not Applicable
  • OR
  • Documentation needed
    • Issue filed:
• Testing - New and feature
  • N/A or can only be tested interactively
  • OR
  • Make sure you've added a new test if existing tests do not effectively test the code changed
• Tooling
  • I have considered the user experience from a tooling perspective and don't believe tooling will be impacted.
  • OR
  • I have considered the user experience from a tooling perspective and enumerated concerns in the summary. This may include:
    • Impact on PowerShell Editor Services which is used in the PowerShell extension for VSCode (which runs in a different PS Host).
    • Impact on Completions (both in the console and in editors) - one of PowerShell's most powerful features.
    • Impact on PSScriptAnalyzer (which provides linting & formatting in the editor extensions).
    • Impact on EditorSyntax (which provides syntax highlighting with in VSCode, GitHub, and many other editors).