Emission Security: Invisible Threats and Compromising Emanations

Emission Security (Emsec) is an area of information security devoted to preventing attacks that use compromising emanations, namely: conductive (transmitted along conductors) or radio-frequency electromagnetic signals.
Military organizations traditionally pay enormous attention to protective measures of the TEMPEST class, which prevent the interception of the spurious radio-frequency emanations generated by computers and other electronic equipment, with the aim of reconstructing the data being processed. In the commercial sector this threat became relevant in the context of side-channel attacks, when the computations performed by a smart card (for example, the creation of a digital signature) are observed by measuring the current consumed by the device. In addition, researchers have discovered attacks exploiting the spurious optical, thermal and acoustic emanations of various equipment.
These threats are closely connected with electromagnetic compatibility (EMC) and radio-frequency interference (RFI), which can accidentally disrupt the operation of systems. As more and more devices are connected to wireless networks and processor clock frequencies move into the gigahertz range, the problems of EMC/RFI, Emsec and electronic warfare (Radio Electronic Warfare) inevitably intersect and worsen.

A Historical Excursion: From Crosstalk to TEMPEST

Crosstalk in telephone wires was well known to the pioneers of telephony in the 19th century. Two-wire circuits stacked on the cross-arms of poles often became a cause of leakage. The solution was the use of twisted pairs. However, the military use of leakage began during the British expedition to the Nile and Suakin (1884–1885).
During the First World War, field telephone wires laid for communication with the troops stuck in the mud of Flanders often ran parallel to enemy trenches at a distance of only a few hundred yards. Single-core insulated cables with grounding were used to reduce weight. It was soon discovered that leakage to earth causes strong crosstalk, allowing the enemy's messages to be intercepted. By 1915 amplifiers on electronic valves made it possible to increase the interception range to 100 yards for telephony and 300 yards for Morse code. By 1916 single-core grounded circuits were prohibited within a zone of 3000 yards from the front line.
The Second World War brought the development of radar, direction finding and low-probability-of-intercept communication methods. By the 1960s the spurious radio-frequency emanations from the local oscillators of household television sets were being intercepted by direction-finding equipment in "TV detector vans" in the UK, where television owners were obliged to pay an annual license fee.
The turning point in the awareness of the scale of the threat was the 1985 publication by the Dutch researcher Wim van Eck. He demonstrated how, with the help of a modified television set, one could reconstruct at a distance the image displayed on a video monitor (VDU). The fact that TEMPEST attacks could be carried out with the help of homemade equipment caused a shock in the computer security industry.

Technical Intelligence and Countermeasures

Before analyzing the spurious emanations of standard devices, it is necessary to consider the simplest and most common attacks using implanted devices — "bugs".
The arsenal of covert information-gathering means available on the market is enormous:

• Radio microphones: The simplest devices costing a few tens of dollars can be hidden under a table. Their main limiting factor is battery life (from days to weeks), and the range is usually a few hundred yards.
• Mains-powered devices: More complex bugs are powered from the telephone line or the electricity mains, which allows them to operate indefinitely long. Some are disguised as electrical adapters, combining in themselves a microphone, a radio transmitter and a television camera.
• Laser microphones: They work by directing a laser beam at a reflecting or semi-transparent surface (for example, a window pane) in a room where a conversation is taking place. The sound waves modulate the reflected light, which is then decoded at a distance.
• The Furby toy: The US National Security Agency (NSA) prohibited bringing these toys into its buildings. The reason was that the Furby "remembered" and accidentally reproduced phrases said in its presence, which created a risk of unintentional information leakage.

Countermeasures require high qualification. To search for hidden electronics at close range, non-linear junction detectors are applied. They emit a weak radio signal and listen for the harmonics generated by transistors and diodes. However, if the bug is hidden inside other electronic equipment, the detector turns out to be useless. There also exist expensive bugs that do not re-radiate the signal at all.
To protect premises, shielded rooms (Faraday cages) are used, as well as strict procedural measures such as the prohibition on bringing in personal electronics and regular inspections.

Passive Attacks: Leakage Through Cables and the Radio Channel

