Code signing (signcode versus strong name)?
FLO
.net-applications?
1) I give the assembly a strong name.
(By specifying a key-file in the AssemblyInfo.cs-File)/using sn.exe.
2) I compile the assembly without strong name.
Afterwards I attach a signature to the binary using signcode.exe
(like it is done for COM)
Thank you
Florian Zug
Hernan de Lahitte
Both ways provide different kind of evidence (from a security policy
standpoint).
From the chapter 7 of "Improving Web Application Security: Threats and
Countermeasures" we read;
Authenticode vs. Strong Names
Authenticode and strong names provide two different ways to digitally sign
an assembly. Authenticode enables you to sign an assembly using an X.509
certificate. To do so, you use the Signcode.exe utility, which adds the
public key part of a full X.509 certificate to the assembly. This ensures
trust through certificate chains and certificate authorities. With
Authenticode (unlike strong names,) the implementation of publisher trust is
complex and involves network communication during the verification of
publisher identity.
Authenticode signatures and strong names were developed to solve separate
problems and you should not confuse them. Specifically:
a.. A strong name uniquely identifies an assembly.
b.. An Authenticode signature uniquely identifies a code publisher.
Authenticode signatures should be used for mobile code, such as controls and
executables downloaded via Internet Explorer, to provide publisher trust and
integrity.
You can configure code access security (CAS) policy using both strong names
and Authenticode signatures in order to grant permissions to specific
assemblies. However, the Publisher evidence object, obtained from an
Authenticode signature is only created by the Internet Explorer host and not
by the ASP.NET host. Therefore, on the server side, you cannot use an
Authenticode signature to identify a specific assembly (through a code
group.) Use strong names instead.
A Comparison of Strong Names and Authenticode Signatures
Feature Strong Name Authenticode
Unique identification of assembly Yes No
Unique identification of publisher Not necessarily.
Depends on assembly developer using a public key to represent the
publisher
Yes
The public key of the publisher can be revoked No Yes
Versioning Yes No
Namespace and type name uniqueness Yes No
Integrity (checks assembly has not been tampered with) Yes Yes
Evidence used as input to CAS policy Yes IE host - Yes
ASP.NET host - No
User input required for trust decision No Yes (pop-up dialog box)
If you want further info go to:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/THCMCh07.asp
--
Hernan de Lahitte
Lagash Systems S.A.
http://weblogs.asp.net/hernandl
Shadowfax Dev Team
This posting is provided "AS IS" with no warranties, and confers no rights.
"FLO" <flo...@web.de> wrote in message
news:O6FQl%23vFE...@tk2msftngp13.phx.gbl...
Michel Gallant
A strong-name is a simple assembly-embedded key with associated
hash value.
It is only known and used by .NET infrastructure to guarantee
integrity, and required before placing assembly in GAC, or
if the assembly is application-specific, checked on each loading.
---- Authenticode Signatures ----
Authenticode signatures apply to any PE file (assembly or traditional
native .exe, .dll, .cat, .vbs, .cab etc..). They are based on CMS/PKCS #7
standards and are embedded in a MS-specific way. It is possible to verify such a
signature on a .NET assembly even on a WinOS without any .NET Framework
installed!
Authenticode signatures can be verified "out of band" in any OS (Win95 - Server 2003)
and Authenticode permeates every Win OS (and will continue to do so).
Authenticode signatures tie into the trust issuance ladder associated with PKI and
certificate stores (whereas strong-name has no explicit notion of any issuance or
associated trust model of the signer).
See also excellent article:
http://msdn.microsoft.com/netframework/default.aspx?pull=/library/en-us/dnnetsec/html/strongNames.asp
- Mitch Gallant
MVP Security
www.jensign.com
"FLO" <flo...@web.de> wrote in message news:O6FQl%23vFE...@tk2msftngp13.phx.gbl...
FLO
Florian
Michael Willers
> What is the difference between the following two ways of signing
A strong name provides code integrity via public key encryption. if your
code was manipulated by someone else (e.g. with a hex editor) the clr will
detect this and will not load this assembly. So malicous code will not not
run on your system. But a strong name will not give you any information
about the publisher.
Authenticode provides code identity. Your code will be signed with a
certificate and the purpose of a certificate is to bind a public key to a
specific person or company.
So it identifies the publisher of the code.
Hope that helps
Michael
P.S.: Your name sounds very german. I wrote an article about this topic for
the next issue of the geman developer magazine dotnetpro. Let me know if you
are interested.
FLO
Now I understood the difference, but am nevertheless interested in the
article.
Still I have one (maybe easy) questions concerning this topic:
- How many keys to use for strong names?
One per application, or is it better to use one key for the whole company?
I guess one per application, except that the same .dll-binaries are used
in multiple applications.
Thank you
Florian
P.S.: Sorry for my late response... just got back from holidays.
Michel Gallant
managing the strong-name keypairs, and how big your enterprise is,
and how it is logically and development-wise structured.
Generally, I would say it is best to keep the number of strong-name
keypairs to an absolute minimum.
- Mitch Gallant
MVP Security
"FLO" <flo...@web.de> wrote in message news:OxFaPgFK...@tk2msftngp13.phx.gbl...