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.

> 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. 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.

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
***************************************************************

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