Passive attacks assume that the attacker merely receives electromagnetic signals, without interfering with the operation of the system. They are divided into conductive (through cables) and radio-frequency ones.

Leakage Through Power and Signal Cables

Engineers have long known that high-frequency signals "leak" everywhere. Conductive leaks can be suppressed by careful design: the use of filters and screens on power and signal lines.
In the military sphere this is implemented through the concept of Red/Black separation. Equipment processing confidential data (Red) must be isolated, with the help of filters and screens, from equipment that can directly transmit signals to the outside world (Black). Devices that have both "red" and "black" connections (for example, cipher machines) present a particular difficulty. The cost of such protective measures is extremely high: filtering thousands of cables in a server room or on an air base, and strict configuration control, can cost millions of dollars.

Leakage Through Radio-Frequency Signals

Any equipment radiates radio waves. Video monitors (VDUs) generate a weak TV signal (VHF or UHF) modulated by a distorted version of the displayed image. The video signal is available at various points of the equipment, in particular in the beam current of the cathode-ray tube. These emanations contain numerous harmonics of the line-scan frequency, some of which radiate better because of the resonance of cables and components at their wavelength. With the help of a wideband receiver these emissions can be received and reconstructed into a video image.
Flat panels (LCD) are also vulnerable. In a typical laptop a serial line passes through the hinge from the system board to the display, which transmits the video signal and can easily be intercepted.
Soft Tempest is a software technology developed to protect against interception. It uses software methods to filter, mask or distort the information contained in the electromagnetic emanations. For example, researchers discovered that most of the energy carrying information from a VDU is concentrated in the upper part of the spectrum. Applying a low-frequency filter to a standard font (convolution with a filter) makes interception practically impossible, while the visual quality of the text for the user hardly suffers.

Active Attacks: From Viruses to Glitching

Active attacks include not only interception, but also deliberate interference with the operation of equipment or the use of external influences to extract data.

TEMPEST Viruses

An attacker can write malicious code that forces a computer to work as a low-power radio transmitter. By changing the patterns of access to memory or to the data bus, the virus modulates the electromagnetic radiation of the system, transmitting stolen data to a nearby receiver. This makes it possible to bypass even air-gapped systems.

Nonstop Attacks

This class of attacks exploits electromagnetic emanations that are accidentally induced by nearby radio transmitters. If equipment processing confidential data is used next to a powerful transmitter (for example, on a ship or an aircraft), the transmitter's signals can induce currents in the computer's circuits. Because of the non-linear effect of junctions, these currents are modulated by the confidential data and re-radiated.

Glitching and Differential Fault Analysis

In the world of smart cards and protected microcontrollers, active attacks are often aimed at introducing faults into the normal operation of the device.
* Glitching: The attacker introduces transients into the power or clock lines of the card. For example, in early banking applications an unjustifiably high clock signal caused a reset only after several cycles. This made it possible to replace one clock pulse with two narrower ones, forcing the processor to execute a NOP (no operation) command instead of the planned instruction. This gives the attacker the opportunity to "jump over" access checks.
* Differential Fault Analysis (DFA): If a random error can be introduced into a cryptographic algorithm (for example, RSA) at a certain stage of the computations, this can lead to a catastrophic leakage of the key. For example, if a signature is computed using the Chinese Remainder Theorem (CRT), an error in one of the branches of the computation allows the secret key to be recovered instantly.

Combined Attacks

The most dangerous scenarios combine passive and active methods. For example, the use of a laser for the partial ionization of a target transistor at the moment when a power consumption analysis (Power Analysis) is being carried out. This allows the attacker to read individual bits of data from memory with the highest precision, even if the logic of the chip is encrypted or uses a "glue logic" architecture.

Timing Analysis

