Armored Transactions
Yours truly was interviewed by Kelly Jackson Higgins, Senior Editor, Dark Reading last week about TriCipher’s latest product announcement, Armored Transactions. Go ahead and read up over there. When you come back I’ll lay out a few more details for you.
Kelly did a nice job capturing the essence of Armored Transactions, but as the tired saying goes, “pictures speak a thousand words”. Below lays out the basic armored transaction flow:
First a couple of things to note:
- As you can see, the user is already protected from a man-in-the-middle (MITM) attack where the attacker is out on the internet in some manner. While the industry is only beginning to awaken to the realities of this type of attack now that they are occurring, we’ve worked to educate and protect our customers against this kind of attack for years.
- So what are we protecting against with Armored Transactions? Essentially, what we and others are referring to as man-in-the-browser attacks. Technically, this is also a man-in-the-middle attack since the attacker is between the victim and the target, but the attacker has moved one step closer to the user. As nicely highlighted in the Dark Reading article, the technical vector used by the attacker is immaterial. The attack may be a browser helper object (BHO) of one variety or another or some other mechanic to essentially disconnect the user from what they believe they are doing in the browser and what is actually being submitted over the wire.
- How does this attack bypass the “over the wire” MITM protections shown by the green pipes in the diagram above? The attacker has gotten close enough to the user to get ahead of the SSL stack and manipulate the session contents before they are submitted to the secure tunnel.
Now let’s walk through the actual process flow. The Scenario: Attacker has gotten a foothold at some point to manipulate the browser such that what the victim is inputting is actually different from what the attacker is submitting on the victim’s behalf.
- Victim submits $200 to Bob’s Garage and the attacker changes it to $500 to BadGuy Offshore.
- The Bank application posts the transaction to the TriCipher ID Vault for confirmation.
- The ID Vault has a separate secure MITM-proof connection to the ID Tool on the user’s PC. The ID Tool is running outside the browser and consequently can be securely delivered the transaction the Bank received. I choose to refer to this as a “side-band” communication instead of an “out-of-band” situation as the communication is still over the internet vs. to a phone or other non-PC device. At this point, on the same screen, the victim is given the opportunity to view both what they intended and what was received at the Bank. If there’s a problem, the lie is shown as the browser and ID Tool contents will differ. Obviously, the user will “Decline” this BadGuy Offshore example.
- However, if the transaction matches up, the user would click “Approve” along with providing their password to approve. This is of course optional workflow as a simple click of an “Approve” button could also be used. Another option provided by the powerful nature of TriCipher credentials, is that the transaction can be digitally signed to strengthen the non-repudiation environment for the transaction.
- The approved transaction is sent back to the application where it is cleared for processing.
Actually pretty simple and straightforward. No extra devices for the user to deal with, same GUI environment they are familiar with for authentication, one less attack vector for criminals to exploit.