Researchers at Applidium have published some interesting findings about the protocol used by Siri. For every request the user makes to Siri, the iPhone 4S sends the compressed audio of the request to servers at Apple to first be converted to text. Then, it is mapped into commands that the iPhone can understand, and then sent back to the device.

This protocol sits on top of HTTPS, and intercepting or spoofing it requires either a valid SSL certificate for guzzoni.apple.com or a way to convince the device to accept your certificate as valid. One must also hijack DNS so that the phone would think guzzoni.apple.com is at an IP address that you control. The post from Applidium covers the details pretty well, so let’s talk about what one could do with this.

I’ll start with the positive and creative things that can be done. In theory, it should be easy to port Siri to any device if you have a valid iPhone 4S ID. Any device capable of recording audio and running an “app” with Internet connectivity should work. This includes laptops, tablets, smartphones, even refrigerators and washing machines.

You can even build your own Siri server for existing Siri capable devices to talk to. This can be utilized for home use for commands like “turn on the light”, or “close the garage door.” This can also be done within a business: imagine integrating such a system with your everyday tools to make workflow voice interactive. Anything you can script, you can ask Siri about.

Unfortunately, there also some not-so-friendly possibilities. For these scenarios, we’ll assume that the attacker has successfully loaded a self-signed certificate into the device and somehow has control of the local DNS, as both are required to successfully intercept Siri communications.

The most obvious attack is to play man-in-the-middle and capture all Siri requests and responses. This alone may be useful, but the questions you ask Siri might betray what you are working on. Soon, we can easily start changing answers like altering stock quotes, or replacing a request to call a colleague from your contact list. This can be replaced with a request to call a different number that will forward the call to the original person you intended to call, and record the conversation. This would certainly require inside knowledge of the victim’s address book, but appears possible to a determined attacker.

There are a number of ways Apple can fix this. The most comprehensive way would be to move to a challenge-response authentication system. Requiring that the server SSL key matches a given key ID, or more practically is signed by a key with a set ID would add broad coverage. Either way, only Apple has the capability to fix this if it is truly broken.