Edited a bit for brevity... On Mon, Aug 29, 2011 at 11:59 PM, Martin Paljak <mar...@martinpaljak.net> wrote: >> I'm in the process of preparing a migration from Aladdin USB eToken >> (CardOS 4.2) PKI tokens to credit-card contact chip PKI ID cards with >> built-in OTP functionality. The vendor has provided me with the >> specifications for the chips (Infineon SLE66C44PE_0105) which are >> CardOS based. > Most of the time, from OpenSC perspective, the actual chip will be irrelevant > as you will be only able to do what has been exposed by the on-card software > through the API it provides through APDU-s. For that matter, it could be an > ARM9 or caasua x86 chip. > >> Here is some information and a few requirements as I can think of them: >> - I've already validated that the electronic interface will work with >> our existing card readers (integrated, and USB). > Ask for CCID/ICCD which is supported by the open source driver [1]. > That's exactly the sort of advice I was looking for. Thanks! I've forwarded a few more questions to our vendor to get answers to some of these items.
> >> - We use 2048 bit RSA keys from certificates generated on an Active >> Directory (yeah... I know) 2008 R2 infrastructure, and imported onto >> the cards. > The keys are also generated by AD, or just the certificates? Go for onboard > key generation if possible. > I can be flexible here, but at the moment, AD generates both. Most of our linux servers generate their own certs via OpenSSL, and they just get signed by our AD CA. However, these cards will only deal with user certificates, and eventually allow SSO capabilities via certificate-based logon if I can get everything right. We're already doing that with our USB tokens, so I'm hoping the implementation here will be the same. > >> Here's what I know I need to tell the vendor based on things I have >> researched from OpenSC sources and my own experiences so far: >> - I need the chips blank, not pre-initialized. >> - I need to know what version(s) of CardOS are available for shipment >> on that chip > Why do you insist on using CardOS? > Because it's what I'm familiar with, and one of the only ones I know for certain already work with our existing systems thanks to the Aladdin eToken USB NG-OTP tokens we implement. As it stands now, I have a fully linux-based solution in place to program the tokens using provided API example code, enroll them in our RADIUS server, assign them to users, and add the user's AD certificates to them in almost one fell swoop. If there would be an easier/more flexible/better route to take, I'm certainly open for suggestions. But my requirements are as follows: - All-in-one HOTP Event-based OTP + PKI contact-chip + RFID + ID Card solution. - Ability to re-seed the OTP function is essential. I don't like using factory-provided seeds. - I would like to be able to add a data object via McAfee EEPC to the cards to use them for booting encrypted laptops. My largest concerns are: moving from my now-familiar USB programming environment which uses the Aladdin middleware to this contact-chip environment with no 3rd-party middleware. I have no real experience working with this interface directly. (And to be honest, my current USB programming system is a hacked together set of php scripts, C programs, and shell scripts.) I'm hoping to leverage the abilities of the opensc/pcsc linux utilities to initialize, personalize, and maintain these new cards. >> - I need to have 64k of memory available for certificate and object storage >> - I need the chip to support 2048 bit RSA keys, and SHA1/SHA256 message >> digests > Hashes can be computed off-card. Support for "last round of hashing on the > card before signatures" [3] is not supported (needs code) > >From the data sheet the vendor sent me, it claims: 68-Kbytes User ROM, 2304 Bytes RAM, 4-Kbytes EEPROM Dual Key Triple DES Transmission protocols T=1 and T=0 32 bytes security area (OTP) (tons more, but I won't spam the list with it. I can email you a pdf if you'd lke to see it) I believe the 68K is the primary certificate storage location, but correct me if I'm wrong there. The on-board cert generation capabilities aren't clearly stated from the chip perspective, but I believe that should be a function of the software where the hardware would provide acceleration capabilities for it. Again, I'm very new to this, so please push me in the right direction if I'm making mistakes. > >> - I need to know what SDK, emulation/simulation options are available >> for the chip for further development and testing > > If you go for a SDK from a vendor you'll be often bound to that SDK (and that > vendor). Use standard API-s. > I'll take that to heart, thanks. I truly appreciate the information so far, and look forward to any further advice, suggestions, or comments. _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
