Re: securing an assembly

From: SStory (TheStorys_at_TAKEOUTTHISSPAMBUSTERsofthome.net)
Date: 03/09/04


Date: Tue, 9 Mar 2004 14:14:15 -0600

But this means the anyone would have to be a rogue developer inside the
organization
who extracted the public key and made his own up right?

Because once I signed it and sent that out, signed, this couldn't happen,
right?

Thanks,

Shane

""Shawn Farkas"" <shawnfa@online.microsoft.com> wrote in message
news:IziS%23BxAEHA.604@cpmsftngxa06.phx.gbl...
> Hi Shane,
>
> The problem the article is pointing out is that a delay signed assembly
does not have a valid signature on it, so it cannot be verified.
> Because of this, on your development machines you need to turn off
verification of that assembly. Since anyone can extract a public key from a
> fully signed file, they could then create a replacement assembly that does
something bad and give it the same strong name (since only the public
> key token is part of the strong name, and they have access to that). They
don't have to get a valid signature onto this malicious assembly, since
> you've turned off verification.
>
> -Shawn
> http://blogs.msdn.com/shawnfa
>
> --
>
> This posting is provided "AS IS" with no warranties, and confers no
rights.
> Note: For the benefit of the community-at-large, all responses to this
message are best directed to the newsgroup/thread from which they
> originated.
> --------------------
> >From: "SStory" <TheStorys@TAKEOUTTHISSPAMBUSTERsofthome.net>
> >References: <EAA195F6-8FE3-42AC-8BE3-A5771C5D15DE@microsoft.com>
<O5C4x##7DHA.1052@TK2MSFTNGP12.phx.gbl> <O9FP0L
> $7DHA.2412@TK2MSFTNGP09.phx.gbl> <O7UvMgF8DHA.2300@TK2MSFTNGP10.phx.gbl>
<lejk201po941d1u9gq1ancsf9cpbq6qn9k@
> 4ax.com> <#RLDwiL8DHA.3704@tk2msftngp13.phx.gbl>
> >Subject: Re: securing an assembly
> >Date: Thu, 4 Mar 2004 13:19:26 -0600
> >Lines: 117
> >X-Priority: 3
> >X-MSMail-Priority: Normal
> >X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
> >X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
> >Message-ID: <uN9jX1hAEHA.1600@tk2msftngp13.phx.gbl>
> >Newsgroups: microsoft.public.dotnet.security
> >NNTP-Posting-Host: 0-1pool98-163.nas16.nashville1.tn.us.da.qwest.net
65.144.98.163
> >Path:
cpmsftngxa06.phx.gbl!TK2MSFTNGXA06.phx.gbl!TK2MSFTNGXA05.phx.gbl!TK2MSFTNGP0
8.phx.gbl!tk2msftngp13.phx.gbl
> >Xref: cpmsftngxa06.phx.gbl microsoft.public.dotnet.security:5247
> >X-Tomcat-NG: microsoft.public.dotnet.security
> >
> >Michel,
> >
> >in the SNing article you mention what does the following warning mean?
> >Protecting Your Development Team
> >Delay signing isn't perfect. Because your team must turn off strong name
> >verification for one or more public keys in order to test their own
> >assemblies during development, be very careful not to confer trust on an
> >assembly based solely on the presence one of these unverified strong
names.
> >Given your public key, an attacker can delay sign a malicious assembly
just
> >as easily as you can delay sign your own assemblies. And you must assume
> >that any attacker will be able to easily obtain your public key, since it
is
> >embedded as metadata in each strong-named assembly you build.
> >
> >Please tell me what the danger is in this? Is this a danger after it is
> >singed or just if it is released before being signed or what?
> >
> >Thanks,
> >
> >Shane
> >
> >
> >
> >"Michel Gallant" <neutron@NOSPAMistar.ca> wrote in message
> >news:%23RLDwiL8DHA.3704@tk2msftngp13.phx.gbl...
> >> Here is a simple walk-through for SNing an assembly and adjusting
> >> CAS for network-share deployment (similar for Internet deployment):
> >> http://www3.sympatico.ca/mitchg/dotnet/networkshare.html
> >>
> >> Also this excellent article on SNing:
> >>
>
>http://msdn.microsoft.com/security/default.aspx?pull=/library/en-us/dnnetse
c/html/strongnames.asp
> >>
> >> - Michel Gallant
> >> MVP Security
> >> JavaScienceConsulting
> >> http://pages.istar.ca/~neutron
> >>
> >> "Mary Chipman" <mchip@nomail.please> wrote in message
> >> news:lejk201po941d1u9gq1ancsf9cpbq6qn9k@4ax.com...
> >> > "Creating and Using Strong-Named Assemblies" in the help file is as
> >> > good place as any to start.
> >> >
> >> > -- Mary
> >> > MCW Technologies
> >> > http://www.mcwtech.com
> >> >
> >> > On Tue, 10 Feb 2004 22:32:19 -0600, "Joe Kaplan \(MVP - ADSI\)"
> >> > <joseph.e.kaplan@removethis.accenture.com> wrote:
> >> >
> >> > >The big decision is whether you want to do strong names or
> >authenticode. If
> >> > >you go with strong names, you first need to sign all of your
> >assemblies.
> >> > >This can be done via the AssemblyKeyName or AssemblyFile attributes
or
> >via
> >> > >the sn tool.
> >> > >
> >> > >To ensure that your assemblies are only used by code that has been
> >signed by
> >> > >one of these mechanisms, you create the appropriate permission and
> >Demand
> >> > >it. You can do this with attributes or in code with permission
objects
> >and
> >> > >the Demand method.
> >> > >
> >> > >I don't have a good sample I can point you too, but there is likely
> >someone
> >> > >else in the forum who might have one or could answer more detailed
> >questions
> >> > >if you get stuck.
> >> > >
> >> > >Joe K.
> >> > >
> >> > >"Jonas" <jonas@nospam.pl> wrote in message
> >> > >news:O9FP0L$7DHA.2412@TK2MSFTNGP09.phx.gbl...
> >> > >> Can You point us to some info on how to do this step-by-step?
> >> > >>
> >> > >> TIA
> >> > >>
> >> > >> Jonas
> >> > >>
> >> > >> "Joe Kaplan (MVP - ADSI)"
<joseph.e.kaplan@removethis.accenture.com>
> >wrote
> >> > >> in message news:O5C4x%23%237DHA.1052@TK2MSFTNGP12.phx.gbl...
> >> > >> > Signing your assemblies with a strong name key or authenticode
> >signing
> >> > >> them,
> >> > >> > along with using StrongNamePermissionAttribute or
> >> > >> > PublisherIdentityPermissionAttribute, should allow you to make
> >ensure
> >> > >that
> >> > >> > only code signed with the correct key or certificate can call
your
> >code.
> >> > >> > This is probably better than trying to implement this yourself.
> >> > >> >
> >> > >> > Joe K.
> >> > >> >
> >> > >> > "steve" <anonymous@discussions.microsoft.com> wrote in message
> >> > >> > news:EAA195F6-8FE3-42AC-8BE3-A5771C5D15DE@microsoft.com...
> >> > >> > > I have written a dll assembly which I want to make sure can
only
> >be
> >> > >> > accessed by applications written by our own company.
> >> > >> > > Are there any inbuilt mechanisms to achieve this or do I have
to
> >> > >> implement
> >> > >> > my own.
> >> > >> > >
> >> > >> > > Steve
> >> > >> >
> >> > >> >
> >> > >>
> >> > >>
> >> > >
> >> >
> >>
> >>
> >
> >
> >
>
>



