Establish a secure connection between a Bluetooth Low Energy device and an Android App using ECDH

Question

Im very new to security and trying to learn how to establish a secure connection between a android application and a Bluetooth Low Energy device with limited hardware performance.

The procedure:

App:

1. Generate private/public keys with ECDH Key Pair Generator and elliptic curve spec "sect163k1" using java.security.* (https://gist.github.com/ymnk/fec39e033394ee2ec47c)
2. Send public key to BLE Device
3. Generate secret master key from apps private key and the public key from the BLE Device using ECDH (https://docs.oracle.com/javase/7/docs/api/javax/crypto/KeyAgreement.html#generateSecret())
4. Store secret master key in database. (never shared)
5. Encrypt data with secret key using AES/CBC with integrity (using https://github.com/tozny/java-aes-crypto)
6. Send data to BLE Device to be decrypted with the device secret master key

BLE Device:

1. Generate private/public keys with ECDH Key Pair Generator and elliptic curve spec "sect163k1" (or another curve)
2. Send public key to App
3. Generate secret master key from apps public key and BLE Device private key using ECDH
4. Store secret master key in device (never shared)
5. Encrypt data with something like EAS/CBC with integrity
6. Send data over to app to be decrypted with apps secret master key

Would this keep the communication between both parts safe? Second time the connection is established the same shared secret could be used to encrypt the data, in order to improve performance. Its a 1:1 relationship between the device and the logged in account in the app so I could also use the shared secret to verify the right user is connecting to the BLE device.

Answer 1

With this protocol, I see three issues right now.

1. In step 2 both devices just send their public keys. Now an attacker could go ahead, intercept the keys from either part, pretend to be the other one and relay all the trafic over himself. This is a classic man-in-the-middle attack against Diffie-Hellman.
2. You use "AES-CBC with integrity". This does look very bad for a mode of operation. It seems to be (from a quick glance) $E_K(m)=E_K^{CBC}(m\parallel H(m))$ at best which is also called hash-then-encrypt, which is highly nonstandard and potentially dangerous. Upon further inspection of the source code (thanks to Isaac Potoczny-Jones in the comments) it turns out to actually be an HMAC-SHA256 applied on the ciphertext which is standard encrypt-then-authenticate.
3. You use sect163k1 which is a Binary Koblitz curve over a field of size $\approx 2^{160}$, thus a brute-force attack would take $\approx 2^{80}$ operations which is considered dangerously weak these days. If you have to (perfomance-wise) you can do it, but it's certainly not the robust 128-bit security level you normally expect.

As for mitigations, I strongly recommend you to use a more standard secure channel protocol (like TLS). If your platform does not natively support it, it may be time to either require an upgrade or bring your own library.