Hi, can I configure/program my vb.net exe/dll to trust on only a particular
Certification Authority (CA)? For example, I would create a new CA, it would
certainly those dlls that I created. Then, my exe would trust only this CA,
thus only those dlls that I created.

What I want to do is to prevent someone else of creating new dlls without my
knowledge, and runs it with my program. If my program can trust the trusted
CA configured at IE, then they can just create their own CA and trust their
own dll, and cause my program to trust them too, right?

I don't think I can just simply use strong name as my program loads these
dlls using reflection, rather than direct referencing them.

Or, is there any other way that I can achieve my objective?
I have look at other security topics including code access security, but I
don't understand them, and I don't know which one can actually help me solve
my issue.

Thanks in advance
Eugene

Yes, but you can't make the CLR trust only your CA.


What you actually want is for the CLR to access only your CA for certificate
verification when your assemblies are loaded, and this is not possible
without modifying the CLR itself.


You can't.  If they have physical control over the deployment, they can
modify your DLLs as well as swapping in entirely new DLLs.  There is nothing
you can do to completely prevent this, although obfuscation can be used to
make this sort of thing more difficult.


Strong name verifications will only protect against spoofing attempts by
partially trusted code.  They are useful, but not against the type of
in-situ assembly swapping that you envisage.

BTW, if you know the identity of your assemblies, why are you loading them
via reflection?  Is this a plug-in scenario and, if so, are you attempting
to limit plugins that can be loaded to only those signed with a certificate
from your CA?


Obfuscation is probably worth considering.  Also, if you're loading plug-in
assemblies, then you can control criteria for the issuing CA for an
assembly's signature, but this won't be particularly useful unless you make
it difficult to modify the code that verifies the CA identity.

Thanks, please see my follow up question below.

   [E] What is the difference between my program trusting it, and CLR
trusting it?
   [E] My own program would load the dll using reflection.
Show quoteHide quote   [E] Yes, mine is a plug-in scenario, I wouldn't know the exact identity
until runtime. So, I would want to limit plugins that my program would load;
how should I do this?
   [E] Consider we can obfuscate the code, which makes it harder to modify
the code; how can i "can control criteria for the issuing CA for an
assembly's signature" ? Thanks, I don't have much knowledge or experience on
this, I would need a clearer description and help. Thanks again.
Show quoteHide quote

Show quote Hide quote If you want to prevent the CLR from loading an assembly based on the CA that
issued its authenticode signing certificate, you would need to modify the
CLR's behaviour in a way that is not possible without hacking the CLR.
However, you can certainly add a CA verification to your own code that loads
your plug-in assemblies.

The easiest approach would probably involve simply checking the issuing CA
for the assembly signing certificate.  For example, if the CA name is enough
for you, something like this should do the trick:

private bool CheckCA(Assembly assembly)
{
      bool retVal = false;

      Publisher publisher = this.GetPublisher(assembly);
      if (publisher != null)
      {
            retVal = (publisher.Certificate.Issuer == "<your CA>");
      }

      return retVal;
}

private Publisher GetPublisher(Assembly assembly)
{
      IEnumerator evidenceEnumerator = assembly.Evidence.GetEnumerator();
      while (evidenceEnumerator.MoveNext())
      {
            Publisher publisherEvidence = evidenceEnumerator.Current as
Publisher;
            if (publisherEvidence != null) return publisherEvidence;
      }

      return null;
}

In the above approach, you don't need to check if the assembly's
authenticode signature is valid since publisher evidence is not issued by
the CLR for an assembly with an invalid signature.


If you don't obfuscate the code that performs the CA verification, it would
be trivial to modify your application to eliminate or modify the
verification.  Obfuscation just makes it more difficult to find the code
that performs the verification then figure out exactly what it is doing.

At What Point Does the Security Begin?
Need advise...
Programmatically Install Certificate into Windows Certificate Store
Help : Access denied ???
Kerberos and forms authentication
Bad Data with DES Decryption
Loading permission sets
Active Directory and ASP.NET 2.0
permission for socket access
IDentifiy user acl on a folder ????