I need some help communicating with Desfire EV1 card. The library (winscard.dll) seems to be automatically handling all responses from the card that have an ADDITIONAL_FRAME (AF) byte so that the application receives already processed data. For example, I send the GetVersion command as follows:
[out] 90 60 00 00 00, and the response is:
[ in ] 04 01 01 01 00 18 05 04 01 01 01 04 18 05 04 83 71 2A 9F 43 80 BA 64 17 8F A0 07 15 91 00
Note: I wrapped the command data in ISO 7816 headers.
I expected the communication to be something like this:
[out] 90 60 00 00 00
[ in ] 04 01 01 01 00 18 05 91 AF
[out] 90 AF 00 00 00
[ in ] 04 01 01 01 04 18 05 91 AF
[out] 90 AF 00 00 00
[ in ] 04 83 71 2A 9F 43 80 BA 64 17 8F A0 07 15 91 00.
The same thing happens during card authentication so when I send
[out] 90 0A 00 00 01 00 00, I get back
[ in ] 91 00
instead of a card challenge.
Is there a way to disable this behaviour?
Thanks.
Related
I am writing a small x86-64 hobby OS I boot with UEFI. I am currently writing a driver for the Intel's xHC. I am at a point where I can address USB devices and have a Transfer Ring allocated for Endpoint 0 of each device. I then use a GET_DESCRIPTOR request to get the configuration descriptor of each device. I ask QEMU to emulate a USB keyboard and a USB mouse. I thus get 2 different descriptors which are the following:
user#user-System-Product-Name:~$ hexdump -C result.bin
00000000 09 02 22 00 01 01 06 a0 32 09 04 00 00 01 03 01 |..".....2.......|
00000010 02 00 09 21 01 00 00 01 22 34 00 07 05 81 03 04 |...!...."4......|
00000020 00 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00001000 09 02 22 00 01 01 08 a0 32 09 04 00 00 01 03 01 |..".....2.......|
00001010 01 00 09 21 11 01 00 01 22 3f 00 07 05 81 03 08 |...!...."?......|
00001020 00 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00001030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00002000
Basically, I ask GDB to output the content of RAM where I placed the descriptors in the file result.bin. Then I hexdump the content of result.bin in the console. Here you can see the configuration of the USB mouse first. Then, 1 page later, the configuration of the USB keyboard.
The configuration descriptor of the mouse is 09 02 22 00 01 01 06 a0 32. It is followed with 2 interface descriptors: 09 04 00 00 01 03 01 02 00 and 09 21 01 00 00 01 22 34 00. Those are followed by one endpoint descriptor: 07 05 81 03 08 00 07.
In the first interface descriptor for both the mouse and the keyboard, it is indicated that there is one endpoint descriptor (indicated by the bNumEndpoints field of the descriptor which is byte number 4 indexed from 0). I would expect that the following descriptor is the endpoint descriptor. Instead, I get a second interface descriptor (indicated by the fact that it has a length of 9 bytes instead of 7 and by the values of the different fields).
As stated on https://wiki.osdev.org/Universal_Serial_Bus:
Each CONFIGURATION descriptor has at least one INTERFACE descriptor, and each INTERFACE descriptor may have up to 15 ENDPOINT descriptors. When the host requests a certain CONFIGURATION descriptor, the device returns the CONFIGURATION descriptor followed immediately by the first INTERFACE descriptor, followed immediately by all of the ENDPOINT descriptors for endpoints that the interface defines (which may be none). This is followed immediately by the next INTERFACE descriptor if one exists, and then by its ENDPOINT descriptors if applicable. This pattern continues until all the information within the scope of the specific configuration is transfered.
Why do I get 2 interface descriptors followed by the endpoint descriptor in my case? Is it a QEMU bug or is it something I should expect?
You're not accurately describing the binary data that I see in your shell output.
The dump starts with 9-byte descriptor of type 2 so that is your device descriptor:
09 02 22 00 01 01 06 a0 32
Then there is a 9-byte descriptor of type 4, so that is an interface, and it has bNumEndpoints set to 1:
09 04 00 00 01 03 01 02 00
Then there is another 9-byte descriptor of type 0x21. I don't recognize that code off the top of my head, but it probably is something standard:
09 21 01 00 00 01 22 34 00
Then we have a 7-byte descriptor of type 5, so that is an endpoint descriptor:
07 05 81 03 04 00 07
As it is the first time that I use globalplatform with javacardos (JCIDE), I noticed that I could not download the applet when in the code I put:
private void processGetCardStatus(APDU apdu) {
byte[] buffer = apdu.getBuffer();
short le = apdu.setOutgoing();
if ( le < (byte)1 )
ISOException.throwIt(ISO7816.SW_WRONG_LENGTH);
apdu.setOutgoingLength( (byte)1);
buffer[0] = (byte)GPSystem.getCardState();
apdu.sendBytes((short)0, (short)1);
}
Downloading cap file with PyApduTool give me an error:
Download Cap error: Download cap file failed. Send: 80 E8 00 00 F0 C4 82 04 29 01 00 1B DE CA FF ED 02 02 04 00 01 05 01 02 03 04 05 0B 6D 6F 6E 70 61 63 6B 61 67 65 32 02 00 21 00 1B 00 21 00 0A 00 1E 00 7E 00 14 02 AE 00 0A 00 60 00 00 01 19 09 6E 00 00 00 00 00 00 03 01 00 04 00 1E 03 03 01 07 A0 00 00 00 62 01 01 07 01 06 A0 00 00 01 51 00 00 01 07 A0 00 00 00 62 00 01 03 00 0A 01 06 01 02 03 04 05 00 00 64 06 00 14 00 00 00 80 03 03 00 02 04 04 00 00 00 7D FF FF 00 70 00 85 07 02 AE 00 05 43 18 8C 00 18 18 10 40 04 8D 00 05 87 00 18 8F 00 03 3D 06 10 08 8C 00 04 87 01 19 1E 25 29 04 1E 16 04 41 04 41 31 19 1E 25 29 05 1E 16 05 41 04 41 31 19 1E 25 29 06 19 1E 04 41 AD 00 03 16 06 8D 00 06 3B 18 8F 00 03 3D 06 10 08 8C 00 04 87 01 AD 01 19 1E 04 41 16 06 8B 00 07 18 8B 00, Recv: 6A 80.
but when i comment the line from code above, i can download the CAP file:
//buffer[0] = (byte)GPSystem.getCardState();
i use GlobalPlatform API 1.7, my card is J2A040, based, JCOP 2.4.1, JC 2.2.2, GP 2.1.1., T=1, SCP02
On top of code i have
import org.globalplatform.GPSystem;
Where is the problem, is it coming from the API version?
Thanks for your response.
Problem, resolved. it's because on JCIDE Javacardos, i need to add jar container, by select package, click right, properties, Libray Option, and click button Add Jar Container, and select Global Platform 2.1.1
I need to be able to inspect ts packets (looking at video PID 481) and determine whether the packet contains an IDR frame. My understanding is that I need to look for a NAL unit start code, and then something else after that to signify it's the start of an IDR frame. Please can someone clarify?
Here's an example of a packet that I think is an IDR frame, but need to be able to prove it from the payload data:
* Packet 2
---- TS Header ----
PID: 481 (0x01E1), header size: 12, sync: 0x47
Error: 0, unit start: 1, priority: 0
Scrambling: 0, continuity counter: 1
Adaptation field: yes (8 bytes), payload: yes (176 bytes)
Discontinuity: 1, random access: 1, ES priority: 0
PCR: 0x000000013A5
---- PES Header ----
Stream id: 0xE0 (Video 0)
PES packet length: 0 (unbounded)
---- Full TS Packet Content ----
47 41 E1 31 07 D0 00 00 00 08 7E E5 00 00 01 E0 00 00 84 C0 0A 31 00 05
E5 CD 11 00 05 AD 8D 00 00 00 01 09 10 00 00 00 01 67 64 00 29 AC D9 40
78 04 4F DE 02 94 04 04 05 00 00 03 00 01 00 00 03 00 32 E6 80 00 F4 24
00 04 F5 8A 49 30 0F 8B 16 CB 00 00 00 01 68 FA A7 CB 00 00 01 06 00 05
95 6C 60 E4 85 80 00 00 01 06 05 FF FF F5 DC 45 E9 BD E6 D9 48 B7 96 2C
D8 20 D9 23 EE EF 78 32 36 34 20 2D 20 63 6F 72 65 20 31 34 38 20 2D 20
48 2E 32 36 34 2F 4D 50 45 47 2D 34 20 41 56 43 20 63 6F 64 65 63 20 2D
20 43 6F 70 79 72 69 67 68 74 20 32 30 30 33 2D 32 30 31 36
Its not possible to tell from that packet. It is however VERY likely it is an IDR. I say its likely, because looking at the NALUs, I can see an AUD 00 00 00 01 09, an SPS 00 00 00 01 67 a PPS 00 00 00 01 68 then an SEI 00 00 01 06
The SEI however takes the remaining bytes of the packet, You will need to continue reading packets from that PID until you fine the next NALU and see if its an IDR.
I need to connect to an SSL server. When I connect using OpenSSL 1.0.1r it works fine:
CONNECTED(00000304)
write to 0x6e13e8 [0x730a98] (297 bytes => 297 (0x129))
0000 - 16 03 01 01 24 01 00 01-20 03 03 16 f2 71 5f 26 ....$... ....q_&
0010 - a5 9b 64 cb 8f 0b 27 65-8d a3 54 e6 de a5 18 7a ..d...'e..T....z
0020 - 3c 5a e4 08 ab ff 6a 92-d7 45 f3 00 00 8a c0 30 <Z....j..E.....0
0030 - c0 2c c0 28 c0 24 c0 14-c0 0a 00 a3 00 9f 00 6b .,.(.$.........k
0040 - 00 6a 00 39 00 38 00 88-00 87 c0 32 c0 2e c0 2a .j.9.8.....2...*
0050 - c0 26 c0 0f c0 05 00 9d-00 3d 00 35 00 84 c0 2f .&.......=.5.../
0060 - c0 2b c0 27 c0 23 c0 13-c0 09 00 a2 00 9e 00 67 .+.'.#.........g
0070 - 00 40 00 33 00 32 00 9a-00 99 00 45 00 44 c0 31 .#.3.2.....E.D.1
0080 - c0 2d c0 29 c0 25 c0 0e-c0 04 00 9c 00 3c 00 2f .-.).%.......<./
0090 - 00 96 00 41 00 07 c0 11-c0 07 c0 0c c0 02 00 05 ...A............
00a0 - 00 04 c0 12 c0 08 00 16-00 13 c0 0d c0 03 00 0a ................
00b0 - 00 15 00 12 00 09 00 ff-01 00 00 6d 00 0b 00 04 ...........m....
00c0 - 03 00 01 02 00 0a 00 34-00 32 00 0e 00 0d 00 19 .......4.2......
00d0 - 00 0b 00 0c 00 18 00 09-00 0a 00 16 00 17 00 08 ................
00e0 - 00 06 00 07 00 14 00 15-00 04 00 05 00 12 00 13 ................
00f0 - 00 01 00 02 00 03 00 0f-00 10 00 11 00 23 00 00 .............#..
0100 - 00 0d 00 20 00 1e 06 01-06 02 06 03 05 01 05 02 ... ............
0110 - 05 03 04 01 04 02 04 03-03 01 03 02 03 03 02 01 ................
0120 - 02 02 02 03 00 0f 00 01-01 .........
>>> TLS 1.2 Handshake [length 0124], ClientHello
01 00 01 20 03 03 16 f2 71 5f 26 a5 9b 64 cb 8f
0b 27 65 8d a3 54 e6 de a5 18 7a 3c 5a e4 08 ab
ff 6a 92 d7 45 f3 00 00 8a c0 30 c0 2c c0 28 c0
24 c0 14 c0 0a 00 a3 00 9f 00 6b 00 6a 00 39 00
38 00 88 00 87 c0 32 c0 2e c0 2a c0 26 c0 0f c0
05 00 9d 00 3d 00 35 00 84 c0 2f c0 2b c0 27 c0
23 c0 13 c0 09 00 a2 00 9e 00 67 00 40 00 33 00
32 00 9a 00 99 00 45 00 44 c0 31 c0 2d c0 29 c0
25 c0 0e c0 04 00 9c 00 3c 00 2f 00 96 00 41 00
07 c0 11 c0 07 c0 0c c0 02 00 05 00 04 c0 12 c0
08 00 16 00 13 c0 0d c0 03 00 0a 00 15 00 12 00
09 00 ff 01 00 00 6d 00 0b 00 04 03 00 01 02 00
0a 00 34 00 32 00 0e 00 0d 00 19 00 0b 00 0c 00
18 00 09 00 0a 00 16 00 17 00 08 00 06 00 07 00
14 00 15 00 04 00 05 00 12 00 13 00 01 00 02 00
03 00 0f 00 10 00 11 00 23 00 00 00 0d 00 20 00
1e 06 01 06 02 06 03 05 01 05 02 05 03 04 01 04
02 04 03 03 01 03 02 03 03 02 01 02 02 02 03 00
0f 00 01 01
read from 0x6e13e8 [0x735ff8] (7 bytes => 7 (0x7))
0000 - 16 03 03 00 57 02 ....W.
0007 - <SPACES/NULS>
read from 0x6e13e8 [0x736002] (85 bytes => 85 (0x55))
0000 - 00 53 03 03 56 bb 11 21-1a ac 49 84 2d be 94 ad .S..V..!..I.-...
0010 - a0 c4 57 46 bc 70 d0 84-95 ce 96 c6 8c 92 07 2e ..WF.p..........
0020 - 4e 13 d6 f3 20 aa d7 86-ca 48 5e 01 a1 8c d3 f1 N... ....H^.....
0030 - d7 74 f9 2c 84 48 7d c1-95 6d 22 81 ff 53 ab d3 .t.,.H}..m"..S..
0040 - 0c 89 81 7d a2 00 3d 00-00 0b 00 0b 00 02 01 00 ...}..=.........
0050 - ff 01 00 01 ....
0055 - <SPACES/NULS>
<<< TLS 1.2 Handshake [length 0057], ServerHello
02 00 00 53 03 03 56 bb 11 21 1a ac 49 84 2d be
94 ad a0 c4 57 46 bc 70 d0 84 95 ce 96 c6 8c 92
07 2e 4e 13 d6 f3 20 aa d7 86 ca 48 5e 01 a1 8c
d3 f1 d7 74 f9 2c 84 48 7d c1 95 6d 22 81 ff 53
ab d3 0c 89 81 7d a2 00 3d 00 00 0b 00 0b 00 02
01 00 ff 01 00 01 00
read from 0x6e13e8 [0x735ffb] (5 bytes => 5 (0x5))
// etc.
However when I connect using OpenSSL 1.0.2f, the server closes the connection immediately:
CONNECTED(00000300)
write to 0x7812d0 [0x7ceef0] (317 bytes => 317 (0x13D))
0000 - 16 03 01 01 38 01 00 01-34 03 03 45 1c 09 c2 2e ....8...4..E....
0010 - 46 06 85 a1 01 fd 0a 2c-bb 6f 15 10 42 74 b3 bf F......,.o..Bt..
0020 - 9f 2e 5c 00 9f f2 93 8e-c0 18 9c 00 00 b6 c0 30 ..\............0
0030 - c0 2c c0 28 c0 24 c0 14-c0 0a 00 a5 00 a3 00 a1 .,.(.$..........
0040 - 00 9f 00 6b 00 6a 00 69-00 68 00 39 00 38 00 37 ...k.j.i.h.9.8.7
0050 - 00 36 00 88 00 87 00 86-00 85 c0 32 c0 2e c0 2a .6.........2...*
0060 - c0 26 c0 0f c0 05 00 9d-00 3d 00 35 00 84 c0 2f .&.......=.5.../
0070 - c0 2b c0 27 c0 23 c0 13-c0 09 00 a4 00 a2 00 a0 .+.'.#..........
0080 - 00 9e 00 67 00 40 00 3f-00 3e 00 33 00 32 00 31 ...g.#.?.>.3.2.1
0090 - 00 30 00 9a 00 99 00 98-00 97 00 45 00 44 00 43 .0.........E.D.C
00a0 - 00 42 c0 31 c0 2d c0 29-c0 25 c0 0e c0 04 00 9c .B.1.-.).%......
00b0 - 00 3c 00 2f 00 96 00 41-00 07 c0 11 c0 07 c0 0c .<./...A........
00c0 - c0 02 00 05 00 04 c0 12-c0 08 00 16 00 13 00 10 ................
00d0 - 00 0d c0 0d c0 03 00 0a-00 15 00 12 00 0f 00 0c ................
00e0 - 00 09 00 ff 01 00 00 55-00 0b 00 04 03 00 01 02 .......U........
00f0 - 00 0a 00 1c 00 1a 00 17-00 19 00 1c 00 1b 00 18 ................
0100 - 00 1a 00 16 00 0e 00 0d-00 0b 00 0c 00 09 00 0a ................
0110 - 00 23 00 00 00 0d 00 20-00 1e 06 01 06 02 06 03 .#..... ........
0120 - 05 01 05 02 05 03 04 01-04 02 04 03 03 01 03 02 ................
0130 - 03 03 02 01 02 02 02 03-00 0f 00 01 01 .............
>>> TLS 1.2 [length 0005]
16 03 01 01 38
>>> TLS 1.2 Handshake [length 0138], ClientHello
01 00 01 34 03 03 45 1c 09 c2 2e 46 06 85 a1 01
fd 0a 2c bb 6f 15 10 42 74 b3 bf 9f 2e 5c 00 9f
f2 93 8e c0 18 9c 00 00 b6 c0 30 c0 2c c0 28 c0
24 c0 14 c0 0a 00 a5 00 a3 00 a1 00 9f 00 6b 00
6a 00 69 00 68 00 39 00 38 00 37 00 36 00 88 00
87 00 86 00 85 c0 32 c0 2e c0 2a c0 26 c0 0f c0
05 00 9d 00 3d 00 35 00 84 c0 2f c0 2b c0 27 c0
23 c0 13 c0 09 00 a4 00 a2 00 a0 00 9e 00 67 00
40 00 3f 00 3e 00 33 00 32 00 31 00 30 00 9a 00
99 00 98 00 97 00 45 00 44 00 43 00 42 c0 31 c0
2d c0 29 c0 25 c0 0e c0 04 00 9c 00 3c 00 2f 00
96 00 41 00 07 c0 11 c0 07 c0 0c c0 02 00 05 00
04 c0 12 c0 08 00 16 00 13 00 10 00 0d c0 0d c0
03 00 0a 00 15 00 12 00 0f 00 0c 00 09 00 ff 01
00 00 55 00 0b 00 04 03 00 01 02 00 0a 00 1c 00
1a 00 17 00 19 00 1c 00 1b 00 18 00 1a 00 16 00
0e 00 0d 00 0b 00 0c 00 09 00 0a 00 23 00 00 00
0d 00 20 00 1e 06 01 06 02 06 03 05 01 05 02 05
03 04 01 04 02 04 03 03 01 03 02 03 03 02 01 02
02 02 03 00 0f 00 01 01
read from 0x7812d0 [0x7d4450] (7 bytes => 0 (0x0))
10124:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:.\ssl\s23_lib.c:177:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 317 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1455100247
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
I don't suppose anyone speaks ClientHello sufficiently well to tell me what the difference is, and how to get OpenSSL 1.0.2f to behave like the old version (even if it is insecure; I don't control the server).
I checked both traces with Wireshark, and the only significant differences I can see are that OpenSSL 1.0.2's ClientHello packet is identified as "SSL" by Wireshark, and the record layer is SSL:
Whereas OpenSSL 1.0.1 is identified as TLS 1.2. It also has fewer cypher suites (I guess they removed some insecure ones?).
I've tried the following combinations, and these are how Wireshark labels them in the "Protocol" column:
1.0.1: <no options>=TLSv1.2; -ssl2=SSLv2; -ssl3=SSLv3; -tls1_2=TLSv1.2
1.0.2: <no options>=SSL; -ssl2=SSLv2; -ssl3=SSLv3; -tls1_2=SSL
Any ideas about:
Why Wireshark decodes 1.0.1 and 1.0.2 differently?
Why the connection is failing with 1.0.2?
How I can get OpenSSL 1.0.2 to behave like 1.0.1?
Why Wireshark decodes 1.0.1 and 1.0.2 differently?
See SSL Record Layer vs SSLv3 Record Layer on the Wireshark Q&A bulletin board and Secure Socket Layer (SSL) on the Wireshark wiki.
Why the connection is failing with 1.0.2?
Looks like a buggy server that's rejecting a record layer that's not an early one, like one used in SSLv3.
The record layer is just that... It specifies the version of the record layer, which is simply the framing of SSL/TLS protocol messages. It is not a MIN-TLS-VERSION as many people think.
The TLS protocol version is just that... It specifies the version of the SSL/TLS protocol. It is not a MAX-TLS-VERSION as many people think.
How I can get OpenSSL 1.0.2 to behave like 1.0.1?
Use the following in your client, but its not exactly the same. The OpenSSL client will do the right thing and select TLS 1.2 if its available:
/* Uses the early record layer for downlevel servers */
const SSL_METHOD* method = SSLv23_method();
if(NULL == method) handleFailure();
ctx = SSL_CTX_new(method);
if(ctx == NULL) handleFailure();
/* Cannot fail ??? */
const long flags = SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3 | SSL_OP_NO_TLSv1 | SSL_OP_NO_TLSv1_1 | SSL_OP_NO_COMPRESSION;
SSL_CTX_set_options(ctx, flags);
I checked OpenSSL 1.0.2's ssl/ssl.h, and both SSL_OP_NO_TLSv1 and SSL_OP_NO_TLSv1_1 are available.
There's a different way to do it for OpenSSL Master (a.k.a, OpenSSL 1.1.0 and above); see Working around servers requiring SSL 2/3 record layer, and using TLS 1.2?
... [OpenSSL 1.0.2] also has fewer cipher suites (I guess they removed some insecure ones?).
You should not leave cipher suites to chance. You should do something like the following:
const char* const PREFERRED_CIPHERS = "HIGH:!aNULL:!kRSA:!PSK:!SRP:!MD5:!RC4";
res = SSL_set_cipher_list(ssl, PREFERRED_CIPHERS);
if(res != 1) handleFailure();
The !PSK and !SRP simply removes cipher suites that are not usually used. !MD5 and !RC4 are removed for servers to help avoid the Obsolete cryptography warning from Browser.
You could even do the following:
const char* const PREFERRED_CIPHERS =
"ECDHE-ECDSA-AES256-GCM-SHA384:"
"ECDHE-RSA-AES256-GCM-SHA384:"
"ECDHE-ECDSA-AES128-GCM-SHA256:"
"ECDHE-RSA-AES128-GCM-SHA256:"
"DHE-DSS-AES256-GCM-SHA384:"
"DHE-RSA-AES256-GCM-SHA384:"
"DHE-DSS-AES128-GCM-SHA256:"
"DHE-RSA-AES128-GCM-SHA256";
res = SSL_set_cipher_list(ssl, PREFERRED_CIPHERS);
if(res != 1) handleFailure();
Be sure to always offer a AES/GCM cipher suite because as server configurations move to a TLS 1.2-only configuration, that's the cipher suite they usually choose.
Also, each cipher suite takes up to bytes in the ClientHello, and you want to minimize the number of them. You want to minimize them because some older Proxies and Interception boxes use a fixed size buffer for the client's ClientHello, and they can't handle the proliferation of cipher suite options available in TLS 1.2. The older boxes include F5 and Ironport middleware.
Why Wireshark decodes 1.0.1 and 1.0.2 differently?
No idea.
Why the connection is failing with 1.0.2?
Hard to tell but I've seen several servers having problems with some ciphers added to OpenSSL 1.0.2 or that too much ciphers were given or similar. I've seen similar problems with recent LibreSSL versions. In this case the servers have obviously broken TLS stacks.
How I can get OpenSSL 1.0.2 to behave like 1.0.1?
You can try to reduce the cipher set so that it only uses the same ciphers as OpenSSL 1.0.1. Notable I've seen servers croak ChaCha20-Poly1305 was inside the cipher set, probably they did not understand what kind of cipher this is.
I have an OTI Copni device and I need to install a .cap file to this Copni device. So I have JCOP tools with Eclipse and I try to upload and install. It then gives this the indicated error. I presume this is happening because of a failed authentication.
cm> /term "winscard:4|SCM Microsystems Inc. SDI011G Contactless Reader 0"
--Opening terminal
> /card -a a000000003000000 -c com.ibm.jc.CardManager
resetCard with timeout: 0 (ms)
--Waiting for card...
ATR=3B 88 80 01 00 73 C8 40 00 00 90 00 62 ;....s.#....b
ATR: T=0, T=1, Hist=0073C84000009000
=> 00 A4 04 00 08 A0 00 00 00 03 00 00 00 00 ..............
(21592 usec)
<= 6F 65 84 08 A0 00 00 00 03 00 00 00 A5 59 9F 65 oe...........Y.e
01 FF 9F 6E 06 47 91 20 17 3F 00 73 4A 06 07 2A ...n.G. .?.sJ..*
86 48 86 FC 6B 01 60 0C 06 0A 2A 86 48 86 FC 6B .H..k.`...*.H..k
02 02 01 01 63 09 06 07 2A 86 48 86 FC 6B 03 64 ....c...*.H..k.d
0B 06 09 2A 86 48 86 FC 6B 04 02 15 65 0B 06 09 ...*.H..k...e...
2B 85 10 86 48 64 02 01 03 66 0C 06 0A 2B 06 01 +...Hd...f...+..
04 01 2A 02 6E 01 02 90 00 ..*.n....
Status: No Error
cm> set-key 255/1/DES-ECB/404142434445464748494a4b4c4d4e4f 255/2/DES-ECB/404142434445464748494a4b4c4d4e4f 255/3/DES-ECB/404142434445464748494a4b4c4d4e4f
cm> init-update 255
=> 80 50 00 00 08 C2 3F 4B C4 BE B6 E5 58 00 .P....?K....X.
(43622 usec)
<= 00 00 32 98 00 09 30 97 06 25 01 02 00 10 68 6C ..2...0..%....hl
E3 CA 2C 2B 4D 2C 4B 0D 0E 62 5F 8C 90 00 ..,+M,K..b_...
Status: No Error
cm> ext-auth plain
=> 84 82 00 00 10 EB FC 66 BC FA 30 91 58 5B 51 FA .......f..0.X[Q.
0C 46 D7 43 C9 .F.C.
(12557 usec)
<= 69 85 i.
Status: Conditions of use not satisfied
jcshell: Error code: 6985 (Conditions of use not satisfied)
jcshell: Wrong response APDU: 6985
Unexpected error; aborting execution
Can someone tell me how to upload a .cap file to this device?
Try ext-auth mac instead, the smart card is probably in the state OP_SECURE, which means that at minimal command MAC is required.
As JCOP tools is not publicly available nor open source, I'd suggest you try a publicly available piece of software instead:
https://github.com/martinpaljak/GlobalPlatform#globalplatform-from-openkms
(as the name of the github repository implies this is self-promotion)