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. [EMAIL PROTECTED] [EMAIL PROTECTED] On 1/22/02 4:23 AM, "Carlos Prados" <[EMAIL PROTECTED]> wrote: > Hi, > > --- Michael Gile <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] with unsubscribe sclinux ***************************************************************
