Develop Reference

Minimal Bluetooth Keyboard on Android

I am trying to write a minimal implementation of a Bluetooth Keyboard for Android using GATT. They are plenty of examples out there, but something is still missing. The device connects to my Windows Machine. Then the GATT database is read:
onCharacteristicReadRequest: 00002a50-0000-1000-8000-00805f9b34fb, id: 7, offset: 0, data: 02 00 00 00 00 00 00
onCharacteristicReadRequest: 00002a4a-0000-1000-8000-00805f9b34fb, id: 8, offset: 0, data: 01 11 00 02
onCharacteristicReadRequest: 00002a4d-0000-1000-8000-00805f9b34fb, id: 9, offset: 0, data: 00 00
onDescriptorReadRequest: 00002908-0000-1000-8000-00805f9b34fb, id: 10, offset: 0, data: 00 01
onDescriptorReadRequest: 00002902-0000-1000-8000-00805f9b34fb, id: 11, offset: 0, data: 00 00
onCharacteristicReadRequest: 00002a4b-0000-1000-8000-00805f9b34fb, id: 12, offset: 0, data: 05 0c 09 01 a1 01 05 07 15 00 25 01 75 01 95 08 09 e0 09 e1 09 e2 09 e3 09 e4 09 e5 09 e6 09 e7 81 02 05 07 95 01 75 08 15 04 25 df 19 04 29 df 81 00 c0
onDescriptorReadRequest: 00002907-0000-1000-8000-00805f9b34fb, id: 13, offset: 0, data: 2a 4d
onDescriptorWriteRequest: 00002902-0000-1000-8000-00805f9b34fb, id: 18, offset: 0, data: 01 00
After that I try to send a key stroke of key H as follows:
public void sendTestNotification(BluetoothDevice device) {
BluetoothGattCharacteristic report = gattServer.getService(UUID.fromString(HID_SERVICE)).getCharacteristic(
UUID.fromString(BtConstants.REPORT_CHARACTERISTIC));
byte[] data = {0x0, 0xB};
report.setValue(data);
// (permission check - omitted)
gattServer.notifyCharacteristicChanged(device, report, true);
}
But nothing happens.
Is something apparently wrong with the GATT configuration?

The approach I used here was contstructing a GATT database from scratch and adding different characteristics manually. I still cannot say, what is wrong here, however the better approach is to use HID profile. You will still have to deal with the Report Map Characteristic, but it's the only hurdle in this case.

APDU commands to get data from NFC tag using ISODEP

I am trying to read the information stored on my German Sparkasse Girocard. My app successfully recognizes the (ISODEP) tag. To read the stored information, I need to send a sequence of APDU commands, but I am not sure which.
From my understanding I need to send a SELECT command first:
byte[] SELECT = {
(byte) 0x00, // CLA Class
(byte) 0xA4, // INS Instruction
(byte) 0x04, // P1 Parameter 1
(byte) 0x00, // P2 Parameter 2
(byte) 0x09, // Lc
(byte) 0xD2,0x76,0x00,0x00,0x25,0x47,0x41,0x01,0x00, // AID
(byte) 0x00 //Le
};
Tag tagFromIntent = intent.getParcelableExtra(NfcAdapter.EXTRA_TAG);
IsoDep tag = IsoDep.get(tagFromIntent);
tag.connect();
byte[] result = tag.transceive(SELECT);
text.setText(Integer.toHexString(result[0]) + ", " + Integer.toHexString(result[1]));
The status response should be 9000 if it works. I am getting 6F44 which indicates that there was some sort of error (I think). I am also not quite sure if I am using the correct AID, but it has also not worked using others, which I thought could be correct.
What is my error and which commands do I have to send to retrieve the data?
Thanks in advance.

