Hi,

I'm currently developing a CSP for a HSM (PCI device).
I first interfaced the HSM, which I thought was the difficult part (very low 
level API, al bits'n bytes). But now it seems the CSP dev is a bit more 
cumbersome then I expected. 

So I managed to create a skeleton DLL, and I found an advapi32.dll hack to 
allow the self-signed csp dll to be loaded.

My problem is that my CSP dll loads; but I can't debug it? I'm running it on 
a windows XP sp2 system and if I'm not mistaking the CSP dll should be loaded 
by the 'winlogon' process. But when I attach my debugger to winlogon then 
none of my breakpoints is hit... I'd prefer not to use kernel debugging as I 
find it a bit awkward to set up. 

Does anybody have a golden tip so I can debug my code?

Thanks!

Hi,

A CSP dll can be debugged as a normal dll, once it's loaded by the desired 
process, without any special handling. In your case, I suppose that the 
Visual C++ debugger can't find the debugging symbols. I advice you to look 
into the "Output" window in Visuall C++ once you have attached it to the 
desired process (Winlogon.exe in your case) and search for the line 
containing your CSP dll. If it's loaded as expected by Winlogon, you should 
see a line like the following : 
'Winlogon.exe': Loaded 'C:\Program Files\XXX\XXX.dll', Symbols loaded.
Otherwise, it will look like : 
'Winlogon.exe': Loaded 'C:\Program Files\XXX\XXX.dll', No symbols loaded.

If you can't find your dll in the output, that means it has not been loaded 
at all. In this case, verify your registry setting. If you find it but no 
symbols have been loaded, this usually means you are using a release version 
of the dll or the dll has been compiled on another machine.
Try this and give us your feedback.

Cheers,
-- 
Mounir IDRASSI
IDRIX
http://www.idrix.fr


"Tom" wrote:

> Hi,
> 
> I'm currently developing a CSP for a HSM (PCI device).
> I first interfaced the HSM, which I thought was the difficult part (very low 
> level API, al bits'n bytes). But now it seems the CSP dev is a bit more 
> cumbersome then I expected. 
> 
> So I managed to create a skeleton DLL, and I found an advapi32.dll hack to 
> allow the self-signed csp dll to be loaded.
> 
> My problem is that my CSP dll loads; but I can't debug it? I'm running it on 
> a windows XP sp2 system and if I'm not mistaking the CSP dll should be loaded 
> by the 'winlogon' process. But when I attach my debugger to winlogon then 
> none of my breakpoints is hit... I'd prefer not to use kernel debugging as I 
> find it a bit awkward to set up. 
> 
> Does anybody have a golden tip so I can debug my code?
> 
> Thanks!

Hi Mounir,

Thanks for your reply, here is what I found:
- The Dll is a debug version, in fact it is the only one on my system.
- The problem seems that is has not been loaded, it's not in the list of 
loaded libraries.

I have registered the CSP as described in the MSDN docs and the CSP test 
suite does find my registration.

So perhaps I can ask another question: is it sufficient to make a test 
program for the CPXXX functions and then 'assume' it will also work for the 
CryptXXX functions?
And is there anything else then adding the Provider to the 
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Defaults\Provider list 
with the appropriate fields? In fact it is an RSA Full provider, perhaps the 
fact that it isn't the default is the problem (and the default rsaenh.dll is 
being used)?

A lot of questions

"Mounir IDRASSI" wrote:

> Hi,
> 
> A CSP dll can be debugged as a normal dll, once it's loaded by the desired 
> process, without any special handling. In your case, I suppose that the 
> Visual C++ debugger can't find the debugging symbols. I advice you to look 
> into the "Output" window in Visuall C++ once you have attached it to the 
> desired process (Winlogon.exe in your case) and search for the line 
> containing your CSP dll. If it's loaded as expected by Winlogon, you should 
> see a line like the following : 
> 'Winlogon.exe': Loaded 'C:\Program Files\XXX\XXX.dll', Symbols loaded.
> Otherwise, it will look like : 
> 'Winlogon.exe': Loaded 'C:\Program Files\XXX\XXX.dll', No symbols loaded.
> 
> If you can't find your dll in the output, that means it has not been loaded 
> at all. In this case, verify your registry setting. If you find it but no 
> symbols have been loaded, this usually means you are using a release version 
> of the dll or the dll has been compiled on another machine.
> Try this and give us your feedback.
> 
> Cheers,
> -- 
> Mounir IDRASSI
> IDRIX
> http://www.idrix.fr
> 
> 
> "Tom" wrote:
> 
> > Hi,
> > 
> > I'm currently developing a CSP for a HSM (PCI device).
> > I first interfaced the HSM, which I thought was the difficult part (very low 
> > level API, al bits'n bytes). But now it seems the CSP dev is a bit more 
> > cumbersome then I expected. 
> > 
> > So I managed to create a skeleton DLL, and I found an advapi32.dll hack to 
> > allow the self-signed csp dll to be loaded.
> > 
> > My problem is that my CSP dll loads; but I can't debug it? I'm running it on 
> > a windows XP sp2 system and if I'm not mistaking the CSP dll should be loaded 
> > by the 'winlogon' process. But when I attach my debugger to winlogon then 
> > none of my breakpoints is hit... I'd prefer not to use kernel debugging as I 
> > find it a bit awkward to set up. 
> > 
> > Does anybody have a golden tip so I can debug my code?
> > 
> > Thanks!

Hi,

First, you are registring your CSP the right way. But, the problem is that 
it's not sufficient for winlogon to load it. Actually, by default, Winlogon 
load the Microsoft Gina dll that supports only smart cards as an additional 
authentication method. Of course, PCI HSMs are not supported but this Gina 
dll unless it appears as a PC/SC reader to the system, in this case your HSM 
will have an ATR and the MS Gina will load your CSP based on this value. 
In order to support logon using your HSM, there are two ways: either you 
implement a specific Gina dll that will be loaded by the Winlogon process, or 
you can implement a dedicated authentication package  which can be tedious. 

Can you explain what are you trying to achieve with your HSM?


-- 
Mounir IDRASSI
IDRIX
http://www.idrix.fr


"Tom" wrote:

> Hi Mounir,
> 
> Thanks for your reply, here is what I found:
> - The Dll is a debug version, in fact it is the only one on my system.
> - The problem seems that is has not been loaded, it's not in the list of 
> loaded libraries.
> 
> I have registered the CSP as described in the MSDN docs and the CSP test 
> suite does find my registration.
> 
> So perhaps I can ask another question: is it sufficient to make a test 
> program for the CPXXX functions and then 'assume' it will also work for the 
> CryptXXX functions?
> And is there anything else then adding the Provider to the 
> HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Defaults\Provider list 
> with the appropriate fields? In fact it is an RSA Full provider, perhaps the 
> fact that it isn't the default is the problem (and the default rsaenh.dll is 
> being used)?
> 
> A lot of questions
> 
> "Mounir IDRASSI" wrote:
> 
> > Hi,
> > 
> > A CSP dll can be debugged as a normal dll, once it's loaded by the desired 
> > process, without any special handling. In your case, I suppose that the 
> > Visual C++ debugger can't find the debugging symbols. I advice you to look 
> > into the "Output" window in Visuall C++ once you have attached it to the 
> > desired process (Winlogon.exe in your case) and search for the line 
> > containing your CSP dll. If it's loaded as expected by Winlogon, you should 
> > see a line like the following : 
> > 'Winlogon.exe': Loaded 'C:\Program Files\XXX\XXX.dll', Symbols loaded.
> > Otherwise, it will look like : 
> > 'Winlogon.exe': Loaded 'C:\Program Files\XXX\XXX.dll', No symbols loaded.
> > 
> > If you can't find your dll in the output, that means it has not been loaded 
> > at all. In this case, verify your registry setting. If you find it but no 
> > symbols have been loaded, this usually means you are using a release version 
> > of the dll or the dll has been compiled on another machine.
> > Try this and give us your feedback.
> > 
> > Cheers,
> > -- 
> > Mounir IDRASSI
> > IDRIX
> > http://www.idrix.fr
> > 
> > 
> > "Tom" wrote:
> > 
> > > Hi,
> > > 
> > > I'm currently developing a CSP for a HSM (PCI device).
> > > I first interfaced the HSM, which I thought was the difficult part (very low 
> > > level API, al bits'n bytes). But now it seems the CSP dev is a bit more 
> > > cumbersome then I expected. 
> > > 
> > > So I managed to create a skeleton DLL, and I found an advapi32.dll hack to 
> > > allow the self-signed csp dll to be loaded.
> > > 
> > > My problem is that my CSP dll loads; but I can't debug it? I'm running it on 
> > > a windows XP sp2 system and if I'm not mistaking the CSP dll should be loaded 
> > > by the 'winlogon' process. But when I attach my debugger to winlogon then 
> > > none of my breakpoints is hit... I'd prefer not to use kernel debugging as I 
> > > find it a bit awkward to set up. 
> > > 
> > > Does anybody have a golden tip so I can debug my code?
> > > 
> > > Thanks!

Hi,

Just for testing I changed the default CSP to my CSP and now it loads 
correctly. It requires a reboot however and debugging this way seems a bit 
tedious, so I will write a test program for the CPXXX functions first.

What I want to do with the HSM is actually not logon. The purpose will be to 
create a CSP that allows X509 certificates to be used in conjunction with the 
HSM. The goal is to provide SSL by using the HSM and also Advanced and 
perhaps later Qualified Electronic signatures.
Everything is ready, Certificate request creation, keypair generation, cert 
management, etc etc so I just need the CSP to work so we can integrate 
smoothly in Windows and IIS.

But for now I will debug the CP methods instead of the Crypt ones, any 
comments or suggestions on that?

Tom

"Mounir IDRASSI" wrote:

> Hi,
> 
> First, you are registring your CSP the right way. But, the problem is that 
> it's not sufficient for winlogon to load it. Actually, by default, Winlogon 
> load the Microsoft Gina dll that supports only smart cards as an additional 
> authentication method. Of course, PCI HSMs are not supported but this Gina 
> dll unless it appears as a PC/SC reader to the system, in this case your HSM 
> will have an ATR and the MS Gina will load your CSP based on this value. 
> In order to support logon using your HSM, there are two ways: either you 
> implement a specific Gina dll that will be loaded by the Winlogon process, or 
> you can implement a dedicated authentication package  which can be tedious. 
> 
> Can you explain what are you trying to achieve with your HSM?
> 
> 
> -- 
> Mounir IDRASSI
> IDRIX
> http://www.idrix.fr
> 
>

Hi,

You can debug your CSP using the Crypt function by writing a test program 
that will call CryptAcquireContext using the name of your CSP instead of NULL 
or the name of the default MS provider for the parameter pszProvider. This is 
how your CSP will be used in the real world. There is no reason for accessing 
directly the CP functions of your dll. 
Do you have any problems accessing the Crypt functions of your CSP after 
specifying your CSP name in the pszProvider parameter of CryptAcquireContext?

-- 
Mounir IDRASSI
IDRIX
http://www.idrix.fr


"Tom" wrote:

> Hi,
> 
> Just for testing I changed the default CSP to my CSP and now it loads 
> correctly. It requires a reboot however and debugging this way seems a bit 
> tedious, so I will write a test program for the CPXXX functions first.
> 
> What I want to do with the HSM is actually not logon. The purpose will be to 
> create a CSP that allows X509 certificates to be used in conjunction with the 
> HSM. The goal is to provide SSL by using the HSM and also Advanced and 
> perhaps later Qualified Electronic signatures.
> Everything is ready, Certificate request creation, keypair generation, cert 
> management, etc etc so I just need the CSP to work so we can integrate 
> smoothly in Windows and IIS.
> 
> But for now I will debug the CP methods instead of the Crypt ones, any 
> comments or suggestions on that?
> 
> Tom
> 
> "Mounir IDRASSI" wrote:
> 
> > Hi,
> > 
> > First, you are registring your CSP the right way. But, the problem is that 
> > it's not sufficient for winlogon to load it. Actually, by default, Winlogon 
> > load the Microsoft Gina dll that supports only smart cards as an additional 
> > authentication method. Of course, PCI HSMs are not supported but this Gina 
> > dll unless it appears as a PC/SC reader to the system, in this case your HSM 
> > will have an ATR and the MS Gina will load your CSP based on this value. 
> > In order to support logon using your HSM, there are two ways: either you 
> > implement a specific Gina dll that will be loaded by the Winlogon process, or 
> > you can implement a dedicated authentication package  which can be tedious. 
> > 
> > Can you explain what are you trying to achieve with your HSM?
> > 
> > 
> > -- 
> > Mounir IDRASSI
> > IDRIX
> > http://www.idrix.fr
> > 
> >

Hi Mounir,

You're absolutelly right.
I must have been blinded by the troubles on the road. Actually my own test 
program used the Crypt functions, but failed due to an 'invalid signature' 
error (I still used the original advapi32 at that point.
So I moved on to winlogon debugging first and then after solving the 
advapi32 problem forgot about my own test program. It's late and monday... 
I'm able to debug properly now, so thanks for helping me out here! 

I don't have problems understanding the techniques used here, I'm just new 
to the CSP development (spent all my time so far on low level non-ms code for 
crypto etc), so perhaps one (or two) thing that is not totally clear for me 
at the moment: How will e.g. the Microsoft Certificate Store 'know' that it 
needs to load my DLL for certain certificates and not the default one without 
user interaction? I also don't feel confident about the concept of 
'Containers' could someone shed some light on that? Are the two 



kind regards,

Tom

Hi Tom,

Microsoft Crypto API and Certificate Store come with no "intelligence" or 
automatic mechanisms. Everything must be done by the applications interacting 
with them. In your case, if you want to populate the Certificate Store "MY" 
with the certificates in the HSM, you have to write a custom application that 
will load them from the HSM using the CSP and create the appropriate entries 
using the CertXXX functions. Once this Certificate Store populated correctly, 
applications like IE or Outlook will find your certificate, thus enabling the 
user to perform SSL or S/MIME operations.
Concerning the CSP containers, you can look at them as named holders where 
you can put your keys and the corresponding certificates for a later use. 
There name can be of any value, thus you can define your own naming strategy 
that will help you identify easily each key depending on its purpose.

I hope this clarifies things to you. By the way, you message seems to be 
incomplete...

-- 
Mounir IDRASSI
IDRIX
http://www.idrix.fr


"Tom" wrote:

> Hi Mounir,
> 
> You're absolutelly right.
> I must have been blinded by the troubles on the road. Actually my own test 
> program used the Crypt functions, but failed due to an 'invalid signature' 
> error (I still used the original advapi32 at that point.
> So I moved on to winlogon debugging first and then after solving the 
> advapi32 problem forgot about my own test program. It's late and monday... 
> I'm able to debug properly now, so thanks for helping me out here! 
> 
> I don't have problems understanding the techniques used here, I'm just new 
> to the CSP development (spent all my time so far on low level non-ms code for 
> crypto etc), so perhaps one (or two) thing that is not totally clear for me 
> at the moment: How will e.g. the Microsoft Certificate Store 'know' that it 
> needs to load my DLL for certain certificates and not the default one without 
> user interaction? I also don't feel confident about the concept of 
> 'Containers' could someone shed some light on that? Are the two 
> 
> 
> 
> kind regards,
> 
> Tom
> 
>