none
Secure Machine Identification RRS feed

  • Question

  • Let's say you have a client/server application. You want to uniquely and securely identify that the communications in question is coming from a particualr client installation.

    To solve this, you create some kind of symmetrically encrypted signature that each machine must pass up to the server to authenticate each request. This signature includes things like MAC addresses, hard drive serials numbers, motherboard serial numbers, etc. Your mechanism is flexibly enough to handle hardware changes, etc. Basically, it's like Windows Activation.

    But how do you ensure that somebody looking at your code (through disassembly) can't figure out how these signatures are geneated/encrypted and just duplicate them on a non-authorized machine? What are the common patterns for this? Since both the client and the server must rely on a shared secret of some kind, using crytpo key containers or the DPAPI doesn't seem like an option.

    Thoughts?

    Wednesday, August 18, 2010 7:06 PM

All replies

  • I guess this is really two questions. First, how to hide a secret, and second, how to hide an algorithm.

    If I used a public/private key mechanism, at least you couldn't take an encrypted signature and decrypt it. But the real goal here is to prevent the creation of a valid encrypted signature to begin with.

    Wednesday, August 18, 2010 7:35 PM
  •  

    Hi,

     

    .NET applications are compiled to IL instructions, but IL instructions are easier to be disassembled. To protect an algorithm writing in C# (or other .NET supported languages), we may either use dotfuscator to make IL instructions hard to read, or implement the algorithm in native code (e.g. C++).


    Sincerely,
    Eric
    MSDN Subscriber Support in Forum
    If you have any feedback of our support, please contact msdnmg@microsoft.com.
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Monday, August 23, 2010 3:51 AM
  • Hi RMD,

    Are you there?


    Sincerely,
    Eric
    MSDN Subscriber Support in Forum
    If you have any feedback of our support, please contact msdnmg@microsoft.com.
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Monday, August 30, 2010 9:04 AM
  • Yes, I'm here.

    Obfuscation isn't of much use to me. What I'm interested in is a way to store a secret on a PC so that even the administrator of the machine can't access the secret. Or, at least, can't easily access that secret.

    I don't think this is possible.

    Monday, August 30, 2010 2:05 PM
  • You may want to consider an advisory case or see what your options are for support if this issue is criticle.

    Your issue falls into a category that we are not able to resolve using the forums.   Please visit

    the below link to see the various paid support options that are available to better meet your

    needs. http://support.microsoft.com/default.aspx?id=fh;en-us;offerprophone

    Friday, October 1, 2010 3:25 PM
    Moderator
  • You can solve both questions using a third part sofware like .net Reactor: http://www.eziriz.com/

    Please, take a deep look on it: it's much more than just an obfuscator.

    Otherwise, you can consider to write an ActiveX using C++ that will hold your "secret" logic. It will be more dificult do disassemble it than disaseemble an native code module.

    You can also think in a more complex routine to exchange and validate those encrypted settings at server side. Of course, you will have to force your clients to be always online, but you will be able to monitor who and where your applications are executed.

    The best option (but also the most expensive) is to use a token (hardware id). But notice that it is possible to fool it too.

    There will always be an workaround for every strategy. The question is how dificullt it can be. 

    Tuesday, October 5, 2010 3:28 PM