Re: COM Interface Security

From: Ulrich Korndoerfer (ulrich_wants_nospam_at_prosource.de)
Date: 01/20/05 

Date: Thu, 20 Jan 2005 08:01:53 +0100

Hi,

Joseph Geretz wrote:

> Hi Ulrich.
>
>> For passing keys around, I agree with you that not the key should be the
>> secret thing but the en/decription algorithm used to en/decrypt using this
>> key.
>
> Let me clarify. The algorithm I spoke of is a way to protect the secrecy of
> the key.

Me too. Lets clarify a little bit further:

You do want to de/encrypt some data lets say on disk. For this purpose
you use a dll. This dll uses Blowfish and a secret key embedded in the
dll (may be clever embedded, but it is there, even if you use a special,
homebrewn algorithm to retrieve it). Then the dll is able to do its
de/encryption work.

As the dll is a COM server with a public interface, anyone could use
this dll for de/encrypting data. For this he does not need to know the
secret key, he just has to use your dll. For this it is necessary to do
a little guess work how the objects and methods have to be served, but
it probably can be done without to much effort and, most important,
without doing reverse engineering of your dll (using a debugger eg).

You want to hinder them from using the dll this easy way, you do not
want to hinder them to do reverse engineering, as, as you admitted, then
you will have lost in any case.

So you suggested to use some authentication mechanism which prevents
spoofing and allows only an authenticated app (which is your own app) to
use the dll.

I suggested a mechanism to do this two way authentication: the dll has
to authenticate itself to the client and the client has to authenticate
him to the server.

This mechanism uses a strong and secure cipher method (ARC4). And it
uses a homebrewn algorithm to scramble a given random key a little bit
before it is used to key anything.

The only way to crack this authentication method is: the attacker must
guess which cipher is used and detect, that a homebrewn further
enhancement is done. He must know that ARC4 is used and he must know
which homebrewn algo is used. If he does not know it, he can not break
the authentication.

So now we have the same preconditions as for the dlls ciphering. For the
attacker if he knows the homeb rewn algo used for retrieving the secret
key embedded in your dll, you lost and the attacker can decipher data
without even using the dll. If the attacker knows the home brewn algo to
scramble the key used for authentication, authentication security is
lost and the attacker can use the dll to decipher data without needing
to know the secure key.

So in both cases it is necessary to hide at least the homebrewn algo. To
make attackers life a bit more harder it is also good to hide the
*information*, which encoding cipher (ARC4/Blowfish) is used.

The main problem in both cases is, that always a homebrewn algo is part
of the whole process to protect the key. If the attackers does
successfully reverse engineering this all is lost. However from the
outside without reverse engineering he can not break into anything.

  However, the security of the ultimate encryption does not depend on
> secrecy of the encryption algorithm, but rather on the secrecy of the key.

Which you keep secret using some home brewn algo.

> All industrial strength encryption algorithms are publicly disclosed
> algorithms. In fact, the integrity of these encryption algorithms are only
> tested through peer review. Thus the truly secure algorithms are those which
> are publicly disclosed and can be proven to be secure through objective,
> mathematic proofs.

Thats correct, but not the point. See above.

> So I for one, have no interest in keeping our encryption algorithm secret.
> We're using Blowfish (which is the only algorithm for which I could find a
> VB implementation).

Would be better to not shouting out loud what you use. See above.
However I could think of circumstances where you have too (marketing? ;-)

But the key? Ah, now that's a different story...
>
> (BTW, years ago I developed my own proprietary 'encryption' algorithm which
> was used successfully in an internal software application. Subsequently I
> posted a ciphertext snippet to one of the security newsgroups. It was
> cracked in about 20 minutes. It was then that I learned that encryption
> algorithms need to be *strong*, rather than secret. It's the key which needs
> to be kept secret.)

Again, thats not the point. We have to keep secret the algorithm which
retrieves the key or scrambles it. And we do better if we do not give
the *information* (which I meant with "hiding" too) which cipher is used. 

-- 
Ulrich Korndoerfer
VB tips, helpers, solutions -> http://www.proSource.de/Downloads/

Relevant Pages

  • Re: COM Interface Security
    ... This dll uses Blowfish and a secret key embedded in the ... homebrewn algorithm to retrieve it). ... I suggested a mechanism to do this two way authentication: ... The only way to crack this authentication method is: the attacker must ...
    (microsoft.public.vb.winapi)
  • Re: COM Interface Security
    ... This dll uses Blowfish and a secret key embedded in the dll ... The algorithm I spoke of is a way to protect the secrecy ... > I suggested a mechanism to do this two way authentication: ...
    (microsoft.public.vb.com)
  • Re: COM Interface Security
    ... This dll uses Blowfish and a secret key embedded in the dll ... The algorithm I spoke of is a way to protect the secrecy ... > I suggested a mechanism to do this two way authentication: ...
    (microsoft.public.vb.winapi)
  • Efficient message authentication?
    ... Is the following message authentication algorithm known? ... One would like to combine encryption and authentication, ... faces impractically difficult patent negotiations for ...
    (sci.crypt)
  • RE: Basics of Implementing a new authentication provider
    ... the the extension) to the registry value "Authentication Packages" AFTER ... I have done this test under Windows XP SP2. ... Maybe if you put your dll after msv1_0 like me it will work. ...
    (microsoft.public.platformsdk.security)