CSP Complexity
Hi Guys.I have been reading a lot on PKI lately including MSDN and third party articles and RFCs. I even went through Brian Komar's excellent PKI reference and even read RSA Labs - Official Cryptography book. After reading all this I believe I now understand PKI internals sufficiently but there are some questions to which I couldn't find answer in all the above readings. I am asking them herewith hopethat PKI experts over here willhave answers to it.So let me describe thequestions then:As per my understanding, I believe that in case of software only CSPs, operating system implements the various cryptographic algorithms which are used by the CSPs to provide crytographic services to the applications. When hardware like smartcards are used then I believe the smartcard implements certain required cryptographic algorithms and its CSP uses the onboard implementation to perform all the cryptographic functions, this is the fact that provides the security associated with smartcards because private key is never exposed. Now I recall reading that each CSP packs data differently so to speak, i.e it uses different padding schemes, data structures etc while feedingthe datato the underlying algorithms implemented by the operating system, which essentially means that the data encrypted or signature generated by a specific CSP can only be decrypted by the CSP that actually generated it and no other CSP can decrypt it? The fact that we need to have the smartcard CSP installed on both the sender and receiver's machines in order to decrypt an S/MIME email confirms this?Now applying thisto the smartcard logon scenario, we can see that during the logon the pre-authentication data (i.e PKINIT message for example) gets encrypted by the smartcard CSP, which then is sent to domain controller. Now as the smartcard CSP will not be available on the domain controller, and we know the fact that only theencrypting CSP can decrypta given chunk of data, I am wondering how the received PKINIT message gets decrypted by the domain controller?The same is also true for an L2TP/IPSEC VPN connection for example, where we can use smartcards for authentication, because here also a VPN client will have and use the smartcard CSP to encrypt authentication data and the VPN server will decrypt it, which will again not have the smartcard CSP available to it for decryption? How does all these smartcard based authentications work then?I hope I have been clear in describing the questions, I now look forward to helpful replies to address these confusions...,Thanks.Best Regards,wakh
August 1st, 2009 3:02am

Hi, As far as I know, decryption was performed on the client side, DC doesnt need know the Smart Card CSP. The "Smart Card Logon and Authentication" section of the following article may help to understand how Smart Card CSP works with Domain Controller. http://technet.microsoft.com/en-us/library/dd277362.aspx For your reference: What Is Kerberos Authentication?http://technet.microsoft.com/en-us/library/cc780469(WS.10).aspx How Interactive Logon Workshttp://technet.microsoft.com/en-us/library/cc780332(WS.10).aspx Thanks.This posting is provided "AS IS" with no warranties, and confers no rights.
Free Windows Admin Tool Kit Click here and download it now
August 3rd, 2009 11:25am

http://technet.microsoft.com/en-us/library/dd277320.aspxCryptography and Microsoft Public Key InfrastructureCreativity cannot be taught, but it can be learned.
August 5th, 2009 3:10am

@Mervyn Zhang: Sorry for the late reply, I was away from my desk. I read the articles you pointed out, and yes the decryption is performed on the client side. Let my clarify the actual question here. CSP Operation: CSPs are compatible with each other only up to the verification of digital signatures as far as I know, i.e a signature generated by CSP-A can be verified by CSP-B and vice versa because it is a requirement by Microsoft for all CSPs to provide some interoperability. But a chunk of data encrypted by CSP-A cannot be decrypted by CSP-B and vice versa as far as I know. Smartcard Authentication: During a smartcard based authentication Kerberos protocol is used to provide authentication. We know that it uses the following messages, KRB_AS_REQ, KRB_AS_REP, KRB_TGS_REQ and KRB_TGS_REP. When the client sends KRB_AS_REQ message to KDC it includes the user's public key certificate signed with the corresponding private key in a field called Pre-Authentication data. After the KDC performs the verification checks it replies with the KRB_AS_REP message to the client and includes the user's credentials hashed and encrypted with the user's public key in the Pre-Authentication field. We know that credentials are included because they are required for requesting Service tickets from the KDC. Now what I don't understand is that how will the client be able to decrypt the included credentials? The domain controller did not have access to smartcard's CSP which means that the smartcard's CSP will not be able to decrypt the credentials due to the fact that only the encrypting CSP can decrypt a given chunk of data? This is the actual question of this topic? @Shems: Thanks for the link you provided, but the question of this topic is much more advanced and that article is just an overview of the PKI. You can read the references I used already in the first post. Looking forward to helpful replies... Best Regards, wakh
Free Windows Admin Tool Kit Click here and download it now
August 16th, 2009 3:33am

You are overthinking this *way* too much <G>.As you stated, "The RB_AS_REP messageincludes the user's credentials hashed and encrypted with the user's public key in the Pre-Authentication field."The client decrypts the data using *its* private key from the key pair (basic assymetric encryption/decryption principals in action). Since the credentials are hashed, this means that the hashing algorithm information is included, so the same hashing algorithm is applied to the credentials to ensure that the values are the same.You have the mistaken assumption that the same CSP must be used at both ends when assymetric encryption is applied. This is an invalid assumption.Brian
August 16th, 2009 4:18pm

Thanks alot for your helpful input Brian. So this means that different CSPs can be used with each other when basic asymmetric encryption is used? But not when symmetric encryption is used to encrypt data and asymmetric encryption is used to encrypt the symmetric key? I had read this MSDN article on CSP interoperability which never mentioned the fact you highlighted. http://msdn.microsoft.com/en-us/library/aa381483%28VS.85%29.aspx
Free Windows Admin Tool Kit Click here and download it now
August 16th, 2009 5:01pm

