On 12.03.2011 16:20, Emanuele Pucciarelli wrote:
> Hi!
>
>> It's on my conscious .
>> I have a strong intention to start this work as soon as possible .
> I would like to collaborate on this.
It would be very appreciated.
> My hidden agenda [ ;) ] is to
> make this happen in such a way that this work can be used by the
> "itacns" driver as well, and possibly by other present and future
> drivers.
>
> The requirements for "itacns" are very simple; there is one RSA keyset
> that mandates the usage of a fixed-key 3DES SM enc+mac scheme for PIN
> verification/changing and for using the key. That is all.
>
>> There are few specification items, that imho should be present in this
>> future implementation :
>> - common crypto library for dnie and ias/ecc (ias/ecc specification has been
>> partly inspired by prEN-14890 standard. Afais, it's the same as cwa14890) ;
> It would be great to layer this upon "basic" ISO 7816-4 SM support, so
> that it can be used by simpler cards too.
I guess you have a reason.
>> - two SM modes:
>> -- 'apdu' (or pcsc) mode (roughly the same as you implement in your driver)
>> -- 'acl' mode where particular ACL initiates the using of SM ;
> I shall now try to rephrase what you are saying. Please correct me if
> I got it wrong, as I am quite sure I got it wrong. :) This should
> relate to how the upper layers (PKCS #15 emulators and card drivers)
> trigger the usage of SM and set its parameters. Some card drivers
> would handle this without exposing the functionality to PKCS #15,
> hence "apdu" mode.
Yes,
libopensc and the upper levels do not suspect existence of SM and
APDUs are wrapped/unwrapped at the apdu transmission level (like in the 'dnie'
patch of Juan Antonio) .
(The dedicated callback from the card driver allows to filter the APDUs that
have to be sent in clear.)
> Some other drivers could trigger SM usage, and
> possibly the setting of specific parameters too, by way of specific
> ACLs as seen by the PKCS #15 layers.
Initially this mode was conceived to reduce the transactions with the remote
entity that holds the keyset and can securize the APDUs.
For example, when importing PKCS#12, only five/six APDUs 'STORE DATA' are
really need to be sent in SM. The rest can be 'generated locally'
and be sent in clear.
Now there are also the cards (like IAS/ECC) that can have multiple keysets .
Which operation, on which file or object is protected by one or another keyset
is getting known only from the ACL of this file or object .
>> - driver specific callback to filter the APDUs that cannot be used in SM
>> mode (for example, for some cards the 'SELECT' command cannot be done in SM);
> So, the card driver would have a "filter" callback that would be
> called when the APDU is ready to be transmitted. The driver would then
> be able to return a value communicating its own "yes, go ahead and use
> SM for this", or "no, skip the SM transformation".
Yes, something like this .
>> - multiple keysets, they can be defined on the global and on the local level
>> (inside of one of the on-card PKCS#15 application);
> Sure thing. IIUC, "global" means "provided by the driver itself",
> while "local" means "provided by the upper layer" (almost surely PKCS #15).
Not exactly,
I mean the 'visibility' of the keyset, like a visibility of 'PIN'.
'Global' is visible from every where in the card system.
For example the Global Platform keysets of the Java cards, that can be used
inside the (PKI or other) applet (it's the case of Oberthur's cards)
has a 'global' visibility. In the IAS/ECC card case it's the keyset defined at
the MF level.
'Local' keyset is defined inside one of the on-card PKCS#15 applications (for
example for IAS/ECC card
the keyset that protects the Qualified Signature, SignPIN, etc.)
>> - dynamically loadable SM modules, configured with the OpenSC config files .
> As Martin mentioned some time ago, in addition to loadable SM modules,
> it would be great to also maintain the capability to embed them in the
> main binary itself, statically linked – at least for those that are
> distributed with OpenSC itself.
Yes, why not,
the main idea of the dynamic modules is possibility to externalize the
manipulation with keysets and protection of APDUs.
In my practice we used the keysets on the remote server, for the development
and debugging it's useful to work with the 'local' keysets.
> I am wondering whether it can be useful to implement this with a
> "transformation stack" concept. I'll try to clarify this.
>
> Let us think of a function type:
>
> int (sc_apdu_transform_cb_t*) (sc_card_t *card, sc_apdu_t *apdu, bool
> response)
>
> A card driver could define two static functions, sm_transform() and
> envelope_transform(), and declare an array:
>
> const sc_apdu_transform_cb_t transforms[] = { sm_transform,
> envelope_transform, NULL};
>
> The apdu.c code would be able to call sm_transform() and
> envelope_transform() in this order, with the "response" parameter set
> to false, before transmitting the APDU, and in the reverse order, with
> the "response" parameter set to true, after receiving the response.
> (It would be probably advisable to prepare data structures to keep
> multiple APDUs and specify what response is expected after
> transmitting each.)
>
> These two functions would be able to act as a filter and to invoke the
> proper SM transformations, after checking both the APDUs and the
> internal state in the sc_card_t structure. Of course, ACL
> considerations should take place when checking the internal state.
> Also, it would be possible to provide "general-purpose" transform
> functions to be invoked by these filter functions (something like
> encode_apdu(apdu_pointer, ALG_3DES_ENC_SIG, key_pointer) ).
>
> Of course, these functions should in turn be able to issue commands to
> the card and get responses before the transformed APDU is processed
> (I'm thinking of GET CHALLENGE and friends).
>
> I am, of course, willing to help with coding or start coding
> altogether when I get a clearer picture but I would really like to
> exchange a few thoughts on a sensible architecture with all of you. I
> am afraid this is over-engineering it a bit, but on the other hand I
> would like to make it easy to let all drivers use this SM framework.
> Possibly there is some simpler way to do it that would provide the
> same level of code reuse.
I also need to get a clearer picture.
Probably we should create 'SM' dedicated wiki page and there to resume the
specifications
and architectural approaches .
> Thanks!
Kind wishes,
Viktor.
--
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
