Hi,
this is a tricky one:
I am using an 2003 Enterprise CA and Sub CA to issue User Certificates.
I use CLM 2003 to manage the Smart Cards. (Axalto .NET v2 in USB Shell Tokens)
The clients have Windows XP SP2 with KB 909520 (Microsoft SmartCard BaseCSP)
The KB comes with the SmartCard Minidriver, the only external driver used is a Gemalto CCID driver for the USB Shell Token which holds the SmartCard.
The pintool.exe from the KB is used to manage the PIN. However you can set 0000 as a valid PIN.
Also, I did not find a way to control the number of PIN attempts until the card blocks the PIN.
And this is where internal audit started to seriously b*tch.
I have tried MS Support, so far with limited success. The Windows Smart Card Minidriver Specification reveals that there is a handle pdwcAttemptsRemaining to control PIN attempts. But not where it comes from. A quick test showed the SmartCard locks after 4 failed attempts. But where did that come from? Account lockout policy from the machine? That could be circumvened. Is is hardcoded in the axaltocm.dll?
Also if I can set the PIN with any pintool.exe on any machine, how in the world do I enforce PINs stronger than 0000? Not with a GPO for sure. But can I put in the certificate template PIN rules? Or can I enforce that the PIN can only be changed when the client has a connect to the CLM to ensure policies?
So my questions:
1. How do you control the initial value of pdwcAttemptsRemaining, or rather where does it come from and where is it stored?
2. Can you in this environment reliably enforce PIN rules, and how?
This Question has been solved and asker verified All Experts Exchange premium technology solutions are available to subscription members.
Experts Exchange has been collecting answers to technology questions since 1996…3 million and counting! If you have a question, chances are we already have your answer.
If you can't find the exact answer you're looking for, ask our exclusive community of 50,000 experts. You’ll get a personalized answer from a trusted professional.
Thousands of free tech tips, tricks, how-to’s and tutorials are available in our peer reviewed articles section. See for yourself how smart our experts are, no login required.
Save solutions to your questions, answers you’ve discovered through searching plus helpful articles in your personal knowledgebase for easy future access.
Access the answers to your technology questions today.
30-day free trial. Register in 60 seconds.
Members of the expert community talk about why the experience at Experts Exchange is different than what you will find anywhere else.
Try it out and discover for yourself.
30-day free trial. Register in 60 seconds.
Join the community of experts here and help other tech pros by answering question in your area of expertise. You can earn FREE access to all Experts Exchange's premium features and resources.
Of course I'm not sure, thats the whole purpose of my endeavor. To satisfy MaRisk and the internal autit of a bank I need to find out exactly where it is located, and how it is controlled.
You are right in that there is no reason for pdwcAttemptsRemaining not to be stored on the card. But still that would leave me with the question how it got there and how to influence the value.
This value is definately stored on the token - otherwise an attacker could just pull the token and move to another box. Depending on the token will depend on added features. Technically there is no standard requirement for PIN strength, length, history, or anything like that - these would all be features of the token's operating system to support these concepts, as well as using typically the manufacturer's own enrollment utility to set these values as most generic software will not have custom values like that.
I am not specifically familiar with other products, but I know that Datakey (now SafeNet) iKey 2000 and higher USB tokens support these types of features and are enforced by a template that is incorporated into the client software. This template is modifiable by the admin that uses the tool that helps create the client piece based on the options set. I'm sure other larger vendors have similar features too.
In short, only when the the token is initialized (formatted/wiped out) can other variables be passed to the token's OS - and only then. The only way to change the settings on the token would be to wipe it and start over.
How this is done through CLM, I'm not specifically sure. I have gone through the available options and such and am not seeing much relating to your concerns, even in CLM2007. At best there may be an .ini, .inf, or something that you can modify but that isn't what I would call a great answer to your problem, if you are worried about auditors.
Just to clarify. Axalto .NET v2 Smartcards came out this year and we just received delivery and yes Gemalto manufactures and sells them, but for legacy and driver reasons the cards still register as Axalto cards. We bought both GemPlus Shell Tokens and Axalto Cards from Gemalto, hence the use of the Gemalto CCID driver for the shell token.
I have a ticket open with MS and am in the process of opening one with Gemalto. I just thought that this question must have come up on somebody before, since it's quite obvious from an audit standpoint. The funny thing is, that nobody knows how CLM works in detail, not even at MS and there are no security whitepapers on the whole shebang, only installation and configuration instructions in the tech net. Not a single word on PIN management there (MS refers to the Minidrivers manufacturer for responsibility, and this is why Apple works so much better than MS, they can't just push responsibility away)
I guess I'll have to wait for Gemalto's response.
OK, here we go
It is just like Paranormastic said, it just took some time to realize the value of his first paragraph.
Where
The Attempts remaining value is stored on the token.
How does it get there
It is stored ther at factory initialization. CLM does NOT control this setting via its templates. Gemalto's web service offers changing this value, so it is indeed a minidirver implementation issue, where it is implemented but with the tools we use, we lack a back end.
The PIN
4-14 digits, no complexity. period.
If one wants to change this behavior one needs a .NET program on the card controlling the PIN change, or different middleware. Again out of the possibilities of the tools we use.
So we need a different solution to satifsfy the internal audit.
Fortunately we are still working on eval licenses with a first batch of tokens.
Thanks all for participating!
And by the way, my bad, it was CLM 2007 not 2003.
Business Accounts
Answer for Membership
by: lamaslanyPosted on 2008-08-14 at 10:13:27ID: 22232158
I've only recently started looking at smart cards so there is a good chance I'm off base but are you sure that the pin attempts count and threashold isn't held on the smartcard itself?