[Mono-dev] [PATCH] SecureString implementation

[Ben Maurer]

I think I am confused about the design of ProtectedMemory, can you
correct the errors I make in the following reply? Mostly this because I
am curious about the API now ;-).

On Fri, 2005-12-09 at 17:39 -0500, Sebastien Pouliot wrote:
> Hello Ben,
> 
> On Fri, 2005-12-09 at 16:28 -0500, Ben Maurer wrote:
> > Why does this need to be implemented in unmanaged code? The win32 apis
> > could be pinvoked, and we already have an AES implementation in managed
> > code. 
> 
> Oh, believe me I have a *much* higher preference to managed code (and I
> did try it) but in the end the choice wasn't about "how", it was about
> "why".
> 
> The use cases for ProtectedMemory (and SecureString is very similar) are
> very different from the "general" use cases of cryptography. I won't get
> in long (and potentially boring for some) details (there's lot of docs
> on MSDN for interested people) but PM and SS are mainly used to limit
> the window of opportunity to access some data during software execution.

The primary goal of ProtectedMemory (or SecureString) seems to be:
     1. To prevent the protected value from being exposed should it ever
        be swapped to disk (and the computer rebooted into an OS that
        could read the swap file)
     2. To reduce the window for for a process with access to the
        program's address space to view the data (what is an example of
        where somebody would have access to the programs address space
        but can't just call the DAPI code to decrypt the string? I don't
        think I understand this case)
     3. (SecureString) Allow untrusted APIs to be given a string without
        being able to read it. For example, I could give somebody a
        password for a web service and know that they'd never be able to
        get the password and send it to a place I didn't want it to go.

Right?

> There are some reasons this cannot be build on top of the managed
> implementation. The biggest one, IMHO, is that the symmetric algorithms
> in .NET have a design flaw[1]: the secret key is publicly exposed (and
> some would say it's "by design" ;-). This it's not a big deal for the
> most common usage where you already supply, hence know, the secret key.
> 
> However the lack of encapsulation of the key (like provided in
> CryptoAPI, and many other toolkits, using opaque handles) makes it
> "hard" to share the use of a common key without sharing the key itself.
> By "hard" I mean it's "too easy to share" so it destroy the real
> advantage of using PM/SS (as the window of opportunity on the secret key
> would be larger than on the protected data).

How does having encapsulated in the runtime add additional security?
Somebody who has access to reflect on private APIs (such as the secret
key for ProtectedMemory/SecureString) should be able to get this data
from the runtime just as easily (well, they might need some more hackery
as the C library obviously isn't reflectable. But it seems to be
protection by obscurity rather than real protection).

> 
> Could it be implemented differently ? Maybe.
> 
> ProtectedData is very similar but has some different rules (e.g.
> longer-term) and it's API makes it easy to use asymmetric cryptography
> (which doesn't have the design flaw [1]) so it was fully implemented in
> managed code. However a quick look at the PM API shows, without a doubt,
> that the implementation is based on a symmetric block cipher.
> 
> Could I modify the managed AES implementation to achieve this ? Probably
> for a good chunk of the current code/features. Hardly for the other
> MemoryProtectionScope options.
> 
> 
> [1] The asymmetric algorithms have the "opaque" concept (using the
> CspParameters class) which can (this is really implementation dependent)
> allow keypairs to be used without disclosing the private key (e.g. by
> refusing to export it).

How is this opacity implemented? If I have the ability to read a random
address in memory, can't I (with some level of reverse engineering) find
the shared key with no more effort than I needed to gain access to the
secure string in the first place? How is the shared key protected from
being swapped to disk?

-- Ben