So if a client component could be signed by your private key, through say a delayed signing service would that not be a method of controlling access to a limited access component as was originally questioned?
Ian said the following: In any case that's probably more trouble than you want to go to. Presumably you plan to ship your users a copy of the code. It's hard for you to make it impossible for them to use without your consent simply because they can easily run your component through ILDASM, modify it by removing any checks for permission, and then run it through ILASM... My second question is: If you do as Ian said to a strong named component will it still be able to run? -----Original Message----- From: Moderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED]] On Behalf Of Richard Blewett Sent: Thursday, June 27, 2002 9:54 AM To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] protect component/library Because, assuming you don't write the client, the client developer would need access to your private key Richard Blewett DevelopMentor -----Original Message----- From: Moderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED]]On Behalf Of Howard Dierking Sent: 27 June 2002 16:17 To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] protect component/library why don't you just strong name your assemblies with the same key pair, and then use the Strong NameIdentityPermissionAttribute class to demand that any calling assemblies must be compiled with that same key pair? _howard -----Original Message----- From: Ian Griffiths [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 26, 2002 5:26 PM To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] protect component/library This is a hard problem to solve. The only reasonably comprehensive solution is to host the library on a server that you control and only let people call into it remotely, and use some kind of authentication mechanism to make sure that the requests are coming from authorized users. Even that doesn't help you if someone's credentials are compromised... In any case that's probably more trouble than you want to go to. Presumably you plan to ship your users a copy of the code. It's hard for you to make it impossible for them to use without your consent simply because they can easily run your component through ILDASM, modify it by removing any checks for permission, and then run it through ILASM... So if you're not prepared to host the code on a secure server, the best you can do is to foil people who can't be bothered to go through such reverse engineering. There are several approaches to solving this problem, all of them ultimately flawed, but here you go anyway: The simplest approach is to require some kind of 'unlock' where the caller passes in some means of identifying themselves as a valid user. This might be as simple as a string constant (say, some random-looking garbage) that must be passed to a static Unlock method. You would have some static bool which is initially false, but set to true when the right key is passed in. The rest of your component simple checks to make sure the bool is true before doing anything. (You have to write this code yourself.) So something like this: public class KeyManager { private bool unlocked = false; internal bool Unlocked { get { return unlocked; } public bool Unlock(string key) { unlocked = key == "thesecret"; } } ... public class SomethingInYourComponent { public SomethingInYourComponent () { if (!KeyManager.Unlocked) throw new UnlicensedException(); } } etc... This is pretty much how LeadTools (a widely-used set of imaging components) works - the keys are the same for all users, so once the key becomes public knowledge everyone can use your component. And even for a classic Win32 component (and Win32 components are allegedly difficult to reverse engineer) it is about half an hour's work to recover the key from components that use such a technique. Despite this fact, LeadTools still seem to be in business. A slight step up on this is where you don't have a single key. You have some key that has the identity of the licensed user embedded in it. The key should be hard to fake, which would typically mean signing it - your organization would generate a key and sign it with the private key and then send it out to the authorized client. (This means that your component doesn't need to contain the private key, just the public key.) This is just as easy to crack if your cracker has access to a working client binary, but it does at least mean that if a key is leaked out to the internet, or appears in an unauthorised product you have some tracability. (I.e. you will be able to find out which client's key was leaked.) You could get a little more paranoid and require that the caller of your unlock function be an assembly signed with a particular public key. (So when the user registers, they will have to tell you what public key they will be using to sign the assembly that will be calling your unlock function. You could then embed, say, a hash of this key (or even the whole key) in the unlocking key you generate, sign, and send back to them.) You can then use the stack walking methods supplied by the CLR to check that the assembly that is unlocking your component really is the authorised one. This means that even if a cracker extracts the key from some authorised application and attempts to use it in their own program, the Unlock will fail because they are passing in the key from some other assembly. But I can think of two attacks against this: (1) the cracker can almost certainly use reflection to load the assembly in question and then invoke the method that unlocks your component. (It would be possible to write the client assembly in such a way as to make this difficult, but it's hard to force clients to adhere to that.) (2) the ILDASM/remove checks/ILASM round trip will still defeat this. It is possible to make your solutions more complex than this, but they all ultimately fall foul of the ILDASM/ILASM round trip. (Of course they won't be able to resign your component after building it, but they probably won't care...) You can use the LicenseProviderAttribute and related types to mark your component as requiring a license. As I understand it this is more or less the simplest approach described above, so it isn't exactly secure. But it's the standard way of doing things if you are writing a control or any other component designed to be dropped onto a form in VS.NET. -- Ian Griffiths DevelopMentor ----- Original Message ----- From: "Agus Kurniawan" <[EMAIL PROTECTED]> > I have made a component/library using C#. I want to protect > my component/library so people can't use my component > without my permission. does anyone know how to protect > component/library ? or any idea ? You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
