|
|
You're in the
dotnet clr
group:Password prompts when signing with smartcard
dotnet clr:
For security reasons, I'm storing my public/private key pair on a smart card. My bulid process delay signs the assemblies using the public key, and I later go back and re-sign the assemblies using public/private key pair from the smartcard using sn.exe -Rc <assembly> <container>. The problem is, for every assembly I re-sign, I am prompted to input the smartcard's password. With a couple hundred assemblies to re-sign, this is tedious and time consuming. Is there a way to avoid all the password prompts? For example, can you specify multiple assemblies or a file containing a list of assemblies to sn.exe -Rc? Thanks,
Hi Bill,
I will give this issue a research. I will reply to you ASAP. Thanks. Best regards, Jeffrey Tan Microsoft Online Community Support ================================================== When responding to posts, please "Reply to Group" via your newsreader so that others may learn and benefit from your issue. ================================================== This posting is provided "AS IS" with no warranties, and confers no rights.
Hi Bill,
Sorry for letting you wait so long. In your scenario, there are two aspects. 1) The prompt to input the smartcard pin is shown by the Smartcard CSP while the application code is attempting to access the RSA private key container for the *first* time either in a call to CPAcquireContext(), CPGetUserKey (AT_KEYEXCHANGE/AT_SIGNATURE), CPSignXXXX() etc. Once the CSP has the PIN information, the application code calling Crypto APIs using the *same* HCRYPTKEY/HCRYPTPROV handle in the *same* process will not get prompted for the PIN again. The behavior is Smartcard CSP specific. 2) The application code using Crypto APIs such as CryptAcquireContext(), CryptGetUserKey() should have the capability of re-using the *same* HCRYPTPROV (provider handle) or HCRYPTKEY (RSA private key handle) for multiple signing operations. If the application code acquires the RSA private key container using CryptAcquireContext() for every Crypto operation, you will get prompted for the PIN each time. The SN.exe confines to the #2 scenario. Also, based on my review, there is not an option in SN.EXE that will allow you resign multi-assemblies at the same time. Additionally, since Smartcard CSP doesn't provide the feature of exporting the RSA private key pair from the smartcard for security reasons. The private key never leaves the smartcard. So, you cannot export the key pair outside of Smart Card. I do not think there is a perfect workaround regarding this issue. Hope my analysis makes sense to you. Best regards, Jeffrey Tan Microsoft Online Community Support ================================================== When responding to posts, please "Reply to Group" via your newsreader so that others may learn and benefit from your issue. ================================================== This posting is provided "AS IS" with no warranties, and confers no rights.
Hi Jeffrey,
Thank you for your response and your clear analysis. This limitation of the SN utility makes it impractical for us to realize the added security benefits of storing our private key on a smart card, because we just have too many assemblies that will require resigning. Can you request that SN.EXE be extended to allow signing of multiple assemblies? Best regards, Bill [quoted text, click to view] ""Jeffrey Tan[MSFT]"" wrote:
> Hi Bill, > > Sorry for letting you wait so long. > > In your scenario, there are two aspects. > > 1) The prompt to input the smartcard pin is shown by the Smartcard CSP > while the application code is attempting to access the RSA private key > container for the *first* time either in a call to CPAcquireContext(), > CPGetUserKey (AT_KEYEXCHANGE/AT_SIGNATURE), CPSignXXXX() etc. Once the CSP > has the PIN information, the application code calling Crypto APIs using the > *same* HCRYPTKEY/HCRYPTPROV handle in the *same* process will not get > prompted for the PIN again. The behavior is Smartcard CSP specific. > > 2) The application code using Crypto APIs such as CryptAcquireContext(), > CryptGetUserKey() should have the capability of re-using the *same* > HCRYPTPROV (provider handle) or HCRYPTKEY (RSA private key handle) for > multiple signing operations. If the application code acquires the RSA > private key container using CryptAcquireContext() for every Crypto > operation, you will get prompted for the PIN each time. > > The SN.exe confines to the #2 scenario. Also, based on my review, there is > not an option in SN.EXE that will allow you resign multi-assemblies at the > same time. > > Additionally, since Smartcard CSP doesn't provide the feature of exporting > the RSA private key pair from the smartcard for security reasons. The > private key never leaves the smartcard. So, you cannot export the key pair > outside of Smart Card. > > I do not think there is a perfect workaround regarding this issue. Hope my > analysis makes sense to you. > > Best regards, > Jeffrey Tan > Microsoft Online Community Support > ================================================== > When responding to posts, please "Reply to Group" via your newsreader so > that others may learn and benefit from your issue. > ================================================== > This posting is provided "AS IS" with no warranties, and confers no rights. >
Hi Jeffrey,
I had one more question for you. Given the smartcard and the PIN, could someone write a utility to extract the private key, or is it stored on the smartcard in such a way that only SN.EXE can access it? Thanks, Bill [quoted text, click to view] ""Jeffrey Tan[MSFT]"" wrote:
> Hi Bill, > > Sorry for letting you wait so long. > > In your scenario, there are two aspects. > > 1) The prompt to input the smartcard pin is shown by the Smartcard CSP > while the application code is attempting to access the RSA private key > container for the *first* time either in a call to CPAcquireContext(), > CPGetUserKey (AT_KEYEXCHANGE/AT_SIGNATURE), CPSignXXXX() etc. Once the CSP > has the PIN information, the application code calling Crypto APIs using the > *same* HCRYPTKEY/HCRYPTPROV handle in the *same* process will not get > prompted for the PIN again. The behavior is Smartcard CSP specific. > > 2) The application code using Crypto APIs such as CryptAcquireContext(), > CryptGetUserKey() should have the capability of re-using the *same* > HCRYPTPROV (provider handle) or HCRYPTKEY (RSA private key handle) for > multiple signing operations. If the application code acquires the RSA > private key container using CryptAcquireContext() for every Crypto > operation, you will get prompted for the PIN each time. > > The SN.exe confines to the #2 scenario. Also, based on my review, there is > not an option in SN.EXE that will allow you resign multi-assemblies at the > same time. > > Additionally, since Smartcard CSP doesn't provide the feature of exporting > the RSA private key pair from the smartcard for security reasons. The > private key never leaves the smartcard. So, you cannot export the key pair > outside of Smart Card. > > I do not think there is a perfect workaround regarding this issue. Hope my > analysis makes sense to you. > > Best regards, > Jeffrey Tan > Microsoft Online Community Support > ================================================== > When responding to posts, please "Reply to Group" via your newsreader so > that others may learn and benefit from your issue. > ================================================== > This posting is provided "AS IS" with no warranties, and confers no rights. >
Hi Bill,
Thanks for your feedback. Yes, I originally have the same thought as you. However, for security reasons, the Smartcard CSP doesn't provide the feature of exporting the RSA private key pair from the smartcard . The private key never leaves the smartcard. So, you cannot export the key pair outside of Smart Card. We have to use Win32 crypto Win32 API to access the Smart Card key pairs, which is what sn.exe does internally. The only option to this issue is rewriting the sn.exe to support re-signing the multiple assemblies at a single command line. Based on your concern regarding sn.exe, I recommend you provide the feedback in the feedback center below: http://connect.microsoft.com/Main/content/content.aspx?ContentID=2220 Our product team will receive your feedback request and follow up with you. Thanks. Best regards, Jeffrey Tan Microsoft Online Community Support ================================================== When responding to posts, please "Reply to Group" via your newsreader so that others may learn and benefit from your issue. ================================================== This posting is provided "AS IS" with no warranties, and confers no rights.
Hi Jeffrey,
I appreciate your followup on this. I don't think I communicated my last question clearly. I understand that neither the smartcard CSP nor SN.EXE allow you to export the private key back to a disk file. My question is, could a developer write a utility using the Win32 Crypto API to extract the private key from the smartcard, or is the key somehow encrypted or otherwise protected so that only SN.EXE can read it? I went ahead and requested the enhancement to SN.EXE as you suggested. Thanks for your help. Bill [quoted text, click to view] ""Jeffrey Tan[MSFT]"" wrote:
> Hi Bill, > > Thanks for your feedback. > > Yes, I originally have the same thought as you. However, for security > reasons, the Smartcard CSP doesn't provide the feature of exporting the RSA > private key pair from the smartcard . The private key never leaves the > smartcard. So, you cannot export the key pair outside of Smart Card. > > We have to use Win32 crypto Win32 API to access the Smart Card key pairs, > which is what sn.exe does internally. The only option to this issue is > rewriting the sn.exe to support re-signing the multiple assemblies at a > single command line. > > Based on your concern regarding sn.exe, I recommend you provide the > feedback in the feedback center below: > http://connect.microsoft.com/Main/content/content.aspx?ContentID=2220 > > Our product team will receive your feedback request and follow up with you. > > Thanks. > > Best regards, > Jeffrey Tan > Microsoft Online Community Support > ================================================== > When responding to posts, please "Reply to Group" via your newsreader so > that others may learn and benefit from your issue. > ================================================== > This posting is provided "AS IS" with no warranties, and confers no rights. >
Hi Bill,
Oh, thanks for your clarify, it appears much clear now :-) Sn.exe is simply a win32 application leverages Win32 Crypto API/CAPICOM to do the signing work. If you used it against smart card, it will use SmartCard CSP. If you are curious about code signing with code, please refer to my reply below(take care of the URL line-break): http://groups.google.com/group/microsoft.public.dotnet.languages.vb/browse_t hread/thread/8021c957190b2377/ba4a67844e999f46?lnk=st&q=%22Verifying+Digital +Signatures+in+Code%22&rnum=1&hl=zh-CN#ba4a67844e999f46 The article below gives Smart Card Cryptographic Service Provider a detailed description: "The Smart Card Cryptographic Service Provider Cookbook" http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnscard/htm l/smartcardcspcook.asp Hope this helps! Best regards, Jeffrey Tan Microsoft Online Community Support ================================================== When responding to posts, please "Reply to Group" via your newsreader so that others may learn and benefit from your issue. ================================================== This posting is provided "AS IS" with no warranties, and confers no rights.
Hi Bill,
Does my reply make sense to you? If you still have any questions please feel free to tell me, thanks. Best regards, Jeffrey Tan Microsoft Online Community Support ================================================== When responding to posts, please "Reply to Group" via your newsreader so that others may learn and benefit from your issue. ================================================== This posting is provided "AS IS" with no warranties, and confers no rights.
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |