I have made android app that reads truck driver card (from tachograph) via otg smart card reader.
I can read all files on card from tree structure on image bellow.
But when I compare data that I read, and from some other public application, I have noticed that some files are fallowed by something that might be a key or signature
I do not know what underlined part represents nor how to read or generate it.
Without those "signatures" all data that I have is useless, but if I hard code those underlined parts (from other apps) in my ddd file, everything works fine
The most I have found is that
05 04 - Current usage Data
01 - means there is still a signature (gen 1)
00 80 - 0x0080 = 128 dec
Also I have read card certificate and ca certificate from card but didn't find is there any correlation with underlined part of problem.
Thanks to #nvf I found explication and solution in document
Part of responses .ddd that start with "01 00 80" represent digital signature of hash value on previously selected file.
To get digital signature you should select file, execute command to perform hash of file, and then execute command to get 128 bytes digital signature.
Related
I used cantools python package to decode canbus message. I used a dbc file created by me for testing. I copied a sample file. When I use can id like 419358976, I get error. But for smaller can ids like 350, it works. Does cantools fail for extended frame ids? how do I get this working?
my code which is failing for extended id's is as follows:
db = cantools.database.load_file('.\\src\\test\\resources\\j1939.dbc')
print(db.decode_message(419358976,b'\xff\xff\xff\xc0\x0c\xff\xff\xff'))
error: cantools.database.errors.Error: Standard frame id 0x18fee900 is more than 11 bits in message EEC1.
I found the answer for my question. The can id like 419358976 is an extended id. So to map that id to the id in the dbc file, I need to add another 32 bit hex number 8000 0000 to the hex can id. Then convert that result hex number to decimal and use it as the id field in the dbc file. It works perfectly after. The above error message is gone after
I'm constructing a generate AC command for a Mastercard contactless card. I have retrieved the CDOL1 from the ICC data, however the card respond with 6985. Any advice on what the problem might be.
Card Risk Management Data Object List 1 (CDOL1) [8C]:
Amount, Authorised (Numeric) [9F02]:
Length: 06
Amount, Other (Numeric) [9F03]:
Length: 06
Terminal Country Code [9F1A]:
Length: 02
Terminal Verification Results (TVR) [95]:
Length: 05
Transaction Currency Code [5F2A]:
Length: 02
Transaction Date [9A]:
Length: 03
Transaction Type [9C]:
Length: 01
Unpredictable Number (UN) [9F37]:
Length: 04
Terminal Type [9F35]:
Length: 01
Data Authentication Code [9F45]:
Length: 02
ICC Dynamic Number [9F4C]:
Length: 08
Cardholder Verification Method (CVM) Results [9F34]:
Length: 03
Transaction Time [9F21]:
Length: 03
Customer Exclusive Data (CED) [9F7C]:
Length: 14
80AE - Generate Application Cryptogram
80 - ARQC
00
42 - Length
000000000100 - 9F02
000000000000 - 9F03
0710 - 9F1A
8000040800 - 95
0710 - 5F2A
191111 - 9A
00 - 9C
3357A30B - 9F37
21 - 9F35
0000 - 9F45
0000000000000000 - 9F4C
1F0302 - 9F34
142005 - 9F21
0000000000000000000000000000000000000000 - 9F7C
The first thing you need to do is to look at the PDOL you get in response to the GPO message, and check that these are exactly the fields and lengths the card is asking for. Post the answer to the GPO message here if you are unsure. A common cause for this error is if you don't provide all the data the card wants, or if you send it too much.
I have a MasterCard that asks for exactly the data you have here and it response correctly to a GEN AC command of:
80AE900042000000000100000000000000082600000000000826190819003357A30A21000000000000000000001F0302120505000000000000000000000000000000000000000000
Comparing this with your message there are a few small differences. Below I list what you send and what I'm sending:
80AE - same
80 - I use 90, see EMV book 4, Section 6.5.5 on how to build the P1 value.
00 - same
42 - same
000000000100 - same
000000000000 - same
0710 - I use 0826 UK rather than Estonia, shouldn't matter.
8000040800 - I use 0000000000 which means no errors
0710 - Again I use 0826 UK, not Estonia
191111 - 9A I use a different date, shouldn't matter.
00 - same
3357A30B - Our UN numbers are only 1 different, which is odd! Where did you find yours?
21 - same
0000 - same
0000000000000000 - same
1F0302 - same
142005 - different time, shouldn't matter.
0000000000000000000000000000000000000000 - same
I also have 00 on the end for the Le.
Tom
Application SELECT Command may return Tag 0x9F38 Processing Options DOL (PDOL).
The Tag Values required by PDOL need to be sent by terminal/reader to the card in the next step Get Processing Options (GPO) Command.
In case PDOL is unknown after application selection you may send GPO Command with empty Tag 0x83 to retrieve Tags 0x82 Application Interchange Profile (AIP) and 0x94 Application File Locator (AFL) from card.
Having AFL you should READ all mentioned records and analyze card tags. They may have CDOL1 value required for Generate AC.
Then, if it is still needed by card transaction scenario, you can send Generate AC Command with CDOL1 Tag Values.
Please refer to EMVCo EMV Contactless Specifications for Payment Systems, Book C-2, Kernel 2 Specification where MasterCard scenarios described.
We want to create a logfile at customer site where
the customer is able to read the log (plain text)
we can verify at our site that the log file isn't manipulated
A few hundred bytes of unreadable data is okay. But some customers do not send us files where they can't verify that they do not contain sensible data.
The only reasonable option I see so far is to append a cryptographic checksum (e.g. SHA256(SECRET_VALUE + "logtext")). The SECRET_VALUE would be something hardcoded which is plain "security through obscurity". Is there any better way?
We use the DotNet-library and I do not want to implement any crypto algorithm by hand if that matters.
You can use standard HMAC algorithm with a secret key to perform the checksum.
Using a secret key prevents in a simple way that the checksum can be regenerated directly. A hardcoded key could be extracted from code, but for your use case I think is enough
The result is a binary hash. To insert it into the text file encode the value as hexadecimal or base64, and ensure you are able to revert the process in server side so you can calculate the hash again with the original file.
You could use also a detached hash file to avoid modifying the log file
Target
customer readable logfiles
verifyable by our side
minimum of binary data
must work offline
Options
Public-Private-key-things... (RSA, ...)
would be secure
but only binary data
Add a signature
We are not the first ones with that idea ( https://en.wikipedia.org/wiki/Hash-based_message_authentication_code )
DotNet supports that ( System.Security.Cryptography.HMACSHA256 )
Key must be stored somewhere ... in source
Even with obfuscation: not possible to do so securely
Trusted Timestamping
again: we are not first ( https://en.wikipedia.org/wiki/Trusted_timestamping )
needs connection to "trusted third party" (means: a web service)
Build Hash + TimeStamp -> send to third party -> sign the data (public-private-key stuff) -> send back
Best option so far
Add a signature with HMAC
Store the key in native code (not THAT easy to extract)
Get code obfuscation running and build some extra loops in C#
Every once in a while (5min?) put a signature into log AND into windows application log
application log is at least basically secured against modification (read only)
and it's collected by the our error report
easy to oversee by customer (evil grin)
We are working with SCOSTA smart card with ISO7816-4 APDU Commands.
I had create file structure but didn't understand how to set security Access Condition in Compact and Extended Format
For Example.
I am using TLV structure for Creating File MF,DF,EF,SE etc
Deticated File will have following FCP:
Tag 8C
Len 08
Security Attribute AM 7F
VALUE FF Delete File(Self):Never
VALUE FF Terminate DF:Never
VALUE 22 Activate File:(SE#2)
VALUE 22 Deactivate File:(SE#2)
VALUE 22 Create File EF:(SE#2)
VALUE 22 Create File DF:(SE#2)
VALUE FF Delete File(child):Never
So My Question is :
Where from VALUE 22 Set and what is the meaning of SE#2 ?
How to calculate AM Byte?
I refer ISO/IEC 7816-4:2005(E) Document Page No:24-25
Tag 8C indicates an access rule in compact format. There an Access Mode Byte (7F) is followed by as many Security Condition Bytes as bits are set in the access mode byte. The example looks reasonable, even if in my opinion, it would be more intuitive, to leave out the bits (and corresponding SCBs) for which only a NEVER security condition byte follows. (An operation not explicitly allowed, should be rejected anyway).
The coding of the Access mode byte for a DF is found in table 16 and the encoding of the security condition byte is in table 20 of ISO 7816-4.
SE#2 means, that the key IDs necessary for User Authentication, External Authentication and Secure Messaging are determined by Security Environment 2, the value 22 means, that in your case only an external authentication is necessary.
I’m generating successfully ARQC’s with VISA credit, debit and MC credit cards, but when i try to generate one with MC Debit i get "6700" command wich means "wrong length", here is my CDOL and my command:
The CDOL1 sum of all data objects length is expecting 35 bytes (Hex 23)
CDOL1
9f02069f03069f1a0295055f2a029a039c019f37049f35019f45029f3403
COMMAND
80AE80002300000000000000000000000004848000008000048413021300550320312100001e0300
Does anybody have an idea what i’m doing wrong?
You do not include 9F4C(ICC Dynamic Number) in your CDOL1. You must include this tag its a must for calculation for ICC Dynamic Data in first Generate AC.