Hi,

I may go out of the purpose of the original message of this thread,
which was to ask for arguments for why a smartcard is useful in
securing a system, but I'll answer anyway.

--- Michael Gile <mgilemac.com> wrote:
> Hi Carlos,
>
> > I consider this argument inaccurate. The smartcard does not
> necesary
> > needs a PC to run. You attach the smartcard to a PC reader to allow
> > some application on your PC to get benefit of the smartcard. But
> your
> > smartcard system (PC application + smartcard) will never be more
> secure
> > than your host PC alone. The smartcard system cannot replace good
> > handling of the user access to the computer resources by the OS.
>
> I think on this point we are in agreement, our points are simply
> argued
> differently. The smartcard does not need a PC (EMV POS terminals for
> example), but in practical application is essentially useless without
> a host
> machine to provide input and output services.
>

My point was that the PC itself without an application running will
always be more secure than the PC with an smartcard system implemented.
It will be even more secure with the network cable disconnected. And
even a degree more secure with the power turned off.

You implement your system to provide some functionality to the user. In
general, the more functionality you provide, the less security you
have. This basically doesn't change with smartcards. The smartcard
system will not secure your PC. It'll only reduce the degree of
security you necesarily lose when implementing some functionality.

F.i. a smartcard public/private key based console login application may
be more secure than a common user/password login application, but not
as secure as completely disabling console logins.

The conclusion is that your smartcard system running on an insecure PC
will be as insecure as any other system not using smartcards running on
an insecure PC. They key is that the PC must be itself secure before
implemeting your system. You cannot blame the smartcard of the fact of
depending on potentially insecure PC's, because the smartcard is not
the one that introduces this dependency.

>
> > IMHO this is a application design problem, and not a problem on the
> > smartcard industry itself. You *must not* have an application
> signing
> > arbitrary data from anybody that request that. Would you run a
> daemon
> > that gets data from anybody and encrypts/signs this data with your
> > private key "safely" stored on your hardisk? The same applies if
> the
> > key was generated onboard on your smartcard.
>
> I used the oracle as a simple example of a common application. Yes,
> it is a
> flawed design, but that hasn't stopped thousands of developers from
> creating
> applications exactly that way. The problem I was trying to identify
> was
> that an attacker need not recover the key on the card in order to
> compromise
> the security of the system.
>
> > The smartcard must be managed by the OS like other normal device,
> lets
> > say the printer or the harddisk. Once a user has logged into the
> > system, he/she may or may not have access to the smartcard,
> depending
> > on system priviledges of this user. Under UNIX this is perfectly
> > handled by regular file permissions to read/write from the
> smartcard.
>
> However, I need not run Unix to control the PC's resources. I can
> bring a
> boot floppy with me and run whichever OS I please. Therefore the
> smartcard
> is now available to anybody with enough skill to create a PC/SC
> application
> and a boot disk.

If you have physical access to the PC to boot from a floppy, what
chance would your remote server have to protect and encrypt the access
to the smartcard?

I start from the point that you have physical security before trying to
have logical security. That is, your server is in some Data Processing
Center and there is a watchman or a policeman on the door asking you
for your ID before allowing you to get in contact with the computer. Or
at least is "safely" stored in your house and you are not used to loose
your keys, like I frequentrly do ;-).

> This is why I argue that the smart card really only
> becomes a security asset when coupled with a remote server
> application. In
> this way, the PC and reader become only a pipe through which
> encrypted data
> may flow. For example, a smart card could negotiate a Diffie-Hellman
> exchange and accept commands only from the authorized server. With
> as
> little as 20 bytes of storage (SHA-1 hash), you can create a chain of
> trust
> using X.509 or other certificate type and be sure that the card can
> only
> perform certain operations when directed by an authorized party.
>

> On the whole, I think we agree more than we disagree Carlos, a
> smartcard by
> itself is secure, but when coupled with an insecure host, it is
> compromised,
> just like any other secure application.
>

Maybe. We only differ in that you blame the smartcard for needing the
insecure PC and Operating System, and put the responsability of fixing
the insecurity on the smartcard side. In contrast I think that each
component of a system is responsible of it's own security, and that you
cannot deploy your application (smartcard-based or not) if the
underlying system is not secure enough for your needs.

The smartcard based system cannot provide "more security" than what you
already have on your OS, but "less insecurity" than a non
smartcard-based system. Of course having smartcard-based replacements
for some components of the OS may result in greater average security
degree.

These are only philosophical arguments however.

Carlos.

> Regards,
>
> Michael Gile
> Wave Systems Corp.
> mgilewavesys.com
> mgilemac.com
>
> On 1/22/02 4:23 AM, "Carlos Prados" <cpradosyahoo.com> wrote:
>
> > Hi,
> >
> > --- Michael Gile <mgilemac.com> wrote:
> >> The security problem with smart cards is not key recovery. It is
> the
> >> fact
> >> that the smart card must rely on a standard PC (or other insecure
> >> host) for
> >> input and output.
> >>
> >
> > I consider this argument inaccurate. The smartcard does not
> necesary
> > needs a PC to run. You attach the smartcard to a PC reader to allow
> > some application on your PC to get benefit of the smartcard. But
> your
> > smartcard system (PC application + smartcard) will never be more
> secure
> > than your host PC alone. The smartcard system cannot replace good
> > handling of the user access to the computer resources by the OS.
> >
> >> For example, say we have a smart card with a signing application
> that
> >> will
> >> sign arbitrary data from the host PC (an oracle). The attacker no
> >> longer
> >> needs access to the key, only an application that can send data to
> >> the card.
> >> Even when adding authorization to the key usage (for example a
> PIN),
> >> an
> >> attacker needs only access to the insecure host machine and can
> then
> >> recover
> >> the PIN itself or send bogus data to be signed.
> >>
> >
> > IMHO this is a application design problem, and not a problem on the
> > smartcard industry itself. You *must not* have an application
> signing
> > arbitrary data from anybody that request that. Would you run a
> daemon
> > that gets data from anybody and encrypts/signs this data with your
> > private key "safely" stored on your hardisk? The same applies if
> the
> > key was generated onboard on your smartcard.
> >
> >> The solution to the smart card attacks above is to add a secure
> >> communication channel to some special purpose server through which
> >> only
> >> encrypted data is ever transmitted outside the card, or provide a
> >> more
> >> robust mechanism to the user that can be used for secure input and
> >> allows
> >> more storage and computing power on the card itself.
> >>
> >
> > The smartcard must be managed by the OS like other normal device,
> lets
> > say the printer or the harddisk. Once a user has logged into the
> > system, he/she may or may not have access to the smartcard,
> depending
> > on system priviledges of this user. Under UNIX this is perfectly
> > handled by regular file permissions to read/write from the
> smartcard.
> >
> > Carlos.
> >
>
>
> ***************************************************************
> Unix Smart Card Developers - M.U.S.C.L.E.
> (Movement for the Use of Smart Cards in a Linux Environment)
> http://www.linuxnet.com/
> To unsubscribe send an email to majordomolinuxnet.com with
> unsubscribe sclinux
> ***************************************************************

__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/
***************************************************************
Unix Smart Card Developers - M.U.S.C.L.E.
(Movement for the Use of Smart Cards in a Linux Environment)
http://www.linuxnet.com/
To unsubscribe send an email to majordomolinuxnet.com with
unsubscribe sclinux
***************************************************************

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