strong key problems

[per9000]

Dear readers,

I have some problems with strong keys.

What I want to do is basically this.
A - create an application (f.x. strongHello.dll) with a strong key.
B - import the functions of this dll into a console application (f.x
StrongConsoleApp.exe) and run it if I have somehow specified the public
part of the strong key and not otherwise.

(think of it as A being me and B my users that may continue developing
my exuisite application)

My question is pretty much: How do I/my users run my strongly named
applications.

I have found some relatively nice info out on the web, but only info
that deals with
i - how to create a strong key and use it in your applications.
ii - how to create the public part of a strong key (not how another
developer can use this public part).
iii - that reverse engineering of strongly named files is still
possible
iv - any referencer to any app with strong name must also have a strong
name
What I had expected
------------------------
a) my dll-file uses a strong key
b) extract public part from this key
c) import public part in new app
d) any app referencing a strong named app must also have a strong name
(thus: create a 2nd strong key (end users key))
e) rejoyce
What I got (Long version below this line)
------------------------
(1)
I create an empty class library with the following (in MS visual c++
2005 express edition)

//ugly way of writing "hell o world!"
namespace A
{
public class B
{
public string C(int pos1, int pos2)
{
string s = "HELLOWORLD!";
s = s.Substring(0, pos1) + " " + s.Substring(pos1, pos2 - pos1) +
" " + s.Substring(pos2);
s.Insert(pos1, " ");
return s;
}
}
}

(2)
I remove the assembly info file (getting version 0.0.0.0 which is ok),
right click my project and sign with my myStrength.snk (just created
with "Long path\sn.exe" -k myStrength.snk)

(3)
Close this solution and start a new one (StrongConsoleApp) with the
following:

namespace strongHello
{
class Program
{
static void Main(string[] args)
{
A.B s = new A.B();
Console.WriteLine(s.C(4, 5));
}
}
}

to my surprise (since I have not used any key for this solution) I get

>HELL O WORLD!

I did not expect this to be possible - does the program know that I did
both of these applications?

(4)
I copy strongHello.dll and StrongConsoleApp.exe to a shared folder and
try the same. I get an exception (as expected, but not the one I had
expected)
Unhandled Exception: System.Security.SecurityException: That assembly
does not allow partially trusted callers.

I had however expected another exception - a complaint about the
application not having a strong name (This is what happened with my
real application. I was trying to reproduce that with this smaller
issue.)

(5)
I sign my exe file with the same key. On my harddrive it still works.
In the shared folder it still fails. with the same exception.

(6)
The application has security under it's properties - I set the project
to be a partial trust application. But the dll does not allow partial
trust, nor has it got a security tab under it's properties (really
confusing).

Can someone please give a helping hand?
/Per

[Marina Levit [MVP]]

Sorry, it is not clear what you are actually trying to accomplish by somehow
splitting out the key, or what it is you are trying to do, and your post is
rather long.

First off, you should only need one key. You should have 1 key for your
organization, and every assembly that is signed coming from your
organization should be signed with the same key.

Additionally, an application does not need to have a strong name, just to
use an assembly that does. That is not true vice versa. But you were saying
that in order to use the assembly with the strong name,your application
needed one too - this is not the case.

You should be able to reference your assembly that has been signed by any
application, and it should just work regardless of whether or not your
application is signed.

<pe*****@gmail.comwrote in message
news:11*********************@m73g2000cwd.googlegro ups.com...

Dear readers,

I have some problems with strong keys.

What I want to do is basically this.
A - create an application (f.x. strongHello.dll) with a strong key.
B - import the functions of this dll into a console application (f.x
StrongConsoleApp.exe) and run it if I have somehow specified the public
part of the strong key and not otherwise.

(think of it as A being me and B my users that may continue developing
my exuisite application)

My question is pretty much: How do I/my users run my strongly named
applications.

