After installing the applet, my card responded thus, to two of the getStatus
polling messages
- muscle applet:
Recorded Wed Sep 14 19:02:26 2005
C-APDU: 80 F2 20 00 02 4F 00 00
R-APDU: 05 A0 00 00 00 01 01 00 90 00
Time: 241 ms
- whereas for the card manager applet we have
Recorded Wed Sep 14 19:05:57 2005
C-APDU: 80 F2 80 00 02 4F 00 00
R-APDU: 08 A0 00 00 00 03 00 00 00 01 1A 90 00
Time: 100 ms
From GP, we know
---------
9.4.3.1 Data Field Returned in the Response Message
..
Length Value Meaning
1 'xx' Length of AID
1-n 'xxxx
' AID
1 'xx' Life Cycle State
1 'xx' Application Privileges
Table 9-22: Issuer Security Domain, Application and Executable Load File
Information Data
9.1.2 Application Privileges Coding
Application Privileges are coded on one byte as described in the following
table (See Section 6.6.2.4 -Application Privileges for additional details):
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
1 X X X X X X X Security Domain
1 1 X X X X X 0 DAP Verification
1 X 1 X X X X X Delegated Management
X X X 1 X X X X Card lock
X X X X 1 X X X Card terminate
X X X X X 1 X X Default Selected
X X X X X X 1 X CVM management
1 1 X X X X X 1 Mandated DAP Verification
Table 9-7: Application Privileges
----------
as the card manager has app privs = 1A, and (1A && 04)==true, so the card
manager has the default select.
for Install (install) for the muscle applet (on its default AID) I had
issued
80 E6 0C 00 1C 05 A0 00 00 00 01 06 A0 00 00 00 01 01 06 A0 00 00 00 01 01
01 04 04 EF 00 C9 00 00 00
which indicates that the IDE *attempted* to install the applet with app
privs = 04.
Ok. It didnt work - doing it by hand: the card manager still has the
privilege, despite installing the applet with the privi.
Im missing a concept, clearly; probably in the security model.
It will be fun to use the tool - but first, I have to understand the bytes,
and the management model behind the flow.
Peter.
From: Snit Mo <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED], MUSCLE <[email protected]>
To: MUSCLE <[email protected]>
Subject: Re: [Muscle] muscle applet as a cardmanager?
Date: Wed, 14 Sep 2005 18:29:09 -0700
With OpenPlatform / GlobalPlatform, it is possible to make an applet
"default selected". You need to set this privilege when you do
install_for_install_and_make_selectable, I think. Refer to OP/GP card
specification.
Latest GPShell (the code in CVS) supports this. I will release a
version that supports this soon.
Thanks,
On 9/14/05, Peter Williams <[EMAIL PROTECTED]> wrote:
> Im back to my problem of getting the muscle applet to be responsive on
ICC
> powerup, without requiring host/reader to perform an explicit select.
>
> Perrhaps the right way to ask the question is this:
>
> is it feasible to denote a loaded/installed muscle applet to act as the
> default card manager, in the GP registry? THe "default" card manager of
> course requires no initial select.
>
> In the first instance, this would be a hack. (a) Use conventional card
> manager to load/install post issuance muscle applet instances . (b)
> designate one muscle applet instance as a card manager (c) lose all card
> management access (given muscle has insufificent supprot to actually be
a
> card manager).
>
> Reactions, before I go play with reality?
>
> I assume the "minimal SUN" javacard license (the single applet license
for
> single-function cards) would faciliate this kind of applet deployment
and
> powerup behaviour - a behaviour create either by card manager
substitution
> or a ROM-time masking process.
>
>
> _______________________________________________
> Muscle mailing list
> [email protected]
> http://lists.drizzle.com/mailman/listinfo/muscle
>
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