In 1996 Paul Kocher demonstrated that many implementations of public-key algorithms, such as RSA and DSA, reveal information about the key through the time spent on their execution. His idea was that when performing exponentiation the software usually processes the secret exponent bit by bit, and if the next bit equals one, a multiplication is performed. This allows an adversary who knows the first b bits of the exponent to compute the (b+1)-th bit by observing a series of exponentiation operations. Attack and defense developed in parallel, and for a long time many considered their implementations secure if they used the Chinese Remainder Theorem. However, in 2003 David Brumley and Dan Boneh implemented a timing attack against Apache using OpenSSL and showed how to extract the private key from a remote server by measuring the time of about a million decryption operations. Modern robust implementations of public-key algorithms now use blinding to prevent such attacks.
In 1998 John Kelsey, Bruce Schneier, David Wagner and Chris Hall pointed out that block ciphers using large S-boxes (such as AES) may be vulnerable to timing attacks based on cache misses. An attacker can test guesses about the output of the first round of the cipher by predicting whether a supposed value will cause a cache miss when looking up the S-box, and comparing this with observations. Since then a number of researchers have refined this attack, and nowadays a naive implementation of AES can be broken by observing only a few hundred encryption operations.

Optical, Acoustic and Thermal Leakage Channels, the Assessment of Emsec Threats and the Beginning of API Attacks

We have considered the classical radio-frequency and conductive attacks. However, as technologies developed, researchers discovered that information leakage can occur through the most unexpected physical media: light, sound and heat. In addition, we will analyze how serious these threats are for governments and business, and then we will consider attacks on application programming interfaces (APIs), where logical design errors make it possible to bypass even the most robust cryptography.

Optical, Acoustic and Thermal Leakage Channels

In recent years a stream of research has revealed new classes of side-channel attacks using non-standard physical phenomena.

Optical Attacks

In 2002 Markus Kuhn demonstrated that the content of the screen of a CRT monitor (VDU) can be recovered optically even if one analyzes only the diffuse light reflected from the walls of the room or from the operator's clothing and face. Using a high-performance photomultiplier and an oscilloscope, he showed that the blue and green phosphors in CRT tubes decay within a few microseconds. This diffuse reflected light contains a significant part of the information from the screen, encoded in the time domain.
Another optical vulnerable spot was discovered by Joe Loughry and David Umphress. They investigated the strobe indicators (light-emitting diodes) that are installed on data transmission lines (for example, on the serial ports of modems, routers and other network equipment) to indicate activity. It turned out that a significant number of such indicators actually transmit optical data, modulating the light at the frequency of the data transmitted along the line.

Acoustic Attacks

In 2004 Dmytro Asonov and Rakesh Agrawal showed that different keys on a keyboard emit sufficiently different sounds that they can be distinguished. They trained a neural network to recognize the clicks of keys and were able to intercept the text being typed with an error rate of only a few percent.
In 2005 Li Zhuang, Feng Zhou and Doug Tygar developed this idea, creating an attack that made it possible to decipher a recording of text typed over ten minutes on an unknown keyboard. They used the characteristics of the keyboard in combination with the statistics of natural language (English text) in order to determine which particular key corresponded to each sound.
An even deeper level of acoustic attacks was demonstrated by Eran Tromer and Adi Shamir. They proved that keys can be intercepted by analyzing the acoustic emissions generated by the capacitors on the motherboard of a PC. These sounds are at frequencies above 10 kHz and are modulated by the computational processes.

Thermal Covert Channels

In 2006 Steven Murdoch discovered that many computers reveal their processor load through thermal leakage. The clock frequency (clock skew) is a function of the ambient temperature and can be measured remotely. Murdoch put forward the hypothesis that, by analyzing these thermal patterns, an attacker can even determine the geographic location of a hidden machine: the longitude — by the time zone, and the latitude (more slowly) — by seasonal temperature fluctuations.

How Serious Are Emsec Attacks?

Threats to Governments

