Secure Doc Sending

This week, I sent an encrypted file to someone I had just met on the phone a couple of minutes earlier. The scheme we used didn’t require that I remember any PINs or passwords, and it didn’t force me to register on any sites that would (inevitably) lose my information to hackers. All I did was accept a message on my iPhone, and then I pointed, clicked, selected, and sent. If I had to describe the experience, I’d say that it was sort of like sending a fax.

The name of the encrypted file transfer tool I was using is BotDoc, and the person receiving my file (it was a pic of a WeWork coffee mug) was the company’s founder and CEO, Karl Falk. I’d been introduced to Karl through my good friend Jason Clark from SixThirty CYBER and 360Velocity. Jason had suggested that I would enjoy reviewing and testing their secure file transfer application – and sure enough, I was intrigued at the potential use cases.

Let me start with a story: Back in 1985, an old colleague of mine at Bell Labs, Paul Rubin, suggested that I send a Fax. I had not heard that word before, and wondered if he meant to say VAX (which I had heard). This was my first intro to that awkward, noisy machine I’ve used a million times since, have never liked, and now never use. By the way, faxes derived their security from circuit switched telecom: If you were OK saying it, then you were OK faxing it.

More recently, however, file transfer has gone the way of email and text attachments. That is, if you are doing business with a customer, sending forms to your bank, providing fliers to your church, and so on and so forth – then you are more than likely sending an attachment. The problem is that these attachments are being sent over networks that have proven to be less than secure. And while encryption is the obvious solution, it’s easier said than done.

Karl and I spent time discussing why secure file transfer is not more commonly used in business. We agreed that the problem is not the cryptography, because excellent cipher toolkits are available for product developers to use in product design. We also agreed that awareness of the actual need to encrypt is not really the issue either. Almost all business people know that sending a sensitive document as a clear text attachment is a bit naughty.

And yet, everyone does it. I must say that pretty much every day since starting TAG Cyber, I’ve either sent or received something that I knew would have been better handled using a more secure form of transmission. “People today know that sending something private over the Internet is a bad idea,” Karl explained, “but because they have no idea how else to do it, they simply attach the file to a text or email and transfer it insecurely.”

My conclusion – and Karl agreed – is that existing secure file transfer solutions have failed because users are asked to do more than just point and click. In contrast, consider that SSL for e-commerce succeeded via the direct insertion of CA public keys into the browser. The amazing result (which netted billions for Marc Andreessen) is that buyers just point and click to buy books on Amazon. If they had to do anything more, then K-Mart might still be in your local strip mall.

The initial set-up for BotDoc is simple: Only one participant in the sending protocol needs to have a BotDoc account. This is an important property for contact or care centers who might be connecting with customers for whom no prior arrangement has been established for secure transfer. If the center possesses BotDoc accounts, then they can send and receive secure documents with their customers without the need to set-up accounts via portals.

Let’s assume that Alice is the BotDoc account holder (fans of Bob can reverse the process). If Alice wants Bob to send her a document securely, then she sends a special link to Bob via email or text. When Bob clicks the link, it connects him securely to an empty container set up in the Azure cloud where he can upload the requested file. The connection is encrypted, and Bob’s authenticity is established via the mobile number or email.

Now, before you go nuts telling me that this is susceptible to phishing attacks (which it is), I will remind you that the most typical use-case here will be Alice and Bob on the phone discussing business. At some point, a document must be sent securely, and this is where the tire hits the road: In virtually every business setting I know, the urge to send this as a clear text attachment often exceeds the urge to be secure. Let’s face it – you know this is true.

Using BotDoc, there are multiple authentication factors at play: There is the contextual verbal discussion in which Alice offers to provide a means for Bob to send the file over. This includes time, purpose, and context. Then there is the knowledge of Bob’s email or mobile number, followed by his clicking on the link from the targeted account. This is not perfect, but it is a hell of a lot better than just punting and attaching your signed real estate contract to a Gmail.

As you would expect, the process of Bob receiving the secure file transfer from Alice works roughly in reverse, with the clickable link pointing to a container with the encrypted file of interest. It is downloaded across an encrypted transfer and Eve-in-the-middle should not have an easy time prying into the transaction. (In case you were wondering, the container stores the files using AES 256, and the transfer is over SSL.)

Now, I mentioned phishing earlier – and here is the issue: Bad guys could send phony BotDoc-like requests with dangerous links to gullible targets. I crafted just such a test phish and sent it to Karl while he was telling me about his company. And while this is certainly an issue, here is my view: This isn’t such a big issue, so long as the use-case follows the progression described above. Alice and Bob are in mid-discussion, and realize that a secure exchange is needed.

I reminded Karl that as his company expands its size, scale, and scope, the phishing risk might grow accordingly – and we joked that this is not a terrible problem for a small company to aspire to. Nevertheless, if you measure this tool against the common choice of insecure attachments, and if you combine it with the contextual use-case with Alice and Bob in conversation, then you find yourself with a useful little tool.

I recommend that you take some time to connect with Karl and his team. Ask them to explain their product and give you a demo. For a segment (certainly not all) of the file sending community, my belief is that this is just what the doctor ordered. The alternative is to send insecurely – or perhaps to revert to an old noisy fax machine. This would be a challenge for me, because I’d have more luck with a slide rule these days than with sending a fax.

Let me know how you make out.