none
Can Non Exportable Private Keys Be Exported? RRS feed

  • Question

  • We are setting up  a PKI solution for our Wifi network

    I understood that user and computer certificates created with not exportable template are safe.

    Today i read that the private keys can be exported with some 3rd party tools.

    are there any solutions for this?

    Thanks

    Wednesday, October 24, 2012 6:48 PM

Answers

  • No, file system

    Even though you can define no export in the certificate template, this only prevents an MS domain joined machine from creating an exportable key. As stated earlier in the thread, if you can get the certificate and the files on the local file system, you could export the certificate with private key (not from the GUI)

    With versions prior to Windows 8, this is  a valid concern and you have to accept the risk that your employees will not purchase software allowing export with private key (when it was disabled in the certificate template)

    With Windows 8, you could move to virtual smart cards where the certificate's private key is protected by your computers TPM. This could prevent any export attacks.

    Prior to windows 8, you would need to protect the key material with either an HSM or a smart card certificate on a smart card or smart card chip-based USB stick

    Brian

    • Proposed as answer by Brian Komar [MVP] Saturday, October 27, 2012 5:21 PM
    • Marked as answer by YakovB Saturday, October 27, 2012 8:46 PM
    Friday, October 26, 2012 4:23 PM
  • yes, these tools exist. You can search internet for private key jailbreak. However, these applications require at least private key read permissions, so not all private keys can be dumped.


    My weblog: http://en-us.sysadmins.lv
    PowerShell PKI Module: http://pspki.codeplex.com
    Windows PKI reference: on TechNet wiki

    • Marked as answer by YakovB Saturday, October 27, 2012 8:45 PM
    Wednesday, October 24, 2012 7:06 PM
  • anyone?


    It looks like the default perms for read are SYSTEM and Administrators.

    Jason Jones | Microsoft MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk

    • Marked as answer by YakovB Saturday, October 27, 2012 8:46 PM
    Friday, October 26, 2012 11:18 AM

