Re: embedded keys - there has to be a less vulnerable approach

From: Andrew Mayo (ajmayo_at_my-deja.com)
Date: 06/26/03 

Date: 26 Jun 2003 02:01:02 -0700

vanepp@sfu.ca (Peter Van Epp) wrote in message news:<bdcsli$8u6$1@morgoth.sfu.ca>...

> What you want to look at is Kerberos.[snip]

An excellent thought. However, on the way home last night an
interesting idea occurred to me which is quite simple to implement and
appears to be reasonably secure.

You create a DLL (which could be a COM object or a standard DLL) and
place your encryption key within the DLL, scattered to resist casual
attack (for simplicity here I'll assume symmetrical encryption).

You then create the executable image which is defined to be the
authorised user of that DLL. Once the image has been created, an
encrypted MD5 hash is written to a reserved area within the image.

The hash represents the image signature, and the encryption key for
this is NOT the same as the main encryption key buried inside the DLL.
(you could create a second DLL with this special key embedded in it,
and make sure this DLL is only available to certain employees).

This second encryption/decryption key is also embedded into the main
DLL that you are going to distribute.

When the application is run and the DLL is called, it then computes
the MD5 hash of its caller - it should be possible to get a pointer to
the caller's code space, I would think - and then encrypts it and
checks it against the encrypted MD5 hash stored in the calling
executable (this will of course all have been loaded into the code
space of the executable)

If they do not match, the calling program is not a valid client of the
DLL.

This is kind of similar to the idea of signed code that won't be run
if the signature isn't valid, except backwards; the DLL checks the
signature of its caller instead.

This approach seems to be fairly resistant to attack; anyone trying to
use the DLL in their own code will be unable to satisfy the signature
check, nor would it be possible to modify the authorised client
executable in order to subvert it, since this would also change the
signature.

Since the DLL itself embeds the MD5 hash encryption key but does not
directly expose the result of the encryption, it cannot be used to
compute a new secure hash directly, except possibly through a fair bit
of complex debugging.

Relevant Pages

  • Re: Embed username/password/etc. in exe at install time.
    ... Write a small native DLL which will generate the encryption key based ... Because you don't want the passwords to be in plain text (so others ... obfuscation is a cat and mouse game. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Identifying parameter(s) on Functions in unmanaged DLLs
    ... P/Invoke declaration in your program? ... Windows API function, you can look in the documentation for the signature, ... > unmanaged DLL, ... > public static extern int MsgBox(PARMETER??? ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Accessing Delphi DLLs
    ... Both the calling app and DLL have myUnit in their uses clause. ... The notation you wrote above tries to make the function "acquire" its signature from a function-pointer type, but that doesn't work because, as you've noted, that's not really a function declaration. ... AddNumbersSignature = AddNumbers; ...
    (alt.comp.lang.borland-delphi)
  • Re: SafeArrayTypeMismatchException - .NET GURUS PLEASE HELP
    ... There is a function in one of my dlls whose signature is as follows: ... The above dll was written in VC++ 6.0. ... Declare Function my_function Lib "tcvbadm.dll" (ByVal X As Integer, ... As Integer, ByVal Z As String, AAs String, AAs Integer) As ...
    (microsoft.public.dotnet.languages.vb)
  • Re: exporting classes from DLL using def file and NONAME
    ... dumpbin on the generated DLL. ... Actually, VC++ name decoration has been very stable since V1.0, ... signature does not change - EVEN if the signature of other methods of ... the class interface ...
    (microsoft.public.vc.language)