(The CSRC website was unavailable since yesterday, but came back online recently.)
(1) Per our discussions, the host driver module accessing musclecard services may be programmed to externally authenticate, using TDEA keys, to the card, before being granted access to its services. The host driver may be a "cardreader", note rather than your PC, particularly if its a CCID-class USB reader supporting APDU-mode 7816-3 behaviour.
In the cited PDF, see 4.1, role "Application Operator".
(2) Note how, unlike musclecard, in the ActiveCard policy its the Cryptographic Officer who owns the keysets of the security domains. In the musclecard case, keysets can be owned by either the party playing the CO role, or the party acting in the CardHolder role. This important distinction affects key management controls, during manufacture and personalization of musclecards.
(3) noting 4.4.1 and 4.4.2, there are different XAUT keys for accessing different methods on the cardedge, distinguished by role. Mapping onto muscle cardedge, we could say that "the Application Operator (i.e. host driver) uses one XAUT TDES key to access any data file, with an acl requiring proof of possession of said TDEA key." This AO role is distinct from the cardholder role. Cardholders are only ever identified/authenticated using pins, and thus cannot ever read data files with XAUT authentication requirements set: these are only accessible to AO role parties (i.e.. host drivers).
(3 comment) Perhaps we should try and determine why that distinction was made: i.e. why one role present on the host computer can access data files, but the cardholder cannot so access their contents, by policy formulation. What's in those files? one naturally asks.
(3 discussion) We know that the files subject to the policy comment (3 comment) distinguish the TL and the V of BER-encoder TLVs. I.e. the tags and lengths of the PDV stream are in one file, under one TDEA key obligation, and the Vs are in another, under a distinct TDEA presentment obligation. We also know, that there can be multiple[le instances of the file manager applet, each with different TDEA key presentment(s), requirements. This suggests that there can be more than instance of the AO, surely? We should investigate the background to this, to apply to musclecards, if appropriate.
(4) Only the CO should have the TDEA key to externally authenticate to the pin unblock method, for a cardholder who is locked out. This TDEA key is distinct from those used by the AO(s). This seems a natural distinction to make, and the assigning the function to a CO role is natural.
(4 comment) When a CO owns the VOP 2.0.1 keysets, perhaps the same CO should not also own the TDEA keysets for pin unblocking. A separation of duties seems appropriate, here.
As we understand these policy examples, this can help us design "full-featured" drivers/plugins/channels to musclecards, that fully exploit all its capabilities based on using XAUT keys appropriately.
----- Original Message ----- From: "Peter Williams" <[EMAIL PROTECTED]>
To: "MUSCLE" <[email protected]>
Sent: Thursday, March 10, 2005 7:36 AM
Subject: Re: [Muscle] muscle getChallenge, versus GP 2 way authentication
----- Original Message ----- From: "Karsten Ohme" <[EMAIL PROTECTED]>
To: "MUSCLE" <[email protected]>
Sent: Thursday, March 10, 2005 5:12 AM
Subject: Re: [Muscle] muscle getChallenge, versus GP 2 way authentication
>>> Are there any other roles vs key usage models I'm missing, for theapplet security policy?
For example, should any offcard application be required to use a DES3-MAC key, to externally authenticate, in order to perform ANY operation - such as populate user certs?
I think this wouldn't be comfortable. Because the smartcard should simplify the signing, log in, ... If I have to know a PIN this is enough. Maybe it is desirable always to have a secure channel (This would be the only reason I see to use a secure channel), but in this case every user has to know a PIN and a 3DES key. Nobody can remember a 3DES key, which is at least 16 bytes. So the idea to go to every computer and use the card would be not possible because I would have to have another media with me which contains this key. Or a always available server with this key must be. And I have to take care which computer I can trust to enter on it this key.
I think we have to distinguish between the user role, and offcard entity role. These are non GP roles, and are not discussed in the GP security policy model disclosures.
Lets assume users apply pin logon to establish user rights. (Lets assume these rights are piss poor in the telecom world, if we believe Scott, presumably so limited by design in order to enable covert surveillance via compromised key management, or facilitate the loading/installation of deception applets.)
Lets also assume the ASM role authorizes which host software is authorized to communicate remote operations to the applet. Assume this is accomplished by limiting which host drivers have the relevant XAUT key, enabling one to logon with strong authentication to the applet, using the applet's own authentication, access control decision and enforcement mechanisms (i.e. not GP). Assume the driver is distributed in hardware module, and OCF provider knows who to access the hardware (perhaps another smarcard, in quad flip pack package). In the .NET world, perhaps this is a custom remoting channel, smilarly, where the role played of this XAUT is offloaded to TPMs.
Does this sound more reasonable, now?
Its not the user who is burdened with the XAUT key. Said key is in one of the many SAMs, in the multi-service-provider public phone terminal, the ATM machines, or the phone's motherboard, etc.
Bye, Karsten _______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
_______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
