From: Karsten Ohme (widerstandt-online.de)
Date: Mon Oct 10 2005 - 18:19:45 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Tommaso Cucinotta wrote:
> Karsten Ohme wrote:
>
>> But for the CardEdge applet this does bot matter, this is only used for
>>
>> Unix libraries to detect if they are compatible with each other. So,
>> 1.0.1 is a beautiful number and does fit in the above scheme.
>>
>> Your above scheme would say
>> So 1.10.0 would be the result.
>>
>>
> Actually, any number is usually reset to 0 as soon as some other number
> on the left is incremented,
> so I would propose 1.0.0 to underline that some internals changed. I'm
> sure David loves tagging
> the Applet to 1.x.x because this gives people the feeling of a stable
> software component, as opposed
> to 0.9.11 which recalls something in experimentation. Please, note that
> the Applet
> version is not important at all for compatibility issues, because the
> only thing that is important is the
> *protocol version*, as output by the GetStatus APDU. On the basis of
> this version, the host-side
> plugin should decide what set of APDUs to use to talk to the card (if
> it's a new plugin), or to
> not talk to the card (if it's an old plugin and sees an increment in the
> leftmost number).

The old MCardPlugin does not care for the protocol version. But the
applet recognizes form the expected response size, which version is
talking from the client side.

> So, the
> real question here is: what is the new protocol version, that could be
> reformulated as "do the old
> MuscleCard plugin APDUs still work the same ?". Current document [1] is
> versioned as 1.2.1,

Yes. You should also be able to talk from old MuscleCard plug-ins to the
applet. I always (?) checked the expected response length and responded
accordingly.

> thus a Yes would imply 1.3.0, a No would imply 2.0.0. And I would like
> to update the protocol
> specification reflecting the new APDUs. Actually, I can't remember if
> the Applet is really compliant
> with [1] or if it has deviated from it in the last four years.
>
>> What is the difference between the usual ACL read parameter and the read
>>
>> only flag? At the moment 0xFFFF 0x0020 0x0020 would mean that it cannot
>> be read (exported) (0xFFFF) and only used (0x0020) and deleted (0x0020)
>> by PIN#1. Please explain.
>>
>>
> The difference is quite important: if the key were injected from the
> outside world with the Read
> ACW inhibited, then an outsider could potentially have that same key.
> If, instead, we added the

OK. Got it. So I would proposed a bit mask (a short) and one bit means
that the key was generated on the card. (Makes such a bit mask also
sense for objects?) What other flags could it be interesting for such a
bit mask?. It is reported with a ListKeys command depending on the
expected length it is reported or not.

> information that the key is a private key of a keypair that was
> generated on the card with Read
> ACW inhibited, then we would be sure that the card is the only entity
> that knows the key. This
> flag could be checked by a software before trusting that key or before
> granting auhtorizations.
> I know, I could write a modified Applet that cheats on that flag and
> always says "never exported".
> So, in order to have a CA that has absolute certainty of the
> non-cloneability of the private keys,
> I (CA) would at least need to control the process of card format.
> Though, I could inject into the
> Applet a generic authentication key, leaving to the user the ability to
> self-generate keys by himself,

I do not get this point. What is the job of the generic authentication key?

> but retaining the ability to check if they are absolutely unique or not.
>
> Bye,
>
> Tommaso.

Bye, Karsten

>
> [1] http://www.musclecard.com/musclecard/files/mcardprot-1.2.1.pdf
> --
> Tommaso Cucinotta, Computer Engineer PhD
> Scuola Superiore Sant'Anna, Pisa, Italy
> Tel +39 050 883 093, Fax +39 050 883 452
> http://feanor.sssup.it/~tommaso
>
> _______________________________________________
> Muscle mailing list
> Musclelists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle

_______________________________________________
Muscle mailing list
Musclelists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]