I am using OrmLite over SQLite with SQLCipher to encrypt a database on Android. Is there a way to cipher a Room database?
Room by default store data in the app's internal storage which any root user can access.
if you need some security you need to use encryption lib like this cwac-saferoom.
SQLCipher for Android now directly supports Room. You can find the documentation here
Consequently, #CommonsWare will not be actively developing cwac-saferoom any longer and recommends using SQLCipher's support
Android Room DB explicitly doesn't support encryption. A typical
SQLite database in unencrypted. You can use SQLCipher for Android with
Room or other consumers of the androidx.sqlite API to Secure Your Data
stored in sqlite DB. QLCipher has a SupportFactory class in
the net.sqlcipher.database package that can be used to configure Room
to use SQLCipher for Android. See the hexdumps of a standard SQLite db
and one implementing SQLCipher.
~ sjlombardo$ hexdump -C sqlite.db
00000000 53 51 4c 69 74 65 20 66 6f 72 6d 61 74 20 33 00 |SQLite format 3.|
…
000003c0 65 74 32 74 32 03 43 52 45 41 54 45 20 54 41 42 |et2t2.CREATE TAB|
000003d0 4c 45 20 74 32 28 61 2c 62 29 24 01 06 17 11 11 |LE t2(a,b)$…..|
…
000007e0 20 74 68 65 20 73 68 6f 77 15 01 03 01 2f 01 6f | the show…./.o|
000007f0 6e 65 20 66 6f 72 20 74 68 65 20 6d 6f 6e 65 79 |ne for the money|
~ $ sqlite3 sqlcipher.db
sqlite> PRAGMA KEY=’test123′;
sqlite> CREATE TABLE t1(a,b);
sqlite> INSERT INTO t1(a,b) VALUES (‘one for the money’, ‘two for the show’);
sqlite> .quit
~ $ hexdump -C sqlcipher.db
00000000 84 d1 36 18 eb b5 82 90 c4 70 0d ee 43 cb 61 87 |.?6.?..?p.?C?a.|
00000010 91 42 3c cd 55 24 ab c6 c4 1d c6 67 b4 e3 96 bb |.B?..?|
00000bf0 8e 99 ee 28 23 43 ab a4 97 cd 63 42 8a 8e 7c c6 |..?(#C??.?cB..|?|
~ $ sqlite3 sqlcipher.db
sqlite> SELECT * FROM t1;
Error: file is encrypted or is not a database
https://github.com/sqlcipher/android-database-sqlcipher
Related
I'm trying to send BLE Notification from android (GAP:central, GATT:server) to peer device (GAP: peripheral, GATT: client).
The problem is that on android 5.0 there is command: BluetoothGatt.requestMtu(int mtu).
But I do not know the way how to find out if peer device support requested MTU and what is actually negotiated MTU.
The required function:
BluetoothGattCallback.onMtuChanged(BluetoothGatt gatt, int mtu, int status)
was added only in API level 22 (Android L 5.1).
My problem is that I do not know how many bytes in packet I can send.
I write a test code to send bigger packet than 20B and it seems android sends just first 20B of data and never tell me that it discarded rest of the data!!! That is terrible behavior. Either I'm missing something, or Android 5.0 is useless for bigger packets than 20 bytes :(
I wrote test code and logs prove that all is sent and returns true:
BluetoothGattCharacteristic mCharacVal;
BluetoothGattServer mGattServer;
...
//log: I/vbeOryNotify: bleNotify snd:msg body; id:27; len:60 :I should have known those alien maggots booby-trapped this s
ret = mCharacVal.setValue(toSnd);
Log.i("vbeOry","bleNotify: setValue "+AppCommon.ByteArrayToHexStr(toSnd)+" ret:"+ret);
//log: I/vbeOry: bleNotify: setValue 03 1B 00 00 00 3C 49 20 73 68 6F 75 6C 64 20 68 61 76 65 20 6B 6E 6F 77 6E 20 74 68 6F 73 65 20 61 6C 69 65 6E 20 6D 61 67 67 6F 74 73 20 62 6F 6F 62 79 2D 74 72 61 70 70 65 64 20 74 68 69 73 20 73
//log: ret:true
byte[] dataRdBck = mCharacVal.getValue();
Log.i("vbeOry","bleNotify: getValue "+AppCommon.ByteArrayToHexStr(dataRdBck));
//log: I/vbeOry: bleNotify: getValue 03 1B 00 00 00 3C 49 20 73 68 6F 75 6C 64 20 68 61 76 65 20 6B 6E 6F 77 6E 20 74 68 6F 73 65 20 61 6C 69 65 6E 20 6D 61 67 67 6F 74 73 20 62 6F 6F 62 79 2D 74 72 61 70 70 65 64 20 74 68 69 73 20 73
ret = mGattServer.notifyCharacteristicChanged(device, mCharacVal, false);
Log.i("vbeOry","bleNotify: notifyCharacteristicChanged "+AppCommon.ByteArrayToHexStr(toSnd)+" ret:"+ret);
//log: I/vbeOry: bleNotify: notifyCharacteristicChanged 03 1B 00 00 00 3C 49 20 73 68 6F 75 6C 64 20 68 61 76 65 20 6B 6E 6F 77 6E 20 74 68 6F 73 65 20 61 6C 69 65 6E 20 6D 61 67 67 6F 74 73 20 62 6F 6F 62 79 2D 74 72 61 70 70 65 64 20 74 68 69 73 20 73
//log: ret:true
Even from call back I do not get any error:
private BluetoothGattServerCallback mGattServerCallback = new BluetoothGattServerCallback() {
public void onNotificationSent(BluetoothDevice device, int status){
Log.i("vbeGattServ", "onNotificationSent status: "+status);
//log: I/vbeGattServ: onNotificationSent status: 0
but then I look with my BLE analyzer and I see that only first 20 B of notification data is send:
So my question is either how to find out negotiated MTU or at least how to find out that not all data was sent? (Constrain is Android 5.0).
Perhaps it has no solution for Android 5.0 :( And I have to stick with 20B even when both device could support higher. Only work around would be to implement mechanism for returning MTU from peer device as was suggested here on stack overflow.
Your issue is not Android but Bluetooth / the app running on your central.
Increasing the useful data size from 20B is only possible with BLE v4.2 and newer. I suppose your radio is running with BLE v4.0 or v4.1 or there is an issue setting up your MTU.
Either way this should not affect reading data. The central device can read a characteristic with an offset. Assuming you have 60B, you would have 3 requests from the central:
Read, offset=0
Read, offset=20
Read, offset=40
TL;DR: Your GATT central simply handles reads wrong.
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 am trying to communicate between PN532 and HCE on Android with ISO 7816-4 command, I am successfully select the AID (a DF), but when I select the EF under that DF (that EF does not exist, so I assume that Select command will create that EF), and then write the records to that EF but it display like this:
inList passive target
write: 4A 1 0
read: 4B 1 1 0 4 60 4 8 23 5A 4D 5 75 80 70 2
write: 40 1 0 A4 4 0 7 F0 1 2 3 4 5 6 0
read: 41 0 48 65 6C 6C 6F 20 44 65 73 6B 74 6F 70 21
Successfully hehe
48 65 6C 6C 6F 20 44 65 73 6B 74 6F 70 21 Hello Desktop!
write: 40 1 0 A4 2 C 1 1 0
read: 41 0 48 65 6C 6C 6F 20 44 65 73 6B 74 6F 70 21
Not enough space
write: 40 1 0 D2 0 0 7 42 41 4F 47 49 41 40 0
read: 41 0 4D 65 73 73 61 67 65 20 66 72 6F 6D 20 61 6E 64 72 6F 69 64 3A 20 30
Not enough space
write: 40 1 0 D2 0 2 4 44 4F 41 4E 0
read: 41 0 4D 65 73 73 61 67 65 20 66 72 6F 6D 20 61 6E 64 72 6F 69 64 3A 20 31
Not enough space
write: 40 1 0 B2 0 0 7 42 41 4F 47 49
read: 41 0 4D 65 73 73 61 67 65 20 66 72 6F 6D 20 61 6E 64 72 6F 69 64 3A 20 32
Not enough space
write: 40 1 0 B2 0 2 4 44 4F 41 4E 0
read: 41 0 4D 65 73 73 61 67 65 20 66 72 6F 6D 20 61 6E 64 72 6F 69 64 3A 20 33
Not enough space
I don't know what I am doing wrong here?
On Android, the log is :
04-15 09:36:54.024: D/HostEmulationManager(929): notifyHostEmulationData
04-15 09:36:54.024: W/System.err(17710): [B#41ed5970
04-15 09:36:54.024: I/HCEDEMO(17710): Received: ???????BAOGI
04-15 09:36:54.024: D/HostEmulationManager(929): Sending data
04-15 09:36:54.164: D/BrcmNfcJni(929): RoutingManager::stackCallback: event=0x17
04-15 09:36:54.164: D/BrcmNfcJni(929): RoutingManager::stackCallback: NFA_CE_DATA_EVT; h=0x302; data len=10
04-15 09:36:54.164: D/HostEmulationManager(929): notifyHostEmulationData
04-15 09:36:54.164: W/System.err(17710): [B#41ed5e20
04-15 09:36:54.164: I/HCEDEMO(17710): Received: ?????DOAN??
04-15 09:36:54.174: D/HostEmulationManager(929): Sending data
04-15 09:36:54.885: D/BrcmNfcJni(929): RoutingManager::stackCallback: event=0x19
04-15 09:36:54.885: D/HostEmulationManager(929): notifyHostEmulationDeactivated
04-15 09:36:54.885: I/HCEDEMO(17710): Deactivated: 0
04-15 09:36:54.885: D/HostEmulationManager(929): Unbinding from service ComponentInfo{de.grundid.hcedemo/de.grundid.hcedemo.MyHostApduService}
04-15 09:36:54.895: E/BrcmNfcNfa(929): UICC[0x0] is not activated
It displays that it can receive some data, but it misses some elements I want to transmit, but, from PN532, when I use read records, it does not display these data?
The commands that your Android HCE emulated smartcard application understands and processes are completely up to you (as long as they are formatted as valid ISO 7816-4 APDUs).
In your case, your Android HCE service obviously processes the SELECT (by DF name) APDU,
00 A4 04 00 07 F0010203040506 00
and gives this as a response:
48 65 6C 6C 6F 20 44 65 73 6B 74 6F 70 21 ("Hello Desktop!" when interpreted as ASCII)
(Note that this response is not a valid response APDU according to ISO 7816-4 as it lacks a status word.)
The next command you send is an invalid SELECT (by EF) command:
00 A4 02 0C 01 01 00
For that command, Lc should be 2 and the EF identifier should consist of two bytes if following ISO 7816-4. In response to that, your Android HCE service again sends
48 65 6C 6C 6F 20 44 65 73 6B 74 6F 70 21 ("Hello Desktop!" when interpreted as ASCII)
(Note that this response is not a valid response APDU according to ISO 7816-4 as it lacks a status word.)
So I would guess, that your Android HCE service performs a check like this:
public byte[] processCommandApdu(byte[] apdu, Bundle extras) {
if (apdu[1] == (byte)0xA4) {
return "Hello Desktop!".getBytes("US-ASCII");
}
}
The next command that you send is a malformed WRITE RECORD command that tries to write "BAOGIA#" in the first record of the cuirrently selected file (malformed, because a WRITE RECORD command normally does not have an Le field):
00 D2 00 00 07 42 41 4F 47 49 41 40 00
As a response your Android HCE service sends:
4D 65 73 73 61 67 65 20 66 72 6F 6D 20 61 6E 64 72 6F 69 64 3A 20 30 ("Message from android: 0" when interpreted as ASCII)
(Note that this response is again not a valid response APDU according to ISO 7816-4 as it lacks a status word.)
You then repeat the WRITE RECORD command with a different record payload and after that you send two malformed READ RECORD commands:
00 D2 00 02 04 44 4F 41 4E 00
00 B2 00 00 07 42 41 4F 47 49
00 B2 00 02 04 44 4F 41 4E 00
As a response your Android HCE service sends:
4D 65 73 73 61 67 65 20 66 72 6F 6D 20 61 6E 64 72 6F 69 64 3A 20 xx ("Message from android: X" when interpreted as ASCII)
Where xx seems to be an ASCII digit X that is incremented for each received command.
So I would guess, that your Android HCE service looks like this:
private int mCommandCounter = 0;
public byte[] processCommandApdu(byte[] apdu, Bundle extras) {
String response;
if (apdu[1] == (byte)0xA4) {
response = "Hello Desktop!";
} else {
response = "Message from android: " + Integer.toString(mCommandCounter);
++mCommandCounter;
}
return response.getBytes("US-ASCII");
}
So, to summarize this, your Android HCE service will understand and process only those commands that you (or whoever develops it) implement. So it is up to you what commands you can send to the HCE device. There is no file system behind it. ISO 7816-4 only suggests a file system layout for smartcard applications.