[API Proposal]: Expose ProtectedMemory in ProtectedData extension

[AJH16]

Background and motivation

The protected memory extension for DPAPI offers support for SAME PROCESS encryption that is not available on ProtectData. Previously this had been brought up, but at the time there was no implementations within dotnet for the interop. Support for SecureString included the necessary interop for calling ProtectedMemory from Crypt32 so I don't see why it wouldn't make sense to expose since ProtectedData is already being exposed in the System.Security.Cryptography.ProtectedData extension.

API Proposal

namespace System.Security.Cryptography.ProtectedData
{
    public class ProtectedMemory
    {
    }
}

API Usage

Usage would match current ProtectedMemory

Alternative Designs

No response

Risks

No response

[ghost]

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

Issue Details

---

Background and motivation

The protected memory extension for DPAPI offers support for SAME PROCESS encryption that is not available on ProtectData. Previously this had been brought up, but at the time there was no implementations within dotnet for the interop. Support for SecureString included the necessary interop for calling ProtectedMemory from Crypt32 so I don't see why it wouldn't make sense to expose since ProtectedData is already being exposed in the System.Security.Cryptography.ProtectedData extension.

API Proposal

namespace System.Security.Cryptography.ProtectedData
{
    public class ProtectedMemory
    {
    }
}

API Usage

Usage would match current ProtectedMemory

Alternative Designs

No response

Risks

No response

Author:	AJH16
Assignees:	-
Labels:	api-suggestion, area-System.Security, untriaged
Milestone:	-

[AJH16]

Never mind. I found the reasoning a few links down on another issue. I don't really agree with it as a best effort is better than nothing and it's mostly there already.

[AJH16]

Actually, I'll reopen this to see if the thinking has changed. I noticed upon further reading that it appears that the reasoning pre-dated the inclusion of SecureString, so perhaps the reasoning has changed now. If not, feel free to re-close, but I would argue that there is still value in being able to access the SameProcess encryption for making a best effort even if it isn't 100%.

[teo-tsirpanis]

What prevents you from importing and using CryptProtectMemory yourself? It's a pretty simple API (no need to open handles to providers or anything like that) and since it's Windows-only exposing it is already questionable.

I am also afraid that people will misuse this API to obtain a false sense of security. SecureString already does that which is the reason it is being obsoleted. And it's not easy (if possible) to correctly use them (both SecureString and your proposal); data will still be in plaintext in memory at some point in time.

[bartonjs]

I appreciate the request from the "I want this, so others probably do, too, and maybe the thinking has changed" perspective, but, unfortunately, there's still no interest to include this in the product.

• It's a Windows-only API, and we don't like adding more single-OS API unless there's a good reason.
• We don't think CryptProtectMemory provides a lot of value.
  • It's even (sort of) remarked as having limited value: "Using CryptProtectMemory and CryptUnprotectMemory for password encryption is not secure because the data exists as plaintext in memory before it is encrypted and at any time the caller decrypts it for use."
• It's not that hard to P/Invoke, so we're not saving anyone a whole lot of time.

[AJH16]

Fair enough.  I guess the part I don't understand is the inconsistency.  Some things like SecureString and AspNetCore's Secret are implemented and actually under the hood ProtectMemory is exposed and wrapped internally.  I get why it's not a main part of core but don't understand why it isn't exposed in an extension when it's otherwise exposed but with extra overhead on it.On Jan 10, 2022 5:33 PM, Jeremy Barton ***@***.***> wrote: I appreciate the request from the "I want this, so others probably do, too, and maybe the thinking has changed" perspective, but, unfortunately, there's still no interest to include this in the product. It's a Windows-only API, and we don't like adding more single-OS API unless there's a good reason.We don't think CryptProtectMemory provides a lot of value. It's even (sort of) remarked as having limited value: "Using CryptProtectMemory and CryptUnprotectMemory for password encryption is not secure because the data exists as plaintext in memory before it is encrypted and at any time the caller decrypts it for use." It's not that hard to P/Invoke, so we're not saving anyone a whole lot of time. —Reply to this email directly, view it on GitHub, or unsubscribe.Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you modified the open/close state.Message ID: ***@***.***>

[AJH16]

And yes, data is exposed at times, but the smaller we can make the window the better.  I certainly understand the false sense of security concern, but don't really know that not providing any mitigation is a good solution to worry that someone might do something wrong.  My experience, they'll just do it even more wrong.On Jan 10, 2022 5:19 PM, Theodore Tsirpanis ***@***.***> wrote: What prevents you from importing and using CryptProtectMemory yourself? It's a pretty simple API (no need to open handles to providers or anything like that) and since it's Windows-only exposing it is already questionable. I am also afraid that people will misuse this API to obtain a false sense of security. SecureString already does that which is the reason it is being obsoleted. And it's not easy (if possible) to correctly use them (both SecureString and your proposal); data will still be in plaintext in memory at some point in time. —Reply to this email directly, view it on GitHub, or unsubscribe.Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you modified the open/close state.Message ID: ***@***.***>

[bartonjs]

... Some things like SecureString ... are implemented and actually under the hood ProtectMemory is exposed and wrapped internally.

SecureString is on the path to deprecation (which is harder than we originally thought). The stance of .NET Security is that it provides effectively no value and therefore no one should ever use it... but it got included in .NET Core / .NET5+ because of the .NET Standard 2.0 effort. It'll keep doing what it does right up until we replace its implementation with throw new PlatformNotSupportedException() (assuming we ever get the OK to do that).