resoli - libero wrote: > Il giorno lun, 21/06/2010 alle 11.05 +0200, Viktor TARASOV ha scritto: > >> resoli - libero wrote: >> >>> This thread is really interesting looking from an italian perspective. >>> >>> Viktor mentioned the fact that in Italian CNS card PIN and signature are >>> secure messaging protected, as reported by Emanuele Pucciarelli that >>> created also some patches[1] to support that cards in OpenSC. >>> >>> Unfortunately the sm 3DES keys needed are static, and usually embedded >>> in proprietary pkcs11 libs, so no chance to have a true open source >>> implementation at this time. >>> >>> >> Static secret keys do contradict the open source implementation. >> The last one will provide the possibility to supply the keys knowledge to >> the middleware (the simplest way to look for it's values in the card >> profile) >> or to externalize the SM encoding of the APDUs (through the loadable >> modules). >> > > Are you referring to this part: > > "... > The main features are: > - 'Secure Messaging' and 'External Authentication' are performed by > external, dynamically loadable module. This relatively small module have > different implementations: > -- 'local' version have access to the keysets and used mostly for tests; > -- 'distant' version should communicate with some distant entity capable > to generate secured APDUs. (In our SCM application such a module uses > IPC to communicate with XPCOM extention of the application's XUL > client-side part. This last one, in its turn, uses XMLHttpRequest to > communicate with the distant server that has a knowledge of keysets.) > ..." > > of your original message[1] ? >
Actually, in the IAS/ECC branch of OpenSC there is an implementation of the 'local' SM module. The card supported by this branch are IAS/ECC (from Oberthur and Gemalto) and 'AuthentIC v3' from Oberthur, Two types of SM -- "IAS/ECC" and "'Global Platform protocol '01'" . > In that case, do you see any use case for the "distant" SM module by the > cardholder in normal usage (signing documents, for example) of the card? > There are some card profiles, where PSO_DST with 'Qualified Signature' key is protected by double factors: SignPIN and SM. (Imagine something like 'signing document in the presence of notary' -- SignPIN is up to user, SM belongs to the distant authority.) We use 'distant' SM for key renewal, recover, enrollment, PIN unlock, ... > Moreover, I'm rather curious about SM for digital signature outside > Italy; is it used at all? > > If yes, is it implemented in a similar fashion? (SM keys embedded in sw > libraries?) > I have no answer. As for me, there is no sense in SM keys embedded in the middleware. > If it is not used, how CWA 14169 "secure path" and "secure channel" > requirements, (CWA 14169 is referred by [2]) are being satisfied? > > >>> IAS-ECC specification describes a "Device authentication with Privacy >>> Protection" scheme[2] where sm session keys are negotiated each time >>> using a protocol similar to TLS. >>> >>> I have looked at the code posted by Viktor at >>> >>> http://www.opensc-project.org/svn/opensc/branches/vtarasov/opensc-sm.trunk >>> >>> and it seems to me that that part is still not covered. Is it correct? >>> >>> >> Yes, it's still under development. >> Before SM implementation, I would like to finish the 'common' support of >> the IAS-ECC card >> and test it with the actually available cards 'Gemalto IAS-ECC >> Multi-App' and 'Oberthur IAS-ECC v1.0.1'. >> It's roughly implemented in 'ACL' mode. In this mode SM is used when ACL of file or objects impose it. Still to be developed 'transmit' mode, where all APDUs are securized by SM at the transmission level. It can be useful to administrate 'remote' smart card, or for the cards where it's not possible to get ACLs for the crypto objects (like 'IdOne Classic' of Oberthur). >> If you are interested by the other IAS-ECC card you can send it me. >> My own interest is to make this support the most general . >> > > Many thanks, but i think that IAS-ECC adoption for italian ID cards is > only still an eventuality. I have no perception of any activity in that > direction at the moment. > In fact, any card that natively supports PKCS#15 and gives the possibility to get the ACLs of files and objects, can be 'easily' integrated. > bye, > rob > Kind wishes, Viktor. > [1] > http://www.opensc-project.org/pipermail/opensc-devel/2010-April/014063.html > [2] http://www.id.ee/public/l_17520030715en00450046.pdf > > > _______________________________________________ > opensc-devel mailing list > opensc-devel@lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel > > -- Viktor Tarasov <viktor.tara...@opentrust.com> _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
