----- 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
Hallo Peter,
Peter Williams wrote:Perhaps someone can correct my (recent) understanding of the functions of the external authentication support in the muscle cardedge.
(1) assume the muscle applet is placed on a GP card during manufacturing, prioir to setting the GP state to operational
Let me change (1): assume the load-file is stored on the card. I was lazy in my thinking.
(2) assume that the card issuer domain keysets are loaded onto the card during per-personalization, using a key Kinit, preloaded into the JVM binary.
(2) assume, for an operational state card, that the security officer role requires GP authentication, to logon to the card, using a card issuer domain keyset. Assume the muscle applet policy requires GP security channel at SCP 01 level 3 service level, in order to perform post-personalization commands such as populating root certificate stores
But this would also mean that this security officer has full rights on this card. Because everybody with the secure channel keys of the issuer security domain can do everything on the card, deleting, installation, key management, also in other security domains. That means that the SO is the card issuer and other application providers would depend on him. Should this be his role? Well, somebody has the be the card issuer.
I too feel that a seperation of duties is required, in the PKI wrld. Ive no real feel for what the visa cash world would require. And perhaps, the key management framework has all that is required for a cryptomodule application of the muscle applet. Let's analyse.
Assume entity P manufactures cards, from masks (with load files) supplied by I. (1)
Assume G unit tests and pre-personalizes cards, populating keysets of card issuer domain. Set export strength bits for I to limit strength of applet instances use of API accessing crypto co-processor. (2)
Assume G installs applet and security domain instances (referencing loadfile), and sets GP state, using card issuer domain rights, as enforced by GP module (2'). Ignore the GP level pin service; doesn't exist..
Analysis: G may NOT have the initial pins or XAUT keys of the applet, given these are populated via the applet's loadfile. So G does not have "full rights", even though he has card issuer domain keyset access.
Perhaps this is the cute way of creating the duty seperation.
In the muscle world, there is of course the TC pin (used in the format command), which gates all the arming of the command dispatcher. It is (of course) set at compile time, and hard coded into the package's loadfile.
I had always assume this TC was for traditional usages of TC control the transport and distribution of card, prioir to personalization. Perhaps it has a more subtle role to play in duty seperation, as we are discussing
(3) assume that applet security manager (ASM) is a FIPS 140-1 role distinct from SO, and user.
(4) assume that users logon to cards using pins, to satisfy user identification.
(5) assume that ASM role parties logon to the applet using the MUSCLE getChallenge, and MUSCLE external authenticate.
(6) assume that certain muscle acls require (5), whose logon establishes the "strong authentication" privilege set for that logical channel
(7) assume that the signing algorithm used in (6) external authentication is DES3-MAC, referencing a MUSCLE DES3 key, in one or other muscle instance's keystore
(8) assume that GP VOP 2.0.1 keks (over an VOP SCP 01 secure channel) have previously been used to deploy the DES3-MAC signature verification key, used in (7)
This means that the SO has installed it, is the only person to change it and also knows it.
Have I got the intended usage model right for the various roles, and different uses of the different authentication services?
I would agree to this design.
Are there any other roles vs key usage models I'm missing, for the applet 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.
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
