News  [SoftwareSite

Latest News
Older News
RSS Feed
 
Complete Projects
Useful Classes
Top Downloads
Message Board
AllAPI.net
 
Send Comments
Software License
Mentalis.org Buttons
Donate
 
Forums -> Security Library Forum
 
Nt service problem - CTYPTO_SILENT flag  
by dan trubow
posted on 2003/11/06

When running as a Windows NT service, a client is unable to connect via a secure socket to a server.

I ran a console app and this worked fine. Then I converted to a service and always recieved an exception "Could not acquite crypto context."

After some troubleshooting here is what I found:

The problem occurred with the call to Certificate.PublicKey which calls SspiProvider.CryptAcquireContext(ref provider, IntPtr.Zero, null, SecurityConstants.PROV_RSA_FULL, flags) and has the flag set to CRYPT_SILENT since this not an Environment.UserInteractive context (it's a Windows Service).

The crypt32.dll function when run on NT sets the error NTE_BAD_FLAGS ( 0x80090009L ) meaning "The dwFlags parameter has an invalid value.". You can retrieve this by using GetLastError.

The CRYPTO_SILENT flag which is set in SecurityConstants to 0x40 is not recognized by the crypt32.dll on NT systems as valid. I checked the value and it is proper. Microsoft claims this is valid on NT systems (but not ME/98/95), but apparently it's not. My NT boxes are all up to date in terms of Service Packs.

Do you have a work around or an alternate flag for NT systems? I'm not very anxious to enter the Microsoft Abyss, perhaps never to return in a sane condition.

OK, a final comment. I found a workaround but it creates a security risk. If youcheck the Window's Service to 'Allow Service to Interact with Desktop' (choose Startup... from the Services window on NT after selecting the service), then the connect will proceed normally. The security risk is well documented (someone who logs in as a guest could potentially get a handle to this service and then have full admin control over the service).

by Pieter Philippaerts [Pieter at mentalis dot org]
posted on 2003/11/07

Can you try to remove that CRYPT_SILENT flag from the flags that get passed to the function? Does it work when you do that?

The Microsoft documentation says that it's supported on Win2K and higher, yet it doesn't list NT4 among the list of unsupported operating systems. Given the behavior you're seeing, I'd say that NT4 should also be on that list of unsupported systems.

by dan trubow [legitreview at NOSPAMhotmail dot com]
posted on 2003/11/13

If the file certificate.cs, in the function public RSA PublicKey, I commented out the 2 lines:

if (!Environment.UserInteractive)
flags = SecurityConstants.CRYPT_SILENT;

Then I set the service to not interact with the desktop.

Here I initiated a secure connection, and it succeeded.

The flags variable was initialized to zero.

Yes, this is another workaround.

by Pieter Philippaerts [Pieter at mentalis dot org]
posted on 2003/11/15

Ok, thanks. Apparently the flag isn't supported on NT4 either. I'll make sure to fix the code in the next release of the library.

by Chris Hudel [chris at hudel dot com]
posted on 2003/11/19

Hi,

I ran into a similar problem with my CryptAcquireContext's failing with the same error. I have modified the PublicKey method (line 1121 in Certificate.cs) and am experiencing some initial success.

Still, I would be happy to hear from the programming community whether or not my change makes sense.

Basically, I changed

from this:

if (SspiProvider.CryptAcquireContext(ref provider, IntPtr.Zero, null, SecurityConstants.PROV_RSA_FULL,flags ) == 0) {

if (SspiProvider.CryptAcquireContext(ref provider, IntPtr.Zero, null, SecurityConstants.PROV_RSA_FULL, flags | SecurityConstants.CRYPT_VERIFYCONTEXT) == 0)

-- You can see that I've added the CRYPT_VERIFYCONTEXT flag. Since the PublicKey documentation says that we the key cannot be used to sign or encrypt data, I believe this is the proper flag to use. Otherwise, you will get an error denying you access to the (Private) key container.

Also, I wish there were more use of GetLastWin32Error so I didn't have to always insert my own code to see what the underlying crypto-api error code is. ;-)


 

Copyright © 2002-2007, The Mentalis.org Team. All rights reserved.
This site is located at http://www.mentalis.org/
Send comments to the webmaster.