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
(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.
(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
