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. 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.
> - 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. 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.
> - 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".
> - 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).
> - 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.
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.
Thanks!
--
Emanuele
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
