Tell us a little about Cellcrypt, its technology focus, number of employees, locations, and so on.
MEAKIN: We were founded in 2005 and we’re a U.K. based company. We secure voice calls [and text messages] on cell phones. These are standard off-the-shelf smartphones, and we provide government-grade encryption on those voice calls to protect calls from the threat of interception. We have about 50 employees, and our main office is in London. Cellcrypt, Inc. is based in Washington and we also have offices in Dubai and Miami.
OK. Cellcrypt has developed secure voice encryption applications for Android-based smartphones, in addition to the iPhone and Blackberry. Could these be used by military troops in Afghanistan, for example?
MEAKIN: Most of our business is government, military, law enforcement, though we also have a corporate division. So yes, we can and do support customers in the military. A couple of examples of this are welfare calling – where troops call back to their loved ones; another example is using the encryption application in covert operations by Special Forces. In covert operations, Cellcrypt smartphone encryption is particularly useful and fit for purpose because the voice encryption application can be downloaded over the air in minutes and used on a standard smartphone. So if you were in a covert operation, you could buy a standard smartphone from a store, connect to the Internet, and install the encryption application. It is inconspicuous when you use it – it just looks like a normal phone, rather than a military-style green device.
What is your primary motivation behind encrypting voice (and text messaging) in smartphones?
MEAKIN: The main use case is covering “sensitive but unclassified” information. This includes conversations with personnel, discussing plans – where to meet, who will be at the meeting, travel plans, ancillary information that becomes very important because [cell phone hackers] can then track people, track meetings, and that can become quite a powerful risk. And probably 95 percent of conversations in the government are of a sensitive but unclassified nature. Most likely all of those sensitive but unclassified conversations are made in the clear. Therefore, that is a market that Cellcrypt protects.
The reason we’re doing this is because cell phones are vulnerable to interception, not just by traditional mechanisms of countries or well-funded criminals, but there’s a new and emerging threat from hackers who have developed equipment that can intercept voice calls for as little as $1,500. It used to be hundreds of thousands of dollars – but now everyone can get ahold of it and so the risk of it happening has gone up.
Earlier you mentioned “government-grade” encryption. What kind of encryption do the Cellcrypt smartphone encryption applications use?
MEAKIN: We use encryption certified by NIST: FIPS 140-2, again for sensitive but unclassified information. Our application uses NSA Suite B crypto. And we use two algorithms for every cryptographic process, For a voice call, we first use RC4 256-bit to encrypt; then we encrypt it again using AES 256-bit.
Something else very important about our approach: We don’t have a central key server. Keys are managed directly between the recipent’s and caller’s applications. The key exchange is done by the software at both endpoints. There’s no human interface into the keys. Therefore, there’s a reduction in vulnerabilities because the key server can’t be compromised because there is no key server.
Though all the Cellcrypt smartphone encryption apps secure voice calls, looks like Cellcrypt mobile encryption app for Blackberry is the only one providing security for text. Why is that?
MEAKIN: The Blackberry application does have the additional feature of secure messaging. It’s not an encrypted SMS system, and it’s not an encrypted instant messaging system. It simply replaces the voice data with text data. Generally our system is used for perishable, [real-time] information.
The text is an alternative to voice – you might be typing in precise information such as an address, or text might be used as a backup to voice when a network in far-flung places makes latency on calls a couple seconds longer. Text is planned for other products as well at various stages in the future, including iPhone, Android, and Nokia smartphones, for which we also have a voice encryption application.
Wouldn’t somebody just use encrypted SMS?
MEAKIN: They could indeed, but ours is a different approach and designed to be used in different circumstances. For example, we avoid a “store and forward design.” When you send an SMS, it uses store and forward technology: The message is sent to a central server that stores the text, then attempts to send it to the receiver. If the recipient is on a plane, they get it 3 hours later, after the plane lands, because the SMS was stored and forwarded. That infrastructure guarantees delivery. In our world, that represents a potential vulnerability because we’re talking about perishable, real-time information: We don’t necessarily want information stored and forwarded later. A good example is a covert operation when the target has moved and someone watching in a coffee shop sends a message “Target moved, fire now.” For whatever reason, if the network isn’t available, you don’t want that message to get to the recipient half an hour later. There are operational consequences to that. Sometimes it’s better for the message not to get through at all. But if people want encrypted SMS as a requirement, we work with partners to deliver encrypted SMS store and forward.
How does your system know when a text message can’t be delivered, and how does your system cancel the message?
MEAKIN: It knows that the recipient isn’t online so it doesn’t try to deliver it in the first place. It’s like a voice call; for me to do that, I contact the recipient and do a cryptographic exchange and share a secret key. We have to both be online to do that. The secret key encrypts voice on my phone and decrypts it on the recipient’s phone so he can hear it. The other thing is that we authenticate each other. It’s the same with the text message. If the other person is not online, the text can’t be sent in the first place.
However, the user can set an automatic retry period, which is user defined. Otherwise, the retry time is 0. There might be circumstances where I say, “Now the person is going through a few tunnels and I’ll retry it for the next 5 minutes or maybe an hour.” I control the operational risk of the message not being delivered right now. If the recipient can’t be reached in the retry period, the message evaporates.
That assumes you exchanged keys earlier?
MEAKIN: Yes. When I first call someone using Cellcrypt and we’ve never contacted each other before, we exchange public keys. The public key I give to somebody else is what they use to encrypt the voice they send back to me, which my private key decrypts. It can only be decrypted by my private key. After a call has been made and we end the call, I have the option of retaining the other person’s public key in my address book. [Thereafter], this can be used to exchange messages. When I send a message to him, I can already encrypt it with his public key. But I still need to connect with him for mutual authentication to make sure it’s the right person I’m talking to and derive a secret key to encrypt the text. And, as I mentioned, we both need to be online to do that.
The Cellcrypt data encryption only secures text, not emails or other data?
MEAKIN: Yes, as I mentioned, it’s not encrypted SMS, it’s not encrypted instant messaging, and it’s not encrypted Email. Each of those systems has its own architecture, which implies certain things. Those all have guaranteed delivery and store and forward architecture, which, again, we don’t have. We are only sending alphanumeric strings in place of voice.
Will you be adding encryption for emails and other data to the Cellcrypt application?
MEAKIN: No because those are provided by our partners. One thing our technology does really well is deliver information in real time. That’s what the focus of our patents and innovation is. A voice call obviously is in real time, and you want the performance to be exceptionally good. So we’ve tuned our technology to deliver that. Email and SMS are not real time. It doesn’t matter if they are delivered a minute later, so we don’t need to tune that to real-time performance data. However, we are interested in transmitting other data – including video – [and enabling secure] file transfers in the future.
How does the Cellcrypt encryption application work?
MEAKIN: The application that works on the smartphone itself is straightforward. Just click on the Cellcrypt icon to use it. It is a user interface that emulates a normal cell phone call and address book: You dial, speak, hang up, and so on. Its key strength is the crypto system behind the scenes. But the user experience is a very easy thing. That’s important because if the system is not easy to use, people won’t use it, even if their operational security policy says they must use it. It’s one of those untalked-about truths: that even though everyone wants to be secure, if they haven’t got systems that are convenient, then they’ll just use their cell phone.
Which kinds of networks does the Cellcrypt secure smartphone application run on?
MEAKIN: Effectively, this is an encrypted Voice over IP [VoIP] call – although we used our own protocol. So it will run on any network with an IP connection: GSM, CDMA, 2G, 3G, 4G, mesh networks, Wi-Fi, and satellite.
Is it possible that some parts of the world could not support that type of network?
MEAKIN: Yeah somewhere, some places, but most countries have data cellular networks. There are very few places that don’t. The biggest problem is the quality of the network. Some places in Africa and Latin America only have 2G networks and are bandwidth constrained. It gets a bit tricky. But one of the advantages of our product is we can operate at a very small bandwidth and over a very small 2G GPRS network. GPRS was the first data network applied to cellular. If there is no cellular coverage at all, some customers use satellite.
Tell us about the architecture of the Cellcrypt smartphone encryption application.
MEAKIN: You have the application installed on both smartphones and a call is encrypted end-to-end between them. Both applications are connected to a signaling server in-between. When you make a call, one application asks the server if the other application is available to receive a call – as well as other things like authenticates the user and checks the license. If it is available, the server sets up the applications to talk directly to each other and then they perform the cryptographic handshake and make the call. The call is routed over our ECDN [Encrypted Content Delivery Network], which is a series of servers around the Internet that optimizes routing and call performance. Importantly, encryption/decryption is only done at the endpoints by the applications – the servers just set up and route calls and carry encrypted data.
We also have an endpoint application that sits on a server in the office and interfaces to a PBX. This allows an encrypted, call into the office and can connect to landlines, voicemail, and conference calling facilities provided by the PBX.
What about latency and voice quality?
MEAKIN: We are constantly using our innovation and technology to overcome the challenges. Our target is to have crystal-clear transmission with zero latency. That’s a nice objective. It’s not practical for that to happen all the time, just like any other communication mechanism. Whether it’s cellular or a landline call, there are always trade-offs between latency and voice quality. But that’s really what our core competency is. If I’m calling from London on a 3G network to Miami on a 3G network, we’ve recorded latency as 151 milliseconds. That’s unnoticeable to somebody who’s talking. The international standard for landline calls is about 300 milliseconds.
Because it’s an IP-based call, the speech quality is very good because the packets get recombined at the recipient’s end. But bandwidth changes and the inherent latency of the network changes constantly – which can affect the call. So a 2G GPRS call might have latency go down to 2 or 3 seconds in some circumstances. We intend to keep speech quality as high as possible and trade-off latency because we think it’s more important to get an accurate voice message to the receiver than it is to get it there half a second sooner. If you’re on Wi-Fi or 3G, latency is good for a normal voice call. It’s only if you get to 2G GPRS or EDGE, that it might get out to 1, 2 seconds. It is a variable that is different for every person.
What’s the future of the DoD in regard to ordering smartphones for troops in the field? Or are you more targeting benign DoD workers for your apps?
MEAKIN: They will, they are doing. And as smartphones roll out in the DoD for data services, we will be looking to help provide a solution for securing the voice part.
But really, anybody who uses a smartphone needs a secure layer on it, if they’ve got sensitive information they want to protect. Talking about customers, if you were traveling to Latin America, you might need it so you don’t get targeted for kidnapping. It’s applicable really to anyone talking about something that can be exploited by someone else. It could be when, where, and with whom a meeting will be held, as I mentioned.
Will your encryption applications cover classified information, too, in the future?
MEAKIN: In other regions, we do have governments using it for classified information. Those governments might have slightly different security requirements than someone like the U.S. or the Western/NATO governments. The security requirements of individual nations are specific to them. But I think it’s worth looking at. The reason is cost of implementation. If you can deliver security over cell phones, you’re solving a couple problems. One is you’re using COTS devices, and they’re cheap. The second thing is they’re interoperable; everything works with everything else. If you provide a security layer, it makes it very easy.
I think that [some] governments are and will be looking at hardening the system such that classified information can be discussed. Obviously one of the downsides of using a COTS smartphone is there are other things to do to it, such as make the hardware more robust and make sure it becomes tamperproof. The downside is that it’s open, and it can be tampered with. Certainly we need to lock that down. And plans can be put in place by governments to make sure that the overall security system in COTS smartphones is secure enough for higher classifications. It is an achievable project.
Cellcrypt 703-879-3328 www.cellcrypt.com