Re: securing an assembly

From: Michel Gallant (neutron_at_NOSPAMistar.ca)
Date: 03/16/04 

Date: Mon, 15 Mar 2004 21:05:20 -0500

And *Michel* agrees with what "Michael" is saying :-)

Imagine if your banking card was not protected with any password, so someone stealing your
card implied instant access to your bank account. Imagine how closely you would then guard
it!

See also the good discussion here:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/THCMCh07.asp
under section "Key Maintenance":
The second bullet in that section should probably read:
 "Protect exported (RSA) private keys and also keypairs generated with .NET snk.exe" :-)

Cheers,
 - Mitch
    "Raise the entropy!"

""Shawn Farkas"" <shawnfa@online.microsoft.com> wrote in message
news:sCQSxjvCEHA.2300@cpmsftngxa06.phx.gbl...
> Michael's not saying that the key shouldn't be stored on the disk, rather he's saying that sn
should encrypt the generated key with some sort of
> password. Right now, if I have your .snk file, I can sign with that signature, no questions asked.
Michael's pointing out that posession of hte .snk file
> should not necessarially imply the right to sign with that key.
>
> -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> <uN9jX1hAEHA.1600@tk2msftngp13.phx.gbl>
<IziS#BxAEHA.604
> @cpmsftngxa06.phx.gbl> <uSChTLhBEHA.464@TK2MSFTNGP11.phx.gbl>
<rUUsIGtBEHA.3552@cpmsftngxa06.phx.gbl> <uusM9PtBEHA.1600
> @tk2msftngp13.phx.gbl>
> >Subject: Re: securing an assembly
> >Date: Mon, 15 Mar 2004 16:36:06 -0600
> >Lines: 325
> >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: <#bRij2tCEHA.688@tk2msftngp13.phx.gbl>
> >Newsgroups: microsoft.public.dotnet.security
> >NNTP-Posting-Host: 0-1pool98-127.nas16.nashville1.tn.us.da.qwest.net 65.144.98.127
> >Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!tk2msftngp13.phx.gbl
> >Xref: cpmsftngxa06.phx.gbl microsoft.public.dotnet.security:5383
> >X-Tomcat-NG: microsoft.public.dotnet.security
> >
> >Michel,
> >
> >Are you just saying that the public/private key should be guarded somewhere
> >off the hard disk?
> >
> >I think that is what you mean.
> >
> >Even so as undeleted files are recoverable, this doesn't solve it either
> >100%.
> >
> >Maybe there are no 100% solutions.
> >
> >Someone suggested putting this file on a smartcard and keeping that safe. I
> >don't know.
> >
> >Just my thoughts.
> >
> >Shane
> >
> >"Michel Gallant" <neutron@NOSPAMistar.ca> wrote in message
> >news:uusM9PtBEHA.1600@tk2msftngp13.phx.gbl...
> >> Shawn,
> >> I think that Microsoft has to be very careful to not introduce
> >infrastructure (like delayed signing)
> >> which can itself very easily lead to incorrect and insecure use.
> >> I found SN delayed signing rather confusing at first glance.
> >>
> >> Actually imo a bigger vulnerability is the fact that any keypairs created
> >by sn -k are
> >> cleartext PRIVATEKEYBLOBS (as I have posted many times :-)
> >>
> >> I suspect most teams don't really practice good security .. so BY DEFAULT
> >why shouldn't
> >> sn.exe generate a pswd-protected keypair file?
> >>
> >> Regards,
> >> - Mitch Gallant
> >> MVP Security
> >> www.jensign.com
> >>
> >> ""Shawn Farkas"" <shawnfa@online.microsoft.com> wrote in message
> >> news:rUUsIGtBEHA.3552@cpmsftngxa06.phx.gbl...
> >> > No, if you've set up your development machines to not verify assemblies
> >signed with that key
> >> (which you have to do in order to work with delay
> >> > signed assemblies), then as soon as you release a signed version of the
> >assembly, anyone could
> >> extract the public key token, and create a new
> >> > assembly that has that token. Since verification is turned off for that
> >specific token, the
> >> malicious person could do whatever they want in their
> >> > assembly. Also, since they have the correct public key token, the
> >strong name will match what
> >> you're expecting. The only obstical remains that
> >> > they must find a way to get this modified assembly downloaded onto a
> >machine where someone has
> >> turned off verification for the token.
> >> >
> >> > -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>
> ><uN9jX1hAEHA.1600@tk2msftngp13.phx.gbl>
> >> <IziS#BxAEHA.604
> >> > @cpmsftngxa06.phx.gbl>
> >> > >Subject: Re: securing an assembly
> >> > >Date: Tue, 9 Mar 2004 14:14:15 -0600
> >> > >Lines: 192
> >> > >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: <uSChTLhBEHA.464@TK2MSFTNGP11.phx.gbl>
> >> > >Newsgroups: microsoft.public.dotnet.security
> >> > >NNTP-Posting-Host: 0-1pool140-179.nas12.nashville1.tn.us.da.qwest.net
> >65.135.140.179
> >> > >Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP11.phx.gbl
> >> > >Xref: cpmsftngxa06.phx.gbl microsoft.public.dotnet.security:5331
> >> > >X-Tomcat-NG: microsoft.public.dotnet.security
> >> > >
> >> > >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!TK2MSFTNGP
> >0
> >> > >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/dnnets
> >e
> >> > >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
> >> > >> >> > >> >
> >> > >> >> > >> >
> >> > >> >> > >>
> >> > >> >> > >>
> >> > >> >> > >
> >> > >> >> >
> >> > >> >>
> >> > >> >>
> >> > >> >
> >> > >> >
> >> > >> >
> >> > >>
> >> > >>
> >> > >
> >> > >
> >> > >
> >> >
> >> >
> >>
> >>
> >
> >
> >
>
>

Quantcast