Re: Securing data to a process identity



CryptProtectData is good for the actual encryption - but Steve's issue is how
to get the PER PROCESS SECRET (pOptionalEntropy).

Steve,

1. It is not clear from your description what type of data protection
(encryption) you want. If the APPLICATION is calling your code (eg. your DLL)
than it's relatively simple - but I guess that you want TRANSPARENT
encryption for any (arbitrary) process without modifying that application's
code. This is actually very hard: you would need to write a File System
Filter Driver. Don't even think about starting from scratch - would be a
multi-year project in itself (and probably still misses a lot). I would
strongly recommend contacting OSR and buying their toolkit.
(http://www.osr.com/toolkits_fddk.shtml) It's not cheap, but would actually
allow you to do what you want.

One note: You MAY think that instead of a filter driver you can simply hook
into the file I/O APIs (kernel32, ntdll). That would work for many
applications - and I wrote such hook in the past (part of SSI's / Rainbow's /
SafeNet's Shell "automatic data protection" feature; also wrote a Win9x file
system filter driver for the same). However, this doesn't work for programs
using memory mapped files - and there are lots of such apps. The only way I
know to work transparently with ALL applications is using File System Filter
Driver.

2. Seems you already have a process which KNOWS the processes you start. So
here is what you would need to do: set up a communication between your
starting program and your filter driver. Whenever you start an application you
- generate some encryption key from the password
- start it with suspended mode => get process id
- pass the {process_id, key} pair to your filter driver
- maybe you also want to pass path / filename information what to encrypt
(or what NOT to encrypt like executables, dlls, parameter files - whatever)
From this point your filter driver can monitor each and every file I/O of
each process your start program REGISTERED - and ignore any other process.

It's not trivial, but certainly doable.

Laszlo Elteto
SafeNet, Inc.

"DaveMo" wrote:

On Mar 3, 8:42 am, "Steve Schuler" <sjs...@xxxxxxxxxx> wrote:
x-posted to microsoft.public.security and microsoft.public.security.crypto
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. (Weakenesses, reasons it won't work, better
approaches, etc.)

Thanks,
Steve Schuler
Safeco Insurance

Hello Steve,

CryptProtectData() should be exactly what you are looking for.

HTH,
Dave

.



Relevant Pages

  • Re: Securing data to a process principal
    ... that did the encryption. ... pOptionalEntropy (or more broadly, "secret") in the apps. ... You MAY think that instead of a filter driver you can simply ...
    (microsoft.public.platformsdk.security)
  • Re: Securing data to a process principal
    ... encryption key first time for the user - and use it later). ... secret. ... I need the decryption to ... You MAY think that instead of a filter driver you can simply ...
    (microsoft.public.platformsdk.security)
  • Re: Passwords, computer ID
    ... AD does not provide any facility to access the password data programmatically, even if reversible encryption is used. ... There is also no documentation about this particular feature works or can be accessed by applicationss that need the plaintext password. ... A client will contact the server and ask for an account password ... similar API requiring a password ...
    (microsoft.public.windows.server.security)
  • Re: How do I send an s/mime e-mail using x509v3?
    ... thrilled with their API as it doesn't really integrate with the Framework at ... a lookup to AD and some crypto API calls to determine which cert is the ... encryption cert and which one is the signing cert since the .NET ... I've searched google and found an s/mime tool made by Chilkat ...
    (microsoft.public.dotnet.security)
  • Securing data to a process identity
    ... encryption API to encrypt data based on something unique to the security ... so that I get the same challenge response packet ... to get the actual reversible encryption key. ...
    (microsoft.public.security)