CODEWITHSUNDEEP
c#smartcardapdupcsc
Oscar K
Oscar K

Reputation: 305

European Tachograph Company Smart Card returns 6D00

We are busy trying to remotely authenticate between a tachograph company smart card and a tachograph. We got it working with our test tachograph but now we encountered a problem with a live one.

Whenever we start the authentication, things go pretty well until the Tachograph sends a get response command: 00C0000080. The Tachograph smart card responds with 6D00. In other words (as I understand it), the tachograph requests a GET response from the smart card. And the smart card answers with "CLA supported, but INS invalid or not programmed" (found in the documentation).

I tried forcing the T1 protocol. Doesn't change the outcome. We tried forcing the T0 protocol, but the smart card is not read by my software anymore. This means the T0 protocol is apparently not supported on this smart card.

Does anyone have an idea what this problem means?

EDIT

It was requested that I place the order of commands by Maarten, see the following lines of commands:

  1. card gives ATR: 3BDF960080B1FE451F870031C16408923201738421E0059000C5
  2. tacho responds: 00A4020C020002
  3. card responds: 9000
  4. tacho responds: 00B0000009
  5. card responds: 000103492B022104309000
  6. tacho responds: 00A4040C06FF544143484F
  7. card responds: 9000
  8. tacho responds: 0022C1B60A8308000DAA06111606A2
  9. card responds: 9000
  10. tacho responds: 0088000010011EBDDCAFA17487000DAA06111606A2
  11. card responds: 9000
  12. tacho responds: 00C000008000
  13. card responds: 6700
  14. tacho responds: 00C0000080
  15. card responds: 6D00
  16. end of all comms

For Maarten: You may assume that the software works correctly. This is live data from a truck this afternoon. The electronics device is wired to the Tacho and my software (that has the readers inserted physically server side) communicates with the electronics device. This device is made by another programmer and he assured me that the data going to and coming from the tacho is communicated correctly. I know that my piece of the software communicates correctly with the smart card, as we got it all working with another card and tacho.

EDIT #2

After we found that some error in the internal authenticate command appeared, we tried forcing a hex byte 80 behind the internal authenticate command. Which makes the process go further, but still cancel after a read binary. Don't know for sure why it does, but we are looking into it at the moment. APDU's below.

  1. comms start, the card sends atr: 3BDF960080B1FE451F870031C16408923201738421E0059000C5
  2. tacho responds: 00A4020C020002
  3. card responds: 9000
  4. tacho responds: 00B0000009
  5. card responds: 000103492B022104309000
  6. tacho responds: 00A4040C06FF544143484F
  7. card responds: 9000
  8. tacho responds: 0022C1B60A8308000DAA06111606A2
  9. card responds: 9000
  10. tacho responds: 0088000010A73D4B33337EBC3D000DAA06111606A280
  11. card responds: 1C90A7F7796CC9B2082470504DCDCF3D3E9EEDEEE00F4AF1FCA127CC1D7B746D21C63DA4D75138B61D7715C4919B37601BF8897DB7C1DD5F58309D55B9588C007AFBA22F997523300B1351684F65AB5FA59E350295B7EE1170F934FC8AFE191E9DEEEDBF7C582D7D0709FEE0F1B44EF3C9D452AB8F25B1106B1E510EF956D6E79000
  12. tacho responds: 0084000008
  13. card responds: 2DA8A7836A6FCF1A9000
  14. tacho responds: 00820000800E5EE3CBE4F16EC816E3FB198F86338604455355AC6123E1B057C9A53ED356679B4F1AE34B8A2EBD95FDD96E4707CDECA208BF22BAA6F70A3ED0CCA39FCC6199B3F959F3226E018D46029142314F25A332C1666A44E9EE3616CD19F9A7E169827C3CEDED372F49A8478BCDD97E63EE48ED695EFFC9B556E4246732BB372C9714
  15. card responds: 9000
  16. tacho responds: 00A4020C020520
  17. card responds: 9000
  18. tacho responds: 0CB000000997018B8E04F0821140
  19. card responds: 9000
  20. tacho responds: 00A4020C020501
  21. card responds: 9000
  22. tacho responds: 0CB00003099701028E046733DD55
  23. card responds: 6688
  24. end of all comms

As you can see, we added 80 manually behind the internal authenticate command which made it go further but it still went wrong. We don't know for sure why it went wrong now, Any ideas, or suggestions as to why the card is now responding with 6688 while a read binary should just return the info are most welcome. We are now on the track of thinking that the "Stonedidge" tacho works differently from the "VDO" tacho. The company/driver has not set the Tacho settings to remote CAN communication, causing errors. I will keep this question updated for later use and other people encountering the same problem.

Solved (for now)

It turns out there is indeed a problem with Stoneridge tachographs. We think a Stoneridge needs to be configured by a workshop to enable remote authentication and download. We have some documentation that seems to confirm this. I will not explain how this is done as this kind of information is not meant for everybody. We did a live test today on another truck with a VDO tachograph (that does not need this configuration) and everything works smoothly and as expected following Appendix 11. If I don't forget, I will update this question when we configure the Stoneridge and get it working, so anybody else encountering this problem can try it as well.

Upvotes: 1

Views: 960

Answers (1)

Maarten Bodewes
Maarten Bodewes

Reputation: 93938

In T=1 the GET RESPONSE is (usually) not supported, as getting the response is part of the APDU transport layer. In T=1 you'd just stick the Le byte (now valued 0x80) to the end of the command requesting the data, making it a ISO CASE 2 (just response data) or 4 (command and response data present) command.

Upvotes: 2

Related Questions