Re: COM Interface Security
From: Joseph Geretz (jgeretz_at_nospam.com)
Date: 01/20/05
- Next message: TC: "Re: Err object being reset and returning err.number = 0"
- Previous message: smith: "Re: to Ken Halter and the other dedicated VB MVPs"
- In reply to: Ulrich Korndoerfer: "Re: COM Interface Security"
- Next in thread: Ulrich Korndoerfer: "Re: COM Interface Security"
- Reply: Ulrich Korndoerfer: "Re: COM Interface Security"
- Messages sorted by: [ date ] [ thread ]
Date: Thu, 20 Jan 2005 14:01:07 -0500
Hi Ulrich,
I think we're pretty much on the same wavelength. But I just want to go over
one detail.
> 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.
The (public) cryptography class implements Blowfish but does not have the
key embedded into it at all. The client (our application) must pass in the
proper key. So the DLL, on it's own can be used by other clients for their
own encryption purposes but cannot be used to decrypt our application data
since our proprietary key is kept secret. (It is embedded in our app and
reverse assembly could discover it, but reverse assembly would be a lot more
damaging than simply discovering the key.)
That being said, there's a need to set up a 'trust relationship' between our
cryptography DLL and our client applications to ensure that another
impersonator class is not being inserted in place of our own cryptography
class in order to discover our key. For this purpose we'd need an embedded
key in the DLL. Since the safety of the scheme ultimately rests on this key,
this key needs to be just as strong and well protected as is the encryption
key. So ultimately we're back to the same situation.
I'm thinking that perhaps our encryption class should NOT be a public
interface in a class library DLL, but should rather be shared among projects
at the source code level and compiled into whichever of our applications
need to use it. As a private class, no one would be able to access it in the
first place and our encrypted data would be protected against all but a
reverse assembly attack.
- Joe Geretz -
"Ulrich Korndoerfer" <ulrich_wants_nospam@prosource.de> wrote in message
news:41EF5761.2050901@prosource.de...
> 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/
- Next message: TC: "Re: Err object being reset and returning err.number = 0"
- Previous message: smith: "Re: to Ken Halter and the other dedicated VB MVPs"
- In reply to: Ulrich Korndoerfer: "Re: COM Interface Security"
- Next in thread: Ulrich Korndoerfer: "Re: COM Interface Security"
- Reply: Ulrich Korndoerfer: "Re: COM Interface Security"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
