Re: Code signing (signcode versus strong name)?

From: Hernan de Lahitte (hernan_at_lagash.com)
Date: 03/31/04 

Date: Wed, 31 Mar 2004 10:37:13 -0300

Florian,

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" <floriz@web.de> wrote in message
news:O6FQl%23vFEHA.740@tk2msftngp13.phx.gbl...
> What is the difference between the following two ways of signing
> .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

Relevant Pages

  • Re: Signing code programatically
    ... Niclas, ... When you sign a PE file (including .NET managed assemblies) the ... Authenticode signature is added the same way to the PE whether it is ...
    (microsoft.public.dotnet.security)
  • "Patching secure assemblies whose digital certificate has expired" ??
    ... which has the effect of ensuring that the set of secure assemblies have all ... been signed with our Authenticode certificate and are therefore authentic. ...
    (microsoft.public.dotnet.framework)
  • "Patching secure assemblies whose digital certificate has expired" ??
    ... which has the effect of ensuring that the set of secure assemblies have all ... been signed with our Authenticode certificate and are therefore authentic. ...
    (microsoft.public.dotnet.general)
  • Re: Authenticode signing an assembly
    ... Authenticode signatures are applied to assemblies exactly the ... the hash with the hackers own private key, ... Embed public part of certificate and encrypted hash in assembly. ...
    (microsoft.public.dotnet.security)
  • Re: Programmatically Signing DLL
    ... - use excellent CAPICOM 2.0.0.1 capability for Authenticode signatures: ... - automate usage of signcode.exe, including pswrd automation (assuming clients have ... - use cryptoAPI (which does not have direct Authenticode signature functions) ... fyi, here is a quick drag/drop utility .exe, implemented via CAPICOM and MS-JVM which is ...
    (microsoft.public.security)