For embassies in hostile countries the Emsec threats are quite real. If your embassy is forced to occupy the second floor of an office building, where the local secret police are located on the first and third floors, protection becomes an extremely difficult task. Shielding all the electronic equipment is part of the solution. However, the human factor remains a vulnerability: for example, cleaners working for the adversary may deliberately weaken the Tempest-protection seals on the equipment.
At the same time, in the USA there is a growing skepticism as to whether foreign agents have ever really carried out successful Tempest attacks. There are anecdotal stories, for example, that the only known use of such interception methods in North America was carried out by Canadian intelligence, which simply eavesdropped on the conversations of American diplomats during grain sale negotiations.
A real scandal connected with leaks and the violation of Emsec standards occurred in the USA with the company Lockheed-Martin during the installation of equipment on Coast Guard vessels within the framework of the Deepwater project. The investigation revealed not only defects of emission security (incorrect types of cables, violations of the rules for separating red/black circuits, missing filters), but also a whole series of other problems: cracks in the hull, non-watertight outdoor radio stations and video surveillance systems that did not provide a 360-degree view.

Threats to Business

For the commercial sector, Emsec attacks have become a serious problem, especially in the smart card industry. The discovery of differential power analysis (DPA) attacks by Paul Kocher delayed the introduction of banking smart cards by several years. The industry was forced to develop ad-hoc protection mechanisms, and although current devices are better protected, they still rely on a complex mixture of hardware and software measures that require constant vigilance.
In addition, the "unclassified" aspects of electromagnetic emission management — electromagnetic compatibility (EMC) and radio-frequency interference (RFI) — are becoming increasingly critical. Clock frequencies are rising, wireless devices and networks proliferate, and digital electronics penetrates into devices that were previously analog or mechanical. The appearance of software radios, which digitize the signal at an intermediate frequency and process it in software, opens up new possibilities both for protection and for attacks.

API Attacks

Many supposedly protected devices have an application programming interface (API) that can be called by untrusted people and processes.

• A bank server may ask a connected hardware security module: "Here is an account number and the customer's PIN code, encrypted with a key that we share with VISA. Is the PIN correct?".
• If you enable JavaScript in a browser, you provide an API that the owners of the sites you visit can use to perform various actions.
• A secure operating system may restrict the calls that an application can make, using a reference monitor to prevent the leakage of information from High to Low.

The natural question: is it safe to divide tasks between trusted and less trusted components? Recent research has shown that the answer very often is no. Designing secure APIs is an incredibly difficult task.
API security is connected with a number of problems already discussed. For example, multilevel security (MLS) systems impose restrictions on the flows of static data, whereas a security API often tries to prevent the leakage of information under conditions of dense and dynamic interaction — which is much more difficult. It is also connected with protocol security: bank security modules are often vulnerable because of the interaction of the many protocols they support. And finally, it is connected with software security: the implementation of JavaScript in Firefox allowed calling programs to scan all the variables set by existing plug-ins, which could compromise your privacy.
The most common mode of API failure is that transactions that are secure individually become insecure in combination — because of application syntax, feature interaction, slow information leakage or concurrency problems.
In the context of embedded systems we discussed prepaid electricity meters: the token vending machines use tamper-resistant modules to protect the keys and the meters. The attack consisted in changing the electricity tariff to the lowest possible value and issuing tokens entitling the holder to receive energy at a price significantly below market. The design error was that the tariff reporting was not rigidly tied to the end-to-end design of the protocol.
A potentially critical example is the "Trusted Computing" initiative. The TPM chip for the secure storage of cryptographic keys is installed on most motherboards. It was planned that future applications would have an "insecure" part running on top of Windows, and a "secure" part (the NCA) running on top of a new security kernel (Nexus). The question arises: how to protect the interface between the application and the NCA? Whenever a trusted computer communicates with a less trusted one, the language of their communication is of critical importance. You must expect that the less trusted device will try all sorts of unexpected combinations of commands in order to deceive the more trusted one.

Attacks on the APIs of Cryptographic Modules

We learned a great deal about API security from the example of failures in the hardware security modules used by banks to protect PIN codes and cryptographic keys for ATM networks. In 1988 Longley and Rigby revealed the importance of separating key types. However, systematic analysis began in 2000, when the question was asked: "How to make sure that there is no chain of 17 transactions that will lead to the leakage of a key?". Studying the manuals, the following vulnerability was discovered.

The XOR-To-Null-Key Attack

