I have problems using Crypto++ to save a RSA public key string. When decoding the key, I always get a BERDecodeErr exception.
Code:
string RsaEncryptor::encryptor(string plaintext, string publicKey)
{
std::string cipher;
AutoSeededRandomPool prng;
try
{
ByteQueue queue;
Base64Decoder decoder(new Redirector(queue));
decoder.Put((const byte *) publicKey.data(), publicKey.size());
decoder.MessageEnd();
RSA::PublicKey rsaPublick;
rsaPublick.BERDecodePublicKey(queue, false, (size_t) queue.MaxRetrievable());
// BERDecodePrivateKey is a void function. Here's the only check
// we have regarding the DER bytes consumed.
CRYPTOPP_ASSERT(queue.IsEmpty());
bool valid = rsaPublick.Validate(prng, 3);
if (!valid)
cipher = "RSA private key is not valid";
RSAES_OAEP_SHA_Encryptor e(rsaPublick);
StringSource ss(plaintext, true,
new PK_EncryptorFilter(prng, e,
new StringSink(cipher)
) // PK_EncryptorFilter
); // StringSource
}
catch (CryptoPP::Exception &e) {
cipher = e.what();
}
return cipher;
}
The public key is:
MIGdMA0GCSqGSIb3DQEBAQUAA4GLADCBhwKBgQDs648aASMAR9VprkzNVS7b36N1hiYvbBG0c
dE0QkS3H/sc3+Ej92lGBQErpBu9LVhwN/beBX4QnbCn1eNSrKoOzS4yqWlwOaCe0WLmFDHCn1
cMTkX89cT4A0pcjBbY+0W7htxWcqHxEQH9x/AjQ9/4blerh1i6/lLIo6hn2hB8kQIB
MIGdMA0GCSqGSIb3DQEBAQUAA4GLADCBhwKBgQDs648aASMAR9VprkzNVS7b36N1hiYvbBG0c
dE0QkS3H/sc3+Ej92lGBQErpBu9LVhwN/beBX4QnbCn1eNSrKoOzS4yqWlwOaCe0WLmFDHCn1
cMTkX89cT4A0pcjBbY+0W7htxWcqHxEQH9x/AjQ9/4blerh1i6/lLIo6hn2hB8kQIB
The key is malformed.
Stripping the Base64 encoding:
FileSource fs1("key.b64", true, new Base64Decoder);
FileSink fs2("key.der");
fs1.CopyTo(fs2);
And then viewing it under Gutmann's dumpasn1 reveals:
$ dumpasn1 key.der
0 157: SEQUENCE {
3 13: SEQUENCE {
5 9: OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1 1)
16 0: NULL
: }
18 139: BIT STRING, encapsulates {
22 135: SEQUENCE {
25 129: INTEGER
: 00 EC EB 8F 1A 01 23 00 47 D5 69 AE 4C CD 55 2E
: DB DF A3 75 86 26 2F 6C 11 B4 71 D1 34 42 44 B7
: 1F FB 1C DF E1 23 F7 69 46 05 01 2B A4 1B BD 2D
: 58 70 37 F6 DE 05 7E 10 9D B0 A7 D5 E3 52 AC AA
: 0E CD 2E 32 A9 69 70 39 A0 9E D1 62 E6 14 31 C2
: 9F 57 0C 4E 45 FC F5 C4 F8 03 4A 5C 8C 16 D8 FB
: 45 BB 86 DC 56 72 A1 F1 11 01 FD C7 F0 23 43 DF
: F8 6E 57 AB 87 58 BA FE 52 C8 A3 A8 67 DA 10 7C
: 91
157 1: INTEGER -1
: Error: Integer has a negative value.
: }
: }
: }
From above, the problem ASN.1 is at position 157. Looking at the file sizes:
-rw-r--r-- 1 jwalton staff 261 Oct 18 23:09 key.b64
-rw-r--r-- 1 jwalton staff 159 Oct 18 23:18 key.der
It looks like there's two byte remaining to be processed. The 02 is the ASN.1 tag for an INTEGER. It should be followed by a length and a value, but there's only the length octet (01) is present. The value is missing.
$ xxd -g 1 key.der
0000000: 30 81 9d 30 0d 06 09 2a 86 48 86 f7 0d 01 01 01 0..0...*.H......
0000010: 05 00 03 81 8b 00 30 81 87 02 81 81 00 ec eb 8f ......0.........
0000020: 1a 01 23 00 47 d5 69 ae 4c cd 55 2e db df a3 75 ..#.G.i.L.U....u
0000030: 86 26 2f 6c 11 b4 71 d1 34 42 44 b7 1f fb 1c df .&/l..q.4BD.....
0000040: e1 23 f7 69 46 05 01 2b a4 1b bd 2d 58 70 37 f6 .#.iF..+...-Xp7.
0000050: de 05 7e 10 9d b0 a7 d5 e3 52 ac aa 0e cd 2e 32 ..~......R.....2
0000060: a9 69 70 39 a0 9e d1 62 e6 14 31 c2 9f 57 0c 4e .ip9...b..1..W.N
0000070: 45 fc f5 c4 f8 03 4a 5c 8c 16 d8 fb 45 bb 86 dc E.....J\....E...
0000080: 56 72 a1 f1 11 01 fd c7 f0 23 43 df f8 6e 57 ab Vr.......#C..nW.
0000090: 87 58 ba fe 52 c8 a3 a8 67 da 10 7c 91 02 01 .X..R...g..|...
Here's another view of the problem. 02 is the ASN.1 INTEGER, 01 is the length of the integer, but the value is missing:
0000090: 87 58 ba fe 52 c8 a3 a8 67 da 10 7c 91 ***02 01 ??***
Here's what a good 1024 bit key looks like. Its different than yours:
$ dumpasn1 key.der
0 157: SEQUENCE {
3 13: SEQUENCE {
5 9: OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1 1)
16 0: NULL
: }
18 139: BIT STRING, encapsulates {
22 135: SEQUENCE {
25 129: INTEGER
: 00 D0 52 BA 4B 3F 44 AA 7B C9 C2 84 46 17 D6 17
: A0 43 03 69 7B 18 06 5B D4 EA 29 E2 74 24 40 62
: 58 16 52 9D 73 82 77 D7 9D 13 97 53 71 76 9F B2
: 99 CA 36 1E D4 E1 DF 0D BE C4 07 1E A0 F2 F2 E9
: EF 32 FA 00 4B 0B 8E C2 91 BA 8B 1D 1C 4D F0 98
: 6C 64 C5 9E 4D EE 58 17 06 20 C9 3C 9A F0 33 BB
: A8 FC 7B 7B 6C F9 C6 FD A0 17 76 3A 3D 1D 7E E7
: 42 C2 49 AD 4C 26 AE B6 F6 DC 99 A3 24 99 1A 30
: D9
157 1: INTEGER 17
: }
: }
: }
0 warnings, 0 errors.
Notice there are two octets following the 02 (01 11 below), and not one octet (like yours):
$ xxd -g 1 key.der
0000000: 30 81 9d 30 0d 06 09 2a 86 48 86 f7 0d 01 01 01 0..0...*.H......
0000010: 05 00 03 81 8b 00 30 81 87 02 81 81 00 d0 52 ba ......0.......R.
0000020: 4b 3f 44 aa 7b c9 c2 84 46 17 d6 17 a0 43 03 69 K?D.{...F....C.i
0000030: 7b 18 06 5b d4 ea 29 e2 74 24 40 62 58 16 52 9d {..[..).t$#bX.R.
0000040: 73 82 77 d7 9d 13 97 53 71 76 9f b2 99 ca 36 1e s.w....Sqv....6.
0000050: d4 e1 df 0d be c4 07 1e a0 f2 f2 e9 ef 32 fa 00 .............2..
0000060: 4b 0b 8e c2 91 ba 8b 1d 1c 4d f0 98 6c 64 c5 9e K........M..ld..
0000070: 4d ee 58 17 06 20 c9 3c 9a f0 33 bb a8 fc 7b 7b M.X.. .<..3...{{
0000080: 6c f9 c6 fd a0 17 76 3a 3d 1d 7e e7 42 c2 49 ad l.....v:=.~.B.I.
0000090: 4c 26 ae b6 f6 dc 99 a3 24 99 1a 30 d9 02 01 11 L&......$..0....
Related
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.
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?
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
I am trying to play AAC audio live stream coming from Red5 server, so to decode the audio data i am using Javacv-ffmpeg. Data is received as packets of byte[]
Here is what i tried
public Frame decodeAudio(byte[] adata,long timestamp){
BytePointer audio_data = new BytePointer(adata);
avcodec.AVCodec codec1 = avcodec.avcodec_find_decoder(avcodec.AV_CODEC_ID_AAC);// For AAC
if (codec1 == null) {
Log.d("showit","avcodec_find_decoder() error: Unsupported audio format or codec not found: " + audio_c.codec_id() + ".");
}
audio_c = null;
audio_c = avcodec.avcodec_alloc_context3(codec1);
audio_c.sample_rate(44100);
audio_c.sample_fmt(3);
audio_c.bits_per_raw_sample(16);
audio_c.channels(1);
if ((ret = avcodec.avcodec_open2( audio_c, codec1, (PointerPointer)null)) < 0) {
Log.d("showit","avcodec_open2() error " + ret + ": Could not open audio codec.");
}
if (( samples_frame = avcodec.avcodec_alloc_frame()) == null)
Log.d("showit","avcodec_alloc_frame() error: Could not allocate audio frame.");
avcodec.av_init_packet(pkt2);
samples_frame = avcodec.avcodec_alloc_frame();
avcodec.av_init_packet(pkt2);
pkt2.data(audio_data);
pkt2.size(audio_data.capacity());
pkt2.pts(timestamp);
pkt2.pos(0);
int len = avcodec.avcodec_decode_audio4( audio_c, samples_frame, got_frame, pkt2);
}
But len after decoding returns -1 for first frame and then -22 always.
First packet is like this always
AF 00 12 08 56 E5 00
Further packets are like
AF 01 01 1E 34 2C F0 A4 71 19 06 00 00 95 12 AE AA 82 5A 38 F3 E6 C2 46 DD CB 2B 09 D1 00 78 1D B7 99 F8 AB 41 6A C4 F4 D2 40 51 17 F5 28 51 9E 4C F6 8F 15 39 49 42 54 78 63 D5 29 74 1B 4C 34 9B 85 20 8E 2C 0E 0C 19 D2 E9 40 6E 9C 85 70 C2 74 44 E4 84 9B 3C B9 8A 83 EC 66 9D 40 1B 42 88 E2 F3 65 CF 6D B3 20 88 31 29 94 29 A4 B4 DE 26 B0 75 93 3A 0C 57 12 8A E3 F4 B9 F9 23 9C 69 C9 D4 BF 9E 26 63 F2 78 D6 FD 36 B9 32 62 01 91 19 71 30 2D 54 24 62 A1 20 1E BA 3D 21 AC F3 80 33 3A 1A 6C 30 3C 44 29 F2 A7 DC 9A FF 0F 99 F2 38 85 AB 41 FD C7 C5 40 5C 3F EE 38 70
Couldn't figure out where is the problem, whether in setting the AVcodec context audio_c or setting packet for decoder.
Any help appreciated. Thanks in advance.
The first packet (config) describes the stream data if I'm not mistaken the follow on data is the encoded audio. You can't assume the sample rate etc.. as you have done above, you need to pull that out of the config data which is marked "AF 00".
I have a similar problem. I've intercepted the packets with Wireshark and here is what it told me:
AF is the control byte of AAC frame, and it decodes to following bits:
1010 .... = Format: HE-AAC
.... 11.. = Sample rate: 44kHz (allthough FFMPEG shows me 48kHz and I would lean to believe it more)
.... ..1. = Sample size: 16 bit
.... ...1 = Channels: stereo
I still can't figure out how to universally decode this data.
edit:
Ha! I've got something :)
I guess the first 2 bytes are RTMP specific bytes. The second one seems to state, whether it is the configuration (0) or actual payload (1) - i've found no sources confirming that, it is just my assumption.
Then the first, short package is the AAC configuration description described here:
http://thompsonng.blogspot.com/2010/03/aac-configuration.html
In my case it is:
11 90
which is binary:
0001 0001 1001 0000
and that decodes to:
0001 0... .... .... = 2 = AAC LC
.... .001 1... .... = 3 = 48 kHz
.... .... .001 0... = 2 = 2 channels (stereo)
.... .... .... .0.. = 0 = 1024 sample length
.... .... .... ..0. = 0 = doesn't depends on core code (?)
.... .... .... ...0 = 0 = extension flag