Hello, On Aug 29, 2011, at 10:02 , LinuxChuck wrote: > Allow me to start by announcing that I am new to PKI smart-card > management with OpenSC, and have only had experience working with > Aladdin eToken devices and their proprietary middleware. However, I > am fairly well versed in the concepts and fundamentals of PKI in > general. Great!
> 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]. > - 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 have OpenSC and Linux compatible card readers (SCM SCR3311) in use > and working on the Linux systems. Our Windows systems will be using > built-in card readers that are fully functional in Windows. See above. Aim for well supported CCID/ICCD devices. If unsure, ask for samples or test. Device firmware (if different versions exist) might be important. > - I would like the ability to use a 3rd-party application (PKCS#15 > compatible) to store a small piece of data on the card. (This is a > Windows application, and will only be used on the Windows systems) PKCS#15 is mostly for *using* cards (meaning looking up information) rather than writing. If the data format is uniform and defined by PKCS/ISO, getting the structure to the card might be slightly non-standard or proprietary. > - I intend to develop (read: throw together) a small front-end web-UI > to the CLI tools to ease card management for some personnel involved > in the initialization and management of the cards. (I'll stick with > the CLI myself) Maybe start OpenTMC (Open Token Management Center) effort ? :) Something that would also deal with secure messaging key management issues etc. Have a look at EJBCA, Dogtag and Hardtokenmgmt. > - I would like to ensure there is enough space to store more than one > certificate, plus the extra data used by our 3rd-party app. I believe > the 3rd party app simply creates an object containing a hash or key of > it's own, and is relatively small. 2048 bits max. We had to upgrade > our 32k Aladdin USB tokens to the 64k versions to allow for full > functionality of the built-in OTP and PKI functions with 2048 bit > keys, so I am working off of the concept that 64k should be the right > amount of minimum memory to shoot for on this chip as well. It should be possible. You can quite easily have at least 10 key pairs with certificates [2] 64 is fairly common these days, better cards have 128 and more KB of EEPROM. > - The vendor has indicated that the built-in OTP function of the card > can have the OTP seed programmed through the contact chip. Is anyone > familiar with this? Is it something I might be able to do through > OpenSC, or will that require some other application? You can send arbitrary APDU-s through OpenSC but that's not what OpenSC is meant for. OpenSC is for (PKI) crypto cards. Assuming the control commands are few, short and simple, OpenSC low level tools will help just fine in that matter. > 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? > - 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) > - 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 know some of the functions above are firmware related, and others > are chip (hardware) related. I am *positive* there are some areas I > haven't thought of yet, and would truly appreciate any and all input > concerning things I need to consider before moving towards a solution. [1] http://pcsclite.alioth.debian.org/ccid.html [2] http://www.opensc-project.org/pipermail/opensc-devel/2011-February/016064.html [3] http://security.stackexchange.com/questions/5060/what-is-gained-by-hashing-the-last-block-on-device -- @MartinPaljak.net +3725156495 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