I have found some relatively nice info out on the web, but only info
that deals with
i - how to create a strong key and use it in your applications.
ii - how to create the public part of a strong key (not how another
developer can use this public part).
iii - that reverse engineering of strongly named files is still
possible
iv - any referencer to any app with strong name must also have a strong
name
What I had expected
------------------------
a) my dll-file uses a strong key
b) extract public part from this key
c) import public part in new app
d) any app referencing a strong named app must also have a strong name
(thus: create a 2nd strong key (end users key))
e) rejoyce
What I got (Long version below this line)
------------------------
(1)
I create an empty class library with the following (in MS visual c++
2005 express edition)

//ugly way of writing "hell o world!"
namespace A
{
public class B
{
public string C(int pos1, int pos2)
{
string s = "HELLOWORLD!";
s = s.Substring(0, pos1) + " " + s.Substring(pos1, pos2 - pos1) +
" " + s.Substring(pos2);
s.Insert(pos1, " ");
return s;
}
}
}

(2)
I remove the assembly info file (getting version 0.0.0.0 which is ok),
right click my project and sign with my myStrength.snk (just created
with "Long path\sn.exe" -k myStrength.snk)

(3)
Close this solution and start a new one (StrongConsoleApp) with the
following:

namespace strongHello
{
class Program
{
static void Main(string[] args)
{
A.B s = new A.B();
Console.WriteLine(s.C(4, 5));
}
}
}

to my surprise (since I have not used any key for this solution) I get

>>HELL O WORLD!

I did not expect this to be possible - does the program know that I did
both of these applications?

(4)
I copy strongHello.dll and StrongConsoleApp.exe to a shared folder and
try the same. I get an exception (as expected, but not the one I had
expected)
Unhandled Exception: System.Security.SecurityException: That assembly
does not allow partially trusted callers.

I had however expected another exception - a complaint about the
application not having a strong name (This is what happened with my
real application. I was trying to reproduce that with this smaller
issue.)

(5)
I sign my exe file with the same key. On my harddrive it still works.
In the shared folder it still fails. with the same exception.

(6)
The application has security under it's properties - I set the project
to be a partial trust application. But the dll does not allow partial
trust, nor has it got a security tab under it's properties (really
confusing).

Can someone please give a helping hand?
/Per

[per9000]

Hi Marina

Marina Levit [MVP] skrev:

Sorry, it is not clear what you are actually trying to accomplish by somehow
splitting out the key, or what it is you are trying to do, and your post is
rather long.

Sorry about the blurryness.

The goal is for others to use my dll knowing it has not been tampered
with.

As I understand it I need to sign my dll with a strong key to do this.

In order for others to know that my dll is untouched - don't they need
the public part of my key?

Also, in order for others to use a dll with a strong name, don't they
need to have their files (the exe-file in my example) signed with their
strong key?

Example:
Microsoft created a dll with helloworld(int pos1, int pos2). They sign
it with their strong key and give me the public part of it.

Now McDonalds want to use helloworld and buy the dll from Microsoft. To
be sure they have the correct dll they do a check with Microsofts
public part of the key.

But, since the dll from Microsoft has a strong name they need to have a
strong name to, so they have to use their own strong key.

Follow-up questions:
If this example is somewhat correct - how does McDonalds enter the
public part of Microsofts strong key into their exe-file?

/Per

[Marina Levit [MVP]]

I don't know how you would initially verify that the DLL came from
microsoft.

However, if initially you have a DLL that is signed by Microsoft, you can
just reference it, and use it. You don't need to do anything, just use it in
your program. If anyone tries to tamper with the software by replacing the
Microsoft DLL with something else, the runtime should detect it, because
McDonald's executable was compiled with the valid version of the DLL, and
there is metadata that allows the runtime to verify that the DLL it is
trying to use is the same valid one.

McDonalds does *not* need to sign their application just because they want
to use Microsoft's dll.

Example, you can use System.dll in any .NET application. Your .NET
application doesn't have to be signed, does it? No, it doesn't. If it did,
then you could never have an application that was not signed, since of
course all the .NET framework dlls have a strong name.

