On Sun, 28 Nov 2004, Tommaso Cucinotta wrote:
Date: Sun, 28 Nov 2004 20:01:21 +0100 From: Tommaso Cucinotta <[EMAIL PROTECTED]> Reply-To: MUSCLE <[EMAIL PROTECTED]> To: MUSCLE <[EMAIL PROTECTED]> Subject: Re: [Muscle] [Patch] - Do not list objects/keys not usable by the currently logged in identities
And not to mention the free-memory information in GetStatus: are we going to reveal to unauthorized users the precious information about how much "secret" data is stored onto your card ?
You are right!
The original semantics of ListObjects, ListPINs, ListKeys and GetStatus is just to give information on how much resources are occupied on the device, as a **public** information, whatever the privilege of the current session is.
If the only reason is to find out about how much space is left on the device, then I see a solution:
* Add an ACL for those commands. Identities allowed see ALL the information. Otherwise only the information about accessible objects and keys is shown. This ACL must be set at setup time/can be set only once to not change the setup command. This would allow the applet to behave as it does now and still allows for more secure operation.
If we start going through access control also for this kind of commands, possibilities are endless, and, as usual, complexity increases.
Well, complexity can be managed, I do not see too many changes.
I would suggest to not apply that patch in the "main" branch of the code, so to retain the original behaviour (which is also documented). The patch may be made available as a separate download for whoever needs that other kind of behaviour. Of course, unless so many people need this new kind of beahaviour .........
Hmm, for me this looks as if this has not been thought of before. Thus I would rather discuss the matter and its security implications than to just leave it as it is (because it is documented). Bug-compatibility often is a GoodThing (r); it definitly isn't if it has possible security implications.
If I have learned one thing about security and cryptography (being a complete non-cryptographer), then it is that even the slightest bit of information leaking out can be the key to break into an otherwise secure system in unexpected ways. And smart cards are actually designed to keep information secret.
If only java had a preprocessor, then the compilation could be either tuned towards the current behaviour or a more secure one (an #ifdef here, an #ifdef there).
Perhaps a better way to look at it would be: What kind of applications need the current behavior for proper operation? Some possible answers are:
* None - then there should be no problem changeing the behaviour (AND the specs)
* One or only a few - The question is then: Why? Can these be fixed? Is the assumption true that those applications have to be compatible with newer versions of the muscle applet? Is there something wrong with the assumptions those applications use?
* All - then I am wrong. But it should still be thought about.
Bye,
T.
Peter Williams wrote:
----- Original Message ----- From: "Peter Stamfest" <[EMAIL PROTECTED]>
To: "MUSCLE" <[EMAIL PROTECTED]>
Sent: Sunday, November 28, 2004 1:10 AM
Subject: [Muscle] [Patch] - Do not list objects/keys not usable by the currently logged in identities
Hello,
This patch changes the applet to only list objects and keys the currently logged-in identities have access to.
You argued that the enumeration is sensitive, because it releases information the logged in identity is not entitled to.
If we accept this, should a user with read only access have visibility on the other identities who have write access?
Should a user with pin-based read rights be able to assert these to learn that an object requires a particular strong authentication key, or #15 bio id?, for writing?
Good point. I do not have a simple solution. I briefly thought about it before I sent out my patch, but could not come up with a consistent solution. However, I think that using my patch is at least better than the current situation.
I definitly do not like the following possibility: Mask out the ACL bits not belonging to a logged-in identity.
Should a user with pin-based read/write rights, but no strong strong authentication rights, be able to assert these to learn that an object requires a particular strong authentication key, or #15 bio id?, for writing?
dito
Maybe one possibility is to not include ACLs at all in list and status commands... but that is not a nice thought, either.
peter _______________________________________________ Muscle mailing list [EMAIL PROTECTED] http://lists.drizzle.com/mailman/listinfo/muscle
