On Mon, 29 Nov 2004, Peter Williams wrote:
Date: Mon, 29 Nov 2004 20:56:24 -0800 From: Peter Williams <[EMAIL PROTECTED]>
----- Original Message ----- From: "Peter Stamfest" <[EMAIL PROTECTED]> Sent: Monday, November 29, 2004 11:22 AM Subject: [Muscle] Questions regarding the Muscle cardedge protocol
Hi,
as you may have noticed I'm snooping around quite a bit...
good! I dont think much has changed from 2001...
All we really have to do is add an IDL descriptor for every stream and method , and indicate non-support for 28 bio formats that the the card doesnt support, and it will be updated to match the GSC-IS grade of functionality! Then we charge the US govt $50 a card, via a defense contractor, on the grounds that the lab version was evaluated as compliant with the procurement offices protection profile (version 2001).
To be serious, what I find wonderful about the applet is its sheer economy - in doing 80% of what anyone wants from a cryptocard: all on a $4 USB chip, with 3 very simple packages that have required no maintenance in 3 years!
I agree with that "economic" side, yet I still would like to have something "better".
By only supporting partial API mapping of PKCS#11 (versus the full object model), the 80% function address the major personal security application that anyone actually uses today, on PCs.
I am on your side, actually. I do not want to have 100% support for eg. PKCS#11 just for completeness, I want something else: I want something that is "secure by default" with no security implications because of either backward compatibility or because of design faults. And it should work with relevant software. My recent patches are all dealing with "design faults" (not saying that anybody involved with the design did anything wrong - "commercial" designs are often much worse) not towards extending the functionality.
Still I wonder: Why the insistance on doing only 80%? If that was the position of the entire open-source world we would be 100% MS now at the level of Windows 98. No Apache, no Linux, no Samba, no <name-your-favourite-open-source-project> - I doubt the internet would exist in its current form. With an attitude like that, the Muscle project will not be used for serious work in a larger scale. And everybody on a tight budget but still security-concious will either have to find funding to buy "the real thing" or will have to become a smartcard guru (and rely on his/her own non-standard implementation, that has not been reviewed by anybody else).
For me this means: If a problem pops up, it has to be solved, not negated by saying: Well, you have 80% of what you want - add the other 20%.
Therefore, I propose the following changes to the Muscle world:
* Add one ACLs for every one of the ListObjects, ListKeys, ListPins and GetStatus commands
* Change the Setup command in a backward-compatible way:
1) Allow for two-byte ACLs for CreateObject/CreateKey/CreatePin (for
completeness).
2) Allow to add two-byte ACLs for the ListObjects, ListKeys, ListPins
and GetStatus commandsThis means that three forms of the Setup command would co-exist (all differentiated by the length of the data sent):
* The current form: If there are three bytes left over after the unblock
pin #1: three one-byte ACLs for CreateObject/CreateKey/CreatePin
* The extended form: If there are six bytes left over after the unblock
pin #1: three two-byte ACLs for CreateObject/CreateKey/CreatePin
* The full form: If there are more than six bytes left after the unblock
pin #1 and the number of bytes is an even number: The first six bytes
are two-byte ACLs for CreateObject/CreateKey/CreatePin, then follow
ACLs for ListPins, ListKeys, GetStatus and ListObjects (the order
being defined by a loose concept of "badness" if unwanted information
leaks out.In all cases: The proposed ACLs have a default value of 0x0000 to be backwards compatible (Though this is debatable in a "secure by default" design).
* How should these ACLs work, I hear you ask?
If a command guarded by an ACL gets executed, it will return the following information:
* If the logged-in identities are granted access due to the command ACL
then return all the information (just as it is done now).
* If the logged-in identities are not granted access due to the command
ACL, the command only returns information about objects/keys/pins
"related" or "accessible" by the logged in identities.What is left over to decide is: What ACLs information should be returned for those commands guarded by an ACL? I would do it the unix way: If you have read-access to a directory you will know the access rights of others as well. Thus object and key ACLs get returned the same way as done now.
Also: Should there be a way to query/change the command ACLs? I would lend towards a clear "no", but there might be a reason to do so. How should such a command be guarded?
If David (or however is in charge of the specification) is OK with this, I will happily implement those changes in the applet. They are not huge changes, AFAICT.
What I do not have time for is the writing up of information for the deployment of a muscle based card. This, however, is very important to have. I fear that many users of the Muscle applet have no real idea of how to deploy it. That is: Set up the card in a secure way (that is, use the Global Platform mechanisms) so that the applet cannot be removed and reinstalled with different keys/certificates by an attacker getting hold of the card or the system the card is attached to, download and initialize/setup the card applet, setting the correct ACLs, etc. If anything like this already exists: good, but I did not see it (yet).
So what do people think about the proposed changes? Let me repeat: These changes are backwards-compatible to the current behaviour. They require a little more code and some 11 bytes more of card memory for ACLs.
[...]
peter _______________________________________________ Muscle mailing list [EMAIL PROTECTED] http://lists.drizzle.com/mailman/listinfo/muscle