Hardware security modules are controlled by transactions sent by host computers. The module contains master keys in tamper-resistant memory. However, since memory inside the device is often insufficient for all the keys, working keys are stored encrypted outside the device. The way of encrypting these keys assigns them a kind of "type system".
For example, in the VISA security module there existed a transaction for generating a terminal master key (Terminal Master Key, KMT) for an ATM. Since the security of an ATM is based on dual control, it was necessary to generate two separate key components that could be entered into the ATM by two different people (for example, a manager and an accountant). The module generated a key component and printed its clear value, and also returned its value encrypted under the corresponding master key K_M:
VSM -> host: {KMTi}KM
There also existed a transaction that combined two such components to obtain a terminal key:
Host -> VSM: {KMT1}KM, {KMT2}KM
VSM -> host: {KMT1 XOR KMT2}KM

The idea was that KMT=KMT1⊕KMT2. However, nothing prevented a programmer from taking any encrypted key and feeding it twice into the second transaction. The result was a known terminal key (a key consisting of all zeros, since the key is XORed with itself):
Host -> VSM: {KMT1}KM, {KMT1}KM
VSM -> host: {KMT1 XOR KMT1}KM (the result is a null key)

Now that we have introduced a known key into the system, what can we do with it? The module had a transaction for encrypting any key encrypted under K_M under any other key which is itself encrypted under K_M. The purpose of this strange transaction was to allow a bank to encrypt its PIN verification key under the terminal master key in order to send it to the ATM for local PIN verification. Moreover, the key type "terminal master key" and the key type "PIN verification key" were identical.
The effect was devastating. A programmer could take the bank's PIN verification master key (which is also stored outside the module, encrypted with the help of K_M) and force the module to encrypt it under the null key that we have just created:
Host -> VSM: {0}KM, {PIN}KM
VSM -> host: {PIN}0

Now the programmer could decrypt the PIN verification master key — the "crown jewel" of the bank — and compute the PIN code for any customer account. The purpose of the security module was completely destroyed; it would have been simpler for the bank to store the PIN codes in the clear.

The Attack on the IBM 4758

The next attack was found using formal methods. Mike Bond built a formal model of key types and immediately discovered another error. The key type "communication key" was used for MAC keys, which had the property: you could enter a MAC key in the clear and obtain it encrypted under... "any key encrypted under K_M". This was yet another way to introduce a known key into the system. You could enter an account number, pretending that it was a MAC key, and obtain it encrypted with the help of the PIN verification key — this would give you the customer's PIN code directly.
Soon after this, Mike Bond carried out an actual attack on the IBM 4758. This shook the industry, since the device was certified to FIPS 140-1 level 4 (in fact the US government declared that it was unhackable). In addition to the meet-in-the-middle attack, he used yet another hidden design error — key replication.
As DES became vulnerable to brute force, financial institutions moved to two-key triple DES: the block was encrypted with the left key, decrypted with the right key and encrypted again with the left key. IBM complicated the task by storing the left and right keys separately. They took measures so that they could not be confused (the left and right keys were encrypted differently, having different types), but they were unable to rigidly bind the two halves together.
The attack consisted of the following:

1. The attacker generated a large number of terminal master keys and collected the check values of each of them (the check value is computed by encrypting a string of zeros under the key).
2. All the check values were saved in a hash table.
3. A brute-force search was performed: a key was guessed, a fixed test pattern was encrypted, and the result was compared with the hash table.
4. Using a key space of 2^56, an attacker who could generate 2^16 target keys (which was done during a lunch break) could find a match with an effort of about 2^40 (which took about a week on a PC).

Having two single DES keys with known values inside the 4758, the attacker could swap the left and right halves in order to obtain a known true triple DES key. This known key was then used to export other valuable keys from the device. The attack was actually implemented and demonstrated in prime time on television.

Multiparty Computations and Differential Attacks on Protocols

