let me also throw in my two cents of opinion:
On 4 Oct 00, at 23:27, David Corcoran wrote:
> It is a
> pain to constantly ask the user a PIN but currently most cards don't
> support channel management which would be the best solution for this
> problem in my opinion.
Sorry, channel management on cards (according to ISO7816 part 4, Manage Channel command) is no solution either. While the card insulates the access rights of different channels, channel stealing works the same way as session stealing, only that its much easier with only four channels to try...
> If the card supports channel management it would be ideal
> if the card required a cryptogram for each command that is transacted and
> the card itself would maintain state.
IMO _this_, secure messaging, is the solution (and my company will be happy to sell appropriate cards). Channels help to share a card between a few good-natured applications, but they add little if anything to security or protection against malicious applications.
>
> Next, we must consider session stealing. At what point do we protect this
> from occurring. If a user has root access they can modify the kernel and
> track kernel calls which would give the cryptogram on even session managed
> cards. Even if the PIN is cached at the application we still must consider
> a superuser poking around at memory. At what point do we give up ?
I think, that one problem is the blurred term PIN which is not sufficiently distinguished from CHV. PINs are used for a several purposes and CHV (i. e. proving you are the legitimate owner of the card) is only one of these. In German digital signature cards the PIN is used as CHV, but it also proves, that you are determined to digitally sign the information presented. It shall be implemented in such a way, that one must re-enter the PIN for *every* signature, which makes sense. In other words, you will burn in (legal) hell if you cache _this_ PIN. The middleware will certainly not be able to make the distiction between a PIN to cache and one not to cache under all circumstances, so this high level information had to be provided by the application. On the other hand, if the option exists to cache a PIN, you will have a hard time to prove, that it is not done and is also impossible to do behind the scenes for that special case.
(BTW I dont like the term caching at all in this context, because it sounds too positive. The suggested mechanism sacrifices security for convenience, which is not completely positive.)
So depending on the scenario the solution might require some of:
- exclusive access to a card (prevents abuse of access right between PIN entry and signature creation by malicious software)
- a security module (second, non-removable smartcard for calculating the cryptographic checksums secure messaging, so the keys for secure messaging are not attackable)
- certified OS kernel (ensures, that nobody built loopholes into the kernel)
- a temper-resistant software/hardware box, where no one is allowed to update anything (ATM-like smartcard terminal)
>
> >If you don't want to comment on the philosophical stuff, at least
> >comment on the simple questions of how people are dealing with when
> >and how to do CHV for 'unlocking' use of the private key on a
> >smartcard. That one was on topic :)
> >
> >Stephen Pellicer
The central problem for multi-shot-PINs is, that the card won't notice when its user leaves the room. So logging in the card at the beginning of the session or caching the PIN both work, but they shift the responsibility to a password-protected screensaver or whatever else the OS offers and the user activates (and what also is attackable at least by the root) and bypass the security provided by the card. It depends on the application, whether this is acceptable but one can't decide it on some general purpose middleware level.
Guido Treutwein Siemens ICM MD IS SW RD 2 *************************************************************** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html ***************************************************************
