Hello Marc,
I assume you simply missed to add the OpenCard mailing list to the
recipients
of your mail, that's why I'm distributing my reply publicly. Your proposal
is
interesting enough for a public discussion. I also added the OpenCard tech
mailing list, since a discussion may result in an RFP.
> I agree that an explicit CHV is necessary and therefore it is a good
> idea to provide an interface that card services can implement in order
> to offer this service to applications. However, I also think that the
> Core framework should be extended to allow ciphered PINs.
Thanks. The extension sounds like a good idea to me.
> One possible way to accomplish that is:
>
> 1. Define one or more "require_CHV_ENC" flag in the access conditions
> of each file or object. These need to be initialized when the card is
> scanned for the first time.
Neither the OpenCard core nor OpenCard opt currently define an abstraction
for access conditions. Such an abstraction would have to be introduced.
From
a view to, for example, PKCS#11, you will learn that this introduces a lot
of complexity, resulting in a much bigger framework. I am not sure whether
this leads in the intended direction for OpenCard improvements.
> 2. Pass this flag to the CardChannel.sendVerifiedAPDU method an on to
> the CardHolderVerificationGUI.sendVerifiedAPDU method.
> 3. Provide a mechanism for CardHolderVerificationGUI to call back the
> CardAccessor if the access conditions call for a ciphered password.
> 4. The CardAccessor holds a reference to the current secure session
> object and can therefore cipher the password and return it to the
> CardHolderVerificationGUI object in order to be sent to the card.
The CardAccessor was an attempt of mine to make access conditions
transparent
to the actual CardServices. It is part of the CardServices for IBM
smartcards,
not of OpenCard itself. In recent developments, I have not used a
CardAccessor
anymore, since the CardServices I have written changed their objective.
Instead
of providing can-do-it-all CardServices for general access to a file
system, the
recent ones are tailored towards specific on-card applications, or DFs on
the
card. In this case, the CardService "knows" which access conditions have to
be
satisfied, and there is no need for the CardAccessor layer. The resulting
Card-
Services are much more compact, and easier to use from the application.
> This capability would be necessary for the implementation of the
> CHVCardService.VerifyPassword method or any implicit method that
> performs Card Holder Verification.
Adding a callback option is the actual change that would be required in
OCF.
This would allow CardService implementors to adopt the scheme you proposed
above. However, callbacks in the protected PIN path (PKCS#11 term) raise
the
question of security, which requires in-depth considerations.
Currently, the sendVerifiedAPDU method does not give away the password. If
the
terminal implements a protected PIN path, it will not even get to know the
PIN
or password, and will therefore be unable to invoke a callback. I guess
this is
not much of a problem, since the terminal would be expected to encrypt the
PIN.
The security of the service layer implementation of sendVerifiedAPDU may be
questioned, since an application-defined CHV dialog can be installed. The
app-
lication will not install that dialog directly, but give it to the service.
The
sendVerifiedAPDU method can never be sure whether such a CHV dialog comes
from
the application, or whether a CardService passed it's own CHV dialog.
Neither
can an application-defined CHV dialog be sure that it is actually used by
send-
VerifiedAPDU, and not invoked by the CardService. Adding a callback that
reveals
the password may therefore not open a new security hole. I'd like to hear
other
people's view on this.
>> [Peter Bendel's reply to the original mail, with attached RFC 14, cut
out]
I will not be able to follow the discussion, which I hope will develop. I
am
out of office from Thursday, 26. August to Sunday, 5th September,
inclusive.
Could you scan answers and suggestions on this issue, and maybe prepare an
official RFP? I'm not sure whether you are on the OCF tech mailing list,
but
someone else at Gemplus surely is, and can file an RFP for you :-)
best regards,
Roland Weber
IBM Pervasive Computing Division - SmartCard Solutions
Visit the OpenCard Framework's WWW site at http://www.opencard.org/ for
access to documentation, code, presentations, and OCF announcements.
-----------------------------------------------------------------------------
To unsubscribe from the OCF Mailing list, send a mail to
"[EMAIL PROTECTED]" with the word "unsubscribe" in the BODY of the
message.
