Tipps for Android app server communication?

A place to discuss the implementation and style of computer programs.

Moderators: phlip, Moderators General, Prelates

User avatar
PeteP
What the peck?
Posts: 1451
Joined: Tue Aug 23, 2011 4:51 pm UTC

Tipps for Android app server communication?

Postby PeteP » Sun May 31, 2015 11:13 am UTC

So I am writing a small app for the first time and now it needs a server and communicate with it. And of course I want to encrypt the communication with the server. Is there some best practice for this? Does it make sense to hard code a public key for the server into the app? (Say in the form of an ssl certificate and then using ssl to communicate.)

KnightExemplar
Posts: 5494
Joined: Sun Dec 26, 2010 1:58 pm UTC

Re: Tipps for Android app server communication?

Postby KnightExemplar » Sun May 31, 2015 4:47 pm UTC

PeteP wrote:So I am writing a small app for the first time and now it needs a server and communicate with it. And of course I want to encrypt the communication with the server. Is there some best practice for this? Does it make sense to hard code a public key for the server into the app? (Say in the form of an ssl certificate and then using ssl to communicate.)


Sort of. Those keys are going to expire eventually, right? (or maybe you may have a security breach and you need to update everyone's certificates).

I'd argue "best practice" would be to hardcode the public key Certificate Authority you plan to use, and to generate a Certificate Authority on an offline computer (and never connect said computer to the internet). Or you can buy certificates from a trusted company if you are willing to pay a subscription fee so that you don't have to maintain your own certificate authority. The client should implement a scheme for revoking certificates as well.
First Strike +1/+1 and Indestructible.

User avatar
Thesh
Made to Fuck Dinosaurs
Posts: 6271
Joined: Tue Jan 12, 2010 1:55 am UTC
Location: Colorado

Re: Tipps for Android app server communication?

Postby Thesh » Sun May 31, 2015 4:51 pm UTC

TLS is the normal method you would use to provide secure communication. If you want to use a self-signed certificate, it should be provided with your application or else there is no way to do validation. If you plan on or ever think you might have multiple servers with different domains, you should consider going with a more traditional model where you provide a root certificate and have that certificate sign your server certificate.

Depending on how important encryption is, you should be aware that TLS has a lot of problems. You should look into severely restricting available cipher suites and TLS version. For example, only allow TLS v1.2 with TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as the cipher suite. This should be done with both the client and the server to make sure that no one can downgrade security (see the recent logjam attack). Since you control the client and the server, there is no reason not to secure it like that. AES in GCM mode is immune to most attacks on the TLS protocol itself since it doesn't require padding, and other attacks involved downgrading the connection which is prevented by only allowing one TLS version and cipher suite. Also, be aware that some attacks have exploited compression in TLS in the past; although without the attacker having some control over what is sent, it may not be an issue (although it still may be an issue); unless you absolutely need it, I would not send compressed data.

EDIT:

KnightExemplar wrote:Or you can buy certificates from a trusted company if you are willing to pay a subscription fee so that you don't have to maintain your own certificate authority.


I would highly recommend against that. For general browsing, that works fine, but if you have control over both the client and the server, all using a third party CA does is provide additional points of attack. Certificate Authorities don't even do a very good job for the regular internet; the main problem is that they are not authorities on what they are issuing certificates for. Create your own CA. Also, you make some good points about reissuing certificates; if you create your own CA rather than using a self-signed certificate, then if there is a breach you can reissue and revoke certificates.
Last edited by Thesh on Sun May 31, 2015 5:18 pm UTC, edited 1 time in total.
Summum ius, summa iniuria.

DaveInsurgent
Posts: 207
Joined: Thu May 19, 2011 4:28 pm UTC
Location: Waterloo, Ontario

Re: Tipps for Android app server communication?

Postby DaveInsurgent » Sun May 31, 2015 5:16 pm UTC

Just use HTTPS / HSTS - the problem you're solving has been handled via application layer protocols. (The user logs in to your service to obtain a token, but that is all done via HTTP within a secure connection).

KnightExemplar
Posts: 5494
Joined: Sun Dec 26, 2010 1:58 pm UTC

Re: Tipps for Android app server communication?

Postby KnightExemplar » Sun May 31, 2015 5:29 pm UTC

DaveInsurgent wrote:Just use HTTPS / HSTS - the problem you're solving has been handled via application layer protocols. (The user logs in to your service to obtain a token, but that is all done via HTTP within a secure connection).


The direction of this conversation should be moving closer to where Thesh went. HTTPS is nothing more than a layer of HTTP on top of TLS. Saying "use HTTPS" doesn't really tell him how to use HTTPS correctly. On the other hand, discussing the details of TLS will explain those details.

If you make a TLS mistake when implementing HTTPS, then you get owned.

Thesh wrote:
KnightExemplar wrote:Or you can buy certificates from a trusted company if you are willing to pay a subscription fee so that you don't have to maintain your own certificate authority.


I would highly recommend against that. For general browsing, that works fine, but if you have control over both the client and the server, all using a third party CA does is provide additional points of attack. Certificate Authorities don't even do a very good job for the regular internet; the main problem is that they are not authorities on what they are issuing certificates for. Create your own CA. Also, you make some good points about reissuing certificates; if you create your own CA rather than using a self-signed certificate, then if there is a breach you can reissue and revoke certificates.


It's more about the convenience factor though of not setting up your own CA. If you want absolute security, you'll have to make your own CA and then perfectly secure it yourself. If you're willing to offload the security concern to someone else, pay a yearly fee to have _them_ handle the reissuing / revoking issues and all that good stuff.

"Secure" is more of a sliding scale than a binary option. There's "more secure" and "less secure". And using 3rd party CAs is "secure enough" for online banking (well... not the cheap Comodo Certs... but say a $1000/year Green Verisign Cert). IMO, the cost / benefit of running your own CA makes it pretty obvious. Even the "cheap" certs are upwards from $100/year, although that seems to be changing recently. Cheap certs are finally getting to the "free" point (I saw some programs by Mozilla / Cisco that may launch within this year actually...)

In any case, "best practice" does include a CA, as opposed to just handing out the public keys in the raw. Those public keys need to be updated every couple of years.

--------

With that said, using TLS 1.2 and a truly secure encryption algorithm (RC4 IIRC is most common, and most broken as well. You'd want to use AES for TLS 1.2, as well as whatever the latest SHA512 or whatever the latest Hashing algorithm is...). And 5 or 10 years from now, when AES and SHA512 are broken, you should update your certificates to the newer encryption algorithms that come around (or if TLS 1.2 ends up having a security hole in it, upgrade to the newest version of that).
First Strike +1/+1 and Indestructible.

User avatar
hotaru
Posts: 1042
Joined: Fri Apr 13, 2007 6:54 pm UTC

Re: Tipps for Android app server communication?

Postby hotaru » Sun May 31, 2015 9:16 pm UTC

Thesh wrote:You should look into severely restricting available cipher suites and TLS version. For example, only allow TLS v1.2 with TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as the cipher suite. This should be done with both the client and the server to make sure that no one can downgrade security (see the recent logjam attack). Since you control the client and the server, there is no reason not to secure it like that. AES in GCM mode is immune to most attacks on the TLS protocol itself since it doesn't require padding, and other attacks involved downgrading the connection which is prevented by only allowing one TLS version and cipher suite. Also, be aware that some attacks have exploited compression in TLS in the past; although without the attacker having some control over what is sent, it may not be an issue (although it still may be an issue); unless you absolutely need it, I would not send compressed data.

this is mostly good advice, but it should really be TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 instead. the only reason to go higher than 128-bit key length is to protect against an attacker with a quantum computer, but such an attacker could just break the key exchange with much less effort than breaking AES 128. I'd also recommend using the secp256k1 curve (because it's faster and some people don't trust the NIST curves) for ECDH and ECDSA.

Code: Select all

factorial product enumFromTo 1
isPrime n 
factorial (1) `mod== 1

User avatar
Thesh
Made to Fuck Dinosaurs
Posts: 6271
Joined: Tue Jan 12, 2010 1:55 am UTC
Location: Colorado

Re: Tipps for Android app server communication?

Postby Thesh » Sun May 31, 2015 9:53 pm UTC

hotaru wrote:this is mostly good advice, but it should really be TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 instead. the only reason to go higher than 128-bit key length is to protect against an attacker with a quantum computer, but such an attacker could just break the key exchange with much less effort than breaking AES 128. I'd also recommend using the secp256k1 curve (because it's faster and some people don't trust the NIST curves) for ECDH and ECDSA.


I'd disagree, there is no security advantage to using AES-128 over AES-256, nor SHA-256 over SHA-384. For AES, the performance difference is minor, but comes with more rounds so to better protect against future attacks, and on 64-bit systems SHA-384 is faster and more secure than SHA-256. Both RSA and ECDSA are fine for signing, I would still stick with RSA for now; 2048-bit RSA is going faster for signature verification than 256-bit ECC (and your server is more power powerful than an android phone, which is only going to be verifying signatures). Also, RSA has been more thoroughly scrutinized for security. If ECC is used*, it's a good idea to choose something larger than 256-bit just to be safe, but larger curves than that see poor support outside of the NSA-supplied curves containing magic numbers that have been chosen with no explanation as to why they were chosen.


*I realize I'm specifying ECC for key exchange, rather than Diffie-Hellman, but as they are ephemeral, if there is an attack then each session key would need to be broken separately rather than just breaking a single public key, so it's al lot less likely to be a serious problem
Summum ius, summa iniuria.

User avatar
hotaru
Posts: 1042
Joined: Fri Apr 13, 2007 6:54 pm UTC

Re: Tipps for Android app server communication?

Postby hotaru » Sun May 31, 2015 10:21 pm UTC

Thesh wrote:I'd disagree, there is no security advantage to using AES-128 over AES-256, nor SHA-256 over SHA-384. For AES, the performance difference is minor, but comes with more rounds so to better protect against future attacks, and on 64-bit systems SHA-384 is faster and more secure than SHA-256. Both RSA and ECDSA are fine for signing, I would still stick with RSA for now; 2048-bit RSA is going faster for signature verification than 256-bit ECC (and your server is more power powerful than an android phone, which is only going to be verifying signatures). Also, RSA has been more thoroughly scrutinized for security. If ECC is used*, it's a good idea to choose something larger than 256-bit just to be safe, but larger curves than that see poor support outside of the NSA-supplied curves containing magic numbers that have been chosen with no explanation as to why they were chosen.

most android devices use 32-bit processors, where SHA-256 is significantly faster than SHA-384. they also don't have hardware support for AES, so AES 256 is a lot slower than AES 128. 2048-bit RSA is weaker than 256-bit ECDSA. you'd have to use 3072-bit RSA to get the same security level. at that size, ECDSA is faster for both signing and verification. to get the security level the AES_256_GCM_SHA384 suits are aiming for, you'd have to use 384-bit EC (and 7168-bit RSA). for 384-bit EC in TLS, there are only two curves: one from NIST and one from brainpool. both could have been manipulated to produce some weakness (unlike secp256k1), and are a lot more likely to have timing side channels than secp256k1 in common implementations. and 7168-bit RSA on a mobile device? no. just no.

Code: Select all

factorial product enumFromTo 1
isPrime n 
factorial (1) `mod== 1

User avatar
Thesh
Made to Fuck Dinosaurs
Posts: 6271
Joined: Tue Jan 12, 2010 1:55 am UTC
Location: Colorado

Re: Tipps for Android app server communication?

Postby Thesh » Sun May 31, 2015 10:42 pm UTC

hotaru wrote:so AES 256 is a lot slower than AES 128.


A lot slower? No, 14 vs 10 rounds; it's linear, and the extra security margin is worth the cost.

hotaru wrote:2048-bit RSA is weaker than 256-bit ECDSA


Weaker against known attacks, not necessarily weaker. We have less certainty on the security of ECC than we do about RSA.

hotaru wrote:you'd have to use 3072-bit RSA to get the same security level. at that size, ECDSA is faster for both signing and verification.


Err... No?

http://citeseerx.ist.psu.edu/viewdoc/do ... 1&type=pdf
Signature verification is where RSA pulls ahead of ECC in performance. The time to verify a message signed in RSA is negligible for the key lengths used, and does not even show a difference until you go from 7680 to 15360 bits. ECC lags behind in performance in every key length, showing nearly linear growth for increasing key sizes.


hotaru wrote:to get the security level the AES_256_GCM_SHA384 suits are aiming for


That's a non-argument; unless you are worried specifically about brute-force attacks, security level is meaningless. No one can break any of those algorithms, so you are going based on two things: performance and security against unknown attacks. Security against unknown attacks is where AES-256/SHA-384 win hands down, and should be your main security concern when picking an algorithm, not just key length as it pertains to brute force.
Summum ius, summa iniuria.

User avatar
hotaru
Posts: 1042
Joined: Fri Apr 13, 2007 6:54 pm UTC

Re: Tipps for Android app server communication?

Postby hotaru » Sun May 31, 2015 11:57 pm UTC

on a 32-bit system:

Code: Select all

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
sha384             600.59k     2398.31k     4809.95k     7637.73k     9310.36k
sha256            3955.27k     9181.52k    16110.99k    19816.35k    21257.83k


NIST P-256 verification is faster than 4096-bit (nowhere close to 7680-bit) RSA verification:

Code: Select all

                  sign    verify    sign/s verify/s
rsa 4096 bits 0.009286s 0.000147s    107.7   6824.6
                              sign    verify    sign/s verify/s
 256 bit ecdsa (nistp256)   0.0001s   0.0001s  18471.9   7105.7

and secp256k1 is faster than NIST P-256.

re: unknown attacks, any new attack that breaks AES 128 will probably also break AES 256. it's also likely that any new attack against AES will be more effective against AES 256 because of its terrible key schedule. if you really want to defend against unknown attacks against AES, encrypt everything with a different algorithm (such as chacha20) before transferring it over TLS.

Code: Select all

factorial product enumFromTo 1
isPrime n 
factorial (1) `mod== 1

DaveInsurgent
Posts: 207
Joined: Thu May 19, 2011 4:28 pm UTC
Location: Waterloo, Ontario

Re: Tipps for Android app server communication?

Postby DaveInsurgent » Mon Jun 01, 2015 12:26 am UTC

It's not hard to appreciate the wealth and depth of knowledge being presented here, but the OP asks how to make "a simple" Android app communicate with a server. Maybe I misread the OP, but I figured it was "I want to talk to a server, and it probably should be encrypted" not, "I need to transmit data and it's paramount that it be as secure as possible" -- get a certificate signed by an authority that is already trusted on the Android platform, look up how to implement HTTPS in whatever provider you're using (i.e. AWS/EB) and start POSTing data:

https://developer.android.com/training/ ... y-ssl.html

The "secure" part of it is totally important, but it's also important, IMHO, not to drown someone trying to learn in details. Once you have a secure channel (and I'd argue that a lot of what is being debated here is sufficiently advanced enough that it can be left as an exercise after getting the client-server interaction understood, then soak in to the nuances being debated, especially since it's an orthogonal concern) you need to actually send and receive data and HTTP(S) is probably what you want.

I feel like this is a little bit classic, "Hey I was wondering about" >> /slams tome down on desk YOU KNOW NOTHING JON SNOW 256 vs 384 GO

User avatar
Thesh
Made to Fuck Dinosaurs
Posts: 6271
Joined: Tue Jan 12, 2010 1:55 am UTC
Location: Colorado

Re: Tipps for Android app server communication?

Postby Thesh » Mon Jun 01, 2015 12:35 am UTC

hotaru wrote:re: unknown attacks, any new attack that breaks AES 128 will probably also break AES 256. it's also likely that any new attack against AES will be more effective against AES 256 because of its terrible key schedule. if you really want to defend against unknown attacks against AES, encrypt everything with a different algorithm (such as chacha20) before transferring it over TLS.


There are no known attacks other than related key attacks that are more effective against AES-256 than AES-128, and the related key attacks are completely impractical against TLS.
Summum ius, summa iniuria.

User avatar
phlip
Restorer of Worlds
Posts: 7556
Joined: Sat Sep 23, 2006 3:56 am UTC
Location: Australia
Contact:

Re: Tipps for Android app server communication?

Postby phlip » Mon Jun 01, 2015 7:06 am UTC

DaveInsurgent wrote:I feel like this is a little bit classic, "Hey I was wondering about" >> /slams tome down on desk YOU KNOW NOTHING JON SNOW 256 vs 384 GO

Exactly this. This is not a thread for "look how much better I can crypto than you". This is a thread for helping someone get a handle on encryption 101. Arguments about key sizes and algorithm trivia can go to RW.

Code: Select all

enum ಠ_ಠ {°□°╰=1, °Д°╰, ಠ益ಠ╰};
void ┻━┻︵​╰(ಠ_ಠ ⚠) {exit((int)⚠);}
[he/him/his]

User avatar
WanderingLinguist
Posts: 237
Joined: Tue May 22, 2012 5:14 pm UTC
Location: Seoul
Contact:

Re: Tipps for Android app server communication?

Postby WanderingLinguist » Mon Jun 01, 2015 7:26 am UTC

KnightExemplar wrote:
DaveInsurgent wrote:Just use HTTPS / HSTS - the problem you're solving has been handled via application layer protocols. (The user logs in to your service to obtain a token, but that is all done via HTTP within a secure connection).


The direction of this conversation should be moving closer to where Thesh went. HTTPS is nothing more than a layer of HTTP on top of TLS. Saying "use HTTPS" doesn't really tell him how to use HTTPS correctly. On the other hand, discussing the details of TLS will explain those details.

If you make a TLS mistake when implementing HTTPS, then you get owned.


Since the op is talking about Android, most of this is a moot point. Using the built-in HTTPS support on Android is likely to be the best option here. In almost all common cases, it does the right thing already. If any exploits come up, you have the weight of Google behind it to patch the implementation in the OS, or update the CA blacklist OTA, etc. Implementing encryption yourself is risky at best even if you're an expert. Yes, you could theoretically get better security by doing it yourself, if you really know what you're doing and don't make any mistakes, but in practice that's not going to happen. The built-in implementation in Android is easy to use and good enough for most use cases.

(edit: Ninja'd twice)

User avatar
Thesh
Made to Fuck Dinosaurs
Posts: 6271
Joined: Tue Jan 12, 2010 1:55 am UTC
Location: Colorado

Re: Tipps for Android app server communication?

Postby Thesh » Mon Jun 01, 2015 9:37 am UTC

When you use any library, TLS version, cipher suites, and CA certificates will be things that you can provide. Restricting cipher suites, CA certificates, and protocol version is not "rolling your own" but best practices to minimize the attack surface. If you just allow any certificate authority... Well, at a previous employer I could get trusted certificate for most minor websites, even if we had no authority over it (the CA model is horribly broken).
Summum ius, summa iniuria.

User avatar
PeteP
What the peck?
Posts: 1451
Joined: Tue Aug 23, 2011 4:51 pm UTC

Re: Tipps for Android app server communication?

Postby PeteP » Mon Jun 01, 2015 12:44 pm UTC

Thanks all. I will sign a certificate for my server with my own certificate authority and set TLS and cipher suite on both sites. (The discussion about which ones to use was interesting, but while I understand enough about the concepts to follow it I'm entirely unqualified to judge the arguments. So I will just go with the suggestion of Thesh mostly because I know him better… (Not the best way to decide perhaps but I doubt my app will become super popular and thus be an attack target which needs the best security and performance possible.) )


Return to “Coding”

Who is online

Users browsing this forum: No registered users and 9 guests