Il giorno ven, 23/07/2010 alle 15.09 +0200, Viktor TARASOV ha scritto: > resoli - libero wrote: > > Il giorno lun, 21/06/2010 alle 11.05 +0200, Viktor TARASOV ha scritto: [...] > 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'" .
Yes i saw the related configuration entries in etc/opensc.conf.in > > 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, ... Ok, this makes sense to me. > > 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. I am with you ... > > If it is not used, how CWA 14169 "secure path" and "secure channel" > > requirements, (CWA 14169 is referred by [2]) are being satisfied? So maybe Emanuele interpretation in another message[1] here is right: "Which is the idea in CWA 14890-1, as far as I can tell, paragraph 8.2: the card holder decides whether the environment is trusted or not, and if it is, the path is already trusted, without a need for secure messaging. The examples of untrusted environments are limited to signing application and SSCD being in different physical locations, or biometrics." And so the classical environment "User's home PC with his own card and reader" is to be considered "Trusted". This interpretation seems even more valid looking at "Figure 8 - Interaction sequences between SCA and SCDev" in Chapter 14.1 of CWA 14170:2004 [2] , in which usage of SM is recommended only if SCA is not under signer's control, and even there "only if level of confidence is not achieved with organisational means" And, even strongly, in chapter 15.1 : "Since cryptosystems with symmetric keys may not be suitable for performing the authentication procedure due to key management problems and security risks, public key based authentication procedures should be applied as shown in Figure 10. " That is, (central box in Figure 10) "Perform mutual authentication and compute session keys for Secure Messaging (SM) " So, even when SM is required, use of static keys seems strongly discouraged in Signature Creation Applications. ... > >> 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. Nice to hear, I hope someone out there is hearing as well ... bye, rob [1] http://www.opensc-project.org/pipermail/opensc-devel/2010-July/014538.html [2] ftp://ftp.cenorm.be/PUBLIC/CWAs/e-Europe/eSign/cwa14170-00-2004-May.pdf _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
