Mobile's Cryptography Conundrums

Immaturity in mobile-device hardware and operating-system environments is holding back organizations' deployments of strong cryptographic protections around mobile applications, according to a pair of unrelated presentations at last week's RSA Conference.

In one instance, the National Security Agency (NSA) discussed how difficult it was for the government to tweak commercially available devices to conform to government cryptographic standards. And in another case, a pair of experts from the firm Cryptography Research showed a demonstration of how mobile devices are radiating cryptographic keys for sensitive applications, such as payment applications through wireless transmissions.

"Why is this so hard? We tried very hard to just stick with the standards and build a component-based infrastructure using what we think are the industry standards now, and yet at every point we ran into little gotchas," said Margaret Salter, technical director for the Fusion, Analysis and Mitigations Group within the Information Assurance Directorate of the NSA. "So I'm really hoping I can engage industry and everybody to sort of push together for this standards-based idea so that it's easier for everybody to build a system like this." Salter's much-attended discussions -- so much so there was an encore presentation -- walked the audience through the NSA's process of creating an architecture where it could encrypt voice and data over commercial 3G and 4G networks using commercially available phones. According to Salter, the genesis of the project came due to the rapid advancement of mobile handsets and tablets that far outpaced the NSA's ability to create its own home-brew devices, which in years past was its mobile strategy.

"We were looking at regular tablets and regular smartphones and trying to figure out some way of creating an architecture where those phones could be used to protect some of our most classified information," she said, explaining that one of the first applications most important to the agency was Voice Over IP. "So we considered voice as a data connection; we looked for the secure protocol we could use to connect that up to our back-end infrastructure and terminate that on some sort of SIP server or unified communications server, and we also encrypted that. And that's how we get what we call double-tunneling. And that's basically been our guiding principles for creating an architecture for mobility."

However, as the agency began evaluating operating systems, it found there were gaps that caused decision-makers to worry that they couldn't count on those OS platforms alone to secure the information. That meant having to run custom middleware on the OS. It quickly found that the only way it would be able to write those kinds of custom applications was if it used Android phones because of the open-source platform.

"But once we did that, we had to narrow it down because of that one set of requirements, and then we started to look for good IPSec implementations on those Android OSes running on handsets. We found none that would meet our requirements," she said. "So every time we made a decision, it turned out that it almost zeroed out our possibilities of choice for all of the other requirements we had. We reached the same problem in the apps space."

In the end, the agency landed on a "very thin-client experience," explained Salter. "You have to be connected up to the infrastructure to get any data or any services, so in a sense it is almost like a cloud in that all of the data that you need doesn’t come down and live on the device."

According to Salter, while many hardware and software vendors have been fairly cooperative, they have a difficult time meshing the NSA vision with their own business models.

"I think we have a little bit of trouble when we get to the standards piece because it's not clear that right now all of the mobility vendors think it's the greatest idea on earth that their products could interoperate with another vendor's product," she said. "But our architecture has a complete dependency on that. We want to be able to pick up one piece or one product and put a different vendors product in and not have to rearchitect the whole infrastructure."

Meanwhile, while vendors figure out interoperability and standards-based deployment issues, they must also think about how to mitigate hardware vulnerabilities that are putting cryptographic application deployments at risk. Gary Kenworthy, principal engineer at Cryptography Research, and Benjamin Jun, CTO of Cryptography Research, demonstrated vulnerabilities in current phones that jeopardize the encryption keys that secure sensitive applications.

"When we started scanning for emissions and leaks, we thought we would find something," Kenworthy said. "And we did. But what surprised us was just how strong the leaks were. We were able to extract keys in some cases from 10 feet away or more."

They showed on stage how easy it is to use simple antennas and probes to pick up leaky transmissions containing key information. According to both of them, the problem is that current sensitive applications, such as mobile payment and premium media services, mimic traditional software used on immobile hardware that has safeguards for transmission leaks built in. But at the moment, there's no such safeguards within mobile hardware.

"There are techniques used in set-top boxes and in credit-card terminals that have been in place more than five or 10 years," Jun said. "So there are techniques for solving this problem, but the mobile environment is so new that applications and the system environments often don’t have these countermeasures."

In the presentation, Jun and Kenworthy suggested that one way to protect applications would be for developers to split up operations that use keys into numerous parts, but that solution would mean a hit on processor performance and battery life.

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.