Relevant Pages

  • Re: When to use Public/Private Key & when to gen new one?
    ... The key pair is uniquely bound to each other: you can't have one private key ... options for extracting the public key, but not one for 'build new public key ... I was including in assemblies whatever it had spat one ... probably keep the same snk file across various builds of an assembly, ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Protecting assemblies from being used outside a company/group/team
    ... public key and verifing "it" knows the same public key as with which it was ... Encrypt something to send the server which can decrypt with its private key. ... "Verification skipping only applies to partially (delay signed) assemblies, ...
    (microsoft.public.dotnet.security)
  • Re: Loading unsigned assembly
    ... How can the solution be to ensure that there are no StrongName skip verification entries on the ... I'm also looking for a solution to this, as it seems there has to be a way to verify an assembly is your own by more than a public key check. ... however the signature is not computed. ... > best ways to avoid this situation would be to ensure that assemblies you don't want to load do not have FullTrust (even the Everything ...
    (microsoft.public.dotnet.security)
  • Re: securing an assembly
    ... >> signed assemblies), then as soon as you release a signed version of the assembly, anyone could ... Since verification is turned off for that specific token, ... Also, since they have the correct public key token, the strong name will match what ... >>>> The problem the article is pointing out is that a delay signed assembly ...
    (microsoft.public.dotnet.security)
  • Re: securing an assembly
    ... I found SN delayed signing rather confusing at first glance. ... > signed assemblies), then as soon as you release a signed version of the assembly, anyone could ... Since verification is turned off for that specific token, ... Also, since they have the correct public key token, the strong name will match what ...
    (microsoft.public.dotnet.security)