"per9000" <pe*****@gmail.comwrote in message
news:11**********************@b28g2000cwb.googlegr oups.com...

Hi Marina

Marina Levit [MVP] skrev:

>Sorry, it is not clear what you are actually trying to accomplish by
somehow
splitting out the key, or what it is you are trying to do, and your post
is
rather long.

Sorry about the blurryness.

The goal is for others to use my dll knowing it has not been tampered
with.

As I understand it I need to sign my dll with a strong key to do this.

In order for others to know that my dll is untouched - don't they need
the public part of my key?

Also, in order for others to use a dll with a strong name, don't they
need to have their files (the exe-file in my example) signed with their
strong key?

Example:
Microsoft created a dll with helloworld(int pos1, int pos2). They sign
it with their strong key and give me the public part of it.

Now McDonalds want to use helloworld and buy the dll from Microsoft. To
be sure they have the correct dll they do a check with Microsofts
public part of the key.

But, since the dll from Microsoft has a strong name they need to have a
strong name to, so they have to use their own strong key.

Follow-up questions:
If this example is somewhat correct - how does McDonalds enter the
public part of Microsofts strong key into their exe-file?

/Per

[per9000]

Ok, I see.

Then the problem I get must be something else.

I could get a project to run on my system. I copied all dll's in our
project and an exe-file that did nothing interesting (except that it
referred to another dll that starts a chain reaction of references) to
one of my colleagues system and an exception (see below) the same
occurs when I run it from a shared folder.

This worries me since this has to work for our users later on.

I was pretty sure this was due to some "strong name hell" since one of
the dll's got a strong name of historical reasons and it seems all
others had to have them.

Unhandled Exception: System.IO.FileLoadException: Could not load file
or assembly 'MyApplication, Version=0.0.0.0, Culture=neutral,
PublicKeyToken=1f42b31139aa4a50' or one of its dependencies. Failed to
grant minimum permission requests. (Exception from HRESULT: 0x80131417)
File name: 'MyApplication, Version=0.0.0.0, Culture=neutral,
PublicKeyToken=1f42b31139aa4a50' --->
System.Security.Policy.PolicyException: Required permissions cannot be
acquired.
at System.Security.SecurityManager.ResolvePolicy(Evid ence evidence,
PermissionSet reqdPset, PermissionSet optPset, PermissionSet denyPset,
PermissionSet& denied, Boolean checkExecutionPermission)
at System.Security.SecurityManager.ResolvePolicy(Evid ence evidence,
PermissionSet reqdPset, PermissionSet optPset, PermissionSet denyPset,
PermissionSet& denied, Int32& securitySpecialFlags, Boolean
checkExecutionPermission)
at MyApplication.Program.Main(String[] args)

Also, what you say seem to contradict #3 in
http://msdn.microsoft.com/library/de...mescenario.asp

Any ideas?

thank,
Per
Marina Levit [MVP] skrev:

I don't know how you would initially verify that the DLL came from
microsoft.

However, if initially you have a DLL that is signed by Microsoft, you can
just reference it, and use it. You don't need to do anything, just use it in
your program. If anyone tries to tamper with the software by replacing the
Microsoft DLL with something else, the runtime should detect it, because
McDonald's executable was compiled with the valid version of the DLL, and
there is metadata that allows the runtime to verify that the DLL it is
trying to use is the same valid one.

McDonalds does *not* need to sign their application just because they want
to use Microsoft's dll.

Example, you can use System.dll in any .NET application. Your .NET
application doesn't have to be signed, does it? No, it doesn't. If it did,
then you could never have an application that was not signed, since of
course all the .NET framework dlls have a strong name.

"per9000" <pe*****@gmail.comwrote in message
news:11**********************@b28g2000cwb.googlegr oups.com...

Hi Marina

Marina Levit [MVP] skrev:

