Isn't that solved by RSA? Printer broadcasts its public key saying "hey, printer here, send me the wifi password please". Your phone uses the printer's public key to encrypt the wifi password and send it out. The attacker cannot snoop on the key, because it doesn't have the printer's private key necessary to decrypt the message.

An attacker could still man in the middle the initial key handshake.

Printer: "Printer here, my pubkey is A"

Attacker (races phone): "Alright bro, I got it"

Attacker: "Printer here, my pubkey is B"

Phone: "Alright bro, I got it"

Phone: "Here is the WiFi password, encrypted with B"

Attacker: "Thanks!"

This example is pretty simplistic, but the idea still works even if there is some form of authentication (e.g., challenge-response).

The way around this is to pre-share some sort of info to verify the authenticity of any new incoming key.

For example, the user downloads a printer app on their phone that contains a master pubkey. On the other side, the printer would have a device pubkey signed with the master private key. When the phone receives a new printer message, it first veriffies the key signature to ensure that it actually came from a legitimate printer.

If you can't get some sort of key onto the phone, your best bet is to perform key exchange out of band. One common technique for phones is NFC: it requires proximity, making the attack above difficult to execute.

> For example, the user downloads a printer app on their phone that contains a master pubkey. On the other side, the printer would have a device pubkey signed with the master private key. When the phone receives a new printer message, it first veriffies the key signature to ensure that it actually came from a legitimate printer.

To further increase security, the certificate (signed pubkey) presented should also contain some unique per-device identifier (serial number or some PIN code or something). Otherwise attacker could possibly extract keys from a similar device to conduct the attack.