All replies

  • yes, these tools exist. You can search internet for private key jailbreak. However, these applications require at least private key read permissions, so not all private keys can be dumped.


    My weblog: http://en-us.sysadmins.lv
    PowerShell PKI Module: http://pspki.codeplex.com
    Windows PKI reference: on TechNet wiki

    • Marked as answer by YakovB Saturday, October 27, 2012 8:45 PM
    Wednesday, October 24, 2012 7:06 PM
  •  by default which users have " private key read permissions " ?

    Wednesday, October 24, 2012 9:11 PM
  • We are setting up  a PKI solution for our Wifi network

    I understood that user and computer certificates created with not exportable template are safe.

    Today i read that the private keys can be exported with some 3rd party tools.

    are there any solutions for this?

    Thanks


    Saving private keys in a HSM is probably the only way to truly protect them...

    Jason Jones | Microsoft MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk

    Wednesday, October 24, 2012 10:47 PM
  • anyone?

    Friday, October 26, 2012 11:07 AM
  • anyone?


    It looks like the default perms for read are SYSTEM and Administrators.

    Jason Jones | Microsoft MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk

    • Marked as answer by YakovB Saturday, October 27, 2012 8:46 PM
    Friday, October 26, 2012 11:18 AM
  • is this set at template level?
    Friday, October 26, 2012 2:01 PM
  • No, file system

    Even though you can define no export in the certificate template, this only prevents an MS domain joined machine from creating an exportable key. As stated earlier in the thread, if you can get the certificate and the files on the local file system, you could export the certificate with private key (not from the GUI)

    With versions prior to Windows 8, this is  a valid concern and you have to accept the risk that your employees will not purchase software allowing export with private key (when it was disabled in the certificate template)

    With Windows 8, you could move to virtual smart cards where the certificate's private key is protected by your computers TPM. This could prevent any export attacks.

    Prior to windows 8, you would need to protect the key material with either an HSM or a smart card certificate on a smart card or smart card chip-based USB stick

    Brian

    • Proposed as answer by Brian Komar [MVP] Saturday, October 27, 2012 5:21 PM
    • Marked as answer by YakovB Saturday, October 27, 2012 8:46 PM
    Friday, October 26, 2012 4:23 PM
  • so with XP and windows 7 the way to go is to block admin level access to machine ? or is that not enough?

    Saturday, October 27, 2012 4:56 PM
  • To be honest, no, that is not enough. It depends on your risk profile and what attacks you are trying to mitigate.

    Your choices are:

    1) use smart cards

    2) Trust that users will not buy the tools that would allow them to manually export. For example, use a Nordahl boot disk and reset the local Admin password or use a tool such as Elcomsoft EFS recovery tool (these are just examples)

    In most cases, setting the non-exportable tag will work. But, more orgs see this as an attack vector, hence the introduction of Virtual Smart Cards in Windows 8.

    Brian

    Saturday, October 27, 2012 5:21 PM
  • There is a even more simple way to export the key. Simply ask for an exportable key. This can be achieved by using the MMC and manually request the precise same certificate which you would get during autoenrollment. Autoenrollment requires Enrollment rights. So you cant prevent this.

    Unfortunately, "non exportability" is a "client feature" not anything defined within the certificate. And even Windows 7 does not respect the certificate template "do not export private key" definition when using the MMC and not autoenrollment. This for me seems to be a bug, not a feature. But it might even be by design :-)

    You might be able to make it a bit more difficult by disallowing certmgr snapin, but this makes supporters life a bit more difficult.

    So Brian is (like often:-) right:

    The only way to really protect the private key is an HSM, hence a smart card.

    Make users life easy and they will not want to circumvent your security measures.

    Patrick

    Friday, November 9, 2012 10:34 PM
  • Just remember that a smart card and an HSM are two different devices. Both protect the private key in a manner that it cannot be exported, but they are two very different devices (huge price difference and role difference)

    Typically HSMs protect server private keys and smart card protect user private keys

    Brian

    Saturday, November 10, 2012 3:50 PM
  • Hello Brian

    I never claimed that a smart card is an HSM.

    All I said, that the only way you can protect private keys are dedicated devices and:

    Windows does NOT prevent users from requesting certificates with exportable private keys, even if the template is set to enforce it.

    In XP you had to have some technical knowledge to use an alternative than autoenrollment or MMC, as both respected the setting. The newer certificate management MMC from Vista and above does allow you to overwrite default request settings. Key lenght, subject, SANs are enforced by CA, even if requested different but not the "export private key" setting.

    Again: this (IMHO) is a bug in the MMC which makes this setting in the template useless.

    Patrick

    Monday, December 10, 2012 7:52 AM
  • > Again: this (IMHO) is a bug in the MMC which makes this setting in the template useless.

    I doubt that this is a bug, because it is manly intended for autoenrollment and simple certificate request purposes. Nothing else. You can use certreq.exe tool to violate this setting. While many other settings can be checked by CA server, it can't get any details about private key (e.g. is key export allowed or not), because this information does not exist in the request.


    My weblog: http://en-us.sysadmins.lv
    PowerShell PKI Module: http://pspki.codeplex.com
    Check out new: PowerShell FCIV tool.

    Monday, December 10, 2012 10:47 AM
  • I thought we can find manually enrolled users by using CA and if required we can revoke them, if they appear to be potential negative impact.

    following command will give us rawrequest
    certutil -view -out Request.RawRequest 

    ' then use a script similar to the following to pull information

    'On Error Resume Next
    Set objFSO = CreateObject("Scripting.FileSystemObject")
    Set objShell = Wscript.CreateObject("Wscript.Shell")
    Set objFile = objFSO.CreateTextFile("./list.txt",2)
    Set objFileO = objFSO.OpenTextFile("./xyz.txt",1)
    Do until objFileO.AtEndOfStream
    strLine = objFileO.Readline
    if left(strline,12) = "  Request ID" Then
    objFile.Write strLine
    End if

    if left (strline,10) = "-----BEGIN" Then
    strQ = "B"
    set objFileT = objFSO.createTextFile("./temp.txt",2)
    else if left (strline,8) = "-----END" Then
    strQ = "E"
    objFileT.WriteLine strLine
    objFileT.close
    objShell.Run "cmd /c certutil temp.txt | findstr " & chr(34) & _
    "Process: User:" & chr(34) & " >a.txt",0, True
    set objFileX = objFSO.openTextFile("./a.txt",1)
    Do until objFileX.AtEndofStream
    objFile.Write "," &  objFileX.ReadLine
    Loop
    objFile.Writeline
    End if
    End if
    if strQ = "B" Then
    objFileT.WriteLine strLine
    End if
    loop

    '----------------------------------------------------

    probably above lines can help us to pull the info of the method of certificate request 

    Thursday, April 4, 2013 9:22 AM
  • In Windows 8 there is also support for the Microsoft Platform Crypto Provider. If you have confidence in the client machines configuration then using this KSP is a good way to ensure non-exportability.

    Guaranteeing that you are really using the KSP is another matter but this is a problem with all KSP/CSPs.

    Andrew

    Saturday, April 6, 2013 5:29 AM