DH with AES - is that an acceptable security scheme over UPnP?

Question

I'm trying to devise a good security scheme to protect comms over Wi-Fi.

Right now, I have 2 devices that already communicate via UPnP but I need to secure this communication. I've come up with this:

• Once the client sees the other host, picks a pair of Diffie-Hellman parameters (out of 1000 pregenerated pairs of $g$ and $p$) and enacts a DH key agreement with the host. This happens each time both devices want to initiate a session, and auth persistence is not needed (generated keys are discarded after the session finishes).
• Once both devices have calculated the same secret, this secret is hashed with SHA-256 to create a common key.
• When the client wants to send a message to the host, it encrypts it with AES-CBC-PKCS#7, using the key, it appends the generated IV and sends it to the host. The host's response follows the same method.

Whoever observes a session can only see $g$, $p$, $A$, $B$, the ciphertexts and their corresponding $IV$s.

Is this secure enough?

P.D.: I'm under the impression that trying to use TLS is way too much for such a simple need and it would be too complicated to get out in a reasonable timeframe.

Answer 1

No. First, you've exposed a padding oracle by using unauthenticated AES. Secondly, you've not authenticated the devices: it's easy to mount a man in the middle attack. Thirdly, I don't understand the role of changing parameters all the time in your protocol.

Answer 2

You really want to authenticate, what use is confidentiality if some random intruder can pretend to be either host or client, or can insert themselves in the middle of the conversation? No need to break the encryption, you'd just give away the keys. If you need to protect the data from being seen, you also need to protect from more active attacks.

There are several ways to authenticate using DH-like algorithms. Secure Remote Password is a DH variant which uses a private key (usually password-derived, but the basic algorithm doesn't care where the key comes from); the verifier is stored on the host and kept secret. You could set up all authorized devices to have the same key, and the host knowing the verifier authenticates the host. You can implement SRP using the same multi-precision integer library you're using for DH.

You could also use the Station-to-Station protocol, (see Authentication and Authenticated Key Exchanges), or the KEA+ protocol. STS needs some form of signature algorithm (RSA, DSA), KEA+ does not (it uses private/public key pairs, but uses them the same way a DH key exchange works).

Note that there's an earlier protocol from the NSA called KEA, referenced in several RFCS (2528, 2773, 2951), but the paper I linked to describes some of the problems with it.

Using multiple generator/prime pairs is unnecessary. The security is in the secret keys, there are no practical attacks against a 2048-bit modulus, certainly none that would be worth doing to attack you individually.

Using 128-bit AES in CBC mode should be fine, it's the key exchange and authentication that's going to be your weak point. As Maarten Bodewes points out, you also need to be concerned with message integrity (i.e. you need to use a MAC on at least the IV and ciphertext, to prevent a Padding Oracle Attack, look up Encrypt-then-MAC for more discussion of why).