Sorry, it is not clear what you are actually trying to accomplish by
somehow
splitting out the key, or what it is you are trying to do, and your post
is
rather long.

Sorry about the blurryness.

The goal is for others to use my dll knowing it has not been tampered
with.

As I understand it I need to sign my dll with a strong key to do this.

In order for others to know that my dll is untouched - don't they need
the public part of my key?

Also, in order for others to use a dll with a strong name, don't they
need to have their files (the exe-file in my example) signed with their
strong key?

Example:
Microsoft created a dll with helloworld(int pos1, int pos2). They sign
it with their strong key and give me the public part of it.

Now McDonalds want to use helloworld and buy the dll from Microsoft. To
be sure they have the correct dll they do a check with Microsofts
public part of the key.

But, since the dll from Microsoft has a strong name they need to have a
strong name to, so they have to use their own strong key.

Follow-up questions:
If this example is somewhat correct - how does McDonalds enter the
public part of Microsofts strong key into their exe-file?

/Per

[Marina Levit [MVP]]

If the program works on your machine, and not on your coworker's, then this
is an environmental issue.

Running a program from a share is not the same as running it locally from
your own computer. There are all sorts of security policies that are set up
with .NET on your machine that are designed to protect you when you run
software - especially from remote locations such as a share.

This is what you are experiencing when you running from a share, and there
are permissions issue related to the .NET framework policy.

Again, as I said, if it runs on one PC, the reason it wouldn't on another
would be related to environment/configuration issues on that particular
computer.

I am not sure why you think this error message has something to do with
strong naming?

Additionally, nothing I said contradicts #3 in that article you sent. In
fact, I think it supports it, in that I said that your application will have
metadata in it, to make sure that it can verify that the assembly it is
referencing is still the right one and not an imposter. This is exactly what
#3 is saying.

It says nothing about the application itself having to be strong named. It
just says it maintains a token about the assembly being used.

"per9000" <pe*****@gmail.comwrote in message
news:11*********************@b28g2000cwb.googlegro ups.com...

Ok, I see.

Then the problem I get must be something else.

I could get a project to run on my system. I copied all dll's in our
project and an exe-file that did nothing interesting (except that it
referred to another dll that starts a chain reaction of references) to
one of my colleagues system and an exception (see below) the same
occurs when I run it from a shared folder.

This worries me since this has to work for our users later on.

I was pretty sure this was due to some "strong name hell" since one of
the dll's got a strong name of historical reasons and it seems all
others had to have them.

Unhandled Exception: System.IO.FileLoadException: Could not load file
or assembly 'MyApplication, Version=0.0.0.0, Culture=neutral,
PublicKeyToken=1f42b31139aa4a50' or one of its dependencies. Failed to
grant minimum permission requests. (Exception from HRESULT: 0x80131417)
File name: 'MyApplication, Version=0.0.0.0, Culture=neutral,
PublicKeyToken=1f42b31139aa4a50' --->
System.Security.Policy.PolicyException: Required permissions cannot be
acquired.
at System.Security.SecurityManager.ResolvePolicy(Evid ence evidence,
PermissionSet reqdPset, PermissionSet optPset, PermissionSet denyPset,
PermissionSet& denied, Boolean checkExecutionPermission)
at System.Security.SecurityManager.ResolvePolicy(Evid ence evidence,
PermissionSet reqdPset, PermissionSet optPset, PermissionSet denyPset,
PermissionSet& denied, Int32& securitySpecialFlags, Boolean
checkExecutionPermission)
at MyApplication.Program.Main(String[] args)

Also, what you say seem to contradict #3 in
http://msdn.microsoft.com/library/de...mescenario.asp

Any ideas?

thank,
Per
Marina Levit [MVP] skrev:

>I don't know how you would initially verify that the DLL came from
microsoft.