The next set of attacks on the APIs of security modules was initiated by Jolyon Clulow in 2003. They depended on manipulating the details of the application logic in order to leak information.
His first attack exploited error messages. One of the PIN block formats used for protection combined the PIN and the account number with the help of XOR and then encrypted them (this was done to prevent attacks in which the encrypted PIN was not tied to the account number). However, XOR turned out to be a bad way to do this. If an incorrect account number was sent with the PIN block, the device decrypted the block, applied XOR with the account number, discovered that the result was not a decimal number, and returned an error message. By feeding a series of transactions with incorrect account numbers, one could quickly compute the PIN itself.
An even simpler attack was found against IBM's method of PIN code generation. The customer's account number was encrypted with the help of the PIN verification key, giving a string of 16 hexadecimal digits. The first four were converted into decimal digits for use as the PIN with the help of a decimalisation table. This gave the "natural PIN", to which an "offset" was added, allowing the customer to choose a memorable PIN.
The problem was that the decimalisation table could be manipulated. If the table was set to zeros (0000000000000000), the PIN "0000" would be generated and returned in encrypted form. Then the call was repeated with the table 1000000000000000. If the encrypted result changed, the attacker knew that the DES output contained a "0" in the first four digits. Using several dozen specially selected queries, one could determine the value of the PIN. Since the method compares repeated but slightly modified runs of one and the same protocol, we called this attack differential analysis of protocols.
The industry initially reacted by introducing rules for admissible decimalisation tables (for example, the table must have no fewer than eight different values). But this did not help (try 0123456789012345, then 1123456789012345 and so on). The only real solution was to remove the decimalisation table altogether.

The Attack on EMV

It would seem that after the publication of the attacks in 2001, the developers of security modules should have become more cautious when adding new transactions. But no! The banking industry continued to demand the addition of new functions that broke the API again and again.
An interesting recent example was a transaction ordered by the EMV consortium to support secure messaging between a smart card and a bank's security module. The goal was that when a bank card appeared in an online transaction, the bank could order it to change some parameter, for example a new key. The "Secure Messaging For Keys" transaction allowed the server to order the security module to encrypt a text message, followed by a key, using a key of the type "for exchange with the bank's smart cards". The encryption could be in CBC or ECB mode, and the text message could have variable length.
This allowed an attacker to choose the length of the message so that exactly one byte of the target key crossed the boundary of an encryption block. This byte could be determined by sending a series of messages one byte longer, where the extra byte went through all possible values until the key byte was found. Then the attacker could attack each of the remaining bytes of the key one after another. In this way, any exportable key could be extracted from the module.

Attacks on Operating System APIs

The second class of API attacks is connected with concurrency and is well illustrated by the vulnerabilities discovered by Robert Watson in system call wrappers.
System call wrappers are used to strengthen the security of operating systems; reference monitors are an example, as is antivirus software. Wrappers intercept the calls made by applications to the OS, analyze them, check them and may pass them on with some modifications: for example, a Low process attempting to access High data may be given dummy data or an error message.
When John Anderson proposed the concept of the reference monitor in 1972, he required that it be tamper-proof, unbypassable and small enough for verification. At first glance, modern wrappers are exactly that — until you start thinking about time. Wrappers usually assume that system calls are atomic, but they are not; modern OS kernels are very heavily parallel. System calls are not atomic either with respect to each other or with respect to the wrappers. There exist numerous opportunities for two system calls to race for access to shared memory, which leads to TOCTTOU (Time-of-Check-to-Time-of-Use) attacks.
A typical attack consists in causing a race over user memory, forcing the kernel to "go to sleep" at an inconvenient moment, for example because of a page fault. In the attack on GSWTK, Watson called a path whose name crossed the page boundary by exactly one byte, forcing the kernel to sleep while the page was loaded; then he replaced the path in memory. It turned out that the windows for such races are large and reliable.
Processors are becoming ever more parallel, and OSes are optimized to exploit this fact. This type of attack may become an ever more serious problem; moreover, as code analysis tools make stack overflows rarer, it is quite likely that it is race conditions that will become the attack of choice.
What can be done to limit them? The only real solution is to rewrite the API. In an ideal world, operating systems would move to a message-passing model, which would exclude (or greatly reduce) the problems of concurrency. But this is hardly practical for OS vendors whose business models depend on backward compatibility. The pragmatic compromise is to build functions into the OS itself to combat concurrency attacks; Linux Security Modules do this, as does Mac OS X 10.5 (based on TrustedBSD, on which Watson worked).
In short, the APIs provided by standard operating systems have a number of known weaknesses, but the solution in the form of a wrapper that places yet another API in front of the vulnerable API looks extremely fragile in a highly parallel environment. The wrapper would have to understand the memory layout fully enough to be completely effective, which would make it as complex (and as vulnerable) as the OS itself that it was trying to protect.

