[Mono-dev] [PATCH] SecureString implementation

[Sebastien Pouliot]

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.

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).

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).

> Your code mentioned "ProtectedMemory is in System.Security.dll -
> move this into the runtime/icall". If that is the only reason,

No it's not - it's a minor nuisance (because I didn't found any clue as
to why that change was made) but a separate issue.

>  there are
> workarounds we could use (reflection to acquire a delegate, implement it
> in mscorlib and use the internals visible to stuff).

Well I know that ;-) Security is probably the most shared stuff Mono
has. We're already sharing a lot of code between corlib/Mono.Security
(e.g. X.509 stuff) and System/Mono.Security (e.g. SSL and more x.509
stuff).
-- 
Sebastien Pouliot
email: sebastien at ximian.com
blog: http://pages.infinit.net/ctech/