(complete list of showcases: https://vnhacker.blogspot.com/search/label/The%20Internet%20of%20Broken%20Protocols)
Administrative note: showcase #1 is not easy, and so far I got only two emails. The following protocol is a bit easier. In case you wonder whether I made up these protocols, the answer is no. I actually found them on the Internet of Things :).
Updated: solution posted ;-)
Alice buys a new smart TV and wants to connect it to, of course, the Internet. She downloads an app from the TV's manufacturer. The app allows her to securely send her WiFi password to the TV.
The app and the TV run the following protocol. Your task is to analyze this protocol and find all weaknesses. You might email me at firstname.lastname@example.org if you want some privacy. I'll update this post with my solution in 48 hours.
1/ The TV in setup mode acts as an open WiFi hotpot. The SSID is a random string that starts with "SmartTV".
2/ The app automatically finds and connects to the first open WiFi network whose SSID starts with "SmartTV".
3/ The app sends the string "Hello".
4/ The TV sends its certificate. All TV certificates are signed by a CA trusted by the app. Each TV has a unique key pair that is provisioned at manufacturing time. The private key is stored in the TV's flash storage.
5/ The app verifies that the certificate is signed by the trusted CA. It extracts the RSA public key PK and sends E(PK, password) || SSID, where E is PKCSv1.5 RSA encryption.
6/ The TV uses the private key to decrypt the password. It shutdowns its open WiFi hotpot and uses the password and SSID to connect to the local WiFi network and the Internet.
Aside from two comments below I also got emails from Andrew L., Alex B., Carl M., Văn D., and Thắng N. Most identified the common issues, but surprisingly none actually found all issues!
Alex B. found two problems:
"1. An attacker with access to one of these TVs (their own) can extract the private key. Presumably when the app initially connects to one of these smart TVs, it chooses the SSID that is lexicographically first (so an attacker's fake WiFi with SSID "SmartTVAAAA..." will be chosen by the app. With the valid cert and private key in hand, the attacker can trivially recover the password (all while performing the protocol with the actual TV)."
This demonstrates a fundamental difference between the Internet of Things and the WWW. On WWW we authenticate servers using public key infrastructure, but this method doesn't work on the Internet of Things because devices don't have easy to remember identifiers like domain names. David Wong also raised a good point about cert pinning in his comment below.
"2. The SSID sent in #5 is not cryptographically bound. So an attacker can replace that SSID with one they control and when the TV attempts to authenticate with them, they will presumably be able to see what the password is."
The attacker can set up a rogue router that pretends to speak the WEP protocol, when the TV attempts to authenticate they can mount one of the known attacks against WEP to obtain the password.
Andrew L. found a unique issue missed by most readers:
Problem 2: There's no forward secrecy. Even if you reset your TV, anyone who gets it later gets the private key can decrypt past exchanges.
Thắng N. and David Wong raised the possibility of mounting a Bleichenbacher attack against the RSA encryption. Thắng N. also found a unique attack that wasn't spotted by other readers:
"Another attack is in step 5, attacker replaces pair (password, SSID) by her own wifi parameters
(password_att, SSID_att). The app decrypts it, then connect to attacker's wifi."
This problem demonstrates the fact that, contrary to popular belief, public key encryption doesn't actually provide authentication because anyone can take the public key and do the encryption themselves.