Protection Methods, Commercial Exploitation

Commercial Exploitation

Not all Emsec attacks are connected with secret military observation or with laboratory hacks of tamper-resistant devices. Recall the vans mentioned for detecting non-payers of television licenses in Britain and the fuss around the electronic voting machines in Holland. There are also marketing applications.
For example, the American event organizer SFX Entertainment tracks which music customers are listening to in their car radios when they drive into the parking lot of the venue. This is done by intercepting the spurious radio-frequency emanations from the radio receiver's local oscillator. Although this action is legal, it causes irritation among privacy advocates. The same equipment is sold to car dealerships, shopping center operators and radio stations.

Defenses

The techniques that can be used to protect smart cards from active Emsec threats are similar to those applied in the passive cases, but with some differences. The use of temporal randomness (jitter) is still useful, since a naive adversary may no longer know exactly when to insert the glitch. However, an experienced adversary may well analyze the power consumption curve of the processor in real time and compare it with the code in order to identify the critical target instructions. In addition, fault attacks are difficult to stop with the help of jitter, since the exact location of the fault in the code is usually not decisive.
In some cases defensive programming is sufficient. For example, the PIN-guessing method described above is prevented in more modern cards by decrementing the attempts counter, requesting the PIN code and subsequently incrementing the counter only in the case of a correct entry. Attacks on public-key protocols can be made significantly more difficult if one simply checks the result of the computations.
Other systems use specialized protective hardware, for example a circuit that combines the card reset with a circuit detecting clock frequencies that are too high or too low. Ordinary resets include dividing the clock frequency by two for several cycles, so an attacker who has found a way to disable the monitoring function will most likely discover that he cannot reset the card at all when the power is switched on.
Optical probing is much more difficult; the attack that a card may face today is that the adversary places it in a test rig, initiates a cryptographic operation and directs a laser at the chip in order to cause a single fault of the device at a precisely measured moment of time. With the help of a motorized stage one can check hundreds of different targets per hour.
At Cambridge a protection technology was developed and prototyped that can withstand such an onslaught, using dual-rail self-timed logic. In such logic, instead of transmitting a '1' through a high level and a '0' through a low level on one line, we use two lines for each logical bit. We transmit a '1' as 'HighLow' and a '0' as 'LowHigh'; the end of a logical operation is 'LowLow'. Such logic has been known for many years and has the property: if the state 'HighHigh' somehow gets into the system, it tends to spread over the whole chip, blocking it and making the device inoperable until reset. We turned this into an advantage by defining 'HighHigh' as an "alarm" state, and redesigned the logic elements so that a single fault would cause the alarm to spread. We also "sprinkled" the chip with many alarm sensors. And since the logic is balanced, the power consumption depends much less on the data; the signals that could potentially be used for power analysis were attenuated by approximately 20 dB. A number of other researchers have recently begun to study such exotic design styles, and some of them have begun to appear in commercial products. Redundant design can be quite expensive, costing at least three times as much as a standard CMOS structure, but the cost of one transistor may already have fallen to the level where this makes sense.

Summary on Emission Security

Emission Security (Emsec) covers a whole range of threats in which the security of systems can be compromised because of compromising emanations: whether they are implanted "bugs", unintentional radio-frequency or conductive electromagnetic radiation, or radiation induced by some external influence. Although initially this was a problem of national intelligence communities, today Emsec is a real problem for companies producing security products such as smart cards and ATMs. Many of these products can be hacked by observing spurious radio signals or conductive emissions. Protection against such threats is not as simple as it may seem.

