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

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.

• What's the threat model? Do you have any concern at all about active attackers? – cpast May 12 '15 at 3:54
• Just pick one g, p. Having 1000 different primes doesn't improve the security. – Steve Peltz May 12 '15 at 5:13
• @cpast With WiFi? Oh my, I hope so. – Maarten Bodewes May 12 '15 at 21:21

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.

• That last sentence is not really strong. You should probably turn it in a comment. I don't (deeply) understand a lot of crypto but doesn't make any schemes less secure. – Maarten Bodewes May 12 '15 at 22:00
• Is it a good idea to do the following? (1) Use PBKDF to derive 2 keys (data key and mac key), (2) Encrypt plaintext with data key and calculate MAC on the ciphertext with mac key, then (3) Send ciphertext, MAC and IV – Léster May 21 '15 at 0:08

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).

• Would you suggest out-of-band methods against MITM? For example, once the client sends $g$, $p$ and $B$, the host shows a random code $r$ on its screen that the user has to input on the client, and to validate the agreement, the client sends $SHA256(s||r)$. – Léster May 20 '15 at 23:05
• Yes, initially you need some form of out-of-band sharing of something. The problem with your suggestion is that if $r$ is too small, a MITM attacker could brute-force it fast enough to spoof the server. Better would be to have both the client and server display a hash of the DH shared secret and the user verifies that they match. Once you have a secure authenticated connection, they can easily exchange proper credentials (either a shared secret, or an SRP-style verifier, or an RSA public key or whatever). – Steve Peltz May 21 '15 at 4:19