Getting data from an EMV card (e.g. Girocard, Mastercard, Visacard) is more a "question and answer" puzzle - you are asking the card, get a response, analyze the data and ask the next question.
The analyzing part is done here by using the "TLV Utilities" from emvlab.org (https://emvlab.org/tlvutils/).
To get more information about the Application Identifier ("AID"s) see the complete list at: https://www.eftlab.com/knowledge-base/211-emv-aid-rid-pix/.
Here is an example of reading a German Girocard (mine is from a "Volksbank"):
Step 1: ask the card which applications are on the card using the "select PPSE" command. The 2 bytes at the end "90 00" say that the answer is successfull:
selectPpseCommand: 00 A4 04 00 0E 32 50 41 59 2E 53 59 53 2E 44 44 46 30 31 00
selectPpseResponse: 6F 67 84 0E 32 50 41 59 2E 53 59 53 2E 44 44 46 30 31 A5 55 BF 0C 52 61 19 4F 09 A0 00 00 00 59 45 43 01 00 87 01 01 9F 0A 08 00 01 05 01 00 00 00 00 61 1A 4F 0A A0 00 00 03 59 10 10 02 80 01 87 01 01 9F 0A 08 00 01 05 01 00 00 00 00 61 19 4F 09 D2 76 00 00 25 47 41 01 00 87 01 01 9F 0A 08 00 01 05 01 00 00 00 00 90 00
Parsed response:
6F File Control Information (FCI) Template
84 Dedicated File (DF) Name
325041592E5359532E4444463031
A5 File Control Information (FCI) Proprietary Template
BF0C File Control Information (FCI) Issuer Discretionary Data
61 Application Template
4F Application Identifier (AID) – card
A00000005945430100
87 Application Priority Indicator
01
9F0A Unknown tag
0001050100000000
61 Application Template
4F Application Identifier (AID) – card
A0000003591010028001
87 Application Priority Indicator
01
9F0A Unknown tag
0001050100000000
61 Application Template
4F Application Identifier (AID) – card
D27600002547410100
87 Application Priority Indicator
01
9F0A Unknown tag
0001050100000000
There are 3 applications with 3 different AIDs available on the card:
A00000005945430100: Zentraler Kreditausschuss (ZKA) Germany Girocard Electronic Cash
A0000003591010028001: Euro Alliance of Payment Schemes s.c.r.l. – EAPS Belgium Girocard EAPS ZKA (Germany)
D27600002547410100: ZKA Germany Girocard ATM
Step 2: Now I'm reading the first AID using the "Select AID" command - the AID is 18 characters = 9 bytes long:
selectAidCommand: 00 A4 04 00 09 A0 00 00 00 59 45 43 01 00 00
selectAidResponse: 6F 47 84 09 A0 00 00 00 59 45 43 01 00 A5 3A 50 08 67 69 72 6F 63 61 72 64 87 01 01 9F 38 06 9F 02 06 9F 1D 02 5F 2D 04 64 65 65 6E BF 0C 1A 9F 4D 02 19 0A 9F 6E 07 02 80 00 00 30 30 00 9F 0A 08 00 01 05 01 00 00 00 00 90 00
Parsed response:
6F File Control Information (FCI) Template
84 Dedicated File (DF) Name
A00000005945430100
A5 File Control Information (FCI) Proprietary Template
50 Application Label
g i r o c a r d
87 Application Priority Indicator
01
9F38 Processing Options Data Object List (PDOL)
9F02 06
9F1D 02
5F2D Language Preference
d e e n
BF0C File Control Information (FCI) Issuer Discretionary Data
9F4D Log Entry
190A
9F6E Unknown tag
02800000303000
9F0A Unknown tag
0001050100000000
Step 3: get the processing options to read the card details
This is the first "tricky" point as it is not easy how to explain to get the right data for your card/AID. In the above response there is a section for the Processing Options Data Object List (PDOL) the card is requesting and the length of the fields - here we do have 2 fields with a length of 6 and 2 bytes, in total 8 bytes. The 8 bytes are just 8 "x00"s with the "header" 83 08, so the complete length is 10 bytes = x0A:
9F38 Processing Options Data Object List (PDOL)
9F02 06
9F1D 02
A more detailed explanation can be found here: https://stackoverflow.com/a/20810855/8166854
getProcessingOptionsCommand: 80 A8 00 00 0A 83 08 00 00 00 00 00 01 00 00 00
getProcessingOptionsResponse: 77 1E 82 02 19 80 94 18 18 01 01 00 20 01 01 00 20 04 04 00 08 05 05 01 08 07 07 01 08 03 03 01
Parsed response:
77 Response Message Template Format 2
82 Application Interchange Profile
1980
94 Application File Locator (AFL)
18010100 20010100 20040400 08050501 08070701 08030301
The most important part for the next step is the "Application File Locator (AFL)" - we need to read the file system with the data that are coded in these 4 byte blocks.
Step 4: read the records from the card
This is the part where I get lost when trying to read the card. You need to get the SFI and RECORD from the first 3 bytes of an AFL block and run a read record command. The following command reads the 4th sector of the AFL list - the command may work or not with your card and if it works you may get different data from your card.
WARNING: providing the response data to an internet form may reveal data like account number or
credit card number - my response is masked so the account number is not 1111111111:
readRecordCommand: 00 B2 05 0C 00
readRecordResponse: 70 38 5F 24 03 21 12 31 5A 0A 67 26 42 89 11 11 11 11 11 7F 5F 34 01 02 5F 28 02 02 80 9F 07 02 FF C0 9F 0D 05 FC 40 A4 80 00 9F 0E 05 00 10 18 00 00 9F 0F 05 FC 40 A4 98 00 90 00
Parsed response:
70 EMV Proprietary Template
5F24 Application Expiration Date
211231
5A Application Primary Account Number (PAN)
6726428911111111117F
5F34 Application Primary Account Number (PAN) Sequence Number
02
5F28 Issuer Country Code
0280
9F07 Application Usage Control
FFC0
9F0D Issuer Action Code – Default
FC40A48000
9F0E Issuer Action Code – Denial
0010180000
9F0F Issuer Action Code – Online
FC40A49800
I strongly recommend that you use a library for the steps 3 and 4; I'm using
https://github.com/devnied/EMV-NFC-Paycard-Enrollment
for this.
This is just a basic explanation for the first steps but now you get some useful responds from your card - good luck for your next steps.
A complete Android example app for the above mentioned library is here (disclaimer: I'm the author):
https://github.com/AndroidCrypto/Android-EMV-NFC-Paycard-Example

got UICC carrier priviliges but failed to open channel in android 5.1

I am trying to develop some functions with newly added UICC features in TelephonyManager in android 5.1,
using these configuration in my UICC and got UICC carrier privileges already.
( refer to https://source.android.com/devices/tech/config/uicc.html )
my UICC configuration in TLV format :
FF40
81 A8
E2 3E
E1 30 //UICC rule
C1 14 CD AE 0D 74 62 B8 ED 7D 58 68 59 23 16 45 E9 7C A5 DA 1F 90
CA 18 63 6f 6d 2e 74 61 69 73 79 73 2e 73 6d 61 72 74 63 61 72 64 74 65 73 74
E3 0A DB 08 FF FF FF FF FF FF FF FF
E2 32 //SEEK smartcard api AID and hash
E1 28
4F 10 01 A4 04 00 0B A0 00 00 00 18 47 50 41 43 2D 31 //AID
C1 14 EA 76 BC 02 00 00 3B 6E 0C 58 12 72 37 F4 1F F9 78 FC 10 6B //sha-1 hash
E3 06 //SEEK smartcard api rule
D0 01 01
D1 01 01
E2 32
E1 28 //uicc privilege AID and hash
4F 10 01 A4 04 00 0B A0 00 00 00 18 47 50 41 43 2D 32
C1 14 CD AE 0D 74 62 B8 ED 7D 58 68 59 23 16 45 E9 7C A5 DA 1F 90
E3 06
D0 01 01
D1 01 01
but after getting UICC privileges and trying to open iccOpenLogicalChannel, This is the stack trace I get when calling one of the above functions:
"java.lang.SecurityException: Only Smartcard API may access UICC"
How to modify the UICC configuration and open channel successfully in Telephonymanager ?
Thanks in advance !

Decrypting APDU response from iPhone6

I transmitted the following APDU command, from an android app, in my android phone,
send: 00 A4 04 00 07 A0 00 00 00 03 10 10 00
to an iPhone 6 through NFC and got the following response,
resp: 6F 39 84 07 A0 00 00 00 03 10 10 A5 2E 9F 38 1B 9F 66 04 9F 02 06 9F 03 06 9F 1A 02 95 05 5F 2A 02 9A 03 9C 01 9F 37 04 9F 4E 14 BF 0C 0D 9F 4D 02 14 01 9F 5A 05 11 08 40 08 40 90 00
Now, I've been trying to decrypt this using various sources, but the confusing part is to understand, whether this is the PKPaymenttoken data (which we receive in apple pay response) or is it just the encrypted card data from the passbook of iPhone 6.
I compared this result with the response that I got from PassKit- framework's-> paymentAuthorizationViewController method's-> payment.token string, both are completely different. So I guess its not the token response for apple pay. My concerns are,
Is this the encrypted card data itself? Can I decrypt it directly to get the card details? (After all, will Apple give out the card details that easily?)
My ultimate requirement is to accept payment through NFC in an Android phone from an iPhone6. So is my APDU request the correct one to obtain card data from iPhone6 (Passbook)?
Any thought is appreciated. Thanks.

I tried with the help of this link
https://github.com/devnied/EMV-NFC-Paycard-Enrollment
It really works. It gives device account number directly from the iPhone. No decryption needed to get this device account number.
How to use this lib
Download the library from this link
Use the code below
IProvider prov = new YourProvider();
// Create parser (true for contactless false otherwise)
EMVParser parser = new EMVParser(prov, true);
// Read card
EMVCard card = parser.readEmvCard();
You will get the card details in card object.
To answer your two major questions
This is just a response for APDU command, if you use the library I've mentioned, you will directly get the card details required for payment via any gateways.
The first answer is also the answer for your second question, you can read the iphone 6 from an android phone using the library. so just two steps Integrate the library -> get the card details -> forward to payment gateway. By this method, you need not send any private keys to the gateways, just send the card details like you do for normal card payment processing.

Is this the encrypted card data itself? Can I decrypt it directly to get the card details?
No and no. As Anand correctly pointed out in their answer, this is the FCI template returned in response to your SELECT (by AID/DF name) command concatenated with the status word 9000 (indicating success).
The FCI template is a TLV (tag-length-value) encoded data structure following basic encoding rules (BER). So your FCI
6F 39 84 07 A0 00 00 00 03 10 10 A5 2E 9F 38 1B 9F 66 04 9F 02 06 9F 03 06 9F 1A 02 95 05 5F 2A 02 9A 03 9C 01 9F 37 04 9F 4E 14 BF 0C 0D 9F 4D 02 14 01 9F 5A 05 11 08 40 08 40
decodes to (see http://www.emvlab.org/tlvutils/):
6F [39] File Control Information (FCI) Template
84 [07] Dedicated File (DF) Name
A0000000031010 (full AID of the application that you just selected)
A5 [2E] File Control Information (FCI) Proprietary Template
9F38 [1B] Processing Options Data Object List (PDOL)
9F66 04
9F02 06
9F03 06
9F1A 02
95 05
5F2A 02
9A 03
9C 01
9F37 04
9F4E 14
BF0C [0D] File Control Information (FCI) Issuer Discretionary Data
9F4D [02] Log Entry
1401 (Transaction log file with at most 1 record is available at SFI 0x14)
9F5A [05] Application Program Identifier (Program ID)
1108400840
My ultimate requirement is to accept payment [...]. So is my APDU request the correct one to obtain card data from iPhone6?
Partially, yes. After application selection, you will need to perform an EMV payment transaction (following the EMV specifications for contactless payment systems, you can get them form http://www.emvco.com/). However, be aware that this is not as easy as getting some "card data". You will need to retrieve some static card data from the contactless "card" (i.e. iPhone). In addition you will also need to let the iPhone generate some dynamic transaction cryptogram/transaction authorization code. You can then use this data to clear the transaction.

Its not encrypted data, it just FCI information
APDU send by you:
00 A4 04 00 07 A0 00 00 00 03 10 10 00.
P1=0x04 means you are selecting MF by DF name and P2=0x00 means returns FCI information.
Your response 6F 39 84 07 A0 00 00 00 03 10 10 A5 2E 9F 38 1B 9F 66 04 9F 02 06 9F 03 06 9F 1A 02 95 05 5F 2A 02 9A 03 9C 01 9F 37 04 9F 4E 14 BF 0C 0D 9F 4D 02 14 01 9F 5A 05 11 08 40 08 40 90 00
Your response description are as follows:
6F->its FCI templates(i.e. set of control parameters and management data).
39->6F tag length, these bytes are 6F tag data 84 07 A0 00 00 00 03 10 10 A5 2E 9F 38 1B 9F 66 04 9F 02 06 9F 03 06 9F 1A 02 95 05 5F 2A 02 9A 03 9C 01 9F 37 04 9F 4E 14 BF 0C 0D 9F 4D 02 14 01 9F 5A 05 11 08 40 08 40 90 00
84 means Tag for DF name
07 is the Lengths
A0 00 00 00 03 10 10 data values i.e. DF name
A5 is the Tag for Proprietary information encoded in BER-TLV
2E is the Length
9F 38 1B 9F 66 04 9F 02 06 9F 03 06 9F 1A 02 95 05 5F 2A 02 9A 03 9C 01 9F 37 04 9F 4E 14 BF 0C 0D 9F 4D 02 14 01 9F 5A 05 11 08 40 08 40 90 00->A5 tag values

Google wallet status is 'Unknown' after successfull 'Compute Crytographic Checksum' via Android isoDep.transceive

I'm still trying to emulate a point of sale (POS) system and complete a transaction with Google wallet.
I've gotten further with great answers on stack overflow.
See Android isoDep.transceive on Generate AC command always returns 6D00 unsupported
Even though every step of the communication from the POS and Google Wallet is successful, I can't get past Google wallet stating
"Status unknown, Check with cashier to see if the payment was successful".
I just need Google wallet to state "Status pending" just like at McDonalds (in the US).
I actually don't care if the whole transaction processes and clears my bank.
I'm new to transaction processing and it seems like I'm missing a fundamental step.
Any ideas would be greatly appreciated.
The following are the successful steps.
Step 1 Select Proximity Payment System Environment (2PAY.SYS.DDF01)
Send = 00 A4 04 00 0E 32 50 41 59 2E 53 59 53 2E 44 44 46 30 31 00
Response = 6f2f 840e 325041592e5359532e4444463031 a51d bf0c1a61184f07a00000 00041010870101500a4d 617374657243617264 9000 (Success)
Step 2 Select Payment Service
Send = 00 A4 04 00 07 A0 00 00 00 04 10 10 00
Response = 6f1e 8407 a0000000041010 a513 500a 4d617374657243617264 870101 9f11 01 01 9000 (Success)
Step 3 Get Processing Options
Send = 80 a8 00 00 02 83 00 00
Response = 770a 8202 0000 9404 08010100 9000 (Success)
Step 4 Read Record
Send = 00 B2 01 0C 00
Response = 70 7c 9f 6c 02
00 01 9f 62 06
00 00 00 00 00
38 9f 63 06 00
00 00 00 03 c6
56 29 42 35 33
39 36 XX XX XX
XX 31 XX XX 39
XX XX XX XX 5e
20 2f 5e 31 34
30 37 31 30 31
34 30 31 30 30
30 30 30 30 30
30 30 30 9f 64
01 04 9f 65 02
00 38 9f 66 02
03 c6 9f 6b 13
53 96 XX XX 1X
X9 XX XX d1 40
71 01 40 10 00
00 00 00 0f 9f
67 01 04 9f 69
0f 9f 6a 04 9f
7e 01 9f 02 06
5f 2a 02 9f 1a
02 9000 (Success)
Step 5 Compute Crytographic Checksum
Send = 80 2A 8E 80 0F 00 00 00 12 00 00 00 00 00 01 00 08 40 08 40 00
Response = 77 0f 9f 61 02 XX XX 9f 60 02 XX XX 9f 36 02 20 fa 9000 (Success)
The "PayPass – M/Chip Transaction Processing" specification states
"After the completion of the COMPUTE CRYPTOGRAPHIC CHECKSUM response, the
PayPass card can be removed from the PayPass reader."
So I assumed POS to Google Wallet communication was done, but Google Wallet seems to need more information.

So I assumed POS to Google Wallet communication was done, but Google Wallet seems to need more information.
Correct. Google Wallet retrieves information about transactions trough the card issuer's online backend system (at least that was the case with pre 2.0 version of GW, but I would assume that's still the case). Thus if you do not perform a real transaction (one that runs through the Master Card network), Google Wallet has no means to retrieve details about the transaction for the online backend.