Re: Protecting private key on a soft cert

From: saict (thurberk_at_cscsw.com)
Date: 06/21/04

  • Next message: Denis: "RE: IAzClientContext AccessCheck returns 0x80070057"
    Date: 21 Jun 2004 14:23:03 -0700
    
    

    "Michel Gallant" <neutron@istar.ca> wrote in message news:<OsAMYMIVEHA.1292@TK2MSFTNGP10.phx.gbl>...
    > "saict" <thurberk@cscsw.com> wrote in message
    > news:7eab6777.0406170655.7ebb9e80@posting.google.com...
    > > "Michel Gallant" <neutron@istar.ca> wrote in message
    > news:<uAz2rb$UEHA.3332@tk2msftngp13.phx.gbl>...
    > > > CSP protection for MS providers in W2k+ is based on DPAPI.
    > > > A fair level of details on how the various keys are derived based on
    > > > logged on user is described here:
    > > >
    > > >
    > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsecure/html/windataprotection-dpapi.asp
    > > >
    > > > - Mitch Gallant
    > > > MVP Security
    > >
    > > Thank you again, Mitch, for your valuable feedback. Would I be
    > > correct in saying that the private key is, in the end, protected by
    > > the user's login credential?
    >
    > If you don't provide extra "entropy" (i.e. "Strong Protection" option), than that is
    > correct. Any process running under your loging credentials would have access to
    > using the private key. That is why Strong Protection (based on another password-derived
    > encryption) is important when importing (say from PKCS #12) private key to CSP.
    > This is described fairly well in the dpapi article above.
    > - Mitch

    Yes, I understand that. I was just trying to get a feel for how
    securely this was happening by default. A discussion at a PKI
    conference had most of us thinking this was done by some sort of
    'security by obscurity' scheme, so we were happy to get your answer.


  • Next message: Denis: "RE: IAzClientContext AccessCheck returns 0x80070057"