On Sat, 27 Nov 2004, Peter Williams wrote:
Date: Sat, 27 Nov 2004 06:28:53 -0800 From: Peter Williams <[EMAIL PROTECTED]> Reply-To: MUSCLE <[EMAIL PROTECTED]> To: MUSCLE <[EMAIL PROTECTED]> Subject: Re: [Muscle] pkcs11: Strange code, what does it mean?
I'm not sure I fully understood everything in its entirety, but after thinking it over a couple of times I'll try to answer anyway:
(1) Adding delete key to the dispatch table is a trivial task. but there is still no assurnace (to the applet programmer) that the garbage collector has run, or that the Common Criteria "object reuse" security requirement is yet satisfied. This assurance only comes from system-level (versus applet-level) analysis.
What is wrong using the Key.clear() method and releasing the object afterwards? No need to think about GC. Key.clear() should overwrite the memory the key parameters were stored at. If it doesn't it is the fault of the card manufacturer. On the system-level I agree: Getting rid of a key can only be assured there: grind the card to dust and burn it afterwards.
(2) The applet can only be sensibly deployed in combination with personalization-time configuration, and system-level login. On an assumed multi-application card, do not assume the applet is in complete control over the security controller, hosting the javacard VM. in contrast. Assume the applet is exporting a cardedge to a system of applets on the card. No not assume the applet is a FIPS 140-1 cryptomodule, nor assume it is a PKCS token object, in its own right. It needs support from other applets, and issuing procedures to play that role.
Obviously the life-cycle of the applet has to be taken care of. In a setup where this has been dealt with, the applet still gives away information it should not.
(3) its quite hard to obtain commercial javacard VMs that do not insist on GP authentication to the card manager applet, during post-loading personalization. Whether a card issuer then allows the applet to export the cardedge over the GP association, or not, depends on the intended deployment parameters. Obviously, the level of authentication required to deliver an TPDU to the applet's command dispatcher is controlled by the GP security domain admin, not the applet.
And that is not what I was talking about. GP card manager security has to be dealt with - agreed. It is the applets responsibility to act safely when it deals with its own matters. The nice thing about the Muscle Card Edge is that it does not have to take the card manufacturers mechanisms into account - the issuer deals with it and assures that the card edge can be communicated with. The issuer also takes care of setting up the card and the applet so that the applet cannot be deleted, other applets can only be installed by the issuer (or somebody controlling another security domain), etc.
The card edge then is the thing to deal with, not the GP card manager. That has already been secured.
(4) The applet is a little dated in its orientation towards pin, reflecting first generation javacard platform ideas, which had no GP support. What you have to remember is that its older techniques, optional component integration, and its source nature means it satisfies 80% of the need, and 80% of the integration requirements at no IP cost, and at no developer tool cost. Given the tool chain to a billion Chinese and half a billion Indian people, perhaps 10000 developers might make good use of it! A serious deployment is of course expected to fill in the 20% by providing system-level assurances, not limited to adding coding to suit the application requirements, adding national ciphers, etc.
Well, OK, but would you use SSH if the SSH guys told you: "Well, we sort of implemented public key authentication, but in its current state everybody can log into you account anyway. If you use it it is your responsibility to deal with it and fill in the missing code." - I guess you would not. You would use something else.
So even if the argument is understandable, it is still an excuse.
(5) I only skimmed the PKCS#11 support - having little interest in modern PKCS-11 design motivations, personally; What I saw, I liked: it indeed seemed "highly-tuned" to the original PKCS-11 goal - interfacing the API consumer to the hardware cardedge. It did not appear tuned to the alternative mission, of constructing a full, PKCS-11 token object lifecycle support layer. This might explain issues like API-provided handling of private keys. Who cares what the API mapping code does: control of delete/release policy is on the card, and in the card management system - not the programming/integration API, and not in the application. Don't assume the applet is focused on the Netscape (i.e. Windows) hyptothesis about PC platform security management. And dont assume the PKCS#11 motive is intended to supplant PC/SC, or a CAPI layer; it might just be an API mapper.
It is an API mapper, but it is a standard API wrapper. Thus it should be usable to do things in a standard way. And storing stuff declared to be private in a publicly accessible way is not the right (=standard) thing to do. AND the applet itself does not properly hide private data. And looking at my patches I just sent out: It was not Netscape/Mozilla that did it wrong - the PKCS11 module is/was buggy....
(6) There are some security policy objects that are discosed in the cardedge spec, that never made it into the public applet implementation. Adding these would be useful, providing operation-level privileges support, for enhanced app(s)<->card(s) control signalling. Given PCSC v2, a little upgrade might be in order, taking 5% kernel of the PCSC v2 initiative that is quite trivial to provide, and which provides 50% of the enhanced functional capabilities.
I have to admit that I only quickly browsed the cardedge spec and that I have not taken a look at PCSC v2.
Given the patches I just submitted, I am now more towards using the muscle applet for real work. The PKCS11 module has to be investigated further, though. Await more patches from me.
peter
----- Original Message ----- From: "Peter Stamfest" <[EMAIL PROTECTED]> To: "MUSCLE" <[EMAIL PROTECTED]> Sent: Saturday, November 27, 2004 12:13 AM Subject: Re: [Muscle] pkcs11: Strange code, what does it mean?
..
Currently, I have my doubts that the musclecard applet and its pkcs11 module can be used seriously. The applet misses some functionality (eg. deleting keys, the list keys and list objects commands give out information about keys and objects without prior authentication), and (sorry) the code quality of the PKCS11 module is questionable.
I am willing to contribute to fix those shortcomings (if others perceive them the same) as far as my (very limited) time permits.
OTOH, I may be wrong completely and have misconceptions about the topic, which might be the more likely alternative anyway. ;-)
peter
_______________________________________________ Muscle mailing list [EMAIL PROTECTED] http://lists.drizzle.com/mailman/listinfo/muscle
