0

As far as we know, smart cards use a Mutual-Authentication method to clarify security between the card and the reader.

I want to know, where the cryptography operations done?(except in the card) In the reader or in the computer?

I mean, whether the reader do any cryptography operation? or it is only a translator for USB / COM protocol to the protocol that card use to transfer data?

In the other word, can I retrieve the [encrypted] data that transfer between the card and the reader, using a sniffer on my computer USB port that my reader conneted to? (Indeed I need to delete some bytes from head and tail of what I see in sniffing. but am I need to do any cryptography function also?)

Note that I need the same data that transfer between card and card reader. and I don't want to have decrypted data.

TheGoodUser
  • 1,188
  • 4
  • 26
  • 52

3 Answers3

3

That depends. For memory based cards and such a lot of things can be done within the readers. If the card is however accessed through PCSC / ISO 7816-4 compatible APDU's then all the crypto is normally performed by the application (this is likely to be true for your situation).

If you want to catch that stuff without messing with the USB itself, I would propose to connect your application to a virtual smart card reader and then forward the APDU's again to a real reader. You can have a hint on how to do this here.

Maarten Bodewes
  • 90,524
  • 13
  • 150
  • 263
  • I want to know, If is it possible to use USB-Sniffers instead of devices such as this : http://www.ul-ts.com/test-tools/domain/payment/collis-card-spy-detail for catching the data exchange between card and reader? – TheGoodUser Oct 25 '14 at 18:37
  • 1
    I don't see why not. The interface between the reader and the driver may have a proprietary format though. Usually such special devicrs are used for lower level protocol testing. – Maarten Bodewes Oct 25 '14 at 20:42
2

I have not yet encountered a reader doing cryptography (besides Mifare and similar), even if there may be specialized devices doing some. I also don't see this as a disadvantage for two reasons:

  • as you mention, doing the cryptography in your application ensures, that the vulnerable device communication is still protected (apart from man in the middle attack types)
  • quite often Mutual Authenticate not only performes an authentication, but also negotiates a session key derived from exchanged random numbers. For that quite a number of different methods exist and I would not rely on the manufacturer incorporating the correct variant in firmware while holding my breath.
guidot
  • 5,095
  • 2
  • 25
  • 37
  • I don't understand this part of first paragraph :`(besides Mifare and similar)`. do you mean, for mifare cards the cryptography done in the reader? – TheGoodUser Oct 25 '14 at 18:44
  • for my mifare cards and my ACR122U reader, I load the keys on the reader just one time (I see the key in plain text when I sniff my USB port when I load the key) and then for each card I send a single authenticate command! I mean I load the key one time for all cards. so can I conclude the cryptography will happen in the reader for my mifares and this reader?if so, how? I mean what is the mechanism? the card send a random number to the reader and the reader keep that number inside itself and don't send it to computer?what application do?loading the key and sendig the authenticate command? – TheGoodUser Oct 25 '14 at 18:52
  • @TheGoodUser: Right, in Mifare there is only one fixed algorithm and just the key is variable, so it is easily possible to do the computation in the reader. (Using the same key for all cards instead of a key derived from serial number is not so great an idea for decent security.) Also Mifare does not involve a separate authentication, applying the correct key to the read/write command is all there is to it, so there is no random number involved. – guidot Oct 25 '14 at 20:23
  • As mentioned in _Security_ section of mifare datasheet here : http://www.gemalto.com/products/hybrid_card_body/download/mifare1K_datasheet.pdf mifares generate a random number in authentication. Am I wrong? – TheGoodUser Oct 25 '14 at 21:48
  • 1
    @TheGoodUser: You are right, a low-quality random number taken from a linear shift register seems to be involved in addition to the fixed serial number of the chip and the chosen key. Anyway, simple, and more important **completely fixed** (read: fwater-tight specified) cryptography may be delegated to the reader, if you choose to do so. – guidot Oct 28 '14 at 09:54
0

In fact, there are smart card readers doing cryptography. For example the Reiner SCT comfort is able to create some secure messaging (PACE, used for id cards and some passports) between smart card and smart card reader, using its own pin pad to collect the credential (value for some pin) from the card holder. So... there are pin-pad smart card readers doing some crypto.

Daniel Heldt
  • 417
  • 5
  • 15