Reading about Silent Circle, and more specifically Silent Text, I learnt that by implementing SAS, the likelyhood of a MITM attack is greatly reduced. Could someone please explain how this works? If there really is someone intercepting your text-based communications, what is to stop them simply modifying the SAS exchange?


  • I'm unclear on how the use of the SAS raises the bar when the voice data can be captured before it is even encrypted. The baseband chip has low level access to all of the hardware on the mobile phone so your voice data can be captured and routed to a cell phone tower: theiphonewiki.com/wiki/Baseband_Device There is a lot more information about this on SlashDot and here: ptsecurity.com/upload/iblock/083/… – user76176 May 9 '15 at 18:23

This question is best answered by reading the Protocol overview published by Silent Circle which describes how it works in much more detail.

In short, the SAS value is derived on each phone by hashing values obtained during the key exchange phase of the protocol. Silent Circle recommends that the SAS value be compared out of band, which makes it very difficult for someone to MITM the conversation.

Silent Circle recommends that users make use of an alternative method to establish the identity of the receiving party and verify that the user has the same SAS value. A phone call would be sufficient for this purpose since confidence building cues such as voice timbre and manner of speech are present. These cues make it difficult for an adversary to convincingly impersonate the other party without being detected. If the two parties are physically co-located, they may even be able to compare their short authentication strings by placing their devices side-by-side.

  • But the screenshots on the Silent Circle FAQ seem to show the users exchanging the SAS through text, which I believe would be classified as in-band. Doesn't that defeat the purpose, or am I still missing something? – Mike Chamberlain Jan 19 '14 at 8:57

My guess is that it's possible that the mechanism uses a token containing a tamper evident hash or seal of some description. This is not foolproof but it raises the bar in that the attacker needs to discover the token's protocol, extract the unique token I'd, change it, and then regenerate the hash.

If the client is not a browser then other techniques can be used to make reverse engineering the token and it's tamper-evident seal.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.