On Thu, Oct 05, 2000 at 02:09:37PM +0200, [EMAIL PROTECTED] wrote:
> 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.
These are very valid arguments in addition to the further ones later
in your message. I guess my desires with this discussion are from a
step down from the hard-core non-repudiation issues with legally
binding use of smartcards. My main interest here is with
authentication and reduced sign on type solutions, so I believe we
have the luxury of reducing some of this control, yes? In these types
of scenarios we can use CHV to allow use of this private key for these
less sensitive issues and only resort to per use PIN's on our
non-repudable (is that a word?), legally binding keys, can't we? I
agree that caching a PIN for legal purposes would be irresponsible
(that does not remove the fact that it is not only possible but easy
unless we follow your following list for all systems we would possibly
use the card on.)
> - exclusive access to a card (prevents abuse of access right between
> PIN entry and signature creation by malicious software)
I guess my argument in some of these cases is that malicious software
can circumvent many of these proposed approaches except for the most
careful user. And that leads to the fact that more careful users can
responsibly use some more lenient approaches in certain scenarios. I
don't think that the solution for all applications of using these keys
on a smartcard entail constant confirmation. This runs the danger of
numbing the user to the ramifications of entering their PIN. I'm
really saying that context and application determines how effective
reprompting the user is. In the case of legally binding signatures,
the user is responsible enough to sacrifice the convenience
responsibly. In the case of access to network and computing resources,
I think users are more likely to irresponsibly deal with the
inconvenience.
> - 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 we had all of these things, I think many of our security issues
would go away. With that much tamper resistant technology, it would be
difficult to _not_ design a workable system. I'm more concerned with
pracital use of this technology leveraging the bulk of our
infrastructure.
> 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.
I think the best we can ask for here is users pulling cards when they
leave and reauthenticating when returning. I think this is an
adequate compromise for reauthentication.
My major concern with systems such as these is really getting to the
root of what is the easiest path of compromise and are our
reservations regarding certain designs stemming from the absolute
security implementation or the practical real-world implementation
issues.
Stephen
***************************************************************
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
***************************************************************