It is really quite basic when you think of it.1) You can log on to AD with any smart card vendor's CSP, yet you do not need to load every specific CSP on the DCs that authenticate the smart cardsBrian
August 17th, 2009 6:23am

Yes, it is clear now that CSPs are compatible with each other as long as simple asymmetric encryption is used, like in the case of Kerberos logon. However, I believe that when a smartcard certificate (based on Smartcard User template) is used along with S/MIME protocol where both symmetric and asymmetric encryption is used then we do need to have the corresponding smartcard CSP installed on both ends right? Regards, wakh
Free Windows Admin Tool Kit Click here and download it now
August 18th, 2009 3:09am

Sigh.... noPlease stop over thinking this.If I were to use my specific smart card, what use would S/MIME be if you were required to use the same smart card CSP on your side to decrypt.Think logicallyBrian
August 18th, 2009 5:15am

OK Brian, I got it, that CSPs are completely interoperable with each other. They all implement standardized algorithms, so it is not required to have same CSP on both ends even in case of smartcard certificate based S/MIME. As a network and software engineer I try to find information about the internal workings of things in order to be a well rounded professional. I am preparing for 70-299 exam, in which PKI is an important topic, it was also new to me, so I tried to learn it completely. It took me the longest time to prepare this topic due to its complexity. Pardon me for the questions I asked, they are easy for you due to your vast knowledge in this topic, but they were not easy for me. One more thing I would like to ask as I couldn't find info on it, i.e in Windows Server 2003 Certificate Services, under the 'Request Handling' tab of version 2 template there is an option called 'Include symmetric algorithms allowed by the subject'. What is it used for? Once again, thanks alot for your helpful input..., Best Regards, wakh
Free Windows Admin Tool Kit Click here and download it now
August 19th, 2009 3:17am

Hi, The following thread may help: Certificate Templates - symmetric algorithmshttp://social.technet.microsoft.com/Forums/en-US/winserversecurity/thread/6de06d50-729f-4e8a-8312-3058b9bd75e2 Thanks.This posting is provided "AS IS" with no warranties, and confers no rights.
August 19th, 2009 5:08am

Thanks for the link Mervyn, but as far as I know the information about the symmetric algorithm that has been used to encrypt email is included in the encrypted email itself along with hashing algorithm. So it is not required to include the information about the supported algorithms separately in the certificate? However, one scenario where it might be helpful is when non-windows machine uses the certificate to encrypt email, the machine can check the certificate to see the list of supported symmetric algorithms and use one of the listed ones to encrypt the email. In this scenario it is helpful because non-windows machines might be supporting more symmetric algorithms than windows machines, so it checks before encrypting to make sure that the other party on the windows machine will be actually able to decrypt it. But on windows machines this information is redundant and not required because all CSPs by default support RC2 and RC4 symmetric algorithms and will use one of those only to encrypt. Am I correct here? Best Regards, wakh
Free Windows Admin Tool Kit Click here and download it now
August 19th, 2009 3:59pm

No.The S/MIME capabilities is read when the email client is going to encrypt the email message for a specific recipient. When the recepient's certificate is acquired (from a directory or contact), the email client is able to inspect the S/MIME capabilities of the recipient. It then can compare what symmetric algorithms its CSP shares with the recipient. Typically, the highest form of symmetric encryption is used (or the default if you have selected a lower form of encryption).Your statement that only RC2 and RC4 are used is absolutely incorrect! I have several customers that require minimum 3DES or AES, and cannot use RC2 or RC4 due to security policyBrian
August 20th, 2009 12:00am

Sorry if I was not clear, but I meant that all microsoft's CSPs by default implement RC2 and RC4 algorithms. Other third party custom CSPs can ofcourse implement additional algorithms as per their requirements. So in case when the symmetric algorithms information is not included in the certificate (i.e the option 'Include symmetric algorithms allowed by the subject' is left unchecked) then the email client just chooses the strongest symmetric encryption its CSPsupports or some other actions are taken? Regards, wakh
Free Windows Admin Tool Kit Click here and download it now
August 21st, 2009 2:44am

Sigh.... no Please stop over thinking this. -specific- Think logically Brian That's a very nice way of saying what's all on our minds. Aside from the fact this thread has much potential, it is damaging Technet itself. Other forums may lower to this level but not Technet. This is simply not a professional way of going about 'just asking'. This is quite a powerful statement, I am well aware. This is one of the few foreign texts I ran through an online translator; specifically the first post. It was painfully (I felt I had been duped) obvious Wakh's first posting is gibberish. It can not be translated; not by yours truly, anyway. As a matter fact the (any) translation brings some comic relief. I've never reacted like so on Technet. In this case I really feel it needs to be said. How Wakh reacted to my first reaction here, did have an emotional impact, but is all but the reason for this posting. Since indirect references don't seem to work, I'll put it loud and clear; this has to stop ! The potential this thread has (still) is in showing that members can and should 'propose as answer' and/or 'vote as helpful' without looking at it as either a great credit or discredit to their 'reputation' but rather as an opinion. The greatest strength would be to balance these ideas. One could even state one should not be afraid to take a risk.Creativity cannot be taught, but it can be learned.
August 23rd, 2009 4:24am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics