Questionable crypto in Annalee Newitz's ‘Autonomous’
Autonomous is a 2017 novel from former io9 editor Annalee Newitz. One of the viewpoint characters is a bot, Paladin, and during his first few pages, we are treated to the following exchange between him and another bot, Fang:
The mantis [Fang] beamed Paladin a hail. Hello. Let’s establish a secure session using the AF protocol.
Hello. I can use AF version 7.6, Paladin replied.
Let’s do it. I’m Fang. We’ll call this session 4788923. Here are my identification credentials. Here comes my data. Join us at 2000.
Fang’s request came with a public key for authentication and a compressed file that bloomed into a 3-D map of the facility.
I’m Paladin. Here are my identification credentials. Here comes my data. See you there.
A fun bit of world-building in the story of an interesting character, perhaps, but there are some pecularities in this exchange that bear some further investigation.
Let's draw a sequence diagram for this exchange:
For convenience, let us refer to Fang as the client (the initiator of the exchange) and Paladin as the server.
Immediately, some pecularities stand out. The protocol negotiation at the beginning is shown to occur before the exchange of public keys, and so appears it must be exchanged in cleartext. To a potential man (bot?)-in-the-middle, say Jack, this presents an interesting attack surface.
Notably, the client does not appear to request a particular version of the AF protocol, and instead trusts the response from the server. We can imagine that a man-in-the-middle could easily perform a downgrade attack, and trick the client into using an older (possibly insecure) version of the AF protocol.
Indeed, downgrade attacks of this sort have been a real problem in SSL/TLS, including FREAK, Logjam and POODLE.
Of course, in this particular situation, the server may well be able to detect that something is wrong once the data is sent, but by that time the attacker has already been able to intercept the data (which has been subject to a downgrade attack).
Taking this even further, we could imagine an even more insidious attack – suppose that the attacker drops even the initial request to start a secure AF session, and instead claims that the server does not support AF. Conceivably, the client may downgrade to a less secure, perhaps even plaintext, protocol.
Now the attacker is able to capture the entire exchange with ease, and neither party is any the wiser!
Again, there is real-world precedent for such attacks – for example, the SSLstrip and STRIPTLS attacks.
In the case of SSLstrip, this attack could be mitigated through HTTPS-Everywhere or HTTP Strict Transport Security (HSTS), and returning to the Autonomous example, with internal communications between two military-esque bots, it is conceivable that plaintext communications could be blacklisted.
In general, however, we see elsewhere in the novel that plenty of plaintext communications take place between strangers, without any apparent exchange of public key information, and it is difficult to imagine how this attack could mitigated in such circumstances without significant practical changes.
These are all well-known real-world exploits, though. What specific attacks might exist against this AF protocol?
Returning to the first diagram, something very peculiar becomes apparent: The first piece of data, ‘Join us at 2000’, appears to be sent before the exchange of credentials is complete! And because the server has not sent its public key, that data must have been sent without encryption.
This means that the attacker doesn't even need to bother with any tricky manipulation – the first piece of data (and in this case, the most crucial piece of data!) is sent in the clear without even verifying the server's identity!
Even worse, if the data is not signed, the plaintext data could be modified by the attacker without detection.
Could this be used to set up an ambush on our poor bot friend Paladin? One can only imagine the possible consequences of such a flaw.
Now at this point, it perhaps bears acknowledging that we are assuming that no additional behind-the-scenes magic happens during that initial protocol negotiation phase. Perhaps ‘establish a secure session using the AF protocol’ includes an (anonymous) Diffie–Hellman key exchange, and so the exchange at this point would be encrypted.
(This is not the case in TLS, which does not begin Diffie–Hellman until after certificates are exchanged.)
Even in this case, though, this doesn't fix the vulnerability. Since the server's identity remains unverified, the attacker can easily man-in-the-middle the Diffie–Hellman key exchange and proceed to intercept the first piece of data as above.
So how can we improve the system? Setting aside the downgrade attacks (which can be mitigated in the ways described above), a simple change is to defer the exchanging of data until after public keys have been exchanged, so the identity of each participant can be verified.
Once this has been done, the data can then be sent encrypted, eliminating this obvious flaw.
We can do better, though. With the public keys exchanged and verified, we can leverage (ephemeral) Diffie–Hellman key exchange to avoid the computationally-expensive process of asymmetric encryption, and at the same time, provide forward secrecy – so that even if one party's private keys are compromised, past conversations cannot be decrypted. For such a security-conscious (obvious protocol flaws notwithstanding) quasi-military operation, this seems highly desirable.
Now at this point, we've basically reinvented TLS (in a high-level overview), and we should simply give up on AF and focus on the take-home message from all this: Don't roll your own crypto! ;)