However, if initially you have a DLL that is signed by Microsoft, you can
just reference it, and use it. You don't need to do anything, just use it
in
your program. If anyone tries to tamper with the software by replacing
the
Microsoft DLL with something else, the runtime should detect it, because
McDonald's executable was compiled with the valid version of the DLL, and
there is metadata that allows the runtime to verify that the DLL it is
trying to use is the same valid one.

McDonalds does *not* need to sign their application just because they
want
to use Microsoft's dll.

Example, you can use System.dll in any .NET application. Your .NET
application doesn't have to be signed, does it? No, it doesn't. If it
did,
then you could never have an application that was not signed, since of
course all the .NET framework dlls have a strong name.

"per9000" <pe*****@gmail.comwrote in message
news:11**********************@b28g2000cwb.googleg roups.com...

Hi Marina

Marina Levit [MVP] skrev:

Sorry, it is not clear what you are actually trying to accomplish by
somehow
splitting out the key, or what it is you are trying to do, and your
post
is
rather long.

Sorry about the blurryness.

The goal is for others to use my dll knowing it has not been tampered
with.

As I understand it I need to sign my dll with a strong key to do this.

In order for others to know that my dll is untouched - don't they need
the public part of my key?

Also, in order for others to use a dll with a strong name, don't they
need to have their files (the exe-file in my example) signed with their
strong key?

Example:
Microsoft created a dll with helloworld(int pos1, int pos2). They sign
it with their strong key and give me the public part of it.

Now McDonalds want to use helloworld and buy the dll from Microsoft. To
be sure they have the correct dll they do a check with Microsofts
public part of the key.

But, since the dll from Microsoft has a strong name they need to have a
strong name to, so they have to use their own strong key.

Follow-up questions:
If this example is somewhat correct - how does McDonalds enter the
public part of Microsofts strong key into their exe-file?

/Per

[per9000]

OMG, you're right of course, I read about public and private keys,
encryption and my brain started assuming things.

Glad I got that figured out at least :-D

The other system and this both have MS .Net Framework 1.1 and 2.0 but
the other does not have 1.1 hotfix (kb886903) and sdk (english) 1.1
that I have.

I'll install it on his system and see what happens.

Still, this irritates me. When I had installed .NET 1 on his system I
got a warning that it lacked .NET 2 but now I just got the strange
security warning (not even a warning - an exception). Also the idea of
the common language runtime that it should work everywhere (I guess I
didn't read the fine printing: assuming systems are identical).

Can this happen if you run programs on different partions of the
harddrive aswell (f.x. I could not install .NET on any other partition
than C)?

/Per

[Marina Levit [MVP]]

Good luck. I haven't had any problems running software written on one
machine, on a different one, as long as the environment/security and all
that was set up to allow the program to run.

"per9000" <pe*****@gmail.comwrote in message
news:11*********************@h48g2000cwc.googlegro ups.com...

OMG, you're right of course, I read about public and private keys,
encryption and my brain started assuming things.

Glad I got that figured out at least :-D

The other system and this both have MS .Net Framework 1.1 and 2.0 but
the other does not have 1.1 hotfix (kb886903) and sdk (english) 1.1
that I have.

I'll install it on his system and see what happens.

Still, this irritates me. When I had installed .NET 1 on his system I
got a warning that it lacked .NET 2 but now I just got the strange
security warning (not even a warning - an exception). Also the idea of
the common language runtime that it should work everywhere (I guess I
didn't read the fine printing: assuming systems are identical).

Can this happen if you run programs on different partions of the
harddrive aswell (f.x. I could not install .NET on any other partition
than C)?

/Per

[per9000]

Hi again,

I used the dependency walker on the files and it seems one of the files
were compiled in debug mode and the other system does not (and should
not if it had been a user) have the debug dll's - so now I'll recompile
in release mode and hope for the best.

So my problem had nothing to do with strong names!

Thanks for your help and hints.

/Per

Marina Levit [MVP] skrev:

Good luck. I haven't had any problems running software written on one
machine, on a different one, as long as the environment/security and all
that was set up to allow the program to run.