Research Problems

A comprehensive set of emission security standards for commercial use is needed. The military standards (NATO SDIP-27 and the US NSTISSAM) are classified, although they have leaked onto the net. The civilian RFI/EMC standards (IEC/CISPR22 and the stricter MIL-STD-461E) simply were not developed for the protection of information. The recent panic in Holland over the Tempest interception of voting machines shows that standards are needed so that buyers and suppliers of equipment can decide whether they are required in each particular application.

Summary on APIs

Interfaces over time become richer, dirtier and nastier. Design errors of interfaces are widespread: from the world of cryptoprocessors through various embedded systems right up to antivirus software and the operating system itself. Wherever trusted software interacts with less trusted software, the interface will most likely "leak" more than the developer of the trusted part intended.
Failures tend to arise because of complexity. We discussed two main stories: cryptoprocessors that accumulated so many transactions that the developers lost the ability to understand their interaction, and system call wrappers that try to audit and filter the calls to the operating system API. At the level of pure computer science we could regard the former as examples of the composition problem or of the task of secure multiparty computation, and the latter as concurrency failures. However, these are industrial-scale systems, not "blackboard" models. A security module may have hundreds of transactions, and with each update a new batch is added. At the application level many failures can be regarded as feature interactions. There are also specific failures, such as the slow leakage of information from poorly designed cryptosystems, which would not be a serious problem in the case of a single transaction, but becomes fatal when the adversary can seize a server and inject hundreds of transactions per second.
API security is already important and is becoming even more important as computers become more complex, diverse and parallel. If Microsoft releases the original mechanisms promised for Trusted Computing in future versions of Windows, then APIs will become even more critical — application developers will be offered to write code containing a "more trusted" part (the NCA) and a "less trusted" ordinary application. Even professionals working in security module companies release APIs with serious errors; what are the chances that NCAs will bring benefit if everyone starts designing their security APIs on their own?
What can be done? One of the lessons learned is that a "secure" processor is not secure if its API is not simple enough to understand and to verify. If you are responsible for a bank's cryptography, a reasonable decision will be to order a security module tailored to your needs, so that it contains only the transactions that you really need. If this is too inconvenient or expensive, filter the transactions and discard everything except the most necessary.
As Robert Watson's work shows, complex APIs for highly parallel systems probably cannot be fixed in this way. If you have critically important applications that depend on such a platform, perhaps you should draw up a migration plan.
Finally, a whole mass of API problems will probably arise when applications interact with each other. As the world moves to web services that begin to communicate with one another, their APIs are opened up to third-party developers — as has just happened, for example, with Facebook. Complexity alone is already enough; later, in another part of my material, we will discuss how social networking sites, in particular, push the complexity of security policy to its limits in trying to cover a significant part of human social behavior. And managing the evolution of APIs is one of the most difficult tasks in security engineering. If you combine this with the fact that economic pressure pushes web applications toward insecure default settings (for example, making everything searchable), and with the high probability that not all third-party developers will be benevolent, it becomes clear that problems await us.

Research Problems

The computer science approach to the problem of API security consists in trying to adapt the tools of formal methods to prove the security of interfaces. On this question a growing body of literature exists, but the methods can still cover only fairly simple APIs. Verifying a single protocol is difficult enough, and the research community spent most of the 1990s learning how to do it. However, a protocol may consist of 2–5 messages, whereas a cryptoprocessor may have hundreds of transactions.
The alternative approach, as in the world of protocols, is to try to work out robustness principles that will guide the developer. As in that field, robustness is to some extent a matter of clarity and unambiguity. Verifying that there is no obscure sequence of transactions that will violate your security policy is difficult enough; and when your policy is not even precisely formulated, it looks impossible.
However, robustness alone is not enough. At the tactical level the history of API security has given us several lessons. Atomicity really does matter (together with consistency, isolation and durability — the other desirable attributes of transaction processing systems). At an even lower level we saw a couple of compelling reasons why using exclusive-or to combine keys or PIN codes is an extremely stupid idea; nobody understood this before. What other common design practices should we reconsider?