“One of the first open references [to back doors] was in the 1983 movie WarGames,” the two explained. “In reality, modern back doors predate Hollywood’s discovery by about 20 years, starting in 196[4] with a time-sharing OS called Multics.”

[youtube https://www.youtube.com/watch?v=s1A4B9AzFNU]

According to Wikipedia, Multics implemented a single-level store for data access, discarding the clear distinction between files (aka segments) and process memory. More specifically, the memory of a process consisted solely of segments that were mapped into its address space. To read or write to them, the process utilized normal CPU instructions, while the operating system was tasked with ensuring all the modifications were saved to disk.

As Rambus Cryptography Research Fellow Pankaj Rohatgi notes, the U.S. Air Force “discovered” the concept of creating back doors during an evaluation of the Multics operating system. To be sure, Paul Karger and Roger Shell inserted trap doors as part of the review process; using them for system testing and to probe for potential security vulnerabilities.

“[This] sequence of code when properly invoked provides the penetrator with the needed tools to subvert the system,” Karger and Shell wrote in a USAF paper. “Such a trap door must be well hidden to avoid accidental discovery by the system maintenance personnel.”

According to Rohatgi, there are now many types of back doors.

“The most obvious is some extraneous process that is running or some extra code that has been inserted that isn’t part of the normal programming,” Rohatgi told Semiconductor Engineering. “The more sophisticated it is, the harder it is to detect. The best back doors are in the binary. That way it will never show up in the source code. There is also the concept of putting back doors in as a crypto implementation.”

Although back doors can be used to compromise a device’s firmware or security mechanisms, not all were designed with devious intent.

“In fact, many so-called [hardware] back doors are design flaws, which can then be used to compromise a chip’s security,” Worthman and Sperling stated. “[However], given the sheer complexity of large SoCs, not to mention the increased use of third-party IP in many designs, it’s also possible to build in extra circuitry that can allow an outsider to take control of a device.”

According to Worthman and Sperling, the practice of inserting back doors into chips has clearly become a highly controversial “science” since the nascent days of Cold War Multics.

Interested in learning more? The full text of “Back Doors Are Everywhere” by Ernest Worthman and Ed Sperling can be read here.

“[The cards use] AES-128, which is supposed to be virtually unbeatable by a brute-force attack, but turns out to be easy to defeat using side-channel analysis,” explained Iain Thomson of The Register. “Side-channel attacks measure things like power consumption, electromagnetic emissions and heat generation to work out what is going on in a chip. The technique has been around for years, and requires physical access to the target device.”

Have you read our primer?
– Side-channel attacks: explained

As Thomson reports, Yu Yu and his university team tracked power levels using an oscilloscope, monitored data traffic with an MP300-SC2 protocol analyzer and correlated the results with a SIM card reader and a standard PC.

“With this simple setup they cracked eight commercial SIM cards in between 10 and 80 minutes,” said Thomson. “Yu [also] demonstrated how the cloned SIM card can successfully impersonate the owner in class [and] showed how a cloned card could change the password on an Alipay and potentially drain the account.”

According to Yu, the above-mentioned hack is based on known differential power analysis attacks.

“The move to AES-based encryption algorithms in 3G/4G USIM cards did not systematically take advantage of state-of-the-art countermeasures against side-channel attacks,” he added. “Indeed, the USIM cards we analyzed essentially relied on plain (unprotected) software implementations of the AES.”

Helena Handschuh, a Director at Rambus’ Cryptography Research division, co-designed the MILENAGE standard discussed in Yu’s Black Hat paper. According to Handschuh, AES-128/Rijndael was chosen for MILENAGE in 2001 so that side-channel countermeasures could be easily incorporated in a SIM-class platform.

“Yu Yu’s paper demonstrates once again that, even though these algorithms are mathematically strong and unbroken, all implementers of crypto need to be aware of side-channel attacks and take appropriate steps to mitigate them,” Handschuh concluded.

As we’ve previously discussed on Rambus Press, physical electronic systems routinely leak information about the internal process of computing. In practical terms, this means attackers can exploit various side-channel techniques to gather data and extract secret cryptographic keys.

As such, the Rambus Cryptography Research division has designed a range of DPA countermeasures that offer a combination of software, hardware and protocol techniques specifically designed to protect tamper-resistant devices from side-channel attacks. These include leak reduction, incorporating randomness, generating amplitude and temporal noise, as well as executing protocol-level countermeasures.

Interested in learning more about how Rambus is helping to secure SoCs, devices and content? You can read more about our DPA countermeasures here, CryptoFireWall Cores here and CryptoManager platform here.

According to IDG’s Lucian Constantin, the scale of the problem is quite significant. Indeed, a recent report published by Veracode confirms that cryptographic issues are now the second most common type of flaws affecting applications across all industries.

“Cryptographic issues ranked higher in prevalence than historically common flaws like cross-site scripting, SQL injection and directory traversal,” Constantin explained. “[This] includes things like improper TLS (Transport Layer Security) certificate validation, cleartext storage of sensitive information, missing encryption for sensitive data, hard-coded cryptographic keys, inadequate encryption strength, insufficient entropy, non-random initialization vectors [and] improper verification of cryptographic signatures.”

As Veracode CTO Chris Wysopal notes, developers may be adding a significant amount of crypto to their code, especially for health care and financial apps. However, they are doing it poorly, with a lack of proper training adversely impacting implementation.

“It goes to show how hard it is to implement cryptography correctly,” Wysopal told the publication. “It’s sort of an endemic issue that a lot of people don’t think about.”

In addition to a lack of expertise, numerous crypto libraries are often difficult for developers to use. Indeed, Matthew Green, a professor of cryptography engineering at Johns Hopkins University in Baltimore, says many crypto libraries are “downright bad” from a usability perspective because they’ve been designed by and for cryptographers.

“Forcing developers to use them is like expecting someone to fly an airplane when all they have is a driver’s license,” Green told IDG. “[Then again], we don’t expect developers to re-implement TCP [a core Internet protocol] or the entire file system every time they write something. The fact that current crypto APIs are so bad is just a reflection of the fact that crypto, and security in general, are less mature than those other technologies.”

Carsten Eiram, the chief research officer at Risk Based Security, expressed similar sentiments in an email to IDG.

“While it’s always preferable that libraries including crypto libraries are made to be used as easily as possible, the programmers using them ultimately need to at least understand on a high level how they work,” he opined. “I really see it as a two-way street: Make crypto as easy to use as possible, but programmers having to implement crypto in applications should also properly educate themselves instead of hoping for someone to hold their hand.”

Commenting on the above-mentioned report, Eliott Jones, VP of User Experience at Rambus, told us that to realize the potential of cryptography-related solutions, usability will need to follow the same path that it has for other development technologies. With so much rich interaction and simplification of the user-facing tools in the modern development sphere, developers have also come to expect that they will not have to become a domain expert to enable technologies like cryptography in their projects.

“As with most nascent technologies, the products start from the ground up, from a pure engineering perspective. But as the space matures and adoption includes a broader user base, usability becomes a key need and differentiator. One gets the sense that, to date, software in the security space has been a tertiary concern. This is true not only for software libraries, but also for user interfaces (UIs) powering various security-related platforms,” said Jones. “From my perspective, effectively interacting with software libraries (upstream) and extracting real meaning from vast amounts of raw data (downstream) requires a highly intuitive (UI) paired with enhanced visual analysis tools.”

As Jones points out, that is precisely why Rambus engineers have adopted design cues from consumer-centric products when developing the software layers of the company’s CryptoManager and DPA Workstation testing platform (DPAWS).

“As examples, the software layers of both DPAWS and CryptoManager feature an intuitive UI that integrates advanced visualization capabilities. This helps increase the efficiency of side-channel analysis for the former and optimizes the Security Engine and related Infrastructure for the latter,” he added. “Although improving the usability of crypto libraries is a critical first step, it is important to realize that this is only one piece of the puzzle. From a broader perspective, an intuitive UI bolsters a platform’s efficiency, ultimately helping to define its competitive advantage.”