Hi Greg, > My question is: what does the support for this card look like today, > and what can I do to help develop it. I'm new to smart cards and to > opensc, but I've spent a lot of time reading through the ACOS5 > documentation and about smart cards in general. > > I feel confident that I could develop the code if I had any idea where > to start and what needs to be done to make this card useful on the > non-Windows platforms. If anyone can help get me started, I'll be > happy to get the project complete and contribute a patch back.
wow, great! I will try to help the best I can. in general cards need a low level driver with functions like "create this file, write this data, etc." and high level functions that decide how to implement something, and a profile how the structures should look like at the end. the current code can be simply deleted / not much in there. if you look at well working drivers like cardos of flex, you will see the same basic skeleton there. IIRC the acos5 cards are a bit special, since in manufacturing mode no access control is enforced. one way to handle this would be to create a main folder with a key to protect it and put the card in operational use. thus at first every pkcs15-init would need that key. this would be similar to the cryptoflex transport key mechanism (a special card key that can be used to erase a card, even without knowing the PINS in the pkcs#15 profile). cardos also has something like that, they have the startkey, packagekey and systemload key or something like that, three special vendor keys that can be used to format the card and to upload firmware etc. maybe this could be implemented in some tool, or directly inside opensc. once that is done, opensc would do normal pkcs#15 create work: create file 2f00, create directory 5015, create files and directories inside that directory, create pin objects and rsa key etc. but this would be quite similar to the other cards I guess, and can be written down from the manual I hope. what do you think? I think the hardest part is to get started, i.e. create some MF with a secure but functional setup. once that exists, it will be much easier to start from there. a dummy driver could implement all functions with something that creates a debug entry and returns an error code. that way one by one you could see which function is called, the parameters, and slowly implement what is needed. but I haven't written a full driver from scratch, so I guess other people have much better advice. Regards, Andreas _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
