Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I am looking for keyboards with a built in SmartCard reader, where the Smartcard can be unlocked directly without going via the computer. The keyboards I found so far connect the SmartCard reader via an integrated USB hub which opens the door for key loggers to snatch the PIN/password. Are there any keyboards where the SmartCard can be unlocked locally that don't transmit the PIN/password to the connected computer?

To clarify for what it will be used:

The employes will get SmartCards with authentication certificates on them. The SmartCard is protected by a PIN/Password. The user will:

  1. insert the card
  2. enter the card PIN/password (preferably locally)
  3. enter the password for the certificate (on the computer)

We made tests with external readers similar to the one here and the local handling of the unlock by PIN worked fine. Now we are looking for a way to remove the "extra device" on the table.

share|improve this question
1  
This would be difficult to implement to be more secure than doing it on a computer itself. How does the keyboard transmit the all clear to the computer? What prevents this signal from being cloned? I suppose it might be possible to use the keyboard to directly unlock the card and then have the card handle the connection, but it sounds like it would be pretty difficult to setup and might introduce risks about attacks convincing a smart card to authenticate something you didn't want to authenticate (since it is unlocked by different hardware than it is authenticating to). –  AJ Henderson Mar 27 '13 at 12:57
    
How would it be more difficult to implement than the Secure PIN Entry (SPE) in the following device: acs.com.hk/index.php?pid=product&id=acr83 ? –  Simon Mar 27 '13 at 13:08
1  
the point of that device is Payment capture. It is either a) communicating the payment information directly to the payment gateway (thus bypassing the computer completely), b) being given a transaction to sign and signing it or c) passing the payment information after unlock. I suppose that authentication could be accomplished by doing a challenge/response signing, but it would open the door for something other than the login to provide the challenge. –  AJ Henderson Mar 27 '13 at 13:13
    
Well maybe i should explain what we want to use it for. We want to use two factor authentication to log on to our system. The employes will get SmartCards with authentication certificates on them. The SmartCard is protected by a PIN/Password. The user will 1. insert the card 2. enter the card PIN/password (preferably locally) 3. enter the password for the certificate (on the computer). We made tests with external readers similar to the one I mentioned above and the local handling of the unlock by PIN worked fine. Now we are looking for a way to remove the "extra device" on the table. –  Simon Mar 27 '13 at 13:27
    
ah, ok, so that is more or less fitting with my b) scenario. I guess that works ok since it still ensures the card is present and can't be reproduced without the card and the pin to unlock the card isn't around. Alright, I just had to finish thinking it through. –  AJ Henderson Mar 27 '13 at 13:46

1 Answer 1

The problem with what you ask for is about sharing the keyboard with the OS. When a keyboard is plugged in a machine, then the operating system on that machine is made aware of every key press and key release event, and the OS maintains the knowledge of which key is pressed at any time. For your PIN entry scenario, you not only need the key presses to be sent to the smart card, but you also want the same key presses not to be sent to the operating system.

The keyboard, by itself, won't be able to guess whether you are about to type a PIN code. You could imagine a specific command sent from the computer, which tells to the keyboard: "now, key presses should be sent to the smart card, not to me". But you do not trust the host computer (that's the point of the discussion), so you cannot trust it for actually sending this command. Therefore, your special keyboard, if it exists at all, should have a manual switch or at least an indicator LED which the OS cannot override (e.g. the LED turns green when key presses are sent to the smart card).

You would not be at the end of your worries, though. Because when you use the smart card to perform a payment, the card "authenticates" the payment order (with some operation that the bank will accept as valid; this could be a MAC or a digital signature). You then want to be sure that what the card sees and signs is indeed the payment order you believe. Since you do not trust the host computer, you need an extra display.

When you go down the road of "host computer is potentially hostile", you normally end up with the idea that the smart card reader should have its own keyboard and display, so that it may show you what you are about to sign, and makes sure that your PIN code goes to the card only. Ideally, the reader should run the banking application itself (to assemble the order in the right format). At that point, you have a payment terminal, which is a small, tamper-resistant computer with its own CPU, RAM, Flash, display, keyboard and smart card reader. The important point is that, short of a full-featured payment terminal, you will not get substantial security against an hostile host computer.

The easier way is to trust the host computer, so that you may reuse the components that the host computer already offers: CPU, RAM, storage, display, keyboard...

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.