Re: COM Interface Security

From: Joseph Geretz (jgeretz_at_nospam.com)
Date: 01/20/05 

Date: Wed, 19 Jan 2005 19:05:10 -0500

Hi Klaus,

> Since your interface is public and the progid
> is well-known, it's probably not difficult to
> create a stub that looks like your encryption
> DLL and offer it up to the client making the call.

Yes, I guess this is the greatest danger, practically speaking. I suppose
the best way around this is to encode an authentication key algorithm (I
don't like hardcoding the key as a literal - too easy to snoop) into any
critical public classes and into our own clients. When instantiating a
secured class, the client should first perform a verification call by asking
the class to provide the verification key. If the class cannot deliver the
correct key, then it's bogus. This would stop impersonation, as far as our
own software is concerned, but would still allow other clients to use the
class.

Where it is undesirable to allow other clients to use our public classes,
then we'll need to implement a bi-directional handshake. That is our own
software instantiates the class, passes in a 'public key' and then expects
the class to return an encrypted value which matches its own internal
private key. This would allow us to develop our software in a modular manner
but would prevent other developers from making use of our own proprietary
classes.

How does that sound? Anyone done anything similar?

Thanks,

- Joe Geretz -

"Klaus H. Probst" <usenet001@simulplex.net> wrote in message
news:esJf1Nf$EHA.3824@TK2MSFTNGP10.phx.gbl...
> Joseph,
>
> Are you using COM+? If you are, you can set the call authentication level
> for calls to the COM+ application to "packet privacy" and that will
> encrypt
> the wire protocol used by the marshaler.
>
> If you're not using COM+ and the call is local (ie, not over RPC or a
> pipe)
> then I don't think you need to worry about interception very much - I'd
> worry about spoofing instead. Since your interface is public and the
> progid
> is well-known, it's probably not difficult to create a stub that looks
> like
> your encryption DLL and offer it up to the client making the call.
>
> I've never seen something that intercepts straight COM calls, but I assume
> it's possible given that the PSDK ships (or used to) with an app that will
> hook standard API calls (depends.exe does something similar). It's
> probably
> not trivial, but I doubt it's impossible.
>
>
> --
> Klaus H. Probst, MVP
> http://www.simulplex.net/
>
>
> "Joseph Geretz" <jgeretz@nospam.com> wrote in message
> news:u%23u4PiZ$EHA.3372@TK2MSFTNGP10.phx.gbl...
>> How easy or difficult is it to intercept data values passing between a
>> client and server via a public COM interface? I've built an encryption
>> component (using the VB Blowfish sample) as a public class in our utility
>> library. As with all encryption, the secrecy of the key must be
>> protected.
>> The key is generated dynamically at run time via an internal algorithm.
>> It
>> would take reverse assembly to discover the key. I'm not worried about
>> reverse assembly. If someone can reverse-assemble our code then the game
> is
>> over in any case.
>>
>> I am wondering though about how we submit our private key when we first
>> instantiate and initialize the cryptor class. (Anyone can instantiate
>> this
>> class, but unless they know the key, they won't be able to decrypt our
>> protected ciphertext.) Can information passing through a COM interface be
>> easily intercepted or would it take a skill at the level of
> reverse-assembly
>> in order to do this?
>>
>> Thanks for your advice.
>>
>> Joseph Geretz
>>
>>
>
>

Relevant Pages

  • Re: COM Interface Security
    ... > DLL and offer it up to the client making the call. ... > then I don't think you need to worry about interception very much - I'd ... > your encryption DLL and offer it up to the client making the call. ...
    (microsoft.public.vb.com)
  • RE: Cannot decrypt files encrypted using Crypto API on a different
    ... previous message which uses the recipien't public key.) ... KEK (key encryption key) to protect the session key. ... embedded into your client app and server code). ... but what is the point to encrypt the data if ANYBODY can decrypt it (since ...
    (microsoft.public.platformsdk.security)
  • Re: username and Password sent as clear text strings
    ... encryption of the traffic. ... SSL is used. ... client, it would seem like too much hassle for a low possibility hack. ... This is how all web applications on the planet work today by design. ...
    (Pen-Test)
  • Re: username and Password sent as clear text strings
    ... encryption of the traffic. ... SSL is used. ... client, it would seem like too much hassle for a low possibility hack. ... This is how all web applications on the planet work today by design. ...
    (Pen-Test)
  • Re: XP wireless questions ...setting encryption
    ... I never use the Linksys software for drivers. ... 802.1x authentication is only used with WPA encryption. ... wireless network. ... The manufacturers client program ...
    (alt.internet.wireless)
Loading