Sam
Sam

Reputation: 2552

Using Indy components to verify Smart Card credential

Does Indy components have any kink of functionality to verify the credential of a Smart Card (CAC)? I am assuming it has to be used in conjunction with InitializeSecurityContext.

I am using it in C++ Builder Seattle but even Delphi examples would be appreciated.

Here is what I have figured out so far:

  1. Open System Certificate Store (CertOpenSystemStore) and let the user select a certificate (CryptUIDlgSelectCertificateFromStore).
  2. Get the Credential Handle (AcquireCredentialsHandle).
  3. Connect to my server using TIdTCPClient and TIdSSLIOHandlerSocketOpenSSL using the secure port 443.
  4. call InitializeSecurityContext which returns SEC_I_CONTINUE_NEEDED.

After that I am not sure what should be sent to server and what to expect in return. Also at which point the system should ask the user for the PIN?

Thank you

Upvotes: 4

Views: 475

Answers (1)

Remy Lebeau
Remy Lebeau

Reputation: 597315

When you get SEC_I_CONTINUE_NEEDED, you are supposed to transfer the output token data to the server, wait for a response token, and then pass that back to InitializeSecurityContext(). Now, how you actually transfer the data back and forth depends on the particular protocol you are using to communicate with the server.

For example, in TIdHTTP, Indy has a TIdSSPINTLMAuthentication class for handling NTLM authentication using the same API you are using. It initializes the NTML security package and then uses InitializeSecurityContext() to retrieve a buffer of bytes containing NTLM token data, which is then base64 encoded put into an HTTP Authorization: NTML ... request header. When the response comes back, if it has an HTTP WWW-Authenticate: NTLM ... header offering the response token data, the data is base64 decoded and the resulting bytes are fed back into InitializeSecurityContext().

So, you need to figure out what communication protocol you are using to talk to your server, and how that protocol expects you to transmit the token bytes back and forth. That is outside of Indy's scope. It provides you with the means of transmitting and receiving bytes, but you have to supply and read them as needed.

Upvotes: 1

Related Questions