Securing data to a process identity

[Steve Schuler]

Hello all -

I've been looking for a way to do this, and I'm hoping someone either can
point me at the obvious API that does this that I somehow missed after
searching long and hard, or else can comment on an idea I'll outline below
that I think would get me there.

First, here's what I'm trying to do: I want something similar to DPAPI, but
with process identity granularity. I'm going to have an administrative UI
that would take a service ID and password, call LogonUser, and then call my
encryption API to encrypt data based on something unique to the security
context created by LogonUser. Later, I want a process configured to run as
that service ID / password identity - and *only* processes running with that
identity - to be able to call a decryption API on that data. (As for why I
want this, it's to provide a "vault" to applications in a shared
environment, where I don't want to require that applications "trust" each
other. Machine-level DPAPI is inadequate for this, since any application can
decrypt another app's secrets.)

So maybe I've missed an obvious way you do this in Windows, and someone can
point me at the right API ... but if not, here's my idea:

An obvious secret associated with the process' identity is the password
hash, but how to get at it - there's no API that I can find that would let
me do that. (Of course there are hacker tools that do this using kernel mode
code, but I don't want anything so messy.) Now here's the idea: I do both
client and server sides of the NTLM challenge / response using SSPI (I have
code that does this already from something else), but I don't really do the
server side that would be generating a random challenge. Instead I feed a
constant pre-baked challenge packet to the second call to
InitializeSecurityContext, so that I get the same challenge response packet
every time, but one which still depends uniquely on the caller's security
context. That challenge response could then be used in a CryptDeriveKey call
to get the actual reversible encryption key.

I'd appreciate any comments.

Thanks,
Steve Schuler
Safeco Insurance

Please reply to the group. If you also want to send private email, I can be
reached at sjschu AT safeco DOT com

 

[Roger Abell [MVP]]

Hi Steve,

There must be part of the use case you did not outline.
Also, although it depends on the network environment where
this would be running, in general the idea of using a pre-baked
challenge is asking for someone to mount replay attack on you.

Why is some use case missing? Well, why is there this planned
code in the middle? It needs to acquire process context of the
service ID in order to encrypt at that ID all so that something can
be stored for use by other codes running as that ID. That is what
I have taken as your stated use case. So why have this planned
code in the middle? Why not just a direct DPAPI call, either to
save it or access and use what was vaulted? I mean, your apps
would need to call your planned code, to store or access, right?
So why? I mean why not just have them use DPAPI?

Roger


"Steve Schuler" <sjschu@safeco.com> wrote in message
news:eEvw3fUfIHA.288@TK2MSFTNGP02.phx.gbl...
> Hello all -
>
> I've been looking for a way to do this, and I'm hoping someone either can
> point me at the obvious API that does this that I somehow missed after
> searching long and hard, or else can comment on an idea I'll outline below
> that I think would get me there.
>
> First, here's what I'm trying to do: I want something similar to DPAPI,
> but with process identity granularity. I'm going to have an administrative
> UI that would take a service ID and password, call LogonUser, and then
> call my encryption API to encrypt data based on something unique to the
> security context created by LogonUser. Later, I want a process configured
> to run as that service ID / password identity - and *only* processes
> running with that identity - to be able to call a decryption API on that
> data. (As for why I want this, it's to provide a "vault" to applications
> in a shared environment, where I don't want to require that applications
> "trust" each other. Machine-level DPAPI is inadequate for this, since any
> application can decrypt another app's secrets.)
>
> So maybe I've missed an obvious way you do this in Windows, and someone
> can point me at the right API ... but if not, here's my idea:
>
> An obvious secret associated with the process' identity is the password
> hash, but how to get at it - there's no API that I can find that would let
> me do that. (Of course there are hacker tools that do this using kernel
> mode code, but I don't want anything so messy.) Now here's the idea: I do
> both client and server sides of the NTLM challenge / response using SSPI
> (I have code that does this already from something else), but I don't
> really do the server side that would be generating a random challenge.
> Instead I feed a constant pre-baked challenge packet to the second call to
> InitializeSecurityContext, so that I get the same challenge response
> packet every time, but one which still depends uniquely on the caller's
> security context. That challenge response could then be used in a
> CryptDeriveKey call to get the actual reversible encryption key.
>
> I'd appreciate any comments.
>
> Thanks,
> Steve Schuler
> Safeco Insurance
>
> Please reply to the group. If you also want to send private email, I can
> be
> reached at sjschu AT safeco DOT com
>
>
>