While testing my app (https://play.google.com/apps/testing/com.degoo.android) I've found that on some devices the TLS handshake between the app and our servers fail if the https request requires a client certificate (i.e. mutual authentication). The same code works on Windows and on OS X, so I know that it's not caused by an incorrect cert or that I have forgotten to include the cert into the SSLContext. I have detected it on both some Android 4.4 devices and on some 5.0 devices. Unfortunately I haven't found any common denominator which causes it to fail (other than Android). However, on devices were it fails it fails 100% of the time.
I've analyzed the network traffic to see more precisely when the error occurs. The following thing works on all devices:
The connection is established and the client successfully validates the server's certs.
The client sends it's HTTP request.
The server detects that the request is for protected area and sends a certificate_request.
The client decides which client certificate to send (we can see that it selects the correct certificate) and sends it.
After the client has responded with its certificate it sends two more TLS records and then the handshake fails.
Here's an example of how what these two TLS records looks like on a device were the handshake SUCCEEDS:
14 03 01 00 20 9c 07 49 78 9f ba 09 03 41 6b 66 ad 46 e2 75 94 f7 cf 18 bd 11 cf 35 a2 eb 5e b8 a8 4c 2a 1d c5
16 03 01 00 30 20 0e 13 d7 48 b9 6e b2 1b 96 6f 10 56 67 81 63 d9 d8 c7 73 23 95 3b f9 da f9 ce f4 f8 d1 7e 1b a4 12 92 4c 4f 54 a5 f8 49 75 d5 46 f4 2d 29 97
Here's an example of how what these two TLS records looks like on a device were the handshake FAILS:
14 03 01 00 20 a9 86 c2 fd 03 0a f8 08 fa f8 9e eb b7 97 07 56 6f 27 c0 d6 8f 95 be 77 c1 44 84 e9 e1 56 6f 6a
16 03 01 00 30 ff 36 76 e5 47 87 84 71 1c ce c9 08 41 45 fc 09 c6 ef 08 e6 21 ff 45 3a 10 ae 8d 5a 99 5f ca c5 ac bd bf 7e ca 69 32 4d 1f 01 c6 30 83 8e 06 cb
From the first byte of the records I can see that both clients send a change cipher spec record and then a handshake record. A funny thing about the failing devices is that byte with index 5 of the second record has value ff. When I look in TLS specification I don't see any handshake record type with that value. The device that succeeds has that byte set to 20, which means "finished".
Any idea on what's going on? What could cause this?
Related
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
I'm really stuck on getting a video stream to play on a java fx project.
-- Short version:
I'm streaming h264/avcc flavor video from an android phone to a desktop computer. However javafx doesn't have an easy solution for displaying stream. I'm attempting to use javacv / ffmpeg in an attempt to make this work. However I am getting errors from ffmpeg.
1) Is there a better way to display streaming video on javafx?
2) Do you have a sample project or good tutorial for javacv ffmpegframegrabber?
3) I think I may be missing some small detail in mycode but Im not sure what i would be.
-- Longer Version:
1) On the android end Im getting video using mediarecorder. In order to get the sps/pps info I record and save a small movie to the device and then parse the sps and pps data.
2) Next, on the android, I split up the nalus to meet MTU req and send them over a udp connection to my desktop
3)On my desktop I reassmble the nalus( or trash them if they loose data) and feed those to an input stream that I gave to the framegreabber constructor.
-- The Code and Logs:
The errors are long and numerous depending on the flavor I feed it. Here are two separate examples which are usually repeated at great length
[h264 # 0000020225907a40] non-existing PPS 0 referenced
[h264 # 0000020225907a40] decode_slice_header error
[h264 # 0000020225907a40] no frame!
[h264 # 00000163d8637a40] illegal aspect ratio
[h264 # 00000163d8637a40] pps_id 3412 out of range
[AVBSFContext # 00000163e28a0e00] Invalid NAL unit 0, skipping.
!! One big caveat that I am aware off is that I have not implemented timestamps
which I created on the android device when feeding ffmpeg. I think it should still show distorted images without this though
Because I have spent all day guessing and trying I have several "flavors" of data I have shoved through. I am only showing the first section of each nal which I believe if correct would at least show a garbage image as long as my sps and pps are right
sps: 67 80 80 1E E9 01 68 22 FD C0 36 85 09 A8
pps: 68 06 06 E2
Below is annex B style.
These were each prefixed with either 00 00 01 and 00 00 00 01
Debug transfer 65 B8 40 0B E5 B8 7B 80 5B 85
Debug transfer 41 E2 20 7A 74 34 3B D6 BE FA
Debug transfer 41 E4 40 2F 01 E0 0C 06 EE 91
Debug transfer 41 E6 60 3E A1 20 5A 02 3C 6D
Debug transfer 41 E8 80 13 B0 B9 82 C3 03 F4
Debug transfer 41 EC C0 1B A3 0C 28 F1 B0 C8
Debug transfer 41 EE E0 1F CE 07 30 EE 05 06
Debug transfer 41 F1 00 08 ED 80 9C 20 09 73
Debug transfer 41 F3 20 09 E9 00 86 60 21 C3
VideoDecoderaddPacket type: 24
Debug transfer 67 80 80 1E E9 01 68 22 FD C0
Debug transfer 68 06 06 E2
Debug transfer 65 B8 20 00 9F 80 78 00 12 8A
Debug transfer 41 E2 20 09 F0 1E 40 7B 0C E0
Debug transfer 41 E4 40 09 F0 29 30 D6 00 AE
Debug transfer 41 E6 60 09 F1 48 31 80 99 40
[h264 # 000001c771617a40] non-existing PPS 0 referenced
Here I tried Avcc style. You can see the first line is the combination of the sps pps followed by idr and then repeated non idr
Debug transfer 18 00 0E 67 80 80 1E E9 01 68
Debug transfer 00 02 4A 8F 65 B8 20 00 9F C5
Debug transfer 00 02 2F DA 41 E2 20 09 E8 0F
Debug transfer 00 02 2C 34 41 E4 40 09 F4 20
Debug transfer 00 02 4D 92 41 E6 60 09 FC 2B
Debug transfer 00 02 47 02 41 E8 80 09 F0 72
Debug transfer 00 02 52 50 41 EA A0 09 EC 0F
Debug transfer 00 02 58 8A 41 EC C0 09 FC 6F
Debug transfer 00 02 55 F9 41 EE E0 09 FC 6E
Debug transfer 00 02 4D 79 41 F1 00 09 F0 3E
Debug transfer 00 02 4D B6 41 F3 20 09 E8 64
The following class is where I try to get javacv/ffmpeg to show the video. I dont think its an ideal solution and am researching canvasfram as a replacement to the image view.
public class ImageDecoder {
private final static String TAG = "ImageDecoder ";
private ImageDecoder(){
}
public static void streamImageToImageView(
final ImageView view,
final InputStream inputStream,
final String format,
final int frameRate,
final int bitrate,
final String preset,
final int numBuffers
)
{
System.out.println("Image Decoder Starting...");
try( final FrameGrabber grabber = new
FFmpegFrameGrabber(inputStream))
{
final Java2DFrameConverter converter = new Java2DFrameConverter();
grabber.setFrameNumber(frameRate);
grabber.setFormat(format);
grabber.setVideoBitrate(bitrate);
grabber.setVideoOption("preset", preset);
grabber.setNumBuffers(numBuffers);
System.out.println("Image Decoder waiting on grabber.start...");
grabber.start(); //---- this call is blocking the loop
System.out.println("Image Decoder Looping---------------------------
-------- hit stop");
while(!Thread.interrupted()){
//System.out.println("Image Decoder Looping");
final Frame frame = grabber.grab();
if (frame != null){
final BufferedImage bufferedImage =
converter.convert(frame);
if (bufferedImage != null){
Platform.runLater(() ->
view.setImage(SwingFXUtils.toFXImage(bufferedImage, null)));
}else{
System.out.println("no buf im");
}
}else{
System.out.println("no fr");
Thread.currentThread().interrupt();
}
}
}catch (Exception e){
System.out.print(TAG + e);
}
}
}
Any help is greatly appreciated.
So I had two problems.
The first was that my sps pps parsing method had a mistake. Notice the 2nd and 3rd bytes are same
The second was I accidentally over sized a buffer and created large 0x00 padded areas which emulated start codes.
This was a big project for me and I want to help other. Please visit my website where I wrote a lengthy multi-part discussion about streaming h264
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 !
I am working on an client - server application project with an Android client and Apache server and mutual authentication (i.e., client certificate). I am poor in SSL/TLS.
Server authentication get done all okay but when it comes to client authentication this error: ssl23_get_server_hello:tlsv1 alert handshake failure happens. I have also checked packets using WireShark many times and i also have created self signed certificates using my self created CA many times.
I should mention I've set Apache SSLVerifyClient property on "require" and SSLVerifyDepth on 1 and SSLCACertificateFile is set also. on "optional" everything is okay but i dont want it to be like that.
It seems everything is okay and without problem on my localhost when I test it using openssl s_client and I address client cert and key and CA file .
c:\OpenSSL-Win64\bin>openssl s_client -connect 192.168.1.55:443 -key c:\xampp\apache\conf\ssl.key\client.key
-cert c:\xampp\apache\conf\ssl.crt\client.crt -CAfile c:\xampp\apache\conf\ssl.crt\ca.crt
Enter pass phrase for c:\xampp\apache\conf\ssl.key\client.key:
CONNECTED(0000011C)
depth=1 C = ir, ST = khuzestan, L = dezful, O = nama, OU = nama, CN = Nama System
verify return:1
depth=0 C = ir, ST = khuzestan, L = dezful, O = nama, OU = nama, CN = 192.168.1.55
verify return:1
---
Certificate chain
0 s:/C=ir/ST=khuzestan/L=dezful/O=nama/OU=nama/CN=192.168.1.55
i:/C=ir/ST=khuzestan/L=dezful/O=nama/OU=nama/CN=Nama System
1 s:/C=ir/ST=khuzestan/L=dezful/O=nama/OU=nama/CN=Nama System
i:/C=ir/ST=khuzestan/L=dezful/O=nama/OU=nama/CN=Nama System
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDQTCCAikCAQEwDQYJKoZIhvcNAQELBQAwZjELMAkGA1UEBhMCaXIxEjAQBgNV
BAgMCWtodXplc3RhbjEPMA0GA1UEBwwGZGV6ZnVsMQ0wCwYDVQQKDARuYW1hMQ0w
CwYDVQQLDARuYW1hMRQwEgYDVQQDDAtOYW1hIFN5c3RlbTAeFw0xNjEwMDcxODE0
MjdaFw0xNzEwMDcxODE0MjdaMGcxCzAJBgNVBAYTAmlyMRIwEAYDVQQIDAlraHV6
ZXN0YW4xDzANBgNVBAcMBmRlemZ1bDENMAsGA1UECgwEbmFtYTENMAsGA1UECwwE
bmFtYTEVMBMGA1UEAwwMMTkyLjE2OC4xLjU1MIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEAo3U+hTqP6911dUELWS9V4h1W172KKNXq/eJqnWO32+nraVHI
jPiFDcU9qRDFNSUdbFAokOrtXVZXePebNKpgbzVW2EDp3EtU4OXzYd/32YEaW0NB
SXS8eQDoJZ4+d1wl/vIM5jRovGmnNEv94XQbeGrUKdYSzaZL0Zilcg7Qop2mG3cq
EKGLCZm2tTzgkRTwkng0L7ODq1SZE4yoy5T+WNqnEOjOlQ2hVfio8HGAgGqJXUY+
YHgj0Shk6nFfg5pRpH15poNRgVGlizqLolN/EUf2CzV12MCyjdri8d5ZMfrTbszN
lwpUzp/3K3CGYjSqzEWL+9j85dE11Lrdix+rcwIDAQABMA0GCSqGSIb3DQEBCwUA
A4IBAQA1XaLfV36GBpOBw32fMvoK7K9XkwP52lvMYgcAPWZFjFvdZnysndDKntFe
cQXZdKnEzm3GNUv4APAEyj97VWnFKKM3lDLaMy99jWavdMNvyU4WpjT4DWj5kP0w
9Esc2fNDv6/A1ME4Ty1XUwNbfDjbG/pz0WZn00bgvbKwmA0GjHYFZTYC0W4wdion
dP9NPTJNENmOIeIE2N4tIPuieMTeCYqwRNplVldmzgeDYKW+n15glvRF1+18kuAC
xNj6bMTOwS2aY5DXthFeLNXWerspcgyUdTss/TdIJxO+pzA1s8ZN8E6RwqfIeKWv
gIwkTiitf8InLsQVRzxEzcmR5V15
-----END CERTIFICATE-----
subject=/C=ir/ST=khuzestan/L=dezful/O=nama/OU=nama/CN=192.168.1.55
issuer=/C=ir/ST=khuzestan/L=dezful/O=nama/OU=nama/CN=Nama System
---
Acceptable client certificate CA names
/C=ir/ST=khuzestan/L=dezful/O=nama/OU=nama/CN=Nama System
Client Certificate Types: RSA sign, DSA sign, ECDSA sign
Requested Signature Algorithms: RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA+SHA1:ECDSA+SHA1
Shared Requested Signature Algorithms: RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA+SHA1:ECDSA+SHA1
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3440 bytes and written 2352 bytes
Verification: OK
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: 155B16EEDAF469AB0E4604A02CAEF4C3FFF20834DE2E25CAD801480CB1E40B2C
Session-ID-ctx:
Master-Key: C83DD8E4633A8DECF0410FA1ED4591F49A10AC24E3B59DC1F6CFC2E5B05878EEB7589EE5F51237E51A01E7017A1F594E
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - 6e c4 ab eb 6f d2 04 b3-81 73 9d cf fc a6 20 08 n...o....s.... .
0010 - 08 1d 1e bc 9e 01 e5 0e-c6 c7 a3 81 02 a9 3d 04 ..............=.
0020 - 5c 86 aa e6 b8 f0 ad 97-a8 e4 bd 44 5b a9 97 17 \..........D[...
0030 - 39 81 71 bf 0c 67 4a b2-fd d9 fe d8 aa c9 5e af 9.q..gJ.......^.
0040 - 21 78 c5 e0 30 c7 5c 0c-4a 62 84 15 4b 45 48 68 !x..0.\.Jb..KEHh
0050 - a6 f8 3b 02 61 1a f2 43-11 54 c1 dc 73 3a 2a 27 ..;.a..C.T..s:*'
0060 - 61 f1 32 df a8 0b 21 c5-fd 02 ff 86 d6 da 7a 79 a.2...!.......zy
0070 - ae af 92 9e 2b a5 e8 eb-dc f8 c8 9b ec 5c a0 58 ....+........\.X
0080 - 75 f5 c7 92 e4 01 49 66-be a2 96 fd 5a 36 34 08 u.....If....Z64.
0090 - c2 eb 14 30 f8 54 45 43-e0 4f 83 45 a1 3d 33 37 ...0.TEC.O.E.=37
00a0 - 0c fc 8f 46 8e f8 28 f3-0f df b7 db 71 2a 81 0e ...F..(.....q*..
00b0 - 39 2d 85 08 52 29 cf d1-8a 56 d6 b9 ca 24 10 a0 9-..R)...V...$..
00c0 - 86 44 68 56 13 dc c7 7b-8d 45 c1 8c c4 b4 be 5d .DhV...{.E.....]
00d0 - 91 75 4c e9 a9 61 a1 d5-af 37 70 d9 7b 7d 9a bd .uL..a...7p.{}..
00e0 - 92 85 cc d9 a8 64 9c bf-7b 8f 89 67 9a 15 d7 47 .....d..{..g...G
00f0 - 56 e9 45 39 35 b6 d5 e2-8d a6 75 0e 71 4d 9b b0 V.E95.....u.qM..
0100 - 0e 97 ae 60 37 49 bd ed-97 93 35 98 10 45 a2 0b ...`7I....5..E..
0110 - dc a2 c9 af 3b 38 98 f9-af ab 65 83 80 fc b2 19 ....;8....e.....
0120 - 10 b7 f6 4f 72 3d fd 2b-9c 18 90 9e be 32 0e 68 ...Or=.+.....2.h
0130 - 60 ac 0f 13 94 b0 9e 80-d4 14 44 41 70 7d 40 86 `.........DAp}#.
0140 - dd 04 66 da 5b 05 69 d3-57 db c9 e0 e5 76 4e 5e ..f.[.i.W....vN^
0150 - b5 07 d1 2b 47 ba 8e f1-92 38 68 b0 23 9e 98 4e ...+G....8h.#..N
0160 - dc aa fd 51 52 e0 7c 7b-f9 0e 30 58 d2 ae 80 5f ...QR.|{..0X..._
0170 - f2 85 0a 48 ab d6 6e 1c-ee 1b 1b 3d c6 b6 13 f6 ...H..n....=....
0180 - ab cc 57 8d d8 90 cc 46-7c 6f af ff 83 46 b4 3d ..W....F|o...F.=
0190 - 1b c7 ed b4 f1 bd 91 c1-6e 22 7f 47 8c b1 39 ef ........n".G..9.
01a0 - 98 7b bc a2 09 0a 2e 76-13 e3 98 6f a1 b7 a3 bd .{.....v...o....
01b0 - 3f 8b 0e cd ca f3 65 83-a4 6f 8c 48 4a fa 82 db ?.....e..o.HJ...
01c0 - 96 f6 c5 e3 57 cf da 26-14 7f 91 65 cc a3 37 b3 ....W..&...e..7.
01d0 - 4d 96 c9 4c 8a e4 cb c4-db 77 10 69 82 d5 7b e2 M..L.....w.i..{.
01e0 - 0d 9e 62 8a 20 95 3a 8a-27 76 60 fa a8 4b 29 88 ..b. .:.'v`..K).
01f0 - e5 90 e7 49 e9 a8 9e 14-8a f5 8f 06 da eb 1f 4c ...I...........L
0200 - b5 e7 9a d9 9b ed db 12-11 e2 f4 2b df cb 6f 73 ...........+..os
0210 - 4e aa 53 a2 e7 04 ff 9c-de bc 5e 21 42 0c b7 2a N.S.......^!B..*
0220 - 1f d3 b9 1a b7 9b 25 92-ef 81 70 d5 1b 4d d5 9b ......%...p..M..
0230 - 65 40 52 c8 b4 cd b4 6b-ab d8 42 31 e0 2a 9f d4 e#R....k..B1.*..
0240 - 35 78 34 b3 34 b5 9d 53-c2 56 82 ff e7 99 8b a6 5x4.4..S.V......
0250 - bd 7b a5 a1 86 25 ce 45-ee 44 d4 14 19 0c 97 41 .{...%.E.D.....A
0260 - b1 a2 c9 eb 5a c8 13 39-09 7a fa 58 15 83 fe e3 ....Z..9.z.X....
0270 - e4 a7 5b f4 b7 74 65 bb-f7 5d d1 88 47 e2 a4 c3 ..[..te..]..G...
0280 - 45 af 6e 31 86 73 19 1e-20 7c 3a a2 69 88 67 30 E.n1.s.. |:.i.g0
0290 - de 3c 75 e0 d5 d4 1e 10-d8 80 ea ca 99 0a e7 c6 .<u.............
02a0 - f5 8d ca 83 2c 23 3e 32-ec e6 72 6c 1d f1 6e 37 ....,#>2..rl..n7
02b0 - 45 de ce 5b df a0 54 69-c5 a9 9d 9b 8f a5 7c 8c E..[..Ti......|.
02c0 - 0b 7d c4 b5 16 64 69 20-4e ca 0f 68 01 e9 bd db .}...di N..h....
02d0 - e5 17 a9 b7 40 d3 dc fd-c1 2a d7 3f a4 f8 2d e2 ....#....*.?..-.
02e0 - f8 1f 83 25 44 d7 54 bb-e2 e6 5b 34 73 99 89 89 ...%D.T...[4s...
02f0 - cd c8 49 53 cf f3 52 a4-c4 e6 9b b1 c6 16 85 1e ..IS..R.........
0300 - e8 0a af d0 8c 7e ab 6e-65 d6 2f 01 ff 59 b5 49 .....~.ne./..Y.I
0310 - 41 56 cd 4a 3f de 75 3a-21 30 9b bc 14 66 71 87 AV.J?.u:!0...fq.
0320 - 59 4e a2 e3 03 a1 95 7a-7a 28 7d 5a 09 05 d3 0a YN.....zz(}Z....
0330 - ea 4f 77 61 74 48 e4 6c-44 5b 7a 5c ed 6c f9 07 .OwatH.lD[z\.l..
0340 - 96 ee a6 69 16 22 3b 8f-8c 53 a2 d2 b7 eb f5 3a ...i.";..S.....:
0350 - 8f 36 8e 2d 6e 59 58 7c-06 02 81 fb e2 c0 56 c2 .6.-nYX|......V.
0360 - 4e 43 89 29 fd 68 0c 36-fc db 0a aa 77 70 c5 e9 NC.).h.6....wp..
0370 - ea c2 78 9e 65 c0 10 12-73 90 54 22 80 4b 24 c9 ..x.e...s.T".K$.
0380 - 74 39 41 d0 0c 59 61 1b-f2 eb 16 2b 35 19 88 13 t9A..Ya....+5...
0390 - 58 79 22 83 03 2c 2c 49-52 10 7c a4 a5 ea 3a b2 Xy"..,,IR.|...:.
03a0 - e9 94 51 70 44 71 ee 6a-1c 34 b4 aa 76 dd d3 08 ..QpDq.j.4..v...
03b0 - 92 7d b8 db 04 47 3e ca-ea 6c 24 ac ae 9e 4f 15 .}...G>..l$...O.
03c0 - 32 f2 34 30 9d 7d 67 29-51 17 89 26 d1 bb ec 1b 2.40.}g)Q..&....
03d0 - 7d b2 b0 18 1f ed 84 bc-23 bb 21 04 1a 1e f5 88 }.......#.!.....
03e0 - 10 c0 9e 97 ed f7 ee 9e-37 8f 57 27 38 59 e9 62 ........7.W'8Y.b
03f0 - 69 58 ac 09 80 c4 42 05-93 2c 39 2e f1 3e ba f4 iX....B..,9..>..
Start Time: 1476823635
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
---
It seems problem is android client authentication. My Android device version which i test the app on is Android 4.4 (Kitkat) and my Apache cipher suite is like this:
SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-GCM-SHA256:AES256+EDH:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GC$
i have searched a lot and i guess the problem can be client and server Ciphers mismatch , but i am not sure if its right and i dont know how to fix it.
Thank you very much for the help.
UPDATE:
I am using NoSSLv3SocketFactory.java class to avoid sslv3.
it turned to this error: SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure, and here is my packet capture my packet capture
and here is also my ssl access log :
[19/Oct/2016:00:47:46 +0330] 192.168.1.55 TLSv1 ECDHE-RSA-AES256-SHA "-" -
[19/Oct/2016:01:08:41 +0330] 192.168.1.55 TLSv1 ECDHE-RSA-AES256-SHA "-" -
Based on the information so far, especially the image of the packet capture, it looks like:
Client and server successfully agree on a cipher (otherwise server would not sent its ServerHello)
Client accepts the servers certificate (otherwise client would complain instead of continuing with the handshake)
Client sends its own certificate
Server sends back an alert: handshake_failure
The most likely thing is that the server does not like the clients certificate. Since the test with openssl s_client and a client certificate shows a successful handshake it might be that the Android client is sending a different certificate than used with the other test. Digging deeper into the packet capture should show, which certificate is sent by the client. Apart from that information about the problem should be visible on the server side, i.e. in server logs or similar.
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